Discussion:
bash/ldap failures
(too old to reply)
Aurélien Aptel via samba-technical
2018-03-16 10:21:03 UTC
Permalink
Raw Message
Hi,

I still run into LDAP test failures from case mismatch since last
december. Andrew mentionned it was due to some sort of bash-ism? I'd
like to understand more if anyone is willing to explain what those test
are supposed to do and have an idea what exactly fails.

I also run this failure:

FAILED: samba3.blackbox.smbclient_s3.NT1.plain (nt4_dc).volume(nt4_dc)

Error Message:
null

Stack Trace:
Traceback (most recent call last):
testtools.testresult.real._StringException: Exception: Exception: CLI_FORCE_INTERACTIVE=yes
/home/ci/workspace/samba-ci/bin/smbclient -Uci%localntdc2pass //LOCALNT4DC2/tmp -I 127.0.0.3
--configfile=/home/ci/workspace/samba-ci/st/client/client.conf -mNT1
Try "help" to get a list of possible commands.
smb: \> Volume: |tmp| serial number 0xad80a8b3
smb: \>
failed doing volume command

The test script is source3/script/tests/test_smbclient_s3.sh

echo "$out" | grep '^Volume: |tmp| serial number'
ret=$?
if [ $ret != 0 ] ; then
echo "$out"
echo "failed doing volume command"
return 1
fi

For some reason the input command ("volume\n") is not copied on the
output so the test works if you remove the ^ at the start of the grep
pattern (without the input string the "Volume:.." line ends up in the
middle of the previous line instead of a new line). Until we know we the
input is not copied in the output I can send a patch that removes that ^
check.

Cheers,
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Rowland Penny via samba-technical
2018-03-16 13:27:47 UTC
Permalink
Raw Message
On Fri, 16 Mar 2018 11:21:03 +0100
Post by Aurélien Aptel via samba-technical
Hi,
I still run into LDAP test failures from case mismatch since last
december. Andrew mentionned it was due to some sort of bash-ism? I'd
like to understand more if anyone is willing to explain what those
test are supposed to do and have an idea what exactly fails.
FAILED: samba3.blackbox.smbclient_s3.NT1.plain
(nt4_dc).volume(nt4_dc)
null
CLI_FORCE_INTERACTIVE=yes /home/ci/workspace/samba-ci/bin/smbclient
-Uci%localntdc2pass //LOCALNT4DC2/tmp -I 127.0.0.3
--configfile=/home/ci/workspace/samba-ci/st/client/client.conf -mNT1
Try "help" to get a list of possible commands. smb: \> Volume: |tmp|
serial number 0xad80a8b3 smb: \>
failed doing volume command
The test script is source3/script/tests/test_smbclient_s3.sh
echo "$out" | grep '^Volume: |tmp| serial number'
ret=$?
if [ $ret != 0 ] ; then
echo "$out"
echo "failed doing volume command"
return 1
fi
For some reason the input command ("volume\n") is not copied on the
output so the test works if you remove the ^ at the start of the grep
pattern (without the input string the "Volume:.." line ends up in the
middle of the previous line instead of a new line). Until we know we
the input is not copied in the output I can send a patch that removes
that ^ check.
Cheers,
I read this and thought I cannot add to the discussion and closed the
email, but something niggled at me, so I came back to it and read it
again.
I then realised what it was and it was this:

echo "$out" | grep '^Volume: |data| serial number'
ret=$?
if [ $ret != 0 ] ; then
echo "$out"
echo "failed doing volume command"
exit 1
fi

The earlier output is echoed through grep and if the return code
isn't zero, a message is printed, 'failed doing volume command'.

If there is an error here, it possibly isn't coming from smbclient. It
could be wrong data in $out, an 'echo' error or a 'grep'
error.

What I am trying to say is, the test could fail for something that is
nothing to do with 'smbclient'.

Rowland
Aurélien Aptel via samba-technical
2018-03-16 13:54:31 UTC
Permalink
Raw Message
Post by Rowland Penny via samba-technical
The earlier output is echoed through grep and if the return code
isn't zero, a message is printed, 'failed doing volume command'.
If there is an error here, it possibly isn't coming from smbclient. It
could be wrong data in $out, an 'echo' error or a 'grep'
error.
What I am trying to say is, the test could fail for something that is
nothing to do with 'smbclient'.
As I said in my previous email, the script expects the input to be
copied to the output:

