From The Linux Foundation
Jump to: navigation, search

Obtaining the Database

The LSB specification database can be obtained from LSB version control (bazaar):

bzr branch http://bzr.linuxfoundation.org/lsb/devel/specdb

The specdb module holds `*.sql` files which mirror the schema of the LSB database. The `*.init` files populate the database with library and header information required by various tools and scripts.

NOTE: the above is for the unreleased development version. To get the production version, subsitute devel for version number (3.1, 3.2, etc.).

Obtaining the Community Part of the Database

Bazaar doesn't store data files for community part of the database (since this data is too huge to be handled by Bazaar, and there is actually no need in this). For some purposes (e.g., for application analysis in Navigator) community tables are vital. A tarball with required files is located at the LF ftp server. All files from that tarball should be copied to the specdb folder obtained from Bazaar.

Setting up the MySQL server

Make sure that the following lines are present in the `[mysqldump]` section of your MySQL configuration file (commonly found at /etc/my.cnf or /etc/mysql/my.cnf)

: quote-names=false
: extended-insert=false

Creating the LSB MySQL admin user

1. Start the mysql server and set the password.

sh# /sbin/chkconfig --level 35 mysqld on
sh# /sbin/service mysqld start
sh# /usr/bin/mysqladmin -u root password '<root_password>'

NOTE: On some systems MySQL daemon name may differ from 'mysqld'.

2. First, use the mysql program to connect to the server as the MySQL root user.

sh# mysql -u root -p

3. At the `mysql` prompt

mysql> GRANT ALL PRIVILEGES ON *.* TO 'lsbadmin'@'localhost' IDENTIFIED BY '<password>' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'lsbadmin'@'%' IDENTIFIED BY '<password>' WITH GRANT OPTION;
myqsl> exit

4. At the shell prompt

sh# mysqladmin -u root -p reload

NOTE: More fine-grained access control is specified in the dbperms.sql file within the repository.

Environment Variables

Almost all scripts and tools require to access the database after querying for shell environment variables. The following variables will also be referred to when initializing the database. It is useful to put the following in a file called 'environ.sh' and source it.

WARNING: Most Scripts/Tools WILL NOT work if these variables are NOT set

LSBDBHOST=localhost   # The name of the host which hosts the MySQL database server>
LSBDB=lsb             # The name of the LSB MySQL database>
LSBUSER=lsbadmin      # The name of the mysql user with access to modify the LSB MySQL database>
LSBDBPASSWD=navigat0r # The password of the mysql user who has access to the LSB MySQL database>

Optionally you may set TMPLSBDB variable indicating name of the database to be used for temporary tables. Such tables are used by Navigator and its user should be able to manage temporary tables (create, insert and select from them). Since it's impossible for MySQL to grant privileges to insert in temporary tables only (denying insert into other tables), we have to create a separate database which doesn't store normal data. Navigator's user will be granted insert privileges for the whole TMPLSBDB database.

If TMPLSBDB is not set, ${LSBDB}_tmp will be used.

NOTE: These variables could be put into .bashrc or .bash_profile files.

Initializing the Database

1. `cd` to the directory where you have checked out the database module from CVS.

sh# cd /path/to/specdb

2. create and populate the database. You can either restore all the database, including Community tables (this can take some time, the size of data is huge!):

sh# make restoreall

or populate only tables that form the specification part:

sh# make -k restore

Remember that the community tables are not in version control; they must be retrieved separately. See the directions above for more information about how to do that.

Without init files for community tables, 'make restoreall' will fail. If you want to create fake community tables (without any data), you should create empty init file for every table. The list of such file can be found below, in the .bzrignore example.

Submitting Changes to the Main Database

This is an abstraction of the 00README file written by NickStoughton available in the specdb bazaar branch. PLEASE read this file before making changes or the consequences may be dire. This procedure seems convoluted but it is designed to isolate from changes in the mysqldump output format, which seem to happen fairly frequently as MySQL evolves. If you're lucky enough to produce identical output to the checked-in dump in bazaar, you wouldn't need the step of first dumping your local copy in order to do the diffs.

Step 1

Create a local copy of the SpecDatabase. This can be done by following the instructions given above.

Step 2

Create a dump of your local database -

sh# cd specdb
sh# make dump 
sh# mkdir old_dump
sh# cp *.init *.sql old_dump/

Step 3

After making your changes to the local database -

sh# make dump
sh# mkdir new_dump
sh# cp *.init *.sql new_dump/

Step 4 (FIXME)

Generate a diff -

sh# diff -u new_dump/ old_dump/ | grep '^+[^+]'

(Note:Your mileage may vary with the above command, It helped me in one particular case)

Step 5

Generate SQL statements script from the diff output.

Note: Care needs to be taken that the database changes occur in the right order in the SQL script. for eg. If a column characterstics change from <NULL> to <NOT NULL>, Insert or Update commands might fail if they are run BEFORE the column properties are changed

Step 6

Test your changes. Make sure that they do not break anything.

Step 7

Send the SQL statements script to the designated database gatekeeper along with a Changelog.


The are some known problems that can arise during database setup and data population. Here is their short classification and solutions:

  • Errors concerning read permissions on the specdb directory ('cannot create file or something like this)
    1. Make sure that the mysql daemon can read this directory contents. Since community data is restored through mysql's 'load data infile', all file operations are performed by mysql's user (usually also named 'mysql').
    2. If all permissions are set properly, but mysql still reports that it cannot find file, make sure you don't have restrictive rules for SElinux or AppArmor that prevent mysql from reading files from your directory. For example, there was a known issue with Ubuntu 8.04 concerning AppArmor profiles: launchpad bug 244406.
  • Complaining about 'syntax error near IF EXISTS ' in the 'DROP TRIGGER IF EXISTS' statement - 'DROP TRIGGER IF EXISTS' is supported since MySQL 5.0.32. If you have older version, you should through away such statements from the 'create_triggers.sql' file and drop the triggers manually (if they exist; surely, if you set up the database for the first time then you have nothing to drop).
  • ERROR 1227 (42000) at line 9: Access denied - you need the SUPER privilege for this operation - well, this is self-explaining message. In MySQL < 5.1.6, there is no special privilege for triggers creation. You should operate with the database through user with SUPER privilege. If this is not possible, the only solution is to comment out call to 'create_triggers.sql' in the makefile.

Bzr Tricks

To say bazaar to ignore files related to community tables, one should create .bzrignore file in the specdb folder and list all files in question there.

This is how .bzrignore should look like at the moment: