DN Print Magazine BSD News BSD Mall BSD Support Source Wars Join Us

Mirrors Primary (US) Issues June 2001

July 2001 Get BSD Contact Us Search BSD FAQ New to BSD? DN Print Magazine BSD News BSD Mall BSD Support Source Wars Join Us

T H I S M O N T H ' S F E A T U R E S From the Editor A Tour through the NetBSD Documentation - Part IV: Usenix Report Loose Odds & Ends by Gregory Sutter by Hubert Feyrer BSD and more at USENIX 2001 This is the last part of our tour though the NetBSD documentation. Besides the places mentioned in the previous parts of this series, there are a few other places Get BSD Stuff that should not go unmentioned here, and that have docs on various things in NetBSD. This last part of the tour goes through a few of them. Read More

Das Blinkenlights for BSD by Don Wilde

Those of you who have attempted to use BSD for hardware Search control know that this is one area where the OS isn't very cooperative. Programs that link to hardware control Search assembly language code have a nasty way of dumping core as soon as you make the call. The process of writing drivers Advanced is very involved and isn't very well documented. My attempts at activating the driver-generator scripts in or Search all Daemon /usr/share/examples/drivers resulted in a whole bunch of News fatal errors and no end in sight. There's a simple little back-door trick that's really helpful. There’s a simple little back-door trick that’s really helpful. It’s called /dev/io. It’s not exactly what you want to use for Daily Daemon News time-critical code, but it works great for applications like mine. I needed to make three bicolor LEDs work as OS X boosts Apple’s indicators for an embedded PicoBSD system, and I didn’t security focus have a lot of time. Read More How I BSDed My iBook Apple releases AppleWorks 6.2 for OS X KWord 1.1beta3 review NetBSD 1.5.1 The road from 1981’s IBM by Hubert Feyrer PC to today’s systems--and all the revolutions, NetBSD 1.5.1 was released in late June 2001 after an evolutions, and fumbles in extended period that was used for testing, enhancing the between. system, and of course bugfixing. NetBSD 1.5.1 is the first SAMBA remote root maintenance release of the NetBSD 1.5 branch, and as such exploit it includes few new features, and mostly improvements Microsoft Slams Open over the NetBSD 1.5 release. Binary compatibility with 1.5 Source, Yet Again is retained, so a full or partial upgrade from 1.5 to 1.5.1 is July edition of not a problem. Read More DæmonNews is out IPFilter now with a BSD license? R E G U L A R C O L U M N S Controlling User Logins

BSD Support Forum Adventures in BSD by Michael Josefsson Permission problem within KDE 2? i think This months adventure article goes under the "Why I chose Is XFree86 4.1.0-client port FreeBSD" category. "I had started to experiment with broken? Linux, a Unix-like system but felt very little enthusiasm for 3 (or two) subnets, one it. Because of an earlier experience with HP-UX, I was BSD router? under the impression that Unix only represented an Sound Blaster Live & extremely complicated way of doing things, and therefor, FreeBSD Unix was ruled out. At this time, there were executables for Who does the OpenBSD FreeBSD available, and not knowing much about FreeBSD, artwork? I made an FTP install of 2.1.7-STABLE. The DES-client ran as expected. I figured out nice commands; ’kill -STOP’, ’kill -CONT’ and that putting an ampersand (&) after the Source Wars command line ran a job in the background. Cool! I could Week 22 manage every aspect of the program. A taste of a new world! This was very enticing." Read More

Hey! Mister Answerman by Todd Whitesel

This month is the special all-reader issue! This month’s mailbag was dominated by follow-ups to This month’s mailbag was dominated by follow-ups to previous questions in this months Answerman column. Daemon News Mall - Read More Summer Specials NetBSD 1.5.1 Pre-Order $23.95 Dæmons Advocate FreeBSD 4.3 NOW by Wes Peters SHIPPING $35 3Ware Escalade RAID I had received a single, cryptic email from someone at that Controller $144 firm a couple of weeks before, stating simply that he could BorderWare Secure Server introduce me to an offer that could be worth "500K." Read R1000 $2295 More Daemon Certified Systems From the Daemon News $1097 Need Reseller Pricing? Go to Cylogistics!

Miscellaneous Credits The hard-working crew Tarball Download a tar.gz version of this issue

BSD and USENIX 2001

Gregory Sutter

For the past week, I've been busy geeking out at the USENIX Annual Technical Conference, this year held in Boston, Massachusetts, US. The conference itself had its ups and downs, but fortunately, the technical sessions were very good, and meeting in person was definitely of large benefit for the BSD teams. But I'm getting ahead of myself. I'll go through the week in rough chronological order, and hopefully paint a picture of what it's like to attend a large technical conference.

Arrival and Accommodations

It's often stated that San Francisco is the most expensive city in the United States. I discovered that that's not true. The conference hotel cost around $169 per room per night, and the other accommodations in the area didn't go for much less than that. As a currently unemployed geek, I couldn't afford to go that route, so I checked into a conveniently-located hostel. (It's still the most expensive hostel I've ever encountered at $30 per night.) Later in the week, I was able to find some friends (and BSD developers) that were willing to let me share their rooms (Thanks, Phil, David, and Murray!), so I was even closer to the action--and to the air-conditioning. Overall, the cost of lodging and food was extremely high, which stretched attendee's budgets even farther than usual, and probably made it impossible for some to attend the conference.

Tutorials

The tutorials are full-day seminars on various subjects, varying widely in diversity from studies of cryptographic algorithms to basic (people) management techniques. The management techniques class was educational, and turned out to be basically an effective communications class for geeks. The "Topics for System Administrators" was okay but too low-level for me (I am a mid-level systems administrator), and the class on system and network performance tuning turned out to be very Solaris-centric--not what I had expected from the general description in the conference prospectus. The tutorials themselves were good, but would have greatly benefited from much-expanded course descriptions and estimated experience levels in the prospectus, so people could plan better.

