CoolRaoul

Pourquoi avoir créé un *dossier* my_sendmail??? C'est un *fichier* qu'il te faut, "/usr/local/bin/my_sendmail" doit être un fichier (exécutable) contenant le texte de mon script. Autre chose, le message: 250 ok 1393753455 qp 15197 indique que le mail à bien été accepté. Reste à savoir ce que le routeur de mail OVH en a fait. Maintenant, je t'engage à contacter le support OVH pour qu'ils t'indiquent explicitement quel smtp il faut utiliser, quelles sont les restrictions sur les domaines des champs From" et/ou "To". NB: tous les problèmes rencontrés serait du même ordre en ayant utilisé la commande "sendmail" native (à la mauvaise gestion des erreurs par mon script prés). Il est d'ailleurs possible qu'installer le package officiel "Mail Server" (même sans le démarrer) apporte la commande sendmail standard (à vérifier toutefois) Pour terminer, et ou çà ou cela s'avère nécessaire (suivant ce que te conseille le support OVH), j'ai fait une nouvelle version du script qui permet de paramétrer le contenu de la chaine "HELLO" du dialogue SMTP. Tu la retrouveras ici. Ca se spécifie par le switch "-h"

En attendant de trouver mieux tu peux utiliser DLNA en mode "push". J'ai fait le test avec succes sur mon téléviseur en utilisant DS Audio sur mon téléphone et aussi Audio Station via la navigateur du PC (déclarer les flux des stations de radios dans la section "radio internet" de Audio Station). ***EDIT*** Trouvé la solution pour le mode "pull": Testé et validé (toujours via mon téléviseur)

