MilesTEG1

lundi à 16:16

il y a 14 minutes, CyberFr a dit :

Je ne sais pas si, concernant le fichier de config, on parle de la même chose. C'est pourquoi j'ai complété le tutoriel en y ajoutant un exemple de fichier de config avec plusieurs entrées.

Je parlais bien de ce fichier que tu as rajouté dans la configuration 😊

Il faudra ensuite que tu parles du fichier côté serveur , le sshd_conf ou /etc/ssh/sshd_config.d/ssh_keys.conf qui permet de faire que le serveur n’accepte plus que la clé ssh et plus le mot de passe.

À la limite, je me dis qu’avoir un compte secours avec un mot de passe le plus long possible (64 caractères pour dsm) et n’autoriser que celui-ci en accès mot de passe serait une bonne idée 😊 enfin pour un nas 😊

lundi à 13:55

il y a 24 minutes, CyberFr a dit :

Je le ferai en temps voulu. J'ai souhaité parler de l'essentiel car le tuto est déjà assez dense. En ce qui concerne le fichier de config, j'ai bien conscience que je ne t'apprendrai rien alors à quoi bon l'ajouter pour l'instant ?

Détrompe toi ! Je n’y connais pas grand-chose. Juste ce que j’ai pu lire et comprendre.

il y a par exemple ces paramètres que je ne comprends pas malgré les exemples vus :

CanonicalizeHostname

ou lui :

CanonicalDomains

Et donc plein d’autres 😊

lundi à 13:16

il y a 20 minutes, CyberFr a dit :

Mais quel est l'intérêt de SSH dans ce cas ? Le seul intérêt de ce choix serait de se prémunir d'un vol où la personne malveillante aurait physiquement accès à ton Mac. Si c'est le cas cette personne aura de toute façon accès à toutes les clés qu’héberge ton Mac. Cela ne présente donc aucun intérêt a priori.

C'est pas faux. Pour mon usage, je pense que je vais revenir sur ce point, et n'utiliser qu'une seule paire de clé ^^ Celle que j'ai déjà générée 🙂

il y a 21 minutes, CyberFr a dit :

Je n'y avais pas pensé. Tu mérites bien ta réputation de barbu 😀 Je commence déjà à écrire le script parce qu'il faut que je m'y prenne un peu à l'avance quand même !

🧔🏻

il y a 21 minutes, CyberFr a dit :

Je l'ai lu mais la commande « cat » fait le même boulot.

Oui et non.
Toi tu dois d'abord copier la clé publique sur le NAS, en passant par la copie dans le home du mac d'utilisateur de ce mac.
Ça fait quatres actions, sans compter les suppressions des fichiers.

La commande que j'ai donné ici fait tout ça en une seule action. Tu la lances depuis le mac. Essaye, tu verras 😉

il y a 23 minutes, CyberFr a dit :

On est pas sur la même longueur d'ondes, je m'explique.
J'ai écrit ce tuto à destination d'un public disposant d'un Mac et d'un NAS et qui souhaitait pouvoir établir une connexion SSH avec une paire de clés. Étant entendu que le NAS était de marque Synology.
Toi, tu gères plusieurs serveurs de marques différentes dont l'un, si j'ai bien compris, tourne sur une machine virtuelle. De plus tu utilises une clé privée par serveur ce qui n'est pas habituel, y compris chez des utilisateurs avancés.
Tu comprendras facilement que le contexte qui est le tien est sans rapport avec l'objet de ce tuto.
Je te propose de commencer avec un Mac et un NAS et de suivre le tuto pas à pas en respectant sa chronologie, ses étapes et sa logique sinon celui-ci ne te servira à rien.

Oui et non.
En effet, j'essayais de faire fonctionne une méthode qui n'est pas la tienne, avec diverses solutions, mais ton tuto m'a aidé, et je ne faisais que relater en quoi, et comment je n'en était sorti.

La connexion SSH par clé sur le Syno va venir, après mes essais, c'est mon objectif ^^
Comme je l'ai dit précédemment, je vais revenir sur l'idée d'avoir une clé par serveur, pour n'en avoir qu'une seule. Ce sera plus pratique à gérer comme tu dis.
Et juste pour clarifier, mon proxmox est une entité physique, pas une machine virtuelle ^^ (mais je vais aussi mettre en place la connexion par clé SSH avec quelques machines virtuelles linux).

Bref, tu as raison sur le fait que je devrais suivre ton tuto à la lettre pour poster ici, donc je vais m'abstenir pour la suite.
En tout cas, merci quand même car il m'a aidé.

PS : Et n'efface pas ton tuto un nouvelle fois 🙂 Il sert et servira à d'autres.

PPS : Agrémente ce dernier d'explications sur les fichiers de configuration une fois que la connexion est établie avec la clé, car selon moi c'est un gros manque de ton tuto.

👋🏻

lundi à 11:26

il y a 15 minutes, CyberFr a dit :

Sans doute et je compte sur toi pour le confirmer 😀

Lol
UN jour peut-être quand j'aurais validé tout le tralala pour faire en sorte que la connexion par clé fonctionne nickel.

il y a 17 minutes, CyberFr a dit :

il y a une heure, MilesTEG1 a dit :

Et préconises-tu d'avoir une clé par serveur ?

Pas vraiment, ça compliquerait les choses au niveau de la gestion des clés.

Ok, mais pour corser le tout, je reste sur une clé par serveur ^^
Je trouve ça un chouilla plus sécurisé d'avoir une seule clé pour un seul serveur.
À voir si à l'avenir ça ne va pas être plus chiant qu'autre chose, mais tu verras plus bas, j'ai fini par y arriver 😄

il y a 16 minutes, CyberFr a dit :

Je n'ai rien fait du tout.

Ok, moi non plus, même juste après l'installation de proxmox.

Mais chez moi (enfin sur les proxmox/debian), le port de mon SSH et du SFTP sont identiques.

il y a 16 minutes, CyberFr a dit :

Je décline toute responsabilité dans ce cas ! Mais je connais ta témérité 😀

🤣

En fait j'aime bien apprendre par l'exemple, et quoi de mieux que de tester dans un environement "inconnu" ^^

Non la vraie raison pour laquelle je teste sur le NUC avant de tester sur le Syno, c'est justement pour ne pas me retrouver bloquer et ne plus pouvoir accéder à la ligne de commande SSH. (voir la suite de ce § plus bas, avec la dernière citation).

... à. suivre ...

il y a 17 minutes, CyberFr a dit :

Il faut vraiment mieux repartir de zéro mais c'est toi qui voit. Je ne comprends pas le rapport avec le SFTP. De plus c'est quoi le proxmox dont tu parles ?

Chez moi SSL et SFTP sont deux services distincts qui utilisent des ports différents. De mémoire je n'ai activé aucun service sur le NAS pour le SSL, par contre j'ai activé le serveur SFTP.

Repartir de 0 complètement ne me ferait que refaire les couples clés privées / clés publiques que j'ai déjà créés avec les passphrases qui vont avec.
Ce ne sont pas ces clés qui posaient problèmes, mais les paramètres dans les fichiers de configuration.

il y a 17 minutes, CyberFr a dit :

Tu n'en a pas besoin pour l'instant, comme je te l'ai indiqué il faut le créer à la fin lorsque le SSL avec clés fonctionne. Il simplifie la vie, pas plus et l'on peut s'en passer dans un premier temps.

Avec mes clés dédiées à chaque machine, il me fallait passer par le fichier de configuration config sur mon mac, sinon la connexion demandait toujours un mot de passe....

il y a 17 minutes, CyberFr a dit :

On sort un peu du champ du tuto là. J'ai modifié le fichier sshd_config sur mon NAS mais une fois de plus je l'ai fait en dernier. Parce que si tu le modifies avant d'avoir testé que tout se passe bien, tu prends de gros risques. En effet tu modifies le fichier sshd_config et tu interdis donc la connexion SSH par mot de passe. Et si tu constates par la suite que la connexion par clés ne fonctionne pas, tu seras forcé de constater par la même occasion que tu es définitivement banni de SSH ! Il ne te restera plus qu'à réinstaller DSM.

Et même en dehors de ce cas extrême il vaut mieux anticiper tout renouvellement de clés @Fenrir recommande de le faire au moins une fois par an. J'ai un fichier sshd_config_backup que je devrai réinstaller avant tout changement de clés. Si je n'oublies pas bêtement de le faire 😀

Comme je disais un peu plus haut, me retrouver KO à la connexion SSH du Syno, ce n'est pas tolérable d'où mon essai sur le proxmox.
Pour info, Proxmox est basé sur Debian, et c'est un hyperviseur qui fait tourner des machines virtuelles, des conteneurs LXC.
Pourquoi essayé sur le NUC Proxmox, et bien parce que si je me retrouve banni du SSH, je peux toujours corriger le tir en me connectant physiquement au NUC avec clavier, souris, et écran et j'aurais accès à l'invite terminal du NUC directement. Je peux aussi le faire via la WebUI de Proxmox.
Donc c'est mon failsafe ^^
Une fois validée ma technique dessus, (enfin la fusion de plusieurs méthodes, donc la tienne), je pourrais transposer pour le Syno ^^ et potentiellement pour l'Asustor et mon RT.

Sinon pour le Syno, il y a un failsafe aussi, mais faut le savoir 😁 Tu peux toujours lancer des commandes CLI via le planificateur de tâche, en mode root, ce qui te permettrait de restaurer ton fichier de configuration sshd_config à son état d'origine, que tu auras bien entendu sauvegardé avant ^^
Tu te fais alors un script qui : copie la sauvegarde à son emplacement d'origine, puis relance le service SSH.

Et voilà ^^ C'est contraignant mais fonctionnel ^^

Sinon, j'ai donc réussi à faire en sorte de me connecter via la clé 😄 à la fois dans iTerm2, mais aussi dans Forklift 4 😄
Précision, j'ai fait en sorte de réussir la connexion avec l'adresse IP ou aussi via le ndd de type nuc1.miles.lan, dont l'adresse est résolue par mon serveur DNS AdGuardHome.

Pour cela j'ai donc une clé privée qui porte le nom : nuc1.miles.lan
Et la publique le même avec .pub à la fin.

Mon fichier config sur le client contient :

# Bloc pour l'accès via IP, car profil créé depuis longtemps dans iTerm2 avec IP
Host 192.168.2.194
    HostName 192.168.2.194
    User root
    IdentityFile /Users/miles/.ssh/nuc1.miles.lan
    IdentitiesOnly yes
    StrictHostKeyChecking yes

# Bloc pour l'accès via alias court, transformé en ndd uniquement dispo sur le LAN
Host nuc1
    HostName nuc1.miles.lan
    User root
    IdentityFile /Users/miles/.ssh/nuc1.miles.lan
    IdentitiesOnly yes
    StrictHostKeyChecking yes

# Bloc commun à tout, pour éviter les répétitions
# Viendra dedans la partie avev IdentitiesOnly et StrictHostKeyChecking quand tout sera au point
Host *
    Port 1234

Et sur le serveur, j'ai ceci :

# Fichier /etc/ssh/sshd_config.d/ssh_keys.conf
# pour ProxmoxVE/Debian

Port 1234
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 2m
PermitRootLogin yes
AllowGroups ssh root
AllowUsers root@192.168.2.28 root@192.168.2.30 root@192.168.2.80 root@192.168.2.142 root@192.168.2.0/24 root@192.168.10.0/24 root@192.168.12.0/24
PermitEmptyPasswords no
StrictModes yes
MaxAuthTries 6
MaxSessions 10

Match user root
    PubkeyAuthentication yes
    PasswordAuthentication no
    ChallengeResponseAuthentication no
Match all

X11Forwarding no

Et bien sûr, la clé publique placée dans le fichier known_hosts sur le serveur.
D'ailleurs à ce propos, sais-tu que tu peux utiliser la commande suivante pour faire cette manipulation, qui enlève plein d'étapes ?

ssh-copy-id -p 1234 -i ~/.ssh/nuc1.miles.lan.pub root@nuc1.miles.lan

Voilà, je reviendrais vers toi quand j'aurais finalisé mon chmilblik 🙂

BOnne journée , et merci pour toutes ces infos qui me permettent de finaliser mes connexions.

lundi à 09:54

Il y a 2 heures, CyberFr a dit :

J'ai testé le tuto sur la version de macOS qui précède Sonoma, à savoir Ventura.

Salut 🙂

Tu penses que ça sera pareil avec Sonoma ?

Il y a 2 heures, CyberFr a dit :

Comme indiqué dans le tuto dans la rubrique "GÉNÉRATION DES CLÉS". Tu peux ne pas choisir l'emplacement qui est proposé par défaut mais pourquoi se compliquer la vie puisque la clé est cryptée ? La clé privée reste sur ton ordinateur quoiqu'il arrive et n'est jamais communiquée au serveur. Lors du lancement de la session SSH c'est le NAS qui envoie une requête à l'ordinateur local et c'est ce dernier qui, en confrontant la clé publique et la clé privée, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non.

