Re: 'unary operator expected' error when TLS turned on - SOLVED

[Buchan Milne <bgmilne@staff.telkomsa.net>]

I note it may not be easy with the software you are using, but this thread 
would probably be easier to read for everyone if you refrained from top-
posting.


On Tuesday 02 June 2009 07:02:04 John Kane wrote:
> This is worse than I thought.

Quoting myself:

> > fix your configuration issue which
> > prevents
> > users from looking up their own user details (such as numerical uid),
> > which is
> > sure to break some applications.

> No commands executed from the bash start
> scripts are returning a value.  And, even simple command line commands,
> when a sub-shell is required, return nothing.  For instance, when TLS is
> turned on, these commands return results:
>
> 	cat /etc/hosts
> 	grep local /etc/hosts
> 	/usr/bin/id -u
> 	echo xxx
>
> But the following return nothing:
>
> 	cat /etc/hosts | grep local
> 	echo `/usr/bin/id -u`
>
>
> In fact, I don't even see the second set of commands hit LDAP (running
> slapd in debug mode).

They won't, since nss_ldap will refuse to connect to the server if it can't 
decide if the server has a valid certificate or not.

>
>
> 	$ grep local /etc/hosts
> 	127.0.0.1       localhost.localdomain   localhost
>
> 	::1     localhost6.localdomain6 localhost6
>
> 	$ /usr/bin/id -u
> 	1805
> 	$ echo xxx
> 	xxx
> 	$
> 	$ cat /etc/hosts | grep local
> 	$
> 	$ echo xxx = `/usr/bin/id -u`
> 	xxx =
> 	$
>
>
> BUT, when I turn off TLS (set 'ssl off' in /etc/ldap.conf)
>
> 	$ cat /etc/hosts | grep local
> 	127.0.0.1       localhost.localdomain   localhost
>
> 	::1     localhost6.localdomain6 localhost6
>
> 	$ echo xxx = `/usr/bin/id -u`
> 	xxx = 1805
> 	$
>
> Any ideas why the sub-shell would not go to LDAP?

Yes. Those were stated in my previous reply. Most likely, your CA certificate 
is not readable by the user in question, which means it can't do certificate 
validation, which means it will refuse to connect to the LDAP server, which 
means any user information lookups performed as the user will fail, which will 
cause many applications to not work.

Please, consider investigating as I recommended in my previous mail.

E.g., as the user in question, how about:


cat /etc/openldap/cacerts/cacert.pem

If that doesn't return the certificate, you need to correct the permissions so 
it does, or instead use a configuration where the user doesn't load nss_ldap 
... such as using nscd.

>
>
> Thanks,
> John
>
> > -----Original Message-----
> > From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
> > Sent: Monday, June 01, 2009 8:21 AM
> > To: openldap-technical@openldap.org
> > Cc: John Kane
> > Subject: Re: 'unary operator expected' error when TLS turned on -
> > SOLVED
> >
> > On Sunday 31 May 2009 16:24:49 John Kane wrote:
> > > Adding the 'set -x' option top of /etc/profile, I was able to
> >
> > determine
> >
> > > the culprit of the
> > >
> > > "-bash: [: =: unary operator expected"
> > >
> > > error that has been occurring on all Linux servers since turning on
> >
> > LDAP
> >
> > > TLS on INT.
> > >
> > > In the file:
> > >
> > > /etc/profile.d/krb5-workstation.sh
> > >
> > > The follow is causing the issue:
> > >
> > > if ! echo ${PATH} | /bin/grep -q /usr/kerberos/sbin ; then
> > >         if [ `/usr/bin/id -u` = 0 ] ; then
> > >                 PATH=/usr/kerberos/sbin:${PATH}
> > >         fi
> > > fi
> > >
> > >
> > > If I add " " around the backticked command, I the bash error goes
> >
> > away.
> >
> > > Not sure who I need to open a ticket against :-)
> >
> > Depends if you want the bug to be fixed (which, while satisfying, will
> > still
> > leave you with real problems), or fix your configuration issue which
> > prevents
> > users from looking up their own user details (such as numerical uid),
> > which is
> > sure to break some applications.
> >
> > You should probably investigate why the output 'id -u' is empty, most
> > likely
> > it is permissions on the certificate.
> >
> > 'ls -l /etc/openldap/cacerts/cacert.pem'
> >
> > If that's not it, you need to look further.
> >
> >  You can probably track it down with 'strace -e open id -u', or
> > similar.