help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnunet] mysql database setup


From: Christian Grothoff
Subject: Re: [Help-gnunet] mysql database setup
Date: Mon, 14 Apr 2008 20:35:30 -0600
User-agent: KMail/1.9.9

First of all, sorry for the very late reply ;-).

On Friday 07 March 2008 04:12:13 am David Kuehling wrote:
> >>>>> "Christian" == Christian Grothoff <address@hidden> writes:
> >
> > Interesting, I didn't think there was much to the mysql-setup given
> > that there is mysql_set_permission.
>
> Well, as far as the current GNUnet documentation is concerned, setting
> up the database is quite a hurdle:
>
>   http://www.gnunet.org/user_afs.php3?xlang=English#mysql
>
> mysql_setpermission is nowhere mentioned there.  Also, for people like
> me, who never ever installed or worked or read about mysql (or databases
> in general), all this is non-trivial.  Especially if your database
> breaks and you want to recreate it.  Nobody would assume, that the
> delete command is named "DROP".  And googling for that took me lots of
> time (googling for "mysql commands" turns up this:
> http://dev.mysql.com/doc/refman/5.0/en/mysql-commands.html which is
> completely useless, since database creatiion is in section "mysql data
> manipulation statemens" who would guess that?).

If you want to improve the online documentation, checkout the GNUnet-docs/WWW/ 
directory and e-mail me diffs, I'll be happy to put improvements on-line ;-).

> > I wonder why you hardwired things like "~/.my.cnf" (where the path
> > maybe different and can be specified in gnunetd.conf)
>
> Oh really, I just overlooked.  I also guess that the gnunet user and the
> username used for the database need not be the same?

Correct.

> > and then ask the user to manually delete certain files -- given
> > gnunetd.conf and some grep/awk-ing (or using gnunet-update's "-g"
> > option) you should be able to determine all of those paths and
> > automate these bits as well.
>
> Well, I actually wanted to auto-delete those things, but I did not want
> to parse the config file from a shell script.  Asking the user to
> manually delete was more like a todo entry so people like you can
> comment on how that could be done right :)

Well, deletion could be easily done in a shell script with a line like this:

cat old-config-file | grep -v "the line to delete" > new-config-file

> > Especially for a Debian package, that level of automation might be
> > nice.
>
> Yes, that somehow was the point of my proof-of-concept script.
>
> > I'll be happy to add the script to contrib/; I just wonder if it would
> > just contribute to the wasteland of undocumented and largely unknown
> > scripts there.
>
> Absolutely positive.  This was more meant for discussion on the mailing
> list.
>
> > Maybe we should make this one part of gnunet-update for the
> > 0.8.0-release? (for systems running gnunet-update when migrating from
> > 0.7.3?).
> >
> > Comments? Further suggestions?
>
> Making this part of gnunet-update would not allow deletion of databases?
> If this were part of a Debian package, than complete removal of the
> package should also remove the database.

With --purge, yes.  gnunet-update could remove DBs -- given permission.  
Naturally, doing it in the .deb properly maybe better.

> Given your comments, I would propose the following:
>
> Add a new binary program to GNUnet: 'gnunet-mysql' (or similar name),
> that does what the shell script does, but uses GNUnet's config file
> parser to read and update the config file and create or delete
> databases, plus updating/invalidating all the meta-data files
> (bloomfilter etc.).  I would like GNUnet to use a my.cnf file in the
> GNUNETD_HOME directory (if present).  Such a private file could also be
> written by gnunet-update/gnunet-mysql without worrying about
> side-effects.

I'm not sure if we strictly need a new binary (gnunet-mysql) or if (given some 
reasonable C code) we should not integrate this into gnunet-update.  But the 
idea is fine.

> I would even volunteer for implementation, but don't expect anything
> before may :) Well, or if somebody more qualified with mysql did the
> setup program, then I'd be happy to test and contribute Debian
> (un)installation scripts that (non)interactively configure the database.

May is fine, I don't think I'd get to it earlier ;-).  As for Debian-scripts, 
you'll need to check with Daniel to see what he'd like to have.

> With my current experience sqlite performance is very weak compared to
> mysql (ie HDD LED constantly glowing).  Any chance that mysql can be made
> the default for Debian/Ubuntu packages?

Again, that's Daniel's call, I see advantages and disadvantages to either 
approach (and I don't know how one would give the user the choice while 
keeping the (Debian) maintainers sane ;-) ).

Christian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]