Migrate OTRS 3.2.4 to new server

[Frobs]

Hi

I wrote a post earlier regarding OTRS on Windows, but have come to the conclusion that Linux is the way to go
viewtopic.php?f=62&t=26597

The running version was installed by a former employee and we would like to do a "fresh" installation and document the steps we take because no one at the Company has the ability to help with the installation if anything happens or OTRS need to be upgraded/patched.

When logged in as root in the Admin module I can do an export of the settings through SysConfig, but I assume this is the same as saving the *.pm files in /opt/otrs?

The following link shows the procedure in case of an upgrade of the OTRS framework. Is it the same files I just need to backup and import on the new server?
http://otrs.github.io/doc/manual/admin/ ... ading.html

I also found this:
http://www.geoffstratton.com/2013/08/mi ... to-centos/
I know it's regarding a change between to different versions of Linux, but I assume it's the same as a migration to a different server. Part III and IV looks helpful.

I assume I should do the following on the running server:
Create a dump of the MySQL database
Save content of /opt/otrs

On the new server
Import the MySQL dump
Import the content of /opt/otrs
Configure Config.pm with the correct settings for the database

Am I fare out or does it make sense?

I have worked with Linux earlier but never in real production, so I am bit rusty

Frobs

[crythias]

Read UPGRADING.md for the version you're in. Note that, in addition, you're expected to back up the database.

If you run the backup/restore utility, that can help the migration.

The biggest issues between distributions will be getting permissions to work and in CentOS/RedHat environments, disable selinux.

[Frobs]

Hi Again

I read UPGRADING.md and it looks pretty straight forward.

In our setup OTRS is installed on one server and the database is running on another server on MySQL. When doing the ./backup.pl it returns an error saying mysqldump is missing, which I can understand since it's installed on the database server. Is it possible to use the ./backup.pl without mysqldump?

Frobs

[crythias]

It's likely sufficient to do a filesystem copy of your otrs directory.

[crythias]

but to do a mysql backup you should do at the hosting server.

[Frobs]

Thanks for the quick replies.

I am still learning by doing

I have installed the 3.3.8 appliance (not the latest because I would like to test the upgrade procedure later on ) and have imported the configuration files from the 3.2.4 installation and changed Config.pm so it uses my test MySQL server. The MySQL server is a clone of our running server, I have just assigned a new IP.

When doing the above I get Access denied when running otrs.CheckDB.pl. Is it possible to do what I am doing, just "attaching" the database to a 3.3.8 installation and hoping it will work?

Frobs

[crythias]

ok, couple of things ... 3.2.x to 3.3.8 needs upgrade, but

