In krb5 1.7 and later, the stash file (/var/kerberos/krb5kdc/.k5.$REALM
on Fedora) is created in the regular keytab format instead of the older
less-portable one. Based from comments and code in kt_file.c, here's a
change to try to recognize that case (the file starts with a magic
number) and read the master key from Python.
The KDC will still read either format, so I left the bits that set
things up on replicas alone (advice appreciated). The patch works as
expected on my 64-bit box, both on RHEL5 (krb5 1.6.1 with a traditional
stash file) and on Raw Hide (krb5 1.7 with a keytab).
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>
along with stdout,stderr also log the initial command
This implements better logging of external commands. Formerly we were
just outputting stdout and stderr without labeling which was which. We
also omitted the initial command and it's arguments. This made it
difficult when reviewing the logs to know what the command was and
what was stdout vs. stderr. This patch fixes that.
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.
I saw this with a host where I joined a host, obtained a host
principal, kinited to that principal, then deleted the host from the
IPA server. The ticket was still valid so Apache let it through but
it failed to bind to LDAP.
Because ipa-join calls ipa-getkeytab I'd like to keep the return values in
sync. ipa-join returns the value returned by ipa-getkeytab so in order to
tell what failed the return values need to mean the same things and not
overlap.
Installing a CA that is signed by another CA is a 2-step process. The first
step is to generate a CSR for the CA and the second step is to install
the certificate issued by the external CA. To avoid asking questions
over and over (and potentially getting different answers) the answers
are cached.
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.
This also removes the Index option of /ipa-assets as well as the
deprecated IPADebug option.
No need to build or install ipa_webgui anymore. Leaving in the code
for reference purposes for now.
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
There was much back and forth and gnashing of teeth about what the
version should actually be in these pre-releases. We decided it isn't
2.0-ish enough so went with 1.9.0, 1.9.1, etc until we're ready to
declare 2.0.0.
We want to only allow a machine to request a certificate for itself, not for
other machines. I've added a new taksgroup which will allow this.
The requesting IP is resolved and compared to the subject of the CSR to
determine if they are the same host. The same is done with the service
principal. Subject alt names are not queried yet.
This does not yet grant machines actual permission to request certificates
yet, that is still limited to the taskgroup request_certs.
We were seeing a rare deadlock of DS when creating the memberOf task because
one thread was adding memberOf in a postop while another was trying to
create an index and this was causing a PRLock deadlock.
We have to replace 05rfc2247.ldif because it contains some conflicting
attributes with DNS in some older versions of 389-DS/RHDS. This fails on
some newer versions of 389-DS/RHDS so this lets it continue installing
if the new file is not needed.
