Categories
Technology

iptables et systemd

L’arrivée de systemd change un tas de choses dans nos habitudes. Il est évidemment nécessaire de comprendre un minimum son fonctionnement si on souhaite totalement abandonner Sysvinit. Une des premières choses sur laquelle j’ai du me pencher est la configuration du pare-feu (ainsi que des points de montage). Bref, ce billet va rapidement vous montrer comment configurer votre pare-feu au démarrage du système.

Tout d’abord, utilisez vous bien systemd en tant que système d’initialisation? Voici comment avoir la réponse.

$ ls -lh /sbin/init 
lrwxrwxrwx 1 root root 20 Apr 16 17:53 /sbin/init -> /lib/systemd/systemd

Pour la première étape, il convient de sauvegarder les règles actuelles du pare-feu (voici mon pare-feu).

# iptables-save > /etc/iptables.rules

La deuxième étape est la création d’un fichier de service systemd afin d’exécuter iptables au démarrage du système, avec les règles précédemment sauvegardées.

# cat /etc/systemd/system/iptables.service 
[Unit]
Description=Firewall
After=network.target
 
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c "/sbin/iptables-restore < /etc/iptables.rules"
 
[Install]
WantedBy=multi-user.target

Voici encore une des raisons pour laquelle j’aime bien systemd. Je trouve ce formalisme très clair.

Finalement, il est nécessaire d’activer le nouveau service.

# systemctl enable iptables.service
# systemctl restart iptables.service

Vous pouvez vérifier l’état du service de la manière suivante.

# systemctl list-unit-files | grep iptables 
iptables.service                           enabled
 
# systemctl status iptables.service
● iptables.service - Firewall
   Loaded: loaded (/etc/systemd/system/iptables.service; enabled)
   Active: active (exited) since Mon 2015-05-11 07:40:14 CEST; 11min ago
 Main PID: 3307 (code=exited, status=0/SUCCESS)

C’est terminé, votre pare-feu sera automatiquement configuré aux prochains démarrages du système.

Categories
Computer Technology

systemd

Voilà, comme un bon nombre de Linuxien(ne) j’utilise dorénavant systemd. Je n’ai pas vraiment un avis tranché sur ce système ni de critiques aussi virulentes qu’il est possible de trouver un peu partout sur le Web. Pour moi systemd, ça signifie d’abord que je vais devoir maîtriser une nouvelle technologie et un tas de nouvelles commandes. Ce qui m’enchante. Et puis, je trouve qu’il est parfois bien de mettre un peu de côté d’anciennes technologies. Et même si cela donne plus de travail aux administrateurs systèmes/réseaux (ceci pour ceux qui pensent encore que des binaires sont nécessaires pour configurer systemd).
Pour le moment, il faut surtout que j’identifie mieux les limites fonctionnelles de systemd. Car il faut bien le dire, systemd peut gérer un tas de choses: services, multi-seat, configuration réseau, pare-feu, etc.

systemd a amélioré le temps de démarrage de ma station fixe de travail sous Kubuntu 15.04 (environ 46 secondes, kernel et userspace) et de mon ordinateur portable sous Debian 8.0. Ce n’est cependant pas tant la vitesse qui m’intéresse, mais surtout le bon fonctionnement et les possibilités d’analyses des logs.

Concernant le fonctionnement, déjà mon démarrage est «plus propre» qu’avant. Tous les services se lancent correctement, l’affichage au démarrage n’est pas trop verbeux et est clair (homogène). Je n’ai en réalité rien de spécial à dire sur ce point (j’ai surtout gagné du temps lors du montage du NAS, qui avant me posait quelques problèmes de manière assez aléatoire).

Du côté des moyens d’analyse des logs, la commande systemd-analyze est bien pratique. Voici quelques exemples.

$ systemd-analyze dot --user --order | dot -Tsvg > systemd-dependency-graph-user.svg

Dependency graph (userspace)
Systemd dependency graph (userspace)

$ systemd-analyze dot --order | dot -Tsvg > systemd-dependency-graph-system.svg

Dependency graph (system)
Dependency graph (system)

$ systemd-analyze plot > system-services.svg

System services
System services

Le graphique ci-dessus est un peu plus parlant. Il existe aussi la commande systemd-analyze blame qui liste les services ordonnés par temps de démarrage. Ce qui peut aider à voir quel service ralenti le démarrage du système. Il faut cependant faire attention car blame ne montre pas les liens: parfois un service prend plus de temps parce qu’il attend le lancement d’un autre service.

$ systemd-analyze dot 'tor.*' | dot -Tsvg > tor.svg

Dépendances du service Tor
Dépendances du service Tor

systemctl list-units est une autre commande très pratique permettant de vérifier l’état des services après le démarrage.

Légende des graphiques:

  • black: Requires
  • dark blue: Requisite
  • dark grey: Wants
  • red: Conflicts
  • green: After
    • Finalement cette migration vers systemd est une réussite et je suis plutôt content, pour le moment. Il va tout de même falloir que je bidouille un peu plus pour me faire un avis plus précis.

Categories
Linux

Upstart et systemd

Une autre manière de voir les différences entre Upstart et systemd.

Categories
Technology

systemd, init et upstart

Si en ce moment tu es un peu perdu entre systemd, init et upstart (plus udev, D-Bus, DCOP, etc.), je pense que ce billet sera d’une bonne aide.

Pour avoir de bonnes informations à propos de systemd:

Categories
Linux

Support Multi-Seat dans Fedora

Très intéressant, il faudrait tester ça.

Oh, and BTW, as Ubuntu appears to be “focussing” on “clarity” in the “cloud” now ;-), and chose Upstart instead of systemd, this feature won’t be available in Ubuntu any time soon. That’s (one detail of) the price Ubuntu has to pay for choosing to maintain it’s own (largely legacy, such as ConsoleKit) plumbing stack.

Dans les dents, Shuttleworth.