checkdb access denied means it is using creds from Config.pm and is denied access by the remote server.
Likely issue is remote server is not a fan of your appliance ip/username/pw combination. (Read: mysql is saying I don't allow that IP address to log in as that user.)

[Frobs]

Is there anywhere in the MySQL installation that it's possible to allow access from specific servers/IPS?

[Frobs]

I fixed the issue with the MySQL connection.

I ran the following on the MySQL server:
GRANT ALL ON otrs03.* TO 'new_user'@'172.16.1.11' IDENTIFIED BY 'Passw0rd';

After doing so, I can run the otrs.CheckDB.pl and succesfully connect to the database.

I can now open http://172.16.1.10/otrs/index.pl but are not allowed to logon. I assume if I reset the password for root@localhost I can then log in. And root@localhost is not the same as the actual root on the server, correct?

[crythias]

but are not allowed to logon

I assume you'd have a more explicit error in the logs, /var/log/messages, /var/log/syslog, etc. Please tell us?

root@localhost at the user (web) interface is not the same as root on server.

[Frobs]

I checked the logs and could see I had a permission issue with ZZZAAuto.pm and then I ran the following again and then I could login:
perl ./otrs.SetPermissions.pl --otrs-user=otrs --web-user=otrs --otrs-group=otrs --web-group=www-data /opt/OTRS

So now I have more or less succesfully done the following
Installed OTRS appliance 3.3.8
Imported configuration files from our 3.2.4 installation
Configured Config.pm to my test MySQL database
- Have created a new user so there is no accidental connection to our production setup
Configured the correct permissions
- Can login to the website, http://172.16.1.10/otrs/index.pl

I am missing some customizations/skins that we have in our production environment, but will look at that part now.

According to the upgrade guide a backup of "/opt/OTRS/var" is recommended, but can I "just" copy it back and replace the existing files/folders?

[crythias]

themes won't convert 3.2->3.3 (read upgrading.md)

[Frobs]

Once again, thanks for your quick replies. You have been very helpful so far.

I can see that settings via Admin->SysConfig is possible to set directly in Config.pm, but have tried it and it won't Work. For example I have seen an issue with not being able to disable SecureMode, and then trying to add it in Config.pm doesn't help either.

After change settings in Config.pm, is it just necessary to do a restart of the apache service?

[Frobs]

As I wrote earlier, is it at all possible to install 3.3.9 and connect it to a database from our 3.2.4 and actually login?

It's a leading question because I have installed 3.3.9 and edited Config.pm so that it connects to my test MySQL server with a copy of our running database. I can run OTRS.CheckDB.pl and everything is good, but I can't login to the site. We have LDAP validation in our production environment but the administrative users are agents created locally in OTRS as far as I know, and I can't login with one of those accounts.

I assume my mistake is that I have to run all the scripts mentioned in UPGRADING.md

[crythias]

the questions:
1) will the website even connect and show a box to login (yes, apparently))
2) will the credentials be properly authenticated (no idea)
3) will anything be accessible after login (probably not and lots of errors.)

[jojo]

you can not connect a new version to an old database. You have to run all migration scripts.

[Frobs]

Those are good questions

And I assumed that I couln't connect the latest version to the old database, just had to try
- When you mention the migration scripts. Do you mean that I can connect the new server with the old database and run all migration scripts or do I have to do this before moving to the new server?

[Frobs]

A question a bit off topic

In our 3.2.4 installation we fetch mail via IMAPTLS and it's working fine. When we configure it the same way in 3.3.9 it fails when pressing fetch mail from the Admin site. I just receive an internal server error. If I check the apache error logs, it looks like a permission issue with the user logged in to OTRS and to the Exchange.

[crythias]

When you mention the migration scripts. Do you mean that I can connect the new server with the old database and run all migration scripts or do I have to do this before moving to the new server?

"connect" means only that proper db authorization is presented and accepted. It doesn't mean the app works.

1) Backup your old database.
2) confirm you have something you can restore
3) The database migration scripts run from a command line. The same script would have the same effect whether they were run from box A or box B as long as they are talking to the same database host/connection.

[Frobs]

Hi Again

Been away for some days.

I have now created a closed lab environment with clones of our production MySQL db and OTRS installation, and I will now try to do an upgrade.

Be back later with the results

[Frobs]

I have now upgraded from 3.2.4 to 3.3.9 in the closed test lab, and "everything" seems to be working.

As part of the upgrade I did the following:
◦If you update from OTRS 3.3.6 or earlier, you need to enable a new cronjob that controls the scheduler process. Please copy the file /opt/otrs/var/cron/scheduler_watchdog.dist to /opt/otrs/var/cron/scheduler_watchdog and update your crontab with /opt/otrs/bin/Cron.sh start (as “otrs” user, not root).

I ended up with a VERY empty cron list when doing "crontab -e -u otrs", and before I had a lot of jobs. Do I have to insert every job again manually or how is this handled?

[crythias]

/opt/otrs/bin/Cron.sh start otrs

[Frobs]

I found it yesterday afternoon

So now I have a valid crontab for the otrs user again.

I am getting really close to have a running version without any major issues, and I have documented every single step on the way. Might do a blog for other OTRS newbies like me

Before doing the upgrade our ticket number contained 12 digits, after the upgrade it contains 16 digits. Is it possible to continue from the 12 digit numbers or should we just accept the new and longer ticket number?

Thanks in advance AGAIN