Yokav

J'ai des gigaset aussi, je n'ai pas pensé à tester avec mais bon si ça fonctionne avec un téléphone, ça devrait fonctionner avec un autre logiquement. Ici je test avec des postes fixes Cisco de la série SPA50xG. Et j'indique bien les mêmes infos que toi pour ma config, je ferais tout de même un test avec une base gigaset demain pour en avoir le coeur net.

Moi je n'arrive même pas à connecter mon téléphone via sip, je suis encore loin de votre config. Pour info, je viens de refaire un test et je suis toujours bloqué. J'ai même désactivé le firewall, me suis dit peut-être qu'un port non référencé est bloqué. Là on touche à la fin de journée , mais dés demain matin j'ouvre un ticket pour savoir si pour eux (synology) leur paquet est clairement fonctionnel ou pas. Et je vais creuser du côté des logs de asterisk car la page de logs affiché via la GUI reste désespérément vide...

Oui, le bouton situé en haut à droit, je le fais à chaque fois pourtant. Je vais vite refaire un nouveau test, une erreur d’inattention de ma part peut-être. Mais sinon, ma brève procédure de test te semble-t-elle correcte ? En fait, pour m'éviter de devoir lire en long et en large le manuel de asterisk, je vais demander à un professionnel de me configurer asterisk mais j'aimerais m'assurer avant que tout soit bien ok... Toi qui est souvent au courant des derniers faits, tu ne sais pas si d'autres personnes ont réussi à se servir pleinement de asterisk ?

J'ai profité de la mise à jour pour faire un nouvel essaie mais pour ma part, je n'arrive même pas à connecter mon téléphone à asterisk. Avant de m’aventurer dans une config avancée, je voudrais m'assurer que les "bases" sont fonctionnels. Pour cela, tout ce que j'ai fait jusqu'à présent c'est créer un compte utilisateur sous asterisk (compte 6000) et ajouter ce compte à mon téléphone sip, aurais-je oublié quelque chose de primordial ? Pour la config du compte sip sur le téléphone, je lui indique de se connecter à l'ip de mon nas, on utilisant comme login "6000" et le mot de passe que j'ai indiqué lors de la création du compte. Tout en passant bien par le port sip 5060. Mon téléphone sip m'indique qu'il n'arrive pas à s'enregistrer et les logs de asterisk restent muets... C'est sur, je dois mal faire quelque chose mais quoi...

Tiens à ce propos, si on accède au NAS depuis l'extérieur en indiquant son IP, on est justement pris dans cette règle par défaut et on termine sur le backend "web" ? Et, est-ce que HAProxy prend en compte les sous-domaines de second niveau ?

