red1

Bonjour, Je viens de faire l'opération. Je suis passé de la version 4.2 (dernière version autorisée pour le DS109) à la 5.0-4528-2. Je ne cherche pas à aller plus loin pour l'instant car j'ai seulement besoin du DSM 5.0 pour installer un nouveau package qui était incompatible avec DSM 4.2. Tout ne s'est pas bien passé la première fois parce que je n'ai pas appliqué exactement le protocole. Autant que d'autres profitent de mon erreur en la partageant. L'idée consiste à faire croire au système que le DS109 est un DS112j (hardware le plus récent compatible avec le DS109.) Depuis une connexion telnet vers le syno (login "root"), on édite le fichier /etc.defaults/synoinfo.conf et on modifie la première ligne. Pas besoin de modifier autre chose. En détails : telnet 192.168.0.10 Trying 192.168.0.10... Connected to 192.168.0.10. Escape character is '^]'. rederon-nas login: admin Password: BusyBox v1.16.1 (2016-04-28 18:03:53 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. rederon-nas> cd /etc.defaults rederon-nas> vi synoinfo.conf La première ligne du fichier est la suivante : unique="synology_88f6281_109" Tu te déplaces avec la flèche droite du clavier jusque sur le 0 du 109. Tu tapes ensuite la touche "escape" puis 2 fois "x" pour supprimer le 0 et le 9 Tu tapes ensuite "espace" puis "i" pour insérer tu texte, et tu tapes alors 12j Ta première ligne doit alors ressembler à ça : unique="synology_88f6281_112j" Si tu penses avoir écrit une bêtise, le mieux est que tu sortes du fichier sans sauvegarder en tapant "escape" puis ":" puis "q" puis "!" puis "retour chariot" Si au contraire tu es sûr de toi alors tu sauvegardes et tu quittes le fichier en faisant "escape" puis ":" puis "w" puis "q" puis "retour chariot" Écrire ensuite exit pour sortir du telnet. Je fais maintenant une parenthèse : après la modification du fichier, j'ai fait l'erreur de redémarrer le serveur Synology en pensant que la modification allait être prise en compte à l'issue du redémarrage : en fait, cela a complètement fait planter le système. Le NAS était inaccessible. Pour m'en sortir j'ai dû faire un double reset (appui long sur le bouton reset jusqu'à entendre un bip, et ceci 2 fois de suite.) Il faut ensuite se reconnecter avec l'assistant Synology (la dernière version pour DSM 6.0 c'est mieux) puis réinstaller la version 4.2. J'avais des sauvegardes mais je n'ai perdu aucune donnée ni aucun fichier de configuration dans la manip. Les outils Synology sont vraiment bien faits. Fin de la parenthèse. Revenons donc au moment où le fichier synoinfo.conf vient d'être modifié. Depuis l'interface DSM, dans le panneau de contrôle, il suffit de vérifier les mises à jour. L'outil ne m'a pas proposé la version 5 tout de suite. Il m'a d'abord proposé la version 4.3. J'aurais pu forcer la mise à jour directement en 5.0 en passant en manuel mais je me suis dit qu'il y avait peut-être un risque de perdre des données si l'écart entre les versions était trop grand ou inadapté. Je l'ai donc fait en 2 fois. 4.2 -> 4.3 -> 5.0. C'est un peu plus long mais ça à bien fonctionné. A noter que lors du passage en 4.3 je n'ai perdu aucune donnée et que tout était configuré comme avant, ce qui n'a pas été le cas du passage 4.3 vers 5.0. Après le passage en 5.0, toutes mes données ont été conservées, mais certains paquets devaient absolument être mis à jour car il ne sont plus compatibles avec DSM 5.0. C'est notamment le cas de Photo Station que j'avais conservé en version 5.2-2413 (compatible DSM 4.2 et 4.3) car je le préférais à la version 6 de Photo Station. Depuis l'upgrade en DSM 5.0, je n'ai plus le choix.

Bonjour, Je redéterre un de mes vieux posts pour apporter une précision. J'ai dû dernièrement réinstaller DSM et j'ai été de nouveau confronté à la nécessité d'installer un fichier .htaccess Etrangement, la méthode décrite ci-dessus ne fonctionnait plus. La raison était la suivante : même si vous ne créez pas de sites web perso sur votre Synology, il faut a minima cocher la case "Activer Web Station" dans les paramètres. Dans le cas contraire, le .htaccess ne sera pas reconnu et donc son contenu sera inopérant.

Ben voilà, j'ai trouvé. Et ce n'est pas possible. Ci dessous un extrait du user's guide du synology directory server : LDAP users are not allowed to access the following DSM applications: Photo Station, Audio Station, and Surveillance Station.

Bonjour, Il te suffit de sélectionner "Comptes photo station" dans la liste déroulante et tu retrouveras les anciens comptes. Très sincèrement, je me demande quel est l'avantage de sélectionner les comptes DSM. Je n'ai pas trouvé la solution pour gérer finement les droits d'accès aux différents album depuis les comptes DSM. Pour les comptes "génériques" (droit d'accès à un groupe de personnes), j'utilise dorénavant l'accès par mot de passe (l'abum est vu verrouillé sur la page d'accueil et demande un mot de passe sans login).

Bonjour, Je relance sur ce fil qui semble avoir été consulté, mais pour lequel aucune réponse n'a encore été apportée. Je suis surpris d'ailleurs car je ne dois pas être le seul à me poser cette question : C'est lié à la problématique de l'accès aux images déposées sur le Syno. Si les images sont dans un album public, pas de souci puisque tout le monde peut les voir. Mais si je dépose mes images sur mon Syno c'est justement pour que mes images ne soient pas publiques : sinon je choisirai de créer un album en ligne. Donc image non publique veut dire gestion des mots de passe (pour les albums visibles sur la page d'accueil publique, mais verrouillés) ou gestion des comptes utilisateurs de photo station et des mots de passe associés. J'ai bien vu qu'on pouvait décider que les comptes photo station pouvaient être synchronisés avec les comptes DSM, mais ce n'est pas le but de la manip : il y a des personnes que j'autorise à visualiser mes albums, sans qu'il soit intéressant qu'elles aient un compte DSM. D'où ma question sur le module LDAP qui peut être installé sur le Syno. Car avec la multiplication des mots de passe ou des login et mots de passe, çà devient de plus en plus complexe à gérer. D'avance merci pour votre aide.

