Fedora Weekly News 141

[Huzaifa Sidhpurwala]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fedora Weekly News Issue 141
==============================

Welcome to Fedora Weekly News Issue 141 for the week ending August 30, 2008.

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

Fedora Weekly News keeps you updated with the latest issues, events and
activities in the Fedora community.

If you are interested in contributing to Fedora Weekly News, please see
our 'join' page. Being a Fedora Weekly News beat writer gives you a
chance to work on one of our community's most important sources of news.
Ideas for new beats are always welcome -- let us know how you'd like to
contribute.

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 Unity releases Fedora 8 Re-Spin

Ben Williams announced[0] that the Fedora Unity team has released a new
re-spin of Fedora 8. "These Re-Spin ISOs are based on the officially
released Fedora 8 installation media and include all updates released as
of August 14th, 2008. The ISO images are available for i386, x86_64 and
PPC architectures via Jigdo and Torrent starting Sunday August 24th,
2008. Go to http://spins.fedoraunity.org/spins to get the bits!"

[0]
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00014....

= Planet Fedora =

In this section, we cover the highlights of Planet Fedora - an
aggregation of blogs from Fedora contributors worldwide.

http://planet.fedoraproject.org

Contributing Writer: Max Spevack

Education

The Fedora Education Spin is progressing[0], having been "approved by
all necessary bodies - Spin SIG, Board, Rel-Eng", reported Sebastian
Dziallas. The spin has its own feature page. "Hopefully, we'll be able
to have a preview of the spin ready in the next weeks", added Sebastian.

[0]
http://sdziallas.joyeurs.com/blog/2008/08/status-report-on-fedora-educat....

Greg DeKoenigsberg reminded potential OLPC contributors[1] to surf over
to the contributors' program on the OLPC wiki in order to request their
own XO for development. Soon, Greg "will be sitting in on the weekly
call that decides how these laptops are disbursed".

[1] http://gregdek.livejournal.com/34240.html

Tech Tidbits

Michael DeHaan, holder of the coveted "best blogger on Planet Fedora"
title, as determined each week by your correspondent, has penned a
treatise[8] concerning the future of systems management software.
"Cobbler and Func are very fun, I think they are quite useful, but I'm
wondering what are next on the horizon for server management tech, not
in terms of a evolutionary improvement but how things can be
legitimately improved by fundamental, indeed 'paradigm-shifty' means."
Click the link below to read the entire post.

[8] http://www.michaeldehaan.net/?p=702

James Antill has written[9] a tutorial on the Python yum API, which is
incredibly useful if you have ever wanted to do stuff with yum, but
don't know where to start and are afraid to ask Seth.

[9] http://illiterat.livejournal.com/6254.html

Events

David Nalley shared some details about the upcoming Fedora Ambassadors
Day for North America[2]. The event will coincide with Ohio Linux Fest
in October. David said, "If you are a Fedora Ambassador, or want to be
one, you should try and attend."

[2] http://www.nalley.sc/david/?p=81

[[ChristophWickert|Christoph Wickert] attended FrOSCon 2008, along with
several other other Ambassadors, and shared his event report[3]. "Just
like on Linuxtag the Fedora booth was located close to the entrance, so
we had quite a lot of visitors. Unfortunately the booth was a little
small and we had lot of stuff to show: Two OLPCs, an eeepc, two ALIX
Machines and a couple of Laptops. Everything was running Fedora, the
Laptops were running Gnome and Xfce, mine also LXDE." Check out the link
below for pictures, and the full report.

[3] http://www.christoph-wickert.de/blog/2008/08/26/back-from-froscon/

Max Spevack reminded[4] everyone about the upcoming FUDCon Brno. "We
currently have 110 people registered for the event," and the list of
sessions and hackfests is on the Fedora wiki. Hans de Goede will be
attending FUDCon Brno. He wrote an update[5] about webcam support in
Fedora, which will be worked on at FUDCon, and also blogged[6] about the
session he will give on how to become a Fedora package maintainer.

[4] http://spevack.livejournal.com/62369.html

[5] http://hansdegoede.livejournal.com/5576.html

[6] http://hansdegoede.livejournal.com/5304.html

Fedora List

Fedora Board member Chris Tyler wrote[7] about the plans for changing
the scope and ownership of fedora-list. Chris says, it is "one of the
first lists that most Fedora users join, and therefore quite important
to the community. However, it's a high-volume list (and is sometimes
perceived to have a high noise level), so many veterans of the Fedora
community aren't subscribed... Paul Frields and I have taken on the
ownership of the list, and we'd welcome one or two experienced members
of the community to join us."

