CoolRaoul

Je ne pense pas qu'ils aient changé d'avis (que je partage d'ailleurs). Où ça? Dans ce fil? Les derniers messages ne parlent que de WiFi AC (5GHZ) qui rien à voir avec l'agrégation de liens (LACP)

Il est ici et je viens à l'instant d'y incorporer les adaptations (mineures) pour DSM6.

Ce matin j'ai voulu éditer mon tuto "reverse proxy avec NGINX" pour y intégrer les quelques modifs nnécessaires à la compatibilité DSM6 A peine en mode édition je constate que tout passe en noir et blanc: plus de colorisation des blocs "code". C'a m'a découragé d'aller plus loin C'est définitif ou on a un espoir que ce soit rétabli?

Je pense qu'on peut considérer la méthode décrite dans ce fil comme obsolète. J'ai fait plus récemment un autre tuto dans le même section du forum sur une approche basée sur nginx. Cette dernière fonctionne toujours en DSM6 sous réserve d'y faire des modifications mineures décrites dans les derniers posts du fil (faudra que je mette à jour je premier post pour les intégrer au tuto). Mais, enfin et surtout, DSM6 supporte désormais nativement (dans le "portail des applications") la mise en place de fonctionnalité reverse proxy. Ça reste basique mais devrait répondre cependant à la majorité des besoins.

Je confirme

Toujours dans le processus de détérrage de topic, un scan TNT via mon dongle PCTV 73e qui fonctionnait correctement (enfin ça fait longtemps que je ne l'avait pas utilisé j'avoue) ne me trouve plus rien. Connecté au PC, même pièce, même antenne avec le même angle de reception emmeteur c'est OK. Je suis perplexe sur le diagnostic: ca vaut la peine d'investir dans un autre modèle? Et si oui lequel?

Apparemment il installé optware dont le package gcc: configure:2912: found /opt/bin/gcc configure:2923: result: gcc configure:3152: checking for C compiler version configure:3161: gcc --version >&5 gcc (GCC) 4.2.3 Mais bon, ce truc (optware) étant désormais complètement abandonné, je conseillerais également la voie de la cross-compilation (j'avais d'ailleurs moi-même cross-compilé inotify-tools, de ce que je me souviens il n'ya quasiment pas de dépendances donc c'est sans trop de problèmes) Mais pas oublier non plus que le tuto en question date de 2010, plus tout récent et probablement obsolète.

En utilisant une version hackée de DSM faut pas s'attendre à pouvoir en faire les upgrades directement. Pas plus qu'espérer un support constructeur (déjà qu'ici, dans un forum dont le lien est donné sur le site officiel, c'est il me semble un peu limite) Pour info: http://www.cachem.fr/xpenology-mot-fin/

Que vient faire ici cette question sans le moindre rapport au thème du fil, ce dernier datant en outre de plus d'un an et demi (août 2014)?

Il y a eu récemment un long fil sur le sujet : La conclusion que j'ai tiré de sa lecture c'est que la détection d'un Iphone sur un réseau wifi c'est autrement plus coton que n'importe quel autres appareil qui répond au "ping". **edit** Trouvé ce fil sur le même sujet (je reconnais par contre que ca ne donnera pas forcément de solution)

Ah, je m'étais laissé embarquer par le message "authorization failure" relatif à une connexion anonyme (qui n'aurait pas collé avec cette explication). Mais je viens de réaliser, vu que l'ordre est chronologique de bas vers le haut, qu'il est antérieur. Désolé pour la mauvaise piste.

Vu qu'il s'agit d'une connexion FTP anonyme at que le log dévoile une erreur d'authentification je conseille pour commencer de vérifier que tout est bien configuré comme détaillé ici

T'inquiète, y a des workarounds (on en a discuté dans un fil voisin). Une simple édition de "/etc/sudoers" plus bidouille du ".profile" du compte "admin" devraient suffire à rendre le tout quasi transparent.

Depuis la dernière beta DSM6, le login root n'est plus possible directement. Faut se logger "admin" (ou un compte du groupe des admins) et faire un "sudo -i"

