Re: [Freeipa-devel] server install failing in F-20?
On 02/28/2014 11:05 PM, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Rob Crittenden wrote: I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I stood up. I finally threw my hands up and configured system to use an environment file to work around it. Not sure if anyone else is seeing this. One difference on F20 is that you are not supposed to see ccaches in /tmp -- they are in the kernel keyring. Did you test with freeipa-server-3.3.4-3.fc20.x86_64? Works for me in up-to-date F20. This build contains the patches in the ticket and thus fixes the bug 1044994. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0483-0485 Move ipalib.text to ipapython
Hi, On 28.2.2014 17:49, Petr Viktorin wrote: Hello! This moves ipalib.text to ipapython. Why do we want this? Firstly, it's a step towards breaking the ipapython dependency on ipalib, which is something we vaguely want to do in the long run for the sake of clean code and potential reuse. But there's another reason: The DNS plugin defines some validators that are used elsewhere. I'd like to eventually move them to ipapython, so the DNS plugin can be made optional (https://fedorahosted.org/freeipa/ticket/4058). The validators use on ipalib.text, so that has to be moved to ipapython (where I think it belongs). The validators are not used in ipapython, right? So why move them there? Also, the plan with DNS is to use python-dns where possible AFAIK, which will probably make most of the validators go away. Anyway, localization does not seem like a thing that a generic util module like ipapython should be bothered with, I would prefer if it stayed in ipalib and friends. The gettext wrappers in turn depend on the context, which I'd rather see in ipalib, but it's literally one line of code so it's not a big burden to have in ipapython. In the future we can think about somehow extracting it and moving it back, if needed. I really don't see how tainting ipapython with stuff that is pure ipalib will make the code cleaner. (And the first patch is just some general cleanup.) ACK on that. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods
On 28.2.2014 16:29, Petr Viktorin wrote: On 02/04/2014 03:01 PM, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4138. Honza Thanks, ACK. Here are some tests for this, do they look good? They look good to me, thanks. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods
On 03/03/2014 11:43 AM, Jan Cholasta wrote: On 28.2.2014 16:29, Petr Viktorin wrote: On 02/04/2014 03:01 PM, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4138. Honza Thanks, ACK. Here are some tests for this, do they look good? They look good to me, thanks. Thanks, pushed to master: fa5cbe7cb2b30b055adfc68d160ddcfa1cec7b39 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] LDAP schema for PKCS#11
Hi, starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. 3] Key attributes Like certificates keys can be stored ina single attribute as pkcs8 or bind.key format. In pkcs11 the keys are defined by their algoritthm specific attributes, I had defined RSA specific attributes (moduleus, exponent, ) and did not remove them. Maybe some app wants to create keys and store these attrs, having defined them does not force to use them, but allows flexibility without requiring new attribute definitions 4] Not needed attributes. Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them. I have not yet removed them, they don't nned to be used, but I can still remove them. 5] Attribute syntaxes I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values There are a couple of attributes with a limited range like key_type which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these values which translate them to integers, which could be used, but I propose to use a syntax of directoryString and use the values directly eg pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 And it would have to be parsed anywy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled
On 21.2.2014 17:45, Nathaniel McCallum wrote: On Fri, 2014-02-21 at 16:29 +0100, Jan Cholasta wrote: Hi, On 21.2.2014 16:09, Nathaniel McCallum wrote: On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: We had originally decided to provide defaults on the server side so that they could be part of a global config for the admin. However, on further reflection, only certain defaults really make sense given the limitations of Google Authenticator. Similarly, other defaults may be token specific. Attempting to handle defaults on the server side also makes both the UI and the generated documentation unclear. NOTE: this patch changes an existing API. VERSION says that we should bump the major version in this case. But we haven't actually released this API yet. Please advise. There were similar changes in the past and bumping minor version was always enough (we never ever bump major version). Fixed. Thanks, ACK. I forgot to mention something else about this patch. The default_from in the key parameter generates a warning. This is because the default is a bytes string and internally a check is done against NULLS (constants.py:36). The u'' in NULLS forces an attempt to convert the byte string to unicode. When this fails (because ipatokenotpkey is *NOT* a string but a byte array), a warning is thrown. Since '' and u'' evaluate as equal, what is the point of having u'' in NULLS? I don't see any way to suppress this warning except to remove u'' from NULLS. I think we can get rid of NULLS entirely and do something better instead (like if not value and value is not False:). Is this worth filing a ticket? How about a patch? https://www.redhat.com/archives/freeipa-devel/2014-February/msg00426.html Even better. But next time please post it in the same thread, so that other people don't review it while I'm reviewing it as well. Nathaniel -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration
Finally got to this patchset!
PATCH 337: ACK
PATCH 338: ACK
This prohibits us to use extra roles that end in digits. Can you put a
note explaining that in
http://www.freeipa.org/page/V3/Integration_testing#Host_configuration
Also, this wiki page points out to environment variables so that it
seems it is the preferred method of configuration. We should mention
more user friendly YAML here first.
PATCH 339: ACK
PATCH 340: ACK
PATCH 341:
The have_master variable seems redundant in from_dict method (it's only
a local definition and not referenced anywhere else):
+def from_dict(cls, dct, config):
+from ipatests.test_integration.host import BaseHost
+
+domain_type = dct.pop('type')
+assert domain_type in ('IPA', 'AD')
+domain_name = dct.pop('name')
+self = cls(config, domain_name, domain_type)
+
+have_master = False
+for host_dict in dct.pop('hosts'):
+host = BaseHost.from_dict(host_dict, self)
+self.hosts.append(host)
+if host.role == 'master':
+have_master = True
+
+check_config_dict_empty(dct, 'domain %s' % domain_name)
+
+return self
PATCH 342: ACK
PATCH 343: ACK
PATCH 348: ACK
PATCH 349: ACK
On 01/06/2014 11:13 AM, Petr Viktorin wrote:
On 12/12/2013 12:40 PM, Petr Viktorin wrote:
Hello Tomáš! I'm planning a little Christmas present for you. Instead of
a surprise I'm Releasing early :)
Apply patches or: git pull http://github.com/encukou/freeipa yaml-config
These patches add YAML/JSON configuration for tests.
YAML/JSON is completely optional, the existing envvar style continues to
work. The ipa-test-config tool can convert between the two (which is not
just for show, export will be needed for debugging and unit tests).
If you choose to use YAML, you need PyYAML (python-yaml) installed.
Example:
$ MASTER=master.ipa.test REPLICA=repl.ipa.test
TESTHOST_XYZ_env1=xyz.ipa.test BEAKERMASTER1_IP_env1=1.2.3.4
BEAKERREPLICA1_IP_env1=1.2.3.5 BEAKERXYZ1_IP_env1=1.2.3.6
ipa-test-config --global --yaml | tee /tmp/testconf.yaml
ad_admin_name: Administrator
ad_admin_password: Secret123
admin_name: admin
admin_password: Secret123
debug: false
dirman_dn: cn=Directory Manager
dirman_password: Secret123
dns_forwarder: 8.8.8.8
domains:
- hosts:
master:
external_hostname: master.ipa.test
ip: 1.2.3.4
role: master
repl:
external_hostname: repl.ipa.test
ip: 1.2.3.5
role: replica
xyz:
external_hostname: xyz.ipa.test
ip: 1.2.3.6
role: xyz
name: ipa.test
type: IPA
ipv6: false
nis_domain: ipatest
ntp_server: 2.pool.ntp.org
root_password: null
root_ssh_key_filename: ~/.ssh/id_rsa
test_dir: /root/ipatests
$ IPATEST_YAML_CONFIG=/tmp/testconf.yaml ipa-run-tests ...
What's left is to update the design and write tests. I'll get to it
eventually, but now I'll probably be busy for a few days. If you'd like
to do them as part of review, tests could be in the format:
from ipatests.test_integration import config
conf = config.Config.from_env($environment)
assert conf.to_dict() == {$result}
conf = config.Config.from_dict($inputdict)
assert conf.to_dict() == {$result}
https://fedorahosted.org/freeipa/ticket/3938
Tests added, new version attached.
As for #4081 (Export dynamic roles properly in ipa-test-config), hosts
are exported like static roles are (from the TestComplexConfig case):
TESTHOST_EXTRAROLEM_env1=extram1.ipadomain.test extram2.ipadomain.test,
TESTHOST_EXTRAROLEM1_env1=extram1.ipadomain.test
TESTHOST_EXTRAROLEM2_env1=extram2.ipadomain.test
For cases where there's just a single host of the role, it'll export
it both with the number and without.
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
Hi, adding Stef Walter to CC, as he has extensive knowledge of PKCS#11. On 3.3.2014 12:51, Ludwig Krispenz wrote: Hi, starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec For the record, here are some details about NSS trust objects: http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. This only adds complexity, as there will have to be two code paths to handle certificates (plus code for handling conflicts between them, etc.) in the module instead of just one. I would prefer if pkcs11certificateValue and pkcs11certificateCategory were removed. They can be re-added later if someone needs them (we don't). 3] Key attributes Like certificates keys can be stored ina single attribute as pkcs8 or bind.key format. In pkcs11 the keys are defined by their algoritthm specific attributes, I had defined RSA specific attributes (moduleus, exponent, ) and did not remove them. Maybe some app wants to create keys and store these attrs, having defined them does not force to use them, but allows flexibility without requiring new attribute definitions These attributes do not add flexibility, because they are RSA only, they only add complexity, because (again) there will have to be two code paths in the module to handle keys. Again, I would prefer if the extra attributes were removed. 4] Not needed attributes. Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them. I have not yet removed them, they don't nned to be used, but I can still remove them. Please do. It just makes no sense to have an LDAP attribute for CKA_TOKEN. 5] Attribute syntaxes I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values There are a couple of attributes with a limited range like key_type which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these values which translate them to integers, which could be used, but I propose to use a syntax of directoryString and use the values directly eg pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 And it would have to be parsed anywy +1, but I would prefer just pkcs11keyType: rsa (i.e. camel-cased and stripped of CKK_ prefix) rather than pkcs11keyType: CKK_RSA. The attribute is named pkcs11keyType, not pkcs11CKA_KEY_TYPE after all. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] server install failing in F-20?
On Friday, February 28, 2014 03:48:43 PM Rob Crittenden wrote: I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I stood up. I finally threw my hands up and configured system to use an environment file to work around it. Not sure if anyone else is seeing this. In reference to finding a way to upgrade F19 to F20: https://www.redhat.com/archives/freeipa-users/2014-March/msg0.html I've been doing some VM testing of both F19 to F20 yum upgrades as well as fresh installs on F20. I actually have better luck with the yum upgrade. The fresh install of FreeIPA on F20 fails near the end of the process using freeipa-server-3.3.4-3.fc20.x86_64. I have to manually start named and sometimes krb5kdc/kadmin then it works after a reboot. *** F20 fresh install error: 2014-03-02T20:41:10Z DEBUG Starting external process 2014-03-02T20:41:10Z DEBUG args=/bin/systemctl enable ipa.service 2014-03-02T20:41:10Z DEBUG Process finished, return code=0 2014-03-02T20:41:10Z DEBUG stdout= 2014-03-02T20:41:10Z DEBUG stderr=ln -s '/usr/lib/systemd/system/ipa.service' '/etc/systemd/system/multi-user.target.wants/ipa.service' 2014-03-02T20:41:10Z DEBUG Starting external process 2014-03-02T20:41:10Z DEBUG args=/bin/systemctl restart ipa.service 2014-03-02T20:42:45Z DEBUG Process finished, return code=1 2014-03-02T20:42:45Z DEBUG stdout= 2014-03-02T20:42:45Z DEBUG stderr=Job for ipa.service failed. See 'systemctl status ipa.service' and 'journalctl -xn' for details. 2014-03-02T20:42:45Z DEBUG File /usr/lib/python2.7/site- packages/ipaserver/install/installutils.py, line 622, in run_script return_value = main_function() File /sbin/ipa-server-install, line 1230, in main ipaservices.knownservices.ipa.enable() File /usr/lib/python2.7/site- packages/ipapython/platform/fedora16/service.py, line 134, in enable self.restart(instance_name) File /usr/lib/python2.7/site-packages/ipapython/platform/base/systemd.py, line 131, in restart ipautil.run([/bin/systemctl, restart, self.service_instance(instance_name)], capture_output=capture_output) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 345, in run raise CalledProcessError(p.returncode, arg_string, stdout) 2014-03-02T20:42:45Z DEBUG The ipa-server-install command failed, exception: CalledProcessError: Command '/bin/systemctl restart ipa.service' returned non- zero exit status 1 *** F19 to F20 upgrade, things seem to go well until the restart of pki- tomcatd@pki-tomcat.service SEVERE: The scratchDir you specified: /var/lib/pki/pki- tomcat/work/Catalina/localhost/pki is unusable Changing the ownership of that directory to 'pkiuser:pkiuser' resolves the SEVERE entry in the log and things seem to work. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E signature.asc Description: This is a digitally signed message part. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] server install failing in F-20?
On 02/28/2014 09:48 PM, Rob Crittenden wrote: I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in new F-20 install I stood up. I finally threw my hands up and configured system to use an environment file to work around it. Not sure if anyone else is seeing this. rob I'm getting a similar error in CI. Setting SELinux to permissive made it go away. A bugzilla is filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1063827 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account
Yes, the attached patch looks good. I see what you are saying how it did look misleading. Thanks, Gabe On Mon, Mar 3, 2014 at 3:13 AM, Petr Viktorin pvikt...@redhat.com wrote: On 03/02/2014 11:26 PM, Gabe Alford wrote: Here is an updated patch that merges the notes and adds info about preventing removal of the last admin. Gabe That looks misleading to me -- by default, the group administrators privilege actually excludes the right to modify admins. Only admins or the Directory Manager can add new admins. I took a stab at correcting this; does the attached patch look good? On Fri, Feb 28, 2014 at 8:39 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com wrote: That does make more sense to merge them under the same note. I can also include a little blurb about ipa user-del and ipa group-remove-member. On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com wrote: On 02/26/2014 04:01 PM, Gabe Alford wrote: Hi all, I added a tip in the deleting users section on restoring admin account. Please review. https://fedorahosted.org/__freeipa/ticket/2746 https://fedorahosted.org/freeipa/ticket/2746 Hello, The new tip is added right under a Note about the same thing (or a very similar thing, from the user's POV). Would it be possible to merge those two into a single Note? Nowadays[0], ipa user-del and ipa group-remove-member will refuse to delete the last admin. I think this information should be added to the main docs. (Also, this reduces the importance of the recovery instructions.) [0] https://fedorahosted.org/__freeipa/ticket/2564 https://fedorahosted.org/freeipa/ticket/2564 -- Petrł -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 3.3.2014 15:07, Stef Walter wrote: On 03.03.2014 15:03, Jan Cholasta wrote: If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account
On 03/03/2014 03:16 PM, Gabe Alford wrote: Yes, the attached patch looks good. I see what you are saying how it did look misleading. Thanks, Gabe Thank you for your help! Pushed to docs master: dfb1b16b4b62e87540b34bae8b4454021f17fd71 On Mon, Mar 3, 2014 at 3:13 AM, Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com wrote: On 03/02/2014 11:26 PM, Gabe Alford wrote: Here is an updated patch that merges the notes and adds info about preventing removal of the last admin. Gabe That looks misleading to me -- by default, the group administrators privilege actually excludes the right to modify admins. Only admins or the Directory Manager can add new admins. I took a stab at correcting this; does the attached patch look good? On Fri, Feb 28, 2014 at 8:39 AM, Gabe Alford redhatri...@gmail.com mailto:redhatri...@gmail.com mailto:redhatri...@gmail.com mailto:redhatri...@gmail.com__ wrote: That does make more sense to merge them under the same note. I can also include a little blurb about ipa user-del and ipa group-remove-member. On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com mailto:pvikt...@redhat.com wrote: On 02/26/2014 04:01 PM, Gabe Alford wrote: Hi all, I added a tip in the deleting users section on restoring admin account. Please review. https://fedorahosted.org/freeipa/ticket/2746 https://fedorahosted.org/__freeipa/ticket/2746 https://fedorahosted.org/__freeipa/ticket/2746 https://fedorahosted.org/freeipa/ticket/2746 Hello, The new tip is added right under a Note about the same thing (or a very similar thing, from the user's POV). Would it be possible to merge those two into a single Note? Nowadays[0], ipa user-del and ipa group-remove-member will refuse to delete the last admin. I think this information should be added to the main docs. (Also, this reduces the importance of the recovery instructions.) [0] https://fedorahosted.org/freeipa/ticket/2564 https://fedorahosted.org/__freeipa/ticket/2564 https://fedorahosted.org/__freeipa/ticket/2564 https://fedorahosted.org/freeipa/ticket/2564 -- Petrł -- Petr³ -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 03.03.2014 15:03, Jan Cholasta wrote: This link definitely should be somewhere in design docs. BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: And this too... Feel free to upload the file to wiki if you didn't find any on-line repo suitable for direct linking from design docs. CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. I would like to emphasis Rob's idea that this schema is IPA-specific for now but we should assume that other PKCS#11-LDAP implementations can exist. And also NSS specific, given the storage of NSS trust. I think we can make that conditional, i.e. by using an environment variable or the reserved argument in C_Initialize (like NSS does). If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAP schema for PKCS#11
On 03.03.2014 14:30, Petr Spacek wrote: On 3.3.2014 13:49, Jan Cholasta wrote: On 3.3.2014 12:51, Ludwig Krispenz wrote: starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema I have added couple links and typo fixes to the document. Please add externals links when referring to some other standard so other people don't need to dig related links again and again. (I have added links for PKCS#8 and PKCS#11.) What is this for? This seems pretty wild :) Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec For the record, here are some details about NSS trust objects: http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html Right, the NSS trust objects are definitely not an extensible scheme. What's your use case. Don't you already have other ways in LDAP of indicating trust in a certificate? This link definitely should be somewhere in design docs. BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: And this too... Feel free to upload the file to wiki if you didn't find any on-line repo suitable for direct linking from design docs. CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) -- (objectclass: pkiUser, usercertificate) and (authority, value) -- (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. I would like to emphasis Rob's idea that this schema is IPA-specific for now but we should assume that other PKCS#11-LDAP implementations can exist. And also NSS specific, given the storage of NSS trust. Cheers, Stef ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0486 permission-mod: Remove attributelevelrights before reverting entry
Hello,
This fixes issue #4212 which Petr¹ found in his Web UI work.
[#4212] https://fedorahosted.org/freeipa/ticket/4212
--
Petr³
From 3fd6a68161cc267d59731cfb0257cc350acfc36f Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 3 Mar 2014 14:46:51 +0100
Subject: [PATCH] permission-mod: Remove attributelevelrights before reverting
entry
LDAPUpdate adds the display-only 'attributelevelrights' attribute,
which doesn't exist in LDAP. Remove it before reverting entry.
https://fedorahosted.org/freeipa/ticket/4212
---
ipalib/plugins/permission.py | 3 +++
ipatests/test_xmlrpc/test_permission_plugin.py | 27 +-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py
index 4477a5e4e379198e2fccc4c2d503ccbe7c97f1fd..4b686941a551be82b7e3482ca0daf9fe2f5e9e28 100644
--- a/ipalib/plugins/permission.py
+++ b/ipalib/plugins/permission.py
@@ -1015,6 +1015,9 @@ def post_callback(self, ldap, dn, entry, *keys, **options):
else:
self.obj.update_aci(entry, old_entry.single_value['cn'])
except Exception:
+# Don't revert attribute which doesn't exist in LDAP
+entry.pop('attributelevelrights', None)
+
self.log.error('Error updating ACI: %s' % traceback.format_exc())
self.log.warn('Reverting entry')
old_entry.reset_modlist(entry)
diff --git a/ipatests/test_xmlrpc/test_permission_plugin.py b/ipatests/test_xmlrpc/test_permission_plugin.py
index b96d29c3f79225ba617e0b6e932f58d227763743..af86758d6e8ce95650b60b8d0551833942c7ca88 100644
--- a/ipatests/test_xmlrpc/test_permission_plugin.py
+++ b/ipatests/test_xmlrpc/test_permission_plugin.py
@@ -327,7 +327,6 @@ class test_permission_negative(Declarative):
name='ipapermexcludedattr',
error='only available on managed permissions'),
),
-
]
@@ -1639,8 +1638,34 @@ class test_permission_rollback(Declarative):
pdn=permission1_dn)),
),
+] + _verifications + [
+
+dict(
+desc='Try adding an invalid attribute on %r with --all --rights' % permission1,
+command=(
+'permission_mod', [permission1], dict(
+attrs=[u'cn', u'bogusattributexyz'],
+rights=True,
+all=True,
+)
+),
+expected=errors.InvalidSyntax(
+attr=r'targetattr bogusattributexyz does not exist '
+r'in schema. Please add attributeTypes '
+r'bogusattributexyz to schema if necessary. ACL Syntax '
+r'Error(-5):(targetattr = \22bogusattributexyz || cn\22)'
+r'(target = \22ldap:///%(tdn)s\22)'
+r'(version 3.0;acl \22permission:%(name)s\22;'
+r'allow (write) groupdn = \22ldap:///%(dn)s\22;)' % dict(
+tdn=DN('uid=admin', users_dn),
+name=permission1,
+dn=permission1_dn),
+),
+),
+
] + _verifications
+
class test_permission_sync_attributes(Declarative):
Test the effects of setting permission attributes
cleanup_commands = [
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1
On 02/28/2014 02:47 PM, Petr Viktorin wrote:
On 02/28/2014 02:12 PM, Martin Kosek wrote:
On 02/26/2014 10:44 AM, Petr Viktorin wrote:
Hello,
Here are a few fixes/improvements, and the first part of a managed
permission
updater.
The patches should go in this order but don't need to be ACKed/pushed
all at once.
Design:
http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater
Part of the work for: https://fedorahosted.org/freeipa/ticket/3566
This part is a preview of sorts, to get the basic mechanism and the
metadata
format reviewed before I add all of the default read permissions.
It implements the first section of Default Permission Updater in
the design;
Replacing legacy default permissions and Removing the global
anonymous read
ACI is left for later.
Metadata is added for the netgroup plugin* for starters, so
installing this
will give you two shiny new read permissions:
$ ipa permission-find ipa: --all
-
2 permissions matched
-
dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX
Permission name: ipa:Read Netgroup Membership
Permissions: read, compare, search
Effective attributes: externalhost, member, memberof, memberuser
Default attributes: member, memberof, memberuser, externalhost
Bind rule type: all
Subtree: cn=ng,cn=alt,$SUFFIX
Target filter: (objectclass=ipanisnetgroup)
Type: netgroup
ipapermissiontype: V2, MANAGED, SYSTEM
objectclass: ipapermission, groupofnames, top, ipapermissionv2
dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX
Permission name: ipa:Read Netgroups
Permissions: read, compare, search
Effective attributes: cn, description, hostcategory, ipaenabledflag,
ipauniqueid, nisdomainname, usercategory
Default attributes: cn, usercategory, hostcategory, ipauniqueid,
ipaenabledflag, nisdomainname, description
Bind rule type: all
Subtree: cn=ng,cn=alt,$SUFFIX
Target filter: (objectclass=ipanisnetgroup)
Type: netgroup
ipapermissiontype: V2, MANAGED, SYSTEM
objectclass: ipapermission, groupofnames, top, ipapermissionv2
Number of entries returned 2
with corresponding ACIs at cn=ng,cn=alt,$SUFFIX:
(targetattr = externalhost || member || memberof ||
memberuser)(targetfilter
= (objectclass=ipanisnetgroup))(version 3.0;acl
permission:ipa:Read Netgroup
Membership;allow (read,compare,search) userdn = ldap:///all;;)
(targetattr = cn || description || hostcategory || ipaenabledflag ||
ipauniqueid || nisdomainname || usercategory)(targetfilter =
(objectclass=ipanisnetgroup))(version 3.0;acl permission:ipa:Read
Netgroups;allow (read,compare,search) userdn = ldap:///all;;)
Patches:
0473: Enables refactoring that will make it more clear (to humans and
machines)
what plugins code depends on.
https://fedorahosted.org/freeipa/ticket/4185
0474: Fix handling of the search term for legacy permissions
My code that's in master now handles the search term incorrectly.
This does a
better job.
0475: Fix tests that relied on some assumptions I'll be breaking
0476: Allow modifying (but not creating) permissions with : in the
name
0477: Permission updater sample metadata
1) 476: Typo in test name:
+desc='Search fo rnonexisting permission with : in the
name',
Will fix.
2) 477: do we want to log anything when permission is up to date?
+try:
+ldap.update_entry(entry)
+except errors.EmptyModlist:
+return
I don't think that's needed, after all that's the expected behavior in
all but the first upgrade.
But I'll be happy to add it if you think it would be better.
3) I am not sure if this was initiated by this patch, but when I
checked access
log for a permission-find --name ipa operation, it produced over 170
LDAP
operations, most of them asking for the same information many times. See
attached access log excerpt.
It's unrelated to this patch. I've started optimizing permission-find
with many legacy permissions, expect a patch soon.
4) I have been quite resilient to the prefixes for the permissions,
but it
seems it is the easier possible approach to fix conflicts with user
permissions
without having to check that later for every upgrade or doing more
complex
stuff like multiple RDNs or different container for system and user
permissions.
I am now just thinking about the prefixing. Now you use this name:
ipa:Read Netgroups
Would it be nicer to use:
IPA:Read Netgroups
or
IPA: Read Netgroups
or even
[IPA] Read Netgroups
? :-)
Bikeshedding time!
Everyone on the list, please chime in!
Bikeshedding results from today's meeting:
ipa: pviktori++
System: mkosek++ simo+ ab++
Builtin: simo++ pvo+
Default:
The winner is System: , so I'll go and change to that.
I don't really have a preference.
5) Are we sure we want to make our code Python 2.7 dependent?
+'ipapermright': {'read', 'search',
[Freeipa-devel] [PATCH 0045] Fix token secret length RFC compliance
RFC 4226 states the following in section 4:
R6 - The algorithm MUST use a strong shared secret. The length of
the shared secret MUST be at least 128 bits. This document
RECOMMENDs a shared secret length of 160 bits.
From d75ea4ffded9e6f9e60702bf481dd7b9e5d201ac Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Mon, 3 Mar 2014 11:09:26 -0500
Subject: [PATCH] Fix token secret length RFC compliance
RFC 4226 states the following in section 4:
R6 - The algorithm MUST use a strong shared secret. The length of
the shared secret MUST be at least 128 bits. This document
RECOMMENDs a shared secret length of 160 bits.
---
ipalib/plugins/otptoken.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index 92853dec3048fd98f98f4113ef8b5874f2500919..91525398d6b7fd1fc355a7a018a6f96bef109979 100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -59,7 +59,7 @@ TOKEN_TYPES = {
}
# NOTE: For maximum compatibility, KEY_LENGTH % 5 == 0
-KEY_LENGTH = 10
+KEY_LENGTH = 20
class OTPTokenKey(Bytes):
A binary password type specified in base32.
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0045] Fix token secret length RFC compliance
On 3.3.2014 17:13, Nathaniel McCallum wrote: RFC 4226 states the following in section 4: R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits. ACK. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer
The updated patch addresses all the mentioned issues.
Also enables systemd's specific domainname service instead of relying
ypbind being present on the system.
Please note that nisdomainname is not configured on boot time at the
moment. The following bug is the cause:
https://bugzilla.redhat.com/show_bug.cgi?id=1071951
On 11/14/2013 12:54 PM, Ana Krivokapic wrote:
On 09/26/2013 10:28 AM, Tomas Babej wrote:
+if options.no_nisdomain and not options.nisdomain:
This should be `if options.no_nisdomain and options.nisdomain:`.
+parser.error(--no-nisdomain cannot be used together with
--nisdomain)
Shouldn't we also revert the nisdomain authconfig setting on client uninstall?
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 3b66934f1dd3167dc56ffa8b4a750a0912a89642 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 25 Sep 2013 13:45:45 +0200
Subject: [PATCH] ipa-client: Set NIS domain name in the installer
Provides two new options for the ipa-client-install:
--nisdomain: specifies the NIS domain name
--no_nisdomain: flag to aviod setting the NIS domain name
In case no --nisdomain is specified and --no_nisdomain flag was
not set, the IPA domain is used.
Manual pages updated.
http://fedorahosted.org/freeipa/ticket/3202
---
ipa-client/ipa-install/ipa-client-install | 65 +++
ipa-client/man/ipa-client-install.1 | 6 +++
ipapython/platform/base/__init__.py | 3 +-
ipapython/platform/fedora16/service.py| 2 +
4 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 7cc0c33973fb9bd2113b33da7cb1d450b66a49dd..03679c10d09c64a284e3950a1808887ec52ae5ea 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -126,6 +126,11 @@ def parse_options():
basic_group.add_option(, --force-ntpd, dest=force_ntpd,
action=store_true, default=False,
help=Stop and disable any timedate synchronization services besides ntpd)
+basic_group.add_option(--nisdomain, dest=nisdomain,
+ help=NIS domain name)
+basic_group.add_option(--no-nisdomain, action=store_true, default=False,
+ help=do not configure NIS domain name,
+ dest=no_nisdomain)
basic_group.add_option(--ssh-trust-dns, dest=trust_sshfp, default=False, action=store_true,
help=configure OpenSSH client to trust DNS SSHFP records)
basic_group.add_option(--no-ssh, dest=conf_ssh, default=True, action=store_false,
@@ -195,6 +200,9 @@ def parse_options():
if options.firefox_dir and not options.configure_firefox:
parser.error(--firefox-dir cannot be used without --configure-firefox option)
+if options.no_nisdomain and options.nisdomain:
+parser.error(--no-nisdomain cannot be used together with --nisdomain)
+
return safe_opts, options
def logging_setup(options):
@@ -595,6 +603,7 @@ def uninstall(options, env):
fstore.restore_all_files()
ipautil.restore_hostname(statestore)
+unconfigure_nisdomain()
nscd = ipaservices.knownservices.nscd
nslcd = ipaservices.knownservices.nslcd
@@ -1351,6 +1360,59 @@ def configure_automount(options):
root_logger.info(stdout)
+def configure_nisdomain(options, domain):
+domain = options.nisdomain or domain
+root_logger.info('Configuring %s as NIS domain.' % domain)
+
+nis_domain_name = ''
+
+# First backup the old NIS domain name
+if os.path.exists('/usr/bin/nisdomainname'):
+try:
+nis_domain_name, _, _ = ipautil.run(['/usr/bin/nisdomainname'])
+except CalledProcessError, e:
+pass
+
+statestore.backup_state('network', 'nisdomain', nis_domain_name)
+
+# Backup the state of the domainname service
+statestore.backup_state(domainname, enabled,
+ipaservices.knownservices.domainname.is_enabled())
+
+# Set the new NIS domain name
+set_nisdomain(domain)
+
+# Enable and start the domainname service
+ipaservices.knownservices.domainname.enable()
+ipaservices.knownservices.domainname.start()
+
+
+def unconfigure_nisdomain():
+# Set the nisdomain permanent and current nisdomain configuration as it was
+if statestore.has_state('network'):
+old_nisdomain = statestore.restore_state('network','nisdomain') or ''
+
+if old_nisdomain:
+root_logger.info('Restoring %s as NIS domain.' % old_nisdomain)
+else:
+root_logger.info('Unconfiguring the NIS domain.')
+
+set_nisdomain(old_nisdomain)
+
+# Restore the configuration of the domainname service
+enabled = statestore.restore_state('domainname', 'enabled')
+if not enabled:
+
[Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source
Hi,
Makes ipa-client-install configure SSSD as the data provider
for the sudo service by default. This behaviour can be disabled
by using --no-sudo flag.
https://fedorahosted.org/freeipa/ticket/3358
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 68de0976b010a484fe29505c161bc874fc0d9e50 Mon Sep 17 00:00:00 2001
From: Tomas Babej tomasba...@gmail.com
Date: Thu, 21 Nov 2013 13:09:28 +0100
Subject: [PATCH] ipa-client-install: Configure sudo to use SSSD as data source
Makes ipa-client-install configure SSSD as the data provider
for the sudo service by default. This behaviour can be disabled
by using --no-sudo flag.
https://fedorahosted.org/freeipa/ticket/3358
---
ipa-client/ipa-install/ipa-client-install | 46 +++
ipa-client/man/ipa-client-install.1 | 3 ++
2 files changed, 49 insertions(+)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 03679c10d09c64a284e3950a1808887ec52ae5ea..c20db0816e1d77d1fcda061d58a74d94eea8b9cf 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -137,6 +137,9 @@ def parse_options():
help=do not configure OpenSSH client)
basic_group.add_option(--no-sshd, dest=conf_sshd, default=True, action=store_false,
help=do not configure OpenSSH server)
+basic_group.add_option(--no-sudo, dest=conf_sudo, default=True,
+ action=store_false,
+ help=do not configure SSSD as data source for sudo)
basic_group.add_option(--no-dns-sshfp, dest=create_sshfp, default=True, action=store_false,
help=do not automatically create DNS SSHFP records)
basic_group.add_option(--noac, dest=no_ac, default=False, action=store_true,
@@ -1141,6 +1144,49 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, options, clie
sssdconfig.activate_service('ssh')
+if options.conf_sudo:
+# Activate the service in the SSSD config
+try:
+sssdconfig.new_service('sudo')
+except SSSDConfig.ServiceAlreadyExists:
+pass
+except SSSDConfig.ServiceNotRecognizedError:
+root_logger.error(Unable to activate the SUDO service in
+ SSSD config.)
+
+sssdconfig.activate_service('sudo')
+
+# Backup the nsswitch.conf, we're going to edit it now
+NSSWITCH_CONF = '/etc/nsswitch.conf'
+fstore.backup_file(NSSWITCH_CONF)
+
+conf = ipaclient.ipachangeconf.IPAChangeConf(IPA Installer)
+conf.setOptionAssignment(':')
+
+# Determine if nsswitch already contains files for sudoers or not
+sudoers_value = ' sss'
+
+with open('/etc/nsswitch.conf', 'r') as f:
+opts = conf.parse(f)
+option_result = conf.findOpts(opts, 'option', 'sudoers')[1]
+
+if option_result and 'files' in option_result['value']:
+sudoers_value = ' files sss'
+
+# Set sss as data source for sudoers
+opts = [{'name':'sudoers',
+ 'type':'option',
+ 'action':'set',
+ 'value': sudoers_value
+},
+{'name':'empty',
+ 'type':'empty'
+}]
+
+conf.changeConf(NSSWITCH_CONF, opts)
+root_logger.info(Configured %s % NSSWITCH_CONF)
+
+
domain.add_provider('ipa', 'id')
#add discovery domain if client domain different from server domain
diff --git a/ipa-client/man/ipa-client-install.1 b/ipa-client/man/ipa-client-install.1
index a7acf58e532d4d39abd6db0bd5c38a74a708ee3e..b3526379f44eec4ada9303c9d3987bc889256118 100644
--- a/ipa-client/man/ipa-client-install.1
+++ b/ipa-client/man/ipa-client-install.1
@@ -137,6 +137,9 @@ Do not configure OpenSSH client.
\fB\-\-no\-sshd\fR
Do not configure OpenSSH server.
.TP
+\fB\-\-no\-sudo\fR
+Do not configure SSSD as a data source for sudo.
+.TP
\fB\-\-no\-dns\-sshfp\fR
Do not automatically create DNS SSHFP records.
.TP
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0008] Typo in warning message where IPA realm and domain name differ
Hi all, Quick one line change to fix. https://fedorahosted.org/freeipa/ticket/4211 Thanks, Gabe freeipa-rga-0008-Typo-in-warning-message-where-IPA-realm-and-domain-n.patch Description: Binary data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On 03/01/2014 10:07 PM, Adam Young wrote: On 02/28/2014 10:21 AM, Petr Viktorin wrote: On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? We don't really have a framework for administrative tools. You may start with install/tools/ipa-adtrust-install, it is main part is relatively independent of the task (which is in ipaserver/install/adtrustinstance.py) The framework is there, new tools use it, and there's a ticket to convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's low priority in Future Releases, so not much progress is there...) Also see http://www.freeipa.org/page/V3/Logging_and_output The RESTful approach would be: 1. Upload a file to a specific URL (not JSON RPC) 2. Receive back a 202 Accepted HTTP Request, to include an URL to poll for status Not certain the right response from the URL in step 2 would be, but I am assuming it would be 200 with the body of the message stating: processing or completed. It would be really nice if the Batch command could be handled this way as well. The response back could be the partial responses until processing is complete. It might also be nice to supply an email address for notification of completed processing instead of polling, if it is going to be a really long running task. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Yes I think that: 1) We should not limit it to server side operation only 2) Upload the whole file and then process it. 3) We should already have code to upload files, we did it for entitlements and were supposed to use for certs. 4) Make sure we have a generic upload mechanism that reads a chunk of a configurable size and asks for more (pagination by 65K might be a good default). Regarding token files specifically: they can be big but not super huge. 10-20K tokens makes sense but probably not more. More than that would be a real corner case becuase it is hard to deploy that amount of tokens at the same time. It can take months and you do not want token file to contain many tokens that would sit on the shelf. Tokens expire so it is inefficient to buy huge chunks and let them sit unused. UI you allow uploading file too and then would process it locally. The processing of the file should generate a log or report. It would be nice to get indication from the server that it is still working so may be upload protocol should be something like: client: Initialize the transfer server: ready client: here is the chunk of data server: ack ... client: here is the last chunk of data