[7]
http://blog.chris.tylers.info/index.php?/archives/134-The-Scope-and-Owner...

= Developments =

In this section the people, personalities and debates on the
@fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley
Approaches to a Minimal Fedora

Luya Tshimbalanga alerted[1] the list to a post on FedoraForum.org in
which a user "stevea" had produced a 67MB "minimalFedora" system.
Jeff
Spaleta worried[2] that the bare-bones system was unable to receive
updates and that this was something which "we as a project might not
officially want to endorse." One way out of that suggested by Jef was
that interested parties could produce a derived distribution which
pushed out entire updated images. Recent changes in the trademark
guidelines make such a move easier.

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

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

A parallel to the minimal OS appliance image used in the oVirt project
was discerned[3] by Daniel Berrange. Daniel reported their 'oVirt
managed node' as being less than 64MB and built entirely from the Fedora
9 repositories. Later Daniel posted[4] that the similarities ended with
the desire for a small image. The oVirt goal was to use only Fedora as
upstream whereas stevea's approach had been to substitute coreutils with
busybox. Daniel acknowledged "[...] finding the bits which aren't needed
is fun in itself & somewhat of a moving target. So wherever possible
we've been filing BZ to get some RPMs split up into finer grained
sub-RPMs" and included a link to his project's kickstart %post stanza.
Richard Jones suggested[5] that KDE's filelight was useful for finding
bloated files and Vasile Gaburici added[6] that there was a GNOME
equivalent called baobab. Vasile also included[7] a script which he uses
to "keep track of bloatware".

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

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

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

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

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

A follow-up post from Daniel concluded[8] that the only bits of upstream
Fedora actually used in stevea's approach were the kernel and busybox as
even glibc and initscripts had been ditched. Daniel wondered "So not
really much trace of Fedora left at all. Not sure why you'd go to the
trouble of doing the initial anaconda install at that point - might as
well just 'rpm *no-deps' install kernel + busybox RPMs into a chroot &
add the custom init script."

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

Doubt on the advantages of stripping down Fedora to make it run on
embedded targets was cast[9] by Patrice Kadionik when he argued that
using the Fedora kernel with all its patches and modules was too
bloated. Instead he preferred to use the vanilla kernel with busybox
with the result that "[...] you have a Linux kernel (about 1MB) with its
root [filesystem] (about 1-2 MB) adapted completely to the target
platform." Alan Cox replied[10] that the ability to receive updates and
benefit from the maintained and tested code was desirable if there were
enough extra space.

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

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

W. Michael Petullo added a link[11] to his "FedoraNano" project which
has the goal of reducing redundancies, identifying probable cases for
sub-packaging and documenting a method to install a small Fedora onto
solid state drives.

[11] http://www.flyn.org/fedoranano/fedoranano.html


Using PackageKit Without NetworkManager-Controlled Interfaces

A question from Martin Langhoff asked[1]: "[i]s there anything
preventing PK from connecting to the network over
non-[NetworkManager]-controlled network interfaces?" This question
appeared to be predicated on the assumption that PackageKit had a
dependency on NetworkManager.

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

Jeremy Katz clarified[2] that PackageKit depended on NetworkManager-glib
and not on NetworkManager. He added that this was because PackageKit
attempted to determine the status of the network connection prior to
checking for updates. Dan Williams confirmed[3] that this was the case
and expanded on the explanation: "If talking to NM fails, the app should
either (a) assume a connection, or (b) could be more intelligent by
asking SIOCGIFCONF/netlink for interfaces, and if at least one interface
is IFF_UP | IFF_RUNNING and has an IP address, then try." Using
NetworkManager in this way allows PackageKit to be restricted to
sensible choices about the type of networks over which it is acceptable
to receive updates.

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

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

A further point raised by Martin was that there were a surprising number
of dependencies and Dan pointed[4] to bugzilla entry#351101[5] while
noting that "[PackageKit] should only depend on NetworkManager-glib,
which itself should not pull in NetworkManager in the future." That bug
specifically affects multilib systems, that is x86-64 systems with i386
packages on them, and prevents the simple removal of the older version
of NetworkManager-glib and replacement with a re-factored one. This will
be fixed for Fedora 10 using the installer anaconda.

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

[5] https://bugzilla.redhat.com/show.bug.cgi?id=351101

In a separate thread Martin asked[6] what debugging facilities were
available for network scripts beyond using bash -x. He detailed his
"hack du jour" by which /etc/udev/rules.d/60-net.rules invokes
net.hotplug.debugger which in turn uses bash -x net.hotplug with STDIN
and STDOUT redirected to a logfile. It appeared from the lack of further
suggestions that this is a good strategy. He also provided[7] a note
which explained that he was upgrading the "School Server" spin to Fedora
9 from Fedora 7.

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

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01207.html
Git-1.6.0 Commands to be Moved Out of PATH

A response by Todd Zullinger to a "cvsextras" commit[1] of changes to
git questioned[2] whether setting gitexecdir=%{_bindir} was a justified
deviation from upstream intent. According to Todd "[..] we've
effectively negated upstream's intent to present less binaries in the
users path". Currently there are 137 git-commands in the /usr/bin
directory. Todd suggested that it was better that individual users added
the output of $(git *exec-path) to their PATH environment variable. As a
precaution against breaking scripts upon update to git-1.6.0 Todd
suggested that this addition to PATH should be made by the package.

[1]
http://www.redhat.com/archives/fedora-extras-commits/2008-August/msg05593...

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

The package maintainer responsible for the change, James Bowes
replied[3] that he had recently attempted to do as Todd suggested and
that had resulted in complaints. He was worried that although Todd's
change made sense there had been no due diligence conducted to see what
would break if the git-* commands were moved in such a way. Josh Boyer
replied[4] that the original complaint had been about "yank[ing] out
commands [...] from a stable release [Fedora 9]". Todd Zullinger
discounted such complaints and dreamt[5] that "[...] a warning could be
hand delivered by a beautiful naked person of whatever gender the user
prefers and many would still scream when the change finally landed. :)"
He suggested that in order to achieve predictability and consistency
across distributions it was best to follow upstream and use the update
to 1.6.0 as a flag day.

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

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

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

In response to queries as to whether there was a need to update Fedora 9
also Josh Boyer replied[6] that a security bug was fixed by git-1.6.0
but that he thought that this might have also been fixed by "a later
release of 1.5.6.x."

[6]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01390.html
Resurrecting Multi-Key Signatures in RPM

Spurred on by the disquiet caused by the recent signing of Red Hat
packages (but not as far as is known any Fedora packages)[1] it was
suggested[2] by Bojan Smojver that multiple GPG signatures of RPM
packages would be a good idea. Distributing the signing could include
using alternate buildsystems "[...] with no public access [...] to
verify package checks before signing[.]"

[1]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012...

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

Andrew Bartlett thought that the checksum part would be a problem
because a build often includes hosts, build times and other specifics
and Chris Adams added[3] that even individual files within a package had
such information embedded. Bojan decided to find out how many packages
were so constrained and Seth Vidal suggested[4] a useful rpm command rpm
- -qp *dump pkg.rpm to list all available information about each package.

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

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

Seth was dubious about the general idea and upon being pressed doubted
the security gain and noted the cost incurred on users trying to verify
that a package was signed correctly. Bojan expanded[5] upon the idea
that for a "[...] multi-key, multi-build system, an attacker would need
to get his hands on a lot of private key passwords, break multiple
independent build systems [...] It is similar to what a reporter does to
confirm a story. One source, not so reliable. Two sources, more
reliable. Many sources, most likely reliable." Stephen Smoogen
described[6] this a logical fallacy and argued that due to the number of
packages all signing would need to be automated and thus probably each
of the multiple sources would "[...] get their information from the same
top level source."

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

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

A useful post by Nils Philippsen laid out[7] four practical objections.
Prime among these was that there were additional pieces of data, besides
those mentioned above, embedded in a specific build even though the
source package may have the same tag. The possibility of making the
build system vulnerable to a DoS attack was also mentioned. A sub-thread
on German banking practices and the value of multiple credentials
developed[8] as did one[9] on the problems of determinism in producing
identical binaries.

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

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

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

Tom Lane was also among those that expressed[10] a general skepticism
that the increased burden of such a scheme was realistic: "Most of us
[packagers] are overworked already. We aren't going to jump through any
hoops for third-party signatories." Bojan argued[11] that if the system
were automated then it probably would be vulnerable but suggested that
it would be better if a community effort to absorb the extra
non-automatic work would be a solution in line with "open source"
practices. Reluctantly he concluded "[n]ever mind, it was just an idea.
Probably not even a good one. Back to the drawing board... ;-)"

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

[11]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01215.html
Intrusion Recovery Slow and Steady

A politely phrased request[1] was made on 25-08-2008 by Mike Chambers
for information about when normal service would resume in the Fedora
Project after the disruptions[1a]. Enigmatically Dominik 'Rathann'
Mierzejewski observed[2] that there had been "some speculation on
fedora-advisory-board that might explain the information blackout, so
please don't jump to conclusions until you really know what happened"
This led Chris Adams to observe that the list archives appeared to be
offline and to restate the request for information "[...] in the absence
of information, rumors and speculation fill the gap (which is not good)."

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

[1a]
https://fedoraproject.org/wiki/FWN/Issue140#Mysterious_Fedora_Compromise

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

Several days later (on 28-08-2008) a similar request was made[3] by Alan
Dunn. He wondered whether bodhi was pushing updates out again, and Josh
Boyer responded[4] that planning and implementation of "how to revoke
the current gpg key used to sign RPMs" were in progress. Jesse Keating
cautioned[5] that the migration to a new key would be slow "I'm
currently re-signing all of the 8 and 9 content with these new keys so
that we can make them available along with the new updates with the new
key for these product lines. This is going to take some time due to the
nature of how our signing works."

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

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

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

A proposal mooted[6] on @rel-eng by Warren Togami and others provided
some insight into at least the part of the plans that involve the
problem of how to distribute a new package signing key.

[6] http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html

"nodata" asked[7] whether the new plans included a means to push out
critical security updates even while there was a general outage. The
thinking behind this seems to be that an attacker could decide to knock
out Fedora infrastructure in order to gain some time to exploit a known
vulnerability even if a simple fix existed. Jesse Keating replied[8]
confidently that in such a scenario the Fedora Project would do
"whatever it takes [...] to get a critical update onto a public
webserver should the need arise" and cautioned against wasting time
trying to plan for every possible scenario. Toshio Kuratomi added[9]
that although it might be possible to speed up recovery "[...]
unfortunately if the infrastructure problem is bad enough, there's no
way we can push package X out until the problem is at least partially
resolved."

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

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

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

On 27-08-2008 Paul Johnson noted that it was possible to "compose and
build" and asked "when will updates via yum become available for
rawhide?" Jeremy Katz responded[10] that "[a]t the moment, the compose
is falling over for new reasons unrelated to the infrastructure changes.
Hopefully we'll see a rawhide make its way out to the masses real soon now."

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

Later Mike Chambers and Ola Thoresen reported[11] that updating from
Fedora 9 to Rawhide seemed to be working. Several Rawhide Reports also
appeared[12].

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

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

= Infrastructure =

This section contains the discussion happening on the
fedora-infrastructure-list

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: HuzaifaSidhpurwala
Some noteworty praise

Paul W. Frields writes for fedora-infrastructure-list [1]

Paul forwarded a mail [2] send by Tim Burke, who is the Director of
Linux Development inside Red Hat, praising the efforts of fedorans who
rose to the occasion to bring things back on track after the recent
incidents in Fedora infrastructure.

[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...

[2]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01023.html
Maintaining a partial cvs workarea

Axel Thimm writes for fedora-infrastructure-list [3]

Axel described how he was keeping a partial check-out of packages, ie
the ones which he was maintaining. Now he would like to be able to cvs
up and have all updates flow in, but if he does do so cvs will want to
get all other thousand packages in. He is currently using a for loop
with pushd/popd, but this process is extremely slow. Axel asked if there
was a better way of doing this?

[3]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...
rawhide, /mnt/koji and /pub/fedora

Jesse Keating writes for fedora-infrastructure-list [4]

Jesse created a user "masher" to have the ability to write to
/mnt/koji/mash/ but not any of the other koji space. This is useful to
prevent too much damage from a horribly wrong rawhide compose. To make
things easier in the rawhide compose configs, they decided to run the
cron/scripts as the masher user. This is also good because it means
things run unprivileged. However he ran into a snag. They have another
user, 'ftpsync' that has write access to /pub/fedora/. Previously the
rawhide script was ran as root, and thus it was no problem to su ftpsync
for the rsync calls. The masher user does not possess the capability of
doing this.


[4]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...
New Key Repo Locations

Warren Togami writes for fedora-infrastructure-list [5]

Warren proposed the latest draft of New Key repo locations. Jesse
Keating points out that the deep levels are necessary because mirrors
exclude releases by directory name like "9/"

[5]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...

= Artwork =

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei
The Echo icon theme and Fedora 10

NicuBuculei asked[1] on @fedora-art about the plans to use the new Echo
icon set as a default on Fedora 10: "considering the feature freeze, the
Beta release and as Echo is not a feature proposed for F10, is correct
the assumption that we won't have Echo as a default for F10, staying
with Mist [at least] one more release cycle?"

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

In reply LuyaTshimbalanga pointed[2] out that it is still possible, due
to a slip in the release cycle: "Shall we try to make it as Fedora 10
feature. Thanks to, in some extend, the incident, feature freeze has
been moved on September 9th."

[2]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00329.html

MartinSourada shared[3] his experience "It seems like artwork things are
preferred to be decided by the Art Team rather than Fesco. I have a
feeling it might be same for Echo." and proposed that this decision
should be made together by the Art and Desktop teams "In this case I
personally think Echo should be put on evaluation by Art Team and
Desktop Team. If both agree it's ready for default we can roll it in
;-)" while NicuBuculei stressed[4] the importance of having Art features
listed "from a marketing POV, if we list it as a "feature" it will be
picked by more news source and help building the excitement around the
new release."

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

