ache a écrit 15 commentaires

Bonjour,

J'utilise pass avec une Yubikey. Je n'ai pas d'intégration avec Firefox.
passmenu me sert à insérer les mots de passes, via un raccourci clavier.

Je n'utilise pas beaucoup Android, j'ai un téléphone depuis 1ans et je m'en sers peu.
Néanmoins, l'intégration de pass est très simple grâce à OpenKeychain et Password Store. Toujours sans intégration à Firefox par-contre.
À noter que du coup, je n'ai pas passmenu, pour rentrer un mot de passe, je copie le mot de passe depuis Password Store.

Pour configurer pass sur Android.
Grosso modo, je rentre ma clé et lance la recherche depuis OpenKeychain. Ma clé publique est importée car j'ai mis l'URL où la télécharger.
d
1. Dans Password Store, je génère une clé SSH, la protection par mot de passe est disponible, le partage de la clé est proposé et « envoie par e-mail » dans la liste.
2. J'importe la clé sur un VPS.
3. Je reviens à l'accueil, gros bouton « Let's go », ça me demande l'adresse du dépôt git et me propose le clone via SSH (forcément).

Puis, pour déchiffrer un mot de passe. Je clique sur l'un d'eux (deux clics généralement car dans pass on stocke souvent via dossier linuxfr.org/ache par exemple). Openkeychains me demande l'authorisation d'être exécuter, je valide, ça me demande mon PIN Yubikey, puis la validation tactile de la Yubikey (ou juste l'insertion ou via NFC, ça dépends comment tu souhaites là configurer).
Mon mot de passe s'affiche avec un bouton « Copier ».

Non vraiment, c'est pratique. Mais je ne me sers pas assez de mon portable pour avoir une vraie utilité à cette installation.

---

Pour mes amis et ma famille, je conseil systématiquement l'usage du gestionnaire de mot de passe intégré via un mot de passe principal.
Les plus exigeant sont comblés par la synchronisation via Firefox Sync. Les plus Geek pourront l'auto-héberger.
L'algorithme derrière est AES 256, ce qui n'est pas le plus moderne, mais qui a été éprouvé et toujours considéré sûr.

Bizarre …

J'ai même cette URL parfois:

linuxfr.org/?banner_size=320x240%27A%3D0&close_cross_action_click=11&content_niche=infidele&corner_position=right-bottom-top&design=01&e=1%27+and+%27x%27%3D%27x&email=&id=10000&page=8&sound=0&synergie=494&tracker=_oopt4e_1_197&typecontenu=sexy&w=0

O_o: typecontenu=sexy, content_niche=infidele.

Cool !
Merci pour la doc, c'est vraiment plus claire comme ça.

Enfin, j'ai des trucs à apprendre quoi.

Petite précision tout de même, si l'appel système mount(2) n'accepte pas les fichiers réguliers, la commande mount(8) les accepte, grâce à l'option -o loop, avec laquelle elle alloue automatiquement un périphérique boucle.

Oui j'avais remarqué ça, même sans l'option -o loop d'ailleurs. Là, j'essaye de comprendre ce que la commande mount(2) fait avec "loop/autoclear" car umount (l'appel système et la commande) ne semble pas avoir besoin de dés-associer le fichier loopback et le fichier régulier, la-dés association semble automatique.

La raison pour laquelle mount(2) a besoin d'un périphérique bloc, c'est qu'à mon avis le noyau doit vouloir accéder aux données du système de fichiers directement à des adresses mémoire. Un fichier régulier n'a rien de tel, à moins de le mapper en mémoire, et c'est justement ce que fait un périphérique boucle.

Humm, intéressant. Donc dans un fichier de type bloc, on a une abstraction (tête de lecture du lecteur ou micrologiciel du SSD) pour lire à une adresse précise alors que dans un fichier normal n'a pas ça.

Que doit faire un fichier régulier pour lire à une adresse précise ? Dans mon programme, j'utilise fseek(3) (je ne connais pas le syscall associé) pour positionner le curseur au bon endroit sans avoir besoin de tout lire. Je pense que ce qui se passe lorsque je fais un fseek dépend du système de fichier mais qu'en règle général, il a pas besoin de lire séquentiellement tout le fichier, si¹ ?

À quoi correspond l'action de mapper ? Car manifestement, il ne met pas tout en mémoire. Seulement le nœud d'index peut-être ?

Je ne connaissais pas. Ça a l'air très propre. Mais effectivement c'est un peu lourd comme truc.

Merci ! C'est une vraie infra légère ça. J'ai juste à mettre les trucs lourds sur le serveur le plus puissant (icinga2, grafana, …).

Je me penche là-dessus !

Je ne souhaite pas avoir de serveur dédié au monitoring. Je voudrais que chacun partage sont status à tous les autres serveurs monitorés. J'idéalise certainement un peu trop.

Euh, son site web à minima me rebute et pour être franc, me fait peur.

C'est tant que ça un problème ? Tous les outils de monitoring utilisent lm-sensord ? C'est une vraie question.

PS: Je me dis que c'est une blague mais en même temps, y a rien qui indique que c'est une blague donc ça me met très mal à l'aise.

Pour l'utilisateur nobody, j'avais bien compris qu'il posait problème. Du coup, je m'en suis débarrassé directement dans /etc/passwd et group. ^"

Il semble quand même un peu utile : https://unix.stackexchange.com/questions/186568/what-is-nobody-user-and-group. Si jamais j'ai un problème, je le recréerai avec l'uid 1999.

Merci beaucoup en tout cas, c'est bien plus clair maintenant ! Je risque également de passer au conteneur non-privilégié de root. Ça a l'air plus simple.

Oh ! Apparemment, c'est le conteneur archlinux qui a ce problème, le conteneur ubuntu fonctionne. 👌

Je dois configurer /etc/lxc/lxc-usernet

ache veth lxcbr0 11

Et lancer le conteneur avec :

$ systemd-run --user --scope lxc-start -n sandbox
$ systemd-run --user --scope lxc-attach -n sandbox

Ça marche nickel. 👌

PS: J'ai également fait systemctl edit user@1000.service pour ajouter

[Service]
Delegate=cpu cpuset io memory pids

Mais je ne comprends pas bien si ça a eu un effet. J'ai l'impression passer à côté de quelque chose dans le nom de ce service. user@1000 pour moi c'est un service comme un autre, je comprends pas bien pourquoi il existait déjà et pourquoi il fait ce qu'il doit faire. En utilisant l'option --full j'ai l'impression que c'est un service générique. On peut utiliser des paramètres dans les units systemd ? Ici le paramètre est 1000 ?

Merci à vous !

Donc j'ai modifié le fichier /etc/lxc/default.conf et également le mien dans ~ache/.config/lxc/default.conf.

En ajoutant ceci :

     lxc.idmap = u 1000 1000 1
     lxc.idmap = g 1000 1000 1

     lxc.idmap = u 0 2000 200
     lxc.idmap = g 0 2000 200

Mon /etc/subuid et /etc/subgid ressemble à ça :

      ache:1000:1
      ache:2000:200

Et là, ça ”marche”. Disons que le conteneur se crée. Mais avec des messages d'erreurs :

     tar: ./var/log/lastlog : le propriétaire ne peut pas être changé en uid 0, gid 997: Argument invalide
     tar: ./var/log/btmp : le propriétaire ne peut pas être changé en uid 0, gid 997: Argument invalide
     tar: ./var/log/wtmp : le propriétaire ne peut pas être changé en uid 0, gid 997: Argument invalide
     tar: ./var/log/journal/remote : le propriétaire ne peut pas être changé en uid 0, gid 981: Argument invalide
     tar: ./var/log/journal : le propriétaire ne peut pas être changé en uid 0, gid 983: Argument invalide
     tar: Arrêt avec code d'échec à cause des erreurs précédentes
     lxc-create: ache: lxccontainer.c: create_run_template: 1618 Failed to create container from template
     lxc-create: ache: tools/lxc_create.c: main: 317 Failed to create container ache

Bref, j'investiguerais ça. Mais pour l'instant le mapping à pas l'air mauvais. Je crois que j'ai compris comment il fonctionne ! Merci à vous ! :)

Ben au final, bien qu'un peu système D, c'est quand même une bonne solution temporaire.
J'ai un peu peur du Velcro, j'essayerais et je donne un retour dès que j'ai fait le montage.

Merci ! ^{^}

Merci, c'est effectivement ça.

Je ne comprend pas trop pourquoi dpkg n'a pas fait son travail tout seul.

LC_ALL=C est dans /etc/environment par défaut semble-t-il.

$ cat /etc/environment
ARCH=arm
LC_ALL=C

Il y a certainement une raison mais je ne capte pas l’intérêt d'avoir ça. Bref, en supprimant la ligne de LC_ALL, tout rentre dans l'ordre.

Merci bien ! Bonne journée ^{^}

Dans une moindre mesure, c'est à l'initiative des développeurs. Ça a été fait pour la peinture en miroir par exemple. (c.f. le lien de mon voisin du dessus)

Argh !

Merci. Je connaissais ce lien, mais il y en avait tellement que je m'étais perdu plusieurs fois.

En me basant sur la deuxième carte, j'ai pu en trouver (oui plusieurs) qui me convenaient parfaitement. Avec quelques recherches supplémentaires, je devrais être fixé.

Je donnerais ici un compte rendu d'installation.