A number of doc strings were not localized, wrap them in _().
Some messages were not localized, wrap them in _()
Fix a couple of failing tests:
The method name in RPC should not be unicode.
The doc attribute must use the .msg attribute for comparison.
Also clean up imports of _() The import should come from
ipalib or ipalib.text, not ugettext from request.
None is passed if the option is set with --minlife=''. This is a valid
use case to delete a non-required attribute. In this case we simply
don't do the math on None and things work as expected.
569847
As a consequence of using doc=_('some message') the _()
method was returning a Gettext instance, thus when optparse
was handed the help text it received a Gettext instance instead
of a basestring. optparse tried to operate on the Gettext instance
as if it were a basestring and since it wasn't threw an exception.
The fix is to promote (e.g. cast) the option.doc to unicode.
If the option.doc was a str it becomes unicode, if it was unicode
nothing happens, if it was Gettext (or any other object implementing
the __unicode__() method) object is converted to unicode via the
objects rules.
By the way, while debugging this I discovered strings which were not
localized, sometimes option.doc would be a str and sometimes a Gettext
object. In a subsequent patch I'll fix all those unlocalized doc
strings, but I don't want to bury this fix along with a load of
string fixes.
This is a temporary fix until we either use Params to determine
output type or treat integers differently from other binary values
internally (as unicode instead of str, for example).
The attributes displayed is now dependant upon their definition in
a Param. This enhances that, giving some level of control over how
the result is displayed to the user.
This also fixes displaying group membership, including failures of
adding/removing entries.
All tests pass now though there is still one problem. We need to
return the dn as well. Once that is fixed we just need to comment
out all the dn entries in the tests and they should once again
pass.
This primarily affects the installer. We want to log to the install/
uninstall file in DEBUG. This was getting reset to INFO causing lots of
details to not show in the logs.
Let the user, upon installation, set the certificate subject base
for the dogtag CA. Certificate requests will automatically be given
this subject base, regardless of what is in the CSR.
The selfsign plugin does not currently support this dynamic name
re-assignment and will reject any incoming requests that don't
conform to the subject base.
The certificate subject base is stored in cn=ipaconfig but it does
NOT dynamically update the configuration, for dogtag at least. The
file /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to
be updated and pki-cad restarted.
Add a new get_subject() helper and return the subject when retrieving
certificates.
Add a normalizer so that everything before and after the BEGIN/END
block is removed.
Need to add a few more places where the DN will not be automatically
normalized. The krb5 server expects a very specific format and normalizing
causes it to not work.
This profile enables subject validation and ensures that the subject
that the CA issues is uniform. The client can only request a specific
CN, the rest of the subject is fixed.
This is the first step of allowing the subject to be set at
installation time.
Also fix 2 more issues related to the return results migration.
The idnsUpdatePolicy takes a list of BIND dynamic update policies, each
of which must be terminated by ";". Also fix a minor error in the
documentation string.
Ignore NotImplementedError when revoking a certificate as this isn't
implemented in the selfsign plugin.
Also use the new type argument in x509.load_certificate(). Certificates
are coming out of LDAP as binary instead of base64-encoding.
The pyOpenSSL PKCS#10 parser doesn't support attributes so we can't identify
requests with subject alt names.
Subject alt names are only allowed if:
- the host for the alt name exists in IPA
- if binding as host principal, the host is in the services managedBy attr
The parsing bug was looking for the string 'version' expecting to find
the ACI version. This blew up with the attribute nsosversion. Use
the string 'version 3.0' instead.
The comparison bug appeared if neither ACI had a targetattr attribute.
It was trying to create a set out of a None which is illegal. If an
ACI doesn't have any targetattrs then return () instead.
This modifies the original patch by including a unit test, handling floats
when passed as unicode, and handling large magnitude values beyond maxint.
The INT parameter class was not respecting any radix prefix (e.g. 0x) the user
may have supplied. This patch implements _convert_scalar method for the Int
class so that we can pass the special radix base of zero to the int constructor
telling it to determine the radix from the prefix (if present).
Signed-off-by: John Dennis <jdennis@redhat.com>
If plugin fails to load log the traceback
If a plugin fails to load due to some kind of error it would be nice
if the error log contained the traceback so you can examine what went
wrong rather than being left blind as to why it failed to load.
If an exception is not handled here then the context isn't destroyed
leaving at least an LDAP connection dangling. This means the next time
this thread/process tries to handle a connection it will fail because
a context already exists.
This introduces 2 new params: --setattr and --addattr
Both take a name/value pair, ala:
ipa user-mod --setattr=postalcode=20601 jsmith
--setattr replaces or sets the current attribute to the value
--addattr adds the value to an attribute (or sets a new attribute)
OptionsParser allows multiple versions of this, so you can have multiple
setattr and addattr, either for the same attribute or for different
attributes.
ipa user-mod --addattr=postalcode=20601 --addattr=postalcode=30330 jsmith
Values are silent dropped if either of these on an existing param:
ipa user-mod --setattr=givenname=Jerry jsmith
Is a no-op.
Using the client IP address was a rather poor mechanism for controlling
who could request certificates for whom. Instead the client machine will
bind using the host service principal and request the certificate.
In order to do this:
* the service will need to exist
* the machine needs to be in the certadmin rolegroup
* the host needs to be in the managedBy attribute of the service
It might look something like:
admin
ipa host-add client.example.com --password=secret123
ipa service-add HTTP/client.example.com
ipa service-add-host --hosts=client.example.com HTTP/client.example.com
ipa rolegroup-add-member --hosts=client.example.com certadmin
client
ipa-client-install
ipa-join -w secret123
kinit -kt /etc/krb5.keytab host/client.example.com
ipa -d cert-request file://web.csr --principal=HTTP/client.example.com