Technical Sessions

The technical sessions, the heart of the conference, were really good this year. There were a large number of BSD-related sessions (you knew I was going to get to BSD at some point...), including talks on TrustedBSD, the NetBSD rc.d system (which will soon be imported to FreeBSD), FreeBSD's SMPng effort, KQueue, and the Citrus i18n project. There was an invited talk by Avi Rubin about the feasibility and security implications of electronic voting in public elections (conclusion: it's not quite time yet), others on DNSSEC, IP wireless networking, and many more. Overall I found these sessions to be of a very good quality, especially when coupled with the printed papers for each, copies of which were distributed to each attendee.

The Community Aspect

During the entire show, there were ample opportunities for groups to get together to chat, hack, engage in multimodal (usually simultaneous verbal and IRC) discussions, drink beer, and do just about anything else that Boston's slightly anal-retentive population of bouncers and security staff would allow. I wound up with the FreeBSD group more often than not, and had a fabulous time learning, chatting, and doing business with all kinds of people. Early in the week, when fewer people were there, I hung out with the European BSD users, had lots of fun, and learned a great deal about various European countries that I now want to visit.

Another way to take advantage of being in physical proximity is to have hacking meetings--and both the FreeBSD and OpenBSD developers did that. I sat in on a few minutes of the FreeBSD meeting, as such topics as SMP, kernel schedulable entities, devfs and devd and more were discussed. After not too long, I felt like Mr. T: "Don't give me none of that jibba-jabba!" That's when I decided to leave while still sane. It was apparent to me, though, that getting twenty developers together in one room for architectural discussion must have accomplished more in eight hours than eight weeks of mailing list email could have. The benefits of getting together to discuss issues in person cannot be overstated!

Ups and Downs

I mentioned earlier that the conference had its ups and downs. Since I'm firmly planted on my soapbox, here are more of the good and not-so-good things that happened at USENIX.

Although the conference was still going on, the terminal room and wireless network were taken down in the middle of the last day. This left people with no ethernet connectivity for the remainder of the day. This was not good planning and should definitely not be repeated; network connectivity throughout the term of the conference is very important to attendees. The USENIX booths also closed midday on the last day of the show. I understand that they have to be cleaned up sometime, but that time is not while the conference is still going on. When the services desk closes, where do people return their conference surveys? When the wireless ethernet checkout desk is taken down, where can people return their rented cards? The Birds-of-a-Feather (BoF) sessions were well publicized and well supplied. All the presenters had to do was show up with their information; overhead projectors, pens, and free bottled water were all ready. In general, the USENIX staff went out of their way to be helpful and friendly, even toward the end of the conference when they were getting very tired. They're generally unappreciated, so I'll say this here: thanks for putting on one of the best technical conferences, year after year!

In Conclusion

I've rambled on quite far enough, so let me just say this in conclusion. If you haven't made it to a USENIX conference or other major technical conference, get ye there if at all possible! Between the direct educational opportunities and the chance to meet and work with fellow sysadmins, developers, and other geeks, these conferences are definitely of benefit to your career and your hacking hobby. Author maintains all copyrights on this article. Images and layout Copyright © 1998-2001 Dæmon News. All Rights Reserved. July 2001 Search Submit Article Contact Us Join Us Merchandise

A Tour through the NetBSD Documentation, Part IV: Loose Odds & Ends

Hubert Feyrer , April 2001

This is the last part of our tour though the NetBSD documentation. Besides the places mentioned in the previous parts of this series, there are a few other places that should not go unmentioned here, and that have docs on various things in NetBSD. This last part of the tour goes through a few of them. Misc Files and Directories

The directories that these various pieces of information can be found in are:

/usr/share/doc/html This directory contains documentation available only in HTML format. Currently, there isn't much documentation available in the Unix world that's not available in one of the more traditional formats (i.e.: manpages), but it's expected that the world will not end with this one package in here.

/usr/share/doc/html/ntp: Documentation for the Network Time Protocol, in HTML format. This includes an overview of the NTP protocol, configuration of the client and server, and some implementation details.

/usr/share/misc: As with the section 7 of the NetBSD manpages, there are some loose odds & ends that don't fit in a better place. Some of them may still be interesting for human consumption, so a look in this directory may be interesting.

/usr/share/misc/operator: If you're programming in C, you may have wondered about operator precedence and associativity. If so, this file is the answer to all your doubts!

/usr/share/misc/style: The NetBSD source code style guide, previously known as KNF, kernel normal form. This document describes how to indent your code so it fits into the existing NetBSD source, how, when and where to place braces, where to put comments, order of include files and a lot more. Web Documentation

All the NetBSD web pages that are available on www.NetBSD.org can also be found in the "htdocs" source collection. It is available in the usual places via AnonCVS, SUP, FTP, etc. All the paths given here are relative to htdocs and/or http://www.netbsd.org. Some of the directories people may find interesting are:

Documentation/Hardware: Information and links to various hardware related documentation. This includes a (rather long) list of the busses, various chips and many machines supported by NetBSD.

Documentation/bsd: This directory contains links to some preformatted documentation from the Berkeley Net/2 and Lite2 User's Supplementary Documents (USD), Programmer's Supplementary Documents (PSD) and System Manager's Manual (SMM). The files themselves are stored on the NetBSD FTP site.

Documentation/cross: Some hints on crosscompiling the NetBSD kernel and userland, which is useful for bootstrapping new ports. This document covers how to prepare the cross compiler, set up the source tree and explains compiling the kernel, libraries and userland.

