loli71

Ok, super Diaoul ;-)

Chose bizarre que je constate, je tape dans la barre d'adresse de mon browser l'url suivante : http://www.synocommunity.com/ et mon browser me redirige vers l'URL suivantes : https://%(server_name)s/ N'y aurait il pas un petit problème de redirection dans le site web ,

Salut bo39, Pourquoi avoir renommé les fichiers "php" en "html", il faut bien les laisser avec l'extension .php. Ensuite, comme tu n'as pas envoyé de position à ton serveur via l'application, c'est normal que la map google ne voit pas disponible (j'ai fait le test chez moi). Pour finir, si tu veux que ton téléphone puisse envoyé à ton serveur NAS les coordonnées, il faut que ton NAS soit accessible depuis l'exterieur avec un nom de domaine (pour cela il existe des tutos dans ce formum) , et tu dois configuré l'application de te ton téléphone pour qu'il envoie les info à ton nas (https://nom.de.domaine/gps.php). Non Mike, il n'y a pas d'erreur, le répertoire "/tmp" existe bien sur les syno et il est accessible pas le serveur web ...

D'après moi, c'est tout simplement à cause de l'espace dans le nom de ton répertoire "/volume1/A lire". Tu devrais peut être essayer d'utiliser le caractère d'échappement avant l'espace avec un backslash (le caractère '') : mount 192.168.0.28:/volume1/A lire /mnt

GLPI est effectivement fourni en package officiel par Synology : https://www.synology.com/fr-fr/dsm/app_packages/GLPI Tu devrais donc pouvoir le trouver dans ton centre de paquets

Ben oui, mais je dois avouer que j'ai baissé les bras après plusieurs mois sans retour de synocommunity. J'ai depuis même upgrader tous les softs qui pouvaient l'être dans mon package: squid 3.4.9 compilé avec SSL et option transparent squidguardmgr 1.13 sauvegarde des configs pour mieux gérer les updates du package.

Malheureusement la version squidguard actuellement fourni par synocommunity en beta est effectivement truffée de bug. J'avais publié sur synocommunity toutes les corrections de ces bug pour avoir une version entièrement fonctionnelle .. mais cela fera bientôt un an que j'attends qu'elles soient acceptées, sans nouvelles. Pour ma part, je me sers de ma version de squidguard comme permettre à mes enfants de naviguer avec un peu pus de sécurité.

Ben je dirais que s'ils n'ont pas de mot de passe, ils ne doivent pas pouvoir se connecter tout simplement

Solution: fermer tous les accès non obligatoires et vitaux depuis internet surtout .... et s'assurer que les services ouverts sur internet son vraiment sécurisés à fond (https au lieu de http, ssh au lieu de telnet, scp/sftp au lieu de ftp) et mots de passes complexes sur les comptes ....

Salut, Ce mail signifie que des petits chinois ont trouvé une cible à attaquer en utilisant le FTP sans succès ..... jusqu'à maintenant Tu risque donc d'avoir beaucoup d'autres tentatives de connexion puisqu'il semblerait que tu aies ouvert le FTP sur internet, je te rappelle que le FTP est un protocole qui n'est pas sûr, puisque pas crypter, et que de permettre des connexions à ton syno depuis internet est toujours dangereux ...

Ah oui effectivement .. là je ne peux pas t'aider du coup :-(

Un petit truc tout bête, étant donné que tu ne te sers pas du pop et imap, et que tu n'héberges aucune boite au lettre sur le NAS, il ne suffirait pas de mettre un nom de domaine bidon dans le mail serveur et activer le relais SMTP ? en tout cas c'est ce que j'ai fait, avec un nom de domaine du type localdomain.local

En résumé: - le DHCP est déjà activé sur ta FB, donc tout nouvel appareil se verra attribué par ta FB une adresse IP. - Le disque dur USB branché sur ton NAS n'a pas besoin d'adresse IP, puisqu'il est vu comme une autre disque dans ton NAS, donc accessible par l'interface Web du NAS ou montage réseau dans le NAS. - Un seul DHCP doit être activé sur ton réseau, si tu actives le DHCP sur ton NAS et plus de celui de la FB, tu vas te retrouver avec 2 DHCP et donc que des ennuis et des conflits d'adresse IP.

Si tu ne sais pas ce que c'est, alors ne l'active pas ;-) http://fr.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

Content que tu aies réussi ;-)

Bon, l'authentification se passe pourtant bien sur le syno serveur : debug1: Authentication succeeded (publickey). Authenticated to xxxx.synology.me ([x.xx.xxx.xx]:22). donc il faut regarder de plus prêt sur le syno serveur, peut-être dans le fichier /var/log/message, et dans le fichier sshd_config aussi Ce fichier /etc/ssh/sshd_config doit contenir la ligne suivante : PermitRootLogin yes

Donc change les droits sur ton fichier /root/.ssh/authorized_keys pour commencer: chmod 600 /root/.ssh/authorized_keys Ensuite, tu peux lancer la commande ssh sur le syno client avec plus de debug pour voir : il faut bien évidement que ta clé privée soit bien /root/.ssh/id_rsa, sinon met le bon chemin/fichier dans la commande

Essaye de commencer par passer la commande ssh manuellement sur ton syno client, pour voir si l'authentification se passe bien avec le deuxième syno, mais attention dans la commande que tu as mise, il faut utiliser la clé privée "id_rsa" et non la clé public contenue dans id_rsa.pub sur le syno client. En plus, il vaut mieux donner le chemin complet vers la clé privée : ssh -i /root/.ssh/id_rsa root@xxxx.synology.me Ensuite, si cela ne marche pas et que le ssh te demande encore un password, il faut vérifier que ton fichier /root/.ssh/authorized_keys ait les bon droits sur ton syno serveur nasserveur> ls -lsa /root/.ssh/authorized_keys 4 -rw------- 1 root root 1019 Oct 6 19:37 /root/.ssh/authorized_keys

Alors là .. possible oui, moi je tourne sous DSM 5.0-4528 Update 2 Je ne sais pas pourquoi mais je n'ai pas voulu passer en DSM5.1 .... peut-être à cause de la liste énorme des bug référencés ici depuis sa sortie lol

Si la commande suivante fonctionne en étant connecté à ton nas en SSH en tant que root, c'est que les droits sont bon, essaye et donne nous le résultat : su - http -s /bin/sh -c "/var/services/web/cgi-bin/essais.cgi" Et si les droits sont bon, tu devrais pouvoir accéder à ton script par l'url : http://<nom de ton nas>/cgi-bin/essais.cgi

Oui Raoul, entièrement d'accord avec toi. soit les sauts de lignes ne sont pas au format UNIX, soit il y a une ligne vide ou un espace avant la ligne shebang dans le script ...

Ah vi, bien vu , je corrige mon post précédent, mais le résultat est le même, cela fonctionne chez moi ;-)

Euh, je persiste et signe ... il n'est pas nécessaire d'indiquer le programme a exécuter pour lancer un cgi à partir du moment où le shebang est bien mis dans la toute première ligne du cgi (donc attention, pas d'espace ou de ligne vide avant cette ligne shebang !!!) et que l'utilisateur http a les droits pour exécuter le cgi. Etant donné qu'un cgi peut être fait avec n'importe quel langage de programmation (perl, sh, bash, ksh ou c compilé) c'est grace au shebang que apache sait quel langage doit être utilisé pour interpréter le code qui suit. nas2> cat /var/services/web/cgi-bin/test.cgi #!/usr/bin/perl print "Content-type: text/htmlnn"; print "Hello, world!"; Lancement de la commande en ssh depuis le compte root : nas2> su - http -s /bin/sh -c "/var/services/web/cgi-bin/test.cgi" Content-type: text/html Hello, world! Connection au compte http depuis le compte root avec le shell /bin/sh et lancement de la commande directe : nas2> su - http -s /bin/sh BusyBox v1.16.1 (2014-10-10 08:38:16 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. nas2> whoami http nas2> /var/services/web/cgi-bin/test.cgi Content-type: text/html Hello, world!

Pour être un peu plus précis sur le test de Raoul, il faudrait même lancer la commande suivante (sans le "perl" devant le script, car le module CGI ne sait pas qu'il s'agit d'un cgi en perl et il utilise la ligne shebang pour savoir quoi utiliser): su - http -s /bin/sh -c "/var/services/web/cgi-bin/test.cgi" Pour le module CGI, out dépend de ta version de DSM, moi pour la version 50.1 j'ai cela dans ma config d'origine httpd.conf-user: LoadModule cgid_module modules/mod_cgid.so ... ... ScriptSock /run/httpd/user-cgisock ... ...

Juste une dernière idée comme çà, après je sèche .... tu n'aurais pas un fichier ".htaccess" qui trainerait quelque part dans l'un de tes répertoires et qui redéfinirait les valeurs du "Options" en enlevant le ExecCGI ?