forum.opsi.org

Verfasst: **11 Aug 2010, 22:27**

Hallo,

zum Testen habe ich mich für eine frische Installation aus dem Debian-Repository entschieden.
Zunächst mal muss ich sagen, dass schon die Beta-Version eine hervorragende Arbeit ist

Als Server habe ich in einer virtuellen Maschine Ubuntu Lucid 10.04 ohne grafische Oberfläche installiert.
Zunächst ist mir aufgefallen, dass das Paket "opsi-depotserver" eine Abhängigkeit zum Paket "dhcp3-server" hat.
Da ich einen externen DHCP-Server betreibe, benötige ich auf dem OPSI-Server keinen. Hier wäre doch eine Paket-Empfehlung besser geeignet.

Nach der Installation der benötigten Pakete fiel mir auf, dass der opsiconfd nicht gestartet ist und sich über /etc/init.d/opsiconfd auch nicht starten ließ.
Die opsiconfd.log zeigte folgendes:

Code: Alles auswählen

==================================================================
=             opsi configuration service starting                =
==================================================================
 (Logger.py|774)
[5] [Aug 11 18:53:52] Starting opsiconfd main thread (opsiconfd.py|2096)
[5] [Aug 11 18:53:52] Added static content '/' which points to directory '/usr/share/opsiconfd/static' (opsiconfd.py|1969)
[5] [Aug 11 18:53:52] Running on depot server 'opsi4.test.intern', exporting repository directory (opsiconfd.py|1983)
[2] [Aug 11 18:53:52] Traceback: (Logger.py|707)
[2] [Aug 11 18:53:52]      line 2101 in 'run' in file '/usr/lib/pymodules/python2.6/opsiconfd/opsiconfd.py' (Logger.py|707)
[2] [Aug 11 18:53:52]      line 1992 in '_createSite' in file '/usr/lib/pymodules/python2.6/opsiconfd/opsiconfd.py' (Logger.py|707)
[2] [Aug 11 18:53:52]      ==>>> Cannot add webdav content 'repository': permissions on directory '/var/lib/opsi/repository' not sufficient. (opsiconfd.py|2110)

Das Problem konnte mit dem Befehl "sudo opsi-setup --set-rights" gelöst werden. Der Dienst startete nun ohne Probleme.
Es wäre natürlich schön, wenn die Rechte schon bei der Paketinstallation korrekt eingestellt sind.

Desweiteren habe ich bis jetzt folgende Pakete erfolgreich getestet:

Code: Alles auswählen

   Product ID                Version                   Name                                                                                     
   =============================================================================================================================================
   hwaudit                   4.0-1                     Client Hardwareinventarisierung                                                          
   hwinvent                  4.0-1                     Hardware Inventarisierung                                                                
   ntfs-restore-image        1.5-1                     NTFS Image zurueckschreiben                                                              
   ntfs-write-image          1.5-1                     NTFS Image sichern                                                                       
   opsi-client-agent         4.0-1                     opsi.org client agent                                                                    
   opsi-winst                4.10.8.1-1                winst                                                                                    
   shutdownwanted            1.0-2                     shutdown wanted                                                                          
   winxppro                  4.0-1                     Windows XP professional - x86 - deutsch

Da ich mit einer Volumen-Lizenz arbeite, möchte ich natürlich den Lizenzkey global für alle Clients festlegen. Bisher konnte ich dafür den Befehl 'opsi-admin -d method setProductProperty winxppro "productkey" "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx"' verwenden. Dieser zeigt allerdings keine Wirkung. Ein "opsi-admin -d method getProductProperties_hash winxppro" zeigt unveränderte Werte. Beim ersten Testclient habe dann die von mir benötigten Werte im Config-Editor eingegeben. Nun sind die Werte aber nicht nur für diesen einen Client gesetzt, sondern global.

Der Befehl 'opsi-admin -d method setProductProperty winxppro "askbeforeinst" "false"' gab folgende Fehlermeldung aus:

Code: Alles auswählen

