Wallog
Indice NDT
(D)ifficulté : Simple, Moyenne, Complexe.
(T)emps estimé pour la réalisation.
| Utilisateur | Technicien | Expert |
| Simple | Moyenne | Complexe |
| – d’une heure | + de 5 heures | 12 heures et + |
OcM
Contexte de la réalisation.
Modalité de l’éxécution.
Changer le fond d’écran de la page de connexion d’un NAS Synology sous DSM 6 est l’objectif de l’automatisation « maison » Wallog. S’appuyant sur un fichier de paramètrage pour son installation, il remplace le papier peint initial par défaut par un autre chaque jour. Chaque année le fichier de journalisation LOG.txt est remis à zéro.
C-I-P-E
Dans les onglets suivants on retrouve les éléments pour le (C)ontenu son (I)nstallation, son (P)aramètrage et enfin son (E)xploitation.
Wallog est un script bash composé :
- du script – Wallog
- du fichier de paramètrage – Param.txt
Le script s’appuie sur le fichier de paramètrage pour plus facilement installer et adapter le script bash à tous et dans toutes situations. (pas besoin d’un accès telnet/ssh au NAS pour installer, paramètrer et exploiter Wallog)
On installe le script et son fichier de paramètrage dans un dossier du NAS.
Le dossier d’exécution peut différer du dossier contenant les images.
Idéalement un dossier personnel type admin ou utilisateur (dans homes/user)
Une fois déposé et paramétré .. on y accède plus.
exemple :
un dossier spécifique dans le dossier run d’admin donc un chemin global qui peut être :
/volume1/homes/admin/run/wallog
C’est dans le fichier param.txt que cela se passe !
Comme son nom l’entend, il s’agit d’un fichier texte modifiable avec n’importe quel éditeur. (on évitera word…)
ATTENTION : les paramètres sont inscrits à des numéros de ligne précis. Il faut éviter les retours chariots.Que se passe-t-il si le paramètre n’est pas trouvé ou incomplet, incohérent ou à la ligne du dessous…
Un contrôle des paramètres est réalisé tant sur leur cohérence, comme aussi l’existence du dossier visé. Le traitement ne se poursuit QUE si le fichier de paramètrage est correctement renseigné. Dans le cas contraire, le fichier de trace TR_param.txt généré dans le dossier d’exécution renseigne sur les informations manquantes et/ou erronées.
Les Paramètres
Variable : DOSS_IMG
– Dossier source des images
– Format : /volume1/web/src/fond/
– Ligne 15
– Un contrôle est fait sur la non appartenance à un dossier racine du NAS et sa présence effective.
#—————————————————-
– Variable : REP_DATA
– Dossier d’exécution du programme
– Format : /volume1/homes/moi/monscript
– Ligne 35
– Un contrôle est fait sur la non appartenance à un dossier racine du NAS et sa présence effective.
#—————————————————-
– Variable : BIP_ON
– Valeur numérique 1 ou 0 (1 ‘bip’ en fin de traitement sinon NAS muet)
– Ligne 35
– Contrôle de cohérence de la donnée
#—————————————————-
A noter : La structure de l’arborescence du dossier Wallog, notamment le sous dossier img est à respecter pour un bon fonctionnement du bash. Ie c’est chaque semaine que le script cherche dans la semaine xx le jour xx et le fond d’écran associé.
Afin d’exécuter le script on l’ajoute au planificateur des tâches.
Les traces
Sont générées dans le dossier d’exécution les fichiers suivants :
– F_init
– Trace la bonne installation (paramètrage OK date d’initialisation correcte)
– Si absent il est généré à la 1ere exécution.
– TR_param.txt
– Trace la bonne lecture et interprétation des paramètres de param.txt
– Si absent est généré à chaque exécution (si changement de paramètrage param.txt)
– Permet d’investiguer si une erreur est trouvée dans le fichier de paramètrage
– LOG.txt
– Le fichier de journalisation d’exécution. Renseigne sur son initialisation, sa réinitialisation en début d’année et la quotidienne numéro de semaine et jour de la semaine concernée.
- Wallog le script Bash – V4
- Param.txt le fichier de paramètrage à amender
- Wallog pdf la notice complémentaire
- le dossier wallog et ses fonds
FAQ
Les principales questions/réponses collectées sur le sujet et/ou les éventuelles évolutions.
Oui on peut personnaliser la source. Il faut respecter la nomenclature (arborescence et noms des fichiers).
Pour personnaliser il suffit de :
– remplacer un couple fond d’écran et sa miniature
– respecter si possible un ratio fichier image comme suit :
FOND : 1920×1200 en 72 dpi, adapter compression jpeg pour faire un fichier entre 100 et 600 ko
MINIATURE : 1160×100 en 72 dpi, adapter compression jpeg pour faire un fichier entre 3 et 4 ko
C’est possible mais pour une année… Le calendrier grégorien est ainsi fait que les jours ne sont pas les mêmes chaque année. Alternative, repérer pour l’année en question la semaine et le jour concerné… Où ajouter un test supplémentaire spécifique à cette date dans le script.
Par défaut c’est le fond d’écran n°1 qui est changé. Cela laisse la liberté à chacun de choisir manuellement un autre fond d’écran.
A chaque changement, un autre rang est pris. Ainsi, pour un rang 2 à 6 sélectionné, alors wallog est opérationnel mais ce n’est pas le fond qui est affiché (puisque lui c’est le n°1).
Pour revenir à un mode complet il faut, manuellement, choisir le wallpaper du rang 1.
Ne pas ajouter ou supprimer des lignes dans un fichier est plus facile à faire lorsqu’on voit les numéros des lignes.
Il existe différents logiciels permettant de le faire comme par exemple :
- Ultraedit sous windows (existe aussi sous macOS)
- TextMate (mon préféré) sous macOS
- et sur le NAS le paquet Éditeur de texte fait le job
(cf FAQ « Modifier un fichier Texte avec le NAS »)
Il en existe plein d’autres sur internet !
Depuis la 1ère version Wallog en Nov 2014, des évolutions sont faites et à ce jour, la V4 permet de se passer totalement d’un accès telnet et/ou ssh au NAS. Il suffit de copier/coller le fichier Wallog et son fichier de paramètrage – param.txt – sur un dossier du NAS, puis de le pointer comme une tâche dans le planificateur pour qu’il soit opérationnel. [ le dossier wallog et ses images aussi ]
Bien sur il faut adapter le fichier param.txt selon sa situation personnelle (chemin où se trouve le dossier wallog et ses images)
Le script ne réalise pas de changement sur les éléments constituant l’environnement logiciel du NAS Synology. Il automatise une action qui peut être faite manuellement par l’utilisateur.
En conséquence, le script ne représente ni un risque de sécurité ni une atteinte aux éléments techniques et juridiques du NAS.
Dans le fichier de paramètrage on doit renseigner les chemins complets selon les volumes existants sur le NAS. Ainsi un dossier cargo dans le dossier partagé web est en fait : /volume_n (où est n est le numéro du volume)/web/cargo.
A partir de FileStation on obtient dans les propriétés du dossier ce chemin complet comme sur l’image à gauche.
Le script représente une automatisation qui ne s’appuie pas sur des fonctions de DSM. Ainsi , sauf changement d’OS et/ou de suppression de fonctions intégrées bas niveau , une MAJ du NAS n’obère pas le traitement du script.
Pour pouvoir modifier un fichier texte directement depuis File Station sous DSM sur un NAS Synology, il faut ajouter le paquet Editeur de Texte (section utilitaire dans l’ajout des paquets).
Par la suite sous File Station, bouton droit sur un fichier texte permet son ouverture pour modification.
Pratique on peut ajouter les n° des lignes et ainsi mieux gérer les modifications dans le fichier de paramètrage.
Attention à la page de code (en général il faut une page de code UTF-8).
Le dossier homes sur un NAS Synology contient le home de chaque utilisateur du NAS. Sauf à se connecter avec un utilisateur du groupe Administrator (ou d’en avoir expressément ajouter les droits), un utilisateur ne voit QUE son home et jamais le dossier homes contenant les dossiers des autres utilisateurs.
L’exécution d’un script « maison » est réalisée avec des droits d’administrateurs. (dans le planificateur des tâches).
C’est pourquoi, sauf sur site distant, pointer un dossier home d’un utilisateur dans le fichier de paramètrage, param.txt, doit être écrit en tenant compte de l’arborescence complète.
Pour le paramètrage en local, la syntaxe « arborescence complète » se présente ainsi :
→ Exemple local : utilisateur toto son home en local est sur le /volumex(x=1 à n selon le nombre de volume présent)/homes/toto.
Dans le cadre de SyncDoss, la connexion au site distant ne se réalise pas avec les mêmes prérogatives (et c’est normal).
→ Exemple distant : pour mon utilisateur toto son home en local sur le site distant est sur le /home/toto.
Cette fois-ci , je me connecte en tant que toto, mon home dans le fichier de paramétrage, param.txt, est à écrire avec l’arborescence simplifiée.
Un shell est un programme qui fait office d’interface entre vous et l’ordinateur sous la forme d’un interpréteur de commandes.
Le Shell est le programme qui fait office entre nous et l’ordinateur. C’est l’intrèpréteur de commandes de base sous le système d’exploitation. Sous linux/Unix il en existe plusieurs :
- Almquist shell (ash) : écrit en remplacement du Bourne Shell, sous licence BSD ; souvent utilisé dans des environnements aux ressources limitées. Les sh de FreeBSD, NetBSD (et leurs dérivés) sont basés sur des cendres qui ont été améliorées pour être conformes à POSIX. (présent sur le NAS Synology)
- Bourne Shell (sh) : Le shell Bourne était le shell par défaut de la version 7 d’Unix. De nombreux systèmes de type Unix continuent à avoir /bin/sh – qui est l’interpréteur de commandes Bourne, ou un lien (symbolique ou en dur) vers un interpréteur de commandes compatible. (par défaut sur le NAS Synology)
- Bourne-Again shell (bash) : écrit dans le cadre du projet GNU pour fournir un sur-ensemble de fonctionnalités du Bourne Shell. Ce shell est souvent pré-installé et est le shell interactif par défaut pour les utilisateurs sur la plupart des systèmes Linux et macOS (jusqu’à Catalina macOS 10.15)
- C shell (csh) : Shell Unix créée par Bill Joy alors qu’il était étudiant à l’Université de Californie, Berkeley, à la fin des années 1970. Il a été largement distribué, à commencer par la version 2BSD de la Berkeley Software Distribution (BSD) pour la première fois en 1978.
- Debian Almquist shell (dash) : un remplacement moderne du shell ash dans Debian et Ubuntu
- Korn shell (ksh) : écrit par David Korn à partir des sources du shell Bourne alors qu’il travaillait aux Bell Labs
- Public domain Korn shell (pdksh) : Shell Unix qui a été développé par David Korn aux Bell Labs au début des années 1980 et annoncé sur USENIX le 14 juillet 1983. Le développement initial était basé sur le code source du shell Bourne.
- MirBSD Korn shell (mksh): un descendant du ksh d’OpenBSD et de pdksh, développé dans le cadre de MirOS BSD
- TENEX Shell (tcsh): Shell Unix basé sur et compatible avec csh. Il s’agit essentiellement d’un interpréteur de commandes C avec une complétion en ligne de commande programmable, une édition en ligne de commande et quelques autres fonctionnalités. Il s’agit de l’interpréteur de commandes racine natif pour les systèmes basés sur BSD comme FreeBSD.
- Z shell (zsh): une coquille relativement moderne qui est rétrocompatible avec le bash. C’est le shell par défaut dans macOS depuis la version 10.15 de Catalina . Présent aussi sur le NAs Synology DSM6.
Quel shell ai-je par défaut ?
D’autres SHELL présents ?
Changer le shell par défaut ?
Sortir du mode Terminal et se reconnecter pour constater que désormais c’est ce shell qui est appliqué par défaut.
Sauf changement dans la structure de la gestion des fonds d’écran par Synlogy, Wallog fonctionne suite à une MAJ sans action particulière.
Dans le « pire » des cas, l’affichage du fond « personnalisé » n’est pas opérationnel c’est tout.
Cool, pas essentiel donc indispensable à ce que l’on dit !
Bref j’aime bien être surpris à chaque connexion à mon NAS.
Belle collection.
Merci