GuiGui's Show

Pour éviter un laborieux ps aux | grep firefox | grep -v grep, il y a ps aux | grep [f]irefox. Merci, Duke. :)
Explication : on demande de chercher une ligne qui contient « f » puis la chaîne « irefox ». La ligne du processus « grep --color=auto [f]irefox » ne correspond pas, car c'est une chaîne qui contient « [ » + « f » + « ] » + « i » +. Il n'y a pas de chaîne qui commence par f et qui finit par « irefox » sur cette ligne, en gros.

On peut aller plus loin. 99 % du temps, quand je filtre la sortie de ps, c'est pour confirmer la présence d'un processus.
Si je veux acquérir une vision globale des processus, je préfère une vue dynamique à la htop / top.

Dans ce cas, ps -fC firefox-esr fait le boulot, si l'on connaît le nom du processus et si c'est exploitable. Genre chercher un programme Java est souvent vain puisque le nom de l'exécutable sera « java », le nom visuel du programme arrive dans les arguments, qui ne sont pas considérés par ps -fC.

On peut aller légèrement plus loin (autant de caractères mais plus simple, je trouve) : pgrep firefox, le copain de pkill. Merci Johndescs. :)

pgrep -x et ps -C sont très utiles dans des scripts : concis (plus que "ps | grep | grep -v grep") et la recherche se fait uniquement sur le nom des programmes, pas sur leurs arguments.
Ça évite qu'un script lancé par CRON ne fasse plus rien car ps aux | grep apt | grep -v grep trouve toujours un processus (alors qu'apt n'est pas en cours d'exécution) car il capture thermald --adaptative (« apt » dans « adaptative »). Oui, c'est du vécu.

Causer dans une socket UNIX avec netcat (déclinaison netcat-openbsd) :

nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

Exemple : l'interface de management d'OpenVPN (qui permet d'afficher des stats d'utilisation, de tuer une session fantôme, de diagnostiquer un problème, etc.) est une socket UNIX.

Nous voulions tester notre code Puppet sur Debian 11 qui était alors dans l'état release candidate (RC).

Dans notre code (et dans Hiera), nous utilisons le fact os/release/major pour agir en fonction de la version d'un système Debian GNU/Linux.
Pour agir sur plusieurs versions en même temps, nous convertissons le fact, qui est une chaîne de caractères, en nombre (if (0 + $facts['os']['release']['major']) >= 9 { […] }).

Or, quand une version de Debian est en RC, os/release/major ne contient pas un nombre mais un texte (« testing » ou « bullseye », je ne sais plus). Forcément, notre code échoue…

Facter permet d'utiliser des variables d'environnement pour créer un fact : FACTER_bonjour='Hello, World!' facter -p.

On peut également surcharger un fact avec une variable d'environnement : FACTER_kernel='GuiGuiOS' facter -p.

Le contenu surchargé est transmis à Puppet. Soit le code suivant :

Notify { $facts['kernel']:
}

puppet agent -t affichera : « Notice: Linux ». FACTER_kernel='GuiGuiOS' puppet agent -t affichera « GuiGuiOS ».

Mais cela ne fonctionne pas avec les facts structurés (tableaux, JSON, YAML). Reprenons notre fil rouge : surcharger os/release/major :

FACTER_os='{
  architecture => "amd64",
  distro => {
    codename => "buster",
    description => "Debian GNU/Linux 11 (bullseye)",
    id => "Debian",
    release => {
      full => "11",
      major => "11"
    }
  },
  family => "Debian",
  hardware => "x86_64",
  name => "Debian",
  release => {
    full => "11.0",
    major => "11",
    minor => "11"
  },
  selinux => {
    enabled => false
  }
}' facter -p | grep major

Cela fonctionne. J'expliquerai à la fin pourquoi j'ai surchargé tout « os » alors qu'il est possible de surcharger uniquement os/release/major.

En revanche, Puppet n'en veut pas :

FACTER_os='{
  architecture => "amd64",
  distro => {
    codename => "buster",
    description => "Debian GNU/Linux 11 (bullseye)",
    id => "Debian",
    release => {
      full => "11",
      major => "11"
    }
  },
  family => "Debian",
  hardware => "x86_64",
  name => "Debian",
  release => {
    full => "11.0",
    major => "11",
    minor => "11"
  },
  selinux => {
    enabled => false
  }
}' puppet agent -t

