Re: PID file /var/run/openldap/slapd.pid not readable (yet?) after start

[Quanah Gibson-Mount]

--On Wednesday, August 14, 2019 4:39 PM + Paul Pathiakis 
 wrote:



I don't even know how to address that.


Sounds like it didn't actually start.  Did you clean up the failed database 
after adjusting the max size?  Did you check to see what (if any) errors 
slapd provided to the syslog file?


I would also note, that if you know the LDIF being imported is "good", it's 
much quicker to use slapadd -q to do an import while slapd is offline than 
to use ldapadd while slapd is running.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: PID file /var/run/openldap/slapd.pid not readable (yet?) after start

[Dieter Klünter]

Am Wed, 14 Aug 2019 15:39:55 + (UTC)
schrieb Paul Pathiakis :

> Hi
> After the previous issue... I went to startup slapd and got the error
> above. I don't even know how to address that.
> Slapd won't even start.  I'm on CentOS 7. :(
> systemctl status slapd.service
> ● slapd.service - OpenLDAP Server Daemon
>    Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled;
> vendor preset: disabled) Active: failed (Result: timeout) since Wed
> 2019-08-14 11:34:15 EDT; 2min 7s ago Docs: man:slapd
>    man:slapd-config
>    man:slapd-hdb
>    man:slapd-mdb
>    file:///usr/share/doc/openldap-servers/guide.html
>   Process: 15117 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS}
> $SLAPD_OPTIONS (code=exited, status=0/SUCCESS) Process: 15102
> ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited,
> status=0/SUCCESS) Main PID: 14277 (code=exited, status=0/SUCCESS)
> 
> Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]:
> Starting OpenLDAP Server Daemon... Aug 14 11:32:45
> NewLDAP.hq.boston-engineering.com runuser[15105]:
> pam_unix(runuser:session): session opened for user ldap by (uid=0)
> Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]:
> pam_unix(runuser:session): session closed for user ldap Aug 14
> 11:32:45 NewLDAP.hq.boston-engineering.com slapd[15117]: @(#)
> $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $
> mockbu...@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openlda...s/slapd
> Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: PID
> file /var/run/openldap/slapd.pid not readable (yet?) after start. Aug
> 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]:
> slapd.service start operation timed out. Terminating. Aug 14 11:34:15
> NewLDAP.hq.boston-engineering.com systemd[1]: Failed to start
> OpenLDAP Server Daemon. Aug 14 11:34:15
> NewLDAP.hq.boston-engineering.com systemd[1]: Unit slapd.service
> entered failed state. Aug 14 11:34:15
> NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service failed.
> Hint: Some lines were ellipsized, use -l to show in full.
> [root@NewLDAP openldap]# systemctl start slapd.service Job for
> slapd.service failed because a timeout was exceeded. See "systemctl
> status slapd.service" and "journalctl -xe" for details.

Run slapd in debug mode in order to identitfy the culprit.

usr/sbin/slapd -h "ldap:///; -u ldap -g ldap -F
/etc/openldap/slapd.d -f /etc/openldap/slapd.conf -d 256

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

PID file /var/run/openldap/slapd.pid not readable (yet?) after start

[Paul Pathiakis]

Hi
After the previous issue... I went to startup slapd and got the error above.
I don't even know how to address that.
Slapd won't even start.  I'm on CentOS 7. :(
systemctl status slapd.service
● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor 
preset: disabled)
   Active: failed (Result: timeout) since Wed 2019-08-14 11:34:15 EDT; 2min 7s 
ago
 Docs: man:slapd
   man:slapd-config
   man:slapd-hdb
   man:slapd-mdb
   file:///usr/share/doc/openldap-servers/guide.html
  Process: 15117 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} 
$SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
  Process: 15102 ExecStartPre=/usr/libexec/openldap/check-config.sh 
