Le Blog Utux

In Azure, the Application Gateway is basically a reverse proxy, passing traffic to some backends. While testing the SSL certificate of a listener with ssllabs, I have been surprised by the "HTTP server signature" field: Nexus/2.14.10-01. Indeed, the backend was a Nexus service, but I was expecting to see the server signature of the Application Gateway (which is Nginx), or nothing, but not the backend.

Turns out the HTTP response contains the following header:

< HTTP/1.1 200 OK
< Server: Nexus/2.14.10-01
[...]

Many sysadmins and organizations consider this as a security issue, giving attackers information about the server. While I do not totally agree with this statement (Obfuscation), I often disable this information. This is simple with Nginx and Apache, but what about Azure Application Gateway?

Application Gateway -> Your application gateway -> Rewrites -> + Rewrite set

• Name: give a name to your rewrite set. Ie: DisableServerTokens.
• Associated routing rules: Select the rule associated to your backend(s)

• Rewrite rule name: give a name to your rewrite rule name. Ie: DisableServerHeader.
• Action type: Delete
• Header type: Response
• Header name: Common header
• Common header: Server

Then Save your modifications. This should remove the "Server" HTTP header.

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.

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.

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.

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:

• Mnx.io: A Proper Server Naming Scheme
• Reddit: How do you decide on your server naming convention?

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.