On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !)
un script permettant de faire des updates automatiques de machines Linux.
C'est sans doute assez trivial, mais je ne vois pas comment faire, je
débute toujours sous Linux... j'ai regardé du coté de wget et rsync
mais, rien ne m'inspire vriament... :/
Grossièrement, chaque machine aurait un script dans sa crontab (éxécuté
toutes les nuits par exemple) qui :
- se connecte au FTP concenant les updates
- vérifie dans un répertoire si il y a un script qui n'a pas encore
été éxécuté
--> Premier problème pour moi !
Comment faire cela ? garder dans un fichier dans /tmp le nom du dernier
fichier téléchargé et on récupère le fichier plus récent que ce fichier
"de référence" ?
Ou peut-être y a-t-il un moyen de synchroniser 2 répertoires distants,
et que si un nouveau fichier est ajouté, on le récupère et on l'éxécute
? Je pensais utiliser wget, mais je viens de découvrir une commande
spécifique : rsync.
Create a mirror image of fly's web (with the same directory structure
the original has), up to six recursion levels, with only one try per
document, saving the verbose output to log file 'log':
wget -r -l6 -t1 -o log http://fly.cc.fer.hr/
En résumé, je ne vois pas du tout comment synchroniser 2 répertoires,
voir les fichiers qui ont été nouvellement ajoutés sur le serveur FTP
distant et éxécuter ces scripts en local
- éxécute le script sur la machine distante. Ce script récupère les
packages "kivonbien"
- écrit dans syslog si tout s'est bien passé ou pas
- update le fichier dans /tmp
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
Le Mon, 28 Jul 2003 16:35:47 +0200, Julien ROBIN écrivait:
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !) un script permettant de faire des updates automatiques de machines Linux.
Ca dépend fortement de la distribution. Il existe des outils qui font ça très bien tout seul pour RedHat (apt-rpm ou apt-get, voir freshrpms.net), Mandrake (urpmi, c'est fourni avec), Debian et ses dérivés (apt-get). Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances "apt-get update", puis "apt-get dist-upgrade" et voilà.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Le Mon, 28 Jul 2003 16:35:47 +0200, Julien ROBIN écrivait:
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !)
un script permettant de faire des updates automatiques de machines Linux.
Ca dépend fortement de la distribution. Il existe des outils qui font ça
très bien tout seul pour RedHat (apt-rpm ou apt-get, voir freshrpms.net),
Mandrake (urpmi, c'est fourni avec), Debian et ses dérivés (apt-get).
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances
"apt-get update", puis "apt-get dist-upgrade" et voilà.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Le Mon, 28 Jul 2003 16:35:47 +0200, Julien ROBIN écrivait:
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !) un script permettant de faire des updates automatiques de machines Linux.
Ca dépend fortement de la distribution. Il existe des outils qui font ça très bien tout seul pour RedHat (apt-rpm ou apt-get, voir freshrpms.net), Mandrake (urpmi, c'est fourni avec), Debian et ses dérivés (apt-get). Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances "apt-get update", puis "apt-get dist-upgrade" et voilà.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Jean-Francois Billaud
Emmanuel Florac wrote:
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !) un script permettant de faire des updates automatiques de machines Linux.
[...]
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances "apt-get update", puis "apt-get dist-upgrade" et voilà.
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
JFB
-- I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. -- Professor Lowd, English, Ohio University
Emmanuel Florac wrote:
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !)
un script permettant de faire des updates automatiques de machines Linux.
[...]
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances
"apt-get update", puis "apt-get dist-upgrade" et voilà.
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur
un serveur de production sans un minimum de tests.
JFB
--
I am returning this otherwise good typing paper to you because someone
has printed gibberish all over it and put your name at the top.
-- Professor Lowd, English, Ohio University
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !) un script permettant de faire des updates automatiques de machines Linux.
[...]
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances "apt-get update", puis "apt-get dist-upgrade" et voilà.
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
JFB
-- I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. -- Professor Lowd, English, Ohio University
Daniel Déchelotte
| > Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu | > lances"apt-get update", puis "apt-get dist-upgrade" et voilà. | | Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur | un serveur de production sans un minimum de tests.
Toutafe. Le cron contient "apt-get upgrade --download-only" et envoie un courriel prevenant que des mises a jour sont disponibles.
Daniel -- http://yo.dan.free.fr/
| > Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu
| > lances"apt-get update", puis "apt-get dist-upgrade" et voilà.
|
| Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur
| un serveur de production sans un minimum de tests.
Toutafe.
Le cron contient "apt-get upgrade --download-only" et envoie un courriel
prevenant que des mises a jour sont disponibles.
| > Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu | > lances"apt-get update", puis "apt-get dist-upgrade" et voilà. | | Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur | un serveur de production sans un minimum de tests.
Toutafe. Le cron contient "apt-get upgrade --download-only" et envoie un courriel prevenant que des mises a jour sont disponibles.
Daniel -- http://yo.dan.free.fr/
Julien ROBIN
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !) un script permettant de faire des updates automatiques de machines Linux.
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances "apt-get update", puis "apt-get dist-upgrade" et voilà.
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses clients, et ce serait pour nous éviter un déployement manuel.
Sinon, le Linux en cause est une Slackware 4, et hélas il ne nous est pas possible d'upgrader à une version plus récente. Ceci dit, bien qu'ancienne, la Slackware 4 marche très bien ! ;)
Julien ROBIN
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet
!) un script permettant de faire des updates automatiques de machines
Linux.
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu
lances
"apt-get update", puis "apt-get dist-upgrade" et voilà.
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur
un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses
clients, et ce serait pour nous éviter un déployement manuel.
Sinon, le Linux en cause est une Slackware 4, et hélas il ne nous est
pas possible d'upgrader à une version plus récente.
Ceci dit, bien qu'ancienne, la Slackware 4 marche très bien ! ;)
On m'a demandé de mettre au point (ou mieux, de trouver sur Internet !) un script permettant de faire des updates automatiques de machines Linux.
Par exemple avec apt-get sous RedHat ou Debian, toutes les nuits tu lances "apt-get update", puis "apt-get dist-upgrade" et voilà.
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses clients, et ce serait pour nous éviter un déployement manuel.
Sinon, le Linux en cause est une Slackware 4, et hélas il ne nous est pas possible d'upgrader à une version plus récente. Ceci dit, bien qu'ancienne, la Slackware 4 marche très bien ! ;)
Julien ROBIN
Étienne Labaume
Le Tue, 29 Jul 2003 09:31:14 +0200, Julien nous disait:
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses clients, et ce serait pour nous éviter un déployement manuel.
Donc c'est toi qui contrôle à la fois les machines à mettre à jour et la source des mises à jour ? Ça facilite un peu les choses. Dis-moi si je me trompe: La société te fournit une archive de binaires à mettre à jour que tu dois installer sur x machines ? AMHA, même si c'est plutôt dédié aux fichiers texte qu'aux binaires, tu devrais utiliser CVS.
Description:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée kivabien dans la crontab des machines à mettre à jour pour qu'elles fassent périodiquement un checkout du CVS.
Plus d'infos sur CVS: http://www.cvshome.org
Sur le stockage des binaires: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_9.html#SEC80
-- Tinou
Le Tue, 29 Jul 2003 09:31:14 +0200, Julien nous disait:
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur
un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses
clients, et ce serait pour nous éviter un déployement manuel.
Donc c'est toi qui contrôle à la fois les machines à mettre à jour et la
source des mises à jour ? Ça facilite un peu les choses. Dis-moi si je
me trompe: La société te fournit une archive de binaires à mettre à jour
que tu dois installer sur x machines ? AMHA, même si c'est plutôt dédié
aux fichiers texte qu'aux binaires, tu devrais utiliser CVS.
Description:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes
mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée
kivabien dans la crontab des machines à mettre à jour pour qu'elles
fassent périodiquement un checkout du CVS.
Plus d'infos sur CVS:
http://www.cvshome.org
Sur le stockage des binaires:
http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_9.html#SEC80
Le Tue, 29 Jul 2003 09:31:14 +0200, Julien nous disait:
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses clients, et ce serait pour nous éviter un déployement manuel.
Donc c'est toi qui contrôle à la fois les machines à mettre à jour et la source des mises à jour ? Ça facilite un peu les choses. Dis-moi si je me trompe: La société te fournit une archive de binaires à mettre à jour que tu dois installer sur x machines ? AMHA, même si c'est plutôt dédié aux fichiers texte qu'aux binaires, tu devrais utiliser CVS.
Description:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée kivabien dans la crontab des machines à mettre à jour pour qu'elles fassent périodiquement un checkout du CVS.
Plus d'infos sur CVS: http://www.cvshome.org
Sur le stockage des binaires: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_9.html#SEC80
-- Tinou
Julien ROBIN
Le Tue, 29 Jul 2003 09:31:14 +0200, Julien nous disait:
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses clients, et ce serait pour nous éviter un déployement manuel.
Donc c'est toi qui contrôle à la fois les machines à mettre à jour et la source des mises à jour ? Ça facilite un peu les choses. Dis-moi si je me trompe: La société te fournit une archive de binaires à mettre à jour que tu dois installer sur x machines ? AMHA, même si c'est plutôt dédié aux fichiers texte qu'aux binaires, tu devrais utiliser CVS.
En fait, le serveur appartient à ma société, et nous "patchons" assez régulièrement des routeurs (qui sont des Linux boxes). Nous controlons le serveur et les routeurs distants. Et c'est nous qui développons les updates. En gros, on développe des scripts qui installent des updates (modification de fichiers de conf, installation de nouveaux packages, ...).
L'idée était de faire un script qui va chercher tout seul les scripts d'updates
Description:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée kivabien dans la crontab des machines à mettre à jour pour qu'elles fassent périodiquement un checkout du CVS.
Plus d'infos sur CVS: http://www.cvshome.org
Sur le stockage des binaires: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_9.html#SEC80
CVS avait été envisagé à une époque, mais il a été jugé qu'il n'était pas assez adapté à la tache, et était trop lourd à mettre en place. Dommage, ca aurait ouvert des perspectives...
Julien
Le Tue, 29 Jul 2003 09:31:14 +0200, Julien nous disait:
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur
un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses
clients, et ce serait pour nous éviter un déployement manuel.
Donc c'est toi qui contrôle à la fois les machines à mettre à jour et la
source des mises à jour ? Ça facilite un peu les choses. Dis-moi si je
me trompe: La société te fournit une archive de binaires à mettre à jour
que tu dois installer sur x machines ? AMHA, même si c'est plutôt dédié
aux fichiers texte qu'aux binaires, tu devrais utiliser CVS.
En fait, le serveur appartient à ma société, et nous "patchons" assez
régulièrement des routeurs (qui sont des Linux boxes).
Nous controlons le serveur et les routeurs distants.
Et c'est nous qui développons les updates.
En gros, on développe des scripts qui installent des updates
(modification de fichiers de conf, installation de nouveaux packages, ...).
L'idée était de faire un script qui va chercher tout seul les scripts
d'updates
Description:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes
mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée
kivabien dans la crontab des machines à mettre à jour pour qu'elles
fassent périodiquement un checkout du CVS.
Plus d'infos sur CVS:
http://www.cvshome.org
Sur le stockage des binaires:
http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_9.html#SEC80
CVS avait été envisagé à une époque, mais il a été jugé qu'il n'était
pas assez adapté à la tache, et était trop lourd à mettre en place.
Dommage, ca aurait ouvert des perspectives...
Le Tue, 29 Jul 2003 09:31:14 +0200, Julien nous disait:
Au passage, je ne pense pas que ça soit une bonne idée de faire ça sur un serveur de production sans un minimum de tests.
Oui oui oui.
En fait, ces updates sont des updates que ma société fournit à ses clients, et ce serait pour nous éviter un déployement manuel.
Donc c'est toi qui contrôle à la fois les machines à mettre à jour et la source des mises à jour ? Ça facilite un peu les choses. Dis-moi si je me trompe: La société te fournit une archive de binaires à mettre à jour que tu dois installer sur x machines ? AMHA, même si c'est plutôt dédié aux fichiers texte qu'aux binaires, tu devrais utiliser CVS.
En fait, le serveur appartient à ma société, et nous "patchons" assez régulièrement des routeurs (qui sont des Linux boxes). Nous controlons le serveur et les routeurs distants. Et c'est nous qui développons les updates. En gros, on développe des scripts qui installent des updates (modification de fichiers de conf, installation de nouveaux packages, ...).
L'idée était de faire un script qui va chercher tout seul les scripts d'updates
Description:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée kivabien dans la crontab des machines à mettre à jour pour qu'elles fassent périodiquement un checkout du CVS.
Plus d'infos sur CVS: http://www.cvshome.org
Sur le stockage des binaires: http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_9.html#SEC80
CVS avait été envisagé à une époque, mais il a été jugé qu'il n'était pas assez adapté à la tache, et était trop lourd à mettre en place. Dommage, ca aurait ouvert des perspectives...
Julien
Étienne Labaume
Le Tue, 29 Jul 2003 12:11:24 +0200, Julien nous disait:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée kivabien dans la crontab des machines à mettre à jour pour qu'elles fassent périodiquement un checkout du CVS.
[...]
CVS avait été envisagé à une époque, mais il a été jugé qu'il n'était pas assez adapté à la tache, et était trop lourd à mettre en place.
Plus simple: SUP (Software Upgrade Protocol implementation)
"The SUP System is a set of programs developed by Carnegie Mellon University that provide for collections of files to be maintained in identical versions across a number of machines. These programs are:
SUP: The "client" program, run by users or system maintainers, which initiates the upgrade activity on a machine requesting the latest version of a collection of files. SUP will normally be run as a daemon, firing up once each night (week, etc.) to upgrade the specified file collections.
SUPFILESRV: The "file server" program, a daemon that is run by the system maintainer to service requests for files initiated by client SUP programs. The file server runs on every machine used as a "repository" of distributable versions of files. It runs continuously and listens for network connection requests by individual client processes; for each individual client request, a process is forked to service that request.
SUPSCAN: The "file scanner" program, that may optionally be run periodically to speed up execution of the file server. It pre-compiles a list of files on the file system that match the specifications for a given file collection so that the file server need not do this during each upgrade of that collection. The file scanner is normally used daily for very large file collections that are upgraded by many clients each day; it is not so useful for small file collections or for those that are upgraded by only a few client machines per day."
Le Tue, 29 Jul 2003 12:11:24 +0200, Julien nous disait:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes
mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée
kivabien dans la crontab des machines à mettre à jour pour qu'elles
fassent périodiquement un checkout du CVS.
[...]
CVS avait été envisagé à une époque, mais il a été jugé qu'il n'était
pas assez adapté à la tache, et était trop lourd à mettre en place.
Plus simple: SUP (Software Upgrade Protocol implementation)
"The SUP System is a set of programs developed by Carnegie Mellon
University that provide for collections of files to be maintained in
identical versions across a number of machines. These programs are:
SUP: The "client" program, run by users or system maintainers, which
initiates the upgrade activity on a machine requesting the
latest version of a collection of files. SUP will normally be
run as a daemon, firing up once each night (week, etc.) to
upgrade the specified file collections.
SUPFILESRV: The "file server" program, a daemon that is run by the
system maintainer to service requests for files initiated by client
SUP programs. The file server runs on every machine used as a
"repository" of distributable versions of files. It runs continuously
and listens for network connection requests by individual client
processes; for each individual client request, a process is forked to
service that request.
SUPSCAN: The "file scanner" program, that may optionally be run
periodically to speed up execution of the file server. It
pre-compiles a list of files on the file system that match the
specifications for a given file collection so that the file server
need not do this during each upgrade of that collection. The file
scanner is normally used daily for very large file collections that
are upgraded by many clients each day; it is not so useful for small
file collections or for those that are upgraded by only a few client
machines per day."
Le Tue, 29 Jul 2003 12:11:24 +0200, Julien nous disait:
Tu installes un serveur CVS sur une machine sur laquelle tu uploades tes mises à jour au fur et à mesure qu'elles arrivent. Tu ajoutes une entrée kivabien dans la crontab des machines à mettre à jour pour qu'elles fassent périodiquement un checkout du CVS.
[...]
CVS avait été envisagé à une époque, mais il a été jugé qu'il n'était pas assez adapté à la tache, et était trop lourd à mettre en place.
Plus simple: SUP (Software Upgrade Protocol implementation)
"The SUP System is a set of programs developed by Carnegie Mellon University that provide for collections of files to be maintained in identical versions across a number of machines. These programs are:
SUP: The "client" program, run by users or system maintainers, which initiates the upgrade activity on a machine requesting the latest version of a collection of files. SUP will normally be run as a daemon, firing up once each night (week, etc.) to upgrade the specified file collections.
SUPFILESRV: The "file server" program, a daemon that is run by the system maintainer to service requests for files initiated by client SUP programs. The file server runs on every machine used as a "repository" of distributable versions of files. It runs continuously and listens for network connection requests by individual client processes; for each individual client request, a process is forked to service that request.
SUPSCAN: The "file scanner" program, that may optionally be run periodically to speed up execution of the file server. It pre-compiles a list of files on the file system that match the specifications for a given file collection so that the file server need not do this during each upgrade of that collection. The file scanner is normally used daily for very large file collections that are upgraded by many clients each day; it is not so useful for small file collections or for those that are upgraded by only a few client machines per day."
Plus simple: SUP (Software Upgrade Protocol implementation)
"The SUP System is a set of programs developed by Carnegie Mellon University that provide for collections of files to be maintained in identical versions across a number of machines. These programs are:
SUP: The "client" program, run by users or system maintainers, which initiates the upgrade activity on a machine requesting the latest version of a collection of files. SUP will normally be run as a daemon, firing up once each night (week, etc.) to upgrade the specified file collections.
SUPFILESRV: The "file server" program, a daemon that is run by the system maintainer to service requests for files initiated by client SUP programs. The file server runs on every machine used as a "repository" of distributable versions of files. It runs continuously and listens for network connection requests by individual client processes; for each individual client request, a process is forked to service that request.
SUPSCAN: The "file scanner" program, that may optionally be run periodically to speed up execution of the file server. It pre-compiles a list of files on the file system that match the specifications for a given file collection so that the file server need not do this during each upgrade of that collection. The file scanner is normally used daily for very large file collections that are upgraded by many clients each day; it is not so useful for small file collections or for those that are upgraded by only a few client machines per day."
En fait, j'ai parlé du problème avec un ingénieur... il a envie finalement de faire ca grace à RPM. Il me suffit donc d'installer le client RPM sur la Slack 4. Ensuite il faudra que l'on fasse nos propres RPM (pas trop dur). Et en fait d'automatisation, il semble qu'un petit script en Perl nous permette d'envoyer des commandes à tous nos routeurs distants à la volée. Ou alors on se débrouillera a faire un ptit script à mettre dans la crontab.
Il commence à avoir du temps pour bosser avec moi, je verrais ce que ca va donner ... :)
Plus simple: SUP (Software Upgrade Protocol implementation)
"The SUP System is a set of programs developed by Carnegie Mellon
University that provide for collections of files to be maintained in
identical versions across a number of machines. These programs are:
SUP: The "client" program, run by users or system maintainers, which
initiates the upgrade activity on a machine requesting the
latest version of a collection of files. SUP will normally be
run as a daemon, firing up once each night (week, etc.) to
upgrade the specified file collections.
SUPFILESRV: The "file server" program, a daemon that is run by the
system maintainer to service requests for files initiated by client
SUP programs. The file server runs on every machine used as a
"repository" of distributable versions of files. It runs continuously
and listens for network connection requests by individual client
processes; for each individual client request, a process is forked to
service that request.
SUPSCAN: The "file scanner" program, that may optionally be run
periodically to speed up execution of the file server. It
pre-compiles a list of files on the file system that match the
specifications for a given file collection so that the file server
need not do this during each upgrade of that collection. The file
scanner is normally used daily for very large file collections that
are upgraded by many clients each day; it is not so useful for small
file collections or for those that are upgraded by only a few client
machines per day."
En fait, j'ai parlé du problème avec un ingénieur... il a envie
finalement de faire ca grace à RPM. Il me suffit donc d'installer le
client RPM sur la Slack 4.
Ensuite il faudra que l'on fasse nos propres RPM (pas trop dur).
Et en fait d'automatisation, il semble qu'un petit script en Perl nous
permette d'envoyer des commandes à tous nos routeurs distants à la
volée. Ou alors on se débrouillera a faire un ptit script à mettre dans
la crontab.
Il commence à avoir du temps pour bosser avec moi, je verrais ce que ca
va donner ... :)
Plus simple: SUP (Software Upgrade Protocol implementation)
"The SUP System is a set of programs developed by Carnegie Mellon University that provide for collections of files to be maintained in identical versions across a number of machines. These programs are:
SUP: The "client" program, run by users or system maintainers, which initiates the upgrade activity on a machine requesting the latest version of a collection of files. SUP will normally be run as a daemon, firing up once each night (week, etc.) to upgrade the specified file collections.
SUPFILESRV: The "file server" program, a daemon that is run by the system maintainer to service requests for files initiated by client SUP programs. The file server runs on every machine used as a "repository" of distributable versions of files. It runs continuously and listens for network connection requests by individual client processes; for each individual client request, a process is forked to service that request.
SUPSCAN: The "file scanner" program, that may optionally be run periodically to speed up execution of the file server. It pre-compiles a list of files on the file system that match the specifications for a given file collection so that the file server need not do this during each upgrade of that collection. The file scanner is normally used daily for very large file collections that are upgraded by many clients each day; it is not so useful for small file collections or for those that are upgraded by only a few client machines per day."
En fait, j'ai parlé du problème avec un ingénieur... il a envie finalement de faire ca grace à RPM. Il me suffit donc d'installer le client RPM sur la Slack 4. Ensuite il faudra que l'on fasse nos propres RPM (pas trop dur). Et en fait d'automatisation, il semble qu'un petit script en Perl nous permette d'envoyer des commandes à tous nos routeurs distants à la volée. Ou alors on se débrouillera a faire un ptit script à mettre dans la crontab.
Il commence à avoir du temps pour bosser avec moi, je verrais ce que ca va donner ... :)
