Re: monter un disque dur externe en ntfs
Bonsoir, Bernard Schoenacker : > j'ai déjà installé ntfs-3g et c'est root qui arrive à le > monter en ligne de commande, mais là je recherche la solution > pour pouvoir le faire à la souris en cliquant sur le volume > ... Apparemment, le mécano de montage de disques intégré à Thunar, l'explorateur de fichiers d'Xfce, permet de faire cette manipulation, modulo la présence du paquet "ntfs-3g", sans avoir besoin de passer en mode administrateur. La partition est bien accessible en lecture et écriture en un clic. Ceci étant, je suis en Debian Sid, donc peut-être que le comportement a changé depuis la sortie de Stretch. Amicalement, -- Étienne Mollier
Re: Commande sur l'instence du shell qui appelé un script
Bonjour, Benoit B : > Je recherche une méthod générale pour qu'une commande > s'applique à l'instance du shell qui a lancé le script... J'essaie de reformuler : vous voulez que l'exécution d'un script se fasse au sein du shell appelant ce script, un peu comme si les commandes du dit script étaient dans la continuité de la session de travail dans le shell plutôt que dans un processus fils. Vous cherchez probablement la commande ".", ou "source" : $ . monscript ou : $ source monscript C'est une pratique toutefois peu recommandable car le contenu de "monscript" doit impérativement correspondre au shell appelant. Si vous souhaitez changer de shell pour une raison quelconque, il faudra réécrire tous les scripts que vous sourcez pour les porter sur le nouveau shell : admettons que vous souhaitiez passer au Z-shell, peut-être que la commande de nettoyage de l'historique des commandes ne sera pas la même. "source" est une commande "built-in", donc en bash l'aide est accessible via le manuel de bash, ou la commande: $ help source > Je ne sais pas si ma question est bien formulée... Si j'ai répondu à côté de la plaque, c'est que ce n'était peut-être pas le cas. :-) Amicalement, -- Étienne Mollier
Re: freeze de l'affichage
Bonjour, F. Dubois : > Si le bug nvidia-driver a l'air réglé avec le passage à une > nouvelle version, cela ne change rien pour moi, j'ai toujours > un écran vide (pas noir mais comme plutôt gris, on dirait que > xorg se lance mais sans rien afficher) au lieu de gdm au > démarrage avec nvidia-driver. Les dernières versions de gdm3 et gnome ne semblent pas bien se marier avec le pilote non libre nvidia. En Stretch déjà, j'ai eu quelques expériences similaires. Faute d'une meilleure idée, est-ce que passer de gdm3 à lightdm, et de gnome à xfce, aiderait à avoir une interface graphique à nouveau opérationnelle ? > Lorsque je vais sur internet, l'écran se fige, je ne peux même > plus basculer sur une console texte, plus rien ne répond pas > même le clavier. Cela n'arrive que dans certaines situations ; > à priori d'après mes constatations c'est lorsque que je veux > me connecter avec identification sur certains sites (notamment > ebay...). Au début je pensais à un problème de firefox, j'ai > fait un peu de ménage, effacer mes mdp enregistrés... Pas > d'amélioration. Avez-vous essayé de couper l'accélération matérielle dans les préférences du navigateur ? Peut-être qu'une instruction envoyée au pilote nouveau est très mal digérée, provoquant un panic... Si ça vient bien de l'accélération matérielle, alors ça vaudrait peut-être le coup de rapporter le bug auprès de nouveau. > Je précise que j'ai installé flash 30 à la main, en copiant > libflashplayer.so dans le répertoire plugins ; je ne vois pas > le problème provenir de là puisque je procède ainsi depuis > longtemps. On n'est pas à l'abri d'un jour qui ne soit pas fait comme les autres. Y a-t-il un changement si la bibliothèque n'est pas présente dans le répertoire des greffons ? Amicalement, -- Étienne Mollier
Re: convertir un odt en markdown
On 08/02/2018 07:15 PM, Bernard Schoenacker wrote: > je recherche une solution pour convertir un document > "texte" (*.odt) en markdown > > comment le faire en ligne de commande Bonjour Bernard, Regarde du côté de "pandoc". Je l'ai vu à l'œuvre pour de la conversion TeX/HTML, et il gère une quantité impressionnante de formats. J'imagine qu'une commande de cet ordre ferait l'affaire $ pandoc -f odt -t markdown texte.odt > texte.md Amicalement, -- Étienne Mollier
Re: bash: initialiser environnement particulier
Bonjour,
Jérémy Prego, par un beau matin d'été :
> j'aimerai parfois lancer un bash avec d'autres variables que
> celle défini par défaut par exemple au lancement d'un bash,
> exporter la variable http_proxy ou encore la variable TZ. par
> contre, faut que se soit juste sur le bash que j'ai choisi.
> j'ai bien essayé de mettre des arguments au lancement de bash
> par exemple, /bin/bash && export
> http_proxy=xx.xx.xx.x.xx:3128/ mais ça ne semble pas
> fonctionné comme ça.
>
> faut-il que je crée un fichier d'initialisation bash
> alternatif et appelé ce fichier au lancement de mon bash
> particulier ?
Il y a tout plein de façons de faire. Typiquement, vous pouvez
stocker les variables dans un fichier "~/.proxy.env" avec le
contenu suivant :
# Mon proxy
export http_proxy="http://www.example.org:3128";
export https_proxy="${http_proxy}"
echo "Proxy ${http_proxy} actif"
Fichier que vous pouvez ensuite charger dans votre session Bash
courante avec la commande "source" :
$ source ~/.proxy.env
Proxy http://www.example.org:3128 actif
$ echo $http_proxy
http://www.example.org:3128
Mais je ferais probablement différemment, abuser de "source"
peut entraîner des complications le jour où on voudrait changer
de shell.
> comment feriez vous ? :)
J'appellerais un shell dans une session particulière via un
script dont la première partie est de régler l'environnement, et
la seconde est d'appeler le shell, qui héritera de ces variables
avec leurs valeurs. En admettant que le script en question soit
"~/bin/bashweb" et que "~/bin" soit dans votre path, le contenu
serait :
#! /bin/bash
set -e
# mon proxy
export http_proxy="http://www.example.org:3128";
export https_proxy="${http_proxy}"
# affichage du témoin d'activité
PS1="[proxy actif] ${PS1}"
# passer les arguments et laisser la main à la session
# de shell Bash interactive
exec bash "$@"
Je lancerais "bashweb" et j'aurais une session dédiée aux
activités nécessitant un accès au web, que je pourrais quitter
pour revenir en mode normal simplement en tapant "exit" :
$ env | grep http
$ bashweb
[proxy actif] $ env | grep http
https_proxy=http://www.example.org:3128
http_proxy=http://www.example.org:3128
[proxy actif] $ exit
$ env | grep http
$ _
Notez, le bricolage avec le prompt fonctionne tant que la
variable PS1 n'est pas écrasée dans "~/.bashrc".
Ce qui est bien, c'est que vous pouvez lancer n'importe quoi
dans votre script et pas seulement Bash ; par exemple il est
possible de lancer une session Octave, un navigateur, une « Wine
bottle », n'importe quel programme qui tire une partie de sa
configuration depuis les variables d'environnement.
Attention a ce que le script ne s'appelle pas accidentellement
lui-même, sinon Bash va boucler, en redémarrant le dit script
indéfiniment.
Sinon, ces genres de petits raccourcis restent envisageable :
alias set-proxy='
export http_proxy="http://www.example.org:3128";
export https_proxy="http://www.example.org:3128";
'
alias unset-proxy='
unset http_proxy https_proxy
'
> debian testing.
Debian Sid... ;)
Amicalement,
--
Étienne Mollier
Re: Lancer Emacs en Buster sous un terminal graphique
Bonjour, MENGUAL Jean-Philippe : > Je lance Emaacs sous X. Mais il persiste à vouloir se lancer > dans une fenêtre X et avec une interface graphique. Pour > pallier ça, je dois utiliser l'option -nw. Vous savez si je > peux faire autrement (à savoir, ne rien taper du tout)? Je ne suis pas utilisateur d'Emacs, mais il me semble qu'en installant seulement le paquet "emacs-nox" (No X) et ses dépendances, vous devriez arriver à vos fins. Vim a un paquet du même tonneau. Amicalement, -- Étienne Mollier
Re: PATH
Bonsoir, Debian Sid ici aussi, mais pas de problème pour installer des paquets via "sudo apt ...", ou "su -" suivi de "apt ...". Klaus , dans un premier message : > Note : la variable PATH du superutilisateur doit normalement > contenir /usr/local/sbin, /usr/sbin et /sbin Klaus , dans un second message : > bash trouve et exécute /sbin/ldconfig et > /sbin/start-stop-daemon, mais pas ldconfig et > start-stop-daemon tout court. Jérémy Prego , en réponse : > j'ai eu ça aussi sur ma testing, mais en utilisant "su" pour > passer en root. Est-ce que la variable PATH contient bien lesdits chemins ? Pour vérifier ça, en partant du principe que vous travaillez avec "sudo" et "apt" : $ sudo bash -c 'echo "$PATH"' ou avec "su -" : $ su - Password: # echo "$PATH" Les chemins en question doivent apparaître dans la liste dans les deux cas. Attention : évitez d'utiliser "su" sans l'option "-", ou "-l", ou "--login" ; vous conservez votre environnement utilisateur, qui ne comporte pas de répertoire */sbin/, en temps normal. Amicalement, -- Étienne Mollier
Re: PATH
Léger erratum, je me suis un peu avancé sur le comportement de "su", il n'a pas toujours été ainsi. > Attention : évitez d'utiliser "su" sans l'option "-", ou "-l", > ou "--login" ; vous conservez *désormais intégralement* votre > environnement utilisateur, qui ne comporte pas de répertoire > */sbin/, en temps normal. Apparemment, il y a eu un changement récent d'implémentation de "su", qui vient désormais du paquet "util-linux". Je me disais bien que j'avais lu un texte à ce sujet quelque part. « Le 'su' nouveau (sans arguments, en préservant l'environnement) conserve également le PATH et IFS, tandis que l'ancien su remettait toujours PATH et IFS à zéro, même en mode 'preserve environment'. » Le message original dans le fichier debian/util-linux/NEWS du code source d'util-linux, tel qu'obtenu via "apt source util-linux", contenait ceci : Andreas Henriksson Fri, 03 Aug 2018 10:52:22 +0200 : > - new 'su' (with no args, i.e. when preserving the > environment) also preserves PATH and IFS, while old su > would always reset PATH and IFS even in 'preserve > environment' mode. En espérant que ce soit informatif, Amicalement, -- Étienne Mollier
Re: installation de mastodon
Bonjour, Bernard Schoenacker : > j'ai essayé d'installer mastodon en suivant le tuto suivant et > je me suis pris les pieds dans le tapis (pebKac for me ?): > https://angristan.fr/installer-instance-mastodon-debian-8/ > > instruction bloquante : bundle exec rake secret C'est typographié curieusement (l'auteur a introduit deux blocs de texte distincts entre l'environnement et le reste de la commande), mais à la lecture du tutoriel, il semblerait que la commande à exécuter soit : RAILS_ENV=production bundle exec rake secret Ou, exprimé autrement : export RAILS_ENV=production bundle exec rake secret unset RAILS_ENV Je ne peux pas certifier que le problème vienne de là, mais quelqu'un s'est pris les pieds dans le tapis de la même manière en commentaire du tuto, une solution du même ordre a été proposée en réponse. > ça me génère une série d'erreur et désolé je n'ai pas pu > continuer et je n'ai pas conservé les logs Si le problème ne se résout pas avec la solution proposée, sans plus d'informations vis à vis de l'exécution de `bundle` (sortie standard, code d'erreurs, journaux. etc), ça va être bien compliqué de dépanner... :-( Amicalement, -- Étienne Mollier
Re: bizarrerie libreoffice-calc
Bonjour, Jean-Michel OLTRA : > Il y a 2 jours, j'édite une feuille de calcul existante et > tout va bien. > > Hier je tente d'ouvrir ce document, et j'ai "Erreur > d'entrée/sortie". Impossible d'ouvrir quelque document > "Classeur" .ods que ce soit. Je cherche avec strace, et rien. J'espère me tromper, mais "Erreur d'entrée/sortie", "I/O Error" en langue C.UTF-8, a une forte odeur de disque fatigué. > Ce matin, je me penche de nouveau sur le problème, et je > remarque que, au niveau du tableau de bord de LibreOffice, je > ne peux pas créer de document Classeur. Je regarde si j'ai > calc, et je ne l'ai pas ! Donc j'installe libreoffice-calc et > je peux de nouveau accéder à mes feuilles de calcul. > > Ça fait un peu le neu-neu, tout ça. Mais je n'ai jamais > désinstallé libreoffice-calc, et la seule ligne dans les logs > d'aptitude où je le vois c'est un upgrade du 2 septembre. C'est comme s'il avait disparu du disque. Est-ce que le paquet était toujours référencé par APT comme « installé » avant de procéder à la réinstallation ? Ou bien est ce que la réinstallation a nécessité de redéployer la suite complète ? Par acquis de conscience, pourriez-vous vérifier l'état du disque qui héberge votre système, via le contrôleur Smart, en admettant que ce soit le fichier bloc /dev/sdx : sudo smartctl -a /dev/sdx Installez le paquet « smartmontools » si la commande est manquante. > Une idée ? Je subodore que l'erreur est encore entre la chaise > et le clavier, mais je ne vois pas quelle c…ie j'ai pu faire ! Espérons que ce soit une effectivement juste une clownerie, mais pour le moment, on dirait plutôt qu'un secteur du disque servant à stocker une partie du programme LibreOffice Calc a sauté, emportant le logiciel de tableur avec lui. Si LibreOffice n'était plus référencé comme « installé », peut-être que le paquet a simplement sauté par un jeu de conflits quelconque, résolu à la dernière réinstallation. Amicalement, -- Étienne Mollier
Re: apt vs apt-get
On 10/14/18 12:35 PM, Pierre L. wrote: > Bonjour, Bonjour, > je viens de tester la commande "apt" pour installer mes MAJ via ssh, et > j'aperçois une barre de progression située en bas de la fenêtre de > commandes, ce que je trouve assez sympa comparé à "apt-get" qui n'a pas > cette feature. N'est-il pas? :-) > Après une petite lecture sur un wiki, je ne vois pas de souci à utiliser > "apt" à la place de "apt-get" tout le temps désormais, une vieille > habitude depuis le début... > Celà ne risque pas de poser de soucis sur des systèmes qui n'ont connu > que des installs et autres maintenance par "apt-get" ? Si j'ai bien compris le principe, « apt » est une commande frontale à « apt-get ». Pour tout ce qui est activité d'installation interactive, pas de problème donc. Si toutefois vous utilisez cette commande dans des scripts, il reste recommandé d'utiliser « apt-get » et « apt-cache », car la façon d'appeler la commande « apt » n'est pas encore fixée. > Merci d'avance! > Bon dimanche. Bon dimanche à vous aussi! Amicalement, -- Étienne Mollier
Re: apt vs apt-get
> j'avais cru comprendre que apt était une commande interactive. > > En réalité, si je tape "apt", j'obtiens: > > apt 1.6.1 (i386) > Usage: apt [options] command [...] On dirait que je me suis mal exprimé. « apt » est destinée à être utilisée directement en ligne de commande. Il vaut mieux s'en tenir à « apt-get » pour les scripts car les appels n'ont pas vocation à changer. « interactif » était un choix de mot malheureux de ma part; le premier terme qui me vient à l'esprit est « front-end ». « aptitude » est bien une commande interactive, par contraste. > De plus, apt me donne des résultats incohérents: Curieux, est-ce que « apt-get » donne les même résultats? Et « aptitude »? -- Étienne Mollier
Re: apt vs apt-get
Pierre Frenkiel, le 2018-10-14: > Etienne Mollier, le 2018-10-14: > > Pierre Frenkiel, le 2018-10-14: > > > De plus, apt me donne des résultats incohérents: > > > > Curieux, est-ce que « apt-get » donne les même résultats? > > même chose avec apt-get. Quelque part, c'est rassurant, le résultat des deux commandes est censé être le même. > > Et « aptitude »? > > Je l'utilisait jusqu'à présent, mais maintenant il se plante, > avec > what(): std::bad_alloc > peut-être à cause du trop grand nombre de packets (je ne > l'avais pas lancé depuis plusieurs mois) > Je reviens donc à "apt-get dist-upgrade" > Je verrai une fois l'upgrade terminé À voir à la fin de l'upgrade alors... Si vous avez l'habitude d'aptitude, peut-être que vous devriez rester sur cette commande. J'ai lu ici et là, que les deux gestionnaires de paquets ne se mélangeaient pas forcément très bien; probablement une histoire d'informations d'état, qui ne sont peut-être pas les même entre les deux outils. Amicalement, -- Étienne Mollier
Re: Le système essaye de monter les partitions étendues
Bonjour, On 10/30/18 2:56 PM, Artur wrote: > /dev/sda4 37058560 1953515519 1916456960 913,9G f W95 Ext'd (LBA) Je ne sais pas si c'est très significatif, mais la première partition étendue que j'ai pu trouver sur mes disques a un numéro magique différent. D'après `fdisk` : /dev/sda4 1024004094 1953523711 929519618 443.2G 5 Extended Peut-être que ça vient de différents outils de partitionnement ? > Une idée pourquoi le système essaye de monter sda4/sdb4 ? Une idée en l'air: est ce que ça pourrait venir du mécanisme de montage automatique de disque fourni par l'éventuel environnement de bureau de la machine ? (thunar-volman, gvfs, et consort) Normalement c'est prévu pour les disques externes et clés USB, mais s'il détecte ces partitions étendues comme étant /inutilisés/, alors peut-être que le mécano en devient tout confus. En espérant amener un peu d'eau au moulin, Amicalement, -- Étienne Mollier
Re: swrast alors !
Txo, le 2018-11-09: > Bonjour, Bonsoir, > j’ai acheté une geforce gt710 premier prix histoire d'avoir > une image. > [...] > J'ai donc installé nvidia-driver avec dkms pour suivre l'avis courant. > J'ai bien une image mais visiblement sans accélération. Naïvement, pas d'incompatibilité en vue. la carte GT710 a l'air toujours maintenue par le fabricant. Peut-être que le pilote a besoin d'être un peu "poussé"... Juste pour se situer, quels sont les niveaux de noyau et nvidia ciblé ? $ uname -r $ dpkg -l | grep nvidia Est-ce que le fichier de Xorg /etc/X11/xorg.conf est bien absent ? Si non, est-ce que la configuration pointe bien sur la GT710 ? Que pense Linux du module "nvidia" ? (si dans la liste des modules chargés, drm n'utilise pas nvidia, ou n'apparait pas tout court, ce n'est pas bon) $ lsmod | grep drm Qu'en pense DKMS ? (si le module n'est pas reconnu comme installé, ce n'est probablement pas bon non plus) $ sudo dkms status > glxinfo > name of display: :0 > libGL error: failed to load driver: swrast > libGL error: Try again with LIBGL_DEBUG=verbose for more details. > X Error of failed request: BadValue (integer parameter out of range for > operation) > Major opcode of failed request: 154 (GLX) > Minor opcode of failed request: 3 (X_GLXCreateContext) > Value in failed request: 0x0 > Serial number of failed request: 27 > Current serial number in output stream: 30 > > pourtant il y a bien un swrast_dri.so dans /usr/lib/i386-linux-gnu/dri/ Ce "swrast" me chiffonne, le module noyau devrait être sobrement intitulé "nvidia", mais peut-être que je me mélange les pinceaux avec les bibliothèques... Amicalement, -- Étienne Mollier
Re: swrast alors !
Pascal, le 2018-11-09 : > Le 09/11/2018 à 19:32, Txo a écrit : > > > > j’ai acheté une geforce gt710 premier prix histoire d'avoir > > une image. L'avis général étant qu'il vaut mieux Nvidia > > qu'AMD. > > Selon quels critères ? > Ça date peut-être un peu, mais j'en étais resté à : > - si on refuse les pilotes et firmwares non libres, il vaut > mieux Nvidia avec le pilote nouveau, ou Intel mais la > performance est minimale ; J'ai des souvenirs d'avoir vu "nouveau" faire des choses assez curieuses avec la démo "glxgears" en Debian 7 sur des Quadro FX. Plus récemment, il a eu une certaine tendance à me geler des écrans dès le chargement par le noyau (même pas eu besoin de lancer X), l'affaire a fini en "modprobe.blacklist=nouveau" aux options passées au noyau dans Grub... Ceci dit, quand on sait comme est développé "nouveau", produit par rétro-ingénierie, voir des applications OpenGL démarrer avec devient une réelle source d'émerveillement. Mes compliments à l'équipe en charge de ce module! Sinon, en faisant le choix des puces Intel, ça ne fait pas beaucoup de variété sur la carte mère... on aime ou on n'aime pas... > - si on accepte les firmwares non libres, il vaut mieux > AMD/ATI avec le pilote radeon/amdgpu et les firmwares non > libres pour une performance moyenne ; J'aurais bien un avis très positif sur la question, mais en tant qu'utilisateur de la même carte depuis bientôt dix ans, mon avis ne sera ni très à jour, ni très impartial... La fin du vieux pilote propriétaire "fglrx" en 2015 a été une expérience curieuse, mais la transition vers "radeon" était plus que bienvenue ; certaines démos techniques d'ASD se sont mises à fonctionner correctement comme par enchantement. :-) > - si on recherche la meilleure performance, il vaut mieux > Nvidia avec le pilote propriétaire. Leur pilote donne l'impression d'être plus abouti, plus stable, en plus des performances. La procédure d'installation qui implique (au moins par défaut avec leur installeur) de devoir arrêter le serveur X a un côté particulièrement agaçant... > > J'ai donc installé nvidia-driver avec dkms pour suivre > > l'avis courant. > > Il me semble déceler une incohérence dans ces choix : une > carte graphique d'entrée de gamme et pas d'impératif de > performance d'un côté, et le pilote propriétaire dont > l'intérêt majeur est la performance de l'autre. L'état de l'accélération graphique libre n'est pas fabuleux aujourd'hui. Peut-être que "nouveau" n'est pas une option dans ce cas ? :-( Amicalement, -- Étienne Mollier
Re: swrast alors !
Txo, au 2018-11-09 : > Le 09/11/2018 à 20:28, Étienne Mollier a écrit : > > $ uname -r > > 4.18.0-2-amd64 > > > $ dpkg -l | grep nvidia > ii glx-alternative-nvidia0.8.8 amd64 allows the selection of NVIDIA as > GLX provider > [...] > ii xserver-xorg-video-nvidia390.87-2 amd64NVIDIA binary Xorg driver > > Ouf, quelle tartine ! Oui, il y a du monde, il y a même un ancien paquet non purgé nvidia-libopencl1 provenant du pilote 304.88-6, mais je ne crois pas que ça interfère. J'imagine que la machine a été redémarrée depuis la désinstallation du 304 puis l'installation du 390 ? > > Est-ce que le fichier de Xorg /etc/X11/xorg.conf est bien > > absent ? Si non, est-ce que la configuration pointe bien > > sur la GT710 ? > > Pas d'xorg À tout hasard, en engendrer un avec nvidia-xconfig ferait-il une différence ? Si non, enlevez le fichier après test, pour éviter toute interférence malvenue dans le futur. > > $ lsmod | grep drm > > nvidia_drm 45056 1 > drm_kms_helper196608 1 nvidia_drm > drm 471040 4 drm_kms_helper,nvidia_drm > nvidia_modeset 1110016 3 nvidia_drm > > $ sudo dkms status > > nvidia-current, 390.87, 4.18.0-2-amd64, x86_64: installed Vu de loin, il ne manque rien. Et pourtant: > glxinfo > name of display: :0 > libGL error: failed to load driver: swrast > libGL error: Try again with LIBGL_DEBUG=verbose for more details. > X Error of failed request: BadValue (integer parameter out of range for > operation) > Major opcode of failed request: 154 (GLX) > Minor opcode of failed request: 3 (X_GLXCreateContext) > Value in failed request: 0x0 > Serial number of failed request: 27 > Current serial number in output stream: 30 > > pourtant il y a bien un swrast_dri.so dans /usr/lib/i386-linux-gnu/dri/ C'est perplexant... Après installation du paquet "nvidia-smi", est-ce que la commande suivante détecte le pilote, la carte, et montre que Xorg tourne bien en utilisant la carte pour l'accélération graphique ? $ nvidia-smi Amicalement, -- Étienne Mollier
Re: swrast alors !
Bonjour, Txo, au 2018-11-10 : > Le 10/11/2018 à 00:00, Étienne Mollier a écrit : > > C'est perplexant... > > J'aurais été plus grossier … Moi aussi, mais nous sommes sur une liste publique. :-) > > > Pas d'xorg > > > > À tout hasard, en engendrer un avec nvidia-xconfig ferait-il une > > différence ? Si non, enlevez le fichier après test, pour éviter > > toute interférence malvenue dans le futur. > > J'essaie ça cette après-midi dès mon retour. Au regard de la sortie de nvidia-smi, je ne suis pas sur que ça fasse une différence après tout, mais à tester néanmoins. Voir ci-après: > $ nvidia-smi > Sat Nov 10 06:44:55 2018 > +-+ > | NVIDIA-SMI 390.87 Driver Version: 390.87 > | > |---+--+--+ > | GPU NamePersistence-M| Bus-IdDisp.A | Volatile Uncorr. ECC > | > | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. > | > |===+==+==| > | 0 GeForce GT 710 Off | :08:00.0 N/A | N/A > | > | 50% 33CP8N/A / N/A | 88MiB / 980MiB | N/A Default > | > +---+--+--+ D'après la consommation de mémoire graphique, Xorg fait probablement usage de la carte. J'insiste sur le /probablement/ parce que : > +-+ > | Processes: GPU Memory > | > | GPU PID Type Process name Usage > | > |=| > |0Not Supported > | > +-+ Désolé, j'avais oublié que le pilote NVidia empêchait le fonctionnement de ce rapport d'utilisation sur leurs cartes grand public. Si tout allait bien, je m'attendais à voir "/usr/lib/xorg/Xorg" à la place de "Not Supported". Ou alors "No processes" dans les cas où ça coince... Gaëtan Perrier, le 2018-11-10 : > Je crois que c'est un problème avec les libGL* > Peut-être une alternative mal réglée. Vu les symptômes c'est très possible. Peut-être qu'une purge, un reboot, une réinstall, et un reboot, des paquets relatifs au pilote privateur NVidia ferait une différence. C'est du brut de fonderie, mais un homme sage a dit un jour que la force brute était une solution acceptable en informatique. C'est un peu frustrant de ne pas savoir... Du côté du fourbi AMD, les seuls composants utilisés à ma connaissance sont firmware-amd-graphics, et les modules noyaux intégrés nativement dans Linux pour Debian (radeon ou amdgpu dépendant des cartes). À part les firmwares, je vois mal quoi éjecter pour faire le ménage ; à moins qu'un installation de amdgpu-pro traîne sur la machine, au quel cas, effectivement, il y a du bazar. En espérant que ça aide un peu, Amicalement, -- Étienne Mollier
Re: emacs (GTK) Problème accès distant via x2go
Bonsoir, Roger Tarani, au 2018-11-13 : > J'accède graphiquement avec x2go (sorte de VNC sous ssh) à une > machine Debian 8 depuis une machine Debian 9. > Tout va bien SAUF quand je lance emacs 26.1 (ou 24.5.1 du > dépôt Debian), sur la machine accédée : > Emacs est arrêté dès que le pointeur de la souris arrive sur > sa fenêtre, sans aucun message d'erreur. [...] > Comment corriger cela tout en continuant d'utiliser un Emacs > normal de la distribution Debian ? Apparemment, il y a un paquet emacs-lucid qui n'utilise pas GTK3. Ça devrait faire une différence, sans pour autant basculer sur le paquet emacs-nox, dédié aux interfaces texte seul. Amicalement, -- Étienne Mollier
Re: libasound2: souci de mix pulseaudio et alsa
Jérémy Prego, au 2018-11-18 : > je sais pas trop expliquer ça a l'écrit, mais je vais tenté quand même. > depuis le passage de libasound2 a la version 1.1.7, il semble y avoir un > souci pour mixer pulseaudio et alsa en même temps, c'est ou l'un ou > l'autre, ce qui pose un souci quand on utilise speech-dispatcher en > permanence. Je précise que ce souci ne se produit pas avec la version > 1.1.6, du coup j'ai le droit à tout mes sons. > En fait, je me suis rendu compte de ce souci, parce qu'après la mise à > jour de libasound, je n'avais plus les sons lié a mon bureau mate. en > faisant un speaker-test, j'ai le droit a un ressource occupée tant que > mon speech-dispatcher utilisant pulseaudio est lancé. si je le kill, ça > fonctionne, mais du coup, plus de synthèse vocale. > J'ai bien essayé de configuré speech-dispatcher pour utiliser libao, > mais en faisant ça, c'est les applications qui utilisent pulseaudio qui > ne fonctionnent plus ! > > bref, un beau basard... > > Devrai-je signaler ça quelque part, je suis assez novice en signalement > de bug :( Bonjour, La commande `reportbug`, du paquet éponyme, est votre amie. Au premier lancement, il faudra la configurer pour la raccorder à votre courriel. Après, il faudra lui indiquer le paquet contenant le bug. Ça peut venir de `libasound2`, qui casserait la compatibilité effectivement, ou alors de votre `speech-dispatcher`, qui devrait migrer vers Pulseaudio. Je n'ai pas la moindre idée duquel est fautif. Toutefois, en utilisant Reportbug sur un paquet, puis sur l'autre, l'outil va partir en quête de doublons dans la base des bugs connus. Si quelqu'un a eu le même symptôme, il y aura probablement un rapport d'ouvert dans lequel vous pourrez éventuellement ajouter des détails si vous le jugez utile. Sinon, si un bug doit être effectivement rapporté, je crois que la commande vois guide plutôt bien ; je n'ai pas encore eu l'occasion d'en avoir l'usage jusqu'à ce point. :) Amicalement, -- Étienne Mollier
Re: emacs (GTK) Problème accès distant via x2go
Bonjour, Roger Tarani, au 2018-11-18 : > J'ai un doute à propos de emacs25 : à ma surprise, il > fonctionne ( "with GTK+ GUI support") mais c'est peut-être un > "virtual package provided by emacs25-lucid, emacs25-nox" ? Les versions GTK et Lucid d'Emacs ne sont pas compatibles : $ apt-cache show emacs-lucid | grep -E 'Provides:|Conflicts:' Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Conflicts: emacs-gtk, emacs-nox Si vous n'avez pas explicitement enlevé `emacs25-lucid` pour installer le paquet `emacs25-gtk`, alors il est très possible que vous ayez lancé tout de même la version Lucid. Sinon, cette version de Emacs GTK3 fonctionne, et ce n'est pas la peine d'en changer. :-) > Dans quelle direction faudrait-il chercher pour trouver la > cause du problème initial ? Il faudrait corriger GTK3 ou X2Go. Mon avis rejoint une observation faite par Tom Horsley : https://bugzilla.redhat.com/show_bug.cgi?id=1349412#c14 X2Go ne supporte pas nombre d'extensions X. Certains programmes en GTK3 peuvent éventuellement exiger ces extensions pour fonctionner. Il faudrait que GTK3 soit capable de gérer correctement les situations « dégradées », ou améliorer X2Go pour supporter ces extensions. VirtualGL permettrait d'implémenter cette dernière solution, mais il ne faut pas avoir peur d'y passer du temps, c'est assez lourd à mettre en place : https://virtualgl.org/ La solution recommandée par Emacs, dans ce cas de figure, reste l'usage de Lucid. Vous pouvez vous référer à la page d'aide en ligne , elle comporte une section à ce sujet. Vi IMproved comporte un paquet similaire `vim-athena`, en conflit avec `vim-gtk`, pour palier à ce genre de problèmes. Amicalement, -- Étienne Mollier
Re: Automatiser la configuration initiale de machines physiques
Olivier, au 2018-11-19 : > J'utilise intensivement des machines virtuelles KVM pour > mettre au point la configuration de serveurs physiques. > Le serveur host KVM est sous Debian Stretch (pas > d'environnement graphique). > Les cibles sont aussi sous Debian Stretch et sans > environnement graphique. > > Je procède en rédigeant un script d'installation que j'adapte > et relance régulièrement sur une machine virtuelle. > Quand j'estime que ce script est au point : > 1. je lance l'installeur Debian sur mon serveur physique avec > un partitionnement standard > 2. je modifie le partitionnement standard avec une clé > RescueCD (*) > 3. je copie mon script d'installation sur mon serveur physique > 4. je lance mon script d'installation en corrigeant les > éventuelles erreurs résiduelles. [...] > J'aimerai améliorer ce processus particulièrement sur les > étapes 1 et 2 au terme desquelles je dispose d'une machine > physique [...] > Qu'en pensez-vous ? > Que conseillez-vous ? Bonsoir Olivier, À vous lire, et si vous avez à maintenir plus de machines physiques que vous ne pouvez en compter avec vos doigts, qui plus est, des machines qui se ressemblent comme deux goûtes d'eau, alors je pense que vous êtes mûr pour un déploiement de serveur FAI (Fully Automated Installation) : http://fai-project.org/ http://fai-project.org/fai-guide/ Avant installation, vous allez définir une ou plusieurs classes de machines. Une arborescence d'exemple est disponible pour vous mettre le pied à l'étrier ; elle vous sera recommandée lors de la configuration de l'infrastructure, après installation des paquets. Pour procéder à une installation, vous allez démarrer vos machines physiques via PXE, le système de base pour l'installation sera fourni par une racine NFS depuis votre serveur FAI, racine qui hébergera également des scripts qui se lanceront automatiquement dans cet environnement dédié à l'installation. Le déroulé de l'installation sera journalisé et envoyé via SSH au serveur FAI à la fin de l'installation. La machine reste joignable en cours d'opération et des options peuvent être passées pour ouvrir l'accès aux terminaux annexes, pendant les phases de débogage de vos classes. Les classes de machines peuvent être assez longues à mettre au point, mais une fois qu'un script d'installation est rodé, des grappes de machines entières peuvent être installées en assez peu de temps. Voilà ce que j'en pense et ce que je vous conseille, en particulier vis-à-vis de l'amélioration des points 1 et 2 ; c'est similaire au preseed, mais sous stéroïdes. Si c'est pour une poignée de machines qui ne sont réinstallées que très occasionnellement, alors c'est peut-être un peu surdimensionné par contre. Amicalement, -- Étienne Mollier
Re: Automatiser la configuration initiale de machines physiques
Bonjour Olivier, TL;DR: Si TFTP est un problème parce que le WAN est très morcelé et cloisonné, alors peut-être que preseed sera plus adapté à votre environnement. Mais n'ayant pas travaillé avec preseed, je ne me rend pas compte de la charge de travail qu'il représente, en terme de déploiement et maintenance. Olivier, au 2018-12-11 : > 1. Je trouve preseed extrêmement difficile à maîtriser. FAI > simplifie-t-il les choses à cet égard ? Étant tombé dans FAI étant petit, je n'ai pas pris le temps de m'intéresser à preseed et aurai du mal à répondre. N'ayant que survolé la page de Wiki, je serais à côté de la plaque si je me risquait à répondre : https://wiki.debian.org/DebianInstaller/Preseed Le déploiement initial de FAI demande beaucoup de travail avant d'arriver à la première installation selon le modèle voulu. Une fois que le système roule, l'ajout de nouvelles configurations se fait sans trop de difficultés, pour peu que le résultat voulu soit bien défini par le demandeur, et l'ajout de nouvelles machines au parc existant est trivial. Il est éventuellement possible de maintenir la configuration des machines avec fai-update, mais ça sous-entend de respecter le caractère idempotent des scripts (si c'est déjà fait, le résultat doit être le même), ce qui peut rapidement ne plus être le cas, au fur et à mesure que le temps passe. Une solution comme Ansible serait préférable pour maintenir la configuration après installation. > 2. Est-il exact de penser que FAI est adapté une installation > sur un réseau local, pas sur un WAN, à cause de l'utilisation > de TFTP ou bien est-ce inexact ? S'il n'y a que deux ou trois réseaux à gérer, il y a moyen de se rattraper avec des relais. Mais si le WAN est très morcelé, cette configuration devient ingérable. En effet il faudra prévoir un serveur TFTP local par réseau, pour distribuer les noyaux, initrd et options de démarrage adéquates. L'export du NFS root aura peut-être besoin d'être revus, ainsi que les règles de pare feux. Avoir un réseau dédié à l'administration peut aider dans ce cas. Sinon, il est aussi possible de se rattraper avec fai-cd, pour produire une ISO à partir de la configuration existante, à coller sur une clé USB sur laquelle démarrer, et qui va configurer la machine proprement, sans avoir besoin du moindre réseau. L'ajout de nouvelles configurations au serveur FAI va nécessiter de régénérer les clés, ce qui rend la solution moins souple. Peut-être qu'à ce stade preseed sera plus simple que de gérer la quasi-totalité du parc avec fai-cd. Si à cause de la limitation inhérente à TFTP, vous considéreriez fai-cd pour l'essentiel de votre parc, alors /peut-être/ que votre temps serait mieux investit à l'étude de preseed. Si toutefois FAI vous intéresse toujours, la liste de diffusion peut être d'un grand secours, quand vous allez buter sur des écueils lors du déploiement : http://fai-project.org/mailinglist/ https://lists.uni-koeln.de/pipermail/linux-fai/ > PS: Désolé pour le temps mis pour réagir aux messages mais > j'ai été happé par d'autres priorités. Ce n'est pas bien grave, on a tout notre temps sur la liste des utilisateurs de Debian. :^) Amicalement, -- Étienne Mollier
Re: Suppression de /etc/apt/trusted.gpg
Benoit, au 2019-01-14 : > Bonjour, > > J'ai voulu ajouter testing dans mon source.list(avec un > Pin-Priority pour rester en stable) et j'avais des messages > d'alerte quand je faisais > > apt update > > Une recherche avec le message me conduit à un post qui suggère > de supprimer /etc/apt/trusted.gpg. > > Je le fais et ça fonctionne sans message d'alerte. > > apt n'a pas recréé un nouveau fichier... > > Est-ce que j'ai bien fait ? > > Si pas je l'ai toujours et peu le remettre à sa place. > > Voici le message que je recevais > > W: http://files2.eid.belgium.be/debian/dists/stretch/InRelease: The key(s) in > the keyring /etc/apt/trusted.gpg are ignored as the file is not readable by > user '_apt' executing apt-key. [...] Bonjour Benoit, Naïvement, j'aurais fait en sorte que l'utilisateur en question « _apt » puisse lire le trousseau de clés GPG. Après un coup d'œil dans mon installation Sid, le fichier /etc/apt/trusted.gpg n'est en fait pas présent. À la place les clés sont stockées dans un ensemble de fichiers sous /etc/apt/trusted.gpg.d/. 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... Amicalement, -- Étienne Mollier
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
Sécurisation pour un serveur (Was: Configuration réseau pour un serveur)
Bonsoir, Roger Tarani, le 2019-01-17 : > En matière de sécurisation d'un serveur Debian, c'est quoi > pour vous la doc de référence ? > > Est-ce que > https://www.debian.org/doc/manuals/securing-debian-howto/index.fr.html#contents > peut servir de référence ? > Sinon quel doc vous semble la plus solide ? Ce n'est pas forcément spécifique à Debian, mais la documentation fournie par l'ANSSI est très complète et me semble assez solide, même si elle commence à dater un petit peu : https://www.ssi.gouv.fr/uploads/2015/10/NP_Linux_Configuration.pdf Ce papier ci est spécifique à SSH (même si le plus sûr est de ne pas le faire tourner du tout) : https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf Amicalement, -- Étienne Mollier
Re: Partitionnement d'un serveur web
Bonsoir, Pascal Hambourg, au 2019-01-18 : > Le 17/01/2019 à 11:00, Daniel Caillibaud a écrit : > > C'est d'ailleurs un argument pour ne pas mettre de swap du tout, pour que > > les oomkill arrivent dès que ça sature sans attendre l'agonie du système > > (même si ça devrait jamais arriver, avec un dimensionnement correct en > > amont). > > Avec deux inconvénients non négligeables : le système ne > tolère pas les surcharges passagères, et on ne choisit pas les > processus à tuer, on doit faire confiance à l'OOM killer. Au risque de paraître insensé, quitte à compter sur l'OOM killer pour faire le ménage de manière efficace, autant configurer le noyau pour déclencher un panic_on_oom, tout en redémarrant immédiatement en cas de panic (option panic=-1 au boot, de mémoire). D'expérience, les tentatives de remises sur les rails de machines ayant subit un OOM se sont souvent soldées par des redémarrages au bout d'un temps déraisonnable, passé à se gratter la tête essentiellement... Certains systèmes peuvent être configurés pour ne pas autoriser la sur-allocation de mémoire ; c'est la configuration par défaut de l'OS au borsalino il me semble. Dans ce cas, l'OOM killer n'est jamais appelé car toute tentative de malloc au delà des limites se solde par un pointeur nul et un errno réglé à ENOMEM, voir malloc(3). Si le service à assurer gère correctement cette erreur lors de sa tentative d'allocation de mémoire, alors il devient possible de remonter un message comme quoi la machine est saturée, au lieu de commencer un nouveau traitement qui aggraverait la situation. Par défaut, Debian GNU/Linux est configuré pour faire de la sur-allocation heuristique, d'où les appels à l'OOM killer en cas de saturation de mémoire. La documentation du noyau donne un peu plus de détails à ce sujet : https://www.kernel.org/doc/html/v4.19/vm/overcommit-accounting.html Bien à vous, -- Étienne Mollier
Re: Sécurisation pour un serveur
Roger Tarani, au 2019-01-17 : > Je n'ai pas repéré d'outil de diagnostic et de configuration > conforme à ces bonnes pratiques dans la doc (pour vérifier > automatiquement que les paramètres vitaux sont bien > configurés). > Est-ce que ça existe pour Linux ? Une recherche dans la base de paquets avec le mot clé « pentest » m'a sorti une série de métapaquets forensics-* semblant prometteurs : $ apt show forensics-all Peut-être que dans le lot vous trouverez votre bonheur ? > Admettons : si on configure correctement/de manière durcie un > système Linux et ssh (plus 2FA pour chaque utilisateur), et > toutes les reco de ces docs, c'est quoi les failles qui > restent ? - Les erreurs humaines, suite à de l'ingénierie sociale par exemple, du phishing, ou la bête fausse manipulation à base de phrase de passe tapée dans un canal IRC à la place du champ prévu dans le formulaire (vécu). - Les portes dérobées, dans le matériel ou dans le système : il y a eu des exemples de correctifs embarquant de telles vulnérabilités dans du code Open Source, parfois ça finit par se voir. - Les failles 0day, encore inconnues du grand public mais exploitées par des entités malveillantes. - Les menaces physiques... La liste n'est pas exhaustive, c'est juste ce qui me vient en tête. > Quelle garantie de sûreté de fonctionnement apporte > aujourd'hui les composants logiciels de sécurité comme > (open)ssh, utilisés à grande échelle, et dont le code a été > examinés par beaucoup de monde ? > J'ignore comment c'est codé. Après tout, si l'architecture est > bien foutue et reste simple, ça peut garantir un composant > sûr. > Question ouverte... Grâce aux bonnes âmes derrière Debian, et pour peu que les entrées deb-src soient configurées dans le sources.list, pour voir comment OpenSSH est codé, le plus rapide est de lancer un petit : $ apt source openssh # :^D Quant aux garanties de sûreté, sur le papier, il n'y en a aucune. Dans la pratique, les problèmes de sécurité dans SSH agitent du monde. Le mieux que vous puissiez faire est de rester à jour de vos paquets. Amicalement, -- Étienne Mollier
Re: problème avec ftp.fr.debian.org
Pierre Frenkiel, au 2019-01-20 : >En fait, comme je l'ai dit, ce qui me gêne, c'est que >ftp.fr soit différent de ftp.us. >Ça me parait en contradiction avec la notion de miroir. Ce n'est qu'une conjecture, mais peut-être que votre dernière update a eu lieu entre deux synchronisations des miroirs fr et us. Ces derniers semblent être d'accord à l'instant t, vis-à-vis des paquets linux-compiler-gcc-6 à mettre à disposition : http://ftp.us.debian.org/debian/pool/main/l/linux/ http://ftp.fr.debian.org/debian/pool/main/l/linux/ Comme l'indiquait Pascal, c'est l'index, ici décrit par l'arborescence dists/, qui fait foi quant à la disponibilité des paquets sur un dépôt. Le pool/ contient en vrac les paquets de l'ensemble des distributions mises à disposition par le dépôt (pêle-mêle : « stretch », « unstable », « stretch-backports », « testing » ...) Le mirroring en question est, je crois, effectué par des appels réguliers à une commande « ftpsync », mais n'a pas forcément le caractère instantané d'un Raid 1. Si quelqu'un maintenant un miroir officiel dans l'assemblée peut confirmer ?... >2 questions: >1/ qu'appelles-tu "base de connaissance d'aptitude"? J'appelais « base de connaissance d'aptitude », les informations sur les paquets disponibles dans les dépôts, construite en local sur votre machine au moment de l'exécution de la commande « aptitude update ». Ces métadonnées sont réutilisée par les commandes comme « aptitude search » ou « aptitude show » sans avoir à se reconnecter au dépôt distant. Elles sont également utilisées lors des commandes « aptitude install » ou « aptitude upgrade » pour connaître l'URL de récupération des paquets requis. Quand un paquet disparaît d'un dépôt, mais est demandé par un par un client « aptitude » dont la base locale de connaissance de paquets n'est plus à jour, cette erreur 404 peut se produire. J'utilise apt, mais je suppose que le principe est identique pour aptitude, basé sur les même outils. Dans mon cas, cette base de connaissance est constituée de l'ensemble des fichiers stockés dans l'arborescence /var/lib/apt/lists/. >2/ qu'appelles-tu "miroir auquel il est raccordé"? J'appelais « miroir auquel il est raccordé », le dépôt spécifié dans /etc/apt/sources.list que apt va utiliser pour récupérer les paquets à installer. Désolé pour le manque de clarté... Amicalement, -- Étienne Mollier
Re: alerte de sécurité sur apt : 1.4.9 résolu
Bonsoir, On 1/24/19 6:17 PM, ajh-valmer wrote: > Résolu en faisant un apt-get upgrade. Gaffe, étant donné que c'est le gestionnaire de paquets qui est affecté, la procédure est un peu particulière : apt -o Acquire::http::AllowRedirect=false update apt -o Acquire::http::AllowRedirect=false upgrade -- Étienne Mollier
Re: alerte de sécurité sur apt : 1.4.9
On 1/30/19 1:46 PM, roger.tar...@free.fr wrote: > Bonjour > avec une machine encore en Jessie qui a une version plus ancienne de apt, > en plus de la mani expliquée, est-il possible de passer simplement à une > version de apt >= 1.4.9 et sans créer d'autres problèmes ? > Merci Bonjour, Oui, c'est possible. Pour Jessie la version apportant les correctifs est la 1.0.9.8.5. Voir : https://security-tracker.debian.org/tracker/CVE-2019-3462 Amicalement, -- Étienne Mollier
Re: alerte de sécurité sur apt : 1.4.9
Moi-même, à l'instant: > On 1/30/19 1:46 PM, roger.tar...@free.fr wrote: > > est-il possible de passer simplement à une version de > > apt >= 1.4.9 [...] > Oui, c'est possible Hum, à la relecture, j'aurais dû me contenter de dire que apt, version 1.0.9.8.5, corrige le problème en Jessie; il y a matière à comprendre mon message initial de travers. Amicalement, -- Étienne Mollier > Pour Jessie la version apportant les > correctifs est la 1.0.9.8.5. Voir : > > https://security-tracker.debian.org/tracker/CVE-2019-3462
Re: clipit empeche le copier/coller
rt ownership of the CLIPBOARD selection and > reassert it any time the clipboard data changes. Et d'autre part, si on jette un coup d'œil rapide au code source de xfwm4, le gestionnaire de fenêtres de Xfce, on peut avoir l'impression que, peut-être, il n'est pas neutre vis-à-vis de la manipulation des tampons du presse-papier (note: je n'ai pas pris le temps de tester), et que donc parmi ses attributions, il pourrait prendre la responsabilité de centraliser le CLIPBOARD : $ rgrep 'X.*Selection.*' xfwm4-4.12.5/ xfwm4-4.12.5/src/compositor.c:if (XGetSelectionOwner (display_info->dpy, a) != None) xfwm4-4.12.5/src/compositor.c:if (XGetSelectionOwner (display_info->dpy, a) != None) xfwm4-4.12.5/src/hints.c:status = XSetSelectionOwner (display_info->dpy, atom, w, server_time); xfwm4-4.12.5/src/hints.c:if (XGetSelectionOwner (display_info->dpy, atom) == w) xfwm4-4.12.5/src/hints.c:systray_win = XGetSelectionOwner (display_info->dpy, net_system_tray_selection); xfwm4-4.12.5/src/screen.c:current_wm = XGetSelectionOwner (display_info->dpy, wm_sn_atom); xfwm4-4.12.5/src/events.c:handleSelectionClear (DisplayInfo *display_info, XSelectionClearEvent * ev) xfwm4-4.12.5/src/events.c:status = handleSelectionClear (display_info, (XSelectionClearEvent *) ev); Clipit semble avoir des fonctions équivalentes, mais basées sur la bibliothèque GTK+ ; `rgrep gtk_clipboard_get` renvoie pas mal de lignes aussi. > Quelq'un a une explication? Sachant que l'heure de la capture de la copie fait partie des données du presse-papier (variable server_time dans xfwm4), mon ressentit dans tout ça est que: le gestionnaire de fenêtres et clipit font du pingpong, en mettant à jour à chaque itération la date des données du presse-papier, le rendant inutilisable dans la manœuvre. Mais peut-être que je me trompe: il n'y a pas de problèmes quand deux instances de clipit sont en train de tourner simultanément, alors que je m'attendais éventuellement à ne plus pouvoir effectuer ni copies ni collages... > Il y a plus de 30 ans, j'avais lu en détail la doc (une > dizaine de pavés) de X11 - à l'époque des stations Sun - et > j'avais tâté NeWS. Mais j'ai oublié la plupart des détails. Désolé pour l'interprétation très empirique et un peu brouillon, je n'ai pas les volumes dans ma bibliothèque. J'espère que ça a fait un peu sens néanmoins. :^) ajh-valmer, au 2019-01-31 : > Le copier/coller fonctionne mal chez moi aussi avec Libreoffice, > grâce à la molette. > Défaut inhérent depuis toujours ainsi que OO. Pour ce qui est des suites bureautique Star/Open/LibreOffice, manifestement, une fonction a été implémentée pour s'exécuter lors d'un clic milieu de la souris, et ne consiste pas toujours à copier le contenu du tampon primaire. Je suis d'accord, ce n'est pas très ergonomique. :^( Amicalement, -- Étienne Mollier Bon sang, on est déjà en février ?
Re: Freeze à cause de Thunderbird ?
François Meyer, au 2019-02-06 : > J'ai l'impression que thunderbird fait planter mon ordi > (Debian Jessie). Il freeze de manière un peu aléatoire mais > toujours quand il y a tbird avec pas mal d'autres choses en > même temps : firefox, emacs, etc. > > J'ai déjà remarqué que tbird consommait parfois énormément de > CPU. > > Comment faire pour trouver le coupable ? est-ce qu'une lecture > attentive du syslog juste avant le freeze me donnerait des > indications (je n'ai pas trop l'habitude de m'y plonger, mais > je peux essayer). Bonsoir, Ça a le goût et la couleur d'une saturation de mémoire; mais peut-être que je me trompe... Voici quelques questions, si ça peut aider à se situer: - Quels symptômes apparaissent lors du crash ? (Machine de plus en plus lente graduellement ? D'un coup ? ...) - Quelle est la consommation typique de mémoire vive au moment du crash ? (Gardez un œil sur la commande « watch free -h ») - Le journal du noyau, accessible dans /var/log/kern.log, mentionne-t-il éventuellement des appels à l'OOM killer ? D'autres erreurs, potentiellement relatives à Thunderbird, y sont elles présentes ? - Mêmes questions pour le /var/log/syslog... :^) Il n'est pas forcément nécessaire de passer en revue l'intégralité des journaux, pour le moment. Essayez d'identifier quelque chose aux alentours de l'heure des faits. Les fonctions de recherche de votre éditeur de texte seront appréciables lors de la nage dans les journaux. Amicalement, -- Étienne Mollier
Re: Cryptage des disques
On 3/21/19 9:21 PM, Belaïd wrote: > Bonsoir, > > LUKS par exemple ... > > Le jeu. 21 mars 2019 21:19, Erwan RIGOLLOT a écrit : > > Bonjour, > > Dans le cadre du RGPD il y a pas mal de choses à faire pour être en > conformité. > Y a-t-il un équivalent à bitlocker sous linux ? (Debian ?) Bonsoir, LUKS, comme proposé par Belaïd, conviendra pour cette tâche et fait partie de Debian Installer. Le chiffrement des disques peut donc être effectué lors de l'installation de la machine, voyez la section 6.3.3.6. de la documentation d'installation : https://www.debian.org/releases/stable/amd64/ch06s03.html.fr Le projet rassemblant dm-crypt/LUKS est `crypsetup` : https://gitlab.com/cryptsetup/cryptsetup Je suppose qu'il y aura quelques différences notables en comparaison avec Bitlocker, plus ou moins bienvenues en fonction de votre politique de comptes et mots de passe. L'activation de certaines fonctionnalités, comme l'obligation de saisie de mots de passe forts peut nécessiter de recompiler le paquet cryptsetup avec quelques options supplémentaires par exemple. Bien à vous, -- Étienne Mollier
Re: patcher en mode conservateur ?
François Meyer, au 2019-03-22 : > Je cherche à patcher un fichier sans rien lui retirer. > > Autrement dit, ajouter à un fichier les lignes d'un autre > fichier mais seulement celles qui n'y sont pas déjà. > > Il doit y avoir une option dans diff ou patch, mais je ne > trouve pas, et la seule solution (sale) que j'ai trouvée > consiste à effacer les lignes commençant par "-" dans le > fichier patch puis à appliquer le patch normalement sur le > fichier à incrémenter. Bonjour François, Les programmes diff et patch ont été écrit dans une optique de génie logiciel, où retirer des lignes a autant d'importance que d'en ajouter. Filtrer le résultat du diff pour votre cas d'usage comme vous le faite n'a rien de bien choquant, tant que ce n'est pas pour mettre à jour du code source. :) Si vraiment vous voulez minimiser le nombre de commandes lancées par votre script, jetez un œil au manuel de diff(1), à partir de l'option -D, il semble qu'il y ait des options de formatage qui permette des manipulations intéressantes sur la sortie de diff. Notez toutefois que manipuler le formatage n'est pas compatible avec les options -u et -U. Je crains cependant que la lisibilité de votre script n'en pâtisse. Mais si vraiment les performances sont un problème, une réimplémentation en langage compilé (C, Rust, ...) du problème que vous voulez résoudre peut être une solution plus appropriée. À vous de voir... Amicalement, -- Étienne Mollier All opinions are my own.
Re: mais ou est passee la place manquante ?
hamster, au 2019-04-04 : > #!/bin/bash > > homeUUID=$(grep "/home" /etc/fstab | grep -v "#" | cut -d"=" -f2 | cut > -d" " -f1); > homedevice=$(ls -l /dev/disk/by-uuid/ | grep $homeUUID | cut -d"/" -f3); > tune2fs -m 0 /dev/$homedevice; > > Vu que je suis assez débutant en scripts, je veux bien le regard de > votre sagacité dessus. Bonjour, Vous l'avez demandé ; vous l'aurez. :) Avant toute chose, il est préférable, quand une commande renvoie un code d'erreur, d'arrêter le script aussitôt, ce que ne fait pas bash par défaut, à moins de lui passer l'option `-e`. Il suffit d'ajouter la commande suivant pour corriger cela : set -e Ensuite, j'aurais un peu ventilé pour éclaircir le propos, par exemple comme suit : homeUUID=$( grep "/home" /etc/fstab \ | grep -v "#" \ | cut -d"=" -f2 \ | cut -d" " -f1 ); Cette manière de présenter le script est très aérée, et me semble très lisible. La substitution de commande et le pipelining ressortent assez bien. Mais comme il s'agit de questions de style, peut-être que vous aurez des goûts différents. Ce n'est pas grand chose en soi, mais le saut de ligne permet de séparer les commandes. Le ';' n'est alors pas nécessaire, à moins que vous préfériez ne pas perdre d'habitudes issue du C : homeUUID=$( grep "/home" /etc/fstab \ | grep -v "#" \ | cut -d"=" -f2 \ | cut -d" " -f1 ) Dans ce genre d'affectation de variable, ça ne changera pas grand chose ; mais d'ordinaire, je protège mes toutes mes évaluations (symbole '$') avec des doubles quotes '"' comme suit, quel que soit le contexte : homeUUID="$( grep "/home" /etc/fstab \ | grep -v "#" \ | cut -d"=" -f2 \ | cut -d" " -f1 )" L'utilisation de l'opérateur d'évaluation '$()', à la place des historiques backtick '`', est un bon réflexe : il a un ouvrant et un fermant, et dispose de sont propre contexte pour les '"', qui ne vont donc pas fermer les doubles quotes se trouvant en dehors de l'évaluation, contrairement aux backticks : echo "`grep \"\\\`du texte\\\`\" fichier`" (Honnêtement, je ne suis même pas certain que la commande ci-dessus fasse ce que je veux.) À comparer avec la commande suivante franchement moins fouillis en caractères d'échappement : echo "$(grep "\`du texte\`" fichier)" Pour l'évaluation du `homedevice`, en terme général, analyser la sortie de la commande `ls` est dangereux, l'exemple typique étant le traitement des fichiers avec des sauts de lignes dedans. Dans le répertoire /dev/disk/by-uuid, ça ne devrait pas poser problème, mais l'usage de `ls` dans un script est un mauvais réflexe très (trop) courant. Une approche un peu plus propre, à mon sens, pour résoudre le lien symbolique serait d'utiliser `readlink` : homedevice="$( readlink -f "/dev/disk/by-uuid/$homeUUID" )" tune2fs -m 0 "$homedevice" Ceci étant, quand on a des liens symboliques, c'est un peu dommage de ne pas s'en servir, il est tout à fait possible d'appliquer le `tune2fs` directement sur le disque par UUID. Le système se charge de résoudre le lien symbolique vers le fichier bloc correspondant pour l'opération : homedevice="/dev/disk/by-uuid/$homeUUID" À ce stade de la réflexion, le script ressemblerait donc à : #!/bin/bash set -e homeUUID="$( grep "/home" /etc/fstab \ | grep -v "#" \ | cut -d"=" -f2 \ | cut -d" " -f1 )" homedevice="/dev/disk/by-uuid/$homeUUID" tune2fs -m 0 "$homedevice" Mais finalement, peut-être qu'on pourrait directement utiliser le fichier bloc stockant /home tel que rapporté par la commande `df`, plutôt que d'aller voir dans le fichier fstab, si d'aventure il devait ne pas être à jour ? (À moins bien sûr que ce ne soit à dessein.) #!/bin/bash set -e homedevice="$( df /home \ | grep -v '^Filesystem' \ | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Attention, si le /home n'est pas sur une partition séparée, alors c'est la partition de / qui va se voir supprimer les blocs réservés à root. Avec le premier script, si le /home n'est pas dans le fstab, et que `set -e` est présent, alors le script s'arrête. Pour aller plus loin, l'Advanced Bash Scripting guide est pour moi un incontournable : http://www.tldp.org/LDP/abs/html/index.html Il est également disponible en Français, même si j'ai quelque difficultés avec la traduction : https://abs.traduc.org/abs-5.0-fr/ Voilà, prenez ce qui vous semble intéressant. :) Amicalement, -- Étienne Mollier Ligne de commande épique : # tune2fs -m0 "$(df /home|sed -n '2s/^\([^ \t]\+\).*/\1/p')"
Re: [HS] Scripting Bash
Sébastien Nobili, au 2019-04-04 : > Attention toutefois aux bashismes. Bash > fournit pas mal d’adaptations au standard (Bourne Shell) qui rendent > non-standard les scripts écrits pour lui et testés avec lui. > > Pas de problème si on n’utilise que Bash, mais si un jour le shell change (par > exemple lorsque Debian est passé de Bash à Dash comme shell par défaut), alors > les scripts plantent (et en général avec des messages assez obscurs). Bonjour, C'est une très bonne remarque, un certain nombre de fonctions avancées de Bash ne peuvent pas être utilisée avec n'importe quel shell. Le Dash a la vocation d'implémenter le standard, ni plus, ni moins. Un script compatible Dash est donc censé tourner de la même manière avec n'importe quel autre shell compatible avec le Bourne Shell standard, du moins en théorie. Quand un shell est appelé de manière implicite, typiquement pour interpréter les recettes dans un Makefile, les bashismes peuvent causer des dégâts. Et changer de shell dans ce genre de contexte n'est pas toujours évident : je viens seulement de découvrir l'existence de la variable SHELL dans make pour changer d'interpréteur, par exemple… Amicalement, -- Étienne Mollier
Re: mais ou est passee la place manquante ?
Pascal Hambourg, au 2019-04-06 : > Le 04/04/2019 à 23:21, Étienne Mollier a écrit : > > Mais finalement, peut-être qu'on pourrait directement utiliser > > le fichier bloc stockant /home tel que rapporté par la commande > > `df`, plutôt que d'aller voir dans le fichier fstab, si > > d'aventure il devait ne pas être à jour ? (À moins bien sûr que > > ce ne soit à dessein.) > > > > #!/bin/bash > > set -e > > homedevice="$( > > df /home \ > > | grep -v '^Filesystem' \ > > | cut -f1 -d' ' > > )" > > tune2fs -m 0 "$homedevice" > > > > Attention, si le /home n'est pas sur une partition séparée, > > A tester auparavant avec mountpoint. Oh la jolie petite commande bien pratique ! Merci pour l'information, on ne fait pas assez de publicité à son sujet. :) Bien à vous, -- Étienne Mollier
Re: retour expérience sur Buster ??
Bruno Volpi, au 2019-04-08 : > 2 - service strat/stop/restart -> commande not found > problème à l'install ??? Bonjour Bruno, Normalement cette commande fait partie des utilitaires système Debian de base : $ dpkg -S /usr/sbin/service init-system-helpers: /usr/sbin/service $ apt-cache show init-system-helpers | grep ^Prio Priority: required Peut-être qu'il y a eu un problème à l'installation, mais pour le moment, j'aurais plutôt une vilaine tendance à soupçonner l'usage d'un `su` à la place d'un `su -`. En effet, il y a eu un changement d'implémentation, et donc de comportement entre Stretch et Buster, notamment vis-à-vis de la prise en compte du PATH utilisateur, qui ne comporte pas les répertoires sbin/. Extrait du fichier NEWS du paquet `util-linux`, fournissant désormais la commande `su` : > The first difference is probably the most user visible one. Doing > plain 'su' is a really bad idea for many reasons, so using 'su -' is > strongly recommended to always get a newly set up environment similar > to a normal login. If you want to restore behaviour more similar to > the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs. Apparemment, même si le mieux serait de prendre l'habitude d'utiliser `su -` à la place de `su`, on peut revenir à l'ancien comportement avec l'option 'ALWAYS_SET_PATH yes' dans le fichier /etc/login.defs. Et s'il y a eu effectivement un problème à l'installation, alors je suis à côté de la plaque. :) Bien à vous, -- Étienne Mollier
Re: retour expérience sur Buster ??
Bruno Volpi, au 2019-04-08 : > 1 - menu des applications dans la bar du tableau de bord. il > semblerai que seulement celles en QT sont affectées ( firefox et > thunderbird fonctionne normalement) > > possibilité de changer dans configuration du système -> > apparences des applications -> Décoration de fenêtres (onglet) > boutons -> add menu Re, N'étant un utilisateur quotidien ni de KDE, ni de Gnome, j'ai peut-être compris le problème de travers. Mais si je résume, KDE dispose d'un réglage pour cacher la barre de menu d'une application (contenant typiquement "Fichier", "Édition", "Affichage", etc) dans un menu situé dans la barre de titre de la fenêtre. Ce composant fonctionne très bien avec les applications Qt mais pas avec les autres applications, notamment celles en GTK. De ce que je comprends, et vu nos petits essais, ce réglage a l'air spécifique à KDE/Qt, et les applications ne bénéficiant pas d'une intégration KDE n'en font pas partie ; par exemple le paquet libreoffice-kde5 fournit cette intégration à LibreOffice, mais sans ce paquet, ce menu, ainsi que plein d'autres fonctionnalités, n’apparaît pas. Il est à noter que GTK a un onglet dédié dans la fenêtre de configuration de KDE, mais ce genre réglage n'y apparaît pas (pas encore?) > si quelqu'un à un peu d'expérience je serai très heureux de > savoir s'il existe un bypass, sinon retour sur gnome. En la matière, mon expérience est limitée. Mais étant donné les tours de passe-passe pour intégrer les applications à KDE, notamment LibreOffice, je crains qu'il n'y ait pas de bypass simple actuellement pour faire de même avec les programmes en GTK. Peut-être dans le futur, si une demande de nouvelle fonctionnalité est faite auprès des développeurs de KDE ? Amicalement, -- Étienne Mollier
Re: retour expérience sur Buster ??
Bruno, au 2018-04-09 : > pour le menu je m'explique un peu mieux > > sur une appli tu as la barre de titre puis les menu ( fichier , > édition ,.), puis la tool bar > > en haut ( ou en bas) de ton écran tu as la barre 'tableau de > bord ou tu as le launcher, et autres infos. > > avec buster et kde je n'ai trouvé que deux alternative : > > 1 - le menu s'affiche dans la barre 'tableau de bord' et il faut > jongler entre la fenêtre appli et le tableau de bord Ah d'accord, je crois que je commence à comprendre le coup du menu s'affichant dans le tableau de bord au lieu de la fenêtre : c'est un peu comme dans Ubuntu classique, ou historiquement à la Apple Macintosh (en tout cas c'était présent dans System 7.5). Je n'ai pas eu ce comportement là par défaut, mais j'ai pu l'activer en suivant : Clic droit sur le tableau de bord -> Options de Tableau de bord -> Ajouter un panneau -> Barre de menu des applications Les applications Qt relancées après coup voient leur barre de menu insérée dans le nouveau panneau, à la place de la fenêtre. Pour revenir à l'état initial, je fais : Clic droit sur la nouvelle barre de menu externe -> Configurer Tableau de bord -> Clic sur le bouton en forme de clé de mécano "Plus de paramètres" -> Supprimer le tableau de bord. Ensuite je relance mes applications, et la barre de menu est de retour à l'intérieur des fenêtres. Est-ce que ça aide ? Amicalement, -- Étienne Mollier
Re: mais ou est passee la place manquante ?
Pascal Hambourg, au 2019-04-09 :
> Au passage, la méthode pour écarter la ligne d'en-têtes n'est
> pas fiable car elle dépend de la langue d'affichage. Il aurait
> mieux valu utiliser tail pour extraire la dernière ligne.
Oui, une autre solution aurait pu aussi consister à s'en tenir à
la locale C :
#!/bin/bash
set -e
export LANG=C
homedevice="$(
df /home \
| grep -v '^Filesystem' \
| cut -f1 -d' '
)"
tune2fs -m 0 "$homedevice"
Amicalement,
--
Étienne Mollier
Ce qui est bien, c'est qu'il y a plein de manières de faire.
Ce qui est terrible, c'est qu'il y a encore plus de manières de
se prendre les pieds dans le tapis.
Re: retour expérience sur Buster ??
Bruno Volpi, au 2019-04-10 : > le menu s'affiche toujours dans la barre de titre de > l'application en style menu déroulant. Bonjour, Pour ce point, en m'inspirant de votre procédure initiale, j'arrive à basculer entre « menu déroulant » et « barre de menu » : Clic menu « K » (enfin, s'il s'appelle encore comme ça) -> Configuration du système -> Apparences des applications -> Décorations de fenêtres -> Onglet « Boutons » -> Cliquer/glisser le menu d'applications depuis la barre de titre vers l'intérieur de la fenêtre schématisée dans le panneau de configuration -> Appliquer -> et éventuellement relancer les applications Qt. Si ça ne vous permet pas d'atteindre une situation adaptée à votre ergonomie, alors là je sèche. Amicalement, -- Étienne Mollier
Re: INFO: task blocked for more than 120 seconds
Bonjour, C'est dommage que chaque sortie de noyau soit sur une seule ligne: ça rend la lecture des listings vraiment très désagréable. :( Ceci étant, j'ai cru voir un truc peut-être intéressant (ou peut-être impertinent, dépendant de la causes.) steve, au 2019-04-12 : > 1 box kernel: [ 3988.692314] Tainted: P OE ... ^~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.) Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver. Bien à vous, -- Étienne Mollier
Re: INFO: task blocked for more than 120 seconds
Bonjour, steve, au 2019-04-15 : > Vraiment désolé, à l'envoi ça semblait correct. Ce n'est pas très grave; on a qu'a dire que ça a justifié le démarrage de mon éditeur de texte préféré. :) > Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit : > > steve, au 2019-04-12 : > > > 1 box kernel: [ 3988.692314] Tainted: P OE ... > > ^~~ > > Le noyau est teinté, quelle en est la cause ? (ce devrait être > > indiqué quelque part dans la sortie de `dmesg`.) > > > driver nvidia proprio. Bon, au moins on en a le cœur net, la teinture n'avait rien de vraiment pertinent, sauf malchance. > > Si un sous système corrompt le noyau, alors il n'est peut-être > > pas nécessaire de chercher plus loin, et juste de le > > désactiver. > > Je pourrais en effet essayer le driver libre « nouveau ». Mais la > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau. Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat) > Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit : > > Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je > > sais pas trop comment. > > Rien dans la page man. L'essentiel du verbe provient surtout de la sortie de `dmesg`. Peut-être que des messages intéressants apparaissent au moment de l'assemblage ? Amicalement, -- Étienne Mollier
Re: INFO: task blocked for more than 120 seconds
steve, au 2018-04-16 : > Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit : > > steve, au 2019-04-15 : > > > Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit : > > > > Si un sous système corrompt le noyau, alors il n'est peut-être > > > > pas nécessaire de chercher plus loin, et juste de le désactiver. > > > > > > Je pourrais en effet essayer le driver libre « nouveau ». Mais la > > > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. > > > > Ça vaudrait peut-être quand même le coup de voir si le noyau est > > toujours teinté sans ce pilote, et si le problème se pose à nouveau. > > Oui. Bonjour, Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! » > > Sinon, plus prosaïquement, dans quel état se trouve le Raid > > actuellement ? Est-il toujours partiel ou bien le remplacement > > du disque en panne a eu lieu ? (cat /proc/mdstat) > > J'avais trois disques dans la grappe dont un spare qui a pris du service > quand j'ai débranché le disque défectueux. > > $ cat /proc/mdstat > Personalities : [raid1] [linear] [multipath] [raid0] [raid6] > [raid5] [raid4] [raid10] > md1 : active raid1 sdb5[2] sde5[3] > 117120896 blocks super 1.2 [2/2] [UU] > > md2 : active raid1 sdb6[2] sde6[3] > 97589120 blocks super 1.2 [2/2] [UU] > > md0 : active raid1 sdb1[2] sde1[3] > 19514240 blocks super 1.2 [2/2] [UU] > > unused devices: > > > Donc ok. En dehors des freezes et des traces dans `dmesg`, tout me semble correct, donc la piste du bug noyau me semble envisageable. En jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a été publié avec une correction relative à la reconstruction de Raid 1 [0] indiquant notamment des risques de corruption, en cas d'interruption de la reconstruction notamment. [0] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24 Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas. > J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de > l'installer. Si cette histoire de corruption à la reconstruction est avérée, alors je délayerais la reconstruction au moins à après mise à jour vers la dernière version de Linux 4.19 mise à disposition dans les backports. Amicalement, -- Étienne Mollier
Re: INFO: task blocked for more than 120 seconds
Bonjour, Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir un rapport à propos du noyau via reportbug. Si ce comportement est connu d'un mainteneur, alors peut-être qu'il aura une solution, sinon ce sera toujours bien d'en avoir une trace. Steve, au 2019-04-17 : > Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit : > > Toutefois, je ne sais pas si vous vous êtes retrouvé dans la > > situation décrite par le changelog, ni si corruption il y a ; > > je crois qu'il y aurait aussi des erreurs relatives à votre > > système de fichier dans `dmesg` dans ce cas. > > J'ai bien peur que non. J'aimerais bien avoir plus d'information dans > les différents fichiers journaux mais je ne sais pas trop comment et > quoi activer. Les message relatif au noyau et ses sous-systèmes apparaissent en sortie de la commande `dmesg`. En dehors, je ne vois pas, à part des copies dans les différents agrégateurs de journaux. Il est éventuellement possible d'augmenter la verbosité de certains modules noyau, via des options du type module.debug=1, mais pas certain que ça aide dans votre cas. Je n'exclue pas d'avoir loupé quelque chose moi-même. Dans le doute, la force brute est aussi une solution valide pour chercher une aiguille dans une botte de foin: # rgrep -i 'ext4\|raid\|md[0-2]' /var/ > uname -a > > Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 > (2019-03-27) x86_64 GNU/Linux 4.19.28-2~bpo9+1, ça devrait être bon. :) Dans le doute, j'ajouterais un incrément dans les backups avant reconstruction, au cas où... > Voilà, j'ai essayé avec le driver « nouveau ». Impossible de charger > xorg, faut dire que j'ai une carte assez récente (GeForce GTX 1080 Ti). Ça vient probablement du fichier /etc/X11/xorg.conf, produit par nvidia-xconfig ou nvidia-settings, lors de l'installation et la configuration du pilote respectivement. Avec un peu de chance, le serveur X démarrera si ce fichier n'existe plus, par exemple en le renommant /etc/X11/xorg.conf.nvidia-bck. Si vraiment c'est « nouveau » qui coince, alors il est toujours possible de le replacer en liste noire, le pilote nvidiafb pourra éventuellement prendre le relai ; ceci étant j'ai déjà vu ce pilote coincer méchamment sur carte Quadro, avec la console coincée sur une fonte blanche à fond vert… L'écran vert de la mort ? > En éteignant la machine, j'ai observé un truc étrange: > > Failed unmounting /var > > et /var est monté sur /dev/md0. > > Je ne sais pas si ça peut corrompre ce système de fichiers si la machine > s'éteint avant que cette partition ne soit démontée. Une piste ? À première vue, ça aurait pu expliquer les erreurs corrigées par fsck, que vous avez mentionné un peu plus tôt dans le file de discussion. Toutefois, si le système de fichier ne s'était pas correctement démonté à l'arrêt de la machine, je crois que le fsck aurait dû se déclencher au démarrage suivant. > Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très > récemment, ce qui a diminué leur nombre). L'essentiel est effectivement du bruit, mais c'est bien pensé, le coup de mettre à jour le Bios. Amicalement, -- Étienne Mollier
Re: INFO: task blocked for more than 120 seconds
Steve, au 2019-04-18 : > Le 17-04-2019, à 22:47:29 +0200, Étienne Mollier a écrit : > > Je crois que je commence à sécher. Ça vaudrait le coup d'ouvrir > > Et bien moi je crois que je suis sur une piste :) > > J'ai trouvé trace de fautes de segmentation de mon agent de transport > mail, dma. Je l'ai donc remplacé par exim4, juste pour voir, et pour le > moment, plus de gel. Je croise les doigts. Ça c'est une très bonne nouvelle! :) > > Dans le doute, j'ajouterais un incrément dans les backups avant > > reconstruction, au cas où... > > C'est à dire ? Faites une sauvegarde avant la manipulation, des fois que… > var.mount: Directory /var to mount over is not empty, mounting > anyway. C'est peut-être du bruit lié à un démarrage sans montage du /var une fois. Et comme les fichiers ne sont pas effacés mais seulement inaccessibles, le message se reproduit à chaque démarrage. Ça pourrait aussi être lié à ce bug si le problème se reproduit après ménage dans le /var de votre partition / (utilisez `mount --bind / /mnt/rescue` pour voir ce qu'il se passe sous les points de montages) : https://github.com/systemd/systemd/issues/4494 Corrigé dans systemd 233, mais je ne suis pas allé vérifier si ça été corrigé dans Stretch ou non. Ou alors un de vos services démarre trop vite et aurait grand besoin de dépendre de var.mount et tmp.mount avant de commencer à tourner ? Amicalement, -- Étienne Mollier
Re: dessin partagé entre deux PC Linux (Inde et France)
Basile Starynkevitch, au 2019-05-09 : > Il se trouve que RefPerSys intéresse dès maintenant un jeune > informaticien indien, Abhishek (il vit à Calcutta). il y > contribue très activement sur son temps libre lui aussi. Je > suis devenu un peu son mentor (il a l'âge d'être mon fils). La > collaboration devient très agréable, et c'est du > gagnant-gagnant: de mon côté, je lui apprends des trucs de > vieux singe, et de son côté il contribue à coder efficacement > dans RefPerSys (pour l'instant, sous ma direction appuyée car > je passe du temps à lui expliquer des trucs). Et Abhishek a > accès, en ssh, à mon ordinateur en région parisienne. Il peut > y ouvrir un vieux xterm, mais c'est lent à cause de la > faiblesse de la bande passante. Bonsoir Basile, Je commence un peu à côté de la question, mais pour tout ce qui a purement trait au rendu textuel à distance, Mosh, le « Mobile Shell », fait des merveilles sur les lignes à faible débit et forte latence. On a l'impression de travailler en local, y compris dans des situations relativement extrêmes, comme les lignes satellites, éventuellement assaisonnées de déconnexions régulières : Package: mosh Homepage: https://mosh.org Description: Mobile shell that supports roaming and intelligent local echo D'expérience, une session SSH entre Massy et Mumbai est plutôt utilisable, mais la latence est suffisamment présente pour que la session de travail soit plus fatigante qu'en travaillant en local. > Ca m'arrangerait beaucoup de pouvoir, en même temps que je > parle en audioconf, dessiner un truc à la souris Pour en revenir à la question d'origine, une recherche avec les mots clés « collaborative drawing » fait remonter le programme Drawpile dans mon moteur de recherche préféré : https://drawpile.net/ C'est un logiciel vraisemblablement Libre, en GPLv3, et dédié au dessin collaboratif. L'installation du logiciel sous Debian nécessite de jouer un peu avec Flatpak, si vous n'y êtes pas réticent. Un serveur est embarqué dans le client lourd, ce qui nécessitera éventuellement de configurer un peu le NAT à la première utilisation, et qui fonctionnera en mode pair à pair le temps de la session. Je crois que cela devrait suffire pour vos besoins. Il est également possible de lancer un daemon dédié, qui lui s'installe via Docker, à en juger par la documentation. Si d'aventure il vous venait l'envie d'administrer un tel service pour vos proches, cela peut-être envisagé, ou pas. Je ne l'ai pas testé donc je ne sais pas ce qu'il vaut dans la pratique, mais une fois pris en main, dans ce contexte, ça m'a l'air plus adapté que les sessions VNC partagées. :) Bien à vous, -- Étienne Mollier
Re: failles de sécurité sur vim et neovim
Bonjour, Je peux me tromper, mais d'après /usr/share/vim/vim81/debian.vim, il me semble que cette vulnérabilité déjà mitigée par défaut dans Debian, et que cette option ne date pas d'hier : > " modelines have historically been a source of security/resource > " vulnerabilities -- disable by default, even when 'nocompatible' is set > set nomodeline Ceci étant, un petit rappel comme quoi il est dangereux d'activer les modelines est toujours bienvenu. Un coup d'œil à l'aide de l'option « secure » est également bienvenu si vous utilisez vim en tant que root pour éditer vos fichiers de configuration : :h secure Bien à vous, -- Étienne Mollier
Re: Problème de lecture vidéo
nicolas, au 2019-06-16 :
> Voici les résultats des commandes totem, VLC et mplayer:
>
>
> * Pour TOTEM:
> % totem D.avi
> libEGL warning: DRI2: failed to open nouveau (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
> libEGL warning: DRI2: failed to open swrast (search paths
> /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
[...]
>
> * Pour VLC qui arrive à lire le son mais pas les images (écran noir):
> % vlc D.avi
[...]
> Failed to open VDPAU backend libvdpau_nvidia.so: Ne peut ouvrir le fichier
> d'objet partagé: Aucun fichier ou dossier de ce type
[...]
Bonjour,
Ces erreurs suggèrent que la pile OpenGL de votre machine est
cassée. On dirait que le pilote libre "nouveau" est installé,
mais VLC fait référence à libvdpau_nvidia.so.1, que je ne vois
apparaître, via apt-file, que dans les paquets liés au pilote
privateur "nvidia".
- Quelle carte graphique utilisez vous ?
- Aviez-vous l'intention d'utiliser le pilote libre "nouveau",
qui fonctionne comme il peut, ou le privateur "nvidia", qui
offre le meilleur support et les meilleures performances ?
>
> * Pour MPLAYER qui arrive aussi a lire le son:
> % mplayer D.avi
> Playing: D.avi
> (+) Video --vid=1 (mpeg4 640x362 23.977fps)
> (+) Audio --aid=1 (mp3 2ch 44100Hz)
> AO: [pulse] 44100Hz stereo 2ch s16
> VO: [opengl] 640x362 yuv420p
> AV: 00:04:18 / 00:58:29 (7%) A-V: 0.000
Ce n'est pas tout à fait évident dans votre mail d'origine, mais
je suppose que l'image ne passe pas non plus. Que donne la
commande :
% mplayer -vo x11 D.avi
Si le problème vient d'OpenGL, alors cette commande devrait
fonctionner correctement pour jouer des vidéos.
Amicalement,
--
Étienne Mollier
Re: Plantage VLC
Eric Degenetais, au 2019-06-20 : > Le jeu. 20 juin 2019 08:59, Eric Bernard > a écrit : > > Depuis 2 semaines j'ai vlc qui plante de plus en plus > > souvent en "figeant" carrément mon interface utilisateur > > (xfce) et sur mes 2 postes (1 fixe et 1 portable). Je n'ai > > que la solution d'ouvrir une autre interface utilisateur et > > de redémarrer le service lightdm... > > quel Debian ? Aussi bien VLC que Xine plantent de même sous > Buster chez moi. Problème Nouveau + Vdpau (rendu vidéo) > d'après les quelques logs que j'ai pu entrevoir avant le > freeze. Parfois ça plante tellement que je suis obligé de > rebooter en force (reset ou shutdown au bouton). J'ai une > partition Stretch où j'utilise également nouveau qui n'a pas > ce problème. Bonjour, Ça pourrait aussi expliquer le problème de nicolas : https://lists.debian.org/debian-user-french/2019/06/msg00177.html Faute de carte nvidia à portée pour jouer avec nouveau, je n'ai pas poussé plus loin, mais je suis tombé sur la page de wiki « Freedesktop » suivante, qui a l'air d'avoir des informations intéressantes : https://nouveau.freedesktop.org/wiki/ Notamment, la page suivante : https://nouveau.freedesktop.org/wiki/VideoAcceleration/ mentionne l'usage de firmware externes, au moins pour les accélérateurs allant du VP2 au VP5. Peut-être qu'ils correspondent aux fichiers /lib/firmware/nvidia/** fournis par le paquet « firmware-misc-nonfree » ? (mais je n'y ai rien vu semblant correspondre à la carte GT 720 par exemple.) > > Du coup j'utilise plus que Parole et c'est pas génial !!! > > > > Une idée ou un autre logiciel à me conseiller ? > > Sur ma partition Buster je suis passé au pilote Nvidia > (legacy) et ça règle le problème. D'une manière générale je > préfère utiliser des pilotes libres, mais là le pilote proprio > règle mon problème, qui serait sinon un nogo pour buster sur > mon matériel. Ne pas utiliser l'accélération vidéo de la carte, en utilisant X à la place, permet de contourner, mais pas de résoudre, le problème. Mais je ne sais pas si vous considérerez mplayer, ou mpv, beaucoup mieux que Parole, à vous de voir : $ mplayer -vo x11 video.fmt $ mpv --vo=x11 video.fmt Peut-être que des options sont cachées dans VLC pour utiliser ce mode de fonctionnement ? Amicalement, -- Étienne Mollier 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Gérer la charge de sa batterie au lithium de son pc portable ?
On 6/23/19 1:21 PM, toto wrote: > Je cherche sous de debian stretch 9.9 un paquet éprouvé (en ligne de > commande ou graphique peu importe) indépendant d'un bureau et qui fonctionne > sous openbox par exemple afin de gérer la charge de ma batterie de pc > portable. Je souhaite lorsque debian est chargé (pc en marche) déclencher la > charge de la batterie en-dessous des 40% puis l'arrêter à 80% de manière > automatique. Un fois la charge déclenchée le système s'éteindra tout seul à > 80% de charge si le pc portable entre temps n'est plus utilisé. Un problème > cependant la charge continue lorsque le pc portable est éteint (bios UEFI). > Des idées ? Bonjour, Certains ordinateurs portables haut de gamme sont fournis avec des contrôleurs de batteries avancés, permettant de choisir entre maximiser la charge, ou maximiser la durabilité de la batterie. Ce point est à étudier dans la configuration de la carte mère. Certains ZBook très récents sont fournis avec cette fonctionnalité disponible par exemple ; il faut aller l'activer dans l'interface de configuration de l'UEFI, ce n'est bien évidemment pas actif par défaut. En solution logicielle, un petit `apt search battery` me renvoie "tlp", caché au milieu de dizaines de paquets, et qui semble faire, entre autres, ce que vous demandez. D'après le README.md il pourrait aussi faire bien d'autres choses, comme intervenir sur la fréquence CPU, la rotation des disques, etc, ce qui potentiellement peut ne pas vous convenir. Mais je ne sais pas à quel point cette solution est éprouvée. Bien à vous, -- Étienne Mollier 59DA 56FE FFF3 882D All opinions are my own. signature.asc Description: OpenPGP digital signature
Re: Utiliser la sortie hdmi de mon pc portable ?
On 6/23/19 1:27 PM, toto wrote: > Sous debian je > cherche également un paquet utilisable sous openbox par exemple qui permet > de passer de mon écran de pc portable à moniteur plus grand. Bonjour, En ligne de commande, usuellement, "xrandr" devrait permettre de travailler avec n'importe quelle configuration. Par contre il faut passer un peu de temps dans le manuel, et expérimenter, avant de bien comprendre comment le mécano fonctionne. Sinon, "arandr", du paquet du même nom, permet d'avoir une petite interface de configuration des écrans, indépendante de l'environnement de bureau. Ça devrait plutôt bien s'intégrer dans votre environnement Openbox. Bien à vous, -- Étienne Mollier 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Thunderbird ne veut pas passer en français
Bonsoir, Je viens de rencontrer le même problème dans Sid, « pour voir ». Mais j'ai pu m'en sortir en changeant l'environnement de Thunderbird. À tout hasard, qu'est ce que ça donne en lançant le MUA avec la commande suivante : env LANG=fr_FR.UTF-8 thunderbird De mon côté il me manquait aussi le paquet thunderbird-l10n-fr, mais de ce que je comprends des échanges, il est déjà présent. Amicalement, -- Étienne Mollier 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Répertoire source de Linux
Jean Bernon, au 2019-07-09 : > Je viens de migrer sans problème de Stretch à Buster. Mais > j'utilise un driver wifi/bluetooth spécial (mt7630e) que je > dois réinstaller à chaque changement de version Linux. Les > scripts d'installation ont fonctionné sans problème depuis 5 > ans. Avec Buster le script d'installation du wifi a bien > fonctionné. En revanche côté bluetooth, le script qui patche > btusb.c et génére un btusb.ko modifié, bute sur la création > d'un répertoire source de Linux. Il y a un problème inédit de > source signé et non signé que je comprends mal. En tout cas le > script veut désinstaller linux-image-4.19 et installer à la > place une version non signée. Voir ci-dessous. > > Si je réponds OK, j'obtiens un ferme avertissement de ne pas > continuer... > > Qui aurait une suggestion pour en sortir sans tout casser ? Bonsoir, Les paquets linux signés et non-signés le sont au sens du « UEFI Secure Boot », dont le support est apparu en Debian 10. En utilisant un paquet non-signé, le boot UEFI Secure Boot ne sera plus possible. Étant donné que vous avez migré depuis Debian Stretch, je suppose que vous n'avez pas activé cette option de sécurité entre temps. À mon sens, il n'y a pas de risque majeur de casse. Bien à vous, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Répertoire source de Linux
Jean Bernon, au 2019-07-11 : > Pour compléter notre échange, je crois comprendre ceci. Le > paquet linux-image-4-19... officiel est signé. Buster utilise > l'option "secure boot" du bios (si elle est choisie) et > vérifie la signature de l'image chargée au boot. Si on > applique le patch du module bluetooth, le linux-image-4-19-... > chargé au boot n'est plus exactement l'officiel, mais une > variante qui doit avoir une autre signature (si option "secure > boot") ou qui peut rester sans signature (si l'on n'utilise > pas l'option bios "secure boot"). Ai-je bien compris ? Bonsoir, Buster supporte le démarrage en UEFI Secure Boot qui, effectivement, procède à la vérification du noyau chargé au démarrage de la machine. Sans faire autorité en la matière, je dirais que c'est l'idée. Le détail de ce qui est vérifié, et à quel moment, entre le chargeur de démarrage Grub, le RAM FS initial, et finalement le chargement du noyau, m'échappe encore, pour être honnête avec vous. Si vous souhaitez signer vos propre noyaux, Greg Kroah Hartman a eu l'occasion de travailler avec le groupe UEFI.org pour définir la procédure qu'il a publié sur son blog : http://www.kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/ Ça date de 2013, et c'est en Anglais, mais c'est peut-être encore valable, si le sujet vous intéresse. Je n'ai pas trop l'occasion de vérifier, mon matériel personnel est trop ancien pour supporter le démarrage UEFI. Bien à vous, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Debian 10 nouvellement installée - Comment vérifier la sécurisation ?
llement de reporter la modification dans FAI pour les installations futures. (Note à part: il y a bien un mécanisme fai-update qui permet de passer des mises à jour, mais il est loin d'être aussi souple que des spécifications Puppet ou Ansible, et ce mécano oblige à rédiger les scripts de post-installation du système de manière idempotente: l'appliquer une fois ou plusieurs doit toujours donner la même situation finale.) > Je ne sais pas s'ils fournissent une configuration des > machines pré-établie ou si on doit définir la sienne à partir > d'une feuille blanche. Un répertoire /srv/fai/config est fourni en exemple dans les fichiers d'installation, un rappel est affiché à la fin de l'exécution de `fai-setup` ; la lecture de la documentation est fortement recommandée pour situer le contexte : http://fai-project.org/fai-guide/ Étant donné la complexité du programme, ce point de départ est plus que bienvenu. Mais les exemples proposés ne vont pas forcément très loin non plus : ils permettent grosso modo de faire des installations de base, et présentent divers concepts (host classes, disk config, packages list, scripts, files, hooks, base archive, etc). Amicalement, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Xorg en "dual-head dual-graphics card AMD/ATI 570 + 6450"
Basile Starynkevitch, au 2019-07-18 : > et ce, malgré ce fichier xorg.conf ci - dessous... (obtenu par > Xorg -config, puis largement bidouillé). [...] > > Section "Device" > Identifier "BasileBigCard" [...] > Driver "amdgpu" > BusID "PCI:10:0:0" > EndSection > > > Section "Device" > Identifier "BasileSmallCard" [...] > Driver "amdgpu" > BusID "PCI:66:0:0" > EndSection [...] > Et mon noyau a > > rimski.x86_64 ~ 2:12 .0 % lsmod |grep amd [...] > drm_kms_helper200704 2 amdgpu,radeon Bonsoir Basile, J'ai l'impression que votre carte HD6450 est pilotée par le module "radeon" et non "amdgpu". Peut-être que vous devriez signaler à Xorg de travailler avec ces deux pilotes différents ; je ne sais pas à quel point c'est supporté cependant. Je ne crois pas que la HD6450 supporte "amdgpu" ; ma vieille HD4770, remplacée récement par une RX560, était trop ancienne pour "amdgpu" et ne fonctionnait qu'avec "radeon". À en juger par le chapitre suivant sur le Wiki d'Arch Linux, ce pourrait bien être aussi le cas de votre carte : https://wiki.archlinux.org/index.php/Xorg#AMD > Avez vous des idées pour m'aider? En espérant que ça aide effectivement, Amicalement, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: Une erreur dans les messgaes de boot que j'aimerais corriger !
toto, au 2019-07-23 : > 1) acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM > > 2) ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.GFX0.DD02._BCL], > AE_NOT_FOUND (20180810/psargs-330) > ACPI Error: Method parse/execution failed \_SB.PCI0.RP05.PEGP.DD02._BCL, > AE_NOT_FOUND (20180810/psparse-516) Bonjour, Pour complémenter la réponse de Pascal, ces messages sont engendrés par la détection d'un certain niveau de support pour la gestion de l'énergie sur divers composants de votre machine, mais le noyau échoue à l'implémenter. Une raison assez courante est que le matériel ne publie pas correctement ces informations au noyau, qui préférera alors ne pas faire usage de ces fonctionnalités, et s'en plaindra bruyamment dans `dmesg` dans la manœuvre. La conséquence de ce genre de message est que votre machine économise un peut moins d'électricité que ce qu'elle pourrait, en laissant les composants non gérés sous tension. Ceci étant, il vaut mieux avoir un composant qui reste sous tension, plutôt qu'un composant qui n'arrive pas à redémarrer après veille... Étant donné que la correction de genre de bug requiert de mettre à jour le firmware de la carte mère, opération relativement simple, mais peu anodine car pouvant briquer la machine si une coupure de courant a lieu pendant la procédure, et que les effets ne sont pas ou peu remarquables sans faire de mesures ; j'ai comme l'impression que beaucoup de monde range ce genre de message relatif à l'ACPI, soit dans la catégorie « bruit », soit dans la catégorie « cause perdue ». Ça dépend des sensibilités. Assez paradoxalement, les mises à jour fréquentes de noyau ont tendance à faire apparaître de plus en plus de message de ce genre sur une carte mère donnée. L'article de Wikipedia en Anglais sur le sujet n'est pas de la plus grande qualité, mais globalement, la question de standardiser cette couche a fini par être confiée au groupe ayant en charge l'UEFI : https://en.wikipedia.org/wiki/Acpi https://uefi.org/specifications Toute la partie relative à la carte mère a l'air désormais unifié autour d'UEFI.org. Pendant ce temps, sur le traqueur de bugs du noyau : https://bugzilla.kernel.org/buglist.cgi?no_redirect=0&quicksearch=acpi En bref, cette affaire a un petit côté « tonneau des Danaïdes ». Je comprendrais que le sujet refroidisse du monde. Si vous vous sentez de mettre à jour votre carte mère, ça peut éventuellement avoir un effet positif quant à corriger ces messages. Sinon, ça ne devrait pas avoir une incidence excessivement néfaste de les négliger. Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
G2PC, au 2019-08-16 :
> .bashrc
> alias mediawiki1='/usr/bin/php
> /var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete'
>
>
> crontab -e
> 01 10 * * * bash -ic "mediawiki1 >> /var/log/cron-dropbox.log 2>&1"
Bonjour,
D'après le manuel de bash(1), section ALIASES, les alias ne sont
pas évalués quand le shell n'est pas interactif, à moins
d'utiliser l'option "expand_aliases" en tête du script, via
"shopt". Je suppose que c'est ce qui vous a motivé à lancer le
script Bash avec l'option "-i". Sauf que le « pseudo terminal »
fourni par l'environnement de cron ne fournit aucune manière
d'interagir, d'où l'erreur :
> bash: impossible de régler le groupe de processus du terminal (20286):
> Ioctl() inapproprié pour un périphérique
> bash: pas de contrôle de tâche dans ce shell
Je pense que vous vous en sortirez mieux simplement à coup de :
01 10 * * * /usr/bin/php
/var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php --delete >>
/var/log/cron-dropbox.log 2>&1
Ou alors, si comme moi vous n'aimez par les longues lignes, en
lançant un script exécutable /root/bin/mediawiki, par exemple :
#!/bin/bash
exec /usr/bin/php \
/var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php \
--delete >> /var/log/cron-dropbox.log 2>&1
Qui serait appelé comme ceci :
01 10 * * * /root/bin/mediawiki
Ou bien alors comme cela si le fichier n'est pas exécutable :
01 10 * * * /bin/bash /root/bin/mediawiki
Amicalement,
--
Étienne Mollier
5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
signature.asc
Description: OpenPGP digital signature
Re: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
On 16/08/2019 22.23, Étienne Mollier wrote: > Qui serait appelé comme ceci : > > 01 10 * * * /root/bin/mediawiki > > Ou bien alors comme cela si le fichier n'est pas exécutable : > > 01 10 * * * /bin/bash /root/bin/mediawiki Hum, bien sûr remplacez root par l'utilisateur en charge dudit mediawiki... ;) 01 10 * * * /bin/bash "$HOME/bin/mediawiki" Amicalement, -- Étienne Mollier 5AB1 4EDF 63BB CCFF 8B54 2FA9 59DA 56FE FFF3 882D signature.asc Description: OpenPGP digital signature
Re: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique
G2PC, au 2019-08-17 :
> Trompé dans ma précédente réponse, ok, je tente votre proposition en
> appelant le script depuis crontab.
> De ce fait, cela ne me permet pas d'utiliser les alias dans crontab.
>
> J'aurais souhaité un contournement, pour ne pas avoir à supporter le
> message d'erreur pour me permettre d'utiliser les alias.
> bash -ic "mediawiki1 >> /var/log/cron-dropbox.log 2>&1"
Bonjour,
Laissez donc de côté les alias en situation de scripting, ce qui
inclue le travail avec cron. Cet outil n'est réellement qu'une
commodité pour le travail en mode interactif, afin de raccourcir
certaines commandes usuelles à quelques caractères. Les alias
sont d'ailleurs désactivés en shell script à dessein, pour
éviter leur usage dans ce contexte.
Pour les opérations un tantinet plus avancées, préférez les
scripts à part entière. Ça vous évitera d'avoir un fichier
.bashrc enflé jusqu'à démesure, et rendra plus rapide, et moins
gourmande en mémoire l'exécution de votre shell au jour le jour.
Ou à minima utilisez des fonctions. En l'occurrence, vous aurez
les même problèmes pour les charger dans l'environnement de cron
que les alias. Mais en général, vous pourrez lancer des
commandes plus construites, réellement gérer les arguments,
avoir possibilité de les déclencher par des "trap" pour gérer
les exceptions, etc:
mediawiki-cleanup () {
/usr/bin/php \
/var/www/wiki.domaine.fr/maintenance/deleteOldRevisions.php \
--delete
}
Librement,
--
Étienne Mollier
5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
Toute opinion exprimée ici est mienne.
signature.asc
Description: OpenPGP digital signature
Choix de langage de script adapté (Was: bash: impossible de régler le groupe de processus du terminal (20286): Ioctl() inapproprié pour un périphérique)
Basile Starynkevitch, au 2019-08-21: >On 8/21/19 1:27 AM, G2PC wrote: >> Le 18/08/2019 à 12:19, Étienne Mollier a écrit : >>> Pour les opérations un tantinet plus avancées, préférez les >>> scripts à part entière. >En particulier, considérez les scripts dans des langages >meilleurs que Bash, par exemple GNU guile (qui est qualifié de >langage de script préférentiel pour GNU) ou Lua. Vrai : Bash est avant tout un shell interactif, avec les limitations qu'impliquent la concision et l'exécution séquentielle des instructions. Rédiger un script robuste dans ce langage est une tâche qui nécessite un apprentissage de règles peu intuitives, au risque de se prendre les pieds dans le tapis ; je pense aux règles relatives à l'usage des guillemets, ou la poursuite de l'exécution d'un script après qu'une erreur ait eu lieu, comportement par défaut à contrer en utilisant l'option "set -e". À mon sens le meilleur langage à utiliser est celui adapté à la tâche ou à l'environnement général de travail. Bien souvent, les administrateurs système tendent à s'en tenir à Bash parce que quasiment tous les scripts du système sont rédigé dans ce langage, ou son parent /bin/sh. Bien sûr il y a deux ou trois exceptions, comme les fichiers de configuration en m4 de Postfix, ou bien du NIS, qu'il faut penser à compiler avant de donner à manger au dæmon, mais ce genre de déviation est relativement rare. De ce que je comprends, dans le cas présent, le gros du travail effectué par le script mediawiki1 était en fait effectué par un autre langage, le PHP, usuellement considéré comme adapté pour construire dynamiquement des pages en HTML. Bash ne servait que d'enrobage pour faciliter le lancement du script tout en ajoutant une fine couche d'enregistrement dans un fichier de journal. Pour faire un peu de tout, le langage Python revient souvent en entreprise ces dernières années. Ce n'est pas forcément le langage le plus amusant du monde, mais par défaut il est très clair à lire et relativement robuste (sauf peut-être pour les allergiques au typage dynamique) ; il faut le faire exprès pour rédiger un script Python comme un cochon. Dans les situation où la vitesse d'exécution prime, le bon vieux langage C est plus efficace que jamais, à condition de bien l'utiliser, comme pour tout ; mais on sort complètement du cadre des langages de script. J'ai eu quelque discussions avec un collègue sur l'usage des langages à paradigme fonctionnels ; je dois admettre que Guile a l'air tentant pour me mettre le pied à l'étrier (non ce n'est pas à cause de la publicité autour de l'interfaçage avec le langage C. :) >Observez aussi que GNU emacs est scriptable en E-lisp (et sait >"presque" tout faire). Est ce que « faire ma vaisselle » fait partie du « "presque" tout » ? :) Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d « Java est en quelque sorte le Cobol du XXIe siècle. » -- Larry Wall Source: https://www.youtube.com/watch?v=LR8fQiskYII Transcription (hachée): http://blog.mattcallanan.net/2013/03/larry-wall-5-programming-languages.html signature.asc Description: OpenPGP digital signature
Re: deux connections Internet sur le meme poste Debian Buster
Basile Starynkevitch, au 2019-08-21: > % ip route > default via 192.168.1.1 dev enp8s0 proto dhcp metric 100 > default via 192.168.4.1 dev enp10s0 proto dhcp metric 101 > 192.168.0.0/23 dev enp8s0 proto kernel scope link src 192.168.1.10 metric 100 > 192.168.4.0/24 dev enp10s0 proto kernel scope link src 192.168.4.3 metric 101 > > > La fibre optique usuelle ou principale est enp8s0 et l'adresse > principale de cette machine est 192.168.1.10 > > Ma motivation c'est de préparer à l'avance la transition vers > Free (qui irait vers enp10s0). Je souhaite un "dyndns" (car je > ssh du bureau vers la maison; les deux postes au taf et chez moi > étant sous Debian; chez moi j'ai deux cartes ethernet et deux > fibres optiques). Le 192.168.0.0/23 me chiffonne un peu dans votre "ip route", je me serais attendu à un 192.168.1.0/24, mais peut-être que vous avez vos raisons. Les réseaux internes 192.168.0.0/16 sont en fait un ensemble de réseaux de classe C (CIDR/24) et non un seul réseau de classe B (CIDR/16), si je n'écris pas de bêtises. Autrement, la configuration me semble déjà cohérente, modulo le fait qu'il faudra que la Freebox gère le réseau 192.168.4.0/24 à la réception, sinon le routage risque d'être un peu compliqué si les deux boxes se disputent le 192.168.1.0/24. Côté Internet, étant donné que Free pratique le partage d'adresse IP publique en séparant les plages de ports en quatre, vous allez très probablement vouloir demander une IP publique statique complète (l'année dernière il m'a suffit de demander poliment aux pages dédié aux clients chez free.fr). Sans cela, vous avez trois chances sur quatre d'obtenir une plage de ports ne comprenant pas le port 22 pour votre serveur SSH (je m'étais retrouvé avec la plage de ports 49152-65535). Je crois bien qu'une fois que l'adresse IP est fixée, le DynDNS ne vous est plus utile ; ou alors, j'ai mal compris le besoin. Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d PS: Buster n'est plus testing depuis Juillet, c'est Bullseye. :) (Oui, je sais, on n'a pas fini de se mélanger les pinceaux.) signature.asc Description: OpenPGP digital signature
Re: Problème de firware pour le wifi et le bluetooth
Dominique Simeone, au 2019-08-21: > j'essaie d'installer le wifi et le bluetooth sans succès avec les tutoriels. > > Voici ce que j'obtiens [... transcription approximative et partielle de l'image jointe: > [ 10.n] iwlwifi :0a:00.0: firmware failed to load for > iwlwifi-6000g2a-5.ucode (-2) ... > [ 11.m] bluetooth hci0: Direct firmware load for > brcm/BCM20702A0-0489-e01.hcd failed with error -2 ...] > Que puis-je faire? Dois-je les télécharger moi-même? > > Car ma carte wifi n'est pas reconnu. Bonjour, Les firmware listés par votre commande "dmesg" sont disponibles dans le paquet intitulé "firmware-iwlwifi". Ce paquet est non-libre, au cas où vous considéreriez cet aspect comme gênant. Si vous avez accès au réseau, alors vérifiez que votre gestionnaire de paquets est configuré pour autoriser les installations de paquets depuis ce dépôt "non-free", qui n'est pas actif par défaut. Ceci fait, déclenchez une update et puis vous pouvez installer le paquet. Si vous n'avez pas accès au réseau, alors vous pouvez récupérer manuellement ce paquet depuis l'un des miroirs Debian disponible à travers le monde depuis une autre machine. Par exemple si vous êtes en France, le paquet sur le miroir le plus proche serait accessible ici: http://ftp.fr.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20190114-1_all.deb Une fois téléchargé, copiez le fichier .deb sur une clé USB, que vous pourrez raccorder ensuite sur la machine ayant besoin des firmware, et vous pourrez installer le paquet manuellement. Par exemple avec la commande suivante: $ sudo apt install /media/VOTRE_CLÉ/firmware-iwlwifi_20190114-1_all.deb Pour les messages en rapport avec la puce bluetooth, je n'ai pas localisé les firmware correspondants dans les paquets Debian 10 pour le moment, j'aurais pensé au "firmware-brcm80211" mais il n'a pas l'air d'y être. Ou alors j'ai mal lu le nom du fichier. Pour finir, voilà une astuce: pour copier et coller le contenu texte d'un terminal, vous pouvez le sélectionner avec la souris, puis dans un éditeur de texte ou directement dans votre courrielleur, vous pouvez faire soit un clic-milieu, soit la combinaison de touche pour coller la sélection. Ça sera beaucoup plus pratique, frugal, et accessible, que de transférer des images. :) Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: deux connections Internet sur le meme poste Debian Buster
Pascal Hambourg, au 2019-08-21 : > Le 21/08/2019 à 18:09, Étienne Mollier a écrit : > > > > Le 192.168.0.0/23 me chiffonne un peu dans votre "ip route", je > > me serais attendu à un 192.168.1.0/24, mais peut-être que vous > > avez vos raisons. Les réseaux internes 192.168.0.0/16 sont en > > fait un ensemble de réseaux de classe C (CIDR/24) et non un seul > > réseau de classe B (CIDR/16), si je n'écris pas de bêtises. > > Les classes sont obsolètes depuis l'entrée en vigueur de CIDR > (dont le C signifie "classless"). Donc on peut bien découper > comme on veut. Je conçois assez bien que les classes soient obsolète. C'est pour le découpage que j'ai eu un doute, mais après révision de mes classiques (RFC 1918, section 3), les plages de réseaux internes sont 10.0.0.0/8, 172.16.0.0/12 et dans le cas qui nous intéresse 192.168.0.0/16 (et pas un ensemble de 192.168.x.0/24 à découper comme suit), donc tout va bien : https://tools.ietf.org/html/rfc1918 Et j'ai effectivement écrit des bêtises. (: Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Problème de firware pour le wifi et le bluetooth
Dominique Simeone, au 2019-08-21 : > Bonsoir, > > je reviens vers vous pour le Bluetooth, j'ai un problème de firmware > > root@dominique:~# dmesg | grep bluetooth > [ 12.509269] bluetooth hci0: firmware: failed to load > brcm/BCM20702A0-0489-e031.hcd (-2) > [ 12.509487] bluetooth hci0: Direct firmware load for > brcm/BCM20702A0-0489-e031.hcd failed with error -2 > > Que dois-je faire? > > Bien cordialement. > > Mr.Dominique Simeone Bonjour, D'autres membres de la liste seront probablement plus au point que moi sur la partie bluetooth. Mieux vaut donc la laisser dans la boucle. Avec un peu de chance vous pourrez vous en sortir en utilisant le paquet "firmware-brcm80211", voir "firmware-nonfree", qui tire avec lui la quasi-totalité des firmware non-libres. Mais je n'ai pas croisé les fichiers correspondants dans les paquets, donc ça peut ne pas suffire, auquel cas il faut voir si le fabriquant de la puce bluetooth ne fournit pas le binaire adéquat sur son site web. Après, j'ai peur de ne pas vous être d'une grande aide, la seule fois que j'ai tenté d'installer des composants bluetooth il y a quelques années, pour quelqu'un, j'ai fini par jeter l'éponge et demander moi-même de l'aide à un utilisateur de GNU/Linux habitué à manipuler ce genre de matériel ; je n'ai ni puce ni gadget bluetooth chez moi. Peut-être que les informations fournies dans le wiki à ce sujet seront suffisamment fraîches : https://wiki.debian.org/fr/BluetoothUser Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: debian et UEFI
On 27/08/2019 20.20, Basile Starynkevitch wrote: > Puis-je configurer cet UEFI depuis Debian en ligne de commande? Par exemple, > l'ordre de boot, l'overclocking léger, le redémarrage automatique, etc. Si > oui, comment? Bonsoir Basile, Sans avoir creusé dans les arcanes de cette commande (et sans machine UEFI à portée de main à l'instant /t/), je dirais que efibootmgr est censé savoir gérer au moins une fraction de ce cahier des charges : $ apt show efibootmgr [...] Description: Interact with the EFI Boot Manager This is a Linux user-space application to modify the Intel Extensible Firmware Interface (EFI) Boot Manager configuration. This application can create and destroy boot entries, change the boot order, change the next running boot option, and more. Amicalement, -- Étienne Mollier 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Configuration de la variable d'environnement HOME
François-Marie Billard, au 2019-08-31 : > Je cherche à savoir ou configure la valeur de la variable > d'environnement HOME, suite à un problème du à un ajout du > second disque pour y mettre le /home dont je décris la procédure > ci-dessous : > > * J'ai créer un utilisateur de test , puis copié les données de >son répertoire /home/test sur le nouveau disque. Avec les >mêmes droits. > * J'ai modifié dans le fichier fstab la ligne du /home avec >l'UUID du nouveau disque > > Au reboot et je découvre que lors du logging en mode texte avec > mon utilisateur de test la variable HOME n'est pas configurée. > Un logging via l'interface graphique boucle instantanément sur > la fenêtre de logging. Bonjour, Quelle procédure avez vous utilisé pour créer "test" ? Normalement, si la variable HOME ne fait pas partie de l'environnement, alors le shell va chercher sa définition dans le fichier /etc/passwd, voir passwd(5) pour plus de détails sur le format du fichier. Par exemple, pour mon utilisateur, j'ai : $ grep emollier /etc/passwd emollier:x:1000:1000:Etienne Mollier,,,:/home/emollier:/bin/bash ^~~~USER ^UID ^~HOME ^~~~SHELL Cette entrée permet de remplir, outre HOME, quelques variables supplémentaires, indiquées ci-dessus. Si vous voulez vraiment creuser dans les détails, en tout cas pour le shell Bash, le code source décrit exactement la procédure suivie: - la fonction get_current_user_info() définie dans shell.c s'occupe de récupérer les informations stockées dans une structure après lecture du fichier /etc/passwd ; - la fonction set_home_var() de variables.c va s'occuper de remplir la variable d'environnement HOME, si elle n'est pas déjà Bien sûr, si vous utilisez un autre shell que Bash, alors la procédure exactement suivie peut être un chouïa différente, mais c'est l'idée. :) Amicalement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Hibernation par défaut sous Buster ?
Bertrand Delaunay, au 2019-09-01 : > Après avoir fait une mise à niveau depuis Stretch, j'ai remarqué qu'à > chaque redémarrage (après extinction complète), le message "resuming > from hibernation" apparaît. Est-ce que c'est normal ? Bonjour, Juste pour vous confirmer que vous n'êtes pas seul, j'ai eu l'occasion de constater ce message au démarrage de machines Debian 10 fraîchement installées. Au tout premier démarrage de l'OS, après installation, ce message est assez succulent. :p À en juger par le système de suivi de bugs, le problème provient d'une erreur de formulation dans les messages fournis par plymouth, donc peut-être que le message sera modifié dans un avenir plus ou moins proche (pour Debian 10.1 ?) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928736 Librement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Mise à jour du noyau et pilotes réseau Intel compilés
Olivier, au 2019-09-24 : > Je serai très curieux de recueillir ici des retours > d'expérience sur l'utilisation de DKMS en production. Bonjour, Je ne sais pas si ça compte comme un « usage en production », mais un certain nombre de paquets Debian fournissent des pilotes tiers non disponibles directement dans Linux, mais qui s'installent justement via DKMS. Ces paquets ont en général un nom qui termine en "-dkms", quelques exemples au hasard tirés de la commande "apt search '.*-dkms$'" : - aufs-dkms, - nvidia-kernel-dkms, - virtualbox-dkms, - zfs-dkms, - etc. Pour les configurations qui ne dévient pas de Debian, il n'y a pas de problèmes particuliers à noter. Mais s'il y en a, alors ça vaut le coup de les rapporter dans le système de suivi de bogues. Pour les configurations un peu plus sioux, ou de test et développement, ou quand quelque chose plante lors d'une mise à jour du pilote ou du noyau, le comportement de DKMS peut parfois être assez opaque. Les journaux de compilation, nécessaires à la phase de débogue, sont cachés au fin fond d'une arborescence de fichiers qui, malgré la convention de nommage, peuvent être écrasés par la compilation suivante, notamment en tentant de construire un pilote donné sur plusieurs noyaux différents. D'autre part, la commande "dkms status" a une sortie qui n'est pas forcément très claire sur le statut des pilotes en fonction des noyaux, pour indiquer les combinaisons qui marchent, et celles qui ne marchent pas. De mémoire, il me semble que sont indiqués: (1) les pilotes qui se sont proprement installés, et (2) ceux qui ont été proprement compilés sans être installés. Les pilotes qui n'ont pas passé l'étape de la compilation ne sont pas indiqués, et les pilotes qui ne sont que compilés ne sont pas pour autant utilisables: il faut parfois bricoler un peu avec la commande "dkms install" pour pousser le tout. Enfin, dernier point, le pilote doit supporter d'être installé via DKMS, ce qui consiste à minima en un fichier dkms.conf avec les méta-informations nécessaires à la compilation du paquets, sa version, sa compatibilité avec les différents niveaux de noyau, etc. Pour mes machines personnelles, je n'ai pas eu besoin de pilotes DKMS jusqu'à présent, du coup je suis un peu en mal d'être plus précis ; mais c'est ce dont je me souviens de mes petits travaux antérieurs. L'outil n'a pas forcément très bonne réputation, mais c'est l'un des seuls disponibles, avec "module-assistant" si j'en croie le cahier des administrateurs Debian section 8.10.5 [1], pour empaqueter les pilotes tiers. DKMS a le mérite d'exister donc. [1] https://www.debian.org/doc/manuals/debian-handbook/sect.kernel-compilation.en.html La « bonne méthode » consisterait a porter le pilote directement dans le code source du noyau (drivers/) afin qu'il puisse bénéficier automatiquement des mises à jour rendues nécessaires par la façon dont le code source de Linux lui-même évolue ; les développeurs noyaux passent des scripts quand l'API change, ce qui peut arriver à chaque nouvelle version stable. Amicalement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Jeux vidéo
Jean-Philippe Mengual, au 2019-09-24 : > Vous savez où je pourrais trouver un "guide" pour savoir les jeux > offerts sur Debian? Pour voir par exemple les thématiques, les jeux > traduits,? Par exemple, quel bon jeu de démineur, cartes, échecs, etc? Bonjour, Le portail des jeux vidéos du Wiki de Debian me semble être un point de départ sympathique: https://wiki.debian.org/Game Ce n'est probablement pas le plus beau catalogue de jeux-vidéos, mais les paquets de la section "games" sont recensés ici, si vous cherchez quelque chose d'exhaustif : https://packages.debian.org/stable/games/ Je crois que la commande aptitude permet de naviguer dans la liste des paquets en fonction de leur section, mais n'ai rien trouvé de tel dans apt(8) ou apt-cache(8). Et c'est avec une agréable surprise que je découvre Dwarf Fortress dans la liste des paquets, non-libres certes. Sinon mon implémentation de démineur favorite est celle fournie par le paquet "sgt-puzzles", commande "sgt-mines". :) Amicalement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: mount: /mnt: /dev/sdb1 n'est pas un périphérique bloc valable
:28:44 Iznogood kernel: [148803.790160] > > > > rescan_partitions+0x140/0x270 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790164] > > > > __blkdev_get+0x38a/0x550 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790167] blkdev_get+0x107/0x310 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790170] ? > > > > unlock_new_inode+0x48/0x60 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790172] ? bdget+0x12d/0x150 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790175] ? > > > > kobject_put+0x23/0x1b0 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790177] > > > > __device_add_disk+0x3a6/0x450 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790184] > > > > sd_probe_async+0xf5/0x220 [sd_mod] > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790187] > > > > async_run_entry_fn+0x39/0x160 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790190] > > > > process_one_work+0x1a7/0x3a0 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790193] > > > > worker_thread+0x30/0x390 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790195] ? > > > > create_worker+0x1a0/0x1a0 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790197] kthread+0x112/0x130 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790203] ret_from_fork+0x22/0x40 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.790213] sdb: p1 could not be > > > > added: 17 > > > > Sep 26 09:28:44 Iznogood kernel: [148803.795765] sd 9:0:0:0: [sdb] > > > > Attached SCSI disk Le noyau a commencé à exploser en vol au moment d'ajouter la première partition disque USB dans la table des devices. Ça vaudrait le coup de : 0. redémarrer la machine, pour ne pas laisser tourner un noyau dans un état douteux; 1. mettre à jour le noyau en version 4.19.0-6 (outre les mises à jour de sécurité, le numéro de version mineur est passé de 37 à 67, avec pas mal de corrections de bug dans le lot); 2. voir si le problème se reproduit sur un noyau à jour et, si possible, non teinté. Amicalement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: killall ne kille plus ?
Seb, au 2019-09-26 : > Le passage de Debian 9 à Debian 10 semble avoir modifié le > comportement de killall. Exemple: > > ~>ps auxw | grep simplescreen > seb 13630 2.3 0.7 393012 64192 pts/31 Sl+ 15:31 0:00 > simplescreenrecorder > > ~>killall simplescreenrecorder > simplescreenrecorder: no process found > > ~>killall -e simplescreenrecorder > simplescreenrecorder: no process found > > ~>kill 13630 > ~> > > Donc kill fait bien le boulot, mais killall ne retrouve pas la > bonne ligne. (Du coup, un script qui marchait sans problème > depuis des années est tombé en panne.) Je n'ai pas trouvé > d'information dans la page de man de killall, qui est d'ailleurs > exactement la même en Debian 9 et en Debian 10. > > Sauriez-vous comment faire retomber killall en marche ? À en juger par le manuel de killall(1) fournie dans Sid, à la description de l'option -e (--exact) le comportement de la commande devient… curieux… dès lors que le nom du processus dépasse 15 caractères. Avec cette information en tête, les commandes suivantes sont tombées en marche : $ killall simplescreenrec $ killall -e simplescreenrec killall ne m'a pas l'air très solide à l'usage. Quand je peux, je préfère me référer à un fichier PID dans les scripts. Apparemment, à moins de préciser un --statsfile particulier, simplescreenrecorder(1) va crééer par défaut un fichier /dev/shm/simplescreenrecorder-stats-PID, si j'en croie son manuel. Il y a peut-être moyen de travailler avec ça ? Amicalement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: killall ne kille plus ?
Bonsoir,
Seb, au 2019-09-30 :
> > À en juger par le manuel de killall(1) fournie dans Sid, à
> > la description de l'option -e (--exact) le comportement de
> > la commande devient? curieux? dès lors que le nom du
> > processus dépasse 15 caractères. Avec cette information en
> > tête, les commandes suivantes sont tombées en marche :
> > $ killall simplescreenrec
> > $ killall -e simplescreenrec
>
> Aaaahh... Merci !!
Je vous en prie. :)
> Après avoir lancé simplescreenrecorder, /dev/shm reste vide.
Dommage, ça aurait été pratique d'avoir des fichiers PID, pour
vérifier que l'on va bien tuer ce qu'on voulait tuer. :(
> (Et pkill ne tue pas non plus simplescreenrecorder.)
À la lecture de pkill(1), la limite à 15 caractères proviendrait
de la façon dont sont obtenus les noms des processus, méthode
qui, j'imagine, devrait être similaire pour killall :
NOTES
The process name used for matching is limited to the 15
characters present in the output of /proc/pid/stat. Use
the -f option to match against the complete command
line, /proc/pid/cmdline.
En français rapide, /proc/pid/stat tronque le nom du process à
15 caractères, et l'option -f permet de basculer sur le fichier
/proc/pid/cmdline pour contrôler le nom du process à tuer. Du
coup, dans le cas qui nous intéresse, les commandes valides
deviennent :
$ pkill simplescreenrec
$ pkill -f simplescreenrecorder # Notez le nom complet.
À plus, :)
--
Étienne Mollier
Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
signature.asc
Description: OpenPGP digital signature
Re: pas de son avec firefox
On 04/10/2019 08.51, Erwann Le Bras wrote: > bonjour > > après avoir éliminé un dysfonctionnement de l'extension"noisy tab" de FFox : > > PulseAudio a la fâcheuse tendance de me mettre Palemoon et le "Master Volume > control" en mute au démarrage. > > Pour avoir du son, je suis systématiquement obligé d'aller touiller de > "contrôle de volume Pulse Audio" et tout dé-muter... > > cordialement > > Le 02/10/2019 à 16:30, Bernard Schoenacker a écrit : >> bonjour, >> >> j'ai un problème de sortie audio avec firefox 69.0.1 (64 bits) >> et je n'ai pas pu trouver la solution ... >> >> en revanche avec les autres applications tout fonctionne >> convenablement ... >> >> qui pourrait me donner une piste ? >> >> merci pour votre aimable attention >> >> bien à vous >> bernard >> > Bonjour, Un truc à savoir, en particulier pour les mélomanes : par défaut, Pulseaudio corrige (sic) la dynamique des sons en égalisant le volume sonore. Ce comportement a un petit effet secondaire très désagréable qui est de pousser le volume à fond quand Firefox se connecte sur certains sites web qui émettent des sons. Pour faire d'une pierre deux coups, en tant que simple utilisateur, j'ai créé le fichier avec le contenu suivant il y a quelque temps déjà, et redémarré mon daemon Pulseaudio : $ cat ~/.config/pulse/daemon.conf flat-volumes = no Ce problème a été traité il y a quelque temps sur la liste de diffusion internationale, qui décrit la solution à appliquer en tant qu'administrateur, via /etc/pulse/daemon.conf : https://lists.debian.org/debian-user/2019/07/msg01328.html Sans plus d'info, je peux tout à fait être à côté de la plaque ; mais indépendamment du problème initial, c'est un truc à savoir. En espérant que ça aide, À plus, :) -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Grub - Augmenter la taille de police au démarrage
On 05/12/2019 18.10, Daniel Huhardeaux wrote: > Question: comment faire pour augmenter la taille de police en mode console et > lors des messages de démarrage. J'ai tenté un GRUB_GFXMODE=1280x1024 > accompagné d'un GRUB_FONT=/boot/grub/fonts/DejaVuSansMono24.pf2, rien n'y > fait. Bonsoir, Passé 640x480, Grub a également besoin de la profondeur de couleur. Essayez l'option suivante, ça devrait aider : GRUB_GFXMODE=1280x1024x32 ^^^ et puis "update-grub" pour prendre en compte le changement au prochain redémarrage. Une fois que le système est démarré, la console peut être réglée avec le fichier de configuration /etc/default/console-setup et setupcon(1) (ou bien avec "dpkg-reconfigure console-setup"). Dans ce fichier, j'utilise entre autres options : FONTFACE="TerminusBold" FONTSIZE="12x24" Exécuter "setupcon" après modification du fichier permet d'appliquer le changement sur la console. De mémoire, la FONTSIZE="16x32" devrait être disponible, et peut-être même lisible sur un écran 4K de 13,3 pouces. Sinon, il est aussi possible de réduire la résolution de la console après démarrage avec l'option : GRUB_GFXPAYLOAD_LINUX=keep Mais la résolution du serveur X, dépendant du pilote en cours d'utilisation, peut être affectée. Bonne soirée, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: comment configurer /etc/whois.conf avec Free comme FAI
On 07/12/2019 09.29, Basile Starynkevitch wrote: > Actuellement whois 212.37.27.58 reste sans réponse. Mais > https://dnschecker.org/ip-whois-lookup.php m'indique que ça vient de Suède. > > > Il y a deux ans, une commande similaire fonctionnait (à l'époque j'étais chez > Orange, et depuis j'ai réinstallé Debian car changé d'ordinateur) > > > Merci de vos conseils éclairés, je joins mon /etc/whois.conf actuel. Bonjour, D'après votre whois.conf, la machine en charge de la Suède est whois.nic-se.se, mais cette addresse ne résoud pas après des tentatives diverses sur des serveurs DNS connus : $ host whois.nic-se.se Host whois.nic-se.se not found: 3(NXDOMAIN) $ host whois.nic-se.se 9.9.9.9 Using domain server: Name: 9.9.9.9 Address: 9.9.9.9#53 Aliases: Host whois.nic-se.se not found: 3(NXDOMAIN) $ host whois.nic-se.se 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host whois.nic-se.se not found: 3(NXDOMAIN) Ceci pourrait il expliquer celà ? Librement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: comment configurer /etc/whois.conf avec Free comme FAI
On 07/12/2019 10.56, Pascal Hambourg wrote: > Le 07/12/2019 à 10:11, Étienne Mollier a écrit : >> On 07/12/2019 09.29, Basile Starynkevitch wrote: >>> Actuellement whois 212.37.27.58 reste sans réponse. Mais >>> https://dnschecker.org/ip-whois-lookup.php m'indique que ça vient de Suède. > (...) >> D'après votre whois.conf, la machine en charge de la Suède est >> whois.nic-se.se > > C'est le serveur whois défini pour le domaine .se, pas pour les adresses IP > allouées en Suède (qui doivent être gérées par le RIPE). > Effectivement, dans ce cas, j'imagine que ce pourrait être l'entrée suivante qui coincerait : .* whois.com Ce qui par ailleurs semble se confirmer avec : $ whois --host whois.com 212.37.27.58 Timeout. $ whois --host whois.ripe.net 212.37.27.58 [...tout plein de choses...] auquel cas, effacer ou remplacer la ligne incriminée par : .* whois.ripe.net devrait contribuer à régler le problème. Me concernant, je serais partisan d'effacer le fichier de configuration pour laisser whois se débrouiller avec ses valeurs par défaut. Bonne journée, :) -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Choix du système Debian
On 16/01/2020 21.10, Étienne Mollier wrote: > Vous verrez les options pour choisir l'environnement de bureau > (Xfce, Mate, Gnome, etc), la possibilité de chiffrer ou non le > disque, etc, lors de la procédure d'installation en utilisant le > DVD 1 de l'image d'installation Debian i386, disponible en > téléchargement en bas de la page suivante : > > http://cdimage.debian.org/mirror/cdimage/archive/10.1.0/i386/iso-dvd/ > > et dont le guide d'installation pas à pas est disponible ici : > > https://d-i.debian.org/manual/fr.amd64/index.html Je me suis confus, le lien ci-dessus pointe sur la documentation d'installation de Debian 11 Bullseye actuellement en développement pour architecture amd64. Le lien correspondant à Debian 10 Buster stable en i386 est : https://www.debian.org/releases/stable/i386/index.fr.html Amicalement, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: Choix du système Debian
On 16/01/2020 18.35, d cyrille wrote: > Bonjour, > > Je possède un Eeepc Asus 1001PXD avec windows 7 aujourd'hui abandonné par > Microsoft. > Je voudrai redonner vie à ce petit ordinateur pour des applications > bureautique et musique principalement. Internet en consultation. > > > Pouvez-vous m'orienter pour le choix du système Debian le mieux adapté ? > > Caractéristiques > Asus Eeepc 1001 PXD > Intel Atom N455 > Ram 2Go > Système d'exploitation 32 bits > Graphique : Intel graphics media Accelerator 3150 > > > Dans l'attente de votre retour. > > Cordialement > Bonjour, Je possède un Eeepc Asus X101CH que je m'étais procuré neuf il y a sept ans (déjà?), vendu avec Ubuntu 12.04 et son bureau Unity de l'époque. Caractéristiques: - Intel(R) Atom(TM) CPU N2600 @ 1.60GHz - RAM 1Go - Architecture 32 bits - Contrôleur graphique intégré au CPU, module gma900. En le migrant en Debian 7 "Wheezy", à sa sortie en 2013, j'ai installé la sélection de bureau Xfce qui fonctionnait de manière tout à fait honorable. Aujourd'hui j'utilise un environnement graphique différent, mais dont je préfère ne pas recommander l'usage par rapport à vos besoins. Aujourd'hui cette machine tourne en Debian 10, qui plus est avec un disque chiffré pour protéger les données en cas de vol. Et malgré cette option censée affecter négativement les performances de manière notable, la lecture de musique est fluide (et même les vidéos, sur l'écran intégré en 1024x600, alors que ce n'était pas le cas avec Ubuntu 12.04). Sans pour autant se comporter comme un foudre de guerre, Xfce devrait, je crois, encore tourner très bien avec la dernière version de Debian 10 sur ma machine, donc je pense qu'avec la votre, qui a l'air un peu plus pêchue, ça devrait bien se passer. :) Un point noir mineur au tableau idyllique, certaines touches de raccourcis, imprimées sur les touches de fonction F* ne marchent pas. Rien de bloquant, mais si elles marchent avec le système actuellement installé, et que vous avez pris l'habitude de vous en servir, peut-être qu'il faudra revoir votre ergonomie, ou ouvrir un rapport de bug (ceci étant, ça peut aussi venir de mon clavier fatigué). Vous verrez les options pour choisir l'environnement de bureau (Xfce, Mate, Gnome, etc), la possibilité de chiffrer ou non le disque, etc, lors de la procédure d'installation en utilisant le DVD 1 de l'image d'installation Debian i386, disponible en téléchargement en bas de la page suivante : http://cdimage.debian.org/mirror/cdimage/archive/10.1.0/i386/iso-dvd/ et dont le guide d'installation pas à pas est disponible ici : https://d-i.debian.org/manual/fr.amd64/index.html Un conseil vis-à-vis de votre besoin de consulter des pages web, si vous ne le faites pas déjà, utilisez un bloqueur de publicités, voir carrément un bloqueur de scripts. Les cycles CPU sont chers avec les Intel Atom, et la vaste majorité des sites web ont toujours plus tendance à se baffrer en CPU et en mémoire afin vous vendre la dernière lessive à la mode. Amicalement, -- Étienne Mollier Empreinte : 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d signature.asc Description: OpenPGP digital signature
Re: ZSH affiche l'erreur : zsh: bad pattern: e[0
Bonjour, On 04/15/2017 12:00 PM, G2PC wrote: > *Afficher un ascii art au lancement de votre terminal* > > Le code suivant avec ZSH affiche l'erreur : zsh: bad pattern: e[0 > > \e[0;36m. > zsh: bad pattern: e[0 > > > Avez vous une piste pour permettre l'affichage ? On dirait que zsh tente d'interprêter ton code d'échappement au lieu de le passer au terminal. As-tu protégé ta chaîne de caractères avec des doubles quotes? Normalement la commande suivante devrait t'afficher un point vert: echo -e "\e[0;36m." J'ai fait le test en bash, mais le comportement devrait être assez voisin de celui de zsh dans ce cas. À plus, -- Étienne Mollier
Re: Caractère inconnue dans nom de Répertoire
On 04/28/2017 07:50 PM, JF Straeten wrote: > Empêcher toute interprétation du nom avec des quotes simples ? > > mv 'Gers Chambre d'h?te' nom-potable Attention, la fermeture de quote se produit à l'apostrophe entre le "d" et le "h" de "d'h?te". La partie "h?te '" est laissée à libre interprétation du shell (et il va donc se plaindre qu'il lui manque une quote fermante). Est ce qu'une autocompletion avec fonctionne ? À plus, -- Étienne Mollier
Re: Caractère inconnue dans nom de Répertoire
On 04/28/2017 08:08 PM, JF Straeten wrote: > Bien vu ;) > > L'échapper manuellement alors ? > > mv 'Gers Chambre d\'h?te' nom-potable Bonne approche, mais comme le caractère "\" est échappé, la fermeture a encore lieu à l'apostrophe de l'hôte, il faut fermer l'inhibition avant l'échappement puis la réouvrir après : mv 'Gers Chambre d'\''h?te' nom-potable Ceci dit, il est toujours possible que ça ne résolve pas le problème induit par le caractère unicode présent dans la chaîne. À plus -- Étienne Mollier
Re: Caractère inconnue dans nom de Répertoire
Par un beau début de fin de semaine, Philippe Merlin écrivit:
> Bonsoir,
> J'ai un problème facile pour la liste j'ai un nom de Répertoire avec un
> Encodage inconnu :
> le nom du fichier tel qu'est donné par un ls :
> "Gers Chambre d'h?te"
> J'essaye de le renommer par mv et je n'y arrive pas il semble que
> l'apostrophe qui est inclus dans le nom de ce répertoire me crée des soucis.
> Toute idée sera la bienvenue, je sèche lamentablement .
> Philippe Merlin
>
Bonsoir Philippe,
Plusieurs solutions sont possibles. Comme dit plus tôt, pour
commencer il faudrait voir si l'autocomplétion du nom de fichier
en utilisant la touche permet de saisir correctement le nom
de fichier.
Si le caractère Unicode bloque ce mécano, alors il y a une astuce
à base de `find' et de numéro d'inode. Tu peux obtenir le numéro
d'inode de ton fichier avec :
$ ls -i
16125155 Gers Chambre d'h?te
Reporte le numéro dans un find comme suit et le fichier sera
renommé :
$ find . -xdev -inum 16125155 -exec mv '{}' nom-potable ';'
Le fichier devrait enfin être renommé, quel que soit son nom
d'origine. N'oublies pas le "';'" à la fin. Pas de risque de
trouver des doublons de fichiers, par définition les numéros
d'inodes sont uniques pour un système de fichier donné (l'option
`-xdev' est là pour s'assurer que le `find' ne va pas aller
chercher dans d'autres FS).
Il se peut également que tu ais quelques soucis avec la
configuration de la langue de ton environnement, cette sortie est
typique d'une variable LANG soit non réglée, soit réglée sur `C',
auquel cas le problème pourrait être corrigé en réglant la langue
de ton système sur un réglage qui lui est connu et puis en
ouvrant un nouveau terminal comme suit :
export LANG=fr_FR.UTF-8
xterm # ou tout autre terminal de ton choix
mv "Gers Chambre d'hôte" gers-chambres-d-hote
Si ça coince, il faudra reconfigurer les locales, mais
normalement les réglages les plus courant devant résoudre ton
problème sont "fr_FR.UTF-8", "en_US.UTF-8", ou au pire "C.UTF-8".
À plus
--
Étienne Mollier
Re: Migration 32 bits vers 64 bits gros problème avec dpkg testing
que et être capable de tourner juste avec les paquets amd64. Reste à redémarrer la machine pour arrêter les processus 32bits encore en cours d'exécution, tel l'init. Si la machine est capable de redémarrer correctement avec ses services opérationnels après ce traitement, alors la bouteille réservée aux jours de fêtes sera amplement méritée. :-) À plus, -- Étienne Mollier
Re: Migration 32 bits vers 64 bits gros problème avec dpkg testing
On 05/09/2017 07:27 PM, Daniel Caillibaud wrote: > Je me suis demandé pourquoi xargs sur > >> apt-get install $(xargs < packages) > > car en bash le $(< fichierQcq) transforme les \n en espaces, et > je l'utilise depuis des années sans me poser de question, mais > effectivement avec dash (par ex) $( pas la 1re ligne) et xargs est alors nécessaire. Bonjour Daniel, J'aurais aimé dire que c'était voulu, mais à la base, c'était une simple méconnaissance de cette construction de ma part. Merci beaucoup, j'ai appris un truc, très utile qui plus est. :D Effectivement, dépendant des situations, les constructions ne sont pas toujours possibles. Par exemple, si on a cassé la lib C et qu'on ne peut se ratrapper qu'avec un shell `busybox ash', alors la construction utilisable dans ce cas est celle en `xargs'. Et encore, parce que `xargs' est un builtin de busybox. Sinon dans ce cas précis, en `dash', aucune des constructions n'aurait fonctionné. Enfin, en `bash' seule la construction en `$(
Re: Migration 32 bits vers 64 bits gros problème avec dpkg testing
On 05/06/2017 06:50 PM, MERLIN Philippe wrote: > Bonsoir, > J'avance péniblement dans cette migration et j'espérais arriver > à la fin > Las !!! > J'arrive à obtenir un apt-get -f install qui semble cohérent > sauf que python3 a frappé et me bloque, je ne sais pas comment > m'en sortir. Bonsoir Philippe, J'ai pris un peu de temps pour sauvagement torturer une VM Debian afin de voir si j'arrivais à me retrouver dans la même situation. Plein de problèmes se sont produits, mais celui-ci je n'ai pas réussi à le voir passer, faute d'avoir pu réussir à atteindre la fin de mon second crossgrade sans tout casser. Ceci dit, ça m'a permis d'avoir peut-être une idée pour décoincer la situation... > Les scripts de python3 semblent ne pas avoir envisager la > possibilité d'avoir un instant donné deux versions d'un paquet > i386 et amd64 si bien que dpkg -L paquet sort en erreur, à la > main un dpkg -l paquet:i386 marche très bien. > Voici la sortie d'erreur : > > Suppression de python3-pil:i386 (4.0.0-4) ... > dpkg-query: erreur: --listfiles requiert un nom de paquet légal. « > python3-pil » ne l'est pas ; nom de paquet « python3-pil » ambigu avec plus > d'une instance installée Cette erreur se produit dans le script de pre-removal `prerm' extrait du paquet python3-pil_4.0.0-4_amd64.deb, script reproduit ci-dessous: #!/bin/sh set -e # Automatically added by dh_python3: if which py3clean >/dev/null 2>&1; then py3clean -p python3-pil else dpkg -L python3-pil | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' find /usr/lib/python3/dist-packages/ -type d -name __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir fi # End automatically added section La ligne qui produit l'erreur est très probablement celle en `dpkg -L python3-pil | ...' qui gagnerait à être rédigée sous la forme `dpkg -L python3-pil:i386 | ...'. La correction peut être effectuée dans le script enregistré par `dpkg' à l'installation de python3-pil, et qui devrait se nommer /var/lib/dpkg/info/python3-pil:i386.prerm ou si l'architecture n'est pas présente (mais je crains une confusion avec le paquet 64bits dans ce cas) : /var/lib/dpkg/info/python3-pil.prerm Aux écarts de versions près, le contenu ne devrait pas différer du code cité plus haut. Il faudrait relancer la moulinette `apt-get' après modification de ce script et voir comment la situation évolue. À plus, -- Étienne Mollier
Re: Migration 32 bits vers 64 bits gros problème avec dpkg testing
Bonsoir Philippe, On 05/14/2017 12:37 PM, MERLIN Philippe wrote: > Quand j'ouvre une session avec Kdm j'obtiens un écran gris et > le plus étrange c'est que la souris fonctionne, en examinant > attentivement on voit que le serveur X marche également > En regardant .Xsession-errors on voit une erreur que je > retranscris de mémoire > Kdm[1401] pam_ck_connector (kde:session) : noX11 mode > Je me suis dit puisque Kdm me joue un tour essayons Sddm et là > un autre problème impossible d'ouvrir une session car > impossible de passer la phase authentification tous mes comptes > sont refusés. > Remarque : J'avais déjà ce problème en 32 bits mais comme Kdm > fonctionnait je me disais que je regarderais ce problème plus > tard. Je n'ai guère que deux conjectures en tête dans ce cas : 1. Soit le problème est lié au multi arch et un ou plusieurs paquets i386 associés de prêt ou de loin à PAM ou KDM marchent sur les pieds du paquet homologue en amd64. (ConsoleKit?) 2. Soit le problème est bel et bien lié à la configuration de PAM, qui donc serait à revoir, voir à remettre à zéro si applicable, ce que laisse particulièrement penser le symptôme de Sddm. À tout hasard, jette également un œil dans le journal de Xorg : /var/log/Xorg.0.log > Voilà ou j'en suis de ma migration et étant actuellement loin > du poste incriminé, je ne peux continuer mes recherches. Difficile effective de poursuivre sans avoir la machine à portée de main. :) Bon courage pour la fin de la migration -- Étienne Mollier
Re: WannaCry "ransomware" cyber attack :
On 05/15/2017 05:41 PM, Eric Degenetais wrote: > Le 15 mai 2017 à 17:12, a écrit : >> Visiblement, ça a eu de l'effet, puisque de nombreux serveurs sont en panne, >> avec arrêts de multiples services d'entreprises dont des cartes bancaires, >> des robots de chaînes de fabrication... >> André > > Mais que f... une chaîne de production sur internet? Si le vecteur > n'est pas le réseau, quelles ouvertures baroques ont des chaînes de > production pour qu'elles puissent succomber à un virus? > Bonsoir, Afin de limiter la casse, et faute d'éléments dans le feu de l'action, je soupçonne de nombreuses installation d'avoir été arrêtées vendredi soir à titre préventif. Peu importe que les machines aient été vulnérables ou non, vu le peu d'éléments à disposition sur le coup, le plus important était la sûreté des équipements pour le week-end afin d'éventuellement reprendre lundi avec une infrastructure à peu près opérationnelle. Vaut mieux ça que de prendre le risque de laisser une chance à la bestiole de faire son nid dans l'infra pendant le week-end, n'est ce pas ? À plus -- Étienne Mollier
Re: WannaCry "ransomware" cyber attack :
On 05/15/2017 08:57 PM, Thierry Bugier Pineau wrote: > Un jour j'ai lu un article (sur internet) assez amusant de > quelqu'un qui était resté sur windows.. 3.1 ! > > Je crois qu'il y avait déjà des embryons de navigateurs > internet (de mémoire, dixit l'article) . mais ce qui m'a le > plus amusé c'est que l'auteur vante son immunité aux virus > puisqu'aucun encore en activité ne cible (ou ne sait cibler) de > tels systèmes. De plus ils ne seront pas ciblés à l'avenir. > > Les virus de l'époque adoraient se nicher dans les secteurs de > boot des disquettes, même pas sûr qu'ils aillent se copier sur > disque dur. Le format d'exécutable 16 bits doit être maintenant > une barrière à l'infection de .exe ou .dll (supposition > personnelle). > > Je sais pas pour vous, mais ça m'a un peu fait réfléchir. > Pourquoi ne pas y retourner ? En plus, sur nos machines > modernes, ça doit démarrer à une vitesse qui scotcherait > n'importe quel OS sur un SSD ! Le bonheur ! Chut ! Moins fort ! Vous allez attirer de vilains pirates sur ces plate-formes. :-) -- Étienne Mollier
Re: install hors reseau
hamster, le 2017-05-31 : > Pour faire des install hors réseau, je me suis fait un dépot > local comme indiqué dans ce tuto : > https://blog.nicolargo.com/2012/01/creer-un-depot-debian-local-sans-liaison-internet.html > > Ca fonctionne très bien une fois la machine installée, mais > j'arrive pas a l'utiliser pendant l'installation. Dans > l'installeur, au moment de configurer le miroir réseau je peux > choisir "configuration manuelle", mais ca me demande de rentrer > le nom de domaine du miroir. J'ai bien essayé de mettre l'IP > 192.168.56.1 dans la case prévue pour le nom de domaine, mais > ca marche pas. > > Quelqu'un a une idée ? Bonjour, J'ai déjà croisé un problème de ce genre. Si une fois le système installé, les installations de paquets via `apt` requièrent une validation manuelle avant de lancer le téléchargement, pour des histoires de signatures cryptographiques, alors ce sera le cas aussi lors de l'installation initiale du système. Sauf qu'aucun prompt n'apparaîtra pour permettre cette validation et on sera bloqué. Mais si comme dit, tout se passe pour le mieux avec `apt` après installation, alors le problème ne vient peut-être pas de là. Autrement, la manipulation que vous décrivez n'a rien de choquant, j'ai vérifié rapidement en utilisant l'IP d'un dépôt public: - premier champ à remplir : l'adresse IP de la machine hébergeant le dépôt, ici "192.168.56.1", - second champ : le chemin vers le dépôt Debian sur le serveur web, à savoir "/debian/", que ce soit en suivant le tuto ou en utilisant la plupart des dépôts publics. La description des symptômes du problème lors de la tentative de connexion est vague cependant. Comment se manifeste la panne précisément ? Avez-vous pu atteindre la saisie du chemin "/debian/" ? Ou bien est ce que ça s'est bloqué avant ? Un message d'erreur est-il apparu ? Ou bien la machine reste bêtement bloquée (avec éventuellement un message comme quoi une opération a fini en timeout au bout de quelque temps) ? À plus -- Étienne Mollier
Re: [HS] si mon fichier contient la premiere ligne
Charles Plessy, le 2017-06-02 :
> Bonjour, c'est vendredi !
Bonjour, béni soit le vendredi !
> pourquoi s'ennuyer avec des outils standards alors qu'on a Perl
> 6 ?
Pourquoi s'ennuyer avec des outils alors qu'il y a tout ce qu'il
faut, tout frais compilé, au sein même des shells bash 3 et
plus ? :-D
Si le fichier à lire est `fichier`, alors les trois commandes
suivantes devraient marcher :
$ builtin mapfile lignes < "fichier"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
Considérant les fichiers `fichier0` à `fichier3` suivants et leur
contenu :
$ xxd fichier0 # vide
$ xxd fichier1 # une ligne sans caractère de fin de ligne
: 6e6f 656f 6c noeol
$ xxd fichier2 # une ligne avec caractère de fin de ligne
: 656f 6c0aeol.
$ xxd fichier3 # deux lignes
: 6c31 0a6c 320a l1.l2.
Les résultat des commandes pour chacun de ces fichier est
disponible dans la copie d'écran suivante :
$ builtin mapfile lignes < "fichier0"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
$ builtin mapfile lignes < "fichier1"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
ok
$ builtin mapfile lignes < "fichier2"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
ok
$ builtin mapfile lignes < "fichier3"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
Bonne fin de builtin vendredi et bon builtin week-end,
--
builtin Étienne Mollier
Re: Screenlets gestion luminosité écran
David Pinson, le 2017-06-03 :
> Bonjour,
>
> Je me pencherai plutôt du côté du handicap visuel de la
> personne concernée...
Bonjour,
Avec les clients Mozilla Thunderbird et Firefox, combiner la
touche avec la roulette de la souris permet de régler la
taille des fontes rapidement. Ça marche pour les pages HTML et
plain texte et c'est très utile pour lire les petites lettres,
même quand on a oublié ses lunettes. Si ça peut rendre service…
> Sinon la réponse à son problème se retrouve dans ce lien
> ci-dessous:
> http://blog.radevic.com/2012/10/icon-gtk-close-not-present-in-theme.html
>
> installer le paquet gnome-icon-theme-full
> #apt-get install gnome-icon-theme-full
Le paquet `gnome-icon-theme-full` a l'air propre à Ubuntu 12.04.
Du moins, il n'apparaît pas dans Stretch.
L'environnement de bureau utilisé est Xfce. Donc peut-être qu'il
manque tout simplement `gnome-icon-theme`, Xfce n'en dépendant
pas. La commande suivante devrait corriger le problème :
# apt install gnome-icon-theme
Si ça coince toujours, avec un peu de chance, les extra
compléteront les éléments manquants :
# apt install gnome-icon-theme-extras
À plus
--
Étienne Mollier
Re: sftp en ligne de commande
On 06/25/2017 11:44 AM, Erwan David wrote: > Le 06/25/17 à 11:35, bernard.schoenac...@free.fr a écrit : >> bonjour, >> >> je recherche un moyen d'employer sftp en ligne de commande >> pour transférer des fichiers ... >> >> actuellement mc est inutilisable (segfault erreur -31) pour sftp >> >> en mode graphique j'emploie filezilla, mais quelles sont les solutions pour >> soit télécharger ou téléverser ? >> >> >> slt >> bernard >> > > sftp tout simplement. (doit être dans openssh-client) > Sinon lftp connaît le protocole aussi. > Bonjour Bernard, La commande `rsync` est aussi une solution valide. La syntaxe suivante utilisera le serveur SSH qui tourne sur l'hôte en utilisant le protocole SFTP pour naviguer dans le système de fichier (pas forcément très pratique, sans configuration adéquate, il faut retaper le mot de passe à chaque exécution): rsync hote: Pour télécharger: rsync -aSH hote:/source/fichier /cible/fichier rsync -aSH hote:/source/repertoire/ /cible/repertoire/ Pour téléverser: rsync -aSH /source/fichier hote:/cible/fichier rsync -aSH /source/repertoire/ hote:/cible/repertoire/ Ce n'est pas la première commande qui vient en tête, mais elle est assez pratique. En prime, si les copies sont récurrentes, sur la base de la date de dernière modification « mtime » de chaque fichier, seuls ceux ayant été modifiés sont transférés. À plus, -- Étienne Mollier
Re: Buster et smokeping
On 06/27/2017 11:13 AM, BERTRAND Joël wrote: > Buster ne contient plus /usr/bin/fping6 nécessaire pour > smokeping. Un petit hack permet de s'en sortir : > > Root rayleigh:[~] > cat /usr/local/bin/fping6 > #!/bin/bash > /usr/bin/fping -6 $@ > exit 0 > > en modifiant l'adresse de la sonde dans > /etc/smokeping/config.d/Probes. Bonjour Joël, Merci beaucoup pour le partage de ce petit hack, qui avec un peu de chance sauvera des vies, ou au moins évitera des maux de têtes. ;-) Juste deux ou trois remarques de la part de monsieur tatillon... Vous pouvez renforcer la robustesse de votre script, notamment en présence d'espaces dans un argument, en ajoutant des doubles apostrophes autour du `$@', qui s'étendra comme suit : "$@" ~ "$1" "$2" "$3" ... Pour comparaison, la différence avec "$*", qui représente aussi tous les arguments, s'étend comme suit : "$*" ~ "$1 $2 $3 ..." Vous pouvez également, d'une pierre deux coups, stopper l'exécution de `bash' en démarrant celle de `fping' en utilisant le mot clef `exec', ce qui permettra dans la foulée à `fping' remonter son code d'erreur en cas de pépins. Ce qui donnerait le script suivant : #!/bin/bash exec /usr/bin/fping -6 "$@" Si le problème se produit dans le paquet `smokeping' fourni dans Buster, il faudrait sans doute remonter le problème au mainteneur. À plus, -- Étienne Mollier
Re: Détecter fichiers qui n'ont pas une expression
Le 28 juin 2017 10:44, a écrit :
> On Tuesday 27 June 2017 20:14:49 Eric Degenetais wrote:
> > find chemin/racine -type f -name "*.txt" -exec grep -v {} \;
> > -print
>
> Merci.
>
> Ça fonctionne mais moins bien que les deux ci-dessous,
> car la commande affiche quand même quelques fichiers qui
> ont pourtant l'expression.
On 06/28/2017 06:55 PM, Eric Degenetais wrote:
> Étrange, ça devrait fonctionner aussi. Et aider si les fichiers
> sont dispersés. Pas le temps de tester en détail mais il faudra
> que j'y revienne O_o
>
Bonjour,
Si j'ai bien compris le principe, la logique semble pêcher dans
la négation de la correspondance. Avec la proposition ci-dessus,
l'assertion suivante est vraie alors qu'apparemment, on la
préférerait fausse :
Si le fichier contient au moins une ligne dans laquelle
l'expression n'est pas présente,
alors afficher le fichier.
La commande suivante pourrait-elle correspondre à vos attentes ?
find chemin/racine/ -type f -name '*.txt' -not -exec grep -q
'{}' \;
Le `-v` du `grep` est enlevé et est remplacé par l'option `-not`
de la commande `find` pour indiquer que la commande passée au
`-exec` doit terminer en erreur pour que le fichier corresponde à
la recherche. L'option `-q` est simplement là pour signaler à
`grep` de ne pas afficher les correspondances qu'il trouve, ça
donnera au passage une sortie d'écran un peu plus lisible.
À plus,
--
Étienne Mollier
Re: Détecter fichiers qui n'ont pas une expression
On 06/28/2017 08:09 PM, Étienne Mollier wrote:
> La commande suivante pourrait-elle correspondre à vos attentes ?
>
> find chemin/racine/ -type f -name '*.txt' -not -exec grep -q
> '{}' \;
>
Erratum, le `-print` à sauté à la fin de la commande. Il faut lire :
find chemin/racine/ -type f -name '*.txt' -not -exec grep -q
'{}' \; -print
--
Étienne Mollier
