Cyril Brulebois a écrit 657 commentaires

Sans réglage particulier, voici les dimensions de mon terminal :

kibi@armor:~$ echo $COLUMNS
115
kibi@armor:~$ echo $LINES
25

Listons les paquets :

kibi@armor:~$ dpkg -l
…
ii  zonecheck              3.0.5-3          all              DNS configuration checker
ii  zsh                    5.3.1-4+b3       amd64            shell with lots of features
ii  zsh-common             5.3.1-4          all              architecture independent files for Zsh

La même chose avec une largeur plus faible :

kibi@armor:~$ COLUMNS=80 dpkg -l
…
ii  zonecheck      3.0.5-3      all          DNS configuration checker
ii  zsh            5.3.1-4+b3   amd64        shell with lots of features
ii  zsh-common     5.3.1-4      all          architecture independent files fo

ou plus importante :

kibi@armor:~$ COLUMNS=200 dpkg -l
…
ii  zonecheck                                    3.0.5-3                     all                         DNS configuration checker
ii  zsh                                          5.3.1-4+b3                  amd64                       shell with lots of features
ii  zsh-common                                   5.3.1-4                     all                         architecture independent files for Zsh

Debian Consultant @ DEBAMAX

Ton pointeur de fichier fait déjà ça, non ?

with open('miaou.csv') as fp:
    for line in fp:
        print(line)

Debian Consultant @ DEBAMAX

Ça tombe bien, c'est exactement ce qui est fait pour sr0 via :

KERNEL=="sr0", SYMLINK+="cdrom", OPTIONS+="link_priority=-100"

dans /lib/udev/rules.d/60-cdrom_id.rules.

Il devrait te suffire de localiser le bon fichier avec une règle similaire, et de le mettre à jour pour obtenir l'effet désiré. Pour être sûr que la nouvelle règle soit bien prise en compte, le plus simple est probablement de redémarrer.

Attention, modifier à la main un fichier sous contrôle d'un gestionnaire de paquets risque d'être oublié lors de la prochaine mise à jour du paquet concerné, donc la modification in situ n'est probablement appropriée que pour un test ponctuel.

Il peut être nécessaire de mettre en place un fichier spécifique (e.g. dans /etc/udev/rules.d/, sous contrôle de l'admin), pour pérenniser la solution. Dans l'exemple donné ci-dessus, le lien symbolique en place est peu prioritaire. D'après udev(7) :

       OPTIONS
           Rule and device options:

           link_priority=value
               Specify the priority of the created symlinks. Devices with
               higher priorities overwrite existing symlinks of other
               devices. The default is 0.

donc il me semble que mettre en place une règle pour sr1 comme suit devrait fonctionner sur le long terme, par exemple dans /etc/udev/rules.d/60-custom-cdrom_id.rules :

KERNEL=="sr1", SYMLINK+="cdrom"

(Ne pas hésiter à mettre un commentaire et/ou une option link_priority explicite pour te souvenir de comment tu en es arrivé là…)

Debian Consultant @ DEBAMAX

Je te suggère de vérifier la configuration réseau effective sur chacune, par exemple avec :

ip l
ip a
ip r
cat /etc/resolv.conf

Cela permettra de détecter des incohérences éventuelles.

Pour les histoires de résolution qui fonctionne ou non, tu peux utiliser dig et poser la question à l'un et/ou l'autre des deux serveurs configurés.

Debian Consultant @ DEBAMAX

Ça veut dire que tu donnes le droit à absolument toute commande dans ce répertoire de faire ce qu'elle veut en tant que root.

C'est un tout petit peu à contre-emploi vis-à-vis de la sandbox dont le but est de filtrer ce qu'il est possible de faire ou non…

Debian Consultant @ DEBAMAX

status=progress

Debian Consultant @ DEBAMAX

C'est pire que ça.

Dès le branchement des redirections, le fichier de log est tronqué et ouvert en écriture, et tout son contenu est perdu.

Deux possibilités pour éviter cela :

• commencer par dupliquer le fichier, et travailler sur une copie, en générant le fichier allégé directement.
• travailler sur le fichier original, générer un nouveau fichier allégé sous un autre nom, puis remplacer le fichier original.

Dans les deux cas, cela ne résout pas le souci que tu mentionnais (les éventuelles lignes de log perdues en cours de route). Mais cela évite de tout perdre.

Debian Consultant @ DEBAMAX

C'est typiquement le cas d'utilisation où éditer la ligne de commande pour enlever quiet et splash peut s'avérer utile. ;-)

Debian Consultant @ DEBAMAX

En complément, ne pas hésiter à supprimer les mots quiet splash de la ligne du commande du noyau pour maximiser les chances d'avoir des messages à l'écran indiquant ce qui fonctionne… et ce qui pose problème.

Note : l'édition n'est valable que pour le prochain démarrage. Elle est oubliée au redémarrage de la machine, donc pas de risque de corrompre la configuration du chargeur de démarrage en cas de fausse manipulation.

Debian Consultant @ DEBAMAX

Je confirme, pavucontrol est souvent un très bon point de départ pour comprendre ce qui est configuré et comment. Cela peut être un problème de profil, cf. l'onglet Configuration. Peut-être un choix de Digital … par défaut, au lieu d'Analog Stereo Duplex, par exemple ?

Debian Consultant @ DEBAMAX

Pour mes comptes pro et perso, j'utilise Skrooge qui a un connecteur weboob, ce qui me permet d'importer les opérations des différentes banques dans différents fichiers. Là, effectivement, j'ai un peu de glu pour dire tel fichier = telle(s) banque(s). Dans Skrooge, je catégorise+pointe les opérations.

Côté pro uniquement, pour être sûr de faire le rapprochement entre les différentes opérations, factures, etc. je n'utilise pas de GED mais j'ai des tableurs LibreOffice. J'imagine qu'il pourrait y avoir plus d'automatisation entre Skrooge et LibreOffice, mais vu le peu d'opérations dans une année, c'est l'expert-comptable qui fait les vérifications ultimes et me rattrape par l'oreille s'il manque une facture ou un justificatif. ;)

