[Freeipa-devel] Re: [Freeipa-users] Re: Renewing /etc/httpd/alias certs

[Fraser Tweedale via FreeIPA-devel]

On Wed, Aug 02, 2017 at 09:59:35AM -0400, Rob Crittenden wrote:
> Petr Vobornik via FreeIPA-devel wrote:
> > On Wed, Aug 2, 2017 at 3:30 AM, Fraser Tweedale  wrote:
> >> Hi devs,
> >>
> >> This is at least the second time recently that people needing to
> >> renew service certificates used ``ipa-cacert-manage renew`` (the
> >> wrong command) and either didn't solve the problem or got into a
> >> deeper mess.
> >>
> >> Clearly we have a usability problem here.
> >>
> >> The ipa-cacert-manage(1) man page is clear, but perhaps could use a
> >> prominent statement that it doesn't renew service certs and if
> >> that's all the user needs to do, to use `getcert resubmit` instead.
> > 
> > Right, I think that a lot of people don't understand certificates well
> > and so they don't distinguish CA cert and other cert. So when they see
> > a howto for "CA certificate renewal" they understand "certificate
> > renewal".
> > 
> > From that perspective another possible culprit is also page:
> >   https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
> > 
> >>
> >> But I think better would be to enhance `ipa-cacert-manage renew` to
> >> inspect the current CA certificate and if it has, say, more than 75%
> >> of its validity period still to go, to PROMPT the user to confirm
> >> that renewing the *CA* certificate is really what they wanted to do.
> >>
> >> What do others think of this idea?
> > 
> > I like the idea.
> 
> Honestly, I'd be even harsher. IMHO this is one of those times that
> requires:
> 
> Are you sure? (yes/NO)
> 
> Are you really sure? (yes/NO)
> 
> Really, you want to renew the CA certificate and not some other
> certificate? This is not something to be done lightly? (yes/NO)
> 
> 
> 
> rob
>
OK, I've filed tickets:

- https://pagure.io/freeipa/issue/7084 (update command with prompts)
- https://pagure.io/freeipa/issue/7085 (manpage)

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [Freeipa-users] Re: Renewing /etc/httpd/alias certs

[Fraser Tweedale via FreeIPA-devel]

Hi devs,

This is at least the second time recently that people needing to
renew service certificates used ``ipa-cacert-manage renew`` (the
wrong command) and either didn't solve the problem or got into a
deeper mess.

Clearly we have a usability problem here.

The ipa-cacert-manage(1) man page is clear, but perhaps could use a
prominent statement that it doesn't renew service certs and if
that's all the user needs to do, to use `getcert resubmit` instead.

But I think better would be to enhance `ipa-cacert-manage renew` to
inspect the current CA certificate and if it has, say, more than 75%
of its validity period still to go, to PROMPT the user to confirm
that renewing the *CA* certificate is really what they wanted to do.

What do others think of this idea?

Cheers,
Fraser

On Tue, Aug 01, 2017 at 05:22:53PM +0200, Florence Blanc-Renaud via 
FreeIPA-users wrote:
> On 08/01/2017 03:50 PM, Jason B. Nance via FreeIPA-users wrote:
> > Hello everyone,
> > 
> > I'm running FreeIPA 4.4 (as shipped with current CentOS 7).  I had a series 
> > of unfortunate events which resulted in the entire cluster being offline 
> > for a matter of a couple weeks during which the certificate in 
> > /etc/httpd/alias expired.  I rolled back the clocks on all of the servers 
> > in the cluster and started them successfully, however, the certificates in 
> > /etc/httpd/alias did not get renewed.  Is there a process that 
> > automatically handles this or was I supposed to be maintaining that?
> > 
> > Additionally, based on:
> > 
> > https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
> > 
> > ...I ran "ipa-cacert-manage renew" on my CA in a hope that that would 
> > trigger renewals across the boards, but now it appears that only the CA was 
> > updated as none of the server certificates were re-issued and are now all 
> > untrusted (I can't do "kinit admin" any longer as my realm is now down).  
> > Is there any chance of rolling that back or issuing new certs to get things 
> > going again?
> > 
> Hi,
> 
> ipa-cacert-manage will only renew IPA CA certificate, not the LDAP or HTTP
> server certificates.
> When IPA is using an embedded CA, the LDAP and HTTP server certificates
> should be automatically renewed thanks to certmonger. If the automatic
> renewal did not happen, you can check:
> - if the certificates are indeed tracked by certmonger
>   sudo getcert list -n Server-Cert
>   The tool should output one cert for HTTP (in /etc/httpd/alias) and one for
> LDAP (in /etc/dirsrv/slapd-DOM...). If the certs are not tracked, you need
> to use getcert start-tracking to track them.
> - if they are tracked but not renewed, check the journal for certmonger
> messages. Certmonger should log a message when a certificate is nearing its
> expiration, and another message when the renewal succeeded.
> 
> When the certificates are expired, the method is to stop ntpd, go back in
> time to a date where the certs were still valid, then manually trigger the
> renewal using getcert resubmit -i . In case of errors, examine the
> journal logs and try to fix the issue, then relaunch getcert resubmit. Once
> the renewal succeeds, getcert list shows the cert status as MONITORING and
> you can restart ntpd.
> 
> This blog [1] provides a few examples of issues and their resolution
> 
> HTH,
> Flo
> 
> [1] 
> https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger-issues-with-freeipa/
> 
> > If I have to start over, that is certainly an option.  I'm just trying to 
> > get a better understanding of what I should have been doing to avoid this 
> > situation in the first place.
> > 
> > Thanks,
> > 
> > j
> > ___
> > FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> > 
> ___
> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [DESIGN] Certificate profile update mechanism

[Fraser Tweedale via FreeIPA-devel]

On Mon, Jul 10, 2017 at 12:44:40PM +0200, Tomas Krizek wrote:
> On 07/10/2017 12:16 PM, Simo Sorce via FreeIPA-devel wrote:
> > Hi Fraser,
> > I think you put on a reasonable proposal, however If I had to design
> > this right now and had the freedom to change dogtag and the rest of
> > freeipa to cope I would do the following:
> >
> > - Change the LDAP profile storage to have versioned subtrees for
> > "system" profiles, and have a "custom" subtree for user profiles.
> >
> > - In the base tree have a version attribute that set what version
> > dogtag should use, if absent dogtag will assume its current hardcoded
> > default version. Profiles are never updated per se, a new version is
> > installed and the version is upped.
> >
> > - On upgrade a modified profile is moved to the "custom" tree and the
> > original version of the profile is stored in the system tree. This is
> > assuming this does not cause older versions of dogtag to misbehave,
> > otherwise we keep the modified version and make sure not to raise the
> > version to use. We also find a way to notify the admin he should move
> > customized profiles in the correct new section and leave system
> > profiles alone.
> >
> > - Potentially if a dogtag server does not understand a new version, it
> > keeps using an older version (perhaps we can have a "mandatory version
> > attribute" to cause older versions to return an error instead. (see
> > also previous case)
> >
> > The reason for this is that having a complex check on ipa versions is
> > potentially fragile as well it adds yet another dimension to the things
> > an admin need to know about to figure out why its domain is not using
> > the "right" profiles.
> > And I think in some cases there is no "conflict" between version
> > profiles only new "optional" attributes you may want to add/support.
> >
> > The other option is to tie the dogtag profiles version to the domain
> > level as well, and only ever use new ones when the whole domain level
> > is upped. This is conditional on newer versions of dogtag being able to
> > use older profile versions without modification in LDAP.
> I'd rather avoid any domain level bumps unless there is serious
> justification for it. Additional domain levels introduce big testing
> overhead.
> > HTH,
> > Simo.
> >
> >
> > On Sat, 2017-07-08 at 15:24 +1000, Fraser Tweedale via FreeIPA-devel
> > wrote:
> >> Hi all,
> >>
> >> I've published a draft design for the profile update mechanism.
> >> This feature is to ensure that we can safely update included
> >> profiles even when we use Dogtag profile components only available
> >> in new versions.
> >>
> >> https://www.freeipa.org/page/V4/Certificate_profile_update_mechanism
> >>
> >> Interested persons, please review the design.  In particular there
> >> are two main questions I would like to discuss:
> >>
> >> 1. We need to store the IPA version in IPA master entries.  What
> >>should be the schema?
> >>
> >>https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
> >> sm#IPA_master_entries
> >>
> >> 2. How should we deal with customised versions of included profiles?
> >>There is a big tradeoff here, of complexity + flexibility vs.
> >>simplicitity + reverting customisations to included profiles (and
> >>preventing them in future).
> >>
> >>https://www.freeipa.org/page/V4/Certificate_profile_update_mechani
> >> sm#Dealing_with_modified_profiles
> >>
> I'm in favor of not supporting customized versions. I'm not sure how
> common it is to customize these profiles among users. Unless it is very
> common, I wouldn't support them to avoid the additional complexity. The
> users always have the option to automate these customizations after
> every server upgrade, if they really require them.
>
I agree - unfortunately we currently allow them so the questions
about how to deal with this remain (even if we transition to
preventing modification of included profiles in future).
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] [RFC] Static type checking for FreeIPA (Mypy)

