Sommaire
Bien le bonsoir,
Histoire de changer d’air, je vais parler un peu de bidouilles qu’il est possible de réaliser sous GNU/Linux avec des outils modernes. Il ne s’agit pas de tutoriel, ni de manuel au sens classique des termes mais d’un exemple pratique et volontairement simplifié à l’extrême, une manière de partager des astuces, écrit au kilomètre, que chacun pourra adapter & compléter à sa convenance. Parce que c’est ce que j’aime sous GNU/Linux, le côté bidouille, avec une documentation foisonnante pour réaliser facilement des tâches complexes, les automatiser, etc. Je finirai par un peu de politique (vous inquiétez pas, il ne sera pas question de communistes mangeurs d’enfants pour une fois).
De la technique
Avant de commencer
Pré-requis : se débrouiller en shell, savoir deux–trois p’tits truc sur les systèmes GNU/Linux, utiliser btrfs comme système de fichier et systemd (le reste appartenant à la préhistoire de l’informatique).
Documentation : le World Wide Web, man_(Unix).
BTRFS
btrfs est un système de fichiers nouvelle génération, utilisant massivement le copy-on-write. Il gère les sous-volumes (subvolume), les instantanés (snapshot), le raid (en cours d’implémentation si je ne m’abuse), le copie de fichier (essayez donc cp --reflink=auto sur un gros fichier, c’est magique…), et j’en oublie sûrement… ah oui ! la possibilité de faire un copy-on-write d’un système de fichier en lecture seule : utile pour des liveCD par exemple.
Aujourd’hui ce qui me préoccupe, c’est la création d’un script shell/dash (pour les performances optimales et l’occupation mémoire minimale) de sauvegarde utilisant des outils extrêmement simples et exploitant btrfs. (Attention tout de même : btrfs n’est stabilisé que sur des versions récentes du noyau et l’utiliser pour des sauvegardes se fait à vos risques & périls.)
Mettons que nous avons monté un système de fichiers btrfs sur /mnt. La première étape est la création d’un sous-volume backup :
sudo btrfs subvolume create /mnt/backupPuis un autre qui se trouvera lui-même dans backup :
sudo btrfs subvolume create /mnt/backup/latestCe sous-volume contiendra toujours la sauvegarde la plus récente de nos données personnelles via un simple :
rsync -axv --inplace --delete $HOME /mnt/backup/latestTout ceci est bien beau, mais qu’en est-il si je veux retrouver un fichier effacé depuis un mois ? Très simple ! Au moment de créer la sauvegarde, juste après que la commande rsync ait fini, on exécute :
sudo btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/`date +'%Y-%m-%d'`Et automagiquement un instantané de latest est créé à la date du jour ! Grâce au copy-on-write, on a une véritable sauvegarde incrémentale : tout rsync dans latest n’enregistrera que les modifications nécessaires, limitant la place mémoire occupée physiquement sur le disque dur, et on conservera les données des instantanés du passé.
On peut raffiner ces quelques commandes et obtenir un script /usr/local/bin/backup du genre :
#!/bin/dash
mount /mnt/backup || exit 1
H=/home/pierre_roc
cmd="rsync -axv --inplace --delete"
$cmd --filter="merge $H/.rsync.pattern" $H /mnt/backup/latest$H
[ -d /mnt/backup/`date +'%Y'` ]||btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/`date +'%Y '`
[ -d /mnt/backup/`date +'%Y-%m'` ]||btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/`date + '%Y-%m'`
[ -d /mnt/backup/`date +'%Y-%m-%d'` ]||btrfs subvolume snapshot -r /mnt/backup/latest /mnt/backup/`dat e +'%Y-%m-%d'`
for i in `seq 0 99`
do
[ -d /mnt/backup/`date --date="year ago $i month ago" +'%Y-%m'` ]&&btrfs subvolume delete /mnt/backup/`date --date="year ago $i month ago" +'%Y-%m'`
done
for i in `seq 0 999`
do
[ -d /mnt/backup/`date --date="month ago $i day ago" +'%Y-%m-%d'` ]&&btrfs subvolume delete /mnt/backup/`date --date="month ago $i day ago" +'%Y-%m-%d'`
done
umount /mnt/backupÀ condition d’exécuter le script tous les jours, on obtient un instantané par jour, avec un roulement : les instantanés de plus d’un mois sont effacés, sauf celui qui a été réalisé en premier chaque mois ; les instantanés de chaque mois sont conservés, sauf s’ils ont plus d’un an ; enfin le premier instantané de chaque année est quand à lui conservé indéfiniment. On obtient par exemple (j’avoue ne pas être très régulier dans la sauvegarde de mes données) :
ls /mnt/backup
2012/ 2013/ 2013-11/ 2014/ 2014-07/ 2014-08-26/ 2014-08-27/ 2014-09/ 2014-09-03/ latest/
Là où ce genre de besoins nécessitait des outils complexes, pas toujours très performants, btrfs permet de résoudre avec brio la problématique posée par un système de sauvegarde, avec une simplicité enfantine pour qui sait manier un peu le shell. Et ce sans absolument rien sacrifier en performances.
Passons à systemd maintenant, car il faut bien automatiser le lancement du script, disons tous les jours à 4h du matin. Par exemple. Avec Cron, c’était imbittable, avec systemd c’est un jeu d’enfant ! Tout d’abord nous allons créer un “timer”, c’est-à-dire une unité qui permet d’activer un service selon un calendrier donné. Pour cela il suffit de créer un fichier /etc/systemd/system/backup.timer :
[Timer]
OnCalendar=*-*-* 04:00:00
[Install]
WantedBy=timers.target
Puis un autre fichier qui doit impérativement porter le même nom et dont seule l’extension change /etc/systemd/system/backup.service :
[Unit]
After=local-fs.target
[Service]
ExecStart=/usr/local/bin/backup
Et on active le bazar via :
sudo systemctl start backup.timer
C’tout. Systemd, plutôt que de vous obliger à réinventer la roue, vous permettra de vérifier très aisément si votre timer a bien exécuté le programme, si le script s’est bien déroulé, etc. grâce aux commandes (entre autres) :
systemctl status backup.service
systemctl status backup.timer
systemctl list-timers
Cool non ? Ça a tout de même plus de gueule qu’un script init à la syntaxe horrible, et qui change en fonction de la distribution pour ne rien arranger, tout en proposant plus de fonctionnalités sans coût supplémentaires (journal, raffinement dans les modalités d’exécution par systemd, etc.).
Udev + systemd
Un autre usage que je propose est l’automatisation du téléchargement des photos depuis un appareil. En gros : je branche mon appareil, j’attends 30s, un “dong” retentit (le détail qui tue), et je n’ai plus qu’à débrancher mon appareil. Tout est fait automatiquement.
On suppose que vous avez déjà un script de téléchargement des photos dans /usr/local/bin/down_photo, on peut utiliser rsync (sans l’option --delete cette fois-ci), ou alors, en guise d’exemple, je présente un script plus raffiné :
#!/bin/dash
H=/home/pierre_roc
mount /mnt/olympus || exit 1
[ -d $H/photographie/darktable ] || exit 1
for i in /mnt/olympus/DCIM/*/*.ORF
do
j=`basename $i`
d=`exiftool $i -DateTimeOriginal|sed 's/^Date\/Time Original\s*: \([0-9]*\):\([0-9]*\):.*$/\1-\2/1'`
echo -n "$d/$j"
if [ ! -d $H/photographie/darktable/$d ]
then
echo -n " mkdir"
mkdir $H/photographie/darktable/$d
chown pierre_roc:pierre_roc $H/photographie/darktable/$d
fi
if [ -f $H/photographie/darktable/$d/$j ]
then
echo " pass"
else
echo " down"
cp $i $H/photographie/darktable/$d/
chmod a-x $H/photographie/darktable/$d/$j
chown pierre_roc:pierre_roc $H/photographie/darktable/$d/$j
fi
done
umount /mnt/olympus
count=0
mount /mnt/olympus
for i in /mnt/olympus/DCIM/*/*.ORF
do
j=`basename $i`
d=`exiftool $i -DateTimeOriginal|sed 's/^Date\/Time Original\s*: \([0-9]*\):\([0-9]*\):.*$/\1-\2/1'`
if diff $i $H/photographie/darktable/$d/$j
then
rm $i
count=$((count+1))
else
echo "error: $j" >&2
rm $H/photographie/darktable/$d/$j
fi
done
umount /mnt/olympus
echo $count pictures downloaded
mpv -quiet $H/documents/ding.mp3 >/dev/nullComme vous pouvez le constater, c’est assez complexe car je classe mes photos dans des dossiers, en fonction du mois de la prise de vue, grâce aux méta-données exif.
Pour info. voici la ligne /etc/fstab qui va bien :
/dev/disk/by-id/usb-OLYMPUS_XZ-1_AAN547126-0:0-part1 /mnt/olympus vfat noauto 0 0
car il est primordial de ne pas être dépendant d’un nom de périphérique du style /dev/sdXN, trop volatile.
Reste plus qu’à lancer automatiquement le script. C’est là où udev entre en jeu. Il y a là deux petits truc à savoir si on ne veut pas galérer. En premier, faites les essais sans photographies importantes sur votre appareil car j’ai constaté des comportements très suspects avec des pertes de données, et écrivez vos règles udev avec votre périphérique débranché pour commencer. En second, on va se servir de systemd : c’est le comportement recommandé pour des versions récentes d’udev qui a été intégré à systemd il y a peu. C’est ce dernier point qui m’a posé problème car il rend caduque certains documents qu’on trouve sur le web.
Tout d’abord on branche l’appareil photo, on repère le périphérique /dev/sdXN qui représente la partition de sa carte mémoire et on exécute :
udevadm info -ap `udevadm info -q path /dev/sdXN`
Vous obtiendrez une sortie bien bien moche (note : il semblerait que la commande udevadm info soit spécifique à Gentoo, la variante la plus courante devrait être udevinfo).
La sortie commence par le device représentant la partition, et remonte l’arbre des périphériques :
looking at device '[...]sdXN':
[...]
SUBSYSTEM=="block"
ATTR{size}=="15515648"
ATTR{partition}=="1"
looking at parent device [...]:
[...]
looking at parent device [...]:
SUBSYSTEMS=="scsi"
[...]
ATTRS{model}=="XZ-1 "
looking at parent device [...]:
[...]
Attention, il y a deux écueils à éviter. Il ne faut choisir qu’un, et un seul, parent device et vous y tenir pour ce qu’y suit : en règle général vous choisirez celui qui identifie à coup sûr votre appareil (le XZ-1 en ce qui me concerne, un excellent objectif ceci dit en passant :) ). Ensuite il faut bien différencier la partition sur la carte mémoire (sdXN) de la mémoire entière (sdX), donc bien veiller à sélectionner un attribut qui permettent de distinguer les deux : ATTR{partition} joue ce rôle.
Nous voilà fin prêt pour écrire la règle udev dans /etc/udev/rules.d/10-local.rules (pensez à débrancher votre appareil avant) :
ACTION=="add",SUBSYSTEM=="block",ATTR{size}=="15515648",ATTR{partition}=="1",SUBSYSTEMS=="scsi",ATTRS{model}=="XZ-1",ENV{SYSTEMD_WANTS}="down_photo.service"
Le tout sur une seule ligne, impérativement. Une règle udev c’est quelque chose d’extrêmement simple : des tests et des assignations, si les tests sont vrais, udev effectuera les assignations. Ici, si le périphérique est branché (ACTION=="add") et qu’il correspond aux critères permettant d’identifier l’appareil photo et sa carte que je ne change jamais d’où le critère de taille (cf. la sortie de la commande précédente), alors on affecte l’unité systemd down_photo.service à la propriété SYSTEMD_WANTS.
Ce dernier point mérite un commentaire. Avant on pouvait lancer directement un script grâce à RUN+="mon_script". Mais ce comportement n’est pas recommandé car la gestion de l’exécution du script par udev est extrêmement sommaire et pose de plus en plus de problèmes (l’environnement y est extrêmement limité). Passer par systemd permet de profiter de ses fonctionnalités avancées : l’appel non bloquant contrairement à udev et, entre autres, les logs. En effet vous aurez remarqué que j’ai plein de echo dans mon script : ils seront redirigés automatiquement vers le journal de systemd.
Il ne reste plus qu’à créer l’unité systemd /etc/systemd/system/down_photo.service. Très simple là encore :
[Unit]
Description=Download from XZ-1
After=local-fs.target
[Service]
ExecStart=/usr/local/bin/down_photo
C’tout. Vous avez votre système de téléchargement des photos entièrement automatisé. :)
De la politique
Systemd est l’occasion de trolls à profusion, et je voulais apporter ma petite contribution.
UNIX : un outil par tâche, vraiment KISS ?
La théorie veut que le système UNIX utilise des outils simples, réalisant des tâches simple, et qu’on assemble le tout pour réaliser des tâches complexes.
En pratique, on fait appel à un outil très particulier pour réaliser la glue : le shell (bash pour respecter la norme de fait, dash pour respecter la norme des pénibles — ou ses perf. —, zsh pour les vrais hommes).
Et c’est là que ça se gâte.
Parce que le shell, dans le genre usine à gaz qui fait plein de choses, et toutes très mal…
Ça se pose là.
Le shell c’est un langage de programmation… Enfin, il paraît ! Syntaxe horrible &co, on écrit pas de gros programmes avec ça, à moins d’être un peu masochiste sur les bords.
Le shell c’est une interface homme–machine… Pourquoi pas ! C’est encore là où il se défend le mieux. Je ne comprends plus l’intérêt d’une interface graphique dans énormément de mes usages, où j’ai l’impression d’être totalement bridé. Mais dès lors qu’on sort du texte, que le travail nécessite beaucoup de manipulations manuelles, y’a plus personne… du coup les opérations à réaliser sont un sous-ensemble relativement restreint de tâches automatiques et donc de tout ce qu’il est possible de faire avec un ordinateur. Pt’êt que chez les dinosaures ça suffit, mais pour une utilisation un poil moderne de l’outil informatique, force est de constater que l’interface en ligne de commande est insuffisante.
Enfin, le shell utilise les tubes pour la glue entre les programmes… Bon ça va bien cinq minutes mais on se retrouve très, mais alors très, très vite limité, même pour du traitement de texte basique (d’où awk,sed&co, même la substitution de texte est une “basherie” !).
Pourquoi parler de tout ça ? Parce que j’ai le sentiment que Systemd loin de trahir la philosophie UNIX, reproduit ce comportement : un outil central (mieux pensé que le shell tout de même) qui permet de gérer un ensemble d’outils très simples (ici mes petits scripts maison) qui communiquent entre eux (ou pas), sans avoir besoin de réinventer la roue (des logs? systemd le fait pour vous).
Des erreurs de jeunesse
Curieusement les débats autour de systemd sont rarement techniques. Pourtant, il y a quelques petits ratés, et je vais en citer un, très factuel, très terre à terre. Ça change. Pour une fois. Peut-être est-ce lié à ma distribution (Gentoo) auquel cas sentez-vous libres de (me) corriger dans les commentaires.
Les développeurs, s’arrogeant le droit de prendre des décisions à ma place, ont décidé que la taille du journal devait être fonction de l’espace mémoire disponible sur le système (un pourcentage je crois bien).
Cela a tout de la fausse bonne idée.
Premièrement. On ne sait jamais combien d’espace mémoire il nous reste réellement. C’est particulièrement pénible sous certaines conditions d’utilisation où on est amené à faire transiter beaucoup de données en mémoire. Vous croyez qu’il vous reste plus que 10 Go, vous virez 10 Go, et vous vous retrouvez avec 15 Go de libre au lieu de 20, vous remettez 10, mais l’espace libre n’a diminué que de 5. L’arithmétique à la sauce systemd : c’est un concept…
Secondement et beaucoup plus grave. Si plusieurs programmes s’avisent de faire de même, cela pose une grande question métaphysiques du style : qui va vampiriser l’espace disponible, combien occupe chaque programme ? En effet mettons qu’on ait deux programmes A & B qui décident d’occuper 50 % de l’espace libre, avec 20 Go de dispo. Je vous passe le cas d’une race condition où les deux programmes évaluent l’espace disponible à 20 Go, avant d’engager chacun le remplissage à hauteur de 10 Go… A voyant 20 Go libres, remplit à hauteur de 10 Go, B arrive après et remplit à hauteur de 5 Go (50 % de 20-10 Go). A repasse après, voit qu’il n’y a plus que 5 Go de libre + 10 Go qu’il occupe ce qui donne 15 Go, divisé par deux, soit 7,5 Go : A se dit “oulala j’occupe 10 Go c’est beaucoup trop, faut que je libère un peu… À l’itération suivante c’est B qui se dit “cool maintenant y’a plus d’espace vais pouvoir charger un peu la mule”. Et ainsi de suite. Au final, en fonction des itérations, des politiques suivies par chacun des programmes et de l’historique d’utilisation de votre mémoire, vous ne saurez jamais combien chacun occupe. C’est la fiesta sur votre disque dur, chacun n’en fait qu’à sa tête, les ressources sont gaspillées, mal réparties et j’en passe.
C’est un comportement particulièrement irresponsable de la part d’un développeur, d’une distribution, et d’un administrateur que d’amener à avoir des programmes qui s’adaptent d’eux-même en fonction des ressources globales du système et applique une politique d’utilisation dans leur coin. Ça marche pas. Tout le monde sait bien que les politiques d’accès aux ressources économiquesinformatiques doivent s’établir de manière globale et non pas laissées à la discrétion des individus–entreprisesprogrammes. (Toute ressemblance avec des système économiques tels que libéralisme et socialisme est purement fortuite, et indépendante de ma volonté, car je l’avais promis.)
Un petit passage par /etc/systemd/journald.conf et la page man associée résoud fort heureusement le problème. Mais ça vous fait tout drôle la première fois de voir ce truc occuper des Go.
Et si c’était politique
Ce qui m’a surpris dernièrement (qu’à moitié ceci dit), c’est d’apprendre que l’auteur de systemd avait une vision politique, au sens noble du terme, c’est-à-dire une vision à long terme, je veux dire un projet, de ce que devrait être le système Linux. Il suffit de lire un peu son blog pour que ça saute aux yeux. En passant outre les qualités diplomatiques de Lennart Poettering — je suis tout cela de très loin, mais j’ai cru comprendre qu’il a tendance à imposer ses solutions (litote) —, je me demande s’il ne s’agit pas de cela au fond. C’est une ouverture que je propose. Honnêtement je ne compte pas répondre moi-même à cet épineux problème (à savoir l’avenir de Linux). Comme je l’ai dit, ce qui m’intéresse avec ce système, c’est la possibilité de mettre les mains dans le cambouis. Et contrairement à l’avis majoritaire sur systemd, je trouve que ce système d’init offre plus d’opportunité, car il est moins rebutant que ce qui existait avant : franchement, je ne sais pas ce qu’il en est de votre côté, mais un script d’init Gentoo/OpenRC/Bash, ça fait pas envie.
Le fait est que je vois d’un très mauvaise œil une quelconque démocratisation de GNU/Linux, car j’ai le sentiment que c’est de cela qu’il s’agit en toute dernière analyse. Outre les contraintes techniques que cela nécessite, c’est aussi une question d’écosystème. Toujours en terme de bidouillage, il est plus facile de trouver une réponse sur le web à un problème précis lorsque vous avez 90 % de contenus très techniques, plutôt que 90 % de questions posées par des neuneus, sans réponse bien évidemment. Et cet écosystème ne peut pas ménager le chou et la chèvre : à un moment donné il faudra faire un choix, qui nous sera très certainement imposé d’ailleurs.
Restera BSD.
# En ce qui concerne tes interrogations métaphysiques...
Posté par Okki (site web personnel, Mastodon) . Évalué à 10.
Pour la partie sur le journal, t'en fais tout roman, pour conclure qu'en lisant la doc, tu t'es rendu compte qu'on pouvait fixer la taille du journal, plutôt que de laisser le pourcentage par défaut. Je ne vois donc pas trop où est le problème. Avant systemd, par défaut, les logs pouvaient saturer la partition. Désormais, ça se limite à un pourcentage, et on peut configurer simplement un autre comportement si l'on préfère.
En ce qui concerne la possible démocratisation de Linux, tu auras de toute façon toujours d'un côté des forums à la Ubuntu, avec le public qui va avec, et d'autres plus techniques, comme ce que l'on peut trouver du côté d'Arch ou Gentoo. Tout comme aujourd'hui, il suffira donc de chercher au bon endroit, ou d'ajouter le nom de la distro qui va bien lors de tes recherches Google, pour obtenir des résultats de bien meilleure qualité.
Et pour conclure sur la partie politique, Lennart n'est pas seul. Si tout se met en place, c'est que derrière, Red Hat semble partager la même vision. Et que ce soit ou non la bonne direction à prendre, la communauté et la plupart des autres distributions semblent d'accord pour les y rejoindre.
Comme je le lisais récemment sur les billets de blog relatifs à Fedora Next, pendant longtemps, le libre n'était qu'une boîte de Lego, dont les distributions récupéraient les pièces dont elles avaient besoin pour tenter d'assembler quelque chose de cohérent et fonctionnel. Le problème, c'est qu'il n'y avait pas vraiment de vision d'ensemble, et encore moins d'avenir. On prenait ce qu'il y avait de disponible à un instant T, et on faisait avec. Maintenant, ils semblent plus se dire « on a envie d'aller là, de pouvoir faire ça et ça, qu'est-ce qu'il nous manque pour y arriver ».
Et quand t'as les moyens, tout est plus facile quand tu peux embaucher des personnes compétentes pour y bosser à temps plein, plutôt que de compter sur la seule bonne volonté de quelques bénévoles. Plutôt que politique, je pense qu'on assiste finalement au résultat d'une professionnalisation plus importante de Linux.
[^] # Re: En ce qui concerne tes interrogations métaphysiques...
Posté par claudex . Évalué à 10. Dernière modification le 04 septembre 2014 à 21:20.
Je ne pense qu'il n'y a pas qu'une professionalisation de Linux, il y a aussi une maturité du libre (c'est peut-être lié). Avant, on visait un système qui marche. Depuis quelques temps, on a un système qui marche et qui peut faire beaucoup de chose. Du coup, on se fixe des objectif en se demandant ce qu'il manque mais surtout comment simplifier le chemin pour qu'un maximum de monde puisse y arriver.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En ce qui concerne tes interrogations métaphysiques...
Posté par Misc (site web personnel) . Évalué à 9.
Je suis d'accord, ça fait longtemps que le libre s'est profesionnalisé.
Quand je vois le tarif d'entrée de LinuxCon, de l'openstack summit à Paris ou de Pycon à Montreal ( cad dans les 600$ pour les 2 derniers ), je me dit que ç'est pas trés communauté friendly. Faut avoir une boite qui paye pour l'entrée, sinon, c'est pas possible.
[^] # Re: En ce qui concerne tes interrogations métaphysiques...
Posté par navaati . Évalué à 1.
Bah, la Embedded Linux Con Europe a un tarif à 150€ (ça reste cher pour un étudiant, c'est vrai) pour les hobbyistes. J'imagine que la Linux Con et les autres ont des offres similaires.
# troll velu avec systemd
Posté par NeoX . Évalué à 10.
avec cron il fallait une ligne dans un fichier pour configurer le timer et lui dire quel script aller chercher, quoi faire, à qui envoyer le resultat.
avec systemd il te faut : 2 fichiers (le timer et le lanceur) en plus de ton script, puis une activation systemctl…
la facilité quoi
:/
[^] # Re: troll velu avec systemd
Posté par ʭ ☯ . Évalué à 8.
Oui, mais avec cron, il fallait apprendre un autre système si finalement au lieu de démarrer à heure fixe, tu as besoin de démarrer sur un évènement. Là, c'est intégré. Bref, tu apprends un seul outil si t'es nouveau, si tu connais cron tu peux continuer de l'utiliser, il est pas près de disparaître.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: troll velu avec systemd
Posté par NeoX . Évalué à 5.
ben avec systemd tu auras ton wrapper qui est pret,
il faudra quand meme lui demander de detecter l'evenement, et lui dire de lancer le wrapper.
avec mon script, j'economise le wrapper,
et je peux aussi le donner à un detecteur d'evenement (un truc perso, udev, inotify…)
bref je suis independant.
une fois qu'on sera tous passé à systemd, il se passe quoi si systemd se "plante" pour une raison X ou Y ?
plus rien ne fonctionne sur la machine ?
[^] # Re: troll velu avec systemd
Posté par Dring . Évalué à 10.
Pour pousser le raisonnement à l'extrême…
Il se passe quoi si le noyau plante ? Il se passe quoi si le thread scheduler plante ? Il se passe quoi si l'allocateur de mémoire plante ? Il se passe quoi si ta centrale électrique s'arrête ?
Il faut effectivement voir systemd comme une brique de base de système, si il plante, ton système est en l'air. Moi ça va pas m'empêcher de dormir.
[^] # Re: troll velu avec systemd
Posté par Moonz . Évalué à 8.
Vu qu’il existe déjà des SPOF, c’est pas grave d’en ajouter à tours de bras ?
[^] # Re: troll velu avec systemd
Posté par xcomcmdr . Évalué à 1. Dernière modification le 04 septembre 2014 à 21:56.
Et sysV c'est pas un SPOF peut-être ?
Par ailleurs, le code de l'init (/usr/bin/systemd) est très réduit.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 04 septembre 2014 à 23:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par xcomcmdr . Évalué à 7. Dernière modification le 05 septembre 2014 à 07:30.
Bah oui. /usr/bin/init (qui est un lien vers /lib/systemd/systemd) ne s'occupe que du boot. Le reste est ailleurs (systemctl, journalctl, …)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: troll velu avec systemd
Posté par xcomcmdr . Évalué à 3.
Et puis bon le nombre de lignes ça a un intérêt très limité, mais si tu vas par là :
T'as regardé le nombre de lignes du kernel, de xorg, de firefox, de chrome ?
Tous en font bien bien plus que /lib/systemd/systemd. OH MY GOD ! :o
Et Xorg tourne en root !
Mais non, c'est systemd le pire parmi les SPOFs présents. Va comprendre…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: troll velu avec systemd
Posté par gnumdk (site web personnel) . Évalué à 7.
Plus pour longtemps grâce à systemd ;)
https://archlinux.fr/news/xorg-server-1-16-est-maintenant-disponible
[^] # Re: troll velu avec systemd
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Je ne vois pas le rapport avec systemd.
[^] # Re: troll velu avec systemd
Posté par gnumdk (site web personnel) . Évalué à 8.
http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
C'est si dure que ça de faire une recherche sur le web? :p
[^] # Re: troll velu avec systemd
Posté par zul (site web personnel) . Évalué à 5.
Whaou. Très impressionant. Pour remettre les choses en perspective, ça fait un certain temps qu'on peut déjà le faire sous OpenBSD (privilège séparation, tout ça …). Pas besoin d'un truc compliqué comme systemd pour arriver à ce résultat.
[^] # Re: troll velu avec systemd
Posté par cedric . Évalué à 3.
Je ne suis pas certain que comparer le design d'une orange et d'une pomme soit tres pertinent pour ce genre de sujet. Entre autre chose, OpenBSD n'est pas trop repute pour l'acceleration materielle de sa stack graphique… D'ailleur ca date de Fevrier le support pour les driver INTEL et AMD en KMS: http://undeadly.org/cgi?action=article&sid=20140223112426 …
[^] # Re: troll velu avec systemd
Posté par zul (site web personnel) . Évalué à 8.
Il dit qu'il ne voit pas le rapport (à par qu'évidemment KMS est nécessaire pour arriver à ce but). L'architecture de séparation de privilège était présente depuis longtemps et Linux aurait pu la mettre en place aussi, sans avoir besoin de systemd. On a l'impression qu'on a besoin de systemd-logind pour arriver à ce résultat (avec des limitations d'autant plus) alors que c'était largement faisable sans tout ce bouzin.
[^] # Re: troll velu avec systemd
Posté par cedric . Évalué à 10.
Si c'est si simple, je veux bien que tu nous fasses un patch :-)
Pour etre un peu plus precis, sans avoir une infrastructure qui inspect les requetes faite par DRI, il est impossible d'avoir la moindre forme de securite. C'est une des raisons de l'existence des resistances a WebGL entre autre, car cela par du principe que tu ne peux pas faire de DMA et que ton architecture qui tappe directement dans le hw ne peut pas etre contourne. Si tu desactives l'acceleration hardware, le probleme ne se pose plus bien evidemment.
La seconde raison, c'est les input, tu ne veux pas que tous les process qui sont execute sous ton identite d'utilisateur, puisse contourner le dispatching de ton systeme graphique et devenir des troyans (Sous X c'est pas un vrai probleme, puisque de toute facon, tu n'as pas de securite). Il te faut donc un process que tu vas truste, qui va faire le dispatching du fd d'input et s'assurer que tout le monde coopere.
Maintenant, tu rajoutes a tout ca le fait que les gens veulent pouvoir avoir du multi utilisateurs, ce qui impose un process affichant une interface sous une entite differente que l'utilisateur finale. Il faut donc demarrer X sous un user different de l'utilisateur finale. Une fois l'authentification faite, tuer X, redemmarrer X sous le bon utilisateur et refiler le dit fd d'input. Et bien entendu, il faut aussi gerer ca quand tu te logges en console…
Donc il te faut un process commun qui se charge de demarrer tes consoles et ton login manager, tourne avec des droits d'execution superieur et peu etre truste. Etant donne que systemd est la seule solution qui implemente deja la majorite du besoin sous Linux, il est plus simple de lui ajouter ce qu'il manque (dans logind) que de reinventer une roue pour arriver au meme resultat.
[^] # Re: troll velu avec systemd
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Merci, mais rien de tout cela n'indique pourquoi systemd est nécessaire, ni même en quoi il faciliterait quoi que ce soit. Pourquoi un simple startx en utilisateur ne pourrait pas lancer X sans setuid root ?
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 10.
La réponse est sur https://hansdegoede.livejournal.com/14268.html
C'est pas tant systemd en tant que tel que le fait que logind gére la session ( cad s'assure que les accés sont revoqués quand il y en a plus besoin, etc ). Ensuite la question est pourquoi logind a besoin de systemd, et pourquoi personne n'a fait ça avant.
Logind a besoin d'un système qui va gérer les sessions de manière fiable ( cad sans fuite de process hors de la session ), et il se trouve que c'est l'un des points fort de systemd, cad via les cgroups. À son tour, la gestion des cgroups, pour être propre, requiert d'avoir un seul process qui gére ça ( histoire que l'état ne change pas sous nez et avec des races conditions ). A son tour, la gestion des process requiert d'avoir un PID1 qui est au courant du fait qu'il y a des cgroups pour les process. Soit il gére ça lui même ( ce que fait systemd ), soit il fait faire ça par un autre process ( ce que upstart aurait fait ).
Les devs de systemd est que pour éviter les races conditions et la fiabilité, c'est plus simple de faire ça dans un seul processus que dans 2 ( vu qu'il y a des délais, potentiellement des communications asynchrones, du code pour communiquer entre les 2 processus, et du code dans le premier pour relancer le 2eme, avec le code du 2eme pour relancer ce qu'il lance lui même, etc ). Donc c'est comme ça qu'on se retrouve avec logind qui a besoin de systemd, et systemd qui se retrouve avec le pid 1.
Je suis sur qu'on aurait pu le faire avant, mais si les premiers trucs au sujet de X sans root date de 2008 ( https://airlied.livejournal.com/59521.html ) et qu'il a fallu 6 ans pour faire les derniers pas, peut être que c'était pas si simple à faire de manière propre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par xcomcmdr . Évalué à -4.
Oulà, t"en tiens une couche…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: troll velu avec systemd
Posté par claudex . Évalué à 3.
Ça veut dire quoi "systemd qui se plante" ? Tu parle du scheduler ou de l'init. Ce n'est pas le même programme. Si tu parle du premier, c'est la même situation que si cron plante. Si tu parle du deuxième, ça reste un code assez réduit et tu peux te connecter en SSH pour redémarrer la machine (à condition que ton serveur SSH soit déjà démarré).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: troll velu avec systemd
Posté par xcomcmdr . Évalué à 2.
Normalement, tu récupères un shell si tu as CrashShell à 1 dans /etc/systemd/system.conf (je n'arrive pas à trouver si l'option est déjà à 1 par défaut ou non)
Tu peux aussi récupérer un coredump avec l'option DumpCore
Note que j'ai jamais eu de crash de systemd qui ne soit pas à cause d'un problème de configuration de ma part (grand classique : une erreur de frappe dans /etc/fstab).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: troll velu avec systemd
Posté par Dring . Évalué à 10.
Je plussoies et pourtant je ne suis pas d'accord - ah, c'est pas comme ça qu'on doit faire ?
Bon, d'accord la méthode systemd est plus verbeuse. Deux fichiers. Et sans doute plus casse-gueule - il faut pas se tromper d'un caractère dans le nom d'un des fichiers, genre un "-" remplacé par un "_".
Mais faut reconnaître que c'est élégant. Il y a plus de cohérence entre "ce qui est déclenché pour et par le système, au démarrage ou non", et "ce qui est déclenché pour l'utilisateur".
Et on voit poindre des tas d'améliorations possibles. Là, le "OnCalendar=*-*-* 04:00:00" n'est qu'une des syntaxes possibles, assez proche de celle de la cron, mais bien plus lisible, merci les "-" et les ":" pour enfin distinguer date et heure. Mon principal reproche à ce stade : ça ne gère pas encore les timezones, un point indispensable dans mon activité pro. Mais rajouter demain une clause "TimeZone" ne semble pas insurmontable.
Il faut aller lire [http://www.freedesktop.org/software/systemd/man/systemd.timer.html] pour voir les fonctions disponibles et à quel point c'est plus simple. Une tâche nocturne qui sort le PC de son hibernation pour faire une sauvegarde ? Facile, un coup de "WakeSystem=true". L'avantage d'un système de planification créé après que le concept d'hibernation ne soit apparu.
[^] # Re: troll velu avec systemd
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Bof, ce serait plus lisible ainsi :
OnCalendar=*-*-* 04:00:00+02:00(pour un décalage horaire fixe) ouOnCalendar=*-*-* 04:00:00/Europe/Paris(pour un fuseau horaire politique avec potentiellement un changement d'heure).[^] # Re: troll velu avec systemd
Posté par Sébastien Le Ray . Évalué à 9. Dernière modification le 04 septembre 2014 à 09:45.
Ouais il te faut deux fichiers… 4 lignes… Trop dur.
Combien de lignes dans le script lancé par cron pour vérifier que la même tâche est pas déjà en cours d'exécution en lisant un fichier PID merdique avec tous les contrôles qu'il faut lui appliquer ? Combien de lignes pour gérer le log convenablement ? Pour avoir l'historique des exécutions ? Savoir si ça s'est bien passé ?
[^] # Re: troll velu avec systemd
Posté par zul (site web personnel) . Évalué à 5.
Normalement 1 que tu dois mettre dans le shell script, vu que c'est surtout lui qui sait si il a le droit ou non d'être exécuter plusieurs fois en parallèle
Aucune idée de ce que tu entend par là, mais logger(1) peut aider (syslogd(8) peut aider aussi).
mail(1) ou syslog
[^] # Re: troll velu avec systemd
Posté par Sébastien Le Ray . Évalué à 6.
En une ligne tu checkes la présence du fichier PID, son contenu, s'il correspond à un process en cours d'exécution, si c'est bien une copie de ton script, tu quittes si c'est le cas et tu crées le fichier avec ton propre PID si c'est OK ? Le tout avec du locking pour gérer la concurrence ? Soit tu ne fais pas tout ça, soit tu appelles une fonction qui fait bien plus d'une ligne.
mail ou syslog pour l'historique… c'est tellement pratique pour sortir des stats, filtrer, etc… Je pense que je vais m'épargner la lecture des (éventuelles) réponses à venir devant tant de bonne foi
[^] # Re: troll velu avec systemd
Posté par zul (site web personnel) . Évalué à 4.
Marrant, tu considère que systemd est une solution simple mais que sourcer un fichier sh et appeller une fonction sh est un truc compliqué. Pourquoi pas. À ce niveau, on ne peut pas dire grand chose hein :)
Je ne doute pas que systemd a une solution miracle à ce problème (analyser finement les données de sorties). Quelle est elle ?
[^] # Re: troll velu avec systemd
Posté par gnumdk (site web personnel) . Évalué à -6.
RTFM
[^] # Re: troll velu avec systemd
Posté par Astaoth . Évalué à 5.
Donc pour bien traduire tes propos : tu ordonnes à quelqu'un de lire un manuel d'un outil qu'il n'utilise pas et dont il se passe très bien afin d'obtenir une précision pour comprendre la réponse de son interlocuteur ?
Emacs le fait depuis 30 ans.
[^] # Re: troll velu avec systemd
Posté par zul (site web personnel) . Évalué à 4.
En fait, j'ai une machine avec systemd (que je n'utilise pas beaucoup au final). J'ai quand même ragé dessus pour le peu que je l'ai utilisé
systemctl stop wpa_supplicantqui ne répond rien ou OK alors qu'il ne fait rien parce que c'est une dépendence de NetworkManager. Bref. Après un certain temps à râler, j'ai fini par comprendre et j'ai viré NetworkManager (oui je sais, je ne suis qu'un sale barbu).Par acquis de conscience, j'ai jeté un coup d'oeil (très rapide) au man de systemd et de systemctl et je n'ai rien vu qui permettrait de résoudre facilement le problème énoncé (historique et analyse fine des logs). J'ai sûrement du raté le truc, mais manifestement, les experts systemd n'ont pas envie d'aider les pauvres êtres qui n'ont pas leur clairvoyance.
[^] # Re: troll velu avec systemd
Posté par xcomcmdr . Évalué à 7.
systemctl status wpa_supplicant
journalctl --unit wpa_supplicant
journalctl --unit wpa_supplicant -xn
journalctl /usr/bin/foo
man journalctl
Aussi, tous les outils de systemd proposent la complétion. Ainsi, je suis tombé sur cette liste d'options :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 04 septembre 2014 à 20:31.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 9.
Je veux pas faire mon chieur, mais ton script va du coup bloquer si quelqu'un d'autre lance un programme et lui fait se renommer pour matcher ton nom de script. C'est un peu naze d'un point de vue sécurité, ça me ferait chiez que mes backups via backup.sh soit bloqué parce qu'un utilisateur s'amuse à lancer un autre backup.sh qui plante ( ou qui tourne dans le vide pour me faire chier ).
Donc je confirme en effet "sans trop reflechir"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 4.
Roh, soit pas aigri, ça arrive de faire une erreur. C'est du shell, c'est rempli de surprise, c'est juste une raison de plus de pas l'utiliser.
La prochaine fois, c'est simple, je te conseille plutôt ce snippet
Déjà, ça corrige le souci que tu as eu. Ensuite, c'est plus lisible de faire 1 -gt, plutôt que le 2 qui va induire les gens en erreurs. Et il vaut mieux utiliser $( ), car tu peux les imbriquer sans souci.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 05 septembre 2014 à 00:41.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par ariasuni . Évalué à 2.
Le mot en anglais est backtick (accent grave pour les non-anglophones).
Écrit en Bépo selon l’orthographe de 1990
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 5.
En effet, ça ne fait que renforcer mon point, c'est dur de faire du shell qui marche :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 07 septembre 2014 à 11:22.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: troll velu avec systemd
Posté par ulver . Évalué à 10.
Rah, mais c'est énervant à force :-)
On retrouve souvent cet argument dans les discussions systemd (Drapeau blanc ! Je ne suis ni pour, ni contre, je m'en fiche) : le shell ça puerait tant que ça ? Mais moi, du shell, j'en fais toute la journée, c'est l'une des principales raisons pour laquelle j'ai adoré linux il y a une dizaine d'années, et il faudrait tout arrêter ?
Si on m'enlève le shell, j'arrête d'utiliser des Unix ! ;)
Plus sérieusement, comme souvent dans les débats interminables (et celui-ci dure peut être depuis trop longtemps sur Linuxfr…), tout le monde est trop extrème :
- les pro-systemd vont te dire qu'un script shell c'est illisible de la première à la dernière ligne
- les anti-systemd vont te sortir des cas d'utilisation surréalistes : et si ça plante pendant le boot, et que ces deux foutus étoiles ne sont pas alignées, tu fais quoi avec ton programme à la con ?
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 10.
Le souci n'est pas le shell pour des scripts rapides. Je fait aussi beaucoup de shell, parce que c'est rapide de torcher un truc de façon incrémental.
Le souci, c'est dire que le shell est génial pour monter un gros truc alors que :
c'est lent ( faut assez souvent faire des forks, ce qui a un cout certes sans doute invisible sur nos machines surpuissante, sans doute plus quand tu veux démarrer vite une VM ou un containeur ), l'interpréteur bash est pas vraiment optimisé pour ça, même si il semble que dash s'en sorte mieux.
les primitives de traitement sont quand même loin de l'idéal sur autre chose que des lignes. IE, on oublie des structures de haut niveau ( alors que pour openrc, on voit qu'il y a clairement un semblant d'orientation objet avec le fait d'avoir une fonction start, une stop, etc, mais que le shell ne le permet pas ). C'est sur que pour de l'analyse de texte et des ones liners, ça passe. Pour enchainer des commandes que tu aurais taper à la main, ouais. Au dela, mhh bof.
qu'il y a une syntaxe un peu baroque ( test vs [ , < vs -lt, etc ) et surtout le besoin de compenser avec des commandes qui sont pas unifiés.
qu'il y a pas les features "modernes" comme un espace de nommage, ou les threads. Même les primitives unix sont pas la. Tu as vaguement les signaux, mais les sémaphores, tu oublies, Creation de fichier temporaire, y a toujours un maigre risque de race condition ( entre le moment ou le fichier est ouvert et le moment ou il est crée, même si en pratique, j'ai du mal à voir un cas ou ça importe ), etc. Les APIs posix, tu as en général pas accès ( et parfois, c'est distro dépendant, genre les sockets qui sont pas activés sur Debian ).
qu'il y a fort peu de libs de test, et que ça rentre pas dans les habitudes des gens qui font du bash ( je sais que c'est faisable, c'est juste que ça rentre pas dans les pratiques usuels )
l'outillage est assez pauvre. La ou des langages comme perl ou python offre divers débuggeurs, profileurs, analyseurs, bash offre un débuggeur qui est dans un état de maintenance, en dehors du projet principal et globalement, c'est tout ce qui existe d'à peu prés avancer ( ça, et set -x, et globalement, la plupart des langages de script le propose aussi, comme rappelé sur http://rigaux.org/language-study/scripting-language/ ).
Encore une fois, tu peux faire un truc qui marche sur un coin de table pendant 5 minutes, je le fait assez souvent. Tu peux même en faire plein. Et je suis sur que tu peux faire tout un tas de trucs.
Mais si tu veux faire un truc qui va tenir plus longtemps et plus gros, je pense ( tu as le droit de pas être d'accord ) que c'est mieux de faire autre chose que du shell ( ça veut pas dire que tu va pas faire de la merde en perl, en python, en C ou autre non plus ). Le système d'init d'une distribution est le seul exemple qui me vient en tête de gigantesque code linbre en shell ( le build system de Mandrake étant le deuxième, et les gros bouts d'openshift étant le 3eme ).
Ensuite, tu as le droit d'en faire, personne t'interdit si ça te va. J'ai aussi un collègue qui en fait tout le temps, il m'écoute pas, et il le vit très bien.
[^] # Re: troll velu avec systemd
Posté par Mimoza . Évalué à 5.
Je suis d'accord avec toi, dire que Cron est trop compliqué et nous sortir un truc ou il faut 2 fichier avec une syntaxe nouvelle et une commande pour l'activer … il faut être sacrément couillu.
Pour ceux qui pense que Cron est trop limité, rien n'empêchait de proposer des évolutions.
En plus j'ai toujours l'impression de voir des fichiers .ini de Windows avec le nom des blocs entre crochets :/
Je suis d'accord que la syntaxe sh/dash/bash/zsh n'est pas facile Que faire communiquer 2 système avec est une gageure. Mais au moins on voie/comprend ce qui se passe, et si on a un problème, l'identification est plus aisé. Là on a plus a faire avec une boite noire qui s'occupe de tout mais si on ne suis pas SA philosophie, alors il est plus que difficile de réaliser ce que l'on souhaite.
Aucun système n'est parfait, et systemd apporte des améliorations indéniable sur certain point. Mais présenter TOUS ses composants comme apportant une révolution est aussi obtus que ceux qui l'attaque. J'ai a chaque fois l'impression d'assister a une présentation Apple avec un "one more thing".
De toute façon si cet outil était tellement génial il n'y aurais pas besoin de le défendre aussi ardemment. Wayland va s'imposer comme le remplaçant de X sans faire autant de polémique …
On ne peut pas leur reprocher d'essayer d'améliorer les choses, mais une alternative aussi crédible est peut être manquante.
[^] # Re: troll velu avec systemd
Posté par Albert_ . Évalué à 6.
Wayland va s'imposer comme le remplaçant de X sans faire autant de polémique …
Il ne fera pas polemique parceque a peu pres tout le monde a accepte de participer au developpement des le depart et c'est pas un truc qui a ete pondu par RH sous la forme d'un troll comme PA ou systemd. Par contre je ne suis pas persuade que Wayland ne declenche pas un sacre paquet de troll mais plutot du cote utilisateurs. Lorsque l'on sait que l'on va avoir des bordures de fenetres differentes suivant le toolkit ou que pas mal de logiciels "anciens" ne fonctionneront plus ca va etre un joyeux merdier et je pense que ce n'est pas pour rien que wayland traine a sortir. Ca fait combien d'annee que l'on entend parler de ca?
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 5.
L'auteur de wayland l'a commencé quand il etait chez RH. Et actuellement, les gens qui poussent wayland sur gnome sont aussi chez RH ( même si jasper st pierre est parti chez Endless ).
Je pense que tu es mal informé, mais c'est pas grave, tu peux quand même avoir une opinion sur une base non factuelle.
[^] # Re: troll velu avec systemd
Posté par Sufflope (site web personnel) . Évalué à 8. Dernière modification le 04 septembre 2014 à 18:37.
Ouais enfin Wayland est globalement soutenu par les devs de Xorg hein… Les principaux opposants sont Canonical-je-réinvente-tout-pour-espérer-qu'on-s'intéresse-à-moi et les vieux croulants-on-faisait-pas-comme-ça-en-1972-donc-c'est-nul.
[^] # Re: troll velu avec systemd
Posté par cedric . Évalué à 8.
Non, mais tu es serieux ? Tu penses vraiment que c'est redhat qui pousse systemd ? C'est une blague ???
L'auteur de Wayland est parti bosser chez Intel, car c'etait la qu'il pouvait bosser dans de bonne condition sur Wayland. C'est Intel qui pousse comme un malade sur Wayland aujourd'hui, et cela pour de veritable raison commercial. Apres il y a des gens qui bossent/bossaient chez Intel sur GNOME et qui ont fini par convaincre le reste de la communaute de GNOME d'avancer sur GNOME. Ca fait a peine 1 an que GNOME travail dessus. Ceux sont les derniers arrives sur le sujet !
Quand a pousser Wayland sur GNOME, c'est juste une evidence. Il est impossible par design de securiser dans un environnement X. A chaque fois que tu tappes un mot de passe sous X, tu as perdu. A chaque fois, sans exception ! Et comme le projet GNOME veut pouvoir enfin faire un eco systeme qui ne depend pas des distributions pour le packaging d'application, ils ont besoin d'une stack sure pour executer du code. Ils n'ont donc plus le choix, si ils veulent faire un truc qui ne transformera pas Linux en Windows Me.
Et pas la peine qu'on discute de Mir, c'est juste une tentative de Canonical de controler sa stack et c'est fait par des gens qui n'ont aucune idee de ce que doit faire un composite manager.
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 7.
Non je le pense pas. Je tente juste de troller albert sur son sempiternel discours à base "tout ce que fait RH est pourri, tout ce ui est pas RH est génial" en rappelant que la réalité est vachement plus nuancé.
[^] # Re: troll velu avec systemd
Posté par gnumdk (site web personnel) . Évalué à 3.
Avec cron? C'est une blague j'espère?
[^] # Re: troll velu avec systemd
Posté par karteum59 . Évalué à 1.
Il ne fera peut-être pas polémique chez les utilisateurs Desktop/gamers, mais à ma connaissance la transparence réseau ne peut être implémentée que via le transfert de gros pixmap (pas de transfert de commandes vectorielles), donc avec des performances bien éloignées de NX et ssh -XC…
Dit autrement: si ça ne fait "pas de polémique", ce sera peut-être parce que la masse d'utilisateurs satisfaits (e.g. support d'optimus, etc.) rendra inaudible les critiques liées aux régressions sur des besoins plus rares.
[^] # Re: troll velu avec systemd
Posté par Olivier Serve (site web personnel) . Évalué à 8.
Les interfaces actuelles n'utilisent plus les commandes vectorielles, donc la soit-disant efficacité de X11 en réseau est déjà morte dans les faits. Et les pixmaps, compressés, seront plus efficaces que ce que fait X11 actuellement.
[^] # Re: troll velu avec systemd
Posté par karteum59 . Évalué à 1.
Mouais, je pense qu'il est aisé de concevoir que des commandes vectorielles doivent logiquement être plus efficaces. Si X ne l'est pas, NX (qui se base sur X) est en revanche à mon avis imbattable. Je peux utiliser NX sur de la 2G/3G sans difficulté, alors que je doute que le transfert de pixmap avec Wayland soit du même ordre…
[^] # Re: troll velu avec systemd
Posté par jyes . Évalué à 7.
Sauf que toutes les boîtes à outils graphiques, à de rares (et vieilles) exceptions près, n’utilisent plus les commandes vectorielles de X.org mais dessinent et envoient directement leur rendu sous forme matricielle.
[^] # Re: troll velu avec systemd
Posté par Albert_ . Évalué à 0. Dernière modification le 04 septembre 2014 à 14:48.
Tres bonne remarque sur la transparence reseau et je ne suis pas persuade que ces besoin soit rares. Je suis meme presque persuade que la proportion de gamers versus les besoins "rares" sous linux sont exactement inverse.
Et cela ne fait pas polemique aujourd'hui car personne ne se sert de wayland.
[^] # Re: troll velu avec systemd
Posté par Nonolapéro . Évalué à 7.
Un peu de lecture au sujet du mythe qu'est la transparence réseau avec X11.
http://blog.martin-graesslin.com/blog/2011/08/thoughts-about-network-trancparency/
[^] # Re: troll velu avec systemd
Posté par Albert_ . Évalué à -1.
Ouhais enfin le mythe de la transparence reseau il est tout de meme utilise a mon boulot tous les jours. Alors je veux bien que cela soit de la merde mais bon ca fonctionne et le jour ou wayland va arriver avec ses gros sabot et tout casse je sens bien le merdier arriver…
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 8.
je pense que c'est plus une question d'intuitivité de la chose. La syntaxe de cron est simple pourles cas simples ( @hourly ), et vite imbittables pour les cas compliqués.
Exemple :
*/5 10 * * 2 /usr/local/bin/yourjob
( la réponse est dans
http://linuxfr.org/nodes/101472/comments/1527821 )
Il y a une courbe d'apprentissage assez raide quand même.
[^] # Re: troll velu avec systemd
Posté par NeoX . Évalué à 5.
toutes les 5 minutes, pendant la 10e heure, le 2e jour de la semaine (le mardi car la semaine US commence le dimanche, et les compteurs commencent à 0) ?
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Et avec systemd, tu dis ça comment ?
Tue *-*-* 10:00/5:00???ou encore
Tue, 10:00/5(si j'en crois le man en tout cas)Je ne suis pas sûr que la possibilité d'avoir plusieurs formes encourage la lecture. De toute façon comme tout ce qui concerne le temps ça fait facilement des nœuds au cerveau à la moitié de la planète.
Je n'ai pas testé systemd comme scheduler. Mais pour moi, ce n'est certainement pas la syntaxe qui en fera un meilleur logiciel que cron. Par contre, s'il est possible gérer des dépendances entre les jobs, d'éviter qu'un script ne se lance tant qu'il est en cours d’exécution, de tuer une tâche qui prends trop de temps … là j'y trouverai un sérieux remplaçant.
[^] # Re: troll velu avec systemd
Posté par Sébastien Le Ray . Évalué à 5.
Tu te rends compte que tu viens de décrire ce que fait le planificateur de tâches Windows depuis plus d'une décennie ?
[^] # Re: troll velu avec systemd
Posté par vv222 . Évalué à 2.
Celui-ci aura tout de même du mal à être utilisé comme remplaçant de cron sous GNU/Linux, aussi efficace soit-il…
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
Je n'ai jamais été suffisamment intime avec windows pour m'en rendre compte
[^] # Re: troll velu avec systemd
Posté par tyoup . Évalué à 1.
Il y a quelque chose de mal là dedans ?
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 5.
Tue 10:00/5Bien que ça reste plus abscons que le dire à voix haute, je continue de penser que c'est plus lisible.
Primo, le nom du jour est clairement visible. C'est pas idéal vu que je continue à me planter entre Thursday et Tuesday, mais bon, je peux imaginer que c'est toujours mieux que 2.
Deuzio, ben 10:00/5, on voit aussi que c'est à 10h.
Trimo, 00/5, bien que ça soit pas forcement intuitif, ça reste plus simple de voir que le pas de 5 s'applique sur les minutes.
Sinon,
Cad, les dépendances sur les jobs ? Activé un premier job quand le 2eme se termine ? Je suis pas sur que ça se fasse, mais c'était le concept d'upstart.
mais tu peux regarder Requires= et After= dans la doc de systemd, et tester ça ( une VM et hop ).
Le timer active un service, donc c'est de base. Mais je testerais ma théorie, car j'ai jamais fait.
C'est faisable, tu mets TimeoutStartSec= dans le service que le timer active. Et si il tourne encore après ce temps sans avoir signaler d'avoir fini, alors il se fait tuer ( et la tache rentre en failed ). Ceci dit, ç'est peut être pas aussi simple, il faut peut être aussi rajouter des choses avec SuccessExitStatus=
[^] # Re: troll velu avec systemd
Posté par Sébastien Le Ray . Évalué à 2.
C'est aussi pris en charge par cron :)
Par contre je confirme sur la gestion des doublons en exécution sous systemd, ça marche bien
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
C'est plus ou moins l'idée. Lorsque tu as besoin d'effectuer des traitements lourds sur des données‚ le fait de disposer d'un scheduler capable de traiter les dépendances entre les jobs permet de simplifier grandement l'écriture des scripts de traitement. Par simplifier j'entends rendre plus robuste.
Par exemples sur une séquence classique telle que : vérifier qu'on est en maintenance, dumper des bases‚ aller récupérer des données via un web service‚ consolider la base selon les données reçues‚ extraire les statistiques‚ tout archiver et remettre en route avant la fin de ta fenêtre de maintenance … Tu as de nombreux cas d'échec possible de nombreux trucs qui peuvent foirer. Tu te retrouves donc facilement a maintenir des scripts gigantesque ne serai-ce que pour gérer tous les cas d'erreur.
Si ton scheduler gère les dépendances type ne lance cette tâche que si celle ci a réussi‚ lance celle la si telle aitre a echouée‚ alors tu peux te contenter de scripts simples faisant une chose et une seule. Facile a écrire et a maintenir.
[^] # Re: troll velu avec systemd
Posté par Moonz . Évalué à 3. Dernière modification le 06 septembre 2014 à 21:30.
Comprend pas pourquoi tu aurais besoin d’un système spécial pour ça.
Tu fais tes scripts simples faisant une chose et une seule, puis un script maître pour chapeauter le tout.
[^] # Re: troll velu avec systemd
Posté par claudex . Évalué à 7.
Et ce script maître, on pourrait l'appeler systemc (ou tout autre lettre qui vous convient).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: troll velu avec systemd
Posté par tyoup . Évalué à 5.
Systemv ça sonne bien je trouve :-)
[^] # Re: troll velu avec systemd
Posté par Misc (site web personnel) . Évalué à 3.
Je vois l'usage.
Je sais pas si systemd y réponds, et si un outil d'orchestration plus classique, voir juste un makefile ferait pas l'affaire par contre.
Un script maitre marcherais, mais je pense que l'idée est aussi d’intelligemment reprendre si ça s'arrête à un moment, ce qui est pas une chose qu'une simple exécution à la suite ferait. Ensuite, peut être que c'est overkill, et qu'il faudrait donc un outil plus spécialisé.
[^] # Re: troll velu avec systemd
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Justement pour éviter d'avoir a maintenir ce que tu appelles les scripts maîtres ou autres makefile.
Ce n'est pas a proprement parlé un besoin. C'est exactement comme la double exécution que tu peux tout a fait gérer dans ton script avec un flag quelconque. C'est juste le petit truc en plus qui te simplifie grandement la vie.
[^] # Re: troll velu avec systemd
Posté par Moonz . Évalué à 3.
Je ne vois pas du tout en quoi une ligne "OnFailure=script1.unit" dans ton script2.unit c’est de la maintenance en moins relativement à écrire "script1.sh || script2.sh" dans un master.sh.
Les deux me semblent équivalents en fait.
Ça veut pas dire que c’est une mauvaise idée d’utiliser ainsi les fonctionnalités de systemd si tu l’utilises à la base pour d’autres raisons (templating, par défaut dans la distrib), c’est juste que ça me semble loin d’être une raison suffisante convaincante pour passer à systemd, ni un avantage énorme de ce dernier.
# Enfin un journal sur systemd bien orienté
Posté par Jean Gabes (site web personnel) . Évalué à 10.
Merci pour ce journal qui s'attaque à une problématique du bon côté, ça change des guerres trollifères. Bon au final certains vont quand même, malgré tes efforts, réussir à réorienté les commentaires vers la guerre idéologique systemd.
Je n'avais vraiment, mais vraiment, pas envie de creuser sur systemd jusqu'à maintenant, mais là ton post m'a titillé la curiosité.
Je suis d'accord sur le côté politique de la chose. C'est un écosystème linux qui est en marche. Bien ou mal, ça restera totalement subjectif et dépendant de l'utilisation que l'on fait de linux ou des outils qui souhaitent le gérer lui en priorité. Bref, pas la peine de lancer un débat là dessus qui ne peux pas avoir de vérité absolue.
# Dash
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 04 septembre 2014 à 09:28.
Non ! Dash doit être vu comme une implémentation d'un shell Unix standard, qui fournit peu de chose de plus. Bash est une autre implémentation, qui fournit pas mal de choses en plus. Mais coder pour Dash, c'est une erreur, si ton code tourne sous Dash il tournera sous n'importe quel implémentation de shell standard, y compris Bash, et il est inutile de cibler
/bin/dash, est nuisible dans la mesure où cela empêcherait sans raison de le lancer sur un système qui ne fournit pas Dash.Bref : tu as presque de bonnes habitudes, continue comme ça mais cible
/bin/sh.[^] # Re: Dash
Posté par Pierre Roc . Évalué à 3.
Sous Debian, ok. Mais je veux dash pour ses performances, et en plus sous Gentoo ce n’est pas conseillé de changé la cible de
/bin/shpour autre chose que bash.Idem en occupation mémoire.
[^] # Re: Dash
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Ça c'est un réglage local, pas un truc qui devrait nécessiter une adaptation des scripts. Mauvaise distribution, changer distribution.
[^] # Re: Dash
Posté par KiKouN . Évalué à 3.
Je ne pense pas que l'optimisation de la partie surpression des anciennes sauvegardes soit importantes ici. D'ailleurs le script ne marche plus si on ne le relance que dans 9999 mois/jour ou s'il plante pendant tout ce temps avant. Il a toutefois l'avantage d'être assez simple.
Dans l'absolu, il aurait fallu faire la liste des dossiers, vérifier que la date n'est pas antérieur à aujourd'hui - 1 an/mois et effacer. Je pense que côté optimisation, c'est plus intéressant que de savoir si dash bat la chamade plus vite que bash.
# /mnt
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Pour info, ce genre d'utilisation de
/mntest caduque depuis, pfiou, au moins cinq ans. Aujourd'hui,/mntest dédié aux montages temporaires, typiquement : voyons voir ce qu'il y a dans cette image ISO. Les montages permanents doivent se faire soit dans un répertoire logique, dans ton cas probablement/var/local/backup, soit dans un répertoire lié au médium de stockage, lorsqu'il s'agit par exemple d'un point de montage pour le lecteur optique, indépendamment de son contenu qui peut varier/media/cdrom.# Intéressant tes critiques sur le shell
Posté par reno . Évalué à 5.
Mais note quand même qu'il y a une différence entre le concept d'un langage de shell et les implémentations.
Pour le concept, je pense que c'est une très bonne idée: même Microsoft l'a (finalement) adopté!
Pour ce qui est des implémentations, effectivement le bash c'est très très nul comme langage, mais tu peux utiliser scsh (un 'shell' en Scheme), là tu as un bon langage mais avec une syntaxe pas adaptée: le plus dur c'est d'avoir un bon langage ET une syntaxe adapté a la ligne de commande..
Pour ce qui est des pipes, le concept de pipe est très puissant mais l'implémentation Unix ou tout est 'texte' par rapport à PowerShell là je ne suis pas convaincu (1), après le problème dans passer des objets est qu'il faut se mettre d'accord sur une sérialisation unique des objets et pour se mettre d'accord sur quelque chose dans le monde Unix, on n'est pas très fort..
1: essayer de parser la sortie de 'ps' de manière fiable et on en reparle de la soi-disant supériorité du texte comme sérialisation.
[^] # Re: Intéressant tes critiques sur le shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
C'est peut-être parce que ps n'est pas fait pour ça, encore que ça ne me semble pas bien difficile en précisant qu'on ne veut pas d'en-tête et qu'on veut des colonnes bien précises. Mais bon, si j'ai besoin d'informations sur un processus dans un script, j'irai plutôt chercher dans /proc.
[^] # Re: Intéressant tes critiques sur le shell
Posté par reno . Évalué à 6.
C'est là le problème, tu ne peux pas vraiment avoir une sortie texte à la fois adaptée pour un être humain et pour un script, donc le 'tout est texte' te force en fait soit à faire des compromis douloureux soit à multiplier les outils..
Et bien ça dépend de ce dont tu as besoin, mais typiquement tu as besoin du nom/de la ligne de commande et là c'est le drame: les noms de processus avec des espaces, les caractères non-ASCII, ça semble marcher sauf quand..
[^] # Re: Intéressant tes critiques sur le shell
Posté par fearan . Évalué à 5.
ps -o est la pour toi
par exemple :
ps -o comm:128,args
tu auras la commande sur 128 caractères, puis la ligne de commande employée pour l'exécuter avec les paramètres, elle est pas belle la vie?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Intéressant tes critiques sur le shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
[^] # Re: Intéressant tes critiques sur le shell
Posté par Anthony Jaguenaud . Évalué à 10.
Le problème de passer par
/procc'est que entre un ls /proc pour avoir la liste des process et l'ouverture du fichier/proc/xxx/commcertains process ont eu le temps de mourir. Alors que la sortie de ps est plus simple à gérer.Un
man psmontre que l'on peut décider de ce que ps affiche (sections : PROCESS SELECTION BY LIST et OUTPUT FORMAT CONTROL). Je pense que aujourd'hui beaucoup de gens font d'abord une recherche sur le net et tombe sur des exemples basic sans jamais lire le man.[^] # Re: Intéressant tes critiques sur le shell
Posté par Misc (site web personnel) . Évalué à 2.
Ensuite, la page de man de ps en francais semble être en retard ( et je pense que tout le monde ne parle pas anglais ).
Et j'ajouterais aussi que les options de ps sont non portables entre Linux et Freebsd, et je suis sur que le layout de /proc est aussi hautement dépendant du systéme.
[^] # Re: Intéressant tes critiques sur le shell
Posté par Anthony Jaguenaud . Évalué à 2.
Tes guillemets sont mal placés.
Comme le montre la colorisation bash de linuxfr. Dans ce cas, comme la variable
pidne contiendra jamais d'espace, il n'y a pas de risque. Mais dans d'autre cas, ça risque de merder.Je vais supposer que
pidcontient une chaîne avec espace (ou séparateur contenue dans la variableIFS)Ensuite, il évalue la commande
catavec ses deux arguments :/proc/1et2/comm.ce que tu voulais faire :
Là,
bashévalue ensuitecatavec 1 argument/proc/1 2/comm.J'ai gardé ton exemple, qui n'est pas pertinent pour les espaces puisque les pid ne contiennent jamais d'espace. Néanmoins, lorsque l'on parse des éléments dans des répertoires cela arrive.
[^] # Re: Intéressant tes critiques sur le shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Carrément pas, le shell interprète à ma connaissance la substitution de commande avant les guillemets qu'elle contient. En tout cas, dash fait ainsi :
[^] # Re: Intéressant tes critiques sur le shell
Posté par Anthony Jaguenaud . Évalué à 2.
Tu as parfaitement raison. Pour tenter de reprendre le dessus, je dirais juste que ça embrouille un peu ta syntaxe avec plein de guillemet. ;-)
A ma décharge, j'étais au boulot sans machine Linux pour tester :-p
Et lire, c'est que j'ai proposé donne deux arguments…
Je te prie d'accepter mes plus plates excuses.
[^] # Re: Intéressant tes critiques sur le shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 04 septembre 2014 à 22:50.
Pas de problème. Je ne trouve pas ma syntaxe si difficile à lire à partir du moment où 1. on n'a pas de coloration déconnante, et 2. on considère bien que toute la commande à substituer entre les parenthèse est interprétée à part. Au contraire, je trouve ça plus lisible qu'avec des échappements, dont j'ai d'ailleurs peur qu'ils ne fonctionnent pas du tout (le shell verra une commande avec des \", c'est quoi ça ?).
Et pour ce qui est d'encadrer de guillemets inutilement, je pars du principe que l'utilisateur, ou celui qui modifiera mon script, pourra mettre les pires conneries dans mes variables, donc je blinde. Une bonne habitude à prendre d'ailleurs, consiste à forcer l'arrêt des options avant de donner un argument variable à une commande histoire de se prémunir des variables commençant par un tiret, genre :
[^] # Re: Intéressant tes critiques sur le shell
Posté par benoar . Évalué à 2.
Comme contre-exemple il y a git, dont la sortie « brute » (raw) est tout à fait lisible par un humain et est celle utilisée par l'outil. Dans la doc, la syntaxe est très bien définie, et surtout de manière stricte. On ne se rend même pas compte qu'en fait, git est un ensemble de script et d'exécutables écrits dans des langages différents (C, shell, perl) qui marchent bien ensemble parce que c'est écrit par des mecs qui savent bien coder.
[^] # Re: Intéressant tes critiques sur le shell
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Autre exemple, le format « orienté machine » d'indication de licence des différents fichiers qui compose un paquet Debian. D'une façon générale, c'est le cas de presque tous les formats descriptifs spécifiques à Debian utilisés dans les paquets d'ailleurs, je pense en particulier au format d'annotation des patchs. En fait, tous ces formats sont eux-mêmes basés sur un format conçu pour être lisible aussi bien par un humain que par une machine : le courrier électronique, enfin son en-tête évidemment.
[^] # Re: Intéressant tes critiques sur le shell
Posté par barmic . Évalué à 4.
Je comprends tout à fait ton point de vu. zsh a des solutions pour ça pour l'exemple que tu donne, il y a zstat.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Je suis sur le Q
Posté par skeespin (site web personnel) . Évalué à 3.
Tu es entrain de nous dire que systemd, c'est génial parce qu'on n'a pas de scripts shells à gérer mais tu développes des scripts pour tes sauvegardes.
Tu sais qu'il existe des softs (moins rebutant que ton script) qui font des sauvegardes ?
[^] # Re: Je suis sur le Q
Posté par deuzene (site web personnel) . Évalué à 5.
-1
Le monsieur nous dit dés le début aimer GNU/Linux pour sa possibilité de le bidouiller.
Il nous présente ses choix, que nous nous devons de respecter, les met en place et les commente.
(Peut-être pourrais-tu nous faire un journal de tes solutions de backup ?)
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: Je suis sur le Q
Posté par skeespin (site web personnel) . Évalué à -2.
Ce monsieur écrit "un script d’init Gentoo/OpenRC/Bash, ça fait pas envie"
et nous montre un script écrit avec les pieds (absence de commentaires/protection des arguments/nommage des variables/trop statique/…) Alors, je lui conseille d'aller les regarder, ça lui permettrait d'apprendre à coder proprement en shell.
Pourquoi je présenterais mes solutions à des gens qui sont tellement au-dessus de moi techniquement ?
# Backup sur le même disque ?
Posté par desktop.ready . Évalué à 4.
Il n'y a que moi que cela choque de voir quelqu'un mettre son backup sur le même disque ?
Je crois qu'il vaut mieux utiliser dans ton cas Btrfs send et receive sur un autre disque mais je ne sais pas où cela en est au niveau fiabilité…
[^] # Re: Backup sur le même disque ?
Posté par Sébastien Le Ray . Évalué à 4.
Évite de lire les petites lignes de la doc btrfs sur la fiabilité… ça fait peur :-) (je précise que ça ne m'empêche pas de l'utiliser, mais bon, de mémoire, les trucs à base de "oui oui on gère le RAID bon par contre si y a un disque qui s'en va et qui revient on le considère pas dirty" c'est un peu flippant).
J'ai eu aussi quelques freezes purs et simples du VFS sur des cas d'utilisation intensive (avec un mount -o compress et de gros fichiers d'image disque déjà en gzip, résolu en désactivant la compression uniquement sur ces fichiers).
[^] # Re: Backup sur le même disque ?
Posté par Spack . Évalué à 3.
Il n'y jamais dit que ses sauvegardes se font sur le même disque. Simplement qu'il monte quelque chose sur
/mnt.[^] # Re: Backup sur le même disque ?
Posté par desktop.ready . Évalué à 0.
C'est forcément le même filesystem (sinon le copy-on-write ne marche pas).
Même en supposant que c'est du RAID, cela ne me semble pas une pratique très saine de faire ainsi. Surtout si Btrfs n'est pas très fiable.
Je confirme avoir testé le RAID avec Btrfs en enlevant/ajoutant un disque pour voir ce qui se passait et le résultat fut… intéressant !
[^] # Re: Backup sur le même disque ?
Posté par Sébastien Le Ray . Évalué à 5.
Mmmm nan, tous les backups sont sur le même disque pour le CoW, mais tu peux très bien rsync depuis un autre disque (tu ne veux le CoW que d'une sauvegarde à l'autre, pas de la « prod » à la sauvegarde)
[^] # Re: Backup sur le même disque ?
Posté par desktop.ready . Évalué à 1.
Je crois que l'on dit la même chose, ou bien je suis fatigué…
Ce qui est décrit dans le journal c'est qu'il enregistre des snapshots sur le même filesystem (ok par forcément uniquement sur le même disque si c'est du RAID).
Pour ma part je dis que ce n'est pas très sain et qui si on parle de backup, il vaut mieux avoir cela sur un autre filesystem séparé (ou un autre disque).
Pour le coup c'est effectivement ce qu'il fait (voir plus bas).
[^] # Re: Backup sur le même disque ?
Posté par Pierre Roc . Évalué à 4.
Pour réexprimer les choses différemment et être sûr de s’être bien compris.
Ce que je dis, c’est que la prod et le backup sont sur deux disques différents. Et pour moi, c’est précisément ce comportement qui n’est pas sain (mais suffisant pour un usage non professionnel).
En effet, en faisant ainsi, on confond deux besoins bien différents. J’imagine un système ultime plutôt comme : (enfin, lorsque BTRFS sera considéré comme fiable pour un usage pro.)
Ainsi c’est le RAID qui a la responsabilité de protéger du vieillissement des disques durs ou d’une panne isolée, le BTRFS de faire du backup (ie. retrouver d’anciens fichiers, pas plus), la copie distante de protéger des grosses pannes (en cascade sur plusieurs disques par exemple) et/ou d’un avion qui s’écrase.
[^] # Re: Backup sur le même disque ?
Posté par Pierre Roc . Évalué à 3. Dernière modification le 04 septembre 2014 à 11:45.
Je distingue la sauvegarde, qui permet de retrouver des fichiers créés et supprimés dans le temps, et qui pourrait éventuellement se faire sur le même système de fichier ; de la protection contre les pannes matérielles : un autre disque en copie (ce que je fais en parallèle en l’occurrence), certains RAID, backup distant. Ce sont deux problématiques très différentes en réalité, et qui devraient en théorie faire appel à des solutions bien distinctes (ce que je ne respecte pas dans ma solution).
À priori ça copie le sous-volume tel quel. Dans mon système latest contient juste un “diff” par rapport au dernier instantanné créé. Avec send&receive j’ai le sentiment que tout sera réécrit à chaque fois.
Le CoW vaut uniquement pour les différents snapshots du backup, pas entre le système sauvegardé et la sauvegarde.
[^] # Re: Backup sur le même disque ?
Posté par desktop.ready . Évalué à 3.
Non cela n'envoie que la différence, voir ici :
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup
# Merci
Posté par barmic . Évalué à 4.
Je n'ai pas encore tout lu, mais tu viens de changer radicalement ma définition du bien et du mal.
Merci :D
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Merci
Posté par desktop.ready . Évalué à -1.
Si tu ne modifies pas le fichier après la copie, cp -al est mieux je pense (si tu fais des rsync, tu peux préserver les hardlinks).
# man
Posté par Patrick Lamaizière (site web personnel) . Évalué à 3.
C'est pas plutôt info sous GNU/Linux ?
(Je dis ça…)
les pixels au peuple !
# Tu es formidable
Posté par Marotte ⛧ . Évalué à 10. Dernière modification le 04 septembre 2014 à 14:14.
Ayant perdu trop de karma à envoyer chier tout le monde tu te fends d'un journal de très bonne qualité, pour rattraper ? Allez je déconne hein…
J'ai (presque) tout lu, j'ai juste une simple question :
Pourquoi ne pas utiliser
directement ?
[^] # Re: Tu es formidable
Posté par Pierre Roc . Évalué à 5.
C’est exécuté en tant que root à priori. Y’a moyen d’activer des services par utilisateurs j’ai l’impression, mais je n’ai pas du tout creuser.
[^] # Re: Tu es formidable
Posté par Sufflope (site web personnel) . Évalué à 5.
Dans la section Service de ton unité systemd tu as les directives User et Group. Mais dans ton cas, je crains qu'un paquet de commandes ne marchent pas avec ton utilisateur (mount, les trucs de snapshot de btrfs…).
# Shell
Posté par barmic . Évalué à 5.
Tout de même un peu expéditif comme affirmation, non ? Il y a des parties qui sont très touchy, mais la majorité des usages ne demande rien de bien violent.
Si, si il y a encore des gens. Il y en a même beaucoup. Depuis la création du shell la règle c'est "faites communiquer des outils". Si tu n'a pas compris ça tu n'a pas compris grand chose au shell. Si tu veux manipuler du binaire utilise (ou crée) un programme pour ça.
Elle est insuffisante pour des cas particulier qui demandent des interactions particulière comme le dessin (genre ce qu'on fait avec gimp ou plus simplement la navigation web).
Le shell est pensé pour utiliser ces outils, comme une bibliothèque standard. C'est comme si tu disais que le C++ est nul parce qu'il n'a pas beaucoup de conteneur (c'est sur qu'en ignorant la STL, il y a plus grand chose).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Correction
Posté par Pierre Roc . Évalué à 9. Dernière modification le 05 septembre 2014 à 12:37.
J’ai honte
ne suffit pas. En effet, au prochain redémarrage le
timerne sera pas activé. Il faut ajouter la ligne :(ce qui devrait ajouter un lien dans
/etc/systemd/system/timers.target.wants)Si un modérateur pouvait rajouter cette ligne, ce serait gentil, merci.
# btrfs et rsync
Posté par Sygne (site web personnel) . Évalué à 4.
J'ai du mal à comprendre l'intérêt d'ajouter les snapshots de btrfs aux sauvegardes de rsync : ça me semble redondant.
Pour quoi ne pas tout simplement faire un snapshot du répertoire à sauvegarder tous les jours, et utiliser send/receive pour dupliquer le tout sur un autre disque ?
[^] # Re: btrfs et rsync
Posté par Pierre Roc . Évalué à 4. Dernière modification le 05 septembre 2014 à 15:12.
Oui, je m’en suis rendu compte quand on m’a signalé l’existence d’un send/receive incrémental. Ce serait un poil plus complexe à mettre en œuvre pour ma part parce que mon /home est sur un SSD, donc limité en espace (je ne veux pas y mettre tous les snapshots de ma sauvegarde). Mais il y a moyen de se débarrasser complètement de rsync.
[^] # Re: btrfs et rsync
Posté par Sygne (site web personnel) . Évalué à 2.
Je comprends mieux maintenant, merci bien.
# Complément & commentaires
Posté par Pierre Roc . Évalué à 4.
Re,
J’utilise quelques programmes qui ont des tâches périodiques, typiquement r2e (abréviation de rss2email) et fetchmail. Je veux pouvoir les exécuter toutes les heures.
Je précise encore une fois que c’est du quick&dirty (ce qui me suffit très largement en l’occurrence).
Je crée les fichiers :
/etc/systemd/system/timers.target.wants/hourly.timerOn introduit un nouveau type d’unité
target, ça sert juste à pouvoir grouper des unités. Si je ne m’abuse, le démarrage (directivestartdesystemctl) d’une unitéxxx.targetva démarrer tout ce qui se trouve dans le dossierxxx.target.wants(d’ou cette correction avecenabledans mon commentaire un peu au-dessus, pour créer les liens symboliques qui vont bien)./etc/systemd/system/hourly.target/etc/systemd/system/fetchmail.service(Notez que fetchmail quitte avec le code de retour 1 lorsqu’il ne trouve aucun mails)
/etc/systemd/system/rss2email.servicePuis on lance :
Enjoy ! \o/ (en théorie ça devrait fonctionner 0:) )
———
Quelques commentaires (en rapport aux discussions).
Notez que fetchmail propose déjà tout ce qu’il faut pour des logs et pour se mettre en démon. Quant à rss2email, j’ai dû créer mon propre script shell pour gérer son réveil toutes les heures, ce qui nécessite de vérifier qu’il n’y a qu’une instance lancée, d’avoir un
dash->sleep 3600dans l’arbre des processus donc en mémoire, etc.Tout ceci conduit à une duplication du code monstrueuse, avec trente six milles (mauvaises, surtout quand c’est moi qui les pond) ré-implémentation des mêmes fonctionnalités : pouvoir écrire des log sur stdout, dans un fichier, et sur syslog, pouvoir forker, pouvoir passer en attente passive, etc.
On a sensiblement simplifié le procédé et mutualisé du code. C’est pourquoi il est inutile de comparer de manière brute le nombre de lignes de codes des
init: c’est insuffisant.Enfin, c’est (toujours) du quick&dirty, il y a moyen de faire les choses plus proprement, par exemple l’utilisateur a la possibilité de créer ses propres unités, en mode utilisateur, dans
~/.config/systemd/user(cfman systemd.unit).Et ici, la solution permet de supprimer un script shell (qui s’occupe de r2e), et de rendre fetchmail à sa vocation première (UNIX, KISS, tout ça…). De plus, il y a un malentendu sur le shell : c’est pour moi un puissant outil lorsqu’il est question de flexibilité, de souplesse, pour élaborer ses propres solutions à des besoins particuliers.
Le problème n’est pas le shell en soi, et évidemment, le shell est incontournable pour des scripts d’init personnalisés.
Le problème tient de ce que petit à petit le shell ait rempli des besoins pour lesquels il n’était pas optimal : j’estime que dès lors qu’un code doit être massivement distribué, le shell devient problématique (sauf à remplir des tâches subalternes).
C’est le cas des scripts d’init distribués usuellement avec les serveurs et démons qui tournent sur nos bécanes. Ce n’est plus du shell (sur une Gentoo qui utilise OpenRC on a
#!/sbin/runscript) mais un sous-ensemble rigide (il faut renseigner un certain nombre de fonctions–variables précises typiquement), mais aussi un ajout de fonctionnalités (toujours avec OpenRC, il y a des mot-clefs à utiliser).Sous Debian c’est pas mieux, puisqu’on utilise les commentaires pour remplir du code. Par exemple :
Entre mettre ce genre de données au début d’un script (peu lisibles qui plus est, le poids historique je suppose), ou dans un fichier séparé appelé “unité”. Je trouve carrément plus propre la seconde solution.
Bref, je trouve que dès qu’on essaie d’utiliser le shell pour autre chose que du script à usage particulier (personnel ou professionnel), on aboutit à des solutions que j’estime souvent bancales et peu rigoureuses. Le shell est un outil pour l’administrateur système, pas pour le distributeur, encore moins pour le développeur.
[^] # Re: Complément & commentaires
Posté par zul (site web personnel) . Évalué à 3.
Désolé de répéter la même chose, mais ça parait horriblement compliqué par rapport à cron (crontab -e en utilisateur). On va tourner en boucle sur les arguments sur le fait que cron ne gére pas finelement le problème de la multiple exécution du programme, mais si fetchmail mets plus d'une heure pour récupérer mes mails, y'a un sérieux problème.
[^] # Re: Complément & commentaires
Posté par Pierre Roc . Évalué à 2. Dernière modification le 05 septembre 2014 à 17:59.
1/ on peut activer sur des tas d’événements et gérer les dépendances, le timer n’est qu’un exemple. Pas seulement à d’autres services : y’a aussi des .device, des .mount, des .path, etc. Je commence à peine à l’utiliser alors je ne sais pas tout ce qu’il est possible de faire avec, mais dans tout les cas, c’est plus qu’avec cron. En fait c’est même pas comparable à cron.
2/ non les mails ne sont pas faits pour gérer des logs. WTF !!! (ça c’était pour la petite pique facile…)
3/ les deux premières étapes de mon exemple auraient pu (dû?) être faites par ma distribution (eg. avoir un hourly.target, daily.target, weekly.target, avec les dossiers .wants qui vont avec) : ne resterait plus à l’administrateur que de placer une unité par service dans le dossier qui va bien, un peu comme cron le fait je crois bien ; ou alors ajouter au WantedBy le target qui va bien et faire ensuite un
systemctl enable; ou encore faire à la main le lien symbolique que faitsystemctl enable.4/ Plus simple ou plus compliqué ? Question de goût : quand j’ai voulu faire du cron, j’avais trouvé ça chiant, si bien que j’avais abandonné et que je préférais largement faire un
while true;do $cmd;sleep $N;done.[^] # Re: Complément & commentaires
Posté par zul (site web personnel) . Évalué à 2.
On peut surement faire plein de trucs avec, je n'en doute pas. Moi je me contente de répondre à tes exemples, qui sont gérables facilement avec cron (un outil standard qui existe sur tous les unix du monde). Si tu veux montrer comment c'est bien, donne un exemple qui utilise des fonctionnalités "avancées" et montre comment ça correspond à un besoin réaliste.
C'est un peu un argument d'autorité. Ce n'est probablement pas un très bon outil pour un grand parc, mais pour quelques machines et un client mail un peu valable, c'est un outil de notification assez satisfaisant. Sur un gros domaine, tu va utiliser des outils de supervisions qui vont bien (et dans ce cas là, tu peux utiliser logger(1)).
Ce n'est objectivement pas un argument.
[^] # Re: Complément & commentaires
Posté par Pierre Roc . Évalué à 10.
Ben écoutez, continuez à utiliser cron, je ne vous l’empêche pas. Je continue avec systemd, parce que je ne compte pas m’arrêter là.
Mon but à terme est de le mettre sur une RaspberryPi (bon, ça craint un peu parce qu’il y a des dépendances noyau qui sautent avec l’architecture ARM, on verra…). Et je note que j’arrive à réduire la consommation mémoire, au passage : au dernier redémarrage j’étais à 31 Mo. C’est pas que Systemd, c’est le fait de passer à dash, c’est le fait de faire sauter au maximum tous les shells ouverts pour rien, etc. etc. Pouvoir virer cron, c’est un gain net. Ça s’inscrit dans le cadre d’un projet plus vaste ou, à priori, systemd a d’énorme avantages.
La je viens de me dire que getty ne devrait démarrer qu’en cas de fail de slim (mon login manager graphique). Bon ben voilà, y’a un
OnFailure=. Faut que je creuse un peu. Pour la raspberry ce sera cool d’ouvrir le serveur SSH, et de basculer sur slim ou getty qu’en cas de problème, et de recouper openSSH assez rapidement pour laisser la place au serveur HTTP (par exemple).D’un autre côté, j’ai tout un tas de points de montages, dont dépendent mes sauvegardes, mes photographies (les RAW ne peuvent pas être stockés sur mon ridicule SSD), etc. à l’heure actuelle je monte tout à la main et si ça n’est pas monté, ma sauvegarde ou le chargement des photos depuis mon appareil ne se font pas. Systemd devrait pouvoir gérer ça, chercher à monter les points nécessaires en fonction des dépendances, etc. Je vais petit à petit configurer tout le bazar.
Alors oui c’est faisable sans systemd. M’en fous. systemd offre un point d’entrée unique avec des fichiers de configuration homogènes pour gérer tout ça. Vous trouvez ça complexe, personnellement je l’ai trouvé simple (j’ai parcouru à l’arrache quelques tutos sur le web, puis ai attaqué les man pour compléter sur des points précis), j’en ai déduit que c’est affaire de goût finalement…
Mon journal n’avait pas vocation à être exhaustif, à présenter un cas extrêmement complexe ni rien : je le dis dès le premier paragraphe. Ce sont des exemples d’utilisation sans prétention. Pour s’initier à systemd et en comprendre l’intérêt (il y a l’exemple avec udev tout de même, que je trouve plutôt classe pour ma part, collez-y une interface openGL là dessus et vous vous la jouez façon Abby dans NCIS 8) ) car, pour le reste c’est-à-dire une fois qu’on a compris le principe, la doc de référence ce sont les pages man.
Et en retour j’ai appris plein de petits trucs, sans avoir eu à chercher 0:-) . Et ça va me servir…
[^] # Re: Complément & commentaires
Posté par Misc (site web personnel) . Évalué à 2.
Ou juste utiliser cronie, qui loggue dans syslog si y a pas de MTA ( ce qui me semble pas déconnant d'un point de vue de l'unification, cad "tout va au même endroit pour les logs" ). C'est aussi un des points de journald, tu as tout dans le journal, tu as donc un endroit à traiter. Ensuite, tu rajoutes les notifications sur la base des entrées consolidés, plutôt que d'avoir la notif pour cron mais pas pour le reste, etc.
[^] # Re: Complément & commentaires
Posté par Pierre Roc . Évalué à 4.
Encore une correction, je cherche à me prendre la tête et pour rien en plus !
Il faut remplacer
par
[^] # Re: Complément & commentaires
Posté par Pierre Roc . Évalué à 5.
Et comme c’est pas suffisant :
Dans
hourly.target(dans la section[Unit]toujours)En fait, ce qui se passait, c’est que
hourly.targetrestait actif (visible viasystemctl list-units). Du couphourly.timerne jugeait pas utile de le réactiver toutes les heures. Avec l’ajout de l’option, on s’assure que hourly.target se désactive de lui-même.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.