First of all, sorry for the very late reply ;-). On Friday 07 March 2008 04:12:13 am David Kuehling wrote: > >>>>> "Christian" == Christian Grothoff <[EMAIL PROTECTED]> 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 _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
