PiwiLAbruti

Rien à voir avec le module donc, ça me rassure. C'est apparemment un souci avec Download Station, est-ce que ça persiste après désinstallation/réinstallation du paquet Download Station ?

Après vérification, il ne s'agissait pas de la dernière version du module. J'avais laissé du code de test actif mais ça ne semblait pas perturber le fonctionnement du paquet. J'ai corrigé tout ça et déposé la nouvelle version du module au même endroit (pensez à supprimer l'ancienne version du module avec d'installer la nouvelle).

Ce module a été testé sous DSM 5.2-5967u2 avec Download Station 3.5-2970. Dans le doute, je viens de tester sous DSM6.0.6-8451u9 avec Download Station 3.8.2-3455 et ça fonctionne parfaitement. Essaye en ne sélectionnant que ce module de recherche dans les paramètres de Download Station, et avec une recherche dont tu es certain qu'elle retourne un résultat.

Donc Torrent9 fonctionne aussi ?

Bon appétit !

C'est bon pour Torrent9 : [Lien supprimé] Pour ceux qui utilisent T411, le module fonctionne toujours ?

Les gammes Avoton et Rangeley sont concernées par ce défaut. À ma connaissance, Synology n'utilise que des Rangeley qu'ils ont nommé Avoton...

Un collègue l'utilise au travail, aucun souci. La liste des tickets apparaît bien. Edit: J'utilise Apache HTTP Server 2.2 et PHP 5.6 comme paramètres par défaut dans Web Station.

Je vais le mettre en ligne ce soir si j'ai le temps, je posterai un lien ici.

Oui, sans modifier pg_hba.conf. La ligne local all all peer permet à tous les utilisateurs déclarés dans /etc/passwd d'accéder à PostgreSQL. Tout ce qui est dans /var/services/web est exécuté avec le compte http par défaut, il faut juste prévoir les autorisations les accès avec les commandes GRANT précédemment décrites.

Ça ne vient pas de Adminer mais de la configuration de PostgreSQL dont j'ai pris le temps de lire la documentation concernant le fichier pg_hba.conf. Par défaut ce fichier contient : # TYPE DATABASE USER ADDRESS METHOD local all postgres peer map=pg_root local all all peer Ça signifie que l'authentification repose sur celle des comptes utilisateur du NAS. Par contre, il faut leur avoir préalablement attribué les droits nécessaires : postgres=# GRANT CONNECT ON DATABASE my_db TO my_user; GRANT postgres=# \connect my_db You are now connected to database "my_db" as user "postgres". postgres=# GRANT SELECT ON TABLE my_table TO my_user; GRANT J'ai donc ajouté certains droits au compte http (compte par défaut de Web Station) et j'ai simplement vérifié le succès de la connexion avec la chiure de PHP suivante (pas encore réussi avec pg_connect()) : try{ $pdo = new PDO('pgsql:dbname=my_db'); }catch (\Exception $e){ var_dump($e); } var_dump($pdo); // Retourne un objet de type PDO Bref, ça fonctionne très bien dans l'absolu même si Synology a voulu rendre PostgreSQL peu accessible à ses utilisateurs. Dernière remarque, un paquet (pour lequel on crée un compte utilisateur dédié sur le NAS) qui aurait besoin de cette base de donnée peut y avoir accès facilement avec les bons droits (bête script à l'installation du paquet).

Avant DSM 6, il suffisait de saisir admin comme login et on accédait directement à la base PgSQL. Depuis DSM 6, impossible de se connecter avec l'utilisateur postgres (admin n'existe plus). Après avoir retiré le host des chaînes de connexion de de la fonction pg_connect() , j'obtiens le message PostgreSQL is not a open service. Je vais simplement ouvrir un ticket sur GitHub.

Oui, l'interface ne le permet pas. Ce n'est même pas la documentation officielle de PHP qui indique ce support, mais un commentaire d'un utilisateur... Je vais implémenter cette solution et la suggérer à Vrana si j'arrive à un résultat satisfaisant.

