Opsi – Installation du serveur Part2

Opsi – Installation du serveur Part2

Opsi

Opsi (Open PC Server Integration) est un outil de gestion de clients Windows basé sur un serveur Linux et sous licence AGPLv3 (hors code des modules cofinancés), version modifiée et orientée serveurs de la licence GPLv3. Son code source est la propriété de la société uib gmgh et son représentant en France/Belgique est la société Opensides.

uibopensides

Ses fonctionnalités principales sont :

  • Installation automatisée via PXE de systèmes d’exploitation clients Windows par le biais d’une image
  • Distribution automatique des logiciels via une connexion agent/serveur
  • Intégration automatique des drivers en se basant sur l’ID de ceux-ci
  • Inventaires matériels et logiciels
  • Dépôts logiciels multiples et décentralisés

 

Objectif

 
L’objectif de cet article est l’installation et la configuration d’un serveur de déploiement Opsi en version 4.0.6, sur une distribution Linux Debian Jessie 8.7 32bits
 

Schéma logique

 

 

Pré-requis

 
Le seul pré-requis ici est d’avoir suivi la première partie relative à l’installation d’un serveur Opsi : Opsi – Installation du serveur Part1
 

4. Paramétrage du serveur Opsi

 

4.1. Désactivation du service Winbind au démarrage du système

Winbind permet à un utilisateur (ou groupe d’utilisateurs) de s’identifier sur un système UNIX/Linux avec des identifiants de domaine Windows.
Pour cela, un UID (ou GID) est mappé avec le RID (portion d’un SID) correspondant de l’annuaire d’un contrôleur de domaine Windows.
La configuration du service Samba de Opsi ne requiert pas Winbind et peu présenter des dysfonctionnements si activé sur Debian Jessie, nous pouvons donc désactiver ce dernier.

# systemctl disable winbind
Synchronizing state for winbind.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d winbind defaults
Executing /usr/sbin/update-rc.d winbind disable
insserv: warning: current start runlevel(s) (empty) of script `winbind' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `winbind' overrides LSB defaults (0 1 6).

ou

# insserv -r winbind

 

4.2. Modification du fichier /etc/samba/smb.conf

Par sécurité, même si Winbind a été désactivé ci-dessus, on peut spécifier l’intervalle de mapping des UID/GID (avec les SID/RID) utilisés par Winbind entre 1000 et 1999999, sachant que les valeurs inférieures à 1000 sont réservées aux comptes système.

[global]
   workgroup = WORKGROUP
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   server role = standalone server
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes
   idmap config * : range = 1000-1999999

Ci-dessus, ajouter la ligne idmap config * : backend = tdb serait redondant car c’est une option implicite par défaut.
Elle signifie que le fichier d’associations requis par Winbind utilise le fichier /var/lib/samba/winbindd_cache.tdb.

Contenu exemple du fichier /var/lib/samba/winbindd_cache.tdb
{
key(10) = "SN/S-1-5-2"
data(41) = "\00\00\00\00t\19\8FX\A0\1A\8FX\00\00\00\00\05\00\00\00\0CNT Authority\07Network"
}
{
key(15) = "SN/S-1-5-32-546"
data(35) = "\00\00\00\00t\19\8FX\A0\1A\8FX\00\00\00\00\04\00\00\00\07BUILTIN\06Guests"
}
{
key(47) = "SN/S-1-5-21-4273826650-3176465359-281838201-514"
data(16) = "s\00\00\C0t\19\8FX\A0\1A\8FX\00\00\00\00"
}
{
key(15) = "SEQNUM/BUILTIN\00"
data(8) = "t\19\8FXt\19\8FX"
}
{
key(24) = "TRUSTDOMCACHE/WORKGROUP\00"
data(98) = "\02\00\00\00BUILTIN\00\00S-1-5-32\00\00\00\00\00\00\00\00\00\00\00\00\00OPSI-TEST\00\00S-1-5-21-4273826650-3176465359-281838201\00\00\00\00\00\00\00\00\00\00\00\00\00"
}
{
key(10) = "SN/S-1-1-0"
data(30) = "\00\00\00\00t\19\8FX\A0\1A\8FX\00\00\00\00\05\00\00\00\00\08Everyone"
}
{
key(17) = "SEQNUM/OPSI-TEST\00"
data(8) = "t\19\8FXt\19\8FX"
}

 
La commande testparm vérifie la syntaxe du fichier de configuration Samba /etc/samba/smb.conf si aucun paramètre ne lui est passé :

# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[opsi_depot]"
Processing section "[opsi_depot_rw]"
Processing section "[opsi_images]"
Processing section "[opsi_workbench]"
Processing section "[opsi_repository]"
Loaded services file OK.
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_STANDALONE
# /etc/init.d/samba restart
[ ok ] Restarting nmbd (via systemctl): nmbd.service.
[ ok ] Restarting smbd (via systemctl): smbd.service.
[ ok ] Restarting samba-ad-dc (via systemctl): samba-ad-dc.service.

 

4.3. Création de l’administrateur adminuser et affectation des groupes

L’administrateur adminuser est créé comme compte local, puis compte Samba, puis affecté aux groupes secondaires opsiadmin et pcpatch.

# useradd -m -s /bin/bash adminuser
# passwd adminuser
Entrez le nouveau mot de passe UNIX : 
Retapez le nouveau mot de passe UNIX : 
passwd : le mot de passe a été mis à jour avec succès
# smbpasswd -a adminuser
New SMB password:
Retype new SMB password:
Added user adminuser.
# usermod adminuser -aG opsiadmin
# usermod adminuser -aG pcpatch
# groups adminuser
adminuser : adminuser pcpatch opsiadmin
# members -t opsiadmin

opsiconfd adminuser
# members -t pcpatch
pcpatch opsiconfd
adminuser

 
On peut rattacher root aux groupes opsiadmin et pcpatch, sinon il ne lui sera pas possible d’utiliser certaines commandes (comme opsi-package-manager -x) :

# usermod root -aG opsiadmin
# usermod root -aG pcpatch
# members -t opsiadmin

opsiconfd adminuser root
# members -t pcpatch
pcpatch opsiconfd
adminuser root

 

4.4. Configuration du service DHCP

Le serveur Opsi utilisant un serveur DHCP externe, le backend dhcpd n’est donc pas requis et le fichier /etc/opsi/backendManager/dispatch.conf doit ressembler à cela :

backend_.*         : file, opsipxeconfd
host_.*            : file, opsipxeconfd

Ensuite nous devons modifier les configurations des serveurs DHCP externes (master et slave) pour informer les clients bootant en PXE que le serveur de boot est le serveur Opsi. Les deux serveurs DHCP doivent donc présenter les lignes suivantes en fin de fichier :

next-server 192.168.1.13;
filename "linux/pxelinux.0";

 

4.4.1. Modification du fichier /etc/dhcp/dhcpd.conf sur le serveur DHCP master
Contenu du fichier /etc/dhcp/dhcpd.conf modifié
include "/etc/bind/tsig.key";

authoritative;
ddns-update-style standard;
update-static-leases off;
ignore client-updates;
default-lease-time 1800;
max-lease-time 1800;
log-facility local7;
db-time-format local;

failover peer "opensharing-failover" {
        primary;
        address 192.168.1.11;
        port 647;
        peer address 192.168.1.12;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 3; 
        load balance max seconds 3;
        mclt 480;
        split 128;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 192.168.1.1;
	ddns-domainname "opensharing.priv";
	ddns-rev-domainname "in-addr.arpa";
	option domain-name "opensharing.priv";
	option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
	set vendor-string = option vendor-class-identifier;
	pool {
	        failover peer "opensharing-failover";
		range 192.168.1.100 192.168.1.199;
		allow unknown-clients;
	}
}

zone opensharing.priv {
	primary 192.168.1.11;
	key "tsig-key";
}

zone 1.168.192.in-addr.arpa. {
	primary 192.168.1.11;
	key "tsig-key";
}

next-server 192.168.1.13;
filename "linux/pxelinux.0";

 

4.4.2. Modification du fichier /etc/dhcp/dhcpd.conf sur le serveur DHCP slave
Contenu du fichier /etc/dhcp/dhcpd.conf modifié
include "/etc/bind/tsig.key";

authoritative;
ddns-update-style standard;
update-static-leases off;
ignore client-updates;
default-lease-time 1800;
max-lease-time 1800;
log-facility local7;
db-time-format local;

failover peer "opensharing-failover" {
        secondary;
        address 192.168.1.12;
        port 647;
        peer address 192.168.1.11;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 3; 
        load balance max seconds 3;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
	option subnet-mask 255.255.255.0;
	option routers 192.168.1.1;
	ddns-domainname "opensharing.priv";
	ddns-rev-domainname "in-addr.arpa";
	option domain-name "opensharing.priv";
	option domain-name-servers dns1.opensharing.priv, dns2.opensharing.priv;
	set vendor-string = option vendor-class-identifier;
	pool {
	        failover peer "opensharing-failover";
		range 192.168.1.100 192.168.1.199;
		allow unknown-clients;
	}
}

zone opensharing.priv {
	primary 192.168.1.11;
	key "tsig-key";
}

zone 1.168.192.in-addr.arpa. {
	primary 192.168.1.11;
	key "tsig-key";
}

next-server 192.168.1.13;
filename "linux/pxelinux.0";

 

4.5. Résolution de noms par le serveur Opsi

Le serveur Opsi doit pouvoir connaitre l’IP de chaque hôte afin de pouvoir communiquer avec ce dernier (envoi de messages, déploiement de paquets à la demande, requêtes d’informations de session, etc.).
Pour cela, parmi plusieurs possibilités, deux scénarios majeurs sont possibles :

  • Scénario 1 : Le service DNS ne connait pas l’IP de l’hôte et ce dernier se voit affecter des IP variables par le service DHCP
  • Scénario 2 : Le service DNS fournit en permanence l’IP à jour de l’hôte

Nous retiendrons ici le scénario numéro 2 car chaque hôte client se verra affecter une réservation sur les serveurs DHCP master et slave et les enregistrements DNS correspondants seront ajoutés manuellement, via nsupdate. Ainsi, les adresses IP des clients seront résolues par le serveur DNS et toujours connues, la base de données locale du serveur Opsi ne sera donc utilisée qu’en cas de dysfonctionnement du service DNS et pour afficher les adresses IP des hôtes sur l’interface Opsi Configed.

 

4.5.1. Scénario 1

Modifier le fichier /etc/opsi/backends/hostcontrol.conf :

"resolveHostAddress": False

Si l’option est à False, alors le serveur Opsi tente d’obtenir l’adresse IP du client par sa base de données locale et, le cas échéant, par le serveur DNS.
L’option est à False par défaut.

# -*- coding: utf-8 -*-

module = 'HostControl'
config = {
    "opsiclientdPort":    4441,
    "hostRpcTimeout":     15,
    "resolveHostAddress": False,
    "maxConnections":     50,
    "broadcastAddresses": ["255.255.255.255"]
}

Modifier le fichier /etc/opsi/opsiconfd.conf :

update ip = yes

Si l’option est à yes, alors le serveur Opsi mettra à jour sa base de données locale dès qu’un client se verra affecter une adresse IP.
L’option est à no par défaut.

[global]
	backend config dir = /etc/opsi/backends
	dispatch config file = /etc/opsi/backendManager/dispatch.conf
	extension config dir = /etc/opsi/backendManager/extend.d
	acl file = /etc/opsi/backendManager/acl.conf
	admin networks = 0.0.0.0/0
	message bus = no
	multiprocessing = no
	pid file = /var/run/opsiconfd/opsiconfd.pid
	log file = /var/log/opsi/opsiconfd/%m.log
	symlink logs = yes
	log level = 5
	log format = [%l] [%D] %M (%F|%N)
	max log size = 5MB
	max execution statistics = 250
	monitoring user = monitoring
	monitoring debug = false
[service]
	interface = 0.0.0.0
	http port = 0
	https port = 4447
	ssl server cert = /etc/opsi/opsiconfd.pem
	ssl server key = /etc/opsi/opsiconfd.pem