[2] Traceback: (Logger.py|707)
[2]      line 1509 in '<module>' in file '/usr/bin/opsi-admin' (Logger.py|707)
[2]      line 301 in 'main' in file '/usr/bin/opsi-admin' (Logger.py|707)
[2]      line 669 in 'execute' in file '/usr/bin/opsi-admin' (Logger.py|707)
[2]      ==>>> Failed to execute 'method setProductProperty winxppro askbeforeinst false': 'bool' object has no attribute 'lower' (opsi-admin|1519)
[3] Failed to write history file '/home/fisimania/.opsi-admin/history': [Errno 13] Permission denied: u'/home/fisimania/.opsi-admin/history' (opsi-admin|461)

Den Zugriffsfehler für den Ordner ".opsi-admin" konnte ich lösen, indem ich den ganzen Ordner gelöscht habe. Dieser wurde mit den Rechten für root geschrieben. Bei der nächsten Verwendung von opsi-admin wurde der Ordner korrekt angelegt. Ich denke mal, ich habe einmal den Befehl mit sudo ausgeführt. Hier wär ein Mechanismus gut, um sowas zu verhindern.
Der andere Fehler tritt nicht auf, wenn man den Befehl so schreibt: admin -d method setProductProperty winxppro "askbeforeinst" "False"
Also "False" groß schreiben.

Zu guter Letzt wäre es natürlich super, wenn die OPSI-Pakete signiert wären. Dann muss man bei der Installation und beim Update nicht immer die Sicherheitsfrage mit "Ja" beantworten.

Schöne Grüße

Verfasst: **12 Aug 2010, 09:55**

Hallo und vielen Dank für das Testen und den ausführlichen Bericht!

fisimania hat geschrieben: Zunächst mal muss ich sagen, dass schon die Beta-Version eine hervorragende Arbeit ist

Danke, das macht Mut

fisimania hat geschrieben: Zunächst ist mir aufgefallen, dass das Paket "opsi-depotserver" eine Abhängigkeit zum Paket "dhcp3-server" hat.
Da ich einen externen DHCP-Server betreibe, benötige ich auf dem OPSI-Server keinen. Hier wäre doch eine Paket-Empfehlung besser geeignet.

Das ist richtig, wir versuchen es den nicht-Linux-Experten etwas einfacher zu machen.
Es wird in Zukunft aber so etwas wie ein 'opsi-depotserver-minimal'-Paket geben.

fisimania hat geschrieben: Nach der Installation der benötigten Pakete fiel mir auf, dass der opsiconfd nicht gestartet ist und sich über /etc/init.d/opsiconfd auch nicht starten ließ.
Das Problem konnte mit dem Befehl "sudo opsi-setup --set-rights" gelöst werden. Der Dienst startete nun ohne Probleme.
Es wäre natürlich schön, wenn die Rechte schon bei der Paketinstallation korrekt eingestellt sind.

Das schauen wir uns nochmal an.

fisimania hat geschrieben: Da ich mit einer Volumen-Lizenz arbeite, möchte ich natürlich den Lizenzkey global für alle Clients festlegen.

Hier würde auch die Option "-p ask" des opsi-package-managers helfen...

fisimania hat geschrieben: Bisher konnte ich dafür den Befehl 'opsi-admin -d method setProductProperty winxppro "productkey" "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx"' verwenden.
Dieser zeigt allerdings keine Wirkung. Ein "opsi-admin -d method getProductProperties_hash winxppro" zeigt unveränderte Werte.

Richtig, hier verhält sich opsi 4 etwas anders.
Da schauen wir auch nochmal drauf.
Funktionieren sollte in jedem Fall:

Code: Alles auswählen

opsi-admin -d method setProductProperty winxppro "productkey" "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx" <fqdn des depotservers>

fisimania hat geschrieben: Beim ersten Testclient habe dann die von mir benötigten Werte im Config-Editor eingegeben. Nun sind die Werte aber nicht nur für diesen einen Client gesetzt, sondern global.

Das hört sich nicht so gut an...
Welche Version des opsi-configed wurde verwendet?

fisimania hat geschrieben: Der Befehl 'opsi-admin -d method setProductProperty winxppro "askbeforeinst" "false"' gab folgende Fehlermeldung aus:

Code: Alles auswählen