Documentation/current: Describes what the development branch of NetBSD is, the problems that one should be prepared to handle, as well as various ways to track NetBSD-current and where/how to get the repository.

Documentation/kernel: Various aspects regarding the NetBSD kernel, starting from compiling and tuning the kernel to debugging, profiling and programming drivers. Also covers subsystems like RAIDframe, UVM, and many more.

Documentation/misc: This page covers adding users, tuning accounts, setting up printers (also to Windows machines!) and scanners, how to handle removable media like floppies, ZIPs, CDs and DVDs and answers many commonly asked questions such as how to get foreign keyboards to work, adding disks, etc. A big source of interesting information!

Documentation/network: All the things you ever wanted to know about NetBSD networking, but never dared to ask. Topics covered include basic configuration, getting PPP, ISDN and NAT going, securing the machine, running Appletalk, BIND and Kerberos plus the usual troubleshooting aid. Further pages describe setting up NAT, firewalling and packet filtering with IPfilter, DHCP, and there are some exhaustive pages describing how to get IPv6 and IPsec going. There is also a long list of links for further reference. Definitely worth reading!

Documentation/power-mgmt: If you have a laptop or notebook, you will almost certainly appreciate this section. It describes how power management in NetBSD works, configuring it and lists some of the tricks on keeping the power consumption from the disk and network at a minimum. Documentation/software: These pages cover commercial software available for NetBSD as well as 3rd party software that is shipped as part of NetBSD, or separate from it in the NetBSD Packages Collection.

Documentation/wscons: This page documents the NetBSD wscons console driver. Topics covered are enabling virtual terminals, changing the keyboard map, editing the console font and more.

Documentation/x: Setting up X hardware like mice, keyboard and graphics hardware is discussed here, as well as compiling and the answers to general X installation questions.

Ports: This directory contains all the NetBSD ports pages, with each in it's own directory. Information available usually includes a general description of the port, link to last binary snapshot, and a port-specific list of frequently asked questions.

guide: This directory contains Federico Lupi's guide, "The NetBSD Operating System", which covers many areas of NetBSD, starting from installation over printing and compiling the kernel to the packages collection, networking including DNS, mail & news, and many other topics. Available in the English and Italian languages, and as HTML, PostScript and RTF.

ja, de, fr, cs: Translation of the web site to Japanese, German, French and Czechian language, in various stages of progress. Online Resources and Books

With the description of these files, our tour through the documentation installed and available on your NetBSD 1.5 ends here. Note that there is a lot more documentation both in online form as well as in printed form.

A lot of books cover all possible aspects of Unix, starting from using the system to administrating and programming the various subsystems and APIs, and also covering not only genuine Unix systems but also specific systems and their own special properties that make them unique. Publishers that should be looked for are first and foremost are O'Reilly with their "Nutshell" series, Addison Wesley and Prentice Hall are other major publishers. There are also many smaller publishers that have excellent books covering Unix.

When you search for online documentation, be sure to check out not only the NetBSD web site - www.netbsd.org - but also have a look at some more generic Unix resources like the information found at www.geek-girl.com or www.unix.com.

When looking for documentation on things that you don't find in NetBSD, keep in mind that most Unix versions are quite similar in many areas, and that documentation on other (non-NetBSD) systems can be used to a certain extent. If you're not sure, feel free to ask on any of the available NetBSD mailing lists for assistance! Hubert Feyrer

Das Blinkenlights for BSD

By Don Wilde,

Those of you who have attempted to use BSD for hardware control know that this is one area where the OS isn't very cooperative. Programs that link to hardware control assembly language code have a nasty way of dumping core as soon as you make the call. The process of writing drivers is very involved and isn't very well documented. My attempts at activating the driver-generator scripts in /usr/share/examples/drivers resulted in a whole bunch of fatal errors and no end in sight.

There's a simple little back-door trick that's really helpful. It's called /dev/io. It's not exactly what you want to use for time-critical code, but it works great for applications like mine. I needed to make three bicolor LEDs work as indicators for an embedded PicoBSD system, and I didn't have a lot of time.

I made up a simple circuit to attach to my serial port sio1, like so: I highly recommend Press-N-Peel circuit resist transfer film, available from All Electronics, Inc. http://www.allelectronics.com. With it I was able to make the circuit tracework (note that the circuit shown has traces only on one side) by simply printing the Gerber output file from OrCAD. Users with no ECAD can use a graphics program such as GIMP with Ghostscript to generate printable images. Once the file is printed on the film with a laser printer, it can be ironed on with a clothes iron and the board etched on the kitchen table using Ferric Chloride solution. Radio Shack's p/n 276-1535a is rather weak; Electronics supply stores have a larger bottle from GC that is stronger stuff.

Connect it to your serial port. The idea is that the software drives lines DTR, RTS and TD under control of three register bits in the UART. In the case of sio1, the port block begins at 0x2F8. When the bits flip, it causes the output lines to transition from -12vDC to +12vDC. When this is applied to a bicolor LED such as a Panasonic LTL-293SJW, Digikey p/n 160-1038-ND, the voltage causes it to glow red or green. A refinement of this circuit is that I have provided separate dropping resistors for each path, to enable the use of a smaller resistor in the red line. The red LED is more efficient, so the green needs to have more voltage applied to make it appear to be the same brightness. By toggling the bits, you can even get a fair yellow by varying the duty cycle, although the /dev/io trick is too slow to do this effectively. Be aware also that some CMOS chipsets do not supply the full RS-232c drive current, and some recent computers may need to have the series resistors increased in ohmage to reduce the draw. cpufunc.h defines macros for the outb() function. It can be used as a primer for describing hardware interface functions that access port bits.

