Living without Windows!by Jos Visser
Part 3a: I go to a customer
I went to a customer for some on site consultancy work. At this particular customer I share a room with about 8 co-workers from the customer, from Hewlett-Packard, from CMG and from Oracle. The customer is a fairly traditional IBM mainframe shop who run Windows on their desktops (WfW and NTW) and OS/2 and NT on their servers. For some of their most stategic projects they are currently looking at Internet and UNIX technology, which is where I come into the picture. The people I work with mostly come from an IBM mainframe background who are now being exposed to the the True Path.
Over the last year, I have been very busy spreading the UNIX gospel, leaving no chance unused to trumpet the many advantages of UNIX. My co-workers have been quite receptive to this, and once when I returned from a holiday I was surprised to find that all of them had installed Red Hat Linux 5.1 on a free partition of their desktop computers. I reckon the local IT support group will be pretty surpised if they ever have to retake control of these computers!
Before going off to SANE'98 I had shared some of my intentions with them about buying ApplixWare and converting to Linux, so when I got back that Tuesday I found a rather inquisitive lot that were anxious to see Linux and ApplixWare at work. As I did the day before, I eagerly showed off with SuSE Linux 5.3, XFree86 and ApplixWare. They were favourably impressed!
Ok, time to get to work: I found a spare network cable and hooked my laptop (Jadzia) to the customer LAN. Only the day before I had created a small script ("net") that allowed me to easily change the networking parameters according to wherever I happened to be. I was about to add the customer site to this script when it dawned on me that this customer uses DHCP to assign IP configurations to computers in the network! Hmmm, my next challenge appeared: trying to extend the "net" script with DHCP client capabilities.
As you are probably well aware of, the Dynamic Host Configuration Protocol (DHCP for short) is a protocol for assigning TCP/IP configurations to computers and other network devices. Apart from an IP address and a subnet mask, the DHCP server can also send parameters like the subnet default gateway and the IP address of a preferred name server. DHCP is largely derived from BOOTP; the main difference is that the DHCP server automatically deassigns previously handed out IP addresses when it "sees" that the DHCP client is no longer there. As such, the DHCP server frees the system administrator from the tedious task of keeping track which IP addresses are currently allocated to whom.
To allow for the automatic assignment and freeing of IP addresses, the DHCP server regularly contacts every client to see if it is still there. If the server has not been able to contact the client for a set amount of time, it frees the IP address and reassigns it to any clients requesting a new (or extra) IP address. Obviously, to avoid duplicate IP addresses on the network it is of the utmost importance that the clients respond the the server's inquiries.
I had not come across DHCP client functionality in my SuSE Linux system, so I reckoned that I had to find an extra package and install it on my system.
At this particular customer, I also have a desktop PC running Windows NT Workstation at my disposal. Using this workstation I fired up a browser and went on the lookout for DHCP client software for Linux. After ample searches (mainly through Yahoo), I came across the "dhcpcd" package. It seemed that this was a DHCP client daemon (hence the name) that could request a DHCP configuration and maintain it through responding to the DCHP server's requests. However, my customer's web proxies do not allow any binary downloads, so I could not download the package. But hey, they do not call me "the Happy Hacker" for nothing! I was not beaten yet. I decided to configure Jadzia to dial out to my own ISP and download the "dhcpcd" package through that dial-up link.
Jadzia also contains a Psion Gold Card PCMCIA fax/modem. I had used it extensively in my previous NT life to dial-out to ISP's so that I could download software and/or read my electronic mail. I hadn't used the modem yet under Linux so I had to go about and configure it from scratch. When my system boots the Linux PCMCIA card manager flawlessly recognises the modem and assigns it to serial device 2 ("/dev/ttyS2"). Dialing out in UNIX usually means setting up a serial connection, authenticating using userid/password and then configuring a network interface on it. Although my ISP (UUNET) allows all of SLIP, CSLIP and PPP I have been using PPP almost exclusively for the last couple of years because the negotiation of the IP configuration of the dial-out interface is included in the protocol. Completely in line with this, I decided to set up a dial-out PPP connection.
Doing so in UNIX requires that you use a dial-out program that opens the modem, establishes a serial connection, authenticates to the ISP, negotiates a TCP/IP connection and then configures a UNIX network interface on the serial port. When I first "did" Linux in 1994 I used to use the Dial-up IP program DIP to achieve this. It only seemed natural to use DIP again. I had foreseen that this day would come when I initially installed SuSE Linux and I had taken care to select DIP from the list of available packages, so it was readily available. When using DIP for dial-out connections you have to write a DIP script that sets up the modem, dials out and then starts the negotiation with your ISP's dial-in server. The exact format of this negotiation depends on your ISP so some advanced DIP customisation is usually called for. Fortunately there is a plenty supply of examples in the manual pages and in the Linux documentation directories ("/usr/doc"). So I happily hacked away at a script that would do the trick for me.
However, whatever I attempted, DIP refused to set up a PPP connection for me :-(. The first few times there were problems with the script but even once I had corrected these the connection still did not materialise. DIP dialed-out, negotiated with my ISP's server, but then, ...... nothing. No connection! Hmmm, this requires some thinking, and perhaps more study of the relevant "HOWTO" documents and manual pages. It took only a short period for me to realise that what I was missing was PPP support in the kernel. Obviously the standard Linux kernel that I ran had no support for PPP. This meant a kernel reconfiguration, recompile and a system reboot. I was not ready for this right now.
I was still planning on downloading and installing the DHCP client software though, so I decided to do it the old fashioned way: through a Z-modem download. Although "cu" is my favourite serial terminal emulator program, it does not support Z-modem, so "cu" would not do right now. Instead, I started "minicom", a full fledged terminal emulator program. Again I dialed out to my ISP, but this time I opted for a "normal" serial terminal session, which patches you through to "solair1.inter.nl.net", a UUNET system running SunOS 4.1.something. From "solair1" I used FTP to download a DHCP package to my home directory from somewhere. Once it had fully arrived, I used the "sz" command to send the package to my local system. Minicom recognises when a Z-modem download starts and it picked up the package and stored it in the assigned download directory.
However, when I installed the package (with the Red Hat Package Manager, RPM) I was surely disappointed: instead of a DHCP client package I had picked up a DHCP server package!
Well, losses all around then! No PPP connection, no DHCP client package, and hence, no network connection to the customer's machines. Now was however not the right time to solve all these problems. It was time to get some real work done so I shifted my attention to the problems at hand and pretty soon I was completely engulfed in a complex package selection process.....