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 ;

Général

Azure Files est un stockage cloud, accessible via SMB par une machine locale, ou une VM Azure.

Azure Files peut stocker plusieurs types de ressources, comme les conteneurs blob, mais je m’intéresse ici uniquement aux partages de fichiers.

Il y’a également la possibilité de créer des partages NFS, mais je n’aborde pas ce cas ici. Un partage est accessible soit par SMB soit par NFS, mais pas les 2 en même temps.

Guide de planification général Azure Files

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-planning

Quelques considérations

MS conseille de ne pas mélanger les différents types de ressources au sein d’un même compte de stockage (si il contient un partage Azure Files, alors il est déconseillé d’y mettre un stocke blob par exemple).

Dans la mesure du possible, essayer de ne mettre qu’un seul partage par compte de stockage (chaque partage aura son propre compte de stockage).

Compte de stockage

https://learn.microsoft.com/fr-fr/azure/storage/common/storage-account-overview

La gestion se fait sur le portail Azure, section “Comptes de stockage”.
Il faut créer un compte de stockage (qui lui-même doit appartenir à un groupe de ressources).
Les performances du compte de stockage (standard ou premium) est défini définitivement à la création du compte.

Le compte de stockage est protégé par 2 clés, “storage account key”. On peut les voir sur le portail Azure, dans le compte de stockage -> Sécurité + réseau (colonne de gauche) -> Clé d’accès.
Ces clés donnent un accès admin complet à l’ensemble des partages et données du compte de stockage.

Pay-as-you-go ou provisionned

https://learn.microsoft.com/en-us/azure/storage/files/understanding-billing

Calculateur de coûts ici :
https://azure.microsoft.com/en-us/pricing/calculator/

Il y a 2 modèles de facturation pour les partages Azure Files :

• le modèle provisionné v2 (le v1 est uniquement pour les storage premium, en SSD) (on définit d’avance une capacité max de stockage, des IOPS et de la bande passante, et le coût est fixe)
• le modèle à l’usage, où on paye chaque Go de stockage, chaque transaction, et chaque Mo de transfert

Le modèle de facturation est défini au niveau du compte de stockage, et sera visible dans ses propriétés (Kind : StorageV2 pour du PAYG, FileStorage pour du provisionné).
Cependant, pour les modèles provisionnés, le décompte de l’usage des ressources est fait pour chaque partage. C’est lorsqu’on déploie un partage que l’on commence à être facturé.

Pour des volumes de données faibles, le modèle PAYG peut être intéressant, mais il revient vite cher s’il y’a du volume de données (~ 300€/mois pour 2.7 To de données en cool storage dont le seul accès est la sauvegarde quotidienne ; en cool storage, le coût des transactions est vite important ! )

Le modèle provisionné peut vite être + intéressant, mais il a des quantités minimum (32Go, 500IOPS, 60MiB/s) qui induisent des coûts fixes, avec un minimum de ~30€/mois pour chaque partage.
Il est possible d’augmenter les performances du partage à tout moment. Pour ça :
Comptes de stockage -> sélectionner -> File shares -> ... (au bout de la ligne du partage) -> Change size and performance
On peut également diminuer le provisonnemnt, mais seulement 1 fois/24h.

Redondance

https://learn.microsoft.com/fr-fr/azure/storage/common/storage-redundancy

LRS : 3 copies dans le même datacenter
ZRS : 1 copie dans chacun de 3 datacenter différents (dans la même région primaire)
GRS : LRS en zone primaire + LRS en zone secondaire
GZRS : ZRS en zone primaire + LRS en zone secondaire

Le niveau de redondance est défini au niveau du compte de stockage, mais il pourra être changé par la suite. Pour ceci :
Storage accounts -> sélectionner -> Data management -> Redundancy
et choisir la nouvelle redondance.
Attention MS prévient que ça peut mettre plusieurs jours (ou semaines !) pour démarrer.

Zones de disponibilité :
https://learn.microsoft.com/fr-fr/azure/reliability/availability-zones-overview?tabs=azure-cli#azure-regions-with-availability-zones

Partages

