forum.opsi.org

Verfasst: **16 Nov 2011, 22:47**

Hallo!
Das Upgrade wurde auf einem Debian Server von 3.4-> 4.x auf der selben Maschine durchgeführt ...
gemäß Upgrade einer opsi 3.4 umgebung auf opsi 4.0 Anleitung durchgeführt.

(Das Filebackend wird verwendet ...)
Evtl. ist da was defekt, da beim Upgrade der Schritt fehlschlug:

#opsi-setup --update-file

Code: Alles auswählen

[5] [Nov 16 19:53:04] Loading backend config '/etc/opsi/backends/file.conf' (opsi-setup|1457)
[2] [Nov 16 19:53:04] Traceback: (Logger.py|742)
[2] [Nov 16 19:53:04]      line 3068 in '<module>' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Nov 16 19:53:04]      line 3042 in 'main' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Nov 16 19:53:04]      line 1466 in 'updateFileBackend' in file '/usr/bin/opsi-setup' (Logger.py|742)
[2] [Nov 16 19:53:04]      ==>>>[b] Detected a file ('/var/lib/opsi/config/config.ini') that should only be in opsi version 4.0, update denied! (opsi-setup|3076)
[/b]

auf einen Fehler lief ...
(Dei Daten des File Backends wurden mit tar gesichert, aber nicht zurückgesichert, da dies wenn ich das richtig verstanden habe nur bei einer anderen Maschine
nötig ist?)

Sowohl über https://opsiserver:4447/configed ...
(Java Verwaltungskonsole)
als auch über:

Code: Alles auswählen

#opsi-admin -d method setProductActionRequest swaudit pc8.domain.firma.com setup

[2] Traceback: (Logger.py|742)
[2]      line 1551 in '<module>' in file '/usr/bin/opsi-admin' (Logger.py|742)
[2]      line 304 in 'main' in file '/usr/bin/opsi-admin' (Logger.py|742)
[2]      line 672 in 'execute' in file '/usr/bin/opsi-admin' (Logger.py|742)
[2]      ==>>> Failed to execute 'method setProductActionRequest swaudit pc8.domain.firma.com setup': No option 'productType' in section: u'office-comp-pack-state' (opsi-admin|1561)

lässt sich nichts installieren ...

opsi-srv

Code: Alles auswählen

#dpkg -l | grep opsi
ii  opsi-atftpd                           0.7.dfsg-1.4               advanced TFTP server - opsi version with pcr
ii  opsi-configed                         4.0.1.16-1                 OPSI config editor
ii  opsi-depotserver                      4.0.1.10-1                 opsi depotserver configuration package
ii  opsi-linux-bootimage                  20110926-1                 opsi linux bootimage
ii  opsi-utils                            4.0.1.14-1                 opsi utils
ii  opsiconfd                             4.0.1.9-4                  opsi configuration service
ii  opsipxeconfd                          4.0.1.4-1                  opsi pxe configuration daemon
ii  python-opsi                           4.0.1.32-1                 opsi python library

#opsi-package-manager -lv
----------------------------------------
- opsisrv.domain.firma.com -
----------------------------------------
   Product ID                Version                   Name
   ===========================================================================
   7-zip                     7.465-1                   7-Zip Dateientpacker
   adobe-flashplayer         11.1.102.55-1             Adobe-Flashplayer-11
   office-comp-pack          1.0-1                     office-compatibility-pa
   opsi-client-agent         4.0.1-20                  opsi.org client agent
   opsi-winst                4.11.1.6-1                winst
   shutdownwanted            1.0-4                     shutdown wanted
   swaudit                   4.0-6                     Client software invento

Vielleicht hat jemand eine Idee?

Verfasst: **17 Nov 2011, 08:07**

Moinsens,

das war hoffentlich nicht das Produktivsystem?

Ich persönlich würde nun nochmal exakt nach dem Handbuch "Getting Started" vorgehen, wie es für Debian im Kapitel 2.1.2 beschrieben ist. Ggf. die Deinstallation und Neuinstallation der fehlerhaften Komponenten durchführen und das Ganze so betrachten, als hätte ich es komplett neu installiert. bzw. als würde ich es neu installieren. Also anschließend auch ein

Code: Alles auswählen

opsi-setup --init-current-config
opsi-setup --set-rights
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart

durchführen. Vorallem aber - und man neigt schnell dazu - würde ich auch die scheinbar unnötigen Schritte wie "hostname -f" nicht auslassen, denn nur was korrekt ist, kann keine Probleme verursachen.

Mir ging es nach einem Update von SuSE nix mehr und ich hatte quasi die gleichen Probleme, wenn sie auch etwas anders geartet waren. Die oben beschriebene Vorgehensweise löste meine Probleme.

Und damit andere nicht die Erfahrung machen (das könnten auch mal andere lesen, die sowohl auf Linux als auch opsi neu sind) niemals auf einem Echtsystem sofort die Änderungen durchführen, sondern immer auf einem geklonten System.

Gruß

Thomas_H

Verfasst: **17 Nov 2011, 14:22**

Thomas_H hat geschrieben:Moinsens,

das war hoffentlich nicht das Produktivsystem?

Natürlich produktiv;-). Dachte ich spar mir die Zeit für den Test in der VM,
da ja nur das relativ simple File-Backend verwendet wird ...

Ich persönlich würde nun nochmal exakt nach dem Handbuch "Getting Started" vorgehen, wie es für Debian im Kapitel 2.1.2 beschrieben ist. Ggf. die Deinstallation und Neuinstallation der fehlerhaften Komponenten durchführen und das Ganze so betrachten, als hätte ich es komplett neu installiert. bzw. als würde ich es neu installieren. Also anschließend auch ein
Code: Alles auswählen
opsi-setup --init-current-config
opsi-setup --set-rights
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart

Hatte ich nicht erwähnt, habe ich dann aber so wie oben gemacht ...
Die ersten beiden Schritte sind später auch ohne Fehler durchgelaufen ...

Beim ersten Mal kam das:
opsisrv:/# opsi-setup --init-current-config
srvnamen und ip-adressen abgeändert

Code: Alles auswählen

[5] [Nov 16 20:17:22] Creating base path: '/var/lib/opsi/config' (File.py|215)
[5] [Nov 16 20:17:22] Getting current system config (opsi-setup|66)
[5] [Nov 16 20:17:22] System information: (opsi-setup|116)
[5] [Nov 16 20:17:22]    distributor  : Debian (opsi-setup|117)
[5] [Nov 16 20:17:22]    distribution : Debian GNU/Linux 5.0.9 (lenny) (opsi-setup|118)
[5] [Nov 16 20:17:22]    ip address   : 192.168.1.100 (opsi-setup|119)
[5] [Nov 16 20:17:22]    netmask      : 255.255.255.0 (opsi-setup|120)
[5] [Nov 16 20:17:22]    subnet       : 192.168.1.0 (opsi-setup|121)
[5] [Nov 16 20:17:22]    broadcast    : 192.168.1.255 (opsi-setup|122)
[5] [Nov 16 20:17:22]    fqdn         : opsisrv.domain.firma.com (opsi-setup|123)
[5] [Nov 16 20:17:22]    hostname     : opsisrv (opsi-setup|124)
[5] [Nov 16 20:17:22]    domain       : domain.firma.com (opsi-setup|125)
[5] [Nov 16 20:17:22]    win domain   : domain (opsi-setup|126)
[5] [Nov 16 20:17:22] Creating config server 'opsisrv.domain.firma.com' (opsi-setup|2448)
[5] [Nov 16 20:17:23] Creating base path: '/var/lib/opsi/config' (File.py|215)
[5] [Nov 16 20:17:23] Configuring client user pcpatch (opsi-setup|349)
[5] [Nov 16 20:17:23]    Creating RSA private key for user pcpatch in '/var/lib/opsi/.ssh/id_rsa' (opsi-setup|363)
[5] [Nov 16 20:17:24] Setting rights (opsi-setup|412)
[5] [Nov 16 20:17:25] Setting rights on directory '/var/lib/opsi/.ssh' (opsi-setup|493)

Code: Alles auswählen

Fehler:
[3] [Nov 16 20:17:27] 'utf8' codec can't decode byte 0x87 in position 0: unexpected code byte (__init__.py|555)

[/b]

Einen Schritt habe ich definitiv falsch gemacht:
Es waren noch clients mit Preloginloader Modus installiert,
könnte das evtl. den Fehler hervorrufen ...?
Der Server mußte heruntergefahren werden, weil die "alten" Clients sonst im Booten hängenblieben ...

durchführen. Vorallem aber - und man neigt schnell dazu - würde ich auch die scheinbar unnötigen Schritte wie "hostname -f" nicht auslassen, denn nur was korrekt ist, kann keine Probleme verursachen.
Mir ging es nach einem Update von SuSE nix mehr und ich hatte quasi die gleichen Probleme, wenn sie auch etwas anders geartet waren. Die oben beschriebene Vorgehensweise löste meine Probleme.

Debian macht da nix kaputt, überschreibt nicht ohne Nachfrage Konfigs

. Aber prüfe ich trotzdem nochmal ...

Und damit andere nicht die Erfahrung machen (das könnten auch mal andere lesen, die sowohl auf Linux als auch opsi neu sind) niemals auf einem Echtsystem sofort die Änderungen durchführen, sondern immer auf einem geklonten System.

Wie wahr

. Dachte eigentlich bin in beiden nicht neu, aber Arroganz wird bestraft, naja vielleicht bin ich ja nach der Opsi-Schulung nächste Woche schlauer ...

Möchte halt jetzt ungern das "halb installierte" System vollends komplett zerschiessen und wie wild de- und installieren
ohne eine konkrete Idee zu haben wo der Fehler liegt ...
btw: ein Neu installierter Win7 Client mit opsi-deploy-agent scheint sauber zum Opsiserver zu connecten, nur kann ich eben im Opsiserver keine Produkte freischalten, ich sehe die Clients und (auch die nach Upgrade manuell installierten Produkte,
die alten Produkte wurden nicht übernommen, das ist aber Standard oder? ...)
aber er bringt zig Fehlermeldungen beim Zugriff auf die Webconsole java.wpt.security o.ä., man kann keine Aktion für ein Produkt übernehmen.
Werde mir nochmals die Pakete mit einem anderen Opsi 4.0 vergleichen, es ist afair java 6.0.18 aber openjdk nicht sun-java ...

Falls jemand noch eine Idee hat ...
Oder Logs fehlen ...

Danke
MH

Verfasst: **17 Nov 2011, 18:59**

Das Problem wurde durch umbenennen der:
/var/lib/opsi/config/config.ini
und erneutem

Code: Alles auswählen

opsi-setup --update-file

gelöst ...
Danke an Alle!

forum.opsi.org

[solved] Fehler nach Upgrade Opsi 3.4 -> Opsi 4.x ...

[solved] Fehler nach Upgrade Opsi 3.4 -> Opsi 4.x ...

Re: Fehler nach Upgrade Opsi 3.4 -> Opsi 4.x ...

Re: Fehler nach Upgrade Opsi 3.4 -> Opsi 4.x ...

Re: [solved] Fehler nach Upgrade Opsi 3.4 -> Opsi 4.x ...