Do symlinks "exist"? (sh, ksh, /bin/test documentation ambiguity)
I expect it's old, old news to those with more shell scripting scars: but the results of the [ -e ] test are at variance with my allegedly reasonable reading of the documentation. For all three of sh, ksh, and the /bin/test manpages, the description of the -e test reads "file exists", unlike the other file-related tests which read "file exists and ", with being is-writable, is-exucatable, is-readable, and the like. The manpage for /bin/test is even more emphatic in suggesting it's going to be true for a strict superset of the files for which the other tests return true - "True if file exsits (regardless of type)". However, there are arguments for which -e returns false, but a different file-related test returns true. These arguments are symlinks which don't resolve to an existing file - both symlinks that point 'nowhere', i.e. to non-existent targets (directly or indirectly), and symlinks which will error with ELOOP if stat()ed. Changing the behaviour of -e for non-resolving symlinks is almost certainly a Really Bad Idea: the existing behaviour of -e is doubtless relied on by a few million shellscripts, all more or less strongly bound to the idea that if -e returns true, there's Something There, and a strong expectation that the Something is stat()able rather than merely lstat()able. But perhaps a small change to the venerable text of the sh, ksh, and /bin/test manpages might be in order? Some form of words like "exists (target exists if a symbolic link)" might capture the actual behaviour more accurately. Yes, it's a picky point - and one I wouldn't bother raising in the Linux world, where manpages are at best impressionistic; but the pithy clarity of OpenBSD manpages is a pearl beyond price, and thus worth cleaning of even small specks. As far as testing in shell scripts whether 'things' are present - using [ -e $file -o -h $file ] catches the 'exists, maybe as a symlink which doesn't resolve' case; as could the use of stat(1) with suitable format-strings, -q, -L, and related incantatia... Cheers, Stefek
Re: Pre-orders for our releases
Kevin wrote: > Part of the cost savings is that there is no need for a per-machine > license, so the company purchases one copy of each release CD set. However, the CDs themselves are *not* freely copyable (FAQ 3.3 and interminable misc@ discussions refer); so for business use it seems unremarkably reasonable to buy a sensible number of copies of the install media, where 'sensible number' is bounded below by the number of physical locations where OpenBSD is to be used, and bounded above by the number of machines. This is *not* irreponsible use of company resources - it's licence and copyright compliance, and avoids PHB questions about 'what's this 'donation' line on the invoice', or even trying to explain that T-shirts aren't being bought primarily to wear, but merely as packaging materials to protect the notoriously fragile jewel cases (and subsequently worn as part of a commitment to corporate ecological responsibility, rather than being dumped in the trash). Stefek
Re: Good boot and run on ancient laptop (HP Omnibook 5000), 16MB RAM
Martin Reindl, reading only what I actually posted, was moved to say > ... your laptop does not seem to have audio(4) hardware anyway. Yeah. You see, a cosmic ray came and interfered with the posting of my dmesg, such that the SMTP server caught a "." prematurely, and the TCP seqnums all magically fell into line with the truncation. The mere idea that I could have loused up the cut-n-paste of my dmesg to miss out the last 17 lines or so is unthinkable. Just to prove that the universe conspires against me, I'll repost the entire dmesg, and again the lines with the audio hardware and the 'root on wd0' will disappear. Never admit to a mistake, always allege a global conspiracy ;-) Looks like this laptop will do duty as little more than a serial terminal and rogue(6) platform, at least with the paltry 16MBs - having stuffed two 3C589 NICs into its two PCMCIA slots, brconfig is willing enough to create a bridge, but packet forwarding grinds to a halt after a few minutes only. I'll see if the backs of cupboards mightn't yield a little more RAM, which can't but help (and so might disabling devices whose interrupts I really don't want the poor little thing to waste its time handling, like the fdc0, joy0, and wss1 devicen. Stefek OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 120 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8 cpu0: F00F bug workaround installed real mem = 16359424 (15976K) avail mem = 6701056 (6544K) using 225 buffers containing 921600 bytes (900K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(c9) BIOS, date 12/23/94, BIOS32 rev. 0 @ 0xea830 apm0 at bios0: Power Management spec V1.1 apm0: AC on, battery charge unknown, estimated 0:00 hours apm0: flags 30101 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xe8000/0x6f7 pcibios0: PCI BIOS has 5 Interrupt Routing table entries pcibios0: PCI Interrupt Router at 000:01:0 ("Opti 82C558 ISA" rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0xa000 0xca000/0x800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Opti 82C557 Host" rev 0x00 pcib0 at pci0 dev 1 function 0 "Opti 82C558 ISA" rev 0x00 vga1 at pci0 dev 2 function 0 "Chips and Technologies 65545" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcic3 at pci0 dev 3 function 0 "Cirrus Logic CL-PD6729" rev 0xfe pcic3 controller 0: has sockets A and B pcmcia0 at pcic3 controller 0 socket 0 ep1 at pcmcia0 function 0 "3Com Corporation, 3C589, TP/BNC LAN Card Ver. 2a" port 0x400/16, irq 3: address 00:a0:24:ab:fc:a0, utp/aui/bnc (default utp) pcmcia1 at pcic3 controller 0 socket 1 pcic3: interrupting at irq 4 pcic3: irq 4, polling enabled pcscp0 at pci0 dev 4 function 0 "AMD 53c974 PCscsi-PCI" rev 0x10: irq 15 pcscp0: AM53C974, 40MHz, SCSI ID 7 pcscp0: SCSI bus reset scsibus0 at pcscp0: 8 targets sd0 at scsibus0 targ 6 lun 0: SCSI2 0/direct removable sd0: drive offline isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 1160MB, 2376864 sectors wd0(wdc0:0:0): using BIOS timings pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 sysbeep0 at pcppi0 npx0 at isa0 port 0xf0/16: using exception 16 pccom0: irq 4 already in use fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 isapnp0 at isa0 port 0x279: read port 0x203 isapnp0: card 1 violates PnP spec; byte 4 wss1 at isapnp0 "CS4232, CSC, , WSS/OPL/SB" port 0x534/4,0x388/4,0x220/16 irq 5 drq 1,0: CS4232 (vers 0) audio0 at wss1 joy0 at isapnp0 "CS4232, CSC0001, , Game" port 0x200/8 "CS4232, CSC0002, , CTRL" at isapnp0 port 0x538/8 not configured mpu0 at isapnp0 "CS4232, CSC0003, , MPU" port 0x330/2 irq 9 mpu0: find failed biomask edc5 netmask edcd ttymask fddf pctr: 586-class performance counters and user-level cycle counter enabled dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302
Good boot and run on ancient laptop (HP Omnibook 5000), 16MB RAM
Unearthed an ancient laptop recently, intending to add it to the collection of 'near-transparent' logging bridges available. Keen-eyed dmesg readers will note the massive 16MB of RAM, and the absence of a floppy device (though the controller is found) - and a Pentium old enough to need the F00F workaround!! Not only no floppy, but no CD drive to hand either, and though unusually this laptop model has built-in SCSI, it won't boot off SCSI devices. Installed OpenBSD by taking the hard drive out, putting it in a USB-to-laptop-drive adaptor on another machine, booting off the OpenBSD install CD (which detected that adaptor and the disk attached to it just fine: how lovely!). First boot when reinstalled went just fine (though if I had a brain I'd have edited the /etc/fstab to change the mountpoint for / from /dev/sd6a to /dev/wd0a while it was still in the write-the-install machine - but a swift 'mount -u -w /dev/wd0a /' fixed it up fine for that boot). As the laptop is very slow processorwise, *much* patience was needed during the sshd 'generating DSA key' stage - took several *minutes*! I did have some memory of reading what turns out to be FAQ 4.12.3, and I was patient, but not smart enough to take the steps described there about doing the keygen on a respectable box and creating a site38.tgz! Though slow, the machine seems to work just fine in its intended role - it just captured packets to and from a new box running Kn*ppix (purely to compare hardware detection results, honest ;-) with two classic 3com 3C589 PCMCIA NICs in its two slots. And the dmesg below comes to you via a Jaz cartridge written on the laptop in question and read on this other box, so that 'works' too. No serious stress-testing yet, of course - but a large thumbs up to OpenBSD putting otherwise-ancient hardware to good network monitoring use! I'll be doing the 'config -e' dance to disable the unwanted audio hardware... later... and no, I don't intend running X on this! Cheers, Stefek OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 120 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8 cpu0: F00F bug workaround installed real mem = 16359424 (15976K) avail mem = 6701056 (6544K) using 225 buffers containing 921600 bytes (900K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(c9) BIOS, date 12/23/94, BIOS32 rev. 0 @ 0xea830 apm0 at bios0: Power Management spec V1.1 apm0: AC on, battery charge unknown, estimated 0:00 hours apm0: flags 30101 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xe8000/0x6f7 pcibios0: PCI BIOS has 5 Interrupt Routing table entries pcibios0: PCI Interrupt Router at 000:01:0 ("Opti 82C558 ISA" rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0xa000 0xca000/0x800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Opti 82C557 Host" rev 0x00 pcib0 at pci0 dev 1 function 0 "Opti 82C558 ISA" rev 0x00 vga1 at pci0 dev 2 function 0 "Chips and Technologies 65545" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcic3 at pci0 dev 3 function 0 "Cirrus Logic CL-PD6729" rev 0xfe pcic3 controller 0: has sockets A and B pcmcia0 at pcic3 controller 0 socket 0 ep1 at pcmcia0 function 0 "3Com Corporation, 3C589, TP/BNC LAN Card Ver. 2a" port 0x400/16, irq 3: address 00:a0:24:ab:fc:a0, utp/aui/bnc (default utp) pcmcia1 at pcic3 controller 0 socket 1 pcic3: interrupting at irq 4 pcic3: irq 4, polling enabled pcscp0 at pci0 dev 4 function 0 "AMD 53c974 PCscsi-PCI" rev 0x10: irq 15 pcscp0: AM53C974, 40MHz, SCSI ID 7 pcscp0: SCSI bus reset scsibus0 at pcscp0: 8 targets sd0 at scsibus0 targ 6 lun 0: SCSI2 0/direct removable sd0: drive offline isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 1160MB, 2376864 sectors wd0(wdc0:0:0): using BIOS timings pcppi0 at isa0 port 0x61 midi0 at pcppi0:
Re: Simple question about appletalk
Bryan Irvine <[EMAIL PROTECTED]> wrote: > If the laptop only needs www access no appletalk is needed. Appletalk > is purely a file serving mechanism, like samba or nfs. If you need > appletalk it's pretty easy to set up on OpenBSD. Well... Appletalk itself is a lower-level protocol than samba or nfs; it's a network protocol which is an alternative to IP. That is, it uses link protocols - these days almost always Ethernet; in the last century often also Localtalk, a 230kbps serial protocol - for transport, and carries upper-level protocols, such as AFP (Apple File Protocol) in turn. A similar protocol (in terms of where it sits in the networking stack) would be IPX. In 'modern' Mac usage, Appletalk is still used in some environments for file sharing and for printing. Unless you have bits of kit in place which are happy to route Appletalk, it'll only be carried on one LAN segment. From what I can glean from manpages and Google (and I'll be trying this live in the next month or so, but have no first-hand experience currently) OpenBSD support for Appletalk is available (good) but not turned on in the GENERIC kernel (less good). atalk(4) describes the kernel interface; documentation suggests (but doesn't state authorititavely?) that OpenBSD will route Appletalk among multiple network interfaces; if you want to serve files and/or print, you'll want the netatalk package. There's a 1.6 version in the ports collection; a web page at http://www.doink.org/geeklog/public_html/article.php?story=20051212224355152 describes a recent instance of 'manual' (i.e. outwith the ports collection) compilation of the 2.0 version. HTH - Stefek
Double 4-port NIC happiness
I've just brought 3.8-RELEASE up on an oldie-but-goody machine - ASUS P3B-F - into which a total of 10 NICs have been thrust. 4 are on an Adaptec AHA-62044, whose NICs get named sf0 .. sf3 (note that as per the i386 info at http://www.openbsd.org/i386.html, these are recognised by the GENERIC kernel but not by the one on the boot CD-ROM); 4 more are on a D-LINK DFE 570TX, whose NICs get named dc0 .. dc3. (That's a minor documentation bug in the i386 web page - it says the 570TX NICs will get driven by the de(4) driver, but it's the dc(4) which does the job in point of fact. The dc(4) and de(4) man pages get this right). No massive stress tests done yet, but basic ping and nc of 10MB in sensible barely-over-a-second time suggests basic functionality working well. (Actual performance for nc sending a 10MB testfile is about 0.98 seconds on the dc ports of the 570TX, and more like 1.4 seconds on the sf ports on the Adaptec; both going through one otherwise unloaded switch to a Windows box.) Hope that's encouraging/useful to anyone else setting up a multizone setup with an OpenBSD box as the spider / hydra / Fat Controller / piggy-in-the-middle / Network Policy Device / whatever you want to call it... dmesg sent to openbsd.org's 'dmesg' address, not appended here; shout if you feel you must see it. Cheers, Stefek
Re: OT: wrt OpenBSD, what's a good laptop
The Thinkpads do have a good reputation for xBSD, and I picked up a good condition T30 which runs both NetBSD and OpenBSD without major drama, from a UK corporate left-over outfit called ITClear - www.itclear.co.uk. They were very helpful when the battery didn't charge as it should - sent a second one FoC, though it turned out to be a hardware fault which IBM fixed (*well* worth getting one with a bit of the manufacturer's warranty still left to run!) HTH - Stefek
brconfig: documentation bug? ease-of-use tweak? or luser wanting too much handholding?
Just revived an aging laptop (details at end) for occasional use as a logging/filtering bridge. Went through the brconfig man page once I had two NICs in the box. man brconfig has in its Examples section (in both 3.7 and Current) the encouraging text Create a bridge pseudo network device: # ifconfig bridge0 create Add the Ethernet interfaces rl0 and xl0 to the bridge bridge0, and have the bridge start forwarding packets: # brconfig bridge0 add rl0 add xl0 up It may be obvious to all but the Noob, but this is not quite enough to 'have the bridge start forwarding packets' in a meaningful, least-surprise sense. Although the two NICs - in my case, xl0 and ep1 - are usefully set into Promiscuous and Broadcast mode, they aren't actually brought UP. In order for packets to actually flow, you need to further incant ifconfig rl0 up ifconfig xl0 up (sticking to the manpage example's NIC names). With those incantations, btw, the bridge works just fine, allowing tcpdump to log packets like a good 'un. And packet-passing can be turned off and on again with great speedy speed and great easeful ease with the commands 'brconfig bridge0 down' and 'brconfig bridge0 up'; s/br/if/ also works fine. I leave it to the Relevant Authorities whether to classify this in one of the three categories suggested in the Subject: line, or dispose of it some other way. Those three possibilities, in order of increasing work, are a) dismiss this as a newbie whinge - of *course* each network interface needs an 'ifconfig up'. D'oh! b) tweak the documentation to add the one-liner # ifconfig rl0 up; ifconfig xl0 up to the relevant Example; c) tweak the brconfig code so that 'up' not only brings up the bridge itself, but brings the NICs up too. (Probably a less than brilliant suggestion, as it entangles things which should not be entangulated: by symmetry, a 'brconfig bridge0 down' would rationally have to down the two ends of the bridge, which would be Unexpected and Inconvenient. Stefek Config dets: OBSD 3.7 generic, running on HP Omnibook 5500, 48MB RAM, in its docking station; one NIC in the docking station's PCI slot, a 3Com 3C905; the other in one of the PCMCIA slots, a 3Com 3C589. dmesg available on request (already posted to dmesg@ a few days back, tho' with a slightly different h/w setup).