Bonjour, Il faut activer le webanalyser depuis la console DSM et vérifier les user agents. Si dessous ce qui est apparu me concernant : Mozilla/5.0 (compatible; bnf.fr_bot; +http://www.bnf.fr/fr/outils/a.dl_web_capture_robot.html)

Bonjour, On les bannit à l'aide du fichier .htaccess. Moi aussi, et j'imagine qu'il y a une faille de sécurité. Pourtant, j'ai bien eu la confirmation de la BNF qu'une partie de mon site avait été collecté. Ci-dessous un extrait du message qu'ils m'ont envoyé : "La collecte de votre site a débuté le 24 octobre avec pour objectif d’archiver un échantillon représentatif du domaine [...]"

Étrange en effet. Rien ne vaut un bon test croisé. J'ai un ami qui a une tablette Android 4.0 qui fonctionne avec mon serveur. Je t'envoie par MP une adresse vers laquelle tu pourras faire un essai depuis ton téléphone.

Bonjour, Savez-vous s'il est possible d'utiliser le serveur LDAP du Syno pour gérer les comptes utilisateurs de Photo Station ? Merci.

Bonjour, Normalement, l'IP fixe ou pas ne devrait pas poser de problème ; j'imagine que dans ta tentative de connexion avec le logiciel DS Photo+ depuis ton téléphone, tu spécifies soit l'adresse IP, soit un nom de domaine qui pointe vers l'adresse IP de Photo Station. Je ne sais pas si cela pourra te donner un début de piste, mais j'avais déjà rencontré un problème similaire, justement avec une version 2.3 d'un téléphone. Pour info, 2.3 c'est la dernière version des téléphones Androïd avant que les tablettes n'apparaissent. Les versions 3 sont des versions réservées aux tablettes Androïd (çà ne doit plus beaucoup exister maintenant), et les versions 4 d'Androïd sont des versions qui peuvent à la fois tourner sur des téléphones et des tablettes dont le hardware est dorénavant compatible. Bref, avec un téléphone en 2.3 je ne pouvais plus accéder à Photo Station parce que DS Photo+ et Photo Station étaient chacun dans des versions incompatibles. A l'époque j'avais dû faire un upgrade de Photo Station et de DSM. C'est un peu un comble : avec un bête navigateur tu accèdes au contenu d'un serveur, mais puisqu'il faut dorénavant utiliser des "applis" sur les téléphones au lieu du navigateur, tu dois mettre à jour les serveurs... Moi, je pencherai donc pour un problème d'incompatibilité entre ta version DS Photo+ et ta version Photo Station. As-tu vérifié que Photo Station était bien à niveau ? Quelle est ta version de DSM et de Photo Station ? D'après le release note de Synology, le support des versions Androïd version 3.1 et plus, arrive dans la version DSM 4.0-2197 (aujourd'hui la dernière version officielle de DSM pour ton Syno est la 4.1-2647 du 2 oct. 2012).

Bonjour, Effectivement. Beaucoup de données et un petit débit en upload. Mais moi ce qui me turlupinerait à votre place (et c'est un peu la raison pour laquelle j'ai posté sur un forum Syno plutôt qu'un forum généraliste ; car finalement c'est avant tout une information qui intéresse tous les propriétaires de domaines .fr), c'est comment le Syno a laissé échapper une grosse quantité de photos du répertoire photo, alors que tous les comptes utilisateurs du Syno nécessitent un mot de passe. La seule solution serait qu'un des utilisateurs qui a tous les droits d'accès (et ils sont très restreints) travaille à la BNF et me fait un petit dans le dos. Mais j'en doute... Une solution crédible serait que mon mot de passe ait été piraté, mais je n'ai loggé aucun accès à un quelconque compte existant durant la période d'aspiration. Donc j'aurai plutôt tendance à conclure qu'il y a un trou quelque part dans le système.

Un Maître des Syno pourra probablement aider un simple initié Et je ne cris pas au complot : je constate. Ceci posé, je ne suis surement pas le seul dans ce cas puisqu'un intervenant un peu plus haut, a aussi eu une visite de courtoisie de la part de la BNF. Contenu du robots.txt : User-Agent: * Disallow: / L'étoile s'adresse à tous les robots, et le disallow sur le / indique que toutes les pages du site sont exclues de l'indexation du robot. Contenu du .htaccess spécial BNF : order allow,deny Deny from 194.199 Deny from bnf.fr allow from all

Dépôt légal c'est le prétexte officiel. Si demain des ayants droits ou des grands groupe représentants légaux d'ayants droits demandent à comparer une œuvre déposée avec le contenu d'un site que la BNF aura aspiré, que pensez-vous qu'ils feront ? Chez moi aussi la page index ne contient rien. Et il faut login et mot de passe pour accéder au moindre contenu du Syno. Pourtant, cela ne les a pas empêcher d'aspirer. Quand à se retourner vers la BNF, j'en connais qui ont essayé ; la CNIL est derrière eux : ils font se qu'ils veulent. Blacklistée chez moi aussi. Ce qui est incroyable c'est que cela vienne de chez nous : j'ai régulièrement des sites chinois qui me visitent et qui repartent sans rien faire après avoir consulté le ROBOTS.TXT. Mais la BNF ne s'encombre pas avec ces subtilités.

Bonjour à tous, Depuis quelques jours, mon serveur Syno ne se mettait plus en veille. Pourtant j'étais certain de ne pas avoir activé les options qui empêchent la mise en hybernation des disques, et généralement l'usage de mon Syno est tel qu'il se met régulièrement en veille. J'ai donc réactivé le webanalyser et j'ai observé quelques jours : C'est la BNF (Bibliothèque nationale de France) qui est en train d'aspirer tous les sites du domaine .fr ! (je possède un nom de domaine en .fr qui pointe sur mon Syno). L'adresse IP qui passe son temps sur mon serveur est celle de la BNF : 194.199.7.23 Et le user agent est explicite : http://www.bnf.fr/fr/outils/a.dl_web_capture_robot.html J'avais pourtant pris soin de mettre à la racine un fichier ROBOTS.TXT au contenu explicite : il semble que le robot de la BNF ne respecte pas la Netiquette. Là où je suis plus inquiet, c'est que j'ai la désagréable impression qu'une bonne partie des photos que je stocke sur mon serveur ont d'ores et déjà été aspirées, alors même qu'elles sont toutes situées dans une section privée avec accès par mot de passe. Je me demande donc s'il n'y aurait pas une faille de sécurité.

Bonjour à tous, Merci pour vos réponses. Pour répondre à PiwiLAbruti, le daemon HTTP qui perme au Syno de répondre aux requêtes web n'empêche pas les disques de se mettre en veille.