Du coup il faut saisir quoi dans le champ Serveur ? Car en ne mettant rien et en utilisant le compte postgres, impossible de se connecter.

Comme tout le monde s'en fout, j'ai finalement réussi à parvenir à un résultat presque correct : login as: admin admin@DiskStation’s password: ************ admin@DiskStation:~$ sudo -i Password: ************ root@DiskStation:~# su - postgres postgres@DiskStation:~$ psql psql (9.3.6) Type “help” for help. postgres=# \du List of roles Role name | Attributes | Member of ----------------------------+------------------------------------------------+----------- postgres | Superuser, Create role, Create DB, Replication | {} postgres=# CREATE USER admin PASSWORD '************' SUPERUSER CREATEDB CREATEROLE; CREATE ROLE postgres=# \du List of roles Role name | Attributes | Member of ----------------------------+------------------------------------------------+----------- admin | Superuser, Create role, Create DB | {} postgres | Superuser, Create role, Create DB, Replication | {} postgres=# \q postgres@DS411:~$ exit logout root@DS411:~# vi /etc/postgresql/pg_hba.conf # TYPE DATABASE USER ADDRESS METHOD local all postgres peer map=pg_root local all all peer host all admin 127.0.0.1/32 trust root@DS411:~# synoservicectl -restart pgsql pgsql restarted. root@DS411:~# synoservicectl -status pgsql pgsql start/running root@DS411:~# exit logout admin@DS411:~$ exit L'un des défauts possibles est que la modification de pg_hba.conf ne soit pas permanente. Sinon ça fonctionne très bien

Est-ce que les références des 4 disques sont identiques ? Ça peut poser des problèmes au RAID si elles sont différentes. Pour la deuxième solution, j'opterais pour un DS216+II car l'écart de performance avec le DS716+II n'est pas perceptible (et le RAID avec une extension est une mauvaise idée).

@Einsteinium : Je ne veux pas que le trafic http du LAN passe par le NAS et bloquer que http, donc Proxy Server n'est pas la bonne solution pour moi.

Je pense que tu devrais en parler dès le premier paragraphe de ton tutoriel en expliquant qu'avoir son propre serveur DNS pour les accès locaux et distants est bien plus efficace que QuickConnect : pas de relai avec les serveurs de Synology (confidentialité, fiabilité, latences, ...), utilisation du même nom en local et distant (très pratique pour les applications mobiles, Cloud Station, accès distant via VPN, ...), pas besoin de loopback, gain de rapidité (même si peu perceptible par l'utilisateur), et j'en passe... En gros il faut appâter avec du concret dès les premières lignes. En ce qui me concerne, je pense le mettre en application pour remplacer ma configuration à base de dnsmasq. Je m'en sers pour de la résolution locale et surtout pour l'anti-pub avec des listes assez exhaustives comme http://winhelp2002.mvps.org/hosts.txt. Par contre je crains qu'il soit compliqué de l'appliquer à DNS Server.

Un usage excessif à 50% ? Pour moi un usage excessif ça démarre à 90% (voir plus selon la quantité totale de RAM).

Est-ce que le port tcp/25 de ta box/routeur est bien redirigé vers ton NAS ?

Ça tombe bien, ma voiture est très sale

Le module de téléchargement cpasbien ne sera plus mis à jour car le site (n'étant plus mis à jour) a été migré vers Torrent9. J'ai un module fonctionnel pour Torrent9 qui va bientôt etre mis à disposition.

Tu confonds sauvegarde et synchronisation. Si une sauvegarde se fait en temps réel, comment comptes-tu pouvoir effectuer une restauration ?

Prends le temps de lire la documentation officielle concernant Cloud Station Server, tu y trouveras la raison de ton problème : Source : https://www.synology.com/fr-fr/knowledgebase/DSM/help/CloudStation/cloudstation

L'un des pré-requis pour monter un serveur de messagerie est justement de disposer d'une adresse IP fixe, sinon ton serveur se fera blacklister systématiquement. Essaye de voir si ton opérateur propose cette option, ou trouve un FAI qui propose une adresse IP fixe.