Fedora Weekly News #151
Oisin Feeley
oisinfeeley at imapmail.org
Mon Nov 10 12:04:39 UTC 2008
Fedora Weekly News Issue 151
1.1 Announcements
1.1.1 Fedora 11 Feature Process
1.1.2 Fedora 10 Preview Release
1.1.3 Elections are coming
1.2 Developments
1.2.1 Security Exceptions to the Mass ACL Opening
1.2.2 Who Moved My Bug ?
1.2.3 HOWTO: Get an SELinux Policy Change
1.2.4 Comps Czar Appointed to Encourage Modifications
1.2.5 LiveConnect Feature Approved for Fedora 10
1.3 Artwork
1.3.1 Echo Monthly News
1.3.2 Maria's Awesome GIMP Videos
1.3.3 Praise for the Solar Theme
1.3.4 The Desktop Beyond Fedora 10
1.4 Virtualization
1.4.1 Enterprise Management Tools List
1.4.1.1 Mapping virt-image XML to Cobbler
1.4.2 Fedora Xen List
1.4.2.1 libvirt Updates Unlikely for Fedora 8
1.4.3 Libvirt List
1.4.3.1 Host Device Enumeration API Complete
1.4.3.2 Allow Arbitrary Paths to
virStorageVolLookupByPath
1.4.3.3 Fully Modular Drivers and Optional dlopen
Support
1.4.3.4 OpenNebula Libvirt Implementation
1.4.3.5 Solaris Containers Support
1.4.4 oVirt Devel List
1.4.4.1 Contributing to oVirt
1.4.4.2 oVirt Console Conundrum
1.5 Translation
1.5.1 FLP Meeting held on 4th November 2008
1.5.2 FLSCo Elections to be held in December 2008
1.5.3 cvsl0n Approval Process
1.5.4 Request for frequent updates of the Status page
1.5.5 F10 Docs and Translation Schedule update
1.5.6 F10 Docs Translation Update
1.6 Security Advisories
1.6.1 Fedora 9 Security Advisories
1.6.2 Fedora 8 Security Advisories
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."
Richard 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]. The 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 ===
* net-snmp-5.4.1-19.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00033.html
* enscript-1.6.4-10.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00040.html
* uw-imap-2007d-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00082.html
* php-Smarty-2.6.20-2.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00117.html
* ipsec-tools-0.7.1-5.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00129.html
* wordpress-2.6.3-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00154.html
* rgmanager-2.03.09-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00163.html
* gfs2-utils-2.03.09-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00164.html
* cman-2.03.09-1.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00165.html
* drupal-cck-6.x.2.0-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00178.html
* moodle-1.9.3-3.fc9 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00205.html
=== Fedora 8 Security Advisories ===
* enscript-1.6.4-9.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00014.html
* net-snmp-5.4.1-8.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00021.html
* ktorrent-2.2.7-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00054.html
* uw-imap-2007d-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00058.html
* php-Smarty-2.6.20-2.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00093.html
* wordpress-2.6.3-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00116.html
* ipsec-tools-0.7.1-5.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00190.html
* moodle-1.8.7-1.fc8 -
https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00199.html
--
Oisin Feeley
http://fedoraproject.org/wiki/OisinFeeley
More information about the fedora-announce-list
mailing list