Re: FYI: min. memory requirements for a -CURRENT install on i386
Matthias Kilian wrote: Just FYI: recently there were some discussion wether an installation on i386 hardware with 16 MB or less would be possible (and usable) or not. Beeing curious, I just made a release(8) (without X11), and gave it a try with qemu. Result: you can do a complete install with 12MB RAM, but for running and *using* the installed system (with sshd and ntpd enabled), you need 16 MB. [In theory 13 MB are enough, but then the system starts trashing as soon as a ksh(1) a top(1) are running.] Ciao, Kili As part of that discussion, I was speculating that there is probably a difference between the requirements of floppy37.fs vs. cdrom37.fs vs. cd37.iso. Which did you use on your test? Also..was that -current or 3.7-release/-stable? Thanks for doing that test, as I have been sadly deficient on testing that recently... Nick.
Re: Install Woes (3.7/sparc) - Spontaneous crashes
Jim Fron wrote: I'm attempting to install OBSD 3.7 sparc on a Sparcstation 20. I've been through installs numerous times on 20's, 2's, and an IPC using previous OBSD versions. Currently, I only have one install method -- floppy. I could conceivably set up a netboot install or wrangle a CDR drive if need be. The problem is this: every time I attempt to install, I get part-way or all the way through the package download process, and the installer bombs, dumps hex to the screen, and drops back into OFW. I don't have serial console, either: I'm using a monitor and keyboard, so it's tough to say what, if any, error messages may be present. The more packages I attempt to install, the more likely it is to crash in the middle of download. If I reduce the packages to bsd and base37.tgz, I can often get as far as building nodes before the crash. This system seemed to happily run Solaris 7, booting all the way into CDE and running seeral apps at once without bombing, so I'm hesitant to start yanking RAM, but if that's the only thing suspect, I'll do it. Sounds like one of two things: either 1) No one has ever installed OpenBSD 3.7 on a SS20, and you have discovered that it really doesn't work. 2) Your computer is broke. While it may be argued that I am a no one, it isn't due to the fact that I have installed OpenBSD 3.7 on an SS20. Two SS20, in fact, testing both CDROM and floppy based installs. It isn't #1. Your computer is broke. Get troubleshooting. Your description sounds just like a memory problem, the more your install, the more memory the system uses. MAKEDEV uses a LOT of RAM. If another OS fails on the same hardware, you can be pretty sure it is bad hardware. If another OS is still working, it is at best a suggestion that it might NOT be hardware. As the system is fully booting the kernel, I don't think it is a floppy problem. Nick.
Re: ccd troubles
James Boothe wrote: I'm having a bit of trouble with ccd. I have a box with 2 80G IDE drives and 1 200G IDE drive. I'm going by the FAQ step for step here but after the ccd is configured and I get ready to run disklabel -E ccd0 it only sees the first frive. I've redone it 6 or 7 times, and switched the drive order in ccd.conf. I've tried taking each drive out one at a time and doing it with the other two drives but it always ends up the same. I'm hoping somebody can help me out here. Hre's what I have in ccd.conf ccd016 none/dev/wd2a /dev/wd1a /dev/wd0h wd2a is the 200G drive with one big empty partition wd1a is one of the 80G drives with one big empty partition wd0h is 78G, the other 2 went to the OS Any help or ideas would be appreciated. If there is any relevent information I left out let me know. Show us what you are seeing and tell us what you are expecting to see. Yes, disklabel -E ccd0 should only show you one drive, so I have no idea what you are not seeing that you are expecting. (trivial little things like dmesg, disklabel and fdisk outputs might be useful, too). Nick.
Re: hardware issues on sparc64
Bob Ababurko wrote: hello- I am trying to load 3.5 sparc64 on an Ultra2. After booting from the CD I get an error message that says( i think) it cannot find the cd-drive No...that's not what it says. or file on the CD. yes, that IS what it says. That makes little sense since I see it start to boot the CD. Is this a bad burn? I know the disc worksused it many times. Degraded? Any ideas on the error? yep. Error is pretty clear, I think... ok boot cdrom Boot device: /sbus/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],0:f File and args: kernel/sparcv9/un ix 'kernel/sparcv9/unix'. That's a funny way to spell 'bsd'! (hint: /bsd is the standard name and location for the OpenBSD kernel.) OpenBSD IEEE 1275 Bootblock 1.1 .. OpenBSD 3.5 (obj) #0: Mon Mar 29 12:00:16 MST 2004 [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/stand/ofwboot/obj open /[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],0:f/kernel/sparcv9/unix: No such file or directory You know, if you look for a file kernel/sparcv9/unix, I'll bet you find it isn't on the CDROM you are using. Might have something to do with it, I bet. :) Your Sun's firmware is trying to pull the wrong file off the CD. Set the firmware options properly, it will probably take off and run fine. See INSTALL.sparc64 for more details... Nick.
Re: Apple iBook
Nuzaihan Kamalluddin wrote: Hi, I've tried googling but with little success, I am trying to use virtual terminals (console), but I could get ctrl+alt+f1 to work. From what I see in the dmesg, it detects those keys such as F1 as a device for brightness and sound volume. http://www.openbsd.org/faq/faq7.html#SwitchConsole Note the platforms that console switching is supported on. How do I solve this? My X-window is not working too (I used the default radeon driver at xorgconfig) for my radeon mobility 9200, I'm using OpenBSD 3.7 That is a completely useless problem report and is being appropriately ignored. It also sounds like you didn't read the /usr/X11R6/README file. Nick.
Re: 8/13 snapshot and DHCP
Emmett Pate wrote: I'd like to install the latest snapshot on a laptop that's currently running 3.7-release. The boot CD fails to get a dynamic IP address. My question is where is the most appropriate archive/list to research whether this is a known problem? I just want to make sure I'm posting to the correct place before I write up the details. Thanks, here, [EMAIL PROTECTED] If in doubt, [EMAIL PROTECTED] Nick.
Re: NAT doesn't appear to work for some websites
Jonathan Weiss wrote: Hello, just an idea, are you connected to the internet via pppoe (DSL). There is a well-known problem with mtu/mss (1500/1460 vs. 1492/1452) You can use scrub in your pf.conf to solve it. something like scrub out on ppp0 all max-mss 1452 Or do a set mtu max 1492 In ppp.conf or set it in your hostname.if file if you are using a DSL router. I've seen this kind of problem in places where the link had a smaller MTU than the default. Sites which expect you to send a lot of data to them tend to just hang, waiting for the rest of the packet. Nick.
Re: Automatic setup of partitions
Gaby vanhegan wrote: Hi, I am still working on a nice automated installation CD system. It is partially a custom boot CD and partially a site36.tgz file that installs all the relevant packages, then does a scripted restoration from out backup server. It's intended for bare-metal restores in the event of complete disk or server failure, and should operate almost totally unattended. The only problem I have left to overcome is that of automatically partitioning the disk at the first stage of the process. I know that I can read an existing disklabel to a text file, and write a disklabel to a disk from the contents of a text file. My configuration file for each server would have an entry like this in it: [partitions] /= 15% swap= 512M /home= 10% /root= 10% /var= * /www= 25% /logs= 10% /tmp= 5% The problem arises when, if going on to a brand new machine, that the disk size may be different than the original it is restoring. As part of the installer (in the OpenBSD install environment, booted off an openbsd installer CD) I'd like to read the size of the disk and partition the disk accordingly. would I need to generate all of this information? Using your strategy, you would have to generate the info. Here's a (I think) better idea... Rather than trying to partition out percentages, just put in what you need... /100M swap 512M /usr 4G /var 1G /tmp 100M ... and so on. And (here's the shocker) leave the REST OF THE DRIVE UNALLOCATED! WHY should / change in size because the disk got bigger? How about /home? why would ANY partition change in size because the disk got bigger?? The partition is either big enough for the job or it isn't. Most modern hard disks are huge compared to what most users need an OpenBSD system to do for them. There is no reason to increase your fsck times just because you needed a 6G drive, and all you could find were 80G and larger. Somewhere along the lines, we decided that 100% of every disk should be allocated. That was never true, and certainly isn't getting more true. Now...here's another trick: leave the most likely to need to grow partition at the end of the disk -- for example, /var or /home. Now, if you run out of space on that partition, use growfs(8) to expand into the unused space (try that if you use the entire disk!). If one of your other partitions needs more space, create a new one in the unused space, and copy the old one to the new one, change fstab, reboot, and done. Benefits to minimal disk partitioning include: * Lower RAM requirements on fsck * Faster fsck * More ability to adjust partitioning later * clustering data in a small part of the disk decreases seek times * MUCH faster remirror if using software mirroring * (I'm sure I will remember more later) Nick.
Re: How to patch a physically weak system recommended use of sudo?
Tim wrote: Hello 1. I have a old computer that is slow and has little memory. But I want to keep it updated with patches. I can't compile these patches on the system but I could do it on another faster system. But how can I later apply the compiled patches to the weak system? In addition to the previously mentioned release(8) process (also documented here: http://www.openbsd.org/faq/faq5.html#Release), there is another thing you could do: run snapshots. They will have all the security and reliability updates (before they are in -stable, in fact), but also feature updates. 2. Alot of you seem to use sudo instead of su - when you want to do something that requires privileges. Why is this? What settings are you using for sudo? Took me a while to get interested in sudo, which is unfortunate. Way cool program. When I set up an OpenBSD system, one of the first things I do is create a personal user for myself, put myself in the wheel group, configure sudo to let wheel users do anything, log in as that user, and disable root logins. Completely disable. This does a few things... 1) Ensures that random PW guessing attacks at root will not succeed. (this isn't a huge security gain, but from completely random attackers, it gives them two things to guess, not just one. If you are going after me personally, yeah, not so hard: my most common user name is 'nick' :) 2) Ensures that for systems that have to be administered by multiple users (i.e., business users), that there is no one user who has more access than any other, and thus, you have full redundancy in maintainers. 3) In multiply administered systems, you don't have to share any passwords between administrators. Sharing PWs is a bad thing, m'kay? (su requires sharing of root PWs) note: while this is a nice trick for OpenBSD, be careful using it on lesser Unixes -- many need a PW for root access for single user mode (by default at least). As mentioned elsewhere, you can also restrict what people do on a system -- for example, I have set up controlled firewalls for schools, where a teacher could turn on and off Internet connections in their classroom. You might not want the teacher to have full access to all functionality in the firewall, but they do need root-level access to change the filter rules. So, permit the proper commands with sudo, wrap it all up in nice scripts, and it becomes very easy and very transparent. Try that with su :) Note that in this case, it isn't that I distrust the teacher's intent, I just don't trust their knowledge of Unix administration, and don't want them having accidents... if I didn't trust at least their intent, I don't think I'd let 'em in. :) Try it, it's addictive. :) Nick.
Re: kernel page fault on initial login (OpenBSD 3.7 Release)
Dave Wickberg wrote: Hi, I've just recently installed OpenBSD 3.7 (Release) on a Celeron 466 w/ 256MB of RAM. I created a boot floppy and from there the install went flawlessly. However, after booting the systems for first time I am getting a kernel page fault error as soon as I try to type in a userid. This is what I'm seeing after waiting for the login prompt and hitting one key: --- OpenBSD/i386 (wormy.starbase) (ttyC0) login: kernel: page fault trap, code = 0 Stopped atpckbc_enqueue_cmd+0x7d: sbbb 0(%eax),%al ddb kernel: page fault trap, code = 0 Faulted in DDB; continuing... ddb --- do you happen to see a message about including a ps and trace with your problem report? I'm left at a debugger prompt that seems functional so I may be able to pull some more info if required. output of ps and trace at the ddb prompt... I can log into the machine via ssh normally (as long as I don't touch the local keyboard and trigger the error). Any idea what might be going on? ok, that wins a prize for originality... :) Thanks, Dave P.S. dmesg below: and that wins a look... OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Celeron (GenuineIntel 686-class, 128KB L2 cache) 468 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real mem = 267952128 (261672K) ... cmpci0 at pci0 dev 13 function 0 C-Media Electronics CMI8338A Audio rev 0x10: irq 9 audio0 at cmpci0 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 (mux 1 ignored for console): console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 ne0: irq 9 already in use Hello. Looks like you have an ISA NIC in this thing. It also isn't configuring properly. BTW: because of the way the ne(4) on ISA driver works, don't believe that irq 9 stuff at all, it could be set to anything. pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker sysbeep0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask ed65 netmask ef65 ttymask ffe7 pctr: 686-class user-level performance counters enabled mtrr: Pentium Pro MTRR support dkcsum: wd0 matched BIOS disk 80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 WARNING: / was not properly unmounted you have a few extra things in there -- I'd remove them. The ISA NIC, the audio card (if possible, disable in BIOS if not possible to physically remove), see if the thing settles down. The ISA NIC has got my attention. I'm not certain how that would mess it up in this way, but it's the best idea I have at the moment. Nick.
Re: Complete disk disaster
Ramiro Aceves wrote: Alexandre Ratchov wrote: ... What could cause this disaster? Please, feel free to ask me for any information that you need before I wipe the entire disk and install a fresh OpenBSD again. hello, The last year a had similar problems because of a bad IDE cable. In few hours there were randomly corrupted files, but no disk error messages in the log. Finally a changed the cable and installed a fresh OpenBSD. regards, Hello Alexandre and OpenBSD fans: Many thanks for the information. As you and other OpenBSD friend said, I must search for disk failure or cable failure. I am going to install a fresh OpenBSD 3.7 and see whether I can reproduce the file corruption. This IDE disk is the slave of my main master disk (first IDE cable), so they are sharing the same cable. Of course that the slave disk connector can be broken (loosy connection). I am going to do some disk tranfers and move the cable back and forth and see whether it tiggers the corruption problem. Do you know of any disk test or utility program that can stress the disk to work hard until it fails? I'd agree, looks like a hardware problem. Note the age of your 1G drive...it has got to be close to ten years old. OpenBSD's file systems are very solid. What you saw is a very extraordinary event. I've seen something close to that only a very few times in many years and many machines of working with OpenBSD, and it always involved a power-off in the middle of some disk activity, and that's not what happened in your case. I routinely freak people out by tapping the power button on an OpenBSD machine if it is not convient to login to do a proper shutdown (yeah, I make sure it isn't busy at the time, but otherwise, just hit the button). Good way to work a hard disk: Unpack ports or source tar.gz files, 'specially with softdeps off. Nick.
Re: Problems with pf+nat+some websites
Guido Tschakert wrote: Jonathan Schleifer wrote: I don't see where you set the MTU/MSS? Are you sure you have set them somewhere else? eBay is known to have problems with bad/wrong MTU/MSS. Try adding scrub out on $ext_if max-mss 1414 to your pf.conf and adding -mtu 1454 to the route. Also take a look at pppoe(4) [*NOT* pppoe(8)!], section MTU/MSS ISSUES. Hello Jonathan, nice try, but i Don't use pppoe. We have a DSL-Router from our providewr and as I mentioned before, we had no Problems with the cisco-router doing the firewall job (Nat). so, yes you DO use PPPoE. DSL systems VERY often have a smaller-than-possible MTU. This often causes problems much like you describe. Just set it in your hostname.if file. Google for simple ping tests to find the maximum MTU you can use in your precise case...and see if setting the firewall accordingly solves your problem. Nick.
Re: raid kernel
Edd Barrett wrote: Hi there, Is there any reason why we can not include a raid enabled kernel in the distribution? (not as default, but in the same way bsd.mp is). I believe this would save me (and others?) time when upgrading OpenBSD machines. The kernel would need static device node configuration, device raid and option RAID_AUTOCONFIG There may well be a very good reason this hasnt been done before which I have overlooked, and if so I apologise in advance. For one, what if you don't want RAID_AUTOCONFIG? It would save YOU time if we set the options you needed. If not, it would cause more complaints about how could you chose such an option? Further, it would probably need to be TWO new kernels -- bsd.raid and bsd.raid.rd, as you would need an install/maintenance kernel, too. And that would add a lot of testing for developers at around this time... Personally, I'd rather keep the focus on the simple system, rather than the possible combinations required to do proper RAID testing every release... Nick.
Re: raid kernel
Edd Barrett wrote: rather then trying more stupid band-aids and wuergarounds it would be fantastic if someone could sit down and get us a software raid implementation that doesn't suck and thus can be included in the regular kernels. I havent noticed anything terribly wrong with raidframe. Why do you think it sucks? The only drawback with raidframe i see is that mirrors can only be 2 disks. * huge * complex * you can't add mirroring after initial install if you weren't planning for it at the beginning. * its recovery from events is not graceful (i.e., long boot times). That's just a starter... (can't believe I forgot the bsd.mp case...) Nick.
Re: problems using usb keyboard on sunblade 100
Robert Storey wrote: Glad that somebody else broached this topic, I was about to ask the same question. No. Your problem is completely unrelated to a Sunblade 100. You've hijacked someone else's thread. Your report is useless. It is DEAD WRONG. USB keyboards work just fine on i386 machine, assuming the HW support is there for it (plugged one into my Athlon system last weekend to fix a wedged PS/2 keyboard problem, in fact). Sounds like that isn't the case on your machine. But since you posted a useless message, we have no idea. Now...learn how to do problem reporting and start your own thread. And don't even think of posting anything without a COMPLETE dmesg. Nick.
Re: kernel page fault on initial login (OpenBSD 3.7 Release)
*sigh* found this sitting on the not done pile from over a week ago... 8-/ Dave Wickberg wrote: On 8/19/05, Nick Holland [EMAIL PROTECTED] wrote: Dave Wickberg wrote: Hi, I've just recently installed OpenBSD 3.7 (Release) on a Celeron 466 w/ 256MB of RAM. I created a boot floppy and from there the install went flawlessly. However, after booting the systems for first time I am getting a kernel page fault error as soon as I try to type in a userid. This is what I'm seeing after waiting for the login prompt and hitting one key: --- OpenBSD/i386 (wormy.starbase) (ttyC0) login: kernel: page fault trap, code = 0 Stopped atpckbc_enqueue_cmd+0x7d: sbbb 0(%eax),%al ddb kernel: page fault trap, code = 0 Faulted in DDB; continuing... ddb --- do you happen to see a message about including a ps and trace with your problem report? Actually no, just what I have above - I guess that would have come after the Faulted in DDB; continuing... line? Here's the output from ps and trace respectively: interesting. I think that's what is refered to as a double fault...and yes, the ps and trace warning probably got smushed by the second fault. PID PPID PGRPUID SFLAGS WAITCOMMAND 17210 6950 17210 0 3 0x4086 ttyin csh 8950 2863 6950 0 3 0x4084 select sshd 28407 1 28407 0 3 0x4086 ttyin getty 11599 1 11599 0 3 0x4086 ttyin getty 2024 1 2024 0 3 0x4086 ttyin getty 3200 1 3200 0 3 0x4086 ttyin getty 20666 1 20666 0 3 0x4086 ttyin getty 14322 1 14322 0 3 0x84 select cron 18567 1 18567 0 3 0x40184 select sendmail 2863 1 2863 0 3 0x84 select sshd 19286 1 19286 0 30x184 select inetd 6021 1 6021 0 3 0x84 pollntpd 21199 1 13058 83 30x186 pollntpd 3268 31864 31864 73 30x184 pollsyslogd 31864 1 31864 0 3 0x84 netio syslogd 16126 1 16126 77 30x184 polldhclient 2558 1 13058 0 3 0x86 polldhclient 11 0 0 0 3 0x100204 crypto_wa crypto 10 0 0 0 3 0x100204 aiodonedaiodoned 9 0 0 0 3 0x100204 syncerupdate 8 0 0 0 3 0x100204 cleaner cleaner 7 0 0 0 3 0x100204 reaper reaper 6 0 0 0 3 0x100204 pagedaemon pagedaemon 5 0 0 0 3 0x100204 usbtask usbtask 4 0 0 0 3 0x100204 usbevt usb0 3 0 0 0 3 0x100204 apmev amp0 2 0 0 0 3 0x100204 kmalloc kmthread 1 0 0 0 3 0x4084 waitinit 0 0 0 0 3 0x80204 scheduler swapper pckbc_enqueue_cmd(d05aad20,0,d06d3d86,2,0) at pckbc_enqueue_cmd+0x7d pckbd_set_leds(d0b5dd00,f10e,f103,80) at pckbd_set_leds+0x3c wskbd_translate(d05aa480,2,1d,1d) at wskbd_translate+0x101 wskbd_input(d0b5fe00,2,1d,1) at wskbd_input+0x3e pckbd_input(d0b5dd00,1d,80dd,16) at pckbd_input+0x53 pckbcintr(d0b5dd80) at pckbcintr+0x9f Xrecurse_legacy1() at Xrecurse_legacy1+0x86 --- interrupt --- idle_loop(d065ed80,28,0,0,8000) at idle_loop+0x21 bpendtsleep(d05b2260,4,d04f5931,0,0,,d04afc2c,0) at bpendsleep uvm_scheduler(d05b2258,3,0,d04afc2c,fff) at uvm_scheduler+0x6b check_console(0,0,0,0,0) at check_console you have a few extra things in there -- I'd remove them. The ISA NIC, the audio card (if possible, disable in BIOS if not possible to physically remove), see if the thing settles down. The ISA NIC has got my attention. I'm not certain how that would mess it up in this way, but it's the best idea I have at the moment. Makes sense. I first took out the ISA NIC and then disabled the on-board sound checking each time to see if there was any change - in each case the problem still occurred. New dmesg is: hm. ok, a couple other tests... 1) What happens if you try to bring the system up in Single User mode (boot -s from the boot prompt). I'm not sure what conclusion to draw either way on that...but... 2) What happens if you install a snapshot kernel? (that should have been my first suggestion, find out if the problem is already fixed! :) Nick.
Re: Lifecycle question
Stephan A. Rickauer wrote: Currently, our Institute investigates alternative operating systems compared to Linux. Apart from technical issues we are also concerned about lifecycle management as well. We simply don't want to reinstall/upgrade an entire OS all half year, which is the main reason, why we will no longer use half-commercial system like SuSE (= 2 year lifecycle for 'free' version). When I was working as an independant consultant, I would occassionally get calls from people who were only interested in one thing: how much I charge per hour. That's it. Wouldn't tell me about the job, or ask me how many hours I felt a job might take. They apparently believed all people could accomplish the same job in the same number of hours, or that they would all do the same job. Be careful when you pick measures for a project. There is often a lot more to it than one simple measure. :) The question is how you OpenBSD guys handle the upgrade issue. From the website I learned that -STABLE is maintained for only one year (= two releases). Given that upgrading by skipping one release is not recommended, does that mean one needs to upgrade the entire OS every half year? I couldn't get that from the website. First of all, you get lots of points for worrying about lifecycle. Too many people measure the success of a project by does it work NOW?, not how long can I keep it working? How do I upgrade it? How do other people maintain it? How do I fix it when it breaks?, etc. There are a lot of measures to how the upgrade process works out. Here are SOME: 1) Frequency (i.e., how often do you need to do upgrades) 2) Difficulty (how much human work is involved) 3) Ugency (when an upgrade is needed, how important is it that it is done *NOW*) 4) Downtime (when you do the upgrade, do you need to do it at 3:00am, or can you do it during production hours?) 5) Flexibility (what cute tricks can you do to make the process simpler, safer, easier, etc.) Yes, OpenBSD had new releases every six months, and only supports a previous release with patches for one past release, so your frequency is going to be higher. So, at the outside, you are looking at an upgrade every year, and I'd recommend staying with the active release, rather than jumping two releases every upgrade cycle. So that looks bad (kinda like my hourly rate. :) HOWEVER...the rest starts looking pretty good. :) How difficult is it to upgrade? Usually, Not Very. Granted, we don't have an automatic tool that does all the work (and thinking) for you, but all things considered, I'd rather that *you* be closely involved in the upgrade of your machines, rather than having some magic happen in the background. It certainly makes it easier to deal with issues if something goes wrong, as you have a much better idea what happened. How urgent are upgrades? Usually, not very urgent at all. That's why you run OpenBSD, right? Look at the errata pages...not a lot of them are security issues for many of the applications that OpenBSD is put to. That isn't to say they aren't important or shouldn't be fixed...but usually it is not a ok, we gotta shut down the main firewall or router NOW to implement a fix, as it is critical and exploits are running around NOW! 4) How much downtime do you experience when you do the upgrade? Well, for certain applications, you could configure your systems for ZERO downtime (CARP'd firewalls -- upgrade one, reboot, upgrade the other, reboot). Other apps, the upgrades will usually involve minimal downtime. Beware of systems that make upgrades too painless -- friend of mine recently had his Debian system rooted, he suspects a hole in the kernel. While he had been using the wonderful Debian update process, he had skipped that little detail about updating the kernel and rebooting, too inconvienent. When you are sitting on the Internet, I think convience has to be secondary to security. 5) Flexibility: wow. I love OpenBSD. :) Granted, learning a lot of this will come from time and usage, and looking at YOUR particular applications. The ability to test your installs on not identical hardware is very nice. The siteXX.tgz stuff is great. The simplicity of the installer is just magical. Anyway...look at the whole picture, not just how often you have to do upgrades. Remember: there are reasons we don't support old releases very long -- in addition to the work required, there is the fundemental moving forward philosophy of OpenBSD. With every release, they try to make the OS more secure and more correct. Not only does pushing stuff back to old releases take time and effort, but some stuff just won't go easily. The malloc(3) upgrades were a huge improvement to security, but pushing them back to 3.6 or before isn't going to happen. We don't want you to think that because you run 3.5-stable, that you are as safe or as reliable as you are if you are running -current. Lifecycle has to be part of
Re: CVSync-Problems...
[EMAIL PROTECTED] wrote: On Mon, Sep 05, 2005 at 07:03:59PM +0200, [EMAIL PROTECTED] wrote: Is there any problem with CVSYNC currently? 3.8 has been tagged, which puts heavy load on all mirrors (including cvsync mirrors). Yes I thought about that too but I wonder why it takes about 1-2 days even for the mirrors to mirror the code. :-/ first of all, it hasn't been two days. Secondly, it is an astronomcal amount of work. Every active file in the tree gets altered. That's big stuff. My cvsync output files so far are over 7M and I'm not sure its done yet. Patience. This is one of those times where slow international links can really hurt. Give it a couple more days, all will be fine. Nick.
Re: Jose Nazario's dmesg explained for OpenBSD
Siju George wrote:
Hi,
In there an online openbsd version of
http://linuxgazette.net/issue59/nazario.html
by Jose??
I understad that it is there in his book but am unable to place it on
the web :-(
Please let me know if it exists on the web!!!
Haven't seen such a beast. LONG ago (before nick@), I actually sat down
to start working on such an article for my own (now mostly abandoned)
OpenBSD help pages. That was back when I was mostly writing in Windows
and uploading to OpenBSD web servers, and it was a royal pain in the
butt to write, as almost every line in a dmesg points to a man page
('course, with what I know now, I could automate that part of the task
with a little scripting. :)
All you really need to do is understand just a little bit about how it
is displayed, and start reading. Information-wise, it is one of the
densest bits of writing you will normally see (short, perhaps, of a hex
dump of a binary executable) -- almost everything has meaning. Let's
look at a small snippet:
pchb0 at pci0 dev 0 function 0 AMD 761 PCI rev 0x12
ppb0 at pci0 dev 1 function 0 AMD 761 PCI-PCI rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 5 function 0 Matrox MGA G400/G450 AGP rev 0x04
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev 0x40
pciide0 at pci0 dev 7 function 1 VIA VT82C571 IDE rev 0x06: ATA100, channel
0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: WDC WD400BB-75AUA1
wd0: 16-sector PIO, LBA, 38166MB, 78165360 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
The first word of most dmesg lines is a device driver, and in this
case, they all are: pchb, ppb, pci, vga, wsdisplay, pcib, pciide, wd.
And (get this!) they each have a man page! Is that cool or what? :)
So, you want to learn about wsdisplay, man 4 wsdisplay.
In this case, ppb0 is a PCI-PCI bridge, giving you another PCI bus
(pci1) attached to the first one (pci0). That second PCI bus has the
vga(4) driver hanging off it, and the wsdisplay(4) driver hangs off
vga(4). There's an ISA bus which isn't being used in this snippet, but
is used later in the sysetm for the ISA devices like the keyboard, DMA
controller, etc. (take note: that's one reason why you DON'T SNIP YOUR
DMESG when asking for help!). There's an IDE interface hanging off
pci0, and that has a wd(4)-supported disk hanging off it.
Nifty, eh?
yeah, I probably should write up a how to read a dmesg article,
probably be a little long for the FAQ (or maybe not, I *do* get to make
those decisions!), but there are other places it could be put. We could
end up with a whole chorus of people on misc@ beating the snot out of
people who don't post dmesgs or snip them down to only the part THEY
think we need. Might be a good thing. :)
Nick.
Re: Lifecycle question
Stephan A. Rickauer wrote: Nick Holland schrieb: ... Yes, OpenBSD had new releases every six months, and only supports a previous release with patches for one past release, so your frequency is going to be higher. So, at the outside, you are looking at an upgrade Ok, that is the key issue here. Upgrading a firewall which has not much software installed at all, which even runs in a HA environemnt etc. is really not a big thing. But think of applications servers that run all weired kind of things ... it is a nightmare to upgrade those every half a year (not speaking of *patching* - only saying that since some posts seem to treat patching and OS upgrade similarly). well...they often are a very similar process. The good news is upgrading OpenBSD is pretty well documented in one place. However, the application servers you mention often will need *application* upgrades, probably more often than OpenBSD does. You will end up doing your upgrades one way or another. Sometimes the applications will just be patched, in other cases, you will have to upgrade to new versions. ... One main reason why companies are interested in 'enterprise products' of vendors like Redhat and SuSE etc. is the five (!) year lifecycle (at least with SuSE, don't know with RH). That means you buy your hardware, install the OS, patch five years and toss the systems afterwards. That keeps TCO pretty low compared to a (technically much better) system that I need to reinstall/upgrade 10 times during that period, don't you think? not at all. If that Redhat system gets rooted once in five years, you will lose far more than you ever lost in time doing planned upgrades/updates. Your reputation, your client/customer data is worth far more than planned upgrades. There is one thing I still don't understand. What effort is it to deliver patches (not backports) longer than just a few month - given that the overall amount of patches per release is low with OpenBSD anyway... let's say you have four security relevant patches per release, then you had 20 in 2.5 years ... Well, I am not a programmer, therefore I may not see the effort. First of all, you are trivializing the process of making patches. In some cases, yes, it is just a matter of applying the exact same patch in the earlier tree. But that is certainly not always the case. Sometimes the patch needs significant reworking to work on previous versions, and of course, each patch has to be tested on each release that is supported. Let's say a bug is found. It is fixed. A quick look is taken to see what the significance of the bug is. IF there is obviously an implication to the bug (reliability, security), it is published as an errata patch. If not, we just move on. The developers don't spend a huge amount of time looking at the implications of a bug -- it's a bug, fix it. This attitude causes the often-seen fixed six months ago in OpenBSD message on security bulletins. Sometimes people critisize the OpenBSD project because we don't wave our hands and warn people of every bug we find...well, watch the source-changes list, you will see thousands of bugs fixed every year. IF there is clearly a security implication, sure, we let people know, but if it isn't obvious, fix and move on. Here's the gotcha: Most bugs are *potential* security holes. We treat 'em as such. Most other projects are only interested in proof that a bug has security implications. We don't care, it's a bug, fix it. Anyone remember the OpenSSH bug where some people who should have known better were running around encouraging people to *ignore* our warnings and NOT upgrade until we showed the actual bug? And that was one that was CLEARLY a security bug. Any of those fixed and moved on bugs could later be found to be exploitable. OpenBSD 3.5 is not as secure as OpenBSD 3.6 was, patches or no patches. OpenBSD 3.7 is more secure than 3.6. And so on. OpenBSD is about security. Supporting old releases, even if practical, would be defeating the purpose people use OpenBSD for. I can not believe that SuSE or any other Linux vendor can provide good support for five-year-old platforms, regardless of claims. Linux thrashes too much (This week's packet filtering system is X) for this to be practical. Since they clearly don't proactively audit code anyway, how will they even find bugs in obsoleted code from three or four years ago until AFTER they are exploited? Nick.
Re: mem issue
M. Schatzl wrote: Philip S. Schulz wrote: Could be your BIOS' fault. Try sth like machine mem [EMAIL PROTECTED] Thanks a lot. That was it. http://www.openbsd.org/faq/faq4.html#InstProb for more info. Nick.
Re: OpenBSD 3.8 - http://www.openbsd.org/38.html - Question
Sebastian .Rother wrote: Theo de Raadt schrieb: Hello everybody, I found an entry on the Website wich confused me: New functionality: . . . wd http://www.openbsd.org/cgi-bin/man.cgi?query=wdsektion=4 disks have the security feature frozen before being attached to prevent malicious users setting a password that would prevent the contents of the drive from being accessed. Isn't that a disadvantage? Maybe I understand it in a wrong way but I understood, that I can't use this feature anymore on 3.8. Let me onto your machine as root for about 10 seconds, and I will show you why this disk drive feature is retarded. Yes you're right Theo but isn't that a Problem an OS shouldn't deal with? I mean that is no software related Problem. It's part of the physical security maybe or it's maybe part of your own net of trust. No, this isn't a physical security issue at all. If I slip you a really cool program that you run blindly without reading the source (which I was careful to not give you), I could easily set a disk PW...and then sell you the password. How much is your data worth to you? Send that amount to me, and I'll unlock it for you. maybe. Anyone remember the OpenSSH exploit which spread viral-like between users who were amazed that a program, run as root, would report that it successfully used OpenSSH to gain root access to your machine (meanwhile, mailing your password and network files to a drop box for later abuse)? People handed it around, to show each other. Virus powered by stupidity. Finest kind. ok, want a more innocent version? Ok, how about this: Web page fires off a Mozilla/Firefox) exploit. Exploit first invokes sudo with atactl, boom. Password set, even though you aren't running as root (unless you actually demand PWs every time you run sudo). This feature should be set only by the BIOS in the machine (if it is to exist at all, but it does, and it probably isn't going away for a while). This is a feature only if you call a time bomb a feature. There was a number of threads on this on misc@ recently... ... Sometimes this Password is the nearly last stage of defence against an Attacker. Eventually, this password will be the first stage of attack against users. Wait for it. Nick.
Re: PowerEdge 1850 w/ dual Xeon : now tested with 3.8 GENERIC.MP
Mariano Benedettini wrote: I wrote last week, about some problems I've experienced with 3.7 GENERIC.MP on a PowerEdge 1850 dual Xeon [1]. Some people suggested to try a 3.8 snapshot, and that's what I did. The system runs fine, but is there any way to make it work with 3.7 GENERIC.MP ? Of course there is! Push all the things that changed in 3.8 to 3.7. You will then end up with...a poorly done 3.8! Wow! :) Slightly more seriously, no. The OpenBSD project is about moving forward, not adding features to previous versions. 3.7 may have bugs fixed, but will not be receiving new features, support new hardware, etc. Just run 3.8. It works. Obviously, you weren't running 3.7 on this machine. There is no reason not to keep running what you have now, and bump to 3.8-release when it ships. Nick. Here's the full dmesg: OpenBSD 3.8 (GENERIC.MP) #298: Sat Sep 10 15:51:54 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP ... thanks! :)
Re: Userland Compilation Dies
Stuart Henderson wrote: --On 22 September 2005 16:52 -0400, Chris wrote: ... Replace i386 in the first line with your machine name. That's 'machine' as in 'what uname -m tells you' (i386, sparc64, macppc, hppa, [...]), not hostname. That was somewhat unclear on my part. Fixed now. Nick.
Re: Any advice on 'Indemnification'? (US Only, obviously)
L. V. Lammert wrote: I have been working with a local OS friendly hosting company to add support for OpenBSD. Unfortunately, they also support with Red Hat, SuSE, and Apple, and these vendors offer an 'Open Source Indemnification', ostensibly protecting against legal action from contributors. Of course, the OBSD project is meticulous about good copyright practices, so WE all know this isn't an issue here, but, unfortunately, the hosting company has lawyer(s) asking for similar 'Indemnification' for OBSD before they will officially allow OBSD on premesis. Question - I know that copyright law trumps 'indemnification' - especially given the BSD licenses on all project s/w, but has anyone dealt with this issue before? Can anyone point me to any legal resources that I could pass along to help satisfy the lawyers? Well, you could try a little logic with the suits. 1) Do they permit W2k? I glanced at the license there, didn't see any indemnification promises there. What if GNU sues MS and all users of W2k over improper use of code (a common bug between GPL'd code and Windows would be pretty good evidence of such borrowing). How about every other piece of software they run on their servers? 2) What if someone runs Application X on their legally safe Redhat server? Do they audit the systems to make sure *every* app offers indemnification? We had a situation at my employer recently where we had to custom compile Apache from source on an SuSE box. Were we still indemnified then? 3) Indemnification for the ISP? I've not looked over any of those contracts, but the hosting company seems to be really far out on the liability limb, would they really be protected by what you run on your machine? If it is your machine, are they really claiming they have to make sure your software meets their standards? Are they going to do this for people running supported OSs? If they are dictating standards, are they going to accept the responsibilty for those decisions? 4) Point out that OpenBSD created and maintains OpenSSH. I'm sure they would feel happy to follow the logic of their desire to be legal risk-free and remove all Cisco, Linux, and lots of other products. Sure, they may claim that Redhat provides indemnification for OpenSSH. *IF* that's true, apparently they are either pretty confident there is no problem with OpenSSH (which might imply that the OpenBSD project is pretty careful), or they don't think the real risk of a lawsuit over this stuff is significant, and it's all a big marketing game (scare you into using our product...i.e., FUD with the emphisis on F) 5) Anyone done a check to see if RedHat/SuSE/Apple really have the spare cash to spend on someone else's defense? 6) Do they feel confident that if you switch to one of the supported OSs at their demand, and if your box gets rooted and lots of people's credit card numbers (or similar) gets scattered across the 'net, that they won't have their pants sued off them by you and your customers for forcing you to run crapware (you probably wouldn't win that suit, but you could end up costing them a lot of money defending it)? 7) Do they understand that it is your money to spend with whatever vendor they wish, and I doubt they are the only hosting company around? Not sure any one of those is a killer argument, but might get them to think about what it is they are requesting. Nick.
Re: Time limited internet connection
Rod.. Whitworth wrote: On Sat, 24 Sep 2005 13:29:18 +0300, Kiraly Zoltan wrote: I want to build a home network using OpenBSD as gateway. A child in network have a computer, and like to surf the Internet. I want to drop her Internet connection at night (11:00AM) because the child don't go to sleep. 11 AM at night is a very strange time seeing that AM literally means before noon I don't want to unplug the network cable, i need to do this job with OpenBSD. Exist a proxy server or solution which limit the Internet connection using time? An example: Drop internet connection at 11:AM night and allow Internet at 6:00 AM morning. Thank you very much How about two pf.conf files (pf6to23.conf and pf 23to6.conf) and a couple of cron entries to do pfctl -f pf6to23.conf and pfctl -f pf23to6.conf ? and put a pf.conf that matches the one you want to have at boot time. You may may not want someone bumping the reset button or power switch and having the system default to [insert your undesired case here. And don't be sure your first answer will be your final answer!] I am sure you can work out the rules. Watch out for established connections keeping state. Flushing those might be good. It varies with your other needs. A few other tips... Hard code the MAC address of machines you DON'T want to turn off into dhcpd.conf, so they always get the same address, and add those addresses to an always on table. Add/remove the switched nodes by cron job/menu/whatever. I found that easier than the two PF rules files, as I kept forgetting to make changes to both/all copies. Run a self-poisoned DNS resolver so you can point completely undesired sites at something harmless, filter all dns traffic so only your firewall can get to the outside, and the inside people can get only to your DNS resolver. http://www.holland-consulting.net/tech/imblock.html I've done stuff like this at schools. Interesting results. The students actually seemed to like the DNS blocking -- they would regularly bring us sites to block (typically, pop-up hells or porn sites that were easy typos or misspellings of good sites for students). I had it set so the teachers could turn the lab on and off relatively easily (off easier than on...tap a key and run out the door and kill the 'net if needed). First year it was in use, it was ignored. Second and third years (two different teachers), it was well used. Fourth year, teacher figured she was in the room most of the time, and the room layout (teacher could see all monitors easily, students couldn't easily tell if teacher was watching), and turned it on and left it. She then forgot about the thing, and whenever the firewall would be rebooted, I'd get a call about the lab not being able to get to the Internet. :) Moral: Technology is cool. But good supervision beats technology every time. Nick.
Re: upgrade is it important ?
Budhi Setiawan wrote: dear all i guess this is stupid question, but since i very young in the openbsd land, i have a lof of question : 1. how important to make our system (OS and packages) always up-to-date ( except with security reason of course ), because some people says you should update your system at least once a year Well..the reason you probably want to run OpenBSD is because you don't have many security issues. This can actually be a mixed blessing, if not managed properly. You can plant an OpenBSD box, and pretty much ignore it for a long time. You slowly forget how you configured it. You don't have a way to deal with issues should they come up (like hardware failures). And the box keeps doing its job. And one day...you *need* to upgrade. Maybe it is a security issue. Maybe it is as minor as needing new features. Now you got a problem. Keeping your system upgradable is critical. The goal isn't to get a machine running, but to keep your application running as much as possible, and that includes life-cycle issues like upgrades, repairs, etc. OpenBSD releases are supported for one year after initial release. Releases are made every six months. Upgrade instructions are published for release-to-release, not skipping releases. I'd highly recommend keeping your system up-to-date on the most recent release (or recent -stable, if you so desire, though most people will usually not need to do that). Keep the upgrade process in mind. I'm in the middle of building a box for my office, relatively simple config, but not exactly off-the-shelf. Did it once, got it all working, now I'm doing it again, WHILE DOCUMENTING IT. I'm discovering I'm not remembering the stuff I did a month ago...I'm surely not going to recall all the little tweeks in six months or a year! :) 2. if i'm doing upgrade from 3.7 to 3.8, what happen to my old program's since my old program's using the old librari's ? is it still works without recompiling ? yep, old libraries are not deleted. Your old programs will most likely keep running. HOWEVER, you probably want to keep those up to date, too. 3. and another if, how to make my system clean after i'm upgrade from one version to another version ? because i still see the old libraries from the old version ! That kinda defeats what you wanted in #2. We can't please everyone, and it looks like we aren't going to please you on these two issues. :) You are free to delete anything you want, but don't expect OpenBSD to do that for you. We provide the bullets, you provide the foot (leg, head, whatever). Nick.
Re: ATA Soft Updates or Write Caching
Michael Favinsky wrote: I understand async is always unsafe. I don't mean async. I don't use async. I mean the hardware write cache built into the ATA drives. I read somewhere Funny...I've read lots of things that proved to be wrong. Wrote a few things, too. ;) that, unlike SCSI drives, the write cache in ATA drives results in misinformation about when data was actually written to disk. So, as I understand it, you can't use soft updates with the drive's write cache on. So you have to chose between the drive's write cache or using soft updates. eh. I'm not impressed by this argument. Most thinking along these lines seems to expect that individual sectors are successfully written or not written to disk (what if this gets written but that doesn't?), and worry about the file system's integrity based on that. Reality is a little more complicated -- the world doesn't plan power outages or communications problems for the times between when the disk isn't being written to. Interrupt a disk mid-write, the sector(s) under the head are hosed, the data in them is lost. Caching (or not caching) will not save you, IDE vs. SCSI will not save you. There are things they can try to do in the design to minimize this impact (have enough capacitance on-board to finish writing a sector when the power goes out, and detect that and not try to start the next write), but I'd not bet they would always save your data or your butt. That's for a power outage. If you are worried about a SW crash, whatever got sent to the drive (and is thus in cache) should make it out to disk eventually. Maybe. Personally, I don't ever turn off the write caching. I almost always use softdeps. I have only a few machines attached to UPSs. I don't always use the halt command before power down if it is inconvenient (Yes, I abuse the things to find out what happens and what I need to do when the unexpected happens). I've never lost one of my own file systems doing this out of the hundreds of machines I've probably abused this way. I've had a couple events at clients which were apparently triggered by power outages, one resulted in bad sectors on the hard disk, preventing a proper fsck (however, a mount -f got the system on-line, tar'd up the files without any error message, replaced the drive and was back up and running in short order). Had a few hard disks outright fail, maybe power event related, maybe not. For all the claimed wonder about SCSI drives and the foolishness of IDE caching, I had one SCSI drive blow out the entire file system when the SCSI adapter fell out of the computer (I was having a bad day, m'kay?). No power interruption to the drive, just a sudden and nasty interruption of communications from the drive to the interface. Never saw an IDE drive trash a file system that bad and still have the drive working. You are worried about tiny little things that very rarely happen in real life. Kinda like worrying about being struck by lightning while playing in the middle of a superhighway -- could happen, but if you made this risk scenareo completely vanish, on the average, it would not change your life one bit. If you REALLY want to obsess about that possible lighting strike and really believe your assessment is correct, do your own benchmarks for your own application(s), and answer your own question for your own usage. Nick.
Re: 3.6 - 3.7 make build problem
eric wrote: [ Note: I don't like doing this. I would rather use a snapshot and ] [ just get -current, but I have the Adaptec bullshit on this machine ] [ and need a kernel that support aac(4). ] I'm going from 3.6 to 3.7, and just trying to get the fscking adaptec controller working. [snip the start of a long and ugly process] Bah. too much like work. Just do this... Grab ANOTHER computer. Pentium 75, 32M RAM or better. IDE disk system. WHATEVER. Load that up with 3.7-release. Turn on softdeps. Install the system source code (/usr/src/sys). Build yourself a 3.7 kernel with that source on the 3.7 system, but with your aac driver in place. Even on a Pentium 75, should only take a few hours. Now..use that kernel instead of the GENERIC kernel to do a remote install on your problem machine as detailed in upgrade37.html. done! better idea: go get a standard SCSI adapter to plug your drives into if you can't afford a good RAID card. Granted, you lose RAID, but you will probably GAIN reliabilty. Remember: RAID isn't your goal. Reliability is. Running an unreliable RAID controller driver is probably worse than having non-RAIDed disks. I've been doing some stuff recently with two disks in a single machine to accomplish the goals of rapid repair (these are DNS resolvers and servers, very important, but also highly redundant by nature, so 100% uptime isn't an issue, but rapid repair is). I stuck a second disk in the machines. I use ALTROOT to duplicate the boot partition (including the /etc directory and its configs), and daily.local also dumps important information as well, and weekly, I dump/restore the rest of the partitions from wd0 to wd1. If I lose the boot drive, unplug the bad drive, and boot off the remaining one. Beats the heck out of most RAID systems I've seen for this application, and in fact, it provides a (lame) kind of backup, as if I manage to rm -r * from the wrong directory, I can still recover nicely. Nick.
Re: Documentation bug in WWW FAQ???
On Mon, Oct 03, 2005 at 04:35:36PM +0100, Bryan wrote: I recently attempted to dualboot my laptop with Windows XP. I was following the FAQ and came to the point where I issued this command: dd if=/dev/rsd0a of=openbsd.pbr bs=512 count=1 And the system tells me that: /dev/rsd0a not configured DON'T BLINDLY TYPE COMMANDS YOU DON'T UNDERSTAND. man wd man sd Yes, I could change that so more people could use it blindly, but multibooting IS NOT TRIVIAL. If you don't understand what you are doing, you can very easily cause data loss. I don't want this section to be too just type this or HOWTO. Nick.
Re: IDE disk problems
Steve Harding wrote: I have been chasing intermittent problems with my hard disks for a while now, and have replaced nearly everything, Statements like that without an itemized list are very dangerous. You might make someone think you really changed everything, when in reality, you just changed the things that YOU felt were important. Fortunately for you, I don't believe you. :) Things to consider: Cables Interface Power supply Drives. You only mentioned the drives. BTW: There are companies which sell too long IDE drive cables. If you want to go fast, you gotta keep 'em short, and that won't work in many boxes. including drives, in an attempt to fix them. I had convinced myself that it must be a motherboard problem so I just swapped out to the one listed below. your drives don't seem to be attached to the motherboard, so no, that's not where the problem is. (well..you could have one of those MoBos with an on-board additional IDE interface chip...) Disk errors show up at the end of the dmesg. This machine acts as a backup server, with data coming in from a Windows machine (via samba) and then a mass of rsync and gtar/gzip activity. What I was wondering is whether the problem might be something other than hardware. Any thoughts would be appreciated. hmm. Most of your problems are with wd3, but some from wd2, both of which are on the Promise controller card. You didn't mention changing that out for a different brand chip card... If for some reason, you are really fond of that Promise card which seems to be causing the problem, you might just de-tune the things to UDMA mode 4 (or 3) from the start via config(8)'ing the wd(4) driver. (man wd, man config). Might also be interesting to re-arrange the drives so that the problem drives are on the on-board controller...you could probably just disconnect the CDROM for the time being. Nick.
Re: It ain't quick, but it's sure fun
Rogier Krieger wrote: We recently deployed a new fileserver:) Most surprising thing was that it recognised a 250 GByte HDD at the first go, without real effort. Yes, I've been pleasantly surprised about how well big drives work on old machines. I've been assured that this is ok by people who know...and my testing has been pretty abusive. Giving up on the BIOS built-in LANdesk 0.99 PXEboot was a little harder, but the machine is a wee bit beyond its supported life cycle. If that's on the fxp card/chip, you might have luck downloading and updating the boot ROMs. I did eventually find an Intel download which works on most of my fxp cards with the 0.99 PXE stuff. For those interested; it's a WinNET II 5BLIP board that will primarily route a few packets on a cable modem uplink. Thanks for making this work so painlessly. Cheers, Rogier OpenBSD 3.8 (GENERIC) #0: Thu Oct 6 16:03:07 CEST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Cyrix 6x86 (486-class) real mem = 31825920 (31080K) avail mem = 21037056 (20544K) ... wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: HDS722525VLAT80 wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors yikes. Um...be really careful with this. If that 250G drive is just because it is what you had around, and you created the minimal partitions you needed, no problem, but if you used the I have the disk, I'm going to allocate the whole thing, dang it! philosophy, you may be in for trouble if you have to fsck the thing. Typically, around 1M of RAM is required to fsck 1G of disk. You can use a swap partition (NOT a swap file, as that isn't activated yet), but that's slow. But yes...fun. :) Nick.
Re: Something hosing my msdos/FAT32 file system
Tom Cosgrove wrote: Andreas Bihlmaier 8-Oct-05 15:20 ... Now what should I do about my network card? Send describtion of problem 1.) to misc@ ? 2.) use sendbug ? 3.) to tech@ ? Plenty of bug reports start out as threads on [EMAIL PROTECTED] If you're not sure, ask on [EMAIL PROTECTED] If it appears that there's a genuine problem, use sendbug(1) (preferred) or post to [EMAIL PROTECTED] As a rule of thumb, don't post to tech@ unless you are including a diff to fix/add something. Even the developers post to tech@ from time to time, to get a wider testing audience. heh. That's the nice way of saying what I was just saying. 'cept I had a line of all caps on the don't post to tech@ part. :) Nick. (nowhere near as nice and civil as Tom)
Re: Multi boot question XP and Openbsd after installation
[EMAIL PROTECTED] wrote: hello, I have installed Openbsd on my computer. The manual says now for multi-booting with XP you must do dd if=/dev/rsd0a of=openbsd.pbr bs=512 count=1 but if i do this i get a error-message that rsd0a does not exist how can i make this right. Roelof Apparently, you are refering to: http://www.openbsd.org/o/faq/faq4.html#Multibooting funny, I was just doing a slight update to that section. It is dissapointing how many people will just stupidly enter a command line into their computer without understanding what it does. It is even more amazing how people will do this when it involves the BOOT LOADER. MY GOODNESS, do you have ANY idea what you could do to your data? The new text: Note: this is a really good time to remind you that blindly typing commands in you don't understand is a really bad idea. This line will not work directly on most computers. It is left to the reader to adapt it to their machine. PLEASE re-read the very first paragraph of that section (the one starting with Multibooting is having...) OVER AND OVER until it sinks in. This is really scary stuff, 'specially combined with some of your other questions Nick.
Re: OpenBSD i386 and macppc on one HDD
Constantine A. Murenin wrote: Hello, I have an external USB 2.0 storage device with OpenBSD i386 installation and some free space. Is it possible to install OpenBSD/macppc on that spare space without breaking my i386 installation? ew, ick. How will it all work? Would it be possible to share /etc, Since /etc is on the root partition, NO. Since /etc holds configuration and your macppc and i386 machines will have different configurations, NO. /var and /home partitions between i386 and macppc? Could the HDD be bootable on both i386 and macppc? My inital response is no, you couldn't share a disk like this. My secondary response is maybe, I've got some ideas how it *might* be done, but I can think of ONLY one reason to do this: learning the boot process on both platforms very intimately. And that is a lesson best taught to one's self. If you are trying to save money, go get a job slinging burgers, take your income and buy a new disk. You will invest less time doing that than you will fighting this battle. It is just not worth it. BTW: If you try this, count on that some free space turning into all free space a few times, usually accidently, though probably at least once deliberately. Nick.
Re: RAID for dummies
Rod.. Whitworth wrote: On Mon, 10 Oct 2005 23:09:39 -0500, J Moore wrote: I want to set up an OBSD box as a file server for some Windoze boxes. I think a RAID 1 setup will provide sufficient reliability - and it appears to be the cheapest way to go. I don't desire to become an expert on RAID, I don't want to spend a lot of money, and I'm confused by what I've read on the subject. Here's how I'd like it to work: Danger! Danger! :) One of the disks craps out... an alarm goes off... I walk in with a new drive, and replace the failed one (hot-swap?)... beeping stops... no data is lost, system heals itself by taking care of the new drive... years pass, and life is good. Is this feasible - can I remain ignorant of the RAID details and jargon, and still benefit from it? Well, gee. That sounds like such a reasonable request. For HW RAID, this should be possible, unfortunately, it is rarely that simple. There's only one RAID system that I think is anything close to as simple as you desire: ... Accusys ACS-7500 or its competitors. No equity position in any of them. And yes, that's it. :) I'll admit to a lot of sweat equity in the Accusys ACS7500. I love the things -- the simplicity, the fact that they usually just work, etc. As close as they are to Just Working, I still felt the following notes are important: http://www.holland-consulting.net/tech/acs7500.html I also note that if you google for ACS7500, you end up seeing that page before seeing the Accusys website...their site is really lame. There's some stuff I'm finding burried under the covers of their website...I'll be updating my page sometime soon (hopefully). I've recently found the ACS7500 has a mostly-hidden serial interface and apparently has the ability to be managed/monitored via the ATA interface and that serial interface. That leads to some interesting possibilities (though, at the moment, ONLY possibilities -- there is no OpenBSD support for the ATA-based management at the moment, and the serial interface is mostly undocumented)... I will also (hopefully) be getting an ACS7630 soon, I'm sure I'll have something to say about it when I get it... Anyway...you HAVE to spend time getting to know whatever RAID solution you are using. Practice, practice, practice!!! Try swapping drives -- what happens if you swap a drive with a larger drive? smaller drive? how does it indicate errors? etc... In short: never trust anyone else to haul your butt out of the fire. Nick.
Re: Blocking p2p via pf
David Elze wrote: Hi, I'm trying to block p2p traffic via pf on OpenBSD 3.x. Unfortunately, all new p2p-clients are able to use dynamic ports or even (ab-)use http-ports etc. so blocking well known p2p-ports is not enough. yep. Apart from blocking ports I just see two possibilities: - slow connections down very hard on well known p2p-ports, so the p2p-clients can connect but don't get speed at all (still, other dynamic ports could be used) - try to look into each datagram and scan for typical p2p-stuff (what is typical, this approach would cost to much computing time) - think outside the traditional box. :) Any hints? Unfortunately, I didn't find a lot of stuff regarding this exept the well known 'iptables-p2p' which is a match module for iptables but hey, I love pf :-) If there are too many IP addresses and ports to effectively block, maybe look for something else...like, maybe mangle the DNS queries. One tiny little DNS block, and kazaa goes bye-bye. Two, and AIM is blocked. Theoretically, this is a weak solution. However, PRACTICALLY speaking, it's simple and very effective. Other than blocked services opening up alternative entry points, I've not actually seen anyone bypass this system in real life (for example, AOL offered a web-based IM alternative, that required an additional block). It isn't a secure solution, but it seems mighty effective. http://www.holland-consulting.net/tech/imblock.html Nick.
Re: upgrade 3.6 - 3.7
Erwin Zbinden wrote: Hi I am upgrading a i386 box from 3.6 to 3.7. In the upgrade guide I miss any hint to mergemaster. Is it obsolete? Tia Erwin Mergemaster is not a part of the base system. OpenBSD is and should be a complete system, the set of CDs, and in fact, the base download, should be all you need to use it and maintain it. Therefore, the upgradeXX.html documents are written to use obscure and sophisticated commands like cp(1) and mv(1). :) I've got nothing against Mergemaster, people whom I respect greatly use it and recommend it. But unless or until it goes into the base system (and it won't due to OTHER dependencies, as I recall), the official upgrade process won't include it. Feel free to write your own upgrade guide using whatever tools you want. :) Nick.
Re: RAID for dummies
J Moore wrote: Anyway...you HAVE to spend time getting to know whatever RAID solution you are using. Practice, practice, practice!!! Try swapping drives -- what happens if you swap a drive with a larger drive? smaller drive? how does it indicate errors? etc... In short: never trust anyone else to haul your butt out of the fire. Not quite sure what point you're trying to make here... are you advocating that one develop expertise in all areas to become totally self-sufficient? If so, I suppose you are all at once: thoracic surgeon, firefighter, psychiatrist, tax lawyer, microbiologist, etc, etc, etc. No, I'm advocating that if you pick of a scalpel, that you understand how to perform surgery on the species you are going to be cutting on. If you pick up a fire hose, you understand what happens when the water hits full pressure. Etc. Taxes? ok, got me there, no one understands tax law. If you don't wish to spend time to learn the RAID tool of your choice, do everyone a favor: skip the RAID. Really. It will *cause* more downtime than it will ever save you. Some solutions are pretty easy (the Accusys is up there as one of the easiest, certainly the easiest I have seen and used), but there are still things you should get to know BEFORE an event, not after... RAID systems in the hands of people who assume magic will happen cause massive down-time problems. In the hands of people who know how to do it, yes, good things really can happen. But I doubt there are any truly mindless RAID options available. Nick.
Re: RAID for dummies
J Moore wrote: On Thu, Oct 13, 2005 at 07:47:48AM -0400, the unit calling itself Nick Holland wrote: Not quite sure what point you're trying to make here... are you advocating that one develop expertise in all areas to become totally self-sufficient? If so, I suppose you are all at once: thoracic surgeon, firefighter, psychiatrist, tax lawyer, microbiologist, etc, etc, etc. No, I'm advocating that if you pick of a scalpel, that you understand how to perform surgery on the species you are going to be cutting on. If you pick up a fire hose, you understand what happens when the water hits full pressure. Etc. Taxes? ok, got me there, no one understands tax law. And I'm suggesting that trying to be an expert in everything is not a realistic goal... why pick up a scalpel at all (to haul your butt out of the fire) if your neighbor has invested years in becoming a thoracic surgeon? If surgery is required, I would choose to let the experienced surgeon haul my butt out of the fire, and concentrate my energy in my field of interest. Sorry if I confused you on that point. From your original post, you said you did not desire to become an expert on RAID. You didn't talk about farming the maintenance of this system to other people. RAID systems in the hands of people who assume magic will happen cause massive down-time problems. In the hands of people who know how to do it, yes, good things really can happen. But I doubt there are any truly mindless RAID options available. Now I'm confused... are you suggesting that the investment required to successfully use an ACS-7500 even approaches that required for the do-it-yourself RAID setup? Not at all. A car with an automatic transmission is much easier to drive than a car with a stick shift. However, without proper training, you can hurt yourself and others with either. The Accusys boxes are very simple, seemingly reliable, but if you don't play with them for a bit and understand how they work, you can still can screw things up. IN FACT, there are so many neat things you can do with the Accusys boxes, you might be tempted to do something silly and wrong, believing that it will save you from everything. If you aren't willing to learn how the thing works, your overall reliability and uptime will probably be better with a single drive, no RAID at all. Sure, the drive could fail, but your recovery options will be very clear and direct. Nick.
Re: HOWTO on spamd+transparent bridge under OpenBSD
Graham Toal wrote: steven mestdagh [EMAIL PROTECTED] wrote: On Fri, Oct 14, 2005 at 03:11:59PM -0500, Graham Toal wrote: For anyone who is interested, I've written up a document on how to install OpenBSD, configure it as a transparent bridge, then install spamd on it. It was written primarily for our campus computer center who want to know how to do it if something happens to me (like I get a better job elsewhere for example ;-) ) but I think I've written it generally enough that it will be of use to anyone. The page is here: http://wiki.utpa.edu/InfoSec/GreyListingInstall?action=print Some quick feedback... You write (allow me to turn off caps): The disk formatting is a major pain. Why? I don't know why, I just know that both myself (experienced in BSD and BSDI from days gone by, and linux in recent years, but not OpenBSD at all) we see that. plus a colleague at work who has a fair bit of OpenBSD experience both have wasted literally days with formatting problems. So having found a working recipe that seems easy, I thought it was worth pointing out to folks that if you do something else, you might hit the hassles we did. I had tried to reuse an old partition table and failed even though it sure looked OK to me - the install program wouldn't progress past the formatting section; my friend had problems when he formatted the swap partition before the data partition. SNIP Oh. My. Gawd. This disk layout section is so wrong. Your explaination of problems are wrong (hint: you don't format the swap partition at all!). There's nothing here to even correct. Your almost every step is just plain WRONG. You have successfully designed a system that some platforms won't even boot, and you have defeated a lot of OpenBSD security. Your working recipe is a disaster. I can't make myself read further. Stop. You clearly have no idea what you are doing. If you have something that works for you, fine, go ahead, use it. PLEASE DO NOT ATTEMPT TO GUIDE PEOPLE UNTIL YOU UNDERSTAND WHAT THE HECK YOU ARE DOING, UNTIL YOU HAVE READ (and understood) THE EXISTING DOCUMENTATION. I fear what will happen if people follow your advice. Good documentation for what you are trying to help people with exists, you are leading them into very unhappy directions. Writing crap like this and pretending to help people makes you into a menace. Please stop. Nick.
Re: No DMA for Cyrix Cx5530 IDE?
Michael Frost wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I wonder if the Cyrix Cx5530 IDE is not supported by OpenBSD v3.8/i386. I'm a newbie to OpenBSD and therefore would like to post my dmesg, maybe somebody is able to clear the thing up and give me some advice howto support DMA modus for my 2,5'' harddisk: 2.5? This a laptop? What is this thing? Step one: provide dmesg. Done! OpenBSD 3.8-current (GENERIC) #179: Thu Oct 6 11:32:36 MDT 2005 step two: try -current. done. :) good problem reporting. Gotta at least look. (we complain when people make bad problem reports, but really, it just gives us excuses to ignore you and make fun of you) [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by National Semi (CyrixInstead 586-class) 301 MHz cpu0: FPU,TSC,MSR,CX8,CMOV,MMX cpu0: TSC disabled real mem = 132227072 (129128K) avail mem = 114065408 (111392K) hm. looks like a lot of RAM for a laptop of that vintage... ... pciide0 at pci0 dev 18 function 2 Cyrix Cx5530 IDE rev 0x00: no DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (other hardware responding at addresses) whoa. I've seen this before... What is this thing? (oops, I asked that already) (and why can't I recall my AP's IP address? AH, there it is...) wow, the machine I was looking for gives very similar error: pciide0 at pci0 dev 18 function 2 Cyrix Cx5530 IDE rev 0x00: no DMA, channel 0 wired to compatibility, channel 1 wired to c ompatibility pciide0: channel 0 ignored (other hardware responding at addresses) pciide0: channel 1 ignored (not responding; disabled or no drives?) Notice the curious inversion from your system... This machine I have was intended to be a small mainframe terminal -- running QNX, X, and some terminal emulator, with an SNA card in it. It originally booted from a 16M or 8M disk-on-module chip (not supported by OpenBSD). I had presumed the DOM chip was the reason for the pciide problems, but maybe there is more to it than that. Anyway...your machine is very similar to mine, though mine is a 233MHz machine. Whatever you are looking for UDMA for...don't. 1) the machine isn't likely to provide it, a little googling seems to indicate that lots of issues exist with this on other OSs, too. 2) Even if it did, you will find the pathetic disk performance the least of your problems. This thing was designed for low power consumption, not speed. If you are worried about disk performance, you have the wrong box for a lot of other reasons. Something is going wrong with the PCIIDE support, so it falls back to wdc(4), which is completely non-DMA. I slapped an IDE drive in mine at one point, did a make build on it...it was glacial. Never seen something that ran that slowly that claimed a three digit clock speed. However, stuck a wi(4) card in it, and it makes a great AP with authpf keeping the riff-raff out, booting from a Compact Flash module now. I thought about stuffing a dc(4) quad-NIC in it and using it as my main firewall, but never got around to it (and really, I prefer faster machines for firewalls, mostly due to the ssh login time. :). Nick.
Re: question about patch submission
JD Harrington wrote: Is there any documentation outlining the preferred process for patch submission from members of the community? I've got something small I'd like to send up, but I'm not entirely sure about where to send it (misc@, bugs@/sendbug, or tech@) as it's not a bug, per se, and I'm also not sure if there's a preference as to where in the src tree the patch should be generated from. I've poked around the site and googled for related list archives, but I can't seem to turn anything concrete up at the moment. Thanks! -JD diff -u. Non-unified diffs cause us to go blind. In-line, not attachment. Make sure your mailer doesn't mangle the diff or the spaces in it. i.e., mail it to yourself, see if you can apply it to a clean tree before you mail it to us. Odds are, your mailer will do something you don't expect, and we'll all laugh at you if you don't. If you are diffing one file, it probably doesn't matter much where you root the patch, at least if the patches we sling around internally are of any measure. If you are patching many files, I guess I prefer /usr/src as the root. If you get the rest of this right, we might be tollerant here. :) Including a usable unified diff pretty well qualifies you for posting to [EMAIL PROTECTED] It also enables you to give verbal beatings to those that don't. :)
Re: congrats on OpenBSD SAN... one little question
Jason Dixon wrote: On Oct 20, 2005, at 1:49 PM, Joe Advisor wrote: Congrats on the cool OpenBSD SAN installation. I was wondering how you are dealing with the relatively large filesystem. By default, if you lose power to the server, OpenBSD will do a rather long fsck when coming back up. To alleviate this, there are numerous suggestions running around that involve mounting with softdep, commenting out the fsck portion of rc and doing mount -f. Are you doing any of these things, or are you just living with the long fsck? Thanks in advance for any insight into your installation you are willing to provide. This is just a subversion repository server for a bunch of developers. There are no dire uptime requirements, so I don't see a lengthy fsck being an issue. Not to mention the hefty UPS keeping it powered. Sorry if this doesn't help you out, but it's not a big problem on my end (thankfully). If it was, I would have just created many slices and distributed projects equally across them. I'm working on a couple big storage applications myself, and yes, this is what I'm planning on doing, as well. In fact, one app I'm going to be turning on soon will be (probably) using Accusys 7630 boxes with about 600G storage each, and I'll probably split that in two 300G pieces for a number of reasons: 1) shorter fsck 2) If a volume gets corrupted, less to restore (they will be backed up, but the restore will be a pain in the butt) 3) Smaller chunks to move around if I need to 4) Testing the storage rotation system more often (I really don't want my app bumping from volume to volume every six months...I'd rather see that the rotation system is Not Broke more often, with of course, enough slop in the margins to have time to fix it if something quit working.) 5) Cost benefit of modular storage. Today, I can populate an ACS7630 (three drive, RAID5 module) with 300G drives for probably $900. I could populate it with 400G drives for $1200. That's a lotta extra money for 200G more storage. Yet, if I buy the 300G drives in a couple storage modules today, and in about a year when those are nearing full, replace them with (then much cheaper) 500G (or 800G or ...) drives, I'll come out way ahead. Beats the heck out of buying a single 3+TB drive array now and watching people point and laugh at it in a couple years when it is still only partly full, and you can buy a bigger single drive at your local office supply store. :) With this system, I can easily add-on as we go, and more easily throw the whole thing away when I decide there is better technology available. Would I love to see the 1T limit removed? Sure. HOWEVER, I think I would handle this application the exact same way if it didn't exist (that might not be true: I might foolishly plowed ahead with the One Big Pile philosophy, and regretted it later). For this application, the shorter fsck is not really an issue. In fact, as long as the archive gets back up within a week or two, it's ok -- the first stage system is the one that's time critical...and it is designed to be repairable VERY quickly, and it can temporarily hold a few weeks worth of data. :) Nick.
Re: Adaptec 1205SA
Chris Zakelj wrote: Szechuan Death wrote: Speaking of which: Which driver supports the Adaptec 1205SA? Anybody? Bueller? Manpages are not forthcoming. Don't know if any of them do, especially now that Adaptec SCSI has been removed from the kernel. However, if any dev wants it, I just removed one from my gaming machine, and I'd be more than happy to send it their way. actually, only the Adaptec RAID controllers using the aac(4) driver were removed. Most of the simple SCSI drivers continue on... Were I a betting man, I'd bet the 1205SA is supported by the pciide(4) driver. It appears to be a very basic SATA controller. If it's not supported by pciide, it probably could be. Probably isn't even an Adaptec chip on it. Semi-related: I've also got a Promise PDC20269 PATA-133 controller sitting around that any dev is welcome to if that driver (probably part of wd or pciide) needs work. That chip/card is specifically listed in i386.html (pciide, again), is there a problem you are having with it? Nick.
Re: congrats on OpenBSD SAN... one little question
per engelbrecht wrote: Nick Holland wrote: ... Would I love to see the 1T limit removed? Sure. HOWEVER, I think I would handle this application the exact same way if it didn't exist (that might not be true: I might foolishly plowed ahead with the One Big Pile philosophy, and regretted it later). Hi Nick We can argue back and forth on the pros and cons of building 1TB partitions or not, but the need for these giant allocations are real enough and from a commen/broader view (small business) the demand is also moving closer and closer. At work we have a disk-to-disk backup server for (for customers) with one 1.5TB (SATA raid5) backup partition. The app works that way and if each customer start using it and used =20GB per customer, we would need at least 3.5TB more disk space. Breaking up in smaller chunks is not always possible/practical. I would appresiate an unlimited filesystem one day - but not at the cost of potentially losing data! I would also just love to see OpenBSD large-scale enterprise SAN/NAS solutions in the LISA program some day :) No denying it is an annoying limit, but talking about it won't change it. Someone will have to be annoyed enough to sit down and devote their time to figuring out how to deal with it appropriately. No amount of begging by those of us who lack the skills (or in my case, the rigor -- I keep writing programs and finding stooopid bugs and say to myself, good thing I don't do file system code! ;) will change that. File system code is about as scary as it gets to work on. Mess up the memory allocation system, or who knows what else, you can always reboot after the panic, and most of your data is still there. Mess up the file system code in a subtle way...you could be writing slightly wrong data to disk for weeks before noticing that you have 2T of trash. In the mean time...while yes, there are apps where One Big Chunk is the only solution, there are lots of apps where Several Smaller Chunks is a tollerable solution, and some where it is even the PREFERED solution. In cases where One Big Chunk is the only solution, OpenBSD isn't a contender. In places where it is a tollerable or even prefered solution, OpenBSD's other advantages can still be leveraged. (did I just say leveraged?? oh my..the damned tie is cutting off oxygen to my brain!) Nick.
Re: Interrupts on quad nics
Digging through the backlog, and found this unanswered... Joe S wrote: Since some quad nics share 1 interrupt, what kind of performance impact would I be dealing with versus using 4 indiviual nics? Debating wehter to use a Phobox P430TX quad dc nic or individual fxp0 nics. Just test it and find out. On the criteria you specify, shared vs. individual IRQs, you are unlikely to see any difference. (it was believed that shared IRQs are faster, but the difference was very slight last time someone actually measured, I do believe.) It depends on what machine you stick that Phobos card in, anyway. The Compaqs I've stuck 'em in give 'em shared IRQs, (Celeron 300) ppb1 at pci0 dev 13 function 0 DEC 21152 PCI-PCI rev 0x03 pci2 at ppb1 bus 2 dc0 at pci2 dev 4 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2c lxtphy0 at dc0 phy 1: LXT971 10/100 PHY, rev. 1 dc1 at pci2 dev 5 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2d lxtphy1 at dc1 phy 1: LXT971 10/100 PHY, rev. 1 dc2 at pci2 dev 6 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2e lxtphy2 at dc2 phy 1: LXT971 10/100 PHY, rev. 1 dc3 at pci2 dev 7 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:2f lxtphy3 at dc3 phy 1: LXT971 10/100 PHY, rev. 1 (I'm sure not all Compaqs do that, but I seem to have a pile of P90 through PII-450s that seem to only allocate one IRQ to the PCI bus, only thing in common between them is the Compaq badge on the front. This machine had at least two other devices sharing that same IRQ 11. Put four fxp cards in there, you will see them all on IRQ 11, too). however, the same kind of card in this Dell does not: (Celeron 400) ppb1 at pci0 dev 13 function 0 DEC 21152 PCI-PCI rev 0x03 pci2 at ppb1 bus 2 dc0 at pci2 dev 4 function 0 DEC 21142/3 rev 0x41: irq 9, address 00:60:f5:08:54:20 lxtphy0 at dc0 phy 1: LXT971 10/100 PHY, rev. 1 dc1 at pci2 dev 5 function 0 DEC 21142/3 rev 0x41: irq 10, address 00:60:f5:08:54:21 lxtphy1 at dc1 phy 1: LXT971 10/100 PHY, rev. 1 dc2 at pci2 dev 6 function 0 DEC 21142/3 rev 0x41: irq 5, address 00:60:f5:08:54:22 lxtphy2 at dc2 phy 1: LXT971 10/100 PHY, rev. 1 dc3 at pci2 dev 7 function 0 DEC 21142/3 rev 0x41: irq 11, address 00:60:f5:08:54:23 lxtphy3 at dc3 phy 1: LXT971 10/100 PHY, rev. 1 (I'll spare you the dmesg from the five 4port NIC dell I set up. Needless to say, IRQs were shared. :) So, if you have to switch between different HW to get shared vs. personal IRQs, you have changed a lot more variables... You will see a much bigger difference about the different chips you have (dc vs. fxp, or even which fxp version you get). Probably even bigger than that would be the design of the machine -- if you have a machine where each individual NIC is on a separate PCI bus, you may see better performance than having them all on one bus (like you would on the quad-port card). HOWEVER... *IF* you really have a situation where you would really see a performance difference between the Phobos and four fxps, you probably need to say, WRONG CARD and grab some good gigabit NICs instead. This isn't auto racing, no one will ever notice a percent or two difference in performance. If you got to use a stopwatch or benchmark to see the difference, it's wasted effort. To get any real difference, you will need some (even) better NICs. Nick.
Re: root on raidframe
Ken Gunderson wrote: Greets: I've been exploring root on raidframe w/a pair of mirrored disks. Once I bring something like this up I then go ahead and do my best to break it, test out recovery scenarios, etc. smart. VERY smart. :) Which brings me to the question at hand. Following a hard failure the system must perfomr a parity check on the raid volume(s) prior to fsck'ing and completing booting. Depending on disk size, speed, and number of volumes, this can easly require a few hours of wait time before being able to bring the system back online. Now my question is whether there is some way to shorten this delay that I'm missing? yes. RAIDframe as absolutely little as you NEED to. Soft-mirroring (or hardware-mirroring, for that matter) more than you absolutely need to is foolish. Let's look at a simple mail server for an example (since you didn't describe your app): / /usr /var /home /var/mail /tmp Where does stuff change rapidly and critical to not lose even a minute's worth of change if possible? /var/mail, probably. MAYBE /home. So, RAIDframe those. / ? Use the altroot process for that. /usr ? dump/restore it to a second disk nightly or weekly. /tmp ? well, as I'm basically assuming your system is going down if a drive fails, I'm going to argue that /tmp does not need to be mirrored. You probably don't need to be mirroring your /usr/src, /usr/ports or /usr/obj directories, even if you really DID want to mirror /, /usr, /tmp, and friends. Now, after an event, only /var/mail (and maybe /home) have to be rebuilt. One nice thing about RAIDframe (or ccd(4)) is that you can mirror only a little slice of a big drive if you so desire. Even if you want to keep the entire system mirrored, you could probably get away with a 2G or 600M system for a lot of applications, rather than 80G or whatever the smallest disk you can get now is. With HW mirroring, you end up doing the entire 80G (or 250G when the purchasing dept. says, hey, it was only $20 more, so we got the bigger one!) Yes, it isn't The Solution for all situations, but it helps in a lot of places. Nick.
Re: Large partition
Beck Zoltan Gyula wrote: Hi! I would like to ask if it is possible to use a large, more than 2T diskarray or CCD? In FAQ: 14.7 - What are the issues regarding large drives with OpenBSD? OpenBSD supports an individual file system of up to 231-1, or 2,147,483,647 sectors, and as each sector is 512 bytes, that's a tiny amount less than 1T. It's true I can't use my 2T partition? Best Regards Bzg 2TB is greater than 1TB, so yes, it can not be one file system. it COULD (and probably SHOULD) be multiple file systems on one array. I can think of lots of apps which might need more than 1TB. I can't think of many apps which need more than 1TB now that might not some day need more than 10TB. It is probably easier to bolt-on new partitions later than to rebuild on a new array later. Plan for multiple partitions now... Nick.
Re: Machine unable to build -STABLE kernel, PEBCAK
On Thu, Oct 27, 2005 at 10:21:16AM -0500, C. Bensend wrote: Hey folks, I seem to have gotten myself into a pickle, and I'm not quite sure how screwed I am. I have an AMD64 server that has been having some stability issues ...^ try to build -STABLE again. 'make clean' works fine, but when I attempt a 'make depend' for the kernel: ... Stop in /usr/src/sys/arch/i386/compile/GENERIC (line 702 of Makefile). ... OpenBSD 3.6-stable (GENERIC) #4: Wed Jun 22 08:30:37 CDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC Looks like you were doing some accidental cross compiling there. :) Nick.
Re: scp/sftp performance myths
frantisek holop wrote: hi there, poking around in the HP ssh docs, one can see the following in the FAQ: Q: How is the performance of HP-UX Secure Shell? A: Compared with conventional file transfer methods, the scp command is 2 - 3 times slower than rcp, and sftp is 2 to 3 times slower than ftp. This is because HP-UX Secure Shell authenticates both the server and users, and encrypts both the data and the password. In addition, HP recommends you use the /dev/random device on your system to significantly speed up program initialization. i find it interesting that most of the user community perceives scp/sftp multiple times slower then their not encrypted counterparts. I find that interesting, too. I was just explaining to my GF's six-year-old niece yesterday that you shouldn't believe everything someone says. Been doing some interesting tests recently... scp'ing large (100M+ files) from a Celron 566 to a PIII-750 went at about 4MB/s, using fxp cards on both sides. Somewhat less than half wire speed. Room for improvement, certainly, but not three times. And that's on two-generation old hardware! (and several switches, a router, and a firewall between them) scp'ing the same large files from the same PIII-750 to an AMD64 3000 processor on the same subnet (though with a LOT of switches between them) managed over 8MBs (sk(4) chip on the amd64, 100Mbps network). Not going to get much better than that. (Well..actually, I *did* get impatient, as there was several hundred gig to transfer, so I pulled the disk out of the PIII and put it in the amd64 and did a disk-to-disk copy). i think it would be very nice to have a performance page on the openssh site describing what should be expected, what is normal and the intended performance of ssh to clear up possible misunderstandings. (like mine here) too many variables. I'd like to grab another amd64 system and a gigabit switch and try my test again, but on modern HW, you should be moving a fair chunk of data. There are some things you should just test yourself, and find your own bottlenecks. BTW: that PIII-750 had a very slow disk system for its age -- UDMA2. The cables were way too long to run at a more respectable rate. Note the difference in the network. And so on and so on. Oh, and OpenSSH is very multi-platform...again, more variables. The people complaining that they didn't get the expected performance they saw on such a page would be a never ending nightmare. For example, when I first started writing this, I forgot that the my two test cases involved one common machine, but two very different network paths... Nick.
FAQ v3.8
I'd like to take a moment to bring a few new things in the FAQ to your attention: 1) upgrade38.html ( http://www.openbsd.org/faq/upgrade38.html ) In addition to the usual stuff you have been used to, note the upgrade38.patch file which is linked from this page. This patch file attempts to make the changes that took place between 3.7 and 3.8 to the files that you may have modified (i.e., the ones you can't just copy over from etc38.tgz). Note: It CAN NOT always work. And, it may really mess things up under some circumstances if used carelessly. Use with care (and backups and repair plans). If it works out well for people, I'll keep making them for the future. If it works out poorly, it may just vanish from the website... 2) Introducing, FAQ 15 - The OpenBSD packages and ports system! Steven Mestdagh (author of the also pretty new FAQ 13 - Multimedia has once again come through with a wonderful new page providing much greater documentation for the OpenBSD packages and ports system. Packages and ports have gone through some major evolutions in the last few releases, but the old faq8.html documentation had been lagging. Many thanks to Steven for his hard work on this! Nick.
Re: Problems installing 3.8 on SS5 (complete dmesg).
Matthew Weigel wrote: Despite the lack of responses, I persevere... below is the complete dmesg, if anyone was waiting for it. OpenBSD finds a total of 120 unknown PHYs (ukphy) on my Quad Fast Ethernet 2.0 card, 30 per hme, and 8 Lucent PHYs (luphy), 2 per hme. Now that you have a complete dmesg (or actually, I suspect, a console capture), you are in a good position to file a good Problem Report (PR). HOWEVER, one last thing to do: try -current, see if the problem is still there, or has already been fixed. Nick. OpenBSD 3.8 (GENERIC) #428: Sat Sep 10 12:38:22 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/sparc/compile/GENERIC real mem = 268058624 avail mem = 241127424 using 200 buffers containing 13107200 bytes of memory bootpath: /[EMAIL PROTECTED],1000/[EMAIL PROTECTED],10001000/[EMAIL PROTECTED],840/[EMAIL PROTECTED],880/[EMAIL PROTECTED],0 mainbus0 (root): SUNW,SPARCstation-5 cpu0 at mainbus0: MB86904 @ 110 MHz, on-chip FPU cpu0: 16K instruction (32 b/l), 8K data (16 b/l) cache enabled obio0 at mainbus0 clock0 at obio0 addr 0x7120: mk48t08 (eeprom) timer0 at obio0 addr 0x71d0 delay constant 52 zs0 at obio0 addr 0x7110 pri 12, softpri 6 zstty0 at zs0 channel 0 (console i/o) zstty1 at zs0 channel 1 zs1 at obio0 addr 0x7100 pri 12, softpri 6 zskbd0 at zs1 channel 0: no keyboard zstty2 at zs1 channel 1: mouse slavioconfig at obio0 addr 0x7180 not configured auxreg0 at obio0 addr 0x7190 power0 at obio0 addr 0x7191 fdc0 at obio0 addr 0x7140 pri 11, softpri 4: chip 82077 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec iommu0 at mainbus0 addr 0x1000: version 0x4/0x0, page-size 4096, range 64MB sbus0 at iommu0: clock = 22 MHz dma0 at sbus0 slot 5 offset 0x840: rev 2 esp0 at dma0 offset 0x880 pri 4: ESP200, 40MHz, SCSI ID 7 scsibus0 at esp0: 8 targets sd0 at scsibus0 targ 1 lun 0: SEAGATE, ST34371W SUN4.2G, 7462 SCSI2 0/direct fixed sd0: 4094MB, 3882 cyl, 16 head, 135 sec, 512 bytes/sec, 8385121 sec total sd1 at scsibus0 targ 3 lun 0: IBM, DDRS34560SUN4.2G, S98E SCSI2 0/direct fixed sd1: 4094MB, 3882 cyl, 16 head, 135 sec, 512 bytes/sec, 8385121 sec total cd0 at scsibus0 targ 6 lun 0: TOSHIBA, XM-4101TASUNSLCD, 1755 SCSI2 5/cdrom removable bpp0 at sbus0 slot 5 offset 0xc80: DMA2 ledma0 at sbus0 slot 5 offset 0x8400010: rev 2 le0 at ledma0 offset 0x8c0 pri 6: address 08:00:20:21:3f:1d le0: 16 receive buffers, 4 transmit buffers audiocs0 at sbus0 slot 4 offset 0xc00 pri 9 audio0 at audiocs0 power-management at sbus0 slot 4 offset 0xa00 not configured cgsix0 at sbus0 slot 1 offset 0x0: SUNW,501-2325, 1152x900, rev 11 wsdisplay0 at cgsix0 wsdisplay0: screen 0 added (std, sun emulation) hme0 at sbus0 slot 2 offset 0x8c0 pri 7: address 08:00:20:be:59:08 rev 34 luphy0 at hme0 phy 0: LU6612 10/100 PHY, rev. 1 luphy1 at hme0 phy 1: LU6612 10/100 PHY, rev. 1 ukphy0 at hme0 phy 2: Generic IEEE 802.3u media interface ukphy0: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy1 at hme0 phy 3: Generic IEEE 802.3u media interface ukphy1: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy2 at hme0 phy 4: Generic IEEE 802.3u media interface ukphy2: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy3 at hme0 phy 5: Generic IEEE 802.3u media interface ukphy3: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy4 at hme0 phy 6: Generic IEEE 802.3u media interface ukphy4: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy5 at hme0 phy 7: Generic IEEE 802.3u media interface ukphy5: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy6 at hme0 phy 8: Generic IEEE 802.3u media interface ukphy6: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy7 at hme0 phy 9: Generic IEEE 802.3u media interface ukphy7: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy8 at hme0 phy 10: Generic IEEE 802.3u media interface ukphy8: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy9 at hme0 phy 11: Generic IEEE 802.3u media interface ukphy9: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy10 at hme0 phy 12: Generic IEEE 802.3u media interface ukphy10: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy11 at hme0 phy 13: Generic IEEE 802.3u media interface ukphy11: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy12 at hme0 phy 14: Generic IEEE 802.3u media interface ukphy12: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy13 at hme0 phy 15: Generic IEEE 802.3u media interface ukphy13: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy14 at hme0 phy 16: Generic IEEE 802.3u media interface ukphy14: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy15 at hme0 phy 17: Generic IEEE 802.3u media interface ukphy15: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy16 at hme0 phy 18: Generic IEEE 802.3u media interface ukphy16: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy17 at hme0 phy 19: Generic IEEE 802.3u media interface ukphy17: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy18 at hme0 phy 20: Generic IEEE 802.3u media interface ukphy18: OUI 0x3ffbff, model 0x003e, rev. 15 ukphy19 at hme0 phy 21: Generic IEEE
Re: / never unmounts properly
Han Boetes wrote: Michael Favinsky wrote: I just installed 3.8 on a server that never had OpenBSD on it. OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005 That's not 3.8: 3.8-stable was compiled on september the 26th. Yes, that *is* 3.8. That *is* what is on the CDs. I have no idea what you are babbling about here, 3.8-stable is only started to be maintained on release day, Nov. 1, and running 3.8-release is very acceptable. $ ftp -a ftp://rt.fm/pub/OpenBSD/3.8/i386/bsd ... 150 Opening BINARY mode data connection for 'bsd' (5281094 bytes). 100% |**| 5157 KB ... $ config -ef bsd OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC Enter 'help' for information ukc (yeah, a demo off the CD would be more impressive, but I seem to have already misplaced my 3.8 CDs... 8-/ D'oh, there it is!) $ sudo mount /dev/cd0a /mnt $ cp /mnt/3.8/i386/bsd . $ config -ef bsd OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC Enter 'help' for information ukc Nick.
Re: OpenBSD CDROM layout definition, Copyright Infringement.
Siju George wrote: Hi, I been asked about http://www.openbsd.org/faq/faq3.html#ISO How is the Layout defined??? maybe Nick or Theo or some other responsible person could give an authoritative answer so I can give it back to the person who asked me. If the md5 sum of the ISO image of a custom made OpenBSD CD is different form that of the md5 sum of the ISO image of official CDROM then can it be considered different in lay out??? uh, no. If you publish a book, and I duplicate it in every way EXCEPT that I change one character in one location, or the color of the cover, or insert a page with the text, THIS PAGE INTENTIONALLY LEFT (almost) BLANK, I can argue that it is a different book (different md5!), but I suspect you would feel cheated, and the courts would probably agree. If you start from the official CD set and try to change it, maybe someone somewhere can give you a guide as to how much change would have to take place to make it safe, but I think you would be clearly violating the spirit if all you can say about your work is, here is my CD, it is just like the OpenBSD disk, except different. HOWEVER, if you start fresh, and with different criteria, you will be very likely safe. Some of the criteria the OpenBSD project uses includes shipping as many CD-useful platforms, with the most common packages that would be of use in a coherent way, and put it all on three CDs. I suspect that would not be YOUR criteria. Change your criteria to something like single platform or single media or All platforms or All Packages or DVD media, put it together in the BEST WAY that fits that criteria, and you suddenly end up with something that is very useful and clearly different. In short, if you are wondering if you are too close, you probably are. If you spent some time and effort to put something together that has some of your own thought and planning, you might be just fine. (heh. funny how one's life flashes before one's eyes when interpreting the words of Theo. Be forewarned, Theo has NOT named me his official spokesperson -- you can follow my guideline to the letter, but I won't be the one jumping down your throat. :) Nick.
Re: harddisk geometry problem.
Riccardo Giuntoli wrote: Hi there. Can someone tell me why during boot my wd1 hd is seen with the correct number of sectors and after fdisk sees only half of them? Yeah. Because Something's Wrong. Since you apparently knew what I need to know to give you that diagnosis, I'm sure you will be very content with it. If you are NOT satisfied with that explanation, DON'T SNIP THE OUTPUT OF DMESG AND OTHER PROGRAMS, DAMMIT. You can not imagine how irritating it is to have someone ask for help and then deliberately restrict the information they give. If you knew what information we needed to answer your question, you would have known the answer yourself. btw: also include FULL output of disklabel... Nick.
Re: OT: 10 things i hate most on unix
Gustavo Rios wrote: Hey folks, sorry, but i found this on the web. May someone tell if it is serious, i myself could not believe it. http://www.informit.com/articles/article.asp?p=424451seqNum=1 The author is taking themselves seriously. I don't recommend you make the same mistake. 1) Everything Is a File (Unless It Isn't) yeah, so? The better solution would be to make somethings a file and somethings not? Hows' that different? Or maybe the Plan 9 option which is supposedly super-consistent, but lacking applications and usage in real life. 2) Everything Is Text I've worked on systems where some files are fixed records, others are binary, some are text...thank you, I like the Unix approach. 3) No Introspection Har. MacOS as an example of what he wants? Gee, isn't Apple DROPPING that feature on OSX? While it is great if you happen to be interested in only talking to other Macs, it's a major irritant if you can't get the ENTIRE REST OF THE WORLD to agree with you on how its done, and that WILL NOT happen. 4) X11: Almost a GUI a very weak, but almost valid point here. I first saw this comment about X almost 20 years ago. X11 is kinda clunky in some regards, but not so clunky that people have decided as a group on a good alternative. Propose an alternative, port it to a lot of platforms, port a lot of software to it, and then we will talk. Until then, enjoy X. 5) Standard Input, Standard Output Without an alternative stated, this is complete bull. Don't like STDIO? Don't use it. Isn't appropriate for your app? Don't use it. Sheesh. 6) Synchronous System Calls *yawn* Hm. If QNX is so much more efficient, why is Unix used on most supercomputers now? Obviously, the issue isn't big enough to cause people to jump favorite OSs. 7) One-Way System Calls Yes, this is clearly why there are so few applications written in Unix. *snicker* 8) C: Cross-Platform PDP Assembler ok, this argument kills all credibility for the whiner..er..author in my eyes. C became the language of choice for because it WORKS and works well for its intended purpose. It was developed by people who used it for their own use. It was chosen by others because it worked for them. Yes, it was developed IN a Huge Company, but it was not pushed by them. Contrast that to a popular language right now which is being crammed down the corporate world's throat. I really suspect that ten years after Sun Microsystems vanishes or quits pushing Java, Java will vanish like scores of other proprietary languages, and C will still be actively used. ok, I may be a bit biased here. I love C. I fell in love with it almost from the first article I read about it (Byte Magazine, early 1980s), and loved it when I first started programming in it (Software Toolworks C on CP/M-80, later BDS C, also on CP/M-80. BDS C could produce hello world in a COMPLETELY self-contained 2k binary). The White Book was the ultimate programming language definition guide -- very complete, and very readable, and very slim. You could feel the bits and bytes flowing by in your programs. Everything was an integer -- pointers were integers, strings were integers, and even floating point was just a bunch of bytes(=integers) you handled carefully. Yeah, obviously, it had some serious problems -- the portable assembly language idea just doesn't work out for anything other than the most basic of programs, so layers of abstraction were added in ANSI C. The whole C doesn't do strings has always been complete Bull Sh*t in my mind. C does strings like the processor underneath does -- it doesn't make complex operations involving moving thousands of bytes look simple. While I do use Perl for some apps, the stuff it lets you get away with in one line creeps me out horribly...knowing C and a few (ancient) assembly languages, I know what is going on under the covers, but I have sympathy for the new programmer (or very experienced programmer who lacks certain bits of experience) who writes a ten line program and wonders why it takes twenty minutes to run... C isn't the ultimate language for all activities, but it is darned good, it has been chosen through natural selection, not marketing money and buzzword compliance. Sure, I'd love to see a better language, but I haven't seen it yet, and I have seen LOTS of replacements for C that clearly will never take over. Funny, many of the alternative languages to C are written in..C. And, they are available and were originally developed on Unix. I'll admit, my love of C kinda faded when it went from being a PDP assembler to a completely portable, abstract, high-level language that ANSI C is now. Yeah, yeah, I know, all kinds of advantages to portable code. But no ANSI C compiler does a hello world in a 2k stand-alone binary...and you can't feel the bytes in your fingers anymore (and if you do, you are writing non-portable code, which is bad. See why I stay out of src/ ? :). Some clues to what the alternative
Re: Dual Head Graphic Card
Gustavo Rios wrote: Dear friends, mo desktop box's graphic card has support for two monitor. I have two sets containing each: 1 monitor, 1 mouse and 1 keyboard. The mouse and keyboard are connected to the monitor via USB. I wonder if i could have a configuration like that: I would like to have the first 5 ttys connected to the one set of devices, and the second set holding the seconds 5 ttys. The ideia is to be able to have two users connected independently to a single desktop. Could i made my self clear about my goal? Is that possible to achieve? Thanks in advance for your time and cooperation. Best regards. Of course it is possible. Just write enough code. Don't waste your time. Add an old, second computer pulled out of the trash to the puzzle, run X on it, and use it as an X terminal for the first. You have accomplished your stated goal using tools the way they were intended to be used, rather than twisting them in ways they were not intended. Plus, you have much greater scalablity -- what do you do for the THIRD, fourth, or twentieth user on your system? With my recommendation, just add more junk computers. Your idea? Not going to happen. Nick.
Re: Telnet daemon retired in 3.8 ?
Xavier Beaudouin wrote: ... Personnaly I don't use telnetd for ages especialy on systems that are security based... there's a point. You use OpenBSD for security. Then you do horribly insecure things to access it. huh? Nick.
Re: mainting a mirror
Martin Ekendahl wrote: What do you guys use to update your mirrors? I have a colo server that I'm not doing much with and I thought about setting up a mirror and just running `cvs up -Pd` twice a day or something to update it. Am I on the right track or is there a better or more official way of doing it? -Martin You don't mention what kind of mirror. If mirroring the website, don't bother, unless there is some market you could service that none of the other mirrors service well. Most of the world can get to one or all of the existing mirrors very well, and there is sufficient capacity. It just creates more maintenance issues for us. If providing downloads via ftp or http, mirroring cvsync, anoncvs, cvsup, sure, we could use more capacity there. In those cases, the respective pages generally give you guidance on setting things up...but keep in mind, the demands on such a system are very much non-trivial. Nick.
Re: Instructions for tracking -CURRENT
On Wed, Nov 09, 2005 at 04:53:12PM +0200, Alari Kask wrote: Hello everybody, i put together some instructions for tracking -CURRENT, it's just for getting things done faster, than reading the cvs instructions on the homepage of openbsd. Any feedback is welcome. Install snapshot If you get any fancier than that, you are probably going to be causing a lot more dammage than good. Nick.
Re: how to clear dmesg outpout
Jose H. wrote: ... On 7/4/07, Nick Guenther [EMAIL PROTECTED] wrote: ... Why do you need to clear the dmesg? I think it is a pretty valid question(request?), you have to relay on external mechanisms, like syslog, or to compare differences from previous outputs of dmesg. and the problem with that is...? On HP-UX dmesg has the optional parameter '-' which: system tables overflow or the system crashes). If the - argument is specified, dmesg computes (incrementally) the new messages since the last time it was run and places these on the standard output. This is typically used with cron (see cron(1)) to produce the error log /var/adm/messages by running the command: On FreeBSD and Linux it can be cleared. I think it is a feature that can help a lot. I think not. Let's not be adding silly knobs for things that can be done better in other ways: /home/nick $ dmesg |diff -u /var/run/dmesg.boot - --- /var/run/dmesg.boot Sun Jun 24 11:17:24 2007 +++ - Wed Jul 4 22:33:35 2007 @@ -87,3 +87,9 @@ dkcsum: sd1 matches BIOS drive 0x81 root on sd0a swap on sd0b dump on sd0b WARNING: / was not properly unmounted +umass0 at uhub0 port 2 configuration 1 interface 0 +umass0: LG USB DRIVE, rev 2.00/2.00, addr 2 +umass0: using SCSI over Bulk-Only +scsibus2 at umass0: 2 targets +sd2 at scsibus2 targ 1 lun 0: LG, USB DRIVE, 2.00 SCSI2 0/direct removable +sd2: 993MB, 126 cyl, 255 head, 63 sec, 512 bytes/sec, 2034944 sec total oh, look, someone plugged in a flash disk. Yes, there are benefits to looking at the change in the dmesg. I do NOT like the idea of CLEARING this most valuable resource, however. Whatever you wish to accomplish this way can be easily accomplished in some other way, I think. Nick.
Re: Running out of RAM -- for the archives
Karl O. Pinc wrote: On 07/06/2007 06:46:26 PM, Chris Smith wrote: I assume the problem is not enough RAM because when I add more RAM everything works fine. Repeatable? Sure you've ruled out a seating problem? Yes, repeatable. yep, I'd believe that. Some time back (3.6?), when I stuffed five 4-port dc(4) cards into a Dell GX1 (late PII system), I found it panicked early in the boot process if I had only 16M RAM in the thing (yes, I actually have some 16M DIMMs I was able to stuff in the machine!). After a bit of discussion with developers who know more than I (which is pretty close to all of them), it was explained that each NIC requires some buffer space, so the more NICs you have, the more RAM you better have for the kernel. If you don't have enough RAM for the kernel, it goes boom. Sounds like I need to do some more small RAM testing again. I am actually somewhat surprised (but not shocked) that 32M is not enough for three NICs, but things have grown since the 3.6 days. It's getting hard to get down to the 16M-32M range anymore on systems that aren't painful to ssh into. :) Nick.
Re: IDE or SCSI virtual disks for VMWare image?
Todd Pytel wrote: ...If it matters, this is going to be lightweight, home server kind of stuff. There's the answer to your question: For your app, it just won't matter. You've spent more time asking, and others (including myself) have spent more time answering your question than you will ever personally benefit (i.e., more work done at the end of the day/week/month). Optimizing for a 1% or even a 20% performance difference is rarely worth the effort for end-of-day productivity (major exception: when it is part of a number of other 20% optimizations. Another major exception is when you are really close to the limit for something, but then, you generally need to be working out a better strategy, not getting just barely getting by a little longer). If you honestly believe you will benefit from such an optimization, you can and need to do your own benchmarks. There are just too many variables in your question to be asked and answered in the way you asked it. For example: * VMware version * VMware host hardware * Other system load * OpenBSD load * etc... Practically speaking, if you are worried about performance, you probably don't want to be in a virtualization environment. If you are trying to optimize for the sake of optimizing, there are probably a lot better ways of spending your (and our!) time. Nick.
Re: FAQ/PF Guide PDF links out of date?
Richard Wilson wrote: I think I may have found a glitch in the OpenBSD website - The FAQ and the PF User's guide are provided as PDF's, which is very handy for those of us who like to print them out to hand to people as part of their site documentation. Quickly out of date I know, but some of our customers like paper. However, having printed out the PDF found at ftp://ftp.openbsd.org/pub/OpenBSD/doc/obsd-faq.pdf which is the one linked from http://www.openbsd.org/faq/index.html I found that the footer stated it was last re-generated on 02/12/06. More fool me for printing it without checking first. A spot of digging revealed that the copy on the mirrors, for example http://spargel.kd85.com/ftp/pub/OpenBSD/doc/obsd-faq.pdf was last updated on 02/05/07, which is far more like what I woulde have expected. In summary, am I being dumb or is something out of sync? Something is out of sync... For some reason that directory isn't replicating properly. I'll bring that up with the right people... Nick.
Re: Multi terabyte filesystems
John Nietzsche wrote: Dear list members, is there plans for openbsd to support multi terabyte filesystems? there is desire. There is work being done. Which release should i expect to see such support? The release it is ready for. What do you want someone to say? For example, do you want me to say, It will be ready by 4.3? If so, you have two choices: 1) Base your decisions around it. (what if I'm wrong? What if it isn't ready? You are screwed.) 2) Assume I'm an idiot, and don't believe me. (why did you ask?) In short: there is no answer you can be given that will sanely make your life better. Here's your measure: when it's in -current, it will be in the next -release, unless horrible problems are found that can't be fixed in time for the release. Whether or not it is ready for your app, that you will have to decide by putting it to your own tests. File system work is scary. It requires a measure of brilliance and optimism in a rare combination. Usually when people have that much brilliance, they look at the risks and run screaming in terror. The question of why is quite valid. Most applications I can think of for multi-TB file systems could be better done with several small file systems. At work, we have an app that will create massive amounts of data over its life span, running on an OS that DOES support multi-TB partitions. With less than 300GB in use currently, people are starting to appreciate my advice to keep the partitions well under 1TB in size...and 500GB is starting to look really, really big. Nick.
Re: installation on extended partition
Dimitrios Apostolou wrote: ... So the question is how to properly install and boot OpenBSD on an extended partition? I couldn't find any relevant documentation anywhere... Booting from extended partitions is not supported by the OpenBSD boot system. OpenBSD has to be installed on a primary partition. Nick.
Re: installation on extended partition
Dimitrios Apostolou wrote: Hello again, I forgot to mention that I'm not subscribed so please CC: me personally in all replies. I know that installation on extended partitions is not officially supported, that's why I'm asking for unofficial information. Always interesting to see how people will pick an OS for its stability and its security, then try to do unsupported things. If I could choose I would of course had tried installation on a primary partition, but I had no alternative. I would either try installing it there, or not at all. Unless you write code, it's gonna be not at all then, given those conditions. After all, I have read at various places about it being unsupported but doable (with no details anywhere, unfortunately). Oh? That's interesting, since: 1) The OpenBSD boot code does not load from non-primary partitions. 2) I'm not aware of any other boot loader out there that will directly load an OpenBSD kernel (all that I am aware of just load the OpenBSD PBR which loads /boot which loads /bsd.) For example I quote the following: flag Make the given partition table entry bootable. Only one entry can be marked bootable. If you wish to boot from an extended partition, you will need to mark the partition table entry for the extended partition as bootable. from http://www.openbsd.org/faq/faq14.html#fdisk Ok, at least you site a source. That saves you from the boiling oil. :) Unfortunately, you misunderstand what it is saying (or what was intended). fdisk can mark any partition bootable. That partition could be OpenBSD, Netware, Windows, OS/2, whatever. Now it is up to the OS on that partition to be able to boot. fdisk doesn't make it happen, it just marks the boot partition. OpenBSD's fdisk doesn't limit what you can do, which is why a lot of us end up grabbing OpenBSD boot disks when we need to clean up partitioning table messes in non-OpenBSD systems. OpenBSD's fdisk assumes you know what you are doing, no limits. What you are doing may have nothing to do with OpenBSD. I've added notes about primary partitions only in a couple strategic places in the FAQ. Usually, the people wanting to do things like this are wanting to try out OpenBSD. BAD idea. Don't try out an OS in the middle of a bunch of other OSs on the same computer. Get to know the system BEFORE you try to do multi-booting. Otherwise, you are very likely going to find yourself with either an accidentally OpenBSD-only system or a blank system. Grab someone's virus-infested computer they are discarding, and get to know OpenBSD on that. That solves a few problems at once. :) Nick.
Re: OBSD4.1 i386 IDE driver fails to find disk..?
John H. Nyhuis wrote: Greetings, My apologies if this is a repost. I am having trouble getting this through to the list. I am trying to install OpenBSD (i386) 4.1 and am failing to get it to identify my standard parallel ide disk. The disk is identified at bootstrapping as hd0*+, but once the installer gets to the point of Proceed with Install? [yes] I receive the message No Disks Found. The bootstrap detects the hard disk because it is talking to the BIOS, whereas OpenBSD has to talk to the HW directly. The hardware checks out via CheckIT, and the FreeBSD installer does not have a problem partitioning and formatting the disk, so I do not believe this is hardware failure. I know that OpenBSD probes hardware differently then FreeBSD, so I think the root of my issue has to do with OpenBSD drive probing. well...actually, looking at your provided dmesg (thanks!), it looks like IRQ... All standard pATA IDE controllers should be supported, according to the hardware pages. well..most. And yours is, but you have other problems. Would someone mind looking over the attached dmesg and giving me some ideas of how to resolve this? I don't see anything that immediately stands out as an error (except for the USB stuff, which I don't need on this box). That's may just be because you are running a kernel with limited driver support. But yes, not an issue at the moment. OpenBSD 4.1 (RAMDISK) #260: Sat Mar 10 19:38:22 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAMDISK cpu0: Intel(R) Celeron(R) CPU 2.80GHz (GenuineIntel 686-class) 2.81 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR real mem = 1064595456 (1039644K) avail mem = 967368704 (944696K) using 4278 buffers containing 53354496 bytes (52104K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+ BIOS, date 03/21/07, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @ 0xf04c0 (53 entries) bios0: ASUSTeK Computer Inc. P5PE-VM apm0 at bios0: Power Management spec V1.2 apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf86a0/176 (9 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801EB/ER LPC rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xa000! 0xca000/0x1000 0xcb000/0x1000 acpi at mainbus0 not configured cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82865G/PE/P CPU-I/0-1 rev 0x02 vga1 at pci0 dev 2 function 0 Intel 82865G Video rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Intel 82801EB/ER USB rev 0x02 at pci0 dev 29 function 0 not configured Intel 82801EB/ER USB rev 0x02 at pci0 dev 29 function 1 not configured Intel 82801EB/ER USB rev 0x02 at pci0 dev 29 function 2 not configured Intel 82801EB/ER USB rev 0x02 at pci0 dev 29 function 3 not configured Intel 82801EB/ER USB2 rev 0x02 at pci0 dev 29 function 7 not configured ppb0 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci1 at ppb0 bus 1 em0 at pci1 dev 9 function 0 Intel PRO/1000GT (82541GI) rev 0x05: irq 14, address 00:0e:0c:c3:05:1e irq 14 looks a little scary to me... em1 at pci1 dev 11 function 0 Intel PRO/1000GT (82541GI) rev 0x05: irq 3, address 00:0e:0c:b9:60:53 skc0 at pci1 dev 13 function 0 Marvell Yukon 88E8001/8003/8010 rev 0x13, Yukon Lite (0x9): irq 5 sk0 at skc0 port A, address 00:1a:92:21:2e:8d ukphy0 at sk0 phy 0: Generic IEEE 802.3u media interface, rev. 5: OUI 0x005043, model 0x0002 ichpcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801EB/ER IDE rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: no compatibility interrupt for use by channel 0 oops. pciide0: channel 1 disabled (no drives) ... Looks to me like you are having interrupt routing issues. STEP 1: Go into your BIOS, and try resetting everything back to defaults. Sometimes, people get in and improve things so much that things break. STEP 2: Try adjusting things in the BIOS. Sometimes the defaults DON'T work. :) I'd aim at maybe making that IRQ14 an ISA IRQ. Don't quote me on this, I'm not as up on PCI interrupt handling as I should be, but seeing something sitting on IRQ14 was really bad back in the ISA days. :) STEP 3: Try poking pcibios(4) with ukc (see FAQ 5). Try disabling it first, then giving it various flags (I'd tell you which to try, 'cept it usually isn't the one I'd have guessed, so I'm just gonna say, try 'em all, 0x1, 0x2, 0x4, 0x8 ..) Nick.
Re: How to use (compact) flash cards with OpenBSD
First of all, a fine point of English: How to should be followed by an explanation of how to do something, not a question, 'specially if not followed by a question mark. The phrase you are probably looking for is how do I . . . ?. (yes, strange thing for me, who has mangled English in many a creative and strange way to gripe about, but this bugs me for some reason) On to your question... Don Jackson wrote: I have a Tyan S2881 Thunder K8SR motherboard (Opteron), and wd0 is a SATA hard disk (Western Digital), but I want to boot and run off a flash card. I have an Addonics SATA to CF adaptor, Model ADSACF) http://www.addonics.com/products/flash_memory_reader/adsacf.asp oh, interesting...CF to SATA adapter. The OpenBSD 4.1 installer (booted via PXEboot) seems to have a LOT of trouble with the flash drive (recognized as WD1). That's going to bite you in the butt eventually, even if nothing else does. You don't want to try to boot from wd1... How can I make OpenBSD happy with this drive? The actual CF card is a SanDisk Ultra II 8Gb. I had zero problems installing and using a similar SanDisk card in a Soekris 4801, so I know that it must be possible to make this work. I doubt that it is your CF card that's causing your problems, it's everything OTHER than the card that's suspect: the SATA chip, the SATA-CF adapter, etc. How do I make OpenBSD happy with the flash disk? Do I need special BIOS settings? I had very similar problems with another IDE - Flash adaptor in a Pentium machine. due to the lack of details and my sucess doing this, I'm totally ignoring this statement. :) Here is the log from the installer: Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.1-stable (RAMDISK_CD) #1: Sun May 27 13:25:48 PDT 2007 [EMAIL PROTECTED]:/home/openbsd/4.1/src/sys/arch/i386/compile/RAMDISK_CD ... pciide0 at pci1 dev 5 function 0 CMD Technology SiI3114 SATA rev 0x02: DMA pciide0: using irq 10 for native-PCI interrupt pciide0: port 0: device present, speed: 1.5Gb/s wd0 at pciide0 channel 0 drive 0: WDC WD2500YS-01SHB0 wd0: 16-sector PIO, LBA48, 239372MB, 490234752 sectors wd0(pciide0:0:0): using BIOS timings, Ultra-DMA mode 6 pciide0: port 1: device present, speed: 1.5Gb/s wd1 at pciide0 channel 1 drive 0: SanDisk SDCFH-8192 wd1: 4-sector PIO, LBA, 7815MB, 16007040 sectors wd1(pciide0:1:0): using BIOS timings, DMA mode 2 ... dkcsum: wd0 matches BIOS drive 0x80 wd1(pciide0:1:0): timeout type: ata c_bcount: 512 c_skip: 0 pciide0:1:0: bus-master DMA error: missing interrupt, status=0x21 pciide0 channel 1: reset failed for drive 0 wd1c: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying pciide0:1:0: not ready, st=0xd0BSY,DRDY,DSC, err=0x00 pciide0 channel 1: reset failed for drive 0 wd1c: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying pciide0:1:0: not ready, st=0xd0BSY,DRDY,DSC, err=0x00 pciide0 channel 1: reset failed for drive 0 wd1c: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying pciide0:1:0: not ready, st=0xd0BSY,DRDY,DSC, err=0x00 pciide0 channel 1: reset failed for drive 0 wd1c: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying pciide0:1:0: not ready, st=0xd0BSY,DRDY,DSC, err=0x00 pciide0 channel 1: reset failed for drive 0 wd1c: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying pciide0:1:0: not ready, st=0xd0BSY,DRDY,DSC, err=0x00 pciide0 channel 1: reset failed for drive 0 ... 1) As already indicated, if you want to boot from this thing, swap your cables so that it is wd0, not wd1. (YES, you CAN probably do it as wd1, but it will be a maintenance nightmare, and seemingly for no point in your config). Unlikely to fix THIS problem, but will probably fix the next one you ask about. 2) I see the thing is picking up as a DMA mode 2 device. I've not seen that with the CF devices and adapters I've used...might want to try disabling the DMA on that device. man 4 wd 3) Try another OS on your adapter/MoBo combo. You may find your CF adapter and CF module just don't play nice together (or the CF module and the SATA chip set). I've seen some IDE devices that claimed to do DMA and UDMA and were just plain lying, apparently relying on the fact that Windows would fall back silently and never tell you that the thing was completely screwed up. 4) MIGHT want to try running just the CF card, skip the HD until you see what is going on. I have no reason to believe that will change anything, other than a deep skepticism of everything and the general urge to simplify the heck out of a troublesome system until it is working properly. 5) Those SiI chips suck, or at least their ROMS suck. I've solved a lot of problems by literally prying the ROM off the board on some of those things. I
Re: How to use (compact) flash cards with OpenBSD
Nick Holland wrote: ... 2) I see the thing is picking up as a DMA mode 2 device. I've not seen that with the CF devices and adapters I've used...might want to try disabling the DMA on that device. man 4 wd 3) Try another OS on your adapter/MoBo combo. You may find your CF adapter and CF module just don't play nice together (or the CF module and the SATA chip set). I've seen some IDE devices that claimed to do DMA and UDMA and were just plain lying, apparently relying on the fact that Windows would fall back silently and never tell you that the thing was completely screwed up. while looking at the provided link and after posting, I noticed this: To ensure compatibility and improve speeds, a Compact Flash media with UDMA Fixed Disk Mode is recommended. Compact Flash media without this may not boot properly. You don't have UDMA, and not sure about this Fixed Disk Mode, but it looks like you fall into that last sentence there... Nick.
Re: Intel Core 2 - errata pulled?!?
Toni Mueller wrote: ... Leaving these aside, I just discovered that the i386 compatibility page does apparently not list _any_ current intel CPUs (eg. Pentium D), and the question about whether recent Xeons still classify as Xeon in this list has been raised. So, is it right to conclude that only current AMD CPUs are supported, and that recent intel CPUs are generally unsupported? from http://www.openbsd.org/i386.html : Everything that is a clone of the 486 or up should work fine. The issue is almost never the CPU itself, the issue is the surrounding support chips and firmware. There is much more to a computer than its processor. Asking Does OpenBSD support my new processor is usually missing the point. Ask if it supports your new COMPUTER. Better yet, get yourself one of those credit-card CDR blanks, drop cd42.iso on it, and carry it with you and find out, or on modern computers (duh, which we are talking about, right?), grab a USB flash drive, and put a test install on that, and you can boot the entire OS, test X, NIC, whatever, and grab a dmesg, drop it on disk and analyze it later. Nick.
Re: amd64 snapshot: md5 mismatch install42.iso
Adriaan wrote: A md5 -c MD5 fails for install42.iso Thats' an experimental feature, not necessarily kept in sync with the rest of the build process at the moment, and thus, the MD5 files may very well not match. Nick.
Re: PF rdr based on hostname
Sam Fourman Jr. wrote: hello misc@ I am PRETTY sure there is no way to do a pf rdr command based on a hostname and I am just trying to confirm this Maybe I could somehow use hostated? What I want to do is have 4 seprate Windows XP Professional workstations with 192.168.x.x address behind a pf firewall and be able to Remote Desktop From an outside location to anyone of the workstations based on hostname eg have 4 hostnames point to the same public ip then pf will rdr to the correct Workstation based on the hostname that is specified. as stated, you can't do what you want to do the way you propose doing it. But as others have already done, just change the definition of the game. Do you REALLY want remote desktop sitting live on the 'net? That's one heck of a hole to punch in your firewall. If SO, here are a couple other ideas: 1) authpf: People log into the firewall, which establishes the link to THEIR computer. Pros: fairly simple to configure, no changes needed to Windows on either end. Con: If you have multiple people on one public IP (i.e., behind NAT), they will rapidly begin to dislike this idea (second person will kick off first) 2) SSH tunnels: On firewall or even extra machine, let people login using PuTTY from their Windows workstation, and establish a tunnel to their target workstation. Fairly simple, walked a lot of novices through it over the phone. Pros: Absurdly simple to configure on OpenBSD end in the most trivial configuration, but can be locked down more if you so desire. Cons: some config needed on remote side, though can be automated with .REG files or batch files. On XP, you have to change the port on the client side, so Windows doesn't say, HEY! You are connecting to me! That could be bad! and keep it from working. Personally, I'd go for the tunnels. Both these systems have the advantage that you are making the first step of the connection through OpenBSD, rather than dangling a likely soft target (Windows RDP) out on the 'net directly. If nothing else, you can at least monitor who has logged in from where easily enough and look for oddities. And yes, rdesktop run on OpenBSD rocks. Nick.
Re: Problems installing OpenBSD to Soekris
Timo Myyrd wrote: Still having problems. I can't get the soekris to boot as far as I can tell. I used fdisk and created slice for OpenBSD and then used disklabel to create the partitions inside it. After that I extracted sets (base,etc,man) to the disk. I used fdisk -u sd1 to update the MBR. You didn't install the PBR. installboot(8), FAQ 14. I modified the /etc/ttys to: tty00 /usr/libexec/getty std.19200 vt220 on secure Personally, I'd rather slow the Soekris ROM down to 9600. That's a more standard speed. The OS and the HW default to two different speeds, so one will have to move from default. If this is the only serial device in your life, you may not care. It's far from my only serial device, however. Everything else seems to default to 9600. I added following to boot.conf: set tty com0 I connected the card to soekris and put the DB9 cable between soekris and my laptop. Before turning power to soekris I gave command tip -19200 tty00 on my laptop and it replied connected. After I turn on Soekris nothing happens. Then you have serial cable problems, IN ADDITION TO the PBR problem. Using cua00 instead of tty00 may help some of your serial problems. I wait a while, turn it off and mount the CF again with the reader. I mounted the partitions again and check the /var/log/messages and it's empty. Shouldn't here be some info if the OpenBSD itself would have booted? Any idea what to do next? install the boot code properly and fix your serial problems. :) Nick.
Re: Backport drivers from 4.1 to 4.0
Kevin Cheng wrote: Hi Darrin, Thanks for reply. The reason is that we have bunch of files integrated with 4.0 and it would take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of upgrade few months ago, plus months of test to stabilize our 4.0 based applications. Should we just isolate one by one manually as safety approach? Any CVS that we can trace for what files been changed for specific drivers? E.g., 4.0-4.1. what you are trying to avoid doing is easier than going the completely unsupported route of making a Frankenstein system. Routine upgrades of /at least/ once a year HAVE to be part of your OpenBSD plans. It is that simple. It's hard to do! is not a valid excuse, that means the rest of your plan is not properly designed. Most of the benefits you gained by using OpenBSD are negated by what you are (not) doing and attempting to get away with. Nick.
Re: OpenBSd or HP-UX?
Alvaro Mantilla Gimenez wrote: Travers Buda wrote: *snip* Just tell him that OpenBSD in the stead of HP-UX will be cheaper, faster to setup, and easier to maintain (because of your experience with Open.) Both OpenBSD and HP-UX can do LDAP, yes, but it's yourself that makes the difference here. Oh, and you have much more freedom in picking out your hardware (back to the cheap tangent.) -- Travers Buda It would be wonderful convince my boss with that argumentbut the next question he will ask is: What ifyou die tomorrow?? Who can maintain the system??... What if you go with HP/UX (or ANYTHING else) and you die tomorrow? Answer is always the same: you have to have more than one capable person on staff who knows the product. It's not just about your death, of course...you DO want to be able to take some time off without having the phone stuck to your ear, right? Cross training people on OpenBSD is much easier -- I bet you have more OpenBSD-capable HW laying around than you do HP/UX capable HW. People can practice at home..and even put systems to use at home. Your resulting system will have to be documented. People will have to look at that documentation and verify its completeness. It doesn't matter what OS and apps you run, you will have to document HOW you implemented your systems. Contrary to many boss's expectation, they can't just pick up the phone and have your replacement magically walk through the door and pick up where you left off. Using a commercial OS doesn't change this, your IMPLEMENTATION must be documented. Your real question is not the OS, but rather the applications that you are running (LDAP in your case). Your hypothetical replacement will spend a lot more time learning your LDAP application and implementation than they will the OS it is running on. Nick.
Re: vmware cvs
Gabri Mati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey there! I'm trying to run OpenBSD under the latest VmWare server, but i've got some problem: i can't use cvs to check out the repositories. It hangs at the connecting phase. It's strange, cause ftp and http connection works, like i can fetch the ports.tar.gz via wget or the ftp client...but thats a bit outdated, so i want to use cvs. I've tried the simple cvs checkout command with CVSROOT variable, and the login method with pserver, none of them succeeded. Any help would be appreciated! troubleshoot, troubleshoot, troubleshoot. cvs uses ssh as its transport, so can you ssh into/out of the box? can you ssh to your ssh repository? $ ssh [EMAIL PROTECTED]whatever.org should return something semi-interesting. $ telnet anoncvs.whatever.org 22 should also try to work. Almost certainly, however, you are doing something incorrect. You have provided a diagnosis, not a set of symptoms, so I can't say much else other than I doubt your diagnosis, as I've done it, it works. Most likely, it is not at all VMware related (unless your vmware networking is screwed up), but rather something like filtering or even incorrect CVS usage messing you up. Nick.
Re: How to use (compact) flash cards with OpenBSD
Don Jackson wrote: I have gotten past all the problems I discussed in my original message to this list. On the AMD/Tyan motherboard with the Addonics CF to SATA converter, what I did was purchase a Lexar Professional UDMA 300X CF card. This card is faster, and provides the UDMA interface that the motherboard and the OS likes to use. I changed the cabling so that the flash card was the first disk (wd0 to OpenBSD), and I moved the SATA hard drive to wd1. For this first attempt, I put swap, /tmp, and /var onto partitions on wd1. wd0 (the flash), has /, /usr, and /home good plan, but make sure your swap is being recognized. You will probably need an entry in /etc/fstab. From memory, swap on anything other than the 'b' partition of the boot device is not automatically recognized by the standard kernel. I was able to cleanly install OpenBSD and boot into it. It appears to work fine. I do get an error from savecore that wants to use wd0b, and I'll have to tweak that. Only if you want to save your cores. :) If you don't have use for core dumps or don't have the space on /var/crash for your entire core (in your case, 2G more than you otherwise need for /var), don't worry about this, it just won't be worth the trouble. You will forget to fix it again after the next upgrade, anyway. Most people will find it not worth the tweaking. Nick.
Re: The Atheros story in much fewer words
Theo de Raadt wrote: I recognize that writeup about the Atheros / Linux / SFLC story is a bit complex, so I wrote a very simple explanation to someone, and they liked it's clarity so much that they asked me to post it for everyone. Here it is (with a few more changes) - starting premise: you can already use the code as it is steps taken: 1. pester developer for a year to get it under another license. - get told no, repeatedly 2. climb over ethical fence 3. remove his license - get caught, look a bit stupid 4. wrap his license with your own - get caught, look really stupid 5. assert copyright under author's license, without original work - get caught, look even more stupid Right now the wireless linux developers -- aided by an entire team of evidently unskilled lawyers -- are at step 5, and we don't know what will happen next. We wait, to see what will happen. Reyk can take them to court over this, but he must do it before the year 2047. As you indicated in a previous posting, this does seem to point a way to accomplish the long-desired goal of a BSD-licensed compiler set, doesn't it? Heck, using this process, I can become a coder! src/, here I come! Not sure why anyone is surprised here. They have long demonstrated their (re)definitions of commonly used words and phrases. GNUspeak: Open Source is THE WAY! (unless, of course, there's a binary blob around, which is more than sufficient) Give back to the community! (which really means, I'm the community, gimme, gimme, gimme!) Free as in Freedom! (but Free as in no monetary charge beats the hell out of taking a stand) Respect our license! (your license is not worth the bits its stored in) GPL is the way! It's our way, we'll make it your way, too. Theo's a loud-mouthed jerk! (but we'll happily benefit from his work, while we pretend to be the nice guys) Hardware vendors should respect alternative OSs! (Ok, they support mine, that's good enough) OS Diversity is good! (but My distro's bigger than yours! Damn, guys, if that's the goal, Windows wins, everyone else is a loser) Not that certain other free software people are all that much different from the Linux fannerds. Free software: It's all about the price. The rest of the talk about freedom, etc. is just trying to keep them from looking like cheap, greedy bastards. At least for an awful lot of 'em. Nick.
Re: The Atheros story in much fewer words
Shawn K. Quinn wrote: On Thu, 2007-09-13 at 07:09 -0400, Nick Holland wrote: GNUspeak: These are definitely not the views of the GNU project. They *might* be views of the self-styled Linux nerds that think they are k00l and eleet because they read Slashdot, but to imply the GNU project espouses these views is, quite frankly, slanderous. Then why don't they fight it? Why isn't Stallman or Torvalds or other prominents standing up and saying, This is wrong! This is not what we are about! Sure, there is no way they can get involved in every little issue that comes up, but the GNU and FSF are all about their license they are very proud of and defend strongly. I'd expect something out of 'em on this, as the morality, ethics -- and yes, the law -- are so clear, and their casual indifference towards another license is too likely to end up blowing up on 'em in the future. (my first response was going to be, this isn't about the official views of the GNU project, but then...they have been strangely silent). Give back to the community! (which really means, I'm the community, gimme, gimme, gimme!) There may be some in the free software movement that think like this, but this is far from a majority view. Of the PROGRAMMERS, sure. Duh. Thats' why they do it. Pretty much by definition, people who give stuff away are..uh..givers. :) If that's what you mean by the free software movement, fine. However, most of the people using the word community include the vast number of users. I'm talking about the takers. Those who leach without ever giving back. I think if I count the number of people posting horribly offensive You should do it MY way, and cater to MY needs because I want you to messages to misc@ to those that actually contribute code (or any other kind of support) to the OpenBSD project, you would see you are wrong. Note: I'm not talking about people asking questions, even dumb or un- researched question. I'm talking about those who say we are doing something wrong who've never attempted to do better. The people who say OpenBSD would be more popular if stupid advice here. The people who post politely worded but ever-so-offensive messages that make developers say to themselves, Why do I do this? Certainly not for him. Free as in Freedom! (but Free as in no monetary charge beats the hell out of taking a stand) Again, Richard Stallman's famous speech makes it clear monetary charge is not the reason for the free software movement. I'm not talking about Richard Stallman, I'm talking about the people who quote him and chant his words, then live very contrary to them. I.e., not words of the prophet, but the actions of the followers. People wrap themselves in pretty words, then go out and screw each other when it is convenient. (Ok, I'm no fan of RMS. Or ESR. But I'm not talking about 'em.) Free software: It's all about the price. The rest of the talk about freedom, etc. is just trying to keep them from looking like cheap, greedy bastards. At least for an awful lot of 'em. You know, it's fine if you hate the GPL. But I'll be damned if I just sit here and let you spread outright Goddamned *lies* about the free software movement and the people that represent it. are you implying that the GPL FSF *is* the free software movement? Sorry, but I happen to ALSO represent it. Obviously you have missed some of my commentaries on the GPL vs. BSD philosophy. I don't hate the GPL. I dislike it compared to the BSD alternative in general (I dislike milk chocolate compared to dark chocolate, too, but either beats the heck out of, uh, most things. :) but the short version is, it boils down to which you fear more: Big Companies using your code and thus, you as a developer, without pay or allowing you to use their code. -- or -- Big Companies NOT using your code, and rolling their own (inferior, incompatible, inconsistent, proprietary) crap instead. I can make a pretty convincing case for either. However, as much as I'd dislike seeing Microsoft take OpenBSD code and ideas without compensation of any kind, I'd much prefer they use the code and ideas to not using 'em. But that's me. Not all may agree, and that's a good thing. What I do hate is hypocrisy. People who preach the love of God, and kill those who preach it slightly differently. People who say God is all powerful, then feel the need to defend him. People in an auto-town who slap a UAW Union NO SCAB PAPERS bumper sticker on their car made by non-union workers (Solidarity for me!) People who say PROTECT MY CODE while they steal someone else's. GPL is so far down that list, it can't be called hate. Not even an annoyance really. UNLESS it gets slapped on someone's code without their permission and against their wishes. That's not hating the GPL in general, just the actions of some who pretend to support it. (I love chocolate, but I hate to see it ground and melted into the upholstery of my chair. That's just
Re: serial port usage
Darren Spruell wrote: ... If cua00 is the right device to use when connecting out, why the missing phone number error? That means your /etc/remote file is still at its defaults (which perhaps should change): tty00|For hp300,i386,mac68k,macppc,mvmeppc,vax:\ :dv=/dev/tty00:tc=direct:tc=unixhost: cua00|For hp300,i386,mac68k,macppc,mvmeppc,vax:\ :dv=/dev/cua00:tc=dialup:tc=unixhost: See, when you do tip tty00, you aren't actually saying, use port tty00, you are saying, use /etc/remote entry tty00, which just so happens to point to port tty00. It doesn't need to. You could really mess with someone. :) Try doing this: # tip tty01 tip: unknown host tty01 unknown HOST, not unknown port (this machine has a second com port). The tc=dialup is what is hurting you. Just change it to direct. Depending upon your cable and needs, you may not ever care, but cua is more forgiving. Nick.
Re: FAQ on install ISO
Chris wrote: I was wondering whether this - http://openbsd.org/faq/faq3.html#ISO - FAQ entry should be changed as OpenBSD now does provide ISO for base install? As every release, many things are changed in the FAQ. Finding and changing the things that need to be changed occupies a LOT of my time between lock and release days. In this release, many, many things will change. That particular entry is already updated in my tree. The ISO stuff is one of the most trivial. EXTREMELY trivial. As in, Of all the things he should be in a panic about, why does he ask about THIS?? However, the publicly available FAQ will be as it is (more-or-less) until release day (Nov. 1, +/-). Nick.
Re: Creating bridge problem
Jake Conk wrote: Hello, For some reason when I try to add my bridge interface to one of my cards it just hangs. My commands are: ifconfig bridge0 create ifconfig bridge0 add fxp1 And it just hangs pretty much forever until i Ctrl-C it... If I put in my /etc/hostname.bridge0 file... add fxp1 up ...then on my screen it would say it couldn't add fxp1 to bridge0... Anyone know what i'm doing wrong? yeah, not providing enough info. :) Most likely, the problem isn't the bridge, it's the NIC and the system not liking each other for some reason. Does the NIC work in a non-bridged mode? (I bet it doesn't). dmesg, dangit! :) Nick.
Re: OpenBSD firewalls as virtual machine ?
Josh wrote: Hello there. We have a bunch of obsd firewalls, 8 at the moment, all working nice and so forth. But we need to add about another 4 in there for new connections and networks, which means more machines to find room for. So basically I have been asked to investigate running all these firewalls in two big boxes, with lots of NIC's, with a bunch of openbsd vritual machines on them. One main box for the primary firewalls, one for the secondary. Each virtual machine getting its own physical NIC. Personally I dont really like the idea, I can see things going wrong, lots of stuff balancing on a guest os and box. Can someone please inform me if this is a really bad idea or not, ideally with some nice reasoning? Cheers, Josh Read this: http://advosys.ca/viewpoints/2007/04/fuzzing-virtual-machines/ Read the paper linked there as well. Always good to go back to original source material. Anyone who told you VM technology and security had anything to do with each other was full of doo-doo. After reading that, I'd not want to put any externally exposed apps on a VM system. Granted, OpenBSD might not be the best entry point for a VM attack, but the foundation VM design is based on isn't as solid as people think. Nick.
Re: Question on interface enumeration
Gregory Edigarov wrote: Hello Everybody, Supposing I have several identical NIC's in my server, can I predict which become int0, which become int1, etc? A link to document explaining (or man something) would absolutely suffice. Thank you. Not Easily, at least if you are referring to a machine you know nothing about and haven't powered up yet. However, it is easy to make simple tests to find out. Assuming PCI, they go by order of the slots in the bus, which isn't something OpenBSD controls. Many machines have curious orders. For example, I have a Dell GX1 which has five PCI slots; the order is something like: 2 3 4 0 1. (To add insult to injury, I had four port NICs in every slot, took a while to find dc0! :) Now, once I know (er.. knew. The above sequence is from non-ECC and proven faulty memory!) the pattern of slots in a GX1, I can know which NIC will get which identifier. If I put int(4) NICs in slots 3 and 1, the one in slot 1 will be int0, the one in slot 3 will be int1. Now, if I move the NIC from slot 1 into slot 4, they will switch IDs. If I replace the NIC in slot 3 with a NIC of the same type (driver-wise, that is), nothing will change. If I remove int0 and replace it with a different driver, int1 will become int0. How did I identify the slot order in the machine? Stuck identical NICs in all slots. Why did I do that? Because I stuck three NICs in the thing and the ordering was not obvious, so I figured I better get to know this machine better. In all cases, the dmesg will link your MACs to physical IDs, so stick the MAC addr on the spine of the card. In most cases, ifconfig will show you which NICs have link in real time, so an easy way to identify things is drop to shell, plug in one cable, run ifconfig and see which has link. Label. Move cable, repeat until done. None of this is applicable to ISA or USB NICs. It may be applicable to other buses and platforms. Moral: 1) Know your HW 2) Label the MAC address on your NICs 3) Have identical replacement HW in case a non-OpenBSD expert has to do a swap, 4) Know how to reconfig your system if you have to change your NICs. 5) Practice, Practice, Practice 6) Drop to shell before install, look around. Nick.
Re: 4.1 on ALIX.1C - recommendations?
Jan Stary wrote: Hi all, last night, I installed 4.1 on the new ALIX.1C: http://www.pcengines.ch/alix1c.htm (see dmesg at bottom). The intended use of the box is a home router/firewall/NAT/DNS/DHCP for my home network of about four computers (heterogeneous). Everything works fine (as usual with OpenBSD), but there are a few fine points I need some advice with. Firstly, swap (i don't really mind reinstalling). Install guide says On the root disk, the two partitions 'a' and 'b' must be created. The installation process will not proceed until these two partitions are available. 'a' will be used for the root filesystem (/) and 'b' will be used as swap space. oops. That's no longer true, you can now install Just Fine with no swap partition. It was true some time back, but that was fixed long ago. It also says The 'b' partition of your first drive automatically becomes your system swap partition -- we recommend a minimum of 32MB but if you have disk to spare make it at least 64MB. If you have lots of disk space to spare, make this 256MB, or even 512MB. On the other hand, if you are using a flash device for disk, you probably want no swap partition at all. Many people follow an old rule of thumb that your swap partition should be twice the size of your main system RAM. This rule is nonsense. The machine has 256M of RAM, and the storage is a 2G CF card (seen as wd0). The machine is mostly idle (basically just routes). How much swap do you think I should set for such operation? none. If swapping is a concern, you don't want flash. For regular operation, I don't think I need a swap partition at all (how would I do that? A 'b' partition of zero size, as it has to exist?), but to be able to save possible core dumps, I am thinking of 300M swap and 300M /var (to hold /var/crash). Is this reasonable? naw. Unless you know what to do with a core dump, just skip the swap. Secondly, the network interfaces. The box comes with an on-board vr0 at pci0 dev 13 function 0 VIA VT6105M RhineIII rev 0x96: irq 10 which I currently use as the external iface, and the PIC slot holds rl0 at pci0 dev 12 function 0 Realtek 8139 rev 0x10: irq 11 which is used as the internal iface. I also have the following cards in my hands, and I would like to figure out which combination of external/internal would give me the best performance (if it makes any difference at all): Intel PRO/100 S Desktop adapter 3C905C-TX-M Etherlink 10/100 PCI 3 I don't have any idea about what amount of e.g. fragment reassembly the external/internal iface needs to do, and which card (or which card's driver) is best for that. The machine only has one PCI slot, so one of these has to be the on-board VIA. Which of the others is best supported in obsd (and which vendor is most open)? If you gotta ask, it won't matter. You have three bad NICs (vr, rl, xl) and one good one (fxp). But it just won't matter for your use. You got yourself a little economy car of a computer system. You got it because it is small and cheap to operate, and you will be operating it in rush-hour. Don't worry about which tail fin will give you the best performance. (no idea how well that analogy travels around the world. Around here, people like buying tiny cars, then putting a loud muffler and a huge fin (on the back of a front-wheel drive car. That so helps) on 'em and think themselves cool, rather than the dumb-as-a-rock that the rest of us think of them as. I really hope the rest of the world isn't this dumb, but I fear it may be) Philosophically, I'd probably rather put Intel card showing to the Internet, but to fight that urge, I ran my primary mail/web server with an rl(4) card facing the 'net for many years with zero problem. Anything you are going to run through this box will not hit the NICs as a bottleneck. Thirdly, the CF storage. Having read http://www.kaschwig.net/projects/openbsd/wrap/#mfs http://blog.innerewut.de/2005/05/14/openbsd-3-7-on-wrap http://blog.innerewut.de/2005/05/19/openbsd-3-7-on-wrap-revised http://blog.innerewut.de/2005/06/03/small-update-on-openbsd-3-7-on-wrap (which apply to 3.7 on WRAP, the predecesor of ALIX), I am concerned about the CF wearing off. As these articles are from 2005 - do these things still apply to newer CF cards, and should I therefore set up a mfs? What else should I do to make the CF card live longer (noatime comes to mind of course). biggest reason to avoid writing to flash is it is painfully slow. General experience (inc. mine) seems to indicate that the finite write cycle problems of flash is not going to bite you. It's a blooming computer system, how long do you even want it to last? :) In two years, you will be buying 32G flash devices at the drugstore closeout pile. The (then big) 256M CF that I had running OpenBSD for many years on is now useless to me for almost
Re: OpenBSD firewalls as virtual machine ?
Douglas A. Tutty wrote: ... Hi Nick. I understand your reasons. To me they look like reasons for separate firewalls on separate boxes. In the scenarios you mention, would you put separate firewalls on one machine? That's where you are supposed to 1) recognize that my mysteriously mangled e-mail address is me and 2) Read back to my previous statement where I stated that I don't feel VM technology is suitable for externally exposed apps or security critical apps and 3) catch the implied sarcastic sneer in If one believed in the idea of 'a perfect VM environment' Yes, very separate is what I was recommending: no VM, keep them as separate as possible. When appropriate, of course. VMware and related technologies look cool, but it's an extra layer of complexity and security vulnerabilities. It is also a technology where the track record is Coolness first, security when they catch us with our pants down. It is also something that is rarely done properly (for my definition of properly), but that's a different discussion for a different list. Nick.
Re: minimum hard-drive space to compile patches?
Douglas A. Tutty wrote: I currently have OBSD running on my P-II with an 850 MB drive and 64 MB ram. On install, I chose not to include the compiler set over concern re drive space. The FAQ says how much space is required to minimally run OBSD and it says how much to be able to comfortably compile (4G is not a bad size). It may not be bad but what is the absolute minimum size of hard drive for an i386 to be able to recompile any necessary patches itself? Thou shall start at Four Gig, perhaps more, no less. Four gig shall be the number thou shall need to be able to store, and the number of the Gig be Four. More thou mayest have, but three gig thou shall not store, excepting that thou then proceed to fill four. Two Gig is right out. 4G. If you want to build X, better make that 6G. COULD you do it in less? Probably. But not much less. Last weekend, I saw brand-new 8G IDE disks for sale for $9US ea. The ONLY excuse trying to cram into smaller disks is if you have an old SCSI-based system, as large-enough narrow SCSI disks are getting hard to come by. Even there, I recently hit the jackpot, having discovered that a number of 9G and 36G SCA disks I have have a jumper that allows them to work on (at least) my mac68k with a suitable adapter. Now, to get some more of those adapters...and fans. Seems mac68ks weren't intended to have enough air flow to keep a 36G 10k disk happy for more than a (very) few hours. yes, the 36G drive, being naughty in the Mac's site, snuffed it. Nick.
Re: RAID1 powerloss - can parity rewrite be safely backgrounded?
Steve Shockley wrote: RedShift wrote: Anyone got any similar experiences with hardware RAID cards? Hardware RAID has always been misery for me. I've had two instances where older Adaptec RAID cards had a disk failure and then reverted to a week-old copy of the data. I'm not quite sure how that's possible, but having it happen on two different machines, at two different employers, in two different brands of servers (Dell, HP Netserver) made me a real believer in Adaptec. I've had generally good luck with Compaq/HP and LSI controllers. I'll give you a fairly realistic possible explanation: For whatever reason, at least some SCSI drives in at least some RAID systems (I saw a lot of it on SCSI Dell PERC cards) will just hop off-line. Nothing wrong with the drive, if you pull the drive out and put it back in, either in SW or physically, it will go back on-line and happily rebuild. Curiously, these same PERC cards also lacked any kind of beeper to let you know they were in any kind of degraded mode. They would turn the deactivated drive orange instead of green, but even that was in dispute with one of our offices which managed to have two drives fail in a RAID10 array and swore there were never any orange lights on the machine (I was checking!! Really!). SO, I suspect that one of your drives hopped off-line and no one noticed. A week later, the OTHER drive failed. Either the system was then rebooted or maybe it just figured, Hey, let's see if we can revive that other drive on its own, and ta-da, you are running with week old data. And no, I can't prove it... [rest of this isn't aimed at Steve...] RAID is a complexity, and complexity is the enemy of security and reliability. It *may* help protect against data loss. It *may* keep you running. It *may* also be the cause of the data loss or downtime. PROPERLY implemented, RAID can be a part of your event recovery process. It certainly can give you performance gains. But if you don't understand the system in your hands, it will most likely bite you hard at some point. Alternatives should be considered: many apps such as firewalls and DNS servers don't need/want RAID at all, as you can mirror entire MACHINES. At that point, the disk failure becomes a special case of system failure and you are ready for it. RAID becomes simply an unneeded complexity. For many systems, L. V. Lammert's rsync system (or even dump/restore) to a second disk in the system is wonderful. Done properly, it can be SUPERIOR to RAID for some apps, in that it gives you a roll-back if you make an error on a change or upgrade...and a number of other failure modes where you wish you could roll back to a previous version. The question of HW vs SW RAID is wrong. The question is understood vs. not understood RAID solutions. I understood very well the old Netware 3/4 software mirroring, and had complete faith in it, and had the experience to prove it on a number of cases. On the other hand, I saw a lot of systems that were completely hosed because people DIDN'T understand the system and expected magic to happen (or someone else to be on call) when the system failed. Same thing goes for HW RAID. HW RAID is easy to get running, but that usually means you have NO idea how it is really working, and that makes it less likely you will know how to get it back to fully functional state AFTER an event. In most (yes, really, I'm convinced it is the vast majority) cases, people make the error of thinking getting it running is the challenge. NO!! The point of RAID (and the rest of your system) is to keep your system serviceable AFTER something goes horribly wrong. What happens when the system goes down hard, how do you bring the system back to a happy state after a drive failure, what happens if you try to stick too small a drive in (yes, it won't work, but how will it inform you the new drive is one pseudo-cylinder smaller than the old ones? Knowing that will save you major headaches when it happens when you can no longer get the exact model of drive you had in place before...or the mfg changes the drive specs without changing the model number (yes, that happened to a friend of mine)). Moral: learn your RAID system. Whatever it is, you have to understand it. Nick.
Re: Question on upgrade path from 3.9 to 4.1 (pf, carp, etc.)
kyle wrote: Hey list.. Im looking to upgrade my 3.9 boxes to 4.1. I plan on upgrading the standby boxes first, and am expecting them to still be paired up pf/carp/ospf-wise with the 3.9 active boxes while I burn them in. I know in the past I ran into an issue where there were differences between releases where pfsync wouldnt work(Im forgetting a bunch of details), but the point being when that had happened I needed to pull the trigger and upgrade the active firewalls at the same time as well. So, would pfsync work between a 3.9 and 4.1 box? Has the pf syntax changed at all? Or can I restore my pf.conf from the 3.9 install onto the 4.1 install without needing to make modifications? Would carp still work? Anyway, any gotchas in a 3.9+4.1 pair of firewalls? I'm not sure what you mean by burn them in -- these are existing machines, running 3.9..they've been burning in for over a year now. They work. Letting the standby boxes run 4.1 while all the traffic is going through the 3.9 boxes isn't doing any kind of testing at all. Do one box at a time, but keep moving, do them both. Don't split the machines like you are planning. You may have some issues on the 4.0 - 4.1 transition, as the PF rule interpretation has changed, though that won't be a pfsync issue, that's a rules issue, and your 4.0 rules may run a tiny bit differently in 4.1 (and usually, better. It may fix things you didn't know you had problems with!) Do your work off-hours. That way, if you do break a state, it wont matter much, and probably no one will notice. Even if you ignore the CARP/PF issues, if you screw up, less likely anyone will notice. Some notes from a PF and CARP developer for a FAQ article, er..I haven't written: -1) Make sure your aliases match on the carp interfaces between boxes. You don't want to have five IP addresses on carp0 on one box and three on the other. Trust me on this. 0) Make sure your PF rules are synced, both on disk and in use. 1) completely upgrade your secondary box 2) Edit the hostname.carp files on the primary to have a higher advskew than the secondary. Yes, edit the files. 3) reboot primary, secondary will take over, and because of step two above, primary will stay..er..secondary. IF there was going to be a problem, this is when it happens. 4) Test. If there is any problem, fix or restore hostname.carp* on primary and reboot, primary will take back over until you figure out what went wrong. 5) Upgrade primary, verify states are syncing. At this point, either move the stickers on the firewalls showing which is primary and which is secondary, or restore your advskew values. Either way, AFTER the upgrades are complete, make sure both firewalls have had a chance to be MASTER to make sure it all works. This is non-peak time, remember? This is when you do this kind of testing. Do this all in one sitting. Don't leave it mixed-versions. Do it this way, and you really risk only one bump in the process. Nick.
Re: Addendum to FAQ 4.8 - Multibooting OpenBSD/i386
Paul Stvber wrote: If OpenBSD's MBR bootcode works for you (fdisk -u), you can hexedit it so that it will boot a fixed MBR partition (instead of the ``active'' one) if the user holds down either Alt key during boot. The marked byte at offset 0x35 tells the fixed MBR partition (04=first, 01=last). Offset 0x2B old: 03 new: 08 Offset 0x2E old: B0 07 E8 CB 00 80 0E B4 01 01 new: E8 1A 01 EB 05 83 F9 01 EB 17 ^^ Offset 0x148 old: 6C 64 20 42 49 4F 53 0D 0A 00 new: 0D 0A 00 C7 06 4D 00 EB E4 C3 Works with src/sys/arch/i386/stand/mbr/mbr.S revisions 1.19--1.21 (OpenBSD 3.5--4.2). The patched MBR bootcode will print MBR on floppy or o instead of MBR on floppy or old BIOS, and the user cannot force CHS reads by holding down Shift (biosboot(8)). That's a neat trick, having done a lot of that kind of binary code modification back in the 1980s (in CP/M and DDT or DU) I gotta respect that, but I'm not putting that in the FAQ. :) It's a bit too hack-ish for the 21st. century. You are, however, on your way to a rather nifty boot selector. Finish it up (make your mod in source, write a maintenance program for it so you don't have to manually edit the sector and make the maintenance program open source and available for multiple platforms), and you have a nifty boot selector that works slicker than many big name ones for people who know what they are doing. (don't forget the logo, mascot, mail list and website. You are doing it in the wrong order, though -- you aren't supposed to do the coding first! :) Hint: Rather than using CTRL or ALT or SHIFT, try NumLock, CapsLock or ScrollLock. That way, you can tap the key and walk away if your machine takes an eternity to boot. Probably won't work for all systems (I suspect some will clear 'em all before the MBR is loaded) but beats waiting around for those that it does work with. I used to use this with a batch file that determined how an old DOS/Win3 machine I had would boot. Nick.
Re: partition layout
Douglas A. Tutty wrote: Hello all, I have a 486DX4-100 with 32 MB ram. I bought an 8 GB drive to put in my P-II and it won't boot it so I've put in in the 486 along with a 1 GB drive. you might want to spend more time on that PII system... I'm on dialup and would like to avoid a bad partitioning decision requring a whole new install/download cycle (I'm on slow dialup). Ouch. ... The box has two drives, both Western Digital. One is 8.1 GB, the other is 1.1. I'll be installing 4.1 release then installing the patches and following their instructions re rebuilding. have you tested that 1G WD drive? Those were curiously cranky, reliable drives. Yes, that's what I meant to say: some years ago, I became the proud owner of something like 60 machines with those drives in them, ranging from never having been powered up (still had factory load on 'em!) to being very heavily used. The majority did not spin up on their own, but if you manually twisted them, they would fire up and stay running...until you turned 'em off long enough to cool back down. Here's what I'm thinking: ...[snip a very functional plan] Do you think that this will give me all the room I need to install and keep patched: full install icewm or Xfce Konqueror on a 486?? Firefox on a 486? With 32M RAM??? 18489 nick 20 73M 93M sleeppoll313:36 0.10% firefox-bin No freaking way. I don't like running Firefox on my 850MHz laptop. a pdf reader or two (Evince, Kpdf, Xpdf) mplayer on a 486? mc mutt vim Yes, I know that compiles will take forever and a day, but hopefully I won't be recompiling much; I need the space in case its required. Not just compiles. Most of those apps just won't run on a 486 in anything more than a oh, look, it came up! sort of way. Are these partitions a good size in the right order or are they any suggestions for improvement? your (partitioning) plan is not bad, but here are some thoughts: Assuming your 1G drive works and you don't bust your knuckles spinning the thing up manually (don't ask), don't use it on this system, but rather use it to place all the install files on. That way, you don't have to do it right the first time. Load it up on another machine (or on this machine before you remove its current OS). Put it in as the secondary drive on the system, boot off floppy, point the install media to the 1G drive as the source for the files (it will read FAT and FAT32). Every time you download a new package, put it on this drive. More reality checks: 1) Many 486 machines have only one IDE port. 2) Many 8G drives don't want to work as a secondary to a 1G drive (but the 1G drive will probably work fine as a secondary to a 8G) 3) IF you get X running on this thing, you will very possibly find that quits working for 4.2. Many old systems like this will need XF3, as XF4 and X.org don't support many of the old drivers. XF3 is gone for 4.2 (and there was much rejoicing). 4) At best, this thing will be an X terminal for you, you won't run many X apps on it. 5) You probably don't know how to configure an ISA NIC 6) I'm trying to forget how to configure an ISA NIC (damn flashbacks) 7) You don't want to know what I will hopefully be putting out on the curb for trash day ..er..next week, since I'm spending tonight answering email. 8) with 32M RAM, swap will be your friend. You need to get out more and meet better friends. This is going to be a really frustrating machine to learn OpenBSD on. Learning almost always requires making mistakes (even if completely intentionally made!). OpenBSD will run on a 486 better than just about any other OS now, but that's not saying much at all, unfortunately. Just logging into the machine will be painful. I wish there was an economical way to get some of the stuff I toss out to some of the people in the world who would love to have it. Nick.
Re: How can I install 4 OS'es on one disk?
stan wrote: I have a new laptop that I would like to set up to have 4 different OS's on. The OS's I would like to install are: OpenBSD FreeBSD Linux Windows (XP r Vista) Is it possible to do this on the one disk. I do have enough space, my concern is about portions. If it is possible can anyone give me an idea how best to approach this? Or a pointer to some docs? Ate the moment the machine has the Vista part-ion, and it's recovery partition (which I figure I don;t need), and a Linux partition on it. I can boot Linux, or Vista using Grub. The answer to your subject: line is with pain Not really an OpenBSD question, more of a How well do you know your OSs? question... You have four primary partitions to play with. Windows, OpenBSD, and possibly FreeBSD will each *need* to be in one of those partitions. I think you are a bit fast to toss your recovery partition, you may wish to give this machine to someone else later, you might wish it was still there for their benefit (at least, dump it to something where you can later put it back. g4u may be your friend here). Besides, if you don't end up dumping your Windows installation, and probably your recovery partition by accident in this process, you were probably lucky. That leaves one partition. And Linux likes to use multiple fdisk partitions (unless you follow the advice of those that propose swapping to RAM disks). So, you probably need to make this one remaining partition an extended partition. Linux will use an extended partition, but I'm not sure if it can boot from one, nor do I know if a boot loader will extract it and boot from there (and I suspect there will be vendor-specific BIOS questions, too). That's your problem to figure out. Personally, I think this is a bad plan. I really can't imagine that you will be regularly using all four OSs on the one machine. This probably means you are wishing to learn all four OSs (or learn some and use some, whatever). Learning implies not yet master of, and multi-booting requires either complete mastery of the boot process of ALL involved OSs, or a type this and don't ask any questions HOWTO for idiots guide, and you aren't likely to find one that matches your exact combo. Since you are asking the question, you aren't complete master of the boot process, I suspect. Get an old PC, install ONE OS on it, learn it. Once you understand the boot process on that OS, set your laptop up to multi-boot with that OS, use your PC to learn the next one. I don't think I'd try to get four OSs on one machine, just use the laptop as a terminal for other OSs on other machines. Nick.
Re: Multi booting OpenBSD and OpenBSD and
One of the sports in answering a question is to figure out what the asker's true motives are, and what the likely results are going to be if things go exactly as the asker wishes. Next you try to figure out what the results are likely to be, regardless of the asker's wishes. I've known R for a while, I know he understands a good educational opportunity when he sees it, and data loss is usually very educational. If not educational, funny. :) RW wrote: I have seen plenty of QA about multibooting OpenBSD and Windows/Linux/whatever and although I did a lot of that stuff way back, I generally don't need it in the days of almost zero cost PC that are plenty good enough to run OpenBSD. So why this question? Well I was blessed by a client who had some troubles with a fairly recent grunty Intel mobo and donated it with its RAM to me for past favours. isn't it wonderful when that happens? :) I figured it would make a pretty nice build machine, tossed a 160G SATA in and voila! Then (the devil made me do it!) I thought: Why not four OpenBSDs as in Release, Release minus one, current and some experimental stuff. Just multiboot to whichever and away. After you get this all done, it will be interesting to see which one(s) you actually use. :) Pretty soon the Release would be stable for latest and one back etc. I know that something like GAG would handle the boots but how would I slice and dice the drive? I managed to play with fdisk and set up partition 3 with about 40G at the end of the disk and use the b command in disklabel to describe the disk and whacked in a bunch of filesystems. Pretty standard install - booted and ran just file. Then I fdisked again to do partition 0, easy. Even remembered the 63 offset. BUT (and I can see Nick Holland smiling here) when I get to the disklabel phase and use b to describe the disk, I still end up with all those other partitions visible. :) I don't want to cream the first install unnecessarily so I'm here to be told. aw, where's the education (or humor) in that? :) Is it at all possible? If so what is the trick? I did flag the new MBR entry as active and I can't see anything in the docs that contemplates this kind of set-up. If there is an answer at Mother Google's I cannot construct a smart enough query to not be drowned in all the OpenBSD and some other OS questions. Anybody successful at this task? I've only done two complete systems on one machine (my one and only amd64 system, which I got and planned to never run a 32 bit OS or app on, and then promptly put to work testing *sigh* i386 code...). As you discovered, the disklabel goes in the /first/ A6 MBR partition, not the /active/ A6 partition. The trick is this: have only one A6 partition active at any one time. The rest are..well, anything other than A6. You might be able to make them FreeBSD or NetBSD partitions, and actually access them through a bit of disklabel magic..haven't tried that, but it might work. So..install one, reboot. During the install of the next, renumber the old A6 partition to something else, create a new A6, install, reboot, repeat. Here's the problem: I highly recommend NOT changing the fdisk partitions around while the system is running. It really didn't like that one bit (I seem to recall a complete reload :) Boot bsd.rd, change it there. That's the no-tools approach. Some of the various bloated boot managers will do that for you in other ways, calling it something like partition hiding, seems not just OpenBSD dislikes having multiple boot partitions on one disk. :) You *might* be able to save a copy of the MBR from each of your MBR images (dd the first sector of the disk to a file), then dd them back into place and reboot...that might keep the kernel from noticing the other disklabels...but practice where you don't need the data... something like these completely untested lines: dd if=/hole-in-foot/current.mbr of=/dev/rwd0c bs=1 count=1 reboot (this will either install and boot off the MBR of your -current partition, or reduce your file systems to something tantalizingly close to useful, but just random enough to drive you nuts. I'm not sure which. :). For extra credit (and lost data), manually disklabel your disk so that your /home, /swap and /tmp partitions are shared between the installs. Remember: extra credit is given in school, and screwing things up horribly is usually educational. :) Now, most people know I'm not much a fan of virtualization (It's great when done right! Exactly. Show me it done right), but this might be a great place for it. Even something slow like qemu might be perfect for your needs -- you want your speed (i.e., real system) to be -current, as you will be doing most of your I want it done NOW! compiles there. -stable/-rel and -prev-rel can be in the emulators, as you won't be doing development there (RIGHT??), just testing ideas and implementations, and if you need to build
Re: Multi booting OpenBSD and OpenBSD and
Douglas A. Tutty wrote: On Wed, Oct 10, 2007 at 10:51:26PM +0200, Tilo Stritzky wrote: I just got a brand new office PC, 64bit CPU. But I'm stuck with some Apps in i386 compatibility. So I installed i386 for work. Next week I'm going to get an USB stick and put an amd64 install on it, for play :) In Debian amd64 Etch (stable), there is no way to use flashplayer (a 32-bit binary plugin that requires a 32-bit browser. To use it, you have to set up a 32-bit chroot. It never has to boot, just be a complete chroot in which to run the 32-bit browser and its plug-ins. The 64-bit kernel can run 32-bit apps if they have 32-bit libraries (which they do in the 32-bit chroot). Is there no way to do this in OpenBSD for your i386 apps or will the amd64 kernel not run 32-bit apps? Not natively, no. I've been told it is possible to implement, if you wish to write some code. Not a whole lot of interest among the developers, however. And no one else has stepped up to do it. OpenBSD is an OPEN SOURCE OS. Seems kinda pointless to run closed source drivers and apps and and and on an open source system, doesn't it? OpenBSD is security oriented, achieved through active auditing and verification. Strange place to stick a Mystery Binary, don'tcha think? Funny, the Linux people are content to use Mystery Binaries, might explain why they have so many of them they have to use. Nick.
Re: expansion of FAQ# 1.10 re OpenBSD as a desktop system
Douglas A. Tutty wrote: I've been evaluating OpenBSD as a desktop system while learning about it on my lesser (older) hardware. I've learned a lot and will continue to learn about OpenBSD but I don't think it will work as my primary desktop. Based on what I've learned here on Misc, I'd like to start a discussion about extending the answer to the OpenBSD FAQ # 1.10: Can I use OpenBSD as a Desktop System? While of course every potential new user has to evaluate OpenBSD for themselves, we could and I believe we should point out some of the more common tripping points found by people who end up not choosing OpenBSD for their desktop. 1) We don't do discussions. 2) See rule #1 :) ... I think the following paragraphs would enhance the FAQ to provide the person new to the OpenBSD focus a heads up on some of the difficulties. # 8-- However, it is also worth noting that some desktop needs and uses are incompatible with the focus of OBSD. There are currently no video cards that provide full specs to create open drivers for all hardware function, most notibly 3D accelleration. While more than adequate for most uses of the X-Window system, performance while watching movies, playing games, or graphic design, may be suboptimal or not possible depending on your hardware and expectations. Wow, you determined a lot from your experience with your 486... Never found a use for 3D acceleration myself. Seems to be mostly for games and, well, games. The use of binary blob drivers would introduce the potential for unknown security breaches and is not going to be supported on OpenBSD. The work is ongoing in the larger open-source community to both create open-source drivers that can access the full hardware potential of the video cards that are available, and there is some work to create new video cards that will be fully open and high performance. It just doesn't exist yet. and no point talking about things that don't exist. Similarily, flash plugins in browsers cause untested code to run on the computer and introduce the potential for unknown security breaches, and are therefore not supported, other than as it already exists for the Opera browser. It depends therefor on what is meant by desktop. System administrators will likely be thrilled with OpenBSD on their desktop. However, a home user wanting an entertainment centre, a movie editor, a graphic designer, or a user requiring a multi-headed Computer Aided Drafting and Design system may find the tradeoffs made for security are too steep to use OpenBSD as their operating system on such computers and may choose to use a less secure operating system. I should introduce you to fluffy, my multi-headed computer. Two 1280x1024 LCD panels, one 1600x1200 CRT. Why do I have three monitors? Because my table isn't big enough for #4 (there are at least two empty PCI slots in the thing. :) # 8-- Does this seem like a fair addition? no, I don't like this. And, I get to make those decisions. :) I obviously don't share your definition of desktop. To me, you don't describe a desktop computer, you are describing an entertainment system. I do work with my computer...both for money and fun, but it is a tool to accomplish what I wish to do, not the goal of my work. It is a tool on my desk, like my the phone, the calculator, the screwdriver and other tools. I watch movies in a theater or on a TV. It's good to step away from the computer once in a while, and interact with people. How about mentioning the fact that it doesn't run Microsoft Office? That is a lot of people's definition of a desktop computer. They don't want OpenOffice, they want MS Word, Excel, and Powerpoint. How about Autocad? Outlook? Visual Basic? Halo3? Nero? Weblogic Workbench? That silly but addictive game my mother plays on her laptop? How dare you call it a desktop without these apps?? Personally, I absolutely LOVE the fact that OpenBSD doesn't support flash natively. I think that's a great selling point for using it on a desktop. Oh, but you not only like flash, but demand it. That's ok, that's your measure of desktop, it's my measure of annoying. Are there some places I can't go? Yep. I rather suspect they lose more by not having me than I do by not having them. There is no shortage of flash-free or non-flash-dependent websites for me to waste my time on. Based on the saying, What is the most commonly clicked on link on the Internet? 'skip intro', I really don't think I'm alone here. It sounds like your definition of desktop is Windows, but you don't like Windows. Ok, whatever. Use whatever Windows-emulating system you like best. OpenBSD is not spending its time emulating Windows, not in look-and-feel, not in application count, not in design, not in security. There were desktop computers before Windows, there are desktop computers OTHER than those based on the Windows model. OpenBSD isn't for everyone. It is for each
Re: openbsd 41 install
Mike F wrote: i am installing in ipx, created floopy, booted ok into floopy, but got these errors when I selected [I] for install. ERROR: No root partition (sd0a). disklabel: ioctl DIOCGDINFO: Input/output error Is my hdd toast? thanks, Toast, or not there, or not hooked up properly... dmesg will tell some... Nick.
Re: Problem with disk size
Jon Sjvstedt wrote: Hello all! I have an OpenBSD-box with two 250G drives inside (and some SCSI). Trying to use one of the drives as a whole gave this from disklabel $ sudo disklabel -p g wd0 [snip] don't snip. 16 partitions: # sizeoffset fstype [fsize bsize cpg] c:233.8G 0.0G unused 0 0 # Cyl 0-486343 d:233.8G 0.0G 4.2BSD 2048 16384 16 # Cyl 0*-486343* but df -h says: /dev/wd0d 7.8G7.4G4.2M 100% and I cant create any new files on the drive. What could be the problem here? Any hints appreciated. dmesg attached. thanks for the dmesg. You tried darned hard to obscure this (I really don't care how many G your disk is, I care about which sectors you are using), but it does appear that you opted to not properly partition your disk. The fact that you didn't show the output of fdisk causes me to believe you knew it, though you may not have recognized the significance. ;) Your OpenBSD subpartition appears to start at sector zero. Bad idea. This means, whether by design or by accident, you don't have an fdisk partition table (aka, MBR) on the disk. Also a bad idea. On some platforms, i386 is one of them, you must use fdisk partitions, and your disklabel partitions must start at a one track offset (in your case, probably 63 sectors). When you don't follow the rules, ugly things happen. It isn't the size of the disk, it's the way it's laid out that is giving you problems. See faq14.html... Nick.
Re: new dell install completed, but...
[EMAIL PROTECTED] wrote: all, I'm happy to read whatever I need to, in order to get this system running. I come before this list humbly. Please don't flame my ass with RTFMs :) I have a new Dell Optiplex 745 with an Intel Core 2 Duo. this system completed the install. Now on boot it hangs after: wskbd1: connecting to wsdisplay0 the only issue I had during install was that the on-board nic would not grab a dhcp address - but the pci nic did. how can I troubleshoot this further? I followed the FAQ for the install - and I've looked at the common issues after install. years ago I had an issue with a piece of hardware that I had to exclude. but I don't recall how I got into that particular sub system to deactivate it. Is there something I can do at the boot prompt? Humbly yours, Metajunkie First, make sure you are trying a snapshot, not 4.1 or older. If you are using 4.2, still try a snapshot, a lot has happened since 4.2 already. If that fixes your problem, you are done. (the onboard NIC problem is hinting to me that you are using an older version). If that doesn't, the good news is since it installed with the bsd.rd kernel but won't run GENERIC, it is probably just a matter of turning the right device driver off. GENERIC has more in it than bsd.rd does. http://www.openbsd.org/faq/faq5.html#BootConfig (see the next two sections as well, which are also appropriate for you) I don't recall if I ever installed OpenBSD on a 745. Certainly did a fair amount with a 620 (which worked fine). Nick.
