Opsi (Open PC Server Integration) est un outil de gestion de clients Windows basé sur un serveur Linux et sous licence AGPLv3 (hors code des modules cofinancés), version modifiée et orientée serveurs de la licence GPLv3. Son code source est la propriété de la société uib gmgh et son représentant en France/Belgique est la société Opensides.
Ses fonctionnalités principales sont :
- Installation automatisée via PXE de systèmes d’exploitation clients Windows par le biais d’une image
- Distribution automatique des logiciels via une connexion agent/serveur
- Intégration automatique des drivers en se basant sur l’ID de ceux-ci
- Inventaires matériels et logiciels
- Dépôts logiciels multiples et décentralisés
Objectif
L’objectif de cet article est l’installation et la configuration d’un serveur de déploiement Opsi en version 4.0.6, sur une distribution Linux Debian Jessie 8.7 32bits
Schéma logique

Pré-requis
Le seul pré-requis ici est d’avoir suivi la première partie relative à l’installation d’un serveur Opsi : Opsi – Installation du serveur Part1
4. Paramétrage du serveur Opsi
4.1. Désactivation du service Winbind au démarrage du système
Winbind permet à un utilisateur (ou groupe d’utilisateurs) de s’identifier sur un système UNIX/Linux avec des identifiants de domaine Windows.
Pour cela, un UID (ou GID) est mappé avec le RID (portion d’un SID) correspondant de l’annuaire d’un contrôleur de domaine Windows.
La configuration du service Samba de Opsi ne requiert pas Winbind et peu présenter des dysfonctionnements si activé sur Debian Jessie, nous pouvons donc désactiver ce dernier.
# systemctl disable winbind
Synchronizing state for winbind.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d winbind defaults
Executing /usr/sbin/update-rc.d winbind disable
insserv: warning: current start runlevel(s) (empty) of script `winbind' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `winbind' overrides LSB defaults (0 1 6).
ou
# insserv -r winbind
4.2. Modification du fichier /etc/samba/smb.conf
Par sécurité, même si Winbind a été désactivé ci-dessus, on peut spécifier l’intervalle de mapping des UID/GID (avec les SID/RID) utilisés par Winbind entre 1000 et 1999999, sachant que les valeurs inférieures à 1000 sont réservées aux comptes système.
[global]
workgroup = WORKGROUP
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
server role = standalone server
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
idmap config * : range = 1000-1999999
Ci-dessus, ajouter la ligne idmap config * : backend = tdb serait redondant car c’est une option implicite par défaut.
Elle signifie que le fichier d’associations requis par Winbind utilise le fichier /var/lib/samba/winbindd_cache.tdb.
{
key(10) = "SN/S-1-5-2"
data(41) = "\00\00\00\00t\19\8FX\A0\1A\8FX\00\00\00\00\05\00\00\00\0CNT Authority\07Network"
}
{
key(15) = "SN/S-1-5-32-546"
data(35) = "\00\00\00\00t\19\8FX\A0\1A\8FX\00\00\00\00\04\00\00\00\07BUILTIN\06Guests"
}
{
key(47) = "SN/S-1-5-21-4273826650-3176465359-281838201-514"
data(16) = "s\00\00\C0t\19\8FX\A0\1A\8FX\00\00\00\00"
}
{
key(15) = "SEQNUM/BUILTIN\00"
data(8) = "t\19\8FXt\19\8FX"
}
{
key(24) = "TRUSTDOMCACHE/WORKGROUP\00"
data(98) = "\02\00\00\00BUILTIN\00\00S-1-5-32\00\00\00\00\00\00\00\00\00\00\00\00\00OPSI-TEST\00\00S-1-5-21-4273826650-3176465359-281838201\00\00\00\00\00\00\00\00\00\00\00\00\00"
}
{
key(10) = "SN/S-1-1-0"
data(30) = "\00\00\00\00t\19\8FX\A0\1A\8FX\00\00\00\00\05\00\00\00\00\08Everyone"
}
{
key(17) = "SEQNUM/OPSI-TEST\00"
data(8) = "t\19\8FXt\19\8FX"
}
La commande testparm vérifie la syntaxe du fichier de configuration Samba /etc/samba/smb.conf si aucun paramètre ne lui est passé :
# testparm Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[print$]" Processing section "[opsi_depot]" Processing section "[opsi_depot_rw]" Processing section "[opsi_images]" Processing section "[opsi_workbench]" Processing section "[opsi_repository]" Loaded services file OK. WARNING: You have some share names that are longer than 12 characters. These may not be accessible to some older clients. (Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.) Server role: ROLE_STANDALONE # /etc/init.d/samba restart [ ok ] Restarting nmbd (via systemctl): nmbd.service. [ ok ] Restarting smbd (via systemctl): smbd.service. [ ok ] Restarting samba-ad-dc (via systemctl): samba-ad-dc.service.
4.3. Création de l’administrateur adminuser et affectation des groupes
L’administrateur adminuser est créé comme compte local, puis compte Samba, puis affecté aux groupes secondaires opsiadmin et pcpatch.
# useradd -m -s /bin/bash adminuser # passwd adminuser Entrez le nouveau mot de passe UNIX : Retapez le nouveau mot de passe UNIX : passwd : le mot de passe a été mis à jour avec succès # smbpasswd -a adminuser New SMB password: Retype new SMB password: Added user adminuser. # usermod adminuser -aG opsiadmin # usermod adminuser -aG pcpatch # groups adminuser adminuser : adminuser pcpatch opsiadmin # members -t opsiadmin opsiconfd adminuser # members -t pcpatch pcpatch opsiconfd adminuser
On peut rattacher root aux groupes opsiadmin et pcpatch, sinon il ne lui sera pas possible d’utiliser certaines commandes (comme opsi-package-manager -x) :
# usermod root -aG opsiadmin # usermod root -aG pcpatch # members -t opsiadmin opsiconfd adminuser root # members -t pcpatch pcpatch opsiconfd adminuser root
4.4. Configuration du service DHCP
Le serveur Opsi utilisant un serveur DHCP externe, le backend dhcpd n’est donc pas requis et le fichier /etc/opsi/backendManager/dispatch.conf doit ressembler à cela :
backend_.* : file, opsipxeconfd host_.* : file, opsipxeconfd
Ensuite nous devons modifier les configurations des serveurs DHCP externes (master et slave) pour informer les clients bootant en PXE que le serveur de boot est le serveur Opsi. Les deux serveurs DHCP doivent donc présenter les lignes suivantes en fin de fichier :
next-server 192.168.1.13; filename "linux/pxelinux.0";
4.4.1. Modification du fichier /etc/dhcp/dhcpd.conf sur le serveur DHCP master
include "/etc/bind/tsig.key";
authoritative;
ddns-update-style standard;
update-static-leases off;
ignore client-updates;
default-lease-time 1800;
max-lease-time 1800;
log-facility local7;
db-time-format local;
failover peer "opensharing-failover" {
primary;
address 192.168.1.11;
port 647;
peer address 192.168.1.12;
peer port 647;
max-response-delay 30;
max-unacked-updates 3;
load balance max seconds 3;
mclt 480;
split 128;
}
subnet 192.168.1.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
ddns-domainname "opensharing.priv";
ddns-rev-domainname "in-addr.arpa";
option domain-name "opensharing.priv";
option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
set vendor-string = option vendor-class-identifier;
pool {
failover peer "opensharing-failover";
range 192.168.1.100 192.168.1.199;
allow unknown-clients;
}
}
zone opensharing.priv {
primary 192.168.1.11;
key "tsig-key";
}
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.11;
key "tsig-key";
}
next-server 192.168.1.13;
filename "linux/pxelinux.0";
4.4.2. Modification du fichier /etc/dhcp/dhcpd.conf sur le serveur DHCP slave
include "/etc/bind/tsig.key";
authoritative;
ddns-update-style standard;
update-static-leases off;
ignore client-updates;
default-lease-time 1800;
max-lease-time 1800;
log-facility local7;
db-time-format local;
failover peer "opensharing-failover" {
secondary;
address 192.168.1.12;
port 647;
peer address 192.168.1.11;
peer port 647;
max-response-delay 30;
max-unacked-updates 3;
load balance max seconds 3;
}
subnet 192.168.1.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
ddns-domainname "opensharing.priv";
ddns-rev-domainname "in-addr.arpa";
option domain-name "opensharing.priv";
option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
set vendor-string = option vendor-class-identifier;
pool {
failover peer "opensharing-failover";
range 192.168.1.100 192.168.1.199;
allow unknown-clients;
}
}
zone opensharing.priv {
primary 192.168.1.11;
key "tsig-key";
}
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.11;
key "tsig-key";
}
next-server 192.168.1.13;
filename "linux/pxelinux.0";
4.5. Résolution de noms par le serveur Opsi
Le serveur Opsi doit pouvoir connaitre l’IP de chaque hôte afin de pouvoir communiquer avec ce dernier (envoi de messages, déploiement de paquets à la demande, requêtes d’informations de session, etc.).
Pour cela, parmi plusieurs possibilités, deux scénarios majeurs sont possibles :
- Scénario 1 : Le service DNS ne connait pas l’IP de l’hôte et ce dernier se voit affecter des IP variables par le service DHCP
- Scénario 2 : Le service DNS fournit en permanence l’IP à jour de l’hôte
Nous retiendrons ici le scénario numéro 2 car chaque hôte client se verra affecter une réservation sur les serveurs DHCP master et slave et les enregistrements DNS correspondants seront ajoutés manuellement, via nsupdate. Ainsi, les adresses IP des clients seront résolues par le serveur DNS et toujours connues, la base de données locale du serveur Opsi ne sera donc utilisée qu’en cas de dysfonctionnement du service DNS et pour afficher les adresses IP des hôtes sur l’interface Opsi Configed.
4.5.1. Scénario 1
Modifier le fichier /etc/opsi/backends/hostcontrol.conf :
"resolveHostAddress": False
Si l’option est à False, alors le serveur Opsi tente d’obtenir l’adresse IP du client par sa base de données locale et, le cas échéant, par le serveur DNS.
L’option est à False par défaut.
# -*- coding: utf-8 -*-
module = 'HostControl'
config = {
"opsiclientdPort": 4441,
"hostRpcTimeout": 15,
"resolveHostAddress": False,
"maxConnections": 50,
"broadcastAddresses": ["255.255.255.255"]
}
Modifier le fichier /etc/opsi/opsiconfd.conf :
update ip = yes
Si l’option est à yes, alors le serveur Opsi mettra à jour sa base de données locale dès qu’un client se verra affecter une adresse IP.
L’option est à no par défaut.
[global]
backend config dir = /etc/opsi/backends
dispatch config file = /etc/opsi/backendManager/dispatch.conf
extension config dir = /etc/opsi/backendManager/extend.d
acl file = /etc/opsi/backendManager/acl.conf
admin networks = 0.0.0.0/0
message bus = no
multiprocessing = no
pid file = /var/run/opsiconfd/opsiconfd.pid
log file = /var/log/opsi/opsiconfd/%m.log
symlink logs = yes
log level = 5
log format = [%l] [%D] %M (%F|%N)
max log size = 5MB
max execution statistics = 250
monitoring user = monitoring
monitoring debug = false
[service]
interface = 0.0.0.0
http port = 0
https port = 4447
ssl server cert = /etc/opsi/opsiconfd.pem
ssl server key = /etc/opsi/opsiconfd.pem
[session]
session name = OPSISID
verify ip = no
update ip = yes
max inactive interval = 120
max authentication failures = 5
max sessions per ip = 25
[directories]
/ = /usr/share/opsiconfd/static (noauth)
configed = /usr/lib/configed (noauth)
4.5.2. Scénario 2 (solution retenue ici)
Modifier le fichier /etc/opsi/backends/hostcontrol.conf :
"resolveHostAddress": True
Si l’option est à True, alors le serveur Opsi tente d’obtenir l’adresse IP du client par le serveur DNS et, le cas échéant, par sa base de donnée locale.
L’option est à False par défaut.
# -*- coding: utf-8 -*-
module = 'HostControl'
config = {
"opsiclientdPort": 4441,
"hostRpcTimeout": 15,
"resolveHostAddress": True,
"maxConnections": 50,
"broadcastAddresses": ["255.255.255.255"]
}
Modifier le fichier /etc/opsi/opsiconfd.conf :
update ip = yes
Si l’option est à yes, alors le serveur Opsi mettra à jour sa base de données locale dès qu’un client se verra affecter une adresse IP.
L’option est à no par défaut.
[global]
backend config dir = /etc/opsi/backends
dispatch config file = /etc/opsi/backendManager/dispatch.conf
extension config dir = /etc/opsi/backendManager/extend.d
acl file = /etc/opsi/backendManager/acl.conf
admin networks = 0.0.0.0/0
message bus = no
multiprocessing = no
pid file = /var/run/opsiconfd/opsiconfd.pid
log file = /var/log/opsi/opsiconfd/%m.log
symlink logs = yes
log level = 5
log format = [%l] [%D] %M (%F|%N)
max log size = 5MB
max execution statistics = 250
monitoring user = monitoring
monitoring debug = false
[service]
interface = 0.0.0.0
http port = 0
https port = 4447
ssl server cert = /etc/opsi/opsiconfd.pem
ssl server key = /etc/opsi/opsiconfd.pem
[session]
session name = OPSISID
verify ip = no
update ip = yes
max inactive interval = 120
max authentication failures = 5
max sessions per ip = 25
[directories]
/ = /usr/share/opsiconfd/static (noauth)
configed = /usr/lib/configed (noauth)
4.6. Installation des produits de base depuis le dépôt uib
L’ensemble des produits disponibles sur les dépôts de uib sont disponibles à l’adresse suivante :
http://download.uib.de/opsi4.0/products/
Où l’on retrouve notamment les produits des sections :
Par défaut la section relative aux produits opsi-linux, dans le dépôt uib_linux, est active, mais nous ne souhaitons par récupérer ces produits car ils viendraient utiliser de l’espace de stockage inutilement et nous n’aurons pas de clients Linux. Pour ces raisons, nous pouvons désactiver de dépôt en modifiant la ligne suivante du fichier /etc/opsi/opsi-product-updater.conf :
[repository_uib_linux]
active = false
baseUrl = http://download.uib.de
dirs = opsi4.0/products/opsi-linux
autoInstall = false
autoUpdate = true
autoSetup = false
; Set Proxy handler like: http://10.10.10.1:8080
proxy =
Par défaut, l’option active est à true, nous la passons donc à false.
Les seules sections restant actives sont maintenant uniquement netboot et localboot dans le dépôt uib :
[repository_uib]
active = true
opsiDepotId =
baseUrl = http://download.uib.de
dirs = opsi4.0/products/localboot, opsi4.0/products/netboot
includeProductIds =
username =
password =
autoInstall = false
autoUpdate = true
autoSetup = false
onlyDownload = false
proxy =
La commande suivante installera tous les produits que ces deux sections du dépôt uib contiennent :
# opsi-product-updater -i -vv
Au moment de la rédaction de cet article, les produits suivants sont installés :
Localboot | Netboot |
activate-win | hwinvent |
config-win-base | memtest86 |
config-win10 | opsi-clonezilla |
config-win81-desktop | win7-captured’ |
hwaudit | win7-enterprise-msdn |
javavm | win7-x64-captured’ |
jedit | win7-x64-enterprise-msdn |
networklocation | win7-x64 |
opsi-client-agent | win7 |
opsi-configed | win10-captured |
opsi-logviewer | win10-x64-captured |
opsi-set-win-uac | win10-x64 |
opsi-setup-detector | win10 |
opsi-template-with-admin | win81-captured |
opsi-template | win81-x64-captured |
opsi-uefi-netboot | win81-x64 |
opsi-wan-config-off | win81 |
opsi-wan-config-on | win2008-r2 |
opsi-wim-capture | win2012-r2 |
opsi-wim-info | win2012 |
opsi-winst-test | win2016 |
shutdownwanted | wipedisk |
swaudit | |
windomain |
Pour chaque produit, le processus de téléchargement et d’installation sera le même. Ici, prenons l’exemple du produit javavm correspondant à Java JRE d’Oracle :
Zsync command found: /usr/bin/zsync Reading config file '/etc/opsi/opsi-product-updater.conf' Getting installed products Getting info for local packages in '/var/lib/opsi/repository' Getting package infos from repository 'http://download.uib.de' [...] javavm_1.8.0.101or1.8.0.102-1.opsi - installation required: product 'javavm' is not installed and auto install is set for repository 'http://download.uib.de' javavm_1.8.0.101or1.8.0.102-1.opsi - download of package is required: local package not found Downloading http://download.uib.de/opsi4.0/products/localboot/javavm_1.8.0.101or1.8.0.102-1.opsi (214.81 MB) to /var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi Download of 'http://download.uib.de/opsi4.0/products/localboot/javavm_1.8.0.101or1.8.0.102-1.opsi' completed Setting rights on directory u'/var/lib/opsi/repository' [...] Installation time window not defined, installing products and setting actions [...] Getting meta data from package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' [...] Installing package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' ================================================================================================= Installing package file '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' on depot 'opsi-test.opensharing.priv' Getting meta data from package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' Creating product in backend Locking product 'javavm' on depot 'opsi-test.opensharing.priv' Checking package dependencies Running preinst script Running package script 'preinst' Unpacking package files Extracting data from package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' Setting product property states in backend Running postinst script Running package script 'postinst' Creating package content file Setting access rights of client-data files Unlocking product 'javavm_1.8.0.101or1.8.0.102-1' on depot 'opsi-test.opensharing.priv' Package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' successfully installed [...] Not setting action 'setup' for product 'javavm' where installation status 'installed' because auto setup is not set for repository 'http://download.uib.de'
Pour résumer, le processus suit les étapes suivantes :
- Vérification du fichier /etc/opsi/opsi-product-updater.conf : quels dépôts et sections sont actifs, quels dépôts sont en autoInstall et/ou autoUpdate et/ou autoSetup
- Vérification des paquets installés en local dans le répertoire /var/lib/opsi/repository
- Vérification des paquets disponibles sur le dépôt http://download.uib.de dans les sections actives (ici localboot et netboot)
- Comparaison des versions collectées en local et sur le dépôt distant
- Téléchargement des produits non installés en local dans le répertoire /var/lib/opsi/repository
- Définition des droits sur les répertoires du dépôt local /var/lib/opsi/repository (770 opsiconfd:pcpatch) et ses fichiers (660 opsiconfd:pcpatch)
- Obtention des métadonnées relatives à chaque produit
- Installation (option -i) des produits non installés en local (c’est-à-dire ici tous car c’est une première installation)
- Création du produit dans le file backend stocké dans /var/lib/opsi/ :
- Exemple pour Java : /var/lib/opsi/config/products/javavm_1.8.0.101or1.8.0.102-1.localboot : fichier texte définissant les propriétés du produit
- Exemple pour Java : /var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi : archive cpio contenant le produit téléchargé en local
- Refus de déploiement automatique des produits sur les clients car aucune section n’est en autoSetup
Ci-dessus, l’option -i a été utilisée pour outrepasser l’option autoInstall définie à false et les éventuelles exclusions pour les dépôts actifs.
4.6. Redémarrage des services
# opsi-setup --init-current-config # opsi-setup --set-rights # service opsiconfd restart # service opsipxeconfd restart
5. Client de connexion à l’interface opsi-configed
Le serveur Opsi est installé, nous pouvons maintenant tester une connexion à l’interface Opsi Configed permettant l’administration du déploiement des produits localboot (logiciels) et netboot (systèmes d’exploitation), même si pour le moment nous n’avons aucun hôte à administrer.
Nous avons besoin, pour établir une connexion avec le serveur, d’installer Java sur le client utilisé pour la connexion.
5.1. Client de connexion Windows
Installer simplement Java.
5.2. Client de connexion Linux
Là aussi il faut installer Java, mais pour cela, la procédure est moins simple :
- Il faut, dans un premier temps, ajouter le dépôt WebUpd8 Oracle Java PPA relatif à la distribution Xenial de Ubuntu dans un nouveau fichier /etc/apt/sources.list.d/webupd8team-java.list.
- Puis, dans un second temps, installer Java 8 et le définir comme version de Java par défaut au cas où d’autres versions soient déjà installées sur le système.
# echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee /etc/apt/sources.list.d/webupd8team-java.list # echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list # apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886 # aptitude update # aptitude install oracle-java8-installer # aptitude install oracle-java8-set-default
On peut ensuite vérifier la version de Java installée sur le système :
# java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)
5.3. Connexion effective à l’interface Opsi Configed
Dans la barre d’adresse d’un navigateur, saisir l’adresse suivante :
https://opsi.opensharing.priv:4447/configed
Accepter l’exception de sécurité en validant le certificat généré en partie 1 de cet article et valide 2 ans.
Ceci entraine le téléchargement d’un applet Java que l’on peut ouvrir avec Oracle Java 8 Web Start (installé avec Java).
Cet applet appelé configed.jnlp contient le code XML suivant :
<?xml version="1.0" encoding="UTF-8"?> <jnlp spec="1.0+" codebase="https://opsi.opensharing.priv:4447" href="configed.jnlp"> <information> <title>opsi-configed</title> <vendor>uib GmbH</vendor> <homepage href="http://www.opsi.org/"/> <description>Management console application for the opsi client management system</description> <description kind="short">opsi management interface (opsi-configed)</description> <icon href="configed.gif"/> <offline-allowed/> </information> <security> <all-permissions/> </security> <resources> <j2se version="1.7+" max-heap-size="1024M"/> <property name="loglevel" value="4" /> <jar href="configed/configed.jar" main="true"/> <jar href="configed/swingx.jar"/> <jar href="configed/commons-io.jar"/> </resources> <application-desc main-class="de.uib.configed.configed"> <argument>--args</argument><argument>-h;;opsi.opensharing.priv:4447</argument> </application-desc> </jnlp>
Lorsque cet applet est exécuté, la connexion s’établit à l’interface de management Opsi Configed, une fois l’authentification faite avec l’utilisateur adminuser créé précédemment :

On retrouve alors la liste des produits localboot installés, sous l’onglet Configuration produit :
Mais aussi les produits netboot sous l’onglet Produits Netboot :
Chaque produit est identifié par sa version installée sur le serveur et installable sur les clients mais aussi par son nom, sa description, ses propriétés et dépendances :
5.4. Et ensuite?
Après la partie 2 d’installation, il est nécessaire de consulter les articles suivants :
Références
- Opsi – Documentation officielle (anglais)
- Opsi – Documentation officielle (français mais non à jour)
- Depot uib pour serveurs Debian
- Depot uib produits localboot pour clients
- Depot uib produits netboot pour clients
- Sources Opsi (Subversion)
- Sources Opsi (GitHub)
- The Official Samba-4 HOWTO
- The Official Samba 3.5.x HOWTO and Reference Guide – Chapter 14. Identity Mapping (IDMAP)
- Samba Manpages – idmap_tdb — Samba’s idmap_tdb Backend for Winbind
- Windows IT Pro – Samba Winbind
- UID, GID, SID and RID
- Les différents backends de Winbind