From Fedora Project Wiki

< FWN
Revision as of 10:37, 14 April 2009 by Fab (talk | contribs) (added category)

Fedora Weekly News Issue 151

Welcome to Fedora Weekly News Issue 151 for the week ending November 9th, 2008.

http://fedoraproject.org/wiki/FWN/Issue151

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". Translation covers l10n work being done and SecurityAdvisories lists essential updates. 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[1].

FWN Editorial Team: Pascal Calarco, Oisin Feeley, Huzaifa Sidhpurwala

[1] http://fedoraproject.org/wiki/NewsProject/Join

Announcements

In this section, we cover announcements from the Fedora Project.

http://www.redhat.com/archives/fedora-announce-list/

http://www.redhat.com/archives/fedora-devel-announce/

Contributing Writer: Max Spevack

Fedora 11 Feature Process

John Poelstra is collecting[1] 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[2] has been created for this purpose.

[1] http://www.redhat.com/archives/fedora-devel-announce/2008-November/msg00003.html

[2] https://fedoraproject.org/wiki/Features/F11PolicyReview

Fedora 10 Preview Release

Jesse Keating announced[3] that the Preview Release of F10 (Cambridge) is available. "The Fedora Project is proud to announce the availability[4] 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."

[3] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00005.html

[4] https://fedoraproject.org/get-prerelease

Elections are coming

Matt Domsch announced[4] that nominations are open for the next round of Fedora elections[5]. 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)"

[4] http://www.redhat.com/archives/fedora-announce-list/2008-November/msg00006.html

[5] http://fedoraproject.org/wiki/Elections

