Pjmail
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.
L‘envoi de pièce jointe par mail est aisée. Cependant, chaque fournisseur de messagerie limite la taille de ces envois (minimum 5 Go parfois 20 Go). Le destinataire peut ne pas recevoir la ou les PJ. Enfin, l’envoi suppose d’avoir une connexion Internet montante conséquente pour ne pas trop attendre attendre…
Le dépôt de PJ sur le NAS dans un sous dossier de web, permet d’envoyer un lien vers l’archive zip souhaitée. On contourne les problématiques citées en amont et on assure ainsi envoi et réception du messages avec sa PJ.
On évite ainsi, le recours à des CLOUDs externes dont on ne maîtrise pas les degrés de confidentialités.
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.
Pjamil est un script bash composé :
- du script – Pjmail
- 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 Menage)
Prérequis :
- Paquet PHP installé (si PhotoStation et/ou WebStation présents, alors PHP l’est aussi)
- Notification des mails paramètrée dans le panneau de configuration
- Le paquet webstation doit être installé pour avoir le dossier « spécial » web et l’accès externe via url à ce dossier.
On installe le script et son fichier de paramètrage dans un dossier du NAS.
Ce dossier n’est pas le dossier visé pour le « réceptacle des fichiers à archiver ».
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/pjmail
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 (existence du NDD pour l’accès au NAS…), 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 : REP_DATA
– Dossier d’exécution du programme
– Format : /volume1/homes/moi/monscript
– Ligne 25
– Un contrôle est fait sur la non appartenance à un dossier racine du NAS
#—————————————————-
– Variable : CARGO & PJMAIL
– Dossier de mise à disposition et de dépôt pour archive ZIP
– Format : /volume1/web/depot/cargo
– Format : /volume1/web/depot/PJMAIL
– Ligne 35 & 37
– Contrôle d’existence effectué + non appartenance à un dossier racine du NAS pour le dossier de dépôt.
A noter : le dossier de mise à disposition de la PJ doit impérativement dépendre du dossier web.
#—————————————————-
– Variable : ADDR_WEB
– Adresse NDD du NAS et du dossier de mise à disposition.
– Format : https://monnas.com/depot/cargo
– Ligne 65
– Un contrôle est fait sur l’existence du dossier et de l’adresse web.
#—————————————————-
– Variables : email
– Destinataire et expéditeur (suppose que le paramètrage d’envoi soit fait par avance –)
– Ligne 55 et 65
– format email
– Contrôle de cohérence réalisé
#—————————————————-
– Variable : CRYPT
– Format : alphanumérique
– Ligne : 75
– Si vide, alors pas de chiffrage.
A noter : lors de la 1ère exécution le mot de passe est chiffré dans le fichier de paramétrage. (paramètre en ligne 74 passe de V à C)
#—————————————————-
– Variable DPJ
– Information sur le délai de mise à disposition de la PJ
– Valeur numérique pour un nombre de jours.
– Ligne 85
– si vide ou nul pas de mention dans le mail envoyé.
#—————————————————-
A noter : Le dossier ‘dépot‘ peut se trouver dans un sous dossier du NAS qui doit cependant être accessible pour l’utilisateur. C’est le dossier vers lequel on copie le(s) fichier(s) et/ou dossier(s) qui sont archivés en une PJ….ZIP, archive ZIP déplacée ensuite dans le dossier de mise à disposition (sous dossier de web du NAS).
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
– TR_smtp.txt
– Vérification des fichiers de paramétrage d’envoi de mail.
– TR_message.txt
– Le Message constituant le mail envoyé (ou pas mais qui est toujours généré).
Est généré dans le sous-dossier web (de mise à disposition) outre la PJ archive ZIP, le fichier suivant :
– PJaaaammjjhhmmss_log.txt
– Le(s) fichier(s) / dossier(s) contenu(s) dans l’archive compressée.
Démo
Le paquet
Composé de 3 fichiers
- Pjmail le script Bash – V1.0
- Param.txt le fichier de paramètrage à amender
- Pjmail.pdf la notice complémentaire
FAQ
Les principales questions/réponses collectées sur le sujet et/ou les éventuelles évolutions.
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 !
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.
Le script déplace/supprime des fichiers.
Par sécurité les dossiers Volume_n (où n peut selon le type de NAS varier de 1 à 8…) et de 1er niveau sur un NAS Synology (souvent dossiers partagés) ne sont pas autorisés.
Seul un niveau comme suit /volume_n/dossier_niv1/dossier_autorisé est possible.
La sécurité est ainsi assurée notamment en ce qui concerne le dossier HomeS. Une vérification d’existence du dossier en sus de son autorisation est réalisée à la lecture du fichier de paramètrage.
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).
La notification par mail s’appuie sur PHP et les paramètres de notification du NAS.
PHP est un paquet installé sous DSM avec PhotoStation et/ou WebStation mais on peut l’ajouter manuellement si nécessaire.
Aucune personnalisation supplémentaire n’est requise sur ce paquet.
La notification par mail se réalise dans le panneau de configuration en tant qu’administrateur et permet de s’assurer (par l’envoi d’un mail de test) que les paramètres sont correctement renseignés.
Ce sont les prérequis pour que l’alerte par mail puisse être opérationnelle avec ce script.
Pas question d’ouvrir le débat entre « j’ai le droit de le faire » versus « ça ne se fait pas ».
Le postulat pour mes scripts, est de pouvoir traiter les sous-dossiers et/ou fichiers présents avec ou sans espace.
(exception faite du dossier de surveillance principal qui ne doit de ne pas avoir d’espace – contrôle réalisé -)
Au delà à chacun son école…
Personnellement je m’interdis les espaces et les caractères spéciaux dans les noms des fichiers et dossiers, un peu comme la méthode préconisée par et l’université de Lausanne par exemple.
Le dossier web et l’url vers le dossier web
Le dossier web est un dossier partagé par le NAS dès que le paquet WebStation est installé sur le NAS. Dès lors, le dossier web est accessible via le protocole http. Le dossier web représente la racine de cet accès et c’est pour cette raison qu’une adresse vers une ressource stockée dans ce dossier ne mentionne jamais le dossier web lui même.
Ainsi, un sous dossier cargo situé sur le dossier web est accessible via le protocole http via l’adresse http://IP/cargo ou http://NDD/cargo.
Conclusion
Le paramètre complet pour déposer des fichiers/répertoire contient le dossier web (/volume1/web/cargo) mais l’adresse url non (http://NDD/cargo)
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.
Le délai de mise à disposition est facultatif. Sans valeur ou à blanc dans le fichier param.txt, aucune mention de durabilité de mise à disposition de la PJ n’est mentionnée.
La valeur est à associer en cohérence avec l’utilisation éventuelle d’un autre script maison : Menage. Ce dernier se propose de supprimer le contenu d’un dossier de fichiers/dossier dont la date de modification dépasse x jours.
J’utilise les deux : tous les 10 jours mon dossier cargo de web où sont stockées chez moi les PJs est scruté et nettoyé des vieilleries qui peuvent trainer.
Trois dossiers à considérer :
- le dossier d’exécution : doit être à un niveau 2 du NAS dans un dossier quelconque, pas de nécessité d’accès pour l’utilisateur lambda (idéalement home d’un admin)
- le dossier réceptacle : doit être à un niveau 2 du NAS sr un dossier accessible en écriture par l’utilisateur. Lieu du dépôt du/des fichier(s) à compresser.
- le dossier de mise à disposition : doit être ç un niveau 2 du dossier web du NAS, pas de nécessité d’accès pour l’utilisateur. La particularité du dossier web permet un accès via url depuis l’extérieur.
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.
Cool merci.
Je n’aime pas trop déposer des fichiers sur des serveurs dont je n’ai pas la maîtrise et cette solution est pour moi tip top.
Facile à mettre en place (je suis une quiche en cde et autres lignes de commande), ça fonctionne très bien.
A noter la 1ere fois le mail s’est trouvé dans les spams… Mais désormais il arrive à bon port.
Je suis avec un PC sous Windows 10 et Thunderbird pour le client mail.
Une remarque : lorsqu’on met en place la programmation, toutes les minutes, le décompte démarre par défaut au lendemain…