Best of Technical Support
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, email@example.com
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, firstname.lastname@example.org
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., email@example.com
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, firstname.lastname@example.org
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.
Check which shared libraries named-xfer uses, using the command:
Create a new directory, $CHROOT/lib, and copy the required libraries into the new directory.
Make the other required directories inside the chroot environment, with
mkdir -p $CHROOT/etc $CHROOT/usr/bin $CHROOT/lib
Make an empty ld.so.conf file and create the necessary symlinks to the libraries:
touch $CHROOT/etc/ld.so.confldconfig -v -r $CHROOT
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, email@example.com
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Nativ Disc
- The Many Paths to a Solution
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Glass Padding
- Identity: Our Last Stand
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide