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
>
>