UNIX Administratosphere

The new version of Core Linux comes with packages and appears to be fully comprised of packages (like Red Hat Linux, and unlike FreeBSD which has a core application set). These packages are simple: they are just tar.bz2 files that contain files relevant to the application, and a set of files that go under /etc/coretools/pkg.

The directory /etc/coretools contains everything related to core packages; the pkg directory has the details on each package, and the directory exec.d has plugins for the program corepkg. Plugins are just scripts that are called by corepkg.

The program corepkg lists its help if called with no parameters. Some of the more common usages might be:

• corepkg --list (list current plugins)
• corepkg --exec=info --pkgname=pkg (package information by name: pkg)
• corepkg --exec=list (list all installed packages)

The plugins as installed are:

• contents - list files created by package named
• count - count packages matching specified options
• info - information on specified package
• install - install specified package
• list - list installed packages
• remove - removed specified package

The packaging system is simple and driven fully by shell scripts. It should be possible to ignore it without adverse effects. There don’t seem to be any packages beyond the basic system, but that may not be the case. Anyway, the goal of the original Core Linux - and its descendents - is to build your own system through compiling your own code.

To prepare for installing grub, it is necessary to chroot into the system mounted on /mnt. To do this, we need a working /proc and /dev under /mnt; this is accomplished like thus:

mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev

Then perform the chroot - making the new environment mounted under /mnt our new environment:

chroot /mnt /bin/bash

Note that this makes bash the current shell - not my general choice (I prefer ksh) but things might break if you use the wrong shell….

Now we can install and configure grub:

grub-mkdevicemap
grub-install –grub-setup=/boot/grub/grub.cfg /dev/sda
/sbin/grub-install: line 223: /boot/grub/grub.cfg: Permission denied
grub-setup –directory=/boot/grub –device-map=/boot/grub/device.map /dev/sda
cat /boot/2.6.21.1/grub >> /boot/grub/grub.cfg

The error comes from grub-install apparently trying to write to grub.cfg (which has permissions 644). The directions say this error can be ignored - so that’s what we’ll do.

The resulting grub.cfg looks like this:

# Set timeout
set timeout=30

# Set default entry
set default=0

# Grub configuration for linux-2.6.21.1
menuentry “Core 2.0 GNU/LInux (2.6.21.1)”{
set root=(hd0,1)
linux (hd0,1)/boot/2.6.21.1/bzImage root=/dev/hda1 vga=5
}

In this case, this is certainly wrong. The last stanza is preconfigured for hda and for a single volume root. Since I have two partitions, and am using /dev/sda, it should be:

# Grub configuration for linux-2.6.21.1
menuentry “Core 2.0 GNU/LInux (2.6.21.1)”{
set root=(hd0,1)
linux (hd0,1)/2.6.21.1/bzImage root=/dev/sda3 vga=5
}

Then edit /etc/fstab:

/dev/sda1 /boot ext3 defaults 0 0
/dev/sda3 / ext3 defaults 0 0
/dev/sda2 swap swap defaults 0 0

Then reboot:

exit
cd /
umount /mnt/dev
umount /mnt/proc
umount /mnt/boot
umount /mnt
shutdown -rn now

Next time…. the first boot.

Installing Core Linux is covered in this article (on the front page of coredistro.org as it happens!). The descriptions are clear; however, we will expand on the instructions listed there.

Let’s assume that you’ve already burned the ISO and booted with the CDROM. Once the system has booted, you’ll see this screen:

Log in as root (which has no password). First, figure out which disk to work with. The disk is most likely either /dev/hda (first IDE drive) or /dev/sda (first SCSI drive). You can see whether these disks exist by searching dmesg for sda and for hda.

Once the disk is determined, we must begin laying out the disk. In my configuration, I used fdisk to create three partitions:

• /boot partition of 500M
• Swap partition of 1G
• / partition of the rest (about 7G)

With this configuration, it is then necessary to (of course) create the filesystems:

mkfs -t ext2 -j /dev/sda1
mkfs -t ext2 -j /dev/sda3

The -j option creates what is commonly called an ext3 partition - which is in reality, and ext2 partition with a journal file attached. But that’s another post.

After the filesystems are created, then they must be mounted under /mnt as the complete environment would be layed out. For this example, that means:

mount /dev/sda3 /mnt
mkdir /mnt/boot
mount /dev/sda1 /mnt/boot

After this is done, the actual process of installing Core Linux can begin. At the prompt, type:

install_core /mnt

Messages will appear like these:

Once this completes, a message comes back:

Install complete - the next step is to chroot into /mnt and install grub

Next installment… setting up grub.

If you want to create your own Linux distribution from scratch (and learn a lot during the process), you could do no better than to start with Linux From Scratch. However, many of us will not want to go to the extremes that LFS requires: there is an alternative - Core Linux.

Core Linux provides just enough of Linux to boot into a shell and compile. Thus it comes with bash and gcc and associated tools. If you want Apache - or PHP - or X11 - or KDE, you’ll have to compile itself - which is the point.

