Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up


Taking It on the Run

Have laptop, will travel. Here's how to make life easier for a nomadic system that is occasionally connected to a network

By Jan Säll

The creation of small-in-size but big--as in powerful--portable computers has made it relatively easy to run a Unix system on today's laptops. With the good color screens and big disks, you can actually take a full Unix system with all the development utilities, and even the X Window System, with you wherever you go without compromise (see ``Good to Go!,'' a review of laptops running Unix in the January 1994 issue of Open Computing print magazine (article not available on this Web site).

One problem, however, is that most new portable computers have a docking station, which allows you to take advantage of add-ons, such as I/O cards, when your system is docked. But after setting your system up to work the way you want in the office, you don't want to lose that time investment when you hit the road. You don't want to hassle with modifying your system settings each time you dock.

One way to easily reconfigure the portable system so it can work with or without a network connection is to make use of Unix's run levels. Run levels determine which mode your Unix system is running in, for example single-user, multiuser, or maintenance mode. (Run levels were most recently covered in the December 1993 UnixWorld print magazine Tutorial, ``Setting Up Your System at Start-Up.''), not yet available on the Web site.

In my setup, I use run level 2 for standalone work outside the office with TCP/IP started just on the loopback driver to get my X server up and running. When I am in the office, I have a docking station with Ethernet cards in it to get me connected to the company network. I then use run level 3 to get TCP/IP to run over the Ethernet card. I have also moved the start-up of the Network File System (NFS) from run level 2 to 3, basically to avoid too many processes on the system when running standalone. Besides, what's the use for NFS when you're running standalone?

My portable system is an AST Power Exec 4/25 ColorPlus with 8 megabytes of RAM and loaded with The Santa Cruz Operation Inc.'s Unix. This version of SCO resembles System V Release 4 Unix versions, such as Solaris 2.3 or Unixware, in the use of run levels, although some of the commands I will describe differ from SVR4.

Because the Unix system is designed to be up and running all the time, much of the cleaning up is done by cron during the night. The Unix system produces a lot of log files during start-up and shutdown as well as during running of the system. This operation is not a problem in a stationary environment, but when used on a portable system that is brought up and down several times a day, it is not so good. I therefore added some cleaning up when shutting down the system.

Network Configuration

We will use SCO's netconfig to configure the network. Because this command is specific to SCO, some explanation is necessary for those unfamiliar with it. The netconfig command configures and enables network products. Listing 1 shows the standard configured chain--or group of networking products (TCP/IP stack, network cards, and so on) that work together--when TCP/IP and NFS are configured.

The netconfig command guides a user through the process of installing a network part--for instance, the TCP/IP stack--and by asking questions, it will set up a standard configuration that works. Of course, if you want a perfectly tuned system or some special setup, you need to get in and edit the configuration files (Listing 2 shows how netconfig works).

This standard configuration also means that when you want to change or remove a chain, it can be done with one command and without risk of forgetting anything.

Though my example will be targeted for SCO systems, and all examples will be from an SCO system, the same idea can be used on other systems; however, you'll have to check out the different command and locations for the system and configuration files.

Where to Run to?

The Unix system provides different levels of system readiness, called run levels. The levels, described below, include system shutdown, single-user state, and multiuser mode, and can be configured to do other things.

  • Run level 0: This level puts the system in shutdown state. Normally you specify this level with the shutdown command (shutdown -i0).
  • Run level 1: Also known as maintenance mode or single-user mode, you start in this mode if--on SCO--you supply the root password when the system starts up.
  • Run level 2: Normally called multiuser mode, it is the normal run level for an SCO system.
  • Run level 3: This run level is not used normally on an SCO system, but we will use it to get the portable computer to access the network card. Despite the fact that it is not customary to use it, the manual says that this level starts the remote file-sharing processes and daemons.
  • Run level 4: This level can be used as a test or as an alternative multiuser environment. It is hardly ever used.
  • Run level 5: The manual says that this level stops the Unix system and goes to the firmware monitor. I've not seen it used on any SCO system.
  • Run level 6: This run level reboots the system. I use it when I have to reboot a system after I have made changes to it over the modem or TCP/IP. It should bring the system back to the state defined by the initdefault entry in /etc/inittab, which I have often set to run level 2 to get the system up to multiuser mode directly.

There is one strange thing about the SCO setup. Despite the fact that SCO doesn't use run level 3 as remote file sharing, they ship the system well adopted to do so. The /etc/rc3 start-up file and the /etc/rc3.d directory exist as well as the entry in inittab to start it all. It seems that SCO has made it easy to use it this way. We can just wonder why.

Safety First

When we are about to modify the start-up activity of the system and there is a risk that we will make an error, it's very important to have an emergency boot floppy set. Make the emergency boot floppy using the command line ``mkdev fd'' (for SCO only).

After you've taken care of the safety aspects, the next thing to do is get the system up and running on its own without any fancy things such as Ethernet cards and so on. Install the system in the standard way to get everything working. If you, like myself, are installing an SCO Open Server Enterprise System, the standard configuration is designed for a lot of terminals and you can get better performance if you turn down some of the kernel tables. I gained at least one megabyte of memory by doing this step. I will probably want the X server-X desktop to work (what else would you have a portable Unix system for?), which means you have to have TCP/IP up and running (over the loopback driver) even if you are running totally standalone. The standard installation does this part.