Sans vouloir enfoncer le clou, Diaoul a raison, un peu de lecture te ferais du bien. Il n'est pas aisé de manier un nouvel outil sans en comprendre son fonctionnement. Voici cependant ce qui devrait t'aider à résoudre tes problèmes... Tu parles beaucoup du port 443 alors que logiquement tu ne devrais pas t'en soucier plus que ça. Il ne faut pas faire de lien direct entre les ports situés avant HAProxy (internet) et les ports situés après HAProxy (réseau local). Tu dois juste déclarer deux ports dans ton routeur, le qui redirige vers le 5080 et le port 443 qui redirige vers 5443, c'est tout, rien de plus ! Le reste étant à configurer sur le Proxy et le NAS. Et encore, si tu es le seul à te connecter à distance à ton NAS et que tu n'utilises que du https, tu peux même virer la redirection du port . Et maintenant, côté réseau local on a HAProxy et le NAS, HAProxy étant chargé de faire le lien entre les sous-domaines en provenance d'internet et les ports utilisés sur le NAS, chaque sous-domaine étant redirigé vers un port précis (port qu'il faudra ouvrir dans le pare-feu du NAS bien entendu). Pour finir, une petite précision concernant WebStation (dont dépend Photostation). WebStation est dédié à l'hébergement de sites internet, plusieurs sites se retrouvent donc sur une même "application" qui utilise un seul et même port le . Pour pouvoir y accéder, on doit alors utiliser des sous-répertoires (http://ip-du-nas/sous-repertoire) hors il n'est pas possible à HAProxy de prendre en compte ces sous-répertoires. On va donc indiquer à HAProxy de faire pointer www.domaine.tld et domaine.tld vers le port du NAS, qui est utilisé par WebStation. Et lorsque tu voudras accéder à Photostation, tu devras indiquer son sous-réprtoire dans l'url afin que ça donne ceci : http://www.domaine.tld/photo.

Oui, c'est bien ça. Internet <<-- httpS -->> HAProxy <<-- http -->> Applis du NAS. Faire du httpS entre HAProxy et les applis du NAS n'a pas vraiment de sens et risque juste de consommer plus de ressources qu'autre chose. Il est important de sécuriser tout ce qui transite par internet mais pas besoin pour ce qui transite en local.

Merci pour les précisions Diaoul, c'est que j'avais cru comprendre dans un de tes précédents messages que seul le protocole HTTP était fonctionnel et que toutes les fonctionnalités n'étaient pas intégrées. Donc si finalement, pas mal de fonctionnalités sont incluses et que ça consomme pas trop de ressources, je vais finir par le tester aussi.

Oualala on est pas sorti de l’auberge... Pour ma part, je vais contredire aurelized en répondant "Oui" à la question de patobiskoto. (Voir le sur le reverse proxy)

Pour ma part, d'après l'application qui en a été montrée jusqu'à présent, ça ne fais rien de plus que ce que peut faire le ReverseProxy. Tout en consommant certainement bien plus de ressources. J'en profite donc pour faire remonter une question restée sans réponse

HAProxy peut-il traiter d'autres protocoles que le HTTP ? L'idée serait par exemple de pouvoir utiliser un autre port que le 22 pour SSH sans devoir toucher au fichier de config de SSH (vu que rien n'a été prévu dans DSM pour le modifier). Et peut-on faire pointer HAProxy vers un sous dossier ? Ce qui donnerait http://soudomaine.domaine.tld: <-> HAProxy:5060 <-> http://localhost:80/monsousdomaine. Cela permettrait de limiter les accès aux sites internet depuis l'extérieur, le port pourrait même être fermé pour les accès externes.

Toujours rien du côté du centre de paquets... Si ça peut aider, voici la liste complète des paquets que je peux installer depuis le centre de paquets :

Merci pour cette réponse détaillée ! Pour l'histoire du ftp, mea-culpa, tu dois avoir raison. J'ai même de mal à reproduire l'exemple que j'ai décris. Pour le NFS par contre, ce n'est pas encore très clair, je vais faire quelques recherches sur google à ce propos. Les questions qui me viennent à l'esprit c'est comment faire pour "mapper" l'uid de l'utilisateur du pc sous linux et celui de l'utilisateur sur le syno. Et puis niveau sécurité, car une adresse ip et un uid, ça me semble un peu léger comme vérification.

Je reviens sur ce sujet... Supprimer l'indexation ne m'intéresse pas non plus, on peut cependant appliquer le reste des recommandations en provenance du site cité dans mon premier message. Pour supprimer automatiquement tous les dossiers @eaDir en ligne de commande : # cd /mon/repertoire/a/nettoyer # find . -name @eaDir -print | while read n ; do echo $n ; rm -rf "$n" ; done Désactiver deux daemons qui semblent créer des miniatures pour les images et les flv. # cd /usr/syno/etc.defaults/rc.d # ./S77synomkthumbd.sh stop # ./S88synomkflvd.sh stop # chmod 000 S77synomkthumbd.sh S88synomkflvd.sh

Alors, le choix de CIFS s'explique par le fait que lors de diverses recherches, on mettait souvent ce protocole en avant car plus stable et permettant des vitesses de transfert plus importantes. J'ai néanmoins voulu remettre en place une connexion NFS récemment pour justement palier à ces problèmes de permissions mais ma connaissance de ce protocole s'avère bien limitée, j'ai été bloqué quand j'ai vu que l'on ne pouvait pas spécifier de login/mdp pour le montage d'un lecteur NFS. J'ai trouvé par la suite que les droits étaient visiblement donnés en fonction de l'adresse ip... Si tu peux m'en dire un peu plus à ce sujet, je suis preneur ! Et pour l'histoire du ACL, je suis persuadé de mon coup... bien que un peu tordu, il montre les limites de l'ACL. Voici la procédure à appliquer et qui prouve que l'ACL ne prend pas le dessus sur les permissions Linux. - On crée un dossier avec une règle ACL donnant les droits en lecture et écriture à tous les groupes pour ce dossier et ses sous-dossiers, fichiers, etc. - On se connecte en FTP avec un compte utilisateur A, on crée dans le dossier principal un sous-dossier nommé "Dossier A", on y ajoute quelques fichiers et ensuite on change le chmod de ce dossier en 755 (dans le but d'empêcher la suppression du contenu par tout autre utilisateur). - On se connecte en FTP avec un compte utilisateur B, même si selon la règle ACL on devrait pouvoir supprimer le contenu du sous-dossier "Dossier A" ça nous est impossible. Je rajouterais aussi que l'option "directory_mode" et "file_mode" est très importante ! Car elle va permettre de décider quel chmod sera appliqué lorsque l'on se connectera à un dossier partagé (avec des permissions Linux) depuis un ordi sous windows. Car par défaut un chmod 777 pour les dossiers et 700 pour les fichiers est appliqué de mémoire. Ce qui est un peu trop permissif à mon goût. Ça fait quand même ressortir le fait que c'est un joli méli-mélo à ce niveau là.

Bonjour, Cela fait un moment que j'utilise des NAS synology mais malgré tout, c'est un contexte que j'ai encore du mal à cerner. J'utilise plusieurs dossiers partagés, certains sur lesquels sont activés les règles ACL et d'autres non. Et j'accède à chaque dossier depuis Windows et Linux. Tant que l'on reste dans le cadre classique Windows <-> ACL tout va bien. Par contre lorsque l'on passe à Linux <-> ACL, voir même Linux <-> Permissions linux, ça devient plus compliqué. Prenons l'exemple de connexions au système de fichiers via samba, mais le problème est similaire avec d'autres services tel que le ftp. Sous linux, je me connecte via CIFS à un dossier partagé avec les permissions Linux. Là le problème se situe au niveau des permissions affectées par défaut, rien a été prévu pour spécifier un "directory mode" ou "file mode" sous DSM, faut donc rajouter ça manuellement dans le fichier de config de samba et le remettre à chaque lancement de samba. Sous linux, je me connecte via CIFS à un dossier partagé avec les permissions ACL. Là, faudrait que chaque dossier créé soit en chmod 777, malheureusement même avec le directory mode, j'arrive pas à dépasser le chmod 755. Résultat, même si on est dans un système ACL et qu'un utilisateur devrait pouvoir supprimer un dossier, si ce dernier est sous un chmod 755, ça ne passe pas.

Merci à tous les deux pour vos réponses. J'en sais un peu plus sur le fonctionnement de nos syno désormais. Vivement que le paquet soit de nouveau dispo, que je puisse l'essayer. Ça va me laisser le temps pour revoir un peu les commandes debian, ça fait longtemps que je n'ai plus fait un "apt get update". @Diaoul: Je viens encore d'actualiser la liste des paquets pour être sur mais je ne le vois toujours pas. Pourtant je me rappelle l'avoir déjà vu, il utilisait d'ailleurs comme icône le logo de Debian.

Étrange, chez moi que ce soit sur un DS213+ ou un DS710+, je ne vois plus ce paquet... Et si possible, j'aimerais avoir encore une ou deux précisions sur Debian Chroot. L'os de synology m'a toujours semblé être bâti sur du redhat plus que sur du debian. Du coup, pour faire tourner une debian et rendre toutes les commandes actives, il faut qu'une machine virtuelle fasse tourner debian, est-ce le cas ? Car ça doit pas mal réduire les performances des syno.

Oui, j'ai vu passer ce paquet mais ça description n'était pas très explicite... tout comme son nom. Pourrais-tu m'en dire plus ? Par ailleurs, ce paquet est passé en "private beta" désormais, il n'est donc plus accessible.

Non, il n'y a rien à réinstaller, c'est lorsque tu indiques l'url, soit tu commences par https:// (port 443) soit par http:// (port ). Ce qui m'a fait penser à un problème de protocole https contre http, c'est que dans ton erreur il est indiqué qu'il y a un problème de "validation du serveur", j'avais donc plus vite pensé à un problème de validation du certificat d'authentification utilisé lorsque l'on passe par le https. Tout ce que tu as à faire pour tester cela, c'est de modifier l'url du caldav utilisé dans ton apli android. ---- Edit: D'après ce message http://forum.ownclou...ec264d3ff6515d6 Sous iOS, il ne faut pas indiquer le protocole mais commencer directement par l'adresse. Donc à la place de mettre https://domaine.net/owncloud tu mets domaine.net:80/owncloud ou domaine.net:443/owncloud Ça pourrait éventuellement être identique sous Android... xD

Salut, Je rencontre le même problème que toi, as-tu trouvé une solution depuis ? Pour info je tourne sous Fedora.

D'après le forum de la communauté allemande, ce serait possible de mettre le bootstrap du DS209+ sur le DS213+. Du moins c'est ce que j'ai compris, grâce à la traduction de ce post http://www.synology-...-IPKG-für-DS213 ----- Edit: Et ici http://www.synology-wiki.de/index.php/Welchen_Prozessortyp_besitzt_mein_System%3F On peut trouver un lien direct vers le paquet ipkg qui irait bien avec le DS213+. Mais je n'ai pas encore pu le tester.

Bonjour, Je cherche à mettre en place des calendriers et des listes de contacts partagés. Je me suis donc tourné vers owncloud au vu des nombreux retours positifs. Mais j'ai une petite hésitation désormais sur la façon de mettre en place les choses. Voici ce que je cherche à faire : - Avoir plusieurs calendriers. Chaque calendrier peut être modifié par une ou plusieurs personnes et ce de façon simultanée. - De même pour les listes de contacts. Pour les calendriers, je me suis dit que je pourrais créer un compte "Calendriers", y ajouter plusieurs calendriers et y affecter les partages qui vont bien. Par contre pour les listes de contacts... il semblerait que l'on ne puisse avoir qu'une liste de contacts par compte. Vais-je devoir créer une compte pour chaque liste de contacts à partager ? Et dans un cas, comme dans l'autre, les accès simultanés aux calendriers et listes de contacts seront opérationnels ? Merci d'avance pour votre aide.

Pour ma part, je pencherais plus sur un problème lié au certificat ssl. Utilises-tu un certificat auto authentifié ? Si oui, essaye de passer par le port (http://) pour voir ce que ça donne.

Bonjour, J'ai quelques notions de voip car j'utilise actuellement un serveur distant pour la voip mais voyant qu'il était possible de l'installer sur mon syno, j'ai décidé de m'y mettre. Ici j'ai essayé quelque chose de très basique mais je bloque déjà. Le but était d'arriver à connecter un de mes téléphones sip au nas. J'ai pour cela créé un nouveau compte d'utilisateur, j'ai ensuite essayé de m'y connecter en sip mais ça ne fonctionne pas. Pourtant j'ai bien autorisé tous les ports de Asterisk dans le pare-feu. Et un ptit telnet sur le port 5060 du syno ne donne aucune réponse... Et les logs de Asterisk restent muets !