Oh mon dieu, IMB achète Red Hat, ça sort vraiment de nulle part mais j'imagine que tout le monde est maintenant au courant.
Même si j'essaie de rationaliser la chose en me disant que cela ne devrait pas changer grand chose, du moins pas avant quelques années, j'ai tout de même envie de me mettre en PLS et de pleurer sous mon bureau. Red Hat c'est un symbole, c'est une boite qui a un rayonnement énorme sur Linux, tant en terme de contributions que de choix politiques. C'est aussi une des distributions les plus présentes en entreprise. Ça et tout l'écosystème qui va avec: KVM, libvirt, ovirt, Ansible, GlusterFS, Ceph, Openshift, Fedora, CentOS... et au final cette entreprise se fait racheter comme un vulgaire opérateur de téléphonie.
J'ai toujours eu du mal à comprendre pourquoi une entreprise qui fonctionne bien accepte de se faire racheter par un plus gros, ça me dépasse complètement et c'est quelque chose de très négatif à mes yeux, comme s'il n'y avait que l'argent qui comptait (on parle quand même de 34 milliard de dollars).
Je me dis maintenant que j'ai bien fait de m'orienter sur Debian, tant pour mes serveurs que mes stations de travail. Et j'espère qu'IBM ne se comportera pas comme Oracle en sabrant tout ce qui fait que Red Hat est une entreprise cool.
Essayons de désactiver AppArmor sur une Ubuntu 16.04 en nous basant sur la documentation.
C'est pourtant clair, 3 sources de documentations nous disent que pour désactiver AppArmor il suffit de stopper le service. Très bien, essayons:
root@ubuntu:~# systemctl stop apparmor
root@ubuntu:~# systemctl disable apparmor
apparmor.service is not a native service, redirecting to systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install disable apparmor
insserv: warning: current start runlevel(s) (empty) of script `apparmor' overrides LSB defaults (S).
insserv: warning: current stop runlevel(s) (S) of script `apparmor' overrides LSB defaults (empty).
Utilisons la commande apparmor_status pour voir le status de AppArmor:
root@ubuntu:~# apparmor_status
apparmor module is loaded.
13 profiles are loaded.
13 profiles are in enforce mode.
/sbin/dhclient
/usr/bin/lxc-start
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/lxd/lxd-bridge-proxy
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/sbin/tcpdump
lxc-container-default
lxc-container-default-cgns
lxc-container-default-with-mounting
lxc-container-default-with-nesting
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
/sbin/dhclient (848)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Diantre! C'est pas bon signe. Faisons un essai en installant mysql-server et en déplaçant son /var/lib/mysql ailleurs:
root@ubuntu:~# apt-get install mysql-server
root@ubuntu:~# systemctl stop mysql
root@ubuntu:~# mv /var/lib/mysql /opt/
root@ubuntu:~# sed -i "s@/var/lib/mysql@/opt/mysql@g" /etc/mysql/mysql.conf.d/mysqld.cnf
root@ubuntu:~# systemctl start mysql
Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.
Mysql ne démarre pas... examinons le log:
juil. 07 10:39:37 ubuntu kernel: audit: type=1400 audit(1530952777.364:32): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/opt/mysql/ibdata1" pid=2959 comm="mysqld" requested_mask="wr" denied_mask="w
juil. 07 10:39:37 ubuntu systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE
AppArmor n'est pas désactivé du tout, on ne peut pas faire confiance à la documentation Ubuntu!!! Il faut en fait rebooter le serveur, vraiment génial quand celui-ci est déjà en production ou quand on essaie d'automatiser une installation avec Ansible.
Après quelques recherches je suis tombé sur cet article qui nous indique qu'on peut utiliser la commande service apparmor teardown :
root@ubuntu:~# service apparmor teardown
* Unloading AppArmor profiles [ OK ]
root@ubuntu:~# apparmor_status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
root@ubuntu:~# systemctl start mysql
root@ubuntu:~# ps aux | grep mysql
mysql 925 0.0 13.2 1107628 134140 ? Ssl 10:43 0:00 /usr/sbin/mysqld
root 1224 0.0 0.0 14264 920 pts/0 S+ 10:46 0:00 grep --color=auto mysql
AppArmor nous laisse enfin tranquille, et sans rebooter le serveur :)
De manière amusant, teardown se traduit par démolir, raser. Est-ce une indication de l'état d'esprit de celui qui a codé le service de démarrage/arrêt d'AppArmor?
Je suis de moins en moins fan de Ubuntu sur les serveurs, car entre les très nombreuses mise à jour de Kernel (reboot fréquents) et les technologies maison de Canonical qui imite RedHat sans en avoir les moyens ou le talent, on se dit que rien ne vaut Debian ou CentOS sur un serveur.
C'est un coup dur :( Hardware.fr va cesser de publier des articles il ne restera donc que le forum et la boutique. J'étais fan des articles longs et détaillés comme les tests des CPU ou des cartes graphiques, le testeur avait même identifié un problème de latence entre les cœurs des RyZen... A chaque fois qu'un site fermait ou devenait payant, je me disais "pas grave il reste toujours hardware.fr".
RIP Hardware...
Une fusillade au siège de YouTube fait plusieurs blessés, vous n'avez sûrement pas échappé à cette information. En ce qui me concerne y'a rien à voir, c'est un fais divers, une(e) timbré(e) de plus qui pète un câble et tire dans la foule, y'a pas d'idéologie ou de coupable à chercher.
Sauf que cette personne était vegan et tout comme le féminisme, c'est un sujet qui fâche. Les commentaires ont été modérés mais quelques minutes après la publication il y en avait 9 pages, avec beaucoup de charge contre les vegan, présentés comme des extrémistes qui veulent imposer leurs idées aux autres.
Je suis vegan et je ne le crie pas sur les toits, en fait je l'ai mentionné en début d'année sans vraiment en faire la promotion. C'est un choix de vie et j'en ai rien à faire de ce que les autres mangent. Je ne fais pas de prosélytisme tout comme la majorité silencieuse. Donc à cette charge anti-vegan je réponds:
- Comme d'habitude vous ne retenez que les plus bruyants, vous ne comptez pas les autres qui ont fait un choix de vie et ne demandent rien d'autre qu'avoir la paix.
- Et merde, ça vous gêne tant que ça qu'il existe des vegan dans le monde? Quand une personne vous dit qu'elle ne mange pas de viande, ça insulte votre virilité? Pourquoi tant d'agressivité?
Il est affligeant de lire un tel niveau de bêtise dans les commentaires, une ambiance que je pensais réservée aux sites grands publics ou aux réseaux sociaux, mais qui débarque maintenant dans des cercles plus restreints. Car oui, NextINpact est fréquenté par des gens initiés qui d'habitude réfléchissent avant de poster sur internet. Facepalm.
Si c'est vraiment le fait d'être vegan qui amène les gens à tirer dans la foule, espérons que les platistes, les antivax et tous les complotistes de Youtube ne vont pas s'y mettre. Ou alors c'est juste une théorie ridicule...
On dirait le titre d'un WTC mais ce n'est pas le cas, c'est plutôt un bug à la con qui m'a bloqué toute une soirée.
Je fais tourner mon blog et d'autres sites chez Scaleway, sur un VC1S avec Docker (debian 9 + installation custom). Je fais au plus simple avec docker-compose qui jusque là était satisfaisant pour mes besoins. Mais depuis quelques temps je songe à passer à la vitesse supérieure avec swarm, qui me permettra d'ajouter d'autres nodes et former un vrai cluster.
Après avoir mené une phase de tests en VM, j'ai décidé de me lancer et migrer sous swarm. Mais je me suis confronté à un bug énervant, impossible de publier des ports, par exemple:
$ docker network create -d overlay net-web
t1q2kzso3a5fnlkd0s8tvywid
$ docker service create --network net-web --publish 80:80 nginx
xl35ov6bkehabkx4547omrodj
overall progress: 1 out of 1 tasks
1/1: running [==================================================>]
verify: Service converged
$ telnet 127.0.0.1 80
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Connexion refusée, le port n'est donc pas publié :/
Cela m'a rendu fou car en machine virtuelle VirtualBox ou KVM ça fonctionne du premier coup, et la lecture de documentation ou divers blogs ont confirmé qu'il n'y avait pas plus de manipulations à faire, ça devrait juste marcher !
J'ai commencé à soupçonner Scaleway, et en faisant une recherche avec les bons mots clés je suis tombé sur ce blog et cette issue github.
Ben voilà, c'est bien un problème avec Scaleway, car leur architecture est un peu particulière. Les serveurs ou VM n'ont pas de grub, ce sont des nodes provisionnées à la volée en PXE, avec script de démarrage et kernel maison. Et il s'avère qu'avec ces deux bootscripts, ça ne marche pas:
- x86_64 4.10.8 std #1
- x86_64 4.10.8 docker #1
C'est con, car le premier est celui proposé par defaut, le second est celui vers lequel on s'oriente naturellement quand on veut faire fonctionner du Docker.
Voici donc le bon bootscript: x86_64 mainline 4.14.23 rev1.
Proposer un kernel custom est une sale habitude des hébergeurs, mais à 3€/mois le vps, peut-on vraiment se plaindre de Scaleway?
Fil RSS des articles de cette catégorie