#include

Here's where /dev/io does its magic. When opened as an active filehandle, /dev/io disables the BSD protections against hardware access. This enables us to poke the hardware without complaint from the kernel. The following six simple functions set or clear the proper bit in either the Line Control or Modem Control Registers. Two LEDs use the Modem Control Register bits RTS and DTR, and the third line is TD, controlled by the BRK bit in the Line Control Register.

/* Bi-Color LED Activation Functions */ unsigned char greenone(unsigned char modemcontreg) { int fHndl; modemcontreg |= 0x02; /* set RTS bit in MCR */ fHndl = open("/dev/io", O_RDONLY); outb(0x2FC, modemcontreg); close(fHndl); return (modemcontreg); } unsigned char greentwo(unsigned char modemcontreg) { int fHndl; modemcontreg |= 0x01; /* set DTR bit in MCR */ fHndl = open("/dev/io", O_RDONLY); outb(0x2FC, modemcontreg); close(fHndl); return (modemcontreg); } unsigned char greenthree(unsigned char linecontreg) { int fHndl; linecontreg |= 0x040; /* set BRK bit in LCR */ fHndl = open("/dev/io", O_RDONLY); outb(0x2FB, linecontreg); close(fHndl); return (linecontreg); } unsigned char redone(unsigned char modemcontreg) { int fHndl; modemcontreg &= 0x0FD; /* clear RTS bit in MCR */ fHndl = open("/dev/io", O_RDONLY); outb(0x2FC, modemcontreg); close(fHndl); return (modemcontreg); } unsigned char redtwo(unsigned char modemcontreg) { int fHndl; modemcontreg &= 0x0FE; /* clear DTR bit in MCR */ fHndl = open("/dev/io", O_RDONLY); outb(0x2FC, modemcontreg); close(fHndl); return (modemcontreg); } unsigned char redthree(unsigned char linecontreg) { int fHndl; linecontreg &= 0x0BF; /* clear BRK bit in LCR */ fHndl = open("/dev/io", O_RDONLY); outb(0x2FB, linecontreg); close(fHndl); return (linecontreg); } int main() {

unsigned char mcr = 0; unsigned char lcr = 0;

while (1) { lcr = redthree(lcr); mcr = greenone(mcr); sleep(1); mcr = redone(mcr); mcr = greentwo(mcr); sleep(1); mcr = redtwo(mcr); lcr = greenthree(lcr); sleep(1); } return (0); }

It’s that easy! Well, at least, it’s easy if you’ve remembered to disable the serial port tty in your kernel and you’re not trying to run getty’s on the same UART!

/dev/io isn’t perfect, however. There are reasons why the BSD driver system is the way it is, and they should be heeded! Enabling the /dev/io special device sometimes takes a noticeable number of microseconds even on a lightly loaded machine, so this is definitely not a call you want to make inside a tight code loop.

It is a viable technique to use in the right situation. Just be aware of the time-cost of the enable, and make sure you do NOT use it for more than a few quick moments, because all other kernel service routines are blocked while /dev/io is enabled.

NetBSD 1.5.1

Hubert Feyrer

NetBSD 1.5.1 was released in late June 2001 after an extended period that was used for testing, enhancing the system, and of course bugfixing. NetBSD 1.5.1 is the first maintenance release of the NetBSD 1.5 branch, and as such it includes few new features, and mostly improvements over the NetBSD 1.5 release. Binary compatibility with 1.5 is retained, so a full or partial upgrade from 1.5 to 1.5.1 is not a problem. * What's new in NetBSD 1.5.1

A complete list of changes between NetBSD 1.5 and 1.5.1 can be found in the CHANGES-1.5.1 file that's part of the NetBSD 1.5.1 release. Some of the highlights include significantly increased NFS client performance by clustering commit operations together and using larger block size on some ports. Support for 802.1Q virtual LANs has been added to all ports. The i386 port was changed to support booting off a RAID1 RAIDframe mirror so it is now possible to configure a failsafe setup of your / filesystem. Furthermore, the i386 port can how have up to 16 partitions per disklabel.

The networking subsystem now knows about cloning interfaces. This permits one to have a variable number of instances of a certain device, and extending it doesn't require a kernel-rebuild and reboot. Use "ifconfig -C" for a list of devices that support cloning in 1.5.1.

New and improved drivers include a driver for the Aironet/Cisco wireless PCMCIA cards, an(4), the NCR siop(4) driver was enhanced for performance and stability, the isp(4) driver now works on MacPPC and other big endian ports, the VIA chipsets now do Ultra/66 DMA, and several pciide controllers now handle Ultra/100 DMA. Support for Intel 82801BAM controllers has also been added, and handling of Ali controllers has been improved. The ex(4) driver now supports the 3COM 3c555, 3c556 and 3c556B MiniPCI Ethernet cards, and drivers for the Apple PowerMac's audio hardware, the Accton EN2242 and other AmdTek AN985 cards and for sound cards based on Yamaha YMF724/740/744/745, ESS Technology Maestro 1, 2 and 2E, NeoMagick 256 and Cirrus Logic CrystalClear PCI Audio CS4281 were added.

Upgraded software includes BIND 8.2.3 (see Security Advisory SA2001-001), OpenSSH 2.5.1 (see SA2001-003), sendmail 8.11.3, ISC DHCP V3 beta2 patchlevel 23, Heimdal kerberos 0.3e and probably some others that I forgot about.

Other security related updates were done to ftp(8) per SA2000-018 and SA2001-005, ntpd(8) per SA2001-004, telnetd(8) per SA2000-017 as well as a on i386 a kernel fix related to USER_LDT that's documented in SA2001-002. * 1.5.1 and pkgsrc

