loli71

Pour le FTP: port TCP 20(data) et 21 (commandes) obligatoire, à moins que ces ports ne soient changé dans l'application Pour le FTPS (FTP protégé par SSL ou TLS) : Port par défaut TCP 990 mais peut varier selon les config. voir là pour plus d'explications (notamment sur la partie établissement de la connexion): http://fr.wikipedia.org/wiki/File_Transfer_Protocol

Sans aller aussi loin que le serveur UK, un post ici même en parle déjà :

Salut Mickael, je suppose que ton script est en perl vu les erreurs. L'appel de commandes shell dans un script perl doit etre fait soit par la commande system(), avec des `` le symbole "@" est aussi un symbole perl, il doit donc être précédé d'un antisah "" je te conseille aussi de mettre les chemins complets pour les appels à nail #Envoi de mail d'alerte avec NAIL if ( (($id_capteur == 49) || ($id_capteur == 50)) ) { `echo "testing bla bla bla" | /opt/bin/nail -s "subject bla bla bla" monmail\@fai.fr`; } if ( (($id_capteur == 10)) ) { `echo "testing bla bla bla" | /opt/bin/nail -s "subject bla bla bla" monmail\@fai.fr`; }

Très bonne idée cela Thomas, je cours regarder, merci ;-)

Faire transiter les requêtes mysql directement sur internet parait effectivement TRES dangereux, si je ne me trompe pas, le protocole n'est pas forcément encrypté, donc on verra passer en clair le compte et mot de passe qui donne accès à ta base de donnée en écriture en clair sur internet .... Après il existe un moyen assez simple de ne pas faire passer en clair ces données, mais qui nécessite un accès en ssh sur le synology et un clietn ssh sur le poste client qui ferait du forwarding de port (type putty). En gros, tu lances sur le PC (avant de lancer ton client lourd) une connexion ssh vers le synology avec (dans la conf putty) le forwarding du port 3306 vers 127.0.0.1:3306 (qui correspond à l'autre bout du tunnel donc ton syno). Ensuite tu paramètre ton client lourd pour qu'il utilise 127.0.0.1 comme adresse du serveur mysql et le tour est joué. Avantages: - pas de connexion en clair sur le port 3306 sur internet entre ton client lourd et ta base de données sur ton syno - pas de port 3306 à ouvrir ni sur le firewall du syno ni sur ta box, uniquement le port 22 (SSH) voir même un autre port moins connu selon le paramétrage de ta box Inconvénients: - nécessité de créer au moins un compte sur le syno (sans forcément de droits dans les différents applications du syno d'ailleurs à part le ssh) permettant l'accès ssh - nécessité de lancer une connexion ssh du PC hébergeant le client lourd vers le syno avant le lancement du client lourd (utilisation de Putty par exemple) - L'utilisation de Putty veut dire que le PC hébergeant le client lourd doit avoir une connexion directe à Internet (pas d'utilisation de proxy d'entreprise par exemple, sinon la solution devient plus complexe) A toi de voir ;-)

Si la clé publique que tu as crée est pour l'utilisateur svnuser, alors tu dois la mettre dans le répertoire home de ton user svnuser : /var/services/homes/svnuser/.ssh/authorized_keys Ensuite, il suffit effectivement d'activer le ssh (pas besoin du telnet) dans la partie "Terminal" du panneau de configuration. Puis d'utiliser un client ssh depuis ton PC (putty pour windows par exemple) et de configurer le compte svnuser, la clé privée et l'adresse ip de ton synology, si tu arrives a te connecter de ton boulot en ssh avec ce compte, il te restera la partie "Accès depuis l'exterieur" à aborder je pense

C'est avec plaisir ;-)

Pour l'executer je mets effectivement la tâche cron suivante dans le fichier /etc/crontab : 01 0 * * 0 root /opt/bin/surveillance_sshd.pl 2>&1 >/dev/null[/CODE] Comme le fichier /var/log/message tourne automatiquement chaque dimanche matin à 00:05, en lançant mon script chaque dimanche à 00:01 (avant la rotation), j'obtiens bien toutes les tentatives de connexions ssh de la semaine qui vient de passer. après, si tu souhaites le lancer tous les jours, tu auras les tentatives de la journée ajoutées aux tentatives déjà reçues dans le mail de la veille, mais ce n'est pas forcément gênant si tu le sais.

MAJ de mon script pour une petite correction concernant la récupération des noms par la commande nslookup.

Effectivement, en modifiant le canal des package (canal stable/canal beta) et en désactivant réactivant la recherche auto du DSM, la crontab est de nouveau complète. Merci du coup de main.

Même celles de la recherche de mise à jours des packages et du firmware ? C'est surtout celles là qui m'embêtait d'avoir perdu

Merci Lurik, C'est exactement les 3 lignes que je voulais récupérer ;-) Etant donné que je n'ai activé que très peu de services sur le syno, je dois avoir ce qu'il me faut maintenant.

Bonjour Raoul, mais je ferais le ménage pour récupérer les 3 lignes qui sont communes à tous les syno (upgrade des packages/syno entre autre)

Bonjour, J'ai installé le package "cron manager", et il semblerait que la version que j'ai ai un problème, en voulant supprimer une ligne que j'avais rajouté dans la crontab, le package m'a supprimé toutes les autres lignes existantes à part celle sur la quelle j'avais cliqué "Del". Je suis en DSM 4.1-2647, est ce que quelqu'un pourrait me mettre ici un copier/coller du contenu de son fichier /etc/crontab pour réparer cette erreur. Merci d'avance de votre aide. Loli

une question, tu essayes d'accéder à l'adresse IP externe de ta box sur le port 5000 (ou 5001) depuis ton réseau interne ? Dans ce cas là, le test ne peut pas être concluant, car en fait ta box voit bien que tu proviens de ton réseau interne et ne fait pas le forwarding de port. si tu fais le test depuis internet réellement (depuis chez un voisin ou un téléphone en 3G), et que cela ne marche pas, là effectivement il y a un soucis.

Salut Trucmuche, Désolé d'avoir enlever le script, il n'était pas très propre, je voulais juste le remettre au mieux pour que tout à chacun puisse l'utiliser à sa convenance, mais j'ai été très pris ces derniers jours. je rattrape donc mon retard en mettant ici le script corrigé et avec en plus quelques commentaires : #!/usr/bin/perl my $message='/var/log/messages'; # fichier de log a surveiller my $dest='mon.adresse@mail.com'; # adresse mail à modifier my %connexionsok; my @connexionsfailed; my $entete, $texte; my $date=`date`; chomp($date); $entete="SSHD surveillance $date"; open(TEXTE, ">/tmp/texte.txt") or die; # recherche du mot "sshd" dans le fichier de log : open (MSG, "/bin/grep sshd $message |"); while ( defined( my $line = <MSG> )) { chomp($line); if (my ($date, $value, $type, $user, $adresse) = ( $line =~ m/^(.*) sshd\[\d+\]: ((?:Accepted|Failed)) (\w+) for (\w+) from (\d+\.\d+\.\d+\.\d+).*$/)) { # recuperation des lignes de la forme # Oct 4 23:16:36 sshd[14190]: Accepted publickey for USER from XXX.XXX.XXX.XXX port 65017 ssh2 # Oct 4 17:51:28 sshd[25256]: Accepted password for USER from XXX.XXX.XXX.XXX port 43954 ssh2 # Oct 4 17:56:45 sshd[13272]: Failed password for USER from XXX.XXX.XXX.XXX port 37651 ssh2 if ($value eq 'Accepted') { my ($moisday) = ($date =~ m/^(\w+\s+\d+)\s+.*$/); my $k="$moisday"."$user"."$adresse"."$type"; $connexionsok{$k}=$moisday.'#'.$type.'#'.$user.'#'.$adresse; } else { push(@connexionsfailed,"$date".'#'."$type".'#'."$user".'#'."$adresse"); } } } close(MSG); print TEXTE "############################\nConnexions Failed:\n"; foreach my $v (@connexionsfailed) { my ($date,$type,$user,$adresse) = split('#', $v); # recuperation du nom par resolution nslookup depuis l'adresse IP my $name=`nslookup $adresse | grep "^Address.*: $adresse"`; chomp($name); $name =~ s/^Address.*:\s+${adresse}\s+//; print TEXTE "$date $user (authtype:$type) $adresse (nom:$name)\n"; } print TEXTE "\n############################\nConnexions Accepted:\n"; foreach my $k (sort( {$a cmp $b} keys(%connexionsok))) { my ($moisday,$type,$user,$adresse) = split('#', $connexionsok{$k}); # recuperation du nom par resolution nslookup depuis l'adresse IP my $name=`nslookup $adresse | grep "^Address.*: $adresse"`; chomp($name); $name =~ s/^Address.*:\s+${adresse}\s+//; print TEXTE "$moisday $user (authtype:$type) $adresse (nom:$name)\n"; } close(TEXTE); # Envoie du mail par le programme nail (ipkg) `/opt/bin/nail -s "$entete" $dest </tmp/texte.txt`; # suppression du fichier temporaire # decommentez la ligne suivante si vous souhaitez ne pas garder le ficheir en local #unlink("/tmp/texte.txt");