The standard installation also installs NFS so it starts up when the system goes into multiuser mode (level 2). You can save some time in the start-up processes and some memory and processes by moving NFS to level 3. This task is accomplished by moving /etc/rc2.d/S89nfs to /etc/rc3.d (see Listing 3).

Setting Up Run Level

After moving NFS start-up to level 3, there are some other files that are involved in setting up level 3. The first version is the streams and socket configuration file /etc/strcf. Because the start file /etc/2.d/S86tcp uses this file, we need two versions. The first one is the current one, which we will use when we have no network card other than the loopback driver. We therefore copy it to the second file, strcf.nonet (see Listing 3).

The other files that are involved are linked together, so we should be careful to preserve this connection in an orderly manner. The program netconfig uses /etc/tcp to change the configuration. The /etc/tcp file is then linked to /etc/rc2.d/S85tcp. To get all things working in level 3, we need to preserve this configuration. Move /etc/rc2.d/S85tcp to /etc/rc3.d/S85tcp and keep the link. We then want a link to /etc/rc3.d/K85tcp because the TCP/IP should be shut down before we initialize TCP/IP with the new card (Listing 4).

We need to make a small adjustment to either /etc/tcp or /etc/rc3.d/S85tcp (the two files are now linked together). It is a check that SCO does to determine if we are coming from start-up to level 2 or not. Because we need this file to work from boot to level 2, from level 2 to 3, and from level 3 to 2, we need to comment out 3 lines. It should be lines 73 to 75 (Listing 5). By doing this step now, we will get these changes copied to the other copies that we now should create.

To get TCP/IP to start locally when we enter run level 2, we need copies of the start files in /etc/rc2.d. It's important that we are using copies, because we don't want future netconfig changes to change run level 2. First copy /etc/rc3.d/S85tcp to /etc/rc.2 and link /etc/rc2.d/S86tcp to /etc/rc2.d/K85tcp because we want TCP/IP to be stopped when we go from run level 3 to 2. Also to stop NFS before we stop TCP/IP, we link /etc/rc3.d/S89nfs to /etc/rc2.d/K79nfs (Listing 6).

What's left now is to get the different streams configuration files to be used in the different start-up files--remember that these files were copied, not linked. We therefore edit /etc/rc2.d/S85tcp to use /etc/strcf.nonet instead of /etc/strcf. The command slink is near line 100 in the file (Listing 7).

We now run netconfig. It will edit /etc/strcf and our configuration will use it when we go to run level 3. It will also edit /etc/tcpip and /etc/nfs. As far as I know, all netconfig programs use these files and not the files in the rc2.d directory. The way that we kept the links makes changes appear to level 3 and not level 2; level 2 is purely standalone and needs no configuration.

Testing, Testing...

I start out by testing that we can get up to multiuser mode (run level 2). If this configuration works, we can start to use netconfig to add a network card and test run level 3.

When we start up the system in run level 2, we start up TCP/IP with just the local loopback driver. When we start up run level 3, the old TCP/IP system is stopped, and then we start it up again but with the network card enabled. After that NFS is started. If you have other software that depends on TCP/IP, you should arrange so it is first stopped and then started again if it cannot handle a stop. SCO-Login handles it fine.

When we stop the system, we enter init 0 and all processes are stopped in the usual way.

It is important that we start up run level 2 first, so that all processes needed for the multiuser environment will get started, and then start up run level 3.

Clean Up

Now we basically have a running portable Unix system, but one thing remains. Because Unix is designed to be up and running for a long time each time it gets started, a lot of log files are created during system start. Also because Unix systems would normally be up and working during the night, a lot of cleaning is scheduled by cron during night hours. In a portable system, which is usually up and running only when we are using it and will be rebooted a lot of times, this scheme won't work well.

The plan I use is a script that is started late in the shutdown process, just before the system is halted and after all other things are stopped.

The way to get this effect is to make an ``S'' script in the /etc/rc0.d directory. Remember that the ``K'' scripts are run first and the ``S'' scripts second. Normally there are no ``S'' scripts in /etc/rc0.d because there is normally nothing running when we halt the system. The script (Listing 8) runs rather quickly (less than 30 seconds on my 25-MHz 486 system), so there is no performance problem.

The S99cleanup file does the following: runs uudemon.clean to clean up all UUCP logs and directories, moves /usr/adm/messages to messages.old and truncates the real one, moves /usr/adm/sulog to sulog.old and truncates the real one, and moves /etc/wtmp to /etc/wtmp.old and truncates the real one.

This clean-up script seems to clean up most of the files on my system.

Timing Is Everything

Because it's a bit new to run Unix on a small PC designed to run DOS, I should mention the amount of time taken to start and stop the system. On my system, it takes 115 seconds to start up the system from boot prompt (the SCO boot manager that you can use to select a different operating system to boot) to multiuser mode (run level 2). To change from run level 2 to 3 takes about 70 seconds.

To shut down the system from multiuser mode (run level 2) takes 80 seconds, and if we shut down directly from run level 3, it takes 110 seconds.

The new more powerful portables can be a real benefit to those who have to take their work with them. I hope this tutorial has put you on the right track to getting your laptop system up and running at work and on the road.[]

Print This Page


e-mail Send as e-mail

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers