Documente Academic
Documente Profesional
Documente Cultură
Revision: 13.02.2013
OpenSides sprl
Rue des Palais 44, bte 33
1030 Brussels
Tel.:+32 2 880 97 40
www.opensides.be
opsi@opensides.be
2 Introduction
2.1
2.2
Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Exprience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
fonctionnalits dopsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Extensions opsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
Aperu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Outil: opsi-setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1
Exigences et fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2
Connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3
Copier-Coller, Glisser-Dposer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4
4.3.5
Slection dpt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6
10
10
Comment faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
11
12
12
12
Appel des outils externes de contrle distance pour des clients slectionns . . . . . . . . . .
12
13
13
14
15
15
16
16
4.3.7
4.3.8
4.3.9
ii
16
16
17
4.4
18
4.5
Outil: opsi-product-updater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.5.1
Dpts paramtrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.5.2
Actions paramtrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
20
4.6.1
Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.6.2
21
4.6
Dfinissez un produit pour la configuration (setup) pour tous les clients qui ont install ce produit 21
4.7
21
Supprimer un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Crer un client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
21
21
22
22
4.7.1
22
22
22
5.1.1
Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.1.2
24
24
25
26
26
27
28
28
29
30
30
30
. . . . . . . . . . . . . . . . .
32
33
34
iii
. . . . . . . . . . . . . . . . . . . . . . . . .
34
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
36
36
36
5.2
36
5.3
43
5.1.3
43
7 opsi-client-agent
44
7.1
Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
7.2
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
51
52
57
7.3.7
Journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
7.3.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.3.9
61
61
62
62
63
7.4.1
63
7.4.2
63
63
7.5.1
63
7.4
7.5
8.2
8.3
iv
63
63
8.1.1
opsi-client-agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
8.1.2
opsi-winst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
8.1.3
64
8.1.4
opsi-adminutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.1.5
jedit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.1.6
64
8.1.7
opsi-template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.1.8
xpconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
64
8.2.1
66
8.2.2
66
8.2.3
66
66
9 Produits Netboot
67
9.1
67
9.2
67
9.2.1
Aperu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
9.2.2
Conditions pralables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
9.2.3
68
9.2.4
Chargement de pxelinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
9.2.5
Dmarrer partir du CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
9.2.6
70
9.2.7
72
9.2.8
72
9.2.9
73
73
9.3
Quelques conseils sur les produits netboot NT6 (Vista / Win7 / 2008) . . . . . . . . . . . . . . . . . .
73
9.4
76
9.5
memtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.6
hwinvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
9.7
wipedisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
10 Inventaire
77
77
79
11 Serveur opsi
80
11.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
80
80
80
80
81
81
12 La scurit
82
12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
82
82
83
83
83
84
84
85
85
86
13 Sauvegarde dopsi
86
13.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
86
86
87
87
87
87
87
88
88
88
90
90
90
. . . . . . . . . . . . . . . . . . . . . . . . . .
vi
91
14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
91
92
92
92
92
92
93
93
. . . . . . . . . . . . . . . . . . . . . . . . . . .
93
94
94
95
95
95
96
96
96
97
97
97
98
98
98
98
100
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
. . . . . . . . . . . . . . . . . . . . . . . . . . 106
vii
107
109
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
115
119
viii
20 Connecteur-opsi-Nagios
127
. . . . . . . . . . . . . . . . . . . . . . . . . 143
146
ix
151
154
161
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
171
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
. . . . . . . . . . . . . . . . . . . . . . . 171
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
xi
173
27 opsi localization
173
1 / 175
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).
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
2.1
Introduction
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
2 / 175
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-depotshare>/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
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
3.3
3 / 175
Extensions opsi
4
4.1
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
4 / 175
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
-l
--log-file <path>
--ip-address <ip>
--register-depot
--set-rights [path]
--init-current-config
--update-mysql
--update-ldap
--update-file
--configure-mysql
--edit-config-defaults
--cleanup-backend
--auto-configure-samba
--auto-configure-dhcpd
/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
5 / 175
--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
4.3.1
La commande
6 / 175
java -version
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,
-h,
-u,
-p,
-d,
4.3.2
--locale
Set locale (format: <language>_<country>)
--host
Configuration server to connect to
--user
Username for authentication
--password Password for authentication
--logdirectory Directory for the log files
--help
Show this text
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
7 / 175
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
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
8 / 175
9 / 175
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.
10 / 175
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.
11 / 175
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
12 / 175
13 / 175
Attention
Si le client a reu le signal, il steindra sans plus de questions.
14 / 175
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
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 dinstallation 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
15 / 175
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
16 / 175
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
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).
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).
17 / 175
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.).
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
18 / 175
Installer un paquet (et le commutateur daction ncessaires, pour la configuration, lorsquil est install):
opsi-package-manager -S -i softprod_1.0-5.opsi
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
-u, --upload
-l, --list
-D, --differences
-r, --remove
-x, --extract
-V, --version
-h, --help
Options:
-v, --verbose
-q, --quiet
--log-file
-d, --depots
-p, --properties
<opsi-package> ...
<opsi-package> ...
<regex>
<regex>
<opsi-product-id> ...
<opsi-package> ...
<log-file>
<depots>
<mode>
--purge-client-properties
-f, --force
-U, --update
-S, --setup
-o, --overwrite
-k, --keep-files
-t, --temp-dir
--max-transfers
<path>
<num>
--max-bandwidth
<kbps>
--new-product-id
<product-id>
4.5
19 / 175
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 maintenir 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
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-productupdater le opsi-product-packages sera rcupr depuis opsi-configserver. Cela peut tre fait par exemple par une tche
cron.
4.5.2
20 / 175
Actions paramtrables
4.6
4.6.1
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
21 / 175
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
Dfinissez un produit pour la configuration (setup) pour tous les clients qui ont install ce produit
opsi-admin -d task setupWhereInstalled "softprod"
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"
par exemple:
opsi-admin -d method setProductActionRequest win7 pxevm setup
22 / 175
Dfini le mot de passe de lutilisateur pcpatch pour le compte Unix, samba et opsi.
4.7
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
Utilisation de ladresse web https://<opsi-server>:4447/info vous obtiendrez un graphique de la charge et de lutilisation 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
5.1
5.1.1
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"
23 / 175
"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 obtiendrez:
"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,
24 / 175
"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
25 / 175
"description" : "sub2",
"notes" : "",
"parentGroupId" : null,
"type" : "HostGroup",
"id" : "sub2"
},
{
"ident" : "subsub",
"description" : "subsub",
"notes" : "",
"parentGroupId" : "sub2",
"type" : "HostGroup",
"id" : "subsub"
}
]
26 / 175
"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.
27 / 175
28 / 175
Note
Les valeurs par dfaut relles sont stockes dans le contexte du dpt dans un objet productPropertyState.
Note
Si vous avez des serveurs de dpt multiple, vous pouvez avoir des versions diffrentes dun mme produit.
29 / 175
30 / 175
Note
Un objet configState ne peut tre cr sans objet un existant config auquel il fait rfrence.
{
"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"
},
{
"vendorId" : "1022",
"macAddress" : "00:0C:29:35:70:A7",
"hardwareClass" : "NETWORK_CONTROLLER",
"state" : 0,
"deviceType" : "PCI",
"subsystemVendorId" : "2000",
"ipEnabled" : "True",
"type" : "AuditHardwareOnHost",
"firstseen" : "2012-03-08 14:26:14",
"revision" : "10",
"hostId" : "xpclient.vmnat.local",
"vendor" : "VMware, Inc.",
"description" : "VMware Accelerated AMD PCNet Adapter",
"subsystemDeviceId" : "1022",
"deviceId" : "2000",
"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"
},
{
"vendorId" : "1022",
"macAddress" : "00:0c:29:35:70:a7",
"hardwareClass" : "NETWORK_CONTROLLER",
"state" : 0,
"deviceType" : null,
"subsystemVendorId" : "1022",
"ipEnabled" : null,
"type" : "AuditHardwareOnHost",
"firstseen" : "2012-02-29 15:43:21",
"revision" : "10",
"hostId" : "xpclient.vmnat.local",
"vendor" : "Advanced Micro Devices [AMD]",
"description" : "Ethernet interface",
"subsystemDeviceId" : "2000",
"deviceId" : "2000",
31 / 175
32 / 175
"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" : ""
}
]
33 / 175
"model" : null,
"revision" : "10",
"type" : "AuditHardware",
"hardwareClass" : "NETWORK_CONTROLLER",
"adapterType" : "Ethernet 802.3",
"description" : "Ethernetadapter der AMD-PCNET-Familie"
},
{
"vendorId" : "1022",
"deviceId" : "2000",
"maxSpeed" : null,
"vendor" : "Advanced Micro Devices (AMD)",
"name" : "Ethernetadapter der AMD-PCNET-Familie",
"subsystemDeviceId" : "1022",
"deviceType" : "PCI",
"subsystemVendorId" : "2000",
"autoSense" : null,
"model" : null,
"revision" : "10",
"type" : "AuditHardware",
"hardwareClass" : "NETWORK_CONTROLLER",
"adapterType" : "Ethernet 802.3",
"description" : "Ethernetadapter der AMD-PCNET-Familie"
},
{
"vendorId" : "1022",
"deviceId" : "2000",
"maxSpeed" : null,
"vendor" : "Advanced Micro Devices (AMD)",
"name" : null,
"subsystemDeviceId" : "2000",
"deviceType" : "PCI",
"subsystemVendorId" : "1022",
"autoSense" : null,
"model" : "",
"revision" : null,
"type" : "AuditHardware",
"hardwareClass" : "NETWORK_CONTROLLER",
"adapterType" : null,
"description" : "Ethernetadapter der AMD-PCNET-Familie"
},
(....)
[
34 / 175
35 / 175
36 / 175
"type" : "LicenseContract",
"id" : "msdn-uib"
}
]
5.1.3
Note
Ce chapitre doit tre crit
5.2
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 lorientation 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.
37 / 175
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
Test du backend pour la cohrence ( prsent uniquement disponible pour les fichiers backend).
method createClient clientName, domain, description=None, notes=None
38 / 175
Supprime un client.
method deleteGeneralConfig objectId
Supprime la configuration rseau (Par exemple lentre dpt de partage) pour un client ou un domaine.
method deleteOpsiHostKey hostId
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.
39 / 175
method getBootimages_list
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 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
40 / 175
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 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 pour tous les clients ltat de linstallation et la requte daction de tous les produits netBoot.
method getNetworkConfig_hash objectId
Fournit les actions disponibles pour chaque produit (setup, deinstall , . . . .).
method getPossibleProductActions_list productId=softprod
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
41 / 175
42 / 175
43 / 175
Dfinir les proprits de produit pour le produit spcifi (et le client spcifi).
method unsetBootimage hostId
5.3
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.
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
44 / 175
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
7.1
opsi-client-agent
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-productpackage. 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
45 / 175
Ce rpertoire contient tous les programmes de opsi-client-agent comme par exemple opsiclientd, opsiclientd notifier, 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 utilisateurs 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.
46 / 175
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.
47 / 175
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 didentification (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.
48 / 175
49 / 175
(Section 7.3.8).
50 / 175
7.3.6
51 / 175
Configuration
52 / 175
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
53 / 175
54 / 175
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)
55 / 175
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
56 / 175
57 / 175
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
shutdown_warning_time = 300
[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
action_processor_timeout = 300
[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
58 / 175
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"
59 / 175
Journalisation
Exemple:
(...)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
generator sync_completed
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
gui_startup
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
generator gui_startup
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
to event generator sync_completed
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
generator gui_startup
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
sync_completed
(Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup ] Event
software_on_demand
(Events.pyo|1107)
60 / 175
[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)
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
61 / 175
Figure 47 Page dinformation de opsiclientd aprs linstallation pousse avec le cache activ du produit
7.3.9
opsiclientd possde sa propre interface de service Web qui peut tre utilis pour transmettre des commandes opsiclientd. 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"
62 / 175
Exemple:
opsi-admin -d method hostControl_fireEvent "on_demand" "myclient.uib.local"
redmarrage:
opsi-admin -d method hostControl_reboot *hostIds
7.4
63 / 175
Pour viter une connexion de lutilisateur avant que toutes les installations sont termines, opsi fournit loption opsilogin-blocker.
7.4.1
opsi-login-blocker est implment comme Gina opsigina.dll. Gina signifie Graphical Identification and Authentication 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-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
Les informations sur une Installation ultrieure de opsi-client-agent vous les trouverez dans le manuel opsi-gettingstarted (Chapitre Premires tapes).
7.5.1
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
Les produits suivants sont des produits de base qui viennent avec linstallation de opsi-server.
8.1.1
opsi-client-agent
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
64 / 175
Le paquet javavm installe lenvironnement dexcution Java 1.6 requis par opsi-configed) sur les clients.
8.1.4
opsi-adminutils
jedit
Les paquets hwaudit et swaudit ils fournissent linventaire matriel et logiciel. Les donnes 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
8.1.8
xpconfig
Paquet pour personnaliser les paramtres de linterface graphique et dExplorer (et pas seulement) pour Windows XP.
8.2
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
65 / 175
66 / 175
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
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
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
Les informations sur "Lintgration des nouveaux paquets logiciels dans le dploiement de logiciels opsi" vous les
trouverez dans le manuel opsi-getting-started.
67 / 175
Produits Netboot
9.1
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 supplmentaires 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>
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
9.2.1
68 / 175
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
Le microprogramme PXE sactive au dmarrage de lordinateur. Une partie de la mise en uvre PXE est un client
DHCP.
69 / 175
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-0c29-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.
70 / 175
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 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.
71 / 175
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
72 / 175
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
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
73 / 175
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
Vous trouverez les informations sur la Structure des produits dinstallation sans assistance dans le manuel opsi-gettingstarted.
9.2.10
Vous trouverez les informations sur la Intgration simplifie des pilotes avec liens symboliques dans le manuel opsigetting-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.
74 / 175
75 / 175
76 / 175
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.
9.4
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
9.6
hwinvent
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
77 / 175
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 "COMPUTER_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>.
78 / 175
"Scope":
"Opsi":
"WMI":
"Linux":
"i",
"systemType",
"SystemType",
"configuration/chassis"
"Type":
"Scope":
"Opsi":
"WMI":
"Linux":
"Unit":
"bigint",
"i",
"totalPhysicalMemory",
"TotalPhysicalMemory",
"core/memory/size",
"Byte"
79 / 175
},
{
},
{
"Type":
"varchar(50)",
"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 "TotalPhysicalMemory". 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
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
11.1
80 / 175
Serveur opsi
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 dinstallation 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
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
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
81 / 175
11.7
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
82 / 175
ou
service nmbd restart
service smbd restart
12
12.1
La scurit
Introduction
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
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
83 / 175
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
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
Depuis opsi 4.0.1 il existe diffrentes possibilits de vrifier la fiabilit du serveur contact.
84 / 175
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:
85 / 175
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
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
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 opsiconfd 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
12.9
86 / 175
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
13.1
Sauvegarde dopsi
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
13.3
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
87 / 175
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 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
file-Backend
mysql-Backend
ldap
univention
dhcp
Description
backend bas sur les fichiers (backend par dfaut)
backend bas sur MySQL (depuis opsi 4 pour toutes
les donnes de configuration)
Stocker les donnes de configuration dans lannuaire
ldap
backend LDAP spcial pour les serveurs dentreprise
Univention
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
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 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.
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.5
88 / 175
dpt opsi
Le rpertoire /var/lib/opsi/repository est utilis pour stocker les paquets opsi, qui sont tlchargs via opsiproduct-updater ou qui sont installs par opsi-package-manager lorsque vous utilisez loption -d.
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.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
positional arguments:
destination
89 / 175
optional arguments:
-h, --help
--flush-logs
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/
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
--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.
90 / 175
Exemple
opsi-backup create --no-configuration --backends=all opsi_backup.tar.bz2
13.5.2
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
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
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
optional arguments:
-h, --help
show this help message and exit
--backends {file,mysql,dhcp,auto,all}
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)
91 / 175
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
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
92 / 175
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
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
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
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 opsiproducts requesting licenses from the same license pools (e.g. the Acrobat Writer license pool). So the relation between
93 / 175
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 opsiproducts).
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
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 (ctrlclick 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
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.
94 / 175
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
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
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
95 / 175
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
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
96 / 175
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
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
14.5.3
97 / 175
License contracts
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 parameters 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.
set $mykey$ = DemandLicenseKey ("pool_office2007")
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
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
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
98 / 175
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
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 (remaining. . . ) 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
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
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.
99 / 175
Examples can be found in the products license-test-. . . .opsi from http://download.uib.de/opsi4.0/products/licensemanagement/. After installing the packets with opsi-package-manager -i *.opsi, in the directory /opt/pcbin/install/<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)
100 / 175
14.9
15
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
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
opsi-client-agent
opsi-winst
python-opsi
opsi-configed
version
>=4.0.1-1
>=4.10.8.12
>=4.0.1-7
>=4.0.1.6-1
15.2
101 / 175
102 / 175
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 interruption. 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
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
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:
103 / 175
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
Note
On windows systems, no symbolic links will be created. Instead of links there will be copies of the link target.
104 / 175
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 functionality as the opsiconfd.
15.4.1
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
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.
105 / 175
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
15.5
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 recommended 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 opsiconfigserver:
opsi-admin -d method
opsi-admin -d method
} active" true
opsi-admin -d method
opsi-admin -d method
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
106 / 175
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
opsi-admin
opsi-admin
opsi-admin
-d
-d
-d
-d
method
method
method
method
configState_create
configState_create
configState_create
configState_create
vpnclient.domain.de
vpnclient.domain.de
vpnclient.domain.de
vpnclient.domain.de
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 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
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
16.1
107 / 175
16.2
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.
108 / 175
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]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[5]
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
[Apr
16.3
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
06
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:32:19]
12:46:03]
12:46:03]
12:46:03]
12:46:04]
12:46:04]
12:46:04]
12:46:04]
12:46:04]
12:46:04]
12:46:06]
12:46:06]
12:46:06]
12:46:06]
12:46:06]
12:46:06]
12:46:27]
12:46:35]
12:46:35]
12:46:35]
12:46:38]
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).
109 / 175
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
mshotfix
vmix12.uib.local :
vmix13.uib.local :
bonifax.uib.local:
17
17.1
-d ALL mshotfix
200804-1
200804-1
200805-2
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 determines, 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
110 / 175
Requirements
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]
17.4
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"}
111 / 175
[
{
"masterDepotId" : "masterdepot.uib.local",
"ident" : "dep1.uib.local",
"networkAddress" : "192.168.101.0/255.255.255.0",
"description" : "Depot 1 Master Depot",
"inventoryNumber" : "",
"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
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
112 / 175
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:
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
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.
113 / 175
global depotSelectionAlgorithmByLatency
depotSelectionAlgorithmByLatency = \
114 / 175
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
[5] [Dec 02 18:25:28] [ event processing
pyo|446)
[5] [Dec 02 18:25:28] [ event processing
[5] [Dec 02 18:25:28] [ event processing
pyo|314)
[5] [Dec 02 18:25:28] [ event processing
.pyo|36)
(...)
[6] [Dec 02 18:25:28] [ event processing
(...)
[6] [Dec 02 18:25:28] [ event processing
.local
(__init__.pyo|106)
[6] [Dec 02 18:25:28] [ event processing
__init__.pyo|110)
[6] [Dec 02 18:25:28] [ event processing
pyo|112)
(...)
[6] [Dec 02 18:25:28] [ event processing
[5] [Dec 02 18:25:28] [ event processing
__init__.pyo|143)
(...)
[6] [Dec 02 18:25:28] [ event processing
[6] [Dec 02 18:25:28] [ event processing
string>|5)
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
gui_startup
(__init__\
(__init__.pyo|78)
(\
(__init__.\
(\
(<\
115 / 175
18
18.1
(\
With the module "Software-on-Demand" opsi administrators may give their users access to install a range of softwareproducts. 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. Furthermore the opsi-client-agent and the opsi-configed at version 4.0.1 are needed.
Table 3: Required Packages
opsi-Package
opsi-client-agent
opsi-winst
python-opsi
opsi-depotserver
opsi-configed
Version
>=4.0.1-3
>=4.10.8.12
>=4.0.1-7
>=4.0.1-2
>=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:
116 / 175
opsi-setup --init-current-config
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 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 Softwareon-Demand
Configuration
software-on-demand.active
software-on-demand.productgroup-ids
software-on-demand.show-details
Description
activates or deactivates the modul.
Product-groups with
software-products, that can be
used for Software-on-Demand.
Show further information to the
user.
Values
true/false
List of produkt-groups
true/false
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 opsiconfiged. Push the Button Server Configuration and change to the tab Host Parameter
117 / 175
../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
118 / 175
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
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
119 / 175
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 dependencies 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
19
19.1
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
120 / 175
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:
121 / 175
19.2
Version
>=4.0.1-23
>=4.11.2.1
>=4.0.1.31-1
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 userLoginScripts 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
122 / 175
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 interpretation 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
123 / 175
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]
Message "Example Profile Patch ...."
if getValue("installationstate", getProductMap) = "installed"
comment "Product is installed"
Files_profile_copy
Registry_currentuser_set
endif
if getValue("lastactionrequest", getProductMap) = "uninstall"
comment "Product was uninstalled"
Files_profile_del
Registry_currentuser_del
endif
[Files_profile_copy]
124 / 175
$MsiId$
$UninstallProgram$
$ProductId$
$InstallDir$
[Winbatch_install]
125 / 175
= "ACME"
= "%ProgramFiles32Dir%\ACME"
126 / 175
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"
127 / 175
As additional action_processor (opsi-winst) parameter you may use /silent, which suppress the display of the opsiwinst 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
20.1
Connecteur-opsi-Nagios
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
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 dactivation. 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
opsi-client-agent
opsiconfd
python-opsi
Version
>=4.0.2-1
>=4.0.2.1-1
>=4.0.2.1-1
20.2.2
128 / 175
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
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
20.4
opsi-checks
Le chapitre suivant explique les objectifs et les configurations des contrles OPSI.
20.4.1
129 / 175
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.
130 / 175
131 / 175
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
-H,--host
-P,--port
-u,--username
-p,--password
-t,--task
Description
serveur opsi qui devrait excuter le
contrle
opsi webservice port
opsi monitoring user
opsi monitoring password
opsi check method (case sensitive)
Exemple
configserver.domain.local
4447 (Default)
monitoring
monitoring123
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:
132 / 175
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
133 / 175
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.
134 / 175
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
/
configed
depot
repository
Path
/usr/share/opsiconfd/static
/usr/lib/configed
/opt/pcbin/install
/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.
135 / 175
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
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:
136 / 175
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 productiveclients.
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
137 / 175
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:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \
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:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \
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:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \
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
138 / 175
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
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
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:
139 / 175
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
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 consquent, vous crez dans /etc/nagios3/conf.d/opsi un autre rpertoire nomm clients.
20.5.3
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
_configserverurl
configserver.domain.local
4447
140 / 175
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
notifications_enabled
event_handler_enabled
flap_detection_enabled
failure_prediction_enabled
process_perf_data
retain_status_information
retain_nonstatus_information
check_command
max_check_attempts
notification_interval
notification_period
notification_options
contact_groups
_configserver
_configserverport
register
icon_image
}
opsi-server-tmpl
1
1
1
1
1
1
1
check-host-alive
10
0
24x7
d,u,r
admins,opsiadmins
configserver.domain.local
4447
0
opsi/opsi-client.png
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
notifications_enabled
event_handler_enabled
flap_detection_enabled
failure_prediction_enabled
process_perf_data
retain_status_information
retain_nonstatus_information
opsi-client-tmpl
1
1
1
1
1
1
1
max_check_attempts
notification_interval
notification_period
notification_options
contact_groups
_configserver
_configserverport
register
icon_image
}
141 / 175
10
0
24x7
d,u,r
admins,opsiadmins
configserver.domain.local
4447
0
opsi/opsi-client.png
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
active_checks_enabled
passive_checks_enabled
parallelize_check
obsess_over_service
check_freshness
notifications_enabled
event_handler_enabled
flap_detection_enabled
failure_prediction_enabled
process_perf_data
retain_status_information
retain_nonstatus_information
notification_interval
is_volatile
check_period
normal_check_interval
retry_check_interval
max_check_attempts
notification_period
notification_options
contact_groups
register
}
opsi-service-tmpl
1
1
1
1
0
1
1
1
1
1
1
1
0
0
24x7
5
1
4
24x7
w,u,c,r
admins,opsiadmins
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
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:
142 / 175
define hostgroup {
hostgroup_name
alias
}
opsi-clients
OPSI-Clients
define hostgroup {
hostgroup_name
alias
members
}
opsi-server
OPSI-Server
configserver.domain.local, depotserver.domain.local
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
host_name
hostgroups
alias
address
}
opsi-server-tmpl
configserver.domain.local
opsi-server
opsi Configserver
configserver.domain.local
define host{
use
host_name
hostgroups
alias
address
}
opsi-server-tmpl
depotserver.domain.local
opsi-server
opsi Depotserver
depotserver.domain.local
Explication des entres: * use rfrences au modle utilise. * hostgroups nous dit quel hostgroup appartient ce
serveur.
20.5.6
Les configurations des clients OPSI doivent tre placs dans un rpertoire propre. Elles doivent tre dfinies comme
ceci:
define host{
use
host_name
hostgroups
alias
address
_depotid
}
opsi-client-tmpl
client.domain.local
opsi-clients
opsi client
client.domain.local
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:
143 / 175
#!/usr/bin/env python
from OPSI.Backend.BackendManager import *
template =
define host {
use
host_name
hostgroups
alias
address
}
opsi-client-tmpl
%hostId%
opsi-clients
%hostId%
%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
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 {
144 / 175
command_name
check_opsiproductstatus
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkProductStatus -e $ARG1$ -d $HOSTADDRESS$ -v
}
define command {
command_name
check_opsiproductStatus_withGroups
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkProductStatus -g $ARG1$ -G $ARG2$ -d "all"
}
define command {
command_name
check_opsiproductStatus_withGroups_long
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkProductStatus -g $ARG1$ -G $ARG2$ -v -d "all"
}
define command {
command_name
check_opsidepotsync
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$
}
define command {
command_name
check_opsidepotsync_long
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ -v
}
define command {
command_name
check_opsidepotsync_strict
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ --strict
}
define command {
command_name
check_opsidepotsync_strict_long
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkDepotSyncStatus -d $ARG1$ --strict -v
}
define command {
command_name
check_opsipluginon_client
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-p $USER3$ -t checkPluginOnClient -c $HOSTADDRESS$ --plugin $ARG1$
}
define command {
command_name
check_opsipluginon_client_with_states
command_line
/usr/lib/nagios/plugins/check_opsi -H $_HOSTCONFIGSERVER$ -P $_HOSTCONFIGSERVERPORT$ -u $USER2$\
-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
adminuser
Opsi
24x7
24x7
w,u,c,r
d,r
notify-service-by-email
notify-host-by-email
root@localhost
contactgroup_name
alias
members
}
145 / 175
opsiadmins
Opsi Administrators
adminuser
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
hostgroup_name
service_description
check_command
check_interval
}
define service{
use
hostgroup_name
service_description
check_command
check_interval
}
define service{
use
hostgroup_name
service_description
check_command
check_interval
}
define service{
use
hostgroup_name
service_description
check_command
check_interval
}
opsi-service-tmpl,srv-pnp
opsi-server
opsi-webservice
check_opsiwebservice
1
opsi-service-tmpl
opsi-server
opsi-diskusage
check_opsidiskusage
1
opsi-service-tmpl
opsi-server
opsi-depotsyncstatus-longoutput
check_opsidepotsync_long!all
10
opsi-service-tmpl
opsi-server
opsi-depotsyncstatus-strict-longoutput
check_opsidepotsync_strict_long!all
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{
use
hostgroup_name
service_description
check_command
check_interval
}
define service{
use
hostgroup_name
service_description
check_command
check_interval
}
define service{
use
opsi-service-tmpl
opsi-clients
opsi-clientstatus
check_opsiclientstatus
10
opsi-service-tmpl
opsi-server
opsi-productstatus-opsiclientagent
check_opsiproductstatus!opsi-client-agent
10
opsi-service-tmpl
hostgroup_name
service_description
check_command
check_interval
}
define service{
use
hostgroup_name
service_description
check_command
check_interval
}
146 / 175
opsi-server
opsi-productstatus-opsiessentials-group
check_opsiproductStatus_withGroups!opsiessentials!productiveclients
10
opsi-service-tmpl
opsi-server
opsi-productstatus-opsiessentials-group-longoutput
check_opsiproductStatus_withGroups_long!opsiessentials!productiveclients
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 configuration de lhte comme _depotid.
define service{
use
host_name
service_description
check_command
check_interval
}
define service{
use
host_name
service_description
check_command
check_memory.exe"
check_interval
}
define service{
use
host_name
service_description
check_command
.exe"
check_interval
}
21
21.1
opsi-service-tmpl
client.domain.local,depotclient.domain.local
opsi-direct-checkpluginonclient
check_opsipluginon_client!"C:\\opsi.org\\nagiosplugins\\check_memory.exe"
10
opsi-service-tmpl
client.domain.local
opsi-direct-checkpluginonclient-with-servicestate
check_opsipluginon_client_with_states!"C:\\opsi.org\\nagiosplugins\\\
10
opsi-service-tmpl
depotclient.domain.local
opsi-direct-checkpluginonclient-from-depot
check_opsipluginon_client_from_depot!"C:\\opsi.org\\nagiosplugins\\check_memory\
10
Habituellement, linstallation des paquets de logiciels opsi sur le client est lanc au dmarrage du client. Ainsi, lutilisateur 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.
147 / 175
Le module opsi pour linstallation lors de larrt apporte cette fonctionnalit. Les clients slectionns peuvent tre
configurs pour faire linstallation larrt.
21.2
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 fonctionnent 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
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 composants 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
148 / 175
Vue densemble
Le module dinstallation lors de larrt repose sur plusieurs lments du systme. Une partie importante est le mcanisme 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 sarrte. 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 dinstallation. En cas de redmarrages requis, la condition pralable installation_pending permet le contrle du processus. 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
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
21.4.3
149 / 175
Ces entres de Registre est fix par les paquets opsi-client-agent et dmarrer lexcution du script darrt doinstall32.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"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="opsi shutdown install policy"
"GPOName"="opsi shutdown install policy"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0\0]
"Script"="C:\\Programme\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall32.cmd"
"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"
"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\Microsoft\Windows\CurrentVersion\Group Policy\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"
"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
150 / 175
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
21.4.5
151 / 175
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
Ce fichier de log est rcrit chaque fois et peut tre vrifie dans le cas dun dysfonctionnement.
22
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
152 / 175
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
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
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
153 / 175
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
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_timeout = 300
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
154 / 175
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 demande 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 configuration 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
23.1
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
155 / 175
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
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
156 / 175
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
157 / 175
158 / 175
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
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
159 / 175
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
160 / 175
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_.*
host_.*
productOnClient_.*
configState_.*
.*
:
:
:
:
:
mysql,
mysql,
mysql,
mysql,
mysql
opsipxeconfd
opsipxeconfd
opsipxeconfd
opsipxeconfd
Finally you have to activate the changed configuration with the following commands:
opsi-setup --init-current-config
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. Configuration 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
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 password). The service address looks like: https://<username>@<ipadresse>:4447/rpc You will be asked for the passwords.
The conversion command looks like that:
161 / 175
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
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
24.1
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 #).
162 / 175
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
192.168.2.153
192.168.2.178
With the following command you may test the name is resolved:
getent hosts $(hostname -f)
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/
/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/*
/etc/opsi/modules
24.1.7
163 / 175
/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
/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
/etc/opsi/version
/etc/init.d/
24.2
Boot files
24.2.1
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
24.3
Files in /var/lib/opsi
24.3.1
/var/lib/opsi/repository
164 / 175
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-packagemanager 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
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
|-repository
manager
|-audit
!-config/-|
|-clientgroups.ini
|-config.ini
opsi_depot share
opsi package repository used by opsi-product-updater opsi-package-\
inventory - files
config share
client groups
Host Parameter (Global Defaults)
|-clients/
|-products/
!-depots
165 / 175
<pcname.ini> files
product control files
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
./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>
166 / 175
/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
167 / 175
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)
168 / 175
[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
Here you find the inventory data for hardware (.hw) and software (.sw).
24.5
24.6
24.6.1
Python library
24.6.2
169 / 175
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
opsi-package-manager
Script to unpack, install, remove, list opsi packages on one ore more servers (and a lot more).
opsi-setup
opsi configuration utility
24.7
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
170 / 175
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
/dev/sda1
*
0+
/dev/sda2
0
/dev/sda3
0
/dev/sda4
0
End
30401-
#cyls
#blocks
Id System
30402- 244197528+
7 HPFS/NTFS
0
0
0 Empty
0
0
0 Empty
0
0
0 Empty
24.7.2
End
1016
-
#cyls
10170
0
0
#blocks
1023580
0
0
0
Id System
b W95 FAT32
0 Empty
0 Empty
0 Empty
/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
/var/log/opsi/package.log
24.7.7
171 / 175
/var/log/opsi/opsi-product-updater.log
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
--\
24.7.9
c:\tmp\opsiloginblocker.txt
c:\tmp\opsiclientd.log
c:\tmp\instlog.txt
25
Registry Entries
25.1
25.1.1
opsi.org/general
bootmode=<bkstd | reins>
Stores the information whether the client is new installed or not.
25.1.2
These both keys should be identical but the second one is deprecated and exists for
compatibility.
Schlssel
[HKEY_LOCAL_MACHINE\SOFTWARE\opsi.org\opsi-client-agent]
[HKEY_LOCAL_MACHINE\SOFTWARE\opsi.org\preloginloader]
"RemoveMsginaOnDeinst"=dword:00000001
on uninstall restore the default login handler
"WinstRegKey"="SOFTWARE\\opsi.org\\winst"
backward
Schlssel
172 / 175
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
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
ID_SYSLOG_FACILITY_KERNEL
ID_SYSLOG_FACILITY_USER
ID_SYSLOG_FACILITY_MAIL
ID_SYSLOG_FACILITY_SYS_DAEMON
ID_SYSLOG_FACILITY_SECURITY1
ID_SYSLOG_FACILITY_INTERNAL
ID_SYSLOG_FACILITY_LPR
ID_SYSLOG_FACILITY_NNTP
ID_SYSLOG_FACILITY_UUCP
ID_SYSLOG_FACILITY_CLOCK1
ID_SYSLOG_FACILITY_SECURITY2
ID_SYSLOG_FACILITY_FTP
ID_SYSLOG_FACILITY_NTP
ID_SYSLOG_FACILITY_AUDIT
ID_SYSLOG_FACILITY_ALERT
ID_SYSLOG_FACILITY_CLOCK2
ID_SYSLOG_FACILITY_LOCAL0
ID_SYSLOG_FACILITY_LOCAL1
ID_SYSLOG_FACILITY_LOCAL2
ID_SYSLOG_FACILITY_LOCAL3
ID_SYSLOG_FACILITY_LOCAL4
ID_SYSLOG_FACILITY_LOCAL5
ID_SYSLOG_FACILITY_LOCAL6
ID_SYSLOG_FACILITY_LOCAL7
26
173 / 175
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
0;
1;
2;
3;
4;
5;
6;
7;
8;
9;
10;
11;
12;
13;
14;
15;
16;
17;
18;
19;
20;
21;
22;
23;
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
kernel messages
user-level messages
mail system
system daemons
security/authorization messages (1)
messages generated internally by syslogd
line printer subsystem
network news subsystem
UUCP subsystem
clock daemon (1)
security/authorization messages (2)
FTP daemon
NTP subsystem
log audit
log alert
clock daemon (2)
local use 0 (local0)
local use 1 (local1)
local use 2 (local2)
local use 3 (local3)
local use 4 (local4)
local use 5 (local5)
local use 6 (local6)
local use 7 (local7)
27
opsi localization
27.1
174 / 175
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
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
PO files: opsi-winst
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
https://svn.opsi.org/listing.php?repname=opsiclientd&path=%2Ftrunk%2Fgettext%2F&#a4c4f8177ba88910762266205d816
27.2.4
PO files: python-opsi
https://svn.opsi.org/listing.php?repname=python-opsi&path=%2Ftrunk%2Fgettext%2F&#a4c4f8177ba88910762266205d81
27.2.5
PO files: opsi-utils
https://svn.opsi.org/listing.php?repname=opsi-utils&path=%2Ftrunk%2Fgettext%2F&#a4c4f8177ba88910762266205d8169
27.2.6
PO files: opsi-bootimage
27.3
175 / 175
configed
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/opsiconfiged_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).
# 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.
27.5
Localization contact