The Answer Gang

We have guidelines for asking and answering questions. Linux questions only, please.
We make no guarantees about answers, but you can be anonymous on request.See also: The Answer Gang's
Knowledge Base
and the LGSearch Engine

Contents:

Greetings from Heather Stern

Greetings dear readers, and welcome once more to the wild and whacky world of The Answer Gang.
Sorry the workshop's a mess. Even sorrier we took so long to clear out the sawdust and get these bits to you. However, I hope you find the threads a little more readable.

Which brings me to thoughts of the next battle ahead. Upgradability has always been something I care about; thence my careful management of my distros, whichever they are, and a particular fondness for Debian's apt-get feature. (I look forward to trying
yum
when I have Copious Free Timetm to try Fedora, and recommend
urpmi
to Mandrake fans.) Still, the main thing that gives any distro is the policies its maintainers apply. RPM based distros are unique because of how the dependencies are laid out - if they're good, installs of new software - even source based softare, are easy, and if not, then upgrades are just hellish. In other words, these maintainers... they are your sysadmin, until you take the reins in your hands to do it yourself - and even then, the tools they make handiest to help you with that also apply policy, at least about where the control files go.

As Linux is increasingly being taken up by people who care about what they're going to do with it, rather than folks who really care what their OS is at all under the hood - this is getting more important. The paper zines have been muttering under their breath for years "not ready for the enterprise" - what they mean is we dunno, as in Ghostbusters, "who ya gonna call?"

Nobody claims that's the problem anymore, all the big names are well known and pretty much Joe User have now heard of mailing lists and blogs. Still they resist, so the next chain to yank is "it's too hard to switch" - oops, GUI and web admin interfaces abound. Can't lean on that one too much anymore. What else? Well, change manaegement is the real problem - a problem about people, not about technology - and that's about policy.

But what about when your fought-for-and-won distro of choice changes its policies? What if you don't like them anymore? Whoops. Of course the mswin folk have dealt with the changing winds from Redmond every other season, but we've grown rather fond of having a choice... and it upsets our applecart when the spirit of a distro changes. I've watched it over the years. Slackware was one of the earliest distros at all - only had 3 or 4 competitors and you may not have even heard of them if you're new to the game - and being a distro proper made life easy. Slackware has its loyal followers everywhere - but you won't find them saying it's because they wanted to have their hand held, no way. Red Hat put together the system for the ordinary guy, the average Joe... and around the time those Caldera people were looking good for a good standing in the business world, decided that was their new definition of Joe. Their trend toward the business world has gone so far they will barely accept money from Joe's buddy out here on the street anymore. What? and have to answer his phone calls?? They run and hide. Much more fun to accept money by the industrial size barrel for the occasional call now and then from a corporate contact. The community that had grown to be fond of them takes this two ways:

a personal challenge, after all the whole point of the GPL and other free licenses is for projects to continue when the original folk bail on it;

vote with their feet, especially if any other policies of basic set up are annoying them. There's a lot more distros to pick from now, maybe it's time to go shopping.

That's where the
Fedora
plan came in. Of course, I've got my clients, and I heard diddly squat from them about the
Fedora Legacy
project - to keep RH consumer distros in security patches at least; lots more about considering the offers of Progeny or other consulting vendors to keep them in good health. Fedora's lifeblood will be the people who took the challenge seriously and though their first burst of energy was a painful birth, I think the kid's coming along nicely.

Mind you, the Linux users of the tinkering spirit, with their off brand distros
and literally a pile of Debian derivitives, are not safe from the winds of
change - they need to learn to set their sails too. The Debian project just
went through a vote that changed some minor wording in their core document, the
Debian Social Contract... and oh, the flame wars that have arisen if one
interprets the new word they chose a bit more broadly. It's not that bad
folks, it just isn't - but people who thought they were standing on solid
ground got mildly dizzy when the bandwagon shifted even a little bit. The
purists who want to know that "free means free" will feel a bit happier setting
sail this way. Those who wail that it may vastly slow down the Sarge release are probably wrong; yeah, it's slow but what I have learned to view as signs of impending release with the next few months - breakage for brief times now and then of core dependencies and thence the install of core packages - have been happening of late, and I've just learned to keep an ear flapping in the wind for the howling of their
Bug Tracking System
entries. The really painful ones get FAQ status in freenode's #debian channel by being listed in the topic you read as you enter. Luckily they also get dealt with rather quickly, but I wouldn't exactly update via cronjob these days; I like to keep a closer eye on things.

That's just a couple of examples. Now that the word "Linux" gets a few less glassy stares I also hear the hiss of people zipping their hand back with burnt fingers everywhere. The good news is there are at least as many varieties of burn cream as there are hot stoves to touch or hot sidewalks to stroll along. The bad news - good news in disguise - is there are so many choices!

That's the way it is in the Open Source world, though, folks. For anything big enough - the world is their beta tester. If we aren't - then the result will not be up to a world of users. Take your choice when to take a plunge - but Summer is here. Enjoy your time at poolside, soak in some rays or lay the Sunblock 2000 as thick as you feel you need to in all its designer colors - but the time will come to dive in. Serves millions. Enjoy.

Yes, the scsi drive is recognized and the appropriate drivers are loaded
(I did a
mkinitrd --preload scsi_mod --preload sd_mod initrd.scsi <kernel image>
and verified that the modules were included in the initrd by mounting
it). I also verified that the root filesystem is indeed ext3 (btw, how
does the system know if the filesystem is of a particular type before it
gets to /etc/fstab? I haven't figured that out yet) and it was clean.

[Ben]
Presumably by reading the partition table and doing a little string
comparison, just as "file" does.

From what I was able to google, one person said that the journal might
have been trashed (fixed with fsck) and another said that there was no
corresponding device in the initrd, which is true. But do I need to
create a device for the /dev/sda in the initrd and if so, how?

[Ben]
I've found that a lot of headaches can be avoided by simply deleting the
journal when there's a related problem. There can be much darkness of
the spirit and wailing and rending of clothes otherwise.

So straight forward that they're not even using 'modprobe'!
-- Thomas Adam

[Ben]
Saaay... that looks interesting. What's that "mkdevices" bit, and how
does it know which devices to "mk"? That's assuming that the lack of an
appropriate device is the problem. I'd also add a "-v" to all those
"insmod" invocations, just for grins - and maybe kill those "echo"
lines.

Any other suggestion for fixing this are welcome. As I've said, I've
fixed three other Red Hat/SCSI problems within the past few weeks ( 1.
boot off of an IDE and mount the scsi, 2. upgrade to Red Hat 9, or 3.
preload modules in initrd) but short of reinstalling the OS, I can't
figure out what to try next.

[Ben]
"pivotroot", IIRC, is only necessary if you want to do an "initrd"-type
boot, where you fire up a RAMdisk, boot off that, then mount your
partition on '/' as ext3, and away you go. Mind you, this is all from
memory - it's been a long time since I did this myself, and the only
reason for doing it was that I wanted to try a Debian-precompiled
kernel. These days, I just make an ext3 partition from the start.
However, you're talking SCSI, so it looks like you're stuck with doing
it that way - unless you stick a small IDE HD in there just for booting.

What I'd run into previously is, "mkinitrd" actually uses "/etc/fstab"
when building the image. I ended up having to tweak "/etc/fstab" to make
it fit the machine I was building it for - as opposed to the one on
which it was being built - and then untweak it after running "mkinitrd".

I've tried that as well.

[Ben]
Argh. Well... let's peel it back as much as we can. It's been a mort of
years since I've dealt with SCSI HDs, so I don't know how helpful this
will be, though.

First off, I'd go ahead and pop in a Knoppix CD, boot with it, and see
if I can detect/mount/read the SCSI - and I would watch carefully to see
just how different the SCSI-related messages are during the process
(i.e., do you need to try a different module?) Then, I'd make sure that
the "/etc/lilo.conf" on the SCSI is trying to do The Right Thing (you
are using LILO, right?) - no IDE-specific stuff in there, "root",
"boot", etc. are set to the correct values (not an "hdX" in the
place...) and re-run "lilo -v" just to see what the output is and make
sure that it's properly set. I'd walk through the "initrd" setup to make
sure that there's nothing odd in there, and particularly check that ROOT
in "/etc/mkinitrd/mkinitrd.conf" is explicitly set (I just remembered
having a problem with that default "probe" setting at one point; my
current one says 'ROOT="/dev/hda1 ext3"'.) Also, take a look at
"/etc/mkinitrd/modules".

Nothing else comes to mind at the moment.

The partition table holds filesystem information? I didn't see anything
in the list of types in fdisk.

[Ben]
Sorry, I should have expanded that. The kernel would read the partition
table, jump to the location indicated by it, and do a string comparison
on the info it finds there - mind you, I don't know that that's what
it does, but it would seem like a simple way to do it. However,
"mkinitrd" also reads "/etc/fstab", so that might me how it's done.

[Faber]
It seems RH doesn't have an /etc/mkinitrd directory or files.

What I'm looking at is the

echo 0x0100 > /proc/sys/kernel/real-root-dev

If I read this right, it's saying the real-root-dev is device major
number 01 and minor 00 which is ram0 (so maybe Kapil was right about Red
Hat using two ramdisks? but I see only one pivot_root. :-?) I'm going
to change it to read

echo 0x802 > /proc/sys/kernel/real-root-dev

[Ben]
I assume you mean something like

disk = /dev/sda
bios = 0x80
disk = /dev/hda
bios = 0x81

[Ben]
That would be pretty standard stuff. You could get really wild and
describe the geometry of "/dev/sda" (see the LILO manual), but I don't
know that it would be helpful.

[Kapil]
I had a look at RedHat's mkinitrd script also. RedHat's procedure
seems to be pretty straightforward (no jumping through hoops here
).
The key to understanding the above script is "man nash".

Both mkdevices and mkrootdev are builtin commands for nash. Quoting from
the man page:

...............

mkdevices path
Creates device files for all of the block devices
listed in /proc/partitions in the directory spec-
fied by path.
mkrootdev path
Makes path a block inode for the device which
should be mounted as root. To determine this device
nash uses the device suggested by the root= kernel
command line argument (if root=LABEL is used
devices are probed to find one with that label).
If no root= argument is available, /proc/sys/ker-
nel/real-root-dev provides the device number.

...............

Note that the line after the mkrootdev business is setting a "dummy"
"real-root-dev" so just replacing "0x100" by "0x810" or some such is not
likely to work.

[Ben]
That smells like it is talking about some sort of RAM based file system
(CRAMFS perhaps?) which is certainly unlikely to be an ext3 filesystem.

In other words your problem may not be with the SCSI disk and its ext3
file system at all! I don't know RH's boot procedure but some of these
distro boot images have some intermediate "RAM disk" in addition to the
initrd and do two pivot_roots!

If you want to stick with the distro's boot procedure,
your best bet is to examine this procedure in detail.

0. Check the boot command line.

1. Open up the initrd image and look at linuxrc.

Having looked at 0 and 1 for a number of distro's I have come to the
conclusion that either the guys who produce these distro boot images
do too many drugs or they are taking care of some really unusual
eventualities or both

I seem to remember that it's either CRAMFS or something like that; I'm
sure Heather knows more about it than I do. It's a "pull yourself up by
your bootstraps" kind of thing: you boot a RAM-based ext2
mini-"partition" (which mounts as "/"), which then loads the appropriate
ext3 modules, mounts your actual partition, and "pivots" "/" to it.

The usual reason is to avoid having to recompile the kernel - it makes
more sense for RH, etc. to make ext3, jfs, jffs, reiserfs, etc. modules
and let you choose which one you want to use, but the price is having to
mess with the "initrd"/"pivot_root" stuff. I just compile ext3 right in,
and never have to mess with it. SCSI, of course, is a different sort of
animal altogether.

I don't see anything there that would screw up because of a SCSI disk,
but then again, I don't know what /proc/sys/kernel/real-root-dev is for,
so I'm off to find out...

[Ben]
Anybody have an idea how 0x0100 would relate to
device numbers, or whatever else "/proc/sys/kernel/real-root-dev" is
supposed to hold? I suspect that the above is the RAMdisk, though, and
that whatever is defined as the device for "pivot_root" to "pivot" to is
what matters.

[JimD]

/proc/sys/kernel/real-root-dev is documented in
.../src/linux/Documentation/initrd.txt

Quoting therefrom:

...............

It works by mounting the "real" root device (i.e. the one set with rdev
in the kernel image or with root=... at the boot command line) as the
root file system when linuxrc exits. The initrd file system is then
unmounted, or, if it is still busy, moved to a directory /initrd, if
such a directory exists on the new root file system.

In order to use this mechanism, you do not have to specify the boot
command options root, init, or rw. (If specified, they will affect
the real root file system, not the initrd environment.)

If /proc is mounted, the "real" root device can be changed from within
linuxrc by writing the number of the new root FS device to the special
file /proc/sys/kernel/real-root-dev, e.g.

# echo 0x301 >/proc/sys/kernel/real-root-dev

Note that the mechanism is incompatible with NFS and similar file
systems.

This old, deprecated mechanism is commonly called "change_root",
while the new, supported mechanism is called "pivot_root".

...............

As Ben suggests this look like /dev/ram0 (The ramdisk) which seems
wrong. I'd look back through the /linuxrc to figure out what logic
it's using to arrive at this point. I'm guessing that it's not loading
or detecting the intended rootfs (hardware) and this value is the
result of a default that wasn't over-written by any more appropriate
case.

create the root device
attach the (ram0) ram disk to it
mount the ram disk to /sysroot
change the system root from the initrd to the ram0 disk
umount initrd

Now, that jives with the initrd on my local )non-scsi) box. The
question is: is this correct behaviour for a scsi box? If so, why is
the failure occuring at mounting the ramdisk? The mount error, IIRC, is
"no such device".

