Aller au contenu

red1

Membres
  • Compteur de contenus

    31
  • Inscription

  • Dernière visite

Tout ce qui a été posté par red1

  1. red1

    DSM 6.2.4-25556 Update 8

    Bonjour, je confirme aussi. J'ai pu mettre à jour mon vieux DS109 (hack DS112j) avec 6.2.4-25556 update 8, et ça fonctionne très bien.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.
  7. red1

    Vous H

    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)
  8. red1

    Vous H

    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 [...]"
  9. É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.
  10. Bonjour, Savez-vous s'il est possible d'utiliser le serveur LDAP du Syno pour gérer les comptes utilisateurs de Photo Station ? Merci.
  11. 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).
  12. red1

    Vous H

    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.
  13. red1

    Vous H

    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
  14. red1

    Vous H

    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.
  15. red1

    Vous H

    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é.
  16. 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.
  17. Bonjour, Ma question s'adresse à ceux qui ont activé la fonction serveur DHCP sur leur Syno, et qui auparavant n'avaient installé aucune fonction empêchant la mise en veille (comme un serveur mail par exemple) : Est-ce que l'activation du serveur DHCP empêche la mise en veille du Syno ? D'avance merci.
  18. Bonjour à tous, Je remonte ce post pour apporter quelques nouvelles à d'autres utilisateurs. Tout d'abord, j'ai réussi à activer ou désactiver à la demande la redirection permanente vers mon répertoire photo. Cette redirection passe bien par le fichier .htaccess dans le répertoire /volume1/web comme évoqué plus haut. Le souci que j'avais, c'est que je n'étais plus en mesure de changer quoi que soit dans la configuration du .htaccess : Si je changeais quelque chose dans ce fichier, ou si même je supprimais le fichier, la redirection était toujours effective. J'ai trouvé pourquoi : Pour que le contenu du .htaccess soit pris en compte, je dois redémarrer le serveur. Je précise que j'ai essayé de redémarrer sélectivement le serveur, notamment en redémarrant seulement Apache depuis le login root, mais cela ne semble pas fonctionner. Je me contente donc de redémarrer le serveur complètement (bouton en face avant ou commande "redémarrer" depuis l'interface de gestion).
  19. Je vous remercie pour tous vos conseils. Mais mon souci c'est que je suis redirigé dans le répertoire photo même en l'absence de .htaccess. J'avoue ne plus rien y comprendre...
  20. Je suis surpris. Je me souviens en effet nettement qu'au début où j'avais ce Syno, je devais donner le lien direct avec le répertoire photo, et que j'avais ensuite réglé le problème avec le .htaccess. Mais çà dépend peut-être de la version de DSM ? Au début j'étais en 3.0 (photo station 4 de mémoire). J'ai mis le .htaccess. Et depuis je suis passé en 3.2 (photo station 5). Dans ce cas essaye d'ajouter un .htaccess dans le répertoire web comme indiqué dans mon post initial.
  21. Bonjour à tous, Il y a quelques temps, j'avais configuré un fichier .htaccess dans le répertoire /volume1/web de mon Syno (DS109, DSM3.2-1955), de façon à rediriger de façon permanente toutes les requêtes http vers le répertoire photo : > pwd /volume1/web > more .htaccess RedirectPermanent /index.html http://www.mondomaine.fr/photo/ Aujourd'hui j'ai cherché à désactiver cette redirection automatique. Mais bizarrement, j'ai l'impression qu'en l'absence même du .htaccess, tous les flux sont encore dirigés de façon permanente vers le répertoire photo. J'ai lu quelque part que lorsque le blog était activé, cette redirection pouvait être permanente. Je ne sais pas si c'est vrai, mais en dans tous les cas le blog n'est pas activé. Je précise que le .htaccess est bien déroulé par le système : Si j'ajoute une redirection vers un autre endroit du site, cela fonctionne. C'est donc la preuve que le .htaccess sert à quelque chose. Mon souci, c'est que lorsque je le supprime, la redirection vers le répertoire photo fonctionne toujours. Sauriez-vous m'aider ? D'avance merci.
  22. red1

    DSM 3.2-1955

    Bonsoir, Effectivement, pour une raison que j'ignore, l'option journal de connexion DMA était activée. Je ne me souviens pas avoir coché dernièrement cette option. J'espère que cette modification de paramètre n'est pas une conséquence de la mise à jour. Enfin, un grand merci pour ton aide.
  23. red1

    DSM 3.2-1955

    Bonjour, Mise à jour faite depuis 2 jours sur un DS109. J'ai l'impression que depuis le disque interne ne veut pas se mettre en hibernation. Pourtant le paramétrage autorise bien l'hibernation au bout de 15 min. Une idée ? D'avance merci.
  24. Génial ! Merci les gars. Finalement le fait que la description soit modifiable directement et pas le titre, c'est assez déroutant. Je confirme que çà fonctionne parfaitement selon la méthode indiquée par Patrick.
  25. Bonjour, Merci de t'intéresser au sujet mais je suis un peu surpris de la réponse... Car il y a 3 choses distincts dans le Syno : 1) Le nom du dossier contenant les photos 2) Le titre de l'album 3) La description de l'album Quand on créé un album depuis l'interface de PhotoStation 5, on peut créer ces 3 éléments. Et clairement, si on spécifie un titre, il peut être différent du nom du dossier. Avec cette méthode, qu'on spécifie un titre ou pas à la création, dans tous les cas on ne peut plus le modifier a posteriori. C'est gênant. Par contre pour la description çà fonctionne bien. Quand tu créé un album sans l'interface de PhotoStation 5, tu créé donc un nouveau répertoire dans le répertoire "photo". Par défaut en l'absence de titre, le NAS donnera donc comme titre le nom du dossier. Et comme précédemment il ne sera plus possible de changer le titre. Lorsque j'ai fait l'upgrade de DSM2.3 vers 3.2 (PhotoStation 4 vers 5 donc), le nouveau PhotoStation a bien conservé les titres des albums qui étaient différents du nom des dossiers. J'imagine donc que l'information doit être stockée quelque part et qu'il est possible de la modifier. D'ailleurs, si le titre peut être différent du nom du dossier, c'est bien parce qu'il y a un intérêt. Et dans la mesure où le site Web de Syno spécifie qu'on peut changer le titre, j'aurais tendance à croire que c'est possible.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.