affa: prejob et postjobcommand

[arnaud056]

Bonsoir,
il faut que je modifie mon "système" de sauvegardes basé sur affa.
Pour ce faire, je souhaite effectuer le démarrage et le montage d'une machine par un prejob.
Une fois la première sauvegarde effectuée, je souhaite lancer la suivante par un postjob et ainsi de suite jusqu'à ce que toutes les sauvegardes soient effectuées.
Et c'est ce qui bloque en ce moment!
Voila un extrait du job.pl de la première sauvegarde:

Code: Tout sélectionner

'postJobCommand'=>'affa --run KCN_dd_usb', # full path to local program/script
'preJobCommand'=>'./root/script_allumage_montages_KCN', # full path to local program/script


Mon script "script_allumage_montages_KCN" fonctionne. Depuis la console, je le lance par un "./" ou par un "bash le _script".
Ce script est très simple:

Code: Tout sélectionner

#!/bin/bash

echo "WOL sur KCN"
ether-wake 00:19:66:C1:CD:87

echo "attendre 2 minutes"
sleep 2m


echo "monter la partition de sauvegarde dans KCN"
ssh -i .ssh/root@192.168.2.103.rsa root@192.168.2.103 mount -t ext3 /dev/sda9 /mnt/sda9


#### monter les partages NFS###

echo "monter le répertore de sauvegardes de KCN"
mount 192.168.2.103:/mnt/sda9 /mnt/KCN

echo "monter le /home de KCN"
mount 192.168.2.103:/home /mnt/homes/KCN


exit 0

Quand je lance la sauvegarde, j'obtiens alors un message d'erreur contenant les lignes suivantes:

Code: Tout sélectionner

Executing_preJobCommand_./root/script_allumage_montages_KCN
Error_1310_in_'main':_Couldn't_execute_preJobCommand_./root/script_allumage_montages_KCN
Executing_postJobCommand_affa_--run_KCN_dd_usb
Error_1319_in_'main':_Couldn't_execute_postJobCommand_affa_--run_KCN_dd_usb

Je pense donc avoir une erreur de syntaxe dans mon job.pl, mais je n'arrive pas à la corriger

Où est mon erreur?

Merci.
@+
Arnaud

EDIT: j'avais oublié: j'ai jeté un coup d'œil dans les exemples sous /usr/lib/affa et cela ne m'a pas apporté grand chose... J'ai simplement constaté que c'est écrit en perl, langage que je ne connais point Quelque part sur ce forum http://forums.ixus.net/viewtopic.php?f=19&t=43744&start=15 , j'ai lu que les scripts bash (comme le mien) sont acceptés en pré ou postjob --> il n'y a apparemment pas l'obligation d'utiliser le perl

[arnaud056]

je pense avoir trouvé une erreur: il faut enlever le point de

Code: Tout sélectionner

'preJobCommand'=>'./root/script_allumage_montages_KCN', # full path to local program/script

-->

Code: Tout sélectionner

'preJobCommand'=>'/root/script_allumage_montages_KCN', # full path to local program/script

et le prejob se lance...

Pour le postjob il me faudrait le chemin complet de la commande affa. Je ne l'ai pas encore trouvé.
Puis-je alors mettre les paramètres "--run KCN_dd_usb" derrière? Ou faut-il que je crée un script "affa --run KCN_dd_usb"?

Merci
@+
Arnaud

[Franck78]

je pense avoir trouvé une erreur: il faut enlever le point

Dis comme ça, ca donne l'impression de ne pas comprendre l'erreur ! Chemin relatif (.) ou chemin absolu, c'est le basique du système de fichier

il me faudrait le chemin complet de la commande affa

which affa
ou
find / -iname affa

ssh -i .ssh/root@192.168.2.103.rsa

même remarque absolu relatif, sans un 'cd' avant c'est assez audacieux (ou aléatoire) ... si appellé par autre chose que toi même.

bye

[jibe]

Salut,

Désolé d'arriver après la bagarre... Franck t'a à peu près tout dit je pense...

Je pense que tu as déjà trouvé affa. En fait, sur SME, la plupart des scripts sont installés en /sbin/e-smith/. C'est le cas pour affa.

Pour ce qui est du langage de script, effectivement bash convient très bien. Affa étant écrit en perl, il est assez logique qu'ils aient tendance à employer perl pour tous leurs scripts, mais cela n'en fait pas une obligation.

[arnaud056]