Une fois le compte de stockage créé, on peut créer des partages (Portail -> Comptes de stockage -> Partages de fichiers puis + Partage de fichiers). Le nom ne peut pas contenir de majuscule.

Chaque partage a son propre niveau de performance (froid, chaud, optimisé pour les transactions).
Celui-ci peut se changer par la suite si besoin.
MS conseille, s’il y a des gros volumes à transférer, de commencer par le niveau optimisé pour les transactions le temps de la migration, puis de repasser à un autre niveau après.

Chaque partage a ses paramètres de sauvegarde.

Suppression réversible (Soft delete)

Concerne uniquement la suppression d’un partage (et non de fichiers dans ce partage).
Si activé, lorsqu’un partage est supprimé, il reste “dans la corbeille” pendant un temps (configurable).
Activé au niveau du compte de stockage, pour tous les partages lui appartenant.
Article chez MS

Les partages dans l’état soft-delete sont facturés selon le modèle de facturation choisie pour le compte de stockage (ils comptent comme s’ils étaient actifs).

Paramètres SMB

Récap chez Microsoft

L’accès SMBv3 est ok pour Windows 10 et Debian Bullseye. Les paramètres SMB sont identiques pour tous les partages au sein d’un compte de stockage.

Accéder au partage Azure Files

Article chez Microsoft

Obtenir l’UNC

Ça devrait toujours être \\nomducomptedestockage.file.core.windows.net\nom-du-partage .

Pour le vérifier :
Azure Portal -> Comptes de stockage -> Sélectionner le compte de stockage souhaité -> Partage de fichiers (colonne de gauche du panneau central) puis clic sur Connecter
Cela donne un script, dans lequel on trouve l’UNC.
On y voit aussi la clé de sécurité, derrière le /pass=

Connexion via clé

Si on veut établir la connexion manuellement, on peut ajouter les informations de connection dans Panneau de configuration -> Comptes d'utilisateur -> informations de connexion Windows (ou à la volée lors de la connexion) :

• Adresse : nomducomptedestockage.file.core.windows.net
• Utilisateur : nomducomptedestockage (ou localhost\nomducomptedestockage )
• Mot de passe : clé du compte de stockage

Il est bien sûr possible d’automatiser le déploiement de ce partage via GPO (ou Intune).

Depuis Linux

smb://nomducomptedestockage.file.core.windows.net/nom-du-partage
Mêmes utilisateurs et mot de passe. “Domaine” non-pertinent.

Authentification/autorisations

Article chez Microsoft

L’accès au partage se fait :

• soit par la “storage account key” (donne un accès complet admin à tous les partages du compte de stockage)
• soit par un accès basé sur l’identité (IAM)

Si on veut utiliser l’IAM, il est bien de commencer par vérifier que le montage fonctionne en utilisant la storage key, pour s’assurer du bon fonctionnement de la partie réseau sans s’occuper de la partie authentification.

Si on veut utiliser l’IAM, il faut le paramétrer. Un paramétrage sur le compte de stockage lui-même est nécessaire (chaque entité doit avoir les droits d’accès au compte de stockage pour accéder à un partage inclus dedans).

Ce paramétrage se fait sur le portail, dans Compte de stockage -> le choisir -> Access Control (IAM) -> Add -> Add role assignment .
On recherche “SMB”, puis on choisit le rôle “Storage File Data SMB Share Contributor” (pour un contributeur simple, qui peut modifier les fichiers).
On y affecte ensuite l’entité qui doit bénéficier de ce rôle (un groupe, un utilisateur).

Si on souhaite pouvoir modifier les ACL directement sur les dossiers/fichiers, depuis l’explorateur Windows, il faut accorder le rôle “Collaborateur à privilèges élevés de partage SMB des données du fichier de stockage”.

Chaque partage de ce compte héritera de cette IAM. Il est possible de surcharger chacun des partage avec d’autres droits (par exemple refus d’accès ?).

Il y a 3 méthodes d’authentification auprès d’une “source AD”, chacune avec ses spécificités.

Auprès d’un AD local (AD DS)

Il est nécessaire de pouvoir contacter ce DC local lors de l’établissement de la connexion au partage.
Ce DC local peut éventuellement être hébergé dans le cloud, avec accès via un VPN.
Disponible seulement pour les utilisateurs hybrides (synchronisés depuis le DC local vers Entra ID).

Introduction - MS
Activation - MS

Entra Domain Services (Entra DS, anciennement Azure AD DS)

Il s’agit d’un domaine géré (managé) par MS, qui fournit entre autres des fonctionnalités de DC et de GPO.
Il semble plutôt fait pour la gestion centralisée de serveurs virtuels, et il ne peut être contacté que via la connexion à un VPN.
Prend en charge les utilisateurs hybrides ainsi que cloud-only.
Les clients (postes utilisateurs) ne peuvent pas être Entra-joined ou Entra-registered.
les clients doivent être joints au domaine hosté pour que tout soit automatisé.
Il est toutefois possible de monter le partage depuis un poste non-joint à un domaine en fournissant des IDs explicites.

Récap chez Microsoft
Activation

Entra Kerberos

C’est une authentification directement auprès d’Entra, uniquement pour les utilisteurs hybrides (synchronisés depuis un DC local).
L’accès peut se faire sans besoin de connexion au DC (sauf pour régler les droits d’accès, là une connexion au DC sera nécessaire).
Les postes clients doivent être Entra-joined ou Entra-hybrid-joined ; pas ok si joints à Entra DS ou si joints uniquement à un AD local.

Détails sur mon memo

Migration des données

https://learn.microsoft.com/fr-fr/azure/storage/files/storage-files-migration-overview

Plusieurs méthodes possibles ; par exemple :

• simplement avec robocopy d’un lecteur à l’autre
• avec Azure Storage Mover
• avec Azure Files Sync

Azure Files Sync

https://brouillons.raphaelguetta.fr/post/azure-files-sync/

Pour synchroniser un serveur local avec un partage Azure Files Sync
https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-planning

Possible de faire de la synchro simple.
Possible aussi de donner au server local un rôle de cache, les clients s’adressant à lui et lui échangeant avec Azure.

Azure Storage Mover

https://learn.microsoft.com/en-us/azure/storage-mover/service-overview

Capable de gérer des gros volumes de données.
Transfère les metadonnées.

Requiert la création sur Azure d’une ressource Azure Storage Mover
Requiert ensuite la création d’un agent (apparement c’est une VM)

Coût

https://azure.microsoft.com/fr-fr/pricing/details/storage/files/#pricing

Il y’a plusieurs choses distinctes qui sont facturées : stockage utilisé, transactions (lecture/écriture de données), metadonnées, backups, snapshots etc…

Facturation provisionnée (espace pré-payé, qu’il soit utilisé ou non)

Facturation à l’usage pour les modes standard (optimisé pour les transactions, chaud, froid).

Le stockage est de moins en cher quand on descend dans les gammes (optimisé pr transactions -> chaud -> froid)
Les transactions sont de + en + chères quand on descend dans la gamme.

Il est possible de changer le niveau de chacun des partages à tout moment. Ceci entraîne toutefois des transactions donc de la facturation.

Sauvegarde

https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview

Vault

Il faut créer un “Recovery Services vault”
https://learn.microsoft.com/en-us/azure/backup/backup-create-recovery-services-vault
Pour ceci, dans le portail Azure, chercher “Business Continuity Center”, et ouvrir Manage -> Vaults.

Attention, il n’est actuellement pas possible de changer la redondance d’un vault après sa création (ou au moins tant que des éléments sont backupés dedans).

Backup policy

Il faut ensuite créer une politique de sauvegarde ; consiste en un vault de destination, un type de sauvegarde (snapshot-only, ou bien vault), une fréquence de sauvegarde et une durée de rétention des sauvegardes. Pour ceci :
https://learn.microsoft.com/en-us/azure/backup/quick-backup-azure-files-vault-tier-portal

Une fois créé, toujours dans “Business Continuity Center”, ouvrir Manage -> Protection Policies puis Create policy -> Create backup policy. Choisir “Azure Files (Azure Storage)” et sélectionner le vault précédemment créé.

Pour une sauvegarde complète, MS recommande de choisir “Vault-Standard” comme niveau de sauvegarde.
Choisir la fréquence de sauvegarde (au + fréquent toutes les 4h, et 6 sauvegardes par jour).

