Re: Suppression de /etc/apt/trusted.gpg
Bonsoir, Jérôme, au 2019-01-15 : > Le lundi 14 janvier 2019 à 21:26 +0100, Étienne Mollier a écrit : > > Toujours aussi naïvement, j'aurais donc tendance à penser que > > l'utilité de ce fichier n'est plus, en tout cas pour une > > installation basique, et que donc vous n'avez pas mal fait. > > > > Gardez tout de même le fichier à portée de main, des fois que... [...] > Ça m'étonnerait qu'il n'y ait pas eu une explication dans la mise a jour, et > un message a root. Tout le problème est de savoir quand c'est apparu. Si ça se trouve, la transition s'est faite silencieusement, entre deux versions stables de Debian, en laissant les anciennes clés expirer dans le fichier trusted.gpg et en incluant les nouvelles dans le répertoire trusted.gpg.d/. La présence de références à Wheezy dans trusted.gpg.d/ laisse à penser qu'une telle transition aurait pu avoir lieu entre Debian 6 et 7, donc quelque part entre 2011 et 2013. À moins d'avoir raté quelque chose, aucune mention de la suppression du trusted.gpg n'est apparue dans les courriels envoyés à root. Confère /usr/share/doc/apt/NEWS.Debian.gz. Du côté de la distribution des paquets, les mécanismes de signature ont apparemment été mis en place fin 2003 avec, si ça se trouve, un support immédiat du fichier trusted.gpg et son homologue en .d. Une entrée probablement intéressante dans le changelog est apparue en 2014, qui laisserait à penser que les fichiers trusted.gpg apparaissaient automatiquement au moins jusqu'en Wheezy: Extrait de /usr/share/doc/apt/changelog.gz : > * only create new trusted.gpg if directory is writeable Les distributions Stretch et Buster n'ont pas ce fichier de clés, au sortir d'une installation fraîche. Pour Jessie, je ne sais plus. Ma perception de la chose est que /etc/apt/trusted.gpg est utilisable, modulo un peu de configuration vis-à-vis de l'utilisateur _apt, mais n'est pas, ou n'est plus, indispensable. À la lecture du manuel de apt-key(8), j'ai l'impression qu'il peut être utile lors de l'ajout de dépôts tiers. Jérôme, au 2019-01-15 : > Le principe des trucs.conf.d c'est de remplacer le fichier de config monobloc > truc.conf par des fichiers qui contiennent les blocs de configuration > nécessaires mis dans le dossier truc.conf.d/ ce qui est plus facile a gérer > pour les configurations dynamiques (au branchement d'un truc...) et évite de > tout charger inutilement. > > Dans ce cas le fichier monobloc de configuration statique est supprimé. > > On peut toujours le remettre ou le trouver dans certains cas, mais l'idée est > là. Par exemple xorg.conf = statique xorg.conf.d/* = dynamique (plug'n > play). C'est mieux de faire un xorg.conf.d/50-ma-souris-gamer.conf qui va se > charger au branchement de ce modèle de souris que de gérer de manière statique > tous les cas dans xorg.conf > > Pour GPG il ne s'agit pas de brancher une souris, mais la gestion dynamique a > son intérêt pour la gestion automatisée. C'est une bonne explication. :^) Pour illustrer le problème de maintenance : devoir ajouter ou retirer une directive au milieu d'un gros fichier monolithique est en moyenne beaucoup plus compliqué que d'effacer un fichier contenant uniquement la directive incriminée, en particulier quant il faut automatiser la chose pour un parc de machine, ou via un paquet. Voici un exemple tiré de la vie réelle : $ dpkg --search /etc/X11/Xsession.d/* dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime libvdpau-va-gl1:amd64, libvdpau-va-gl1:i386: /etc/X11/Xsession.d/20vdpau-va-gl x11-common: /etc/X11/Xsession.d/20x11-common_process-args x11-common: /etc/X11/Xsession.d/30x11-common_xresources x11-common: /etc/X11/Xsession.d/35x11-common_xhost-local boinc-client: /etc/X11/Xsession.d/36x11-common_xhost-boinc x11-common: /etc/X11/Xsession.d/40x11-common_xsessionrc x11-common: /etc/X11/Xsession.d/50x11-common_determine-startup gpg-agent: /etc/X11/Xsession.d/90gpg-agent at-spi2-core: /etc/X11/Xsession.d/90qt-a11y x11-common: /etc/X11/Xsession.d/90x11-common_ssh-agent x11-common: /etc/X11/Xsession.d/99x11-common_start On voit que plein de paquet peuvent ajouter facilement leur petit morceau de configuration, juste avec une copie, au lieu de devoir tout gérer avec x11-common. Et si la purge d'un de ces paquets est effectuée, les risques de casser les sessions graphiques sont minimes, en comparaison avec une manipulation effectuée directement dans /etc/X11/Xsession. Évidemment, cela se fait au prix d'une inflation du nombre des fichiers de configuration. Amicalement, -- Étienne Mollier
Re: Partitionnement d'un serveur web
Le 15/01/2019 à 08:52, Pierre L. a écrit : Humm, j'ai cette impression que la commande update-grub, suite à mise à jour de kernel par exemple, ne mettra à jour que celui sur lequel la machine a booté ? Pas du tout. update-grub se moque bien de savoir quel noyau est mis à jour. Il recense tous les noyaux présents dans /boot et regénère entièrement un nouveau fichier de configuration /boot/grub/grub.cfg incluant ces noyaux. Par défaut depuis GRUB 2.x le noyau de version la plus élevée est dans le menu principal et les autres sont dans un sous-menu "options avancées". Il est possible de revenir au comportement sans sous-menu des versions précédentes (1.9x) en ajoutant l'option suivante dans /etc/default/grub : GRUB_DISABLE_SUBMENU=y En gros, si c'est GRUB2 qui est sur /dev/sda qui a lancé Debian, cette commande ne mettra pas à jour l'amorçage dans /dev/sdb update-grub se contente de générer le fichier de configuration /boot/grub/grub.cfg et se moque bien de savoir sur quel disque est installé le chargeur GRUB qui va le lire. Secundo, l'exécution de grub-install sur d'autres disques lors d'une mise à jour du paquet grub-pc peut être automatisée dans la configuration du paquet avec dpkg-reconfigure. C'est donc ici qu'il serait intéressant de cocher les 2 disques /dev/sda et /dev/sdb afin d'avoir ce GRUB2 qui se mettrait à jour comme tu nous le dis précédemment ? Oui. Et donc sur une installation déjà faite, un dpkg-reconfigure grub-pc pourrait remédier à ce manque et automatiser cette MAJ de GRUB2 sur les 2 disques à chaque update de kernel. Non. Je répète que GRUB n'est pas LILO, il n'est pas nécessaire ni utile de le réinstaller (avec grub-install) à chaque mise à jour de noyau. GRUB ne doit être réinstallé que lors d'une mise à jour des paquets grub-*. C'est le fichier de configuration grub.cfg qu'il faut regénérer (avec update-grub) lorsqu'un noyau est ajouté ou supprimé. En principe ce n'est pas nécessaire en cas de simple mise à jour de noyau, mais les scripts de post-installation du noyau le font quand même.
Re: erreur d'interprétation dxf2gcode
- Mail original - > De: "Hugues MORIN" > À: debian-user-french@lists.debian.org > Cc: "debian" > Envoyé: Mardi 15 Janvier 2019 18:27:44 > Objet: Re: erreur d'interprétation dxf2gcode > Bonsoir > Je ne suis pas specialiste mais je fais occasionnellement quelques > impression 3D > As tu essaye d'exporter ton fichier DXF en STL comme pour les > imprimantes 3D > Et a l'aide de Cura ou Repetier, de le transformer en Gcode. > Il me semble que repetier a des options pour les cnc. > Sinon tu peux aussi regarder du cote de LINXCNC ( > http://linuxcnc.org/ ), c'est une distri complete qui permet de > commande directement une machine CNC. > Cordialement > Hugues Hugh, grand sachem a parlé ! et moi le scarabée j'ai eu une réponse du dev de dxf2gcode qui m'a indiqué que la version debian était obsolète ... par conséquent je suis contraint d'attendre que la nouvelle mouture sorte des cartons en version deb sachant que le dxf de base fournit est correct (librecad) attention, le Gcode est calé pour de la découpe laser pour ce cas ci et non pour de l'usinage ... merci beaucoup pour s'être penché dessus, mais pour l'instant je suis contraint à être au "chômage technique" ... slt bernard
Re: erreur d'interprétation dxf2gcode
Bonsoir Je ne suis pas specialiste mais je fais occasionnellement quelques impression 3D As tu essaye d'exporter ton fichier DXF en STL comme pour les imprimantes 3D Et a l'aide de Cura ou Repetier, de le transformer en Gcode. Il me semble que repetier a des options pour les cnc. Sinon tu peux aussi regarder du cote de LINXCNC (http://linuxcnc.org/), c'est une distri complete qui permet de commande directement une machine CNC. Cordialement Hugues Le lun. 14 janv. 2019 à 19:11, Bernard Schoenacker < bernard.schoenac...@free.fr> a écrit : > bonjour, > > j'ai voulou utiliser un dessin existant et > voici le résultat : > > > Creating configuration window > Creating configuration window > New configuration applied > File: > /home/bernard/Documents/Q-cad/torche-suedoise/grille-torche-suedoise-2.dxf > selected > Loading file: > /home/bernard/Documents/Q-cad/torche-suedoise/grille-torche-suedoise-2.dxf > Reading DXF Structure > Reading Block *Model_Space; Nr: 0 > Reading Block *Paper_Space; Nr: 1 > Reading Block *D16; Nr: 2 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D4; Nr: 3 > Found unsupported geometry type: SOLID ! > Reading Block *D6; Nr: 4 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D2; Nr: 5 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D5; Nr: 6 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D3; Nr: 7 > Found unsupported geometry type: SOLID ! > Reading Block *D19; Nr: 8 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D12; Nr: 9 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D21; Nr: 10 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D23; Nr: 11 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D1; Nr: 12 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D22; Nr: 13 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D11; Nr: 14 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D20; Nr: 15 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D10; Nr: 16 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D8; Nr: 17 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D9; Nr: 18 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D7; Nr: 19 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D13; Nr: 20 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D15; Nr: 21 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D14; Nr: 22 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D18; Nr: 23 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Reading Block *D17; Nr: 24 > Found unsupported geometry type: SOLID ! > Found unsupported geometry type: MTEXT ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: LEADER ! > Found unsupported geometry type: LEADER ! > Found unsupported geometry type: MTEXT ! > Found unsupported geometry type: MTEXT ! > Found unsupported geometry type: MTEXT ! > Found unsupported geometry type: MTEXT ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found unsupported geometry type: DIMENSION ! > Found
Cockpit/NetworkManager sur un serveur
Bonjour, J'ai souvent lu (cf [1]) que l'administration des paramètres réseau d'un serveur devait se faire SANS NetworkManager, en utilisant les fichiers du répertoire /etc/network. Pourtant, je découvre l'existence de Cockpit [2] qui semble s'appuyer sur NetworkManager, si NetworkManager est installé (cf [3]). À cet égard, le paquet cockpit de Buster recommande le paquet cockpit-networkmanager. 1. Avez-vous déjà utilisé Cockpit sur une machine dont l'adresse IP est fixe ? Si oui, avez-vous conjointement installé NetworkManager ? 2. Peut-on facilement retrouver dans /etc/NetworkManager ce qu'on avait dans /etc/network (je pense à /etc/network/if-pre-up.d, ...) ? 3. Que peut apporter (ou retirer) NetworkManager à un serveur ? [1] https://wiki.debian.org/fr/NetworkManager [2] https://cockpit-project.org/ [3] https://cockpit-project.org/guide/latest/feature-networkmanager.html Slts
Re: Gnome-openbox [résolu ?]
- Mail original - > De: "Stephane Ascoet" > À: "debian-user-french" > Envoyé: Mardi 15 Janvier 2019 11:48:41 > Objet: Re: Gnome-openbox [résolu ?] > Le 14/01/2019 à 15:01, Jean Bernon a écrit : > > - la commande "gnome-session --choose-session=openbox-session" est > > obsolète, je l'ai remplacée par "gnome-session > > --session=openbox-gnome" > Ce que je ne comprends pas, c'est que si tu as une version 3, cette > partie de code n'est pas executee. Ce sont justement ces deux blocs > gerant les versions anterieures a "3" qui ont ete retires dans la > version de Buster. Ainsi donc il y a bien des paquets > non-fonctionnels > dans les Debian stables :-( M'enfin ce n'est pas aussi grave que le > noyau bugge de la Etch qui provoquait des pertes de donnees :'-( Tu as raison. J'ai mal interprété le script. Ce changement était inutile. Dans le cas d'une version 3 le script se résume à son avant-dernière ligne "exec gnome-session --session=openbox-gnome"... > > - ensuite la commande gnome-session cherche le fichier > > "openbox.desktop" qu'elle cherche dans divers répertoires, mais > > pas dans les deux où se trouve un fichier de ce nom > > /usr/share/gnome/wm-properties/ et /usr/share/xsessions/. J'ai > > copié tour à tour dans $HOME/.config/autostart chacun des deux > > fichiers qui sont différents et aboutissent au même résultat. > Ces deux fichiers sont justement installes par le paquet semble t-il. Curieux qu'ils soient installés dans des répertoires que gnome-session ignore... > -- > Cordialement, Stephane Ascoet
Re: Gnome-openbox [résolu ?]
Le 14/01/2019 à 15:01, Jean Bernon a écrit : - le script est en sh et le test de la version de gnome installée ne fonctionne pas avec bash (merci à Stéphane Ascoët). J'ai remplacé le test par "VER=3.22.2". Bonjour, le bug ne vient pas d'une difference entre generations de Shells mais d'un code qui ne respecte pas les bonnes pratiques. Il applique sur le numero de version un Sed dont je ne vois pas l'utilite, sans doute une autre vieille survivance. En fait, le script a quasiment ete vide pour Buster. Ce qui signifie que mon depot de bug sera rejete. - la commande "gnome-session --choose-session=openbox-session" est obsolète, je l'ai remplacée par "gnome-session --session=openbox-gnome" Ce que je ne comprends pas, c'est que si tu as une version 3, cette partie de code n'est pas executee. Ce sont justement ces deux blocs gerant les versions anterieures a "3" qui ont ete retires dans la version de Buster. Ainsi donc il y a bien des paquets non-fonctionnels dans les Debian stables :-( M'enfin ce n'est pas aussi grave que le noyau bugge de la Etch qui provoquait des pertes de donnees :'-( - ensuite la commande gnome-session cherche le fichier "openbox.desktop" qu'elle cherche dans divers répertoires, mais pas dans les deux où se trouve un fichier de ce nom /usr/share/gnome/wm-properties/ et /usr/share/xsessions/. J'ai copié tour à tour dans $HOME/.config/autostart chacun des deux fichiers qui sont différents et aboutissent au même résultat. Ces deux fichiers sont justement installes par le paquet semble t-il. -- Cordialement, Stephane Ascoet
Re: Partitionnement d'un serveur web
"dpkg-reconfigure grub-pc" merci c'est juste parfait Le mar. 15 janv. 2019 à 10:55, Florian Blanc a écrit : > ah yes my /boot is in raid1 sorry :/ > > root@ams1:/home/panpansh# lsblk > NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT > loop0 7:00 100G 0 loop > loop1 7:1030G 0 loop > loop2 7:2030G 0 loop > loop3 7:3030G 0 loop > loop4 7:40 100G 0 loop > sda 8:00 477G 0 disk > ├─sda18:10 299M 0 part > │ └─md0 9:00 298.7M 0 raid1 /boot > ├─sda28:20 3.8G 0 part > │ └─md1 9:10 3.8G 0 raid1 > │ └─md1_crypt 253:10 3.8G 0 crypt [SWAP] > └─sda38:30 472.9G 0 part > └─md2 9:20 472.7G 0 raid1 > └─md2_crypt 253:00 472.7G 0 crypt / > sdb 8:16 0 477G 0 disk > ├─sdb18:17 0 299M 0 part > │ └─md0 9:00 298.7M 0 raid1 /boot > ├─sdb28:18 0 3.8G 0 part > │ └─md1 9:10 3.8G 0 raid1 > │ └─md1_crypt 253:10 3.8G 0 crypt [SWAP] > └─sdb38:19 0 472.9G 0 part > └─md2 9:20 472.7G 0 raid1 > └─md2_crypt 253:00 472.7G 0 crypt / > > I have a small buffer :p > > Le mar. 15 janv. 2019 à 09:44, Pierre L. a > écrit : > >> Oui effectivement, c'était sous-entendu dans mes propos ! >> Un /boot en miroir devra être identique sur chaque disque. >> >> La vision dans sa globalité est donc celle-ci, à noter donc ! >> >> Oui j'avais un vague souvenir que la chose qui pouvait poser problème en >> RAID1 était justement l'amorçage, ici géré par GRUB, car les secteurs >> d'amorce ne sont pas en miroir... et c'est bien la seule chose qui n'est >> pas "dupliquée"... >> >> >> Le 15/01/2019 à 09:06, Daniel Huhardeaux a écrit : >> > Ce que tu dis est vrai si /boot *est* en Raid. >> >> >>
Re: Partitionnement d'un serveur web
ah yes my /boot is in raid1 sorry :/ root@ams1:/home/panpansh# lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:00 100G 0 loop loop1 7:1030G 0 loop loop2 7:2030G 0 loop loop3 7:3030G 0 loop loop4 7:40 100G 0 loop sda 8:00 477G 0 disk ├─sda18:10 299M 0 part │ └─md0 9:00 298.7M 0 raid1 /boot ├─sda28:20 3.8G 0 part │ └─md1 9:10 3.8G 0 raid1 │ └─md1_crypt 253:10 3.8G 0 crypt [SWAP] └─sda38:30 472.9G 0 part └─md2 9:20 472.7G 0 raid1 └─md2_crypt 253:00 472.7G 0 crypt / sdb 8:16 0 477G 0 disk ├─sdb18:17 0 299M 0 part │ └─md0 9:00 298.7M 0 raid1 /boot ├─sdb28:18 0 3.8G 0 part │ └─md1 9:10 3.8G 0 raid1 │ └─md1_crypt 253:10 3.8G 0 crypt [SWAP] └─sdb38:19 0 472.9G 0 part └─md2 9:20 472.7G 0 raid1 └─md2_crypt 253:00 472.7G 0 crypt / I have a small buffer :p Le mar. 15 janv. 2019 à 09:44, Pierre L. a écrit : > Oui effectivement, c'était sous-entendu dans mes propos ! > Un /boot en miroir devra être identique sur chaque disque. > > La vision dans sa globalité est donc celle-ci, à noter donc ! > > Oui j'avais un vague souvenir que la chose qui pouvait poser problème en > RAID1 était justement l'amorçage, ici géré par GRUB, car les secteurs > d'amorce ne sont pas en miroir... et c'est bien la seule chose qui n'est > pas "dupliquée"... > > > Le 15/01/2019 à 09:06, Daniel Huhardeaux a écrit : > > Ce que tu dis est vrai si /boot *est* en Raid. > > >
Re: Partitionnement d'un serveur web
Oui effectivement, c'était sous-entendu dans mes propos ! Un /boot en miroir devra être identique sur chaque disque. La vision dans sa globalité est donc celle-ci, à noter donc ! Oui j'avais un vague souvenir que la chose qui pouvait poser problème en RAID1 était justement l'amorçage, ici géré par GRUB, car les secteurs d'amorce ne sont pas en miroir... et c'est bien la seule chose qui n'est pas "dupliquée"... Le 15/01/2019 à 09:06, Daniel Huhardeaux a écrit : > Ce que tu dis est vrai si /boot *est* en Raid. signature.asc Description: OpenPGP digital signature
Re: Partitionnement d'un serveur web
Le 15/01/2019 à 08:52, Pierre L. a écrit : [...] Bonjour à tous, Secundo, l'exécution de grub-install sur d'autres disques lors d'une mise à jour du paquet grub-pc peut être automatisée dans la configuration du paquet avec dpkg-reconfigure. C'est donc ici qu'il serait intéressant de cocher les 2 disques /dev/sda et /dev/sdb afin d'avoir ce GRUB2 qui se mettrait à jour comme tu nous le dis précédemment ? (première image trouvée sur le net... histoire d'illustrer) https://manual.siduction.org/static/images-common/images-grub2/grub2-convert-1.png Et donc sur une installation déjà faite, un dpkg-reconfigure grub-pc pourrait remédier à ce manque et automatiser cette MAJ de GRUB2 sur les 2 disques à chaque update de kernel. Humm humm, c'est bon ca ! (si j'ai bien compris le principe ?) Sauf que le point crucial qu'a indiqué Pascal est que grub a besoin du fichier de config qui est dans /boot. Si cette partition est sur /dev/sda et non /dev/sdb (pas de Raid) tu as beau mettre ce que tu veux sur /dev/sdb il ne démarrera pas si /dev/sda est absent. Ce que tu dis est vrai si /boot *est* en Raid. -- Daniel
