wismerhill a écrit 2608 commentaires

Le wikipedia français va dans ton sens, par contre la version anglaise est moins catégorique:
https://en.wikipedia.org/wiki/Trim_(computing)#Operation
Le dernier paragraphe indique que les données ne sont pas forcément physiquement effacées des cellules flash, et donc potentiellement récupérables avec du matériel adapté.

Vu que les SSD fonctionnent par blocs nettement plus gros que les 4kiO habituels des FS, ce serait contre-productif d'essayer d'effacer un bloc logique dès qu'on le trim, il vaut mieux au contraire retenir les blocs "trimmés", et attendre d'avoir un bloc physique complet pour pouvoir l'effacer d'un coup.

De la même façon, les SSD utilisent le trim, qui effacent carrément les données des cellules.

Non, ou en tout cas pas obligatoirement.
Le trim (appelé discard sous linux) permet au système de dire au SSD que certains secteurs ne sont plus utilisé (il n'y a plus de donnée utile dedans) et que le SSD peut donc les ré-utiliser la prochaine fois qu'il fera une écriture (en général les SSD ne ré-écrivent pas au même endroit, pour répartir l'usure sur toutes les cellules, ce qui est un peu gênant pour l'effacement sécurisé façon shred).
S'il n'y a pas eu de ré-écriture, les données effacées sont probablement encore dans les cellules, mais avec le wear leveling compliqué qui est mis en place ça doit être très compliqué de retrouver ses jeunes.

Mais de toute façon, le sujet d'origine est un SSD qui a cessé de fonctionné, ce sont donc les données qui y étaient encore stockées, celles sur lesquelles on n'a pas fait de trim, qu'il voudrait récupérer.

Si par « var_a m'est passée par un appel à mon playbook » tu veux dire que la variable est passée par la ligne de commande ansible-playbook (extra vars), alors tu ne peux rien faire, celles-là ont la priorité maximum.
Si tu veux dire qu'elle est définie directement dans le playbook (play vars), elles ont également une priorité supérieure aux variables venant de l'inventaire.
Voir la documentation d'ansible pour l'ordre de précédence des variables
http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Ah, j'avais compris à l'envers, je croyais que tu ne pouvais pas modifier les variables des hosts et était obligé de les re-définir dans le playbook.
Alors je ne vois pas bien le problème, met directement la bonne valeur puisque tu controlle la définition 'origine des variables.

Sans avoir vérifié dans le code d'ansible, je suppose que c'est un effet de bord de la façon dont sont implémentés les facts d'ansible.
Il ne faut probablement pas voir ça comme une affectation de variable, qui ferait appel à son ancienne valeur, mais à une re-définition de la valeur, l'ancienne valeur n'étant plus disponible tu te retrouve avec une définition récursive qu'il ne peut pas résoudre.

Mais tu ne dis pas à quel endroit tu essaie de re-définir cette variable.
Est-ce dans une action set_facts?
Ou peut-être dans une section vars d'une action, ou d'un block?

Au passage, si ta variable booleen est déjà un … booléen, tu peux résumé ton test à "not booleen" (avec quand même de filtre default si la variable n'est pas définie pour tous les hosts), et en inversant le if on évite la négation.

Au pire, si tu as vraiment besoin de re-définir la variable var_a, ça peut probablement se faire en deux temps:

- set_fact:
    var_a_bis: "{{var_a if booleen|default(true) else var_b}}"
- set_fact:
    var_a: "{{var_a_bis}}"

Je n'ai pas testé, mais comme les actions s'exécutent séquentiellement, ça devrait le faire.

• on n'a aucune idée de ce que fait le bash en question (un .deb est plus facile à évaluer),

Heu, un deb ou un rpm ont aussi des script des pré et post (dés)installation, et ce n'est même pas évident à priori, il faut aller chercher dans les méta-données du paquet pour voir s'il y en a et ce qu'ils fonts.

Par contre, tu as beaucoup de temps pour troller sur linuxfr, vu le nombre de tes réponses (plus de 25% au moment où j'écris).

le fait que les consoles textes ne soit plus préchargées depuis systemd n’améliore pas.

C'est effectivement la configuration par défaut, mais rien ne t'interdit d'en avoir une pré-chargée.
C'est justement à ça que sert le service "instanciable" getty@, si tu veux avoir toujours un getty démarré sur la console virtuelle 2, il suffit de faire (de mémoire)

systemctl enable getty@tty2.service

Tu préfère perdre ton travail sans avertissement plutôt que de devoir attendre un peu pour l'enregistrer proprement?

Tu n'aurais peut-être pas eu de problème si tu avais utilisé une vrai distribution en rolling-release (quoique ce terme ne soit pas clairement défini).
Car debian sid n'est PAS une rolling-release (pour toute définition raisonnablement pertinente qui me vienne à l'esprit). C'est la version de développement de la prochaine debian stable. C'est pour ça que c'est acceptable que des choses soient cassées pendant un temps (éventuellement assez long), parce que le but n'est pas de trouver une solution pour que ça marche rapidement, mais de trouver une bonne solution pour que ça fonctionne bien (et soit maintenable) quand ça deviendra la prochaine stable.
Et quand il est temps de sortir une nouvelle stable, sid est gelé jusqu'à ce que tous les problèmes bloquants soient résolus.

Note que les développeurs debian font quand plus attentions depuis quelques années à ne pas casser sid pour rien (et à ce que les corrections de sécurité arrivent relativement vite), justement à cause de toutes les personnes qui, comme toi, l'utilisent en production.

À moins que je n'ai pas compris ce que tu cherche à faire, il me semble que c'est exactement à ça que sert la commande paste.

Il y a aussi l'outil gpart qui sert exclusivement à ça.
Il est aussi sur system rescue CD, c'est là que je l'avais découvert … le jour où moi aussi j'en ai eu besoin.

Mais s'il veut quelque chose qui est à la pointe de ce qui se fait maintenant, c'est vers du M.2 qu'il faut aller, car en SATA les SSD actuels (à part le bas de gamme) sont bridés par l'interface SATA elle-même (un peu comme les disques dur externes en USB2).

Puisque tu invoque la flemme, je suis obligé de faire remarquer que la commande source peut être remplacée par un point.

C'est bizarre, moi ça fait longtemps que je n'ai plus trouvé une vidéo (.rm, .mov ou autre) qui ne soit pas lisible par mplayer (à part évidemment si c'est dans un format trop récent), tu as un exemple?

D'où vient ce RealPlayer11GOLD-1.deb ?
Vu que ça faisait longtemps que je n'avais plus vu de référence à realplayer, je suppose que tu as retrouvé un vieux paquet compilé pour une ancienne version de debian/ubuntu et dont les dépendances ne sont plus disponibles dans une distribution un peu récente.

As-tu vraiment besoin de ce realplayer?
As-tu des fichiers vidéos qui ne sont lisibles que par ce dernier et pas par les différentes lecteurs vidéos (beaucoup plus puissants) inclus dans la distribution et déjà cités plus haut?

J'ai une Mint (j'ai pas choisi), sur un portable Toshiba (que j'ai pas choisi non plus).

Alors tu devrais demander des comptes à la personne qui a choisi pour toi.

Avec TOML, tu peux indenter si tu souhaites pour clarifier (comme dans les langages de programmation)

À part python, qui est justement le language dans lequel est écrit ansible ;-)

Et puis, d'après https://github.com/toml-lang/toml TOML est encore noté en version 0.4.0, donc la syntaxe peut encore changer de façon incompatible.

L'exemple que tu donne n'est pas un role, c'est un playbook normal que tu as mis dans le répertoire roles, mais n'importe où d'autre aurait fait l'affaire (puisque tu donne son chemin complet à ansible-playbook).

Les roles sont des répertoires (placés par défaut dans le répertoire roles que tu indique) avec une structure de sous-répertoires conventionnelle pour limiter les boilerplate. cf
http://docs.ansible.com/ansible/playbooks_roles.html

Voici comment restructurer ton exemple en un vrai role (je fais ça de tête, je n'ai pas testé):

Tu crée un répertoire /etc/ansible/roles/common (common sera donc le nom de ce role), dedans tu fais un répertoire tasks dans lequel tu met un fichier mail.yml avec le contenu

- name: install common packages for all servers
  apt: 
      update_cache=yes
      state=latest
      name={{item}}
  with_items: 
    - curl
    - htop
    - ncdu
    - pwgen
    - strace
    - sudo
    - tar
    - unzip
    - vim
    - wget
    - whois
    - screen

Ensuite, dans un fichier skhn.yml (que tu met où tu veux) tu met ceci:

- hosts: all
  remote_user: root
  roles: [ common ]

Avec un exemple aussi simple, l'intérêt d'un role est simité par rapport à l'instruction include, ça devient plus intéressant quand tu y ajoute des handlers, des templates, des fichiers, des variables, car ça permet de regrouper les choses logiquement.

[commentaire redondant supprimé]

Est-ce que si on est en raid 1 et qu'un disque tombe en panne, le raid et le système tourne toujours? Ensuite si on remet un disque alors la reconstruction est envisageable automatiquement !?

Bien sur, c'est exactement à ça que sert le RAID 1, pas d'interruption du service, les données étant identiques sur les deux disques on continue avec celui qui reste.

D'ailleurs les deux autres configuration que tu mentionne permettent également de perdre un disque sans interruption, voir deux dans le cas du RAID 10 s'ils ne sont pas dans la même grappe RAID 1.

Il y a aussi le RAID 6 qui offre deux disques de redondance (donc minimum 4 disques pour que ça serve à quelque chose).
Sinon, avec du RAID 1 (et donc aussi du 10) tu peux rajouter un troisième disque à postériori (quand tu as de nouveau du budget), donc les données seront dupliquées en triple («tripliquées»?) et tu ne sera pas dans l'urgence quand un des deux premiers lachera (ou le nouveau, si tu n'a pas de chance).

Concernant les controlleurs RAID, à moins que tu ne prenne un serveur professionnel avec un vrai controlleur RAID, avec batterie intégrée, pas les pseudo-RAID qu'on trouve dans les cartes-mère grand public, je te conseille plutôt d'utiliser le RAID logiciel de Linux.
Il a plus de possibilités que beaucoup de controlleurs matériels, il est utilisé par énormément de monde, donc très bien testé, et surtout, si autre chose dans ton serveur lache tu peux sans problèmes re-lire les disques avec n'importe quelle autre machine sous Linux (de préférence avec un noyau au moins aussi récent).

Si je comprends bien on dit à systemd d’exécuter le script quand le runlevel la cible 'multi-user' s’arrête.

Pas tout à fait, les unités ont toutes par défaut (il y a une option pour désactiver ce défaut) un conflit avec le target shutdown, c'est pour ça que son ExecStop sera exécuté à l'arrêt du système, mais seulement s'il a été démarré (le RemainAfterExit est là pour qu'il ne soit pas nécessaire de mettre un ExecStart qui fait une pause indéfinie).
Le WantedBy dans la section Install est seulement là pour qu'un "systemctl enable" ait poru effet que l'unité soit démarrée avec le target multi-user (donc dans tous démarrage normal).

Il faut noter que ce n'est pas tout à fait équivalent à lancer un script à l'arrêt, car tu peux arrêter l' e service avec "systemctl stop" et le script sera exécuté à ce moment-là, et plus à l'arrêt (si tu ne la redémarre pas).
Cela peut s'éviter avec l'option RefuseManualStop=true (dans la section Unit).

Est-ce qu'il est prévu de supporter CentOS (RHEL) 7?
Ça fait quand même plus de deux ans qu'elle est disponible et la 6 commence à se faire vieille.

Peut-être qu'après la mise à jour ton clavier n'est plus correctement configuré dans la session graphique?
Vérifier les caractère tapés dans le champ login, et le cas échéant, tape ton mot de passe comme en qwerty.

Si pour toi c'est l'ordre alphabétique, quel alphabet utilise-tu?