[2] Traceback: (Logger.py|707)
[2]      line 1509 in '<module>' in file '/usr/bin/opsi-admin' (Logger.py|707)
[2]      line 301 in 'main' in file '/usr/bin/opsi-admin' (Logger.py|707)
[2]      line 669 in 'execute' in file '/usr/bin/opsi-admin' (Logger.py|707)
[2]      ==>>> Failed to execute 'method setProductProperty winxppro askbeforeinst false': 'bool' object has no attribute 'lower' (opsi-admin|1519)
[3] Failed to write history file '/home/fisimania/.opsi-admin/history': [Errno 13] Permission denied: u'/home/fisimania/.opsi-admin/history' (opsi-admin|461)

Danke, ist gefixt und kommt mit dem nächsten Paket-Update

fisimania hat geschrieben: Zu guter Letzt wäre es natürlich super, wenn die OPSI-Pakete signiert wären. Dann muss man bei der Installation und beim Update nicht immer die Sicherheitsfrage mit "Ja" beantworten.

Stimmt.

Verfasst: **12 Aug 2010, 19:44**

j.schneider hat geschrieben: Funktionieren sollte in jedem Fall:
Code: Alles auswählen
opsi-admin -d method setProductProperty winxppro "productkey" "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx" <fqdn des depotservers>

Super. Der Befehl funktioniert

Und mit der neusten Version funktioniert es auch wieder ohne Angabe des Depotserver.

fisimania hat geschrieben: Beim ersten Testclient habe dann die von mir benötigten Werte im Config-Editor eingegeben. Nun sind die Werte aber nicht nur für diesen einen Client gesetzt, sondern global.

j.schneider hat geschrieben: Das hört sich nicht so gut an...
Welche Version des opsi-configed wurde verwendet?

Ich muss mich hier entschuldigen. Der Wert wurde doch nicht global gesetzt.
Eingesetzt wurde die Version 1.9.6.2-1+svn540~lucid

Der Befehl 'opsi-admin -d method setProductProperty winxppro "askbeforeinst" "false"' funktioniert nun mit der neusten Version ohne Probleme.

Weiter ist mir heute aufgefallen, dass wenn man im opsi-configed beim Produkt winxppro im Feld "Konfiguration für Client" auf den Button "Server-Defaults" klickt, eine Meldung aufpoppt mit folgendem Inhalt:

Code: Alles auswählen

key not valid: i386_dir

Wenn ich auf OK klicke, werden die Werte für den Client nicht auf den Server-Default zurückgesetzt.

Zum jetzigen Zeitpunkt verwende ich folgende Versionen:

Code: Alles auswählen

ii  opsi-atftp                      0.7.dfsg-1.4+svn22~lucid          advanced TFTP client
ii  opsi-atftpd                     0.7.dfsg-1.4+svn22~lucid          advanced TFTP server - opsi version with pcr
ii  opsi-depotserver                3.99.0-1+svn193~lucid             opsi depotserver configuration package
ii  opsi-linux-bootimage            20100715-1+svn131~lucid           Linux-Bootimage fuer das Softwareverteilungs
ii  opsi-utils                      3.99.0-1+svn168~lucid             opsi utils
ii  opsiconfd                       3.99.0.0-1+svn227~lucid           opsi configuration service
ii  opsipxeconfd                    3.99.0-1+svn58~lucid              opsi pxe configuration daemon
ii  python-opsi                     3.99.0.0-1+svn1089~lucid          opsi python library

Verfasst: **12 Aug 2010, 21:19**

Hallo!

fisimania hat geschrieben: Weiter ist mir heute aufgefallen, dass wenn man im opsi-configed beim Produkt winxppro im Feld "Konfiguration für Client" auf den Button "Server-Defaults" klickt, eine Meldung aufpoppt mit folgendem Inhalt:
Code: Alles auswählen
key not valid: i386_dir

Das war noch ein Problem im winxppro-Produkt.
Bitte noch einmal herunterladen (Versionsnummer ist unverändert):
http://download.uib.de/opsi4.0/products ... 4.0-1.opsi
und neu einspielen.

Gruß,
Jan Schneider

Verfasst: **16 Aug 2010, 20:43**

j.schneider hat geschrieben:Hallo!
Das war noch ein Problem im winxppro-Produkt.
Bitte noch einmal herunterladen (Versionsnummer ist unverändert):
http://download.uib.de/opsi4.0/products ... 4.0-1.opsi
und neu einspielen.

Nachdem ich das aktuelle Paket eingespielt habe, tritt der Fehler nicht mehr auf.

Nun kommt mir aber die Frage auf, was den eigentlich "Server-Defaults" sind.

