Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 8.3.2013 20:09, Rob Crittenden wrote: Petr Spacek wrote: On 8.3.2013 16:45, Rob Crittenden wrote: One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) Yes but when we do that search we've got a full principal. Consider the host plugin. If we are given a non-fully-qualified hostname we add the IPA domain by default when looking for things. It is not uncommon for people to name their laptop after themselves. So if we are told to add a flag to the pspacek principal, which one is it? The user pspacek or the host pspacek.example.com? Or we could require that hostnames are fully-qualified, it would just be a difference from other plugins. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). Would it be possible define some reasonable default value for --type? I don't like typing --service all the time ... Maybe, if we can assume what type of principal is most likely to be updated. Remember that the host/ principal is stored in a host, not a service record. Then again, I don't know how often one is going to be adding flags to principals, so perhaps a required switch wouldn't be too onerous. Since the plugin would be used to manage Kerberos specifics, I think it is fair to require a valid principal as the argument. So it's either user or host/fqdn (or service/fqdn), there's no ambiguity in that and no --type option is required. If you insist on using arbitrary names, I think we better do this in user/host/service plugins, as suggested originally. Setting PAC type is done in the usual place in service plugin after all, even when it is Kerberos-specific. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 8.3.2013 14:41, Simo Sorce wrote: On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. Simo. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling
On 03/11/2013 04:58 PM, Petr Spacek wrote: Hello list! My first patch for FreeIPA is attached :-) I managed to add new 389 DS plugin to build system, but the LDAP magic in installer and updater is too much for my brain. Could somebody show me how installer and updater should add new object to cn=config ? Plugin configuration is static (example is in comments in ipa_dns.c). This patch implements minimal necessary support for idnsSOASerial replication. I investigating more advanced techniques, but I still see problems with locking and so on. Anyway, this patch should be sufficient for now. Commit message: Add 389 DS plugin for special idnsSOASerial attribute handling Default value 1 is added to replicated idnsZone objects if idnsSOASerial attribute is missing. https://fedorahosted.org/freeipa/ticket/3347 I did not review the actual plugin yet, I just added a code to configure this plugin during new install and upgrade. Patch attached. Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copypaste errors: +libipa_uuid_la_LIBADD =\ libipa_uuid?? + $(LDAP_LIBS)\ + $(UUID_LIBS)\ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \not defined, not needed (I will add it in my patch) + $(NULL) + Martin From c62cb358da4ffb5f131438392c29a5a0a0d0b68a Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Tue, 12 Mar 2013 09:46:47 +0100 Subject: [PATCH] Configure ipa_dns DS plugin on install and upgrade The plugin is configured unconditionally (i.e. does not check if IPA was configured with DNS) as the plugin is needed on all replicas to prevent objectclass violations due to missing SOA serial in idnsZone objectclass. The violation could happen if just one replica configured DNS and added a new zone. https://fedorahosted.org/freeipa/ticket/3347 --- daemons/ipa-slapi-plugins/ipa-dns/Makefile.am | 5 + daemons/ipa-slapi-plugins/ipa-dns/ipa-dns-conf.ldif | 15 +++ install/updates/40-dns.update | 16 ipaserver/install/dsinstance.py | 6 ++ 4 files changed, 42 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/ipa-dns/ipa-dns-conf.ldif diff --git a/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am b/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am index a1528358e5e9c2fc32717700e292a86524b86382..6b5a31623b9ee3d99420537786ecfbf85019e90e 100644 --- a/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am +++ b/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am @@ -33,6 +33,11 @@ libipa_uuid_la_LIBADD = \ $(UUID_LIBS) \ $(NULL) +appdir = $(IPA_DATA_DIR) +app_DATA = \ +ipa-dns-conf.ldif \ +$(NULL) + EXTRA_DIST = \ $(app_DATA) \ $(NULL) diff --git a/daemons/ipa-slapi-plugins/ipa-dns/ipa-dns-conf.ldif b/daemons/ipa-slapi-plugins/ipa-dns/ipa-dns-conf.ldif new file mode 100644 index ..808cc966db301e0b2b465e1a99ec37f2e33cd768 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-dns/ipa-dns-conf.ldif @@ -0,0 +1,15 @@ +dn: cn=IPA DNS,cn=plugins,cn=config +changetype: add +objectclass: top +objectclass: nsslapdPlugin +objectclass: extensibleObject +cn: IPA DNS +nsslapd-plugindescription: IPA DNS support plugin +nsslapd-pluginenabled: on +nsslapd-pluginid: ipa_dns +nsslapd-plugininitfunc: ipadns_init +nsslapd-pluginpath: libipa_dns.so +nsslapd-plugintype: preoperation +nsslapd-pluginvendor: Red Hat, Inc. +nsslapd-pluginversion: 1.0 +nsslapd-plugin-depends-on-type: database diff --git a/install/updates/40-dns.update b/install/updates/40-dns.update index 3478a03ca27fc38c3c08d556fcd7af851aea8b9b..7ad366e6099aed5cfd240fa2068d9e41bc2af9aa 100644 --- a/install/updates/40-dns.update +++ b/install/updates/40-dns.update @@ -41,3 +41,19 @@ replace:aci:'(targetattr = idnsname || cn || idnsallowdynupdate || dnsttl || dn # replace DNS tree deny rule with managedBy enhanced allow rule dn: cn=dns, $SUFFIX replace:aci:'(targetattr = *)(version 3.0; acl No access to DNS tree without a permission; deny (read,search,compare) (groupdn != ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;) and (groupdn != ldap:///cn=Read DNS Entries,cn=permissions,cn=pbac,$SUFFIX);)::(targetattr = *)(version 3.0; acl Allow read access; allow (read,search,compare) groupdn = ldap:///cn=Read DNS Entries,cn=permissions,cn=pbac,$SUFFIX or userattr = parent[0,1].managedby#GROUPDN;)' + +# add DNS plugin +dn: cn=IPA DNS,cn=plugins,cn=config +default: objectclass: top +default: objectclass: nsslapdPlugin +default: objectclass: extensibleObject +default: cn: IPA DNS +default: nsslapd-plugindescription: IPA DNS support plugin +default: nsslapd-pluginenabled: on +default: nsslapd-pluginid: ipa_dns +default: nsslapd-plugininitfunc: ipadns_init +default: nsslapd-pluginpath: libipa_dns.so +default: nsslapd-plugintype: preoperation +default: nsslapd-pluginvendor:
Re: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master
On 03/11/2013 05:00 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/07/2013 08:27 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/06/2013 09:52 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
[...]
On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config is added before the entry
itself.
I didn't test everything as I didn't get the access.
[...]
Gotcha. I moved where the replica acis are loaded.
Thanks! Everything works now, I just found two issues in error reporting.
I set up three masters like this:
$ ipa-replica-manage dnarange-show
vm-084.idm.lab.eng.brq.redhat.com: 1109050002-110909
vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999
vm-079.idm.lab.eng.brq.redhat.com: 1109025001-110904
$ ipa-replica-manage dnanextrange-show
vm-084.idm.lab.eng.brq.redhat.com: 110900-1109012499
vm-081.idm.lab.eng.brq.redhat.com: 110919-1109190001
vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set
vm-079 is git master, the other two have the patch applied.
Now when I deleted vm-081, there was no indication which ranges I lost:
vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.redhat.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica
file
and re-install.
Continue to delete? [no]: y
Deleting replication agreements between
vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com
ipa: INFO: Setting agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update succeeded: start: 0: end: 0
Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com:
Insufficient access: Insufficient 'write' privilege to the
'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric
assignment plugin,cn=plugins,cn=config'.
Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com'
Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost
Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com'
to 'vm-081.idm.lab.eng.brq.redhat.com'
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
One more detail: Ranges where start==end are invalid. We should fail the
same way as for startend.
$ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com
677100401-677100401
ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid
DNA configuration.', 'desc': 'Server is unwilling to perform'}
Updating next range failed: Server is unwilling to perform: Changes
result in an invalid DNA configuration.
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Jan Cholasta wrote: On 8.3.2013 20:09, Rob Crittenden wrote: Petr Spacek wrote: On 8.3.2013 16:45, Rob Crittenden wrote: One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) Yes but when we do that search we've got a full principal. Consider the host plugin. If we are given a non-fully-qualified hostname we add the IPA domain by default when looking for things. It is not uncommon for people to name their laptop after themselves. So if we are told to add a flag to the pspacek principal, which one is it? The user pspacek or the host pspacek.example.com? Or we could require that hostnames are fully-qualified, it would just be a difference from other plugins. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). Would it be possible define some reasonable default value for --type? I don't like typing --service all the time ... Maybe, if we can assume what type of principal is most likely to be updated. Remember that the host/ principal is stored in a host, not a service record. Then again, I don't know how often one is going to be adding flags to principals, so perhaps a required switch wouldn't be too onerous. Since the plugin would be used to manage Kerberos specifics, I think it is fair to require a valid principal as the argument. So it's either user or host/fqdn (or service/fqdn), there's no ambiguity in that and no --type option is required. If you insist on using arbitrary names, I think we better do this in user/host/service plugins, as suggested originally. Setting PAC type is done in the usual place in service plugin after all, even when it is Kerberos-specific. I cam to the same conclusion and updated the proposal yesterday this way. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer password migration
On 03/12/2013 10:10 AM, Petr Viktorin wrote:
On 03/11/2013 02:56 PM, Martin Kosek wrote:
On 03/11/2013 01:48 PM, Jan Cholasta wrote:
On 11.3.2013 13:43, Petr Viktorin wrote:
On 03/11/2013 01:13 PM, Jan Cholasta wrote:
On 8.3.2013 14:14, Petr Viktorin wrote:
On 03/07/2013 05:42 PM, Jan Cholasta wrote:
Patch 191:
The patch is missing the ipapython/ipaldap.py file.
On 7.3.2013 18:29, Petr Viktorin wrote:
It's there, it's just copied from ipaserver/ipaldap.py with a small
change at the bottom.
There is no sign of the file, except in the patch header and the patch
cannot be applied with git am nor with git apply. But perhaps I'm doing
something wrong.
Attaching a re-formatted version of the patch.
[...]
ACK.
Honza
ACK for real.
Honza
I would not want to rush this, I still see errors:
1) ipa-ldap-updater is broken:
# ipa-ldap-updater --upgrade
Upgrading IPA:
[1/8]: stopping directory server
[2/8]: saving configuration
[3/8]: disabling listeners
[4/8]: starting directory server
[5/8]: upgrading server
Upgrade failed with 'NameSpace' object has no attribute 'ldap2'
[6/8]: stopping directory server
[7/8]: restoring configuration
[8/8]: starting directory server
Done.
IPA upgrade failed.
Thanks for the catch!
This is a symptom of the fact the plugins attach themselves to the default API
object as soon as they're imported.
Before, ipaldap imported ldap2, so the ldap2 server plugin was magically
available whenever ipaldap was imported before.
Now, ldap2 needs to be imported explicitly if api.Backend.ldap2 needs to be
available.
2) What's the purpose of this new error?
+class DatabaseTimeout(DatabaseError):
+
+**4211** Raised when an LDAP call times out
+
+For example:
+
+ raise DatabaseTimeout()
+Traceback (most recent call last):
+ ...
+DatabaseTimeout: LDAP timeout
+
+
+errno = 4211
+format = _('LDAP timeout')
Thanks for this catch too, I mis-squashed the code to raise it.
It is not raised anywhere (as far as I can see). BTW I assume it is not
related to errors.LimitsExceeded in any way, right?
No, it's timeout in the client↔server communication rather than the LDAP
operation. It wraps ldap.TIMEOUT rather than ldap.TIMELIMIT_EXCEEDED.
3) Client installation no longer works if the server has disabled
anonymous authentication:
# ipa-client-install
Error checking LDAP: Inappropriate authentication: Anonymous access is
not allowed.
DNS discovery failed to determine your DNS domain
Provide the domain name of your IPA server (ex: example.com): ^C
I couldn't reproduce this. But I did find some misleading log messages in this
case. It work well now.
4) I suddenly cannot run some tests, looks like import loop:
# ./make-test tests/test_xmlrpc/test_host_plugin.py
/usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins
tests/test_xmlrpc/test_host_plugin.py
Failure: ImportError (cannot import name ipautil) ... ERROR
==
ERROR: Failure: ImportError (cannot import name ipautil)
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/loader.py, line 390, in
loadTestsFromName
addr.filename, addr.module)
File /usr/lib/python2.7/site-packages/nose/importer.py, line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
File /usr/lib/python2.7/site-packages/nose/importer.py, line 86, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File /root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py,
line 27, in module
from ipapython import ipautil
File /root/freeipa-master/ipapython/ipautil.py, line 52, in module
from ipalib import errors
File /root/freeipa-master/ipalib/__init__.py, line 930, in module
api.finalize()
File /root/freeipa-master/ipalib/plugable.py, line 674, in finalize
self.__do_if_not_done('load_plugins')
File /root/freeipa-master/ipalib/plugable.py, line 454, in
__do_if_not_done
getattr(self, name)()
File /root/freeipa-master/ipalib/plugable.py, line 613, in
load_plugins
self.import_plugins('ipalib')
File /root/freeipa-master/ipalib/plugable.py, line 655, in
import_plugins
__import__(fullname)
File /root/freeipa-master/ipalib/plugins/cert.py, line 30, in module
from ipalib import pkcs10
File /root/freeipa-master/ipalib/pkcs10.py, line 24, in module
from ipapython import ipautil
ImportError: cannot import name ipautil
Gasp... I have no idea how we didn't catch this earlier.
Simplifying a bit, it's partly due to the fact that ipalib does a lot of work
on import in __init__ -- including loading plugins that assume ipalib's
already
set up.
I've deferred the import, and added a FIXME.
Thank you for
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 10:23 +0100, Jan Cholasta wrote: On 8.3.2013 14:41, Simo Sorce wrote: On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0037] Add support for re-enrolling hosts using keytab
On 03/08/2013 03:01 PM, Tomas Babej wrote: On Thu 07 Mar 2013 11:01:33 PM CET, Rob Crittenden wrote: Petr Viktorin wrote: On 03/07/2013 04:27 PM, Tomas Babej wrote: On 03/07/2013 04:12 PM, Petr Viktorin wrote: Thanks! I just have two more very minor nitpicks. On 03/06/2013 01:04 PM, Tomas Babej wrote: On 03/05/2013 02:10 PM, Petr Viktorin wrote: Thanks! The mechanism works, but see below. This is a RFE so it needs a design document. http://freeipa.org/page/V3/Client_install_using_keytab Please also add the link to the commit message. I think you answered Petr²'s security questions adequately. Petr, note that this is a client-side change; if the keytab is compromised the attacker can do all this manually anyway. diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 308c3f8d0ec39e1e7f048d37a34738bf6a4853e2..a16a6b2d7cddbf7085b27c3835a4676919a8a15b 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -104,6 +104,8 @@ def parse_options(): [...] @@ -1691,8 +1693,12 @@ def install(options, env, fstore, statestore): except ipaclient.ntpconf.NTPConfigurationError: pass -if options.unattended and (options.password is None and options.principal is None and options.prompt_password is False) and not options.on_master: -root_logger.error(One of password and principal are required.) +if options.unattended and ((options.password is None and +options.principal is None and +options.keytab is None and +options.prompt_password is False)\ +and not options.on_master): Please also remove the inner parentheses and the backslash. Both fixed, updated patch attached. Tomas ACK, thanks! This needs related man page updates before we can push it. Man pages updated: [tbabej@thinkpad7 freeipa]$ git diff diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-ins [...] +\fB\-k\fR, \fB\-\-keytab\fR +Path to backed up host keytab from previous enrollment. +.TP [...] diff --git a/ipa-client/man/ipa-join.1 b/ipa-client/man/ipa-join.1 [...] +\fB\-f,\-\-force\fR +Force enrolling the host even if host entry exists. +.TP Can you update the design to specifically include that the old certificate needs to be revoked, not just that a new certificate be issued (sort of implied, and it worked in my testing)? I updated the design page accordingly. However, shouldn't be this handled by server side automatically? rob Updated patch attached. I see the requested man page is there, the patches look OK now. Thus, second ACK, pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 118] [WIP] Add 389 DS plugin for special idnsSOASerial attribute handling
On 12.3.2013 10:40, Martin Kosek wrote: On 03/11/2013 04:58 PM, Petr Spacek wrote: Hello list! My first patch for FreeIPA is attached :-) I managed to add new 389 DS plugin to build system, but the LDAP magic in installer and updater is too much for my brain. Could somebody show me how installer and updater should add new object to cn=config ? Plugin configuration is static (example is in comments in ipa_dns.c). This patch implements minimal necessary support for idnsSOASerial replication. I investigating more advanced techniques, but I still see problems with locking and so on. Anyway, this patch should be sufficient for now. Commit message: Add 389 DS plugin for special idnsSOASerial attribute handling Default value 1 is added to replicated idnsZone objects if idnsSOASerial attribute is missing. https://fedorahosted.org/freeipa/ticket/3347 I did not review the actual plugin yet, I just added a code to configure this plugin during new install and upgrade. Patch attached. Just in daemons/ipa-slapi-plugins/ipa-dns/Makefile.am I noticed some copypaste errors: +libipa_uuid_la_LIBADD =\ libipa_uuid?? + $(LDAP_LIBS)\ + $(UUID_LIBS)\ + $(NULL) + +EXTRA_DIST = \ + $(app_DATA) \not defined, not needed (I will add it in my patch) + $(NULL) + Fixed version is attached. -- Petr^2 Spacek From dfded6bffd8a4ee66fff120cd81865755f6432b3 Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Fri, 8 Mar 2013 18:54:58 +0100 Subject: [PATCH] Add 389 DS plugin for special idnsSOASerial attribute handling Default value 1 is added to replicated idnsZone objects if idnsSOASerial attribute is missing. https://fedorahosted.org/freeipa/ticket/3347 Signed-off-by: Petr Spacek pspa...@redhat.com --- daemons/configure.ac | 1 + daemons/ipa-slapi-plugins/Makefile.am | 1 + daemons/ipa-slapi-plugins/ipa-dns/Makefile.am | 40 + daemons/ipa-slapi-plugins/ipa-dns/ipa_dns.c | 211 ++ freeipa.spec.in | 2 + 5 files changed, 255 insertions(+) create mode 100644 daemons/ipa-slapi-plugins/ipa-dns/Makefile.am create mode 100644 daemons/ipa-slapi-plugins/ipa-dns/ipa_dns.c diff --git a/daemons/configure.ac b/daemons/configure.ac index ebf625ebffd8a92e0a3b050955b9376e002ed6c9..2f6cfd5e2683167aa27625c39d2c6f0d99ca2769 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -334,6 +334,7 @@ AC_CONFIG_FILES([ ipa-sam/Makefile ipa-slapi-plugins/Makefile ipa-slapi-plugins/ipa-cldap/Makefile +ipa-slapi-plugins/ipa-dns/Makefile ipa-slapi-plugins/ipa-enrollment/Makefile ipa-slapi-plugins/ipa-lockout/Makefile ipa-slapi-plugins/ipa-pwd-extop/Makefile diff --git a/daemons/ipa-slapi-plugins/Makefile.am b/daemons/ipa-slapi-plugins/Makefile.am index c79e68db112c9d21bcbffba3d00442d2fd20ab3a..08c7558c812effc00ae940661e448779077fb409 100644 --- a/daemons/ipa-slapi-plugins/Makefile.am +++ b/daemons/ipa-slapi-plugins/Makefile.am @@ -2,6 +2,7 @@ NULL = SUBDIRS = \ ipa-cldap \ + ipa-dns \ ipa-enrollment \ ipa-lockout \ ipa-modrdn \ diff --git a/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am b/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am new file mode 100644 index ..319c6676e9df1434feee468fa3861910a28f86dc --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-dns/Makefile.am @@ -0,0 +1,40 @@ +NULL = + +PLUGIN_COMMON_DIR=../common + +INCLUDES = \ + -I. \ + -I$(srcdir) \ + -I$(PLUGIN_COMMON_DIR) \ + -I/usr/include/dirsrv \ + -DPREFIX=\$(prefix)\ \ + -DBINDIR=\$(bindir)\\ + -DLIBDIR=\$(libdir)\ \ + -DLIBEXECDIR=\$(libexecdir)\ \ + -DDATADIR=\$(datadir)\\ + $(AM_CFLAGS) \ + $(LDAP_CFLAGS) \ + $(WARN_CFLAGS) \ + $(NULL) + +plugindir = $(libdir)/dirsrv/plugins +plugin_LTLIBRARIES = \ + libipa_dns.la \ + $(NULL) + +libipa_dns_la_SOURCES = \ + ipa_dns.c \ + $(NULL) + +libipa_dns_la_LDFLAGS = -avoid-version + +libipa_dns_la_LIBADD = \ + $(LDAP_LIBS) \ + $(NULL) + +EXTRA_DIST = \ + $(NULL) + +MAINTAINERCLEANFILES = \ + *~ \ + Makefile.in diff --git a/daemons/ipa-slapi-plugins/ipa-dns/ipa_dns.c b/daemons/ipa-slapi-plugins/ipa-dns/ipa_dns.c new file mode 100644 index ..0769a54aadc54a49909474cf86f8ebc0d228e759 --- /dev/null +++ b/daemons/ipa-slapi-plugins/ipa-dns/ipa_dns.c @@ -0,0 +1,211 @@ +/** BEGIN COPYRIGHT BLOCK + * This Program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License as published by the Free Software + * Foundation; version 2 of the License. + * + * This Program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS + * FOR A PARTICULAR PURPOSE. See the
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Petr Spacek wrote: On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. kadmin.local changes things in LDAP because we use our own backend driver. It doesn't speak LDAP natively. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, Mar 12, 2013 at 08:34:33AM -0400, Simo Sorce wrote: On Tue, 2013-03-12 at 10:23 +0100, Jan Cholasta wrote: On 8.3.2013 14:41, Simo Sorce wrote: On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? iirc Martin introduced a reload of the configuration if it is older than a certain time with the SID blacklist work. bye, Sumit Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 16:00, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) kadmin.local changes things in LDAP because we use our own backend driver. It doesn't speak LDAP natively. rob -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 15:31 +0100, Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? No for 3 reasons. 1. Persistent searches are expensive for the server. 2. The KDC is not threaded so it has no way to react to data being sent down the pipe. It may accumulate for hours and then the KDC would be swamped processing all that data on the first request it gets from a client. 3. The KDC is configured to spawn multiple processes on multi-CPU machines, and that would mean tons of duplication with one persistent search per process, and the associated heavy load on DS would increase even more. We might have a dirty way to do something like this with inotify and a common file we agree upon to 'touch' from DS plugins. The the KDC would be able to reload the configuration only when inotify signals there is a change in the underlying file. It's not really elegant and will probably also require changes to the selinux policy but it would be less heavy weight. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: On 12.3.2013 16:00, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external)
Here's a patch for filtering groups by type.
Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type
The interface is:
StrEnum('type?',
cli_name='type',
label=_('Type'),
doc=_('Group type'),
values=(u'posix', u'normal', u'external'),
),
I have two design questions.
1. Is --type the right option name?
2. Is `normal` the right name for non-posix, non-external group? The
default group type (when adding group) is posix. Should the name be
something else: `simple`, `plain`, `ordinary`?
I didn't want to create an option for each type. IMO it brings more
complexity.
https://fedorahosted.org/freeipa/ticket/3483
--
Petr Vobornik
From 586a14edd30d2754a69aa304a5bd4b2f645273c5 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 11 Mar 2013 12:37:29 +0100
Subject: [PATCH] Filter groups by type (normal, posix, external)
Added option 'type' for filtering groups by type. Allowed values: [normal, posix, external].
Group types:
* normal: not posix, not external
* posix: with objectclass posixgroup
* external: with objectclass ipaexternalgroup
https://fedorahosted.org/freeipa/ticket/3483
---
API.txt| 3 +-
VERSION| 2 +-
ipalib/plugins/group.py| 26 -
tests/test_xmlrpc/objectclasses.py | 1 +
tests/test_xmlrpc/test_group_plugin.py | 97 +-
tests/test_xmlrpc/xmlrpc_test.py | 4 ++
6 files changed, 128 insertions(+), 5 deletions(-)
diff --git a/API.txt b/API.txt
index 734f99e36567aa77b34afeee6d064ca519b2e704..99b8313a8b96edf16273ec5e9a7bde5c78cc772e 100644
--- a/API.txt
+++ b/API.txt
@@ -1307,7 +1307,7 @@ output: Output('result', type 'bool', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
command: group_find
-args: 1,24,4
+args: 1,25,4
arg: Str('criteria?', noextrawhitespace=False)
option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
option: Str('cn', attribute=True, autofill=False, cli_name='group_name', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, query=True, required=False)
@@ -1331,6 +1331,7 @@ option: Flag('private', autofill=True, cli_name='private', default=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Int('sizelimit?', autofill=False, minvalue=0)
option: Int('timelimit?', autofill=False, minvalue=0)
+option: StrEnum('type?', cli_name='type', values=(u'posix', u'normal', u'external'))
option: Str('user*', cli_name='users', csv=True)
option: Str('version?', exclude='webui')
output: Output('count', type 'int', None)
diff --git a/VERSION b/VERSION
index 4108bc808619ed0d6d05e38fb903b2186bc8f925..5c4c932446ce174fe246ceeba8f8e91b776f2488 100644
--- a/VERSION
+++ b/VERSION
@@ -89,4 +89,4 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=54
+IPA_API_VERSION_MINOR=55
diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py
index bde002a8de0c4674432c4c4b4030b6d8c06ec4e1..460adf52a58ab2c95ae143a9be252d4eda32f5c2 100644
--- a/ipalib/plugins/group.py
+++ b/ipalib/plugins/group.py
@@ -19,7 +19,7 @@
# along with this program. If not, see http://www.gnu.org/licenses/.
from ipalib import api
-from ipalib import Int, Str
+from ipalib import Int, Str, StrEnum
from ipalib.plugins.baseldap import *
from ipalib.plugins import baseldap
from ipalib import _, ngettext
@@ -328,10 +328,32 @@ class group_find(LDAPSearch):
cli_name='private',
doc=_('search for private groups'),
),
+StrEnum('type?',
+cli_name='type',
+label=_('Type'),
+doc=_('Group type'),
+values=(u'posix', u'normal', u'external'),
+),
)
def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *args, **options):
assert isinstance(base_dn, DN)
+
+# filter groups by pseudo type
+tflt = None;
+if options.get('type') is not None:
+search_kw = {}
+if options['type'] == u'posix':
+search_kw['objectclass'] = ['posixGroup']
+tflt = ldap.make_filter(search_kw, rules=ldap.MATCH_ALL)
+elif options['type'] == u'external':
+search_kw['objectclass'] = ['ipaExternalGroup']
+tflt = ldap.make_filter(search_kw, rules=ldap.MATCH_ALL)
+else:
+search_kw['objectclass'] = ['posixGroup' , 'ipaExternalGroup']
+tflt = ldap.make_filter(search_kw, rules=ldap.MATCH_NONE)
+del options['type']
+
# if looking for private groups, we need to create a new search filter,
# because private groups have
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page
On 03/06/2013 01:42 PM, Petr Vobornik wrote:
On 03/02/2013 08:40 PM, Endi Sukma Dewata wrote:
- Original Message -
First two patches are bug fixes which are required for third patch.
Depends on my patch #259 (Combobox keyboard support)
1) [PATCH] Fix dirty state update of editable combobox
Editable combobox didn't update it's dirty state correctly. CB had
it's own internal value changed event, which was incorrectly used. It
was
removed and widget's value_changed event was used instead.
ACK.
Pushed to master
2) [PATCH] Fix handling of no_update flag in Web UI
There was an incorrect check for no_update flag. Check was performed
as if the flag was an attribute of object not an item of array. Hence,
the flag never caused any effect.
ACK.
Pushed to master
3) [PATCH] Global trust config page
https://fedorahosted.org/freeipa/ticket/
Just two notes:
ipantfallbackprimarygroup requires a posix group. Our API currently
doesn't support search based on object classes therefore the entity
select widget incorrectly offers non posix groups as well.
Are we planning to add the missing functionality? Right now you'll get
'group not found' if you select a non-POSIX group, which is confusing
because the group does exist. Possible solutions:
Waiting for [RFE] Add option for filtering groups by type (posix,..) in
group-find command to be implemented to solve issue.
Triaged to march and implemented. Patch 267 is on review.
This patch is modified accordingly.
8-
Another problem is that hidden 'Default SMB Group' is not listed.
Hence it couldn't be set again after a modification. I made the combobox
editable (first usage, so it revealed a bug) to avoid this problem.
User can enter garbage, but the framework should handle that.
This is a little difficult to use. You'll need to know that you have to
type 'Default SMB Group' to go back to the default and the UI doesn't
show that as an acceptable value. Possible solutions:
1. Add the 'Default SMB Group' as the first entry in the drop down list
so you can reselect it again. The drop down list doesn't need to be
editable.
2. Use radio buttons to separate the default value from other values:
Fallback primary group: (o) Default SMB Group
( ) POSIX group: [ drop down list ]
Regardless, I think the server API needs to be changed to accept an
empty value to go back to the default value instead of taking 'Default
SMB Group'. A default value should be simple and not something that will
potentially conflict with a non-default value that happens to have the
same name.
I agree. Martin is it feasible?
From other emails: Apparently its not worth the time. So I implemented #1.
3. Found an issue: trusctconfig-show will raise 'not found' error when
trusts are not configured on a system. It's fixed separately in attached
patch #268. It has similar behavior as dns pages.
Also I added data .json files to patch 262 and 268, so the static
version can be used.
--
Endi S. Dewata
--
Petr Vobornik
From 146e1b8d084399a7cf3518d1f7be08137c97a33a Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 12 Mar 2013 17:00:32 +0100
Subject: [PATCH] Don't show trusts pages when trust is not configured
When trust is not configured trust-config page is raising an error. Trusts search page won't find anything either - no use for the pages - hiding.
https://fedorahosted.org/freeipa/ticket/
---
install/ui/src/freeipa/ipa.js | 12 +++-
install/ui/src/freeipa/trust.js| 14 ++
install/ui/test/data/ipa_init.json | 25 -
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/install/ui/src/freeipa/ipa.js b/install/ui/src/freeipa/ipa.js
index 0d5c0bbdc5d2346c291260781d253010019bd65a..c1ed722144967e87e4e7c4937aea2db50be0d669 100644
--- a/install/ui/src/freeipa/ipa.js
+++ b/install/ui/src/freeipa/ipa.js
@@ -140,7 +140,17 @@ var IPA = function() {
}
}));
-
+batch.add_command(IPA.command({
+entity: 'trustconfig',
+method: 'show',
+retry: false,
+on_success: function(data, text_status, xhr) {
+that.trust_enabled = true;
+},
+on_error: function(xhr, text_status, error_thrown) {
+that.trust_enabled = false;
+}
+}));
batch.execute();
};
diff --git a/install/ui/src/freeipa/trust.js b/install/ui/src/freeipa/trust.js
index b79379746e32c121f27938fc313368b86fa6a24b..964f94988b3f1c7aaa1b9e79bf63f8f3fbf656da 100644
--- a/install/ui/src/freeipa/trust.js
+++ b/install/ui/src/freeipa/trust.js
@@ -28,6 +28,13 @@ IPA.trust.entity = function(spec) {
var that = IPA.entity(spec);
that.init = function() {
+
+if (!IPA.trust_enabled) {
+throw {
+expected: true
+};
+}
+
that.entity_init();
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 18:01, Simo Sorce wrote: On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master
Petr Viktorin wrote:
On 03/11/2013 05:00 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/07/2013 08:27 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/06/2013 09:52 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
[...]
On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config is added before the entry
itself.
I didn't test everything as I didn't get the access.
[...]
Gotcha. I moved where the replica acis are loaded.
Thanks! Everything works now, I just found two issues in error reporting.
I set up three masters like this:
$ ipa-replica-manage dnarange-show
vm-084.idm.lab.eng.brq.redhat.com: 1109050002-110909
vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999
vm-079.idm.lab.eng.brq.redhat.com: 1109025001-110904
$ ipa-replica-manage dnanextrange-show
vm-084.idm.lab.eng.brq.redhat.com: 110900-1109012499
vm-081.idm.lab.eng.brq.redhat.com: 110919-1109190001
vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set
vm-079 is git master, the other two have the patch applied.
Now when I deleted vm-081, there was no indication which ranges I lost:
vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.redhat.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica
file
and re-install.
Continue to delete? [no]: y
Deleting replication agreements between
vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com
ipa: INFO: Setting agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update succeeded: start: 0: end: 0
Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com:
Insufficient access: Insufficient 'write' privilege to the
'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric
assignment plugin,cn=plugins,cn=config'.
Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com'
Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost
Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com'
to 'vm-081.idm.lab.eng.brq.redhat.com'
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Fixed.
One more detail: Ranges where start==end are invalid. We should fail the
same way as for startend.
$ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com
677100401-677100401
ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid
DNA configuration.', 'desc': 'Server is unwilling to perform'}
Updating next range failed: Server is unwilling to perform: Changes
result in an invalid DNA configuration.
done
rob
From 2fb6da167cb5cb8ab366c9d2a7b701f903cddb78 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Fri, 1 Mar 2013 15:02:14 -0500
Subject: [PATCH] Extend ipa-replica-manage to be able to manage DNA ranges.
Attempt to automatically save DNA ranges when a master is removed.
This is done by trying to find a master that does not yet define
a DNA on-deck range. If one can be found then the range on the deleted
master is added.
If one cannot be found then it is reported as an error.
Some validation of the ranges are done to ensure that they do overlap
an IPA local range and do not overlap existing DNA ranges configured
on other masters.
http://freeipa.org/page/V3/Recover_DNA_Ranges
https://fedorahosted.org/freeipa/ticket/3321
---
install/share/delegation.ldif | 9 ++
install/share/replica-acis.ldif| 5 +
install/tools/ipa-replica-manage | 288 -
install/tools/man/ipa-replica-manage.1 | 45 +-
install/updates/40-replication.update | 12 ++
ipaserver/install/dsinstance.py| 3 +-
ipaserver/install/replication.py | 98 +++
ipaserver/ipaldap.py | 2 +
8 files changed, 453 insertions(+), 9 deletions(-)
diff --git a/install/share/delegation.ldif b/install/share/delegation.ldif
index f62062fe498634d56128ebf78874c3ba91d7d09b..14069586cf1f1021d281a3e86133de1535b62559 100644
--- a/install/share/delegation.ldif
+++ b/install/share/delegation.ldif
@@ -545,6 +545,15 @@ cn: Remove Replication Agreements
ipapermissiontype: SYSTEM
member: cn=Replication Administrators,cn=privileges,cn=pbac,$SUFFIX
+dn: cn=Modify DNA Range,cn=permissions,cn=pbac,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: groupofnames
+objectClass: ipapermission
+cn: Modify DNA Range
+ipapermissiontype: SYSTEM
+member: cn=Replication Administrators,cn=privileges,cn=pbac,$SUFFIX
+
# Entitlement management
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: On 12.3.2013 18:01, Simo Sorce wrote: On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? The problem is determining if all the flags can be set by the same set of admins or if we need to be able to delegate some of them. In the second case we have only 2 options: 1) break the flags out in multiple attributes so we can set separate ACIs 2) create a plugin that can intercept and filter modifications to the attribute so only the allowed flags are changed The first option has the problem that we are going to change the schema. The second option has the problem that the check will be less flexible than with regular ACIs (unless we use some sort of virtual ACI) and duplicates access control points. Anyway we need to find out if we really need fine grained access control per flags or not before wrapping our heads. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
