La Fibre

Télécom => Logiciels et systèmes d'exploitation => Linux Linux => Discussion démarrée par: vivien le 05 juillet 2016 à 19:02:00

Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 05 juillet 2016 à 19:02:00
Par contre slackware c'est un peu le désert niveau dépôts et pas très réactif pour la correction des brèches de sécurité... Et tu as vraiment des fois des trucs bien louches, des paquets  qui n'ont pas été actualisés pendant des années... mais ils font un effort depuis quelques temps  je trouve... ils ont enlevé la frein à main et on passé la deuxième.
L'avantage c'est qu'il n'y a pas encore systemd , c'est vrais, tu as raison  :D
que ce que vous avez contre systemd ?

Je trouve qu'il apporte un vrai plus en terme de suivit de process et fonctionnalité.

Je précise au passage que il y a eu une mise à jour de systemd dans Ubuntu 16.04 et que la limite de 512 a sauté (après que j'ai eu le problème, suite à la migration rapide).

Bien vu, j'avais zappé les réponses et c'est une nouveauté introduite récemment dans systemd qui limite le nombre maximum de tâches qui peuvent être créés dans l'unité à 512 par défaut.
Pour Ubuntu, c'est introduit à partir d'Ubuntu 16.04

Le man :
TasksMax=N
Specify the maximum number of tasks that may be created in the unit. This ensures that the number of tasks accounted for the unit (see above) stays below a specific limit. If assigned the special value "infinity", no tasks limit is applied. This controls the "pids.max" control group attribute. For details about this control group attribute, see pids.txt[4].

Implies "TasksAccounting=true". The system default for this setting may be controlled with DefaultTasksMax= in systemd-system.conf.

Pour ne plus avoir cette limitation, il suffit d'éditer /etc/systemd/system.conf et de remplacer #DefaultTasksMax=512 par DefaultTasksMax=infinity

Ce que donne systemctl status apache2 avant la modification :


$ systemctl status apache2
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: active (running) since mer. 2016-05-18 06:22:18 CEST; 6h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 16760 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
  Process: 1148 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
    Tasks: 487 (limit: 512)
   CGroup: /system.slice/apache2.service
           ├─  481 /usr/sbin/apache2 -k start
           ├─  863 /usr/sbin/apache2 -k start
           ├─ 1221 /usr/sbin/apache2 -k start
           ├─ 1226 /usr/sbin/apache2 -k start
           ├─ 1373 /usr/sbin/apache2 -k start
           ├─ 1734 /usr/sbin/apache2 -k start
           ├─ 3180 /usr/sbin/apache2 -k start
           ├─ 6791 /usr/sbin/apache2 -k start
           ├─ 7611 /usr/sbin/apache2 -k start
           ├─10271 /usr/sbin/apache2 -k start
           ├─16813 /usr/sbin/apache2 -k start
           ├─16818 /usr/sbin/apache2 -k start
           ├─16920 /usr/sbin/apache2 -k start
           ├─17925 /usr/sbin/apache2 -k start
           ├─20430 /usr/sbin/apache2 -k start
           ├─22225 /usr/sbin/apache2 -k start
           ├─24790 /usr/sbin/apache2 -k start
           ├─31388 /usr/sbin/apache2 -k start
           └─31576 /usr/sbin/apache2 -k start

mai 18 06:22:15 ubuntu systemd[1]: Starting LSB: Apache2 web server...
mai 18 06:22:15 ubuntu apache2[1148]:  * Starting Apache httpd web server apache2
mai 18 06:22:18 ubuntu apache2[1148]:  *
mai 18 06:22:18 ubuntu systemd[1]: Started LSB: Apache2 web server.
mai 18 10:05:15 ubuntu systemd[1]: Reloading LSB: Apache2 web server.
mai 18 10:05:15 ubuntu apache2[16760]:  * Reloading Apache httpd web server apache2
mai 18 10:05:15 ubuntu apache2[16760]:  *
mai 18 10:05:15 ubuntu systemd[1]: Reloaded LSB: Apache2 web server.


Après la modification, (limit: 512) n’apparaît plus.
Titre: systemd
Posté par: Hugues le 05 juillet 2016 à 19:04:41
la stack réseau complètement pétéerevue, par exemple ?
Titre: systemd
Posté par: jack le 05 juillet 2016 à 19:08:32
systemd, c'est un truc pour dev qui se tripotent sur github.

"regarde, c'est mon projet ! c'est MON projet ! OWHHIIHUIHIUOQIDNZ"
D'où l'importance, dans l'idée, de ne pas corriger l'existant, mais plutôt de faire un autre projet,  from scratch (ou mieux : de fork un projet existant), mais sous ton nom, histoire de dire "regardez, je rosk, j'ai un projet qui est utilisé"

Faire nouveau plutôt que d'améliorer l'existant = mauvais
Le changement sans bénéfice = mauvais
systemd = mauvais
Avoir une interface réseau qui s'appelle enx78e7d1ea46da == très con et très très mauvais

(tu peux split le HS immédiatement :p)
Titre: systemd
Posté par: Hugues le 05 juillet 2016 à 19:12:39
resolvconf  ::)
le /etc/network/interfaces qui n'est écouté qu'a moitié...

dhcpcd.conf, très beau celui là aussi !
Titre: systemd
Posté par: vivien le 05 juillet 2016 à 19:40:29
Pour les cartes réseau,

Il y a eu trois époques :

Avant 2013 : 1ère époque : Celle de eth0, eth1, eth2, eth3 : les interfaces sont nommées dans l'ordre d'arrivée. Sympa quand on a une carte réseau mais beaucoup moins quand on 2 cartes réseau : Sur un serveur avec 2 carte réseau, la carte 1 peut être eth1 et la carte 2 eth0.
Sur des portables, il arrive que le wifi soit eth1.

Séquence d'initialisation d'un serveur avec 4 ports 1 Gb/s intégrés et 2 ports 10 Gb/s sur le slot 1 :
$ dmesg | grep eth
[    3.963167] bnx2 0000:0b:00.0 eth0: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found at mem 96000000, IRQ 28, node addr 34:40:b5:9f:d0:48
[    3.964371] bnx2 0000:0b:00.1 eth1: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found at mem 98000000, IRQ 40, node addr 34:40:b5:9f:d0:4a
[    3.965855] bnx2 0000:10:00.0 eth2: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found at mem 92000000, IRQ 29, node addr 34:40:b5:a5:5a:40
[    3.967251] bnx2 0000:10:00.1 eth3: Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express found at mem 94000000, IRQ 41, node addr 34:40:b5:a5:5a:42
[    8.544285] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    8.544291] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[    8.544296] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[    8.544300] IPv6: ADDRCONF(NETDEV_UP): eth3: link is not ready
[    8.544304] IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
[    8.544309] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready
[    9.133174] cdc_ether 5-2:1.0 usb0: register 'cdc_ether' at usb-0000:00:1d.0-2, CDC Ethernet Device, 36:40:b5:98:d0:4b
[    9.133198] usbcore: registered new interface driver cdc_ether
[    9.596080] ixgbe 0000:1a:00.0: registered PHC device on eth4
[    9.699234] IPv6: ADDRCONF(NETDEV_UP): eth4: link is not ready
[    9.763165] ixgbe 0000:1a:00.0 eth4: detected SFP+: 5
[   10.014999] ixgbe 0000:1a:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[   10.015853] IPv6: ADDRCONF(NETDEV_CHANGE): eth4: link becomes ready

2013/2014 : 2ème époque, celle de em1 / em2 qui est ma préférée : (depuis Ubuntu 13.04, uniquement sur le matériel qui sait identifier slot/port)
- em1 : première port Ethernet intégré à la carte mère
- em2 : second port Ethernet intégré à la carte mère
-  p1p1 : premier slot, premier port Ethernet
-  p1p2 : premier slot, second port Ethernet
-  p2p1 : second slot, premier port Ethernet
-  p2p2 : second slot, second port Ethernet
ect...
Le Wifi est lui avec une nomination séparée
On arrive a déterminer par le nom du port, l'emplacement sur le serveur avec certitude.

Séquence d'initialisation d'un serveur avec 2 ports 1 Gb/s intégrés et 2 ports 10 Gb/s sur le slot 1 :
$ dmesg | grep eth
[    2.991442] bnx2 0000:02:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d4:ae:52:ce:9a:9c
[    2.994398] bnx2 0000:02:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d4:ae:52:ce:9a:9d
[    3.077138] bnx2 0000:02:00.0 em1: renamed from eth0
[    3.338749] bnx2 0000:02:00.1 em2: renamed from eth1
[    4.759659] ixgbe 0000:01:00.1 p1p2: renamed from eth1
[    4.778882] ixgbe 0000:01:00.0 p1p1: renamed from eth0

Depuis 2015, l'époque Systemd : La nouvelle est je trouve incompréhensible. (depuis ubuntu 15.10)

- eno1: première port Ethernet intégré à la carte mère
- eno2: second port Ethernet intégré à la carte mère
- enp1s0 : premier slot, premier port Ethernet
- enp2s0 : second slot, premier port Ethernet
- wlp2s0 pour le wifi sur mon portable (!)
- wlp3s0 pour le wifi sur mon PC fixe (!)

Séquence d'initialisation d'un serveur avec 2 ports 1 Gb/s intégrés et un port 10 Gb/s sur le slot 1 :
$ dmesg | grep eth
[    2.919121] bnx2 0000:02:00.0 eth0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c0000000, IRQ 16, node addr d0:67:e5:e9:ba:b4
[    2.921879] bnx2 0000:02:00.1 eth1: Broadcom NetXtreme II BCM5716 1000Base-T (C0) PCI Express found at mem c2000000, IRQ 17, node addr d0:67:e5:e9:ba:b5
[    3.019509] bnx2 0000:02:00.0 eno1: renamed from eth0
[    3.238308] bnx2 0000:02:00.1 eno2: renamed from eth1
[    3.930651] ixgbe 0000:01:00.0 enp1s0: renamed from eth0
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 05 juillet 2016 à 20:44:14
Le truc de l'ordre des interfaces, j'imagine que c'est un besoin réel, quand bien même je n'ai jamais constaté de "soucis", avec plein de configurations matériels différentes

Mais le plus important .. quel est l'intérêt de renommer wlan0 en wlp2s0 ?
Et eth0 en em1, et donc de ce que tu dit, maintenant en eno1 ?

À quoi ça sert, franchement ?
En tant que sysadmin, je n'en ai rien à foutre de différencier les interfaces Gb "intégré à la carte mère" et les cartes Gb "sur un port PCI" ou autre
Ce qui m'importe, c'est de savoir que telle interface est branchée sur tel machin, c'est à dire que je peux faire tel truc avec (ex LACP, configuration des vlan ou sque tu veux)

Non ?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 05 juillet 2016 à 20:44:50
Ce qui me fait chier avec systemd :

- Le renommage abscons des noms d'interface réseau

- Les requêtes DNS qui vont interroger Google si les DNS sont mal configurés dans le resolv.conf (dafuq ?)

- ce machin s'occupe de faire du firewalling (?!) avec systemd-firewalld

- les sessions tux / screen qui sont, par défaut, tuées automatiquement lorsque l'on se déconnecte de son compte utilisateur : il faut activer le mode "linger" de systemd pour empêcher ça...
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: BadMax le 05 juillet 2016 à 21:13:51
Le renommage des interfaces c'est le taf de udev. Pas besoin de systemd.

C'est même présent sur Slackware, c'est dire.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 05 juillet 2016 à 21:15:12
(c'est le même projet, tristement)
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 05 juillet 2016 à 21:19:22
Citer
C'est même présent sur Slackware, c'est dire.

C'était vrai jusqu'à la 14.1.

Aujourd'hui sur une 14.2  fraichement installée, udev est remplacé par eudev.

Du coup, un ifconfig -a me retourne bel et bien les traditionnels ethX et wlanX
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 05 juillet 2016 à 21:39:19
Mais le plus important .. quel est l'intérêt de renommer wlan0 en wlp2s0 ?
Et eth0 en em1, et donc de ce que tu dit, maintenant en eno1 ?
Oui, sur un serveur, eth0 est devenu em1 puis eno1.
C'est assez logique et utile sur un serveur.

Par contre sur un PC grand public, Linux ne sais pas si la carte est intégrée à la carte mère et chez moi cela donne enp2s0 pour le port Ethernet intégré à la carte mère.

Le "2" viens du fait que lspci indique que c'est le 2ème slot PCI (pour la carte intégrée à la CM) :
$ lspci | grep Eth
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

Pour le WiFi, j'ai wlp3s0 car là aussi lspci dit que c'est le 3ème slot PCI (carte Wifi intégré à mon PC fixe) :
$ lspci | grep Wireless
03:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)

Pour le wifi de mon portable, wlp2s0, lepci indique que c'est le 2ème slot PCI :
$ lspci | grep Wireless
02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

Avant (2ème époque avec em1), seul les carte mères capable d'indiquer précisèment où est la carte étaient renommés : les pc grand public restaient en eth0.

Je ne comprends pas non plus l’intérêt de renommer les interface sur un pc grand public.

Attention : les interfaces ne sont jamais renommées lors d'une mise à jour. Il faut faire une clean install pour voir les nouvelles modes.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Hugues le 05 juillet 2016 à 22:51:47
Attention : les interfaces ne sont jamais renommées lors d'une mise à jour. Il faut faire une clean install pour voir les nouvelles modes.
LOL, on en parle de mon serveur qui est passé au nouveau nommage d'un coup sans aucune raison ? (ça m'a pris quelques temps de débug à la con...)
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 05 juillet 2016 à 22:58:09
Oui, sur un serveur, eth0 est devenu em1 puis eno1.
C'est assez logique et utile sur un serveur.

Si t'as des cas d'utilisations, j'veux bien :)
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: kcdtv le 06 juillet 2016 à 03:45:59
 Vivien, le "renommage" des interfaces réseaux que tu évoque est justement un bel exemple du degré d'absurde auquel ont peut arriver en suivants les cheminements des synapses détraquées des développeurs de Fedora qui ont lancé systemd.
  C'est peut être bien vu pour les interfaces réseaux ethernet (quoique je crois que ce n'étais vraiment pas nécessaire et que le système ethX suffisait)
