Re: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica
On 09/02/2013 06:21 PM, Tomas Babej wrote: On 09/02/2013 06:07 PM, Petr Viktorin wrote: On 08/29/2013 05:56 PM, Ana Krivokapic wrote: Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3867. Patch works well. It's temping to restart the discussion about how to wrap text output from installation tools. Wrapping at 60 characters because it looks better in the code seems suboptimal. Does anyone remember if we established some guideline last time this came up? I'm not sure if I'm missing something, but do we need a guideline here? I don't see any reason why not have best of the both worlds, using print as a function we can wrap the text inside the parenthesis with no effect on the output whatsoever. Or use print statement, but enclose the text in parenthesis. Or use backslash. Yes. But whatever we choose, we need to make sure that the resulting text is wrapped the same to avoid inconsistent output. IMO we should do our best to keep the text wrapped at 80 characters in new or updated texts. So I would prefer to have Ana's patch refactored a bit, to change wrapping of the resulting from 60 to 80 characters. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] IPA Server UI Behind Proxy
On 09/03/2013 02:50 AM, Jan Pazdziora wrote: On Mon, Sep 02, 2013 at 05:57:16PM +0200, Petr Vobornik wrote: Could we change the CSRF protection method from the Referrer check to some user session specific token? I don't think we can use the recommended method[1] where CSFR token is stored in a requested page(ie in hidden element) because we don't generate UI on a server. The only way to use the token, which I see, is to create CSFR token on login and returned it in a cookie. Does it have to be cookie? What is the result of a login operation? It seems that at least for the /ipa/session/login_password call, it is the result of finalize_kerberos_acquisition which is return [''], and that empty string is ignored by IPA.login_password's success_handler. Could the return be the token, and get stored either to IPA.ui.csrf_token or similar place, or stored to an element in the DOM? You don't really need to use cookies for that. It has one drawback. You won't have access to the token if you open new instance of Web UI because you already have a session and therefore don't need to log in. I suppose we can create a new handler (can't be a command) which new Web UI instance would call to obtain the token. Special care would be needed to prevent cross origin usage though. IMO the cookie is more secure, but I'm not a security expert ... -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] IPA Server UI Behind Proxy
On Tue, Sep 03, 2013 at 09:57:45AM +0200, Petr Vobornik wrote: It has one drawback. You won't have access to the token if you open new instance of Web UI because you already have a session and therefore don't need to log in. I suppose we can create a new handler (can't be a command) which new Web UI instance would call to obtain the token. Special care would Right. Well, you can actually make it a lazy thing -- only make the call to get the token before any POST is done (and the JS does not have the token). Chances are, if the user is only viewing things on the WebUI without modifying anything, you won't need the token at all. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] IPA Server UI Behind Proxy
On 09/03/2013 09:57 AM, Petr Vobornik wrote: On 09/03/2013 02:50 AM, Jan Pazdziora wrote: On Mon, Sep 02, 2013 at 05:57:16PM +0200, Petr Vobornik wrote: Could we change the CSRF protection method from the Referrer check to some user session specific token? I don't think we can use the recommended method[1] where CSFR token is stored in a requested page(ie in hidden element) because we don't generate UI on a server. The only way to use the token, which I see, is to create CSFR token on login and returned it in a cookie. Does it have to be cookie? What is the result of a login operation? It seems that at least for the /ipa/session/login_password call, it is the result of finalize_kerberos_acquisition which is return [''], and that empty string is ignored by IPA.login_password's success_handler. Could the return be the token, and get stored either to IPA.ui.csrf_token or similar place, or stored to an element in the DOM? You don't really need to use cookies for that. It has one drawback. You won't have access to the token if you open new instance of Web UI because you already have a session and therefore don't need to log in. I suppose we can create a new handler (can't be a command) which new Web UI instance would call to obtain the token. Special care would be needed to prevent cross origin usage though. IMO the cookie is more secure, but I'm not a security expert ... Maybe there is a way to avoid the cookie and the new handler. DOM is not usable as a storage, but sessionStorage or localStorage [1] might be. Browser support: http://caniuse.com/namevalue-storage [1] https://developer.mozilla.org/en-US/docs/Web/Guide/DOM/Storage -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Debian client support
On 09/02/2013 11:43 PM, Timo Aaltonen wrote:
This fixes https://fedorahosted.org/freeipa/ticket/1887
and
https://fedorahosted.org/freeipa/ticket/2455
Thank you!
the first three patches fix some bugs in how python is used
These look okay, I'll check when other build errors are fixed.
fourth patch checks if dbus is already running before trying to start it
Please handle this in platform/debian/service.py.
Is this only for D-Bus or do all start() methods for Debian need this?
If it's all of them, add it in DebianService.start.
If it's just D-Bus you'll want to make a special service there, like
DebianSSHService.
fifth fixes some compilation warnings
Looks good to my eyes, perhaps a C expert can look at this one too.
I wonder why these warnings aren't enabled in our builds, though.
sixth finally adds the Debian platform module
Please add copyright headers to the new files.
in debian/auth.py:DebianAuthConfig.execute, you should use a dictionary
for env:
env = {'DEBCONF_FRONTEND': 'noninteractive'}
You need to import ipautil to use ipautil.run in auth.py. This trips
pylint and prevents building the code for me. Do you include pylint in
your build procedure?
platform/debian/auth.py: Git complains about a new blank line at EOF
I don't think anyone from the regular IPA team can really verify the
Debian code, so we may just trust you that it works and push it without
full tests :)
there are also distro patches that aren't upstreamable as-is, that do
stuff like
- give--install-layout=deb to setup.py
Add a SETUP_PY_ARGS variable to the Makefile.
- disable make-testcert since it needs a server running
For now you can just run ./make-test directly. Getting `make test`
working will be just icing on the cake at this point.
- fix hardcoded NFS related paths and a variable in ipa-client-automount
- fix ldap.conf path in ipa-client-install
ipa-client requires ipa-python, we can just stick these in the platform
module and include that.
- fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like
Fedora)
A patch to replace ntpdate with ntp is on review right now; you'll want
to revisit this when it gets pushed.
- change nss includes in ipa_pwd.c (nss/.. not nss3/..)
I'd ask for a C expert's opinion.
dunno what to do about those, the packaging can keep on carrying those
but if you have ideas how to make them configurable so that upstream
git/tarball could be used for development/testing on Debian then that
would be nice.
Patches to make them configurable are very welcome. You might want to
file a bug for each patch, so it's easier to keep track of what's left
to do.
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Debian client support
On Tue, Sep 03, 2013 at 11:00:07AM +0200, Petr Viktorin wrote: fifth fixes some compilation warnings Looks good to my eyes, perhaps a C expert can look at this one too. I wonder why these warnings aren't enabled in our builds, though. They look good to me, too. (Does this answer make me a C expert? :-)) -Wformat-security is not among default CFLAGS on Fedora. In SSSD, we only recently fixed these problems in our debug messages. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount
On 09/02/2013 01:31 PM, Ana Krivokapic wrote: On 09/02/2013 12:55 PM, Petr Viktorin wrote: On 08/30/2013 04:10 PM, Ana Krivokapic wrote: Hello, The attached patch addresses ticket https://fedorahosted.org/freeipa/ticket/3740. Hello, Please write a design doc for this RFE. I updated the Minor Enhancements page: http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient in this case. Also you'll need to update the ipa-client-install man page. Done. I wonder if `location` is too generic a name for this option. Did you think about `--automount-location`, Good point, I changed `--location` to `--automount-location`. plus maybe `--automount` without argument to just use the default location? It's a bit longer but it would make it immediately clear what the option is about. I think this is a bit of an overkill, as --automount-location=default does precisely that. I would rather not complicate things further by adding more options. Thanks for the review, updated patch is attached. Looks good! One more comment for usability. The man page should explain that --automount-location configures automount by running ipa-client-automount(1). -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0063 Do not show unexpected error in ipa-ldap-updater
Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3825. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From f71bace581340667d27a0ad0f1b47eb2b7b9d870 Mon Sep 17 00:00:00 2001 From: Ana Krivokapic akriv...@redhat.com Date: Tue, 3 Sep 2013 12:42:48 +0200 Subject: [PATCH] Do not show unexpected error in ipa-ldap-updater Prevent showing of unfriendly Unexpected error message, when providing incorrect DM password to ipa-ldap-updater. https://fedorahosted.org/freeipa/ticket/3825 --- ipaserver/install/installutils.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py index 268279dc9d22b9f983406303cbfc80c00a2b8fa0..67c3fa9befbeb9ecce3c7d53ba582b3d81f73b56 100644 --- a/ipaserver/install/installutils.py +++ b/ipaserver/install/installutils.py @@ -673,6 +673,8 @@ def handle_error(error, log_file_name=None): if isinstance(error, socket.error): return error, 1 +if isinstance(error, errors.ACIError): +return error.message, 1 if isinstance(error, ldap.INVALID_CREDENTIALS): return Invalid password, 1 if isinstance(error, ldap.INSUFFICIENT_ACCESS): -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount
On 09/03/2013 12:27 PM, Petr Viktorin wrote:
On 09/02/2013 01:31 PM, Ana Krivokapic wrote:
On 09/02/2013 12:55 PM, Petr Viktorin wrote:
On 08/30/2013 04:10 PM, Ana Krivokapic wrote:
Hello,
The attached patch addresses ticket
https://fedorahosted.org/freeipa/ticket/3740.
Hello,
Please write a design doc for this RFE.
I updated the Minor Enhancements page:
http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient
in
this case.
Also you'll need to update the ipa-client-install man page.
Done.
I wonder if `location` is too generic a name for this option.
Did you think about `--automount-location`,
Good point, I changed `--location` to `--automount-location`.
plus maybe `--automount` without argument to just use the default
location?
It's a bit longer but it would make it immediately clear what the option is
about.
I think this is a bit of an overkill, as --automount-location=default does
precisely that. I would rather not complicate things further by adding more
options.
Thanks for the review, updated patch is attached.
Looks good! One more comment for usability.
The man page should explain that --automount-location configures automount by
running ipa-client-automount(1).
Fixed in updated patch.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From 17818950350f189202b4e1a9dfac870d53b58d20 Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Fri, 30 Aug 2013 16:05:01 +0200
Subject: [PATCH] Add option to ipa-client-install to configure automount
Add the --automount-location option to ipa-client-install. If the option is
used, ipa-client-automount is called at the end of ipa-client-install.
https://fedorahosted.org/freeipa/ticket/3740
---
ipa-client/ipa-install/ipa-client-install | 27 +++
ipa-client/man/ipa-client-install.1 | 6 +-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 280edd793326150c416fe1b82f9866435e9c6509..3bfd5a4455c786d638a8ab1984f780dd537a103d 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -148,6 +148,8 @@ def parse_options():
# only, it isn't meant to be used on clients.
basic_group.add_option(--on-master, dest=on_master, action=store_true,
help=SUPPRESS_HELP, default=False)
+basic_group.add_option(--automount-location, dest=location,
+ help=Automount location)
parser.add_option_group(basic_group)
sssd_group = OptionGroup(parser, SSSD options)
@@ -1288,6 +1290,28 @@ def configure_sshd_config(fstore, options):
except Exception, e:
log_service_error(sshd.service_name, 'restart', e)
+
+def configure_automount(options):
+root_logger.info('\nConfiguring automount:')
+
+args = [
+'ipa-client-automount', '--debug', '-U',
+'--location', options.location
+]
+
+if options.server:
+args.extend(['--server', options.server[0]])
+if not options.sssd:
+args.append('--no-sssd')
+
+try:
+stdout, _, _ = run(args)
+except Exception, e:
+root_logger.error('Automount configuration failed: %s', str(e))
+else:
+root_logger.info(stdout)
+
+
def resolve_ipaddress(server):
Connect to the server's LDAP port in order to determine what ip
address this machine uses as public ip (relative to the server).
@@ -2515,6 +2539,9 @@ def install(options, env, fstore, statestore):
if options.conf_sshd:
configure_sshd_config(fstore, options)
+if options.location:
+configure_automount(options)
+
root_logger.info('Client configuration complete.')
return 0
diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-install.1
index bb19041b13622e3384fb800fca60b7b6f695e8f0..65c5c2f73913ce8ae705f3b1ff46f16c7eb4c5c6 100644
--- a/ipa-client/man/ipa-client-install.1
+++ b/ipa-client/man/ipa-client-install.1
@@ -146,13 +146,17 @@ Print debugging information to stdout
\fB\-U\fR, \fB\-\-unattended\fR
Unattended installation. The user will not be prompted.
.TP
-\fB\-\-ca-cert-file\fR=\fICA_FILE\fR
+\fB\-\-ca\-cert\-file\fR=\fICA_FILE\fR
Do not attempt to acquire the IPA CA certificate via automated means,
instead use the CA certificate found locally in in \fICA_FILE\fR. The
\fICA_FILE\fR must be an absolute path to a PEM formatted certificate
file. The CA certificate found in \fICA_FILE\fR is considered
authoritative and will be installed without checking to see if it's
valid for the IPA domain.
+.TP
+\fB\-\-automount\-location\fR=\fILOCATION\fR
+Configure automount by running ipa\-client\-automount(1) with \fILOCATION\fR as
+automount location.
.SS SSSD OPTIONS
.TP
--
1.8.3.1
___
Freeipa-devel mailing list
Re: [Freeipa-devel] [PATCH] 0062 Replace ntpdate calls with ntpd
On 09/02/2013 05:05 PM, Ana Krivokapic wrote: Hello, This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3797. Thanks! I have a question. -# retry several times -- logic follows /etc/init.d/ntpdate -# implementation +# retry several times for retry in range(0, 3): What's the reason to try several times? Is it still necessary with ntpd? I checked /etc/init.d/ntpdate in RHEL (since Fedora doesn't have it any more) and I didn't see any repeating. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Debian client support
On 09/03/2013 11:22 AM, Jakub Hrozek wrote: On Tue, Sep 03, 2013 at 11:00:07AM +0200, Petr Viktorin wrote: fifth fixes some compilation warnings Looks good to my eyes, perhaps a C expert can look at this one too. I wonder why these warnings aren't enabled in our builds, though. They look good to me, too. (Does this answer make me a C expert? :-)) Why, yes! (Your certificate will arrive by mail shortly.) -Wformat-security is not among default CFLAGS on Fedora. In SSSD, we only recently fixed these problems in our debug messages. I've taken the WARNINGS from SSSD's aliases, built with them, and reported three additional warnings. https://fedorahosted.org/freeipa/ticket/3896 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Debian client support
On Tue, Sep 03, 2013 at 01:34:48PM +0200, Petr Viktorin wrote: On 09/03/2013 11:22 AM, Jakub Hrozek wrote: On Tue, Sep 03, 2013 at 11:00:07AM +0200, Petr Viktorin wrote: fifth fixes some compilation warnings Looks good to my eyes, perhaps a C expert can look at this one too. I wonder why these warnings aren't enabled in our builds, though. They look good to me, too. (Does this answer make me a C expert? :-)) Why, yes! (Your certificate will arrive by mail shortly.) -Wformat-security is not among default CFLAGS on Fedora. In SSSD, we only recently fixed these problems in our debug messages. I've taken the WARNINGS from SSSD's aliases, built with them, and reported three additional warnings. https://fedorahosted.org/freeipa/ticket/3896 Yes, they are a good source of defensive CFLAGS. But make sure to grab a very recent version (git HEAD ideally), there was recently a typo that prevented the aliases from working correctly. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica
On 09/03/2013 08:25 AM, Martin Kosek wrote:
On 09/02/2013 06:21 PM, Tomas Babej wrote:
On 09/02/2013 06:07 PM, Petr Viktorin wrote:
On 08/29/2013 05:56 PM, Ana Krivokapic wrote:
Hello,
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3867.
Patch works well.
It's temping to restart the discussion about how to wrap text output from
installation tools. Wrapping at 60 characters because it looks better in the
code seems suboptimal.
Does anyone remember if we established some guideline last time this came
up?
I'm not sure if I'm missing something, but do we need a guideline here?
I don't see any reason why not have best of the both worlds, using print as a
function we can wrap the text inside the parenthesis
with no effect on the output whatsoever. Or use print statement, but enclose
the text in parenthesis. Or use backslash.
Yes. But whatever we choose, we need to make sure that the resulting text is
wrapped the same to avoid inconsistent output.
IMO we should do our best to keep the text wrapped at 80 characters in new or
updated texts. So I would prefer to have Ana's patch refactored a bit, to
change wrapping of the resulting from 60 to 80 characters.
Martin
Text is wrapped at 80 characters in the updated patch.
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From b47a751de3279de38e13a2b626c7ea003c0175a5 Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Thu, 29 Aug 2013 17:44:02 +0200
Subject: [PATCH] Add warning when uninstalling active replica
Add a warning when trying to uninstall a replica that has active replication
agreements.
https://fedorahosted.org/freeipa/ticket/3867
---
install/tools/ipa-server-install | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index bfdef82ab7be1dd76efcab2514cda73445b483a9..1bf932da731965b342c0c49d39e6a175bf98705b 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -28,18 +28,17 @@
import sys
import os
-import errno
import grp
-import subprocess
import signal
import shutil
-import glob
import pickle
import random
import tempfile
import nss.error
import base64
-from optparse import OptionGroup, OptionValueError, SUPPRESS_HELP
+import pwd
+import textwrap
+from optparse import OptionGroup, OptionValueError
from ipaserver.install import dsinstance
from ipaserver.install import krbinstance
@@ -51,10 +50,11 @@ from ipaserver.install import cainstance
from ipaserver.install import memcacheinstance
from ipaserver.install import otpdinstance
from ipaserver.install import sysupgrade
-
+from ipaserver.install import replication
from ipaserver.install import service, installutils
from ipapython import version
from ipapython import certmonger
+from ipapython import ipaldap
from ipaserver.install.installutils import *
from ipaserver.plugins.ldap2 import ldap2
@@ -624,6 +624,32 @@ def main():
print Aborting uninstall operation.
sys.exit(1)
+conn = ipaldap.IPAdmin(api.env.host, ldapi=True, realm=api.env.realm)
+conn.do_external_bind(pwd.getpwuid(os.geteuid()).pw_name)
+rm = replication.ReplicationManager(api.env.realm, api.env.host, None,
+conn=conn)
+agreements = rm.find_ipa_replication_agreements()
+
+if agreements:
+other_masters = [a.get('cn')[0][4:] for a in agreements]
+msg = (
+\nReplication agreements with the following IPA masters
+found: %s. Removing any replication agreements before
+uninstalling the server is strongly recommended. You can
+remove replication agreements by running the following
+command on any other IPA master:\n % , .join(other_masters)
+)
+cmd = $ ipa-replica-manage del %s\n % api.env.host
+print textwrap.fill(msg, width=80, replace_whitespace=False)
+print cmd
+if not (options.unattended or user_input(Are you sure you want
+ to continue with the
+ uninstall procedure?,
+ False)):
+print
+print Aborting uninstall operation.
+sys.exit(1)
+
return uninstall()
if options.external_ca:
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Multiple CA certificates in LDAP, questions
On 09/02/2013 04:49 AM, Petr Spacek wrote: On 22.8.2013 15:43, Jan Cholasta wrote: Hi, I'm currently investigating support for multiple CA certificates in LDAP (https://fedorahosted.org/freeipa/ticket/3259, https://fedorahosted.org/freeipa/ticket/3520). This will be useful for CA certificate renewal (https://fedorahosted.org/freeipa/ticket/3304, https://fedorahosted.org/freeipa/ticket/3737) and using certificates issued by custom CAs for IPA HTTP and directory server instances (https://fedorahosted.org/freeipa/ticket/3641). The biggest issue is how to make IPA clients aware of CA certificate changes. One of the tickets suggests polling the LDAP server from SSSD. Would that be sufficient? Perhaps a combination of polling and detecting certificate changes when connecting to LDAP would be better? Another issue is how to handle updating IPA systems with new CA certificate(s). On clients it is probably sufficient to store the certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places where the update needs to be done (HTTP and directory server NSS databases, KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, so there should be a way to do this externally. The simplest thing that comes to mind is that SSSD would execute an external script to do the update when it detects changes, but I'm not sure how well would that work with SELinux in the picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 450 Fix RUV search scope in ipa-replica-manage
The search had an incorrect scope and therefore it didn't find any RUV. This issue prevented removing of replica. https://fedorahosted.org/freeipa/ticket/3876 -- Petr Vobornik From f45007f57cebf7508022d0861bc3adda260c8f77 Mon Sep 17 00:00:00 2001 From: Petr Vobornik pvobo...@redhat.com Date: Tue, 3 Sep 2013 11:01:48 +0200 Subject: [PATCH] Fix RUV search scope in ipa-replica-manage The search had an incorrect scope and therefore it didn't find any RUV. This issue prevented removing of replica. https://fedorahosted.org/freeipa/ticket/3876 --- install/tools/ipa-replica-manage | 2 +- ipatests/test_integration/test_simple_replication.py | 10 ++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage index e2bd38e9b824f210871e2881461945bc08a2fe01..45b915c664c6776dc019b180d049eb985cf21abd 100755 --- a/install/tools/ipa-replica-manage +++ b/install/tools/ipa-replica-manage @@ -348,7 +348,7 @@ def get_ruv(realm, host, dirman_passwd, nolookup=False): search_filter = '((nsuniqueid=---)(objectclass=nstombstone))' try: entries = thisrepl.conn.get_entries( -api.env.basedn, thisrepl.conn.SCOPE_ONELEVEL, search_filter, +api.env.basedn, thisrepl.conn.SCOPE_SUBTREE, search_filter, ['nsds50ruv']) except errors.NotFound: print No RUV records found. diff --git a/ipatests/test_integration/test_simple_replication.py b/ipatests/test_integration/test_simple_replication.py index 2d8f9fcfe53e33b94085d5cc9485461c58a37f39..998b1196a24ef52b88ab4a6248cdc2d1f808677d 100644 --- a/ipatests/test_integration/test_simple_replication.py +++ b/ipatests/test_integration/test_simple_replication.py @@ -59,3 +59,13 @@ class TestSimpleReplication(IntegrationTest): def test_user_replication_to_master(self): Test user replication replica - master self.check_replication(self.replicas[0], self.master, 'testuser2') + +def test_replica_removal(self): +Test replica removal +result = self.master.run_command(['ipa-replica-manage', 'list']) +assert self.replicas[0].hostname in result.stdout_text +# has to be run with --force, there is no --unattended +self.master.run_command(['ipa-replica-manage', 'del', + self.replicas[0].hostname, '--force']) +result = self.master.run_command(['ipa-replica-manage', 'list']) +assert self.replicas[0].hostname not in result.stdout_text -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance
On 09/02/2013 09:42 AM, Petr Spacek wrote: On 27.8.2013 23:08, Dmitri Pal wrote: On 08/27/2013 03:05 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 08/09/2013 08:30 AM, Petr Spacek wrote: Hello, I would like to get opinions about key maintenance for DNSSEC. Problem summary: - FreeIPA will support DNSSEC - DNSSEC deployment requires 2,n cryptographic keys for each DNS zone (i.e. objects in LDAP) - The same keys are shared by all FreeIPA servers - Keys have limited lifetime and have to be re-generated on monthly basics (in very first approximation, it will be configurable and the interval will differ for different key types) - The plan is to store keys in LDAP and let 'something' (i.e. certmonger or oddjob?) to generate and store the new keys back into LDAP - There are command line tools for key-generation (dnssec-keygen from the package bind-utils) - We plan to select one super-master which will handle regular key-regeneration (i.e. do the same as we do for special CA certificates) - Keys stored in LDAP will be encrypted somehow, most probably by some symmetric key shared among all IPA DNS servers Could certmonger or oddjob do key maintenance for us? I can imagine something like this: - watch some attributes in LDAP and wait until some key expires - run dnssec-keygen utility - read resulting keys and encrypt them with given 'master key' - store resulting blobs in LDAP - wait until another key reaches expiration timestamp It is simplified, because there will be multiple keys with different lifetimes, but the idea is the same. All the gory details are in the thread '[Freeipa-devel] DNSSEC support design considerations: key material handling': https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html Nalin and others, what do you think? Is certmonger or oddjob the right place to do something like this? Thank you for your time! Was there any discussion of this mail? I think at least some of this was covered in another thread, DNSSEC support design considerations: key material handling at https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html rob Yes, I have found that thread though I have not found it to come to some conclusion and a firm plan. I will leave to Petr to summarize outstanding issues and repost them. All questions stated in the first e-mail in this thread are still open: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html There was no reply to these questions during my vacation, so I don't have much to add at the moment. Nalin, please, could you provide your opinion? How modular/extendible the certmonger is? Does it make sense to add DNSSEC key-management to certmonger? What about CA rotation problem? Can we share some algorithms (e.g. for super-master election) between CA rotation and DNSSEC key rotation mechanisms? BTW I like the idea of masters being responsible for generating a subset of the keys as Loris suggested. E-mail from Loris in archives: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html The idea seems really nice and simple, but I'm afraid that there could be some serious race conditions. - How will it work when topology changes? - What if number of masters is number of days in month? (= Auto-tune interval from month to smaller time period = Again, what should we do after a topology change?) - What we should do if topology was changed when a master was disconnected from the rest of the network? (I.e. Link over WAN was down at the moment of change.) What will happen after re-connection to the topology? Example: Time 0: Masters A, B; topology: A---B Time 1: Master A have lost connection to master B Time 2: Master C was added; topology: A § B---C Time 3 (Day 3): A + C did rotation at the same time Time 4: Connection was restored; topology: A---B---C Now what? I have a feeling that we need something like quorum protocol for writes (only for sensitive operations like CA cert and DNSSEC key rotations). http://en.wikipedia.org/wiki/Quorum_(distributed_computing) The other question is how should we handle catastrophic situations where more than half of masters were lost? (Two of three data centres were blown by a tornado etc.) It becomes more and more obvious that there is no simple solution that we can use out of box. Let us start with a single nominated server. If the server is lost the key rotation responsibility can be moved to some other server manually. Not optimal but at least the first step. The next step would be to be able to define alternative (failover) servers. Here is an example. Let us say we have masters A, B, C. In topology A - B - C. Master A is responsible for the key rotation B is the fail-over. The key rotation time would be in some way recorded in the replication agreement(s) between A B. If at the moment of the
Re: [Freeipa-devel] [SSSD] FreeIPA on Debian
As a possible approach to getting things started, would it be possible to use Alien and a JEOS install to get the FreeIPA server running on a Debian system, and then work on converting over the dependencies one at a time? It seems like there are likely to be a series of Debian vs Fedora issues, WRT things like Python Path (lib vs lib64) and so forth. Also, the Dogtag install is a very Custom way of configuring a Tomcat App. It is likely to But up against the Debian packaging standards for Java Web Apps: http://dep.debian.net/deps/dep7/ One other difference between the Debian and Fedora philosophies is that, after apt-get install, you tend to have a deployed service, whereas the Yum/RPM based approach calls for a post deployment configuration stage. It sounds like the effort should be split along the Core FreeIPA work and the Dogtag work. We used to have a Self-Signed Ca approach for IPA that would be useful to have again. With the current External CA work, we might be able to do something similar: generate the certificates we need in a self-signed manner and provide them to the IPA server. That will let the Dogtag effort continue without holding up the rest of the work. On 09/01/2013 04:35 PM, Timo Aaltonen wrote: On 01.09.2013 21:43, Dmitri Pal wrote: On 09/01/2013 02:20 PM, Timo Aaltonen wrote: On 31.08.2013 00:04, Dmitri Pal wrote: Hello, Sorry for cross posting to 4 different lists but it seems that this is the best way to include most of people who might be interested in this discussion. The question of When FreeIPA will be available on Debian? has been coming up periodically on the list(s) without any resolution. However it is clear that it would be beneficial for the community and the project. Hi, As you know, I've been packaging stuff for the past two years with the goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has been accomplished, but quite a bit is still missing too.. May be it is time to try again? Let us see why it yet has not happened? 1) Some components need to be ported to Debian especially Dogtag and a slew of its new RESTEasy dependencies. This requires time and quite an effort from someone familiar with the domain. Yes, this is the biggest blocker. Dogtag 9 is packaged in git and working, but I'm not going to push that to the distro. It can be used for testing the IPA server though, before we have Dogtag 10. Once the prereqs are in place the Dogtag git should be easy to rebase with 10.x. I did start packaging some of the dependencies, but hit a wall when some maven component needed a different release than another one.. AIUI this is a known issue with maven based projects.. Other blockers off the top of my head include: - support for shared certificate database in NSS * patches sent to the Debian bug (#537866), maintainer isn't too responsive How can we help? I don't think you can, guess it just needs some perseverance on my side.. - dyndb support in bind * haven't asked the maintainer to add it to bind9, it might happen Are you talking about byndb maintainer or bind9 Debian maintainer? May be we should connect the two? the debian bind maintainer, I heard from the dyndb maintainer that bind10 might support it natively, but getting that in Debian might still be further in the future, so if we'd need dyndb by early next year it's probably needed to have it via bind9 first. 3) Someone needs to own packages in Debian and maintain them, someone with good knowledge of the distro and time to take ownership of about 50 packages. I'm doing this on my spare time, which has meant obvious delays in shipping something. Would be great to have more skillful people (pun intended) on the pkg-freeipa team.. Are you the only person there so far? pretty much, there have been some debian developers sponsoring packages to the distro (I'm not a DD yet), but they've all fled before too long :) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance
On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: On 09/02/2013 09:42 AM, Petr Spacek wrote: On 27.8.2013 23:08, Dmitri Pal wrote: On 08/27/2013 03:05 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 08/09/2013 08:30 AM, Petr Spacek wrote: Hello, I would like to get opinions about key maintenance for DNSSEC. Problem summary: - FreeIPA will support DNSSEC - DNSSEC deployment requires 2,n cryptographic keys for each DNS zone (i.e. objects in LDAP) - The same keys are shared by all FreeIPA servers - Keys have limited lifetime and have to be re-generated on monthly basics (in very first approximation, it will be configurable and the interval will differ for different key types) - The plan is to store keys in LDAP and let 'something' (i.e. certmonger or oddjob?) to generate and store the new keys back into LDAP - There are command line tools for key-generation (dnssec-keygen from the package bind-utils) - We plan to select one super-master which will handle regular key-regeneration (i.e. do the same as we do for special CA certificates) - Keys stored in LDAP will be encrypted somehow, most probably by some symmetric key shared among all IPA DNS servers Could certmonger or oddjob do key maintenance for us? I can imagine something like this: - watch some attributes in LDAP and wait until some key expires - run dnssec-keygen utility - read resulting keys and encrypt them with given 'master key' - store resulting blobs in LDAP - wait until another key reaches expiration timestamp It is simplified, because there will be multiple keys with different lifetimes, but the idea is the same. All the gory details are in the thread '[Freeipa-devel] DNSSEC support design considerations: key material handling': https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html Nalin and others, what do you think? Is certmonger or oddjob the right place to do something like this? Thank you for your time! Was there any discussion of this mail? I think at least some of this was covered in another thread, DNSSEC support design considerations: key material handling at https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html rob Yes, I have found that thread though I have not found it to come to some conclusion and a firm plan. I will leave to Petr to summarize outstanding issues and repost them. All questions stated in the first e-mail in this thread are still open: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html There was no reply to these questions during my vacation, so I don't have much to add at the moment. Nalin, please, could you provide your opinion? How modular/extendible the certmonger is? Does it make sense to add DNSSEC key-management to certmonger? What about CA rotation problem? Can we share some algorithms (e.g. for super-master election) between CA rotation and DNSSEC key rotation mechanisms? BTW I like the idea of masters being responsible for generating a subset of the keys as Loris suggested. E-mail from Loris in archives: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html The idea seems really nice and simple, but I'm afraid that there could be some serious race conditions. - How will it work when topology changes? - What if number of masters is number of days in month? (= Auto-tune interval from month to smaller time period = Again, what should we do after a topology change?) - What we should do if topology was changed when a master was disconnected from the rest of the network? (I.e. Link over WAN was down at the moment of change.) What will happen after re-connection to the topology? Example: Time 0: Masters A, B; topology: A---B Time 1: Master A have lost connection to master B Time 2: Master C was added; topology: A § B---C Time 3 (Day 3): A + C did rotation at the same time Time 4: Connection was restored; topology: A---B---C Now what? I have a feeling that we need something like quorum protocol for writes (only for sensitive operations like CA cert and DNSSEC key rotations). http://en.wikipedia.org/wiki/Quorum_(distributed_computing) The other question is how should we handle catastrophic situations where more than half of masters were lost? (Two of three data centres were blown by a tornado etc.) It becomes more and more obvious that there is no simple solution that we can use out of box. Let us start with a single nominated server. If the server is lost the key rotation responsibility can be moved to some other server manually. Not optimal but at least the first step. The next step would be to be able to define alternative (failover) servers. Here is an example. Let us say we have masters A, B, C. In topology A - B - C. Master
Re: [Freeipa-devel] [SSSD] FreeIPA on Debian
On 09/03/2013 01:50 PM, Timo Aaltonen wrote: On 03.09.2013 23:30, Nathan Kinder wrote: On 09/01/2013 01:35 PM, Timo Aaltonen wrote: On 01.09.2013 21:43, Dmitri Pal wrote: On 09/01/2013 02:20 PM, Timo Aaltonen wrote: On 31.08.2013 00:04, Dmitri Pal wrote: Hello, Sorry for cross posting to 4 different lists but it seems that this is the best way to include most of people who might be interested in this discussion. The question of When FreeIPA will be available on Debian? has been coming up periodically on the list(s) without any resolution. However it is clear that it would be beneficial for the community and the project. Hi, As you know, I've been packaging stuff for the past two years with the goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has been accomplished, but quite a bit is still missing too.. May be it is time to try again? Let us see why it yet has not happened? 1) Some components need to be ported to Debian especially Dogtag and a slew of its new RESTEasy dependencies. This requires time and quite an effort from someone familiar with the domain. Yes, this is the biggest blocker. Dogtag 9 is packaged in git and working, but I'm not going to push that to the distro. It can be used for testing the IPA server though, before we have Dogtag 10. Once the prereqs are in place the Dogtag git should be easy to rebase with 10.x. I did start packaging some of the dependencies, but hit a wall when some maven component needed a different release than another one.. AIUI this is a known issue with maven based projects.. I would like to organize the effort to get Dogtag 10 ported to Debian. I know that there are a lot of dependencies needed for this to happen. I can create and maintain a wiki page to track all of the work that is needed to get this porting done. Do you have a list of Dogtag 10 dependencies that are not currently packaged for Debian that I can use as a starting point? Once we have a clear outline of what is needed, we can start trying to divide up and schedule the work. Alright, nice! This is the list I sent to debian-java a year ago, roughly in dependency order: Great, this will help me get started. It might be a bit out of date, as I know that we worked on reducing the number of dependencies within the last year. I'll start with this and cross-reference with the current dependencies. codehaus-parent keytool-maven-plugin maven-help-plugin maven-idea-plugin maven-jarsigner-plugin maven-jxr maven-source-plugin geronimo-parent-poms geronimo-annotation plexus-mail-sender maven-release plexus-resources maven-checkstyle-plugin maven-pmd-plugin maven-anno-plugin maven-reporting-api maven-changes-plugin maven-deploy-plugin apache-james-project javamail base64coder gdata-java sonatype-oss-parent forge-parent mojo-parent maven-plugin-build-helper relaxngcc xsom glassfish-fastinfoset jvnet-parent glassfish-jaxb-api glassfish-dtd-parser stax-ex istack-commons rngom glassfish-jaxb maven-jaxb2-plugin jboss-parent jandex jboss-specs-parent jboss-annotations jetty-parent jetty-toolchain jetty-version-maven-plugin scannotation snakeyml resteasy There might be errors, now that I know that the fedora package of resteasy doesn't built everything to make the deps a bit easier? Yes, resteasy was trimmed to make things easier. And at least codehaus-parent, mojo-parent and jetty-parent are packaged and pushed to git.debian.org but since I'm not a DD (yet) I can't upload them. The debian java policy means that the actual package names are like 'libmojo-parent-java' etc., in case you try to find a package. Do you have more details on the maven issue you were running up against? if my notes are to be trusted, it was that keytool-maven-plugin wants v16 of mojo-parent, and not v30 that is in git now.. Ok, I'll note it down and we can figure out the details when we try it again. Thanks, -NGK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] FreeIPA on Debian
On 03.09.2013 23:30, Nathan Kinder wrote: On 09/01/2013 01:35 PM, Timo Aaltonen wrote: On 01.09.2013 21:43, Dmitri Pal wrote: On 09/01/2013 02:20 PM, Timo Aaltonen wrote: On 31.08.2013 00:04, Dmitri Pal wrote: Hello, Sorry for cross posting to 4 different lists but it seems that this is the best way to include most of people who might be interested in this discussion. The question of When FreeIPA will be available on Debian? has been coming up periodically on the list(s) without any resolution. However it is clear that it would be beneficial for the community and the project. Hi, As you know, I've been packaging stuff for the past two years with the goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has been accomplished, but quite a bit is still missing too.. May be it is time to try again? Let us see why it yet has not happened? 1) Some components need to be ported to Debian especially Dogtag and a slew of its new RESTEasy dependencies. This requires time and quite an effort from someone familiar with the domain. Yes, this is the biggest blocker. Dogtag 9 is packaged in git and working, but I'm not going to push that to the distro. It can be used for testing the IPA server though, before we have Dogtag 10. Once the prereqs are in place the Dogtag git should be easy to rebase with 10.x. I did start packaging some of the dependencies, but hit a wall when some maven component needed a different release than another one.. AIUI this is a known issue with maven based projects.. I would like to organize the effort to get Dogtag 10 ported to Debian. I know that there are a lot of dependencies needed for this to happen. I can create and maintain a wiki page to track all of the work that is needed to get this porting done. Do you have a list of Dogtag 10 dependencies that are not currently packaged for Debian that I can use as a starting point? Once we have a clear outline of what is needed, we can start trying to divide up and schedule the work. Alright, nice! This is the list I sent to debian-java a year ago, roughly in dependency order: codehaus-parent keytool-maven-plugin maven-help-plugin maven-idea-plugin maven-jarsigner-plugin maven-jxr maven-source-plugin geronimo-parent-poms geronimo-annotation plexus-mail-sender maven-release plexus-resources maven-checkstyle-plugin maven-pmd-plugin maven-anno-plugin maven-reporting-api maven-changes-plugin maven-deploy-plugin apache-james-project javamail base64coder gdata-java sonatype-oss-parent forge-parent mojo-parent maven-plugin-build-helper relaxngcc xsom glassfish-fastinfoset jvnet-parent glassfish-jaxb-api glassfish-dtd-parser stax-ex istack-commons rngom glassfish-jaxb maven-jaxb2-plugin jboss-parent jandex jboss-specs-parent jboss-annotations jetty-parent jetty-toolchain jetty-version-maven-plugin scannotation snakeyml resteasy There might be errors, now that I know that the fedora package of resteasy doesn't built everything to make the deps a bit easier? And at least codehaus-parent, mojo-parent and jetty-parent are packaged and pushed to git.debian.org but since I'm not a DD (yet) I can't upload them. The debian java policy means that the actual package names are like 'libmojo-parent-java' etc., in case you try to find a package. Do you have more details on the maven issue you were running up against? if my notes are to be trusted, it was that keytool-maven-plugin wants v16 of mojo-parent, and not v30 that is in git now.. -- t ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] FreeIPA on Debian
Jumping in here, if someone is organizing a TODO list to get freeipa on debian, feel free to add porting/testing puppet-ipa to this. I'm the puppet-ipa [1] guy. I'm happy to work on that part whenever someone has a working debian freeipa install for me to use. Once it works or at least mostly, feel free to ping me somehow. HTH, James [1] https://github.com/purpleidea/puppet-ipa ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] FreeIPA on Debian
On 09/01/2013 01:35 PM, Timo Aaltonen wrote: On 01.09.2013 21:43, Dmitri Pal wrote: On 09/01/2013 02:20 PM, Timo Aaltonen wrote: On 31.08.2013 00:04, Dmitri Pal wrote: Hello, Sorry for cross posting to 4 different lists but it seems that this is the best way to include most of people who might be interested in this discussion. The question of When FreeIPA will be available on Debian? has been coming up periodically on the list(s) without any resolution. However it is clear that it would be beneficial for the community and the project. Hi, As you know, I've been packaging stuff for the past two years with the goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has been accomplished, but quite a bit is still missing too.. May be it is time to try again? Let us see why it yet has not happened? 1) Some components need to be ported to Debian especially Dogtag and a slew of its new RESTEasy dependencies. This requires time and quite an effort from someone familiar with the domain. Yes, this is the biggest blocker. Dogtag 9 is packaged in git and working, but I'm not going to push that to the distro. It can be used for testing the IPA server though, before we have Dogtag 10. Once the prereqs are in place the Dogtag git should be easy to rebase with 10.x. I did start packaging some of the dependencies, but hit a wall when some maven component needed a different release than another one.. AIUI this is a known issue with maven based projects.. I would like to organize the effort to get Dogtag 10 ported to Debian. I know that there are a lot of dependencies needed for this to happen. I can create and maintain a wiki page to track all of the work that is needed to get this porting done. Do you have a list of Dogtag 10 dependencies that are not currently packaged for Debian that I can use as a starting point? Once we have a clear outline of what is needed, we can start trying to divide up and schedule the work. Do you have more details on the maven issue you were running up against? Thanks, -NGK Other blockers off the top of my head include: - support for shared certificate database in NSS * patches sent to the Debian bug (#537866), maintainer isn't too responsive How can we help? I don't think you can, guess it just needs some perseverance on my side.. - dyndb support in bind * haven't asked the maintainer to add it to bind9, it might happen Are you talking about byndb maintainer or bind9 Debian maintainer? May be we should connect the two? the debian bind maintainer, I heard from the dyndb maintainer that bind10 might support it natively, but getting that in Debian might still be further in the future, so if we'd need dyndb by early next year it's probably needed to have it via bind9 first. 3) Someone needs to own packages in Debian and maintain them, someone with good knowledge of the distro and time to take ownership of about 50 packages. I'm doing this on my spare time, which has meant obvious delays in shipping something. Would be great to have more skillful people (pun intended) on the pkg-freeipa team.. Are you the only person there so far? pretty much, there have been some debian developers sponsoring packages to the distro (I'm not a DD yet), but they've all fled before too long :) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
