PiwiLAbruti

Bonjour @ymeyer18 Quels paquets sont installés ? (Synology Drive Server ?)

Je n'ai ce souci qu'avec les messages à destination de domaines Microsoft (outlook.com, live.com, hotmail.com, et leurs équivalents nationaux). La solution a été de définir un relai SMTP pour ces adresses uniquement (Remise de messages > Delivery > Liste des hôtes actifs > Règle du destinataire).

Si par "IP extérieure" tu entends adresse IP publique, ces dernières sont attribuées par les FAI. Il n'est pas possible de la définir soi-même. Pour le reste, je n'ai rien compris.

Ce qui m'intéresse est d'avoir le contenu des fichiers de configuration de quelqu'un qui a le problème comme @ibanana ou @Torvic-Gall. S'il faut réinitialiser une configuration erronée, il faut que le fichier firewall_settings.json contienne, { "profile" : "default", "status" : true } que le fichier 1.json contienne, { "adapterPolicyMap" : { "global" : 2 }, "name" : "default", "rules" : null } Et que tout autre fichier {n}.json soit supprimé. À partir de à il ne devrait plus y avoir de souci pour repartir sur une base propre.

Supprimer, non. On peut remettre les fichiers de configuration par défaut. Déjà, il faut voir l'état du parfe-feu en affichant le contenu de /usr/syno/etc/firewall.d/firewall_settings.json. En suite il faut également afficher le contenu des profiles de pare-feu ({n}.json) pour voir les règles. S'il n'y a qu'un profil, seul un fichier 1.json est présent. À parti de là on pourra éventuellement voir ce qui coince et restaurer la configuration par défaut.

Intéressant, il faudrait pouvoir supprimer les profils de pare-feu manuellement directement dans les fichiers de configuration de DSM. J'y jetterai un œil si j'aime temps.

C'est tout ?! C'est là qu'on voit qu'il ne s'agit que d'une contrainte marketing car techniquement tout est prêt pour VMM. Pour la mise à jour automatique, il faudrait modifier l'identifiant du NAS. Mais ça pourrait avoir des impacts négatifs ailleurs (ou pas).

Ce que tu cherches est intéressant, mais ça ne me dit rien du tout. Il existe bien Calibre ou COPS mais ils ne proposent pas d'application mobile. Je ne sais pas s'il y a un équivalent sur Android, mais sur iOS j'utilise DS File pour accéder aux fichiers PDF du NAS et iBooks pour les stocker et les lire sur mobile. C'est simple, il n'y pas d'application tierce à installer (ni sur le NAS, ni sur le mobile). J'ai aussi utilisé l'application iComics (iOS) qui est très bien pour lire tous types d'eBooks. En tout cas, je ne pense pas qu'il faut t'attendre à trouver une solution tout en un (NAS et mobile).

En tout cas, Synology a bien bossé sur les paquets MailPlus : https://www.synology.com/fr-fr/releaseNote/MailPlus-Server#7_x_series https://www.synology.com/fr-fr/releaseNote/MailClient#7_x_series

Ça ressemble à une saturation des serveurs de téléchargement de Synology. Alternative manuelle : https://archive.synology.com/download/Package

Pour ma part, je laisse également la zone publique domain.tld chez OVH. Par contre, j'héberge des zones publique de 3ème niveau sur le NAS du type nas.domain.tld qui sont totalement insensibles aux changements d'adresse IP. Pour cela, il faut créer un enregistrement NS nas.domain.tld chez OVH pointant vers un DynHost dynhost-nas.domain.tld (ou n'importe quel service de DNS dynamique). Le DynHost est configuré sur le NAS pour qu'il soit mis à jour automatiquement avec l'adresse IP publique. Ainsi, s'il y a un changement d'adresse IP publique, la zone publique du NAS nas.domain.tld redevient accessible dès que le DynHost a été mis à jour (1 minute d'indisponibilité maximum). Inconvénients : Ça rallonge un peu les URL (https://dsm7.nas.domain.tld/ pour accéder à DSM par exemple), mais avec un 2ème niveau de 4 caractères (minimum disponible pour le grand public) ce n'est pas une grosse contrainte (abcd.tld). Avantages : On peut gérer une infinité de zones publiques de 3ème niveau tout en conservant le domaine parent chez le registrar. Cette technique rend une zone publique exploitable même avec une connexion ne disposant pas d'une adresse IP fixe. L'accès peut être limité dans le pare-feu, très pratique pour sécuriser le serveur DNS. On peut aussi limiter les IP source directement dans les paramètres de chaque zone, mais le pare-feu à l'avantage de ne même pas exposer le port udp/53.

Je n'utilise que des systèmes sans interface graphique pour des raisons d'efficacité : Debian pour pas mal de services qui me servent pour du développement (MQTT, WebSockets, Redis, ...), Une instance de routeur MikroTik pour du lab réseau, Un DSM virtuel (VDSM) pour DSM 7 et quelques conteneurs Docker.

Y a-t-il des tâches en cours sur le NAS ? (commande top via SSH si le Moniteur de ressources est inexploitable) As-tu vidé le cache de ton navigateur ? (tu peux aussi tester dans un mode navigation privée)

5. Reserve extra time to complete DSM 7.0.1 update. The DSM update takes 10 to 20 minutes, while the package update may take more than an hour. The actual time depends on the computing power of your model, the number of media indexing files, and the number of packages installed.

Les tarifs pratiqués en ce moment sont liés aux difficultés d'approvisionnement (même si certains spéculent). C'est la différence de tarif avec Materiel.net qui est surprenante. Peut-être parce qu'ils ont du stock, mais faisant parti du groupe LDLC, il est encore plus surprenant que les approvisionnements (et donc le stock) n'aient pas été rationalisés.

Ok, donc tu n'as aucune attente particulière venant de DSM 7. Même pas le gain de réactivité apporté ? Je t'invite à lire l'intégralité des changements apportés par DSM 7 avant de faire quoi que ce soit : https://www.synology.com/fr-fr/releaseNote/DSM?model=DS216%2BII#7_0 Sinon, la procédure est la même que pour tout changement majeur de version d'un système : Mettre les sauvegardes à jour, Faire un test de restauration partiel, Mettre à jour du système. À savoir que Synology maintient toujours les mises à jour de sécurité pour DSM 6, ça laisse largement le temps de temporiser la migration vers DSM 7.

Les prix du WD Ultrastar DC HC310 sont assez surprenants, surtout chez les deux premiers qui font parti du même groupe : 260€ chez LDLC 185€ chez Materiel.net 206€ minimum chez les vendeurs tiers Amazon Sinon il n'y a aucune évolution matérielle notable sur ces modèles (le changement de processeur suit la logique de renouvellement en place depuis 1 an).

La question la plus importante : Qu'attends-tu de DSM 7 ? Pour le reste, je n'ai pas connaissance de problèmes bloquants lié à DSM 7 et aux usages que tu as donnés.

Hi @ChristaHegmann, This forum is the French community of Synology. I think you'll find better answers to your questions on the official Forum (international) : https://community.synology.com/

Ça dépend du protocole utilisé pour la copie. HTTP, SMB, FTP, NFS, AFP, ... n'ont pas les mêmes spécifications (longueur des métadonnées, compression, chiffrement, ...).

Bon bah comme prévu, Synology a débloqué le problème. J'ai juste eu à définir le volume de stockage et le réseau virtuel. Les VM ont été importées avec succès et ont bien démarré. J'ai quand même demandé à avoir les détails sur la résolution de ce problème.

Il suffit de diffuser domaine2 dans une vue différente, non ?

J'attends toujours qu'on m'offre une boule de cristal 😄, mais le plus efficace est de faire une demande d'amélioration à Synology pour tenter d'accélérer les choses : https://www.synology.com/fr-fr/form/inquiry/feature Pour ma part, j'attends que FDN mette en ligne ses serveurs DoT pour commencer à me pencher sur le sujet : Le plus efficace pour le moment est d'utiliser un relai DNS supportant DoT (via Docker) comme pihole-dot. DNSCrypt n'a pas fait l'objet d'une standardisation (RFC) contrairement à DoT et DoH, et il est moins fiable que DoT donc on peut l'oublier. Il y a une liste assez exhaustive des services DNS supportant DNSCrypt, Dot, DoH, ... sur le site de AdGuard : https://kb.adguard.com/en/general/dns-providers#adguard-dns Un serveur DNS local est toujours amené à résoudre des enregistrements qu'il ne connaît pas. Il utilise donc ses redirecteurs, donc ces requêtes sont visibles par le FAI.

Le trafic DNS n'est pas chiffré par défaut. Donc, tout ton trafic internet traversant le réseau de ton FAI, ce dernier peut techniquement capturer toutes les requêtes DNS de ses clients (et pas que). Il y a tout un tas de possibilités (mirroring sur les équipements de commutation/routage interne, et/ou proches du peering, ...), mais légalement le FAI n'a le droit d'y procéder que sous requête de la justice, des services de renseignement, ...