openldap-devel

openldap-devel@openldap.org

1418 discussions

The Last Sysadmin Prayer: Discussion Returns to Wrap and Base64 World
by Angel Bosch 24 Jul '12

24 Jul '12

Hi, I'm struggling with a new CentOS6 installation and turns out that mozldap tools aren't packaged anymore and all my scripts scream out loud because wraping and base64 encoding. I've been reading lots of old petitions of adding wrapping and encoding, testing patches and trying to understand denials. Without being a (truly) developer the only reason I can understand about not implementing this is complexity and lack of time/resources, but seems that some devs already sended patches for those modifications. So I'm really lost: why could be wrong adding a feature that is asked again and again and will help lot of sysadmins make their life better? I know about pipes and string manipulation, but why refusing a non default option that don't break anything? This is specially dramatic for base64 manipulation. mozldap has(had?) a parameter (-e) that "minimize base-64 encoding of values", I don't really know how does it determines if a value should be decoded or not, but it Just Works! In my script-ldap-world i just want to display names, surnames and some description with accents (à, è,...) and some catalan letter (ç). And that's the reason I use decoding 99.99% of times. No photos, blobs or any other exotic embeded object. So please, I mean PLEASE! Could you add a non wrapping and a decoding option to ldap tools? I can't pay my mortage and world if falling down, but I see the light and the end of some patches. abosch

3 4

RE24 testing call#2 (OpenLDAP 2.4.32)
by Quanah Gibson-Mount 18 Jul '12

18 Jul '12

If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.32 release, please do so. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE24 testing call#1 (OpenLDAP 2.4.32)
by Quanah Gibson-Mount 07 Jun '12

07 Jun '12

5 5

Usage of private headers make building out-of-tree extensions painful
by Guillaume Rousse 04 Jun '12

04 Jun '12

As suggested by Howard, I'm posting here what have been originally submitted as an ITS: http://www.OpenLDAP.org/its/index.cgi?findid=7283 Basically, some openldap header files not installed, hence considered as private seems to be needed for building out of tree extensions, such as ppolicy external password: checker (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password). According to howard, at least one of them (slap.h) seems to be mostly useless in this specific case, and could be avoided. The other one, tough (portable.h) seems unavoidable... -- BOFH excuse #238: You did wha... oh _dear_....

3 3

Czy dysponujesz dwoma wolnymi godzinami w tygodniu? Oto jak zarobc 185 EUR w tym czasie.
by ietf-ldapbis＠OpenLDAP.org 26 May '12

26 May '12

Milego dnia! Dziekujemy bardzo za zainteresowanie pozycja regionalnego przedstawiciela dostepna obecnie w Polsce i krajach Europy Srodkowej. Z waszego pozwolenia chce krotko przedstawic Panstwu nasza firme. W.U.G. Inc szybko rozwiwala sie zaczynajac od roku 1992, zeby stac sie jedna z najwiekszych fachowych poradniczych organizacji w swiecie. Siec przedstawicielstw West Union Group jest reprezentowana w ponad 32 krajach i swiadczy uslugi do 46 krajow. Nasza specjalizacja - porada co do podatkowego planowania, rejestracji firm oraz dodatkowe uslugi w zakresie wspierania firm zagranicznych. WUG jest dobrze znana w USA, Kanadzie i niektorych panstwach Unii Europejskiej. Niestety WUG INC nie jest w stanie otworzyc biura operacyjne w kazdym kraju, otoz my oferojemy stanowisko przedstawiciela regionalnego by zatrudnic dodatkowych pracownikow w waszym miescie. Wiele operacji z naszymi klientami odbywa sie online. Regionalny przedstawiciel bedzie musial pomoc klientowi zaplacic za korzystanie z uslug firmy i przekonac sie, ze oplata byla obrobiona pomyslnie. Regionalny Przedstawiciel bedzie odpowiedzialny za pomoc naszym klientom z niektorymi ugodami i przetwarzanie przelewow. Wynagrodzenie Przedstawiciela Regionalnego wynosi 2500 euro miesiecznie. Prosze zrozumiec, ze znaczna czesc zadan zostanie dostarczona przed poludniem lub w ciagu dziennego czasu. Prosimy was odnotowac, ze to nie jest to proces zatrudniania na pelny etat, lecz na niepelny dzien roboczy, tak ze bedziecie mialy szanse utrzymac wasza glowna prace i tracic 2-3 godziny na ta prace. Aby zostac czlonkiem naszego zespolu, wymaga sie, zeby zakonczyliscie dwutygodniowy okres probny. Wszystkie materialy edukacyjne dla procesu szkolenia dostaniecie od waszego osobistego menedzera. Jezeli jestescie zainteresowani we wspolpracy z firma lub chcecie wiedziec wiecej o nas prosimy wyslac nam wasze nazwisko i numer telefonu, a nasz przedstawiciel skontaktuje sie z Panstwem w ciagu tygodnia. Jesli macie jakiekolwiek pytania, prosimy zwracac sie do nas w kazdej chwili o pomoc i nasi przedstawiciele chetnie pomoze Panstwu w kazdej kwestii. Nasz e-mail: Melchior(a)toppolandjobs.com,Najcieplej pozdrawiamy, Melchior Drugnowski Menadzer personelu WUG Inc