[Fraser Tweedale via FreeIPA-devel]

Hi team,

At PyCon Australia on the weekend I was reminded of PEP-484 type
hinting** and the Mypy type checker for Python.

With focus of FreeIPA project shifting more towards stability,
quality and maintainability, and with Python 3 porting work nearly
wrapped up, now is the time to think about how we can get more
confidence in our code not just from tests, but from the code
itself.  Static checking of annotated types can help us there, and
Mypy can let us begin to do this when writing new code or
refactoring old code.  Furthermore there is a benefit for IDE-users
where plugins can use type annotations to provide better completion
suggestions, etc.  For an overview of Mypy please see the PyCon AU
talk[1] or the docs[2].

[1] https://www.youtube.com/watch?v=mXfsMDM3LwQ
[2] http://mypy.readthedocs.io/en/latest/index.html

So, what's the plan?  Alongside my other tasks, I'm going to start
looking at how we could use Mypy in FreeIPA CI, and see what it is
like using types in some of the areas I'm familiar with e.g.
ipalib.x509.  Based on my findings I'll update the team on the wins
and challenges and we can decide how to proceed from there.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [RFC] Static type checking for FreeIPA (Mypy)

[Fraser Tweedale via FreeIPA-devel]

On Wed, Aug 09, 2017 at 10:18:33AM +0200, Christian Heimes via FreeIPA-devel 
wrote:
> On 2017-08-08 08:04, Fraser Tweedale via FreeIPA-devel wrote:
> > Hi team,
> > 
> > At PyCon Australia on the weekend I was reminded of PEP-484 type
> > hinting** and the Mypy type checker for Python.
> > 
> > With focus of FreeIPA project shifting more towards stability,
> > quality and maintainability, and with Python 3 porting work nearly
> > wrapped up, now is the time to think about how we can get more
> > confidence in our code not just from tests, but from the code
> > itself.  Static checking of annotated types can help us there, and
> > Mypy can let us begin to do this when writing new code or
> > refactoring old code.  Furthermore there is a benefit for IDE-users
> > where plugins can use type annotations to provide better completion
> > suggestions, etc.  For an overview of Mypy please see the PyCon AU
> > talk[1] or the docs[2].
> > 
> > [1] https://www.youtube.com/watch?v=mXfsMDM3LwQ
> > [2] http://mypy.readthedocs.io/en/latest/index.html
> > 
> > So, what's the plan?  Alongside my other tasks, I'm going to start
> > looking at how we could use Mypy in FreeIPA CI, and see what it is
> > like using types in some of the areas I'm familiar with e.g.
> > ipalib.x509.  Based on my findings I'll update the team on the wins
> > and challenges and we can decide how to proceed from there.
> 
> Felipe ask me about typing and Mypy a couple of weeks ago. It's a good
> idea and we should do it. But I advise against typing information in the
> source code. FreeIPA should use external stub files for two reasons.
> First of all it is required to stay compatible with Python 2. And more
> importantly it's faster. FreeIPA's CLI scripts already take several
> hundred milliseconds to execute. Typing would slow them down even further.
> 
I disagree with using stub files.  Types should be declared where
the functions are defined.  Types are documentation and proximity is
important (for humans).

Fortunately, Mypy supports "type comments" in addition to PEP 3107
function annotations.  Mypy groks them but CPython will treat them
as comments and discard.  This allows us to use type hints with no
runtime cost for the CLI scripts.

> It's rather easy to auto-generate stub files -- assuming you are running
> on Fedora and have all Python 3 dependencies installed:
> 
> $ sudo dnf install python3-mypy
> $ echo "api.bootstrap(ra_plugin='dogtag')" >> ipalib/__init__.py
> $ mkdir out
> $ PYTHONPATH=. stubgen --recursive ipaclient ipalib ipaplatform
> ipapython ipaserver
> 
> The api.bootstrap() call is required. Otherwise stubgen cannot import a
> bunch of plugin files.
> 
Thanks for this additional info.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: add Dogtag 10.4 builds to FreeIPA COPRs

[Fraser Tweedale via FreeIPA-devel]

