CoolRaoul

Tu ne te rends certainement pas compte de tous les pré-requis nécessaires pour faire tourner un Firefox: tout un paquet de librairies dont certaines ayant très peu de chances de se trouver sur un NAS. Ensuite la partie graphique de Firefox (et de tous les autres navigateurs Internet) s'appuie sur X11, qui fonctionne en mode client /serveur avec le moteur graphique s'exécutant sur le poste qui dispose de la carte vidéo (pas sur le NAS donc). Il est donc requis d'installer ce logiciel sur le PC. Et pour faire communiquer ce petit monde ce n'est pas trivial. D'autres approches sont possibles (via VNC) mais la aussi faut bidouiller. Bref, tu n'est pas prêt de voir quelqu'un prendre la peine de porter firefox sur un NAS C'est comme si tu demandais Libre Office sur Syno.

Je viens de recevoir à l'instant la réponse du support Syno, le problème est déjà connu et un hotfix est déjà dans le pipe.:

Peut-etre une solution coté Windows en bidouilllant cette clé de registre (a faire pour chaque compte PC): HKCUSoftwarePoliciesMicrosoftOffice14.0CommonOpen FindRestrictedBrowse Ou mieux, via une policy si il s'agit de postes en domaine: ref: http://technet.microsoft.com/en-us/library/ee308297(v=office.14).aspx

Cloudstation n'est pas un système de sauvegarde, il est donc nécessaire aussi d'avoir une sauvegarde des données simultanément.

As-tu regardé du coté de CloudStation? Je pense que cela répondrai mieux a ton besoin;

Mon propos n'était pas de donner un avis, mais de mettre en avant une fonctionnalité de TimeBackup qui deviendrait impossible sans utiliser les hardlinks. J'ai l'impression que ce que tu recherches est un système de gestion de version basé sur une vue orientée *fichier*, TimeBackup présente une interface avec une vue orientée *chronologique* et répond donc à un besoin différent. Ce n'est tout simplement pas l'outil adapté à ton besoin. Tu devrais envisager de chercher des solutions tierces je pense.

Je n'ai pas d'explication non plus, mais l'important est que ça marche maintenant.

Sinon, tant qu'on y est, il est possible d'installer sur le Syno le package debian Debian chroot de la communauté () Sera possible d'avoir n'importe quel navigateur supporté par debian mais la connexion sera pas des plus simple à mettre en oeuvre: lancer un serveur X sur le PC client (cygwin, xming par exemple) se connecter ssh sur le syno avec le tunnel X11 actif (via pageant par exemple) lancer le navigateur dans le contexte debian chrooté Mais je ne garantis pas les perfs (bonjour la conso mémoire déjà ...) et m'étonnerait pas que j'oublie quelques pre requis.

Tu n'aura pas alors la possibilité de "voir" une image complète de répertoire à une date donnée ce qui est quand même une fonctionnalité essentielle de timebackup. Tu remarquera qu'Il est possible de se ballader dans n'importe quel dossier archive de TimeBackup et de se retrouver exactement dans l'état ou étaient les dossiers sources à l'heure et date correspondante.

Un autre truc étonnant est que tu n'ai pas eu à mettre cette règle dans le firewall en 4.1: chez moi sans ça, ça ne fonctionnait pas. A moins que tu ne nous ais pas tout dit et suggéré une mauvaise piste en ciblant ton passage sous DSM 4.2, n'aurais-tu pas activé le firewall ou modifié sa configuration depuis ?

Ce n'est pas une mauvaise idée, c'est la seule façon de faire

Avec ipconfig /renew non plus? Parceque sinon, une fois que le PC a son IP allouée par DHCP, il ne va pas en redemander le renouvellement tant que le bail n'est pas expiré. Faut au moins le rebooter pour ça.

D'autant plus que ça ne serait pas le seul endroit ou les outils DSM s'emmêlent les pinceaux avec les hardlinks pour calculer la place disque Cf ici:

C'était pas forcément clair dans ta description La au moins plus de doute Pour que DHCP fonctionne j'ai du autoriser le port 68 (en port *source* attention) dans le firewall du syno, comme cela: Ca ne serait pas ça ton probleme?

