23 Nov 2018, 00:00

Centre réseau qui n'est plus connecté

J’ai eu récemment un poste dont le Centre réseau et partage m’indiquait systématiquement comme non connecté, alors que le DHCP faisait son office correctement, et que la connexion fonctionnait. Il y avait systématiquement une croix rouge au lieu du symbole de connexion, et il était impossible de gérer les réseaux wifi. Après de longues recherches sur le net, c’est la commande suivante, en administrateur, qui a résolu le souci :

net localgroup Administrateurs localservice /add

23 Nov 2018, 00:00

crng init done

Dans les versions du noyau disponibles dans stretch-backports, il m’est arrivé sur plusieurs machines d’avoir un démarrage très long (1 à 2 minutes sans activité visible), avec un blocage tant que la phrase “crng init done” n’est pas apparue.
Visiblement, certaines fonctions/pilotes nécessitent d’avoir le pool d’entropie rempli, ce qui peut dorénavant prendre plusieurs minutes.

Pour corriger ceci, il semblerait que les paquets haveged, rng-tools et/où rng-tools5 améliorent la vitesse d’acquisition de l’entropie, à défaut de trouver une solution plus pérenne.

07 Nov 2018, 00:00

Réinitialiser le mot de passe BIOS sur certains portables HP

HPBR

Un outil nommé HP Bios Reset permet, sur certains modèles, notamment des Probook et des Elitebook, de réinitialiser le mot de passe du bios. Lien vers le thread mydigitallife.
Et un exemplaire de HPBR mirroré chez moi

Il faut déjà créer la clé bootable.
Depuis Windows, il suffit de lancer l’exécutable, de brancher la clé (qui sera effacée), la sélectionner, cliquer sur Restore, choisir le fichier image fourni dans l’archive.
Sous Linux, je n’ai pas testé, mais je présume que l’image se dumpe simplement sur la clé avec dd.

On boote l’ordinateur sur la clé. Au lancement, il faut en trer les commandes suivantes :

cd ..
HPBR

Dans “reprogram” on peut sauvegarder les informations actuelles (fichiers .sav dans le répertoire HPBR).
Dans “first run” on peut lancer la réinit du mot de passe du bios en choisissant le bon modèle.

Forcer l’upgrade du bios

Dans mon cas, le bios était trop vieux, et n’était pas supporté par HPBR. J’ai donc du faire la mise à jour, mais la procédure standard me demandait le mot de passe, que je n’avais toujours pas.

Pour ceci, des indications données sur ce post peuvent être utiles. Les images et signatures de BIOS sont stockées dans le dossier Hewlett-Packard/BIOS/Current. L’image HPBR en contient certains, mais pas tous. On peut donc rajouter celui d’un autre modèle.
J’ai donc récupéré le bios le plus récent sur le site de support de HP.
J’ai extrait le fichier exe, puis le fichier rom.cab.
Dedans, il y’a un fichier “ver.txt”, on trouve dedans le numéro de la ROM, par exemple _ROM_ 68PDD v0F.20 12/07/2011 ROLL_BACK_WARNING
Dans ce cas, c’est “68PDD”. On renomme rom.bin par 68PDD.bin et efibios.sig par 68PDD.sig, on copie ces 2 fichiers dans “Current” (à noter que sur un clé usb vierge en fat32, l’arborescence et ces 2 fichiers suffisent pour la MAJ du BIOS, pas besoin de HPBR).
On éjecte la clé proprement.

Ensuite, il faut faire booter l’ordi sur la clé, mais pas par le boot habituel. Il faut, ordi éteint, brancher la clé, maintenir Super+B, allumer le pc en maintenant les touches enfoncées, normalement la LED de VerrMaj clignote, puis le voyant de la clé usb (s’il y’en a un…) va commencer à clignoter. C’est le moment de relacher les touches.

Normalement l’écran reste noir, pendant au maximum 2 minutes (selon le readme), puis devrait redémarrer tout seul et informer du succès de la mise à jour. Il est alors possible de reset le mot de passe via HPBR
Si rien ne se passe au bout de 10 minutes (soyons précautionneux…) ,c’est que la MAJ n’a pas réussi, et il faut redémarrer le poste.

29 Oct 2018, 00:00

Utilisation de ddrutility pour identifier les secteurs contenant de la données NTFS pour une utilisation optimale de ddrescue

EDIT

