oracle7

@sebdepringy Bonjour, Bienvenue à toi sur ce forum. Cordialement oracle7😉

@sebdepringy Bonjour, Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit, rassures-toi il n'est pas trop tard pour bien faire surtout après 5 posts déjà ... Cela dépend de l'application que tu veux atteindre via le RP. Certaines ont besoin de l'entête websocket d'autres de plus de paramètres et d'autres encore : rien. Pour mémoire : "En-tête personnalisé" sauf erreur de ma part, sert à passer des paramètres particuliers au serveur Web, notamment le Websocket pour certains types de communication utilisés par le serveur Web, afin que le Reverse Proxy puisse prendre en charge la fonction/protocole Websocket. Le protocole WebSocket est un protocole réseau basé sur le protocole TCP. Celui-ci définit la façon dont les données sont échangées entre les réseaux. En raison de sa fiabilité et de son efficacité, il est utilisé par presque tous les clients. TCP établit une connexion entre deux points finaux de communication qu’on appelle des sockets. Ainsi, une communication bidirectionnelle s’établit entre les données. Dans le cas d’une connexion bidirectionnelle comme avec le protocole WebSocket (parfois écrit web socket), les données circulent simultanément dans les deux sens. L’avantage : le chargement des données est beaucoup plus rapide. Dans le cas présent, je crains que tu ne joues à "l'apprenti sorcier" en introduisant ta liste d'entêtes personnalisés semble-t-il de façon systématique. Essaies déjà sans aucun entêtes, puis si tu rencontres des soucis, recherches la configuration du serveur web nginx (ou Apache selon) adaptée à ton application et là tu auras les bons entêtes à saisir. Cordialement oracle7😉

@olivier97430 Bonjour, C'est l'@IP externe de ta box/routeur. Cordialement oracle7😉

@.Shad. Bonjour, Ah que voilà une remarque plus que pertinente ! Dans le feu de l'action, je n'ai pas pensé à cet aspect et du coup cela pourrait effectivement devenir problématique. Cela dit, je me dis que les utilisateurs rsync sur le NAS peuvent aussi être amenés à modifier ces fichiers et eux aussi perdraient indirectement leur configuration de sauvegarde. Aussi, j'espère que Synology a envisagé ce cas et lorsqu'ils fournissent une màj de DSM il n'y a pas d'impact sur ces fichiers. Je croise les doigts... Mais tu as parfaitement raison, je vais surveiller cela de près lors d'une prochaine MàJ de DSM. Cordialement oracle7😉