Besides the core operating system, NetBSD also maintains a collection of 3rd party software in the NetBSD Packages Collection, pkgsrc. For the NetBSD 1.5.1 release, pkgsrc was taken through a freeze, and with the help of automated bulk builds on various platforms, the number of broken packages was reduced. Besides fixing build problems of the various packages and the pkgs they require, many applications were fixed to work on LP64 architectures. Furthermore, many bugs from the 'pkg' category were closed by the hard-working pkgsrc people. At the end of the freeze, of the roughly 2100 packages in the collection, there were <10 packages that didn't build properly on i386, and only about 40 had problems on alpha. Those are pretty good numbers! Furthermore, many pkg related problem reports were closed and at the end fewer than 100 pkg-related problem reports remain open.

Binary packages built on and for NetBSD 1.5.1 are available on ftp.netbsd.org in the /pub/NetBSD/packages dir, and there are also several ISOs that have the binary pkgs available for download. Thanks go to Dan McMahill here for his 'cdpack' program that helps in putting binary pkgs on CDs so that each CD has all the dependencies resolved. The result is three fully packed CDs for i386, and likely similar numbers for other architectures.

With NetBSD 1.5.1, you can now experience NetBSD, KDE2 and KOffice for a fully integrated office environment with no license problems. Available for i386, alpha and many other architectures. Mozilla 0.9, KDE 2's Konqueror and Links 0.95 are just a few examples of browsers available to explore the Internet with NetBSD. A support package for running VMware on NetBSD/i386 was added, it's called suse_vmware. The official VMware code, a valid license and Wasabi Systems' compat package are still needed.

Other highlights of the pkgsrc and binary pkgs that are available for NetBSD 1.5.1 include: Apache 1.3.19 and 2.0.16, BIND 4.9.8/8.2.3/9.1.2, Civilisation Call To Power (demo version), Ghostscript 6.01, GNOME 1.4.0, GNU Emacs 20.7, Heretic 2 (demo version), Sun's JDK & JRE 1.3.0.2, KDE 1.1.2/2.1, Mozilla 0.9, perl-5.6.0, Perl 5.6.0 with many modules, Quake3-Arena (demo version), Samba 2.0.9, teTeX 1.0.7, Xemacs 21.1.14. * The X files

Historically, NetBSD shipped with an X that was based on XFree 3, with XFree 3.3.6 being the latest version in xsrc. That version was enhanced a lot, to support many of the architectures that NetBSD runs on, but that are not part of the official XFree release. Unfortunately the changes were never fed back to the XFree developers, and as a result the new XFree 4 release doesn't have most of the changes. To make things worse, there are cards that are only supported in XFree 3, and there others that you need to run XFree 4 to get X going.

As a result of this, NetBSD ships the "old" XFree 3.3.6 from xsrc by default, but also includes a binary snapshot of the new XFree 4.x line so people using recent graphics cards can use that for NetBSD. The sources for the latter can be found in xsrc/xfree, and everyone interrested in rebuilding XFree 4 can do so after putting USE_XF86_4=yes into /etc/mk.conf.

To install the XFree 4 shapshot that comes with NetBSD 1.5.1, move aside /usr/X11R6 and extract the tarball in /. Then run 'xf86cfg' to configure X. * Downloading

The NetBSD 1.5.1 release is available from ftp.netbsd.org and its mirrors in the /pub/NetBSD/NetBSD-1.5.1 directory. ISO images of the release are available in the /pub/NetBSD/iso/1.5.1 directory. The project’s main ftp server ftp.netbsd.org is rather heavily loaded these days, and it is greatly appreciated if you use one of the mirrors available. See the list available at the NetBSD web site www.NetBSD.org for a mirror near you.

Hubert Feyrer

Adventures in BSD

By Michael Josefsson

I am sometimes asked "Why do you use FreeBSD?" My usual 'auto-response' is "Because it is the best!" While I truly think it is the best, this reply does not really answer the question. I hope this article will better explain my feelings.

Way back in 1994 I became the manager of a hardware laboratory at my old University. I was to manage the labs in all aspects, from computers down to data sheets, pliers, and students. With some 300+ students attending each year this was a very time-consuming task. Of the three labs, only two had computers and networks in them. In the third lab, 16 serial lines were connected through a Xyplex terminal server to a computer of unknown pedigree. (It later turned out to be a Sun 3.) I had been into computers since the early 80s, and PCs since 1989, but I had never touched a network of any kind.

The two labs were connected by a Lantastic LAN. Only one area of the server's disk was shared and every student stored his/her own home-directory on it. As long as everything worked fine, and it generally did, I had better things to do than trying to understand what this network setup was all about. The odd downtime was mostly due to students tampering with the RG-58 coax that ran from one machine to another continuing on into the next lab. Problems were easy to locate. I knew the coax had to be terminated with a 50-ohm BNC terminator, and moving this terminator to strategic places along the cable always led me to the culprit.

Then there was a software upgrade. The labs had been running MS-DOS with a DOS-based compiler for many years. The new version of the compiler required MS Windows. (At the time this meant Windows for Workgroups 3.11.) I could not get the old LAN software to run under Windows. I don't remember why, perhaps I was a victim of my own ignorance. After reading the Windows docs I managed to set up a common workgroup for the two labs. With a 486/66 Windows box working as a file server we again had a fully functioning lab...or so we thought!

I found that it was possible to access the server's shared area and was quite pleased with my doings. I compiled some typical code from a client machine and everything ran as expected. What I did not test was network performance under a higher load. The idea never crossed my mind.

During one compilation, several large, multi-megabyte files were created in the project's home directory. This was in itself not a problem as the network's bandwidth was not saturated. However, all this data moving in and out of the server turned out to be detrimental to its health. With 10-15 clients chewing away, the load on the server increased. After a period of time ranging from a few minutes to several hours, the server would unexpectedly crash. A reboot got everything working again. All source files had been auto-saved before entering the compilation stage so it was easy to start over and hope for more success the second time. Still, the situation was less than satisfactory. At this point, OS/2 enters the story. In the outside world, Windows 95 was being deployed. I got my hands on an old OS/2 2.1 demo CD. After several problems I got it up and running. I thought it was cool and ordered my own OS/2 Warp soon after. Warp was my favourite desktop for years to come. I really liked the smooth user interface, and enjoyed the increased stability compared to the Windows version I had used earlier. A co-worker with a similar interest in computers used Windows 95 and had to re-install every three to four months. The system would somehow clog itself up beyond recognition. My OS/2 machine ran happily all the time. Great! Except for the RSA DES Challenge. Being outside of the United States I took an interest in the Swedish-run SolNet DES-attack. With SolNet's limited resources there was quite some time before an OS/2 executable was published. The situation annoyed me.

So what to do? I was unwilling to give-up OS/2 and surrender to Windows 95. I had started to experiment with Linux, a Unix-like system but felt very little enthusiasm for it. Because of an earlier experience with HP-UX, I was under the impression that Unix only represented an extremely complicated way of doing things, and therefor, Unix was ruled out. At this time, there were executables for FreeBSD available, and not knowing much about FreeBSD, I made an FTP install of 2.1.7-STABLE. The DES-client ran as expected. I figured out nice commands; 'kill -STOP', 'kill -CONT' and that putting an ampersand (&) after the command line ran a job in the background. Cool! I could manage every aspect of the program. A taste of a new world! This was very enticing.

My success was short-lived. There was soon a new DES client requiring newer libs, which forced me to install 2.2.2. This time I ordered the 2 disc FreeBSD set from Walnut Creek sometime around June 1997. Before the summer I had plans to replace the lab server with OS/2, but during the summer, I experimented with FreeBSD and learned about TCP/IP, Samba, FTP and Unix. The client machines in the lab were using Windows 95 and since we had to get rid of Windows for Workgroups anyway, I installed FreeBSD on each and every machine. I made further experiments with the r*-services (rsh, rcp, ruptime, etc.) among other things. All in all, the experiments made me confident with managing FreeBSD. In the beginning of August, when I had to actually wire-up the lab's new infrastructure I made FreeBSD run the lab for me. That turned out to be a wise move; not one spontaneous reboot occurred during the years to come.

With a busy lab, reliability is of major importance. The logs show students accessing the server around the clock. FreeBSD really is reliable, the server's longest uptime to date is 220 days.