3 2

Brakuje Ci pieniedzy? Proponujemy proste rozwiazanie � dodatkowa praca.
by kurt＠OpenLDAP.org 24 May '12

24 May '12

Dzien dobry! Chcielibysmy podziekowac za zainteresowanie wakatem regionalnego przedstawiciela juz dostepnego w Polsce i krajach Europy Srodkowej. Pozwolcie mi w skrocie prezentowac Panstwu nasza wybitna firme. W.U.G. Inc szybko rozwiwala sie zaczynajac od roku 1992, zeby stac sie jedna z najwiekszych fachowych poradniczych organizacji w swiecie. Siec przedstawicielstw West Union Group znajduje sie w ponad 32 krajach swiadczacych uslugi do 46 krajow. Specjalizujemy sie w doradztwie w zakresie planowania podatkowego, rejestracji firm, nadajac rowniez dodatkowe finansowe uslugi wsparcia dla firm zagranicznych. WUG INC jest jedna z najbardziej znanych firm na swiecie, szczegolnie w takich krajach jak USA, Kanadzie i niektorych krajach UE. Niestety WUG INC nie jest w stanie otworzyc biura operacyjne w kazdym kraju, otoz my oferojemy stanowisko przedstawiciela regionalnego by zatrudnic dodatkowych pracownikow w waszym miescie. Przeprowadzamy wiekszosc naszych operacji z klientami biznesowymi glownie za posrednictwem Internetu. Glowne obowiazki przedstawiciela regionalnego beda obejmowac obrobke przelewow pienieznych ze swoich kont i pomagac klientom zaplacic rachunki w potrzebnym czasie. Dlatego regionalny przedstawiciel bedzie mial do czynienia z dosc prostymi, ale bardzo odpowiedzialnymi zadaniami przetwarzania oraz zapewnienie niezbednego wsparcia dla roznych transakcji. Wasza comiesieczna placa zarobkowa zlozy 2500 Euro za miesiac. Prosze zrozumiec, ze znaczna czesc zadan zostanie dostarczona przed poludniem lub w ciagu dziennego czasu. Zwroccie uwage, ze proponujemu pozycje o niepelnym wymiarze godzin, wiec trzeba bedzie wydac tylko 2-3 godzin dziennie na tej prace. Aby zostac czlonkiem naszego zespolu, wymaga sie, zeby zakonczyliscie dwutygodniowy okres probny. Jeden z naszych fachowcow po zatrudnieniu poprowadzi was przez caly proces szkolenia. Aby wyrazic swoje zainteresowanie w powyzszym wakacie nadeslijcie nam swoje dane osobowe (numer telefonu, imie i nazwisko) i nasz manager skontaktuje sie z Panstwem w celu przeprowadzenia wstepnej rozmowy kwalifikacyjnej. Prosimy Panstwo nie wahac sie, zeby z nami skontaktowac, jesli macie dowolne pytania dotyczace pracy, i jeden z naszych przedstawicieli chetnie pomoze wam. Nasz e-mail: Maciej(a)toppolandjobs.com,Najcieplej pozdrawiamy, Maciej Maksymowicz Menadzer personelu WUG Inc