Résultat : « Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: A substring operation does not accept a String as a character index. ».

On peut essayer de formater pour tout mettre sur une ligne ou de fournir un format JSON, ça ne fonctionne pas mieux. C'est connu.

On peut diffuser un fact personnalisé / externe via un module Puppet. Je n'ai pas envie car je veux juste faire un test sur une seule machine.

Un fact peut également être stocké en local sur une machine. L'emplacement des facts externes est mentionné dans la doc'.
Le dossier « /etc/facter/facts.d/ » n'existe pas, mais on peut le créer.

/etc/facter/facts.d/os.yaml :

os:
  architecture: "amd64"
  distro:
    codename: "bullseye"
    description: "Debian GNU/Linux 11 bullseye"
    id: "Debian"
    release:
      full: "11"
      major: "11"
  family: "Debian"
  hardware: "x86_64"
  name: "Debian"
  release:
    full: "11.0"
    major: "11"
    minor: "11"
  selinux:
    enabled: false

Cela fonctionne. \o/

Pour les masos, on peut aussi l'faire en JSON. /etc/facter/facts.d/os.json :

{
  "os": {
    "architecture": "amd64",
    "distro": {
      "codename": "bullseye",
      "description": "Debian GNU/Linux 11 bullseye",
      "id": "Debian",
      "release": {
        "full": "11",
        "major": "11"
      }
    },
    "family": "Debian",
    "hardware": "x86_64",
    "name": "Debian",
    "release": {
      "full": "11.0",
      "major": "11",
      "minor": "11"
    },
    "selinux": {
      "enabled": false
    }
  }
}

Il est possible de surcharger uniquement la variable désirée (os/release/major dans mon cas), mais je le déconseille : facter ne fusionnera pas ta variable avec le reste du fact structuré (dans mon cas, si je surcharge os/release/major, os/architecture ou os/distro ou os/release/full ou… n'existeront plus). Or, ton code ou un module peut vouloir récupérer un fact ignoré. Dans ce cas, l'exécution de puppet se terminera avec une erreur genre « Error 500 on SERVER: Server Error: Evaluation Error: Operator '[]' is not applicable to an Undef Value. ».

J'avais pas tilté, mais la commande pour afficher les facts personnalisés (custom facts / external facts, déposés par un module Puppet) sur un client Puppet change en fonction de la version de facter et des envies des mainteneurs Debian du paquet facter :

• >= Debian 10 : facter -p ou puppet facts ;
  
  
• Debian 9 : facter -p --external-dir=/var/cache/puppet/facts.d/ ;
  
  
• Debian 8 : facter -p --external-dir=/var/lib/puppet/facts.d/.

Pour les facts natifs, la commande est invariable : facter -p.

Besoin de surligner ou d'annoter un PDF ? xournal. 0 prise de tête. Présent dans les dépôts officiels Debian.

ÉDIT DU 29/06/2023 : le surlignage se fait à main levée, donc imprécis. okular permet de surligner droit, mais uniquement du texte (xournal permet de travailler également sur un scan). Bref, toujours aucun outil libre parfait. FIN DE L'ÉDIT.

ÉDIT DU 15/04/2024 : okular permet de surligner sur des images (scan) en dessinant des rectangles (outil caché dans le menu « flèches » de la barre d'outils), en choisissant la même couleur de bordure et de remplissage des annotations (boutons de la barre d'outils), puis en choisissant l'opacité des annotations (icône « goutte » à côté des icônes pour choisir les couleur, toujours dans la barre d'outils). Plusieurs couleurs disponibles. C'est super pratique. Dans les deux cas (surligneur ou traçage de rectangles ou…), il s'agit d'une annotation, à laquelle on peut ajouter du texte. On peut supprimer une annotation en cliquant dessus dans le mode « Parcourir » (bouton dans la barre d'outils) ou via la visionneuse d'annotations (à gauche, à la place de la visionneuse de vignettes).

okular permet également d'insérer une signature manuscrite au format image. Tutoriel ici. FIN DE LÉDIT DU 15/04/2024.

La direction interministérielle du numérique (DINUM) a adressé une note aux sinistères les informant qu'Office 365 n'est pas conforme à la nouvelle doctrine de l'État en matière de clown (cloud). Pour moi, il ne s'agit pas d'audace, mais de la suite logique aux décisions Schrems et Schrems 2 de la Cour de Justice de l'Union Européenne.

