Re: [Freeipa-devel] [PATCH] 236 Log unhandled exceptions in certificate renewal scripts
On 28.1.2014 14:44, Petr Viktorin wrote:
On 01/23/2014 03:47 PM, Jan Cholasta wrote:
Hi,
the attached patch fixes https://fedorahosted.org/freeipa/ticket/4093.
Honza
This needs a rebase for the new LDAP API.
Fixed and rebased on top of current master.
--
Jan Cholasta
From 79d023ad0a265931c133376a64ff7bf484d82049 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 23 Jan 2014 15:33:26 +0100
Subject: [PATCH] Log unhandled exceptions in certificate renewal scripts.
https://fedorahosted.org/freeipa/ticket/4093
---
.../certmonger/dogtag-ipa-retrieve-agent-submit| 79 ++--
install/restart_scripts/renew_ca_cert | 137 +++--
install/restart_scripts/renew_ra_cert | 105
install/restart_scripts/restart_dirsrv | 27 ++--
install/restart_scripts/restart_httpd | 15 ++-
install/restart_scripts/restart_pkicad | 77 ++--
install/restart_scripts/stop_pkicad| 33 +++--
7 files changed, 262 insertions(+), 211 deletions(-)
diff --git a/install/certmonger/dogtag-ipa-retrieve-agent-submit b/install/certmonger/dogtag-ipa-retrieve-agent-submit
index 7267901..1422494 100644
--- a/install/certmonger/dogtag-ipa-retrieve-agent-submit
+++ b/install/certmonger/dogtag-ipa-retrieve-agent-submit
@@ -31,6 +31,8 @@ import sys
import shutil
import tempfile
import syslog
+import base64
+import traceback
from ipalib import api
from ipapython.dn import DN
from ipalib import errors
@@ -39,45 +41,52 @@ from ipapython import services as ipaservices
from ipapython import ipautil
from ipaserver.install import certs
from ipaserver.plugins.ldap2 import ldap2
-import base64
-# We cheat and pass in the nickname as the CA profile to execute against.
-# Some way is needed to determine which entry to retrieve from LDAP
-operation = os.environ.get('CERTMONGER_OPERATION')
-nickname = os.environ.get('CERTMONGER_CA_PROFILE')
+def main():
+# We cheat and pass in the nickname as the CA profile to execute against.
+# Some way is needed to determine which entry to retrieve from LDAP
+operation = os.environ.get('CERTMONGER_OPERATION')
+nickname = os.environ.get('CERTMONGER_CA_PROFILE')
-if operation not in ['SUBMIT', 'POLL']:
-sys.exit(6) # unsupported operation
+if operation not in ['SUBMIT', 'POLL']:
+sys.exit(6) # unsupported operation
-api.bootstrap(context='renew')
-api.finalize()
+api.bootstrap(context='renew')
+api.finalize()
-# Update or add it
-tmpdir = tempfile.mkdtemp(prefix = tmp-)
-try:
-dn = DN(('cn', nickname), ('cn', 'ca_renewal'), ('cn', 'ipa'), ('cn', 'etc'), api.env.basedn)
-principal = str('host/%s@%s' % (api.env.host, api.env.realm))
-ccache = ipautil.kinit_hostprincipal('/etc/krb5.keytab', tmpdir, principal)
-conn = ldap2(shared_instance=False, ldap_uri=api.env.ldap_uri)
-conn.connect(ccache=ccache)
+# Update or add it
+tmpdir = tempfile.mkdtemp(prefix = tmp-)
try:
-syslog.syslog(syslog.LOG_NOTICE, Updating certificate for %s % nickname)
-entry_attrs = conn.get_entry(dn, ['usercertificate'])
-cert = entry_attrs['usercertificate'][0]
-cert = base64.b64encode(cert)
-print x509.make_pem(cert)
-except errors.NotFound:
-syslog.syslog(syslog.LOG_INFO, Updated certificate for %s not available % nickname)
-# No cert available yet, tell certmonger to wait another 8 hours
-print 8 * 60 * 60
-sys.exit(5)
+dn = DN(('cn', nickname), ('cn', 'ca_renewal'), ('cn', 'ipa'), ('cn', 'etc'), api.env.basedn)
+principal = str('host/%s@%s' % (api.env.host, api.env.realm))
+ccache = ipautil.kinit_hostprincipal('/etc/krb5.keytab', tmpdir, principal)
+conn = ldap2(shared_instance=False, ldap_uri=api.env.ldap_uri)
+conn.connect(ccache=ccache)
+try:
+syslog.syslog(syslog.LOG_NOTICE, Updating certificate for %s % nickname)
+entry_attrs = conn.get_entry(dn, ['usercertificate'])
+cert = entry_attrs['usercertificate'][0]
+cert = base64.b64encode(cert)
+print x509.make_pem(cert)
+except errors.NotFound:
+syslog.syslog(syslog.LOG_INFO, Updated certificate for %s not available % nickname)
+# No cert available yet, tell certmonger to wait another 8 hours
+print 8 * 60 * 60
+sys.exit(5)
+finally:
+conn.disconnect()
+except Exception, e:
+syslog.syslog(syslog.LOG_ERR, Exception trying to retrieve %s: %s % (nickname, e))
+# Unhandled error
+sys.exit(3)
finally:
-conn.disconnect()
-except Exception, e:
-syslog.syslog(syslog.LOG_ERR, Exception trying to retrieve %s: %s % (nickname, e))
-# Unhandled error
-sys.exit(3)
-finally:
-shutil.rmtree(tmpdir)
+shutil.rmtree(tmpdir)
-sys.exit(0)
+sys.exit(0)
+
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 7.3.2014 17:33, Dmitri Pal wrote: I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I want to make clear that I'm not opposed to Vault in general. I'm questioning the necessity of Vault from the beginning because it will delay DNSSEC significantly. One of the proposals in this thread is to use something simple for DNSSEC keys (with few lines of Python code) and migrate DNSSEC with Vault when Vault is available and stable enough (in some later release). I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. We will have one huge release with DNSSEC + Vault at once if we to postpone DNSSEC to the same release as Vault. As a result, it would be harder to debug it because we will have to find if something is broken because of: - DNSSEC-IPA integration - Vault-IPA integration - DNSSEC-Vault integration. I don't think it is a good idea to make such huge release. Release early, release often -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions
On 03/07/2014 04:45 PM, Martin Kosek wrote: On 02/28/2014 03:51 PM, Petr Viktorin wrote: Hello, This reduces LDAP searches in permission-find when there are legacy permissions. The root entry (which contains all legacy permission ACIs) is only looked up once. There is a conflict on one line. But when I manually resolved it, the patch worked for me. We got from 176 OPS per ipa permission-find to ~96. This should be OK for now. Martin I don't see the conflict. Perhaps I mistakenly based this patch on something that's now pushed (though this applies cleanly to master from a week ago, too...). Could you check again? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/10/2014 11:49 AM, Petr Spacek wrote: On 7.3.2014 17:33, Dmitri Pal wrote: I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I want to make clear that I'm not opposed to Vault in general. I'm questioning the necessity of Vault from the beginning because it will delay DNSSEC significantly. +1, I also now see number of scenarios where Vault will be needed. One of the proposals in this thread is to use something simple for DNSSEC keys (with few lines of Python code) and migrate DNSSEC with Vault when Vault is available and stable enough (in some later release). I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. We will have one huge release with DNSSEC + Vault at once if we to postpone DNSSEC to the same release as Vault. As a result, it would be harder to debug it because we will have to find if something is broken because of: - DNSSEC-IPA integration - Vault-IPA integration - DNSSEC-Vault integration. I don't think it is a good idea to make such huge release. Release early, release often I must say I tend to agree with Petr. If the poor man's solution of DNSSEC without Vault does not cost us too much time and it would seem that the Vault is not going to squeeze in 4.0 deadlines, I would rather release the poor man's solution in 4.0 and switch to Vault when it's available in 4.1. This would let our users test the non-Vault parts of our DNSSEC solution instead of waiting to test a perfect solution. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic Correct If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? Quite soon. I would leave it to the team to suggest whether user and host provisioning smart proxies should be a same smart proxy or different so that they can be installed independently from each other but use the same approach. IMO haveing them separately but share the same code and approach will be more valuable to the project. But I am open to other ideas here. I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. If done right: i.e. following process and style then yes. Please become familiar with the coding style [9] page on the wiki and other contributer guidelines [10]. Also having a design page created as a result of the preliminary investigation would go a long way towards acceptance and quality of the feature. We will gladly guide you on the way if you have specific questions [...] Ok then, we'll do it as follows. We are currently experimenting with FreeIPA, to get familiar with technology and options; once we will be confident enough to start the actual work on the connector, we will check the status of the smart proxy patches from [11]. If the implementation status will be close to be ready and about to be included in the official distribution, we will follow the suggestions above and develop a REST-based connector. We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration
On Mon, 2014-02-24 at 14:26 -0500, Nathaniel McCallum wrote: Before this patch, ipa-kdb would load global configuration on startup and never update it. This means that if global configuration is changed, the KDC never receives the new configuration until it is restarted. This patch enables caching of the global configuration with a timeout of 60 seconds. https://fedorahosted.org/freeipa/ticket/4153 I still need a review of this. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 04:57 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 04:13 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 02:33 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 01:21 PM, Rob Crittenden wrote: Martin Kosek wrote: On 02/14/2014 11:26 PM, Dmitri Pal wrote: +1, this was exactly my goal. It is easy to name and organize things now, difficult to do when it is live upstream and/or integrated with Foreman. I think the key for the right naming is a fact if this is really specific to Foreman or it is a truly general design usable also in other use cases. If Foreman-specific, I would go with freeipa-server-smartproxy-host or similar. If general, we can go with freeipa-server-proxy-host freeipa-server-proxy-user freeipa-server-proxy-dhcp The proxies may share the framework and only expose the requested part of the tree - which in advance gives you an option for an API separation, as compared to general freeipa-server-smartproxy. I still don't get the point of this. Are you proposing having 3 different servers, each providing a unique service? Or one service that one can turn on/off features, or something else? Do you envision this as 3 separate subpackages? There is no framework in my current patch, it is a cherrypy server that exposes parts of IPA on a given URI. It is the thinnest of layers. Then it seems to make sense to have 3 different packages that can be optionally coninstalled and would probably share the same principal, keytab and local REST API socket/port. Well, what you are designing is a central framework with plugins. What I designed is a quick-and-dirty get something up quickly. We need to pick one. The plugable method is going to require a fair bit of rework, though it will potentially pay dividends in the future. I think that we can start where you are but drive towards this architecture via refactoring. But we need to pick the right name now. Even if the architecture is not there yet we should name the package in such way that it does not preclude us from moving towards a clean architecture I described during the next iteration. Just having a hard time seeing the value. This would be like making each of the IPA plugins a separate package and somehow installing them individually. To do this you'd need at least 2 packages, a high level one with the framework and then a separate one for each data type. This could also be achieved, and likely more cleanly, without all these extra packages, as a simple configuration file. Once a package, always a package. Maybe I'm too close to the problem, but to me this is a Foreman-specific solution. The smartproxy is a Foreman creation, I don't know that anything else is using it. If you want a RESTful server, then we enable REST in IPA directly, but selectively enabling and disabling APIs is not something we've done before. It has been controlled by ACIs instead. rob We are trying to predict future here. Say we release it as you suggest. Tomorrow we point someone upstream who wants to add users to IPA from a similar proxy to this implementation and say use this as a model. And then Rich needs the same but for DNS for Designate. What would be the best? Rob if you knew that tomorrow two other developers will create similar proxies for users and DNS would you change anything? Would you provide some guidelines to them? If you are close to the problem you should be able to at least tell them: copy and paste vs. add more APIs to the same proxy. If your recommendation is copy and paste then I suspect there will be challenges of running these proxies on the same machine - they will collide on ports and sockets. If we say extend shouldn't we use a more generic name? I'd say use the existing IPA API. The only reason we have to write the smartproxy at all is to interoperate with another service that already has a well-defined remote server API which uses REST. rob OK, so you think that proxy is one off. OK I am fine with it. I was under assumption that it would be a beginning of a trend but I might be wrong as I do not have valid arguments to prove or disprove one way or another. I guess time would show. Any objections to Rob's approach? Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity . Foreman otherwise supports no other
Re: [Freeipa-devel] [PATCH] 236 Log unhandled exceptions in certificate renewal scripts
On 03/10/2014 11:23 AM, Jan Cholasta wrote: On 28.1.2014 14:44, Petr Viktorin wrote: On 01/23/2014 03:47 PM, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4093. Honza This needs a rebase for the new LDAP API. Fixed and rebased on top of current master. ACK, pushed to master: 8e986904096925fc08df8cbdf271d722314c5460 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/10/2014 08:24 AM, Petr Viktorin wrote: On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic Correct If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? Quite soon. I would leave it to the team to suggest whether user and host provisioning smart proxies should be a same smart proxy or different so that they can be installed independently from each other but use the same approach. IMO haveing them separately but share the same code and approach will be more valuable to the project. But I am open to other ideas here. I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. If done right: i.e. following process and style then yes. Please become familiar with the coding style [9] page on the wiki and other contributer guidelines [10]. Also having a design page created as a result of the preliminary investigation would go a long way towards acceptance and quality of the feature. We will gladly guide you on the way if you have specific questions [...] Ok then, we'll do it as follows. We are currently experimenting with FreeIPA, to get familiar with technology and options; once we will be confident enough to start the actual work on the connector, we will check the status of the smart proxy patches from [11]. If the implementation status will be close to be ready and about to be included in the official distribution, we will follow the suggestions above and develop a REST-based connector. We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. What are the operations you need to implement? Can you list them? Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- 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
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/10/2014 07:17 PM, Dmitri Pal wrote: On 03/10/2014 08:24 AM, Petr Viktorin wrote: On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: [...] I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. ^ quote left here deliberately [...] We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. You'd be building two bridges (IPA--REST REST--ConnID) when you could build just one. Unless you already have a suitable generic REST connector already, I don't think it's your best option. From this thread it seems to me that JSON-RPC--ConnID would not require significantly more work than just the REST--ConnID part. What are the operations you need to implement? Can you list them? They were listed earlier in the thread, and [5]. Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob On my VMs, where the first request is handled properly but the server hangs on the second one. I gave you access to the machines for investigation. Sent you something out-of-band but in short, I wasn't able to reproduce on your reproducing VMs :-( Ping me tomorrow and we'll try it together. Please add the Python libraries (python-cherrypy, python-requests, python-kerberos) to BuildRequires. Otherwise the build fails due to pylint errors. Fixed. In the man page: +Create a host or user whose credentials will be used by the server to make requests and add it to the role: + + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' the first command should be ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy since by default the username is 'sserversmartproxy'. The problem was a missing space before smartproxy. I have the login name last in this example. Fixed. A nitpick regarding the systemd service: according to [0], Type=forking should be avoided. Is there a reason against setting Type=simple, and removing the PID file? Because I wasn't able to get this working with cherrypy daemon mode. AFAICT it forks itself and systemd wouldn't end up with the right pid so can't stop the service. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
Rob Crittenden wrote: Petr Viktorin wrote: On 02/27/2014 10:18 PM, Rob Crittenden wrote: Rob Crittenden wrote: Updated patch based on feedback from Foreman team. I added a new URI, /features, which Foreman uses to determine what capabilities a proxy has. rob On my VMs, where the first request is handled properly but the server hangs on the second one. I gave you access to the machines for investigation. Sent you something out-of-band but in short, I wasn't able to reproduce on your reproducing VMs :-( Ping me tomorrow and we'll try it together. Please add the Python libraries (python-cherrypy, python-requests, python-kerberos) to BuildRequires. Otherwise the build fails due to pylint errors. Fixed. In the man page: +Create a host or user whose credentials will be used by the server to make requests and add it to the role: + + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' the first command should be ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy since by default the username is 'sserversmartproxy'. The problem was a missing space before smartproxy. I have the login name last in this example. Fixed. A nitpick regarding the systemd service: according to [0], Type=forking should be avoided. Is there a reason against setting Type=simple, and removing the PID file? Because I wasn't able to get this working with cherrypy daemon mode. AFAICT it forks itself and systemd wouldn't end up with the right pid so can't stop the service. And now the updated patch. The changes are super-minor. rob From 1b0207e47249ce16c56012245a5be711d6cce53f Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Tue, 3 Dec 2013 09:14:00 -0700 Subject: [PATCH] Implement an IPA Foreman smartproxy server This currently server supports only host and hostgroup commands for retrieving, adding and deleting entries. The incoming requests are completely unauthenticated and by default requests must be local. Utilize GSS-Proxy to manage the TGT. Configuration information is in the ipa-smartproxy man page. Design: http://www.freeipa.org/page/V3/Smart_Proxy --- Makefile | 5 +- freeipa.spec.in| 39 ipalib/util.py | 13 +- ipatests/test_smartproxy/resttest.py | 170 +++ ipatests/test_smartproxy/test_features.py | 35 +++ ipatests/test_smartproxy/test_host.py | 145 + ipatests/test_smartproxy/test_hostgroup.py | 97 + smartproxy/Makefile.am | 43 smartproxy/configure.ac| 75 +++ smartproxy/ipa-smartproxy | 336 + smartproxy/ipa-smartproxy.conf | 15 ++ smartproxy/ipa-smartproxy.logrotate| 11 + smartproxy/ipa-smartproxy.service | 12 ++ smartproxy/man/Makefile.am | 19 ++ smartproxy/man/ipa-smartproxy.1| 78 +++ smartproxy/man/ipa-smartproxy.conf.5 | 72 +++ 16 files changed, 1159 insertions(+), 6 deletions(-) create mode 100644 ipatests/test_smartproxy/resttest.py create mode 100644 ipatests/test_smartproxy/test_features.py create mode 100644 ipatests/test_smartproxy/test_host.py create mode 100644 ipatests/test_smartproxy/test_hostgroup.py create mode 100644 smartproxy/Makefile.am create mode 100644 smartproxy/configure.ac create mode 100755 smartproxy/ipa-smartproxy create mode 100644 smartproxy/ipa-smartproxy.conf create mode 100644 smartproxy/ipa-smartproxy.logrotate create mode 100644 smartproxy/ipa-smartproxy.service create mode 100644 smartproxy/man/Makefile.am create mode 100644 smartproxy/man/ipa-smartproxy.1 create mode 100644 smartproxy/man/ipa-smartproxy.conf.5 diff --git a/Makefile b/Makefile index 2808f6153c1920f66dc7729f9ae6ef8798cb0e19..ee10e3aa7c5fb03e76986e8eddb96be5c5a418ce 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ include VERSION -SUBDIRS=daemons install ipapython ipa-client +SUBDIRS=daemons install ipapython ipa-client smartproxy CLIENTDIRS=ipapython ipa-client PRJ_PREFIX=freeipa @@ -74,6 +74,7 @@ bootstrap-autogen: version-update client-autogen @echo Building IPA $(IPA_VERSION) cd daemons; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR) --with-openldap; fi cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi + cd smartproxy; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi client-autogen: version-update cd ipa-client; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi @@ -193,6 +194,7 @@ tarballs: local-archive cd
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/10/2014 03:14 PM, Petr Viktorin wrote: On 03/10/2014 07:17 PM, Dmitri Pal wrote: On 03/10/2014 08:24 AM, Petr Viktorin wrote: On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: [...] I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. ^ quote left here deliberately [...] We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. You'd be building two bridges (IPA--REST REST--ConnID) when you could build just one. Unless you already have a suitable generic REST connector already, I don't think it's your best option. From this thread it seems to me that JSON-RPC--ConnID would not require significantly more work than just the REST--ConnID part. What are the operations you need to implement? Can you list them? They were listed earlier in the thread, and [5]. It is usually easy to take something that is already working like smart proxy and change the entry points to the ones that you need. I am not familiar with the architecture of the connectors. Are they separate processes? Are they daemons? Are they forked per request? Connection to IPA needs to be authenticated. If the connection to IPA happens from a single process like smart proxy you do not need to worry about machinery related to authentication and session managment. It is already implemented. This is why I was suggesting to use smart proxy. IMO REST vs. JSON is not that big deal. They are similar. Doing things right from the authentication POV and session management are much harder. But if we do not see a value in using smart proxy even like a reference point for ConnID I would not insist. Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- 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
