[389-devel] Re: 389-devel] Advice on a problem (syncrepl + entryuuid)
>>> >> I still think allowing entryuuid to diverge from nsuniqueid is the right >>> >> call. It opens more scenarioes up to us for migration. >> > >> > Just fyi, when replicating from 389DS to OpenLDAP, we directly map >> > nsUniqueId to entryUuid. They're >> > both UUIDs and both serve the same purpose on their respective servers, so >> > why is there >> > any reason to allow proliferation of other IDs? > > Ahh I believe that you may be referring to the sundsee syncrepl consumer mode > from your 2.5 or git master perhaps? Sadly, this is not the target of my work > - if it was, life would be much easier, and this would not be a problem. In > this case, we have a customer who wants to create read-only openldap > consumers which are able to get data from 389-ds, but they are on version > 2.4.41 of openldap which does not appear to perform this mapping from my > reading of the code (but i've had some mistakes reading code lately, so > perhaps I'm wrong). Yes, the consumer code is only in 2.5, not 2.4. But the mapping is trivial; the nsUniqueId format has the same number of digits as the entryUuid format and only differs by having one less hyphen. So it's quite simple to write an overlay or plugin to convert from one to the other. e.g. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/syncrepl.c#L2112 > Their goal is to move from openldap to 389-ds due to support reasons. So this > means entryuuid which has been a stable ID for a long time in their fleet is > something we need to support - and many external applications do read > entryuuid as a primary key to identify objects in the directory, despite the > fact it should be an internal replication-only element IMO (vmware and > nextcloud come to mind immediately). nsuniqueid (annoyingly) is not the same > format as entryuuid, so we can't just ask them to change to reading nsunique > (even if the bytes were the same). Every day we get to live with the > decisions of the past, and we have the joy of working through and around > them. > > So I think as much as your suggestion is probably correct technically, it > doesn't apply in this situation. > > I am considering that the "solution" in this case though, is that when we see > an entryuuid on an import/add, we derive nsuniqueid from that, so that > entryuuid / nsunique are equivalents in the respective directories, and we > can then re-synthesise the entryuuid from nsunique on the syncrepl. We still > need to store entryuuid however, because client applications will be > expecting it to remain consistent and present during an openldap to 389 > migration. Why wouldn't you just generate entryUuid from nsUniqueId on the fly, as a virtual attribute, when requested in a search/compare? And yes, derive nsUniqueId from entryUuid on an Add. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: Advice on a problem (syncrepl + entryuuid) (William Brown)
> Date: Mon, 22 Jun 2020 15:43:30 +1000 > From: William Brown > Subject: [389-devel] Advice on a problem (syncrepl + entryuuid) > To: "389 Directory server developer discussion." > <389-devel@lists.fedoraproject.org> > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi all, > > I've been a bit stuck on this problem, and I was hoping for some advice or > thoughts. > > So, part of the migration from openldap, and in general, is that we support > entryuuid. That's all fine. I made a decision to allow entryuuid to diverge > from nsuniqueid, as entryuuid is often a primary key in many databases. So we > should be able to bring in entryuuids' that already exist. > > This creates a dilema in syncrepl though. Syncrepl currently uses the > nsuniqueid in place of the entryuuid for sync. It does not appear to be > straight forward to change this to use entryuuid if it exists - when we send > a delete, that comes from the retro changelog, and it stores a delete as a > delete with the nsuniqueid. That also means the entry that held the nsunique > in question may no longer exist so we cant reference what the entryuuid was. > > So this leads me to a problem of "how to solve it". > > I still think allowing entryuuid to diverge from nsuniqueid is the right > call. It opens more scenarioes up to us for migration. Just fyi, when replicating from 389DS to OpenLDAP, we directly map nsUniqueId to entryUuid. They're both UUIDs and both serve the same purpose on their respective servers, so why is there any reason to allow proliferation of other IDs? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: System tap performance results,
389-devel-requ...@lists.fedoraproject.org wrote: > My next steps from here will be: > > * To add USDT probes to the logs and back_ldbm to get better, fine detail > about what is causing the excessive latency. > * these probes are also needed to resolve what appears to be a symbol > resolution issue with systemtap when optimisations are enabled. > * To add probes in other parts of the code base to get better visualisation > about where and how long timings are taking through an operation. > * To run a lock contention profile (I was unable to do this today due to bugs > in systemtap) > * To document the setup proceedures > * Commit all these into a PR > * Document some actionable improvements we can make to improve the server > performance. mutrace will give you a good audit of lock contention, and it's simple to use, takes no setup. http://git.0pointer.net/mutrace.git/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: Issue with building RPMs with ASAN_ON
> Date: Tue, 18 Jun 2019 07:54:43 +0200 > From: Viktor Ashirov > On Tue, Jun 18, 2019 at 1:30 AM Simon Pichugin wrote: >> >> Hi team, >> I'm in the process of creating a Vagrant file which is close to the >> customer's ENV. >> It is heavilly based on Viktor's beaker task. >> I use it for building and testing my code. And it is pretty important to >> build with ASAN. >> >> Currently, what I do is: >> 1. Set 'ASAN_ON = 1' in rpm.mk >> 2. Run `make -f rpm.mk srpms` target >> 3. Build the RPM using `mock -q my_generated.srpm` >> 4. Install it >> >> Then I've tried running `dscreate` manually or running tests with py.test. >> Every time I have the same error here: >> /run/dirsrv/ns-slapd-standalone1.asan.X >> >> ==22487==LeakSanitizer has encountered a fatal error. >> ==22487==HINT: For debugging, try setting environment variable >> LSAN_OPTIONS=verbosity=1:log_threads=1 >> ==22487==HINT: LeakSanitizer does not work under ptrace (strace, gdb, >> etc) > Ludwig also recently had this issue. Looks like you're hitting this > bug: https://github.com/google/sanitizers/issues/723 This bug report is about trying to access mprotect'd memory. It's not directly caused by using memalign. Looks like a red herring. > We're using posix_memalign() in a few places and LeakSanitizier can't handle > it. > There is a workaround in the last comment. I did the builds for gcc8 > and gcc9 in copr, both internal and fedora one, but they failed (not > related to the patch). > So I did a local build with the patch and it worked like a charm. I > will share the links to the rpms for you to try. > > Perhaps we should review our usage of posix_memalign() or convince the > upstream to implement a proper fix for this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: [discuss] Entry cache and backend txn plugin problems
> Date: Tue, 26 Feb 2019 17:21:50 -0700 > From: Rich Megginson > Message-ID: > On 2/26/19 4:26 PM, William Brown wrote: >>> I think the recursive/nested transaction on the database level are not the >>> problem, we do this correctly already, either all or no change becomes >>> persistent. >>> What we do not manage is modifications we do in parallel on the in memory >>> structure like the entry cache, changes to the EC are not managed by any >>> txn and I do not see how any of the database txn models would help, they do >>> not know about ec and can abort changes. >>> We would need to incorporate the EC into a generic txn model, or have a way >>> to flag ec entries as garbage for if a txn is aborted >> The issue is we allow parallel writes, which breaks the consistency >> guarantees of the EC anyway. LMDB won’t allow parallel writes (it’s single >> write - concurrent parallel readers), and most other modern kv stores take >> this approach too, so we should be remodelling our transactions to match >> this IMO. It will make the process of how we reason about the EC much much >> simpler I think. > Some sort of in-memory data structure with fast lookup and transactional > semantics (modify operations are stored as mvcc/cow so each read of the > database with a given txn handle sees its own > view of the ec, a txn commit updates the parent txn ec view, or the global ec > view if no parent, from the copy, a txn abort deletes the txn's copy of the > ec) is needed. A quick google search > turns up several hits. I'm not sure if the B+Tree proposed at > http://www.port389.org/docs/389ds/design/cache_redesign.html has > transactional semantics, or if such code could be added to its > implementation. > > With LMDB, if we could make the on-disk entry representation the same as the > in-memory entry representation, then we could use LMDB as the entry cache too > - the database would be the entry > cache as well. Exactly. This was the original design goal for back-mdb and LMDB in OpenLDAP. http://www.openldap.org/lists/openldap-devel/200905/msg00036.html Note that the back-mdb in OpenLDAP 2.4 is a compromise from this original design; we still have a slight deserialization pass when reading entries from the DB. But it's much simpler and faster than what we used to do with back-bdb/hdb. Ultimately - if your local persistence layer is so slow that it needs an in-memory cache, that local persistence layer is broken. This conclusion is inescapable, after many years of working with BerkeleyDB. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Re: Sign compare checking
Date: Mon, 29 Aug 2016 11:43:27 -0600 From: Rich Megginson <rmegg...@redhat.com> Subject: [389-devel] Re: Sign compare checking To: 389-devel@lists.fedoraproject.org Message-ID: <a7fdb987-8efa-d26d-08c1-3cf0ecb59...@redhat.com> Content-Type: multipart/alternative; boundary=" 2A83E5142B304396ABB138B7" Part of the problem is that we wanted to support being able to use both mozldap and openldap, without too much "helper" code/macros/#ifdef MOZLDAP/etc. It looks as though this is a place where we need to have some sort of helper. (as for why we still support mozldap - we still need an ldap c sdk that supports NSS for crypto until we can fix that in the server. Once we change 389 so that it can use openldap with openssl/gnutls for crypto, we should consider deprecating support for mozldap.) What support for MozNSS is OpenLDAP lacking? Support for MozNSS has been in there for ages now. Patches to make Mozilla work with OpenLDAP instead of mozldap have also been available for ages. https://bugzilla.mozilla.org/show_bug.cgi?id=292127#c17 through comment #30 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Stephen John Smoogen wrote: 1. There is a problem for a certain group that systemd people care about (usually desktop but not always). 2. Systemd puts in a fix for that problem. In this timeline, your step (2) is crucially missing a piece. Systemd has put in a *change* but it has been shown *not* to address the actual problem. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RYKLRYGPNGA6USK4RMDV6FDXTHYIJXZ7/ It's also quite obviously *not* an actual fix, it is a bandaid at best and the real problems remain in other code. Whether or not there's any actual security benefit to the change is a pure non-sequitur. The fact remains that the original problem that prompted the change hasn't been fixed, while numerous legitimate use cases spanning 30+ years of practice get broken. This is *not* good software engineering, by any measure. 3. Someone who isn't using the system that way gets affected and asks/complains/bitches about the fix (depending on the person). 4. Communication goes down hill with the following items you can checkmark regularly: A. Someone 'representing' systemd says its right and it is dragging the neanderthals into the light of 21st century computing. B. Someone 'representing' grognards says its right and it doesn't want know-it-all eggheads pissing on it all the time. C. Someone 'explains' how this fixes a security problem. D. Someone 'explains' how it causes a security problem. E. Both sides tear apart each others arguments. F. Both sides yells, screams, throws insults, emails 'anonymous' death threats to people in the other side. G. Both sides say they are going to take their toys and go home. H. Eventually FESCO has to play adult and tell the groups to work together or no one gets to play. I am guessing we are hitting E and will be going to F soon. G will come sometime after F24 is released (usually 2-3 weeks after release). H. will happen after the deadline for features in F25 occurs. [PS I do not condone or think that any of the steps are good or should be done. It just seems to be the standard bingo for this software. Someone might also be able to put dnf or GNOME into similar categories. ] -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Solomon Peachy wrote: On Wed, Jun 01, 2016 at 10:35:31AM -0400, Dan Book wrote: As mentioned, this isn't just about screen, tmux, and nohup (or if there's any other programs used in a similar context). *Any* command run with a trailing & is commonly expected to survive logout, usually from remote shells. Um, no. There is *no* expectation of a random command surviving loss of its controlling tty (ie logout) unless explcit steps were taken to mitigate it. Such as the command daemonizing itself or ignoring SIGHUP -- either explicitly or via use of nohup (which also gives the added benefit of capturing stdout) '&' in of itself was *never* any sort of guarantee, regardless of foolish expectations to the contrary. Wrong, for all csh users. You folks are all talking from quite narrow perspectives. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Matthias Clasen wrote: On Wed, 2016-06-01 at 09:59 -0400, Matthew Miller wrote: This paints a very specific premise of what a "logout" is, and I'm not sure I agree with it. There are actually many cases where I want to use resources on systems I have accounts on without specifically being logged in — the login session is just a connection in to manage things. Otherwise, we should remove user crontabs, at, and similar. And there are definitely some systems where that policy has a place, but I don't see it making sense as Fedora default, either system wide or for any of the Editions. Explicitly marking things to escape the session (nohup, crontab, starting system services, etc) is very different from just leaking any and all non-terminating processes out of the session. I am very much in favor of systemd enforcing that the session actually ends when I log out, so that I don't accidentally leave processes running. Leaking session processes have been a perennial problem that we have been battling forever (gconf, ibus, pulseaudio, the list goes on...). And they are causing actual problems, from preventing re-login to subtly breaking the next session to slowing down shutdown. So far you have only identified problems associated with GUI sessions. I still see no justification for terminating *all* user processes when it's clear there's only a problem with one very specific class of processes, all being launched in a very specific context. That doesn't mean that you can't have user crontabs. As Lennart says, using those mechanisms should ideally be a privileged operation (with a lenient policy on single-user systems). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Tom Hughes wrote: On 01/06/16 12:19, Howard Chu wrote: This is still looking at the problem back-asswards. The problem isn't that screen and tmux are special cases. The problem is that some handful of programs that got spawned in a GUI desktop environment are special cases, not exiting when they should. I'm sorry, but I disagree. There are basically three things that I'm aware of that are used from a user session to run something in background in a way that will survive the end of the user session and you named them - nohup, screen and tmux. Your awareness is apparently limited. Anything else I put in background with "&" in my shell will be killed when I log out unless it has been disowned which is basically a shell builtin version of nohup. Your shell is not *every* shell. csh and derivatives don't provide (and don't need) "nohup". So things which are intended to survive the end of a login session really are the special case. The default behaviour has always been that things are killed when you logout, False. Your premise is wrong, and your conclusion is wrong. it's just that the way of enforcing that (sending a SIHGHUP) is fairly gentle so things can easily survive without really intending to. Tom -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Tom Hughes wrote: On 01/06/16 11:41, Bastien Nocera wrote: You've obviously never had to run something that's going to take hours or days to complete on a remote server and not wanted it to abort half way through because of a network glitch then. Yeah, I never used nohup. *roll eyes* Sure, nohup is like the cheap version of screen, and systemd-run would do something basically equivalent when linger is enabled. The advantage of screen is being able to interact with the process when necessary, for example when doing an OS upgrade on a remote machine and it want to ask you questions. That's when I use screen, either just setting running something in the background, or leaving it connected but knowing it will continue if anything goes wrong and I can just reattach from a new login. The screen manual says "Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells).". Sure, and I don't generally use any of that. I'm a very simple screen user and just use it for long running tasks that I need to be able to monitor the output of or interact with remotely. I'm not against the change in systemd at all, I would just like cleaner ways to make the handful of things like screen and tmux continue to work. This is still looking at the problem back-asswards. The problem isn't that screen and tmux are special cases. The problem is that some handful of programs that got spawned in a GUI desktop environment are special cases, not exiting when they should. Fix the broken programs, don't force every well-behaved program in the universe to change to accommodate your broken GUI environment. This is Programming 101. The fact is that screen and tmux *aren't* the only programs that can legitimately run in the background. *Any* command can be backgrounded / nohup'd by a user and *all* of them are legitimate in that case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
DJ Delorie wrote: Lennart Poettering <mzerq...@0pointer.de> writes: Again, as mentioned before: key here is that permitting user processes to stick around after all sessions of the user ended needs to be a privilieged concept. It should not be allowed for user code to stick around after logout, unless this is explicitly permitted by the admin, and this hence needs to be enforced by privileged code. How many Fedora installs are multi-user these days? How many single-user desktops are we afflicting with a "you must ask an admin" rule, when there is no admin besides the user sitting at the keyboard? Any rule that tries to split users into "unpriviledged" and "admin" is short-sighted. Agreed. And the basic premise is utterly wrong. The user was obviously permitted to login to the machine, they are therefore permitted to run processes on the machine. Whether their shell process stays alive or not is utterly irrelevant, any other processes that continue to run after their login shell terminates is still legitimately using the machine. To call running without a control terminal "privileged" is inventing new definitions out of thin air. There is no logical basis for it. The entire premise is invalid. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Chris Murphy wrote: On Fri, May 27, 2016 at 7:19 AM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: On Fri, May 27, 2016 at 08:09:33AM -0500, Chris Adams wrote: Once upon a time, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> said: Also note that running jobs in a systemd service has advantages on the server: better accounting, more transparency, logs are easier to read. The (old) default of allowing left-over session processes to live on seems especially bad on a server with multiple users. Starting a one-off task under screen and detaching is an age-old server management process. Breaking that is not acceptable IMHO. This change was done for a reason: left-over session processes are causing real problems. You still can start a one-off task under screen, you just need to invoke it in one the different ways described in https://www.freedesktop.org/software/systemd/man/systemd-run.html#Examples I have to agree, but there is a difference in expectations depending on the system. Fedora Workstation, I expect all processes launched by/owned by me, to be quit on logout. Actually what I expect is by telling GNOME I'm logging out, restarting, or shutting down, that it should send a quit message to all applications. Those applications should be able to interrupt this if there's unsaved data and prompt the user; but better than this would be applications that can save their own state because an application cancelling a reboot is archaic. But often this doesn't work, processes continue to keep the user-session alive because they won't stop running. So we keep seeing these problems on Fedora were the system won't reboot for 1m30s which is the systemd timeout for user sessions that haven't yet quit. If all you care about is your desktop environment getting cleaned up, then you're looking for a feature that is only activated within a desktop context. Historically, people accomplished this by adding commands to .xinitrc. Making this a system-wide default, whether you used a GUI desktop environment or not, is grossly mis-targeting this "fix". So it's a problem. Fedora Server, I expect to login, run tmux, start sessions, detach, and log out and I expect those tmux sessions to keep running. If this workflow is going to change I need some super clean and obvious way to know the right new way to do things or I'll just get annoyed and cranky. Running tmux as a systemd service? I don't know how that'll work, and I'm very skeptical that the user should get dinged with a workflow change just because there are some stubborn programs floating around that won't quit without delay. It seems to me systemd should be able to know the difference between a program that's zombie or unresponsive but isn't doing anything or is unresponsive but is doing something; and if not then some way for programs to say "hey wait just a minute, I need to clean things up" or whatever, rather than just abruptly killing them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
Martin Kolman wrote: On Fri, 2016-05-27 at 18:15 +0200, Björn Persson wrote: Dominique Martinet <dominique.marti...@cea.fr> wrote: Just noticed this change on rawhide... https://github.com/systemd/systemd/blob/master/NEWS#L29 * systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout. This sounds very much like a system-wide Change. Where can I find the Change proposal? Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject .org Also I could see separate Workstation & Server changes - as the impact of this change is IMHO much bigger than on the Workstation where it actually might have benefits in some cases. This change might be reasonable on a Workstation but it makes no sense on a Server. It's debatable whether it's actually reasonable on a Workstation too. Jobs backgrounded with "&" in a shell are expected to keep running. Having to create rules and profiles for every possible command is idiotic. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat
Chris Adams cmadams.net> writes: > > Once upon a time, Neal Gompa gmail.com> said: > > My understanding of the problem is that it's less about the "doubts > > about its future" and more about the fact Oracle inexplicably changed > > the license with BDB 6.x to AGPLv3. Berkley DB 5.3 is old, and no one > > has forked it and maintained it. > > To me, it seems like it would be less work to maintain an already > implemented database (BDB) than to start from scratch. I understand > that nobody is happy with Oracle and their license change, but that > doesn't affect the version already in use in many places. If even a > couple of the current BDB users (say, OpenLDAP and RPM) had stepped up, > it probably wouldn't be that much work, but instead, everybody seems > intent on re-inventing their own wheels (and spending more effort in the > process). > We "reinvented the wheel" with LMDB for multiple reasons, both technical and political. 1) BerkeleyDB is a large code base. 1.7MLOCs https://www.openhub.net/p/berkeleydb . LMDB is only 7KLOCs 2) BerkeleyDB includes a large number of features that are irrelevant to OpenLDAP (hash DBs, replication, multiple other access methods). LMDB is strictly a B+tree. 3) BerkeleyDB is slow, and requires extensive, complex tuning to wring any glimmer of performance out of it. LMDB requires no tuning and is orders of magnitude faster. 4) BerkeleyDB is fragile, and even a slight misconfiguration can render its transaction logs useless for crash recovery. LMDB is crash-proof by design, and that design has held up in the real world. 5) BerkeleyDB lives under a licensing cloud. Since 2008 Oracle lawyers were contacting commercial OpenLDAP users and demanding license fees from them, even though BerkeleyDB is expressly licensed for free use in open source software (such as OpenLDAP). Even if we forked BerkeleyDB and maintained it ourselves, Oracle's lawyers would continue to illegitimately harass OpenLDAP users. LMDB has been in use since 2011. At this point it has saved tremendous administration and maintenance cost, both for us (Symas and OpenLDAP Project) and for all the other projects that have adopted it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[389-devel] please review: Ticket 47941 - openldap - set TLS protocol version in LDAP client library used by server
Date: Fri, 07 Nov 2014 16:57:11 -0500 From: Mark Reynolds marey...@redhat.com To: 389 Directory server developer discussion. 389-devel@lists.fedoraproject.org Subject: [389-devel] please review: Ticket 47941 - openldap - set TLS protocol version in LDAP client library used by server Message-ID: 545d4037.4040...@redhat.com Content-Type: text/plain; charset=utf-8 https://fedorahosted.org/389/ticket/47941 https://fedorahosted.org/389/attachment/ticket/47941/0001-Ticket-47941-set-TLS-protocol-version-in-LDAP-client.patch Strictly speaking, the bug report is incorrect - you can set any libldap option, including TLS_PROTOCOL_MIN, using environment variables, ldap.conf files, or ldaprc files. All as documented in ldap.conf(5) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] RFC: New Design: Fine Grained ID List Size
Rich Megginson wrote: On 09/12/2013 07:08 PM, David Boreham wrote: On 9/11/2013 11:41 AM, Howard Chu wrote: Just out of curiosity, why is keeping a count per key a problem? If you're using BDB duplicate key support, can't you just use cursor-c_count() to get this? I.e., BDB already maintains key counts internally, why not leverage that? afaik you need to pass the DB_RECNUM flag at DB creation time to get record counting behavior, and it imposes a performance and concurrency penalty on writes. Also afaik 389DS does not set that flag except on VLV indexes (which need it, and coincidentally were the original reason for the feature being added to BDB). I'm using bdb 4.7 on RHEL 6. Looking at the code, it appears the dbc-count method for btree is __bamc_count() in bt_cursor.c. I'm not sure, but it looks as though this function has to iterate each page counting the duplicates on each page, which makes it a non-starter. Unless I'm mistaken, it doesn't look as though it keeps a counter on each update, then simply returns the counter. I don't see any code which would make the behavior different depending on if DB_RECNUM is used when the database is created. Ah totally forgot about that, it's been a couple years since I looked inside that code. LMDB updates record counts on every write op so returning the count is zero-cost. (Ironically we don't use this fact to optimize filter evaluation order in OpenLDAP. Probably should...) Also due to the fact that writing a leaf page requires every page up to the root to be updated (copy-on-write design), updating the counts also comes for free since the root page had to be updated anyway. (Or put another way, LMDB writes are already slow by design; updating the counters doesn't make them any slower.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] 389-devel Digest, Vol 99, Issue 6
to figure out a way to have escapes (e.g. if a value contains a comma or an escape character). Was thinking of using LDAP escapes (e.g. \, or \032) -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- Message: 2 Date: Tue, 10 Sep 2013 16:35:07 +0200 From: Ludwig Krispenz lkris...@redhat.com To: Rich Megginson rmegg...@redhat.com Cc: 389 Directory server developer discussion. 389-de...@lists.fedoraproject.org Subject: Re: [389-devel] RFC: New Design: Fine Grained ID List Size Message-ID: 522f2e1b.9010...@redhat.com Content-Type: text/plain; charset=UTF-8; format=flowed On 09/10/2013 04:29 PM, Rich Megginson wrote: On 09/10/2013 01:47 AM, Ludwig Krispenz wrote: On 09/09/2013 07:19 PM, Rich Megginson wrote: On 09/09/2013 02:27 AM, Ludwig Krispenz wrote: On 09/07/2013 05:02 AM, David Boreham wrote: On 9/6/2013 8:49 PM, Nathan Kinder wrote: This is a good idea, and it is something that we discussed briefly off-list. The only downside is that we need to change the index format to keep a count of ids for each key. Implementing this isn't a big problem, but it does mean that the existing indexes need to be updated to populate the count based off of the contents (as you mention above). I don't think you need to do this (I certainly wasn't advocating doing so). The statistics state is much the same as that proposed in Rich's design. In fact you could probably just use that same information. My idea is more about where and how you use the information. All you need is something associated with each index that says not much point looking here if you're after something specific, move along, look somewhere else instead. This is much the same information as don't use a high scan limit here. In the short term, we are looking for a way to be able to improve performance for specific search filters that are not possible to modify on the client side (for whatever reason) while leaving the index file format exactly as it is. I still feel that there is potentially great value in keeping a count of ids per key so we can optimize things on the server side automatically without the need for complex index configuration on the administrator's part. I think we should consider this for an additional future enhancement. I'm saying the same thing. Keeping a cardinality count per key is way more than I'm proposing, and I'm not sure how useful that would be anyway, unless you want to do OLAP in the DS ;) we have the cardinality of the key in old-idl and this makes some searches where parts of the filter are allids fast. Just out of curiosity, why is keeping a count per key a problem? If you're using BDB duplicate key support, can't you just use cursor-c_count() to get this? I.e., BDB already maintains key counts internally, why not leverage that? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