quoique...
Citer
Par contre sur un PC grand public, Linux ne sais pas si la carte est intégrée à la carte mère et chez moi cela donne enp2s0 pour le port Ethernet intégré à la carte mère.
...Une belle avancé pour l'utilisateur lambda qui n'a pas de serveur et une carte intégrée. qui s'appelait eth0...    :D
  Par contre pour les interfaces wifi USB (wlan) depuis la version 197 c'est la règle  73-special-net-names.rules qui s'applique si on ne l’annote pas (ou ceux qui maintiennent votre disto :
# Use MAC based names for network interfaces which are directly or indirectly
# on USB and have an universally administered (stable) MAC address (second bit
# is 0).
ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", ATTR{address}=="?[014589cd]:*", #IMPORT{builtin}="net_id", NAME="$env{ID_NET_NAME_MAC}"

Pour une interface USB on applique la règle 4
    Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
    Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
    Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
    Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
    Classic, unpredictable kernel-native ethX naming (example: eth0)
Predictable Network interface Names (https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) @ freedesktop.org
Le nom de l'interface se base sur la mac...
Ils auraient pu faire wlanuX ou uwlanX si ils pensaient que c'étaient si important que ça de distinguer les wlan PCI et PCI-E des wlan USB.
Ce qui, au passage, n'est vraiment pas nécessaire: Sachant  que la wlan0 est toujours la première carte détecté et c'est donc toujours la carte interne
wlan0 = interne   wlan1 = USB wifi. .. dur dur.  ::)

Donc maintenant c'est a priori...
 wlxXXXXXXXXXXXXXX dont les X sont les symboles hexadécimaux du bSSID