The script sends "volume\nquit\n" as input to smbclient and expects this
back:

Try "help" to get a list of possible commands.
smb: \> volume
Volume: |tmp| serial number 0xad80a8b3
smb: \> quit

But the input isnt copied to the output, so it actually gets this back:

Try "help" to get a list of possible commands.
smb: \> Volume: |tmp| serial number 0xad80a8b3
smb: \>

The pattern "^Volume" matches only the first thing, not the second but
the test is just looking for this Volume chain. The failure is
incorrect.

I have no idea why the input isnt copied on the output. I've tried
running this on a different machine and it passes. It could be that the
shell have different behaviours regarding eval/echo/backticks together.
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Ralph Böhme via samba-technical
2018-03-16 12:20:27 UTC
Permalink
Raw Message
Hi Aurélien,
Post by Aurélien Aptel via samba-technical
Post by Rowland Penny via samba-technical
The earlier output is echoed through grep and if the return code
isn't zero, a message is printed, 'failed doing volume command'.
If there is an error here, it possibly isn't coming from smbclient. It
could be wrong data in $out, an 'echo' error or a 'grep'
error.
What I am trying to say is, the test could fail for something that is
nothing to do with 'smbclient'.
As I said in my previous email, the script expects the input to be
The script sends "volume\nquit\n" as input to smbclient and expects this
Try "help" to get a list of possible commands.
smb: \> volume
Volume: |tmp| serial number 0xad80a8b3
smb: \> quit
Try "help" to get a list of possible commands.
smb: \> Volume: |tmp| serial number 0xad80a8b3
smb: \>
The pattern "^Volume" matches only the first thing, not the second but
the test is just looking for this Volume chain. The failure is
incorrect.
I have no idea why the input isnt copied on the output. I've tried
running this on a different machine and it passes. It could be that the
shell have different behaviours regarding eval/echo/backticks together.
while I haven't really read into your description, I just wanted to mention that
maybe this is another dashism? Remember, sn-devel runs dash...

-slow
--
Ralph Boehme, Samba Team https://samba.org/
Samba Developer, SerNet GmbH https://sernet.de/en/samba/
GPG Key Fingerprint: FAE2 C608 8A24 2520 51C5
59E4 AA1E 9B71 2639 9E46
Martin Schwenke via samba-technical
2018-05-04 04:35:03 UTC
Permalink
Raw Message
On Fri, 16 Mar 2018 14:54:31 +0100, Aurélien Aptel via samba-technical
Post by Aurélien Aptel via samba-technical
Post by Rowland Penny via samba-technical
The earlier output is echoed through grep and if the return code
isn't zero, a message is printed, 'failed doing volume command'.
If there is an error here, it possibly isn't coming from smbclient. It
could be wrong data in $out, an 'echo' error or a 'grep'
error.
What I am trying to say is, the test could fail for something that is
nothing to do with 'smbclient'.
As I said in my previous email, the script expects the input to be
The script sends "volume\nquit\n" as input to smbclient and expects this
Try "help" to get a list of possible commands.
smb: \> volume
Volume: |tmp| serial number 0xad80a8b3
smb: \> quit
Try "help" to get a list of possible commands.
smb: \> Volume: |tmp| serial number 0xad80a8b3
smb: \>
The pattern "^Volume" matches only the first thing, not the second but
the test is just looking for this Volume chain. The failure is
incorrect.
I have no idea why the input isnt copied on the output. I've tried
running this on a different machine and it passes. It could be that the
shell have different behaviours regarding eval/echo/backticks together.
I'm quite confident that it isn't the shell that is copying input to
output. I think readline() is doing that. Perhaps different
versions of readline are behaving differently? Or perhaps it depends
whether the test is run interactively via a tty or run from a cron job?

My question would be: Why does the test set CLI_FORCE_INTERACTIVE=yes?
The test doesn't check that the prompt is in the output and the test
does not need readline functionality. So, in some circumstances the
unwanted prompt gets in the way of the test passing.

From my perspective, the best thing would be to drop
CLI_FORCE_INTERACTIVE=yes in test cases that aren't testing whether a
prompt is shown.

peace & happiness,
martin

Loading...