[Freeipa-devel] [freeipa PR#444][comment] Allow nsaccountlock to be searched in user-find commands
URL: https://github.com/freeipa/freeipa/pull/444 Title: #444: Allow nsaccountlock to be searched in user-find commands HonzaCholasta commented: """ I see, I assumed that it's not operational because it's not always set. I stand corrected, but this information does not change anything in respect to the default value search issue. """ See the full comment at https://github.com/freeipa/freeipa/pull/444#issuecomment-284323770 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#444][comment] Allow nsaccountlock to be searched in user-find commands
URL: https://github.com/freeipa/freeipa/pull/444 Title: #444: Allow nsaccountlock to be searched in user-find commands abbra commented: """ The nsaccountlock *is* virtual attribute in 389-ds: attributeTypes: ( 2.16.840.1.113730.3.1.610 NAME 'nsAccountLock' DESC 'Operational attribute for Account Inactivation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryOperation X-ORIGIN 'Netscape Directory Server' ) Notice `USAGE directoryOperation` in the attribute definition. It is treated as a virtual one everywhere in the code but nothing sets it. It is supposed to be set via nsRole and CoS template. See ns-activate.pl/ns-inactivate.pl/ns-accountstatus.pl in 389-ds for external manipulation of it. """ See the full comment at https://github.com/freeipa/freeipa/pull/444#issuecomment-284320588 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#539][comment] Define errors_by_code in ipalib.errors
URL: https://github.com/freeipa/freeipa/pull/539 Title: #539: Define errors_by_code in ipalib.errors HonzaCholasta commented: """ The codes are only relevant for XML-RPC. Why do you need them? """ See the full comment at https://github.com/freeipa/freeipa/pull/539#issuecomment-284319912 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#444][comment] Allow nsaccountlock to be searched in user-find commands
URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands
HonzaCholasta commented:
"""
@abbra, the issue is not that the attribute is not requested (it is in fast
always requested in user commands), it is that when the attribute is not set on
a user entry (that's right, the attribute is *not* operational in 389 DS), the
entry will not be returned in `ipa user-find --disabled=0`, which might be
surprising to the user.
@redhatrises, the framework fix would be to update
`LDAPSearch.get_attr_filter()` to handle the "search for the default value"
case, off the top of my head it should be something like this:
```python
def get_attr_filter(self, ldap, **options):
"""
Returns a MATCH_ALL filter containing all required attributes from the
options
"""
search_kw = self.args_options_2_entry(**options)
search_kw['objectclass'] = self.obj.object_class
default_kw = self.get_default(**options)
filters = []
for name, value in search_kw.items():
flt = ldap.make_filter_from_attr(name, value, ldap.MATCH_ALL)
if name in default_kw and value == default_kw[name]:
# default value search, check also for non-present attribute
flt = ldap.combine_filters([flt, '(!({}=*))'.format(name)])
filters.append(flt)
return ldap.combine_filters(filters, ldap.MATCH_ALL)
```
"""
See the full comment at
https://github.com/freeipa/freeipa/pull/444#issuecomment-284318835
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Please review: V4/AD user short names design draft
On 03/02/2017 02:54 PM, Simo Sorce wrote: On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote: In this case it would probably be a good idea to think about "forward compatibility" and define a new AUX objectclass bringing in 'ipaDomainResolutionOrder' instead of extending two separate objectclasses. In this way we may the just extend whathever object we desire to carry the override in an easy and clean way. I agree. Simo. Now the most difficult question remains... How to name this objectclass. I personally am out of ideas but will try my best to come up with something meaningful. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [freeipa PR#531][comment] httpinstance: disable system trust module in /etc/httpd/alias
URL: https://github.com/freeipa/freeipa/pull/531 Title: #531: httpinstance: disable system trust module in /etc/httpd/alias HonzaCholasta commented: """ Updated to use `modutil -disable` which works even on mod_nss reinstall. """ See the full comment at https://github.com/freeipa/freeipa/pull/531#issuecomment-284312430 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