Évidemment, l'utilisation d'Office 365 et l'externalisation restent autorisées : version d'Office 365 déconnectée du clown de Microsoft, installation On-Premises (Office hébergé sur une infrastructure (co-)détenue par l'administration), les offres commerciales labelisées SecNumcloud par l'ANSSI (à ce jour : Oodrive, Outscale et OVH) et immunisées contre les législations impérialistes hors UE type Cloud Act ou Patriot Act (par quelle magie ?! quels moyens met-on en œuvre pour s'en assurer techniquement ?), le "clown" de l'État (SNAP), le clown Bleu (Orange, Capgemini, Microsoft, etc., ça va encore donner naissance à un mammouth ingérable et inutilisable en pratique), etc. ÉDIT DU 27/06/2022 : cloud Thales-Google. FIN DE L'ÉDIT.

Évidemment, il y aura des dérogations, et le pouvoir de prescription de la DINUM reste très limité : la note, comme celle où elle invitait les sinistrères à définir Qwant comme moteur de recherche par défaut, s'adresse exclusivement aux sinistères, et, d'une manière générale, les DSI des administrations sous tutelle ministérielle peinent à savoir s'ils sont concernés. Quelles sanctions ? Etc.

Évidemment, la note manque d'ambition. Pas de financement d'un écosystème concurrent complet (conception, maintenance, maîtrise, formation, etc.). On attend que le privé se bouge en balaçant des tonnes de yakafokon (oui, y'a l'offre interministérielle SNAP, lol) ce qui est l'un des symptômes d'une absence de politique en matière de numérique. Manque de volonté (combien de dirigeants d'administration locales et centrales, jusqu'au plus haut niveau de l'État, utilisent Zoom, WhatsApp, etc. ?!). Pour moi, la nouvelle doctrine du clown est uniquement là pour rafistoler à l'arrache le radeau suite aux décisions de la CJUE.

La note de la DINUM peut également être consultée ici.

Voir aussi : https://www.nextinpact.com/lebrief/48166/la-dinum-autorise-suite-office-mais-proscrit-sa-version-365-hebergee-dans-cloud-microsoft.

Via https://twitter.com/emile_marzolf/status/1440673920332402705 via https://twitter.com/bayartb/status/144079246619445658.

Comment insérer une page au format paysage dans un document (dont les autres pages sont au format portrait) ?

Sur l'interface web d'Aruba Mobility Master v8.6, je tente d'uploader un nouveau certificat x509 : « Error : Expecting string of length 1 to 31 ». Il faut que la longueur du nom du fichier contenant le certificat n’excède pas 31 caractères… … …

J'étais au-dessus car, dans le nom du fichier, nous mettons le common name ainsi que le numéro de commande auprès de notre autorité de certification afin de superviser et de retrouver facilement un certificat. Dingue qu'Aruba ne prenne pas en charge un cas aussi banal.

Sur notre parc Ubuntu 20.04, chromium ne fonctionne pas. Chromium est installé avec snap. L'ensemble pose deux problèmes :

• Le profil AppArmor livré ne prend pas en charge les homedirs situés ailleurs que dans /home/ et/ou montés en NFS (non, il ne suffit pas de configurer les variables dans /etc/apparmor.d/tunables/home.d, lire ci-dessous pour les détails) ;
  
  
• Indépendamment d'AppArmor (le désactiver ne résout pas le problème), snap ne semble pas gérer des homedirs (dossier personnel) montés en NFS. Voir : https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552 et https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1884299.

On notera également que le dossier Téléchargements se trouve dans ~/snap/chromium/current/Téléchargements. Super pratique pour un utilisateur !

Au final, on a installé Google Chrome (qui n'est pas diffusé via snap) et basta. :( On a autre chose à faire que de compiler chromium régulièrement depuis les sources et on n'a pas trouvé de dépôt apt à jour et de confiance (ce qui permettrait de nous passer de snap).

Démarche (tests effectués) et découverte d'AppArmor :

• Chemin vers homedir = /home/$uid + absence de NFS : chromium démarre ;

• Chemin vers homedir = /home/$uid + NFS : chromium ne démarre pas, erreur « cannot open path of the current working directory: Permission denied » ;

  • cd /tmp/ && chromium-browser : chromium démarre (+ snap écrit dans $HOME/snap ! Je croyais que t'arrivais pas à y accéder ?!) ;
• Chemin vers homedir = /home/$nas/$categorie/$uid + NFS : même comportement et même erreur ;
  • cd /tmp && chromium-browser : chromium ne démarre pas, erreur « cannot create user data directory: /home/$nas/$categorie/$uid/snap/chromium/1753: Permission denied ». En fonction de la configuration d'AppArmor (voir ci-dessous), l'erreur peut aussi être « cannot create user data directory: /home/$nas/$categorie/$uid/snap/chromium/1753: Stale file handle ».

Le dernier point est lié au profil AppArmor /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883.

• Si je désactive totalement AppArmor (ajouter apparmor=0 dans GRUB_CMDLINE_LINUX_DEFAULT dans /etc/default/grub puis lancer update-grub2 puis redémarrer), je n'ai plus de problème pour lancer chromium depuis /tmp (ou autre endroit sans NFS). Sur le web, on lit que la commande systemctl disable apparmor et un redémarrage permettent de désactiver AppArmor : ce n'est pas exact ;
  
  
• Si je passe le profil en mode complain (geindre dans les journaux sans rien bloquer), chromium démarre toujours quand pwd = /tmp. Comme le profil n'est pas dans /etc/apparmor.d, la commande aa-complain /snap/snapd/12883/usr/lib/snapd/snap-confine sort en erreur « Profile for /snap/snapd/12883/usr/lib/snapd/snap-confine not found, skipping » (idem avec « /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 »). Pour passer outre : ln -s /var/lib/snapd/apparmor/snap-confine.snapd.12883 /etc/apparmor.d/ && aa-complain /snap/snapd/12883/usr/lib/snapd/snap-confine. Quid de la pérennité ? « 12883 » dans le nom du profil est la révision de snapd… qui changera lors des mises à jours… ;
  
  
• Si je passe le profil en mode complain, je m'aperçois qu'AppArmor empêche snap d'accéder à /home/ et /home/$nas en lecture ainsi que d'envoyer des messages réseau pour accéder à notre NAS en NFS. Pour débrayer le premier problème, il faut ajouter les lignes /home/ r, et /home/$nas/ r, dans le profil. Pour NFS, il faut ajouter une ligne network, dans le profil. Puis je recharge le profil avec apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 (on lit souvent que systemctl reload apparmor fait le job, mais c'est incorrect). Quid de la pérennité ? « 12883 » dans le nom du profil est la révision de snapd, donc le nom du profil (et/ou son contenu) changera lors des mises à jours… ;
  
  
• Il est vain de désactiver le profil (ln -s /var/lib/snapd/apparmor/profiles/snap-confine.snapd.12883 /etc/apparmor.d/disable/ + reboot), le lancement de chromium génerera l'erreur « snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks » ;
  
  
• Il n'est pas possible de désinstaller AppArmor car snapd dépend de lui et chromium dépend de snapd…

Dans un annuaire LDAP genre OpenLDAP, l'attribut « userPassword » est multi-valué (plusieurs valeurs), cf le RFC 2829.

Il est donc possible d'avoir plusieurs mots de passe pour un même utilisateur.

Une application qui fait de l'authentification LDAP effectue une seule requête BIND et le serveur LDAP itère sur l'ensemble des attributs userPassword pour tester le mot de passe, donc le comportement ne dépend pas de l'application. (Évidemment, y'a toujours des applications qui tentent d'authentifier un utilisateur sur un annuaire LDAP sans faire de BIND, genre en récupérant l'attribut userPassword, dont le comportement face à plusieurs mots de passe est imprévisible).

Quand on veut diagnostiquer une authentification ou une autorisation (droits dans un logiciel / site web) sans connaître le mot de passe de l'utilisateur qui se plaint d'un problème, sans lui réinitialiser son mot de passe et sans mettre en place tout un processus pour qu'il se rende disponible pour reproduire le problème devant toi, il suffit donc d'ajouter une valeur supplémentaire l'attribut « userPassword ». L'utilisateur continuera d'utiliser son mot de passe et toi, tu utiliseras celui que t'as ajouté. Quand t'as terminé, tu retires ton mot de passe additionnel.

C'est, pour moi, l'équivalent adminsys des frameworks web genre Symfony qui permettent de se faire passer pour un utilisateur et d'obtenir ainsi les mêmes droits.