CoolRaoul

Vu qu'aucune documentation ne semble disponible, ça n'est pas prés de changer Je l'ai téléchargé, ca contient au contraire tout une arborescence de librairies (/usr/syno/lib), includes(/usr/syno/include) et binaires (/usr/syno/bin) Plus de 600 megas compressé quand même. Hélas, j'ai eu la flemme (j'ai honte ) d'apprendre à utiliser spksrc et je me suis bâti un petit environnement de cross compil perso pour mon archi, s'appuyant aussi sur la toolchain officielle. Voila pourquoi je me demandais si je dois migrer sur la version de toolchain étiquetée "5.0 beta" ou si une définitive va bientôt être diffusée. (cela dit apparemment la compatibilité ascendante me semble OK, donc il n'y a pas le feu)

Avant de tout de suite envisager des solutions radicales, serait-il possible de commencer par vérifier si le login/password d'un des comptes non admin est également refusé lors d'une connexion http, directement sur le GUI DSM, histoire de cibler un peu mieux ou se trouve le problème. Préciser quelle est la version de DSM utilisée aussi

Voulant mettre à jour mon espace de cross compilation par rapport a la DSM 5 je m’aperçois que sur l'espace "Synology NAS GPL Source" de Sourceforge les toolchain les plus récents sont dans un dossier toujours affublés de l'attribut "beta" A coté de ça je vois apparaître un répertoire "toolkit" mais donc la structure du contenu ne correspond pas à la documentation existante (http://ukdl.synology.com/download/ds/userguide/DSM_Developer_Guide.pdf) Bref je suis un peu pommé.. Si une bonne âme voulais bien me remettre dans le droit chemin **EDIT** Ma mémoire me faisait défaut: wayback archive m'a permis de constater que le toolkit existe depuis un bout de temps Reste ma question sur l'arrivée de la toolchain "non beta" et sur l'usage/documentation de ce toolkit Merci d'avance.

Je n'ai pas dit ça! Via PhotoStation on peut gérer les droits aussi finement que l'on veux (il a sa propre gestion de droits intégrée). Par contre il faut alors astreindre les utilisateurs du NAS à utiliser *exclusivement* photostation pour manipuler les photos (en limitant globalement les acces au partage "Photo" au seuls administrateurs : panneau de configuration -> dossier partagé -> photo -> modifier -> permission) L'autre approche est de ne pas utiliser Photo Station et choisir un autre dossier partagé que "photo" pour stocker ses photos.

Pour ceux que ça intéresse le chemin du doc à changé, c'est ici maintenant: http://download.synology.com/download//Document/FAQ/Synology_Download_Station_Official_API_V3.pdf

C'est comme cela que fonctionne le dossier "photo". Il n'est pas vraiment prévu pour être accédé autrement que via PhotoStation (qui a sa propre gestion de droits). Si on veut gérer les droits directement en acces direct (partage windows, filestation, etc ... ) à sa convenance il faut utiliser un autre dossier. (mais on ne pourra plus utiliser PhotoStation).

Je viens de m'apercevoir que Synology avait oublié de fournir avec DSM 5 le contenu complet du répertoire "zoneinfo" ("/usr/share/zoneinfo"). La conséquence est que de nombreuses commandes se retrouvent à récupérer des heures UTC car elles n'ont pas accès à la description de la timezone déclarée dans la variable TZ (qui se définit dans les options régionales, onglet "temps", rubrique "fuseau horaire" du panneau de configuration) Je me demande d'ailleurs au passage si cela n'aurait pas d'impact possible sur certains scripts PHP. Coup de pot, la distribution pgsql incluse dans DSM comprend sa propre copie du dossier zoneinfo. Ci dessous un petit script (à exécuter une seule fois et après chaque upgrade) qui résout le problème via des liens symboliques; #!/bin/ash PATH="/bin:/usr/bin" PGSQLDIR="/usr/share/pgsql-8.3" # sera sans doute à modifier dans les releases à venir cd $PGSQLDIR/share/timezone || exit 1 for tzdir in * do [ -d "$tzdir" ] || continue tzsysdir="/usr/share/zoneinfo/$tzdir" [ -e "$tzsysdir" ] && continue echo "fixing $tzdir" >&2 ln -s "$PWD/$tzdir" "$tzsysdir" done exit Résultat Avant: > echo $TZ Europe/Brussels > /bin/date -u Sun Mar 16 08:49:59 UTC 2014 > /bin/date Sun Mar 16 08:50:01 Europe 2014 # <-- GMT Apres: > /bin/date -u Sun Mar 16 08:50:32 UTC 2014 > /bin/date Sun Mar 16 09:50:33 CET 2014 # <- timezone bien prise en compte maintenant ***EDIT*** Je réalise que tout ce qui précède n'est pas forcément nécessaire: si le contenu de ma variable TZ était au format "<continent>/<pays>", c'était suite à une ancienne l'installation d'un package Java qui avait ajouté cette définition dans le ".profile" de root. Bien que le package ait été désinstallé cette définition était restée. Apres l'avoir supprimé, je me retrouvé bien avec un TZ défini "à l'ancienne" ("CET-1CEST,M3.5.0,M10.5.0/3" pour moi) qui n'utilise donc pas les fichiers "zoneinfo"

Tu peux "monter" ("mapper" si tu préfère ) des dossiers partagés du 2eme NAS dans des dossiers existants vides du NAS auquel tu es connecté via filestation. Dans file station utiliser le menu "outils -> monter le dossier distant"

Ah oui, bien vu En DSM 4.X les fichiers de conf apache étaient générées dynamiquement lors du démarrage et cette méthode ne s'appliquait pas ce qui explique que je n'y ai pas pensé.

Ou, plus rapide (puisque connecté en shell) le relancer avec la commande : /usr/syno/sbin/synoservicecfg --restart httpd-user

me semble bien avoir écris "il y a des fils à ce sujet dans le forum" Suffisait de chercher un peu, tiens voici: Mais je te conseille plutôt la deuxième solution (filtrage dans le firewall) bien plus facile à implémenter

On l'a quand même échappé belle: dans la beta certains étaient carrément absent du répertoire "modules". Si c'était resté comme ça la on aurait vraiment emm*

Allez, histoire d'en revenir au fondamentaux En DSM 4, la commande permettant de redémarrer le service web "user" ("/usr/syno/etc/rc.d/S97apache-user.sh restart") affichait clairement les erreurs a l'écran (dans le cas d'erreurs de syntaxe dans les fichiers de conf apache) Maintenant, que le script apache-user à disparu de rc.d, ne reste que "/usr/syno/sbin/synoservicecfg --restart httpd-user" mais on se retrouve aveugle. Le premier qui trouve une solution pour faire s'afficher les erreurs aura droit à toute ma gratitude

J'étais en train de te répondre sur cet autre fil avec la solution mais, le temps de trouver les références, je me suis fait doubler.

En fait c'est toujours supporté mais les modules requis ne sont plus chargés par défaut par apache Suffit de rajouter les bonnes lignes "loadmodule" dans le fichier "/etc/httpd/conf/httpd.conf-user" (ou mieux dans in fichier perso inclus par ce dernier) Voir ici: http://forum.synology.com/enu/viewtopic.php?f=232&t=79801&start=15#p308755 **EDIT** doublon!

C'est le port ssh par défaut qui est le plus attaqué. Utiliser un autre no de port entrant que le 22 (suffit de modifier la règle de redirection de port dans le routeur) est particulièrement efficace pour diminuer de façon drastique les attaques (je peux en témoigner) Par contre après ça, si on veut que la sauvegarde externe continue à effectuer il y aura des modifs de conf à faire sur l'autre NAS (il y a des fils à ce sujet dans le forum) Autre possibilité: dans la mesure ou l'ouverture de ce port est exclusivement réservée à la sauvegarde d'un NAS externe, ajouter dans le firewall du Syno une règle autorisant en entrée l'IP externe ce dernier (pou peu qu'il s'agisse d'une IP fixe) suivie d'une règle bloquant le port SSH pour toutes les IP et tu sera vraiment tranquille.

Non il sait faire les deux (cf le screenshot ci dessus) Syncback est particulièrement configurable au niveau de ce qui est filtré ou pas. les filtres peuvent être extrêmement précis. Si le fichier est modifié très souvent, CloudStation peut avoir l'inconvéient d'être trop réactif alors qu'on souhaite juste synchroniser qu'une fois par jour par exemple

Ah non je répondais à la partie "automatiquement /../ à une période donnée." Sinon c'est demandé au moment de la creation du profil: Ensuite il est possible d'affiner dans les options de la tache (partie décision) On est parti sur syncback car au début du fil la question était "Je cherche logiciel pour faire des sauvegardes" De plus si l'objectif est de faire une synchro d'un seul fichier, comme il semble, Cloud Station n'est pas adapté

La fonction de planification (schedule) est faite pour ça il me semble

J'ai effectivement rencontré un comportement erratique de cloudsync que j'ai voulu tester pour savoir comment ça marche. Me suis trouvé devant un blocage quasi complet du NAS, bien possible que ce soit lié. J'ai désactivé ce package, on verra plus tard (déjà le fait qu'il ne soit pas capable de synchroniser juste un sous-répertoire du service cloud, que ce soit Drive ou Dropbox est éliminatoire pour moi) Depuis pas encore de nouveau problèmes. Non, j'ai fais la mise a jour. C'est à la beta que je n'avais volontairement pas participé. Juste oublié de mettre à jour ma signature du forum. Il est surtout important de *systématiquement* ouvrir un ticket de support des qu'on rencontre un dysfonctionnement. me souviens avoir insisté sur sur point lors de la phase beta, car je suis persuadé que nombreux sont ceux qui y ont participé juste pour voir à quoi ca ressemble en négligeant de faire remonter les problèmes par le canal officiel. Voila qui est fait

