Re: [SLIS] mise en place d'un repository
Laurent a écrit : Pour la validation, il me semblerai bon de faire une maquette de ce vous allez déployez. Je m'explique : Vous prenez 2 ou 3 machines. * Une jour le rôle de dépôt des mises à jour, * Une deuxième joue de rôle d'un poste client utilisé par un administrateur s'il est différent des autres postes de travail, * Une troisième pour simuler un poste de travail standard. S'il y a plus de configuration alors c'est un poste par type de conf. Il faut aussi une autre machine configurée comme celle qui joue le rôle de dépôt. Après il ne reste plus qu'a : 1 - Vérifier les package un à un (clés PGP, package cassés, ...) 2 - Tester l'installation des packages un à un et valider les fonctionnalités mises en oeuvre par le poste mis à jour 3 - Si tous c'est bien passé, alors mettre à jour la machine qui joue le rôle de dépôt (Et oui, faut pas l'oublier celle-là) 4 - Tester si le système de mise à jour fonctionne encore Et là si tout fonctionne, alors c'est que ça doit passer... Salut, Je pense que l'on part sur cette piste : Un repository pour les serveurs SLIS avec trois arbo : slis (en 3 branches /stable / testing /unstable) sarge (en 2 branches /to_be_validate /validate) security (en 2 branches /to_be_validate /validate) Afin d'avoir des slis de test en testing et en unstable pour tester les màj to_be_validate avant de les transférer dans la branche validate. Maintenant, les branches to_be_validate de sarge et de security ne contiendraient que les paquets nécessaires aux serveurs SLIS. Quel outil vous semble le plus adapté pour ce travail ? Si j'ai bien compris debmirror est un outil de mirroring d'une branche complète (avec certe des exclusions), ou alors scripter nous même la mise à jour des paquets et d'organiser ces dépots avec apt-ftparchive... L'idéal serait de pouvoir utiliser un fichier contenant la liste des paquets utiles à mirorrer. A+ -- Eric Mercier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[SLIS] mise en place d'un repository
Bonjour, Le projet SLIS (Serveurs Linux pour l'Internet Scolaire) prépare sa future version 4 sous Debian, et nous avons besoin de conseils ! Les SLIS assurent la fonction de serveurs de communication dans les établissements scolaires : firewall, messagerie, DHCP, DNS, ... Il y a environ 7000 serveurs SLIS en France dans les lycées, collèges, et écoles, répartis dans les différentes académies. Les différentes académies gèrent leurs slis depuis des plates formes d'administration (SLIM = slis management) En particulier, les serveurs SLIS sont automatiquement mis à jour par script la nuit (les SLIS se connectent à la plateforme centrale pour effectuer différentes opérations de maintenance, dont les màj), sans intervention de l'administrateur dans l'établissement. Afin d'assurer au mieux la disponibilité des SLIS déployés, l'administrateur de plateforme centrale doit s'assurer que les mises à jours n'entraîneront pas d'effets de bords. Ceci est un point très important : lorsqu'une académie dispose de plusieurs centaines de SLIS en production, répartis sur un secteur parfois assez étendu, il vaut mieux s'assurer qu'une mise à jour ne plantera pas l'ensemble du parc ! :) C'est pourquoi l'administrateur de plateforme centrale dispose d'un dépot apt spécifique, dans lequel il place les mises à jours de sécurités ainsi que les mises à jours fonctionnelles après les avoir « validées ». Afin de préparer le déploiement et la mise à jour des serveurs SLIS4, nous réfléchissons à l'organisation des dépôts académiques des paquets debian. Sur ces dépôts, nous devrons donc avoir : - les paquets deb de SLIS4 proprement dit - Les paquets debian / sarge / main nécessaires au SLIS4 - Les paquets de mise à jour de sécurité (issus de security) : avant de rendre disponible une màj de security, l'administrateur s'assure de l'absence d'effets de bord. nous envisageons la solution suivante : Un dépôt slis/ avec trois branches (stable / testing / unstable) Un dépôt sarge ( éventuellement ne contenant que les paquets nécessaires à SLIS) Un dépôt updates (issu du security officiel qui aura été validé) C'est là que je sollicite vos compétences : - y a t-il une meilleure solution ? - concernant le dépot officiel sarge : est-ce qu'il peut arriver qu'il subisse des modifications (mis à jour, etc) ? En d'autres termes, devons-nous également surveiller les paquets disponibles dans sarge, pour prévenir les éventuels effets de bords ? - est-il sérieux de valider à la main les mises à jour de security ? Bien Cordialement -- Eric Mercier http://wiki.debian.org/DebianEduFrench/SLIS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SLIS] mise en place d'un repository
On Wed, 15 Mar 2006, Eric Mercier wrote: nous envisageons la solution suivante : Un dépôt slis/ avec trois branches (stable / testing / unstable) Un dépôt sarge ( éventuellement ne contenant que les paquets nécessaires à SLIS) Un dépôt updates (issu du security officiel qui aura été validé) C'est là que je sollicite vos compétences : - y a t-il une meilleure solution ? Je retourne la question, qu'est-ce qui ne te satisfait pas là-dedans ? Ton raisonnement m'a paru logique et la démarche aussi... - concernant le dépot officiel sarge : est-ce qu'il peut arriver qu'il subisse des modifications (mis à jour, etc) ? En d'autres termes, devons-nous également surveiller les paquets disponibles dans sarge, pour prévenir les éventuels effets de bords ? Oui sarge est mise à jour à chaque révision (3.1r2 étant la prochaine). http://wiki.debian.org/DebianReleases/PointReleases Ces révisions incluent la plupart des mises à jour de sécurité et d'autres mises à jour importante. On est très conservateur au niveau de ce qui est accepté mais cela pourrait évoluer à l'avenir maintenant que le responsable de ces mises à jour a changé (notamment en intégrant des paquets de volatile). Les mises à jour à venir sont disponibles dans les répertoires stable-proposed-updates des miroirs. - est-il sérieux de valider à la main les mises à jour de security ? Globalement les MAJ de sécurité ne doivent rien casser, mais il est déjà arrivé que certains effets de bords soient gênants, cf la mise à jour de sudo qui fait perdre tout l'environnement ou la MAJ du noyau qui va nécessiter une mise à jour de l'installateur. A+ -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SLIS] mise en place d'un repository
- concernant le dépot officiel sarge : est-ce qu'il peut arriver qu'il subisse des modifications (mis à jour, etc) ? En d'autres termes, devons-nous également surveiller les paquets disponibles dans sarge, pour prévenir les éventuels effets de bords ? Oui. Les MAJ de stable, contrairement à une opinion couramment répandue, ne concernent PAS que les MAJ de sécurité. Cf par exemple l'arrivée d'une MAJ samba dans sarge récemment (c'était bien sûr toujours un 3.0.14a, mais il y a eu une modif -me souviens plus laquelle- qui n'était pas directement liée à la sécurité) - est-il sérieux de valider à la main les mises à jour de security ? Oui, à mon sens. Si je reprends l'exemple de samba, une mise à jour provoque un redémarrage de démon donc, ne serait-ce que pour avoir l'opportunité de valider le *moment* où se fera la mise à jour, il vaut mieux une action manuelle. signature.asc Description: Digital signature
Re: [SLIS] mise en place d'un repository
Le Mercredi 15 Mars 2006 20:14, Eric Mercier a écrit : Merci de vos réponses, Raphael Hertzog a écrit : On Wed, 15 Mar 2006, Eric Mercier wrote: C'est là que je sollicite vos compétences : - y a t-il une meilleure solution ? Je retourne la question, qu'est-ce qui ne te satisfait pas là-dedans ? Ton raisonnement m'a paru logique et la démarche aussi... Merci :=) mais je préférais avoir confirmation avant de lancer les grosses manoeuvres... Et il nous reste à bosser sur le mechanisme de validation ... D'oû d'ailleurs, la necessité d'avoir 3 branches à notre dépôt SLIS (en réponse à huji) pour pouvoir facilement mettre en place des serveurs de test ... Oui sarge est mise à jour à chaque révision (3.1r2 étant la prochaine). http://wiki.debian.org/DebianReleases/PointReleases Ces révisions incluent la plupart des mises à jour de sécurité et d'autres mises à jour importante. On est très conservateur au niveau de ce qui est accepté mais cela pourrait évoluer à l'avenir maintenant que le responsable de ces mises à jour a changé (notamment en intégrant des paquets de volatile). Les mises à jour à venir sont disponibles dans les répertoires stable-proposed-updates des miroirs. Globalement les MAJ de sécurité ne doivent rien casser, mais il est déjà arrivé que certains effets de bords soient gênants, cf la mise à jour de sudo qui fait perdre tout l'environnement ou la MAJ du noyau qui va nécessiter une mise à jour de l'installateur. Effectivement, tout cela nous conforte dans le principe indispensable de validation de ces mises à jour ! (et pour sarge et pour security) Nous souhaitons faire fonctionnel et *beau* quitte à retarder légèrement la mise en production, c'est pourquoi vos avis sont très importants ! Cordialement Eric Mercier Pour la validation, il me semblerai bon de faire une maquette de ce vous allez déployez. Je m'explique : Vous prenez 2 ou 3 machines. * Une jour le rôle de dépôt des mises à jour, * Une deuxième joue de rôle d'un poste client utilisé par un administrateur s'il est différent des autres postes de travail, * Une troisième pour simuler un poste de travail standard. S'il y a plus de configuration alors c'est un poste par type de conf. Il faut aussi une autre machine configurée comme celle qui joue le rôle de dépôt. Après il ne reste plus qu'a : 1 - Vérifier les package un à un (clés PGP, package cassés, ...) 2 - Tester l'installation des packages un à un et valider les fonctionnalités mises en oeuvre par le poste mis à jour 3 - Si tous c'est bien passé, alors mettre à jour la machine qui joue le rôle de dépôt (Et oui, faut pas l'oublier celle-là) 4 - Tester si le système de mise à jour fonctionne encore Et là si tout fonctionne, alors c'est que ça doit passer... Ma petite contribution à la cause ;) Librement Laurent -- Laurent Registered as user #301590 with the Linux Counter
Re: [SLIS] mise en place d'un repository
Eric Mercier a écrit : - est-il sérieux de valider à la main les mises à jour de security ? oui et non : oui, car 2 vérifications valent mieux qu'une, surtout en prod non car faire intervenir des dépos suplémentaires qui ne sont pas des mirroires des dépos officiels engendre amha plus d'erreurs humaines que pas de vérif :-) Ma solution à 2 bales : - Un dépos apt pour les paquets SLIS - Un ou des proxy apt pour les packets officiels pour décharger les serveurs officiels - Un verrou pour la mise à jour sous forme d'URL http = lancement des apt-get dist-upgrade que si http://monserveur/update contient GO -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30JabberID : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
