[Freeipa-devel] TypeError at ipa-server-uninstall
Hi all,
I've just caught a TypeError while performing the ipa-server-install
--uninstall on replicas running the latest ipa code (without today's
patches from Ludwig, though).
Here is the session transcript:
$ ipa-server-install --uninstall
This is a NON REVERSIBLE operation and will delete all data and
configuration!
Are you sure you want to continue with the uninstall procedure? [no]: yes
Replication agreements with the following IPA masters found:
replica3.zaeba.li,
testmaster.zaeba.li. Removing any replication agreements before
uninstalling the
server is strongly recommended. You can remove replication agreements by
running
the following command on any other IPA master:
$ ipa-replica-manage del replica1.zaeba.li
Are you sure you want to continue with the uninstall procedure? [no]: yes
Shutting down all IPA services
Removing IPA client configuration
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa_memcached
Unconfiguring ipa-otpd
Unexpected error - see /var/log/ipaserver-uninstall.log for details:
TypeError: coercing to Unicode: need string or buffer, NoneType found
The logfile is attached. This error was reproduced twice.
--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
2015-06-02T08:06:27Z DEBUG /sbin/ipa-server-install was invoked with options: {'conf_sshd': True, 'ip_addresses': [], 'setup_pkinit': True, 'domainlevel': 1, 'mkhomedir': False, 'create_sshfp': True, 'http_cert_files': None, 'conf_ntp': True, 'subject': None, 'no_forwarders': False, 'ui_redirect': True, 'external_ca_type': None, 'domain_name': None, 'idmax': 0, 'hbac_allow': False, 'http_cert_name': None, 'dirsrv_cert_files': None, 'no_dnssec_validation': False, 'ca_signing_algorithm': None, 'no_reverse': False, 'pkinit_cert_files': None, 'unattended': False, 'external_cert_files': None, 'trust_sshfp': False, 'no_host_dns': False, 'dirsrv_cert_name': None, 'realm_name': None, 'forwarders': None, 'idstart': 21760, 'external_ca': False, 'pkinit_cert_name': None, 'conf_ssh': True, 'zonemgr': None, 'ca_cert_files': None, 'setup_dns': False, 'host_name': None, 'debug': False, 'reverse_zones': [], 'uninstall': True}
2015-06-02T08:06:27Z DEBUG missing options might be asked for interactively later
2015-06-02T08:06:27Z DEBUG IPA version 4.1.99.201506010847GITe2c2d59-0.fc21
2015-06-02T08:06:27Z DEBUG Starting external process
2015-06-02T08:06:27Z DEBUG args='/usr/sbin/selinuxenabled'
2015-06-02T08:06:27Z DEBUG Process finished, return code=0
2015-06-02T08:06:27Z DEBUG stdout=
2015-06-02T08:06:27Z DEBUG stderr=
2015-06-02T08:06:27Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index'
2015-06-02T08:06:27Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
2015-06-02T08:06:27Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'...
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseuser.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/domainlevel.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py'
2015-06-02T08:06:27Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
Re: [Freeipa-devel] TypeError at ipa-server-uninstall
On Tue, Jun 02, 2015 at 10:37:43AM +0200, Oleg Fayans wrote:
Hi all,
I've just caught a TypeError while performing the ipa-server-install
--uninstall on replicas running the latest ipa code (without today's patches
from Ludwig, though).
Martin Basti's PATCH 0262 (not yet pushed) fixes this issues.
Here is the session transcript:
$ ipa-server-install --uninstall
This is a NON REVERSIBLE operation and will delete all data and
configuration!
Are you sure you want to continue with the uninstall procedure? [no]: yes
Replication agreements with the following IPA masters found:
replica3.zaeba.li,
testmaster.zaeba.li. Removing any replication agreements before uninstalling
the
server is strongly recommended. You can remove replication agreements by
running
the following command on any other IPA master:
$ ipa-replica-manage del replica1.zaeba.li
Are you sure you want to continue with the uninstall procedure? [no]: yes
Shutting down all IPA services
Removing IPA client configuration
Unconfiguring ntpd
Configuring certmonger to stop tracking system certificates for KRA
Configuring certmonger to stop tracking system certificates for CA
Unconfiguring CA
Unconfiguring named
Unconfiguring ipa-dnskeysyncd
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa_memcached
Unconfiguring ipa-otpd
Unexpected error - see /var/log/ipaserver-uninstall.log for details:
TypeError: coercing to Unicode: need string or buffer, NoneType found
The logfile is attached. This error was reproduced twice.
--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
2015-06-02T08:06:27Z DEBUG /sbin/ipa-server-install was invoked with options:
{'conf_sshd': True, 'ip_addresses': [], 'setup_pkinit': True, 'domainlevel':
1, 'mkhomedir': False, 'create_sshfp': True, 'http_cert_files': None,
'conf_ntp': True, 'subject': None, 'no_forwarders': False, 'ui_redirect':
True, 'external_ca_type': None, 'domain_name': None, 'idmax': 0,
'hbac_allow': False, 'http_cert_name': None, 'dirsrv_cert_files': None,
'no_dnssec_validation': False, 'ca_signing_algorithm': None, 'no_reverse':
False, 'pkinit_cert_files': None, 'unattended': False, 'external_cert_files':
None, 'trust_sshfp': False, 'no_host_dns': False, 'dirsrv_cert_name': None,
'realm_name': None, 'forwarders': None, 'idstart': 21760, 'external_ca':
False, 'pkinit_cert_name': None, 'conf_ssh': True, 'zonemgr': None,
'ca_cert_files': None, 'setup_dns': False, 'host_name': None, 'debug': False,
'reverse_zones': [], 'uninstall': True}
2015-06-02T08:06:27Z DEBUG missing options might be asked for interactively
later
2015-06-02T08:06:27Z DEBUG IPA version 4.1.99.201506010847GITe2c2d59-0.fc21
2015-06-02T08:06:27Z DEBUG Starting external process
2015-06-02T08:06:27Z DEBUG args='/usr/sbin/selinuxenabled'
2015-06-02T08:06:27Z DEBUG Process finished, return code=0
2015-06-02T08:06:27Z DEBUG stdout=
2015-06-02T08:06:27Z DEBUG stderr=
2015-06-02T08:06:27Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-06-02T08:06:27Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-06-02T08:06:27Z DEBUG importing all plugin modules in
'/usr/lib/python2.7/site-packages/ipalib/plugins'...
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/baseuser.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/config.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/domainlevel.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/group.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py'
2015-06-02T08:06:27Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py'
2015-06-02T08:06:27Z DEBUG importing plugin
Re: [Freeipa-devel] [PATCH 0007] replica install fails with domain level 1
Hi Ludwig, Nope, I did not remove the replica2 (this time) I just used replica3 machine because I had it by hand. I'll re-run the whole procedure today to see if it reproduces On 06/01/2015 04:52 PM, Ludwig Krispenz wrote: Hi Oleg, On 06/01/2015 04:14 PM, Petr Vobornik wrote: On 06/01/2015 01:48 PM, Ludwig Krispenz wrote: On 06/01/2015 01:34 PM, Oleg Fayans wrote: So far I've bumped into problem, using the newly built packages: I've installed a master, a replica (replica1) Then replica3 (prepared on replica1), so, my topology looks like this: master = replica1 = replica3 However, the `ipa topologysegment-find` shows correct topology only on replicas (not on master) looks like replication from replica1 to master is not/nolonger working. will look into this. With the same topology, replication works for me. I've not done anything else related to topology after the installation. Maybe some other operations caused that. could it be that you had a replica2 which you had removed ? The second problem, is that the changes (like user creation) made on any of the nodes do not get replicate to other ones. The dirsrv logs are full of GSSAPI errors like this: Seems to be caused by the first issue. = [01/Jun/2015:07:04:48 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [01/Jun/2015:07:09:46 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success) [01/Jun/2015:07:09:46 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success) [01/Jun/2015:07:09:47 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 0 (Success) = Full logs are attached I am using the 389-ds-base from mreynolds/389-ds-base dnf repo: root@testmaster:~]$ rpm -q 389-ds-base 389-ds-base-2015_03_11-1.fc21.x86_64 I used the one from mkosek/freeipa-master COPR: 389-ds-base-1.3.4.a1-20150512143653.git1bf67a4.fc17.src.rpm On 06/01/2015 11:19 AM, Oleg Fayans wrote: Woks for me too. Will perform extensive testing today, and report everything that I find. Thanks, Ludwig! On 05/29/2015 04:44 PM, Ludwig Krispenz wrote: This is a patch for the two issues reported in ticket #5035 https://fedorahosted.org/freeipa/ticket/5035 Works for me. I was able to install 2 replicas with domain level 1 in one topology. Code looks good to me as well. Tentative ACK (would be nice if it was skimmed by Thierry). -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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 0014 v3] Support multiple user and host certificates
On Mon, Jun 01, 2015 at 02:50:45PM +0200, Martin Basti wrote:
On 01/06/15 06:40, Fraser Tweedale wrote:
New version of patch; ``{host,service}-show --out=FILE`` now writes
all certs to FILE. Rebased on latest master.
Thanks,
Fraser
On Thu, May 28, 2015 at 09:18:04PM +1000, Fraser Tweedale wrote:
Updated patch attached. Notably restores/adds revocation behaviour
to host-mod and service-mod.
Thanks,
Fraser
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not cert guru :)
I personally vote for serial number in case there are multiple
certificates,
if ^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the
code.
only the --addattr='usercertificate=cert' appends new value there
--
Martin Basti
My objections/proposed solutions in attached patch.
* VERSION
* In the previous version normalized values was stored in LDAP, so I added
it back. (I dont know why there is no normalization in param settings, but
normalization for every certificate is done in callback. I will file a
ticket for this)
* IMO only normalized certificates should be compared in the old
certificates detection
I incorporated your suggested changes in new patch (attached).
There were no proposed changes to the other patchset (0001..0013)
since rebase.
Thanks,
Fraser
From a1381dcb849d24f9d77fed4cc92655075d0a5a35 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Wed, 27 May 2015 08:02:08 -0400
Subject: [PATCH] Support multiple host and service certificates
Update the framework to support multiple host and service
certificates.
host-mod and service-mod revoke existing certificates that are not
included in the modified entry. Using addattr=certificate=... will
result in no certificates being revoked.
The existing behaviour of host-disable, host-del, service-disable
and service-del (revoke existing certificate) is preserved but now
applies to all certificates in the host or service entry.
Also update host-show and service-show to write all the principal's
certificates to the file given by the ``--out=FILE`` option.
Part of: http://www.freeipa.org/page/V4/User_Certificates
---
API.txt | 10 ++---
VERSION | 4 +-
ipalib/plugins/host.py| 107 +-
ipalib/plugins/service.py | 94 +---
4 files changed, 124 insertions(+), 91 deletions(-)
diff --git a/API.txt b/API.txt
index
da69f32de5c12c0d85a7d61d9027385aa3c0ee05..3cfcf34939a58d6888de8f0a7a6ef0c7779c993e
100644
--- a/API.txt
+++ b/API.txt
@@ -1812,7 +1812,7 @@ option: Str('nsosversion', attribute=True, cli_name='os',
multivalue=False, requ
option: Flag('random', attribute=False, autofill=True, cli_name='random',
default=False, multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
option: Str('setattr*', cli_name='setattr', exclude='webui')
-option: Bytes('usercertificate', attribute=True, cli_name='certificate',
multivalue=False, required=False)
+option: Bytes('usercertificate', attribute=True, cli_name='certificate',
multivalue=True, required=False)
option: Str('userclass', attribute=True, cli_name='class', multivalue=True,
required=False)
option: Str('userpassword', attribute=True, cli_name='password',
multivalue=False, required=False)
option: Str('version?', exclude='webui')
@@ -1935,7 +1935,7 @@ option: Flag('pkey_only?', autofill=True, default=False)
option: Flag('raw', autofill=True,
Re: [Freeipa-devel] [PATCH 0262] Installer FIX: remove temporal ccache
On Mon, Jun 01, 2015 at 04:47:46PM +0200, Martin Basti wrote: On 01/06/15 16:14, Rob Crittenden wrote: Martin Basti wrote: Fixes an issue caused by the latest installer patches pushed to master. Patch attached. The use of globals makes my skin crawl a bit, but since you're making changes in here you should take a look at this ticket: https://fedorahosted.org/freeipa/ticket/5042 rob Hi Rob, this is fix for that ticket, I missed the ticket somehow. Thanks. Martin^2 -- 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 Fixes the problem for me, but I agree with Rob re globals - a context manager would be much nicer. Something like (pseudocode): @contextlib.context_manager def private_ccache(): ... stuff currently in init_private_ccache() yield ... stuff currently in destroy_private_ccache() Then in ipa-server-install main(): with private_ccache: if not options.uninstall: server.install_check(options) server.install(options) else: server.uninstall_check(options) server.uninstall(options) 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
[Freeipa-devel] [PATCH 0008-0009] use 1 as domain level to activate plugin, fix a crash when removing a replica
Hi,
with the first patch the topo plugin no longer uses plugin version to
compare to set domainlevel, always gets activated if dom level = 1
the second patch fixes a crash at replica removal
Ludwig
From 7e08b6181973cc51e50eae69974682878b8ca66b Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz lkris...@redhat.com
Date: Tue, 2 Jun 2015 09:17:54 +0200
Subject: [PATCH] plugin uses 1 as minimum domain level to become active no
calculation based on plugin version
---
daemons/ipa-slapi-plugins/topology/topology.h | 9 ++--
daemons/ipa-slapi-plugins/topology/topology_cfg.c | 25 +++---
daemons/ipa-slapi-plugins/topology/topology_init.c | 2 +-
daemons/ipa-slapi-plugins/topology/topology_util.c | 4 +---
4 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/topology/topology.h b/daemons/ipa-slapi-plugins/topology/topology.h
index 38c2823f50153c6b02a234608869617c92d1bdf2..4135a8ff71b9160919a089fde63a95a989830de8 100644
--- a/daemons/ipa-slapi-plugins/topology/topology.h
+++ b/daemons/ipa-slapi-plugins/topology/topology.h
@@ -125,11 +125,6 @@ typedef struct topo_plugin_config {
int activated;
} TopoPluginConf;
-typedef struct ipa_domain_level {
-int major;
-int minor;
-} IpaDomainLevel;
-
#define CONFIG_ATTR_SHARED_BASE nsslapd-topo-plugin-shared-config-base
#define CONFIG_ATTR_REPLICA_ROOT nsslapd-topo-plugin-shared-replica-root
#define CONFIG_ATTR_SHARED_BINDDNGROUP nsslapd-topo-plugin-shared-binddngroup
@@ -158,8 +153,8 @@ int ipa_topo_get_plugin_version_major(void);
int ipa_topo_get_plugin_version_minor(void);
char *ipa_topo_get_domain_level_entry(void);
Slapi_DN *ipa_topo_get_domain_level_entry_dn(void);
-int ipa_topo_get_domain_level_major(void);
-int ipa_topo_get_domain_level_minor(void);
+int ipa_topo_get_domain_level(void);
+int ipa_topo_get_min_domain_level(void);
int ipa_topo_get_plugin_startup_delay(void);
void ipa_topo_set_plugin_id(void *plg_id);
void ipa_topo_set_plugin_active(int state);
diff --git a/daemons/ipa-slapi-plugins/topology/topology_cfg.c b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
index 17493495af83d1095fbafead104d6f56bd7af10e..982ad647db9737c1aa0fc7f68c7d9b20de895fb6 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_cfg.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
@@ -10,7 +10,8 @@
*/
static TopoPluginConf topo_plugin_conf = {0};
static TopoReplicaConf topo_shared_conf = {0};
-static IpaDomainLevel ipa_domain_level = {0,0};
+static int ipa_domain_level = 0;
+static int topo_min_domain_level = 1;
char *ipa_topo_plugin_managed_attrs[] = {
nsds5ReplicaStripAttrs,
@@ -95,15 +96,15 @@ ipa_topo_get_domain_level_entry_dn(void)
}
int
-ipa_topo_get_domain_level_major(void)
+ipa_topo_get_min_domain_level(void)
{
-return ipa_domain_level.major;
+return topo_min_domain_level;
}
int
-ipa_topo_get_domain_level_minor(void)
+ipa_topo_get_domain_level(void)
{
-return ipa_domain_level.minor;
+return ipa_domain_level;
}
char *
@@ -199,22 +200,12 @@ ipa_topo_set_plugin_shared_bindgroup(char *bindgroup)
void
ipa_topo_set_domain_level(char *level)
{
-char *minor;
-
if (level == NULL) {
-ipa_domain_level.major = 0;
-ipa_domain_level.minor = 0;
+ipa_domain_level = 0;
return;
}
-minor = strchr(level,'.');
-if (minor) {
-*minor = '\0';
-ipa_domain_level.minor = atoi(++minor);
-} else {
-ipa_domain_level.minor = 0;
-}
-ipa_domain_level.major = atoi(level);
+ipa_domain_level = atoi(level);
}
void
diff --git a/daemons/ipa-slapi-plugins/topology/topology_init.c b/daemons/ipa-slapi-plugins/topology/topology_init.c
index 77e740ea182c2331c88d2716d1c4f7be8ef8c257..af5b8021f4ba6833dff11d9c89543e9bb74bdeb9 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_init.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_init.c
@@ -264,7 +264,7 @@ ipa_topo_rootdse_search(Slapi_PBlock *pb, Slapi_Entry* e, Slapi_Entry* entryAfte
/* we expose temporarily the domain level in this function, should
* finally be handled in a plugin managing the domain level
*/
-char *level = slapi_ch_smprintf(%d, ipa_topo_get_domain_level_major());
+char *level = slapi_ch_smprintf(%d, ipa_topo_get_domain_level());
slapi_entry_attr_set_charptr(e, ipaDomainLevel, level);
slapi_ch_free_string(version);
slapi_ch_free_string(level);
diff --git a/daemons/ipa-slapi-plugins/topology/topology_util.c b/daemons/ipa-slapi-plugins/topology/topology_util.c
index f206464a5b47b9dc7e0edd5dd764228b076b6dd9..d487cfb638ac9bd0fb94cdd2638d5fd5ae4e6908 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_util.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_util.c
@@ -110,9 +110,7 @@ ipa_topo_util_get_pluginhost(void)
void
ipa_topo_util_check_plugin_active(void)
{
-if (ipa_topo_get_plugin_version_major() ipa_topo_get_domain_level_major() ||
-
Re: [Freeipa-devel] [PATCH 0008-0009] use 1 as domain level to activate plugin, fix a crash when removing a replica
On 06/02/2015 10:12 AM, Oleg Fayans wrote: Hi Ludwig, Are you talking about this crash? I'm talking about a crash in DS which MBasti reported for ipa-replia-manage del replica 2015-06-02T08:06:57Z DEBUG stderr= 2015-06-02T08:06:57Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 733, in run_script return_value = main_function() File /sbin/ipa-server-install, line 375, in main server.uninstall(options) File /usr/lib/python2.7/site-packages/ipaserver/install/server/install.py, line 279, in decorated destroy_private_ccache() File /usr/lib/python2.7/site-packages/ipaserver/install/server/install.py, line 267, in destroy_private_ccache if os.path.exists(path): File /usr/lib64/python2.7/genericpath.py, line 18, in exists os.stat(path) 2015-06-02T08:06:57Z DEBUG The ipa-server-install command failed, exception: TypeError: coercing to Unicode: need string or buffer, NoneType found On 06/02/2015 10:04 AM, Ludwig Krispenz wrote: Hi, with the first patch the topo plugin no longer uses plugin version to compare to set domainlevel, always gets activated if dom level = 1 the second patch fixes a crash at replica removal Ludwig -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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] TypeError at ipa-server-uninstall
On 02/06/15 10:37, Oleg Fayans wrote: Hi all, I've just caught a TypeError while performing the ipa-server-install --uninstall on replicas running the latest ipa code (without today's patches from Ludwig, though). Here is the session transcript: $ ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Replication agreements with the following IPA masters found: replica3.zaeba.li, testmaster.zaeba.li. Removing any replication agreements before uninstalling the server is strongly recommended. You can remove replication agreements by running the following command on any other IPA master: $ ipa-replica-manage del replica1.zaeba.li Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Configuring certmonger to stop tracking system certificates for KRA Configuring certmonger to stop tracking system certificates for CA Unconfiguring CA Unconfiguring named Unconfiguring ipa-dnskeysyncd Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring ipa_memcached Unconfiguring ipa-otpd Unexpected error - see /var/log/ipaserver-uninstall.log for details: TypeError: coercing to Unicode: need string or buffer, NoneType found The logfile is attached. This error was reproduced twice. Patch mbasti-0262 fixes it. https://fedorahosted.org/freeipa/ticket/5042 HTH -- 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 0008-0009] use 1 as domain level to activate plugin, fix a crash when removing a replica
Hi Ludwig, Are you talking about this crash? 2015-06-02T08:06:57Z DEBUG stderr= 2015-06-02T08:06:57Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 733, in run_script return_value = main_function() File /sbin/ipa-server-install, line 375, in main server.uninstall(options) File /usr/lib/python2.7/site-packages/ipaserver/install/server/install.py, line 279, in decorated destroy_private_ccache() File /usr/lib/python2.7/site-packages/ipaserver/install/server/install.py, line 267, in destroy_private_ccache if os.path.exists(path): File /usr/lib64/python2.7/genericpath.py, line 18, in exists os.stat(path) 2015-06-02T08:06:57Z DEBUG The ipa-server-install command failed, exception: TypeError: coercing to Unicode: need string or buffer, NoneType found On 06/02/2015 10:04 AM, Ludwig Krispenz wrote: Hi, with the first patch the topo plugin no longer uses plugin version to compare to set domainlevel, always gets activated if dom level = 1 the second patch fixes a crash at replica removal Ludwig -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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] TypeError at ipa-server-uninstall
On 02/06/15 10:46, Oleg Fayans wrote: Thanks Martin! It's not merged yet, I can suggest? I think I'll apply it as it is manually then. On 06/02/2015 10:41 AM, Martin Basti wrote: On 02/06/15 10:37, Oleg Fayans wrote: Hi all, I've just caught a TypeError while performing the ipa-server-install --uninstall on replicas running the latest ipa code (without today's patches from Ludwig, though). Here is the session transcript: $ ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Replication agreements with the following IPA masters found: replica3.zaeba.li, testmaster.zaeba.li. Removing any replication agreements before uninstalling the server is strongly recommended. You can remove replication agreements by running the following command on any other IPA master: $ ipa-replica-manage del replica1.zaeba.li Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Configuring certmonger to stop tracking system certificates for KRA Configuring certmonger to stop tracking system certificates for CA Unconfiguring CA Unconfiguring named Unconfiguring ipa-dnskeysyncd Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring ipa_memcached Unconfiguring ipa-otpd Unexpected error - see /var/log/ipaserver-uninstall.log for details: TypeError: coercing to Unicode: need string or buffer, NoneType found The logfile is attached. This error was reproduced twice. Patch mbasti-0262 fixes it. https://fedorahosted.org/freeipa/ticket/5042 HTH -- Martin Basti -- Oleg Fayans Quality Engineer FreeIPA team RedHat. It is not merged, and it may change. -- 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] TypeError at ipa-server-uninstall
Thanks Martin! It's not merged yet, I can suggest? I think I'll apply it as it is manually then. On 06/02/2015 10:41 AM, Martin Basti wrote: On 02/06/15 10:37, Oleg Fayans wrote: Hi all, I've just caught a TypeError while performing the ipa-server-install --uninstall on replicas running the latest ipa code (without today's patches from Ludwig, though). Here is the session transcript: $ ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Replication agreements with the following IPA masters found: replica3.zaeba.li, testmaster.zaeba.li. Removing any replication agreements before uninstalling the server is strongly recommended. You can remove replication agreements by running the following command on any other IPA master: $ ipa-replica-manage del replica1.zaeba.li Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Configuring certmonger to stop tracking system certificates for KRA Configuring certmonger to stop tracking system certificates for CA Unconfiguring CA Unconfiguring named Unconfiguring ipa-dnskeysyncd Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring ipa_memcached Unconfiguring ipa-otpd Unexpected error - see /var/log/ipaserver-uninstall.log for details: TypeError: coercing to Unicode: need string or buffer, NoneType found The logfile is attached. This error was reproduced twice. Patch mbasti-0262 fixes it. https://fedorahosted.org/freeipa/ticket/5042 HTH -- Martin Basti -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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 0002] Abstract the HostTracker class from host plugin test
Hello,
this is the (first) patch with the Tracker class implementation based on
host plugin test.
It is meant to be used as a base class to implement a helper class to
write xml-rpc (api)
tests for LDAP based plugins and to replace the Declarative class which
is used for
most of the xml-rpc tests at the moment.
For an example usage take a look at the host plugin test.
Cheers,
Milan
From a0cba2ffaafb7cc44ccfef4f00f047df1f91cf37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= mku...@redhat.com
Date: Mon, 25 May 2015 16:05:46 +0200
Subject: [PATCH] Abstract the HostTracker class from host plugin test
Implements a base class to help test LDAP based plugins.
The class has been decoupled from the original host plugin test
and moved to separate module ipatests.test_xmlrpc.ldaptracker.
https://fedorahosted.org/freeipa/ticket/5032
---
ipatests/test_xmlrpc/ldaptracker.py | 287 +++
ipatests/test_xmlrpc/test_host_plugin.py | 155 +
2 files changed, 292 insertions(+), 150 deletions(-)
create mode 100644 ipatests/test_xmlrpc/ldaptracker.py
diff --git a/ipatests/test_xmlrpc/ldaptracker.py b/ipatests/test_xmlrpc/ldaptracker.py
new file mode 100644
index ..97412440446a0cc56e283e58fb731a31c4d9458f
--- /dev/null
+++ b/ipatests/test_xmlrpc/ldaptracker.py
@@ -0,0 +1,287 @@
+#
+# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
+#
+
+
+Implements a base class to track changes to an LDAP object.
+
+
+import functools
+
+from ipalib import api, errors
+from ipapython.dn import DN
+from ipapython.version import API_VERSION
+
+
+class Tracker(object):
+Wraps and tracks modifications to a plugin LDAP entry object
+
+Stores a copy of state of a plugin entry object and allows checking that
+the state in the database is the same as expected.
+This allows creating independent tests: the individual tests check
+that the relevant changes have been made. At the same time
+the entry doesn't need to be recreated and cleaned up for each test.
+
+Two attributes are used for tracking: ``exists`` (true if the entry is
+supposed to exist) and ``attrs`` (a dict of LDAP attributes that are
+expected to be returned from IPA commands).
+
+For commonly used operations, there is a helper method, e.g.
+``create``, ``update``, or ``find``, that does these steps:
+
+* ensure the entry exists (or does not exist, for create)
+* store the expected modifications
+* get the IPA command to run, and run it
+* check that the result matches the expected state
+
+Tests that require customization of these steps are expected to do them
+manually, using lower-level methods.
+Especially the first step (ensure the entry exists) is important for
+achieving independent tests.
+
+The Tracker object also stores information about the entry, e.g.
+``dn``, ``rdn`` and ``name`` which is derived from DN property.
+
+To use this class, the programer must subclass it and provide the
+implementation of following methods:
+
+ * make_*_command -- implementing the API call for particular plugin
+ and operation (add, delete, ...)
+ These methods should use the make_command method
+ * check_* commands -- an assertion for a plugin command (CRUD)
+ * track_create -- to make an internal representation of the
+ entry
+
+Apart from overriding these methods, the subclass must provide the
+distinguished name of the entry in `self.dn` property.
+
+It is also required to override the class variables defining the sets
+of ldap attributes/keys for these operations specific to the plugin
+being implemented. Take the host plugin test for an example.
+
+The implementation of these methods is not strictly enforced.
+A missing method will cause a NotImplementedError during runtime
+as a result.
+
+retrieve_keys = None
+retrieve_all_keys = None
+create_keys = None
+update_keys = None
+managedby_keys = None
+allowedto_keys = None
+
+_override_me_msg = This method needs to be overriden in a subclass
+
+def __init__(self, default_version=None):
+self.api = api
+self.default_version = default_version or API_VERSION
+self._dn = None
+
+self.exists = False
+
+@property
+def dn(self):
+A property containing the distinguished name of the entry.
+if not self._dn:
+raise ValueError('The DN must be set in the init method.')
+return self._dn
+
+@dn.setter
+def dn(self, value):
+if not isinstance(value, DN):
+raise ValueError('The value must be an instance of DN.')
+self._dn = value
+
+@property
+def rdn(self):
+return self.dn[0]
+
+@property
+def name(self):
+Property holding the name of
Re: [Freeipa-devel] Suggestion for the A part of IPA
Just a bit of a head's up and a refresh of this with perhaps some new data. Good to hear :-) We recently also started investigating the Audit capabilities for (notice I write for and not in) IPA. You can check my initial nudge to the freeipa-users list, which was unfortunately with no reply: https://www.redhat.com/archives/freeipa-users/2015-March/msg00940.html First up, just got round to reading this Martin. Not sure how I missed it when it first came out as it's a strong area of interest for me. The main part of what this message is about is a big change I made to our logging recently. I added in 4 of our main production IPA servers (there are 8 in total, but 4 sit beyond firewalls that take more scrutiny for changes than I wanted for now). The 4 I've added, though, serve more clients I figure. The amount of log traffic to the pair of Logstash servers has now jumped from around 50k records/hour to around 250k. Doubtless this still doesn't push any of the parts to their limits, but there has been a barely noticeably increase in CPU usage on the 2 Logstash servers. We've gone from around 2% CPU usage to 4%. Since the CPU usage on our 'loudest' IPA server rarely peaks above 10%, this doesn't present nearly as much load as I had anticipated. I have run Logstash parsers on my DEV IPA boxes, but will now investigate running them on my Prod servers too. What I'm getting at is that perhaps clients sending logs back to the IPA servers for parsing, then being sent on to a central DB for storage, isn't going to break the bank performance-wise. All of the systems in question here are 2vCPU with 4Gb vRAM running on ESXi hosts, so nothing special in the performance arena. It strikes me as a reasonably elegant solution to pair the authentication and log parsing services on the same set of servers. This would allow each client to use the same servers/failover etc for SSSD as for rsyslog. There may, of course, be other considerations, but I'm suggesting that system load isn't necessarily one of them. Much as projects such as Katello can run with everything on the same server, or split out Postgres and the like onto separate servers when there are performance considerations. Thoughts? I'm not saying they should always be paired, but that if a user designs a system with enough horse power, this piggy-backing could work well. Cheers Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com -- 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 0262] Installer FIX: remove temporal ccache
On 02/06/15 10:24, Fraser Tweedale wrote: On Mon, Jun 01, 2015 at 04:47:46PM +0200, Martin Basti wrote: On 01/06/15 16:14, Rob Crittenden wrote: Martin Basti wrote: Fixes an issue caused by the latest installer patches pushed to master. Patch attached. The use of globals makes my skin crawl a bit, but since you're making changes in here you should take a look at this ticket: https://fedorahosted.org/freeipa/ticket/5042 rob Hi Rob, this is fix for that ticket, I missed the ticket somehow. Thanks. Martin^2 -- 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 Fixes the problem for me, but I agree with Rob re globals - a context manager would be much nicer. Something like (pseudocode): @contextlib.context_manager def private_ccache(): ... stuff currently in init_private_ccache() yield ... stuff currently in destroy_private_ccache() Then in ipa-server-install main(): with private_ccache: if not options.uninstall: server.install_check(options) server.install(options) else: server.uninstall_check(options) server.uninstall(options) Cheers, Fraser Thank you! However, I would wait for Honza's answer, if this will fit in his big installer plan. -- 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] Password vault
On Tue, 2015-06-02 at 07:07 -0500, Endi Sukma Dewata wrote: On 6/2/2015 1:10 AM, Martin Kosek wrote: Hi Endi, Quickly skimming through your patches raised couple questions on my side: 1) Will it be possible to also store plain text password via Vault? It talks about taking in the binary data or the text file, but will it also work with plain user secrets (passwords)? I am talking about use like this: # ipa vault-archive name --user mkosek --data Secret123 For security the plain text password should be stored in a file first: # vi password.txt # ipa vault-archive name --user mkosek --in password.txt It's also possible to specify the password as base-64 encoded data: # echo -n Secret123 | base64 # ipa vault-archive name --user mkosek --data U2VjcmV0MTIz But it's not recommended since the data will be stored in the command history and someone could see and decode it. I think passing a plain text password as command line argument would be even worse. The --data parameter is mainly used for unit testing. Later we might be able to add an option to read from standard input: # cat password.txt | ipa vault-archive name --user mkosek --std-in Yes please, a way to pass in via stdin is extremely useful, as leaving files on the filesystem is also a big risk. 2) Didn't we discuss a dependency of IPA/Vault on python-cryptography in the past? I rather see use of python-nss for cryptography... Yes. I might have mentioned that it would be in the 2nd (current) vault patch. Actually it will be in the 3rd patch when we add the symmetric and asymmetric vaults. The symmetric and asymmetric encryption will be implemented using python-cryptography. You can also see this in an old patch (#358) but it's obsolete now. The standard vault in the current patch uses python-nss for transport encryption because when the KRA interface was written python-cryptography wasn't available on Fedora, it didn't support certificates, and I'm not sure if it supports key wrapping. It depends on the key wrapping, I have coded in python (jwcrypto) support for some key wrapping not yet available in python-cryptography and can lend you the code as needed. The symmetric and asymmetric vaults add an additional layer of encryption on top of the standard transport encryption, so it will depend on both python-nss and python-cryptography. In the future if the KRA can support python-cryptography without python-nss we may be able to drop the python-nss dependency from vaults. 3) You do a lot of actions in the forward() method (as planned in https://www.freeipa.org/page/V4/Password_Vault#Archival). But how do you envision that this is consumed by the Web UI? It does not have access to the forward() method. Would it need to also include some crypto library? If Web UI wants to access vault (not sure if everybody agrees with that), it would have to perform an encryption on the browser side. In that case we will need to use either WebCrypto or a browser-specific extension to implement something similar to vault_archive.forward(), assuming the required cryptographic functionalities are available. In the future PKI might be able to provide a JavaScript interface for KRA. I so much want to NACK crypto in web browsers ... but we may have to do it, it stinks soo much though ... Perhaps a plugin ? 4) In the vault-archive forward method, you use pki module. However, this module will be only available on FreeIPA PKI-powered servers and not on FreeIPA clients - so this will not work unless freeipa-client gets a dependency on pki-base - which is definitely not something we want... In my opinion it should be fine to require pki-base on the client NACK look at the dependency chain for that packages. because it contains just the client library, unless you have other concerns? Any objections to having pki-nss and pki-cryptography dependencies on the client? you mean python-nss/python-cryptography ? I see no problem having them as dependencies on the client. Even if we can change the client code not to depend on pki module, since in this framework the client and server code are written in the same plugin, the import pki still cannot be removed since it's still needed by the server code, and I don't think conditional import is a good programming practice. conditional import is just fine 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] Password vault
On Tue, 2015-06-02 at 12:04 +0200, Jan Cholasta wrote: Dne 2.6.2015 v 02:02 Endi Sukma Dewata napsal(a): On 5/28/2015 12:46 AM, Jan Cholasta wrote: On a related note, since KRA is optional, can we move the vaults container to cn=kra,cn=vaults? This is the convetion used by the other optional components (DNS and recently CA). I mean cn=vaults,cn=kra of course. If you are talking about the o=kra,PKI suffix, I'm not sure whether the IPA framework will work with it. If you are talking about adding a new cn=kra,IPA suffix entry on top of cn=vaults, what is the purpose of this entry? Is the entry going to be created/deleted automatically when the KRA is installed/removed? Is it going to be used for something else other than vaults? I'm talking about cn=kra,IPA suffix. It should be created only when KRA is installed, although I think this can be done later after the release, moving vaults to cn=kra should be good enough for now. It's going to be used for everything KRA-specific. There are a lot of questions that need to be answered before we can make this change. This is about sticking to a convention, which everyone should do, and everyone except KRA already does. I'm sorry I didn't realize this earlier, but the change must be done now. We probably should revisit this issue after the core vault functionality is added. We can't revisit it later because after release we are stuck with whatever is there forever. See attachment for a patch which implements the change. Shouldn't we s/kra/vault/ ? After all the feature is called Vault, not KRA. 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] 1112 Add service constraint delegation plugin
Martin Basti wrote:
On 31/05/15 04:07, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/27/2015 08:17 PM, Martin Basti wrote:
On 27/05/15 19:27, Rob Crittenden wrote:
Martin Basti wrote:
Thank you.
I haven't finished review yet, but I have few notes in case you will
modify the patch.
Please fix following issues:
3)
There are many PEP8 errors, can you fix some of them,?
Is PEP8 a concern? What kinds of errors do we fix? For example, the
current model for defining options generates a slew of indention
errors.
In old modules it's preferred to keep the old indentation style for
options(not to mix 2 styles). New modules should use following pep8
compliant style:
Str(
'cn',
cli_name='name',
primary_key=True,
label=_('Server name'),
doc=_('IPA server hostname'),
),
We try to keep PEP8 in new code, mainly indentation, blank lines, too
long lines.
Yes in test definitions and option definitions, is better to keep the
same style, but other parts of code should be PEP8.
For example these should be fixed
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225
missing whitespace around operator
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302
expected 2 blank lines, found 1
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302
expected 2 blank lines, found 1
I'll wait and see what falls out of the API review before making any
real changes.
rob
Updated API and addressed Martin's concerns. The regex must have been
a bad copy/paste, it is fixed now.
The design page has been updated as well.
rob
Hello,
comments below, in the right thread:
1)
+Str(
+'memberprincipal',
+label=_('Failed principals'),
+),
+Str(
+'ipaallowedtarget',
+label=_('Failed targets'),
+),
+Str(
+'servicedelegationrule',
+label=_('principal member'),
+),
Are these names correct?
# ipa servicedelegationrule-find
--
1 service delegation rule matched
--
Delegation name: ipa-http-delegation
Allowed Target: ipa-ldap-delegation-targets,
ipa-cifs-delegation-targets
Failed principals: HTTP/vm-093.example@example.com
Fixed.
2)
+ pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, ., '
+ 'and a space inside',
This regex does not allow space inside
In [6]: print re.match(pattern, 'lalalala lalala')
None
Fixed. I'm tempted to just drop this regex entirely. Other plugins have
no such restrictions, but this should work better now.
3)
+yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
+ label=_('member %s') % name,
+ csv=True, alwaysask=True)
IMHO CSV values should not be supported.
Honza told me, the option doesn't work anyway.
Yeah, a copy and paste issue.
Patch with minor fixes attached.
I removed unused code and PEP8 complains
Incorporated and fixed a number of other things, including some typos in
the doc examples.
rob
From 8458d605dcbe30191dda561d60d0145b44a65cfb Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Thu, 14 May 2015 13:08:58 +
Subject: [PATCH] Add plugin to manage service constraint delegations
Service Constraints are the delegation model used by
ipa-kdb to grant service A to obtain a TGT for a user
against service B.
https://fedorahosted.org/freeipa/ticket/3644
---
ACI.txt| 16 +
API.txt| 153 ++
VERSION| 4 +-
install/updates/20-indices.update | 9 +
install/updates/25-referint.update | 1 +
ipalib/plugins/servicedelegation.py| 537 +++
ipatests/test_xmlrpc/objectclasses.py | 11 +
.../test_xmlrpc/test_servicedelegation_plugin.py | 591 +
8 files changed, 1320 insertions(+), 2 deletions(-)
create mode 100644 ipalib/plugins/servicedelegation.py
create mode 100644 ipatests/test_xmlrpc/test_servicedelegation_plugin.py
diff --git a/ACI.txt b/ACI.txt
index 3c4ebde..1821696 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -212,6 +212,22 @@ dn: cn=services,cn=accounts,dc=ipa,dc=example
aci: (targetattr = createtimestamp || entryusn || ipakrbauthzdata || ipakrbprincipalalias || ipauniqueid || krbcanonicalname || krblastpwdchange || krbobjectreferences || krbpasswordexpiration || krbprincipalaliases || krbprincipalexpiration || krbprincipalname || managedby || memberof || modifytimestamp || objectclass || usercertificate)(targetfilter = (objectclass=ipaservice))(version 3.0;acl permission:System: Read Services;allow (compare,read,search) userdn = ldap:///all;;)
dn:
Re: [Freeipa-devel] [PATCH 0001] Migrate now accepts scope as argument
Sorry, the email address on that patch is wrong. It picked the old one off my personal box when I migrated my dotfiles. I don't know if that's important, but if the merger could s/dpe...@crimson.ua.edu/de...@redhat.com/g, that would be better. Sorry about that, I'll fix it in my next patch. On 06/02/2015 04:23 PM, Drew Erny wrote: Hi, all, This is my first patch, which fixes Ticket #2547 at https://fedorahosted.org/freeipa/ticket/2547 It introduces a --scope option to ipa migrate-ds which allows the user to specify the search depth of a migration. The previous default behavior is the same as --scope=onelevel. To search nested OUs, the user uses --scope=subtree. --scope=base will cause the migrate script not to find anything, but has been included for completeness. Any other option is invalid and will cause the command to abort. Please review this one carefully, because I'm only like 98% confident it doesn't break anything. The only thing I'm not sure about is that if you run ipa migrate-ds without --scope specified, it gives an interactive input for that option; I'm not sure if it's supposed to do that. Thanks, Drew Erny de...@redhat.com -- 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
Please take a look at the new patch.
On 6/2/2015 10:05 AM, Martin Kosek wrote:
4) In the vault-archive forward method, you use pki module. However,
this module will be only available on FreeIPA PKI-powered servers and
not on FreeIPA clients - so this will not work unless freeipa-client
gets a dependency on pki-base - which is definitely not something we
want...
In my opinion it should be fine to require pki-base on the client because it
contains just the client library, unless you have other concerns? Any
objections to having pki-nss and pki-cryptography dependencies on the client?
Even if we can change the client code not to depend on pki module, since in
this framework the client and server code are written in the same plugin, the
import pki still cannot be removed since it's still needed by the server
code, and I don't think conditional import is a good programming practice.
I have major concerns here. Look at the different between installing
freeipa-client and freeipa-client + pki-base on my F21:
~~
$ sudo yum install freeipa-client
...
Install 1 Package (+4 Dependent packages)
Total download size: 2.6 M
Installed size: 14 M
~~
$ sudo yum install freeipa-client pki-base
...
Install 2 Packages (+288 Dependent packages)
Total download size: 160 M
Installed size: 235 M
~~
This is obviously a no-go for client. The conditional import is smaller concern
that big dependency growth on the client. We do them in trust plugin for
example and it works fine (though I agree it is not ideal programming practice).
IMO, we should limit new freeipa-client dependencies only to
python-cryptography (or also python-nss in the worst case, in case
python-cryptography is not enough) - there should be no pki dependencies at
all, these should be only on the server side.
OK. I opened a ticket to split the pki-base into separate Python and
Java packages:
https://fedorahosted.org/pki/ticket/1399
For now in this patch I added conditional imports for pki.account and
pki.key which are needed to access KRA on the server side. I removed
dependency on pki.crypto on the client side and replaced it with direct
python-nss code.
On 6/2/2015 1:40 PM, Simo Sorce wrote:
I have coded in python (jwcrypto)
support for some key wrapping not yet available in python-cryptography
and can lend you the code as needed.
Thanks. I'll get back to you when it's time to add support for
python-cryptography in KRA:
https://fedorahosted.org/pki/ticket/1400
On 6/2/2015 10:16 AM, Alexander Bokovoy wrote:
Yes, please use conditional import here, it is perfectly valid use case
for the client side.
On 6/2/2015 1:40 PM, Simo Sorce wrote:
conditional import is just fine
The conditional imports that I've seen usually are used for importing
different versions of the same module, which I think is acceptable
because the dependency always exists. In the vault case we're
selectively importing a module depending on where the code runs. I think
that is bad because it adds complexity and it's easy to make mistakes.
Any code that depends on that module would have to be (a) guarded:
if pki_is_loaded:
... call pki ...
or (b) used in a method that's only called if the module is loaded:
def do_something(self): # runs only on server
... call pki ...
The (a) is similar to #ifdef's which should be avoidable using OOD, and
in (b) we may inadvertently call a wrong method indirectly. I think
ideally the client and server code should be in separate files (so they
can be deployed separately too), but the framework doesn't seem to allow
that.
Regardless, the conditional imports are in.
--
Endi S. Dewata
From 0e9d3868423c21dc47d125f4b3c23e8261c4655f Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Tue, 21 Oct 2014 10:57:08 -0400
Subject: [PATCH] Added vault-archive and vault-retrieve commands.
New commands have been added to archive and retrieve
data into and from a vault, also to retrieve the
transport certificate.
https://fedorahosted.org/freeipa/ticket/3872
---
API.txt | 28 ++
VERSION | 4 +-
ipalib/plugins/vault.py | 517 +-
ipatests/test_xmlrpc/test_vault_plugin.py | 71 +++-
4 files changed, 616 insertions(+), 4 deletions(-)
diff --git a/API.txt b/API.txt
index
da69f32de5c12c0d85a7d61d9027385aa3c0ee05..3741e6f16689e43838c2d31a44872d1ea47589c7
100644
--- a/API.txt
+++ b/API.txt
@@ -4768,6 +4768,24 @@ option: Str('version?', exclude='webui')
output: Entry('result', type 'dict', Gettext('A dictionary representing an
LDAP entry', domain='ipa', localedir=None))
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
+command: vault_archive
+args: 1,9,1
+arg: Str('cn', cli_name='name',
[Freeipa-devel] [PATCH 0001] Migrate now accepts scope as argument
Hi, all,
This is my first patch, which fixes Ticket #2547 at
https://fedorahosted.org/freeipa/ticket/2547
It introduces a --scope option to ipa migrate-ds which allows the user
to specify the search depth of a migration. The previous default
behavior is the same as --scope=onelevel. To search nested OUs, the user
uses --scope=subtree. --scope=base will cause the migrate script not to
find anything, but has been included for completeness. Any other option
is invalid and will cause the command to abort.
Please review this one carefully, because I'm only like 98% confident it
doesn't break anything. The only thing I'm not sure about is that if you
run ipa migrate-ds without --scope specified, it gives an interactive
input for that option; I'm not sure if it's supposed to do that.
Thanks,
Drew Erny
de...@redhat.com
From b50522be44ade6af8ddd24f33eac100af67bc101 Mon Sep 17 00:00:00 2001
From: Drew Erny dpe...@crimson.ua.edu
Date: Wed, 27 May 2015 09:52:42 -0400
Subject: [PATCH] Migration now accepts scope as argument
Adds a new option to command ipa migrate-ds,
--scope=[base,onelevel,subtree], which allows the user to specify LDAP
search depth for users and groups. 'onelevel' was the previous default
level. Specify 'subtree' to to search nested OUs for users and groups.
fedorahosted.org/freeipa/ticket/2547
---
API.txt | 3 ++-
ipalib/plugins/migration.py | 18 +-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/API.txt b/API.txt
index d987bc949948a280018f0f20d5af93838ecaeb20..f8f0bb1955b21385d85e59d7683698a30ca37181 100644
--- a/API.txt
+++ b/API.txt
@@ -2450,7 +2450,7 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: migrate_ds
-args: 2,18,4
+args: 2,19,4
arg: Str('ldapuri', cli_name='ldap_uri')
arg: Password('bindpw', cli_name='password', confirm=False)
option: DNParam('basedn?', cli_name='base_dn')
@@ -2466,6 +2466,7 @@ option: Str('groupignoreobjectclass*', autofill=True, cli_name='group_ignore_obj
option: Str('groupobjectclass+', autofill=True, cli_name='group_objectclass', csv=True, default=(u'groupOfUniqueNames', u'groupOfNames'))
option: Flag('groupoverwritegid', autofill=True, cli_name='group_overwrite_gid', default=False)
option: StrEnum('schema?', autofill=True, cli_name='schema', default=u'RFC2307bis', values=(u'RFC2307bis', u'RFC2307'))
+option: StrEnum('scope', cli_name='scope', default=u'onelevel', values=(u'base', u'onelevel', u'subtree'))
option: DNParam('usercontainer', autofill=True, cli_name='user_container', default=ipapython.dn.DN('ou=people'))
option: Str('userignoreattribute*', autofill=True, cli_name='user_ignore_attribute', csv=True, default=())
option: Str('userignoreobjectclass*', autofill=True, cli_name='user_ignore_objectclass', csv=True, default=())
diff --git a/ipalib/plugins/migration.py b/ipalib/plugins/migration.py
index c8379420d539ac35901d99f981b4c8e2f0f89ffc..da23d287afd9e21cb2e5f3edec9abfa9b98f0af4 100644
--- a/ipalib/plugins/migration.py
+++ b/ipalib/plugins/migration.py
@@ -139,6 +139,7 @@ _ref_err_msg = _('Migration of LDAP search reference is not supported.')
_dn_err_msg = _('Malformed DN')
_supported_schemas = (u'RFC2307bis', u'RFC2307')
+_supported_scopes = (u'base', u'onelevel', u'subtree')
def _pre_migrate_user(ldap, pkey, dn, entry_attrs, failed, config, ctx, **kwargs):
@@ -607,6 +608,14 @@ class migrate_ds(Command):
doc=_('Load CA certificate of LDAP server from FILE'),
default=None
),
+StrEnum('scope',
+cli_name='scope',
+label=_('Search scope'),
+doc=_('LDAP search scope for users and groups: base, onelevel, or '\
+ 'subtree. Defaults to onelevel'),
+values=_supported_scopes,
+default=_supported_scopes[1],
+),
)
has_output = (
@@ -711,13 +720,20 @@ can use their Kerberos accounts.''')
exclude = options['exclude_%ss' % to_cli(ldap_obj_name)]
context = dict(ds_ldap = ds_ldap)
+if options.get('scope') == 'base':
+scope = ds_ldap.SCOPE_BASE
+elif options.get('scope') == 'subtree':
+scope = ds_ldap.SCOPE_SUBTREE
+else:
+scope = ds_ldap.SCOPE_ONELEVEL
+
migrated[ldap_obj_name] = []
failed[ldap_obj_name] = {}
try:
entries, truncated = ds_ldap.find_entries(
search_filter, ['*'], search_bases[ldap_obj_name],
-ds_ldap.SCOPE_ONELEVEL,
+scope,
time_limit=0, size_limit=-1,
search_refs=True# migrated DS may contain search references
)
--
2.4.2
--
Manage your subscription for the Freeipa-devel mailing list:
Re: [Freeipa-devel] [PATCH] Password vault
On Tue, 02 Jun 2015, Endi Sukma Dewata wrote: Please take a look at the new patch. On 6/2/2015 10:05 AM, Martin Kosek wrote: 4) In the vault-archive forward method, you use pki module. However, this module will be only available on FreeIPA PKI-powered servers and not on FreeIPA clients - so this will not work unless freeipa-client gets a dependency on pki-base - which is definitely not something we want... In my opinion it should be fine to require pki-base on the client because it contains just the client library, unless you have other concerns? Any objections to having pki-nss and pki-cryptography dependencies on the client? Even if we can change the client code not to depend on pki module, since in this framework the client and server code are written in the same plugin, the import pki still cannot be removed since it's still needed by the server code, and I don't think conditional import is a good programming practice. I have major concerns here. Look at the different between installing freeipa-client and freeipa-client + pki-base on my F21: ~~ $ sudo yum install freeipa-client ... Install 1 Package (+4 Dependent packages) Total download size: 2.6 M Installed size: 14 M ~~ $ sudo yum install freeipa-client pki-base ... Install 2 Packages (+288 Dependent packages) Total download size: 160 M Installed size: 235 M ~~ This is obviously a no-go for client. The conditional import is smaller concern that big dependency growth on the client. We do them in trust plugin for example and it works fine (though I agree it is not ideal programming practice). IMO, we should limit new freeipa-client dependencies only to python-cryptography (or also python-nss in the worst case, in case python-cryptography is not enough) - there should be no pki dependencies at all, these should be only on the server side. OK. I opened a ticket to split the pki-base into separate Python and Java packages: https://fedorahosted.org/pki/ticket/1399 For now in this patch I added conditional imports for pki.account and pki.key which are needed to access KRA on the server side. I removed dependency on pki.crypto on the client side and replaced it with direct python-nss code. On 6/2/2015 1:40 PM, Simo Sorce wrote: I have coded in python (jwcrypto) support for some key wrapping not yet available in python-cryptography and can lend you the code as needed. Thanks. I'll get back to you when it's time to add support for python-cryptography in KRA: https://fedorahosted.org/pki/ticket/1400 On 6/2/2015 10:16 AM, Alexander Bokovoy wrote: Yes, please use conditional import here, it is perfectly valid use case for the client side. On 6/2/2015 1:40 PM, Simo Sorce wrote: conditional import is just fine The conditional imports that I've seen usually are used for importing different versions of the same module, which I think is acceptable because the dependency always exists. In the vault case we're selectively importing a module depending on where the code runs. I think that is bad because it adds complexity and it's easy to make mistakes. Any code that depends on that module would have to be (a) guarded: if pki_is_loaded: ... call pki ... or (b) used in a method that's only called if the module is loaded: def do_something(self): # runs only on server ... call pki ... The (a) is similar to #ifdef's which should be avoidable using OOD, and in (b) we may inadvertently call a wrong method indirectly. I think ideally the client and server code should be in separate files (so they can be deployed separately too), but the framework doesn't seem to allow that. This exactly the case we have to use here and we are using that in trusts case as well -- some code has to run on server only and shouldn't cause to install Samba related packages on the client. This is because IPA client is actually using the same IPA plugins that server uses, to have access to the API calls metadata and client-side callbacks are defined in the same place where server-side callbacks are. It is IPA framework design, so we have to use what we have. In other words, it is not necessarily an evil under conditions we are dealing with. -- / 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] Use Exception class instead of BaseException
Niranjan wrote: Greetings, I would like to present patch for replacing StandardError exception with Exception class in ipapython/adminutil.py. Also replacing BaseException class with Exception class. Though the use of StandardError is many places. I would like to start with ipapython/adminutil.py This is my first patch. Please let me know if my approach on this is correct. Could anyone have a look at this please. Regards Niranjan From 018312f76952ea86c8c6e2396657e0531d2d61ba Mon Sep 17 00:00:00 2001 From: Niranjan Mallapadi mrniran...@redhat.com Date: Mon, 1 Jun 2015 09:41:05 +0530 Subject: [PATCH] Use Exception class instead of BaseException 1. Replace BaseException with Exception class. 2. Remove StandardError and use Exception class. StandError is deprecated (Python3) 3 .From python3.0 use of , is not recommended, instead use as keyword (PEP 3110) Signed-off-by: Niranjan Mallapadi mrniran...@redhat.com --- ipapython/admintool.py | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/ipapython/admintool.py b/ipapython/admintool.py index d55bd18499ac427db8adc0c04096bc2aabdc2bbd..891232b9f387182ac5dbfb279a6f666805261ba1 100644 --- a/ipapython/admintool.py +++ b/ipapython/admintool.py @@ -32,7 +32,7 @@ from ipapython import config from ipapython import ipa_log_manager -class ScriptError(StandardError): +class ScriptError(Exception): An exception that records an error message and a return value def __init__(self, msg='', rval=1): @@ -169,13 +169,20 @@ class AdminTool(object): self.ask_for_options() self.setup_logging() return_value = self.run() -except BaseException, exception: +except Exception as exception: traceback = sys.exc_info()[2] error_message, return_value = self.handle_error(exception) if return_value: self.log_failure(error_message, return_value, exception, traceback) return return_value +except SystemExit as exception: +traceback = sys.exc_info()[2] +error_message, return_value = self.handle_error(exception) +if return_value: +self.log_failure(error_message, return_value, exception, +traceback) +return return_value self.log_success() return return_value -- 1.9.3 Removed an attachment of 322 bytes with the following headers: Content-Type: application/pgp-signature -- 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 pgpQ5Eb09aF5m.pgp Description: PGP signature -- 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] KeyError raised upon replica installation
Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]: importing CA chain to RA certificate database [11/21]: fixing RA database permissions [12/21]: setting up signing cert profile [13/21]: set certificate subject base [14/21]: enabling Subject Key Identifier [15/21]: enabling Subject Alternative Name [16/21]: enabling CRL and OCSP extensions for certificates [17/21]: setting audit signing renewal to 2 years [18/21]: configure certmonger for renewals [19/21]: configure certificate renewals [20/21]: configure Server-Cert certificate renewal [21/21]: Configure HTTP to proxy connections Done configuring certificate server (pki-tomcatd). Restarting the directory and certificate servers Configuring Kerberos KDC (krb5kdc):
Re: [Freeipa-devel] [PATCH 0377-0382] Synchronize changes from LDAP after reconnect
On 05/28/2015 05:58 PM, Matus Honek wrote: Hi, functionality seems to work fine. I have not checked the code thoroughly. Kind of a test is attached (requires setting named's ldap connection appropriately). ACK Matúš Honěk - Original Message - From: Petr Spacek pspa...@redhat.com To: tho...@redhat.com, Matus Honek mho...@redhat.com Cc: freeipa-devel@redhat.com Sent: Wednesday, May 27, 2015 2:50:52 PM Subject: [PATCH 0377-0382] Synchronize changes from LDAP after reconnect Hello, https://fedorahosted.org/bind-dyndb-ldap/ticket/128 Previously records deleted when connection to LDAP server was down were not synchronized properly. It should work now. I use this command to simulate broken connections and connection re-establishment: $ socat tcp-listen:3899,reuseaddr,fork tcp-connect:localhost:389 It should be enough to add ldap://$(hostname):3899 as LDAP URI to /etc/named.conf and then simulate changes by killing and restarting socat. Let me know if you need any assistance! Hi. I did a formal review of the code. Everything looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com -- 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 0010] KeyError raised upon replica installation
On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg the topology plugin needs a replica binddngroup to be able to setup agrements without having to modify cn=config. If the replica is installed from an older version, this group doesn't exist and adding members to it fails. The attached patch should handle this Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]: importing CA chain to RA certificate database [11/21]: fixing RA database permissions [12/21]: setting up signing cert profile [13/21]: set certificate subject base [14/21]: enabling Subject Key Identifier [15/21]: enabling Subject Alternative Name [16/21]: enabling CRL and OCSP extensions for certificates [17/21]: setting audit signing renewal to 2 years [18/21]:
Re: [Freeipa-devel] [PATCH 0329] ipa-replica-manage: Do not allow topology altering commands
On 06/02/2015 02:10 PM, Tomas Babej wrote: Hi, With Domain Level 1 and above, the usage of ipa-replica-manage commands that alter the replica topology is deprecated. Following commands are prohibited: * connect * disconnect * del Upon executing any of these commands, users are pointed out to the ipa topologysegment-* replacements. Part of: https://fedorahosted.org/freeipa/ticket/4302 Works for me, 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
[Freeipa-devel] [PATCH 0329] ipa-replica-manage: Do not allow topology altering commands
Hi,
With Domain Level 1 and above, the usage of ipa-replica-manage commands
that alter the replica topology is deprecated. Following commands
are prohibited:
* connect
* disconnect
* del
Upon executing any of these commands, users are pointed out to the
ipa topologysegment-* replacements.
Part of: https://fedorahosted.org/freeipa/ticket/4302
From e96c3b045ced1773def444ffee9a45f813abb954 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 2 Jun 2015 14:06:26 +0200
Subject: [PATCH] ipa-replica-manage: Do not allow topology altering commands
from DL 1
With Domain Level 1 and above, the usage of ipa-replica-manage commands
that alter the replica topology is deprecated. Following commands
are prohibited:
* connect
* disconnect
* del
Upon executing any of these commands, users are pointed out to the
ipa topologysegment-* replacements.
Part of: https://fedorahosted.org/freeipa/ticket/4302
---
install/tools/ipa-replica-manage | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 0d2688e6d73b1591c5e386656b7198c20d71558a..a27360c002433e5f1b8133b98055cb757468ad0a 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -747,12 +747,6 @@ def del_master(realm, hostname, options):
try:
if bindinstance.dns_container_exists(options.host, thisrepl.suffix,
dm_password=options.dirman_passwd):
-if options.dirman_passwd:
-api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
- bind_pw=options.dirman_passwd)
-else:
-ccache = krbV.default_context().default_ccache()
-api.Backend.ldap2.connect(ccache=ccache)
bind = bindinstance.BindInstance()
bind.remove_master_dns_records(hostname, realm, realm.lower())
bind.remove_ipa_ca_dns_records(hostname, realm.lower())
@@ -1209,6 +1203,22 @@ def main():
options.dirman_passwd = dirman_passwd
+# Initialize the LDAP connection
+if options.dirman_passwd:
+api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
+ bind_pw=options.dirman_passwd)
+else:
+ccache = krbV.default_context().default_ccache()
+api.Backend.ldap2.connect(ccache=ccache)
+
+# Check the domain level
+if args[0] in (connect, disconnect, del):
+domainlevel = api.Command['domainlevel_get']().get('result', 0)
+if domainlevel 0:
+sys.exit(The {0} command is deprecated with domain level 1.
+ Please use ipa topologysegment-* commands to manage
+ IPA replication topology..format(args[0]))
+
if args[0] == list:
replica = None
if len(args) == 2:
--
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] KeyError raised upon replica installation
On 06/02/2015 02:07 PM, Martin Babinsky wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]: importing CA chain to RA certificate database [11/21]: fixing RA database permissions [12/21]: setting up signing cert profile [13/21]: set certificate subject base [14/21]: enabling Subject Key Identifier [15/21]: enabling Subject Alternative Name [16/21]: enabling CRL and OCSP extensions for certificates [17/21]: setting audit signing renewal to 2 years [18/21]: configure certmonger for renewals [19/21]: configure certificate renewals [20/21]: configure Server-Cert certificate renewal [21/21]: Configure
Re: [Freeipa-devel] [PATCH] Password vault
On 06/02/2015 12:04 PM, Jan Cholasta wrote: Dne 2.6.2015 v 02:02 Endi Sukma Dewata napsal(a): On 5/28/2015 12:46 AM, Jan Cholasta wrote: On a related note, since KRA is optional, can we move the vaults container to cn=kra,cn=vaults? This is the convetion used by the other optional components (DNS and recently CA). I mean cn=vaults,cn=kra of course. If you are talking about the o=kra,PKI suffix, I'm not sure whether the IPA framework will work with it. If you are talking about adding a new cn=kra,IPA suffix entry on top of cn=vaults, what is the purpose of this entry? Is the entry going to be created/deleted automatically when the KRA is installed/removed? Is it going to be used for something else other than vaults? I'm talking about cn=kra,IPA suffix. It should be created only when KRA is installed, although I think this can be done later after the release, moving vaults to cn=kra should be good enough for now. It's going to be used for everything KRA-specific. There are a lot of questions that need to be answered before we can make this change. This is about sticking to a convention, which everyone should do, and everyone except KRA already does. I'm sorry I didn't realize this earlier, but the change must be done now. +1 for this change. I do not even think it will that big deal, it is just about the default space in the IPA tree - to have proper structure in it (DNS has cn=dns, KRA has cn=kra, etc.). We probably should revisit this issue after the core vault functionality is added. We can't revisit it later because after release we are stuck with whatever is there forever. Right. -- 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] KeyError raised upon replica installation
On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]: importing CA chain to RA certificate database [11/21]: fixing RA database permissions [12/21]: setting up signing cert profile [13/21]: set certificate subject base [14/21]: enabling Subject Key Identifier [15/21]: enabling Subject Alternative Name [16/21]: enabling CRL and OCSP extensions for certificates [17/21]: setting audit signing renewal to 2 years [18/21]: configure certmonger for renewals [19/21]: configure certificate renewals [20/21]: configure Server-Cert certificate renewal [21/21]: Configure HTTP to proxy connections Done configuring
Re: [Freeipa-devel] [PATCH] Password vault
On 6/2/2015 1:10 AM, Martin Kosek wrote: Hi Endi, Quickly skimming through your patches raised couple questions on my side: 1) Will it be possible to also store plain text password via Vault? It talks about taking in the binary data or the text file, but will it also work with plain user secrets (passwords)? I am talking about use like this: # ipa vault-archive name --user mkosek --data Secret123 For security the plain text password should be stored in a file first: # vi password.txt # ipa vault-archive name --user mkosek --in password.txt It's also possible to specify the password as base-64 encoded data: # echo -n Secret123 | base64 # ipa vault-archive name --user mkosek --data U2VjcmV0MTIz But it's not recommended since the data will be stored in the command history and someone could see and decode it. I think passing a plain text password as command line argument would be even worse. The --data parameter is mainly used for unit testing. Later we might be able to add an option to read from standard input: # cat password.txt | ipa vault-archive name --user mkosek --std-in 2) Didn't we discuss a dependency of IPA/Vault on python-cryptography in the past? I rather see use of python-nss for cryptography... Yes. I might have mentioned that it would be in the 2nd (current) vault patch. Actually it will be in the 3rd patch when we add the symmetric and asymmetric vaults. The symmetric and asymmetric encryption will be implemented using python-cryptography. You can also see this in an old patch (#358) but it's obsolete now. The standard vault in the current patch uses python-nss for transport encryption because when the KRA interface was written python-cryptography wasn't available on Fedora, it didn't support certificates, and I'm not sure if it supports key wrapping. The symmetric and asymmetric vaults add an additional layer of encryption on top of the standard transport encryption, so it will depend on both python-nss and python-cryptography. In the future if the KRA can support python-cryptography without python-nss we may be able to drop the python-nss dependency from vaults. 3) You do a lot of actions in the forward() method (as planned in https://www.freeipa.org/page/V4/Password_Vault#Archival). But how do you envision that this is consumed by the Web UI? It does not have access to the forward() method. Would it need to also include some crypto library? If Web UI wants to access vault (not sure if everybody agrees with that), it would have to perform an encryption on the browser side. In that case we will need to use either WebCrypto or a browser-specific extension to implement something similar to vault_archive.forward(), assuming the required cryptographic functionalities are available. In the future PKI might be able to provide a JavaScript interface for KRA. 4) In the vault-archive forward method, you use pki module. However, this module will be only available on FreeIPA PKI-powered servers and not on FreeIPA clients - so this will not work unless freeipa-client gets a dependency on pki-base - which is definitely not something we want... In my opinion it should be fine to require pki-base on the client because it contains just the client library, unless you have other concerns? Any objections to having pki-nss and pki-cryptography dependencies on the client? Even if we can change the client code not to depend on pki module, since in this framework the client and server code are written in the same plugin, the import pki still cannot be removed since it's still needed by the server code, and I don't think conditional import is a good programming practice. Thanks, Martin -- Endi S. Dewata -- 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 0007] replica install fails with domain level 1
On 06/01/2015 03:10 PM, thierry bordaz wrote: On 06/01/2015 11:19 AM, Oleg Fayans wrote: Woks for me too. Will perform extensive testing today, and report everything that I find. Thanks, Ludwig! On 05/29/2015 04:44 PM, Ludwig Krispenz wrote: This is a patch for the two issues reported in ticket #5035 https://fedorahosted.org/freeipa/ticket/5035 Works for me. I was able to install 2 replicas with domain level 1 in one topology. Code looks good to me as well. Tentative ACK (would be nice if it was skimmed by Thierry). Sorry for the late feedback. This change looks good to me as well. ACK Pushed to master: faa4d0b6ea6e911c1098b070d1959b3106d5b5b2 -- Petr Vobornik -- 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 2.6.2015 v 02:02 Endi Sukma Dewata napsal(a):
On 5/28/2015 12:46 AM, Jan Cholasta wrote:
On a related note, since KRA is optional, can we move the vaults
container to cn=kra,cn=vaults? This is the convetion used by the other
optional components (DNS and recently CA).
I mean cn=vaults,cn=kra of course.
If you are talking about the o=kra,PKI suffix, I'm not sure whether
the IPA framework will work with it.
If you are talking about adding a new cn=kra,IPA suffix entry on top
of cn=vaults, what is the purpose of this entry? Is the entry going to
be created/deleted automatically when the KRA is installed/removed? Is
it going to be used for something else other than vaults?
I'm talking about cn=kra,IPA suffix. It should be created only when
KRA is installed, although I think this can be done later after the
release, moving vaults to cn=kra should be good enough for now. It's
going to be used for everything KRA-specific.
There are a lot of questions that need to be answered before we can make
this change.
This is about sticking to a convention, which everyone should do, and
everyone except KRA already does.
I'm sorry I didn't realize this earlier, but the change must be done now.
We probably should revisit this issue after the core vault
functionality is added.
We can't revisit it later because after release we are stuck with
whatever is there forever.
See attachment for a patch which implements the change.
--
Jan Cholasta
From 47295de5fb63195f7c07fa2528c6d6450e25d659 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Tue, 2 Jun 2015 09:40:50 +
Subject: [PATCH] vault: Move vaults to cn=vaults,cn=kra
https://fedorahosted.org/freeipa/ticket/3872
---
install/updates/40-vault.update | 13 +
ipa-client/man/default.conf.5 | 2 +-
ipalib/constants.py | 2 +-
ipatests/test_xmlrpc/test_vault_plugin.py | 24
4 files changed, 23 insertions(+), 18 deletions(-)
diff --git a/install/updates/40-vault.update b/install/updates/40-vault.update
index 5a6b8c6..dcd1e2a 100644
--- a/install/updates/40-vault.update
+++ b/install/updates/40-vault.update
@@ -1,19 +1,24 @@
-dn: cn=vaults,$SUFFIX
+dn: cn=kra,$SUFFIX
+default: objectClass: top
+default: objectClass: nsContainer
+default: cn: kra
+
+dn: cn=vaults,cn=kra,$SUFFIX
default: objectClass: top
default: objectClass: nsContainer
default: cn: vaults
-dn: cn=services,cn=vaults,$SUFFIX
+dn: cn=services,cn=vaults,cn=kra,$SUFFIX
default: objectClass: top
default: objectClass: nsContainer
default: cn: services
-dn: cn=shared,cn=vaults,$SUFFIX
+dn: cn=shared,cn=vaults,cn=kra,$SUFFIX
default: objectClass: top
default: objectClass: nsContainer
default: cn: shared
-dn: cn=users,cn=vaults,$SUFFIX
+dn: cn=users,cn=vaults,cn=kra,$SUFFIX
default: objectClass: top
default: objectClass: nsContainer
default: cn: users
diff --git a/ipa-client/man/default.conf.5 b/ipa-client/man/default.conf.5
index 0973f1a..e345e93 100644
--- a/ipa-client/man/default.conf.5
+++ b/ipa-client/man/default.conf.5
@@ -221,7 +221,7 @@ The following define the containers for the IPA server. Containers define where
container_sudocmdgroup: cn=sudocmdgroups,cn=sudo
container_sudorule: cn=sudorules,cn=sudo
container_user: cn=users,cn=accounts
- container_vault: cn=vaults
+ container_vault: cn=vaults,cn=kra
container_virtual: cn=virtual operations,cn=etc
.SH FILES
diff --git a/ipalib/constants.py b/ipalib/constants.py
index 95dec54..7815e14 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -99,7 +99,7 @@ DEFAULT_CONFIG = (
('container_hbacservice', DN(('cn', 'hbacservices'), ('cn', 'hbac'))),
('container_hbacservicegroup', DN(('cn', 'hbacservicegroups'), ('cn', 'hbac'))),
('container_dns', DN(('cn', 'dns'))),
-('container_vault', DN(('cn', 'vaults'))),
+('container_vault', DN(('cn', 'vaults'), ('cn', 'kra'))),
('container_virtual', DN(('cn', 'virtual operations'), ('cn', 'etc'))),
('container_sudorule', DN(('cn', 'sudorules'), ('cn', 'sudo'))),
('container_sudocmd', DN(('cn', 'sudocmds'), ('cn', 'sudo'))),
diff --git a/ipatests/test_xmlrpc/test_vault_plugin.py b/ipatests/test_xmlrpc/test_vault_plugin.py
index 44d397c..012baec 100644
--- a/ipatests/test_xmlrpc/test_vault_plugin.py
+++ b/ipatests/test_xmlrpc/test_vault_plugin.py
@@ -54,7 +54,7 @@ class test_vault_plugin(Declarative):
'value': vault_name,
'summary': 'Added vault %s' % vault_name,
'result': {
-'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,%s'
+'dn': u'cn=%s,cn=admin,cn=users,cn=vaults,cn=kra,%s'
% (vault_name, api.env.basedn),
'objectclass': [u'top', u'ipaVault'],
'cn': [vault_name],
@@ -75,7 +75,7 @@ class test_vault_plugin(Declarative):
'summary': u'1 vault matched',
Re: [Freeipa-devel] [PATCH 0008-0009] use 1 as domain level to activate plugin, fix a crash when removing a replica
On Tue, Jun 02, 2015 at 10:04:55AM +0200, Ludwig Krispenz wrote:
Hi,
with the first patch the topo plugin no longer uses plugin version to
compare to set domainlevel, always gets activated if dom level = 1
the second patch fixes a crash at replica removal
Ludwig
These patches fix the issue for me.
I don't know what is (supposed to be) happening in the code. Is my
testing enough for the ACK?
Cheers,
Fraser
From 7e08b6181973cc51e50eae69974682878b8ca66b Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz lkris...@redhat.com
Date: Tue, 2 Jun 2015 09:17:54 +0200
Subject: [PATCH] plugin uses 1 as minimum domain level to become active no
calculation based on plugin version
---
daemons/ipa-slapi-plugins/topology/topology.h | 9 ++--
daemons/ipa-slapi-plugins/topology/topology_cfg.c | 25
+++---
daemons/ipa-slapi-plugins/topology/topology_init.c | 2 +-
daemons/ipa-slapi-plugins/topology/topology_util.c | 4 +---
4 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/topology/topology.h
b/daemons/ipa-slapi-plugins/topology/topology.h
index
38c2823f50153c6b02a234608869617c92d1bdf2..4135a8ff71b9160919a089fde63a95a989830de8
100644
--- a/daemons/ipa-slapi-plugins/topology/topology.h
+++ b/daemons/ipa-slapi-plugins/topology/topology.h
@@ -125,11 +125,6 @@ typedef struct topo_plugin_config {
int activated;
} TopoPluginConf;
-typedef struct ipa_domain_level {
-int major;
-int minor;
-} IpaDomainLevel;
-
#define CONFIG_ATTR_SHARED_BASE nsslapd-topo-plugin-shared-config-base
#define CONFIG_ATTR_REPLICA_ROOT nsslapd-topo-plugin-shared-replica-root
#define CONFIG_ATTR_SHARED_BINDDNGROUP
nsslapd-topo-plugin-shared-binddngroup
@@ -158,8 +153,8 @@ int ipa_topo_get_plugin_version_major(void);
int ipa_topo_get_plugin_version_minor(void);
char *ipa_topo_get_domain_level_entry(void);
Slapi_DN *ipa_topo_get_domain_level_entry_dn(void);
-int ipa_topo_get_domain_level_major(void);
-int ipa_topo_get_domain_level_minor(void);
+int ipa_topo_get_domain_level(void);
+int ipa_topo_get_min_domain_level(void);
int ipa_topo_get_plugin_startup_delay(void);
void ipa_topo_set_plugin_id(void *plg_id);
void ipa_topo_set_plugin_active(int state);
diff --git a/daemons/ipa-slapi-plugins/topology/topology_cfg.c
b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
index
17493495af83d1095fbafead104d6f56bd7af10e..982ad647db9737c1aa0fc7f68c7d9b20de895fb6
100644
--- a/daemons/ipa-slapi-plugins/topology/topology_cfg.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
@@ -10,7 +10,8 @@
*/
static TopoPluginConf topo_plugin_conf = {0};
static TopoReplicaConf topo_shared_conf = {0};
-static IpaDomainLevel ipa_domain_level = {0,0};
+static int ipa_domain_level = 0;
+static int topo_min_domain_level = 1;
char *ipa_topo_plugin_managed_attrs[] = {
nsds5ReplicaStripAttrs,
@@ -95,15 +96,15 @@ ipa_topo_get_domain_level_entry_dn(void)
}
int
-ipa_topo_get_domain_level_major(void)
+ipa_topo_get_min_domain_level(void)
{
-return ipa_domain_level.major;
+return topo_min_domain_level;
}
int
-ipa_topo_get_domain_level_minor(void)
+ipa_topo_get_domain_level(void)
{
-return ipa_domain_level.minor;
+return ipa_domain_level;
}
char *
@@ -199,22 +200,12 @@ ipa_topo_set_plugin_shared_bindgroup(char *bindgroup)
void
ipa_topo_set_domain_level(char *level)
{
-char *minor;
-
if (level == NULL) {
-ipa_domain_level.major = 0;
-ipa_domain_level.minor = 0;
+ipa_domain_level = 0;
return;
}
-minor = strchr(level,'.');
-if (minor) {
-*minor = '\0';
-ipa_domain_level.minor = atoi(++minor);
-} else {
-ipa_domain_level.minor = 0;
-}
-ipa_domain_level.major = atoi(level);
+ipa_domain_level = atoi(level);
}
void
diff --git a/daemons/ipa-slapi-plugins/topology/topology_init.c
b/daemons/ipa-slapi-plugins/topology/topology_init.c
index
77e740ea182c2331c88d2716d1c4f7be8ef8c257..af5b8021f4ba6833dff11d9c89543e9bb74bdeb9
100644
--- a/daemons/ipa-slapi-plugins/topology/topology_init.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_init.c
@@ -264,7 +264,7 @@ ipa_topo_rootdse_search(Slapi_PBlock *pb, Slapi_Entry* e,
Slapi_Entry* entryAfte
/* we expose temporarily the domain level in this function, should
* finally be handled in a plugin managing the domain level
*/
-char *level = slapi_ch_smprintf(%d, ipa_topo_get_domain_level_major());
+char *level = slapi_ch_smprintf(%d, ipa_topo_get_domain_level());
slapi_entry_attr_set_charptr(e, ipaDomainLevel, level);
slapi_ch_free_string(version);
slapi_ch_free_string(level);
diff --git a/daemons/ipa-slapi-plugins/topology/topology_util.c
b/daemons/ipa-slapi-plugins/topology/topology_util.c
index
Re: [Freeipa-devel] [PATCH 0262] Installer FIX: remove temporal ccache
On 02/06/15 10:24, Fraser Tweedale wrote:
On Mon, Jun 01, 2015 at 04:47:46PM +0200, Martin Basti wrote:
On 01/06/15 16:14, Rob Crittenden wrote:
Martin Basti wrote:
Fixes an issue caused by the latest installer patches pushed to master.
Patch attached.
The use of globals makes my skin crawl a bit, but since you're making
changes in here you should take a look at this ticket:
https://fedorahosted.org/freeipa/ticket/5042
rob
Hi Rob,
this is fix for that ticket, I missed the ticket somehow.
Thanks.
Martin^2
--
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
Fixes the problem for me, but I agree with Rob re globals - a
context manager would be much nicer. Something like (pseudocode):
@contextlib.context_manager
def private_ccache():
... stuff currently in init_private_ccache()
yield
... stuff currently in destroy_private_ccache()
Then in ipa-server-install main():
with private_ccache:
if not options.uninstall:
server.install_check(options)
server.install(options)
else:
server.uninstall_check(options)
server.uninstall(options)
Cheers,
Fraser
Hello,
comments below:
1)
+Str(
+'memberprincipal',
+label=_('Failed principals'),
+),
+Str(
+'ipaallowedtarget',
+label=_('Failed targets'),
+),
+Str(
+'servicedelegationrule',
+label=_('principal member'),
+),
Are these names correct?
# ipa servicedelegationrule-find
--
1 service delegation rule matched
--
Delegation name: ipa-http-delegation
Allowed Target: ipa-ldap-delegation-targets, ipa-cifs-delegation-targets
Failed principals: HTTP/vm-093.example@example.com
2)
+ pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, ., '
+ 'and a space inside',
This regex does not allow space inside
In [6]: print re.match(pattern, 'lalalala lalala')
None
3)
+yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
+ label=_('member %s') % name,
+ csv=True, alwaysask=True)
IMHO CSV values should not be supported.
Honza told me, the option doesn't work anyway.
Patch with minor fixes attached.
I removed unused code and PEP8 complains
Martin^2
From 3d051d3ec13fe19e2e5246b28e848460538d81bf Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Tue, 2 Jun 2015 15:49:21 +0200
Subject: [PATCH] review service delegation
---
ipalib/plugins/servicedelegation.py | 40 ++---
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/ipalib/plugins/servicedelegation.py b/ipalib/plugins/servicedelegation.py
index 434c446de590299b8a1c26344cbecd17f6a8ef3c..50b07dc8ad3112c0ee636b0d0ea7e0cd59365d9c 100644
--- a/ipalib/plugins/servicedelegation.py
+++ b/ipalib/plugins/servicedelegation.py
@@ -178,8 +178,7 @@ class servicedelegation_add_member(LDAPAddMember):
name = self.member_names[attr]
doc = self.member_param_doc % name
yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
- label=_('member %s') % name,
- csv=True, alwaysask=True)
+ label=_('member %s') % name, alwaysask=True)
def get_member_dns(self, **options):
@@ -187,7 +186,7 @@ class servicedelegation_add_member(LDAPAddMember):
special handling since it is just a principal, not a
full dn.
-return (dict(), dict())
+return dict(), dict()
def post_callback(self, ldap, completed, failed, dn, entry_attrs,
*keys, **options):
@@ -210,8 +209,8 @@ class servicedelegation_add_member(LDAPAddMember):
name = normalize_principal(name)
obj_dn = ldap_obj.get_dn(name)
try:
-s_attrs = ldap.get_entry(obj_dn, ['krbprincipalname'])
-except errors.NotFound, e:
+ldap.get_entry(obj_dn, ['krbprincipalname'])
+except errors.NotFound as e:
failed[attr][ldap_obj_name].append((name, unicode(e)))
continue
try:
@@ -219,22 +218,21 @@ class servicedelegation_add_member(LDAPAddMember):
members.append(name)
else:
raise errors.AlreadyGroupMember()
-except errors.PublicError, e:
+except errors.PublicError as e:
failed[attr][ldap_obj_name].append((name, unicode(e)))
else:
completed += 1
if members:
-if attr in
Re: [Freeipa-devel] [PATCH 0262] Installer FIX: remove temporal ccache
On 02/06/15 16:00, Jan Cholasta wrote:
Dne 2.6.2015 v 15:57 Martin Basti napsal(a):
On 02/06/15 10:24, Fraser Tweedale wrote:
On Mon, Jun 01, 2015 at 04:47:46PM +0200, Martin Basti wrote:
On 01/06/15 16:14, Rob Crittenden wrote:
Martin Basti wrote:
Fixes an issue caused by the latest installer patches pushed to
master.
Patch attached.
The use of globals makes my skin crawl a bit, but since you're making
changes in here you should take a look at this ticket:
https://fedorahosted.org/freeipa/ticket/5042
rob
Hi Rob,
this is fix for that ticket, I missed the ticket somehow.
Thanks.
Martin^2
--
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
Fixes the problem for me, but I agree with Rob re globals - a
context manager would be much nicer. Something like (pseudocode):
@contextlib.context_manager
def private_ccache():
... stuff currently in init_private_ccache()
yield
... stuff currently in destroy_private_ccache()
Then in ipa-server-install main():
with private_ccache:
if not options.uninstall:
server.install_check(options)
server.install(options)
else:
server.uninstall_check(options)
server.uninstall(options)
Cheers,
Fraser
Hello,
comments below:
1)
+Str(
+'memberprincipal',
+label=_('Failed principals'),
+),
+Str(
+'ipaallowedtarget',
+label=_('Failed targets'),
+),
+Str(
+'servicedelegationrule',
+label=_('principal member'),
+),
Are these names correct?
# ipa servicedelegationrule-find
--
1 service delegation rule matched
--
Delegation name: ipa-http-delegation
Allowed Target: ipa-ldap-delegation-targets,
ipa-cifs-delegation-targets
Failed principals: HTTP/vm-093.example@example.com
2)
+ pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$',
+pattern_errmsg='may only include letters, numbers, _, -,
., '
+ 'and a space inside',
This regex does not allow space inside
In [6]: print re.match(pattern, 'lalalala lalala')
None
3)
+yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
+ label=_('member %s') % name,
+ csv=True, alwaysask=True)
IMHO CSV values should not be supported.
Honza told me, the option doesn't work anyway.
Patch with minor fixes attached.
I removed unused code and PEP8 complains
Wrong thread :-)
Sorry :-)
--
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] 1112 Add service constraint delegation plugin
On 31/05/15 04:07, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/27/2015 08:17 PM, Martin Basti wrote:
On 27/05/15 19:27, Rob Crittenden wrote:
Martin Basti wrote:
Thank you.
I haven't finished review yet, but I have few notes in case you will
modify the patch.
Please fix following issues:
3)
There are many PEP8 errors, can you fix some of them,?
Is PEP8 a concern? What kinds of errors do we fix? For example, the
current model for defining options generates a slew of indention
errors.
In old modules it's preferred to keep the old indentation style for
options(not to mix 2 styles). New modules should use following pep8
compliant style:
Str(
'cn',
cli_name='name',
primary_key=True,
label=_('Server name'),
doc=_('IPA server hostname'),
),
We try to keep PEP8 in new code, mainly indentation, blank lines, too
long lines.
Yes in test definitions and option definitions, is better to keep the
same style, but other parts of code should be PEP8.
For example these should be fixed
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225
missing whitespace around operator
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302
expected 2 blank lines, found 1
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302
expected 2 blank lines, found 1
I'll wait and see what falls out of the API review before making any
real changes.
rob
Updated API and addressed Martin's concerns. The regex must have been
a bad copy/paste, it is fixed now.
The design page has been updated as well.
rob
Hello,
comments below, in the right thread:
1)
+Str(
+'memberprincipal',
+label=_('Failed principals'),
+),
+Str(
+'ipaallowedtarget',
+label=_('Failed targets'),
+),
+Str(
+'servicedelegationrule',
+label=_('principal member'),
+),
Are these names correct?
# ipa servicedelegationrule-find
--
1 service delegation rule matched
--
Delegation name: ipa-http-delegation
Allowed Target: ipa-ldap-delegation-targets,
ipa-cifs-delegation-targets
Failed principals: HTTP/vm-093.example@example.com
2)
+ pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, ., '
+ 'and a space inside',
This regex does not allow space inside
In [6]: print re.match(pattern, 'lalalala lalala')
None
3)
+yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
+ label=_('member %s') % name,
+ csv=True, alwaysask=True)
IMHO CSV values should not be supported.
Honza told me, the option doesn't work anyway.
Patch with minor fixes attached.
I removed unused code and PEP8 complains
--
Martin Basti
From 3d051d3ec13fe19e2e5246b28e848460538d81bf Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Tue, 2 Jun 2015 15:49:21 +0200
Subject: [PATCH] review service delegation
---
ipalib/plugins/servicedelegation.py | 40 ++---
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/ipalib/plugins/servicedelegation.py b/ipalib/plugins/servicedelegation.py
index 434c446de590299b8a1c26344cbecd17f6a8ef3c..50b07dc8ad3112c0ee636b0d0ea7e0cd59365d9c 100644
--- a/ipalib/plugins/servicedelegation.py
+++ b/ipalib/plugins/servicedelegation.py
@@ -178,8 +178,7 @@ class servicedelegation_add_member(LDAPAddMember):
name = self.member_names[attr]
doc = self.member_param_doc % name
yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
- label=_('member %s') % name,
- csv=True, alwaysask=True)
+ label=_('member %s') % name, alwaysask=True)
def get_member_dns(self, **options):
@@ -187,7 +186,7 @@ class servicedelegation_add_member(LDAPAddMember):
special handling since it is just a principal, not a
full dn.
-return (dict(), dict())
+return dict(), dict()
def post_callback(self, ldap, completed, failed, dn, entry_attrs,
*keys, **options):
@@ -210,8 +209,8 @@ class servicedelegation_add_member(LDAPAddMember):
name = normalize_principal(name)
obj_dn = ldap_obj.get_dn(name)
try:
-s_attrs = ldap.get_entry(obj_dn, ['krbprincipalname'])
-except errors.NotFound, e:
+ldap.get_entry(obj_dn, ['krbprincipalname'])
+except errors.NotFound as e:
failed[attr][ldap_obj_name].append((name, unicode(e)))
continue
try:
@@ -219,22 +218,21 @@ class servicedelegation_add_member(LDAPAddMember):
members.append(name)
Re: [Freeipa-devel] [PATCH 0262] Installer FIX: remove temporal ccache
Dne 2.6.2015 v 10:53 Martin Basti napsal(a): On 02/06/15 10:24, Fraser Tweedale wrote: On Mon, Jun 01, 2015 at 04:47:46PM +0200, Martin Basti wrote: On 01/06/15 16:14, Rob Crittenden wrote: Martin Basti wrote: Fixes an issue caused by the latest installer patches pushed to master. Patch attached. The use of globals makes my skin crawl a bit, but since you're making changes in here you should take a look at this ticket: https://fedorahosted.org/freeipa/ticket/5042 rob Hi Rob, this is fix for that ticket, I missed the ticket somehow. Thanks. Martin^2 -- 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 Fixes the problem for me, but I agree with Rob re globals - a context manager would be much nicer. Something like (pseudocode): @contextlib.context_manager def private_ccache(): ... stuff currently in init_private_ccache() yield ... stuff currently in destroy_private_ccache() Then in ipa-server-install main(): with private_ccache: if not options.uninstall: server.install_check(options) server.install(options) else: server.uninstall_check(options) server.uninstall(options) Cheers, Fraser Thank you! However, I would wait for Honza's answer, if this will fit in his big installer plan. The code will be gradually ported to the new install framework, removing the globals in the process. The context manager was used before the code was moved into a module and was removed on purpose to allow the split to two functions, which is necessary for the port. ACK on the patch. Pushed to master: af8f44c86ab37d83b952c0f021c6509c48be7da8 -- 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] [PATCH 0014 v3] Support multiple user and host certificates
On 02/06/15 11:42, Fraser Tweedale wrote:
On Mon, Jun 01, 2015 at 02:50:45PM +0200, Martin Basti wrote:
On 01/06/15 06:40, Fraser Tweedale wrote:
New version of patch; ``{host,service}-show --out=FILE`` now writes
all certs to FILE. Rebased on latest master.
Thanks,
Fraser
On Thu, May 28, 2015 at 09:18:04PM +1000, Fraser Tweedale wrote:
Updated patch attached. Notably restores/adds revocation behaviour
to host-mod and service-mod.
Thanks,
Fraser
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not cert guru :)
I personally vote for serial number in case there are multiple certificates,
if ^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
only the --addattr='usercertificate=cert' appends new value there
--
Martin Basti
My objections/proposed solutions in attached patch.
* VERSION
* In the previous version normalized values was stored in LDAP, so I added
it back. (I dont know why there is no normalization in param settings, but
normalization for every certificate is done in callback. I will file a
ticket for this)
* IMO only normalized certificates should be compared in the old
certificates detection
I incorporated your suggested changes in new patch (attached).
There were no proposed changes to the other patchset (0001..0013)
since rebase.
Thanks,
Fraser
Thank you,
ACK
Martin^2
--
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 0048] fix ipa help command output errors
Dne 25.5.2015 v 14:27 Martin Basti napsal(a): On 22/05/15 17:40, Gabe Alford wrote: On Fri, May 22, 2015 at 9:01 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 22/05/15 16:08, Gabe Alford wrote: Hello, This should fix https://fedorahosted.org/freeipa/ticket/3584, and as requested in the ticket, this should also fix https://fedorahosted.org/freeipa/ticket/2284 Thanks, Gabe Thank you! IMO your first part of fix only mask issue, not solving it. This could be way, but I did not test it. out_encoding = getattr(outfile, 'encoding', None) if out_encoding is None: out_encoding = 'utf-8' print outfile, unicode(string).encode(out_encoding) I'm confused and maybe missing something here. If I run `ipa help dns | bad_command`, shouldn't the command fail with only the following? -bash: bad: command not found Can you split this patch into 2 separate patches for each ticket please? Done Martin^2 -- Martin Basti Thank you! ACK and ACK. Pushed to master: b98077ea6844eddd8810e4ae6ddd5bf40c61b58e -- 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] [PATCH 0262] Installer FIX: remove temporal ccache
Dne 2.6.2015 v 15:57 Martin Basti napsal(a):
On 02/06/15 10:24, Fraser Tweedale wrote:
On Mon, Jun 01, 2015 at 04:47:46PM +0200, Martin Basti wrote:
On 01/06/15 16:14, Rob Crittenden wrote:
Martin Basti wrote:
Fixes an issue caused by the latest installer patches pushed to
master.
Patch attached.
The use of globals makes my skin crawl a bit, but since you're making
changes in here you should take a look at this ticket:
https://fedorahosted.org/freeipa/ticket/5042
rob
Hi Rob,
this is fix for that ticket, I missed the ticket somehow.
Thanks.
Martin^2
--
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
Fixes the problem for me, but I agree with Rob re globals - a
context manager would be much nicer. Something like (pseudocode):
@contextlib.context_manager
def private_ccache():
... stuff currently in init_private_ccache()
yield
... stuff currently in destroy_private_ccache()
Then in ipa-server-install main():
with private_ccache:
if not options.uninstall:
server.install_check(options)
server.install(options)
else:
server.uninstall_check(options)
server.uninstall(options)
Cheers,
Fraser
Hello,
comments below:
1)
+Str(
+'memberprincipal',
+label=_('Failed principals'),
+),
+Str(
+'ipaallowedtarget',
+label=_('Failed targets'),
+),
+Str(
+'servicedelegationrule',
+label=_('principal member'),
+),
Are these names correct?
# ipa servicedelegationrule-find
--
1 service delegation rule matched
--
Delegation name: ipa-http-delegation
Allowed Target: ipa-ldap-delegation-targets, ipa-cifs-delegation-targets
Failed principals: HTTP/vm-093.example@example.com
2)
+ pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, ., '
+ 'and a space inside',
This regex does not allow space inside
In [6]: print re.match(pattern, 'lalalala lalala')
None
3)
+yield Str('%s*' % name, cli_name='%ss' % name, doc=doc,
+ label=_('member %s') % name,
+ csv=True, alwaysask=True)
IMHO CSV values should not be supported.
Honza told me, the option doesn't work anyway.
Patch with minor fixes attached.
I removed unused code and PEP8 complains
Wrong thread :-)
--
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] [PATCH 0014 v3] Support multiple user and host certificates
Dne 2.6.2015 v 12:36 Martin Basti napsal(a):
On 02/06/15 11:42, Fraser Tweedale wrote:
On Mon, Jun 01, 2015 at 02:50:45PM +0200, Martin Basti wrote:
On 01/06/15 06:40, Fraser Tweedale wrote:
New version of patch; ``{host,service}-show --out=FILE`` now writes
all certs to FILE. Rebased on latest master.
Thanks,
Fraser
On Thu, May 28, 2015 at 09:18:04PM +1000, Fraser Tweedale wrote:
Updated patch attached. Notably restores/adds revocation behaviour
to host-mod and service-mod.
Thanks,
Fraser
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem
file, but I'm
not cert guru :)
I personally vote for serial number in case there are multiple
certificates,
if ^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in
the code.
only the --addattr='usercertificate=cert' appends new value there
--
Martin Basti
My objections/proposed solutions in attached patch.
* VERSION
* In the previous version normalized values was stored in LDAP, so I
added
it back. (I dont know why there is no normalization in param
settings, but
normalization for every certificate is done in callback. I will file a
ticket for this)
* IMO only normalized certificates should be compared in the old
certificates detection
I incorporated your suggested changes in new patch (attached).
There were no proposed changes to the other patchset (0001..0013)
since rebase.
Thanks,
Fraser
Thank you,
ACK
Martin^2
Pushed to master: 7f7c247bb5a4b0030d531f4f14c156162e808212
--
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] [PATCH 0329] ipa-replica-manage: Do not allow topology altering commands
On 06/02/2015 02:19 PM, Martin Babinsky wrote: On 06/02/2015 02:10 PM, Tomas Babej wrote: Hi, With Domain Level 1 and above, the usage of ipa-replica-manage commands that alter the replica topology is deprecated. Following commands are prohibited: * connect * disconnect * del Upon executing any of these commands, users are pointed out to the ipa topologysegment-* replacements. Part of: https://fedorahosted.org/freeipa/ticket/4302 Works for me, ACK. Not that fast... connect and disconnect is clear. However, del does more actions than just removing the agreement. It may need to - check domain level - if 0, continue doing what it always did - if 1, call the topology API command - continue with the cleanup (CLEANALLRUV and friends) 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 0329] ipa-replica-manage: Do not allow topology altering commands
hi, is there a real replacement for del, it is not in the scope of the topology commands, the removal of teh agreement is rejected and later done by the plugin, but what about removal of the host, services, cleanruv ? Ludwig On 06/02/2015 02:10 PM, Tomas Babej wrote: Hi, With Domain Level 1 and above, the usage of ipa-replica-manage commands that alter the replica topology is deprecated. Following commands are prohibited: * connect * disconnect * del Upon executing any of these commands, users are pointed out to the ipa topologysegment-* replacements. Part of: https://fedorahosted.org/freeipa/ticket/4302 -- 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 0329] ipa-replica-manage: Do not allow topology altering commands
I agree. Maybe we should think about some wrapper that would call topologysegment-del command before actually cleaning the services etc., upon each `ipa-replica-manage del` rather than prohibiting the usage of the command at all. My 2 cents (maybe, too late) On 06/02/2015 02:24 PM, Ludwig Krispenz wrote: hi, is there a real replacement for del, it is not in the scope of the topology commands, the removal of teh agreement is rejected and later done by the plugin, but what about removal of the host, services, cleanruv ? Ludwig On 06/02/2015 02:10 PM, Tomas Babej wrote: Hi, With Domain Level 1 and above, the usage of ipa-replica-manage commands that alter the replica topology is deprecated. Following commands are prohibited: * connect * disconnect * del Upon executing any of these commands, users are pointed out to the ipa topologysegment-* replacements. Part of:https://fedorahosted.org/freeipa/ticket/4302 -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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 0257] ULC: Fix: Upgrade for stage user admins failed
Dne 25.5.2015 v 10:53 David Kupka napsal(a): On 05/22/2015 05:59 PM, Martin Basti wrote: Patch attached. Thanks for patch. Works for me, ACK. Pushed to master: 943c5391221fdeb6520e60d2f5b04ce41b085169 -- 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] [PATCH 0377-0382] Synchronize changes from LDAP after reconnect
On 2.6.2015 13:15, Tomas Hozza wrote: On 05/28/2015 05:58 PM, Matus Honek wrote: Hi, functionality seems to work fine. I have not checked the code thoroughly. Kind of a test is attached (requires setting named's ldap connection appropriately). ACK Matúš Honěk - Original Message - From: Petr Spacek pspa...@redhat.com To: tho...@redhat.com, Matus Honek mho...@redhat.com Cc: freeipa-devel@redhat.com Sent: Wednesday, May 27, 2015 2:50:52 PM Subject: [PATCH 0377-0382] Synchronize changes from LDAP after reconnect Hello, https://fedorahosted.org/bind-dyndb-ldap/ticket/128 Previously records deleted when connection to LDAP server was down were not synchronized properly. It should work now. I use this command to simulate broken connections and connection re-establishment: $ socat tcp-listen:3899,reuseaddr,fork tcp-connect:localhost:389 It should be enough to add ldap://$(hostname):3899 as LDAP URI to /etc/named.conf and then simulate changes by killing and restarting socat. Let me know if you need any assistance! Hi. I did a formal review of the code. Everything looks good. ACK. Thank you very much! Pushed to master: 9b4a6373c868f8858253d5e9bf850e1cbbed2a7f Avoid synchronization state resets. 783b04c87575205388a1277da8b46a781508f4a7 Consolidate synchronization state machine to sync_state_change(). c727f40cae75b9f2e05f2789bade937c90202f11 On reconnect, detect and delete RBT nodes which were removed from LDAP. 77ecee87f551567b94bd26290c734c7feb5ed93f Add iterators for dead nodes in metaLDAP. b476041bd6a88b88cd1739e61960a666868e1b23 Increment MetaLDAP generation number on reconnect. 57e87e325bbfe60709a53c8d5422339bb5f2b664 Add functions for MetaLDAP generation number manipulation. We are well on track to 8.0 release :-) -- 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 424] install: Introduce installer framework ipapython.install
Dne 11.5.2015 v 13:41 Jan Cholasta napsal(a):
Dne 6.5.2015 v 08:22 Jan Cholasta napsal(a):
Dne 6.5.2015 v 08:11 Martin Kosek napsal(a):
On 04/29/2015 06:25 PM, Jan Cholasta wrote:
Dne 20.4.2015 v 16:56 Jan Cholasta napsal(a):
Dne 20.4.2015 v 15:14 Martin Basti napsal(a):
On 17/04/15 16:15, Jan Cholasta wrote:
Dne 16.4.2015 v 16:46 Jan Cholasta napsal(a):
Hi,
the attached patch adds the basics of the new installer framework.
As a next step, I plan to convert the install scripts to use the
framework with their old code (the old code will be gradually
ported to
the framework later).
(Note I didn't manage to write docstrings today, expect update
tomorrow.)
Added some docstrings.
Also updated the patch to reflect little brainstorming David and I
had
this morning.
Honza
Hello, see comments bellow:
1) We started using new shorter License header in files:
#
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
#
OK.
2) IMO this will not work, NoneType has no 'obj' attribute
+else:
+if isinstance(value, from_):
+value = None
+stack.append(value.obj)
+continue
Right.
3) Multiple inheritance. I do not like it much.
+class CompositeInstaller(Installer, CompositeConfigurator):
I guess you are antagonistic to multiple inheritance because of how
other languages (like C++) do it. In Python it can be pretty elegant
and
is basis for e.g. the mixin design pattern.
Installer and CompositeConfigurator inherites from Configurator
class,
and all of them implements _generator method.
Both of them call super()._generator(), so it's no problem (same for
other methods).
If I understand correctly
(https://www.python.org/download/releases/2.3/mro/) the
Installer._generator method will be used in this case.
However in case when CompositeConfigurator has more levels
(respectively
it is more specialized) of inheritance, it could take precedence
and its
_generator method may be used instead.
The order of precedence is defined by the order of base classes in the
class definition.
I'm afraid this may suddenly stop working.
Maybe I'm wrong, please fix me.
As long as you call the super class, it will work fine.
And Multiple inheritance is not easily readable, this is even a
diamond
inheritance model.
Cooperative inheritance is used by design and IMHO is easily
readable if
you know how to read it. Every class defines a single bit of behavior.
Without cooperative inheritance, it would have to be hardcoded and/or
hacked around, which I wanted to avoid.
This blog post explains it nicely:
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/.
Updated patch attached.
Also attached is patch 425 which migrates ipa-server-install to the
install
framework.
Good job there. I am just curious, will this framework and new option
processing be friendly to other types of option passing than just via
options?
I mean tickets
https://fedorahosted.org/freeipa/ticket/4517
https://fedorahosted.org/freeipa/ticket/4468
Especially 4517 is important, we need to be able to run
# cat install.conf
ds_password=Secret123
admin_password=Secret456
ip_address=123456
setup_dns=False
# ipa-server-install --unattended --conf install.conf
I assume yes, but I am just making sure.
Yes, definitely.
Updated patches attached.
Another update, patches attached.
--
Jan Cholasta
From 1426620a2bc89ab74689ca6ede075ebc398bab9e Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Tue, 2 Jun 2015 12:04:25 +
Subject: [PATCH 1/2] install: Introduce installer framework ipapython.install
https://fedorahosted.org/freeipa/ticket/4468
---
freeipa.spec.in | 2 +
ipapython/Makefile| 1 +
ipapython/install/__init__.py | 7 +
ipapython/install/cli.py | 253 +
ipapython/install/common.py | 114 ++
ipapython/install/core.py | 506 ++
ipapython/install/util.py | 169 ++
ipapython/setup.py.in | 4 +-
8 files changed, 1055 insertions(+), 1 deletion(-)
create mode 100644 ipapython/install/__init__.py
create mode 100644 ipapython/install/cli.py
create mode 100644 ipapython/install/common.py
create mode 100644 ipapython/install/core.py
create mode 100644 ipapython/install/util.py
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 09dd66e..bedcb6d 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -882,6 +882,8 @@ fi
%{python_sitelib}/ipapython/*.py*
%dir %{python_sitelib}/ipapython/dnssec
%{python_sitelib}/ipapython/dnssec/*.py*
+%dir %{python_sitelib}/ipapython/install
+%{python_sitelib}/ipapython/install/*.py*
%dir %{python_sitelib}/ipalib
%{python_sitelib}/ipalib/*
%dir %{python_sitelib}/ipaplatform
diff --git a/ipapython/Makefile b/ipapython/Makefile
index b2cf719..8527643 100644
--- a/ipapython/Makefile
+++ b/ipapython/Makefile
@@ -10,6 +10,7 @@ all:
(cd
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? There should be a moment where all the DNs are added. root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg the topology plugin needs a replica binddngroup to be able to setup agrements without having to modify cn=config. If the replica is installed from an older version, this group doesn't exist and adding members to it fails. The attached patch should handle this Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]:
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 05/27/2015 03:53 PM, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Has anybody tried it with Web UI?
Currently Web UI is designed only for one cert. I wonder if it still
works even with just one.
We should probably file a ticket.
--
Petr Vobornik
--
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 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. I see you created cn=replication managers,cn=etc,SUFFIX group. I think this should work, with couple changes: - it should rather be in cn=sysaccounts,cn=etc,SUFFIX, where other similar groups are. See for example cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. Yep, see my another email with an example. -- / 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 0010] KeyError raised upon replica installation
On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg the topology plugin needs a replica binddngroup to be able to setup agrements without having to modify cn=config. If the replica is installed from an older version, this group doesn't exist and adding members to it fails. The attached patch should handle this Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. I see you created cn=replication managers,cn=etc,SUFFIX group. I think this should work, with couple changes: - it should rather be in cn=sysaccounts,cn=etc,SUFFIX, where other similar groups are. See for example cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. Yep, see my another email with an example. -- 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
On 06/02/2015 02:07 PM, Endi Sukma Dewata wrote: On 6/2/2015 1:10 AM, Martin Kosek wrote: Hi Endi, Quickly skimming through your patches raised couple questions on my side: 1) Will it be possible to also store plain text password via Vault? It talks about taking in the binary data or the text file, but will it also work with plain user secrets (passwords)? I am talking about use like this: # ipa vault-archive name --user mkosek --data Secret123 For security the plain text password should be stored in a file first: # vi password.txt # ipa vault-archive name --user mkosek --in password.txt It's also possible to specify the password as base-64 encoded data: # echo -n Secret123 | base64 # ipa vault-archive name --user mkosek --data U2VjcmV0MTIz But it's not recommended since the data will be stored in the command history and someone could see and decode it. I think passing a plain text password as command line argument would be even worse. The --data parameter is mainly used for unit testing. Later we might be able to add an option to read from standard input: # cat password.txt | ipa vault-archive name --user mkosek --std-in Ok. Well, base64 + file input look as good enough for now. I was mostly concerned about usability of the solution for normal users as for a manual secret, it is not convenient to always create an interim file. We will see based on user experience, maybe Web UI or further CLI-only additions will be the answer. 2) Didn't we discuss a dependency of IPA/Vault on python-cryptography in the past? I rather see use of python-nss for cryptography... Yes. I might have mentioned that it would be in the 2nd (current) vault patch. Actually it will be in the 3rd patch when we add the symmetric and asymmetric vaults. The symmetric and asymmetric encryption will be implemented using python-cryptography. You can also see this in an old patch (#358) but it's obsolete now. Ok. The standard vault in the current patch uses python-nss for transport encryption because when the KRA interface was written python-cryptography wasn't available on Fedora, it didn't support certificates, and I'm not sure if it supports key wrapping. The symmetric and asymmetric vaults add an additional layer of encryption on top of the standard transport encryption, so it will depend on both python-nss and python-cryptography. In the future if the KRA can support python-cryptography without python-nss we may be able to drop the python-nss dependency from vaults. Ok. 3) You do a lot of actions in the forward() method (as planned in https://www.freeipa.org/page/V4/Password_Vault#Archival). But how do you envision that this is consumed by the Web UI? It does not have access to the forward() method. Would it need to also include some crypto library? If Web UI wants to access vault (not sure if everybody agrees with that), it would have to perform an encryption on the browser side. In that case we will need to use either WebCrypto or a browser-specific extension to implement something similar to vault_archive.forward(), assuming the required cryptographic functionalities are available. In the future PKI might be able to provide a JavaScript interface for KRA. Ok, makes sense. I think we will want Web UI at some point, but the summary for FreeIPA 4.2 seems - no Web UI for Vault (yet). 4) In the vault-archive forward method, you use pki module. However, this module will be only available on FreeIPA PKI-powered servers and not on FreeIPA clients - so this will not work unless freeipa-client gets a dependency on pki-base - which is definitely not something we want... In my opinion it should be fine to require pki-base on the client because it contains just the client library, unless you have other concerns? Any objections to having pki-nss and pki-cryptography dependencies on the client? Even if we can change the client code not to depend on pki module, since in this framework the client and server code are written in the same plugin, the import pki still cannot be removed since it's still needed by the server code, and I don't think conditional import is a good programming practice. I have major concerns here. Look at the different between installing freeipa-client and freeipa-client + pki-base on my F21: ~~ $ sudo yum install freeipa-client ... Install 1 Package (+4 Dependent packages) Total download size: 2.6 M Installed size: 14 M ~~ $ sudo yum install freeipa-client pki-base ... Install 2 Packages (+288 Dependent packages) Total download size: 160 M Installed size: 235 M ~~ This is obviously a no-go for client. The conditional import is smaller concern that big dependency growth on the client. We do them in trust plugin for example and it works fine (though I agree it is not ideal programming
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. I see you created cn=replication managers,cn=etc,SUFFIX group. I think this should work, with couple changes: - it should rather be in cn=sysaccounts,cn=etc,SUFFIX, where other similar groups are. See for example cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. - the group should be populated during new installation of 4.2 or upgrade to 4.2 so that Domain Level raise does not need to be overloaded and generate this group by itself. If this group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no operation needed on FreeIPA side. This is part of the ticket https://fedorahosted.org/freeipa/ticket/3416 This looks as another change that should make it to the Alpha, no? 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 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. -- / 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 0010] KeyError raised upon replica installation
On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? If this group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no operation needed on FreeIPA side. This is part of the ticket https://fedorahosted.org/freeipa/ticket/3416 This looks as another change that should make it to the Alpha, no? 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
On Tue, 02 Jun 2015, Martin Kosek wrote: But it's not recommended since the data will be stored in the command history and someone could see and decode it. I think passing a plain text password as command line argument would be even worse. The --data parameter is mainly used for unit testing. Later we might be able to add an option to read from standard input: # cat password.txt | ipa vault-archive name --user mkosek --std-in Ok. Well, base64 + file input look as good enough for now. I was mostly concerned about usability of the solution for normal users as for a manual secret, it is not convenient to always create an interim file. We will see based on user experience, maybe Web UI or further CLI-only additions will be the answer. Correct, this is a part that can and should be driven by actual use experience. Reading from the stdin is easy to implement (we have it done for password already) so maybe we can simply reuse password option here for such case, we even have a flag for omitting the confirmation prompt. This is fairly small addition. 4) In the vault-archive forward method, you use pki module. However, this module will be only available on FreeIPA PKI-powered servers and not on FreeIPA clients - so this will not work unless freeipa-client gets a dependency on pki-base - which is definitely not something we want... In my opinion it should be fine to require pki-base on the client because it contains just the client library, unless you have other concerns? Any objections to having pki-nss and pki-cryptography dependencies on the client? Even if we can change the client code not to depend on pki module, since in this framework the client and server code are written in the same plugin, the import pki still cannot be removed since it's still needed by the server code, and I don't think conditional import is a good programming practice. I have major concerns here. Look at the different between installing freeipa-client and freeipa-client + pki-base on my F21: ~~ $ sudo yum install freeipa-client ... Install 1 Package (+4 Dependent packages) Total download size: 2.6 M Installed size: 14 M ~~ $ sudo yum install freeipa-client pki-base ... Install 2 Packages (+288 Dependent packages) Total download size: 160 M Installed size: 235 M ~~ This is obviously a no-go for client. The conditional import is smaller concern that big dependency growth on the client. We do them in trust plugin for example and it works fine (though I agree it is not ideal programming practice). IMO, we should limit new freeipa-client dependencies only to python-cryptography (or also python-nss in the worst case, in case python-cryptography is not enough) - there should be no pki dependencies at all, these should be only on the server side. Yes, please use conditional import here, it is perfectly valid use case for the client side. -- / 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 0010] KeyError raised upon replica installation
On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. If this group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no operation needed on FreeIPA side. This is part of the ticket https://fedorahosted.org/freeipa/ticket/3416 This looks as another change that should make it to the Alpha, no? 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 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. They should be fqdn=ipa.master,... For example, this is how cn=adtrust agents looks like for upcoming one-way trust: # adtrust agents, sysaccounts, etc, t.vda.li dn: cn=adtrust agents,cn=sysaccounts,cn=etc,dc=t,dc=vda,dc=li objectClass: GroupOfNames objectClass: top objectClass: nestedgroup cn: adtrust agents memberOf: cn=ADTrust Agents,cn=privileges,cn=pbac,dc=t,dc=vda,dc=li memberOf: cn=System: Read system trust accounts,cn=permissions,cn=pbac,dc=t,dc =vda,dc=li member: krbprincipalname=cifs/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts ,dc=t,dc=vda,dc=li member: fqdn=ipa-01.t.vda.li,cn=computers,cn=accounts,dc=t,dc=vda,dc=li As you can see, cifs/ipa.master and host/ipa.master are members of the group through their respective DNs -- for host/ipa.master the DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. -- / 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 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Simo Sorce wrote: On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. I'm fine to have that too, we rely on it in trusts case so just follow the pattern. -- / 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 0001-0013 v5.1] Profiles and CA ACLs
On 02/06/15 14:11, Fraser Tweedale wrote: On Mon, Jun 01, 2015 at 05:22:28PM +1000, Fraser Tweedale wrote: On Mon, Jun 01, 2015 at 05:10:58PM +1000, Fraser Tweedale wrote: On Fri, May 29, 2015 at 01:03:46PM +0200, Martin Kosek wrote: On 05/29/2015 11:21 AM, Martin Basti wrote: On 29/05/15 06:17, Fraser Tweedale wrote: On Thu, May 28, 2015 at 02:42:53PM +0200, Martin Basti wrote: On 28/05/15 11:48, Martin Basti wrote: On 27/05/15 16:04, Fraser Tweedale wrote: Hello all, Fresh certificate management patchset; Changelog: - Now depends on patch freeipa-ftweedal-0014 for correct cert-request behaviour with host and service principals. - Updated Dogtag dependency to 10.2.4-1. Should should be in f22 soon, but for f22 right now or for f21, please grab from my copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Martin^1 could you please add to the quasi-official freeipa copr? SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm. - cert-request now verifies that for user principals, CSR CN matches uid and, DN emailAddress and SAN rfc822Name match user's email address, if either of those is present. - Fixed one or two other sneaky little bugs. On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote: Hi all, Please find attached the latest certificate management patchset, which introduces the `caacl' plugin and various fixes and improvement to earlier patches. One important change to earlier patches is reverting the name of the default profile to 'caIPAserviceCert' and using the existing instance of this profile on upgrade (but not install) in case it has been modified. Other notes: - Still have changes in ipa-server-install (fewer lines now, though) - Still have the ugly import hack. It is not a high priority for me, i.e. I think it should wait until after alpha - Still need to update 'service' and 'host' plugins to support multiple certificates. (The userCertificate attribute schema itself is multi-valued, so there are no schema issues here) - The TODOs in [1]; mostly certprofile CLI conveniences and supporting multiple profiles for hosts and services (which requires changes to framework only, not schema). [1]: http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress Happy reviewing! I am pleased with the initial cut of the caacl plugin but I'm sure you will find some things to be fixed :) Cheers, Fraser [root@vm-093 ~]# ipa-replica-prepare vm-094.example.com --ip-address 10.34.78.94 Directory Manager (existing master) password: Preparing replica for vm-094.example.com from vm-093.example.com Creating SSL certificate for the Directory Server not well-formed (invalid token): line 2, column 14 I cannot create replica file. It work on the upgraded server, but it doesn't work on the newly installed server. I'm not sure if this causes your patches which modifies the ca-installer, or the newer version of dogtag. Or if there was any other changes in master, I will continue to investigate with new RPM from master branch. Martin^2 ipa-replica-prepare works for: * master branch * master branch + pki-ca 10.2.4-1 So something in your patches is breaking it Martin^2 Martin, master + my patches with pki 10.2.4-1 is working for me on f21 and f22. Can you provide ipa-replica-prepare --debug output and Dogtag debug log? ( /var/log/pki/pki-tomcat/ca/debug ) Thanks, Fraser I can not reproduce it today. And I already recycled the VMs from yesterday. :-( In that case I would suggest ACKingpushing the patch and fixing the bug if it comes again. The tree may now be a bit unstable, given the number of patches going in. My main motivation here is to unblock Fraser. Thanks, Martin Rebased patchset attached; no other changes. Heads up: I just discovered I have introduced a bug with ipa-replica-install, when it is spawning the CA instance. I think replication it only causes issues with ``--setup-ca``. I will try and sort it out tomorrow or later tonight (I have to head out for a few hours now, though); and I'm not suggesting it should block the push but it's something to be aware of. Cheers, Fraser New patchset attached ; haven't gotten to the bottom of the ipa-replica-install issue mentioned above, but it fixes an upgrade bug. The change is: diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py index c288282..c5f4d37 100644 --- a/ipaserver/install/server/upgrade.py +++ b/ipaserver/install/server/upgrade.py @@ -316,7 +316,7 @@ def ca_enable_ldap_profile_subsystem(ca): caconfig.CS_CFG_PATH, directive, separator='=') -if value == 'ProfileSubsystem': +if value == 'com.netscape.cmscore.profile.ProfileSubsystem': needs_update = True break except OSError, e: @@ -328,7 +328,7 @@ def ca_enable_ldap_profile_subsystem(ca): installutils.set_directive( caconfig.CS_CFG_PATH,
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? -- 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 0010] KeyError raised upon replica installation
On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. Simo. -- 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 0010] KeyError raised upon replica installation
On 06/02/2015 06:00 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Simo Sorce wrote: On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. I'm fine to have that too, we rely on it in trusts case so just follow the pattern. Cool! Who will do the work and make sure the group and the members are properly set on installation and upgrades? Petr1, Jan or anyone else? (The group should also move to sysaccounts container with this change). -- 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 0001-0013 v5.1] Profiles and CA ACLs
On 06/02/2015 06:37 PM, Martin Basti wrote: On 02/06/15 14:11, Fraser Tweedale wrote: On Mon, Jun 01, 2015 at 05:22:28PM +1000, Fraser Tweedale wrote: ... 4) * Maybe I do everything wrong :) I'm not able to create certificate stored in FILE, via ipa-getcert request. I'm getting error: status: CA_UNREACHABLE ca-error: Server at https://vm-137.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. vm-137.example@example.com: host not found). or error: Request ID '20150602154115': status: CA_REJECTED ca-error: Server at https://vm-137.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: not allowed to perform this command). (I'm root and kinited as admin) Maybe additional ACI is required for cert_request as it is VirtualCommand Note that even if you run ipa-getcert kinited as root/admin, it asks certmonger to do that job and certmonger works as host/... principal. -- 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 0010] KeyError raised upon replica installation
On 06/02/2015 06:53 PM, Martin Kosek wrote: On 06/02/2015 06:00 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Simo Sorce wrote: On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. I'm fine to have that too, we rely on it in trusts case so just follow the pattern. Cool! Who will do the work and make sure the group and the members are properly set on installation and upgrades? Petr1, Jan or anyone else? (The group should also move to sysaccounts container with this change). I will do it. -- Petr Vobornik -- 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
On 06/02/2015 02:00 AM, Endi Sukma Dewata wrote: Please take a look at the updated patch. On 5/27/2015 12:39 AM, Jan Cholasta wrote: 21) vault_archive is not a retrieve operation, it should be based on LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it does not do anything with LDAP. The same applies to vault_retrieve. The vault_archive does not actually modify the LDAP entry because it stores the data in KRA. It is actually an LDAPRetrieve operation because it needs to get the vault info before it can perform the archival operation. Same thing with vault_retrieve. It is not a LDAPRetrieve operation, because it has different semantics. Please use Command as base class and either use ldap2 for direct LDAP or call vault_show instead of hacking around LDAPRetrieve. It's been changed to inherit from LDAPQuery instead. NACK, it's not a LDAPQuery operation, because it has different semantics. There is more to a command than executing code, so you should use a correct base class. Changed to inherit from Command as requested. Now these commands no longer have a direct access to the vault object (self.obj) although they are accessing vault objects like other vault commands. Also now the vault name argument has to be added explicitly on each command. You can inherit from crud.Retrieve and crud.Update to get self.obj and the argument back. I tried this: class vault_retrieve(Command, crud.Retrieve): and it gave me an error: TypeError: Error when calling the metaclass bases Cannot create a consistent method resolution order (MRO) for bases Retrieve, Command I'm sticking with the original code since it works fine although not ideal. I'm not a Python expert, so if you know how to fix this properly please feel free to post a patch on top of this. If KRA is not installed, vault-archive and vault-retrieve fail with internal error. Added a code to check KRA installation in all vault commands. If you know a way not to load the vault plugin if the KRA is not installed please let me know, that's probably even better. Not sure how that will work on the client side though. The commands still behave differently based on whether they were called from API which was initialized with in_server set to True or False. That is unfortunately a restriction imposed by the framework. In order to guarantee the security, the vault is designed to have separate client and server code. The client code encrypts the secret, the server code forwards the encrypted secret to KRA. To archive a secret into a vault properly, you are supposed to call the client code. If you're calling the server code directly, you are responsible to do your own encryption (i.e. generating session key, nonce, and vault data). If another plugin wants to use vault, it should implement a client code which calls the vault client code to perform the archival from the client side. What is the use case for calling the vault API from the server side anyway? Wouldn't that defeat the purpose of having a vault? If a secret exists on the server side in an unencrypted form doesn't it mean the secret may already have been compromised? There is no point in exposing the session_key, nonce and vault_data options in CLI when their value is always overwritten in forward(). I agree there is no need to expose them in CLI, but in this framework the API also defines the CLI. If there's a way to keep them in the server API but not expose them in the CLI please let me know. Or, if there's a way to define completely separate server API (without a matching client CLI) and client CLI (without a matching server API) that will work too. Will this always succeed? +# deactivate vault record in KRA +response = kra_client.keys.list_keys( +client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE) Yes. If there's no active keys it will return an empty collection. +for key_info in response.key_infos: +kra_client.keys.modify_key_status( +key_info.get_key_id(), +pki.key.KeyClient.KEY_STATUS_INACTIVE) This loop will do nothing given an empty collection. If not, we might get into an inconsistent state, where the vault is deleted in LDAP but still active in KRA. (I'm not sure if this is actually a problem or not.) That can only happen if the server crashes after deleting the vault but before deactivating the key. Regardless, it will not be a problem because the key is identified by vault ID/path so it will not conflict with other vaults, and it will get overwritten if the same vault is recreated again. Hi Endi, Quickly skimming through your patches raised couple questions on my side: 1) Will it be possible to also store plain text password via Vault? It talks about taking in the binary data or the text file, but will it also work with plain user secrets (passwords)? I am talking about use like this: # ipa vault-archive name --user mkosek --data Secret123
