tag:blogger.com,1999:blog-4121334Thu, 26 Jun 2008 10:38:36 +0000http://berrange.com/personal/diary/indexnoreply@blogger.com (Daniel)Blogger126125tag:blogger.com,1999:blog-4121334.post-2860228926655985071Thu, 26 Jun 2008 10:33:00 +00002008-06-26T10:38:36.857Z<p> <a href="http://veillard.com/">DV</a> has recently been looking at the issue of Java bindings for libvirt. A few months back a libvirt community member, Tóth István, contributed most of the code for Java bindings to libvirt. Daniel has now taken this codebase added a build system, and is hosting it in the libvirt CVS repository and done <a href="http://www.redhat.com/archives/libvir-list/2008-June/msg00280.html">a formal release</a>. This should be hitting Fedora 10 rawhide in the near future, meaning we now have bindings for C, Perl, Python, OCaml, Ruby and Java. Now who wants to do a PHP binding....that's the only other language commonly requested </p>http://berrange.com/personal/diary/2008/06/new-java-bindings-for-libvirtnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-3519830596558477787Wed, 18 Jun 2008 20:23:00 +00002008-06-18T20:25:35.450Z<p> Just finished my talk at the <a href="http://redhat.com/summit/">Red Hat Summit</a> on libvirt and virtualization tools. For those who are interested, the I've now posted <a href="http://people.redhat.com/berrange/summit-2008/">the slides</a> online. </p>http://berrange.com/personal/diary/2008/06/red-hat-summit-2008noreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-4110472207169373707Fri, 23 May 2008 19:08:00 +00002008-05-23T20:31:12.637Z<p> The <a href="http://libvirt.org/">libvirt</a> library provides a core C API upon which language specific bindings are also built. Being written in C of course means we have to do our memory management / allocation. Historically we've primarily used the standard malloc/realloc/calloc/free APIs that even knows and loves/hates, although we do have an internal variable length string API (more on that in a future post). Of course there are many other higher level memory management APIs (obstacks/memory pools, garbage collectors, etc) you can write C code with too, but in common with the majority of other other apps/code we happen to be using the general purpose malloc/free pattern everywhere. I've recently been interested in improving our code quality, reliability and testing, and found myself thinking about whether there was a way to make our use of these APIs less error prone, and verifiably correct at build time. </p> <p> If you consider the standard C library malloc/realloc/calloc/free APIs, they in fact positively encourage application coding errors. Off the top of my head there are at least 7 common problems, probably more.... </p> <ol> <li>malloc() - pass incorrect number of bytes</li> <li>malloc() - fail to check the return value</li> <li>malloc() - forget to fully initialize returned memory</li> <li>free() - double free by not setting pointer to NULL</li> <li>realloc() - fail to check the return value</li> <li>realloc() - fail to re-assign the pointer with new address</li> <li>realloc() - leaking memory upon failure to resize</li> </ol> <p> A great many libraries will create wrapper functions around malloc/free/realloc but they generally only attempt to address one or two of these points. As an example, consider GLib, which has a wrapper around malloc() attempting to address point 2. It does this by making it call abort() on failure to allocate, but then re-introduces the risk by also adding a wrapper which doesn't abort() </p> <pre> gpointer g_malloc (gulong n_bytes) G_GNUC_MALLOC; gpointer g_try_malloc (gulong n_bytes) G_GNUC_MALLOC; </pre> <p> It also wraps realloc() for the same reason, and adds an annotation to make the compiler warn if you don't use the return value </p> <pre> gpointer g_realloc (gpointer mem, gulong n_bytes) G_GNUC_WARN_UNUSED_RESULT; gpointer g_try_realloc (gpointer mem, gulong n_bytes) G_GNUC_WARN_UNUSED_RESULT; </pre> <p> This at least addresses point 6, ensuring that you update your variable with the new pointer, but can't protect against failure to check for NULL. And the free() wrapper doesn't address the double-free issue at all. </p> <p> You can debate which of "checking for NULL" vs "calling abort()" is the better approach - <a href="http://log.ometer.com/2008-02.html">Havoc has some compelling points</a> - but that's not the point of this blog posting. I was interested in whether I could create wrappers for libvirt which kept the choice in the hands of the caller, while still protecting from the common risks. </p> <ol> <li><p>For any given pointer type the compiler knows how many bytes need to be allocated for a single instance of it - it sizeof(datatype) or sizeof(*mptr). Both options are a little tedious to write out, eg</p> <pre> mytype *foo; foo = malloc(sizeof(*foo)); foo = malloc(sizeof(mytype)); </pre> <p> Since C has no data type representing a data type, you cannot simply pass a data type to a function as you might like to: </p> <pre> mytype *foo = malloc(mytype); </pre> <p> You do, however, have access to the preprocessor and so you can achieve the same effect via a trivial macro. </p> <pre> #define MALLOC(ptr) malloc(sizeof(*(ptr))) or #define MALLOC(mytype) malloc(sizeof(mytype)) </pre> </li> <li> <p> GCC has a number of ways to annotate APIs, one of which is <code>__attribute__((__warn_unused_result__))</code>. This causes emit a warning if return value is not used / checked. Add -Werror and you can get guarenteed compile time verification (the rest of your code was 100% warning free, wasn't it - it ought to be :-). This doesn't actually help with the NULL check for malloc, because you <strong>always</strong> do something with the return value - assign it to a variable. The core problem here is that the API encodes the error condition as a special case value in the returned "data". The obvious answer to this is to separate the two cases, keeping the return value soley as a bi-state success of fail flag. The data can be passed by via a output parameter. This might look like: </p> <pre> myptr *foo; mymalloc(&foo, sizeof(*foo)); </pre> <p> And the compiler would be able to warn that you failed to check for failure. It looks rather ugly to write this way, but consider that a preprocessor macro is already being used for the previous issue, so we can merely extend its use </p> <pre> #define MALLOC(ptr) mymalloc(&(foo), sizeof(*(foo)) myptr *foo; if (MALLOC(foo) < 0) ... do error handling... </pre> </li> <li> <p> The memory allocated by malloc() is not initialized to zero. For that a separate calloc() function is provided. This leaves open the possiblity of an app mistakenly using the wrong variant. Or consider an app using malloc() and explicitly initializing all struct members. Some time later a new member is added and now the developer needs to find all malloc() calls wrt to that struct and explicitly initilize the new member. It would be safer to always have malloc zero all memory - even though it has an obvious performance impact, the net win in safety is probably worth it for most applications. Dealing with this in realloc() is much harder though, because you don't know how many extra bytes (if any) you need to initialize without knowing the original size. </p> </li> <li> <p> Since free() takes the pointer to be freed directly it cannot reset the caller's original pointer variable back to NULL. So the application is at risk of mistakenly calling free() a second time, leading to corruption or a crash. free() will happily ignore a NULL pointer though. If free() were to accept a pointer to a pointer instead, it could automatically NULL-ify it. Again this has extra computational cost from the often redundant assignment to NULL, but it is negligable in the context of the work done to actually free the memory region, and easily offset by the safety benefits. </p> </li> <li><p> As with point 2, this is caused by the fact that the error condition is special case of the return data value.</p></li> <li> <p>This is a fun one which may escape detection for ages because most of the time the returned pointer address is the same as the original address. realloc() doesn't often need to relocate the data to another address. Given that solving the previous point required changing the return data to be an output-parameter, we've already basically solved this issue to. Pass in a pointer to the pointer to be reallocated and it can update the address directly. </p> </li> <li> <p> What todo on failure of a realloc() is an interesting question. The chances are that most applications will immediately free() the block and go into cleanup code - indeed I don't recall coming across code that would ever continue its work if realloc() failed. Thus one could simply define that if realloc fails it automatically free's the original data too. </p> </li> </ol> <p> Having considered this all its possible to define a set of criteria for the design of a low level memory allocation API that is considerably safer than the standard C one, while still retaining nearly all its flexibility and avoiding the imposition of policy such as calling abort() on failure. </p> <ul> <li>Use return values only for a success/fail error condition flag</li> <li>Annotate all the return values with __warn_unused_result__</li> <li>Pass a pointer to the pointer into all functions</li> <li>Define macros around all functions to automatically calculate datatype sizes</li> </ul> <p> So the primary application usage would be via a set of macros: </p> <pre> VIR_ALLOC(ptr) VIR_ALLOC_N(ptr, count) VIR_REALLOC_N(ptr, count) VIR_FREE(ptr) </pre> <p> These call through to the underlying APIs: </p> <pre> int virAlloc(void *ptrptr, size_t bytes) int virAllocN(void *ptrptr, size_t bytes, size_t count) int virReallocN(void *ptrptr, size_t bytes, size_t count) int virFree(void *ptrptr) </pre> <p> The only annoying thing here is that although we're passing a pointer to a pointer into all these, the first param is still just 'void *' and not 'void **'. This works because 'void *' is defined to hold any type of pointer, and in addition using 'void **' causes the compiler to complain bitterly about strict aliasing violations. Internally the impls of these methods can still safely cast to 'void **' when deferencing the pointer. </p> <p> All 3 of Alloc/Realloc functions will have <code>__warn_unused_result__</code> annotation so the caller is forced to check the return value for failure, validated at compile time generating a warning (or fatal compile error with -Werror). </p> <p> And finally to wire up the macros to the APIs: </p> <pre> #define VIR_ALLOC(ptr) virAlloc(&(ptr), sizeof(*(ptr))) #define VIR_ALLOC_N(ptr, count) virAllocN(&(ptr), sizeof(*(ptr)), (count)) #define VIR_REALLOC_N(ptr, count) virReallocN(&(ptr), sizeof(*(ptr)), (count)) #define VIR_FREE(ptr) virFree(&(ptr)) </pre> <p> If this is all sounding fairly abstract, an illustration of usage should clear things up. These snippets are taken from libvirt, showing before and after <dl> <dt>Allocating a new variable:</dt> <dd><p>Before</p> <pre> virDomain *domain; if ((domain = malloc(sizeof(*domain))) == NULL) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> <p> After </p> <pre> virDomain *domain; if (VIR_ALLOC(domain) < 0) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> </dd> <dt>Allocating an array of domains</dt> <dd><p>Before</p> <pre> virDomain *domains; int ndomains = 10; if ((domains = malloc(sizeof(*domains) * ndomains)) == NULL) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> <p>After</p> <pre> virDomain *domains; int ndomains = 10; if (VIR_ALLOC_N(domains, ndomains) < 0) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> </dd> <dt>Allocating an array of domain pointers</dt> <dd> <p>Before</p> <pre> virDomain **domains; int ndomains = 10; if ((domains = malloc(sizeof(*domains) * ndomains)) == NULL) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> <p>After</p> <pre> virDomain **domains; int ndomains = 10; if (VIR_ALLOC_N(domains, ndomains) < 0) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> </dd> <dt>Re-allocate the array of domains to be longer</dt> <dd> <p>Before</p> <pre> virDomain **tmp; ndomains = 20 if ((tmp = realloc(domains, sizeof(*domains) * ndomains)) == NULL { free(domains); __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } domains = tmp; </pre> <p>After</p> <pre> ndomains = 20 if (VIR_REALLOC_N(domains, ndomains) < 0) { __virRaiseError(VIR_ERROR_NO_MEMORY) return NULL; } </pre> </dd> <dt>Free the domain</dt> <dd><p>Before</p> <pre> free(domain); domain = NULL; </pre> <p>After</p> <pre> VIR_FREE(domain); </pre> </dd> </dl> <p> As these short examples show the number of lines of code hasn't changed much, but the clarity of them has - particularly the realloc() usage, and of course there is now compile time verification of usage. The main problem remaining is the classic memory leak, by forgetting to call free() at all. If you want to use a low level memory allocation API this problem is essentially unavoidable. Fixing it really requires a completely different type of API (eg, obstacks/pools) or a garbage collector. And there's always valgrind to identify leaks which works very nicely, particularly if you have extensive test suite coverage </p> <p> The original mailing thread from which this post is derived is on <a href="http://www.redhat.com/archives/libvir-list/2008-April/msg00372.html">the libvirt mailing list</a> </p>http://berrange.com/personal/diary/2008/05/better-living-through-api-design-lownoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-4109844165493719791Fri, 25 Apr 2008 01:39:00 +00002008-04-25T01:48:24.986Z<p> While browsing around the web a few weeks back I discovered a fabulous new way to <strike>waste</strike> occupy my time while <a href="http://xkcd.com/303/">waiting for code to compile</a> in the form of <a href="http://flickrvision.com/maps/show_3d">FlickrVision</a>. A globe showing satellite imagery of the Earth, spinning around every few seconds to show a newly uploaded & geo-tagged photo from Flickr. </p> <p> <a href="http://flickrvision.com/maps/show_3d"><img src="/~dan/flickrvision.png" alt="FlickrVision screengrab"></a> </p> <p> For those without flash it also comes in a <a href="http://flickrvision.com/">plain old 2-d format</a>, but that's not nearly so entertaining.http://berrange.com/personal/diary/2008/04/flickr-around-worldnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-2741073390355211674Mon, 21 Apr 2008 17:22:00 +00002008-04-21T17:34:00.245Z<p> CNet are running an article with a nice <a href="http://www.cnet.com/8301-13846_1-9920202-62.html">scary sounding headline</a> </p> <blockquote> <strong>"Free Open Source Software Is Costing Vendors $60 Billion"</strong> </blockquote> <p> Pretty clearly trying to imply that open source software is a threat to the entire existence of the software industry. Don't fall for such FUD. Just look at the headline from the other side of the fence </p> <blockquote> <strong>"Free Open Source Software Is Saving Customers $60 Billion"</strong> </blockquote> <p> Not nearly so scary sounding now. In fact it is probably quite appealing. </p> <p> On the one hand, you have a small number of large software companies sitting on their monopolies and extorting cash through licensing fees. On the other hand, you have hundreds of thousands of companies saving money by using open source software, paying for services with tangible value for their business, rather than an arbitrary software "tax" (license fee). Open source software benefits the many, at the expense of the few. A worthy trade-off. </p>http://berrange.com/personal/diary/2008/04/presentation-is-everythingnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-2910256187006521606Fri, 18 Apr 2008 14:48:00 +00002008-04-18T14:54:28.013Z<p> For some incomprehensible reason it has been decided that presenting <a href="http://dilbert.com/">Dilbert</a> cartoon strips as a plain old image isn't sexy enough. You now need a flash plugin to display the same old static image as before. Seriously, WTF.COM ? </p> <p> The only positive, is that there is a now <a href="http://feeds.feedburner.com/DilbertDailyStrip">an RSS feed</a> for the strips, which does have the static images inline to the feed. So now I can avoid the nauseating website completely and just read the strips from the comfort of <a href="http://liferea.sourceforge.net/">LiFeRea</a>. </p>http://berrange.com/personal/diary/2008/04/dilbert-flash-epic-failnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-6530713813555223836Mon, 14 Apr 2008 16:34:00 +00002008-04-14T16:47:51.824Z<p> <a href="http://cpants.perl.org">CPANTS</a> is an automated testing system for Perl modules hosted on <a href="http://search.cpan.org">CPAN</a> which checks various Perl <a href="http://cpants.perl.org/kwalitee.html">Kwalitee</a> guidelines. There was recently a hackathon to add more guidlines to the testrig and interestingly a couple of these are focusing on distribution integration points. </p> <ul> <li><a href="http://cpants.perl.org/kwalitee/shortcoming?name=fits_fedora_license"><strong>fits_fedora_license</strong></a> - this validates the module license against the allowable Fedora license list. In particular this seeks to fail modules which are Artistic v1 only - modules need to be dual Artistic/GPL to be suitable for Fedora. This is a great example of how Fedora's rigour around licensing is raising awareness across the open source community &amp; helping to identify and solve problems before they get to the distro. </li> <li><a href="http://cpants.perl.org/kwalitee/shortcoming?name=easily_repackageable_by_fedora"><strong>easily_repackageable_by_fedora</strong></a> - this is a compound metric which validates that the <strong>fits_fedora_license</strong> and <strong>no_generated_files</strong> metrics were satisfied by the module.</li> </ul> <p> Unfortunately with all these new metrics I've got a whole bunch more failures to address in <a href="http://cpants.perl.org/author/DANBERR">my CPAN modules</a>. </p>http://berrange.com/personal/diary/2008/04/new-cpants-test-criteria-for-fedoranoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-7469824443716700845Thu, 20 Mar 2008 01:43:00 +00002008-03-20T03:12:35.237Z<p> The question is.. <blockquote> <p> <em>How long should police/security services be allowed to hold a suspect prior to charging them with an offense?</em></p> </blockquote> <p> In the USA the answer to this question is <em>2 days</em>; In Russia it is <em>5 days</em>; In France it is <em>6 days</em>; In the UK the answer is <strong>already an astonishing 28 days</strong>. <a href="http://www.liberty-human-rights.org.uk/issues/pdfs/comparative-law-exec-summary.pdf">No other democracy comes close</a>. And yet the government's latest "anti-terror" legistation (which will get a second reading in the commons on April 1st ,with a vote to follow after the May local elections), proposes to extend <strong>this period of pre-charge detention to 42 days</strong>. </p> <p> The idea that someone can be held by Police for as long as 42 days, potentially without being told of the grounds for suspicion, let alone be charged with an offence, is an idea that should remain the province of Kafka and his book <a href="http://www.gutenberg.org/etext/7849">"The Trial"</a>. The Judiciary serves the key role in English law providing the counter-balance to the state, allowing independent oversight and review of prosecution. Yet until you are charged with an offense there are no grounds for the Judiciary to intervene. You cannot defend yourself when there is no charge against which to defend. </p> <blockquote> ...the first impression made by the defence will often determine the whole course of the proceedings. Unfortunately, though, he would still have to make it clear to K. that the first documents submitted are sometimes not even read by the court. if the court deems it necessary it can be made public but there is no law that says it has to be. As a result, the accused and his defence don't have access even to the court records, and especially not to the indictment, and that means we generally don't know - or at least not precisely - what the first documents need to be about, which means that if they do contain anything of relevance to the case it's only by a lucky coincidence. If anything about the individual charges and the reasons for them comes out clearly or can be guessed at while the accused is being questioned, then it's possible to work out and submit documents that really direct the issue and present proof, but not before. Conditions like this, of course, place the defence in a very unfavourable and difficult position. But that is what they intend. In fact, defence is not really allowed under the law, it's only tolerated, and there is even some dispute about whether the relevant parts of the law imply even that. So strictly speaking, there is no such thing as a counsel acknowledged by the court, and anyone who comes before this court as counsel is basically no more than a barrack room lawyer. The effect of all this, of course, is to remove the dignity of the whole procedure, </blockquote> <p> This is an extract from "The Trial" yet disturbingly close to what can happen in the UK should the government continue to extend pre-charge detention during which time the (yet to be) accused is allowed no meaningful defense. </p> <p> <blockquote> <em>What is the motivation of the government in extending this pre-charge period ?</em> </blockquote> <p> The posited need is to allow more time to investigate "terrorism" cases. There is little-to-no evidence that the current limit of 28 days is harming such investigations, and members of the security services, police and judiciary have either directly questioned whether an extension would have any tangible benefit in terror investigations, or failed to provide any supporting evidence for the extension. Furthermore, <strong>there are viable alternatives</strong> to this proposal which extend the powers relating to terrorism investigations. As part of the <a href="http://liberty-human-rights.org.uk/issues/2-terrorism/extension-of-pre-charge-detention/index.shtml">Charge or Release</a> campaign, <a href="http://liberty-human-rights.org.uk/">Liberty Human Rights</a> have suggested &amp; support a number of alternative powers: </p> <blockquote style="padding-left: 3em"> <ul> <li>Remove the bar on the use of intercept (phone tap) evidence because its inadmissibility is a major factor in being unable to bring charges in terror cases. Liberty welcomes the Government?s proposed Privy Council review into the use of this evidence in terror trials. </li> <li>Allow post-charge questioning in terror cases, provided that the initial charge is legitimate and there is judicial oversight. This will allow for a charge to be replaced with a more appropriate offense at a later stage. </li> <li>Hire more interpreters: Prioritise the hiring of more foreign language interpreters to expedite pre-charge questioning and other procedures. </li> <li>Add resources: More resources for police and intelligence services. </li> <li>Emergency measures in the Civil Contingencies Act 2004 could be triggered in a genuine emergency in which the police are overwhelmed by multiple terror plots, allowing the Government to temporarily extend pre-charge detention subject to Parliamentary and judicial oversight. Liberty believes that this is preferable to creating a permanent state of emergency. </li> </ul> </blockquote> <p> Crucially these proposals do not undermine the foundations of our justice system. </p> <blockquote> <em>What can you do about it?</em> </blockquote> <ul> <li><a href="http://www.liberty-human-rights.org.uk/issues/2-terrorism/extension-of-pre-charge-detention/what-you-can-do.shtml">Support the Charge or Release</a> campaign. <li><a href="http://www.theyworkforyou.com/">Check up on your MP's record</a> of participation in the parliamentary debates. After all they work for and represent <em>you</em>. <li>And if they support the extension to 42 days, <a href="http://www.writetothem.com/">write to your MP</a> and present a counterpoint to the government's plans. <li><a href="http://liberty-human-rights.org.uk/issues/2-terrorism/extension-of-pre-charge-detention/index.shtml">Educate yourself on the issues</a><br> <object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/sA-cUpLa-aE&hl=en"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/sA-cUpLa-aE&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object></li> </ul>http://berrange.com/personal/diary/2008/03/answer-is-not-42noreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-4293104055517467712Sun, 17 Feb 2008 20:48:00 +00002008-02-17T21:17:08.276Z<p> For the <a href="http://ovirt.org/">oVirt</a> project the end product distributed to users consists of a LiveCD image to serve as the 'managed node' for hosting guests, and a virtual machine appliance to serve as the 'admin node' for the web UI. The excellant Fedora LiveCD creator tools obviously already deal with the first use case. For the second though we don't currently have a solution. The way we build the admin node appliance is to boot a virtual machine and run anaconda with a kickstart, and then grab the resulting installed disk image. While this works it involves a number of error-prone steps. Appliance images are not inherantly different from LiveCDs - instead of a ext3 filesystem inside an ISO using syslinux, we want a number of filesystems inside a partitioned disk using grub. The overall OS installation method is the same in both use cases. </p> <p> After a day's hacking I've managed to re-factor the internals of the LiveCD creator, and add a new installation class able to create virtual machine appliances. As its input it takes a kickstart file, and the names and sizes for one or more output files (which will act as the disks). It reads the 'part' entries from the kickstart file and uses parted to create suitable partitions across the disks. It then uses kpartx to map the partitions and mounts them all in the chroot. The regular LiveCD installation process then takes place. Once complete, it writes a grub config and installs the bootloader into the MBR. The result is one or more files representing the appliance's virtual disks which can be directly booted in KVM / Xen / VMware. </p> <p> The <code>virt-image</code> tool defines a simple XML format which can be used to describe a virtual appliance. It specifies things like minimum recommended RAM and VCPUs, the disks associated with the appliance, and the hypervisor requirements for booting it (eg Xen paravirt vs bare metal / fullvirt). Given one of these XML files, the <code>virt-image</code> tool can use libvirt to directly deploy a virtual machine without requiring any further user input. So an obvious extra feature for the virtual appliance creator is to output a virt-image XML description. With a demo kickstart file for the <strong>oVirt</strong> admin node, I end up with 2 disks: </p> <pre> -rwxr-xr-x 1 root root 5242880001 2008-02-17 14:48 ovirt-wui-os.raw -rwxr-xr-x 1 root root 1048576001 2008-02-17 14:48 ovirt-wui-data.raw </pre> <p> And an associated XML file </p> <pre> &lt;image&gt; &lt;name&gt;ovirt-wui&lt;/name&gt; &lt;domain&gt; &lt;boot type='hvm'&gt; &lt;guest&gt; &lt;arch&gt;x86_64&lt;/arch&gt; &lt;/guest&gt; &lt;os&gt; &lt;loader dev='hd'/&gt; &lt;/os&gt; &lt;drive disk='ovirt-wui-os.raw' target='hda'/&gt; &lt;drive disk='ovirt-wui-data.raw' target='hdb'/&gt; &lt;/boot&gt; &lt;devices&gt; &lt;vcpu&gt;1&lt;/vcpu&gt; &lt;memory&gt;262144&lt;/memory&gt; &lt;interface/&gt; &lt;graphics/&gt; &lt;/devices&gt; &lt;/domain&gt; &lt;storage&gt; &lt;disk file='ovirt-wui-os.raw' use='system' format='qcow2'/&gt; &lt;disk file='ovirt-wui-data.raw' use='system' format='qcow2'/&gt; &lt;/storage&gt; &lt;/image&gt; </pre> <p> To deploy the appliance under KVM I run </p> <pre> # virt-image --connect qemu:///system ovirt-wui.xml # virsh --connect qemu:///system list Id Name State ---------------------------------- 1 ovirt-wui running </pre> <p> Now raw disk images are really quite large - in this example I have a 5 GB and a 1 GB image. The LiveCD creator saves space by using resize2fs to shrink the ext3 filesystem, but this won't help disk images since the partitions are a fixed size regardless of what the filesystem size is. So to allow smaller the appliance creator is able to call out to <code>qemu-img</code> to convert the raw file into a <code>qcow2</code> (QEMU/KVM) or <code>vmdk</code> (VMWare) disk image, both of which are grow on demand formats. The <code>qcow2</code> image can even be compressed. Wtth the <code>qcow2</code> format the disks for the <strong>oVirt</strong> WUI reduce to 600 KB and 1.9 GB. </p> <p> The LiveCD tools have already seen immense popularity in the Fedora community. Once I polish off <a href="http://www.redhat.com/archives/fedora-livecd-list/2008-February/msg00085.html">this new code</a> to be production quality, it is my hope that we'll see similar uptake by people interested in creating and distributing appliances. The great thing about basing the appliance creator on the Live CD codebase and using kickstart files for both, is that you can easily switch between doing regular anaconda installs, creating Live CDs and creating appliances at will, with a single kickstart file. </p>http://berrange.com/personal/diary/2008/02/prototype-for-fedora-virtual-machinenoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-7815184654174838925Thu, 14 Feb 2008 22:15:00 +00002008-02-14T22:35:55.570Z<p> Way back in Fedora Core 5, we introduced the <a href="http://libvirt.org">libvirt management library</a> for virtual machines. Shortly thereafter in Fedora Core 6 we introduced <a href="http://virt-manager.org/">Virtual Machine Manager</a> (aka virt-manager) desktop application. In Fedora Core 7 we introduced <a href="http://kvm.qumranet.com/">KVM</a> as a virtualization technology. In Fedora 8 we introduced secure remote management of virtual machines using TLS/x509, further enhanced to support Kerberos in Fedora 9. Meanwhile the <a href="http://freeipa.org/">FreeIPA</a> project has been busy working to integrate Kerberos and LDAP (Fedora Directory Server). </p> <p> Clearly the time has come to move beyond managing handfuls of virtual machines with a desktop application, and take full advantage of all the infrastructure we've painstakingly prepared. To move to a web-based management capable of scaling from a handful of machines, up to an entire data center, allowing administration from any client OS whether Linux or Windows or Mac OS-X. </p> <p> It is time for <a href="http://ovirt.org/"><strong><big>oVirt</big></strong></a>. </p> <p> Quoting <a href="http://www.redhat.com/archives/libvir-list/2008-February/msg00155.html">Hugh's announcement</a> </p> <blockquote> <pre> oVirt is: * A small OS image that runs libvirt and hosts virtual machines * A Web-based virtual machine management console oVirt goals: * Empower virtual machine owners without giving up control of hardware * Automate virtual machine clustering, load balancing, and SLA maintenance * Simplify management of large numbers of machines * Work across platforms and architectures oVirt uses: * A kerberos/LDAP server for authentication and authorization (oVirt ships with FreeIPA) * DNS/DHCP services on the local LAN -- or provides them for oVirt hosts over a private network if desired * Libvirt for virtual machine management, storage management, and secure remote communication * collectd for stats gathering and monitoring * Rails for rapid, flexible development oVirt mailing list: http://www.redhat.com/mailman/listinfo/ovirt-devel oVirt IRC: irc.freenode.net/#ovirt oVirt website: http://ovirt.org </pre> </blockquote> <p> <a href="http://fedoraproject.org/">Fedora 9</a> (current rawhide) is providing the underlying OS distribution for both the "managed nodes" running guests, and the management application itself. We're targetting <a href="http://libvirt.org/">libvirt</a> as the mangement API, to avoid being tied into any single virtualization technology, though KVM is our current technology of choice due to its clean integration with the Linux kernel, and its ever improving performance. </p>http://berrange.com/personal/diary/2008/02/announcing-ovirt-web-based-virtualnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-5404216273494923560Tue, 05 Feb 2008 01:04:00 +00002008-02-05T01:17:30.811Z<p> The new GTK-VNC 0.3.3 release was made available over the weekend. This was primarily a bug fix release dealing with yet more UltraVNC compatability issues, a few crash scenarios, improved key-state tracking to deal with annoying GTK behaviour where it fails to send you 'release' events during key-repeat, and ability to reset modifier state when the widget looses focus to avoid the server thinking Alt/Ctrl are stuck 'on'. </p> <p> We also have an <strong>EXPERIMENTAL</strong> web browser plugin for firefox. Before you go and install this, remember I'm saying this is <strong>EXPERIMENTAL</strong>. We're not recommending anyone use this outside the lab yet because there needs to be a proper security audit of our protocol handling, and some more thought about how plugin security should work. Needless to say the build is disabled by default for now. </p> <p> More interestingly though, is that the dev tree of GTK-VNC now has support for scaling the VNC display. We didn't fancy writing pixmap scaling code, so for this we're integrating with <a href="http://gtkglext.sourceforge.net/">GtkGExt</a> and OpenGL to get hardware accelerated scaling. The performance is pretty decent - Anthony tells me he's been able to watch a DVD over VNC with scaling active. Sadly I'm stuck with the non-accelerated radeon driver in my laptop for now, so CPU usage is considerable. Still, its nice to be able to go "full screen" and have it use all screen real estate even when the remote desktop resolution doesn't match the local desktop resolution. </p>http://berrange.com/personal/diary/2008/02/new-gtk-vnc-and-work-on-openglnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-9193491123818894609Fri, 01 Feb 2008 15:26:00 +00002008-02-01T15:57:36.728Z<p> You may recall <a href="http://berrange.com/personal/diary/2007/11/plan-for-xen-kernels-in-fedora-9">my announcement</a> of our plans for Fedora 9 Xen kernels. The 5 second summary is that we're throwing away the current Xen kernels, and writing Xen support on top of paravirt_ops, for both DomU and Dom0, and both i386 &amp; x86_64. Hugely ambitious given the limited time scales involved and the fact that only i386 DomU was working when we started this project. </p> <p> Just minutes ago, after many many weeks work, Stephen Tweedie reached a very important milestone - the first kernel build capable of fully booting on Dom0, including the IOAPIC &amp; DMA support neccessary to run real hardware drivers - ie the ability to access your real disks once the initrd is done :-) </p> <blockquote> <pre> (10:22:13 AM) sct: It boots (10:22:14 AM) sct: It runs (10:22:16 AM) sct: I can ssh into it (10:22:50 AM) sct: [root@ghost ~]# dmesg|grep para (10:22:50 AM) sct: Booting paravirtualized kernel on Xen (10:22:50 AM) sct: [root@ghost ~]# </pre> </blockquote> <p> It is beginning to look like we might actually succeed in our goals in time for Fedora 9 - congrats due to Stephen & the rest of the team working on this ! </p>http://berrange.com/personal/diary/2008/02/progress-in-fedora-9-xen-pvops-kernelnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-6184718449878717559Fri, 11 Jan 2008 05:36:00 +00002008-01-11T05:46:25.866Z<p> For Fedora 9 one of the new feature's we've got pending for virtualization is <a href="http://fedoraproject.org/wiki/Features/VirtPolicyKit">integration with PolicyKit</a>. This will allow virt-manager to manage local hypervisor connections without having to run as root via consolehelper. Although the virt-manager part of this won't be ready for a while yet, the libvirt bits were made available in libvirt 0.4.0 just before christmas. As a sneak preview this is now in updates-testing and already gives you the ability to run virsh as non root. </p> <p> For example, currently if you run virsh as non-root you'l lsee something like </p> <pre> $ virsh --connect qemu:///system libvir: Remote error : authentication failed error: failed to connect to the hypervisor </pre> <p> Now with PolicyKit support you can use 'polkit-grant' to authenticate and then you'll be able to run virsh without issue! </p> <pre> $ polkit-grant --gain org.libvirt.unix.manage Attempting to gain the privilege for org.libvirt.unix.manage. Authentication is required. Password: Keep this privilege for the session? [no/session]? session Successfully gained the privilege for org.libvirt.unix.manage. $ virsh --connect qemu:///system Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # start VirtTest virsh # list Id Name State ---------------------------------- 1 VirtTest running </pre> <p> In other news, <a href="http://annexia.org/">Rich Jones</a> has created a <a href="http://sourceforge.net/mailarchive/forum.php?thread_name=47866C66.9090000%40redhat.com&forum_name=gtk-vnc-devel">Mozilla Plugin for GTK-VNC</a> so there's at last a less-sucky replacement for the terrible Java VNC plugins out there </p>http://berrange.com/personal/diary/2008/01/policykit-and-libvirt-integration_11noreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-1732226149687596917Mon, 31 Dec 2007 18:05:00 +00002007-12-31T18:21:05.433Z<p> Things have been progressing well with the <a href="http://gtk-vnc.sourceforge.net/">GTK-VNC widget</a>. The 0.3.0 release a few weeks back fixed a couple of co-routine race conditions, fixed portability to Solaris and added compatability for UltraVNC brokenness - it claims support for RFB version 3.4 which doesn't technically exist. 0.3.1 was a brown paper bag release a day later, due to the 'make dist' process going wrong with 0.3.0; say no more. Today <a href="http://codemonkey.ws/">Anthony</a> released version 0.3.2 which adds a GThread based co-routine implementation to provide portability to platforms lacking ucontext support (yes I'm looking at you Windows/cygwin). It also adds support for the RRE server encoding which is a zlib compressed format, although not commonly used its in the spec so its worth supporting. </p> <p> For the next releases we'll have support for the Tight encoding as used by TightVNC - this is a more advanced variant on RRE, in some cases using JPEG as its compression method which is interesting. We're also in communication with the VMWare team to see if we can write code to support the RFB extensions, for which they recently got official extension numbers assigned. We decided to apply the 'release early, release often' mentality with earnest, and thus we're aiming to have regular monthly releases for the forseeable future. Meanwhile John is continuing to develop <a href="http://www.gnome.org/projects/vinagre/">Vinagre</a>, a long overdue modern VNC client taking full advantage of the GNOME infrastructure & desktop integration points. </p>http://berrange.com/personal/diary/2007/12/new-gtk-vnc-release-032noreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-8085336440450637470Sat, 29 Dec 2007 01:28:00 +00002007-12-29T01:43:47.443Z<p> If you are a Perl developer you may have come across <a href="http://cpants.perl.org/">CPANTS</a> which analyses and ranks all distributions and authors on <a href="http://search.cpan.org">CPAN</a> based on their <strong><a href="http://cpants.perl.org/kwalitee.html">Kwalitee</a></strong> score. To quote... </p> <blockquote> <pre> What is a good module? That's hard to say. What is good code? That's also hard to say. "Quality" is not a well-defined term in computing ... and especially not Perl. One man's Thing of Beauty is another's man's Evil Hack Since we can't define quality, how do we write a program to assure it? </pre> <p> <em><strong>Kwalitee:</strong> It looks like quality, it sounds like quality, but it's not quite quality.</em> </p> </blockquote> <p> I was rather disappointed to discover <a href="http://cpants.perl.org/author/DANBERR">my own Kwalitee scores</a> were rather poor so have been spending time to improve matters. The key to this is to run a test to check the Kwalitee score of a new release <strong>before uploading</strong> it to CPAN. Conveniently the very code used to generate the rankings is available to download and run offline in the form of the <a href="http://search.cpan.org/dist/Module-CPANTS-Analyse/">Module-CPANTS-Analyse</a>. Inconveniently this wasn't in Fedora...<strong>until today</strong>. I finally got all the dependent modules through review and built for rawhide, with F-8 to follow shortly... So now if you want to test the Kwalitee of your Perl modules before release just run: </p> <pre> # yum install perl-Module-CPANTS-Analyse # cpants_lint.pl /path/to/my/module.tar.gz </pre> <p> It already helped me get Test-AutoBuild perfect... </p> <pre> $ cpants_lint.pl Test-AutoBuild-1.2.2.tar.gz Checked dist Test-AutoBuild-1.2.2.tar.gz Kwalitee rating 112.50% (27/24) Congratulations for building a 'perfect' distribution! </pre> <p> 112.50% you might wonder ? Yes, indeed. Only 24 of the checks are considered mandatory at this time. The other 3 are optional, but good practice none-the-less. To get to 100% you need to pass all the mandatory checks. If you manage this, then passing any optional checks will give you an additional boost. </p>http://berrange.com/personal/diary/2007/12/improve-your-perl-code-kwaliteenoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-5905633036531081403Mon, 10 Dec 2007 01:58:00 +00002007-12-10T02:18:12.547Z<p> I finally got around to doing some more work on <a href="http://autobuild.org/">Test-AutoBuild</a> - a build and test automation framework for upstream developers. It checks sources out of SCM repos (CVS, Subversion, SVK, GNU Arch, Mercurial, Perforce), runs any build and test processes. It detects any RPMs generated during the build and publishes them in a YUM repo. It also publishes HTML status pages showing build logs, list of generated packages, any artifacts generated (eg, code test coverage reports, API documentation) and changelogs from the SCM repo. It is a similar system to CruiseControl, but is more powerful since it directly understands the idea of module dependancies, and so can intelligently manage chained builds of multiple dependant modules. We use this in the ET group for testing our virtualization stack. Our <a href="http://builder.virt-manager.org/">nightly builder</a> builds libvirt and gtk-vnc first, then builds virt-viewer and virt-install against these builds, and finally builds virt-manager against all of them. So any change in libvirt gets validated to make sure it doesn't break apps using libvirt. Since autobuild understands the dependancies, it can do intelligent build caching. eg if there were new changes in the libvirt SCM repo, but none in the virt-manager repos, it will still do a rebuild of virt-manager as a regression test </p> <p> This <a href="https://mail.gna.org/public/testautobuild-announce/2007-12/msg00000.html">new release version 1.2.1</a> was all about making the SCM checkout process more reliable. Previously if a module could not be checked out (eg due to a server being down, or a config file typo) the entire build cycle would be aborted. With the new release, the troublesome module is simply skipped and the SCM logs published for the admin to diagnose - other modules in the build cycle continue to be built </p>http://berrange.com/personal/diary/2007/12/new-release-of-test-autobuild-121noreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-5291104927250988108Fri, 30 Nov 2007 20:36:00 +00002007-11-30T20:54:05.390Z<p> This is a friendly alert of the major plans we have for Xen kernels in Fedora 9 timeframe... Also <a href="http://www.redhat.com/archives/fedora-xen/2007-November/msg00106.html">syndicated</a> on the <a href="http://www.redhat.com/mailman/listinfo/fedora-xen">fedora-xen</a> mailing list. </p> <p> Since we first added Xen in Fedora Core 4, our kernels have been based on a forward-port of XenSource's upstream Xen kernels, to new LKML. For a long time we ported their 2.6.16 tree to 2.6.18. Now we do ports of their 2.6.18 tree to 2.6.21/22/23, etc. At the same time, upstream Linux gained Xen support for i386 DomU, and shortly x86_64 DomU, and is generally getting ever more virtualization capabilities. </p> <p> As everyone knows, we have tended to lag behind Fedora's state-of-the-art bare metal kernels by several releases due to the effort required to port Xen to newer LKML releases. Despite our best efforts, this lag has been getting worse, not better. </p> <p> We have taken the decision, that this situation is unacceptable for Fedora 9. We simply cannot spend more time forward porting Xen kernels. Either Xen has to be dropped entirely, or we need a different strategy for dealing with the kernels. Since people seeem to use Xen, we have decided not to drop it :-) </p> <p> So the plan is to re-focus 100% of all Xen kernel efforts onto paravirt_ops. LKML already has i386 pv_ops + Xen DomU. We intend to build on this to add: </p> <ul> <li>x64_64 pv_ops</li> <li>x86_64 Xen DomU on pv_ops</li> <li>i386 &amp; x86_64 Xen Dom0 on pv_ops</li> <li>memory balloon</li> <li>paravirt framebuffer</li> <li> save/restore</li> </ul> <p> All of this based on same LKML release as Fedora bare metal. If all goes to plan it may even be in the base kernel RPM, instead of kernel-xen, but thats a minor concern compared to the actual coding. </p> <p> Getting all this done for Fedora 9 is seriously ambitious, but it is the only long term sustainable option, other than dropping Xen entirely. </p> <p> What this means though, is that Fedora 9 Xen will certainly be going through periods of instability and will certainly be even buggier than normal. F9 may well end up lacking features compared to Xen in Fedora 8 & earlier (eg no PCI device passthrough, or CPU hotplug). On the plus side though we will be 100% back in sync with bare metal kernel versions & hopefully even have a lot of this stuff merged in LKML to make ongoing maintainence sustainable. Short term pain; Long term gain! </p> <p> I have not got any ETA on when any of these kernel changes will appear in rawhide - some time before the F9 feature freeze date is best guesstimate. We will alert people when the time comes. There is a <a href="http://fedoraproject.org/wiki/Features/XenPvops">F9 feature page</a> with some amount of info about the plan. </p> <p> In terms of Fedora 6/7/8 maintainence... The kernel-xen in these existing releases already lags behind the bare metal kernel version by 2-3 releases. We do not intend to continue trying to rebase the kernel-xen in existing Fedora releases. It will be essentially important bug-fix mode only. This is neccessary to enable maximum resources to be focused on the critical Fedora 9 Xen work. </p> <p> This broadcast was on behalf of some very busy Fedora Xen kernel developers :-) </p>http://berrange.com/personal/diary/2007/11/plan-for-xen-kernels-in-fedora-9noreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-3350215080810959529Mon, 05 Nov 2007 18:44:00 +00002007-11-06T00:26:29.253Z<p> For the short story, <a href="http://www.redhat.com/archives/libvir-list/2007-November/msg00023.html">read the announcement</a>. For the long story, read on..... </p> <p> The <a href="http://libvirt.org/">libvirt</a> project provides a hypervisor agnostic API for managing virtual machines (and their associated resources like their network & storage). The libvirt API has 3 core characteristics - simplicity - minimal code required to get useful work done; standard - the same API can be used across any virtualization backend; stable - guarenteed stable public API and XML descriptions across releases. In the short time it has been around, libvirt has proved impressively popular, finding its way in all the main Linux distributions, as well as Open Solaris. There are drivers in libvirt for Xen, QEMU, KVM, OpenVZ and soon Linux-VServer. If someones contributes VMWare, UML, and VirtualBox support we'll basically have complete coverage for all common Linux virtualization platforms in a single open source API, usable by open & closed source apps alike (libvirt is LGPL licensed explicitly to enable use by closed source apps). </p> <p> In the enterprise world, people like to form committees to come up with comprehensive standards to cover everything you can think of, and then go off and write multiple implementations of these standards ;-) For virtualization, the 'standard' is based around the DMTF / CIM specification. Pretty much since the start of the libvirt project, people have asked why we didn't just implement the CIM APIs directly. We always wanted the core of our public APIs to be simpler to use though. At the same time, we recognise that some people really want to use a CIM API for their virtualization management tools. Thus we've always supported the idea of writing a CIM provider on top of libvirt. Not only would this mean only a single CIM provider implementation is needed for all of the virt platforms supported in libvirt, but it gives good interoperability between tools using libvirt vs CIM. </p> <p> Over the past year & a half (or more), the Xen project has developed a CIM provider using the Xen-API as the underlying implementation. Indeed at one time this actually used libvirt instead of Xen-API, but back when the switch was made to Xen-API, KVM wasn't around so the benefits of a hypervisor agnositic libvirt API were more hypothetical than tangible. KVM does eventually appear on the scene & sure enough, the topic of developing CIM providers for KVM soon comes up. KVM though doesn't have any form of existing management API to deal with - a KVM guest is 'managed' by running a QEMU process, and killing it when you're done. QEMU provides a mini admin shell for controlling various aspects of its behaviour. Turning this into a formal API is hard work - libvirt has already done it once and you don't want to have to duplicate that :-) </p> <p> At the recent KVM forum, IBM announced that they were going to develop a CIM provider based on libvirt, and release it to the open source community. Fast forward a few months and I'm happy to <a href="http://www.redhat.com/archives/libvir-list/2007-November/msg00023.html">announce their plans have come to fruition</a>. Furthermore, this is not just a 3rd party add-on, the CIM provider is to be a core part of the libvirt project & ecosystem. We're collaborating on ideas, API requirements, hosting for our infrastructure (websites, SCM repos, mailing lists, IRC channels, etc) and above all working towards the common goal of providing <em><strong>state-of-the-art open source management APIs, capable of working across any virtualization platform.</strong></em> </p>http://berrange.com/personal/diary/2007/11/announcing-libvirt-cim-providernoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-4161717974607937844Mon, 05 Nov 2007 00:29:00 +00002007-11-05T01:04:28.027Z<p> In his <a href="http://hoegsberg.blogspot.com/2007/08/redirected-direct-rendering.html"> recent blog posting</a> on redirected direct renderering, Kristian happened to mention <a href="http://clutter-project.org/">Clutter</a>, a toolkit which allows you to do 3d graphics without first needing to acquire a PhD in OpenGL. I made a mental note to give it a try sometime. </p> <p> On saturday I spent a few hours doing the major upgrade from Fedora 6 to Fedora 8 on my laptop & desktop (skipping F7). I did it the crazy way, just changing my YUM config files & letting it upgrade everything. I can't say it was a painless process, but I do finally have two working boxes on F8 now. I also took the opportunity to switch my IBM T60p laptop over to the Avivo driver, instead of the VESA driver & which worked without a hitch. </p> <p> Back on topic. After the upgrade to F8, I poked at the repos and found that (nearly) all the Clutter related bits are packaged & available to Fedora users already. There is just an annoying <a href="https://bugzilla.redhat.com/show_bug.cgi?id=365981">buildrequires missing</a> in the python bindings spec file, which meant the RPM is missing the GTK & GST APIs for clutter. A quick rebuild fixed that issue. You may remember I've been working on a <a href="http://gtk-vnc.sourceforge.net/">GTK widget</a> for displayed VNC sessions. One evil thought, led to another even more evil thought, and thus I ended up writing a <a href="/~dan/gvncclutter.py">VNC viewer program</a> which displays multiple VNC sessions on a spinning cube. To make it even more evil, I decided to not restrict it to a cube, and instead generalized to an arbitrary number of sides. </p> <p> The results are spectacular, though a static screenshot doesn't really do it justice...<br/> <a href="/~dan/gvncclutter.png"><img border="0" src="/~dan/gvncclutter-small.png" alt="VNC sessions on a 3d spinning hexagon"/></a> <br/> Ctrl+Alt+PageUp/PageDown lets you rotate to the previous/next session respectively. The mouse & keyboard events are fully plumbed in so you can actually interact with each session. In this example I just started 6 VNC server instances running TWM at 500x500 pixels, but they could have been real GNOME desktops too. The only issue is that I've not yet figured out how todo correct depth sorting of each desktops. You don't notice this problem in the screenshot, since I've just got them all rendering at 50% opacity ;-) It is impressively slow & impressively fast at the same time. Slow because I'm using Avivo which doesn't have any real 3d rendering support yet; fast because I'm amazed it is actually working at all :-) </p> <p> Now to hook this all up into the next version of <a href="http://virt-manager.org/">virt-manager</a>..... just kidding ;-P </p>http://berrange.com/personal/diary/2007/11/vnc-sessions-on-3-d-spinning-cubenoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-1245100596584899172Fri, 02 Nov 2007 01:32:00 +00002007-11-02T01:47:50.359Z<p> Alot has been going on in the libvirt universe recently as it continues on its path to world domination. A couple of days ago Daniel Hokka Zakrisson (that's the 4th Daniel involved in libvirt!) surprised us all by <a href="http://www.redhat.com/archives/libvir-list/2007-October/msg00273.html">announcing the start</a> of a Linux-VServer driver for libvirt. This is the second container based virtualization driver, following on from the previous OpenVZ driver work. On the KVM front we now have support for save & restore thanks to Jim Paris, and the Xen & KVM drivers can also do CDROM media changes which will make Windows guest installs much more friendly. A bunch of work is taking place around NUMA to allow guests to be intelligently placed to take advantage of the capabilities of large NUMA boxes. </p> <p> I've been working on integrating SASL support into the remote management driver. This will augment our existing SSL/TLS + x509 security model, to provide fun stuff like Kerberos integration (single sign on!) and plain old username/password auth (with data encryption thrown in too though). This will tie in very nicely with the <a href="http://freeipa.org/">FreeIPA</a> project which is providing a way to get a pre-integrated Kerberos + LDAP solution for Linux users to compet with ActiveDirectory. I installed FreeIPA in a Fedora 7 guest a few weeks back and can say it is looking very impressive indeed. </p> <p> There have been lengthy discussions & arguments about how to represent & manage storage from within libvirt, which is a key requirement for being able to provision guest OS from a remote host. Once this all gets fleshed out we'll be able to manage plain old files, QCow/VMDK files, LVM volumes, iSCSI volumes, disks/partitions and even FiberChannel with NPIV from within virt-manager and other libvirt based apps. This will improve the admin experiance significantly. </p> <p> <a href="http://annexia.org/">Rich Jones</a> has put together all sorts of fun apps ontop of libvirt in recent months. <a href="http://et.redhat.com/~rjones/virt-top/">virt-top</a> is a command line tool to provide a 'top' like display of CPU, disk & network activity in all guest machines on a host. <a href="http://et.redhat.com/~rjones/virt-p2v/">Virt-P2V</a> is a Live CD based on Fedora which allows you to take an existing physical machine and turn its disk images into a virtual guest running under Xen / KVM fullvirt. <a href="http://et.redhat.com/~rjones/nagios-virt/">Nagios-Virt</a> is a plugin for the Nagios monitoring system which gives status on virtual machines. There are various other interesting admin tools along these lines in the works, so watch this space.... </p>http://berrange.com/personal/diary/2007/11/news-from-libvirt-virtualizationnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-7235618952718864022Wed, 05 Sep 2007 21:54:00 +00002007-09-05T22:23:17.266Z<p> I've got many boxes for testing purposes and while often I can run graphical apps over SSH, every so often I really do need to run the app within a full GNOME session. For example, the incredible new PolicyKit app in Fedora 8 enables desktop applications to authenticate to gain extra privileges. PolicyKit uses ConsoleKit for its session tracking & the ConsoleKit sessions are created by GDM when you initially login. Thus to test an application using PolicyKit you really do need to login via GDM and run a full GNOME session, not merely a X tunnel over SSH. </p> <p> Now of course the critical times when I need to do this testing are when I'm not physically anywhere near the machine I need to test on. And invariably I've not left a login session active, nor even GNOME's 'remote desktop' access enabled. Traditionally I've just created a suitable VNC server startup file containing </p> <pre> $ cat $HOME/.vnc/xstartup #!/bin/sh [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources xsetroot -solid grey vncconfig -iconic & unset DBUS_SESSION_BUS_ADDRESS eval `dbus-launch --sh-syntax --exit-with-session` exec gnome-session </pre> <p> This gets me a full GNOME login session. Unfortunately there's no ConsoleKit session associated with this & thus no possibility of using PolicyKit. GNOME itself though does come with VINO which can export your regular X session using the VNC protocol. If only I were logged into X on the machine's console & running VINO. Argh. </p> <p> After much poking around I finally figured out a solution. First off, SSH to the box in question as your regular desktop user. Now we can use gconftool-2 to enable VINO. We need to enable it, enable authentication, set a password, turn off incoming connection prompts and possibily set an explicit port (if you have something else on the regular port 5900 - eg a Xen guest). </p> <pre> # Disable local confirmation dialog for incoming connections gconftool-2 --type bool --set /desktop/gnome/remote_access/prompt_enabled false # Change VNC port to :9 instead of :0 gconftool-2 --type bool --set /desktop/gnome/remote_access/use_alternative_port true gconftool-2 --type int --set /desktop/gnome/remote_access/alternative_port 5909 # Enable password auth gconftool-2 --type list --list-type string --set /desktop/gnome/remote_access/authentication_methods '[vnc]' PW=`echo 'mypassword' | base64` gconftool-2 --type string --set /desktop/gnome/remote_access/vnc_password $PW # Enable the VINO server gconftool-2 --type bool --set /desktop/gnome/remote_access/enabled true </pre> <p> So that has the VINO server configured to run when I'm logged in, but as I mentioned already - I'm typically not logged in on the console when I need to be. For this challenge GDM comes to the rescue. It is possible change its config file to specify that a particular user will be automatically logged in the moment GDM starts. To do this edit /etc/gdm/custom.conf and add </p> <pre> [daemon] AutomaticLogin=yourusername AutomaticLoginEnable=true </pre> <p> A quick restart of GDM later, and I'm automatically logged into the remote box with a full GNOME session, including all the neccessary ConsoleKit magic. I can now connect with VNC and properly test virt-manager / PolicyKit integration. Yay. </p>http://berrange.com/personal/diary/2007/09/remotely-setting-up-remote-access-tonoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-82219365109347682Thu, 16 Aug 2007 22:58:00 +00002007-08-17T00:11:20.497Z<p> Any OS running Fedora Core 6 or later has IPv6 networking support enabled out of the box. Most people will never notice and/or care since they're only ever connected to IPv4 networks. A few months back now though I decided it was time to give IPv6 a try for real.... </p> <p> I've got two servers on the Internet running in UserModeLinux guests, one running Debian, the other Fedora Core 6, and then a home network provided by a LinkSys router running OpenWRT White Russian. My goal was provide full IPv6 connectivity to all of them. </p> <h3>Home Router</h3> <p> I tackled the problem of the home router first. The OpenWRT wiki has an <a href="http://wiki.openwrt.org/IPv6_howto">IPv6 Howto</a>, describing various setups. I decided to get a tunnel from the fine folks at <a href="http://sixxs.net/">SixXS</a>. My Verizon DSL only provides a dynamic IPv4 address and regular IPv6 over IPv4 tunnels require the server end to know the IPv4 address of your local endpoint. Obviously this is a bit of a problem with a dynamic IPv4 endpoint. SixXS though have a funky way around this in the form of their AICCU daemon which sets up a heartbeat from your local endpoint to their server. Thus should your IPv4 address ever change it can (securely with SSL) inform the server of your changed configuration. So I registered with SixXS, requested an IPv6 tunnel and a short while later they approved me. The service is open to anyone who wants IPv6 connectivity - the approval process is mainly to help avoid abuse & frivilous requests. I was fortunate in that OCCAID are providing an IPv6 tunnel server just a few miles away in Boston - there's other tunnel servers dotted around but mostly concentrated in America or Europe at this time. </p> <p> With my IPv6 address allocated it and the OpenWRT guide handy my router was up & running with IPv6 connectivity - I could do ping sites over IPv6 eg </p> <pre> # ping6 www.kame.net PING www.kame.net (2001:200:0:8002:203:47ff:fea5:3085): 56 data bytes 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp6_seq=0 ttl=50 time=513.2 ms 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp6_seq=1 ttl=50 time=512.5 ms 64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: icmp6_seq=2 ttl=50 time=519.5 ms </pre> <p> OpenWRT only ships with an IPv4 firewall as standard, so I quickly added ip6tables rules to deny all incoming traffic to the router. Even though port-scanning the entire IPv6 address space is not practical, only a tiny portion is active, and nearly all tunnels end up using addresses ending in :1 and :2, so a firewall is a must no matter what. </p> <h3>Home Network</h3> <p> To ensure you are serious about making use of their services, SixXS operate a credit system for admin requests. You start off with enough credits to request a IPv6 tunnel, but not enough to request an IPv6 subnet. To gain credits you have to prove you can keep the tunnel operational 24 hours a day for 7 days in a row - you then start gaining credits for each day's uptime. So I had a slight pause before I could move onto setting up the home network. </p> <p> Fortunately the LinkSys router is very reliable and so after a week I had enough uptime and thus enough credits to request an IPv6 subnet. In the brave new world of 128 bit addressing there's no shortage of addresses, so to simplify routing, whenever someone needs a block of addresses they'll typically be allocated an entire /48. That's right /48 - you'll be given more global IPv6 addresses for your personal use, than there are total IPv4 addresses in existance. Another interesting difference is that IPv6 subnets are not technically 'sold' - they are merely 'loaned' to end users. The upshot is that there's no issue of having to pay your stinkin' DSL/Cable ISP $$$ per month for one or two extra addresses. </p> <p> Having got the subnet allocated, the first step is to configure an IP address on the LAN interface of the LinkSys box. With OpenWRT this just required editing /etc/init.d/S40network to add "ip -6 addr add 2001:XXXX:XXXX:XXXX::1/64 dev br0" (where 2001:XXXX:XXXX:XXXX is my subnet's prefix). When the various IPv6 protocols were specced out a big deal was made of the fact that there would be no NAT anywhere, and that client configuration would be completely automatic & be able to dynamically reconfigure itself on the fly. The key to this is what they call a 'router advertisment daemon'. On Linux this is the 'radvd' program. If you only have a single outgoing net connection, and a single local network, then configuring it is incredibly easy. Simply edit /etc/radvd.conf file and fill in the IPv6 address prefix for your subnet as allocated by SixXS. Then start the daemon. </p> <p> Remember I just mentioned network configuration would be automatic - well look at any Fedora box plugged into your local network at this point. You'll see they all just got globally routable IPv6 addresses assigned to their active network interfaces. Pop up a web browser and visit <a href="http://kame.net/">Kame</a> and you'll see an animated dancing turtle logo! IPv4 users only see a static image... </p> <h3>Bytemark Server</h3> <p> One of my web servers is running Debian in a User Mode Linux instance at <a href="http://bytemark.co.uk">Bytemark</a> in the UK. The good news is that Bytemark have already taken care of getting IPv6 connectivity into their network, so there's no need to use a tunnel on any server hosted by them. Simply ask their helpdesk to allocate you an IPv6 address from their pool, and add it to your primary ethernet address. Again don't forget to setup ip6tables firewall rules before doing this. For Debian configuring the eth0 was a mere matter of editing /etc/network/interfaces and adding </p> <pre> iface eth0 inet6 static address 2001:XXXX:XXXX:XXXX::2 netmask 64 up ip route add 2000::/3 via 2001:XXXX:XXXX:XXXX::1 </pre> <p> Again, with '2001:XXXX:XXXX:XXXX' being the address they allocated to your server. Since SSH listens for IPv6 connections by default, with the interface address configured I could now SSH from my laptop at home to my server using IPv6. Type 'who' and you'll see a big long IPv6 address against your username if its working correctly. </p> <h3>Linode Server</h3> <p> My other web server is hosted by <a href="http://linode.com/">Linode</a>. Unfortunately they don't provide direct IPv6 connectivity so I had to use a tunnel. Since I do have a permanent static IPv4 address though I could use a regular IPv6-over-IPv4 tunnel rather than the dynamic heartbeat one I used at home with SixXS. For the sake of redundancy I decided to get my tunnel from a different provider, this time choosing <a href="http://tunnelbroker.net/">Hurricane</a>. When registering with them you provide a little contact info and the IPv4 address of your server. A short while later they'll typically approve the request & activate their end of the tunnel. It is then a matter of configuring your end. This machine was running Fedora Core 6, so creating a tunnel requires adding a file /etc/sysconfig/network-scripts/ifcfg-sit1 containing something like </p> <pre> DEVICE=sit1 BOOTPROTO=none ONBOOT=yes IPV6INIT=yes IPV6TUNNELIPV4=YY.YY.YY.YY IPV6ADDR=2001:XXXX:XXXX:XXXX::2/64 </pre> <p> Where YY.YY.YY.YY was the IPv4 address of hurricane's tunnel server, and 2001:XXXX:XXXX:XXXX was the IPv6 address prefix they allocated for my server. A quick ifup later and this server too has IPv6 connectivity. </p> <h3>The summary</h3> <p> This was all spread out over a couple of weeks, but by the end of it I had got both servers and my entire home network all operational with fully routable, global IPv6 connectivity. I have three differents types of IPv6 connectivity - direct (from Bytemark), static tunnel (from Hurricane), and a dynamic tunnel (from SixXS - they offer static tunnels too). If you have a static IPv4 address there's a fourth way to get connected called 6-to-4 which maps your Ipv4 address into the IPv6 space and uses anycast routing. With so many ways to get IPv6 connectivity it doesn't matter if your crappy DSL/Cable ISP doesn't offer IPv6 - simply take them out of the equation. </p> <p> One of the great things about being rid of NAT is that I can directly SSH into any machine at home from outside my network - no need for VPNs, or special reverse proxy rules through the NAT gateway. IPv6 addresses are crazily long, so the one final thing I did was to setup DNS entries for all my boxes, including a DNS zone for my home network. Remember how all clients on the home network auto-configure themselves, well this is done based on their network prefix and their MAC address, so they'll always auto-configure themselves to the same IPv6 address. Makes it easy to give them permanent DNS mappings, without needing to manually administer a DHCP server. </p>http://berrange.com/personal/diary/2007/08/how-i-learned-to-stop-worrying-and-lovenoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-3752357339509440991Thu, 16 Aug 2007 01:55:00 +00002007-08-16T02:13:05.055Z<p> For Fedora 8 we have quite an <a href="http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity">ambitious set of goals</a> to improve security of the virtualization management stack. With the test2 date fast approaching things are starting to fall into place, although as ever its taken longer than expected. Should really have expected this since it requires getting code accepted in 3 upstream projects (Xen, QEMU, KVM), releases several brand new pieces of new software (GTK-VNC and Virt Viewer), and updating many others (Virt Manager & virt-install). </p> <p> A couple of weeks ago <a href="http://www.advogato.org/person/DV/">DV</a> released an update of libvirt which includes support for secure remote management, either tunnelled over SSH, or directly connecting with TLS/SSL and x509 certificate authentication. This was the culmination of many months work by <a href="http://libvirt.org/">Rich Jones</a>, and review & feedback by the rest of the <a href="http://libvirt.org/">libvirt</a> team. Oh, it also supports IPv6 out of the box - the only open source virtualization management software to support IPv6 for remote management. </p> <p> Yesterday I <a href="http://lists.gnu.org/archive/html/qemu-devel/2007-08/msg00149.html">submitted</a> another iteration of the my patches to add password authentication and the VeNCrypt extension to QEMU's VNC server. The latter allows VNC to be encrypted with SSL/TLS and authenticated with x509 certificates. </p> <p> Today I <a href="http://lists.xensource.com/archives/html/xen-devel/2007-08/msg00351.html">submitted</a> changes to Xen to remove the horrible VNC server implementation based on LibVNCServer . For those who don't know, LibVNCServer is a horrible hack which turns the vncserver code into a shared library for embedding in applications which need VNC server support. Unfortunately the code is utterly unintelligable, and has been retrofitted with multi-thread support which is completely and utterly broken. We've made countless fixes to the thread synchronization to address deadlocks & crashes and still have no confidence that it is truely working correctly. So I'll be glad to see the back of LibVNCServer. </p> <p> Staying on the VNC theme, we announced the first official release of <a href="http://gtk-vnc.sourceforge.net/">GTK-VNC</a>. This is a GTK widget which provides a VNC client viewer. It provides a core library written in C, using coroutines to allow it to be completely asynchronous while remaining single threaded. A wrapper library using PyGTK provides access to the widget functionality from Python. Two example programs illustrate use of the widget by re-implementing the traditional 'vncviewer' in a few 10's of lines of code. The client is fully IPv6 aware, and as well as the traditional VNC authentication protocol, implements the VeNCrypt extension to provide secure TLS/SSL encrypted communications, optionally using x509 certificates to authenticate. </p> <p> Finally also announced the first release of <a href="http://virt-manager.org">Virtual Machine Viewer</a>, a lightweight, minimal UI for interacting with the graphical console from virtual machines. It is intended as a replacement for vncviewer, since it integrates with libvirt there is no need to tell it the VNC display address - just tell it the guest name, ID or UUID and it'll figure out the rest. </p> <p> There's still plenty of work to be done before Fedora 8 is released, but its starting to come together nicely. The forthcoming Fedora 8 release will again be leading the pack when it comes to open source virtualization management. </p>http://berrange.com/personal/diary/2007/08/fedora-8-virtualization-work-innoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-1393201641872951628Sun, 15 Jul 2007 22:24:00 +00002007-07-16T19:04:33.904Z<p> Last week, after many months development &amp; testing, we finally did a new release of <a href="http://libvirt.org/">libvirt</a> which includes secure remote management. Previously usage of libvirt was restricted to apps running on the machine being managed. When you are managing a large data center of machines requiring that an admin ssh into a machine to manage virtual machines is clearly sub-optimal. XenD has had the ability to talk to its HTTP service remotely for quite a while, but this used cleartext HTTP and had <strong>zero</strong> authentication until Xen 3.1.0. We could have worked on improving XenD, but it was more compelling to work on a solution that would apply to all virtualization platforms. Thus we designed &amp; implemented a small daemon for libvirt to expose the API to remote machines. The the communications can be run over a native SSL/TLS encrypted transport, or indirectly over an SSH tunnel. The former will offer a number of benefits in the long term - not least of which the ability to delegate management permissiosn per-VM and thus avoid the need to provide root access to virtual machine administrators. </p> <p> So how do you make use of this new remote management. Well, installing libvirt 0.3.0 is the first step. Out of the box, the SSL/TLS transport is not enabled since it requires x509 certificates to be created. There are <a href="http://libvirt.org/remote.html">docs about certificate creation/setup</a> so I won't repeat it here - don't be put off by any past experiance setting up SSL with Apache - its really not as complicated as it seems. The GNU TLS <code>certtool</code> also a much more user friendly tool than the horrific <code>openssl</code> command line. Once the daemon is running, then the only thing that changes is the URI you use to connect to libvirt. This is best illustrated by a couple of examples </p> <dl> <dt>Connecting to Xen locally <dd><pre> $ ssh root@pumpkin.virt.boston.redhat.com # virsh --connect xen:/// list --all Id Name State ---------------------------------- 0 Domain-0 running 6 rhel5fv blocked - hello shut off - rhel4x86_64 shut off - rhel5pv shut off </pre></dd> <dt>Connecting to Xen remotely using SSL/TLS <dd><pre> $ virsh --connect xen://pumpkin.virt.boston.redhat.com/ list --all Id Name State ---------------------------------- 0 Domain-0 running 6 rhel5fv blocked - hello shut off - rhel4x86_64 shut off - rhel5pv shut off </pre></dd> <dt>Connecting to Xen remotely using SSH <dd><pre> $ virsh --connect xen+ssh://root@pumpkin.virt.boston.redhat.com/ list --all Id Name State ---------------------------------- 0 Domain-0 running 6 rhel5fv blocked - hello shut off - rhel4x86_64 shut off - rhel5pv shut off </pre></dd> <dt>Connecting to QEMU/KVM locally <dd><pre> $ ssh root@celery.virt.boston.redhat.com # virsh --connect qemu:///system list --all Id Name State ---------------------------------- 1 kvm running - demo shut off - eek shut off - fc6qemu shut off - rhel4 shut off - wizz shut off </pre></dd> <dt>Connecting to QEMU/KVM remotely using SSL/TLS <dd><pre> $ virsh --connect qemu://celery.virt.boston.redhat.com/system list --all Id Name State ---------------------------------- 1 kvm running - demo shut off - eek shut off - fc6qemu shut off - rhel4 shut off - wizz shut off </pre></dd> <dt>Connecting to QEMU/KVM remotely using SSH <dd><pre> $ virsh --connect qemu+ssh://root@celery.virt.boston.redhat.com/system list --all Id Name State ---------------------------------- 1 kvm running - demo shut off - eek shut off - fc6qemu shut off - rhel4 shut off - wizz shut off </pre></dd> </dl> <p> Notice how the only thing that changes is the URI - the information returned is identical no matter how you connect to libvirt. So if you have an application using libvirt, all you need do is adapt your connect URIs to support remote access. BTW, a quick tip - if you get tired of typing --connect arg you can set the VIRSH_DEFAULT_CONNECT_URI environment variable instead. </p> <p> What about virt-install and virt-manager you might ask. Well there are slightly more complicated. During the creation of new virtual machines, both of them need to create files on the local disk (to act as virtual disks for the guest), possibly download kernel+initrd images for booting the installer, and enumerating network devices to setup networking. So while virt-manager can run remotely now - it will be restricted to monitoring existing VMs, and basic lifecycle management - it won't be possible to provision entirely new VMs remotely. Yet. Now the basic remote management is working, we're looking at APIs to satisfy storage management needs of virt-manager. For device enumeration we can add APIs which ask HAL questions and pass the info back to the client over our secure channel. Finally kernel+initrd downloading can be avoided with by PXE booting the guests. </p> <p> There's lots more to talk about, such as securing the VNC console with SSL/TLS, but I've not got time for that in this blog posting. Suffice to say, we're well on our way to our <a href="http://fedoraproject.org/wiki/Releases/FeatureVirtSecurity">Fedora 8 goals for secure remote management</a>. Fedora 8 will be the best platform for virtualization management by miles. </p>http://berrange.com/personal/diary/2007/07/libvirt-remote-management-newsnoreply@blogger.com (Daniel)tag:blogger.com,1999:blog-4121334.post-4866178555289477796Mon, 02 Jul 2007 00:51:00 +00002007-07-02T01:22:58.935Z<p> In the latter half of last year I was mulling over the idea of <a href="https://mail.gna.org/public/testautobuild-devel/2006-10/msg00000.html">writing SELinux policy for Test-AutoBuild</a>. I played around a little bit, but never got the time to really make a serious attempt at it. Before I go on, a brief re-cap on the motivation... </p> <p> <a href="http://autobuild.org/">Test-AutoBuild</a> is a framework for providing continous, unattended, automated software builds. Each run of the build engine checks the latest source out from CVS, calculates a build order based on module dependancies, builds each modules, and the publishes the results. The build engine typically runs under a dedicated system user account - <code>builder</code> - to avoid any risk of the module build process compromising a host (either accidentally, or delibrately). This works reasonably well if you are only protecting against accidental damage from a module build - eg building apps maintained inside your organization. If building code from source repositories out on the internet though there is a real risk of delibrately hostile module build processes. A module may be trojaned so that its build process attempts to scan your internal network, or it may trash the state files of the build engine itself - both the engine & the module being built are under the same user account. There is also the risk that the remote source control server has been trojaned to try and exploit flaws in the client. </p> <p> And so enter SELinux... The build engine is highly modular in structure, with different tasks in the build workflow being pretty well isolated. So the theory was that it ought to be possible to write SELinux policy to guarentee separation of the build engine, from the SCM tools doing source code checkout, from the module build processes, and other commands being run. As an example, within a build root there a handful of core directories </p> <pre> root | +- source-root - dir in which module source is checked out +- package-root - dir in which RPMs/Debs & other packages are generated +- install-root - virtual root dir for installing files in 'make install' +- build-archive - archive of previous successful module builds +- log-root - dir for creating log files of build process +- public_html - dir in which results are published </pre> <p> All these dirs are owned by the <code>builder</code> user account. The build engine itself provides all the adminsitrative tasks for the build workflow, so generally requires full access to all of these directories. The SCM tools, however, merely need to be able to check out files into the <code>source-root</code> and create logs in the <code>log-root</code>. The module build process needs to be able to read/write in the <code>source-root</code>, <code>package-root</code> and <code>install-root</code>, as well as creating logs in the <code>log-root</code>. So, given suitable SELinux policy it ought to be possible to lock down the access of the SCM tools and build process quite significantly. </p> <p> Now aside from writing the policy there are a couple of other small issues. The primary one is that the build engine has to run in a confined SELinux context, and has to be able to run SCM tools and build processes in a different context. For the former, I choose to create a 'auto-build-secure' command to augment the 'auto-build' command. This allows user to easily run the build process in SELinux enforced, or traditional unconfined modes. In the latter cases, most SELinux policy has automated process context transitions based on the binary file labels. This isn't soo useful for autobuild though, because the script we're running is being checked out direct from a SCM repo & thus not labelled. The solution for this is easily though - after fork()ing, but before exec()ing the SCM tools / build script we simply write the desired target context into /proc/self/attr/exec. </p> <p> So with a couple of tiny modifications to the build engine, and many hours of writing <a href="http://cvs.gna.org/cvsweb/testautobuild/conf/selinux/?cvsroot=testautobuild">suitable policy for Test-AutoBuild</a>, its now possible to run the build engine under a strictly confined policy. There is one horrible troublespot though. Every application has its own build process & set of operations is wishes to perform. Writing a policy which confines the build process as much as possible, while still keeping it secure is very hard indeed. In fact it is effectively unsolveable in the general case. </p> <p> So what to do ? SELinux booleans provide a way to toggle on/off various capabilities system wide. If building multiple applications though, it may be desirable to run some under a more confined policy than others - booleans are system wide. The solution I think is to define a set of perhaps 4 or 5 different execution contexts with differing levels of privileges. As an example, some contexts may allow outgoing network access, while others may deny all network activity. So the build admin can use the most restrictive policy by default, and a less restrictive policy for applications which are more trusted. </p> <p> This weekend was just the start of experimentation with SELinux policy in regards to <a href="http://autobuild.org">Test-AutoBuild</a>, but it was more far, far successful than I ever expected it to be. The level of control afforded by SELinux is awesome, and with the flexibility of modifying the application itself too, the possibilities for fine grained access control are enourmous. One idea I'd like to investigate is whether it is possible to define new SELinux execution contexts on-the-fly. eg, instead of all application sources being checked out under a single 'absource_t' file context, it would be desirable to create a new source file context per-applicaiton. I'm not sure whether SELinux supports this idea, but it is interesting to push the boundaries here nonetheless... </p>http://berrange.com/personal/diary/2007/07/security-enhanced-test-autobuildnoreply@blogger.com (Daniel)