Re: [Freeipa-devel] [PATCH] 892 webui: add mangedby tab to otptoken
On 07/01/2015 06:59 PM, Petr Vobornik wrote: Added managedby_user tab to manage users who can manage the token. https://fedorahosted.org/freeipa/ticket/5003 Nathaniel, I could not reproduce the following part of the ticket: Careful interaction is required here. In the current code, this also creates a bug since all UI created tokens are owned but not managed. When users of these tokens are deleted, their self-created tokens are orphaned rather than deleted. Self-created tokens MUST be both self-owned AND self-managed. The self-created tokens which I created in Web UI as admin or normal user were in both cases managed by the same user who created them. (Once again, this time also reply to the list) The patch itself does what it is supposed to. So ACK from me. However, I have found out that the token's manager is correctly set *only* when it is directly created by the user that should own it. In this case when the manager is not specified, the code works as expected and fill in the logged-in user as manager. However, if e.g. admin creates a token for another user and does not set him as the manager explicitly, the 'managedBy' attribute is not set. -- 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] 0026..0027 #5096 enforce caacl for SAN principals
The attached patches fix:
- a bug that caused caacl false negatives for hosts principals
- #5096 cert-request: enforce caacl for subjectAltName principals
Thanks,
Fraser
From f6d7f8e58a7fcb09261ae18a8722f28da778779c Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Fri, 3 Jul 2015 10:05:40 -0400
Subject: [PATCH 26/27] caacl: fix incorrect construction of HbacRequest for
hosts
The _acl_make_request function is using the 'host/' prefix itself
instead of the hostname after it. Use split_any_principal to do the
splitting correctly, also taking realm into account.
---
ipalib/plugins/caacl.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/ipalib/plugins/caacl.py b/ipalib/plugins/caacl.py
index
6bf39d2330c8999726484e1e9fb44fdb7c755767..247d6df143aef1fba9f0ee74a9f7d8386bef5180
100644
--- a/ipalib/plugins/caacl.py
+++ b/ipalib/plugins/caacl.py
@@ -55,13 +55,15 @@ register = Registry()
def _acl_make_request(principal_type, principal, ca_ref, profile_id):
Construct HBAC request for the given principal, CA and profile
+service, name, realm = split_any_principal(principal)
+
req = pyhbac.HbacRequest()
req.targethost.name = ca_ref
req.service.name = profile_id
if principal_type == 'user':
req.user.name = principal
elif principal_type == 'host':
-req.user.name = principal[:5] # strip 'host/'
+req.user.name = name
elif principal_type == 'service':
req.user.name = normalize_principal(principal)
groups = []
@@ -70,8 +72,7 @@ def _acl_make_request(principal_type, principal, ca_ref,
profile_id):
groups = user_obj.get('memberof_group', [])
groups += user_obj.get('memberofindirect_group', [])
elif principal_type == 'host':
-service, hostname, realm = split_any_principal(principal)
-host_obj = api.Command.host_show(hostname)['result']
+host_obj = api.Command.host_show(name)['result']
groups = host_obj.get('memberof_hostgroup', [])
groups += host_obj.get('memberofindirect_hostgroup', [])
req.user.groups = sorted(set(groups))
--
2.1.0
From c39c0f122310f070997c058aefc5617ca75a7ff2 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Fri, 3 Jul 2015 10:15:19 -0400
Subject: [PATCH 27/27] cert-request: enforce caacl for principals in SAN
cert-request currently does not enforce caacls for principals
included in the subjectAltName requestExtension. Enforce for any
dNSName values recognised as hosts/services known to FreeIPA.
Fixes: https://fedorahosted.org/freeipa/ticket/5096
---
ipalib/plugins/cert.py | 42 +-
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py
index
1878e5ad5f80fa93e1a77b0a88711c1da0016681..743fb4d3930f051c4a2098128b09b241a844cb43
100644
--- a/ipalib/plugins/cert.py
+++ b/ipalib/plugins/cert.py
@@ -220,6 +220,22 @@ def ca_enabled_check():
if not api.Command.ca_is_enabled()['result']:
raise errors.NotFound(reason=_('CA is not configured'))
+def caacl_check(principal_type, principal_string, ca, profile_id):
+principal_type_map = {USER: 'user', HOST: 'host', SERVICE: 'service'}
+if not ipalib.plugins.caacl.acl_evaluate(
+principal_type_map[principal_type],
+principal_string, ca, profile_id):
+raise errors.ACIError(info=_(
+Principal '%(principal)s'
+is not permitted to use CA '%(ca)s'
+with profile '%(profile_id)s' for certificate issuance.
+) % dict(
+principal=principal_string,
+ca=ca or '.',
+profile_id=profile_id
+)
+)
+
@register()
class cert_request(VirtualCommand):
__doc__ = _('Submit a certificate signing request.')
@@ -305,6 +321,7 @@ class cert_request(VirtualCommand):
add = kw.get('add')
request_type = kw.get('request_type')
profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE)
+ca = '.' # top-level CA hardcoded until subca plugin implemented
Access control is partially handled by the ACI titled
@@ -327,21 +344,7 @@ class cert_request(VirtualCommand):
else:
principal_type = SERVICE
-principal_type_map = {USER: 'user', HOST: 'host', SERVICE: 'service'}
-ca = '.' # top-level CA hardcoded until subca plugin implemented
-if not ipalib.plugins.caacl.acl_evaluate(
-principal_type_map[principal_type],
-principal_string, ca, profile_id):
-raise errors.ACIError(info=_(
-Principal '%(principal)s'
-is not permitted to use CA '%(ca)s'
-with profile '%(profile_id)s' for certificate issuance.
-) % dict(
-principal=principal_string,
-
Re: [Freeipa-devel] [PATCH 0046] add option to skip client API version check and proceed at user's own risk
On 07/02/2015 01:58 PM, Martin Babinsky wrote:
First attempt at https://fedorahosted.org/freeipa/ticket/4768
Attaching reworked patch.
--
Martin^3 Babinsky
From 809a63b86f73cc041f28e223187337dd65f8b1fd Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Fri, 3 Jul 2015 12:21:09 +0200
Subject: [PATCH] add option to skip client API version check
This can be either set in IPA config file or specified as
'ipa --skip-version-check [COMMAND]'.
part of https://fedorahosted.org/freeipa/ticket/4768
---
VERSION | 4 ++--
ipalib/cli.py | 1 -
ipalib/constants.py | 4
ipalib/frontend.py | 4 ++--
ipalib/plugable.py | 8 +++-
5 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/VERSION b/VERSION
index 266a04af1a61132637112611b7e86649ff818c2a..043d505c1525cbb4bcea7036292aa8bffbe99711 100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=137
-# Last change: mbabinsk: Commands to manage user/host/service certificates
+IPA_API_VERSION_MINOR=138
+# Last change: mbabinsk: Add option to skip client API version check
diff --git a/ipalib/cli.py b/ipalib/cli.py
index 8515b91ed42fcdb853f8ca1aab14575c38d9bfb3..b260ca65172dab7ba56a23b78c086f49f5c18f70 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -1082,7 +1082,6 @@ class cli(backend.Executioner):
else:
for callback in callbacks:
callback(cmd, kw)
-kw['version'] = API_VERSION
self.load_files(cmd, kw)
return kw
diff --git a/ipalib/constants.py b/ipalib/constants.py
index a062505c349436332d430af4fd29c76d20c85343..53c3106cdd16fef0eba42a70518f7633b3fd95d1 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -188,6 +188,10 @@ DEFAULT_CONFIG = (
# Used when verifying that the API hasn't changed. Not for production.
('validate_api', False),
+# Skip client vs. server API version checking. Can lead to errors/strange
+# behavior when newer clients talk to older servers. Use with caution.
+('skip_version_check', False),
+
#
# The remaining keys are never set from the values here!
#
diff --git a/ipalib/frontend.py b/ipalib/frontend.py
index 81bf6d90b7f4d0b60a1312c4ec3049c63b09512f..3a59838d78f2b67f9eebf6dbb77bb7dac731abfb 100644
--- a/ipalib/frontend.py
+++ b/ipalib/frontend.py
@@ -423,7 +423,7 @@ class Command(HasParam):
version_provided = 'version' in options
if version_provided:
self.verify_client_version(unicode(options['version']))
-else:
+elif self.api.env.in_server or not self.api.env.skip_version_check:
options['version'] = API_VERSION
params = self.args_options_2_params(*args, **options)
self.debug(
@@ -451,7 +451,7 @@ class Command(HasParam):
):
ret['summary'] = self.get_summary_default(ret)
if self.use_output_validation and (self.output or ret is not None):
-self.validate_output(ret, options['version'])
+self.validate_output(ret, options.get('version', API_VERSION))
return ret
def soft_validate(self, values):
diff --git a/ipalib/plugable.py b/ipalib/plugable.py
index 2ce7acfd6c916000923500a1da077f49e68392d1..269d58092b297afae6bf8553ef762da3060acb25 100644
--- a/ipalib/plugable.py
+++ b/ipalib/plugable.py
@@ -484,6 +484,12 @@ class API(ReadOnly):
dest='fallback',
help='Only use the server configured in /etc/ipa/default.conf'
)
+parser.add_option(
+'--skip-version-check',
+action='store_true',
+dest='skip_version_check',
+help=optparse.SUPPRESS_HELP
+)
return parser
@@ -503,7 +509,7 @@ class API(ReadOnly):
pass
overrides[str(key.strip())] = value.strip()
for key in ('conf', 'debug', 'verbose', 'prompt_all', 'interactive',
-'fallback', 'delegate'):
+'fallback', 'delegate', 'skip_version_check'):
value = getattr(options, key, None)
if value is not None:
overrides[key] = value
--
2.4.3
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] CA ACL enforcement when authenticated as root
On Sat, 2015-07-04 at 00:32 +1000, Fraser Tweedale wrote: On Wed, Jul 01, 2015 at 04:06:11PM +1000, Fraser Tweedale wrote: Hi everyone, With the addition of CA ACLs, there are now two levels of permissions checked by the `cert-request' command: - LDAP permission checks. This check is performed against the bind principal; `admin' has permission to write the userCertificate attribute of any principal. - CA ACLs: whether issuing a certificate to a particular principal using a particular profile is permitted. This check is performed against the principal for whom the certificate is being requested, which might or might not be the bind principal. Some questions came up after the recent GSS IdM test day: 1) It was requested to add a caacl rule to allow `admin' to issue a certificite for itself via any profile. This is straightforward, but what are the use cases for the `admin' account issuing certificates to itself? 2) When `admin' (as bind principal) requests a certificate for another principal and there is no CA ACL allowing issuance of a certificate for that principal+profile, the request is currently rejected. Should we change the behaviour to allow `admin' to issue a certificate to any principal, using any profile? (This would be accomplished by skipping CA ACL checks in `cert-request' when authenticated as admin.) (Note, if the answer to (2) is yes, (1) is subsumed.) There should be a group (of which admin will be part of by default) that can do this. It is needed to be able to provide certificates to hosts that respond to multiple names, wildcard names and so on. So, yes. Simo. 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 Ping. Anyone got feels about this? Otherwise a patch will appear implementing (2), because that is a smaller patch :) -- 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 7/1/2015 1:53 AM, Jan Cholasta wrote: I think it would be better to use a new attribute type which inherits from ipaPublicKey (ipaVaultPublicKey?) rather than ipaPublicKey directly for assymetric vault public keys, so that assymetric public key and escrow public key are on the same level and you can still use ipaPublicKey to refer to either one: ipaPublicKey ipaVaultPublicKey ipaEscrowPublicKey OK. To be consistent the parameters need to be renamed too: --vault-public-key and --vault-public-key-file. It doesn't need to, there is no requirement for CLI names to always match attribute names. (Also I don't insist on the name ipaVaultPublicKey, feel free to change it if you want.) It's unchanged for now. In a previous discussion it was advised to reuse the existing attribute type whenever possible. Well, in this discussion, it is not. Escrow public key should also reuse ipaPublicKey, but it can't if you use it for vault public key. By using ipaPublicKey subtypes you can distinguish between the two uses and still use ipaPublicKey to refer to either of them. So what's changed? This is what you said when I posted the same patch six months ago: In this patch I'm adding ipaVaultSalt and ipaVaultPublicKey attribute types to store salt and public key for vault. Are there existing attribute types that I can use instead? I see there's an ipaPublicKey, should I use that and maybe add ipaSalt/ipaEncSalt? Thanks. yes, please re-use existing attributes where possible. Honza What changed is that I now know there is also escrow public key, which I didn't know six months ago. Here's patch #368 to be applied on top of patch #357-5, but see comments below. Could you show me how to use ipaPublicKey to refer to ipaVaultPublicKey and ipaEscrowPublicKey? Under what situation would that be useful? For example for ipaPublicKey searches - if ipaVaultPublicKey and ipaEscrowPublicKey both inherit from ipaPublicKey, then an ipaPublicKey search will look in both ipaVaultPublicKey and ipaEscrowPublicKey. This is not something we actually need right now, but once the schema is done, it can't be fixed and I don't think we should prevent this, especially since we can get it for free. BTW even the core LDAP schema does this, see for example how the cn attribute inherits from the more general name attribute: https://tools.ietf.org/html/rfc4519#section-2.3. I don't think that's how LDAP works. The RFC doesn't say that either. The cn does inherit from name, but if you search for name it won't match/return cn. See queries below: $ ldapsearch -LLL -x -b dc=example,dc=com (cn=Accounting Managers) dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames cn: Accounting Managers ou: groups description: People who can manage accounting entries uniqueMember: cn=Directory Manager $ ldapsearch -LLL -x -b dc=example,dc=com (cn=Accounting Managers) \ name dn: cn=Accounting Managers,ou=Groups,dc=example,dc=com (no cn attribute) $ ldapsearch -LLL -x -b dc=example,dc=com (name=Accounting Managers) (no result) Assuming this is what you meant, which doesn't seem to be working, is there still a valid reason to add a new ipaVaultPublicKey instead of using the existing ipaPublicKey? * CLI options will be identical to client and server API options (i.e. no CLI-only, client-only, or server-only options) Actually, you can create CLI-only options (add include='cli' to the param's kwargs). I need to look at this more closely. If I understand correctly in user_del there are two 'preserve' options, the Bool preserve is for client and server API, and the Flag preserve is for CLI. Wouldn't it be better if they are stored in separate lists (or maybe separate classes)? And it looks like you still need to delete the CLI options explicitly anyway. Well, it would be better if there was no Flag class at all and flags were handled by CLI exclusively, because parameter classes should reflect the data type (bool) and not the presentation (flag). That indicates there should be a separation between client API and the CLI too because, as you see in user_del, they can be different. Does the API.txt actually show the CLI options, the client API options, or the server API options? I only see the Flag preserve, not the Bool preserve. It shows CLI options, see how the API object is initialized in makeapi. Does that mean we're only doing the versioning on the CLI, and not the client API or server API? Suppose there are changes in client or server API that do not appear in API.txt but will affect the XML RPC, it might cause a compatibility problem. I think it just shows how convoluted the CLI, client API, and server API are in this framework. * a plugin will only access one type of data (i.e. LDAP plugin can only access LDAP data) This is not assumed anywhere in the framework, you can access whatever you want, but you can't expect baseldap to do
Re: [Freeipa-devel] [PATCH] 0024..0025 Add missing certprofile features
On Thu, Jul 02, 2015 at 08:12:12PM +1000, Fraser Tweedale wrote:
On Thu, Jul 02, 2015 at 11:23:49AM +0200, Jan Cholasta wrote:
Hi,
Dne 2.7.2015 v 11:15 Fraser Tweedale napsal(a):
Attached patches fix a couple of important gaps in certprofile
plugin:
- Add --out option to export Dogtag profile data to file
https://fedorahosted.org/freeipa/ticket/5091
- Add --file option to update existing profile in Dogtag
https://fedorahosted.org/freeipa/ticket/5093
Just a couple nitpicks:
+takes_options = LDAPUpdate.takes_options + (
+File('file?',
+label=_('File containing profile configuration'),
+cli_name='file',
+flags=('virtual_attribute',),
+),
+)
1) Don't set cli_name if it's the same as name.
2) The virtual_attribute flag is meaningless in Commands.
3) Add include='cli' to denote that the option is specific to CLI (applies
to --out as well).
Honza
--
Jan Cholasta
Thanks, updated patches attached. Interdiff below.
diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py
index 7323565..08a0d1c 100644
--- a/ipalib/plugins/certprofile.py
+++ b/ipalib/plugins/certprofile.py
@@ -185,6 +185,7 @@ class certprofile_show(LDAPRetrieve):
takes_options = LDAPRetrieve.takes_options + (
Str('out?',
doc=_('Write profile configuration to file'),
+include='cli',
),
)
@@ -284,8 +285,7 @@ class certprofile_mod(LDAPUpdate):
takes_options = LDAPUpdate.takes_options + (
File('file?',
label=_('File containing profile configuration'),
-cli_name='file',
-flags=('virtual_attribute',),
+include='cli',
),
)
NACK on patchset v2; does not work (even after makeapi, which I
forgot to include in updated patchset). I keep getting error
``ipa: ERROR: Unknown option: file''. Need to investigate why,
but other patches are taking priority right now.
Here is patchset v3, which is just v1 rebased on latest master.
Thanks,
Fraser
From 258f0cbea42b482871d360c33c252ad173c2b0e0 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Thu, 2 Jul 2015 03:31:31 -0400
Subject: [PATCH 24/25] certprofile: add option to export profile config
Add the `--out=FILENAME' option to `certprofile-show'. When given,
it exports the profile configuration from Dogtag and writes it to
the named file.
Fixes: https://fedorahosted.org/freeipa/ticket/5091
---
API.txt | 3 ++-
VERSION | 4 ++--
ipalib/plugins/certprofile.py | 39 ---
ipaserver/plugins/dogtag.py | 8
4 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/API.txt b/API.txt
index
e226712d3b8f8eda721a906927cd7fac01eac39f..22ae9bb88710366736ee915e6fe6f2f1c09f2449
100644
--- a/API.txt
+++ b/API.txt
@@ -747,9 +747,10 @@ 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: certprofile_show
-args: 1,4,3
+args: 1,5,3
arg: Str('cn', attribute=True, cli_name='id', multivalue=False,
primary_key=True, query=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False,
exclude='webui')
+option: Str('out?')
option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
option: Flag('rights', autofill=True, default=False)
option: Str('version?', exclude='webui')
diff --git a/VERSION b/VERSION
index
266a04af1a61132637112611b7e86649ff818c2a..5827f05a4b6b07afb91bd193ff8d7bdecdcc5f9a
100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=137
-# Last change: mbabinsk: Commands to manage user/host/service certificates
+IPA_API_VERSION_MINOR=138
+# Last change: ftweedal: add certprofile-show --out option
diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py
index
9e1e47e943f5c14a7e7ce418d3fc2d095331a38a..abb62434eee4cb87356da5568b8a1bb12b762f67
100644
--- a/ipalib/plugins/certprofile.py
+++ b/ipalib/plugins/certprofile.py
@@ -5,7 +5,7 @@
import re
from ipalib import api, Bool, File, Str
-from ipalib import output
+from ipalib import output, util
from ipalib.plugable import Registry
from ipalib.plugins.virtual import VirtualCommand
from ipalib.plugins.baseldap import (
@@ -175,9 +175,42 @@ class certprofile_find(LDAPSearch):
class certprofile_show(LDAPRetrieve):
__doc__ = _(Display the properties of a Certificate Profile.)
-def execute(self, *args, **kwargs):
+has_output_params = LDAPRetrieve.has_output_params + (
+Str('config',
+
Re: [Freeipa-devel] my remaining 4.2 tickets
On Fri, Jul 03, 2015 at 08:23:45AM +0200, Martin Kosek wrote: On 07/02/2015 05:58 PM, Jan Cholasta wrote: Hi, Dne 2.7.2015 v 17:18 Fraser Tweedale napsal(a): On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. I haven't looked at this yet. FYI getcert supports setting EKU in the CSR using the -U option for a long time. It also correctly passes the profile to IPA since 0.78. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. On a related note, I think we should also always include kerberos principal name SAN. That would be nice, how difficult is to enable this with certificates FreeIPA issues? It would also let us make easier principal-based queries for Dogtag certificates. Right? We could do it with a new ProfileInput class in Dogtag, possibly (probably) also requiring a new ProfileDefault class, and of course and update of the included profile(s) where we want this behaviour. I have a bolder vision for the future of Dogtag/IPA integration. I have had a some thoughts brewing in my mind for a while, ready to unleash after rhel72 crunch, but oh well, now you are making me reveal my ideas, hopefully not too prematurely :) In the medium-term we want to connect Dogtag (components thereof) to the IPA directory to read and enforce caacls. We also wish to use s4u2proxy to avoid all-powerful RA Agent cert and have Dogtag act with authenticated principal's authority. Since we will be talking to the IPA directory, we can create new profile components that read information directly out of the IPA directory. This will make it much simpler to pull fancy extension data or other information into certificates issued by Dogtag, all defined by profiles. These components can even be shipped as part of FreeIPA, as only FreeIPA-provided profiles would use them, and I believe it is fairly straightforward to tell Dogtag about 3rd-party classes. This gives us agility to include support for pulling data from IPA directory into certificates without depending on Dogtag release cycle. This sort of regime may also make it easier to tackle the desired profile builder feature. Finally, since it is JVM .class files we will be shipping we can write it using FP in Scala ^_^ Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Postponing Topology feature
On 07/03/2015 04:50 PM, Simo Sorce wrote: On Fri, 2015-07-03 at 08:44 +0200, Martin Kosek wrote: Hi all, I had several offline discussions about the Topology feature [1] and what to do with it. Many developers worked pretty hard on making the Topology usable for the upcoming FreeIPA 4.2 release, however, it still misses some of the functionality that would prevent our users from making the best of it. Namely: 1) Dogtag Topology management: https://fedorahosted.org/freeipa/ticket/3053 2) Replica Promotion: https://fedorahosted.org/freeipa/ticket/2888 3) Graphical topology view: https://fedorahosted.org/freeipa/ticket/4286 While 3) is mostly an eye candy, without 1) and 2) the current Topology does not have sufficient value for our users to ship it. Also, there could be upgrade issues when 1) is implemented and we may need to introduce another Domain Level. So what we thought would make most sense for FreeIPA 4.2 is to simply release without Topology functionality and postpone it to next version which could follow FreeIPA 4.2 within 1-2 months. Sorry for the inconvenience, but don't worry - Topology is not going anywhere, it's coming! (Just a bit later and with more bells and whistles) [1] https://fedorahosted.org/freeipa/ticket/4302 -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. +1, I am working on (2) and will like to have a few more weeks to plow along as I am discovering various things that may delay it a little bit. I'll work on (1), did update the ticket with first test, what is currently working and what's missing 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] CA ACL enforcement when authenticated as root
On Wed, Jul 01, 2015 at 04:06:11PM +1000, Fraser Tweedale wrote: Hi everyone, With the addition of CA ACLs, there are now two levels of permissions checked by the `cert-request' command: - LDAP permission checks. This check is performed against the bind principal; `admin' has permission to write the userCertificate attribute of any principal. - CA ACLs: whether issuing a certificate to a particular principal using a particular profile is permitted. This check is performed against the principal for whom the certificate is being requested, which might or might not be the bind principal. Some questions came up after the recent GSS IdM test day: 1) It was requested to add a caacl rule to allow `admin' to issue a certificite for itself via any profile. This is straightforward, but what are the use cases for the `admin' account issuing certificates to itself? 2) When `admin' (as bind principal) requests a certificate for another principal and there is no CA ACL allowing issuance of a certificate for that principal+profile, the request is currently rejected. Should we change the behaviour to allow `admin' to issue a certificate to any principal, using any profile? (This would be accomplished by skipping CA ACL checks in `cert-request' when authenticated as admin.) (Note, if the answer to (2) is yes, (1) is subsumed.) Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code Ping. Anyone got feels about this? Otherwise a patch will appear implementing (2), because that is a smaller patch :) -- 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] Postponing Topology feature
On Fri, 2015-07-03 at 08:44 +0200, Martin Kosek wrote: Hi all, I had several offline discussions about the Topology feature [1] and what to do with it. Many developers worked pretty hard on making the Topology usable for the upcoming FreeIPA 4.2 release, however, it still misses some of the functionality that would prevent our users from making the best of it. Namely: 1) Dogtag Topology management: https://fedorahosted.org/freeipa/ticket/3053 2) Replica Promotion: https://fedorahosted.org/freeipa/ticket/2888 3) Graphical topology view: https://fedorahosted.org/freeipa/ticket/4286 While 3) is mostly an eye candy, without 1) and 2) the current Topology does not have sufficient value for our users to ship it. Also, there could be upgrade issues when 1) is implemented and we may need to introduce another Domain Level. So what we thought would make most sense for FreeIPA 4.2 is to simply release without Topology functionality and postpone it to next version which could follow FreeIPA 4.2 within 1-2 months. Sorry for the inconvenience, but don't worry - Topology is not going anywhere, it's coming! (Just a bit later and with more bells and whistles) [1] https://fedorahosted.org/freeipa/ticket/4302 -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. +1, I am working on (2) and will like to have a few more weeks to plow along as I am discovering various things that may delay it a little bit. 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
Here is the rebased patch for vault access control.
--
Endi S. Dewata
From 6bec99d51552a6415c45d655f95627e341fae44b Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Fri, 17 Oct 2014 12:05:34 -0400
Subject: [PATCH] Added vault access control.
New LDAP ACIs have been added to allow vault owners to manage the
vaults and to allow members to access the vaults. New CLIs have
been added to manage the owner and member list. The LDAP schema
has been updated as well.
https://fedorahosted.org/freeipa/ticket/3872
---
API.txt | 92 ++
VERSION | 4 +-
install/share/60basev3.ldif | 2 +-
install/share/vault.update| 5 ++
ipalib/plugins/vault.py | 122 --
ipatests/test_xmlrpc/test_vault_plugin.py | 27 +--
6 files changed, 224 insertions(+), 28 deletions(-)
diff --git a/API.txt b/API.txt
index
d0ae1b72c2ae445a4e2cc168da5fd53f9a4de56d..c182098fe1017d46f9f7980c7b6891a1031f1068
100644
--- a/API.txt
+++ b/API.txt
@@ -5341,27 +5341,58 @@ option: Flag('raw', autofill=True, cli_name='raw',
default=False, exclude='webui
option: Str('service?')
option: Str('setattr*', cli_name='setattr', exclude='webui')
option: Flag('shared?', autofill=True, default=False)
-option: Str('user?')
+option: Str('username?', cli_name='user')
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_add_internal
-args: 1,10,3
+args: 1,11,3
arg: Str('cn', attribute=True, cli_name='name', maxlength=255,
multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True)
option: Flag('all', autofill=True, cli_name='all', default=False,
exclude='webui')
option: Str('description', attribute=True, cli_name='desc', multivalue=False,
required=False)
option: Bytes('ipavaultpublickey', attribute=True, cli_name='public_key',
multivalue=False, required=False)
option: Bytes('ipavaultsalt', attribute=True, cli_name='salt',
multivalue=False, required=False)
option: Str('ipavaulttype', attribute=True, autofill=True, cli_name='type',
default=u'standard', multivalue=False, required=False)
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
option: Str('service?')
option: Flag('shared?', autofill=True, default=False)
-option: Str('user?')
+option: Str('username?', cli_name='user')
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_add_member
+args: 1,9,3
+arg: Str('cn', attribute=True, cli_name='name', maxlength=255,
multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True,
required=True)
+option: Flag('all', autofill=True, cli_name='all', default=False,
exclude='webui')
+option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
+option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
+option: Str('service?')
+option: Flag('shared?', autofill=True, default=False)
+option: Str('user*', alwaysask=True, cli_name='users', csv=True)
+option: Str('username?', cli_name='user')
+option: Str('version?', exclude='webui')
+output: Output('completed', type 'int', None)
+output: Output('failed', type 'dict', None)
+output: Entry('result', type 'dict', Gettext('A dictionary representing an
LDAP entry', domain='ipa', localedir=None))
+command: vault_add_owner
+args: 1,9,3
+arg: Str('cn', attribute=True, cli_name='name', maxlength=255,
multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True,
required=True)
+option: Flag('all', autofill=True, cli_name='all', default=False,
exclude='webui')
+option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Flag('no_members', autofill=True, default=False, exclude='webui')
+option: Flag('raw', autofill=True, cli_name='raw', default=False,
exclude='webui')
+option: Str('service?')
+option: Flag('shared?', autofill=True, default=False)
+option: Str('user*', alwaysask=True, cli_name='users', csv=True)
+option: Str('username?', cli_name='user')
+option: Str('version?', exclude='webui')
+output: Output('completed', type 'int', None)
+output: Output('failed', type 'dict', None)
+output: Entry('result', type 'dict', Gettext('A dictionary representing an
LDAP entry', domain='ipa', localedir=None))
command: vault_archive
args: 1,10,3
arg: Str('cn', attribute=True, cli_name='name',
Re: [Freeipa-devel] [PATCH 0272] Server upgrade: log more into debug log instead of info log
Hi, Dne 1.7.2015 v 10:34 Martin Basti napsal(a): Update is logging too much info into info log. Patch attached. Works for me, ACK. Pushed to master: 884afb5d38480e23c91ec14876bcf39151a2c2ed -- 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] 886-890 webui: API browser
On 07/02/2015 04:55 PM, Martin Kosek wrote:
On 07/01/2015 04:51 PM, Petr Vobornik wrote:
For those of you who don't want to try the patches:
* https://pvoborni.fedorapeople.org/images/api-user-show.png
* https://pvoborni.fedorapeople.org/images/api-user-add.png
On 07/01/2015 09:35 AM, Martin Kosek wrote:
On 06/30/2015 06:35 PM, Petr Vobornik wrote:
First part of API Browser - displaying the metadata in more consumable way.
Second part, how to use it in different languages will be written as wiki
pages
first.
The browser could be later enhanced with more infos and tooltips.
Patch 886 extends backend to send more metadata.
Patch 887,888,889 are webui fixes and prerequisites
Patch 890 is the API browser
Thanks, this is a very good start. I looked at a VM with the patches and
have
couple usability suggestions:
1) It was hard for me to find where the API Browser is. But IPA Server
looks
as a good tab where it should be though.
could be moved to Help tab when it's introduced. For that we need at least
one more link.
2) I have strong doubts about the Objects tab, this is only
understandable to
users knowledgeable about FreeIPA framework internals. Common API user who
just
want to consume the API and not know about the internals will not know what
this is.
What I would do is make API Browser directly clickable so that it opens
the
Commands tab. This is what most people will use. Other tabs may be stacked
on
the left just like with Staged or Deleted users. For now, I would hide
Objects
as I think it would cause more confusion. If we want to show it, there
should
be some introduction what it is good for and maybe limitation of showed
fields
to only those that has any value for the consumers.
fixed, there is only API Browser and no submenu
3) In Commands tab, we will some more explanatory what the attributes of
Param
needs and probably hide some. For example exclude is not needed for
consumers.
Attributes as follows were kept: label, type, default, default_from, values,
minlength, maxlength, pattern, minvalue, maxvalue, precision, cli_name,
option_group
4) Many attributes have autofill: True. I wonder how usable it is without
knowing the actual default for the attribute. Can we show the default?
default_from now contains list of attrs which are used for the default value,
e.g.:
default value created from: givenname, sn
5) I would hide Output Params all together given we don't have them set up
correctly in FreeIPA framework and they may rather confuse people, with
having
all the HBAC or SUDO with User objects.
Removed from metadata
I may think about it more, there were just my couple first thoughts. Others
may
have different opinions here.
Martin
Other changes:
* cli options are shown with dashes as in CLI
* required and multivalued were changed into tags next to option name.
'flags'
which were shown as the tags are not displayed anymore
updated patches attached.
I like the new version, good job! ACK from my side.
Patchset works fine in my testing.
Two (nitpick) questions:
1.) Should we show objects that have defined no methods or params as
'pkinit'?
2.) Relationships and attirbute members are displayed in rather raw form:
attribute_members:
{member:[user,group],memberindirect:[user,group],memberof:[group,netgroup,role,hbacrule,sudorule],memberofindirect:[group,netgroup,role,hbacrule,sudorule]}
relationships: {member:[Member,,no_],memberindirect:[Indirect
Member,null,no_indirect_],memberof:[Member
Of,in_,not_in_],memberofindirect:[Indirect Member
Of,null,not_in_indirect_]}
Could we maybe special-case these (or introduce a way how to detect and
display a dict of lists as formatted html)? Or are there arguments for
the raw view of the API?
Tomas
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 886-890 webui: API browser
On 07/03/2015 10:06 AM, Tomas Babej wrote:
On 07/02/2015 04:55 PM, Martin Kosek wrote:
On 07/01/2015 04:51 PM, Petr Vobornik wrote:
For those of you who don't want to try the patches:
* https://pvoborni.fedorapeople.org/images/api-user-show.png
* https://pvoborni.fedorapeople.org/images/api-user-add.png
On 07/01/2015 09:35 AM, Martin Kosek wrote:
On 06/30/2015 06:35 PM, Petr Vobornik wrote:
First part of API Browser - displaying the metadata in more consumable
way.
Second part, how to use it in different languages will be written as wiki
pages
first.
The browser could be later enhanced with more infos and tooltips.
Patch 886 extends backend to send more metadata.
Patch 887,888,889 are webui fixes and prerequisites
Patch 890 is the API browser
Thanks, this is a very good start. I looked at a VM with the patches and
have
couple usability suggestions:
1) It was hard for me to find where the API Browser is. But IPA Server
looks
as a good tab where it should be though.
could be moved to Help tab when it's introduced. For that we need at least
one more link.
2) I have strong doubts about the Objects tab, this is only
understandable to
users knowledgeable about FreeIPA framework internals. Common API user who
just
want to consume the API and not know about the internals will not know what
this is.
What I would do is make API Browser directly clickable so that it opens
the
Commands tab. This is what most people will use. Other tabs may be stacked
on
the left just like with Staged or Deleted users. For now, I would hide
Objects
as I think it would cause more confusion. If we want to show it, there
should
be some introduction what it is good for and maybe limitation of showed
fields
to only those that has any value for the consumers.
fixed, there is only API Browser and no submenu
3) In Commands tab, we will some more explanatory what the attributes of
Param
needs and probably hide some. For example exclude is not needed for
consumers.
Attributes as follows were kept: label, type, default, default_from, values,
minlength, maxlength, pattern, minvalue, maxvalue, precision, cli_name,
option_group
4) Many attributes have autofill: True. I wonder how usable it is without
knowing the actual default for the attribute. Can we show the default?
default_from now contains list of attrs which are used for the default
value,
e.g.:
default value created from: givenname, sn
5) I would hide Output Params all together given we don't have them set
up
correctly in FreeIPA framework and they may rather confuse people, with
having
all the HBAC or SUDO with User objects.
Removed from metadata
I may think about it more, there were just my couple first thoughts.
Others may
have different opinions here.
Martin
Other changes:
* cli options are shown with dashes as in CLI
* required and multivalued were changed into tags next to option name.
'flags'
which were shown as the tags are not displayed anymore
updated patches attached.
I like the new version, good job! ACK from my side.
Patchset works fine in my testing.
Two (nitpick) questions:
1.) Should we show objects that have defined no methods or params as
'pkinit'?
2.) Relationships and attirbute members are displayed in rather raw form:
attribute_members:
{member:[user,group],memberindirect:[user,group],memberof:[group,netgroup,role,hbacrule,sudorule],memberofindirect:[group,netgroup,role,hbacrule,sudorule]}
relationships: {member:[Member,,no_],memberindirect:[Indirect
Member,null,no_indirect_],memberof:[Member
Of,in_,not_in_],memberofindirect:[Indirect Member
Of,null,not_in_indirect_]}
Could we maybe special-case these (or introduce a way how to detect and
display a dict of lists as formatted html)? Or are there arguments for
the raw view of the API?
Tomas
On a second thought, I don't think these issues should block this
patchset for now. We can improve/discuss that in 4.2.x.
Pushed to master: 2a976334c2160c91a61fb0c47e7adbbd3150
--
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] my remaining 4.2 tickets
On 07/02/2015 05:58 PM, Jan Cholasta wrote: Hi, Dne 2.7.2015 v 17:18 Fraser Tweedale napsal(a): On Tue, Jun 30, 2015 at 03:46:08PM +0200, Martin Kosek wrote: On 06/30/2015 03:03 PM, Fraser Tweedale wrote: #2915 ipa-getcert does not allow setting specific EKU on certificates Involves certmonger so I will need to do a bit more investigation. If non-trivial to accomplish this with the default profile, now that we have support for multiple profiles it could be done with a separate profile, as long as certmonger passes the profile propertly with `-T' argument. I will follow up on this tomorrow and let you know what I find out. Ok. I was not involved when the ticket was filed, but it does not seem to me as something that should get much priority and your time at this stage. I haven't looked at this yet. FYI getcert supports setting EKU in the CSR using the -U option for a long time. It also correctly passes the profile to IPA since 0.78. #4970 Server certificate profile should always include a Subject Alternate name for the host If a subjectAltName request extension is in CSR, it is checked by `cert-request', and copied onto the final certificate by Dogtag. In the default profile there is currently no other way to specify the SAN. A possible approach to resolve this with the default profile is to update it to include a separate, optional subjectAltName request input, which could be filled in if explicit SAN is not provided in CSR. There are related lines of investigation. Will provide update tomorrow. Ok. I investigated this. My comments are on the ticket: https://fedorahosted.org/freeipa/ticket/4970#comment:7 but in brief: the way our current SAN support is implemented makes this a non-trivial ticket. On a related note, I think we should also always include kerberos principal name SAN. That would be nice, how difficult is to enable this with certificates FreeIPA issues? It would also let us make easier principal-based queries for Dogtag certificates. Right? 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 0054] cermonger: Use private unix socket when DBus SystemBus is not, available.
Dne 2.7.2015 v 14:34 David Kupka napsal(a): On 01/07/15 16:31, David Kupka wrote: Updated patch attached. Client install works, but uninstall does not: # ipa-client-install --uninstall -U certmonger failed to start: Command ''/bin/systemctl' 'start' 'certmonger.service'' returned non-zero exit status 1 certmonger failed to stop tracking certificate: Failed to start certmonger: Timeouted 2015-07-03 02:38:15 [17242] Error reading PIN from /etc/ipa/nssdb/pwdfile.txt: No such file or directory. Failed to start certmonger: Timeouted The patch needs a rebase. -- 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
[Freeipa-devel] Postponing Topology feature
Hi all, I had several offline discussions about the Topology feature [1] and what to do with it. Many developers worked pretty hard on making the Topology usable for the upcoming FreeIPA 4.2 release, however, it still misses some of the functionality that would prevent our users from making the best of it. Namely: 1) Dogtag Topology management: https://fedorahosted.org/freeipa/ticket/3053 2) Replica Promotion: https://fedorahosted.org/freeipa/ticket/2888 3) Graphical topology view: https://fedorahosted.org/freeipa/ticket/4286 While 3) is mostly an eye candy, without 1) and 2) the current Topology does not have sufficient value for our users to ship it. Also, there could be upgrade issues when 1) is implemented and we may need to introduce another Domain Level. So what we thought would make most sense for FreeIPA 4.2 is to simply release without Topology functionality and postpone it to next version which could follow FreeIPA 4.2 within 1-2 months. Sorry for the inconvenience, but don't worry - Topology is not going anywhere, it's coming! (Just a bit later and with more bells and whistles) [1] https://fedorahosted.org/freeipa/ticket/4302 -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- 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 0054] cermonger: Use private unix socket when DBus SystemBus is not, available.
On 07/03/2015 08:41 AM, Jan Cholasta wrote: Dne 2.7.2015 v 14:34 David Kupka napsal(a): On 01/07/15 16:31, David Kupka wrote: Updated patch attached. Client install works, but uninstall does not: # ipa-client-install --uninstall -U certmonger failed to start: Command ''/bin/systemctl' 'start' 'certmonger.service'' returned non-zero exit status 1 certmonger failed to stop tracking certificate: Failed to start certmonger: Timeouted 2015-07-03 02:38:15 [17242] Error reading PIN from /etc/ipa/nssdb/pwdfile.txt: No such file or directory. Failed to start certmonger: Timeouted The patch needs a rebase. Also, Timeouted is not a word, try Timed out instead :-) -- 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] 885 topology: make cn of new segment consistent with topology plugin
On 07/02/2015 07:42 PM, David Kupka wrote: On 30/06/15 16:16, Petr Vobornik wrote: SSIA Works for me, ACK. Pushed to master: 66ea322e7e01266cc916156860b684adb21c618d -- 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] 882 ipa-replica-manage del: relax segment deletement check if, topology is disconnected
On 07/02/2015 07:42 PM, David Kupka wrote: On 30/06/15 16:15, Petr Vobornik wrote: Comment from segment deletion check which describes the patch: Relax check if topology was or is disconnected. Disconnected topology can contain segments with already deleted servers. Check only if segments of servers, which can contact this server, and the deleted server were removed. This code should handle a case where there was a topology with a central node(B): A - B - C, where A is current server. After removal of B, topology will be disconnected and removal of segment B - C won't be replicated back to server A, therefore presence of the segment has to be ignored. part of: https://fedorahosted.org/freeipa/ticket/5072 patch 883 adds 180s timeout to the check and changes check interval from 1s to 2s. Works for me, ACK. Pushed to master: fa4954c35d2742606bf0b865d5a48899aa64de99 -- 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] 884 topologysegment: hide direction and enable options
On 07/02/2015 07:42 PM, David Kupka wrote: On 30/06/15 16:15, Petr Vobornik wrote: These options should not be touched by users yet. https://fedorahosted.org/freeipa/ticket/5061 Works for me, ACK. Pushed to master: 2b8e1caa7bfda5e540a94fe26fbcdbfd0ea68928 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0274] DNS: Check if dns package is installed
On 07/02/2015 02:03 PM, Petr Spacek wrote: On 2.7.2015 13:54, Jan Cholasta wrote: Dne 2.7.2015 v 13:34 Petr Spacek napsal(a): On 2.7.2015 12:57, Tomas Babej wrote: On 07/02/2015 08:50 AM, Petr Spacek wrote: On 1.7.2015 20:29, Tomas Babej wrote: On 07/01/2015 04:45 PM, Petr Spacek wrote: On 1.7.2015 15:32, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4058 Requires patch freeipa-pspacek-0052 ACK I must admit I don't really like wrapping a constant in the method in the TaskNamespace object. We're interested in the constant itself - there's no case I can imagine where the name of the freeipa's dns package will be dynamic. For paths we have BasePathNamespace that contains all the paths, maybe we should introduce something similar for the non-path platform dependent constants? Generally I support this but it seems like a 4.3 material (and out of scope of #4058). We need to finish 4.2 now. Please ACK or NACK ASAP. It's fairly straightforward to introduce a new platform namespace for constants. See attached patch, it implements the namespace and already contains the proper values for the dns package name. The original patch 274 would only need to use: from ipaplatform.constants import constants constants.DNS_PACKAGE_NAME 'freeipa-server-dns' I'm okay with that if Honza or somebody else knowledgable about the whole platform-thingy can ACK this, amend Martin^2's patch 274 and test the whole thing. Unfortunately I do not have time for it myself. If nobody does that please push the original patch (when it's dependency pspacek-0052 gets ACK). I think you are overengineering this a little bit, adding whatever ipaplatform stuff just because of an error message seems rather unnecessary to me. I think changing the error message to Integrated DNS requires 'freeipa-server-dns' package or even Integrated DNS requires IPA DNS server package would be perfectly fine. The message should be as specific as possible but I do not care how it will be implemented. Alright, let's not get stuck. Petr insists on specific message on each platform. Given that package name is platform dependent, I think we should keep it as platform constant, task makes little sense. Given that Martin's not available right now, I'll amend his patches and send the updated version. Tomas -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
