wismerhill a écrit 2608 commentaires

Juste une remarque, /usr n'est pas le bon endroit pour faire ce genre de modification. Les configurations locales doivent plutôt aller dans /etc (pour avoir une séparation claire entre ce qui est fourni par la distribution dans /usr, et la configuration locale dans /etc).
Donc en l'occurrence, tu devrais plutôt créer ton fichier dans /etc/X11/xorg.conf.d/ (cf la page de manuel xorg.conf).

Gparted est un outil de partitionnement, pas de vérification de disque dur. La seule chose qu'il peut éventuellement réparer, c'est la table de partitions.

Je te conseille d'utiliser gsmartcontrol, c'est uen interface graphique pour smartctl, dans la liste des attributs il t'affichera en fond rouge ceux qui sont considérés comme inquiétants, et au survol de la souris il affiche une explication (si elle est disponible) de la signification des différents attributs (certains n'ont pas la même signification selon le constructeur).

Oui, c'est à craindre, vu sa formulation:

j'ai voulu installer Ubuntu 16.04 […] sur mon disque C:

Si je comprends bien ton besoin, tu veux qu'un script s'exécute au démarrage du système et un autre à l'arrêt.
Tu avais fait ça en utilisant les actions start et stop d'un init script sysV, mais j'ai l'impression que ce n'est pas vraiment le fonctionnement prévu pour ces scripts et que ça fonctionnait par effet de bord (l'init sysV traditionnel n'ayant aucun moyen de savoir si un service fonctionne encore vraiment, il lance tous les stop prévu, qu'il y ait quelque chose à arrêter ou pas).

Systemd a essayer de maintenir autant que possible la compatibilité avec ces scripts d'init, mais il a visé le fonctionnement normal et le scripts qui comptaient sur un effet de bord des limitations d'init sysV ne vont plus forcément fonctionner comme prévu.
En l'occurrence, je pense que systemd constate, après avoir démarré ton «service» qu'il ne reste plus aucun processus qui tourne et en conclu que le service s'est terminé et qu'il n'y a donc plus rien à arrêter.

La solution est de faire un vrai service systemd en tenant compte du fonctionnement (documenté!) de systemd.
Je te recommande de lire les pages de manuel systemd.unit systemd.service et systemd.exec.

En particulier, je pense que l'option importante pour ce que tu veux faire est RemainAfterExit (dans le man systemd.service) qui permet de dire à systemd que le service doit encore être considéré comme actif même si tous les processus se sont terminés.
Tu combine ça avec ExecStart et ExecStop pour définir les scripts à exécuter au démarrage et à l'arrêt (le Type par défaut simple devrait faire l'affaire).
Tu ajoute une section Install où tu indique que ton service est WantedBy multi-user.target (ou celui qui est le plus adapté à ce que tu veux faire).
Un fois que tu systemctl enable ton service il devrait être automatiquement démarré au boot et arrêté au shutdown (parce que par défaut tous les services sont arrêtés au suhtdown, cf le paramètre DefaultDependencies dans man systemd.unit).

Note que si tu veux en plus que ton service soit arrêté quand le système est mis en veille et relancé quand il sort de veille, c'est plus compliqué (j'ai une solution qui fonctionne, mais elle n'est pas très élégante).

Attention, l'option -d de svnserve lui dit de se "daemonizer", c'est à dire de se détacher de lui-même de son processus parent pour tourner en arrière-plan.
Si tu veux fonctionner comme ça, il faut le dire à systemd avec l'option

Type=forking

et pour bien faire il faudrait ajouter l'option PIDFile pour que systemd sache quel est le processus à arrêter, et ajouter à la ligne de commande l'option --pid-file pour dire à svnserve où enregistrer son fichier PID.

Voir la documentation via man systemd.service

Ton include fait un chemin relatif, donc il cherche le répertoire app dans le répertoire courant, qui n'est probablement pas celui que tu crois (plutôt le répertoire de base du serveur web).
Il faut soit faire un chemin absolu (commençant par un /), soit un chemin relatif au répertoire du fichier courant en utilisant __DIR__

Le : n'est même pas nécessaire, un simple >fichier_vide aura pour effet de créer (ou vider) le fichier donné.

Mais l'inconvénient par rapport à touch, c'est que justement cette forme videra un fichier existant sans avertissement, là ou touch se contentera de changer sa date de modification.

Edit: oups, pas vu que ça avait déjà été répondu par d'autres…

youtube-dl se débrouille bien pour récupérer les vidéos.