@MilesTEG1 Bonjour, Finalement j'ai testé une autre méthode d'usage de rsync pour réaliser ma sauvegarde de dossier Linux vers/sur le NAS. J'ai tout simplement utilisé rsync en mode daemon et la BINGO !!! cela marche nickel. Tous les droits, propriétaires et groupes sont conservés. Je peux donc envisager un restore des fichiers de la sauvegarde sans aucuns problèmes. Autre gros avantage de ce mode, c'est qu'il n'y a pas non plus besoin de s'embêter à faire un montage de dossier partagé du NAS (nfs, cifs, sshfs, etc ...) sur la machine Linux (ou inversement) avec tous les problèmes qu'il faut gérer à cause d'UID/GID différents entre NAS et machine Linux pour un même username. Donc je donne ici la solution, i.e. la commande à lancer dans un script shell sur la machine Linux pour le mode rsync daemon (exemple à adapter bien évidemment) : SOURCE_DIR="/opt/docker/homeassistant/config" BACKUP_DIR="oracle7@192.168.2.10::SV_HomeAssistant" BACKUP_PATH="${BACKUP_DIR}/SV_HA_$(date '+%FT%H%M')" sudo rsync -a --rsync-path="sudo rsync" --password-file=/root/.password --delete "${SOURCE_DIR}/" "${BACKUP_PATH}" L'usage de sudo est obligatoire car rsync s'exécute en root bien que le script est lancé par un utilisateur avec droit d'admin (même nom sur le NAS et la machine Linux). Bien évidemment, il faut aussi mettre en place un échange de clés privé/publique SSH pour chaque utilisateur du NAS (root et oracle7 dans mon cas). Le fichier /root/.password (à créer) comporte sur une seule ligne le MdP de root et est protégé (chmod 600 + chown root:root). On remarquera aussi la nuance dans l'appel au serveur NAS --> les " :: " suivant l'@IP du NAS suivi du nom du module qui est défini dans /etc/rsyncd.conf . cela aussi implique d 'ajouter ceci sur le NAS dans le fichier /etc/rsyncd.conf : #------------------------------------------- # Ajout oracle7 20230406 pour Sauvegarde dossier config HomeAssistant (sur la Machine Linux) # Id de l'utilisateur qui execute rsync uid = root # Id du groupe d'utilisateurs qui execute rsync gid = root # Creation du module [SV_HomeAssistant] # Chemin vers le dossier partage du NAS recepteur de la sauvegarde path = /volume1/Sauvegardes/SV_HomeAssistant comment = Module de sauvegarde configuration HomeAssistant # Utilisateurs pouvant se connecter au daemon rsync auth users = root, oracle7 # Masque <username:passwd> utilise pour l'authentification du module secrets file = /etc/rsyncd.secrets # Par defaut : read only = yes : doit etre 'no' pour pouvoir ecrire read only = no # Rendre le module "listable" list = yes # Liste des hotes autorises à se connecter au module (séparateur = " , " ou " ") # @IP machine Linux hosts allow = 192.168.2.60 et dans le fichier /etc/rsyncd.secret les mots de passe des utilisateurs (username:password) : root:MotDePasseTresTresLong_1 oracle7:MotDePasseTresTresLong_2 En espérant que cette solution servira pour d'autres membres qui veulent faire "simple" ! @.Shad. Oui j'avais vu cette possibilité ainsi que celle avec un duplicati en docker, mais dans un premier temps je souhaite faire simple et pas trop me prendre la tête déjà que là, j'y ai passé quelques heures de recherche et lecture en tous genres sur la toile où il faut trier en permanence le bons grains de l'ivraie, tout et son contraire en somme ... Cordialement oracle7😉

@Antom Bonjour, Bienvenue à toi sur ce forum, tu verras c'est une mine d'informations. J'invite à regarder et suivre ces deux TUTOs pour t'assurer que tu avais bien démarré. TUTO : Débuter avec un NAS Synology TUTO : Sécuriser les accès à son NAS Ceci dit, mais je peux me tromper, je crains que ton NAS soit trop ancien et pas assez puissant pour ton objectif de vidéosurvaillance avec SS. Saches aussi dans ton cas qu'une mise à jour vers un système DSM trop récent risque de trop "charger" ton NAS et que ses performances pourraient bien pâtir. Du coup, peut-être qu'envisager d'investir dans un NAS récent serait un bon plan. Maintenant ce que j'en dit, c'est toi qui voit ... Cordialement oracle7😉

@Antom Bonjour, Regardes cet article de la base de connaissances Synology, il devrait pouvoir te donner une piste pour ta mise à jour. Si oui alors télécharges les fichiers indiqués au § "Pour les versions DSM 4.0 ou antérieures". Cordialement oracle7😉

@MilesTEG1 Bonjour, Merci de ta réponse.😀 J'ai donc essayé tout à tour avec les options suivantes : -aX , -aA (-A = --acls) mais sans effet sur les propriétaires et groupes. Je n'ai pas utilisé les options -v et -h car elles n'apportent que le mode verbose lors de l'exécution pour la première et la seconde rend seulement "human readable" les infos de l'option --stats dans le progress. Pour ton information l'option --syno-acl n'existe pas (voir le man rsync) avec rsync sur Linux : rsync: --syno-acl: unknown option rsync error: syntax or usage error (code 1) at main.c(1749) [client=3.2.3] cette option n'existe qu'avec le rsync "propre" à Synology (voir rsync --help) quand on le lance depuis un NAS donc pour une sauvegarde du NAS vers un système externe. Je te l'accorde, je n'avais pas précisé que je lançais le script depuis la machine Linux d'où ta réponse pour cette option. Désolé. J'ai donc édité mon post pour le préciser. Je continue donc à chercher ...😥 Cordialement oracle7😉

Bonjour, Le but : Réaliser la sauvegarde un dossier d'une machine sous Linux dans un dossier partagé du NAS pour si besoin en est, pouvoir restaurer ce dossier tel qu'à l'origine. Le contexte : Pour réaliser la sauvegarde du dossier Linux, dans un shell script, j'utilise la commande "rsync" (depuis la machine Linux) telle que : SOURCE_DIR="/opt/docker/homeassistant/config" BACKUP_DIR="oracle7@192.168.2.10:/volume1/Sauvegardes/SV_HomeAssistant" BACKUP_PATH="${BACKUP_DIR}/SV_HA_$(date '+%FT%H%M')" sshpass -f /home/oracle7/.synology/.password sudo rsync -a --delete "${SOURCE_DIR}/" "${BACKUP_PATH}" Constat : Les fichiers sont bien copiés avec les bons droits mais les propriétaires et groupes restent figés sur mon utilisateur du NAS et son groupe sur le NAS. Par exemple : drwxr-xr-x 1 oracle7 users 960 Apr 5 21:26 ./ drwxr-xr-x 1 oracle7 users 554 Apr 5 21:26 ../ -rw------- 1 oracle7 users 8672 Apr 5 11:51 auth -rw------- 1 oracle7 users 417 Mar 8 16:34 auth_provider.homeassistant -rw-r--r-- 1 oracle7 users 339 Mar 9 12:27 camera -rw-r--r-- 1 oracle7 users 275 Feb 25 19:59 core.analytics -rw-r--r-- 1 oracle7 users 452 Feb 25 18:44 core.area_registry -rw------- 1 oracle7 users 389 Mar 9 12:58 core.config alors que la source est telle que : drwxr-xr-x 2 oracle7 root 4096 5 avril 21:29 ./ drwxr-xr-x 17 oracle7 root 4096 5 avril 21:26 ../ -rw------- 1 root root 8672 5 avril 11:51 auth -rw------- 1 root root 417 8 mars 16:34 auth_provider.homeassistant -rw-r--r-- 1 root root 339 9 mars 12:27 camera -rw-r--r-- 1 root root 275 25 févr. 19:59 core.analytics -rw-r--r-- 1 oracle7 root 452 25 févr. 18:44 core.area_registry -rw------- 1 root root 389 9 mars 12:58 core.config Questions : Qu'est-ce que je rate selon vous ? Pourquoi les propriétaires et groupes ne sont-ils pas conservés lors de ma copie des fichiers sur le NAS ? Ai-je omis une option de paramétrage de rsync ? Donc messieurs les "barbus" si vous avez une ou des idées, je suis vivement preneur. MERCI d'avance de vos réponses. Cordialement oracle7😉

@Dimebag Darrell Bonjour, Pour ton information : "rw- rw- --- " c'est la même chose que 660 en octal. Avec r = 4, w=2, x=1, -=0 du coup ici pour chaque groupe de 3 lettres en faisant la somme des valeurs des lettres, on a rw- = 6 soit au final pour "rw- rw- --- " = 660. C'est pas plus compliqué ! Mais vu ta question, manifestement tu n'as lu n'y essayer de jouer avec le "chmod_calculator" que t'a donné @MilesTEG1 tu l'aurais compris. Pas grave ...🤪 Enfin, il n'y a pas lieu d'avoir à redémarrer le docker.sock, c'est juste un fichier qui doit avoir les droits suscités. Cordialement oracle7😉

@j3r3m51 Bonjour, Tu es sûr de ton coup là ? car dans le TUTO Sécuriser les accès à son NAS ce n'est pas ce que je lis : Dans tous les cas, tant mieux si cela marche pour toi maintenant 😊 Cordialement oracle7😉

@Dimebag Darrell Bonjour, A tout hasard, vérifies les droits sur /var/run/docker.sock, ils devraient être : 660 octal Encore à tout hasard, tu utilises bien une version d'image de influxdb en V1.8 et pas en V2.x ? Cordialement oracle7😉

@firlin Bonjour, Regardes toujours ceci, cela répond en partie à ta demande pour l'utilisation du certificat LE de ton domaine. MAIS je te l'accorde, cela ne répond pas à ton besoin d'utiliser ton domaine en lieu et place de ton @IP. Cordialement oracle7😉

@laurenttaieb Bonjour, Bien sûr que oui tu as un compte root. Le compte root n'est accessible qu'en lignes de commandes sous SSH et pas dans l'UI de DSM. Dans un terminal, tu te connectes en SSH avec PuTTY (ou autre) et ton compte utilisateur "normal" (pas l'utilisateur "admin" car il devrait être désactivé si tu as bien suivi les conseils de ce TUTO : Sécuriser les accès à son NAS). Tu tapes la commande suivante : " sudo su - " et tu saisis comme MdP, le MdP de ton utilisateur "admin" : c'est le même. Et là tu seras sous root, un # en fin de ligne d'invite te l'indique, si c'est un $ alors c'est que tu es connecté sous un utilisateur "normal". Donc sous root, tu peux alors faire toutes les actions dévolues à ce type de compte. Mais attention à ce que tu tapes car la moindre erreur peut avoir des conséquences désastreuses pour le bon fonctionnement ton NAS. Tu es prévenu ! Pas seulement, il faut aussi que les droits sur le dossier .ssh et le fichier authorized_keys soient corrects i.e. respectivement 700 et 600. Cordialement oracle7😉

@mauvaisdawa Bonjour, Content d'avoir pu t'aider.😊 Juste pour ta gouverne, dans tes réponses, il n'est pas nécessaire de re citer le post précédant dans sa totalité, ce serait bien que tu ne cites que la partie à la quelle tu réponds, cela surcharge moins les posts et ils sont plus faciles à lire. Merci. Cordialement oracle7😉

@j3r3m51 Bonjour, Tu sais que cela ralentit les échanges et en plus tu es sur ton réseau local donc quel intérêt à moins que tu n'ais des pirates en herbes sur celui-ci ? Si c'est vraiment le cas (loads infinis), tu serais bien avisé de revoir ta configuration de ton RP et de ton réseau local. Maintenant ce que j'en dit ... Au passage, quand on utilise le RP il ne faut pas activer dans le portail de connexion, la fonction qui redirige automatiquement les flux HTTP vers HTTPS pour le bureau DSM. C'est expliqué dans le tuto RP, cela casse les mécanismes du RP dans certains cas. D'où peut-être ces loads infinis ... Cordialement oracle7😉

@louloudu77 Bonjour, Bienvenue à toi sur ce forum, tu verras c'est une mine d'informations. Je t'invite à parcourir la rubrique [TUTORIELS] où tu trouveras sûrement des réponses. Cordialement oracle7😉

@mauvaisdawa Bonjour, A mon humble avis AVANT de vouloir directement rendre accessible ton PLEX en dehors de ton réseau, il serait plus sage et avisé de sécuriser les accès à ton NAS. Pour cela je t'invite à suivre ce TUTO : Sécuriser les accès à son NAS Ensuite, prends aussi le temps de lire cet autre TUTO : Débuter avec un NAS Synology. C'est toujours bon pour la connaissance générale de ton NAS. EDIT : Oui puisqu'en IPv6 chaque appareil a une adresse IPv6 différente, donc le problème du NAT ne se pose pas. Par contre la redirection de port ça n'a de sens qu'en IPv4 et comme tu dit être chez SFR il y a de fortes chances que tu sois en CGNAT et là tu n'as PLUS de redirections de ports paramétrables en IPv4 et en plus tu n'as pas la totalité des ports de disponibles. Pour vérifier, tu te connectes à la box SFR avec http://192.168.1.1 et regardes en haut à droite si tu vois :IPv6 / IPv4 CGNAT alors ton @IP est partagée et le NAT est désactivé (seulement ¼ des ports sont accessibles et pas forcément ceux qui t'intéressent : 80, 443, etc …). Dans ce cas, je t'invite à appeler SFR pour demander à obtenir une IPv4 Full Stack et pour ainsi pouvoir revenir en arrière. Ils le font normalement sans problèmes, dire simplement que tu as un NAS et des services Web et que tu as besoin de faire du NAT, ce qui n'est plus possible depuis le passage en IPv6 / IPv4 CGNAT. Cordialement oracle7😉

@MilesTEG1 Bonjour, Juste pour mon info, au final qu'elle méthode as-tu suivie ? Cordialement oracle7😉

@mauvaisdawa Bonjour, Bienvenue à toi sur ce forum, Je t'invite à parcourir la rubrique [TUTORIELS] où tu trouveras sûrement des réponses. Cordialement oracle7😉

image inaccessible 🥴

Bonjour, Comme l'a justement dit @bliz quand on loue les services d'un VPN tiers c'est que l'on fait confiance au fournisseur du dit VPN. Donc, il ne faut se plaindre après coup d'éventuelles fuites ... Il y a assez d'offres sur le marché pour "bien choisir" son VPN. Mais ce n'est que mon avis ... Cela dit, l'article reste tout de même assez (voire même plutôt) tendancieux dans le sens ou il met en exergue pour ne pas le citer NordVPN alors que ce dernier n'est même pas dans la ligne de mire des VPN concernés. Les commentaires en réaction le prouvent ! Si c'est fait pour faire peur à Monsieur tout le monde, alors l'article est pas loin de gagner. Cordialement oracle7😉

@.Shad. Bonjour, Oui évidemment 😜 En aparté, juste une question au passage : Je n'arrive pas à créer un lien symbolique sur un dossier partagé de mon NAS monté par cifs sur mon NUC linux : mount -t cifs -o credentials=/home/oracle7/.synology/secret,user=oracle7,uid=1000,gid=100,_netdev,vers=2.0 //@IPlocaleNAS/dossierPartageSurNAS /mnt/dossierPartageSurNAS ln -s /mnt/dossierPartageSurNAS /home/oracle7/fichierLien Je récupère une erreur du type : " ln: impossible de créer le lien symbolique '/home/oracle7/fichierLien': Opération non supportée " Une idée peut-être ? Je ne vois pas ce qui bloque la création du lien symbolique, parce que ce serait sur un dossier monté ? Edit : Finalement j'ai trouvé, il suffisait d'ajouter l'option " mfsymlinks " à la commande de montage. Cordialement oracle7 😉

@.Shad. Bonjour, Je ne te suis pas bien, changer quoi dans le fichier sshd_config ? Je ne sais pas comment vérifier si le service SFTP est actif ou non. Je ne vois pas de processus (ps aux | grep sftp) ... Au niveau de SFTP dans ce fichier il n'y a que cela : # override default of no subsystems #Subsystem sftp /usr/libexec/sftp-server Subsystem sftp internal-sftp -f DAEMON -u 000 et c'est par défaut. A tout hasard, mon fichier ssh-conf : Ciphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 MACs hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes AllowTcpForwarding no #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # override default of no subsystems #Subsystem sftp /usr/libexec/sftp-server Subsystem sftp internal-sftp -f DAEMON -u 000 # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server Match User root AllowTcpForwarding yes Match User admin AllowTcpForwarding yes Match User anonymous AllowTcpForwarding no GatewayPorts no Une idée pour éventuellement relancer le serveur SFTP ? " synosystemctl start sftp.service " ne donne rien à part un " Fail to start [sftp] " Cordialement oracle7😉

@PiwiLAbruti Bonjour, Oui pour la clé publique et cela marchait très bien jusqu'à mon problème. Désolé mais aucun effet, après suppression des entrées relatives au NAS dans "C:\Users\oracle7\.ssh\known_hosts". Sinon je viens de remplacer mon fichier sshd_config dans /etc/ssh par celui qui était présent dans /etc.defaults/ssh. J'ai ensuite reload puis restart le sshd.service. Du coup BINGO !!! J'ai pu réactiver le service SSH dans l'UI de DSM et j'ai pu de nouveau établir une connexion SSH au NAS avec mon user droit d'admin. Par contre, sous WinSCP lorsque je lance une nouvelle session sous root je récolte ce message : alors que la connexion sous root se fait sans problèmes depuis WinSCP sur mon second NAS. Une idée, peut-être ? Cordialement oracle7😉