2 votes

Gestion des interfaces réseau sur RHEL/CentOS avec GUI + script (system-config-network)

Nous avons deux serveurs CentOS 5.3 à charge équilibrée qui gèrent un nombre décent (~20) de sites Web d'achats individualisés. Le résultat final est que nous devons avoir un site sécurisé distinct par produit, ce qui entraîne un grand nombre d'alias de réseau, un pour chaque IP afin que SSL fonctionne.

Il est évident que la gestion manuelle de ces éléments n'est pas une partie de plaisir, surtout lorsque les serveurs meurent et qu'il faut les reconstruire pour garantir la cohérence.

Cependant, le responsable informatique n'est pas à l'aise avec l'utilisation d'outils CLI pour gérer certaines choses et tient absolument à disposer d'un outil GUI tel que system-config-network disponible au cas où il voudrait changer quelque chose.

Les scripts que j'ai écrits pour gérer les configurations des machines ont essayé de prendre cela en compte et pour la plupart de la configuration du réseau, j'utilise system-config-network-cmd -e > netconfig pour vider la configuration, effectuer des modifications, puis system-config-network-cmd -i -c -f netconfig pour réimporter les changements.

Le problème que j'ai rencontré est que les différentes versions de s-c-n-cmd ont agi différemment et souvent ce qui est importé n'est pas ce qui est réellement stocké. Même en faisant simplement system-config-network-cmd -e > netconfig suivi immédiatement par system-config-network -i -c -f netconfig sans faire de changement, on obtient une configuration différente (en exécutant system-config-network-cmd -e > netconfig2 et faire un diff netconfig netconfig2 montre des différences).

Que les problèmes avec s-c-n-cmd soient corrigés ou non, quelqu'un d'autre a-t-il rencontré ce problème ? J'ai essayé de modifier /etc/sysconfig/networking/* directement, mais cela ne semblait pas toujours fonctionner correctement non plus.

Existe-t-il une bonne méthode (TM) qui garantisse que les outils GUI RH et /etc/sysconfig/network-scripts puissent vivre en harmonie tout en étant scripts-friendly ?

J'envisage de passer à Puppet, mais c'est loin dans la longue liste des autres projets qui doivent être menés à bien, alors j'espère que quelque chose nous permettra de tenir jusque-là.

1voto

Jeff Hillman Points 3333

Une question : pourquoi l'IT manager veut changer la configuration du réseau, alors qu'il n'est même pas à l'aise avec un Shell ? Je lui dirais de rester loin des serveurs de production s'il s'attend à ce que je fasse bien mon travail. Il fait son travail (me payer), je fais le mien (serveurs de travail).

Quoi qu'il en soit, la commande 'setup' peut peut-être vous aider. Et pourquoi ne pas faire de /etc/sysconfig/network-scripts un dépôt svn ou git. Ainsi, vous pourrez au moins revenir à une version précédente. Je n'ai pas rencontré un problème comme le vôtre moi-même, parce que j'ai tendance à scripts la configuration du réseau lors du déploiement, et à en rester là. Ce que vous décrivez ressemble à un bug cependant, donc vous pourriez vouloir déposer un bugreport sur le comportement inconséquent de cet outil.

Configurer Puppet pour une tâche aussi triviale n'est pas un travail considérable, ce qui pourrait constituer une bonne solution.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X