wismerhill a écrit 2602 commentaires

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?

Alors, dans le message auquel je répondais tu ne parlais pas de dépendances en cascades, tu parlais de script manquants.
Je t'ai indiqué le paquet qui contient ces scripts, que tu n'a vraisemblablement pas regardé, car moi j'y vois un fichier /etc/init.d/virtlogd (et quand je regarde les sources du paquet, ça ressemble bien à un script à la sauce sysV).

Je suis d'accord que c'est dommage que systemd se retrouve installé alors que tu utilise un autre système d'init, mais dans la mesure où il n'est pas démarré ça me semble un problème mineur.

Pourtant, si je regarde la liste des fichiers de https://packages.debian.org/sid/libvirt-daemon-system , je vois bien des fichiers dans /etc/init.d

Il y a aussi les crochets si tu veux n'accepter qu'un sous-ensemble des caractères possibles, en pouvant spécifier des intervalles.
Exemple:

$ rm fichier[1-79].txt

supprimera fichier1.txt, fichier5.txt mais pas fichier8.txt

Et les accolades qui permettent de générer du texte (alternatives ou séquences), indépendamment des fichiers.

$ echo "c'est le "{matin,soir}
c'est le matin c'est le soir
$ echo {1..15}
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
$ echo {000..200..40}
000 040 080 120 160 200

et on peut les imbriquer

echo "version "{1.{1..5},2.{4,5},3.7}
version 1.1 version 1.2 version 1.3 version 1.4 version 1.5 version 2.4 version 2.5 version 3.7

Ça ne fonctionnera pas si tu as des espaces (ou d'autres caractères amusants) dans tes fichiers ou leurs chemins.
Puisque la boucle for ne sert qu'à lancer ffmpeg, on peut faire presque la même chose avec le -exec de find (avec moins de possibilités pour le nouveau nom):

find . -name '*.*' -exec ffmpeg -i \{\} [options...] \{\}-new.mkv \;

Ou pour des choses plus complexes tu utilise l'option -print0 de find combiné par exemple à un "xargs -0 -L 1".

Et puis, le find est trop général, iol faudrait au moins exclure les fichiers *.mkv pour ne pas les recoder une deuxième fois si tu relance la commande, voir se limiter à une liste d'extensions connues.

Oui, sync c'est pour les systèmes de fichier.
Je ne pense pas qu'il y ait de cache quand on écrit directement sur un périphérique (si on accède directement à un périphérique physique, si c'est une couche d'abstraction du genre LVM c'est peut-être plus compliqué).
Je crois que les clés USB mettent simplement du temps avant d'éteindre leur LED, mais dans le doute, dd a des conversions (fdatasync et fsync) et des flags (dsync et sync) pour forcer à ce que les données soient écrites avant que le processus ne se termine (ce qui n'a probablement d'effet que quand on écrit dans un fichier normal).

Et vu la façon dont PHP transforme les types de données, le ==true est en trop.
Et vu que la valeur de logout est quant même convertie en booléen, on pourrait aussi bien utiliser

if(!empty($_REQUEST['logout']))