deb.sury.org... miroir ou sauvegarde ?
Me suis fait avoir... tous les packages bien à jour pour Jessie (dont php7.4) viennent d'être supprimés sur deb.sury.org (et tout ce qui tourne autour, genre php-redis et les bonnes dépendances)... Personne n'aurait ça dans le coin ? - Oui Jessie c'est vieux mais bon... TG de Pineau vieux pour les amateurs ;) -- Be Seeing You Number Six
Hello, J'ai ça dans nos repos interne. Tu as besoin de quoi ? Tu veux que je te transfert ca quelques part ? MP Ronan Le sam. 18 juil. 2020 à 19:36, Stéphane Rivière <stef@genesix.org> a écrit :
Me suis fait avoir... tous les packages bien à jour pour Jessie (dont php7.4) viennent d'être supprimés sur deb.sury.org (et tout ce qui tourne autour, genre php-redis et les bonnes dépendances)...
Personne n'aurait ça dans le coin ? - Oui Jessie c'est vieux mais bon...
TG de Pineau vieux pour les amateurs ;)
-- Be Seeing You Number Six
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Ronan,
J'ai ça dans nos repos interne. Tu as besoin de quoi ? Tu veux que je te transfert ca quelques part ? MP
Oh punaise génial !!! Ce qui me décoincerai grave, c'est ces deux paquets... https://packages.sury.org/php/ jessie/main php-redis amd64 5.3.0+4.3.0-2+0~20200707.24+debian8~1.gbp066876 https://packages.sury.org/php/ jessie/main php-igbinary amd64 3.1.2+2.0.8-1+0~20200518.16+debian8~1.gbp1a098b Et c'est juste ma faute... J'ai pas twitter, j'ai pas vu l'autodafé en préparation et deux jours avant qu'il efface tout, j'ai passé une VM php7.0 en php7.4 (ce qui a déclenché ensuite une 'intolérance' à predis (depuis php7.2) et quand j'ai voulu remplacer par php-redis... c'était parti :() PS J'aurais bien pris (plus tard) en amd64 /php/pool/main/p ou à défaut /php/pool/main/p/php7.4 mais je ne sais pas si il y a une manière simple pour toi de faire ça, sinon on oublie, tu me sauves déjà, je vais pas abuser :)))
TG de Pineau vieux pour les amateurs ;)
Blanc ou rouge ? :) Bien frais avec glaçons ? -- Stéphane Rivière Ile d'Oléron - France
Le 18/07/2020 à 20:04, Stéphane Rivière a écrit :
Bonjour Ronan,
J'ai ça dans nos repos interne. Tu as besoin de quoi ? Tu veux que je te transfert ca quelques part ? MP Oh punaise génial !!!
Ce qui me décoincerai grave, c'est ces deux paquets...
https://packages.sury.org/php/ jessie/main php-redis amd64 5.3.0+4.3.0-2+0~20200707.24+debian8~1.gbp066876
https://packages.sury.org/php/ jessie/main php-igbinary amd64 3.1.2+2.0.8-1+0~20200518.16+debian8~1.gbp1a098b
Et c'est juste ma faute... J'ai pas twitter, j'ai pas vu l'autodafé en préparation et deux jours avant qu'il efface tout, j'ai passé une VM php7.0 en php7.4 (ce qui a déclenché ensuite une 'intolérance' à predis (depuis php7.2) et quand j'ai voulu remplacer par php-redis... c'était parti :()
PS
J'aurais bien pris (plus tard) en amd64 /php/pool/main/p ou à défaut /php/pool/main/p/php7.4 mais je ne sais pas si il y a une manière simple pour toi de faire ça, sinon on oublie, tu me sauves déjà, je vais pas abuser :)))
TG de Pineau vieux pour les amateurs ;)
Blanc ou rouge ? :) Bien frais avec glaçons ?
Bonsoir, Sinon il y a peut-être le depot debian archive: http://archive.debian.org/debian/README A+ Alex.
apt-get dist-upgrade ? Le 18/07/2020 à 19:33, Stéphane Rivière a écrit :
Me suis fait avoir... tous les packages bien à jour pour Jessie (dont php7.4) viennent d'être supprimés sur deb.sury.org (et tout ce qui tourne autour, genre php-redis et les bonnes dépendances)...
Personne n'aurait ça dans le coin ? - Oui Jessie c'est vieux mais bon...
TG de Pineau vieux pour les amateurs ;)
Le 18/07/2020 à 21:29, Guillaume Tournat a écrit :
apt-get dist-upgrade ?
Plus compliqué que ça... Depuis quelques version Debian devient vraiment pénible dans ses upgrades. Impossible de passer d'une version à l'autre sans tout casser. systemd, pourquoi pas, on s'y est fait, mais network-systemd, là ça me casse les <censuré> À moins qu'il y ait un génie pour me dire comment transposer pointtopoint de interfaces dans networkd, marre de devoir réinventer la roue pour juste rien... Et je dois faire vivre cette VM encore arf, environ 6 mois... Et après je repars sur du neuf, même si on a pas mal de choses déjà compilées et à jour dessus... Probablement sur du Devuan pour avoir la paix de la config :) systemd a ses bons cotés, mais ça s'occupe de trop de choses aujourd'hui, fallait pas toucher au réseau :) On a des setups chiadés au niveau hyperviseur Xen (dont on se sert comme routeur local) et pas question de changer ce qui marche parfaitement. -- Stéphane Rivière Ile d'Oléron - France
Le samedi 18 juillet 2020, 22:02:02 CEST Stéphane Rivière a écrit :
Le 18/07/2020 à 21:29, Guillaume Tournat a écrit :
apt-get dist-upgrade ?
Plus compliqué que ça...
Depuis quelques version Debian devient vraiment pénible dans ses upgrades. Impossible de passer d'une version à l'autre sans tout casser.
systemd, pourquoi pas, on s'y est fait, mais network-systemd, là ça me casse les <censuré> À moins qu'il y ait un génie pour me dire comment transposer pointtopoint de interfaces dans networkd, marre de devoir réinventer la roue pour juste rien...
[...] Bonsoir, Je ne pense pas que networkd soit obligatoire, par défaut sur Debian. Bon, ça fait un moment que je n'ai pas fait d'installation, mais mes sid sont toujours avec /etc/network/interfaces / ifupdown. Sauf une ou j'ai justement voulu tester systemd-networkd.
cat /etc/apt/preferences.d/systemd Package: *systemd* Pin: release * Pin-Priority: -1 comme ca, il n'installe pas cette bouse de systemd. on reste sur un bon vieux sysV des familles : # dpkg -l|grep sysv ii sysv-rc 2.93-8 all System-V-like runlevel change mechanism ii sysvinit-core 2.93-8 amd64 System-V-like init utilities ii sysvinit-utils 2.93-8 amd64 System-V-like utilities et si on garde des configs propres, ca migre sans souci. Le 18/07/2020 à 22:02, Stéphane Rivière a écrit :
Le 18/07/2020 à 21:29, Guillaume Tournat a écrit :
apt-get dist-upgrade ?
Plus compliqué que ça...
Depuis quelques version Debian devient vraiment pénible dans ses upgrades. Impossible de passer d'une version à l'autre sans tout casser.
systemd, pourquoi pas, on s'y est fait, mais network-systemd, là ça me casse les <censuré> À moins qu'il y ait un génie pour me dire comment transposer pointtopoint de interfaces dans networkd, marre de devoir réinventer la roue pour juste rien...
Et je dois faire vivre cette VM encore arf, environ 6 mois...
Et après je repars sur du neuf, même si on a pas mal de choses déjà compilées et à jour dessus... Probablement sur du Devuan pour avoir la paix de la config :)
systemd a ses bons cotés, mais ça s'occupe de trop de choses aujourd'hui, fallait pas toucher au réseau :) On a des setups chiadés au niveau hyperviseur Xen (dont on se sert comme routeur local) et pas question de changer ce qui marche parfaitement.
Le 19/07/2020 à 00:29, Guillaume Tournat a écrit :
cat /etc/apt/preferences.d/systemd Package: *systemd* Pin: release * Pin-Priority: -1
Je pars d'une install nue systemd Buster par exemple...
comme ca, il n'installe pas cette bouse de systemd.
Je pin tout systemd... J'installe sysvinit-core Régénère initramfs et grub et redémarre ? Puis je mets en hold sysvinit-core pour prévenir toute réinstallation intempestive de systemd ? C'est /aussi simple/ que ça ? Sur une station gnome, je suis bien sûr qu'on aurait quelques /centaines de paquets désormais dépendants de systemd. Dans le cas d'un serveur, avec tous les paquets typiques d'un serveur, on échappe à ces dépendances ? mmm... shure not ? (C) Idiocracy
on reste sur un bon vieux sysV des familles :
Faut avouer que, pour un serveur dont l'objectif est la fiabilité, donc la simplicité, systemd n'est pas indispensable.
# dpkg -l|grep sysv ii sysv-rc 2.93-8 all System-V-like runlevel change mechanism ii sysvinit-core 2.93-8 amd64 System-V-like init utilities ii sysvinit-utils 2.93-8 amd64 System-V-like utilities
et si on garde des configs propres, ca migre sans souci.
N'ayant pas peur des nouveautés, je m'étais toujours adapté aux évolutions. Mais ta proposition rejoins ma préoccupation. J'avais vaguement entendu dire qu'on pouvait (comme le suggérais Gilles) se passer de networkd, qu'on pouvait aussi virer systemd... et bien allons y... Merci pour vos bons conseils ! -- Be Seeing You Number Six
pas besoin de mettre en hold ensuite sysV, le simple fait de mettre Pin-Priority:-1 sur systemd interdit son installation. je nettoie toute install Debian de cette atrocité, sauf par exemple quand je monte un hyperviseur Proxmox, où là c'est un prérequis de l'appli. Le 19/07/2020 à 12:13, Stéphane Rivière a écrit :
Le 19/07/2020 à 00:29, Guillaume Tournat a écrit :
cat /etc/apt/preferences.d/systemd Package: *systemd* Pin: release * Pin-Priority: -1 Je pars d'une install nue systemd Buster par exemple...
comme ca, il n'installe pas cette bouse de systemd. Je pin tout systemd... J'installe sysvinit-core Régénère initramfs et grub et redémarre ?
Puis je mets en hold sysvinit-core pour prévenir toute réinstallation intempestive de systemd ?
C'est /aussi simple/ que ça ?
Sur une station gnome, je suis bien sûr qu'on aurait quelques /centaines de paquets désormais dépendants de systemd.
Dans le cas d'un serveur, avec tous les paquets typiques d'un serveur, on échappe à ces dépendances ?
mmm... shure not ? (C) Idiocracy
on reste sur un bon vieux sysV des familles : Faut avouer que, pour un serveur dont l'objectif est la fiabilité, donc la simplicité, systemd n'est pas indispensable.
# dpkg -l|grep sysv ii sysv-rc 2.93-8 all System-V-like runlevel change mechanism ii sysvinit-core 2.93-8 amd64 System-V-like init utilities ii sysvinit-utils 2.93-8 amd64 System-V-like utilities
et si on garde des configs propres, ca migre sans souci. N'ayant pas peur des nouveautés, je m'étais toujours adapté aux évolutions. Mais ta proposition rejoins ma préoccupation.
J'avais vaguement entendu dire qu'on pouvait (comme le suggérais Gilles) se passer de networkd, qu'on pouvait aussi virer systemd... et bien allons y...
Merci pour vos bons conseils !
Le 18/07/2020 à 22:02, Stéphane Rivière a écrit :
Le 18/07/2020 à 21:29, Guillaume Tournat a écrit :
apt-get dist-upgrade ?
Plus compliqué que ça...
Depuis quelques version Debian devient vraiment pénible dans ses upgrades. Impossible de passer d'une version à l'autre sans tout casser.
systemd, pourquoi pas, on s'y est fait, mais network-systemd, là ça me casse les <censuré> À moins qu'il y ait un génie pour me dire comment transposer pointtopoint de interfaces dans networkd, marre de devoir réinventer la roue pour juste rien...
Ah, marrant. Vendredi, j'ai justement remonté un soucis jusqu'à cette merde de systemd-networkd sur une VM qui ... perdait l'IPv6 de manière intermittente. Elle ne pinguait même plus sa gateway pendant des temps de 15 secs à 3/4 minutes. A priori, networkd faisait merder complètement le NDP. Je n'ai pas cherché les détails, j'ai juste tout viré et pouf, nickel depuis. Donc on a un consensus sur le fait qu'ils sont allé trop loin : network, ntp, dns, ... Du coup, on se retrouve à mettre en place des astuces pour EVITER d'utiliser ce truc, c'est fatiguant. Julien
Donc on a un consensus sur le fait qu'ils sont allé trop loin : network, ntp, dns, ...
Même pour le hostname on peut plus taper bêtement dans le fichier, faut tapoter hostnamectl set-hostame <hostname> sinon gare...
Du coup, on se retrouve à mettre en place des astuces pour EVITER d'utiliser ce truc, c'est fatiguant.
Y'avait un gars, dans le temps, (Kha je crois) qui disait : J'utilise Linux non par satisfaction philosophique, mais pour trois raisons : - ça marche - ça marche à chaque fois - et ça marche à chaque fois de la même manière. Les dinos-réacs de chez Devuan, je commence à mieux les comprendre. -- Be Seeing You Number Six
Ils sont en weekend, comme leur infra marche toute seule ils peuvent passer le dimanche au jardin Le 19/07/2020 à 17:17, Seb Astien a écrit :
> Du coup, on se retrouve à mettre en place des astuces pour EVITER > d'utiliser ce truc, c'est fatiguant.
Aucun défenseur systemd sur la liste ?
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Aucun défenseur systemd sur la liste ?
Moi. J'utilise systemd depuis le début.¹ Sauf qu'au début, ça restait à sa place. Et il y avait des idées pas déconnantes. Mais quand tu sors des sentiers battus (de mon coté), et que ça commence à se mêler de tout et de rien (de leur coté) en ignorant les principes Unix d'une fonction par app, ça devient pas nécessairement gérable (à moins d'être un dieu de networkd, ce que je ne suis pas). Sans compter que les bugs, ils en ont, ça... Exemple d'un truc que je n'arrive pas à transposer en networkd... Sur un serveur avec un hyperviseur Xen (Xen ne gère plus le réseau des VM depuis sa nouvelle commande XL, c'est à l'admin de faire sa sauce comme il ne souhaite), quand tu veux utiliser les ressources de l'hyperviseur (routage + firewalling) au lieu d'avoir la classique VM dédiée à un routeur/firewall quelconque - ce qui représente une perte de ressource, perte de perf et complexification parfaitement inutile et des pertes d'IP, avec le cahier des charges suivant : - T'as 1 IP hyper et un /29 ou un /28 et t'as pas non plus envie de perdre 3 IP pour le plaisir (les classiques IP de réseau, de passerelle et de broadcast) - Bridger une IP sur une VM sans bridger l'interface physique ; - Autoriser le mix de VM nattées avec IP alias et de VM bridgées - Autoriser des sous réseaux de VM séparés (intranets isolés les uns des autres). Avec networking/interfaces + iptables (du nux de base quoi), je sais faire et ça poutre du poney question perfs. En plus tu gagnes des IP, une VM, des perfs et tout est dans trois fichiers : interfaces, sysctl et firewall : KISS et ultra fiable : j'ai des bécanes avec 10 à 15 VM qui tournent ainsi depuis cinq ans. Plus d'explication ici : https://stef.genesix.org/pub/serveur_Debian_8_-_Genesix_v2_-_Installation.pd... (page 13 puis 30 et suivantes pour l'exemple en question). Avec systemd-network, j'ai pas trouvé comment reproduire le paramètre pointopoint du fichier interfaces et je suis encore pas bien bon autour des bridges et des interfaces virtuelles. Pourtant j'ai cherché, mais la réponse est toute trouvée : je suis un neuneu paresseux :) ¹ De même que je comprends l'intérêt de Pulse Audio (du même auteur, malgré la polémique) plus facile que Jack pour de "l'audio à Mme Michu" (et même plus, j'ai une install de sono pour un cinéma qui tourne avec pulse audio, ça le fait). -- Stéphane Rivière Ile d'Oléron - France
Le Sunday 19 July 2020 17:56:29 Stéphane Rivière a écrit :
Aucun défenseur systemd sur la liste ?
Moi.
J'utilise systemd depuis le début.¹
Je suis aussi utilisateur, mais tardif. Les scripts sysinit m'ont toujours rebuté, entre la répétition entre scripts, l'incompatibilité entre distribs, le boilerplate dans chaque daemon, la gestion des dépendances ... Il y quelques années j'avais essayé initng (http://web.archive.org/web/20090225093848/http://www.initng.org/), qui n'est plus développé depuis longtemps, mais dont les idées étaient assez proches de systemd, en plus basique. Cependant j'ai attendu de ne plus vraiment avoir le choix avant de passer a systemd [...]
Mais quand tu sors des sentiers battus (de mon coté), et que ça commence à se mêler de tout et de rien (de leur coté) en ignorant les principes Unix d'une fonction par app
Je n'ai pas l'envie de le lancer un débat, mais il y a quand même un certain découpage des programmes et fonctions dans le projet/paquet systemd. Il y a le /sbin/init et les fonctions annexes (networkd par exemple) sont dans des binaires séparés. Est-ce qu'il n'y a pas trop de choses dans le pid 1, pour ca les opinions divergent ... [...]
Sans compter que les bugs, ils en ont, ça...
Ca, oui. Et vu l'attitude des dévs, personne n'a envie de les rapporter et de se faire agresser. En particulier networkd, c'est pas vraiment sec. D'ailleurs networkd n'est pas disponible du tout (même pas packagé) dans redhat/centos 8. En gros, faut pas faire d'interfaces trop dynamiques ou de reload, mais sur un serveur c'est beaucoup plus utilisable que le monstre NetworkManager et l'horreur de la config de ce truc. Et aussi plus complet, plus maintenu, plus rapide et avec moins de race conditions que ifupdown qui reste le défaut sous debian, networkd étant bien désactivé par défaut.
Exemple d'un truc que je n'arrive pas à transposer en networkd... ... - T'as 1 IP hyper et un /29 ou un /28 et t'as pas non plus envie de perdre 3 IP pour le plaisir (les classiques IP de réseau, de passerelle et de broadcast) - Bridger une IP sur une VM sans bridger l'interface physique ; - Autoriser le mix de VM nattées avec IP alias et de VM bridgées - Autoriser des sous réseaux de VM séparés (intranets isolés les uns des autres). ...
Plus d'explication ici : https://stef.genesix.org/pub/serveur_Debian_8_-_Genesix_v2_-_Installation.pd f (page 13 puis 30 et suivantes pour l'exemple en question).
Avec systemd-network, j'ai pas trouvé comment reproduire le paramètre pointopoint du fichier interfaces
Si je comprends bien (j'ai pas tout lu tout le doc, mais ca paraitrait logique chez ovh), la config c'est que la passerelle est *sur le même lien* (L2) mais pas directement accessible sur le même réseau IP (L3). Le mot clé c'est donc "on-link" pour forcer la présence de la gw sur le lien, comme avec la commande ip pour éviter d'avoir "Error: Nexthop has invalid gateway." : # ip r add $route via $gw onlink dev eth0 Exemple avec une vm en 145.x en macvtap (avec kvm) avec une mac virtuelle sur un dédié en 188.x dont la gw est en 188.x.x.254 (et avec le renommage d'interface pour éviter les conneries du genre ens4u8x4y5z6p1 en bonus) : # cat 32-wan0.link [Match] MACAddress=02:00:00:xx:xx:xx [Link] Name=wan0 # cat 32-wan0.network [Match] Name=wan0 [Network] Address=145.x.x.x/32 [Route] Gateway=188.x.x.254 GatewayOnlink=yes C'est presque pareil avec un bloc ip *routé* sur l'ip principale (cas de l'xdsl ovh), mais la gw est l'ip interne de la gw sur cette interface, pas la gw ovh. Je suppose que c'est pareil sur les serveurs ...
et je suis encore pas bien bon autour des bridges et des interfaces virtuelles. Pourtant j'ai cherché, mais la réponse est toute trouvée : je suis un neuneu paresseux :)
Pour créer un bridge : # cat 40-virbr0.netdev [NetDev] Name=virbr0 Kind=bridge [Bridge] ForwardDelaySec=250ms et un .network qui va bien pour mettre une ip la dessus Puis dans les .network des interfaces a mettre dans le bridge, si besoin : [Match] Name=ethX [Network] Bridge=virbr0 Le problème de la doc est que vu qu'il faut créer (pour chaque interface) 3 types de fichier, il faut regarder dans 3 pages de man : systemd.link systemd.netdev systemd.network . Et aussi, ca multiplie très vite le nombre de fichiers, par exemple sur une passerelle un peu complexe j'en suis a plus de 30 ... Après pour la partie xen, je ne connais pas du tout
¹ De même que je comprends l'intérêt de Pulse Audio (du même auteur, malgré la polémique) plus facile que Jack pour de "l'audio à Mme Michu" (et même plus, j'ai une install de sono pour un cinéma qui tourne avec pulse audio, ça le fait).
Oui, ca a son utilité, mais il a quand même fallu attendre quelques années pour avoir un truc utilisable, vu que l'attitude de l'auteur en question était déjà la même et qu'il considérerait que son code était parfait et que le problème était forcément les drivers/le matériel/les utilisateurs. Depuis qu'il a abandonné ce projet pour se consacrer a systemd, c'est devenu plus stable et les bugs ont pour la plupart été corrigés ...
Hello la liste, Je n'écris pas souvent alors je me permet de réagir....
Je suis aussi utilisateur, mais tardif.
Très tardif, mais je suis en train de ne plus être utilisateur (voir plus bas).
Les scripts sysinit m'ont toujours rebuté, entre la répétition entre scripts, l'incompatibilité entre distribs, le boilerplate dans chaque daemon, la gestion des dépendances ... Il y quelques années j'avais essayé initng
initng me paraissais bien en tous cas pour les linux qui le supportaient.
choix avant de passer a systemd
Idem. Passé dessus parce qu'on m'as pas demandé mon choix (enfin, techniquement je pourrais, mais l'install de base du linux m'obligeant sur les devices linux only que j'ai... j'ai dû m'adapter) (...)
Je n'ai pas l'envie de le lancer un débat, mais il y a quand même un certain découpage des programmes et fonctions dans le projet/paquet systemd. Il y a le /sbin/init et les fonctions annexes (networkd par exemple) sont dans des binaires séparés. Est-ce qu'il n'y a pas trop de choses dans le pid 1, pour ca les opinions divergent ...
Heu là je suis un dino, et la phylosophie des unix c'est KISS : keep it simple and stupid. Sans compter le repects des RFC qui sont totalement ignorées par les dev. Exemple : le DNS, le client DHCP, les RA etc... Systemd avec tout le merdier dans pid 1 est tout SAUF KISS. Et ses dépendances ne le sont pas, ainsi que les besoins de plein de lib, a un tel point qu'on arrive a faire des choses "fat" pour un OS qui as la réputation d'être simple (voir encore plus bas). (...)
Le problème de la doc est que vu qu'il faut créer (pour chaque interface) 3 types de fichier, il faut regarder dans 3 pages de man : systemd.link systemd.netdev systemd.network . Et aussi, ca multiplie très vite le nombre de fichiers, par exemple sur une passerelle un peu complexe j'en suis a plus de 30 ...
Suis désolé mais 3 fichiers pour chacune des interfaces, c'est tout sauf KISS. Quand par exemple je fait du NAT compliqué avec un os libre, j'ai besoin d'avoir tout sur un fichier pour comprendre les choses. En terme de maintenabilité, c'est tout sauf maintenable. Un moment de trop découper on deviens une usine a gaz et on espère que les dépendances sont correctement gérées. Pourquoi je râle ? Simple: quand on reprends une infra d'un tier et qu'il faut passer plusieurs jours a comprendre les systemdiseries qui bien évidement changent parce qu'il n'y a pas de stabilité dans les implementation, on croise les doigts pour ce machin n'explose pas en vol. Si pour le poste de travail, je n'ai rien contre systemd (oui on peux l'encadrer), dans le cadre d'infra serveur, je n'ai absolument pas besoin de ce truc. On a plein de méthode pour éviter ce délire, et les containers (docker, jails, etc...) permettent d'arbitrer correctement le lancement des dépendance si on est pas idiot, et aussi permettre de faire une archi scalable. Systemd en env serveur n'as rien a faire dedans. D'ailleurs les idées de fichiers découpés en plusieurs fichiers ont tjrs rendu les choses compliquées que simple, mais l'habitude des debian a fait que ça a dérapé. De mon coté, je pousse du FreeBSD, des jails et un vrai stack réseau qui marche. Un /etc/rc.conf qui contient tout la configuration système est bcp plus pratique qu'une centaine de fichiers mis un peu partout... Après connaissant bien le monde de linux, je suis avec mon générateur de popcorn, et comme debian permet de nouveau de ne pas dépendre de systemd, c'est que quand même il y a de l'espoir... Xavier
(je zappe le reste, pas envie de me lancer dans un débat pour/contre systemd. Et j'utilise vim, emacs c'est nul ;-) ) On lundi 20 juillet 2020 08:10:28 CEST, Xavier Beaudouin wrote:
Suis désolé mais 3 fichiers pour chacune des interfaces, c'est tout sauf KISS.
Je suis d'accord que ca fait beaucoup et j'aurais préféré avoir le choix de regrouper certains fichiers, ou de continuer a utiliser ifupdown, mais quand on est obligé de faire des ifup -a --force a chaque reboot parce que la gw statique est déjà définie par ipv6 RA et que ifupdown aime pas, on cherche ailleurs un truc pas trop compliqué et qui fonctionne. Mais une vm typique, c'est 2 fichiers, le .link lu par udev pour le renommage de l'interface (la seule méthode qui fonctionne encore correctement, même sans networkd), et le .network pour les paramètres ip. Mes 30 fichiers sur la passerelle, c'est un cas extrême avec des bridges, des vlans, plusieurs wans, des interfaces xfrm pour ipsec, ... Le tout est généré par ansible, ou c'est moins découpé, donc ca reste gérable. La même config avec ifupdown, c'était devenu impossible niveau interdépendances, et foireux dès qu'un des wans tombait (ok, une partie est certainement de ma faute ...).
D'ailleurs les idées de fichiers découpés en plusieurs fichiers ont tjrs rendu les choses compliquées que simple, mais l'habitude des debian a fait que ça a dérapé.
On peut quand même y voir un avantage pour ansible et autres, pas besoin de jouer avec des fragiles blockinfile ou replace, on écrase les fichiers complets ... Et je préfère largement ca que 18000 lignes de xml ...
comme debian permet de nouveau de ne pas dépendre de systemd,
Fake news. systemd n'a jamais été le seul choix possible sous debian, du moins en environnement serveur, faut pas croire ce que racontent certains trolls. C'est gnome et les autres DE qui ont forcé la dépendance sur systemd-logind, pour la gestion des sessions, et l'alternative elogind a été empêchée d'entrer dans debian ... Après vu le peu d'utilisateurs restant de sysvinit et donc le peu de tests, faut pas s'attendre a quelque chose de parfait
Hello Vincent,
Les scripts sysinit m'ont toujours rebuté, entre la répétition entre scripts, l'incompatibilité entre distribs, le boilerplate dans chaque daemon, la gestion des dépendances ...
Tout à fait d'accord. Tant que systemd en restait à l'init, je considérais ça comme un progrès.
En particulier networkd, c'est pas vraiment sec. D'ailleurs networkd n'est pas disponible du tout (même pas packagé) dans redhat/centos 8.
Si je comprends bien (j'ai pas tout lu tout le doc, mais ca paraitrait logique
Merci beaucoup pour tes exemples, je vais les garder précieusement pour des expérimentations futures :) !
Oui, ca a son utilité, mais il a quand même fallu attendre quelques années pour avoir un truc utilisable, vu que l'attitude de l'auteur en question était déjà la même et qu'il considérerait que son code était parfait et que le problème était forcément les drivers/le matériel/les utilisateurs. Depuis qu'il a abandonné ce projet pour se consacrer a systemd, c'est devenu plus stable et les bugs ont pour la plupart été corrigés ...
+1 -- Be Seeing You Number Six
Si, si.... mais lorsque les gens sont persuadés d'une chose pourquoi les persuader d'une autre ? Pour ma part, à partir du moment où RedHat active qq chose dans sa distribution entreprise, je regarde de près en général... mais avant faut juste regarder pour voir ce qui va arriver pas l'utiliser en prod. Exemple, j'ai utilisé XFS au tout début de sa libération.... Ben j'ai perdu des fichiers...Depuis que RedHat le propose par défaut comme type de fs cela ne m'est plus jamais arrivé. Systemd, plus je creuse, plus je trouve qu'il y a plein de bonnes idées... Systemd ça : - Gère bien les dépendances (chkconfig avec des valeurs à la main ça reste pas exceptionnel) - Démarre en // des services qui peuvent démarrer en // (mais j'ai eu un tour en RHEL 7.x où il n'y avait pas les bonnes dépendances entre udev, lvm, et multipath et du coup je perdais mes disques, RedHat a depuis bien résolu le pb et ils avaient pondu un workaround rapidement de tête) - Peut démarrer des services sur présence d'une socket, un fichier, etc... - Gère les cgroups pour toi (et les cgroups c'est qq qui je crois est d'un certain intérêt pour les container) Bref... Après systemd-network, c'est pas encore mur (tiens d'ailleurs j'ai l'impression que RH le propose pas de base dans ses distro entreprises, je devrais vérifier)...et je regarderais plus autour de Network-Manager qui me semble vraiment avoir bien muri (en version RHEL/CentOS 6.x c'était limite), pour ceux qui auraient du mal à maitriser le biniou regarder le miracle de completion disponible avec la commande nmcli /me pour moi c'est pas une obligation systemd-network sur Debian, sur Ubuntu c'est bcp moins sur... Trolldiment, JYL Le 19/07/2020 à 17:17, Seb Astien a écrit :
> Du coup, on se retrouve à mettre en place des astuces pour EVITER > d'utiliser ce truc, c'est fatiguant.
Aucun défenseur systemd sur la liste ?
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le dim. 19 juil. 2020 à 17:19, Seb Astien <krionux@gmail.com> a écrit :
Aucun défenseur systemd sur la liste ?
Si, mais plus la force. J'invite les gens intéressés à regarder cette excellente conf de Benno Rice qui explique très bien pourquoi autant de résistance au changement : https://www.youtube.com/watch?v=o_AIw9bGogo. Ma résolution de 2020 était d'arrêter de pisser dans des violons, et j'essaie de m'y tenir. :) -- Jonathan Leroy
Il y a même eu un fork de Debian (nommé Devuan) Depuis ils ont remis la possibilité de s’en passer dans une Debian mainstream. Et je ne m’en prive pas...
Le 19 juil. 2020 à 16:44, Julien Escario <julien.escario@altinea.fr> a écrit :
Le 18/07/2020 à 22:02, Stéphane Rivière a écrit :
Le 18/07/2020 à 21:29, Guillaume Tournat a écrit : apt-get dist-upgrade ?
Plus compliqué que ça...
Depuis quelques version Debian devient vraiment pénible dans ses upgrades. Impossible de passer d'une version à l'autre sans tout casser.
systemd, pourquoi pas, on s'y est fait, mais network-systemd, là ça me casse les <censuré> À moins qu'il y ait un génie pour me dire comment transposer pointtopoint de interfaces dans networkd, marre de devoir réinventer la roue pour juste rien...
Ah, marrant. Vendredi, j'ai justement remonté un soucis jusqu'à cette merde de systemd-networkd sur une VM qui ... perdait l'IPv6 de manière intermittente. Elle ne pinguait même plus sa gateway pendant des temps de 15 secs à 3/4 minutes. A priori, networkd faisait merder complètement le NDP.
Je n'ai pas cherché les détails, j'ai juste tout viré et pouf, nickel depuis.
Donc on a un consensus sur le fait qu'ils sont allé trop loin : network, ntp, dns, ...
Du coup, on se retrouve à mettre en place des astuces pour EVITER d'utiliser ce truc, c'est fatiguant.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Pas certain que cette possibilité perdure aux vues des dernières évolutions et des souhaits exprimés par certain développeurs Debian ( https://m.slashdot.org/story/365234 ). Perso, je préfère devuan ou tenter de me débrouiller avec systemd/debian (j'ai un paquet de recettes en fonction des distros/paquets), même si je rejoins votre point de vue sur le "ils vont trop loin" (et encore on n'a pas encore le systemd-homed...). Bref, un peu dégoûté de ces évolutions de mon côté également (KISS where are you... ?). Rémy. Ps : truc drôle aussi : changer motd dans une ubuntu récente... Le 19 juillet 2020 17:27:01 GMT+02:00, Guillaume Tournat via FRsAG <frsag@frsag.org> a écrit :
Il y a même eu un fork de Debian (nommé Devuan)
Depuis ils ont remis la possibilité de s’en passer dans une Debian mainstream.
Et je ne m’en prive pas...
Le 19 juil. 2020 à 16:44, Julien Escario <julien.escario@altinea.fr> a écrit :
Le 18/07/2020 à 22:02, Stéphane Rivière a écrit :
Le 18/07/2020 à 21:29, Guillaume Tournat a écrit : apt-get dist-upgrade ?
Plus compliqué que ça...
Depuis quelques version Debian devient vraiment pénible dans ses upgrades. Impossible de passer d'une version à l'autre sans tout
casser.
systemd, pourquoi pas, on s'y est fait, mais network-systemd, là ça
me
casse les <censuré> À moins qu'il y ait un génie pour me dire comment transposer pointtopoint de interfaces dans networkd, marre de devoir réinventer la roue pour juste rien...
Ah, marrant. Vendredi, j'ai justement remonté un soucis jusqu'à cette merde de systemd-networkd sur une VM qui ... perdait l'IPv6 de manière intermittente. Elle ne pinguait même plus sa gateway pendant des temps de 15 secs à 3/4 minutes. A priori, networkd faisait merder complètement le NDP.
Je n'ai pas cherché les détails, j'ai juste tout viré et pouf, nickel depuis.
Donc on a un consensus sur le fait qu'ils sont allé trop loin : network, ntp, dns, ...
Du coup, on se retrouve à mettre en place des astuces pour EVITER d'utiliser ce truc, c'est fatiguant.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Le 18/07/2020 à 19:33, Stéphane Rivière a écrit :
Me suis fait avoir... tous les packages bien à jour pour Jessie (dont php7.4) viennent d'être supprimés sur deb.sury.org (et tout ce qui tourne autour, genre php-redis et les bonnes dépendances)...
Personne n'aurait ça dans le coin ? - Oui Jessie c'est vieux mais bon...
TG de Pineau vieux pour les amateurs ;)
https://web.archive.org/web/20200122224444/https://packages.sury.org/php/dis... ? :P Sinon, passer sur une version de Debian avant la bascule en oldstable ;) @+ Gilou
Merci à Ronan pour le partage... Je laisse ça à dispo ici, pour un bout de temps, si ça peut aider d'autre paléojessiens à avoir du PHP 7.4 dessus (entre autres). https://stef.genesix.org/pub/sury-jessie -- Be Seeing You Number Six
Le Mon, Jul 20, 2020 at 04:26:51PM +0200, Stéphane Rivière a écrit:
Merci à Ronan pour le partage... Je laisse ça à dispo ici, pour un bout de temps, si ça peut aider d'autre paléojessiens à avoir du PHP 7.4 dessus (entre autres). https://stef.genesix.org/pub/sury-jessie
J'en ai une rigolote dans l'autre sens: j'ai un client qui a besoin de php *4* pour une appli avant sa migration d'ici la fin de l'année en théorie. Je ne suis même pas sûr de pouvoir retrouver une etch pour lui faire tourner ça dessus... Je pars du principe que ça n'existe pas sous buster, on est d'accord ? :) Arnaud.
Le 21/07/2020 à 17:33, Arnaud Launay a écrit :
Le Mon, Jul 20, 2020 at 04:26:51PM +0200, Stéphane Rivière a écrit:
Merci à Ronan pour le partage... Je laisse ça à dispo ici, pour un bout de temps, si ça peut aider d'autre paléojessiens à avoir du PHP 7.4 dessus (entre autres). https://stef.genesix.org/pub/sury-jessie J'en ai une rigolote dans l'autre sens: j'ai un client qui a besoin de php *4* pour une appli avant sa migration d'ici la fin de l'année en théorie. Je ne suis même pas sûr de pouvoir retrouver une etch pour lui faire tourner ça dessus... Je pars du principe que ça n'existe pas sous buster, on est d'accord ? :)
Arnaud. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
à l'époque, j'avais écrit une procédure pour le compiler sur debian 7 (doit être adaptable en debian 8, sur stretch et buster, j'en sais rien, j'ai jamais essayé, mais ça doit être la misère avec les libs) ## installer OpenSSL 0.9.X : ./config --prefix=/opt/applis/openssl-0.9.8zh ## installer les dépendances (Debian 7) aptitude install flex libssl-dev libcurl4-openssl-dev libgnutls-openssl27 libcurl-dev libcurl4 libxml2-dev libpng-dev libpng3-dev libmcrypt-dev mcrypt libtomcrypt-dev libjpeg8-dev libfreetype6-dev libmhash-dev libmysqlclient-dev libexpat1-dev libxslt1-dev libgd2-xpm-dev autoconf bison libbison-dev libbz2-dev libbz2-dev curl libxpm-dev libicu-dev unixodbc-dev libreadline-dev libgmp-dev libjpeg-dev libpspell-dev libicu-dev ## faire un peu de karaté avec les libs mkdir /usr/kerberos mkdir /usr/include/freetype2/freetype/ ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/libpng.so ln -s /usr/lib/x86_64-linux-gnu/libmysqlclient.so /usr/lib/libmysqlclient.so ln -s /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 /usr/lib/libmysqlclient.so.18 ln -s /usr/lib/x86_64-linux-gnu/libexpat.so /usr/lib/libexpat.so ln -s /usr/include/freetype2/freetype.h "/usr/include/freetype2/freetype/freetype.h" ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64 ## configurer le bouzin ./configure --prefix=/opt/applis/php-4.4.9 --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl --with-mcrypt --with-zlib --with-gd --disable-rpath --enable-inline-optimization --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --with-mhash --enable-zip --with-pcre-regex --with-mysql=/usr --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl=/opt/applis/openssl-0.9.8zh --with-openssl-dir=/opt/applis/openssl-0.9.8zh --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-imap-ssl --with-kerberos --with-gettext --with-expat-dir=/usr --enable-fastcgi et voilà ça marchait.
Je confirme que du php plus vieux que 5.6 sous Debian > 8 c'est la misère et pour moi impossible tellement les libs ssl et d'autres dépendances ont évoluées, ils n'arrivent plus à se brancher ensemble (correction de bug et sécu qui empêche le fonctionnement). Seule solution réinstaller une vieille Debian qui a la bonne version mais y aura d'autres soucis comme les ciphers tls / ssh obsolètes, toute la suite supervision, métrologie, sauvegarde moderne qui ne pourra pas se brancher dessus... Le 21/07/2020 à 17:38, Pierre DOLIDON a écrit :
Le 21/07/2020 à 17:33, Arnaud Launay a écrit :
Le Mon, Jul 20, 2020 at 04:26:51PM +0200, Stéphane Rivière a écrit:
Merci à Ronan pour le partage... Je laisse ça à dispo ici, pour un bout de temps, si ça peut aider d'autre paléojessiens à avoir du PHP 7.4 dessus (entre autres). https://stef.genesix.org/pub/sury-jessie J'en ai une rigolote dans l'autre sens: j'ai un client qui a besoin de php *4* pour une appli avant sa migration d'ici la fin de l'année en théorie. Je ne suis même pas sûr de pouvoir retrouver une etch pour lui faire tourner ça dessus... Je pars du principe que ça n'existe pas sous buster, on est d'accord ? :)
Arnaud. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
à l'époque, j'avais écrit une procédure pour le compiler sur debian 7 (doit être adaptable en debian 8, sur stretch et buster, j'en sais rien, j'ai jamais essayé, mais ça doit être la misère avec les libs)
## installer OpenSSL 0.9.X : ./config --prefix=/opt/applis/openssl-0.9.8zh
## installer les dépendances (Debian 7) aptitude install flex libssl-dev libcurl4-openssl-dev libgnutls-openssl27 libcurl-dev libcurl4 libxml2-dev libpng-dev libpng3-dev libmcrypt-dev mcrypt libtomcrypt-dev libjpeg8-dev libfreetype6-dev libmhash-dev libmysqlclient-dev libexpat1-dev libxslt1-dev libgd2-xpm-dev autoconf bison libbison-dev libbz2-dev libbz2-dev curl libxpm-dev libicu-dev unixodbc-dev libreadline-dev libgmp-dev libjpeg-dev libpspell-dev libicu-dev
## faire un peu de karaté avec les libs mkdir /usr/kerberos mkdir /usr/include/freetype2/freetype/ ln -s /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/libjpeg.so ln -s /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/libpng.so ln -s /usr/lib/x86_64-linux-gnu/libmysqlclient.so /usr/lib/libmysqlclient.so ln -s /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 /usr/lib/libmysqlclient.so.18 ln -s /usr/lib/x86_64-linux-gnu/libexpat.so /usr/lib/libexpat.so ln -s /usr/include/freetype2/freetype.h "/usr/include/freetype2/freetype/freetype.h" ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64
## configurer le bouzin ./configure --prefix=/opt/applis/php-4.4.9 --with-zlib-dir --with-freetype-dir --enable-mbstring --with-libxml-dir=/usr --enable-soap --enable-calendar --with-curl --with-mcrypt --with-zlib --with-gd --disable-rpath --enable-inline-optimization --with-zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-pcntl --enable-mbregex --with-mhash --enable-zip --with-pcre-regex --with-mysql=/usr --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-jpeg-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-openssl=/opt/applis/openssl-0.9.8zh --with-openssl-dir=/opt/applis/openssl-0.9.8zh --with-libdir=/lib/x86_64-linux-gnu --enable-ftp --with-imap-ssl --with-kerberos --with-gettext --with-expat-dir=/usr --enable-fastcgi
et voilà ça marchait.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Tuesday 21 July 2020 17:33:11 Arnaud Launay a écrit :
J'en ai une rigolote dans l'autre sens: j'ai un client qui a besoin de php *4* pour une appli avant sa migration d'ici la fin de l'année en théorie.
Bon la on est dans le domaine de la paléontologie, plus dans l'archéologie ...
Je ne suis même pas sûr de pouvoir retrouver une etch pour lui faire tourner ça dessus...
Dans les archives debian ca doit se trouver : deb http://archive.debian.org/debian etch main et les cds d'install : https://cdimage.debian.org/cdimage/archive/ https://cdimage.debian.org/cdimage/archive/4.0_r9/amd64/iso-cd/ A l'epoque il ne devait pas y avoir de date d'expiration dans les dépots, sinon il faudra désactiver le check Sans support de sécurité depuis une décennie, bien entendu ...
Je pars du principe que ça n'existe pas sous buster, on est d'accord ? :)
Non, il n'y a que php 7.3 dans les dépôts officiels ... Peut etre que ca compile a la main sous buster ...
Salut Il existe phpfarm qui permet de faire de l'archéologie/paléontologie. https://github.com/fpoirotte/phpfarm ça simplifie fortement la compilation et tu peux avoir du php-fpm assez facilement. C'est ce que j'utilisais avant d'avoir sury et que debian découpe les version php. Sur mes vieux serveurs ça tourne encore :) Km Le 21/07/2020 à 18:15, Vincent Tondellier via FRsAG a écrit :
Le Tuesday 21 July 2020 17:33:11 Arnaud Launay a écrit :
J'en ai une rigolote dans l'autre sens: j'ai un client qui a besoin de php *4* pour une appli avant sa migration d'ici la fin de l'année en théorie.
Bon la on est dans le domaine de la paléontologie, plus dans l'archéologie ...
Je ne suis même pas sûr de pouvoir retrouver une etch pour lui faire tourner ça dessus...
Dans les archives debian ca doit se trouver :
deb http://archive.debian.org/debian etch main
et les cds d'install :
https://cdimage.debian.org/cdimage/archive/
https://cdimage.debian.org/cdimage/archive/4.0_r9/amd64/iso-cd/
A l'epoque il ne devait pas y avoir de date d'expiration dans les dépots, sinon il faudra désactiver le check
Sans support de sécurité depuis une décennie, bien entendu ...
Je pars du principe que ça n'existe pas sous buster, on est d'accord ? :)
Non, il n'y a que php 7.3 dans les dépôts officiels ...
Peut etre que ca compile a la main sous buster ... _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ouah sacré projet dommage que je l'ai pas vu plus tôt c'est un sacré boulot et ça aurait bien servi. Merci Le 23/07/2020 à 11:21, cam.lafit a écrit :
Salut
Il existe phpfarm qui permet de faire de l'archéologie/paléontologie. https://github.com/fpoirotte/phpfarm
ça simplifie fortement la compilation et tu peux avoir du php-fpm assez facilement.
C'est ce que j'utilisais avant d'avoir sury et que debian découpe les version php. Sur mes vieux serveurs ça tourne encore :)
Km
Le 21/07/2020 à 18:15, Vincent Tondellier via FRsAG a écrit :
Le Tuesday 21 July 2020 17:33:11 Arnaud Launay a écrit :
J'en ai une rigolote dans l'autre sens: j'ai un client qui a besoin de php *4* pour une appli avant sa migration d'ici la fin de l'année en théorie.
Bon la on est dans le domaine de la paléontologie, plus dans l'archéologie ...
Je ne suis même pas sûr de pouvoir retrouver une etch pour lui faire tourner ça dessus...
Dans les archives debian ca doit se trouver :
deb http://archive.debian.org/debian etch main
et les cds d'install :
https://cdimage.debian.org/cdimage/archive/
https://cdimage.debian.org/cdimage/archive/4.0_r9/amd64/iso-cd/
A l'epoque il ne devait pas y avoir de date d'expiration dans les dépots, sinon il faudra désactiver le check
Sans support de sécurité depuis une décennie, bien entendu ...
Je pars du principe que ça n'existe pas sous buster, on est d'accord ? :)
Non, il n'y a que php 7.3 dans les dépôts officiels ...
Peut etre que ca compile a la main sous buster ... _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (18)
-
Alexandre GRIVEAUX -
Arnaud Launay -
cam.lafit -
Gilles Mocellin -
Gilou -
Guillaume Tournat -
Jean-Yves LENHOF -
Jonathan Leroy - Inikup -
Julien Escario -
Pierre DOLIDON -
Ronan Ducamp -
Rémy Dernat -
Seb Astien -
Stéphane Rivière -
Sébastien Le Ray -
Vincent Tondellier -
Wallace -
Xavier Beaudouin