Il y a 12 heures, MilesTEG1 a dit :

Ok, je laisserais donc la clé privée sur le mac.
Et préconises-tu d'avoir une clé par serveur ?

Il y a 2 heures, CyberFr a dit :

Comment veux-tu que je te réponde puisque je n'en suis pas l'auteur ? Le plus simple sans doute est de tout reprendre à zéro avec le tuto que j'ai écrit. Un utilisateur lambda devrait faire ça en 20 minutes mais un as de la CLI comme toi devrait expédier cela en 10 minutes 😀

Je me doute bien, et la question ne portait pas sur le tuto dont je parlais, mais plutôt sur ce que j'ai évoqué ensuite 🙂

Il y a 2 heures, CyberFr a dit :

Moi j'ai conservé les deux, le SSH avec la paire de clés ,et le SFTP. Ils cohabitent à merveille.

Ok. Et tu n'as rien fait de spécial pour conserver le SFTP sur le serveur ?

PS : mes essais sont fait sur une instance proxmox, base Debian 😉 Il va peut-être y avoir des subtilités 🤣

Il y a 2 heures, CyberFr a dit :

À mon humble avis c'est une raison de plus pour repartir de zéro. Mais attention ,ne crée pas de fichier de config avant d'avoir terminé le tuto où tu risques de tout casser. J'ai créé un tel fichier de config sur mon Mac après m'être assuré que tout fonctionnait. Et donc au moindre problème il me suffisait de supprimer le fichier de config pour repartir du bon pied.

Ok, j'ai déjà tout viré, sauf les clés privées/publiques que j'avais généré pour chaque serveur.
Car j'avais besoin d'accéder en SFTP au proxmox.

Tu as quoi comme fichier de configuration ? Je ne vois pas où est décrit dans ton tuto comment on le paramètre...

En relisant ton tutoriel, je me rends compte que tu conserves l'accès par mot de passe puisque tu ne vas pas toucher au fichier /etc/ssh/sshd_config

C'est voulu ?

dimanche à 20:46

@CyberFr
J'ai suivi un autre tuto avant d'avoir le tiens, et dans celui que j'ai utilisé, il y a la création d'un fichier config sur le client et l'ajout de la clé sur le serveur avec aussi la création/modification du fichier de configuration sur le serveur.
Mais en faisant cela, je perds l'accès en SFTP au serveur, or moi je veux le conserver.
Est-ce que ta méthode le permet ?

dimanche à 18:54

Le 13/04/2024 à 5:50 PM, CyberFr a dit :

l est possible de stocker la passphrase dans le Trousseau d'accès du Mac en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins :

La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement tronquée à 10 caractères dans le Trousseau...

Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté.

Bonsoir @CyberFr,

Merci pour ce repartage de tuto.

Pour ce que j'ai cité, as-tu testé sur une version récente de macOS comme Sonoma ?

Et comment stockes-tu la clé privée ?

vendredi à 16:26

Je confirme tout ce qui est dit 😉

je suis moi même rédacteur de quelques tutos , ils n’ont pas très souvent de réponses mais sont visités régulièrement donc ça me suffit 😝 mais du coup je ne les mets pas tellement à jour 😅

vendredi à 11:14

Le 21/08/2017 à 2:21 AM, unPixel a dit :
- Autoriser l'accès SSH uniquement avec un clé :

Pour renforcer un peu plus la sécurité, nous pouvons désactiver l'authentification par mot de passe comme on s'est connecté au début du tutoriel. Ceci va avoir pour conséquence d'autoriser uniquement les connexions SSH avec une clé et la passphrase associée.

On édite le fichier "sshd_config" pour lui indiquer que l'on n'accepte pas l'authentification par mot de passe.
vi /etc/ssh/sshd_config

Bonjour,

Je me met enfin à la gestion des connexions SSH par clés.
Je suis en train de peaufiner ma méthode depuis macOS, afin de gérer plusieurs serveurs, avec chacun un clé privée/publique différente sur mon mac.

Est-ce que la modification du fichier sshd_config est pérenne dans le temps ?
Ne saute-t-elle pas après une MAJ de DSM ?

De même, ne serait-il pas préférable de placer un fichier de configuration ici : /etc/ssh/sshd_config.d/ssh_keys.conf

le 27 mars

Il y a 16 heures, .Shad. a dit :

Et j'ai profité de la réinitilisation pour chiffrer mon volume

Ha ! C’est une bonne idée mais comment est stocké la clé de déverrouillage ?

c’est ce qui me freine au chiffrement des volumes.

Il y a 16 heures, .Shad. a dit :

Ah, mes tâches récurrentes de tests SMART avaient disparu, alors que j'avais coché la restauration de la configuration du planificateur de tâches, étrange.

Même chose aussi chez moi .

jai du recréer ces tâches moi même.

Mais j’ai bien récupérée toutes mes tâches Hyperbackup.

il a cependant fallu tout reconnecter et ça prend du temps.

surtout qu’on ne peut pas tout reconnecter en un seul clic.

meme chose pour lancer un backup.

le 25 mars

Bonsoir,

Ayant formaté les disques de mon Syno pour gagner une partition root de 8Go au lieu des 2 pauvres giga, j'ai du refaire mes conteneurs, dont ACME.
Et à l'étape 3B, j'ai une erreur :

20:08:56 - Script pour paramétrer le déploiement automatique des certificats sur le Syno.
20:08:56 - Exécution de la commande...
[Mon Mar 25 19:08:56 UTC 2024] Logging into 172.20.0.1:19810
[Mon Mar 25 19:08:57 UTC 2024] Getting certificates in Synology DSM
[Mon Mar 25 19:08:57 UTC 2024] Unable to find certificate: mon-ndd.ovh - Certificat Wildcard Lets Encrypt & $SYNO_Create is not set
[Mon Mar 25 19:08:57 UTC 2024] Error deploy for domain:mon-ndd.ovh
[Mon Mar 25 19:08:57 UTC 2024] Deploy error.
20:08:57 - Script de création du certificat wildcard terminé

En regardant les réponses du sujet, je me suis dit que ça devait être un problème de nom de certificat. Et oui, le nom de la variable SYNO_Certificate doit être identique au nom mis dans DSM, sinon on a l'erreur précédente.

Bref, tout fonctionne bien maintenant 😉 Pour le peu que je vais me servir du certificat de mon .ovh dans DSM 😅

le 25 mars

Bonjour 👋🏻

je suis dsns le même cas que vous.

les applications épinglées dans la barre des tâches disparaissent et il faut les ré-épingler à nouveau . Et ce fréquemment.

Jai contacté le support à ce propos il y a quelques mois mais ils n’ont pas su corriger le soucis et mon fait faire un nouvel utilisateur admin pour voir si ça faisait pareil.

bref c’est bien chiant 🤬

le 24 mars

Ha, je crois qu'un fois, j'avais fait quelque chose comme ce qui est décrit dans le lien suivant :

https://linuxconfig.org/how-to-setup-the-rsync-daemon-on-linux

Sinon, après presque 12h, la grosse sauvegarde a été restaurée... mais affichait un message d'échec, car deux applications n'ont pu être restaurée : Universal Search, et un autre dont j'ai oublié le nom.
Toutes les autres applications ont pu être restaurées. Toutes les tâches Hyperbackup sont présentes 🥳, mais faut que je les reconnecte.
Les 1,2 To ont pu être restaurés également.

J'en suis à la restauration des 600 Go restants via la commande rsync dans un terminal.
J'ai quelque peu modifié mon script pour pouvoir quitter avec un CTRL+C, et pour checker à la fin de chaque dossier s'il y a des erreurs :

#!/bin/bash
clear
declare -a source_folders_to_sync_ARRAY=()
declare -a destination_folders_ARRAY=()

folder_name_list="/volume1/homes/Miles-ADMIN/folder_name_list.log"
LOG_FILE="/volume1/homes/Miles-ADMIN/rsync_vers_Syno_script.log"
rsync_LOG_FILE="/volume1/homes/Miles-ADMIN/rsync-restauration_depuis_asustor.log"

if [ -f "${LOG_FILE}" ]; then
    echo "${LOG_FILE} exists, removing"
    rm "${LOG_FILE}"
fi


# while read -r line; do