[session]
	session name = OPSISID
	verify ip = no
	update ip = yes
	max inactive interval = 120
	max authentication failures = 5
	max sessions per ip = 25
[directories]
	/ = /usr/share/opsiconfd/static (noauth)
	configed = /usr/lib/configed (noauth)

 

4.5.2. Scénario 2 (solution retenue ici)

Modifier le fichier /etc/opsi/backends/hostcontrol.conf :

"resolveHostAddress": True

Si l’option est à True, alors le serveur Opsi tente d’obtenir l’adresse IP du client par le serveur DNS et, le cas échéant, par sa base de donnée locale.
L’option est à False par défaut.

# -*- coding: utf-8 -*-

module = 'HostControl'
config = {
    "opsiclientdPort":    4441,
    "hostRpcTimeout":     15,
    "resolveHostAddress": True,
    "maxConnections":     50,
    "broadcastAddresses": ["255.255.255.255"]
}

Modifier le fichier /etc/opsi/opsiconfd.conf :

update ip = yes

Si l’option est à yes, alors le serveur Opsi mettra à jour sa base de données locale dès qu’un client se verra affecter une adresse IP.
L’option est à no par défaut.

[global]
	backend config dir = /etc/opsi/backends
	dispatch config file = /etc/opsi/backendManager/dispatch.conf
	extension config dir = /etc/opsi/backendManager/extend.d
	acl file = /etc/opsi/backendManager/acl.conf
	admin networks = 0.0.0.0/0
	message bus = no
	multiprocessing = no
	pid file = /var/run/opsiconfd/opsiconfd.pid
	log file = /var/log/opsi/opsiconfd/%m.log
	symlink logs = yes
	log level = 5
	log format = [%l] [%D] %M (%F|%N)
	max log size = 5MB
	max execution statistics = 250
	monitoring user = monitoring
	monitoring debug = false
[service]
	interface = 0.0.0.0
	http port = 0
	https port = 4447
	ssl server cert = /etc/opsi/opsiconfd.pem
	ssl server key = /etc/opsi/opsiconfd.pem
[session]
	session name = OPSISID
	verify ip = no
	update ip = yes
	max inactive interval = 120
	max authentication failures = 5
	max sessions per ip = 25
[directories]
	/ = /usr/share/opsiconfd/static (noauth)
	configed = /usr/lib/configed (noauth)

 

4.6. Installation des produits de base depuis le dépôt uib

L’ensemble des produits disponibles sur les dépôts de uib sont disponibles à l’adresse suivante :
http://download.uib.de/opsi4.0/products/
Où l’on retrouve notamment les produits des sections :

Par défaut la section relative aux produits opsi-linux, dans le dépôt uib_linux, est active, mais nous ne souhaitons par récupérer ces produits car ils viendraient utiliser de l’espace de stockage inutilement et nous n’aurons pas de clients Linux. Pour ces raisons, nous pouvons désactiver de dépôt en modifiant la ligne suivante du fichier /etc/opsi/opsi-product-updater.conf :

[repository_uib_linux]
active = false
baseUrl = http://download.uib.de
dirs = opsi4.0/products/opsi-linux
autoInstall = false
autoUpdate = true
autoSetup = false
; Set Proxy handler like: http://10.10.10.1:8080
proxy =

Par défaut, l’option active est à true, nous la passons donc à false.
Les seules sections restant actives sont maintenant uniquement netboot et localboot dans le dépôt uib :

[repository_uib]
active = true
opsiDepotId =
baseUrl = http://download.uib.de
dirs = opsi4.0/products/localboot, opsi4.0/products/netboot
includeProductIds =
username =
password =
autoInstall = false
autoUpdate = true
autoSetup = false
onlyDownload = false
proxy =

La commande suivante installera tous les produits que ces deux sections du dépôt uib contiennent :

# opsi-product-updater -i -vv

Au moment de la rédaction de cet article, les produits suivants sont installés :

Localboot Netboot
activate-win hwinvent
config-win-base memtest86
config-win10 opsi-clonezilla
config-win81-desktop win7-captured’
hwaudit win7-enterprise-msdn
javavm win7-x64-captured’
jedit win7-x64-enterprise-msdn
networklocation win7-x64
opsi-client-agent win7
opsi-configed win10-captured
opsi-logviewer win10-x64-captured
opsi-set-win-uac win10-x64
opsi-setup-detector win10
opsi-template-with-admin win81-captured
opsi-template win81-x64-captured
opsi-uefi-netboot win81-x64
opsi-wan-config-off win81
opsi-wan-config-on win2008-r2
opsi-wim-capture win2012-r2
opsi-wim-info win2012
opsi-winst-test win2016
shutdownwanted wipedisk
swaudit
windomain

Pour chaque produit, le processus de téléchargement et d’installation sera le même. Ici, prenons l’exemple du produit javavm correspondant à Java JRE d’Oracle :

Zsync command found: /usr/bin/zsync
Reading config file '/etc/opsi/opsi-product-updater.conf'
Getting installed products
Getting info for local packages in '/var/lib/opsi/repository'
Getting package infos from repository 'http://download.uib.de'
[...]
javavm_1.8.0.101or1.8.0.102-1.opsi - installation required: product 'javavm' is not installed and auto install is set for repository 'http://download.uib.de'
javavm_1.8.0.101or1.8.0.102-1.opsi - download of package is required: local package not found
Downloading http://download.uib.de/opsi4.0/products/localboot/javavm_1.8.0.101or1.8.0.102-1.opsi (214.81 MB) to /var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi
Download of 'http://download.uib.de/opsi4.0/products/localboot/javavm_1.8.0.101or1.8.0.102-1.opsi' completed
Setting rights on directory u'/var/lib/opsi/repository'
[...]
Installation time window not defined, installing products and setting actions
[...]
Getting meta data from package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi'
[...]
Installing package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi'
=================================================================================================
Installing package file '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' on depot 'opsi-test.opensharing.priv'
Getting meta data from package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi'
Creating product in backend
Locking product 'javavm' on depot 'opsi-test.opensharing.priv'
Checking package dependencies
Running preinst script
Running package script 'preinst'
Unpacking package files
Extracting data from package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi'
Setting product property states in backend
Running postinst script
Running package script 'postinst'
Creating package content file
Setting access rights of client-data files
Unlocking product 'javavm_1.8.0.101or1.8.0.102-1' on depot 'opsi-test.opensharing.priv'
Package '/var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi' successfully installed
[...]
Not setting action 'setup' for product 'javavm' where installation status 'installed' because auto setup is not set for repository 'http://download.uib.de'

Pour résumer, le processus suit les étapes suivantes :

  1. Vérification du fichier /etc/opsi/opsi-product-updater.conf : quels dépôts et sections sont actifs, quels dépôts sont en autoInstall et/ou autoUpdate et/ou autoSetup
  2. Vérification des paquets installés en local dans le répertoire /var/lib/opsi/repository
  3. Vérification des paquets disponibles sur le dépôt http://download.uib.de dans les sections actives (ici localboot et netboot)
  4. Comparaison des versions collectées en local et sur le dépôt distant
  5. Téléchargement des produits non installés en local dans le répertoire /var/lib/opsi/repository
  6. Définition des droits sur les répertoires du dépôt local /var/lib/opsi/repository (770 opsiconfd:pcpatch) et ses fichiers (660 opsiconfd:pcpatch)
  7. Obtention des métadonnées relatives à chaque produit
  8. Installation (option -i) des produits non installés en local (c’est-à-dire ici tous car c’est une première installation)
  9. Création du produit dans le file backend stocké dans /var/lib/opsi/ :
    • Exemple pour Java : /var/lib/opsi/config/products/javavm_1.8.0.101or1.8.0.102-1.localboot : fichier texte définissant les propriétés du produit
    • Exemple pour Java : /var/lib/opsi/repository/javavm_1.8.0.101or1.8.0.102-1.opsi : archive cpio contenant le produit téléchargé en local
  10. Refus de déploiement automatique des produits sur les clients car aucune section n’est en autoSetup

Ci-dessus, l’option -i a été utilisée pour outrepasser l’option autoInstall définie à false et les éventuelles exclusions pour les dépôts actifs.

 

4.6. Redémarrage des services

# opsi-setup --init-current-config
# opsi-setup --set-rights
# service opsiconfd restart
# service opsipxeconfd restart

 

5. Client de connexion à l’interface opsi-configed

Le serveur Opsi est installé, nous pouvons maintenant tester une connexion à l’interface Opsi Configed permettant l’administration du déploiement des produits localboot (logiciels) et netboot (systèmes d’exploitation), même si pour le moment nous n’avons aucun hôte à administrer.
Nous avons besoin, pour établir une connexion avec le serveur, d’installer Java sur le client utilisé pour la connexion.
 

5.1. Client de connexion Windows

Installer simplement Java.

 

5.2. Client de connexion Linux

Là aussi il faut installer Java, mais pour cela, la procédure est moins simple :

  • Il faut, dans un premier temps, ajouter le dépôt WebUpd8 Oracle Java PPA relatif à la distribution Xenial de Ubuntu dans un nouveau fichier /etc/apt/sources.list.d/webupd8team-java.list.
  • Puis, dans un second temps, installer Java 8 et le définir comme version de Java par défaut au cas où d’autres versions soient déjà installées sur le système.
# echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee /etc/apt/sources.list.d/webupd8team-java.list 
# echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu xenial main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list
# apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886
# aptitude update
# aptitude install oracle-java8-installer
# aptitude install oracle-java8-set-default

On peut ensuite vérifier la version de Java installée sur le système :

# java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)

 

5.3. Connexion effective à l’interface Opsi Configed

Dans la barre d’adresse d’un navigateur, saisir l’adresse suivante :

https://opsi.opensharing.priv:4447/configed

Accepter l’exception de sécurité en validant le certificat généré en partie 1 de cet article et valide 2 ans.
Ceci entraine le téléchargement d’un applet Java que l’on peut ouvrir avec Oracle Java 8 Web Start (installé avec Java).
Cet applet appelé configed.jnlp contient le code XML suivant :

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="https://opsi.opensharing.priv:4447" href="configed.jnlp">
	<information>
		<title>opsi-configed</title>
		<vendor>uib GmbH</vendor>
		<homepage href="http://www.opsi.org/"/>
		<description>Management console application for the opsi client management system</description>
		<description kind="short">opsi management interface (opsi-configed)</description>
		<icon href="configed.gif"/>
		<offline-allowed/>
	</information>
	<security>
		<all-permissions/>
	</security>
	<resources>
		<j2se version="1.7+" max-heap-size="1024M"/>
		<property name="loglevel" value="4" />
		<jar href="configed/configed.jar" main="true"/>
		<jar href="configed/swingx.jar"/>
		<jar href="configed/commons-io.jar"/>
	</resources>
	<application-desc main-class="de.uib.configed.configed">
	<argument>--args</argument><argument>-h;;opsi.opensharing.priv:4447</argument>
	</application-desc>
</jnlp>

Lorsque cet applet est exécuté, la connexion s’établit à l’interface de management Opsi Configed, une fois l’authentification faite avec l’utilisateur adminuser créé précédemment :

On retrouve alors la liste des produits localboot installés, sous l’onglet Configuration produit :

Mais aussi les produits netboot sous l’onglet Produits Netboot :

Chaque produit est identifié par sa version installée sur le serveur et installable sur les clients mais aussi par son nom, sa description, ses propriétés et dépendances :

 

5.4. Et ensuite?

Après la partie 2 d’installation, il est nécessaire de consulter les articles suivants :

Opsi – Installation du serveur Part1 Opsi – Installation du serveur Part2
Opsi – Creation d’une image Windows 7 Opsi – Installation d’un client Windows 7
Opsi – Creation d’une image Windows 10 Opsi – Installation d’un client Windows 10
Opsi – Creation d’une image Windows XP Opsi – Installation d’un client Windows XP
Opsi – Pour aller plus loin Opsi – Fonctionnement des scripts
Opsi – Exemples de scripts Opsi – Script de test local
Opsi – Scripts avancés Opsi – Création d’un produit
Opsi – Commandes utiles Opsi – Package activate-win Officiel
Opsi – Package windomain Officiel

 

Références

 

Laisser un commentaire