(https://www.wifi-libre.com/img/members/3/Interfaces_locas_2.jpg)
Super!    ;D
Si je veux éteindre mon interface USB wifi en ligne de commande je n'ai plus qu'à écrire
sudo ifconfig wlx00c0ca849eac downau lieu de
sudo ifconfig wlan1 downC'est quand mème cents fois mieux  ;D

Et halte au systemcl plizzzz
moi pas comprendre l'intérêt de tout renommer "systemcl qqchose..."
reboot = systemcl reboot
poweroff = systemcl poweroff
Why?  :D

Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 06 juillet 2016 à 10:30:38
Citer
reboot = systemctl reboot
poweroff = systemctl poweroff

Ouais, ça aussi c'est débile.

Mais depuis, des liens symboliques ont été créer pour permettre aux vieux cons utilisateurs aguerris d'utiliser les anciennes commandes.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: SOSFR le 06 juillet 2016 à 17:08:09
Les noms reseau je trouve ca pas mal, ca garantit que peu importe la distro (du moment qu'elle utilise udev) sur une meme machine la meme carte reseau aura toujours le meme nom, apres pour ceux qui aiment vraiment pas on peut soit le desactiver (en symlinkant le 73-setup-net-rules) soit definir un nom personnalise en creant un /etc/systemd/network/macarte.link et en definissant le nom perso + l'adresse MAC de la carte concernee.

Sinon, a part les conneries "philosophiques" genre "systemd c'est le mal", vous pouvez donner des exemples concrets la ou systemd vous a fait perdre plus de temps que l'equivalent avec un systeme d'init traditionnelprehistorique? Perso c'est l'inverse, et tout outil qui me permet de passer moins de temps derriere le terminal est bon a prendre selon moi.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 06 juillet 2016 à 17:20:46
T'en as deux pages.
Changement = contrainte, changement sans bénéfices = contraintes sans bénéfices = non merci.

C'est vrai que, tu as raison, j'vais changer tout mes systèmes pour avoir le même nom sur les 150 distributions que je n'utilise pas, et qui avait déjà le même nom avant.

Ben oui, eth0, wlan0, c'est les noms du noyau Linux.
Dingue.

Tu fait un bon défenseur de systemd : aucune connaissance de ce dont tu parles :)
Ce n'est pas grave, c'est l'occasion d'apprendre : va lire drivers/net/*, c'est très intéressant et ça t'évitera de dire "regarder, c'est génial, avec systemd, ça existe enfin !".
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: SOSFR le 06 juillet 2016 à 17:39:53
En meme temps si pour toi systemd se resume a un renommeur de cartes reseau je peux comprendre que ca te semble de la merde inutile.

Mais niveau gestion de services, t'as quoi contre lui? Eviter d'avoir a ecrire un script init.d avec plus de boilerplate que de code utile, je vois pas comment tu peux considerer ca un inconvenient...
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Free_me le 06 juillet 2016 à 17:44:25
systemd c'est la vie.

depuis que je m'y suis mis ma vie a changé. Je dors mieux, je suis plus fort, j'ai plus de succès auprès des femmes, je n'ai plus besoin de lunettes, et je gagne plus d'argent !
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 06 juillet 2016 à 17:56:30
(http://i.imgur.com/QAKFpPF.gif)
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 06 juillet 2016 à 18:23:14
Mais niveau gestion de services, t'as quoi contre lui? Eviter d'avoir a ecrire un script init.d avec plus de boilerplate que de code utile, je vois pas comment tu peux considerer ca un inconvenient...
Alors, parlons-en.

La version sysvinit que j'ai sur mon système, lvm-lvmetad (21 lignes):
#!/bin/sh
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides:          lvm2-lvmetad
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: LVM2 metadata daemon
### END INIT INFO

DESC="LVM2 metadata daemon"
DAEMON=/sbin/lvmetad
PIDFILE=/run/lvmetad.pid

do_start_prepare() {
  mkdir -m 0700 -p /run/lvm
}

Et le fichier "service" de systemd que j'ai aussi (18 lignes):
[Unit]
Description=LVM2 metadata daemon
Documentation=man:lvmetad(8)
Requires=lvm2-lvmetad.socket
After=lvm2-lvmetad.socket
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=simple
NonBlocking=true
ExecStart=/sbin/lvmetad -f
Environment=SD_ACTIVATION=1
Restart=on-abort
PIDFile=/run/lvmetad.pid

[Install]
WantedBy=sysinit.target

boilerplate, you said ? hum hum
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: kcdtv le 06 juillet 2016 à 18:54:05
Citer
Sinon, a part les conneries "philosophiques" genre "systemd c'est le mal", vous pouvez donner des exemples concrets la ou systemd vous a fait perdre plus de temps que l'equivalent avec un systeme d'init traditionnelprehistorique? Perso c'est l'inverse, et tout outil qui me permet de passer moins de temps derriere le terminal est bon a prendre selon moi.
  Je ne sais pas à quels messages tu fais référence exactement mais je ne crois pas que personne (pas moi en tout cas) est déclaré que  "c'était le mal".
Je ne suis pas contre le changement et je ne vois pas tout en blanc ou noir.
Il y a des choses réussies et il y en à d'autres qui le sont moins.
  En quoi systemd te fait passer moins de temps dernière le terminal?  ???
  Je n'ai rien contre le fait de ne pas utiliser le terminal par contre il y a des choses qui se font dix fois plus vites et c'est bien là l’intérêt d'avoir un interprète d'ordre avec  la puissance de bash....
 Pour en revenir au wifi, avec le passage à systemd on a galéré pendant un an avec des bugs de partout et des conflits entre les commandes de base - netwrok manager - systemd
  Et toutes les GUI du monde "pour ne pas utiliser le terminal" utilisent des ordres de terminal.
  Il y a des centaines de scripts et GUI qu'il faut retoucher par exemple parce qu'elles n’acceptent que des interfaces wifi de type wlanX....  pas de wlxXXXXXXXXXXXXX (j'ai bien mis douze caractères?  ::) )
Citer
Les noms reseau je trouve ca pas mal, ca garantit que peu importe la distro (du moment qu'elle utilise udev) sur une meme machine la meme carte reseau aura toujours le meme nom.
   C'était déjà quelque chose d'aquis.... wlan0 carte interne... wlan1 carte USB . j'ai trois SO installés, pas de soucis, wlan0 interne, wlan1 USB... 
   Pourquoi veux tu absolument utiliser un identifiant unique au lieu d’identifiants génériques logiques?
   Il ne s'agit pas là de révolution technologique mais d'un choix.
   Moi je ne dis pas non au débat par contre la manière dont ces changements sont arrivés..  Ça a manqué de transparence, c'est passé au forceps...., Au bout du compte on a un team de membres de fedora - Red hat qui ont réinventé la roue  et forcèment il y a des ratés...
  Avec une vision  que l'on ne partage pas forcèment (red hat c'est une entreprise, pas une communauté et leur cri de raliement c'est : Heil GNOME!  :D )
  Leur approche me semble équivoque.
Explique moi l'avantage par example d'être connecté avec l'interface wifi au réseau que tu as gardé en mémoire au moment du boot.... avec une interface qui utilise un identifiant unique... En termes de sécurité c'est une très mauvaise idée.
  Et je ne vois pas l’intérêt je préfère être connecté en ouvrant ma session avec mon utilisateur "normal"
je crois que cette  citation de linus trovalds résume bien les choses :
Citer
Linus Torvalds said:
    "I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
Ils ont voulu refaire le monde en nous prenant un peu comme des cobayes...
Maintenant dans les faits... C'est fait.
 Personne n'est mort, personne ne crie au diable, on se dmerde avec systemd
  Mais je crois que le bilan est plutôt médiocre si on voit les avantages obtenues et le temps perdu et les efforts faits par tous (des développeurs aux utilisateurs lambda)  pour prendre le train en marche (forcée)
  Ça c'est fait sans coordination avec les développeurs de linux. ce que je crois nous devrions déplorer...

Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 06 juillet 2016 à 18:54:43
On me dit dans l’oreillette que les fichiers XML c'est mieux que les scripts Bash rafistolés à la glue. (http://forum-images.hardware.fr/images/perso/2/s@ms.gif)

systemd 1 - SysVinit 0 (http://forum-images.hardware.fr/images/perso/2/s@ms.gif)
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 07 juillet 2016 à 05:50:56
Par contre sur un PC grand public, Linux ne sait pas si la carte est intégrée à la carte mère et chez moi cela donne enp2s0 pour le port Ethernet intégré à la carte mère.
L'utilisateur non plus (sauf peut être 0,1 %) et c'est très bien comme ça. Ce genre d'information n'a pas beaucoup d'utilité et je ne vois pas pourquoi on se remplirait la tête de choses sans intérêt.

Je ne comprends pas non plus l’intérêt de renommer les interface sur un pc grand public.
Le nommage des interfaces réseau est un des nombreux domaines merdiques de linux, rendu encore plus merdique par cette réforme du nommage.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 07 juillet 2016 à 08:51:54
Pour ceux qui ont déjà utilisé windows, avec plus de 2 cartes réseaux doivent aussi pester contre windows avec sa "Connexion au réseau local 1"  "Connexion au réseau local 2"  "Connexion au réseau local 3"  "Connexion au réseau local 4".

La première action est donc de renommer les cartes, pour savoir qui correspond à qui.

La gestion des VLAN peut être bien complexe, en fonction du fournisseur, vu que la gestion des VLAN est dans le driver n'est pas au même endroit selon les marques et que les drivers par défaut de Windows ne gèrent pas les VLAN, il faut aller sur le site du constructeur télécharger un pilote qui gère les VLAN.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 07 juillet 2016 à 11:31:16
Euh, ça suffit pas de faire des switchport mode access côté switch ?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 07 juillet 2016 à 11:54:34
Avant 2013 : 1ère époque : [/size]Celle de eth0, eth1, eth2, eth3 : les interfaces sont nommées dans l'ordre d'arrivée. Sympa quand on a une carte réseau mais beaucoup moins quand on 2 cartes réseau : Sur un serveur avec 2 carte réseau, la carte 1 peut être eth1 et la carte 2 eth0.
Sur des portables, il arrive que le wifi soit eth1.
Sur un PC avec mise en veille profonde l'ordre de lancement des drivers peut être non déterministe et ce ne sera pas toujours le même driver qui sera prem's pour enregistrer le nom "eth".

C'est quand même très chiant. De toute façon il faut donner aux périphériques des petits noms!
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: BadMax le 07 juillet 2016 à 12:33:45
Euh, ça suffit pas de faire des switchport mode access côté switch ?

Non là tu n'autorises qu'un seul vlan non taggué.
Titre: systemd
Posté par: raf le 24 juillet 2016 à 17:40:23
Faire nouveau plutôt que d'améliorer l'existant = mauvais
Le changement sans bénéfice = mauvais
systemd = mauvais
Avoir une interface réseau qui s'appelle enx78e7d1ea46da == très con et très très mauvais
journald, networkd = tres mauvais, je dirais meme "absolute evil".
systemd-boot, logind, consoled, timedated = mauvais concept.
un "init system" qui remplace peu a peu tous les composants systeme standard = "absolute evil".
Pour finir, ne pas oublier des 2 plus grands problemes de systemd : Lennart et Kai, qui se prennent pour des dieux.

En regle generale, les auteurs semblent ne pas avoir en tete rien d'autre qu'une utilisation "desktop". Je trouve l'utilisation du systemd cote serveur inutile, voire contre-productive.
Le fait de remplacer des composants portables par des inventions "systemd-only" mais surtout "linux-only" c'est quelque-chose qu'il fallait jamais commencer. Et meme une fois commence c'est une pratique que leur employeur (RedHat) devrait pas entretenir.
Titre: systemdon't
Posté par: raf le 24 juillet 2016 à 17:43:40
Autant dire, pour mois ce n'est pas "systemd" c'est systemdon't.
Cote desktop je suis reste pour l'instant coince a Ubuntu 14.04 LTS (dernier LTS sans l'abomination).
Cote serveur je bataille un peu pour passes a un jessie "classic" (sysvinit).
Je garde aussi en tete la possibilite de revenir a Slackware, une des seules distributions majeures a ne pas etre pressee a migrer.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 25 juillet 2016 à 14:27:41
Citer
Je garde aussi en tete la possibilite de revenir a Slackware, une des seules distributions majeures a ne pas etre pressee a migrer.

Yep.

Slackware 14.2 comporte : SysVinit + eudev + ConsoleKit2 pour éviter les Lennarderies à la con.

Pour le son, on a tout de même le droit à PulseAudio par défaut maintenant.

Surprenant, mais je ne dis pas non à la gestion du son séparée par applications  :D

Du coup, ya quand même un peu de Red Hat dans la distro, en comptant également gnome-keyring et NM.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: kcdtv le 25 juillet 2016 à 15:48:30
Tu peux mettre wicd (https://slackbuilds.org/mirror/slackware/slackware-14.1/extra/wicd/) (dépôts "extra") au lieu de Network Manager pur déredathiser ton système (je n'ai pas dis dératiser  :P )
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 05 août 2016 à 10:47:27
Vu que c'est la journée, vla mon dernier script init :
#!/lib/init/init-d-script
DAEMON=/root/raven/raven.py

Décidement, il faut absolument que je passe à systemd : sysvinit est vraiment trop verbeux, avec trop de code redondant.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: kcdtv le 05 août 2016 à 18:02:56
Trop c'est trop!  :D

Un peu de lecture ( objective  :D ) : Systemd is the best example of Suck. (http://suckless.org/sucks/systemd) @ suckless.org 
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 05 août 2016 à 20:38:04
Bon en fait c'est juste un mélange de GNU, de linux, des scripts Redhat intégrés dans un processus?

Où est le problème? Il n'y a même pas d'équivalent de X Windows dans ce truc, donc c'est encore assez simple(iste).
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 05 août 2016 à 20:45:49
Pour un peu simplifier le "débat", je poste donc ceci :

(https://media.giphy.com/media/5xtDarAgrjoOrBxSVYk/giphy.gif)

Un classique, qui permet de se faire une idée de ce que fait systemd  ;D
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 05 août 2016 à 21:29:20
Bon on va essayer de faire simple, clair et précis :

Qu'est-ce ça ne fait pas?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: eruditus le 05 août 2016 à 21:35:24
Le café ?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 05 août 2016 à 21:55:38
S'il y a un serveur juste pour donner le hostname, pourquoi pas un serveur pour faire chauffer l'eau, un pour faire couler l'eau, un pour contrôler le débit, et un pour contrôler le maintient au chaud du café?

(dans l'hypothèse la simpliste évidemment)
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: eruditus le 05 août 2016 à 21:56:57
Et un avec une camera pour surveiller si il reste du café ?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 06 août 2016 à 19:53:34
Vous rigolez, mais les machines a café modernes Selecta sont sous Linux.

Les nouvelles imprimantes laser couleur Samsung ont une tablette 10 pouces en guise de panneau de commande et je vous le donne dans le mille, c'est sous Android et il est possible d'installer des applications sur l'imprimante.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 06 août 2016 à 20:07:15
Avec systemd?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: ctressens le 06 août 2016 à 20:07:50
Vous rigolez, mais les machines a café modernes Selecta sont sous Linux.

Les nouvelles imprimantes laser couleur Samsung ont une tablette 10 pouces en guise de panneau de commande et je vous le donne dans le mille, c'est sous Android et il est possible d'installer des applications sur l'imprimante.

Au moins c'est pas du Windows Embedded ...
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: corrector le 06 août 2016 à 20:18:14
Contrairement aux distributeurs de billets sous XP...
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: Nh3xus le 06 août 2016 à 20:56:22
Au moins c'est pas du Windows Embedded ...

J'ai déjà croisé des oscilloscopes sous XP Embedded  :o
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: alegui le 08 août 2016 à 04:26:34
J'ai déjà croisé des oscilloscopes sous XP Embedded  :o
Disons que c'est toujours moins affreux que du XP standard  :-[

PS : Pour le café, il y a déjà une RFC pour contrôler une cafetière à distance...
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: perror le 08 août 2016 à 17:13:13
Je dirais même plus, c'est tout un protocole (qui prend en compte les théières AUSSI): https://tools.ietf.org/html/rfc7168
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: kcdtv le 11 août 2016 à 01:48:45
C'est marrant tous ces smarts objets à la con super indispensables avec du wifi de troisième zone et des configurations à se taper la tronche contre les murs.
Hack de réseau WiFi correctement configuré et sécurisé en attaquant un kettle
https://www.youtube.com/watch?v=GDy9Nvcw4O4#t=30 (https://www.youtube.com/watch?v=GDy9Nvcw4O4#t=30)
Pour ceux qui n'ont pas envie de voir le vidéo :
  1 = On utilise une interface wifi pour créer un Rogue AP (sans chiffrement - en OPEN) en utilisant l'eSSID du réseau domestique cible .
  2 = Avec une autre interface ont injecte des ACK entre le point d'accès légitime et le kettle (paquets de dés-autentification)
  1+2 =  Le kettle se déconnecte du routeur légitime et se connecte à note interface réseau
  3 =  Une fois que le kettle est connecté sur notre réseau on va lui faire une petite visite en passant par telnet
  4 =  Mot de passe par défaut 123456 sinon c'est brute force sur 6 caractères sans caractères spéciaux... in the pocket
  5 = Ensuite la clé WiFi du réseau est accessible car -  Youpi! - Elle est gardée en texte clair.
Avec ou sans sucre?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 22 novembre 2017 à 09:13:49
Je besoin, sur certains serveurs que les mises à jour de sécurité se réalisent à une heure précise (entre 5h55 et 5h56).

J'ai donc édite /etc/cron.daily/apt-compat pour réduire le temps d’attente aléatoire (passer de 0 à 1800 secondes => 0 à 60 secondes).

Pour l'heure de lancement, j'ai directement édité  /etc/crontab : le lancement des scripts de cron.daily a été avancé de 6H25 à 5h55 :
# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
55 5    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

J'ai bien les différents scripts quotidiens qui s'exécutent maintenant a 5h55 (rotation de log par exemple)

Par contre les mises à jour de sécurité sont toujours à l'ancienne heure, selon /var/log/unattended-upgrades/unattended-upgrades.log

En regardant le début du script /etc/cron.daily/apt-compat qui lance les mises à jour, j'ai trouvé une information intéressante :
#!/bin/sh

set -e

# Systemd systems use a systemd timer unit which is preferable to
# run. We want to randomize the apt update and unattended-upgrade
# runs as much as possible to avoid hitting the mirrors all at the
# same time. The systemd time is better at this than the fixed
# cron.daily time
if [ -d /run/systemd/system ]; then
    exit 0
fi

Bref, je pense qu'il y a un lancement crontab de /etc/cron.daily/apt-compat mais qu'il sort tout de suite car j'ai systemd.

D'où ma question : où contrôler la crontab de Systemd ?
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: zoc le 22 novembre 2017 à 10:32:54
Ca ne serait pas par hasard dans /lib/systemd/system/apt-daily.timer ?

Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 22 novembre 2017 à 19:25:22
Tout a fait !

Si j'ai bien compris, il y a 6 fichiers importants pour les mises à jour automatiques sous Ubuntu et probablement Debian :

- apt-daily.timer  / apt-daily.service : lance toutes les 12 heures, après un temps d'attente aléatoire variant de 0 à 12h la vérifications de présence de mises à jour. Dans le passé, c'était une fois par jour, la nuit a 6h25 après un temps d'attente variant de 0 à 30 minutes. Par contre, il ne va pas vérifier deux fois dans la même journée les paquets.

- apt-daily-upgrade.timer / apt-daily-upgrade.service : Lance l'upgrade proposent dit et le reboot si c'est configuré comme ça. Le llancement se fait a 6h00 + une attente aléatoire variant de 0 à 60 minutes.

- /etc/apt/apt.conf.d/10periodic : Autorise la mise à jour des paquets permettant de voir si une mise à jour est disponible, le téléchargement de la mise à jour proprement dite et l'installation.

- /etc/apt/apt.conf.d/50unattended-upgrades : Indique si cela ne concerne que les mises à jour de sécurité ou toutes les mises à jour disponibles. C'est aussi là qu'on précise les options pour supprimer les anciens noyaux et si on souhaite un reboot après la mise à jour.

/lib/systemd/system/apt-daily.timer :
[Unit]
Description=Daily apt download activities

[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/apt-daily.service :
[Unit]
Description=Daily apt download activities
Documentation=man:apt(8)
ConditionACPower=true
After=network.target network-online.target systemd-networkd.service NetworkMana$

[Service]
Type=oneshot
ExecStartPre=-/usr/lib/apt/apt-helper wait-online
ExecStart=/usr/lib/apt/apt.systemd.daily update

/lib/systemd/system/apt-daily-upgrade.timer :
[Unit]
Description=Daily apt upgrade and clean activities
After=apt-daily.timer

[Timer]
OnCalendar=*-*-* 6:00
RandomizedDelaySec=60m
Persistent=true

[Install]
WantedBy=timers.target

/lib/systemd/system/apt-daily-upgrade.service :
[Unit]
Description=Daily apt upgrade and clean activities
Documentation=man:apt(8)
ConditionACPower=true
After=apt-daily.service

[Service]
Type=oneshot
ExecStart=/usr/lib/apt/apt.systemd.daily install
KillMode=process
TimeoutStopSec=900

/etc/apt/apt.conf.d/10periodic :
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "0";

/etc/apt/apt.conf.d/50unattended-upgrades :
// Automatically upgrade packages from these (origin:archive) pairs
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for
// every release and this system may not have it installed, but if
// available, the policy for updates is such that unattended-upgrades
// should also install from here by default.
"${distro_id}ESM:${distro_codename}";
// "${distro_id}:${distro_codename}-updates";
// "${distro_id}:${distro_codename}-proposed";
// "${distro_id}:${distro_codename}-backports";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};

// This option will controls whether the development release of Ubuntu will be
// upgraded automatically.
Unattended-Upgrade::DevRelease "false";

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "false";

// Install all unattended-upgrades when the machine is shutting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
//Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

// Enable logging to syslog. Default is False
// Unattended-Upgrade::SyslogEnable "false";

// Specify syslog facility. Default is daemon
// Unattended-Upgrade::SyslogFacility "daemon";
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: vivien le 28 novembre 2017 à 10:34:21
Cela fonctionne.

Ne pas oublier un sudo systemctl daemon-reload après avoir modifier un fichier, sinon ce n'est pas pris en compte.
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: lordzurp le 28 novembre 2017 à 11:04:02
arretez de vous faire du mal, passez sous UNIX :troll:
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: jack le 28 novembre 2017 à 21:13:49
Hum
Titre: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
Posté par: seb le 29 novembre 2017 à 08:53:29
Si j'ai bien compris, pour surcharger la configuration d'un élèment systemd, il faut recopier le fichier /lib/systemd/system/quelque.chose sous /etc/systemd/system/, et faire ses modifs dedans.
Sinon, elles sauteront à la prochaine mise à jour du paquet qui embarque le fichier.