Thursday, 29 December 2011

Etckeeper on Ubuntu

There's a package in the Ubuntu repositories called 'etckeeper', which is a brilliant little tool for tracking changes to your configuration stored under the /etc directory.

The way it works is that it puts the whole of the /etc directory under version control, using one of either Bazaar, Mercurial, Git or Darcs. Then, whenever changes are made, either directly by modifying a file, or indirectly by running something like "apt-get update" it makes a note of who made the changes and what the differences in the files were. It then becomes easy to roll back configuration changes, find out who made the change and what the specific change to the configuration file was.

There's a good writeup on the basic usage on the Ubuntu Server Guide page.

Installing 'etckeeper' is as easy as:

sudo apt-get install etckeeper

It will use Bazaar as the VCS by default and will commit the first revision on installation.

Then, let's say that we wanted to install Apache, we would do this using "apt-get" as per usual, but during the install there'd be an extra section dealing with the commit by etckeeper:

$ sudo apt-get install apache2
[sudo] password for srdan:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libcap2
Suggested packages:
apache2-doc apache2-suexec apache2-suexec-custom
The following NEW packages will be installed:
apache2 apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libcap2
0 upgraded, 10 newly installed, 0 to remove and 3 not upgraded.
Need to get 3,248 kB of archives.
After this operation, 11.7 MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
Get:1 oneiric/main libcap2 amd64 1:2.21-2 [12.2 kB]
Get:2 oneiric/main libapr1 amd64 1.4.5-1 [88.8 kB]
ldconfig deferred processing now taking place
Committing to: /etc/
modified .etckeeper
added apache2
added apache2/apache2.conf
added apache2/conf.d
added apache2/envvars
added apache2/httpd.conf
added apache2/magic
added apache2/mods-available
added apache2/mods-enabled
added apache2/ports.conf
added rc6.d/K09apache2
added ufw/applications.d/apache2.2-common
Committed revision 6.

So, we can see that as well as installing Apache, apt-get has committed the changes to the /etc/ directory as well. If you want to see what those changes are, you can using the "bzr log" command as below:

$ sudo bzr log /etc/apache2/httpd.conf
revno: 6
committer: srdan
branch nick: etckeeper1 /etc repository
timestamp: Thu 2011-12-29 12:05:11 +1300
committing changes in /etc after apt run

Package changes:
+apache2 2.2.20-1ubuntu1.1
+apache2-mpm-worker 2.2.20-1ubuntu1.1
+apache2-utils 2.2.20-1ubuntu1.1
+apache2.2-bin 2.2.20-1ubuntu1.1
+apache2.2-common 2.2.20-1ubuntu1.1
+libapr1 1.4.5-1
+libaprutil1 1.3.12+dfsg-2
+libaprutil1-dbd-sqlite3 1.3.12+dfsg-2
+libaprutil1-ldap 1.3.12+dfsg-2
+libcap2 1:2.21-2

So from the above output we can see who made the last change to this file, we can see that it was made as a part of an "apt" run and we can see the list of other packages that were installed as a part of this run.

When you make a change to any files under /etc directly, the changes aren't committed straight away, but are rather committed daily (probably by a cron job). To see whether there are any files which have been modified but not committed, use the "bzr status" command:

$ sudo bzr status /etc

And to commit the change manually, use the "etckeeper commit" command:

$ sudo etckeeper commit "Changed the email address of the default webmaster"
Committing to: /etc/
modified apache2/sites-available/default
Committed revision 7.

Hopefully this has been a good introduction to etckeeper and it's use. While it won't stop people breaking things due to bad configuration, at least it can be helpful for preserving a working config and quickly determining what changes were made, by who and for what reason.

Sunday, 18 December 2011

belongsTo Relationships in Grails and DB schema

There are three (two actually as far as DB schemas are concerned) types of belongsTo relationships in Grails:

The first one "belongsTo = [customer: Customer" defines a one-to-one relationship between CustomerOrders and Customers. It stores the reference in the "CUSTOMER_ORDER" table in a "CUSTOMER_ID" column:

The second and third types of belongsTo relationships produce the same type of schema, with neither the "CUSTOMER" or "CUSTOMER_ORDER" tables containing references to each other, but rather that relationship information being kept in a "CUSTOMER_CUSTOMER_ORDER" table.

How to view HSQLDB grails contents

If you're working with Grails it's sometimes very useful to be able to view the layout and contents of the database that you're working with. If you're using the default HSQLDB engine that comes with Grails, one of the ways to achieve this is to launch the "Database Manager" application from your BootStrap file, giving you a GUI which you can use to explore the database.

class BootStrap {
def init = { servletContext ->
def destroy = {
This will result in the Database Manager GUI being launched:

You just need to change the last part of the URL to "devDB" (or whatever you've chosen to name your development database) and hit the "Ok" button. You should be presented with the Database Manager's default screen, showing all of the tables in a list on the left.

Selecting the + next to each table allows you to see the columns/fields of each table and so forth. Entering SQL commands in the text portion and hitting the 'Execute' button, while using the application will allow you to see the contents of your database in real-time.

Note that closing the Database Manager window will close the application.

Additionally the Database Manager program is available from the "universe" debian and ubuntu repositories under the package name "hsqldb-utils". However I was unable to connect to the in-memory HSQLDB instance from a Database Manager instance launched outside of Grails. I'm assuming this is because it's launched as a seperate process, it gets its own memory space. It should be possible to get it to connect to the HSQLDB instance when using a file based database.

NOTE: The above instructions apply to pre 2.0 Grails versions. Since Grails 2.0, the way to see the Database schema has been to access the web interface, which is launched automatically at: http://localhost:8080/[ApplicationName]/dbconsole. You might need to change the URL, but shouldn't have to enter a password.