Bonjour 'Nal,
J'ai les boules, un peu les glandes, et les… ouais tu vois le genre.
Il y a chez moi un petit Eee PC qui nous sert de NAS et rend quelques autres menus services : il fait tourner Apt Cacher, Transmission, stocke quelques dépôts Git pour divers petits trucs perso, et surtout un partage NFS où nous mettons les trucs à partager (le KeyPass, les photos, quelques documents, etc.)
Histoire d'avoir un peu de crédit dans les dîners mondains, j'ai bien sûr chiffré le disque de l'Eee PC. J'ai aussi mis en place une sauvegarde quotidienne sur un disque externe, chiffré aussi, et sur S3, chiffré aussi grâce à rclone, sur les bons conseils de l'excellence bivalve.
Quelle ne fut pas ma surprise de voir l'ordi éteint sans raison apparente récemment. Ce n'est rien, me dis-je, on rallume et ça repart. Ok ça boot, il me demande le mot de passe du disque. Quel est-il déjà ?
Heureusement, pas con, j'avais enregistré le mot de passe dans le KeePass. Stocké sur l'ordi que je suis en train d'essayer de démarrer. Une goutte de sueur perle sur mon front.
Regardons sur la copie du fichier KeePass qui est sur mon téléphone. Mmmh ok j'ai bien le mot de passe, avec une petite note :
Attention, le clavier est probablement en qwerty.
Comment ça « probablement » ? Ça ne m'a pas l'air très rigoureux tout ça. Quoi qu'il en soit je rentre le mot de passe. Refusé. Bon en qwerty alors. Re. Fu. Sé. Je tente cinquante fois, toujours rien. Je reboote et ouvre une console Grub pour vérifier ce que j'écris et là je pige : une touche est faiblarde et n'imprime pas toujours. Bon je relance et je saisis le mot de passe à coup d'Elbow Drop. Toujours rien. En qwerty peut-être ?
Nope, ça ne passe pas.
Une goutte de sueur perle sur ma goutte de sueur.
Là il faut se rendre à l'évidence, ça sent la restauration de sauvegarde. Les hauts-parleurs hurlent : « Ceci n'est pas un exercice. Je répète : ceci n'est pas un exercice ».
Allez c'est parti, coup de pot j'ai encore l'ISO d'Ubuntu Server que j'avais installée, pas besoin de retélécharger. Une vraie chance. Quel. Gros. Veinard.
Après l'installation et vérification que j'arrive à saisir le nouveau mot de passe du disque, je branche le disque externe. Aucun problème pour entrer son mot de passe, ouf. Je le monte. Dans ces moments on s'accroche aux plus petites victoires.
Première réflexion : ça manque d'un script de restauration en fait. Bon je commence à en écrire un, c'est pas trop compliqué. Je recopie l'arborescence à coup d'rsync --recursive --progress et… Et j'attends. Bon sang que c'est long. 250 Go de données à faire transiter d'un disque USB mécanique vers le disque interne SSD, ça se fait au mieux à 12 Mo/s. et ça prend au moins six heures. Je ne suis pas pressé de faire une restauration depuis S3.
Je mets aussi dans le script de quoi remettre les paquets qui vont bien : apt-cacher-ng en premier, puis je lui restaure sa config, et seulement ensuite j'installe les autres paquets.
Penser à virer snapd et désactiver le message du jour au login aussi.
Finalement la restauration se fait bien, modulo quelques typos dans le script et des erreurs de propriétaires de fichiers dans la restauration. Forcément tout ce qui est restauré de la sauvegarde appartient à root, mais Apt Cacher et Transmission s'attendent à avoir des fichiers possédés par leurs utilisateurs associés. Je me demande comment je pourrais garder les propriétaires lors de la sauvegarde. A priori il y aurait moyen de garder l'UID dans la copie mais que se passera-t-il si ce n'est pas l'UID des utilisateurs initiaux lors de la restauration ?
Cela étant vu, c'est l'heure du bilan :
- dossier partagé accessible sur le réseau avec ses fichiers originaux : check ;
- les machines du réseau passent par Apt Cacher : double check ;
- les pages HTML documentant les service sur le réseau sont accessibles : tchèckeu ;
- Transmission est accessible sur le réseau, avec la config restaurée : super tchèckeu turbo prime, high-five, combo ×4 ;
- la config rclone est bien restaurée : ultimate tchèckeu ;
- le script de backup est… ah bah tiens il est où ce con ? fail ;
- les dépôts Git sont absents : double fail, moins mille points.
Bon ben c'est pas si mal pour une première deuxième. Oui j'avais déjà dû faire une restauration pour cause de disque mort, ce qui m'avait amené à mettre en place des sauvegardes un peu sérieuses, notamment en copiant sur S3.
Je suis bien dégoûté de ne pas avoir sauvegardé mon script de sauvegarde. Il était hyper classe, j'en était fier, et il est parti. Avec lui a disparu la démonstration que P != NP que j'avais rédigé dans les marges, mais bon c'est la vie. En plus c'est bien galère à tester comme script, ça m'avait pris pas mal de temps de le mettre en place.
Pour les dépôts Git ça devrait aller puisque, par désaïgne, c'est sauvegardé sur d'autres machines.
Notes pour l'avenir :
- pense à fréquemment copier ton fichier KeePass sur d'autres supports ;
- « Bon y'a des trucs qui sont copiés ça a l'air ok » n'est pas une validation acceptable pour un script de sauvegarde ;
- pense à avoir un script de restauration ;
- la restauration est étonnamment lente. Le disque est un 5400 rpm qui devrait sortir du 60 Mo/s., sur un port USB 2 qui a un débit théorique à 90 Mo/s. Il y a quelque chose à faire là dessus ;
- pense à tester les scripts de sauvegarde et de restauration ;
- pense à tester le script de test des scripts de sauvegarde et de restauration ;
- pense à tester le script de test du script de test… argh.
# azerty/qwerty
Posté par Serge Julien . Évalué à 10.
Ah les keymaps indéterminées au boot!
Depuis un certain temps, sur ce genre de machine, je mets des mots de passe de 42 kilomètres de long MAIS qui utilisent uniquement les touches communes aux claviers azerty, qwerty et qwertz. C'est pas grand chose, mais on est un peu plus sûr de soi quand on tape à l'aveugle.
Sinon, il va falloir qu'on compare nos démonstrations parce que j'étais arrivé ce matin à P = NP de mon côté. La démonstration était écrite avec le doigt sur la buée des vitres, mais je viens de me rendre compte que le soleil s'est levé et paf, plus de buée…
[^] # Re: azerty/qwerty
Posté par KiKouN . Évalué à 4.
J'ai personnellement ajouter bépo ( bépoèw perso pour être exacte ) dans la liste de clavier.
Au final, ça me facilite la vie. Mes mots de passe sont devenu beaucoup plus facile à retenir.
[^] # Re: azerty/qwerty
Posté par _kaos_ . Évalué à 7.
Salut,
Moi j'ai ajouté tous les keymaps !
Et effectivement, le mot de passe est devenu rigoureusement simple. Bonus, il n'est dans aucun dictionnaire, garanti.
Pendant le calcul des combinaisons possibles pour trouver le mot de passe final à utiliser, j'ai démontré de mon côté que
P ≈ NPet chiffré la démonstration avec un fichier daté pour prouver sa précédence.Ce qui est dommage, c'est que j'ai utilisé un ancien mot de passe à ce moment, supprimé depuis puisque devenu inutile…
Matricule 23415
[^] # Re: azerty/qwerty
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
C'est pas indéterminé, c'est juste la valeur d'usine (avant que ton système applique sa traduction) …donc qwerty us (oui, oui, précision importante car il y a quelques petites variations…)
Je fais comme toi, j'utilise des touches communes pour pas avoir de surprise. Nous ne sommes pas nombreux vu le nombre de fois que j'ai du râler contre la manie des collègues à fonctionner en azerty (c'est de la m.rd. ça) et qu'on galère aussi comme ça en console pré-boot (le pire ce ont les trucs en alt-gr)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: azerty/qwerty
Posté par PLuG . Évalué à 1. Dernière modification le 10 avril 2021 à 11:39.
et utiliser une device inputkey sur port usb ?
mot de passe généré par keypass = donc sauvegardé
utilisation de inputkey pour setuper le mot de passe au début et dans la majorité des cas pour le saisir en cas de besoin …
il peut être long et compliqué ce n'est plus un problème.
… par contre, prévoir plusieurs device "inputkey" au cas ou :-)
[^] # Re: azerty/qwerty
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Clairement une bonne approche quand on utilise keypass (ou toute autre solution gérant les périphériques "inputkey") et sur une machine physique en accès direct comme ici. Faut voir si ça marche avec les consoles web/java/etc (non physiques) comme IDRAC/ILO/VMRC/etc. (Dell/HP/Vmware/etc.) où je me suis plusieurs fois pris la tête.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: azerty/qwerty
Posté par Cᴬᴾᵀ Samavor . Évalué à 1.
Grub et l'initramfs peuvent gérer les keymaps aussi, donc lors d'une MàJ de l'initramfs la keymap système peut être copiée et prise en compte pour l'entrée de la clé.
Et les keymaps peuvent être légèrement différentes d'un système à l'autre j'ai eu une petite frayeur suivie d'un temps d'adaptation quand je suis passé sous Fedora qui active la composition.
# Identifiants qui changent
Posté par HL . Évalué à 10.
La commande
rsyncutilise par défaut les noms d'utilisateur et de groupe, mais on peut utiliser les ID avec--numeric-ids.Si les UID et GID changent, on peut indiquer des tables de correspondance avec les paramètres
--usermap,--groupmap. C'est peut-être utilisable dans ce contexte.(Réponse sur SuperUser.com.)
[^] # Re: Identifiants qui changent
Posté par Glandos . Évalué à 9.
Non mais surtout il faut sauvegarder
/etcen entier. Y a tout dedans. La configuration postgresql, la configuration des scripts d'init (dans/etc/defaultou bien les services personnalisés dans/etc/systemd/system) et enfin/etc/passwdet/etc/shadow, qu'on utilise pour écraser allègrement ceux installés avant la restauration. Et dedans, y a les UID/GID pile poil.Personnellement, j'utilise borg, et je lui demande de sauvegarder tout. Toute la racine
/, sans dépasser les points de montages externes, sur lesquels se trouvent des données plus importantes, sauvegardées d'une autre manière. Et borg se souvient des UID/GID, donc ça colle avec ce qu'il y a plus haut.[^] # Re: Identifiants qui changent
Posté par Anonyme . Évalué à 3.
Non, surtout il faut des outils de gestion de configuration / IaC comme Puppet.
[^] # Re: Identifiants qui changent
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Il y a plusieurs approches (bien que j'aime beaucoup borg )
:-)Comme il a déjà du Git, il peut aussi s'en servir avec etckeeper pour sauvegarder et mieux versionner tout son
/etc.Une autre approche, est d'utiliser par exemple Ansible pour tout ce qu'il déploie (ou met à jour) avec les configurations qui vont avec. Ces playbooks étant stockés dans un dépôt Git aussi, la différence par rapport à l'autre cas est que c'est plus sélectif et qu'en plus on documente indirectement ce qui est fait de façon plus globale.
J'ai cité Ansible, mais on peut bien utiliser Chef/Salt/Puppet/etc, si on est plus à l'aise avec.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Identifiants qui changent
Posté par barmic 🦦 . Évalué à 4.
Utiliser un orchestrateur a pleins d'inconvénients :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Identifiants qui changent
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Ça a beaucoup moins d'inconvénients que de reinstaller une sauvegarde de /etc ou je ne sais quoi d'autre. Parce que cette reinstallation peut-être déstructrice si tu reinstalles un système avec une version plus récente des logiciels, donc avec de potentiels modifications dans les fichiers /etc/.
J'utilise Ansible pour configurer ma machine. Le temps passé à écrire les playbooks (et encore, y en a que je réutilises d'autres projets), est largement compensé par le temps énormément gagné lorsque je reinstalle mon ordi. Je n'ai pas à réfléchir, ni à me souvenir de ce que je dois installer pour être opérationnel, ni ce que je dois toucher dans mes fichiers de config système pour prendre en compte les spécificités de mon matériel ou de ma configuration. J'ai une machine opérationnelle en quelques dizaines de minutes, juste le temps d'installer l'OS à partir d'une ISO, de lancer ansible, et si j'ai mon /home à réinstaller, de faire un rsync depuis mon NAS.
Bonus : j'ai un desktop et un laptop, configuré quasi à l'identique. Je gagne encore plus de temps.
Alors certes, il faut maintenir à jour. Il m'arrive parfois de modifier des fichiers de conf à la main parce que je n'ai pas le temps, et dans ce cas, je le note dans INSTALL.md du dépôt de mes playbooks. Et pour les modifications dans /etc/, j'essaye d'utiliser des modules qui modifient les fichiers plutôt que d'utiliser un template qui va m'écraser les éventuelles nouvelles options si il y a des installations de nouvelles versions de soft.
Cependant, j'admet que l'utilisation d'outils comme ansible est un truc d'informaticien et que ce n'est pas forcément adapté à M. Michu.
[^] # Re: Identifiants qui changent
Posté par barmic 🦦 . Évalué à 2.
Tu as le même problème avec ansible. Tu as peut être des cas mieux gérés (mais c'est même pas dis, git va beugler si un patch ne s'applique pas correctement), mais en soit si tu veux t'éviter des soucis utiliser une distribution stable et ne pas faire de restauration d'une version majeure sur l'autre.
Je connais l'intérêt des gestions de conf', mais :
Donc tu mutualise avec du temps que tu passe professionnel. C'est pas un mal, c'est juste que si tu n'utilise pas l'outil de manière suffisamment intensive. L'utiliser est coûteux. Déjà que même pour toi le fait de devoir savoir quoi modifier dans
/etc+ mettre à jour ton playbook est du temps en plus.Oui alors tu passe ton temps à devoir gérer les modifications de ton etc + du playbook. C'est un coût que tu paie autre part. Tu as l'avantage de ne pas le faire au moment où tu es potentiellement le plus pressé, mais ça demande une rigueur. Et tu oubli dans tout ça de devoir aller regarder ton INSTALL.md pour les modifications manuelles potentielles.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Identifiants qui changent
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Si tu dois modifier un truc dans /etc, il faut savoir le faire, que ce soit à la main ou avec ansible. je ne vois pas ce que ça change là au niveau temps.
Oui, mais c'est du temps vite "rentabilisé". Alors que si tu dois modifier à la main à chaque installation .. (ou gérer les trucs écrasés par une restauration de /etc…)
Je ne comprends pas. Je ne passe pas mon temps à devoir gérer les modifs de mon etc… J'y passe 0 même. J'y passe un peu de temps, parfois, 30 secondes, quand je dois avoir des valeurs spécifiques que je modifierais de toute façon à la main. Je ne sauvegarde pas les modifications que font les logiciels d'eux même…
la liste de ces modifications reste très limitées et actuellement sur des trucs très peu importants..
Mais oui, faut un peu de rigueur.
[^] # Re: Identifiants qui changent
Posté par barmic 🦦 . Évalué à 3.
Il y a incompréhension. etckeeper ne peut pas écraser ton
/etcil va y appliquer des patch. C'est différent, mais ça apporte une fiabilité plus ou moins identique.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Identifiants qui changent
Posté par Jérôme FIX (site web personnel) . Évalué à 3. Dernière modification le 12 avril 2021 à 11:26.
Cela doit faire 5 ans que ma machine principale est en place (mai 2016), mon serveur sa dernière installation date de 7 ans à la louche (Debian 7.10 à l'installation).
Cela signifie donc que je dois, à chaque changement de version et/ou mise à jour un peu conséquente, vérifier un à un tous mes playbook Ansible pour être sûr que cela marchera à la réinstallation ?
Pas sûr que le gain de temps soit du côté de la solution Ansible !
Ansible c'est cool pour les serveurs ou quand tu déploies de nombreuses machines, sinon perso je n'en vois pas d'avantage pour remonter une machine perso, sauf à la réinstaller tous les deux jours (mais j'ai fini de jouer à cela depuis un paquet d'années !)
Mais peut être que je me trompe.
Jérôme
[^] # Re: Identifiants qui changent
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Ça fait 6 ans que j'utilise Ansible pour ma machine perso/pro, les seuls trucs que je modifie à chaque fois ce sont des identifiants de clés GPG expirées ou des infos d’accès à des dépôts tiers. Et encore. Ou alors des fois des noms de paquets qui changent ou qui n'existent plus.
En fait, j'installerais tout à la main, j'aurais exactement les mêmes problèmes.
Je ne fais pas non plus des trucs super compliqués dans mes playbooks ansible :
Bref, à part les changements que j'ai indiqué sur les dépôts et parfois des noms de paquets, mes scripts Ansible fonctionnent sans problème, tout ce que je configure ne sont pas des trucs qui changent à chaque version de Debian. Et j'économise beaucoup de temps, même si c'est une, voir deux fois par an que je les utilise.
Quand je faisais une installation à la main, c'était particulièrement pénible de passer ma journée à configurer ma machine, voire la semaine parce qu'il y avait toujours des trucs manquant pour telle ou telle tâches. Là je sais qu'après 45 minutes (install OS+update+ansible), j'ai tout opérationnel et je peux bosser.
[^] # Re: Identifiants qui changent
Posté par Psychofox (Mastodon) . Évalué à 2.
L'intérêt des outils de gestion de configuration, c'est de les faire idempotents, donc en théorie ils doivent pouvoir tourner toutes les 30 minutes sur ta machine sans tout casser, que tu mettes à jour ou pas. Typiquement puppet tournes toutes les 30 minutes sur nos serveurs.
Mais c'est aussi pour ça que je préfère puppet ou salt à ansible, c'est trop facile de faire des trucs dégueux et pas idempotent avec ansible.
[^] # Re: Identifiants qui changent
Posté par Jérôme FIX (site web personnel) . Évalué à 1.
Sur les serveurs ok… pas de soucis avec cela, même sir sur mon serveur perso je n'ai pas mis en place de telle solution. Ensuite j'ai un seul service vraiment important dessus.
C'est pour la machine perso ou j'ai plus de mal à y voir l'intérêt, ma config est principalement dans $HOME. Donc restaurer le home c'est quasi 100% du taf qui est fait !
Le reste :
- une modif dans /etc/sysctl.conf : fs.inotify.max_user_watches, au pire je l'ajouterai quand le problème se posera à nouveau
- un ou deux ajout dans des groupes de mon user : idem (docker et autre)
- un logiciel qui manque : apt install XYZ
J.
[^] # Re: Identifiants qui changent
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
En théorie… (déjà cassé des serveurs de production où tourne du Puppet après une avoir lancé une mise à jour ; déjà cassé aussi des machines de production en lançant un playbook Ansible ; dans les deux cas, les incohérences sur le serveur et sa dérive sur le temps ainsi que le défaut de tests rigoureux a fini par clasher l'outil) Les mises à jour doivent être faites avec la solution en usage, ou y être reportées pour ne pas avoir de collision malheureuse (et ça s'applique pour d'autres cas aussi : récemment, c'est avec un Ferm en place qui a été bypassé pour ajouter directement des entrées dans IPTables et au redémarrage de la machine ce fut des pleurs)
Chez mon dernier client c'était lancé tous les quart d'heure.
Chez un autre, où je l'ai le plus utilisé, c'était toutes les heures.
À noter que leur mode de fonctionnement (pull) est possible aussi avec Ansible, mais ce n'est pas ainsi que c'est utilisé par défaut …parce-que ça ne s'est jamais positionné ainsi (en concurrence des autres) mais en orchestrateur de déploiement (ce que les autres ont du mal à faire sans cachet d'aspirine et heures de bataille)
De mon expérience, partout où je suis passé et où c'est utilisé, j'ai vu des trucs dégueux et pas idempotent avec Puppet. Ceci n'empêche pas qu'effectivement, de par sa facilité, les gens ne passent pas autant de temps à faire leur Ansible et qu'on voit pas mal de choses faites vite et mal.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Identifiants qui changent
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Une manière de faire est de faire ça au fur et à mesure. Tu commences par des rêgles d'installations des quelques softs principaux que tu utilises (très simple et très rapide à mettre en place), et au fur et à mesure que tu fais des modifications sur ta machine au cours des semaines/mois qui suivent, tu écris petit à petit tes règles dans Ansible ou autre.
En général, tu n'as pas vraiment besoin "d'annuler". Ansible (et certainement les autres), ont des options en ligne de commande pour "simuler" les actions et afficher les différences (quand tu modifies des fichiers). Il y a des cas où il va raler (genre tu modifie un fichier de conf d'un paquet pas encore installé car installation simulé), mais en fait c'est rare. En ce qui me concerne la configuration ansible de ma machine est largement plus simple que celle des serveurs de ma boite par exemple.
[^] # Re: Identifiants qui changent
Posté par barmic 🦦 . Évalué à 2.
Excellente manière d'oublier des choses, tu peux difficilement lister toutes les modifications que tu as fait après coup.
C'est quoi le workflow ?
Pratique…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Identifiants qui changent
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Alors oui, si tu dois reinstaller ta machine alors que tes playbooks ne sont pas terminés, tu auras une machine pas entièrement configurée. Mais ça sera toujours moins que rien.
J'indiquais juste une méthode pour ne pas que ce soit trop chronophage au début. C'est ce que j'ai fait. Après chacun fait ce qu'il veut.
À la première reinstallation qui a suivi, j'en ai profité pour terminé l'écriture de mes playbooks pour y mettre ce que j'avais oublié d'installer. Et au final, j'ai eu assez rapidement un truc complet (je ne reinstalle pas ma machine tous les 3 mois hein..).
à la prochaine reinstall de ma machine :
Après, si tu ne trouves pas pratique, je n'oblige personne à utiliser ansible, je faisais juste part de mon expérience.
Ce que je dis là, ce n'est pas de la théorie, c'est de la pratique, c'est ce que je fais en vrai, et ça m'est beaucoup plus confortable que d'installer à la main, et ça m'a permis de ne pas passer des journées entières à réinstaller une machine suite à un disque mort, à un changement de machine ou à un upgrade d'OS qui a merdé ou trop long. (j'ai déjà testé, une reinstallation toute fraîche avec mes scripts ansible peut-être plus rapide que de faire un upgrade de distro)
[^] # Re: Identifiants qui changent
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 12 avril 2021 à 11:31.
Et moi de même j'ai tenté de m'en servir en vrai, mais j'en suis revenu. Chacun fais bien ce qu'il veut. C'est juste pas la méthode que je trouve la plus simple.
Ça peut être assez casse gueule si tu as quelque chose d'un minimum complexe. Avec etckeeper, tu vois forcément toutes les nouveautés.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Identifiants qui changent
Posté par Adrien . Évalué à 1. Dernière modification le 10 avril 2021 à 09:14.
Une autre approche peut-être de tout dockeriser : le docker-compose est versionné, il suffit ensuite de sauvegarder les volumes Docker persistant, et éventuellement les mots de passe (.env, secrets/ dans le dossier docker-compose).
La machine hôte n'ayant aucune conf, la sauvegarde du /etc/ devient assez inutile.
Remonter tout le serveur, pour une migration ou une réinstallation devient assez simple.
[^] # Re: Identifiants qui changent
Posté par Glandos . Évalué à 3.
C'est assez overkill. J'ai un Atom D2550 et « seulement » 250 Go de SSD, avec 4Go de RAM.
[^] # Re: Identifiants qui changent
Posté par Psychofox (Mastodon) . Évalué à 4.
Moi je préfère podman à docker mais dans tous les cas l'overhead est assez léger. L'avantage de ce genre de déploiement c'est que tu n'as qu'à sauvegarder le fichier compose, éventuellement l'unit systemd si tu passes par lui pour le lancer et que tu redéploies assez facilement sur une autre distro ou un autre hébergeur sans te préocupper de la config et distro qui le fait tourner.
Et si tu décides un jour d'avoir plusieurs noeuds tu peux même t'amuser à avoir un noeud debian, un noeud fedora et un noeud archlinux et t'as pas trop de risque que tout tombe si une des distros sort un patch foireux.
# et un clavier!
Posté par romi . Évalué à 10.
en cas de doute, simplement brancher un clavier de PC testé et sûr!
c'est comme les câbles, parfois on galère, on cherche midi à 14h alors que c'est simplement le câble USB (ou SCSI à l'époque, ça m'est arrivé) qui n'est pas fiable…
# Copie
Posté par barmic 🦦 . Évalué à 3.
Ce genre de copie, je ne fais en SATA des 2 cotés quitte à ouvrir une autre machine pour pouvoir faire ça tranquillement. Même si ce n'est pas pressé attendre 6h pour se rendre compte qu'on a raté un truc dans la copie, je trouve ça embêtant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Copie
Posté par Glandos . Évalué à 6.
Source : Wikipédia
Donc, c'est 60 Mo/s grand maximum. En pratique, je ne vois aussi que du 15 à 20 Mo/s
[^] # Re: Copie
Posté par flavien75 . Évalué à 5.
Je dirais même moins, selon la norme USB 2.0 (chapitre 5.8.4), dans le meilleur des cas on n'obtiendra que 53.248 Mo/s (104 trames de 512 octets).
Valeur à diminuer en fonction de l'overhead du protocole ATA.
Les vrais naviguent en -42
[^] # Re: Copie
Posté par wismerhill . Évalué à 4.
Avec un ordinateur suffisamment puissant, on peut tout à fait avoir un débit en USB2 de 45Mo/s soutenu.
Mais là on parle d'un vieil eeePc …
# Question à propos du clavier
Posté par David Demelier (site web personnel) . Évalué à 10.
Est-ce que ça ne serait tout simplement pas un clavier qui se blo
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Question à propos du clavier
Posté par saltimbanque (site web personnel) . Évalué à 9.
v us av z t us de cl viers po rris!, l s mi ns march nt beauco p mi ux
# recalbox
Posté par nomorsad . Évalué à 1.
Autre usage, j'ai installé Recalbox sur mon vieux EEEPC et avec une manette bluetooth j'ai une parfaire boiboite de jeux pour me rappeler ma jeunesse !
# utilité du chiffrement ?
Posté par Adrien . Évalué à 6.
Si l'Eee-PC sert de NAS, il ne doit pas beaucoup bouger pyhisquement. S'il reste constamment à la maison (et allumé en plus), quel est l'intérêt de chiffrer le disque tout entier ?
Dans ton histoire, c'est une grosse source d'emmerde, comme souvent avec le chiffrement, pour un gain de sécurité qui me semble assez minime.
[^] # Re: utilité du chiffrement ?
Posté par Julien Jorge (site web personnel) . Évalué à 10.
Je chiffre le disque au cas où je me ferais cambrioler. À moins que le voleur ne l'embarque en le maintenant allumé, trouve le mot de passe de la session ou un autre moyen de se loguer, il ne devrait pas pouvoir récupérer mes trucs.
En terme de source d'emmerde ça n'est pas énorme non plus. À côté de ça, en dix ans j'ai eu un ordi volé (de boulot, pas chiffré), et un ordi jeté, pas chiffré non plus. Pour ces deux là je ne saurais dire si ce qu'ils stockaient a disparu ou si ça a été copié et conservé, et ça me perturbe un peu. Il n'y avait plus grand chose de personnel dessus mais je préfère être prudent pour les prochains.
[^] # Re: utilité du chiffrement ?
Posté par Misc (site web personnel) . Évalué à 4.
Tu as regardé du coté des nouveautés comme http://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html ou https://semanticlab.net/sysadmin/encryption/Network-bound-disk-encryption-in-ubuntu-20.04/ ?
J'ai pas encore testé ça, mais si tu as besoin d'une clé u2f juste au boot, je pense que ça peux être suffisant (en supposant que tu es du bon coté de l'équation mossad/not mossad du chercheur James Mickens https://www.usenix.org/system/files/1401_08-12_mickens.pdf )
[^] # Re: utilité du chiffrement ?
Posté par xandercagexxx . Évalué à 1. Dernière modification le 16 avril 2021 à 18:32.
Je comprend la problématique et dans le même temps je me pose tjrs la question sur le chiffrement et la pseudo utilité réel (dans le contexte familiale que tu décris)
Si je comprend bien, en 10ans tu as subit (connu) 1 vol d'ordinateur et vu ce que tu donnes comme info, pas de cambriolage chez toi. Appliques-tu le même niveau de sécurité à tous les autres éléments/contenu/etc que tu possèdes (les relevé de compte en format papier par exemple, l'accès aux smartphone, les objets cher/sensible que tu possèdes, etc.)
Le bénéfice/risque est-il si intéressent que cela, de chiffrer le disque du eeepc pour être obligé de restaurer un backup car le fichier de mot de passe (la bdd keepass chiffré 2 fois au final) n'est pas accessible ?
D'ailleurs, ne pouvais-tu pas "juste" restaurer ton keepass sur une autre machine pour pouvoir récupérer le mot de passe de la première machine ? (restaurer sur une machine rapide et utiliser la bdd keepass pour débloquer la machine lente). Peut-être qu'une piste est juste de stocker la bdd keepass sur un support non chiffré aussi (si tout les mot de passe sont dans le keepass, comment tu restaure ton backup chiffré ?).
J'ai mis en vrac mes différentes interrogations qui me viennent en écrivant, et c'est des questions que je pose aussi à moi même. (ne faudrait-il pas par exemple, mettre le nas dans une pièce sécurisé, plutôt que de chiffrer les données par exemple).
:)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.