GuiGui's Show

Sur l'un de mes serveurs informatiques Debian GNU/Linux stable, la commande who n'affiche rien. La commande w n'affiche pas plus les utilisateurs connectés. Ça fait plus d'un an et demi que ça dure. Dans le passé, j'ai eu ce comportement avec des conteneurs LXC et uniquement des conteneurs LXC. Mais ce système n'a jamais été dans un conteneur. Je me décide à étudier un peu le problème.

TL;DR : sudo chown root:root /.

Évidemment, rien dans les journaux systèmes usuels (avec le mot-clé « utmp »).

Le premier résultat dans un moteur de recherche web est la base de connaissances de Suse : 'who' output is blank, returns nothing. De même, le manuel d'utmp est clair : « None of these programs creates the file, so if it is removed, record-keeping is turned off ». Sur mon serveur, le fichier /var/run/utmp n'existe pas. En le créant, who (et w) affiche toutes les connexions SSH postérieures.

L'ennui, c'est que /var/run est un lien vers /run, et que /run est un tmpfs (c'est-à-dire un ramdisk, stocké en mémoire vive). Donc son contenu sera effacé au prochain redémarrage (ou extinction). C'est la config par défaut de Debian.

L'hypothèse la plus probable est qu'un logiciel ne crée pas le fichier /var/run/utmp au démarrage de la machine ou le crée trop tôt, quand le tmpfs n'est pas encore monté.

L'absence de création peut être liée à une absence de configuration. Mais, une comparaison de la sortie de grep -Ri utmp /etc entre plusieurs machines montre une config identique.

Quel logiciel s'occupe de créer /var/run/utmp ? Je soupçonne systemd. Je regarde la liste des units avec systemctl list-units. Tiens, systemd-update-utmp.service. Je redémarre ce service : le fichier est toujours absent.

Une recherche sur le web désigne systemd-tmpfiles. systemctl status systemd-tmpfiles-setup.service affiche « (code=exited, status=73) » et « Detected unsafe path transition / (owned by guigui) → /run (owned by root) during canonicalization of XXXX ». Même chose pour /var. Sur mes autres machines (serveurs ou non), le code retour est 0, et il n'y a aucune erreur.

Tout s'éclaircit : il y a encore un an et demi, ce système était une machine virtuelle chez un autre hébergeur. J'ai exposé la migration ici. Le support de stockage de destination était un disque dur externe raccordé en USB utilisant le système de fichiers ext4. Pour l'utiliser sans les droits root, j'avais donc changé le propriétaire du point de montage, et donc celui de la racine du système de fichiers (en clair : sudo chown guigui /mnt/disqueDurExterne). Et, en effet, ls -la sur le serveur (qui utilise ledit disque dur) expose que / appartient à guigui au lieu de root.

Je rétablis les droits corrects : sudo chown root:root /.

Je redémarre mon serveur. systemd-tmpfiles-setup.service termine son boulot sans erreur (code retour = 0), et who (et w) affiche les utilisateurs connectés. \o/

Je veux contacter le délégué à la protection des données à caractère personnel (DPO en anglais) d'un éditeur de presse. Dans les mentions légales, je lis « Vous pouvez faire valoir vos droits en contactant : [email protected] […] ». Le lien sur « email protected » conduit à une page web sur le même domaine qui expose « The website from which you got to this page is protected by Cloudflare. Email addresses on that page have been hidden in order to keep them from being accessed by malicious bots. You must enable Javascript in your browser in order to decode the e-mail address. » et qui pointe vers Cloudflare Email Address Obfuscation.

Même avec un profil Firefox vierge (ni extension, ni paramètres persos), l'adresse emails reste dissimulée.

Vu ce qui est dit supra, il s'agit d'une dissimulation (offuscation) locale au navigateur web.

Rapidement, on trouve un bout de code à saisir dans la console des outils de développement web de Firefox pour désopacifier cette adresse email.

Je le recopie ici afin de l'archiver :

// Adapted from https://raddle.me/f/Privacy/3722/how-to-circumvent-cloudflare-s-email-protected-thing-without with the help of chatGPT
function fixObfuscatedEmails() {
  const elements = document.getElementsByClassName('__cf_email__');
  for (let i = 0; i < elements.length; i++) {
    const element = elements[i];
    const obfuscatedEmail = element.getAttribute('data-cfemail');
    if (obfuscatedEmail) {
      const decodedEmail = decrypt(obfuscatedEmail);
      element.setAttribute('href', 'mailto:' + decodedEmail);
      element.innerHTML = decodedEmail;
    }
  }
}

function decrypt(obfuscatedEmail) {
  let output = '';
  const xorKey = parseInt(obfuscatedEmail.substr(0, 2), 16);
  for (let i = 2; i < obfuscatedEmail.length; i += 2) {
    const charCode = parseInt(obfuscatedEmail.substr(i, 2), 16) ^ xorKey;
    output += String.fromCharCode(charCode);
  }
  try {
    output = decodeURIComponent(escape(output));
  } catch (error) {
    console.error(error);
  }
  return output;
}

// Call the function to fix the obfuscated email addresses
fixObfuscatedEmails();

Le temps qu'on perd avec ce genre de merdes… Soupir.

D'après la Dares (une direction du ministère du taff), en 2022, 7 % des sondés ayant retrouvés un emploi déclaraient que France Travail a été le facteur décisif de leur retour à l'emploi.

En 2017, l'INSEE publiait que 9 % des sondés déclaraient avoir retrouvé un emploi grâce à France Travail ou un autre organisme public. Proportion stable depuis 20 ans et proche de celle observée chez nos voisins.

Évidemment, c'est un peu bidon car il s'agit d'un sondage déclaratif, et qu'un retour à l'emploi peut avoir plusieurs facteurs (ex. : offre d'emploi trouvée sans France Travail, mais entretien d'embauche réussi grâce à une formation France Travail), mais quand même, c'est parlant.

Sachant qu'en 2023, 60 % du budget de France Travail provenait des cotisations chômage (à hauteur de 11 % des recettes). Stable dans le temps. Financer, par son travail, sa future oppression hors emploi, c'est beau.

J'ai déjà listé ce que l'on peut reprocher à France Travail.

Via https://www.france.tv/france-5/vu/.