In the last few days I've started experimenting with some advanced features
in order to create a storage cluster for a relatively large setup (several
servers need shared access to about 30TB of space). Basically what I am
trying to set up is either a GFS or OCFS2 cluster using iSCSI devices as
What I noticed though is that the required tools in Fedora seem to be in a
state of neglect and I'm wondering what the gameplan is both for the Server
SIG and future RHEL releases that presumably are derived from these tools.
Here is what I've run into so far:
"scsi-target-utils" seems to be the recommended package to create iscsi
targets but it doesn't seem to be well integrated. Configured devices
aren't brought online on boot nor are they switched to offline during
shutdown resulting in error messages like "Targets still in use. Cannot
shutdown service.". The package "netbsd-iscsi" which also provides iscsi
target functionality seems to be much better integrated.
OCFS2 seems to be broken in F10 because of a missing line in the init.d file:
"system-cluster-config" has missing dependencies and references files in
the wrong places:
I think the Server SIG is the perfect place to address these issues and
maybe come up with some recommendations/best practices regarding advanced
setups involving the above tools.
From the Wiki page at
What exactly do we mean by lightweight?
What exactly do we mean by bootstrapping?
I'm inclined to shout "Genome!" but I'm not sure I read this the same
way as you do.
Thanks in advance,
Jeroen van Meeuwen
Another topic I find interesting especially for servers is the yum
If you download the fedora-release package for Fedora N+1, along with
it's dependency fedora-release-notes of course, and install it, you
should find a large number of updates available to the system.
Needless to say, either a "yum update" or a "yum upgrade", even when
just applied to specific packages only, should update the system to
whatever packages Fedora N+1 has to offer. Long story short, you should
end up with a Fedora N+1 system. The key word being "should".
Although this is not a very feasible way to upgrade servers (as it may
interrupt services running on the system because of the replacement of
binaries and libraries), I'm not stabbing at this for the concern of
stability -as obviously when from your point of view you need stability
what the he^H^H are you doing installing Fedora on the server.
Sometimes, like with Fedora Core 1 to Fedora Core 2 upgrades, you will
find yourself behind to console to accompany the change to using udev;
there's not much we can do about that.
Sometimes though, and this is where I get back to the actual point of
this message, like with the upgrade from Fedora 8 to Fedora 9, as it
turns out there's no upgrade path for essential packages like openssl;
openssl on a Fedora 8 system has a newer NEVRA then the available
package in Fedora 9+Updates. This causes yum and rpm to disregard the
Fedora 9 openssl package as an update although in Fedora 8, openssl is
the package that offers the libssl.so.6 library a lot of other packages
depend upon. In Fedora 9, this library is called libssl.so.7. Needless
to say, if the Fedora 9 version of the openssl packages does not end up
on the to-be-upgraded system as an update or upgrade, a lot of packages
depending on libssl.so.6 won't be upgraded, and the packages depending
on libssl.so.7 won't be upgraded either.
Now, to put this into perspective, my servers at home run Fedora, both
as a testing ground, because I need recent stuff to do stuff with and
because I find the well-known derivatives a little boring.
Is the Server SIG interested in pursuing a package maintainer guideline
that requires Fedora N+X should _always_ have newer NEVRA then Fedora N?
Jeroen van Meeuwen
So, here's another one I wanted to get some opinions on.
If, and when, like me, you are suicidal enough to have your servers run
Fedora, and for some foolish reason you decide to install zope/plone,
you will need python2.4 which is like from the Core era (or before,
dunno, don't care, looking forward, history is overrated).
A lot of effort has been made towards building a python2.4 compat
package, so that those that really really needed it could at least grab
it from a repository where a bugzilla was attached and more of that
"collaborative" and "upstream".
It has worked well... in fact, it has worked very very well. However,
the compat-python2.4 package was not accepted for inclusion in Fedora,
for various reasons I cannot recall right now. Seemingly endless threads
on the -devel list is about all I remember.
The point of this message being; How do the other members of the Server
SIG rate the importance of compat-/legacy tools and utilities being
available in Fedora (rather then in the more-then-insignificant
third-party-repository we all know about but do not dare mention)?
Jeroen van Meeuwen
endangering myself to be labeled the nitpicking spammer;
The exact description of the item in the working area says:
"collaborate with the installer team so we can enable different spins,
desktop versus server builds"
While I'm not sure the installer team has anything to do with creating
spins, and I'm not sure this is a big enough challenge to be separate
from the other goal listed;
"create a spin targeted at head-less servers, NAS and similar devices
(running on both physical and virtual hardware)"
So, maybe I'm misunderstanding the point, but can anyone elaborate on
these goals (and why/how they are separate)?
Jeroen van Meeuwen
Is fast bootup a priority for other Fedora server admins?
I know this may be an exercise in futility on popular server-class
hardware where the BIOS takes an inordinate time finding its boots. :-(
But when we run server clusters on cheap/desktop-grade hardware, the added
few seconds is quite significant for HA scenarios.
I've submitted a few bugs/patches that shave off a few more seconds on a
minimalist f10 setup.
http://bugzilla.redhat.com/327661 - net optional BLINDSTART skips arping
http://bugzilla.redhat.com/327651 - postfix smart newaliases
http://bugzilla.redhat.com/475101 - ipmi high-res sleep for udev
Time to prompt is reduced from 19s to 12s here. And no more large
steps/delays appear in bootchart. Should these block FedoraServerTracker?
Doing some server benchmarking today on f10. And gnuplot has somehow
acquired *way* to many unnecessary deps.
# yum -d1 install gnuplot
Package Arch Version Repository
gnuplot x86_64 4.2.3-1.fc10 fedora 2.2 M
Installing for dependencies:
GConf2 x86_64 2.24.0-1.fc10 fedora 1.7 M
ORBit2 x86_64 2.14.16-1.fc10 fedora 196 k
PolicyKit x86_64 0.9-3.fc10 fedora 173 k
SDL x86_64 1.2.13-6.fc10 fedora 210 k
alsa-lib x86_64 1.0.18-6.rc3.fc10 fedora 418 k
atk x86_64 1.24.0-1.fc10 fedora 216 k
cdparanoia-libs x86_64 10.2-2.fc10 fedora 53 k
cups-libs x86_64 1:1.3.9-2.fc10 fedora 199 k
gd x86_64 2.0.35-6.fc10 fedora 151 k
gstreamer x86_64 0.10.21-2.fc10 fedora 789 k
gstreamer-plugins-base x86_64 0.10.21-2.fc10 fedora 990 k
gstreamer-tools x86_64 0.10.21-2.fc10 fedora 20 k
gtk2 x86_64 2.14.4-3.fc10 fedora 4.3 M
hicolor-icon-theme noarch 0.10-4 fedora 39 k
jasper-libs x86_64 1.900.1-8.fc9 fedora 153 k
libICE x86_64 1.0.4-4.fc10 fedora 54 k
libIDL x86_64 0.8.11-1.fc10 fedora 93 k
libSM x86_64 1.1.0-2.fc10 fedora 26 k
libXcomposite x86_64 0.4.0-5.fc10 fedora 14 k
libXcursor x86_64 1.1.9-3.fc10 fedora 29 k
libXdamage x86_64 1.1.1-4.fc9 fedora 11 k
libXfixes x86_64 4.0.3-4.fc10 fedora 15 k
libXi x86_64 1.1.3-4.fc9 fedora 29 k
libXinerama x86_64 1.0.3-2.fc10 fedora 13 k
libXpm x86_64 3.5.7-4.fc9 fedora 57 k
libXrandr x86_64 1.2.3-1.fc10 fedora 26 k
libXv x86_64 1.0.4-1.fc10 fedora 20 k
libjpeg x86_64 6b-43.fc10 fedora 143 k
libogg x86_64 2:1.1.3-9.fc9 fedora 19 k
liboil x86_64 0.3.14-1.fc9 fedora 148 k
libtheora x86_64 1.0rc1-2.fc10 fedora 190 k
libtiff x86_64 3.8.2-11.fc10 fedora 317 k
libvisual x86_64 0.4.0-6.fc9 fedora 152 k
libvorbis x86_64 1:1.2.0-5.fc10 fedora 212 k
wxBase x86_64 2.8.9-1.fc10 fedora 673 k
wxGTK x86_64 2.8.9-1.fc10 fedora 3.8 M
Install 37 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 18 M
Is this ok [y/N]: n
Exiting on user Command
In this case, the server admin already has the desired base libX11 and
libpng stuff. So only the jpeg and related imaging libs are probably
reasonable. But definitely *not* the multimedia and various UI elements.
-----BEGIN PGP SIGNED MESSAGE-----
I have just joined the mailing list and I would like to be part of this
SIG as I have been teaching Redhat based courses for quite a while.
Myself had done RHCE plus RHCSS and after finishing up with my RHCSS I
have felt that there is a lack of concern about SELinux in general
within the Linux server community. I would love to see SELinux as a
point in our goals to achieve.
Also I quite like the idea about a spin for fedora server stuff only. I
would like to contribute to this and other projects going on within this
SIG. Please let me know how could I be of any benefit.
And do we have a IRC channel yet to start discussion.
For more information on me: https://fedoraproject.org/wiki/User:Deepsa
Key Server: pgp.mit.edu
User ID: Deependra Singh Shekhawat (Fedora Project)
Key fingerprint: ED45 62EA A4D7 53FB 44C7 774A D55B F3F0 483B 234C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
Apoligies if this list is supposed to be solely about distribution
politics. But I've an operational curiosity...
Does anyone know why the ipmi_si module and kipmi0 thread are so busy on a
totally quiet pristine Fedora 10 install?
I've installed minimialist and done nothing but a few tests. But they're
already acumulating *way* to many clicks.
# lsmod |grep ipmi
ipmi_si 47564 0
ipmi_msghandler 39288 1 ipmi_si
# ps -fp `pgrep ipmi`
UID PID PPID C STIME TTY TIME CMD
root 1492 2 0 Nov30 ? 00:04:12 [kipmi0]
# egrep 'CPU|ipmi' /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
21: 9215 407 334886 114 6969 406 334900 109 IO-APIC-fasteoi ipmi_si
Hardware is an HP ProLiant G5 with no vendor crud installed.
it has been some time when the Server SIG was announced. And one goal
has been already almost accomplished - to start discussion about the
needs of the server community. For "Server" specific issues I have
opened our own mailing list - subscribe at
One question raised during the discussions was "what is a server" and
the answer can be simple. The server is a combination of bootloader,
kernel and "the server", where "the server" can be a file server, web
server, database server, application server, etc. It is quite common to
have just one service running per hardware (both physical and virtual).
But a mix of running servers is also possible :-)
There are miscellaneous goals written on the wiki page, so it is time to
get them a little bit organized and to divide the work into more
specific areas. And they are here:
- work with the anaconda team to keep anaconda suitable for server
installs (text mode, kickstarts, ...)
- create a lightweight installer/bootstraper
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
- everything about the kernel side of servers
- place for administration and monitoring technologies available in
- collects pointers to how-tos and other docs useful for administrators
- work on the TUI counterparts of GUI system-config-* tools, should go
in hand with the backend/frontend separation
- improve/monitor the security standards for current server software
- help the desktop developers with the security aspects of their work
If there are no objections I will update the wiki accordingly and
participants can then put their names/nicks to their area of interest.