Pour ma part, je me suis fait un petit script perl qui tourne en crontab 1 fois par semaine. Le script parse le fichier /var/log/message qui contient les informations sur les connexions ssh (Accepted ou Failed), construit un fichier temporaire de résultat en séparant les Failed des Accepted et envoie un mail avec ce résultat dans le corps du message. Le mail est envoyé en utilisant la commande "nail" disponible via ipkg. Le script perl est adaptable selon les besoin (filtrage de certain utilisateurs, filtre sur autre chose que sshd dans le fichier /var/log/messages ...) Ce script est bien évidement développé "rapidement", mais fonctionnel, si cela intéresse quelqu'un, n'hésitez pas à me MP

bizarre ton fichier dont la ligne open_basedir se termine par "/v" de toute façon, ton open_basedir contient déjà le répertoire "/volume1/web" en premier, ce qui inclut les répertoire suivant (dont ton répertoire "/volume1/web/php_ratio_manager"). De plus, tu nous indiques que ton script marche bien par le serveur Web, ce qui montre que l'open_basedir est correct. Et pour finir, PatrickH t'a indiqué que php en mode CLI n'utilise pas les même paramètres que le php utilisé par apache, as tu testé la ligne que je t'ai mise 3 postes plus haut ?

Je ne sais plus si le fait d'utiliser un script PHP en ligne de commande utilise ou pas le fichier php.ini défini pour le serveur web apache. De même, je me demande si ton problème ne viendrait pas aussi du fait que tu utilises le "-f" pour lancer le script dans ta ligne de commande ... à tester Au cas où, le fichier php.ini se trouve (si je me souviens bien) là : /usr/syno/etc/php/user-setting.ini Où alors au contraire, il faut peut-être que tu rajoutes l'option suivante à ta ligne de commande pour dire à php d'utiliser le fichier php.ini : /usr/bin/php -c /usr/syno/etc/php/user-setting.ini -f /volume1/web/monscript.php

Il s'agit d'un problème de restriction d'accès à ton fichier log.txt par la directive open_basedir de php (qui se trouve dans le php.ini) il faut que tu rajoutes "/volume1/web/php_ratio_manager" dans la ligne open_basedir du fichier php.ini

trop fort Piwi, merci beaucoup pour ta rapidité, je n'attendais "presque que cela" pour m'acheter un DS213+ ^^

Ton problème se trouve donc bien là, le fichier n'a pas les droits d'exécution pour le compte root (seulement rw au lieu de rwx). passe la commande suivante pour régler le souci : chmod u+x /usr/syno/etc.defaults/rc.d/S99mount.sh Et ensuite relance ton test cela devrait fonctionner

tu peux passer la commande suivante et nous donner le résultat : ls -lsa /usr/syno/etc.defaults/rc.d/S99mount.sh

Avec une ptite recherche rapide sur ce site, tu aurais trouvé cela :