Ce serait plus robuste de faire un "file --mime-type" suivi d'un "grep -v image/".
Je te laisse trouver un moyen d'améliorer ça pour ne pas exclure des fichiers qui se trouvent dans un répertoire appelé image sans pour autant être des images.

Sauf que la page de manuel française n'est pas à jour.
Par exemple, dans la manpage anglaise (et le -h de la commande), on voit qu'on peut l'appeler dans cette variante:

reptyr -l|-L [COMMAND [ARGS]]

Mais dans la version française il n'est documenté que

reptyr -l

Donc mieux vaut se référer à la version anglaise.

Si tu t'étais limité à ta première phrase, j'aurais noté ton commentaire comme pertinent.
Mais la deuxième phrase méprisante annule l'effet positif de la première.

Quand on trifouille dans les partitions, surtout si on déplace une partition (avec gparted ou autre), la première chose à faire c'est une sauvegarde de ses données importantes.

Pour toutes les données dont tu n'a pas une sauvegarde, il faut te poser la question « est-ce que je peux accepter de perdre ces données ».

J'ai déjà réussi à sauver le contenu d'une partition dont le déplacement par gparted avait été interrompu par une coupure de courant. Mais ça a pris plusieurs jours de travail et l'achat d'un disque dur externe deux fois plus gros que celui d'origine.

Dans la configuration de ton datasource, tu accepte jusqu'à 500 connexions, est-ce que PostgreSQL est configuré pour en accepter également autant que ça? (par défaut, c'est 100)

Et puis, une webapp pour laquelle tu prévois d'avoir besoin de jusqu'à 500 connexions simultanées à la DB, je n'appelle pas ça une "petite" appli.
Tu as vraiment autant de monde que ça qui visite ton appli?

Si, il y a bien deux inconnues (le poids de la bouteille et le poids du bouchon) et deux équations (la somme des deux et la différence des deux), ensuite tu élimine une des inconnues pour ne conserver que celle qui t'intéresse.

Vu sur XKCD what if
Relativistic baseball
Diamond

Encore une fois, un script qui veut modifier /etc/fstab ne peut fonctionner qu'en root, donc récupérer le nom de l'utilisateur avec whoami est inutile, ce sera forcément root. (à moins que tes postes aient des configurations spéciales?)

Concernant le hostname, bash défini déjà lui-même une variable HOSTNAME (à de très rares exceptions près, les variables pré-définies sont en majuscule).

