Password policy entries must be a child of the entry protected by this
ACI.
Also change the format of this because in DS it was stored as:
\n(target)\n so was base64-encoded when it was retrieved.
In order to run the tests you must put your DM password into
~/.ipa/.dmpw
Some tests are expected to generate errors. Don't let any ERROR
messages from the updater fool you, watch the pass/fail of the nosetests.
- The aci plugin didn't quite work with the new ldap2 backend.
- We already walk through the target part of the ACI syntax so skip that
in the regex altogether. This now lets us handle all current ACIs in IPA
(some used to be ignored/skipped)
- Add support for user groups so one can do v1-style delegation (group A
can write attributes x,y,z in group B). It is actually quite a lot more
flexible than that but you get the idea)
- Improve error messages in the aci library
- Add a bit of documentation to the aci plugin
This will create a host service principal and may create a host entry (for
admins). A keytab will be generated, by default in /etc/krb5.keytab
If no kerberos credentails are available then enrollment over LDAPS is used
if a password is provided.
This change requires that openldap be used as our C LDAP client. It is much
easier to do SSL using openldap than mozldap (no certdb required). Otherwise
we'd have to write a slew of extra code to create a temporary cert database,
import the CA cert, ...
External CA signing is a 2-step process. You first have to run the IPA
installer which will generate a CSR. You pass this CSR to your external
CA and get back a cert. You then pass this cert and the CA cert and
re-run the installer. The CSR is always written to /root/ipa.csr.
A run would look like:
# ipa-server-install --ca --external-ca -p password -a password -r EXAMPLE.COM -u dirsrv -n example.com --hostname=ipa.example.com -U
[ sign cert request ]
# ipa-server-install --ca --external-ca -p password -a password --external_cert_file=/tmp/rob.crt --external_ca_file=/tmp/cacert.crt -U -p password -a password -r EXAMPLE.COM -u dirsrv -n example.com --hostname=ipa.example.com
This also abstracts out the RA backend plugin so the self-signed CA we
create can be used in a running server. This means that the cert plugin
can request certs (and nothing else). This should let us do online replica
creation.
To handle the self-signed CA the simple ca_serialno file now contains
additional data so we don't have overlapping serial numbers in replicas.
This isn't used yet. Currently the cert plugin will not work on self-signed
replicas.
One very important change for self-signed CAs is that the CA is no longer
held in the DS database. It is now in the Apache database.
Lots of general fixes were also made in ipaserver.install.certs including:
- better handling when multiple CA certificates are in a single file
- A temporary directory for request certs is not always created when the
class is instantiated (you have to call setup_cert_request())
Also, member attributes are now mapped to 'member user', 'member group',
etc. instead of 'member users', 'member groups'. In other words,
the second word is now taken from LDAPObject.object_name instead of
LDAPObject.object_name_plural.
ldapi: grants httpd and krb5kdc to access the DS ldapi socket
ctypes: the Python uuid module includes ctypes which makes httpd segfault
due to SELinux problems.
dogtag: remove the CRL publishing permissions. This only worked if you
had dogtag installed. In the near future will publish elsewhere so for
the time being CRL file publishing will be broken with SELinux enabled.
- remove obsolete code related to PluginProxy
- remove parent_key attribute, for the purpose of nested objects
the parent's primary key is retrieved automatically
- added support for auto-generating of UUIDs
- make use of the improved attribute printing in CLI
- make LDAPDelete delete all sub-entries, not just one-level
- minor bug fixes
If the DNS zones already exist but don't contain our own records, add
them. This patch introduces the ipalib.api into the installers. For now,
the code is still little messy. Later patches will abandon the way we
create zones now and use ipalib.api exclusively.
BIND starting before we apply LDAP updates and restart kdc and directory
server causes trouble. We resolve this for now by postponing BIND setup
to the end of installation. Another reason is that we will be using
xml-rpc during the setup in the future.
This patch adds options --forwarder and --no-forwarders. At least one of
them must be used if you are doing a setup with DNS server. They are
also mutually exclusive. The --forwarder option can be used more than
once to specify more servers. If the installer runs in interactive mode,
it will prompt the user if none of these option was given at the command
line.
This also adds a new option to the template system. If you include
eval(string) in a file that goes through the templater then the
string in the eval will be evaluated by the Python interpreter. This is
used so one can do $UIDSTART+1. If any errors occur during the evaluation
the original string is is returned, eval() and all so it is up to the
developer to make sure the evaluation passes.
The default value for uid and gid is now a random value between
1,000,000 and (2^31 - 1,000,000)
If you don't want to use ldapi then you can remove the ldap_uri setting
in /etc/ipa/default.conf. The default for the framework is to use
ldap://localhost:389/
ipaObject is defined as an auxiliary objectclass so it is up to the
plugin author to ensure that the objectclass is included an a UUID generated.
ipaUniqueId is a MUST attribute so if you include the objectclass you must
ensure that the uuid is generated.
This also fixes up some unrelated unit test failures.