By now, things were moving fast. The third lab was also computerized. (The introduction of Microchip's PIC line of processors necessitated this.) I added a couple of hubs and the labs were interconnected. The next summer I set up a local name server and a private domain on a FreeBSD box with two NICs - one for the internal net and one for external access. There was no forwarding between the two interfaces. This setup allowed me, as admin, to download software which I then installed on the clients. Each project team in the lab had their own home, with permissions fixed so they could not peek at each other's work. They could also edit files at home and upload via FTP. The user 'system' was added as a way to keep a central repository of programs and files that every client would need - Adobe Acrobat for Windows for example, printer drivers, upgrades and other stuff.

Until now all data sheets had been in a folder in my room. The projects' supervisors had access to the folder and make copies which they handed out to the project teams. There were 95 steps to the photo copier, and with 95 steps back from it, the handling of the data sheets was becoming more and more cumbersome as a variety of components were added. What to do? Install Apache! By letting the server have all data sheets in PDF-format, the actual paper handling has eliminated. This was a truly brilliant move that I wish I had thought of earlier. Now each project group could peruse the available components’ data sheets, both from home and when in the lab before committing the device into their project. Some students printed out data sheets of course, but I see a trend of more and more students reading the specs directly off the screen.

There is a lot of activity in the labs, and with up to 75 students there at the same time, not all of them can be busy with their assignment; installing MP3s on the clients has become a popular pastime. It is quite possible that the especially zealous students fiddle around with the system settings of Windows 95 and cause damage! To simplify the re-install Windows 95 we have made a complete 2 gigabyte image of the Windows partition which easily can be downloaded and written onto the machines. While this may sound rather brutal, it works well in practice. In fact, every machine in the lab was born this way.

Needless to say, the client machines are dual-boot with Windows 95 and FreeBSD. It is a particular pleasure to find the students shutting down Windows and rebooting into FreeBSD because they feel more at home with it.

Earlier I mentioned we had a Sun 3 box. That particular machine has gone to the scrap heap and the FreeBSD server has replaced its functionality. Using the ports, I installed the m68k-coff cross-compiler and spent some time rebuilding the libs needed for our particular hardware. We were able to get rid of gcc-1.40 and now use gcc-2.8.1 for our in house built 68008 computer card.

Some small bits and pieces to complete the picture: The server has been endowed with a Tandberg SLR-5 tape backup. Once a week I do a level 0 dump and every night a cron job initiates a level 1 incremental backup. The machines’ disks are mirrored with vinum(8). Thus the entire /usr is safeguarded from disk failure. To ease new installations and administration, each client has a P:\ (P for program) directory with all non-standard Windows 95 software: It is now sufficient to install new software on only one client and it will become available to the other clients at the next log-in. Every home share is attached as Q:\ on the client. To this end, Samba is configured as an NT domain controller. Log-in scripts handle the actual attachment of the devices at log-in time. On the FreeBSD side I use NFS and amd(8) to automount the user’s home directories upon log-in.

I have unfortunately left OS/2. I really liked the Workplace Shell, but the functionality built into even a basic FreeBSD system makes me more productive. I have now been using FreeBSD exclusively for over two years for all my desktop needs. My experience is best summarized by something I saw someone post to one of the FreeBSD mailing lists: "I’m home."

Michael Josefsson is a research engineer at Linköping University, Linköping, Sweden.

He can be reached at [email protected].

Hey! Mister Answer Man by Todd Whitesel

This month is the special all-reader issue!

I've got my hands full preparing to run the Registration desk for Anime Expo 2001, and this month's mailbag was dominated by follow-ups to previous questions, so I'm taking a break and just editing everything together this time around.

There's one "real" question, which broadens the Answerman universe. Which question it is, is left as an exercise for the reader. List of Topics

Compiler warnings revisited: put on your pedantic goggles... Finally got that strange CD-ROM setup to work! How do I mount an ISO 9660 filesystem on FreeBSD? Obtaining the network interface name isn't as simple as it sounds. I need some wetware interfacing advice, help! Mailbag: Questions I didn't get to, or didn't have a clue about.

Q: Compiler warnings revisited: put on your pedantic goggles...

A reader writes in:

A: This is in regards to the compiler warnings answer from your May column.

The assignment of char* to int is implementation defined, but for something like double, it's not even implementation defined but is instead undefined; i.e. the source is no longer valid C as defined by ISO 9899, hence the Standard doesn't apply anymore. implementation defined does not mean "it works on many systems but not on all", it means "this must do something on all implementations, and the compiler documentation must state what it does". In other words, the code is valid C but what it actually does is left to the compiler producer. For the example of pointer-to-int conversion, you could snip off some bits, or assign zero, or abort the program; or do something nasty with the number's sign bit. stralloc shouldn't be used by the programmer. All names that begin with "str" followed by a lowercase letter are reserved for . This means that the compiler producer is allowed to provide a function or macro or even a variable called stralloc, which would conflict with any user-definitions of the same name. extern is not basically redundant for functions, it's entirely redundant, except perhaps for documentation purposes.

Q: Finally got that strange CD-ROM setup to work!

A reader writes in:

A: I am most grateful both for you publishing my question and then publishing the replies.

Basically none of the replies worked alone, but a combination of 1, 2 and 4 did: swap the CD-ROM (the 4x in there was "slow to reply"), stick it on Cable Select instead of Master and stick it on the secondary IDE.

Chalk one up for the "Non Deterministic View of Computing" theory.

Please forward my sincere thanks to all who took the time to reply. PCs are really a pain. (I come from the pretty workstation world where the number of CD drives you get can be counted on one hand!)

Q: How do I mount an ISO 9660 filesystem on FreeBSD?

A reader writes in:

A: I've been looking for the same answer myself. On a FreeBSD mailing list archive, I found an example that works great for me with a standard ISO 9660 filesystem image.

# vnconfig /dev/vn0 /scratch/fbsd33.iso # mount -t cd9660 /dev/vn0a /mnt

Q: Obtaining the network interface name isn't as simple as it sounds.

A reader writes in:

A: This question is unanswerable, unless the original querent can be more specific. For example:

1. Q: I need to know the name of an interface so that I can use a particular ioctl() on it. A: You'll have to ask the user. You can use the techniques described below to get a list of all interfaces, but there's no guarantee that you can select the right one automatically! 2. Q: I have an IP address and I need to know which interface it's configured on. A: Use the sysctl(3) MIB net.route.0.iflist.0 to get a complete list in routing socket format. If you have an interface index instead of an IP address, use the index instead of zero as the last element in the MIB variable name. Some BSD systems have the getifaddrs(3) library routine which does the complicated parsing of sysctl(3)'s output for you. You can also try parsing the output of ifconfig -a, which is relatively consistent and much easier to do from a shell script. 3. Q: I need to know which interface the route to xxx.yyy.zzz.aaa points to. A: You can parse the output of route(8)'s get subcommand, but it's painful. It might not be as painful as trying to parse the output of sysctl(3) net.route.0.dump, though! If you really want to do it yourself, you should look at the source code to route(8) to see how it's done.

Q: I need some wetware interfacing advice, help!

Hey, I just met a real cool guy and he said he thought I looked hot, so I asked him out. He said we have to get to know each other better. All of his friends are saying he won't go out with me because he wants to have all the girls not just one. He's all I think about, please help!

A: I'd bet he means the first bit, and he really does think you look hot. But guys will think that any time they get excited just from looking at you; it's probably the most honest compliment you will ever get from a guy.

That bit about "get to know each other better" sounds to me like a classic dodge, however -- a polite way to admit he already knows he doesn't want to go out with you, but can't bring himself to say it to your face.

What his friends say suggests that he really isn't comfortable with you going head over heels for him, so you're either going to have to win his heart big time, or move on.

Actually, if you read a pile of Archie Comics Digest from the checkout stand at the supermarket, I think you'll get over him pretty quick.

Mailbag: Questions I didn't get to, or didn't have a clue about.

1. How do I make xBSD use Solaris style automounting? 2. I have Windows NT installed on partition 1 of my first harddisk and FreeBSD 4.3 installed on partition 2. Is there a program for Windows that will allow me to read from the second (ufs) partition like explore2fs does for ext2fs partitions? 3. I have installed a Linux program binary onto my FreeBSD computer. Running under compat mode I now get the error message that the program needs /dev/ptmx, a pseudo-tty master device. How does one fix this? Do you have questions for the BSD Answer Man? Send them to [email protected]. Any email sent to this address is assumed intended for publication and will become the property of Dæmon News. That's all for this month, folks. Until next time, remember: there's no shame in asking RTFM questions any more, because these days, there is just too much FM to R.

About the Author

Todd Whitesel has been grokking computers for fun since his first grade school Apple II in 1980, and doing it for a living since 1992, when he escaped from Caltech with a B.S. degree. He helps promote Japanese Animation in America by running Registration for Anime Expo, and helps promote NetBSD by way of his NetBSD Architecture Farm.

[home| mail]

Dæmon’s Advocate

Wes Peters Flesh Peddlers

I received a very interesting phone call recently. I was talking with a couple of co-workers when our office manager tracked me down and said she had a caller who asked for "the Wes Peters who writes for Dæmon News magazine." This is not how I usually receive calls at work, so we were both curious.

When I picked up the phone, the caller repeated the question, asking if I was the "Wes Peters who writes for Dæmon News." I replied yes, and asked what I could do for him. He introduced himself as the HR director for a computer industry start-up company and proceeded to tell me the strangest story...

It seems Dave (I will call him Dave because that’s his name) had received a copy of my resume in email a few days before the call. Dave’s company was in need of a few good hackers, BSD hackers in particular, at that time, so he was interested in this resume. He forwarded a copy of the resume to his CTO, who returned shortly to Dave’s office. The CTO is familiar with the BSD developer community, having spent a number of years with a commercial software company noted for being friendly to FreeBSD in particular. Given some of the claims made on the resume, including authorship of Dæmon News columns, FreeBSD committer status, etc., he thought he should recognize the name. When he did not, he became suspicious.

Dave called the phone number on the resume with the CTO still in his office. Neither were particularly surprised when it turned out to be a technical recruiting firm. Curiosity firmly piqued, the CTO used his favorite search engine, picked out a few key words from my resume, and located an on-line copy of my resume with my name and phone number immediately.

On the block, or not?

Dave and his CTO were curious as to how this came about. They used a couple of other leads to track down my employer and call me, to see if they could learn how this situation came about. I did not immediately recall the name of the recruiter, but when Dave told me the domain from which the resume was emailed, I recalled it instantly. I had received a single, cryptic email from someone at that firm a couple of weeks before, stating simply that he could introduce me to an offer that could be worth "500K." I dismissed it as yet another meaningless bit of spam, deleted it, and moved on. It caught my attention because it didn’t offer to lead me to a web page or include any instructions other than to reply to the email. I keep a copy of my resume on my web site for some of the consulting work I do. Web spiders can find this resume, so I get contacted by recruiters quite a lot. I don't mind, I consider it an opportunity to put them in contact with friends who might be looking for jobs even when I am happily employed. I had been told some horror stories about recruiters in the past, but this was my first really bad experience.

The call from Dave turned out to be fortuitous. The company Dave works for seems a fine company, well funded and guided by clueful executives, with a clear business plan. Once we'd straightened out the situation with this charlatan who'd shopped my resume in there as his own, I had several fruitful discussions with Dave and his executives. They are, by the way, looking for several good BSD kernel developers. If you're interested and have credentials, contact me and I will forward your information along to them.

After the above conversations, I mentioned this episode to several friends on an IRC channel often frequented by FreeBSD hackers. Wow, did I get an earful. Well, screenful. It seems that almost everyone who's been in the industry for more than a couple of years has a sleazy recruiter story. Now I understand why friends and associates say "head hunter" and "flesh peddler" with such dripping disdain in their voices.

Being still somewhat naive, or at least sheltered, in this area, I asked if the Internet job sites were much better. The answer was a resounding "No!" I was told tales of personal information appearing on public web sites, immediate influxes of spam mail, unsolicited phone calls after posting resumes, and one correspondent who picked up a stalker from an online job search.

Just fix it

I've been interesting in creating a BSD job clearing house for quite some time. I realize now this would not be enough. What we need is a secure on-line meeting place for employers with openings and for members of the BSD community looking for jobs. Moreover, we need a secure, private communication channel between the two.

I have several friends who are professional technical recruiters, and very good ones, and I respect them for their skills and for the services they provide. I've solicited their input on whether such a job site might work, and they seem positive that it can. I have a few ideas on how this might be done, but I'd like to solicit your opinions as well.

What I have in mind is a job posting board where the companies can disclose their names or not. All of the jobs would be BSD related in some way, probably focusing on programmers, system administrators, technical writers, and cat herders, er, managers of all the above. Ideally, we would provide employers the ability to post job titles and descriptions, and as many or few details about the company as they wish to disclose. Remember, a lot of companies in this business operate in "stealth" mode, where they are trying to avoid disclosing their development plans to potential competitors.

On the other side, we would provide job seekers with a secure site where they could post their resume, scrubbed free of personal information. Hiring managers could review the posted resumes without learning the name or other personal information about the candidate. Each would be informed of the others interested, once a mutual interest is determined, then and only then would any contact information be exchanged.

I'd like to know what you, gentle readers, think of this idea. Would you feel safe using such a service? Would a BSD-specific job database be of use to you? What sorts of information would you need to see in job postings or resumes in order to make this of use to you? In order to fully serve the BSD community, this would need to be a global resource. Suggestions as to how to make such a global undertaking work, and what data needs to be provided, are welcomed as well.

Dæmon News has been about bringing the BSD community together since it’s inception. Perhaps in our third year we can help bring some employers together with the talented individuals in this community as well.

I have setup a special mail box to receive feedback on this topic. Please send cheers, jeers, horror stories, and suggestions to [email protected]>. I will summarize our findings, and report our progress, in an upcoming column. Don’t worry about that email address, it’s an alias for my personal email address that will help me sort and respond to email on this issue. I won’t give away any information you provide without your explicit permission.