Opsi Manual PDF

opsi manual opsi version 4.0.
OpenSides sprl
Rue des Palais 44, bte 33
1030 Brussels
Tel.:+32 2 880 97 40
www.opensides.be
Revision: 13.02.2013 opsi@opensides.be
opsi manual opsi version 4.0.3 i
Table des matires
1 Droit dauteur 1
2 Introduction 1
2.1 Qui devrait lire ce manuel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Vue densemble dopsi 2

3.1 Exprience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 fonctionnalits dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.3 Extensions opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 configuration de opsi et outils 3

4.1 Aperu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2 Outil: opsi-setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3 Outil: Management Interface: opsi-configed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3.1 Exigences et fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3.2 Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.3 Copier-Coller, Glisser-Dposer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3.4 Configuration du client / configuration du serveur / gestion des licences . . . . . . . . . . . . . 7
4.3.5 Slection dpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.6 Slection des clients unique et configuration de groupe . . . . . . . . . . . . . . . . . . . . . . . 7
La liste des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Slection des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.7 Slection des clients et groupes hirarchiques en utilisant treeview . . . . . . . . . . . . . . . . 10
Les concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Comment faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.8 Traitement des clients / Actions des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
WakeOnLan (Rveillez les clients slectionns) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Dclencher lvnement on_demand (Push Installation) . . . . . . . . . . . . . . . . . . . . . . 12
Envoi de messages (Show popup message) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appel des outils externes de contrle distance pour des clients slectionns . . . . . . . . . . 12
Arrt / redmarrage des clients slectionns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Supprimer, crer, renommer et dplacer des clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.9 Configuration des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.10 Tableaux de proprit with list editor windows . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.11 Produits Netboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.12 Informations sur le matriel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.13 Linventaire logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
opsi manual opsi version 4.0.3 ii
4.3.14 Journaux systme: Journaux du client et du serveur . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3.15 Paramtres de lhte dans la configuration du client et du serveur . . . . . . . . . . . . . . . . . 16
4.3.16 Configuration du dpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Outil: opsi-package-manager: (d-)installer les paquets opsi . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Outil: opsi-product-updater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.1 Dpts paramtrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.2 Actions paramtrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Outil: opsi-admin / opsi config interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.2 Cas dutilisation typique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Dfinissez un produit pour la configuration (setup) pour tous les clients qui ont install ce produit 21
Liste de tous les clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Supprimer un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Crer un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Dfinir une requte daction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Joindre la description du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Dfinir le mot de passe de pcpatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 Processus serveur: opsiconfd et opsipxeconfd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7.1 opsiconfd monitoring: opsiconfd info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5 Service web / mthodes de lAPI 22

5.1 Service web / Les mthodes API depuis opsi 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.2 Les objets de stockage de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
host (serveur et clients) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
group (ladministration des groupes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
objectToGroup (ladministration des groupes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
product (les mta-donnes du produit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
productProperty (Dfinition des proprits du produit) . . . . . . . . . . . . . . . . . . . . . . . 27
productPropertyState (Paramtres de proprit des produits spcifiques au dpt ou aux clients) 28
productDependency (dpendances du produit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
productOnClient (informations client spcifique un produit, par exemple ltat de linstallation) 29
productOnDepot (informations dpt spcifiques un produit) . . . . . . . . . . . . . . . . . . 29
config (ladministration des valeurs par dfaut des paramtres hte) . . . . . . . . . . . . . . . 30
configState (ladministration des paramtres de lhte client) . . . . . . . . . . . . . . . . . . . 30
auditHardwareOnHost (informations sur le matriel spcifique au client) . . . . . . . . . . . . . 30
auditHardware (informations sur le matriel client indpendant) . . . . . . . . . . . . . . . . . 32
auditSoftwareOnClient (informations sur les logiciels client spcifiques) . . . . . . . . . . . . . . 33
auditSoftware (informations sur les logiciels client indpendants) . . . . . . . . . . . . . . . . . 34
opsi manual opsi version 4.0.3 iii
auditSoftwareToLicensePool (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . . 34

softwareLicenseToLicensePool (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . 35
softwareLicense (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
licenseContract (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
licenseOnClient (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
licensePool (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.3 Les objets spciaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Les mthodes opsi3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Les extensions backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Activation des modules non libres 43
7 opsi-client-agent 44
7.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2 Rpertoires de the opsi-client-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Le service: opsiclientd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3.2 opsiclientd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3.3 opsiclientd notifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.3.4 opsi-login-blocker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3.5 Droulement du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3.6 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuration de diffrents vnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Configuration via le fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Configuration via le web service (Host Parameter) . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.7 Journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3.8 opsiclientd page dinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3.9 opsi-client-agent commande distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Lenvoi de messages pop-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Pousser les installations: dmarrer lvnement la demande . . . . . . . . . . . . . . . . . . . 62
Tches de maintenance supplmentaires (arrt, redmarrage,. . . ..) . . . . . . . . . . . . . . . . 62
7.4 Blocage de la connexion de lutilisateur avec opsi-Loginblocker . . . . . . . . . . . . . . . . . . . . . . 63
7.4.1 opsi loginblocker de Windows 2000 XP (NT 5) . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.4.2 opsi loginblocker pour NT 6 (Win 7 & Co) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.5 Installation ultrieure de opsi-client-agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.5.1 Installation de opsi-client-agent partir dune image matre ou comme exe . . . . . . . . . . . 63
opsi manual opsi version 4.0.3 iv
8 Produits Localboot: distribution de logiciels automatique avec opsi 63

8.1 produits standards dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.1 opsi-client-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.2 opsi-winst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.1.3 javavm: Java Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.4 opsi-adminutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.5 jedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.6 Swaudit et hwaudit: Produits pour linventaire matriel et logiciel . . . . . . . . . . . . . . . . 64
8.1.7 opsi-template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.8 xpconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.2 La manipulation de la squence dinstallation en fonction des priorits du produit . . . . . . . . . . . . 64
8.2.1 Algorithm1: dpendance lgard de la prioritaire du produit (par dfaut) . . . . . . . . . . . . 66
8.2.2 Algorithm2: dpendance lgard de la dpendance du produit . . . . . . . . . . . . . . . . . . 66
8.2.3 Dfinir les priorits et les dpendances du produit . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3 Lintgration des nouveaux paquets logiciels dans le dploiement de logiciels opsi. . . . . . . . . . . . . 66
9 Produits Netboot 67
9.1 Paramtres de limage de dmarrage Linux pour opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.2 Installation automatise de lOS sans assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.1 Aperu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9.2.2 Conditions pralables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.3 Dmarrage du PC client via le rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.4 Chargement de pxelinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
9.2.5 Dmarrer partir du CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.2.6 Limage de dmarrage linux se prpare pour la rinstallation . . . . . . . . . . . . . . . . . . . 70
9.2.7 Installation du systme dexploitation et dopsi-client-agent . . . . . . . . . . . . . . . . . . . . 72
9.2.8 Comment fonctionne le programme Patcha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.2.9 Structure des produits dinstallation sans assistance . . . . . . . . . . . . . . . . . . . . . . . . 73
9.2.10 Intgration simplifie des pilotes avec liens symboliques . . . . . . . . . . . . . . . . . . . . . . 73
9.3 Quelques conseils sur les produits netboot NT6 (Vista / Win7 / 2008) . . . . . . . . . . . . . . . . . . 73
9.4 image Ntfs (crire et restaurer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.5 memtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.6 hwinvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.7 wipedisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10 Inventaire 77
10.1 Inventaire Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
10.2 Inventaire des logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
opsi manual opsi version 4.0.3 v
11 Serveur opsi 80
11.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.2 Installation et mise en service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.3 Configuration Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.4 Le dmon opsiconfd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
11.5 Comptes dutilisateurs et groupes administratifs ncessaires . . . . . . . . . . . . . . . . . . . . . . . . 80
11.6 Rpertoire de partage ncessaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.7 la gestion des problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
12 La scurit 82
12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
12.2 Restez lcoute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
12.3 La scurit gnrale du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
12.4 Dpt en lecture seule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.5 Lauthentification du client sur le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.6 Lauthentification du serveur au client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.6.1 Variante 1: verify_server_cert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
12.6.2 Variante 2: verify_server_cert_by_ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
12.7 Lauthentification au niveau du serveur de commande du client . . . . . . . . . . . . . . . . . . . . . . 85
12.8 Configuration du rseau admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
12.9 Lutilisateur pcpatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
13 Sauvegarde dopsi 86
13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.2 Conditions pralables la sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.3 Mise en route rapide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.4 lments de base dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.4.1 La configuration dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.4.2 Les backends Opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.4.3 dpt de partage opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.4.4 opsi work bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.4.5 dpt opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
13.5 Le logiciel opsi-backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
13.5.1 Crer une sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
13.5.2 Archivez vos fichiers de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.5.3 Vrifier une sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.5.4 Restauration partir dun fichier de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . 90
opsi manual opsi version 4.0.3 vi
14 opsi license management 91

14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
14.1.1 Main features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
14.1.2 Invoking the license management from the opsi-configed . . . . . . . . . . . . . . . . . . . . . . 92
14.2 license pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.2.1 What is a license pool? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.2.2 Administration of license pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.2.3 license pools and opsi-products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
14.2.4 license pools and Windows software IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
14.3 Setting up licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
14.3.1 Some aspects and terms of the license concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
14.3.2 Registering the license contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
14.3.3 Configuring the license model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
14.3.4 Saving the data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
14.4 Editing licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
14.4.1 Example downgrade option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
14.5 Assignment and release of licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
14.5.1 opsi service calls for requesting and releasing a license . . . . . . . . . . . . . . . . . . . . . . . 96
14.5.2 opsi-winst script calls for requesting and releasing of licenses . . . . . . . . . . . . . . . . . . . 96
14.5.3 License contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.5.4 Manual administration of license use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.5.5 Preservation and deletion of license usages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14.6 Reconciliation with the software inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.7 Licenses usage overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.7.1 In case of downgrade option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.8 Service methods for license management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
14.9 Example products and templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15 opsi WAN/VPN extension 100

15.1 Preconditions for using the WAN/VPN extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15.2 General overview of the WAN/VPN extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
15.3 Caching of opsi-products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
15.3.1 Communication Protocol for accessing an opsi-depot . . . . . . . . . . . . . . . . . . . . . . . . 102
15.3.2 Using the .files file for Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
15.3.3 Internal processing of opsi-product caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
15.3.4 Configuring the opsi-product caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
15.4 Caching of configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
15.4.1 The local client-cache-backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
15.4.2 Internal processing of configuration synchronizing . . . . . . . . . . . . . . . . . . . . . . . . . . 104
15.4.3 Configuration of config caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
15.5 Recommended configuration when using the WAN/VPN extension module . . . . . . . . . . . . . . . . 105
15.5.1 Setting the protocol for caching of opsi-products . . . . . . . . . . . . . . . . . . . . . . . . . . 106
15.5.2 Verifying the server certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
opsi manual opsi version 4.0.3 vii
16 opsi-server with multiple depots 107

16.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
16.2 Creating a (slave) depot-servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
16.3 package management with multiple depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
17 Dynamic Depot Assignment 109

17.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
17.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.4 Editing the depot properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
17.5 Synchronizing the depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
17.6 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
17.7 Template of the assignment script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
17.8 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
18 opsi Software On Demand (Kiosk-Mode) 115

18.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
18.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
18.3 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
18.3.1 Managing product-groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
18.3.2 configure the module Software-On-Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuration for the whole system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Configuration for a single client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
18.3.3 opsiclientd event-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
18.3.4 Customize to corporate identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
18.4 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
18.5 Specialities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
19 opsi extension Roaming Profile Support 119

19.1 Preconditions for the extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
19.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
19.3 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
19.4 New and extended opsi-winst functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
19.5 Examples of userLoginScripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
19.6 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
19.7 Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
opsi manual opsi version 4.0.3 viii
20 Connecteur-opsi-Nagios 127
20.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
20.2 Conditions pralables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
20.2.1 Conditions pralables au niveau du serveur et des clients OPSI . . . . . . . . . . . . . . . . . . 127
20.2.2 Conditions pralables au niveau du serveur Nagios . . . . . . . . . . . . . . . . . . . . . . . . . 128
20.3 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
20.3.1 extension opsi web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
20.3.2 extension opsi-client-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
20.4 opsi-checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
20.4.1 Quelques renseignements gnraux sur lendroit o excuter les contrles . . . . . . . . . . . . . 129
20.4.2 opsi-check-plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Contrle: opsi web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Contrle: opsi web service pnp4nagios template . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Contrle: opsi-check-diskusage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Contrle: opsi-client-status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Contrle: opsi-check-ProductStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Contrle: opsi-check-depotsync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Contrle: contrle nagios client plugin via opsiclientd . . . . . . . . . . . . . . . . . . . . . . . . 137
20.5 configuration de la surveillance dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
20.5.1 utilisateur de la surveillance dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
20.5.2 Rpertoire de configuration du connecteur opsi-Nagios . . . . . . . . . . . . . . . . . . . . . . . 139
20.5.3 modle Nagios: opsitemplates.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
20.5.4 opsi hostgroup: opsihostgroups.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
20.5.5 opsi server: <nom complet du serveur>.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
20.5.6 opsi Clients: clients/<nom complet du client>.cfg . . . . . . . . . . . . . . . . . . . . . . . 142
20.5.7 configuration commande opsi: opsicommands.cfg . . . . . . . . . . . . . . . . . . . . . . . . . 143
20.5.8 Contacts: opsicontacts.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
20.5.9 Services: opsiservices.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
21 Installation dopsi lors de larrt 146

21.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
21.2 Conditions pralables linstallation lors de larrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
21.3 Activation de linstallation lors de larrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
21.4 Concept technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
21.4.1 Vue densemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
21.4.2 Installation par script darrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
21.4.3 Entres de Registre pour excuter le script darrt . . . . . . . . . . . . . . . . . . . . . . . . . 149
21.4.4 Configuration de opsiclientd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
21.4.5 Configuration spciale dInstallation lors de lArrt . . . . . . . . . . . . . . . . . . . . . . . . . 151
21.4.6 Fichier de log local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
opsi manual opsi version 4.0.3 ix
22 La fonctionnalit opsi SilentInstall 151

22.1 Conditions pralables linstallation en mode silencieux . . . . . . . . . . . . . . . . . . . . . . . . . . 152
22.2 Vue densemble de la fonctionnalit SilentInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
22.3 Excution de linstallation silencieuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
22.4 Configuration de la fonctionnalit opsi: SilentInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
23 opsi data storage (backends) 154

23.1 file backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.2 ldap-Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
23.3 mysql backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
23.3.1 mysql backend for inventory data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
23.3.2 mysql backend for configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.3.3 Initializing the MySQL-Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.3.4 Configure the mysql database for access from outside the server . . . . . . . . . . . . . . . . . . 160
23.4 HostControl backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.5 Conversion between different backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.6 Boot files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
23.7 Securing the shares with encrypted passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24 Important files on the depot servers 161

24.1 Configuration files in /etc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24.1.1 /etc/hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
24.1.2 /etc/group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.1.3 /etc/opsi/backends/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.1.4 /etc/opsi/backendManager/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.1.5 /etc/opsi/hwaudit/* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.1.6 /etc/opsi/modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
24.1.7 /etc/opsi/opsiconfd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.1.8 /etc/opsi/opsiconfd.pem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.1.9 /etc/opsi/opsipxeconfd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.1.10 /etc/opsi/opsi-product-updater.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.1.11 /etc/opsi/version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.1.12 /etc/init.d/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.2 Boot files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.2.1 Boot files in /tftpboot/linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.2.2 Boot files in /tftpboot/linux/pxelinux.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
24.3 Files in /var/lib/opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.3.1 /var/lib/opsi/repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.3.2 /var/lib/opsi/depot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
opsi manual opsi version 4.0.3 x
24.3.3 /var/lib/opsi/ntfs-images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

24.3.4 Other directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.4 Files of the file backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.4.1 /etc/opsi/pckeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.4.2 /etc/opsi/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.4.3 Overview /var/lib/opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
24.4.4 Configuration files in detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
./clientgroups.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
./config.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
./clients/<FQDN>.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
/var/lib/opsi/config/templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
/var/lib/opsi/config/depots/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Product control files in /var/lib/opsi/config/products/ . . . . . . . . . . . . . . . . . . . . . . . 166
24.4.5 Inventory data /var/lib/opsi/audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.5 Files of the LDAP backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.6 opsi programs and libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.6.1 Python library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
24.6.2 Programs in /usr/bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
24.7 opsi log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
24.7.1 /var/log/opsi/bootimage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
24.7.2 /var/log/opsi/clientconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
24.7.3 /var/log/opsi/instlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
24.7.4 /var/log/opsi/opsiconfd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
24.7.5 /var/log/opsi/opsipxeconfd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
24.7.6 /var/log/opsi/package.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
24.7.7 /var/log/opsi/opsi-product-updater.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.7.8 tftp log in /var/log/syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.7.9 c:\tmp\opsiloginblocker.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.7.10 c:\tmp\opsiclientd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
24.7.11 c:\tmp\instlog.txt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
25 Registry Entries 171

25.1 Registry entries for the opsiclientd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
25.1.1 opsi.org/general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
25.1.2 opsi.org/opsi-client-agent and opsi.org/preloginloader . . . . . . . . . . . . . . . . . . . . . . . 171
25.1.3 opsi.org/shareinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
25.2 Registry entries of the opsi-winst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
25.2.1 opsi.org/winst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
25.2.2 Controlling the logging via syslog protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
opsi manual opsi version 4.0.3 xi
26 Upgrade of a serveur opsi 173
27 opsi localization 173

27.1 Using existing localizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
27.2 Creating or changing localizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.2.1 PO files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.2.2 PO files: opsi-winst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.2.3 PO files: opsiclientd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.2.4 PO files: python-opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.2.5 PO files: opsi-utils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.2.6 PO files: opsi-bootimage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
27.3 configed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
27.4 opsiclientd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
27.5 Localization contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
opsi manual opsi version 4.0.3 1 / 175
1 Droit dauteur
Le droit dauteur de ce manuel est dtenu par uib gmbh Mainz, Allemagne.
Le droit dauteur de la traduction francaise est dtenu par OpenSides Bruxelles, Belgique.
Ce manuel est publi sous licence creative commons
Attribution - ShareAlike (by-sa).
Vous trouverez ici la description allemande:

http://creativecommons.org/licenses/by-sa/3.0/de/
La licence allemande:
http://creativecommons.org/licenses/by-sa/3.0/de/legalcode
La description anglaise:
http://creativecommons.org/licenses/by-sa/3.0/
La licence anglaise:
http://creativecommons.org/licenses/by-sa/3.0/legalcode
La description franaise:
http://creativecommons.org/licenses/by-sa/3.0/deed.fr
La licence franaise:
http://creativecommons.org/licenses/by-sa/3.0/fr/legalcode
Le logiciel OPSI est dans la plupart de ces pices open source.
Seulement les nouvelles pices qui sont encore sous le cofinancement ne sont pas open source.
voir:
http://www.opsi.org/fr/projets-de-co-financement
Tout le reste du code source est publi sous licence GPLv3:
La licence GPLv3:
http://www.gnu.org/licenses/gpl.html
Le nom opsi est une marque dpose de uib gmbh.
Le logo de opsi est dtenue par uib gmbh et peut tre utilis uniquement avec lautorisation explicite.
2 Introduction
2.1 Qui devrait lire ce manuel?
Ce manuel est crit pour tous ceux qui veulent acqurir une meilleure comprhension des mcanismes et des outils du
systme de gestion client opsi ("open pc server integration").
Il prsente un guide pratique complte pour lutilisation de opsi en soulignant la comprhension des connaissances
techniques. Le dcideur qui dcide dutiliser opsi ainsi que ladministrateur systme qui travaille avec lui obtiendront
une base solide pour leurs tches.
2.2 Notations
Les chevrons < > marquent des noms abstraits. Dans un contexte concret tous qui est marqu <nom abstrait>
doit tre remplac par un vrai nom. Exemple: Le partage de fichiers, o opsi place les paquets logiciels, peut tre
not abstraitement comme <opsi-depot-share>. Si le partage de fichiers rel est /opt/pcbin/install, alors vous
devez remplacer le nom abstrait par exactement cette chane de caractres. Lemplacement du paquet <opsi-depot-
share>/ooffice devient /opt/pcbin/install/ooffice.
Exemple dextraits de code de programme ou de fichier de configuration utilisant une police Courier, avec une couleur
de fond:
depoturl=smb://smbhost/sharename/path
3 Vue densemble dopsi
Les outils de distribution de logiciels automatiss et dinstallation du systme dexploitation sont des outils importants
et ncessaires pour la normalisation, la maintenabilit et la rduction des cots dans des grands rseaux de PC.
Normalement, lapplication de ces outils saccompagne dimportantes redevances, alors que OPSI comme un logiciel
open source permet lconomie explicite. Les dpenses seront que pour les services rendus, comme conseil, formation
et maintenance, et peut-tre faible taux de co-financement, si vous souhaitez utiliser certains de ces modules non
libres.
Bien que le logiciel lui-mme et les manuels sont gratuits, le processus dintroduction doutil de distribution de
logiciels est encore un investissement. Pour obtenir le bnfice, sans retours en arrire, et sans une longue periode
dapprentissage, lducation des administrateurs systme par un partenaire professionnel est recommand. uib offre
tous ces services autour dopsi.
Le systme opsi dvelopp par uib dpend de serveurs linux. Ils sont utiliss pour linstallation et la maintenance
distance du systme dexploitation client et des paquets logiciel client ("PC-Server-Integration"). Il est bas autant
que possible sur des outils disponibles gratuitement (GNUtools, SAMBA etc.). Le systme complet tous ensemble
est nomm opsi (Open PC-Server-Integration) et avec sa configurabilit est une solution trs intressante pour les
difficults dadministration dun parc informatique important.
3.1 Exprience
opsi est driv dun systme, qui est en usage depuis le milieu des annes 90 avec plus de 2000 clients-PC dans des
endroits diffrents dune autorit gouvernementale. Depuis ce temps il a t continuellement adapte lvolution du
systme dexploitation Microsoft. En tant que produit, opsi est dsormais accessible pour un large ventail dutilisateurs
intresss.
Vous pouvez trouver une vue densemble gographique des installations OPSI sur: http://www.opsi.org/fr/opsi-map .
3.2 fonctionnalits dopsi
Les principaux lments de opsi sont :

Distribution automatique des logiciels
Installation automatique du systme dexploitation
Inventaire hardware et software avec historique
Contrle confortable via linterface de gestion opsi
Prise en charge de multiples serveurs de dpt
3.3 Extensions opsi
Gestion des licences

MySQL-Backend
Utilisation de groupes de clients hirarchique (Treeview)
Slection dynamiques du serveur de dpt
Logiciels sur demande
Prise en charge de clients derrire des connexions lentes (WAN Extension)
4 configuration de opsi et outils
4.1 Aperu
La configuration dopsi ncessite une certaine gestion des donnes. Tous les composants non-serveur utilisent un service
Web pour changer des donnes avec le serveur opsi. Ils changent des donnes via opsiconfd, et opsiconfd transmet
les donnes au gestionnaire de backend qui passe les donnes dans le backend slectionn.
opsi prend en charge diffrents backends: Backends:
bas Fichier
bas LDAP
bas MySQL
En utilisant le backend de fichier les donnes sont stockes dans des fichiers texte comme les fichiers ini.
Schema: opsi avec le backend de fichier
Figure 1 Schema: opsi avec le backend de fichier
En utilisant le backend mysql ou ldap les donnes sont stockes dans des objets de donnes spcifiques.
Schema: opsi avec le backend SQL / LDAP
Figure 2 Schema: opsi avec le backend SQL / LDAP
Vous trouverez plus de dtails dans
Schema: couches backend et contrle daccs
Figure 3 Schema: couches backend et contrle daccs
Le rpertoire de opsi 3 /etc/opsi/backendManager.d nest plus utilis dans opsi 4.

Les fichiers de configuration dans /etc/opsi/backends dfinissent les backends.
Quelle base est utilise pour lesquels des donnes, est configur dans le fichier /etc/opsi/backendManager/dispatch.
conf.
Le fichier /etc/opsi/backendManager/acl.conf dfinit qui a accs quelles mthodes.
Dans le rpertoire /etc/opsi/backendManager/extend.d il pourrait y avoir des fichiers dfinissant les mthodes
tendu de opsi. Ainsi, vous trouverez ici par exemple les fichiers qui dfinissent les anciens mthodes legacy de opsi 3
en les mappant les nouvelles mthodes de opsi 4 (/etc/opsi/backendManager/extend.d/20_legacy.conf).
Vous trouverez une rfrence plus dtaille de ces fichiers de configuration dans
4.2 Outil: opsi-setup

Ce programme est quelque chose comme le couteau suisse de la configuration de opsi. Il est utilis par les scripts
dinstallation de opsi et peut tre galement appel sparment pour le but de maintanace ou de rparation.
Les tches de opsi-setup sont:
enregistrer un serveur opsi comme serveur de dpt
corriger des droits daccs aux fichiers
initialiser les backends de stockage de donnes
mettre jour les backend (de 3.4 4.0)
configuration du backend MySQL
modifier les configurations par dfaut
nettoyer le(s) backend(s) courant(s)
configurer lessentiel du partage Samba
configurer les entres essentielles du dhcp
La commande opsi-setup --help montre les options du programme:
opsi-setup --help
Usage: opsi-setup [options]
Options:
-h, --help show this help
-l log-level 0..9
--log-file <path> path to log file

--ip-address <ip> force to this ip address (do not lookup by name)
--register-depot register depot at config server
--set-rights [path] set default rights on opsi files (in [path] only)
--init-current-config init current backend configuration
--update-mysql update mysql backend
--update-ldap update ldap backend
--update-file update file backend
--configure-mysql configure mysql backend
--edit-config-defaults edit global config defaults
--cleanup-backend cleanup backend
--auto-configure-samba patch smb.conf
--auto-configure-dhcpd patch dhcpd.conf
Les fonctions et les options en dtail:

--ip-address <ip>
Dfinit ladresse IP pour serveur opsi et ne rsolve pas par le nom.
--register-depot
Cette option est utilise pour enregistrer un serveur opsi comme serveur de dpt dun autre serveur opsi (opsi-
configserver). Pour plus de dtails voir
--set-rights [path]
Dfinit les droits daccs aux fichiers dans tous les rpertoires de opsi:
/tftpboot/linux
/home/opsiproducts
/var/log/opsi
/var/lib/opsi
/opt/pcbin/install
/etc/opsi
Vous pouvez donner un nom de rpertoire comme argument pour dfinir uniquement les droits daccs en dessous
de ce rpertoire.
par exemple
opsi-setup --set-rights /opt/pcbin/install/winxppro/drivers
--init-current-config
initialise le backend configur. Doit toujours tre appele aprs modification du fichier
/etc/opsi/backendManager/dispatch.conf
Les trois commandes:
--update-mysql
--update-ldap
--update-file
sont utilises pour mettre niveau les backends dune version dopsi la suivante.
Pour plus de dtails voir le releasenotes-upgrade-manual.
--configure-mysql
fait la premire configuration de la base de donnes.
--edit-config-defaults
Pour modifier les valeurs par dfaut de certaines donnes de configuration, comme dans la configuration du serveur
de opsi-configed.
--edit-config-defaults
Pour modifier les valeurs par dfaut de certaines donnes de configuration, comme dans la configuration du serveur
de opsi-configed.
Dialog: opsi-setup --edit-config-defaults
Figure 4 Dialog: opsi-setup --edit-config-defaults
par exemple:
clientconfig.depot.id
Le nom du serveur de dpt par dfaut.
license-management.use
Dfinit si les produits netboot devraient obtenir les cls de licence depuis la gestion des licences ou partir des
proprits du produit.
product_sort_algorithm
Dfinit lalgorithme qui est utilis pour calculer la squence dinstallation des produits.
--cleanup-backend
Vrifie le backend actuel(s) pour les entres qui ne sont plus ncessaires et lintgrit rfrentielle
--auto-configure-samba
Cre les partage opsi dans le fichier de configuration /etc/samba/smb.conf
--auto-configure-dhcpd
Cre les entres opsi ncessaires dans `/etc/dhcp3/dhcpd.conf.
Ne pas utiliser si vous ne prvoyez pas dutiliser le dhcpd sur le serveur opsi.
Plus de dtails dans le manuel opsi-getting-started
4.3 Outil: Management Interface: opsi-configed
4.3.1 Exigences et fonctionnement
opsi-configed ncessite Java 1.6 et un opsiconfd en excution sur le serveur.

Si vous excutez opsi-configed sur une machine base sur Linux, alors assurez-vous que votre Java est la version Sun.
La version OpenJDK souvent installs ou dautres versions peuvent conduire des erreurs subtiles. Donc, vous devez
installer Sun Java et le configurer comme dfaut Java:
update-alternatives config java
La commande
java -version
devrait aboutir la sortie suivante:

java version "1.6....
Java(TM) SE Runtime Environment ...
La plupart du temps opsi-configed sera appel comme applet dans le navigateur via: https://<servername>:4447/
configed
Lapplication opsi-configed est galement une partie du produit opsi opsi-adminutils et peut alors tre dmarr via le
menu Dmarrer de Windows. Sur le serveur opsi-configed est install dans le cadre de linstallation du serveur opsi. Il
peut tre dmarr en utilisant lentre de menu ou avec la commande /usr/bin/opsi-configed.
Si vous tes dans le bon rpertoire, il peut galement tre lanc avec java -jar configed.jar.
Loption daide java -jar configed.jar --help montre les options disponibles en ligne de commande.
P:\install\opsi-adminutils>java -jar configed.jar --help
starting configed
default charset is windows-1252
server charset is configured as UTF-8
configed [OPTIONS]...
Options:
-l, --locale Set locale (format: <language>_<country>)
-h, --host Configuration server to connect to
-u, --user Username for authentication
-p, --password Password for authentication
-d, --logdirectory Directory for the log files
--help Show this text
4.3.2 Connexion
opsi-configed: login mask
Figure 5 opsi-configed: masque de connexion
Au moment de la connexion opsi-configed tente de se connecter au serveur opsi via https. La connexion se fait avec
les paramtres donns opsi server[:Port] (default port 4447 opsiconfd) et lutilisateur/mot de passe du compte
opsi-configserver. Pour la connexion lutilisateur fourni doit tre un membre du groupe unix opsiadmin.
4.3.3 Copier-Coller, Glisser-Dposer
Vous pouvez copier les entres slectionnes de presque chaque section de opsi-configed dans le presse papier en
utilisant les combinaisons de touche standard (Strg-Insert, Strg-C ). Ceci peut tre utilis pour transfrer des donnes
intressantes dautres programmes. Pour la plupart des tables vous pouvez galement utiliser le Glisser-Dposer
pour copier les donnes vers des programmes comme Excel.
Note
Depuis la version Java 1.6.24 Oracle a dsactiv le Copier-Coller vers et partir du presse-papiers du systme partir
dun applet Java ne pas signe, pour des raisons de scurit. Lapplication opsi configed est livr avec la signature depuis
la version 4.0.1.11, et a maintenant accs au systme complet.
4.3.4 Configuration du client / configuration du serveur / gestion des licences
Pour basculer entre les diffrentes vues de opsi-configed, utiliser les boutons dans le coin suprieur droit.
opsi-configed: Buttons for (from left to right): Client configuration, Server configuration, License management
Figure 6 opsi-configed: Boutons pour (de gauche droite): Configuration du client, Configuration du serveur,
Gestion des licences
4.3.5 Slection dpt
opsi-configed: depot selection
Figure 7 opsi-configed: slection dpt
4.3.6 Slection des clients unique et configuration de groupe
Aprs une connexion russie la fentre principale souvre et affiche longlet Client selection. Cet onglet affiche la liste
des clients connus des opsi-depot slectionns ou les clients qui sont slectionnes en utilisant le contrle treeview sur
le ct gauche de opsi-configed.
opsi-configed: client selection mask
Figure 8 opsi-configed: masque de slection des clients
Vous pouvez slectionner une ligne de la liste non seulement par dfilement manuel et en choisissant mais aussi par
une chane de recherche. Cela exige que vous entrez une chane dans le champ de recherche au sommet de la liste Dans
la liste une ligne peut galement tre slectionne par la recherche dune valeur de chane.
Le fonctionnement de la recherche est dtermine par les lments slectionns dans deux listes droulantes:
Via la slection des champs vous dcidez si
tous les champs (plus prcisment, tous les champs qui se produisent sous forme de colonnes) sont recherchs (par
dfaut), ou
un seul champ (et celui qui) est recherch.
Concernant la mthode de recherche vous devez choisir si est dfinie
comme occurrence de la chane de recherche nimporte o dans une valeur de champ (recherche de chane partielle,
par dfaut),
comme occurrence de la chane de recherche au dbut dune valeur dun champ
comme une correspondance de motif dans une recherche dexpression rgulire o la chane de recherche sert de
modle (pour les experts, bas sur la recherche de motifs java).
La touche entre conduit la recherche suivante. Plus de fonctions de slection bases sur la recherche de chane sont
indiqus dans le menu contextuel du champ de recherche.
opsi-configed: Client search
Figure 9 opsi-configed: Fonction de recherche dans la liste de slection des clients

La liste des clients
La liste des clients a par dfaut les colonnes client name, description, on, IP address et last seen.
client name est le nom dhte complet qualifi qui est le nom du client, y compris le nom de domaine
description est une description libre slectionnable que vous pouvez diter dans la partie suprieure droite de la
fentre
On montre aprs avoir cliqu sur le bouton Check wich clients are connected (Vrifiez quels clients sont connects)
le rsultat de cette requte.
opsi-configed: Button: Check which clients are connected
Figure 10 opsi-configed: Bouton Vrifiez quels clients sont connects
IP address indique le numro IP laquelle le serveur OPSI rsout le nom du client.

last seen indique la date et lheure du dernier client qui sest connect au service web opsiconfd
Certaines colonnes sont dsactives par dfaut:

session infos (les donnes sont extraites du systme dexploitation sexcutant sur le client spcifique)
Inventory No (affiche certaines donnes en option)
created (date et heure de cration du client)
opsi mac address (adresse matrielle du client utilis par opsi)
Vous pouvez activer ces colonnes laide du menu contextuel. La configuration des colonnes activs peut tre modifi
en utilisant lentre configed.host_displayfields dans la configuration du serveur.
opsi-configed: change the default for visible columns in the clients list
Figure 11 opsi-configed: changer la valeur par dfaut pour les colonnes visibles dans la liste des clients
Lajout de la colonne session infos active le bouton "request session infos from all clients" dans le panneau des boutons.
opsi-configed: Buton SessionInfo?
Figure 12 opsi-configed: Bouton Sessioninfo?
Lorsque ce bouton est cliqu opsiconfd tente de se connecter tous les clients et de rcuprer les donnes des sessions
utilisateur actives. A partir du rsultat, les noms de compte sont indiqus dans la colonne session infos. Au lieu
dutiliser le bouton vous pouvez dmarrer la requte uniquement pour les clients slectionns via le menu contextuel
ou lentre du menu principal de OpsiClient. Comme a on vite dattendre le timeouts du rseau.
Puisque la fonction de recherche pour la liste client fonctionne (si nest pas configur autrement) sur toutes les colonnes
affiches vous pouvez maintenant trouver quel est le client appartenant un utilisateur connect (avec le nom de compte
connu).
Pour trier les clients par une certaine colonne cliquez sur lentte de haut de cette colonne.
Slection des clients
Vous pouvez slectionner un ou plusieurs clients pour travailler avec. Le point de vue du client peut tre re-
streint des clients slectionns en cliquant sur licne entonnoir ou dans le menu Grouping / Show only selected
clients(Groupement / Afficher seulement les clients slectionns).
Un groupe de clients slectionns peuvent tre enregistrs avec licne Save grouping (Enregistrer regroupement) ou
partir du menu Grouping / save group (Groupement / Enregistrer le groupe) introduisant le nom de votre choix.
Vous pouvez utiliser la souris pour ajouter les clients slectionns dans un groupe existant (en les faisant glisser dans
un groupe existant qui est affich dans larborescence).
Dans la bote de dialogue de slection des clients (appel via le menu Slection / Prciser la recherche) les clients
peuvent tre slectionns en utilisant une varit de critres bass sur leurs configurations.
Figure 13 opsi-configed: masque: slection des clients
Par exemple, il est possible de rechercher des produits opsi installs ainsi que des logiciels tels que trouvs par laudit
logiciel dOPSI (swaudit). Vous pouvez ainsi rechercher les PC satisfaisant certaines des conditions matrielles. Les
critres peuvent tre combins par des oprateurs logiques and ou or. La ngation est galement possible. Les chanes
de recherche peuvent tre donns sous forme de chanes fixes combins avec des astrisques * en tant que symboles
gnriques.
Les dfinitions de recherche peuvent tre enregistrs, puis de nouveau utilis via le menu Slection/Utilisez dfinitions
de recherche sauvegarde.
Figure 14 opsi-configed: recherches enregistres
Il est galement possible dexcuter une recherche enregistre partir de la ligne de commande lorsque lditeur de
opsi-configed est lanc. En incluant le drapeau "-qs" et le nom de la recherche enregistre, lditeur de configuration
dmarre avec les rsultats de recherche enregistrs. Si le nom est omis, alors une liste de recherches disponibles seront
affichs.
4.3.7 Slection des clients et groupes hirarchiques en utilisant treeview
Depuis opsi 4.0 il est possible de grer des groupes et des clients utilisant un contrle darborescence sur le ct gauche
de opsi-configed. Une deuxime amlioration est la possibilit de groupes hirarchiques (groupes dans les groupes).
Cette fonctionnalit tree view fait partie dun projet de co-financement et ne fonctionne quavec un fichier dactivation
valide. Les frais dactivation sont 500 . Pour lvaluation sil vous plat contactez info@uib.de. The tree view control
has base node ALL with all groups and clients beyond..
Les concepts de base
Le contrle TreeView a base de noeud ALL avec tous les groupes et les clients au-dessus. Il y a un autre nud Groups
qui est le groupe de base pour toutes les autres groupes dfinis automatiquement.
opsi-configed: Treeview with clients and groups
Figure 15 opsi-configed: Treeview avec les clients et les groupes
Il y a un groupe supplmentaire REPORTED_FAILURES qui contient tous les clients, qui ont un rsultat de laction
failed (chou).
Chaque client connu est toujours dans le groupe ALL. En outre, un client peut tre dans un ou plusieurs autres
groupes. Vous pouvez construire des arbres de groupe diffrent qui reprsentent critres dordre diffrent, comme la
structure administrative, matrielle ou linventaire logiciel typique.
Si vous slectionnez un client, les icnes de tous les groupes auxquels le client slectionn appartiennent seront colors.
Comment faire . . .
Par un clic sur un nud (ou un groupe) tous les clients au-dessus de ce nud seront affichs dans longlet Clients,
mais aucun de ces clients est slectionn pour le traitement.
Par un clic sur un client, ce client sera affich dans longlet Clients est slectionn pour le traitement. Vous pouvez
galement utiliser ce moyen pour changer le client slectionn alors que vous tes dans un autre onglet, comme pour
la configuration du produit sans revenir longlet clients.
Vous pouvez utiliser Ctrl-click et Shift-click pour slectionner plusieurs clients. Ce contrle TreeView montre les groupes
qui sont crs selon le chapitre
Vous pouvez galement crer des groupes en utilisant le menu contextuel dessus de ALL ou tout autre groupe existant.
opsi-configed: Using the context menu to create a new subgroup
Figure 16 opsi-configed: Utiliser le menu contextuel pour crer un nouveau sous-groupe
Il vous sera demand le nouveau nom du groupe.
opsi-configed: Dialog: Group name
Figure 17 opsi-configed: Bote de dialogue: nom du groupe
Un groupe peut tre peuples avec des clients laide du glisser-dposer avec
copie des clients partir de longlet Clients vers le groupe dans larborescence (bouton gauche de la souris)
copie des clients partir de larborescence sous le nud ALL vers le groupe dans larborescence (bouton gauche de
la souris)
dplacement dun groupe de clients dans larborescence vers un autre groupe dans larborescence (bouton gauche
de la souris)
copie des clients dun groupe de larborescence dans un autre groupe de larborescence (Ctrl-bouton gauche de la
souris)
4.3.8 Traitement des clients / Actions des clients
En utilisant le menu OpsiClient ou le menu contextuel de longlet Clients vous pouvez choisir parmi un grand nombre
doprations spcifiques du client
opsi-configed: : context menu Clients Tab
Figure 18 opsi-configed: : menu contextuel de longlet Clients

WakeOnLan (Rveillez les clients slectionns)
Choisissant cette entre de menu, vous allez envoyer aux clients slectionns un signal WakeOnLan.
Dclencher lvnement on_demand (Push Installation)
Cette entre de menu est utilis pour envoyer opsi-client-agent sur les clients slectionns une commande pour
dclencher lvnement on_demand (sur demande). Cet vnement commencera le traitement de la demande daction
immdiatement. Tous les messages seront affichs sur le bureau actif. Si le client nest pas joignable, vous obtiendrez
un message.
Quest-ce qui se passe exactement if you fire the event on_demand can be configured in the event on_demand
configuration.
Envoi de messages (Show popup message)
Choisissant lentre de menu Show popup message (Voir le message contextuel) vous aurez une petite fentre o vous
pouvez saisir votre message.
opsi-configed: opsi message edit mask
Figure 19 opsi-configed: opsi message edit mask
En cliquant sur la case rouge, vous envoyez le message aux clients slectionns.
Une fentre de message apparatra aux clients slectionns.
opsi-configed: opsi message display dialog
Figure 20 opsi-configed: opsi message display dialog
Appel des outils externes de contrle distance pour des clients slectionns
Loption Remote Control Software call (appel logiciel de contrle distance) dans le menu contextuel du client ainsi
que le menu principal du client (depuis opsi-configed version 4.0.1.11) est trs puissant. Il peut tre utilis pour utiliser
nimporte quelle commande que le systme dexploitation offre, paramtre par exemple par le nom du client.
Par exemple il existe des configurations gnr automatiquement qui peuvent tre utilis pour envoyer un ping pour
le client slectionn: une commande ping qui fonctionne en environnement Windows et une commande qui exige
un environnement X Linux. Sil vous plat observez: opsi-configed appelle de toute vidence la commande dans son
environnement, par exemple, nous avons besoin de la commande Linux lorsque opsi-configed tourne sous Linux.
opsi-configed: Choice of Remote Control call
Figure 21 opsi-configed: Choix de lappel de contrle distance
La fentre de slection comporte trois parties. La partie suprieure numre les noms des commandes existantes. Une
ligne suit, qui montre la commande slectionne et offre la possibilit de la modifier (si cela est autoris). De plus, la
ligne contient les boutons pour excuter ou abandonner laction. La troisime zone de texte de la fentre capture les
messages qui sont retourns par le systme dexploitation lors de lappel de la commande.
Ces appels offrent une gamme quasi infinie de possibilits. Par exemple, une commande peut tre configur pour
ouvrir une connexion Remote Desktop pour le client slectionn (si elle permet de telles connexions). Sur un systme
Windows, la commande est
cmd.exe /c start mstsc /v:%host%

Dans un environnement Linux, la commande suivante peut tre utilise:
rdesktop -a 16 %host%
Dans les exemples %host% est une variable, dont opsi-configed remplace automatiquement par la valeur de lhte
slectionn. Dautres variables qui sont de faon analogue utilis dans les commandes sont %ipaddress% et %invento
rynumber%.
Si la commande est marque par lentre supplmentaire editable comme true, la ligne de commande permet ldition
ad hoc. Par exemple, vous pouvez ajouter un mot de passe demand ou varier la commande si ncessaire.
Si plus dun client est slectionne, la commande sera excute dans un thread propres chaque client.
La liste des commandes de contrle distance est modifiable via les entres de configuration du serveur (voir Sec-
tion 4.3.15).
Pour dfinir une commande example, au minimum une entre configed.remote_control.example (ou configed.
remote_control.example.command) doit tre gnr. La valeur de la proprit doit tre la commande (dans laquelle les
variables %host%, %ipaddress% etc. peuvent tre utilises). En plus, une entre configed.remote_control.example.
description peut tre dfini. La valeur de cette entre sera affich comme info-bulle (si nexiste pas, la commande
elle-mme servira de contenu info-bulle). Par ailleurs, une entre boolenne configed.remote_control.example.
editable peut tre ajoute. Si sa valeur est fixe false la commande ne peut pas tre modifis dans la fentre de
slection.
opsi-configed: Editing of remote control commands in the server properties editor
Figure 22 opsi-configed: Modification des commandes de contrle distance dans lditeur des proprits du serveur
Arrt / redmarrage des clients slectionns
Vous pouvez envoyer aux clients slectionns un signal darrt ou de redmarrage. Vous devez confirmer cette commande
opsi-configed.
Attention
Si le client a reu le signal, il steindra sans plus de questions.
Supprimer, crer, renommer et dplacer des clients
Vous pouvez supprimer les clients slectionns partir du serveur opsi.

Si vous choisissez de crer un client, un masque de saisie souvre. Vous entrez ou confirmez les donnes requises
nom du client sans spcification de domaine, nom de domaine, nom du serveur de dpt. Vous pouvez ajouter une
description textuelle pour ce client et des notes sur ce client.
opsi-configed: cration dun client
Figure 23 opsi-configed: cration dun client
Le masque contient galement des champs pourune dclaration facultative de ladresse IP et de ladresse MAC dun
client. Si le backend est activ pour la configuration dun serveur dhcp locale (qui nest pas le paramtre par dfaut),
cette information sera utilise pour faire connaitre le nouveau client au serveur dhcp. Sinon, ladresse MAC sera
enregistr dans le serveur et ladresse IP sera rejet.
Vous pouvez renommer un client slectionn, il vous sera demand le nouveau nom.
Le dplacement dun client un serveur de dpt diffrents. Si vous cliquez, les fentres suivantes saffichent avec une
liste de serveurs de dpt existant
opsi-configed: changer le dpt dun client
Figure 24 opsi-configed: changer le dpt dun client
4.3.9 Configuration des produits
En passant longlet Product configuration (Configuration des produits) vous obtenez une liste de paquets logiciels
disponibles avec leur statut dinstallation et le statut daction pour les clients slectionns.
opsi-configed: masque de configuration des produits
Figure 25 opsi-configed: masque de configuration des produits
Sil y a un statut diffrent pour les clients slectionns ce sera marque en gris (undefined). La liste des clients
slectionns est indiqu droite en haut.
Vous pouvez galement trier la liste des produits en cliquant sur lentte de colonne.
Ceci sont les colonnes:
Status (Statut) est le dernier tat du produit et peut contenir les valeurs installed (install) , not_installed (non
install) , unknown (inconnus). Le tableau montre une cellule vide si la valeur est not_installed pour amliorer la
convivialit de la vue. La cellule devient gris si une multitude de clients sont slectionns et ne partagent pas une
valeur commune (la coloration grise reprsente la valeur pseudo mixed).
Report informe sur les progrs ou le rsultat de la dernire action en utilisant le modle <action result> (<last
action>). Lors dun processus dinstallation il peut indiquer installing (installant) , ensuite par exemple failed(setup)
(chou (installation)) ou success (uninstall) (succs (dsinstaller)).
La colonne Requested action (Action demand) dtient les informations sur laction qui sera excut. Les valeurs
possibles sont none (montr par une cellule vide) et les types daction pour lesquels les scripts sont dfinis dans le
paquet du produit (valeurs possibles sont setup (installer), uninstall (dsinstaller), update (mise jour), once (une
fois), always (toujours), custom (personnalis)).
Le champ Version affiche le numro de version du logiciel combin avec le numro du paquet opsi du logiciel install
sur le client.
Il y a deux colonnes supplmentaires qui peuvent tre actives via le menu contextuel:
Priority class affiche une valeur de priorit qui est attribu au produit (priorit la plus leve +100, priorit la plus
faible -100). Elle influe sur lordre dinstallation des produit (en vertu de product_sort_algorithm)
La colonne position column displays the product ordering forecast for installation sequences.
Choisissez un logiciel pour obtenir plus dinformations sur le produit dans la partie droite de la fentre, comme:
Complete product name: nom complet du produit de ce paquet logiciel.
Software/package version: version du logiciel-version du paquet opsi du progiciel (spcifi dans le paquet dinstalla-
tion opsi).
Product description: texte libre pour dcrire le logiciel.
Hints: texte libre avec conseils et avertissements pour la manipulation du paquet.
Requirements: Une liste des autres produits dont le produit slectionn (dit A) dpend combin avec le type de
dpendance: required signifie que A exige lautre produit (B), mais peu importe si B est install avant ou aprs
A. pre-required signifie que B doit tre install avant A. post-required signifie que B doit tre install aprs A. on
deinstall signifie que cette action devrait avoir lieu si A est de-install.
Configuration for client: Il est possible de dfinir des proprits supplmentaires pour un produit. Leurs valeurs
peuvent tre values dans un script de configuration pour configurer le produit par client. En raison de la complexit
intrinsque dune dfinition de la proprit il y a un lment dinterface spcifiques pour afficher et diter la table
des proprits:
4.3.10 Tableaux de proprit with list editor windows
Une table de proprit est un tableau deux colonnes. Dans chaque ligne, la premire colonne contient un nom de
proprit, la deuxime colonne affiche la valeur(s) attribue la proprit.
Il peut tre configur pour quune info-bulle saffiche avec quelques informations sur le sens de la proprit et la valeur
par dfaut.
opsi-configed: Table de proprit avec info-bulle
Figure 26 opsi-configed: Table de proprit avec info-bulle
Si vous cliquez sur une valeur, une fentre souvre: lditeur de liste (list editor) pour cette proprit. Il montre une
valeur, respectivement une liste de pr valeurs configures avec la valeur actuelle comme slectionn.
opsi-configed: diteur de liste, liste de slection
Figure 27 opsi-configed: diteur de liste, liste de slection
En cliquant une nouvelle valeur modifie la slection.

Si la liste des valeurs de la proprit est modifiable (des nouvelles valeurs peuvent tre ajouts la liste existante resp.
existing values changed) la fentre vient avec un champ ddition pour les valeurs nouvelles ou modifies.
opsi-configed: diteur de liste, champ ddition
Figure 28 opsi-configed: diteur de liste, champ ddition
La faon la plus confortable pour obtenir une nouvelle valeur qui est une variante dune valeur existante est de
double-cliquer sur la valeur existante dans la liste. Cela copie la valeur dans le champ ddition o elle peut tre
modifi.
Ds que le champ ddition contient une nouvelle valeur pas encore prsent dans la liste des valeurs le bouton plus
est activ par lequel la nouvelle valeur peut tre ajoute la liste des valeurs.
Si plusieurs valeurs sont permises comme il faut par exemple pour la proprit additional drivers une valeur peut
tre ajoute lensemble des valeurs slectionnes par Strg-Click . La mme action supprime la valeur de lensemble.
Le bouton moins (depuis opsi-configed en version 4.0.2) efface compltement la slection.
Lorsque la liste a t dite la coche verte devient rouge comme dhabitude dans opsi-configed. En cliquant dessus,
la nouvelle slection devient la nouvelle valeur de la proprit (et termine ldition). En cliquant sur le bouton bleu
annuler, ldition sarrte rinitialisant la valeur dorigine.
4.3.11 Produits Netboot
Les produits sous longlet Netboot products sont principalement utiliss pour installer le systme dexploitation client
et sont rpertoris et configurs comme les produits sous longlet Product configuration.
Si pour le(s) client(s) slectionn(s) un produit netboot est rgl sur setup, limage de dmarrage correspondant sera
charg et excut au prochain redmarrage du client.
opsi-configed: masque pour lancer limage de dmarrage
Figure 29 opsi-configed: masque pour lancer limage de dmarrage
Cela se fait gnralement pour dmarrer une installation de lOS ou toute autre tche de limage de dmarrage (comme
un test de mmoire, etc.)
4.3.12 Informations sur le matriel
Avec cet onglet, vous obtenez les dernires informations matrielles dtect pour ce client (disponible uniquement si
un seul client est slectionn).
opsi-configed: Informations sur le matriel pour le client slectionn
Figure 30 opsi-configed: Informations sur le matriel pour le client slectionn
4.3.13 Linventaire logiciel
Avec cet onglet, vous obtenez les dernires informations logiciels dtect pour ce client (disponible uniquement si un
seul client est slectionn).
opsi-configed: Informations sur les logiciels pour le client slectionn
Figure 31 opsi-configed: Informations sur les logiciels pour le client slectionn
4.3.14 Journaux systme: Journaux du client et du serveur
Les journaux systme spcifique au client sont stockes sur le serveur et visible avec opsi-configed via longlet log files.
Il est galement possible de rechercher dans ces fichiers (pour continuer la recherche, appuyez F3 ou n).
Figure 32 opsi-configed: Affichage du journal systme dans opsi-configed
4.3.15 Paramtres de lhte dans la configuration du client et du serveur
Il y a de nombreuses options de configuration pour le serveur et les clients opsi qui peuvent tre initialise ou change
via longlet Host parameters. Ainsi, les options par dfaut du serveur sont dfinies dans le mode server configuration,
les valeurs spcifiques du client dans le mode client configuration ainsi que la slection manuelle dans longlet des Host
parameters (voir aussi Section 4.3.4).
En principe, ces entres de configuration (config objects du serveur opsi) sont conus comme des listes de valeurs.
Donc ils sont dits via loutil de lditeur de liste (voir Section 4.3.10).
En fonction de la dfinition prcise dun objet de configuration
les valeurs dune liste peuvent tre de type texte (Unicode) ou de type Boolean (par exemple true/false);
la liste peut avoir quun seul lment ou peut tre une vritable liste avec plusieurs membres;
lensemble des valeurs partir de laquelle des lments de liste sont slectionns peuvent tre fixes ou extensibles.
Les nouvelles configurations des entres, des types de unicode (extendible) et boolean (fixed) peuvent tre crs via le
menu contextuel. Il offre galement la possibilit de supprimer les entres existantes.
La relation des entres du serveur et du client est complique.
Les entres du serveur dtiennent les valeurs par dfaut pour les entres du client.
Quand une entre du serveur (un objet de configuration) est supprim les entres dpendants du client (tats de
configuration) disparaissent aussi.
La cration dune entre client via opsi-configed entrane la cration automatique dune approprie valeur par dfaut
du serveur.
La suppression dune entre client via opsi-configed supprime uniquement la valeur client spcifique (si elle existe)
mais laisse les valeurs par dfaut du serveur (qui seront valables pour le client).
Pour le moment opsi-configed nindique pas si une valeur spcifique du client existe ou si la valeur par dfaut du
serveur est utilis par le client.
Il ya des objets de configurations pour lesquelles des valeurs du client peuvent tre cres et dites, mais seulement
les objets du serveur sont utiliss (par exemple les entres de opsi-configed, commenant par configed.).
Figure 33 opsi-configed: Onglet Paramtres de lhte (Configuration du serveur et du client)
4.3.16 Configuration du dpt
Dans le mode Properties of depots vous verrez longlet Dpts. Il y a un menu droulant pour slectionner le dpt.
Aprs avoir slectionn le dpt, vous pouvez modifier les proprits de opsi-depot.
voir aussi:
opsi-configed: Onglet de configuration Dpt
Figure 34 opsi-configed: Onglet de configuration Dpt

4.4 Outil: opsi-package-manager: (d-)installer les paquets opsi
opsi-package-manager est utilis pour (d-)installer un opsi-product-packages sur un serveur opsi.

Afin dinstaller un opsi-product-package, le opsi-product-package doit tre lisible pour lutilisateur opsiconfd. Cest
pourquoi il est fortement recommand dinstaller ces paquets partir du rpertoire /home/opsiproducts (ou un sous-
rpertoire).
Le journal systme de opsi-package-managers vous le trouverez /var/log/opsi/package.log.
Installer un paquet (sans poser de questions):
opsi-package-manager -i softprod_1.0-5.opsi
Installer un paquet (posant des questions):

opsi-package-manager -p ask -i softprod_1.0-5.opsi
Installer un paquet (et le commutateur daction ncessaires, pour la configuration, lorsquil est install):
opsi-package-manager -S -i softprod_1.0-5.opsi
Dsinstaller un paquet (sans poser de questions):

opsi-package-manager -r softprod
Extraire et renommer un paquet:

opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod
Appeler opsi-package-manager avec loption --help donne une liste des options possibles.
Sil vous plat remarquez:
Loption -d ou --depots sont rserves lusage dans un environnement multi serveur de dpt.
En utilisant loption -d le paquet opsi sera copi dans le rpertoire /var/lib/opsi/repository du serveur cible
avant linstallation. Sil vous plat assurez-vous quil y a suffisamment despace libre sur ce systme de fichiers.
voir aussi:
#opsi-package-manager --help
usage: opsi-package-manager [options] <command>
Manage opsi packages
Commands:
-i, --install <opsi-package> ... install opsi packages
-u, --upload <opsi-package> ... upload opsi packages to repositories
-l, --list <regex> list opsi packages matching regex
-D, --differences <regex> show depot differences of opsi packages matching regex
-r, --remove <opsi-product-id> ... uninstall opsi packages
-x, --extract <opsi-package> ... extract opsi packages to local directory
-V, --version show programs version info and exit
-h, --help show this help message and exit
Options:
-v, --verbose increase verbosity (can be used multiple times)
-q, --quiet do not display any messages
--log-file <log-file> path to debug log file
-d, --depots <depots> comma separated list of depot ids to process
all = all known depots
-p, --properties <mode> mode for default product property values
ask = display dialog
package = use defaults from package
keep = keep depot defaults (default)
--purge-client-properties remove product property states of the installed product(s)
-f, --force force install/uninstall (use with extreme caution)

-U, --update set action "update" on hosts where installation status is "installed"
-S, --setup set action "setup" on hosts where installation status is "installed"
-o, --overwrite overwrite existing package on upload even if size matches
-k, --keep-files do not delete client data dir on uninstall
-t, --temp-dir <path> tempory directory for package install
--max-transfers <num> maximum number of simultaneous uploads
0 = unlimited (default)
--max-bandwidth <kbps> maximum transfer rate for each transfer (in kilobytes per second)
0 = unlimited (default)
--new-product-id <product-id> set a new product id when extracting opsi package
4.5 Outil: opsi-product-updater
Lutilitaire en ligne de commande opsi-product-updater est conu pour tlcharger et installer des paquets opsi
confortablement depuis un dpt ou dun autre serveur opsi. Lusage de opsi-product-updater rendre facile de main-
tenir le serveur opsi jour. Il peut tre galement utilis dans une tche cron pour garder le serveur de dpt en
synchronisation avec le serveur de configuration.
# opsi-product-updater --help
Usage: opsi-product-updater [options]

Options:
-h Show this help text
-v Increase verbosity (can be used multiple times)
-V Show version information and exit
-c Location of config file
Les caractristiques principales sont:

dpts paramtrables
actions paramtrables
Toute la configuration se fera dans le fichier de configuration /etc/opsi/opsi-product-updater.conf.
4.5.1 Dpts paramtrables
Les dpts sont les sources qui seront utilises par opsi-product-update pour rcuprer des nouveaux paquetages opsi
Il existe deux types de dpts:
Dpts Internet
Exemple: download.uib.de
Cela sont des dpts qui sont configurs par:
URL de base (dans lexemple http://download.uib.de)
rpertoires ( Une liste de rpertoires, par exemple: opsi4.0/produkte/essential)
et, si ncessaire, nom dutilisateur et mot de passe pour les dpts protgs par mot de passe (par exemple pour les
abonnements la gestion des correctifs opsi)
Vous pouvez galement configurer un proxy ici.
serveur opsi
Ceci est (utilisant un opsi-depotserver) la centrale opsi-configserver qui sera utilise pour rcuprer les paquets opsi.
Llment de configuration central est ici:
opsiDepotId
Cela, dans la plupart des cas sur un opsi-depotserver la centrale opsi-configserver. Donc sur tout appel de opsi-product-
updater le opsi-product-packages sera rcupr depuis opsi-configserver. Cela peut tre fait par exemple par une tche
cron.
4.5.2 Actions paramtrables
Pour chaque dpt, vous devez configurer les actions excuter:

autoupdate: Les nouvelles versions des paquets installs seront tlchargs et installs
autoinstall: Aussi des paquets qui ne sont pas encore install, seront tlcharg et install
autoinstall: Pour tous les nouveaux paquets installs et tous les clients sur lesquels ces paquets sont installs, la
demande daction sera mis configuration.
En outre, il est possible denvoyer tous ces clients un signal Wake-On-LAN pour installer le nouveau logiciel sur les
clients. En utilisant opsi-product shutdownwanted vous pouvez faire en sorte que les clients seront mis hors tension
aprs linstallation.
time window for autosetup: Vous pouvez attribuer une fentre de temps qui peut tre utilise par les demandes
daction des clients configurer.
Automatic WakeOnLan with shutdown: Sil y a un nouveau logiciel, les clients pourraient tre rveill et aprs
linstallation automatiquement arrt.
4.6 Outil: opsi-admin / opsi config interface
4.6.1 Prsentation
opsi V3 introduit une bibliothque en python, de proprit dopsi,qui fournit une API pour la configuration de opsi.
opsiconfd fournit cette API comme un service web, alors que opsi-admin est linterface en ligne de commande pour
cette API.
En appelant https://<opsi-server>:4447/votre navigateur vous offre une interface graphique pour le web service dopsi.
Vous devez vous connecter en tant que membre du groupe unix opsiadmin.
opsi config interface: Laccs au service web via un navigateur
Figure 35 opsi config interface: Laccs au service web via un navigateur
En ligne de commande opsi-admin fournit une interface opsi-API. Il y a un mode interactif et un mode non interactif
pour le traitement par lots partir de scripts.
Loption daide opsi-admin --help affiche une liste des options en ligne de commande qui sont disponibles :
# opsi-admin --help
Usage: opsi-admin [options] [command] [args...]

Options:
-h, --help Display this text
-V, --version Display this text
-u, --username Username (default: current user)
-p, --password Password (default: prompt for password)
-a, --address URL of opsiconfd (default: https://localhost:4447/rpc)
-d, --direct Do not use opsiconfd
--no-depot Do not use depotserver backend
-l, --loglevel Set log level (default: 3)
0=nothing, 1=essential, 2=critical, 3=error, 4=warning
5=notice, 6=info, 7=debug, 8=debug2, 9=confidential
-f, --log-file Path to log file
-i, --interactive Start in interactive mode
-c, --colorize Colorize output
-S, --simple-output Simple output (only for scalars, lists)
-s, --shell-output Shell output
opsi-admin peut utiliser le service web de opsi ou exploiter directement le backend des donnes. Pour travailler avec
le service web vous devez fournir lURL et un nom dutilisateur et mot de passe. Pour des raisons de scurit, vous
nauriez probablement pas envie de faire cela dans un script. Dans ce cas, vous prfreriez un accs direct la base de
donnes en utilisant loption -d: opsi-admin -d.
En mode interactif (commencent par opsi-admin -d ou opsi-admin -d -i -c ou opsi-admin -dic) vous obtenez
le support pour la saisie avec la touche TAB. Aprs quelques saisie, avec la touche TAB vous obtenez une liste ou les
dtails, du type de donnes de la prochaine saisie attendue.
Loption -s ou -S gnre un format de sortie qui peut tre facilement analys par des scripts.
Il y a quelques mthodes qui sont bases directement sur les requtes API, et il ya quelques tches, qui sont un
ensemble dappels de fonctions pour faire un travail spcial plus complexe.
4.6.2 Cas dutilisation typique
Dfinissez un produit pour la configuration (setup) pour tous les clients qui ont install ce produit
opsi-admin -d task setupWhereInstalled "softprod"
Liste de tous les clients
opsi-admin -d method host_getIdents
Supprimer un client
opsi-admin -d method host_delete <nom du client>
par exemple:
opsi-admin -d method host_delete "pxevm.uib.local"
Crer un client
opsi-admin -d method host_createOpsiClient <nom du client pleinement qualifi>
par exemple:
opsi-admin -d method host_createOpsiClient "pxevm.uib.local"
Dfinir une requte daction
opsi-admin -d method setProductActionRequest <Id du produit> <Id du client> <requte daction>
par exemple:
opsi-admin -d method setProductActionRequest win7 pxevm setup
Joindre la description du client
opsi-admin -d method setHostDescription "dpvm02.uib.local" , "Client sous VMware"

Dfinir le mot de passe de pcpatch
opsi-admin -d task setPcpatchPassword
Dfini le mot de passe de lutilisateur pcpatch pour le compte Unix, samba et opsi.
4.7 Processus serveur: opsiconfd et opsipxeconfd
opsipxeconfd fournit les named pipes dans les rpertoires tftpboot, qui sont utiliss pour contrler le processus de
dmarrage PXE.
Le fichier de configuration est /etc/opsi/opsipxeconfd.conf
Le fichier journal systme est /var/log/opsi/opsipxeconfd.log.
opsiconfd fournit les opsi API comme JSON service web et ont beaucoup dautres tches importantes. Par consquent
opsiconfd est le service central dopsi et fait tout la communication vers les clients.
En ce qui concerne cette rle centrale, un outil pour surveiller ce processus donne beaucoup dinformations sur la
charge et les problmes ventuelles. Cet outil est la page dinfo de opsiconfd.
4.7.1 opsiconfd monitoring: opsiconfd info
Utilisation de ladresse web https://<opsi-server>:4447/info vous obtiendrez un graphique de la charge et de lutili-

sation CPU/mmoire de opsiconfd dans la dernire heure/jour/mois/anne. Cette information est complte par des
informations tabulaires, des tches relles et des sessions.
opsiconfd info: Les valeurs de la dernire heure de opsiconfd
Figure 36 opsiconfd info: Les valeurs de la dernire heure de opsiconfd
opsiconfd info: les valeurs de la dernire journe de opsiconfd
Figure 37 opsiconfd info: les valeurs de la dernire journe de opsiconfd
5 Service web / mthodes de lAPI
5.1 Service web / Les mthodes API depuis opsi 4.0
5.1.1 Prsentation
Dans opsi 4 la structure des donnes de tous les backends et les mthodes de service web sont de conception totalement
nouvelle.
La nouvelle conception est oriente objet / base de donnes. Un objet a des proprits.
Comme exemple nous allons regarder lobjet product. Un objet de type product qui dcrit le produit javavm peut
ressembler ceci:
"ident": "javavm;1.6.0.20;2"
"id": "javavm"
"description": "Java 1.6"
"changelog": ""
"advice": ""
"userLoginScript": ""
"name": "SunJavaRuntimeEnvironment"
"priority": 0
"packageVersion": "2"
"productVersion": "1.6.0.20"
"windowsSoftwareIds": None
"productClassIds": None
"type": "LocalbootProduct"
"licenseRequired": False
"setupScript": "javavm.ins"
"updateScript": ""
"uninstallScript": "deljvm.ins"
"alwaysScript": ""
"onceScript": ""
"customScript": ""
Chaque objet a un ensemble doprateurs qui peuvent tre utilises pour travailler avec cet objet. La plupart du temps,
ces oprateurs sont:
getObjects (renvoie les objets)
getHashes (variante, qui offre pour des raisons de performances les objets du backend en lecture seule. Pour un
grand nombre dobjets cette mthode est beaucoup plus rapide de lappel getObjects)
create (crer un objet laise)
createObjects (crer un ou plusieurs objets)
delete (supprimer un objet)
deleteObjects (supprimer un ou plusieurs objets)
getIdents (renvoie lid de lobjet)
insertObject (crer un nouvel objet)
updateObject (mise jour dun objet, si lobjet nexiste pas il sera cr)
updateObjects (mise jour dun ensemble dobjets)
Les noms des mthodes sont concatns:
<nom objet>_<opration>
Selon cette rgle de nommage, ces nouvelles mthodes sont facilement diffrencis des anciens mthodes legacy de opsi
3, que commencent par get, set ou create.
Les mthodes getObjects ont deux paramtres facultatifs:
attributes
filter
Le paramtre attributes est utilis dans la requte uniquement pour certaines proprits dun objet. Si vous utilisez des
attributs lobjet retourn a toutes les cls dattributs, mais seulement des valeurs de lattribut que vous avez demand
et pour tous les attributs qui sont utiliss pour identifier cet objet. Tous les autres attributs ont la valeur none.
Par exemple, en appelant la mthode product_getObjects avec attributes:["name"] pour le produit javavm, vous ob-
tiendrez:
"onceScript": None,
"ident": "javavm;1.6.0.20;2",
"windowsSoftwareIds": None,
"description": None,
"setupScript": None,
"changelog": None,
"customScript": None,
"advice": None,
"uninstallScript": None,
"userLoginScript": None,
"name": "Sun Java Runtime Environment",
"priority": None,
"packageVersion": "2",
"productVersion": "1.6.0.20",
"updateScript": None,
"productClassIds": None,
"alwaysScript": None,
"type": "LocalbootProduct",
"id": "javavm",
"licenseRequired": None
Si vous souhaitez ne pas demander des attributs mais que vous voulez utiliser le second paramtre filter vous devez
donner comme paramtre dattribut [].
Le filtre de paramtre est utilis pour dfinir les objets que vous voulez obtenir. Par exemple si vous utilisez le filtre {
"id":"javavm" } sur la mthode product_getObjects vous aurez seulement lobjet(s) qui dcrit le produit javavm.
Si vous utilisez des mthodes qui attendent un ou plusieurs objets, ces objets doivent tre donns titre dobjets JSON
ou en tant que srie dobjets JSON.
Les objets les plus importants sont:
auditHardwareOnHost (informations sur le matriel client spcifique)
auditHardware (informations sur le matriel client indpendant)
auditSoftwareOnClient (informations sur les logiciels spcifiques du client)
auditSoftware (informations sur les logiciels indpendent du client)
auditSoftwareToLicensePool (gestion des licences)
configState (gestion des paramtres dhte du client)
config (administration des paramtres dhte par dfaut)
group (administration des groupes)
host (serveur et clients)
licenseContract (gestion des licences)
licenseOnClient (gestion des licences)
licensePool (gestion des licences)
objectToGroup (administration des groupes)
productDependency (dpendances du produit)
productOnClient (information sur les clients spcifiques un produit, par exemple ltat dinstallation)
productOnDepot (informations du dpt spcifiques un produit)
productPropertyState (dpt ou client spcifique, paramtres de proprit des produits)
productProperty (dfinition des proprits du produit)
product (mta-donnes du produit)
softwareLicenseToLicensePool (gestion des licences)
softwareLicense (gestion des licences)
En plus des objets et des mthodes dcrites il y a encore plus pour des oprations spciales.
Cette conception:
est cr pour la transmission rapide des informations sur un grand nombre de clients
filtrer les donnes par une syntaxe unifie
permettre de vrifier la syntaxe correcte de toutes les entres
Conformment ces donnes nous obtenons une stabilit et des performances accrues.
5.1.2 Les objets de stockage de donnes
host (serveur et clients)
Exemple pour un OpsiClient:

method host_getObjects [] {"id":"xpclient.vmnat.local"}

[
{
"ident" : "xpclient.vmnat.local",
"description" : "",
"created" : "2012-03-22 12:13:52",
"inventoryNumber" : "",
"ipAddress" : "172.16.166.101",
"notes" : "Created by opsi-deploy-client-agent at Wed, 24 Aug 2011 10:24:36",
"oneTimePassword" : "",
"lastSeen" : "2012-03-30 16:20:04",
"hardwareAddress" : "00:0c:29:35:70:a7",
"opsiHostKey" : "1234567890abcef1234567890abcdef",
"type" : "OpsiClient",
"id" : "xpclient.vmnat.local"
}
]
La plupart de ces donnes sont affiches dans longlet clients de opsi-configed.

Les types possibles sont:
OpsiClient
OpsiConfigserver (ce qui signifie implicitement que cest aussi un OpsiDepotserver)
OpsiDepotserver
Les types serveur ont des donnes diffrentes et supplmentaires.
Exemple pour un serveur:
method host_getObjects [] {"id":"sepiolina.vmnat.local"}
[
{
"masterDepotId" : null,
"ident" : "sepiolina.vmnat.local",
"networkAddress" : "172.16.166.0/255.255.255.128",
"description" : "",
"ipAddress" : "172.16.166.1",
"repositoryRemoteUrl" : "webdavs://sepiolina.vmnat.local:4447/repository",
"depotLocalUrl" : "file:///var/lib/opsi/depot",
"isMasterDepot" : true,
"notes" : "",
"hardwareAddress" : null,
"maxBandwidth" : 0,
"repositoryLocalUrl" : "file:///var/lib/opsi/repository",
"opsiHostKey" : "1234567890abcef1234567890abcdef",
"type" : "OpsiConfigserver",
"id" : "sepiolina.vmnat.local",
"depotWebdavUrl" : "webdavs://sepiolina:4447/depot",
"depotRemoteUrl" : "smb://sepiolina/opsi_depot"
}
]
La plupart de ces donnes sont affiches dans la configuration de dpt de opsi-configed.
group (ladministration des groupes)
Dcrit les groupes et leur structure hirarchique.

Exemple pour un objet de groupe:
method group_getObjects
[
{
"ident" : "sub2",
"description" : "sub2",
"notes" : "",
"parentGroupId" : null,
"type" : "HostGroup",
"id" : "sub2"
},
{
"ident" : "subsub",
"description" : "subsub",
"notes" : "",
"parentGroupId" : "sub2",
"type" : "HostGroup",
"id" : "subsub"
}
]
objectToGroup (ladministration des groupes)
Dcrit lappartenance dun objet dans un groupe.

On trouve Hostgroups et Productgroups
Exemple pour un objet objectToGroup:
method objectToGroup_getObjects
[
{
"groupType" : "HostGroup",
"ident" : "HostGroup;sub2;win7.vmnat.local",
"type" : "ObjectToGroup",
"groupId" : "sub2",
"objectId" : "win7.vmnat.local"
},
{
"groupType" : "HostGroup",
"ident" : "HostGroup;subsub;win7x64.vmnat.local",
"groupId" : "subsub",
"objectId" : "win7x64.vmnat.local"
},
{
"groupType" : "ProductGroup",
"ident" : "ProductGroup;opsiessentials;opsi-client-agent",
"groupId" : "opsiessentials",
"objectId" : "opsi-client-agent"
},
{
"groupType" : "ProductGroup",
"ident" : "ProductGroup;opsiessentials;opsi-winst",
"groupId" : "opsiessentials",
"objectId" : "opsi-winst"
}
]
product (les mta-donnes du produit)
Dcrit les mtadonnes dun produit qui sont dfinies lors de la cration du paquet.
Exemple pour un objet produit:
method product_getObjects [] {"id":"jedit","productVersion":"4.5"}
[
{
"onceScript" : "",
"ident" : "jedit;4.5;3",
"windowsSoftwareIds" :
[
],
"description" : "jEdit with opsi-winst Syntax-Highlighting",
"setupScript" : "setup.ins",
"changelog" : "",
"customScript" : "",
"advice" : "",
"uninstallScript" : "uninstall.ins",
"userLoginScript" : "",
"name" : "jEdit programmers text editor",
"priority" : 0,
"packageVersion" : "3",
"productVersion" : "4.5",
"updateScript" : "update.ins",
"productClassIds" :
[
],
"alwaysScript" : "",
"type" : "LocalbootProduct",
"id" : "jedit",
"licenseRequired" : false
}
]
Note
Si vous avez des serveurs de dpt multiple, vous pouvez avoir des versions diffrentes dun mme produit.
Les entres productClassIds et windowsSoftwareIds ne sont pas utiliss pour le moment.
productProperty (Dfinition des proprits du produit)
Dcrit les proprits dun produit qui sont dfinies lors de la cration du paquet.
Exemple pour un objet productProperty:
method productProperty_getObjects [] {"productId":"jedit","productVersion":"4.5"}
[
{
"ident" : "jedit;4.5;3;start_server",
"description" : "Should the jedit derver started at every startup ?",
"editable" : false,
"defaultValues" :
[
false
],
"multiValue" : false,
"possibleValues" :
[
false,
true
],
"type" : "BoolProductProperty",
"propertyId" : "start_server",
"productId" : "jedit"
}
]
Note
Les valeurs par dfaut relles sont stockes dans le contexte du dpt dans un objet productPropertyState.
productPropertyState (Paramtres de proprit des produits spcifiques au dpt ou aux clients)
Dcrit:
* la valeur par dfaut dune proprit du produit dans un dpt donn proprits dun produit qui sont dfinies lors
de la cration du paquet. * les paramtres spcifiques du client pour les proprits du produit.
Exemple pour un objet productPropertyState:
method productPropertyState_getObjects [] {"productId":"jedit"}
[
{
"ident" : "jedit;start_server;sepiolina.vmnat.local",
"objectId" : "sepiolina.vmnat.local",
"values" :
[
false
],
"type" : "ProductPropertyState",
},
{
"ident" : "jedit;start_server;xpclient.vmnat.local",
"objectId" : "xpclient.vmnat.local",
"values" :
[
true
],
"type" : "ProductPropertyState",
}
productDependency (dpendances du produit)
Dcrit les dpendances dun produit un autre produit tel quil est dfini lors de la cration du package.
Exemple pour un objet productDependency:
method productDependency_getObjects [] {"productId":"jedit","productVersion":"4.5"}
[
{
"ident" : "jedit;4.5;3;setup;javavm",
"productAction" : "setup",
"requiredPackageVersion" : null,
"requirementType" : "before",
"requiredInstallationStatus" : "installed",
"requiredProductId" : "javavm",
"requiredAction" : null,
"requiredProductVersion" : null,
"type" : "ProductDependency",
}
]
productOnClient (informations client spcifique un produit, par exemple ltat de linstallation)
Dcrit les produits dans lesquels versions sont installes sur lequel client..
Exemple pour un objet productOnClient:
method productOnClient_getObjects [] {"productId":"jedit","clientId":"xpclient.vmnat.local"}
[
{
"ident" : "jedit;LocalbootProduct;xpclient.vmnat.local",
"actionProgress" : "",
"actionResult" : "successful",
"clientId" : "xpclient.vmnat.local",
"modificationTime" : "2012-03-30 15:49:04",
"actionRequest" : "none",
"targetConfiguration" : "installed",
"productType" : "LocalbootProduct",
"lastAction" : "setup",
"actionSequence" : -1,
"type" : "ProductOnClient",
"installationStatus" : "installed",
}
]
productOnDepot (informations dpt spcifiques un produit)
Dcrit le produit qui est install et sa version sur un dpt donn..

Exemple pour un objet productOnDepot:
method productOnDepot_getObjects [] {"productId":"jedit"}
[
{
"ident" : "jedit;LocalbootProduct;4.4.1;2;depotserver.vmnat.local",
"locked" : false,
"productVersion" : "4.4.1",
"depotId" : "depotserver.vmnat.local",
"type" : "ProductOnDepot",
},
{
"ident" : "jedit;LocalbootProduct;4.5;3;sepiolina.vmnat.local",
"locked" : false,
"depotId" : "sepiolina.vmnat.local",
"type" : "ProductOnDepot",
}
]
Note
Si vous avez des serveurs de dpt multiple, vous pouvez avoir des versions diffrentes dun mme produit.
config (ladministration des valeurs par dfaut des paramtres hte)
Dcrit le paramtre hte de la Configuration serveur de opsi-configed.

Exemple pour un objet config:
method config_getObjects [] {"id":"opsiclientd.event_gui_startup.active"}
[
{
"ident" : "opsiclientd.event_gui_startup.active",
"description" : "gui_startup active",
"defaultValues" :
[
true
],
"editable" : false,
"multiValue" : false,
"possibleValues" :
[
false,
true
],
"type" : "BoolConfig",
"id" : "opsiclientd.event_gui_startup.active"
}
]
configState (ladministration des paramtres de lhte client)
Dcrit le paramtre hte de la configuration du client de opsi-configed.

Exemple pour un objet configState:
method configState_getObjects [] {"configId":"opsiclientd.event_gui_startup.active"}
[
{
"configId" : "opsiclientd.event_gui_startup.active",
"ident" : "opsiclientd.event_gui_startup.active;wanclient.vmnat.local",
"values" :
[
false
],
"objectId" : "wanclient.vmnat.local",
"type" : "ConfigState"
}
]
Note
Un objet configState ne peut tre cr sans objet un existant config auquel il fait rfrence.
auditHardwareOnHost (informations sur le matriel spcifique au client)
Dcrit les types de matriels dtects (y compris les valeurs spcifiques du client). Lide est que vous verrez ici les
donnes spcifiques du client et dans auditHardware une seule entre pour une carte rseau qui est utilis dans tous
vos ordinateurs.
Malheureusement, dans la ralit cette ide ne fonctionne pas comme vous pourriez le penser.
Exemple pour un objet auditHardwareOnHost:
method auditHardwareOnHost_getObjects [] {"hostId":"xpclient.vmnat.local","hardwareClass":"NETWORK_CONTROLLER","\
ipAddress":"172.16.166.101"}
[
{
"vendorId" : "1022",
"macAddress" : "00:0C:29:35:70:A7",
"hardwareClass" : "NETWORK_CONTROLLER",
"state" : 1,
"deviceType" : "PCI",
"subsystemVendorId" : "2000",
"ipEnabled" : "True",
"type" : "AuditHardwareOnHost",
"firstseen" : "2012-03-30 15:48:15",
"revision" : "10",
"hostId" : "xpclient.vmnat.local",
"vendor" : "Advanced Micro Devices (AMD)",
"description" : "Ethernetadapter der AMD-PCNET-Familie",
"subsystemDeviceId" : "1022",
"deviceId" : "2000",
"autoSense" : null,
"netConnectionStatus" : "Connected",
"maxSpeed" : null,
"name" : "Ethernetadapter der AMD-PCNET-Familie",
"serialNumber" : null,
"lastseen" : "2012-03-30 15:48:15",
"model" : null,
"ipAddress" : "172.16.166.101",
"adapterType" : "Ethernet 802.3"
},
{
"macAddress" : "00:0C:29:35:70:A7",
"state" : 0,
"ipEnabled" : "True",
"firstseen" : "2012-03-08 14:26:14",
"revision" : "10",
"vendor" : "VMware, Inc.",
"description" : "VMware Accelerated AMD PCNet Adapter",
"autoSense" : null,
"netConnectionStatus" : "Connected",
"maxSpeed" : null,
"name" : "VMware Accelerated AMD PCNet Adapter",
"serialNumber" : null,
"lastseen" : "2012-03-10 14:47:15",
"model" : null,
"ipAddress" : "172.16.166.101",
"adapterType" : "Ethernet 802.3"
},
{
"macAddress" : "00:0c:29:35:70:a7",
"state" : 0,
"deviceType" : null,
"ipEnabled" : null,
"firstseen" : "2012-02-29 15:43:21",
"revision" : "10",
"vendor" : "Advanced Micro Devices [AMD]",
"description" : "Ethernet interface",
"autoSense" : "",
"netConnectionStatus" : "yes",
"maxSpeed" : null,
"name" : "79c970 [PCnet32 LANCE]",
"serialNumber" : "00:0c:29:35:70:a7",
"lastseen" : "2012-03-30 14:58:30",
"model" : "79c970 [PCnet32 LANCE]",
"ipAddress" : "172.16.166.101",
"adapterType" : ""
}
]
auditHardware (informations sur le matriel client indpendant)
Dcrit les types de matriels dtects (indpendante des valeurs spcifiques du client). Lide est que vous verrez ici
une seule entre pour une carte rseau qui est utilis dans tous vos ordinateurs.
Malheureusement, dans la ralit cette ide ne fonctionne pas comme vous pourriez le penser.
Exemple pour un objet auditHardware:
method auditHardware_getObjects [] {"hardwareClass":"NETWORK_CONTROLLER","vendorId":"1022"}
[
{
"maxSpeed" : null,
"vendor" : "Advanced Micro Devices [AMD]",
"name" : "79c970 [PCnet32 LANCE]",
"deviceType" : null,
"autoSense" : "",
"model" : "79c970 [PCnet32 LANCE]",
"revision" : "10",
"type" : "AuditHardware",
"adapterType" : "",
"description" : "Ethernet interface"
},
{
"maxSpeed" : null,
"vendor" : "VMware, Inc.",
"name" : "VMware Accelerated AMD PCNet Adapter",
"autoSense" : null,
"model" : null,
"revision" : "10",
"adapterType" : "Ethernet 802.3",
"description" : "VMware Accelerated AMD PCNet Adapter"
},
{
"maxSpeed" : null,
"autoSense" : null,
"model" : null,
"revision" : "10",
"description" : "Ethernetadapter der AMD-PCNET-Familie"
},
{
"maxSpeed" : null,
"autoSense" : null,
"model" : null,
"revision" : "10",
},
{
"maxSpeed" : null,
"name" : null,
"autoSense" : null,
"model" : "",
"revision" : null,
"adapterType" : null,
},
(....)
[
auditSoftwareOnClient (informations sur les logiciels client spcifiques)
Dcrit les types de logiciels dtects (y compris les valeurs spcifiques du client). Lide est que vous verrez ici les
donnes spcifiques du client et dans auditSoftware une seule entre pour un logiciel de bureau qui est utilis dans
tous vos ordinateurs.
Exemple pour un objet auditSoftwareOnClient:
method auditSoftwareOnClient_getObjects [] {"name":"jEdit 4.5.0","clientId":"xpclient.vmnat.local"}
[
{
"ident" : "jEdit 4.5.0;4.5.0;;;x86;xpclient.vmnat.local",
"licenseKey" : "",
"name" : "jEdit 4.5.0",
"uninstallString" : "\\\"C:\\\\Programme\\\\jEdit\\\\unins000.exe\\\"",
"usageFrequency" : -1,
"clientId" : "xpclient.vmnat.local",
"lastUsed" : "0000-00-00 00:00:00",
"subVersion" : "",
"language" : "",
"state" : 1,
"version" : "4.5.0",
"lastseen" : "2012-03-30 16:19:55",

"binaryName" : "",
"type" : "AuditSoftwareOnClient",
"firstseen" : "2012-03-30 16:19:55",
"architecture" : "x86"
}
]
auditSoftware (informations sur les logiciels client indpendants)
Dcrit les types de logiciels dtects (indpendante des valeurs spcifiques du client). Lide est que vous verrez ici une
seule entre pour un logiciel de bureau qui est utilis dans tous vos ordinateurs.
Exemple pour un objet auditSoftware:
method auditSoftware_getObjects [] {"name":"jEdit 4.5.0"}
[
{
"windowsDisplayVersion" : "4.5.0",
"ident" : "jEdit 4.5.0;4.5.0;;;x64",
"name" : "jEdit 4.5.0",
"windowsSoftwareId" : "jedit_is1",
"windowsDisplayName" : "jEdit 4.5.0",
"installSize" : -1,
"subVersion" : "",
"language" : "",
"version" : "4.5.0",
"architecture" : "x64",
"type" : "AuditSoftware"
},
{
"windowsDisplayVersion" : "4.5.0",
"ident" : "jEdit 4.5.0;4.5.0;;;x86",
"name" : "jEdit 4.5.0",
"windowsSoftwareId" : "jedit_is1",
"windowsDisplayName" : "jEdit 4.5.0",
"installSize" : -1,
"subVersion" : "",
"language" : "",
"version" : "4.5.0",
"type" : "AuditSoftware"
}
]
auditSoftwareToLicensePool (gestion des licences)
Dcrit les regroupements de licences assigns quels motifs auditSoftware.

Exemple pour un objet auditSoftwareToLicensePool:
method auditSoftwareToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"}
[
{
"ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x64;win7-msdn-prof",
"name" : "Windows 7 Professional N",
"language" : "de-DE",
"subVersion" : "00376-165",
"licensePoolId" : "win7-msdn-prof",
"version" : "6.1",
"type" : "AuditSoftwareToLicensePool"
},
{
"ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x86;win7-msdn-prof",

"name" : "Windows 7 Professional N",
"language" : "de-DE",
"subVersion" : "00376-165",
"version" : "6.1",
"type" : "AuditSoftwareToLicensePool"
}
]
softwareLicenseToLicensePool (gestion des licences)
Dcrit quels softwareLicenseId est affecte quels licensePoolId.

Exemple pour un objet softwareLicenseToLicensePool:
method softwareLicenseToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"}
[
{
"softwareLicenseId" : "uib-msdn-win7-vol",
"ident" : "uib-msdn-win7-vol;win7-msdn-prof",
"licenseKey" : "12345-12345-12345-12345-3dbv6",
"type" : "SoftwareLicenseToLicensePool"
}
]
softwareLicense (gestion des licences)
Dcrit les licences logicielles existantes et leurs mta-donnes.

Exemple pour un objet softwareLicense:
method softwareLicense_getObjects [] {"id":"uib-msdn-win7-vol"}
[
{
"ident" : "uib-msdn-win7-vol;msdn-uib",
"maxInstallations" : 0,
"boundToHost" : null,
"expirationDate" : "0000-00-00 00:00:00",
"licenseContractId" : "msdn-uib",
"type" : "VolumeSoftwareLicense",
"id" : "uib-msdn-win7-vol"
}
]
licenseContract (gestion des licences)
Dcrit les contrats de licences existants et leurs mta-donnes.

Exemple pour un objet licenseContract:
method licenseContract_getObjects [] {"id":"msdn-uib"}
[
{
"ident" : "msdn-uib",
"description" : "",
"conclusionDate" : "2011-04-22 00:00:00",
"notificationDate" : "0000-00-00 00:00:00",
"notes" : "",
"expirationDate" : "0000-00-00 00:00:00",
"partner" : "Microsoft",
"type" : "LicenseContract",
"id" : "msdn-uib"
}
]
licenseOnClient (gestion des licences)
Dcrit quel licence est utilis par quel client.

Exemple pour un objet licenseOnClient:
method licenseOnClient_getObjects [] {"clientId":"win7client.vmnat.local"}
[
{
"softwareLicenseId" : "uib-msdn-win7-vol",
"ident" : "uib-msdn-win7-vol;win7-msdn-prof;win7client.vmnat.local",
"licenseKey" : "12345-12345-12345-12345-3dbv6",
"notes" : "",
"clientId" : "win7client.vmnat.local",
"type" : "LicenseOnClient"
}
]
licensePool (gestion des licences)
Dcrit le pool de licences et quel produit opsi est attribue.

Exemple pour un objet licensePool:
method licensePool_getObjects [] {"id":"win7-msdn-prof"}
[
{
"ident" : "win7-msdn-prof",
"type" : "LicensePool",
"description" : "MSDN Keys",
"productIds" :
[
"win7",
"win7-x64"
],
"id" : "win7-msdn-prof"
}
]
5.1.3 Les objets spciaux
Note
Ce chapitre doit tre crit
5.2 Les mthodes opsi3
Ces mthodes sont encore disponibles en tant que anciennes mthodes, ce qui signifie que les appels ces mthodes
sont mappes aux nouvelles mthodes en interne.
Voici une courte liste de certaines mthodes avec une courte description. Ceci est principalement conu pour lorien-
tation et non pas comme une rfrence complte. La courte description ne doit pas ncessairement fournir toutes les
informations dont vous avez besoin pour utiliser cette mthode.
method addHardwareInformation hostId, info
Ajoute des informations sur le matriel de lordinateur <hostid>. Le hachage de <info> est pass. Les informations
existantes seront crases pour la correspondance des cls. Applicable uniquement pour les cls spciales.
method authenticated
Prouver si lauthentification sur le serveur a russi.

method checkForErrors
Test du backend pour la cohrence ( prsent uniquement disponible pour les fichiers backend).
method createClient clientName, domain, description=None, notes=None
Cre un nouveau client.

method createGroup groupId, members = [], description = ""
Cre un groupe de clients (tel quutilis par the opsi-Configed).

method createLicenseKey productId, licenseKey
Assigne une cl de licence (supplmentaires) pour le produit <productId>.

method createLocalBootProduct productId, name, productVersion, packageVersion, licenseRequired=0, setupScript="", \
uninstallScript="", updateScript="", alwaysScript="", onceScript="", priority=10, description="", advice="", \
productClassNames=(localBoot)
Cre un nouveau produit localBoot (produit opsi-winst).

method createNetBootProduct productId, name, productVersion, packageVersion, licenseRequired=0, setupScript="", \
productClassNames=(netboot)
Cre un nouveau produit netBoot (image de dmarrage).

method createOpsiBase
Pour usage interne, seulement avec le backend LDAP.

method createProduct productType, productId, name, productVersion, packageVersion, licenseRequired=0,setupScript="", \
productClassNames=""
Cre un nouveau produit.

method createProductDependency productId, action, requiredProductId="", requiredProductClassId="", requiredAction="", \
requiredInstallationStatus="", requirementType=""
Cre des dpendances du produit.

method createProductPropertyDefinition productId, name, description=None, defaultValue=None, possibleValues=[]
Cre les proprits du produit.

method createServer serverName, domain, description=None
Cre un nouveau serveur dans le backend LDAP.

method createServerProduct productId, name, productVersion, packageVersion, licenseRequired=0,setupScript="", \
productClassNames=(server)
Pas encore implment pour une utilisation future.

method deleteClient clientId
Supprime un client.
method deleteGeneralConfig objectId
Supprime une configuration client ou une configuration de domaine.

method deleteGroup groupId
Supprime un groupe de clients.

method deleteHardwareInformation hostId
Supprime toutes les informations sur le matriel de lordinateur <hostid>.

method deleteLicenseKey productId, licenseKey
Supprime une cl de licence pour le produit <productId>.

method deleteNetworkConfig objectId
Supprime la configuration rseau (Par exemple lentre dpt de partage) pour un client ou un domaine.
method deleteOpsiHostKey hostId
Supprime un pckey de la base de donnes pckey.

method deleteProduct productId
Supprime un produit de la base de donnes.

method deleteProductDependency productId, action, requiredProductId="", requiredProductClassId="", requirementType=""
Supprime les dpendances du produit.

method deleteProductProperties productId *objectId
Supprime toutes les proprits dun produit.

method deleteProductProperty productId property *objectId
Supprimer une seule proprit du produit.

method deleteProductPropertyDefinition productId, name
method deleteProductPropertyDefinitions productId
Supprime une seule proprit ou toutes les proprits du produit <productId>.

method deleteServer serverId
Supprime une configuration de serveur

method exit
Quitter opsi-admin.
method getBackendInfos_listOfHashes
Fournit des informations sur les backends disponibles sur le serveur de dpt opsi et qui dentre eux sont activs.
method getBootimages_list
Fournitures la liste des images de dmarrage disponibles.

method getClientIds_list serverId = None, groupId = None, productId = None, installationStatus = None, actionRequest = \
None
Fournit une liste de clients qui rpondent aux critres affects.

method getClients_listOfHashes serverId = None, groupId = None, productId = None, installationStatus = None, \
actionRequest = No
Fournit une longue liste de clients qui rpondent aux critres affects (avec la description, des notes et vu la dernire
fois pour chaque client).
method getDefaultNetBootProductId clientId
Fournit le produit netboot (par exemple: logiciel systme) qui sera install lorsque limage de dmarrage install est
attribu.
method getDomain hostId
Fournit le domaine.
method getGeneralConfig_hash objectId
Fournit la configuration gnrale dun client ou dun domaine.

method getGroupIds_list
Fournit la liste des groupes de clients enregistrs.

opsi-admin -d -S method auditHardwareOnHost_getObjects [] {"hostId":"<hostId"}
Fournit les informations matriel de lordinateur spcifi.

method getHostId hostname
Fournit lID hte du nom dhte spcifi.

method getHost_hash hostId
Liste des proprits de lordinateur spcifi.

method getHostname hostId
Fournit le nom dhte de lID hte spcifi.

method getInstallableLocalBootProductIds_list clientId
Fournit une liste de tous les produits localBoot qui pourraient tre installs sur le client.
method getInstallableNetBootProductIds_list clientId
Fournit une liste de tous les produits netBoot qui pourraient tre installs sur le client.
method getInstallableProductIds_list clientId
Fournit une liste de tous les produits qui pourraient tre installs sur le client.
method getInstalledLocalBootProductIds_list hostId
Fournit une liste de tous les produits localBoot qui sont installs sur le client.
method getInstalledNetBootProductIds_list hostId
Fournit une liste de tous les produits netBoot products qui sont installs sur le client ou sur le serveur.
method getInstalledProductIds_list hostId
Fournit une liste des produits installs pour un client ou un serveur.

method getIpAddress hostId
Fournit ladresse IP dun hte.

method getLicenseKey productId, clientId
Fournit une cl de licence disponibles du produit spcifi ou la cl de licence du produit qui est attribu au client.
method getLicenseKeys_listOfHashes productId
Fournit une liste de toutes les cls de licence pour le produit spcifi.
method getLocalBootProductIds_list
Fournit une liste de tous les produits localBoot connus (par exemple dans larbre LDAP).
method getLocalBootProductStates_hash clientIds = []
Fournit, pour tous les clients, ltat de linstallation et la requte daction de tous les produits localBoot.
method getMacAddresses_list hostId
Fournit ladresse MAC de lordinateur spcifi.

method getNetBootProductIds_list
Fournit une liste de tous les produits NetBoot.

method getNetBootProductStates_hash clientIds = []
Fournit pour tous les clients ltat de linstallation et la requte daction de tous les produits netBoot.
method getNetworkConfig_hash objectId
Fournit les configurations rseau spcifiques dun client ou dun domaine.

method getOpsiHostKey hostId
Fournit le pckey de lID hte spcifi.

method getPcpatchPassword hostId
Fournit le mot de passe pcpatch (crypt avec la pckey de hostId).

method getPossibleMethods_listOfHashes
Fournit la liste des mthodes appelables (approximativement comme dans ce chapitre).

method getPossibleProductActionRequests_list
Affiche la liste des demandes daction disponibles dans opsi.

method getPossibleProductActions_hash
Fournit les actions disponibles pour chaque produit (setup, deinstall , . . . .).
method getPossibleProductActions_list productId=softprod
Fournit la liste de toutes les actions (setup, deinstall,. . . .).

method getPossibleProductInstallationStatus_list
Fournit la liste de tous les tats dinstallation (installed, not_installed,. . . )

method getPossibleRequirementTypes_list
Fournit la liste des types dexigence du produit (before, after, . . . )

method getProductActionRequests_listOfHashes clientId
Fournit la liste des actions venir du client spcifie.

method getProductDependencies_listOfHashes productId = None
Fournit la liste des dpendances de tous les produits ou du produit spcifi.

method getProductIds_list productType = None, hostId = None, installationStatus = None
Fournit une liste de produits qui rpondent aux critres spcifis.

method getProductInstallationStatus_hash productId, hostId
Fournit ltat de linstallation pour le client et le produit spcifie.

method getProductInstallationStatus_listOfHashes hostId
Fournit ltat de linstallation du client spcifi.

method getProductProperties_hash productId, objectId = None
Fournit les proprits du produit pour le produit et le client spcifi.

method getProductPropertyDefinitions_hash
Fournit toutes les proprits connus du produit avec la description, les valeurs admises,. . .
method getProductPropertyDefinitions_listOfHashes productId
Fournit les proprits produit du produit spcifi avec la description, les valeurs admises,. . . .
method getProductStates_hash clientIds = []
Fournit ltat de linstallation et la requte daction de tous les produits (pour les clients spcifi).
method getProduct_hash productId
Fournit les mta-donnes du produit (description, version, . . . )

method getProvidedLocalBootProductIds_list serverId
Fournit une liste de produits localBoot disponibles sur le serveur spcifi.

method getProvidedNetBootProductIds_list serverId
Fournit une liste de produits netBoot disponibles sur le serveur spcifi.

method getServerId clientId
Fournit la opsi-configserver charge du client spcifie.

method getServerIds_list
Fournit une liste des opsi-configserver connus.

method getServerProductIds_list
Fournit une liste des produits serveur.

method getUninstalledProductIds_list hostId
Fournit la liste des produits qui sont dsinstalls.

method powerOnHost mac
Envoyer un signal WakeOnLAN ladresse MAC spcifie.

method setBootimage bootimage, hostId, mac=None
Dfinir une image de dmarrage pour le client spcifi.

method setGeneralConfig config, objectId = None
Dfinir la GeneralConfig pour un client ou un domaine.

method setHostDescription hostId, description
Dfinir une description pour un client.

method setHostLastSeen hostId, timestamp
Rgler lhorodatage vu la dernire fois dun client.

method setHostNotes hostId, notes
Dfinir les notes pour un client.

method setMacAddresses hostId, macs
Dfinir ladresse MAC du client dans la base de donnes.

method setNetworkConfig objectId, serverId=, configDrive=, configUrl=, depotDrive=, depotUrl=, utilsDrive=,\
utilsUrl=, winDomain=, nextBootServiceURL=
Dfinir le rseau de donnes spcifi pour opsi-client-agent pour un client.

method setOpsiHostKey hostId, opsiHostKey
Dfinir le pckey pour un ordinateur.

method setPXEBootConfiguration hostId *args
Dfinir le pipe pour le dmarrage PXE avec *args dans append-List.

method setPcpatchPassword hostId password
Dfinir le mot de passe crypt(!) pour hostId

method setProductActionRequest productId, clientId, actionRequest
Dfinir une requte daction pour le client et le produit spcifis.

method setProductInstallationStatus productId, hostId, installationStatus, policyId="", licenseKey=""
Dfinir un tat de linstallation pour le client et le produit spcifis.

method setProductProperties productId, properties, objectId = None
Dfinir les proprits de produit pour le produit spcifi (et le client spcifi).
method unsetBootimage hostId
Annuler le dmarrage de limage de boot pour le client spcifi.

method unsetPXEBootConfiguration hostId
Supprimer le pipe pour le dmarrage PXE.

method unsetProductActionRequest productId, clientId
Dfinir action request none.
5.3 Les extensions backend
Dans opsi 4 nous avons la possibilit dtendre les mthodes de base de opsi 4 avec ses propres mthodes supplmentaires
qui utilisent les mthodes de base de opsi 4. Ceci est fait par exemple pour mettre en uvre les mthodes hrits de
opsi 3 ou pour crer des mthodes qui sadapte mieux aux besoins de opsi-configed.
Ces extenstions doivent tre rdig en code Python dans le rpertoire /etc/opsi/backendManager/extend.d.
6 Activation des modules non libres
Mme si opsi est open source, il y a certains composants qui ne sont pas libres ce moment. ce moment (Mai 2011)
les composantes suivantes de opsi ne sont pas libres:
gestion des licences
backend MySQL pour les donnes de configuration
le support pour les groupes de clients hirarchiss
lextension WAN/VPN
la haute disponibilit et la rpartition de charge (pas encore implment)
Logiciels la demande
Ces composants sont dvelopps dans un projet de co-financement ce qui signifie que jusqu ce que les cots de
dveloppement complet sont pays par les co-financeurs, leurs utilisation est seulement autoris aux les co-financeurs
ou des fins dvaluation. Une fois que les cots de dveloppement seront gagn nous allons donner ces modules
tout le monde gratuitement. Pour contrler lutilisation de ces composants jusqu ce quils soient libre il y a un fichier
dactivation /etc/opsi/modules, qui est protg contre les modifications via la signature lectronique. Si ce fichier
dactivation nexiste pas, seulement les parties libre de opsi fonctionneront.
Si vous avez besoin pour lvaluation un fichier dactivation temporaire valide contactez info@uib.de. Si vous devenez
un cofinanceur, vous obtiendrez un fichier dactivation illimite. Copiez ce fichier en tant que root dans /etc/opsi/
modules. Si cela est fait, excutez:
opsi-setup --set-rights /etc/opsi
Vous pouvez vrifier votre tat dactivation avec lune des mthodes suivantes:
Utilisant opsi-configed choisissez le menu Help/opsi-Module qui vous montre une fentre avec ltat dactivation.
Display of activation state in opsi-configed
Figure 38 Affichage de ltat dactivation dans opsi-configed
En ligne de commande vous pouvez utiliser la commande opsi-admin avec la mthode backend_info. (Remarque:
Ne donnez jamais votre fichier dactivation ou la sortie de cette commande des tierces personnes sans supprimer la
signature).
opsi-admin -d method backend_info
{
"opsiVersion" : "3.99.0.0",
"modules" :
{
"customer" : "uib GmbH",
"vista" : true,
"vpn" : true,
"license_management" : true,
"expires" : "never",
"valid" : true,
"multiplex" : true,
"signature" : "Ceci nest pas une signature authentique",
"treeview" : true,
"mysql_backend" : true
}
}
7 opsi-client-agent
7.1 Prsentation
Pour rendre la distribution de logiciels grable pour ladministrateur systme, un ordinateur client doit remarquer que
les paquets de nouveaux logiciels ou mises jour sont disponibles et les installer sans linteraction de lutilisateur. Il
est important de rendre linteraction de lutilisateur compltement obsoltes, comme linstallation peut fonctionner
sans surveillance, et que lutilisateur ne puisse pas arrter linstallation.
Ces exigences sont mises en uvre dans opsi par le opsi-client-agent:
Du ct du client le service opsiclientd examine habituellement au moment du dmarrage, avant que lutilisateur se
connecte, si une mise jour doit tre install pour ce client.
Sil y a des paquets logiciels installer sur le client, le programme de traitement de script opsi-winst est mis en marche
pour faire le travail dinstallation. Le serveur fournit tous les scripts et fichiers dinstallation de logiciels sur un partage
de fichiers. ce moment lutilisateur na aucune chance dinterfrer avec le processus dinstallation.
En option, le module supplmentaire loginblocker peut tre install pour empcher une connexion de lutilisateur avant
que la fin de la procdure dinstallation est atteinte.
Avant que tout logiciel puisse tre install avec le programme opsi-winst, il doit tre prpar comme un opsi-product-
package. Pour plus de dtails voir le chapitre Lintgration des nouveaux paquets logiciels dans le dploiement de
logiciels opsi depuis le manuel getting started.
7.2 Rpertoires de the opsi-client-agent
opsi-client-agent est install dans %ProgramFiles%\opsi.org\opsi-client-agent.

Ce rpertoire contient tous les programmes de opsi-client-agent comme par exemple opsiclientd, opsiclientd noti-
fier, opsi-winst et des bibliothques ncessaires. Vous trouverez ici aussi les fichiers de configuration et les modles
graphiques (skins) des programmes mentionns.
Le rpertoire %ProgramFiles%\opsi.org\opsi-client-agent est protg contre toute manipulation par les utilisa-
teurs sans privilges dadministrateur.
Le rpertoire %ProgramFiles%\opsi.org\opsi-client-agent\opsiclientd contient le fichier de configuration de
opsiclientd et vous avez besoin des privilges dadministrateur pour le lire.
Il y a aussi le rpertoire c:\opsi.org.
Ce rpertoire est utilis (pour le moment) pour mettre en cache les fichiers dinstallation et les donnes (voir lextension
WAN). A lavenir, il aura encore plus de fonctions contenant des fichiers journaux.
Vous devez disposer de privilges dadministrateur pour lire le rpertoire c:\opsi.org.
Vous trouverez les fichiers de log de opsi-client-agent dans c:\tmp.
7.3 Le service: opsiclientd
opsiclientd est le cur de opsi-client-agent. opsiclientd dbute au moment du dmarrage et sexcute avec des privilges
dadministrateur.
Les caractristiques importantes sont:
Le contrle bas sur lvnement:
Lactivit de lagent client opsi (opsiclientd) peut tre dclenche par diffrents vnements dans le systme client.
Daprs cet tat de fait, le dbut de linstallation peut tre dclenche par le systme de dmarrage dvnements
ou peut tre configur pour tre dclench par dautres systmes dvnements.
Contrle via le service web:
Cette interface est utilise pour pousser les installations et aussi des fins de maintenance.
La configuration distance:
Les donnes de configuration pour les clients peuvent tre modifies (globalement ou spcifique au client) sur le
serveur en ditant le Host parameters.
opsi-client-agent est constitu de plusieurs composants :
opsiclientd: le principal service
opsiclientd notifier: fentre dinformation et de communication
opsi-login-blocker: bloque la connexion de lutilisateur jusqu ce que linstallation est termine
7.3.1 Installation
En cas dinstallation automatique du systme dexploitation avec opsi (pas bas sur une image), opsi-client-agent sera
install automatiquement.
Vous pouvez dfinir la demande daction uninstall pour dsinstaller opsi-client-agent.
Pour une installation ultrieure sur un systme Windows existant ou des fins de rparation voir le manuel getting
started. Section 7.5.
7.3.2 opsiclientd
Composante essentielle de opsi-client-agent est le service opsiclientd. Ce service sexcute au moment du dmarrage.
opsiclientd a les tches suivantes:
Tandis que le systme dmarre et opsiclientd est en attente de linterface graphique, block_login_notifier est lanc
et affiche un cadenas dans le coin suprieur droit de lcran.
Mise en action si lvnement de configuration a lieu. Dans le cas dune action opsiclientd contacte le serveur opsi
via le service web (JSON-RPC) et demande les donnes de configuration et les actions requises.
Lvnement par dfaut est gui_startup qui se dclenche au moment du dmarrage avant le login utilisateur.
Cre un canal de communication nomm qui est utilis par opsi-login-blocker pour demander via JSON-RPC
opsiclientd quand dbloquer la connexion.
Dmarrer opsiclientd notifier comme un fil dinformation et dinteraction avec lutilisateur.
Si ncessaire, il se connecte opsi-depot pour mettre jour linstallation locale de opsi-winst et puis il commence
traiter les action requests (Installations de paquets logiciels).
7.3.3 opsiclientd notifier
opsiclientd notifier met en oeuvre linteraction avec lutilisateur. Il affiche des messages dtat et peut donner la
possibilit dinteragir avec le processus.
Il existe diffrentes situations o opsiclientd notifier deviendra actif de diffrentes faons:
blocking notifier
Indique que opsi-login-blocker bloque la connexion.
Figure 39 opsiclientd notification blocklogin
event notifier
Affiche des informations sur lvnement en cours.
Figure 40 opsiclientd notification vnement
action notifier
Montre ltat de traitement de lvnement.
Figure 41 opsiclientd notification de laction
shutdown notifier
Donne des informations sur le redmarrage / arrt demand. (si shutdown_warning_time > 0)
Figure 42 opsiclientd notification darrt
Attention
Les noms et les fonctions de notification ont chang de opsi 4.0 opsi 4.0.1.
Le notificateur dvnement de opsi 4.0 nexiste plus.
Le notificateur dvnement de opsi 4.0.1 est gal au notifiant daction de opsi 4.0.
Le notificateur daction de opsi 4.0.1 a presque la mme fonctionnalit du notificateur dvnement de opsi 4.0,
mais il ne sera activ que sil existe une action request.
7.3.4 opsi-login-blocker
opsi-login-blocker pour NT5 (Win2K/WinXP) est mis en oeuvre en tant que GINA (opsigina.dll). GINA attend jusqu
ce que les rapports opsiclientd, que tous product actions sont termins ou, si opsiclientd nest pas joignable, jusqu
ce que le dlai dattente de connexion opsiclientd est atteint (normalement 120 secondes). Puis le contrle intgral
est transmis lautre GINA, qui est normalement msgina.dll.
opsi-login-blocker pour NT6 (Vista/Win7) est mis en oeuvre en tant que filtre fournisseur dinformations didentifica-
tion (OpsiLoginBlocker.dll). Ce "filtre fournisseur dinformations didentification" bloque tous les credential providers
jusqu ce que les rapports opsiclientd, que tous product actions sont termins ou, si opsiclientd nest pas joignable,
jusqu ce que le dlai dattente de connexion opsiclientd est atteint (normalement 120 secondes).
7.3.5 Droulement du processus
Le fonctionnement de opsiclientd peut tre configur dans de nombreux dtails. Pour comprendre ces options de
configuration, il est ncessaire de comprendre la squence de traitement. Voici un aperu du flux de travail dun
standard event comme event_gui_startup.
Figure 43 flux de travail simplifi dun standard event
Les paramtres les plus importants ont les relations suivantes:
ASTUCE
Sil y a une erreur lors de la connexion opsi-configserver, les logs de ces problmes ne peuvent pas tre envoys au
serveur. Mais vous pouvez trouver les logs dans le fichier journal locale opsiclientd.log dans le rpertoire des journaux
(c:\tmp) sur le client.
1. Si un vnement se dclenche, event_notifier_command est lanc.

Maintenant, opsiclientd essaie datteindre opsi-configserver en utilisant ladresse url.
Si, aprs user_cancelable_after secondes il nexiste toujours pas de connexion tablie, alors opsiclientd notifier
activera un bouton abandonner. Si aucune connexion na pu tre tablie dans connection_timeout secondes, le
processus de connexion opsiclientd sera interrompue et lvnement se terminera par un message derreur. Pour
viter linterruption de la part de lutilisateur, rglez user_cancelable_after = connection_timeout .
2. Aprs une connexion russie au opsi-configserver, opsiclientd vrifie sil y a une action requests pour ce client.
Si il y a des action requests et action_warning_time > 0, action_notifier_command sera excut.
Cest normalement opsiclientd notifier, qui affiche maintenant la liste des action requests pour ce client pendant
action_warning_time secondes.
Si action_warning_time = 0 (par dfaut) alors action_notifier_command ne sera pas excut.
Vous pouvez permettre lutilisateur de suspendre le processus en ce moment en mettant action_user_cancel

able >= 0. Lutilisateur peut suspendre les actions jusqu action_user_cancelable fois. Apres action_user
_cancelable suspensions en squence ou si action_user_cancelable = 0 lutilisateur nobtient pas la facult
de suspendre les actions.
Dans tous les cas, il y aura un bouton qui permettra lutilisateur de dmarrer les installations immdiatement,
sans attendre le dcompte des action_warning_time secondes. Les messages affichs par opsiclientd notifier peut
tre configur avec les options action_message ou action_message[lang] . Ces messages peuvent contenir des
espaces rservs %action_user_cancelable% (nombre total de permission de suspensions) et %action_cancel
_counter% (nombre de suspensions dj utiliss par lutilisateur).
Si les actions ne sont pas suspendues par lutilisateur, action_cancel_counter se rinitialise et opsi-winst est
excute pour le traitement de action requests.
3. Si opsi-winst se termine par une demande de redmarrage ou darrt, shutdown_notifier_command sera excut
si shutdown_warning_time > 0.
shutdown_notifier_command montre pendant shutdown_warning_time secondes un message indiquant que le
client va tre redmarr. Si shutdown_user_cancelable > 0 lutilisateur peut suspendre le redmarrage jusqu
shutdown_user_cancelable fois en squence. Si lutilisateur suspend le redmarrage, shutdown_notifier_c
ommand sera redmarr aprs shutdown_warning_repetition_time. shutdown_notifier_command affiche un
message qui peut tre configur par shutdown_warning_message ou shutdown_warning_message[lang]. Ce
message peut contenir les espaces rservs %shutdown_user_cancelable% (nombre maximum de permission de
suspensions) et %shutdown_cancel_counter% (nombre de suspensions dj fait par lutilisateur).
Si le client est redmarr (par lutilisateur ou opsi-client-agent) %shutdown_cancel_counter% sera rinitialis.
ASTUCE
La squence de traitement des vnements et actions de lutilisateur sont visualises sous forme de graphique chronologique
la page dinformation de opsiclientd.
(Section 7.3.8).
Figure 44 le flux de travail complt dun vnement

7.3.6 Configuration
Configuration de diffrents vnements
Pour rpondre aux exigences des diffrentes situations dans lesquelles opsi-client-agent devient actif, une configuration
un peu complexe est ncessaire. Afin de rduire la complexit, le fichier de configuration utilise quelque chose comme
hritage.
Dans lentte de la section de configuration de opsiclientd par exemple [event_<config-id>] introduit une nouvelle
section de configuration des vnements. Une configuration dvnement peut tre dsactive en rglant loption de
section active =false.
Il existe diffrents types de configurations dvnements (type).
Il y a event configuration templates (type = template).
Les configurations dvnements peuvent hriter les configurations dun autre vnement. Dans ce cas, loption super
points lautre vnement pour hriter de tous ses paramtres ( lexclusion du paramtre active). Ces paramtres
hrits peuvent tre remplaces par des paramtres locaux dans la section vnement en cours. Donc une section
vnement a besoin uniquement des paramtres qui sont diffrents de lvnement super.
Le rglage dun vnement active =false ne change rien dans le processus dhritage.
Les autres types dvnements sont:
gui startup
Un vnement gui startup dbute lors du dmarrage du client et le chargement de linterface graphique utilisateur
(GUI). Cest lvnement le plus utilis, dfinie comme active dans la configuration par dfaut.
custom
Les configurations dvnement du type custom sont dclenchs par un vnement wql. Un vnement wql est
dfini par la dclaration correspondante wql dans la configuration des vnements. Si la dclaration wql est vide,
lvnement ne sera jamais dclench, mais peut tre excute partir de linterface Web interactive.
user login
sera dclenche lors de la connexion dun utilisateur.
timer
sera dclenche toutes les interval secondes.
sync completed
sera dclenche si la synchronisation des configurations (sync_config_from_server) ou des produits (cache_pr
oducts) est complt.
sw on demand
sera dclenche par lutilisateur choisissant Dmarrer les actions maintenant dans la page Web software-on-
demand de opsiclientd. Elle ne sera jamais dclenche si software-on-Demand nest pas utilis.
Il y a des Preconditions
Preconditions dfinit des tats spciaux du systme (par exemple un utilisateur est connect). Dans la configuration
de opsiclientd une entte de section de la forme [precondition_<precondition-id>] dbute la dclaration dune
Precondition. Une Precondition est vrai, si toutes les options dclares sont vraies. Une option non dclare (mais
possible) est suppos comme vraie.
Les options possibles pour Preconditions sont:
user_logged_in: est vrai si un utilisateur est actuellement connect.
config_cached: est vrai si la mise en cache des donnes de configuration est termine (voir: sync_config_from
_server).
products_cached: est vrai si la mise en cache des fichiers du produit est termine (voir: cache_products).
Une Precondition peut tre affect une configuration dvnement.
Si il y a une Precondition dans un entte de configuration des vnements, il doit galement avoir une configuration
pour cet vnement sans precondition. La configuration des vnements avec condition pralable hrite de tous les
paramtres de la configuration des vnements sans precondition.
Si lvnement est dclench, dabord, il sera vrifi que preconditions sont vraies. Sil ny a pas de precondition
vraie, la configuration sans precondition est utilis. Si une precondition est vraie, la configuration utilis est li
cette precondition. Si plus dune des preconditions sont vraies, la configuration dvnement la plus spcifique est
utilise (qui est la configuration avec les options les plus appariement).
Un petit exemple pour mieux comprendre:

Lors de linstallation du logiciel, il peut tre ncessaire de redmarrer lordinateur. Sil y a actuellement un utilisateur
connect, vous devriez le mettre en garde contre le redmarrage en attente. Cet avertissement devrait avoir un dlai
dattente et il peut tre judicieux de demander lutilisateur, si le redmarrage devrait tre annule (pour le moment).
Si aucun utilisateur nest connect, na aucun sens de demander et dattendre une rponse. Donc, dans ce cas, le
redmarrage devrait avoir lieu immdiatement.
Pour faire face ces diffrentes situations, il faut configurer event_on_demand de la faon suivante:
Nous dfinissons une Precondition user_logged_in qui se ralise si un utilisateur est connect au systme (user_l
ogged_in =true).
Dans la configuration par dfaut de lvnement event_on_demand (sans aucune Precondition) on met shutdown_w
arning_time =0 (redmarrage immdiat sans avertissement).
Dans la configuration event_on_demand{user_logged_in} on met shutdown_warning_time =300 (avertissement
avec 300 secondes de dlai dattente).
Configuration via le fichier de configuration
Le fichier de configuration est dans:

c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
Attention
Ce fichier de configuration est cod en UTF-8.
Toute modification laide des diteurs qui ne prennent pas en charge ce type de codage (par exemple notepad.exe)
peut dtruire tout trma dans ce fichier.
La configuration crite dans ce fichier peut tre modifi par des donnes de configuration diffrentes, qui viennent par
le biais du service Web aprs une connexion russie au serveur opsi.
Un exemple de opsiclientd.conf:
; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
; = configuration file for opsiclientd =
; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - global settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[global]
# Location of the log file.

log_file = c:\\tmp\\opsiclientd.log
# Set the log (verbosity) level

# (0 <= log level <= 9)
# 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices
# 6: infos, 7: debug messages, 8: more debug messages, 9: passwords
log_level = 4
# Client id.
host_id =
# Opsi host key.

opsi_host_key =
# Verify opsi server certs

verify_server_cert = false
# Verify opsi server certs by ca

verify_server_cert_by_ca = false
# On every daemon startup the user login gets blocked

# If the gui starts up and no events are being processed the login gets unblocked
# If no gui startup is noticed after <wait_for_gui_timeout> the login gets unblocked
# Set to 0 to wait forever
wait_for_gui_timeout = 120
# Application to run while blocking login

block_login_notifier = %global.base_dir%\\notifier.exe -s notifier\\block_login.ini
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - config service settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[config_service]
# Service url.
# http(s)://<opsi config server address>:<port>/rpc
url = https://opsi.uib.local:4447/rpc
# Conection timeout.
connection_timeout = 30
# The time in seconds after which the user can cancel the connection establishment
user_cancelable_after = 30
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - depot server settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[depot_server]
# Depot server id
depot_id =
# Depot url.
# smb://<depot address>/<share name>/<path to products>
url =
# Local depot drive

drive =
# Username that is used for network connection [domain\]<username>

username = pcpatch
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - cache service settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[cache_service]
# Maximum product cache size in bytes
product_cache_max_size = 5000000000
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - control server settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[control_server]
# The network interfaces to bind to.

# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 0.0.0.0
# The port where opsiclientd will listen for HTTPS rpc requests.
port = 4441
# The location of the server certificate.

ssl_server_cert_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem
# The location of the server private key

ssl_server_key_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem
# The location of the static files

static_dir = %global.base_dir%\\opsiclientd\\static_html
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - notification server settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[notification_server]
# The network interfaces to bind to.

# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 127.0.0.1
# The first port where opsiclientd will listen for notification clients.
start_port = 44000
# Port for popup notification server

popup_port = 45000
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - opsiclientd notifier settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_notifier]
# Notifier application command

command = %global.base_dir%\\notifier.exe -p %port% -i %id%
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - opsiclientd rpc tool settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_rpc]
# RPC tool command

command = %global.base_dir%\\opsiclientd_rpc.exe "%global.host_id%" "%global.opsi_host_key%" "%control_server.port%"
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - action processor settings -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[action_processor]
# Locations of action processor
local_dir = %global.base_dir%\\opsi-winst
remote_dir = opsi-winst\\files\\opsi-winst
filename = winst32.exe
# Action processor command

command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.\
host_id% /username %global.host_id% /password %global.opsi_host_key%
# Load profile / environment of %run_as_user%

create_environment = false
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; - events -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[event_default]
; === Event configuration
# Type of the event (string)
type = template
# Interval for timer events in seconds (int)
interval = -1
# Maximum number of event repetitions after which the event will be deactivated (int, -1 = forever)
max_repetitions = -1
# Time in seconds to wait before event becomes active (int, 0 to disable delay)
activation_delay = 0
# Time in seconds to wait before an event will be fired (int, 0 to disable delay)
notification_delay = 0
# Event notifier command (string)
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\event.ini
# The desktop on which the event notifier will be shown on (current/default/winlogon)
event_notifier_desktop = current
# Block login while event is been executed (bool)
block_login = false
# Lock workstation on event occurrence (bool)
lock_workstation = false
# Logoff the current logged in user on event occurrence (bool)
logoff_current_user = false
# Get config settings from service (bool)
get_config_from_service = true
# Store config settings in config file (bool)
update_config_file = true
# Transmit log file to opsi service after the event processing has finished (bool)
write_log_to_service = true
# Shutdown machine after action processing has finished (bool)
shutdown = false
# Reboot machine after action processing has finished (bool)
reboot = false
; === Sync/cache settings

# Sync configuration from local config cache to server (bool)
sync_config_to_server = false
# Sync configuration from server to local config cache (bool)
sync_config_from_server = false
# Sync configuration from local config cache to server after action processing (bool)
post_sync_config_to_server = false
# Sync configuration from server to local config cache after action processing (bool)
post_sync_config_from_server = false
# Work on local config cache
use_cached_config = false
# Cache products for which actions should be executed in local depot cache (bool)
cache_products = false
# Maximum transfer rate when caching products in byte/s (int, 0 = no limit)
cache_max_bandwidth = 0
# Dynamically adapt bandwith to other network traffic (bool)
cache_dynamic_bandwidth = false
# Work on local depot cache
use_cached_products = false
; === Action notification (if product actions should be processed)

# Time in seconds for how long the action notification is shown (int, 0 to disable)
action_warning_time = 0
# Action notifier command (string)
action_notifier_command = %opsiclientd_notifier.command% -s notifier\\action.ini
# The desktop on which the action notifier will be shown on (current/default/winlogon)
action_notifier_desktop = current
# Message shown in the action notifier window (string)
action_message = Starting to process product actions. You are allowed to cancel this event a total of %\
action_user_cancelable% time(s). The event was already canceled %state.action_processing_cancel_counter% time(s).
# German translation (string)
action_message[de] = Starte die Bearbeitung von Produkt-Aktionen. Sie knnen diese Aktion insgesamt %\
action_user_cancelable% mal abbrechen. Die Aktion wurde bereits %state.action_processing_cancel_counter% mal \
abgebrochen.
# Number of times the user is allowed to cancel the execution of actions (int)
action_user_cancelable = 0
; === Action processing

# Should action be processed by action processor (bool)
process_actions = true
# Type of action processing (default/login)
action_type = default
# Update the action processor from server before starting it (bool)
update_action_processor = true
# Command which should be executed before start of action processor
pre_action_processor_command =
# Action processor command (string)
action_processor_command = %action_processor.command%
# The desktop on which the action processor command will be started on (current/default/winlogon)
action_processor_desktop = current
# Action processor timout in seconds (int)

action_processor_timeout = 10800
# Command which should be executed before after action processor has ended
post_action_processor_command =
; === Shutdown notification (if machine should be shut down or rebooted)

# Process shutdown requests from action processor
process_shutdown_requests = true
# Time in seconds for how long the shutdown notification is shown (int, 0 to disable)
shutdown_warning_time = 0
# Shutdown notifier command (string)
shutdown_notifier_command = %opsiclientd_notifier.command% -s notifier\\shutdown.ini
# The desktop on which the action notifier will be shown on (current/default/winlogon)
shutdown_notifier_desktop = current
# Message shown in the shutdown notifier window (string)
shutdown_warning_message = A reboot is required to complete software installation tasks. You are allowed to delay this \
reboot a total of %shutdown_user_cancelable% time(s). The reboot was already delayed %state.\
shutdown_cancel_counter% time(s).
shutdown_warning_message[de] = Ein Neustart wird bentigt um die Software-Installationen abzuschliessen. Sie knnen \
diesen Neustart insgesamt %shutdown_user_cancelable% mal verschieben. Der Neustart wurde bereits %state.\
shutdown_cancel_counter% mal verschoben.
# Number of times the user is allowed to cancel the shutdown (int)
shutdown_user_cancelable = 0
# Time in seconds after the shutdown notification will be shown again after the user has canceled the shutdown (int)
shutdown_warning_repetition_time = 3600
[event_gui_startup]
super = default
type = gui startup
name = gui_startup
block_login = true
[event_gui_startup{user_logged_in}]
name = gui_startup
block_login = false
[event_gui_startup{cache_ready}]
use_cached_config = true
use_cached_products = true
action_user_cancelable = 3
action_warning_time = 60
[event_on_demand]
super = default
type = custom
name = on_demand
[event_on_demand{user_logged_in}]
name = on_demand
[event_software_on_demand]
super = default
type = sw on demand
[event_sync]
super = default
type = template
process_actions = false
event_notifier_command =
sync_config_to_server = true
sync_config_from_server = true
cache_products = true
cache_dynamic_bandwidth = true
[event_timer]
super = sync
type = timer
active = false
interval = 3600
[event_net_connection]
super = sync
type = custom
active = false
wql = SELECT * FROM __InstanceModificationEvent WITHIN 2 WHERE TargetInstance ISA Win32_NetworkAdapter AND \
TargetInstance.NetConnectionStatus = 2
[event_sync_completed]
super = default
type = sync completed
event_notifier_command =
process_actions = false
get_config_from_service = false
write_log_to_service = false
[event_sync_completed{cache_ready_user_logged_in}]
reboot = true
shutdown_user_cancelable = 10
[event_sync_completed{cache_ready}]
reboot = true
[event_user_login]
super = default
type = user login
action_type = login
active = false
message = Starting to process user login actions.
message[de] = Beginne mit der Verarbeitung der Benutzer-Anmeldungs-Aktionen.
block_login = false
process_shutdown_requests = false
get_config_from_service = false
update_config_file = false
write_log_to_service = false
update_action_processor = false
action_notifier_command = %opsiclientd_notifier.command% -s notifier\\userlogin.ini
action_notifier_desktop = default
action_processor_command = %action_processor.command% /usercontext %event.user%
action_processor_desktop = default
[precondition_user_logged_in]
user_logged_in = true
[precondition_cache_ready]
config_cached = true
products_cached = true
[precondition_cache_ready_user_logged_in]
user_logged_in = true
config_cached = true
products_cached = true
Configuration via le web service (Host Parameter)
La configuration de opsiclientd peut tre modifi par longlet Rseau et paramtres supplmentaires dans linterface
de gestion OPSI.
Les entres dans Rseau et paramtres supplmentaires doivent tre selon les modes suivants:
opsiclientd.<nom de la section>.<nom de la cl>

Exemple:
opsiclientd.event_gui_startup.action_warning_time =20
dfinie dans le fichier configuration opsiclientd.conf dans la section [event_gui_startup] la valeur de action_w
arning_time 20.
La figure ci-dessous montre comment changer la configuration gnrale du serveur via opsi-configed
Figure 45 Rglage de la configuration du serveur par dfaut pour opsiclientd
Utilisant le menu contextuel, vous pouvez choisir ajouter une proprit pour dfinir une nouvelle paire cl/valeur.
Pour supprimer un dfaut du serveur, utilisez loutil opsi-admin:
Exemple:
opsi-admin -d method config_delete "opsiclientd.event_gui_startup.action_warning_time"
Il est galement possible de manipuler ces entres spcifiquement pour un client via opsi-configed.
Pour supprimer une entre spcifique au client, utilisez loutil opsi-admin:
Exemple:
@opsi-admin> method configState_delete "opsiclientd.event_gui_startup.action_warning_time" "myclient.uib.local"
Figure 46 configuration spcifique au client opsiclientd via opsi-configed
7.3.7 Journalisation
opsiclientd ecrit ces logs dans:

c:\tmp\opsiclientd.log.
Toutes les informations du journal seront transfrs opsi-configserver via le web service. Au niveau du serveur
vous trouverez ces infos dans /var/log/opsi/clientconnect/<ip-ou-nom-du-client>.log. Ils sont prsents dans
opsiconfiged longlet Journaux systmes / clientconnect.
Chaque ligne du journal a le motif:
[<log level>] [<time stamp>] [message source] message.
Il y a les niveaux de journalisation suivants:
# Set the log ( verbosity ) level
# (0 <= log level <= 9)
# 0: rien , 1: essentiel , 2: critique , 3: erreurs , 4: avertissements , 5: notices
# 6: infos , 7: messages de dbogage , 8: plus de messages de dbogage , 9: mots de passe
Exemple:
(...)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config sync_completed{cache_ready} added to event \
generator sync_completed (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config gui_startup added to event generator \
gui_startup (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config gui_startup{cache_ready} added to event \
generator gui_startup (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config on_demand added to event generator on_demand \
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config sync_completed{cache_ready_user_logged_in} added\
to event generator sync_completed (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config gui_startup{user_logged_in} added to event \
generator gui_startup (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config sync_completed added to event generator \
sync_completed (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config software_on_demand added to event generator \
software_on_demand (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event config on_demand{user_logged_in} added to event \
generator on_demand (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Updating config file: C:\Program Files (x86)\opsi.org\opsi-\
client-agent\opsiclientd\opsiclientd.conf (Config.pyo|287)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] No need to write config file C:\Program Files (x86)\opsi.org\\
opsi-client-agent\opsiclientd\opsiclientd.conf, config file is up to date (Config.pyo|318)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] No product action requests set (EventProcessing.pyo|591)
[5] [Mar 22 10:17:49] [ event processing gui_startup ] Writing log to service (EventProcessing.pyo|247)
[6] [Mar 22 10:17:49] [ opsiclientd ] shutdownRequested: 0 (Windows.pyo|340)
[6] [Mar 22 10:17:49] [ opsiclientd ] rebootRequested: 0 (Windows.pyo|326)
[5] [Mar 22 10:17:49] [ opsiclientd ] Block login now set to False (Opsiclientd.pyo|111)
[6] [Mar 22 10:17:49] [ opsiclientd ] Terminating block login notifier app (pid 1620) (Opsiclientd.\
pyo|148)
[6] [Mar 22 10:17:49] [ event processing gui_startup ] Stopping notification server (EventProcessing.pyo|225)
[6] [Mar 22 10:17:51] [ control server ] client connection lost (Message.pyo|464)
[6] [Mar 22 10:17:52] [ event processing gui_startup ] Notification server stopped (Message.pyo|651)
[5] [Mar 22 10:17:52] [ event processing gui_startup ] ============= EventProcessingThread for event gui_startup \
ended ============= (EventProcessing.pyo|1172)
[5] [Mar 22 10:17:52] [ opsiclientd ] Done processing event <ocdlib.Events.GUIStartupEvent object at\
0x023CE330> (Opsiclientd.pyo|405)
[5] [Mar 22 10:19:41] [ opsiclientd ] Session HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu from ip 127.0.0.1,\
application opsi jsonrpc module version 4.0.1 expired after 120 seconds (Session.pyo|184)
[6] [Mar 22 10:19:41] [ opsiclientd ] Session timer <_Timer(Thread-20, started daemon 2636)> canceled\
(Session.pyo|120)
[5] [Mar 22 10:19:41] [ opsiclientd ] Session HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu from ip 127.0.0.1,\
application opsi jsonrpc module version 4.0.1 deleted (Session.pyo|207)
[6] [Mar 22 10:27:55] [ control pipe ] Creating pipe \\.\pipe\opsiclientd (ControlPipe.pyo|253)
[5] [Mar 22 10:27:55] [ event generator wait_for_gui ] -----> Executing: getBlockLogin() (JsonRpc.pyo|123)
[5] [Mar 22 10:27:55] [ opsiclientd ] rpc getBlockLogin: blockLogin is False (ControlPipe.pyo\
|428)
[6] [Mar 22 10:27:55] [ event generator wait_for_gui ] Got result (JsonRpc.pyo|131)
opsi-login-blocker enregistre dans le fichier journal: c:\tmp\opsi_loginblocker.log.
7.3.8 opsiclientd page dinformation
Daprs les fait quil existe un grand nombre de sous-composants de opsiclientd qui travaillent et journalisent en mme
temps, le fichier journal de opsiclientd devient complexe.
Afin de rendre plus facile comprendre comment les diffrents sous-composants travaillent ensemble, opsiclientd a
une propre "page dinformation" qui permet de visualiser les tches en cours dexcution sur une chronologie.
Vous pouvez voir cette "page dinformation" dans le navigateur ladresse:
https://<address-of-the-client>:4441/info.html
Figure 47 Page dinformation de opsiclientd aprs linstallation pousse avec le cache activ du produit
7.3.9 opsi-client-agent commande distance
opsiclientd possde sa propre interface de service Web qui peut tre utilis pour transmettre des commandes opsi-
clientd. Les commandes possibles peuvent tre rpartis dans les catgories suivantes:
envoyer des messages (Popup)
Pousser les installations (dmarrer lvnement on_demand)
autres tches de maintenance
Cela peut tre fait en ligne de commande en utilisant loutil opsi-admin en appelant lune des mthodes hostControl_*.
Lappel une de ces mthodes prend le paramtre *hostid qui:
peut tre dpos pour envoyer la commande tous les clients
peut tre le nom dun client (ex. "pcbon4.uib.local")
peut tre une liste de noms de client selon le schma [ <client1>, <client2>]
ex. ["pcbon1.uib.local", "pcbon2.uib.local"]
peut contenir des jokers comme *
ex. "pcbon4.*" or "pcbon*"
Si un client nest pas joignable (par exemple hors tension) vous obtiendrez un message.
Lenvoi de messages pop-up
En utilisant opsi-configed vous pouvez envoyer des messages aux clients. Section 4.3.8
Sur la ligne de commande, vous pouvez le faire avec loutil opsi-admin:
opsi-admin -d method hostControl_showPopup message *hostid
Exemple:
opsi-admin -d method hostControl_showPopup "This is my message" "myclient.uib.local"
Pousser les installations: dmarrer lvnement la demande
serveur opsi peut envoyer une commande au client que le client doit traiter les requtes dactions configures imm-
diatement. Ceci est fait en activant lvnement on_demand sur le client.
Ceci est possible en utilisant opsi-configed et il est dcrit dans le chapitre: Pousser linstallation: dmarrer lvnement
on demand
A partir de serveur opsi le client peut tre invit excuter les product actions.
Lexcution dvnements peut galement tre effectue partir de opsi-configed. Section 4.3.8
Sur la ligne de commande, vous pouvez utiliser opsi-admin pour dclencher un vnement:
opsi-admin -d method hostControl_fireEvent event *hostIds
Exemple:
opsi-admin -d method hostControl_fireEvent "on_demand" "myclient.uib.local"
Tches de maintenance supplmentaires (arrt, redmarrage,. . . ..)
En utilisant le port de contrle du serveur vous pouvez contrler distance opsiclientd. Pour ce faire, vous devez vous
authentifier auprs du service web. Cela pourrait se faire soit avec le compte dadministrateur local (avec un mot de
passe non vide) ou avec le opsi-host-Id (FQDN, le nom du client et le nom de domaine DNS) comme nom dutilisateur
et le opsi-hostkey comme mot de passe.
En utilisant opsi-configed vous pouvez choisir le menu opsiClient ou le menu contextuel de longlet Selection des clients.
Figure 48 Service Web de opsiclientd
Sur la ligne de commande, vous pouvez galement dmarrer un client:

arrt:
opsi-admin -d method hostControl_shutdown *hostIds
redmarrage:
opsi-admin -d method hostControl_reboot *hostIds
7.4 Blocage de la connexion de lutilisateur avec opsi-Loginblocker

Pour viter une connexion de lutilisateur avant que toutes les installations sont termines, opsi fournit loption opsi-
login-blocker.
7.4.1 opsi loginblocker de Windows 2000 XP (NT 5)
opsi-login-blocker est implment comme Gina opsigina.dll. Gina signifie Graphical Identification and Authentica-
tion et cest le hook officiel de Microsoft pour manipuler le processus de connexion.
Si vous avez dj un particulier Gina-DLL install, qui est diffrent de loriginal Microsoft msgina.dll (ex. Novell
nwgina.dll), vous ne devez pas installer opsi-login-blocker sans consulter opensides ou https://forum.opsi.org. Il est
possible de chaner diffrentes gina.dlls, mais par consquent linstallation doit tre personnalise. Lenchanement
correct des DLL Gina est une tche trs critique et peut entraner un verrouillage de lordinateur si cela est fait
incorrectement.
Que opsi-login-blocker est install ou pas est configur par le commutateur LoginBlockerStart=on/off dans la section
[opsi-client-agent-install] de la configuration du client.
7.4.2 opsi loginblocker pour NT 6 (Win 7 & Co)
opsi-login-blocker dans Vista est implment comme un "Filtre fournisseur dinformations didentification". Il bloque
tous "informations didentification" jusqu la libration par opsiclientd ou dlai dattente.
7.5 Installation ultrieure de opsi-client-agents

Les informations sur une Installation ultrieure de opsi-client-agent vous les trouverez dans le manuel opsi-getting-
started (Chapitre Premires tapes).
7.5.1 Installation de opsi-client-agent partir dune image matre ou comme exe
# doit tre crit #
8 Produits Localboot: distribution de logiciels automatique avec opsi

Un produit localboot est un produit opsi qui sera install par opsi-client-agent aprs que le client dmarr lOS par
dfaut partir du disque dur local. Cela le distingue des produits netboot qui seront dcrit plus loin.
8.1 produits standards dopsi

Les produits suivants sont des produits de base qui viennent avec linstallation de opsi-server.
8.1.1 opsi-client-agent
Le paquet opsi-client-agent contient le mcanisme dinstallation et de mise jour pour opsi-client-agent.
8.1.2 opsi-winst
Le paquet opsi-winst est un cas particulier. Il comprend opsi-winst winst32.exe, qui est mis jour par le paquet
opsi-client-agent mme. opsi-client-agent contrle dans le serveur si il y a une version diffrente de winst32.exe puis
copie le nouveau opsi-winst (tous ses fichiers) sur le client. Cette mise jour automatique ne fonctionne pas pour
Windows 2000 depuis opsi 4.
8.1.3 javavm: Java Runtime Environment
Le paquet javavm installe lenvironnement dexcution Java 1.6 requis par opsi-configed) sur les clients.
8.1.4 opsi-adminutils
Le paquet opsi-adminutils offre des utilitaires et une installation locale de opsi-configed.
8.1.5 jedit
Editeur Java avec coloration syntaxique pour les scripts opsi-winst.
8.1.6 Swaudit et hwaudit: Produits pour linventaire matriel et logiciel
Les paquets hwaudit et swaudit ils fournissent linventaire matriel et logiciel. Les don-
nes du matriel sont acquises en utilisant WMI et crites dans linventaire du matriel via
le web service opsi. Les donnes de linventaire logiciel sont tires de la base de registre
(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) et transmis au serveur
dinventaire par le web service opsi.
8.1.7 opsi-template
Modle pour vos propres scripts opsi.

Vous pouvez extraire ce modle avec:
opsi-package-manager -x opsi-template_<version>.opsi
il est galement possible de le renommer en mme temps:

opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod
8.1.8 xpconfig
Paquet pour personnaliser les paramtres de linterface graphique et dExplorer (et pas seulement) pour Windows XP.
8.2 La manipulation de la squence dinstallation en fonction des priorits du produit
Depuis opsi 4.0 la squence dinstallation sera calcul en ce qui concerne les dpendances entre produits et les priorits
du produit.
dpendances du produit
dfinit les dpendances et la squence dinstallation ncessaire entre les paquets opsi. Un exemple typique est la
dpendance entre un programme Java et lenvironnement dexcution Java (javavm).
priorits du produit
sera utilis pour pousser certains paquets au dbut de la squence dinstallation et dautres paquets la fin. Par
exemple, il est utile installer le Service Pack et les correctifs au dbut dune squence dinstallation et linventaire
logiciel la fin.
Les priorits de produit sont des nombres compris entre 100 et -100 (0 est la valeur par dfaut)
Il existe diffrentes possibilits dutilisr ces deux facteurs pour calculer la squence dinstallation. Opsi propose deux
algorithmes diffrents.
Vous pouvez basculer entre ces algorithmes:
en utilisant opsi-configed, dans longlet Rseau et paramtres supplmentaires de la configuration du serveur
Figure 49 opsi-configed: configuration du serveur
ou vous pouvez le faire en ligne de commande:

opsi-setup --edit-config-defaults
Figure 50 Choisissez lalgorithme de tri: Partie 1

Figure 51 Choisissez lalgorithme de tri: Partie 2
8.2.1 Algorithm1: dpendance lgard de la prioritaire du produit (par dfaut)
Grce cet algorithme, la squence dinstallation du produit dans un premier temps sera calcul en fonction des
priorits du produit. Dans un deuxime temps, il fera recours aux les dpendances du produit. Cet algorithme peut
pousser les produits avec une priorit basse avant les produits ayant une plus grande priorit pour rpondre aux
besoins de dpendances du produit. Mais par consquent vous ne verrez pas les problmes dinstallation la suite de
dpendances non rsolues du produit.
8.2.2 Algorithm2: dpendance lgard de la dpendance du produit
La philosophie de base de cet algorithme est, que dans la pratique, il y a trois classes de priorit ncessaires:
Les produits qui doivent tre installs au dbut dune squence , comme les mises jour de lOS. Ces produits ont
besoin dun rang de priorit lev (ex. 100)
Les produits "normalaux" pour installer des applications (priorit par dfaut = 0)
Les produits qui doivent tre installs la fin dune squence dinstallation, comme linventaire logiciel. Ces produits
ont besoin dun faible degr de priorit (ex. -100)
Les dpendances du produit seront seulement rsolu lintrieur de la classe de priorit. Cela garantit que les produits
ayant une haute priorit seront installs trs tt. Mais est de votre responsabilit quil ny a pas de dpendances du
produit qui vont franchir les frontires de classe de priorit.
8.2.3 Dfinir les priorits et les dpendances du produit
Les priorits et les dpendances de produits appartiennent aux mtadonnes dun produit. Il vous sera demand pour
ces mta-donnes crant un nouveau produit en utilisant la commande opsi-newprod.
Ces mta-donnes seront stockes dans le fichier de contrle des produits et peuvent tre dit. Aprs avoir modifi le
fichier de contrle que vous avez crer et install le paquet nouveau.
Pour plus de dtails, voir le manuel getting started dans le chapitre de cration dun paquet opsi.
8.3 Lintgration des nouveaux paquets logiciels dans le dploiement de logiciels opsi.
Les informations sur "Lintgration des nouveaux paquets logiciels dans le dploiement de logiciels opsi" vous les
trouverez dans le manuel opsi-getting-started.
9 Produits Netboot
9.1 Paramtres de limage de dmarrage Linux pour opsi
Limage dmarrage Linux pour opsi a des paramtres qui peuvent tre utiliss pour modifier son comportement. Vous
essayerez cette option si limage de dmarrage ne fonctionne pas correctement avec les paramtres standard de votre
matriel (par exemple un cran noir).
Vous pouvez modifier ces paramtres standards via opsi-configed choisissant longlet Rseau et paramtres supplmen-
taires et en utilisant lentre opsi-linux-bootimage.append.
Les valeurs typiques sont (peuvent tre combins):
acpi=off
noapic
irqpoll
reboot=bios
Une autre valeur par dfaut importante est le mot de passe de lutilisateur root dans limage de dmarrage Linux. Ce
mot de passe est linux123 par dfaut et vous devez le changer pour des raisons de scurit.
Pour ce faire, modifiez lentre opsi-linux-bootimage.append dans Configuration serveur.
Loption que vous devez changer est pwh (password hash). Comme valeur pour cette option, vous devez donner un
nouveau mot de passe de hachage, qui sera charg dans /etc/shadow au moment du dmarrage.
La meilleure faon dobtenir le hash correct du mot de passe est de se connecter via ssh votre image de dmarrage:
ssh root@<client.domain.tld>
Lancien mot de passe est linux123.

Maintenant dfinissez un nouveau mot de passe pour lutilisateur root:
passwd
Rcuprez le nouveau hachage

grep root /etc/shadow
Le rsultat devrait ressembler ceci:

root:$6$344YXKIT$D4RPZfHMmv8e1/i5nNkOFaRN2oYNobCEjCHnkehiEFA7NdkDW9KF496OHBmyHHq0kD2FBLHZoTdr5YoDlIoWz\
/:14803:0:99999:7:::
Maintenant, copiez daprs le premier deux-points jusquau deuxime deux-points et utilisez cela comme valeur pour
pwh.
Donc loption pour opsi-linux-bootimage.append sera:
pwh=$6$344YXKIT$D4RPZfHMmv8e1/i5nNkOFaRN2oYNobCEjCHnkehiEFA7NdkDW9KF496OHBmyHHq0kD2FBLHZoTdr5YoDlIoWz/
9.2 Installation automatise de lOS sans assistance
9.2.1 Aperu
tapes dune r-installation:

En utilisant PXE-Boot:
Choisissez le client qui doit tre install avec lutilitaire opsi-configed ou opsi-admin.
Au prochain redmarrage, le client dtecte (via PXE-Bootprom) la demande de re-installation et charge limage de
dmarrage partir de serveur opsi.
En utilisant CD-Boot:
Le client dmarre limage de dmarrage partir de opsi-client-bootcd.
Limage damorage dmarre et demande confirmation pour procder la rinstallation. Cest la seule question
interactive. Aprs avoir confirm, linstallation se poursuit sans aucune nouvelle demande dinteraction.
Limage de dmarrage partitionne et formate le disque dur.
Limage de dmarrage copie les fichiers dinstallation et de configuration du serveur opsi vers le client et dclenche
le redmarrage.
Aprs le redmarrage le client installe le systme dexploitation en fonction des informations de configuration fournies
sans aucune interaction.
Aprs opsi-client-agent est install en tant quinstallateur OPSI pour la distribution automatis de logiciel.
Opsi installe tous les logiciels tel que dfini dans la configuration du client.
9.2.2 Conditions pralables
Lordinateur client doit tre quip dun contrleur rseau amorable. Les contrleurs rseau les plus rcents offrent
cette fonctionnalit (PXE boot), galement les contrleurs rseau rcentes qui sont intgrs sur la carte mre du PC.
Le logiciel PXE, qui est stock dans bootprom du contrleur de rseau, commande le processus de dmarrage via le
rseau en fonction de la squence damorage du BIOS. Habituellement, la squence de dmarrage doit tre dfini dans
le BIOS, network-boot doit tre le priphrique de dmarrage initial. Sil ny a aucune possibilit dutiliser PXE vous
pouvez dmarrer partir du opsi-client-bootcd.
Le paquet dinstallation opsi pour le systme dexploitation pour tre install doit tre prsent sur le serveur de dpt.
Dans ce qui suit nous supposons que Windows XP soit le systme dexploitation installer.
9.2.3 Dmarrage du PC client via le rseau
Le microprogramme PXE sactive au dmarrage de lordinateur. Une partie de la mise en uvre PXE est un client
DHCP.
Figure 52 tape 1 pendant le Boot PXE

Au dbut, le PC ne connat que ladresse Ethernet de son contrleur rseau (MAC), compos de six caractres
hexadcimaux deux chiffres.
Le firmware dclenche une diffusion DHCPDISCOVER: Jai besoin dune adresse IP, qui est mon serveur DHCP?
Le serveur DHCP propose une adresse (DHCPOFFER).
DHCPREQUEST est la rponse du client au serveur si ladresse IP est accepte. (Ce nest pas une tape obsolte car
il pourrait y avoir plus dun serveur DHCP dans le rseau.)
Le serveur envoie un DHCPACK pour reconnatre la demande. Linformation est envoye nouveau au client.
Vous pouvez observer ce processus sur lcran, pour PXE-BOOTPROM affiche des informations sur le micrologiciel
et son MAC. Le symbole "pipe" en rotation est affich lors de la demande. Lorsquune offre a t faite, il est remplac
par un \ et vous obtenez les informations transmises (IP du CLIENT, MASQUE, IP du serveur DHCP, IP de la
PASSERELLE). Un peu plus tard, vous devriez obtenir une rponse comme ceci: Mon adresse IP SEMBLE TRE
.......
Ce processus rend le PC rgulirment membre part entire du rseau configur. Ltape suivante consiste charger
le fichier de dmarrage (image de dmarrage) propose dans les informations de configuration.
9.2.4 Chargement de pxelinux
Limage damorage est charg via le protocole de transfert trivial de fichiers (tftp). Le message affich est LOADING.
tftp est un protocole assez ancien et simple pour transfrer des fichiers sans authentification. En fait, toutes les donnes
disponibles via tftp sont accessibles tous dans le rseau. Donc laccs tftp se limite un rpertoire, qui est gnralement
/tftpboot. Ce rpertoire est spcifi dans inetd (internet daemon, /etc/inetd.conf), qui dbutera le dmon tftp tftpd
la demande. La commande de dmarrage comme indiqu dans inetd.conf est quelque chose comme
tftpd -p -u tftp -s /tftpboot
Le processus de dmarrage PXE est multi-tape:
La premiere tape est de charger et lancer le fichier soumis dans le cadre du processus de dcouverte dadresse
(habituellement /tftpboot/linux/pxelinux.0).
Le logiciel pxelinux.0 cherche alors des informations de configuration et damorage dans /tftpboot/linux/pxelinux.cfg.
Il recherche dabord un fichier PC spcifique avec un nom bas sur ladresse Ethernet (MAC) du contrleur rseau
avec un premier 01. Le nom de fichier pour le contrleur avec ladresse Ethernet 00:0C:29:11:6B:D2 serait 01-00-0c-
29-11-6b-d2. Si le fichier nest pas trouv, pxelinux.0 commencera raccourcir le nom du fichier ( partir de la fin)
pour obtenir une correspondance. Si ce processus se termine sans rsultat, le fichier default sera charg. Ce fichier ne
contient que les instructions pour dmarrer partir du disque dur local. Dans ce cas sur lordinateur rien sera install
et tout simplement dmarrera le systme dexploitation actuel depuis son disque dur.
Figure 53 Etape 2 Boot PXE
Pour lancer la rinstallation dun certain PC, un fichier chargeable est prpar pour le programme pxelinux.0. Afin
de le faire, opsipxeconfd cre un fichier personnalis pour le PC dans /tftpboot/linux/pxelinux.cfg. Une partie de ce
fichier est la commande pour charger limage damorage de linstallation. Ce fichier contient aussi la cl du client
pour dchiffrer le mot de passe pcpatch. Ce fichier est cr en tant que canal nomm et disparat donc aprs avoir t
lu une fois. Plus de dtails ce sujet dans le chapitre sur la scurit des partages de fichiers.
Sur la base des informations de pxelinux.0 obtenues partir du canal nomm, limage de dmarrage actuelle est charg
partir du serveur de dpt opsi via tftp. Limage de dmarrage est bas sur un noyau Linux (/tftpboot/linux/install)
au sein dun systme de fichiers initrd appropri (/tftpboot/linux/miniroot.gz) et dune taille denviron 65 MB.
9.2.5 Dmarrer partir du CD
Analoguement linitialisation tftp via PXE-bootprom, limage de dmarrage de linstallation peut tre dmarr
partir du CD de dmarrage dopsi.
Cela pourrait tre recommand dans les conditions suivantes:
le client na pas de PXE bootprom;
il ny a pas de dhcp;
il y a un dhcp mais il nest pas autoris configurer les donnes du client et les adresses matrielles des clients sont
inconnus;
il y a un dhcp mais il nest pas configur pour cette demande.
Selon les diffrentes situations, plusieurs informations doivent tre fournies limage de dmarrage via CD en saisie
interactive. Le cas le plus simple est de ne pas fournir aucune autre information. ventuellement, le nom dhte du
client peut tre transmis par hn=<nom hte>. En utilisant loption ASK_CONF=1 plusieurs paramtres peuvent
tre interrogs. En appuyant sur F1 au prompt du CD montre la syntaxe.
Lisez le chapitre Crer un nouveau client en utilisant opsi-client-bootcd dans le manuel opsi-getting-started.
9.2.6 Limage de dmarrage linux se prpare pour la rinstallation
Limage damorage effectue nouveau une requte DHCP et configure linterface rseau daprs les informations
perues. Ensuite, les donnes de configuration pour le client seront chargs via web service dopsi.
Figure 54 Boot PXE charg pour la prparation de limage de dmarrage sur le disque dur pour linstallation du
systme dexploitation
Il dtient galement des informations sur la faon de partitionner le disque dur, le systme de fichiers utiliser et le
systme dexploitation installer. En outre, il fournit le mot de passe crypt pour se connecter au partage de fichiers.
Ces informations seront combines avec des informations tires de la rponse DHCP et ensuite seront transmises au
script dinstallation pour un traitement ultrieur.
Ensuite le mot de passe de lutilisateur pcpatch sera dchiffr avec la cl transfr pour monter le partage de fichiers de
linstallation, puis sera la fois de lappelle au script dinstallation partir du partage mont pour lancer linstallation
du systme dexploitation. Les oprations spcifiques qui excute le script dpendent du systme dexploitation qui
doit tre installe. Ci-dessous seront dcrites les tapes dune installation de Windows XP.
Prparer le disque: Sur le disque dur, limage de dmarrage cre une nouvelle partition (de la taille de 6 GB),
formate et installe un noyau amorable ntloader.
Copiez le fichier dinstallation: Les fichiers ncessaires linstallation de lOS et les fichiers de configuration pour
opsi-client-agent (qui est le paquet de distribution de logiciel OPSI) seront copis partir du serveur de partage de
fichiers (ex. /opt/pcbin/install/winxppro/i386) sur le disque dur local.
Entretenir les informations de configuration: Certains des fichiers de configuration et de contrle contiennent
des caractres de remplacement, qui seront mis jour avant de commencer linstallation relle. Avec un script spcifi
(patcha-script) les espaces rservs seront remplacs par des paramtres pris dans le paquet dinformations, qui est
construit partir des fichiers de configuration et de la rponse DHCP. Par exemple dans le fichier unattend.txt, qui est
le fichier de contrle pour linstallation sans assistance du systme dexploitation, sera patch avec des informations
spcifiques comme IP de lhte, IP du client, nom du client, groupe de travail, passerelle par dfaut etc..
Prparer le redmarrage: Lenregistrements damorage sera install qui dmarrera le programme dinstallation de
Windows au prochain redmarrage. Le fichier patch unattend.txt est transmis la configuration en tant que fichier
de commande de linstallation automatique.
Redmarrage: Au cours de lamorage prcdent, le canal nomm (qui indique une demande dinstallation) a t
limine, en le lisant une fois. Donc la prochaine initialisation PXE chargera la rponse netboot par dfaut, qui
excute la commande hdboot. Le chargeur damorage locale sera lanc et la configuration de linstallation du systme
dexploitation dmarre.
Ces tapes sont contrles par un script python spcifique au systme dexploitation.
9.2.7 Installation du systme dexploitation et dopsi-client-agent
Linstallation de lOS est bas sur linstallation sans assistance de Microsoft. Une partie de cela est la dtection
du matriel standard. En plus des possibilits offertes lors de linstallation de non-OEM ou support dinstallation
slipstreamed, pilotes et correctifs (ex. service packs) peuvent tre installs pendant linstallation initiale, rendant
linstallation spare des pilotes obsolte.
Une des caractristiques de linstallation sans assistance est la possibilit dengager des installations supplmentaires
une fois linstallation principale termin. Ce mcanisme est utilis pour installer opsi-client-agent, qui met en uvre le
systme automatis de distribution de logiciels. Une entre dans la base de registre indique la machine comme tant
encore dans le mode de rinstallation.
Le redmarrage final entrane le demarrage su service opsi-client-agent pour la distribution de logiciels avant le premier
login de lutilisateur. Sur la base de la valeur de la cl de registre mentionne ci-dessus the opsi-client-agent commute
dans le mode de rinstallation. Par consquent, en ce qui concerne ltat de la configuration de chaque paquet opsi,
chaque paquet qui est marqu en tant que setup ou tat de linstallation installed lintrieur de la configuration de
ce client est install. Aprs que tous logiciels client dsigns ont t installs, le processus de rinstallation est termine
et ltat interne est commut de mode de rinstallation mode standard. Dans mode standard seuls les logiciels qui
sont marqus comme setup seront installs.
9.2.8 Comment fonctionne le programme Patcha
Comme mentionn ci-dessus les informations recueillies auprs du dhcp et de opsi-webservice seront utiliss pour
patcher certains fichiers de configuration comme par exemple unattend.txt. Le programme utilis pour patcher est le
script /user/local/bin/patcha.
Ce script remplace les motifs comme @flagname() dans un fichier avec des valeurs comme flagname=value prises
partir dun fichier de contrle (lentre par dfaut est /proc/cmdline). Dans les fichiers qui doivent tre corrigs, le
motif de recherche et de remplacement doit commencer par @, peut disposer en option de aprs le nom du drapeau
et doit avoir un ou plusieurs .
Donc en appelant patcha <nom de fichier> le fichier <nom de fichier> sera patch avec les informations extraites de
/proc/cmdline.
En appelant patcha sans aucun paramtre affichera toutes les entres nom du drapeau=valeur depuis /proc/cmdline.
Un fichier dentre diffrente (another_cmdline) peut tre pass patcha: patcha -f another_cmdline
Sans aucun autre paramtre patcha affiche les informations tires de another_cmdline. Ce fichier dentre doit avoir
la syntaxe cmdline, qui signifie avoir des entres comme <nom du drapeau>=<valeur> spars par un espace.
patcha -f another_cmdline patchfile
Cela va patcher patchfile avec des substitutions prises de another_cmdline.
Usage: patcha [-h|-v] [-f <params file>] <patch file>
Fill placeholders in file <patch file>

Options:
-v Show version information and exit
-h Show this help
-f <params file> File containig key value pairs
If option not given key value pairs from kernel cmdline are used
patcha patcht nur einen Tag pro Zeile.

Avertissement: patch a patches only the first pattern of each line.
Chaque motif sera tendu (ou rduit) la longueur de la valeur remplacer, puis remplac. Des caractres de fin ne
seront pas affects.
Exemples:
Avec le fichier dentre try.in
cat try.in
tag1=hallohallohallo1 tag2=t2
et le fichier patch.me patcher:

cat patch.me
<#@tag1##########################>
<#@tag2##########################>
<#@tag1#>
<#@tag2#>
<#@tag1*##########################>
<#@tag2*##########################>
<#@tag1*#>
<#@tag2*#>
<#@tag1#><#@tag1#####>
<#@tag2*#######><#@tag1#>
le rsultat sera:
./patcha -f try.in patch.me
cat patch.me
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1><#@tag1#####>
<t2><#@tag1#>
9.2.9 Structure des produits dinstallation sans assistance
Vous trouverez les informations sur la Structure des produits dinstallation sans assistance dans le manuel opsi-getting-
started.
9.2.10 Intgration simplifie des pilotes avec liens symboliques
Vous trouverez les informations sur la Intgration simplifie des pilotes avec liens symboliques dans le manuel opsi-
getting-started.
9.3 Quelques conseils sur les produits netboot NT6 (Vista / Win7 / 2008)
Les produits netboot pour linstallation des systmes dexploitation de la famille NT6, contiennent un grand nombre
de proprits qui seront dcrites ci-dessous.
Figure 55 proprits du produit NT6
additional_drivers
Un ou plusieurs rpertoires sous <productid>\drivers\drivers\additional. Tous les rpertoires du pilote
sous les rpertoires donns seront intgrs. Sil y a t-il un pilote dun priphrique trouv, aucune autre pilote
sera intgr par lintgration automatique du pilote.
askbeforeinst
Faut-il y avoir un dialogue de confirmation avant de commencer installer ?
boot_partition_label
Etiquette de la partition de dmarrage (partition Bitlocker)
boot_partition_letter
Lettre du lecteur de partition de dmarrage (partition Bitlocker)
boot_partition_size
Taille de la partition de dmarrage (partition Bitlocker). 0 = ne pas crer de partition
data_partition_label
Etiquette de la partion de donnes (si elle est cre)
data_partition_letter
Lettre du lecteur de la partion de donnes (si elle est cre)
fullname
Nom complet du titulaire de la licence, qui est donn au programme dinstallation
imagename
Nom de la variante du systme dexploitation
Figure 56 Nom de la variante NT6
orgname
Nom de lentreprise ou de lorganisation du titulaire de la licence, qui est donn au programme dinstallation
productkey
Cl de licence pour linstallation. Nest utilise que si license-management.use dans longlet Rseau et
paramtres supplmentaires est dfini sur false. Si cest dfini sur True la cl de licence sera obtenue par-
tir du module de gestion des licences.
system_keyboard_layout
Slectionnez la langue du clavier (voir: http://msdn.microsoft.com/en-us/goglobal/bb895996 )
Figure 57 Slectionnez la langue du clavier
system_language
Slectionnez la langue du systme
system_timezone
Slectionner le fuseau horaire
windows_partition_label
Etiquette de la partion systme (c:)
windows_partition_size
Taille de la partition systme (c:). La taille peut tre donn comme pourcentage de la taille du disque dur ou
comme taille absolue (G=Gigabyte). Si vous choisissez une autre valeur que 100%, le reste sera utilis comme
partition de donnes.
Figure 58 Taille de la partition systme
winpenetworkmode
Si true le PE essaie de monter le dpt de partage et de commencer linstallation du systme dexploitation
partir du partage (plus rapide). Si false tous les fichiers dinstallation seront copis sur le disque dur et
linstallation dmarre partir du disque local (plus lent).
9.4 image Ntfs (crire et restaurer)

Les produits ntfs-write-image et ntfs-restore-image sont des utilitaires pour sauvegarder et restaurer des images de
partitions des clients. La cible (et la source) pour le fichier image doivent tre sur le serveur de dpt OPSI et seront
transfrs par ssh (utilisateur pcpatch) comme spcifi en tant que proprit du produit.
9.5 memtest
Le produit memtest est un utilitaire pour effectuer un test de mmoire du client.
9.6 hwinvent
Ce produit offre un inventaire du matriel du client.
9.7 wipedisk
Le produit wipedisk crase le disque dur entier (partion=0) ou plusieurs partitions avec des motifs diffrents. Le nombre
doprations dcriture conscutives effectuer est spcifi en tant que proprit du produit itrations (1-25).
10 Inventaire
Linventaire peut tre ordonne avec les produits Localboot hwaudit et swaudit ou avec le produit Netboot hwinvent.
10.1 Inventaire Hardware
Linventaire matriel est contrl par un fichier de configuration opsi. Cela signifie que les informations sur lesquelles
les donnes seront compiles ne sont pas enchss dans les produits correspondants hwaudit et hwinvent. En fait, les
produits seront contrles par un fichier de configuration. Le fichier de configuration sera appele et interprt avec
chaque envoi du service Web. Simultanment, le fichier de configuration dtermine la structure de la base de donnes,
de sorte quun changement de ce fichier de configuration modifiera le schma de base de donnes.
Le fichier de configuration est /etc/opsi/hwaudit/opsihwaudit.conf.
Tous le objets inventoris sont dfinis et dcrits dans ce fichier, comme la faon dont ces objets et leurs donnes
sont instancies (sous Linux et Windows). Ce fichier va galement dfinir la structure de donne associe. Pour tre
plus prcis, ce fichier de configuration contient les dfinitions dhritage orient objet. La raison cela est le fait
que beaucoup dobjets contiennent des identiques champs de donnes (ex. comme Nom et Vendeur). Les informations
gnrales seront dfinies dans des classes de base virtual du matriel. Le objets dinventaire rels sont alors des classes
structural du matriel, lorsque de nombreuses proprits pourraient ventuellement tre hrite de la substitution des
classes de base virtual.
Lexemple suivant peut tre instructif:
Dans un premier temps le fichier de configuration dfinit une virtual Class appel "BASIC_INFO". Celle-ci dfinit les
proprits (Values):
"name"
"description"
Vient ensuite la virtual Class appel "HARDWARE_DEVICE", qui hrite de tous les paramtres supplmentaires de
"BASIC_INFO", et inclut les lments suivants:
"vendor"
"model"
"serialNumber"
Suivant suit le premier objet qui se trouve dans linventaire, qui est la premire structural Class appel "COM-
PUTER_SYSTEM", qui hrite de lensemble des paramtres supplmentaires de "HARDWARE_DEVICE", elle est
dfinie (et crase les proprits) comme:
"name"
"systemType"
"totalPhysicalMemory"
La dfinition de la classe comprendra une description de diffrents paramtres et leur Values:
Dfinition de la classe:
"Type"
est "STRUCTURAL" ou "VIRTUAL"
"Super"
cette classe dont elle va tre hrite.
"Opsi"
donne la nom de la classe, qui sera utilis par la suite dans opsi comme un nom daffichage.
De plus, la dfinition de classe permet de dfinir la manire dont les donnes seront compiles. Ces informations
peuvent galement tre trouvs dans la dfinition de Values.
Pour linventaire sous Linux:
"Linux": "[<commande>]<paramtre>"
Excute la commande <commande> sur la ligne de commande, avec largument <paramtre>.
"Python": "<code python avec espace rserv>"

Excute le code Python dont la sortie sera plac dans lespace rserv qui est comprise entre les signes "#" (voir
lexemple ci-dessous).
Pour linventaire sous Windows:
"WMI": "<wmi select statement>"
WMI sexcute lorsquil est appel
"Cmd": "<Objet texte Python avec espace rserv>"
Dans ce cas, cest le chemin relatif au programme excutable Python, dont la sortie sera plac dans lespace
rserv.
"Registry": "[<cl de registre>] <nom de la valeur>"
La valeur de <nom de la valeur> sera lu partir de la base de registre, et donne le nom de la cl <cl de registre>.
Le registre doit tre lu dune manire spcifique larchitecture. Cela signifie que le secteur 64 bits seront lus sur
un systme 64 bits.
Dfinition de la valeur:
"Type": "<MySQL Database type>"
<MySQL Database type> donne le type de base de donnes MySQL qui sera appliqu cette valeur (ex. une
chane Python sera "<MySQL Datenbase type>"="varchar(200)").
"Scope": "<porte>"
Le champ <porte> sera utilis de la manire suivante:
"g" signifie: Cet attribut est le mme dans tous les liens de ces types.
"i" signifie: Cet attribut peut avoir diffrents types de valeurs avec ces liens.
"Opsi": "<id>"
"<id>" est le nom interne des champs. Cela peut tre trouv dans le fichier situ dans /etc/opsi/hwaudit/
locales .
"WMI": "<id ou commande>"
<id ou commande> est soit le nom dune commande WMI qui affiche la valeur ou une seule commande WMI.
Si la commande WMI est donne dans la dfinition de classe (ex. "select * from Win32_ComputerSystem") , les
rsultats sont attribus aux variables "WMI" dans la dfinition de la classe "Values" . Sil ny a pas de commande
WMI, les variables "WMI" dans la section "Values" sont des commandes WMI (voir lexemple ci-dessous).
"Linux": "<id>"
Cela fait partie de la dfinition de classe, <id> est le nom de la valeur affiche lorsque la commande Linux est
donne.
"Condition": "<condition>"
<condition> est une condition qui doit tre remplie, avec laquelle les Value seront dtermins. Ainsi, par exemple
si la <condition> est dfinie comme "vendor=[dD]ell*", ensuite les valeurs de "vendor" doivent contenir Dell ou
dell.
Voici un exemple de la classe "COMPUTER_SYSTEM":
{
"Class": {
"Type": "STRUCTURAL",
"Super": [ "HARDWARE_DEVICE" ],
"Opsi": "COMPUTER_SYSTEM",
"WMI": "select * from Win32_ComputerSystem",
"Linux": "[lshw]system"
},
"Values": [
{
"Type": "varchar(100)",
"Scope": "i",
"Opsi": "name",
"WMI": "Name",
"Linux": "id"
},
{
"Scope": "i",
"Opsi": "systemType",
"WMI": "SystemType",
"Linux": "configuration/chassis"
},
{
"Type": "bigint",
"Scope": "i",
"Opsi": "totalPhysicalMemory",
"WMI": "TotalPhysicalMemory",
"Linux": "core/memory/size",
"Unit": "Byte"
},
{
"Scope": "i",
"Opsi": "dellexpresscode",
"Condition": "vendor=[dD]ell*",
"Cmd": "#dellexpresscode\dellexpresscode.exe#.split(=)[1]",
"Python": "str(int(#{COMPUTER_SYSTEM:serialNumber,CHASSIS:serialNumber}#,36))"
}
]
},
En ce qui concerne les commandes "WMI", la dfinition de classe contient "select * from Win32_ComputerSystem".
Cette commande est excute par WMI, qui comporte des colonnes de sortie "Name", "SystemType", et "TotalPhysi-
calMemory". Ces valeurs sont ensuite affects aux valeurs de opsi "name", "systemType", et "totalPhysicalMemory".
Particulirement intressant est ici la dernire valeur "dellexpresscode":
Ceci est vraiment utile quand lIT sinterroge sur un ordinateur Dell, sur son tat.
Le programme en ligne de commande dellexpresscode.exe a t conu pour Windows, et indique hwaudit.exe
que les dellexpresscode est fourni dans le rpertoire dellexpresscode\. Les lments entre # sont des espaces rservs
pour la sortie. Ainsi, la dclaration "dellexpresscode\dellexpresscode.exe" excute dellexpresscode.exe, et produit
une sortie sous la forme : dellexpresscode=123456789. La valeur qui sera utilis est lune aprs la sparation sur
lespace rserv =, ce qui est fait en Python en utilisant la mthode split () comme tel .split(=)[1] . Sous Linux,
on trouvera une valeur pour serialNumber pour les lments (COMPUTER_SYSTEM ou CHASSIS), qui est ensuite
utilis pour attribuer les codes Dell Express. Lappel int(,36) convertit la sortie nombre entier en base-36.
Les noms opsi des valeurs seront convertis en utilisant les fichiers trouvs dans /etc/opsi/hwaudit/locales/*. Le
fichier /etc/opsi/hwaudit/locales/en_US peut contenir des traductions telles que:
COMPUTER_SYSTEM = Computer
COMPUTER_SYSTEM. systemType = Type
Le nom de la classe COMPUTER_SYSTEM sera traduit en "Computer". Lattribut Opsi "systemType" de la classe
COMPUTER_SYSTEM sera traduit en "Type" pour langlais. Si lon regarde dans le fichier /etc/opsi/hwaudit/loc
ales/de_DE, on verrait que lattribut "COMPUTER_SYSTEM.systemType" sera traduit en "Typ" pour lallemand.
Enfin, une autre suggestion: Lorsquun nouveau champ est cr, il doit tre plac dans ces fichiers, mme si ne traduit
pas explicitement le terme. Ceci vite tous les messages de "Warning".
10.2 Inventaire des logiciels
Linventaire logiciel se fait avec le produit Localboot swaudit. Dans ce cas, les informations seront hrits de la
dsinstallation du Registre, et des informations supplmentaires seront obtenues partir des correctifs et des cls de
licence.
Le code source de ces paquets peut tre trouv ici:
https://svn.opsi.org/listing.php?repname=swaudit
https://svn.opsi.org/listing.php?repname=hwaudit
11 Serveur opsi
11.1 Prsentation
Les fonctionnalits dun serveur opsi peuvent tre installs sur diffrents types de distributions Linux.
Il y a deux rles diffrents quun serveur opsi peut avoir:
opsi-configserver
Le opsi-configserver a le stockage central de donnes et fournit laccs ces donnes via le service web opsi. Un
opsi-configserver a normalement en plus le rle de opsi-depotserver.
opsi-depotserver
Le opsi-depotserver na pas de stockage de donnes de configuration. Un opsi-depotserver stocke les fichiers din-
stallation dans un partage et fournit les services PXE / tftpboot pour les produits netboot.
Les exigences matrielles sont faibles. Le serveur OPSI peut galement fonctionner comme une instance virtuelle, ex.
vmware (www.vmware.com) ou virtualbox (www.virtualbox.org).
11.2 Installation et mise en service

Linstallation et le dmarrage dun serveur opsi sont dcrites dans le manuel getting started.
11.3 Configuration Samba

Le serveur de dpt opsi vous offre les partages rseau qui dtient les informations de configuration et les paquets
logiciels. Ces partages peuvent tre monts par les clients. Pour les clients Windows les partages sont fournies par
SAMBA (version 3.x).
Pour configurer votre samba en fonction des besoins de opsi (ou pour rparer) excutez:
opsi-setup --auto-configure-samba
Aprs chaque changement de configuration de samba, vous devez recharger votre samba (/etc/init.d/samba reload).
11.4 Le dmon opsiconfd

opsiconfd est le dmon centrale opsi (service). opsiconfd fournit le service web opsi et fait beaucoup plus des choses.
opsiconfd est configur dans /etc/opsi/opsiconfd.conf.
11.5 Comptes dutilisateurs et groupes administratifs ncessaires

Utilisateur opsiconfd
Le dmon opsiconfd sexcute en tant que cet utilisateur.
Utilisateur pcpatch
Cet utilisateur est utilis par opsi-client-agent pour monter le dpt de partage. Cet utilisateur a normalement le
uid 992. Vous pouvez dfinir le mot de passe pour cet utilisateur avec
opsi-admin -d task setPcpatchPassword.
Groupe pcpatch
Le groupe pcpatch a lautorisation dcriture sur plusieurs fichiers et vous aurez besoin dtre dans ce groupe afin
de construire et dinstaller des produits opsi.
Groupe opsiadmin
Les membres du groupe opsiadmin sont autoriss se connecter au service web dopsi et peuvent utiliser par exemple
lditeur de configuration opsi-configed. Par consquent, tous les administrateurs dopsi doivent tre membres du
groupe pcpatch.
Un utilisateur peut rejoindre le groupe opsiadmin avec: addgroup <utilisateur> opsiadmin.

11.6 Rpertoire de partage ncessaires
Depotshare avec les fichiers dinstallation (opt_pcbin)

Le dpt de partage fournit tous les paquets logiciels qui peuvent tre installs par le logiciel opsi-winst. Le rpertoire
par dfaut pour les paquets logiciels est /opt/pcbin/install. Dans ce rpertoire chaque paquet logiciel a son propre
rpertoire sous le nom du paquet logiciel. Ces sous-rpertoires contiennent les scripts dinstallation et les fichiers
spcifiques des paquets.
ASTUCE
Le rpertoire /opt/pcbin/install sera remplac par le rpertoire (LSB conformes) /var/lib/opsi/depot. Le partage
opt_pcbin sera remplac par le partage en lecture seule opsi_depot.
Le rpertoire de construction des paquets (opsi_workbench)

Dans /home/opsiproducts vous y trouverez lendroit idal pour crer de nouveaux paquets et partir de l vous
devriez installer les paquets avec opsi-package-manager.
Partage avec les fichiers de configuration des backends (opsi_config)
Dans /var/lib/opsi vous trouverez les fichiers de configuration des backends.
11.7 la gestion des problmes
Si vous avez des incidents en utilisant opsi, vous devriez vrifier la liste suivante ou plutt excuter les commandes
suivantes. Lexprience a montr que la combinaison des commandes dans ce chapitre fixe la plupart des incidents.
Vrifiez laccessibilit et la charge de opsi-webservice:
Appelez avec votre navigateur ladresse URL: https://<server-ip>:4447/info. Si ne pouvez pas vous connecter,
passez ltape suivante. Si vous pouvez vous connecter: vrifier la charge de opsi-webservice et vrifiez lespace
libre sur le disque (dfiler vers le bas dans la page dinformation).
Vrifiez que les dmons sont en marche et redmarrez-les:
ps -ef | grep opsiconfd
ps -ef | grep opsipxeconfd
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart
Initialiser la configuration
opsi-setup --init-current-config
Dfinissez les droits pour les fichiers et les rpertoires importants dans opsi:
opsi-setup --set-rights
Nettoyez le backend
opsi-setup --cleanup-backend
Vrifiez que samba est en marche:
ps -ef | grep mbd
Il doit excuter au moins un processus nmbd et un processus smbd.

Pour redmarrer samba:
/etc/init.d/samba restart
ou
service nmbd restart
service smbd restart
Dfinissez le mot de passe pcpatch:
opsi-admin -d task setPcpatchPassword
12 La scurit
12.1 Introduction
OPSI est un outil puissant pour ladministration de nombreux clients.

Daprs cette ralit, le serveur opsi doit tre au centre des considrations de scurit.
Si vous contrlez le serveur opsi, vous contrlez tous les clients qui se connectent ce serveur opsi.
Combien de temps et dargent vous devez dpenser pour la scurit de votre serveur opsi, dpend de vos besoins en
matire de scurit et de lenvironnement oprationnel pour lutilisation de opsi. Ainsi, par exemple un serveur opsi
dans le cloud est plus en danger que un serveur opsi dans un rseau scuris.
Dans le chapitre suivant, nous avons rassembl les questions et les problmes les plus importantes.
A ce stade, nous disons merci tous les clients et les utilisateurs qui nous renseignent sur les problmes de scurit
et qui nous aident amliorer la scurit du systme opsi. Si vous trouvez un problme de scurit, vous pouvez nous
informer (opsi@opensides.be) avant de divulguer la faille de scurit publiquement.
12.2 Restez lcoute
Des informations sur les mises jour de scurit et les nouvelles sont publis dans
la zone des Nouveauts, sur le forum OPSI:
https://forum.opsi.org/viewforum.php?f=15
12.3 La scurit gnrale du serveur
Le logiciel OPSI peut pas tre plus scuris que le systme dexploitation sous-jacent. Assurez-vous de mettre jour
votre serveur avec les mises jour de scurit de votre distribution Linux. Cela doit tre fait non seulement pour
opsi-configserver, mais aussi pour tous les opsi-depotserver.
Il peut vous aider linstallation de programmes qui informent par e-mail sil y a des nouvelles mises jour disponibles.
Debian, Ubuntu
apticron
RHEL, CentOS
yum-updatesd
Il y a beaucoup de possibilits pour amliorer la scurit de votre serveur Linux. Mais ce nest pas la tche de ce
manuel.
Nous serions heureux de vous aider dans cette tche dans le cadre dun contrat de support.
12.4 Dpt en lecture seule
Le dpt de partage qui est utilis par les clients, devrait tre en lecture seule. Ceci est important pour viter les
infections des fichiers par des virus dans le dpt de partage par un client infectes.
Depuis opsi 4.0.1 il y a un nouveau partage opsi_depot qui est en lecture seule. Pour utiliser ce partage, excutez (sur
tous vos opsi-servers):
opsi-setup --auto-configure-samba
Cette commande cre le nouveau partage. Ce partage pointe vers le rpertoire /var/lib/opsi/depot. Selon votre
distribution Linux, un lien symbolique de ce rpertoire dans /opt/pcbin/install sera cr.
Pour dire aux clients quils doivent maintenant utiliser ce nouveau partage, vous devez excuter le script suivant sur
votre opsi-configserver:
for depot in $(opsi-admin -dS method host_getIdents unicode "{\"type\":\"OpsiDepotserver\"}"); do
echo "Depot: $depot"
depot_remote=$(opsi-admin -dS method host_getObjects [] "{\"id\":\"$depot\"}" | grep "depotRemoteUrl=" | cut -d "=" \
-f2)
depot_local=$(opsi-admin -dS method host_getObjects [] "{\"id\":\"$depot\"}" | grep "depotLocalUrl=" | cut -d "=" -\
f2)
depot_remote_new=$(echo $depot_remote | sed "s|/opt_pcbin/install|/opsi_depot|")
depot_local_new=$(echo $depot_local | sed "s|/opt/pcbin/install|/var/lib/opsi/depot|")
servertype=$(opsi-admin -dS method host_getObjects [] "{\"id\":\"$depot\"}" | grep "type=" | cut -d "=" -f2)
opsi-admin -d method host_updateObjects "{\"type\":\"$servertype\",\"id\":\"$depot\",\"depotLocalUrl\":\"\
$depot_local_new\",\"depotRemoteUrl\":\"$depot_remote_new\"}"
done
12.5 Lauthentification du client sur le serveur
Le client sauthentifie en utilisant le nom de domaine complet comme nom dutilisateur et le opsi-host-key comme mot
de passe.
Le opsi-host-key est stock sur le client dans le fichier:
%programfiles%\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf
qui est lisible avec des privilges administratifs seulement.
Le opsi-host-key est stock au niveau du serveur dans le backend utilis (ex. dans /etc/opsi/pckeys).
En plus de cette authentification, vous pouvez dire opsiconfd de vrifier si ladresse IP du client correspond au FQDN
donn. Pour activer cette vrification, vous pouvez dfinir dans /etc/opsi/opsiconfd.conf:
verify ip = yes
et recharger opsiconfd:
/etc/init.d/opsiconfd reload
Attention
Nutilisez pas cette fonction si vous ntes pas vraiment sr que votre rsolution de noms fonctionne correctement
dans les deux sens pour tous les clients.
12.6 Lauthentification du serveur au client
Depuis opsi 4.0.1 il existe diffrentes possibilits de vrifier la fiabilit du serveur contact.
Attention
Ne les utilisez pas en combinaison. Choisissez une seule voie ou vous serez verrouill depuis votre client.
12.6.1 Variante 1: verify_server_cert
Lors du premier contact un serveur opsi, le client accepte le certificat SSL donne et le stocke dans C:\opsi.org\
opsiclientd\server-certs.
Pendant tout contact ultrieur, le client cre une chane alatoire et utilise la public key du certificat stock pour
chiffrer cette chane (et les paramtres daccs). Ces donnes cryptes sont transmises au serveur.
Le serveur utilise la private key de son propre certificat SSL pour dcrypter les donnes et envoie la chane alatoire
dcrypte en retour vers le client.
Maintenant, le client vrifie si la chane correcte a t renvoy. Si ce nest pas le cas, la communication avec le serveur
est interrompue.
Vous pouvez empcher la possibilit de diriger vos clients vers un mauvais serveur, par exemple en manipulant les
DNS. Si vous configurez un nouveau serveur, vous pouvez migrer le certificat SSL de lancien vers le nouveau serveur
sans problmes. Et vous ne devez pas dployer aucune autorit de certification (CA).
Linconvnient de cette mthode est que un attaque man-in-the-middle est encore possible.
Cette mthode de scurit vrifie la communication entre le client et opsi-configserver.
En utilisant lextension WAN dopsi et que clientconfig.depot.protocol webdav, aussi les communication vers
opsi-depotserver sont vrifies.
Section 15.3.1
Pour activer cette vrification, rgl opsiclientd.conf dans la section [global] loption:
verify_server_cert = true
Excutez la commande suivante sur votre opsi-configserver pour crer cette entre de configuration pour tous les
clients:
opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert "verify_server_cert" false
Maintenant, vous pouvez activer cette fonction, en utilisant opsi-configed avec le bouton Configuration du Serveur ou
longlet Rsaux et paramtres supplmentaires des clients slectionns en modifiant la valeur de false true.
Attention
Soyez trs prudent avec lactivation de "verify_server_cert", car, en cas de mauvaise configuration, vos clients
refusront la connexion!
12.6.2 Variante 2: verify_server_cert_by_ca
Cette variante fonctionne exactement comme les certificats SSL qui sont vrifies dans votre navigateur.
Le certificat SSL donne ne sera accepte que sil est mis pour le FQDN exacte (commonName) du serveur (ou si le
DNS vrifie que cest le nom de domaine complet correspondant ladresse IP du serveur) et le certificat est dlivr
et sign par uib gmbh.
Si une de ces conditions nest pas vrai, la communication avec le serveur est interrompu.
Cette mthode est plus sre que la premire. Mais vous devrez acheter les certificats chez uib gmbh. Pour les prix et
conditions, vous pouvez jeter un oeil la liste des prix uib gmbh:
http://uib.de/en/opsi_support/index.html
Tous les profits de la vente de ces certificats seront investis dans le maintien de la scurit dopsi.
Pour activer cette mthode de scurit, rgl dans opsiclientd.conf dans la section [global] loption:
verify_server_cert_by_ca = true
Excutez la commande suivante sur votre opsi-configserver pour crer cette entre de configuration pour tous les
clients:
opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert_by_ca "verify_server_cert_by_ca" false
Maintenant, vous pouvez lactiver en utilisant opsi-configed avec le bouton Configuration du Serveur ou longlet Rsaux
et paramtres supplmentaires des clients slectionns en modifiant la valeur de false true.
Attention
Soyez trs prudent avec lactivation de "verify_server_cert_by_ca", car, en cas de mauvaise configuration, vos
clients refusront la connexion!
12.7 Lauthentification au niveau du serveur de commande du client
opsiclientd fournit une interface de service Web, ce qui permet le contrle distance de opsiclientd et donc le contrle
distance du client.
(Section 7.3.9).
Pour accder cette interface est ncessaire lauthentification. Vous pouvez vous authentifier en tant quadministrateur
local avec un mot de passe non vide, ou avec un nom dutilisateur vide et le opsi-host-key comme mot de passe.
12.8 Configuration du rseau admin
Lide dun rseau admin est dinterdire tout accs administratif partir du rseau de production standard et permettre
ces accs qu partir dun rseau admin spcial.
Avec opsi tous les clients ont un accs restreint au opsi web service, ce qui leur permet de lire et modifier leurs propres
donnes. Laccs administratif avec des privilges supplmentaires est accord seulement aux membres du groupe unix
opsiadmin.
Si vous configurez un paramtre admin networks, tous les accs administratifs sont limits ce rseau(x).
Dfinissant loption [global] admin networks dans /etc/opsi/opsiconfd.conf limitera laccs administratif op-
siconfd pour les connexions en provenance de ladresse de rseau spcifique(s).
Vous pouvez donner plusieurs adresses spares par des virgules.
Laccs non administratif peut galement provenir dautres rseaux.
La valeur par dfaut est:
admin networks = 0.0.0.0/0
et permet un accs administrateur depuis tous les rseaux.

Une configuration comme par exemple:
admin networks = 127.0.0.1/32, 10.1.1.0/24
restreint laccs administratif au serveur lui-mme et depuis le rseau 10.1.1.0/24.

12.9 Lutilisateur pcpatch

Avec opsi 4 lutilisateur pcpatch est seulement utilis par opsi-client-agent pour monter le dpt de partage (et en ce
moment par les produits netboot ntfs-write-image et ntfs-restore-image pour lire et crire les fichiers images via ssh).
Le mot de passe de lutilisateur pcpatch est gnralement stock et transmis crypt. Dans des circonstances spciales
il pourrait tre possible de capturer le mot de passe en clair. Pour rduire les risques rsultants , vous devez faire ce
qui suit:
Refuser lutilisateur pcpatch laccs tous les partages autres que le partage opsi_depot. Vous devez faire cela en
ajoutant lentre suivante toutes les dfinitions de partage (sauf opsi_depot) dans /etc/samba/smb.conf:
invalid users = root pcpatch
Alternative
Dans /etc/samba/smb.conf restreindre les privilges de lutilisateur pcpatch en lecture seule globale en dfinissant
dans la section [global]:
read list = pcpatch
Comme tche supplmentaire vous devriez changer frquemment le mot de passe de lutilisateur pcpatch. Vous pouvez
dfinir le mot de passe comme une chane alatoire que personne ne doit connatre (sauf opsi). Vous pouvez le faire
en appelant la commande suivante, par exemple par une tche cron:
opsi-admin -d task setPcpatchPassword $(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c16)
Si vous ne prvoyez pas dutiliser les produits netboot ntfs-write-image et ntfs-restore-image, vous pouvez refuser
une ouverture de session pour lutilisateur unix pcpatch en dfinissant dans /etc/passwd le shell /bin/false pour
lutilisateur pcpatch.
13 Sauvegarde dopsi
13.1 Introduction
Votre serveur opsi devrait tre sauvegards (comme tout autre systme important). Ce chapitre montre ce quil faut
sauvegarder et comment.
Et, bien sr, comment restaurer.
13.2 Conditions pralables la sauvegarde

Vous devez excuter commande opsi-backup comme root.
Vous devez installer le programme mysqldump avant de pouvoir utiliser opsi-backup dans le cadre du backend mysql.
Habituellement, ce programme fait partie des paquets du client mysql.
13.3 Mise en route rapide

Crer une sauvegarde:
opsi-backup create opsi_backup.tar.bz2
Cre une sauvegarde des backends utiliss et toutes les donnes de configuration dans le rpertoire courant avec le
nom opsi_backup.tar.bz2.
Restaurer une sauvegarde:
opsi-backup restore --backends=all --configuration opsi_backup.tar.bz2
Restaure les donnes partir du fichier de sauvegarde opsi_backup.tar.bz2, qui est recherch dans le rpertoire
courant.
13.4 lments de base dopsi
OPSI peut tre divis en cinq parties diffrentes qui peuvent tre sauvegards ou pas. Lemplacement o se trouvent
ces parties peut varier (selon la distribution Linux, la version et la configuration).
13.4.1 La configuration dopsi
La partie la plus importante de OPSI est la configuration. Vous la trouverez dans /etc/opsi.
Cette partie sera sauvegard par opsi-backup.
13.4.2 Les backends Opsi
Les donnes sur les clients grs et les produits peuvent tre stockes dans diffrents backends. Les backends les plus
importants sont:
Table 1: backends opsi
Backend Description
file-Backend backend bas sur les fichiers (backend par dfaut)
mysql-Backend backend bas sur MySQL (depuis opsi 4 pour toutes
les donnes de configuration)
ldap Stocker les donnes de configuration dans lannuaire
ldap
univention backend LDAP spcial pour les serveurs dentreprise
Univention
dhcp Backend spcial qui est utilis en combinaison avec un
dhcpd du serveur opsi
Des backends diffrents peuvent tre utiliss des fins diffrentes en mme temps. Donc, vous devriez jeter un oeil
/etc/opsi/backendManager/dispatch.conf pour voir quels backends vous utilisez.
Cette partie sera sauvegard par opsi-backup.
13.4.3 dpt de partage opsi
Dans le dpt de partage opsi Vous trouverez les fichiers dinstallation des logiciels installer sur les clients par opsi.
Les rpertoires qui contiennent ces fichiers (produits Localboot et produits netboot) sont situs dans /opt/pcbin/
install ou /var/lib/opsi/depot.
Selon le nombre des systmes dexploitation, pilotes, logiciels et ainsi de suite qui se trouvent ici, cette partie pourrait
tre de grande taille.
Cette partie ne sera pas sauvegard par opsi-backup.
Donc, si vous voulez sauvegarder cette partie, vous pouvez utiliser rsnapshot ou dautres utilitaires de sauvegarde.
13.4.4 opsi work bench
opsi work bench est le lieu qui est utilis pour crer ses propres paquets. Il est gnralement situ dans /home/
opsiproducts et exports comme partage Samba opsi_workbench. Puisque ce rpertoire contient votre propre travail,
il doit tre sauvegard.
13.4.5 dpt opsi
Le rpertoire /var/lib/opsi/repository est utilis pour stocker les paquets opsi, qui sont tlchargs via opsi-
product-updater ou qui sont installs par opsi-package-manager lorsque vous utilisez loption -d.
13.5 Le logiciel opsi-backup
opsi-backup est un programme en ligne de commande qui facilite la cration et la restauration des sauvegardes de
donnes opsi.
Les commandes de base sont create, restore et verify.
Loption --help affiche des informations sur les options de ligne de commande. Utilisez aussi <command> --help (ex.
opsi-backup create --help) pour obtenir des informations sur les options de la commande.
opsi-backup --help
Lutilitaire opsi-backup stocke les donnes de configuration et le backend dans presque le mme format auquel ils
ont t trouvs sur le serveur. Donc, vous ne pouvez pas restaurer ces donnes sur un serveur qui utilise
dautres backends, ou dispose dautres versions dopsi ou est dune autre manire diffrente en ce qui
concerne la structure des donnes opsi.
opsi-backup cre toujours une sauvegarde complte. Il ny a pas de support pour les sauvegardes incrmentielles ou
diffrentiel.
Attention
Remarquez que opsi-backup ne cre pas de sauvegarde de:
* opsi depot share * opsi work bench * opsi repository
opsi-backup cre un fichier de sauvegarde, dans le format compress tar. Donc vous pouvez accder aux donnes
laide dautres outils standard.
Attention
Un fichier de sauvegarde cr par opsi-backup peut contenir un mot de passe, touches de raccourci et dautres
donnes lies la scurit. Donc, assurez-vous de stocker les fichiers de sauvegarde dans un endroit sr.
13.5.1 Crer une sauvegarde
Pour crer une sauvegarde utilisez opsi-backup create.

Cette commande (sans options supplmentaires) crera une sauvegarde de toutes les donnes de configuration et
de tous les backends utilises. Le fichier de sauvegarde sera stock dans le rpertoire courant avec un nom gnr
automatiquement.
Pour obtenir des informations sur les options possibles de create appelez
opsi-backup create --help
opsi-backup create
opsi-backup create --help
usage: opsi-backup create [-h] [--flush-logs]
[--backends {file,mysql,dhcp,auto,all}]
[--no-configuration] [-c [{gz,bz2,none}]]
[destination]
positional arguments:
destination Destination of the generated output file. (optional)
optional arguments:
--flush-logs Causes mysql to flush table logs to disk before the
backup. (recommended)
--backends {file,mysql,dhcp,auto,all}
Select a backend to backup or all for all backends.
Can be given multiple times. (Default: auto)
--no-configuration Backup opsi configuration.
-c [{gz,bz2,none}], --compression [{gz,bz2,none}]
Sets the compression format for the archive (Default:
bz2)
Vous pouvez donner le rpertoire cible ou le chemin complet vers le fichier de sauvegarde en option pour opsi-backup
create. Si loption donne est un nom de fichier, la sauvegarde sera cr dans ce fichier - les fichiers existants seront
crass. Si loption est un dossier, le fichier de sauvegarde sera cr dans ce rpertoire avec un nom de fichier gnr
en utilisant le motif: <nom dhte>_<version dopsi>_<date>_<heure>
opsi-backup create /mnt/backup/opsi_backup.tar.bz2
opsi-backup create /mnt/backup/
Les autres options pour create sont:

--backends {file,mysql,dhcp,all,auto}
est utilis pour slectionner les backends qui doivent tre inclus dans la sauvegarde. Vous pouvez donner cette option
plusieurs fois.
Loption --backends=all comprend tous les backends supports.
La valeur par dfaut est --backends=auto, qui signifie que opsi-backup lit le fichier de configuration /etc/opsi/
backendManager/dispatch.conf et sauvegarde tous les backends supports utiliss dans cette configuration. Les
backends supports sont: mysql, file, dhcp
opsi-backup create --backends=file --backends=mysql
opsi-backup create --backends=all
ASTUCE
Si vous utilisez un backend pas pris en charge (comme ldap), vous pouvez utiliser opsi-convert pour convertir vos
donnes vers un backend qui est pris en charge par la sauvegarde.
--no-configuration
Exclut kes fichiers opsi configuration de la sauvegarde.
opsi-backup create --no-configuration
-c [{gz,bz2,none}], --compression [{gz,bz2,none}]

Spcifie la mthode de compression. none signifie pas de compression.
La valeur par dfaut est bz2.
opsi-backup create -c bz2
--flush-log
La sauvegarde du backend mysql utilise la commande mysqldump. Cela signifie que toutes les donnes connues par
la base de donnes sont sauvegards, peu importe si elles sont sur le disque ou encore seulement dans la mmoire.
Cela signifie, que votre sauvegarde peut tre plus actuel que vos fichiers de base de donnes (ce qui nest vraiment
pas un problme).
Si vous voulez vous assurer que la base de donnes stocke les donnes sur le disque avant de commencer la sauvegarde,
vous pouvez utiliser loption --flush-log. Mais avant que vous pouvez le faire, vous devez accorder les privilges
ncessaires pour le RELOAD lutilisateur de la base de donnes opsi, ou votre sauvegarde chouera. Voir: RELOAD.
Il faut donc utiliser cette option que si vous savez vraiment ce que vous faites.
opsi-backup create --backends=mysql --flush-log
Exemple
opsi-backup create --no-configuration --backends=all opsi_backup.tar.bz2
13.5.2 Archivez vos fichiers de sauvegarde
opsi-backup na pas de fonctionnalits pour archiver les fichiers de sauvegarde crs. Donc, vous devez le faire par
vous-mme (ex. en utilisant un outil de sauvegarde de fichiers).
Si vous faites appel opsi-backup avec un rpertoire cible en option, gardez lesprit que chaque appel cre un
nouveau fichier de sauvegarde complte et aucun fichier plus ancien sera effac.
13.5.3 Vrifier une sauvegarde
La commande opsi-backup verify est utilis pour tester lintgrit du fichier de sauvegarde cr. Laide pour la
commande opsi-backup verify est disponible par loption de commande --help.
Exemple
opsi-backup verify opsi_backup.tar.bz2
opsi-backup verify --help
usage: opsi-backup verify [-h] file [file ...]
required arguments:
file The backup archive to verify.
optional arguments:
-h, --help shows this help message and then exits
ASTUCE
Si vous appelez opsi-backup verify depuis la console, il peut tre utile dactiver les messages de sortie standard en
utilisant loption -v: opsi-backup -v verify opsi_backup.tar.bz2
13.5.4 Restauration partir dun fichier de sauvegarde
Pour restaurer les donnes partir dun fichier de sauvegarde, utilisez la commande opsi-backup restore.
Vous devez donner le chemin vers le fichier de sauvegarde en tant que paramtre.
La commande opsi-backup restore --help donne des informations sur les options de la commande restore.
opsi-backup restore --help
usage: opsi-backup restore [-h] [--backends {file,mysql,dhcp,auto,all}]
[--configuration] [-f]
file
required arguments:
file The backup archive to restore data from.
optional arguments:
Select a backend to restore or all for all backends.
Can be given multiple times.
--configuration Restore opsi configuration.
-f, --force Ignore sanity checks and try to apply anyway. Use
with caution! (Default: false)
opsi-backup restore possde les options suivantes:

Spcifie le backend restaurer. Cette option peut tre utilise plusieurs fois.
Loption --backends=all spcifie que les donnes de tous les backends qui se trouvent dans le fichier de sauvegarde
doivent tre restaurs.
La valeur par dfaut est --backends=auto. Cela permet de restaurer les donnes partir du fichier sauvegarde vers
le systme en utilisant les donnes de configuration actuelles de /etc/opsi/backendManager/dispatch.conf.
opsi-backup restore --backends=file --backends=mysql opsi_backup.tar.bz2
opsi-backup restore --backends=all opsi_backup.tar.bz2
Attention
Si vous avez modifi la configuration de votre backend depuis que vous avez cr la sauvegarde, pas ou pas toutes
les donnes seront restaurs. Dans ce cas, vous devez utiliser loption --backends=all et ensuite convertir les
donnes restaures dans le backend effectivement utiliss laide de opsi-convert.
--configuration
Indique que opsi configuration doit tre restaur.
Ce nest pas loption par dfaut de la commande restore.
opsi-backup restore --configuration opsi_backup.tar.bz2
-f, --force
Pour viter dendommager les donnes opsi-backup fait une vrification de la compatibilit du systme (version opsi,
Version OS, nom de lhte et Nom de domaine) avant de restaurer les donnes et sarrte si le systme actuel diffre
du systme ou le fichier de sauvegarde a t cr. Grce cette option vous pouvez outrepasser cette vrification.
opsi-backup restore -f opsi_backup.tar.bz2
Exemple
opsi-backup restore --configuration --backends=all opsi_backup.tar.bz2
14 opsi license management
14.1 Overview
14.1.1 Main features
The opsi license management module is designed for managing the software licenses for proprietary software installed
on opsi clients.
The main features are:
Providing the license management functions from within the opsi-configed.
Automated providing, assignment and reservation of license keys.
Different types of licenses can be managed:
standard single licenses (a single license key assigned to a single license),
volume licenses (a single license key for a certain number of installations) or campus licenses (a single license key
for an unlimited number of installations)
client bound licenses (which is a single license valid for a dedicated client only, e.g. OEM licenses),
concurrent licenses (managed by a license server)
Release of license keys when deinstalling the assigned software.
Manual editing of license assignment, e.g. for software which is not deployed by opsi.
Reporting funktions, also available for licenses not installed by opsi, based on the software inventory, matching of
data with the opsi based installations.
14.1.2 Invoking the license management from the opsi-configed
From the opsi-configed a separate window is used for the license management.
It is available by the button "licenses" from the main window of the opsi-configed, provided that the license management
module is acivated for the current opsi configuration (see the entry for "license management" from the main menu
/Help/Modules).
If the license management is disabled, a note will be displayed.
opsi-configed: Menu bar with button licenses (rightmost)
Figure 59 opsi-configed: Menu bar with the button "licenses" (rightmost)
The opsi license management module is a co financed opsi extension module, which is available to the participants of
the cofunding project, who have payed a certain amount of the development costs. The module will be available to
the community when all the development costs have been funded.
14.2 license pools
14.2.1 What is a license pool ?
For every type of license a license pool has to be defined. The license pools represent the use cases of licenses and
provide the license keys for installing the licensed software on the clients. The license pool is the central element of the
opsi license management. Therefore the first tab of the license management window of the opsi-configed is dedicated
to the management of license pools.
License management: Tab license-pools
Figure 60 License management: tab "License pools" from the license management window
14.2.2 Administration of license pools
In the upper part of the license pools window is a table of available license pools.
The input field description can be edited.
Some more editing functions are available from the context menu. The most important is: creating a new license pool.
When inserting a new line into the table, a (unique) licensePoolId must be entered, e.g. softprod_pool. Please do not
use umlauts. When saving the new entry, any capitals will be converted to lower case.
The new licensePoolId cannot be changed after saving, for it is used as the master key.
The upper part contains the table of available license pools. The context menu provides several functions for managing
license pools, especially to insert a new license pool. When editing, the green check mark changes to red and the cancel
option is enabled. By clicking the red check mark the changes can be saved, or cancelled by clicking the cancel option
(also available from the context menu).
14.2.3 license pools and opsi-products
The standard case of license management is an opsi-product installing software, which is subject to a license (e.g. the
Acrobat Writer) from a single license pool.
More complicated is the situation with an opsi-product is installing software, which requires licenses from several
license pools, like an opsi-product "Designer tools" which installs Adobe Photoshop as well as Acrobat Writer.
In this case the opsi-product requests licenses from several license pools. At the same time there might be other opsi-
products requesting licenses from the same license pools (e.g. the Acrobat Writer license pool). So the relation between
opsi-products and license pools can be ambiguous. This can be avoided by using unambiguous policies when building
opsi-products.
The second part of the license pool tab manages the relationship between license pools and productIds (from opsi-
products).
As it is with all tables of the license management module, clicking on the column header will sort the table content
by the column content. Clicking again inverts the order (ascending or descending).
Sorting can be used to display the connections between opsi-products and license pools. Sorting by opsi-product displays
all license pools connected to a certain opsi-product, whereas sorting by license pool shows which opsi-products are
connected to a license pool.
The context menu provides an option for inserting a new relationship between opsi-product and license pool. An empty
row is inserted on top of the table. Clicking into the field licensePoolId or productId displays a dropdown with the
available options.
14.2.4 license pools and Windows software IDs
The third section of the license pools tab displays the Windows software IDs connected to the currently selected license
pool (in the first section of the tab).
A Windows software ID is an unique key identifying a software packet as detected by opsi software audit. These
software IDs are also used by the opsi software inventory module to identify which software is actually installed on
the client.
The assignment of software IDs to the current license pool can be changed by setting or removing the selection (ctrl-
click or shift-click). From the context menu the display can be toggled between showing all available software IDs
detected by the software audit or just showing the software IDs connected to the current license pool.
Displaying the relationship between Software IDs and license pools is useful for comparing the number of actual
software installations (detected by the software audit) with the number of legal installations available from the license
pool (tab "Statistics", see below).
14.3 Setting up licenses
Setting up a license for being provided by a license pool requires several steps. The second tab New license is for
setting up and editing licenses.
On top is the table of available license pools to select the license pool the new license is to be assigned to. So the first
step is to select the license pool for the new license.
Tab New license
Figure 61 License management: tab "New license" from the license management window
Before continuing with the next steps, some basic concepts and terms of license management have to be introduced:
14.3.1 Some aspects and terms of the license concept
Licensing means the actual deployment of a permission to use a software by installing the software on a client. This
might (but doesnt have to) include the use of a special license key (license key).
The software license is the permission to install and use a software as defined by the license contract. Within the
opsi database a software license is identified by a softwareLicenseId.
There are several types of software licenses (volume license, OEM license, time limited license etc.) which are the
different license models. A software license is based on a license contract (license contract), which is defining and
documenting the juristic aspects of the license.
A license option defines the option to use a software license for a selected license pool. Within opsi the license option
is defined by a combination of softwareLicenseId and licensePoolId. This includes the actual licenseKey (if required).
Finally the license usage documents the use of a license by assigning the license option to a client. This is the legal
and implemented licensing of a software defined by the combination of softwareLicenseId, licensePoolId, the unique
client name hostId and (if required) the licenseKey.
14.3.2 Registering the license contract
After selecting the license pool for the new license option, the next step is to register the license contract the license
is based on. The section "Select or enter license contract" (from tab "New license") defaults to a standard contract
with ID default. The default setting can be used if the license contract is implied by purchasing the software or the
contract is documented some other way. Otherwise the contract can be selected from the table or a new contract can
be registered from the context menu. The license contract dataset comes with data fields for partner, conclusion date,
notification date and expiration date. The entry field notes can hold some additional notes like the location where the
contract document is kept. The unique contract ID (licenseContractId) is for identifiying the license contract in the
license management database. When entering a new license contract, a new unique ID is constructed based on the
current date and time stamp. This ID can be changed before saving the new data set. When saving the data, the opsi
service checks whether the ID is unique. In case it is not, a new ID is generated and cannot be changed any more.
14.3.3 Configuring the license model
The third part of the Tab "New license" is named "Configure license" and is for registering the license model and license
data.
Several types of license models are available:
Standard license
Volume license
OEM license
Concurrent license
Each Option is represented by a button. Clicking a button, the form is filled with data for that type of license model.
The license model Standard license means, that this license is valid for a single installation on an arbitrary client.
So the license key (if any) is valid for a single installation only.
A Volume license is valid for a certain number n of installations. In this case the optional license key is used for that
number of installations. Setting n = 0 means, that the number of installations is unlimited within the same network
(campus license).
In case of an OEM license, the license is valid for a dedicated client only. Clients that come with a vendor pre
installed operating system often have this type of license for the pre installed OS and software packets.
The Concurrent license means that a certain number of licenses is available for a variable set of clients. Within
opsi this situation is handled like an unlimited Volume license. The number of actual installations in use has to be
managed by some external license server.
After clicking a button, the automatic generated data include a generated unique ID (derived from date and time
stamp). This ID can be changed as desired.
It depends on the type of license model, which of the other fields can or cannot be changed.
The field "Expiration date" defines the expiration date of the license in a technical sense. (This column of the license
is for future use).
14.3.4 Saving the data
The "Send" button sends the data to the opsi service to save them permanently to the opsi data base (if they are
consistent and no errors occur).
While proceeding this, data records will be generated for the new software license based on the selected software
contract and the new license option assigned to that.
The list of available license options at the bottom of the window will be refreshed with the new license option selected.
If necessary, the license key can be changed then.
14.4 Editing licenses
For ninety percent of the use cases editing the license data with the tabs "License pools" and "New license" will do.
But there might be some special cases affording to edit license data more specific and explicit. Therefore the tab "Edit
licenses" presents the license data in three tables, representing the internal data structure and allowing to adapt the
data for some special cases.
License management: tab Lizenzierungen bearbeiten
Figure 62 License management: tab "Edit licenses" from the license management window
Based on this direct data access, the following chapter shows how to configure a special license, like the Microsoft
Vista or Windows 7 professional downgrade option for installing Windows XP.
14.4.1 Example downgrade option
Downgrade option means, that instead of the software purchased, also the preceding version can be installed. For
instance installing Windows XP based on a Windows Vista license. In this case, the license key also can be used for
an installation, which it wasnt meant for in the first place.
In the opsi license model this case can be configured like this:
From the tab "New license" the Vista license is to be registered as usual, resulting in a new license option, which is
displayed in the list of license options at the bottom of the window. This new license option is based on a new software
license identified by softwareLicenseId.
License management: copying the licene ID
Figure 63 License management: copying the license-ID to the license options from the context menu
This softwareLicenseId is needed for the further configuration steps. You can keep it in mind or copy it with drag&drop.
You can as well look for the ID in the "Available license options" list of the "Edit licenses" tab. The context menu
supports copying the ID.
The important step now is to connect this softwareLicenseId to an additional license pool.
Therefore a new record has to be registered from the "Available license options" table of the "Edit licenses" tab. The
fields of the new record have to be filled with the softwareLicenseId and the ID of the additional license pool (in this
case the pool for Windows XP licenses). For installing Windows XP based on this license, an applicable Windows XP
license key already in use by another client has to be added.
After saving the new record, there are two different license options based on the same software license! The opsi service
counts the use of either of them as an installation deducting from the maximum installation count. So in case of a
downgrade license (with maxInstallations = 1), the opsi service delivers a license key for a Vista installation or for a
XP installation, but not for both of them.
14.5 Assignment and release of licenses
Using a license option by installing the software on a client results in the actual licensing (which is the use of the
license option).
In the opsi context installations are done script based and automatically, which is the client running the Winst script
invokes some calls to the central opsi service.
The following chapters introduce some of these service calls, which are relevant for the license management. For further
information about Winst and opsi commands see the documentation on Winst and opsi.
14.5.1 opsi service calls for requesting and releasing a license
The opsi service call for requesting a license option and retrieving the license key for doing the installation (as
transmitted by a Winst script) is
getAndAssignSoftwareLicenseKey
The parameters to be passed are the client hostID (hostID of the client where the software is to be installed) and the
ID of the license pool the license is requested from. Instead of the licensePoolId also an opsi-product ID or a Windows
Software ID can be passed, if they are connected to a license pool within the opsi license management.
The use of a license option can be released by calling:
deleteSoftwareLicenseUsage
Again the parameters to be passed are the hostID and alternatively the licensePoolId, productID or Windows Software
ID. Calling this service releases the license option and returns it to the pool of available license options.
For the complete documentation of opsi service calls see below.
14.5.2 opsi-winst script calls for requesting and releasing of licenses
The opsi-winst provides the client related calls as opsi-winst commands.

A opsi-winst script can make a call to the function DemandLicenseKey to get a license key for installing. The parameters
to be passed are:
DemandLicenseKey (poolId [, productId [, windowsSoftwareId]])
The return value is the license key (can be empty) as a string:
set $mykey$ = DemandLicenseKey ("pool_office2007")
The returned license key can be used by other script command for installing the software.
For releasing a license option and license key (as to be used in a opsi-winst deinstallation script) the command
FreeLicense is available with the following syntax:
FreeLicense (poolId [, productId [, windowsSoftwareId]])
The boolean function
opsiLicenseManagementEnabled
can be used to check whether the opsi license management is enabled and can be used for scripting:
if opsiLicenseManagementEnabled
else
set $mykey$ = IniVar("productkey")
The service calls can be invoked from the command line tool opsi-admin.
Parameters marked with * are optional.
14.5.3 License contracts
method createLicenseContract(*licenseContractId, *partner, *conclusionDate, *notificationDate, *expirationDate, *notes)
This method registers a new license contract record with the ID licenseContractId. If no licenseContractId is passed,
it will be generated automatically. Using the licenseContractId of an existing contract, this contract can be edited.
The parameters partner (co-contractor) and notes are strings and can be filled with any information desired. The pa-
rameters conclusionDate (date of conclusion of the contract), notificationDate (date for a reminder) and expirationDate
(expiration date of the contract) are passed in the format YYYY-MM-DD (e.g. 2009-05-18).
The method returns the licenseContractId of the contract.
else
set $mykey$ = IniVar("productkey")
With the string returning functions

getLastServiceErrorClass
and
getLastServiceErrorMessage
error states can be detected and handled, e.g. if there is no license available:
if getLastServiceErrorClass = "None"
comment "no error"
endif
14.5.4 Manual administration of license use
Within the opsi config editor, the licenses registered by the opsi service are listed on the tab "Licenses usage":
License management: tab Licenses usage
Figure 64 License management: tab "Licenses usage" from the license management window
From this tab, licenses also can be managed manually. This can be useful, if a licensed software is not integrated into
the opsi deployment, but installed manually on just a few clients.
These are the functions for manual license management in detail:
"Delete row" (available from the context menu) releases a license option.
"Reserve license for client" at the bottom of the window is to create a license reservation for a dedicated client.
By editing the field "licenseKey" from the "Usage of licenses" table, the license key can be changed.
14.5.5 Preservation and deletion of license usages
If a software packet is reinstalled, the call to the opsi-winst function DemandLicenseKey will return the same license
option and license key as had been used before.
In case this is not favoured, the former license option has to be released by calling the opsi-winst command FreeLicense,
or by calling the opsi service call deleteSoftwareLicenseUsage or deleting the license use manually.
So, if not explicitly deleted, the license usages are preserved when reinstalling a client.
For releasing the licenses, they can be deleted from the tab "Licenses usage" or can be deleted by the service call
deleteAllSoftwareLicenseUsages
passing the client host name to delete the license uses from.
14.6 Reconciliation with the software inventory
The tab "Reconciliation" lists for each client and for each license pool whether a use of this license pool is registered
by opsi ("used_by_opsi") and if the software inventory (swaudit) on that client reported a software, that requires a
license option from that pool (Swinventory_used).
To evaluate the results from swaudit, the relevant Software IDs (as found in the client registry) have to be associated
with the appropriate license pool (tab "License pools").
When data matching with the software inventory, the license management counts not more than one license per client
and license pool. So if the license pool office2010 is connected with ten different patterns from software inventory,
indicating that office2010 is installed on this client, this is (regarding the licenses usage count) counted as a single
installation, although all of the detection patterns might to be found on the client.
"License management: tab "Reconciliation" (data matching) with the inventory
Figure 65 License management: tab "Reconciliation" (data matching) with the inventory
As usual, this table can be copied as Drag & Drop and for instance pasted to a spreadsheet program. If the opsi-configed
process has got the required access rights (running standalone and not from the applet), the table also can be printed
from the context menu.
14.7 Licenses usage overview
The tab "Statistics" displays a summary of the different license pools, showing the total number of license options
(license_options) and how many of them are in use (used_by_opsi) or still available (remaining opsi).
License management: tab Statistics from the license management window
Figure 66 License management: tab "Statistics" from the license management window
In addition to the number of license uses registered by opsi (used by opsi) and the currently available licenses (remain-
ing. . . ) the ovierview also shows the total number of detected installations, that require a license (SWinventory_used).
The data from the column SWinventory_used are based on the registry scans from the opsi-product swaudit and the
assignment of the Windows software IDs (as they are found in the registry) to the license pools (as registered with the
opsi license management (tab "License pools", see Section 14.2).
From the context menu the table can be printed (because of restricted access rights not available from the applet),
with drag&drop data can be copied to e.g. a spreadsheet.
14.7.1 In case of downgrade option
If a downgrade option has been configured (see Section 14.4.1), this appears in the overview and statistics like this:
A single downgrade license results in a license option for at least two different license pools, but only one of them can
be requested for an installation. So using a downgrade license option decreases the number of available license options
(remaining_opsi) in each of the license pools concerned by that downgrade option by 1. So this looks like a single
installation reduces the number of available license options by 2, which, in this case, actually is the fact.
14.8 Service methods for license management
The service methods for license management can be called from the command line tool opsi-admin. So they are
accessible for scripting, e.g. to read license keys from a file.
Examples can be found in the products license-test-. . . .opsi from http://download.uib.de/opsi4.0/products/license-

management/. After installing the packets with opsi-package-manager -i *.opsi, in the directory /opt/pcbin/in-
stall/<product name> the corresponding scripts: create_license-*.sh can be found.
As an example here the script create_license-mixed.sh (the current version comes with the download packet).
#!/bin/bash
# This is a test and example script
# (c) uib gmbh licensed under GPL
PRODUCT_ID=license-test-mixed
# read the license key from a file
# myretailkeys.txt has one licensekey per line
MYRETAILKEYS=cat myretailkeys.txt
# myoemkeys.txt has one pair: <licensekey> <hostid.domain.tld> per line
MYOEMKEYS=cat myoemkeys.txt
# some output
echo "$PRODUCT_ID"
# this is the function to create the oem licenses

#############
createlic ()
{
while [ -n "$1" ]
do
#echo $1
AKTKEY=$1
shift
#echo $1
AKTHOST=$1
shift
echo "createSoftwareLicense with oem key: ${PRODUCT_ID}-oem-${AKTKEY} for host ${AKTHOST}"
MYLIC=opsi-admin -dS method createSoftwareLicense "" "c_$PRODUCT_ID" "OEM" "1" "${AKTHOST}" ""
opsi-admin -d method addSoftwareLicenseToLicensePool "$MYLIC" "p_$PRODUCT_ID" "${PRODUCT_ID}-oem-${AKTKEY}"
done
}
#############
# here the script starts
# delete the existing license pool and all connected licenses

# ATTENTION: never (!) do this on a productive system
echo "deleteLicensePool p_$PRODUCT_ID"
opsi-admin -d method deleteLicensePool "p_$PRODUCT_ID" true
# delete the existing license contract

echo "deleteLicenseContract c_$PRODUCT_ID"
opsi-admin -d method deleteLicenseContract "c_$PRODUCT_ID"
# create the new license pool

# the used method has the following syntax:
# createLicensePool(*licensePoolId, *description, *productIds, *windowsSoftwareIds)
echo "createLicensePool p_$PRODUCT_ID"
opsi-admin -d method createLicensePool "p_$PRODUCT_ID" "opsi license test" \["$PRODUCT_ID"]\ \["$PRODUCT_ID"\
]\
# create the new license contract

# the used method has the following syntax:
# createLicenseContract(*licenseContractId, *partner, *conclusionDate, *notificationDate, *expirationDate, *notes)
echo "createLicenseContract c_$PRODUCT_ID"
opsi-admin -d method createLicenseContract "c_$PRODUCT_ID" "uib gmbh" "" "" "" "test contract"
# create the new license and add the key(s)

# the used methods have the following syntax:
# createSoftwareLicense(*softwareLicenseId, *licenseContractId, *licenseType, *maxInstallations, *boundToHost, *\
expirationDate)
# addSoftwareLicenseToLicensePool(softwareLicenseId, licensePoolId, *licenseKey)
# create the retail licenses:

for AKTKEY in $MYRETAILKEYS
do
echo "createSoftwareLicense with retail key: ${PRODUCT_ID}-retail-${AKTKEY}"
MYLIC=opsi-admin -dS method createSoftwareLicense "" "c_$PRODUCT_ID" "RETAIL" "1" "" ""
opsi-admin -d method addSoftwareLicenseToLicensePool "$MYLIC" "p_$PRODUCT_ID" "${PRODUCT_ID}-retail-${AKTKEY}"
done
# create the oem licenses

createlic $MYOEMKEYS
# create the volume licenses

echo "createSoftwareLicense with volume key: ${PRODUCT_ID}-vol-key"
MYLIC=opsi-admin -dS method createSoftwareLicense "" "c_$PRODUCT_ID" "VOLUME" "10" "" ""
opsi-admin -d method addSoftwareLicenseToLicensePool "$MYLIC" "p_$PRODUCT_ID" "${PRODUCT_ID}-vol-key"#
14.9 Example products and templates
In the uib download section at

http://download.uib.de/opsi4.0/products/license-management/
there are four example products available. One for each type of license model, as there are Retail, OEM and Volume
license type, as well as a product combining all of them.
These example products use as an example some licenses and release them again. So using them leaves some marks in
the software inventory, that might be of influence to reconciliation and statistics.
All of these products contain a shell script to automatically generate license pools, license contracts and license options.
The standard template for opsi-winst scripts opsi-template also contains some examples for using the opsi license
management.
15 opsi WAN/VPN extension
The WAN/VPN extension module allows to integrate clients, that are connected via low speed connections. This
chapter is about configuring and maintaining the opsi WAN/VPN extension.
15.1 Preconditions for using the WAN/VPN extension
Currently the WAN/VPN extension module is in the cofinancing process. See cofinanced opsi extensions.
There are some preconditions to use the WAN/VPN extension module. The feature product groups is required, which
is available with opsi 4.0 and above. Also the packets opsi-client-agent and opsi-configed are required, which come
with version 4.0.1.
Table 2: Required packets
opsi-Packet version
opsi-client-agent >=4.0.1-1
opsi-winst >=4.10.8.12
python-opsi >=4.0.1-7
opsi-configed >=4.0.1.6-1
15.2 General overview of the WAN/VPN extension
opsi software deployment is mainly doing the following steps:

The opsi-login-blocker at client system startup prevents the users from logging on.
The opsiclientd service running on the client connects the opsi-configserver.
If any product actions are set for the client, it mounts a share from the opsi-depot.
The opsi-winst is starting and also connects to the opsi-configserver.
The opsi-winst executes the product actions, using the share from the opsi-depot.
If a reboot is required, it executes and the process starts all over.
When all the product actions are completed, the log files are transferred to the opsi-configserver and the user logon
is unblocked.
Now we will look at the special circumstances of a client, which is located in a remote branch, connected via WAN to
the LAN, where the opsi-configserver and opsi-depotserver are:
During communication with the opsi-configserver small amounts of data are transferred, so there is no noticeable
slowdown of the software deployment in a WAN.
But processing the product actions might consume a very long time, depending on the packet sizes, bandwidth and
latency of the WAN connection. There also might occur timeouts during file access.
Therefore, during the installation is processing, the user has to wait for an unreasonably long time before logon is
granted.
As an alternative to providing a dedicated opsi-depotserver in the remote branch network, the remote clients can be
connected via WAN/VPN extension module. Using the WAN/VPN extension module, the opsi-client-agent can be
configured this way:
At system startup, if there are no opsi-products cached and ready for installation, the user can logon immediately.
When there are product actions set for the client, the opsiclientd, which is running on the client, starts downloading
the required installation files from the opsi-depot to the local file system. This is done in the background while the
user is working. The maximum download bandwidth can be configured and also can be dynamically adapted to the
current network traffic status.
When the synchronization of the opsi-products is completed, a reboot request is triggered.
The logged on user can accept the reboot request, or the client will be rebooted at some time later on.
At the next system startup, the cache is found to be filled with the opsi-products to be installed and the installation
starts. In this case, the installation will use the downloaded files from the local file system, which increases the speed
of installation even compared to a standard LAN installation.
Now we examine the situation of a notebook, which at system startup often cannot connect the opsi-configserver:
Trying to connect the opsi-configserver at system startup will result in a timeout.
Connecting the opsi-configserver might be possible when a user logs on and a VPN connection to the corporate
network is established.
Without connection the opsi-configserver no software deployment is available.
This situation also can be solved by using the WAN/VPN extension module.
The opsi-client-agent can be configured the following way:
At system startup, if there are no opsi-products cached and ready for installation, the user can logon immediately.
Triggered by network activation or a by timer event, the opsiclientd running on the client tries to connect the
opsi-configserver.
If the opsi-configserver is reachable, the opsiclientd starts to:
synchronize the configurations
download the required files from the opsi-depot to the local file system.
In combination with the opsi extension module Dynamic Depot Selection, the download is done from the best
fitting opsi-depot.
When the synchronization of the opsi-products is completed, a reboot request is triggered.
The logged on user can accept the reboot request or the client will be rebooted at some time later on.
At the next system startup, the cache is found to be filled with the opsi-products to be installed and the installation
starts. In this case, the installation will use the downloaded files from the local file system, which increases the speed
of installation even compared to a standard LAN installation. So the opsiclientd takes over the function of both the
opsi-configserver and the opsi-depotserver.
At the next connect to the opsi-configserver the results of the installation process (configuration change, log files
. . . ) will be synchronized.
The download mechanism of product synchronization is multiple interruptible and will continue at the point of inter-
ruption. So files that are already downloaded will not have to be downloaded again.
The WAN/VPN extension module allows to connect clients, that are outside of the secure corporate network. Therefore
additional security mechanisms are required regarding the communication between client and server.
So the opsiclientd now offers the ability to verify the identity of an serveur opsi. Therefore the key pair of the SSL
certificate of the opsiconfd is used.
By this mechansim the opsi-configserver as well as the opsi-depotserver can be verified, assumed the communication
is performed via opsiconfd and SSL. In case of an opsi-depot the file access must be done by the opsiconfd using
HTTPS/WEBDAVS. Access done via CIFS/SMB will not be checked.
15.3 Caching of opsi-products

Caching of opsi-products is done by the ProductCacheService, which is part of the opsiclientd.
The ProductCacheService synchronizes the local copy of an opsi-product with the current version of the corresponding
opsi-products on the opsi-depot. The location of the local product cache can be configured and defaults to %SystemDr
ive%\opsi.org\cache\depot.
15.3.1 Communication Protocol for accessing an opsi-depot
For transferring the product files, two different protocols are used:
CIFS/SMB
HTTP(S)/WEBDAV(S)
In case of using CIFS/SMB, a connection to the depotRemoteUrl will be established as configured with the properties
of the opsi-depot. In case of using HTTP(S)/WEBDAV(S), the depotWebdavUrl is connected, which as well is to be
configured with the properties of the opsi-depot.
Which protocol is to be used, can be configured client specific by the opsi-config-object clientconfig.depot.proto
col. Available values to be set as clientconfig.depot.protocol are cifs and webdav.
Note
Also the opsi-linux-bootimage is evaluating this setting and uses the specified protocol.
15.3.2 Using the .files file for Synchronization
The synchronization process is based on the file <product-id>.files, which is located in the base directory of each
opsi-product on the opsi-depot. This file contains information about the files, directories ans symbolic links used by an
opsi-product. Each line of that file contains such information. Different types of information are separated by a blank.
The first character of a line defines the type of the following entry. Available values are:
d for a directory
f for a file
l for a symbolic link
Separated by a blank follows the relative path, which is single quoted.
The next entry gives the sizes of the file (which is 0 for directories and symbolic links).
The final entry in case of a file is the MD5-sum of the file, in case of a symbolic link it is the target referred to by the
symbolic link.
Example excerpt of a .files file:
d utils 0
f utils/patch_config_file.py 2506 d3007628addf6d9f688eb4c2e219dc18
l utils/link_to_patch_config_file.py 0 /utils/patch_config_file.py
The .files file is generated automatically when installing opsi-product-packages (after running the postinst-Script).
AVERTISSEMENT
When using the WAN/VPN extension, the files of opsi-products on the opsi-depot should not be changed manually,
otherwise the information contained in the .files file would be outdated, causing errors during the synchronization
process.
15.3.3 Internal processing of opsi-product caching
The synchronization of a local copy of an opsi-product processes as follows:

The .files file of the opsi-product is transferred to the local client.
Then it is checked, whether there is enough local disk space available to cache the opsi-products. If there isnt enough
disc space available, some old opsi-products will be deleted, which havent been used (synchronized) for a long time.
The local caching directory will be created if it doesnt exist.
Referring to the .files file, any old files and directories, which arent in use anymore, will be deleted from the local
opsi-product cache.
Then the .files file will be processed in the following order.
missing directories are created.
missing files are transferred.
existing files will be checked by size and MD5-sum and be synchronized again if necessary.
The synchronization results in an exact local copy of the opsi-product from the opsi-depot.
Note
On windows systems, no symbolic links will be created. Instead of links there will be copies of the link target.
When the opsi-product has completed successfully,

the status of products_cached will turn to true (and stays true in case of a system restart, see: Section 7.3.6).
a sync completed event will be triggered.
15.3.4 Configuring the opsi-product caching
The opsi-product caching is configured in the section [cache_service] of the opsiclientd.conf.

product_cache_max_size (integer): The maximum size of the opsi-product cache in byte. This is important to limit
the disk space to be used by opsi-product caching.
storage_dir (string): the path to the directory, in which the base directory depot for the opsi-product caching is
to be created.
Further configurations can be done event specific.
Within an event configuration section [event_<event-config-id>] the following options are available:
cache_products (boolean): if the value of this option is true, in case of the event the ProductCacheService will start
to cache opsi-products, for which a product action is set. If additionally the value of the option use_cached_products
is set to true, the further processing of this section will be suspended until the caching of opsi-products is completed.
cache_max_bandwidth (integer): the maximum bandwidth in byte/s to be used for caching. If this value is set to 0
or less, the bandwidth is unlimited.
cache_dynamic_bandwidth (boolean): if the value of this option is set to true, the bandwidth will be adapted
dynamically. Therefore the network traffic at the network interface to the opsi-depot will be monitored. If any traffic
is detected, which is not caused by the opsi-product caching, the bandwidth for the caching will be sharply reduced,
to allow other processes to work at (almost) full speed. If the caching works at reduced bandwidth and no more
other network activity but the opsi-product caching is detected, the caching process will continue with unlimited
bandwidth. The value of cache_max_bandwidth will be used to limit the maximum dynamic bandwidth.
use_cached_products (boolean): if the value of this option is set to true, the local opsi-product cache will be used
for processing product actions. If caching of the opsi-products is not completed, the processing of this event will stop
and return an error code.
15.4 Caching of configurations
The caching of configurations is done by the ConfigCacheService, which is part of the opsiclientd.
The ConfigCacheService synchronizes a local client-cache-backend with the config backend of the opsi-configserver.
The opsiclientd provides per WebService an access point to the backend and thereby provides quite the same func-
tionality as the opsiconfd.
15.4.1 The local client-cache-backend
The local client-cache-backend is based on SQLite and mainly consists of a local working copy, a snapshot an a
modification tracker, which records all changes of the local working copy.
The base directory of the config cache can be configured and defaults to %SystemDrive%\opsi.org\cache\config.
The snapshot reflects the configuration status on the opsi-configserver at the time of the last synchronization.
At the start of the processing, the local working copy is a copy of the snapshot, but will be modified during processing.
15.4.2 Internal processing of configuration synchronizing
The synchronization of the local changes of the client-cache-backend with the config backend of the opsi-configserver
is processed as follows:
The changes of the local working copy registered by the modification-tracker are transferred to the opsi-configserver.
Any changes of the configuration on the opsi-configserver since the last synchronization will be detected by comparing
to the snapshot. If there are any conflicts deteced, the following rules apply:
In case of inventory data, the local client data have priority.
In case of action requests, the value from the opsi-configserver has priority.
In case of installation status and action result, the client data have priority.
The software licenses in use are given by the local client. Any unused licences, which have been reserved during
replication, will be released again.
The opsi-configserver has priority for the status of opsi-config-objects and proprits du produit.
The modification tracker will be cleared.
The logfiles will be transferred.
The config backend replication of the opsi-configserver to the client-cache-backend is processed as follows:
The replication only takes place, if any action requests are set on the opsi-configserver. The product action always
does not count in this respect. The replication process will start only if the status of action requests is changed since
the last replication.
The modification tracker and the local working copy are cleared.
The configurations required for local processing will be replicated.
If action requests are set for opsi-products which are marked as to require a license, the required software license
will be reserved from a license pool, which is assigned to that opsi-product.
Additionally required data, as there are the auditHardwareConfig and the modules, will be transferred.
The snapshot and the local working copy will be updated, so they have the same content.
A successful replication from server to client results in:
The status of config_cached is set to true (and stays true in case of a system restart, see: Section 7.3.6).
An event of type sync completed will be triggered.
15.4.3 Configuration of config caching
The configuration of the config caching is mainly done event specific:

Within an event configuration section [event_<event-config-id>], the following options are available:
sync_config_to_server (boolean): if the value of this option is set to true, the ConfigCacheService in case of that
event starts to transfer the changes registered by the modification tracker to the opsi-configserver. The process will
wait for that task to complete.
sync_config_from_server (boolean): if this value is set to true, the ConfigCacheService starts with the replication.
If additionally the value of the option use_cached_config is set to true, the processing of this event is suspended
until the replication is completed.
use_cached_config (boolean): if the value of this option is set to true, the client-cache-backend will be used for
processing the product actions. If the synchronization is not completed, the processing of this event will be stopped
and return an error code.
post_sync_config_to_server (boolean): has the same functionality as sync_config_to_server, but will be eval-
uated after the product actions have been completed.
post_sync_config_from_server (boolean): has the same functionality as sync_config_from_server, but will be
evaluated after the product actions have been completed.
15.5 Recommended configuration when using the WAN/VPN extension module
The opsi-client-agent-package comes with a opsiclientd.conf prepared for the WAN/VPN extension.
For activating the WAN/VPN extension, just enabling of some events and disabling of some others is required.
The configuration of the opsi-client-agent also can be done from the web service (see: Section 7.3.6), so it is recom-
mended to create the following opsi-config-objects:
opsiclientd.event_gui_startup.active (boolean, default: true)
opsiclientd.event_gui_startup{user_logged_in}.active (boolean, default: true)
opsiclientd.event_net_connection.active (boolean, default: false)
opsiclientd.event_timer.active (boolean, default: false)
By these opsi-config-objects, events can be enabled or disabled client specific. The opsi-config-objects can be created
using the opsi-configed or opsi-admin.
For creating the opsi-config-objects by opsi-admin, the following commands have to be executed on the opsi-
configserver:
opsi-admin -d method config_createBool opsiclientd.event_gui_startup.active "gui_startup active" true
opsi-admin -d method config_createBool opsiclientd.event_gui_startup{user_logged_in}.active "gui_startup{user_logged_in\
} active" true
opsi-admin -d method config_createBool opsiclientd.event_net_connection.active "event_net_connection active" false
opsi-admin -d method config_createBool opsiclientd.event_timer.active "event_timer active" false
The default values are as they come with the special opsiclientd.conf.
For a WAN/VPN client, which shall do caching of configurations and opsi-products, the opsi-config-objects have to be
configured as follows:
opsiclientd.event_gui_startup.active: false
opsiclientd.event_gui_startup{user_logged_in}.active: false
opsiclientd.event_net_connection.active: true
opsiclientd.event_timer.active: true
The client specific opsi-config-objects can be set by opsi-configed or opsi-admin.
To set the opsi-config-objects by opsi-admin, the following commands have to be executed on the opsi-configserver:
(in this example the client has the opsi-host-Id vpnclient.domain.de):
opsi-admin -d method configState_create vpnclient.domain.de opsiclientd.event_gui_startup.active false
opsi-admin -d method configState_create vpnclient.domain.de opsiclientd.event_gui_startup{user_logged_in}.active false
opsi-admin -d method configState_create vpnclient.domain.de opsiclientd.event_net_connection.active true
opsi-admin -d method configState_create vpnclient.domain.de opsiclientd.event_timer.active true
This configuration will process as follows:

At system start of the client there will be no connection established to the opsi-configserver.
When the activation of a network interface is detected, a connection to the opsi-configserver will be established (if
possible) and the synchronization starts as background task.
A timer-Event will be established, which tries at regular intervals to trigger the synchonization process.
15.5.1 Setting the protocol for caching of opsi-products
The caching of opsi-products can be done via the protocols HTTPS/WEBDAVS or CIFS/SMB.
When using webdav, access to the opsi-depot is performed by the opsiconfd.
advantages:
easy firewall configuration, for it requires just port 4447.
verify of the SSL-certificate of the opsi-depot available.
disadvantage:
the opsiconfd generates more traffic on the opsi-depot.
By using cifs, access to the opsi-depot is done via SAMBA.
advantage:
the SAMBA-server shows a good performance, is resource-conserving and well scaleable.
disadvantages:
the firewall configuration is more complicated, access to the SAMBA ports is required.
no verify of the SSL-certificate of the opsi-depot is available.
An instruction for configuring the protocols is to be found in the chapter Section 15.3.1.
ospclientd-infopage-wan-cached
Figure 67 processing of an installation with WAN extension as displayed in the opsiclientd infopage
15.5.2 Verifying the server certificates
To activate the verifying of SSL certificates, in the opsiclientd.conf within the section [global], the option ver
ify_server_cert is to be set to true. This, during connection to an opsiconfd, results in verifying the serveur
opsi by using the SSL certificate. The server certificates will be stored in the directory %SystemDrive%\opsi.org\
opsiclientd\server-certs. The name of the certificate is combined from the server address (IP or name) and the
extension .pem. If at connection time no stored certificate is to be found, no checking will be done.
ASTUCE
To publish a changed certificate, the old certificate stored on the clients has to be deleted. This can be done by the
RPC-method deleteServerCerts, which is available from the control interface of the opsiclientd.
16 opsi-server with multiple depots
16.1 Concept
Supporting multiple depot shares in opsi aims at the following targets:

central configuration data storage and configuration management
providing the software depots on local servers
automated deployment of software packages from the central server to the local depots
Accordingly, it is implemented:
All configuration data is stored on the central opsi-configserver.
All clients connect to this opsi-configserver in order to request their configuration data. The configuration data
comprise the information on method and target of the opsi-depotserver connection.
All installable software is stored on opsi-depotservers.
The opsi-depotservers have as well an opsipxeconfd running by which they provide boot-images to clients via
PXE/tftp.
opsi-package-manager
A program to (de-)install opsi packages on one ore more opsi-depotservers.
The opsi packages are copied via webdav protocol to the opsi-depotservers and are installed from the opsiconfd via
a web service call.
opsi-configed supports the management of multiple depots.
Clients connected to different depots can be managed in one bundle if the involved depots are synchronized (have
all product packages in identical versions).
The following schema gives a more detailed view on the communication between the components of a opsi multi depot
share environment.
Scheme: opsi-config server without attached depot server
Figure 68 Scheme: opsi config server without attached depot server (single location)
Scheme: opsi-config server with attached depot server
Figure 69 Scheme: opsi config server with attached depot server (multi location)
16.2 Creating a (slave) depot-servers
In order to create a opsi-depotserver you have to install a standard serveur opsi. This serveur opsi can be configured
to act as opsi-depotserver by calling the script opsi-setup --register-depot at that server which should be become
the opsi-depotserver. Because this script does not only reconfigure the local server, but also registers this server as
opsi-depotserver with the central opsi-configserver, username and password of a member of the opsiadmin group have
to be supplied here.
Example:
svmdepotde.svm.local will be reconfigured as opsi-depotserver and registered at the opsi-configserver sepiella.svm.local:
svmdepotde:~# opsi-setup --register-depot
Now you will be prompted for the opsi-configserver you want to connect to in order to make the server you are working
on to a opsi-depotserver at the selected opsi-configserver. To do this you have to give user name and password of a
member of the group opsiadmin at the opsi-configserver.
opsi-setup-registerdepot-1
Figure 70 opsi-setup --register-depot : Enter opsiadmin account for the opsi-configserver
Now the opsi-depotserver settings will be displayed and may be changed.

Normally you do not have to change anything.
opsi-setup-registerdepot-2
Figure 71 opsi-setup --register-depot : depot settings
After the data input is completed the configuration process will start:
[5] [Apr 06 12:32:19] Getting current system config (opsi-setup|70)
[5] [Apr 06 12:32:19] System information: (opsi-setup|117)
[5] [Apr 06 12:32:19] distributor : Debian (opsi-setup|118)
[5] [Apr 06 12:32:19] distribution : Debian GNU/Linux 5.0.8 (lenny) (opsi-setup|119)
[5] [Apr 06 12:32:19] ip address : 172.16.166.33 (opsi-setup|120)
[5] [Apr 06 12:32:19] netmask : 255.255.255.0 (opsi-setup|121)
[5] [Apr 06 12:32:19] subnet : 172.16.166.0 (opsi-setup|122)
[5] [Apr 06 12:32:19] broadcast : 172.16.166.255 (opsi-setup|123)
[5] [Apr 06 12:32:19] fqdn : svmdepotde.svm.local (opsi-setup|124)
[5] [Apr 06 12:32:19] hostname : svmdepotde (opsi-setup|125)
[5] [Apr 06 12:32:19] domain : svm.local (opsi-setup|126)
[5] [Apr 06 12:32:19] win domain : OPSI (opsi-setup|127)
[5] [Apr 06 12:46:03] Creating depot svmdepotde.svm.local (opsi-setup|2342)
[5] [Apr 06 12:46:03] Getting depot svmdepotde.svm.local (opsi-setup|2345)
[5] [Apr 06 12:46:03] Testing connection to config server as user svmdepotde.svm.local (opsi-setup|2354)
[5] [Apr 06 12:46:04] Successfully connected to config server as user svmdepotde.svm.local (opsi-setup|2359)
[5] [Apr 06 12:46:04] Updating backend config /etc/opsi/backends/jsonrpc.conf (opsi-setup|2361)
[5] [Apr 06 12:46:04] Backend config /etc/opsi/backends/jsonrpc.conf updated (opsi-setup|2373)
[5] [Apr 06 12:46:04] Updating dispatch config /etc/opsi/backendManager/dispatch.conf (opsi-setup|2375)
[5] [Apr 06 12:46:04] Dispatch config /etc/opsi/backendManager/dispatch.conf updated (opsi-setup|2388)
[5] [Apr 06 12:46:04] Setting rights (opsi-setup|410)
[5] [Apr 06 12:46:06] Setting rights on directory /tftpboot/linux (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory /home/opsiproducts (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory /var/log/opsi (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory /etc/opsi (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory /var/lib/opsi (opsi-setup|482)
[5] [Apr 06 12:46:06] Setting rights on directory /opt/pcbin/install (opsi-setup|482)
[5] [Apr 06 12:46:27] Restarting services (opsi-setup|2392)
[5] [Apr 06 12:46:35] Configuring client user pcpatch (opsi-setup|347)
[5] [Apr 06 12:46:35] Creating RSA private key for user pcpatch in /var/lib/opsi/.ssh/id_rsa (opsi-setup|361)
[5] [Apr 06 12:46:35] Setting rights (opsi-setup|410)
[5] [Apr 06 12:46:38] Setting rights on directory /var/lib/opsi/.ssh (opsi-setup|482)
16.3 package management with multiple depots
see also:
Section 4.4
Section 4.5
In or to manage opsi-packages with different opsi-depotserver the opsi-packet-manager got the option -d ( or --
depot). With this option you can give the target opsi-depotserver for the installation. Using the keyword ALL the
opsi package will be copied to /var/lib/opsi/repository on all known opsi-depotservers and then installed via a
web service call.
If you dont give the option -d, the opsi package will be only installed on the local server (without upload to /var/
lib/opsi/repository).
Example:
Install the package softprod_1.0-5.opsi on all known opsi-depotservers:
opsi-package-manager -d ALL -i softprod_1.0-5.opsi
In order to get informations about what are the differences between depots you may call opsi-packet-manager with
the option -D (or --differences).
Example:
Show the differences between all known depots regarding the product mshotfix
opsi-package-manager -D -d ALL mshotfix
mshotfix
vmix12.uib.local : 200804-1
vmix13.uib.local : 200804-1
bonifax.uib.local: 200805-2
17 Dynamic Depot Assignment
17.1 Introduction
With the standard opsi multi depot support, the clients are assigned to a designated depot. This is now extended
with the option, that for download speed-up, each client can dynamically detect a suitable depot to download software
packets from.
For most cases an assignment according to the IP address might be the easiest and suitable solution. For other network
topologies, e.g. a star topology VPN network, this might not be sufficient.
Therefore a mechanism is required for the client to detect dynamically, which depot to connect for download of software
packets. The specific assignment algorithm and implementation depends on the network topology and other special
customer requirements. So it is best to have this adaptable and configurable.
To offer the option, that the client can detect the suitable depot according to the current network conditions, it must
be ensured, that the alternative depots are synchronized, which means they offer the same software packets. In practice
the depots will not be synchronized at all times. So the list of alternative depots offered to a client is limited to those
depots, which are synchronized with the clients master depot. The master depot of a client is the depot, which the
client is assigned to. So the master depot defines, which software version is to be installed on the client.
The opsi concept for this is as follows:
The opsi config-server provides a client script, which can be requested and executed by the client. This script deter-
mines, which depot is to be used according to the current conditions. The interfaces to the client script are specified
as: the interface to get the list of available servers and the current client configuration (IP address, netmask, gateway)
and to return the result of the selection procedure. Furthermore there are interfaces for logging and user information
about the processing progress.
So the actual implementation within the script can easily be adapted to the requirements of the particular opsi
environment.
Regarding to this concept the single steps of a client connect are as follows:
1. The client connects to the opsi opsi-configserver via web service.
2. The opsi-configserver passes to the client the list of software packets to be installed.
3. The opsi-configserver transmits to the client the script for detecting the best depot and the list of available
depots.
4. The client executes the script and determines the best depot.
5. The client connects the chosen depot to get the required software packets.
6. The client installation status is reported to the opsi-configserver.
17.2 Requirements
This option requires opsi version >= 4.0.

Also at a minimum the following packet versions are required:
o p s i c l i e n t a g e n t 4.0 11
pythono p s i 4 . 0 . 0 . 1 8 1
o p s i c o n f i g e d 4 . 0 . 1 . 5 1
17.3 Configuration
The script for the dynamic depot assignment is expected on the server as:
/etc/opsi/backendManager/extend.d/70_dynamic_depot.conf
To activate the dynamic depot assignment for a client, the following host parameter has to be set:
clientconfig.depot.dynamic = true
This can be done with the opsi-configed from the tab host parameter.
Alternatively this can be done at the command line with the opsi-admin (in this case <client-id> is the FQDN, e.g.
client1.uib.local):
opsi-admin -d method configState_create \
clientconfig.depot.dynamic <client-id> [True]
The result can be checked by calling:

opsi-admin -d method configState_getObjects \
[] {"configId":"clientconfig.depot.dynamic","objectId":"<client-id>"}
17.4 Editing the depot properties
The properties of a depot are partly queried while registering an opsi-server as a depot by executing the command:
opsi-setup --register-depot (see Section 16.2).
The properties of a depot can be edited. This can be done from the management interface as well as from the command
line.
Showing the properties of a depot
Figure 72 Showing the properties of a depot (2nd button from the left)
The depot properties can be called by the button Properties of depots from the management interface (the buttons
are in the upper right corner).
Depot properties from the opsi-configed
Figure 73 Depot properties from the opsi-configed
From the command line the depot properties can be shown by the method host_getObjects. Here e.g. for the depot
dep1.uib.local.
opsi-admin -d method host_getObjects [] {"id":"dep1.uib.local"}
This call results in the following output:

[
{
"masterDepotId" : "masterdepot.uib.local",
"ident" : "dep1.uib.local",
"networkAddress" : "192.168.101.0/255.255.255.0",
"description" : "Depot 1 Master Depot",
"ipAddress" : "192.168.105.1",
"repositoryRemoteUrl" : "webdavs://dep1.uib.local:4447/repository",
"depotLocalUrl" : "file:///opt/pcbin/install",
"isMasterDepot" : true,
"notes" : "",
"hardwareAddress" : "52:54:00:37:c6:8b",
"maxBandwidth" : 0,
"repositoryLocalUrl" : "file:///var/lib/opsi/repository",
"opsiHostKey" : "6a13da751fe76b9298f4ede127280809",
"type" : "OpsiDepotserver",
"id" : "dep1.uib.local",
"depotWebdavUrl" : "webdavs://dep1.uib.local:4447/depot",
"depotRemoteUrl" : "smb://dep1/opt_pcbin/install"
}
]
To edit the depot properties on the command line, the output can be redirected to a file:
opsi-admin -d method host_getObjects [] {"id":"dep1.uib.local"} \
> /tmp/depot_config.json
The resulting file (/tmp/depot_config.json) can now be edited and then written back with the following command:
opsi-admin -d method host_createObjects < /tmp/depot_config.json
The depot properties, which are relevant for the dynamic depot assignment, are as follows:
isMasterDepot
Must be true for assigning a client to that depot.
networkAddress
Network address for that depot. The network address can be specified in two different notations:
network/netmask, example: 192.168.101.0/255.255.255.0
network/maskbits, example: 192.168.101.0/24
Whether the networkAddress is actually evaluated for the depot assignment depends on the script algorithm. The
default algorithm, as provided by uib, uses that parameter.
17.5 Synchronizing the depots
The opsi tools for synchronizing the depots are:

opsi-productupdater
The opsi-package-manager, when installing an opsi packet, can be configured by the parameter -d ALL to install
the packet not only on the current server, but also on all known depots. Example:
opsi-package-manager -i opsi-template_1.0-20.opsi -d ALL
By using the parameter -D the opsi-package-manager can be instructed to list the differences between depots. In
this case the option -d must specify a list of depots or refer to all known depots by -d ALL. Example:
opsi-package-manager -D -d ALL
The opsi-package-manager also is the tool for a push synchronization. Whereas the tool opsi-product-updater
is meant for pull synchronization. The opsi-product-updater on the depot servers can be configured as a cronjob.
Therefore in the configuration file of the opsi-product-updater (/etc/opsi/opsi-product-updater.conf) set in
the section [repository_uib] active =false, and in the section [repository_master] active =true. Also, in the same
section, set opsiDepotId to the depot ID (FQDN) to synchronize with. The opsi-product-updater then synchronizes
with the specified depot all the packets in the directory /var/lib/opsi/repository.
Attention
When a packet is installed on an opsi server with the command opsi-package-manager -i, the packet is not
installed to the repository directory. To get the packet to the repository directory, the name of the depot can
be specified by the -d option. Alternatively the upload of the packet to the repository directory can be done by
opsi-package-manager -u <packet name>.
Please refer to the documentation of the tools opsi-package-manager and opsi-product-updater in the opsi manual.
17.6 Processing
If the dynamic depot assignment is activated for a client by the host parameter clientconfig.depot.dynamic, the client
retrieves the script via web service and executes it.
The script to be used for dynamic assignment is:
/etc/opsi/backendManager/extend.d/70_dynamic_depot.conf
Following parameters are passed to the function selectDepot, which is defined in the script:
clientConfig
Information about the current client configuration (hash).
The clientConfig hash keys are currently:
"clientId": opsi host ID of the client (FQDN)
"ipAddress": IP address of the network interface to the opsi-configserver
"netmask" : netmask of the network interface
"defaultGateway": default gateway
masterDepot
Information regarding the master depot (opsi-depotserver-object). The master depot is the depot which the client is
assigned to from the management interface. The attributes of the passed opsi-depotserver-object match the attributes
as given by host_getObjects (see Section 17.4).
alternativeDepots
Information about the alternative depots (list of opsi-depotserver-objects). The list of alternative depots lists the
depots, which are, regarding the required software packets, identical to the master depot.
Based on this information, the assignment algorithm can pick a depot from the provided depot list and return the
opsi-depotserver-object of the chosen depot as the result of the function. If the assignment algorithm does not find a
suitable depot from the list (or if the provided list is empty), the return result should be the master depot object.
17.7 Template of the assignment script

The template script checks the network addresses of the given depots and picks the depot which is in the same network
as the client.
The template script offers example functions for depot detection.
The function depotSelectionAlgorithmByNetworkAddress checks the network addresses of the depots and selects
the depot which is in the same network as the client.
The function depotSelectionAlgorithmByLatency sends ICMP echo-request-packets (ping) to the depots and
selects the depot with the lowest latency.
The function getDepotSelectionAlgorithm is called by the client and returns the algorithm for depot selection.
The template script uses as default the function depotSelectionAlgorithmByNetworkAddress.
# -*- coding: utf-8 -*-
global depotSelectionAlgorithmByNetworkAddress
depotSelectionAlgorithmByNetworkAddress = \
def selectDepot(clientConfig, masterDepot, alternativeDepots=[]):

selectedDepot = masterDepot
logger.info(u"Choosing depot from list of depots:")
logger.info(u" Master depot: %s" % masterDepot)
for alternativeDepot in alternativeDepots:
logger.info(u" Alternative depot: %s" % alternativeDepot)
if alternativeDepots:
import socket, struct
# Calculate bitmask of hosts ipaddress
n = clientConfig[ipAddress].split(.)
for i in range(4):
n[i] = forceInt(n[i])
ip = (n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]
depots = [ masterDepot ]
depots.extend(alternativeDepots)
for depot in depots:
if not depot.networkAddress:
logger.warning(u"Network address of depot %s not known" % depot)
continue
(network, netmask) = depot.networkAddress.split(u/)
while (network.count(.) < 3):
network = network + u.0
if (netmask.find(.) == -1):
netmask = forceUnicode(socket.inet_ntoa(struct.pack(>I,0xffffffff ^ (1 << 32 - \
forceInt(netmask)) - 1)))
while (netmask.count(.) < 3):
netmask = netmask + u.0
logger.debug(u"Testing if ip %s is part of network %s/%s" % (clientConfig[ipAddress], network\

, netmask))
n = network.split(.)
for i in range(4):
n[i] = int(n[i])
network = (n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]
n = netmask.split(.)
for i in range(4):
n[i] = int(n[i])
netmask = (n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]
wildcard = netmask ^ 0xFFFFFFFFL

if (wildcard | ip == wildcard | network):
logger.notice(u"Choosing depot with networkAddress %s for ip %s" % (depot.\
networkAddress, clientConfig[ipAddress]))
selectedDepot = depot
break
else:
logger.info(u"IP %s does not match networkAddress %s of depot %s" % (clientConfig[\
ipAddress], depot.networkAddress, depot))
return selectedDepot
global depotSelectionAlgorithmByLatency
depotSelectionAlgorithmByLatency = \
def selectDepot(clientConfig, masterDepot, alternativeDepots=[]):

selectedDepot = masterDepot
logger.info(u"Choosing depot from list of depots:")
logger.info(u" Master depot: %s" % masterDepot)
for alternativeDepot in alternativeDepots:
logger.info(u" Alternative depot: %s" % alternativeDepot)
if alternativeDepots:
from OPSI.Util.Ping import ping
from OPSI.Util.HTTP import urlsplit
depots = [ masterDepot ]
depots.extend(alternativeDepots)
latency = {}
for depot in depots:
if not depot.repositoryRemoteUrl:
continue
try:
(scheme, host, port, baseurl, username, password) = urlsplit(depot.repositoryRemoteUrl)
latency[depot] = ping(host)
logger.info(u"Latency of depot %s: %0.3f ms" % (depot, latency[depot]*1000))
except Exception, e:
logger.warning(e)
if latency:
minValue = 1000
for (depot, value) in latency.items():
if (value < minValue):
minValue = value
selectedDepot = depot
logger.notice(u"Choosing depot %s with minimum latency %0.3f ms" % (selectedDepot, minValue\
*1000))
return selectedDepot
def getDepotSelectionAlgorithm(self):
#return depotSelectionAlgorithmByLatency
return depotSelectionAlgorithmByNetworkAddress
17.8 Logging
If the dynamic depot assignment is activated, there are some logs from the depot assignment in opsiclientd.
log. In this shortened example log, the server bonifax.uib.local is config server and master depot for the client
pctrydetlef.uib.local. As a master server the server has the network address 192.168.1.0/255.255.255.0. As
an alternative depot the server stb-40-srv-001.uib.local is available with the network address 192.168.2.0/255.
255.255.0. The client pctry4detlef.uib.local has the IP address 192.168.2.109, which is in the network of the
alternative depot.
(...)
[6] [Dec 02 18:25:27] [ opsiclientd ] Connection established to: 192.168.1.14 (HTTP.pyo|421)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] [ 1] product opsi-client-agent: setup (EventProcessing.\
pyo|446)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Start processing action requests (EventProcessing.pyo|453)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Selecting depot for products [uopsi-client-agent] (Config.\
pyo|314)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Selecting depot for products [uopsi-client-agent] (__init__\
.pyo|36)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Dynamic depot selection enabled (__init__.pyo|78)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Master depot for products [uopsi-client-agent] is bonifax.uib\
.local (__init__.pyo|106)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Got alternative depots for products: [uopsi-client-agent] (\
__init__.pyo|110)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] 1. alternative depot is stb-40-srv-001.uib.local (__init__.\
pyo|112)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Verifying modules file signature (__init__.pyo|129)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Modules file signature verified (customer: uib GmbH) (\
__init__.pyo|143)
(...)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Choosing depot from list of depots: (<string>|4)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Master depot: <OpsiConfigserver id bonifax.uib.local> (<\
string>|5)
[6] [Dec 02 18:25:28] [ event processing gui_startup ] Alternative depot: <OpsiDepotserver id stb-40-srv-001.uib.\
local> (<string>|7)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Choosing depot with networkAddress 192.168.2.0/255.255.255.0 \
for ip 192.168.2.109 (<string>|40)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Selected depot is: <OpsiDepotserver id stb-40-srv-001.uib.\
local> (__init__.pyo|171)
(...)
[5] [Dec 02 18:25:28] [ event processing gui_startup ] Mounting depot share smb://stb-40-srv-001/opt_pcbin/install (\
EventProcessing.pyo|415)
(...)
18 opsi Software On Demand (Kiosk-Mode)
18.1 Introduction
With the module "Software-on-Demand" opsi administrators may give their users access to install a range of software-
products. These software products may be selected and installed user-driven without the administrator needing to do
anything. This documentation shows how the module "Software-on-Demand" works, describes its functions and how
to configure it.
18.2 Prerequisites
There are some preconditions for using the extension. The product-groups are needed, available with opsi 4.0. Fur-
thermore the opsi-client-agent and the opsi-configed at version 4.0.1 are needed.
Table 3: Required Packages
opsi-Package Version
python-opsi >=4.0.1-7
opsi-depotserver >=4.0.1-2
opsi-configed >=4.0.1.6-1
The Software-on-Demand module is tested and declared as stable for the following browsers:
Internet Explorer 8
Mozilla Firefox 3.6.15
18.3 configuration
The configuration of this extension is based on product-groups and config-variables. The used config-variables are:
software-on-demand.active
software-on-demand.product-group-ids
software-on-demand.show-details
These config-variables are created with installing the opsi-depotserver-package.
Attention
Please notice the minimum requirements of the opsi-depotserver-package.
(see also chapter: Prerequisites) If the config-variables are not available, they can be added via opsi-setup:
18.3.1 Managing product-groups
The most comfortable way to create and manage product-groups is using the opsi-configed. There you have to
change to the tab product configuration.
ASTUCE
Since version 4.0.1.6 of the opsi-configed you can change to product configuration without choosing a client.
The product-group menu is above the product list.
../images/configed_productgroup_en.png
Figure 74 product-group menue
With the drop down menu you can choose a product-group to edit it. If you have chosen a group, the corresponding
products will be highlighted.
With a second icon, filter can be activated or deactivated. When a filter was activated, only the products of the
activated product-group are seen.
Product-groups can be edited after activating the icon with the yellow packets (show editor / hide editor) next to the
icon with the filter. In this view, a new group and its description can be added. Save the editing by activating the
red check icon.
If some more products should be added to a group, select them and press the red check icon. (Press the <ctrl> button
and select the products).
18.3.2 configure the module Software-On-Demand
The module can be configured, as mentioned above, with the config-variables described in the following table:
Table 4: overview of the config-variables of the module Software-

on-Demand
Configuration Description Values

software-on-demand.active activates or deactivates the modul. true/false
software-on-demand.product- Product-groups with List of produkt-groups
group-ids software-products, that can be
used for Software-on-Demand.
software-on-demand.show-details Show further information to the true/false
user.
There are two ways to use these configuration objects. For the whole system or for each client. The following 2 chapters
will explain both ways.
Configuration for the whole system
The configuration here is the default system wide for every client. The configuration can be edited in the opsi-
configed. Push the Button Server Configuration and change to the tab Host Parameter
../images/configed_serverconfiguration_en.png
Figure 75 part of the module server configuration in the opsi configuration editor
Another possibility is to change the server-configuration with the following command:

opsi-setup --edit-config-defaults
Figure 76 edit-config-defaults with opsi-setup
ASTUCE
Administration is also possible with the opsi-python-API or with opsi-admin
Configuration for a single client
The configuration for a single client - or client specific configuration - is useful if, for example, only some of the clients
should have access to the Software-on-Demand extension. Or if you want to make several product groups available to
some clients.
The configuration of the client specific host parameters can be edited in different ways:
The most comfortable way to edit the configuration is via opsi-configed. Choose one or several clients (even all clients
of a client group if you want to) and then navigate to the tab "Host parameters".
Figure 77 edit hostparameter in the configuration editor
This editing overrides the system wide defaults.
18.3.3 opsiclientd event-configuration
There are two ways for the users to start the software-installation:
with the next system start
immediately
If the user chooses "with the next system start", the product state will be set to "setup." If the choice is "immediately",
the opsiclientd creates an event software on demand. This event can be configured in the file opsiclientd.conf as
any other event.
18.3.4 Customize to corporate identity
The look of the software-on-demand module can be customized to the companies corporate identity. Therefore the
file opsiclientd.css has to be customized. It lies under:
c:\program files\opsi.org\opsi-client-agent\opsiclientd\static_html
It can be edited and then reloaded. The changes have to be copied to the server to remain with new opsi-client-agent
installations. Copy the CSS-file and perhaps a file with the companies logo to the server directory:
/opt/pcbin/install/opsi-client-agent/files/opsi/dist/opsiclientd/static_html
To avoid errors, we recommend to set rights after changing the configuration.
opsi-setup --set-rights /opt/pcbin/install/opsi-client-agent
Attention
The customization will not automatically be saved at the moment. If you install opsi-client-agent again you will
loose the changes. Dont forget to save the files, before upgrading the system.
18.4 Usage
The software-on-demand module contains a web application, based on the opsiclientd. This can be reached by every
client via browser URL https://localhost:4441/swondemand.
If the host-parameter software-on-demand.active is "true" an entry in the start-menue will be added during the
installation of the opsi-client-agent. A shortcut in the start-menu will be created in Start -> Program Files ->
opsi.org -> software-on-demand, that calls the URL above.
It can be configured, with software-on-demand.show-details whether more or less details are shown.
With authentication a connect via network is possible.
../images/opsi-software-on-demand_en.png
Figure 78 overview of the software-on-demand list
The user can choose some software from the list by activating the check box. If the software has been already installed,
the choice is to install or to uninstall the software first. Other software, that has opsi driven dependencies to the chosen
program will not be uninstalled. Choose "continue" to go to the next page.
If the parameter software-on-demand.show-details is set to "true" the software-packages with opsi driven depen-
dencies will be shown at this place, too.
../images/opsi-software-on-demand_actions_en.png
Figure 79 overview of succeeding actions
There are three possibilities to continue at this time. If you choose the button "back", the choice can be changed. With
"process on next boot" the changes are sent to the opsi-service and appear with the next system boot. With "process
now" the installation will proceed immediately.
18.5 Specialities
There are some specialties for the software-on-demand module:

software-dependencies will be set automatically
If there are some software-dependencies to other software (e.g. javaVM) outside the on-demand-group, it will be
set to setup automatically
Any software that has the status "setup" will be displayed in the overview-page.
19 opsi extension Roaming Profile Support
19.1 Preconditions for the extension
This extension is at the moment a co-funding project which means that until the complete development costs are
payed by co-funders, they are only allowed to use by the co-funders or for evaluation purposes. If we have earned the
development cost we will give these modules for everybody for free.
see also Section 6
and
http://uib.de/en/opsi_cofunding/index.html http://www.opsi.org/en/statistics
So as precondition to use this extension you need as first an activation file. For evaluation purpose you will get a
temporary activation file if you ask for it in a mail at info@uib.de.
Technical preconditions are opsi 4.0.1 with the following package and product versions:
Table 5: Needed product and package versions
opsi product Version

python-opsi >=4.0.1.31-1
19.2 Introduction
The opsi-winst has some special commands to manipulate profiles. These commands act at the local stored profiles.
If you are using Roaming Profiles this feature of the opsi-winst does not help you because all modifications at the
profiles will be overwritten by the server stored profile while login.
The opsi extension for Roaming Profiles gives you the possibility to do the needed profile manipulation after the login
of the user, at the correct profile. This is done by starting the opsi-winst after the user login again and run some
special userLoginScripts.
19.3 Concept
If you cant do the profile manipulation while installing the software on the machine, you have to separate the machine
part of the software installation from the profile part. This can be done inside of a script and also by putting the profile
part into a separate script. Many admins still use the second idea by integrating profile parts into a domain login
script.
According to the method you use the profile part of your opsi products are part of the opsi installation scripts for
installation and deinstallation or they are separated for example as part of the domain login scripts.
The goal of this opsi extension is to provide the possibility to integrate both variants of scripts easily.
The core concepts of this opsi extension are:
Executing special userLoginScripts scripts at the user login
At the user login the opsiclientd uses the event_user_login to startup the opsi-winst in a special login script mode.
In this special mode the opsi-winst executes only the userLoginScripts which are assigned to the opsi products.
Executing these scripts with administrative privileges inside the context of the logged in user
Domain login scripts may be used to execute profile parts. But they run only with user privileges. opsi userLogin-
Scripts run with administrative privileges. They run with these high privileges in the user context, so that is easy
to manipulate file and registry parts of the profile using the same commands you may use in a domain login script.
Executing these scripts inside of the opsi service context
The opsi userLoginScripts run inside the opsi service context, so that they know all details about at which opsi
product name, version and package version they are just working. They have the complete access to product
properties and other information that can be requested by opsi service calls.
Restrictions:
The opsi userLoginScripts will be always executed online and not from a local cache. Even if your client runs with
the opsi WAN extension.
19.4 New and extended opsi-winst functions
Command line parameter /allloginscripts

If you are calling opsi-winst in the opsi service context with the additional parameter /allloginscripts this will lead
to the following actions:
All products which have a userLoginScript will be detected. Only for these products will be the userLoginScripts
executed.
The logged in user will be identified. All global constants to user specific directories like %CurrentAppdataDir%
will be directed to the directories of the logged-in user. Also the registry operations (Registry sections and
GetRegistryString) which going to HKCU will be executed in a way that they read or write to the current_user
hive of the logged-in user.
Command line parameter /silent
The command line parameter /silent switches off the opsi-winst standard window in order to not disturb the user.
Function GetScriptMode
In order to detect if a script runs as userLoginScript or for example as installation script, the function GetScriptMode
gives you two possible values:
Machine
The script is not executed as userLoginScript (but e.g. as setup or uninstall script).
Login
The script is executed as userLoginScript.
New primary section ProfileActions
This section may be used to the place for calling user profile manipulations. Here a syntax may be used, which
make it possible to use this section as a part of a installation script and as a userLoginScript as well. Therefore this
primary section will be interpreted in different ways according to the fact if it is called at Machine mode or at Login
mode (as userLoginScript):
Login
If a script is running as userLoginScript and there is a section ProfileActions in the script, the script interpre-
tation will start at the ProfleActions section (and not at the Actions section, which will be ignored).
Machine
If a script is running as normal istallation script, you may call the section ProfileActions as a sub section.
But in difference to a normal sub section it has some special rules: For every called Registry section the modifier
/AllNtUserDats is implicit set. gesetzt. For every called Files section the modifier /AllNtUserProfiles is implicit
set.
Registry sections
Registry sections which should work on the HKCU or HKEY_CURRENT_USER hive in the openkey command,
will be executed in login script mode (Login) in a way, that all changes will be made in the registry hive of the
logged-in user. The same applies to the functions GetRegistryStringValue*.
Registry sections which are called at the normal mode (Machine) with the modifier /AllNtUserDats, may now
contain HKCU resp.. HKEY_CURRENT_USER at the openkey command. This gives you the possibility to use
the same registry sections in both modes.
Avoid unnecessary script execution:
With the new script command saveVersionToProfile you save product name, version and package version to the
logged-in users profile. These information can be retrieved by the new string function readVersionFromProfile,
so that you may see if this script was executed at this profile before. To make the handling easier there is also a
new Boolean function scriptWasExecutedBefore. This function checks if there is a version stamp in the profile
(like you may do with the readVersionFromProfile command) and set a new stamp to the profile (like you may
do with the saveVersionToProfile command). So you may just use this single command in a if statement.
The new string list function getProductMap gives you a hash with all information about the installation states and
report to the actual product. So you may see if this product is installed or was uninstalled.
Logging
The logs of the userLoginScripts are written to
c:\opsi.org\log\<login user name>_login.log
This log file will be transmitted to the server. At the server they will be stored at /var/log/opsi/userlogin/
<clientid>.log.
This log file is handled in append mode. This means new logs will appended to a existing log file of this client. To
avoid to large log files, the size of the log files are limited by the server to a maximal size of 5 MB.
You may display these log files at the opsi management interface (opsi-configed) at the tab Log files in the sub tab
userlogin.
19.5 Examples of userLoginScripts
We are starting with examples that are build in a way that they also may used in a domain login script.
A very simple generic example:
[Actions]
Message "Example Profile Patch ...."
Files_profile_copy
Registry_currentuser_set
[Files_profile_copy]
copy "%Scriptpath%\profiles\*.*" "%CurrentAppdataDir%\ACME"
[Registry_currentuser_set]
openkey [HKCU\Software\ACME]
set "show_greeting_window" = "no"
A example for firefox configuration:

[Actions]
Message "Firefox Profile Patch ...."
DefVar $akt_profile_ini$
DefVar $rel_prefs_path$
comment "check for existing profile ..."

Set $akt_profile_ini$ = "%CurrentAppdataDir%\Mozilla\Firefox\profiles.ini"
if FileExists($akt_profile_ini$)
Set $rel_prefs_path$ = GetValueFromInifile($akt_profile_ini$,"Profile0","Path","")
if FileExists("%CurrentAppdataDir%\Mozilla\Firefox\\"+$rel_prefs_path$)
comment "We found the profile and will now patch it ....."
endif
else
comment "no firefox profile found for user"
endif
At the next example (which simply extends the first example) we show how you may delete things from the profile in
the case that this product has been uninstalled. According to what we get from the function getProductMap different
parts of the script will be executed.
[Actions]
if getValue("installationstate", getProductMap) = "installed"

comment "Product is installed"
Files_profile_copy
endif
if getValue("lastactionrequest", getProductMap) = "uninstall"

comment "Product was uninstalled"
Files_profile_del
Registry_currentuser_del
endif
[Files_profile_del]
del -s -f "%CurrentAppdataDir%\ACME"
[Registry_currentuser_del]
deletekey [HKCU\Software\ACME]
Now a example which shows how standard installation scripts (setup32.ins and delsub32.ins) may used also as user-
LoginScripts to avoid unneeded code doubling.
setup32.ins:
[Actions]
requiredWinstVersion >= "4.11.2"
DefVar $MsiId$
DefVar $UninstallProgram$
DefVar $ProductId$
DefVar $InstallDir$
; ----------------------------------------------------------------
; - Please edit the following values -
; ----------------------------------------------------------------
Set $ProductId$ = "ACME"
Set $InstallDir$ = "%ProgramFiles32Dir%\ACME"
; ----------------------------------------------------------------
comment "Show product picture"
ShowBitmap "%ScriptPath%\\" + $ProductId$ + ".png" $ProductId$
if FileExists("%ScriptPath%\delsub32.ins")
comment "Start uninstall sub section"
Sub "%ScriptPath%\delsub32.ins"
endif
if GetScriptMode = "Machine"
Message "Installing " + $ProductId$ + " ..."
comment "Start setup program"

Winbatch_install
comment "Patch the local Profiles ..."

Registry_currentuser_set /AllNtUserDats
Files_profile_copy /AllNtUserProfiles
endif
if GetScriptMode = "Login"
comment "login part"
Files_profile_copy
endif
[Winbatch_install]
"%ScriptPath%\setup.exe" /sp- /silent /norestart
copy "%Scriptpath%\profiles\*.*" "%CurrentProfileDir%\Appdata\ACME"
delsub32.ins:
Message "Uninstalling " + $ProductId$ + " ..."
if GetScriptMode = "Machine"
comment "The machine part ..."
Set $UninstallProgram$ = $InstallDir$ + "\uninstall.exe"
if FileExists($UninstallProgram$)
comment "Uninstall program found, starting uninstall"
Winbatch_uninstall
endif
; does also work since 4.11.2.1:
Registry_currentuser_del /AllNtUserDats
Files_profile_del /AllNtUserProfiles
endif
if GetScriptMode = "Login"
comment "The profile part ..."
Files_profile_del
Registry_currentuser_del
endif
[Winbatch_uninstall]
"$UninstallProgram$" /silent /norestart
[Files_profile_del]
del -s -f "%CurrentProfileDir%\Appdata\ACME"
[Registry_currentuser_del]
deletekey [HKCU\Software\ACME]
Now a variant which is variant of the example before. It makes use of the new primary section ProfileAction. This
makes the script shorter and it may be still used as installation script and as userLoginScript as well.
[Actions]
requiredWinstVersion >= "4.11.2"
DefVar $ProductId$
DefVar $InstallDir$
Set $ProductId$ = "ACME"

Set $InstallDir$ = "%ProgramFiles32Dir%\ACME"
comment "Show product picture"

ShowBitmap "%ScriptPath%\\" + $ProductId$ + ".png" $ProductId$
Message "Installing " + $ProductId$ + " ..."

comment "Start setup program"

Winbatch_install
comment "Patch the local Profiles ..."

ProfileActions
[ProfileActions]
comment "if this script is executed as userLoginScript only this part will be executed"
Files_profile_copy
[Winbatch_install]
"%ScriptPath%\setup.exe" /sp- /silent /norestart
copy "%Scriptpath%\profiles\*.*" "%CurrentProfileDir%\Appdata\ACME"
Now a variant which reminds, if this script (for this product, in this version and this package version) was executed
before for this profile.
[Actions]
comment "Did we run this script before ? - and set version stamp in profile"
if not (scriptWasExecutedBefore)
comment "loginscript was not run yet "
Files_profile_copy
endif
19.6 Configuration
In order to use the opsi Roaming Profile extension, you have to activate the event_user_login at the opsiclientd
configuration. At the configuration of this event the action_processor (opsi-winst) should be started with the additional
parameter /allloginscripts. Last not least should the opsi-winst winst run as user SYSTEM in order to have the
possibility to enter the context of the logged-in user.
This configuration you may do at the command line with the following commands:
opsi-admin -d method config_createBool opsiclientd.event_user_login.active "user_login active" true
opsi-admin -d method config_createUnicode opsiclientd.event_user_login.action_processor_command "user_login \

action_processor" "%action_processor.command% /sessionid %service_session% /allloginscripts"
opsi-admin -d method config_createUnicode opsiclientd.action_processor.run_as_user "action_processor run_as_user" "\

SYSTEM"
As additional action_processor (opsi-winst) parameter you may use /silent, which suppress the display of the opsi-
winst window.
opsi-admin -d method config_createUnicode opsiclientd.event_user_login.action_processor_command "user_login \
action_processor" "%action_processor.command% /sessionid %service_session% /allloginscripts /silent"
These configurations you will also see (and modify) at the opsi management interface (opsi-configed) at the tab Host
parameters at the client or server configuration-
19.7 Notification
If you have activated the event_user_login (as described above), you will see after every login the user_login_notifier:
User Login Notifier
Figure 80 User Login Notifier
20 Connecteur-opsi-Nagios
20.1 Introduction
Outre la gestion des clients, la surveillance est lune des fonctions centrales dans une gestion des services informatiques
modernes. Avec OPSI vous avez un outil de gestion clients. Pour les tches de surveillance il y a dautres bien connus
solutions open source. Alors nous construisons pour les tches de surveillance dans OPSI non pas un outil de surveillance
propre mais une interface aux solutions existantes. Avec cette extension OPSI nous fournissons un connecteur Nagios.
Dans les chapitres suivants est explique la conception et la configuration du connecteur opsi Nagios.
Le connecteur opsi Nagios nest pas strictement lie Nagios. Il est dvelopp pour lutilisation avec Nagios et Icinga.
Il devrait galement fonctionner avec des drivs de Nagios mais cela nest pas test ni pris en charge.
La porte de ce manuel est la conception et la configuration du connecteur opsi-Nagios. Il nest pas un manuel Nagios.
Vous aurez besoin dune installation de Nagios et de savoir comment faire fonctionner Nagios.
20.2 Conditions pralables
20.2.1 Conditions pralables au niveau du serveur et des clients OPSI
Ce module est dvelopp en tant que projet en co-financement. Cela signifie quil nest disponibles que pour les clients
qui paient une contribution aux cots de dveloppement ou des fins dvaluation. Ds que le dveloppement du
projet sera refinanc, le composant fera partie de la distribution opsi et pourra tre utilis gratuitement.
voir aussi
http://www.opsi.org/fr/projets-de-co-financement
http://www.opsi.org/fr/statistics
Donc, comme condition sine qua non pour utiliser cette extension, vous avez besoin dabord dun fichier dactiva-
tion. des fins dvaluation vous obtiendrez un fichier dactivation temporaire si vous le demandez dans un mail
opsi@opensides.be.
Les conditions pralables techniques sont opsi 4.0.2 avec le suivant paquets et versions de produits:
Table 6: Versions des produits et des paquets ncessaires
opsi package Version

opsiconfd >=4.0.2.1-1
python-opsi >=4.0.2.1-1
20.2.2 Conditions pralables au niveau du serveur Nagios
Comme condition pralable, vous avez besoin dune installation de Nagios dans la version 3.x ou dune installation
Icinga dans la version 1.6 ou suprieur.
Pour une sortie graphique de donnes sur le rendement, linstallation de pnp4nagios est ncessaire.
Vous trouverez de plus amples informations :
www.nagios.org
www.icinga.org
www.pnp4nagios.org
20.3 Concept
Le Connecteur opsi-Nagios contient deux composantes fondamentales. Dans un premier temps nous allons discuter du
coeur du systme.
20.3.1 extension opsi web service
Le coeur du connecteur opsi-Nagios sont des fonctions tendues du service Web OPSI. Ces extension de service Web
permettent dexcuter des vrifications via le web service sur le serveur opsi. Donc le serveur Nagios appelle des
contrles via le web service qui sont excuts sur le serveur opsi et les rsultats reviennent au serveur Nagios via le
web service opsi. Lavantage de cette solution cest quil ny a presque rien faire sur le serveur opsi surveill.
Lobjectif de lextension de service Web OPSI se trouve sur des contrles OPSI spcifiques comme par exemple le
suivi de dploiement. Pour la surveillance normal du serveur, vous devriez utiliser toujours des mthodes de contrle
standards.
20.3.2 extension opsi-client-agent
Une autre partie du Connecteur opsi-Nagios est lextension de opsi-client-agent.

Dans un environnement OPSI sur chaque client gr sexcute opsi-client-agent. Avec cette extension, vous pouvez
utiliser opsi-client-agent comme agent de Nagios ainsi. Mais en fait toutes les fonctions dun agent standard Nagios ne
sont pas mis en uvre dans opsi-client-agent comme NSClient++. Vous pouvez utiliser opsi-client-agent pour excuter
des programmes en ligne de commande et renvoyer la sortie.
Si vous nutilisez pas toutes les fonctions comme NSCA mais plutt certains contrles standard par plugin sur le client
ou un ensemble de plugins vous sur les clients vous pouvez utiliser opsi-client-agent.
Si vous avez besoin de plus de fonctionnalits pour le suivi des clients vous devriez dploiement, par lintermdiaire
opsi, un agent standard comme NSClient++.
Lavantage dutiliser opsi-client-agent comme agent de Nagios est que vous navez pas besoin dun agent supplmentaire
sur le client et que vous navez pas besoin de donnes daccs pour les clients au niveau du serveur de surveillance. Ces
donnes ne sont pas ncessaires parce que tout vrification sont excut via le serveur OPSI. Cela rend la configuration
beaucoup plus facile.
20.4 opsi-checks
Le chapitre suivant explique les objectifs et les configurations des contrles OPSI.
20.4.1 Quelques renseignements gnraux sur lendroit o excuter les contrles
Les administrateurs de surveillance connaissent la diffrence entre les contrles actifs et passifs.
Avec le Connecteur opsi-Nagios on obtient une nouvelle diffrence: directe et indirecte.
directe:
Le contrle qui recueille des informations sur un client sexcute sur ce client, il reoit linformation directement
auprs du client et renvoie linformation.
indirecte:
Le contrle qui recueille des informations sur un client sexcute sur le serveur opsi et il reoit linformation partir
des donnes de configuration dopsi qui sont stockes dans le backend dopsi. Donc, cette information peut tre
diffrente de la situation relle du client.
Un bon exemple pour un contrle indirect est le check-opsi-client-status. Cette vrification vous donne, pour
un client donn, les informations sur les demandes daction en attente et les dfaillances signales du dploiement de
logiciel dopsi. Donc, ce sont des informations sur le client partir du point de vue du serveur opsi. Par consquent,
cette vrification sexcute sur le serveur OPSI et cest un contrle indirecte. Une vrification qui sexcute sur le client
est un contrle direct.
Pour une correcte distribution et configuration des contrles vous devez analyser votre installation OPSI.
En fonction de la flexibilit de OPSI de nombreuses configurations diffrentes dopsi sont possibles. Donc, ici nous ne
pouvons quexpliquer certaines situations typiques. Bien sr, nous allons vous aider pour des situations particulires
avec notre support commercial.
un seul serveur opsi:
Une installation autonome dopsi est la situation que vous trouverez dans la plupart des environnements OPSI. Dans
ce type dinstallation le serveur opsi ainsi que le serveur de depot opsi (un seul) sont sur la mme machine.
Cela signifie pour vous, que vous pouvez ignorer si un contrle doit tre excut sur le serveur de configuration ou le
serveur de dpt.
Figure 81 Schma dun serveur autonome OPSI
OPSI avec serveurs de dpts multiples:

Si vous avez un gestion centralise dun environnement OPSI de plusieurs emplacements (un serveur de config, plusieurs
serveurs de dpt) la situation est plus complique. Donc, vous devez comprendre la situation:
Figure 82 Schma dun environnement OPSI avec multiples dpt
Comme le souligne la figure il nexiste quun seul serveur qui contient les donnes de configuration - le backend. Il
sagit du serveur de configuration opsi. Le serveur de dpt OPSI, il ne dispose pas de son propre stockage de donnes,
mais dune redirection vers le backend. Cela signifie que si vous demandez un serveur de dpt pour les donnes
de configuration, cette question sera redirig vers le serveur de configuration. Et cela conduit la consquence que
chaque contrle qui va lencontre du backend sera au moins excuter sur le serveur de configuration. Vous devez
donc rpondre des contrles qui sexcutent lencontre du backend toujours sur le serveur de configuration. Mme
dans la situation de collecte dinformations sur les clients qui sont affects un dpt qui est diffrente du serveur de
configuration et le contrle est logiquement partie de la vrification de ce serveur de dpt.
Si vous excutez les contrles directs vous avez lhabitude aussi daborder la configuration du serveur opsi. Vous pouvez
rgler le serveur de dpt si les clients ne peuvent pas tre atteint par le serveur de configuration OPSI via le port
4441. Dans ce cas, cest une bonne ide de sadresser au serveur de dpt.
Figure 83 Contrles distribus
20.4.2 opsi-check-plugin
Au niveau du serveur nagios il nexiste quun seul opsi-check-plugin qui fournit un large ventail de diffrents contrles.
En fonction du nombre de fonctionnalits il y a aussi un grand nombre doptions de ligne de commande. Lister toutes
ces options ne vous aidera pas trop. Au lieu de cela, loption sera expliqu dans le contexte de la documentation des
possibles contrles.
Toutefois, pour obtenir une liste de toutes les options vous pouvez utiliser check_opsi avec les paramtres --help ou
-h.
Les options gnrales suivantes sont ncessaires pour chaque contrle:
Table 7: General Options
Option Description Exemple

-H,--host serveur opsi qui devrait excuter le configserver.domain.local
contrle
-P,--port opsi webservice port 4447 (Default)
-u,--username opsi monitoring user monitoring
-p,--password opsi monitoring password monitoring123
-t,--task opsi check method (case sensitive)
Le chapitre suivant dcrit comment appeler opsi-check-plugin en ligne de commande. Comment vous devez configurer
ces appels votre serveur Nagios est dcrit au chapitre configuration.
Afin dinstaller opsi-check-plugin sur votre serveur Nagios vous devez ajouter le dpt OPSI sur votre serveur et
installer le paquet opsi-nagios-plugins.
Par exemple, dans Debian ou Ubuntu avec les commandes suivantes:
apt-get install opsi-nagios-plugins
Sur RedHat/CentOS serveurs sil vous plat utilisez la commande suivante:

yum install opsi-nagios-plugins
Et enfin pour des installations openSUSE/SLES:

zypper install opsi-nagios-plugins
Le plugin en lui-mme est crit en python et devrait fonctionner sur nimporte quelle distribution.
Le paquet se base sur les paquets nagios-plugins-basic et nagios-plugins et il installe le plugin dans /usr/lib/nagios/
plugins.
Selon la flexibilit de check_plugin il ny a pas de configuration automatique.
Contrle: opsi web service
Cette vrification surveille le processus opsi web service (opsiconfd). Cette vrification renvoie galement les donnes de
performance. Vous devez excuter cette vrification sur chaque serveur OPSI parce que chaque serveur OPSI dispose
dun processus opsiconfd.
check_opsi.py -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiWebservice
Cette vrification renvoi normalement OK.

Vous obtiendrez dautres valeurs de retour dans les situations suivantes:
Critical:
Si opsiconfd a des problmes et ne peut pas rpondre correctement.

Si opsiconfd consomme plus de 80% de la cpu.
Si vous avez un taux derreurs RPC de plus de 20%.
Warning:
Si opsiconfd consomme plus de 60% (mais moins de 80%) de la cpu.

Si vous avez un taux derreurs RPC de plus de 10% mais moins de 20%
Unknown:
Le service web OPSI na pas pu tre atteint.
NOTICE: La valeur en pourcentage de la consommation cpu appartient toujours une cpu parce que opsiconfd peut
seulement utiliser une cpu. (Cela pourrait changer avec lextension de multitraitement dopsi)
Contrle: opsi web service pnp4nagios template
Pour laffichage des donnes de performance il y a un modle pour pnp4nagios qui affiche les donnes dune manire
combine.
Ici, nest pas dcrit comment installer pnp4nagios. Nous supposons que pnp4nagios est install et configur correcte-
ment. La faon dont vous avez utiliser pour configurer notre modle peut diffrer de la faon ci-dessous dcrite en
fonction de votre installation pnp4nagios (qui peut utiliser un chemin diffrent).
Les modles standard affichent pour toutes les donnes de performance un diagramme propre. Pour crer un affichage
combin vous devez passer aux tapes suivantes:
tape 1:
crez dans /etc/pnp4nagios/check_commands un fichier nomm check_opsiwebservice.cfg et insrez le contenu
suivant:
CUSTOM_TEMPLATE = 0
DATATYPE = ABSOLUTE,ABSOLUTE,ABSOLUTE,ABSOLUTE,DERIVE,GAUGE,GAUGE,GAUGE
tape 2:
accdez au rpertoire /usr/share/pnp4nagios/html/templates et placez dedans le fichier check_opsiwebservice.
php que vous pouvez consulter partir de svn.opsi.org:
cd /usr/share/pnp4nagios/html/templates
svn co https://svn.opsi.org/opsi-pnp4nagios-template/trunk/check_opsiwebservice.php
Sil vous plat vrifiez que votre fichier php est nomm exactement comme le command_name qui est dfini dans /
etc/nagios3/conf.d/opsi/opsicommands.cfg. Si les noms ne correspondent pas, un modle standard sera utilis
la place de notre modle combin.
Aprs linstallation de ce modle vous devez supprimer la bases de donnes RRD qui appartiennent ce contrle (sil
y a une existante). Vous trouverez ces bases de donnes dans /var/pnp4nagios/perfdata/<host>/ o vous devriez
(seulement) supprimer les fichiers opsi-webservice.rrd et opsi-webservice.xml.
Si vous avez tout configur correctement vous devriez maintenant pouvoir voir les diagrammes comme dans la capture
dcran ci-dessous.
Contrle: opsi-check-diskusage
Ce contrle surveille lutilisation des ressources (rpertoires) qui sont utilises par OPSI. Le tableau suivant montre
les noms des ressources et les rpertoires correspondants:
Table 8: ressources opsi
Resource name Path

/ /usr/share/opsiconfd/static
configed /usr/lib/configed
depot /opt/pcbin/install
repository /var/lib/opsi/repository
Sil vous plat notez que ce contrle surveille uniquement les donnes pertinentes dopsi et remplace une vrification
gnral de lusage du disque pour le serveur.
La commande suivante extrait toutes les ressources en mme temps:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage
En plus de cette variante standard vous pouvez restreindre la vrification la ressource depot:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage -r depot
La valeur par dfaut du rsultat de cette vrification est OK et lespace libre des ressources. Lespace libre est donne
en Gigabyte. Les valeurs par dfaut pour les rsultats de Warning et Critical sont:
WARNING: Si au moins une ressource as 5GB ou moins despace libre.
CRITICAL: Si au moins une ressource as 1GB ou moins despace libre.
Ce sont les seuils par dfaut. Elles peuvent changer en donnant dautres valeurs pour Warning avec les options -W
ou --warning et pour Critical avec les options -C ou --critical. Avec ces options, vous pouvez indiquer les seuils en
Gigabyte (G) et en pourcentage (%) ainsi. La sortie produite utilise la mme unit qui est utilis pour dfinir les seuils.
Enfin un exemple:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage -r depot --warning\
10% --critical 5%
Contrle: opsi-client-status
Lun des objectifs du connecteur OPSI Nagios est la surveillance du dploiement de logiciel par lcoute des clients
individuels. Cest lun des contrles, qui est conu pour cet emploi. Plus exactement: les situations dploiement du
logiciel et vu la dernire fois dun certain client sont vrifies.
Le rsultat des contrles suivants est dtermine par deux tats diffrents:
Ltat de dploiement dun ou plusieurs logiciels:
Le rsultat de ltat du dploiement de logiciels peut tre:
OK si le logiciel est install dans le mme produit et version du paquet qui est disponible au niveau du serveur
et aucune demande daction est dfinie.
Warning si le logiciel est install dans une version qui est diffrente de la version serveurs ou si une demande
daction est dfinie.
Critical sil y a un chec rapport par la dernire action.
Le temps coul depuis vu la dernire fois:
Le rsultat du temps coul depuis vu la dernire fois peut tre:
OK si le client a t vu moins ou gale 30 jours avant.
Warning si le client a t vu plus de 30 jours avant.

Ce contrle peut tre utilis avec diffrentes variantes, ici la plus simple, qui comprend tous les logiciels:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkClientStatus -c opsiclient.\
domain.local
Comme variante, il est possible dexclure des produits de la vrification. par exemple:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkClientStatus -c opsiclient.\
domain.local -x firefox
Dans lexemple ci-dessus le produit firefox a t exclu de la vrification. Donc, cette vrification ne passera pas
critique parce que la dernire action sur firefox a signal une dfaillance.
Contrle: opsi-check-ProductStatus
Un autre objectif du connecteur OPSI Nagios est la surveillance du dploiement de logiciel par lcoute de produit
unique ou de groupe de produits.
Le rsultat de ces contrles est dtermin par les tats suivants:
Le rsultat de ltat du dploiement de logiciels peut tre: * OK si le logiciel est install dans le mme produit et
version du paquet qui est disponible au niveau du serveur et aucune demande daction est dfinie. * Warning si le
logiciel est install dans une version qui est diffrente de la version serveurs ou si une demande daction est dfinie. *
Critical sil y a un chec rapport par la dernire action.
Ces contrles ont de nombreuses variantes et sont donc trs souples. La meilleur faon dexpliquer ces variantes cest
avec des exemples.
La variante simple verifie un produit sur tous les clients. Il faut specifier le produit par son opsi productId.
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox
Dans un environnement avec un seul serveur opsi, ce contrle est tout ce dont vous avez besoin pour verifier ltat du
produit firefox sur tous les clients.
Vous sauriez combien de clients sont dans ltat Warning et Critical.
Pour savoir quel client a effectivement des problmes, vous devez lappeler en modalit verbeuse:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox -v
Une autre variante vous permet dexclure un client de la verification.

//// produkt muss angegebn werden ?! ////
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox -x \
client.domain.local
Dans un environnement opsi avec plusieurs serveurs de depot vous devez utiliser des options supplmentaires pour
vrifier aussi les clients que ne sont pas assign au depot du serveur de configuration. Si vous avez les dpts multiple,
vous pouvez passer le nom des dpts comme parametres:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox -d \
depotserver.domain.local
La raison est que la version du paquet peut tre diffrente entre vos depots. Donc la version de chaque client devra
tre vrifi partir du depot qui lui est assign. Un avantage est quil pourra placer laffichage des rsultats sur le
serveur de depot.
Vous pouvez donner au lieu du nom du serveur de depot le mot clef all ce qui signifie tous les serveurs de depot connus.
Mais cela normalement a seulement sens si vous avez un ou deux serveurs de depot. Vous pouvez aussi donner une
liste de serveurs de depot spare par une virgule.
Une autre faon de definir le contrle est de donner le nom dun ou plusieurs groups opsi. Ainsi vous pouvez verifier
ltat du dploiement de logiciels pour tous les produits dans un group de produits opsi donn. Si vous avez par
exemple un group de produits accounting vous pouvez utiliser lappel suivant:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -g accounting
Maintenant vous pouvez vrifier tous les produits qui sont membre du group de produits opsi accounting avec ce
simple contrle. Limportant est de voir, que la rsolution du groupe OPSI se fait au moment du contrle au niveau
du serveur OPSI. De cette faon vous pouvez changer le group opsi dans linterface web the gestion dopsi et changer
le produits tester sans apporter de modification sur le serveur Nagios.
Note
Sub groups (groups in groups) will not be resolved.
De la mme faon sera possible de dfinir les clients que vous voulez verifier en donnent le nom dun groupe de clients
opsi.
Un exemple pour un group de clients productiveclients:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -g accounting -G \
productiveclients
Ceci vrifiera tous les produits du groupe de produits accounting sur tous les clients du groupe de clients productive-
clients.
Note
Sub groups (groups in groups) will not be resolved.
Note
Vous pouvez aussi donner une liste de groupes opsi separ par virgule.
Contrle: opsi-check-depotsync
Si vous utilisez des dpts multiple est importante de surveiller aussi la synchronicit. Mme si vos dpts ne son pas,
pour des bonnes raison, compltement synchronis ils devraient, autant que possible, ltre pour pallier au problmes
de dplacement dun client depuis un depot vers un autre.
Ce contrle surveille si vos depots sont synchronis en fonction de lids des produits, des versions du produits et des
versions du paquet.
Ce contrle renvoi:
OK
Si tout est sincronis.
Warning
Sil y a des difference.
Vous devez excuter ce contrle toujours sur un serveur de config parce que tous les donnes viennent du backend du
serveur de config.
Ici quelques exemples.
La variante de base:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus
Cette variante de base est quivalente lappel suivant:

check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d all
Donc si vous ne donnez pas le depot verifier, tous les depots connus seront vrifis. Si vous avez beaucoup de depots,
linterprtation des rsultats sera compliqu, donc ce sera une bonne ide de dfinir un ensemble de contrles simples
o les dpts sont donns comme liste spar par virgule:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \
configserver.domain.local,depotserver.domain.local
Avec ce contrle vous comparez tous les produits qui sont installs sur les deux depots. Tous les produits installs
seulement dans un depot seront ignor et naffectera pas le rsultat.
Si vous voulez inclure des produits which qui ne sont pas installs dans tous les depots vrifis, vous devez utiliser le
commutateur strictmode:
configserver.domain.local,depotserver.domain.local --strictmode
Maintenant aussi les diffrences sur les produits manquants seront affiches.
Si vous voulez exclure un produit de la verification (peut-tre parce que ce produit doit tre dans des versions diffrentes
sur diffrents dpts) vous devez utiliser loption -x. Vous pouvez aussi utiliser une liste separ par virgule:
configserver.domain.local,depotserver.domain.local --strictmode -x firefox,thunderbird
Ce contrle ne vous averti pas si les produits firefox ou thunderbird ne sont pas synchronis.
Au lieu dexclure des produits vous pouvez donner une liste explicite de produits vrifier:
configserver.domain.local,depotserver.domain.local --strictmode -e firefox,thunderbird
Dans ce cas seulement firefox et thunderbird seront vrifi. Nous vous recommandons dutiliser cette variante stric
tmode du contrle pour voir si lun des produits est manquante.
./check_opsi.py -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSync
Contrle: contrle nagios client plugin via opsiclientd
Cette vrification vous donne un moyen facile pour intgrer les contrles qui collectent les donnes directement sur le
client avec un minimum de travail de configuration.
Donc, ce contrle demande opsiclientd qui est en cours dexcution au niveau du client opsi dexcuter une commande,
rcuprer la sortie et de la renvoyer.
Cette extension nest pas destin tre un remplacement complet dun agent Windows Nagios avec toutes ces fonc-
tionnalit . Cest seulement une alternative lgre.
Les plugins que opsiclientd peut appeler doivent tre compatibles avec la Nagios plug-in development guidelines.
(More details at: http://nagiosplug.sourceforge.net/developer-guidelines.html ).
Afin dexcuter un tel plugin sur le client, il doit tre install sur le client. La solution du problme est de le dployer
comme un paquet opsi. Le chemin dans lequel le plugin est install chez le client na pas dimportance parce que vous
devez donner le chemin complet la dfinition du contrle. Nous recommandons dinstaller tous les plugins dans un
rpertoire pour faciliter lentretien des plugins sur le client.
Pour des raisons de scurit, vous devriez faire en sorte que les utilisateurs non privilgis nont pas accs en criture
des plugins, parce quils seront excuts partir de opsiclientd avec des privilges systme.
Il ya beaucoup de plugins prts lemploi sur Internet. Une adresse regarder est:
http://exchange.nagios.org/
Dans ce qui suit, nous supposons que vos plugins sont installs dans C:\opsi.org\nagiosplugins\ et nous y trou-
verons le plugin check_win_disk.exe sorti de son paquet nagioscol depuis
http://sourceforge.net/projects/nagiosplugincol/
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkPluginOnClient --plugin "C:\\\

opsi.org\\nagiosplugincol\\check_win_disk.exe C:" -c client.domain.local
Cet appel contrle le client client.domain.local. Au niveau du client le plugin check_win_disk.exe est appel avec
le paramtre C:. Cela signifie que le disque dur avec la lettre C doit tre vrifie. La sortie et la valeur du rsultat
du plugin seront rcupres par opsiclientd et seront donne au serveur Nagios (via le serveur OPSI) dans un format
correct pour Nagios.
Une autre caractristique spciale est de garder les rsultats de la dernire vrification, mme si le client nest pas
joignable.
Cette fonctionnalit a t mis en uvre selon le fait que les clients ne sont pas toujours en cours dexcution comme les
serveurs, mais le plus de temps dans leur vie sont gnralement teint. Normalement Nagios montrera pour les clients
teints le rsultat Inconnu. En fait le plus de problmes sur les clients surveills ne vont pas disparatre simplement en
les teignant et en les allumant nouveau. Ainsi, les informations que le client avait un problme avant quil ne soit
teints peuvent tre des informations essentielles pour ladministrateur systme. (Vous pouvez essayer de rsoudre ce
problme en utilisant Timeperiods la configuration de Nagios, mais nous pensons que ce nest pas assez souple et
conduit un travail de configuration permanente). Donc, cette extension OPSI vous donne la possibilit de renvoier
les derniers rsultats de contrle rels, si le client nest pas joignable en ce moment.
Pour utiliser cette fonctionnalit, vous devez utiliser les macros Nagios $SERVICESTATEID$ et $SERVICEOUTPUT$.
$SERVICESTATEID$ donne le dernier rsultat et devrait tre pass loption -s. $SERVICEOUTPUT$ donne la dernire
ligne de sortie et devrait tre pass loption -o. Ainsi le contrle peut donner ces dernires valeurs au lieu de Inconnu
si le client nest pas joignable.
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkPluginOnClient --plugin "C:\\\
opsi.org\\nagiosplugincol\\check_win_disk.exe C:" -c client.domain.local -s $SERVICESTATEID$ -o $SERVICEOUTPUT$
20.5 configuration de la surveillance dopsi
Ce chapitre se concentre sur la configuration qui a t raliss pour une interface operationnel entre les serveur opsi
et Nagios. Il suffit de voir cela comme une recommandation, il y aura beaucoup dautres faons de faire le travail.
Cette description utilise un serveur Nagios en tant que serveur de surveillance. Sur un serveur Icinga il devrait
fonctionner similairement mais vous devez changer certaines entres de chemin. Il devrait galement fonctionner sur
les produits drivs de Nagios, mais ce nest pas test.
ASTUCE
Les fichiers de configuration de ce chapitre sont dans opsi-nagios-connector-utils svn-Repository. Pour obtenir ces fichiers
de configuration vous pouvez vous connecter avec un navigateur web lurl:
https://svn.opsi.org/listing.php?repname=opsi-nagios-connector-utils
ou vous pouvez faire une extraction directe partir du dpt svn avec la commande suivante:
svn co https://svn.opsi.org/opsi-nagios-connector-utils
20.5.1 utilisateur de la surveillance dopsi
Dans les environnements de surveillance vous trouverez souvent que laccs est seulement limit par ladresse IP. En
raison de labsence de scurit de cette solution nous avons dcid de travailler avec un vritable utilisateur / mot de
passe de scurit dans cette extension opsi.
En utilisant le groupe standard OPSI opsiadmin on donnerait Nagios plus de droits que ncessaire. Donc, vous
devez crer un utilisateur OPSI propre pour le Connecteur opsi-Nagios.
Dans lexemple suivant, un utilisateur nomm monitoring avec le mot de passe monitoring123 est cr pour opsi:
opsi-admin -d method user_setCredentials monitoring monitoring123
Lutilisateur cr monitoring sera stocke avec le mot de passe crypt dans /etc/opsi/passwd et nest pas un utilisateur
qui peut tre utilis pour connecter au shell. En fait, il nest pas un utilisateur rel Unix.
Vous devez crer cet utilisateur uniquement sur votre serveur de configuration, mme si vous avez des dpts multiples.
Sur votre serveur Nagios vous devriez masquer lutilisateur et le mot de passe en faisant une entre dans /etc/
nagios3/resource.cfg. Cela devrait tre par exemple comme ceci:
$USER2$=monitoring
$USER3$=monitoring123
Le nombre derrire $USER peut varier. Si cette configuration na pas t utilis avant, il devrait y avoir seulement $
USER1 $ utilisable. Selon ce que vous utilisez ici, vous pourriez avoir modifier les autres exemples dans ce manuel.
20.5.2 Rpertoire de configuration du connecteur opsi-Nagios
Pour rendre la maintenance de la configuration de Nagios plus facile, nous vous recommandons de mettre tous les
fichiers de configuration associs au connecteur opsi nagios dans un endroit spar.
Il suffit donc de crer dans /etc/nagios3/conf.d un nouveau rpertoire nomm opsi pour ces configurations.
Les fichiers de configuration que nous allons placer dans ce rpertoire sont:
Nagios Template: opsitemplates.cfg
Hostgroups: opsihostgroups.cfg
Server Hosts: <full name of the server>.cfg
Commands: opsicommands.cfg
Contacts: opsicontacts.cfg
Services: opsiservices.cfg
Nous vous recommandons de mettre tous les fichiers de configuration du client dans des sous-rpertoires. Par con-
squent, vous crez dans /etc/nagios3/conf.d/opsi un autre rpertoire nomm clients.
20.5.3 modle Nagios: opsitemplates.cfg
Ltilisation des modles est une fonctionnalit standard de Nagios qui ne sera pas expliqu ici. Le principal avantage
est que cela rend les fichiers de configuration petitset plus faciles lire (et crire).
A lintrieur des modles nous utilisons certaines variables personnalises Nagios pour les valeurs souvent utiliss.
Selon le fait que le plus grand nombre de contrle doivent sexcuter sur le serveur de configuration opsi, nous allons
dfinir le nom et le port du serveur de configuration en tant que variable personnalise:
_configserver configserver.domain.local
_configserverurl 4447
Vous trouverez ce ci-dessous dans les dfinitions de modles.

Ces variables personnalises peuvent plus tard tre rfrenc par les macros Nagios: $_HOSTCONFIGSERVER$ et $_HO
STCONFIGSERVERPORT$. (Ces macros ont HOST dans leur nom, parce quils sont dfinis lintrieur dune dfinition
dhte).
Pour plus de dtails sur les variables et les macros regardez la documentation de Nagios.
Maintenant, le premier fichier que nous crons dans /etc/nagios3/conf.d/opsi est le fichier de dfinition de modle
opsitemplates.cfg.
Ce fichier peut contenir diffrents modles. Chaque modle est cr selon la base suivante (qui contient des commen-
taires pour mieux comprendre):
define host{
name opsihost-tmp ; The name of this host template
notifications_enabled 1 ; Host notifications are enabled
event_handler_enabled 1 ; Host event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
failure_prediction_enabled 1 ; Failure prediction is enabled
process_perf_data 0 ; Process performance data
retain_status_information 1 ; Retain status information across program restarts
retain_nonstatus_information 1 ; Retain non-status information across program restarts
max_check_attempts 10
notification_interval 0
notification_period 24x7
notification_options d,u,r
contact_groups admins
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
icon_image opsi/opsi-client.png
}
NOTE: * Loption facultative icon_image peut tre mise dans une image avec un chemin relatif dans: /usr/share/
nagios3/htdocs/images/logos/. * En option vous pouvez donner un propre contact_group, qui doivent tre dfinis
en tant quobjet de contact, par exemple dans le fichier opsicontacts.cfg.
Maintenant, nous recommandons de crer des modles pour les objets suivants
opsi server
opsi client
opsi service
et 2 modles pour pnp4nagios (host-pnp / srv-pnp)
Commenons par lexemple du modle du serveur opsi (opsi server):
define host{
name opsi-server-tmpl
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_command check-host-alive
contact_groups admins,opsiadmins
_configserverport 4447
register 0
}
Vous avez juste changer configserver.domain.local avec le nom de votre serveur de configuration. Aussi, vous pouvez
changer le contact_groups selon vos besoins.
La prochaine partie du fichier opsitemplates.cfg est le modle pour les clients:
define host{
name opsi-client-tmpl
process_perf_data 1
_configserverport 4447
register 0
}
Loption "check command check-host-alive" ne devrait tre pas dfinie ici parce que les clients ne sont pas toujours en
cours dexcution. En effet les clients seront affiches comme pending au lieu de offline.
Vous avez juste changer configserver.domain.local avec le nom de votre serveur de configuration. Aussi, vous pouvez
changer le contact_groups selon vos besoins.
La prochaine partie du fichier opsitemplates.cfg est le modle pour les opsi-services:
define service{
name opsi-service-tmpl
active_checks_enabled 1
passive_checks_enabled 1
parallelize_check 1
obsess_over_service 1
check_freshness 0
process_perf_data 1
is_volatile 0
check_period 24x7
normal_check_interval 5
retry_check_interval 1
notification_options w,u,c,r
register 0
}
Si vous utilisez pnp4nagios pour la reprsentation graphique des donnes de performance vous aurez besoin de deux
autres modles dans le fichier opsitemplates.cfg:
define host {
name host-pnp
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_
register 0
}
define service {
name srv-pnp
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
register 0
}
20.5.4 opsi hostgroup: opsihostgroups.cfg
La prochaine tape consiste dfinir les hostgroups. Cela contribue structurer laffichage des rsultats ainsi que les
dfinitions de services.
Crez donc un fichier nomm opsihostgroups.cfg avec le contenu suivant:
define hostgroup {
hostgroup_name opsi-clients
alias OPSI-Clients
}
define hostgroup {
hostgroup_name opsi-server
alias OPSI-Server
members configserver.domain.local, depotserver.domain.local
}
Ne pas oublier de modifier la ligne member.
20.5.5 opsi server: <nom complet du serveur>.cfg
Ltape suivante consiste crer pour chaque serveur opsi en cours dexcution un fichier de configuration propre. Ce
fichier doit tre nomm sur la base du modle <nom complet du serveur>.cfg. Par exemple configserver.domain.
local.cfg.
(Vous pouvez galement crer un fichier (ex. opsihost.cfg avec toutes les dfinitions de serveur).
Le contenu devrait ressembler ceci:
define host{
use opsi-server-tmpl
host_name configserver.domain.local
hostgroups opsi-server
alias opsi Configserver
address configserver.domain.local
}
define host{
use opsi-server-tmpl
host_name depotserver.domain.local
hostgroups opsi-server
alias opsi Depotserver
address depotserver.domain.local
}
Explication des entres: * use rfrences au modle utilise. * hostgroups nous dit quel hostgroup appartient ce
serveur.
20.5.6 opsi Clients: clients/<nom complet du client>.cfg
Les configurations des clients OPSI doivent tre placs dans un rpertoire propre. Elles doivent tre dfinies comme
ceci:
define host{
use opsi-client-tmpl
host_name client.domain.local
hostgroups opsi-clients
alias opsi client
address client.domain.local
_depotid depotserver.domain.local
}
Cette configuration du client utilise nouveau une variable personnalise: _depotid. Cette variable personnalise peut
tre rfrence par la macro $_HOSTDEPOTID$.
Lutilisation est facultative. Si un client nest pas connect directement au serveur de configuration opsi, vous devez
crir ici partir de quel serveur de dpt le client peut tre contact.
Pour faciliter la cration des fichiers de configuration pour votre nombreux clients OPSI, vous pouvez excuter le script
suivant sur votre serveur de configuration OPSI:
#!/usr/bin/env python
from OPSI.Backend.BackendManager import *
template =
define host {
use opsi-client-tmpl
host_name %hostId%
hostgroups opsi-clients
alias %hostId%
address %hostId%
}
backend = BackendManager(
dispatchConfigFile = u/etc/opsi/backendManager/dispatch.conf,
backendConfigDir = u/etc/opsi/backends,
extensionConfigDir = u/etc/opsi/backendManager/extend.d,
)
hosts = backend.host_getObjects(type="OpsiClient")
for host in hosts:

filename = "%s.cfg" % host.id
entry = template.replace("%hostId%",host.id)
f = open(filename, w)
f.write(entry)
f.close()
20.5.7 configuration commande opsi: opsicommands.cfg
Maintenant, nous devons dfinir quels sont les commandes de contrle, qui sont dcrites avant, que nous voulons
utiliser. Vous devez le faire dans un fichier nomm opsicommands.cfg.
Ceci est juste un exemple que vous pouvez modifier vos besoins:
Dabord nous expliquons la structure des entres:
define command{
command_name check_opsi_clientstatus
command_line $USER1$/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \
$USER3$ -t checkClientStatus -c $HOSTADDRESS$
}
command_name sera utilis par dautres fichiers de configuration. Loption command_line dfinit la commande et tous
les arguments utiliss.
Bas sur ce modle, nous crons maintenant le fichier opsicommands.cfg:
define command {
command_name check_opsiwebservice
command_line /usr/lib/nagios/plugins/check_opsi -H $HOSTADDRESS$ -P 4447 -u $USER2$ -p $USER3$ -t \
checkOpsiWebservice
}
define command {
command_name check_opsidiskusage
command_line /usr/lib/nagios/plugins/check_opsi -H $HOSTADDRESS$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \
$USER3$ -t checkOpsiDiskUsage
}
define command {
command_name check_opsiclientstatus
command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkClientStatus -c $HOSTADDRESS$
}
define command {
command_name check_opsiproductstatus
-p $USER3$ -t checkProductStatus -e $ARG1$ -d $HOSTADDRESS$ -v
}
define command {
command_name check_opsiproductStatus_withGroups
-p $USER3$ -t checkProductStatus -g $ARG1$ -G $ARG2$ -d "all"
}
define command {
command_name check_opsiproductStatus_withGroups_long
-p $USER3$ -t checkProductStatus -g $ARG1$ -G $ARG2$ -v -d "all"
}
define command {
command_name check_opsidepotsync
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$
}
define command {
command_name check_opsidepotsync_long
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ -v
}
define command {
command_name check_opsidepotsync_strict
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ --strict
}
define command {
command_name check_opsidepotsync_strict_long
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ --strict -v
}
define command {
command_name check_opsipluginon_client
-p $USER3$ -t checkPluginOnClient -c $HOSTADDRESS$ --plugin $ARG1$
}
define command {
command_name check_opsipluginon_client_with_states
-p $USER3$ -t checkPluginOnClient -c $HOSTADDRESS$ --plugin $ARG1$ -s $SERVICESTATEID$ -o "$SERVICEOUTPUT$"
}
define command {
command_name check_opsipluginon_client_from_depot
command_line /usr/lib/nagios/plugins/check_opsi -H $_HOSTDEPOTID$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$ -p \
$USER3$ -t checkPluginOnClient -c $HOSTADDRESS$ --plugin $ARG1$
}
20.5.8 Contacts: opsicontacts.cfg
Ceci dfinit les contacts qui obtiendront les notifications.

define contact{
contact_name adminuser
alias Opsi
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email root@localhost
}
define contactgroup{
contactgroup_name opsiadmins
alias Opsi Administrators
members adminuser
}
Vous devez remplacer adminuser par un ou plusieurs utilisateurs rels.
20.5.9 Services: opsiservices.cfg
Enfin, nous dfinissons avec services ce que les serveur Nagios doivent surveiller et afficher. Cette dfinition utilise
comme modles, commandes et hostgroups ou hosts la dfinition de lautre fichier de configuration susmentionn.
Comme premire partie nous dfinissons les services qui nous donnent des informations sur les serveurs. Lun deux
est le contrle de la synchronisation des dpts, qui est ici-bas en opposition avec tous les dpts connus.
#OPSI-Services
define service{
use opsi-service-tmpl,srv-pnp
service_description opsi-webservice
check_command check_opsiwebservice
check_interval 1
}
define service{
use opsi-service-tmpl
service_description opsi-diskusage
check_command check_opsidiskusage
check_interval 1
}
define service{
service_description opsi-depotsyncstatus-longoutput
check_command check_opsidepotsync_long!all
check_interval 10
}
define service{
service_description opsi-depotsyncstatus-strict-longoutput
check_command check_opsidepotsync_strict_long!all
check_interval 10
}
La prochaine partie est le suivi du dploiement de logiciels. Dans un contrle un produit concret opsi opsi-client-agent
est mentionn. Dans deux autres contrles sont rfrencs un groupe de produits opsi opsiessentials et un groupe de
client opsi productiveclients.
define service{
hostgroup_name opsi-clients
service_description opsi-clientstatus
check_command check_opsiclientstatus
check_interval 10
}
define service{
service_description opsi-productstatus-opsiclientagent
check_command check_opsiproductstatus!opsi-client-agent
check_interval 10
}
define service{
service_description opsi-productstatus-opsiessentials-group
check_command check_opsiproductStatus_withGroups!opsiessentials!productiveclients
check_interval 10
}
define service{
service_description opsi-productstatus-opsiessentials-group-longoutput
check_command check_opsiproductStatus_withGroups_long!opsiessentials!productiveclients
check_interval 10
}
Dans la troisime et dernire partie du fichier sont dfinis les contrles qui doivent sexcuter directement sur les clients
(direct checks).
Ces contrles ne sont pas (par exemple) affect des hostgroups mais un seul host ou des listes dhosts
(client.domain.local,depotclient.domain.local).
Certains descriptif:
opsi-direct-checkpluginonclient
excute des contrles direct sur le client et renvoie unknown si le client est dconnect.
Lors de cette vrification le serveur de configuration essaie datteindre le client directement.
opsi-direct-checkpluginonclient-with-servicestate
est gal opsi-direct-checkpluginonclient, mais il renvoie le dernier rsultat valide si le client est dconnect (au lieu
de unknown)
opsi-direct-checkpluginonclient-from-depot
est gal opsi-direct-checkpluginonclient, mais le client sera contact par le serveur qui est donne dans la configu-
ration de lhte comme _depotid.
define service{
host_name client.domain.local,depotclient.domain.local
service_description opsi-direct-checkpluginonclient
check_command check_opsipluginon_client!"C:\\opsi.org\\nagiosplugins\\check_memory.exe"
check_interval 10
}
define service{
host_name client.domain.local
service_description opsi-direct-checkpluginonclient-with-servicestate
check_command check_opsipluginon_client_with_states!"C:\\opsi.org\\nagiosplugins\\\
check_memory.exe"
check_interval 10
}
define service{
host_name depotclient.domain.local
service_description opsi-direct-checkpluginonclient-from-depot
check_command check_opsipluginon_client_from_depot!"C:\\opsi.org\\nagiosplugins\\check_memory\
.exe"
check_interval 10
}
21 Installation dopsi lors de larrt
21.1 Introduction
Habituellement, linstallation des paquets de logiciels opsi sur le client est lanc au dmarrage du client. Ainsi, lutil-
isateur doit attendre que linstallation se termine, avant que louverture de session utilisateur soit autorise. Il pourrait
tre utile de faire la plupart de linstallation du logiciel lorsque le client va arrter.
Le module opsi pour linstallation lors de larrt apporte cette fonctionnalit. Les clients slectionns peuvent tre
configurs pour faire linstallation larrt.
21.2 Conditions pralables linstallation lors de larrt
Le module opsi dinstallation lors de larrt peut tre utilis pour des clients partir de Windows XP. Les composants
ncessaires font partie du paquet opsi opsi-client-agent. Actuellement, ce module est en projet de cofinancement. Donc,
il ncessite un fichier spcial des modules pour dverrouiller cette fonctionnalit. Pour plus de dtails sur les projets
en cofinancement voir Section 6 et le lien internet projets en co-financement.
Le paquet opsi-client-agent doit tre la version 4.0.2.3-2 ou suprieur et opsiclientd la version 4.0.75 ou suprieur.
Les cas suivants sont des restrictions et contraintes techniques:
Extension WAN: le module dinstallation lors de larrt, nest actuellement pas disponible pour les clients fonction-
nent avec lextension WAN. Lutilisation de lextension WAN pour un client, sous certaines conditions, ncessite
dutiliser les fichiers de configuration locaux, qui gnent la manipulation de ltat de linstallation sur le mcanisme
darrt.
Les stratgies de groupe: une partie du mcanisme dinstallation lors de larrt est bas sur des scripts darrt par
la stratgie de groupe locale. Dautres stratgies de groupe peuvent remplacer ces configurations locales. Dans ce
cas, la configuration requise pour lexcution de scripts darrt devraient tre inclus dans vos stratgies de groupe
prise en charge. Voir Section 21.4.2 pour les configurations requises.
Windows Home Edition: Windows Home ne fournit pas le ncessaire mcanisme de script darrt via la stratgie de
groupe locale. Par consquent, linstallation lors de larrt ne peut pas tre utilis pour Windows Home Edition.
Windows 2000: Pour les clients Windows 2000 le dlai dattente maximal pour les scripts darrt est de 10 minutes.
Aprs 10 minutes, linstallation est interrompue par le systme Windows. Par consquent, linstallation lors de larrt
ne peut pas tre utilis pour les clients Windows 2000.
21.3 Activation de linstallation lors de larrt
Les composants requis pour linstallation lors de larrt font partie de lactuel paquet opsi-client-agent. Pour le
dverrouiller, un fichier modules valide doit tre obtenue et copi sur le serveur.
En suite, linstallation lors de larrt peut tre configur pour les clients appropris (voir Section 21.2) en tablissant
pour opsi-client-agent la proprit du produit on_shutdown_install=on et en fixant opsi-client-agent=setup.
a y est. Tout le reste de la configuration est effectue par le paquet opsi-client-agent lors de linstallation.
Linstallation lors de larrt se fait en plus de linstallation au dmarrage. Habituellement, cest le meilleur moyen de
sassurer que les clients ont toujours les mises jour de scurit actuels install, mme si le client tait teinte pendant
une longue priode (lorsque lutilisateur est en vacances par exemple). Si ncessaire, linstallation au dmarrage par
dfaut peut tre dsactive, voir Section 21.4.5. Les installations en cours se poursuivent tout de mme, ce qui est
command par la condition installation_pending.
Le systme Windows lors de larrt du systme ne distingue pas larrt du redmarrage. Linstallation lors de larrt
est lanc dans les deux cas et il nest pas possible de les distinguer lors de linstallation. En outre, il nest pas possible
de transformer un arrt du systme dans un redmarrage (ou vice versa). Ainsi, en cas dun arrt du systme, toutes
les autres installations sont poursuivies au prochain dmarrage du systme.
21.4 Concept technique
Les explications qui suivent sont pour la comprhension de la conception technique et les interactions entre les com-
posants en cas de configurations particulires ou des tats derreur. Habituellement toutes les configurations requises
sont effectues par le paquet opsi-client-agent.
21.4.1 Vue densemble
Le module dinstallation lors de larrt repose sur plusieurs lments du systme. Une partie importante est le m-
canisme du script darrt de Windows via la stratgie de groupe locale. Les scripts darrt permettent dexcuter des
tches larrt, lorsque lutilisateur est dj dconnect, mais tous les services du systme sont encore disponibles.
Le script darrt effectue une tche opsi, qui dclenche la fonction systme opsi opsiclientd pour dmarrer le processus
dinstallation et attendre la fin de la tche. Ainsi, le systme attend que le processus dinstallation se termine puis sar-
rte. Lors de la manipulation darrt, le systme Windows ne distingue pas larrt du redmarrage, donc linstallation
est dclench dans les deux cas.
Le service client opsi opsiclientd est configur pour traiter laction on_shutdown, qui commence le processus dinstal-
lation. En cas de redmarrages requis, la condition pralable installation_pending permet le contrle du proces-
sus. Si, lors de linstallation, un redmarrage est ncessaire avant de poursuivre linstallation, la condition pralable
installation_pending mne poursuivre linstallation au prochain dmarrage du systme (mme si linstallation
gui_startup est dsactive). Pendant ltat de installation_pending, aucune autre installation larrt ne sera
dclench, sinon, il ny aurait pas de redmarrage entre linstallation au dmarrage et linstallation lors de larrt.
Donc, jusqu ce que linstallation actuelle soit termine, linstallation lors de larrt est supprim par la mise en
event_on_shutdown{installation_pending}.
Le chapitre suivant donne quelques dtails supplmentaire sur linstallation lors de larrt.
21.4.2 Installation par script darrt
Au travers de spciales entres de registre, la stratgie de groupe locale est configur pour effectuer un script darrt
opsi, ce qui dclenche le processus dinstallation. Les entres du registre utilises par opsi-client-agent sont les
mmes quen utilisant lditeur de stratgie de groupe gpedit.msc.
Ceci est la faon de configurer le script darrt laide de lditeur de stratgie de groupe gpedit.msc:
Stratgie dordinateur local
Configuration de lordinateur
Paramtres Windows
Scripts (Dmarrage/Arrt)
Arrt
Scripts - Ajout - Parcourir
C:\Programme\opsi.org\opsi-client-agent\on_shutdown\doinstall32.cmd (ou doinstall64.cmd pour 64Bit systems)
Pour configurer le systme afin dattendre la fin du processus dinstallation, le temps dattente maximum est rgle
sur linfini (0 secondes):
Modles dadministration
Systme - Scripts
Temps dattente maximal pour les scripts de stratgie de groupe
Rglage - Activ - Secondes: 0
Le script darrt opsi doinstall32.cmd / doinstall64.cmd change le rpertoire de travail et dclenche lvnement
on_shutdown:
echo Start opsi product installation ...
cd "%ProgramFiles%\opsi.org\opsi-client-agent"
opsiclientd_shutdown_starter.exe on_shutdown
Pour les systmes 64 bits:

echo Start opsi product installation ...
cd "%ProgramFiles(x86)%\opsi.org\opsi-client-agent"
opsiclientd_shutdown_starter.exe on_shutdown
opsiclientd_shutdown_starter il dclenche linstallation et attend lexcution, si larrt du systme est retard

pendant que la tche opsiclientd_shutdown_starter est en cours dexcution.
21.4.3 Entres de Registre pour excuter le script darrt
Ces entres de Registre est fix par les paquets opsi-client-agent et dmarrer lexcution du script darrt doin-
stall32.cmd sous des clients WinXP / 32Bit. Pour les systmes 64 bits, le nom du script est doinstall64.cmd (au lieu
de doinstall32.cmd).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="opsi shutdown install policy"
"GPOName"="opsi shutdown install policy"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0\0]
"Script"="C:\\Programme\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall32.cmd"
"Parameters"=""
"ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0\0]
"Parameters"=""
"ExecTime"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system]
"MaxGPOScriptWait"=dword:00000000
Celles-ci sont les entres de registre pour Win6 64Bit (Vista / Win7 / Win8):
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0\0]
"Parameters"=""
"ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\Windows\\System32\\GroupPolicy\\Machine"
"PSScriptOrder"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0\0]
"Script"="C:\\Program Files (x86)\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall64.cmd"
"Parameters"=""
"IsPowershell"=dword:00000000
"ExecTime"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system]
"MaxGPOScriptWait"=dword:00000000
21.4.4 Configuration de opsiclientd
Pour la gestion de linstallation lors de larrt, le service client opsi opsiclientd a besoin des entres pour lvnement
spcial on_shutdown dans le fichier de configuration opsiclientd.conf. Celles-ci sont les entres correspondantes:
[event_gui_startup]
active = True
[event_gui_startup{installation_pending}]
active = True
[event_on_shutdown]
active = False
[event_on_shutdown{installation_pending}]
active = False
[precondition_installation_pending]
installation_pending = true
La condition pralable installation_pending est rgle sur true par opsiclientd alors quune installation est en
cours, et elle est rgle false lorsque linstallation est termine. Ainsi, une installation inacheve, qui doit procder
linstallation aprs un redmarrage, peut tre dtecte par la condition installation_pending encore tant true la
fin de lexcution du script. Lorsque la section event_on_shutdown est rgle sur False (qui est la valeur par dfaut),
linstallation lors de larrt est dsactiv.
Celle-ci est la configuration dun client avec linstallation lors de larrt active:
[event_gui_startup]
active = True
[event_gui_startup{installation_pending}]
active = True
[event_on_shutdown]
active = True
[event_on_shutdown{installation_pending}]
active = False
[precondition_installation_pending]
installation_pending = true
Donc, la seule diffrence est la section event_on_shutdown tant True:

[event_on_shutdown]
active = True.
Le rglage de la section event_on_shutdown est gr par le commutateur produit on_shutdown_install du paquet

opsi-client-agent.
La condition pralable precondition_installation_pending =true indique que le processus dinstallation en cours
nest pas encore termin. Cette condition reste true, mme aprs plusieurs redmarrages, jusqu ce que linstallation
actuelle est complt. Dans le cas dun redmarrage ncessaire lors de linstallation, la configuration [event_gui_s
tartup{installation_pending}] active =True provoque la poursuite de linstallation au prochain dmarrage du
systme. Cette configuration ne peut pas tre chang, parce que linstallation actuelle doit tre complte, avant que
lutilisateur soit autoris se connecter.
galement la configuration [event_on_shutdown{installation_pending}] active =False doit conserver sa valeur
False en permanence, parce que linstallation doit se poursuivre APRS le prochain redmarrage. Sinon, il ny aurait
pas un redmarrage entre linstallation au dmarrage et linstallation lors de larrt.
Ds que le processus dinstallation est termin, la condition pralable est rgl sur installation_pending =false,
de sorte que linstallation lors de larrt est de nouveau active.
21.4.5 Configuration spciale dInstallation lors de lArrt
Pour activer linstallation larrt, juste un fichier modules valide est ncessaire, comme dcrit dans Section 21.3.
Ensuite, linstallation lors de larrt, peut tre activ en positionnant le commutateur de produit on_shutdown_install
du paquet opsi-client-agent.
Par faut, linstallation au dmarrage est galement active. Donc il est assur, que le client a toujours de logiciels mis
jour. Mme sil a t hors ligne pendant un certain temps (lorsque lutilisateur rentre de vacances, par exemple).
Linstallation au dmarrage peut tre dsactive, si on le dsire. La configuration de opsi-client-agent peut tre effectue
par le service Web (voir: Section 7.3.6), therefore an opsi-config-object should be created:
opsiclientd.event_gui_startup.active (boolean, default: true)
Par ce opsi-config-object lvnement gui_startup peut tre configur pour un client. opsi-config-objects peut tre cre
par opsi-configed ou opsi-admin.
Pour la cration de opsi-config-object avec opsi-admin, excutez la commande suivante sur le opsi-configserver:
opsi-admin -d method config_createBool opsiclientd.event_gui_startup.active "gui_startup active" true
La valeur par dfaut true est la valeur par dfaut dans opsiclientd.conf.
Pour dsactiver linstallation au dmarrage pour un client, opsi-config-object peut tre configur comme suit:
opsiclientd.event_gui_startup.active: false
Soyez prudent avec la dsactivation de linstallation au dmarrage, car il y a un risque lev davoir des logiciels
obsoltes. Ne jamais modifier les paramtres des sections de la condition installation_pending. Les paramtres par
dfaut sont ncessaires pour grer le processus dinstallation.
Pour dfinir opsi-config-object avec opsi-admin, excutez la commande suivante sur le opsi-configserver (dans lexemple,
pour un client avec opsi-host-Id myclient.domain.de):
opsi-admin -d method configState_create opsiclientd.event_gui_startup.active myclient.domain.de false
Avec la configuration event_gui_startup=false il ny a pas de connexion opsi-configserver et aucune installation

de logiciel au dmarrage. A lexception des installations en cours, qui continuent au dmarrage du systme. Cela
est gr par la configuration event_on_shutdown{installation_pending}. Donc, ne modifiez pas les paramtres
pour les sections avec la condition installation_pending, car ils sont importants pour les produits qui demandent un
redmarrage lors de linstallation.
21.4.6 Fichier de log local
Au cours de linstallation lors de larrt, un fichier de log est crit:

C:\opsi.org\tmp\doinstall.log
avec, en cas de succs, le contenu suivant:
doinstall32.cmd started
The current date is: .Tue 02/012/2013
Enter the new date: (mm-dd-yy) Backend connected.
modules: passed first checkpoint.
Modules file signature verified (customer: my company)
Check completed.
Event fired
Task completed.
Ce fichier de log est rcrit chaque fois et peut tre vrifie dans le cas dun dysfonctionnement.
22 La fonctionnalit opsi SilentInstall

La fonctionnalit opsi SilentInstall fournit aux administrateurs la possibilit dinstaller un logiciel sur un client sans
que lutilisateur connect soit drang. Ce chapitre dcrit les caractristiques de cette fonctionnalit et propose des
lignes directrices pour la configuration de cette nouvelle mthode dinstallation.
22.1 Conditions pralables linstallation en mode silencieux
Pour utiliser cette fonctionnalit, est requise la version opsi 4.0.3. ou au-dessus, et pour opsi-client-agent est requise
la version 4.0.3.1 ou au-dessus.
22.2 Vue densemble de la fonctionnalit SilentInstall
La mthode dinstallation silencieuse offre la possibilit dinstaller une liste prdfinie de produits sur un client, sans
que lutilisateur ait interrompre son travail. Contrairement linstallation onDemand (linstallation pousse), la
mthode SilentInstall naffiche rien sur le bureau de lutilisateur.
Tous les affichages sont supprimes, et ne seront pas vus sous tous les bureaux. Bien sr, cette fonctionnalit porte un
certain risque. En cas de problme, ex. une erreur de syntaxe du script opsi-winst, il ny a aucun moyen dinteragir avec
le processus dinstallation, aucune bote de dialogue sera prsents. Donc cela se traduirait par le fait que le traitement
de lvnement par opsi-winst ne sachve pas, et donc, aucun autre vnement ne sera plus excut. Pour viter ce
"Scnario le plus dfavorable", le temps dinstallation maximale est limite par un dlai dattente dans la configuration.
Cette valeur de temporisation peut tre adapt dans le cas dune installation prolonge. Pour plus dinformations, voir
le chapitre sur la configuration.
Une autre possibilit trs importante de cette fonctionnalit est la liste prdfinie de produits destins tre installs en
mode silencieux. Un contact avec le service est tabli, mais diffremment de la procdure habituelle, les ActionRequests
propose par le service sont ignors. La liste des logiciels installer est dfinie par une configuration de opsi-client-agent
configuration. Laction "setup" sera excute pour tous les produits figurant sur cette liste sans quils soient mis setup.
Comme dhabitude, aprs le traitement du script de configuration, le script de mise jour galement sera excut,
si celui-ci existe. Les dpendances de produits ne seront pas rsolues. Donc, aucun produit contenant des
dpendances dautres produits doit tre install par la fonctionnalit SilentInstall, ou sinon tous les produits de la liste
de dpendance doivent tre ajouts la liste des produits SilentInstall. Comme dhabitude, le processus dinstallation se
termine en envoyant ltat dinstallation et les fichiers de log de linstallation au service. En rsum, il est recommand
dutiliser le SilentInstall que pour les produits qui satisfont aux exigences suivantes:
petits paquets ou installations singulires
peu de charge du systme: certaines installations de logiciels, donc la plupart par exemple des installations MSI, il
demandent pendant linstallation la plupart des ressources client. Il pourrait en rsulter un mauvais rendement du
systme pour lutilisateur.
installable dans un laps de temps fixe: le dlai dattente par dfaut pour cet vnement est de 300 secondes. Si le
processus dinstallation nest pas termine dans le dlai, le processus opsi-winst sera termin et donc lvnement
pourra tre complt.
pas de redmarrage ncessaire: sde logiciels demandant un redmarrage ne devrait pas tre installs partir du
SilentInstall. Avec la configuration par dfaut, lvnement est configur pour ne pas traiter toutes les demandes
de redmarrage. Sans cette configuration de scurit opsi-client-agent pourrait redmarrer le client sans aucun
avertissement lutilisateur. Cela pourrait entraner une perte de donnes si il y a un utilisateur connect. Il
pourrait en rsulter un logiciel inutilisable install par SilentInstall sans redmarrage.
Dans la configuration par dfaut swaudit et hwaudit sont installs par ce procd. Les produits dinventaire de OPSI,
il satisfont toutes les exigences ci-dessus et sont donc applicables pour cette mthode. Avec la configuration par
dfaut, les inventaires matriels et logiciels OPSI sont gnrs la demande, sans la ncessit dtablir la demande
daction dinstallation avec opsi-configed. Avec cette mthode, les informations dinventaire peuvent tre gnrs en
temps rel. galement applicable tout produit de configuration, qui effectuent des rparations automatiques ou des
restaurations de correctifs client.
22.3 Excution de linstallation silencieuse
Cet vnement ne se dclenche pas automatiquement comme les autres vnements. Il y a donc deux manires de
raliser cet vnement.
La premire voie est de dclencher lvnement partir du webservice opsi, comme par exemple:
opsi-admin -d method hostControl_fireEvent silent_install client.domain.local
Donc cette commande est scriptable, et peut tre utilis dans des scripts qui peut tre combin avec un at-job pour
planifier lexcution de lvnement.
Comme alternative, lvnement peut tre dclench par un vnement programm, aprs un certain laps de temps.
La configuration par dfaut pour cet vnement est de 6 heures. Cette valeur suppose quun poste de travail est
habituellement utilis pendant 8 heures. Donc lvnement sera excut une fois par jour au bout de six heures de
temps de fonctionnement. Pour plus dinformations sur la configuration et lactivation de cet vnement, voir le chapitre
suivante.
22.4 Configuration de la fonctionnalit opsi: SilentInstall
Ce chapitre traite de la configuration par dfaut de cette fonctionnalit. Par dfaut opsiclientd.conf possde vnement
SilentInstall. Cette liste indique uniquement les options importantes:
vnement standard SilentInstall:
[event_silent_install]
process_shutdown_requests = false
action_processor_productIds = swaudit,hwaudit
action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent
action_processor_desktop = winlogon
action_processor_productIds
Cette option est une nouvelle proprit importante pour le contrle des vnements. Pour tous les vnements qui
excutent des actions de produits, cette option permet de dfinir une liste de produits. La liste des produits doit
tre donne sous forme de liste spare par des virgules.
process_shutdown_request = false
Cette configuration supprime les demandes de redmarrage de opsi-winst.
action_processor_command
Cette configuration prpare lappel opsi-winst.
action_processor_desktop
Cette option dfinit le bureau pour afficher linterface graphique opsi-winst.
action_processor_timeout
Cette option dfinit le dlai dattente pour terminer le processus opsi-winst.
Le deuxime vnement est lvnement de temporisation, qui dclenche lvnement aprs un certain laps de temps:
vnement de temporisation par dfaut pour SilentInstall
[event_timer_silentinstall]
super = silent_install
type = timer
active = false
interval = 21600
super
Cette option dfinit partir de quel vnement hriter les proprits. Par dfaut il hrite de lvnement
silent_install.
type
Cette option dfinit que lvnement est un Timer-Event.
active
par dfaut cet vnement nest pas actif. Pour lactiver, rglez cette option sur true.
interval
Cette option dfinit lintervalle pour dclencher lvnement. La valeur par dfaut est 6 heures, donc au bout de
six heures de temps de fonctionnement lvnement est dclench pour la premire fois, puis tous les six autres
heures. Donc cet intervalle devrait (comme nimporte quel intervalle de temporisation) ne pas tre trop court,
autrement, lvnement sera effectu la plupart du temps, en bloquant ainsi lexcution dautres actions. Dautre
part, lintervalle ne devrait pas tre trop long, pour que opsi-client-agent soit excut tout ce temps, jusqu ce
que lvnement est dclench. Si le client ou opsi-client-agent sont toujours redmarrs avant que lintervalle est
coul, cet vnement ne sera jamais dclench.
En outre, lvnement SilentInstall pourrait tre dclench par un autre vnement systme, dtecte par une de-
mande WMI. Donc une option wql peut tre spcifie. Comment spcifier loption wql doit tre vu dans la section
event_net_connection. Si loption wql est utilise, lvnement doit tre rgl sur active = false par dfaut, de sorte
quil peut tre activ suite la demande.
Pour dclencher lvnement par un temporisateur, en gnral il suffit de dfinir un paramtre hte. Donc, une con-
figuration par dfaut doit tre dabord cre. Dans ce cas, il suffit dactiver la temporisation de lvnement.
Pour crer loption standard, les suivants opsi-config-objects doivent tre cres par opsi-admin. Cette configuration
peut tre cr aussi par opsi-configed:
opsi-admin -d method config_createBool opsiclientd.event_timer_silentinstall.active "event_timer_silentinstall active" \
false
Donc, dans un premier temps, cet vnement est dsactive pour tous les clients. Ensuite, lvnement peut tre activ
pour les clients individuels:
opsi-admin -d method configState_create opsiclientd.event_timer_silentinstall.active silentclient.domain.de true
Pour dfinir les produits installer, lentre suivante doit tre dfinie. Si, par exemple, au lieu de swaudit et hwaudit
doit tre install le produit firefox, les entres devraient tre cre tel que dcrit ci-dessus:
opsi-admin -d method config_createUnicode opsiclientd.event_silent_install.action_processor_productIds "\
event_silent_install productIds" "swaudit,hwaudit"
Avec cette option par dfaut pour tous les clients la liste des produits pour lvnement SilentInstall est dfini sur
swaudit et hwaudit. Pour modifier la liste des produits pour un seul client en firefox excutez la commande suivante:
opsi-admin -d method configState_create opsiclientd.event_silent_install.action_processor_productIds client.domain.de "\
firefox"
Comme vous pouvez le voir, la liste des produits peut tre diffrente pour chaque client.
23 opsi data storage (backends)
23.1 file backend
With the backend type {file backend} the configuration information is kept in text files (ini file syntax) on the server.
Important details of the backend file :
It is the default backend
You will find the files of this backend at /var/lib/opsi.
More details to the files and theire structure you will find at Section 24.4.
23.2 ldap-Backend
The opsi backends are configured at /etc/opsi/backends/*.conf. If you are intend to use the backend ldap, you have
to write down the detail how to access your LDAP in the `ldap.conf`file here.
Furthermore you have to configure for which data you want to use the ldap backend. How to do this is described in
the getting started manual chapter backend configuration.
The opsi data you will find below the LDAP base at the organizationalRole cn=opsi (e.g. cn=opsi, dc=uib, dc=local).
Below this node you will find the complete opsi data structure.
You may use for example the tool Jxplorer to browse the LDAP data.
opsi ldap in the jxplorer
Figure 84 opsi ldap backend in the Jxplorer
23.3 mysql backend
23.3.1 mysql backend for inventory data
Inventory data at the backend file is stored in structured text files by default. This type of storage is not very useful if
you wish to form free queries on these data. In order to allow free queries and reports a mysql based backend for the
inventory data has been introduced.
The main characteristics of this backend are: * only for inventory data free (for other data it is part of a co funding
project until now) * optional (not the default backend) * a very fine granulated data structure with an additional
table to make queries easier. * a history function which tracks changes in the inventory.
Regarding the very different structure of the components in the inventory the resulting data structure is complex.
The table hosts comprises all known hosts. For every device type we use two tables: The HARDWARE_DEVICE_
.table describes the model without individual aspects like the serial number. The HARDWARE_CONFIG table stores
these individual and configuration data.
These both tables are connected via the field hardware_id. This is the resulting list of tables:
HARDWARE_CONFIG_1394_CONTROLLER
HARDWARE_CONFIG_AUDIO_CONTROLLER
HARDWARE_CONFIG_BASE_BOARD
HARDWARE_CONFIG_BIOS
HARDWARE_CONFIG_CACHE_MEMORY
HARDWARE_CONFIG_COMPUTER_SYSTEM
HARDWARE_CONFIG_DISK_PARTITION
HARDWARE_CONFIG_FLOPPY_CONTROLLER
HARDWARE_CONFIG_FLOPPY_DRIVE
HARDWARE_CONFIG_HARDDISK_DRIVE
HARDWARE_CONFIG_IDE_CONTROLLER
HARDWARE_CONFIG_KEYBOARD
HARDWARE_CONFIG_MEMORY_BANK
HARDWARE_CONFIG_MEMORY_MODULE
HARDWARE_CONFIG_MONITOR
HARDWARE_CONFIG_NETWORK_CONTROLLER
HARDWARE_CONFIG_OPTICAL_DRIVE
HARDWARE_CONFIG_PCI_DEVICE
HARDWARE_CONFIG_PCMCIA_CONTROLLER
HARDWARE_CONFIG_POINTING_DEVICE
HARDWARE_CONFIG_PORT_CONNECTOR
HARDWARE_CONFIG_PRINTER
HARDWARE_CONFIG_PROCESSOR
HARDWARE_CONFIG_SCSI_CONTROLLER
HARDWARE_CONFIG_SYSTEM_SLOT
HARDWARE_CONFIG_TAPE_DRIVE
HARDWARE_CONFIG_USB_CONTROLLER
HARDWARE_CONFIG_VIDEO_CONTROLLER
HARDWARE_DEVICE_1394_CONTROLLER
HARDWARE_DEVICE_AUDIO_CONTROLLER
HARDWARE_DEVICE_BASE_BOARD
HARDWARE_DEVICE_BIOS
HARDWARE_DEVICE_CACHE_MEMORY
HARDWARE_DEVICE_COMPUTER_SYSTEM
HARDWARE_DEVICE_DISK_PARTITION
HARDWARE_DEVICE_FLOPPY_CONTROLLER
HARDWARE_DEVICE_FLOPPY_DRIVE
HARDWARE_DEVICE_HARDDISK_DRIVE
HARDWARE_DEVICE_IDE_CONTROLLER
HARDWARE_DEVICE_KEYBOARD
HARDWARE_DEVICE_MEMORY_BANK
HARDWARE_DEVICE_MEMORY_MODULE
HARDWARE_DEVICE_MONITOR
HARDWARE_DEVICE_NETWORK_CONTROLLER
HARDWARE_DEVICE_OPTICAL_DRIVE
HARDWARE_DEVICE_PCI_DEVICE
HARDWARE_DEVICE_PCMCIA_CONTROLLER
HARDWARE_DEVICE_POINTING_DEVICE
HARDWARE_DEVICE_PORT_CONNECTOR
HARDWARE_DEVICE_PRINTER
HARDWARE_DEVICE_PROCESSOR
HARDWARE_DEVICE_SCSI_CONTROLLER
HARDWARE_DEVICE_SYSTEM_SLOT
HARDWARE_DEVICE_TAPE_DRIVE
HARDWARE_DEVICE_USB_CONTROLLER
HARDWARE_DEVICE_VIDEO_CONTROLLER
HOST
SOFTWARE
SOFTWARE_CONFIG
Which field name in the database is corresponding to which reported and localized name in the opsi management
interface is defined in a configuration file. Example (/etc/opsi/hwaudit/locales/en_US):
DEVICE_ID.deviceType = Device type
DEVICE_ID.vendorId = Vendor ID
DEVICE_ID.deviceId = Device ID
DEVICE_ID.subsystemVendorId = Subsystem vendor ID
DEVICE_ID.subsystemDeviceId = Subsystem device ID
DEVICE_ID.revision= Revision
BASIC_INFO.name = Name
BASIC_INFO.description = Description
HARDWARE_DEVICE.vendor = Vendor
HARDWARE_DEVICE.model = Model
HARDWARE_DEVICE.serialNumber = Serial number
COMPUTER_SYSTEM = Computer
COMPUTER_SYSTEM.systemType = Type
COMPUTER_SYSTEM.totalPhysicalMemory = Physical Memory
CHASSIS = Chassis
CHASSIS.name = Name
CHASSIS.chassisType = Chassis type
CHASSIS.installDate = Installation date
CHASSIS.serialNumber = Serial number
BASE_BOARD = Base board
BASE_BOARD.product = Product
BIOS = BIOS
BIOS.version = Version
SYSTEM_SLOT = System slot
SYSTEM_SLOT.currentUsage = Current usage
SYSTEM_SLOT.status = Status
SYSTEM_SLOT.maxDataWidth = Maximum data width
PORT_CONNECTOR = Port
PORT_CONNECTOR.connectorType = Attributes
PORT_CONNECTOR.internalDesignator = Internal designator
PORT_CONNECTOR.internalConnectorType = Internal type
PORT_CONNECTOR.externalDesignator = External designator
PORT_CONNECTOR.externalConnectorType = External type

PROCESSOR = Processor
PROCESSOR.architecture = Architecture
PROCESSOR.family = Family
PROCESSOR.currentClockSpeed = Current clock speed
PROCESSOR.maxClockSpeed = Maximum clock speed
PROCESSOR.extClock = External clock
PROCESSOR.processorId = Processor-ID
PROCESSOR.addressWidth = Address width
PROCESSOR.socketDesignation = Socket designation
PROCESSOR.voltage = Voltage
MEMORY_BANK = Memory bank
MEMORY_BANK.location = Location
MEMORY_BANK.maxCapacity = Maximum capacity
MEMORY_BANK.slots = Number of slots
MEMORY_MODULE = Memory module
MEMORY_MODULE.deviceLocator = Device locator
MEMORY_MODULE.capacity = Capacity
MEMORY_MODULE.formFactor = Form factor
MEMORY_MODULE.speed = Speed
MEMORY_MODULE.memoryType = Memory type
MEMORY_MODULE.dataWidth = Data width
MEMORY_MODULE.tag = Tag
CACHE_MEMORY = Cache memory
CACHE_MEMORY.installedSize = Installed size
CACHE_MEMORY.maxSize = Maximum size
CACHE_MEMORY.location = Location
CACHE_MEMORY.level = Level
PCI_DEVICE = PCI device
PCI_DEVICE.busId = Bus id
NETWORK_CONTROLLER = Network adapter
NETWORK_CONTROLLER.adapterType = Adapter type
NETWORK_CONTROLLER.maxSpeed = Maximum speed
NETWORK_CONTROLLER.macAddress = MAC address
NETWORK_CONTROLLER.netConnectionStatus = Net connection status
NETWORK_CONTROLLER.autoSense = auto-sense
NETWORK_CONTROLLER.ipEnabled = IP protocoll enabled
NETWORK_CONTROLLER.ipAddress = IP address
AUDIO_CONTROLLER = Audio controller
HDAUDIO_DEVICE = HD Audio device
HDAUDIO_DEVICE.address = Addresse
IDE_CONTROLLER = IDE controller
SCSI_CONTROLLER = SCSI controller
FLOPPY_CONTROLLER = Floppy controller
USB_CONTROLLER = USB controller
1394_CONTROLLER = 1394 controller
PCMCIA_CONTROLLER = PCMCIA controller
VIDEO_CONTROLLER = Video controller
VIDEO_CONTROLLER.videoProcessor = Video processor
VIDEO_CONTROLLER.adapterRAM = Adapter RAM
DRIVE.size = Size
FLOPPY_DRIVE = Floppy drive
TAPE_DRIVE = Tape drive
HARDDISK_DRIVE = Harddisk drive
HARDDISK_DRIVE.cylinders = Cylinders
HARDDISK_DRIVE.heads = Heads
HARDDISK_DRIVE.sectors = Sectors
HARDDISK_DRIVE.partitions = Partitions
DISK_PARTITION = Partition
DISK_PARTITION.size = Size
DISK_PARTITION.startingOffset = Starting offset
DISK_PARTITION.index = Index
DISK_PARTITION.filesystem = Filesystem
DISK_PARTITION.freeSpace = Free space
DISK_PARTITION.driveLetter = Drive letter
OPTICAL_DRIVE = Optical drive
OPTICAL_DRIVE.driveLetter = Drive letter
USB_DEVICE = USB device
USB_DEVICE.vendorId = Vendor ID
USB_DEVICE.deviceId = Device ID
USB_DEVICE.usbRelease = USB release
USB_DEVICE.maxPower = Maximum power
USB_DEVICE.interfaceClass = Interface class
USB_DEVICE.interfaceSubClass = Interface sub class
USB_DEVICE.interfaceProtocol = Interface protocol
USB_DEVICE.status = Status
MONITOR = Monitor
MONITOR.screenHeight = Screen height
MONITOR.screenWidth = Screen width
KEYBOARD = Keyboard
KEYBOARD.numberOfFunctionKeys = Number of function keys
POINTING_DEVICE = Pointing Device
POINTING_DEVICE.numberOfButtons = Number of buttons
PRINTER = Printer
PRINTER.horizontalResolution = Horizontal resolution
PRINTER.verticalResolution = Vertical resolution
PRINTER.capabilities = Capabilities
PRINTER.paperSizesSupported = Supported paper sizes
PRINTER.driverName = Driver name
PRINTER.port = Port
Examples for queries: Listing of all hard drives:

SELECT * FROM HARDWARE_DEVICE_HARDDISK_DRIVE D
LEFT OUTER JOIN HARDWARE_CONFIG_HARDDISK_DRIVE H ON D.hardware_id=H.hardware_id ;
The software inventory uses as primary keys the following entries:

Name
This is the windowsDisplayName or, if this entry isnt found at the registry, it is the windowsSoftwareId. Both values
come from the registry:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<id> DisplayName
Version
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<id> DisplayVersion
SubVersion
Language
Architecture (32 Bit / 64 Bit)
At the table Software_config these primary keys are integrated to one key: config_id.
data base schema: software inventory
Figure 85 data base schema: software inventory
23.3.2 mysql backend for configuration data
The backend mysql for configuration data is available since opsi 4.0 and is published as co funding project.
The backend mysql has a high performance which is important for large installations.
Here a data structure overview:
data base schema: configuration data
Figure 86 data base schema: configuration data

23.3.3 Initializing the MySQL-Backend
First, the mysql-server has to be installed (if not done yet):

apt-get install mysql-server
In the next step the administrative password for the mysql-server has to been set:
mysqladmin --user=root password linux123
The command
opsi-setup --configure-mysql
will now initialize the mysql backend.

A example session:
Figure 87 Dialog: opsi-setup --configure-mysql
Figure 88 Output: opsi-setup --configure-mysql
At all questions (beside the password) you may accept the defaults by pressing ENTER.
As next step you have to configure how (for which methods) opsi should use which backend. Therefore please edit the
file /etc/opsi/backendManager/dispatch.conf .
A detailed description for this configuration you will find at the getting started manual. The configuration file also
contains a lot of examples of typical configurations.
A configuration for the use of the backend mysql (without internal dhcpd) looks like that:
backend_.* : mysql, opsipxeconfd
host_.* : mysql, opsipxeconfd
productOnClient_.* : mysql, opsipxeconfd
configState_.* : mysql, opsipxeconfd
.* : mysql
Finally you have to activate the changed configuration with the following commands:
opsi-setup --set-rights
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart
23.3.4 Configure the mysql database for access from outside the server
# has to be written #
23.4 HostControl backend
The HostControl backend does not store any information. It is a special backend to control the opsi clients.
Typical tasks are to send Wake-On-Lan signals and send control signals to the opsi-client-agent.
The HostControl backend is configured by the configuration file /etc/opsi/backends/hostcontrol.conf. Configu-
ration options are here:
opsiclientdPort:
Network port to contact the opsi-client-agent.
hostRpcTimeout:
Timeout (in seconds) connecting a opsi-client-agent.
resolveHostAddress:
This option controls whether the name resolution of a opsi-client address is primary done by the opsi database or
by the name resolution of the operating system of the serveur opsi. If this option is True, the serveur opsi tries at
first to get the IP-Address of a opsi-client by the name resolution of the operating system (DNS, /etc/hosts) and if
this fails the opsi database is used. To use the opsi database at first, you have to set this option to False.
maxConnections:
Maximal number of concurrent connections to opsi-client-agents.
broadcastAddresses:
List of broadcast addresses used to send Wake-On-Lan broadcasts.
23.5 Conversion between different backends
The command opsi-convert converts the opsi configuration files from one backend to another. The target or the
source can be assigned in different ways:
backend name:
A backend on the current server can be addressed with just the backend name. The command opsi-convert file
mysql converts the data base of the current server from backend file to the backend mysql.
Service address
Providing a full qualified service address allows access to a remote servers data base (after passing the users pass-
word). The service address looks like: https://<username>@<ipadresse>:4447/rpc You will be asked for the pass-
words.
The conversion command looks like that:
opsi-convert -s -l /tmp/log https://uib@192.168.2.162:4447/rpc https://opsi@192.168.2.42:4447/rpc
Configuration directories
With a declaration of a configuration directory for the specified backend manager configuration source or target can
be described in detail.
opsi-convert --help
Usage: opsi-convert [options] <from> <to>

Convert an opsi database into an other.
Options:
-h show this help text
-V show version information
-q do not show progress
-v increase verbosity (can be used multiple times)
-c clean destination database before writing
-s use destination host as new server
-l <file> log to this file
<from> and <to> can be:

- the name of a backend as defined in /etc/opsi/backends (file, ldap, ...)
- the url of a opsi configuration service
http(s)://<user>@<host>:<port>/rpc
23.6 Boot files
/tftpboot/linux contains the boot files needed for the system start with the PXE boot proms.
23.7 Securing the shares with encrypted passwords
The opsi-client-agent accesses the shares provided by the serveur opsi to get the software which have to be installed
at the client.
The mount of these shares is done by using the user pcpatch. That these shares are not public and have to be mounted
using a password is important for: * general system security and data integrity * meet the license agreements of special
software packets
To give the client task opsi-client-agent access to authentication data, the server creates a specific key (opsi-host-key)
when creating a client. This key is stored (at the backend file) in the file /etc/opsi/pckeys and is passed to the PC
with the (re)installation request. The opsi-client-agent will store this key in the local file c:\program files\opsi.
org\opsi-client-agent\opsiclientd\opsiclientd.conf during system installation (access rights limited to the
administrators). Also, on the server, the file /etc/pckeys is only accessible by the user root and members of the group
opsiadmin. This way every PC has got an unique key only known to the client itself and the serveur opsi, not accessible
by client standard users. The key is used to encrypt the password of the user pcpatch. The encrypted password will be
transferred to the client at boot time via web service. Hence the servers pcpatch password can be changed any time.
The new encrypted password will be sent to every client at the next reboot.
24 Important files on the depot servers
24.1 Configuration files in /etc
24.1.1 /etc/hosts
The hosts file stores all IP addresses and IP names known to the network. The IP addresses and names of all clients
have to be entered here. There might be aliases (additional names) and comments (starting with #).
opsi needs full qualified host name (including the domain name) and this might come from the /etc/hosts as well
from the DNS.
Example:
192.168.2.106 dplaptop.uib.local dplaptop # this opsi-server
192.168.2.153 schleppi.uib.local
192.168.2.178 test_pc1.uib.local # Test-PC PXE-bootprom
With the following command you may test the name is resolved:
getent hosts $(hostname -f)
The result should be similar to:

192.168.1.1 server.domain.tld server
If the result isnt like that and contains for example 127.0.0.1 or localhost you should correct your /etc/hosts or
your DNS before you continue with the installation.
24.1.2 /etc/group
The required opsi groups are pcpatch and opsidamin. All users who are administrating opsi packets need to be member
of the pcpatch group. Membership of the group opsiadmin allows users to connect to the opsi web service (for instance
using the opsi-configed).
24.1.3 /etc/opsi/backends/
Configuration files for the used backends.
24.1.4 /etc/opsi/backendManager/
acl.conf
Configuration of the access control lists to the opsi methods.
dispatch.conf
Configuration which of the in /etc/opsi/backends/ configured backends should be used for which method.
extend.d/
Directory for backend extensions. For example this is be used to implement the old opsi 3 methods which are mapped
to the new opsi 4 methods.
24.1.5 /etc/opsi/hwaudit/*
Since opsi V3.2

Here the configuration files for the hardware inventory are to be found. The directory locales holds the language
specifications. The file opsihwaudit.conf specifies the mapping of WMI classes to the opsi data management.
24.1.6 /etc/opsi/modules
Since opsi 3.4

The opsi activation file.
This is by the uib gmbh signed file which is used to activate not free features of opsi. Any change on this file will
invalidate the activation. Without this file (or with a invalid file) you may only use the free feature of opsi.
24.1.7 /etc/opsi/opsiconfd.conf
Since opsi V3
Configuration file for the opsiconfd service including configurations like ports, interfaces, logging.
24.1.8 /etc/opsi/opsiconfd.pem
Since opsi version 3.0

Configuration file for the opsiconfd holding the ssl certificate.
24.1.9 /etc/opsi/opsipxeconfd.conf
Configuration file for the opsipxeconfd in charge for writing the start-up files for the Linux boot image. You can
configure directories, defaults and log level here.
24.1.10 /etc/opsi/opsi-product-updater.conf
Configuration file for the opsi-product-updater. See also Section 4.5
24.1.11 /etc/opsi/version
Holds the version number of the installed opsi.
24.1.12 /etc/init.d/
Start and stop scripts for: * opsi-atftpd * opsiconfd * opsipxeconfd
24.2 Boot files
24.2.1 Boot files in /tftpboot/linux
pxelinux.0
Boot file which will be loaded first by the PXE boot-prom.
install and miniroot.gz
Installation boot-image which will be loaded by the client (per tftp) during a re-installation.
24.2.2 Boot files in /tftpboot/linux/pxelinux.cfg
01-<mac adresse> or <IP-NUMMER-in-Hex>

Files named by the clients hardware address (prefix 01-) are stored on the serveur opsi as client-specific boot files.
Usually they are named pipes created by the opsipxeconfd as to initiate the (re)installation of clients.
default
The file default is loaded if no client-specific file is found. This initiates a local boot.
install
Information for the boot of the install boot image which will be used by the opsipxeconfd to create the named pipe.
24.3 Files in /var/lib/opsi
24.3.1 /var/lib/opsi/repository
This is the place where opsi-product-packages are saved, which are loaded by the calls of the opsi-product-updater
to the server.
This is also the place where opsi-product-packages are saved, which are installed by the calls of the opsi-package-
manager if it is called with the option -d.
24.3.2 /var/lib/opsi/depot
This directory is exported as read only Samba share opsi_depot. It is used at the Linux distribution SLES as depot
directory (instead of /opt/pcbin/install). At other distributions, you will find here a link to the directory /opt/
pcbin/install. In future you will find here also at other distributions the depot directory because this path is conform
to LSB.
24.3.3 /var/lib/opsi/ntfs-images
This directory holds (per default) the partition image files which are produced by the netboot product ntfs-write-image.
24.3.4 Other directories
The other directories in /var/lib/opsi (config and audit) are directories of the backend files, which are described
in the following chapters.
24.4 Files of the file backend
24.4.1 /etc/opsi/pckeys
In this file the opsi-host-keys, specified for each computer, are stored.
Example:
schleppi.uib.local:fdc2493ace4b372fd39dbba3fcd62182
laptop.uib.local:c397c280fc2d3db81d39b4a4329b5f65
pcbon13.uib.local:61149ef590469f765a1be6cfbacbf491
24.4.2 /etc/opsi/passwd
Here the passwords encrypted with the server key of the server (e.g. for pcpatch) are kept.
24.4.3 Overview /var/lib/opsi
The files of the file backend are in /var/lib/opsi, which is the home directory of the opsiconfd daemon. The following
schema gives an overview of the directory structure.
/var/lib/opsi-|
|-depot opsi_depot share
|-repository opsi package repository used by opsi-product-updater opsi-package-\
manager
|-audit inventory - files
!-config/-| config share
|-clientgroups.ini client groups
|-config.ini Host Parameter (Global Defaults)
|-clients/ <pcname.ini> files

|-products/ product control files
!-depots depot description files
+audit/
global.<Type> (generic hard-, and software information)
<FQDN>.<Type> (host specific hard-, and software information)
clientgroups.ini (hold the host groups)
+clients/
<FQDN>.ini (client configuration information)
config.ini (store the configs (host parameter))
+depots/
<FQDN>.ini (Information according to the depots)
+products/
<ID>_<ProdVer>-<PackVer>.<Type> (Information about the products)
+templates/
pcproto.ini (template for new clients)
<FQDN>.ini (specific templates (not implemented yet))
24.4.4 Configuration files in detail
./clientgroups.ini
This file holds information on the client groups.

[<GroupId>]
<HostId> = 1 #aktiv
<HostId> = 0 #inaktiv
./config.ini
This are the global defaults of the host parameter as shown in the server configuration in the opsi-configed.
./clients/<FQDN>.ini
In these files the client specific configuration is set. This information will be combined with the <depot-id>.ini values
whereas the settings from <FQDN>.ini overrides the <depot-id>.ini setting.
These files can have the following structure:
The section info contains all non product client information:
[info]
description = <String>
created = <Date> #format: YYYY-MM-DD HH:MM:SS
lastseen = <Date> #format: YYYY-MM-DD HH:MM:SS
inventorynumber = <String>
notes = <String>
hardwareaddress = <MAC> #format: hh:hh:hh:hh:hh:hh
ipaddress = <IP> #format: nnn.nnn.nnn.nnn
onetimepassword = <String>
The following section stores the installation state and the action request of a product. If there is no information here,
the default is not_installed:none.
[<Type>_product_states] #Local-, bzw. NetbootProduct
<ProductId> = <InstallationStatus>:<ActionRequest>
More information on products you will find at the product sections:

[<ProductId>-state]
producttype = <Type> #Local-, bzw. NetbootProduct
actionprogress = <String>
productversion = <ProdVer>
packageversion = <PackVer>
modificationtime = <Date> #format: YYYY-MM-DD HH:MM:SS
lastaction = <ActionRequest>
actionresult = <ActionResult>
targetconfiguration = <InstallationStatus>
/var/lib/opsi/config/templates
In this directory are the template files like pcproto.ini, which is the standard template for creating a new <FQDN>.
ini file. It has the same internal structure as the <FQDN>.ini file.
/var/lib/opsi/config/depots/
Here are the depot specific data storage which are also stored as <depot-id>.ini. Here you find general information
about about the the depot.
[depotshare]
remoteurl = smb://<NetBiosName>/<Path>
localurl = file://<Path>
[depotserver]
notes = <String>
network = <IP>
description = <String>
hardwareaddress = <MAC>
ipaddress = <IP>
inventorynumber = <String>
[repository]
remoteurl = webdavs://<FQDN>:<Port>/<Path>
localurl = file://<Path>
maxbandwith = <Integer> #in Bytes
You will find also information which opsi product is installed at the depot in which version and with which property
defaults.
Product control files in /var/lib/opsi/config/products/
This directory contains the product meta data, which is the product name, properties, default values and dependencies.
The control files are the kind of control files, that are generated by creating new opsi-products in the directory <product
name>/OPSI/control.
The control files have the following sections:
Section [Package]
Description of the package version and whether this is an incremental package.
Section [Product]
Description of the product
Section(s) [ProductProperty]
(optional)
Description of variable product properties
Section(s) [ProductDependency]
(optional)
Description of product dependencies
Example:
[Package]
version: 1
depends:
incremental: False
[Product]
type: localboot
id: thunderbird
name: Mozilla Thunderbird
description: Mail client by Mozilla.org
advice:
version: 2.0.0.4
priority: 0
licenseRequired: False
productClasses: Mailclient
setupScript: thunderbird.ins
uninstallScript:
updateScript:
alwaysScript:
onceScript:
[ProductProperty]
name: enigmail
description: Install encryption plug-in for GnuPG
values: on, off
default: off
[ProductDependency]
action: setup
requiredProduct: mshotfix
requiredStatus: installed
requirementType: before
[Package]-Version
is for different package versions from the same product version. This helps to distinguish packages build from the
same product version but with different opsi-winst script for instance.
[Package]-depends
refers to the base package of an incremental package.
[Package]-Incremental
specifies whether this is an incremental package.
[Product]-type
marks the product type as localboot or netboot.
[Product]-Id
is the general name of that product (like firefox), independent from the product version.
[Product]-name
is the full name of the product.
[Product]-Description
is an additional description for the product as shown in the opsi-configed as Description.
[Product]-Advice
is an additional hint for handling the product (caveats etc.) as to be shown in the opsi-configed as Note.
[Product]-version
is the version of the original software.
[Product]-Priority
affects (in combination with the product dependencies) the installation sequence.
[Product]-productClasses
is for future use.
[ProductProperty]-type
Type of the property: (unicode/boolean)
[ProductProperty]-name:
Name of the property.
[ProductProperty]- multivalue
May this property contain a list of values (True/False)
[ProductProperty]- editable
Is this property free editable or may the user only select on of the values (True/False)
[ProductProperty]-description:
Description of a property (Tool-tip in the opsi-configed).
[ProductProperty]-values :
List of allowed values.
[ProductProperty]-default :
Default value of the property.
[ProductDependency]-Action :
To which product action this dependency entry belongs (setup, uninstall . . . ).
[ProductDependency]-Requiredproduct:
Product ID of the product to that a dependency exists.
[ProductDependency]-Required action:
The required action of the product, which the dependency entry refers to. Actions could be setup, uninstall, update. . .
[ProductDependency]-Required installation status:
The required status of the product, which the dependency entry refers to. Typically this is installed, which results
in setting this dependency product to setup, if it isnt installed on the client yet.
[ProductDependency]-Requirement type:
this is regarding the installation order. If the product, which the dependency entry refers to, has to be installed
before the actual product installation starts, the Requirement type must be before. If the dependency product has to
be (re-)installed after the actual product, the Requirement type is set to after. If there is no entry, the installation
order is of no relevance.
24.4.5 Inventory data /var/lib/opsi/audit
Here you find the inventory data for hardware (.hw) and software (.sw).
24.5 Files of the LDAP backend
The opsi-LDAP schema is located at /etc/ldap/schema/opsi.schema.
24.6 opsi programs and libraries
24.6.1 Python library
The opsi python modules are located at:

Debian Lenny
/usr/share/python-support/python-opsi
/usr/share/python-support/opsiconfd
Ubuntu Lucid
/usr/share/pyshared/python-opsi
/usr/share/pyshared/opsiconfd
24.6.2 Programs in /usr/bin
opsipxeconfd
opsi daemon to administrate the files required for the PXE boot of the clients.
opsi-admin
Starts the command line interface for the opsi python library
opsiconfd
opsi daemon which is the central opsi configuration daemon.
opsiconfd-guard
opsi daemon which monitors if the opsiconfd is running and restarts the opsiconfd if it isnt running.
opsi-configed
Command to start the opsi management interface
opsi-convert
Script for converting between different backends.
opsi-makeproductfile
Script for packing the opsi-package (opsi-product)
opsi-newprod
Script for creating the structure and meta data files of a new opsi product
Script to unpack, install, remove, list opsi packages on one ore more servers (and a lot more).
opsi-setup
opsi configuration utility
24.7 opsi log files
The opsi log files have the following format:

[Loglevel] Timestamp Message
The log levels are:
0 = nothing (absolute nothing)
1 = essential ("we always need to know")
2 = critical (unexpected errors that my cause a program abort)
3 = error (Errors that dont will abort the running program)
4 = warning (you should have a look at this)
5 = notice (Important statements to the program flow)
6 = info (Additional Infos)
7 = debug (important debug messages)
8 = debug2 (a lot more debug information and data)
9 = confidential (passwords and other security relevant data)
24.7.1 /var/log/opsi/bootimage
In this directory are the log-files of the opsi-linux-bootimage. These log files will be named log.<IP-number>.
If the opsi-linux-bootimage couldnt connect the web-service, you will find the logs in /tmp/log at the bootimage. In
such case, there are two possible ways to get the log file:
1. You have a network connection to the client
You may use scp (winscp) to copy the log file from the running boot-image to your computer (login as root with
password linux123).
2. You have no network connection to the client
You have to use a USB stick.
Login as root with the password linux123
Connect USB stick to the client and wait some seconds
use the command sfdisk -l to check on which device you will find your stick
mount
copy
umount
A example session:
#sfdisk -l
Disk /dev/sda: 30401 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System

/dev/sda1 * 0+ 30401- 30402- 244197528+ 7 HPFS/NTFS
/dev/sda2 0 - 0 0 0 Empty
Disk /dev/sdb: 1017 cylinders, 33 heads, 61 sectors/track

Units = cylinders of 1030656 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System

/dev/sdb1 0+ 1016 1017- 1023580 b W95 FAT32
/dev/sdb2 0 - 0 0 0 Empty
# mount /dev/sdb1 /mnt
# cp /tmp/log /mnt
#umount /mnt
24.7.2 /var/log/opsi/clientconnect
In this directory are the log-files of the opsi-client-agent running on the client.
The client log files will be named <client FQDN>.log. On the client you will find this file at c:\tmp\opsiclientd.
log.
24.7.3 /var/log/opsi/instlog
In this directory are the log-files of the opsi-winst running on the client. The client log files will be named <client
FQDN>.log. On the client you will find this file at c:\tmp\instlog.txt
24.7.4 /var/log/opsi/opsiconfd
In this directory are the log-files of the opsiconfd and the clients.
The client log files will be named log.<IP-number> and (if available) a symbolic link named <IP-Name>.log to log.
<IP-number> is created.
24.7.5 /var/log/opsi/opsipxeconfd.log
Log file the opsipxeconfd

that administrates the tftp files for the PXE boot of the clients.
24.7.6 /var/log/opsi/package.log
Log file of the opsi-package-manager.

24.7.7 /var/log/opsi/opsi-product-updater.log
Log file of the opsi-product-updater.
24.7.8 tftp log in /var/log/syslog
The log of the tftpd you will find at /var/log/syslog.

You should increase the log level to see important information.
At the file /etc/inetd.conf in the line starting with tftpd set the parameter verbose to 7 :
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --\
mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=7 /tftpboot
If this is done execute:

killall tftpd
killall -1 inetd
24.7.9 c:\tmp\opsiloginblocker.txt
Log file of the opsi-login-blocker
24.7.10 c:\tmp\opsiclientd.log
Log file of the opsiclientd

This file is copied at the end of a event to server at /var/log/opsi/clientconnect/<pc-ipnummer.log>.
24.7.11 c:\tmp\instlog.txt
Log file of the opsi-winst.

This file is copied at the end of a installation to server at /var/log/opsi/instlog/<pc-ipnummer.log>.
25 Registry Entries
25.1 Registry entries for the opsiclientd
25.1.1 opsi.org/general
bootmode=<bkstd | reins>
Stores the information whether the client is new installed or not.
25.1.2 opsi.org/opsi-client-agent and opsi.org/preloginloader
These both keys should be identical but the second one is deprecated and exists for backward
compatibility. Schlssel [HKEY_LOCAL_MACHINE\SOFTWARE\opsi.org\opsi-client-agent] Schlssel
[HKEY_LOCAL_MACHINE\SOFTWARE\opsi.org\preloginloader]
"RemoveMsginaOnDeinst"=dword:00000001
on uninstall restore the default login handler
"WinstRegKey"="SOFTWARE\\opsi.org\\winst"
where to look for opsi-winst registry reboot requests

"LoginBlockerStart"=dword:00000001
opsigina waits for READY from the named pipe
(if set to 0, the user is allowed to logon during software installation)
"LoginBlockerTimeoutConnect"=dword:00000005
Timeout in minutes for pipe-connect
"LoginBlockerLogLevel"=reg_dword:006
Log level of the loginblocker
"OpsiServiceType"=dword:00000002
Should opsigina connect to prelogin (1) or opsiclientd (2)
"NextGina"="msgina.dll"
The next gina.dll in the gina chain
25.1.3 opsi.org/shareinfo
depoturl
<URL for installation packets>
depoturl pattern: <protocol:\\server\share\dir>
Example:
smb:\\schleppi\opsi_depot
depotdrive
drive letter the depoturl will be mounted to
Example: P: (including the colon)
25.2 Registry entries of the opsi-winst
25.2.1 opsi.org/winst
This registry entries are controlled by opsi-winst and should not be edited.
"LastLogFilename"="C:\\TMP\\syslogin.log"
"ContinueLogFile"=dword:00000000
"RebootRequested"=dword:00000000
"SendLogToService"=dword:00000001
"NumberOfErrors"=dword:00000000
"ShutdownRequested"=dword:00000000
25.2.2 Controlling the logging via syslog protocol
The relevant registry section is [HKLM\Software\opsi.org\syslogd] the value of RemoteErrorLogging (DWORD) is

evaluated:
RemoteErrorLogging =(0=trel_none, 1=trel_filesystem, 2=trel_syslog)
If logging is set to syslog protocol ("remoteerrorlogging"=dword:00000002), the string variable sysloghost gives the
IP-name of the LogHost.
The DWORD variable syslogfacility defines the source of the syslog messages (default is
ID_SYSLOG_FACILITY_LOCAL0).
The logging source can be:
ID_SYSLOG_FACILITY_KERNEL = 0; // kernel messages

ID_SYSLOG_FACILITY_USER = 1; // user-level messages
ID_SYSLOG_FACILITY_MAIL = 2; // mail system
ID_SYSLOG_FACILITY_SYS_DAEMON = 3; // system daemons
ID_SYSLOG_FACILITY_SECURITY1 = 4; // security/authorization messages (1)
ID_SYSLOG_FACILITY_INTERNAL = 5; // messages generated internally by syslogd
ID_SYSLOG_FACILITY_LPR = 6; // line printer subsystem
ID_SYSLOG_FACILITY_NNTP = 7; // network news subsystem
ID_SYSLOG_FACILITY_UUCP = 8; // UUCP subsystem
ID_SYSLOG_FACILITY_CLOCK1 = 9; // clock daemon (1)
ID_SYSLOG_FACILITY_SECURITY2 = 10; // security/authorization messages (2)
ID_SYSLOG_FACILITY_FTP = 11; // FTP daemon
ID_SYSLOG_FACILITY_NTP = 12; // NTP subsystem
ID_SYSLOG_FACILITY_AUDIT = 13; // log audit
ID_SYSLOG_FACILITY_ALERT = 14; // log alert
ID_SYSLOG_FACILITY_CLOCK2 = 15; // clock daemon (2)
ID_SYSLOG_FACILITY_LOCAL0 = 16; // local use 0 (local0)
26 Upgrade of a serveur opsi
Please refer to the special releasenotes-upgrade manuals.
27 opsi localization
Get your localization code:

http://www.gnu.org/software/gettext/manual/html_node/Usual-Language-Codes.html
Example:
en
English
de
German
fr
French
it
Italian
da
Danish
27.1 Using existing localizations
opsi has localizations for:

English
German
French
Italian
Danish
If it is possible for a localized part of opsi to detect what is your standard language it will switch automatically. If ths
is not possible in most cases English is the fallback language and in some cases still German.
Some Parts of opsi have no chance to detect the language to use, so you have to help a little:
Bootimage: Edit on your Server the file /tftpboot/linux/pxelinux.cfg/install. Append to the append line
lang=<code> for example lang=fr.
27.2 Creating or changing localizations
We are always very happy if you like to make a new localization or correct a existing. Here some hints how to start.
27.2.1 PO files
Many localizations are done in the standard GNU *.po files.

You may use the poedit application for editing for editing: http://download.uib.de/opsi4.0/products/contribute/full-
package/poedit_1.4.6-1.opsi or http://www.poedit.net/
27.2.2 PO files: opsi-winst
You will find the po files for the opsi-winst here:

opsi-winst: at svn.opsi.org repo: opsi-winst branches/4.11.3/languages:
https://svn.opsi.org/listing.php?repname=opsi-winst&path=%2Fbranches%2F4.11.3%2Flanguages%2F&#a0658e5e6a7e3d7
A modified new opsi-winst.po you may test by just store it in the opsi-winst\languages directory.
27.2.3 PO files: opsiclientd
You will find the po files for the opsiclientd here:

https://svn.opsi.org/listing.php?repname=opsiclientd&path=%2Ftrunk%2Fgettext%2F&#a4c4f8177ba88910762266205d816
27.2.4 PO files: python-opsi
You will find the po files for the python-opsi here:

https://svn.opsi.org/listing.php?repname=python-opsi&path=%2Ftrunk%2Fgettext%2F&#a4c4f8177ba88910762266205d81
27.2.5 PO files: opsi-utils
You will find the po files for the opsi-utils here:

https://svn.opsi.org/listing.php?repname=opsi-utils&path=%2Ftrunk%2Fgettext%2F&#a4c4f8177ba88910762266205d8169
27.2.6 PO files: opsi-bootimage
You will find the po files for the opsi-bootimage here:

Until we published the opsi-bootimage code at our svn, just send a mail to our localization contact mentioned at thend
of this chapter.
27.3 configed
You will find the po files for the opsi-configed here:

opsi-configed (stable): at svn.opsi.org repo: opsi-configed/trunk/classes/de/uib/messages
https://svn.opsi.org/listing.php?repname=opsi-configed&path=%2Ftrunk%2Fsrc%2Fde%2Fuib%2Fmessages%2F&#a07717
The latest (unstable) version you will find at our experimental repositories. For example:
http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40-experimental/Debian_6.0/all/opsi-
configed_4.0.2.2-1_all.deb
If you unzip configed.jar you find the translation files in de/uib/messages. There you can replace the file, pack (zip)
again the archive and retry the program.
You have to modify the valid_translations.conf and add a new configed_da.properties and a da.png
Since we introduced some signing mechanisms the procedure to get a new working configed.jar has become a little bit
more complicated.
One option that your really check out the configed code from svn.opsi.org (where you will find the last stable version),
add a configed_da.properties, a da.png and a new valid_localisations.conf (as you provided). Then you may use the
bash scripts compile.sh plus sign_jars.sh to produce new signed configed.jar and swingx.jar files. You may put the
jars to /usr/lib/configed in order to see it in browser (after reopening the browser).
It is also possible just to put the additional needed files to a unpacked configed.jar, but then you have to rebuild it
with the java packager jar. Since it is not signed it cannot be used via the browser.
So you may directly have a look at the result of your work.
27.4 opsiclientd.conf
One part will be the localization of the message entries of the opsiclientd.conf like for example:
# Message shown in the action notifier window (string)
action_message = Starting to process product actions. You are allowed to
cancel this event a total of %action_user_cancelable% time(s). The event
was already canceled %state.action_processing_cancel_counter% time(s).
action_message[de] = Starte die Bearbeitung von Produkt-Aktionen. Sie
knnen diese Aktion insgesamt %action_user_cancelable% mal abbrechen.
Die Aktion wurde bereits %state.action_processing_cancel_counter% mal
abgebrochen.
You will find the opsiclientd.conf here:
https://svn.opsi.org/filedetails.php?repname=opsiclientd&path=%2Ftrunk%2Fsrc%2Fwindows%2Fopsiclientd.conf
27.5 Localization contact
Please send any questions, hints or localization files to: locales@uib.de

Opsi Manual PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Opsi Manual PDF

Uploaded by

Copyright:

Available Formats

opsi manual opsi version 4.0.

Table des matires

3 Vue densemble dopsi 2

4 configuration de opsi et outils 3

4.3.14 Journaux systme: Journaux du client et du serveur . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Service web / mthodes de lAPI 22

auditSoftwareToLicensePool (gestion des licences) . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Activation des modules non libres 43

8 Produits Localboot: distribution de logiciels automatique avec opsi 63

14 opsi license management 91

15 opsi WAN/VPN extension 100

16 opsi-server with multiple depots 107

17 Dynamic Depot Assignment 109

18 opsi Software On Demand (Kiosk-Mode) 115

19 opsi extension Roaming Profile Support 119

21 Installation dopsi lors de larrt 146

22 La fonctionnalit opsi SilentInstall 151

23 opsi data storage (backends) 154

24 Important files on the depot servers 161

24.3.3 /var/lib/opsi/ntfs-images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

25 Registry Entries 171

26 Upgrade of a serveur opsi 173

27 opsi localization 173

Vous trouverez ici la description allemande:

2.1 Qui devrait lire ce manuel?

3 Vue densemble dopsi

3.2 fonctionnalits dopsi

Les principaux lments de opsi sont :

3.3 Extensions opsi

Gestion des licences

4 configuration de opsi et outils

Figure 1 Schema: opsi avec le backend de fichier

Schema: opsi avec le backend SQL / LDAP

Figure 2 Schema: opsi avec le backend SQL / LDAP

Vous trouverez plus de dtails dans

Schema: couches backend et contrle daccs

Figure 3 Schema: couches backend et contrle daccs

Le rpertoire de opsi 3 /etc/opsi/backendManager.d nest plus utilis dans opsi 4.

4.2 Outil: opsi-setup

Usage: opsi-setup [options]

--log-file <path> path to log file

Les fonctions et les options en dtail:

Dialog: opsi-setup --edit-config-defaults

Figure 4 Dialog: opsi-setup --edit-config-defaults

4.3 Outil: Management Interface: opsi-configed

4.3.1 Exigences et fonctionnement

opsi-configed ncessite Java 1.6 et un opsiconfd en excution sur le serveur.

devrait aboutir la sortie suivante:

opsi-configed: login mask

Figure 5 opsi-configed: masque de connexion

4.3.3 Copier-Coller, Glisser-Dposer

4.3.4 Configuration du client / configuration du serveur / gestion des licences

4.3.5 Slection dpt

opsi-configed: depot selection

Figure 7 opsi-configed: slection dpt

4.3.6 Slection des clients unique et configuration de groupe

opsi-configed: client selection mask

Figure 8 opsi-configed: masque de slection des clients

opsi-configed: Client search

Figure 9 opsi-configed: Fonction de recherche dans la liste de slection des clients

La liste des clients

Figure 10 opsi-configed: Bouton Vrifiez quels clients sont connects

IP address indique le numro IP laquelle le serveur OPSI rsout le nom du client.