- 1 Fedora Weekly News Issue 151
- 1.1 Announcements
- 1.2 Developments
- 1.3 Artwork
- 1.4 Virtualization
- 1.4.1 Enterprise Management Tools List
- 1.4.2 Fedora Xen List
- 1.4.3 Libvirt List
- 1.4.4 oVirt Devel List
Fedora Weekly News Issue 151
Welcome to Fedora Weekly News Issue 151 for the week ending November 9th, 2008.
This week's action-packed Virtualization section investigates how the "OpenNebula Libvirt Implementation" could allow access to EC2 using libvirt APIs; Announcements announces "Elections Are Coming"; Developments peeks at the addition of LiveConnect to IcedTea; Artwork relays well-earned "Praise for the Solar Theme". As always there is much more worth reading in this issue.
If you are interested in contributing to Fedora Weekly News, please see our 'join' page.
In this section, we cover announcements from the Fedora Project.
Contributing Writer: Max Spevack
Fedora 11 Feature Process
John Poelstra is collecting feedback about the Fedora 10 feature process, which will be reviewed and discussed before the Fedora 11 process begins. "I would like to collect your constructive criticism and ideas for making the process better." A wiki page has been created for this purpose.
Fedora 10 Preview Release
Jesse Keating announced that the Preview Release of F10 (Cambridge) is available. "The Fedora Project is proud to announce the availability of the Fedora 10 Preview Release. The Fedora 10 Preview Release is our last pre-release offering before we let everyone taste the goods for real."
Elections are coming
Matt Domsch announced that nominations are open for the next round of Fedora elections. All the information you need for nominations and voting is in the links below.
"The following groups have elections in December 2008:
- Fedora Project Board
- Fedora Ambassadors Steering Committee (FAmSCo)
- Fedora Engineering Steering Committee (FESCo)
- Fedora Localization Steering Committee (FLSCo/Translators)"
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Security Exceptions to the Mass ACL Opening
MichaelDeHaan initiated discussion on why he had chosen not to open access (previously covered in FWN#148, FWN#136) on some of his systems management software packages. His main reasoning was that obtaining provenpackager status was too easy and could lead to at least two undesirable security outcomes: "(A) provenpackager decides to correct what he thinks is an rpmlint error and thus unintentionally breaks the security of the packaged application, (B) credentials of provenpackager are compromised allowing $evil to replace the contents of a said package. In either case, the change could either be making a new release of an application (which contains an exploit and/or unwitting bug), or updating the specfile in a way that breaks file permissions in a way that may not be immediately obvious (whether intentional or not)." The packages omitted by Michael were
certmaster all of which could, if compromised, "[...] allow reprogramming of an entire datacenter in very easy steps."
 After a flamewar (see FWN#148 "PackageGurus, SpecMentats or UeberPackagers?") the group name for packagers with access to any package in CVS is provenpackager: https://fedorahosted.org/packagedb/browser/fedora-packagedb-stable/ChangeLog#L45
Toshio Kuratomi shared Michael's concerns but pointed out that it would be possible to introduce compromised code into his packages' dependencies: "I'd like to mention, though, that func depends on the following packages with open acls: pyOpenSSL, python, python-simplejson So in terms of protecting against $EVIL, restricting provenpackager isn't very effective."
Daniel Berrange thought it would be more effective to have more co-maintainers: "The ideal should be for every package in the distro to have at least 1 extra comaintainer, or preferrably 3 or 4. People with a little domain knowledge for the package who can handle both the low-hanging fruit the main maintainer misses, with less risk of making mistakes due to lack of package specific knowledge." Toshio countered with a detailed reply which investigated the problems of non-responsiveness and trust which would be encountered by such a change. Michael Schwendt added his experiences of the practical problems involving non-responsive maintainers and the difficulty of informing people without overloading them.
Jesse Keating returned to the main topic and remarked that he agreed with Michael DeHaan's logic with regard to these specific packages but that membership of "provenpackagers" was now obtainable by requesting membership via the account system and approval of said request by a provenpackager. The requirement to have at least five packages was merely for initial seeding.
Tim Lauridsen wondered when co-maintainers would be enabled to submit updates to packages through
bodhi and subsequent discussion with Michael Schwendt suggested that it should be possible. Kevin Kofler had similar concerns and Michael shared the last public information on the topic which was that anyone with commit access to the devel branch can submit updates.
Who Moved My Bug ?
Debarshi Ray's question sounded alluringly like a parody of a self-help book but expressed genuine concern over why the status of bugs assigned to him were being changed. Till Maas reassured Debarshi that the status ASSIGNED means "that the bug has been triaged, i.e. it is assigned to the rigth component and all necessary information is provided. A member of the Fedora Triage Team probably did the changes to your bugs [,]" he included a useful link to the BugZappers wikipage. Bryn Reeves explained how to see every change made to a bug. John Poelstra also suggested using the "history" link and explained that the use of the "FutureFeature" keyword was to insure that bugs would continue to be given the version "rawhide" even after the GA release of
It appeared that this was a different process to that used to handle package review submissions and this had difference had caused some confusion. Confusion also reigned about when this use of the ASSIGNED keyword had become standard and Dominik Mierzejewski argued that it had not been approved by FESCo, but Brian Pepple posted the FESCo logs and Jesse Keating suggested following the discussions on @fedora-devel. Dominik declined to rely on following such a high-volume list and Steve Grubb agreed.
Kevin Kofler added some useful information for those working in teams: "[...] when you're actively working on fixing something (so you don't duplicate work in the team), you can use the ON_DEV status for that purpose."
HOWTO: Get an SELinux Policy Change
Jerry James requested information on how to get the correct security context in place for the
GCL binaries which he was packaging. He needed to know both whether it was acceptable to use a
chcon -t java_exec_t within the Makefile and how to have this reflected explicitly in Fedora policy.
Hans de Goede suggested filing a bug against
selinux-policy as Dan Walsh was "[...] usually very fast and correct in fixing issues like this one." Dan posted that Jerry could get the final destination of the file with a
matchpathcon -n /usr/bin/gcl LOCALPATH/gcl
Jochen Schmitt suggested that Jerry create a
SELinux module to fix the issue and then actually did it himself and shared it with the list, which impressed Jerry.
The problem evolved to be a little deeper than modifying the Makefile as Jerry explained: "I need a non-default security context for binaries that are both built and executed in the %build script, when the policy module has not yet been installed. It appears to me that there are only two ways to accomplish this: keep abusing java_exec_t like I have been, or get a GCL policy incorporated into selinux-policy* prior to building GCL. Am I wrong?" After Paul Howarth pointed out that
selinux-policy needed to provide a context type for
/usr/bin/gcl Dan modified his previous
matchpathcon suggestion and advised that this would be provided in
Comps Czar Appointed to Encourage Modifications
An important decision made by FESCo in its 2008-10-29 deliberations was to try and encourage further modification of
comps.xml by defining some clearer procedures. These included the appointment of Bill Nottingham as a "Grand Arbitrator of Comps" to decide which packages should be included in comps. The main concern expressed during the deliberation was that packagers tended not to modify comps and that awareness of its purpose had not been clearly communicated. It was hoped that extending the wiki page and making one person formally responsible would help. Currently there are filters in place and only those with uberpackager status can commit changes. Jesse Keating (f13) wanted to "[...] rather correct bad behavior than prevent good behavior [.]"
 Comps is an XML file which is used by anaconda (the installer) to present groups of available packages for selection by the administrator during the installation of a new operating system. See: https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
One worry was to ensure that not everything is added to comps as this would produce an unreadable, large list. This latter problem was foregrounded when Christopher Stone advocated that "[a]ll packages should go in comps. I don't know why notting is against this?!!? Why should my php-pear-* packages be excluded from comps for example? Just because some newb might not want to install them does not mean a php web developer would not use comps to install them." Matt Miller explained that the current scheme was inflexible: "If comps ends up with a thousand programs under Games and Entertainment, another thousand under Graphical Internet, etc., it's even more useless than having nothing in comps at all. What would be the point? On the other hand, having a thousand small comps groups is also no good."
Seth Vidal and Toshio Kuratomi seemed interested in the idea of allowing Flickr-like tagging of package as a replacement for the problem of assigning them to groups. Denis Leroy also suggested such a system: "Comps evolved over time into something that doesn't make a whole bunch of sense to me. Is the main use of comps still for installation groups within yum and anaconda ? A lot of packages are not installation "targets" but simply libraries that should only be installed by being pulled in from dependency resolution. Now if we're trying to "categorize" all packages nonetheless, it'd be better to have a tagbased system from packagedb, where packages can be "tagged" a-la-gmail, and also belong into multiple tag groups as some things really belong into multiple categories..."
Nicolas Mailhot listed the advantages of the current format of comps as: human-editable, version-controllable, diff-able, grep-able, platform-agnostic and scalable. Toshio leaned towards having tag information stored in
packagedb which could generate static "[...] separate files for the installer and general use (so that the installer isn't sprinkled with thousands of libraries but one could still use yum to search for "all packages that have a 'python' 'library' to do 'ssl'")."
In another post Nicolas raised another series of pertinent questions which included thinking about other repositories and alternate views of any data which might shoehorned into a particular model. Bill Nottingham wondered where Nicolas was going with all this and re-capped the current purpose of comps as both an input to a graphical package selector and an input to tree composition tools. The discussion with Bill revealed that Nicolas advocated "[...] just add everything in comps and run basic scripts that check every package we ship appears there (say in a dev-null group for libs or such stuff). You can easily cull the dev-null group at comps.xml.in -> comps.xml stage if needed" in order to ease the QA burden.
Jeremy Katz wondered who was the audience and task for Seth Vidal's "tree hierarchy plus tags" interface and distinguished between users looking for an application and administrators installing a system. Seth suggested that using kickstart to install a minimal base and then the desired packages was the appropriate solution for the latter problem. He later explained that having a tag-based presentation of the packages online would make it easier to determine which packages were available. Les Mikesell wished to reproduce specific machine configurations easily which led Seth to suggest using
yum-groups-manager to create a comps.xml file and then
createrepo -g that_comps.xml somedir which produces "[...] a repository that ONLY has comps.xml in it that is then instantly usable by any site which can get to the baseurl where it lives."
LiveConnect Feature Approved for Fedora 10
gcjwebplugin as an XPCOM plugin has been named
IcedTeaPlugin and is the default in
The practical implications for end users are that many popular sites are now usable without the problems associated with the installation of Sun Microsystems' non-FLOSS Java plugin.
There was some agonizing over the problem that
LiveConnect was being approved as a Feature post freeze date while other exciting projects had been dropped because they were not complete at that time. Brian Pepple worried: "Those folks we booted since they weren't complete would be justified in being pissed about us." Although this seemed to be a non-controversial opinion Deepak's work was also felt to be very important and fully tested. In addition Deepak submitted that "[...] no new packages introduced for this feature. Just an update to an existing package, that now installs a different Java plugin."
In this section, we cover the Fedora Artwork Project.
Contributing Writer: Nicu Buculei
Echo Monthly News
Martin Sourada announced on @fedora-art a new issue of the Echo Monthly News, a publication covering the development for the Echo icon set. This month it featured: new icons, new templates, Echo's withdrawal from Fedora 10 as a default theme, an icon check script and thoughts about the Echo's future
Maria's Awesome GIMP Videos
Mairin Duffy shared with the rest of the Art Team her enthusiasm about the GIMP video tutorials created by Maria Leandro, another member of the team "Hey, María shared these with us in #fedora-art today and I wanted to post them to the list so everyone could see".
Praise for the Solar Theme
Nicu Buculei forwarded to @fedora-art an article in praise of the default wallpaper theme in Fedora 10: "Here is what Ryan Paul from Ars Technica says about the Fedora 10 theme in a short article about the Preview Release: 'I was particularly impressed with the high quality of the new desktop wallpaper image, which comes from the Solar artwork theme. The whole user experience felt amazingly polished'", experience shared by Jayme Ayres "I showed Solar Theme and some works that the Artwork team has produced during Latinoware and ALL people were impressed with the high quality of the subject, this is a pride for the Artwork some people ask me 'Were we find that to download!? This is amazing!'"
The Desktop Beyond Fedora 10
Matthias Clasen posted on @fedora-desktop a list of ideas regarding the future of the Fedora desktop "Currently this is just a pretty unsorted mixture of wild ideas, implementation details and concrete plans, and a lot of them are missing details, user stories and use cases. Don't misunderstand it as 'the plan for the F11 desktop.'"
In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.
Contributing Writer: Dale Bewley
Enterprise Management Tools List
This section contains the discussion happening on the et-mgmt-tools list
Mapping virt-image XML to Cobbler
Bryan Kearney pointed out his posting to @cobbler list describing efforts to reconcile the XML formats used by
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
libvirt Updates Unlikely for Fedora 8
Daniel Veillard began by pointing out that
libvirt 0.4.6 has been available for some time, the
libvirt in Fedora 8 is ancient, and that Fedora 8 is nearing retirement. Daniel then asked for opinions about pushing out an update so late in the Fedora 8 life cycle.
There was tepid support for an update. Daniel P. Berrange was convinced it would cause regressions and was firmly against an update. He also suggested users build the new releases if they desire them. Daniel V. mentioned new releases could be built and left in updates-testing.
Maxim Doucet noted there will be no Xen dom0 support in any current Fedora release when F8 is retired, and asked if these test builds would be maintained after F8 reaches end of life. Daniel P. Berrange said F8 will be removed from the update system when it reaches end of life, and said "If you want a long term usable Xen host then for now CentOS or RHEL are the best options."
This section contains the discussion happening on the libvir-list.
Host Device Enumeration API Complete
David Lively completed the host device enumeration API which enables querying of physical node hardware features. Also see coverage in FWN #146.
Allow Arbitrary Paths to virStorageVolLookupByPath
Chris Lalancette reconciled device names used to track devices within a storage pool with the names returned by
virStorageVolLookupByPath. "Basically, it tries to convert whatever path it is given (say /dev/sdc) into the form currently used by the Pool (say /dev/disk/by-id). It then goes and looks up the form in the pool, and returns the storageVolume object as appropriate." This change augments scanning for LVM devices in
Fully Modular Drivers and Optional dlopen Support
Daniel P. Berrange posted a set of 10 patches which "clean up our internal modularization to remove unneccessary dependancies between source files, and make everything follow a consistent pattern of XXXX.h declaring stuff in XXXX.c. Later in the series is plays some games with the linker scripts, and finally makes all hypervisor drivers fully modular, and optionally dlopen'able."
OpenNebula Libvirt Implementation
Ruben S. Montero announced a new implementation of
libvirt by way of the
"The implementation of
libvirt on top of a
distributed VM manager, like
OpenNebula, provides an abstraction of a whole
cluster of resources (each one with its hypervisor). In this way, you can use
libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a
distributed level. "
"For example, you may create a new domain with 'virsh create', then
will look for a suitable resource, transfer the VM images and boot your VM
using any of the supported hypervisors."
Having only just learned of
OpenNebula, Daniel Veillard asked
OpenNebula in some way also an abstraction layer for the hypervisors, so in a
libvirt driver for
OpenNebula is a bit 'redundant'?"
Daniel also wondered if
OpenNebula intended to submit patches to
Ruben confirmed intent to submit patches to
libvirt and went on to further
libvirt API is just another interface to the
OpenNebula system" which "provides an abstraction layer for A SET of distributed resources (like Platform VM Orchestrator or VMWare DRS). In this way,
OpenNebula leverages the functionality provided by the underlying VM hypervisors to provide a centralized management (allocation and re/allocation of VMs, balance of workload....) of a pool physical resources."
libvirt to interact with the physical nodes. With
libvirt, one of the nodes managed with
oVirt could be a whole cluster."
This explaination led Daniel Veillard to the conclusion that this is "the reverse appraoch from
oVirt, where we use
libvirt to build the distributed management. One interesting point is that your driver would allow to access EC2 using
And, referring to the
oVirt example, added "This is a bit against the Node principle of
libvirt, and could result in some fun in the hardware discovery mode, but in general the approach might work. Still we are looking at bits on the node to provide capabilities of the hypervisor, which may break in your case, and migration is defined as an operation between a domain in a given node and a connection to another node, so the migration within the
OpenNebula cluster won't be expressable in a simple way with the normal
Daniel P. Berrange was intrigued by this problem. "We might like to extend the node capabilities XML to provide information about the cluster as a whole - we currently have <guest> element describing what guest virt types are supported by a HV connection, and a <host> element describing a little about the host running the HV. It might make sense to say that the <host> info is optional and in its place provide some kind of 'cluster' / 'host group' information."
Solaris Containers Support
Jovial asked about support for Solaris Zones AKA Containers.
Daniel P. Berrange denied knowledge of Solaris Zone support in
libvirt, and went on to describe the state of support for other Solaris virtulization technologies.
Sun forked an older
libvirt release, and added LDoms support. "Hopefully they'll find the time to re-submit the driver for inclusion in main libvirt codebase again in the future." "There has been work in official [libvirt] releases to support Xen dom0 on Open Solaris, but I think there are still some outstanding patches in the Open Solaris repositories that aren't in our offcial releases." There is also no
support for Sun
xVM at this time.
As to an LDoms patch submission, Ryan Scott from Sun replied "it's a case of too much to do and not enough time. The LDoms port is currently on hold." Ryan also added, the Open Solaris Xen dom0 work is "temporarily stuck on 0.4.0 for the time being, which makes forwarding-porting patches difficult. I hope to update our internal gate to 0.4.6 within a month, which will allow me to send out some patches." and finally "I would like to port libvirt to Zones, but it looks unlikely that I'll have the time to do so."
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.
Will Zhou asked how to contribute to the
oVirt project. Alan Pevec pointed out the
oVirt contribution page and Richard Jone's page on contributing to open source projects, and described the process as "basically, follow http://ovirt.org/build-instructions.html and checkout 'next' branch from git repositories and send patches to the ovirt-devel list.
Create your local git branch and rebase it to 'next' before sending patches with git-send-email.
For Git Crash Courses see http://git.or.cz/"
oVirt Console Conundrum
Richard W.M. Jones referred to a previous discussion on adding guest console access to the Web User Interface while including Windows support. Richard enumerated the options explored thus far:
- A Gtk-based VNC browser plugin. "Unfortunately we couldn't make this stable enough for real production use."
- Launching an external program such as
virt-viewerfrom a browser plugin. "This works, but it's a security issue, and we can't use a Gtk dialog to get around the warning issue because of (1)."
vinagreas separate, standalone programs. "This works, but requires the user to type in some very long and complicated command line by hand, and there are unresolved authentication problems."
Richared then listed a new fourth option:
- Write a custom C/Gtk/Gtk-VNC Windows program which contacts the
oVirtWUI to do authentication, get available consoles, and launch a Gtk-VNC widget with the appropriate tunnelling (
Daniel P. Berrange liked option four: "This is actually quite a good idea - a oVirt thin client desktop [...] Basically this is kind of a cross of virt-viewer + vinagre, but talking to oVirt instead of libvirt. Or you could write a libvirt driver that talks to oVirt - cf the OpenNebula guys."