Une fois créée, la politique apparaît dans la liste des “Protection policies”, en tant que politique gérée par Azure. Il faut toutefois s’assurer que la “Datasource type” est bien définie sur “Azure Files (Azure Storage)” pour la voir apparaître.

Activation de la sauvegarde

Aller dans “Business Continuity Center -> Overview” et cliquer sur “+ Configure protection”. Choisir “Azure”, “Azure Files” et “Azure Backup” en solution.
Choisir le vault créé précedemment.
Choisir le compte de stockage contenant les données à sauvegarder. Choisir le ou les partages à inclure dans la sauvegarde. Choisir la stratégie de sauvegarde désirée (celle créée précédemment).

Les différents partages au sein d’un même compte de stockage ne peuvent pas utiliser des vaults différents. On peut choisir de ne pas sauvegarder tous les partages d’un compte de stockage, mais ceux sauvegardés le seront tous dans le même vault.

Déclenchement manuel d’une sauvegarde

Aller dans les détails du vault, puis Protected items -> Backups items. Choisir “Azure Storage”.
Choisir le partage à sauvegarder, et ouvrir les détails, puis clic sur “Backup now”.
Les points de sauvegarde déclenchés manuellement ne sont pas soumis à la politique de rétention standard, mais ont une date de validité définie directement lors de la création du backup (par défaut c’est 1 mois).
L’avancement de la sauvegarde peut être suivi dans les notifications.

Restauration

https://learn.microsoft.com/en-us/azure/backup/restore-afs

Dans les propriétés d’un partage, si on va dans Operations -> Snapshots, on peut voir les snapshots disponibles.
On peut accéder à chacun d’eux via l’explorateur Windows, via clic-droit -> Restaurer les versions précédentes.

Suppression du partage

Dans le cas où un partage est supprimé, les données apparaissent toujours dans le vault, mais ne sont pas restorables/explorables !
Le message suivant s’affiche :
Listed restore points are not available as the associated file share containing the restore point snapshots has been deleted permanently. We recommend undeleting file-shares within the soft-delete retention period to prevent permanent deletion.Learn More

Changement de Vault pour un compte de stockage

https://learn.microsoft.com/en-us/azure/backup/backup-azure-files-faq

Pour pouvoir changer le vault qui recevra les sauvegardes d’un compte de stockage, il faut d’abord désactiver la protection pour chacun des partages de ce compte, puis désenregistrer le compte de stockage du vault.

Pour stopper la protection, aller dans Business continuity Center -> Protected items. Choisir “Azure Files” en source. Choisir les partages appartenant au compte de stockage concerné. Choisir Stop Backup dans la barre du haut.
La doc MS indique qu’on peut choisir de conserver les données sauvegardées, ou bien de les supprimer ; mais dans mon expérience, il est indispensable de les supprimer pour pouvoir désenregistrer le compte de stockage.

Une fois la protection stoppée, ouvrir le vault actuel, puis aller dans Manage -> Backup infrastructure puis Azure storage accounts -> Storage accounts.
Choisir le compte de stockage à désassocier, clic sur les … à droite puis “Unregister”.

Limites de quantités de sauvegarde

https://learn.microsoft.com/en-us/azure/backup/azure-file-share-support-matrix

Rapport par mail

Business Continuity Center -> Monitoring + Reporting -> Reports

Coût et soft-delete

https://azure.microsoft.com/en-us/pricing/details/backup/

L’option de soft-delete des données de sauvegarde, activée par défaut, peut se définir dans les propriétés du vault :
Business Continuity Center -> Vaults -> choisir - Settings -> Properties -> Soft Delete and security settings
Lorsque cette option est activée, lors la suppression d’une sauvegarde, les données de celle-ci sont conservées pendant 14 jours.

On peut désactiver cette fonctionnalité, ou bien modifier/augmenter la durée de rétention après suppression.
Selon cette page :
https://learn.microsoft.com/en-us/azure/backup/backup-azure-enhanced-soft-delete-about#pricing
la conservation des données est gratuite pendant 14 jours (en cas d’augmentation de la durée de conservation, ce sont les 14 derniers jours qui sont gratuits ; si on undelete les données avant la fin de la rétention, on paye depuis le 1er jour).

Snapshots

Il y a un coût d’abonnement de ~6€/mois.

Pour le modèle pay-as-you-go, l’espace utilisé par les snapshots est facturé au même coût que le stockage Azure Files. Son espace dépend de l’évolution des données (des données n’évoluant pas du tout n’utiliseront aucun espace pour leurs snapshots).
Pour voir l’espace utilisé par les snapshots d’un compte de stockage,
Storage accounts -> sélectionner -> Monitoring -> Metrics puis régler ainsi :
Metric Namespace : File
Metric : Fileshare Snapshot Size
Dans ce modèle pay-as-you-go, on a l’info pour l’ensemble du compte de stockage ; il ne me semble pas possible de décomposer par partage.

Pour le modèle provisionned v2, l’espace utilisé par les snapshots essaye de rentrer dans le quota provisionné.
Si le total de l’espace utilisé (fichiers+snapshots) ne dépasse pas l’espace provisionné, il n’y aura pas de surcoût.
Si l’espace utilisé total dépasse le quota provionné, les snapshots sont facturés à part (environ 1€/100Go/mois).
Pour voir l’espace utilisé par les snapshots, même méthode que ci-dessus, mais il y a en + une section Metrics dans le détail du partage (ou on peut afficher les métriques du compte de stockage puis ajouter un filtre sur le nom du partage, ce qui revient au même).

Recovery Services Vault

Il y a un abonnement mensuel de ~12€/vault/mois.

L’espace utilisé dans le vault est également facturé, avec son propre coût, dépendant notamment de la redondance choisie.

Disques managés

disques virtuels attachables à une VM azure en tant que disque local
https://azure.microsoft.com/fr-fr/pricing/details/managed-disks/
en HDD, 8To = 300€/mois

Montable sur plusieurs serveurs virtuels ?

Généralités

L’authentification via Entra kerberos permet à un poste de s’authentifier sur Azure Files (ou autre application hébergée sur Azure) en ayant uniquement besoin d’être en lien avec internet (nécessité de pouvoir contacter certains noms de domaine publics appartenant à Microsoft).
Cette authentification passe par un ticket Kerberos émis par Azure, qui doit être récupéré par le poste client lors de la connexion utilisateur.

Elle repose sur une architecture hybride (utilisateurs existants sur un AD local qui sont synchronisés sur Entra via Entra Connect Sync).
Les postes utilisés pour accéder aux ressources Azure doivent également être en jonction hybride à Azure (donc joints au domaine local, puis joints à MS Entra). Une jonction simple à Entra, ou une jonction simple au domaine local, ne permettront pas l’authentification auprès des ressources cloud.

Il est nécessaire d’avoir une connectivité au DC local pour définir les autorisations NTFS sur les fichiers/dossiers du partage Azure Files.

Il est également nécessaire d’avoir une connectivité au DC local pour établir la jonction hybride d’un poste.
Il est aussi nécessaire d’avoir une connectivité au domaine local pour paramétrer le poste pour récupérer toutes les informations nécessaires à l’établissement de la connexion au partage réseau Azure Files.
Une fois cette connexion établie, on peut accéder au partage Azure Files sans connectivité au DC (à voir s’il faut renouveler le ticket Kerberos de temps en temps avec un dialogue avec le DC ?)

Présentation générale chez MS

Prérequis

• il faut une synchronisation des utilisateurs locaux vers Entra via Entra Connect Sync (utilisateurs hybrides)
• il faut une jointure hybride des postes à Entra
• le compte de stockage Azure ne doit pas avoir d’autre méthode d’auth déjà activée (la désactiver si c’est le cas)
• les services WinHttpAutoProxySvc et iphlpsvc doivent être en cours d’exécution (sur le poste client je suppose ? Ça devrait être le cas par défaut)
• l’authentification multifacteurs (MFA) doit être désactivée pour l’appli Azure représentant le compte de stockage
• l’OS client doit être Win 10 Pro/Entreprise v2004 ou ultérieure, ou Win Server 2022, complètement à jour (note : pour un serveur qui définit les droits, synchronise vers Entra, mais n’accède pas à des partages Azure, un Server 2016 est OK)

Activation de l’auth

Via le portail Azure

Comptes de stockage -> sélectionner le compte -> Stockage des données -> Partages de fichiers
À côté de “Accès basé sur l’identité”, choisir “Configurer” puis choisir “Microsoft Entra Kerberos”.

J’ai personnellement eu une erreur lors de l’activation en passant par le portail Azure (error : is not available with June21 api version alors je suis passé par Powershell.

Via Powershell

Si besoin :
Install-Module -Name Az.Storage
puis
Connect-AzAccount

Pour activer l’auth :

$rgname = "myressourcegroup"
$saname = "mystorageaccount"
Set-AzStorageAccount -ResourceGroupName $rgname -StorageAccountName $saname -EnableAzureActiveDirectoryKerberosForFile $true 

Si on fait ceci depuis un DC local, on peut extraire le nom de domaine local et le GUID de domaine local avec ces commandes :

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot

et on peut alors ajouter ces arguments à la commande précédente :
-ActiveDirectoryDomainName $domainName -ActiveDirectoryDomainGuid $domainGuid

Autorisation de l’application

Étape indispensable

Aller sur Entra ID -> Identité -> Applications -> Inscription des applications
et choisir Toutes les applications

On doit y retrouver une application nommée “[Storage Account] mystorageaccount.file.core.windows.net”
On la sélectionne, puis on ouvre le menu “API autorisées”, et on y coche “Accorder un consentement d’administrateur pour Ma Super Entreprise”

Note : autorisations par défaut :
Microsoft Graph -> Autorisations déléguées :

• openid
• profile
• User.Read

Configuration des clients

Pour rappel, le client doit être hybrid-joined à Entra après avoir été joint au domaine.

Il faut activer un paramètre autorisant la récupération des tickets Kerberos lors du login.
Ceci peut se faire via GPO, mais uniquement sur Server 2019 et ultérieur, via :
Config Ordi -> Stratégies -> Modèles d'administration -> Système -> Kerberos -> Autoriser la récupération du ticket Kerberos cloud lors de la connexion
Je suppose qu’il est possible d’importer le modèle kerberos.admx mais je ne l’ai pas fait.

Si on n’a pas de Server 2019+ dans le domaine, on peut le faire par une entrée de registre ; manuellement via :
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
ou via une GPO qui ajoute une entrée de registre :
Config ordi -> Préférences -> Paramètres Windows -> Registre -> Nouvel Élément registre :

• Update
• HKLM
• Chemin : SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
• Nom : CloudKerberosTicketRetrievalEnabled
• REG_DWORD
• Valeur : 1

C’est également faisable via intune (voir doc MS).

Il est nécessaire de redémarrer pour appliquer ce paramètre.

une fois ceci fait (et un lecteur connecté ?), on devrait pouvoir voir le ticket Kerberos via la commande klist (à lancer en simple utilisteur et non admin).

Accès à des comptes de stockage Azure via une authentification AD locale

L’activation du paramètre pour Kerberos empêche l’accès par ces postes à un autre compte de stockage Azure, qui serait configuré avec l’authentification via AD locale.
S’il était nécessaire de faire cohabiter les 2, il faudra suivre ces étapes

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

Il m’est arrivé d’avoir un fichier mp3 sur lequel vlc me sortait des tags qui n’étaient pas du tout ceux mentinnés par id3v2.
Après analyse du fichier, j’ai vu qu’il s’agissait de tags Monkey’s Audio (APE tags).

Pour les gérer sous Linux, j’ai trouvé le logiciel apetag (qui n’est pas dans les dépôts Debian).

git clone https://github.com/robertmuth/apetag
make
qui nous donne l’éxécutable apetag (que l’on peut éventuellement mettre dans /usr/local/bin pour l’avoir dans le $PATH).

Usage pour supprimer les tags

apetag -m erase -i file.mp3

Pour plusieurs fichiers à la fois, il me semble que la wildcard ne fonctionne pas, donc avec find :
find ./ -iname "*.mp3" -exec apetag -m erase -i {} \;

FOR /L %N IN () DO @echo "commande" & timeout 5 & "C:\mysoft.exe"

Une source quie m’a aidé

Identification du switch et du port série

Modèle de switch : Catalyst 3560 v2
Port console RJ45 à l’arrière du switch ; câble fourni RJ45 <-> DB9

Sur une Debian Bookworm ; on utilise setserial pour identifier le port, puis minicom pour interagir avec le switch.
apt install minicom setserial
Pour identifier le port série utilisé :
sudo setserial -g /dev/ttyS*

À noter qu’un convertisseur usb sera probablement de la forme /dev/ttyUSB0 .

Ici, le port utilisé est /dev/ttyS0.

Configuration et usage de minicom

La doc Cisco nous indique la config nécessaire : 9600 bauds ; 8b de données ; 1b d’arrêt ; aucune parité ; aucun contrôle de flux.
C’est une config assez classique connue sous la forme “9600 8N1”.

sudo minicom -s
A -> entrer “/dev/ttyS0”
La configuration étant assez classique, elle fait partie des options prédéfinies ; on la sélectionne :
E -> C puis Q ; on vérifier que la config actuelle est bien “9600 8N1”
Entrée
Entrée
Enregistrer config sous .dsl (écrit /etc/minicom/minirc.dfl )

“Sortir de minicom” quitte vraiment minicom
“Sortir” quitte la config et nous affiche l’interface avec le port série.

Il est possible qu’il faille relancer minicom pour activer la config qu’on vient de définir.

Pour quitter minicom :
Ctrl-A -> X

Afficher l’aide :
Ctrl-A -> Z

Communication avec le switch

Une fois minicom lancé, on branche le switch au port serie, on le branche au secteur, et au bout de qqs instants, le log du démarrage devrait apparaître dans minicom.

Une fois le démarrage du switch terminé, avec Entrée on lance l’invite de commande ( Switch> )

Pour afficher les infos ip :
show ip interface

Il arrive que l’ESP soit visible parmi les lecteurs dans l’explorer Windows.

Pour la cacher même après reboot, si diskpart ne fonctionne pas, essayer :
mountvol X: /d

rsyslog

Sous Debian Bookworm, c’est le paquet rsyslog qui est utilisé par défaut.

Son fichier de conf est /etc/rsyslog.conf et il inclut /etc/rsyslog.d/*.conf
rsyslog a ses propres filtres qui lui sont uniques, mais je parle ici des filtres par sélecteurs, qui sont les filtres classiques du syslog originel.

Son principe est d’associer un ou plusieurs sélecteurs à une action.
Page de doc sur les filtres

Un sélecteur est composé d’un ou plusieurs “facility” (sous-système qui a produit le message) et d’une priorité (la sévérité du message).

facility : auth, cron, mail, etc  
priorité : warn, crit, info etc.  (ou * )  

On peut accoler plusieurs facility avec une même priorité graçe à la virgule ,
On peut accoler plusieurs sélecteurs à une même action avec le point-virgule ;

Les actions sont ce qu’on fait du message ; principalement écrire dans un fichier, envoyer sur un tty, envoyer vers un autre poste etc.
Page de doc des actions facility1,facility2.priorité1;facility3.priorité3 action

on peut mettre un “moins” - à ‘action ; pour les fichiers, cela signifie ne pas flush le cache à chaque écriture.

Rediriger cron vers un fichier à part :

Dans /etc/rsyslog.conf, il y’a un catchall qui integrera tout dans syslog, sauf les facility “auth” et “authpriv”.
Si on ne veut pas du tout les logs de cron dans le syslog, et limiter les modifications du fichier principal de conf, il faut commenter cette ligne :
#*.*;auth,authpriv.none -/var/log/syslog

Puis on peut ajouter le fichier /etc/rsyslog.d/00-catchall.conf dans lequel on met :

# Catch everything except auth, authpriv and cron msgs into syslog
*.*;cron,auth,authpriv.none          -/var/log/syslog

et le fichier /etc/rsyslog.d/10-cron.conf avec :

# Log cron stuff
cron.*          /var/log/cron.log

Puis on redémarre rsyslog :
sudo service rsyslog restart