Bonsoir,

je pense avoir trouvé une erreur: il faut enlever le point

Dis comme ça, ca donne l'impression de ne pas comprendre l'erreur ! Chemin relatif (.) ou chemin absolu, c'est le basique du système de fichier

oui et non.....
Je n'ai simplement pas su interpréter "indiquer le chemin complet de la commande" J'ai cherché des complications et ai voulu lancer le script (./le_script) tout en indiquant le chemin complet...

which affa

merci, c'est exactement ce dont j'avais besoin.

ssh -i .ssh/root@192.168.2.103.rsa


même remarque absolu relatif, sans un 'cd' avant c'est assez audacieux (ou aléatoire) ... si appellé par autre chose que toi même.

Bien vu Je m'en suis aperçu pendant que tu écrivais ces lignes et cela m'a coûté 20 minutes d'interrogations et de recherches. Je ne l'ai pas remarqué avant car le script était lancé manuellement à partir de /root. Mais quand affa a essayé de lancer le script, la clé n'a plus été trouvée ..... Me voici maintenant plus savant!

Concernant les scripts: je suis donc désormais capable de lancer un script en pré ou postjob. Mais je n'ai pas réussi à lancer de sauvegarde affa directement en pré ou postjob:

Code: Tout sélectionner

'postJobCommand'=>'/sbin/e-smith/affa --run la_sauvegarde'

plante et crée une erreur. Est-ce normal ou suis-je encore trop "intelligent"

Pour contourner ceci, j'ai écrit un script par sauvegarde (script avec affa --run la_sauvegarde en seule commande)...

Maintenant mon système fonctionne, même s'il a fallu que je dévie de mon concept prévu: combiner 6 sauvegardes affa les unes dans les autres avec les pré et postjobs, les montages etc... donne tout simplement mal à la tête , est très inflexible dans les cas où l'on souhaite lancer une sauvegarde précise en manuel, et en plus avec les 6 scripts "affa --run"
--> j'ai préféré un script unique de sauvegarde qui fait les montages, lance les 6 affa's et démonte. C'est beaucoup plus simple, clair et flexible.

Une question subsiste cependant: le lancement programmé de ce script.
J'ai essayé directement dans cron (http://doc.ubuntu-fr.org/cron) mais ai vite laissé tomber: je ne sais que faire de "crontab -e" et dans le fichier /etc/crontab est indiqué de ne pas modifier le fichier.
L'idée m'est donc venue de créer un job affa bidon qui en fait ne fait rien d'autre que de lancer mon joli script de sauvegardes en postjob. Ce job d'amorçage est configuré pour fonctionner à une heure précise (TimeSchedule).
J'ai effectué "affa --make-cronjobs" pour entrer ce job dans cron. Mais le fichier /etc/crontab n'a pas l'air d'avoir été modifié (je m'attendais à trouver quelque chose en rapport avec affa dedans. Est-ce normal?

Désolé d'arriver après la bagarre...

il n'y a pas de quoi. Et bagarre il n'y a même pas eu...

@+
Arnaud

[jibe]

Salut,

Et bagarre il n'y a même pas eu...

C'était une façon de parler ! Tu t'es bien battu avec tes scripts et tes chemins

Code: Tout sélectionner

'postJobCommand'=>'/sbin/e-smith/affa --run la_sauvegarde'

plante et crée une erreur. Est-ce normal ou suis-je encore trop "intelligent"

Pour contourner ceci, j'ai écrit un script par sauvegarde (script avec affa --run la_sauvegarde en seule commande)...

Effectivement, je ne crois pas qu'on puisse mettre des arguments en pré ou post-job. En tous cas, je ne le fais jamais, m'étonnerait que ce ne soit pas parce que je sais (lecture ? expérience ? Je ne me souviens pas) que ça ne fonctionne pas...

ai voulu lancer le script (./le_script) tout en indiquant le chemin complet...

Pourquoi lance-t-on ./le_script ? Parce que sous linux, contrairement à MSDOS, le répertoire courant n'est pas pris en compte pour les commandes : seul le path l'est. Ainsi, si tu lances simplement le_script, le système ira le chercher selon le path sans "voir" qu'il est juste là, dans le chemin courant. Le ./ ne fait pas partie de la commande, mais est simplement l'indication du répertoire où la trouver !

Dans le cas d'affa et de toutes les commandes "spécifiques SME", je crois que maintenant (ce n'était pas le cas dans les anciennes versions) /sbin/e-smith/ fait partie du path par défaut. Si je ne me trompe pas, il est donc inutile de le préciser.

