PiwiLAbruti

Ç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.

http://download.synology.com/download/Package/spk/GLPI/

Tout le monde sait que le Français est une langue difficile (surtout pour les Français d'aileurs), mais là ça me fait saigner des yeux :

Coche l'extension iconv dans la liste et clique sur [Appliquer].

Regarde dans la liste des processus du Moniteur de ressources (ou via la commande top) ce qui consomme du CPU lors de la copie. S'agissant d'un DS413j, le processeur est un 88f6282 (ARMv5) qui est très peu véloce et sature facilement lors de la copie de fichiers avec certains protocoles. L'écart entre FTP et SMB, par exemple, est très visible. Par contre les valeurs S.M.A.R.T. sont inquiétantes. Les valeurs raw_read_error_rate et seek_error_rate devraient être à 0 (zéro).

Une telle solution n'existe pas chez Synology. Sinon il faut une machine Windows sur le même réseau que le NAS et accéder à cette machine à distance via RDP.

Installée sur un DS411+II de test, un redémarrage a été nécessaire.

C'est d'ailleurs purement stupide commercial de la part de Synology. Le DS216+II est identique au DS716+II, seul le processeur est sensiblement différent (Celeron N3060 (2C/2T) contre N3160 (4C/4T)). Je ne pense pas que le passage du 2 à 4 cœurs soit révélateur dans la gestion d'une extension eSATA.

Il faut d'abord identifier ce qui a besoin d'être sauvegardé. Les films téléchargés peuvent souvent être re-téléchargés, donc inutile de les sauvegarder. Évaluer la volumétrie que ça représente et adapter la solution de sauvegarde en conséquence. Tu n'as pas répondu à ma question :

Qu'est-il affiché dans Groupe de disques ? Ça ne rend pas pour autant les sauvegardes facultatives. Si ton NAS contient des données importantes, il vaut mieux les sauvegarder car le RAID0 (aucune redondance) ne permettra pas de récupérer quoi que ce soit en cas de panne d'un seul des disques.

Le plus important est de respecter la distance à laisser entre les câbles électriques et les câbles de télécommunication. À partir de là, la question du blindage ne se pose parfois même pas. Je n'ai pas retrouvé le document normalisé avec ces spécifications (NF C15-100 ?). De mon point de vue, il vaut mieux choisir au minimum un blindage du câble de type F/* (F/UTP ou supérieur) pour éviter les éventuelles perturbations de certains appareils électriques. Par contre ça demande une installation irréprochable par rapport à du U/UTP (prises murales FTP avec raccord à la terre indispensable). Pour le GbE il faut au minimum du Cat.5e (Cat.6 recommandé). Il faut aussi savoir que les câbles passés dans des murs sont monobrin contrairement aux câbles de brassage qui sont multibrin.