11 May 2018, 00:00

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

Création de l’interface virtuelle

[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 et routage

Voir ce post.

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.

Par défaut, lorsque le service DFSR s’arrête, par exemple lorsqu’un serveur reboote, le système lui laisse 30 secondes pour s’éteindre proprement. S’il sépasse ce délai, alors la fermeture sera forcée, de façon brutale.
Or il arrive régulièrement que le service aie besoin de plus de temps que ça pour s’éteindre (dans le cas d’une grosse base de fichiers). Pour éviter ce problème, on peut, sur chaque serveur, accéder à la clé de registre

`HKLM\SYSTEM\CurrentControlSet\Control`

et régler la valeur WaitToKillServiceTimeout sur le nombre de millisecondes que l’on souhaite accorder à l’extinction (de chaque service). Par exemple, 600000 pour laisser 10 minutes. À noter que cette valeur ne peut excéder 1h, sans quoi elle est réinitialisée à la valeur par défaut de 30 secondes. Source

DFSR - Problème de synchronisation

Il peut arriver que certains dossiers ou fichiers ne soient pas répliqués correctement. Plusieurs raisons peuvent expliquer ceci, des problèmes de taille de la Staging Area étant régulièrement évoqués. (cf comment définir une taille de staging)

Une autre raison possible est que les éléments en question soient chiffrés. DFSR ne synchronise pas les fichiers chiffrés.
Le script suivant, strippé de cette page (script bien plus complet et détaillé), permet de lister les fichiers chiffrés dans le fichier $logFile, puis de les déchiffrer

$logFile = "C:\Users\Administrateur\Desktop\EncryptedFiles.log"
$path = "X:\path\to\data"

$encryptedfiles +=  Get-ChildItem $path -File -Recurse -Force -ErrorAction SilentlyContinue |
                    Where-Object { $_.Attributes -match "Encrypted" } |
                    Select-Object -ExpandProperty FullName
	                
foreach ($file in $encryptedfiles){
	Add-Content $logFile "$file"
	(Get-Item -Force -LiteralPath $file).Decrypt()
	}

$encryptedfolders += Get-ChildItem $path -Directory -Recurse -Force -ErrorAction SilentlyContinue |
                     Where-Object { $_.Attributes -match "Encrypted" } |
                     Select-Object -ExpandProperty FullName

foreach ($folder in $encryptedfolders){
	Add-Content $logFile "$folder"
    cipher.exe /d /i $folder
}

juste avant la dernière accolade pour ajouter le déchiffrement automatique.

Une autre raison possible est que DFSR, par design, ne synchronise pas les dossiers/fichiers avec l’attribut “temporaire”. Source : https://blogs.technet.microsoft.com/askds/2008/11/11/dfsr-does-not-replicate-temporary-files/
Or, il peut arriver, sur de gros volumes de données, que des dossiers légitimes contiennent, par erreur (humaine ?), cet attribut. Rien n’indique graphiquement sa présence, et l’utilitaire attrib.exe non plus. Il faut utiliser fsutil pour le consulter.

fsutil usn readdata X:\path\to\folder\

qui retournera quelque chose du genre

Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x0021000000002350
Parent FileRef# : 0x0003000000005f5e
Usn : 0x000000004d431000
Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x5fb
<b>File Attributes : 0x120</b>
File Name Length : 0x10
File Name Offset : 0x3c
FileName : test.txt

On y voit que, dans les attributs du fichier, le masque 0x100 est présent. Selon la table donnée dans le lien ci-dessus, il correspond à l’attribut TEMPORARY.

Pour le supprimer récursivement, on passe par Powershell :

Get-childitem X:\PATH -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

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 hébergeant 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…

27 Apr 2018, 00:00

Monter une image de disque complet sous Linux (y compris Gparted, et VirtualBox)

Présentation et analyse

Si on a créé une image entière de disque (par exemple avec dd , dcfldd ou bien ddrescue), il est possible de la monter au sein du système, pour qu’elle soit détectée par le noyau, par Gparted, et même transférable (en tant que disque brut) à une machine virtuelle sous VirtualBox.

Dans mon exemple, on a le fichier /home/user/sdi.img, qui est une image complète d’un disque (avec le boot code et la table de partition, dans cet exemple au format MBR).

On vérifie la structure de l’image (qui doit être une copie du disque, donc avec une ou des partitions) : sudo fdisk -l ~/sdi.img. Chez moi, ça donne :

Disk sdi.img: 1,8 TiB, 2000399892480 bytes, 3907031040 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: 0x909b28dc

Device     Boot Start        End    Sectors  Size Id Type
sdi.img1   *     2048 3907031039 3907028992  1,8T  7 HPFS/NTFS/exFAT

J’ai bien la partition sdi.img1, formattée en NTFS.

Montage du disque complet

On utilise pour ça la commande losetup (en root).
Si on l’exécute toute seul, elle nous liste les périphériques actuellement montés. Par défaut, ce devrait être vide.
Si on l’exécute avec le paramètre -f, elle nous donne le premier périphérique disponible pour monter une image. Par défaut, ce devrait être /dev/loop0.

On monte l’image sur le périphérique loop : sudo losetup -r -P /dev/loop0 ~/sdi.img.
Note : l’option -r sert à monter le périphérique en lecture seule, pour éviter les corruptions de données, au cas où.
L’image est bien montée (vérifiable avec losetup sans argument), mais la partition n’est pour l’instant pas prise en compte par le noyau. (EDIT : plus vrai avec l’option -P)

Prise en compte de la table de partition par le noyau

EDIT : l’option losetup -P permet de faire cette étape automatiquement. Ceci dit c’est toujours bien d’avoir un peu les détails des rouages :)

