Category: How To

Recently I was asked to look into a problem involving BIND. DNS was not able to start via webmin, nor via /etc/rc.d/init, but named could could be manually started as root. While that works in the short run, that doesn’t solve the problem of the system surviving a reboot cleanly.

The only error named was reporting was:
Starting named: Error in named configuration: none:0: open: /etc/named.conf: permission denied

Obviously, this looks like a permission problem.

Normally, the trick, to solving it involves running named as root and looking at the error messages.
# named -g -u named

Problem is, as root, that worked. Not what I expected.

However, I found the problem and have a fix.

Bind used to run with the setuid bit, making it privileged, however in these security concious days, named now sheds its permissions. Even better, it is locked into a limited portion of the directory via chroot. That should be a big clue.

In FC4 and FC5, you’ll noted that /etc/named.conf is actually a symbolic link. It points into /var/named/chroot, where the process is jailed. In that directory you’ll find an a named, etc, and var directory. The etc directory mimcs all the needed files from /etc. The named directory has all the zone files. And the var directory has the pid and log files.

If named can’t run due to a permission problem, one should be looking under /var/named/chroot — which is how the process will see the world, not from /, like you do.

In my case, someone had run named as root, and that was enough to create a slave file in /var/named/chroot/var/named/slaves with an owner and group of root. Because the named process when running normally did not have permissions to replace this file with an update, named failed with a permission problem. I removed the file and was instantly able to start named from webmin as normal.

So there’s the trick. Look around in /var/named/chroot/var, /var/named/chroot/etc, and /var/named/chroot/named (and their subdirectories) and make sure all the things are readable to the named user, and the stuff that’s writable has the right owner, group, and permissions.

REMEMBER: when a config file says /etc or /var, it’s from the perspective of the chroot’d process — therefore you need to look where the process has been jailed to in the filesystem, and not what the path name looks like.

I still use FC4 quite a bit, but was surprised that sudo appears to be broken. It doesn’t work.

Even after adding user entries to /etc/sudoers, sudo will authenticate, showing the password, but won’t execute the command. For instance, sudo bash drops me back at the unprivileged shell.

The “problem” is actually PAM. The Pluggable Authentication Module.

If you hop over to the /etc/pam.d directory, you’ll discover that you need a sudo file. If one does not exist, then PAM will use other; and doing a cat on that file shows the default policy is to deny.

The quick solution is to simply something that works, such as the sshd file:
# cp sshd sudo

Or, at a minimum for Fedora Core 4, you can use this content:


/etc/pam.d$ cat sudo
#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_limits.so


Note, though that for Fedora Core 5, things change a little:

#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session required pam_limits.so


Make sure you set the perissions and ownerships correctly:

# chown root sudo
# chgrp root sudo
# chmod 644 sudo
$ ls -l sudo
-rw-r--r-- 1 root root 203 Jul 5 2006 sudo


Please note that there is a yum distribution. You can add sudo to your system with:
# yum install sudo

Watch for warning messages. /etc/pam.d/sudo might need to be replaced with /etc/pam.d/sudo.newrpm, and /etc/sudoers might need to be replaced with /etc/sudoers.newrpm. This is simply yum not wanting to step on any existing files. Yum is the preferred way of installing sudo with FC4 and FC5.

I’m working with some old equipment, specifically a P3 server that has a Mylex DAC960PTL1 raid controller in it running a 1999 version of EzAssist off firmware. I ran into a problem where I couldn’t delete a disk array nor a logical volume once created.

According to the manual, entitled RAID ExAssist Configuration Utility, User Reference Guide, DB13-000047-00 First Edition, 08P5519, by LSI Logic, there were delete menus, but I just wasn’t seeing them.

A little research showed that LSI Logic now owned the Mylex DAC960PTL1, and their download page, while showing plenty of DAC960 variations, did not have the PTL1 suffix. Turns out this is now called the AcceleRAID 250 controller, and drivers and firmware are available.

Turns out the problem was that I needed to upgrade the BIOS, EzAssist, Firmware, and Bootblock by using the latest Software Kit v4.04-02, dated December 20, 2001.

So I grabbed a copy of ez_assist404.zip, unpacked it to a floppy, and followed the directions in the readme, which consisted of booting, holding down Alt-R to bring up the existing EzAssist setup utility, and flashing the files off the diskette one by one.

Once I did that, I was able to manage the existing raid drives, both logical and physical, without incident.

For those curious, you set up the physical drives first, add them to a pool of storage called an array, and from there make logical volumes, which are then exposed to any operating system with a device driver for the raid card, such as Fedora Core 4 (/dev/rd/… which then has a controller/disk/partition notation for device names).

It took over a full day to locate this information and make use of it. Hopefully, documenting this save someone else the trouble.

I had been a little discouraged by the Apple Pro Care recently. I attempted to get online and make a reservation with the Genius Bar, but every time I try that, I could never get a same day appointment.

Turns out that the Tysons Corner Apple Store has stopped taking reservations! Seems that people would make reservations from work at 3:PM, then show up at 4:45pm, and wonder why they aren’t being immediately seen.

Turns out Apple’s solution is fairly clever.

Last night I showed up at the store, and it was packed. Even the local access to the Genius Bar said no more appointments would be made. There was a long line.

However, having my ProCare card in hand. This got me instant priority access, and I shot to the front of the support line. Awesome.

I’d been using ProCare for access to big machines, professional software, and one-on-one tutorials. This is an additional perk — line avoidance. If I was on the fence, I’m not any more.

-wls