Samba 4
by Joseph Harnish
I am not sure what the road map looks like for Samba 4 but I would be
interested in testing that. Is this something that we need to wait for
it to be closer to production ready? Or can we get it in the dev tree?
Thanks
Joe
18 years, 1 month
Header file 'ordering' issue?
by Tom London
Vmware has some difficulties with the latest few kernel packages that
appear to be related to some changes in the kernel build headers.
Described here:
http://www.vmware.com/community/message.jspa?messageID=375839#375839
Here's the gist:
asm-i386/bitops.h includes asm-i386/alternatives.h, and
asm-i386/alternatives.h uses type 'u8' although it does not include
asm-i386/types.h. Right fix is either replace all 'u8' with 'unsigned
char' in asm/alternatives.h, or include asm/types.h in alternatives.h.
Appears that bitops.h/alternatives.h now assumes types.h was
previously included.
Is this a known feature/change?
tom
--
Tom London
18 years, 1 month
Where is the kernel source package for FC5 GA?
by Allyn, Mark A
Hello:
I am trying to build kernel modules on a standard install
of Fedora Core 5 GA. I did select the development block
of packages.
However there do not seem to be any kernel sources available
to build kernel modules.
I tried yum and did a yum look for kernel-source and it came
up with nothing.
Where do I get enough of the kernel source to do compiles
of kernel driver modules?
Thank you
Mark Allyn
18 years, 1 month
GUI controls for instrumentation
by Kenneth Porter
I'm tasked to write a front end for an instrumentation application for
"that other operating system" ;) and I'd like to use GUI controls that are
cross-platform portable for an eventual Linux port. What would the list
recommend? I essentially need something that resembles the front panel of
an oscilloscope, along with some dial indicators and knobs. I've also been
thinking about making it web-accessible, so perhaps a Java-based solution
would be suitable.
18 years, 1 month
How to debug Fedora mono applications?
by Émeric Maschino
Hi,
Is there a HOWTO explaining how to debug Fedora mono applications? For example,
in current Rawhide, beagle-search segfaults and I would like to obtain a
callstack. Since beagle-search isn't an ELF executable, beagle-debuginfo and
gdb are of no help.
Many thanks,
Émeric
18 years, 1 month
Bootsplash?
by Richard Hughes
Now that FC5 has hibernate working for lots of people, how about we do
something about the delay which currently is displayed as a black
screen?
I click the hibernate button, and am presented with the black screen for
about 30 seconds as my ram is swapped out to disk. At resume, I'm
presented with a black screen until the desktop re-appears.
I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think
that requires a patch to the kernel away from vanilla, so that might not
be an option for fedora. Maybe rhgb could be used instead?
Has any work been done, or ideas discussed on this for fedora? Thanks.
Richard.
18 years, 1 month
Rights for /var/named in latest FC4-bind-Update "incorrect"?
by Stefan Neufeind
Hi,
the latest bind-updates to
bind i386 24:9.3.1-18.FC4 updates-released
bind-libs i386 24:9.3.1-18.FC4 updates-released
bind-utils i386 24:9.3.1-18.FC4 updates-released
triggered a problem here that we've had in the past as well :-)
The rights for /var/named are
drwxr-x--- 5 root named 266240 Apr 2 12:30 named
On a secondary-DNS zones are being written to /var/named. However bind
does not have the right to write files there. A chown to named or chmod
g+w help.
But I'd like to know what others think about this "issue". Is this due
to an error in the package, or a misusage on my side?
Regards,
Stefan
18 years, 1 month
Package names in FC5
by Rafał Kwaśny
Hi,
I wonder why some packages are named like:
cman-1.0.5-0.FC5.1.i386.rpm
(with capital FC5)
some are named like:
compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
but most of them don't have any fc5 tag
Is there any pattern in this?
--
Rafal Kwasny
rkwasny(a)aurox.org
18 years, 1 month
The Strengths and Weakness of Fedora/RHEL OS management
by Shane Stixrud
Greetings,
This message to the Fedora Development Community is an attempt to start a
useful discussion on where Fedora/RHEL is today and where it is going in
the future, on the subject of OS management. My apologies in advance for
the long message.
OS management is a very broad topic, in specific I will focus on the
elements that I consider foundational weaknesses (compared to what it
could be). This is not to imply these perceived "weaknesses" out weigh
its strengths or that other OS's are overall superior in this regard.
A bit of background to put my technical comments in perspective:
I remember when I was first introduced to Unix (1992) and then later
Linux (1993) compared to what I was used to at the time they combined a
flexibility, functionality and a form of simplicity (in design) that when
combined made all other operating systems seem hallow. For the most part
I still feel this way today, but over the years having worked in
enterprise environments where Linux is the up and coming challenger to
entrenched non-unix platforms (VMS, Windows, zOS, etc...) I have come to
better appreciate some of the elements involved in limiting Linux's
adoption.
I was recently tasked with standardizing/documenting our Linux server
build/configuration process and as part of this process began training
some of our Windows/Novell administrators to be able to carry out some of
these basic tasks. It was this second part of helping train people that
caused me to examine and re-examine the processes I used for this
standardization.
My goal was simple in theory, I would use pxe+kickstart and enforce
standard configurations and policies via a series of post scripts while
attempting to keep readability, simplicity and supportability from a
"non-unix guru" perspective as my guiding light (A wise man once said:
Make it as simple as possible but no simpler). For those interested an
example of what I came up with it can be obtained here:
http://geeklords.org/~shane/kickstart
The process turned out to be not quite as simple as the theory but very
educational none the less. To start with I had a number of ways I could
manipulate my fresh Linux install.
1) I could create a custom RPM that had all of the changes imbedded in
config files and rpm scripts that merely overwrote the pre-existing ones.
Problem being this approach hides the complexity of what all was being
changed and why.
2) Use cfengine after the kickstart install. This of course has some
advantages over the rpm method but it also hides the same complexity and
adds some of its own.
3) Document on paper all of the steps required and how to perform them
from the console, taking advantage of the guis when available or command
line when required. I felt that was not only a big waste of time but left
far too much to human error.
4) Create a series of simple scripts using basic OS applications/tools
(sed, echo, cp, mv, authtool, postconf etc...) to perform all of the
required modifications, documenting what and why along the way.
I choose method 4.
My conclusion having completed this process is that the number of
variables, complexity and dependencies that must be understood and taken
into account when modifying configuration files is much higher than it
needs to be. I think this should be clear when reading the example scripts
mentioned above.
Some things I learned:
Sed is a wonderful tool, but it is highly limited by the fact its user
must take into account whole file(s) for each expression, this is further
complicated when one must consider the file may change over time. The
complexity and readability of regular expression tools is much higher than
should be required to change OS/application variables.
Creating new files or appending to the end of existing files with "echo"
only takes one so far. This also tends to have the cost of hurting
readability as it is often the case you would prefer putting data
somewhere else in the file (i.e. sed).
The nature of flat configuration files where each application has its own
format is such where recovery and/or applying changes only if they have
not been already applied is too complex and hurts readability far to much
to be attempted in a simple shell script.
Many applications have their own command line driven configuration
utilities. However each has their own oddities and complexities
(authtool, gconftool-2, postconf etc...) Oddly enough out of all of the
command line configuration tools I have used, I find gconftool-2 to be
closest to The Right Way (TM), which is odd as it is by far one of the
most complex syntax's to use (God help anyone who tries to make major
edits to gnome xml files using sed) example:
"gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.mandator
y --type float --set /desktop/gnome/peripherals/mouse/motion_acceleration 1"
Even a complex (yet powerful) tool can meet the golden rule of "Make it as
simple as possible but no simpler" when compared against a bunch of tools
that are less powerful (and perhaps less complex when viewed in
isolation).
It is my opinion that we as a community need to find a Better Way (tm) to
manage configuration changes for Linux subsystems and applications.
Everything should be a file, but that does not mean every configuration
file needs to be formatted and managed differently.
In closing, a change this fundamental must be designed by the best minds
and must have a strong champion for it to have a chance to succeed. The
Fedora community is likely the only Linux entity with the brain power and
influence to address this issue.
Cheers,
Shane
18 years, 1 month
Re: The Strengths and Weakness of Fedora/RHEL OS management
by Avi Alkalay
Bill Crawford <billcrawford1970 gmail com> wrote:
> Dunno where you got this obsession, but just because you can represent data as
> "key/value pairs" doesn't mean that's always the best layout.
Maybe not for your or my eyes. The best layout is the one accessible
by the broadest range of ways. Currently, human-readable files are
accessible by human-beings only, or by configuration file "compilers",
that are difficult, unique, that nobody wants to write or maintain
except for the original software writer (e.g. the Samba developer with
the smb.conf file).
The proposed layout is accessible to you by simple reformatting (as
with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or
by GUIs (as kdbedit,
http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any
software that uses a simple API as libelektra.
> There's a reason why programs aren't written for the old Turing Machine, and
> that's that however well it might be able to represent any possible program,
> it's incredibly verbose.
The only reason I can see is historical. Since there is now projects
integration efforts in the OSS world, everybody uses its own format.
So you may think there is a reason, lost in time, but there is
actually no reason why BIND named.conf file look that way, which is
different from /etc/passwd, which is different from smb.conf, which is
different from httpd.conf. Well, the real reason I can see is selfish
developers that enjoy rewriting config file parsing code and invent
configuration file layouts that seems best suited for their apps. But
when you strip the syntax fat, they all are not more than key and
value pairs on a hierarchy.
So to make the discussion productive, please enlighten us with the
reasons you think exists somewhere, or please don't speculate.
> The examples which have appeared in this thread have all made things *less*
> clear afaics.
Again, maybe for our human eyes, but are 100% clear for software. And
the end-goal is leverage better software integration between
themselves, so we, human-beings, will have to look at configuration
element everyday less.
Anyway, for human eyes, I think this is pretty pleasant to see:
http://www.libelektra.org/Screenshots_and_Key_Examples
> Bill"somewhat sick of this thread but suspecting if people don't reply the
> lunatics will end up running the asylum"Crawford.
Or maybe the lunatics are already running it and some people are
trying to take the control back :-)
Avi
18 years, 1 month