On Thu, Jun 08, 2017 at 05:13:43PM +0200, Martin Bašti wrote:
> 
> 
> On 08.06.2017 09:08, Martin Bašti via FreeIPA-devel wrote:
> > 
> > 
> > On 08.06.2017 02:43, Fraser Tweedale via FreeIPA-devel wrote:
> > > My PR https://github.com/freeipa/freeipa/pull/859 bumps the pki-core
> > > dependency to >= 10.4.  This patch is intended for master and 4.5
> > > branches.  Could someone with the needed permissions please add
> > > pki-core 10.4 builds for f25 and f26 to the @freeipa/freeipa-master
> > > and @freeipa/freeipa-4.5 COPRs?
> > > 
> > > The latest Dogtag 10.4 builds are available at
> > > https://copr.fedorainfracloud.org/coprs/g/pki/10.4/.
> > > 
> > > Thanks,
> > > Fraser
> > > ___
> > > FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> > > To unsubscribe send an email to
> > > freeipa-devel-le...@lists.fedorahosted.org
> > 
> > Working on it
> > 
> 
> everything should be now in @freeipa/freeipa-master
> 
> freeipa-4-5 is only for released 4.5.x versions of freeipa, your PR is only
> for master.
> 
Thanks.  Here's a PR for ipa-4-5 branch:
https://github.com/freeipa/freeipa/pull/863

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] add Dogtag 10.4 builds to FreeIPA COPRs

[Fraser Tweedale via FreeIPA-devel]

My PR https://github.com/freeipa/freeipa/pull/859 bumps the pki-core
dependency to >= 10.4.  This patch is intended for master and 4.5
branches.  Could someone with the needed permissions please add
pki-core 10.4 builds for f25 and f26 to the @freeipa/freeipa-master
and @freeipa/freeipa-4.5 COPRs?

The latest Dogtag 10.4 builds are available at
https://copr.fedorainfracloud.org/coprs/g/pki/10.4/.

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] freeipa-master COPR: add certmonger-0.79.5

[Fraser Tweedale via FreeIPA-devel]

Hi,

Could someone with the relevant permissions please add
certmonger-0.79.5-1[1] to the freeipa-master COPR for f26?

It is needed for testing PR 930[2] and so I can amend the PR to bump
the min version of certmonger in the spec file.

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=965164
[2] https://github.com/freeipa/freeipa/pull/930 

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] pytest_multihost problems on f27

[Fraser Tweedale via FreeIPA-devel]

Just a heads up that running tests on f27 is a bit of a problem
right now, due to a bug in paramiko that gets triggered when
importing pytest_multihost.transport.

Relevant upstream issues:

- https://github.com/paramiko/paramiko/issues/1069
- https://github.com/paramiko/paramiko/pull/861

A quick workaround:

--- /usr/lib/python2.7/site-packages/paramiko/ssh_gss.py.orig
+++ /usr/lib/python2.7/site-packages/paramiko/ssh_gss.py
@@ -52,7 +52,7 @@
 try:
 import gssapi
 GSS_EXCEPTIONS = (gssapi.GSSException,)
-except (ImportError, OSError):
+except (ImportError, OSError, AttributeError):
 try:
 import pywintypes
 import sspicon

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: freeipa-master COPR: add certmonger-0.79.5

[Fraser Tweedale via FreeIPA-devel]

Thank you, Tomas!

On Fri, Sep 22, 2017 at 11:27:34AM +0200, Tomas Krizek wrote:
> On 09/21/2017 05:39 PM, Rob Crittenden via FreeIPA-devel wrote:
> > Tomas Krizek via FreeIPA-devel wrote:
> >> On 09/21/2017 02:32 AM, Fraser Tweedale via FreeIPA-devel wrote:
> >>> Hi,
> >>>
> >>> Could someone with the relevant permissions please add
> >>> certmonger-0.79.5-1[1] to the freeipa-master COPR for f26?
> >>>
> >>> It is needed for testing PR 930[2] and so I can amend the PR to bump
> >>> the min version of certmonger in the spec file.
> >>>
> >>> [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=965164
> >>> [2] https://github.com/freeipa/freeipa/pull/930 
> >> Hi,
> >>
> >> I've tried to build certmonger-0.79.5-1 in @freeipa/freeipa-master [1],
> >> but there's the following test failure for F26 [2]:
> >>
> >> Running test 038-ms-v2-template... FAIL
> >>
> >> --- expected.out   2017-09-01 17:46:34.0 +
> >> --- expected.out   2017-09-01 17:46:34.0 +
> >> +++ actual 2017-09-21 08:22:03.581400300 +
> >> +++ actual 2017-09-21 08:22:03.581400300 +
> >> @@ -9,11 +9,3 @@
> >> @@ -9,11 +9,3 @@
> >>  [csr : too many parts]
> >>  [csr : too many parts]
> >>  extension not present
> >>  extension not present
> >>  [csr : oid, major version]
> >>  [csr : oid, major version]
> >> -0:d=0  hl=2 l=   8 cons: SEQUENCE  
> >> -0:d=0  hl=2 l=   8 cons: SEQUENCE  
> >> -2:d=1  hl=2 l=   3 prim: OBJECT:1.2.3.4
> >> -2:d=1  hl=2 l=   3 prim: OBJECT:1.2.3.4
> >> -7:d=1  hl=2 l=   1 prim: INTEGER   :2A
> >> -7:d=1  hl=2 l=   1 prim: INTEGER   :2A
> >> -[csr : oid, major version, minor version]
> >> -[csr : oid, major version, minor version]
> >> -0:d=0  hl=2 l=  11 cons: SEQUENCE  
> >> -0:d=0  hl=2 l=  11 cons: SEQUENCE  
> >> -2:d=1  hl=2 l=   3 prim: OBJECT:1.2.3.4
> >> -2:d=1  hl=2 l=   3 prim: OBJECT:1.2.3.4
> >> -7:d=1  hl=2 l=   1 prim: INTEGER   :2A
> >> -7:d=1  hl=2 l=   1 prim: INTEGER   :2A
> >> -   10:d=1  hl=2 l=   1 prim: INTEGER   :11
> >> -   10:d=1  hl=2 l=   1 prim: INTEGER   :11
> >>
> >>
> >> Any ideas what to do with it?
> >>
> >>
> >> [1] -
> >> https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-master/build/605833/
> >> [2] -
> >> https://copr-be.cloud.fedoraproject.org/results/@freeipa/freeipa-master/fedora-26-x86_64/00605833-certmonger/build.log.gz
> > The problem is a missing build dependency on python. The test utilizes a
> > python2 script to evaluate the results.
> >
> > rob
> > ___
> > FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
> Thanks! I added the dependency and the build has passed [1].
> 
> [1] -
> https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-master/build/606559/
> 
> -- 
> Tomas Krizek
> 
> PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869
> 
> 


___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [BLOG/DESIGN] cert-request revocation changes

[Fraser Tweedale via FreeIPA-devel]

On Fri, May 11, 2018 at 01:52:57PM -0400, Rob Crittenden via FreeIPA-devel 
wrote:
> Simo Sorce wrote:
> > On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel
> > wrote:
> > > Hi all,
> > > 
> > > Ticket https://pagure.io/freeipa/issue/7482 made me think about the
> > > current revocation behaviour in `ipa cert-request`.  For hosts and
> > > services, all old certificates get revoked.
> > > 
> > > I wrote a blog post[1] outlining the problems with the current
> > > behaviour, and some suggested changes.  I'd like to know others'
> > > thoughts.  If we go ahead it would be something for a major release,
> > > not a bugfix release.  The actual amount of work is pretty small.
> > > 
> > > [1] 
> > > https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and-revocation.html
> > 
> > I'd prefer no revocation by default, if people need two+ certs with the
> > same name they should be able to do so easily (for example for
> > clustered services that need to answer as a single machine).
> 
> Multiple certs is fine but the convention to date has been one cert per
> service so that usage can be more easily tracked. If they want that can have
> a single cert and share it everywhere but then things are more opaque and
> the systems harder to manage. You can't easily answer the question "What TLS
> services are we running on bob?"
> 
> I can't quite get my head around Fraser's scenario Certificate for new
> purpose (non-renewal). New purpose for the same service? Do you have any
> examples of that?
> 
(Not a concrete example, but anyway...) Some service principal needs
a TLS server certificate, and a client certificate to connect to
some backend service, which needs a special Extended Key Usage value
(or whatever).

> Beyond the fact that we'll have to come up with some other scheme to sift
> the database looking for expired certs to remove from usercertificate.
>
We already have a ticket to add a command (or command options) for
pruning expired certs: https://pagure.io/freeipa/issue/7219
We could add it to the certmonger helper to get automatic pruning
for certmonger-tracked certs.

> Remember that storing usercertificate in host/service entries provides
> really no value whatsoever except to pin the fact that the service has a
> certificate at all. So being able to store 0, 1 or more doesn't really buy
> you a lot unless you are using these services to bind as clients.
> 
Do we know what customer expectations are around this?  (BTW,
whether to store issued certs in principal's userCertificate
attribute is a profile-specific configuration).

> Even now when you display a service it provides the details for only ONE
> certificate.
> 
That's a bug IMO.

> user certs are another story altogether and not covered here.
> 
> > It also fills a CRL list for no good reasons, we should be conservative
> > on CRL size, and if someone has a dynamic environment where hosts are
> > created and destroyed frequently the CRL could become enormous.
> 
> Sure, assuming they actually use the CRL or OCSP.
> 
> I'd be ok making it a config option.
> 
> I think I'd rather not extend the cert-request API for the revocation case
> and use post-command scripts to do it instead. This is an IPA policy so it
> should live within IPA.
>
Fair enough.  I didn't feel strongly either way.

Rob & Simo, thanks for your feedback!  I'll write up a proper design
proposal later this week.

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] New RFCs 8398 and 8399 update RFC 5280 (X.509)

