Re: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows

[Niranjan]

Petr Viktorin wrote:
> On 04/06/2016 10:55 AM, Niranjan wrote:
> > Greetings,
> > 
> > For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have 
> > proposed
> > a patch, I think this patch is more of a workaround , than a solution. I 
> > would
> > like to get more inputs on how to use pytest-multihost to execute commands 
> > on Windows. The method i am using requires cygwin with openssh/bash to be
> > installed. 
> 
> Wow. I'm surprised the only problem on Windows is the "set -e".
> 
> Regarding the patch:
> 
> - Why is get_winhost_class needed? I don't see it called anywhere.
> - Similarly, why is host_type needed? Your patch only sets it.
> 
> If run_command of WinHost and Unix hosts are this similar, I would put
> the 'set -e\n' for Unix (and an empty string for Windows) in a class
> attribute named e.g. "command_prelude", use it in run_command, and move
> run_command from Host to BaseHost.
> Would that work, or am I missing something?
yes, that would work. But there are few more suggestions, right now
test_dir is global and for windows test_dir should be set to
~/$ssh_username/username. So can that also be set ?

> 
> 
> -- 
> Petr Viktorin

Regards,
yiranjan


pgp5F277IIbPC.pgp
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Fraser Tweedale]

On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote:
> On 7.4.2016 12:13, Christian Heimes wrote:
> >On 2016-04-07 11:09, Petr Spacek wrote:
> >>On 7.4.2016 08:43, Fraser Tweedale wrote:
> >>>Hi team,
> >>>
> >>>I updated the Sub-CAs design page with more detail for the key
> >>>replication[1].  This part of the design is nearly complete (a large
> >>>patchset is in review over at pki-devel@) but there are various
> >>>options about how to authenticate to Custodia.
> >>>
> >>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
> >>>
> >>>In brief, the options are:
> >>>
> >>>1) authenticate as host principal; install binary setuid
> >>>root:pkiuser to read host keytab and custodia keys.
> >>
> >>Huh, I really do not like this. Host keytab on IPA master is one of the most
> >>sensitive keys we have.
> >>
> >>Maybe gssproxy can be used somehow, but I think it would be better to use
> >>separate key.
> >>
> >>
> >>>2) authenticate as host principal; copy host keytab and custodia
> >>>keys to location readable by pkiuser.
> >>
> >>No, really, do not copy host keytab anywhere.
> >>
> >>
> >>>3) create new principal for pkiuser to use, along with custodia keys
> >>>and keytab in location readable by pkiuser.
> >>>
> >>>I prefer option (1) for reasons outlined in the design page.  The
> >>>design page goes into quite a bit more detail so please review the
> >>>section linked above and get back to me with your thoughts.
> >>
> >>The only downside of (3) using new keys is:
> >>... This approach requires the creation of new principals, and Kerberos
> >>keytabs and Custodia keys for those principals, as part of the
> >>installation/upgrade process.
> >>
> >>Compared with additional SUID binary this seems as safer and easier way to 
> >>go.
> >>FreeIPA installers already create quite a lot of principals and keytabs so
> >>this is well understood task.
> >>
> >>I would do (3).
> >
> >+1 for (3)
> >
> >A SUID binary feels like a dangerous hack.
> 
> +1
> 
OK, (3) it is.  Thanks all for your input.

Now for next question: what should service principal name be?  I
think `dogtag/example@example.com' but am open to other
suggestions, e.g. `pki/...'.

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] [DESIGN] Sub-CAs; authenticating to Custodia

[Simo Sorce]

On Thu, 2016-04-07 at 16:43 +1000, Fraser Tweedale wrote:
> Hi team,
> 
> I updated the Sub-CAs design page with more detail for the key
> replication[1].  This part of the design is nearly complete (a large
> patchset is in review over at pki-devel@) but there are various
> options about how to authenticate to Custodia.
> 
> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
> 
> In brief, the options are:
> 
> 1) authenticate as host principal; install binary setuid
>root:pkiuser to read host keytab and custodia keys.
> 
> 2) authenticate as host principal; copy host keytab and custodia
>keys to location readable by pkiuser.
> 
> 3) create new principal for pkiuser to use, along with custodia keys
>and keytab in location readable by pkiuser.
> 
> I prefer option (1) for reasons outlined in the design page.  The
> design page goes into quite a bit more detail so please review the
> section linked above and get back to me with your thoughts.