Pour ceci : sudo partprobe /dev/loop0.

Ceci va dire au noyau d’aller réactualiser la table des partitions connues (en l’occurence en n’analysant que le périphérique loop0). Ceci a du créer les périphériques pour chacune des partitions de l’image (pour moi une seule). On vérifie : ls -l /dev/loop0* qui donne chez moi :

 20423171 brw-rw---- 1 root disk   7, 0 avril 27 13:56 /dev/loop0
213017956 brw-rw---- 1 root disk 259, 0 avril 27 13:56 /dev/loop0p1

J’ai bien le périphérique loop0p1 qui représente la première partition de mon image. On peut alors utiliser cette partition comme une partition physique : la monter (sudo mount /dev/loop0p1 /mnt), la fsck (sudo fsck /dev/loop0p1) etc.
On peut également manipuler l’image comme un vrai disque avec Gparted : sudo gparted /dev/loop0. Il faut spécifier manuellement l’emplacement, car Gparted sans argument ne liste que les disques physiques.

À noter, si la partition a été retrécie via GParted, l’image du disque ne le sera pas pour autant (car l’espace non-partitionné existe toujours). Pour ceci, suivant les conseils de ce billet, on peut lancer la commande sudo fdisk -l /home/user/sdi.img pour analyser la table de partition, puis utiliser la commande truncate pour couper l’image dès que la partition se finit. Pour ceci, on multiplie le numéro de secteur final de la dernière partition+1 par la taile des secteurs (logique, je suppose, en cas de différence entre physique et logique. A vérifier).

Par exemple, selon mon exemple en début d’article :

truncate --size=$[(3907031039+1)*512] /home/user/sdi.img

Accès à l’image depuis Virtualbox

VirtualBox permet l’accès depuis le système invité aux disques physiques de la machine hôte. Cela se fait via les disques virtuels VMDK.

Cette partie est grandement recopiée de ce billet.

On commence par s’assurer qu’on fait bien partie du groupe disk : sudo usermod -G disk -a `whoami` (et on pense à log out pour appliquer les modifs). Ceci permet de pouvoir accéder aux disques sans avoir besoin de lancer VB en root.

On crée le fichier vmdk avec la commande suivante : VBoxManage internalcommands createrawvmdk -filename image.vmdk -rawdisk /dev/loop0. Ceci va donner l’accès au disque complet.

Si on souhaite ne donner accès qu’à une partition, on peut utiliser l’option -partitions 2 (pour donner l’accès à la 2ème partition).
A noter que, selon ce Github, cet outil n’est capable de comprendre que les tables MBR. L’outil proposé par le github lui-même semble capable de lire le GPT aussi.

Une fois le fichier créé, il n’y a plus qu’à l’ajouter dans la configuration Stockage de la machine virtuelle.

Démontage

Une fois que l’on a fini, on peut démonter la partition de son point de montage (umount), puis démonter l’image du périphérique loop0 via la commande sudo losetup -d /dev/loop0.

[EDIT : avec l’option -P au montage, losetup supprimera les blocks partitions au démontage, l’étape suivant n’est donc pas nécessaire.]

Ceci ne supprime néanmoins pas le block /dev/loop0p1. Pour ceci : sudo delpart /dev/loop0 1.
C’est l’inverse de partprobe, cette commande dit au noyau d’oublier la partition 1 du périphérique loop0. A faire pour chaque partition.

08 Apr 2018, 00:00

Lancer server Xorg sans ecran connecté (Nvidia)

Sur une machine avec une GTX 1070, Xorg refusait de se lancer si un écran n’était pas physiquement connecté à la carte. Le fichier /etc/X11/xorg.conf suivant fait l’affaire (c’est probablement sur les sections Screen qu’on peut simuler la conection des écrans). L’option Coolbits sert à activer les possibilités d’overclocking.

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 375.26  (buildd@debian)  Fri Jan 13 02:38:29 UTC 2017

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0"
    Screen      1  "Screen1" RightOf "Screen0"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
    BusID          "PCI:1:0:0"
EndSection

Section "Device"
    Identifier     "Device1"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
    BusID          "PCI:2:0:0"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "True"
    Option         "UseDisplayDevice" "DFP-0"
    Option         "Coolbits" "28"
    Option         "ConnectedMonitor" "DFP-0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Device1"
    Monitor        "Monitor1"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "True"
    Option         "UseDisplayDevice" "DFP-0"
    Option         "Coolbits" "28"
    Option         "ConnectedMonitor" "DFP-0"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

06 Jan 2018, 00:00

Live-USB Hybrid Debian Stretch

Quelques petites variations par rapport à Jessie, notamment le fait que la construction d’une image avec double architecture semble échouer. il faut donc d’abord créer une image complète en architecture i386 (ainsi le système complet sera 32 bits, mais exploitable par un noyau 64 bits), puis créer une image 64 bits dont on extraiera le noyau et l’initrd.

sudo aptitude install live-build live-tools
mkdir stretch_live && cd stretch_live
mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/

Editer le fichier auto/config pour qu’il contienne ceci :

#!/bin/sh

set -e

lb config noauto \
	--architectures 'i386' \
	--archive-areas 'main contrib non-free' \
	--bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
	--binary-images 'iso-hybrid' \
	--distribution 'stretch' \
	--linux-flavours '686-pae' \
	--source 'false' \
	"${@}"

On peut rajouter le noyau des backports en rajoutant aussi ce qui suit :

	--backports 'true' \
	--linux-packages 'linux-image-4.18.0-0.bpo.1 \

Entrer la commande lb config, puis aller éditer le fichier config/package-lists/live.list.chroot et ajouter les paquets désirés. Je propose ceci :

live-boot
live-config
live-config-systemd
#FIRMWARE
firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-realtek broadcom-sta-dkms

#UTILS
nmap rcconf gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools lightdm bash-completion chntpw dcfldd bootlogd less mesa-utils numlockx ethtool grub2 ssh gdisk testdisk python-tk iftop nethogs pm-utils dmraid aptitude apt-file smartmontools debootstrap pciutils usbutils cifs-utils e2fsprogs mtools screen lvm2 net-tools mdadm lsscsi haveged rng-tools cryptsetup efibootmgr efivar ncdu wireless-tools

# DESKTOP
hplip system-config-printer xsane simple-scan mate-desktop-environment caja-open-terminal mesa-utils chromium-l10n pulseaudio pavucontrol pavumeter mate-media-common mate-media mate-settings-daemon-dev mate-settings-daemon-common mate-settings-daemon chromium engrampa unrar pluma bluez blueman pulseaudio-module-bluetooth gddrescue ddrescueview vlc rdesktop conky network-manager-gnome

Puis entrer la commande sudo lb build.

A noter qu’il est possible de décomposer la commande sudo lb build en la succession suivante :

sudo lb bootstrap
sudo lb chroot
sudo lb binary

Il est possible d’aller modifier/ajouter manuellement des fichiers entre l’étape chroot et l’étape binary. Par exemple, pour créer /home/user/ , /home/user/Bureau/ et y ajouter des fichiers, qui seront disponibles directement sur le bureau du live.

Si on souhaite recommencer la création du live, on peut utiliser la commande sudo lb clean qui ne conserve que le cache des paquets, du bootstrap et la config. On peut aussi utiliser les options --binary ou bien --chroot pour conserver les étapes antérieures.