Pour les options de montage, les file_mode et dir_mode que tu met sont une mauvaise idée, ça veut dire que tout le monde peut écrire/supprimer n'importe quoi dans le montage, et que tous les fichiers seront exécutables. Peut-être est-ce vraiment ce que tu veux, mais ne perd pas de vue que ça veut dire que tous les utilisateurs locaux font ce qu'ils veulent.
Il serait préférable d'utiliser les valeurs file_mode=0664,dir_mode=0775 combinées avec l'options gid pour que seuls les utilisateurs du groupe donné aient accès en écriture.
(et tu as mis deux fois l'options users)

C'était également une meilleure idée de mettre le fichier credentials dans /etc (sans le point au début, pas besoin qu'il soit caché), car maintenant il va se retrouver dans le home de root, ou pire, si l'utilisateur qui exécute le script ne le fait pas correctement (par exemple avec "su" plutôt que "su -"), ça peut se retrouver dans le home de l'utilisateur normal.
(par contre, le "chmod 600" est bien ce qu'on veut pour ce fichier)

Toujours pas envie d'informer l'utilisateur qui exécute le script si ça s'est passé correctement?

Pour la coloration syntaxique, c'est indiqué dans l'aide-mémoire de la page d'édition (et il faut laisser une ligne avant et après, sinon ça ne fait rien du tout)

Le

chown -R `whoami`  $dir_tgt

est inutile, c'est toi qui a créé ce répertoire un peu avant, donc il t'appartient déjà.
De toute façon, si le script n'est pas exécuté par root il n'aura pas le droit de changer le propriétaire (et faire le reste non plus d'ailleurs).
Si le but est de le remettre à root au cas où il existerait déjà avant, met explicitement root à la commande chown.
Au passage, la syntaxe en backtick est dépréciée, il est préférable d'utiliser la version $() qui a l'avantage d'être imbriquable.
Mais de toute façon, le mount peut échouer pour d'autres raisons, et tu pourrais aussi bien faire ce chown tout de suite après la tentative de création du répertoire.

La commande interne read a une option -p pour afficher un prompt, ça économise le printf avant.

Tu devrais toujours utiliser des double quotes autours de tes variables ($dir_tgt en l'occurrence), ce n'est pas un problème dans ton exemple car la variable ne contient rien de problématique, mais si tu modifie ultérieurement la valeur ça pourrait le de venir.0A;
Ce n'est pas une bonne idée d'utiliser un fichier temporaire avec un nom fixe (surtout dans un répertoire commun et avec un nom aussi générique).
Mieux vaut utiliser la commande mktemp pour générer un fichier temporaire avec un nom aléatoire, et ne pas oublier de le supprimer à la fin.
Au passage, utiliser la redirection de type >> signifie que tu ajoute à la fin du fichier, ça ne me semble pas le but ici. (ou alors voudrais-tu que le log s'accumule à chaque exécution du script?)

MOUNTLOG=$(mktemp mount.XXXXXX)
mount -a > "$MOUNTLOG"
#..suite
rm -f "$MOUNTLOG"

Plutôt que de tester le code de sortie de la commande mount, tu peux la mettre directement dans le if:

if ! mount -a > "$MOUNTLOG" ;then

(d'ailleurs il manquait un espace entre le 0 et le ])

Tu utilise la commande mail, es-tu sur qu'il y aura toujours un serveur mail correctement configuré sur tous les serveurs où le script sera utilisé? (ou au minimum une implémentation locale de sendmail, comme dma ou ssmtp)
Et puis, ce serait quand même bien d'informer la personne qui exécute le script si ça s'est passé correctement ou non.

Pour finir, c'est une très mauvaise idée d'écrire un script complexe ex nihilo et de l'exécuter directement sur des machines de production. Mieux vaut le tester d'abord sur une machine qu'il est acceptable de casser un peu.
Prépare-toi à devoir intervenir en urgence sur certaines machines qui ne fonctionneraient plus.

les mots français commencent à disparaître au profit de l'anglais parce que c'est plus cool

:-)

Sed seul suffit pour faire ce que tu demande en faisant usage du hold space:

sed '1h;1d;$p;$g' mon_fichier.txt

Si tu veux modifier directement le fichier, ajoute l'option -i, sinon redirige vers un autre fichier.

Et puisque tu as posté dans le forum astuces par erreur, j'en ajoute une:
Pour comparer directement le résultat avant après, sans devoir le mettre dans un fichier temporaire, tu peux profiter du process substitution du shell:

diff -u mon_fichier.txt <(sed '1h;1d;$p;$g' mon_fichier.txt)

(testé avec bash, je ne sais pas si c'est une fonctionnalité de base de shell posix ou une extension de bash)

Sauf que dans ton message initial, tu mentionne des adresse IP. Et si c'est de l'IPv4, elles contiendront des points.
Or pour grep (et dans les expressions rationnelles en général, même en version restreinte), le point signifie n'importe quel caractère.
Donc si tu veux que ça extraie uniquement les lignes qui contiennent les adresses IP telles quelles (plutôt que la même chose mais avec n'importe quoi à la place des points), il faut soit protéger les points par des backslash, soit utiliser l'option -F de grep, qui lui dit de traiter la chaine telle quelle, plutôt que comme une expression rationnelle.
(et je ne parle même pas de caractères qui viennent avant ou après le fragment de chaîne repéré dans la ligne)

Les { et } sont aussi des caractères spéciaux du shell, il faut les protéger comme le point-virgule.

Ceci étant dit (ou plutôt écrit), find a une action -delete, qui t'évitera de lancer autant de fois rm que tu trouve de fichiers (ce qui peut être largement mitigé en passant à la variante "-exec command {} +")

en proposant à la place de les stocker dans un mysql qui c'est bien connu utilise des fichiers texte dans /var/log.

Avec MySQL, ça peut se faire :-)
http://dev.mysql.com/doc/refman/5.5/en/csv-storage-engine.html

Non, le codage par défaut d'un fichier properties c'est l'ISO-8859-1, donc tu peux y mettre des caractères accentués à la française.
http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#load(java.io.InputStream)
Et si tu le charge avec la variante qui prend un Reader
http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html#load(java.io.Reader)
ça peut être ce que tu veux, puisque tu peux utiliser un InputStreamReader auquel tu précisera le codage des caratères.
http://docs.oracle.com/javase/7/docs/api/java/io/InputStreamReader.html

Intéressant en effet, je le retiens.