Tant que tu n'aura pas réussi la fin (terminer par <entrée> "." <entrée>, rajoute un <entrée> de plus pour faire bonne mesure) on ne pourra rien conclure: l'objectif est de vérifier si tu reçois ou pas le mail avec ce test. Ensuite on saura si il faut incriminer le script (mais j'en doute) ou quelque chose du coté OVH Pense à tester aussi avec "smtp.dsl.ovh.net"

Je viens de vérifier encore, pour moi avec -m smtp.free.fr ç'est OK Tu peux faire un test en ligne de commande comme ci dessous pour voir ce qui coince (tu tapes exactement ce que j'ai misen terminant par <return< "." <return> telnet ns0.ovh.net smtp EHLO localhost.localdomain MAIL FROM:<postmaster@mondomaine.com> RCPT TO:<prenom.nom@mondomaine.com> DATA From: postmaster@mondomaine.com To: prenom.nom@mondomaine.com essai . ***EDIT*** J'ai trouvé ceci: (http://forum.ovh.com/showthread.php?67837-Offre-ADSL-b%E9ta-et-serveurs-smtp&p=419688&viewfull=1#post419688)

As-tu configuré un client mail PC pour utiliser le mail OVH en envoi? C'est le même nom de serveur smtp qu'il faut utiliser. Sinon, je ne sais plus quoi dire, faut demander sur les forums OVH quel est le serveur smtp à utiliser. PS: quand tu dis que l'envoi de mail ne passe pas, est-ce que le script fait une erreur ou bien tu recois un "bounce" ?

Peux-tu me dire pour quelle raison tu ne veux pas utiliser, comme j'ai conseillé, le smtp de ton FAI et insistes pour choisir celui de ton hébergeur (OVH)?

Mon script n'intègre pas le support du SMTP authentifié, mais il suffit d'utiliser le FTP de ton FAI qui acceptera les connexions sans mot de passe (faudra peut-être renseigner le "From" ou le "To:" avec un email du domaine correspondant pour ne pas se prendre un bounce). Non. Il est exact que le corps de la partie textuelle du message est lue via l'entrée standard. ce n'est qu'en plus et optionnellement qu'on peut spécifier en argument des fichiers qui seront ajoutés au messages comme pièces jointes, encodés en Base64.

Mais c'est justement pour cette raison que je propose l'utilisation de mon script

Une solution pour le mail en utilisant un script perl de mon cru (nécessite d'avoir installé le package perl) A lire à partir d'ici:

Pour exclure une IP du bannisement: Les adresses bannies sont dans l'onglet "liste des blocages" **EDIT** Je n'avais pas réalisé que le fil était aussi vieux! Ce n'est plus du déterrage mais de l'archéologie.

Vu que ca ne fait moins d'un jour ton programme fonctionne c'est normal que rien ne se passe. Ma commande ("find -mtime") se base sur les *timestamps* des sous dossiers de "$BACKUP" sur la cible. Je suppose que, pour tester, tu as du y créer des dossiers "bidons" , mais ils sont tous forcément datés du jour. Les premier effacements ne seront effectifs que d'ici 6 jours.

En effet Pour effacer des fichiers distants faudrait pouvoir faire un ssh en mode commande mais il me semble que tu l'as désactivé? Sinon et si je ne me goure pas ça serait faisable comme ceci (attention aux quotes): ssh $SERVEUR "cd '$BACKUP' && find . -type d -maxdepth 1 -mindepth 1 -mtime +5 | xargs rm -r"

Je m'y prendrais plutôt comme suit: (laisser le code entre parenthèses afin que le "cd" reste local): ( cd "$BACKUP" && find . -type d -maxdepth 1 -mindepth 1 -mtime +5 | xargs rm -r ) A tester avec un "echo" avant le "xargs" pour tester (le "cd <truc> && <commande dangereuse>" ainsi que les quotes autour de $BACKUP (pas se faire avoir si variable non définie), sont des habitudes que j'ai prises, pas forcément utile ici mais bon: ceintures, bretelles , ... toussa,

L'opération de génération de clé est indépendante du compte utilisé si c'est ça ta question; la clé générée à la même "qualité" quelle que soit le compte utilisée pour cela. Sinon le risque, en laissant le port SSH ouvert, est de se faire attaquer (mais pas obligatoirement pirater: il reste encore des mécanismes de sécurité efficace comme le blocage auto) . Je conseillerait d'utiliser des règles dans le firewall du Syno pour laisser passer sur le port SSH iniquement les IP "amies". A cet effet, décfinir une ou plusieurs règles autorisant les connexion SSH pour ces IPs (ou range d'IPs) suivie d'une règle bloquant tout le port 22. Iu mieux configurer le firewall en cochant "interdire l’accès" quand "aucune règle n'est remplie" (dans ce cas ne pas oublier de mettre en tète de liste une règle autorisant toutes les IP di LAN locale. De plusla règle de blocage devient inutile) Le service de sauvegarde réseau est basé sur rsync qui lui même s'appuie sur SSH. A partir du moment ou le service a été activé via le panneau de configuration DSM, le démon sshd l'est aussi, même si on a désactivé les connexions ssh dans "terminal" (ce qui aura juste pour effet d'interdire les connexions ssh "non rsync")

Là on s'éloigne du problème initial. Il va falloir d'abord que tu apprennes à utiliser l'authentification SSH par clé. Je t'engage à chercher de l'info et des tutos la dessus mais si tu pars de zero comme je commence à m'en rendre compte prévois d'y consacrer un peu de temps. Sache aussi que, si ton objectif est de synchroniser des dossiers à distance, peut-être ferais-tu mieux d'envisager l'utilisation des outils déà prévus ) cet effet dans l'interface DSM (synchro de dossier partagé), ou même attendre l'arrivé de DScloud de NAS à NAS en DSM 5, plutôt que passer par des scripts shell.

Je ne pense pas qu'ils considèrent cela comme un bug. J'imagine que, pour Synology, le VPN doit être considéré comme un réseau *privé*. Ce n'est pas pas hasard que cela se nomme "virtual *private* network": comme je l'ai dit plus haut destiné à relier entre eux à distance des réseaux en confiance mutuelle. Et dans cette optique, le firewall est moins justifié. Ensuite que certains en fassent un usage "détourné", ce n'est plus leur problème.

Classique quand on utilise un éditeur sous Windows (mais une fois bien configuré Notepad++ est très bien)

En étant connecté en mode ligne de commande sur le NAS, par SSH ou par telnet Par exemple oui Normal, la commande "chmod" fait son travail sans rien afficher. Assure toi juste de l'avoir configuré comme ci dessous: Une fois connecté sur le NAS en mode ligne, tu peux exécuter directement ton script, inutile de passer par le gestionnaire de tache tant que tu est en phase de mise au point.

J'ai trouvé ça aussi:

Commencer par vérifier que l'option ci dessous (dans DSM -> Panneau de Configuration -> Win/Mac/NFS -> Paramètres Avancés) n'aurait pas été cochée par inadvertance:

Tu as probablement certainement oublié de le rendre exécutable. Essaie de faire: chmod +x /volume1/Backup/rsync/script.shEt re-testes. Non, il peut être situé ou tu veux.

Oups, copier/coller qui a merdé Je corrige

Tu serais bien le seul dans ce cas... tous les vieux habitués du forum (et de DSM en général) connaissent cette particularité. Suffit de taper la commande: iptables -l -V -n en ligne de commande pour constater que seule l'interface ethernet physique du NAS est prise en compte apres avoir configuré le firewall par le panneau de configuration DSM.

Tu as oublié de déclarer le PATH dans ton script! Au minimum il faudrait mettre: PATH=/bin:/usr/bin:/usr/syno/bin D'autre part, via le planificateur de taches, tu est "aveugle" sur les erreurs, donc pense a ajouter la création d'un log ou tu pourras vérifier que tout s'est bien passé (ou pas): [ -t 0 ] || exec >/tmp/monscript.log 2>&1 Ces deux lignes à inclure en tête de ton script.

Vous pouvez laisser tomber la conf firewall: on vous a expliqué que de toutes façon ça ne s’appliquait pas à la connexion VPN