OTRS Server neu aufsetzen und Daten von bisherigem System migrieren

[MathiasM]

Hallo,

ich habe einmal eine grundlegende Frage.
Ist es möglich einen neuen OTRS Server aufzusetzen (Version 5) und Daten von einem anderen Server zu migrieren welcher in Version 3 läuft?

Kurz zur Ist-Situation:
Wir betreiben derzeit OTRS in der Version 3.1.11 auf einem Debian Server mit lokaler SQL Datenbank und LDAP-Anbindung für die Authentifizierung.
Zusätzlich haben wir das Monitoring System Icinga (ehemals Nagios) im Einsatz, welches Tickets über das Ticketsystem erzeugt.

Kurz zum Problem:
Das hat vor 3-4 Jahren alles mein Kollege eingerichtet, der aber nicht mehr im Unternehmen ist. Ich als Stellvertreter für das Ticketsystem habe nun einen relativ schlechten Überblick über die Einstellungen, da ich mich erst noch einarbeiten muss. Aus der config.pm werde ich nicht ganz so schlau. Zusätzlich haben wir derzeit noch das Problem, dass der LDAP Sync nicht richtig funktioniert? Bzw. neue Mitarbeiter im AD werden nicht mehr als Kundenbenutzer in OTRS gefunden. Außerdem war geplant, dass wir das System demnächst auf die neuste Versin 5 upgraden.

Nun die Frage:
Kann ich folgenden Umweg:
- OTRS Konfiguration verstehen inkl. LDAP Sync
- OTRS LDAP Sync "wiederherstellen" / richtig konfigurieren
- Upgrade auf die neuste Version 5

durch nachfolgenden Weg ersetzen?
- Neuen OTRS Server mit aktueller Version 5 aufsetzen und konfigurieren (inkl. Icinga Kommunikation)
- Alte (Ticket-) Daten vom alten Server (Version 3) auf neuen Server migrieren (Version 5); Ticketdaten liegen unter /opt/otrs/var/article

Somit würde ich auch verstehen, wie der neue OTRS Server konfiguriert ist und könnte das auch ein bisschen dokumentieren

Ich hoffe es ist zu verstehen worauf ich hinaus möchte.

Vielen Dank für Eure Ihre!

[Charmacas]

Ich würde an deiner Stelle ein Backup machen. Wenn du eine virtuelle Umgebung besitzt, dann clone deine OTRS Maschine. Daraufhin versuche ein Update Schritt für Schritt auf Version 5. Dann bist du an dem Punkt, an dem du die Datenbank mit dem integrierten Backup Skript exportieren kannst und bei einer Neuinstallation wieder einspielen könntest.

Da es gerade zwischen den Major Versionen auch zu Datenbankänderungen kommt kann ich mir nämlich nicht vorstellen, dass ein Export der 3er DB zum Erfolg führen würde.

Jedoch wirst du je nach der Vielzahl der bisherigen Anpassungen deines Vorgängers eine lange Zeit brauchen um das umzusetzen. Außer natürlich du hast den ganzen Tag immer Zeit dafür.

[StephanSch]

Ich würde auch auf jeden Fall mit der selben Version starten und auf die aktuelle Version aktualisieren, sonst passen die Daten überhaupt nicht zueinander.

Also einfach SQL-Dump machen, OTRS-Ordner kopieren.
Auf neuem System OTRS 3.1.1 mit Installer installieren.
Gesicherte Daten wieder einspielen und testen.
Updates machen.

So setze ich nach einem Ausfall immer den Debian-Server (oder den MySQL-Slave) auf, ohne Update natürlich.

[MathiasM]

Hallo zusammen und danke für die Antworten.
ok, wenn ich sowieso erst ein Upgrade machen muss, dann versuche ich lieber einmal die config.pm zu verstehen sodass ich das System im besten Fall so weiterführen kann.

Das Problem derzeit besteht darin, dass ein neu angelegter Benutzer im AD nicht in OTRS angezeigt wird / er sich nicht anmelden kann. Hier mal der Code aus der config.pm:

Teil1: CustomerUser

Code: Select all

# CustomerUser (customer database backend and settings)
$Self->{CustomerUser} = {
    Name => 'Backend Name...',
    Module => 'Kernel::System::CustomerUser::DB',
    Params => {
             Table => 'customer_user',
            CaseSensitive => 0,
        },
# customer unique id
CustomerKey => 'login',

# customer #
CustomerID => 'customer_id',
CustomerValid => 'valid_id',

    CustomerUserListFields => ['first_name', 'last_name', 'email'],
    CustomerUserSearchFields => ['login', 'first_name', 'last_name', 'customer_id'],
    CustomerUserSearchPrefix => '',
    CustomerUserSearchSuffix => '*',
    CustomerUserSearchListLimit => 250,
    CustomerUserPostMasterSearchFields => ['email'],
    CustomerUserNameFields => ['title','first_name','last_name'],
    CustomerUserEmailUniqCheck => 1,
#    # show not own tickets in customer panel, CompanyTickets
#    CustomerUserExcludePrimaryCustomerID => 0,
#    # generate auto logins
#    AutoLoginCreation => 0,
#    AutoLoginCreationPrefix => 'auto',
#    # admin can change customer preferences
#    AdminSetPreferences => 1,
#    # cache time to live in sec. - cache any database queries
#    CacheTTL => 0,
#    # just a read only source
#    ReadOnly => 1,
    Map => [
        # note: Login, Email and CustomerID needed!
        # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target
        #[ 'UserTitle',      'Title',      'title',      1, 0, 'var', '', 0 ], 
        [ 'UserFirstname',  'Firstname',  'first_name', 1, 1, 'var', '', 0 ],
        [ 'UserLastname',   'Lastname',   'last_name',  1, 1, 'var', '', 0 ],
        [ 'UserLogin',      'Username',   'login',      1, 1, 'var', '', 0 ],
        [ 'UserPassword',   'Password',   'pw',         0, 0, 'var', '', 0 ],
        [ 'UserEmail',      'Email',      'email',      1, 1, 'var', '', 0 ],

#       [ 'UserEmail',      'Email', 'email',           1, 1, 'var', '$Env{"CGIHandle"}?Action=AgentTicketCompose&ResponseID=1&TicketID=$Data{"TicketID"}&ArticleID=$Data{"ArticleID"}', 0 ],
        [ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],

#        [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],
        [ 'UserPhone',        'Phone',       'phone',        1, 0, 'var', '', 0 ],
        [ 'UserFax',          'Fax',         'fax',          1, 0, 'var', '', 0 ],
        [ 'UserMobile',       'Mobile',      'mobile',       1, 0, 'var', '', 0 ],
        [ 'UserStreet',       'Street',      'street',       1, 0, 'var', '', 0 ],
        [ 'UserZip',          'Zip',         'zip',          1, 0, 'var', '', 0 ],
        [ 'UserCity',         'City',        'city',         1, 0, 'var', '', 0 ],
        [ 'UserCountry',      'Country',     'country',      1, 0, 'var', '', 0 ],
        [ 'UserComment',      'Comment',     'comments',     1, 0, 'var', '', 0 ],
        [ 'ValidID',          'Valid',       'valid_id',     0, 1, 'int', '', 0 ],
    ],
    # default selections
    Selections => {
        UserTitle => {
            'Mr.' => 'Mr.',
            'Mrs.' => 'Mrs.',
        },
    },
};

Teil2: Agentenauthentifizierung (domain namen und controller umbenannt)

Code: Select all

$Self->{'AuthModule'} = 'Kernel::System::CustomerAuth::LDAP';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@<domäne>.COM';

