Debian Question posted in
The oficial documentation can be found here.

Database issue when migrating a Trac project – Debian

I am trying to migrate a series of Trac projects originally hosted on CloudForge onto a new Bitnami virtual machine (debian with Trac stack installed).

The documentation on the Trac wiki regarding restoring from a backup is a little vague for me but suggests that I should be able to setup a new project

$ sudo trac-admin PROJECT_PATH initenv

stop the services from running

$ sudo /opt/bitnami/ctlscript.sh stop

copy the snapshot from the backup into the new project path and restart the services

$ sudo /opt/bitnami/ctlscript.sh start

and should be good to go.

Having done this (and worked through quite a few issues on the way) I have now got to the point where the browser page shows

Trac Error

TracError: Unable to check for upgrade of trac.db.api.DatabaseManager: TimeoutError: Unable to get database connection within 0 seconds. (OperationalError: unable to open database file)

When I setup the new project I note that I left the default (unedited) database string but I have no idea what database type was used for the original CloudForge Trac project i.e. is there an additional step to restore the database.

Any help would be greatly appreciated, thanks.

Edit
Just to add, the CloudForge was using Trac 0.12.5, new VM uses Trac 1.5.1. Not sure if this will be an issue?

Edit
More investigation and I’m now pretty sure that the CloudForge snapshot is not an SQLite (or other) database file – it looks like maybe a query type response as it starts and ends with;

BEGIN TRANSACTION;
…
COMMIT;

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    Thanks to anyone taking the time to read this but I think I'm sorted now.

    After learning more about SQLite i discovered that the file sent by CloudForge was an sqlite DUMP of the database and was easy enough to migrate to a new database instance using the command line

    $ sqlite3 location_of/new_database.db < dump_file.db

    I think I also needed another prior step of removing the contents of the original new_database.db using the sqlite3 command line (just type sqlite3 in terminal)

    $ .open location_of/new_database.db
$ BEGIN TRANSACTION;
$ DELETE FROM each_table_in_database;
$ COMMIT;
$ .exit

    I then had some issue with credentials on the bitnami VM so needed to retrieve these (as per the bitnami documentation) using

    $ sudo cat /home/bitnami/bitnami_credentials

    and add this USER_NAME as a TRAC_ADMIN using

    $ trac-admin path/to/project/ permission add USER_NAME TRAC_ADMIN

    NOTE that pre and post this operation be sure to stop and re-start the bitnami services using

    $ sudo /opt/bitnami/ctlscript.sh stop
$ sudo /opt/bitnami/ctlscript.sh start

  2. 0

    I am the guy from Trac Users, you need to understand that the user isnt really stored in the db. You got some tables with columns holding the username but there is no table for an user. Looking at you post i think your setup used htdigest and then your user infos are in that credential file. if you cat it you should see something like

    username:realmname:pwhash

    i thing this is md5 as hash but it doesnt really matter for your prob. so if you want to make a new useryou have to use

    htdigest [ -c ] passwdfile realm username

    then you should use trac-admin to give the permission and at that point your user should be able to login.

    Cheers

    MArkus

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search