Developments

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[1] discussion on why he had chosen not to open access (previously covered in FWN#148[2], FWN#136[3]) on some of his systems management software packages. His main reasoning was that obtaining provenpackager[4] 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 koan, cobbler, func and certmaster all of which could, if compromised, "[...] allow reprogramming of an entire datacenter in very easy steps."

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00382.html

[2] http://fedoraproject.org/wiki/FWN/Issue148#The_Big_ACL_Opening

[3] http://fedoraproject.org/wiki/FWN/Issue136#New_libraw1394_Rebuild_Exposes_Closed_ACLs

[4] 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[5] 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."

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00384.html

Daniel Berrange thought[6] 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[7] with a detailed reply which investigated the problems of non-responsiveness and trust which would be encountered by such a change. Michael Schwendt added[8] his experiences of the practical problems involving non-responsive maintainers and the difficulty of informing people without overloading them.

[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00387.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00392.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00405.html

Jesse Keating returned[9] 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.

[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00385.html

Tim Lauridsen wondered[10] 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[11] the last public information on the topic which was that anyone with commit access to the devel branch can submit updates.

[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00407.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00411.html

Who Moved My Bug ?

Debarshi Ray's question sounded[1] 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[2] 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[3] to the BugZappers wikipage. Bryn Reeves explained[4] how to see every change made to a bug. John Poelstra also suggested[5] 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 Fedora 10.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00273.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00274.html

[3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00279.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00290.html

It appeared[6] 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[7] about when this use of the ASSIGNED keyword had become standard and Dominik Mierzejewski argued[8] that it had not been approved by FESCo, but Brian Pepple posted the FESCo logs and Jesse Keating suggested[9] following the discussions on @fedora-devel. Dominik declined to rely on following such a high-volume list and Steve Grubb agreed[10].

[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00325.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00310.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00420.html

Kevin Kofler added[11] 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."

[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00283.html

HOWTO: Get an SELinux Policy Change

Jerry James requested[1] 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.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00259.html

Hans de Goede suggested[2] 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 chcon matchpathcon -n /usr/bin/gcl LOCALPATH/gcl.

[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00261.html

Jochen Schmitt suggested[3] that Jerry create a SELinux module to fix the issue and then actually did it himself and shared[4] it with the list, which impressed Jerry.

[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00289.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00294.html

The problem evolved[5] to be a little deeper than modifying the Makefile as Jerry explained[6]: "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[7] his previous matchpathcon suggestion and advised that this would be provided in selinux-policy-3.5.13-19.fc10.

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00307.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00350.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00367.html

Comps Czar Appointed to Encourage Modifications

An important decision made[1] by FESCo in its 2008-10-29 deliberations was to try and encourage further modification of comps.xml[2] 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[3] 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 [.]"

[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html

[2] 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

[3] 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[4] 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[5] 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."

[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00098.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00120.html

Seth Vidal and Toshio Kuratomi seemed[6] 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[7] 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..."

[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00134.html

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00107.html

Nicolas Mailhot listed[8][9] the advantages of the current format of comps as: human-editable, version-controllable, diff-able, grep-able, platform-agnostic and scalable. Toshio leaned[10] 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'")."

[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00108.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00158.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00122.html

In another post Nicolas raised[11] 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[12] 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[13] "[...] 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.

[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00125.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00165.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00226.html

Jeremy Katz wondered[14] 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[15] that using kickstart to install a minimal base and then the desired packages was the appropriate solution for the latter problem. He later explained[16] 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[17] 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."

[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00147.html

[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00148.html

[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00150.html

[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00152.html

LiveConnect Feature Approved for Fedora 10

FESCo's 2008-10-29 discussions[1] contained a decision to include the LiveConnect[2] feature in Fedora 10. LiveConnect is a way for web browsers to allow JavaScript and Java classes to call each other's methods. The project to develop a completely FLOSS implementation was initiated[3] by Tom Fitzsimmons and brought to completion by Deepak Bhole. Tom's work[4] on a rewrite of gcjwebplugin as an XPCOM plugin has been named IcedTeaPlugin and is the default in IcedTea6.

[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html

[2] http://fedoraproject.org/wiki/Features/Liveconnect

[3] http://people.redhat.com/fitzsim/fosdem-2008/fosdem-2008-liveconnect.pdf

[4] http://fitzsim.org/blog/?p=23

The practical implications for end users are that many popular sites[5][6] are now usable without the problems associated with the installation of Sun Microsystems' non-FLOSS Java plugin.

[5] http://www.jigzone.com/

[6] http://games.yahoo.com/

There was[7] 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."

[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00097.html

Artwork

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei

Echo Monthly News

Martin Sourada announced[1] on @fedora-art a new issue of the Echo Monthly News[2], 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

[1] https://www.redhat.com/archives/fedora-art-list/2008-November/msg00001.html

[2] https://fedorahosted.org/echo-icon-theme/wiki/MonthlyNews/Issue3

Maria's Awesome GIMP Videos

Mairin Duffy shared[1] with the rest of the Art Team her enthusiasm about the GIMP video tutorials[2] 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".

[1] https://www.redhat.com/archives/fedora-art-list/2008-November/msg00016.html

[2] http://www.youtube.com/profile?user=tatadbb&view=videos

Praise for the Solar Theme

Nicu Buculei forwarded[1] 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!'"

[1] https://www.redhat.com/archives/fedora-art-list/2008-November/msg00022.html

[2] http://arstechnica.com/journals/linux.ars/2008/11/06/fedora-10-preview-release-shines-like-a-star

[3] https://www.redhat.com/archives/fedora-art-list/2008-November/msg00025.html

The Desktop Beyond Fedora 10

Matthias Clasen posted[1] on @fedora-desktop a list of ideas[2] 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.'"

[1] https://www.redhat.com/archives/fedora-desktop-list/2008-November/msg00009.html

[2] https://fedoraproject.org/wiki/Desktop/Whiteboards


Virtualization

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[1] out his posting[2] to @cobbler list describing efforts to reconcile the XML formats used by virt-image and Cobbler[3].

[1] http://www.redhat.com/archives/et-mgmt-tools/2008-November/msg00013.html

[2] https://fedorahosted.org/pipermail/cobbler/2008-November/001346.html

[3] https://fedorahosted.org/cobbler/

Fedora Xen List

This section contains the discussion happening on the fedora-xen list.

libvirt Updates Unlikely for Fedora 8

Daniel Veillard began[1] by pointing out that libvirt 0.4.6 has been available[2] 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.

[1] http://www.redhat.com/archives/fedora-xen/2008-October/msg00014.html

[2] https://admin.fedoraproject.org/updates/F8/FEDORA-2008-8447

There was tepid support for an update. Daniel P. Berrange was convinced it would cause regressions and was firmly against[3] 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[4].

[3] http://www.redhat.com/archives/fedora-xen/2008-October/msg00017.html

[4] https://admin.fedoraproject.org/updates/F8/testing

Maxim Doucet noted[5] 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[6] 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."

[5] http://www.redhat.com/archives/fedora-xen/2008-October/msg00019.html

[6] http://www.redhat.com/archives/fedora-xen/2008-October/msg00020.html

Libvirt List

This section contains the discussion happening on the libvir-list.

Host Device Enumeration API Complete

David Lively completed[1] the host device enumeration API which enables querying of physical node hardware features. Also see coverage in FWN #146[2].

[1] http://www.redhat.com/archives/libvir-list/2008-October/msg00617.html

[2] http://fedoraproject.org/wiki/FWN/Issue146#Host_Device_Enumeration_API

Allow Arbitrary Paths to virStorageVolLookupByPath

Chris Lalancette reconciled[1] 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 oVirt.

[1] http://www.redhat.com/archives/libvir-list/2008-October/msg00762.html

Fully Modular Drivers and Optional dlopen Support

Daniel P. Berrange posted[1] 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."

[1] http://www.redhat.com/archives/libvir-list/2008-October/msg00718.html

OpenNebula Libvirt Implementation

Ruben S. Montero announced[1] a new implementation[2] of libvirt by way of the OpenNebula[3] project.

"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 any 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 OpenNebula will look for a suitable resource, transfer the VM images and boot your VM using any of the supported hypervisors."

[1] http://www.redhat.com/archives/libvir-list/2008-November/msg00004.html

[2] http://trac.opennebula.org/wiki/LibvirtOpenNebula

[3] http://www.opennebula.org

Having only just learned of OpenNebula, Daniel Veillard asked[4] "isn't OpenNebula in some way also an abstraction layer for the hypervisors, so in a sense a libvirt driver for OpenNebula is a bit 'redundant'?" Daniel also wondered if OpenNebula intended to submit patches to libvirt.

[4] http://www.redhat.com/archives/libvir-list/2008-November/msg00016.html

Ruben confirmed[5] intent to submit patches to libvirt and went on to further describe OpenNebula.

"The 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."

"For example, oVirt uses libvirt to interact with the physical nodes. With OpenNebula+libvirt, one of the nodes managed with oVirt could be a whole cluster."

[5] http://www.redhat.com/archives/libvir-list/2008-November/msg00020.html

This explaination led Daniel Veillard to the conclusion[6] 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 libvirt APIS..."

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 libvirt API."

[6] http://www.redhat.com/archives/libvir-list/2008-November/msg00025.html

Daniel P. Berrange was intrigued[7] 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."

[7] http://www.redhat.com/archives/libvir-list/2008-November/msg00029.html

Solaris Containers Support

Jovial asked[1] about support for Solaris Zones AKA Containers.

Daniel P. Berrange denied[2] knowledge of Solaris Zone support in libvirt, and went on to describe the state of support for other Solaris virtulization technologies[3].

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[4] at this time.

[1] http://www.redhat.com/archives/libvir-list/2008-November/msg00005.html

[2] http://www.redhat.com/archives/libvir-list/2008-November/msg00007.html

[3] http://www.sun.com/software/solaris/virtualization.jsp

[4] http://en.wikipedia.org/wiki/Sun_xVM

As to an LDoms patch submission, Ryan Scott from Sun replied[5] "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."

[5] http://www.redhat.com/archives/libvir-list/2008-November/msg00026.html

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.

Contributing to oVirt

Will Zhou asked[1] how to contribute to the oVirt project. Alan Pevec pointed[2] out the oVirt contribution page[3] and Richard Jone's page[4] 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/"


[1] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00358.html

[2] https://www.redhat.com/archives/ovirt-devel/2008-October/msg00359.html

[3] http://ovirt.org/contribute.html

[4] http://et.redhat.com/~rjones/how-to-supply-code-to-open-source-projects/

oVirt Console Conundrum

Richard W.M. Jones referred[1] to a previous discussion[2] 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-viewer from 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)."
  • Running virt-viewer or vinagre as 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 oVirt WUI to do authentication, get available consoles, and launch a Gtk-VNC widget with the appropriate tunnelling (openssh.exe based?).

[1] http://www.redhat.com/archives/ovirt-devel/2008-November/msg00040.html

[2] https://www.redhat.com/archives/ovirt-devel/2008-August/msg00004.html

Daniel P. Berrange liked[3] 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."

[3] http://www.redhat.com/archives/ovirt-devel/2008-November/msg00042.html

Translation

This section covers the news surrounding the Fedora Translation (L10n) Project.

http://fedoraproject.org/wiki/L10N

Contributing Writer: Runa Bhattacharjee

FLP Meeting held on 4th November 2008

The fortnightly meeting of the Fedora Translation Project was held on 4th November 2008 at 1900 UTC[1]. The important points of discussion were centered around the Fedora Release Notes and Installation Guide Translation for F10, approval of members into the cvsl10n group, FLSCo elections etc[2].

KarstenWade also suggested about introducing a level of completeness for the Fedora Release Notes that would allow individual teams some amount of flexibility while translating them.

DimitrisGlezos announced that the cvsl10n group has grown to 450 members last week.


[1] http://fedoraproject.org/wiki/L10N/Meetings#Next_Meeting:_Tuesday.2C_4_november_2008_19:00_or_20:00_UTC.3F

[2] http://www.redhat.com/archives/fedora-trans-list/2008-November/msg00016.html

FLSCo Elections to be held in December 2008

The Fedora Translation Project is gearing up for the next Fedora Localization Steering Committee (FLSCo) elections[3] to be held in December 2008. In these elections three new members would be elected to replace the bottom three seats from the last elections[4]. These seats are currently held by MarekMahut (Slovak Team), FabianAffolter (German Team) and Piotr Drag (Polish Team).

[3] http://fedoraproject.org/wiki/L10N/SteeringCommittee/Elections

[4] http://www.redhat.com/archives/fedora-trans-list/2008-April/msg00208.html

cvsl0n Approval Process

The current process of approving new members into the cvsl10n group is currently being discussed for enhancement[5]. Due to some recent problems related to submission of translations by unknown translators[6] and other problems related to translation submission, the request for a review of this process was raised again in the FLP meeting last week.


[5] http://www.redhat.com/archives/fedora-trans-list/2008-November/msg00017.html

[6] http://www.redhat.com/archives/fedora-trans-list/2008-November/msg00030.html

Request for frequent updates of the Status page

A new ticket[7] was filed by RunaBhattacharjee requesting to increase the frequency of updates of the Translation Status page[8] as translators rely heavily on these status pages while coordinating the translation work requirements.


[7] https://fedorahosted.org/fedora-infrastructure/ticket/963

[8] http://translate.fedoraproject.org

F10 Docs and Translation Schedule update

As part of the ongoing schedule finalization process for the Fedora Docs and Translation Project, JohnPoelstra has built a special report combining the Docs and Translation tasks into one schedule[9][10]. Further discussions are expected to continue as part of preparation for the F11 schedule.


[9] http://www.redhat.com/archives/fedora-trans-list/2008-November/msg00048.html

[10] http://poelstra.fedorapeople.org/schedules/f-10/f-10-docs-and-trans-tasks.html

F10 Docs Translation Update

The Release Notes package (release-notes, readme, readme-burning-isos, about-fedora, readme-live-image) translation deadline for F10 GA is unchanged at 13th November 2008[11]. In case of non-completion of the translations until that date, translations can be done until 21st November 2008 for the web version of the F10 Release Notes[12].

20 November 2008 is the deadline for translations of the Installation Guide[11].


[11] http://www.redhat.com/archives/fedora-trans-list/2008-November/msg00013.html

[12] http://www.redhat.com/archives/fedora-trans-list/2008-November/msg00044.html

Security Advisories

In this section, we cover Security Advisories from fedora-package-announce.

https://www.redhat.com/mailman/listinfo/fedora-package-announce

Contributing Writer: David Nalley

Fedora 9 Security Advisories

Fedora 8 Security Advisories

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Issue151&oldid=96786"