Mais le fichier /etc/crontab n'a pas l'air d'avoir été modifié (je m'attendais à trouver quelque chose en rapport avec affa dedans. Est-ce normal?

Oui, normal. Je n'ai pas le temps (et un peu la flemme ) de rechercher, mais c'est fait de manière un peu surprenante, ce qui fait qu'on ne trouve pas ça là où on s'y attend. Mais c'est bien fait de telle sorte que ça fonctionne, et d'ailleurs ça fonctionne bien !

combiner 6 sauvegardes affa les unes dans les autres avec les pré et postjobs, les montages etc... donne tout simplement mal à la tête , est très inflexible dans les cas où l'on souhaite lancer une sauvegarde précise en manuel, et en plus avec les 6 scripts "affa --run"

Oui ! A la lecture de ton post, j'ai bien trouvée l'idée osée et ça ne me plaisait pas trop sans que j'aie bien réfléchi pourquoi. Je me suis dit qu'après tout, ça avait un certain côté logique. Mais j'aurais mieux fait de suivre mon instinct et te le déconseiller : je ne suis pas du tout étonné de ton constat. Je n'avais pas pensé au fait que, le lancement de la sauvegarde suivante étant fait dans le job, il s'effectue quelque soit la manière dont la sauvegarde est lancée !

Ton idée de tout mettre dans un script lancé en post-job d'un job vide ne me plait guère... Pourquoi ne pas lancer automatiquement chaque job avec assez de décalage entre chaque pour éviter les chevauchements ? Quitte à faire un lock de synchro un peu comme j'ai fait les lock d'arrêt de mon NAS (je crois que je t'avais envoyé mes scripts. Si ce n'est pas le cas et que tu ne voies pas comment faire, just ask )

[arnaud056]

Salut,

1) merci pour l'explication concernant le ./le_script

2) ok pour le /etc/crontab . Je vais voir ce soir si ça fonctionne.......

3) pour mon concept de sauvegarde, je pense qu'il est nécessaire que je rappelle le contexte général:
- le but de la manip' est de réaliser les sauvegardes d'un serveur sme, d'un client fixe et d'un client portable. Jusqu'ici, chaque machine était sauvegardée sur les 2 autres. L'ordre de sauvegarde était lancé du portable lors de l'extinction de celui-ci. Ceci a bien fonctionné. Malheureusement, la place commence à manquer sur le disque du portable --> il est temps que je mette au point une autre solution.
- j'ai à ma disposition un disque usb externe et un vieux PC équipé d'un disque IDE d'une capacité insuffisante.
- j'ai, après mainte réflexion (si-si!!) pris la décision de me servir de mon disque usb en le reliant à la sme. Ce disque sera sous tension 30 minutes par jour (les sauvegardes ne durent plus de 15 minutes) via une prise programmable. Je suis tout à fait conscient que le changement de l'heure d'été à l'heure d'hiver, un déréglage de l'heure dû à un manque de précision de la prise, une sauvegarde qui dure plus longtemps que prévu etc... ont des chances de me planter une sauvegarde. Je pense cependant que ceci n'est pas dramatique car il ne s'agit que de fins domestiques et que la probabilité que je perde quelque chose car cette sauvegarde n'a pas fonctionné est franchement minime. Je sais que ce n'est pas la solution, mais simplement quelque chose qui je pense peut fonctionner à 95% sans me couter un €. Si la pratique me montre que ce n'est pas viable, et bien j'essaierai quelque chose d'autre...
- mon portable n'est pas compatible avec le wake on lan et ne sait démarrer à heure fixe

