wismerhill a écrit 2598 commentaires

Et surtout, json ne prévoit pas les commentaires!
C'est un format simple et pratique pour échanger des données structurées (mais pas trop quand même) entre programmes hétéroclites, mais c'est une aberration d'utiliser ça pour un fichier de configuration. (composer, c'est à toi que je pense)

Certes, mais il utilise explicitement bash, il n'y a donc pas de raison de s'interdire l'utilisation de [[, qui a l'avantage d'être une construction du langage (voir la documentation de bash), ce qui évite notamment de lancer une commande à chaque fois.
Le seul problème était effectivement l'oubli de l'espace après [[

Je suppose que tu parle de classic theme restorer.

Son auteur a fait ça pour firefox 57+:
https://github.com/Aris-t2/CustomCSSforFx

Ça ne fait pas tout ce que permettait CTR, mais déjà pas mal de personnalisations intéressantes.

Là, tu supprime le caractère # où qu'il se trouve dans la ligne.
Si tu veux le supprimer uniquement s'il est au début de la ligne, c'est plutôt ça qu'il faut faire:

s/^#//

D'abord, si la variable $look contient des caractères particulier (ne serait-ce qu'un espace!), ça ne va pas donner ce que tu espèce.
Il faut la protéger avec des guillemets doubles:

sed 's/'"$look"'/^#/' test.conf

Mais puisque le reste de la commande sed ne contient pas de $, on peut faire plus simple:

sed "s/$look/^#/" test.conf

Ensuite, cette commande sed ne fait pas ce que tu crois, elle va remplacer la valeur contenue dans $look par la série de caractères "^#".

Mais en fait, toute la ligne qui affecte une valeur à look ne sert à rien (et contient un UUOC).
Tu peux simplement faire

sed "/$domain/ s/^/#/" test.conf

Cette version utilise une adresse, sous forme d'expression rationnelle, pour déterminer à quelles lignes appliquer la commande s, cette dernière se contente de faire un match sur le début de la ligne, et le remplacer par un #.
Et au moins, cette version fonctionnera correctement si plus d'une ligne dans le fichier contient de domaine recharché.

Note que si $domain contient des caractères spéciaux pour sed, ça ne fonctionnera pas.
Au minimum, puisqu'il doit s'agir de noms de domaine, il faudrait échapper les points, tu peux utiliser la syntaxe du shell pour ça avec l'expansion du type ${PARAMETER/PATTERN/STRING}, ça donne

sed "/${domain//./\\.}/ s/^/#/" test.conf

Je n'ai pas testé, mais cette version à plus de chance de fonctionner.

C'est vrai qu'il peut y avoir plantage de l'environnement pendant la mise à jour, c'est pour ça qu'il est recommandé de désactiver le verrouillage automatique (ou alors faire la mise à jour depuis un autre bureau que plasma). Et dans ce cas on perdra d'éventuelles données sur lesquelles on était en train de travailler.

Mais à part ça, quelles données as-tu perdu?

Non, si tu as supprimé tous les fichiers, tous l'espace est disponible et le système n'a aucune raison de fragmenter, il écrira séquentiellement dans l'espace qui est disponible.

dd if=/dev/mmcblk0p2 of=/dev/sda1 bs=32M conv=noerror,sync

Déjà, tu dis à dd de continuer même s'il y a des erreurs, as-tu des raisons de supposer que ta partition d'origine n'est pas entièrement lisible?

Ensuite, est-ce que sda1 a bien une taille supérieure ou égale à mmcblk0p2 (à l'octet près!)?

Et surtout, est que mmcblk0p2 est bien démonté avant d'entreprendre l'opération?
Sinon, c'est normal d'avoir un système de fichier corrompu (et potentiellement irrécupérable) après copie.

Il y a des versions LTS d'openjdk?

Sauf que avec |&, | redirige non stdout mais stderr, et non vers le programme à sa droite, mais vers & qui désigne cette fois non la mise en arrière plan mais /dev/stdout.

Non, il redirige les deux.
D'après la page de manuel de bash (version 4.3):

If |& is used, command's standard error, in addition to its standard output, is connected to command2's standard input through the pipe; it is shorthand for 2>&1 |. This implicit redirection of the standard error to the standard output is performed after any redirections specified by the command.

C'est donc bien l'équivalent de l'exemple donné dans le message d'origine.

C'est du coup plus long à écrire.
D'autant qu'avec bash (et probablement d'autres), on a une version encore plus courte:

./a.out |& grep toto

De mon expérience, s'il y a beaucoup de petits fichiers, rsync est plus rapide que scp dès la copie initiale.

Pour ansible (je ne connais pas les autre, mais c'est probablement le même principe) tu modifie le playbook et tu le ré-applique à tous tes serveurs.

Je ne suis pas celui à qui tu répondais.

Si seulement il marchait dans la bonne direction …

C'est le boulot de chaque programme d'être capable de charger la configuration écrite par une de ses anciennes versions, ou de les ignorer si les changements sont trop importants (certains programmes mettent leur version majeure (voir majeur+mineur) dans le nom du répertoire pour que ce soit automatique).
Si ce n'est pas le cas et que le programme ne fonctionne pas à cause de ça, c'est un bug à rapporter aux développeurs upstream.

Je ne sais pas pour vous, mais moi j'aime plutôt bien que les programmes conservent les configurations que j'y avais faites. (le passage de KDE 4 à plasma 5 a été douloureux)

KWin est probablement trop intégré à plasma pour l'utiliser indépendamment, tu va probablement avoir plein de services KDE lancés en arrière-plan (je suppose que si tu es passé à XFCE, c'est pour éviter ça).

Tu copie (cp -a, pour préserver les méta-données) avec un nom temporaire le fichier que tu veux re-dupliquer, puis tu fais un mv -f du nom temporaire vers le nom d'origine pour "défaire" le lien physique.
Combine ça avec find pour trouver tous les fichiers ayant plus d'un lien physique (et d'autres critères à ta convenance).

Si tu sais que le mot de passe a été constitue de 5 mots parmi 4096 mots, ca ne fait que 5*4096 tirages avant de le retrouver, soit 24530 (~ 16 bits d'entropie) tirages possible.

Non, ça fait 4096^5, ce qui donne bien 60 bits.

Ton calcul ne serait correct que si on pouvait tester chaque mot individuellement, mais ce n'est pas le cas, ils sont concaténés pour former un mot de passe qui ne peut être testé que dans son intégralité, pas par morceaux.

Protection de la mémoire

Un fichier d'une taille pareille, est-ce que ce ne serait pas une image complète de la partition (voir du disque complet)?
Si tu demande simplement à file de te dire ce qu'est ce fichier, est-ce qu'il te donne une information pertinente?

Si c'est une image de la partition (avec donc le système de fichiers dedans), tu peux essayer de la monter en loopback (en lecture seule!!) pour voir si tu accède aux fichiers.
S'il y a bien un FS dedans mais qu'il ne peut pas être monté parce qu'il est corrompu, fais-en une copie (pour garder un original non modifié) puis fais un fsck dessus, en espérant qu'il arrive à le remettre suffisamment en état pour récupérer les données importantes.

Non, systemctl enable et disable ne font que (dés)activer une unité selon ce qui est défini dans sa section [install], les dépendances entre unités sont lues dans les fichiers des unités et les répertoires *.wants ne sont qu'une façon d'y contribuer (et la dépendance Wants n'est qu'une version plus faible de Requires, Wants existe principalement pour configurer ce qui doit être lancé au démarrage).
cf la page de manuel de systemd.unit

Edit: et pour être complet, il y a aussi des répertoires *.requires qui correspondent à la dépendance Requires.

Je vais laisser quelqu'un qui sait ce qu'est influxd répondre à cette question …

(astuce: si tu utilise systemctl cat influxd.service il t'affichera non seulement le fichier de base, où qu'il se trouve, mais aussi d'éventuels fragments supplémentaires qu'il aurait inclus en plus)

Le type de service n'est pas précisé (et il n'y a pas de BusName), donc il est implicitement de type simple. Ça veut dire que dès que le programme indiqué par ExecStart est lancé le service est considér(é comme démarré. Mais je suppose que ton service influxd met un certain tempos à être fonctionnel.
La documentation de systemd recommande dans ce cas de mettre en place le socket à l'avance via systemd (qui lui bloquera en attendant que le service répond correctement), mais ça suppose d'être supporté par ton service (ce qui n'est probablement pas le cas), ou d'utiliser un proxy (plus tordu et peut-être moins bon pour les performances).

Sinon, dans ton propre service, tu peux ajouter un ExecStartPre qui va exécuter un script qui va attendre que le service soit correctement démarré (le programme défini en ExecStart n'est lancé que quand tous les ExecStartPre se sont terminé séquentiellement).
Un tel script pourrait également être mis en ExecStartPost d'influxd.service (via un fragment dans le répertoire influxd.service.d, pour ne pas modifier le fichier principal) si tu veux que ça profite à d'autres services. (c'est à vérifier, mais il me semble qu'un service n'est considéré comme démarré que quand les ExecStartPost se sont terminés)

Si tu ne sais pas comment déterminer ton ton script si influxd est bien fonctionnel, tu as toujours la solution barbare de faire un sleep de quelques secondes (pas besoin de script dans ce cas) en espérant que ce sera toujours suffisant, mais l'ennui dans ce cas est que tu fera toujours une pause au démarrage de ton service, même si influxd est démarré depuis longtemps.
Une solution intermédiaire serait de faire un script qui va utiliser systemctl (avec la commande show) pour savoir depuis combien de temps le service influxd est démarré, et faire une pause si ce n'est pas au moins quelques secondes.

Ben si, les SSD c'est (presque toujours) de la flash: Solid-state_drive
mais c'est fortement parallélisé pour améliorer les performances.

À ma connaissance, les seuls SSD basés sur une technologie différente sont les optane d'intel basés sur 3D XPoint.