Depot aus datenstruktur verschuwnden bzw Eintrag zerschossen

[dark alex]

Hallo zusammen!

Ich habe ein Script, das den Opsi-Agent auf Clients verteilt.
Irgendwie kam der auf die Idee, auch den Opsi-Server mit dem Agent ausstatten zu wollen.
Blöderweise überschreibt opsi-deploy-client-agent den Eintrag des Depotservers dann mit dem eines Clients...
(das finde ich übrigens fast schon grenzwertig, dass er das selbst hier tut...)

Was muss ich tun, damit aus dem vermeintlichen client in der Datenstruktur wieder ein Depot wird?
Backup einspielen steht eigentlich nicht zur Debatte weil heute viel Arbeit verloren ginge
Ich habe übrigens MySQL und mal kurz rein gesehen:

Der Host "OpsiSrv" ist jetzt type OpsiClient und notes sagt mir Created by opsi-deploy-client-agent at Mon, 04 Apr 2016 12:18:59
Allerdings sind die Werte wie depotRemoteURL usw noch gesetzt...

//Edit: Es geht übrigens um's Master-Depot (und das einzige)

[dark alex]

Ich hab jetzt versucht, das Depot mit

Code: Alles auswählen

# opsi-setup --register-depot

wieder live zu bekommen, jedoch hängt der Befehl seit ca 15 Minuten:

Code: Alles auswählen

[5] [Apr 04 13:34:45] Getting current system config (opsi-setup|113)
[5] [Apr 04 13:34:45] System information: (opsi-setup|166)
[5] [Apr 04 13:34:45]    distributor  : Debian (opsi-setup|167)
[5] [Apr 04 13:34:45]    distribution : Debian GNU/Linux 8.3 (jessie) (opsi-setup|168)
[5] [Apr 04 13:34:45]    ip address   : 172.16.10.10 (opsi-setup|169)
[5] [Apr 04 13:34:45]    netmask      : 255.255.0.0 (opsi-setup|170)
[5] [Apr 04 13:34:45]    subnet       : 172.16.0.0 (opsi-setup|171)
[5] [Apr 04 13:34:45]    broadcast    : 172.16.255.255 (opsi-setup|172)
[5] [Apr 04 13:34:45]    fqdn         : opsisrv.***.local (opsi-setup|173)
[5] [Apr 04 13:34:45]    hostname     : opsisrv (opsi-setup|174)
[5] [Apr 04 13:34:45]    domain       : ***.local (opsi-setup|175)
[5] [Apr 04 13:34:45]    win domain   : KLINIKUM (opsi-setup|176)
[5] [Apr 04 13:35:34] Creating depot 'opsisrv.***.local' (opsi-setup|1742)
[5] [Apr 04 13:35:34] Getting depot 'opsisrv.***.local' (opsi-setup|1745)
[5] [Apr 04 13:35:34] Testing connection to config server as user 'opsisrv.***.local' (opsi-setup|1754)
[5] [Apr 04 13:35:35] Successfully connected to config server as user 'opsisrv.***.local' (opsi-setup|1759)
[5] [Apr 04 13:35:35] Updating backend config '/etc/opsi/backends/jsonrpc.conf' (__init__.py|85)
[5] [Apr 04 13:35:35] Backend config '/etc/opsi/backends/jsonrpc.conf' updated (__init__.py|99)
[5] [Apr 04 13:35:35] Updating dispatch config '/etc/opsi/backendManager/dispatch.conf' (opsi-setup|1763)
[5] [Apr 04 13:35:35] Dispatch config '/etc/opsi/backendManager/dispatch.conf' updated (opsi-setup|1776)

//Editt: Ah! Er versucht die dispatch.conf zu überschreiben und rennt dann gegen die Wand... Klar...

[dark alex]

Code: Alles auswählen

# opsi-setup --init-current-config

ist mächtiger als ich dachte... Ich habe die ganze Zeit versucht die Daten zu rekonstruieren und jetzt einfach mal den Snapshot von direkt nach der Panne eingespielt und den Befehl ausgeführt...
[strike]Läuft augenscheinlich wieder [/strike]

[dark alex]

Leider kann ich jetzt aber keine Product-Properties mehr bearbeiten... die Listen bleiben einfach leer...
egal ob Netboot oder localboot und egal ob Depot- oder Clientconfig...

[dark alex]

ich hab mir jetzt beholfen indem ich ein backup, das mittels "opsi-backup create" angelegt wurde zurückgespielt habe.
Konnte es leider nicht anders lösen.

Und ja, d.oertel, ich weiß, Supportvertrag

[n.wenselowski]

Hi dark alex,

Und ja, d.oertel, ich weiß, Supportvertrag

Dies!
Aber wie ich sehe hast du selbst eine Lösung gefunden

Vermutlich hätte es auch geklappt dir die Daten des Servers bei host_getObjects ausgeben zu lassen, den Typ anzupassen nach OpsiConfigserver und das neu einspielen.


Gruß

Niko

[dark alex]

Du meinst den "type" auf OpsiConfigserver setzen? Hab ich versucht... selbes Ergebnis wie beim init-current-config