1 0

Added option (-K) on client tools to redirect errors on stdout instead of stderr.
by Hans Deragon 03 May '12

03 May '12

Greetings, I implemented a simple common option (-K) for the client tools that if enabled, sets the file descriptor used to output errors to stdout instead of the default (and currently used) stderr. This is done because when running a batch of commands with the output sent to a file, logs collected are not shown chronologically because the output is split between stdout and stderr. This occurs because both stdout and stderr do not have the same buffer behavior and unfortunately, there is no means within any shell to get them to behave in concert. Here is an example of the output of ldapmodify saved in a file using the current code: ldapmodify: Type or value exists (20) ldapmodify: Type or value exists (20) ldapmodify: Type or value exists (20) modifying entry "uid=User01,ou=MyOrganization,o=example.com " modifying entry "uid=User03,ou=MyOrganization,o=example.com " modifying entry "uid=User04,ou=MyOrganization,o=example.com " modifying entry "uid=User03,ou=MyOrganization,o=example.com " modifying entry "uid=User02,ou=MyOrganization,o=example.com " modifying entry "uid=User05,ou=MyOrganization,o=example.com " modifying entry "uid=User21,ou=MyOrganization,o=example.com " modifying entry "uid=User22,ou=MyOrganization,o=example.com " Now when instructing ldapmodify to redirect errors to stdout, the following output shows up. modifying entry "uid=User01,ou=MyOrganization,o=example.com " modifying entry "uid=User03,ou=MyOrganization,o=example.com " ldapmodify: Type or value exists (20) modifying entry "uid=User04,ou=MyOrganization,o=example.com " ldapmodify: Type or value exists (20) modifying entry "uid=User03,ou=MyOrganization,o=example.com " modifying entry "uid=User02,ou=MyOrganization,o=example.com " ldapmodify: Type or value exists (20) modifying entry "uid=User05,ou=MyOrganization,o=example.com " modifying entry "uid=User21,ou=MyOrganization,o=example.com " modifying entry "uid=User22,ou=MyOrganization,o=example.com " As you can see, in the first case it is impossible to tell which of the multiple operations failed. With my little feature, now it is possible. Many persons on the web complain about this and I believe that my feature will be well received. Default for errors still remain stderr, so normal usage will remain undisturbed. The change to the code is very simple. I change common.c and common.h, added the -K options and replaced stderr with errorfp (default to stderr) in many of the tools' source code. Very low risk of breaking anything. I have been using ldapsearch and ldapmodify a lot with my option. Why -K? Because it is one of the rare letters still available in the long list of options. I would like to submit my changes for review and hopefully, if accepted, that it becomes part of the trunk. However, I do not know how to proceed. Though I am familiar with other configuration management tools, I am not familiar with git, thus if any operation with this tools is required, please provide me examples of commands I should do. Best regards, Hans Deragon http://www.deragon.biz

3 4

RE24 testign call #2 (2.4.31)
by Quanah Gibson-Mount 19 Apr '12

19 Apr '12

If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.31 release, please do so. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

proposal, library error codes for TLS failures
by Jan Včelák 18 Apr '12

18 Apr '12

Hello list. People from SSSD would like to have a better information when some TLS operation in OpenLDAP library fails, instead of a general LDAP_CONNECT_ERROR. I already mentioned it on this list some time ago: http://www.openldap.org/lists/openldap-devel/201105/msg00011.html I can write a patch for this, but I would like to discuss it with you before. I already tried something. I added LDAP_TLS_INITIALIZATION_ERROR (-19) and LDAP_TLS_NEGOTIATION_ERROR (-20) API error codes and slightly modified the TLS code in OpenLDAP to propagate the errors. These two new error codes are sufficient for SSSD. Currently I have covered only the code for Mozilla NSS backend and it still needs some tunings. I would like to know, if adding the error codes this way is acceptable. Should I proceed? Or should it be done a different way? Thanks & regards, Jan

6 9

MDB slapadd potential improvements
by Howard Chu 15 Apr '12

15 Apr '12

