[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

This is worse than I thought.  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).

	$ grep local /etc/hosts       localhost.localdomain   localhost
	::1     localhost6.localdomain6 localhost6
	$ /usr/bin/id -u
	$ echo 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       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?




> -----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 -
> 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
> > 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.
> Regards,
> Buchan

This message is confidential to Prodea Systems, Inc unless otherwise indicated 
or apparent from its nature. This message is directed to the intended recipient 
only, who may be readily determined by the sender of this message and its 
contents. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient:(a)any dissemination or copying of this message is strictly 
prohibited; and(b)immediately notify the sender by return message and destroy 
any copies of this message in any form(electronic, paper or otherwise) that you 
have.The delivery of this message and its information is neither intended to be 
nor constitutes a disclosure or waiver of any trade secrets, intellectual 
property, attorney work product, or attorney-client communications. The 
authority of the individual sending this message to legally bind Prodea Systems  
is neither apparent nor implied,and must be independently verified.