opsi Linux Support
Unterstützt als opsi-client: Linux
Stand 01.10.2023
Distribution | OS Installation | Netboot Products | Client Agent |
---|---|---|---|
Debian 12 Bookworm |
|
||
Debian 11 Bullseye |
|
||
Debian 10 Buster |
|
||
Debian 9 Stretch |
|
||
Debian 8 Jessie |
|
||
Ubuntu 24.04 LTS Noble Numbat |
|
||
Ubuntu 22.04 LTS Jammy Jellyfish |
|
||
Ubuntu 20.04 LTS Focal Fossa |
|
||
Ubuntu 18.04 LTS Bionic Beaver |
|
||
Linux Mint 22 |
|
||
Linux Mint 21.3 |
|
||
Linux Mint 21.2 |
|
||
Linux Mint 21.1 |
|
||
Linux Mint 21 |
|
||
Linux Mint 20.3 |
|
||
Linux Mint 20.2 |
|
||
Linux mint 20.1 |
|
||
RHEL 9 |
|
||
RHEL 8 |
|
||
RHEL 7 |
|
||
AlmaLinux 9 |
|
||
AlmaLinux 8 |
|
||
Rocky Linux 9 |
|
||
Rocky Linux 8 |
|
||
Oracle Linux 9 |
|
||
Oracle Linux 8 |
|
||
CentOS 8 |
|
||
CentOS 7 |
|
||
SLES 15 SP5 |
|
||
SLES 15 SP4 |
|
||
SLES 15 SP3 |
|
||
SLES 15 SP2 |
|
||
SLES 15 SP1 |
|
||
SLES 12 SP5 |
|
||
SLES 12 SP4 |
|
||
SLES 12 SP3 |
|
||
SLES 12 SP2 |
|
||
SLES 12 SP1 |
|
||
SLES 12 |
|
||
openSUSE Leap 15.6 |
|
||
openSUSE Leap 15.5 |
|
||
openSUSE Leap 15.4 |
|
||
openSUSE Leap 15.3 |
|
||
UCS 5.0 |
|
||
UCS 4.4 |
|
: Supported : Unsupported : Under development : Discontinued
Stand 01.10.2023
Netboot Product | Installer | State | Remark |
---|---|---|---|
|
opsi |
Stretch - Bullseye |
|
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
opsi |
Focal - Noble |
|
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
||
|
Distribution |
: Supported : Unsupported : Under development : Discontinued
Vorbedingungen für den opsi Linux Support
Technische Voraussetzungen sind opsi 4.0.5 mit den Paketständen:
opsi-Paket | Version |
---|---|
opsi-linux-bootimage |
>= 20140805-1 |
Der opsi Support für Linux besteht aus einem Teil, der von Anfang an Opensource ist (den Netbootprodukten) und einem kofinanzierten Teil (dem Agent für die Clients).
Dieser opsi-linux-client-agent ist eine
opsi Erweiterung.
Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details hierzu finden Sie in Freischaltung kostenpflichtiger Module.
opsi-linux-client-agent: 15 Freistarts
Der opsi-linux-client-agent beinhaltet 15 Freistarts bei denen der Agent auch ohne Freischaltung verwendet werden kann.
Genauer formuliert: Nach der initalen Installation des opsi-linux-client-agent kann der der opsi-script 15 mal im Servicekontext gestartet werden ohne eine Freischaltung zu fordern.
Dies gibt Ihnen die Möglichkeit einen Linuxrechner aufzusetzen und mit den entsprechenden opsi-Produkten für den geplanten Einsatz zu konfigurieren.
Beispielsweise können Sie nach der Installation das Produkt l-opsi-server
aufrufen, um aus dem frisch installierten Rechner einen opsi-server zu machen.
Für eine dauerhafte Pflege des installierten Linuxrechners über diese 15 Freistarts hinaus benötigen Sie aber eine Freischaltung dieses Features.
Installieren der Pakete
Die Linux-bezogenen Pakete können über den opsi-package-updater
geladen werden.
Im Auslieferungszustand hat dieser bereits das Repository für die Linux-Produkte aktiviert.
Sie können mit dem folgenden Aufruf die opsi-linux Produkte einspielen:
opsi-package-updater -v --repo uib_linux install
Einführung
Ein Management-Werkzeug für Windows und Linux
Ziel der Erweiterung von opsi um die Unterstützung von Linux-Systemen ist die Schaffung eines Managementsystems für heterogene Umgebungen. Der Fokus liegt dabei auf der möglichst vollständigen Integration beider Welten in die gleichen Management-Vorgänge und Werkzeuge.
Dies bedeutet, dass eine Linux-Installation auf die gleiche Weise angestoßen wird wie eine Windows-Installation.
Der opsi-client-agent unter Linux basiert auf dem selben Code wie der unter Windows und ist (soweit sinnvoll) befehlskompatibel.
Linux-Distributionsübergreifend
Der Linux-Support von opsi ist distributionsübergreifend angelegt.
Die folgenden Distributionen werden gleichwertig unterstützt:
-
Debian
-
Ubuntu
-
Linux Mint
-
OpenSuse / SLES (Suse Linux Enterprise Server)
-
RHEL (RedHat Enterprise Linux)
-
Alma Linux 8
-
Rocky Linux 8
-
CentOS
-
UCS
Bitte beachten Sie das für eine Linux Mint Installation mindestens 4GB RAM in der Maschine bzw. VM verügbar sein müssen.
Installation eines neuen Linux PC über opsi (OS-Installation)
Linux Netboot Produkte auf Basis des Distributionseigenen Installers
-
Ähnlich wie bei der Windows-Installation wird für den Installer eine Antwortdatei bereit gestellt, welche vom Installer zur nichtinteraktiven Installation genutzt wird.
-
Der distributionseigene Installer ist nicht wie bei Windows ein Programm das aufgerufen wird, sondern in einer Kombination aus distributionseigenem Kernel und initrd implementiert.
-
Die gesamte Grundinstallation - inklusive Partitionierung, LVM, Basissoftware, etc. - liegt in der Hand des Installers und wird nicht mehr durch das bootimage durchgeführt.
-
Bei den Suse- und RedHat-artigen Distributionen werden die Installationsquellen von Ihnen bereitgestellt, in dem Sie die Installations-DVD als ISO-Datei auf dem Depotshare ablegen. Dieses Verfahren ähnelt der Situation unter Windows, nur dass der Ablageort ein anderer ist und dass Sie bei Windows den Inhalt der Installations-DVD ablegen anstatt einer ISO-Datei.
-
Für eine Linux Mint Installation in Version 4.2.0.1-6 und früher wird der Inhalt der offiziellen Installations Medien über einen NFS Server benötigt. Ab Version 4.2.0.2-1 wird ein ISO Image in das Produktunterverzeichnis
iso
gespeichert. -
Bei den Debian-artigen werden die Installationsquellen aus dem Netz verwendet. Auf dem Depotshare liegen nur die Netboot Versionen von Distributionskernel und dazugehörigem initrd. Da diese Dateien nicht groß sind, werden sie im opsi-Paket mitgeliefert.
Das Paketubuntu22-04
erwartet ein ISO Image im Produktunterverzeichnisiso
und liefert selbst keinen Distributionskernel und dazugehöriges Initrd mehr mit. -
Zur weiteren Pflege der Installation kann der opsi-linux-client-agent im Rahmen der Basisinstallation mit installiert werden.
Abläufe der neuen Installationsmimik:
-
Das opsi-linux-bootimage wird gebootet, löscht die Partitionstabelle und erstellt eine kleine temporäre Hilfsparition.
-
Das opsi-linux-bootimage holt sich das distributionseigene initrd und entpackt es auf der Hilfspartition.
-
Das opsi-linux-bootimage holt sich die generische Vorlage für die Antwortdatei, patcht (personalisiert) diese und legt sie dann in das initrd Verzeichnis.
-
Das opsi-linux-bootimage erstellt weitere Hilfscripte und Konfigurationsdateien (z.B. zur Installation des opsi-linux-client-agent) und legt sie dann in das initrd Verzeichnis.
-
Das opsi-linux-bootimage packt das gepatchte initrd Verzeichnis wieder zusammen.
-
Das opsi-linux-bootimage bootet den Distributions-Kernel mit dem gepatchten initrd per kexec.
-
Das so geladene System installiert das Zielsystem unattended und installiert abschließend den opsi-linux-client-agent.
Die Vorteile dieses Vorgehens sind:
-
Die Installation findet exakt gemäß den Anforderungen des Distributors statt. Dies ist immer ein Vorteil, aber natürlich im Unternehmensumfeld als Ausgangsbedingung für Supportverträge besonders wichtig.
-
Die Integration neuer Releases in opsi wird einfacher und dadurch schneller.
-
Bei den Suse- und RedHat-artigen, Linux Mint Distributionen und Ubuntu 22-04 findet die Installation aus auf dem opsi-Server liegenden Installationsquellen statt und ist damit schneller und unempfindlicher gegen Störungen als beim Zugriff auf Repositories aus dem Internet.
Bereitstellung und der Installationsmedien auf dem Server per NFS
Dies betrifft die RedHar-artigen Distributionen vor Version 4.2.0.3-1, die SLES-artigen Distributionen vor Version 4.2.0.2-1 und Linux Mint vor 4.2.0.2-1. Im Anschluss an die NFS-Server Variante, wird die neuartige Variante erklärt.
Die Bereitstellung der Installationsmedien für die Suse-, RedHat und Linux Mint-artigen Distributionen erfolgt auf einem nfs share: opsi_nfs_share
.
Zur Einrichtung des shares muss ein NFS-Server auf dem opsi-server installiert und konfiguriert sein.
Seit opsi v4.0.6 wird dies über ein gesondertes Paket opsi-linux-support
erfolgen. Dieses Paket wird nicht per default installiert und muss einmalig nachinstalliert werden.
Auf Debian-artigen Betriebssystemen kann das durch den folgenden Befehl erreicht werden:
apt install opsi-linux-support
Beim Einsatz einer Firewall auf Ihrem Server muss diese noch so konfiguriert werden, dass TCP-Verbindungen auf Port 80 akzeptiert werden. Bitte konsultieren Sie hierzu das entsprechende Handbuch.
Was dieses Paket macht, ist (als händige Anleitung) im Folgenden beschrieben:
-
Auf dem opsi-server muss das entsprechende NFS-Server-Paket installiert sein. Auf Debian, Ubuntu, Suse ist dies das Paket:
nfs-kernel-server
. Auf Centos, Redhat ist es das Paketnfs-utils
. -
Der Export
opsi_nfs_share
muss angelegt und exportiert werden:-
Verzeichnis erzeugen:
mkdir -p /var/lib/opsi/depot/opsi_nfs_share
-
In der Datei
/etc/exports
den Eintrag:
/var/lib/opsi/depot/opsi_nfs_share *(ro,no_root_squash,insecure,async,subtree_check)
erzeugen. -
Das Aktivieren des Exports wird mit dem folgenden Befehl ausgelöst:
exportfs -r
-
Zur Kontrolle des erfolgreichen Exports den folgenden Befehl aufrufen:
showmount -e localhost
Die Ausgabe sollte sein:
Export list for localhost:
/var/lib/opsi/depot/opsi_nfs_share *
-
-
Der share
opsi_nfs_share
hat folgenden Verzeichnisaufbau:
opsi_nfs_share/<productId>/<arch>/<dvd>.iso
zum Beispiel:
opsi_nfs_share/opensuse53-2/64/openSUSE-15.2-DVD-x86_64.iso
Die Installationsdatei muss als Dateiendung.iso
haben, der Rest ist egal. Liegen in einem Verzeichnis mehrere.iso
Dateien so ist nicht definiert welche verwendet wird.
Eine Ausnahme hierzu bildet das Netboot Produkt mint20-X. Hierfür ist es nötig den gesamten Inhalt, auch versteckte Verzeichnisse, in den entsprechendenopsi_nfs_share
Unterordner zu kopieren. -
Kopieren Sie die Installations-DVD an den entsprechenden Platz im
opsi_nfs_share
und führen Sie aus:
opsi-set-rights /var/lib/opsi/depot/opsi_nfs_share
WICHTIG: Verwenden Sie die Standard Installations-DVD’s der Distribution. Modifizierte Installations DVD’s haben eventuell einen anderen Aufbau und funktionieren nicht. -
Sollten Sie aus irgendwelchen Gründen das Verzeichnis
/var/lib/opsi/depot/opsi_nfs_share
nicht vom opsi-server aus per NFS exportieren können (z.B. weil der Depotshare vom opsiserver per NFS von einem NAS eingebunden ist), so kann der zu verwendende NFS-share über ein Serverweites config angegeben werden. Z.B.clientconfig.opsi_nfs_share=172.16.166.1:/var/lib/opsi/depot/opsi_nfs_share
-
Beim Produkt
ubuntu22-04
muss die .iso Datei im Produktverzeichnis im Unterverzeichnisiso
hinterlegt werden.
Bereitstellung und der Installationsmedien auf dem Server per opsifond WebDAV
Dies betrifft die RedHar-artigen Distributionen ab Version 4.2.0.3-1, die SLES-artigen Distributionen ab Version 4.2.0.2-1 und Linux Mint ab 4.2.0.2-1.
Die RedHat- und SUSE-artigen Distributionen, sowie Linux Mint und Ubuntu22-04 nutzen seit den oben genannten Versionen keinen NFS-Server mehr zur Verteilung der Installationsmedien. Vielmehr gibt es in den jeweiligen Produktverzeichnissen ein Unterverzeichnis iso
bzw. isocontent
.
In das iso
Verzeichnis wird das ISO Image abgelegt. Das isocontent
Verzeichnis beinhaltet den Inhalt eines ISO Images, analog zum installfiles
Verzeichnis eines Windows Netboot Pakets.
Hier ein Beispiel anhand des SLES15-3 Produktes.
mount SLE-15-SP3-Full-x86_64-GM-Media1.iso /mnt
cp -r /mnt/* /var/lib/opsi/depot/sles15-3/isocontent/
cp /mnt/.treeinfo /var/lib/opsi/depot/sles15-3/isocontent/
cp /mnt/.discinfo /var/lib/opsi/depot/sles15-3/isocontent/
umount /mnt
Hinweis: Die Datei .discinfo
ist nicht bei allen Distributionen vorhanden und kann dementsprechend fehlen.
Allgemeine Properties der opsi Linux Netboot Produkte mit distributions Installer
Die folgenden Properties finden Sie zur Steuerung der Linuxinstallation in allen v406 Netbootprodukten:
-
askbeforeinst
:
Soll das Starten der Installation am Client bestätigt werden müssen? (Default='true') -
architecture
:
Mit welcher Architektur soll das Zielsystem installiert werden?
Beeinflusst außerdem das verwendete Bootimage. (Default='64bit') -
language
oderlocale
:
Welche Sprache / locale soll installiert werden. (Default=Distributionsabhängig / 'de') -
console_keymap
: (nicht unter ubuntu22-04!)
Zu installierendes Tastaturlayout. (Default=Distributionsabhängig / 'de') -
timezone
:
Welche Zeitzone soll verwendet werden?. (Default='Europe/Berlin') -
root_password
:
Passwort für root. (Default='linux123') -
user_password
:
Passwort für user. (Default='linux123') -
proxy
:
Proxystring (wenn benötigt) in der Form: 'http://<ip>:<port>'. (Default='') -
install_opsi-client-agent
:
Installiere den opsi-client-agent für Linux (Kofinanzierungsprojekt: Sie benötigen eine Aktivierung durch die /etc/opsi/modules). (Default='true') -
setup_after_install
:
Welche opsi-Produkte sollen zum Abschluss der Betriebssysteminstallation auf setup gestellt werden. (Default='')
Die Produkte: debian10, debian11 und ubuntu18-04, ubuntu20-04, ubuntu22-04 und mint20-1, mint20-2, mint20-3, mint21
Die Basis-Installation erfolgt direkt aus dem Netz, mit Ausnahme vom Netboot Paket ubuntu22-04. Hier muss zusätzlich im Produktverzeichnis im Unterverzeichnis iso ein ISO abbild hinterlegt werden. Bei ubuntu16-04 ist auch eine Installation von einem lokalen Repository möglich.
Bedingt durch den Wechsel des verwendeten Installers sind nicht alle aufgeführten Properties im Netboot Paket ubuntu22-04 (und neuer) enthalten. Die entsprechenden Properties haben jeweils einen Hinweis auf das Fehlen im Netboot Paket ubunut22-04
Das Produkt hat produktiven Status.
Das Produkt hat folgende zusätzliche Properties:
-
online_repository
:
Repository der Distribution für die Installation. (Nur bei Debian/Ubuntu Produkten) (Default=Distributionsabhängig) -
encrypt_password
: (nicht unter ubuntu22-04!)
Passwort für die Festplattenverschlüsselung (nur verwendet wenn encrypt_logical_volumes=true)
Example:linux123
Default:linux123
-
installation_method
:
Methode zur Installation des Installers. Funktioniert nur mit der UEFI Erweiterung:
reboot
: Es wird eine kleine Partition angelegt und nach einem Reboot wird der Installer von dieser Partition gestartet. /kexec
: Das opsi-linux-bootimage startet den Installer direkt per kexec, es erfolg kein Reboot. Possible: "reboot", "kexec"
Default:kexec
-
partition_disk
: (nicht unter ubuntu22-04!)
Zu verwendende Festplatte:first
oder kompletter device path (nicht unter ubuntu22-04!) Examples: "first", "/dev/sda", "/dev/sdb"
Default:first
-
preseed
: (unter ubuntu20-04autoinstall
)
Zu verwendende Autonstallationsdatei. Diese muss sich im Produktverzeichnis im Unterordnercustom
befinden. Examples: "auto", "raid.cfg", "raid.yml" (ubuntu22-04
Default:auto
-
partition_method
:
Methode zur Partitionierung der Festplatte:
regular
: Standard Partionierung (unter ubuntu22-04:direct
)/lvm
: LVM’s anlegen /crypto
: In einer verschlüsselten Partition LVM’s anlegen (nicht unter ubuntu22-04!)
Possible: "regular" oder "direct", "lvm", "crypto"
Default:lvm
-
partition_recipe
: (nicht unter ubuntu22-04!)+ Die Art der verwendeten Partitionierung:
atomic
: Alles in einer Partition /home
: eigene /home Partition /multi
: eigene /home, /usr, /var, und /tmp Partitionen Possible: "atomic", "home", "multi"
Default:atomic
-
desktop_package
:
Zu installierendes desktop package (standard = kein desktop) (Nur bei Debian/Ubuntu Produkten). Possible: "standard", "ubuntu-desktop", "kubuntu-desktop", "lubuntu-desktop", "xubuntu-desktop", "ubuntu-gnome-desktop"
Default:standard
-
language_packs
: (nicht unter ubuntu22-04!)+ Possible: "ar", "bg", "by", "cf", "de", "dk", "en", "es", "et", "fa", "fi", "fr", "gr", "il", "it", "kg", "kk", "lt", "mk", "nl", "no", "pl", "ro", "ru", "sg","sr", "ua", "uk", "us", "wo"
Default:de
Folgende Videos zeigen jeweils eine Installation.
Sie sind mit einem Frame pro Sekunde aufgenommen und dadurch schneller anzusehen als die Installation eigentlich dauert.
Das Produkt ucs44
Die Basis-Installation bezieht ihre Pakete von den offiziellen UCS Repositories. Eine Installation mit lokalen Paketquellen ist ebenfalls möglich.
Dieses Produkt hat einen produktiven Status.
Mit diesem Produkt ist es möglich, einen Master-, Slave-, Backup, und einen Member-Server zu installieren. Wir empfehlen das l-opsi-server Produkt, um aus einer UCS Maschine auch einen opsi-Server zu machen. Dieses Produkt ermöglicht es auch Clients über einen Member-Server zu installieren, hierfür werden einige Besonderheiten durchgeführt.
Das Produkt hat über die oben genannten Properties eines z.B debian8 Produktes noch die folgenden zusätzlichen UCS spezifischen Properties:
-
dns_domain
:
Der DNS Domain Name:
Example:example.com
Default:ucs.test
-
ldap_base
:
ldap base. Example:dc=example,dc=com
Default:dc=ucs,dc=test
-
ucs_code_name
:
Der Codename der UCS-Version, welche im onlien Repository bereit gestellt wird.
Example:ucs414
Default:ucs414
-
organisation
:
Der Name der Organisation der bei der UCS Installation verwendet wird.
Example:uib gmbh
Default:uib gmbh
-
windomain
:
Der Name der Samba/Windows Domain.
Example:MYDOMAIN
Default:MYDOMAIN
-
external_nameserver
:
Welcher externe Nameserver soll bei der Installation verwendet werden ?
Example:10.11.12.13
Default:auto
= the name server given by dhcp -
ucs_master_ip
:
Die IP-Nummer des UCS Domain Controller (wird beim joinen von anderen Rollen verwendet) ?
Example:10.10.10.10
Default:10.10.10.10
-
ucs_master_admin_password
:
Das Administrator Passwort des UCS Domain Controller (wird beim joinen von anderen Rollen verwendet) ?
Example:linux123
Default:linux123
-
ucs_role
:
Welche UCS Rolle soll installiert werden ?
Possible: "domaincontroller_master", "domaincontroller_backup", "domaincontroller_slave", "memberserver", "base"
Default:domaincontroller_master
Die Produkte sles12sp3, sles12sp4, sles12sp5, sles15-1, sles15-2, sles15-3, sles15-4 und opensusel15-3, opensusel15-4
Das Produkt hat folgende zusätzliche Properties:
name: productkey multivalue: False editable: True description: email:regcode-sles for suse_register. Is only used if the host parameter `license-management.use` is set to false . If it set to True the license key will be get from the license management module. / La clé de licence pour l'installation. Est utilisée uniquement si dans "Réseau et paramètres supplémentaires" `license-management.use` est défini à false (faux) . Si c'est réglé sur True (vrai) la clé de licence sera obtenue du module de gestion des licences. values: ["", "myemail@example.com:xxxxxxxxxxxxxx"] default: [""] name: suse_register description: set to false, if you don't want to register your system online, if you set this to false you have to give local repositories default: True name: local_repositories multivalue: True editable: True description: list of local repositories to use. Syntax: "repository description", example entry: "http://sles.example.com/suse/repo NameForRepo" values: [""] default: [""] name: install_unattended description: If false then do interactive installation default: True
Zum herunterladen der Installations DVD brauchen Sie einen Account bei SUSE.
Vor Version 4.2.0.2-1:
ISO-File kopieren nach /var/lib/opsi/depot/opsi_nfs_share/sles15-3/64/
Nach Version 4.2.0.2-1
ISO Inhalt kopieren nach /var/lib/opsi/depot/sles15-3/isocontent/
Ausführung von opsi-set-rights
nicht vergessen.
Folgendes Video zeigt eine Installation.
Es ist mit einem Frame pro Sekunde aufgenommen und dadurch schneller anzusehen als die Installation eigentlich dauert.
Die Produkte redhat8, redhat9 und rocky8, rocky9 und alma8, alma9
Das Produkt hat folgende zusätzliche Properties:
name: install_unattended description: If false then do interactive installation default: True name: selinux_mode multivalue: False editable: False description: In which mode should SELinux run ? values: ["enforcing", "permissive", "disabled"] default: ["permissive"] name: partition_method multivalue: False editable: False description: plain: Regular partitions with no LVM or Btrfs. / lvm: The LVM partitioning scheme. / btrfs: The Btrfs partitioning scheme. / thinp: The LVM Thin Provisioning partitioning scheme. values: ["plain", "lvm", "btrfs", "thinp"] default: ["lvm"] name: productkey multivalue: False editable: True description: email:regcode for subscription_register. Is only used if the host parameter `license-management.use` is set to false . If it set to True the license key will be get from the license management module. / La clé de licence pour l'installation. Est utilisée uniquement si dans "Réseau et paramètres supplémentaires" `license-management.use` est défini à false (faux) . Si c'est réglé sur True (vrai) la clé de licence sera obtenue du module de gestion des licences. values: ["", "myemail@example.com:xxxxxxxxxxxxxx"] default: [""] name: subscription_register description: set to false, if you don't want to register your system online, if you set this to false you have to give local repositories default: True
Laden sie das ISO Image bitte herunter, z.B. hier here.
Vor Version 4.2.0.3-1
ISO Datei hierhin kopieren /var/lib/opsi/depot/opsi_nfs_share/alma8/64/
Nach Version 4.2.0.3-1
Den Inhalt der ISO kopieren nach /var/lib/opsi/depot/alma8/isocontent/
Bitte nicht vergessen opsi-set-rights
auszuführen.
Zum Download der ISO benötigen sie einen RedHat Account.
Vor Version 4.2.0.3-1
ISO Datei hierhin kopieren /var/lib/opsi/depot/opsi_nfs_share/redhat8/64/
Nach Version 4.2.0.3-1
Den Inhalt der ISO kopieren nach /var/lib/opsi/depot/redhat8/isocontent/
Bitte nicht vergessen opsi-set-rights
auszuführen.
Laden sie das ISO Image bitte herunter, z.B. hier here.
Vor Version 4.2.0.3-1
ISO Datei hierhin kopieren /var/lib/opsi/depot/opsi_nfs_share/rocky8/64/
Nach Version 4.2.0.3-1
Den Inhalt der ISO kopieren nach /var/lib/opsi/depot/rocky8/isocontent/
Bitte nicht vergessen opsi-set-rights
auszuführen.
Folgende Videos zeigen eine Installation.
Sie sind mit einem Frame pro Sekunde aufgenommen und dadurch schneller anzusehen als die Installation eigentlich dauert.
Linux Netboot Produkte mit generischem (also ohne distributionseigenen) Installer
Basis-Installation des OS per Netboot
Für die Installation eines Linux Basissystems wird zunächst per Netboot das Standard opsi-linux-bootimage gebootet (welches auch für die Windows-Installationen zum Einsatz kommt).
Von diesem Bootimage aus wird die Ziel-Festplatte partitioniert (/ und swap) und formatiert. Nun folgt die Installation des Grundsystems (mit Netzwerkkonfiguration und ssh aber ohne X11). Die Abläufe dieser Grundinstallation unterscheiden sich naturgemäß zwischen den unterschiedlichen Distributionen erheblich. Gemeinsam ist, dass die Installation direkt aus den Originalpaketen der Distribution erfolgt.
Optional kann nun der opsi-client-agent für Linux installiert werden. Dieser ist dann für die Installation und Konfiguration weiterer Software zuständig.
Die opsi-Netboot-Produkte zur Linuxinstallation sind bereits als Open Source freigegeben.
Bedingt dadurch, dass die Basisinstallation aus dem Standard opsi-linux-bootimage erfolgt, gibt es distributionsabhängig unterschiedlich bestimmte Dinge, welche sich erst in der Umgebung nach dem ersten Boot des Systems konfigurieren bzw. installieren lassen. Beispiele hierfür sind die SELinux-Installation bei den 'RedHat artigen' bzw. die Konfiguration der Tastatur bei den 'Debian artigen'. Hierfür gibt es ein Standard Localbootprodukt l-os-postinst
welches diese Aufgaben übernimmt.
Allgemeine Properties der Linux Netboot Produkte mit generic Installer
Die folgenden Properties finden Sie zur Steuerung der Linuxinstallation in allen Netbootprodukten:
-
askbeforeinst
:
Soll das Starten der Installation am Client bestätigt werden müssen? (Default='true') -
architecture
:
Mit welcher Architektur soll das Zielsystem installiert werden?
Beeinflusst die Auswahl des bootimages und die Installationsarchitektur. (Default='64bit') -
system_partition_size
:
Größe der Systempartition. Die Größe kann in Prozent der Festplattengröße oder als absoluter Wert (G=Gigabyte) angegeben werden. Wenn Sie einen kleineren Wert als 100% angeben, wird der verbleibende Rest als Datenpartition verwendet (wenn das Property data_partion_create = true). (Default='100%') -
swap_partition_size
:
Größe der Swappartition. (Default='2000M') -
data_partition_create
:
Verwende freien Plattenplatz zur Erstellung einer Datenpartition. (true/false). (Default='true') -
data_partition_preserve
:
Soll eine existierende Datenpartition erhalten werden ?
always = Installation abbrechen wenn der Erhalt einer gefundenen Partition mit dem Label 'data' mit den angegebenen Partitionierungsdaten nicht möglich ist.
if_possible = Wird eine Partition mit dem Label 'data' gefunden und der Erhalt dieser Partition ist gemäß der angegebenen Partionierungsdaten nicht möglich, so wird die Partition gelöscht.
never = Die gesamte Partitionstabelle wird immer neu geschrieben. (Default='never') -
language
:
Welche Sprache / locale soll installiert werden. (Default='de') -
console_keymap
:
Zu installierendes Tastaturlayout. (Default=Distributionsabhängig / 'de') -
timezone
:
Welche Zeitzone soll verwendet werden?. (Default='Europe/Berlin') -
root_password
:
Passwort für root. (Default='linux123') -
user_password
:
Passwort für user. (Default='linux123') -
online_repository
:
Repository der Distribution für die Installation. (Nicht bei SLES) (Default=Distributionsabhängig) -
proxy
:
Proxystring (wenn benötigt) in der Form: 'http://<ip>:<port>'. (Default='') -
additional_packages
:
Welche zusätzlichen Pakete sollen installiert werden? Angabe der Pakete Leerzeichen separiert. (Default='') -
wget_and_execute
:
Url (http) einer Datei welche am Ende der Installation geholt und ausgeführt wird. (Default='') -
install_opsi-client-agent
:
Installiere den Linux opsi-client-agent (Kofinanzierungsprojekt: Sie benötigen eine Aktivierung durch die /etc/opsi/modules) . (Default='false') -
release
:
(nur Debian und Ubuntu)
Welches Release der Distribution soll installiert werden. (Default=Distributionsabhängig) -
setup_after_install
:
Welche opsi Produkte sollen zum Abschluss der Betriebssysteminstallation auf setup gestellt werden. (Default='l-os-postinst')
Ubuntu
Die Basis Installation erfolgt per debootstrap direkt aus dem Netz.
Das Produkt hat produktiven Status.
Das Produkt ist UEFI/GPT kompatibel.
Es gibt für diese Produkt passende opsi-server Pakete, welche über 'install_opsi_server=true' installiert werden können.
Debian
Die Basis Installation erfolgt per debootstrap direkt aus dem Netz.
Das Produkt hat produktiven Status.
Das Produkt ist UEFI/GPT kompatibel.
Es gibt für diese Produkt passende opsi-server Pakete, welche über 'install_opsi_server=true' installiert werden können.
opsi-linux-client-agent
Der opsi-client-agent für Linux ist Bestandteil des Kofinanzierungsprojektes 'Linux Agent' und derzeit kostenpflichtig.
Ein Rechner kann nicht gleichzeitig am selben 'opsi-configserver' Client und Server (z.B. 'opsi-depot' / 'opsi-configserver') sein. Dies ist ein Problem mit der derzeitigen Datenstruktur in opsi und wird zu einem späteren Zeitpunkt gelöst. Ein 'opsi-configserver' kann sich also auch nicht selbst als Client haben. Es ist aber durchaus möglich einen Linuxclient als opsi-Server zu installieren der dann selber als 'opsi-configserver' agiert oder als 'opsi-depot' für einen anderen 'opsi-configserver'. Wenn Sie auf diese Weise einen opsi-Server aufgesetzt haben und wollen diesen als Depotserver an dem 'opsi-configserver' registrieren an dem diese Maschine auch Client ist, müssen Sie den Rechner als Client vorher löschen. |
Der opsi-client-agent für Windows besteht im Kern aus den Komponenten:
-
dem Service
opsiclientd
-
dem Actionprocessor
opsi-script / opsi-script-nogui
Der opsi-client-agent für Linux basiert auf einer Portierung des Windows-Clientagenten nach Linux.
Die Aufgaben des opsiclientd
beim Systemstart sind:
-
Kontakt mit dem opsi-Server: Prüfen ob Aktionen gesetzt sind
-
Mounten des Depot Shares
-
Gegebenenfalls Updaten des Actionprocessors
-
Starten des Actionprocessors
-
Unmount des Depot Shares
-
Senden der Logdatei an den Server
Der Actionprocessor heißt unter Linux opsi-script und ist aus den selben Quellen gebaut wie unter Windows. Damit steht unter Linux die gleiche Scriptsyntax zur Verfügung wie unter Windows. Weiterhin sind alle nicht plattformspezifischen Funktionen umgesetzt wie z.B:
-
File handling
-
String und Stringlisten Funktionen
-
Ausführen von externen Scripten und Programmen
-
Kommunikation mit dem opsi-Server
-
Patchen von Konfigurationsdateien
Natürlich gibt es unter Linux keine Funktionen zum Patchen der Registry, dafür aber neue linuxspezifische Funktionen wie z.B.:
-
getLinuxDistroType
-
getLinuxVersionMap
Das Logging des opsi-script ist analog zur dem unter Windows.
Anders als bei Windows gibt es den opsi-script neben einer grafischen Version für die Arbeit unter X-Windows zusätzlich in einer Version 'no-gui' für Systeme ohne grafische Oberfläche.
opsi-linux-client-agent: Installation: service_setup.sh
Diese Methode dient zur Installation auf einzelnen Rechnern. Für ein Massen-Rollout siehe weiter unten.
-
Loggen Sie sich mit
root
Rechten auf dem Client ein. -
Mounten Sie den share
//<opsiserver>/opsi_depot
an eine beliebige Stelle. -
Wechseln Sie in das Verzeichnis
opsi-linux-client-agent
auf dem gemounteten share -
Starten Sie dort das Script
./service_setup.sh
Das Skript nimmt per opsi-Webservice Kontakt zum Server auf, um serverseitig den Client zu erzeugen und den pckey zu erfahren. Dies erfolgt zunächst mit einer user/password Kombination, die aus mehreren möglichen Konfigurationsdateien auszulesen versucht wird. Schlägt dies fehl, so erscheint ein Login mit der Frage nach client-id, Service-URL, user und password. Dort kann die Operation mit den Accountdaten eines Mitglieds der Gruppe opsiadmin-Gruppe autorisiert werden.
opsi-linux-client-agent: Installation: opsi-deploy-client-agent
Das opsi-deploy-client-agent
verteilt den opsi-client-agent direkt vom opsi-Server auf die Clients.
Voraussetzung hierfür sind bei den Clients:
-
ssh Zugang als root oder als user, welcher
sudo
ausführen darf.
Das Skript erzeugt serverseitig den Client, kopiert die Installations-Dateien und Konfigurationsinformationen, wie bspw. den pckey, auf den Client und startet dort die Installation.
Mit dem opsi-deploy-client-agent
kann auch eine ganze Liste von Clients bearbeitet werden.
Dazu können entweder beliebig viele Clients als letzter Parameter übergeben werden oder mit der Option '-f' die Clients aus einer Datei eingelesen werden.
Bei der Verwendung einer Datei, muss in jeder Zeile ein Client stehen.
Das Programm kann mit IP-Adressen, Hostnamen und FQDNs arbeiten. Es versucht automatisch zu erkennen welche Art von Adresse übergeben wurde.
Das Skript findet sich unter '/var/lib/opsi/depot/opsi-linux-client-agent'
Führen Sie das Programm mit 'root' Rechten aus oder als user, der Teil der Gruppe "opsifileadmins" ist
bonifax:/var/lib/opsi/depot/opsi-linux-client-agent# ./opsi-deploy-client-agent --help
usage: opsi-deploy-client-agent [-h] [--version] [--verbose]
[--debug-file DEBUGFILE] [--username USERNAME]
[--password PASSWORD]
[--use-fqdn | --use-hostname | --use-ip-address]
[--ignore-failed-ping]
[--reboot | --shutdown | --start-opsiclientd | --no-start-opsiclientd]
[--hosts-from-file HOSTFILE]
[--skip-existing-clients]
[--threads MAXTHREADS] [--depot DEPOT]
[--group GROUP] [--smbclient | --mount]
[--keep-client-on-failure | --remove-client-on-failure]
[host [host ...]]
Deploy opsi client agent to the specified clients. The c$ and admin$ must be
accessible on every client. Simple File Sharing (Folder Options) should be
disabled on the Windows machine.
positional arguments:
host The hosts to deploy the opsi-client-agent to.
optional arguments:
-h, --help show this help message and exit
--version, -V show program's version number and exit
--verbose, -v increase verbosity (can be used multiple times)
--debug-file DEBUGFILE
Write debug output to given file.
--username USERNAME, -u USERNAME
username for authentication (default:
Administrator).Example for a domain account: -u
<DOMAIN>\\<username>
--password PASSWORD, -p PASSWORD
password for authentication
--use-fqdn, -c Use FQDN to connect to client.
--use-hostname Use hostname to connect to client.
--use-ip-address Use IP address to connect to client.
--ignore-failed-ping, -x
try installation even if ping fails
--reboot, -r reboot computer after installation
--shutdown, -s shutdown computer after installation
--start-opsiclientd, -o
Start opsiclientd service after installation
(default).
--no-start-opsiclientd
Do not start opsiclientd service after installation.
--hosts-from-file HOSTFILE, -f HOSTFILE
File containing addresses of hosts (one per line).If
there is a space followed by text after the address
this will be used as client description for new
clients.
--skip-existing-clients, -S
skip known opsi clients
--threads MAXTHREADS, -t MAXTHREADS
number of concurrent deployment threads
--depot DEPOT Assign new clients to the given depot.
--group GROUP Assign fresh clients to an already existing group.
--smbclient Mount the client's C$-share via smbclient.
--mount Mount the client's C$-share via normal mount on the
server for copying the files. This imitates the
behaviour of the 'old' script.
--keep-client-on-failure
If the client was created in opsi through this script
it will not be removed in case of failure. (DEFAULT)
--remove-client-on-failure
If the client was created in opsi through this script
it will be removed in case of failure.
opsi-linux-client-agent: Installation: Durch die opsi netbootprodukte
Wenn Sie ein Linux über die opsi-Netboot-Produkte installieren, wird der opsi-linux-client-agent automatisch mit installiert, wenn das Property install_opsi-client-agent
auf 'true' steht.
opsi-linux-client-agent: opsiclientd Konfiguration
Der opsiclientd
für Linux ist eine Portierung des opsiclientd für Windows und arbeitet mit einer analogen Konfigurations Datei: /etc/opsi-client-agent/opsiclientd.conf
.
Eine ausführliche Beschreibung dieser Konfiguration findet sich im Kapitel zum opsi-client-agent: opsi-client Konfiguration
Dabei sind nicht alle Features und Events auch unter Linux verfügbar.
Verfügbar sind:
-
Start beim Systemstart (bzw. start des
opsiclientd
) unter Linux ist der Name des Eventsopsiclientd_start
(und nichtgui_startup
) -
event_on_demand
-
Das
event_timer
aber nur mit der Einstellung:super = default
Nicht verfügbar sind (derzeit):
-
Alles was mit dem lokalen Cache ('WAN-Erweiterung') zu tun hat.
-
Das
event_net_connection
-
Das
event_on_shutdown
-
Das
event_silent_install
opsi-linux-client-agent: Pfade
Der opsi-linux-client-agent legt Dateien an folgenden Orten ab:
Die Binaries (bzw symlinks auf binaries):
/usr/bin/opsi-script
/usr/bin/opsiclientd
Die Hilfsdateien für den opsi-script finden sich in:
Skindateien:
/opt/opsi-script/skin
custom : /usr/share/opsi-script/customskin
opsi-script Library:
/opt/opsi-script/lib
Translation Dateien:
/opt/opsi-script/locale/opsi-script.po
Die Konfigurationen:
/etc/opsi-client-agent/opsiclientd.conf
(Konfiguration des opsiclientd)
/etc/opsi-script/opsi-script.conf
(Konfiguration des opsi-script)
Logdateien sind zu finden unter:
/var/log/opsi-client-agent
/var/log/opsi-client-agent/opsiclientd
/var/log/opsi-script/
opsi-linux-client-agent: Known Bugs
Das Kopieren von vielen Dateien von einem Samba3-Share ist abhängig von der Samba-Version fehlerhaft. Es werden nicht alle Dateien kopiert. Das Problem wurde bei Samba4 Shares bisher nicht beobachtet.
Als Workaround kann statt:
[Files_copy_netboot]
copy -s "%scriptPath%/installfiles/*" "$target$/installfiles/"
das folgende verwendet werden:
[ShellScript_opsi_copy_netboot]
set -x
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
cd "%scriptPath%"
tar cf - installfiles | ( cd "$target$/installfiles/" ; tar xf - )
Beispiel Scriptteile
Unter Windows gilt für die Softwareverteilung: Die Installation von Software ist genauso wichtig wie die anschließende Konfiguration der Software.
Unter Linux stehen die meisten Pakete über die Repositories der Distribution zur Verfügung. Dadurch wird der Installationsanteil kleiner, der Konfigurationsanteil aber bleibt. Weiterhin gibt es auch Applikationen, welche nicht über die Standardrepositories verfügbar sind.
Hier müssen unter Umständen zunächst weitere Repositories dem System hinzugefügt werden bzw. Installationsquellen dem Paket zugefügt werden.
Wichtig ist, dass alle Installations- und Konfigurationsarbeiten zentral vom opsi-Server gesteuert und dort auch geloggt werden.
Im folgenden finden Sie Beispiele für folgende Aufgaben in einem beispielhaften Script für den opsi-linux-client-agent:
-
Beenden wenn es nicht unter Linux läuft
-
Feststellen des Distributionstyps zur Entscheidung zwischen
apt
,zypper
undyum
-
Feststellen der genauen Linux Version
-
Installation eines Paketes
-
Hinzufügen eines Repositories
Beispiel: Beenden wenn es nicht unter Linux läuft:
[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off
DefVar $OS$
set $OS$ = GetOS
if not($OS$ = "Linux")
LogError "Wrong OS: Product: " + $ProductId$ + " is only for Linux"
isFatalError "Wrong OS"
endif
Beispiel: Feststellen des Distributionstyps:
[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off
DefVar $distrotype$
set $distrotype$ = getLinuxDistroType
if $distrotype$ = 'debian'
Message "Try to get Package Lock..."
if waitForPackageLock("60","false")
comment "we got the package lock."
else
LogError "could not get Package Lock"
isFatalError "package lock failed"
endif
ShellScript_Upgrade_deb
else
LogError "Wrong Distro: This Product is for Debian/Ubuntu only"
isFatalError "Wrong distro"
endif
if not("0" = getLastExitCode)
Message "failed ShellScript_Upgrade"
LogError "failed ShellScript_Upgrade"
isFatalError "failed Upgrade"
endif
[ShellScript_Upgrade_deb]
set -x
export DEBIAN_FRONTEND=noninteractive
apt update
apt --yes dist-upgrade
exit $?
Beispiel: Feststellen der genauen Linux Version und Installation eines Paketes:
[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off
DefVar $distCodeName$
DefVar $distroName$
DefVar $distRelease$
DefVar $desktop$
DefStringList $linuxInfo$
set $linuxInfo$ = getLinuxVersionMap
set $distCodeName$ = getValue("Codename", $linuxInfo$)
set $distRelease$ = getValue("Release", $linuxInfo$)
set $distroName$ = getValue("Distributor ID", $linuxInfo$)
set $desktop$ = GetProductProperty("desktop", "kde")
if $distrotype$ = 'suse'
if $desktop$ = "unity"
Message " No Unity on SUSE - fallback to KDE ..."
set $desktop$ = "kde"
endif ; unity
Message "Try to get Package Lock..."
if waitForPackageLock("60","false")
comment "we got the package lock."
else
LogError "could not get Package Lock"
isFatalError "package lock failed"
endif
if $desktop$ = "kde"
if ($distroName$ = 'openSUSE project')
ShellScript_kde_suse
endif
if ("SUSE LINUX" = $distroName$) and ($distRelease$ = "11")
ShellScript_kde_sles11
endif
if not("0" = getLastExitCode)
LogError "failed ShellScript"
Message "failed kde"
isFatalError "failed kde"
endif
endif ; kde
endif; suse type
[ShellScript_kde_suse]
set -x
zypper --no-gpg-checks --non-interactive install patterns-openSUSE-kde4 patterns-openSUSE-kde4_basis
zypper --no-gpg-checks --non-interactive install splashy-branding-openSUSE
exit $?
[ShellScript_kde_sles11]
set -x
zypper --no-gpg-checks --non-interactive install --auto-agree-with-licenses -t pattern kde
exit $?
Beispiel: Hinzufügen eines Repositories:
[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off
DefVar $distCodeName$
DefVar $distroName$
DefVar $distRelease$
DefVar $desktop$
DefStringList $linuxInfo$
set $linuxInfo$ = getLinuxVersionMap
set $distCodeName$ = getValue("Codename", $linuxInfo$)
set $distRelease$ = getValue("Release", $linuxInfo$)
set $distroName$ = getValue("Distributor ID", $linuxInfo$)
set $desktop$ = GetProductProperty("desktop", "kde")
if $distroName$ = 'Ubuntu'
if $desktop$ = "cinnamon"
set $desktopPackage$ = $desktop$
Message "Try to get Package Lock..."
if waitForPackageLock("60","false")
comment "we got the package lock."
else
LogError "could not get Package Lock"
isFatalError "package lock failed"
endif
ShellScript_ubuntu_cinnamon
if not("0" = getLastExitCode)
Message "failed ShellScript_ubuntu_cinnamon"
LogError "failed ShellScript_ubuntu_cinnamon"
isFatalError "failed cinnamon"
endif
endif ; cinnamon
endif; ubuntu
[ShellScript_ubuntu_cinnamon]
set -x
export DEBIAN_FRONTEND=noninteractive
# we need to get the add-apt-repository command
apt --yes --force-yes install python-software-properties
# the cinnamon repository
add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-stable
apt update
apt --yes install ubuntu-desktop
exit $?
Viele dieser und einige weitere nützliche Funktionen sind in der opsi-script standard-Bibliothek uib_lin_install.opsiscript enthalten.
Linux Localboot Produkte
Hier einige Lokalbootprodukte, welche zum Standardumfang des opsi Linuxsupports gehören.
Das Produkt l-opsi-server
Das Produkt 'l-opsi-server' dient dazu, automatisiert auf einer Linuxmaschine per opsi-linux-client-agent einen opsi-server zu installieren. Dies kann dazu dienen, um schnell einen neuen opsi-depot-server zu installieren oder z.B. ein opsi Testsystem.
Derzeit kann eine Maschine nicht gleichzeitig am selben opsi-configserver
opsi-client und opsi-depot-server sein. Sie haben derzeit zwei Möglichkeiten mit dieser Beschränkung umzugehen: 1. Verwendung von einem opsi-configserver: Wenn also ein per 'l-opsi-server' installierter opsi-server zum Depotserver an seinem Config-Server werden soll, so müssen Sie vorher im configed die Maschine als Client löschen. 2. Verwendung von zwei opsi-configservern: Sie setzen für die Verwaltung Ihrer opsi-server einen zweiten, unabhängigen opsi-configserver auf, welcher nur dazu dient die anderen opsi-server zu installieren und zu pflegen. Dieser zweite opsi-configserver kennt die anderen opsi-server also nur als Clients, während der bisherige (erste) opsi-configserver die anderen opsi-server nur als Depots (oder garnicht) kennt. In UCS Umgebungen wird Methode 2 empfohlen und der zweite opsi-configserver darf keine UCS Maschine sein. |
Das Produkt 'l-opsi-server' hat folgende Properties:
-
opsi_online_repository
:
(Basis-) Repository für die opsi-server installation.
(Default="https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/")
siehe auch 'repo_kind' -
opsi_noproxy_online_repository
:
(Basis-) Repository für die opsi-server installation (ohne cache proxy).
(Default="https://download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/")
Sollten Sie beiopsi_online_repository
einen Proxy oder deb-cacher mit angegeben haben (z.B. 'http://mydeb-cacher:9999/download.opensuse.org/repositories/home:/uibmz:/opsi:/4.2:/"), dann geben Sie hier die URL nochmal ohne den Proxy an. Ansonsten geben Sie hier das selbe an wie beiopsi_noproxy_online_repository
. -
repo_kind
:
Welche Repository Art ["experimental", "stable", "testing"] soll zur Installation verwendet werden ?. (Default='stable')
Aus dem Client OS, 'opsi_online_repository' und 'repo_kind' wird die URL zusammengebaut, welche verwendet wird, um dem Client ein opsi Repository hinzuzufügen. -
backend
:
Welches Backend soll installiert werden ? (Die Auswahlmysql
benötigt die Hinterlegung einer gültigen Freischaltdatei). (Default='file')
Eine modules Datei mit den benötigten Freischaltungen kann im custom Verzeichnis des Produktes abgelegt werden. Wird dort eine modules gefunden so wird diese verwendet. -
opsi_admin_user_name
:
Unter welchen Namen soll ein opsi_admin_user erzeugt werden (empty= kein user wird erzeugt). (Default='adminuser')
Wird hier ein user angegeben, so wird dieser angelegt, wird Mitglied der Gruppen 'opsiadmin', 'pcpatch'/'opsifileadmin' und bekommt als unix- und samba Passwort den Wert vonopsi_admin_user_password
-
opsi_admin_user_password
:
Was ist das Passwort für den opsi_admin_user (empty= nicht erlaubt). (Default='linux123')
sieheopsi_admin_user_name
-
setup_after_install
:
Welche opsi Produkte sollen nach der Installation von l-opsi-server installiert werden ?. (Default="") -
allow_reboot
:
Darf die Maschine nach der Installation von l-opsi-server rebootet werden ?. (Default='true') -
myipname
:
Soll ein abweichender IP-Name (FQDN) bei der Installation verwendet werden ? ('auto'= use standard) (Default='auto')
sieheinstall_and_configure_dhcp
-
myipnumber
:
Soll eine abweichende IP-Nummer bei der Installation verwendet werden ? ('auto'= use standard) (Default='auto')+ sieheinstall_and_configure_dhcp
-
install_and_configure_dhcp
:
Soll ein DHCP-Server auf der Maschine installiert und konfiguriert werden ?. (Default='False')
Wenn dieses Property 'false' ist, so werden die Properties: 'netmask', 'network','dnsdomain','nameserver' und 'gateway' nicht beachtet, da diese nur der DHP Konfiguration dienen. -
netmask
:
Netmask (für dhcp). (Default="255.255.0.0")
Nicht verwendet wenn 'install_and_configure_dhcp=false' -
network
:
Netzwek Adresse (für dhcp). (Default="192.168.0.0")
Nicht verwendet wenn 'install_and_configure_dhcp=false' -
dnsdomain
:
DNS domain (for dhcp). (Default="uib.local")
Nicht verwendet wenn 'install_and_configure_dhcp=false' -
nameserver
:
Primary nameserver (für dhcp). (Default="192.168.1.245")
Nicht verwendet wenn 'install_and_configure_dhcp=false' -
gateway
:
gateway (option routers for dhcp). (Default="192.168.1.245")
Nicht verwendet wenn 'install_and_configure_dhcp=false' -
ucs_master_admin_password
:
Passwort des users 'Administrators' auf dem UCS-Master.
Wird nur für UCS-Server benötigt und hier nur für alle Rollen außer 'Master'. (Default='linux123') -
update_test
:
Nicht verwenden: Internal Debuging. (Default='False')
Das Produkt hat eine 'setup required before' Abhängigkeit zu dem Produkt 'l-system-update'. D.h. wenn Sie 'l-opsi-server' auf 'setup' stellen, wird automatisch 'l-system-update' auch auf setup gestellt und vorher installiert.
In dem Verzeichnis custom
des Produktes l-opsi-server
kann eine Freischaltdatei (modules
) abgelegt werden, welche bei der Installation durch das Produkt l-opsi-server
verwendet wird und beim Einspielen einer neuen Version des Produktes erhalten bleibt.
l-os-postinst für v4.0.5 Netboot installationen
Dieses Produkt übernimmt jene Teile der Basisinstallation, welche sich vom Bootimage nicht korrekt ausführen lassen.
Dies ist für die unterschiedlichen Distributionen:
-
CentOS:
-
Installation von SELinux
-
Das Produkt hat eine Abhängigkeit zu dem Produkt 'l-system-update', welches vor dem Lauf von 'l-os-postinst' aufgerufen wird.
Das Produkt hat eine hohe Priorität, d.h. es wird vor 'normalen' Produkten ausgeführt.
l-desktop
Das Produkt l-desktop installiert einen Desktop auf dem Rechner.
Über das Property desktop
kann der zu installierende Desktop ausgewählt werden. Dabei ist zu beachten, das nicht alle Desktops auf allen Distributionen verfügbar sind. So gibt es z.B. 'Unity' nur unter Ubuntu. Wird ein nicht verfügbarer Desktop gewählt so wird ein Distributionsspezifischer Defaultdesktop installiert. Weiterhin haben die Desktop Pakete einen unterschiedlichen Umfang, welcher abhängig von Distribution und Desktop sich auf die eigentliche Desktop Software beschränken kann oder auch Basisprodukte wie libreoffice, firefox, PDF-Reader usw. enthalten kann.
Das Property desktop
hat folgende Werte:
-
Gnome
Default für Debian, CentOS, RHEL
Verfügbar auf allen Distributionen. -
KDE
Default für SLES, OpenSuse Verfügbar auf allen Distributionen. -
Unity
verfügbar nur für Ubuntu -
Cinnamon
verfügbar nur für Ubuntu -
xfce4
Verfügbar auf Ubuntu, Debian. -
lxde
Verfügbar auf Ubuntu, Debian.
Inventarisierung
Zur Inventarisierung werden die Daten durch den Clientagenten erhoben und an den Server gesendet. Die Hardwareinventarisierung basiert auf den schon im Bootimage implementierten Methoden.
Die Softwareinventarisierung basiert auf den Daten des Paketmanagements der verwendeten Distribution.
UEFI / GPT Unterstützung
Die Meisten der opsi 4.1 / opsi 4.2 Linux Netbootprodukte sind UEFI/GPT kompatibel. Details siehe hierzu in der obigen Auflistung der Netbootprodukte.