2:11 p.m.
I've also posted this message on the OpenSSL forum:
I just turned on TLS on my LDAP (per instructions on
http://www.openldap.org/faq/data/cache/185.html). Now all of my Linux
servers (RH EL5) give the following error on login:
-bash: [: =: unary operator expected
The error goes away when I turn TLS off. I cannot determine what is
causing this error, or even which file contains the error. I've gone
through my LDAP config files, cannot find an issue in any of these.
Other than my cacert.pem, and the LDAP config files, are there other
files that are read only when TLS is turned on?
Thanks,
John
I am running Openldap 2.3.43-2.el5 & OpenSSL 0.9.8b-10.el5 (RPMs from
Red Hat, which I am required to use unless I put up a BIG fight).
++++ Here's my configs ++++
I turn on TLS by adding the following in my /etc/ldap.conf (pam/nss
file):
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_cacertdir /etc/openldap/cacerts/
and have the following in my /etc/openldap/ldap.conf (openldap file):
HOST 172.25.3.97
BASE dc=example,dc=net
TLS_CACERTDIR /etc/openldap/cacerts/
TLS_REQCERT allow
and my (self-signed) cacert:
[root@serverx cacerts]# openssl x509 -text -in
/etc/openldap/cacerts/cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Utah, O=Bigtime CA, OU=Signers, CN=Integration
Root CA/emailAddress=john.smith(a)myco.com
Validity
Not Before: May 28 04:37:13 2009 GMT
Not After : May 27 04:37:13 2012 GMT
Subject: C=US, ST=Utah, O=Bigtime CA, OU=Signers, CN=Integration
Root CA/emailAddress=john.smith(a)myco.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b3:bf:f0:18:5d:7e:57:0a:ce:15:3c:28:2a:81:
6d:e6:c5:31:98:7e:cc:09:03:d2:28:f2:33:3e:88:
11:5f:7d:e1:18:33:38:7d:f5:fa:9d:89:a8:95:16:
08:00:81:08:29:ac:37:b3:b1:2b:f3:20:52:15:d7:
19:44:92:9c:45:e7:2e:58:fe:7e:07:d4:1f:5a:ad:
59:91:37:84:14:a8:4e:df:54:a2:62:66:38:9b:f0:
cf:48:01:68:0d:3a:7c:93:83:02:48:e0:76:a1:5c:
f9:05:3b:49:1e:03:9a:fd:ea:ee:79:f7:87:66:96:
b0:69:39:e1:e6:1a:bd:9e:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
0B:FB:7D:0B:0D:17:A3:CD:79:02:A3:A3:92:57:15:6F:DE:38:07:3C
X509v3 Authority Key Identifier:
keyid:0B:FB:7D:0B:0D:17:A3:CD:79:02:A3:A3:92:57:15:6F:DE:38:07:3C
Signature Algorithm: sha1WithRSAEncryption
28:52:3d:9c:90:d1:89:00:d7:9d:3b:06:a6:32:28:e8:c0:8d:
9d:5a:0b:79:bb:1a:c9:1a:8d:c6:3a:a5:ec:5d:4c:9f:20:4c:
c6:1e:41:df:7d:d5:fc:45:09:2b:4b:7c:ff:38:aa:ea:33:a0:
4a:be:7c:84:7c:58:e8:98:9b:c9:0e:4b:5b:11:c6:28:84:b1:
3f:bb:30:03:f6:38:40:9f:2d:32:bc:3a:97:b8:6f:fd:aa:9f:
67:a6:27:07:53:b2:40:41:86:b7:02:f2:6b:07:6f:1b:74:87:
63:3b:1b:89:13:08:cb:32:f0:3c:3b:5e:d6:df:e3:91:19:86:
7a:d4
-----BEGIN CERTIFICATE-----
MIIDDzCCAnigAwIBAgIBADANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UERhMCVVMx
DjAMBgNVBAgTBVRleGFzMRMwEQYDVQQKEwpCaWd0aW1lIENBMRAwDgYDVQQLEwdT
aWduZXJzMRwwGgYDVQQDExNJbnRlZ3JhdGlvbiBSb290IENBMSowKAYJKoZIhvcN
AQkBFhtqb2huLmthbmVAcHJvZGVhc3lzdGV3cy5jb20wHhcNMDkwNTI4MDQzNzEz
WhcNMTIwNTI3MDQzNzEzWjCBjjELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVRleGFz
MRMwEQYDVQQKEwpCaWd0aW1lIENBMRAwDgYDVQQLEwdTaWduZXJzMRwwGgYDVQQD
ExNJbnRlZ3JhdGlvbiBSb290IENBMSowKAYJKoZIhvcNAQkBFhtqb2huLmthbmVA
cHJvZGVhc3lzdGVtcy5jb20wgZ8wDQYJKoZIhvcNAQE1BQADgY0AMIGJAoGBALO/
8BhdflcKzhU8KCqBbebFMZh+xAkD0ijyMz6IEV994RgzNX31+p2JqJUWCACBCCms
N7OxK/MgUhXXGUSSnEXnLlj+fgfUH1qtWZE3hBSoTd9UomJmOJvwz0gBaA06fJOD
AkjgdqFc+QU7SR4Dmv3q7nn3h2aWsGl54eYavZ4NAgMBAAGjezB5MAkGA1UdEwQC
MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl
MB0GA1UdDgQWBBQL+30LDRejzXkCo6OSVxVv3jgHPfAfBgNVHSMEGDAWgBQL+30L
DRejzXkCo6OSVxVv3jgHPDANBgkqhkiG9w0BAQUFAAOBgQAoUj2ckOGJANedOwam
MijowI2dWgt5uxrJGo3GOqXsXUyfIEzGHkHffdD8RQkrS3z/OKrqM6BKvnyEfFjo
mJ7JDktbEcYohLE/uzAD9jhAny0yvDqXuG/9qp9npicHU7JAQYa3AvJrB28bdIdo
OxuJEwjLNvA8O17W3+ORGYZ61A==
-----END CERTIFICATE-----
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.
7:24 a.m.
New subject: 'unary operator expected' error when TLS turned on - SOLVED
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 :-)
Thanks,
John
-----Original Message-----
From: openldap-technical-
bounces+john.kane=prodeasystems.com(a)OpenLDAP.org [mailto:openldap-
technical-bounces+john.kane=prodeasystems.com(a)OpenLDAP.org] On Behalf
Of John Kane
Sent: Friday, May 29, 2009 4:12 PM
To: openldap-technical(a)openldap.org
Subject: 'unary operator expected' error when TLS turned on
I've also posted this message on the OpenSSL forum:
I just turned on TLS on my LDAP (per instructions on
http://www.openldap.org/faq/data/cache/185.html). Now all of my Linux
servers (RH EL5) give the following error on login:
-bash: [: =: unary operator expected
The error goes away when I turn TLS off. I cannot determine what is
causing this error, or even which file contains the error. I've gone
through my LDAP config files, cannot find an issue in any of these.
Other than my cacert.pem, and the LDAP config files, are there other
files that are read only when TLS is turned on?
Thanks,
John
I am running Openldap 2.3.43-2.el5 & OpenSSL 0.9.8b-10.el5 (RPMs from
Red Hat, which I am required to use unless I put up a BIG fight).
++++ Here's my configs ++++
I turn on TLS by adding the following in my /etc/ldap.conf (pam/nss
file):
ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/openldap/cacerts/cacert.pem
tls_cacertdir /etc/openldap/cacerts/
and have the following in my /etc/openldap/ldap.conf (openldap file):
HOST 172.25.3.97
BASE dc=example,dc=net
TLS_CACERTDIR /etc/openldap/cacerts/
TLS_REQCERT allow
and my (self-signed) cacert:
[root@serverx cacerts]# openssl x509 -text -in
/etc/openldap/cacerts/cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Utah, O=Bigtime CA, OU=Signers,
CN=Integration
Root CA/emailAddress=john.smith(a)myco.com
Validity
Not Before: May 28 04:37:13 2009 GMT
Not After : May 27 04:37:13 2012 GMT
Subject: C=US, ST=Utah, O=Bigtime CA, OU=Signers,
CN=Integration
Root CA/emailAddress=john.smith(a)myco.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b3:bf:f0:18:5d:7e:57:0a:ce:15:3c:28:2a:81:
6d:e6:c5:31:98:7e:cc:09:03:d2:28:f2:33:3e:88:
11:5f:7d:e1:18:33:38:7d:f5:fa:9d:89:a8:95:16:
08:00:81:08:29:ac:37:b3:b1:2b:f3:20:52:15:d7:
19:44:92:9c:45:e7:2e:58:fe:7e:07:d4:1f:5a:ad:
59:91:37:84:14:a8:4e:df:54:a2:62:66:38:9b:f0:
cf:48:01:68:0d:3a:7c:93:83:02:48:e0:76:a1:5c:
f9:05:3b:49:1e:03:9a:fd:ea:ee:79:f7:87:66:96:
b0:69:39:e1:e6:1a:bd:9e:0d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
0B:FB:7D:0B:0D:17:A3:CD:79:02:A3:A3:92:57:15:6F:DE:38:07:3C
X509v3 Authority Key Identifier:
keyid:0B:FB:7D:0B:0D:17:A3:CD:79:02:A3:A3:92:57:15:6F:DE:38:07:3C
Signature Algorithm: sha1WithRSAEncryption
28:52:3d:9c:90:d1:89:00:d7:9d:3b:06:a6:32:28:e8:c0:8d:
9d:5a:0b:79:bb:1a:c9:1a:8d:c6:3a:a5:ec:5d:4c:9f:20:4c:
c6:1e:41:df:7d:d5:fc:45:09:2b:4b:7c:ff:38:aa:ea:33:a0:
4a:be:7c:84:7c:58:e8:98:9b:c9:0e:4b:5b:11:c6:28:84:b1:
3f:bb:30:03:f6:38:40:9f:2d:32:bc:3a:97:b8:6f:fd:aa:9f:
67:a6:27:07:53:b2:40:41:86:b7:02:f2:6b:07:6f:1b:74:87:
63:3b:1b:89:13:08:cb:32:f0:3c:3b:5e:d6:df:e3:91:19:86:
7a:d4
-----BEGIN CERTIFICATE-----
MIIDDzCCAnigAwIBAgIBADANBgkqhkiG9w0BAQUFADCBjjELMAkGA1UERhMCVVMx
DjAMBgNVBAgTBVRleGFzMRMwEQYDVQQKEwpCaWd0aW1lIENBMRAwDgYDVQQLEwdT
aWduZXJzMRwwGgYDVQQDExNJbnRlZ3JhdGlvbiBSb290IENBMSowKAYJKoZIhvcN
AQkBFhtqb2huLmthbmVAcHJvZGVhc3lzdGV3cy5jb20wHhcNMDkwNTI4MDQzNzEz
WhcNMTIwNTI3MDQzNzEzWjCBjjELMAkGA1UEBhMCVVMxDjAMBgNVBAgTBVRleGFz
MRMwEQYDVQQKEwpCaWd0aW1lIENBMRAwDgYDVQQLEwdTaWduZXJzMRwwGgYDVQQD
ExNJbnRlZ3JhdGlvbiBSb290IENBMSowKAYJKoZIhvcNAQkBFhtqb2huLmthbmVA
cHJvZGVhc3lzdGVtcy5jb20wgZ8wDQYJKoZIhvcNAQE1BQADgY0AMIGJAoGBALO/
8BhdflcKzhU8KCqBbebFMZh+xAkD0ijyMz6IEV994RgzNX31+p2JqJUWCACBCCms
N7OxK/MgUhXXGUSSnEXnLlj+fgfUH1qtWZE3hBSoTd9UomJmOJvwz0gBaA06fJOD
AkjgdqFc+QU7SR4Dmv3q7nn3h2aWsGl54eYavZ4NAgMBAAGjezB5MAkGA1UdEwQC
MAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRl
MB0GA1UdDgQWBBQL+30LDRejzXkCo6OSVxVv3jgHPfAfBgNVHSMEGDAWgBQL+30L
DRejzXkCo6OSVxVv3jgHPDANBgkqhkiG9w0BAQUFAAOBgQAoUj2ckOGJANedOwam
MijowI2dWgt5uxrJGo3GOqXsXUyfIEzGHkHffdD8RQkrS3z/OKrqM6BKvnyEfFjo
mJ7JDktbEcYohLE/uzAD9jhAny0yvDqXuG/9qp9npicHU7JAQYa3AvJrB28bdIdo
OxuJEwjLNvA8O17W3+ORGYZ61A==
-----END CERTIFICATE-----
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.
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.
6:21 a.m.
New subject: '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.
Regards,
Buchan
10:02 p.m.
New subject: '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
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?
Thanks,
John
-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
Sent: Monday, June 01, 2009 8:21 AM
To: openldap-technical(a)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.
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.
12:12 a.m.
New subject: 'unary operator expected' error when TLS turned on - SOLVED
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(a)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.
7:08 a.m.
New subject: 'unary operator expected' error when TLS turned on - SOLVED
-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
Sent: Tuesday, June 02, 2009 2:13 AM
To: John Kane
Cc: openldap-technical(a)openldap.org
Subject: Re: 'unary operator expected' error when TLS turned on -
SOLVED
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.
[JK]
Thanks for you rely. All of my comments are 'in-line'.
Personally, I prefer any response to my mails be posted at the top where
I can read it initially, especially when threads get extremely long. To
each his own, I guess. :-)
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.
[JK]
If my user cannot see his own numerical ID, why does this work (issued
from the user in question):
$ /usr/bin/id -u
1805
and why would this only be an issue when TLS is on, and not when TLS is
off?
> 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.
[JK]
I am confused...why is the user allowed to authenticate and login, issue
commands (that return results), but just not commands that require a
secondary sub-shell?
>
>
> $ 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.
[JK]
Sorry, but permissions was one of the first things I investigated. The
following is done logged in as 'the user in question':
$ ll /etc/openldap/cacerts/cacert.pem
-rw-rw-r-- 1 root root 3305 May 28 04:45
/etc/openldap/cacerts/cacert.pem
$ cat /etc/openldap/cacerts/cacert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
etc., etc.
Also, once again, commands that do not invoke a secondary sub-shell
work, I see them hit LDAP.
I am confused with your statement about not loading nss_ldap. Are there
known problems with this?
>
>
> Thanks,
> John
>
> > -----Original Message-----
> > From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
> > Sent: Monday, June 01, 2009 8:21 AM
> > To: openldap-technical(a)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.
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.
5234
days inactive
5238
days old
openldap-technical@openldap.org
5 comments
2 participants
participants (2)
-
Buchan Milne -
John Kane