Voici comment on peut perdre bêtement le contenu de son homedir …
J'ai maladroitement configuré un dépot git, et en voulant comprendre ce qui n'allait pas, j'ai lancé cette commande :
totof@newbipbip:~/Documents$ git clone ssh://ban@82.229.78.185/~
Clonage dans '~'...
warning: Vous semblez avoir cloné un dépôt vide.
$ ls
~ ban
Ca a marché, mais comme ce répertoire ~ me gênait, j'ai fait la seule chose à ne pas faire :
$ rm -fr ~
rm: impossible de supprimer '/home/totof/Documents/simavr/examples/board_ledramp/obj-x86_64-linux-gnu/ledramp.elf': Permission non accordée
rm: impossible de supprimer '/home/totof/Documents/simavr/examples/board_ledramp/obj-x86_64-linux-gnu/ledramp.o': Permission non accordée
[...]
suis tellement dégouté par cette erreur complètement débile que je ne sais quoi dire, ni quoi faire, à part écrire ce journal.
Heureusement, j'ai encore une sauvegarde d'il y a environs 1 an, et il n'y a pas grand chose que je ne puisse retrouver ou refaire, mais c'est surtout la stupidité de mon action qui me dégoute.
Ca m'apprendra à faire attention, et surtout à bien configurer mes repo git. Ca montre également qu'il n'y a pas qu'en tant que root qu'on peut faire de grosses erreurs.
Je vais aller me coucher, avant de faire autre chose de pire.
# Récupération avec livecd
Posté par Olivier Esver (site web personnel) . Évalué à 6.
Pour les photos, testdisk/photorec font des miracles (même si les noms ne sont pas terribles)
Je n'ai pas testé mais extundelete peut peut-être marcher si t'es en ext3 ou 4
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Récupération avec livecd
Posté par totof2000 . Évalué à 3.
A priori, en démarrant en mode maintenance et en empêchant le montage de mon home, je devrais m'en sortir sans liveCD (je sépare toujours mes partitions / /home et /var, dans ce genre de cas c'est bien pratique). Il faut juste que je trouve de la place disque pour la récupération, et la place disque, j'en ai pas beaucoup en ce moment …
Celà dit, je n'ai pas forcément besoin de tout récupérer. Le truc qui me gènerai le plus de perdre, c'est les petits développements que j'ai fait pendant un an, dont une tentative de portage de taptempo qui m'a pris beaucoup de temps, et que je n'ai pas encore publiée.
[^] # Re: Récupération avec livecd
Posté par Sufflope (site web personnel) . Évalué à 5.
Euh salut, t'es mon autre personnalité ?
[^] # Re: Récupération avec livecd
Posté par totof2000 . Évalué à 5.
sais pas … Taptempo, j'aime bien. C'est un truc tout bête, bien plus intéressant que HelloWorld, et qui est un bon exercice de portage en plusieurs langages/environnements.
# De l'utilité de la tabulation
Posté par Anonyme . Évalué à 9.
Personnellement, il m'est absolument impossible psychologiquement de faire entrer sur une commande manipulant des fichiers sans avoir utilisé sur la touche tabulation avant.
Dans ton cas, cela aurait dû t'afficher le contenu de ton home, c'est du moins le comportement que j'ai avec zsh.
(cela dit, c'est quand même fou qu'à notre époque on ait pas des systèmes de fichiers qui fassent ce genre d'actions dans des transactions qu'on pourrait rollback…)
[^] # Re: De l'utilité de la tabulation
Posté par ʭ ☯ . Évalué à 10.
Pour l'utilisateur final, on a ça s'appelle la corbeille. Mais quand tu attaques à coups de rm -rf comment différencier le "j'ai besoin d'espace disque" du "je suis en train de faire une connerie"?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: De l'utilité de la tabulation
Posté par totof2000 . Évalué à 3.
Ce genre de farce avec le ~ m'est déjà arrivé une fois. A ce moment, j'étais suffisamment alerte pour comprendre que le rm sur ~ virerait tout mon homedir. J'ai donc fait un mv de ./~ vers toto avant la suppression, et refait un clone en précisant le rep cible.
Je me suis dit aussi qu'il faudrait que je revois mon script de création de repo pour qu'il me fasse plus ce genre de truc, ou ma méthode de récupération du repo, mais procrastination oblige, j'ai laissé ça de côté et j'ai oublié. Et hier soir, il était tard, et j'ai pas fait attention .. et paf le rm.
[^] # Re: De l'utilité de la tabulation
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 8.
Bah si, il suffit d’utiliser un système de fichiers moderne. Par ex. zfs et ses snapshots, et sans doute aussi BTRFS (mais là, j’avoue que je ne le connais pas).
Mais bon, ça ne dispense pas non plus de faire des sauvegardes, hein…
[^] # Re: De l'utilité de la tabulation
Posté par jyes . Évalué à 6.
btrfs + snapper donnent de très bons résultats, instantané pris à chaque ouverture de session, utilisé au quotidien chez moi.
Une autre solution, que je conseille autour de moi mais que j’avoue ne pas beaucoup utiliser, c’est de prendre l’habitude d’utiliser « trash » plutôt que « rm », quitte à faire un alias mais pas sous le nom « rm » car ça fait prendre de très mauvaises habitudes.
[^] # Re: De l'utilité de la tabulation
Posté par nerbrume . Évalué à 1.
J'utilise trash (aliasé sur "rt" chez moi) sur toutes mes machines, en tant qu'utilisateur et root également.
Avec un cron qui vide le .Trash toutes les nuits, histoire de liberer la place.
Ca m'a déjà sauvé d'erreurs stupides…
En revanche, il n'est pas conseillé d'aliaser rm sur trash : le jour où tu n'es pas chez toi, ca peut faire bizarre. Et puis quand j'ai vraiment besoin de faire de la place là maintenant tout de suite, j'utilise rm, mais du coup, je relis deux fois ce que je viens d'écrire avant de faire entrée. Bref, ca forme une bonne habitude.
Mais il faudra que je me penche sur les snapshots btrfs un de ces jours…
[^] # Re: De l'utilité de la tabulation
Posté par pralines . Évalué à 3.
est-ce qu'il s'agit bien de trash-cli ?
https://doc.ubuntu-fr.org/trash-cli
https://www.lifewire.com/delete-files-using-linux-command-line-4119814
Envoyé depuis mon Archlinux
[^] # Re: De l'utilité de la tabulation
Posté par Dreamkey . Évalué à 8.
C'est pas forcément sauveur d'utiliser tab, au contraire : j'avais fait un dossier symbolique dans
/tmp/ploppour tester quelque chose, et quand j'ai voulu le supprimer, le tab m'a rajouté un/au nom du lien, ce qui donnaitrm -r /tmp/plop/…J'ai malheureusement mis quelques secondes à comprendre pourquoi la commande ne retournait pas immédiatement.
[^] # Re: De l'utilité de la tabulation
Posté par Tonton Th (Mastodon) . Évalué à 4.
VMS savait faire ça il y a bien plus de trente ans…
# Sauvegarde automatique
Posté par Walter . Évalué à 5.
Pour éviter ce genre de mésaventure, je met tout sur un serveur de fichier.
Pour ce qui doit être obligatoirement dans le dossier personnel de la machine, j'ai programmé une copie régulière de tout le dossier personnel vers le serveur.
Ça occupe un peu de place, mais ça devient dur de perdre des données.
Et surtout ça couvre :
- Le chat/enfant qui joue avec le clavier
- Les gouttes d'eau sur le clavier, que l'on essuie sans verrouiller la session
- Le travail bourré/malade
- Toutes autres action stupides que l'on regrette juste après l'avoir validé
- J'ai la flemme, pas maintenant ou toute autre type de procrastination
- accessoirement la panne, mais ça c'est juste un effet de bord.
[^] # Re: Sauvegarde automatique
Posté par totof2000 . Évalué à 2.
Je n'ai pas de serveur de fichier en tant que tel, mais je rsync régulièrement mes données de mon portable vers ma machine fixe. Mais ces derniers temps je n'ai plus beaucoup de place disque, et j'avais entamé une démarche pour créer un serveur de fichier dédié. J'ai pas encore fini mais le dépot git était créé justement pour ne pas perdre mes données.
Suite à ça je crois que je vais cesser ma réorg de données, et commencer par louer un serveur dédié ou un espace disque quelque part dans le cloud, et faire une copie de mes données qui me restent, ou que j'aurais réussi à récupérer, juste le temps de faire un peu de ménage et de monter mon serveur de fichier.
[^] # Re: Sauvegarde automatique
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 5.
Tarsnap est très bien pour ça.
[^] # Re: Sauvegarde automatique
Posté par totof2000 . Évalué à 2.
Cool, merci pour le lien, je vais m'y intéresser de près.
[^] # Re: Sauvegarde automatique
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est par ça que tu aurais du commencer bien avant de "faire le ménage" et même si ça impliquait de "gaspiller" du stockage temporairement. C'est à mon sens la plus grosse connerie que tu ais faite car finalement des fautes de manip en interactif on en fait tous avec des conséquences plus ou moins grandes. De nos jours on peut louer un serveur dédié/semi-dédié ou de l'espace de stockage en une poignée de minutes et le détruire aussi vite si besoin.
Après les sauvegardes déportées c'est bien, mais ne surtout pas oublier de copier/synchroniser les clés de chiffrement / password d'accès quelque part ailleurs disponible à tout moment et avec un secret que l'on a en mémoire ou tout du moins qu'on peut retrouver sans pc.
[^] # Re: Sauvegarde automatique
Posté par totof2000 . Évalué à 2.
Yep, je suis allé un peu trop vite. Mais les choses se sont un peu enchainées sans que j'y réfléchisse réellement. Ajouté à la fatigue, toutes les conditions pour faire ce genre d'erreur étaient réunies.
J'aurais du m'arrêter quand je me suis rendu compte que je n'avais plus d'espace pour faire une copie "raw" de mon homedir. (le pire c'est que j'y ai pensé, mais je me suis dit "allez, ça ne prendra que 5 mn. et efectivement, ça m'a pris moins de 5 mn pour tout perdre).
# le proverbe qui va bien
Posté par Christophe B. (site web personnel) . Évalué à 7. Dernière modification le 02 mai 2018 à 07:27.
chez les sysadmins ont repete souvent :
il y a 2 categories de sysadmins :
ceux qui ont fait une betise avec root et ceux qui vont faire une betise avec root…
sinon j ai un script de sauvegarde de home dir base sur borg pour ceux que cela interresse
[^] # Re: le proverbe qui va bien
Posté par totof2000 . Évalué à 5.
Je crois que ce proverbe n'est pas applicable dans mon cas : je n'étais pas root (mais je fais partie de toute façon de la 1ere catégorie).
Le plus désolant dans cette affaire, c'est que j'étais en train de mettre en place des dépots git justement pour ne pas perdre mon travail.
J'ai commencé par le dépot git parce que je n'ai plus beaucoup de place disque pour sauvegarder mon homedir quelque part, donc le but initial était de faire de la place.
[^] # Re: le proverbe qui va bien
Posté par nico4nicolas . Évalué à 5.
Ca c'est plutôt bien réussi ! Tu peux maintenant passer à la suite ;) Je me permets de me moquer car je fais partie de la grande majorité à qui une telle mésaventure est déjà arrivée.
[^] # Re: le proverbe qui va bien
Posté par Obsidian . Évalué à 4.
En plus, il est qualifié pour devenir BOFH, maintenant…
[^] # Re: le proverbe qui va bien
Posté par Christophe B. (site web personnel) . Évalué à 2.
s/root/rm/ :)
[^] # Re: le proverbe qui va bien
Posté par Christophe B. (site web personnel) . Évalué à 4.
s/root/rm/ :)
ma bétise à moi :
rm -fr r* en étant dans /dev sur une machine en exploitation sinon c'est pas drôle
à l'époque sous sco unix les périphériques de disques s'appelait rdsk*
comme la machine tournait et qu'un fichier ouvert n'est pas réellement effacé ce qui est le cas des rdsk…
j'ai pu me palucher tout les mknod en copiant sur une machine équivalente, en priant pour qu'il n'y ait pas
de coupure de courant entre temps.
Un peu de stress lors du premier reboot mais globalement plus de peur que de mal
On apprend plus de ses erreurs que de ses réussites.
[^] # Re: le proverbe qui va bien
Posté par totof2000 . Évalué à 2.
Dans la liste, à mes tous débuts, j'ai fait un truc du genre mv file /dev/null pour supprimer un fichier …
[^] # Re: le proverbe qui va bien
Posté par Tonton Th (Mastodon) . Évalué à 2.
http://sam.linuxfr.org/efface
[^] # Re: le proverbe qui va bien
Posté par freem . Évalué à 2. Dernière modification le 04 mai 2018 à 11:46.
C'est sûr, vu que quand on ne fait pas de conneries, il n'y a pas besoin d'apprendre à les réparer… non non, c'est pas en faisant des conneries que j'ai appris quasi-par coeur la liste des services utiles de windows (à l'époque), des paquets «utiles» de ma Debian ou comment récupérer un fichier dans une partition FAT32 à coup d'éditeur héxa :p (sans parler la pléthore de trucs & astuces qui du coup sont utiles même hors des situations d'urgence).
Sinon, moi, j'ai déjà fait un
killall -9 sshsur une machine à laquelle on n'accédait que… via ssh, moi inclut :) (je ne sais plus pourquoi j'avais eu cette drôle d'idée d'ailleurs).[^] # Re: le proverbe qui va bien
Posté par barmic . Évalué à 1.
Je suis sûr que l'état d'esprit dans le quel tu es quand tu commet une erreur fait que tu mémorise mieux.
[^] # Re: le proverbe qui va bien
Posté par Christophe B. (site web personnel) . Évalué à 4.
Si tu cherches les betises rigolottes :
et en contrepartie tu peu plus te connecter :)
Avant SD (systemd) unix utilisais initttab et le niveau d'init 0 correspond à l'arrêt de la machine
le niveau 6 au reboot
Donc une machine avec un init par defaut à 6 ne fait que rebooter … alors qu'avec tu l'allumes … elle s'éteint
pensez y pour le 1er avril …
# Blame the victim
Posté par Fabrice Devaux . Évalué à -3.
1-Pas normal de pas avoir de sauvegardes récentes. Pour ce type de fausse manip j'ai une sauvegarde quotidienne sur un autre répertoire du même disque (ça ne protège pas de la mort du disque, mais ça protège des rm & co).
2-Sans rire tu tapes "rm -fr ~" sans te dire "~ c'est $HOME" ?!
[^] # Re: Blame the victim
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
On peut augmenter le niveau de perversité en créant volontairement un fichier ou un répertoire ~:
Note: ceci n'a pas beaucoup d'intérêt (à part trouver une excuse de mauvaise foi au fait de vouloir supprimer un fichier/répertoire ~). Ceci a bien évidemment été réalisé par un professionnel entraîné et aguerri à réaliser des cascades en shell, ne refaites pas ça chez vous les enfants.
[^] # Re: Blame the victim
Posté par Tonton Th (Mastodon) . Évalué à 3.
well done bro !-)
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 8.
En général, si. Mais vu l'heure et mon état physique du moment, j'y ai pas pensé (et il ne faut surtout pas penser que ça ne t'arrivera jamais, parce que c'est quand tu penses ça que ça t'arrive).
[^] # Re: Blame the victim
Posté par calandoa . Évalué à 10. Dernière modification le 02 mai 2018 à 14:44.
Rassure-toi, la situation pourrait être pire : tu pourrais être un connard imbuvable qui passe son temps à humilier ceux dans la merde en leur reprochant de ne pas être parfait et de faire des erreurs dans leur vie, ta femme aurait pu te quitter, tes enfants pourraient ne plus t'adresser la parole et tu pourrais crever tout seul comme un rat sous la pluie sans que personne n'en ai rien à faire.
(pour ceux qui se sentiraient visés, je plaisante bien sûr, c'est juste un vague support psychologique, d'ailleurs même moi je me sens auto-visé en écrivant ça)
[^] # Re: Blame the victim
Posté par arnaudus . Évalué à 10.
Pas normal de faire un chèque sans savoir qu'il va être encaissé entre un gros achat et le versement du salaire. Pas normal de ne pas vérifier la DLC avant de bouffer un truc qui sort du frigo. Pas normal de ne pas avoir vérifié les piles du distributeur de croquettes du chat avant de partir en vacances…
Sans rire, tu tends le pied pour rattrapper ton marteau sans te dire «merde, je vais m'éclater les doigts de pieds»?
La négligeance, c'est la norme chez les gens qui ont une vie un peu compliquée avec des centaines de trucs à faire et à penser dans la journée. Tout le monde ne passe pas sa vie à tout faire soigneusement, tout anticiper, tout planifier… Et les accidents, c'est toujours idiot. C'est même le principe des accidents. Si on vivait dans un monde où tout le monde était prévoyant et où personne n'agirait stupidement, alors oui, il y aurait moins de conneries. Blam blam, double enfonçage de portes dégondées depuis des siècles.
Ce que ce genre de trucs cache, c'est finalement que nos systèmes informatiques sont encore très loin d'être rentrés dans un processus rationnel de mise au point d'une interface fonctionnelle. La norme d'un logiciel de bureautique est forcément d'avoir une fonction Annuler/Ctrl-Z, par contre, aucun shell n'a ça. Ça n'a pas de sens, quelque part…
[^] # Re: Blame the victim
Posté par Marco . Évalué à 4. Dernière modification le 02 mai 2018 à 16:11.
La différence c'est qu'ici l'utilisateur a tout son temps taper la commande et la valider.
Tu peux toujours faire un mv vers ta corbeille et te créer un script shell type rm_safe que tu mettra dans ton bin.
D'ailleurs je pense que ca agacerait certains de devoir reconfirmer en vidant la corbeille. La preuve est qu'ici l'option f a été utilisé alors que le répo est vide.
[^] # Re: Blame the victim
Posté par arnaudus . Évalué à 2.
Le constat, c'est que la baraque est faite de matériaux inflammables, et en gros, tu dis qu'il vaut mieux utiliser des allumettes qu'un briquet… Le fait est qu'il est beaucoup trop facile de faire des conneries irrattrappables en ligne de commande, ça n'a pas grand chose à voir avec les options de rm. Tu peux aussi péter un système avec chmod, ou avec plus ou moins n'importe quel utilitaire qui fait quelque chose. On ne va pas changer les options par défaut des commandes UNIX, ça n'a pas de sens. Ça n'aurait pas non plus beaucoup de sens de diminuer la puissance de ces outils ; les demandes de confirmation sont pénibles et sans aucun effet (tout le monde va taper -f automatiquement, et puis voila).
Bien sûr, la remarque des vieux barbons, c'est que ça a toujours été comme ça, que les gens n'ont qu'à faire attention, qu'eux ne font jamais d'erreurs et/ou que quand ils font des erreurs, c'est qu'ils l'ont bien cherché, etc. Mon avis là-dessus, c'est que ces "opinions" sont sans grand intérêt. Ce genre de discours ne revient qu'à nier les problèmes, à faire porter les problèmes sur les gens plutôt que sur les logiciels, et à nier les pertes de données, d'argent, et de temps dûs à la mauvaise conception de nos interfaces.
De facto, la très grande majorité des commandes qu'on tape dans un terminal sont trivialement réversibles. D'autres, comme rm, seraient également trivialement modifiables pour être réversibles. Le coût associé à une réversibilité serait très faible; il suffirait d'avoir un historique simplifié des actions sur le système (sachant que tous les shells courants logguent déja la liste des commandes dans un fichier d'historique, la liste des effets ne serait pas bien coûteux…).
Alors oui, YAKA, FAUKON, toussa toussa. Il n'est pas non plus évident de savoir à quel niveau l'intervention doit être faite (est-ce à ln ou chmod de garder un historique d'appels systèmes, ou est-ce au shell d'interpréter les commandes usuelles?). Mais je trouve qu'on est beaucoup trop complaisants avec le statu quo ; se complaire dans une ergonomie dégueulasse n'est à l'honneur de personne.
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 4.
La dessus je ne suis pas d'accord avec toi. Je ne suis pas d'accord sur le fait que l'interface est mal fichue. Dans mon cas, le comportement de rm -fr est bien décrit et connu, et ça ne me pose pas problème. rm fait ce qu'il est censé faire et il le fait bien, sans mentir. Et si rm supprime quelque chose alors qu'il n'aurait pas du, j'assume, c'est ma faute. Je ne veux surtout pas qu'on change le comportement de rm -fr. c'est pareil pour le reste (le chmod dont tu parles par exemple).
Par contre, je ne serais pas contre une alternative à rm qui serait réversible pour les jours ou je suis fatigué …
Je ne suis pas si sur que ça soit si simple : par exemple, un rm réversible quand tu n'as plus de place sur un filesystem n'a pas trop de sens.
[^] # Re: Blame the victim
Posté par arnaudus . Évalué à 4.
Le rm pourrait rester réversible tant que tu n'as pas écrasé la zone avec d'autres données, ce qui permettrait de débloquer une très grande majorité des situations (où, quand même, tu t'aperçois très très vite que tu as perdu un fichier).
Ce que je voulais développer, c'était qu'il n'était pas raisonnable de vouloir développer des commandes alternatives ou de modifier des comportements par défaut, ça n'est pas efficace et ça ne ferait qu'encourager les contournements. Il "suffirait" de développer un moyen d'annuler les commandes sans modifier leur sémantique.
[^] # Re: Blame the victim
Posté par bubar🦥 (Mastodon) . Évalué à 7. Dernière modification le 02 mai 2018 à 20:50.
Cela m'est arrivé pas plus tard que hier : une vm pour compiler un soft pour lequel je veux faire/automatiser une appimage. J'ai démarré une vm "au hasard" la sachant vide et inutile aujourd'hui. Mais pas assez de place sur le disque. Donc ajout d'un autre disque, copie de /usr dessus, classique, j'efface l'ancien, je remonte, coup de téléphone, et .. vous avez compris la suite : j'efface "l'ancien" /usr puis j'apprete à monter le nouveau disque sur /usr … :p :p :p
Là c'est sans conséquence, autre qu'une grosse perte de temps, mais c'est au moins aussi con qu'un simple rm ! Ce qui devrait systématiquement nous rappeler le proverbe :
[^] # Re: Blame the victim
Posté par Meku (site web personnel) . Évalué à 2.
Moi il y a quelques mois, j'ai pourri le /var/lib d'un serveur de backup (miroir) que je préparais. Je voulais copier une application installée là-dedans vers le serveur de backup en utilisant rsync car j'avais la flemme de faire un tar/scp/tar.
Mais pour une sombre histoire de '/' en fin de path, ça c'est pas passé comme prévu. Il m'en a foutu partout c'était horrible. Alors j'ai tenté de réparer rapidement le bordel je ne sais plus trop comment. Ensuite je me souviens que j'ai dû prendre la décision de réinstaller tout le système depuis zéro car c'était pire qu'avant (notamment, j'avais perdu la base de yum, dont la liste des paquets installés).
C'était vraiment con car vu qu'il y avait des milliers de petits fichiers à copier, un tar/scp/tar était 100 fois plus rapide en durée d'exécution.
[^] # Re: Blame the victim
Posté par freem . Évalué à 3.
Je pense que sur des serveurs, des outils comme cfengine, chef, puppet & co doivent permettre d'éviter ce genre d'erreurs non? Enfin, je dis ça, mais je ne sais pas m'en servir, paille, voisin, poutre, tout ça… (ceci étant dit, c'est en haut de ma todo list, j'ai même déjà fait quelques recherches sur le sujet, notamment comment intégrer cfengine à runit/demontools, mais la doc est terriblement pourrie quand même, et il ne semble même pas y avoir un IRC :/).
[^] # Re: Blame the victim
Posté par barmic . Évalué à 2.
Franchement je ne pense pas que cfengine soit le plus sympa pour commencer. Chef, Puppet, Ansible ou Salt sont bien plus cool à utiliser (surtout ansible qui a beaucoup de succès et dont on peut trouver beaucoup d'info du coup).
[^] # Re: Blame the victim
Posté par freem . Évalué à 2.
Le problème n'est pas d'être cool, mais de pouvoir être utilisé sur du matériel très «léger» (que ce soit en ram, en disque, ou en bande passante avec des connexions type GPRS/GSM/3G, accessoirement), et de ce que j'ai cru comprendre ici et la, cfengine semblait le plus logique dans ce type de situation.
Mais bon, je vais probablement regarder ailleurs, parce que comme je l'ai dis, la doc est franchement mauvaise, sur plusieurs points:
Enfin, pour le moment, faut livrer en urgence, donc on verra ça plus tard -.-' (même si je me suis préparé le terrain quand même).
[^] # Re: Blame the victim
Posté par barmic . Évalué à 2.
Par cool j'entends qu'on peut trouver des informations sur le net.
Alors c'est des outils qui sont principalement vu comme étant utilisés en datacenter/sale serveur donc c'est pas des problématiques directement adressées, mais Salt utilise un moyen de communication très léger avec les minions (les agents salt) grâce à 0MQ. Là où Ansible va plutôt utiliser SSH. Mais ansible, n'a pas d'agents donc n'utilise des ressources que quand il est en cours d'exécution.
[^] # Re: Blame the victim
Posté par Psychofox (Mastodon) . Évalué à 5.
salt est le plus léger des outils avec agents, c'est aussi le plus performant pour des grosses quantités de machines gérées là où des ansible/puppet peuvent arriver à la peine quand on atteint la dizaine de milliers de machines gérées (mais bon faut déjà y aller).
ansible est agentless mais a quand même besoin d'un python
cfengine est un peu l'ancêtre de la bande, et donc la conf est pas forcément très folichone et à l'époque de la version 2 j'avais pas le souvenir d'une idempotence assurée.
Pour de l'embarquée j'aurais tendance à privilégier salt.
[^] # Re: Blame the victim
Posté par freem . Évalué à 2.
Merci à vous pour les infos.
Du coup, salt, ça se passe comment au niveau init (pid1)? Il se double-fork joyeusement sans moyen de contrôle, ou il peut être sympa, rester en avant-plan et causer tranquillement et exclusivement sur stdout/stderr?
[^] # Re: Blame the victim
Posté par freem . Évalué à 3.
De la littérature que j'ai déjà avalée, j'ai cru comprendre que les agents sont la pour synchroniser les systèmes. Donc, en théorie, rien n'empêcherait de les démarrer uniquement sur des plages horaires, économisant CPU et RAM?
Ce qui est triste, à l'heure de l'IoT, parce que ces outils me semblent intéressants pour résoudre entres autres le problème de mettre à jour des systèmes dont la connexion réseau est sporadique et l'accès physique très coûteux.
Enfin, c'est mon impression.
[^] # Re: Blame the victim
Posté par barmic . Évalué à 2.
À toi de faire le taff et de le maintenir, mais je croyais que tu voulais le monitorer ça va encore complexifier ton bousin.
Ça dépend de ta connexion sporadique. Si on parle de réseau comme sigfox ou lora, ça va vraiment faire la gueule de faire des mises à jours système dessus… S'il s'agit juste de perte fréquentes de connexion ça n'est pas un problème.
Après tu peux toujours simplement monter un dépôt de paquet et faire tes actions via les mises à jours automatiques du système, ça marche très bien.
[^] # Re: Blame the victim
Posté par kna . Évalué à 3.
Avec ansible, tu peux aussi utiliser ansible-pull. C'est un script qui pull un repository et lance un playbook localement. On peut le lancer via un cron.
Néanmoins, ça implique d'avoir ansible installé sur chaque machine (pour exécuter le playbook). Mais pas besoin d'agent qui tourne sur la machine ni de pouvoir lancer des connexions vers elle. Il faut juste que la machine puisse accéder au repository.
[^] # Re: Blame the victim
Posté par freem . Évalué à 2.
C'était juste une question «pour le sport», et pour contrecarrer un peu l'argument de l'usage des ressources par un agent :)
Je ne connais pas sigfox et pas trop lora, mais effectivement, dans le cas de lora, je doute que le débit suffise pour faire des MàJ avec les moyens conventionnels. Peut-être que ça pourrait passer avec des patchs, cela dit.
C'est sûr, et j'y ai pensé, mais l'inconvénient dans ce cas c'est si une application part en vrille pas possible de la remonter. D'un autre côté, tu me diras, un système de supervision type daemontools permettrai de la relancer en cas de plantage (reste d'autres problèmes, mais ça fait déjà une bonne classe de problèmes à gérer en moins).
[^] # Re: Blame the victim
Posté par aiolos . Évalué à 2.
Sigfox, avec le forfait standard, c'est 4 "downlink messages" de 8 octets par jour. La mise à jour va effectivement être un peu longue…
C'est un peu plus pour LoRa, qui peut recevoir un message après chaque transmission, mais ça reste pas de la folie non plus. Je ne connais pas les offres commerciales des opérateurs pour LoRa…
Non, ces restrictions sont avant tout légales : ces réseaux IoT fonctionnent sur des fréquences en libre accès pour n'importe qui, il faut donc veiller à ne pas trop les occuper. Du coup des régulations sont en place pour éviter que quelqu'un s'octroie la totalité de la bande.
Ceci dit, NB-IOT (qui vient de la 3GPP) peut fonctionner sur les bandes de fréquences alouées à LTE (sur les bandes de garde), ils n'ont sans doute pas des restrictions aussi fortes.
[^] # Re: Blame the victim
Posté par freem . Évalué à 2.
Effectivement. Mais, comment diantre font nos pauvres développeurs web pour établir leurs websockets? :D (le trolldi, c'est permis)
Je n'avais pas du tout pensé à cet aspect.
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 3. Dernière modification le 03 mai 2018 à 15:06.
J'ai touché à cfengine il y a un peu plus d'un an, et franchement je te conseille fortement d'oublier cette bouse : fichiers de conf illisible, peu de docs, et plein d'autres défauts que je préfère taire. En plus il a besoin d'un agent en local.
Ansible est bien plus lisible et bien mieux documenté, même s'il a aussi ses défauts. Je préfère lire un yaml qu'un obscur dsl pourri à la cfengine.
[^] # Re: Blame the victim
Posté par freem . Évalué à 2. Dernière modification le 03 mai 2018 à 16:54.
Sur ce point, je ne vais pas avoir le choix, je préférerai éviter d'avoir un reverse tunnel ssh permanent, et vu que je suis derrière des connexions type téléphone, je n'ai pas le contrôle sur le lien lui-même, donc, ni NAT ni IP fixe. Bref: ansible, s'pas plausible (pas pu me retenir, mais j'avoue que c'est mauvais comme blague).
[^] # Re: Blame the victim
Posté par Meku (site web personnel) . Évalué à 2.
Oh si certainement. En fait je ne suis pas un vrai sysadmin moi. J'ai monté un serveur artisanalement pour le projet parce que le service informatique est à la rue, et j'ai monté un serveur de secours car j'ai (à raison) peu confiance dans les sauvegardes du service informatique. Et j'ai du faire tout ça sur mon budget de dev, donc hélas peu le temps d'expérimenter de nouveaux outils ;-(
[^] # Re: Blame the victim
Posté par freem . Évalué à 2.
Nous somme 2 (au moins) :)
Au moins t'en a un, et il t'empêche pas de bosser :D dans ma boîte actuelle, y'en à pas (faut dire, moins de 10 employés aussi), et dans celle dont je suis parti en moins de 3 mois, il m'empêchait littéralement de bosser (grosse boîte, plusieurs centaines de personnes. Veni Vidi Parti.).
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 3.
C'est ce que j'aurais fait dans un état normal (et que j'ai déjà fait il y a plusieurs mois). Mais la fatigue peut jouer beaucoup de tours : perte de concentration et de lucidité. Ce n'est pas pour rien qu'on déconseille de prendre le volant lorsqu'on est fatigué. D'ailleurs, même sans prendre le volant, la fatigue peut être dangereuse pour soi (j'ai déjà failli me faire écraser en traversant à un carrefour protégé parce que j'étais fatigué et que je n'avais pas fait attention au petit bonhomme rouge. Je l'avais bien vu mais mon cerveau n'avait pas réagi).
[^] # Re: Blame the victim
Posté par arnaudus . Évalué à 2.
Mais de toutes manières, l'argument est purement rhétorique. Quel est le délai moyen entre la fin de la commande et l'appui sur Enter chez un admin sys? Autour de 100ms?
Le mec qui relit ses commandes une par une avant de taper entrée, il n'a un peu que ça à faire… C'est juste l'histoire de blâmer l'utilisateur, un peu comme balancer "RTFM" quand -h n'envoie pas une page d'aide.
[^] # Re: Blame the victim
Posté par Marco . Évalué à 2.
Tout dépend de la commande que je tape : je prêterais bien plus attention à un rm -fr qu'à une commande type cd/rmdir/ls ou même rm sans r. Mais je te rassure, je fais aussi partie de la partie de la population qui ait déjà perdu des données bêtement.
D'ailleurs j'ai essayé de supprimer un fichier en utilisant la touche shift sous w$, pour voir si je peux le récupérer facilement (avec ctrl+z) et cela ne semble pas possible avec un ctrl+z
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 2.
Le problème avec Windows, c'est que tu ne peux pas systématiquement faire un reverse du rm. Et tant qu'à faire, je préfère un comportement cohérent, quite à ne rien récupérer, plutot qu'un comportement variable en fonction des circonstances. Au moins je sais à quoi m'attendre.
[^] # Re: Blame the victim
Posté par Olivier . Évalué à 4.
Sur Windows, la suppression des fichiers n’efface que leur existence sur la table qui les référence, même s’ils ne sont plus dans la Corbeille. (N’est-ce pas la même chose sur Linux ?)
C’est normal puisque effacer réellement des gigaoctets de données, c’est long. Le système ne perd pas son temps à écrire des zéros à la place des fichiers, et ceux-ci ne sont vraiment écrasés que lorsque d’autres fichiers sont écrits par-dessus ces emplacements considérés comme libres.
Sur Windows, il existe plusieurs logiciels qui scannent le disque à la recherche de ces fichiers oubliés mais toujours présents. C’est long, puisque tout le disque doit être lu, mais j’ai pu récupérer plusieurs de mes maladresses ou celles d’autrui ainsi. On peut même souvent retrouver des fichiers effacés il y a des années. Mais c’est la loterie. L’important, pour récupérer les fichiers effacés, c’est de ne plus rien écrire sur le disque.
Je suis un peu étonné que tout le monde considère l’erreur comme irrattrapable…
As-tu essayé ça :
https://www.r-studio.com/free-linux-recovery/
https://www.cyberciti.biz/tips/linux-ext3-ext4-deleted-files-recovery-howto.html
https://unix.stackexchange.com/questions/80270/unix-linux-undelete-recover-deleted-files
https://itsfoss.com/recover-deleted-files-linux/
https://www.tecmint.com/recover-deleted-file-in-linux/
https://www.rootusers.com/restore-deleted-file-linux/
etc.
?
[^] # Re: Blame the victim
Posté par freem . Évalué à 2.
Ce n'est pas tout à fait vrai, ou du moins ça ne l'était pas du temps de windows XP sur une partition en FAT (le format). Dans ce cas précis, Windows ne mettait que la 1ère lettre du nom du fichier dans la FAT (la zone disque) à 0xFF (
ÿde mémoire), ce qui rend l'annulation de suppression très rapide pour celui qui sait.Quand j'utilisais ce système, j'utilisais mécaniquement Shift+Del pour virer mes fichiers, parce que je n'aimais pas l'idée de corbeille (maintenant que je travaille et que mes fichiers sont autrement plus importants, mon opinion sur le sujet à changé, mais je ne sais pas comment avoir de corbeille en ligne de commande… damned! (enfin, certains ont mentionné trash, je vais voir ça et l'aliaser sur
delje pense)), et j'ai ainsi pu sauver mes fesses à plus d'une reprise :D[^] # Re: Blame the victim
Posté par barmic . Évalué à 1.
L'appel système permettant de supprimer un fichier sur un système POSIX s'appelle
unlink(2). Il supprime un lien vers le fichier. C'est quand il n'existe plus de lien vers ce fichier et qu'il n'existe plus de descripteur de fichier vers ce fichier, que l'espace peut être considéré comme libre.C'est ce que fait photorec cité plus haut. Il fonctionne aussi sur windows.
[^] # Re: Blame the victim
Posté par Albert_ . Évalué à 4.
Dans tous les metiers ce genre de chose arrive. La ce n'est "que" des donnees. Je connais des personnes qui ont voulu aller vite car il etait tard ou je sais pas quoi et qui ont "oublie" les notions de securites les plus elementaires avec une scie circulaire… Le resultat etait pas beau a voir et nettement pire qu'une perte de donnee.
Ca arrive, cela s'appelle un accident et personne n'est a l'abri de ce genre de truc.
[^] # Re: Blame the victim
Posté par Marco . Évalué à 5. Dernière modification le 03 mai 2018 à 14:06.
Dans la formation sécurité que j'ai reçu, le mec nous expliquait que pour un accident, il y avait énormément d'anomalies/comportement à risque (du genre 1000 pour 1 accident) l'anomalie pouvant être bénigne (un câble qui traine).
Et que quand un accident arrive faut pas se dire "oh on n'a pas eu de chance" mais plutôt se dire "où sont les autres anomalies". En gros se dire : bon y a eu tel événement irréversible (genre un mec à l'hosto ou pire), quelles sont les causes et qu'est ce qu'on fait pour réduire les risques d'accidents futurs.
On constate en suivant ce fil que totof a déjà eu ce que ma boîte appelle un "presque accident" (c'est à dire qu'une anomalie a failli généré un accident) en gros y a 10 presqu'accident pour 1 accident.
Au moins totof nous a signalé l'accident pour pas que ca arrive à l'un d'entre nous
La question c'est aussi de se demander, depuis combien de temps ont ils voulu aller vite (le font-ils tous les jours ?), combien de fois se sont ils fait peur (presque accident) tard le soir ? Pourquoi ont ils voulu aller si vite (pression de la hiérarchie pour terminer une commande par ex)
Quelles ont été les plans d'actions à la suite de l'accident ou du signalement des presqu'accident si signalement il y a eu (formation/formation recyclage/ ne jamais être seul quand on manipule etc.)
Y en a beaucoup à mon taf qui disent "ouais les formations sécurités ça sert à rien". Qui quand un truc ne vas pas se contente de corriger le problème sans se poser la question de comment est il arrivé, ne le signale à personne.
Quand on analyse l’accident de totof on a :
Pour réduire les risques :
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 2.
D'ou sors-tu " y a des accidents précédents puisqu'il a déjà perdu des données" ?
[^] # Re: Blame the victim
Posté par Marco . Évalué à 2.
Mais c'est vrai que tu n'as pas précisé quelle était l'erreur, ca n'avait peut être rien à voir avec de la perte de données ou peut être que tu as pu les récupérer.
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 2.
Les erreurs que j'ai faites ont été récupérables d'une façon ou d'une autre. Seul le temps a été perdu.
[^] # Re: Blame the victim
Posté par totof2000 . Évalué à 3. Dernière modification le 03 mai 2018 à 15:12.
Je remplacerais 'Ne plus nommer ses dossiers "~"' par 'modifier l'acces au repo pour qu'un git clone ~ ne soit plus possible" (le nommage en ~ n'est pas volontaire, ce n'est qu'une tentative de debug).
[^] # Re: Blame the victim
Posté par Albert_ . Évalué à 0. Dernière modification le 03 mai 2018 à 15:49.
Perso je ne connais pas un seul endroit ou un accident ne soit pas arrive un jour ou l'autre. c'est extremement facile de donner des lecons apres les faits mais bon ca ne sert a rien les "tu aurais du…", je te garantie qu'il/elle le sait et se flagelle tout seul(e)!
[^] # Re: Blame the victim
Posté par Marco . Évalué à 3. Dernière modification le 03 mai 2018 à 16:20.
Pour le coup je n'aime pas non plus les "tu aurais dû", je préfère dire "pour éviter que cela se reproduise". Il est vrai que je n'ai pas insisté là-dessus dans mon commentaire. Parce que dire juste "oh merde c'est pas de chance, ça arrive" c'est pas plus utile.
D'ailleurs y a des choses que je ne faisais pas encore et que j'ai bien l'intention de faire pour éviter que ça m'arrive (typiquement utiliser un mv vers ma corbeille plutôt qu'un rm par exemple) et je sais parfaitement que si j'avais eu un dossier ~ je me serais fait avoir aussi.
[^] # Re: Blame the victim
Posté par Sufflope (site web personnel) . Évalué à 4.
Le mec écrit 5 paragraphes pour expliquer que la démarche saine maintenant c'est l'introspection pour comprendre les racines du problème et que c'est totof2000 qui peut le faire, et ça se finit en "si c'est pour dire haha bien fait fallait faire ci et ça, tais-toi". Impressionnant.
[^] # Re: Blame the victim
Posté par fearan . Évalué à 2.
utiliser rmdir à la place de rm -rf pour un dossier vide ;P
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Blame the victim
Posté par freem . Évalué à 4.
Un dépôt git vide n'est pas un dossier vide.
[^] # Re: Blame the victim
Posté par Christophe B. (site web personnel) . Évalué à 3.
Et le Titanic était insubmersible
Et les vagues à Fukushima ne faisait JAMAIS plus de 10 metres de haut …
Et … (je vous laisse complèter la liste)
Et bientôt … l'intelligence artificielle crée par l'homme pour justement éviter ce genre de choses …
Et qui inévitablement en arrivera à la conclusion que pour supprimer la source de toutes les conneries :
il faut supprimer l'espèce humaine … sauf Edward Murphy peut être mais il est déjà mort …
# Les données du /home sont souvent les moins protégées
Posté par Liorel . Évalué à 10.
C'est même souvent le contraire. Le système de droits Unix est remarquablement efficace pour protéger le système, mais avec les distribs modernes, ce qui est précieux, ce sont les données utilisateur, car elles sont encore souvent non sauvegardées, et que la distrib se réinstalle en 20 minutes (plus si t'es sous Gentoo, mais c'est l'idée).
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par aiolos . Évalué à 10.
Et le XKCD de circonstance : https://xkcd.com/1200/ :)
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Faya . Évalué à 3.
https://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par ff9097 . Évalué à 1.
C'est parce que nos distributions Linux sont en premier lieu des OS serveurs où le plus important est le système
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par freem . Évalué à 3.
Dans ce cas, je préfère un
rf -rf /binquerm -rf /etcourm -rf /var:)Et le pire d'entre tous:
rm -rf /, qui peut se produire à cause d'une bête erreur de variable pas initialisée dans un script qui doit obligatoirement être exécuté en tant que root. Celui qui détruit autant les données utilisateur, la config système, et les données systèmes.[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Moi il m'en faut 5 à 10 de plus, le temps que mes scripts Ansible terminent d'installer les paquets nécessaires et de configurer le reste ;-) (Bien sûr, n'est pas compris là dedans le temps de reinstallation du $HOME qui serait nécessaire si ma partition home avait été flinguée).
Pas plus tard qu'hier, j'ai réinstallé mon laptop pro pour passer à kubuntu 18.04 : en 30 min j'étais opérationnel.
D'ailleurs, depuis que j'ai mes scripts Ansible, je ne m'embête plus à faire des upgrades de distro, ça prend moins de temps de tout reinstaller que de faire l'upgrade. Et ça permet de faire le ménage (genre les paquets que j'installe "pour voir" et que j'oublie de virer).
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Liorel . Évalué à 3.
En ce qui me concerne, depuis que je suis sous Archlinux… Ah mince, je vais passer pour pédant :P
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Albert_ . Évalué à 3. Dernière modification le 04 mai 2018 à 09:23.
Pfff bande de petit joueurs qui vous voulez mettre les cafettieres au chomage!
Heureusement que la majorite des ordis sont encore sous windows, le systeme auto-destructeur qui prend pas moins de 4 ou 5 heures a etre installe et cela avec une grosse connection :).
Ca ce sont des gens responsables, ils evitent le burn-out!
PS: je rigole en fait c'est la version Dell qui est pourri et les techniciens qui viennent la reinstaller tout les 6 mois :D
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par freem . Évalué à 2. Dernière modification le 04 mai 2018 à 11:50.
À ton avis, c'est pour quoi, systemd et pulseaudio? (allez, ça faisait longtemps ;))
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Albert_ . Évalué à 2.
Puisque nous sommes vendredi:
systemd je dois avouer que cela marche par contre je sais pas ce que cela fait. J'ai ecris des script pour mes besoins que je mettais dans /etc/init.d maintenant ben tant pis si ca marche pas comme je veux je contourne le probleme comme sous windows quoi…
Pulseaudio? Je ne sais pas je me sers du systeme fourni par le kernel (comme pulseaudio d'ailleurs) et j'entend du bruit…
D'autre question? Et si on revenait a mon troll prefere: c'est pas beau les updates windows? On dirait des updates de logiciels libres fait par des amateurs…
Ca faisait longtemps que j'avais pas eu un peu de temps pour troller comme un goret un vendredi :)
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par barmic . Évalué à 3.
Je marche dedans, mais c'est complètement documenté et trivial à faire. Si tu ne veux pas apprendre on ne peut pas le faire pour toi (« nul n'est plus aveugle que celui qui refuse de voir »). Même ici sur linuxfr tu trouvera tout ce qu'il faut comme ressources pour faire fonctionner ton script avec systemd.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Albert_ . Évalué à 3.
Vu que FreeBSD a maintenant KDE5 je pense plutot migrer vers ce systeme!
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par freem . Évalué à 3.
C'est extrême, si tu veux rester avec le noyau linux, tu peux aussi utiliser void. Mais bon, c'est aussi un bon prétexte pour changer de kernel et voir du neuf.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
J’en profite qu’on soit trolldi, mais le mainteneur a bien prévenu tout le monde qu’en fait KDE5 n’existait pas, mais qu’on allait l’appeler comme ça tout de même parce que c’est plus facile, et qu’au final tout le monde parle de KDE5…
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par freem . Évalué à 2.
Dans ce cas je veux bien un lien qui explique comment changer proprement le tty utilisé par défaut sur un OS. J'insiste sur le proprement, un truc qui risque pas de péter à la moindre MàJ (c'est pratique de virer des mots pour détourner le sens d'une phrase :p).
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par barmic . Évalué à 1.
Ça n'a pas de rapport avec ton script que tu « colle dans
/etc/init.d».J'ai pris la totalité de ton paragraphe.
Les comportements de « je veux pas savoir comment ça fonctionne soit ça marche, soit je bave sur le logiciel » est relativement nouveau sous linux. Je présume que ça vient de sa popularité, les utilisateurs de niveau plus faibles qui préfèrent se comporter en consommateurs plus qu'en utilisateurs avertis :p (à troll, troll et demi)
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par freem . Évalué à 2.
Ce n'est pas moi qui ait écrit le script à migrer :)
Je faisais référence à moi :)
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par totof2000 . Évalué à 4.
Bah, ce que je reproche à systemd, c'est qu'on ne peut pas savoir comment ça fonctionne sans se palucher une palanquée de documents pas forcément en phase avec la version utilisée, avec plein de cas divers et variés selon que tu configures l'un ou l'autre truc, ou alors tu dois aller te taper un code source en C imbitable (et tu dois t'assurer que le code en question correspond bien à la version que tu utilises).
Avec les systemes d'init classique, c'était tout simple : tu places tes scripts dans /etc/rcx.d et tu t'arranges pour qu'ils traitent les paramètres start, stop, reload, etc … Et si tu veux savoir comment ça marche, tu lis le code. Et sur ur xBSD c'est encore plus simple. Avec systemd, si tu as un problème de démarrage, t'es obligé d'attendre que ta distrib (ou l'upstream) corrige avant de pouvoir démarrer. Avec les scripts init classiques, tu peux corriger de suite et démarrer ton serveur en attendant que les correctifs te soient fournis.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par barmic . Évalué à 3.
Hé hé !
Bien sûr… Tu as regardé comment le skeleton de Debian par exemple ? Tu espère que le script prennent correctement en compte les paramètres, mais en faite euh… Ben pas forcément… Tu as vu combien de scripts qui ne sont trop dépendant de l'environnement ? (lancé par le mauvais utilisateur, variable d'environnement en trop,…)
Je pense bien connaître le scripting shell et il est vraiment rare que je ne vois un script sans me dire "là on peut le faire péter". Pour faire un bon script shell il faut être très défensif. Donc le shell c'est bien, mais c'est bien de limiter fortement le contexte dans le quel on l'utilise.
Bref je connais suffisamment le shell pour vouloir simplifier au maximum ce qu'on en fait et toujours me méfier des scripts shell.
C'est insupportable à lire, les distributions font différemment (ma distribution utilise un binaire compilé qui s'appelle "start-stop-daemon".
Non c'est encore différent pas simple. Simple quand tout se passe bien. Valider que tout est fiable est encore une complexité en plus.
Tu es entrain de nous présenter le scénario de la bombe à retardement version système d'init. Les faits montrent que ça ne semble pas si invivable (Note : quand tu fais quelque chose qui pète ton init quelque soit ton système d'init tu pourra le corriger => je n'ai pas de doute que tu sache faire l'action inverse de ce que tu as fais).
# Petite astuce
Posté par gnumdk (site web personnel) . Évalué à 4.
Chez moi, ça donne ça:
ou:
En gros, ça me demande confirmation si je vire un répertoire et/ou si je supprime plus d'un fichier, ça évite aussi les fautes de frappe avec cette touche * si proche de la touche entrée…
Dans mon .bashrc:
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Petite astuce
Posté par Albert_ . Évalué à 2.
Mauvais clavier changer clavier… ---> []
Le clavier français est assez horrible et je viens de decouvrir une nouvelle raison :)
# Ce moment où tu réalises que tu viens de faire une boulette…
Posté par gouttegd . Évalué à 4.
Il m’est arrivé un truc similaire une fois, même si je ne me souviens plus de la commande exacte (je crois que c’était quelque chose du genre
rm -rf ../*, alors que j’étais dans un dossier juste sous mon home).Je me souviens très bien de ce petit moment de flottement où je me dis « tiens c’est bizarre, pourquoi ça prend aussi long—OH PURÉE CTRL-C CTRL-C CTRL-C!!! »
Mais j’avais des sauvegardes, dont je n’ai quasiment rien perdu si ce n’est le temps de les restaurer. D’ailleurs en réalité ce n’était pas une mauvaise manip de ma part, en fait c’était délibéré, je voulais tester mes sauvegardes, si si.
(Bon j’ai quand même perdu quelques petits trucs, parce qu’à l’époque j’étais encore sélectif sur ce que je sauvegardais ou pas — vestige d’un temps où l’espace disque était compté… Depuis j’ai inversé la logique : par défaut tout mon home est sauvegardé, sauf ce que je décide explicitement d’exclure.)
[^] # Re: Ce moment où tu réalises que tu viens de faire une boulette…
Posté par totof2000 . Évalué à 4.
Avec un SSD, c'est TRES rapide. Pas le temps de se poser la question et de faire le ctrl+c. Seul le message indiquant que je n'avais pas les droits pour supprimer certains fichiers (que j'avais compilé via sudo) m'ont mis la puce à l'oreille, mais il était déjà trop tard.
# Gag
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
Autre gag qui peut arriver : le remplacement de . par ;
Ça va donner un truc du genre :
$ rm *;txttxt: not found[^] # Re: Gag
Posté par Liorel . Évalué à 8.
J'en suis protégé par mon clavier bépo, et à te lire j'en suis bien content, c'est le genre de trucs qui aurait pu m'arriver…
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Gag
Posté par Seb . Évalué à 1.
oui, j'avais fait un
rm test *
rm test*
[^] # Re: Gag
Posté par Tony Flow . Évalué à 4.
Ah tiens ça me rappelle une fois où je voulais simplement renommer un fichier… Mais manque de bol dans l'instant j'ai pensé "rm" ça sonne comme "rename" :
Hein !? mais c'est quoi cette rép… oh merde…
Car aucune erreur sur le premier nom de fichier : celui-ci a bien été trouvé et supprimé avec succès :')
[^] # Re: Gag
Posté par freem . Évalué à 2.
Il faut avouer que sur ce point, les outils du shell sont douteux. On se demande après pourquoi les scripts se remplissent de programmation défensive…
[^] # Re: Gag
Posté par fearan . Évalué à 3.
Une des raisons pour lesquelles je peste contre les distribs qui ne mettent pas rm -i en alias de base à rm. ça n'évite pas toujours les conneries mais ça aide pas mal.
Pour cette même raison j'ai tendance à faire un rm d'un ficher nouvellement crée pour vérifier la présence de la question lorsque je sur en distant où une machine que je ne connais pas (oui un alias rm fonctionne aussi, mais un mauvais réflexe est dur à perdre ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Gag
Posté par jyes . Évalué à 7.
Hérésie !
rm avec l’option '-i' par défaut n’incite qu’à acquérir le réflexe d’ajouter '-f' automatiquement, et avec lui court-circuiter toutes les vérifications de droits d’accès (tant pis pour git qui essaie de protéger de ce genre de bêtises en créant des fichiers en lecture seule, tant pis pour les sauvegardes qu’on avait pensé à protéger aussi, etc).
Autant un wrapper du style
snapper -c home_$USER create --command rm $1je n’aurais rien contre (ce pourrait être une bonne solution), autant tout alias qui modifie le comportement par défaut de 'rm' me semble ajouter du risque plutôt que le limiter, en favorisant les mauvaises habitudes.[^] # Re: Gag
Posté par fearan . Évalué à 2.
pour toi peut être, chez moi non. si je veux court-circuiter le -i je fait \rm, et la mécanique de devoir préciser -f ou \ incite fortement à relire deux fois la commande, quitte à faire [ctrl]-[c] [flèche haut] [ctrl]-[a] [\] [return]
Je recommande d'ailleurs le \ cela évite justement ton cas de figure.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Ça arrive même aux meilleurs.
Posté par Meku (site web personnel) . Évalué à 8.
Ça me rappelle une anecdote tiens. Une histoire un peu similaire : un collègue qui a rincé sa clef USB par erreur sous mes yeux, en voulant faire le malin.
Sa clef était bien pleine et il voulait faire de la place en vidant la corbeille (.Trash) qui était stockée sur la clef. Il commence à sortir un terminal et tout, et je lui dis alors de ne pas se faire chier, au moment de démonter la clef sous Gnome, une fênetre va poper et lui demander s'il veut vider la corbeille automatiquement. Mais non, il voulait me montrer qu'il maîtrisait Linux.
Donc il a promptement ouvert un terminal à la racine de sa clef, puis « rm -rf * [ENTRER] ».
« VOILÀ. »
Il y a eu un silence pendant 3 secondes puis j'ai éclaté de rire :D
[^] # Re: Ça arrive même aux meilleurs.
Posté par freem . Évalué à 3. Dernière modification le 03 mai 2018 à 12:24.
Il voulait de la place, il en a eu :D
Mais bon, ça va, c'est juste une clé usb, il suffit de ne rien écrire et de récupérer les données, surtout que c'est trivial si elle est en FAT (format pas mal utilisé pour les échanges, encore).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.