This replace the former ipactl script, as well as replace the current way ipa
components are started.
Instead of enabling each service in the system init scripts, enable only the
ipa script, and then let it start all components based on the configuration
read from the LDAP tree.
resolves: https://fedorahosted.org/freeipa/ticket/294
The DS guys decided not to expose the DS inetrnal functions used to generate
UUIDs for DS. This means the interface is not guaranteed to be available.
Switch the ipa_uuid plugin to use the system libuuid plugin instead.
NOTE: This causes once again a change in the tring format used for UUIDs.
fixes: https://fedorahosted.org/freeipa/ticket/465
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
It makes little sense to install ipa-admintools without ipa-client, require it.
Also see if the client has been configured. This is a bit tricky since we
have a full set of defaults. Add a new env option that gets set if at least
one configuration file is loaded.
ticket 213
python-configobj is a leftover from TurboGears requires as far as I can tell.
The ipa-ldap-updater message was supposed to detect when an upgrade was
installed but not applied. We are doing upgrades differently in v2.
tickets 141 and 219
Quick summary:
- use jQuery UI and jQuery BBQ libraries
- code restructuring
The patch has so many changes they can't be listed here. Many parts
of the code have been rewritten from scrach.
See freeipa-devel mailing list:
webUI code restructuring [wall of text, diagrams, ... you've been warned!]
2010-09-07
Also do the following:
- Remove conflicts on mod_ssl
- Remove a lot of version checking for EOL'd Fedora versions
- Add a few conditionals for rhel6
- Add Requires of nss-tools on ipa-client
Installing dogtag is quite slow and it isn't always clear that things
are working. This breaks out some restart calls into separate steps
to show some amount of progress. There are still some steps that take
more than a minute (pkicreate and pkisilent).
Add new argument to pkisilent, -key_algorithm
Update a bunch of minimum required versions in the spec file.
tickets 139 (time) and 144 (key_algorithm)
This patch:
- bumps up the minimum version of python-nss
- will initialize NSS with nodb if a CSR is loaded and it isn't already
init'd
- will shutdown NSS if initialized in the RPC subsystem so we use right db
- updated and added a few more tests
Relying more on NSS introduces a bit of a problem. For NSS to work you
need to have initialized a database (either a real one or no_db). But once
you've initialized one and want to use another you have to close down the
first one. I've added some code to nsslib.py to do just that. This could
potentially have some bad side-effects at some point, it works ok now.
Whenever we upgrade IPA such that any data incompatibilities might occur
then we need to bump the DATA_VERSION value so that data will not
replicate to other servers. The idea is that you can do an in-place
upgrade of each IPA server and the different versions own't pollute
each other with bad data.
We need the configured kerberos realm so we can clean up /etc/krb5.keytab.
We have this already in /etc/ipa/default.conf so use that instead of
requiring a whole other python package to do it.
I couldn't put the dogtag rules into the spec file until we required
dogtag as a component. If it wasn't pre-loaded them the rules loading
would fail because types would be missing.
- Don't run nscd if using sssd, the caching of nscd conflicts with sssd
- Set the minimum version of sssd to 1.1.1 to pick up needed hbac fixes
- only try to read the file configuration if the server isn't passed in
A new directory install/po has been added which contains all
the translations for all files in IPA.
The build has been agumented to build these files. Also the
autogen.sh script was mostly replaced by autoreconf, the preferred
method. The old autogen.sh sript also had some serious bugs in the
way it compared versions which caused it to run old versions of some
of the tools, using standared autoreconf is much better.
This does a number of things under the hood:
- Use authconfig to enable sssd in nss and pam
- Configure /etc/sssd/sssd.conf to use our IPA provider
- Enable the certmonger process and request a server cert
- join the IPA domain and retrieve a principal. The clinet machine
*must* exist in IPA to be able to do a join.
- And then undo all this on uninstall
When we un-enroll a client we'll do a bit of cleanup including removing
any principals for the IPA realm from /etc/krb5.keytab.
This removes principals in 2 ways:
- By principal, only entries matching the full principal are removed
- By realm. Any principal for that realm is removed
This does not change the KDC at all, just removes entries from a file
on the client machine.
The new framework uses default.conf instead of ipa.conf. This is useful
also because Apache uses a configuration file named ipa.conf.
This wipes out the last vestiges of the old ipa.conf from v1.
This policy should really be provided by dogtag. We don't want
to grant read/write access to everything dogtag can handle so we
change the context to cert_t instead. But we have to let dogtag
read/write that too hence this policy.
To top it off we can't load this policy unless dogtag is also loaded
so we insert it in the IPA installer
