UNIX Administratosphere

How much memory is in this machine?

It would seem that answering this question ought to be easy; it is - but every system has the answer in a different place. Most put an answer of some sort into kernel messages reported by dmesg (AIX apparently does not).

Most systems have a program for system inventory which reports a variety of things, including memory.

Rather than go into great detail about each one, we’ll just put these out there for all of you to reference. Each environment has multiple commands that give available memory; each command is listed below.

Without further ado, here are a few answers to this burning question:

Solaris

1. dmesg | grep mem
2. prtdiag | grep Memory
3. prtconf -v | grep Memory

AIX

1. bootinfo -r
2. lsattr -E1 sys0 -a realmem
3. getconf REAL_MEMORY

HPUX

1. dmesg | grep Physical
2. /opt/ignite/bin/print_manifest | grep Memory
3. machinfo | grep Memory

Linux

1. dmesg | grep Memory
2. grep -i memtotal /proc/meminfo
3. free

OpenVMS

1. show mem /page

Update:

FreeBSD

1. dmesg | grep memory
2. grep memory /var/run/dmesg.boot
3. sysctl -a | grep mem

When the system starts, it sometimes will fail to load the kernel - or perhaps there are other adjustments that must be made. It pays, thus, to know exactly how the system gets to the point of loading the kernel - even before initd runs or swapper runs.

It can also be a benefit in trying to get the system to use a serial console or to provide splash screens throughout.

In a FreeBSD/x86 system, the process goes something like this:

1. The system turns on, and the BIOS begins processing and preparing hardware for the boot up. Most Intel machines do not provide a serial port view of the BIOS boot process.
2. The system loads the first block (the master boot record, or MBR) from disk.
3. The disk loader then loads the rest of the loader. It is at this point that the first screen appears. This loader may be GRUB or the FreeBSD loader.
4. The next step is normally to load the FreeBSD boot loader (which is different from the FreeBSD MBR loader). The boot loader provides a FORTH-based environment for modifying the boot sequence, and so on.
5. The final step is to load the kernel and to start processing. GRUB could load the kernel directly, but using the boot loader provides access to the prompt and to modify the boot process.

GRUB can be configured for a serial port, as can the FreeBSD kernel and loader. Likewise, the splash screens can be set here as well.

It is also possible that any of these items may fail; knowledge of the others will provide for methods of recovery.

If GRUB fails to load the loader (or kernel) properly, it can be adjusted interactively to load the right loader with the right parameters.

If the FreeBSD boot loader does not load the kernel properly (or is misconfigured), it can be adjusted by pressing a key and using the FORTH prompt to manipulate the loaded kernel - including loading a different kernel, changing parameters, loading modules, and so forth.

The best documentation out there on OPIE focuses on using OPIE with FreeBSD. FreeBSD comes with OPIE as part of the core, and it works beautifully.

The FreeBSD Handbook contains a section on One-time Passwords (14.5) which discusses using OPIE, and how to use utilities associated with it.

The esteemed Dru Lavigne wrote excellent articles as well (way back in February of 2003!) about making OTP work in FreeBSD. The first was One-Time Passwords, and followed by PAM (which used OPIE access as an example).

There is no installation required, as all the appropriate bits already exist in the base install. To get started, follow this example with your own password:

$ opiepasswd -c
Only use this method from the console: NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
 
ID dgd OTP key is 499 xf4915
OTTO BRIM CAT PEN FAD PREEN
$

Now everything is set. However, the first password requested will be number 498: so let’s generate the key so we can record it:

$ opiekey 499 xf4915
Using the MD5 algorithm to compute response.
Reminder: Don’t use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
498: SLIP MAX ROT BLIP PIP FLIT
$

Note that this second step does not have to be done on the same machine. You do need to have your count (499 in the example) and the seed (xf4915 in the example). Combined with your secret password, you can generate your next password or passwords using any valid OTP password calculator.

Dru’s article on PAM discusses the conversion from Linux PAM to OpenPAM, and other things relevant to the introduction of FreeBSD 5.0. However, now with FreeBSD 6.3 out and FreeBSD 7 coming, most of what she discussed then is now well-tested and preconfigured. OPIE is built into PAM as she suggests (within the file /etc/pam.d/system file).

Now if you want to be forced to log in with OTP, touch the file .opiealways (note the leading dot) file in your home directory and it will be so.

There was also an interview done in June of 2007 in BSDTalk #117 (audio) which discussed OTP in depth. One interesting thing to note: FreeBSD uses OPIE, whereas NetBSD and OpenBSD both use S/Key for their implementations.

Installing GRUB onto a FreeBSD system isn’t that hard - if you know how.

If you just run grub-install as root - which should normally work - you might see an error like this:

# grub-install hd0

GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> root (hd0,1,a)
Filesystem type is ufs2, partition type 0xa5
grub> setup –stage2=/boot/grub/stage2 –prefix=/boot/grub (hd0)
Checking if “/boot/grub/stage1″ exists… yes
Checking if “/boot/grub/stage2″ exists… yes
Checking if “/boot/grub/ufs2_stage1_5″ exists… yes
Running “embed /boot/grub/ufs2_stage1_5 (hd0)”… failed (this is not fatal)
Running “embed /boot/grub/ufs2_stage1_5 (hd0,1,a)”… failed (this is not fatal)
Running “install –stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) /boot/grub/stage2 p /boot/grub/menu.lst “… failed

Error 29: Disk write error
grub> quit

The first step is to set a FreeBSD kernel variable:

sysctl kern.geom.debugflags=16

This will make the master boot record (MBR) writable, which is normally where the boot record is installed. Unless you do this, you will receive the error above.

Once the variable is set, the program grub-install should work fine with your chosen drive. The menu is in /boot/grub/menu.lst; here is a starter example for FreeBSD:

title FreeBSD
root (hd0,0,a)
kernel /boot/loader

The loader is the “kernel” in this case, as it will load the FreeBSD kernel anyway and it allows you the ability to drop into the boot console if you want.

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.

The ports tree is vaguely like a package system (like RPM). It is just a large number of files who just define changes to the source code of a particular “port”, where to get the port’s source code from, and options that can be set or unset during compilation. Gentoo took direct inspiration from the FreeBSD ports tree for their portage system.

Prior to version FreeBSD 6.x, the ports tree was kept up-to-date with the cvsup command. This is now being phased out in favor of a utility called portsnap. This portsnap utility aims to make it much easier to maintain an up-to-date ports tree, and it seems to be true. If you are using a version of FreeBSD prior to 6.x, the portsnap utility will have to be loaded from ports before you can use it.

To start maintaining a port with portsnap:

portsnap fetch extract

To update the ports tree:

portsnap fetch update

Another common utility used to manage ports is the portupgrade command. However, portupgrade is a port, so you will have to install it first. The portupgrade utility will help you maintain your system and keep installed ports current. There is also the portversion command, included with portupgrade, which will list installed ports and their status relative to the current port (newer, older, equivalent, etc.).

To keep the portupgrade database valid and current, use this command on a regular basis (perhaps from cron):

portsdb -Fu

This will fetch the INDEX file from upstream and then recreate the local database file used by portupgrade. A (much slower) alternative is to create the INDEX file from the local ports:

portsdb -Uu

However, with a decent internet connection the -F option will be faster.

On occasion, the portupgrade database may become corrupted, or their may be unresolvable conflicts between the ports tree and an installed port. To resolve these issues, issue this command:

pkgdb -F

This will check the database and ask you to resolve any problems that may occur. Daniel Reinholz has an excellent article on how to understand and use pkgdb -F available.

The portsclean command cleans out all of the detritus that gets left behind during ports installation at times. The best command is probably:

portsclean -CD

This will remove all working directories left in the ports tree (the -C option specifies this) and will remove archives from the distfiles directory (the -D option) which are not in the ports tree.

With this combination of tools, I would suggest the following crontab entries (assuming a decently fast always-on internet connection):

1 3 * * * portsclean -CD
2 4 * * * portsnap fetch update && pkgdb -u

This will keep the ports tree updated nightly, as well as the portupgrade database.

There is a lot more information available out there. Papa Mike IT Services has not one but two excellent articles: one on updating and upgrading ports, and one on basic port management. Be sure to read the articles all the way through and don’t miss the links at the bottom.

Over at My Digital Life, there is an excellent tutorial on using portsnap. It covers not only the basics, but all the rest as well.

If you are looking for ports online, you can get information from FreshPorts or directly from FreeBSD itself. FreshPorts maintains a constant list of current ports and lists the recent additions or updates almost in realtime, and have a feed that will keep you updated. The FreeBSD ports page is mainly a search interface to the ports, as well as some documentation on ports. The FreeBSD Handbook (in Chapter 4) gives an account of how to use and comprehend ports, but a fuller picture may be had be reading the other articles listed here (at least until portsnap is introduced into the Handbook).

Things are working well with the combination of the new FreeBSD 6.3 and the Compaq Armada E500. The machine has a great feel to it, and despite the huge applications of today, 128M can still be used for a KDE environment.

There are a number of nice features, including a ton of connectors (10BaseT, WinModem, USB, serial, parallel, PS/2, PCMCIA). The machine just keeps going, though I have had a few (few!) lockups (normally with Amarok and something else running). With the appropriate tweaks, the KDE desktop can be as polished as any from Red Hat or Novell.

Some of the things I did:

• Replace the shutdown picture with something else; the picture of the dragon was too smarmy.
• Replace the background (of course!) - personalization to the max.
• Switch to the “Macintosh” version of menu layout; it’s the most user-friendly.
• Load KDM from ports, then activate and theme it.
• Load a splash screen for the boot loader
• Switch the boot loader to grub then use a splash screen to start it off.
• Configure the special buttons to work.
• Change the KDE menu for something easier to use (such as TastyMenu or KBFX).

When all of these are combined, the environment is very slick and professional. It still wants more than 128M though.

One pet peeve of mine I might mention with regards to menus (such as KMenu or KBFX): menus should respond instantly!! I absolutely despise hiccups and watch cursors because the menu is loading its stuff. It should just pop! into place, not thrash the hard disk. Maybe one day…

What was the best part of this? I learned a ton about themes, X keys, configuring KDM, configuring the boot loader, and using grub. And learning is the best part, right?

FreeBSD is a nice environment, and I tend to gravitate to it (though I love Linux and Solaris as well). It does tend to work better in smaller environments than either Linux or Solaris.

There was recently a discussion of FreeBSD on the EeePC; it appears that while some items do not work (to be expected) it runs nicely and works nicely (including wireless). There was recently posted a simple introductory article which also refers to a comprehensive article on FreeBSD on the EeePC.

There was also an article (with followup) about running FreeBSD on the fitPC; in contrast to the EeePC, this sounds like it is not as good. However, the fitPC has less memory and a slower processor; it is unclear as to whether the processor is “fast enough” (I still use Pentium IIIs for my use!) or if it really is slow. It is, however, very surprising that the default Ubuntu install would be a graphical installation that swaps badly and comes without SSH.

The fitPC forums have a nice Linux on fitPC section, which also includes the BSDs as well. The biggest problem with FreeBSD seems to be its lack of a USB CDROM driver in the base kernel; however, apparently OpenBSD loads fine. Since the system has only 256M of memory, it perhaps should not be swamped with heavy desktop applications.

Just after installing 6.3-RC2, I discovered that 6.3 was officially released!

This didn’t take much work to update to. The basic steps were:

freebsd-update upgrade
freebsd-update install

Then - after a reboot (for kernel updates, I presume) another:

freebsd-update install

Relatively painless, throughout.

Then, continuing my install over the weekend, there were a few niggling things to fix. First off, the buttons up on the top of the keyboard didn’t work (no surprise there). Using the xev utility helps to pin down the actual keycodes for these keys, then use the xmodmap tool to add the appropriate actions to the keys. In my case, xev reported that the keys left to right were:

• 163 (info key)
• 142 (home key)
• 154 (search key)
• 143 (mail key)

These can be configured using xmodmap and a .Xmodmap file configured this way:

keycode 163 = Help
keycode 142 = XF86HomePage
keycode 154 = XF86Search
keycode 143 = XF86Mail

The values on the right (Help, XF86HomePage, XF86Search, XF86Mail) show their XFree86 heritage, but apparently do not change for X.org. These are activated by using the command:

xmodmap .Xmodmap

A good place for this line would be in the .xinitrc. However, once this is set, it is still necessary to tie applications to the shortcuts listed. In KDE, this is done in the Keyboard Shortcuts section of the Regional and Accessibility pane in Settings. In this dialog, select the “Command Shortcuts” tab, then the application you desire to use. For example, “Find Files/Folders” could be attached to the shortcut XF86Search. Once the xmodmap has been modified using the command above, then click on the Custom radio button, and click the shortcut button. Press the actual shortcut button to define the shortcut for the application.

Do this for all four buttons, and all will be well.

Then there was the problem of the mouse not being operational when waking up from a suspend. Turns out that the moused( daemon is the culprit. Sending a HUP signal to the daemon fixes it, but having to do this all the time is not a desirable outcome. The utility acpiconf( describes how it uses /etc/rc.suspend and /etc/rc.resume before and after suspending the system. I placed the command:

pkill -HUP moused

into this script, but I don’t yet know if it is truly having the desired effect or if other things are causing failures.

Another thing: the CD player would not play CDs in Amarok. Apparently, this is due to HAL and DBUS not being available. HAL depends on DBUS, so both are necessary. The following packages were needed:

hal-0.5.8.20070909
dbus-1.0.2_2
dbus-glib-0.74
dbus-qt3-0.70_1

I don’t know that all the dbus packages are necessary, but I decided not to chance it. Of course, dbus is part of GNOME, but whatever. Once these packages are installed, add the following to the startup configuration in /etc/rc.conf:

hald_enable="YES"
dbus_enable=”YES”

Next time the system boots, these daemons will start.

Also, up until this point X.org had to be started using startx as a normal user. However, adding the login screen isn’t difficult. Edit the /etc/ttys file. In this file, there will be a line that specifies the command xdm.

Since kdm (the KDE display manager, the login screen) is actually a reworked xdm, switching one for the other is smooth and clean. Replace the xdm setting with /usr/local/bin/kdm (keeping the -nodaemon option) and set the tty to “on” (instead of “off”). Then the next time the system starts (or the ttys file is read) a login screen will activate on ttyv8 (if your file is like mine).