[Fraser Tweedale via FreeIPA-devel]

Just a quick heads up that a couple of new RFCs[1][2] update RFC
5280 w.r.t. i18n support.

[1] https://tools.ietf.org/html/rfc8398
[2] https://tools.ietf.org/html/rfc8399

The most notable change is a new otherName type to represent
internationalised email addresses (i.e. when the local part is not
ASCII).  I have filed a ticket[3] to support this in FreeIPA (no
Dogtag changes are needed).  I don't think it is urgent, but
eventually someone will ask for it.

[3] https://pagure.io/freeipa/issue/7564

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/message/4QS3CGNASSJ2RPMCQMYLQP43URRVYIAK/

[Freeipa-devel] Re: [Design draft] Promoting replica to CRL master

[Fraser Tweedale via FreeIPA-devel]

On Thu, May 31, 2018 at 11:17:51AM -0400, Rob Crittenden via FreeIPA-devel 
wrote:
> Standa Laznicka via FreeIPA-devel wrote:
> > Hello people of the freeipa-devel channel,
> > 
> > Let me share a design that proposes a way of automating the way FreeIPA
> > replicas would be promoted to become a CRL master. Since the
> > configuration cannot be dynamically altered by modifying an entry in the
> > LDAP database, the proposal is to create an ipa-advise extension that
> > could handle this operation instead for now. Read all about it in the
> > attachement.
> > 
> 
> This makes sense to me.
> 
> I wonder if we should reflect the current CRL master in LDAP somehow, as
> a role perhaps. This way one could look to see whether one is assigned
> or not.
> 
> The downside is that this could easily get stale, for example if the CRL
> master server was lost in some way. But it would provide more visibility
> into which master is the CRL master and could be used to prevent/warn a
> user if they try to set multiple.
> 
> rob
>
Unless Dogtag is actually configuring itself based on this
hypothetical LDAP configuration, then it's still easy for the Dogtag
configuration to get out of sync with what we have recorded about
the CRL master.

There is a Dogtag ticket for moving CRL configuration into LDAP:
https://pagure.io/dogtagpki/issue/1262.  But the work has not been
scheduled.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/message/6FHVIL52TNRI2VFCTAHXBGP4LVLPF3I4/

[Freeipa-devel] Re: [Design draft] Promoting replica to CRL master

[Fraser Tweedale via FreeIPA-devel]

On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel 
wrote:
> Hello people of the freeipa-devel channel,
> 
> Let me share a design that proposes a way of automating the way FreeIPA
> replicas would be promoted to become a CRL master. Since the
> configuration cannot be dynamically altered by modifying an entry in the
> LDAP database, the proposal is to create an ipa-advise extension that
> could handle this operation instead for now. Read all about it in the
> attachement.
> 
> Looking forward to your comments,
> Stanislav Láznička
> 
> -- 
> Standa Láznička
> A Red Hat person
> PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
> 

