openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6247)
by michael＠stroeder.com 19 Aug '09

19 Aug '09

daniel(a)pluta.biz wrote: > Some personal thoughts about locale (timezone) support. This seems to be > by far out of scope and probably completely against the intention of > "now.c". > > How can the timezone be evaluated/specified? I think this can only be > achieved on client-side by specifying some kind of +/-HHMM or > timezone-strings in the matching rule's assertion... > > This offers the possibility to chose a timezone on client side (e.g. a > "window" of 46 hours) which is against the intention of "now". > > now.c's original purpose is strictly limited and specialized on data > privacy requirements. Only the server should decide about a currently > (now) valid entry. I don't want to give a client the chance to variable > request a timestamp (e.g by using a filter or even timezone) of > "personal" interest. > > Even with the above described limited scope there seem to be plenty of > open questions before thinking about "office-hours" and so on. Just two > examples regarding the current implementation of now: > - The server's timezone vs. the client's timezone (that's more or less > obvious - in my opinion it's sufficient to store UTC times). > - Replication of "now" attributes' values between slapds that are > located in different timezones and client's that communicate with these > server's... IMHO the client has to convert all user input to GMT and convert all server results to local timezone for presentation to the user. The server internally processes everything as GMT. Maybe I got you wrong though. Other server implementations do it this way when checking logon hours. Ciao, Michael.

1 0

(ITS#6265) ppolicy: modifications in ppolicy_bind_response don't update entries' operational attributes
by jonathan＠phillipoux.net 19 Aug '09

19 Aug '09

Full_Name: Jonathan Clarke Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-ppolicy-20090819.patch Submission from: (NULL) (82.67.204.30) Hi, In the password policy overlay, the function ppolicy_bind_response() contains: Operation op2 = *op; [...] op2.orm_modlist = mod; [...] rc = op2.o_bd->be_modify( &op2, &r2 ); This reuses the original Operation structure (a BIND request) to perform a modification operation. The code changes the value orm_modlist, which is actually in the OpRequest union. This union is thereafter referred to as containing a req_modify_s, not a req_bind_s as before, since this is now a modification operation. However, other fields from req_modify_s are not updated and are interpreted with values set by the bind operation. In particular orm_no_opattrs is set to != 0 (bv_len of the credentials, actually), which causes modifications done by the overlay not to cause updates to operational attributes (which ultimately means these updates are not replicated if we're on a syncrepl provider, which is how I came across this). Sorry for the long explanation, which may seem obvious to those familiar with these structures. The patch above corrects *this* issue. I'm unsure whether orm_increment should also be reset? Probably, I'm guessing. Regards, Jonathan

1 0

(ITS#6264) (docs) Admin guide: bad link in password policy overlay section
by jonathan＠phillipoux.net 19 Aug '09

19 Aug '09

Full_Name: Jonathan Clarke Version: irrelevant OS: irrelevant URL: Submission from: (NULL) (82.67.204.30) In http://www.openldap.org/doc/admin24/overlays.html#Password%20Policies : 8<--------- Please see slapo-ppolicy(5) for complete explanations of features and discussion of "Password Management Issues" at http://www.connexitor.com/forums/viewtopic.php?f=6&t=25 8<--------- This link leads to a "The requested topic does not exist." error.

1 0

(ITS#6247)
by daniel＠pluta.biz 19 Aug '09

19 Aug '09

Some personal thoughts about locale (timezone) support. This seems to be by far out of scope and probably completely against the intention of "now.c". How can the timezone be evaluated/specified? I think this can only be achieved on client-side by specifying some kind of +/-HHMM or timezone-strings in the matching rule's assertion... This offers the possibility to chose a timezone on client side (e.g. a "window" of 46 hours) which is against the intention of "now". now.c's original purpose is strictly limited and specialized on data privacy requirements. Only the server should decide about a currently (now) valid entry. I don't want to give a client the chance to variable request a timestamp (e.g by using a filter or even timezone) of "personal" interest. Even with the above described limited scope there seem to be plenty of open questions before thinking about "office-hours" and so on. Just two examples regarding the current implementation of now: - The server's timezone vs. the client's timezone (that's more or less obvious - in my opinion it's sufficient to store UTC times). - Replication of "now" attributes' values between slapds that are located in different timezones and client's that communicate with these server's...

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 19 Aug '09

19 Aug '09

hyc(a)symas.com wrote: > The TTR feature is now available for testing in HEAD. (As well as the offline > mode switch.) Bind caching is now working in HEAD as well. manpage is up to date, test020 needs some new tests still. Working on 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/

1 0

Re: (ITS#6263) Should www.openldap.org still list slurpd on the front page?
by michael＠stroeder.com 19 Aug '09

19 Aug '09

ghenry(a)OpenLDAP.org wrote: > Should www.openldap.org still list slurpd on the front page? IMO no since a link to 2.4.17 is placed on the front page. Ciao, Michael.

1 0

(ITS#6263) Should www.openldap.org still list slurpd on the front page?
by ghenry＠OpenLDAP.org 19 Aug '09

19 Aug '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi, Should www.openldap.org still list slurpd on the front page? Thanks.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 19 Aug '09

19 Aug '09

> masarati(a)aero.polimi.it writes: >> PS: need to regenerate configure && portable.h > > And portable.hin. Of course. Those who regenerate it know. > Why not commit them? Because. My autotools usually differ from those used by the project. p.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by h.b.furuseth＠usit.uio.no 19 Aug '09

19 Aug '09

masarati(a)aero.polimi.it writes: > PS: need to regenerate configure && portable.h And portable.hin. Why not commit them? -- Hallvard

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Applied to HEAD, please test. p. PS: need to regenerate configure && portable.h

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs