Re: [Freeipa-devel] [PATCH] 276 Fix: Certificate status is not visible in Service and Host page
On 04/26/2013 06:43 PM, Petr Vobornik wrote: https://fedorahosted.org/freeipa/ticket/3593 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers
On 04/26/2013 09:53 PM, Rob Crittenden wrote: A dogtag 9 - 10 upgraded server doesn't provide the RESTful API so therefore the cert-find command doesn't work. Starting with dogtag 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this case so we at least have something to catch. This patch catches a 501 and returns a more specific message. 10.0.2 builds should be available this weekend, or you can pull from their devel repo at: [dogtag-devel] name=Dogtag development $releasever - $basearch baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ enabled=0 gpgcheck=0 With the new Dogtag, /root/.pki/pki-tomcat/ca_admin_cert.p12 is not created. Installation of a new server fails on copying that to /root/ca-agent.p12. Adding Ade to the thread, he should know more. On my instance upgraded from f17 to f18, I get 404 errors, not 501. $ rpm -q pki-base pki-base-10.0.2-1.fc18.noarch $ ./ipa cert-find ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) $ curl -v http://`hostname`:9180/ca/rest/certs/search [...] HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 5723 Date: Sun, 28 Apr 2013 23:08:44 GMT [...] -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1097 Bump nss Requires
On 04/26/2013 06:39 PM, Rob Crittenden wrote: Set minimum version of nss/nss-tools to pick up fix to certutil handling of base64-encoded certificates. We saw pretty reliable failures in F-19 without this. rob ACK -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1097 Bump nss Requires
Petr Viktorin wrote: On 04/26/2013 06:39 PM, Rob Crittenden wrote: Set minimum version of nss/nss-tools to pick up fix to certutil handling of base64-encoded certificates. We saw pretty reliable failures in F-19 without this. rob ACK Pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf
On 04/25/2013 12:42 PM, Martin Kosek wrote:
On 04/25/2013 12:29 PM, Jan Cholasta wrote:
On 25.4.2013 08:51, Martin Kosek wrote:
On 04/24/2013 08:02 PM, Rob Crittenden wrote:
Jan Cholasta wrote:
On 24.4.2013 14:54, Martin Kosek wrote:
On 04/24/2013 02:51 PM, Rob Crittenden wrote:
Jan Cholasta wrote:
Hi,
On 23.4.2013 12:28, Tomas Babej wrote:
Hi,
We should respect already configured options present in
/etc/openldap/ldap.conf when generating our own configuration.
With this patch, we only rewrite URI, BASE and TLS_CACERT
options.
https://fedorahosted.org/freeipa/ticket/3582
the changeConf call will fail when the file does not exist, we
might
want to handle that gracefully.
Honza
We also need to handle the case where these items are already
defined. I'm
honestly not sure what the behavior should be: overwrite, warn and
overwrite,
fail.
rob
I am also thinking that we may want to be more cautious before
updating this
file. AFAIK, we do not need the updated file for our function, its
only updated
for user convenience so that he can run ldapsearches more easily.
I see several options here that could help this goal:
1) Update ldap.conf if BASE and URI and TLS_CACERT only if these
options are
not set. If the options are already set, we could just print a note
that we
skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has
these options
commented out, so it should be possible to implement this check.
2) Do ldap.conf changes only if a new special option is passe (e.g.
--configure-ldap-cong)
3) Do not update ldap.conf when a new special option is not
passed (e.g.
--no-ldap-conf
Martin
If we don't need the file for our function, we can just not
configure it
at all IMO. We can document how to configure it for users who want
it.
It was an RFE that we create this file. It is handy to have
pre-configured, I
like having it actually.
We just need to try to have a gentler touch than my first crack at
it, which
overwrote it completely. I think #1 is probably enough for now. I'm
not sure I
want to add two new options this late in the game, and the client
already has a
lot of knobs.
rob
Yeah, I also agree that 1) is enough. It will not add any more
options and will
let us be more gentle and respectful to already existent custom user
settings
in ldap.conf. So Tomas, this seems like the way to go :-)
Martin
I don't see the point of updating only some of these values. What about
Not some of them - either all of them (BASE, URI, TLS_CACERT) when
none of them is already configured or none at all.
4) Update BASE and URI and TLS_CACERT, comment any old settings out.
?
This would still break an existing user configuration, we would just
tell user what we broke :-)
Martin
Honza
The following version of the patch configures (BASE, URI, TLS_CACERT)
attributes if they are not set.
However, to preserve user-friendliness, our suggested option is added as
an comment. See commit message for details.
Tomas
From 80e70a0a68d64eb9826a8ff4c20330f49aa0d362 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Mon, 22 Apr 2013 12:55:38 +0200
Subject: [PATCH] Preserve already configured options in openldap conf
We should respect already configured options present in
/etc/openldap/ldap.conf when generating our own configuration.
With this patch, we only rewrite URI, BASE and TLS_CACERT options
only if they are not configured. In the case they are, our suggested
configuration is inserted as a comment.
Also adds tab as a delimeter character in /etc/openldap/ldap.conf
https://fedorahosted.org/freeipa/ticket/3582
---
ipa-client/ipa-install/ipa-client-install | 41 +++
ipa-client/ipaclient/ipachangeconf.py | 12 +++--
2 files changed, 41 insertions(+), 12 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 29adc93f3bcb3ccc81c31237af314af0ba61b8c9..c71c5e9b152dca2f66ffb26c3fa6241371666035 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -815,19 +815,38 @@ def configure_nslcd_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server,
def configure_openldap_conf(fstore, cli_basedn, cli_server):
ldapconf = ipaclient.ipachangeconf.IPAChangeConf(IPA Installer)
-ldapconf.setOptionAssignment( )
+ldapconf.setOptionAssignment(( , \t))
-opts = [{'name':'comment', 'type':'comment', 'value':'File modified by ipa-client-install'},
-{'name':'empty', 'type':'empty'},
-{'name':'URI', 'type':'option', 'value':'ldaps://'+ cli_server[0]},
-{'name':'BASE', 'type':'option', 'value':cli_basedn},
-{'name':'TLS_CACERT', 'type':'option', 'value':CACERT},
-{'name':'empty', 'type':'empty'}]
+opts = [{'name':'comment', 'type':'comment',
+'value':'File modified by ipa-client-install'},
+
Re: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts
On 04/26/2013 07:02 PM, Dmitri Pal wrote:
On 04/26/2013 06:47 AM, Petr Viktorin wrote:
On 04/25/2013 06:59 PM, Dmitri Pal wrote:
On 04/25/2013 09:54 AM, Martin Kosek wrote:
On 04/25/2013 12:37 PM, Petr Viktorin wrote:
On 04/23/2013 10:10 AM, Martin Kosek wrote:
This new freeform host attribute will allow provisioning systems
to add custom tags for host objects which can be later used for
in automember rules or for additional local interpretation.
Design page:
http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems
Ticket: https://fedorahosted.org/freeipa/ticket/3583
[...]
Can we use this patch to create a HOWTO on how to add and LDAP attribute
to IPA?
Yes, I can annotate the patch and put it on the wiki. I'll do it once
it's pushed so I can link to it.
I know we're trying to organize the wiki page names. What's the
correct location for a developer-focused HOWTO?
I do not have a preference. Whatever makes sense.
http://www.freeipa.org/page/HowTo/Add_a_new_attribute
Also we have, I suspect a lot of metadata about attributes encoded in
the framework, right?
Why can't we use some kind of the data file(s) for it? This way one can
add attributes dynamically and the framework would pick them up.
It is clear that it would have to be done on all replicas
So we should store it in LDAP and have it replicated.
I am not against it. Files might be an interim step before getting there.
Keep in mind that clients would need the info too.
but still it
would not require people to change the code - only configuration. Have
we ever thought about this?
If you're talking about parameters in the the framework commands, I
think --setattr is fine.
Or is this also about the schema? Web UI?
There are three parts:
a) Schema
b) Code
option: Str('userclass', attribute=True, cli_name='class', multivalue=True,
required=False)
...
option: Str('userclass', attribute=True, autofill=False, cli_name='class',
multivalue=True, query=True, required=False)
...
option: Str('userclass', attribute=True, autofill=False, cli_name='class',
multivalue=True, required=False)
+Str('userclass*',
+cli_name='class',
+label=_('Class'),
+doc=_('Host category (semantics placed on this attribute are for '
+ 'local interpretation)'),
+),
) + ticket_flags_params
+ test
This code can be completely parametarized and values read from the LDAP
or files
Having one definitive list for the framework, UI, and various flags like
default_attributes is the better design, but sadly without much
practical advantage except the configurability.
And the configurability would be limited. Lots of IPA code depends on
our attributes being there, so users would need to only add additional
ones, or risk breaking something. For small things a schema change and
--setattr is enough (except the Web UI needs a way to do setattr too).
If they need to add something big (custom validators, interdependencies
between attributes), they'll need to write code anyway.
c) UI metadata - should be similar to above
Then adding a new field would be equivalent to changing the schema and
adding an entry or two - it is not a a software update per say.
We would need to keep the data version clear rather than in addition to
the hardcoded version in the code
It would be a pretty large change, and it would need to be designed
carefully to deal with replication, clients, data/schema/API versioning,
etc.
Don't get me wrong, I'd love to implement this, but I don't think
there's enough demand/value to justify it.
I filed a RFE: https://fedorahosted.org/freeipa/ticket/3595
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf
Tomas Babej wrote: On 04/25/2013 12:42 PM, Martin Kosek wrote: On 04/25/2013 12:29 PM, Jan Cholasta wrote: On 25.4.2013 08:51, Martin Kosek wrote: On 04/24/2013 08:02 PM, Rob Crittenden wrote: Jan Cholasta wrote: On 24.4.2013 14:54, Martin Kosek wrote: On 04/24/2013 02:51 PM, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 23.4.2013 12:28, Tomas Babej wrote: Hi, We should respect already configured options present in /etc/openldap/ldap.conf when generating our own configuration. With this patch, we only rewrite URI, BASE and TLS_CACERT options. https://fedorahosted.org/freeipa/ticket/3582 the changeConf call will fail when the file does not exist, we might want to handle that gracefully. Honza We also need to handle the case where these items are already defined. I'm honestly not sure what the behavior should be: overwrite, warn and overwrite, fail. rob I am also thinking that we may want to be more cautious before updating this file. AFAIK, we do not need the updated file for our function, its only updated for user convenience so that he can run ldapsearches more easily. I see several options here that could help this goal: 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these options are not set. If the options are already set, we could just print a note that we skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has these options commented out, so it should be possible to implement this check. 2) Do ldap.conf changes only if a new special option is passe (e.g. --configure-ldap-cong) 3) Do not update ldap.conf when a new special option is not passed (e.g. --no-ldap-conf Martin If we don't need the file for our function, we can just not configure it at all IMO. We can document how to configure it for users who want it. It was an RFE that we create this file. It is handy to have pre-configured, I like having it actually. We just need to try to have a gentler touch than my first crack at it, which overwrote it completely. I think #1 is probably enough for now. I'm not sure I want to add two new options this late in the game, and the client already has a lot of knobs. rob Yeah, I also agree that 1) is enough. It will not add any more options and will let us be more gentle and respectful to already existent custom user settings in ldap.conf. So Tomas, this seems like the way to go :-) Martin I don't see the point of updating only some of these values. What about Not some of them - either all of them (BASE, URI, TLS_CACERT) when none of them is already configured or none at all. 4) Update BASE and URI and TLS_CACERT, comment any old settings out. ? This would still break an existing user configuration, we would just tell user what we broke :-) Martin Honza The following version of the patch configures (BASE, URI, TLS_CACERT) attributes if they are not set. However, to preserve user-friendliness, our suggested option is added as an comment. See commit message for details. Tomas Ok, this works as advertised, I just have a general question. This could enable a mix of IPA and non-IPA settings. In my case I left BASE configured and only URI and TLS_CACERT got set. This could cause some unexpected results I think, depending on what got changed. Do we rather want to punt on all of them if any of them can't be updated? This would require a bit more code, and wouldn't be as generic. I just wonder if this would cause subtle failures. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2
Jan Cholasta wrote: On 19.4.2013 19:39, Rob Crittenden wrote: Jan Cholasta wrote: Also, this does not fix SSH integration not working on Fedora 18, as that is caused by backward incompatiblity in openssh-server-6.1p1-6 and later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). FYI this bug was fixed. This seems to work ok. Do we want to do this upgrade as an rpm scriptlet or is it better to handle this in ipa-upgradeconfig (it might be easier to maintain there)? As Martin pointed out, this needs to be done on the client and we don't have client upgrade script yet, hence the scriptlet. In any case, a condrestart of sssd is required to have it pick up the new config. Fixed. Do you know if F-18 will get 6.2? Do we need to consider backporting this to 3.1? It won't, backport is not needed. Updated patch attached. Honza Alexander pointed out that we can use the user nobody to run these commands rather than running as the user who requested it, %u. For the purposes of development, this is going to commit everyone to moving to F-19 now. Is that acceptable or do we want to wrap this with a conditional for some period? rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf
On 04/29/2013 08:13 PM, Rob Crittenden wrote: Tomas Babej wrote: On 04/25/2013 12:42 PM, Martin Kosek wrote: On 04/25/2013 12:29 PM, Jan Cholasta wrote: On 25.4.2013 08:51, Martin Kosek wrote: On 04/24/2013 08:02 PM, Rob Crittenden wrote: Jan Cholasta wrote: On 24.4.2013 14:54, Martin Kosek wrote: On 04/24/2013 02:51 PM, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 23.4.2013 12:28, Tomas Babej wrote: Hi, We should respect already configured options present in /etc/openldap/ldap.conf when generating our own configuration. With this patch, we only rewrite URI, BASE and TLS_CACERT options. https://fedorahosted.org/freeipa/ticket/3582 the changeConf call will fail when the file does not exist, we might want to handle that gracefully. Honza We also need to handle the case where these items are already defined. I'm honestly not sure what the behavior should be: overwrite, warn and overwrite, fail. rob I am also thinking that we may want to be more cautious before updating this file. AFAIK, we do not need the updated file for our function, its only updated for user convenience so that he can run ldapsearches more easily. I see several options here that could help this goal: 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these options are not set. If the options are already set, we could just print a note that we skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has these options commented out, so it should be possible to implement this check. 2) Do ldap.conf changes only if a new special option is passe (e.g. --configure-ldap-cong) 3) Do not update ldap.conf when a new special option is not passed (e.g. --no-ldap-conf Martin If we don't need the file for our function, we can just not configure it at all IMO. We can document how to configure it for users who want it. It was an RFE that we create this file. It is handy to have pre-configured, I like having it actually. We just need to try to have a gentler touch than my first crack at it, which overwrote it completely. I think #1 is probably enough for now. I'm not sure I want to add two new options this late in the game, and the client already has a lot of knobs. rob Yeah, I also agree that 1) is enough. It will not add any more options and will let us be more gentle and respectful to already existent custom user settings in ldap.conf. So Tomas, this seems like the way to go :-) Martin I don't see the point of updating only some of these values. What about Not some of them - either all of them (BASE, URI, TLS_CACERT) when none of them is already configured or none at all. 4) Update BASE and URI and TLS_CACERT, comment any old settings out. ? This would still break an existing user configuration, we would just tell user what we broke :-) Martin Honza The following version of the patch configures (BASE, URI, TLS_CACERT) attributes if they are not set. However, to preserve user-friendliness, our suggested option is added as an comment. See commit message for details. Tomas Ok, this works as advertised, I just have a general question. This could enable a mix of IPA and non-IPA settings. In my case I left BASE configured and only URI and TLS_CACERT got set. This could cause some unexpected results I think, depending on what got changed. Do we rather want to punt on all of them if any of them can't be updated? This would require a bit more code, and wouldn't be as generic. I just wonder if this would cause subtle failures. rob After IRC conversation with Rob, we decided to keep the behaviour, while having it explicitly mentioned in the ldap.conf file. For illustration, the ldap.conf file could look like this: [/etc/openldap/ldap.conf] # File modified by ipa-client-install # We do not want to break your existing configuration, hence: # URI, BASE and TLS_CACERT have been added if they were not set. # In case any of them were set, a comment with trailing note # # modified by IPA note has been inserted. # To use IPA server with openLDAP tools, please comment out your # existing configuration for these options and uncomment the # corresponding lines generated by IPA. # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=ipa,dc=example,dc=com # modified by IPA BASEdc=example,dc=com #URI ldaps://ipa.example.com # modified by IPA URI ldap://ldap.example.com #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts TLS_CACERT /etc/ipa/ca.crt Tomas From 9a41e0d875517be599d6393090b856cd98d8602c Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Mon, 22 Apr 2013 12:55:38 +0200 Subject: [PATCH] Preserve already configured options in openldap conf We should respect already configured options present in /etc/openldap/ldap.conf when generating our own configuration. With this patch, we only rewrite URI, BASE and TLS_CACERT
Re: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers
Petr Viktorin wrote: On 04/26/2013 09:53 PM, Rob Crittenden wrote: A dogtag 9 - 10 upgraded server doesn't provide the RESTful API so therefore the cert-find command doesn't work. Starting with dogtag 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this case so we at least have something to catch. This patch catches a 501 and returns a more specific message. 10.0.2 builds should be available this weekend, or you can pull from their devel repo at: [dogtag-devel] name=Dogtag development $releasever - $basearch baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ enabled=0 gpgcheck=0 With the new Dogtag, /root/.pki/pki-tomcat/ca_admin_cert.p12 is not created. Installation of a new server fails on copying that to /root/ca-agent.p12. Adding Ade to the thread, he should know more. On my instance upgraded from f17 to f18, I get 404 errors, not 501. $ rpm -q pki-base pki-base-10.0.2-1.fc18.noarch $ ./ipa cert-find ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) $ curl -v http://`hostname`:9180/ca/rest/certs/search [...] HTTP/1.1 404 Not Found Server: Apache-Coyote/1.1 Content-Type: text/html Content-Length: 5723 Date: Sun, 28 Apr 2013 23:08:44 GMT [...] This is caused by some syntax errors in the dogtag upgrade script. They are working on a respin. See /var/log/pki/pki-server-upgrade-*.log rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
