Sorry. I haven't followed the previous conversations on this but just
wanted to highlight that any future updates should incorporate
if you haven't already done that. Also a note on how to create a Xorg
configuration file if one doesn't exist should be included as well.
It recently occurred to me that it is time I gave something back to
the community. I started using Red Hat 8 in college, and eventually
switched to using Linux on my primary desktop. I now make a living as
a sysadmin for RHEL desktops and servers in a small department of a
large Midwestern university. Since I don't have much skill as a
programmer, I decided that the Docs group was a good place to start.
I don't have any formal project experience, but I do fancy myself a
passable writer. Among the accomplishments I'm most proud of during
my tenure as a sysadmin is the creation of an internal wiki for my
department's IT staff. When I took the position, the documentation
was whatever could be found in old e-mail messages. Largely on my own
effort, but with considerable help from the rest of the staff, our
wiki is now a valuable resource. The contents range from detailed
how-to guides to big-picture discussions of the system architecture.
My degree is in meteorology, so I do not have a great deal of formal
training with computers. Most of my knowledge comes from breaking my
computer and then getting it working again. I do have certifications
on Linux (RHCT) and OS X (ACSP), and I try to get training when the
opportunity and budget align. My primary technical skills are in
basic setup and administration: kickstarts, package management, NFS,
CUPS, etc. What I lack in technical skills, though, I make up for in
the ability to find contributors. I tend to bring in people outside
my department to help on specific tasks when their skills better match
Here's my GPG key:
[1018 bcotton@boone ~ ]$ gpg --fingerprint AB46AA74
pub 1024D/AB46AA74 2009-02-14
Key fingerprint = B09D 841C 1347 091A 3BD0 759F D9CD 1319 AB46 AA74
uid Ben Cotton <bcotton(a)purdue.edu>
sub 2048g/4BB9F3C7 2009-02-14
I think that covers all I need to share. I look forward to working
with all of you and contributing to the project.
My name is Héctor Daniel Cabrera. I'm from South America, Argentina, Buenos
Aires. Nowadays I´m working in a foundation, doing several research projects
related to the history and geography of our country.
I'm also a happy fedora user for about two years now, and one of the active
translators of the Spanish team.
The main reason why I want to join the Documentation Project is that I've
enjoyed so much translating both Installation and User Guide, that I realize
how comfortable am I trying to explain to other people what's fedora about.
So, if you need any help, it will be nice if you can count me in.
See you around,
irc: _logan_ on freenode
My name is Idealist Lee. I'm from East Asia, China, Suzhou. Nowadays I´m
working as a junior software deveopler on Home Automation.
I have used Fedora for two years(Fedora 6, Fedora 8 and now Fedora 10).
I think it's time for me to do something for the community now. And I can
be help to translate English documents to Chinese, though I need some
practice first. So, if something that I can be helpful to, please count me
Below is the the text of the interview, didn't really think about the
lead it, but thats trivial...
*1. Please introduce yourself and what you do and how you got started
working on virtualization.*
I'm one of the lead developers for the libvirt project and am actively
involved in many related areas of open source development (qemu/kvm,
xen, gtk-vnc, virt-manager, to name but a few). I also co-maintain many
of these packages in Fedora and RHEL, along with many others in Red
Hat's virtualization team.
More than three years ago (shortly after transferring into Red Hat's
Engineering team, from consulting services) I was working on the OLPC
project. We needed a way to easily test the OS images we were building
without needing real hardware. As a proof of concept, I hacked up a
simple GTK application to run images them under QEMU. At around the same
time Daniel Veillard had started the libvirt project and there was a
desire for a desktop application to manage Xen using libvirt. So I
switched over to the virtualization team, wrote virt-manager for Fedora
6, and my involvement in all areas of open source virtualization grew
*2. Many people view the work being done on virtualization as a feature
set of major importance and significance. Can you give us a brief
overview of some of the changes that we can expect to see in F11?
The open source virtualization development effort is so large now, that
it is useful to discuss each stream in turn.
At the lowest layer is obviously the Linux kernel & KVM/QEMU. There has
been a major acceleration of development in QEMU and push to merge KVM
into the official QEMU source repository. There's ever continuing work
on performance, stability, scalability & reliability in KVM. PCI device
passthrough is one new feature we're highlighting for Fedora 11. The
return of Xen Dom0 was not to be, as the Dom0 paravirt_ops merge with
the upstream Linux kernel is still an ongoing process.
At the middle layer is libvirt, providing a consistent management API
across different virtualization technologies. New features in libvirt,
since F10, include PCI device passthrough for Xen and KVM, the sVirt
security driver using SELinux to protect KVM guests from each other,
thread safety of all libvirt APIs, improved scalability, reliability and
debugging for the libvirtd daemon and support for SCSI HBAs and
copy-on-write volumes in the storage management APIs.
The top layer covers end user tools such as virt-install & virt-manager.
virt-manager is undergoing a significant (and ongoing) overhaul of its
user interface. The first improvements arriving for Fedora 11 are in the
guest installation process and storage management capabilities. As guest
installation is first task most users try, ensuring this is simple and
reliable is key to making a good first impression. Guest desktop
interaction is another historical pain point which has been a focus for
improvements in Fedora 11.
With every release we also try to make a significant step forward in
security of the virtualization stack. In Fedora 11 the focus has been
on SELinux to protect guests from each other and SASL to authenticate
*3. There have been some large changes in virt-manager and libvirt,
which are at the core of the user experience when it comes to
virtualization. Can you talk to use about those some more?*
The guest installation process and desktop interaction are the most
critical areas for making a good first impression. In the virt-manager
re-design the wizard used for installing new guests has been
streamlined, cutting out three redundant steps. Where possible, it will
automatically detect the type of operating system being installed and
choose the best configuration options to optimize for this OS, no longer
requiring the user to figure this out for themselves. The installation
process now directly utilizes the libvirt storage management APIs to
allow easy creation of files in a variety of formats (raw, qcow2, vmdk,
etc), allocation of new local disk partitions or LVM volumes and access
to LUNs exported by iSCSI targets. This is particularly useful when
remotely managing virtualization hosts, allowing regular administrator
tasks to be performed from the virt-manager UI without resorting to
command line SSH sessions.
The mouse pointer has been a constant source of trouble for
virtualization management applications. Getting the guest mouse pointer
to track the host pointer is essentially impossible with the standard
emulated PS/2 mouse. The solution is to provide a pointer device that
supports absolute motion events, instead of relative events that the
PS/2 mouse provides. For KVM and Xen, this means adding a USB tablet
device, but historically Xorg has not been able to automatically
configure this correctly. This is resolved with Fedora 11 guests,
finally providing a guest pointer that moves in perfect sync with the
host, not requiring the pointer to be confined to the guest window.
Users with non-US layout keyboards have also had a hard time getting
their guests to support input of accented/special characters. The VNC
protocol has now been extended to allow the hardware keycodes to be
passed directly from the VNC client to the guest OS without any
intermediate translation step. This should allow the guest OS complete
control over the keyboard layout mapping, without a need for any special
settings on the host.
The final piece of work was to increase the guest desktop resolution.
The real Cirrus video card that QEMU emulates would never have done more
than 800x600, but there are tricks that can be done in a virtual world.
Thus a simple change to the Xorg cirrus driver allows it to detect that
it is using a Cirrus card emulated by QEMU and increase the guest
desktop resolution to 1024x768. Still not great by today's standards,
but better than before. Longer term plans involve replacing the cirrus
driver in QEMU with something more virtualization friendly.
*4. Also, as people should take note of, there has been a lot of work
done surrounding KVM and getting that well integrated into the whole
virtualization setup in Fedora. How has that work been going and has
anything significant been done in that area in this release?*
Fedora was the first major Linux distribution to integrate KVM back in
the Fedora 7 release. It became the default virtualization technology in
Fedora 9, when it became clear we could no longer maintain the separate
Xen host kernel until it was merged in the upstream Linux kernel. The
great benefit of KVM from an distro integration point of view, is that
it is there by default in all new Linux kernels. All that was required
in Fedora was to turn on the module build and make sure the modules are
always loaded when compatible CPUs are found. libvirt and virt-manager
have also both supported KVM since it was first added to Fedora. Thus
there hasn't been a need for much additional integration work for KVM.
The focus has simply been on improving features available to KVM users
via libvirt and virt-manager.
5. Glauber Costa has also done significant work merging KVM and QEMU.
Can you explain to us what QEMU is and why the choice was made to merge
it with QEMU and how that is of benefit to the user base?*
Earlier Fedora releases have have suffered from the divergence of QEMU
and KVM code bases. Upstream QEMU has had releases almost 1 year apart,
while KVM has been releasing at least once a month, if not more, using
snapshots of the QEMU source repository. Thus the features available in
QEMU were far behind those available in KVM even though they both shared
the same fundamental code base and upstream development stream. It also
doubled the work package maintainers had todo for security & bug fixes.
Since Fedora 10 though, the upstream QEMU community has accelerated its
release schedule significantly and many of the KVM features have been
merged back into the main QEMU code base. Thus we judged that the time
was right to attempt to ship a single package containing both QEMU and
KVM built from a single code base. For users this means that parity of
features between QEMU and KVM, while the reduced burden on our Fedora
package maintainers, ensures more timely security and bug fixes. Glauber
also took the opportunity to split out all the virtual BIOS files and
ROMs from QEMU into separate packages and ensure all are fully built
from source using appropriate upstream source releases.
*6. Virtualization and Security are two things that are being discussed
more or less hand in hand these days, as the ability to create and use
virtualized machines expands there are many security risks involved. Can
you speak a bit to the work that was done one improving security both at
the kernel level (sVirt) and also the user level with things like SASL
for VNC Auth?*
In each Fedora release we try to make at least one significant step
forward in the security of our virtualization technology. In Fedora 8,
libvirt gained support for secure remote management using TLS for
encryption and x509 client certificates for authentication, while
GTK-VNC, QEMU, KVM and Xen were also all extended to add a VNC extension
for TLS encryption providing a secure remote desktop. In Fedora 9
libvirt was further extended to support SASL enabling secure remote
managment with Kerberos for authentication and PolicyKit for local
desktop authentication. Fedora 9 and 10 also increased use of SELinux to
protect the host operating system from a compromised or malicious
The latter still did not provide any protection between guests, so one
compromised QEMU process would still potentially be able to compromise
another on the same host. Thus James Morris started work on a project
known as sVirt, the first results of which are appearing in Fedora 11.
The focus has been to provide isolation between guests running on a
single host. libvirt directly integrates with SELinux to ensure every
QEMU process it launches runs within a dedicated security context, only
able to access its own assigned disk images. This protection is enabled
by default on all Fedora 11 hosts using libvirt for management. As well
as the security benefits, the end user experiance is improved because
libvirt will automatically manage SELinux labelling for all guest disks,
eliminating a major source of bug reports from previous Fedora releases.
*7. These features have all evolved over time and over the previous
Fedora releases and Fedora, as a distribution, has always been a leader
in the virtualization realm. Can you talk a bit now about the actual
process of developing these features and how many of the improvements
and enhancements to virtualization have come about as a direct result of
the work done previously? Also, what does the future look like?*
Virtualization technology in Fedora is reaping the benefit of very
active upstream projects and the significant developer resources of Red
Hat's Virtualization Engineering team. The combination of these provide
great opportunities for new features to have their debut in Fedora releases.
The ideas for new features come from many sources, some from Fedora
end-user experiances & consequent bug reports, some magically arrive on
cue from upstream projects, while others are things that look to be
important for future RHEL releases. With the PCI device passthrough
feature in F11, the core support was all already done by the upstream
KVM community. This is a important feature for future RHEL, so Red Hat
put resources into a F11 feature to add support to libvirt for PCI
passthrough with KVM and Xen and then expose this in virt-manager.
The feature aiming to improve the guest desktop interaction was a result
of the persistent stream of bug reports from Fedora users. We had been
considering ways to address this over course of several Fedora releases,
but it was not until Fedora 11 that all the pieces of the solution
finally came together from the various upstream projects.
The security improvements in virtualization have a different origin.
Very few end users ever file explicit bug reports asking for the
addition of more authentication / encryption features or to use more
SELinux. If anything users ask for ability to more easily turn off
existing security features. This is a case where the user is not always
right. They do want more security, but they just don't know it yet!
As a developer it is neccessary to be very proactive with security
improvements. This can be particularly challenging work because the
solutions often involve working across multiple upstream communities.
Take the VNC SASL authentication feature in Fedora 11 as an example. The
first step was to write a specification for a new VNC security
extension, have it reviewed & get a code for it allocated by RealVNC.
Work on QEMU was required to implement the server side. Work on GTK-VNC
was needed for client side. For management tools, work on libvirt was
required to get the new security type enabled for guests it launches and
finally virt-manager was extended such that it knows how to login.
That's give different projects involved for one feature. This is only
practical by having a close working relationship with all the upstream
communities and carefully coordinating the work there so it all arrives
in time for the next Fedora release.
For the future we're happy that libvirt gained support for managing
VirtualBox recently and likely to soon have a driver for the Open
Nebular cloud management project. Expect more advancements in sVirt,
allowing for tighter controls on what a virtual machine can do, for
example, ability to restrict network access of guests. libvirt will also
gain the ability to manage host network configuration in Fedora 12,
removing the need to manually configure bridge devices. Container based
virt may make a more formal appearance in Fedora 12 as the native Linux
container (LXC) support improves in the kernel and libvirt. The overhaul
of the virt-manager user interface also continues.
*8. Working on Virtualization must be awfully time consuming and very
involved. Do you enjoy it? What do you do to get away from the
pressures of hacking?*
Working on open source virtualization technology is a great experiance
because it is a really interesting & challenging field, having plenty of
talented developers to work with & learn from. There is plenty of work
still to be done at all levels of the stack from kernel/hypervisor right
through to end user applications & not nearly enough time todo it all.
I'm fortunate to be able to spread my work between upstream projects,
the Fedora community and RHEL releases and maintainence. As for free
time ? What free time :-) I try to find time for a photography, with 4
out of my 5 cameras still using film, rather than digital.
-------- Original Message --------
Subject: Re: [Fwd: Re: Proposal for Implementing a Docbook Editor]
Date: Thu, 21 May 2009 11:20:26 +1000
From: Lana Brindley <lbrindle(a)redhat.com>
Organization: Red Hat Asia-Pacific
To: Christopher Curran <ccurran(a)redhat.com>
CC: Joshua Wulf <jwulf(a)redhat.com>, content-services-staff(a)redhat.com
References: <4A14A4D0.40207(a)redhat.com> <4A14A6E1.6040702(a)redhat.com>
Christopher Curran wrote:
> Lana Brindley wrote:
>> Joshua Wulf wrote:
>>> Satya is doing a WYSIWYG docbook editor as a Google SOC project in
>>> Fedora. He wants feedback on what tags to provide support for. Please
>>> take a look at this list and give some feedback on tags that we use
>>> that are not covered in it.
>>> - Josh
>>> -------- Original Message --------
>>> Subject: Re: Proposal for Implementing a Docbook Editor
>>> Date: Wed, 20 May 2009 21:47:25 +0530
>>> From: satya komaragiri <satya.komaragiri(a)gmail.com>
>>> Reply-To: For participants of the Documentation Project
>>> To: For participants of the Documentation Project
>>> I have narrowed down to the following set of tags as the minimum that
>>> Docbook editor will need to support for the initial stages of the
>>> project. It would be great if the list could review them once and
>>> suggest any additions/deletions.
>>> Top Level:
>>> <article id="ID">
>>> <section id="ID">
>>> Block Tags:
>> Is this tag the same as <programlisting>? I don't know it.
> programlisting is for a block of preformatted code. computeroutput is
> for a single inline output snippet.
Ah-ha! Thanks Chris :)
>> <abbrev> and <acronym> could both possibly be dropped
> and in there place firstterm should be added.
It's in, scroll up.
>> Also, support for <!--comments-->
> The only one I would say is seglist should be in the list of advanced
> features to implement :)
Actually, that reminds me of <variablelist>, which I use a lot:
> I wonder why I didn't get the fedora-docs-list email about this...
I am a final year undergraduate student from India and I plan to apply
for Google Summer of Code. I would like to implement a Docbook editor.
I discussed this idea with Mr. Yaakov Nemoy (cc'ed in this mail) who
has agreed and is guiding me through the process.
The Docbook editor will make it easy to write documentation through a
wysiwyg interface. Since Docbook has a great collection of XSLs it
will be easy to convert it to HTML and write a web based editor.
My research has pointed me to Beacon, which is a similar editor for
GuideXML (Gentoo's documentation format). It uses an XSLT engine to
transform XML to HTML and vice versa. I contacted the developer of
this project and it seems like this project has been in hibernation
for couple of months or so. But the codebase is quite developed and
should be easy to work with. The developers were also making it a
generic plug-able framework for easy integration of other doc types.
Since it is a web-based editor, we can integrate this into the Fedora
documentation site for easy editing and creation.
It would be very nice if the Docs team could provide some feedback on
what they feel about a web-based GUI editor which would eliminate the
need for knowing the Docbook XML format. If I am given a go ahead, I
would like to put this up as a Feature.
 Existing XSL for Docbook:
 Beacon: http://beacon.kix.in/
-----BEGIN PGP SIGNED MESSAGE-----
Forwarding along to the Docs Team...
- ---------- Forwarded message ----------
From: Domingo Becker
Date: Mon, May 18, 2009 at 08:21
Subject: release notes for F11
To: Fedora Translation Project List
It's hard to find where to read more about how to configure
fingerprint readers mentioned in "5.2.1. Fingerprint Readers" of
Fedora 11 Release Notes.
Unlike other new sections, it has no links at all.
Is it possible to add it some links for further reading ?
Fedora-trans-list mailing list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5)
-----END PGP SIGNATURE-----