Étant donné que ma prise programmable est ......programmée, il faut donc que les sauvegardes s'effectuent à heure fixe --> usage de cron.
Mon portable doit être allumé manuellement et tourne sur accus tant que ceux-ci ne sont pas totalement vides --> il n'est pas pensable de le laisser allumé longtemps car on ne sait jamais si la batterie tiendra jusqu'au bout--> il faut que les sauvegardes soient faites rapidement et peu de temps après que je le quitte des yeux. C'est la raison pour laquelle j'écarte (pour l'instant!!) la solution que tu proposes jibe. Si j'avais une machine fixe dédiée aux sauvegardes, alors j'aurais certainement mis ça en place comme tu l'indiques.
Pour couronner le tout, vu que je sauvegarde aussi sur mon client fixe et que le script l'éteint à la fin des sauvegardes, il faut que celles-ci soient effectuées à un moment où je n'utilise pas ce client qui s'éteindrait alors sous mon nez au moment où il ne faut pas........

J'ai donc décidé d'effectuer les sauvegardes à l'heure du repas du soir!!!

Où est en fait le problème de mettre le script en postcommand d'un job vide??
C'est bien sûr utiliser affa pour autre chose que ce pourquoi ce programme est prévu, mais si affa permet ça, en plus des sauvegardes......Avec un tourne-vis, on gratte bien, on fait levier, on s'en sert aussi à l'occasion comme burin....

Encore 45 minutes...........

Peut être un retour frais ce soir.....

@+
Arnaud

[arnaud056]

Peut être un retour frais ce soir.....

et bien non! j'ai stupidement laissé ma prise programmable sur off et non sur auto......................... Je ne suis pas sûr que quelqu'un puisse m'aider dans ce cas de figure........

2 Points positifs cependants:
- le job d'amorçage a bien été lancé automatiquement par cron
- quand j'ai lancé (après avoir allumé ma prise) la sauvegarde manuellement: elle s'est bien déroulée.

1 point négatif: je n'ai pas (encore) reçu de mail d'erreur de la part du job d'amorçage. Etant donné que la prise était éteinte, le montage du disque usb n'a pu être effectué --> le script a dû bloquer --> la postcommand du job d'amorçage n'a pu être terminée --> je pense que j'aurais dû recevoir un message.......

Je retente ma chance demain!

Bonne soirée.
@+
Arnaud

[jibe]

Salut,

:oops: Je ne suis pas sûr que quelqu'un puisse m'aider dans ce cas de figure........

A part te répéter une fois de plus que la prise programmable est une solution risquée, on ne peut effectivement rien pour toi

Bon, je suis moi aussi un peu trop adepte des solutions à la Mac Gyver pour te reprocher de ne pas suivre mes conseils. Je pense qu'il faut d'abord chercher à faire propre et fiable. Mais après, il faut bien s'adapter aux diverses contraintes, et pour un projet personnel/familial, les contraintes sont souvent un manque cruel de moyens qui complique beaucoup les choses...

[arnaud056]

Rapport d'aujourd'hui:
- la prise, qui était réglée correctement aujourd'hui, a ................... parfaitement fonctionné
- le job d'amorçage a bien été lancé et a effectué la sauvegarde du fichier témoin
- le job d'amorçage s'est proprement terminé
- malheureusement, le script d'amorçage en postjob n'a pas tourné!
- aucun message d'erreur!

Je sais que le job d'amorçage a bien tourné car il figure dans "affa --list-archives".

J'ai alors lancé ce job en manuel (affa --run job_amorçage) qui a bien entendu effectué une nouvelle sauvegarde du fichier témoin, mais qui a daigné lancer le script des sauvegardes et ce sans broncher.

C'est, je pense, ce qui s'est passé hier: le script de sauvegardes (qui effectue d'abord les montages) n'a certainement pas été lancé non plus --> le fait que ma prise programmable soit sur off n'a aucunement dérangé sme qui n'a pas essayé de monter le dd usb.

Je n'ai pas d'explication sur le fait que le script ne soit pas lancé et avoue de ne pas avoir encore essayé de tester quoique ce soit dans cette direction.
Cependant je vais essayer de voir comment va réagir affa demain: je viens de placer le script en precommand. On va voir s'il ignore encore mon script.......

@ suivre & bon vendredi soir!
Arnaud

[jibe]

Salut,

Quelques pistes :

- J'ai plusieurs fois constaté des problèmes avec les disques USB : de temps en temps, sans apparemment d'explication logique, le disque n'est pas "vu" par le système et n'apparait pas dans lsusb.

- Es-tu sûr qu'au moment du lancement de ton script, le disque soit bien en état de marche ? Il lui faut un peu de temps pour prendre sa vitesse et signaler sa présence. Je dirais que pour être tranquille, il faut que ta prise soit programmée au moins une minute avant le lancement du script (tiens, ça me donne une idée : voir plus bas)

- T'es-tu assuré que le disque soit bien détecté s'il est déjà connecté sur l'USB au moment de son démarrage via la prise programmable ? Il me semble que ce n'est pas pour rien que je branche toujours l'USB de mes disques lorsqu'ils ont bien pris leur vitesse et jamais avant leur mise en route...

Et une idée : Je n'ai pas le temps de me pencher sur le problème et je ne sais pas s'il est vraiment possible de faire ce à quoi je pense... Je me dis qu'il doit y avoir moyen de savoir quand le disque est détecté par le système, et d'utiliser ce signal pour lancer tes sauvegardes. Ainsi, tu résous le problème de synchro entre ta prise programmable et le lancement d'affa, et tu es certain de la présence du disque lors du mount

[arnaud056]

Bonsoir,
non je ne pense pas que ce soit un problème de montage:
1) le disque usb se met en route 10 minutes avant la sauvegarde
2) la première commande de mon script de sauvegarde est le wake on lan du client fixe, et 2 minutes après s'effectuent les montages. Or le client fixe ne se réveille pas quand affa est lancé par cron --> le problème est donc en amont. Non?

Le fait de passer le script en "precommand" de affa n'a rien changé: affa me donne l'impression de l'ignorer et de passer tout de suite à sa sauvegarde du fichier témoin. Aucun message d'erreur. Quand je lance manuellement avec affa --run , alors là tout se passe comme JE le souhaite.

J'ai l'intention de faire la chose suivante:
- créer un script simple m'écrivant "script réalisé" dans un fichier quelconque (ce script est tellement simple, qu'il va falloir que je cherche ce qu'il faut mettre dedans... )
- créer un job affa sauvant un fichier témoin et ayant ce script de contrôle en pré- ou postcommand
- enregistrer ce job dans les tâches cron et voir si le script a bien lancé (présence de "script réalisé" dans le fichier quelconque.

En fonction de ces résultats, je saurais si j'ai un problème de cron, de script ou de job affa.

Je ne vais malheureusement pas avoir trop le temps de faire ça cette semaine ... je vous tiens tout de même au courant dès que possible.

Ah oui, encore une chose: je suis sous sme8, mais je ne pense pas que ceci ait de l'importance car cron lance bien la tâche à l'heure prévue.

L'astuce soulevée par toi jibe avec le démarrage de la sauvegarde dès la reconnaissance du disque serait en effet un luxe!!! Il faudrait, je pense, tout de même avoir un système qui permette de ne PAS lancer les sauvegardes dès que le disque est allumé, ceci afin de pouvoir réaliser des tâches ou contrôles en manuel (espace libre du disque, jeter un coup d'œil aux sauvegardes etc...).

Bonne soirée.
@+
Arnaud

EDIT: echo "script réalisé" >> le_fichier //// j'ai eu de la chance de tomber tout de suite sur ce que je cherchais!

[jibe]

Salut,

Oui, c'est un peu curieux... Il semblerait, d'après ce que tu dis, qu'effectivement affa ne lance pas le script ou que le script ne soit pas exécuté lorsque affa le lance... Ton essai sera intéressant (au passage, perso je mets toujours dans mes scripts quelques messages de log comme ci-après)

Code: Tout sélectionner

D=`date`
echo $D " -- Mise en route du NAS --\n" >> /var/log/affa/e-smith.log

Ça sert bien en cas de problème pour comprendre ce qui se passe

Une idée en l'air : ne serait-ce pas un problème de droits ? Il n'est pas impossible que ce ne soit pas le même user qui lance le script lorsque tu lances affa manuellement et lorsqu'il est lancé par cron. Pure supposition, mais peut-être à vérifier...

Ou alors, c'est un problème sous SME8 ? Jamais eu de tel problème pour ma part, mais je n'ai jamais installé de SME8...

N'avais-tu pas déjà fait des essais avec un script en pre-job ? Quelle(s) différence(s) avec le cas actuel ?

[arnaud056]

Bonsoir,
j'ai bien avancé même si ce fût laborieux, et vous propose le résumé - REX suivant:

1) le lancement du script en pré- ou postcommand est très facile: il faut simplement indiquer le chemin complet du script...

Concernant le script (montages, sauvegardes, démontage et extinction), je retiens les points suivants:
2) j'ai été fortement "contrarié" par le montage-démontage du NFS Quand le script était lancé directement, tout fonctionnait, mais quand il était lancé par affa, j'avais droit à un "NFS stale file". Après recherches et essais, je me suis aperçu que cela arrivait lorsque ma sme "ordonnait" via ssh au PC de sauvegarde de monter sa propre partition de sauvegardes.
J'ai dû effacer le point de montage sur le PC et ..... le recréer.

