Opsi 4.0.3 Notes de version

Opsi 4.0.3 Notes de version Revision: 26.02.2013 OpenSides sprl Rue des Palais 44, bte 33 1030 Brussels Tel.:+32 2 880 97 40 www.opensides.be opsi@opensides.be

Opsi 4.0.3 Notes de version i Table des matières 1 Droit d auteur 1 2 Vue d ensemble des nouvelles fonctionnalités 2 3 Cessation 4 3.1 Cessation du support de Python 2.4..................................... 4 3.2 Cessation des versions de distribution Linux................................. 4 4 Remarques sur l installation 5 5 Installation d opsi lors de l arrêt 6 5.1 Introduction................................................... 6 5.2 Conditions préalables à l installation lors de l arrêt............................. 6 5.3 Activation de l installation lors de l arrêt................................... 6 5.4 Concept technique............................................... 7 5.4.1 Vue d ensemble............................................. 7 5.4.2 Installation par script d arrêt..................................... 7 5.4.3 Entrées de Registre pour exécuter le script d arrêt......................... 8 5.4.4 Configuration de opsiclientd...................................... 9 5.4.5 Configuration spéciale d Installation lors de l Arrêt......................... 10 5.4.6 Fichier de log local........................................... 11 6 La fonctionnalité opsi SilentInstall 12 6.1 Conditions préalables à l installation en mode silencieux.......................... 12 6.2 Vue d ensemble de la fonctionnalité SilentInstall............................... 12 6.3 Exécution de l installation silencieuse..................................... 13 6.4 Configuration de la fonctionnalité opsi: SilentInstall............................ 13 7 Protect your CI changes from updates: le répertoire custom 16 8 Adaptations des méthode byaudit pour l intégration des drivers 17 9 Backend HostControlSafe 18

Opsi 4.0.3 Notes de version ii 10 opsi-winst 4.11.3.5 19 10.1 Customisation opsi-winst........................................... 19 10.1.1 Mode Fenêtre / Skin.......................................... 19 10.2 Commandes pour contrôler la journalisation................................. 20 10.3 Calcul avec des nombres............................................ 20 10.4 Sections PatchTextFile............................................. 23 10.4.1 Paramèters............................................... 23 10.5 Sections LinkFolder............................................... 23 10.6 Sections ExecWith............................................... 24 10.6.1 Paramètres d appel (Modificateur).................................. 24 10.7 Sections WinBatch............................................... 24 10.7.1 Paramètres d appel (Modificateur).................................. 24 10.8 Section LDAPsearch.............................................. 25 10.8.1 Syntaxe section LDAPsearch..................................... 25 10.8.2 Exemples................................................ 25 11 opsi-configed 4.0.3.1 26 11.1 Paramètres de l hôte dans la configuration client et serveur........................ 26 11.2 Fichiers de log................................................. 26 12 Miscellaneous 28 12.1 Les références au manuel opsi......................................... 28 12.1.1 Activation du module de gestion des licences............................ 28 12.1.2 Configuration par le service Web (opsi-config-object)........................ 28 12.2 Changelogs:................................................... 28 12.2.1 Changelog de opsi-winst........................................ 28 12.2.2 Changelog de opsi-winst-test..................................... 29 12.2.3 Changelog de jedit........................................... 29 12.2.4 Changelog de opsi-adminutils..................................... 30 12.2.5 Changelog de opsi-template...................................... 30 12.2.6 Changelog des produits netboot windows.............................. 30 12.2.7 Changelog de opsi-client-agent.................................... 31 12.2.8 Changelog de python-opsi....................................... 32 12.2.9 Changelog de opsipxeconfd...................................... 32 12.2.10 Changelog de opsiconfd........................................ 32 12.2.11 Changelog de opsi-utils........................................ 33 12.2.12 Changelog de opsi-linux-bootimage.................................. 33 12.2.13 Changelog de opsi-depotserver.................................... 34 12.2.14 Changelog de opsi4ucs......................................... 34 12.2.15 Changelog de opsi-configed...................................... 34

Opsi 4.0.3 Notes de version 1 / 34 Chapitre 1 Droit d auteur Le droit d auteur de ce manuel est détenu par uib gmbh à Mainz, Allemagne. Le droit d auteur de la traduction francaise est détenu par OpenSides à Bruxelles, Belgique. Ce manuel est publié sous licence creative commons Attribution - ShareAlike (by-sa). Vous trouverez ici la description allemande: http://creativecommons.org/licenses/by-sa/3.0/de/ La licence allemande: http://creativecommons.org/licenses/by-sa/3.0/de/legalcode La description anglaise: http://creativecommons.org/licenses/by-sa/3.0/ La licence anglaise: http://creativecommons.org/licenses/by-sa/3.0/legalcode La description française: http://creativecommons.org/licenses/by-sa/3.0/deed.fr La licence française: http://creativecommons.org/licenses/by-sa/3.0/fr/legalcode Le logiciel OPSI est dans la plupart de ces pièces open source. Seulement les nouvelles pièces qui sont encore sous le cofinancement ne sont pas open source. voir: http://www.opsi.org/fr/projets-de-co-financement Tout le reste du code source est publié sous licence GPLv3: La licence GPLv3: http://www.gnu.org/licenses/gpl.html Le nom opsi est une marque déposée de uib gmbh. Le logo de opsi est détenue par uib gmbh et peut être utilisé uniquement avec l autorisation explicite.

Opsi 4.0.3 Notes de version 2 / 34 Chapitre 2 Vue d ensemble des nouvelles fonctionnalités La release 4.0.3 est riche en nouvelles fonctionnalités et améliorations. extension opsi: Installation lors de l arrêt fonctionnalité opsi: installation silencieuse Localisation italien et danois Support pour les distributions suivantes: UCS 3.1 Ubuntu 12.10 Le guide d installation se trouve dans le manuel opsi-getting-started. L arrêt à la fin de Mars 2013 du support pour: CentOs 5 RedHat 5 OpenSuse 11.3 / 11.4 opsi-client-agent Version largement révisée Version Open Source de l extension opsi: Sélection dynamique du dépôt extension opsi: Installation lors de l arrêt fonctionnalité opsi: installation silencieuse Amélioration de la personnalisation Adaptations pour le support de Windows 8 Gestion de session révisée: une meilleure identification des comptes d utilisateurs. Améliorations pour le support WAN plusieurs corrections composants du serveur opsi Amélioration du Backend DHCP Nouveau Backend HostControlSafe Génération du certificat SSL webservice par l intermédiaire de opsi-setup Produits Windows Netboot Support Windows 8 / Server 2012 Amélioration de la procédure byaudit Taille de la partition WinPE configurable

Opsi 4.0.3 Notes de version 3 / 34 Nouvelle propriété data_partition_create: la partition de données sera créée s il existe un espace disque disponible (true/false; par défaut: true). Support UEFI Prise en charge de RAID 1 logiciel: Nouvelle propriété useraid1 gère 2 disques existants de la même façon. opsi-winst: Un grand nombre de nouvelles fonctionnalités, qui sont décrits en détail plus bas. Changement de la licence depuis GPLv3 vers AGPLv3: Avec la release 4.0.3 nous allons passer à AGPLv3. Ce changement du type de licence ne concerne que les entreprises, qui distribuent opsi dans le cadre d un produit à code source fermé. Quiconque a besoin d une licence pour vendre opsi dans le cadre d une solution à code source fermée peut nous contacter. Pour plus de détails s il vous plaît consulter le document opsi-v403-releasenotes et les manuels révisés d opsi.

Opsi 4.0.3 Notes de version 4 / 34 Chapitre 3 Cessation Dans ce chapitre sont répertoriés les abandons. Ces versions de distribution, par différentes raisons, ne seront plus prises en charge par opsi. 3.1 Cessation du support de Python 2.4 Avec cette version le soutien officiel de Python 2.4 est interrompue. Cela concerne les distributions: Redhat 5 et Centos 5. Les dépôts concernés seront fermés à la fin de Mars 2013. Les versions finales des paquets seront disponibles à partir de l archive download.uib.de. Pour les installations opsi concernés, nous vous recommandons la mise à niveau vers les nouvelles versions des distributions, qui sont toujours pris en charge. 3.2 Cessation des versions de distribution Linux Les versions suivantes de distributions Linux ne sont plus supportées en raison de l entretien insuffisant par le distributeur: opensuse 11.3 Ubuntu 10.10 Ubuntu 11.04 Ubuntu 11.10 Ces dépôts seront fermés à la fin de Mars 2013. Pour les installations basées sur ces versions de distribution, nous recommandons fortement une mise à niveau du système d exploitation. Mais avant de le faire, vérifiez si la version choisie est soutenue par opsi.

Opsi 4.0.3 Notes de version 5 / 34 Chapitre 4 Remarques sur l installation Les produits contenus dans ce communiqué en plusieurs parties dépendent les unes des autres. Donc installez tous ses morceaux et n essayez pas d installer seulement certaines parties. Vous devez mettre à jour d abord le serveur, puis les produits opsi. Pour installer les paquets de la version de test hangez le dépôt opsi de opsi40 vers opsi40-testing. Par exemple pour Ubuntu 12.04: deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40/xubuntu_12.04./ il faut le remplacer par: deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40-testing/xubuntu_12.04./ Puis mettez à jour vos paquets. Par exemple pour Ubuntu / Debian: aptitude update aptitude dist-upgrade Pour l installation des produits opsi de test: cd /home/opsiproducts mkdir opsi403 cd opsi403 wget -r -l1 -nc -nd -A "*.opsi" http://download.uib.de/opsi4.0/testing/opsi403/products/ opsi-package-manager -i *.opsi Si la commande wget devrait échouer, vous pourriez avoir à régler la variable environnementale http_proxy avec un adresse proxy valide (ex. http_proxy=http://192.168.1.5:8080/) Dans le cas où vous disposez d une installation à plusieurs dépôts, mettez à niveau d abord le serveur de configuration, puis les serveurs dépôt. Attention Depuis opsi 4.0.3 nous avons supprimé les dépendances des paquetages dhcp server et java runtime environment du serveur opsi. Nous avons fait ces changements, parce que la plupart de nos clients utilisent un autre serveur dhcp et n ont pas besoin d exécuter opsi-configed directement sur le serveur OPSI. Ceci mène à une désinstallation automatique de ces paquets s ils ont été installées avant par la dépendance opsi. Si vous avez besoin d un de ces paquets sur votre serveur opsi, vous devez vérifier et (si nécessaire) réinstaller ces paquets après mise à jour vers opsi 4.0.3.

Opsi 4.0.3 Notes de version 6 / 34 Chapitre 5 Installation d opsi lors de l arrêt 5.1 Introduction Habituellement, l installation des paquets de logiciels opsi sur le client est lancé au démarrage du client. Ainsi, l utilisateur doit attendre que l installation se termine, avant que l ouverture de session utilisateur soit autorisée. Il pourrait être utile de faire la plupart de l installation du logiciel lorsque le client va arrêter. Le module opsi pour l installation lors de l arrêt apporte cette fonctionnalité. Les clients sélectionnés peuvent être configurés pour faire l installation à l arrêt. 5.2 Conditions préalables à l installation lors de l arrêt Le module opsi d installation lors de l arrêt peut être utilisé pour des clients à partir de Windows XP. Les composants nécessaires font partie du paquet opsi opsi-client-agent. Actuellement, ce module est en projet de cofinancement. Donc, il nécessite un fichier spécial des modules pour déverrouiller cette fonctionnalité. Pour plus de détails sur les projets en cofinancement voir Section 12.1.1 et le lien internet projets en co-financement. Le paquet opsi-client-agent doit être à la version 4.0.2.3-2 ou supérieur et opsiclientd à la version 4.0.75 ou supérieur. Les cas suivants sont des restrictions et contraintes techniques: Extension WAN: le module d installation lors de l arrêt, n est actuellement pas disponible pour les clients fonctionnent avec l extension WAN. L utilisation de l extension WAN pour un client, sous certaines conditions, nécessite d utiliser les fichiers de configuration locaux, qui gênent la manipulation de l état de l installation sur le mécanisme d arrêt. Les stratégies de groupe: une partie du mécanisme d installation lors de l arrêt est basé sur des scripts d arrêt par la stratégie de groupe locale. D autres stratégies de groupe peuvent remplacer ces configurations locales. Dans ce cas, la configuration requise pour l exécution de scripts d arrêt devraient être inclus dans vos stratégies de groupe prise en charge. Voir Section 5.4.2 pour les configurations requises. Windows Home Edition: Windows Home ne fournit pas le nécessaire mécanisme de script d arrêt via la stratégie de groupe locale. Par conséquent, l installation lors de l arrêt ne peut pas être utilisé pour Windows Home Edition. Windows 2000: Pour les clients Windows 2000 le délai d attente maximal pour les scripts d arrêt est de 10 minutes. Après 10 minutes, l installation est interrompue par le système Windows. Par conséquent, l installation lors de l arrêt ne peut pas être utilisé pour les clients Windows 2000. 5.3 Activation de l installation lors de l arrêt Les composants requis pour l installation lors de l arrêt font partie de l actuel paquet opsi-client-agent. Pour le déverrouiller, un fichier modules valide doit être obtenue et copié sur le serveur.

