L’idée : capter une connection wifi ou 3G, et la partager à travers le port Ethernet de l’ordinteur, en créant un sous-réseau, avec DHCP. Le paquet isc-dhcp-server est nécessaire.

Paramétrer le fichier /etc/dhcp/dhcpd.confafin qu’il soit ainsi, en adaptant les valeurs à vos préférences :

# option definitions common to all supported networks...
option domain-name "nomdureseau";
option domain-name-servers 8.8.8.8, 8.8.4.4;

default-lease-time 3600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;


subnet 10.88.1.0 netmask 255.255.255.0 {
  range 10.88.1.5 10.88.1.199;
  option routers 10.88.1.1;
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  option broadcast-address 10.88.1.255;
}

Ce fichier sert à définir le réseau et la plage d’IP qui seront distribuées par le serveur DHCP.

Si on souhaite désactiver l’IPv6 afin de ne pas avoir de message d’erreur, on édite le fichier /etc/default/isc-dhcp-server et on ajoute le nom de l’interface filaire à la ligne “INTERFACESv4=”
Source

Créer ensuite le fichier /etc/network/interfaces.nat qui contiendra ceci :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.88.1.1
netmask 255.255.255.0
network 10.88.1.0
broadcast 10.88.1.255

Ce fichier sert à définir manuellement les paramètres réseaux de la carte qui servira le DHCP. Il doit être en cohérence avec le dhcpd.conf ci-dessus.

On copie le fichier interfaces actuel pour pouvoir le restaurer lorsqu’on quittera ce mode de partage :

sudo cp /etc/network/interfaces /etc/network/interfaces.pasnat

Puis on crée les scripts. Créer quelque part le fichier nat.sh qui contiendra ceci :

#!/bin/sh

# on coupe les services réseau
service network-manager stop
service networking stop

# on configure les interfaces et le forward
echo 1 > /proc/sys/net/ipv4/ip_forward
cp /etc/network/interfaces.nat /etc/network/interfaces

# on réinitialise et remet en route le réseau
ip addr flush eth0
ifconfig eth0 up
service networking start
service isc-dhcp-server start
service network-manager start

# on masquerade les paquets qui vont vers toutes les interfaces actuellement actives sauf eth0 et loopback
iptables -t nat -F
for interface in $(ip link show | grep UP | grep -v DOWN | grep -v eth0 | grep -v LOOPBACK | sed s/^[0-9]*:\ // | sed s/:.*$//);
do
  iptables -t nat -A POSTROUTING -o ${interface} -j MASQUERADE;	## On crée dans iptables la règle de NAT à proprement parler
done

# On prépare pour le prochain reboot
cp /etc/network/interfaces.pasnat /etc/network/interfaces

Puis le fichier pour retourner en connection standard, pasnat.sh :

#!/bin/sh

# On coupe le réseau
service network-manager stop
service networking stop
service isc-dhcp-server stop

# On désactive le forward ipv4, et reconfigure les interfaces normalement
echo 0 > /proc/sys/net/ipv4/ip_forward
cp /etc/network/interfaces.pasnat /etc/network/interfaces

# on réinitialise et remet en route le réseau
ip addr flush eth0
service networking start
service network-manager start

# on purge les tables iptables
iptables -t nat -F
iptables -F

On rend ces 2 fichiers exécutables

chmod +x /path/to/nat.sh
chmod +x /path/to/pasnat.sh

On peut désormais les lancer avec sudo

sudo /path/to/nat.sh

et les connections (wifi, USB, ppp etc) sera partagée à tous les clients branchés sur la carte filaire du l’ordi !

La résolution de noms Zeroconf en .local ou encore en .custom sous Linux se fait grâce au logiciel Avahi, sous la forme du paquet avahi-daemon. Sous windows, il est possible d’installer Bonjour (livré avec iTunes et extractible de l’installeur). Sous OSX, Bonjour est présent par défaut.

Pour résoudre les noms Netbios sous Debian, une méthode facile est d’installer le paquet libnss-winbind, puis de configurer le fichier /etc/nsswitch.conf de sorte à ce qu’il ressemble à ceci :

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

## Ligne originelle
#hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
hosts:		files dns wins mdns4_minimal
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

L’utilisation du protocle mdns4, qui correspond à Zeroconf, peut considérablement ralentir la recherche ping, notamment sur les recherches Netbios. On préférera utilser mdns4_minimal qui ne recherche que dans les adresses .local en ignorant n’importe quel .custom mais va beaucoup plus vite. L’ajout de la directive wins correspond à la recherche Netbios.

Normalement, ainsi le poste pourra pinger (donc niveau système, et accessible à toutes les applis) les hostname.local des ordis ayant une implémentation de Zeroconf en fonctionnement et les hostname de tous les postes Windows et les Linux ayant un samba en fonctionnement, et la navigation internet en général ne devrait pas du tout être ralentie.

Côté client

Le fichier qui contient tous les hôtes qu’un client ssh connaît est /home/$USER/.ssh/known_hosts. Si il y a un conflit de clés (clé d’un serveur renouvelée par exemple), on peut supprimer uniquement la ligne concernant le serveur en question, dont il faut connaitre le hostname : ssh-keygen -R HOSTNAME

Si on souhaite créer une clé d’authentification RSA (ou DSA), on peut le faire via la commande ssh-keygen -t rsa -b 4096 -C "Commentaire pour ditinguer la clé" (ou ssh-keygen -t dsa pour l’algo DSA, bien que ce soit aujourd’hui moins conseillé). Il est possible de créer une passphrase pour ces clés. Les fichiers créés le seront par défaut à l’emplacement ~/.ssh/id_rsa pour la clé privée et ~/.ssh/id_rsa.pub pour la clé publique. Ces clés peuvent servir pour se connecter sans mot de passe à un serveur ssh. Le commentaire se retrouve à la fin de la clé publique.

Le programme utilisé pour gérer la liste des clés utilisables pour l’authentification par clé est ssh-agent. La clé à l’emplacement par défaut est toujours référencée par ssh-agent. On peut gérer ce programme via la commande ssh-add. Par exemple ssh-add -L liste les clés référencées, ssh-add -D supprime toutes les clés référencées, ssh-add /path/to/id_rsa référence la clé en question et ssh-add -d /path/to/id_rsa supprime uniquement cette clé.

Pour que tous les terminaux partagent le même agent, il faut placer ceci dans son .bashrc (et peut-être le .profile) (source) :

	export SSH_AUTH_SOCK=~/.ssh/ssh-agent.$HOSTNAME.sock
	ssh-add -l 2>/dev/null >/dev/null
	if [ $? -ge 2 ]; then
	  ssh-agent -a "$SSH_AUTH_SOCK" >/dev/null
	fi

Côté serveur

Les clés publiques/privées du serveur sont créées à l’installation du serveur SSH. Elles se trouvent par défaut à /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_dsa_key.pub, /etc/ssh/ssh_host_rsa_key et /etc/ssh/ssh_host_rsa_key.pub.

Pour accepter les connections par clé RSA, le serveur doit avoir les directives RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys dans le fichier de configuration du serveur /etc/ssh/sshd_config.

Comme l’indique la 3ème directive ci-dessus, les clés (publiques) acceptées pour chaque user sur le serveur doivent se trouver dans le fichier /home/$USER/.ssh/authorized_keys. Ce paramètre peut-être modifié en décommentant cette ligne et en mettant un emplacement différent.
Une des manières de l’ajouter, depuis le poste client, est de rentrer la commande ssh-copy-id -i /path/to/id_rsa -p port user@serveur. La paramètre -i est facultatif, en son absence ce sera l’emplacement par défaut qui sera utilisé.
On peut également le copier à la main sur le serveur, en copiant la clé publique correspondante à l’emplacement indiqué dans le fichier de conf.

Le but de la manipulation est de pouvoir, aisément, booter un système Linux Debian aussi bien en mode UEFI que MBR, sans avoir à faire de reconfiguration particulière en passant de l’un à l’autre, avec un disque dur partitionné en GPT. Ceci me permet de pouvoir, à la volée, grâce au menu de démarrage (sur un HP DM1-4332sf), booter mon OS linux en mode BIOS, permettant un meilleur support du matériel (la mise en veille ne fonctionnant actuellement pas en mode EFI), tout en conservant les systèmes Windows 7, Windows 8 et mon système Debian bootables en mode EFI.

N’ayant actuellement pas réussi à faire cohabiter grub-pc et grub-efi sur une même installation, le démarrage par efi se fera via GRUB et le démarrage par MBR se fera via EXTLINUX.

Cette démarche fonctionne aussi en cas de multiboot, mais ce multiboot ne sera possible qu’en mode EFI (via GRUB pour EFI). Le système Syslinux ne sera capable de démarrer que la Debian. Cet article ne parlera toutefois pas du tout de la configuration du dual-boot en EFI, celui-ci étant de toute façon totalement indépendant de la coexistence avec un Syslinux pour BIOS.

Le disque /dev/sda est supposé partitionné comme ceci :

/dev/sda1 : FAT32, EFI System Partition (label EFI)
/dev/sda2 : NTFS Partition (label WIN_7)
/dev/sda3 : Ext4 partition (label SLASH)
/dev/sda4 : Ext4 partition (label HOME)
/dev/sda5 : swap partiton
/dev/sda6 : NTFS partition (label DATA)

Il faut ensuite rajouter le flag legacy_boot à la partition SLASH (/dev/sda3 ici). Ceci peut se faire via GParted. Dans le cas d’une partiton /boot séparée, il faut probablement positionner ce flag sur la partition /boot .

Le système est présupposé fonctionnel en mode EFI, via GRUB (soit par une installation directement en mode EFI, soit en rendant le système bootable en EFI après une installation classique, comme détaillé ici). Comme les labels l’indiquent, /dev/sda3 est monté sur / , /dev/sda4 est monté sur /home/ . Le setup ne contient PAS de partiton /boot/ séparée. La partition EFI System Partition est montée sur /boot/efi/.

Il faut d’abord installer le paquet extlinux. sudo aptitude install extlinux syslinux-common Il crée automatiquement un répertoire /boot/extlinux/ avec la configuration nécessaire. Il install également extlinux sur le MBR du disque (commande extlinux-install), or celui-ci ne convient pas à l’installation actuelle, car il est conçu pour les partitons natives en MBR. On écrase donc ce mbr avec le extlinux prévu pour les partitions GPT :

dd if=/usr/lib/syslinux/gptmbr.bin of=/dev/sda

Et voilà ! Si on choisit de démarrer l’ordinateur en mode BIOS, sur le disque dur, on aura la liste de nos noyaux bootables via Extlinux. D’après mes tests, l’ajout et la suppression de noyaux peuvent être faits à partir du mode BIOS ou EFI, GRUB et Extlinux auront tous les 2 leur configuration mise à jour.

On va créer un utilisateur dedié, qui installera et lancera l’instance de freenet. Il n’est pas nécessaire et donc pas recommandé de lancer l’instance en root.

Installation :

    sudo adduser --system --group freenet
    cd ~freenet
    sudo su -s "$SHELL" freenet
    wget https://downloads.freenetproject.org/alpha/installer/new_installer_offline.jar
    java -jar new_installer_offline.jar -console

Selectionner un répertoire, par exemple /home/freenet/freenet_bin pour l’installation. Le client est lancé automatiquement suite à l’installation. Pour couper/lancer le serveur ou savoir s’il tourne, les commandes, en tant qu’utilisateur freenet, sont /home/freenet/freenet_bin/run.sh stop, /home/freenet/freenet_bin/run.sh start et /home/freenet/freenet_bin/run.sh status.

On peut ensuite accéder au panneau de contrôle via l’url, dans son navigateur favori : http://localhost:8888

Généralités

Legacy Mode = Compatibility Support Module (CSM) = BIOS Mode . Utilisé pour qu’un système UEFI se comporte comme un BIOS traditionnel.

Pour savoir si l’on a bien booté en mode efi : Sous Linux : dmesg | grep -i EFI ne renverra presque rien si l’on est en mode BIOS, mais plein d’infos (gestion mémoire etc) si on est en mode efi.
Sous Windows, il suffit de se repérer à la table de partition du disque système : il ne peut booter en mode BIOS que sur disque MBR, et en mode EFI que sur disque GPT.

À une certaine époque, fdisk ne gèrait pas les disques GPT. Aujourd’hui oui. gdisk les gère aussi, et permet un certain nombre d’actions dessus.

Les tables de partition GPT sont dupliquées ; en début ET en fin de disque. Pour cette raison, dumper un disque vers un disque plus grand ne fonctionne plus, car la table de secours ne sera pas correctement placée. Il faut copier la table de partition (sudo sgdisk /dev/sdX -R /dev/sdY pour copier la table de sdX vers sdY), puis dumper chacune des partitions une à une.

Une table de partition GPT contient une zone réservée habituellement au MBR, avec plusieurs états possibles : cette zone MBR peut-être en protective (non utilisée, montre une seule grosse fausse partition de max 2To), en hybrid (une pseudo-table MBR devant concorder avec la table gpt sur 4 partitions) ou en MBR-only (c’est nativement un disque MBR). Le rôle de cette zone est d’éviter la modification/création d’une table MBR par des outils ne connaissant pas le GPT.
gdisk peut (ré)écrire une table hybrid-MBR pour qu’elle concorde avec l’état actuel de la table GPT. L’utilisation d’un hybrid-MBR est toutefois un hack étant aujourd’hui plutôt déconseillé.

On peut voir l’état de ce mbr avec l’outil gdisk :
sudo gdisk -l /dev/sdX

gparted gère sans problème les disques GPT, sauf dans le cas d’un disque en Hybrid-MBR. Les modifications seraient dans ce cas faites uniquement sur la pseudo-table mbr, sans tenir compte de la gpt, et donc de l’agencement réel des partitions, ce qui risque très probablement de casser toute la table. (edit : probablement plus vrai aujourd’hui)

Lors de la création d’une table de partition, va être créé un “Disk identifier” (sous forme d’UUID pour du GPT, et de 8 caractères hexadécimaux pour du MBR). Cet identifiant est purement logiciel.

Flags, types de partition

Une table de partition GPT associe à chaque partition un type, qui permet de donner une indication sur le rôle de la partition. Ce type est un UUID, qui se traduit en une appellation (qui peut être différente selon les programmes). Un fdisk -l affiche le type de chaque partition existante. On peut voir la liste complète des types de partition avec fdisk /dev/sdX puis l.

On peut également voir/modifier facilement les types de partition avec cfdisk .

La partition sera accessible, même si le type ne concorde pas avec le formatage. Toutefois, certains types peuvent ne pas apparaître dans l’explorateur, et nécessiter un montage à la main (par exemple esp).

Sous GParted, un certain nombre de ces types de partition sont représentés par des drapeaux (flags). Par exemple,

• absence de drapeau = Linux Filesystem (ou Inconu sous diskpart) = UUID 0fc…de4
• drapeau “esp” (également “boot”) = type EFI System Partition (ou Système sous diskpart) = c12…93b
• swap = Linux Swap = 065…f4f
• bios_grub = BIOS boot
• diag = Windows recovery environment
• msftdata = Microsoft Basic Data (ou Principale sous diskpart) = ebd…9c7
• msftres = Microsoft reserved (ou Réservé sous diskpart) = e3c…5ae

Lors du formatage vers certains systèmes de fichiers (par exemple ext4 ou ntfs), GParted assigne automatiquement le type “évident” à la partition (par exemple “Linux filesystem” ou “Microsoft basic data”). Un formatage en FAT32 ne semble pas modifier le type déjà existant.

Certains drapeaux sont toutefois indépendants du type ; par exemple “hidden” et “legacy_boot”.
Il y’a une explication de nombreux drapeaux ici.

Types en table MRB

Les partitions ont également un type dans les partitions MBR. L’identifiant est sur 2 octets et Par exemple

Démarrage

L’UEFI ne peut démarrer un périphérique (disque dur, clé usb etc) qu’à partir d’une partition en fat32 (en réalité, certaines cartes-mères sont capables de lire le NTFS aussi). Généralement, elle est nommée “EFI System Partition” (ESP) et elle a le flag “boot” dans GParted (et le flag “esp” si la table de partition est GPT).

Le chemin par défaut où l’UEFI va chercher un bootloader (exécutable EFI) est ${ESP}/boot/BOOT${ARCH}.efi , typiquement /efi/boot/BOOTX64.efi. Si l’exécutable est ailleurs, on peut aller le chercher à la main lors du choix de boot (bien que ceci dépende de l’implémentation sur la carte-mère).

L’UEFI supporte aussi l’enregistrement d’entrées de démarrage au sein-même de l’UEFI. Ceci permet d’avoir plusieurs bootloaders en parallèle, avec un chemin et un nom associés. Par exemple ${ESP}/Microsoft\bootmgrfw.efi (Windows Boot Manager) et ${ESP}/debian/grubx64.efi (debian). Ces entrées peuvent se visualiser et se gérer sous Linux avec la commande efibootmgr. Si définies, elles sont prioritaires sur le chemin par défaut.
Ces entrées comportent le chemin absolu de l’exécutable, avec l’UUID de la partition (PARTUUID dans blkid) le contenant. Par conséquent, une fois enregistrée dans l’UEFI, il est possible de démarrer depuis une partition n’ayant PAS le flag boot/esp. Cette partition doit toutefois être en FAT32.

Les CD et DVD sont bootables en UEFI via le format ElTorito, comme les BIOS auparavant.

Les disques au format MBR sont bootables aussi sans problème par un système UEFI, tant que la partition à booter est en fat32. La limitation de Windows qui ne peut booter en UEFI que sur GPT vient de Windows et non de la norme UEFI.
(note : Windows n’accepte de s’installer que sur une table de partition correspondant à son type de démarrage, mais il est possible de le faire démarrer sur une table non-prévue en installant les fichiers à la main).

À l’inverse, les disques GPT peuvent être démarrés sur un système BIOS. Si GRUB est utilisé, il a besoin d’une partition dédiée (1Mo, non formatée) avec le flag “bios_grub”. Ceci lui permet de stocker les infos qui sont habituellement stockées dans un espace libre de la MBR (qui est ici utilisé par la table de partition GPT elle-même). Sans quoi la commande grub-install /dev/sdX renverra une erreur de “listes de blocs”. Une fois utilisée, cette partition apparaîtra avec le système de fichiers “grub2 core.img”.
Dans ce cas, la partition ESP ainsi que les flags “boot” et “esp” ne sont pas nécessaires. Ils peuvent toutefois être positionnés, pour faciliter une migration future vers un système EFI. Ceci nécessitera toutefois le remplacement du paquet grub-pc par le paquet grub-efi.

La plupart des UEFI sont de nature 64 bits, mais certains (souvent des PCs assez bas-de-gamme) ont un EFI uniquement en 32 bits. Ceci n’empêche pas le chargement d’un système en 64 bits, mais l’exécutable EFI (grub-efi, syslinux-efi etc) doit être en 32 bits.

Bien que déconseillé, il est possible d’avoir 2 (ou + ?) partitions ESP en même temps sur un disque interne. On peut aussi positionner/enlever les flags boot pour alterner entre 2 ESP.

efibootmgr

Pour lister les entrées, lancer simplement efibootmgr. On peut avoir plus de détails avec efibootmgr -v.

Pour supprimer l’entrée “BootABCD”, on entre
sudo efibootmgr -b ABCD -B

Utilitaires

Le comportement de certains programmes est le suivant :

grub-update : os-prober ne référencera que les exécutables UEFI situés sur la (les ?) partitions ESP (comportant le flag boot)

grub : peut booter sur une partition qui n’est PAS la partition ESP ; peut aussi lancer des OS/noyaux qui sont sur une partition non-ESP

Install Windows : si pas de partition flaggée ESP lors de l’install, il va en créer une dans le premier espace libre sur le disque ; si pas d’espace libre, message “Nous n’avons pas pu créer de partition…” et l’install ne pourra pas continuer.
Si la partition ESP est en NTFS, l’installation échouera en demandant de la formater en FAT32 (toutefois certaines cartes-mères sont capables de démarrer depuis une partition NTFS si on recrée les fichiers manuellement).

Windows : si absent de la liste de démarrage UEFI et que la partition contenant son bootloader est flaggée ESP, alors il s’enregistre dans l’UEFI lors du démarrage et se place en priorité

bcdboot : crée les fichiers de démarrage sur la partition ESP, sauf si le flag /s X: est spécifié, X: étant la lettre assignée à la partition où l’on souhaite créer ces fichiers

veracrypt : lors du chiffrement de la partition système (et du pre-test qui va avec), les fichiers EFI de veracrypt sont écrits sur la partition flaggée ESP
Lors du déchiffrement, les fichiers sont aussi écrits sur la partition flaggée ESP

Ordre des partitions

Si on aime avoir le numéro des partitions qui correspond à leur ordre sur le disque, on peut utiliser la commande
sudo sgdisk -s /dev/sdX

Ou aussi la commande gdisk :

sudo gdisk /dev/sdX
s
p
w
Y

Lister les utilisateurs : Si les mots de passe sont stcokés de manière sécurisée (directive passdb backend = tdbsam dans le fichier /etc/samba/smb.conf)
sudo pdbedit -L
Sinon
cat /etc/samba/smbusers

Tous les utilisateurs samba doivent correspondre à un utilisateur Unix sur le système.
Pour créer un mot de passe à un utilisateur (ou le modifier), et qu’il puisse donc être utilisé comme identifiant pour une connexion via partage réseau :
sudo smbpasswd -a username
Pour le supprimer de la base d’utilisateurs samba :
sudo smbpasswd -x username

Pour définir si un utilisateur a le droit d’accéder à un partage, il existe, dans les paramètres du partage, la directive
valid user = username1 username2 @groupname1
Les droits des utilisateurs sont ensuite définis par 2 paramètres, read only = et write list = . Si on a
read only = no
alors tout le monde (parmi les valid users) aura accès en lecture/écriture. Si on a

	read only = yes
	write list = username1 @groupname1

alors seul l’utilisateur username1 et les utilisateurs du groupe groupname1 auront droit à l’écriture.

Cela peut donner, par exemple :

	[Reception]
	   comment = reception
	   browseable = yes
	   path = /path/to/reception
	   guest ok = yes
	   read only = no

	[private]
	   comment = User private folder
	   browseable = no # it only made it disappear from broadcasted shares, but doesn't affect the real browseability
	   path = /home/user/
	   guest ok = no
	   valid users = gaetan
	   read only = yes
	   write list = gaetan

Ces règles ne sont pas valides pour le mode de sécurité security = share.

Cette boite de dialogue, sous 7 et 8, n’est accessible par clic que via la barre d’actions en haut de l’Explorer, lorsqu’une imprimante est sélectionnée. Si on n’a pas d’imprimante, on ne peut pas.

Il suffit donc de lancer la commande printui /s Le commutateur /s sert à lancer l’interface graphique. Sans lui, on gère tout en ligne de commande.

Parfois, bien que l’on éxécute un programme en tant qu’administrateur de l’ordinateur, on peut se retrouver avec certaines restrictions. Par exemple si l’on veut modifier les lés du registre à HKLM\System\CurrentControlSet\Enum . Pour contourner ceci, on peut lancer l’utilisatire PsExec de Sysinternals, avec les options -i qui permet que le programme soit lancé interactivement sur le bureau de l’utilisateur, et -s qui demande à utiliser le compte system.

Par exemple,

C:\Users\moi\path\vers\psexec.exe -i -s regedit

permettra de modifier le registre à notre guise. À noter qu’il faut lancer la commande dans un shell cmd lancé avec les droits administrateur.

Cette info a été trouvée grâce à ces posts, bien utiles malgré un langage aussi fleuri qu’une sépulture d’ancien combattant un 8 mai.

Il peut arriver qu’une imprimante ne soit pas supprimable dans le gestionnaire d’imprimantes. Plus d’infos ici : Problème d’installation d’imprimantes dans Windows 7

Imprimante locale

Dans le cas d’une imprimante locale, il s’agit le plus souvent d’une file d’attente qui ne veut pas se vider. Or il est impossible de supprimer une imprimante dont la file d’attente n’est pas vide. Pour forcer le vidage de la file d’attente :

• couper le service spouleur d’impression, soit par l’interface graphique (services.msc), soit avec la commande net stop spooler
• supprimer tous les éléments du dossier C:\Windows\System32\spool\PRINTERS\
• relancer le service Spouleur d’impression (net start spooler)

Les files d’attente doivent être vides, et les imprimantes peuvent être supprimées.

Imprimante réseau

Dans le cas d’une imprimante réseau, ce peut être un peu plus compliqué. Il arrive qu’une imprimante réseau, même avec une file d’attente vide, ne puisse être supprimée. Ceci est particulièrement vrai lors d’une imprimante déployée automatiquement par une GPO (mal) appliquée à un domaine.

Sous 7

Sous 7, il suffit généralement d’aller dans la base de registre, d’aller à la clé HKCU\Printers\Connections et de supprimer la clé correspondant à l’imprimante récalcitrante. Un coup de redémarrage de Spouleur d’impression (voir ci-dessus) et c’est réglé, elle n’apparaît plus.

Sous 8

Sous Windows 8, bien que cette clé existe aussi, ce n’est pas elle qui contrôle l’existence des imprimantes. Il faut aller éditer la base de registre en tant qu’utilisateur System (voir ce post), et aller à la clé HKLM\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM\, trouver la ou les clés des imprimantes à supprimer (via la valeur FriendlyName), et les supprimer. Si les connexions automatiques via GPO aux imprimantes partagées sont à refaire au propre, il faut redémarrer l’ordinateur, puis réappliquer la commande gpupdate /force.

Normalement, cela devrait suffire. Si l’on souhaire effacer toutes les traces de l’imprimantes dans le registre, voilà les différents emplacements mentionnant une imprimante partagée dans le registre. Notez que je mentionne HKCU pour l’utilisateur concerné, mais que si regedit est lancé via psexec, il faudra aller chercher dans HKU\SID.

• HKCU\Printers\Connections

• HKCU\Software\Microsoft\Windows NT\CurrentVersion\Devices\

• HKCU\Software\Microsoft\Windows NT\CurrentVersion\PrinterPorts\

• HKCU\Software\Policies\Microsoft\Windows NT\Printers\PushedPrinterConnectionStore\{XXXXX-XXX-XXX....XXXX}\

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\SID\Printers\Connections\

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers\SERVEUR-D-IMPRESSION-DU-DOMAINE\

• HKLM\SYSTEM\CurrentControlSet\Enum\SWD\PRINTENUM\

Penser à redémarrer la machine après ces manips, et éventuellement à réappliquer la commande gpupdate /force.