(code=exited, status=0/SUCCESS)
 Main PID: 14277 (code=exited, status=0/SUCCESS)

Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: Starting OpenLDAP 
Server Daemon...
Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]: 
pam_unix(runuser:session): session opened for user ldap by (uid=0)
Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com runuser[15105]: 
pam_unix(runuser:session): session closed for user ldap
Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com slapd[15117]: @(#) $OpenLDAP: 
slapd 2.4.44 (Jan 29 2019 17:42:45) $
    
mockbu...@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openlda...s/slapd
Aug 14 11:32:45 NewLDAP.hq.boston-engineering.com systemd[1]: PID file 
/var/run/openldap/slapd.pid not readable (yet?) after start.
Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service 
start operation timed out. Terminating.
Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: Failed to start 
OpenLDAP Server Daemon.
Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: Unit 
slapd.service entered failed state.
Aug 14 11:34:15 NewLDAP.hq.boston-engineering.com systemd[1]: slapd.service 
failed.
Hint: Some lines were ellipsized, use -l to show in full.
[root@NewLDAP openldap]# systemctl start slapd.service
Job for slapd.service failed because a timeout was exceeded. See "systemctl 
status slapd.service" and "journalctl -xe" for details.


Thank you,

P.

Re: Username case

[JC]

 
Thanks everybody for your feedback. If I understand things correctly, there is 
really nothing much that one can do in the OpenLDAP, for the attribute I am 
interested in is defined to have case-insensitive values already. Since the 
string comparison carried out by getpwnam() in Linux is case-sensitive, my only 
way out seems to be to use 'ignorecase yes' in my /etc/nslcd.conf file - not 
really that  desirable, for a number of reasons, but probably OKin my case.


On Tuesday, August 13, 2019, 05:09:54 PM MDT, Quanah Gibson-Mount 
 wrote:  
 
 

--On Tuesday, August 13, 2019 4:25 PM + JC  
wrote:

>
> Now it seems to be the case that, with a user entry in OpenLDAP as
> described above, getpwnam("james") will look for an entry such that the
> its uid attribute takes the value "james". I.e. if the value of uid is,
> say, "James" then it will be ignored. Which, following the discussion
> above, doesn't fit my goal.

The "uid" attribute is explicitly defined to be case insensitive in 
RFC1274, see section 9.3.1 "userid".  This is reflected in the OpenLDAP 
core schema:

#attributetype ( 0.9.2342.19200300.100.1.1
#  NAME ( 'uid' 'userid' )
#  DESC 'RFC1274: user identifier'
#  EQUALITY caseIgnoreMatch
#  SUBSTR caseIgnoreSubstringsMatch
#  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

  

Re: mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)

[Quanah Gibson-Mount]

--On Wednesday, August 14, 2019 3:13 PM + Paul Pathiakis 
 wrote:



Could I have what the issue is?
How do I correct it?
What are the commands I run properly load this (and generate the indexes)?
How do I make sure enough space for the DB and the indexes is allocated?


Set the maximum database size for the back-mdb database, as documented in 
the slapd-mdb(5) man page, to something large.  The idea with the max size 
value is to set it to something very large that you do not ever expect to 
hit.  I usually go with 80 GB.


Regards,
Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Multi-master replication : read_config: no serverID / URL match found. Check slapd -h arguments.

[Quanah Gibson-Mount]

--On Wednesday, August 14, 2019 11:23 AM +0200 HG 
 wrote:




olcServerID: 1 ldap://linux1014.ts.aa-srv.com
olcServerID: 2 ldap://linux1015.ts.aa-srv.com


Neither of those has a trailing slash.  You noted:

SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com/;

doesn't start, but

SLAPD_URLS="ldapi:/// ldap://linux1014.ts.aa-srv.com;

starts.

I would expect this.  As I said before, it's a MATCH between what's 
provided in the olcServerID field and the -h option to slapd (SLAPD_URLS in 
your case).  I.e., the software is functioning as documented.  If you want 
it to match on the trailing slash, adjust your olcServerID values to 
include a trailing slash.


Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Antw: Re: Username case

[Ulrich Windl]

>>> Quanah Gibson-Mount  schrieb am 14.08.2019 um 01:09 in
Nachricht <59A1EC7FB57F5649201E5D92@[192.168.1.144]>:

> 
> ‑‑On Tuesday, August 13, 2019 4:25 PM + JC  
> wrote:
> 
>>
>> Now it seems to be the case that, with a user entry in OpenLDAP as
>> described above, getpwnam("james") will look for an entry such that the
>> its uid attribute takes the value "james". I.e. if the value of uid is,
>> say, "James" then it will be ignored. Which, following the discussion
>> above, doesn't fit my goal.
> 
> The "uid" attribute is explicitly defined to be case insensitive in 
> RFC1274, see section 9.3.1 "userid".  This is reflected in the OpenLDAP 
> core schema:
> 
> #attributetype ( 0.9.2342.19200300.100.1.1
> #   NAME ( 'uid' 'userid' )
> #   DESC 'RFC1274: user identifier'
> #   EQUALITY caseIgnoreMatch
> #   SUBSTR caseIgnoreSubstringsMatch
> #   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

However UNIX is not case-insensitive. We had the case that entering a valid
user's name in capital letters (dammed Shift-lock key) caused an authentication
failure, and nscd in turn cached that (case-insensitively), so after that even
entering the user name in lower case caused a (cached) authentication failure.
(I had tried to convince support that this is a  bug in nscd, but failed to
convince them)

So be warned: UNIX is not case-insensitive!

Regards,
Ulrich

> 
> 
> Regards,
> Quanah
> 
> 
> ‑‑
> 
> Quanah Gibson‑Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 

mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)

[Paul Pathiakis]

Hi,
I'm reloading a DB into OpenLDAP after an upgrade.
It starts off fine with:
 ldapadd -f ./20190812-21.ldif -v -D "cn=root,dc=hq,dc=example,dc=com" -h 
newldap.hq.example.com -W -c
However, during the load, it gets through a few hundred entries and then:

adding new entry 
"cn=ZRO001-INTERNAL,ou=ZRO001,ou=Projects,dc=hq,dc=example,dc=com"ldap_add: 
Other (e.g., implementation specific) error (80)
    additional info: index generation failed


During the load, it seems that the indexes are failing as well.
Could I have what the issue is?How do I correct it?What are the commands I run 
properly load this (and generate the indexes)?How do I make sure enough space 
for the DB and the indexes is allocated?
@(#) $OpenLDAP: slapd 2.4.44 (Jan 29 2019 17:42:45) $
    
mockbu...@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/servers/slapd

Thank you!
P.

Re: Username case

[Michael Ströder]

On 8/14/19 1:09 AM, Quanah Gibson-Mount wrote:
> --On Tuesday, August 13, 2019 4:25 PM + JC
>  wrote:
>> Now it seems to be the case that, with a user entry in OpenLDAP as
>> described above, getpwnam("james") will look for an entry such that the
>> its uid attribute takes the value "james". I.e. if the value of uid is,
>> say, "James" then it will be ignored. Which, following the discussion
>> above, doesn't fit my goal.
> 
> The "uid" attribute is explicitly defined to be case insensitive in
> RFC1274, see section 9.3.1 "userid".  This is reflected in the OpenLDAP
> core schema:

Some more notes to add:

Having EQUALITY caseIgnoreMatch means that "(uid=james)" and
"(uid=James)" will return entries containing all variants of etc. JAMES,
James, jAmEs.

This also means that enabling unique overlay (slapo-unique) will enforce
case-insensitive uniqueness on uid values, so that there are now two
distinct entries matching uid=james and uid=James.

This solves searching for the entry by user name.

The other big problem is that POSIX standard defines all POSIX names
(user names, group names) to be case-sensitive. This matches also the
case-sensitive file name semantics. So one has to look more closely on
how the NSS subsystem used handles this. The default for nss-pam-ldapd
(aka nslcd) treats 'uid' values retrieved from LDAP server as
case-sensitive.

Even if you switch to case-insensitive handling in /etc/nslcd.conf you
might run into issues with applications consuming the data via NSS.

To avoid all this mess in my Æ-DIR I'm always normalizing the 'uid'
values (and 'cn' values in group entries) to lower-case and avoid mixed
cases by proper data maintenance.

Ciao, Michael.