Building the RIPEDB server

         imported      Tech · Work · ISP · RIPE

It took me a few hours over the course of this week to build the RIPE whois server for some internal projects – given that there seems to be a very limited amount of documentation for the build process, and threads on mailing lists, I’m going to post this here. I hope that it gets picked up by Google.

The first problem that is encountered is that the libtool that is included with the whois server does not support ‘modern’ tags, such as –tag=CC. This looks to be because the included libtool is somewhat dated. This can be easily fixed by using the system libtool: 

[rjs@dbhost whoisserver-nightly]$ mv libtool libtool.old
[rjs@dbhost whoisserver-nightly]$ ln -s which libtool .
(NB: after doing this, you should specify –no-all –setup-db –setup-config –install –setup-tests, and NOT –configure, otherwise the existing libtool will just replace the symlink that you’ve created)

The next problem is that there are a large number of definitions of yywrap() that conflict when they are being linked. On examination, these seem to be of the form: 
int yywrap(){
    return 1;
}
There are definitions in: that conflict with each other. Simply removing the yywrap function that only returns 1 from each of these files resolves this linker issue.

The next problem is that there is a multiple definition of a ‘set_dynamic’ function – I believe that this is a function that’s used both in the src/modules/pc/pc_commands.c files, and in the MySQL headers. 
/usr/lib/mysql/libmysqlclient_r.a(array.o): In function set_dynamic':
/home/mysqldev/rpm/BUILD/mysql-4.1.22/libmysql_r/array.c:175: multiple definition ofset_dynamic’
/home/rjs/tmp/whoisserver-nightly/src/.././src/librip.a(pc_commands.o):
/home/rjs/tmp/whoisserver-nightly/src/modules/pc/pc_commands.c:509: first defined here
/usr/bin/ld: Warning: size of symbol `set_dynamic’ changed from 366 in
/home/rjs/tmp/whoisserver-nightly/src/.././src/librip.a(pc_commands.o) to 203 in
/usr/lib/mysql/libmysqlclient_r.a(array.o)
The first definition (/home/mysqldev/rpm/BUILD/…) is from the RPM package of the shared MySQL libraries. I’ve tried the compatibility libraries, as well as versions from MySQL 4.1, and MySQL 4.0. The only way I can find to correct this is to change where the include path is from the files that are provided by the MySQL development libraries, to the shared libraries provided by MySQL: 
[rjs@dbhost whoisserver-nightly]$ diff Makefile Makefile.orig
214c214



< MYSQL_LIBS = -L/usr/lib/ -lmysqlclient_r -lz -lcrypt -lnsl -lm





MYSQL_LIBS = -L/usr/lib/mysql -lmysqlclient_r -lz -lcrypt -lnsl -lm
[rjs@dbhost whoisserver-nightly]$ diff src/Makefile src/Makefile.orig
378c378



< MYSQL_LIBS = -L/usr/lib/ -lmysqlclient_r -lz -lcrypt -lnsl -lm



MYSQL_LIBS = -L/usr/lib/mysql -lmysqlclient_r -lz -lcrypt -lnsl -lm
This then allows the whoisd to compile.

However, when starting the server a number of segmentation faults are experienced: 
[rjs@dbhost bin]$ ./whoisd_start –config=rip.config –crashes=1
Starting whois-server daemon with configuration
/home/rjs/whoistmp//conf/rip.config from /home/rjs/whoistmp//bin
./whoisd_start: line 165: 23118 Segmentation fault      (core dumped) $NOHUP_NICENESS $WHOISRIP -p $pid_file -c ${CONFIG} >> $err_log 2>&1
mv: cannot stat core': No such file or directory
./whoisd_start: line 165: 23145 Segmentation fault      (core dumped) $NOHUP_NICENESS $WHOISRIP -p $pid_file -c ${CONFIG} >> $err_log 2>&1
mv: cannot statcore’: No such file or directory
081008 11:24:36  $WHOISD ended
This is because the MySQL connections do not work correctly out of the box – what you will need to do is to go to src/SQL/ and create the DB manually: 
[rjs@dbhost SQL]$ mysql -utest_db -pPASSWORD test_db < create.tables.sql
[rjs@dbhost SQL]$ mysql -utest_db -pPASSWORD test_db < main.index.1
As long as your $PREFIX/conf/sources.config is correct (correct U/P for the object database, not the admin db), and the rip.conf has the admin DB specified correctly – then the server should then start.

This was originally going to be an e-mail to ripe-dbm, but I seem to have fixed it during the course of writing the mail!