I was never able to fix my client's system to boot off of the SCSI drive
no matter how I mucked with initrd. It was a lot of fun however and I
learned more about initrd than is probably necessary.

In the end, we reinstalled RH9 from scratch. We took advantage of the
new install to reconfigure some partitions and stuff, so all was not a
total waste.

Interesting side note(s): the RH installer would not let us use LILO
and the SCSI MBR. I could use the MBR of hda or sda1, but not the way I
wanted it. So I went with GRUB.

After playing with GRUB, I must say I like it, but it has one really
weird feature. All of the documentation says that GRUB refers to the
first IDE drive as (hd0,0) and the fist SCSI drive as (sd0,0). Not on
this system! It took me two hours (for shame!) to figure out that the
SCSI drive is (hd0,0) and the first IDE drive is (hd1,0). If anyone
knows why, I'd love to hear it.

Now all I have to do is recreate two years worth of customizations on
this box. Good thing I have a very understanding client.

howto

From Guy Milliron

Answered By: Benjamin A. Okopnik, Jim Dennis

I've googled for an answer to my question, just it's too obscure for me to
figure out I guess...

I'm attempting to install a new software on my RHL box. Anyhow, it's calling
a program called fping (Which is pretty interesting itself, a round-robin
style ping http://www.fping.com ). It says it needs to run as root (which I
won't allow the calling program to run as, or needs to be "setuid".

As Ricki Ricardo would say "Splain Lucy Splain!"

[Ben]
For that, see "perldoc splain" for more info.
Although it's not quite
smart enough to help you this time...

[Ben]
"ping" has always been SUID; it needs to be in order to use ICMP - which
is what "ping" does. It's a weird security model ("ICMP can be
dangerous, so we'll lock it away under root privilege... but then we'll
make the ICMP generator SUID so everybody can use it.") Some old, hoary,
scarred and scared sysadmins remove the SUID bit from "ping" so you have
to "su" in order to use it... but note that the users will complain.
My guess is, user complaints are the reason that the situation exists.
Of course, they could have made "ping" use TCP instead of ICMP, but then
we'd be violating <Tevye the Milkman mode>TRADITION!</TtMm>.

There actually are some valid reasons for sticking with ICMP, but
they're not unique to it, and are mostly doable with TCP. TCP "ping",
IMO, would be a Good Thing and support a better security model.

[Jim]
"setuid" is a special bit in the UNIX permissions. You can make your
program SUID with a command like (as root):

chown root.bin `which fping` && chmod u+s `which fping`

... assuming fping in own your PATH.

You can be a little safer using commands like:

chmod root.$TRUSTEDGROUP `which fping`; chmod 4550 `which fping`

... where you create a group (such as 'staff' or 'trusted') which which
will be allowed to execute this program. Then you associate this
program with that group and mark it so that the owner and members of
the associated group are permitted to read and execute the SUID
program.

Thus if there is an exploitable bug in the program (a way to "trick" it
into doing things it's not intended to do with it's root privileges)
then only the owner (who's already root) and the members of the trusted
group can attempt to exploit the vulnerability.

This is very basic UNIX systems administration practice that should be
taught to ALL UNIX and Linux system administration professions in their
first term. There is not difference between UNIX and Linux in this
regard.

Note that SUID and SGID only applies to binaries --- NOT to scripts.
Perl has a special helper application (sperl) which allows it to
handle SUID (and SGID?) Perl scripts. It would be wise to associate
sperl with a trusted group and make it non-world executable (as my
second command example shows). You can make as many trusted groups
as you like.

Note that SUID and SGID are the most basic forms of privilege
delegation in UNIX and Linux. They allow you to write a program which
acts as an agent, allowing one group of users to access some resource
in a controlled and limited way (through the agent). If the program
(and the libraries against which it is linked) are bug free (or
"sufficiently robust") then this is a safe means of giving everyone or
specific groups access to some protected resource. In the case of
fping that resource is a lower level form of access to one or more of
your networking interfaces. In other cases a program might be SGID
"games" to allow it to update a file of high scores.

Because the likelihood of vulnerability rises dramatically as the size
and complexity of a program increases, it is considered best practice
to make SUID and SGID programs as small as possible --- often splitting
the "agent" portion of the code into a small helper application that is
called by the larger application.

A general purpose "SUID" wrapper program is called sudo. It allows you
to maintain a list (even a network wide list) of users (and hostnames)
and a precise list of programs, options that each user or group are
permitted to run and precisely who these programs will effective run
as. (There are several similar programs like super, caliph, and runas).
sudo is the most commonly used choice among professional sysadmins.
You control its configuration via /etc/sudoers (using the visudo
wrapper to edit that; and to check your syntax as you save and exit).

Naturally I would suggest you make a sudoers group, associate sudo
with that, and mark its mode to 4550 (SUID and non-world-executable)
as I explained before. This will help limit the number of users that
could exploit any bug found in sudo itself. Luckily sudo is one of the
more widely audited bits of code on the Internet. Unfortunately it's
also sufficiently well known and widespread that any cracker that does
find a bug in it; or manages to pass out a trojaned copy of it, will
gain LOTs of access using it (though they need to get to a local shell
account first).

So it is with all SUID and SGID programs. If the agent is
"vulnerable" it can become a confused deputy and give unfettered access
to all resources owned by a given user or associated with a given
group. (Obviously unfettered access to the root UID is also complete
control of a normal UNIX or Linux system).

You can search your entire system for SUID and SGID files with a
command like:

find / -type f -perm +6000 -ls

... this will find all SUID and SGID files. The SUID bit is
meaningless on directories (at least under Linux and most forms of
UNIX --- so far) and the SGID bit has some special semantics on Linux
and BSD systems (which I've explained in other articles):

The SUID/SGID files are also meaningless on device nodes, FIFOs (named
pipes) and unix domain sockets; as well as "regular" non-executable
files and most scripts (text executables). All of the permissions bits
are generally ignored on symlinks.

Wireless networking

From Ben Okopnik

Answered By: Benjamin Okopnik, Jason Creighton, Thomas Adam

Hi, all -

I've finally had a chance to test out the wireless Ethernet on my
laptop - in fact, I'm sitting at the local airport right next to their
Air Port (that's a joke, dammit. You're s'posed to laugh.) The problem
is, the speeds that I'm getting in Linux and Wind0ws are wildly
disparate, with Linux being on the losing end. Of course, I have no way
to measure the exact speed in Wind0ws (other than maybe downloading a
large file and doing a little math), but the connection properties say
"11Mbps" and "Quality: excellent", and the Web pages snap onto the
screen like I've never seen before. Linux... [sigh] I've seen it get as
high as 29kB/S during an "apt-get" operation, and Web pages crawl.

I'm using "ndiswrapper" (possibly part of the problem - like everything
else on this damned Acer, the hardware (Intel PRO/Wireless LAN 2100) is
unsupported), so my whole initialization sequence goes like this:

Is ACPI such an all-around evil thing that you recommend turning it off
in all cases? It just doesn't seem relevant here, unless you have info
to the contrary.

[Heather] I caution against confusing APIC (some sort of feature which SMP
processors all do, some uniprocessors happen to do, and some
CPU/motherboard combinations make poor Tux give up on herring for
Lent) with ACPI (which is what APM might be is you divided it into a few
levels of suspend then told each device to deal with sleepiness
themselves - kind of neat from an object oriented point of view, but
somewhat annoying to someone who just wants to be able to close the
lid safely without knowing why it works). Both have their moments...
and their times to be set on fire

[Thomas]
It is a complete nightmare from start to finish. It interferes with
everything. Whenever you get a HW problem such as this, I would always
look at seeing if turning it off solves it.

[Ben]
Well! That's quite the characterization.

[Thomas]
Humour me, at least. Then you can slowly remove your sunglasses and tell
me to think again

[Ben]
I was actually asking in a spirit of inquiry, not doubting you. It's
just these sunglasses make everyone suspicious.

I'll check it out - should be back on in a few minutes.

Just tried it. The Wi-Fi and the Bluetooth lights now stay on
permanently (can't be turned off), and the speed is a bit lower if
anything (I'm copying a movie file from idgames, and it's running about
26kB/S.)