Il semblerait que partclone permette aussi de créer le fichier domaine, sur plusieurs systèmes de fichiers, avec la syntaxe :

sudo partclone.FSTYPE -s /dev/sdX_1 -D --offset_domain=1048576 -o ./domain.log

L’option -s (sdX_1) précise la source, c’est-à-dire la partition à cartographier (par ex sdb1 ou loop0p1),
-D précise que nous souhaitons créer un fichier de domaine,
l’offset calculé de la même manière qu’expliqué plus loin dans l’article (et utile seulement si on dumpe le disque entier),
-o nomme le fichier de sortie.
A noter que le fichier créé est par défaut non lisible par les non-root. De plus; le fichier de domaine n’intégrera pas (contrairement à ddrutility) les zones à lire pour identifier correctement la table de partition et les débuts/fins de partitions.

———

Cet article se penche sur l’utilisation de ddrutility pour créer un fichier de carte de domaine à utiliser avec ddrescue, afin de focaliser ce dernier sur les secteurs qui contiennent effectivement des données. Dans cet exemple, je ne parle que du ntfs.

L’ensemble d’utilitaires ddrutility peut être installé depuis les dépôts Debian à partir de Buster, ou bien compilé depuis la source disponible ici.

L’utilitaire qui nous intéresse : ddru_ntfsbitmap qui va créer un fichier de domaine, c’est-à-dire une liste des secteurs à lire sur la partition ntfs (secteurs effectivement utilisés). Concrètement, ce fichier a le même format qu’un fichier mapfile de ddrescue, mais où les secteurs censés contenir des données sont déterminés grâce à l’analyse du MBR et de la MFT, et sont marqués comme “finished” (lus), bien que rien ne soit effectivement lu.

Ceci ne fonctionnera que si ddrescuelog est présent dans la release de ddrescue (à partir de la version 1.15, normalement)

Création du fichier de délimitation du domaine

Voici la syntaxe pour une partition seule :

sudo ddru_ntfsbitmap /dev/sdX1 ./domain_ntfs.log

Dans mon cas, j’ai l’habitude de dumper le disque en entier, y compris la table de partitions. Pour ceci, il faut calculer l’offset de la partition (en octets) avec des maths assez simples : multiplier le secteur de démarrage de la partition par la taille d’un secteur en octets. Pour ceci : sudo fdisk -lu /dev/sdX qui nous donne par exemple :

Disk /dev/sdX: 465,7 GiB, 500074283008 bytes, 976707584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a183

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdX1        2048 976707583 976705536 465,7G  7 HPFS/NTFS/exFAT

On voit que la partition démarre au secteur 2048, et que chaque secteur pèse 512 bytes (octets). On multiplie donc : 2048*512 = 1048576, puis on passe l’argument -i à ddrutility, ce qui donne la commande

sudo ddru_ntfsbitmap /dev/sdX ./domain_ntfs.log -i 1048576

Ceci va aller lire le secteur de boot de la partition ntfs, puis la section bitmap afin de déterminer quels sont les clusters sur lesquels des données sont stockées. Selon la doc de ddrutility, si des secteurs du bitmap sont illisibles, alors ddrutility va les remplir avec le motif 0xFF (soit uniquement des 1), ce qui signifie que les secteurs en question sont utilisés pour stocker des données. Ainsi, en l’absence de certitude (grâce à la lecture correcte du bitmap) qu’un secteur est inutilisé, alors il sera extrait par ddrescue. On a ainsi le “risque” de lire des secteurs inutilisés, mais beaucoup moins de risque de sauter des secteurs sur lesquels des données sont effectivement stockées !

On obtient plusieurs fichiers en résultat :

  • __bootsec qui est un dump du secteur de boot de la partition (et est utilisé pour trouver l’emplacement de la MFT
  • __bootsec.log : la mapfile ddrescue utilisée pour l’extraction du secteur de boot

  • __mftshort : dump de la MFT

  • __mftshort.log : mapfile utilisée par ddrescue pour dumper la MFT

  • __bitmapfile : dump du fichier $BitMap de la partition

  • _partX__bitmapfile.log : fichier mapfile utilisé par ddrescue pour dumper le fichier $BitMap. Il est possible qu’il y en ait plusieurs si le fichier $BitMap est fragmenté

  • ntfsbitmap_rescue_report.log : résumé des différentes passes de ddru

  • domain_ntfs.log : le fichier à donner à ddrescue lors de la réelle tentative de récupération de données. Le nom dépend de la ligne de commande invoquée.

Utilisation de ce fichier avec ddrescue

Il faut impérativement penser à accorder la ligne de commande ddrescue avec celle utilisée par ddrutility pour obtenir le fichier domaine. Notamment déterminer si on dumpe une partition ou bien un disque entier. Dans mon cas, c’est un disque entier.

Une fois le fichier obtenu, on peut lancer la récupération de données avec ddrescue avec l’option -m, comme ceci :

sudo ddrescue -m ./domain_ntfs.log /dev/sdX ./disk_image.img mapfile.log

Si on souhaite suivre l’avancement en graphique avec ddrescueview, il est possible dans le menu de ce dernier d’ouvrir une mapfile de domaine (et séléctionner domain_ntfs.log). Ainsi, le secteurs hors domaine seront coloriés en grisé.

À noter qu’il est possible de combiner cette méthode avec ddrescue sans carte de domaine, en utilisant le même fichier source (disque défectueux), la même destination et la même mapfile. Après avoir laissé tourner ddrescue séquentiellement sur le disque, et une récupération extremement lente (quelques ko/s), j’ai repris l’avancement en cours en rajoutant l’argument de la carte de domaine. Il est également possible de reprendre le dump du disque sans carte de domaine une fois que tous les secteurs sur la carte de domaine ont été correctement récupérés (même si cela devrait théoriquement être inutile).

Analyse des secteurs défectueux pour connaître les fichiers affectés

Le disque dur sur lequel je travaillais m’a donné un taux de récupération supérieur à 99%, mais toutefois incomplet.
Pour connaître la liste des fichiers dont certains secteurs peuvent être manquants, ddrutility propose un autre utilitaire, ddru_ntfsfindbad.

Bien qu’il puisse fonctionner directement sur le disque, il est plutôt prévu pour être utilisé sur l’image résultant de la récupération avec ddrescue. En effet, à ce stade, l’image devrait être suffisamment complète pour ne pas avoir à refaire de lecture lente et incertaine sur le disque défaillant.

De la même manière que ddru_ntfsbitmap, cet utilitaire va avoir besoin de connaître l’offset de la partition, et de pouvoir lire la MFT ntfs (si cette dernière est endommagée, le processus risque d’être compliqué et infructueux…).

Pour ceci, je lance : ddru_ntfsfindbad ./disk_image.img mapfile.log -i 1048576
Le fichier disk_image.img doit être précisément celui créé par ddrescue.
Le fichier mapfile.log doit aussi être celui utilisé par ddrescue.
L’offset (-i) doit être le même que celui determiné à l’étape ddru_ntfsbitmap (si seule la partition du disque défaillant est dumpée, alors il vaut 0 et n’a pas besoin d’être précisé).
Seront comptabilisés comme secteurs non lisibles au moins les secteurs “non-trimmed” et les secteurs “failed”, mais pas les “non-tried”.

L’outil va ensuite créer un fichier ntfsfindbad.log, qui contient la liste des fichiers/dossiers dont la récupération est incomplète, et qu’il suffit de lire pour obtenir les informations !
Notons enfin que l’outil est prévu pour lister les fichiers qui sont dans la corbeille (et qui seront clairement affiché comme présents dans le dossier “$RECYCLE.BIN”), mais PAS les fichiers supprimés (pour ceci, un outil du genre testdisk ou photorec est plus adapté).

28 Jul 2018, 00:00

Divers - Office 365 - Exchange online

Équivalences AD / O365 / EAC si ADConnect paramétré

Globalement, l’autorisation “Gérer” de AD correspond au status “Propriétaire” sous O365.
Ce qui existe dans l’AD est transmis vers O365/EAC, l’inverse n’est pas (forcément) vrai. Si on souhaite avoir les éléments en local, il FAUT les créer en local.
Les autorisations d’envoyer un mail “en tant que” (par ex. en tant qu’un groupe de distribution) se gèrent dans tous les cas dans l’EAC, car dans le setup actuel, il n’y a pas de serveur Exchange en local, seulement sur O365.

Utilisateurs

Un utilisateur créé sous AD apparaîtra dans O365 sous “Utilisateurs actifs” et dans EAC sous “Destinataires -> Boîtes aux lettres”. C’est un utilisateur à part entière avec boîte mail dédiée.

Groupes de sécurité

Un groupe de sécurité créé sous AD peut avoir une adresse mail renseignée ou non.

Si adresse, il apparaîtra dans O365 sous “Groupes” (en tant que “Sécurité avec extension messagerie”) et dans EAC sous “Destinataires -> Groupes” (en tant que “Sécurité à extension courrier”).

Si aucune adresse mail n’est renseignée, il apparaitra sous O365 sous “Groupes” (en tant que “Sécurité”) et n’apparaitra PAS dans EAC.

C’est avant tout un groupe pour l’organisation de l’entreprise (GPO de l’AD, etc.), qui peut également être utilisé pour remettre un courrier à tous les membres de ce groupe.
Si un autre groupe est lui-même membre du groupe, les utilisateurs de cet autre groupe ne recevront le mail QUE SI cet autre groupe a une adresse de messagerie renseignée dans ses propriétés (ceci permet de couper le transfert vers les N+1 par exemple, si on ne met pas d’adresse mail).

Groupes de distribution

Un groupe de distribution créé sous AD apparaitra dans O365 sous “Groupes” en tant que “Liste de distribution” et dans EAC sous “Destinataires -> Groupes” en tant que Liste de distribution. Il faut lui définir une adresse mail, sans quoi son intérêt est très limité (il semble qu’il n’apparaisse as dans EAC si pas d’adresse mail renseignée).

C’est un alias qui va rediriger le courrier envoyé à l’adresse en question vers tous les membres inclus dedans (permet une gestion différente des groupes de sécurité).
Si un sous-groupe est lui-même membre du groupe, les utilisateurs de ce sous-groupe ne recevront le mail QUE SI le sous-groupe a une adresse de messagerie renseignée dans ses propriétés.

L’autorisation “Send As” ne peut être définie que directement dans le EAC. Par contre, si le groupe a été créé sur AD, l’autorisation “Send On Behalf” est définie dans ADSI, sous l’attribut “publicDelegates”. Il faut toujours attendre quelques (dizaines de) minutes pour que les changements soient effectifs sous Exchange.
Dans certains cas, le client Outlook d’un utilisateur peut rester “bloqué” sur l’intention d’envoyer “de la part de” (on behalf), ce qui echouera si la seule autorisation accordée est “send as”. Pour “réinitialiser” le comportement du client, il faut désactiver puis réactiver le mode “en cache” du compte Exchange.

Boîte au lettres partagées

Il s’agit d’une boîte à part entière, avec son propre stockage/quota (quota de 99Go à l’heure de cet article). Elle permet de centraliser des messages partagés par plusieurs utilisateurs, ainsi que le calendrier. Sur l’Outlook de l’utilisateur, la boîte sera distincte de celle de l’utilisateur.
Elle permet également de partager un calendrier entre tous les utilisteurs.

Comme nous n’avons dans le cas présent pas de serveur Exchange en local, il ne me semble pas possible d’en créer une sur l’AD. Elle peut être créée dans l’EAC sous “Destinataires -> Boîte aux lettres partagée”.

Elle n’apparaitra pas dans l’AD, mais dans O365 sous les ““Utilisateurs actifs, et bien sûr dans l’EAC.

Création d’une boite aux lettres partagées avec déploiement automatique (dont calendrier)

Dans le centre d’administration Exchange (EAC), on peut aller dans Recipients -> Shared, et créer une boite aux lettres partagées. Tous les utilisateurs qui sont entrés dans les propriétés de la boite partagée -> Mailbox delegation -> Full access verront la boite mail ainsi que son calendrier se déployer automatiquement sur leur client Outlook (avec toutefois un délai jusqu’à une heure).
Ceci correspond à une vraie boîte mail à part entière, avec son propre espace de stockage (quota de 99Go à l’heure de cet article) et apparaitra sur le client outlook séparée de la boite principale.

Il semblerait que l’ajout d’un groupe de sécurité, même avec adrese mail renseignée, ne déploie pas automatiquement les boites et calendriers chez les membres du groupe.

Liste de distribution (alias) sur EAC

Dans le EAC -> Recipients -> Groups, on peut créer des listes de distributions. Ceci ne correspond pas à une vraie boîte mail, mais plutôt à un alias. Les messages sont transférés à tous les utilisateurs définis dans les propriétés de la liste -> Membership.
Si on souhaite qu’un utilisateur puisse écrire depuis l’adresse de la liste de distribution, il faut ajouter l’utilisateur en question dans les propriétés de la liste -> Group delegation, et ajouter son nom sous Send As (envoi en tant qu’alias) ou bien Send on Behalf (envoi en tant que user au nom de alias).

Pour que l’utilisateur puisse envoyer des messages depuis sont Outlook (version de bureau), il faut ajouter le champ De qui est masqué par défaut. Sous 2016, ceci peut se faire dans la fenêtre de rédaction d’un message, sous l’onglet Options. Ensuite, on ajoute à la main le nom de l’alias qui doit servir à envoyer le message. Si les paramètres serveur sont corrects, l’envoi devrait fonctionner. Sinon, essayer de désactiver puis réactiver le mode “en cache” du compte Exchange.

11 May 2018, 00:00

Installer une interface réseau virtuelle sous Debian et utilisation par Virtualbox

Création de l’interface virtuelle

Chargement du module

On peut créer très simplement une interface réseau virtuelle grâce au module dummy fourni par le noyau. Pour ceci, taper :

sudo modprobe dummy

et vérifier que cela ne renvoie pas d’erreur. Il faut ajouter ‘dummy’ au fichier /etc/modules pour un chargement automatique au démarrage.

Configuration réseau

[EDIT] J’ai finalement opté pour un pont br0 qui associe dummy0 et une carte réseau physique eth1. Dans ces conditions, aucune des 2 cartes n’a d’adresse IP directement, seul br0 en possède une, et dummy0 peut rester en NOARP, cela ne genera pas la circulation des paquets.
br0 est toujours en up (contrairement à eth1 qui ne l’est pas si pas de cable branché, ce qui empeche de bridger une VM VBox dessus sans cable) et l’ARP est activé par défaut (contrairement à dummy0, ce qui empêche de bridger la VM VBox sur dummy0 sans scripter l’activation de l’ARP…)

La suite reste ici à titre informatif [/EDIT]

On ajoute ensuite une entrée dans le /etc/network/interfaces

auto dummy0
iface dummy0 inet static
    address 192.168.2.1
    netmask 255.255.255.0
    network 192.168.2.0
    broadcast 192.168.2.255

pour une adresse statique. On redémarre le service :

sudo service networking restart

et on vérifie que la carte est bien détectée avec sudo ifconfig dummy0, qui doit donner quelque chose comme ça :

dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 192.168.2.1  netmask 255.255.255.0  broadcast 192.168.2.255
        inet6 fe80::440f:8eff:fe69:4e35  prefixlen 64  scopeid 0x20<link>
        ether 46:0f:8e:69:4e:35  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 107  overruns 0  frame 0
        TX packets 606  bytes 43672 (42.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On voit qu’elle porte le flag NOARP, alors que l’arp est nécessaire pour pouvoir communiquer en ethernet. On tape donc

sudo ip l set dummy0 up arp on

On peut aussi, si on le souhaite, activer le flag multicast

sudo ip l set dummy0 up multicast on

La route vers le nouveau réseau est normalement configurée automatiquement.

Lien avec VirtualBox

Mon LAN principal est en 192.168.1.x.
Je souhaite mettre en place un réseau distinct derrière cette carte, qui aie sa propre plage IP (192.168.2.x) et serveur DHCP, pour faire des tests de serveur. Je souhaite toutefois que les VM dans ce réseau puissent avoir accès à mon LAN principal (et vice-versa), et à Internet.

Config dans VBox

Il suffit de paramétrer la carte réseau de la VM en accès ponté avec la carte dummy0.
Plusieurs VM peuvent être bridgées à cette interface, elles pourront toutes communiquer ensemble (comme autour d’un switch) ainsi qu’avec Internet via l’hôte.

Forward ipv4

Pour que la machine (Debian) hébergeant la VM accepte de transmettre les paquets, il faut taper :

sudo sysctl -w net.ipv4.ip_forward=1

afin l’activer à la volée. Et rajouter

net.ipv4.ip_forward = 1

au fichier /etc/sysctl.conf pour que ce soit pris en compte à chaque démarrage.

Routage

Il faut activer le masquerading (NAT) sur les paquets sortant par l’interface eth0 (à adapter avec le nom de l’interface réseau principale, connectée à internet. Ainsi, les périphériques ne connaissant pas le réseau VBox auront l’impression que les requêtes viennent directement de l’hôte, connu.

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Cela suffit à donner au système invité un accès complet à routes les ressources LAN/Internet.

Sous Debian, les règles iptables sont défaut perdues au reboot. Le paquet iptables-persistent peut s’occuper de les sauvegarder et restaurer au démarrage.

Cependant, je souhaitais aussi que les machines de mon LAN principal puissent accéder à toutes les machines virtuelles de mon réseau VBox. Pour ceci, il faut utiliser une route qui va vers le réseau 192.168.2.0/24 et qui a pour passerelle l’ip de la machine hôte sur le réseau principal, par exemple en 192.168.1.x. Ainsi, n’importe quel machine du LAN physique pourra accéder à n’importe quelle machine du LAN virtuel.

Cette route doit être paramétrée en statique dans le routeur, et peut éventuellement être distribuée directement aux clients par DHCP. Tous les routeurs ne permettent hélas pas ces 2 possibilités.

10 May 2018, 00:00

Mise en place d'une réplication/failover AD/DNS/DHCP/DFS sur 2 Windows Server

Préambule

Je pars d’une situation où j’ai déjà un serveur Windows 2012R2 configuré en controleur de domaine, avec GPO et partage de fichiers. Je veux ajouter un 2e serveur sous Windows Server 2016, qui fasse office principalement de failover si un des 2 serveurs tombe en panne. Ceci pour les rôles de contrôleur de domaine, de serveur DHCP, serveur DNS, de serveur SMB et déploiement automatique de partages réseaux et d’imprimantes.

Le domaine est WINDOMAIN, le serveur actuel est WINDOMAIN\DC1.

Configurer le serveur secondaire

On commence par relier le serveur au réseau, on lui configure une adresse ip fixe, le hostname souhaité (ici DC2). on le connecte au domaine.

On peut ensuite installer le rôle AD DS, puis promouvoir le serveur en contrôleur de domaine.
La réplication de l’AD se fait automatiquement, avec toutes les GPO.

DNS

Intégration à l’AD

Normalement, le serveur DNS est installé et configuré en même temps que le serveur AD DS. Ceci permet aux enregistrements DNS d’être stockés dans l’AD directement, et donc d’être répliqués entre tous les controleurs de domaine. Cela se vérifie dans le gestionnaire DNS, avec un clic droit -> Propriétés sur une zone, on doit voir l’Etat “Intégré à AD”.
Ceci ne fonctionne que si les 2 serveurs DNS sont aussi des controleurs de domaine, ce qui est le cas ici. Si un serveur DNS n’est pas controleur, il faut passer par la création sur le second serveur d’une zone secondaire qui pointera vers le premier serveur).

Un peu plus d’infos chez Microsoft

Redirecteurs

Toujours dans le gestionnaire DNS, dans les propriétés de chaque serveur, il faut penser à aller vérifier les redirecteurs (serveur DNS utilisé si le serveur intégré ne sait pas résoudre, c’est-à-dire pour tout ce qui ne relève pas du domaine). Typiquement, on peut mettre l’IP de notre box, ou 8.8.8.8 par exemple. Il y’a aussi l’option de se rapatrier sur les serveurs DNS racines en cas d’indisponibilité des redirecteurs. On trouve la liste de ces serveurs dans l’onglet “Indications de racine”.

Distribution par DHCP

Enfin, il faut aller paramétrer les options du DHCP pour qu’il distribue les 2 serveurs DNS. Pour ceci, dans DC1 (actuellement le seul serveur DHCP), aller dans le gestionnaire DHCP, IPv4 -> Étendue -> Options d’étendue et ajouter l’IP du nouveau serveur dans les Serveurs DNS (006).

Note : si un des 2 serveurs venait à être en panne/hors-ligne durablement, penser à s’assurer que le serveur toujours en place est bien distribué en serveur primaire, ceci accélérera la résolution DNS.

DHCP

La première étape est d’avoir une étendue active sur un des 2 serveurs, dans cet exemple sur DC1. Si ce n’est pas le cas, on peut en créer une dans le gestionnaire DHCP -> Nouvelle étendue. L’installation est complètement guidée.
Penser à spécifier les options telles que serveurs DNS, passerelle par défaut.

Sur DC2, installer le rôle Serveur DHCP. Ne pas configurer d’étendue maintenant, elle va être automatiquement répliquée depuis DC1.
Aller sur DC1 dans le gestionnaire DHCP, IPv4 -> Clic-droit sur “Étendue” -> Configurer un basculement
Suivre les étapes en ajoutant l’IP du serveur secondaire (DC2).

Au cours de la création du basculement, les options du serveur DHCP de DC1 seront répliquées sur DC2 (étendue, route par défaut, serveur DNS etc°. Toutefois ces options ne seront par la suite plus synchronisées automatiquement. Pour les synchroniser, on peut lancer sur le serveur “source”, qui possède les informations à jour, la commande Powershell suivante :

Invoke-DhcpServerv4FailoverReplication

qui va répliquer l’ensemble de ses paramèters sur tous les serveurs partenaires.
Il y’a aussi un script planifié qui permet de faire ceci automatiquement, disponible sur cette page avec l’archive zip mirroré sur mon memo.

Si on souhaite supprimer la relation de basculement, il faut savoir que si on procède à la déconfiguration du basculement sur DC1, cela supprimera automatiquement l’étendue sur DC2 (et vice-versa).

Partage de fichiers

Afin d’assurer l’accès aux partages réseaux même si un des 2 serveurs (hébergeant directement les données) tombe, nous allons passer par la réplication DFS. Celle-ci va nous permettre une synchronisation instantanée et permanente de l’état des dossiers de travail, tout en y accédant de manière transparente par le réseau, via un espace de nom DFS.

Dans mon cas, je pars d’un dossier de travail déjà existant, sur DC1, avec le chemin D:\Travail\. Celui-ci est paramétré avec des droits d’accès spécifiques, et le partage réseau est déployé automatiquement via GPO avec le chemin \\DC1\Travail\.

Configuration de la réplication DFS (DFSR)

Il faut commencer par installer le rôle Services de fichiers et de stockage -> Services de fichiers et iSCSI -> Espaces de noms DFS et Réplication DFS sur DC1 ET sur DC2.

On lance le Gestionnaire de système de fichiers distribué DFS.
Réplication -> Nouveau groupe de réplication.... J’ai laissé le choix par défaut, groupe de réplication multi-usages.
On donne un nom au groupe de réplication, dans mon cas “Travail”.
On ajoute DC1 et DC2 dans la liste des serveurs.
Pour une réplication dans les 2 sens, quel que soit le serveur sur lequel les données sont modifiées, on choisit “Maille pleine”. J’ai laissé les options de bande passante par défaut, puisq’on est ici en réseau local.

On prend bien garde à choisir le serveur qui contient actuellement les données en tant que Membre principal. Il s’agit ici de DC1, car DC2 ne contient actuellement aucune donnée. Ainsi, au cours de la synchro initiale, toutes les données présentes actuellement sur DC1 seront répliquées sur le ou les autres serveurs. une fois la synchro initiale terminée, cela ira dans les 2 sens.

On choisit ensuite le dossier local où sont stockées les données sur DC1. C’est D:\Travail comme indiqué au-dessus.
Note : Microsoft eux-même déconseillent de répliquer directement une lettre de lecteur, bien que ce soit censé fonctionner. J’ai personnellement eu des soucis lorsque j’ai essayé. Il faut ensuite la réplication sur chaque serveur membre. On coche la case Activé, et on définit un chemin local sur le membre en question. Il n’est pas obligatoire que tous les membres aient le même chemin d’accès local.

On valide, et la réplication commencera sous peu. Les données seront ainsi sur les 2 serveurs. Toutefois, le partage réseau déployé chez les clients ne fait toujours appel qu’au serveur DC1.

Configuration de l’espace de nom DFS (DFSN)

Généralités

L’idée est de pouvoir centraliser les partages réseaux en y accédant via le nom de domaine. Par exemple, au lieu de déployer \\DC1\Travail, on va déployer le partage \\WINDOMAIN\Travail, et ce sera un des serveurs qui hébergent l’espace de nom Travail qui va répondre.

Cette techno est complètement dissociable de la réplication, bien qu’elles soient souvent utilisées ensemble. On peut décider de partager sous des chemins unifiés des ressources venant de serveurs différents (par exemple \\DC1\Travail et \\DC2\Direction, même si uniques sur leurs serveurs respectifs, peuvent être accessibles sous \\WINDOMAIN\Travail et \\WINDOMAIN\Direction). On peut aussi utiliser la réplication sans espace de noms, juste pour dupliquer les données d’un site à l’autre par exemple.

Si 2 serveurs hébergent le même espace de nom, mais sans réplication des dossiers, le contenu affiché sera alternativement le contenu de l’un ou l’autre. Par exemple, si \\DC1\Travail et \\DC2\Travail sont tous les 2 référencés par l’espace de nom \\WINDOMAIN\Travail mais que les 2 dossiers ne sont pas répliqués et ont des contenus différents, on ne sait jamais quel sera le contenu affiché par \\WINDOMAIN\Travail, ce sera celui qui répond le plus vite.

Mise en place

On ouvre le gestionnaire DFS.
Espace de noms (clic-droit) -> Nouvel espace de noms. On choisit DC1 comme premier serveur. On nomme notre espace de nom, ici Travail ; Dans Modifier les paramètres, on peut choisir l’emplacement des données locales. On choisit ici D:\Travail, comme défini précédemment, et on choisit les droits d’accès Admin : Full ; Users : RW (les vrais droits d’accès sont gérés par le NTFS).
On choisit l’option “Espace de noms de domaine”, puis on valide la création.

Le serveur DC1 est maintenant prêt à répondre lorsqu’on appelle \WINDOMAIN\Travail. On veut maintenant que DC2 puisse répondre aussi. Pour ceci, dans le gestionnaire DFS, sous Espaces de noms, clic-droit sur \WINDOMAIN\Travail -> Ajouter un serveur d’espaces de noms. Comme ci-dessus, on rentre le nom du serveur, on choit l’emplacement local des données, on met les droits sur le partage et on valide.

Et voilà : les 2 serveurs sont désormais capables de répondre lorsque l’on interroge le partage directement auprès du domaine, et grace à la combinaison avec la réplication, la continuité en cas de chute d’un serveur est quasi-transparente (à un caffouilage d’explorer près, sur les postes clients).

Note : il est possible, directement sous l’espace de noms DFS? de “Publier” des dossiers, qui seront créés puis partagés automatiquement, et référencés dans le gestionnaire. Il n’est pas du tout obligatoire de les utiliser si l’on souhaite créer des sous-dossiers et les partager, et le faire manuellement permet une plus grande souplesse (chemin du partage réseau notamment).

05 May 2018, 00:00

Chemin absolu dans un script bash

Pour lancer un script bash en se positionnant initialement dans le répertoire qui contient ce script bash (nécessaire dans certains cas, par exemple pour qu’un exécutable de jeu trouve le dossier data dont il a besoin pour se lancer, dans le cas des jeux Unity), ce de manière automatique quel que soit le répertoire en question, et même s’il a des caractères spéciaux du type espace ou accent, il suffit de faire commencer le script par cette ligne :

cd "`dirname "$0"`"

Cette commande va chercher le chemin complet du script lancé ($0) et y positionne le terminal.

05 May 2018, 00:00

Librairies pour les jeux sous Wine

Pour résoudre des erreurs de type

0009:err:d3dcompiler:compile_shader HLSL shader parsing failed

tester

winetricks d3dcompiler_43

28 Apr 2018, 00:00

Supprimer récursivement les fichiers corrompus suite à récupération de données peu concluante

Suite à une récupération de données via ddrescue qui n’a que peu fonctionné, le disque ne répondant rapidement plus du tout, j’ai essayé de tirer parti du peu que j’avais en ma possession.

L’image a été montée sous Windows via VirtualBox, les chkdsk nécéssaires ont été effectués, le système de fichier est redevenu lisible sous Linux comme sous Windows, mais malgré ça, une bonne partie des fichiers référencés par le NTFS n’étaient pas lisibles, car leur emplacement (qui n’a pas été dumpé depuis le disque) ne contenait rien d’autre que des 0.

Lorsque, sous Linux, on fait un file monfichier.jpg, on voit que dans le cas d’un fichier corrompu, comme il n’y a aucune donnée à analyser, le retour est un simple “data”.

J’ai donc utilisé cet indicateur pour supprimer tous les fichiers sans donnée, via le script suivant, rangé sous ~/del_empty.sh :

#!/bin/bash

cd "$1"
for i in *; do
    type=`file -b "./$i"`
    if [ "$type" = "data" ]
    then
        rm "./$i"
    fi
done

Ce script, qui fait référence à la variable de position $1, est voué à être utilisé en conjonction avec la commande find :

find /path/to/data/ -type d -exec ~/del_empty.sh {} \;

Puis on supprime automatiquement les dossiers vides

find /path/to/data/ -type d -empty -print -delete

Il ne reste plus qu’à découvrir ce qu’il reste des données initiales…