Oui, enfin optware n'est pas un truc qui tourne en tache de fond non plus, tant que tu n'en utilise pas les commandes ca ne peut pas interférer avec DSM. Faut voir ça un peu comme cygwin sous windows. Car si on prend ton commentaire à la lettre ("pas installer autre chose que les packages validés par Synology") ce reviendrai a ne rien mettre sur les disques du NAS... ==> Etrangement, d'apres l'aide en ligne, le "du" DSM devrait aussi savoir gérer aussi les hardlinks (du -h indique "-l Count sizes many times if hard linked"), donc on pourrait croire que sans le "-l" c'est bien géré mais en fait non. Dommage, on aurait pu faite sans optware. C'est sur que les hardlinks, vu a travers un montage réseau SMB faut pas trop espérer que ce soit détecté par windows. Je n'ai pas dit le contraire. Le but était d'analyser en détail *ou* cette place était occupée. Le "du" optware t'aurai permis ds savoir *exactement* la place consommée, dossier par dossier. Chaque "junction" comme tu dis (hardlink en fait), occupe exactement un inode, ce qui n'est pas grand chose. Ce ne sont pas des "junctions" entre répertoires au sens Windows (correspondant à la commande windows "mklink /j") mais des liens *physiques* (équivalent de "mklink /h") et c'est la seule façon d'avoir multiple images de répertoires à des instants donnés en mutualisant l'espace disque pour les fichiers non modifiés. A moins que tu ais une meilleure solution, perso je ne vois pas.

Ceci devrait être plus robuste: #!/bin/sh PATH=/bin:/usr/bin logfile=/tmp/$(basename $0).log if [ "$1" == "" ] ; then # on se relance mais cette fois en se detachant nohup $0 "CALLBACK" </dev/null >$logfile 2>&1 & exit 0 fi # a partir d'ici on s'execute de facon autonome MY_DDNS_CONF="/usr/local/etc/ddns_provider.conf" DDNS_CONF="/etc/ddns_provider.conf" cmp -s $MY_DDNS_CONF $DDNS_CONF && exit # fichier identiques: rien a faire # attente active que DDNS soit demarré, 5 minutes au total tries=30 # nombre de tentatives delay=10 # secondes until killall -q -0 ddnsd ; do sleep $delay tries=$(expr $tries - 1) if [ $tries -eq 0 ] ; then # toujours pas de DDNS, on laisse tomber echo "service DDNS inactif" >&2 exit 1 fi done cp $MY_DDNS_CONF $DDNS_CONF /usr/syno/etc/rc.d/S09DDNS.sh restart remarques: J'ai cru comprendre que ce que tu souhaitais étais simplement de maîtriser la config ddns, donc mieux vaut utiliser comme référence un fichier non touché par DSM, j'ai pris "/usr/local/etc/ddns_provider.conf" Ceci constitue un script autonome (le mettre par exemple dans "/usr/local/bin/fix_ddns_conf"), qui doit être appelé au boot, à partir de /etc/rc.local ou d'une autre manière. des qu'il est invoqué, il se relance lui-même en mode détaché et attend que ddns soit démarré pour faire la manip au moment opportun. ne pas hésiter à me corriger si je n'ai pas bien compris l'effet souhaité **EDIT*** Attention a bien éditer "/usr/local/etc/ddns_provider.conf" avant de lancer le script la 1ère fois! **EDIT#2** fixé grammaire et orthographe

Voila, voila ... Théoriquement, pour respecter strictement ta spec ceci devrait faire l'affaire (à mettre dans un script autonome, lui même invoque par /etc/rc.local #!/bin/sh # 1- Vérifier que "/etc/ddns_provider.conf" et # "/etc.defaults/ddns_provider.conf"sont identiques # # 2- Si ils ne sont pas identiques, copier le fichier # "/etc/ddns_provider.conf" et le coller dans # "/etc.defaults/ddns_provider.conf" en écrasant l'ancien # 3- Si la 2ème étape a eu besoin d'être effectuée, rebooter le syno PATH=/bin:/usr/bin A_FILE="/etc/ddns_provider.conf" D_FILE="/etc.defaults/ddns_provider.conf" cmp -s $A_FILE $D_FILE && exit # fichier identiques: rien a faire cp $A_FILE $D_FILE reboot Mais attention, faire un "reboot" lors de la séquence de startup (puisque appelé par rc.local), je ne pense pas que ce soit une très bonne idée. Le boot DSM exécute certaines parties en parallèle, ton reboot va arriver comme un poisson dans l'eau en plein milieu de cette séquence tandis que d'autre opérations sont en train de se dérouler (démarrage des packages par exemple) et ca risque de mettre un joyeux souk. Déja, a la place du reboot peut-être se contenter d'un simple /usr/syno/etc/rc.d//S09DDNS.sh restart serai moins violent Mais meme dans ce cas, et a cause du parallellisme du démarrage, ton rc.local peut tres bien être exécuté avant ou apres le démarrage DDNS, ou pire ... simultanément! Tu vois, c'est pas si simple. Je vais essayer de trouver une solution plus robuste Stay tuned...

Si tu disposes de la commande "du" d'optware (ipkg) tu peut avoir une idée précise de la place réellement occupée par les différents dossier images timebackup. Commencer par se déplacer dans le dossier cible de timebackup La dessous tu devrais avoir un sous dossier avec un nom du style "<hostname>_XXXXXXXXXX", et en dessous un autre nommé "task_<n>" (chez moi par exemple, ça donne "/volume2/backups/TimeBackup/fserv_00113205F256/task_8") Une fois dans le répertoire "task_n", tu utilise la commande "du -sh *" (en s'assurant de bien utiliser le "du" optware et pas celui intégré a dsm). Cela va afficher un rapport d'utilisation de chacun des dossiers images timebackup avec prise en compte unique des fichiers multiplement liés (ce que ne fait pas /usr/bin/du), par conséquent l'espace disque réellement occupé, dossier par dossier

Sur quoi te bases-tu pour supposer que ce que tu constates est causé par le serveur DHCP? Tu peux faire le test sous windows en ligne de commande: ipconfig /renew Est-ce que cette commande met longtemps à répondre? Si non ce n'est pas le serveur DHCP le coupable.

http://www.dd-wrt.com/wiki/index.php/Netgear_WNDR3700

Il me semble (reste à démontrer) qu'il se pourrait que certains scripts de démarrage (dans /usr/syno/etc.defaults/rc.d/) pourrait fonctionner de façon asynchrone. Résultat, quand "/usr/syno/etc.defaults/rc.d/<machin> stop" rend la main, <machin> n'est pas forcément encore arrété. Voila pourquoi, je pense que "S95sshd.sh stop" va se contenter d'initialiser l'arret du démon ssh, arrêt qui ne sera effectif que lorsque *toutes* les sessions ssh existantes se seront terminées. Je suppose que lorsque tu as voulu arréter le service ssh, tu était toi-même connecté par l'intermédiaire d'une session ssh non? C'est pour éviter cela: que ssh reste actif je pense:

C'est confirmé: http://www.justanswer.com/computer-networking/3xkm2-forward-external-port-8008--wndr3700.html Décevant quand on sait que la première BOX modem/routeur fournie par la plupart des FAIs sait faire ce genre de chose.

Le test que je demandais de faire était d'ajouter explicitement une ACL pour le groupe "administrateurs" ? Faudrait essayer même si ça peut avoir l'air bizarre. Ce n'est pas obligatoire: une application (de la part de Microsoft on peut s'attendre a tout) peut tout à fait récupérer, d'une part la structure de donnée correspondant à l'ACL, d'autre part la structure correspondant a la liste de droits du process et tenter de vérifier elle-même les droits, plutôt que l'approche, a priori plus "naturelle", de tenter l'ouverture du fichier en écriture et d'intercepter l'éventuelle erreur . Si tu veux savoir exactement ce qui ce passe je t'invite a utiliser process monitor sur le PC, c'est un outil absolument extraordinaire pour "espionner" ce que fait un process en temps réel. Il va te permettre d'auditer quels sont les API invoquées par Office et voir les codes retour. Ce devrait aider pour voir exactement ou ça et ce qui coince. En parallèle, activer la trace SMB dans DSM (panneau de conf -> Win/Mac/Nfs -> Service de fichiers windows -> activer le journal des transfert) peut aussi aider à identifier ce qui se passe.

Peut-être qu'office starter interprète mal l'autorisation *implicite* donnés aux utilisateurs du groupe administeurs d'accéder aux dossiers. Une piste: essayer d'ajouter une autorisation *explicite* sur ces dossiers en ajoutant une entrée d'ACL donnant droit de lecture/ecriture (ou plus) sur ces dossiers à ce groupe

Ca peut demander une manip supplémentaire; On en a discuté ici le cas de la sauvegarde cryptée (via ssh donc):