[4]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00343.html
Automating the One Canvas workflow

In the last FWN[1] issue we covered 'One Canvas workflow', an innovative
way to create icons, this week it continued to be a topic on @fedora-art
and MartinSourada introduced[2][3] a script that makes the work easier.
"[It] greatly simplifies life for Echo artist, since all they need is to
make the Source SVG, run the script on it, select which branches they'd
like to push it to and write commit message(s) - i.e. it automates most
of the process". He also wrote a blog post[4] about this and created a
screencast[5] illustrating the process.

[1] http://fedoraproject.org/wiki/FWN/Issue140

[2]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00327.html

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

[4]
http://mso-chronicles.blogspot.com/2008/08/echo-nodoka-one-canvas-ruby-an...

[5] http://mso.fedorapeople.org/screencasts/echo-add-icon-screencast.ogg

= 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

As there have been disruptions to the infrastructure of the Fedora
Project this week there are no Security Advisories to report. Please see
the Announcements and Development sections for more information.
Fedora 9 Security Advisories

None
Fedora 8 Security Advisories

None

= 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
Fedora Xen List

This section contains the discussion happening on the fedora-xen list.
virt-what Script Detects Running in a Virtual Machine

Richard W.M. Jones announced[1] version 1.0 of | virt-what which is a
simple shell script that detects if you are running inside a virtual
machine, and prints some "facts" about that virtual machine.

[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00039.html
Xen 3.3.0 Released

Pasi Kärkkäinen forwarded[1] from xen-devel an announcement of Xen
3.3.0. Pasi also followed up[2] on a thread from July where Daniel P.
Berrange said about Fedora 10, "Even though we don't have any Dom0 I'll
update it to 3.3.0 for the xen RPM and hypervisor. This will at least
let people build their own legacy Xen kernel from upstream's 2.6.18 xen
kernel"

[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00038.html

[2] https://www.redhat.com/archives/fedora-xen/2008-August/msg00029.html
Testing LiveCD Distros as DomU Guests

jean-Noël Chardron posted[1] a howto for testing live cd images by
booting them in a DomU with virt-install.

[1] https://www.redhat.com/archives/fedora-xen/2008-August/msg00024.html
Libvirt List

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

Daniel P. Berrange posted[1] a todo list for libvirt which was the
product of a brainstorming session at Red Hat. Daniel offered this list
as a good starting point for those wishing to assist in the development
of libvirt.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00718.html
Live Migration Sanity Checks

Chris Lalancette described[1] a feature that oVirt would like to see.
The feature would be a set of sanity checks a caller could make to
determine if live migration of a given virtual machine would be likely
to succeed.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00757.html
sVirt: XML Representation of Security Labels

James Morris continued[1] work on the sVirt project by investigating how
and when to label the resources accessed by domains and proposed an XML
representation of these labels.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00740.html
LXC: Making the Private Root Filesystem More Secure

After committing the private root filesystem code for LXC Daniel P.
Berrange noted[1] that cgroups supports device ACLs which could defend
against 'mknod' escapes into the host OS devices.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00734.html
Exposing Unique Hypervisor Features

Nguyen Anh Quynh asked[1] how libvirt can expose the unique features of
a given hypervisor such as the monitor interface of Qemu. Daniel P.
Berrange responded[2] by stating the policy for adding new APIs to
libvirt is that the conceptual representation has to be applicable to
multiple hypervisors and unique concepts may be exposed if they can be
represented in a way which would also make sense for other hypervisors
in the future. This goal is also stated in the libvirt architecture
document.

[1] https://www.redhat.com/archives/libvir-list/2008-August/msg00693.html

[2] https://www.redhat.com/archives/libvir-list/2008-August/msg00701.html

oVirt Devel List

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



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
>
> iD8DBQFIu8O/zHDc8tpb2uURArkzAKCZJprWqqb9prB84eXpqiSqvbrDDACgh50M
> 3H2qF1AMyoMPdcf1comVOwU=
> =wk+7
> -----END PGP SIGNATURE-----