Re: erreur d'interprétation dxf2gcode
On 15/01/2019 18:37, Bernard Schoenacker wrote: > 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) Tu ne peux pas compiler les sources ? -- Fabien
Re: Partitionnement d'un serveur web
Bonjour, Le mardi 15 janvier 2019, Pascal Hambourg a écrit... > 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 Tiens ? Tu es sûr de ça ? Car j'avais, il y a peu, un noyau perso 4.18.6 sur lequel tournait ma machine. Est survenue la mise à jour (testing) qui a installé 4.19.0 Et, au boot suivant, j'ai été justement un peu surpris de retrouver mon 4.18.6 sur le menu principal et le 4.19 dans le sous-menu. -- jm
Re: N° de version de Freecad 0.17 en testing
Le mercredi 16 janvier 2019 à 22:05 +0100, benoit...@ouvaton.org a écrit : > Bonjour à tous, > > La version stable de Freecad 0.17 est sortie et j'aimerais en profiter > autrement qu'en appImage. > > Cf. > https://www.freecadweb.org/downloads.php > > Comment puis-je savoir si les sources du paquet Freecad 0.17 est bien la > dernière version stable et pas une ancienne version 0.17 de > développement ? > Cf. > https://packages.debian.org/buster/freecad > > Merci d'avance > > -- > Benoit D'après cette page https://tracker.debian.org/news/979514/accepted-freecad-017dfsg1-1-source-all-amd64-into-experimental-experimental/ C'est bien une version 0.17 upstream. Gaëtan signature.asc Description: This is a digitally signed message part
Re: Suppression de /etc/apt/trusted.gpg
Bonsoir, Merci à tous pour vos réponses. Conclusion, je garde trusted.gpg sous la main an cas de problème. Pour l'instant tout fonctionne sans ce fichier. Avec gratitude, -- Benoit Le 2019-01-15 22:09, Étienne Mollier a écrit : 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,
Re: Partitionnement d'un serveur web
Le 16/01/2019 à 10:27, Daniel Caillibaud a écrit : - certains préfèrent mettre le swap en raid1, deux fois moins rapide mais plus sûr, à toi de voir. En ce qui me concerne c'est tout vu : si le système est en redondance, alors tout doit l'être, y compris et surtout le swap. Amha le swap doit rester exceptionnel et doit être le plus rapide possible car la machine souffre déjà quand y'en a besoin, donc deux partitions natives filées au kernel dans /etc/fstab (il fait du raid0), Attention : par défaut, le noyau attribue des priorités décroissantes aux différents swaps et remplit entièrement chaque swap par ordre de priorité. Pour distribuer les allocations entre plusieurs swaps, il faut leur attribuer explicitement la même priorité positive avec l'option --priority de swapon ou prio= de /etc/fstab. avec l'inconvénient que si un disque lâche pendant que l'os utilise le swap ça va crasher le système (et l'avantage que le swap est 2× plus rapide tout le reste du temps). Quand on met de la redondance, ce n'est pas pour la vitesse. C'est pour la disponibilité. Si l'objectif est que le système continue à fonctionner malgré la perte d'un disque, alors un swap sans redondance ne garantit pas cette disponibilité et va à l'encontre de l'objectif. Si l'objectif n'est pas la disponibilité, alors on n'a pas besoin de RAID 1 ni pour le swap ni pour le reste.
N° de version de Freecad 0.17 en testing
Bonjour à tous, La version stable de Freecad 0.17 est sortie et j'aimerais en profiter autrement qu'en appImage. Cf. https://www.freecadweb.org/downloads.php Comment puis-je savoir si les sources du paquet Freecad 0.17 est bien la dernière version stable et pas une ancienne version 0.17 de développement ? Cf. https://packages.debian.org/buster/freecad Merci d'avance -- Benoit
Re: Partitionnement d'un serveur web
Le 16/01/2019 à 14:07, Daniel Caillibaud a écrit : Le 16/01/19 à 11:44, Stephane Ascoet a écrit : Bonjour, parce qu'il est possible de mettre a jour un noyau sans monter de version, hors cas d'une recompilation a la main??? Oui car la version qui compte pour GRUB est la version "visible" présente dans les noms de fichiers de l'image du noyau vmlinuz-$version et de l'initramfs initrd.img-$version (qui sont repris dans grub.cfg), dans la sortie de uname -a pour le noyau actif dans le nom du paquet linux-image-*. Les mises à jour de sécurité du noyau sans changement de l'ABI ne modifient pas cette version. Bien sûr la véritable version source, présente dans la sortie de uname -v pour le noyau actif, change à chaque mise à jour. oui, debian te propose plein de noyaux par ex apt install linux-image-4.9.0-4-grsec-amd64 va t'installer ce noyau (4.9 dans sa version grsec) Si cela installe un nouveau noyau, cela ne correspond pas à une mise à jour d'un noyau existant et il faut exécuter update-grub pour mettre à jour le menu de démarrage et pouvoir démarrer avec ce noyau. Ce n'est pas à ce genre de version, que je qualifie plutôt de variante, que je pensais.
Re: Partitionnement d'un serveur web
Le 16/01/19 à 11:44, Stephane Ascoet a écrit : > Bonjour, parce qu'il est possible de mettre a jour un noyau sans monter > de version, hors cas d'une recompilation a la main??? oui, debian te propose plein de noyaux aptitude search linux-image remonte 62 noyaux chez moi ;-) par ex apt install linux-image-4.9.0-4-grsec-amd64 va t'installer ce noyau (4.9 dans sa version grsec), et par défaut ça devrait être le noyau par défaut pour ton prochain démarrage (suivant ta conf grub et les autres noyaux déjà installés) -- Daniel Il y a deux genre d'avocats : ceux qui connaissent bien la loi, et ceux qui connaissent bien le juge. Coluche
Re: Cockpit/NetworkManager sur un serveur
Bonjour, Pour répondre aux questions : 1. Oui j'ai déjà utilisé Cockpit avec un serveur et une IP fixe. NetworkManager est une dépendance du paquet cockpit-networkmanager, donc oui. 2. Je n'ai pas approfondi, mais dans la mesure ou Cockpit utilise NetworkManager, il va stocker toute sa configuration dans NetworkManager (/etc/NetworkManager). 3. J'ai fini par désinstaller cockpit-networkmanager ainsi que network-manager car j'ai eu des surprise en appliquant des règles de réseau. D'une manière générale, c'est toujours une très mauvaise idée de faire des configurations réseaux d'un serveur à distance (SSH ou Interface Web), car c'est un coup à se couper l'herbe sous les pieds. En conclusion, je ne préconiserais donc pas l'utilisation de Cockpit avec NetworkManager. Pour ma part, je continue à utiliser Cockpit, mais j'ai désinstallé son module Network Manager. Je continue de configurer mon réseau via le paquet ifupdown (dans /etc/network/interfaces) Olivier Le mar. 15 janv. 2019 à 13:09, Olivier a écrit : > 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: Partitionnement d'un serveur web
Le 15/01/2019 à 20:33, Pascal Hambourg a écrit : 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. Bonjour, parce qu'il est possible de mettre a jour un noyau sans monter de version, hors cas d'une recompilation a la main??? -- Cordialement, Stephane Ascoet
Re: Configuration réseau pour un serveur
Le 16/01/19 à 09:50, roger.tar...@free.fr a écrit : > Bonjour > > J'ai lu pas mal de docs sur le sujet. Et aussi sur les groups et users > qui se trouvent toujours présents dans un système Linux. Comme j'en > découvre en permanence, je me dis que je suis loin d'avoir fait le tour ! > > > Je voudrais configurer un serveur Debian absolument minimaliste : > > Est-ce que je peux me limiter à configurer resolv.conf et interfaces et > le vpn et le fw ? (En retirant tout ce qui est NM resolvconf ou autre) je > le crois mais il y a sans doute d'autres détails à considérer Les détails à considérer sont ton usage, je comprend "minimaliste" comme "seulement ce dont j'ai besoin" (certains considèreront que minimaliste => sans vpn ni fw). > Il y a aussi de nombreux groups et users "présents pour des raisons > historiques" (adm, stadf, etc. ) Que suffit-il de conserver là et parmi > d'autres éléments du système ? Je suggérerais : 1) À partir d'une install debian minimale (rien de coché à l'installation, ou une image déjà prête), configurer apt pour ne pas installer les paquets suggérés, voire recommandés, avec par ex un /etc/apt/apt.conf.d/81no_reco_sugg qui contiendrait // on veut pas des recommandés ou suggérés APT::Install-Recommends "0"; APT::Install-Suggests "0"; 2) lister les paquets installés (non auto) aptitude search '~i !~M' et virer tout ce dont on a pas l'usage. Pour en savoir plus sur un paquet : # sa description aptitude show xx # pourquoi il est installé aptitude why xx 3) pour faire maigrir encore le tout, on peut recommencer l'exercice avec tous les paquets (`aptitude search ~i`) pour voir si y'aurait pas des dépendances inutiles installées. Pour avoir la liste complète (ici avec les paquets auto, mettre ~i à la place de ~M pour les avoir tous, auto ou pas) aptitude search ~M -F %p|while read p; do echo -e "\n$p"; aptitude why $p; done note: on peut bien sûr utiliser apt plutôt qu'aptitude, c'est juste que je connais la syntaxe aptitude et mal celle d'apt -- Daniel Lorsque vous posez un caméléon sur du tissu écossais, il vous fait un bras d'honneur. François Cavanna
Re: Partitionnement d'un serveur web
Le 14/01/19 à 06:24, Fabrice Delvallée a écrit : > Bonjour > > > J'ai le projet d'installer un serveur dans mon lycée pour : > > - héberger une plate-forme d'apprentissage en ligne (moodle) > > - créer à la volée des images dockers contenant des notebooks python > > > je partirai sur : > > - 2x256GO SSD en raid1 pour l'os L'OS n'a pas besoin de tout ça, 20Go sont amplement suffisant (modulo rmq suivante). > - 2x1TO SATA en raid1+LVM pour les données Si tu as des dockers, tu as intérêt à avoir ton /var/lib/docker sur ssd. Si c'est la même partition que l'OS il faut ajouter aux 20Go précédents la taille des images (ça peut être gros). Et si tu as des images qui manipulent de gros volumes de données, tu leur monte un volume qui lui est sur le hd sata classique (ssd est aussi en sata en général). Je sais plus trop comment fonctionne docker, s'il peut ne conserver en mémoire qu'une seule version des lib système lorsque les images ont le même système que l'hôte, et si ça change qqchose que les images docker soient sur la même partition que l'OS hôte ou pas. > - 64Go de mémoire > > Je suis un peu perdu pour le partitionnement :( > > faut-il mettre aussi LVM sur les SSD ? J'ai cru comprendre que grub > n'est pas compatible LVM, dans ce cas il me faut une partition /boot D'autres ont déjà répondu, tu as intérêt à tout avoir sur lvm, c'est autrement plus simple si ça doit évoluer (et pas tellement plus compliqué sinon). Je mettrais sur chaque ssd - une partition mdadm pour /boot en raid1 (/dev/md1 par ex), hors lvm donc directement partitionné en ext4 (ou ext2, suffisant pour /boot). Ne pas être trop radin, prévoir quand même ~256Mo min pour pouvoir mettre plusieurs noyaux (j'ai déjà installé avec ~50Mo et regretté ensuite). - une partition pour le swap (taille à voir suivant l'usage, 2×10Go me parait déjà très large, si tu as besoin de plus c'est qu'il y a un pb à régler ailleurs) - le reste dans une partition mdadm en raid1 (/dev/md2 par ex), qui servira de pv pour lvm, que tu pourras donc découper comme tu veux (avec un lv pour /, et d'autres lv pour des datas) et sur les disques classiques un seul volume mdadm en raid1 (/dev/md3 par ex), que tu utilise en pv lvm notes - certains préfèrent mettre le swap en raid1, deux fois moins rapide mais plus sûr, à toi de voir. Amha le swap doit rester exceptionnel et doit être le plus rapide possible car la machine souffre déjà quand y'en a besoin, donc deux partitions natives filées au kernel dans /etc/fstab (il fait du raid0), avec l'inconvénient que si un disque lâche pendant que l'os utilise le swap ça va crasher le système (et l'avantage que le swap est 2× plus rapide tout le reste du temps). - pour mettre lvm en raid1, on utilise souvent un volume mdadm comme pv pour lvm, mais tu peux te passer de mdadm : un pv sur sda et un autre sur sdb, en disant à lvm de gérer le raid1 lors de la création des vg (man vgcreate pour la syntaxe, ça permet d'avoir certains lv en raid1 et d'autres en raid0). - si tu veux chiffrer les partitions (en général on s'en passe sur un serveur web car on préfère qu'il reboot tout seul sans devoir se connecter pour saisir la passphrase), la logique est différente, et ce serait plus logique de mettre le swap dans un volume chiffré aussi. -- Daniel C'est facile d'arrêter de fumer, j'arrête 20 fois par jour! Oscar Wilde
Re: Configuration réseau pour un serveur
Le 16/01/2019 à 09:50, roger.tar...@free.fr a écrit : > Bonjour > > J'ai lu pas mal de docs sur le sujet. Et aussi sur les groups et users qui se > trouvent toujours présents dans un système Linux. > Comme j'en découvre en permanence, je me dis que je suis loin d'avoir fait le > tour ! > > > Je voudrais configurer un serveur Debian absolument minimaliste : > > Est-ce que je peux me limiter à configurer resolv.conf et interfaces et le > vpn et le fw ? (En retirant tout ce qui est NM resolvconf ou autre) > je le crois mais il y a sans doute d'autres détails à considérer Si tu installe une debian minimaliste, tu n'aura même pas NM et resolvconf. ( tasksel avec juste SSH ) > > Il y a aussi de nombreux groups et users "présents pour des raisons > historiques" (adm, stadf, etc. ) > Que suffit-il de conserver là et parmi d'autres éléments du système ? > Ils ne sont pas génants. > Merci > -- EON Vincent http://www.lws.fr -- Siége social: LIGNE WEB SERVICES 4, RUE GALVANI 75017 PARIS - FRANCE --- Ce message et toute pièce jointe sont confidentiels et doivent être protégés contre toute divulgation. Si vous n'êtes pas le destinataire de ce message, merci de téléphoner ou d'envoyer un email à l'expéditeur, et de détruire ce message et toute pièce jointe.
Configuration réseau pour un serveur
Bonjour J'ai lu pas mal de docs sur le sujet. Et aussi sur les groups et users qui se trouvent toujours présents dans un système Linux. Comme j'en découvre en permanence, je me dis que je suis loin d'avoir fait le tour ! Je voudrais configurer un serveur Debian absolument minimaliste : Est-ce que je peux me limiter à configurer resolv.conf et interfaces et le vpn et le fw ? (En retirant tout ce qui est NM resolvconf ou autre) je le crois mais il y a sans doute d'autres détails à considérer Il y a aussi de nombreux groups et users "présents pour des raisons historiques" (adm, stadf, etc. ) Que suffit-il de conserver là et parmi d'autres éléments du système ? Merci
Re: Partitionnement d'un serveur web
Le 15/01/2019 à 20:33, Pascal Hambourg a écrit : >> 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. Merci Pascal pour toutes ces précisions bien utiles. J'avais en tête le souci de la MBR dans laquelle GRUB va se positionner pour démarrer un système. Cependant RAID1 ne duplique pas la MBR d'un disque sur un autre. C'était dans ce cas où la magouille du mécréant que je suis était de lancer un grub-install sur le 2ième disque, sinon celui-ci ne pourrait démarrer seul (en cas de crash du 1ier). Dans ce cas il parait effectivement intéressant d'utiliser ce dpkg-reconfigure comme précédemment cité... yes yes. Gracias signature.asc Description: OpenPGP digital signature
