Best of Technical Support

Our experts answer your technical questions.
Setting Inodes for Small Files

I need to fine-tune the ext2 file system of a new server to handle a large amount of extremely small files (10K or less). How do I format the drive so that it can handle these small files without running out of inodes? —Ether Trogg,

All you need to do is increase the number of inodes on the system. You can do so using the “-i” parameter of “mke2fs”. Most systems use 4096 as the default value, which means you will get one inode for every 4096 bytes on your system. This should be fine for your 10K requirement, since that will average two or three inodes per file. However, if you find yourself with many files <4K in size, try values of 2048 or 1024. Anything lower is probably counterproductive. —Chad Robinson,

Mapping Keys Independently

I need to map keys to mean different things depending on which console I am using. For example, I need to have a menu screen on one session and a POS order taker on the other. Each has to have keys set up to mean different things. So far, it appears that Linux only supports a global change. I need them to act independently, which worked well under SCO UNIX. We are using Debian Potato. —Dave A.,

You can do this under Linux in much the same way as you do in SCO. The problem is that most default distributions don't except you to, so you have to do a bit of work yourself. The /etc/termcap file determines the keyboard mapping definitions (among other things). What you need to do is define two entries, for example, linuxtty1 and linuxtty2. Once you do this, modify your /etc/profile. You may optionally place these changes in the user account's .profile or .cshrc, depending on the shell used. You must write code to determine the user's login TTY and set the TERM environment variable based on that. I can't give you an example without knowing which shell you are using, but a less-than-trivial bash example can be found in /etc/profile on most systems. (It sets TERM based on local versus Telnet logins.)--Chad Robinson,

Running a Slave Name Server in a Chroot Environment

In the October 2000 Linux Journal, Michael D. Bauer's article on Securing DNS and BIND explained how to run your name server in a chroot environment. When my name server also works as a slave for some domains, it needs to be able to run /usr/sbin/named-xfer, to transfer zonefiles from the master. I spent quite some time solving why my slave domains didn't work, and I finally got it. But lots of less experienced users might waste too much time on this with a final result of “it doesn't work”, and run non-chrooted names again, which decreases their security.

The solution is as follows. $CHROOT is the directory in which you are running your chroot BIND.

  1. Check which shared libraries named-xfer uses, using the command:

ldd /usr/sbin/named-xfer
  1. Create a new directory, $CHROOT/lib, and copy the required libraries into the new directory.

  2. Make the other required directories inside the chroot environment, with

mkdir -p $CHROOT/etc $CHROOT/usr/bin $CHROOT/lib
  1. Make an empty file and create the necessary symlinks to the libraries:

touch $CHROOT/etc/ -v -r $CHROOT
  1. Copy named-xfer into the new usr/sbin directory under the chroot directory:

cp /usr/sbin/named-xfer $CHROOT/usr/sbin

And voilà--it works! Of course, your directory for slave-files needs to be writable for users who runs named. —Michal Ludvig,