#     if [[ "${line}" == "" ]]; then
#         printf "\nDossier %s sans nom. On passe." "${line}" 2>&1 | tee -a "${LOG_FILE}"
#     else
#         printf "\nCopie rsync du dossier : %s ...\n" "${line}" 2>&1 | tee -a "${LOG_FILE}"
#         source_folders_to_sync_ARRAY+=source_folders_to_sync_ARRAY("${line}")
#         destination_folders_ARRAY+=destination_folders_ARRAY("${line}")
#     fi
# done <"$folder_name_list"


echo "Création de la liste des dossiers à restaurer à partir du fichier $folder_name_list"
lines=$(cat $folder_name_list)
for line in $lines; do
    # echo "$line"
    if [[ "${line}" == "" ]]; then
        printf "\nDossier %s sans nom. On passe." "${line}" 2>&1 | tee -a "${LOG_FILE}"
    else
        # printf "\nCopie rsync du dossier : %s ...\n" "${line}" 2>&1 | tee -a "${LOG_FILE}"
        source_folders_to_sync_ARRAY=( "${source_folders_to_sync_ARRAY[@]}" "${line}" )
        # source_folders_to_sync_ARRAY+=source_folders_to_sync_ARRAY( "${line}" )
        # destination_folders_ARRAY+=destination_folders_ARRAY("${line}")
    fi
done


echo "Copie du contenu des dossiers sauvegardés via Rsync vers le Syno, dossier par dossier" 2>&1 | tee -a "${LOG_FILE}"

for folder in "${source_folders_to_sync_ARRAY[@]}"; do
    folder_dest="${folder}"

    printf "\n\t--> Dossier source \"%s\" qui va être restauré avec le dossier de destination \"%s\" sur le Synology\n" "${folder}" "${folder_dest}" 2>&1 | tee -a "${LOG_FILE}"
    
    # read -n 1 -r -s -p "Press any key to continue..." key
    
    rsync --password-file=/volume1/homes/Miles-ADMIN/secret_rsync_pwd_asustor -avh --progress --stats --exclude={'@eaDir','#recycle','~$*.*','~*','~*.tmp','desktop.ini','.DS_Store'} --log-file="${rsync_LOG_FILE}" rsync://MilesBackup@192.168.2.203:/Backup-TMP/Backup_Temp_Syno/"${folder}"/ /volume1/"${folder_dest}"/  2>&1 | tee -a "${LOG_FILE}"

    read -n 1 -r -s -p "Press any key to continue..." key

    # printf "\n"
done


printf "\n\nCopie du contenu des dossiers sauvegardés via Rsync vers le Syno, dossier par dossier terminé.\n" 2>&1 | tee -a "${LOG_FILE}"

le 24 mars

Bonjour à tous,

Pour ma curiosité personnelle, comment puis-je réussir à établir une connexion rsync depuis l'asustor vers le Syno depuis l'asustor lui-même ?

le 23 mars

il y a 20 minutes, Kramlech a dit :

Est-ce qu'au niveau du Syno, tu as bien activé le service rsync ?

Oui bien entendu 😊

sur un autre port que le 22.

pour mon script , j’ai des erreurs rsync de copie (faudra que je le relance pour faire un copier coller ici), j’ai arrêté le script (d’ailleurs pas le choix que de relancer la connexion ssh sinon un ctrl+c ne fait rien…)

le 23 mars

Bon je n'ai pas le choix que de passer par la ligne de commande pour lancer rsync.
Mais impossible de lancer depuis l'asustor, car je n'arrive pas à me connecter sur le Syno...
Alors que l'inverse est possible.

Je me suis fait un petit script pour copier le contenu des dossiers :

#!/bin/bash

folder_name_list="/volume1/homes/MonUserADMIN/folder_name_list.log"
rsync_LOG_FILE="/volume1/homes/MonUserADMIN/rsync-restauration_depuis_asustor.log"

echo "Copie du contenu des dossiers sauvegardés via Rsync vers le Syno, dossier par dossier"

while read -r line; do

    if [[ "${line}" == "" ]]; then
        printf "\nDossier %s sans nom. On passe." "${line}"
    else
        printf "\nCopie rsync du dossier : %s ...\n" "${line}"

        rsync --password-file=/volume1/homes/MonUserADMIN/secret_rsync_pwd_asustor -avXh --progress --stats --exclude={'@eaDir','#recycle','~$*.*','~*','~*.tmp','desktop.ini','.DS_Store'} --log-file="${rsync_LOG_FILE}" rsync://MilesBackup@192.168.2.203:/Backup-TMP-Syno/Backup_Temp_Syno/"${line}"/ /volume1/"${line}"/

    fi
done <"$folder_name_list"


printf "\n\nCopie du contenu des dossiers sauvegardés via Rsync vers le Syno, dossier par dossier terminé.\n"

J'ai la liste des dossiers dans le fichier folder_name_list, et le mot de passe rsync dans le fichier secret_rsync_pwd_asustor.

Je ne comprends pas pourquoi je n'arrive pas à avoir une communication rsync depuis l'asustor vers le Syno...

Je précise que la commande ssh fonctionne bien.

le 23 mars

edit : bon bah la sauvegarde rsync monoversion ne passe pas.
En revanche, les multiversions veulent bien se laisser restaurer.

Vous avez une technique pour restaurer les dossiers partargés qui ont été sauvegardés par un rsync sans verisonning ?

le 23 mars

Bon, et bien je n'ai pas tout récupéré comme avant...
Je n'ai plus aucune tâche de sauvegardes hypoerbackup, même après restauration des paramètres via le .dss.

Mais bon j'ai récupéré une bonne partie des paramétrages.

Par contre, la tâche de backup Rsync simple version ne peut pas être reconnectée... du coup je ne sais pas trop comment faire la restauration de ces données-là autrement que par un simple copier/coller via un montage SMB...

Vous avez une idée ?

J'ai fini par trouver comment faire pour restaurer depuis un référentiel existant.
Mais j'ia cette erreur :

Une idée de pourquoi et comment rectifier ?

le 23 mars

salut 👋🏻

Dites hier j’ai voulu restaurer ma sauvegarde dsm et il faut que je me connecte avec l’utilisa « admin » qui est désactivé. C’est normal ?

je n’ai d’ailleurs pas vu d’option pour restaurer le .dss à l’installation de dsm.

le 22 mars

Nickel 🙂

Merci.

Je vais quand même sortir les disques et passer un coup de formatage rapide depuis un ordinateur (sauf les NVMe, car je n'ai pas ce qu'il faut).
Je vais aussi en profiter pour passer les 4 To en secteurs 4k au lieu de 512 (faut encore que je retrouve comment faire XD)

le 22 mars

Il y a 8 heures, Mic13710 a dit :

De toute manière, il faudra que @MilesTEG1 vérifie que c'est bien le cas à la fin de l'opération et avant de créer le ou les groupes.

@Mic13710 @.Shad. @Jeff777

Est-ce que c'est bon ça ?

Je pense que oui 🙂

J'ai fait la réinitialisation depuis DSM, puis réinstallation de DSM depuis Synology Assistant.

le 22 mars

Ok je vérifierais avant de tout refaire niveau stockage.

deja une fois les sauvegardes finies (elles sont encore en cours …), je supprime les volumes , j’efface les disques effaçables depuis dsm , je casse le shr principal en gardant un seul disque , l’autre est effacé et ensuite je verrai.

est-ce qu’on peut depuis synolgy assistant formater le dernier disque et réinstaller dsm ?

le 22 mars

@.Shad.haaa oui j’avais fait ça pour intégrer Crowdsec 😊

c’est une bonne idée 😊👍🏻

le 22 mars

il y a 49 minutes, .Shad. a dit :

C'est l'option à utiliser pour un formatage total oui.

Ha cool ça alors, donc ça supprime toutes les partitions, et donc ça pourra récréer les partitions root à 8Go ?

il y a 51 minutes, .Shad. a dit :
Si tu mets tes infos dans des .env rien n'apparaîtra sur Github, car tu les chargeras avec :
env_file:
  - stack.env
Et si tu passes tes stack en version 3+ tu peux utiliser les docker secrets au besoin.

Ha ! Donc les .env ne seront pas envoyés sur GH ?

Pour les docker secrets, je ne sais pas comment ça fonctionne, bien que j'en ai entendu parler.

le 22 mars

@.Shad.Tu vas abandonner le macvlan ?

En ce qui me concerne j'ai placé SWAG sur un NUC, donc plus besoin du macvlan.
Mais j'ai continué à utiliser ton travail sur SWAG ^^

Connexion

Profils

Forums

Calendrier

Blogs

Messages posté(e)s par MilesTEG1

Information importante