Re: [Freeipa-devel] [PATCH] 801-806 webui-ci: otptoken tests
On 05/07/2015 01:38 PM, Petr Vobornik wrote:
On 02/19/2015 03:51 PM, Petr Vobornik wrote:
https://fedorahosted.org/freeipa/ticket/4307
For ipa-4-1 apply:
- patch 800 (different thread)
- patches 801-806
For master apply:
- patch 800 (different thread)
- patch 807 (different thread)
- patch 801-master
- patches 802-806
Patch 801 allows to use ipalib rpc client in Web UI test suite.
Patches 802-805 are various ui_driver fixes to allow stuff in patch 806.
== [PATCH] 806 webui-ci: otptoken tests ==
Basic otptoken Web UI CI coverage.
tests:
* crud for otptokens as admin
* crud for normal users
* checks fields of adder dialog for both token types and user role
(admin/user)
* token actions as admin (enable, disable, delete)
* token actions as normal user (delete)
* login as normal user with hotp and totp token
* sync token hotp and totp token as normal user and then login
https://fedorahosted.org/freeipa/ticket/4307
== [PATCH] 805 webui-ci: allow custom names for disable/enable
actions ==
Not all disable and enable actions are called 'disable' and 'enable'.
== [PATCH] 804 webui-ci: allow to update pkey in post-add in basic-crud
tests ==
== [PATCH] 803 webui-ci: add post_add_action ==
post add action allows to fill autogenerated values, e.g. a pkey of new
otptoken.
This value can be then used in other subsequent test which would depend
on it - like crud tests.
== [PATCH] 802 webui-ci: fix negative visibility check ==
Allow to define, that element doesn't have to be present on a page for
negative visible checks.
E.g. if element is added only if it's displayed and is removed
otherwise.
== [PATCH] 801 webui-ci: support direct IPA API calls ==
Add IPA API support to ui_driver. It leverages new ipalib RPC client's
forms based authentication. It then allows to call an IPA API while
the machine is not an IPA client nor is kerberized.
api's environment values are taken from test configuration and
therefore duplication in ~/.ipa/default.conf is not required.
Since the machine doesn't have to be IPA client, it then also doesn't
have nss database with IPA's CA certificate. Therefore on each API
initialization a new NSS database is created with a CA certificate
downloaded from IPA. This db is deleted in tearDown phase.
Usage:
1. as admin one can immediately call rpc commands, api will be
initialized upon first request and is available under self.api
(assuming self is ui_driver):
self.api.Command.user_del(USER_ID, **{'continue': True})
2. to reconnect as other user:
self.reconnect_api(USER_ID, USER_PW)
3. reconnect back as admin:
self.reconnect_api()
Patch #803 needed rebase.
Hi, thanks for the patches.
Please, fix pep8 complaints in 803, 805 and 806.
Also, change the header in 806 to the shorter version, please.
#
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
#
Patches 801, 802 and 804 look good to me.
The test cases in 806 look good to me as well.
Milan
--
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] Domain Level feature kick-off
On 05/06/2015 09:29 AM, Martin Kosek wrote: Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. the topology plugin also accepts a single numerical value, eg 3. It will internally parse this to 3.0 and use this. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- 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] Domain Level feature kick-off
Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- 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] Domain Level feature kick-off
Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. -- 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] Domain Level feature kick-off
On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) -- 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] Domain Level feature kick-off
On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. Makes sense? [1] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00199.html [2] http://www.redhat.com/archives/freeipa-devel/2014-December/msg00221.html [3] https://fedorahosted.org/freeipa/ticket/5018 [4] http://www.redhat.com/archives/freeipa-devel/2015-April/msg00096.html -- 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] Fwd: [openssl-users] removing Kerberos support from OpenSSL
Yes and no. The current Kerberos support is insecure and should not be used. The main problem is that the session key is reused for all TLS connections. This prevents perfect forward secrecy. That being said, we have been toying around with the idea of making a new standard for GSSAPI/TLS which uses a DH or a PAKE to ensure that both sides contribute entropy to a random encryption key. However, we have to get some of the other standards work off our plates before we can tackle such a large task. In short: existing Kerberos support should be removed from OpenSSL. Nathaniel On Tue, 2015-05-05 at 14:44 +0200, Petr Spacek wrote: Hello! Is this somehow interesting for us? Petr^2 Spacek Forwarded Message Subject: [openssl-users] Kerberos Date: Tue, 05 May 2015 09:21:28 +0100 From: Matt Caswell m...@openssl.org Reply-To: openssl-us...@openssl.org To: openssl-us...@openssl.org, openssl-...@openssl.org I am considering removing Kerberos support from OpenSSL 1.1.0. There are a number of problems with the functionality as it stands, and it seems to me to be a very rarely used feature. I'm interested in hearing any opinions on this (either for or against). Thanks in advance for your input, Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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] Domain Level feature kick-off
On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. +1 for set -- 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] ipa-replica-manage del fails to delete host entry
On 05/06/2015 03:07 PM, Tomas Babej wrote:
On 05/06/2015 02:47 PM, Ludwig Krispenz wrote:
Hi,
in recent posts about corrupted ruvs, there also was the error about failing
cleanup, like:
ipa-replica-manage del vm-162.idm.lab.eng.brq.redhat.com
..
Failed to cleanup vm-162.idm.lab.eng.brq.redhat.com entries: Not allowed on
non-leaf entry
in the access log we see
[06/May/2015:14:19:11 +0200]conn=30 op=17 SRCH
base=cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
scope=2 filter=(objectClass=*) attrs=ALL
[06/May/2015:14:19:11 +0200] conn=30 op=17 RESULT err=0 tag=101 nentries=6
etime=0 notes=U
[06/May/2015:14:19:11 +0200] conn=30 op=18 DEL
dn=cn=vm-162.idm.lab.eng.brq.redhat.com,cn=masters,cn=ipa,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
[06/May/2015:14:19:11 +0200] conn=30 op=18 RESULT err=66 tag=107 nentries=0
etime=0
which means that there was an attempt to remove the host before the services
in replica_cleanup we have:
# delete master entry with all active services
try:
dn = DN(('cn', replica), ('cn', 'masters'), ('cn', 'ipa'),('cn', 'etc'),
self.suffix)
entries = self.conn.get_entries(dn, ldap.SCOPE_SUBTREE)
if entries:
entries.sort(key=len, reverse=True)
for entry in entries:
self.conn.delete_entry(entry)
this intends to delete children befor the parent, as teh dns of children are
longer, but get_entries does return a list of entries, not DNs, and so the
sorting does not work as can be seen in this example:
list = [('123456','A'),('123','B'),('12345678','C')]
list.sort(key=len,reverse=True)
for l in list:
... print l
...
('123456', 'A')
('123', 'B')
('12345678', 'C')
A quick fix would be to use key=lambda x: len(x.dn) then.
Tomas
Thanks. But please link the patch proposal to
https://fedorahosted.org/freeipa/ticket/5019
to not loose track of it.
Thanks,
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] Domain Level feature kick-off
Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. -- 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] Domain Level feature kick-off
Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. +1 for set -- 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] Domain Level feature kick-off
On 11.5.2015 16:36, Martin Kosek wrote: On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. So call it 'functional level' :-) -- 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] Domain Level feature kick-off
Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a): On 05/11/2015 05:42 PM, Petr Spacek wrote: On 11.5.2015 16:36, Martin Kosek wrote: On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. So call it 'functional level' :-) This thread is about implementing the design provided in Simo's domain level design page, we had discussed this before, do we really need to iterate it again ? I don't think anyone is actually suggesting to make changes to the design. Right? -- 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] Fwd: [openssl-users] removing Kerberos support from OpenSSL
Nico Williams has made an interesting proposal on this topic: http://marc.info/?l=openssl-usersm=143136162429551w=2 It is probably worth discussing. On Mon, 2015-05-11 at 10:09 -0400, Nathaniel McCallum wrote: Yes and no. The current Kerberos support is insecure and should not be used. The main problem is that the session key is reused for all TLS connections. This prevents perfect forward secrecy. That being said, we have been toying around with the idea of making a new standard for GSSAPI/TLS which uses a DH or a PAKE to ensure that both sides contribute entropy to a random encryption key. However, we have to get some of the other standards work off our plates before we can tackle such a large task. In short: existing Kerberos support should be removed from OpenSSL. Nathaniel On Tue, 2015-05-05 at 14:44 +0200, Petr Spacek wrote: Hello! Is this somehow interesting for us? Petr^2 Spacek Forwarded Message Subject: [openssl-users] Kerberos Date: Tue, 05 May 2015 09:21:28 +0100 From: Matt Caswell m...@openssl.org Reply-To: openssl-us...@openssl.org To: openssl-us...@openssl.org, openssl-...@openssl.org I am considering removing Kerberos support from OpenSSL 1.1.0. There are a number of problems with the functionality as it stands, and it seems to me to be a very rarely used feature. I'm interested in hearing any opinions on this (either for or against). Thanks in advance for your input, Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 0031] provide a dedicated ccache file to httpd
On Mon, 04 May 2015, Martin Babinsky wrote:
On 04/30/2015 08:23 AM, Alexander Bokovoy wrote:
On Thu, 30 Apr 2015, Jan Cholasta wrote:
Hi,
Dne 29.4.2015 v 19:42 Martin Babinsky napsal(a):
The attached patch is a merge of PATCHES 0031-0032 incorporating Simo's
and Martin's suggestions (see e.g.
https://www.redhat.com/archives/freeipa-devel/2015-April/msg00327.html
for reference).
https://fedorahosted.org/freeipa/ticket/4973
IMHO we should set the environment variable in
/etc/systemd/system/httpd.service, instead of providing a new service
file, because we are just changing configuration, not creating a new
concurrent httpd instance, as is the case with ipa-memcached, and also
not using alternative httpd implementation which masks the current
one, as is the case with bind-pkcs11. It would simplify the whole
thing significantly and it's even recommended in httpd.service to do
I agree.
so:
# For example, to pass additional options (for instance, -D
definitions) to the
# httpd binary at startup, you need to create a file named
# /etc/systemd/system/httpd.service containing:
#.include /lib/systemd/system/httpd.service
#[Service]
#Environment=OPTIONS=-DMY_DEFINE
(BTW I wonder why /etc/sysconfig/httpd support was removed from httpd
in Fedora
(http://pkgs.fedoraproject.org/cgit/httpd.git/commit/?id=0b19f7b6e1a47c6167a8ab43b4a9d1e759b54721),
it seems like a better place to customize environment variables,
rather than having to create a modified service file...)
We had discussion with Joe Orton (httpd maintainer) a while ago and his
arguments were following:
Hi guys, we made that change to adopt what is considered best practice
for systemd. The change is not in RHEL7, only Fedora = 20.
I would not say we are strongly wedded to that change, but the use case
you provide seems very weak. /etc/sysconfig/httpd is intended to be
user-configurable and if users do rm -f /etc/sysconfig/httpd then
Fedora packages should keep working correctly. Can we find a more
robust way to achieve the same results? Why is it required that the
environment variable is set globally within /usr/sbin/httpd?
... [and later in dicussion]
I'd argue that in this case you should not be using httpd.service as-is;
instead it would be correct to create an httpd-ipa.service unit file
or similar, which can .include the system httpd.service, and sets up
the appropriate Environment= (or EnvironmentFile=) directly.
Also, if the intent is to purely to change mod_auth_kerb's interaction
with libkrb5 is there no way to do this via the libkrb API - or
mod_auth_kerb's existing use thereof?
The use of /etc/sysconfig/httpd has historically been a mild PITA and
I'm not seeing a compelling reason to revert the decision to kill it
here.
Anyway, I would prefer if we set it in a way that works on non-systemd
distros as well. Can't we just set GssapiCredStore
ccache:FILE:/var/run/httpd/krbcache/krb5ccache in
/etc/httpd/conf.d/ipa.conf?
It is not just mod_auth_gssapi, it is needed for users of the
credentials obtained by mod_auth_gssapi. mod_auth_gssapi only sets
KRB5CCNAME value when there is delegation of credentials in use and
there is something to delegate.
Ok, attaching updated patches. After the discussion with Martin^1 we
decided to play it safe and put KRB5CCNAME into
/etc/systemd/system/httpd.service.
--
Martin^3 Babinsky
From 6042f4ce093890394da4f6e625d5cc745b285c35 Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Tue, 28 Apr 2015 16:24:02 +0200
Subject: [PATCH] provide dedicated ccache file for httpd
httpd service stores Kerberos credentials in kernel keyring which gets
destroyed and recreated during service install/upgrade, causing problems when
the process is run under SELinux context other than 'unconfined_t'. This patch
enables HTTPInstance to set up a dedicated CCache file for Apache to store
credentials.
https://fedorahosted.org/freeipa/ticket/4973
---
freeipa.spec.in| 4
init/systemd/httpd.service | 4
2 files changed, 8 insertions(+)
create mode 100644 init/systemd/httpd.service
diff --git a/freeipa.spec.in b/freeipa.spec.in
index
608242b5adbc43efbbf0ae30a6d7a933bebc1084..664162fe918f03049c27f70c9e7f852a11c50a8c
100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -12,6 +12,7 @@
%endif
%global plugin_dir %{_libdir}/dirsrv/plugins
+%global etc_systemd_dir %{_sysconfdir}/systemd/system
%global gettext_domain ipa
%if 0%{?rhel}
%global platform_module rhel
@@ -470,8 +471,10 @@ touch
%{buildroot}%{_libdir}/krb5/plugins/libkrb5/winbind_krb5_locator.so
# NOTE: systemd specific section
mkdir -p %{buildroot}%{_unitdir}
+mkdir -p %{buildroot}%{etc_systemd_dir}
install -m 644 init/systemd/ipa.service %{buildroot}%{_unitdir}/ipa.service
install -m 644 init/systemd/ipa_memcached.service
%{buildroot}%{_unitdir}/ipa_memcached.service
+install -m 644 init/systemd/httpd.service
%{buildroot}%{etc_systemd_dir}/httpd.service
# END
mkdir -p
Re: [Freeipa-devel] [PATCH] 0178 Fix AD trusts in Fedora 22
On Fri, 08 May 2015, Alexander Bokovoy wrote: Hi, attached patch fixes issues with Samba 4.2 in Fedora 22. See commit message for the details. Note that you'll also need Samba fixes from https://bugzilla.redhat.com/show_bug.cgi?id=1219832 to test the patch. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1219834 An update is available in Bodhi: https://admin.fedoraproject.org/updates/samba-4.2.1-8.fc22,freeipa-4.1.4-3.fc22 Please test and support. -- / 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] Domain Level feature kick-off
On 05/11/2015 06:44 PM, Jan Cholasta wrote: Dne 11.5.2015 v 18:03 Ludwig Krispenz napsal(a): On 05/11/2015 05:42 PM, Petr Spacek wrote: On 11.5.2015 16:36, Martin Kosek wrote: On 05/11/2015 04:34 PM, Jan Cholasta wrote: Dne 11.5.2015 v 16:29 Petr Vobornik napsal(a): On 05/11/2015 04:13 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:56 Martin Kosek napsal(a): On 05/11/2015 03:50 PM, Jan Cholasta wrote: Dne 11.5.2015 v 15:34 Martin Kosek napsal(a): On 05/11/2015 03:18 PM, Jan Cholasta wrote: Dne 6.5.2015 v 09:29 Martin Kosek napsal(a): Hello, as already discussed in December [1], we will need to implement domain levels in FreeIPA 4.2 to make sure we can manage the replication agreement by Topology plugin. I created a ticket for this feature [3] and linked it with Simo's design. The proposed scope for the feature is written in the ticket itself. Tomas agreed he would work on this. The first consumer is Ludwig's topology plugin. Seeing Ludwig's initial patches [4], I suspect he chose a different format (major/minor) for the domain level value, but as we discussed in [2], it will rather be a numerical value, raised only when needed. This is something for Tomas and Ludwig to coordinate together. I am not sure if Custodia work will need this, maybe the new ipa-replica-install would just check if Custodia is there or not and not decide on Domain Levels... we will see. The design page does not list the actual API, but I expect it to be very simple for now, maybe just $ ipa domainlevel-show $ ipa domainlevel-raise NUMBER I would think $ ipa domain-show $ ipa domain-set-level NUMBER because domain level does not sound like an object, but rather a level property of a domain object. I think the point here was that the Domain Level is a separate LDAP object with just that value. So the naming seemed pretty self-explanatory and consistent to me. That seems to me like an implementation detail rather than something against which to model the API. (Come on, singleton object with a single property?) IIRC, that was the point. To have this value in a single LDAP object without other settings, so that components can simply watch this object or have syncrepl on it, without receiving false positives (as they would have with for example config-* object). OK, so it indeed is just an implementation detail - if it was possible to watch just a single attribute of an entry, it could be stored in more meaningful location, but it's not, so it can't. It is perfectly possible with SyncRepl protocol. With using just domain-* we are blocking ourselves for the time when real Domain object shows up. I don't see why it should. Anyway, I don't have a strong opinion on this, except I like set better than raise. I liked the raise more as it does not give people the hopes that domain level can be lowered once it was raised :-) I like set because it is very explicit - raise not so much, it might mean raise to specific value or raise by specific value and maybe other things. +1 for domainlevel - there is no and most likely won't be a singleton domain object, hence domainlevel is the object. But there is: api.env.basedn aka the suffix. In other words: what domain? I would argue that the feature should be called a realm level because there is only one realm but multiple domains in the realm. That depends on the definition of domain :-) But I think realm level does indeed fit better in our Kerberos-centric world. Maybe. But we try to hide Kerberos specifics... I think the idea was to make it sound similar to AD's Domain Functional Level. So call it 'functional level' :-) This thread is about implementing the design provided in Simo's domain level design page, we had discussed this before, do we really need to iterate it again ? I don't think anyone is actually suggesting to make changes to the design. Right? well, the design all over talks about domain levels, the entry is specified as cn=domainlevel, so the discussion is questioning the design -- 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 0231-0232] Server Upgrade: support base64 encoded values in update files + remove CSV
Dne 7.5.2015 v 19:54 Martin Basti napsal(a): On 07/05/15 11:09, Martin Basti wrote: On 06/05/15 13:17, Martin Basti wrote: On 29/04/15 10:07, Jan Cholasta wrote: Dne 27.4.2015 v 16:46 Martin Basti napsal(a): On 27/04/15 13:05, Martin Basti wrote: On 23/04/15 13:06, Martin Basti wrote: On 16/04/15 17:14, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/4984 I had to remove CSV (which is evil) to be able fix this ticket. Patches attached. Updated patches attached. -- Martin Basti Rebased patches attached. -- Martin Basti rebased patches attached -- Martin Basti ACK on patch 231. BTW I have found a 7 year old bug caused by CSV while reviewing it: https://fedorahosted.org/freeipa/ticket/5007. There is also similar git-only bug in install/updates/10-uniqueness.update: default:uniqueness-subtrees: 'cn=accounts,$SUFFIX' default:uniqueness-subtrees: 'cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX' but your patch fixes it. I will review patch 232 later. Honza Honza doesn't like original 232 so much. Updated patch 232 attached Updated patch 232 attached -- Martin Basti Updated patches attached. -- Martin Basti ACK. Pushed to master: 520bbd001b68bc51a79c2b4a9684fb1c12a582cd -- 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
