oui je suis tout à fait d'accord avec ce point de vue. c'est également vrai avec d'autre applications orientées serveurs comme MySQL 4.1 qui offre par exemple les très attendues requetes imbriqués.
j'ai un serveur LDAP qui tourne woody (donc openldap 2.0.37) avec des schemas comme celui de courier.schema. il y a déjà qques temps j'ai essayé une migration woody -> sarge d'une copie de ce serveur sur un PC de test en sarge (donc openldap 2.1.3) pour voir , ben j'ai dû touillé le schema courier qui était plus bon (le serveur ldap démarrait) et revoir la conf en profondeur. J'ai dû chercher une bonne journée pour trouver le probleme sur le schema courier.
Alors ceux qui attendent patiemment que sarge = stable en se disant que ca va rouler tout seul peuvent avoir qques surprises auxquelles ils ne seront forcement pas préparés, et dans une situation d'urgence de maj qui roule justement pas tout seul sur un serveur de prod qui gère un annuaire de 20 000 personnes on est pas forcement bon, lucide et efficace, je sais de quoi je parle pour avoir déjà fait qque boulettes...
et puis bon, pour avoir gouté au debian installer depuis la RC1, quel bonheur de pouvoir installer vite et bien une sarge sur du matos récent avec des cartes rsx gigabit, du sata etc etc. sur woody, fallait que je mette une bonne vieille 3com 3c509x et après recompiler les e1000 des serveur xeon, pénible.
bref on voit bien que woody pour des serveurs c pas forcement la panacé sur certains services et quand on doit aussi aller vite.
en fait faudrait une distrib minimale "debian-serveur" plus facile à maintenir avec que des paquets orientés services/ serveurs plus à jour que woody et débarassé des logiciels genre gnome/kde/WM (les brokens dependencies viennent souvent de ceux là...)
quant à ubuntu, j'avoue que cette distrib ma soufflé (je teste hoary depuis peu) par sa qualité et sa facilité (reconnaissance du wifi, install des drivers nvdia accélérés avec 1 apt-get). Et ca rejoint un peu ce que je disait au-dessus : si ubuntu se concentre sur le desktop, pkoi pas une distrib basée sur debian qui se concentre sur le serveur...
merci, oui merci d'apprécier ce site web universitaire et de partager notre vision de l'informatique Libre dans les administrations.
ce post me fait énormément plaisir, pas pour mon ego, mais il récompense les nombreux efforts et sacrifices que Bob et moi-meme ,et aussi d'autres djeuns geeks travaillant ou ayant travaillé au CRI de Lille 3, avons fait pour faire entrer Linux et les LL dans l'université de Lille 3 depuis 2-3 ans. Et cette reconnaissance de geeks qui ont les mains dans le cambouis compte beaucoup pour moi.
Ce n'est pas évident de faire comprendre aux utilisateurs d'une Fac ,pas très orienté vers l'informatique à part comme simple outil, que les LL sont une alternative très sérieuse aux produits M$. Et qu'en tant qu'administration, il me semble cohérent que nous devons montrer aux contribuables qu'on fait tout pour pas jetter leur pognon par les fenetres (ah ah ah). Et effectivement meme si nous avons dû consentir à qques compromis pour IE et les Mac (downgrade du SSL en v2 sur le serveur web par exemple, c'est ti pas malheureux...) nous préférons dire aux utilisateurs nos convictions et pourquoi.
Nous migrons doucement mais surement une informatique qui tournait sous OpenVMS vers Linux (avec du Debian comme OS). Après le serveur web, c'est le tour de la messagerie de migrer depuis le 4/12 avec une passerelle SMTP / antivirus et un serveur POP/IMAP entièrement sous Linux et logiciels libres (postfix, courier pop/imap, squirrelmail, amavisd-new). Reste encore le DNS sous VMS, mais foi de geek, nous aurons "sa peau" avant fin 2005 ;-)
Encore merci pour ce post, il me met du baume au coeur pour 2005.
Intéressant. j'aimerai avoir vos retours d'experience sur des serveurs Debian en production quand la stable ne suffit pas.
quelles solutions utilisez / préconisez vous ?
1) passage systématique en testing/unstable (de toute la distrib) avec suivi / sécurité , bugs etc et avec éventuellement une machine de test indentique pour simuler les maj (encore faut-il pouvoir en avoir une, car OK sur un PC a 1000 euro mais sur un gros serveur genre bi-pro avec plein de gros disques IDE en raid, glups le portefeuille).
2) stable + backport des paquets recherchés en stable. pas tjs évident, les backports concernent souvent les applis les plus demandées aussi (genre Xfree, Gnome, KDE etc etc) non ?
3) faire un mix stable-testing ou stable-sid le plus limité possible. cad install d'une stable, et install uniquement des paquets voulus en testing/sid. Si oui quelles précautions prendre ?
C'est une grande question que je me pose pour une admin simple et efficace (et sûre !) mais tenant compte des besoins.
J'essaie de priviliégier la solution stable quand je peux mais il est vrai que dans certains cas, c'est franchement pas possible.
Par exemple, j'utilise pour une passerelle smtp/anti-virus une stable avec qques paquets qui ne sont dispo qu'en testing (amavisd-new). Pour le moment pas de soucis, mais j'avoue avoir qques "peurs" qd je vois une maj (je fais tjs un apt-get upgrade -s avant) sur un des paquets de la testing (j'ai pas de machine test en copie conforme, je sais je devrais la faire, mais manque de temps etc etc)
[^] # Re: et les serveurs
Posté par Arnaud Jayet . En réponse au journal Et si Debian ne sortait plus de distribution stable......?. Évalué à 1.
j'ai un serveur LDAP qui tourne woody (donc openldap 2.0.37) avec des schemas comme celui de courier.schema. il y a déjà qques temps j'ai essayé une migration woody -> sarge d'une copie de ce serveur sur un PC de test en sarge (donc openldap 2.1.3) pour voir , ben j'ai dû touillé le schema courier qui était plus bon (le serveur ldap démarrait) et revoir la conf en profondeur. J'ai dû chercher une bonne journée pour trouver le probleme sur le schema courier.
Alors ceux qui attendent patiemment que sarge = stable en se disant que ca va rouler tout seul peuvent avoir qques surprises auxquelles ils ne seront forcement pas préparés, et dans une situation d'urgence de maj qui roule justement pas tout seul sur un serveur de prod qui gère un annuaire de 20 000 personnes on est pas forcement bon, lucide et efficace, je sais de quoi je parle pour avoir déjà fait qque boulettes...
et puis bon, pour avoir gouté au debian installer depuis la RC1, quel bonheur de pouvoir installer vite et bien une sarge sur du matos récent avec des cartes rsx gigabit, du sata etc etc. sur woody, fallait que je mette une bonne vieille 3com 3c509x et après recompiler les e1000 des serveur xeon, pénible.
bref on voit bien que woody pour des serveurs c pas forcement la panacé sur certains services et quand on doit aussi aller vite.
en fait faudrait une distrib minimale "debian-serveur" plus facile à maintenir avec que des paquets orientés services/ serveurs plus à jour que woody et débarassé des logiciels genre gnome/kde/WM (les brokens dependencies viennent souvent de ceux là...)
quant à ubuntu, j'avoue que cette distrib ma soufflé (je teste hoary depuis peu) par sa qualité et sa facilité (reconnaissance du wifi, install des drivers nvdia accélérés avec 1 apt-get). Et ca rejoint un peu ce que je disait au-dessus : si ubuntu se concentre sur le desktop, pkoi pas une distrib basée sur debian qui se concentre sur le serveur...
a+
Arnaud
# dans le genre, y a netcat, mirrordir aussi
Posté par Arnaud Jayet . En réponse au message [Admin] Transférer son système d'une machine à une autre. Évalué à 2.
mais netcat et mirrordir j'aime bien, assez simple d'usage.
petite doc perso sans prétention sur netcat + tar :
http://smitters.univ-lille3.fr/wiki/SystemeNetcat
quant à mirrordir, il permet aussi facilement de synchroniser des repertoires
=> # apt-get install mirrordir
---
mes 2 cts
Arnaud
[^] # Re: On peut souligner autre chose
Posté par Arnaud Jayet . En réponse au journal Linux et l'université Lille3 - Charles de Gaulle. Évalué à 5.
merci, oui merci d'apprécier ce site web universitaire et de partager notre vision de l'informatique Libre dans les administrations.
ce post me fait énormément plaisir, pas pour mon ego, mais il récompense les nombreux efforts et sacrifices que Bob et moi-meme ,et aussi d'autres djeuns geeks travaillant ou ayant travaillé au CRI de Lille 3, avons fait pour faire entrer Linux et les LL dans l'université de Lille 3 depuis 2-3 ans. Et cette reconnaissance de geeks qui ont les mains dans le cambouis compte beaucoup pour moi.
Ce n'est pas évident de faire comprendre aux utilisateurs d'une Fac ,pas très orienté vers l'informatique à part comme simple outil, que les LL sont une alternative très sérieuse aux produits M$. Et qu'en tant qu'administration, il me semble cohérent que nous devons montrer aux contribuables qu'on fait tout pour pas jetter leur pognon par les fenetres (ah ah ah). Et effectivement meme si nous avons dû consentir à qques compromis pour IE et les Mac (downgrade du SSL en v2 sur le serveur web par exemple, c'est ti pas malheureux...) nous préférons dire aux utilisateurs nos convictions et pourquoi.
Nous migrons doucement mais surement une informatique qui tournait sous OpenVMS vers Linux (avec du Debian comme OS). Après le serveur web, c'est le tour de la messagerie de migrer depuis le 4/12 avec une passerelle SMTP / antivirus et un serveur POP/IMAP entièrement sous Linux et logiciels libres (postfix, courier pop/imap, squirrelmail, amavisd-new). Reste encore le DNS sous VMS, mais foi de geek, nous aurons "sa peau" avant fin 2005 ;-)
Encore merci pour ce post, il me met du baume au coeur pour 2005.
Joyeuses fetes de fin d'année à tous.
--
Arnaud aka Braque
[^] # Re: Debian ou comment "produire" autrement
Posté par Arnaud Jayet . En réponse à la dépêche La sortie de la prochaine Debian menacée ?. Évalué à 1.
Intéressant. j'aimerai avoir vos retours d'experience sur des serveurs Debian en production quand la stable ne suffit pas.
quelles solutions utilisez / préconisez vous ?
1) passage systématique en testing/unstable (de toute la distrib) avec suivi / sécurité , bugs etc et avec éventuellement une machine de test indentique pour simuler les maj (encore faut-il pouvoir en avoir une, car OK sur un PC a 1000 euro mais sur un gros serveur genre bi-pro avec plein de gros disques IDE en raid, glups le portefeuille).
2) stable + backport des paquets recherchés en stable. pas tjs évident, les backports concernent souvent les applis les plus demandées aussi (genre Xfree, Gnome, KDE etc etc) non ?
3) faire un mix stable-testing ou stable-sid le plus limité possible. cad install d'une stable, et install uniquement des paquets voulus en testing/sid. Si oui quelles précautions prendre ?
C'est une grande question que je me pose pour une admin simple et efficace (et sûre !) mais tenant compte des besoins.
J'essaie de priviliégier la solution stable quand je peux mais il est vrai que dans certains cas, c'est franchement pas possible.
Par exemple, j'utilise pour une passerelle smtp/anti-virus une stable avec qques paquets qui ne sont dispo qu'en testing (amavisd-new). Pour le moment pas de soucis, mais j'avoue avoir qques "peurs" qd je vois une maj (je fais tjs un apt-get upgrade -s avant) sur un des paquets de la testing (j'ai pas de machine test en copie conforme, je sais je devrais la faire, mais manque de temps etc etc)
merci.