refdb-users

[Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi all,

there's yet another prerelease available for testing. Please use these
files:

http://refdb.sourceforge.net/pre/refdb-0.9.3-pre5.tar.gz
http://refdb.sourceforge.net/pre/RefDB-perlmod-0.3_pre1.tar.gz
http://refdb.sourceforge.net/pre/RefDBClient-Client-1.5.tar.gz

This prerelease fixes a segfault (big oops) and a couple of minor
issues. 

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi Jakob,

(moving back to the list where you apparently meant to send your mail)

Jakob Beetz writes:
 > 1. I was not able to get make test through, none of the subtests in 
 > test.pl was able to connect to the database when sending plain passwords 
 > in the coresponding subs in  Client.pm ( $cmd .= "-w $self->{passwd} "; 
 > ).  I could partly "solve" this by replacing the above lines with $cmd 
 > .= "-w $self->{numberized_passwd} "; which resolved the issue for most 
 > tests (however  10..21 still fails with "failed to connect to database 
 > server", strange enough the second call to $clientc->refdb_addref passes 
 > a different -w $self->{numberized_passwd} to refdbd after 9..10 
 > succeeded...)
 > 

Your fix was absolutely correct. I never came across these typos as I
run tests mostly on a SQLite database which doesn't care about
username and password.

$self->{numberized_passwd} will be different for each test as each
connection to refdbd will result in a fresh scramble string which is
used to encode the password.

 > 
 > 2. after "solving" this issue, refdb_addref could not be executed, 
 > stating "cannot lock tables" for  "testuser" created during the 
 > execution of test.pl. What I did was adding LOCK TABLES to the GRANT 
 > statements in refdba.c line 1176 ff. (However, as I did not want to 
 > touch the default rights to refdb1 I manually added LOCK TABLES for 
 > "testuser" (for the call  "LOCK TABLES [...] refdb1.t_journal_words 
 > WRITE" in 9..21))
 > 

This fix should not be required unless there is a MySQL version issue
at work (I still use a 3.23 release). The real problem was an
uninitialized pointer that happened to be NULL in all my previous
tests. Besides, the reference data used in make test did not match the
latest risx.dtd and thus would have given strange results anyway.

I've fixed all these issues. Please test the new prereleases as
announced in a separate mail and see whether your table locking issue
still persists.

thanks for your testing
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Jakob B. <J....@bw...>]

Hi Markus, all,

thanks for the quick fix!
I testested it this morning, the numberized_passwd issues went like a 
charm out-of-the-box.
However, the "cannot lock tables" issue remains the same for my setup (I 
suppose this is a mySQL w32 issue, so maybe it is not worth investigating).
And now to the weird part ;-)
There seems to be a bug within enigma_encrypt: On _random_ occasions 
(though at least once a test.pl run) the denumberized password is 
incorectly decrypted. Here is from my refdbd log (I uncommented the 
printf in refdbd.c line 1031, hence the additional "encrypted:"... line)

/usr/src/RefDBClient-Client-1.6$> make test
logfile output:

healty - looking output here

---------------------------snip 8< --------------------

connected to database server using database:
perltest
command processing done, finish dialog now
child finished client on fd 4
adding client on fd 4
server waiting n_max_fd=4
parent removing client on fd 4
server waiting n_max_fd=3
try to read from client
serving client on fd 4 with protocol version 1
201-04-63-23
send pseudo-random string to client
listdb  -u testuser -w 121092107075
wheelpos:121092107075
encrypted:y\kK<< plain:pass<<
dbi_driver_dir went to:

dbi is up using default driver dir
131.155.xxx.xx
testuser
pass

3306
mysql

connected to database server using database:
refdb1
command processing done, finish dialog now
child finished client on fd 4
adding client on fd 4
server waiting n_max_fd=4
parent removing client on fd 4
server waiting n_max_fd=3
try to read from client
serving client on fd 4 with protocol version 1
120-80-71-20
send pseudo-random string to client
gettexbib -d perltest -s refdbteststyle -u testuser -w 121092107075  1
wheelpos:121092107075
encrypted:y\kK<< plain:Al6`<<
dbi_driver_dir went to:

dbi is up using default driver dir
131.155.xxx.xxx
testuser
Al6`
perltest
3306
mysql

failed to connect to database server
could not connect to database server
command processing done, finish dialog now
child finished client on fd 4

---------------------------snip 8< --------------------


(x-ed out my IP)

now the strange lines are
encrypted:y\kK<< plain:pass<<

and

encrypted:y\kK<< plain:Al6`<<

As I mentioned I could not find special conditions to reproduce this, it 
seems to happen at random with 'testuser:pass' . I tried with diffent 
"user:pass", same thing.
The enigma - stuff is a little bit over my head ;-), maybe you can make 
s.th. from this.

Do you have any idea?

Keep up the good work,

Cheers
Jakob


Markus Hoenicka wrote:

>Hi Jakob,
>
>(moving back to the list where you apparently meant to send your mail)
>
>Jakob Beetz writes:
> > 1. I was not able to get make test through, none of the subtests in 
> > test.pl was able to connect to the database when sending plain passwords 
> > in the coresponding subs in  Client.pm ( $cmd .= "-w $self->{passwd} "; 
> > ).  I could partly "solve" this by replacing the above lines with $cmd 
> > .= "-w $self->{numberized_passwd} "; which resolved the issue for most 
> > tests (however  10..21 still fails with "failed to connect to database 
> > server", strange enough the second call to $clientc->refdb_addref passes 
> > a different -w $self->{numberized_passwd} to refdbd after 9..10 
> > succeeded...)
> > 
>
>Your fix was absolutely correct. I never came across these typos as I
>run tests mostly on a SQLite database which doesn't care about
>username and password.
>
>$self->{numberized_passwd} will be different for each test as each
>connection to refdbd will result in a fresh scramble string which is
>used to encode the password.
>



>
> > 
> > 2. after "solving" this issue, refdb_addref could not be executed, 
> > stating "cannot lock tables" for  "testuser" created during the 
> > execution of test.pl. What I did was adding LOCK TABLES to the GRANT 
> > statements in refdba.c line 1176 ff. (However, as I did not want to 
> > touch the default rights to refdb1 I manually added LOCK TABLES for 
> > "testuser" (for the call  "LOCK TABLES [...] refdb1.t_journal_words 
> > WRITE" in 9..21))
> > 
>
>This fix should not be required unless there is a MySQL version issue
>at work (I still use a 3.23 release). The real problem was an
>uninitialized pointer that happened to be NULL in all my previous
>tests. Besides, the reference data used in make test did not match the
>latest risx.dtd and thus would have given strange results anyway.
>
>I've fixed all these issues. Please test the new prereleases as
>announced in a separate mail and see whether your table locking issue
>still persists.
>
>thanks for your testing
>Markus
>
>

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Jakob Beetz writes:
 > Hi Markus, all,
 > 
 > thanks for the quick fix!
 > I testested it this morning, the numberized_passwd issues went like a 
 > charm out-of-the-box.
 > However, the "cannot lock tables" issue remains the same for my setup (I 
 > suppose this is a mySQL w32 issue, so maybe it is not worth investigating).

I'll browse the MySQL docs and see whether anything has changed
between 3.23 and 4.x that would cause this problem. I wouldn't bet
this is a platform issue, and even if it was I'd have to work around
it.

 > And now to the weird part ;-)
 > There seems to be a bug within enigma_encrypt: On _random_ occasions 
 > (though at least once a test.pl run) the denumberized password is 
 > incorectly decrypted. Here is from my refdbd log (I uncommented the 
 > printf in refdbd.c line 1031, hence the additional "encrypted:"... line)
 > 

I've had problems with this encryption stuff before on some particular
platforms (PPC, but that's been fixed), but never on Windows, the
BSDs, Linux, or OSX. Did you run a reasonable number of tests using
the C clients directly? I'd like to know whether Perl has something to
do with it, because this part has been tested much less than the C
clients. Could be some weird quoting issue or something like that. If
I knew Perl better I'd go ahead and write a native implementation of
the encryption in Perl but I'm afraid this would take too much time
off my efforts to get 0.9.3 out the door. Any Perl gurus out there
with some spare time?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi,

Markus Hoenicka writes:
 > I've had problems with this encryption stuff before on some particular
 > platforms (PPC, but that's been fixed), but never on Windows, the
 > BSDs, Linux, or OSX. Did you run a reasonable number of tests using
 > the C clients directly? I'd like to know whether Perl has something to
 > do with it, because this part has been tested much less than the C
 > clients. Could be some weird quoting issue or something like that. If
 > I knew Perl better I'd go ahead and write a native implementation of
 > the encryption in Perl but I'm afraid this would take too much time
 > off my efforts to get 0.9.3 out the door. Any Perl gurus out there
 > with some spare time?
 > 

Ok, forget about all this. The Perl module was utterly broke. I've
uploaded a fixed version to:

http://refdb.sourceforge.net/pre/RefDBClient-Client-1.7.tar.gz

Please try again.

Thanks
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Jakob B. <J....@bw...>]

Hi Markus, all,

great work! runs very smooth, all tests ok (that is: with the 0.9.3-pre6 
with additional GRANT LOCK TABLES in dbfncs.c and  refdbda.c for 
mySQL-nt. Without these additional grants I still got "cannot lock 
tables" with make test)
Im going to start a CGI module on that basis now.

Thanks again.
Cheers
Jakob

Markus Hoenicka wrote:

>Hi,
>
>Markus Hoenicka writes:
> > I've had problems with this encryption stuff before on some particular
> > platforms (PPC, but that's been fixed), but never on Windows, the
> > BSDs, Linux, or OSX. Did you run a reasonable number of tests using
> > the C clients directly? I'd like to know whether Perl has something to
> > do with it, because this part has been tested much less than the C
> > clients. Could be some weird quoting issue or something like that. If
> > I knew Perl better I'd go ahead and write a native implementation of
> > the encryption in Perl but I'm afraid this would take too much time
> > off my efforts to get 0.9.3 out the door. Any Perl gurus out there
> > with some spare time?
> > 
>
>Ok, forget about all this. The Perl module was utterly broke. I've
>uploaded a fixed version to:
>
>http://refdb.sourceforge.net/pre/RefDBClient-Client-1.7.tar.gz
>
>Please try again.
>
>Thanks
>Markus
>
>  
>

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi Jakob,

Jakob Beetz writes:
 > Hi Markus, all,
 > 
 > great work! runs very smooth, all tests ok (that is: with the 0.9.3-pre6 
 > with additional GRANT LOCK TABLES in dbfncs.c and  refdbda.c for 
 > mySQL-nt. Without these additional grants I still got "cannot lock 
 > tables" with make test)

I'm glad the Perl issues are sorted out. I've checked the MySQL docs
today. Turns out that the LOCK TABLES privilege was indeed introduced
in MySQL 4.02, so it is a simple version issue that I have to work
around somehow.

 > Im going to start a CGI module on that basis now.
 > 

I'm looking forward to seeing your work. I'd greatly appreciate if
you decide to share the results.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi Jakob,

Markus Hoenicka writes:
 > I'm glad the Perl issues are sorted out. I've checked the MySQL docs
 > today. Turns out that the LOCK TABLES privilege was indeed introduced
 > in MySQL 4.02, so it is a simple version issue that I have to work
 > around somehow.
 > 

I've added a MySQL version check in the CVS version. It does work on
3.23.x but I'd like to know whether it works on >=4.02 too. Would you
mind testing the CVS version?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Jakob B. <j....@bw...>]

Hi Markus,

Markus Hoenicka wrote:

>I've added a MySQL version check in the CVS version. It does work on
>3.23.x but I'd like to know whether it works on >=4.02 too. Would you
>mind testing the CVS version?
>  
>
everything runs fine now! Thanks for the great work.
BTW when trying to make a fresh checkout from CVS the configure script, 
Makefile.*s and other things are missing , but that's maybe just me 
missing s.th.

best regards
Jakob

Re: [Refdb-users] ANN: RefDB 0.9.3-pre5 available

[Markus H. <mar...@mh...>]

Hi Jakob,

Jakob Beetz writes:
 > everything runs fine now! Thanks for the great work.
 > BTW when trying to make a fresh checkout from CVS the configure script, 
 > Makefile.*s and other things are missing , but that's maybe just me 
 > missing s.th.
 > 

Yes :-) You need to run ./autogen.sh to build these files. It'll be
mentioned in the next version of the manual.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de