18 Dec 2017, 00:00

Divers imprimantes

“Envoyé vers l’imprimante”

Sur un Windows Server 2012, les travaux restaient bloqués dans la file d’attente avec le statut “Envoyé vers l’imprimante”, bien qu’ils soient imprimés correctement. La solution qui semble bien marcher est de passer à un port type IP (au lieu d’un port WSD par exemple).

Outlook et les paramètres d’impression par défaut

Outlook 2016 a certains paramètres définis dans les “styles d’impression” (le style de base étant Mémo) qui outrepassent les réglages par défaut de l’imprimante (par exemple le choix du bac de sortie). Il faut les modifier directement dedans pour qu’il soient respectés.

18 Dec 2017, 00:00

Notes en vrac sur Azure AD Connect et Office 365

Mise en cohérence des domaines

Dans mon cas, l’AD avait été pis en place il y’a longtemps, le domaine local était du genre domain.oldcompany.com, mais les utilsateurs utilisaient aujourd’hui des adresses mail du genre user@newcompany.fr, et l’abonnement O365 avait pour domaine initial unusedcompany.onmicrosoft.com.

Dans ces conditions, la synchro de l’AD vers Azure donnait des identifiants du type nomprenom@unusedcompany.onmicrosoft.com, ce qui rend tout plus pénible, par exemple la connexion à OWA qui ne marche pas avec d’éventuels alias, mais qu’avec cet identifiant.

Comme le domaine initial ne peut être changé, il faut ajouter et vérifier le domaine newcompany.fr dans la gestion des domaines sur le portail O365, connecté en admin de l’abonnement. Pour le vérifier, il faudra aller mettre une preuve TXT dans la zone DNS.
Il faut ensuite ajouter un nouveau suffixe UPN au domaine (Outils d’administration -> Domaines et approbations Active Directory -> Propriétés -> Suffixes UPN), on ajoutera ici newcompany.fr car c’est l’adresse couramment utilisée par l’entreprise. Il faut ensuite modifier les suffixes UPN des utilisateurs dans les Utilisateurs et Ordinateurs AD, pour les passer de p.nom@domaine.oldcompany.fr à p.nom@newcompany.fr. Il est possible de le faire en PowerSehll, par exemple avec ce script

Ainsi, les utilisateurs auront un seul couple adresse/password pour se connecter à tout (Session sur le domaine, OWA, Portail O365 pour télécharger les logiciels etc).

Préparer l’AD local pour la synchro

Pour synchroniser un Active Directory local avec les services Azure Active Directory, il faut commencer par préparer l’AD local (notamment étendre le schéma AD sur un serveur Windows 2012). Cette page de Microsoft détaille beaucoup plus la précédure.

Il faut récupérer une installation d’Exchange 2013, par exemple sur cette page de chez Microsoft. On la décompresse, on lance cmd puis la commande suivante :
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Une fois que le schéma est préparé, on peut identifier les incohérences dans l’annuaire avant de synchroniser avec O365. Pour ça, on utilise l’outil IdFix (DL). Dans le cas où une offre dediée à O365 a été souscrite, il faut aller dans les paramétres et choisir “Dedicated” au lieu de “Multi-tenants”. On clique sur Query, on le laisse chercher, on vérifie puis acccepte les modifications, on fait Apply et on voit ce que ça donne. Si tout va bien, on peut passer à la synchro avec Azure. Si il y’a des problèmes (par exemple attributs non-existants), revérifier que l’AD a bien été préparé tel qu’indiqué sur le tuto de Microsoft.

Mise en oeuvre Azure AD Connect

Télécharger AAD Connect. La dernière version à prendre en charge Windows Server 2012 R2 est la 1.6.16.

Synchronisation du hachage de mot de passe.
Utilisé l’UPN (userPrincipalName) comme nom d’utilisateur AAD.

Powershell

Pour installer le module :
Import-Module ADSync
ou si ça ne fonctionne pas :
Import-Module -Name "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync" -Verbose

Une fois installé et configuré, il est possible de synchroniser manuellement avec la commande PowerShell :
start-adsyncsynccycle -policytype delta

PowerShell et Office 365

Envoi en tant que groupe :
Set-distributionGroup -Identity "group" -GrantSendOnBeHalfto "user@domain.com"