Installer utilitaires CLI

Centre de paquets -> Paramètres -> Sources de paquets
Ajouter une entrée, choisir un nom, et ajouter :
https://packages.synocommunity.com/
comme Emplacement.

L’actualisation devrait se faire tout seul, et on peut alors chercher synocli .
On a notamment les “Disk Tools” qui fournissent entre autres ncdu, et les “File Tools” qui fournissent entre autres nano.

SSH et dossier home

Le SSH s’active dans
Panneau de configuration -> Terminal & SNMP

Si on veut pouvoir y accéder via SFTP, il faut l’activer dans
Panneau de conf -> Services de fichiers -> FTP -> SFTP

Enfin, si on veut pouvoir se connecter via clé SSH, il faut activer les dossiers homes. pour ceci :
Panneau de conf -> Utilisateurs et groupes -> Avancé -> Accueil utilisateur

Synchronisation du dossier partagé

Pour une synchronisation unidirectionnelle d’un Syno source vers un Syno destination.
Fonctionne à l’échelle d’un dossier partagé.
Lance rsync en sous-jacent, avec l’option --delete .

Sur le Syno destination, il faut aller dans
Panneau de conf -> Services de fichiers -> rsync
et activer le service rsync.

Sur le Syno source, il faut aller dans
Panneau de conf -> Services de fichiers -> Avancé
et trouver “Synchronisation du dossier partagé”.
Clic sur “Liste des tâches” et ajouter une tâche (tâche = transfert sortant).

Sur le Syno cible, dans le même menu, on voit l’état du serveur, et on a la possibilité de gérer la “Liste des connexions”, c’est à dire les transferts entrants.

Lorsque la tâche est lancée, la ligne de commande lancée est de ce genre :

/usr/bin/rsync --timeout=600 --verbose --progress --no-h -rlpt -go -H -W --one-file-system --syno-auth --syno-acl --syno-pseudo-root --numeric-ids --exclude-from=/tmp/EXCLUDE  /volume1/MONPARTAGE/ --rsync-path=rsync -e "/usr/bin/ssh -p 11122 -oNumberOfPasswordPrompts=1 -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=10 -oServerAliveCountMax=60" -s raphael@10.0.10.89::Public/ --exclude=/*/#recycle/

et le fichier exclude contient ça :

/#recycle/***
/#snapshot/***
/@eaDir/SYNO@.fileindexdb/***
/@eaDir/SYNO@file_index_queue
/@eaDir/SYNO@file_index_queue.tmp
/@eaDir/SYNO@.fileindexdb@SynoEAStream
/@eaDir/@dedupedb/***

Types de synchro

Depuis le Syno source, si on va dans la section “Liste des tâches”, il y a un bouton pour “Synchroniser maintenant” et un bouton pour “Synchro complète”.

“Synchro maintenant” va faire une synchro très rapide, qui ne fait que copier les fichiers nouveaux/modifiés vers la destination. Pour ~ 20To de données en ~ 4 millions de fichiers, qui a déjà été complètement synchronisé 1h avant, cela met 2-3 minutes. Les fichiers de la destination absents de la source ne sont PAS supprimés.
C’est cette synchro qui est faite par la planification.

“Synchronisation complète” va mettre + de temps (environ 40 minutes pour le même volume de données) mais va créer un miroir complet des données, incluant la suppression des fichiers/dossiers de la destination qui sont absents de la source, ainsi que la réplication des permissions.

Permissions

Lorsque la synchro de dossier partagé est activée, les permissions avancées sont activées sur les partages de la destination ; si on veut que les utilisateurs puissent y acccéder, il faut les ajuster en conséquence (ou les désactiver).
Ça se règle dans le Panneau de config -> Dossiers partagés -> Modifier -> Permissions avancées

Synology Drive Server

Permet la syncho bidirectionnelle entre 2 Syno.

Hyperbackup

Restauration

La restauration d’un dossier partagé se fait en intégralité, sans tenir compte des données pré-existantes.

Lorsqu’on restaure, le contenu existant n’est pas effacé ; il faut d’abord supprimer/vider le partage de réception avant de restaurer Si le partage n’existe pas, il est automatiquement créé.

Spécificités Btrfs

Snapshots

Si le système de fichiers d’un dossier partagé est btrfs, on peut installer le paquet “Snapshot Replication”.
Celui-ci permet de gérer les instantanés. L’assistant est assez intuitif.

Pour un dossier partagé donné, si on coche la case “Rendre visible” (onglet Avancé), on peut accéder aux instantanés dans le dossier #snapshots à la racine du dossier partagé.
Ceci permet également d’activer la fonctionnalité des “Versions précédentes” dans l’explorateur Windows.

Si on veut analyser l’espace utilisé sur le dossier partagé avec ncdu, il faut penser à exclure ce dossier :
ncdu /volume1/MONPARTAGE --exclude "#snapshot*"

Réplication

Permet de dupliquer un dossier partagé vers un 2e NAS, par les commandes btrfs send et btrfs receive.
Si cette fonctionnalité est activée, un snapshot est créé à chaque réplication.

Par défaut, seul l’instantané généré lors de la réplication est répliqué.
Il est toutefois possible d’envoyer en + également les instantanés locaux. C’est une option disponible lors de l’assistant, ou en modifiant la tâche de réplication (onglet Avancé). Elle ne concerne que les instantanés créés après l’activation de l’option.

La rotation des versions des instantanés se paramètre indépendamment sur chaque NAS.

Sur la source, des snapshots des partages réseau sont dans /volume1/@sharesnap. C’est ce chemin qui est utilisé pour le send.
Sur la destination, la replication en cours est stockée dans le dossier /volume1/@sharesnap_receiving/.

La réplication se configure depuis le NAS source, et elle nécessite que les volumes sur les 2 NAS soient formatés en btrfs.
L’utilisateur choisi pour établir la connexion doit être membre du groupe “administrators” sur la destination.

Quand un partage sur la destination est paramétré pour recevoir des instantanés, on ne peut plus lui configurer des instantanés locaux.

Dans les paramètres de l’app Snapshot Replication, on peut modifier le nombre de tâches en parallèle ; par défaut c’est 1 seule.
Ainsi, même si des réplications sont planifiées au même moment, il n’y aura pas de parallélisation des accès disques, afin de conserver des performances optimales.

Nettoyage de l’espace

Pour que l’espace soit réellement récupéré lors de la suppression d’un snapshot, on peut activer le nettoyage des données. Pour ceci :
Gestionnaire de stockage -> Stockage -> bouton “Planifier le nettoyage des données”

On peut choisir des périodes sur lesquelles ce nettoyage est mis en pause.

Divers

restauration des utilisateurs depuis une sauvegarde (.dss) lorsqu’ils existent déjà sur la cible ?
-> les passwords des utilisateurs existants ne semblent pas remplacés par les éléments de la sauvegarde

Synoacl

synoacltool -add /volume2/backups/latest/LOGICIELS/ everyone:*:deny:-w-pdD-A-W-Co:fd–

find /volume2/backups/history/xxx/$share/* -type d -exec synoacltool -set-archive “{}” is_inherit,is_support_ACL ;

https://www.it-connect.fr/chapitres/les-cinq-roles-fsmo/

Les rôles FSMO sont des rôles spéciaux, chacun détenu par un seul DC au sein du domaine (le maître d’opération).

5 rôles

Primary DC
Maitre des noms de domaine
Contrôleur de schema
Gestionnaire RID
Maitre d’infrastructure

Connaître les maîtres d’opération

Pour avoir les 5 d’un coup :
netdom query fsmo

Pour les avoir 1 par 1 :
dsquery server -hasfsmo <role>
avec <role> pouvant valoir “pdc”, “name”, “schema”, “rid” ou “infr”.

Changer les maîtres d’opération

Sur le détenteur du rôle FSMO, lancer la commande ntdsutil
puis
role
connections
connect to server newservername puis touche q
transfer <role> master
avec pouvant valoir “rid”, “schema”, “infr”, “naming” ou “pdc”
(sauf pour pdc, ne pas mettre “master”)
et confirmer le transfert

Si le maître d’opération n’est plus disponible

Il faut alors “seize” le rôle.
Pour ceci, passer par ntdsutil.
https://support.microsoft.com/help/255504

Si on héberge un WordPress derrière un reverse proxy (dans mon cas jwilder-nginx+letsencrypt) qui gère le https et les certificats, WordPress verra le trafic en non-chiffré.
Il faut donc l’informer que le trafic est chiffré de manière externe, et qu’il doit modifier les URLs en https://.
Si je comprends bien, ceci se fait via la détection d’une en-tête définie par le reverse proxy.

Pour ceci, on ajoute dans le wp-config.php (dans le volume) :

//Load Balancer NGINX Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
    $_SERVER['HTTPS']='on';

Complètement copié-collé de cet article :
https://www.wundertech.net/setup-a-static-ip-address-for-openvpn-clients-on-your-synology-nas/

Testé sur DSM 6, mais pas sur DSM 7.

Pré-requis :

• serveur OpenVPN installé sur le NAS
• accès SSH au NAS, avec un utilisateur aux droits sudoers

L’identification du client dépendra de l’utilisateur (sur le serveur VPN) utilisé pour établir la connexion VPN.
On crée le dossier qui stockera les configurations IP souhaitées.

cd /usr/syno/etc/packages/VPNCenter/
sudo mkdir userIPs
sudo chmod 0755 userIPs
cd userIPs

Créer un fichier du nom (exact) de chaque utilisateur dont on souhaite fixer l’IP.
Notre utilisateur d’exemple s’appelle myUser. Je pense qu’il faut respecter la casse.
Notes sur l’utilisation de vi

sudo vi myUser

Dans ce fichier, coller la ligne suivante en adaptant l’adressage réseau. Attention, le dernier chiffre de la première adresse doit être ((multiple de 4) + 2), et la seconde adresse doit être l’adresse immédiatement précédente.
Choisir une adresse suffisamment élevée pour éviter le conflit avec les adresses attribuées à la volée.

ifconfig-push 10.8.0.202 10.8.0.201

Mettre les autorisations correctes :

sudo chmod 0644 ./*

On configure ensuite le serveur VPN pour prendre en compte ces fichiers :

cd /usr/syno/etc/packages/VPNCenter/openvpn/
sudo vi openvpn.conf

Ajouter dans le fichier la ligne suivante :

client-config-dir /usr/syno/etc/packages/VPNCenter/userIPs/

cd /volume1/@appstore/VPNCenter/etc/openvpn
sudo vi radiusplugin.cnf

et modifier la ligne overwriteccfiles pour obtenir

overwriteccfiles=false

Ensuite, il devrait suffire de redémarrer le Synology (ou éventuellement uniquement les services nécessaires ?) et de vérifier que les réglages sont bien pris en compte.

Sous Windows Server, la stratégie de mot de passe gérée par les GPO est commune à tous les utilisateurs.

À partir de Windows Server 2008 (et 2012 pour l’interface graphique, il me semble), si on veut définir des stratégies plus fines, on peut le faire en passant par les PSO (Password Settings Objects).
Il faut d’abord créer un groupe de sécurité, et y placer les utilisateurs concernés.
Ensuite, ouvrir le Active Directory Admin Center (ADAC) :
dsac.exe
Aller dans domain (local) -> System -> Password Settings Container et faire clic-droit -> Nouveau -> Paramètres de mot de passe.
Donner un nom et une priorité (1 = la + élevée) à la stratégie, régler les paramètres désirés, et choisir le groupe de sécurité précedemment créé dans “S’applique directement à”.

Une fois le PSO créé, il devrait s’appliquer correctement, uniquement aux utilisateurs positionnés dans le groupe, en étant prioritaire par rapport à la stratégie par défaut.

Dans Hyper-V, si on crée un disque virtuel, et qu’on l’attribue à une VM dans un 2nd temps, il est possible qu’elle ne puiss pas démarrer avec le message “Erreur d’accès général refusé” concernant le fichier VHD.

Ceci est parce que chaque VM est un objet de sécurité, et qu’il faut lui affecter les autorisation correctes sur le fichier disque. Pour ceci, lancer Powershell, et obtenir le SID de la VM :
Get-VM 'Mon serveur virtuel' | Select-Object VMID (en entrant le nom de la VM).
Puis lui donner les droits sur le fichier :
icacls hard-disk.vhdx /grant %SID%:F (en entrant le SID trouvé ci-dessus).

La VM devrait alors pouvoir démarrer.

Source

openssl x509 -enddate -noout -in file.crt
Doit fonctionner avec les fichiers crt, pem

Sous Teamviewer, il y’a un ID attribué à la sesion actuellement ouverte et active (non verrouillée), qui est celui qui s’affiche dans la fenêtre ; c’est l’identifiant utilisateur.
Mais si on veut pouvoir accéder au poste à tout moment, il faut l’ID de serveur ; pour l’obtenir, clic-droit sur l’icône de TV dans la zone de notification, puis À propos de Teamviewer.

Depuis Windows Server 2019, l’accès aux dossiers partagés (sur un autre serveur) qui ne nécessitent pas d’authentification est désactivé.
Pour le réactiver, il faut aller dans gpedit.msc, et aller dans Configuration ordinateur -> Modèles d'administration -> Réseau -> Station de travail LANMAN et activer le paramètre Activer les ouvertures de session invité non sécurisées.

Probablement faisable via gpmc.msc dans le cas d’un domaine.

Source

Possible via regedit aussi ?

https://wiki.debian.org/KVM
https://www.how2shout.com/linux/how-to-install-and-configure-kvm-on-debian-11-bullseye-linux/

Pour voir si le processeur possède les extensions matérielles nécessaires pour la virtualisation matérielle :
grep -E --color '(vmx|svm)' /proc/cpuinfo

Qu’est-ce que c’est ?

kvm - QEMU

kvm est un hyperviseur type 1, en espace noyau, sous forme de module noyau pour Linux (intégré au noyau depuis la version 2.6.20). Il permet l’accès aux instructions processeur de virtualisation (Intel-VT ou AMD-V).

QEMU est un émulateur de PC (ou hyperviseur de type 2) : il simule du matériel (disques, RAM etc) pour un système invité. Grâce à kvm, il peut mettre à disposition le processeur physique, pour des performances quasi-natives.

L’un n’a pas besoin de l’autre (kvm peut servir à faire tourner une appli Linux sans OS complet, via containerization, et QEMU peut faire tourner un OS virtuel en émulant complètement un processeur), mais c’est en binôme qu’ils fonctionnent le mieux.

Pour voir si une VM utilise kvm , il faut trouver le PID de la VM, puis entrer la commande strings /proc/<PID>/cmdline|grep kvm. Si oui, on peut y lire “-enable-kvm” ou “accel=kvm”.

Il y’a un module noyau nommé kqemu, qui visait à améliorer les performances de qemu, mais celui-ci a été rendu obsolète par kvm. Son seul avantage potentiel est qu’il fournissait une accélération (logicielle) sur les processeurs ne disposant pas des extensions de virtualisation (mais en ce cas, Virtualbox reste aujourd’hui une solution correcte), si l’invité et l’hôte sont sous la même architecture.

Le paquet qemu-user permet de faire tourner un OS compilé pour une architecure différente du processeur physique ?

libvirt, virsh, virt-install, virt-manager

libvirt est une bibliothèque qui permet de gérer les machines virtuelles. Elle peut aussi se connecter à plusieurs hyperviseurs, dont kvm/QEMU, mais aussi Xen par exemple.

virt-install est une interface en ligne de commande pour simplifier la création de VM.

virsh est une interface en ligne de commande pour interagir avec libvirt, et donc créer, supprimer, modifier, démarrer, arrêter etc. les VMs.

• un “domaine” équivaut à une machine virtuelle.
• pour lister les VMs de la session utilisateur : virsh list --all
• pour lister les VMs de la session système : virsh -c qemu:///system list --all
• pour démarrer une VM système : ‘virsh -c qemu:///system start nom_de_la_vm’

virt-manager est une interface graphique pour interagir avec libvirt (même rôle que virsh, mais en GUI).

virtio

Il me semble que c’est un protocole/une interface pour mettre le matériel de l’hôte à disposition des invités, avec le moins de latence possible. Ces périphériques virtuels nécessitent des pilotes spécifiques, sans quoi ils ne seront pas disponibles, au moins sous Windows. On peut trouver ces pilotes sur cette page.
En montant l’ISO en tant que lecteur CD lors de l’installation de Windows, on peut installer les pilotes pour le contrôleur de disque, à la volée (il faut choisir le dossier qui contient directement les pilotes, il n’y a pas de récursivité).

Virtualbox

C’est simplement un émulateur. Il est plutôt simple d’utilisation, peut être utilisé par un utilisateur non privilégié, mais n’a pas de performances folles.

Xen

Hyperviseur de type 1.

kvm - QEMU

Installation

kvm est déjà présent dans le noyau par défaut. Pour installer QEMU sous Debian Bullseye : sudo apt install qemu-system-x86.
Pour installer virt-manager : sudo apt install virt-manager. Installera automatiquement qemu.
Pour installer le démon libvirt : sudo apt install libvirt-daemon-system

Connexion system ou session

https://blog.wikichoon.com/2016/01/qemusystem-vs-qemusession.html

QEMU peut être utilisé avec une connexion système, ou avec une connexion session.

La connexion système permet l’accès complet à toutes les ressources ; libvirtd est lancé en tant que root, les VMs en tant qu’utilisateur qemu. L’accès d’un utilisateur simple est géré via polkit. On peut ajouter le user au groupe libvirt pour lui permettre un accès aux ressources sans avoir à s’authentifier en root.
La configuration de libvirt est dans /etc/libvirt/.

La connexion session est spécifique à l’utilisateur. Tout est exécuté par l’utilisateur simple. Les configurations/pools sont stockés dans le $HOME. Cependant le réseau accessible par défaut est lent, et peu flexible (difficile à rendre accessible depuis l’extérieur). À voir avec qemu-bridge-helper pour accéder à un pont réseau (créé au préalable par l’admin) ?
La configuration de libvirt est stockée dans $HOME/.config/libvirt.

Détacher souris/clavier de la VM

Par défaut, c’est la combinaison L-Ctrl + L-Alt.

Connexion via SSH

On peut gérer les VMs d’un serveur distant via ssh. Pour ceci, via virsh : virsh --connect qemu+ssh://root@example.com/system.
Via virt-manager, il faut ajouter une connexion, et entrer l’URI qemu+ssh://root@example/system.

En ce cas, il faudra entrer certains chemins manuellement (par exemple pour définir un chemin vers un ISO ou un fichier qcow2), le bouton “Parcourir” étant grisé.

Processeur

La configuration par défaut est de “Copier la configuration du processeur de l’hôte”. Il me semble que ça donne des performances très moyennes. Il vaut mieux décocher cette case et choisir le mode host-passthrough. De même, la détection automatique de la topologie ne me donnait pas de très bons résultats. En choisissant une topologie manuelle, ça fonctionne bien mieux.
Socket : nombre de processeurs physiques sur la MB (1 dans la plupart des cas)
Coeurs : nombre de core du CPU
Chaînes : nombre de thread de chaque core

Périphériques USB ?

Réseau

https://wiki.qemu.org/Documentation/Networking

Le réseau par défaut est un réseau en NAT, et il ne démarre pas automatiquement.
Si on veut bridger une VM à une carte réseau, il faut d’abord créer le pont au niveau système ; il ne semble pas possible de bridger la VM directement à l’interface physique.

Disques

Si connexion à qemu:///system, les pools de stockage (emplacement des fichiers image de disque dur) sont définis dans /etc/libvirt/storage/ et celui par défaut pointe sur /var/lib/libvirt/images/. Les définitions de VMs (fichier XML) sont rangées dans /etc/libvirt/qemu/.

Si connexion à qemu:///session, les pools de stockage dont définis dans $HOME/.config/libvirt/storage/ et celui par défaut pointe vers $HOME/.local/share/libvirt/images/. Les définitions de VMs sont rangées dans $HOME/.config/libvirt/qemu/.

Les images sont au format qcow2.
Il est possible d’utiliser directement un périphérique de type block. Pour ceci, il faut éditer le fichier XML.

Virtualbox

L’avantage principal que je vois est le fait de pouvoir ponter facilement et à la volée la carte réseau virtuelle et n’importe quelle carte réseau (physique, pont ou virtuelle, genre tap0 ), sans préparer le réseau auparavant.

USB

Pour pouvoir passer les périphériques USB à l’invité, l’utilisateur qui lance VBox doit faire partie du groupe vboxusers :
sudo adduser $(whoami) vboxusers

Pour gérer l’USB2 / USB3 , il faut l’extension pack :
sudo apt install virtualbox-ext-pack

On peut passer les périphériques à la volée, via clic-droit sur l’icône USB en bas à droite de la fenêtre de la VM.