Core Linux comes in a small ISO, and provides a small shell script to install the basics of the system. The ISO is 150M and is available from Sourceforge.

When you burn the ISO, don’t forget to use the image capabilities of your CD burning application; don’t copy the file into a CDROM directory - but then you knew that already, didn’t you?

In upcoming parts of this series, I’ll show you how to install Core and how to get started with some applications. Of course, if you can’t wait…..

Planning for a disaster is not necessarily as easy as it sounds. It helps if you have a rampant imagination. Throughout disaster planning, the dominant question is What if…? Following the planning, testing is required: the best plans are worthless if they don’t work in practice.

Consider an Internet server serving web pages. Let’s assume that downtime is not an option: this is a typical point to start at. The best thing to do is to start with the most specific to the system (the complete environment) and work out:

• What if… a disk goes bad?
• What if… the software stops?
• What if… memory runs out?
• What if… the power goes out?
• What if… the kernel panics?
• What if… the cluster failover fails?
• What if… the network switch fails?
• What if… the network firewall fails?
• What if… the internet link goes down?
• What if… the internet provider drops off the grid?

Each one of the questions must be answered and the results tested. To test for power outage, pull the power. For a failed network switch, pull the network cable - and so forth.

Most of the answers will include some form of redundancy - clusters, dual facilities (such as power and network and internet providers), and so on. However redundancy is only one solution; there is prevention and alerts as well.

Each risk must be weighed against the cost to mitigate that risk. However, assuming that the risk is minimal does not eliminate the risk; the biggest problem is not accounting for a risk that eventually happens. There is nothing like downtime of a critical server to get an unforeseen risk taken care of; better to handle the risk before it happens.

It also does not matter if the plans have not been tested. If tests are not done, then the actual event will be the first time things have been put to the test - and what if something was missed and the system goes down? During a test, preventive measures can be taken to make sure that things work as they should - during an unexpected event, it is not possible to back out or prepare; if things go down they go hard. Don’t let that happen to you!

And disaster planning is not limited to servers (or virtual servers) - what about the possibility of a server hosting multiple virtual servers going down? What if your server is hacked into? What about your monitoring system failing? What about getting paged? Have you planned contingencies for all of these events?

Plan, then test, test, test - and you will make it.

The utility lsof is a relatively new (well, compared to UNIX anyway) that has more options than even ls. These options provide for some extremely powerful capabilities, some of which we aim to illuminate here.

My favorite use for lsof is for networking: all sockets can be seen with the following options:

lsof -n -i

The -n option prevents lsof from being slowed down by a large number of DNS lookups, and the -i option returns all TCP/IP connections (with process numbers, user ids, file descriptor ids, and so on). To narrow it down, utilize options like the following - to list all SMTP connections, for example:

lsof -n -i :25

It is also possible to list only certain processes (such as process 25 and process 45):

lsof -n -p 25 -p 45

Alternately, the process can be selected by name:

lsof -n -c perl

However, suppose one wants to list all TCP/IP sockets held open by perl processes. The obvious choice does not work! This is because the options are combined together as an OR function; to combine them as an AND function (that is, all options must be satisfied) use the -a option - such as this:

lsof -a -n -c perl -i

This lists, as desired, all TCP/IP sockets held open by perl processes.

Another that might be useful in a security context is listing all files that are open but have no links to them: that is, they’ve been deleted, but one or more processes are keeping the file open, which means the file itself (and its blocks) are being preserved even though it appears to be deleted from the filesystem. To see these files, use this option:

lsof +L1

The utility lsof is indeed very useful, and reading the man page for lsof is recommended.

The PWN to OWN Contest is a hacking contest at the CanSecWest security conference that pits a standard install of Linux, Windows, and MacOS X against all comers. Each laptop has a default installation on it, and has not been hardened at all. The successful hacker will not only win a cash prize, but the system in question as well.

The MacBook Pro was the first to fall, and the laptop running Microsoft Vista Ultimate second. However, there will be those that misinterpret the results by not realizing how the contest was conducted.

Each contestant gets 30 minutes to attempt to crack the machine, and can choose which machine to attack. The attacks are limited by the rules, and each day that went by the rules allowed a wider range of attack vectors. It was a third party application (Adobe Flash) that permitted the compromise of the Microsoft Vista machine.

No part of the contest can be considered a scientific study into which system is more secure than the other: contestants attacked a single machine of choice, and contestants were allowed their attempts one at a time - and the operating system was not hardened.

This is entirely different than, for example, the Capture the Flag contest at DEFCON. That contest consists of setting up a server and trying to capture the other teams “flag” through compromising the server in some way. In that contest, any and all comers are permitted to enter and to attack at will during the contest with whatever vulnerabilities and methods they have available.

