I've implemented basic support for Kerberos (ie: SSO) auth in Cockpit.
I'll be working on polishing this further, and I don't think it's ready
for merge. But I did get kerberos authentication working against my
FreeIPA instance. Happiness.
Needs unit tests, and needs documentation. I won't pretend it's ready
for general consumption. Doesn't yet use the kerberos credentials to
connect out to other servers. Not tested with gss-proxy.
One thing of note, is that we need to handle unauthorized responses at
the HTTP level. Currently for /socket we respond with a JSON message
when the cookie has expired. However this won't work for kerberos, as
the client needs proper headers, and can/should re-authenticate right
then and there. I haven't fully tested out the implications of this
change, and we may need to tweak this further.
There's also some refactoring of the CockpitAuth and credential code.
Available on my wip/gssapi-auth github branch for the morbidly curious.
FYI, I have create a new Git repository for our unreleased dependencies:
The Git repo is visible in the old place at
and nothing should have changed for users of the RPM repo (except that
Fedora 18 has disappeared), but if something is broken for you, now you
I have also removed the cockpit-deps directory in the
cockpit-project.github.io Git repository.
as discussed, we want to speed up the test suite.
Here are some VERY round numbers of the current test suite:
vm boot: 0:10 x 27 = 4:30
If we don't want to touch the tests themselves for tnow, we can do this
to speed this up:
- Make the vms boot faster.
The time to boot includes waiting for the network to be up, which
needs a DHCP response, wich can be quite slow apparently.
- Make mock faster.
Adding --no-clean to mock let's make-rpms run in about 0:30. I will
do this and add a "--clean" option to make-rpms.
- Make vm-install faster.
The idea is to start from a 'prepared' tarball that is already
up-to-date with the repos and has all the dependencies installed. The
'prepared' tarball would be refreshed once per day.
The 'prepared' tarball will be created from the current 'base' tarball
simply by running the base tarball through vm-create && vm-install
$DEPS && virt-tar-out. $DEPS are some reasonable current dependencies
This might bring vm-install down to about 10 seconds.
I'll set this up and keep a freshly prepared tarball online somewhere.
- Make vm-create faster.
We can get rid of this step altogether by using a disk image directly
instead of a tarball.
With this, we still have the magic base tarball that I have created by
hand. I tried to automate this with oz-install and virt-install but I
failed. I didn't try virt-builder since it is not in Fedora 19.
I have changed the way that the test suite needs to be operated. Right
now, it requires quite a bit of manual interaction and inside knowledge,
but as we gain experience, we will probably automate more of this, and
make it more fool-proof.
Here is how I (intend) to do it:
$ export TEST_DATA=$HOME/cockpit-tarballs/
# Get the magic base tarballs. Do this only once, they wont change
# without a loud announcement here.
$ mkdir $TEST_DATA/base
$ curl https://dl.dropboxusercontent.com/s/10b3q7ualqxew1d/fedora-18-x86_64.tar.gz \
$ curl https://dl.dropboxusercontent.com/s/10b3q7ualqxew1d/fedora-20-x86_64.tar.gz \
# Create the tarballs for the actual test runs. Do this whenever the
# OS repository or cockpit-deps have changed enough. Once a day or
# so. This is slow and a bit unreliable since it runs VERIFY to test
# the new tarballs.
$ cd .../cockpit
$ git checkout master
$ TEST_OS=fedora-18 ./PREPARE
$ mv ./test/fedora-18.tar.gz $TEST_DATA/
$ TEST_OS=fedora-20 ./PREPARE
$ mv ./test/fedora-20.tar.gz $TEST_DATA/
# Run the actual tests. This shouldn't go to the network much, only
# mock still runs yum.
$ cd .../cockpit
$ git checkout wip/whatever
$ TEST_OS=fedora-18 ./VERIFY
$ TEST_OS=fedora-20 ./VERIFY
So the biggest change is that we are now isolated from changes in the OS
and in cockpit-deps when running tests (but not while building). VERIFY
should also be a bit faster, but not dramatically so.
The idea is that the PREPARE step is done centrally, and we all download
fresh tarballs whenever necessary. That comes soon, I hope, but for now
you all need to run PREPARE yourself.
let's nail down our coding style guidelines. I have this so far,
Cockpit Coding Guidelines
- No trailing whitespace, no tab characters
- Maximum line length is 120 characters.
- Gtk+ coding standards.
- C99 is allowed and the default.
- __attribute((cleanup)) is allowed, via libgsystem.
- PEP 8
* CSS / HTML
- XXX dashes vs underscores in ids.
- XXX namespacing of ids.
(setq indent-tabs-mode nil)
(add-hook 'before-save-hook 'delete-trailing-whitespace)
(setq whitespace-style '(face trailing lines-tail empty))
(setq whitespace-line-column 120)