# Agentenauthetifizierung über AD <Firma1>
	$Self->{'AuthModule'} = 'Kernel::System::Auth::LDAP';
	$Self->{'AuthModule::LDAP::Host'} = '<domaincontroller>.<domäne>.com';
	$Self->{'AuthModule::LDAP::BaseDN'} = 'dc=com';
	$Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';
	#$Self->{'AuthModule::LDAP::UserSuffix'} = '@domäne.com';
	$Self->{'AuthModule::LDAP::SearchUserDN'} = 'cn=otrs,ou=Technische User,ou=Benutzer,dc=<firma1>,dc=com';
	$Self->{'AuthModule::LDAP::SearchUserPw'} = '...pw...';
	#$Self->{'AuthModule::LDAP::GroupDN'} = 'cn=G_OTRS_Agenten,ou=Uebergreiffend,ou=DG,ou=DE,ou=Groups,dc=<firma1>,dc=com';
	# bei 2008er Domänen ist es 'member' bei 2003er ist es 'memberUID'*
	# $Self->{'AuthModule::LDAP::AccessAttr'} = 'member';
	#$Self->{'AuthModule::LDAP::UserAttr'} = 'Uid';
	#$Self->{'AuthModule::LDAP::UserAttr'} = 'DN';
	
## Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
 	$Self->{'AuthModule::LDAP::Params'} = {
     	port    => 3268,
 	timeout => 120,
   	async   => 0,
      	version => 3,
   };

Teil3: User Anmeldung von einer anderen Domäne/Firma (in Vertrauensstellung mit unserer Domäne)
(domain namen und controller umbenannt)

Code: Select all

# User Anmeldung über AD <Firma2>
	$Self->{'Customer::AuthModule1'} = 'Kernel::System::CustomerAuth::LDAP';
  	$Self->{'Customer::AuthModule::LDAP::Host1'} = '<domaincontroller>.<firma2>.<firma1>.com';
	$Self->{'Customer::AuthModule::LDAP::BaseDN1'} = 'dc=<firma2>, dc=<firma1>, dc=com';
  	$Self->{'Customer::AuthModule::LDAP::UID1'} = 'sAMAccountName';
	$Self->{'Customer::AuthModule::LDAP::SearchUserDN1'} = 'cn=otrs,ou=Technische User,ou=Benutzer,dc=<firma1>,dc=com';
	$Self->{'Customer::AuthModule::LDAP::SearchUserPw1'} = '...pw...';

[StephanSch]

Soweit ich mich erinnere ist das Verhalten richtig so. Es muss immer der Agent nochmal manuell in OTRS angelegt werden (irgendein Passwort). Es müssen ja eh noch die Berechtigungen auf Queues/Gruppen/Rollen gesetzt werden. Wenn der User mit dem selben Anmeldename wie im LDAP da ist sollte die Anmeldung LDAP-Passwort funktionieren.

Ob sich das in v4 oder 5 ändert weiß ich nicht.

[reneeb]

Soweit ich mich erinnere ist das Verhalten richtig so. Es muss immer der Agent nochmal manuell in OTRS angelegt werden [...]

Dazu kann man die Sync-Funktionalität nutzen. Dann muss das nicht manuell gemacht werden, sondern wer sich erfolgreich einloggen kann (Prüfung gegen das LDAP), der wird - falls notwendig - angelegt.

[StephanSch]

Stimmt, haben wir tatsächlich auch aktiv:

Code: Select all

#-------------Ldap Sync --> DB -------------------------------------#   


    $Self->{AuthSyncModule} = 'Kernel::System::Auth::Sync::LDAP';
    $Self->{'AuthSyncModule::LDAP::Host'} = 'ldaps://ldap.xxx';
    $Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=xxx,dc=xxxx';
    $Self->{'AuthSyncModule::LDAP::UID'} = 'uid';

    # The following is valid but would only be necessary if the
    # anonymous user do NOT have permission to read from the LDAP tree
#    $Self->{'AuthSyncModule::LDAP::SearchUserDN'} = '';
#    $Self->{'AuthSyncModule::LDAP::SearchUserPw'} = '';

    # in case you want to add always one filter to each ldap query, use
    # this option. e. g. AlwaysFilter => '(mail=*)' or AlwaysFilter => '(objectclass=user)'
#    $Self->{'AuthSyncModule::LDAP::AlwaysFilter'} = '';

    # AuthSyncModule::LDAP::UserSyncMap
    # (map if agent should create/synced from LDAP to DB after successful login)
    $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
        # DB -> LDAP
        UserFirstname => 'givenName',
        UserLastname  => 'sn',
        UserEmail     => 'mail',
    };

    # In case you need to use OTRS in iso-charset, you can define this
    # by using this option (converts utf-8 data from LDAP to iso).
#    $Self->{'AuthSyncModule::LDAP::Charset'} = 'iso-8859-1';

    # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
    $Self->{'AuthSyncModule::LDAP::Params'} = {
        port    => 636,
        timeout => 120,
        async   => 0,
        version => 3,
    };
        $Self->{'AuthSyncModule::LDAP::Die'} = 1;

#--- Initial Group users --------------------------------- #

    # Attributes needed for group syncs
    # (attribute name for group value key)
    $Self->{'AuthSyncModule::LDAP::AccessAttr'} = 'memberUid';
    # (attribute for type of group content UID/DN for full ldap name)
    $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'UID';
#    $Self->{'AuthSyncModule::LDAP::UserAttr'} = 'DN';

    # AuthSyncModule::LDAP::UserSyncInitialGroups
    # (sync following group with rw permission after initial create of first agent
    # login)
    $Self->{'AuthSyncModule::LDAP::UserSyncInitialGroups'} = [
        'users',
    ];

[KlausNehrer]

Wie definiert Du eigentlich "kann sich nicht anmelden"? Und wird Deine Theorie durch Einträge im Log gestützt?

[wurzel]

Hi,

OTRS Server neu aufsetzen und Daten eines alten OTRS zu migrieren ist so gut wie unmöglich. In jedem Fall ist es aufwändig. In den letzten 6 Jahren in denen ich OTRS mache habe ich das erst einmal gesehen von einem Datenbankspezialisten. Betonung auf Spezialist. Die haben aber heute noch Datenbankfehler drin.
Das is nix für Anfänger. Auch nicht für Profis. Das ist ausschließlich was für Hardcore Spezialisten. Eigentlich sollte man es garnicht erst versuchen.

In solchen Fällen wäre es einfacher die bestehende Instanz auf 5 zu migrieren und dort Stück für Stück optimieren. Am einfachsten wäre es, Dir Hilfe zu holen und/oder 'ne OTRS Schulung zu besuchen.

Ich als Stellvertreter für das Ticketsystem habe nun einen relativ schlechten Überblick über die Einstellungen, da ich mich erst noch einarbeiten muss.

Profis können das sicher schneller Dafür gibt's Hersteller Support.

Flo

[MathiasM]

Hallo zusammen und danke für die vielen Antworten.

Das mit dem Migrieren auf einen neuen Server habe ich mir inzwischen aus dem Kopf geschlagen

Ich besuche demnächst eine OTRS Schulung an der ich hoffentlich noch einen besseren Einblick in die Systemadministration erhalte.
Generell kenne ich mich schon "recht gut" damit aus, jedoch weiß ich nicht genau, welche konkreten Anpassungen (abweichend vom Standard) vorgenommen wurden.

Wenn ich das richtig verstanden habe, muss dieser Code zur config.pm ergänzt werden, sodass die User automatisch vom LDAP in die OTRS Kundendatenbank übernommen werden?

Code: Select all

    # AuthSyncModule::LDAP::UserSyncMap
    # (map if agent should create/synced from LDAP to DB after successful login)
    $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
        # DB -> LDAP
        UserFirstname => 'givenName',
        UserLastname  => 'sn',
        UserEmail     => 'mail',
    };

Ich hatte eigentlich in Erinnerung, dass bisher auch alle User automatisch vom LDAP übernommen wurden, jedoch ist dieses Stück Code bisher ja nicht in der config.pm. Sonst gibt es keine andere Möglichkeit die User automatisch hinzuzufügen? Ich möchte halt gerne wissen warum dies bis vor 3-4 Wochen funktionierte und dann auf einmal nicht mehr.