Auteur Sujet: systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !  (Lu 6898 fois)

0 Membres et 1 Invité sur ce sujet

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 528
  • La Madeleine (59)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #12 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 :)

kcdtv

  • Client FAI autre
  • *
  • Messages: 107
  • Internacionalunya 00
    • wifi-libre
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #13 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 @ 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

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


Nh3xus

  • Réseau Deux Sarres (57)
  • Client K-Net
  • *
  • Messages: 2 017
  • Sarrebourg (57)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #14 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.

SOSFR

  • Invité
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #15 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.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 528
  • La Madeleine (59)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #16 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 !".

SOSFR

  • Invité
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #17 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...

Free_me

  • Client Free adsl
  • *
  • Messages: 485
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #18 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 !

Nh3xus

  • Réseau Deux Sarres (57)
  • Client K-Net
  • *
  • Messages: 2 017
  • Sarrebourg (57)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #19 le: 06 juillet 2016 à 17:56:30 »

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 528
  • La Madeleine (59)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #20 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

kcdtv

  • Client FAI autre
  • *
  • Messages: 107
  • Internacionalunya 00
    • wifi-libre
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #21 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...


Nh3xus

  • Réseau Deux Sarres (57)
  • Client K-Net
  • *
  • Messages: 2 017
  • Sarrebourg (57)
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #22 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.

systemd 1 - SysVinit 0

corrector

  • Invité
systemd : l'init martyrisé, l'init bafoué, mais l'init libéré !
« Réponse #23 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.

 

Mobile View