Debian Consultant @ DEBAMAX

Effectivement, les applicatifs qui se relancent tout seuls peuvent être un peu pénibles pour les manipulations de leur environnement.

Il est toutefois possible de faire la correspondance français→anglais en téléchargeant le paquet source et en localisant (no pun intended) la chaîne dans le fichier de traduction. L'outil habituel est gettext et c'est probablement po/fr.po qui va t'intéresser. Seulement, il y a des chances que ça vienne d'une des bibliothèques utilisées, donc ça peut ne pas donner de résultats directs… Et je ne trouve rien que ressemble via https://sources.debian.org/ — Manjaro propose peut-être un service similaire qui peut t'aider à trouver d'où ça vient.

Pour ce qui est de la compréhension du problème, si tu avais un fonctionnement normal précédemment, c'est plutôt une bonne nouvelle : il doit être possible de comprendre d'où vient la régression. Dans ce genre de cas, ma priorité va aux logs de l'outil de mise à jour : est-ce que des paquets ont été mis à jour récemment, si oui est-ce que le timing correspond à l'apparition des symptômes, etc. En complément ou à la place d'une telle mise à jour, il peut y avoir eu un changement de configuration (/etc ou dans les préférences utilisateur). Enfin, dans ce cas particulier, il faut penser à vérifier ce genre de choses à la fois côté client et côté serveur. Bonne chance !

Debian Consultant @ DEBAMAX

Les fichiers du dépôt en question semblent dater de 2006/2007, j'imagine que tu as envie de trouver un autre emplacement d'où télécharger des paquets ? :)

Debian Consultant @ DEBAMAX

Oh, j'ai oublié de mentionner l'existence de webkit2gtk, peut-être que son -dev est ce que tu cherches ?

Debian Consultant @ DEBAMAX

Tu peux utiliser https://tracker.debian.org/pkg/libwebkit-dev (ou l'autre), qui va automatiquement te rediriger du paquet binaire vers le paquet source correspondant → https://tracker.debian.org/pkg/webkitgtk

Dans la section « news » :

[2018-12-01] Removed 2.4.11-4 from unstable (Debian FTP Masters)
[2018-09-27] webkitgtk REMOVED from testing (Debian testing watch)

