4. Migrating from OmniDB 2 to 3

Migrating from 2 to 3 involves basically copying users, connections, snippets and custom monitoring units from OmniDB 2 and then adjusting the new configuration file.

The steps explained in this chapter are needed for those using omnidb-server version. Users of omnidb-app use default settings and directories so migration is done automatically.

4.1 Configuration File

As explained in chapter 3, OmniDB 3 uses the file config.py to retrieve custom settings.

OmniDB 2, on the other hand, used a file called omnidb.conf, which has a different syntax.

After installing OmniDB 3 package, when running it for the first time, a default config.py file will be created in the target directory.

Users will have to manually edit the new configuration file with the appropriate settings.

4.2 Backend Database

As explained in the previous chapter, OmniDB 3 can be deployed pointing to a PostgreSQL database as opposed to using the default SQLite.

Before running the migration, make sure that OmniDB 3 already has a config.py file with backend database properly configured.

Even if users decide to stick to SQLite, OmniDB 3 uses a completely different database schema so migration steps are needed.

OmniDB 2 stored its data in a SQLite database file located by default in ~/.omnidb/omnidb-server/omnidb.db. If being used as a service, the file was located in the home of the root user, /root/.omnidb/omnidb-server/omnidb.db. If users were pointing OmniDB 2 to a custom directory with -d, location would be /path/to/dir/omnidb.db.

After installing OmniDB 3 packages, if you run OmniDB pointing to the same directory either using -d or letting OmniDB use the default location, migration will be transparent and OmniDB will automatically migrate objects:

omnidb-server
Copying config file to home directory.
Running database migrations...
Operations to perform:
  Apply all migrations: OmniDB_app, admin, auth, contenttypes, sessions, social_django
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying OmniDB_app.0001_3_0_0... OK
  Applying OmniDB_app.0002_3_0_1... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying sessions.0001_initial... OK
  Applying social_django.0001_initial... OK
  Applying social_django.0002_add_related_name... OK
  Applying social_django.0003_alter_email_max_length... OK
  Applying social_django.0004_auto_20160423_0400... OK
  Applying social_django.0005_auto_20160727_2333... OK
  Applying social_django.0006_partial... OK
  Applying social_django.0007_code_timestamp... OK
  Applying social_django.0008_partial_timestamp... OK
  Applying social_django.0009_auto_20191118_0520... OK
  Applying social_django.0010_uid_db_index... OK
Attempting to migrate users, connections and monitoring units and snippets from OmniDB 2 to 3...
Creating user 'admin'...
User 'admin' already exists.
Attempting to create connections of user 'admin'...
Creating connection with alias 'conn1'...
Connection with alias 'conn1' created.
Creating connection with alias 'conn2'...
Connection with alias 'conn2' created.
Creating connection with alias 'conn3'...
Connection with alias 'conn3' created.
Attempting to create snippets of user 'admin'...
Snippet 'snippet1' created.
Folder 'folder1' created.
Snippet 'snippet2' created.
Attempting to create monitoring units of user 'admin'...
Monitoring unit 'db size custom' created.
Database migration finished.

If the user is pointing OmniDB to a new directory but kept the old database file, a manual migration can be performed with parameter -M:

-M dbfile, --migratedatabase=dbfile
                    migrate users and connections from OmniDB 2 to 3: -M
                    dbfile
omnidb-server -d path/to/new/dir -M path/to/old/dir/omnidb.db
Running database migrations...
Operations to perform:
  Apply all migrations: OmniDB_app, admin, auth, contenttypes, sessions, social_django
Running migrations:
  No migrations to apply.
Target database already migrated from OmniDB 2, continue anyway? (y/n) y
Attempting to migrate users, connections and monitoring units and snippets from OmniDB 2 to 3...
Creating user 'admin'...
User 'admin' already exists.
Attempting to create connections of user 'admin'...
Creating connection with alias 'conn1'...
Connection with alias 'conn1' created.
Creating connection with alias 'conn2'...
Connection with alias 'conn2' created.
Creating connection with alias 'conn3'...
Connection with alias 'conn3' created.
Attempting to create snippets of user 'admin'...
Snippet 'snippet1' created.
Folder 'folder1' created.
Snippet 'snippet2' created.
Attempting to create monitoring units of user 'admin'...
Monitoring unit 'db size custom' created.
Database migration finished.

4.2.1 OmniDB User Passwords

OmniDB 2 stored user passwords as hashes so there is no way to retrieve the old password. The migration creates users with password changeme, so users will have to adjust their passwords (or a superuser will have to do it for them).