I have a "thread" branch on ssh://ada.openldap.org/~hyc/OD/head/.git with some preliminary patches to improve multi-threaded indexing in back-mdb slapadd. So far the scale of improvement is small, but there may be ways to enhance it further from here. Currently back-mdb's multi-threaded indexing code is largely copied from back-bdb/hdb, and it is always slower than regular single-threaded slapadd. The slowdown comes from a number of reasons. 1) Thread synchronization overhead is huge. Much greater than the actual cost of index processing. 2) Index processing is awkward since MDB doesn't support multi-threaded writes (while BDB does). 1) is because we're using cond_wait/cond_broadcast to perform synchronization, and that requires every waiting thread to successfully acquire the condition mutex before progressing any further. So it is inherently serial, even using cond_broadcast. Also, we're doing this twice, once to start all of the index processing for an entry, and once at the end of index processing. The latter one is required so that we will know it's safe to dispose of the current entry and move on to the next. The new code uses a single pthread_barrier for synchronization, and it is only used at the start of index processing. Index cleanup is deferred, and all of the relevant data is double-buffered. This allows us to only need to worry about the start of processing; the processing can take as long as it needs. This restructure requires a small change in slapadd as well, to maintain two Entry pointers instead of just one, and free them in a staggered fashion. The back-bdb/hdb threaded indexer can also be restructured along these lines for a similar benefit. 2) Index results were being gathered in several malloc'd structures and then individually freed after being written to the DB. Now I'm using sl_malloc, and simply resetting the memctx between entries, thus eliminating all cost of free() operations. These changes are sufficient to bring multithreaded performance down to just on par with single-threaded slapadd. In fact there's very little to gain here when all of the DB writes are still single-threaded. One further tweak: most of our index keys are 4-byte hash values. Using the MDB_INTEGERKEY flag allows them to be compared word-at-a-time instead of byte-at-a-time, which gives a further speedup. At present this is the most significant improvement. With the original back-mdb code currently in git master, slapadd of our test LDIF (4.9GB, 6326513 entries, 31 indexed attributes) was taking 1h50m on ada. (Using -q. Without -q, 2h46m.) With no indexing, it takes only 9m11s. Even though sizewise indices don't account for much, they cost a lot in numbers of keys. 6M entries means 6M keys in the id2entry DB and 12M keys in the dn2id DB. Indexing on 31 attributes with multiple values, substrings, and other such parameters thrown in, amounts to hundreds of millions of keys, and each of these needs multiple comparisons to be inserted into their proper index. I tried a further hack on MDB_APPEND to eliminate some more of this overhead. Currently, MDB_APPEND only affects the behavior of mdb_page_split, causing the newly added key to simply be added as the first node of a new page rather than splitting the existing page in half and copying half of the keys to the new page. (This in itself is a pretty major speedup for slapadd, but obviously already factored in.) The new code also simply appends new keys to the end of the DB's last page (rather than searching for its insertion point), which again is useful for eliminating unnecessary comparisons. This is only effective when adding an entryID to an already existing index key. This brought the slapadd -q time down to 1h46m. Turning on the MDB_INTEGERKEY flag brought the slapadd -q time down to 1h32m. Adding the threading rewrite to that, the time came down to 1h29m with tool-threads set to 4. Using more threads actually slows things down, again because thread synchronization becomes too expensive. Only the index key generation is being done in the extra threads, and the reality is that index key generation is not a very significant cost in the overall workload. But anyway, some of the work done here can be ported back into back-bdb/hdb to improve things there. In particular, the use of two synchronization events per entry can be reduced to one by adding double-buffering there too. And some malloc/free overhead in the index threads can be removed by using sl_malloc in each thread. Of course we first need to add pthread_barrier detection to the configure script, as well as wrapper functions in libldap_r. (Anyone interested in handling this? And writing the compatibility code for Windows?) In the meantime, I'm considering an MDB environment option to support multiple threads in a single write TXN, as long as each thread is operating on separate databases. This would hopefully allow us to further distribute the load of indexing without adding too much new complexity to libmdb. If you have an account on ada.openldap.org I encourage you to checkout this code and think about what's suitable to merge back into master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel