Je préfère préciser que je ne connais pas systemd en profondeur avant toute chose, donc loin de moi l'idée de critiquer la chose (visiblement, on a vite fait d'être catalogué comme hyper-résistant au changement, ou comme raleur professionnel à la moindre critique donc je prends les devants !).
Mais il faut quand même distinguer 2 choses :
A) avoir systemd sur son système et le fait que ça boote normalement
B) l'administrer au jour le jour (avec des cas un peu louches)
Pour A), j'ai envie de dire : heureusement ;) C'est quand même la moindre des choses, sinon j'imagine qu'il n'y aurait même pas débat possible sur systemd.
Quand je boote un Windows, il fonctionne ! Idem avec une Fedora 17/systemd, et idem avec une Debian Squeeze/sysvinit. Plus ou moins vite peut être, mais ça boote. Dois-je en déduire que tout est parfait pour autant sous le capot ?
Par contre, pour B), quand j'ai un problème au démarrage, sous Windows, je suis perdu. J'ai beau chercher à droite et à gauche, essayer de refaire la chaine de boot, je ne m'en sors pas (certainement à cause d'un manque de connaissances, certes).
Avec sysvinit (ou l'init bsd), je peux bricoler, faire des trucs hyper sales, mettre des echo, des exit, des tests… je débuggue, et une fois mis la main sur le problème, j'enlève et je patche proprement.
J'ai l'impression que les gens avec systemd ont peur de perdre un peu de ce contrôle. Moi le premier d'ailleurs. Mais peut être qu'on peut s'en sortir aussi facilement qu'avec un init classique. C'est parfait, ArchLinux (la distrib que j'utilise) vient d'y passer, je vais pouvoir m'y frotter de plus près, et me faire mon propre avis.
Mais en tout cas, si je me contente de rajouter un init=/usr/lib/systemd/systemd à mon kernel, et que par magie, je retrouve mon espace de travail, je ne vais pas pour autant me dire "Roh là là ces trolleurs de linuxfr, ils y entendent rien, ça fonctionne parfaitement systemd !".
L'exemple du paquet cassé est peut être un peu tiré par les cheveux ceci dit :)
Mais ça fait quand même parti de la doc officielle, donc ça met le doute sur le choix entre testing et unstable...
En espérant que le projet CUT permette de régler ces choix cornéliens :)
Voilà une config qui fonctionne correctement et que j'utilise souvent :
# Bond public + bridge pour les VM
auto bond0
iface bond0 inet manual
slaves eth0 eth2
bond_mode active-backup
bond_miimon 100
bond_downdelay 200
bond_updelay 200
auto br0
iface br0 inet manual
bridge_ports bond0
bridge_stp off
bridge_fd 0
Le concept est grosso modo la même chose que toi :
J'ai mon hôte qui a 3 cartes réseaux :
- eth0 et eth2 sont en bonding, et le bond0 est bridgé. Ce sont en fait mes interfaces publiques, les VM (c'est de l'openvz mais l'idée est la même) s'attachent à ce bridge. Pas d'IP sur ce bridge par contre, car l'hôte n'est accessible que par VPN, il n'est pas accessible par le réseau public
- l'interface VPN est justement eth1, sur un réseau privée. Je ne bridge pas cette interface, pas besoin dans mon cas. Par contre, j'ai qqs hôtes où cette interface est bridgée pour que la VM sous jacente puisse accéder au VPN mais c'est très rare, et les options du bridge sont les même que plus haut.
Derrière, les cables sont pluggués sur des switchs avec du vlan pour séparer le vpn du public, enfin, du classique...
Quand tu modifies les paramètres innodb (notamment les paramètres innodb_log_file_size et innodb_data_file_path), il faut que le moteur innodb reconstruise les fichiers, sinon le mysql ne démarre pas (ou démarre mal, sans utiliser innodb). Enfin, normalement, y'a des erreurs un peu plus explicites dans les logs (mauvaise taille des iblogfile etc), mais j'imagine que ça doit être ça le problème.
Quand je fais une opération de la sorte, je prévois tout ça (pas en pleine journée par contre :p) :
- je dumpe mes bases
- je droppe les databases
- j'arrête le mysql
- j'efface les ib files : rm -f /var/lib/mysql/ib* # sur une debian
- je relance le mysql (là tu verras que le ibdata et les iblogfile vont se recréer, avec les nouvelles tailles que tu as donné dans le my.cnf, en l'occurence 2g pour les data, 256mo pour les ib logs)
- je réimporte les bases
Ca fait un peu beaucoup (certaines phases ne sont pas obligatoires, comme le drop des bases, mais j'ai eu des cas où j'ai dû tout faire, donc maintenant je suis prévenant), mais ça marche très bien :)
[^] # Re: Alors
Posté par ulver . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
Je préfère préciser que je ne connais pas systemd en profondeur avant toute chose, donc loin de moi l'idée de critiquer la chose (visiblement, on a vite fait d'être catalogué comme hyper-résistant au changement, ou comme raleur professionnel à la moindre critique donc je prends les devants !).
Mais il faut quand même distinguer 2 choses :
A) avoir systemd sur son système et le fait que ça boote normalement
B) l'administrer au jour le jour (avec des cas un peu louches)
Pour A), j'ai envie de dire : heureusement ;) C'est quand même la moindre des choses, sinon j'imagine qu'il n'y aurait même pas débat possible sur systemd.
Quand je boote un Windows, il fonctionne ! Idem avec une Fedora 17/systemd, et idem avec une Debian Squeeze/sysvinit. Plus ou moins vite peut être, mais ça boote. Dois-je en déduire que tout est parfait pour autant sous le capot ?
Par contre, pour B), quand j'ai un problème au démarrage, sous Windows, je suis perdu. J'ai beau chercher à droite et à gauche, essayer de refaire la chaine de boot, je ne m'en sors pas (certainement à cause d'un manque de connaissances, certes).
Avec sysvinit (ou l'init bsd), je peux bricoler, faire des trucs hyper sales, mettre des echo, des exit, des tests… je débuggue, et une fois mis la main sur le problème, j'enlève et je patche proprement.
J'ai l'impression que les gens avec systemd ont peur de perdre un peu de ce contrôle. Moi le premier d'ailleurs. Mais peut être qu'on peut s'en sortir aussi facilement qu'avec un init classique. C'est parfait, ArchLinux (la distrib que j'utilise) vient d'y passer, je vais pouvoir m'y frotter de plus près, et me faire mon propre avis.
Mais en tout cas, si je me contente de rajouter un init=/usr/lib/systemd/systemd à mon kernel, et que par magie, je retrouve mon espace de travail, je ne vais pas pour autant me dire "Roh là là ces trolleurs de linuxfr, ils y entendent rien, ça fonctionne parfaitement systemd !".
[^] # Re: Il y a eu du cadavre avec la dernière maj
Posté par ulver . En réponse à la dépêche Une nouvelle image d'installation pour Archlinux (2012.07.15) est disponible. Évalué à 1.
Lire ce que dit Pacman, et si ça ne te parait assez clair regarder sur le site officiel, et là tout était marqué (notamment le "never use --force for this update").
http://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/
[^] # Re: Jails ?
Posté par ulver . En réponse au message Quand utiliser la virtualisation. Évalué à 2.
http://wiki.openvz.org/Main_Page
http://fr.wikipedia.org/wiki/OpenVZ
Et depuis quelques versions, le kernel Linux embarque sa propre solution : LXC (OpenVZ et Vserver restent des patchs externes).
http://lxc.sourceforge.net/
[^] # Re: Explications
Posté par ulver . En réponse au message Testing et Unstable. Évalué à 1.
http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.(...)
http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.(...)
L'exemple du paquet cassé est peut être un peu tiré par les cheveux ceci dit :)
Mais ça fait quand même parti de la doc officielle, donc ça met le doute sur le choix entre testing et unstable...
En espérant que le projet CUT permette de régler ces choix cornéliens :)
[^] # Re: À qui profite le patch ?
Posté par ulver . En réponse au journal Noël, noël, un patch miraculeux !. Évalué à 2.
A votre avis, le patch sera profitable sur ce type d'utilisation ? (idem avec kvm j'imagine).
# Ma config
Posté par ulver . En réponse au message Problème avec du bridging over Ethernet bonding. Évalué à 2.
Voilà une config qui fonctionne correctement et que j'utilise souvent :
# Bond public + bridge pour les VM
auto bond0
iface bond0 inet manual
slaves eth0 eth2
bond_mode active-backup
bond_miimon 100
bond_downdelay 200
bond_updelay 200
auto br0
iface br0 inet manual
bridge_ports bond0
bridge_stp off
bridge_fd 0
# VPN
auto eth1
iface eth1 inet static
address 192.168.1.17
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
Mon fichier interfaces ne contient rien d'autre.
Le concept est grosso modo la même chose que toi :
J'ai mon hôte qui a 3 cartes réseaux :
- eth0 et eth2 sont en bonding, et le bond0 est bridgé. Ce sont en fait mes interfaces publiques, les VM (c'est de l'openvz mais l'idée est la même) s'attachent à ce bridge. Pas d'IP sur ce bridge par contre, car l'hôte n'est accessible que par VPN, il n'est pas accessible par le réseau public
- l'interface VPN est justement eth1, sur un réseau privée. Je ne bridge pas cette interface, pas besoin dans mon cas. Par contre, j'ai qqs hôtes où cette interface est bridgée pour que la VM sous jacente puisse accéder au VPN mais c'est très rare, et les options du bridge sont les même que plus haut.
Derrière, les cables sont pluggués sur des switchs avec du vlan pour séparer le vpn du public, enfin, du classique...
Voilà, j'espère que ça pourra t'aider :)
# ModSecurity ?
Posté par ulver . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 1.
Quelqu'un l'utilise en production ?
[1] http://www.modsecurity.org/
# Reconstruire les fichiers ib*
Posté par ulver . En réponse au message Changements de paramètres InnoDB explosent mes tables. Évalué à 3.
Quand tu modifies les paramètres innodb (notamment les paramètres innodb_log_file_size et innodb_data_file_path), il faut que le moteur innodb reconstruise les fichiers, sinon le mysql ne démarre pas (ou démarre mal, sans utiliser innodb). Enfin, normalement, y'a des erreurs un peu plus explicites dans les logs (mauvaise taille des iblogfile etc), mais j'imagine que ça doit être ça le problème.
Quand je fais une opération de la sorte, je prévois tout ça (pas en pleine journée par contre :p) :
- je dumpe mes bases
- je droppe les databases
- j'arrête le mysql
- j'efface les ib files : rm -f /var/lib/mysql/ib* # sur une debian
- je relance le mysql (là tu verras que le ibdata et les iblogfile vont se recréer, avec les nouvelles tailles que tu as donné dans le my.cnf, en l'occurence 2g pour les data, 256mo pour les ib logs)
- je réimporte les bases
Ca fait un peu beaucoup (certaines phases ne sont pas obligatoires, comme le drop des bases, mais j'ai eu des cas où j'ai dû tout faire, donc maintenant je suis prévenant), mais ça marche très bien :)