Nous voyons donc que le paquet n'était plus dans un état convenable pour rester dans testing d'une part, et que nous avons même été jusqu'à sa suppression d'unstable. En cliquant sur le premier lien (https://tracker.debian.org/news/1008054/removed-2411-4-from-unstable/), nous avons les détails de la suppression (https://bugs.debian.org/893863) avec notamment en résumé :

RoM; RoQA; unmaintained, over 100 CVEs that won't be fixed

Plus d'infos sur les acronymes → https://wiki.debian.org/ftpmaster_Removals

Debian Consultant @ DEBAMAX

Cf. https://fr.wiktionary.org/wiki/privado

Debian Consultant @ DEBAMAX

Avec parted et quelques contorsions en plus des droits superutilisateur :

kibi@armor:~$ sudo /sbin/parted -l /dev/sda 2>/dev/null | grep Model | head -1
Model: ATA SanDisk SD7SN6S- (scsi)

Avec lsblk, un peu plus direct…

kibi@armor:~$ lsblk -d -o +'MODEL' /dev/sda
NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT MODEL
sda    8:0    0  477G  0 disk            SanDisk SD7SN6S-

kibi@armor:~$ lsblk -n -d -o 'MODEL' /dev/sda
SanDisk SD7SN6S-

Debian Consultant @ DEBAMAX

Note : Utiliser les ACL suppose d'installer le paquet acl2 et d'activer l'option sur le FS concerné.

Debian Consultant @ DEBAMAX

Je valide également pour borgbackup. Ça n'est pas forcément évident de mettre les mains dedans avec les différents choix pour --encryption mais une fois qu'on a compris les options et fait un choix, c'est un superbe outil !

Debian Consultant @ DEBAMAX

Je n'ai pas de PARTLABEL sous la main pour tester mais ça fonctionne avec LABEL= et PARTUUID= à tout le moins :

kibi@armor:~$ /sbin/blkid -t PARTUUID="63e124c2-01" -o device
/dev/sda1

Il y a plein d'options sympathiques dans blkid et lsblk, je te laisse faire ton marché. :)

Debian Consultant @ DEBAMAX

C'est activé :

$ grep SECCOMP /boot/config-4.19.0-10-amd64 
CONFIG_SECCOMP=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y

Debian Consultant @ DEBAMAX

Pour compléter un tout petit peu, une socket UNIX est accessible en connaissant son chemin dans l'arborescence locale.

Tandis qu'une socket AF_INET/AF_INET6 (disons « internet ») sera en général exposée via un port TCP ou UDP, qui peut être limité à une écoute locale (type 127.0.0.1) ou distante (avec une IP donnée, ou en écoutant sur toute IP). Ces dernières peuvent ensuite être firewallées à coup d'iptables/nftables ou autre surcouche.

Debian Consultant @ DEBAMAX

La séparation que j'envisage, c'est justement pour ne pas avoir besoin de me poser la question de si j'ai confiance ou non.

Debian Consultant @ DEBAMAX

Je me permets de rebondir sur l'aspect technique plutôt que juridique.

Je vais me retrouver dans une situation similaire très prochainement, avec un poste mis à disposition par un client. Étant pour la toute première fois confronté à ce genre de situation (éventuel contrôle à distance par le client, pour déployer des composants/mises à jour… et donc accès root j'imagine, autant dire que je n'ai aucun contrôle), je me demandais comment limiter les effets de bord en local.

Mes pistes actuelles :

• Branchement sur un switch configuré avec des VLAN pour m'assurer que le poste ne voit que la Freebox pour sortir sur internet (la question de la sécurité se poserait toujours côté Freebox, mais ça limite la connexion aux autres équipements). Inconvénient : Il va falloir que je m'équipe et que j'apprenne rapidement comment on configure ce genre de choses.
• Utilisation du réseau invité de la Freebox. Inconvénient : Jamais utilisé jusque-là, je ne sais pas trop quel cloisonnement cela offre.

Debian Consultant @ DEBAMAX

Oui. Ce que tu proposes appelle le contenu de $1 en tant que commande en positionnant temporairement var1 à eval…

Debian Consultant @ DEBAMAX