I haven't read the whole design completely yet (sorry, busy with some
critical bug), only the Key Replication part.
We are moving toward removing access to the HTTP key from even the IPA
framework, and I would definitely not want to give access to the host
keytab to unprivileged processes.

So I lean very heavily on (3).

Simo. 


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides

[Sumit Bose]

On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote:
> Hi,
> 
> On 1.4.2016 16:53, Tomas Babej wrote:
> >Hi,
> >
> >this extends the user ID overrides with capability to store the user
> >certificate.
> >
> >https://fedorahosted.org/freeipa/ticket/4955
> 
> The preferred way of managing certificates nowadays is using $OBJ-add-cert
> and $OBJ-remove-cert commands, you should add them here as well.
> 
> I would even go as far as not allowing to modify certificates using
> idoverrideuser-mod - in user-mod and host-mod, it's there just for backward
> compatibility, which is not the case here. But I don't have a strong opinion
> on that.
> 
> For consistency with user-find and host-find, the full certificate blob
> should not be shown in idoverrideuser-find. You can do that by setting
> search_display_attributes attribute on the idoverrideuser class
> appropriately.

I tested the current patch with my related patches for SSSD and all is
working as expected.

bye,
Sumit

> 
> Honza
> 
> -- 
> Jan Cholasta
> 
> -- 
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

-- 
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] [TEST][patch-0035] Test replica installed under domain level 0 is functional after domain upgrade

[Oleg Fayans]

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From df2d57707875d37783c51521e3c5562642652a42 Mon Sep 17 00:00:00 2001
From: Oleg Fayans 
Date: Thu, 7 Apr 2016 11:49:44 +0200
Subject: [PATCH] Add test if replica is working after domain upgrade

Corresponds to the testcase described in
http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan#Test_case:
_Replica_created_using_old_workflow_is_functional_after_domain_upgrade
---
 .../test_integration/test_replica_promotion.py | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/ipatests/test_integration/test_replica_promotion.py b/ipatests/test_integration/test_replica_promotion.py
index acae5c924594cc73bf262eeab5f843f252723207..4a8a93656888248ca44a803602d3b912c418ac7f 100644
--- a/ipatests/test_integration/test_replica_promotion.py
+++ b/ipatests/test_integration/test_replica_promotion.py
@@ -349,3 +349,31 @@ class TestProhibitReplicaUninstallation(IntegrationTest):
in result.stdout_text)
 self.replicas[0].run_command(['ipa-server-install', '--uninstall',
   '-U', '--ignore-topology-disconnect'])
+
+
+class TestOldReplicaWorksAfterDomainUpgrade(IntegrationTest):
+"""
+http://www.freeipa.org/page/V4/Replica_Promotion/Test_plan#Test_case:
+_Replica_created_using_old_workflow_is_functional_after_domain_upgrade
+"""
+topology = 'star'
+num_replicas = 1
+domain_level = DOMAIN_LEVEL_0
+
+def test_replica_after_domain_upgrade(self):
+tasks.kinit_admin(self.master)
+tasks.kinit_admin(self.replicas[0])
+self.master.run_command(['ipa', 'user-add', 'testuser',
+ '--first', 'test',
+ '--last', 'user'])
+tasks.wait_for_replication(self.replicas[0].ldap_connect())
+self.master.run_command(['ipa', 'domainlevel-set',
+ str(DOMAIN_LEVEL_1)])
+result = self.replicas[0].run_command(['ipa', 'user-show', 'testuser'])
+assert('User login: testuser' in result.stdout_text), (
+"A testuser was not found on replica after domain upgrade")
+self.replicas[0].run_command(['ipa', 'user-del', 'testuser'])
+tasks.wait_for_replication(self.master.ldap_connect())
+result1 = self.master.run_command(['ipa', 'user-show', 'testuser'],
+  raiseonerr=False)
+assert_error(result1, "testuser: user not found", 2)
-- 
1.8.3.1

-- 
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] [DESIGN] Sub-CAs; authenticating to Custodia

[Jan Cholasta]

On 7.4.2016 12:13, Christian Heimes wrote:

On 2016-04-07 11:09, Petr Spacek wrote:

On 7.4.2016 08:43, Fraser Tweedale wrote:

Hi team,

I updated the Sub-CAs design page with more detail for the key
replication[1].  This part of the design is nearly complete (a large
patchset is in review over at pki-devel@) but there are various
options about how to authenticate to Custodia.

[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication

In brief, the options are:

1) authenticate as host principal; install binary setuid
root:pkiuser to read host keytab and custodia keys.


Huh, I really do not like this. Host keytab on IPA master is one of the most
sensitive keys we have.

Maybe gssproxy can be used somehow, but I think it would be better to use
separate key.



2) authenticate as host principal; copy host keytab and custodia
keys to location readable by pkiuser.


No, really, do not copy host keytab anywhere.



3) create new principal for pkiuser to use, along with custodia keys
and keytab in location readable by pkiuser.

I prefer option (1) for reasons outlined in the design page.  The
design page goes into quite a bit more detail so please review the
section linked above and get back to me with your thoughts.


The only downside of (3) using new keys is:
... This approach requires the creation of new principals, and Kerberos
keytabs and Custodia keys for those principals, as part of the
installation/upgrade process.

Compared with additional SUID binary this seems as safer and easier way to go.
FreeIPA installers already create quite a lot of principals and keytabs so
this is well understood task.

I would do (3).


+1 for (3)

A SUID binary feels like a dangerous hack.


+1

--
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] [DESIGN] Sub-CAs; authenticating to Custodia

[Christian Heimes]

On 2016-04-07 11:09, Petr Spacek wrote:
> On 7.4.2016 08:43, Fraser Tweedale wrote:
>> Hi team,
>>
>> I updated the Sub-CAs design page with more detail for the key
>> replication[1].  This part of the design is nearly complete (a large
>> patchset is in review over at pki-devel@) but there are various
>> options about how to authenticate to Custodia.
>>
>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
>>
>> In brief, the options are:
>>
>> 1) authenticate as host principal; install binary setuid
>>root:pkiuser to read host keytab and custodia keys.
> 
> Huh, I really do not like this. Host keytab on IPA master is one of the most
> sensitive keys we have.
> 
> Maybe gssproxy can be used somehow, but I think it would be better to use
> separate key.
> 
> 
>> 2) authenticate as host principal; copy host keytab and custodia
>>keys to location readable by pkiuser.
> 
> No, really, do not copy host keytab anywhere.
> 
> 
>> 3) create new principal for pkiuser to use, along with custodia keys
>>and keytab in location readable by pkiuser.
>>
>> I prefer option (1) for reasons outlined in the design page.  The
>> design page goes into quite a bit more detail so please review the
>> section linked above and get back to me with your thoughts.
> 
> The only downside of (3) using new keys is:
> ... This approach requires the creation of new principals, and Kerberos
> keytabs and Custodia keys for those principals, as part of the
> installation/upgrade process.
> 
> Compared with additional SUID binary this seems as safer and easier way to go.
> FreeIPA installers already create quite a lot of principals and keytabs so
> this is well understood task.
> 
> I would do (3).

+1 for (3)

A SUID binary feels like a dangerous hack.

Christian




signature.asc
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Petr Spacek]

On 7.4.2016 08:43, Fraser Tweedale wrote:
> Hi team,
> 
> I updated the Sub-CAs design page with more detail for the key
> replication[1].  This part of the design is nearly complete (a large
> patchset is in review over at pki-devel@) but there are various
> options about how to authenticate to Custodia.
> 
> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
> 
> In brief, the options are:
> 
> 1) authenticate as host principal; install binary setuid
>root:pkiuser to read host keytab and custodia keys.

Huh, I really do not like this. Host keytab on IPA master is one of the most
sensitive keys we have.

Maybe gssproxy can be used somehow, but I think it would be better to use
separate key.


> 2) authenticate as host principal; copy host keytab and custodia
>keys to location readable by pkiuser.

No, really, do not copy host keytab anywhere.


> 3) create new principal for pkiuser to use, along with custodia keys
>and keytab in location readable by pkiuser.
> 
> I prefer option (1) for reasons outlined in the design page.  The
> design page goes into quite a bit more detail so please review the
> section linked above and get back to me with your thoughts.

The only downside of (3) using new keys is:
... This approach requires the creation of new principals, and Kerberos
keytabs and Custodia keys for those principals, as part of the
installation/upgrade process.

Compared with additional SUID binary this seems as safer and easier way to go.
FreeIPA installers already create quite a lot of principals and keytabs so
this is well understood task.

I would do (3).

-- 
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] [DESIGN] Server Roles

[Petr Spacek]

