Joey has proposed a new concept of “Continuously Usable Testing” for Debian [1], basically testing should be usable at all times and packages that aren’t usable should be dropped. But to properly achieve this goal we need continual testing of usability.
Table of Contents
The Plan For SE Linux
To do this for SE Linux I’m setting up a Xen server which will have a number of different DomUs for testing a variety of server applications. The system has 1.5G of RAM and 160G of mirrored storage. An image of a typical server will take about 4G of disk space, so we could have something like 40 images online and ready for testing. I have already setup Squid on another system on the same LAN to cache Debian packages, so running “apt-get dist-upgrade” on a number of DomUs won’t take that long. With 256M for a typical server image I could have 5 images running at the same time. If the hardware isn’t enough then I can expand it, I hope to get some donations of DDR-266 or DDR-333 RAM (or maybe DDR-400) to upgrade the system to 4G of RAM, I can add more hard drives, and I could even install more servers.
I want to have testing be very usable for SE Linux throughout the development cycle so that I don’t have to rush things before release.
At this stage I’m not sure whether to track Unstable or Testing for this. I guess it might be best to track Testing most of the time and only track Unstable for daemons that are changing rapidly. It might get boring testing every version that comes through Unstable, but if people want to do this then I won’t stop them.
Setting up the Tests
What I need are interested people who want to install server configurations for testing. If you have some favorite combination of daemons that you want tested for SE Linux support (even if it’s daemons that have no current policy) then I can give you root access to a DomU to develop test cases. Ideally there would be automated tests used for most things for example testing a mail server by using swaks to deliver mail and a POP or IMAP client script to retrieve it. But some things can’t be tested properly without human intervention.
For the automated tests I want to script the creation of DomUs, upgrading the packages in the DomU, testing it, and then shutting down the DomU if it all works. If at any time the tests fail (or the upgrade fails) then it would wait for human intervention. That would be me fixing SE Linux problems and other people fixing the application problems. I think that discovering SE Linux issues will only be a part of this project.
For the manual tests I will grant access to create and destroy the DomUs in question to people who can run the tests.
I’m thinking of having a couple of DomUs running permanently for things which are test candidates but also useful for the project, such as a MediaWiki instance. It really depends on the interest of people who might use such things.
Also I’m thinking of setting up some Ubuntu DomUs too, I probably should join Ubuntu and get involved with SE Linux there.
Sharing the Images
I have a web server in Germany with almost unlimited bandwidth and storage. For every image that is created I want to upload a version to the server in Germany to allow anyone in the world to test it. There are lots of possible ways of using this for software development. For example if you had a patched version of Apache that you wanted to test then you could download every image that had Apache installed and test that they all work. That would be easier than configuring Apache in different ways and also possibly provide better coverage.
Also if someone can’t figure out how to configure a daemon correctly then downloading a Xen image of a working configuration could be helpful (if a little bandwidth intensive). Note that deploying such an image in production would be a really bad idea, among other things there are lots of places where passwords are stored and you wouldn’t want to risk missing one.
I also plan to share the scripts used in running the Dom0 and anything else that seems useful along the way.
What We Need
The main thing we need is volunteers to configure virtual machines with their favorite daemons. Note that I don’t plan to have only one daemon per DomU, if we can get multiple daemons running that don’t conflict (EG file server and mail server) or multiple daemons that can interact (EG database server and a mail server or anything else that can be a database client) running on the same system then that’s a good thing. So there will be some degree of interaction with other people.
I’m happy to accept contributions from people who aren’t interested in SE Linux. But SE Linux will run on all DomUs.
Finally I also need more RAM for a HP D530S, DU875PA (that’s a Celeron 2.4GHz). I’ll accept donations of complete systems too once my HP system gets full, preferably relatively low power systems as they will be housed in a location that’s not as well ventilated as I would like (cost and availability of IP addresses were the main criteria). A laptop with a broken screen would be great!
The system won’t go live until Monday, but I think that probably people won’t be ready to do much work with less than two days notice anyway.
I find it very strange that you use the words “new concept” to link to a page which states prominently: “last edited 2 years and 1 month ago”… for a second I thought I’d missed something.
You do have a reasonable point that CUT was invented a while ago – and some people have been running Unstable for a decade or more.
But in terms of actually doing the extra testing to ensure that it works, either not much is being done or the people who are doing it aren’t talking about it much.
Hi Russell,
What would also help is if there is some documentation out there on how to debug and fix SELinux rulesets. I’ve been trying to run SELinux on my personal laptop for a while now, but that isn’t going to work (there are simply too many incorrect avc denials to be able to do anything remotely useful with SELinux in enforcing mode).
I am reasonably aware of how SELinux works (I run a number of RHEL machines for customers, most of whom have it enabled), but I don’t have a grasp on how the policy files work.
Rather than file bugs on each of the individual problems that I encounter (there are simply too many of them), I would like to be able to file bugs with patches. But I haven’t the slightest idea where to start. Would you be willing to post a blog entry explaining how these files work, how to debug them, and where to find more documentation? I’m sure that if more DD’s understood SELinux, more would be willing to help with SELinux policy updates for their own packages’ behaviour as well as for debugging it.
Thanks,