Opsi 4.0.3 Notes de version 7 / 34 En suite, l installation lors de l arrêt peut être configuré pour les clients appropriés (voir Section 5.2) en établissant pour opsi-client-agent la propriété du produit on_shutdown_install=on et en fixant opsi-client-agent=setup. Ça y est. Tout le reste de la configuration est effectuée par le paquet opsi-client-agent lors de l installation. L installation lors de l arrêt se fait en plus de l installation au démarrage. Habituellement, c est le meilleur moyen de s assurer que les clients ont toujours les mises à jour de sécurité actuels installé, même si le client était éteinte pendant une longue période (lorsque l utilisateur est en vacances par exemple). Si nécessaire, l installation au démarrage par défaut peut être désactivée, voir Section 5.4.5. Les installations en cours se poursuivent tout de même, ce qui est commandé par la condition installation_pending. Le système Windows lors de l arrêt du système ne distingue pas l arrêt du redémarrage. L installation lors de l arrêt est lancé dans les deux cas et il n est pas possible de les distinguer lors de l installation. En outre, il n est pas possible de transformer un arrêt du système dans un redémarrage (ou vice versa). Ainsi, en cas d un arrêt du système, toutes les autres installations sont poursuivies au prochain démarrage du système. 5.4 Concept technique Les explications qui suivent sont pour la compréhension de la conception technique et les interactions entre les composants en cas de configurations particulières ou des états d erreur. Habituellement toutes les configurations requises sont effectuées par le paquet opsi-client-agent. 5.4.1 Vue d ensemble Le module d installation lors de l arrêt repose sur plusieurs éléments du système. Une partie importante est le mécanisme du script d arrêt de Windows via la stratégie de groupe locale. Les scripts d arrêt permettent d exécuter des tâches à l arrêt, lorsque l utilisateur est déjà déconnecté, mais tous les services du système sont encore disponibles. Le script d arrêt effectue une tâche opsi, qui déclenche la fonction système opsi opsiclientd pour démarrer le processus d installation et attendre la fin de la tâche. Ainsi, le système attend que le processus d installation se termine puis s arrête. Lors de la manipulation d arrêt, le système Windows ne distingue pas l arrêt du redémarrage, donc l installation est déclenché dans les deux cas. Le service client opsi opsiclientd est configuré pour traiter l action on_shutdown, qui commence le processus d installation. En cas de redémarrages requis, la condition préalable installation_pending permet le contrôle du processus. Si, lors de l installation, un redémarrage est nécessaire avant de poursuivre l installation, la condition préalable installation_pending mène à poursuivre l installation au prochain démarrage du système (même si l installation à gui_startup est désactivée). Pendant l état de installation_pending, aucune autre installation à l arrêt ne sera déclenché, sinon, il n y aurait pas de redémarrage entre l installation au démarrage et l installation lors de l arrêt. Donc, jusqu à ce que l installation actuelle soit terminée, l installation lors de l arrêt est supprimé par la mise en event_on_shutdown{installation_pending}. Le chapitre suivant donne quelques détails supplémentaire sur l installation lors de l arrêt. 5.4.2 Installation par script d arrêt Au travers de spéciales entrées de registre, la stratégie de groupe locale est configuré pour effectuer un script d arrêt opsi, ce qui déclenche le processus d installation. Les entrées du registre utilisées par opsi-client-agent sont les mêmes qu en utilisant l éditeur de stratégie de groupe gpedit.msc. Ceci est la façon de configurer le script d arrêt à l aide de l éditeur de stratégie de groupe gpedit.msc: Stratégie d ordinateur local Configuration de l ordinateur Paramètres Windows Scripts (Démarrage/Arrêt) Arrêt

Opsi 4.0.3 Notes de version 8 / 34 Scripts - Ajout - Parcourir C:\Programme\opsi.org\opsi-client-agent\on_shutdown\doinstall32.cmd (ou doinstall64.cmd pour 64Bit systems) Pour configurer le système afin d attendre la fin du processus d installation, le temps d attente maximum est réglée sur l infini (0 secondes): Modèles d administration Système - Scripts Temps d attente maximal pour les scripts de stratégie de groupe Réglage - Activé - Secondes: 0 Le script d arrêt opsi doinstall32.cmd / doinstall64.cmd change le répertoire de travail et déclenche l événement on_shutdown: echo Start opsi product installation... cd "%ProgramFiles%\opsi.org\opsi-client-agent" opsiclientd_shutdown_starter.exe on_shutdown Pour les systèmes 64 bits: echo Start opsi product installation... cd "%ProgramFiles(x86)%\opsi.org\opsi-client-agent" opsiclientd_shutdown_starter.exe on_shutdown opsiclientd_shutdown_starter il déclenche l installation et attend l exécution, si l arrêt du système est retardé pendant que la tâche opsiclientd_shutdown_starter est en cours d exécution. 5.4.3 Entrées de Registre pour exécuter le script d arrêt Ces entrées de Registre est fixé par les paquets opsi-client-agent et démarrer l exécution du script d arrêt doinstall32.cmd sous des clients WinXP / 32Bit. Pour les systèmes 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 entrées de registre pour Win6 64Bit (Vista / Win7 / Win8):

Opsi 4.0.3 Notes de version 9 / 34 [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 5.4.4 Configuration de opsiclientd Pour la gestion de l installation lors de l arrêt, le service client opsi opsiclientd a besoin des entrées pour l événement spécial on_shutdown dans le fichier de configuration opsiclientd.conf. Celles-ci sont les entrées 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 préalable installation_pending est réglée sur true par opsiclientd alors qu une installation est en cours, et elle est réglée false lorsque l installation est terminée. Ainsi, une installation inachevée, qui doit procéder à l installation après un redémarrage, peut être détectée par la condition installation_pending encore étant true à la fin de l exécution du script. Lorsque la section event_on_shutdown est réglée sur False (qui est la valeur par défaut), l installation lors de l arrêt est désactivé. Celle-ci est la configuration d un client avec l installation lors de l arrêt activée: [event_gui_startup] active = True [event_gui_startup{installation_pending}] active = True [event_on_shutdown]

Opsi 4.0.3 Notes de version 10 / 34 active = True [event_on_shutdown{installation_pending}] active = False [precondition_installation_pending] installation_pending = true Donc, la seule différence est la section event_on_shutdown étant à True: [event_on_shutdown] active = True. Le réglage de la section event_on_shutdown est géré par le commutateur produit on_shutdown_install du paquet opsi-client-agent. La condition préalable precondition_installation_pending =true indique que le processus d installation en cours n est pas encore terminé. Cette condition reste à true, même après plusieurs redémarrages, jusqu à ce que l installation actuelle est complété. Dans le cas d un redémarrage nécessaire lors de l installation, la configuration [event_gui_s tartup{installation_pending}] active =True provoque la poursuite de l installation au prochain démarrage du système. Cette configuration ne peut pas être changé, parce que l installation actuelle doit être complétée, avant que l utilisateur soit autorisé à se connecter. Également la configuration [event_on_shutdown{installation_pending}] active =False doit conserver sa valeur à False en permanence, parce que l installation doit se poursuivre APRÈS le prochain redémarrage. Sinon, il n y aurait pas un redémarrage entre l installation au démarrage et l installation lors de l arrêt. Dès que le processus d installation est terminé, la condition préalable est réglé sur installation_pending =false, de sorte que l installation lors de l arrêt est de nouveau active. 5.4.5 Configuration spéciale d Installation lors de l Arrêt Pour activer l installation à l arrêt, juste un fichier modules valide est nécessaire, comme décrit dans Section 5.3. Ensuite, l installation lors de l arrêt, peut être activé en positionnant le commutateur de produit on_shutdown_install du paquet opsi-client-agent. Par éfaut, l installation au démarrage est également active. Donc il est assuré, que le client a toujours de logiciels mis à jour. Même s il a été hors ligne pendant un certain temps (lorsque l utilisateur rentre de vacances, par exemple). L installation au démarrage peut être désactivée, si on le désire. La configuration de opsi-client-agent peut être effectuée par le service Web (voir: Section 12.1.2), therefore an opsi-config-object should be created: opsiclientd.event_gui_startup.active (boolean, default: true) Par ce opsi-config-object l événement gui_startup peut être configuré pour un client. opsi-config-objects peut être créée par opsi-configed ou opsi-admin. Pour la création de opsi-config-object avec opsi-admin, exécutez 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 défaut true est la valeur par défaut dans opsiclientd.conf. Pour désactiver l installation au démarrage pour un client, opsi-config-object peut être configuré comme suit: opsiclientd.event_gui_startup.active: false Soyez prudent avec la désactivation de l installation au démarrage, car il y a un risque élevé d avoir des logiciels obsolètes. Ne jamais modifier les paramètres des sections de la condition installation_pending. Les paramètres par défaut sont nécessaires pour gérer le processus d installation. Pour définir opsi-config-object avec opsi-admin, exécutez la commande suivante sur le opsi-configserver (dans l exemple, pour un client avec opsi-host-id myclient.domain.de):

Opsi 4.0.3 Notes de version 11 / 34 opsi-admin -d method configstate_create opsiclientd.event_gui_startup.active myclient.domain.de false Avec la configuration event_gui_startup=false il n y a pas de connexion à opsi-configserver et aucune installation de logiciel au démarrage. A l exception des installations en cours, qui continuent au démarrage du système. Cela est géré par la configuration event_on_shutdown{installation_pending}. Donc, ne modifiez pas les paramètres pour les sections avec la condition installation_pending, car ils sont importants pour les produits qui demandent un redémarrage lors de l installation. 5.4.6 Fichier de log local Au cours de l installation lors de l arrêt, un fichier de log est écrit: C:\opsi.org\tmp\doinstall.log avec, en cas de succès, le contenu suivant: doinstall32.cmd started The current date is:.tue 02/012/2013 Enter the new date: (mm-dd-yy) Backend connected. modules: passed first checkpoint. Modules file signature verified (customer: my company) Check completed. Event fired Task completed. Ce fichier de log est réécrit à chaque fois et peut être vérifiée dans le cas d un dysfonctionnement.

Opsi 4.0.3 Notes de version 12 / 34 Chapitre 6 La fonctionnalité opsi SilentInstall La fonctionnalité opsi SilentInstall fournit aux administrateurs la possibilité d installer un logiciel sur un client sans que l utilisateur connecté soit dérangé. Ce chapitre décrit les caractéristiques de cette fonctionnalité et propose des lignes directrices pour la configuration de cette nouvelle méthode d installation. 6.1 Conditions préalables à l installation en mode silencieux Pour utiliser cette fonctionnalité, est requise la version opsi 4.0.3. ou au-dessus, et pour opsi-client-agent est requise la version 4.0.3.1 ou au-dessus. 6.2 Vue d ensemble de la fonctionnalité SilentInstall La méthode d installation silencieuse offre la possibilité d installer une liste prédéfinie de produits sur un client, sans que l utilisateur ait à interrompre son travail. Contrairement à l installation ondemand (l installation poussée), la méthode SilentInstall n affiche rien sur le bureau de l utilisateur. Tous les affichages sont supprimées, et ne seront pas vus sous tous les bureaux. Bien sûr, cette fonctionnalité porte un certain risque. En cas de problème, ex. une erreur de syntaxe du script opsi-winst, il n y a aucun moyen d interagir avec le processus d installation, aucune boîte de dialogue sera présentés. Donc cela se traduirait par le fait que le traitement de l événement par opsi-winst ne s achève pas, et donc, aucun autre événement ne sera plus exécuté. Pour éviter ce "Scénario le plus défavorable", le temps d installation maximale est limitée par un délai d attente dans la configuration. Cette valeur de temporisation peut être adapté dans le cas d une installation prolongée. Pour plus d informations, voir le chapitre sur la configuration. Une autre possibilité très importante de cette fonctionnalité est la liste prédéfinie de produits destinés à être installés en mode silencieux. Un contact avec le service est établi, mais différemment de la procédure habituelle, les ActionRequests proposée par le service sont ignorés. La liste des logiciels à installer est définie par une configuration de opsi-client-agent configuration. L action "setup" sera exécutée pour tous les produits figurant sur cette liste sans qu ils soient mis à setup. Comme d habitude, après le traitement du script de configuration, le script de mise à jour également sera exécuté, si celui-ci existe. Les dépendances de produits ne seront pas résolues. Donc, aucun produit contenant des dépendances d autres produits doit être installé par la fonctionnalité SilentInstall, ou sinon tous les produits de la liste de dépendance doivent être ajoutés à la liste des produits SilentInstall. Comme d habitude, le processus d installation se termine en envoyant l état d installation et les fichiers de log de l installation au service. En résumé, il est recommandé d utiliser le SilentInstall que pour les produits qui satisfont aux exigences suivantes: petits paquets ou installations singulières peu de charge du système: certaines installations de logiciels, donc la plupart par exemple des installations MSI, il demandent pendant l installation la plupart des ressources client. Il pourrait en résulter un mauvais rendement du système pour l utilisateur.

Opsi 4.0.3 Notes de version 13 / 34 installable dans un laps de temps fixe: le délai d attente par défaut pour cet événement est de 300 secondes. Si le processus d installation n est pas terminée dans le délai, le processus opsi-winst sera terminé et donc l événement pourra être complété. pas de redémarrage nécessaire: sde logiciels demandant un redémarrage ne devrait pas être installés à partir du SilentInstall. Avec la configuration par défaut, l événement est configuré pour ne pas traiter toutes les demandes de redémarrage. Sans cette configuration de sécurité opsi-client-agent pourrait redémarrer le client sans aucun avertissement à l utilisateur. Cela pourrait entraîner une perte de données si il y a un utilisateur connecté. Il pourrait en résulter un logiciel inutilisable installé par SilentInstall sans redémarrage. Dans la configuration par défaut swaudit et hwaudit sont installés par ce procédé. Les produits d inventaire de OPSI, il satisfont à toutes les exigences ci-dessus et sont donc applicables pour cette méthode. Avec la configuration par défaut, les inventaires matériels et logiciels OPSI sont générés à la demande, sans la nécessité d établir la demande d action d installation avec opsi-configed. Avec cette méthode, les informations d inventaire peuvent être générés en temps réel. Également applicable à tout produit de configuration, qui effectuent des réparations automatiques ou des restaurations de correctifs client. 6.3 Exécution de l installation silencieuse Cet événement ne se déclenche pas automatiquement comme les autres événements. Il y a donc deux manières de réaliser cet événement. La première voie est de déclencher l événement à partir du webservice opsi, comme par exemple: opsi-admin -d method hostcontrol_fireevent silent_install client.domain.local Donc cette commande est scriptable, et peut être utilisé dans des scripts qui peut être combiné avec un at-job pour planifier l exécution de l événement. Comme alternative, l événement peut être déclenché par un événement programmé, après un certain laps de temps. La configuration par défaut pour cet événement est de 6 heures. Cette valeur suppose qu un poste de travail est habituellement utilisé pendant 8 heures. Donc l événement sera exécuté une fois par jour au bout de six heures de temps de fonctionnement. Pour plus d informations sur la configuration et l activation de cet événement, voir le chapitre suivante. 6.4 Configuration de la fonctionnalité opsi: SilentInstall Ce chapitre traite de la configuration par défaut de cette fonctionnalité. Par défaut opsiclientd.conf possède événement SilentInstall. Cette liste indique uniquement les options importantes: événement 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 propriété importante pour le contrôle des événements. Pour tous les événements qui exécutent des actions de produits, cette option permet de définir une liste de produits. La liste des produits doit être donnée sous forme de liste séparée par des virgules. process_shutdown_request = false Cette configuration supprime les demandes de redémarrage de opsi-winst. action_processor_command

Opsi 4.0.3 Notes de version 14 / 34 Cette configuration prépare l appel à opsi-winst. action_processor_desktop Cette option définit le bureau pour afficher l interface graphique opsi-winst. action_processor_timeout Cette option définit le délai d attente pour terminer le processus opsi-winst. Le deuxième événement est l événement de temporisation, qui déclenche l événement après un certain laps de temps: Événement de temporisation par défaut pour SilentInstall [event_timer_silentinstall] super = silent_install type = timer active = false interval = 21600 super Cette option définit à partir de quel événement hériter les propriétés. Par défaut il hérite de l événement silent_install. type Cette option définit que l événement est un Timer-Event. active par défaut cet événement n est pas actif. Pour l activer, réglez cette option sur true. interval Cette option définit l intervalle pour déclencher l événement. La valeur par défaut est 6 heures, donc au bout de six heures de temps de fonctionnement l événement est déclenché pour la première fois, puis tous les six autres heures. Donc cet intervalle devrait (comme n importe quel intervalle de temporisation) ne pas être trop court, autrement, l événement sera effectué la plupart du temps, en bloquant ainsi l exécution d autres actions. D autre part, l intervalle ne devrait pas être trop long, pour que opsi-client-agent soit exécuté tout ce temps, jusqu à ce que l événement est déclenché. Si le client ou opsi-client-agent sont toujours redémarrés avant que l intervalle est écoulé, cet événement ne sera jamais déclenché. En outre, l événement SilentInstall pourrait être déclenché par un autre événement système, détectée par une demande WMI. Donc une option wql peut être spécifiée. Comment spécifier l option wql doit être vu dans la section event_net_connection. Si l option wql est utilisée, l événement doit être réglé sur active = false par défaut, de sorte qu il peut être activé suite à la demande. Pour déclencher l événement par un temporisateur, en général il suffit de définir un paramètre hôte. Donc, une configuration par défaut doit être d abord créée. Dans ce cas, il suffit d activer la temporisation de l événement. Pour créer l option standard, les suivants opsi-config-objects doivent être créées 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 événement est désactivée pour tous les clients. Ensuite, l événement peut être activé pour les clients individuels: opsi-admin -d method configstate_create opsiclientd.event_timer_silentinstall.active silentclient.domain.de true Pour définir les produits à installer, l entrée suivante doit être définie. Si, par exemple, au lieu de swaudit et hwaudit doit être installé le produit firefox, les entrées devraient être créée tel que décrit ci-dessus:

Opsi 4.0.3 Notes de version 15 / 34 opsi-admin -d method config_createunicode opsiclientd.event_silent_install.action_processor_productids "\ event_silent_install productids" "swaudit,hwaudit" Avec cette option par défaut pour tous les clients la liste des produits pour l événement SilentInstall est défini sur swaudit et hwaudit. Pour modifier la liste des produits pour un seul client en firefox exécutez 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 différente pour chaque client.

Opsi 4.0.3 Notes de version 16 / 34 Chapitre 7 Protect your CI changes from updates: le répertoire custom (disponible depuis la version opsi-client-agent 4.0.2.3) Le répertoire custom peut être utilisé pour protéger vos modifications de configuration au cours des mises à jours de opsi-client-agent: (/opt/pcbin/install/opsi-client-agent/files/opsi/custom). Au cours de mises à jour de opsi-client-agent sur le serveur, le répertoire custom sera sauvegardé et restauré après la mise à jour, afin que vos modifications persistent. custom/cfg/config.ini Les valeurs de ce fichier de configuration, remplacent les valeurs par défaut de cfg/config.ini. À l exception des valeurs de pckey et bootmode, qui ne sont pas repris à partir de ce fichier. Ajoutez à votre fichier de configuration personnalisée uniquement ces valeurs, qui sont différents des paramètres par défaut. custom/winstskin/*.* Tous les fichiers de ce répertoire seront copiées vers les clients, dans le répertoire C:\Program Files (x86)\opsi. org\opsi-client-agent\custom\winstskin lors de l installation de opsi-client-agent sur le client. Ce répertoire winstskin, s il existe, depuis la version 4.11.3.4 de opsi-winst, est le préféré. Il doit contenir tous les fichiers et les configurations nécessaires de winstskin, pour que le contenu du répertoire par défaut soit ignorée. custom/notifier/*.* Tous les fichiers de ce répertoire seront copiées vers les clients, dans le répertoire C:\Program Files (x86)\opsi. org\opsi-client-agent\notifier lors de l installation de opsi-client-agent et remplaceront les fichiers côté serveur du répertoire files/opsi/dist/notifier/. custom/opsiclientd.conf S il existse, custom/opsiclientd.conf sera copié sur les clients, dans le répertoire C:\Program Files (x86)\ opsi.org\opsi-client-agent\opsiclientd lors de l installation de opsi-client-agent et remplacera le fichier par défaut opsiclientd.conf du répertoire files/opsi/dist/opsiclientd/ sur le serveur. Ainsi, le fichier personnalisé opsiclientd.conf doit contenir tous les entrées de configuration nécessaires. Attention: L utilisation d un fichier personnalisé opsiclientd.conf n est pas recommandée. Pour personnaliser la configuration de votre client, utilisez le paramètre de configuration hôte pour les fonctions simples telles que décrites dans le chapitre opsi-client-agent. L utilisation d un fichier personnalisé opsiclientd.conf s applique seulement pour les configurations très complexes. En utilisant un fichier personnalisé opsiclientd.conf, après chaque mise à jour de opsi-client-agent, sera nécessaire vérifier sur le serveur le fichier par défaut files/opsi/dist/opsiclientd/ opsiclientd.conf pour apporter les nécessaires corrections dans votre fichier personnalisé opsiclientd.conf. Donc: les mains au large de cette fonction, sauf si vous savez vraiment ce que vous faites!

Opsi 4.0.3 Notes de version 17 / 34 Chapitre 8 Adaptations des méthode byaudit pour l intégration des drivers Certains fabricants utilisent des codes d identification de modèles comprenant des caractères spéciaux, qui ne peuvent pas être utilisés dans les noms de fichiers et de répertoires. Par exemple, une identification du modèle : "5000/6000/7000". Le slash ne peut pas être utilisé pour les noms de répertoires valides. Donc depuis la release opsi 4.0.3 les caractères spéciaux suivants: < >? " : \ / * intérieurement seront remplacés par un trait de soulignement _. Ainsi, l exemple précédent, sera remplacé par : "5000_6000_7000" et le répertoire sera automatiquement attribué, bien que les informations contenues dans l inventaire matériel différent.