> # CRL master reassignment draft
> 
> ## Rationale
> 
> Changing the CRL master of the FreeIPA system feels complex for the users
> and is thus rather error prone from the experience of the support engineers.
> 
> We should provide a more automatic way of handling this process.
> 
> ## Design
> 
> While FreeIPA framework offers an API to define a server role, the framework
> itself counts with all the necessary information to be available in the 
> backend
> database. Assigning an IPA server as a CRL master requires access to the
> filesystem [freeipa.org:Promote CA to Renewal and CRL Master](
> https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and
> therefore the framework should not be used, at least not until
> PKI allows us to change this configuration aspect of the system based on the
> values stored in the database. Instead, we will use the capabilities of the
> `ipa-advise` tool. Creating a separate Python script would also be an option
> but creating a script for every possible action in IPA seems like an
> unfortunate decision to make as it would only generate a bunch of binaries
> that would be hard getting rid of when a proper solution for that certain
> problem appears.
> 
> ## Implementation
> A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will
> provide the user with a script that will simultaneously try to change the
> configuration files on the current CRL master making it a common CRL clone
> (should be done via ssh), and also edit the files on the current system
> so that it becomes the CRL master. The script will be based on the
> steps in the aforementioned HOWTO page.
> 
> ## FEature management - CLI
> | Command | Arguments |
> | :---: | :---: |
> | ipa-advise | set-crl-master |

Thanks for the design, Standa.  One comment:

We already have `ipa-csreplica-manage set-renewal-master`.  IMO
configuring CRLs is in the same ball park, so why not make new
subcommand(s), e.g.:

  ipa-csreplica-manage [un]configure-crl-generation

If/when we support LDAP-based CRL configuration in Dogtag, we can
enhance these subcommands to work with the new configuration system.

Regardless of where we put the behaviour, 100% agree with having a
command to automate this for admins!

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/message/VXMKDFOIPTVD6K364DCHSVQTMYQGNNWU/

[Freeipa-devel] Re: [Design draft] Promoting replica to CRL master

[Fraser Tweedale via FreeIPA-devel]

On Thu, May 31, 2018 at 10:10:07PM -0400, Rob Crittenden via FreeIPA-devel 
wrote:
> Fraser Tweedale via FreeIPA-devel wrote:
> > On Thu, May 31, 2018 at 11:17:51AM -0400, Rob Crittenden via FreeIPA-devel 
> > wrote:
> >> Standa Laznicka via FreeIPA-devel wrote:
> >>> Hello people of the freeipa-devel channel,
> >>>
> >>> Let me share a design that proposes a way of automating the way FreeIPA
> >>> replicas would be promoted to become a CRL master. Since the
> >>> configuration cannot be dynamically altered by modifying an entry in the
> >>> LDAP database, the proposal is to create an ipa-advise extension that
> >>> could handle this operation instead for now. Read all about it in the
> >>> attachement.
> >>>
> >>
> >> This makes sense to me.
> >>
> >> I wonder if we should reflect the current CRL master in LDAP somehow, as
> >> a role perhaps. This way one could look to see whether one is assigned
> >> or not.
> >>
> >> The downside is that this could easily get stale, for example if the CRL
> >> master server was lost in some way. But it would provide more visibility
> >> into which master is the CRL master and could be used to prevent/warn a
> >> user if they try to set multiple.
> >>
> >> rob
> >>
> > Unless Dogtag is actually configuring itself based on this
> > hypothetical LDAP configuration, then it's still easy for the Dogtag
> > configuration to get out of sync with what we have recorded about
> > the CRL master.
> 
> Absolutely right. I'm a bit torn if it is a good idea or not myself.
> 
> It would be a check on someone running the script on all masters though.
> 
> There is a risk of a false sense of security if no masters are
> generating a CRL but then again, if your masters aren't generating a CRL
> and you don't notice then you aren't using the CRL in the first place.
> 
> > There is a Dogtag ticket for moving CRL configuration into LDAP:
> > https://pagure.io/dogtagpki/issue/1262.  But the work has not been
> > scheduled.
> 
> Nice, good to know. Once agreed-upon this should be added to the design
> page on the wiki.
> 
It's part of a broader desire to move configuration into the DB.
There are several related tickets (see
https://pagure.io/dogtagpki/issue/2586 for a list).  If/when it
happens it will probably be a big effort with collaborative design,
of which the CRL configuration will just be one use case.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahosted.org/message/DNKHYRH5VI6NYPRBCAPMYA4H7ZA3NVA4/

[Freeipa-devel] Re: [Design draft] Promoting replica to CRL master

[Fraser Tweedale via FreeIPA-devel]

On Wed, Jun 06, 2018 at 10:24:12AM +0200, Standa Laznicka wrote:
> Thank you guys for your great comments, I was away for the past few days
> but you correctly understood all of the motivations of the design and
> shared them here. I'll add several comments throughout the mails here:
> 
> 
> On 06/05/2018 11:02 AM, Fraser Tweedale wrote:
> > On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
> >> On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
> >>> On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via 
> >>> FreeIPA-devel wrote:
> >>>> Hello people of the freeipa-devel channel,
> >>>>
> >>>> Let me share a design that proposes a way of automating the way FreeIPA
> >>>> replicas would be promoted to become a CRL master. Since the
> >>>> configuration cannot be dynamically altered by modifying an entry in the
> >>>> LDAP database, the proposal is to create an ipa-advise extension that
> >>>> could handle this operation instead for now. Read all about it in the
> >>>> attachement.
> >>>>
> >>>> Looking forward to your comments,
> >>>> Stanislav Láznička
> >>>>
> >>>> -- 
> >>>> Standa Láznička
> >>>> A Red Hat person
> >>>> PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
> >>>>
> >>>> # CRL master reassignment draft
> >>>>
> >>>> ## Rationale
> >>>>
> >>>> Changing the CRL master of the FreeIPA system feels complex for the users
> >>>> and is thus rather error prone from the experience of the support 
> >>>> engineers.
> >>>>
> >>>> We should provide a more automatic way of handling this process.
> >>>>
> >>>> ## Design
> >>>>
> >>>> While FreeIPA framework offers an API to define a server role, the 
> >>>> framework
> >>>> itself counts with all the necessary information to be available in the 
> >>>> backend
> >>>> database. Assigning an IPA server as a CRL master requires access to the
> >>>> filesystem [freeipa.org:Promote CA to Renewal and CRL Master](
> >>>> https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) 
> >>>> and
> >>>> therefore the framework should not be used, at least not until
> >>>> PKI allows us to change this configuration aspect of the system based on 
> >>>> the
> >>>> values stored in the database. Instead, we will use the capabilities of 
> >>>> the
> >>>> `ipa-advise` tool. Creating a separate Python script would also be an 
> >>>> option
> >>>> but creating a script for every possible action in IPA seems like an
> >>>> unfortunate decision to make as it would only generate a bunch of 
> >>>> binaries
> >>>> that would be hard getting rid of when a proper solution for that certain
> >>>> problem appears.
> >>>>
> >>>> ## Implementation
> >>>> A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will
> >>>> provide the user with a script that will simultaneously try to change the
> >>>> configuration files on the current CRL master making it a common CRL 
> >>>> clone
> >>>> (should be done via ssh), and also edit the files on the current system
> >>>> so that it becomes the CRL master. The script will be based on the
> >>>> steps in the aforementioned HOWTO page.
> >>>>
> >>>> ## FEature management - CLI
> >>>> | Command | Arguments |
> >>>> | :---: | :---: |
> >>>> | ipa-advise | set-crl-master |
> >> Hi Standa,
> >>
> >> thanks for the design.
> >>
> >> I was thinking as Rob and Fraser about storing the CRL generation master in
> >> LDAP, and came to the following question. Currently we always configure the
> >> CA renewal and CRL generation on the same host. Does it make sense to have
> >> these 2 functions on different masters? If not, we may consider relying on
> >> the existing attribute (ipaconfigstring=caRenewalMaster).
> >>
> > There is no technical reason these functions have to be the same
> > server.  There is usually no reason why they'd have to be separate
> > servers, either.  But the

[Freeipa-devel] Re: IP addresses in Subject Alt Name

[Fraser Tweedale via FreeIPA-devel]

On Fri, Feb 16, 2018 at 12:51:41PM -0600, Ian Pilcher via FreeIPA-devel wrote:
> I have an older NETGEAR switch that has annoying habit of using its IP
> address in URLs that it sends back to the browser.  The result can be
> seen here:
> 
>   https://www.penurio.us/oops.png
> 
> I would like to add the switch's IP address to the Subject Alt Name
> extension of its TLS certificate, which is not currently supported by
> FreeIPA.
> 
> I'm interested in trying to add this capability, if there's a chance
> that my work will be accepted.  My initial thought is that an IP address
> should only be accepted if all of the following are true:
> 
> 1. One of the hostnames in the Subject Alt Name (or possibly the Common
>Name) ultimately resolves to that IP address, possibly via one or
>more CNAMEs.
> 
> 2. All of the DNS records (A, , CNAME) involved in #1 are managed by
>this IPA instance.
> 
> 3. The reverse DNS record for the IP address is managed by this IPA
>instance, and it points to an A or  record that is managed by
>this IPA instance (and contains the correct IP address).
> 
> Does this make sense?
> 
We have discussed this many times in the past.  Each time it has
gone in the "too hard" basket because of concerns around DNS views -
the IPA-managed DNS view seen by IPA clients may differ from
external DNS views.  Also IP addresses may change much more rapidly
than the lifetime of a certificate, etc.

Ultimately, the same problems exist for any kind of subject name and
the only practical mitigation is short-lived certificates.  With
that in mind, given that Ian's proposal is scoped to only validatate
IP Address altnames against data that are explicitly managed in
FreeIPA, I don't object.  I'm interested to hear other views.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: Contribute/Code wiki page update

[Fraser Tweedale via FreeIPA-devel]

On Mon, Mar 12, 2018 at 10:11:24AM +0100, Florence Blanc-Renaud via 
FreeIPA-devel wrote:
> Hi all,
> 
> I recently updated the Contribute/Code wiki page
> (https://www.freeipa.org/page/Contribute/Code), especially the sections
> related to Code Review Process.
> 
> As developers, we often prefer to deliver code rather than review other
> people's code, but I really think that the code reviews are an essential
> part of our job. They allow to ensure that code quality is preserved, but
> also foster discussions and help share experience.
> 
> So as always, comments or suggestions are welcome!
> 
> Flo
>
Thanks Flo,

I know I can always do more reviews.  A new resolution I have made
this year is to review at least one PR for each PR I submit.  That
way I will not contribute to the problem of PR backlog, and maybe
improve it a little :) (Please hold me accountable to this, request
reviews, etc).

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: IP addresses in Subject Alt Name

[Fraser Tweedale via FreeIPA-devel]

On Wed, Mar 14, 2018 at 09:11:20AM -0500, Ian Pilcher via FreeIPA-devel wrote:
> On 03/11/2018 09:31 PM, Fraser Tweedale wrote:
> > Thanks Ian!  I'll try and review this in the next couple of days?
> 
> No rush.  I'm traveling this week, so I won't be to do anything with
> this anyway.
> 
> > Do you use GitHub?  If so, you could create a pull request there,
> > which will make it more visible, easier to review, and cause CI to
> > run on your patch.  If not, that's OK.  We are happy to receive your
> > contribution by any means!
> 
> Define use.  ;-)
> 
> I have an ID, but my git usage has been limited to basic clone/pull/
> push stuff.  Learning how to do a pull request would not be a bad thing,
> though.
> 
> To that end, I've tried to follow/adapt this page:
> 
>   https://www.freeipa.org/page/Pull_request_on_Github
> 
> But I haven't been able to push anything to my new github repo.  I
> keep getting "The remote end hung up unexpectedly" errors.
> 
> Is there updated/better documentation anywhere?
> 
Hi Ian,

Looks like you have not created a "fork" on GitHub yet.
Go to https://github.com/freeipa/freeipa and hit the "Fork" button
(top right).  Then do the `git remote add', push your feature branch
to your freeipa repo (the fork), and return to GitHub.com to create
the pull request.

Let me know if you still get stuck.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

[Freeipa-devel] Re: [DESIGN] IPA healthcheck design

[Fraser Tweedale via FreeIPA-devel]

On Wed, Oct 24, 2018 at 04:49:21PM -0400, Rob Crittenden via FreeIPA-devel 
wrote:
> I started a design of an IPA healthcheck framework at
> https://www.freeipa.org/page/V4/Healthcheck
> 
> Have at it.
> 
> Note that this concentrates more on how it will work big picture and
> less on individual checks that may be performed. I'm happy to add any
> ideas you come up with for specific tests.
> 
> rob
>
Thanks Rob, feedback below.

1. I think we should consider promoting the server hostname into the
object, with attribute name 'ipaErrorHost' (or whatever).  This may
make some kinds of searches easier, e.g. if you have
ipa[123].bne.example.com and ipa[123].bos.example.com, and you are
interested in errors from the bne site, you can search for
'(ipaErrorHost=*.bne.example.com)'.  We can index the attribute.

It does make some sense to group in per-host subtrees but because
there is no subtree delete operation a flat container might be worth
it for the additional search flexibility.

2. Schema and indices:

- for ipaErrorDateReported and ipaErrorDateResolved, specify:

  EQUALITY generalizedTimeMatch
  ORDERING generalizedTimeOrderingMatch

- for ipaSeverity specify:
  EQUALITY integerMatch
  ORDERING integerOrderingMatch

- ipaIgnoreError specify: EQUALITY booleanMatch

- ipaIgnoreError being MAY is a pitfall.  Assuming absense
  implies "not ignored", searching for:

(ipaIgnoreError=FALSE)

  will _exclude_ entries without the ipaIgnoreError attribute.
  The correct filter is '(!(ipaIgnoreError=FALSE))'.  Better to
  make it a MUST attribute and exclude this pitfall.

- We probably want presence index for ipaErrorDateResolved


3. Execution; we might want a watchdog to kill checks that take too
long (for whatever reason).  There'll be some complexity so maybe
just make a note not to code ourselves into a corner and we can
defer it.

4. (Comment) regarding the separate repo, I'm not against it but
there's some interdependency, i.e. HC will depend on a lot of stuff
from ipalib, but the IPA healthcheck plugin will also depend on
stuff defined by HC.  What bits will live where is not fully clear.
We might have to work it out as we go.

5. CLI: the '--source' option has not been defined.  Does '--tool'
mean the same thing?

6. Terminology: not sure about "source"/"command" (especially
"command", which could be confusing ("what command failed?") Some
ideas: command -> item/check/fault.  I don't care about bikeshedding
the strings, I just want to avoid overloaded/confusing terms.

7. CLI: there is some inconsistency with how other IPA commands work
(not necessarily bad, but it should be justified).  If we follow the
IPA pattern:

- `ipa healthcheck-show UUID` would show a single report
- `ipa healthcheck-find` would have a `--master=HOSTNAME` filter
  option.
- `--all` would show all attributes, and there would be a separate
  option to show ignored reports (e.g. `include-ignored`).

So again, we don't have to do it that way, but the current design is
a deviation from the norm so I think that should be discussed from a
usability perspective.

8. Can a single tool+command combo produced multiple reports for a
single master, with different ipaErrorMessage key-value pairs?
Example: file permissions.  Is every possible file to check a
different tool+command, or is it one tool+command, with potentially
multiple reports with different ipaErrorMessage parameters?

Consider this from a usability perspective: the resolution is likely
to be very similar for all the possible instantiations.  Also
consider how many tool+command combinations there would be if all
the possible files to check had to have different names.  Lookup
tables for error message generation and external resources get huge.

OTOH if a single tool+command can produce multiple reports, it
affects the API/CLI somewhat (e.g. `ipa healthcheck-ignore` must now
be given the UUID or enough parameters to uniquely identify the
report to ignore).

9. Would be good to include links to external resources etc in
healthcheck-show.  Also to indicate when 'ipa-healthcheck' may be
able to repair the issue (may reduce support burden if we can subtly
encourage the administrator to run the repair tool instead of
contact support / mailing list).


That's all for now :)  Overall the design is looking good.

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: certificate checking tool

[Fraser Tweedale via FreeIPA-devel]

On Mon, Oct 01, 2018 at 10:10:52PM -0400, Rob Crittenden via FreeIPA-devel 
wrote:
> As part of a larger IPA "health" checker and driven largely by necessity
> I have the beginning of a certificate checking tool available at
> https://github.com/rcritten/checkcerts
> 
> It works for me in IPA 4.5.4, IPA 4.6.0 and IPA master (basically 4.7+
> patches) mostly with just a single-master install. YMMV.
> 
> I think the guts are somewhat solid but there is no real, usable
> framework wrapped around it so there are no options (like no --debug
> option), no control over logging, etc. It just spits output to stdout.
> 
> I did this because I expect it to be rolled up into some larger tool at
> some point and don't want to have to throw away a ton of code.
> 
> It needs to be run on an IPA master and checks the things I thought of
> to check. I've only done limited testing so I'd appreciate feedback.
> Don't freak out of it spits out errors as it could just be bugs on my
> part :-)
> 
> It is read-only so it shouldn't blow up anything.
> 
> So if you want to run it against your system and send me the any output
> I can try to figure out if it is my tool that is the issue or your
> system (it is supposed to help pro-actively diagnose issues after all).
> 
> rob
>
Thanks Rob.  This tool covers a lot of the checks and we will
undoubtedly copy some of your code to implement the low-level checks
once we have a health check system that can report the results.
And work is about to begin on that :)

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: [Pki-devel] Dogtag+FreeIPA: adapting to the Fedora mass orphaning

[Fraser Tweedale via FreeIPA-devel]

On Mon, Mar 11, 2019 at 03:58:17PM +0100, François Cami wrote:
> Hi,
> 
> The Java maintainers have orphaned most, if not all, of the Java stack
> in Fedora, in favor of modules:
> https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/message/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/
> 
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/ITDMQ7UACH4CL6754IMOYQ45QOBVPOX6/
> 
> As this change would lead into a lot of retired packages (maven and
> all that depends on it, like Dogtag), there was a proposal to create a
> SIG that would take care of these packages.
> It does not seem to have advanced much for the past month:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/I7AP2G7KUBGT6FP4GJBDBLCHZJ54YZG2/#I7AP2G7KUBGT6FP4GJBDBLCHZJ54YZG2
> 
> And it seems unrealistic for the Dogtag and FreeIPA teams to take over
> all these packages.
> 
> In the future packages will be able to BuildRequire modules:
> https://tree.taiga.io/project/modularity-wg/epic/12
> but it is not possible yet and there is no ETA.
> 
> The consequence is that Dogtag will be considered FTBFS as soon as
> maven and other dependencies are retired.
> Dogtag will therefore will be retired (along with FreeIPA) if
> maintenance for the dependencies is not picked up.
> 
> There does not seem to be a good solution except by moving both Dogtag
> and FreeIPA to modules (where we could BR: existing modules) before
> Fedora releng starts to retire our packages.
> 
> Thoughts?
> 
> Cheers
> François
> 
We are already in a module for RHEL 8.  I don't perceive any major
disadvantage if we have to move to modules in Fedora too.  Are there
any big reasons, from a user point of view, against moving to
modules?

Thanks,
Fraser

> ___
> Pki-devel mailing list
> pki-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: ipatool PR #72 ; need review

[Fraser Tweedale via FreeIPA-devel]

On Tue, Jun 11, 2019 at 11:40:52AM +1000, Fraser Tweedale via FreeIPA-devel 
wrote:
> Hi team,
> 
> I opened a PR a couple weeks ago - a pretty simple fix to not
> consider tickets in diff context or removed lines.  Looking for a
> review / agreement that this is a good idea, and then we can merge
> it.
> 
> https://github.com/freeipa/freeipa-tools/pull/72/files
> 
And here's another PR with some fixes and enhancements for the
'backport' command: https://github.com/freeipa/freeipa-tools/pull/73

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] ipatool PR #72 ; need review

[Fraser Tweedale via FreeIPA-devel]

Hi team,

I opened a PR a couple weeks ago - a pretty simple fix to not
consider tickets in diff context or removed lines.  Looking for a
review / agreement that this is a good idea, and then we can merge
it.

https://github.com/freeipa/freeipa-tools/pull/72/files

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] ipatool pr-push --autobackport

[Fraser Tweedale via FreeIPA-devel]

Continuing with fixes and enhancements to ipatool, here is a patch
that teaches pr-push the --autobackport option.  So we can avoid
manually looking and specifying the backport targets.

https://github.com/freeipa/freeipa-tools/pull/74

Enjoy!
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] [BLOG] Plans for ACME support in FreeIPA

[Fraser Tweedale via FreeIPA-devel]

My latest blog post outlines our plan for ACME support in FreeIPA.
If you have any feedback or questions please share.

https://frasertweedale.github.io/blog-redhat/posts/2019-12-06-freeipa-acme-plans.html

Cheers,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: [Freeipa-users] COPR repositories changes

[Fraser Tweedale via FreeIPA-devel]

On Thu, Dec 19, 2019 at 05:17:05PM +0200, Alexander Bokovoy via FreeIPA-users 
wrote:
> Hi,
> 
> thanks to the recent changes done by Dinesh(master[1] and ipa-4-8[2]),
> it is now possible to have continuous rebuild of FreeIPA master and
> ipa-4-8 branches using COPR repositories.
> 
> We now have @freeipa/freeipa-master-nightly[3] to continuously track git
> master branch. Every time there is a commit made upstream in the master
> branch and synchronized to FreeIPA GitHub mirror, COPR will do a rebuild
> of the git master for Fedora 31 and Rawhide on x86_64, i686, aarch64,
> and ppc64le.
> 
> We also have @freeipa/freeipa-4.8-nightly[4] to continuously track git
> ipa-4-8 branch. Every time there is a commit made upstream in the master
> branch and synchronized to FreeIPA GitHub mirror, COPR will do a rebuild
> of the git master for Fedora 31 and Rawhide on x86_64, i686, aarch64,
> and ppc64le.
> 
> Each repository page has explanation how to use the COPRs. There will
> probably be some delay before actual packages will appear in the
> repositories as we haven't had any merges upstream done yet since I've
> set up the tracking process.
> 
> I also cleaned up @freeipa/freeipa-master[5] repository which is used for
> hosting temporary dependencies that might still be lacking in stable
> Fedora versions, not to provide FreeIPA rebuilds.
> 
Thanks Alexander!

I'd like to clarify that putting freeipa builds in the
@freeipa/freeipa-master COPR is a MUST NOT.  Otherwise PR-CI will
install freeipa from @freeipa/freeipa-master instead of the RPMs
produced by the build job, and the actual changes from the PR are
not tested.

Cheers,
Fraser

> [1] https://github.com/freeipa/freeipa/pull/4034
> [2] https://github.com/freeipa/freeipa/pull/4038
> [3] https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-master-nightly
> [4] https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4.8-nightly
> [5] https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-master
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: FreeIPA PR-CI down due to maintenance issues.

[Fraser Tweedale via FreeIPA-devel]

Thanks Triviño!

You PR-CI wrangers are absolute legends.  

Cheers,
Fraser

On Mon, Feb 03, 2020 at 01:26:45PM +0100, Francisco Triviño García via 
FreeIPA-devel wrote:
> Our FreeIPA PR-CI infra is up and running again.
> 
> -Triviño.
> 
> 
> On 2/3/20 11:27 AM, Francisco Triviño García wrote:
> > Hi,
> > 
> > An important part of our FreeIPA infrastructure is down due to
> > maintenance issues. We are working on recovering all PR-CI runners ASAP.
> > I'll send another email once our infra is fully up & running.
> > 
> > -Triviño.
> > 
> > 
> ___
> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: Azure tests failing

[Fraser Tweedale via FreeIPA-devel]

On Wed, Jul 01, 2020 at 04:07:02PM -0400, Rob Crittenden via FreeIPA-devel 
wrote:
> You may notice that your azure tests are failing with:
> 
> Bash exiting with code '1':
> GATING sudo_1_to_5 * Check for coredumps
> 
> It is an updated certmonger that is dropping core. I pushed a fix in
> F31-rawhide so it should appear in the updates repo in a few hours I hope.
> 
> rob
>
Hi Rob,

Looking at [1] it seems only the f33 update was pushed to stable.
f32 (which we need for master CI) and f31 are still in testing.

[1] https://bodhi.fedoraproject.org/updates/?packages=certmonger

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org

[Freeipa-devel] Re: Preparing for FreeIPA 4.9.0 release candidate

[Fraser Tweedale via FreeIPA-devel]

On Wed, Nov 11, 2020 at 11:45:15AM +0200, Alexander Bokovoy via FreeIPA-devel 
wrote:
> Hi,
> 
> we are close to get FreeIPA 4.9.0 release candidate out.
> 
> Draft release notes: https://vda.li/drafts/freeipa-4.9.0-release-notes.html
> 
> They include difference between 4.8.10 and current git master. Note that
> since many things were backported to 4.8 in separate commits that
> referenced the same FreeIPA tickets, they appear in the release notes
> too even though you might have seen them in release notes for FreeIPA
> 4.8 releases.
> 
> Currently, in nightly tests
> https://github.com/freeipa-pr-ci2/freeipa/pull/525 we have 126
> successful testsuites and 6 failures, out of which four have known
> failures:
>  - test_adtrust_install, test_cert, test_ipahealthcheck_nodns_extca_file
>failure already reported in FreeIPA#8533
> 
>  - test_installation_TestInstallWithCA2 failure already reported in
>FreeIPA#8477
> 
>  - test_webui_general failure already reported in FreeIPA#8570
> 
>  - test_webui_users failure already reported in FreeIPA#8569
> 
> The latter two issues will most likely be irrelevant for FreeIPA release
> as they track behavior change in Fedora FAS plugin and we simply need to
> install that plugin in a confined environment, to avoid overlapping with
> our tests. FAS behavior is specific to Fedora/CentOS AAA deployment and
> should not be a problem for anything else, it is simply a design choice
> in FAS plugin.
> 
> This makes us down to two known and two not-yet-investigated failures.
> 
> On top of that we have a worrying behavior of the Azure CI with regards
> to DNSSEC that waits for investigation.
> 
> One major part not exercised in the nightlies is an upgrade code.
> 
> My plan is to do FreeIPA 4.9.0 release candidate this week -- I planned
> it to do last week but things slipped due to various failures and
> load at other projects. I think for a release candidate this state is
> quite good.
> 
Thank you Alexander!

I noticed I have a doppelganger in the release notes, because of one
commit with my personal email address.  I just made a PR to add
myself to the mailmap: https://github.com/freeipa/freeipa/pull/5249

Thanks,
Fraser
___
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-devel@lists.fedorahosted.org