Standalone mode and database setup

[Gustav Jonegard]

Hello fellow developers,

I am currently trying to get the most basic instance of googles certificate transparency logging server up and running for testing purposes. I wish to run it in standalone mode with a sqlite database. Compiling and running the unit tests worked well. The problem I have run into is that the tables I need aren't created and I have yet to find any documentation of what is needed in the database or a script which sets it all up.

During yesterday while looking through the source code I reverse-engineered a bit and constructed a basic database with the node, leaves, trees and entries tables. With those tables present the server started but shortly after that it began logging error messages, I suppose this is due to the other missing tables in the database. The command I ran to start the server was the following:

sudo ct-server --key=/home/test/logger.key --trusted_cert_file=/home/test/logger.crt --sqlite_db=/home/test/logger.db --i_know_stand_alone_mode_can_lose_data=true --alsologtostderr=true

Are there any database setup scripts available or is there a bug with the creation of the tables in blank databases? I have seen that there are CREATE TABLE statements present in the code base but they don't seem to be run. Perhaps it is all a user error on my side? Any help is appreciated.

Best regards

[Pierre Phaneuf]

There shouldn't be any other scripts necessary when using the SQLite
data in standalone mode. The code that opens the database is here:

https://github.com/google/certificate-transparency/blob/master/cpp/log/sqlite_db.cc#L55

Did you create the /home/test/logger.db database beforehand? The code
here will create the database *and* the tables if opening the database
fails, so if you create the database file by hand (with the
command-line "sqlite3" tool, for example), you might have the problem
you're describing?

If that's the case, simply deleting /home/test/logger.db and
restarting the server should do the trick.

In the case where the database opens successfully, we didn't want to
get into the business of verifying the schema, and potentially
evolving it, as this is a whole other kettle of fish!

You use "sudo" with your command-line there, by the way, this
shouldn't be necessary. The default port (specified using --port) is
9999, which isn't privileged, and I believe that's the only reason you
might want to use "sudo". It is preferable to not run in privileged
mode, of course, for security reasons (in case of an exploitable bug
in our code!).

For production use (obviously not your current situation, with the
"--i_know_stand_alone_mode_can_lose_data" flag!), I would recommend
using a reverse proxy setup in front (such as an Nginx or Apache
reverse proxy setup), which could also be used to provide HTTPS
termination, as well as load balancing between the ct-server cluster
nodes, and this reverse proxy can be configured to access the nodes on
a different port, of course.

If you want to try the clustered setup (which can work on a single
node), you'll need to do an initial configuration using the "initlog"
subcommand of the "cpp/tools/ct-clustertool" binary. If you run only
one node, you will have to set the "minimum_serving_nodes"
configuration to 1, for obvious reasons (please use a higher setting
for production use!).

> --
> You received this message because you are subscribed to the Google Groups
> "certificate-transparency" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to certificate-transp...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Gustav Jonegard]

Hi,

Thank you for the speedy reply. Yes, I had created the database file beforehand as I made an assumption on how it all was to work. Once I removed the file starting the server worked out fine. Thank you again.

Cheers, Gustav

[Pierre Phaneuf]

Great, glad to be of help! Feel free to ask here again if you have any
other questions.