Kein Admin-User mehr, Adminbereich für alle Nutzer nicht erreichbar

[niemalsnever]

Moin,

ich habe heute ein neues OTRS 5.0.4 aufgesetzt, nachdem unser altes OTRS 4 nach einem Upgrade in die Binsen gegangen ist. Ich habe allen Usern alle Rechte für alle Gruppen geben wollen, scheinbar habe ich mich irgendwo doof verklickt, jedenfalls hat nun kein User mehr Admin-Rechte. Normalerweise würde ich einfach die Datenbank neu anlegen, aber leider sind schon Tickets im System die ich ungern verlieren würde.

Wo wir schon bei verlorenen Tickets sind, habt ihr ne Idee, wie ich die Ticket-History des alten OTRS 4 in das neue hineinbekomme? Habe schnell verfügbar nur ein SQL-Backup der alten Datenbank.

Gruß,
niemalsnever

[jojo]

Hallo,

um de alten Tickets in das System zu bekommen musst Du die alte Datenbank migrieren (=Verlust der Daten die bereits in das neue System gelaufen sind).

Ansonsten gibt es die Möglich über das CLI Benutzer zu Gruppen oder Rollen zuzuweisen. Gerade bei einem bestehenden Produktivsystem solltest Du aber einen an das System lassen, der entsprechende Fachahnung für den Betrieb von OTRS Systeme hat

[niemalsnever]

Moin,

lt. der DB hat mindestens der User root@localhost rw-Permissions in allen 3 Gruppen (users, admins, stats). Zusätzlich habe ich eben nochmal probiert das OTRS mit dem Webinstaller in ner leeren DB aber mit den bestehenden Configs zu installieren, auch hier hatte der frisch angelegte root@localhost keine Admin-Permissions. Ich habe das Gefühl dass irgendwo in der Config ein Fehler ist, der dafür sorgt, dass OTRS "Insufficient Permissions" meldet.

Alte Datenbank migrieren fällt schwer, weil es die Struktur dieser DB scheinbar irgendwann mal zerschossen hat, OTRS hat ständig fehler geworfen, weil es Probleme hatte E-Mail-Anhänge zu verwalten. Wenn gewünscht, kann ich die alten Fehlermeldungen gerne mal hier reinwerfen.

Gruß,
niemalsnever

[darkdead]

Du könntest mal ne Datenbank Reparatur einleiten oder mal die Sysconfig sichern und die Defaults.pm einspielen. Evtl. hat die DB nen knax oder die Sysconfig hat ein Problem.

[niemalsnever]

Moin,

DB-Reparatur halte ich für wenig sinnig, da wie gesagt mit einer durch den Installer erstellten neuen DB das selbe Problem auftrat. Sysconfig sichern und Defaults.pm einspielen, könnte man mal ausprobieren.

Ich kann auch gerne die Sysconfig mal hier einstellen, vllt. sieht man dann was.

Gruß,
niemalsnever

[KlausNehrer]

Nutzt ihr die lokale OTRS DB für die Agenten? Deine Beschreibung klingt nach externer Auth.

Bist Du Dir sicher, dass Du der Richtige für die Betreuung des OTRS bist? Deine Fragen deuten Erfahrungsgemäß daraufhin, dass es entweder am fehlenden Willen oder Wissen liegt.

[niemalsnever]

Moin, nein, LDAP-Authentication. Habe das Problem jetzt behoben indem ich OTRS einmal komplett neu installiert habe, und ihm die Datenbank von gestern untergejubelt habe. Das scheint soweit zu funktionieren. Jetzt ist das einzige Problem noch, wie ich die Ticket-History des alten OTRS wieder in das neue kriege. Eine Import-/Export-Funktion gibt es ja leider nicht, oder?

[Hazet]

Die Tickethistorie ist in der Datenbank. Wenn Du also alles richtig gemacht hast, dann ist die jetzt auch da...

[niemalsnever]

Die Tickethistorie ist in der Datenbank. Wenn Du also alles richtig gemacht hast, dann ist die jetzt auch da...

Moin,
wie ich ganz zu Anfang schon mal schrieb, hat es die alte Datenbank zerschossen. da scheint eine Migration nicht sauber durchgelaufen zu sein, deswegen ja das ganze Hickhack mit komplett neu aufsetzen. Deswegen war die Frage, ob ich die alte Historie irgendwie manuell übertragen bekomme.

Wenn das nicht geht, hab ich wohl Pech gehabt, danke für eure Mühen!

[KlausNehrer]

Was bedeutet denn zerschossen?
Und nein, in dieser Art gibt es keinen Import für das OTRS.

Eine andere Option zum Thema Berechtigung wäre gewesen, die LDAP Auth in der Config zu deaktivieren, wodurch der root@localhost aus der OTRS DB wieder funktioniert hätte.

[darkdead]

hat es die alte Datenbank zerschossen. da scheint eine Migration nicht sauber durchgelaufen zu sein

Deshalb mach ich von dem System vorher immer ne Sicherung (unter VMWare Snapshot). Wenn dann was schief läuft einfach einspielen.

[Schojo]

ne schöne lösung gibt es dafür bestimmt, dafür hast du den karren jetzt schon zu weit in den dreck gefahren, aber versuchs doch mal so:
spiel dir die alte db in deinen db-server ein, als otrsold oder whatever und erstell dir mal über den webinstaller ne weitere instanz, otrstemp oder so.
dann kopierste mal die tickettabellen von otrsold in otrstemp und lässt mal die DBUpdate scripts aus dem UPGRADING laufen und schaust mal was da so passiert. falls das funktionieren sollte, könntest du dir die tickettabellen dann nach erfolgreichem update in deine aktive otrs db schieben.

wie gesagt, nicht schön aber vielleicht möglich. und bitte denk für jedem schritt an db-exports...

[niemalsnever]

Moin,

Der Fehler in der alten Datenbank war übrigens dass bei irgendeinem Update (wahrscheinlich sogar noch vor mir) in der Tabelle article_attachment die Spalte "disposition" nicht angelegt wurde. So hab ich es letztendlich dann auch repariert. Spalte hinzugefügt, löppt. Das es keinen Import gibt ist schade, aber nun gut, jetzt läuft es wieder, mit der alten DB.

Kurzum, das Topic kann geschlossen werden. Danke nochmals für eure Hinweise. Im übrigen wurden Sicherungen an jedem Punkt erstellt, was einem allerdings wenig nützt, wenn der Fehler erst einige Monate nach dem Update auftritt und ordentlich diagnostiziert werden kann.

Gruß,
niemalsnever

P.S. Als Neuling fühlt man sich hier richtig willkommen geheißen </ironie> :|