Comme je l'ai dit à plusieurs reprises, le problème n'est pas seulement d'avoir ou pas lu l'avertissement, mais de l'interprétation qu'on doit donner à "downgrade". Mon PC perso est sous Windows 7, je peux ressortir un vieux DVD Vista, reformater et l'installer si ça me chante. Jamais je ne parlerais de "downgrade" pour décrire cette opération. Pour moi un *downgrade* s'interprète comme une descente de niveau de version en conservant données et settings, et ça, je comprend tout fait que se soit difficile sinon impossible à réaliser et par suite qu'on éditeur/constructeur annonce ne pas le supporter. Et me reste surtout à comprendre la raison de cette limitation (apparemment volontaire). L'explication "commerciale" donnée par Piwi a du mal à me convaincre (je ne vois pas la logique) ***EDIT*** Dans le panneau de configuration DSM ,dans "terminal et sécurité" (enfin, c'est comme ça en DSM5, pas de raison que ça ait beaucoup changé) Non (enfin, ca serait possible avec winscp, mais avec les nouvelles restrictions de DSM6 c'est un peu coton). Le mieux est d'utiliser un émulateur de terminal supportant SSH, putty est le plus répandu. Vu que tu as écris te retrouver "loggé sous un compte nommé admin sans mot de passe", une fois loggé y a plus qu'a le créer ce mot de passe, dans le panneau de conf DSM, rubrique "utilisateur"

Comme je l'ai écrit dans une autre réponse je trouve que ca reste soumis à interprétation: il est juste question de "downgrade" impossible. Ayant également lu cette indication je ne l'avais pas interprété comme une *impossibilité* de vrai factory reset. (faut avouer que je ne me suis pas senti pas trop concerné: ne disposant pas d'un exemplaire de test, je n'ai pas envisagé d'installer cette beta. Par suite j'ai pas creusé le sujet). **EDIT** Dans le même esprit (et c'est peut-être ce qui a orienté mon interprétation), il n'existe pas (à de rares exceptions près) de possibilité d'upgrade (et encore moins de downgrade) entre version majeures de RedHat/CentOS (ref) et plus particulièrement de 5 en 6, mais, bien entendu, un matériel préalablement installé en n'importe quelle version peut être toujours réinstallé en n'importe quelle autre.

Le formatage lent de devrait rien changer (à part perdre du temps) par rapport au formatage rapide Si la manip indiquée (modification de "/etc.defaults/VERSION" ) fonctionne il faudrait, suite à un nouveau reset par appui long, reinstaller DSM6 beta, faire une config minimale, activer SSH, se connecter en SSH (comte admin) puis "sudo vi /etc.defaults/VERSION") Ensuite, c'est reparti pour un reset puis install de DSM 5 en fournissant le .pat de la version 5.2 de DSm (à récupérer ici) PS: noter qu'en installant une beta faut être prêt à rencontrer potentiellement n'importe quel problème plus ou moins grave.

Je veux bien comprendre qu'il n'existe pas de méthode supportée de downgrade conservant les données et encore moins les settings (c'est d'ailleurs comme ça que j'avais interprété "Not downgradable") Par contre, rendre impossible un véritable "factory reset" avec full wipe , je trouve ça franchement stupide. Quel peut en être l'objectif? N'est-elle pas contradictoire avec l'explication de la version inscrite en dans l'espace de mémoire flash cette méthode? Il y est question de modifier un fichier dans "/etc/defaults". Sur mon modèle en tout cas ce dossier n'est pas en mémoire flash.

Que faut-il comprendre par "dans le NAS" ? Il y a un espace de stockage autre que les disque dur? Si c'est confirmé ca signifie qu'il est impossible de faire un reset usine d'un Syno (le remettre dans l'état initial tel qu'à l'ouverture de la boite). A quoi pourrait bien servir cette limitation?

Tiens, j'ignorais. Je pensais que la procédure d'installation "from scratch" permettait (optionellement) de réformater le(s) disques, et par suite, la partition système. Bon, suffit d'écraser les partitions en le connectant à un PC alors.

Il y a deux procédures présentées dans la page, c'est la deuxième ("Réinitialiser pour réinstaller le système d'exploitation") qui permet de réinstaller le firmware.

https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS#t3

Ceci peut-être:

Automatiquement c'est impossible: c'est un paramètre de la box.

Comme d'habitude, s'agit d'une Nème bug de type buffer overflow: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547 Pour provoquer le risque de "remote code exécution" faudrait pouvoir injecter une réponse DNS appropriée ("possibly execute arbitrary code via a crafted DNS response", bien noter l'emploi du conditionnel ici) et s'arranger pour que l'application se déroute sur du code binaire fourni à la volée dans la réponse (ça fait beaucoup de "si" n'est-ce pas?) Pas de raison de s'affoler d'autant plus que je ne pense pas qu'il existe un exploit démontré.