Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
Il 15/11/23 19:58, Ben Poliakoff ha scritto: With flat file configuration, it was straightforward to include text comments (e.g. "# blah blah"), but as far as I know there isn't any sort of analog for comments, when using slapd.d. Looking for any tips about how best to annotate slapd configuration, in a slapd.d/olc world. Does anyone have a practice that they find works well for them? Do people just maintain separate documents/wiki pages/etc that describe their servers' configs? That's the main reason because I don't use slapd.d, and I revert to slapd.conf after installation, if it's used by default. I don't need the slapd.d features, using slapd.conf configuration is more readable, and I can revert any modification with a stop and a file replacement, automation and deploy is simpler. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597
Re: Connections blocked for some tens of seconds while a single slapd thread running 100%
Il 05/11/20 16:26, Howard Chu ha scritto: > Traces from a stripped binary are useless. > Using a non stripped binary in production lead to some performance problem, so it took a while to plan a deploy for enough time to take data. I'm attaching two gstack traces taken during two different events. What I see is a thread (the second one, here the slapd pid was 31267) in epoll_wait, all the other waiting in a futex excepted one, 31280. But I non skilled enough to understand what it is doing. We also had a much longer event later than the ones from which the attached traces are taken (lasted some minutes). During this one all the thread were straced and we don't have a gstack trace. This time we also got some different errors in the log, and I'm attacching a redacted excerpt hoping that they may constitute a useful clue. What we found were messages like: Nov 10 00:49:56 ldp-11 slapd[31267]: nonpresent_callback: rid=012 present UUID 258f12bd-b531-426e-8dc8-49263545db58, dn cn=905719,cn=protected,o=ourorg They starte appear around five seconds before most of the slapd thread stopped waiting on a futex (that happened near 00:50:03). After that there were still lot of messages on the logs (but only "nonpresent_callback" ones) up to around 00:50:57; then nothing more until the activities resumed (around 00:53:06). >From the strace we saw that the second thread (MAIN_PID+1, here 31268) was ever processing epoll_wait, with some activity in the beginning, then just awakening every 2500ms doing nothing, another thread was sending (with sendto) a lot of messages to fd 3 (from their beginning they seems syslog messages) for about 50 seconds (and the log is full of "nonpresent_callback" in this time) then it also stopped in the same futex of the other threads. The only thread (except for the epoll waiter) that never stopped, was doing just the following system calls: 00:50:05.384738 mprotect(0x7f23bb1bc000, 9613312, PROT_READ|PROT_WRITE) = 0 00:53:05.415500 msync(0x7f23e6e56000, 25769803776, MS_SYNC) = 0 00:53:06.114513 futex(0x7f29eae6e040, FUTEX_WAKE, 1) = 1 the FUTEX_WAKE was on the futex stopping all the other ones, and after that one they restarted working. I hope this could be enough to pin down the problem. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597 Thread 18 (Thread 0x7f23e6e55700 (LWP 31268)): #0 0x7f29e96baed3 in epoll_wait () from /lib64/libc.so.6 #1 0x0042944e in slapd_daemon_task (ptr=0x151fbb0) at daemon.c:2596 #2 0x7f29e9991e75 in start_thread () from /lib64/libpthread.so.0 #3 0x7f29e96ba8fd in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7f23e6654700 (LWP 31269)): #0 0x7f29e998fa5b in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x004f4584 in mdb_txn_renew0 (txn=0x151cd40) at ./../../../libraries/liblmdb/mdb.c:2752 #2 0x004f4c7b in mdb_txn_begin (env=0x141a060, parent=0x0, flags=524288, ret=0x7f23e66522e0) at ./../../../libraries/liblmdb/mdb.c:2910 #3 0x0055d715 in mdb_opinfo_get (op=0x7f23dc17ca70, mdb=0x7f29ead2d010, rdonly=0, moip=0x7f23e66522c8) at id2entry.c:470 #4 0x00506e05 in mdb_modify (op=0x7f23dc17ca70, rs=0x7f23e66539e0) at modify.c:511 #5 0x004bfaf8 in overlay_op_walk (op=0x7f23dc17ca70, rs=0x7f23e66539e0, which=op_modify, oi=0x136a4f0, on=0x0) at backover.c:677 #6 0x004bfd1c in over_op_func (op=0x7f23dc17ca70, rs=0x7f23e66539e0, which=op_modify) at backover.c:730 #7 0x004bfe50 in over_op_modify (op=0x7f23dc17ca70, rs=0x7f23e66539e0) at backover.c:769 #8 0x0044d666 in fe_op_modify (op=0x7f23dc17ca70, rs=0x7f23e66539e0) at modify.c:303 #9 0x0044cf48 in do_modify (op=0x7f23dc17ca70, rs=0x7f23e66539e0) at modify.c:177 #10 0x0042d756 in connection_operation (ctx=0x7f23e6653b10, arg_v=0x7f23dc17ca70) at connection.c:1175 #11 0x0042dceb in connection_read_thread (ctx=0x7f23e6653b10, argv=0x4a1) at connection.c:1311 #12 0x0058a4a2 in ldap_int_thread_pool_wrapper (xpool=0x12fb090) at tpool.c:696 #13 0x7f29e9991e75 in start_thread () from /lib64/libpthread.so.0 #14 0x7f29e96ba8fd in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7f23e5e53700 (LWP 31272)): #0 0x7f29e998fa5b in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x004f4584 in mdb_txn_renew0 (txn=0x151cd40) at ./../../../libraries/liblmdb/mdb.c:2752 #2 0x004f4c7b in mdb_txn_begin (env=0x141a060, parent=0x0, flags=524288, ret=0x7f23e5e512e0) at ./../../../libraries/liblmdb/mdb.c:2910 #3 0x0055d715 in mdb_opinfo_get (op=0x7f23dc022b50, mdb=0x7f29ead2d010, rdonly=0, moip=0x7f23e5e512c8) at id2entry.c:470 #4 0x00506e05 in mdb_modify (op=0x7f
Re: Connections blocked for some tens of seconds while a single slapd thread running 100%
Il 03/11/20 22:49, Quanah Gibson-Mount ha scritto: >> The problem manifests itself without periodicity and looking on the >> number of connection before it we could not see any usage peak. We tried >> to strace slapd threads during the problem, and they seem blocked on a >> mutex waiting for the one running at 100% (in a single CPU, user time). >> I'm attaching a top results during one of these events. > > If you can attach to the process while this is occurring, I'd suggest > obtaining a full GDB backtrace to see what the different slapd threads > are doing at that time. Also, what mutex specifically is slapd waiting on? > I executed gstack on the slapd pid during one of such events saving the output, they are attached, but the running slapd is stripped so they are quite obscure (at least for me). We are trying to put in a non stripped version (compiled with CFLAGS='-g" and --enable-debug=yes) in use for a test, but that's a production machine, and it will take a while. What I should do to find which one the mutex is? in the straces they are identified just by a number. >> So a first question is: there is any other configuration parameter about >> indexing that I can try? > > If you really believe that this is indexing related, you should be able > to tell this from the slapd logs at "stats" logging, where you would see > a specific search taking a significant amount of time. However that > generally does not lead to a system that's paused as searches shouldn't > trigger a mutex issue like what you're describing. > No, it is not that I believe that, as I said it was just a guess about something that could need full CPU for tens of seconds blocking all other operations. But from what you are saying the guess is probably plain wrong. > Is this on RHEL7 or later? If you have both "stats" and "sync" logging > enabled (the recommended setting for replicating nodes), what does the > slapd log show is happening at this time? The server is running an updated version of Amazon Linux (Amazon Linux AMI 2018.03). We enabled stats and sync to logs, and I'm attaching a redacted excerpt of them around the incident time, when I also took the gstack.txt (done at 00:39:04) and gstack2.txt (done at 00:39:20) backtraces. But during that time there is no data. Simone Thread 18 (Thread 0x7f1718b84700 (LWP 23491)): #0 0x7f1d1b3e9ed3 in epoll_wait () from /lib64/libc.so.6 #1 0x00420cc4 in ?? () #2 0x7f1d1b6c0e75 in start_thread () from /lib64/libpthread.so.0 #3 0x7f1d1b3e98fd in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7f1713fff700 (LWP 23492)): #0 0x7f1d1b6bea5b in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x004c2652 in ?? () #2 0x004c3524 in ?? () #3 0x0051b3ff in ?? () #4 0x004d1b1e in ?? () #5 0x0049a592 in ?? () #6 0x0049a6ce in ?? () #7 0x00440ea7 in ?? () #8 0x00442e7b in ?? () #9 0x00425e54 in ?? () #10 0x0042612a in ?? () #11 0x00541a40 in ?? () #12 0x7f1d1b6c0e75 in start_thread () from /lib64/libpthread.so.0 #13 0x7f1d1b3e98fd in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7f17137fe700 (LWP 23494)): #0 0x004c3b93 in ?? () #1 0x004c718f in ?? () #2 0x004cc8ae in ?? () #3 0x004cfab6 in ?? () #4 0x0051a462 in ?? () #5 0x004d22c7 in ?? () #6 0x0049a592 in ?? () #7 0x0049a6ce in ?? () #8 0x00440ea7 in ?? () #9 0x00442e7b in ?? () #10 0x00425e54 in ?? () #11 0x0042612a in ?? () #12 0x00541a40 in ?? () #13 0x7f1d1b6c0e75 in start_thread () from /lib64/libpthread.so.0 #14 0x7f1d1b3e98fd in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x7f1712ffd700 (LWP 23495)): #0 0x7f1d1b6bea5b in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x004c2652 in ?? () #2 0x004c3524 in ?? () #3 0x0051b3ff in ?? () #4 0x004d1b1e in ?? () #5 0x0049a592 in ?? () #6 0x0049a6ce in ?? () #7 0x00440ea7 in ?? () #8 0x00442e7b in ?? () #9 0x00425e54 in ?? () #10 0x0042612a in ?? () #11 0x00541a40 in ?? () #12 0x7f1d1b6c0e75 in start_thread () from /lib64/libpthread.so.0 #13 0x7f1d1b3e98fd in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x7f17127fc700 (LWP 23496)): #0 0x7f1d1b6bea5b in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x004c2652 in ?? () #2 0x004c3524 in ?? () #3 0x0051b3ff in ?? () #4 0x004d1b1e in ?? () #5 0x0049a592 in ?? () #6 0x0049a6ce in ?? () #7 0x00440ea7 in ?? () #8 0x00442e7b in ?? () #9 0x00425e54 in ?? () #10 0x0042612a in ?? () #11 0x00541a40 in ?? () #12 0x7f1d1b6c0e75 in start_thread () from /lib64/libpthread.so.0 #13 0x7f1d1b3e98fd in clone () from /lib64/libc.so.6 Thread
Connections blocked for some tens of seconds while a single slapd thread running 100%
Hi, we got a quite strange behaviour in which a slapd server stops processing connections for some tens of seconds while a single thread is running 100% on a single CPU and all other CPU are almost idle. When the problem arise there is no significant iowait or disk I/O (and no swapping, that's disabled). Context switches just go near zero (from some tens of thousand to some hundreds). Load average is almost always under 2. The server has 32G of RAM and 4 HT processors, is running openldap-2.4.54 in mirror mode (but no delta replication) using the mdb backend. The same behaviour was found also with 2.4.53. OpenLDAP is the only service running on it, apart SSH and some monitoring tools. Database maxsize is 25G around 17G are used. I'm attaching a redacted configuration of the main server (the secondary one is the same, with IDs reverted for mirror mode use) Most of the time it works just fine, processing a up to a few thousand of read query per second while having some tens of write per second. Connections are managed by HA-proxy, sending them to this server by default (used as main node). Many times these stop are short (around 10 second) and we don't lost connections, but when the problem arise and last for enough time, HAproxy switch to the second node, and we got downtimes. Staying with the secondary node we have the same behaviour. The problem manifests itself without periodicity and looking on the number of connection before it we could not see any usage peak. We tried to strace slapd threads during the problem, and they seem blocked on a mutex waiting for the one running at 100% (in a single CPU, user time). I'm attaching a top results during one of these events. >From the behaviour I was suspecting (just a wild and uninformated guess) some indexing issue, blocking all access. We tried to change tool-threads to 4 because I found it cited in some example as related to threads used for indexing, but the change has no effect. Re-reading last version of man-page, if I understand it correctly, it's effective only for slapadd etc. So a first question is: there is any other configuration parameter about indexing that I can try? Anyway I'm not sure if there is an effective indexing issue (indexes are quite basic). I was suspecting this because there are lot of writes, and there is no strace activity during the stop. I should look somewhere else? Any suggestion on further checks or configuration changes will be more than appreciated. Regards Simone # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/openldap/etc/openldap/schema/corba.schema include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/duaconf.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/java.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/openldap.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/collective.schema #add OurOrganization schema include /usr/local/openldap/etc/openldap/schema/OurOrganization.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # This is for mirrormode replication serverID 11 # Global ACLs include /usr/local/openldap/etc/openldap/acls/global.acl # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args # options: none sync parse shell stats2 stats ACL config filter BER conns args packets trace any # https://www.openldap.org/doc/admin24/slapdconfig.html #loglevel none #loglevel stats sync loglevel stats #loglevel none #loglevel any # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /usr/local/openldap/etc/openldap/certs TLSCACertificateFile /usr/local/openldap/etc/openldap/certs/rootCA.pem TLSCertificateFile /usr/local/openldap/etc/openldap/certs/server.crt TLSCertificateKeyFile /usr/local/openldap/etc/openldap/certs/server.key #TLSCertificateFile /etc/pki/tls/certs/ldap1_pubkey.pem #TLSCertificateKeyFile /etc/pki/tls/certs/ldap1_privkey.pem sizelimit 25 # Setup the idle timeout to prevent app servers from taking down ldap. #
Re: Openldap support SHA-256 or SHA-3.
Il 08/01/20 03:05, Quanah Gibson-Mount ha scritto:
>
> In any case, I've been advocating for several years now to get rid of
> SSHA as the default hashing mechanism and replace it with something that
> may actually have some security value.
But in the current version it better to use the contrib module, or
delegate the hashing to the C library? I'm currently using on new install:
password-hash {CRYPT}
password-crypt-salt-format "$6$%.16s"
but I'm using only Linux, I don't know if this is applicable on other OS.
Simone
Re: Forbidden account password reuse of the last 5 password
Il 16/02/19 15:27, Howard Chu ha scritto: The module was written for Heimdal. Feel free to submit a patch to make it compatible with MIT Kerberos. Sorry I dont think I'm capable to do something like this, I'm not a programmer. I was just asking if it was compatible, I assume your answer means it is not. Regards Simone
Re: Forbidden account password reuse of the last 5 password
Il 15/02/19 15:50, Howard Chu ha scritto: As for kerberos, you can always run the KDC with OpenLDAP as its backing store, and use e.g. the smbk5pwd overlay to update the kerberos keys when changing a user's LDAP password. IMO this is a superior solution since a single LDAP-based admin tool can take care of standard LDAP as well as Kerberos administration. But it still work only on heimdal or it can be used aslo with MIT kerberos? Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597
Re: Upgrade from 2.4.40 to 2.4.44
Il 15/09/2017 18:33, Michael Ströder ha scritto: > > I hope slapd.conf will never go away. :-/ > I hope that also ... Regards Simone
Re: sasl-auxprop (and sasl/slapd.conf)
Il 17/11/2015 21:46, Dan White ha scritto: On 11/17/15 18:38 +0100, Simone Piccardi wrote: I'm trying to understand which values I can use for the sasl-auxprop directives and how to configure (if possible) sasl/slapd.conf. That's a lot more painful to determine than it should be. Do: I have to agree ... Anyway many thanks for the detailed infos, now I could get it working, that would be an useful addition to the administration guide and the man pages. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
sasl-auxprop (and sasl/slapd.conf)
I'm trying to understand which values I can use for the sasl-auxprop directives and how to configure (if possible) sasl/slapd.conf. I was trying to use the users created with slappasswd2 -c (as written in the Administration guide) but no sasldb file was open by the server (I straced out a full session). I tried to put an explicit configuration in sasl/slapd.conf, and stracing the server I saw it was open and read, but the configuration inside is just ignored. Reading the manpage I found it says that sasl-auxprops "Specify which auxprop plugins to use for authentication lookups." and that the default is use the slapd internal support. But I did not define this one, and sasl/slapd.conf still seems to be ignored. And no possible values for the available plugins to use as sasl-auxprops parameter are listed. I could get DIGEST-MD5 authentication working putting the password inside the server (userPassword in CLEARTEXT), so it seems that the default is used anyway. But I'd like to have it working using using sasldb or configuring sasl/slapd.conf to use saslauthd. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
On 13/05/2014 11:01, Mike Jackson wrote: In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. I don't need anything of this. I just need a simple LDAP server for a small business, where the complexity of dynamic configuration is just a cost with no benefit. And anyway a lot of services (bind, apache, posfix just to name a few) implemented dynamic configuration by the means of a kill -HUP. Simone
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
On 14/05/2014 00:58, Howard Chu wrote: Most people didn't need electricity when they still had oil lamps... If I'm going in a cave almost everytime I still need an oil lamp. Bringing there electricity can be far more costly. Yes for a solution for arbitrarily large networks cn=config could be more scalable and cheaper. But that's not true for a small server for a small organization that doesn't need the extra complexity. I don't want to understate the pros of cn=config, I just state my opinion about the cons. If you tell me the maintaining slapd.conf is too costly in terms of developers energies I've nothing to say. But I don't agree that cn=config is always better. Simone
Re: Converting from slapd.d back to slapd.conf
On 03/27/2014 04:38 PM, Aaron Richton wrote: Would you mind documenting your concerns/experiences for the benefit of the list? (And, for that matter, if there are outright flaws they should be tracked in OpenLDAP's ITS...) I can give my reason: - it's more readable than the ldif slapcat is producing - I can put comments on it - I can go back to a previous configuration just by a cp o editing back the contents Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Converting from slapd.d back to slapd.conf
On 03/28/2014 01:16 PM, Nick Milas wrote: On 28/3/2014 1:25 μμ, Christian Kratzer wrote: I consider cn=config superior once you get your head wrapped around it. On 28/3/2014 12:53 μμ, Simone Piccardi wrote: - I can put comments on it Christian, Please allow me to intervene in the thread to say that your comments are very valid, but still, Simone's need for comments is beyond doubt. It's not only about comments, it's also about readability. The ACL order is a problem, but also having what were directives prefixed by olc make the output far less readable, brain is not fast as sed to remove unuseful (for human understanding) prefixes. Just think what an apache or bind configuration file will look if you prepend olc to almost all keywords. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
On 07/02/2014 18:36, Quanah Gibson-Mount wrote: --On Friday, February 07, 2014 2:25 PM +0100 Simone Piccardi picca...@truelite.it wrote: Not to mention that slapd.conf is still far more readable that any slapd.d ldif... Definitely not. slapd.conf allows people to put things in all sorts of random order that slapd fixes when it reads in the slapd.conf file. I never got any problem with it having always used a it in a correct order with well commented directives. But if ordering is needed not having it enforced in the file configuration syntax is a design defect of slapd, not a shortcoming of using a text file for configuration. cn=config enforces correct ordering, so with cn=config you can tell exactly what is happening, where it can be a muddled mess with slapd.conf. Using apache, postfix, bind, and so on I usually know quite well what is happening, just having a text configuration file. And I can use a generic text editor to modify it, and I don't need to feed the configuration to the program using some dedicated tool or talking the specific protocol they are serving. I agree that the current slapd.conf has lot problems and is prone to abuse, and if you tell me that rewriting it in a saner way or simply mantaining it is too much a burden for developers, I will not raise any further objection. But this does not change the fact that slapd.conf is far more readable than a cn=config ldif file, were the use of LDIF syntax force the use of that ugly curly brace index prefix to order things, and make visible irrelevant (for the sake of configuration) informations like entryCSN, createTimestamp, and the like. Perhaps I'm just getting old, but I still prefer the traditional Unix way to configure services, by the simple use of human (almost) readable text configuration files. Regards Simone -- Simone Piccardi - KeyID:2A972F9D - JabberID:picca...@truelite.it http://piccardi.gnulinux.it - http://www.fountainpen.it Prima ti ignorano, poi ti deridono, poi ti combattono. Poi vinci. M. K. Ghandi
Re: Debian Squeeze: Slapd subtree disappears, but ldapsearch finds it | unable to allocate memory for mutex; resize mutex region
On 05/02/2013 04:08 PM, Quanah Gibson-Mount wrote: --On Thursday, May 02, 2013 8:32 AM +0200 Denny Schierz linuxm...@4lin.net wrote: but than you have to download, patch and update security fixes by your self. Yep. Part of being a competent sys admin anyhow. Sorry, I disagree. A competent sysadmin has to make choices on how he has to employ his time. When having limited resources the choice you suggest can be easily seen as an incompetent wasting of time. For example when you have to manage 70 small server for 70 school, applying security upgrade by recompiling apache, bind, samba, openldap (just to cite some of the services on them) every time is plain wrong. It's a waste of the scarce sysadmin time that could not be afforded. That's just an example, but there are lot of situations in which the solution to bad distribution packaging cannot be recompile it by yourself and reinstall. Better to point to another distribution or to a good packaging (if they exist). Otherwise every competent sysadmin will use the packages, also if they are suboptimal. I'm sorry to hear that Debian OpenLDAP packages are in a such bad state, but if, as it seems, there no distribution getting OpenLDAP right (I heard complaints also about RedHat), then I start thinking that something is not working fine, at least on the user end of OpenLDAP distribution. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Debian Squeeze: Slapd subtree disappears, but ldapsearch finds it | unable to allocate memory for mutex; resize mutex region
On 05/02/2013 06:10 PM, Quanah Gibson-Mount wrote: Sorry, as someone who used to maintain some 600 servers for a major university running a very wide variety of services, I disagree. If you can't figure out an easy way to build and distribute your own packages in an automated fashion, you are putting yourself at the mercy of your distribution provider's capabilities and competence, which has been shown time and again to be severely lacking in multiple areas. I can figure it, but that was not my point. The point is that in a lot of situations people prefer to be at the mercy of a distribution provider and less dependent from a skilled sysadmin (or an external consultant) because this would cost them less on update management. When you have strong budget limits (both in money or skills you can use) inferior solution are willingly chosen because they cost less or have less resource requirements. What I cannot agree is calling this kind of choice incompetence. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Extending smbk5pwd overlay
On 01/16/2012 02:43 PM, Clément OUDOT wrote: Hello, I am interested in extending the features of smbk5pwd overlay to manage more password mechanisms: * Digest MD5 for authentication (see http://en.wikipedia.org/wiki/Digest_access_authentication): we will have MD5(user:domain:password), with configuration for user attribute to use and the domain string * Active Directory password: will use the syntax of AD unicodePwd, in order to sync the attribute into AD What about shadowLastChange updating? Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: smbldap-populate error
Il 03/01/2012 19:59, Adrián Arévalo Tirado ha scritto: First of all. Thanks for the response. I'm totally new to LDAP (so, excuse me if I ask for nonsenses) and, to be honest, I don't know which method uses my distro (Debian 6) for configuration. On every documentation I see, they use /etc/slapd/slapd.conf, but in my case that file doesn't exist. Therefore, I'm using /usr/share/slapd/slapd.conf (The only slapd.conf I find). Recent Debian use the cn=config by default on new installation. You have to add the samba schema (should be inside the samba-doc package), but I don't remember if there is an .ldif version or just the old samba.schema file. Having a working traditional slapd.conf configuration it's just matter to add an include for the samba.schema file. Simone
Re: About set LDAP passwd expires
On 11/11/2011 03:10, Gary Jsz wrote: Hi,All I want set my ldap user's password expires in linux server. how can to do? or the LDAP service read the linux system's /etc/login.defs file? If you use (as almost all distributions are doing) the traditional posixAccount account approach, you must set the shadowMax attribute to the maximum number of days the password can be considered value. And be sure that when you change an user password the shadowLastChange attribute is updated. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: About set LDAP passwd expires
On 11/11/2011 03:31, Chris Jacobs wrote: Password Policy. The OpenLDAP Admin Guide and Google are your friends. That's good for LDAP authentication, but when you want to put linux users in LDAP then you need to have also to configure NSS and PAM to use it. And for most distribution nssov (that if I understand rightly the issue is the way to use ppolicy for NSS) is not packaged nor supported (and is not documented too, at least in the Guide). So at least for me the traditional posixAccount and posixGroup are still a better option (and there are many management packages you can use). Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Overlays syncrepl and smbk5pwd
On 14/11/2011 15:22, Francesco Storti wrote: Hi, I am using both syncrepl (for replication) and smbk5pwd (for password synchronisation between samba and ldap account) overlays. I have configured replication in the simplest way: a read-only producer that forwards updates to the provider thought updateref. If I change my password thought passwd command on a client with pam modules configured for gaining information from the provider everything works fine (userPassword, sambaLMPassword and sambaNTPassword are correctly syncronized). Instead, if I change my password thought passwd command on another client with pam modules configured for gaining information from the consumer only the userPassword is changed. I do not understand why. Has someone experimented the same problem? Thank you in advance. If I remember right password modification is done by an extended operation (at least the one needed for smbk5pwd to work). Not sure if this is forwarded as an ordinary modification. Unfortunately I don't have any experience in your setup, so this can be just a guess. Ciao Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: LDAP and SSL
On 26/09/2011 21:58, criderke...@aol.com wrote: Our network is secure. It's internal, except for the VPN. Access to these apps, even the web-based ones, is blocked by the firewall to outside and other vlans. This LDAP is for company/internal use, not for paying users. In the monkeying around at home I have setup my test systems with SSL, and I am learning it...just wondering if in a production environment we would need the extra layer of security, complexity and overhead. Thanks for the help! So you are thrusting that no one of your users will not just start ettercap and capture all the passwords he wants. That's your choice, but in my opinion is not a good one. Regards Simone
Re: migrating from (old) /etc/shadow to LDAP
On 22/09/2011 16:10, Christopher Wood wrote: Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have compat ldap as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.) This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever. It can be made working with a patched smbk5pwd overlay in the openldap server, but that's not present in Debian or Ubuntu. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
On 23/09/2011 13:20, Howard Chu wrote: Not a major shortcoming. If you're actually using LDAP then you should set expiration using ppolicy and not using shadow attributes at all. Did this solve problems with current nslcd, libnss-ldapd, libpam-ldapd packages on Debian Stable and Ubuntu LTS? I was not aware of this. Anyway I have more than 80 server in schools, with hundred of students registered in each one. When they where created 6 years ago ppolicy was not an option. I prefer to install a patched slapd-smbk5passwd package on each server and have a consistent managament of the actual information than reworking the data in each database and make changes in about 2500 client configurations. Ppolicy could be the future, but I have to deal with the present and the past. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: migrating from (old) /etc/shadow to LDAP
On 23/09/2011 14:42, Christopher Wood wrote: On Fri, Sep 23, 2011 at 12:19:17PM +0200, Simone Piccardi wrote: On 22/09/2011 16:10, Christopher Wood wrote: Debian/Ubuntu: install nslcd, libnss-ldapd, libpam-ldapd, configure your /etc/nslcd.conf, and ensure you have compat ldap as lookups listed in /etc/nsswitch.conf for passwd, group, shadow. (I figure on the whole nss-pam-ldapd arrangement for CentOS6 too, but I haven't gotten that far yet.) This, at least for Debian Stable and Ubuntu LTS has an important shortcoming, it does not update shadowLastChange on password change. So if you set a password expiration they will stay expired forever. This depends where passwords are maintained. Certainly in your case it sounds like the authoritative password copy is maintained in the directory. The problem I'm talking is not about password, they are just in userPassword. Problem arise form the lack of managament of shadowLastChange in the current version of nslcd, libnss-ldapd, libpam-ldapd, for both Squeeze and Lucid. It should work if you use the old libpam-ldap. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: secure passwords
On 14/09/2011 16:54, Michael Ströder wrote: Buchan Milne wrote: IMHO, you shouldn't be hashing passwords on the client-side, it is much better to let the DS hash the password In some use-cases it is better to do client-side hashing. Especially if you want to set more attributes together with attribute 'userPassword' in a single modify request (which means single transaction). I still prefer using Password Modification extended operation. I can use smbk5pwd to automatically update also all the other relevant informations (sambaPwdLastSet, sambaLMPassword, sambaNTPassword), having a much simpler code. It's unfortunate that the patch to update also shadowLastChange was not applied. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: OpenLDAP configuration
On 29/07/2011 08:47, Andreas Laesser wrote: But my critism on the whole thing is, that -it seems- the new config system is cn=config, and it is so poor documented. There are so less howtos and other stuff in the web using cn=config. My criticism is not about missing documentation. I think there is enough of that, and what missing could be added. My criticism, if slapd.conf will be removed, is about the added complexity that will be imposed forcing the use of cn=config on all the people that don't need the benefits it gives. I already stated the reasons for which I strongly prefer simple text configuration files for service deamons, so I won't repeat it here. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 04/07/2011 00:32, Nick Milas wrote:
olcAccess: to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=example,dc=com
by * search
description;x-olcAccess: (1) Allow search on children of example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=com
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
we should be able to easily display:
olcAccess: {0}to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: {1}to dn.children=dc=example,dc=com
by * search
description;x-olcAccess: (1) Allow search on children of example.com
description;x-olcAccess: (1) Entered by Nick on 7/12/2012
olcAccess: {2}to dn.children=dc=com
by * read
description;x-olcAccess: (2) Allow only read on children of com
description;x-olcAccess: (2) Entered by Nick on 7/12/2012
I use comments to clarify things, so to be easy readable is a major
requirement. This doesn't seems so readable to me (personal opinion).
Simone
--
Simone Piccardi Truelite Srl
picca...@truelite.it (email/jabber) Via Monferrato, 6
Tel. +39-347-103243350142 Firenze
http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 03/07/2011 14:21, Howard Chu wrote: What you call a deficiency(sp) is sheer nonsense. Tell me how you expect to provide read/write database access to a file included from any arbitrary filesystem location? Think about the safety of such a proposition as well; not everybody has AppArmor or other security mechanisms on their machines. You cry that it can't do X when in fact it would be irresponsible to ever allow it to do X. You haven't thought it through, you're just babbling. In my use cases I don't need read/write database access to a file for configuration. I can afford to restart slapd to make it reload the configuration file, as it always did until now. What I'm advocating is not losing this feature. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
Il 02/07/2011 00:47, Christopher Wood ha scritto: What stops you from checking the ldif of cn=config into revision control before and after a change? Complexity, because you have to add more steps to have less informations. I don't think there are comments inside cn=config, and those are very important when you have to document and track tens of different installations. Simone
Re: Loading LDAP schema files into cn=config
On 29/06/2011 18:30, Mark Cave-Ayland wrote: On 29/06/11 16:56, Simone Piccardi wrote: Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Because slapd.conf is deprecated and going away in openldap 2.5. So I'd like to get familiar with it now before this happens :) I understood that this was not the case, but I can be wrong. And if yes I hope this decision could be reversed, but I'm not a developer so I can just state my uneasiness about such a choice. As I already said I'm just an old style Unix admin, and as such I don't like at all to be forced to use any kind of program different from just an editor to do a service configuration. Having text configuration files (that can be commented and put under a revision system) is a major strength for an Unix system, and giving it away is very bad. I can afford a restart or a reload in any of the tens of installation I have, but reworking the method we have to take trace of configuration changes made in production servers will be a real pain. I support the choice to make possible configuration change without restarting the service, what I do not support is the choice to remove the use of textual configuration files. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 30/06/2011 19:18, Quanah Gibson-Mount wrote: Again, I urge people to file bug reports etc with distributions when they find issues like these. I do this fairly often with Debian/Ubuntu. As I said I already filed a bug for Debian, is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626911 That's about using /etc/ldap/slapd.d. I will not file any bugs about passing to .ldap files for schemas, because I think .schema files are far more readable, so they are still useful, and there is a clear way to get LDIF files from them where the reverse is not true. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 29/06/2011 16:46, Mark Cave-Ayland wrote: I have been honest enough during this thread to admit that I felt I may have missed something obvious. But I have to point out that all of the Google searches I have done on this topic have returned posts similar to the one I pointed you to, which you are saying are wrong. There is a lot of mis-information out there regarding cn=config but I at least I understand that I need to come to the project itself to get some answers. I understand your frustration here, but it will also take some effort on behalf of the project to ensure that the documentation can answer questions such as mine - I've been using openldap for 3 years now, and cn=config still takes some getting used to. I think that putting the cn=config backend in some other directory instead of /etc/ldap/slapd.d (that's for Debian, don't know for other distributions) could help a lot. Most sysadmin expect to find text configuration files under /etc, not a kind of testual DB. I already filed a bug for Debian because that choice is like looking for trouble. Having it in a binary format could be even better, so people will not mislead thinking they are some kind of split configuration files. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Loading LDAP schema files into cn=config
On 29/06/2011 16:15, Daniel Qian wrote: Not sure if it is the same on Debian but on Fedora I only copied the workplace output schema file (autofs.schema in my case) to /etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I restarted slapd after that and everything worked for me. Surprisingly easy although I had to do a restart. Then I think you must be flamed too... But if you did so, then why just not to stay with slapd.conf? It still work and is far easier to understand and manage. Regards Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Installation openLDAP in Debian
On 28/04/2011 12:00, Hallvard B Furuseth wrote: Olivier Guillard writes: How to survive in operational environnement without comments in files ( nor a way to track change logs btw ) ? I suppose you could put slapd.d/ under version control. After making a change or a set of changes, commit your modified slapd.d/ with your comments in the commit message. Or put comments in other files under slapd.d/. If these filenames do not resemble DNs, e.g. have filetype .txt and no '=' in them, they won't clash with cn=config's filenames. I haven't tried how cumbersome this is/isn't in practice though. Apart the fact we were told not to touch slapd.d, this will raise complexity (adding a VCS, finding a way to relate commens to contens, and so on). So now I need more logic, more programs, when I can do everything with just an editor and some text when having a file. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: Installation openLDAP in Debian
On 20/04/2011 17:30, Jose Ildefonso Camargo Tolosa wrote: Hi! it no longer uses slapd.conf by default, it uses cn=config . It is on /etc/ldap/slapd.d/ Debian will leave you with a working directory (even thought not optimal, but you will be able to use it). If you can be more specific on what you want to do, just let us know! If you are used to configure with slapd.conf, you can actually use that configuration too, or you can convert your slapd.conf configuration into cn=config with slaptest (check the docs!). Ildefonso Camargo That's the way I'm using it. And I suggest to anyone not needing to modify configurations on the fly to use it that way. Because apart the missing documentation, I found difficult having to deal with the obscure attribute names and the complex directory structure (and the not so explicative file names used under it) that I found in /etc/ldap/slapd.d/. I understand the needs for cn=config, but for the moment I don't need it. Having a file with a simple syntax that I can read and modify instead of a tree of LDIF files is far more convenient for me. So I hope that slapd.conf will remain supported. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