Speaking of DEFCON, DEFCON 9 saw the entrance of an Alpha-based VMS machine - installed with the standard setup - which remained unscathed throughout the contest, though try they did. The VMS Team (the Green Team) had a writeup and also wrote a white paper afterwards.

If you are interested in DEFCON, DEFCON 16 will be August 8-10 in Las Vegas, Nevada.

Also, speaking of DEFCON - let’s not forget the similarly named but totally unrelated InterSystems DEVCON2008, which is just wrapping up. DEVCON, among other things, covers Caché development and related. It is interesting to note that InterSystems DEVCON began 15 years ago, whereas DEFCON began 16 years ago. I wonder how much Caché security is covered at DEVCON2008.

In Solaris 9, two new utilities were added: pkill and pgrep. These tools are perhaps old news to Solaris admins. However, these utilities were then quietly added to Linux in short order, and now show up in HP-UX 11i v3 and perhaps others. What do these tools do?

First of all, pkill is just a wrapper for pgrep. Well, what does pgrep do? It searches the current processes for a match based on arguments that you give to it.

The most common use would be to search for a command. The pgrep utility will then return each process ID, one per line. The pkill utility will send the default kill signal to each pid. The pgrep utility can search based on a large array of factors, including userid, groupid, virtual size, effective user ids, command name, full command string, and more.

Here’s an example:

# pgrep cache
13
12
14
15
33
49
22006
21950
21973
21976
#

When combined with scripting, these commands can be quite useful. Consider this ksh snippet:

for i in $(pgrep cache) ; do
  // do some commands here
done

In a Windows environment, people have gotten used to just picking up any device (whether it is a CDROM, PCMCIA card, printer, or modem) and expecting it to work. While the concept of “plug and play” is not yet here, the fact is that when installed everything should work with Windows.

And it isn’t just Windows - other large commercial vendors have access that you and I do not. Apple comes to mind - MacOS X has much better support than Linux or FreeBSD, for example.

Open source operating systems rely on hardware manufacturers to make the details of their hardware available for free or low cost - and then for someone to come and craft the software drivers needed. Usually, the latter is not a big problem; the former is.

The problem can be deeper than that as well, since the label on the product is not the same as the label on the internal devices: so it is not possible to simply look for a brand and use it. Worse, manufacturers can change hardware vendors on the same model, so that discerning which model is which can occasionally be difficult - the revision becomes the determining factor as to which hardware was used.

First thing is to determine which devices are supported. Start with the release documents for the operating system and look for supported hardware. Another place to look is the man pages (or other documentation) for the drivers. Keep the list of specific hardware handy, on another screen or printed out.

Then, look for the device (or devices) at your chosen store. Write down what you find, even if it isn’t listed (and even if it is). Then look up the device on the Internet using your desired search engine. Pay attention to mailing list threads and watch what sort of trouble people had (or didn’t have). The mailing list threads should also help you identify the hardware sources used in otherwise unidentified products, and also will keep you up to date on people’s experiences.

Once you have a product chosen, given few problems on mailing lists and a well-supported and identified hardware chip set, then buy it. However, for best results, make sure there is a good return policy in case it doesn’t work - otherwise, you are taking a chance (albeit a very small one if you’ve done your homework).

I’ve gone through this with several wireless cards under FreeBSD. The first was the Netgear MA401 (researched as given here) - worked flawlessly until it was smushed. The second I received as a bonus with my laptop purchase was a Zonet 1502 (definitely a mistake, but it came with the laptop). I’m sure the Zonet works fine under Windows (and probably OpenBSD: they reverse engineered the driver). Currently, I’ve added a TP-Link TL-WN610G (again researched as described here) - also working flawlessly.

This isn’t just good practice for wireless cards, though - networking cards, mice, video - all benefit from this research. Even laptops: when I bought my laptop, I researched the two brands that were available (for sale used at my favorite local used computer store) and found that one had lots of difficulties and the other did not. Guess which one I bought?

Gary Sims wrote an excellent and in-depth review of FreeNAS (a FreeBSD-based network attached storage system). His article details his experiences with FreeNAS, how it worked, where it (or he) failed, and other tips and tricks that he found as he went.

While FreeNAS appears to be the most popular (at least according to Google!) there are others out there, including OpenFiler (which is Linux-based).

A NAS basically is a dedicated file server that provides many different protocols to the clients and acts as an appliance. In some ways, this is no different than the historical file server - but in these cases, the NAS device is much more a turnkey solution with no other purpose. Many NAS systems support Windows file sharing, Macintosh file sharing, NFS, and a plethora of other protocols - all in order to make files available as much as possible. OpenFiler is one of these.

NAS devices were traditionally contrasted against SANs (storage area networks). The NAS provided a filesystem on the network; the SAN provides a block device on the network. This apparent sharp division of purposes does not exist in reality: some NAS systems also provide SAN resources as well.

Which - FreeNAS or OpenFiler - would I use? Can’t say - OpenFiler caught my eye first, but FreeNAS has the FreeBSD base. I’m liable to try both of them one of these days.