[Freeipa-devel] [PATCH 0272] Server upgrade: log more into debug log instead of info log
Update is logging too much info into info log.
Patch attached.
--
Martin Basti
From 9af056e70bc8ea3a0aa50269e6e7fe7af174e68c Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Mon, 8 Jun 2015 17:33:11 +0200
Subject: [PATCH] Server Upgrade: use debug log level for upgrade instead of
info
Upgrade contains too many unnecessary info logs.
---
ipalib/plugins/permission.py | 2 +-
ipaserver/install/ldapupdate.py| 30 +++---
ipaserver/install/plugins/adtrust.py | 4 +--
ipaserver/install/plugins/dns.py | 8 +++---
ipaserver/install/plugins/update_idranges.py | 2 +-
.../install/plugins/update_managed_permissions.py | 22
ipaserver/install/plugins/update_referint.py | 2 +-
ipaserver/install/schemaupdate.py | 10
8 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index f46affc34cfa6f49c2ca1b3947a39ca5ec2549b9..f2e896935cc777801ec3a70262372f296b1ea2b8 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -648,7 +648,7 @@ class permission(baseldap.LDAPObject):
try:
ldap.update_entry(acientry)
except errors.EmptyModlist:
-self.log.info('No changes to ACI')
+self.log.debug('No changes to ACI')
return acientry, acistring
def _get_aci_entry_and_string(self, permission_entry, name=None,
diff --git a/ipaserver/install/ldapupdate.py b/ipaserver/install/ldapupdate.py
index f30659fe96ea57512ccf5c053d0bc4add348061d..7359dbc4e549c57fad2b7048611252c92f8eb66d 100644
--- a/ipaserver/install/ldapupdate.py
+++ b/ipaserver/install/ldapupdate.py
@@ -544,7 +544,7 @@ class LDAPUpdate:
nsIndexAttribute=[attribute],
)
-self.info(Creating task to index attribute: %s, attribute)
+self.debug(Creating task to index attribute: %s, attribute)
self.debug(Task id: %s, dn)
self.conn.add_entry(e)
@@ -580,7 +580,7 @@ class LDAPUpdate:
continue
if status.lower().find(finished) -1:
-self.info(Indexing finished)
+self.debug(Indexing finished)
break
self.debug(Indexing in progress)
@@ -652,7 +652,7 @@ class LDAPUpdate:
try:
entry_values.remove(update_value)
except ValueError:
-self.warning(remove: '%s' not in %s, update_value, attr)
+self.debug(remove: '%s' not in %s, update_value, attr)
else:
entry[attr] = entry_values
self.debug('remove: updated value %s', safe_output(
@@ -746,15 +746,15 @@ class LDAPUpdate:
raise BadSyntax, More than 1 entry returned on a dn search!? %s % new_entry.dn
entry = e[0]
found = True
-self.info(Updating existing entry: %s, entry.dn)
+self.debug(Updating existing entry: %s, entry.dn)
except errors.NotFound:
# Doesn't exist, start with the default entry
entry = new_entry
-self.info(New entry: %s, entry.dn)
+self.debug(New entry: %s, entry.dn)
except errors.DatabaseError:
# Doesn't exist, start with the default entry
entry = new_entry
-self.info(New entry, using default value: %s, entry.dn)
+self.debug(New entry, using default value: %s, entry.dn)
self.print_entity(entry, Initial value)
@@ -779,8 +779,8 @@ class LDAPUpdate:
except errors.NotFound:
# parent entry of the added entry does not exist
# this may not be an error (e.g. entries in NIS container)
-self.info(Parent DN of %s may not exist, cannot create the entry,
-entry.dn)
+self.error(Parent DN of %s may not exist, cannot
+ create the entry, entry.dn)
return
added = True
self.modified = True
@@ -799,9 +799,9 @@ class LDAPUpdate:
self.debug(Updated %d % updated)
if updated:
self.conn.update_entry(entry)
-self.info(Done)
+self.debug(Done)
except errors.EmptyModlist:
-self.info(Entry already up-to-date)
+self.debug(Entry already up-to-date)
updated = False
except errors.DatabaseError, e:
self.error(Update failed: %s, e)
@@ -827,11 +827,11 @@ class LDAPUpdate:
dn = updates['dn']
try:
-self.info(Deleting entry %s, dn)
+self.debug(Deleting entry %s, dn)
Re: [Freeipa-devel] [PATCH 0050] Fix client ca.crt to match the server's cert
On 01/07/15 09:05, Martin Basti wrote: On 30/06/15 17:31, Gabe Alford wrote: On Tue, Jun 30, 2015 at 8:51 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 16/06/15 16:58, Gabe Alford wrote: I know you guys are busy. Bump for review. Thanks, Gabe On Tue, May 26, 2015 at 8:16 AM, Gabe Alford redhatri...@gmail.com wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/3809 Thanks, Gabe I'm getting certificate on server without extra '\n' at the end. So certificate files are not the same. I assume you did a diff of the server /etc/ipa/ca.crt and the client /etc/ipa/ca.crt, right? Did you setup a server and then connect a client (just wonder what your steps were so that I can also reproduce)? Yes. I did that. I will retest it today. Retested and ca.cert on client has extra '\n' at the end. -- Martin Basti -- Martin Basti -- Martin Basti -- 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] [PATCH 0046] DNSSEC: Store time date key metadata in UTC
On 30/06/15 14:36, Petr Spacek wrote: Hello, DNSSEC: Store time date key metadata in UTC. OpenDNSSEC stores key metadata in local time zone but BIND needs timestamps in UTC. UTC will be stored in LDAP. https://fedorahosted.org/freeipa/ticket/4657 ACK -- Martin Basti -- 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] [PATCH] 0020..0022 pki-related upgrade fixes
On 30/06/15 18:02, Fraser Tweedale wrote: On Mon, Jun 29, 2015 at 05:56:11PM +0200, Martin Basti wrote: On 29/06/15 16:03, Fraser Tweedale wrote: On Thu, Jun 25, 2015 at 11:23:01AM +0200, Martin Basti wrote: On 19/06/15 09:28, Fraser Tweedale wrote: The attached patches fix upgrade issues when pki is also updated from pre 10.2.4. pki dependency is bumped to 10.2.5 - the official builds should be done Friday (US time) but it is available from my copr[1]. If someone wants to add to official freeipa COPR in meantime the SRPM is here[2]. [1] https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ [2] https://ftweedal.fedorapeople.org/pki-core-10.2.5-0.2.fc21.src.rpm Thanks, Fraser Thank you. 1) I cannot apply patches. Rebased patches attached. 2) IMO patch 0020 was fixed with my patch 266 It seems we are hitting another case of LDAP disconnection during upgrade; without 0020 the upgrade fails. There might be a better way so let me know if you have ideas. 3) This print should not be there + +print cs_cfg +for profile_id in profile_ids: Thakns; removed. 4) This is unused variable, it is defined later + cs_cfg = None Thanks; removed. 5) Can you add there log.error or log.debug instead of pass please? +# enable the profile +try: +profile_api.enable_profile(profile_id) +except errors.RemoteRetrieveError: +pass You've got it. Also did this a few lines up where the profile is disabled. I will test it later. -- Martin Basti Thank you, Fraser PATCH 0020 - NACK see my patch 269, it fixes root cause. (IMO with reworked patch 21 it is not needed) PATCH 0021 - NACK, it runs whole upgrade machinery again. Patch how to fix it is attached. Sorry I didn't notice it last time. PATCH 0022 - LGTM -- Martin Basti Thank you very much! Your patch to my patch works perfectly. I squashed it into 0021. Patch 0020 rescinded. Rebased patches attached. Cheers, Fraser Thank you, ACK for both patches. -- Martin Basti -- 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] [PATCH 0275] DNS commands: do not show traceback if DNS is not installed
On 07/01/2015 05:53 PM, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/5017 Patch attached Repeated code hurts my eyes, but abstracting it seems like an overkill. ACK. Pushed to master: 96c23659fcb8adc64dd925556fb40f558fa7e37d -- 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] topology plugin woes
I am working on the replica promotion code and suddenly the topology plugin is getting in the way. First thing I noticed is that it converted an agreement into a segment even though my domain level is 0, is this expected ? I thought we'd enable the plugin only when level - 1 By taking over immediately it will break ipa management tools from older serves which know nothing about dealing with segments, they only know about direct removal of replication agreements. The other problem is that it seem I can't remove the replication agreement even if I removed all references to the (failed) replica I installed. It complains it would cause split brain .. but this is the last replica and I already removed the master's computer object, why is the topology plugin not recognizing the master is no more and not letting me remove the segment ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] [PATCH] 891 replication: fix regression in get_agreement_type
dcb6916a3b0601e33b08e12aeb25357efed6812b introduced a regression where get_agreement_type does not raise NotFound error if an agreement for host does not exist. The exception was swallowed by get_replication_agreement. -- Petr Vobornik From 4dd4f13c2fc746f800ebbfc81f084ef0690bec63 Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Wed, 1 Jul 2015 18:27:05 +0200 Subject: [PATCH] replication: fix regression in get_agreement_type dcb6916a3b0601e33b08e12aeb25357efed6812b introduced a regression where get_agreement_type does not raise NotFound error if an agreement for host does not exist. The exception was swallowed by get_replication_agreement. --- ipaserver/install/replication.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipaserver/install/replication.py b/ipaserver/install/replication.py index efdb7dfdfed1800c2a7f9720e1ce4f5e9ccf42b7..3b5ed29e584b40f1e38f4e068bcef2fbe78c4434 100644 --- a/ipaserver/install/replication.py +++ b/ipaserver/install/replication.py @@ -1169,6 +1169,9 @@ class ReplicationManager(object): def get_agreement_type(self, hostname): entry = self.get_replication_agreement(hostname) +if not entry: +raise errors.NotFound( +Replication agreement for %s not found % hostname) objectclass = entry.get(objectclass) for o in objectclass: -- 2.4.3 -- 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] [PATCHES 306-316] Automated migration tool from Winsync
On 06/30/2015 05:55 PM, Tomas Babej wrote: On 06/16/2015 01:01 PM, Jan Cholasta wrote: Dne 16.6.2015 v 10:14 Martin Babinsky napsal(a): On 05/06/2015 10:12 AM, Tomas Babej wrote: On 05/05/2015 02:02 PM, Tomas Babej wrote: On 04/29/2015 12:28 PM, Tomas Babej wrote: On 03/11/2015 04:20 PM, Jan Cholasta wrote: Hi, Dne 10.3.2015 v 16:35 Tomas Babej napsal(a): On 03/09/2015 12:26 PM, Tomas Babej wrote: Hi, this couple of patches provides a initial implementation of the winsync migration tool: https://fedorahosted.org/freeipa/ticket/4524 Some parts could use some polishing, but this is a sound foundation. Tomas Attaching one more patch to the bundle. This one should make the winsync tool readily available after install. Tomas Nitpicks: The winsync_migrate module should be in ipaserver.install. Also I don't see why it has to be a package when there is just one short file in it. By convention, the AdminTool subclass should be named WinsyncMigrate, or the tool should be named ipa-migrate-winsync. Honza Updated patches attached. Tomas Rebased patches with cleaned membership bits. Tomas I did some self-review, updated patches attached. Hi Tomas, patches look good and seem to work as expected. I have some comments: 1.) When running the tool I get a number of warnings about users not found (https://paste.fedoraproject.org/232251/43884831/), but in the end everything seems to be fine and users are migrated in the external groups just fine. Is this behavior normal? In that case, yes. What happened here is that SSSD in POSIX trust will not resolve users that do not have POSIX attributes set. Winsync synchornizes all the users, hence the discrepancy. 2.) Since both --realm and --server options are mandatory, I was thinking if it would be better to use positional arguments, since you always have to specify them. What are your thought on this? I would rather stay consistent with ipa-server-install and friends and keep them as options. 3.) Patches 317-318 seem to just just rename/move things and could be squashed in the previous ones. But that is just a minor thing and I leave that to your discretion. 4.) After all the renaming and moving around the WinsyncMigrate class (see previous point) there is an unused file ipaserver/winsync_migrate/__init__.py left. You should remove it in some patch (e.g. in patch 318 if you decide to keep it). I removed the file and squashed the change into 318. Also please rename the class to MigrateWinsync, for consistency. Naming is consistent, the tool is called ipa-winsync-migrate, class is called WinsyncMigrate. This is consistent with other IPA tools. 5.) Option --log-file seems to be broken. When specified on CLI the log is created but empty, the program prints out nothing and then exits without doing anything. However, I suspect that this is AdminTool's problem, not yours. Yep. Please, file a ticket for this more generic issue. Will do. Otherwise ACK. -- 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
Re: [Freeipa-devel] topology plugin woes
On Wed, 2015-07-01 at 14:34 -0400, Simo Sorce wrote: I am working on the replica promotion code and suddenly the topology plugin is getting in the way. First thing I noticed is that it converted an agreement into a segment even though my domain level is 0, is this expected ? I thought we'd enable the plugin only when level - 1 By taking over immediately it will break ipa management tools from older serves which know nothing about dealing with segments, they only know about direct removal of replication agreements. The other problem is that it seem I can't remove the replication agreement even if I removed all references to the (failed) replica I installed. It complains it would cause split brain .. but this is the last replica and I already removed the master's computer object, why is the topology plugin not recognizing the master is no more and not letting me remove the segment ? Ugh, I just found the Domain Level is set to 1 ... ok so it is ok the topology is managed, but why can't I remove the segment if the server object is gone ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] [PATCH 0274] DNS: Check if dns package is installed
On 07/01/2015 04:45 PM, Petr Spacek wrote: On 1.7.2015 15:32, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4058 Requires patch freeipa-pspacek-0052 ACK I must admit I don't really like wrapping a constant in the method in the TaskNamespace object. We're interested in the constant itself - there's no case I can imagine where the name of the freeipa's dns package will be dynamic. For paths we have BasePathNamespace that contains all the paths, maybe we should introduce something similar for the non-path platform dependent constants? Tomas -- 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] [PATCH 0018] allow deletion of segment, if not both nodes are managed
On Wed, 2015-07-01 at 12:05 +0200, Ludwig Krispenz wrote: This fix allows the removal of segments, where not both endpoints of the segments are managed. These segments can exist after deliberately disconnecting a topology by removal of a central node, a fix to automatically remove dangling segments is in process, but it cannot handle all situations, especially if the removed server is no longer working and the topology is already broken before the removal. In these cases a manual cleanup must be possible and is addressed in this patch Ludwig Tested and works as expected. Full ACK. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] [PATCH 0018] allow deletion of segment, if not both nodes are managed
This fix allows the removal of segments, where not both endpoints of the
segments are managed.
These segments can exist after deliberately disconnecting a topology by
removal of a central node, a fix to automatically remove dangling
segments is in process, but it cannot handle all situations, especially
if the removed server is no longer working and the topology is already
broken before the removal.
In these cases a manual cleanup must be possible and is addressed in
this patch
Ludwig
From 82e0e824bfb1b77329bc10ed582e75a951a6bf3c Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz lkris...@redhat.com
Date: Wed, 1 Jul 2015 11:55:13 +0200
Subject: [PATCH] allow deletion of segment if endpoint is not managed
in the preop check do not reject the deletion of a segment, if not both endpoints
are managed servers for the suffix
thisis part of work for ticlet #5072
---
daemons/ipa-slapi-plugins/topology/topology.h | 1 +
daemons/ipa-slapi-plugins/topology/topology_pre.c | 5 +
daemons/ipa-slapi-plugins/topology/topology_util.c | 11 +++
3 files changed, 17 insertions(+)
diff --git a/daemons/ipa-slapi-plugins/topology/topology.h b/daemons/ipa-slapi-plugins/topology/topology.h
index 953a5e33f2fac379a9621910a86aa8ce5a8c89b2..be9737679153ad4b2f8d07bc1622bcd6775bc8b1 100644
--- a/daemons/ipa-slapi-plugins/topology/topology.h
+++ b/daemons/ipa-slapi-plugins/topology/topology.h
@@ -283,6 +283,7 @@ void ipa_topo_util_delete_segments_for_host(char *repl_root, char *delhost);
int ipa_topo_util_entry_is_candidate(Slapi_Entry *e);
int ipa_topo_util_target_is_managed(Slapi_Entry *e);
+int ipa_topo_util_segment_is_managed(TopoReplica *tconf, TopoReplicaSegment *tsegm);
char * ipa_topo_util_get_segm_attr(TopoReplicaAgmt *agmt, char *attr_type);
void ipa_topo_util_set_segm_attr(TopoReplicaAgmt *agmt, char *attr_type,
char *attr_val);
diff --git a/daemons/ipa-slapi-plugins/topology/topology_pre.c b/daemons/ipa-slapi-plugins/topology/topology_pre.c
index 0b9f8900940eda4429bb26fe6fc8118e2a71932b..952068e7dd24d30054c0bd2aaa2efd64d2a6618f 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_pre.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_pre.c
@@ -406,6 +406,11 @@ ipa_topo_check_topology_disconnect(Slapi_PBlock *pb)
segment to be deleted does not exist\n);
goto done;
}
+if (!ipa_topo_util_segment_is_managed(tconf,tsegm)) {
+/* not both endpoints are managed servers, delete is ok */
+rc = 0;
+goto done;
+}
/* check if removal of segment would break connectivity */
fanout = ipa_topo_connection_fanout(tconf, tsegm);
if (fanout == NULL) goto done;
diff --git a/daemons/ipa-slapi-plugins/topology/topology_util.c b/daemons/ipa-slapi-plugins/topology/topology_util.c
index ea9a9c74c3bb755decadb80c82225a0047d7bdeb..523f6123c6db942860939842b64a098dd25839c9 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_util.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_util.c
@@ -1036,6 +1036,17 @@ ipa_topo_util_target_is_managed(Slapi_Entry *e)
}
+int ipa_topo_util_segment_is_managed(TopoReplica *tconf, TopoReplicaSegment *tsegm)
+{
+int ret = 0;
+
+if (ipa_topo_cfg_host_find(tconf, tsegm-from, 1)
+ipa_topo_cfg_host_find(tconf, tsegm-to, 1)) {
+ret = 1;
+}
+return ret;
+}
+
void
ipa_topo_util_segm_update (TopoReplica *tconf,
TopoReplicaSegment *tsegm,
--
2.1.0
--
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] [PATCH 0017] dirsrv crash on segment add if suffix does not exist
On 06/30/2015 04:50 PM, Ludwig Krispenz wrote: new patch attached On 06/30/2015 03:37 PM, thierry bordaz wrote: On 06/30/2015 12:07 PM, Ludwig Krispenz wrote: added verification for issue reported in ticket 5088 and sanity checks requested in review for patch 0014 Hello, The fix looks good except those sanity settings: * In ipa_topo_post_del, tsegm needs to be NULL initialized * In ipa_topo_check_segment_is_valid or ipa_topo_pre_add, I think *errtxt should be initialized to NULL thanks thierry ACK thanks thierry -- 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] [PATCH 0017] dirsrv crash on segment add if suffix does not exist
On 07/01/2015 12:11 PM, thierry bordaz wrote: On 06/30/2015 04:50 PM, Ludwig Krispenz wrote: new patch attached On 06/30/2015 03:37 PM, thierry bordaz wrote: On 06/30/2015 12:07 PM, Ludwig Krispenz wrote: added verification for issue reported in ticket 5088 and sanity checks requested in review for patch 0014 Hello, The fix looks good except those sanity settings: * In ipa_topo_post_del, tsegm needs to be NULL initialized * In ipa_topo_check_segment_is_valid or ipa_topo_pre_add, I think *errtxt should be initialized to NULL thanks thierry ACK thanks thierry Pushed to master: 5b76df4e7335c723f3fb14ef809e4d71e53509c9 -- 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] [PATCHES 0042-45] new commands for adding/removing certificates from entries
On 06/30/2015 02:45 PM, Martin Babinsky wrote: On 06/30/2015 01:11 PM, Martin Babinsky wrote: On 06/30/2015 12:04 PM, Jan Cholasta wrote: Dne 29.6.2015 v 10:36 Martin Babinsky napsal(a): On 06/23/2015 01:49 PM, Martin Babinsky wrote: This patchset implements new API commands for manipulating user/host/service userCertificate attribute alongside some underlying plumbing. PATCH 0045 is a small test suite that I slapped together since manual testing of this stuff is very cumbersome. It requires my PATCH 0040 to apply and work which was pushed to master recently (commit 74883bbc959058c8bfafd9f63e8fad0e3792ac28). The work is related to http://www.freeipa.org/page/V4/User_Certificates and https://fedorahosted.org/freeipa/ticket/4238 Attaching updated patches. Here are some notes for Jan because I did some things differently than we agreed on during review: 1.) I chose not to rename 'usercertificate' to 'usercertificate;binary' and back in pre/post callbacks. Despite the fact that the correct way to name the certificate attribute is 'usercertificate;binary', I feel that suddenly renaming it in the new code is asking for trouble. New code is new, there is no renaming, there is naming, and that naming should follow standards, and the standard is userCertificate;binary. (For the record I did not ask for any renaming in *old* host and service code.) OK I will then use 'usercertificate;binary' and try to not break things. I'm all for changing the mapping between CLI options and actual attribute names but it should be done in a systematic fashion. +1, shall I post a patch? That would be great, but I'm not sure if there is time for it. Maybe we can create a ticket for tracking? 2.) I have kept the `normalize_certs` function. It has the potential to catch incorrectly formatted/encoded certificates and in a way circumvents the slightly demented way the framework deals with supposedly binary data. One sentence above you asked for doing things in systematic fashion. This is exactly what it isn't. A systematic solution would be a new parameter type for certificates. Ha I didn't notice that incorrect encoding is caught by validator. But I think that we still need to catch malformed certificates that can not be decoded to DER and AFAIK we don't do that anywhere (failing tests when adding a random Base64-encoded string confirm this). All this probably stems from my confusion about the way IPA framework guesses binary data. For example, if I call `api.Command.user_add_cert` and fill 'certificate' option with Base64 blob reencoded to Unicode, everything works as expected. However, filling this option with 'str' leads to another round of Base64 encoding in the framework, leading to 'userCertificate;binary' which is filled by original Base64 blob instead of DER encoded cert. I have also added two negative test cases which deal with incorrectly encoded and formatted certificates. Attaching updated patches (actually only 44 is updated, I added the rename to/from 'usercertificate;binary' to user pre/post callbacks). Another patch update attached (mainly fixing pep8 complaints and reworking certificate validation). -- Martin^3 Babinsky From 5692c7759a4c9249edd59ea68745d20679d03419 Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Tue, 23 Jun 2015 13:42:45 +0200 Subject: [PATCH 4/4] test suite for user/host/service certificate management API commands These tests excercise various scenarios when using new class of API commands to add or remove certificates to user/service/host entries. Part of http://www.freeipa.org/page/V4/User_Certificates --- ipatests/test_xmlrpc/test_add_remove_cert_cmd.py | 349 +++ 1 file changed, 349 insertions(+) create mode 100644 ipatests/test_xmlrpc/test_add_remove_cert_cmd.py diff --git a/ipatests/test_xmlrpc/test_add_remove_cert_cmd.py b/ipatests/test_xmlrpc/test_add_remove_cert_cmd.py new file mode 100644 index ..c414498a29ba2ffaf0c6fb0d2a9e92a34a673b70 --- /dev/null +++ b/ipatests/test_xmlrpc/test_add_remove_cert_cmd.py @@ -0,0 +1,349 @@ +# +# Copyright (C) 2015 FreeIPA Contributors see COPYING for license +# + +import base64 + +from ipalib import api, errors + +from ipatests.util import assert_deepequal, raises +from xmlrpc_test import XMLRPC_test +from ipapython.dn import DN +from testcert import get_testcert + + +class CertManipCmdTestBase(XMLRPC_test): +entity_class = '' +entity_pkey = None +entity_subject = None +entity_principal = None +non_existent_entity = None + +profile_store_orig = True +default_profile_id = u'caIPAserviceCert' +default_caacl = u'hosts_services_%s' % default_profile_id +cmd_options = dict( +entity_add=None, +caacl=None, +) +cert_add_cmd = None +cert_del_cmd = None + +cert_add_summary = u'' +cert_del_summary = u'' + +entity_attrs = None + +@classmethod +def
[Freeipa-devel] [PATCH 0274] DNS: Check if dns package is installed
https://fedorahosted.org/freeipa/ticket/4058 Requires patch freeipa-pspacek-0052 Patch attached. -- Martin Basti From df79ebacc24299178d222f1dd83507e2ba15f479 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Wed, 1 Jul 2015 15:05:45 +0200 Subject: [PATCH] DNS: check if DNS package is installed Instead of separate checking of DNS required packages, we need just check if IPA DNS package is installed. https://fedorahosted.org/freeipa/ticket/4058 --- ipaplatform/base/paths.py | 1 + ipaplatform/base/tasks.py | 6 ++ ipaplatform/redhat/tasks.py | 5 + ipaplatform/rhel/tasks.py | 7 ++- ipaserver/install/bindinstance.py | 19 +-- ipaserver/install/dns.py| 11 ++- ipaserver/install/dnskeysyncinstance.py | 6 -- ipaserver/install/opendnssecinstance.py | 8 8 files changed, 25 insertions(+), 38 deletions(-) diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py index ab88e8f12d915af033e7117adb7f7ea2f0a32e3e..88324d85fec24786d370da69ede91ee4191c0ac5 100644 --- a/ipaplatform/base/paths.py +++ b/ipaplatform/base/paths.py @@ -149,6 +149,7 @@ class BasePathNamespace(object): ROOT_TMP_CA_P12 = /root/tmp-ca.p12 NAMED_PID = /run/named/named.pid IP = /sbin/ip +IPA_DNS_INSTALL = /sbin/ipa-dns-install NOLOGIN = /sbin/nologin SBIN_REBOOT = /sbin/reboot SBIN_RESTORECON = /sbin/restorecon diff --git a/ipaplatform/base/tasks.py b/ipaplatform/base/tasks.py index 10c5e835d0d585caa989c7744d3bae9f253de0d3..f06b81b83061bf14542c69027da148609a882d6e 100644 --- a/ipaplatform/base/tasks.py +++ b/ipaplatform/base/tasks.py @@ -218,5 +218,11 @@ class BaseTaskNamespace(object): return parse_version(version) +def get_ipa_dns_package_name(self): + +Return package name for IPA DNS + +return + task_namespace = BaseTaskNamespace() diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py index b26604aa736eb472c88bc0dcbc3a4b515712ce9d..e83b5d80ac84f9db21cb9ddcd26592436db27a9b 100644 --- a/ipaplatform/redhat/tasks.py +++ b/ipaplatform/redhat/tasks.py @@ -414,5 +414,10 @@ class RedHatTaskNamespace(BaseTaskNamespace): super(RedHatTaskNamespace, self).create_system_user(name, group, homedir, shell, uid, gid, comment) +def get_ipa_dns_package_name(self): + +Return package name for IPA DNS + +return freeipa-server-dns tasks = RedHatTaskNamespace() diff --git a/ipaplatform/rhel/tasks.py b/ipaplatform/rhel/tasks.py index 75158066521f47636299166fe939e3947eef530d..5dcbe6e325e1092e649dd6b628e60457593bafcd 100644 --- a/ipaplatform/rhel/tasks.py +++ b/ipaplatform/rhel/tasks.py @@ -25,7 +25,12 @@ from ipaplatform.redhat.tasks import RedHatTaskNamespace class RHELTaskNamespace(RedHatTaskNamespace): -pass + +def get_ipa_dns_package_name(self): + +Return package name for IPA DNS + +return ipa-server-dns tasks = RHELTaskNamespace() diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py index 77ff342d770ee1bb42521a3373df797663afd7b5..f6099afa1d43addd969ecaf788a29aed4d923a01 100644 --- a/ipaserver/install/bindinstance.py +++ b/ipaserver/install/bindinstance.py @@ -63,25 +63,8 @@ named_conf_arg_options_template_nonstr = %(indent)s%(name)s %(value)s;\n named_conf_include_re = re.compile(r'\s*include\s+(?Ppath)\s*;') named_conf_include_template = include \%(path)s\;\n + def check_inst(unattended): -has_bind = True -named = services.knownservices.named -if not os.path.exists(named.get_binary_path()): -print BIND was not found on this system -print (Please install the '%s' package and start the installation again - % named.get_package_name()) -has_bind = False - -# Also check for the LDAP BIND plug-in -if not os.path.exists(paths.BIND_LDAP_SO) and \ - not os.path.exists(paths.BIND_LDAP_SO_64): -print The BIND LDAP plug-in was not found on this system -print Please install the 'bind-dyndb-ldap' package and start the installation again -has_bind = False - -if not has_bind: -return False - if not unattended and os.path.exists(NAMED_CONF): msg = Existing BIND configuration detected, overwrite? return ipautil.user_input(msg, False) diff --git a/ipaserver/install/dns.py b/ipaserver/install/dns.py index d22bce7a7cd2e0e8a7ffe0ab4aa496634465903b..206296dddade0a0a3c8b2ed933692ae05deb7630 100644 --- a/ipaserver/install/dns.py +++ b/ipaserver/install/dns.py @@ -9,6 +9,7 @@ from subprocess import CalledProcessError from ipalib import api from ipalib import errors from ipaplatform.paths import paths +from ipaplatform.tasks import tasks from ipaplatform import services from ipapython import ipautil from ipapython import sysrestore @@ -96,6 +97,10
[Freeipa-devel] [PATCH 0054] cermonger: Use private unix socket when DBus SystemBus is not, available.
--
David Kupka
From ece6e155007e5ab1c13c4cb61977fec5c68c8e51 Mon Sep 17 00:00:00 2001
From: David Kupka dku...@redhat.com
Date: Wed, 1 Jul 2015 16:26:15 +0200
Subject: [PATCH] cermonger: Use private unix socket when DBus SystemBus is not
available.
---
ipaplatform/base/paths.py | 1 +
ipapython/certmonger.py | 125 +-
2 files changed, 91 insertions(+), 35 deletions(-)
diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index e94cb9d02a8d429a5c19a935766486d5e60c97ad..52ab156c907158d6f52ca4ffc876c01cd5ffa01e 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -346,6 +346,7 @@ class BasePathNamespace(object):
BAK2DB = '/usr/sbin/bak2db'
DB2BAK = '/usr/sbin/db2bak'
KDCPROXY_CONFIG = '/etc/ipa/kdcproxy/kdcproxy.conf'
+CERTMONGER = '/usr/sbin/certmonger'
path_namespace = BasePathNamespace
diff --git a/ipapython/certmonger.py b/ipapython/certmonger.py
index 4b85da08bb943d6b9f0091a1d2acc36b18d6..09e1ce78609f205c7e633053c1fab36d095ee07d 100644
--- a/ipapython/certmonger.py
+++ b/ipapython/certmonger.py
@@ -27,6 +27,8 @@ import sys
import time
import dbus
import shlex
+import subprocess
+import tempfile
from ipapython import ipautil
from ipapython import dogtag
from ipapython.ipa_log_manager import *
@@ -39,12 +41,11 @@ DBUS_CM_REQUEST_IF = 'org.fedorahosted.certmonger.request'
DBUS_CM_CA_IF = 'org.fedorahosted.certmonger.ca'
DBUS_PROPERTY_IF = 'org.freedesktop.DBus.Properties'
-
class _cm_dbus_object(object):
Auxiliary class for convenient DBus object handling.
-def __init__(self, bus, object_path, object_dbus_interface,
+def __init__(self, bus, parent, object_path, object_dbus_interface,
parent_dbus_interface=None, property_interface=False):
bus - DBus bus object, result of dbus.SystemBus() or dbus.SessionBus()
@@ -60,6 +61,7 @@ class _cm_dbus_object(object):
if parent_dbus_interface is None:
parent_dbus_interface = object_dbus_interface
self.bus = bus
+self.parent = parent
self.path = object_path
self.obj_dbus_if = object_dbus_interface
self.parent_dbus_if = parent_dbus_interface
@@ -74,31 +76,83 @@ def _start_certmonger():
Start certmonger daemon. If it's already running systemctl just ignores
the command.
-if not services.knownservices.certmonger.is_running():
-try:
-services.knownservices.certmonger.start()
-except Exception, e:
-root_logger.error('Failed to start certmonger: %s' % e)
-raise
-
-
-def _connect_to_certmonger():
-
-Start certmonger daemon and connect to it via DBus.
-
try:
-_start_certmonger()
-except (KeyboardInterrupt, OSError), e:
+services.knownservices.certmonger.start()
+except Exception, e:
root_logger.error('Failed to start certmonger: %s' % e)
raise
-try:
-bus = dbus.SystemBus()
-cm = _cm_dbus_object(bus, DBUS_CM_PATH, DBUS_CM_IF)
-except dbus.DBusException, e:
-root_logger.error(Failed to access certmonger over DBus: %s, e)
-raise
-return cm
+
+def _private_conn_start():
+sock_dir = tempfile.mkdtemp()
+sock_filename = os.path.join(sock_dir, 'certmonger')
+proc = subprocess.Popen([paths.CERTMONGER, '-n', '-L', '-P', sock_filename], stderr=subprocess.STDOUT)
+while not os.path.exists(sock_filename):
+time.sleep(1)
+unix_sock = unix:path=%s % sock_filename
+return (unix_sock, proc)
+
+
+def _private_conn_stop(proc, timeout=30):
+retcode = proc.poll()
+if retcode is not None:
+return
+proc.terminate()
+for i in range(0, timeout, 5):
+retcode = proc.poll()
+if retcode is not None:
+return
+time.sleep(5)
+proc.kill()
+
+
+class _certmonger(_cm_dbus_object):
+
+Create a connection to certmonger.
+By default use SystemBus. When not available use private connection
+over Unix socket.
+This solution is really ugly and should be removed as soon as DBus
+SystemBus is available at system install time.
+
+_bus = None
+_private_sock = None
+_proc = None
+
+def __del__(self):
+if self._proc:
+_private_conn_stop(self._proc)
+
+def __init__(self):
+if self._bus and self._bus.get_is_connected():
+return
+
+try:
+self._bus = dbus.SystemBus()
+except dbus.DBusException as e:
+err_name = e.get_dbus_name()
+if err_name == 'org.freedesktop.DBus.Error.ServiceUnknown':
+try:
+_start_certmonger()
+except Exception as e:
+root_logger.error(Failed to start certmonger: %s % e)
+else:
+try:
+self._bus = dbus.SystemBus()
+
Re: [Freeipa-devel] [PATCHES 448-460] Allow multiple API instances (take 2)
Dne 1.7.2015 v 14:26 Martin Babinsky napsal(a): On 07/01/2015 09:30 AM, Jan Cholasta wrote: Dne 30.6.2015 v 12:37 Martin Babinsky napsal(a): On 06/24/2015 05:21 PM, Jan Cholasta wrote: Hi, the attached patches fix https://fedorahosted.org/freeipa/ticket/3090 and https://fedorahosted.org/freeipa/ticket/5073. Honza Hi Honza, everything seems to work except `ipa-replica-prepare` which raises the following exception: http://fpaste.org/237625/43558123/ `git bisect` marks PATCH 453 as guilty. See new patch 461 for a fix. Rebased patches attached. Had to fix a snippet of code recently introduced by Fraser's patch (see attachment) to make them work. Squashed the change into patch 453. I also found 3 more occurences of the same issue in tests and fixed them. See attachment. But otherwise everything seems to be OK. ACK Thanks. Pushed to master: e43296ba9acb20342d2b6d4bb030d06deac39c2a -- Jan Cholasta From b3d581c6070f926d5299278ed59e4879a479be63 Mon Sep 17 00:00:00 2001 From: Jan Cholasta jchol...@redhat.com Date: Mon, 22 Jun 2015 10:58:43 + Subject: [PATCH 06/14] plugable: Pass API to plugins on initialization rather than using set_api https://fedorahosted.org/freeipa/ticket/3090 --- .../certmonger/dogtag-ipa-ca-renew-agent-submit| 2 +- install/restart_scripts/renew_ca_cert | 2 +- install/tools/ipa-compat-manage| 2 +- install/tools/ipa-nis-manage | 2 +- ipalib/__init__.py | 4 +- ipalib/backend.py | 4 +- ipalib/cli.py | 2 +- ipalib/frontend.py | 7 +- ipalib/plugable.py | 50 +++ ipalib/plugins/migration.py| 2 +- ipalib/plugins/misc.py | 7 +- ipalib/plugins/user.py | 4 +- ipaserver/advise/base.py | 4 +- ipaserver/install/bindinstance.py | 2 +- ipaserver/install/cainstance.py| 8 +- ipaserver/install/ipa_cacert_manage.py | 2 +- ipaserver/install/ipa_otptoken_import.py | 2 +- ipaserver/install/ipa_replica_prepare.py | 2 +- ipaserver/install/server/install.py| 3 +- ipaserver/plugins/dogtag.py| 12 +- ipaserver/plugins/ldap2.py | 45 +- ipaserver/plugins/rabase.py| 4 +- ipaserver/rpcserver.py | 36 ++--- ipatests/test_cmdline/cmdline.py | 2 +- ipatests/test_cmdline/test_ipagetkeytab.py | 2 +- ipatests/test_ipalib/test_backend.py | 21 ++- ipatests/test_ipalib/test_cli.py | 3 +- ipatests/test_ipalib/test_crud.py | 5 +- ipatests/test_ipalib/test_frontend.py | 166 ++--- ipatests/test_ipalib/test_output.py| 3 +- ipatests/test_ipalib/test_plugable.py | 26 +--- ipatests/test_ipaserver/test_ldap.py | 10 +- ipatests/test_ipaserver/test_rpcserver.py | 18 ++- ipatests/test_xmlrpc/test_baseldap_plugin.py | 15 +- ipatests/test_xmlrpc/test_dns_plugin.py| 2 +- ipatests/test_xmlrpc/test_netgroup_plugin.py | 2 +- ipatests/test_xmlrpc/test_permission_plugin.py | 2 +- ipatests/test_xmlrpc/testcert.py | 2 +- 38 files changed, 209 insertions(+), 278 deletions(-) diff --git a/install/certmonger/dogtag-ipa-ca-renew-agent-submit b/install/certmonger/dogtag-ipa-ca-renew-agent-submit index 66f3bf7..e833a31 100755 --- a/install/certmonger/dogtag-ipa-ca-renew-agent-submit +++ b/install/certmonger/dogtag-ipa-ca-renew-agent-submit @@ -58,7 +58,7 @@ OPERATION_NOT_SUPPORTED_BY_HELPER = 6 def ldap_connect(): conn = None try: -conn = ldap2(shared_instance=False, ldap_uri=api.env.ldap_uri) +conn = ldap2(api) conn.connect(ccache=os.environ['KRB5CCNAME']) yield conn finally: diff --git a/install/restart_scripts/renew_ca_cert b/install/restart_scripts/renew_ca_cert index 95205e4..86f5765 100644 --- a/install/restart_scripts/renew_ca_cert +++ b/install/restart_scripts/renew_ca_cert @@ -140,7 +140,7 @@ def _main(): conn = None try: -conn = ldap2(shared_instance=False, ldap_uri=api.env.ldap_uri) +conn = ldap2(api) conn.connect(ccache=ccache_filename) except Exception, e: syslog.syslog( diff --git a/install/tools/ipa-compat-manage b/install/tools/ipa-compat-manage index 23b528f..7d9d20c 100755 --- a/install/tools/ipa-compat-manage +++ b/install/tools/ipa-compat-manage @@ -107,7 +107,7 @@ def main(): conn = None try: try: -conn =
Re: [Freeipa-devel] [PATCH 0052] Create server-dns sub-package
On 1.7.2015 15:13, Jan Cholasta wrote: Hi, Dne 1.7.2015 v 14:12 Petr Spacek napsal(a): Hello, Create server-dns sub-package. This allows us to automatically pull in package bind-pkcs11 and thus create upgrade path for on CentOS 7.1 - 7.2. IPA previously had no requires on BIND packages and these had to be installed manually before first ipa-dns-install run. We need to pull additional bind-pkcs11 package during RPM upgrade so ipa-dns-install cannot help with this. https://fedorahosted.org/freeipa/ticket/4058 Can this be done without adding server-core? I'm not aware of such method (except of adding all DNS dependencies as Requires straight into freeipa-server package). Because it's not server core, it's the whole thing! Or maybe just rename it to server-common? I'm fine with 'common'. Ticket 4058 calls for sub-package for CA too so my idea was to create 'core' package which will be gradually reduced more and more. To me it seems that the real problem is that IPA should continue to work with plain bind after upgrade, without DNSSEC which is optional anyway, but it does not. Why not fix that instead? Because it is impossible to support and debug. Differences between bind and bind-pkcs11 are quite subtle and I'm not willing to spend my and support's time on debugging subtle bugs in someone's deployment. We do not need more newspapers to hide our packaging problems, we need to get rid of them. -- Petr^2 Spacek -- 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] [PATCH 0052] Create server-dns sub-package
Hi, Dne 1.7.2015 v 14:12 Petr Spacek napsal(a): Hello, Create server-dns sub-package. This allows us to automatically pull in package bind-pkcs11 and thus create upgrade path for on CentOS 7.1 - 7.2. IPA previously had no requires on BIND packages and these had to be installed manually before first ipa-dns-install run. We need to pull additional bind-pkcs11 package during RPM upgrade so ipa-dns-install cannot help with this. https://fedorahosted.org/freeipa/ticket/4058 Can this be done without adding server-core? Because it's not server core, it's the whole thing! Or maybe just rename it to server-common? To me it seems that the real problem is that IPA should continue to work with plain bind after upgrade, without DNSSEC which is optional anyway, but it does not. Why not fix that instead? Honza -- Jan Cholasta -- 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] [PATCHES 326-328] ID Views improvements
On Thu, 28 May 2015, Tomas Babej wrote: From c4ad3ba829ab2816c6ddb64da8d5c6ceb8789340 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 27 May 2015 16:30:48 +0200 Subject: [PATCH] idviews: Remove ID overrides for permanently removed users and groups For IPA users and groups we are able to trigger a removal of any relevant ID overrides in user-del and group-del commands. https://fedorahosted.org/freeipa/ticket/5026 ACK. -- / Alexander Bokovoy -- 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] [PATCHES 448-460] Allow multiple API instances (take 2)
On 07/01/2015 09:30 AM, Jan Cholasta wrote: Dne 30.6.2015 v 12:37 Martin Babinsky napsal(a): On 06/24/2015 05:21 PM, Jan Cholasta wrote: Hi, the attached patches fix https://fedorahosted.org/freeipa/ticket/3090 and https://fedorahosted.org/freeipa/ticket/5073. Honza Hi Honza, everything seems to work except `ipa-replica-prepare` which raises the following exception: http://fpaste.org/237625/43558123/ `git bisect` marks PATCH 453 as guilty. See new patch 461 for a fix. Rebased patches attached. Had to fix a snippet of code recently introduced by Fraser's patch (see attachment) to make them work. But otherwise everything seems to be OK. ACK -- Martin^3 Babinsky From 3e068859a8d43d1f4c1654361b3bed0a02ee1e4c Mon Sep 17 00:00:00 2001 From: Martin Babinsky mbabi...@redhat.com Date: Wed, 1 Jul 2015 14:09:41 +0200 Subject: [PATCH] fixed Fraser's LDAP call --- ipaserver/install/cainstance.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 3ee8e83ce1941a8385f162feb0b73d309f51e830..5fd3017e16e0d7ed4b4f8eead0e59266fdaff097 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -1643,7 +1643,7 @@ def ensure_ldap_profiles_container(): server_id = installutils.realm_to_serverid(api.env.realm) dogtag_uri = 'ldapi://%%2fvar%%2frun%%2fslapd-%s.socket' % server_id -conn = ldap2.ldap2(shared_instance=False, ldap_uri=dogtag_uri) +conn = ldap2.ldap2(api, ldap_uri=dogtag_uri) if not conn.isconnected(): conn.connect(autobind=True) -- 2.4.3 -- 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] [PATCHES 326-328] ID Views improvements
On Thu, 28 May 2015, Tomas Babej wrote: From 8acc50c10d9886668a0147b46f311f9aa83294bb Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 27 May 2015 14:31:13 +0200 Subject: [PATCH] idviews: Set dcerpc detection flag properly The availability of dcerpc bindings is being checked on the client side as well, hence we need to define it properly. https://fedorahosted.org/freeipa/ticket/5025 --- ipalib/plugins/idviews.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py index 57f0cce1549edb4e582df225f7831916d96c216b..a7b1e0a78e57fcd2864d258c7968393c359499f2 100644 --- a/ipalib/plugins/idviews.py +++ b/ipalib/plugins/idviews.py @@ -30,12 +30,14 @@ from ipalib.util import (normalize_sshpubkey, validate_sshpubkey, from ipapython.dn import DN +_dcerpc_bindings_installed = False + if api.env.in_server and api.env.context in ['lite', 'server']: try: import ipaserver.dcerpc _dcerpc_bindings_installed = True except ImportError: -_dcerpc_bindings_installed = False +pass __doc__ = _( ID Views -- 2.1.0 ACK -- / Alexander Bokovoy -- 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] [PATCH 0046] DNSSEC: Store time date key metadata in UTC
On 07/01/2015 10:37 AM, Martin Basti wrote: On 30/06/15 14:36, Petr Spacek wrote: Hello, DNSSEC: Store time date key metadata in UTC. OpenDNSSEC stores key metadata in local time zone but BIND needs timestamps in UTC. UTC will be stored in LDAP. https://fedorahosted.org/freeipa/ticket/4657 ACK Pushed to: master: fe6819eb9d7d9f84616daadb5f07072a3dfa02b1 ipa-4-1: 840bf5f41a532252db329cbdab0baf544f2448b2 -- 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] [PATCHES 448-460] Allow multiple API instances (take 2)
On 07/01/2015 09:30 AM, Jan Cholasta wrote: Dne 30.6.2015 v 12:37 Martin Babinsky napsal(a): On 06/24/2015 05:21 PM, Jan Cholasta wrote: Hi, the attached patches fix https://fedorahosted.org/freeipa/ticket/3090 and https://fedorahosted.org/freeipa/ticket/5073. Honza Hi Honza, everything seems to work except `ipa-replica-prepare` which raises the following exception: http://fpaste.org/237625/43558123/ `git bisect` marks PATCH 453 as guilty. See new patch 461 for a fix. Rebased patches attached. Rebased patch 253 can't be applied, see http://fpaste.org/238377/57489761/ But the original version works even with the rest of rebased patches. This is the diff between them: diff freeipa-jcholast-453.1-plugable-Pass-API-to-plugins-on-initialization-rathe.patch freeipa-jcholast-453-plugable-Pass-API-to-plugins-on-initialization-rathe.patch 1c1 From a3d2332b4d0a8348da6be804f446bfda3fc2972e Mon Sep 17 00:00:00 2001 --- From 55b1eff76dd5bfd720f8fbef77894fb6fd342b47 Mon Sep 17 00:00:00 2001 4c4 Subject: [PATCH 06/14] plugable: Pass API to plugins on initialization rather --- Subject: [PATCH 06/13] plugable: Pass API to plugins on initialization rather 227d226 -- 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
Re: [Freeipa-devel] [PATCHES 326-328] ID Views improvements
On 05/28/2015 12:59 PM, Tomas Babej wrote: Hi, this couple of patches improves ID Views and ID overrides handling. See commit messages for details. Tomas Bump. Can this sad, forgotten patch set get a review? -- 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] [PATCHES 0252-0253, 268, 50 - 51] DNSSEC: allow to move DNSSEC key master to another IPA server
On 30/06/15 22:09, Petr Spacek wrote: On 30.6.2015 16:04, Martin Basti wrote: On 30/06/15 10:25, Martin Basti wrote: On 29/06/15 15:16, Martin Basti wrote: On 25/06/15 13:46, Petr Spacek wrote: On 17.6.2015 13:37, Martin Basti wrote: On 17/06/15 13:26, Petr Spacek wrote: On 16.6.2015 15:40, Martin Basti wrote: On 05/06/15 12:54, Petr Spacek wrote: On 20.5.2015 18:00, Martin Basti wrote: This patch allows to disable DNSSEC key master on IPA server, or replace current DNSSEC key master with another IPA server. Only for master branch. https://fedorahosted.org/freeipa/ticket/4657 Patches attached. NACK. This happens on DNSSEC key master: $ ipa-dns-install --disable-dnssec-master Do you want to disable current DNSSEC key master? [no]: yes Unexpected error - see /var/log/ipaserver-install.log for details: TypeError: sequence item 0: expected string, DNSName found 2015-06-05T10:52:35Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 733, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 128, in main dns_installer.disable_dnssec_master(options.unattended) File /usr/lib/python2.7/site-packages/ipaserver/install/dns.py, line 112, in disable_dnssec_master , .join(dnssec_zones)) 2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, exception: TypeError: sequence item 0: expected string, DNSName found Updated patches attached. Due new installers, more changes were required. Sorry, NACK, I'm not able to apply this patch set to current master (69607250b9762a6c9b657dd31653b03d54a7b411). Rebased patches attached. NACK. 0) ipa-dns-install --replace-dnssec-master always puts file into /root/ipa-kasp.db. It would be better to put it into local working directory or /var/lib/ipa (as with replica files). 1) I installed DNSSEC key master role on the vm-134 but DNSSEC services were not stopped by ipactl stop: [root@vm-134 review]# ipactl stop Stopping ipa-otpd Service Stopping httpd Service Stopping ipa_memcached Service Stopping kadmin Service Stopping krb5kdc Service Stopping Directory Service ipa: INFO: The ipactl command was successful [root@vm-134 review]# ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-otpd Service Starting ipa-ods-exporter Service Starting ods-enforcerd Service Starting ipa-dnskeysyncd Service Subsequent ipactl stop worked fine, only the first one is affected. 2a) vm-134 was the original master. I ran this: [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com ... and then attempted to install master to vm-059: [root@vm-059 review]# ipa-dns-install --dnssec-master This command was accepted despite of missing --kasp-db option and wrong replica name. It should error out and tell the user to run the command with --kasp-db option. Even better, we could get rid of explicit replica name specification in --replace-dnssec-master option and allow to run installation with --kasp-db on any replica as long as the kasp.db file is provided. 2b) Attempt to move DNSSEC key master from vm-134 to vm-090 *without* specifying --kasp-db option was accepted. [root@vm-090 review]# ipa-dns-install --dnssec-master As in case (2a), it should print what user is supposed to do. I propose following text: Current DNSSEC key master vm-134.abc.idm.lab.eng.brq.redhat.com is being moved to different server. You need to copy kasp.db file from vm-134.abc.idm.lab.eng.brq.redhat.com and run following command to complete the transition: # ipa-dns-install --dnssec-master --kasp-db=/path/to/the/copied/kasp.db 3) [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com does not remove ISMASTER option from file /etc/sysconfig/ipa-dnskeysyncd . 4) [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com it is possible to run [root@vm-134 review]# ipa-dns-install --dnssec-master again without --kasp-db and it is accepted. Moreover, in this case ipaConfigString NEW_DNSSEC_MASTER is not properly removed from cn=DNSKeySync,cn=vm-090.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example. 5) Sequence of commands [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com [root@vm-090 review]# ipa-replica-manage del vm-134.abc.idm.lab.eng.brq.redhat.com allows me to run [root@vm-090 review]# ipa-dns-install --dnssec-master without --kasp-db option, it does not throw an error, and the information that some other master existed somewhere is lost. It would be probably better to replace this and to use some global attribute in cn=dns so similar problems do not happen. 6) The migration itself seems to work, KASP DB seems to work properly, however it is necessary to run
Re: [Freeipa-devel] [PATCHES 0252-0253, 268, 50 - 51] DNSSEC: allow to move DNSSEC key master to another IPA server
On 1.7.2015 12:35, Martin Basti wrote: On 30/06/15 22:09, Petr Spacek wrote: On 30.6.2015 16:04, Martin Basti wrote: On 30/06/15 10:25, Martin Basti wrote: On 29/06/15 15:16, Martin Basti wrote: On 25/06/15 13:46, Petr Spacek wrote: On 17.6.2015 13:37, Martin Basti wrote: On 17/06/15 13:26, Petr Spacek wrote: On 16.6.2015 15:40, Martin Basti wrote: On 05/06/15 12:54, Petr Spacek wrote: On 20.5.2015 18:00, Martin Basti wrote: This patch allows to disable DNSSEC key master on IPA server, or replace current DNSSEC key master with another IPA server. Only for master branch. https://fedorahosted.org/freeipa/ticket/4657 Patches attached. NACK. This happens on DNSSEC key master: $ ipa-dns-install --disable-dnssec-master Do you want to disable current DNSSEC key master? [no]: yes Unexpected error - see /var/log/ipaserver-install.log for details: TypeError: sequence item 0: expected string, DNSName found 2015-06-05T10:52:35Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 733, in run_script return_value = main_function() File /sbin/ipa-dns-install, line 128, in main dns_installer.disable_dnssec_master(options.unattended) File /usr/lib/python2.7/site-packages/ipaserver/install/dns.py, line 112, in disable_dnssec_master , .join(dnssec_zones)) 2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, exception: TypeError: sequence item 0: expected string, DNSName found Updated patches attached. Due new installers, more changes were required. Sorry, NACK, I'm not able to apply this patch set to current master (69607250b9762a6c9b657dd31653b03d54a7b411). Rebased patches attached. NACK. 0) ipa-dns-install --replace-dnssec-master always puts file into /root/ipa-kasp.db. It would be better to put it into local working directory or /var/lib/ipa (as with replica files). 1) I installed DNSSEC key master role on the vm-134 but DNSSEC services were not stopped by ipactl stop: [root@vm-134 review]# ipactl stop Stopping ipa-otpd Service Stopping httpd Service Stopping ipa_memcached Service Stopping kadmin Service Stopping krb5kdc Service Stopping Directory Service ipa: INFO: The ipactl command was successful [root@vm-134 review]# ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-otpd Service Starting ipa-ods-exporter Service Starting ods-enforcerd Service Starting ipa-dnskeysyncd Service Subsequent ipactl stop worked fine, only the first one is affected. 2a) vm-134 was the original master. I ran this: [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com ... and then attempted to install master to vm-059: [root@vm-059 review]# ipa-dns-install --dnssec-master This command was accepted despite of missing --kasp-db option and wrong replica name. It should error out and tell the user to run the command with --kasp-db option. Even better, we could get rid of explicit replica name specification in --replace-dnssec-master option and allow to run installation with --kasp-db on any replica as long as the kasp.db file is provided. 2b) Attempt to move DNSSEC key master from vm-134 to vm-090 *without* specifying --kasp-db option was accepted. [root@vm-090 review]# ipa-dns-install --dnssec-master As in case (2a), it should print what user is supposed to do. I propose following text: Current DNSSEC key master vm-134.abc.idm.lab.eng.brq.redhat.com is being moved to different server. You need to copy kasp.db file from vm-134.abc.idm.lab.eng.brq.redhat.com and run following command to complete the transition: # ipa-dns-install --dnssec-master --kasp-db=/path/to/the/copied/kasp.db 3) [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com does not remove ISMASTER option from file /etc/sysconfig/ipa-dnskeysyncd . 4) [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com it is possible to run [root@vm-134 review]# ipa-dns-install --dnssec-master again without --kasp-db and it is accepted. Moreover, in this case ipaConfigString NEW_DNSSEC_MASTER is not properly removed from cn=DNSKeySync,cn=vm-090.abc.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example. 5) Sequence of commands [root@vm-134 review]# ipa-dns-install --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com [root@vm-090 review]# ipa-replica-manage del vm-134.abc.idm.lab.eng.brq.redhat.com allows me to run [root@vm-090 review]# ipa-dns-install --dnssec-master without --kasp-db option, it does not throw an error, and the information that some other master existed somewhere is lost. It would be probably better to replace this and to use some global
Re: [Freeipa-devel] [PATCHES 326-328] ID Views improvements
On Thu, 28 May 2015, Tomas Babej wrote: From 41f158cd2b18ee7007e5b1d9ee2e1e02e37512c5 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 27 May 2015 15:06:15 +0200 Subject: [PATCH] idviews: Allow users specify the raw anchor directly as identifier For various reasons, it can happen that the users or groups that have overrides defined in a given ID view are no longer resolvable. Since user and group names are used to specify the ID override objects too by leveraging the respective user's or group's ipaUniqueID, we need to provide a fallback in case these user or group entries no longer exist. https://fedorahosted.org/freeipa/ticket/5026 ACK -- / Alexander Bokovoy -- 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] [PATCHES 326-328] ID Views improvements
On 07/01/2015 12:50 PM, Alexander Bokovoy wrote: On Thu, 28 May 2015, Tomas Babej wrote: From c4ad3ba829ab2816c6ddb64da8d5c6ceb8789340 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 27 May 2015 16:30:48 +0200 Subject: [PATCH] idviews: Remove ID overrides for permanently removed users and groups For IPA users and groups we are able to trigger a removal of any relevant ID overrides in user-del and group-del commands. https://fedorahosted.org/freeipa/ticket/5026 ACK. Pushed to master, ipa-4-1. Patch 328 required a slight rebase. -- 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] [PATCH 0052] Create server-dns sub-package
Hello,
Create server-dns sub-package.
This allows us to automatically pull in package bind-pkcs11
and thus create upgrade path for on CentOS 7.1 - 7.2.
IPA previously had no requires on BIND packages and these had to be
installed manually before first ipa-dns-install run.
We need to pull additional bind-pkcs11 package during RPM upgrade
so ipa-dns-install cannot help with this.
https://fedorahosted.org/freeipa/ticket/4058
--
Petr^2 Spacek
From 5dc874339861eadd3715b3db728756d4e38e460a Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 1 Jul 2015 14:06:37 +0200
Subject: [PATCH] Create server-dns sub-package.
This allows us to automatically pull in package bind-pkcs11
and thus create upgrade path for on CentOS 7.1 - 7.2.
IPA previously had no requires on BIND packages and these had to be
installed manually before first ipa-dns-install run.
We need to pull additional bind-pkcs11 package during RPM upgrade
so ipa-dns-install cannot help with this.
https://fedorahosted.org/freeipa/ticket/4058
---
freeipa.spec.in | 83 -
1 file changed, 59 insertions(+), 24 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 4f08db9f693318c6f4bfaf5e634ccffa78a4a28c..2287755b298f138d5e7e3d3872a28e9b307da6fb 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -111,6 +111,20 @@ logs, analysis thereof).
%package server
Summary: The IPA authentication server
Group: System Environment/Base
+Requires: %{name}-server-core = %{version}-%{release}
+Requires: %{name}-server-dns = %{version}-%{release}
+
+%description server
+IPA server metapackage. Main IPA server functionality is provided by
+ipa-server-core package. Integrated DNS server is in ipa-server-dns package.
+
+
+%package server-core
+Summary: The IPA authentication server
+Group: System Environment/Base
+# upgrade from monolithic freeipa-server to freeipa-server + freeipa-server-dns
+Conflicts: %{name}-server 4.2.0
+
Requires: %{name}-python = %{version}-%{release}
Requires: %{name}-client = %{version}-%{release}
Requires: %{name}-admintools = %{version}-%{release}
@@ -161,43 +175,57 @@ Requires: systemd-python
Requires: %{etc_systemd_dir}
Conflicts: %{alt_name}-server
-Obsoletes: %{alt_name}-server %{version}
+Conflicts: %{alt_name}-server-core
+Obsoletes: %{alt_name}-server-core %{version}
# With FreeIPA 3.3, package freeipa-server-selinux was obsoleted as the
# entire SELinux policy is stored in the system policy
Obsoletes: freeipa-server-selinux 3.3.0
-# We have a soft-requires on bind. It is an optional part of
-# IPA but if it is configured we need a way to require versions
-# that work for us.
-Conflicts: bind-dyndb-ldap 6.0-4
-%if 0%{?fedora} = 21
-Conflicts: bind 9.9.6-3
-Conflicts: bind-utils 9.9.6-3
-%else
-Conflicts: bind 9.9.4-21
-Conflicts: bind-utils 9.9.4-21
-%endif
-# DNSSEC
-Conflicts: opendnssec 1.4.6-4
-
# Versions of nss-pam-ldapd 0.8.4 require a mapping from uniqueMember to
# member.
Conflicts: nss-pam-ldapd 0.8.4
-%description server
+%description server-core
IPA is an integrated solution to provide centrally managed Identity (machine,
user, virtual machines, groups, authentication credentials), Policy
(configuration settings, access control information) and Audit (events,
logs, analysis thereof). If you are installing an IPA server you need
to install this package (in other words, most people should NOT install
this package).
+%package server-dns
+Summary: IPA integrated DNS server (BIND 9) with DNSSEC support (OpenDNSSEC)
+Group: System Environment/Base
+Requires: %{name}-server-core = %{version}-%{release}
+
+Requires: bind-dyndb-ldap = 6.0-4
+%if 0%{?fedora} = 21
+Requires: bind = 9.9.6-3
+Requires: bind-utils = 9.9.6-3
+Requires: bind-pkcs11 = 9.9.6-3
+Requires: bind-pkcs11-utils = 9.9.6-3
+%else
+Requires: bind = 9.9.4-21
+Requires: bind-utils = 9.9.4-21
+Requires: bind-pkcs11 = 9.9.4-21
+Requires: bind-pkcs11-utils = 9.9.4-21
+%endif
+# DNSSEC
+Requires: opendnssec = 1.4.6-4
+
+Obsoletes: %{alt_name}-server-dns %{version}
+
+%description server-dns
+IPA integrated DNS server with support for automatic DNSSEC signing.
+DNS server implementation is BIND 9. DNSSEC signing is provided by OpenDNSSEC.
+
+
%package server-trust-ad
Summary: Virtual package to install packages required for Active Directory trusts
Group: System Environment/Base
-Requires: %{name}-server = %version-%release
+Requires: %{name}-server-core = %version-%release
Requires: m2crypto
Requires: samba-python
Requires: samba = %{samba_version}
@@ -522,15 +550,15 @@ mkdir -p %{buildroot}%{_sysconfdir}/cron.d
rm -rf %{buildroot}
%if ! %{ONLY_CLIENT}
-%post server
+%post server-core
# NOTE: systemd specific section
/bin/systemctl --system daemon-reload 21 || :
# END
if [ $1 -gt 1 ] ; then
/bin/systemctl condrestart certmonger.service 21 || :
fi
-%posttrans server
+%posttrans server-core
# This must be run in
Re: [Freeipa-devel] [PATCH 0274] DNS: Check if dns package is installed
On 1.7.2015 15:32, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4058 Requires patch freeipa-pspacek-0052 ACK -- Petr^2 Spacek -- 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] [PATCH] 0016 user life cycle: Display the wrong attribute name when mandatory attribute is missing
From 99d65933e49360750cf18f06315e1e259dd71126 Mon Sep 17 00:00:00 2001
From: Thierry Bordaz tbor...@redhat.com
Date: Wed, 1 Jul 2015 14:46:22 +0200
Subject: [PATCH] Display the wrong attribute name when mandatory attribute is
missing
When activating a stageuser, if 'sn' or 'cn' or 'uid' is missing
it displays an error with 'cn'
---
ipalib/plugins/stageuser.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/stageuser.py b/ipalib/plugins/stageuser.py
index 7c714f627f000f7b013b60b096e72587cf935022..738c1bd8f5e8e51acb78c5e8220cbabc78942188 100644
--- a/ipalib/plugins/stageuser.py
+++ b/ipalib/plugins/stageuser.py
@@ -514,7 +514,7 @@ class stageuser_activate(LDAPQuery):
if attr not in entry:
raise errors.ValidationError(
name=self.obj.primary_key.cli_name,
-error=_('Entry has no \'cn\''),
+error=_('Entry has no \'%s\'' % attr),
)
def _build_new_entry(self, ldap, dn, entry_from, entry_to):
--
1.7.11.7
--
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] [PATCH 0275] DNS commands: do not show traceback if DNS is not installed
https://fedorahosted.org/freeipa/ticket/5017
Patch attached
--
Martin Basti
From b7ebb0661ff46306f25c5406ebaf0719e10e3834 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 1 Jul 2015 17:40:16 +0200
Subject: [PATCH] DNS: Do not traceback if DNS is not installed
Instead of internal error show 'DNS is not configured' message, when a
dns* command is executed.
https://fedorahosted.org/freeipa/ticket/5017
---
ipalib/plugins/dns.py | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index f65f8f4103547aa0a6b06de55129ef7fb47426e4..a7a4100db6de1956b8d0468e03214abc227386d5 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -2021,6 +2021,9 @@ class DNSZoneBase(LDAPObject):
)
def get_dn(self, *keys, **options):
+if not dns_container_exists(self.api.Backend.ldap2):
+raise errors.NotFound(reason=_('DNS is not configured'))
+
zone = keys[-1]
assert isinstance(zone, DNSName)
assert zone.is_absolute()
@@ -2101,8 +2104,6 @@ class DNSZoneBase_add(LDAPCreate):
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
assert isinstance(dn, DN)
-if not dns_container_exists(self.api.Backend.ldap2):
-raise errors.NotFound(reason=_('DNS is not configured'))
try:
entry = ldap.get_entry(dn)
@@ -2177,6 +2178,9 @@ class DNSZoneBase_find(LDAPSearch):
def pre_callback(self, ldap, filter, attrs_list, base_dn, scope, *args, **options):
assert isinstance(base_dn, DN)
+# Check if DNS container exists must be here for find methods
+if not dns_container_exists(self.api.Backend.ldap2):
+raise errors.NotFound(reason=_('DNS is not configured'))
filter = _create_idn_filter(self, ldap, *args, **options)
return (filter, base_dn, scope)
@@ -3087,6 +3091,9 @@ class dnsrecord(LDAPObject):
def get_dn(self, *keys, **options):
+if not dns_container_exists(self.api.Backend.ldap2):
+raise errors.NotFound(reason=_('DNS is not configured'))
+
dn = self.check_zone(keys[-2], **options)
if self.is_pkey_zone_record(*keys):
@@ -4249,6 +4256,8 @@ class dnsconfig(LDAPObject):
}
def get_dn(self, *keys, **kwargs):
+if not dns_container_exists(self.api.Backend.ldap2):
+raise errors.NotFound(reason=_('DNS is not configured'))
return DN(api.env.container_dns, api.env.basedn)
def get_dnsconfig(self, ldap):
--
2.4.3
--
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] [PATCH] 0016 user life cycle: Display the wrong attribute name when mandatory attribute is missing
Hi Thierry,
I think it would be better to use:
error=_('Entry has no \'%s\'') % attr
or even better, use named substitution:
error=_('Entry has no \'%(attribute)s\'') % dict(attribute=attr)
This way will generate a more readable strings for translators.
Tomas
--
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] [PATCH] 886-890 webui: API browser
For those of you who don't want to try the patches:
* https://pvoborni.fedorapeople.org/images/api-user-show.png
* https://pvoborni.fedorapeople.org/images/api-user-add.png
On 07/01/2015 09:35 AM, Martin Kosek wrote:
On 06/30/2015 06:35 PM, Petr Vobornik wrote:
First part of API Browser - displaying the metadata in more consumable way.
Second part, how to use it in different languages will be written as wiki pages
first.
The browser could be later enhanced with more infos and tooltips.
Patch 886 extends backend to send more metadata.
Patch 887,888,889 are webui fixes and prerequisites
Patch 890 is the API browser
Thanks, this is a very good start. I looked at a VM with the patches and have
couple usability suggestions:
1) It was hard for me to find where the API Browser is. But IPA Server looks
as a good tab where it should be though.
could be moved to Help tab when it's introduced. For that we need at
least one more link.
2) I have strong doubts about the Objects tab, this is only understandable to
users knowledgeable about FreeIPA framework internals. Common API user who just
want to consume the API and not know about the internals will not know what
this is.
What I would do is make API Browser directly clickable so that it opens the
Commands tab. This is what most people will use. Other tabs may be stacked on
the left just like with Staged or Deleted users. For now, I would hide Objects
as I think it would cause more confusion. If we want to show it, there should
be some introduction what it is good for and maybe limitation of showed fields
to only those that has any value for the consumers.
fixed, there is only API Browser and no submenu
3) In Commands tab, we will some more explanatory what the attributes of Param
needs and probably hide some. For example exclude is not needed for consumers.
Attributes as follows were kept: label, type, default, default_from,
values, minlength, maxlength, pattern, minvalue, maxvalue, precision,
cli_name, option_group
4) Many attributes have autofill: True. I wonder how usable it is without
knowing the actual default for the attribute. Can we show the default?
default_from now contains list of attrs which are used for the default
value, e.g.:
default value created from: givenname, sn
5) I would hide Output Params all together given we don't have them set up
correctly in FreeIPA framework and they may rather confuse people, with having
all the HBAC or SUDO with User objects.
Removed from metadata
I may think about it more, there were just my couple first thoughts. Others may
have different opinions here.
Martin
Other changes:
* cli options are shown with dashes as in CLI
* required and multivalued were changed into tags next to option name.
'flags' which were shown as the tags are not displayed anymore
updated patches attached.
--
Petr Vobornik
From 92cc50ebfce0aede3d823b9df5f52ea83e5aa368 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 5 Jun 2015 19:03:46 +0200
Subject: [PATCH] webui: API browser
First part of API browser - displaying metadata in more consumable way.
https://fedorahosted.org/freeipa/ticket/3129
---
install/ui/doc/categories.json | 4 +-
install/ui/less/widgets.less | 14 +
install/ui/src/freeipa/app.js | 1 +
install/ui/src/freeipa/navigation/menu_spec.js | 6 +
install/ui/src/freeipa/plugins/api_browser.js | 106 +
install/ui/src/freeipa/widgets/APIBrowserWidget.js | 383
install/ui/src/freeipa/widgets/browser_widgets.js | 503 +
7 files changed, 1016 insertions(+), 1 deletion(-)
create mode 100644 install/ui/src/freeipa/plugins/api_browser.js
create mode 100644 install/ui/src/freeipa/widgets/APIBrowserWidget.js
create mode 100644 install/ui/src/freeipa/widgets/browser_widgets.js
diff --git a/install/ui/doc/categories.json b/install/ui/doc/categories.json
index 83c24c5efa7f8e52188a30452a9b3119d831592b..3a7c2ebc2d6cdee34d48cc72f94ce845bd73d7e4 100644
--- a/install/ui/doc/categories.json
+++ b/install/ui/doc/categories.json
@@ -39,7 +39,8 @@
classes: [
facet.facet,
facets.Facet,
-*_facet
+*_facet,
+*Facet
]
},
{
@@ -254,6 +255,7 @@
stageuser,
topology,
user,
+plugins.api_browser,
plugins.load,
plugins.login,
plugins.login_process,
diff --git a/install/ui/less/widgets.less b/install/ui/less/widgets.less
index 066e074a044fc25f88ca8060c6ead2edd9d11cb0..7778f6bf46b3bbebf99fff4a7799fe4b0b090385 100644
--- a/install/ui/less/widgets.less
+++ b/install/ui/less/widgets.less
@@ -117,5 +117,19 @@
padding-left: 10px
}
+.apibrowser {
+
Re: [Freeipa-devel] topology plugin woes
On Wed, 2015-07-01 at 14:44 -0400, Simo Sorce wrote: On Wed, 2015-07-01 at 14:34 -0400, Simo Sorce wrote: I am working on the replica promotion code and suddenly the topology plugin is getting in the way. First thing I noticed is that it converted an agreement into a segment even though my domain level is 0, is this expected ? I thought we'd enable the plugin only when level - 1 By taking over immediately it will break ipa management tools from older serves which know nothing about dealing with segments, they only know about direct removal of replication agreements. The other problem is that it seem I can't remove the replication agreement even if I removed all references to the (failed) replica I installed. It complains it would cause split brain .. but this is the last replica and I already removed the master's computer object, why is the topology plugin not recognizing the master is no more and not letting me remove the segment ? Ugh, I just found the Domain Level is set to 1 ... ok so it is ok the topology is managed, but why can't I remove the segment if the server object is gone ? Simo. -- Simo Sorce * Red Hat, Inc * New York Patch 0018 fully solved this problem, next time I'll dig the uncommitted patches before opening my mouth :-) Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] topology plugin woes
On Wed, 2015-07-01 at 15:00 -0400, Simo Sorce wrote: On Wed, 2015-07-01 at 14:44 -0400, Simo Sorce wrote: On Wed, 2015-07-01 at 14:34 -0400, Simo Sorce wrote: I am working on the replica promotion code and suddenly the topology plugin is getting in the way. First thing I noticed is that it converted an agreement into a segment even though my domain level is 0, is this expected ? I thought we'd enable the plugin only when level - 1 By taking over immediately it will break ipa management tools from older serves which know nothing about dealing with segments, they only know about direct removal of replication agreements. The other problem is that it seem I can't remove the replication agreement even if I removed all references to the (failed) replica I installed. It complains it would cause split brain .. but this is the last replica and I already removed the master's computer object, why is the topology plugin not recognizing the master is no more and not letting me remove the segment ? Ugh, I just found the Domain Level is set to 1 ... ok so it is ok the topology is managed, but why can't I remove the segment if the server object is gone ? Simo. -- Simo Sorce * Red Hat, Inc * New York Patch 0018 fully solved this problem, next time I'll dig the uncommitted patches before opening my mouth :-) A followup question though, why is the toplogy plugin not seeing a new agreement (created by another replica that is being installed) until the server is restarted ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] [PATCH] 891 replication: fix regression in get_agreement_type
On 07/01/2015 06:32 PM, Petr Vobornik wrote: dcb6916a3b0601e33b08e12aeb25357efed6812b introduced a regression where get_agreement_type does not raise NotFound error if an agreement for host does not exist. The exception was swallowed by get_replication_agreement. ACK. Pushed to master: 25a5e38b85f897cc798609217830b626b7880da1 -- 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] [PATCH] 892 webui: add mangedby tab to otptoken
Added managedby_user tab to manage users who can manage the token.
https://fedorahosted.org/freeipa/ticket/5003
Nathaniel, I could not reproduce the following part of the ticket:
Careful interaction is required here. In the current code, this also
creates a bug since all UI created tokens are owned but not managed.
When users of these tokens are deleted, their self-created tokens are
orphaned rather than deleted.
Self-created tokens MUST be both self-owned AND self-managed.
The self-created tokens which I created in Web UI as admin or normal
user were in both cases managed by the same user who created them.
--
Petr Vobornik
From fda590b00652563342db29828dc71bfa6163f433 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 1 Jul 2015 18:50:47 +0200
Subject: [PATCH] webui: add mangedby tab to otptoken
Added managedby_user tab to manage users who can manage the token.
https://fedorahosted.org/freeipa/ticket/5003
---
install/ui/src/freeipa/otptoken.js | 6 ++
1 file changed, 6 insertions(+)
diff --git a/install/ui/src/freeipa/otptoken.js b/install/ui/src/freeipa/otptoken.js
index 9ba6821a59e2818b60731d1ac91c6ee298b6b713..caa7a85523d6e63db629a3a518e8611d511f7952 100644
--- a/install/ui/src/freeipa/otptoken.js
+++ b/install/ui/src/freeipa/otptoken.js
@@ -221,6 +221,12 @@ return {
]
}
]
+},
+{
+$type: 'association',
+name: 'managedby_user',
+add_method: 'add_managedby',
+remove_method: 'remove_managedby'
}
],
--
2.4.3
--
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] [PATCH] 886-890 webui: API browser
On 06/30/2015 06:35 PM, Petr Vobornik wrote: First part of API Browser - displaying the metadata in more consumable way. Second part, how to use it in different languages will be written as wiki pages first. The browser could be later enhanced with more infos and tooltips. Patch 886 extends backend to send more metadata. Patch 887,888,889 are webui fixes and prerequisites Patch 890 is the API browser Thanks, this is a very good start. I looked at a VM with the patches and have couple usability suggestions: 1) It was hard for me to find where the API Browser is. But IPA Server looks as a good tab where it should be though. 2) I have strong doubts about the Objects tab, this is only understandable to users knowledgeable about FreeIPA framework internals. Common API user who just want to consume the API and not know about the internals will not know what this is. What I would do is make API Browser directly clickable so that it opens the Commands tab. This is what most people will use. Other tabs may be stacked on the left just like with Staged or Deleted users. For now, I would hide Objects as I think it would cause more confusion. If we want to show it, there should be some introduction what it is good for and maybe limitation of showed fields to only those that has any value for the consumers. 3) In Commands tab, we will some more explanatory what the attributes of Param needs and probably hide some. For example exclude is not needed for consumers. 4) Many attributes have autofill: True. I wonder how usable it is without knowing the actual default for the attribute. Can we show the default? 5) I would hide Output Params all together given we don't have them set up correctly in FreeIPA framework and they may rather confuse people, with having all the HBAC or SUDO with User objects. I may think about it more, there were just my couple first thoughts. Others may have different opinions here. Martin -- 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] [PATCH] Password vault
Dne 25.6.2015 v 19:01 Endi Sukma Dewata napsal(a):
On 6/25/2015 12:35 AM, Jan Cholasta wrote:
I think it would be better to use a new attribute type which inherits
from ipaPublicKey (ipaVaultPublicKey?) rather than ipaPublicKey
directly
for assymetric vault public keys, so that assymetric public key and
escrow public key are on the same level and you can still use
ipaPublicKey to refer to either one:
ipaPublicKey
ipaVaultPublicKey
ipaEscrowPublicKey
OK. To be consistent the parameters need to be renamed too:
--vault-public-key and --vault-public-key-file.
It doesn't need to, there is no requirement for CLI names to always
match attribute names. (Also I don't insist on the name
ipaVaultPublicKey, feel free to change it if you want.)
It's unchanged for now. In a previous discussion it was advised to reuse
the existing attribute type whenever possible.
Well, in this discussion, it is not. Escrow public key should also reuse
ipaPublicKey, but it can't if you use it for vault public key. By using
ipaPublicKey subtypes you can distinguish between the two uses and still
use ipaPublicKey to refer to either of them.
So what's changed? This is what you said when I posted the same patch
six months ago:
In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute
types to store salt and public key for vault. Are there existing
attribute types that I can use instead? I see there's an ipaPublicKey,
should I use that and maybe add ipaSalt/ipaEncSalt? Thanks.
yes, please re-use existing attributes where possible.
Honza
What changed is that I now know there is also escrow public key, which I
didn't know six months ago.
Could you show me how to use ipaPublicKey to refer to ipaVaultPublicKey
and ipaEscrowPublicKey? Under what situation would that be useful?
For example for ipaPublicKey searches - if ipaVaultPublicKey and
ipaEscrowPublicKey both inherit from ipaPublicKey, then an ipaPublicKey
search will look in both ipaVaultPublicKey and ipaEscrowPublicKey. This
is not something we actually need right now, but once the schema is
done, it can't be fixed and I don't think we should prevent this,
especially since we can get it for free. BTW even the core LDAP schema
does this, see for example how the cn attribute inherits from the more
general name attribute: https://tools.ietf.org/html/rfc4519#section-2.3.
a) When the non-split vault_{archive,retrieve} was called from a
server API with client-only options, it crashed. This is the broken API
I was talking about.
This is because in the current framework any API called on the server
side will be a server API, so you are not supposed to call it with
client options in the first place. Because of that limitation, the only
way to use client options is to use a separate API on the client side to
call the original API on the server side. The point is, client options
belong to client API, and server options belong to server API. In
vault_add the public key file name belongs to client API because it's
used to load a file on the client side. You should not add public key
file name option to the server API just because it can safely be
ignored.
I don't disagree, but file name options do not belong to the general
client API either, as they are strictly CLI-specific.
To my understanding the current framework doesn't have a separate CLI
class, so you don't have a choice but to put CLI-specific options in the
client API class too. However, you do have a choice not to combine
client API class and server API class because otherwise that will put
CLI-specific options in the server API class too.
Right.
2. Since the vault_archive_internal inherits from Update, it
accepts
all non
primary-key attributes automatically. This is incorrect since we
don't want to
update these parameters during archival. Can this behavior be
overridden?
Inherit from PKQuery instead (don't forget to add has_output =
output.standard_entry).
Previously you didn't want to use LDAPQuery because of semantics
reasons. Is PKQuery fine semantically?
It's not. Currently there is a set of commands which operate on the
LDAP
part of vault and another set of commands which operate on the KRA part
of vault and we don't want the commands in one set to see attributes
related to the other part of vault. If you insist on keeping both parts
in a single object, you have to resort to hackery like using PKQuery,
hence my suggestion to split the data part off to a separate object to
avoid this.
This because the framework was based on simplistic assumptions which
create unnecessary restrictions, for example:
* client API is just a proxy to server API (i.e. client and server
cannot do different things)
They can do different things the same way vault_archive/vault_retrieve
does that, the commands just can't be called the same (which is not
necessarily a bad thing).
Of course different APIs can do different things, like vault_add calling
vault_archive,
[Freeipa-devel] CA ACL enforcement when authenticated as root
Hi everyone, With the addition of CA ACLs, there are now two levels of permissions checked by the `cert-request' command: - LDAP permission checks. This check is performed against the bind principal; `admin' has permission to write the userCertificate attribute of any principal. - CA ACLs: whether issuing a certificate to a particular principal using a particular profile is permitted. This check is performed against the principal for whom the certificate is being requested, which might or might not be the bind principal. Some questions came up after the recent GSS IdM test day: 1) It was requested to add a caacl rule to allow `admin' to issue a certificite for itself via any profile. This is straightforward, but what are the use cases for the `admin' account issuing certificates to itself? 2) When `admin' (as bind principal) requests a certificate for another principal and there is no CA ACL allowing issuance of a certificate for that principal+profile, the request is currently rejected. Should we change the behaviour to allow `admin' to issue a certificate to any principal, using any profile? (This would be accomplished by skipping CA ACL checks in `cert-request' when authenticated as admin.) (Note, if the answer to (2) is yes, (1) is subsumed.) Cheers, Fraser -- 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] [PATCH 0050] Fix client ca.crt to match the server's cert
On 30/06/15 17:31, Gabe Alford wrote: On Tue, Jun 30, 2015 at 8:51 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 16/06/15 16:58, Gabe Alford wrote: I know you guys are busy. Bump for review. Thanks, Gabe On Tue, May 26, 2015 at 8:16 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/3809 Thanks, Gabe I'm getting certificate on server without extra '\n' at the end. So certificate files are not the same. I assume you did a diff of the server /etc/ipa/ca.crt and the client /etc/ipa/ca.crt, right? Did you setup a server and then connect a client (just wonder what your steps were so that I can also reproduce)? Yes. I did that. I will retest it today. -- Martin Basti -- Martin Basti -- 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