Weder

Code: Alles auswählen

opsi-admin -d method setProductProperty winxppro "productkey" "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx" <fqdn des depotservers>

noch

Code: Alles auswählen

opsi-admin -d method setProductProperty winxppro "productkey" "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx"

noch

Code: Alles auswählen

opsi-package-manager -i winxppro_4.0-1.opsi -p ask

natürlich jeweils mit den richtigen Werten, ändern etwas an den sogenannten "Server-Defaults".

Verfasst: **17 Aug 2010, 14:10**

Die Server-Defaults sind in diesem Fall die Einstellungen der ProductProperties auf dem jeweiligen Depotserver.
Diese Defaults (im File Backend jetzt unter /var/lib/opsi/config/depots/<depotid>.ini) gelten für alle Clients die diesem Depot zugewiesen sind.

Verfasst: **17 Aug 2010, 19:56**

j.schneider hat geschrieben:Diese Defaults (im File Backend jetzt unter /var/lib/opsi/config/depots/<depotid>.ini) gelten für alle Clients die diesem Depot zugewiesen sind.

In der ini-Datei stehen auch die von mir gewünschten Einstellungen drin. Doch leider setzt ein Klick auf den Button "Server-Defaults" die Einstellungen wieder auf die Werte, welche bei der Installation bestehen. Also "xxxxx-xxxxx-xxxxx-xxxxx-xxxxx" im Productkey, fullname ist "Name" und orgname ist "Orgname".

Auszug aus der Depot-ini:

Code: Alles auswählen

[winxppro-install]
productkey = ["ABCDE-ABCDE-ABCDE-ABCDE-ABCDE"]
additional_drivers = [""]
i386_dir = ["i386"]
askbeforeinst = [false]
orgname = ["Testfirma"]
fullname = ["fisimania"]
store_i386 = [false]

Desweiteren bricht seit eben meine Clientinstallation mit folgender Fehlermeldung ab:

Code: Alles auswählen

list index out of range

bootimage.log im Anhang

Beim Paket wipedisk ist mir aufgefallen, dass man als Partition die Zahl 0 wählen kann. Laut Beschreibung soll dann die ganze Festplatte gelöscht werden. Hier kommt aber die Fehlermeldung, dass die Partition unbekannt ist.
Bei Auswahl einer gültigen Partitionsnummer läuft der Löschvorgang einwandfrei.

Verfasst: **23 Aug 2010, 10:48**

Das Problem mit den Netboot-Produkten ist auf das opsi-linux-bootimage zurückzuführen.
Leider ist im 4.0er Repository eine veraltete Version gelandet.
Diese ist nun aber durch die aktuelle (20100802) Version ersetzt worden.
Bitte auf die neue Version upgraden.

Code: Alles auswählen

apt-get update
apt-get upgrade

Das Problem mit den Server-Defaults resultiert aus einem Bug im configed, der gerade in Bearbeitung ist.
Den Fix werden wir noch in dieser Woche bereitstellen.

Verfasst: **24 Aug 2010, 21:49**

Hab nun ein Upgrade durchgeführt, aber der Fehler "list index out of range" ist leider immer noch da

Code: Alles auswählen

$ dpkg -l | grep opsi
ii  opsi-atftp                      0.7.dfsg-1.4+svn22~lucid          advanced TFTP client
ii  opsi-atftpd                     0.7.dfsg-1.4+svn22~lucid          advanced TFTP server - opsi version with pcr
ii  opsi-depotserver                3.99.0-1+svn194~lucid             opsi depotserver configuration package
ii  opsi-linux-bootimage            20100802-1+svn142~lucid           Linux-Bootimage fuer das Softwareverteilungs
ii  opsi-utils                      3.99.0-1+svn177~lucid             opsi utils
ii  opsiconfd                       3.99.0.0-1+svn247~lucid           opsi configuration service
ii  opsipxeconfd                    3.99.0-1+svn74~lucid              opsi pxe configuration daemon
ii  python-opsi                     3.99.0.0-1+svn1113~lucid          opsi python library

Verfasst: **25 Aug 2010, 10:48**

Könnten wir nochmal eine Bootimage-Log haben?

forum.opsi.org

Neuinstallation unter Lucid

Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid

Re: Neuinstallation unter Lucid