PiwiLAbruti

Il n'y a aucun renvoi. Le port tcp/443 est le port par défaut en HTTPS donc il peut être omis dans l'URL. Les deux écritures ci-dessus ne sont que des synonymes. Si tu utilises un autre port, ça ne fonctionnera pas.

Essaye avec la commande top via SSH en sélectionnant la colonne RES (ou %MEM) avec les touches [<] et [>] pour naviguer entre les colonnes. Tu peux aussi essayer de stopper tous les paquets, conteneurs, et machines virtuelles pour voir si la consommation de RAM augmente toujours.

C'est normal, cette mise à jour n'est pas encore déployée automatiquement. Il est seulement possible de l'installer manuellement. Après chacun y voit l'urgence qu'il veut 😇

2) Oui, c'est le principe des hôtes dynamiques. L'adresse IP d'un nom d'hôte est mise à jour via une requête HTTP. Le loopback c'est le fait qu'une machine reçoive du trafic qui lui est destiné mais pas sur la bonne interface (dans le cas présent à destination de l'adresse IP publique mais sur l'interface privée). Du coup le trafic est renvoyé sur la bonne interface (l'interface publique) afin d'atteindre la destination indiquée dans les règles NAT/PAT. D'où la boucle interne à la machine concernée. 3) En HTTP, chaque application n'a pas besoin d'un port défini. Tous les d'hôtes, ports, ou chemins ne sont que des alias pointant vers un dossier contenant l'application (qui, dans le cas de File Station, Synology Photo, ..., ne sont en réalité que de simples sites web). 4) Comme déjà dit ci-dessus, le port n'est pas nécessairement déterminant.

1) Oui, le protocole de résolution de ces noms s'appelle NetBIOS. 2) En externe, le nom est résolu par DNS qui retourne l'adresse IP publique. C'est exactement la même chose en interne, sauf que l'adresse IP publique étant celle de la box, cette dernière renvoie le trafic vers la bonne destination interne en utilisant les règles de translation de ports définies. On appelle ça le loopback. 3) En HTTP, les applications peuvent être distinguées selon le chemin utilisée (peu importe le domaine et le port utilisés) : <scheme>://<host>:<port>/<path>?<query>. Par exemple pour Synology Photo : https://diskstation:5001/?launchApp=SYNO.Foto.AppInstance&SynoToken=******** 4) Je suppose que tu fais référence au Portail de connexion ? Si c'est le cas, il est possible d'y configurer presque n'importe quel type d'accès par application (par hôte, port, chemin, ...). À toi de savoir quel fonctionnement tu souhaites avant d'y configurer quoi que ce soit. 5) Une adresse IP fullstack est obligatoire pour faire de l'auto-hébergement. En IP partagée, un autre abonné ne peut pas utiliser le même port que toi puisqu'ils te sont réservés. En fullstack, l'adresse IP t'es entièrement dédiée (et n'est donc plus partagée), donc tu bénéficies de tous les ports disponibles (0-65535).

C'est systématique maintenant chez Synology 😆 Tant que ceux qui l'ont déjà installée n'ont pas de problème, c'est le principal.

Les notes de mise à jour officielles : https://www.synology.com/fr-fr/releaseNote/SRM?model=RT1900ac#ver_8227-3 Je trouve dommage que Synology ait abandonné le RT1900ac, surtout que ce modèle aurait pu bénéficier des améliorations de performances de SRM 2 (comme DSM 7 face à DSM 6).

L'utilisation des étiquettes n'est malheureusement pas standard. Gmail propose dans la liste des étiquettes de les publier en IMAP, mais elles deviennent alors des dossiers (ce qui me semble pire que de ne pas utiliser les étiquettes). MailPlus Client n'a aucune option équivalente.

Pour sécuriser MailPlus Server, il faut en premier lieu valider tous les mécanismes de sécurité SPF, DKIM, et DMARC. Ensuite, l'ouverture du port 25 au monde entier n'est pas un souci (je vérifierai si je n'ai pas configuré d'autres subtilités). On peut voir énormément de tentatives échouées de relaying sur le port tcp/25 dans les logs de sécurité de MailPlus Server. Ensuite, il faut identifier les adresses ou réseaux depuis lesquels les clients se connectent aux protocoles SMTP (tcp/465 ou 587), IMAP (tcp/993), et POP (tcp/995), et restreindre les accès depuis ces seuls réseaux. Dans mon cas, ne consultant mes messages que depuis mon opérateur mobile (Freemobile), seul le réseau 37.160/12 a accès à ces ports (le reste des consultations se faisant en local). Pour identifier les réseaux du RIPE-NCC (incluant l'Europe), il suffit d'utiliser le fichier de registre mis à jour quotidiennement : https://ftp.ripe.net/ripe/stats/membership/alloclist.txt Si certains utilisent des méthodes de sécurisation IP plus efficaces, je suis preneur 🤓

Je m'en doute bien, mais quand tu dis : Tu parles bien de MalPlus Server ?

En fait il en restait deux, maintenant il n'en reste plus qu'un 😅 Ceci dit j'ai déjà éprouvé DSM 7 sur un DS213j, et torturé sur VDSM. Mon DS718+ va bientôt y passer, par contre il va falloir que je sauvegarde le contenu de mes utilisateurs locaux pour les restaurer en utilisateurs LDAP avant la migration.

Quand tu parles de MailPlus, il s'agit du paquet client ou serveur ?

C'est-à-dire que les ports 465 et 587 ne peuvent être ouverts qu'à ton pays de résidence. Seul le port 25 a besoin d'une exposition plus large sur internet pour recevoir les messages.

Seuls les ports tcp/465 et tcp/587 doivent être limités aux clients SMTP qui les utilisent. Le port tcp/25 est utilisé entre les MTAs et n'a pas besoin d'être limité si ton serveur est correctement configuré.

Un simple whois donne beaucoup d'information sur une adresse IP ou un domaine : https://whois.domaintools.com/37.1.255.126 Quels sont les ports que tu bloques à certains pays sur MailPlus ?

Quelle est l'adresse IP et le masque de ton PC sous Windows XP ? Y a-t-il un serveur DHCP dans le réseau du PC ? Le NAS doit avoir une adresse IP dans le même réseau que ce PC. Ça devrait suffire à le rendre accessible sur le réseau. Le choix de continuer d'utiliser Windows XP (sorti en 2001) impacte tout l'environnement récent avec lequel tu pourrais travailler (dont le NAS).

Pourquoi utiliser Windows XP et Internet Explorer ? Ce système d'exploitation et ce navigateur internet sont incompatibles avec les technologies web récentes utilisées par DSM. À moins de trouver un navigateur supportant les technologies web récentes et compatible avec Windows XP, je ne vois pas d'autres alternatives que d'abandonner Windows XP au profit d'un système d'exploitation plus récent.

l'URL http://x.x.x.x:8080/var/packages/domoticz/backupdatabase.php ne risque pas de renvoyer quoi que ce soit à part une erreur (probablement une HTTP 404). Je ne connais pas Domoticz, mais le fichier backupdatabase.php devrait être dans un dossier web pour être accessible depuis une URL. Mais vu la sensibilité de ce script, il est probablement plus judicieux de l'exécuter depuis une ligne de commande : user@DiskStation:~$ php -f /var/packages/domoticz/backupdatabase.php > /var/services/homes/...

Merci pour ces précisions @.Shad.. En tout cas, il est impossible de lancer un container Portainer depuis l'interface de DSM car on ne peut pas ajouter /var/run/docker.sock dans les volumes (restriction d'interface Synology). Alors que dans Portainer c'est possible. De toute façon j'utilise maintenant directement les commandes Docker qui sont plutôt bien hiérarchisées et donc presque intuitives au bout de quelques minutes de manipulations.

Quel est le masque complet de 192.168.0.1/255.255.25... ? Ça ne devrait pas plutôt être 192.168.1.0/255.255.255.0 ? (d'où la notification de blocage)

Ok, merci pour les précisions. Le problème des versions taguées [:latest] est qu'on ne connaît pas la version utilisée. Donc le [:latest] d'il y a quelques mois est souvent obsolète, et quand ça touche à la sécurité... 🤕 C'est le plus gros reproche fait à Docker dans la gestion des images, il faudrait des branches dédiées afin d'éviter les ruptures liées aux versions majeures et assurer la continuité des mises à jour automatiques d'une branche (surtout pour la sécurité). Il y a des choses qui ont été faites de ce côté ? (j'utilise peu Docker)

---- Je m'auto-réponds : N'ayant pas pu définir ce chemin dans l'interface de DSM, j'ai utilisé la commande docker. sudo docker run -d -p 8000:8000 -p 9000:9000 -p9443:9443 --name=portainer-ce -v /var/run/docker.sock:/var/run/docker.sock -v /volume1/docker/portainer:/data portainer/portainer-ce:2.11.0 @Lelolo : Le lien vers /var/run/docker.sock est automatiquement créé à la création du container ?

Je déterre ce sujet. L'interface de Portainer 2.11.0 a changé et ne détecte pas l'hôte local car je ne parviens pas à créer le lien vers /var/run/docker.sock (pas de souci pour /data). J'utilise l'image portainer/portariner-ce:2.11.0. Une idée ?

Je pensais que ça permettait de mettre en place une réplication entre deux instances de MailPlus Server sans SHA. Si ce n'est pas le cas, ça n'a effectivement aucun intérêt.

Si vous disposez déjà de deux NAS supportant MailPlus Server, il vous suffit de suivre le tutoriel de Synology : https://kb.synology.com/en-br/DSM/tutorial/How_to_create_a_high_availability_cluster_for_MailPlus_Server Un des préalables est d'utiliser LDAP Server pour distribuer la base des utilisateurs. Hors du contexte ci-dessus, c'est mission impossible. @Amsonia, il est peu probable que la tâche de migration (exécution unique) soit capable de faire de la synchronisation. Donc ça ne me semble pas être une solution viable. Concernant LDAP, j'ai mis en place la réplication avec plusieurs nœuds LDAP, ça fonctionne très bien. Chaque nœud est indépendant dans la gestion des authentifications.