[Freeipa-devel] [PATCH] 0016..0018 profiles regression fixes
Patches 16 and 17 fix regressions in the default profile.
Patch 18 fixes the `ipa-replica-install --setup-ca' breakage.
Cheers,
Fraser
From bc2b1d729c50dc1ae88a5e5709f655ea2f5ecd66 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Thu, 4 Jun 2015 22:49:01 -0400
Subject: [PATCH 16/18] Fix certificate subject base
Profile management patches introduced a regression where a custom
certificate subject base (if configured) is not used in the default
profile. Use the configured subject base.
Part of: https://fedorahosted.org/freeipa/ticket/4002
---
ipaserver/install/cainstance.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index
ca0b6df5db80bc842a78f614872831ddd82330b1..42225c28c8201bbae8ac0e46f7791a7f6ed3d158
100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -1665,7 +1665,7 @@ def import_included_profiles():
DOMAIN=ipautil.format_netloc(api.env.domain),
IPA_CA_RECORD=IPA_CA_RECORD,
CRL_ISSUER='CN=Certificate Authority,o=ipaca',
-SUBJECT_DN_O=str(DN(('O', api.env.realm))),
+SUBJECT_DN_O=dsinstance.DsInstance().find_subject_base(),
)
server_id = installutils.realm_to_serverid(api.env.realm)
--
2.1.0
From dcf1531b109a0ebacb060be4b443df013957c56e Mon Sep 17 00:00:00 2001
From: Fraser Tweedale ftwee...@redhat.com
Date: Fri, 5 Jun 2015 02:57:48 -0400
Subject: [PATCH 17/18] Import profiles earlier during install
Currently, IPA certificate profile import happens at end of install.
Certificates issuance during the install process does work but uses
an un-customised caIPAserviceCert profile, resulting in incorrect
subject DNs and missing extensions. Furthermore, the
caIPAserviceCert profile shipped with Dogtag will eventually be
removed.
Move the import of included certificate profiles to the end of the
cainstance deployment phase, prior to the issuance of DS and HTTP
certificates.
Part of: https://fedorahosted.org/freeipa/ticket/4002
---
ipaserver/install/cainstance.py | 5 +
ipaserver/install/server/install.py | 3 ---
ipaserver/plugins/dogtag.py | 10 +++---
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index
42225c28c8201bbae8ac0e46f7791a7f6ed3d158..563a198ab472a58cc6fbeeceb7731486ce7ca6b5
100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -473,6 +473,9 @@ class CAInstance(DogtagInstance):
self.step(configure Server-Cert certificate renewal,
self.track_servercert)
self.step(Configure HTTP to proxy connections,
self.http_proxy)
+if not self.clone:
+self.step(restarting certificate server,
self.restart_instance)
+self.step(Importing IPA certificate profiles,
import_included_profiles)
self.start_creation(runtime=210)
@@ -1694,6 +1697,7 @@ def import_included_profiles():
)
conn.add_entry(entry)
api.Backend.ra_certprofile._read_password()
+api.Backend.ra_certprofile.override_port = 8443
with api.Backend.ra_certprofile as profile_api:
# import the profile
try:
@@ -1715,6 +1719,7 @@ def import_included_profiles():
except errors.RemoteRetrieveError:
pass
+api.Backend.ra_certprofile.override_port = None
root_logger.info(Imported profile '%s', profile_id)
conn.disconnect()
diff --git a/ipaserver/install/server/install.py
b/ipaserver/install/server/install.py
index
955e4cc11fba20475a07126f4101edbf1024290e..999766d677a19768fdc31b256a2d026b2204dbb0
100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -906,9 +906,6 @@ def install(options):
service.print_msg(Restarting the certificate server)
ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME)
-service.print_msg(Importing certificate profiles)
-cainstance.import_included_profiles()
-
if options.setup_dns:
api.Backend.ldap2.connect(autobind=True)
dns.install(False, False, options)
diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py
index
e6668bb43b994863a14fdd347635753422ed9388..4b9d82a84e387758113066163c8346db69a734e1
100644
--- a/ipaserver/plugins/dogtag.py
+++ b/ipaserver/plugins/dogtag.py
@@ -1973,6 +1973,7 @@ class RestClient(Backend):
super(RestClient, self).__init__()
# session cookie
+self.override_port = None
self.cookie = None
def _read_password(self):
@@ -2007,7 +2008,8 @@ class RestClient(Backend):
if self.cookie is not None:
return
status, status_text, resp_headers, resp_body = dogtag.https_request(
-self.ca_host,
Re: [Freeipa-devel] [PATCH] 0016..0018 profiles regression fixes
On Fri, Jun 05, 2015 at 01:00:14PM +0200, Martin Basti wrote: On 05/06/15 11:47, Fraser Tweedale wrote: Patches 16 and 17 fix regressions in the default profile. Patch 18 fixes the `ipa-replica-install --setup-ca' breakage. Cheers, Fraser NACK, sorry ./make-lint * Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:2010: [E1124(redundant-keyword-arg), RestClient.__enter__] Argument 'method' passed by position and keyword in function call) ipaserver/plugins/dogtag.py:2011: [E0602(undefined-variable), RestClient.__enter__] Undefined variable 'ca_host') -- Martin Basti Whoops. One wayward comma that should have been a period! Here's an updated 0017..0018. Thanks, Fraser From 61677911dec136e6d022622549c476f8ca5f6e5b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale ftwee...@redhat.com Date: Fri, 5 Jun 2015 02:57:48 -0400 Subject: [PATCH 17/18] Import profiles earlier during install Currently, IPA certificate profile import happens at end of install. Certificates issuance during the install process does work but uses an un-customised caIPAserviceCert profile, resulting in incorrect subject DNs and missing extensions. Furthermore, the caIPAserviceCert profile shipped with Dogtag will eventually be removed. Move the import of included certificate profiles to the end of the cainstance deployment phase, prior to the issuance of DS and HTTP certificates. Part of: https://fedorahosted.org/freeipa/ticket/4002 --- ipaserver/install/cainstance.py | 5 + ipaserver/install/server/install.py | 3 --- ipaserver/plugins/dogtag.py | 10 +++--- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index 42225c28c8201bbae8ac0e46f7791a7f6ed3d158..563a198ab472a58cc6fbeeceb7731486ce7ca6b5 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -473,6 +473,9 @@ class CAInstance(DogtagInstance): self.step(configure Server-Cert certificate renewal, self.track_servercert) self.step(Configure HTTP to proxy connections, self.http_proxy) +if not self.clone: +self.step(restarting certificate server, self.restart_instance) +self.step(Importing IPA certificate profiles, import_included_profiles) self.start_creation(runtime=210) @@ -1694,6 +1697,7 @@ def import_included_profiles(): ) conn.add_entry(entry) api.Backend.ra_certprofile._read_password() +api.Backend.ra_certprofile.override_port = 8443 with api.Backend.ra_certprofile as profile_api: # import the profile try: @@ -1715,6 +1719,7 @@ def import_included_profiles(): except errors.RemoteRetrieveError: pass +api.Backend.ra_certprofile.override_port = None root_logger.info(Imported profile '%s', profile_id) conn.disconnect() diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py index 955e4cc11fba20475a07126f4101edbf1024290e..999766d677a19768fdc31b256a2d026b2204dbb0 100644 --- a/ipaserver/install/server/install.py +++ b/ipaserver/install/server/install.py @@ -906,9 +906,6 @@ def install(options): service.print_msg(Restarting the certificate server) ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME) -service.print_msg(Importing certificate profiles) -cainstance.import_included_profiles() - if options.setup_dns: api.Backend.ldap2.connect(autobind=True) dns.install(False, False, options) diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py index e6668bb43b994863a14fdd347635753422ed9388..e60cced1a35df821d900407df2d9b66371c61510 100644 --- a/ipaserver/plugins/dogtag.py +++ b/ipaserver/plugins/dogtag.py @@ -1973,6 +1973,7 @@ class RestClient(Backend): super(RestClient, self).__init__() # session cookie +self.override_port = None self.cookie = None def _read_password(self): @@ -2007,7 +2008,8 @@ class RestClient(Backend): if self.cookie is not None: return status, status_text, resp_headers, resp_body = dogtag.https_request( -self.ca_host, self.env.ca_agent_port, '/ca/rest/account/login', +self.ca_host, self.override_port or self.env.ca_agent_port, +'/ca/rest/account/login', self.sec_dir, self.password, self.ipa_certificate_nickname, method='GET' ) @@ -2020,7 +2022,8 @@ class RestClient(Backend): def __exit__(self, exc_type, exc_value, traceback): Log out of the REST API dogtag.https_request( -self.ca_host, self.env.ca_agent_port, '/ca/rest/account/logout', +self.ca_host, self.override_port or self.env.ca_agent_port, +
Re: [Freeipa-devel] [PATCH] 0016..0018 profiles regression fixes
Is it supposeed to fis this issue? 2015-06-05T12:11:57Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py, line 44, in run import ipaserver.plugins.dogtag # ensure profile backend gets loaded File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1273, in module raise SkipPluginModule(reason='dogtag not selected as RA plugin') On 06/05/2015 01:53 PM, Fraser Tweedale wrote: On Fri, Jun 05, 2015 at 01:00:14PM +0200, Martin Basti wrote: On 05/06/15 11:47, Fraser Tweedale wrote: Patches 16 and 17 fix regressions in the default profile. Patch 18 fixes the `ipa-replica-install --setup-ca' breakage. Cheers, Fraser NACK, sorry ./make-lint * Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:2010: [E1124(redundant-keyword-arg), RestClient.__enter__] Argument 'method' passed by position and keyword in function call) ipaserver/plugins/dogtag.py:2011: [E0602(undefined-variable), RestClient.__enter__] Undefined variable 'ca_host') -- Martin Basti Whoops. One wayward comma that should have been a period! Here's an updated 0017..0018. Thanks, Fraser -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0049] Move CA installation code into single module.
On 06/03/2015 05:49 PM, David Kupka wrote:
Updated patch attached.
--
David Kupka
From ca004a585f86a5e35d02a90dc9db0753f786b84a Mon Sep 17 00:00:00 2001
From: David Kupka dku...@redhat.com
Date: Wed, 3 Jun 2015 17:43:27 +0200
Subject: [PATCH] Move CA installation code into single module.
---
install/tools/ipa-ca-install | 251 +++
install/tools/ipa-replica-install | 3 +
ipaserver/install/ca.py| 267 +
ipaserver/install/server/install.py| 101 ++-
ipaserver/install/server/replicainstall.py | 46 ++---
5 files changed, 325 insertions(+), 343 deletions(-)
create mode 100644 ipaserver/install/ca.py
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index f087d2d6a5138915008395cde4c461fc7602811b..36b89b6437c21ff7538708858966915ce214ffec 100755
--- a/install/tools/ipa-ca-install
+++ b/install/tools/ipa-ca-install
@@ -21,26 +21,18 @@
import sys
import os
import shutil
-from ConfigParser import RawConfigParser
from ipapython import ipautil
from ipaserver.install import installutils
from ipaserver.install import certs
-from ipaserver.install.installutils import (HostnameLocalhost, ReplicaConfig,
-expand_replica_info, read_replica_info, get_host_name, BadHostError,
-private_ccache, read_replica_info_dogtag_port, load_external_cert,
-create_replica_config)
-from ipaserver.install import dsinstance, cainstance, bindinstance
-from ipaserver.install.replication import replica_conn_check
+from ipaserver.install.installutils import (private_ccache,
+create_replica_config)
+from ipaserver.install import dsinstance, ca
from ipapython import version
-from ipalib import api, certstore, x509
+from ipalib import api
from ipapython.dn import DN
from ipapython.config import IPAOptionParser
-from ipapython import sysrestore
-from ipapython import dogtag
-from ipapython import certdb
from ipapython.ipa_log_manager import *
-from ipaplatform import services
from ipaplatform.paths import paths
log_file_name = paths.IPAREPLICA_CA_INSTALL_LOG
@@ -86,6 +78,9 @@ def parse_options():
if len(args) != 1:
parser.error(you must provide a file generated by
ipa-replica-prepare)
+
+options.external_ca = None
+options.external_cert_files = None
else:
filename = None
@@ -106,31 +101,6 @@ def get_dirman_password():
Directory Manager (existing master), confirm=False, validate=False)
-def check_ca():
-if not cainstance.check_port():
-print IPA requires port 8443 for PKI but it is currently in use.
-sys.exit(1)
-
-def install_dns_records(config, options):
-
-if not bindinstance.dns_container_exists(config.master_host_name,
- ipautil.realm_to_suffix(config.realm_name),
- dm_password=config.dirman_password):
-return
-
-bind = bindinstance.BindInstance(dm_password=config.dirman_password)
-disconnect = False
-try:
-if not api.Backend.ldap2.isconnected():
-api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
- bind_pw=config.dirman_password)
-disconnect = True
-bind.add_ipa_ca_dns_records(config.host_name, config.domain_name)
-finally:
-if api.Backend.ldap2.isconnected() and disconnect:
-api.Backend.ldap2.disconnect()
-
-
def install_replica(safe_options, options, filename):
standard_logging_setup(log_file_name, debug=options.debug)
@@ -141,18 +111,12 @@ def install_replica(safe_options, options, filename):
if not ipautil.file_exists(filename):
sys.exit(Replica file %s does not exist % filename)
-global sstore
-sstore = sysrestore.StateFile(paths.SYSRESTORE)
-
if not dsinstance.DsInstance().is_configured():
sys.exit(IPA server is not configured on this system.\n)
api.bootstrap(in_server=True)
api.finalize()
-if api.env.ra_plugin == 'selfsign':
-sys.exit('A selfsign CA can not be added')
-
# get the directory manager password
dirman_password = options.password
if not dirman_password:
@@ -174,48 +138,17 @@ def install_replica(safe_options, options, filename):
REPLICA_INFO_TOP_DIR = config.top_dir
config.setup_ca = True
-if not ipautil.file_exists(config.dir + /cacert.p12):
-print 'CA cannot be installed in CA-less setup.'
-sys.exit(1)
+api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
+ bind_pw=dirman_password)
-if not options.skip_conncheck:
-replica_conn_check(
-config.master_host_name, config.host_name, config.realm_name, True,
-config.ca_ds_port, options.admin_password)
+options.realm_name = config.realm_name
+
Re: [Freeipa-devel] [PATCH] 828 webui: don't log in back after logout
On 07/05/15 19:24, Petr Vobornik wrote: Automatic login attempt is initiated by first failed xhr request which happens in metadata phase. New phase was added before metadata phase. It interrupts UI load and shows login page if it's directly after logout(marked in session storage). Successfull manual login resolves the phase so that metadata phase can follow. https://fedorahosted.org/freeipa/ticket/5008 ACK -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Password vault
Dne 3.6.2015 v 14:17 Jan Cholasta napsal(a): Dne 2.6.2015 v 02:00 Endi Sukma Dewata napsal(a): Please take a look at the updated patch. On 5/27/2015 12:39 AM, Jan Cholasta wrote: 21) vault_archive is not a retrieve operation, it should be based on LDAPUpdate instead of LDAPRetrieve. Or Command actually, since it does not do anything with LDAP. The same applies to vault_retrieve. The vault_archive does not actually modify the LDAP entry because it stores the data in KRA. It is actually an LDAPRetrieve operation because it needs to get the vault info before it can perform the archival operation. Same thing with vault_retrieve. It is not a LDAPRetrieve operation, because it has different semantics. Please use Command as base class and either use ldap2 for direct LDAP or call vault_show instead of hacking around LDAPRetrieve. It's been changed to inherit from LDAPQuery instead. NACK, it's not a LDAPQuery operation, because it has different semantics. There is more to a command than executing code, so you should use a correct base class. Changed to inherit from Command as requested. Now these commands no longer have a direct access to the vault object (self.obj) although they are accessing vault objects like other vault commands. Also now the vault name argument has to be added explicitly on each command. You can inherit from crud.Retrieve and crud.Update to get self.obj and the argument back. I tried this: class vault_retrieve(Command, crud.Retrieve): and it gave me an error: TypeError: Error when calling the metaclass bases Cannot create a consistent method resolution order (MRO) for bases Retrieve, Command I'm sticking with the original code since it works fine although not ideal. I'm not a Python expert, so if you know how to fix this properly please feel free to post a patch on top of this. The class hierarchy is as follows: frontend.Command frontend.Method crud.PKQuery crud.Retrieve cdur.Update So removing Command from the list of base classes should fix it. If KRA is not installed, vault-archive and vault-retrieve fail with internal error. Added a code to check KRA installation in all vault commands. If you know a way not to load the vault plugin if the KRA is not installed please let me know, that's probably even better. Not sure how that will work on the client side though. I see this has been already resolved in the other thread. The commands still behave differently based on whether they were called from API which was initialized with in_server set to True or False. That is unfortunately a restriction imposed by the framework. In order to guarantee the security, the vault is designed to have separate client and server code. The client code encrypts the secret, the server code forwards the encrypted secret to KRA. To archive a secret into a vault properly, you are supposed to call the client code. If you're calling the server code directly, you are responsible to do your own encryption (i.e. generating session key, nonce, and vault data). I understand why the code has to be separated, what I don't understand is why it is in fact *not* separated and crammed into a single command, making weird and undefined behavior possible. If another plugin wants to use vault, it should implement a client code which calls the vault client code to perform the archival from the client side. What is the use case for calling the vault API from the server side anyway? Wouldn't that defeat the purpose of having a vault? If a secret exists on the server side in an unencrypted form doesn't it mean the secret may already have been compromised? Server API is used not only by the server itself, but also by installers for example. Anyway the point is that there *can't* be a broken API like this, you should at least raise an error if the command is called from server API, although actually separating it into client and server parts would be preferable. There is no point in exposing the session_key, nonce and vault_data options in CLI when their value is always overwritten in forward(). I agree there is no need to expose them in CLI, but in this framework the API also defines the CLI. If there's a way to keep them in the server API but not expose them in the CLI please let me know. Or, if there's a way to define completely separate server API (without a matching client CLI) and client CLI (without a matching server API) that will work too. As I suggested above, you can split the commands into separate client and server commands. The client command should inherit from frontend.Local so that it is always executed locally and the server command should have a NO_CLI = True attribute so that it is not available in the CLI. Will this always succeed? +# deactivate vault record in KRA +response = kra_client.keys.list_keys( +client_key_id, pki.key.KeyClient.KEY_STATUS_ACTIVE)
Re: [Freeipa-devel] [PATCH] 0016..0018 profiles regression fixes
On 05/06/15 14:16, Oleg Fayans wrote: Is it supposeed to fis this issue? 2015-06-05T12:11:57Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py, line 44, in run import ipaserver.plugins.dogtag # ensure profile backend gets loaded File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1273, in module raise SkipPluginModule(reason='dogtag not selected as RA plugin') No On 06/05/2015 01:53 PM, Fraser Tweedale wrote: On Fri, Jun 05, 2015 at 01:00:14PM +0200, Martin Basti wrote: On 05/06/15 11:47, Fraser Tweedale wrote: Patches 16 and 17 fix regressions in the default profile. Patch 18 fixes the `ipa-replica-install --setup-ca' breakage. Cheers, Fraser NACK, sorry ./make-lint * Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:2010: [E1124(redundant-keyword-arg), RestClient.__enter__] Argument 'method' passed by position and keyword in function call) ipaserver/plugins/dogtag.py:2011: [E0602(undefined-variable), RestClient.__enter__] Undefined variable 'ca_host') -- Martin Basti Whoops. One wayward comma that should have been a period! Here's an updated 0017..0018. Thanks, Fraser -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 831 webui: better error reporting
On 15/05/15 11:02, Petr Vobornik wrote: Helps in development and debugging. - ActionDropdownWidget - report error if required action is missing - report build errors to console ACK -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [patch 0002] Abstract the HostTracker class from host plugin test
On 06/02/2015 10:27 AM, Milan Kubik wrote: Hello, this is the (first) patch with the Tracker class implementation based on host plugin test. It is meant to be used as a base class to implement a helper class to write xml-rpc (api) tests for LDAP based plugins and to replace the Declarative class which is used for most of the xml-rpc tests at the moment. For an example usage take a look at the host plugin test. Cheers, Milan Hello! Thanks for the patch. Works for me, ACK. -- David Kupka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Suggestion for the A part of IPA
-Original Message-
From: Martin Kosek [mailto:mko...@redhat.com]
Sent: 05 June 2015 13:31
To: Innes, Duncan; freeipa-devel@redhat.com; Jakub Hrozek
Subject: Re: [Freeipa-devel] Suggestion for the A part of IPA
On 06/02/2015 10:29 AM, Innes, Duncan wrote:
Just a bit of a head's up and a refresh of this with perhaps some
new
data.
We have more now! I created
https://www.freeipa.org/page/Centralized_Logging
where you can read more about this POC project and even see demo
showing
what the current POC ELK server can do (with link to Docker server
container and sources of course).
Excellent stuff - I fumbled together the page linked in your Other
Resources section at the bottom.
Will be upgrading my configs to replicate what you've done with respect
to
pulling in extra log files.
Thoughts? I'm not saying they should always be paired, but that if
a
user designs a system with enough horse power, this piggy-backing
could work well.
Ah, interesting idea and measurement. We have not thought about this
kind
of architecture yet. What we did in our POC is to configure FreeIPA
clients and servers to send the logs directly to the logging server
which
was on completely different machine (container) than rest of the
infrastructure.
It may be an alternative scheme, to have FreeIPA server containing the
log processing and then forwarding further to other REK/ELK server and
clients simply forwarding the logs to the same server as where they
are
authenticating.
If all the log configuration is baked in
ipa-{server,replica,client}-install, it would be extremely easy to
integrate.
I was also thinking that this kind of setup would work well in a heavily
firewalled environment. We have both hardware and host-based iptables
firewalls across the estate. In our case, pairing the firewall rules
for logging to the IPA servers is much easier than creating new servers
and requesting separate rules for them. Every client need to talk to
the
IPA servers via the IPA ports after all. Adding in an extra port to the
firewall rule group for IPA isn't hard to maintain.
I am not sure if the authentication+logging binding would be that
easy,
nor that it belong together that much. SSSD would need to dynamically
export the address of the FreeIPA server it communicates with, maybe
similarly as it does with Kerberos
(http://linux.die.net/man/8/sssd_krb5_locator_plugin) - but that does
not seem as a good fit either.
No - perhaps not. Again I'm thinking more from my current situation.
We
were not given access to create _SRV_ records by the AD team, so we have
had to hard-code our IPA servers into the config files. i.e.
[domain/unix.example.com]
cache_credentials = True
krb5_realm = UNIX.EXAMPLE.COM
ipa_domain = unix.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = client01.unix.example.com
chpass_provider = ipa
ipa_server = ipa01.unix.example.com, ipa02.unix.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
We try and figure out which IPA servers we can see, then randomise the
order of available servers and put it in the ipa_server setting.
So relatively simple for our setup to copy this config into an rsyslog.d
config file. Less easy if you just use _srv_ in there.
Not sure how you'd do that to be fair. But if it's possible to parse
the data coming back from the DNS _SRV_ query, couldn't all the
potential
IPA servers be included for rsyslog failover?
If all my remote servers are down, my failover reverts to /dev/null, so
no data will be written to disk if I'm isolated.
That's for rsyslog of course. I'm also working on getting
systemd-journal-upload to send direct to logstash (hopefully with the
http input plugin).
In any case, CCing Jakub for reference.
Thanks,
Martin
This message has been checked for viruses and spam by the Virgin Money email
scanning system powered by Messagelabs.
This e-mail is intended to be confidential to the recipient. If you receive a
copy in error, please inform the sender and then delete this message.
Virgin Money plc - Registered in England and Wales (Company no. 6952311).
Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL.
Virgin Money plc is authorised by the Prudential Regulation Authority and
regulated by the Financial Conduct Authority and the Prudential Regulation
Authority.
The following companies also trade as Virgin Money. They are both authorised
and regulated by the Financial Conduct Authority, are registered in England and
Wales and have their registered office at Jubilee House, Gosforth, Newcastle
upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no.
3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482).
For further details of Virgin Money group companies please visit our website at
virginmoney.com
--
Manage your subscription for the Freeipa-devel mailing list:
Re: [Freeipa-devel] Password Maxlife 0 causes expiration of 90 days
On 06/04/2015 05:41 PM, Alexander Bokovoy wrote:
On Thu, 04 Jun 2015, Drew Erny wrote:
https://fedorahosted.org/freeipa/ticket/2795
I've tracked down the source of this bug; it's nutty C stuff.
So, in daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c, when you
update password, the expiration time appears to be set in the
function ipapwd_CheckPolicy on line 631, which looks like
data-expireTime = data-timeNow + pol.max_pwd_life;
So the bug has to be in how pol.max_pwd_life gets is value. So I
check around, pol is initialized like this:
struct ipapwd_policy pol = {0};
...
pol.max_pwd_life = IPAPWD_DEFAULT_PWDLIFE;
And IPAPWD_DEFAULT_PWDLIFE is a constant 90 days.
But then the actual value of max_pwd_life is obtained by passing pol
into the function ipapwd_getPolicy on line 577 or 590, depending on
the password change type.
Inside of ipapwd_getPolicy, there's a couple of lines starting at
line 393
tmpint = slapi_entry_attr_get_int(pe, krbMaxPwdLife);
if (tmpint != 0) {
policy-max_pwd_life = tmpint;
}:
Which sets the max password life to the returned value, unless this
function returns 0. However, the documentation from
/usr/include/dirsrv/slapi-plugin.h says that that function,
slapi_entry_attr_get_int, returns 0 if the entry does not contain
that attribute. So, since the value 0 is returned, an error is
assumed to have occurred that member of the struct is left
untouched... which means it's still set to the value it was set to
when it was initialized, 90 days.
So, when the expireTime is set at line 631, it's set to 90 days
because the value returned by slapi_entry_attr_get_int is 0.
I've checked to see if we can get some error context out of the pe
variable passed in, but it appears to be an opaque struct that the
user isn't meant to see the internals of.
I'm not really sure what to do with this knowledge. The only thing I
can think would be to use another sentinel value, like -1, to
indicate that the password does not expire; or, otherwise, to
document that there is no way to have non-expiring passwords, and
administrators can only set value to some far-future date, and then
close this bug. Or, we could just set the default expiration date to
be somewhere far in the future. I'm not really qualified to make a
call on how to proceed with this, but I'm capable of making the
change if someone more senior decides.
I can also totally see this issue with the interface of slapi-plugin
being the possible cause of many bugs.
You can use slapi_entry_attr_exists() to check if attribute does exist
and then treat result of slapi_entry_attr_get_int() as actual value.
Otherwise, that's a great investigation!
Using slapi_entry_attr_exists() clears us of having to worry about
getting an error condition back, but I'm still not confident how to
handle the 0 maximum. Should I just put in a far-future date?
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0051] Clear SSSD caches when uninstalling the client
How should https://www.redhat.com/archives/freeipa-users/2015-June/msg00116.html be handled where the user cleared out the db cache? On Fri, Jun 5, 2015 at 9:08 AM, Jakub Hrozek jhro...@redhat.com wrote: On Fri, Jun 05, 2015 at 05:03:08PM +0200, Martin Basti wrote: On 05/06/15 16:13, Gabe Alford wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5049 Thanks, Gabe Thank you. I dont think we should remove all SSSD caches. SSSD can have configured several providers not just IPA. IMO we should remove only IPA related caches, but wait for SSSD guys for their opinion. You could use the python configAPI SSSD has to query which SSSD domains are active. But if the uninstall script removes sss from nsswitch.conf maybe it's enough to remove the memcache (/var/lib/sss/mc/), the persistent cache will not be reachable at all. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0051] Clear SSSD caches when uninstalling the client
Thanks. Updated patch attached.
On Fri, Jun 5, 2015 at 9:53 AM, Jakub Hrozek jhro...@redhat.com wrote:
On Fri, Jun 05, 2015 at 09:46:05AM -0600, Gabe Alford wrote:
How should
https://www.redhat.com/archives/freeipa-users/2015-June/msg00116.html be
handled where the user cleared out the db cache?
Ah, I confused that one with another issue Jan Pazdziora had, which was
incidentally about client uninstall as well.
In that case, you can just remove the single ldb file that corresponds
to the domain that the client is leaving. Maybe it would be safer to mv
the files instead of remove them, but I guess if you run --uninstall,
you really want just to purge everything..
btw do the ipa installer tools support multiple domains at all?
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
From 40f7c3780baaf0b42d10c94c8527c9359a42247f Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Fri, 5 Jun 2015 11:27:46 -0600
Subject: [PATCH] Clear SSSD caches when uninstalling the client
https://fedorahosted.org/freeipa/ticket/5049
---
ipa-client/ipa-install/ipa-client-install | 13 +
ipaplatform/base/paths.py | 1 +
2 files changed, 14 insertions(+)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 63e3c9800791f3d29c977d63815c4291f5a235b9..a7a4e9780081559398bbbaa5b0e062dabb9e6f98 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -628,6 +628,19 @@ def uninstall(options, env):
Failed to remove krb5/LDAP configuration: %s, str(e))
return CLIENT_INSTALL_ERROR
+# Clean up the SSSD cache before SSSD service is stopped or restarted
+remove_file(paths.SSSD_MC_GROUP)
+remove_file(paths.SSSD_MC_PASSWD)
+
+ipa_domain = domain.get_option('ipa_domain')
+sssd_domain_ldb = cache_ + ipa_domain + .ldb
+sssd_ldb_file = os.path.join(paths.SSSD_DB, sssd_domain_ldb)
+remove_file(sssd_ldb_file)
+
+sssd_domain_ccache = ccache_ + ipa_domain.upper()
+sssd_ccache_file = os.path.join(paths.SSSD_DB, sssd_domain_ccache)
+remove_file(sssd_domain_ccache)
+
# Next if-elif-elif construction deals with sssd.conf file.
# Old pre-IPA domains are preserved due merging the old sssd.conf
# during the installation of ipa-client but any new domains are
diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index 9ba87523b5619188f02bdad6c23d2446a2c4b0f2..8bee3e7c5862a3815987fa1bd55fa90e25b95ebc 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -289,6 +289,7 @@ class BasePathNamespace(object):
KRA_BACKUP_KEYS_P12 = /var/lib/pki/pki-tomcat/alias/kra_backup_keys.p12
KRACERT_P12 = /root/kracert.p12
SAMBA_DIR = /var/lib/samba/
+SSSD_DB = /var/lib/sss/db
SSSD_MC_GROUP = /var/lib/sss/mc/group
SSSD_MC_PASSWD = /var/lib/sss/mc/passwd
SSSD_PUBCONF_KNOWN_HOSTS = /var/lib/sss/pubconf/known_hosts
--
1.8.3.1
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0026-0028] Fix nits in user-visible output
On 06/03/2015 03:55 PM, Martin Basti wrote: On 14/04/15 09:43, Petr Spacek wrote: On 14.4.2015 09:10, Martin Kosek wrote: On 04/13/2015 05:05 PM, Petr Spacek wrote: Hello, documentation team proposed few changes in user-visible messages so here it is. It was not worth a ticket and related overhead. The changes look OK to me. I would just have one (prudish) request to not add nazi reference to our git history - whether they are grammar or not. Please keep the git technical :-) Sure, here is the same patch with modified commit message. 0026 ACK 0027-2 ACK 0028 ACK pushed to master: * a62b37cda271b74005198e4c8cecfb5528041cfd Clarify messages related to adding DNS forwarders * 5bb35c1a295f61828dde17b2cbc04c5fb494e450 Grammar fix in 'Estimated time' messages printed by installer * 13700d9d3f9abd25c80af5edf406e7057e04f318 Clarify host name output in ipa-client-install -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Database error on replicas
Hi, So far I am still unable to reproduce the problem. Comparing the errors logs of failing replica vs successful replica they are very similar. Except this failure Failing one ... [03/Jun/2015:03:45:33 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: *LDAP error -1 (Can't contact LDAP server)* ((null)) errno 115 (Operation now in progress) [03/Jun/2015:03:45:33 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [03/Jun/2015:03:45:33 -0400] NSMMReplicationPlugin - agmt=cn=meTotestmaster.zaeba.li (testmaster:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [03/Jun/2015:03:45:38 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 2 (No such file or directory) many errors ... Successful one: ... [05/Jun/2015:17:51:20 +0200] NSMMReplicationPlugin - agmt=cn=meTovm-229.idm.lab.eng.brq.redhat.com (vm-229:389): Replication bind with GSSAPI auth failed: *LDAP error -2 (Local error)* (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [05/Jun/2015:17:51:23 +0200] NSMMReplicationPlugin - agmt=cn=meTovm-229.idm.lab.eng.brq.redhat.com (vm-229:389): Replication bind with GSSAPI auth resumed [05/Jun/2015:18:47:26 +0200] - slapd shutting down - signaling operation threads - op stack size 7 max work q size 2 max work q stack size 2 [05/Jun/2015:18:47:26 +0200] - slapd shutting down - waiting for 1 thread to terminate [05/Jun/2015:18:47:26 +0200] - slapd shutting down - closing down internal subsystems and plugins [05/Jun/2015:18:47:26 +0200] - Waiting for 4 database threads to stop [05/Jun/2015:18:47:27 +0200] - All database threads now stopped [05/Jun/2015:18:47:27 +0200] - slapd shutting down - freed 2 work q stack objects - freed 8 op stack objects [05/Jun/2015:18:47:27 +0200] - slapd stopped. ... This is looking like in the failing case, the replica is not able to connect to the master. In the successful tests I did not install DNS while it was installed in the failing tests. We need to retry with DNS configuration, because it could be part of the failure to access the master host. thanks theirry On 06/04/2015 07:27 PM, thierry bordaz wrote: Hello Oleg, So far I have been unable to reproduce the problem. I tried various scenarios depending if the first update was on master/slave, or with 2 slaves, 1 slave, 1slave added later. Do you have any detail how you did your test ? If you can restart the remaining VM, I would be interested in the logs (access/errors). thanks thierry On 06/03/2015 11:11 AM, Oleg Fayans wrote: Hi Martin, On 06/03/2015 10:46 AM, Martin Babinsky wrote: On 06/03/2015 10:33 AM, Oleg Fayans wrote: Hi, With the latest freeipa code containing Topology plugin patches, I am unable to make any changes in replicas. I have the following topology: replica1 = master = replica3 Here is the output of the ipa topologysegment-find command: Suffix name: realm -- 2 segments matched -- Segment name: replica1.zaeba.li-to-testmaster.zaeba.li Left node: replica1.zaeba.li Right node: testmaster.zaeba.li Connectivity: both Segment name: replica3.zaeba.li-to-testmaster.zaeba.li Left node: replica3.zaeba.li Right node: testmaster.zaeba.li Connectivity: both Number of entries returned 2 Any changes on master get replicated to replicas successfully. However, any attempts to change anything on replicas, for example, create a user, result in the error message about DatabaseError (attached). The corresponding part of the dirsrv log looks like this: 03/Jun/2015:04:11:55 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [03/Jun/2015:04:15:02 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 0 (Success) [03/Jun/2015:04:16:55 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 2 (No such file or directory) [03/Jun/2015:04:16:55 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) The full log is attached Hi Oleg, could you also post the output of 'journalctl -xe' related to dirsrv (on master and also on replicas)? I have seen a couple of segfaults there during reviewing Petr Vobornik's
Re: [Freeipa-devel] [PATCH 0001 v2] Migrate now accepts scope as argument
On 06/05/2015 01:50 PM, Martin Basti wrote:
On 04/06/15 21:36, Drew Erny wrote:
Whoops, hit the wrong reply.
On 06/04/2015 03:34 PM, Drew Erny wrote:
This is the same patch sort of manually rebased on the master branch.
I couldn't get it to cleanly rebase using tools, so I apply my commit
line-by-line; the only changes I made were pulling the scope =
_supported_scopes[options.get('scope')] out of the for loop I'd
accidentally left it in, and moving the import statement to a
different spot. Everything else should be the same, excep I
incremented VERSION and edited the comment.
I do have to convert to tuple, because that argument is expected to
be a tuple but .keys() returns a list.
Oh right, Enum requires explicitly tuple
On 06/04/2015 11:35 AM, Martin Basti wrote:
On 03/06/15 20:40, Drew Erny wrote:
Hi, all,
This is an updated patch, with the code changes suggested by Martin
Batsi in my test email. The biggest difference is that I had to do
from ldap import SCOPE_BASE, SCOPE_ONELEVEL, SCOPE_SUBTREE
To get access to those constants in the global scope. This seems
like a fairly clean solution, but if it's a code smell, feel free
to suggest improvements. This should have identical behavior to the
last patch, except it will autofill scope and no longer prompt
interactively.
Thanks,
Drew Erny
de...@redhat.com
Hello,
please continue discussion in the same thread :)
API.txt was changed, please update VERSION file, increment minor
version +1 and edit comment there. I forgot to tell you yesterday.
Can you rebase your patch to current master?
This patch is supposed to go to IPA 4.2.
Is the tuple conversion needed?
values=tuple(_supported_scopes.keys()),
Otherwise patch looks good.
Martin^2
--
Martin Basti
Thank you.
ACK, it works as expected.
Martin^2
Pushed to master: a57998f51eb8b62052fe021a68503eed4714c6d3
next time, please, include full link to the ticket, i.e., with protocol,
otherwise it is not clickable and ipa push tool doesn't recognize the
ticket.
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0051] Clear SSSD caches when uninstalling the client
On Fri, Jun 05, 2015 at 09:46:05AM -0600, Gabe Alford wrote: How should https://www.redhat.com/archives/freeipa-users/2015-June/msg00116.html be handled where the user cleared out the db cache? Ah, I confused that one with another issue Jan Pazdziora had, which was incidentally about client uninstall as well. In that case, you can just remove the single ldb file that corresponds to the domain that the client is leaving. Maybe it would be safer to mv the files instead of remove them, but I guess if you run --uninstall, you really want just to purge everything.. btw do the ipa installer tools support multiple domains at all? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 831 webui: better error reporting
On 06/05/2015 01:04 PM, Martin Basti wrote: On 15/05/15 11:02, Petr Vobornik wrote: Helps in development and debugging. - ActionDropdownWidget - report error if required action is missing - report build errors to console ACK Pushed to master: 847b5fd8d202e526c9d9599d5671808e9316aab7 -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 828 webui: don't log in back after logout
On 06/05/2015 12:39 PM, Martin Basti wrote: On 07/05/15 19:24, Petr Vobornik wrote: Automatic login attempt is initiated by first failed xhr request which happens in metadata phase. New phase was added before metadata phase. It interrupts UI load and shows login page if it's directly after logout(marked in session storage). Successfull manual login resolves the phase so that metadata phase can follow. https://fedorahosted.org/freeipa/ticket/5008 ACK Pushed to master: cd5fe9b4079c848667b1e7c41b2f5d6ab173ee5f -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [patch 0002] Abstract the HostTracker class from host plugin test
On 06/05/2015 03:32 PM, David Kupka wrote: On 06/02/2015 10:27 AM, Milan Kubik wrote: Hello, this is the (first) patch with the Tracker class implementation based on host plugin test. It is meant to be used as a base class to implement a helper class to write xml-rpc (api) tests for LDAP based plugins and to replace the Declarative class which is used for most of the xml-rpc tests at the moment. For an example usage take a look at the host plugin test. Cheers, Milan Hello! Thanks for the patch. Works for me, ACK. Pushed to master: d25a45a9f99aa5d841f47baa0332f49223ecffca I'm not sure, if this patch fixes the ticket or if it's just first of a series. Milan, please close the ticket if it is fixed by this patch. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0016..0018 profiles regression fixes
On 06/05/2015 05:09 PM, Martin Basti wrote: On 05/06/15 14:18, Martin Basti wrote: snip NACK, sorry snip Martin Basti Whoops. One wayward comma that should have been a period! Here's an updated 0017..0018. Thanks, Fraser -- Martin Basti ACK 16-1, 17-2, 18-2 pushed to master: * ce33f82cfe528c17d3a1367172bb1475fe169b25 Fix certificate subject base * 8b3bc99a737edb9178e115c188d60d963f73e50c Import profiles earlier during install * 355b6d416d800692f7028e057ff76aab9f8c0470 ipa-pki-proxy: allow certificate and password authentication -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0051] Clear SSSD caches when uninstalling the client
Jakub Hrozek wrote: On Fri, Jun 05, 2015 at 09:46:05AM -0600, Gabe Alford wrote: How should https://www.redhat.com/archives/freeipa-users/2015-June/msg00116.html be handled where the user cleared out the db cache? Ah, I confused that one with another issue Jan Pazdziora had, which was incidentally about client uninstall as well. In that case, you can just remove the single ldb file that corresponds to the domain that the client is leaving. Maybe it would be safer to mv the files instead of remove them, but I guess if you run --uninstall, you really want just to purge everything.. btw do the ipa installer tools support multiple domains at all? Yes, unless specifically requested an attempt is made to preserve the existing sssd.conf. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0001 v2] Migrate now accepts scope as argument
On 04/06/15 21:36, Drew Erny wrote:
Whoops, hit the wrong reply.
On 06/04/2015 03:34 PM, Drew Erny wrote:
This is the same patch sort of manually rebased on the master branch.
I couldn't get it to cleanly rebase using tools, so I apply my commit
line-by-line; the only changes I made were pulling the scope =
_supported_scopes[options.get('scope')] out of the for loop I'd
accidentally left it in, and moving the import statement to a
different spot. Everything else should be the same, excep I
incremented VERSION and edited the comment.
I do have to convert to tuple, because that argument is expected to
be a tuple but .keys() returns a list.
Oh right, Enum requires explicitly tuple
On 06/04/2015 11:35 AM, Martin Basti wrote:
On 03/06/15 20:40, Drew Erny wrote:
Hi, all,
This is an updated patch, with the code changes suggested by Martin
Batsi in my test email. The biggest difference is that I had to do
from ldap import SCOPE_BASE, SCOPE_ONELEVEL, SCOPE_SUBTREE
To get access to those constants in the global scope. This seems
like a fairly clean solution, but if it's a code smell, feel free
to suggest improvements. This should have identical behavior to the
last patch, except it will autofill scope and no longer prompt
interactively.
Thanks,
Drew Erny
de...@redhat.com
Hello,
please continue discussion in the same thread :)
API.txt was changed, please update VERSION file, increment minor
version +1 and edit comment there. I forgot to tell you yesterday.
Can you rebase your patch to current master?
This patch is supposed to go to IPA 4.2.
Is the tuple conversion needed?
values=tuple(_supported_scopes.keys()),
Otherwise patch looks good.
Martin^2
--
Martin Basti
Thank you.
ACK, it works as expected.
Martin^2
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Password vault
On 6/5/2015 7:13 AM, Jan Cholasta wrote:
If KRA is not installed, vault-archive and vault-retrieve fail with
internal error.
Added a code to check KRA installation in all vault commands. If you
know a way not to load the vault plugin if the KRA is not installed
please let me know, that's probably even better. Not sure how that will
work on the client side though.
I see this has been already resolved in the other thread.
The other thread was talking about removing the pki-base dependency on
the client side, but the vault plugin is still loaded on both client and
server regardless of KRA installation. Ideally the vault plugin should
not even be loaded so you cannot even execute the commands.
The commands still behave differently based on whether they were called
from API which was initialized with in_server set to True or False.
That is unfortunately a restriction imposed by the framework. In order
to guarantee the security, the vault is designed to have separate client
and server code. The client code encrypts the secret, the server code
forwards the encrypted secret to KRA. To archive a secret into a vault
properly, you are supposed to call the client code. If you're calling
the server code directly, you are responsible to do your own encryption
(i.e. generating session key, nonce, and vault data).
I understand why the code has to be separated, what I don't understand
is why it is in fact *not* separated and crammed into a single command,
making weird and undefined behavior possible.
If another plugin wants to use vault, it should implement a client code
which calls the vault client code to perform the archival from the
client side.
What is the use case for calling the vault API from the server side
anyway? Wouldn't that defeat the purpose of having a vault? If a secret
exists on the server side in an unencrypted form doesn't it mean the
secret may already have been compromised?
Server API is used not only by the server itself, but also by installers
for example. Anyway the point is that there *can't* be a broken API like
this, you should at least raise an error if the command is called from
server API, although actually separating it into client and server parts
would be preferable.
There is no point in exposing the session_key, nonce and vault_data
options in CLI when their value is always overwritten in forward().
I agree there is no need to expose them in CLI, but in this framework
the API also defines the CLI. If there's a way to keep them in the
server API but not expose them in the CLI please let me know. Or, if
there's a way to define completely separate server API (without a
matching client CLI) and client CLI (without a matching server API) that
will work too.
As I suggested above, you can split the commands into separate client
and server commands. The client command should inherit from
frontend.Local so that it is always executed locally and the server
command should have a NO_CLI = True attribute so that it is not
available in the CLI.
I see the vault_archive and vault_retrieve now inherit from PKQuery, and
there is a hack to execute the forward() even on the server side. A few
things below:
1. Why didn't you use frontend.Local as you initially suggested? If
there's a problem with frontend.Local please attach the ticket number in
the code.
2. The forward() can be merged into run(). There is no need to keep the
code in forward(). It would make more sense to have a run() method that
runs both on client and server, rather than a forward() that is supposed
to run on the client only but now forced to run on server too,
semantically speaking.
Attached is a patch including the requested changes.
I have also changed vault_config to vaultconfig_show, for consistency
with {,dns}config_show (it also makes the transport certificate
retrieval code in vault_{archive,retrieve} simpler).
3. The parameter description for nonce should be just 'Nonce' instead of
'Nonce encrypted'.
4. There's a PEP8 error.
5. The VERSION needs to be updated.
Assuming the above issues are addressed, ACK.
I have noticed that triple-length DES is used for the session key.
Wouldn't AES be better?
# generate session key
mechanism = nss.CKM_DES3_CBC_PAD
That's the default used by the KRA's client library, and that's what the
KRA has been tested with. We probably can change it to AES later. It
shouldn't be blocking this patch.
BTW, ipa-kra-install is broken with pki-core-10.2.4-1, but it works with
pki-core-10.2.1-3.
There's a bug in IPA: https://bugzilla.redhat.com/show_bug.cgi?id=1228671
--
Endi S. Dewata
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0051] Clear SSSD caches when uninstalling the client
On 05/06/15 16:13, Gabe Alford wrote: Hello, Fix for https://fedorahosted.org/freeipa/ticket/5049 Thanks, Gabe Thank you. I dont think we should remove all SSSD caches. SSSD can have configured several providers not just IPA. IMO we should remove only IPA related caches, but wait for SSSD guys for their opinion. -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Password Maxlife 0 causes expiration of 90 days
On Fri, 2015-06-05 at 10:37 -0400, Drew Erny wrote:
On 06/04/2015 05:41 PM, Alexander Bokovoy wrote:
On Thu, 04 Jun 2015, Drew Erny wrote:
https://fedorahosted.org/freeipa/ticket/2795
I've tracked down the source of this bug; it's nutty C stuff.
So, in daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c, when you
update password, the expiration time appears to be set in the
function ipapwd_CheckPolicy on line 631, which looks like
data-expireTime = data-timeNow + pol.max_pwd_life;
So the bug has to be in how pol.max_pwd_life gets is value. So I
check around, pol is initialized like this:
struct ipapwd_policy pol = {0};
...
pol.max_pwd_life = IPAPWD_DEFAULT_PWDLIFE;
And IPAPWD_DEFAULT_PWDLIFE is a constant 90 days.
But then the actual value of max_pwd_life is obtained by passing pol
into the function ipapwd_getPolicy on line 577 or 590, depending on
the password change type.
Inside of ipapwd_getPolicy, there's a couple of lines starting at
line 393
tmpint = slapi_entry_attr_get_int(pe, krbMaxPwdLife);
if (tmpint != 0) {
policy-max_pwd_life = tmpint;
}:
Which sets the max password life to the returned value, unless this
function returns 0. However, the documentation from
/usr/include/dirsrv/slapi-plugin.h says that that function,
slapi_entry_attr_get_int, returns 0 if the entry does not contain
that attribute. So, since the value 0 is returned, an error is
assumed to have occurred that member of the struct is left
untouched... which means it's still set to the value it was set to
when it was initialized, 90 days.
So, when the expireTime is set at line 631, it's set to 90 days
because the value returned by slapi_entry_attr_get_int is 0.
I've checked to see if we can get some error context out of the pe
variable passed in, but it appears to be an opaque struct that the
user isn't meant to see the internals of.
I'm not really sure what to do with this knowledge. The only thing I
can think would be to use another sentinel value, like -1, to
indicate that the password does not expire; or, otherwise, to
document that there is no way to have non-expiring passwords, and
administrators can only set value to some far-future date, and then
close this bug. Or, we could just set the default expiration date to
be somewhere far in the future. I'm not really qualified to make a
call on how to proceed with this, but I'm capable of making the
change if someone more senior decides.
I can also totally see this issue with the interface of slapi-plugin
being the possible cause of many bugs.
You can use slapi_entry_attr_exists() to check if attribute does exist
and then treat result of slapi_entry_attr_get_int() as actual value.
Otherwise, that's a great investigation!
Using slapi_entry_attr_exists() clears us of having to worry about
getting an error condition back, but I'm still not confident how to
handle the 0 maximum. Should I just put in a far-future date?
The current behavior is completely intentional, not a side effect of the
code, the code was written that way intentionally.
However me may consider an RFE that requests different behavior, we
would have to devise a special value for krbMaxPwdLife that means
infinite.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0016..0018 profiles regression fixes
On 05/06/15 14:18, Martin Basti wrote: On 05/06/15 14:16, Oleg Fayans wrote: Is it supposeed to fis this issue? 2015-06-05T12:11:57Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py, line 44, in run import ipaserver.plugins.dogtag # ensure profile backend gets loaded File /usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py, line 1273, in module raise SkipPluginModule(reason='dogtag not selected as RA plugin') No On 06/05/2015 01:53 PM, Fraser Tweedale wrote: On Fri, Jun 05, 2015 at 01:00:14PM +0200, Martin Basti wrote: On 05/06/15 11:47, Fraser Tweedale wrote: Patches 16 and 17 fix regressions in the default profile. Patch 18 fixes the `ipa-replica-install --setup-ca' breakage. Cheers, Fraser NACK, sorry ./make-lint * Module ipaserver.plugins.dogtag ipaserver/plugins/dogtag.py:2010: [E1124(redundant-keyword-arg), RestClient.__enter__] Argument 'method' passed by position and keyword in function call) ipaserver/plugins/dogtag.py:2011: [E0602(undefined-variable), RestClient.__enter__] Undefined variable 'ca_host') -- Martin Basti Whoops. One wayward comma that should have been a period! Here's an updated 0017..0018. Thanks, Fraser -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Martin Basti ACK 16-1, 17-2, 18-2 -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
