Hello everyone,
I upgraded my debian machine from lenny to squeeze (the new stable) that comes with samba 3.5.6 and openldap 2.4.23. this machines works primarily as a PDC.
i have 3 services authenticating on ldap: samba, apache and redmine. samba is acting very weird, but it's kinda working, but redmine and apache aren't working at all.
these services do bind to the server, but it cannot find the users. also, i cannot execute ldapsearchs via CLI. plus, in the bash, when i try to change to some user other than root (eg: lscarneiro), the system does not recognize the user:
fileserver:~# su - lscarneiro I have no name!@fileserver:~$ whoami whoami: cannot find name for user ID 1130
i'm very VERY noob on ldap and don't know exactly what kind of info i should give to you guys to get some help. any help is very welcome
On Mon, Feb 14, 2011 at 12:37 PM, Leonardo Carneiro chesterman86@gmail.com wrote:
Hello everyone,
I upgraded my debian machine from lenny to squeeze (the new stable) that comes with samba 3.5.6 and openldap 2.4.23. this machines works primarily as a PDC.
i have 3 services authenticating on ldap: samba, apache and redmine. samba is acting very weird, but it's kinda working, but redmine and apache aren't working at all.
these services do bind to the server, but it cannot find the users. also, i cannot execute ldapsearchs via CLI. plus, in the bash, when i try to change to some user other than root (eg: lscarneiro), the system does not recognize the user:
fileserver:~# su - lscarneiro I have no name!@fileserver:~$ whoami whoami: cannot find name for user ID 1130
i'm very VERY noob on ldap and don't know exactly what kind of info i should give to you guys to get some help. any help is very welcome
any news...? please :)
On 14/02/11 12:37 -0200, Leonardo Carneiro wrote:
Hello everyone,
I upgraded my debian machine from lenny to squeeze (the new stable) that comes with samba 3.5.6 and openldap 2.4.23. this machines works primarily as a PDC.
i have 3 services authenticating on ldap: samba, apache and redmine. samba is acting very weird, but it's kinda working, but redmine and apache aren't working at all.
these services do bind to the server, but it cannot find the users. also, i cannot execute ldapsearchs via CLI. plus, in the bash, when i try to change to some user other than root (eg: lscarneiro), the system does not recognize the user:
fileserver:~# su - lscarneiro I have no name!@fileserver:~$ whoami whoami: cannot find name for user ID 1130
i'm very VERY noob on ldap and don't know exactly what kind of info i should give to you guys to get some help. any help is very welcome
Start with your admin (rootdn/rootpw) credentials and see if you can bind to the server. If so, try binding with your Apache/Redmine credentials from the CLI to verify your ACL configuration is good. Try to prove that your Apache configuration is good by reproducing it's bind and search via command line tools.
With regards to Squeeze, see:
http://www.debian.org/releases/stable/i386/release-notes/ch-whats-new.en.htm...
If you're using libnss-ldap (for nss/user id mapping), consider moving to libnss-ldapd.
On Mon, Feb 14, 2011 at 12:37:24PM -0200, Leonardo Carneiro wrote:
I upgraded my debian machine from lenny to squeeze (the new stable) that comes with samba 3.5.6 and openldap 2.4.23. this machines works primarily as a PDC.
these services do bind to the server, but it cannot find the users. also, i cannot execute ldapsearchs via CLI.
It sounds as if there is no data in the LDAP server.
Debian Lenny seems to use OpenLDAP 2.4.11 with db4.2 I suspect that Squeeze uses later versions of both, so it is very unlikely to be able to read the original database files. I do not know what the Lenny->Squeeze update process does with LDAP data - I would hope that it creates an LDIF and re-imports it, but in your case something has obviously gone wrong.
You should look in the logs for complaints at startup time which might give some clues. If you do not find any logs, try adding '-d 768' to the slapd startup command to make it log to stdout.
As your server appears to be running, you could check that it has your suffix configured:
ldapsearch -x -LLL -b '' -s base '(objectclass=*)' namingcontexts
If my guess about DB files is right, you will need to re-load the data from an LDIF backup file. Something like this:
Stop the server Preserve the existing database files somewhere safe Create a new empty database (i.e. an empty DB directory, possibly with a DB_CONFIG file in it) Load the LDIF file using slapadd (do this as the openldap user) Start the server
Andrew
On Tue, Feb 15, 2011 at 10:24 AM, Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
It sounds as if there is no data in the LDAP server.
Debian Lenny seems to use OpenLDAP 2.4.11 with db4.2 I suspect that Squeeze uses later versions of both, so it is very unlikely to be able to read the original database files. I do not know what the Lenny->Squeeze update process does with LDAP data - I would hope that it creates an LDIF and re-imports it, but in your case something has obviously gone wrong.
You should look in the logs for complaints at startup time which might give some clues. If you do not find any logs, try adding '-d 768' to the slapd startup command to make it log to stdout.
As your server appears to be running, you could check that it has your suffix configured:
ldapsearch -x -LLL -b '' -s base '(objectclass=*)' namingcontexts
If my guess about DB files is right, you will need to re-load the data from an LDIF backup file. Something like this:
Stop the server Preserve the existing database files somewhere safe Create a new empty database (i.e. an empty DB directory, possibly with a DB_CONFIG file in it) Load the LDIF file using slapadd (do this as the openldap user) Start the server
Andrew
Hi Andrew.
The ldapsearch you gave me returned the following output: chester@reploid:~$ ldapsearch -h ldap.server -x -LLL -b '' -s base '(objectclass=*)' namingcontexts dn: namingContexts: dc=dominio,dc=com,dc=br
I think It's ok, cause that's precisely the root of my ldap tree.
Just another info: when I was on the root shell and tried to change to another user, i did changed, but i gave some errors:
fileserver:~# su - lscarneiro I have no name!@fileserver:~$ whoami whoami: cannot find name for user ID 1130
but than i read this link that dan gave me: http://www.debian.org/releases/stable/i386/release-notes/ch-whats-new.en.htm... and installed the libnss-ldapd and libpam-ldapd packages as recommended. but now i can't even 'su' to my username:
fileserver:~# su - lscarneiro Unknown id: lscarneiro
It's seems that the unix and samba database have lost their sync. I'll try to execute the backup/restore in a new db dir as you said and post the results here. This backup need to be from a point before the upgrade or a can simple get a dump of the actual database?
Sorry for my poor english.
On Tue, Feb 15, 2011 at 11:13:03AM -0200, Leonardo Carneiro wrote:
The ldapsearch you gave me returned the following output: chester@reploid:~$ ldapsearch -h ldap.server -x -LLL -b '' -s base '(objectclass=*)' namingcontexts dn: namingContexts: dc=dominio,dc=com,dc=br
I think It's ok, cause that's precisely the root of my ldap tree.
That looks good, and it suggests that the slapd config is OK. Now try this:
ldapsearch -h ldap.server -x -b dc=dominio,dc=com,dc=br -s base '(objectclass=*)'
If you get an entry, then try:
ldapsearch -h ldap.server -x -b dc=dominio,dc=com,dc=br '(objectclass=*)'
If you see lots of data then there is probably nothing wrong with the LDAP server at all.
Just another info: when I was on the root shell and tried to change to another user, i did changed, but i gave some errors:
fileserver:~# su - lscarneiro I have no name!@fileserver:~$ whoami whoami: cannot find name for user ID 1130
but than i read this link that dan gave me: http://www.debian.org/releases/stable/i386/release-notes/ch-whats-new.en.htm... and installed the libnss-ldapd and libpam-ldapd packages as recommended. but now i can't even 'su' to my username:
fileserver:~# su - lscarneiro Unknown id: lscarneiro
It's seems that the unix and samba database have lost their sync. I'll
Ignore Samba for now. You need to get the basic Unix-level stuff working first.
try to execute the backup/restore in a new db dir as you said and post the results here. This backup need to be from a point before the upgrade or a can simple get a dump of the actual database?
It would be best to use an LDIF made with slapcat just before the upgrade. If you don't have one then you may need to copy your database files onto a machine running the same versions of software that the server had before the upgrade, and make an LDIF there.
Andrew
On Tue, Feb 15, 2011 at 11:24 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> wrote:
On Tue, Feb 15, 2011 at 11:13:03AM -0200, Leonardo Carneiro wrote:
The ldapsearch you gave me returned the following output: chester@reploid:~$ ldapsearch -h ldap.server -x -LLL -b '' -s base '(objectclass=*)' namingcontexts dn: namingContexts: dc=dominio,dc=com,dc=br
I think It's ok, cause that's precisely the root of my ldap tree.
That looks good, and it suggests that the slapd config is OK. Now try this:
ldapsearch -h ldap.server -x -b dc=dominio,dc=com,dc=br -s base
'(objectclass=*)'
If you get an entry, then try:
ldapsearch -h ldap.server -x -b dc=dominio,dc=com,dc=br '(objectclass=*)'
This search gave me no result:
fileserver:/var/log# ldapsearch -h 127.0.0.1 -x -b dc=dominio,dc=com,dc=br '(objectclass=*)' # extended LDIF # # LDAPv3 # base <dc=dominio,dc=com,dc=br> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
# numResponses: 1
But binding it to a root cn did work:
fileserver:/var/log# ldapsearch -h 127.0.0.1 -x -b dc=dominio,dc=com,dc=br '(objectclass=*)' -D "cn=root,dc=dominio,dc=com,dc=br" -w [passwd] # extended LDIF # # LDAPv3 # base <dc=dominio,dc=com,dc=br> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# dominio.com.br dn: dc=dominio,dc=com,dc=br dc: dominio ...
If you see lots of data then there is probably nothing wrong with the LDAP server at all.
Just another info: when I was on the root shell and tried to change to another user, i did changed, but i gave some errors:
fileserver:~# su - lscarneiro I have no name!@fileserver:~$ whoami whoami: cannot find name for user ID 1130
but than i read this link that dan gave me:
http://www.debian.org/releases/stable/i386/release-notes/ch-whats-new.en.htm...
and installed the libnss-ldapd and libpam-ldapd packages as recommended. but now i can't even 'su' to my username:
fileserver:~# su - lscarneiro Unknown id: lscarneiro
It's seems that the unix and samba database have lost their sync. I'll
Ignore Samba for now. You need to get the basic Unix-level stuff working first.
try to execute the backup/restore in a new db dir as you said and post the results here. This backup need to be from a point before the upgrade or a can simple get a dump of the actual database?
It would be best to use an LDIF made with slapcat just before the upgrade. If you don't have one then you may need to copy your database files onto a machine running the same versions of software that the server had before the upgrade, and make an LDIF there.
Andrew
I have a backup from the very last moment before the upgrade, i'll use it and post the results here.
On Tue, Feb 15, 2011 at 11:37:59AM -0200, Leonardo Carneiro wrote:
fileserver:/var/log# ldapsearch -h 127.0.0.1 -x -b dc=dominio,dc=com,dc=br '(objectclass=*)' # extended LDIF # # LDAPv3 # base <dc=dominio,dc=com,dc=br> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# search result search: 2 result: 32 No such object
But binding it to a root cn did work:
fileserver:/var/log# ldapsearch -h 127.0.0.1 -x -b dc=dominio,dc=com,dc=br '(objectclass=*)' -D "cn=root,dc=dominio,dc=com,dc=br" -w [passwd]
I am a bit worried about the order of parameters there. The filter '(objectclass=*)' should be at the end.
# extended LDIF # # LDAPv3 # base <dc=dominio,dc=com,dc=br> with scope subtree # filter: (objectclass=*) # requesting: ALL #
# dominio.com.br dn: dc=dominio,dc=com,dc=br dc: dominio ...
Aha! How many entries did that search return? Was is about the same number that you would expect given your users and groups?
If you see lots of data then there is probably nothing wrong with the LDAP server at all.
Maybe it is just access-control that is not doing what you expect.
I have a backup from the very last moment before the upgrade, i'll use it and post the results here.
Wait a bit. The data may well be OK.
If the root-dn search returned the right number of entries then your problem is access-control, not database.
Did you previously have the LDAP server set up to refuse data to anonymous users?
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Dan White -
Leonardo Carneiro