Thread: [Refdb-users] was database too old or corrupt error on debian ever solved
Status: Beta
Brought to you by:
mhoenicka
Menu
▾
▴
refdb-users
|
From: Daniel O'D. <dan...@ul...> - 2006-05-29 03:43:29
|
Hi, I'm making one of my periodic attempts to get refdb set up under Ubuntu (this time in dapper using mysql5). I've got the database too old or corrupt error again. As this ever been solved? This installation was on a clean system. -d -- Daniel Paul O'Donnell, PhD Associate Professor and Chair Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> Department of English University of Lethbridge Lethbridge AB T1K 3M4 Tel. +1 (403) 329-2378 Fax. +1 (403) 382-7191 :@wiglaf (dapper ubuntu) |
|
From: Markus H. <mar...@mh...> - 2006-05-29 09:14:53
|
Hi Daniel, as much as I'd like to resolve this issue before the next release (I'm almost done), I was not able to reproduce it yet. I need input from anyone who ever bumped into this problem. Unfortunately it is likely that users experiencing this problem get frustrated and toss refdb instead of subscribing to the list. Did you run the tests that I suggested in my previous reply: http://sourceforge.net/mailarchive/forum.php?thread_id=10200584&forum_id=1798 regards, Markus Daniel O'Donnell <dan...@ul...> was heard to say: > Hi, > > I'm making one of my periodic attempts to get refdb set up under Ubuntu > (this time in dapper using mysql5). I've got the database too old or > corrupt error again. > > As this ever been solved? This installation was on a clean system. -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Dan O'D. <dan...@ul...> - 2006-05-29 16:13:27
|
A redfaced solution. I think I figured out what the problem is. It doesn't speak well of me, but since I hate people who answer their own queries with "nevermind, I solved it" I'll specify: There were always two problems: 1) I was getting a dbase too old or corrupt, and 2) I didn't seem to be using MySql. The solution to both problems lay in the config files: you need to change the default dbase to MySql (if that's what you want), and you need to change the default username to whatever is required by the dbase. This gets rid of the errors I've been having all along. Now I don't seem able to able to finish the creation or new users or databases, but that may be simply a result of my never reading the manual past trouble shooting, since I couldn't get past the "main db corrupt" error. -d On Mon, 2006-29-05 at 11:14 +0200, Markus Hoenicka wrote: > Hi Daniel, > > as much as I'd like to resolve this issue before the next release (I'm almost > done), I was not able to reproduce it yet. I need input from anyone who ever > bumped into this problem. Unfortunately it is likely that users experiencing > this problem get frustrated and toss refdb instead of subscribing to the list. > Did you run the tests that I suggested in my previous reply: > > http://sourceforge.net/mailarchive/forum.php?thread_id=10200584&forum_id=1798 > > regards, > Markus > > Daniel O'Donnell <dan...@ul...> was heard to say: > > > Hi, > > > > I'm making one of my periodic attempts to get refdb set up under Ubuntu > > (this time in dapper using mysql5). I've got the database too old or > > corrupt error again. > > > > As this ever been solved? This installation was on a clean system. > > > -- Daniel Paul O'Donnell, PhD Acting Chair and Associate Professor of English Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 (403) 329-2378/-2377 Fax: +1 (403) 382-7191 |
|
From: Markus H. <mar...@mh...> - 2006-05-29 16:36:30
|
Hi Dan, Holy s...! We could have solved this months ago by simply looking at the output of the refdb-bug script (which was designed to find configuration errors like this). I should have insisted on having a look. Flexibility seems to have its price. How can we prevent mishaps like this one in the future? Better debug information? Better error messages? Better docs? All of the above? regards, Markus Dan O'Donnell <dan...@ul...> was heard to say: > A redfaced solution. > > I think I figured out what the problem is. It doesn't speak well of me, > but since I hate people who answer their own queries with "nevermind, I > solved it" I'll specify: > > There were always two problems: 1) I was getting a dbase too old or > corrupt, and 2) I didn't seem to be using MySql. The solution to both > problems lay in the config files: you need to change the default dbase > to MySql (if that's what you want), and you need to change the default > username to whatever is required by the dbase. > > This gets rid of the errors I've been having all along. Now I don't seem > able to able to finish the creation or new users or databases, but that > may be simply a result of my never reading the manual past trouble > shooting, since I couldn't get past the "main db corrupt" error. > -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Rich S. <rsh...@ap...> - 2006-05-29 16:50:17
|
On Mon, 29 May 2006, Markus Hoenicka wrote: > Flexibility seems to have its price. How can we prevent mishaps like this > one in the future? Better debug information? Better error messages? Better > docs? All of the above? Markus, Perhaps by not letting us new users install the software until we've read the admin manual completely -- and passed a test on it. :-) Of course, your mail volume would drop substantially in this case, but that might be a Good Thing. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc.(TM) | Accelerator <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
|
From: Markus H. <mar...@mh...> - 2006-05-29 17:00:33
|
Rich Shepard <rsh...@ap...> was heard to say: > Markus, > > Perhaps by not letting us new users install the software until we've read > the admin manual completely -- and passed a test on it. :-) > The RCSI (RefDB certified system installer) test? Let's see whether I can incorporate a multiple choice test into the configure script... regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Dan O'D. <dan...@ul...> - 2006-05-29 17:04:09
|
While agreeing with Rich, I think this specific case the solution would be to add a line to the troubleshooting page, since it is a recurring problem, and we have similar specific and common error messages already listed there. Basically two lines, one saying: "Main Database to Old or Corrupt": the most likely cause of this error is a faulty setting in the config. files. Check that you have indicated the correct database in file xxx; and also that you have changed the user name in xxxx." I also think there should be an indication that the desired dbase system needs to be set in the config files, otherwise the default is SqlLite. Finally, I wonder if supplying values for dbase and username in the config files is really wise, especially in the case of the dbase username (nobody is likely to use Joe User, so this can ONLY cause trouble), and probably in the case of SqlLite, since many people will want to use either MySql or PostGres. A better approach IMO would be to use a script to ask users for the username and dbase server type (the way mediawiki do for username); failing that leaving them blank and *requiring* users to fill in the requisite fields of the config files might be an answer that would prevent some grief. Since they have to go in to change the username anyway, it seems to me not to hurt the installation setup process any. -d On Mon, 2006-29-05 at 09:49 -0700, Rich Shepard wrote: > On Mon, 29 May 2006, Markus Hoenicka wrote: > > > Flexibility seems to have its price. How can we prevent mishaps like this > > one in the future? Better debug information? Better error messages? Better > > docs? All of the above? > > Markus, > > Perhaps by not letting us new users install the software until we've read > the admin manual completely -- and passed a test on it. :-) > > Of course, your mail volume would drop substantially in this case, but that > might be a Good Thing. > > Rich > -- Daniel Paul O'Donnell, PhD Acting Chair and Associate Professor of English Director, Digital Medievalist Project <http://www.digitalmedievalist.org/> University of Lethbridge Lethbridge AB T1K 3M4 Canada Vox: +1 (403) 329-2378/-2377 Fax: +1 (403) 382-7191 |
|
From: Markus H. <mar...@mh...> - 2006-05-29 23:00:32
|
Dan O'Donnell writes: > While agreeing with Rich, I think this specific case the solution would > be to add a line to the troubleshooting page, since it is a recurring > problem, and we have similar specific and common error messages already > listed there. Basically two lines, one saying: "Main Database to Old or > Corrupt": the most likely cause of this error is a faulty setting in the > config. files. Check that you have indicated the correct database in > file xxx; and also that you have changed the user name in xxxx." > I've added a few lines about the database too old or corrupt error. The username/password stuff is already explained in that section as it causes a different kind of error message. > I also think there should be an indication that the desired dbase system > needs to be set in the config files, otherwise the default is SqlLite. > This is already described in the manual as well as in the ./configure --help output (but it is a known fact that users don't read. I'm not complaining here, it is just a fact we have to live with and work around if possible). > Finally, I wonder if supplying values for dbase and username in the > config files is really wise, especially in the case of the dbase > username (nobody is likely to use Joe User, so this can ONLY cause > trouble), and probably in the case of SqlLite, since many people will > want to use either MySql or PostGres. > This is basically a good point. The clients are written to use the login name as a fallback if no database user name is supplied. I'll change the config files accordingly. > A better approach IMO would be to use a script to ask users for the > username and dbase server type (the way mediawiki do for username); > failing that leaving them blank and *requiring* users to fill in the > requisite fields of the config files might be an answer that would > prevent some grief. Since they have to go in to change the username > anyway, it seems to me not to hurt the installation setup process any. > I have pondered this too, but I've seen problems everywhere. I'm not sure whether package builders can handle this appropriately, since RefDB is usually split at least into a server and a client package which need to be configured differently. And besides, if users don't care to configure their config files because they don't know they have to, would they be likely to run a script that they don't know about? That's why I attempted to put as much configuration as possible into the most natural place for this - the configure script. In any case, I welcome any suggestions to handle this better, as the current approach apparently causes more problem than I'd like. Please feel free to let the ideas flow. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: <ste...@jo...> - 2006-05-30 08:59:33
|
Markus Hoenicka a =E9crit : > Dan O'Donnell writes: > > While agreeing with Rich, I think this specific case the solution wo= uld I agree! > > A better approach IMO would be to use a script to ask users for the > > username and dbase server type (the way mediawiki do for username); > > failing that leaving them blank and *requiring* users to fill in the > > requisite fields of the config files might be an answer that would > > prevent some grief. Since they have to go in to change the username > > anyway, it seems to me not to hurt the installation setup process an= y. > >=20 >=20 > I have pondered this too, but I've seen problems everywhere. I'm not > sure whether package builders can handle this appropriately, since > RefDB is usually split at least into a server and a client package > which need to be configured differently. And besides, if users don't > care to configure their config files because they don't know they have > to, would they be likely to run a script that they don't know about? > That's why I attempted to put as much configuration as possible into > the most natural place for this - the configure script. >=20 > In any case, I welcome any suggestions to handle this better, as the > current approach apparently causes more problem than I'd like. Please > feel free to let the ideas flow. >=20 > regards, > Markus As a packager, one suggestion i could do is to split (or *pluginize*)=20 the db connectors. Like this, one refdb-server package could exist=20 (using by default sqlite) and if the mysql or pgsql connector is present=20 then it is used. i'm not sure this is trivial, but i see one major advantage :=20 facilitating password/users and db maintenance (the connector would need=20 to be filled with those informations to work), getting the possibility=20 to have other db connectors (after all, you're not working on db, but on=20 biblio stored on a db). As i said i'm not using it for now (i must finish the packages *and*=20 test them) but i'm on my way to, and this is one point that seems an=20 improvement, since you're asking for new directions ;-) Keep up the work! Yours, St=E9phane --=20 St=E9phane T=E9letch=E9a, PhD. http://www.steletch.org Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f= r/mig INRA, Domaine de Vilvert T=E9l : (33) 134 652 891 78352 Jouy-en-Josas cedex, France Fax : (33) 134 652 901 |
|
From: Markus H. <mar...@mh...> - 2006-05-30 19:33:19
|
St=E9phane T=E9letch=E9a writes: > As a packager, one suggestion i could do is to split (or *pluginize*= )=3D20 > the db connectors. Like this, one refdb-server package could exist=3D= 20 > (using by default sqlite) and if the mysql or pgsql connector is pre= sent=3D20 > then it is used. >=20 What precisely do you mean with "db connectors"=3F What would these packages contain=3F As far as RefDB is concerned, you switch between database engines by changing one or two entries in refdbdrc and by creating the main database using the new engine.=20 regards, Markus --=20 Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: <ste...@jo...> - 2006-05-31 10:18:44
|
Markus Hoenicka a =E9crit : > St=E9phane T=E9letch=E9a writes: > > As a packager, one suggestion i could do is to split (or *pluginize*= )=3D20 > > the db connectors. Like this, one refdb-server package could exist=3D= 20 > > (using by default sqlite) and if the mysql or pgsql connector is pre= sent=3D20 > > then it is used. > >=20 >=20 > What precisely do you mean with "db connectors"? What would these > packages contain? As far as RefDB is concerned, you switch between > database engines by changing one or two entries in refdbdrc and by > creating the main database using the new engine.=20 >=20 > regards, > Markus >=20 I may have misunderstood, but while packaging, i'm using those options : ./configure --disable-docs --with-db-server=3Dpgsql --disable-rpath * the --disable-docs is for avoiding the doc building problem (and since=20 they are provided, there is no point in having a rebuilding), * --disable-rpath is to avoid the warning * i used --with-db-server=3Dpgsql Ok, after reading again p29 of the manual (chpater 4 - Installation), i=20 see the option -with-db-server is only for getting preconfigurations for=20 pgsql, mysql or sqlite, but all of them will be ok with the correct=20 configuration file ... Is there a mean to provide the three=20 configurations so the admin can link the correct one to its situation ? Otherwise, i'll consider adding them on the package, using 3 differents=20 builds to get the environnment in /usr/local/etc/refdb/* Thanks for the clarification, this was my last limiting step. As a sidenote, the command line on page 42 (the sed replacement for=20 InnoDB in mysql) is truncated :-) St=E9phane --=20 St=E9phane T=E9letch=E9a, PhD. http://www.steletch.org Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f= r/mig INRA, Domaine de Vilvert T=E9l : (33) 134 652 891 78352 Jouy-en-Josas cedex, France Fax : (33) 134 652 901 |
|
From: Markus H. <mar...@mh...> - 2006-05-31 10:34:49
|
Hi, St=E9phane T=E9letch=E9a <ste...@jo...> was heard to say: > I may have misunderstood, but while packaging, i'm using those options = : > > ./configure --disable-docs --with-db-server=3D3Dpgsql --disable-rpath > > * the --disable-docs is for avoiding the doc building problem (and sinc= e=3D20 > they are provided, there is no point in having a rebuilding), I believe I've figured out the problem why make attempted to rebuild the = docs although they were there. This should be fixed in the upcoming 0.9.7, and= you should be able to make do without this switch. > * --disable-rpath is to avoid the warning > * i used --with-db-server=3D3Dpgsql > > Ok, after reading again p29 of the manual (chpater 4 - Installation), i= =3D20 > see the option -with-db-server is only for getting preconfigurations fo= r=3D20 > pgsql, mysql or sqlite, but all of them will be ok with the correct=3D2= 0 > configuration file ... Is there a mean to provide the three=3D20 > configurations so the admin can link the correct one to its situation ? > Otherwise, i'll consider adding them on the package, using 3 differents= =3D20 > builds to get the environnment in /usr/local/etc/refdb/* I could provide refdbdrc.mysql, refdbdrc.pgsql and so on as templates preconfigured for the supported database engines. They would all receive = the other relevant modifications (var dir, log dir etc) and be installed as refdbdrc.mysql.example and so on. Users could copy and edit these files appropriately. Package builders could just set a symlink to the appropria= te file, depending on which database engine the user selected when configuri= ng the package. Is that what you meant? I think this is a good solution. > > Thanks for the clarification, this was my last limiting step. > > As a sidenote, the command line on page 42 (the sed replacement for=3D2= 0 > InnoDB in mysql) is truncated :-) > Thanks for the reminder. I try to fix these truncated lines (there must b= e a few in the manual) before 0.9.7 is officially released. regards, Markus --=20 Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Markus H. <mar...@mh...> - 2006-05-30 20:10:15
|
Hi Dan, Markus Hoenicka writes: > > Finally, I wonder if supplying values for dbase and username in the > > config files is really wise, especially in the case of the dbase > > username (nobody is likely to use Joe User, so this can ONLY cause > > trouble), and probably in the case of SqlLite, since many people will > > want to use either MySql or PostGres. > > > > This is basically a good point. The clients are written to > use the login name as a fallback if no database user name is > supplied. I'll change the config files accordingly. > I checked the config file examples, and none of them defines a database username, so all should be well. Where did you take "Joe User" from? Is that something you typed off the manual? BTW the reason to pick SQLite as a default was to allow the easiest possible package installation using precompiled binaries. RefDB needs at least one database engine to start with, and SQLite is small and requires no administration. That is, with some script magic a *BSD or Linux package builder can package RefDB in a way that it is ready to run right after installation. Setting up the refdb database in MySQL or PostgreSQL.requires knowledge of the database admin password, and in the case of PostgreSQL it may require running commands from the postgres user account. This is far harder to do from a run-of-the-mill installation script. Therefore David (the now-gone Debian package builder) convinced me to use SQLite as a default in the tarball too. You just have to provide the proper switch to the ./configure script to use a different engine. That script even prints your choice at the end of the output to make sure you notice what it did. It's just hard to find a way to make users aware of the configure switch in time. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Markus H. <mar...@mh...> - 2006-05-29 09:22:04
|
Hi, I just recalled a nifty "feature" of PostgreSQL on Debian. To increase security, you had to be logged in as the postgres (or pgsql, don't recall the exact name) user in order to do administrative stuff. Does anyone know whether MySQL on Debian uses a similar trick these days? regards, Markus Markus Hoenicka <mar...@mh...> was heard to say: > Hi Daniel, > > as much as I'd like to resolve this issue before the next release (I'm almost > done), I was not able to reproduce it yet. I need input from anyone who ever > bumped into this problem. Unfortunately it is likely that users experiencing > this problem get frustrated and toss refdb instead of subscribing to the > list. -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Rich S. <rsh...@ap...> - 2006-05-29 13:51:39
|
On Mon, 29 May 2006, Markus Hoenicka wrote: > I just recalled a nifty "feature" of PostgreSQL on Debian. To increase > security, you had to be logged in as the postgres (or pgsql, don't recall > the exact name) user in order to do administrative stuff. Does anyone know > whether MySQL on Debian uses a similar trick these days? Markus, No, I don't know that answer because I don't use mysql. For future reference, the username is 'postgres' in PostgreSQL. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc.(TM) | Accelerator <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X