PiwiLAbruti

Et ça n'empêche pas d'avoir des machines "volantes".

Je ne t'avais pas dit de la retirer... Si tu veux savoir pourquoi ça ne marchait pas : http://fr.wikipedia.org/wiki/File_Transfer_Protocol

Actuellement non, nous devons implémenter la signature des paquets que Synology a prévu pour le DSM 5.1 (on attend la documentation officielle à ce sujet). Pour contourner ce problème, il faut modifier les paramètres du Centre de paquets pour accepter les paquets tiers.

Tu as retiré la redirection du port tcp/21 ?

Oui, c'est normal car ces adresses appartiennent au même subnet (192.168.1/24). Le problème c'est de vouloir différencier deux réseaux alors qu'ils sont sur le même plan d'adressage. D'ailleurs je ne comprends pas l'intérêt des routeurs dans ton schéma. Les machines de parc 1 et parc 2 sont bien adressées dans le réseau 192.168.1/24 ? De mon point de vue il y a un gros problème d'architecture.

Sans un schéma global du réseau, j'ai du mal à voir comment tu as interconnecté tout ça.

Supprime les redirections UDP ainsi que la redirection du port tcp/20, elles sont inutiles. Remplace le port tcp/5000 par le tcp/5001 pour chiffrer les connexions au DSM, question de sécurité (https://stuff.synology.me:5001). Pour que FTP fonctionne il faut également rediriger la plage de ports passifs définie dans la configuration du serveur FTP (tcp/555xx à tcp/555yy)

Je parle des redirection si de ports à configurer sur ta box/routeur.

As-tu redirigé les ports correspondants ?

iSCSI n'est pas fait pour transiter sur internet.

Vérifiez que la case "Mises à jour importantes" est bien coché dans vos options de mise à jour (Panneau de configuration > Mise à jour et restauration).

Que donne un redémarrage ?

Il va falloir faire preuve d'un peu plus de curiosité : https://www.synology.com/fr-fr/dsm/5.0/cloud_services

@ozone : Quel est le rapport avec le sujet ? Ouvre un nouveau sujet pour exposer ton problème.

As-tu essayé Cloud Station ?

J'ai une meilleure question : que veux-tu faire ?

Les services Cloud actuels sont chiffrés, en quoi une sauvegarde chiffrée chez Synology serait-elle plus digne de confiance ?

C'est quand même surprenant cet abandon sans même proposer une alternative sans régression. Je ne sais pas comment Synology justifie ce choix.

C'est pour ça que Synology et en train de mettre en place la signature des paquets pour certifier leur provenance, ça sera disponible avec la version finale du DSM 5.1. Synology va donc mettre à disposition 3 niveaux de confiance dans le Centre de Paquets : 1. Seuls les paquets Synology officiels sont autorisés, 2. Les paquets de dépôts de confiance sont autorisés, 3. Tous les paquets sont autorisés. Ainsi l'utilisateur aura plus de visibilité sur la provenance de ses paquets.

Il n'y aurait pas comme une contradiction quelque part ?

Ça a été proposé il y a 2 mois chez SynoCommunity : https://github.com/SynoCommunity/spksrc/issues/1163 Si quelqu'un en a le courage, il faudrait faire le tour des dépendances pour évaluer la faisabilité d'un paquet : http://kolab.org/blog/paul-boddie/2014/01/26/current-kolab-package-dependency-graph.

Vérifie qu'il n'y a plus de dossier python dans /volume1/@appstore. As-tu essayé après redémarrage du NAS ?

As-tu essayé en désinstallant le paquet au préalable ?

Vois ça directement avec Synology. L'EDS14 a une architecture armada370, les paquets pour cette architecture existent bien : Directory Server : http://ukdl.synology.com/download/spk/DirectoryServer/2.0-2317/DirectoryServer-armada370-2.0-2317.spk Syslog Server : http://ukdl.synology.com/download/spk/SyslogServer/2.1-2318/SyslogServer-x64-2.1-2318.spk C'est effectivement étrange que ces paquets n'apparaissent ni dans le Centre de paquets, ni dans la page support de l'EDS14. Du coup il est possible que l'installation manuelle échoue, auquel cas il faudra rajouter ce problème à la solution 1.

Sans plus de précision, personne ne t'aidera. Comment se manifeste le problème ? Y a-t-il un message d'erreur ?