[Freeipa-devel] [PATCH] 0268 Allow freeipa-tests to work with older paramiko versions

[Petr Viktorin]

Hello,
Not all systems have the latest python-paramiko available. This patch 
allows the testing framework to run with Paramiko 1.7, as opposed to 
requiring 1.10.


--
Petr³
From 5e99cf12c6b96d6db329e28a9487317b9de94f4b Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Mon, 12 Aug 2013 15:38:32 +0200
Subject: [PATCH] Allow freeipa-tests to work with older paramiko versions

The integration testing framework used Paramiko SFTP files as
context managers. This feature is only available in Paramiko 1.10+.
Use an explicit context manager so that we don't rely on the feature.
---
 freeipa.spec.in   |  5 -
 ipatests/test_integration/host.py | 20 ++--
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 7ee1a87bc3d40132059b571330a2b3d1abab5e9f..b3c5b84b8dfe7efc4fcacbc75eac9439a6cbeb72 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -303,7 +303,7 @@ Requires: python-nose
 Requires: python-paste
 Requires: python-coverage
 Requires: python-polib
-Requires: python-paramiko >= 1.10.1
+Requires: python-paramiko >= 1.7.7
 
 %description tests
 IPA is an integrated solution to provide centrally managed Identity (machine,
@@ -832,6 +832,9 @@ fi
 %endif  # ! %{ONLY_CLIENT}
 
 %changelog
+* Mon Aug 12 2013 Petr Viktorin  - 3.2.99-14
+- Downgrade required version of python-paramiko for the tests subpackage
+
 * Thu Aug 8 2013 Martin Kosek  - 3.2.99-13
 - Require slapi-nis 0.47.7 and sssd 1.11.0-0.1.beta2 required for core
   features of 3.3.0 release
diff --git a/ipatests/test_integration/host.py b/ipatests/test_integration/host.py
index b4c7ffd63c47461036e8aca8cb95e0df937f90eb..1614b5fd3e95052e868a42a35dd75ce78c7a9079 100644
--- a/ipatests/test_integration/host.py
+++ b/ipatests/test_integration/host.py
@@ -23,6 +23,7 @@
 import socket
 import threading
 import subprocess
+from contextlib import contextmanager
 import errno
 
 import paramiko
@@ -118,6 +119,21 @@ def read_stream():
 return thread
 
 
+@contextmanager
+def sftp_open(sftp, filename, mode='r'):
+"""Context manager that provides a file-like object over a SFTP channel
+
+This provides compatibility with older Paramiko versions.
+(In Paramiko 1.10+, file objects from `sftp.open` are directly usable as
+context managers).
+"""
+file = sftp.open(filename, mode)
+try:
+yield file
+finally:
+file.close()
+
+
 class Host(object):
 """Representation of a remote IPA host"""
 def __init__(self, domain, hostname, role, index, ip=None):
@@ -314,13 +330,13 @@ def mkdir_recursive(self, path):
 def get_file_contents(self, filename):
 """Read the named remote file and return the contents as a string"""
 self.log.debug('READ %s', filename)
-with self.sftp.open(filename) as f:
+with sftp_open(self.sftp, filename) as f:
 return f.read()
 
 def put_file_contents(self, filename, contents):
 """Write the given string to the named remote file"""
 self.log.info('WRITE %s', filename)
-with self.sftp.open(filename, 'w') as f:
+with sftp_open(self.sftp, filename, 'w') as f:
 f.write(contents)
 
 def file_exists(self, filename):
-- 
1.8.3.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

[Anthony Messina]

On Monday, August 12, 2013 09:34:19 AM Martin Kosek wrote:
> On 08/09/2013 04:13 PM, Anthony Messina wrote:
> > On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
> >>> Dmitri, Martin and me discussed this proposal in person and the new
> >>> plan is: - Elect one super-master which will handle key generation (as
> >>> we do with special CA certificates)
> >>
> >> 
> >>
> >> I guess we can start this way, but how do you determine which one is 
> >> master ? I do not really like to have all this 'super roles', it's
> >> brittle and admins will be confused which means one day their whole
> >> infrastructure will be down because the keys are expired and all the
> >> clients will refuse to communicate with anything.
> >>
> >> 
> >>
> >> I think it is ok as a first implementation, but I think this *must not* 
> >> be the final state. We can and must do better than this.
> >
> > 
> >
> > I've been "listening in" on the DNSSEC discussion and do not mean to
> > derail the course of this thread, however...
> >
> > 
> >
> >> From a sysadmin's perspective, I agree with Simo's comments insofar as
> >> they
> > 
> > relate to "not all masters being created equal".  Administratively,
> > unequal masters have the potential to create single points of failure
> > which may be difficult to resolve, especially on upgrade between minor
> > versions and between replicas.
> >
> > 
> >
> > Small-time sysadmins like myself who may only run one (maybe two) FreeIPA
> >
> >  instances incur a significant about of trouble when that already limited
> >  resource isn't working properly after some issue with file ownership or 
> >
> > SELinux during a yum upgrade.
> >
> > 
> >
> > In addition, I realize FreeIPA wasn't probably designed with small-ish 
> > installs as the target use case.  But I would argue that since FreeIPA
> > *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it
> > is a viable choice for small-timers (with the only exception being no real
> > way to "back up" an instance without an "always-on" multi-master
> > replica).
> >
> > 
> >
> > As a user who has just completed a "manual" migration/upgrade to F19
> > (after realizing that there really was no way to migrate/upgrade when the
> > original install began on F17 2.1 on bare metal with the split slapd
> > processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA
> > move forward but continue to deliver the above-mentioned services to the
> > small-timers, who, without FreeIPA's unification, would never be able to
> > manage or offer all of those services independently, like the big-timers
> > might be able to.
> >
> > 
> >
> > Thanks.  -A
> 
> Hello Anthony,
> 
> From your post above, I did not understand what is the actual problem with
> FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for
> both small-timers and bigger deployments (sorry for having to undergo the
> manual migration procedure).
> 
> If you see that this is not true in some part of FreeIPA, please comment or
> file tickets/RFEs/Bugzillas which we can process and act on to amend the
> situation.
> 
> Thanks in advance,
> Martin

Martin, I *do* think FreeIPA is an excellent choice for small-time admins, 
especially with the increased effort on improving documentation, the upcoming 
ipa-client-advise tool, and the ipa-backup/restore tools.  I merely wanted to 
state that 1) I agreed with Simo's comments, and point out that 2) unequal 
masters with regard to DNSSEC  has the potential to be a single point of 
failure and an area of concern for small-time admins who may for example, 
already be coping with the, albeit solid, recommendations to run multiple 
concurrent masters in virtualized environments with duplicates of those 
environments available simply for testing upgrades (a fair amount of 
administrative overhead for a small-timer).

In short, I was voicing a sysadmin's opinion that FreeIPA should continue to 
evolve in a way that supports small-time admins as well.  I do not think there 
is a problem with "FreeIPA vs. small-time admins" and am hoping it stays that 
way.

As far as the manual migration...  This was likely an issue with documentation 
and/or release notes: 2.2 said it was ok to upgrade from 2.1, 3.0 said it was 
ok to upgrade from 2.2, etc.  This is likely all true, unless your original 
2.2 was based on a 2.1 with Dogtag9.  At that point in time, I had one FreeIPA 
master on bare metal.  I have since upgraded my infrastructure and "started 
over" to have two FreeIPA masters in VMs hosted on separate machines.  
Hopefully, this amount of redundancy will afford me some upgrade protection 
for the future.

Thanks again.  -A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E


signature.asc
Description: This is a digitally signed message part.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
http

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

[Loris Santamaria]

El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribió:
> On 9.8.2013 15:12, Rob Crittenden wrote:
> > Simo Sorce wrote:
> >> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
> >>> On 23.7.2013 10:55, Petr Spacek wrote:
>  On 19.7.2013 19:55, Simo Sorce wrote:
> > I will reply to the rest of the message later if necessary, still
> > digesting some of your answers, but I wanted to address the following
> > first.
> >
> > On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
> >>
> >> The most important question at the moment is "What can we postpone?
> >> How
> >> fragile it can be for shipping it as part of Fedora 20?" Could we
> >> declare
> >> DNSSEC support as "technology preview"/"don't use it for anything
> >> serious"?
> >
> > Until we figur out proper management in LDAP we will be a bit stuck, esp
> > if we want to consider usin the 'somthing' that stores keys instead of
> > toring them stright in LDAP.
> >
> > So maybe we can start with allowing just one server to do DNSSEC and
> > source keys from files for now ?
> 
>  The problem is that DNSSEC deployment *on single domain* is 'all or 
>  nothing':
>  All DNS servers have to support DNSSEC otherwise the validation on client
>  side
>  can fail randomly.
> 
>  Note that *parent* zone indicates that the particular child zone is 
>  secured
>  with DNSSEC by sending DS (delegation signer) record to the client.
>  Validation
>  will fail if client receives DS record from the parent but no signatures 
>  are
>  present in data from 'child' zone itself.
> 
>  This prevents downgrade (DNSSEC => plain DNS) attacks.
> 
>  As a result, we have only two options: One DNS server with DNSSEC 
>  enabled or
>  arbitrary number DNS servers without DNSSEC, which is very unfortunate.
> 
> > as soon as we have that workign we should also have clearer plans about
> > how we manage keys in LDAP (or elsewhere).
> >>>
> >>> Dmitri, Martin and me discussed this proposal in person and the new plan 
> >>> is:
> >>> - Elect one super-master which will handle key generation (as we do with
> >>> special CA certificates)
> >>
> >> I guess we can start this way, but how do you determine which one is
> >> master ?
> How do we select the 'super-master' for CA certificates? I would re-use the 
> same logic (for now).
> 
> >> I do not really like to have all this 'super roles', it's brittle and
> >> admins will be confused which means one day their whole infrastructure
> >> will be down because the keys are expired and all the clients will
> >> refuse to communicate with anything.
> >
> > AFAIU keys don't expire, rather there is a rollover process. The problem 
> > would
> > be if the server that controlled the rollover went away the keys would never
> > roll, leaving you potentially exposed.
> In DNSSEC it could be a problem. Each signature contains validity interval 
> and 
> validation will fail when it expires. It practically means that DNS will stop 
> working if the keys are not rotated in time. (More keys can co-exists, so the 
> roll-over process can be started e.g. a month before the current key really 
> expires.)
> 
> >> I think it is ok as a first implementation, but I think this *must not*
> >> be the final state. We can and must do better than this.
> I definitely agree. IMHO the basic problem is the same or very similar for 
> DNSSEC key generation & CA certificates, so we should solve both problems at 
> once - one day.
> 
> I mean - we need to coordinate key & cert maintenance between multiple 
> masters 
> somehow - and this will be the common problem for CA & DNSSEC.

You could implement a "protocol" where each master has a day or the week
or the month where it checks if there are any pending keys or CA
certificates to renew and tries to do the job. Next day it is another
master's turn to do the same job and so on.

Every master is identified by an unique nsDS5ReplicaId, which could be
used as a vector to generate an ordered list of masters. If you have
masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with
nsDS5ReplicaId 5 is master number one, the next is master number two and
so on.

On first day of the month it is master number one's turn to check of any
pending key and CA certificate renewal issues and to do the renewal. On
second day of the month it is master number two's turn to do the same.
So if a master was down the job will be done next day by the next
master.

The cicle will repeat every "number of master" days, in the example
every four days. 


-- 
Loris Santamaria   linux user #70506   xmpp:lo...@lgs.com.ve
Links Global Services, C.A.http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:1...@lgs.com.ve

"If I'd asked my customers what they wanted, they'd have said
a faste

Re: [Freeipa-devel] [PATCH] 0267 Update translations

[Petr Viktorin]

On 08/02/2013 05:10 PM, Jérôme Fenal wrote:

2013/8/2 Petr Viktorin mailto:pvikt...@redhat.com>>

On 08/02/2013 04:25 PM, Petr Viktorin wrote:

Hello,
I've prepared a patch with fresh translations pulled from Transifex.
As usual the patch is pretty large; please download it from:
https://github.com/encukou/__freeipa/compare/translations.__patch 


Thank you to all translators!

This time the patch also updates the Transifex URL in our config
file;
the old .net URL is still redirecting to the new .com, but its
certificate has expired.


In other news, I've set up a repo to archive the Transifex
translations,
and a cron job to update it periodically. The repo can be found at:
https://github.com/encukou/__freeipa-translations

With this in place, there should be less fear of pushing source
strings
to Transifex.
If you want to keep your own archive; my cron job goes like this:
  make
  git add po
  git commit -m"Update translations (automatic commit)"
  git push origin master


In yet other news, the ticket to split long __doc__ strings is
scheduled
for the IPA 3.4. This time it's getting in :)
https://fedorahosted.org/__freeipa/ticket/3587



The IPA team doesn't have anyone who can check translations, so
self-ACK, pushed to master: 5d141bd39cb99f2c2e16b61bcc4e06b734bbab04


Great!

Were the __doc__ strings splitted as well?


Not yet, it's planned for the next release (3.4). I'm sorry if that 
wasn't clear.



Or are they splitted on double \n at string extraction time?


The plan is to split them directly in the source; the extraction process 
isn't too flexible.


I think it would be best to only split them when they're first changed, 
so the existing translations aren't disturbed.



--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

[Martin Kosek]

On 08/09/2013 04:13 PM, Anthony Messina wrote:
> On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
>>> Dmitri, Martin and me discussed this proposal in person and the new
>>> plan is: - Elect one super-master which will handle key generation (as
>>> we do with special CA certificates)
>> 
>> I guess we can start this way, but how do you determine which one is 
>> master ? I do not really like to have all this 'super roles', it's
>> brittle and admins will be confused which means one day their whole
>> infrastructure will be down because the keys are expired and all the
>> clients will refuse to communicate with anything.
>> 
>> I think it is ok as a first implementation, but I think this *must not* 
>> be the final state. We can and must do better than this.
> 
> I've been "listening in" on the DNSSEC discussion and do not mean to
> derail the course of this thread, however...
> 
>> From a sysadmin's perspective, I agree with Simo's comments insofar as
>> they
> relate to "not all masters being created equal".  Administratively,
> unequal masters have the potential to create single points of failure
> which may be difficult to resolve, especially on upgrade between minor
> versions and between replicas.
> 
> Small-time sysadmins like myself who may only run one (maybe two) FreeIPA
>  instances incur a significant about of trouble when that already limited
>  resource isn't working properly after some issue with file ownership or 
> SELinux during a yum upgrade.
> 
> In addition, I realize FreeIPA wasn't probably designed with small-ish 
> installs as the target use case.  But I would argue that since FreeIPA
> *is* so unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it
> is a viable choice for small-timers (with the only exception being no real
> way to "back up" an instance without an "always-on" multi-master
> replica).
> 
> As a user who has just completed a "manual" migration/upgrade to F19
> (after realizing that there really was no way to migrate/upgrade when the
> original install began on F17 2.1 on bare metal with the split slapd
> processes and Dogtag 9, through F18, to F19), I would like to see FreeIPA
> move forward but continue to deliver the above-mentioned services to the
> small-timers, who, without FreeIPA's unification, would never be able to
> manage or offer all of those services independently, like the big-timers
> might be able to.
> 
> Thanks.  -A

Hello Anthony,

>From your post above, I did not understand what is the actual problem with
FreeIPA vs. small-time admins. I personally think that FreeIPA is usable for
both small-timers and bigger deployments (sorry for having to undergo the
manual migration procedure).

If you see that this is not true in some part of FreeIPA, please comment or
file tickets/RFEs/Bugzillas which we can process and act on to amend the
situation.

Thanks in advance,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [Freeipa-interest] Announcing FreeIPA 3.3.0

[Ellen Newlands]

Congrats team, this is a very nice list of new features.
On Aug 8, 2013, at 10:03 AM, Martin Kosek  wrote:

> The FreeIPA team is proud to announce FreeIPA v3.3.0!
> 
> It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19
> builds are already on their way to updates-testing repo.
> 
> == Highlights in 3.3.0  ==
> === New features for 3.3 ===
> * Active Directory integration:
> ** Support of externally defined POSIX attributes for Active Directory trusted
> domains
> ** Automatic discovery of Active Directory identity mapping configuration
> ** Support of trusted domain users for legacy clients
> ** Identity mapping for AD users can now be delegated
> * Performance improvements in processing large number of users and groups
> * Automated integration testing infrastructure
> * ipa-advise utility is added to generate client setup advice based on  an IPA
> master configuration
> * FreeIPA-specific SELinux policies has been merged to the main SELinux policy
> in Fedora 19
> * SSSD 1.11 is required
> 
> === Active Directory integration ===
> Starting with FreeIPA 3.3, it is possible to define identity ranges for a
> trusted Active Directory domain that rely on POSIX attributes provided by AD 
> DC
> instead of generating them out of corresponding security identifiers. This
> functionality requires Services for Unix (SFU) or Identity Management for UNIX
> enabled on Active Directory side and is provided mostly to aid with migration
> to SID-based mapping.
> 
> In order to support externally defined POSIX attributes, identity ranges have
> been extended to support new range types:
> * AD trust with SID-based mapping: 'ipa-ad-trust' (default)
> * SFU support: 'ipa-ad-trust-posix'
> 
> 'ipa-ad-trust-posix' range type is activated when range discovery finds out 
> SFU
> is in use by Active Directory domain. To override automatic detection,
> --range-type=ipa-ad-trust can be specified to 'ipa trust-add' command.
> 
> FreeIPA 3.3 requires SSSD 1.11 on the IPA master in order to support 
> externally
> defined POSIX attributes in AD.
> 
> More details: 
> http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD
> 
> FreeIPA 3.3 provides a new way to enable legacy clients to support trusted
> domain users. A compatibility tree, provided by slapi-nis, can now be
> configured to look up trusted domain users and handle authentication for them.
> This functionality relies on SSSD 1.11 and release 0.47.7 of slapi-nis. One 
> can
> enable legacy clients support by running ipa-adtrust-install and answering
> positively to the corresponding question.
> 
> More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts
> 
> Finally, SSSD 1.11 is used to query identity information about trusted 
> domains'
> users from within IPA framework, including SID to name and name to SID
> resolution. In addition to speed improvements, FreeIPA 3.3 allows to manage
> mappings for trusted domains' users without requiring elevated privileges of
> 'trust admins'.
> 
> === Performance improvements ===
> When acting on large datasets, FreeIPA now reduces number of potential read
> roundtrips required to update user and group information. When scaled to
> thousands of users and groups, this shortens the time required by certain
> operations tenfold.
> 
> === Automated testing infrastructure ===
> The FreeIPA team has been providing self-testing code for a long time.
> 
> The FreeIPA 3.3 test suite includes a framework for integration tests that
> verify functionality such as replication across several machines. Tests can be
> run manually, or by test automation servers such as Jenkins or Beaker.
> 
> Development builds now create a freeipa-tests RPM containing the test suite 
> and
> related tools. However, as the focus is on testing development code, this
> package will not be released to Fedora yet.
> 
> More details: http://www.freeipa.org/page/V3/Integration_testing
> 
> Additionally, it is now possible to run Web UI tests through the test suite.
> 
> More details: http://www.freeipa.org/page/Web_UI_Integration_Tests
> 
> === IPA advise tool ===
> FreeIPA 3.3 introduces new framework to generate recipes of configuration 
> based
> on how IPA master is configured. These recipes can be taken to the target
> client systems and used there to configure them for a specific task.
> 
> We expect to expand use of 'ipa-advise' tool to cover at least configuration 
> of
> legacy systems in subsequent releases. Three advices are provided with FreeIPA
> 3.3.0 release:
> * configuring a generic Fedora release with authconfig tool
> * configuring RHEL-based systems with SSSD 1.5-1.8
> * configuring Debian-based systems with SSSD 1.5-1.8
> 
> Contributions are always welcome to grow capabilities of 'ipa-advise' tool to
> other areas.
> 
> More details:
> http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement
> 
> === SELinux policy ===
> SELinux policies specifi