28 Jul 2018, 00:00

Divers - Office 365

Création d’une boite aux lettres partagées avec déploiement automatique

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).

Liste de distribution (alias)

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.

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…

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 -P /dev/loop0 ~/sdi.img.
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 user_name (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' \
	"${@}"

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-ralink firmware-realtek

#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 

# 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.