3) sur la sme, au démontage d'un partage NFS, il me fallait utiliser "umount.nfs" quand le script était lancé en manuel. Quand il est lancé avec affa, il a fallut que je le transforme en un "umount -f" pour ne pas attraper un autre message d'erreur de type "NFS stale file".

4) pas seulement dans la pré- ou postcommand de la config de affa, mais également dans le script, il faut utiliser les chemins complets pour les fichiers mais aussi pour quasiment toutes les commandes --> /sbin/ether-wake, /sbin/e-smith/affa --run le_job, /bin/sleep etc....... vive la commande "which" pour trouver les chemin!
Il y a cependant des commandes comme "echo" qui peuvent être lancées directement .... --> bien faire attention car ce qui n'est pas trouvé est très poliment ignoré sans pour autant générer un message d'erreur!
En ce qui concerne "mount" et "umount", j'ai mis par précaution là aussi le chemin complet et ne peut donc affirmer avec certitude si ils nécessitent vraiment le chemin complet.

Le script ne nécessite pas de permissions d'accès particulières: le "755" qui est attribué par sme quand on rend le script exécutable fonctionne très bien. "777" n'apporte aucune amélioration. Propriétaire=root.

5) il y a GRAND intérêt à mettre un log comme indiqué par jibe (merci au passage, c'est exactement ce que je souhaitais obtenir!) après chaque étape du script durant la période de débuggage car même si le script est simple et tourne lorsqu'il est lancé directement, il peut vite devenir un casse tête lorsqu'il est lancé par affa Et vu qu'un message d'erreur n'est pas toujours généré, il est intéressant de s'apercevoir que 5go ont été sauvegardés en 1 seconde .......

6) A y réfléchir il est peut être plus censé de "créer" le script directement pour affa que d'en écrire un qui tournera en lancement manuel et qui devra être "traduit" pour affa.

Maintenant tout fonctionne en automatique et correctement chez moi depuis 3 jours.

Voilà!
Bonne soirée!
Arnaud

EDIT: petite précision supplémentaire: le "job" de sauvegarde de affa ne fait rien d'autre que de lancer le script des sauvegardes via cron à heure définie. Il est (comme je l'ai indiqué plus haut) cependant nécessaire qu'il effectue par lui même la sauvegarde d'un fichier bidon.

[jibe]

Salut,

Merci pour ce REX que probablement beaucoup apprécieront. Je me permets quelques commentaires :

le lancement du script en pré- ou postcommand est très facile: il faut simplement indiquer le chemin complet du script...

Oui, j'aurais dû y penser... C'est vrai qu'avec l'habitude, on repère facilement et on corrige sans même y penser ce genre d'oubli. Et puis, j'ai vite pris l'habitude de préciser les chemins partout avec Affa, et comme c'est un automatisme je ne pense pas à insister sur cette quasi nécessité...

J'ai dû effacer le point de montage sur le PC et ..... le recréer.

Bizarre, ça... Une histoire de droits, peut-être ? Hormis leur lenteur, je n'ai jamais eu de problèmes avec les mount/umount NFS... Mais bon, sur SME 7.x, comme je le disais je n'ai jamais installé de SME 8.

pas seulement dans la pré- ou postcommand de la config de affa, mais également dans le script, il faut utiliser les chemins complets pour les fichiers mais aussi pour quasiment toutes les commandes

Oui, c'est ce que je disais plus haut. C'est souvent nécessaire, et c'est une bonne habitude de le faire systématiquement : ça ne coûte pas grand chose (au pire, une commande whitch), et ça peut faire gagner des heures de debugging et d'arrachage de cheveux

Le script ne nécessite pas de permissions d'accès particulières: le "755" qui est attribué par sme quand on rend le script exécutable fonctionne très bien. "777" n'apporte aucune amélioration.

Non : une autorisation d'écriture est inutile. Ce qu'il faut bien, c'est que tout le monde ait les droits d'exécution. Après, les paranos de la sécurité diront peut-être qu'il ne faut pas mettre les droits d'exécution à tous si ce n'est pas nécessaire, ils n'ont pas tort. Mais entre le risque minime et les heures de recherche pour trouver dans chaque cas les droits les plus justes, perso je ne me casse pas la tête. De toutes manières, s'il y a intrusion sur une SME, c'est forcément en root, alors, on peut bien limiter les droits des autres, ça ne changera rien !