Linux C - implementazione della capacità che un programma può aggiornare da solo

Question

Sto scrivendo un programma in ambiente C su Linux (Debian-Lenny) e vorrei che il programma venisse aggiornato quando un aggiornamento è disponibile (il programma viene avvisato quando un è disponibile un nuovo aggiornamento). Sto cercando un modo in cui il programma può aggiornarsi.

Quello che sto pensando è che il programma principale invoca un nuovo programma per gestire l'aggiornamento. Il programma di aggiornamento avrà (accesso a) il codice sorgente e ricevere le informazioni di aggiornamento sulle modifiche sul codice sorgente, qualcosa di simile:

edit1: line 20, remove column 5 to 20; 
edit2: line25, remove column 4-7 then add "if(x>3){" from the column4 
edit3: line 26, enter a new line and insert "x++;" 

poi uccidere il processo principale, ricompilare il codice sorgente, e quindi sostituire il nuovo binario con quello vecchio.

oppure esiste un modo migliore (più semplice) e standard per implementare la capacità che un programma può aggiornare da solo?

Uso il programma per controllare un sistema con una scheda incorporata Linux. Pertanto, non voglio che il codice sorgente sia accessibile a un'altra persona (se il sistema è compromesso o qualcosa del genere). Se il modo migliore per aggiornare un programma utilizzando il codice sorgente, come mi suggerisce di proteggere il codice sorgente? Se mi suggerisci di crittografare il codice sorgente, quale funzione (Linux C) può utilizzare il programma per crittografare e decrittografare il file sorgente?

Answer 1

Se il sistema di destinazione è Debian, è necessario sfruttare il sistema di imballaggio Debian per fornire aggiornamenti. Imballare l'applicazione compilata in un pacchetto .deb, distribuirla su un archivio APT incluso nel numero di sistema sources.list e utilizzare semplicemente cron per pianificare un controllo di aggiornamento regolare con apt. Il pacchetto .deb può includere uno script di post-installazione che riavvia l'applicazione.

È possibile eseguire un proxy di caching apt-proxy sui nodi "gateway" che dispongono di accesso a Internet e che gli altri nodi lo utilizzano come origine apt.

La distribuzione del codice sorgente in questo caso non è probabilmente appropriata, perché in tal caso è necessario includere una toolchain del compilatore completo sul sistema di destinazione.

Answer 2

Quello che stai descrivendo è molto simile allo stile anni '80 del rilascio del codice sorgente Unix, reso popolare dallo sviluppo di PERL. Si utilizza diff per ottenere una registrazione delle modifiche tra diverse versioni del codice sorgente, quindi distribuire questo file "patch" e utilizzare patch per eseguire le modifiche necessarie sul lato client. Questo non risolve i problemi relativi alla comunicazione di rete o al controllo della versione.

Un possibile svantaggio è che un download per la prima volta potrebbe essere necessario applicare molte patch per portare la versione. Questo è spesso il caso quando si studia il vecchio sorgente da nntp: comp.sources.unix.