On 6.4.2016 16:37, Martin Babinsky wrote:
> On 03/21/2016 09:28 AM, Jan Cholasta wrote:
>> On 17.3.2016 18:16, Martin Babinsky wrote:
>>> Hi list,
>>>
>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP
>>> design document concerning the concept of Server Roles as a
>>> user-friendly abstraction of the services running on IPA masters.
>>>
>>> The main aim of this feature is to provide a higher level interface to
>>> query and manipulate service-related information stored in dirsrv
>>> backend.
>>>
>>> I have not touched the design much from the post-Devconf session, mainly
>>> because there are some points to clarify and agree upon.
>>>
>>> I have the following points to discuss:
>>>
>>> 1.) the design assumes that there is a distinction between roles such as
>>> DNS server, CA, etc. and the more specific sub-roles such as DNSSec key
>>> master, CRL master, etc. Now in the hindsight I think this distinction
>>> is quite artificial and just clutters the interface unnecessarily. We
>>> might implement this kind of hierarchy in the code itself but that is
>>> something the user needs not be aware of.
>>
>> These shouldn't be (sub-)roles at all - they are inherently a
>> one-to-many relationship between the logical services and servers,
>> whereas roles are many-to-many relationship between the logical services
>> and servers. I would rather see them exposed in the global service
>> config, such as:
>>
>> $ ipa dnsconfig-mod --sec-master=ipa12.example.com
>>DNSSEC master: ipa12.example.com
>>
>>>
>>> 2.) I guess the role names should be case insensitive so that users are
>>> not hindered by trying to get the case right.
>>
>> +1
>>
>>>
>>> 3.) Do we need an internal API call which will add all services
>>> belonging to a role to the corresponding master entry? (basically a
>>> 'server_add_role' type of command). Currently, each service instance
>>> adds its own service entry during service installation so we probably do
>>> not need to duplicate this functionality.
>>
>> +1, we don't need more duplicate code.
>>
>>>
>>> That is all I can think of right now. I had many more questions popping
>>> up during this night's bout of insomnia, but they got lost during the
>>> day.
>>
>> How are we going to expose the different states of server roles? They
>> can be:
>>
>> a) available/unavailable (the package providing the role was/was not
>> installed on the server)
>> b) configured/unconfigured (the installer for the role was/was not
>> successfully run on the server, LDAP service entries exist)
>> c) enabled/disabled
>>
>> My preference would be to make server-role commands work on top of
>> available services, like this:
>>
>> # ipa server-role-show $HOSTNAME DNS
>> ipa: ERROR: DNS: server role not found
>>
>> # dnf install freeipa-server-dns
>> ...
>>
>> # ipa server-role-show $HOSTNAME DNS
>>Name: DNS
>>Configured: False
>>Enabled: False
>>
>> # ipa-dns-install
>> ...
>>
>> # ipa server-role-show $HOSTNAME DNS
>>Name: DNS
>>Configured: True
>>Enabled: True
>>
>>>
>>> Do not be afraid to bring up other questions/remarks/comments. This is
>>> my first design documents so I expect them to be plenty.
>>
>> The CLI commands are a little bit self-inconsistent, see any other
>> plugin for how the general layout of arguments should look like.
>>
> 
> I have updated the design page[1] according to the comments gathered in this
> thread and offline discussion with principal reviewer, e.g. Jan.
> 
> Again comments are welcome.
> 
> [1] http://www.freeipa.org/page/V4/Server_Roles

Hi,

I wonder if proposed service list->role and ipaConfigString value->server
attribute mappings will work for DNSSEC key master.

DNS server consist of named-pkcs11 and ipa-dnskeysyncd services.
DNSSEC key master adds opendnssec and ipa-ods-exporter services.

Can this be represented in the described model? I'm not sure.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Fraser Tweedale]

Hi team,

I updated the Sub-CAs design page with more detail for the key
replication[1].  This part of the design is nearly complete (a large
patchset is in review over at pki-devel@) but there are various
options about how to authenticate to Custodia.

[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication

In brief, the options are:

1) authenticate as host principal; install binary setuid
   root:pkiuser to read host keytab and custodia keys.

2) authenticate as host principal; copy host keytab and custodia
   keys to location readable by pkiuser.

3) create new principal for pkiuser to use, along with custodia keys
   and keytab in location readable by pkiuser.

I prefer option (1) for reasons outlined in the design page.  The
design page goes into quite a bit more detail so please review the
section linked above and get back to me with your thoughts.

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