bash/ldap failures

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

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,

[Rowland Penny via samba-technical]

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]

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.

[Ralph Böhme via samba-technical]

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

[Martin Schwenke via samba-technical]

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