Moi non plus (c'est d'ailleurs la première fois que j'utilise cet argument) maiss les attaques directes comme les tiennes (la qualité de mes interventions maintenant ...) sont toujours dures à avaler. Faut parfois savoir se modérer, ça encourage les autres à faire des efforts à chercher des solutions. **EDIT** Commence à me chatouiller de me désabonner de ce fil. Dommage il y avait des infos interessantes

J'ai plus de 3500 messages à mon actif sur le forum, je t'engage a les lire en intégralité et on en reparle;

Faudrait citer le message auquel tu répond, sinon on va décrocher de la compréhension du fil.

Enfin tu a quand même écris: De mon coté, vu que je ne suis même pas capable d'établir des stats pour comparer le volume de feedbacks négatifs par rapport aux M.A.J précédentes je me garderai bien d'être aussi catégorique dans un sens ou dans un autre. D'autre part ce n'est pas le nombre de posts qui est important, mais le nombre de posteurs. Enfin pas oublier que certains problèmes remontés sont liés à de nouvelles fonctionnalités (cloud sync par exemple). Vu que déjà, si on cherche la stablilté, il est conseillé d'attendre un peu avant toute version majeure (et qui plus est une release majeure) une fois le cap de l'upgrade franchi, au moins toujours rester prudent sur les nouveautés.

Euh .. je ne répondais qu'à jcpamart (c'est pourquoi que je l'ai cité d'ailleurs) qui soupçonnait explicitement un problème de droits dans son cas perso. Qaudn à ton pb de CPU un petit "top" pourrait nous mettre sur une piste