Monter ses partages à la demande avec Autofs

Rédigé par uTux - - 2 commentaires

Je me connecte régulièrement avec mon laptop à des partages Samba/CIFS de mon NAS. Pour cela j'utilise la commande suivante à chaque démarrage:

$ sudo mount -t cifs //192.168.1.1/partage /mnt/partage/ -o user=utux

J'aimerai que ce soit automatique. Le problème est que je ne peux pas utiliser le /etc/fstab car au moment où il est exécuté le réseau n'est pas prêt (wifi ou client openvpn). Il existe bien l'option _netdev mais elle n'a jamais fonctionné pour moi. Ce cas d'usage montre bien les limites des montages Linux qui ne sont pas adaptés à la mobilité et aux environnements dynamiques.

Bonne nouvelle, il existe une alternative: autofs qui s'appuie sur automount. Contrairement à mount, il connecte le partage lorsqu'on y accède (et pas au démarrage) et le déconnecte si on ne l'utilise pas. Il a aussi de nombreuses autres fonctionnalités:

  • Un système de templates utile quand on a de nombreux partages.
  • Support de plusieurs protocoles (cifs, nfs, raw...).
  • Auto-découverte des partages.
  • Consommation de ressources moindre (déconnecte les partages non utilisés)
  • Meilleure tolérance aux coupures réseau.

Installation sous Debian / Ubuntu:

$ sudo apt install autofs

Créer/éditer le /etc/auto.master:

/mnt	/etc/auto.nas --timeout 300 --browse

Créer/éditer le /etc/auto.nas:

partage -fstype=cifs,credentials=/home/utux/.autofs_creds,user=utux,uid=utux,rsize=8192,wsize=8192 ://192.168.1.1/partage

Créer le fichier /home/utux/.autofs_creds:

username=utux
password=secret

Mettre le /home/utux/.autofs_creds en chmod 0600:

$ chmod 0600 /home/utux/.autofs_creds

Mettre le /etc/auto.nas en chmod 0644

$ sudo chmod 0644 /etc/auto.nas

Démarrer le service:

$ sudo systemctl start autofs

Tester:

$ ls /mnt/partage

Si cela ne fonctionne pas:

$ sudo systemctl stop autofs
$ sudo automount -f –v

Notez que cela ne fonctionnera pas si le /etc/auto.nas est exécutable:

$ sudo chmod -x /etc/auto.nas

Autofs est génial et solutionne mes problèmes de montage de partages en mobilité.

EDIT 15/03/2020: Smb version 4, ajout uid pour corriger des problèmes de droits.

Gitlab, bien mais gourmand

Rédigé par uTux - - 10 commentaires

J'adore gitlab, alternative libre à github installable chez soi ou utilisable en tant que service. Il a énormément de fonctionnalités: gestion du https avec letsencrypt, embarque sa BDD Postgresql, du CI avec des runnners, des issues, un registry Docker, et même de la métrologie... le tout avec une interface graphique intuitive et bien léchée.

Le problème de gitlab, c'est qu'il est monolithique et gourmand. Trop gourmand. J'ai installé une instance de gitlab-ce sur un serveur équipé de 2G de RAM, et au bout de quelques jours des erreurs 502 sont apparues. En me connectant sur le serveur j'ai constaté qu'il était quasi saturé: 1,7G ! Et en effet, après avoir consulté la page des requirements, j'a rapidement compris. Le minimum du minimum, c'est 4G de RAM + 4G de swap! Et la recommandation est de 8G!

Pour un usage perso, il est quand même ennuyeux de devoir louer un VPS à 8G de RAM, c'est pas donné, on tape dans la dizaine d'euros par mois voire plus. J'ai essayé quelques optimisations, comme diminuer le nombre de workers, le cache Postgresql, la métrologie... et après un redémarrage je suis à 1,5G de RAM.

Memoire Gitlab

Moui, ce n'est pas une franche réussite. Au moindre pic de consommation le serveur va ookill des processus. Gitlab est cool mais c'est un peu une usine à gaz en terme de ressources.

Même si je suis toujours fan de Gitlab et le recommande pour les entreprises et les organisations, je vais me mettre en recherche d'une alternative plus propice aux usages persos.

Comment nommer mes serveurs ?

Rédigé par uTux - - 3 commentaires

Vous avez tous eu dans votre entreprise un serveur nommé Orion car le nommage selon les constellations ou objets du système solaire est un grand classique. J'ai eu affaire à du Asterix et Obelix, Tom et Jerry, Arnold et Willy... et je trouve ça pénible. Beaucoup de gens choisissent un dictionnaire bien précis pour nommer leur serveur, il y en a d'ailleurs une liste ici, et pourtant je ne pense pas que ce soit une bonne pratique. Outre le fait que nous n'avons pas forcément le même humour que nos prédécesseurs, cela peut vite devenir l'enfer dans les situations d'urgence:

At 3am, when the world is burning down, having to figure out if "tatooine" is the DNS or the DHCP server is a problem you DON'T want or need.

Source.

Il est plus avisé de choisir un nom qui donne des informations utiles, comme la localisation et la fonction, ou encore le client quand il s'agit d’infogérance. Je n'ai pas encore trouvé la solution idéale, mais je trouve cet article intéressant: A Proper Server Naming Scheme. Le début me contredit puisqu'il recommande de donner des noms sans rapport avec la fonction et d'utiliser ensuite des CNAME records, mais je le trouve quand même assez complet. Ainsi pour un hypothétique serveur Web utux de développement hébergé à Amsterdam et faisant partie de l'organisation utux.fr on obtient ça:

  • web01.dev.ams.utux.fr

On a toutes les infos dont on a besoin en un simple coup d'oeil. L'inconvénient est que c'est un peu long pour un hostname ou un nom de machine virtuelle. Je ne gère que mes propres serveurs et je n'en ai pas une centaine, j'ai donc plutôt adopté ce format:

  • dev-ams-web01

Simple, efficace et lisible. Et vous?

Sources:

Ansible Jinja loop all groups except

Rédigé par uTux - - Aucun commentaire

I want to generate a /usr/local/etc/backuppc/hosts with all hosts from the ansible inventory, but exclude a group.

Inventory:

[dbservers]
db1
db2
db3

[DisableBackup]
db3

hosts.j2:

# {{ ansible_managed }}

{% for hosts in groups['all'] | difference(groups['DisableBackup']) %}
{{ hosts }}
{% endfor %}

tasks/generate_hosts.yml:

  - name: Generate hosts file
    template:
      src: hosts.j2
      dest: "{{ backuppc__confdir }}/hosts"
      owner: "{{ backuppc__user }}"
      group: "{{ backuppc__group }}"
      mode: 0644
      force: yes

Run:

ansible-playbook -i inventory install_backuppc.yml

Result:

cat /usr/local/etc/backuppc/hosts
# Ansible managed
db1
db2

Source.

On peut pas faire confiance à la documentation ubuntu

Rédigé par uTux - - 2 commentaires

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
Facepalm

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.

Fil RSS des articles de cette catégorie