Re: Serial console questions on i386 and amd64
Nick Holland wrote: Don Jackson wrote: I use serial consoles on all my OpenBSD servers for remote serial access to the machines, both during initial install via pxeboot, and later on in regular use after the install. I'm currently running either 4.2 or 4.1 on all my machines. The FAQ states: Only the first serial port (com0) is supported for console on amd64 and i386 http://www.openbsd.org/faq/faq7.html#SerCon Why is this the case? because that's the way the code was written... Why does OpenBSD care which serial port I use? because that's the way the code was written... Will it simply not work if I specify set tty com1 in /etc/boot.conf ? I certainly wouldn't plan on it working. Feel free to try. Don't whine if things work as advertised. Well, I've been informed that at least for -current (and I'm pretty sure that means for -recent :) it DOES (at least sometimes) work. I just tried it on one of my machines with -current, it Just Worked. (and on -current, it works Just Cool. Set it up with com1, not only does it install on com1, it sets the config files up for com1) So, I'm happy to report that I and the FAQ are at least partly, and very possibly completely wrong on this. I'm pretty sure this was true at one point, obviously that limitation was removed, and tom@ is probably going to pull up a list of 20 test cases I ran for him, but I don't remember that. FAQ will be fixed once I make sure deleting the warning is 100% appropriate. Nick.
Re: P2V with VMWare - ERR M
RANT ALERT!! RANT ALERT!! Zlfar M. E. Johnson wrote: Thanks for the replay. I was not sure which man page you were referring to, but I took a quick glance at installboot. I have often cloned linux systems at work with rsync. I have also done bare-bone restores using system-rescue cd and backups from our backup system. I thought it would be interesting to see how others do it with openbsd. very simply, actually. :) What exactly are you referring to Diskimage route it's not so easy.? Are you referring to cloning the system? Similar to this example http://www.monkey.org/openbsd/archive/tech/0112/msg00079.html What tool does one use to Diskimage the system? You could probably try this tool if I understand what you mean by Diskimage http://sanbarrow.com/moa-video-vdiskmanager-as-ghost.html All the P2V (and imaging) stuff is really missing a big point: If the target machines weren't hopelessly broke, it shouldn't be a big deal to move to a VM system. Just activate your DR plan! Ah, but the problem is...lots of broken designs exist, running with obsolete apps on obsolete and over-complex OSs that can't run on modern HW and no one can figure out how to reload the apps on a new system. Why are there no tools for P2V for OpenBSD? Why would you need them? The tools you need are in the OS: dump/restore, tar, cpio, dd. Granted, you might just have to spend a couple hours understanding how your OS works..but MUCH better to do that on your schedule than with 500 people sitting around idle asking When are the computers going to be back up? These tools shouldn't need to exist for other OSs, either. Just activate your Disaster Recovery plan on to the VM system. Oh, you don't have a DR plan? That means your system was not well designed. Migrating a system SHOULD be no more difficult than restoring your backup...and you should have tested that process. Oh, your system is too old to run on modern HW? Your system was either not well designed or not well managed, in that it was allowed to outlive its useful life. Oh, no one knows how to recover your existing system? Your system was not well managed, as documentation wasn't kept, people weren't cross-trained (or they were all driven away faster than they could cross-train new people as happened at my previous employer). Oh, your system is too complicated or time consuming to migrate through normal DR processes? Perhaps sticking configuration info in magical places that most backup systems never touch? Bad decisions were made on the design and product selection. Hey, these things happen, so P2V software for some OSs is pretty close to mandatory for some tasks...but remember what it is -- it is a work around for a problem which should NEVER HAVE EXISTED in the first place, and an indication of bad design, not a proper way of doing things. Quintuple bypass surgery and heart-lung machines are really fantastic equipment...but it is better if you can admire them from a distance... It is easy to get into the cool tools mindset. You should have seen the first draft of the note I first posted to this thread -- I had a really cool process of using dd and growfs and then I realized I was solving a problem that didn't exist (there are times when you might want to use dd and growfs, and at least one time when I seem to have NEEDED to, but that's pretty unusual). Backup! Restore! Ta-Da! Failure to be able to do this should be your first warning sign that something is very wrong, and rather than migrating or virtualizing your problems, be a real engineer and FIX the real problem, don't just change it. Remember, virtualized systems can need Disaster Recovery, too... (end Rant) Nick.
Re: [bug fix] Problem installing OpenBSD 4.2
Saulo Bozzi Daleprane wrote: I have a problem installing OpenBSD 4.2 in old machines. The bug fix instructs to use disc 2 of amd64, but what's the name of this ISO?! lots of responses, all wrong. This issue ONLY impacted the official, purchased CD sets, not the downloadable images. If you have the official CD set, you just use the disk labeled amd64, not the one labeled i386. That's pretty painfully obvious if you own the CDs, so I think you are referring to the downloaded images. So, if you can't install from the downloads, you have a problem other than what you are looking at. Provide useful info, we can provide guidance. Note: i386 machines I call old can't boot from CD. :) Nick.
Re: Is there a tool or a deamon that documented a change in the /etc directory?
Stephan Andreas wrote: The problem is clear, I think. But a simple example: You are an operator for e.g. a OBSD Firewall. Yesterday everything was ok, Today a person phoned me and want that I open a tcp port for him. Ok I open. Tomorrow, I notice problems that I never have had before. But I have forgotten the new open port. Now it is nice to have a ChangeLog. Because it is faster than restore an Backup. ...and more productive, as you may be able to see what is wrong, rather than simply roll back to what was... This functionality is built into and turned on by default in OpenBSD. If you set up the root user's e-mail to forward or otherwise be delivered to your inbox every morning, you will find this is already being done for you. If you didn't do this, you have a pile of these things waiting for you to read through in /var/mail/root. Every night, as part of the /etc/daily script, it looks for changes to the files listed in /etc/changelist, and stores a backup of those files. If it finds a change, it mails you a diff of that file in an insecurity report. If you keep those, you have a very good record of the history of changes on your machine. Ta-da! Just what you asked for, by simply creating a /root/.forward with just your e-mail address in it. :) Within a few days, you will be reinventing this on every Unix machine you work with. That being said... I'm also fond of this little entry in my /etc/daily.local file: TGZFILE=/backup/`date +backup%Y-%m-%d`.tgz cd / tar czf $TGZFILE etc var On firewalls and DNS servers I have done this with, you get many YEARS of this backup files on the spare space on a 40G drive. Another trick that works well for firewalls is to have a script which you use to synchronize the pf.conf (and other) files between machines. I wrote one which: * did a diff -u against the other machine * Recorded that diff into a file, tossed the user into an editor to both review and explain/document the diff * Saved that file to /bkup/history * copy the compared files AND the change log file to the other machine and install them * run pfctl -f on that other machine. (this was all done in shell script and base tools, no packages were added to the machine) Yes, you could say I reinvented cvs for this, but I liked this specialized script over a general CMS for a few reasons, including the fact it stuffed the diff in your face and had it there while you were making the change message, and I found the dated change files much easier to grep through when looking for when something changed and why. Nick.
Re: Move hard disks in soft raid to new machine
klemen wrote: Hello I have new computer in which I would like to have same things as on old one (OpenBSD 4.2). In old one have software raid with two 500g ide drives. How will raid react if I move both disks to new computer with completely different hardware. depends how completely different you are talking about. :) If you are going from an amd64 system to a Sparc64, it won't work for a lot of reasons long before you get to RAID. However, I suspect by completely different, you mean 80% the same, such as from an AMD64 to another AMD64 or i386 to another i386, (or even i386 to a newer amd64) in which case, it should just work, again having nothing to do with the (unspecified) software RAID system in use. Granted, since we are missing all specifics here, you win nothing for coming up with a wacked scenario that it won't work in (I can think of a few), but since the software RAID partition is just a partition of the disk, if the system boots (indicating the partitioning is good), RAID will usually just work, and it will almost always boot when moving around on the same platform. Nick.
Re: AMD Geode
Nicolas Legrand wrote: Damien Miller [EMAIL PROTECTED] writes: On Mon, 17 Mar 2008, Dimitri wrote: Hello all. My cuestion is simply. OpenBSD run over AMD Geode, Yes. specificly over Packard Bell S18P?. I've read it's an AMD Geode LX800, so yes. ONCE AGAIN, the processor on an PC-like machine is one of the least important parts to the question of compatibility. The question is, what are all the other chips around the thing, how are they hooked up, and how badly did the designers screw it up in ways that haven't already been dealt with already. Unfortunately, until someone tests a machine, it is pretty close to impossible to find out. Load OpenBSD on a USB flash drive, stick it in the thing, boot from it and see what happens... Nick.
Re: [OT] Pursuing Management to adopt OpenBSD
Chris wrote: I been trying (rather unsuccessfully) to convince various clients and employers to adopt OpenBSD. Most people, I find, are resistent to change and would not use anything they are not familiar with. Others would say that if I leave the job, it would be hard to find people who can use (or even heard of) OpenBSD and in some places Management never heard of OpenBSD and have very little clue as to how good or bad it is compared to Linux/ Solaris and Windows thus they will just knock off the proposal in 2 seconds. Is there any way I could convince these people to make the move to OpenBSD? Suggestions, tips and tricks along with real life examples would be much appreciated. Thanks. *) Respect the work that has come before you. No one likes someone who walks in and says, Let's change everything, because this is what I know!. Wait until you know the real problems...then deliver solutions based on the problem, not based on your desires. *) Prove to them that you know what you are doing on OTHER things. Solve real problems, make things work better, document existing systems. Give them reason to trust your judgment and quality of work. *) Prove to them that you can (and do) document the systems you are responsible for. *) Point out the relative unknownness of various products already in your environment. I.e., if you have a SAN that only one person in the office knows how to configure, you have just won the not familiar argument. Even if it is the Indu$try $andard $olution, the How you configured it in your environment is critical. *) Point out that people who know OpenBSD may not be falling out of trees, people who REALLY know Linux, Solaris, Cisco, Juniper, EMC, Xiotech, Windows, etc. WELL (i.e., not just a hack with a sheet of paper that would be more useful in the bathroom than on the wall) are not common, either...and if they are really good at what they do, they already have jobs, and you will pay THROUGH THE NOSE and every other orifice you have to get them to come work for you. The ones sitting around waiting for the phone to ring aren't that good. I recently heard a guy enjoying the idea of a $150k/yr job he had heard about to maintain an industry standard firewall. Why so much? Because there weren't very many good people available to maintain this standard device. AND, the ability to grow-your-own expert was about zero, because you could not grab an old junk machine and build a demo or test machine, you had to shell out big money for their box and their training. And, if you don't pay them a lot, your expert will go elsewhere once you make them an expert. *) Show how easy it is to BUILD your own experts. If you want to learn Solaris, you will be looking at buying some newish computers to run it on. If you want to learn OpenBSD, you can do it on old junk! You can teach your co-workers, they can work with old company equipment to learn more. Try that with the big name products. (funny story: former employer, we built a very nice set of OpenBSD firewalls. Massive redundancy, DR, etc., ALL out of spare parts. An ex-boss got a bug up his butt about having Juniper on his resume, so he brought in a pair of probably $40k Juniper firewalls. But...I don't speak Juniper. Fine, we'll have E. do it!. E. wasn't quite up to the task, and he got fed up with the BS and quit. Now the boss had NO one who could bring up his babies. He was later fired, and the new resume-stuffing boss didn't like Juniper, but liked Cisco, so in come a new pair of $50k boxes. The never-used Junipers are currently sitting in a warehouse somewhere, and a consultant made a LOT of money replacing our OpenBSD firewalls with the Ciscos that accomplished the EXACT SAME THING). *) Point out that there are a lot of people LOOKING for experts in these industry standard systems, and they are not finding good ones. Lots of people looking is BAD for your company, not good! That bids up the prices and that discourages long-term employment. *) Demonstrate, don't talk. Don't say, it would be nice if you handed me $4000 for this project, grab an old junk machine and build a demonstrator. Do it right -- include the disaster recovery, the backup, the repair and the documentation in your demonstrator. IF it proves that's all you need, you are done! *) Hook your co-workers. OpenBSD is fun, and it is very easy to learn (not just load). I managed to get a co-worker interested, he's now got an OpenBSD machine at home, which has been doing real work for him and solving problems (and the Windows box puked its guts, but the data was stored on Samba on the OpenBSD box, and now his wife is a fan, too! :) Guess what? We now have TWO OpenBSD experts in the office. (which is probably more than we have of the official company solution). *) Solve real problems with OpenBSD. On my second day on the job, the guy I was replacing told me about one problem he had -- a mail server would collect huge amounts of mailer
Re: BSD Documentation License?
Lars Noodin wrote: If one has to identify a specific license (or licenses) for OpenBSD documentation, which is/are recommended? Is there a generic BSD-Documenation License anymore? I wasn't able to spot anything in either the OpenBSD FAQ or the Misc mailing list archive. Regards, -Lars I'm not entirely sure what you are asking...if you are asking what the license is for a PARTICULAR bit of existing documentation, the source file is your clue. It's not only a clue, of course, it's the law. The man pages tend to follow the application they are documenting, pretty much out of necessity. You don't want to have the official documentation having different distribution rules than the app. The OpenBSD website, for the most part, has no license, which means it falls under standard copyright law. Parts of the FAQ are under a BSD-style license. For stuff you publish on other people's site, you follow their rules or guidelines. This is actually pretty critical, as your docs will go out of date quickly, and if history is an indicator, you will probably not bother to update it, so someone else will need to step in and either delete it or update it (or at least, modify it to say, this is great historical information about this five year old problem, the writing is sublime, but completely pointless now.) For stuff you write and publish yourself? Why are you asking us? Decide what you want done with it, and act accordingly! Why should someone else decide how YOU license YOUR work?? If you really want others to tell you how to distribute your work, may I suggest the GNUbies... Anyway, cheap shots aside, for many, many uses, you should probably just stick with standard copyright law. If you want something other than that, ask yourself why, what you hope to accomplish, and how you and others will benefit from a license. Think long and hard about it. Are you going to be upset if someone takes your BSD'd webpages, prints them on their laser printer, binds them in book form and sells 'em for $40/ea, and ends up on the New York Times Best Seller List without forwarding a dime to you? If not, don't BSD-license your text. It happened to us, a lot of people were all bent out of shape over it, but Joel and I had already discussed that probability and we were ok with it, both as a hypothetical and after it actually happened. How do you or the world benefit from having your writing in slightly different form at 700 different sites around the Web? I don't have a good suggestion, really, other than be careful. I admit that third-party documentation for free software sounds like it should be free at first thought, but /practically/, I don't see the benefit to anyone. When we BSD'd parts of the FAQ, we had what we (Joel and I...I think it is should be pointed out that Theo thought we were a bit nuts) thought was good reason, and we have no regrets about doing it. BUT it isn't for everyone or everything. I've not even looked too closely at free documentation licenses. I just don't know what I want them to say in general. Usually, I prefer that what I write either stay under regular copyright law, so I can determine how it is distributed, modified, etc. or should be spread as widely as possible with nothing more than attribution, and much of what I write would probably be best for me if spread without attribution or buried and never seen again :). Nick.
Re: Intel Core2 Dual/Quad - i386 or amd64?
Alexander Hall wrote: What is the recommended architecture to use for Intel's Core2 (Dual/Quad) processors? I have two computers I'm considering going amd64 on: ... I've found the following (likely incomplete) list of things that may affect the choice, or might be affected by it, are: - Memory (4GB limit) - W^X W^X is available on most OpenBSD platforms, including i386 and amd64. - 64-bit instructions as a user, you don't execute instructions directly, so this is mostly just bigger is better hype, the same reason people get excited about seeing all their cores in their dmesg on an app that a 100MHz Pentium could do just fine on. Most of the same apps work on i386 as on amd64, you really don't care what instructions are being executed (or how many bits are in 'em) to make them run. http://www.openbsd.org/faq/faq12.html#amd64Intel To be honest, most users probably won't see a difference. Me? I'd probably go with amd64, as practically speaking, i386 is slowly moving into the legacy category. I say probably, because I would very possibly forget and accidentally install i386 on it. :) Ok, based on the fact that I did that today already, let's say I'd SUGGEST going with amd64, even though I'd probably forget and go with i386 myself. :) Nick.
Re: File System Corrupted Due to didn't Umount cause by power failure
Peter_APIIT wrote: Hello all expect openbsd user, i have encountered this incident before where previously i can solve it easily but not this time. My openbsd is running for 24 X 7 but my mother going off the power and i didn't know about that for few times. After that, file is not properly unmount. OpeBSD asked me to check fschk_ffs manually but i cannot read man pages anymore but before i can. It just stop scrolling at 13%. man pages are available on-line, see front page of website. Enter shell path name or return to sh : I press enter Terminal type ? i enter tty220 what did you do to change that? It should prompt you with a default thatworks. Return me unknow terminal type, i tried it with tty00 and others No use. Then i ctrl + c to force it to terminal. you can't type random things there, at least the wrong random things. Assuming it is an i386 or amd64 with a monitor attached, it would be vt220 After that, i try ffschk_ffs and ffschk but still cannot solve it. (no error message, but we can pretty well guess what it would be) AGAIN, typing random stuff isn't how you solve computer problems. The command is fsck or fsck_ffs (either will work), and that command was told to you in the error message (which was probably scrolled off the screen due to your bumbling the terminal type question). OpenBSD drop me to single user and kernel security level is . I think is just for read and not for write. I need your help. Your help is greatly appreciated by me and others. A billion thanks for your help. If things are really messed up, you may prefer (or need) to boot from bsd.rd, either from your disk or from a CD or floppy, then fsck all your partitions. Easiest way to proceed would be to look at the error message you get at boot, it will be complaining about a particular partition, let's assume it is /dev/wd0d. You will enter in the following command: fsck /dev/wd0d When it finds errors, it will ask you if you want to fix them, say y. If it starts irritating you with how many things it is asking you to fix, hit F (upper case!), and it will just assume y for all remaining questions. Once this fsck is done, it may ask you if you want to write the fixes to disk. If so, DO SO! Otherwise, you just wasted your time. :) (I'm drawing a blank at the moment if OpenBSD is one of the OSs I've worked with that asks that question). Now, do a mount -a. The system may now report another partition needs to be cleaned, so repeat the process with the next partition, and so on, until your system comes up with a mount -a. Note, this mount -a trick attempts to mount everything in your /etc/fstab file, so if you booted from bsd.rd, this doesn't work. In that case, you need to look at your disklabel or the etc/fstab file on your disk. Nick.
Re: Dangers to upgrading without install kernel
Juan Miscaro wrote: Hello, The online upgrade documentation [1] is fairly vehement about its recommendation regarding the use of the install kernel when upgrading. I was wondering why? What dangers await someone going down the remote upgrade path? /juan [1] http://www.openbsd.org/faq/upgrade42.html#upgrade IF you follow the remote upgrade process properly, it works. When I write it, I test first on a machine in my lab, then one in my basement, then one across town that is my mail and web server, and then a bunch of other machines. So, by the time I remove the warning notes from the new version of the file, it's ready for use. I don't recall anyone reporting that they followed the upgradeXX.html and their system died because of it. However, I don't get a lot of test reports for the process, a lot more testing goes on for the install kernel process. HOWEVER, there is stuff that can happen. If you are in front of the machine running the install kernel, you have a much better chance of dealing with it. The number of ways things can go right is very finite, typically. The number of ways things can go bad is...big. Really big. Here are just a few things that could go wrong: IF you were doing 4.1 - 4.2 upgrade and your machine happened to be one of the five that someone estimated might be impacted by the ahci driver change, you would be really unhappy if you had no serial console on the system, as your machine would suddenly refuse to boot, because your HD became sd(4) devices instead of wd(4) devices. Same goes if you were any of the twenty or so people who guessed their machines would do that, and didn't. If your hard disk developed a bad spot that didn't impact operation and yet prevented booting, you will be unhappy when you reboot (been there, done that. In my case, I saw the warning signs in dmesg, and knew the machine would probably not come back up. You might not be so lucky or observant). You could easily fat-finger something, installing (say) the new kernel in the wrong place and finding out the old kernel doesn't support the new userland. You could be trying to install i386 file sets on your sparc64 system. (been there, done that, too. Works great, until you hit reboot) Your system will be semi-functional during the upgrade, this may be bad, or may be good, or may be completely indifferent. When you use the install kernel, the system is in a known state: it is DOWN, and it will stay that way until you reboot it AFTER the upgrade. However, there are several interesting time periods on the live system upgrade -- early on, you are running with the new kernel and old userland. PF doesn't always come up in that situation...so you may be running without any filters for any apps on the machine. Those apps may be running or maybe not. Those apps may start out running, then blow up once you start unpacking the userland files (hello, Sendmail!). Maybe your machine is involved in a CARP set, during the upgrade maybe it is, maybe it isn't, and maybe it shouldn't be while mid-upgrade but maybe it is anyway. In other words, you will get to your destination, but the states in the between start and finish may not be fully understood by you, and you may not be happy with the impact of that interim time. Again, this is not intended to be a complete list of what could go wrong for you. The remote upgrade process is here because a lot of people who understand their systems need it, and I need it, so I spend the time working on it. However, it's not officially recommended process, rebuilding a live system remotely is just not quite as error tolerant as using an install kernel locally. We'd be nuts to try to tell you otherwise. Nick.
Re: RAMdisk, not for boot, how?
chefren wrote: On 3/28/08 1:20 AM, Rod Whitworth wrote: The CF wearout meme needs to die. Specs, it's all about specs, it seems a fact to me that standard CF cards, as used in camera's, often without any technical specification other than size, cannot be written as often as ordinary harddisks. maybe, maybe not. Rod's right, though... I've never seen a flash media die from write fatigue. I have seen and heard of a fair number die for other reasons. There are reasons to use flash media. Reliability is not one of them in my mind. They are small, they are quiet, they are low power, they are vibration resistant. They last a long time...usually. But they can fail. The foreseeable future people need to be really careful while choosing memory cards as hard disk replacements. I agree, but not for the reasons usually given. If you are using a flash drive to avoid worrying about failures, you are fooling yourself..even if the flash drives were PERFECT, there are other parts of the computer that fail, and there are user errors. SO, you still need the EXACT SAME recovery processes in place for flash drives as you do for disks. Using flash doesn't let you dodge recovery and backup needs. If you try to shoe-horn a big system into a small flash drive and make something you don't properly maintain (key issue is DO YOU maintain it, not COULD you maintain it. Doesn't matter what you could do if you don't), the system will be less reliable. If you have an app where you need or want low power, quiet or small, go ahead, use flash media, but for goodness sake, don't screw up a really good OS by trying to meet some goal that is completely bogus. Just use it as normal, and maintain it as normal. Odds are, something else will take your system down long before write fatigue does, most likely, it will be your butchery of a working solution. It's the unexpected downtime that counts, not the reason. Who the frick cares that you tried to avoid a one-in-five-year hypothetical failure if you caused several days of very non-hypothetical downtime as a result? A simple, standard install will out-perform your hacked up mess every time. Someone posted an article recently about people liking to use Linux because they like tweaking and adjusting and working with the system. I've worked with people like that -- they are smart and clever and will cause hours of downtime to avoid a totally non-problem (or on really cool technology. This don't write to flash is a perfect example. If you wish to set a goal for yourself of I don't wish to ever write to this disk, great. BUT don't tell yourself or anyone else this frankensystem is better than the normal installation. So, if your goal is a reliable system, keep it simple. If your goal is to have fun, do so. But don't confuse having fun with doing good work. Yes, you learn more by breaking things, but you impress people more if you break 'em off-line, and use that knowledge to keep your production stuff running and repaired quickly when it breaks. Nick.
Re: i have lost /etc
Rafael Morales wrote: Hi list, Please someone help me I have deleted my /etc dir (rm -rf /etc), is there any way to recover it, or there is a way to recover my data stored in /home ??? Rergards restore from backup? :) something tells me this is not an option. Actually, even if it is an option, you probably need to get the system up enough to do your restore... Several ways. Easiest might just be to reinstall OpenBSD from scratch, but don't touch your /home partition (when it asks where to mount it, say none), then add it to /etc/fstab after reboot. You did put /home in a separate partition, right? :) You could also boot bsd.rd, and do something like: mount /dev/wd0a /mnt cd /mnt tar xzpf /path/etc.tgz then go through and re-customize it. You will be worried about hostname.if, hosts, myname, mygate, resolv.conf, but also other files, too. (now you can restore from your backup. :) Once you get the system gimping along, take a look in /var/backups. Now, vow to kiss the feet of the person who did that person should you ever meet them. Or buy them a beer, which they will probably prefer anyway. This doesn't apply if you reloaded the whole system and blew away your /var partition. You did have /var in a separate partition, right? Nick.
Re: i have lost /etc
forgot something: Nick Holland wrote: ... You could also boot bsd.rd, and do something like: mount /dev/wd0a /mnt cd /mnt tar xzpf /path/etc.tgz er.. one potential problem with that: it will overwrite parts of your /var partition, which may or may not be a problem for you (i.e., if you have a really complex httpd configuration, it is will get overwritten with the default). Again, /var/backups is your friend. Nick.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... One thing I'm not clear on: if the only issue is kernel size based on having an old box with low memory, where every MB counts, does deactivating unnecessary drivers with config actually result in a smaller kernel or just a kernel with deactivated drivers? Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this. config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. WELL...there MIGHT be a small savings in data structures not allocated for drivers, but that would most likely only be the case if you had such a device in the machine, but deactivated the driver. (i.e., em(4) (the driver) might allocate a RAM buffer for each em(4) card in the machine, but only for the cards in the machine...disable the driver, you don't allocate the buffers, but you can't use the card). Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. That would be a funky kind of relinking, or a bunch of loadable modules, ala Windows or Linux, which is why Windows and Linux needs so much less RAM than OpenBSD. Oh..wait... ;) Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. One problem is you almost certainly need another computer -- if you have 16M RAM, you want to whittle down the kernel a lot...but $DEITY help you if you need to build that new kernel on that machine, since just sitting at the shell prompt will have you into swap. HOWEVER, by the time you get to 32M, I doubt you will appreciate the time and effort required to build and reboot off a new kernel (even if compiled on another machine). You just won't be adding much functionality to the machine -- there won't be something major you will suddenly be able to do that you couldn't do before. Nick.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... So perhaps to add to this entry for the FAQ, something that address this desire to shrink the kernel to save memory: ... For standard i386 old computers with little ram, recompiling the kernel does not provide enough free memory to affect what you can then do with that old computer. You are far better to just add a bit more ram. much closer to something I'd consider adding. :) I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. Same thing was done recently with OpenBSD, actually. There are better reasons, however... The big one was the 80386 was a first generation 32 bit processor for Intel, and there were a lot of ugly work-arounds in the OpenBSD kernel for 80386 systems that didn't need to be there for 80486 and later systems. Dropping support for the 80386 simplified the kernel code, and as we know, that's a very good thing. There were some practical reasons why you don't want to use OpenBSD on an 80386 system: 1) OpenBSD /requires/ a hardware FPU. The 80386 chip did not have it, you needed to add-on an 80387 Math coprocessor, and a relatively small number of 80386 machines had this. 2) There are things we just do today that were big deals back in the 80386 and before days, simple little things like compressing a file. Simply loading an 80386 system with OpenBSD was an all-day affair, due mostly to the time required to uncompress the *.tgz files! 3) IDE disks were not common on 80386 systems. You don't want to try to install OpenBSD on an MFM or ESDI drive. Even what should have been an easy retrofit was complicated by inflexible BIOSs. 4) 16M RAM was almost unheard of back then...and many of the 80386 systems of the day were using different RAM than more modern systems do, so the likelihood that you had an OpenBSD-capable 80386 was very low, and upgrading it to being OpenBSD-capable was cost-prohibitive. When this was done, no one had been sending in 80386 dmesg's for a long time. Even before then...the 80386 code spent some time broken around the 3.3 days..and only a couple people had even noticed (we didn't even realize it wasn't broke machines until we realized that several people were seeing the exact same problem!). I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? oh, most certainly. The VERY FIRST generation of non-IBM-brand 80386 (i.e., Zenith, Compaq, AST, etc.) systems were basically 80286 systems with a faster processor and almost everything else carried over from the 80286 siblings. However, by the time the second generation rolled around, the systems were starting to make use of the 80386 potential (though the OS and apps were still treating the 80386 as a really, really fast 8088, for the most part. I'm most familiar with the Zenith systems, as that's where I was at the time, but the second generation Zenith 80386 systems were capable of 20M on board (supposed to be 32M, but a bug was found with support for actual production 4M 72 pin SIMMs (which didn't even exist when the machine was first shipped!) that limited their use to only the lower four slots, so limit was 20M, though later boards fixed that and were able to use all 32M. I recall no customers complaining about this bug. :) I've got several of these second generation Zenith machines still, one of which was, according to the dmesg log, the last systems to run OpenBSD on an 80386. I also have a no-name clone board which I'd put 8x4M 30 pin SIMMs in for 32M, as well. By the time I had the resources to do this, I'd long got and retired much better machines that were capable of running OpenBSD. I'd actually be surprised if the IBM Model 70 was design limited to 16M, though it is likely there was just no physical way to put more than that in. The PS/2 MCA machines were much more advanced than the ISA-standard machines of the day, though a pain in the butt to work with and incompatable, but I'm pretty sure all 32 bits of address lines made it out to the bus. HOWEVER, the 80386sx was a non-starter for a long time: these machines only had 24 bit address buses, so it had a max of 16M, and being they were cheap machines, the actual potential of most of the hardware they were used in was 12M, 8M, or way, way less. I don't know that I have ever seen an 80387SX chip -- kinda bizarre thing, an expensive accelerator for a machine you bought because you didn't need much speed... Nick.
Re: creating FAT32 partitions?
Fred Snurd wrote: I apologize for the newbie question, the lack of line wraps is mighty annoying, too. but how is one supposed to add a FAT32 partition? The following shows where I have verified the partitioning of a USB flash drive containing two partitions through fdisk. One for OpenBSD (type A6) the rest FAT32. Yet when entering the disklabel, I am not seeing the FAT32 partition (typically partition 'i'), and disklabel doesn't allow adding it either. What is the trick for making this visible? $ sudo fdisk sd0 Disk: sd0 geometry: 124/255/63 [2002944 Sectors] Offset: 0 Signature: 0xAA55 Starting EndingLBA Info: #: id C H S - C H S [ start:size ] 0: 06 26 0 1 -123 254 63 [ 417690: 1574370 ] DOS 32MB 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 0 33 - 25 254 63 [ 32: 417658 ] OpenBSD $ sudo disklabel -E sd0 # Inside MBR partition 3: type A6 start 32 size 417658 Treating sectors 32-417690 as the OpenBSD portion of the disk. You can use the 'b' command to change this. Initial label editor (enter '?' for help at any prompt) p device: /dev/rsd0c type: SCSI disk: SCSI disk label: Flash Voyager bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 124 total sectors: 2002944 free sectors: 0 rpm: 3600 16 partitions: #size offset fstype [fsize bsize cpg] a: 417658 32 4.2BSD 2048 163841 c: 20029440 unused 0 0 a i No space left, you need to shrink a partition q No label changes. $ I assume you want to be able to access the FAT32 partition from Windows. I've found that W2k and XP both seem to require that the FAT32 partition be physically first on the disk. Zero your drive (dd if=/dev/zero of=/dev/rsdXc count=200. Replace the X as appropriate, of course), then start over. Create a FAT partition first, then an OpenBSD partition, then disklabel. Since both partitions will be there when disklabel is first invoked, it will give you what you are after automatically. IF you want the OpenBSD partition to be bootable, set that in OpenBSD's fdisk, too. Windows really gets unhappy when it sees multiple partitions on removable media, so it won't help you at all. Once the FAT partition is created in OpenBSD, however, it can (and probably should be) formatted in Windows. Windows does that ok, as long as it is the first partition on the disk. Nick.
Re: Optimising OpenBSD
Matthew Smith wrote: Quoth Rod Whitworth at 2008-04-09 08:04... Matthew, you are pretty new here so I'll be kind. Read http://www.openbsd.org/faq/faq5.html#Why For this, I apologise. I am currently in the situation that I don't know where to look for what. I might try writing a OpenBSD for Linux escapees somewhere down the track, because that's what I really need. http://www.openbsd.org/faq/faq9.html :) Don't re-invent, improve. :) (It used to be called migrating from Linux or something like that, but there are a lot of other non-Linux Unixes that people might be coming from). Also Search The Fine Archives I now discover that they are under a different domain - which is why the site search wasn't pulling up much. I must pull out my copy of 'Google Hacks' and see if there is a way that an aggregated site search can be done that pulls in the list archives as well. there's a bunch of archives out there, each has their own search functions, and that's really a good thing. Very often, when looking for something and one search engine strikes out, another will pop up the answer for you. As wonderful as Google is, it isn't the Final Word on knowledge retrieval. Often, when the best answer is don't, search engines do a much better job of coming up with more long- winded and incorrect answers. The GENERIC kernel has been compiled with all the right flags. The article you cite was never good advice and furthermore it is going on 8 years old. It's going to take me a while to get used to having a kernel that I don't HAVE to touch - not that I'm complaining! wait until you get used to working on your projects rather than tweaking your OS... It will raise your expectations on everything. Nick.
Re: install42.iso hangs....any ideas?
Redirected from ports@ to [EMAIL PROTECTED] An explanation of what lead you to post it to ports@ would be interesting, second one of those in a couple days, starting to sound like something is unclear somewhere. [EMAIL PROTECTED] wrote: Hey All, I'm trying to install OpenBSD 4.2 and have created an ISO image using ISORecorder for XP. The creation of the image on the CD completed with no errors. When I boot from the CD to install...the script begins and I get some white text on blue background...but then the install stops at the following message: cd0 at scsibus0 targ 1 lun 0: HL-DT_ST, DVDRAM GSA-E50L, NE01 SCSI0 5/cdrom removalable any ideas would be greatly appreciated. Thanks in advance. You have given us almost nothing to go on. however... I notice you have a DVDRAM there. I've only had one of those, and I pulled it out of the machine it was in because it seemed to be defective. I could be wrong..it may be that only two people have ever tried to install OpenBSD on a machine with a DVDRAM drive into OpenBSD, you and me. Or maybe you and I are the only owners of defective DVDRAM drives. SO, first thing I'd try is to pull the DVDRAM drive out and use a CD or DVD drive, see if that works better. If so, let us know, I'll look into my defective DVDRAM drive more. If not, tell us SOMETHING about your computer, or (much) better yet, just put a serial console on it and snag the boot output and let us look. Or type out a lot more of what you see on the screen. Put the digicam down, I'm not looking. Nick.
Re: Logging failed SSH users and the passwords they typed
Sam Fourman Jr. wrote: Is there a way to login the passwords that were used in the bruteforce attack? I am siting trying to come up with a good reason why you would give a damn what passwords they tried? Actually, I have a reason why a list of PWs that the brute-force apps use would be interesting: to show people how bad their PWs typically are. Ok, everyone, pick a creative password for the all-powerful root account. Now...let's look at a brute force list, and see how original you aren't. Wow, look, five of you picked 'iamgod' for your root PW, and here it is on the brute-force list! However, a much better way to this would be simply snag a copy of the program. (one way, perhaps: honeypot machine, with a firewall that cuts off all net connections after it makes, say, ten outgoing ssh connections in a minute). Nick.
Re: Problems reading CD during install
Wade, Daniel wrote: The installer can't mount the cd to read the files from it. I'm using a recent install43.iso. I'll try to use ftp for the install sets, but it would be nice if I could do it all from the CD. Here is what I get if I try to mount the CD cd0(ahci0:1:0): Check Condition (error 0x70) on opcode 0x8 SENSE KEY: Illegal Request cd0(ahci0:1:0): Check Condition (error 0x70) on opcode 0x8 SENSE KEY: Illegal Request cd0(ahci0:1:0): Check Condition (error 0x70) on opcode 0x8 SENSE KEY: Illegal Request My first reaction: Looks like a bad media, a bad drive, or a bad burner used to create the disk. Do you have any reason to believe otherwise? Looks like a SATA DVD ROM drive attached to an ahci controller, which is kinda new stuff (at least for me! :), so I'm not going to say there ISN'T an OpenBSD problem, at least until I get some better HW in production here to try it, but I'd certainly start with the obvious. Nick.
Re: Upgrade 4.1-4.2-4.3
Damon McMahon wrote: Greetings, Can anyone enlighten me as to why DHCP clients are no longer retrieving their domain name from my OpenBSD DHCP/DNS server which I recently upgraded from 4.1 to 4.3 via 4.2? DHCP and DNS seems to functioning normally otherwise... Any advice appreciated (as always), Damon it is your DHCP /SERVER/ machine which was upgraded, not the clients (I say this because I started out the note thinking it was a client that was upgraded and no longer fetching from the DHCP server) Show us what is happening, what you expected to happen, why you expected etc., rather than diagnosing the problem for us. :) Contents of dhcpd.conf would be interesting, as well as any message in /var/log/daemon regarding dhcpd. More details on what you did for the upgrade might also be interesting, as a fair number of people (including me) have upgraded their DHCP servers from 4.1 (and before) to 4.2 to 4.3 without reporting this problem, so my guess at this point is either something strange was done during the upgrade process or the problem is not directly related to the upgrade. There isn't much to dhcpd: dhcpd.conf and /usr/sbin/dhcpd are about it. Some other files launch it, but if it is running, it will be mostly those two files. dhcpd was replaced in the upgrade process, dhcpd.conf /should/ be untouched. Looking at the dates on those files will tell a few things, I suspect. Nick.
Re: OpenBSD 4.3 released May 1, 2008
Rich Healey wrote: ... I've been finding it a bit slow, but nice enough, bnut with the release realeased as it were, I should now rebuild the kernel/userland to incorporate the changes? Sorry if this is in the FAQ somewhere, I've been unable to find it. http://www.openbsd.org/faq/faq5.html Nick.
Re: Double 4-port NIC happiness
Stefek Zaba wrote: I've just brought 3.8-RELEASE up on an oldie-but-goody machine - ASUS P3B-F - into which a total of 10 NICs have been thrust. 4 are on an Adaptec AHA-62044, whose NICs get named sf0 .. sf3 (note that as per the i386 info at http://www.openbsd.org/i386.html, these are recognised by the GENERIC kernel but not by the one on the boot CD-ROM); 4 more are on a D-LINK DFE 570TX, whose NICs get named dc0 .. dc3. (That's a minor documentation bug in the i386 web page - it says the 570TX NICs will get driven by the de(4) driver, but it's the dc(4) which does the job in point of fact. The dc(4) and de(4) man pages get this right). That's a whoops. Once, that was true. That was..uh..long ago. Fixed. No massive stress tests done yet, but basic ping and nc of 10MB in sensible barely-over-a-second time suggests basic functionality working well. (Actual performance for nc sending a 10MB testfile is about 0.98 seconds on the dc ports of the 570TX, and more like 1.4 seconds on the sf ports on the Adaptec; both going through one otherwise unloaded switch to a Windows box.) Hope that's encouraging/useful to anyone else setting up a multizone setup with an OpenBSD box as the spider / hydra / Fat Controller / piggy-in-the-middle / Network Policy Device / whatever you want to call it... dmesg sent to openbsd.org's 'dmesg' address, not appended here; shout if you feel you must see it. For a test, I once ... well, I'll just jump right to the punch line: dc19 at pci7 dev 7 function 0 DEC 21142/3 rev 0x41: irq 10, address 00:60:f5:08:54:27 lxtphy11 at dc19 phy 1: LXT971 10/100 media interface, rev. 1 Hardest part was finding which port was which so I could install the OS on it. :) Later, I found I had a six-PCI slot machine, but I never got around to repeating the test... In case anyone is wondering, that was 3.6-beta, from Aug. 2004. Nick.
Re: updating the kernel to CURRENT
Spruell, Darren-Perot wrote: From: [EMAIL PROTECTED] When updating the kernel to CURRENT (in the case, 3.9), do I have to update ports and already installed packages? I think the OP is using words in non-standard ways. The kernel is one file, /bsd. Ports and packages are the add-on stuff. Missing from the question is the userland -- the utilities and such that makes OpenBSD (or any OS) go. OpenBSD is the combination of the userland and kernel. I'm going to guess that's what the OP meant by kernel. Packages and ports should stay in sync with the rest of the userland. The OS should stay in synch with the kernel since there are important dependencies on kernel interfaces. So I would guess if you want to run CURRENT kernel, you will be best served running CURRENT userland as well, and subsequently ports will need to follow CURRENT as well. Maybe you should consider a snapshot. (hoping I'm not misleading on this...) Technically, you are somewhat wrong, practically, you are mostly correct. :) The kernel and userland must be kept in sync for a fully functioning system (though a brief new kernel, old userland usually works for the middle of the remote upgrade process). Newly installed packages must match the rest of the OS. Packages built from ports must be from a ports tree that matches the OS. HOWEVER... as the upgrade process does not remove the old library files, old packages will (usually) continue to run on an UPGRADED system (however, don't try to install an old package on a newly-installed (not upgraded) system). So, technically, you are wrong, you could keep using old ports on new systems. Practically, you are right. Try to live with that concept, you run into at least a couple issues: * Dependancies: new packages may be dependent upon newer versions of packages you already have installed. Might as well upgrade them on your schedule. * Security: third party software seems to have a non-trivial rate of security issues. You probably want to keep it up to date. You will probably have more reason to worry about updating the apps than the OS itself. As long as you are updating the system, just update the ports and packages. And yes, always use a snapshot (or release, or other prepared binary). Compiling is for customizing (which you probably don't need to do) or for -stable. Upgrading is done using binaries. Nick.
Re: Utilisation of free memory as disc cache: tweaking is required?
On Mon, Feb 20, 2006 at 02:49:01PM +, Constantine A. Murenin wrote: ... Although the documentation says that it defaults to 5%, it actually seems to default to 10% on amd64, alpha, hppa and hppa64. Why it's not made to default to 10% on i386 too if enough memory is available? because 5% more of 24M or 16M makes a big difference, perhaps? yes, we care about OpenBSD working well on Really Small Machines. Also, it looks like Filesystem Buffer was in the FAQ in 2003-05-01 (http://www.se.openbsd.org/faq/faq11.html), stating option BUFCACHEPERCENT=30 for config(8), but now it no longer appears in today's version (http://www.openbsd.org/faq/faq11.html). Is there a reason for that? Yes, because people who thought they knew more than the programmers kept twisting knobs to the max and expected things to ALWAYS be better, and we spent too much time reading and answering IT BROKE! questions. This way, we can laugh at people who break their systems in clear conscience. Come on, think. Do you really think OpenBSD developers LIKE to have things go slower than they could Just Because they like to watch people twist knobs? Do you think if they felt there was a better OVER ALL value, they wouldn't set it? Not all the world shares your design criteria. ... True, I was making a generalisation to mean any modern PC/mac. :-) It was almost a year ago that 512MB became the minimum even for most entry models. How about this: Consider i386 a legacy platform. All modern stuff is amd64 compatable, anyway, right? Wow, look at that. amd64 (which probably will never be seen with less than 256M due to the memory design) has a default of 10%. The developers are ahead of you on that. :) Nick.
Re: SCSI tape drive hanging
Marcus Barczak wrote: ... -- dmesg output -- ahc0 at pci0 dev 9 function 0 Adaptec AHA-2940U rev 0x00: irq 11 scsibus2 at ahc0: 16 targets st0 at scsibus2 targ 4 lun 0: HP, C1537A, L706 SCSI2 1/sequential removable st0: density code 0x8c, variable blocks, write-enabled Has anyone seen this problem before or have any suggestions as to how I may fix it? wow, never seen a dmesg like that before. No wonder it doesn't work, most of your computer is missing! Alternate response: If you know what parts of a dmesg we need to fix your problem, you obviously can fix your own problem. Nick.
Re: Pf questions for larger implementation
Steve D. wrote: Hi, I'm setting up a gateway (1.7 Ghz machine with 1 Gig of ram) for 700+ users using pf with NAT and BINAT's (90% NAT).I would like to know if anyone has any recommendations on tweaking the runtime options in PF. This box will pretty much just be handling the natting with a bare minimum of filtering, just enough to keep the box secure. Yes: DON'T TOUCH ANYTHING UNTIL YOU KNOW WHAT THE GOAL IS. Apparently, there are some OSs people are used to that ship in a nearly useless state, at least judging by the queries like this. With OpenBSD, you aren't supposed to have to tweak things..it should Just Work. See if you run into a problem. Don't start twisting knobs until you see if there is a reason to do so, and until you know what the desired outcome is. The defaults are set pretty darned well to start with -- you are much more likely to break something by tweaking than you are to improve anything. For comparison: we have ~850 people, hiding behind a CARP'd pair of machines -- primary is a Celeron 600, 384M RAM. Failover box is a PIII-750, 512M RAM, in an otherwise identical box. Hooked to a 45Mbps DS3. We aren't exercising the system much at this point (neither the box nor the DS3). I suspect some day, we'll start seeing some limits hit on this thing, we'll worry about it then...assuming these boxes haven't died of old age by the time that happens. :) Nick.
Re: In chroot: /dev/stdin: Device not configured
On Fri, Feb 24, 2006 at 10:38:13PM +0100, Matthias Kilian wrote: Hi, can anyone tell me wtf I'm missing in the commands below? # mkdir foo # cd foo # mkdir bin dev # cp -p /bin/cat bin # cd dev # /dev/MAKEDEV std # cd .. # chroot . /bin/cat /dev/stdin cat: /dev/stdin: Device not configured The reason I ask is that I need to run tar -czf within a chroot environment, but gzip(1) tries to open /dev/stdin and fails (as the contrived invocation of cat(1) in the example above). ~ $ mount /dev/wd0a on / type ffs (local, softdep) /dev/wd0h on /home type ffs (local, nodev, nosuid, softdep) /dev/wd0e on /tmp type ffs (local, nodev, nosuid, softdep) /dev/wd0d on /usr type ffs (local, nodev, softdep) /dev/wd0f on /var type ffs (local, nodev, nosuid, softdep) /dev/wd0o on /open type ffs (local, softdep) Any possibility your FSs are mounted like mine are? There are only two places above where I could drop a /dev directory, and that would be wd0a and wd0o... Nick.
Re: Dependancies with make search key=
Harry Putnam wrote: ... So shouldn't `X' appear as a dependancy? Or whatever package supplies X? No. X is not a package. It is a file set, not part of the ports tree. Assuming I need to backup and get the installation package *x*.tgz. I'm not sure how to proceed. http://www.openbsd.org/faq/faq4.html#AddFileSet I've installed from a recent snapshot and then built from src to follow current. So what is the normal way to backup and get something basic like X? Get the X files from a snapshot, install those as above. Or, boot an install media, install all file sets. Nick.
Re: Nothing in FAQ about X ?
Harry Putnam wrote: I haven't seen any section of FAQ devoted to setting up X. Is it supposed to just work after installing the base tgz files? it would be nice. But they have not reached that goal yet, at least on some very popular platforms. Or maybe I'm just blindly overlooking the section? The part about building X doesn't have anything to say about setting it up. Is it covered somewhere else? see /usr/X11R6/README on your installed system for some tips on getting X up and running. Yes, the FAQ is sadly deficient on setting up and using X at the moment. Hopefully, that will be changing in the future. Nick.
Re: make build error on 3.9 (-current) i386
Reza Muhammad wrote: Hi guys, I was just updating my source tree through cvsup, and I've been following -current for a while. There hadn't been any problems before. But today, make build returned errors. ... Can anyone help me with it? What seems to be missing from your process is the words, I downloaded and installed the most recent snapshot before I started the 'make build' Always Start From A Snapshot. Usually, you can stop right there, too. There is very little reason to build from source after installing a snapshot. Nick.
Re: Sun Ultra 1 and Ultra 5
On Fri, Mar 03, 2006 at 12:51:31PM -0300, Gustavo Rios wrote: Hey folks, i have an sun workstation in hand and had never had a previous experience with sun hardare before. I would like redirect console to serial port. These machine are very old, and hardware documentation has been lost. It has a serial port, doesn't it? already covered by someone else, though I'll put in a plug for http://www.openbsd.org/faq/faq7.html#SerCon I was trying to get X working, but no lucky. Does anybody have openbsd 3.8 running on such hardware? Could you send your xorg.conf file? Read /usr/X11R6/README on your installed system. Take the sample xorg.conf file as a starting point, BUT DON'T EXPECT IT TO WORK. Now, edit it as indicated by the rest of the README file for your particular system. You will be looking at your dmesg several times. It should be pretty straight forwardr, but you WILL NOT be able to just use the sample config. (well, I can't say that's true on everything, there may be some system where the sample config Just Works, but the U5 is not it. Not sure about the U1. Just treat the sample as a starting point, a framework where you hang your system's details). Nick.
Re: OpenBSD has bad security
Damien Miller wrote: Please, This troll is several years old, let it go already. Not only that, the number of times you guys repeated the links will raise Google's interest (and that site's profile) the next time it digs through a mail archive. I'm sure the author of that site will thank you guys. Nick.
Re: OptiPlex GX620n - OpenBSD
Mark Pecaut wrote: On 3/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - Are they suitable to run OpenBSD on them. Here is a dmesg from a GX620. I can report that everything works quite well, including X. You prompted me to go back and take another shot at X on a Optiplex 620. I've (again) had no luck getting it to work with the standard, on-board video. What did you do to configure X on it? (I didn't see an extra video card in your dmesg). I can report that with a Pentium-D chip in them, a recent OpenBSD/i386 snapshot will use both cores on an O620 (I should test OpenBSD/amd64, I guess). SATA support seems to work pretty well, though I haven't really put it through its paces much with OpenBSD yet. The Minitower case will take an Accusys box nicely, though you have to leave off (or cut) the plastic bezel (it actually doesn't look all bad off) and you will not get an internal CD. Spend the extra $9 to get the PS/2 and second serial port adapter...even if you don't care now, you will wish you had it at SOME time in the future, and the $9 is cheaper than the USB converters that don't work as well. In spite of the case size, there are only two PCI slots in the minitower case, which is the same number as the smaller desktop case (and if you need that PS/2 adapter, you lost one of them...or the PCI Express slot). Nick.
Re: crash: savecore - saves core dump every day?
Stefan Drexleri wrote: Hi, from the faq: Upon reboot, savecore(8)will attempt to save the contents of the swap partition to a file in /var/crash savecore would be called by /etc/rc. So which criterias must be fulfilled to make core dump upon reboot? Does savecore look for special file names at special places? Who makes the rule? I'm not entirely sure I understand your question, the subject and the body of your message don't seem to be completely related. However, I think you may find the answers to your questions in man 8 crash Third paragraph (more or less, depending what one counts) tells what conditions cause the in-RAM image to be written to disk in the swap partition. If that happens, an attempt will be made to dump it to physical disk upon reboot. Note that on a modern system, /var is very often not large enough to hold a core dump. If this is something you care about, you will need to deal with it accordingly. (aren't we all glad that attachments are stripped from misc@ postings now? Hi, here's my 2G core dump. why did it happen?) Nick.
Re: crash: savecore - saves core dump every day?
Stefan Drexleri wrote: 2006/3/10, Nick Holland [EMAIL PROTECTED]: I'm not entirely sure I understand your question, the subject and the body of your message don't seem to be completely related. However, I think you may find the answers to your questions in man 8 crash Third paragraph (more or less, depending what one counts) tells what conditions cause the in-RAM image to be written to disk in the swap partition. If that happens, an attempt will be made to dump it to physical disk upon reboot. Will try to ask more clearly: How does savecore work in sense of detecting that condition to save core dump to swap space has been accomplished? Does it get message from kernel (which IPC technique?) or does it something like polling for special event (eg. newly created file)? Savecore is running after a reboot. It isn't getting a message from the now dead kernel through traditional techniques. After a kernel panic, it is generally not a great idea to write a normal file to a normal file system. As man 8 savecore indicates, it looks at the swap space to see if it looks like a valid core dump. If so, it dumps to disk. If you need more info on how it determines that, I'd suggest a read of the source code. If you really need that kind of information, you will probably have no problem with the source code (pretty small and contained, too -- about 16k in size). I suspect there is a question you are trying not to ask. What is prompting your questions? Are you having a problem? Trying to accomplish something? Nick.
Re: OpenBSD 3.8 ports quality?
Ramiro Aceves wrote: ... Yes, WM also works fine here. But again, it is not a solution. GNOME should not be released in such buggy state. I don't follow your logic here. Ok, let's say GNOME was removed from ports by your suggestion. In that case, you WOULD need to find another solution. In the mean time, no one would be attempting to isolate and repair problems with GNOME, which means nothing would get better, and you would still have to find another solution. From your original post: Do the porters check that the ports work before a release? uh...yes. But...YOU also have to be involved. Don't wait for a new release, then whine that it is broken. TOO LATE! You missed your chance. Quit letting other people do your testing and work, and then whining about the results. I find it entertaining (in a morbid sort of way) when people come from Linux when they realize some of the same things that drove them to Linux in the first place take place there, too. So then they go hunting around for an alternative, and then they try to make their alternative look just like what they gave up on. *sigh* Nick.
Re: Install defaults
Bruno Carnazzi wrote: Hi all, Why not use soft update as a default for created file system on install ? It seems to be a good practice, no ? Well...assuming you: * Have some extra RAM to spare. * Don't mind added complexity * aren't running on a Sun4c sure, soft updates are a fine idea for most people to use on most of their systems. However, no one's system is broke because of not having softdeps on. No one's system will crash because of no softdeps. Softdeps is an added complexity. You don't add complexity and get a more solid result. IF you always want softdeps on the systems you work with, it is two lines of shell script in a siteXX.tgz file (or less if you know what you are doing, or more if you know of some edge cases I didn't think of). However, I don't think it will be defaulting to on anytime in the next release (and probably not the one after that). :) Nick.
Re: kernel panic
Joe Advisor wrote: ... Can anybody provide any insight for me as to what I might be doing wrong? I am not sure where to be even begin to debug. Thanks in advance. http://www.openbsd.org/faq/faq2.html#Bugs Nick.
Re: sudo nopasswd rm
Marco Fretz wrote: hello i've got a little problem. i have to remove some files in a shell script that or not owned or writable by the user the shell script runs. is there a way to give this user write access only to the files needed to remove by the shell script (with sudo nopasswd)? With sudo, you can spell out very explicit command lines which can be stuck in scripts, but variations of the commands are not. For example: dvd ALL= NOPASSWD: /sbin/mount /drv0,/sbin/mount /drv1, /sbin/umount /drv0,/sbin/umount /drv1 So, yes, I suspect you can use sudo to accomplish your desired deletion, without granting write access to those files to the user in question. HOWEVER, be careful of undesired side effects -- holes you leave that a malicious user could use to their advantage. And don't assume my line above is very correct, I'm not a sudo expert and I can't recall how carefully I tested that. :) Nick.
Re: Problems with X in OpenBSD (3.9) -current with LCD WideScreen Monitor
Francisco Valladolid wrote: Hi folks. Recently I bougth a new LCD display, it is a ViewSonic 19 WideScreen, i have proble with xorg in -current, for correct display mode only 1024x768 is displayed. The X windows is so wrong. Some have some tips about the X under xorg. This monitor work fine in other OS running xfree86. Unfortunately, you have provided no hard information, so you will get no hard answers. In short, however, you need to hand-tweak your /etc/X11/xorg.conf file, apparently. Under 'Section Monitor', make sure you have accurate HorizSync and VertRefresh lines. Under 'Section Screen', add/alter a couple lines: Default Depth 24 and under 'SubSection Display' add: Modes 1280x1024 (correct the Depth and Modes to the values you want, of course). You may be in business. You may not be, if your video card or X driver is incapable of driving your monitor at the desired depth and resolution, or if there is some other quirk in your hardware we can't see. Or if I'm forgetting something, which is possible. :) You can also try to use DDC, apparently it was default for 3.8, now for 3.9, DDC is disabled by default, and I'm glad (worked great when it worked, sucked big time when it didn't). Nick.
Re: 3ware 9500 and large drive issues
Vincent Meanie wrote: I am attempting to use a 3ware 9500s, the problem is how it displays the 8 disks as one large 2.3tb disk. There are documented issues with disks over 1tb, will partitioning under this limit prevent further issues, or will I have to look forward to errors in the future from the filesystem? http://www.openbsd.org/faq/faq14.html#LargeDrive says it pretty clear, I hope. One large 2.3 TB disk is unlikely to work. Granted 3.9 will be out soon, but I am just going off of the information 3.9 won't change this. 4.0 probably won't. Work is being done, but slowly and carefully, just as I'm sure you would want something so critical to be done. No one wants to lose data on their 256M flash device because of a sloppy addition of multi-T support. There are some kinds of work that are just plain terrifying to do, file systems are way up there, if not top of the list. I have at hand. I attempted to use an unsupported card that could present sized luns to the OS, but it was an unreliable production sample, and the 3ware card is what I have. ...speaking of unreliable... 3ware isn't anyone's favorite around here... Nick.
Re: Theo opinion of Plan 9
Andris Delfino wrote: I would like to know what does Theo think about Plan 9. Just curiosity, :P. Not curious enough to Google for it? First page of hits for 'deraadt plan 9' gets you some interesting reading. You get more interesting stuff if you play with the spaces in various combinations: de Raadt and Plan9. Nick.
Re: Questions about 3.9 Installation on External USB Disk
Dave Feustel wrote: I got my 3.9 Cdrom set yesterday and today started installing it on an external usb disk so as not to wipe out my existing 3.8 setup. When I got to the disk partition, I erased the existing 'a' partition (dos) and created a new bsd 'a' partition. The partition had a default offset of 32 which looked odd to me, so I changed it to 64 and sized it to 1G. Then I created a 'b' partition. Again, the default offset was 32. That looked even odder to me, so I aborted the installation. A dmesg of the 3.8 boot (with external usb drive attached) follows at the end of this post. So is it possible to install 3.9 on an external usb drive and then to boot from that drive? Is the default 32 offset for a and b partitions on the usb drive correct? (I don't think so, but I am asking anyways since I have not used usb hard drives with OpenBSD before). The point is not a 32 block or 63 block offset, but rather, a ONE TRACK offset for the first partition on i386 and some other systems. This leaves room for the master boot record (MBR) which is in sector 0. Your dmesg showed this: sd0 at scsibus2 targ 1 lun 0: WDC WD60, 0UE-22HCT0, SCSI0 0/direct fixed sd0: 57231MB, 57231 cyl, 64 head, 32 sec, 512 bytes/sec, 117210240 sec total so the layout for this disk connected this way is 32 sectors per track so YES, it should be starting at 32. If you override this, you left a 32 sector gap at the beginning of the disk, and disklabel will start looking for space at the start of the disk, so again, it will offer you that same starting address. Most modern IDE and SATA disks will use a track size of 63 sectors, so yes, that's your offset. HOWEVER, if you were to bring OpenBSD up on an old MFM drive, you would be looking at 17 sectors per track, so THAT would be your offset. Your disklabel offsets should match your fdisk offsets, though if you answered yes to the use entire disk option, that was done for you in the install program. Can this all work? Certainly, assuming a machine that boots off an external USB HD, but most new machines can. You can even set up the disk with funny offsets if you take full responsibility for doing the math accurately. :) I would recommend disconnecting the normal disk from the machine for testing, however. Keeps life easier... Nick. Nick.
Re: OpenBSD 3.9 stable from cvs
On Wed, Apr 12, 2006 at 01:03:58PM +0200, Piotrek Kapczuk wrote: Hi I have a new server to deploy and I don't want to wait unlit official release. So I'd like to compile 3.9 stable from source and I've faced a problem. I have a machine which runs 3.8-stable I've wiped out /usr/src then, as http://www.openbsd.org/faq/faq5.html says I did No, you completely ignored the Install or upgrade to closest available binary step. You can't do that. If you had started from a 3.9-beta, you might have got lucky. But jumping from 3.8 to 3.9 is NOT an easy process, and is completely unsupported. This looks like it will be a particularly difficult jump to make this release (though, as I recall, that's been true for a LOT of releases lately). You can't just download a new release's source and build on an old release. Further, what happens if there is a critical security issue in 3.9-rel before 3.9 is officially released? -stable commits do NOT get made until 3.9 is official (hint: sendmail bug). Your choices: 1) Start with 3.8, and upgrade to 3.9 later (actually, pretty easy). 2) start with 3.9-current, and then jump to 4.0-stable in about seven months or so, when it becomes available. This could be either very easy or a pain in the butt, depending on how many additional packages you end up installing after first install. Nick.
Re: OpenBSD 3.9 stable from cvs
Ted Unangst wrote: On 4/12/06, Geof Crowl [EMAIL PROTECTED] wrote: Unless I am reading something wrong, isn't this: If you had started from a 3.9-beta, you might have got lucky. But jumping from 3.8 to 3.9 is NOT an easy process, and is completely unsupported. [building 3.9 source on 3.8] and this: 1) Start with 3.8, and upgrade to 3.9 later (actually, pretty easy). [install 3.9 binaries] totally contradictory? yeah, except i think what nick was getting at was that upgrading via source is going to be bad, upgrading via sets is easy. yeah, and one of these days, Nick will learn what everyone else has long figured out: don't give long, detailed answers, as someone will try to pick it apart and take it out of context, analyzing the text as if it were a fine novel, rather than a quick I need a break from helping people at work, let's see if I can help someone on the mail list posting. Yes: Upgrading from source = difficult, if even possible by ordinary people, and certainly not supported by developers. Upgrading by binaries = easy. Nick.
Re: OpenBSD 3.9 stable from cvs
Piotrek Kapczuk wrote: ... It was fixed. First time I've seen it happen before official release though. Well, security problems just before releases are not that common. ;-) If I understand this right. This commit is in OPENBSD_3_9_BASE in cvs but it's not on CD's. Isn't it ? n... Anyway, to answer the original question: download a src.tgz from somewhere, the 3.8 version from your local mirror should do, and cvs up it to OPENBSD_3_9. Instead of this, can I checkout full src with tag OPENBSD_3_9_BASE ? The result should be the same. N... http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendmail/libsm/fflush.c OPENBSD_3_9_BASE is tagged...and that's it. (well..usually. I'm sure there's some exception somewhere...) The patches were put into OPENBSD_3_9 (a.k.a., stable), it turns out. That's not at all usual, and rather surprised me. Apparently, this is a Special Case. Nick.
Re: OpenBSD 3.9 stable from cvs
On Fri, Apr 14, 2006 at 01:16:17PM +0200, Srebrenko Sehic wrote: On 4/14/06, Nick Holland [EMAIL PROTECTED] wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendmail/libsm/fflush.c OPENBSD_3_9_BASE is tagged...and that's it. (well..usually. I'm sure there's some exception somewhere...) The patches were put into OPENBSD_3_9 (a.k.a., stable), it turns out. That's not at all usual, and rather surprised me. Apparently, this is a Special Case. No. All patches past the _BASE tag always go into -STABLE. In this case, correctly into OPENBSD_3_9. This is not special AFAIK. *sigh* HELLO... Topic is WHEN they go in. 3.9 is not official yet. This patch set went into -stable already. That *is* unusual. Nick.
Re: SMP support for Sun E450 Sparc64?
David B. wrote: Hi, are there any plans to release a bsd.mp version for sparc64? My box currently can only use cpu0; I have 4 processors, and it seems a shame to waste all of that power. thanks There is, of course, desire to support SMP on mvme88k, sparc, sparc64, Alpha, and just about anything else it could be supported on. By plans, however, I suspect you want some kind of time schedule. No, there is none. When code is ready for testing, announcements will be made. After many crashes and data loss events, it will be ready for use. People who are making plans based on this are foolish. You can't make plans on vaporware, whether it is a commercial or free product. Until it exists, you can't use it. There is no effective way to accurately predict when it will happen. Once SMP is available on these machines, you will discover that your E450 is still a fraction of the speed and many times the power consumption of a modern computer. So: If you need more performance, get a faster computer. If you are satisfied with the performance you get now, seeing all four processors in the dmesg won't change your life much. Sure, there is a wow, that's cool factor, but beware of how much that that's cool costs you in electricity. Nick.
Re: LZMA and the Install Sets?
curiosity got the best of me here. Found I had a machine with several major compression programs on it, and while this tired argument isn't worth this, I found it the idea of a comparison interesting, so I thought I'd share... [EMAIL PROTECTED] wrote: you obviously missed the part about the preposterously slow compression times. Well.. You missed my point. I know you don`t crosscompile but you can compress all Archives on a stronger Computer. So a VAX isn`t the best hardware to start with LZMA compressing. Yes.. ick. no. Something else: You compress install Sets for CDs mostly just once but they get decompressed many times. :) depends. I build sets often on slow machines. More often than I install 'em. In OpenBSD, I don't get much of a vote, but I get more than you. :) And if somebody wanna change these install Sets he could use another Box for the compression. But I don4t think there`s anybody out there who just owns a 486 and a VAX. As a NATIVE BUILDING OS, we assume you have only one machine. OpenBSD does not need a second machine to build, and hopefully will not. When you need a second machine, you might as well be cross building. Heck, you ARE cross-building. You would save a lot Bandwith and also storage space on the CDs. Bandwidth is cheap. If you can cut the time to download from 30 minutes to 3 minutes, you have accomplished something. Changing it from 30 minutes to 15 minutes, I don't think that changes a thing. You will still get up and go do something else (or you need a job). Far less painful to all than changing compression would probably be DVD media. If you are going to inconvience some people, heck, at least give them a REAL benefit, not 20% more. E.g. the src gets compressed very well and the decompression isn`t that much slower. Oh? Where are your numbers? Being you have brought this topic up in the past, I'm going to show you some real numbers. Took comp39.tgz for i386 and ran these tests on a slow amd64 system (yeah, choice of an i386 file for running the test on an amd64 is kinda strange, but it really doesn't matter much). Unzipped it, and copied it several times, ran these compressions and watched RAM usage using top: ~/comptest $ time bzip2 comp39b.tar 1m7.03s real 0m55.97s user 0m0.43s system (maximum RAM used: around 8M) ~/comptest $ time rzip comp39c.tar 0m36.42s real 0m26.62s user 0m1.14s system (maximum RAM used: around 118M) ~/comptest $ time lzma e comp39d.tar comp39d.tar.lz 7m5.59s real 6m54.79s user 0m0.59s system (maximum RAM used: around 80M, I think) ~/comptest $ time gzip -9 comp39e.tar 1m16.87s real 1m15.28s user 0m0.42s system (maximum RAM used: around 700k) Results: ~/comptest $ ls -l comp* -rw-r--r-- 1 njholland njholland 75288260 Apr 17 19:20 comp39.tgz -rw-r--r-- 1 njholland njholland 218347520 Apr 17 19:25 comp39a.tar -rw-r--r-- 1 njholland njholland 50369737 Apr 17 19:26 comp39b.tar.bz2 -rw-r--r-- 1 njholland njholland 25860279 Apr 17 19:29 comp39c.tar.rz -rw-r--r-- 1 njholland njholland 20849017 Apr 17 19:38 comp39d.tar.lz -rw-r--r-- 1 njholland njholland 75288272 Apr 17 19:45 comp39e.tar.gz Comments: rzip and lzma turned in some good numbers (REALLY good numbers), but the RAM required was absolutely absurd (at least, for this application). Your average mac68k or 486 would be in swap hell for a week, and many good firewall systems would take many times as long to load. I'm rather amazed that rzip was such a screamer in compression speed for this app, I've never seen it outrun anything before. I repeated the test, btw, consistent. bzip2 seems to be an answer in search of a problem. It does things a little better for a big price. gzip is the only one with a RAM footprint that is acceptable for a multi-platform OS. Really, the amount of change in our lives that switching to a better compressor would make is not worth the difference here. HOWEVER, I did spot one interesting thing...first time I ran the gzip test, I got a funny answer: ~/comptest $ time gzip comp39e.tar 0m29.39s real 0m26.70s user 0m0.44s system [EMAIL PROTECTED] ~/comptest $ ls -l comp39 ~/comptest $ ls -l comp39* -rw-r--r-- 1 njholland njholland 75288260 Apr 17 19:20 comp39.tgz ... -rw-r--r-- 1 njholland njholland 75990958 Apr 17 19:26 comp39e.tar.gz Since the size didn't line up, I figured that was probably due the wrong compression factor specified -- apparently, the file sets are built with a -9. Note that in my humble opinion, the -9 on gzip that tar and/or the build process uses is Just Not Worth It -- for a tiny improvement in file size, you wait well over twice as long. You think that doesn't matter? Re-pack a mac68k build some day. ok, one last nail: ~ $ ls -l `which rzip` `which lzma` `which bzip2` `which gzip` -r-xr-xr-x 6 root bin 29248 Feb
Re: dual port ethernet (DP83816-based)
[EMAIL PROTECTED] wrote: I would like to add a DMZ for a webserver and need to add another ethernet port. My 3.5- based box upgrade. has limited card space, so I thought of using a dual port card to add the 3rd ethernet port. I have access to a NS DP83816-based dual port card. I see that I would have to update my OS version for the DP83816 chip, which is not a problem. However, I see that the compatible cards are limited to 3 Netgear FA3xx. usually, what matters is the chips on the card, not the sticker on the box. You are almost always better off going by the chips than the sticker on the box. First, are there particular issues with multi-port cards and OpenBSD? nope. normally, they are just a PCI-PCI bridge and a bunch of NICs. WELL...some older machines don't seem to like PCI-PCI bridges on their expansion bus. However, that's not an OpenBSD issue...they don't seem to boot ANY OS when you stuff these cards into them. Second, outside of just trying the card, is there anything to review/prepare for? stick it in, it will probably work just fine. The chip you have is no model of quality or efficiency, but it will work for many apps. probably. Only way to find out is to try it. Nick.
Re: upgrade halted
Jasper Bal wrote: After nummerous advices on the list that I should upgrade, I decided to try remote upgrading. there is reason we suggest practicing on an identical LOCAL box first! At the folowing step: Reboot on the new kernel: This might be a tempting step to skip, but it should be done now, as usually, the new kernel will run old userland apps (such as the soon to be important reboot!), but often a new userland will NOT work on the old kernel. something went wrong. I issued a reboot. And when the system came back up, SSH didn't recognize any of my passwords. All the services seem to be running though. I even have unchrooted access through FTP. I'm in wheel group but have no access as root with FTP. Already checked ftpusers, but root is hashed (yes, I know this is wrong). Either I forgot the password, or something has changed. Any hints? Did I do something wrong? Is there a fix? Or do I have to travel 400 km? Well, assuming there is a human being on the other end that you share a common language with, I doubt you need to travel. You provide basically no information about what you did, what you started with or where you tried to go, so you aren't going to get a certain answer here. However, the only time something like that happened to me is when I tried to take a system from 3.1 to 3.5 or similar by remote. Being the system was completely wrong by that point, I did a remote reinstall, including unpacking etcXX.tgz (which you will note, you are told not to do) which clobbered my existing passwd file (which I expected), but I forgot to change the password before reboot. I ended up with a completely functional system with no root password, and sshd is smart enough to keep people out of root if there is no pw. Oops. That's assuming ssh is really responding to you. If you are just getting slapped away, rather than getting a login prompt, it could be a problem with your PF configuration, most likely one that was going to bite you on reboot anyway, reboot or not. Can you log in as any other user via ssh? Got sudo set up? With FTP access to the box, your only hope is a configuration error you can exploit. Hopefully, that's not gonna happen. Most likely, you will just have someone local force the box for you: http://www.openbsd.org/faq/faq8.html#LostPW and then log in (or have them disable PF or ...). You can also look at /var/log/authlog for clues as to why you can't log in as you wish now. Nick.
Re: pf blocking nets in a way like *.google.com ?
Falk Husemann wrote: [EMAIL PROTECTED] wrote: That doesn`t mean I can use *.google.com but I would be able to use www.google.com if I understood the FAQ and the manual correctly. Because I may not be bale to know every Hostname in a foreign network a Joker would be a neat solution. Is it maybe planed to add any joker to PF so that such stuff would be possible in the future if it isn`t already possible? Why isn't it feasible to use Googles allocated netblock (216.239.32.0/19)? It is feasible to block any numeric network block. What isn't feasible is to look at a DNS name and think that you can come up with simple PF rules that will block it. Maybe you could use a script to update a table in pf using whois and grep for the CIDR/Netrange in the reply. Maybe you could for your application. However, this is not a generic solution at all. Here's an example: at the office I work at, we used to have a firewall which claimed to block by DNS name, just as is being discussed. What it really did is exactly what you propose: periodically, it would do some DNS queries, and populate a table, and block those IP addresses. It was decided that our users should not have access to webmail from our offices, so mail.google.com was blocked, but www.google.com was ok. Here's what happened (warning: vast oversimplifications here!): A DNS query for mail.google.com returned a set of IP addresses. A small subset of the actual addresses that served mail.google.com. That's the way DNS can work: if there are five hundred machines that respond to a particular name, a single DNS query might return eight. Or one. Whatever. What this firewall didn't know is mail.google.com machines were the EXACT same machines as www.google.com. So, the results of the block was, uh..entertaining. Two people in the same department with the same network privileges would try to go to google, and one would get what the expected, the one next to them would get the This site is blocked! page. If I had thought to look for it, we'd have seen the same behavior for people trying to get to gmail -- some would be blocked, most would get through. Took a while to debug that one, as I really never figured someone would put such a clearly flawed feature in a commercial firewall product. :) (silly me, work with OpenBSD too long, you forget to think about buzzword compliance and management pressures to do something!, no matter how idiotic.) Today, many big sites use world-wide distributed front-end services like Akamai. Many of them use the SAME world-wide distributed front-end service -- so what you do by IP address (for example) to google.com might impact microsoft.com and apple.com, which is probably not what you intend. PF, can easily block every single address of every single Akamai server, but that won't necessarily do what you want. I've been a fan of DNS mangling to deal with this problem for some time. Technically, it is a horribly flawed system. Practically, it works, and works very easily. More: http://www.holland-consulting.net/tech/imblock.html Nick.
Re: How will OpenBSD Defend against Virtual Rootkits?
On Tue, Apr 25, 2006 at 07:32:41AM -0500, Dave Feustel wrote: This question comes to mind as a result of my reading just now VM Rootkits: The Next Big Threat? By Ryan Naraine March 10, 2006 http://www.eweek.com/article2/0,1895,193,00.asp Not much that can be done. As has always been said, if someone has physical access to the box, Game Over. VMs just give someone a new way to have physical access to the box. Now, if only we could do away with the myth that an OS can really find problems within itself (such as malware scanners that claim to fix problems on infested machines). Since that won't go away, I guess it isn't surprising that people expect that a guest OS can detect or deal with a problem on the host OS. Nick.
Re: X on Compact Flash
Steve wrote: Hi all, I am currently using 3.8 release with a basic X install and rdesktop as a thin term for a windows terminal server. I would like to migrate this to compact flash or similar. Flashdist and flashboot dont seem to be able to accomodate this. as they were designed for tiny, non-X setups, I'd be surprised if they did. Am I missing something or are there alternatives. You seem to be missing the obvious: Install OpenBSD normally on a sufficient sized flash media. What is wrong with this solution? You can't easily buy 16M CF devices anymore. 512M will probably do the job. If starting a new project, start with 3.9, as things got a lot bigger due to the addition of debugging symbols in libraries. Might have to leave out the compXX file set, not much desire to compile from source on flash anyway. Nick.
Re: Why advocate Old daemon book?
prad wrote: On April 29, 2006 02:09 am, [EMAIL PROTECTED] wrote: The state of the art of computer science has gone (steadily?) downhill for the last 30 (maybe 40) years. The computers are bigger and faster, but the knowedge of what to do with them has decayed. There are a few pockets of resistance to the decay. what an interesting comment! i'm from the past - 1980s (pascal era even recall doing stuff with punch cards) and while i am not particularly experienced with computers, i do recall that back then things were 'harder' and you did have to know more aspects of what you were doing. for instance, i was brought up to believe that it was a good thing to declare your variables before using them and that there is one way in and one way out of a loop. you don't have to do all this anymore ... i enjoy the convenience and fluidity, but do wonder if this is a good thing? writing precise compact code back then was not just a matter of pride, but a necessity too. I've been watching them try to make programming easier and faster for almost thirty years. From what I have seen, good programmers are still desperately needed and very rare. And writing GOOD code is still a slow process. Writing crappy code has got a bit faster, maybe. However, as the expectations get lower and lower, few really seems to care much. i have almost settled on openbsd as 'the system' for us after trying various linuxes and then the 3 'main' BSDs (couldn't get free and net to work the way we wanted to on our servers). i like the simplicity of openbsd and i especially like the fish!! Funny, I agree completely. ;) i do have a question about goals. i have been told that freebsd (which ran quite well on my personal system) strives for performance and stability. apparently, it achieves both quite well too from what i have heard. openbsd, on the other hand, doesn't even mention performance or stability in its goals. (curiously, i've found on my system at least that some things seem to work faster on openbsd than freebsd.) so are performance and stability a bit of panacean bravado? is it possible that all the bsds perform competitively and have similar robustness? is that why netbsd chose to focus on being able to run even on a toaster, while openbsd emphasized security? Stability should just be: The natural result of quality code. You can tell someone who has spent too long with Windows, they are the ones bragging about uptime, thinking it is a wonderful and shocking thing when you go over a year without rebooting. Uh..what was supposed to happen? Operating systems and applications aren't supposed to crash, they are supposed to Just Work from the time you power 'em on to the time when you shut them down or the power goes out, or you have to relocate the machine or ... Exceptions to this are just plain wrong, sanity would dictate that this should just be assumed. Or as I tell people, when I first started working in this business (1982), when a customer's computer crashed, they brought it in for me to FIX. Sorry, that just happens wasn't an acceptable answer back then. When the thing crashed, it was broke and needed repair. Of course, the consumer machines often went from power-on to OS prompt in 15 seconds or less (I have an Osborne 1 which I timed going from power-on to command prompt in five seconds... booting off a floppy disk!), and power-down was flipping the power switch. So, the idea uptime really didn't exist in the consumer market...when we were done, we turned off the machine. Wouldn't surprise me if the fact that there was no reason or desire to leave your computer on 24x7 hid a lot of memory leaks and other problems. As for performance, that's not a key goal of OpenBSD, but when you code things right (and that IS a goal), things will work pretty well. For what most people will do with their systems, you will need a stopwatch (or automated timing!) to see the differences in performance between different OSs. That's silly -- if you can't FEEL the difference, the difference doesn't matter to the HUMANS using your system. This isn't drag racing or speed skating, a fraction of a second in the total runtime of most tasks won't matter to anyone. If improving security costs a bit of performance, OpenBSD views that as a fine trade-off. If doing something RIGHT means not being the first to market with a new feature, that's not the end of the world. And then...really funny things can happen when it comes to performance... Someone optimizes the heck out of the code, make sure it will be able to pull every last bit of performance out of the system possible...and then they say, Oh, but it would be 'expedient' to incorporate binary drivers from vendors who don't give a rat's butt about the project's goals, or about optimizing their product performance on anything other than (maybe) Windows. And suddenly, all that work is now...pointless. It's a funny thing about goals. Lots of people have
Re: Compilers make a system less secure?
Anton Karpov wrote: Maybe, because in some cases, it just takes a bit more time to 0wn your box if it has no compiler installed. Bull. I've never heard of someone taking over a box using a compiler. After all, the compiler is not exposed to the outside world. At most, they build some tools on the system AFTER the takeover. But that's hardly the only way to get those tools on the system. scp works very nicely. ftp works very nicely. http works very nicely. After all...why download and compile tools when you can just download the pre-compiled tools? If you can't download the pre-compiled binaries, you won't be downloading the source, either. Proof: how many Windows boxes have development tools installed? A: Almost none. Conclusion: Windows is more secure. ...uh, wait a minute. This isn't a matter of opinion. This is a matter of easily disproved nonsense. I can show you lots of examples of compromise which had nothing to do with the compiler. Can you show me one example of compromise which REQUIRED a compiler? (i.e., could not be accomplished without the compiler on the target machine, lack of hardware by the attacker doesn't count). The only time when leaving off the compiler might help is if your vulnerable machine is a non-mainstream platform...and relying on that for security is kinda like moving the door of your house to the back, so attackers can't find it. Nick.
Re: www.openbsd.org defaults to Japanese
[EMAIL PROTECTED] wrote: From: Tan Dang [EMAIL PROTECTED] Any reason why www.openbsd.org displays Japanese by default now? Tan I see English when accessing www.openbsd.org as I have always done so. You might want to look at your locale settings. You might want to check your browser cache. The site was certainly was messed up at the moment you wrote that. :) yeah, there was an incident...it's been fixed, but it will take a while for the fix to replicate its way out... Nick.
Re: AMD64 still broken...
Ed V. wrote: Thanks for all the suggestions (on list and off list). At this point I have: ...provided vague, imprecise descriptions, with some details scattered in a lot of different messages in multiple threads. Here's the explanation, plain and simple: you did something wrong. amd64 is NOT broken, your system or process is. Got a couple amd64 systems at work that needed a bit of evaluation, I installed 3.9-release off CD, checked out the 3.9-stable source, built the kernel, built the userland, no problems. Either: 1) You are not doing what you described 2) you are doing something wrong you didn't describe 3) You are doing something you aren't telling us that you assume is completely unimportant. And isn't. It works. Really. Wish I had a few bucks for each and every time someone jumped up and down and swore that release or stable was broke, and prompted me to test it...and (of course) found no problem. Fortunately, amd64 systems are fast. One of these things had two dual-cores...and a laptop hard disk. The single-core system with the multiple SCSI disks finished in half the time. 8-/ You might want to try faq5.html the build instructions, a bit more detail there. Nick.
Re: patch validation
[EMAIL PROTECTED] wrote: yea. i'll keep that in mind. too bad it doesnt work in an audit. seriously, is there anything that a) can be queried against? sometimes b) compared against? sometimes c) hashs of files? don't count on it. d) etc? yes. Seriously, tell us what your criteria is on the first question, then. The nature of a patch is usually that it changes the absolute minimum required to fix the problem. That usually involves no version number changes. Some things embed the compile time in the binary, so hashes are useless for this. Still...how about a nice, simple ls -l? For example: Patch is released on Mar 25, 2006. Look at your binary's date. If your binary is dated May 2. 2006, either it has the patch or your process is broken. Why would you build if you haven't recently updated the code (if that's your purpose). If it is dated Mar 24, 2006, it probably isn't patched. Seems pretty simple to me. If you are running on a VAX or mac68k, add the number of days it takes you do a build. Nick.
Re: i386 chroot on amd64 platform (obsd 3.9)
Karel Gardas wrote: Hello, I've installed OpenBSD 3.9(amd64) on AMD64 box and now I thought about installing i386 OpenBSD minimal install into this installation just to be able to chroot from amd64 environment to i386 without a need to reboot computer. I tried this, but it seems at least on GENERIC kernels it's not supported: # chroot `pwd`/i386/ chroot: /bin/ksh: Exec format error # machine amd64 # file i386/bin/ksh i386/bin/ksh: ELF 32-bit LSB executable, Intel 80386, version 1, for OpenBSD, statically linked, stripped OpenBSD/amd64 is a totally different platform than OpenBSD/i386. Do you expect to be able to run sparc apps on alpha? is this way supported in different kernel configuration? Is it recommended by you OpenBSD folks? I'm asking since this is how I test software on both platforms on debian. And we all know OpenBSD is just another Linux variant. Sounds like either they spent a lot of time putting in a compatibility layer or very little time putting in 64 bit code support. I'm guessing it was something expedient to help compatibility with binary stuff that wasn't available in 64 bit code. You probably think this is a feature of Debian. As someone who watched the world spend over a decade running 8088 code and work around 8088 limitations (i.e., EMS)on 80286, 80386 and 80486 and later processors, I think this is a really bad idea. I am SO glad that OpenBSD has kept them separate. Here's an interesting thought...wonder how one would handle the W^X on your hypothetical OpenBSD/amd64-32. Some code could use the NX bit, others would have to play with the MMU...sounds unlikely to be done right. ok, never mind...not that interesting at all. Nick.
Re: Mouse problem
Gabriel George POPA wrote: ... Unfortunately, one day when I came to work the mouse pointer started to behave in a chaotic manner on the screen when I moved the mouse. Both in console and in X. Very nasty. I know it is a stupid problem and a stupid question, but that's it. ... Could this be it? http://www.openbsd.org/faq/faq12.html#i386smouse Nick.
Re: www.openbsd.org defaults to Japanese
On Fri, May 05, 2006 at 12:41:51PM +0200, Jacques wrote: Nick Holland wrote: You might want to check your browser cache. The site was certainly was messed up at the moment you wrote that. :) yeah, there was an incident...it's been fixed, but it will take a while for the fix to replicate its way out... Nick. May we know, what kind of 'incident'? Sounds like a security issue. Someone once said that life in the modern world requires a knowledge of statistics and psychology, and those without will live in a world of conspiracy theories. I'd be tempted to add and the ability to do a little research on your own. Nick.
Re: Partition not showing up in disklabel
Henrik Borgh wrote: Hello there. I have a laptop which dualboots Windows XP and OpenBSD. For each of these i have a partition. Further more i have a partition, which contains somekind of restore-information and at last another partition. The Windows XP-partition is FAT32, the restore-partition is some Compaq-thingie and the last partition is also FAT32. Unfortinately i apparently can not access the second FAT32-partition from OpenBSD, and even after reading the manpages for fdisk(8) and disklabel(8), i haven't found my solution. I fear that i may have missed something very basical somewhere and would really like a hint, for where to go. The FAT32-partition is 3: 0C 3931 0 1 - 4862 254 63 [63151515:14972580 ] Win95 FAT32L which was created _after_ the OpenBSD installation. My poroblem now is, that i haven't been able to find a way to include this to the existing disklabel, without clearing the entire disklabel and manually create it again? Don't clear anything! Just add it. That is something you have to do, however. Nothing does it automatically for you after the initial install. http://www.openbsd.org/faq/faq14.html#foreignfs Read the whole thing. Carefully. If you don't understand, start at the top of FAQ 14, and work back through it. When you understand what is going on (usually indicated by saying to yourself, Oh, I get it! That's cool!), you are ready to do it. As always, have a backup of important data before starting, though if you understand what you are doing, recovery from most errors is pretty easy. You win no points for finding the edge cases, however. Nick.
Re: 3.9, Sparc64, and X issues (black screens)
Chris wrote: Are there issues with 3.9 and Sparc64's with ATI Mach64 cards and X? I cant seem to find a happy place to have X running. All I get is a black screen. I tried several diff mem settings, screen sizes, etc and still nothing but black screens. I ask becasue this is the same on both my Sparc 10's Has someone have a working config? Lots of people do. Works fine on my U5. see /usr/X11R6/README. Read it, follow the instructions, look at your dmesg, take the proper parts from the README file, and you will have no problem putting a working config file together. Nick.
Re: ftp-proxy isssues
[EMAIL PROTECTED] wrote: Hi All, Until pf 3.9 i've had no problems with ftp-proxy and now it doesnt work anymore because of the anchor stuff, very nice .. ... How can i transform all this into the anchor stuff? See at least the following: http://www.openbsd.org/faq/upgrade39.html http://www.openbsd.org/faq/pf/ftp.html#client (might want to give the second one an hour or two, just found that I forgot a very important line in it!) Nick.
Re: /var filled up and can't login locally or remotely
Tobias Ulmer wrote: On Wed, May 10, 2006 at 10:50:14AM -0300, Giancarlo Razzolini wrote: Paul de Weerd wrote: Don't change root's shell. It's set to a static shell (/bin/ksh these days) for a reason. Changing the root shell doesn't hurt. But you have to install your shell static. I use the bash-static from packages, and hadn't any problems. I think that booting in single and cleaning some trash, might solve the problem. Also you might want to consider installing the bash-static. My 2 cents, If you change it, fine. But don't tell others that this is not a problem. It can be a very big one if a critical box is 500km away in some datacenter and your remote upgrade failed because you removed all packages without thinking that you still need to keep bash... If you don't believe me that these things happen, search the archive. There's a more basic rule I like: KEEP IT SIMPLE, KEEP IT LEAN. The more stuff you slop into your system: ..The more stuff you have to keep up to date. ..The more complicated upgrades become. ..The more likely something will go wrong. ..The more things you have to worry about security holes in. ..The less often you will do updates/upgrades because it is difficult. ..The more ignorant you will look when confronted with a system without the slop. and so on... I doubt many people have had a non-responsive system and said to themselves, Gee, if only I had installed bash on it. Learn your base system. If you really NEED something, where you can say clearly why and what benefit there is to you that outweighs the risks, well, fine. But slopping your system with crud just to make it look like something else or just because you can is not a good idea. Nick.
Re: Manually naming Multiple NICs
[EMAIL PROTECTED]@mgEDV.net wrote: [you edited out discussion of *USB* devices] Normally these devices come up in the same order each time. It is not gauranteed, unfortunately, because device bring up can race against other devices. I've seen it be non-deterministic. me, too. especially, if you plug in another nic on pci between 2 other nics. this is really confusing the box. also take care for your bios interrupt settings - if you have a lot of traffic, it sometimes can be smart to put all the nics on the same interrupt. You creatively edited out the part that clearly indicated the topic of the part you quoted was USB devices, not PCI. PCI devices come up very predictably, if you understand how it works. Nothing is confusing to the box at all. YOU may be confused, but the box is quite sure of what it is doing. :) A little experimentation (which everyone should do before putting a box into production) will make it very clear. Assuming you have all the same kind of NIC, it goes by slot number. Yes, if you stuff a card between two other cards, yes, the cards are EXPECTED to change IDs, I can't think of anything else I would want it to do (being that I really hate it when software or hardware tries to make guesses about what I was intending). If that isn't what you want, first move one of the existing cards, then add the new card to the vacated slot. I still recommend writing the last few digits of the MAC addr on the spine of the NIC, as some machines number their slots in a curious way. A Dell GX1 will number its slots something like 2 3 4 0 1. BUT...if you blow a NIC, pull one out and put a spare in, all stays as it was. If you change it out for a different type of NIC, things will change, but you can easily predict what they will end up being, and if you don't understand what is going on, dmesg and the label I suggested putting on the card will clear it all up. :) If you pull the NICs out of one machine and drop in another, you have to take a little care to make sure you know where they end up, but again, once you know where they are, they stay put, and you can replace them and know what will end up happening predictively. Michael Schmidt wrote: Please allow a silly question: What4s the reason for put all the nics on the same interrupt if one has a lot of traffic? First, you start messing with your BIOS at that level, you are more likely to break things than improve things. The way people usually shoot themselves in the foot is by forgetting that PCI was designed to share interrupts, and trying to use the old ISA logic of each device on its own IRQ. Here is a massively over-simplified explaination of what happens: Let's say you have five PCI devices which could trigger interrupts. Again, the PCI bus was designed to share IRQs, so when an IRQ comes through, the first thing that happens is you have to push a bunch of stuff off to the stack before servicing the IRQ, then you have to identify which device fired off the IRQ before you can do anything about it. If a lot of IRQs are happening, so the next is often coming in before the previous one was finished, there are two ways things could happen: 1) You return to what you were doing before the IRQ came in, but then the IRQ fires again, sending you back to the IRQ service routine. (this is how unshared ISA IRQs were handled) 2) BEFORE returning, you check to see if any other device needs to be serviced, which is possible if they are sharing the same IRQ channel. In fact, if you are sharing the same IRQ, you have to do this. Hopefully, it is moderately clear that you save two IRQ-caused context switches by staying in the IRQ service routine and looking for more work to do. The more additional IRQs that come in, the more potential savings. This is possible if you are sharing IRQs. IRQs are costly things when it comes to processor time. Reality check #1: This only matters on HIGHLY loaded systems, where IRQs are stacking up. If your system is this loaded and you have less than the best HW, you can probably get better gains by selecting different hardware. A machine which has multiple PCI buses or higher-quality NICs will probably give you a MUCH larger benefit than IRQ sharing. My wild-a**ed guess of what IRQ sharing would do for you would be at most a few percentage points, not enough that anyone would ever notice in the real world of how it feels to the user results. Reality check #2: I'm not a kernel hacker. But in eight+ hours, no one else answered. :) If you take what I said too seriously, you are nuttier than I am for saying it. Nick.
Re: PF references
News Collector wrote: Hello: Where (what) is the canonical site (or book) for PF. documentation-wise? that would be the OpenBSD man pages. They are authoritative. When things change, they get updated, or people get beaten. In particular, see pf.conf(5), pfct.(8), pf(4) and the SEE ALSOs in each. Beyond that, there are several websites and books. My personal favorite website is the OpenBSD website itself, but I may be biased. :) Are there any site where talk about PF is a application (like for OS X). probably. There's a website for just about everything. Talk is cheap. One Last, has anyone done any work on using CARP, Quite a few people have, yes. ;) I know synchronizations depends on similar cpus with similar clocks and constrained clock drift. oh? News to me. And the Celeron 600 that I CARPed with a PIII-750. Don't really have to even be the same platform, though it can create administrative problems (On this machine, carp0 is on the dc0, on that machine, it's on hme3). Nick.
Re: ksh and X windows.
Peter Fraser wrote: If you install a new 3.9 system, and enable X windows (The only package I installed was emacs) Create a new userid with ksh as its shell and sign on though X. ~/.profile does not get executed Nor does ~/.profile get executed then a new xterm is created using the left click menu in the background. http://www.openbsd.org/faq/ I expect this related to my earlier messages about .profile and ksh. Got me, I see you have asked a lot of questions, often in the tone of a remarkable discovery that most of us already knew about. A little time doing some research on your own will be far more educational. For that reason, I deleted the rest of the link above. The answer to your quest..er..statement is very much in there. Start reading. Nick.
Re: Help needed with 3.9 bandwidth/speed problem
Adam wrote: Hello, I have an odd problem with my 3.9 server. I can not seem to push more than 2.5 - 3.0 mbps per connection over the Internet to hosts. I've tested this with scp, apache/httpd, and lighttpd. I've also tried this with PF on and off, resulting in no difference at all. I have tried filtering packets in PF and redirecting to another host. That works fine and I've been able to pull 8.3 mbps over the Internet without a problem. Also, just for reference, the server is on a 100M line in a datacenter so I'm not running out of bandwidth. When I did my tests, things were completely idle and I was the only client creating traffic at the time. I'm quit stumped with this. There doesn't appear to be any errors, but there is definitely some sort of glass ceiling that I'm running in to. Try this: http://www.openbsd.org/faq/faq6.html#Tuning 'specially 6.6.4... As you indicated, it doesn't seem to improve performance when FILTERING packets going between two other machines, only when OpenBSD machines are the endpoints. The difference can be dramatic over a WAN. Or completely non-existent for most people. (thanks for the dmesg! :) Nick.
Re: dual boot problem
viq wrote: On Thursday 25 May 2006 09:22, Jan Johansson wrote: akonsu [EMAIL PROTECTED] wrote: dd if=/dev/rwd0c of=mbr count=1 Here is your error dd if=/dev/rwd0a of=pbr count=1 For the NTLDR you want the PBR (Partition Boot Record) not the MBR (Master Boot Record). I changed the of= for correct the terminology the important part is the if= device. I usually use dd if=/dev/rwd0a of=/mnt/OpenBSD.pbr bs=512 count=1 where /mnt is the mountpoint of a small FAT partiton that is active. While at the subject, you need to run this every time you upgrade bootblocks. What would be the result of not updating bootblocks when upgrading from snapshot? depends. The boot code doesn't change dramatically often. Last time it happened, it was the changes that permitted OpenBSD to boot beyond the 8G point on BIOSs which permitted it. I personally tested around 50 different machines to make sure it worked, and several hundred other reports were provided by other users and developers. And when a last minute improvement was discovered, I had to re-run those tests. :) So...avoiding updating the boot blocks is usually harmless...you would be replacing code with the exact same code. Now that I've said that, it will probably change, and in an important way. Or not rerunning that command when updating them? As indicated by others, the system won't boot. The inode for the second-stage boot loader (/boot) is hard-coded in the PBR. Change that inode, you have a problem, because what the NTLDR does is invoke the PBR that was saved...IN THE PAST. So, that PBR will end up trying to pull in and run who-knows-what...and will likely fail. Ugly? Well, before that bootloader change, the actual physical blocks were coded in the PBR, which meant recopying the file /boot would break the boot process. The current process is actually very robust, recopying the /boot file doesn't change the inode number normally. The normal upgrade processes are done in such a way that the inode isn't changed, so this will rarely be a problem. The good news, almost by definition, a multi-booting machine isn't at some remote location...it's in front of you, thus easy to repair. (yeah, I am sure someone has a weird setup. whatever). Nick.
Re: OpenBSD Newbie
misiu wrote: Hello all, I'm new to OpenBSD, I installed it a few times but than did not know what to do realy. Right now I'm little more experienced with Linux and I thought give it a nother try. Now I'm runnin an Openbsd 3.9 Box. Default setup. I try to run a Webmailbox and later Openvpn. It did not work so I searched long for an answer. I started httpd -u and now Openwebmail is running. I read allso that it is insecure, how can I run httpd chrooted and Openwebmail? Did not find any (for me understandable) answer. You are getting some good advice on chrooting in GENERAL, but kinda missing your specific case by a wide margine. What does chroot do? Confine an untrusted app within a section of your file system, preferably one in which they have no write access, so if the app has a security problem, the damage is minimized. Doesn't make the app more secure by itself. BUT... you need write access. So you grant it. You need libraries, you copy them over. You need programs, you copy them over. You need root access, you grant it. by this point, you have lost just about all the advantage of chroot, and spent a lot of time doing it. Look at OpenWebmail. Neat program for a basic webmail app (and considerably better than some commercial webmail programs). Amazingly self-contained, doesn't need an IMAP server. Just off the top of my head, having installed it in a trial environment a few years ago, it needs AT LEAST the following: access to sendmail binaries access to /var/mail access to /home root (that's how it reads the mbox files in /var/mail and /home) perl The thing needs root. Gotta have root. No root, no work. If you got root, you can probably escape from a chroot. Much better than worrying about chroot'ing OpenWebmail, just put it on a disposable box, with no other secure apps, and make sure you use passwords/keys on it that don't show up elsewhere on machines you maintain. Box gets owned? shut it down, figure out what went wrong, rebuild and repair. Some places, chrooting is great. However, simply tossing enough stuff in the chroot to make your app run does NOT automatically mean the app (or your box!) is any more secure when done than it was before. By the time you copy everything over to the chroot, you have not really gained much advantage /in this case/. Openwebmail is not good explained too. Has anyone installed it ? (I guess for shure) would that one please contact me offlist? I don't whant step by step help just to shed a little light in been a while...but a few hints: var needs to be able to exec code and no nosuid, which IS there on default OpenBSD installs. Put your home directories physically in /var if you expect quotas to work as expected, you can symlink them back to /home if that freaks you out excessively. That's about all I remember. Oh, and don't have 25 kids change their PWs all at the same time unless you have around 600M of RAM+Swap available. Ouch... Nick.
Re: Wondering about security...
Peter Philipp wrote: Hi, I had this USB stick called CHEER, see message ID Message-ID: [EMAIL PROTECTED] here is a clip from messages showing the ID, May 11 16:05:41 neptune /bsd: umass0: CHEER USB_DISK, rev 2.00/2.00, addr 2 May 11 16:05:41 neptune /bsd: sd1 at scsibus2 targ 1 lun 0: CHEER, USB_DISK, 1.00 SCSI2 0/direct removable bash-3.1$ grep sd1 /var/log/all | more May 11 16:05:41 neptune /bsd: sd1 at scsibus2 targ 1 lun 0: CHEER, USB_DISK, 1. 00 SCSI2 0/direct removable May 11 16:05:41 neptune /bsd: sd1: 1010MB, 1010 cyl, 64 head, 32 sec, 512 bytes/ sec, 2069760 sec total May 11 16:06:12 neptune /bsd: sd1 detached May 26 15:12:31 neptune /bsd: sd1 at scsibus2 targ 1 lun 0: SKYMEDI, USB Drive, 1.0 SCSI2 0/direct removable May 26 15:12:31 neptune /bsd: sd1(umass0:1:0): only the first 4,294,967,295 sect ors will be used. May 26 15:12:31 neptune /bsd: sd1: 2097151MB, 2097151 cyl, 64 head, 32 sec, 512 bytes/sec, 4294967295 sec total May 26 15:12:44 neptune /bsd: sd1 detached Anyhow... yesterday was a holiday here in germany. And I left my apartment with the iBook turned off. Someone musta done an exchange of my USB stick drive while I was out. Surprisingly it booted OpenBSD like usual and I did not notice a change until it blew up today and wiped itself. When I plugged it into my host neptune I noticed the different USB Id... The USB drive looks exactly the same coincidentally. So... To get to the point. What are some recommendations by OpenBSD users for physical security, other than run and don't look back (kidding, heh), Keep my house a complete cluttered mess. If you don't know where to step, you are dead. Someone tries to break in, I'll probably find their remains sprawled across a pile of junk, with an old EISA FDDI card puncturing their lung. :) As a hind thought, how possible is it for a device to blow up and change its own ID but then still being detected by the USB protocol? A lot more likely than you might think. Somewhere around here, I have a Compaq SCSI hard disk... Actually, it was made by IBM, didn't really even try to hide that on their stickers outside the drive. I had at one point probably fifty of these things, all the same, all pulled from the same batch of computers (dealer's customer wanted 4G, not 2G drives). Every one had the same ID string, saying COMPAQ and some model number. Except this one. For unknown reasons, this one forgot its Compaq programming, and reverted to being an IBM disk. As I recall, it worked fine for a while like that, but I think it failed later (or maybe I noted the bizarre change after it failed). So yes, Funny Things Happen. I could attempt to make a wild guess as to why this drive shed its altered ID and reverted back to the ID it was originally engineered, but you are probably thinking the same thing, and we are probably both wrong. I think I've seen this elsewhere, too. And yes, I've seen various supposedly non-volatile EEPROMs and Flash devices spontaneously die. Seen it so many times, I really do snicker when people try to use Flash because it is has no moving parts and is thus more reliable than disk (there are very valid reasons to use it. I just don't think reliability is one of them). I really suspect that no one did the swap on you, your stick probably just died, and in the process, lost some custom programming the marketer did to it. You would have to have some thing Really Valuable for someone to go through all that trouble. Much easier to replace your good stick with a completely defective stick...you'd just think the thing failed, and never think that maybe someone somewhere now had your data. Note also that your drive's size became very wrong. I think the thing just died on you...and picked up another identity on the way. Nick.
Re: dd problem
akonsu wrote: hello, i wanted to create an ISO image of a CDROM, so i ran this command: dd if=/dev/cd0a of=my.iso and i waited and waited for about 30 minutes until i just gave up and pressed ^C. the resulting iso file was much larger than the source disc. try dd if=/dev/rcd0c of=disk.iso bs=32k note the rcd0c instead of cd0a. The 'a' vs. 'c' doesn't (seem to) matter, I just philosophically prefer the 'c' implying entire disk, rather than just one partition. The raw mode of access makes a lot of difference here. I put the bs=32k in there for a bit of additional performance, but it turns out that without the bs= line, it didn't work at all. After a little thought (and testing), I remembered that on most modern platforms, CDROM drives have a 2k block size, so apparently dd has trouble moving 512 bytes at a time out of CDROM drives. I confirmed that bs=2k worked, bs=1k does not, so I might possibly be not totally wrong on that. bs=32k seemed to go about twice as fast as bs=2k. Well, I learned something. :) Nick.
Re: one drive in a raid 0 failed, can I save any data?
On Thu, Jun 01, 2006 at 08:57:08AM -0700, John Brahy wrote: F.r.a.c.u.l. .e.k. . .a. .u.n.n. .i.h.u. .a.k.p. .n. .n. .f.t.e.d.i.e. .i.d. .s.t.e.e.a.w.y.t. .e.o.e. .n. .f.t.e.d.t. .r.m.t.e.d.i.e.? N t l k l . o r . - Drive 0, RAID0 o i e y S r y - Drive 1, RAID0 Nick. - Drive 0, RAID1 Nick. - Drive 1, RAID1
Re: A joke
Sean Cody wrote: On 1-Jun-06, at 10:22 AM, Andrew Pinski wrote: On Jun 1, 2006, at 1:44 AM, Rico wrote: Manager: George, I need a program to output the string Hello World! You forgot one: a lazy person #!/bin/sh echo Hello World! Why waste an extra shell process not to mention all that extra typing? #!/bin/echo 'Hello World!' :P --Sean On the other extreme... Hire a company to develop an app. Add $18k Java application server license to make it easy to program. Add $9k IDE to make the easy to program stuff easy to program. Add five more programmers from the programming company (and five more IDE licenses) when timeline starts to slip. Wonder why you never have to buy the carpenter's tools when they build your house. Or the plumbers tools. Or... Notice that the $9k tool these carpenters use is made by the carpenters themselves. Upgrade RAM in all the developers machines (which you ALSO provided) to 2G of RAM, because the IDE takes 1.5G just to load. Delete all emacs jokes from local disk). Wonder why carpenters who built that IDE didn't know that it needed that much RAM. Or couldn't diagnose why their machines were so slow without it. Look at pathetic result. Coulda been done in perl, Apache and vi, 'cept it would have worked, then. Show development company the door. Make sure it hits 'em in the butt. Realize that after $63k in IDE licenses, the development company STILL made money on the deal, and trained a bunch of their people on their product (and our dime) Bring in another dev. company... (the good news is, this one seems to be MUCH better.) Nick. (who simply does not get Java Application Servers. I did ask the vendor to demonstrate a hello world program. I was not impressed).
Re: No-name NICs
Lars Hansson wrote: On Tuesday 06 June 2006 17:42, Martin Schrvder wrote: Hi, how likely is a no-name 100MBit NIC to just work with 3.9 stable? In my experience, very. Most are using the same chipsets (ie rl) as the brand NICs anyway. I cant recall ever having a NIC, brand or non-brand, that didnt work. Agreed. Whatever chip they use, the manufacturer is usually more interested in selling product than keeping you from using it outside of the Windows environment. Thus, we probably have docs, and the driver probably works pretty well (even if the chip itself is often resoundingly criticized). Kinda silly how much effort some big-name companies put into making sure you CAN'T use their product anywhere and everywhere... Nick.
Re: Custom /bsd.rd to send in dmesgs?
vladas wrote: Will devs ignore dmesgs from /bsd.rd that would resemble the -current GENERIC /bsd (if it is possible to do so)? I want to send in a few dmesgs from the machines where I cannot install OpenBSD, so I thought /bsd.rd would help. There are a lot of reasons why developers want the dmesgs -- a major reason is to find out how the GENERIC kernel sees the hardware, another is to get reports of how it actually works with that hardware. A custom kernel does neither of those tasks. Simply booting bsd.rd (even an official one) doesn't answer either very well...what happens if a probe of something in GENERIC that isn't in bsd.rd causes the machine to lock? What happens if the disk interface is properly recognized..but doesn't work properly? You would never know if you didn't actually do the install. The lack of a didn't work! message might cause someone to think it did... Perhaps even more tantalizing, what if a problem IS seen in the dmesg...if you can't install, you can't test a fix. So..I suspect you won't get a lot of excited responses from developers, in general. Or I could be wrong... Nick.
Re: Combining boot floppies
When I saw your note, I figured Something Ain't Right here. I wasn't the only one. Theo noticed. I'm on a mission from Theo. Michael White wrote: Hi all, I'm attempting my first install of OpenBSD (version 3.9) on an HP Omnibook 800CT (Pentium 166, 80 MB RAM, 4.3 GB HD, 3COM 3CXEM556 Carbus Ethernet card), coming over from RH9.0. One peculiarity of the 800CTs is that the SCSI CDROM is not bootable, so I'm down to booting with floppies. whoa. SCSI. (he's right on this, btw... Symbios Logic 53C810, if the page I'm reading is to be believed.) I first attempted to boot from floppyC39.fs, since that's supposed to be the image for laptops. Well, it does recognize my Ethernet card, but seems to choke on the hard drive. After recognizing the Ethernet card, I see the following: -- wd0(wdc0:0:0): timeout type: ata c_bcount: 512 c_skip: 0 wd0(wdc0:0:0): timeout type: ata c_bcount: 512 c_skip: 0 WARNING: preposterous time in file system WARNING: file system time much less than clock time -- After that, the machine is locked up. So I boot from floppy39.fs instead. That had no problem with the hard drive. I was able to successfully partition the drive. But that image does not recognize my Ethernet card, so I'm unable to retrieve any images (didn't see an option for PPP). The fact that floppy38.fs didn't see your network adapter is not unexpected, of course. The fact that you had disk issues on floppyC39.fs is unexpected. The fact that they go away on floppy39.fs is all the way to Just Plain Wrong. Even after formatting the hard drive under the floppy39.s floppy, the floppyC39.fs floppy chokes on the hard drive. Is there any way to combine the two capabilities? Not the way you are thinking. But I have some ideas... The only reason I'm asking is because of a comment in the FAQ (section 4.3): Yes, there may be situations where one install disk is required to support your SCSI adapter and another disk is required to support your network adapter. Fortunately, this is a rare event, and can usually be worked around. Worked around means combining hardware and install options in such a way that it is made to work...not fiddling with the boot media. Usually. I may have access to a Xircom network card - is that supported by the floppy39.s floppy? No, the Xircom driver is not in floppy39.fs... At least, not the Xircom driver I'm thinking of...they may have more than one. :) Anyway...I'm sitting here looking at the config files that make up floppy39.fs and floppy39C.fs (RAMDISK and RAMDISKC, for those who want to follow along), and their diffs. First, I see that the SCSI controller that is probably in your laptop is supported by the siop(4) driver, which is on floppy39.fs. SO..the suggestion of dropping the file set on a CD and installing from that is probably workable. But that's not what Theo sent me to ask. We are interested in the reason for the problem more than a quick-and-dirty work-around. Besides, it is entirely possible the problem will be back with us when the full kernel loads. So..back to the diff... It sounds like there is something hurting the disk support on this thing. So...we can try turning some drivers off, and see if that gets floppyC booting properly. You do this using User Kernel Configuration, a.k.a., UKC: http://www.openbsd.org/faq/faq5.html#BootConfig Here is a list of things to try disabling (disable bla at the ukc prompt): uhci* ohci* wdc* Those you can do all at once. h... those were the only easy (a.k.a., mostly harmless) ones. Well...if those don't improve things, let's try breaking some things: pciide* (your disk performance now sucks) pcic* (that might kill your PCcard slot) cbb* (if the above didn't, this will) Do these one-at-a-time. I'm not really sure what is going on... You may have an issue with the PCcard/Cardbus support...which means your NIC may show up in the dmesg, but it may be just as non-functional as it is with floppy39.fs. Disabling pciide will cause a huge performance hit, but slow beats not working at all. Might be interesting to see what happens if you boot without the NIC installed in the machine. yeah, useless for your problem, but interesting for troubleshooting. I'd love to see is a serial console capture of the output of the boot on this thing, from both the floppy39 and floppyC39 disks...but if you aren't fluent in serial, hooking one up for your first OpenBSD install might be a lot to ask for. Ah, heck, if I don't ask, I won't get, right? :) http://www.openbsd.org/faq/faq4.html#getdmesg You can probably at least get the dmesg from floppy39.fs to a floppy disk using the process there, but if you can get both by using a serial cable, all the better... Nick.
Re: like the faq 14.16.1, partition is not in my disklabel ... need help anyway
Joachim Schipper wrote: On Thu, Jun 08, 2006 at 08:31:59PM +, Didier Wiroth wrote: Hello, My ntfs amd comaq diag. partition is not in the disklabel. I presume this means you deleted them, and now want 'em back. As they appear to have been there before the OpenBSD install, I'd have expected them to be in your disklabel. Wait a minute...how'd you get the compaq partition THERE??? (ok, that's way OT). Unfortunately I don't know how to add correctly in the disklabel. I've read the faq 14.16.1 but it only shows a modification. Here is my fdisk output, which shows id 0 the ntfs partition: Disk: wd0 geometry: 12921/240/63 [195365520 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: idC H S -C H S [ start: size ] *0: 070 1 1 - 6800 239 63 [ 63: 102831057 ] HPFS/QNX/AUX 1: 12 12270 0 1 - 12920 239 63 [ 185522400: 9843120 ] Compaq Diag. 2: A6 6801 0 1 - 12269 239 63 [ 102831120:82691280 ] OpenBSD 3: 000 0 0 -0 0 0 [ 0: 0 ] unused Here is current my disklabel: 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 2097648 102831120 4.2BSD 2048 16384 328 # Cyl 102015 -104095 b: 1024128 104928768swap # Cyl 104096 -105111 c: 195371568 0 unused 0 0 # Cyl 0 -193820 d: 4194288 105952896 4.2BSD 2048 16384 328 # Cyl 105112 -109272 e: 1024128 110147184 4.2BSD 2048 16384 328 # Cyl 109273 -110288 f: 4194288 71312 4.2BSD 2048 16384 328 # Cyl 110289 -114449 g: 10486224 115365600 4.2BSD 2048 16384 328 # Cyl 114450 -124852 h: 4194288 125851824 4.2BSD 2048 16384 328 # Cyl 124853 -129013 i: 2097648 130046112 4.2BSD 2048 16384 328 # Cyl 129014 -131094 j: 3072384 132143760 4.2BSD 2048 16384 328 # Cyl 131095 -134142 k: 50306256 135216144 4.2BSD 2048 16384 328 # Cyl 134143 -184049 What do I have to add to disklabel to be able to access the ntfs and the compaq diag partition? For ntfs something like: l: 102831057 63 unknown # Cyl ??? I would really appreciate some help. with what? You got it right there! Do disklabel -E, you won't have to worry about the cyl part. :) You probably want type to be ntfs. Thank you very much ! Some noteworthy points: 1. Looks like you ran out of space in the disklabel (or in the device namespace, or whatever): don't define this many disklabel slices if you want to see the other partitions (which are typically numbered from i). [I'm not 100% sure I'm correct here; please flame me, with the correct answer if possible, if this is not the case.] Grabbing the marshmallows and a stick here... Yes, non-OpenBSD partitions which are recognized at install time are typically listed as partitions i and up, but there is NOTHING sacred about this. a, b and c are sacred..don't misuse them. d through p can be used however you wish. Make d DOS. Make p your /usr partition. Whatever. consider yourself flamed. :) 2. NTFS is not supported in GENERIC. This usually means the implementation isn't really ready for prime time yet; you could build a custom kernel, if you know what you are doing and have read most, if not all, of FAQ 5.*. right. man -k ntfs 3. I don't know what you want to do with the Compaq diag partition, but it might not be too useful. agreed. If you aren't planning on USING a partition, don't bother putting it in disklabel. On the other hand, might be fun to find what is in that compaq partition. (no idea why, but I've never looked closely. Just a mislabeled msdos partiton, as I recall). Nick.
Re: Mail Server configuration question(s)
[re Dovecot as an IMAP server] Adam wrote: On Fri, 9 Jun 2006 20:39:24 +0200 Joachim Schipper [EMAIL PROTECTED] wrote: Does it even work on openbsd yet? Its got a long history of corrupting indexes, and spinning out of control sucking up 100% of the CPU. I first read this out-of-order... sounds like they are talking about Dovecot was my first thought... There is a port, and I've been running it for about a year now. Never had any problems, except that upgrading 0.9.x to 1.0 beta y required rm'ing all indices or strange things happened. Of course, this is on two boxes with respectively 1 and about 20 users, so it's not that good an indication; but it does not crash at every opportunity. I do use it with maildir, though; mbox support may be less good. I used the packages too. And with maildirs. It didn't crash, it just kept corrupting its indexes and then using 100% of the CPU. It could be fixed now, I don't know. Adam I haven't seen it do the CPU sit-and-spin in a long time (it did prompt me to put a dual processor machine in place for my IMAP server...it only killed one processor at a time! :), so I think that is fixed. However, it still has issues. Let's forgive the sit-and-spin. Let's forgive the corrupted indexes (even though from the first day I used it, the author claimed its indexes were fail safe. I can't tell you how safe I felt on many, many occasions with it). Let's forgive the upgrades where I kept wondering, Is THIS going to fix things, or is this going to be even worse than the last upgrade? How much mail will I lose THIS time? It is much better than it was. It is going in the right direction. But it still has issues. Want a seemingly reliable demo? Try this: Set it up on a machine to do IMAP/SSL. Push 2000 e-mail messages from a local mail client to your IMAP server. Somewhere between message 3 and 1000, it will hang, then time out on you. Switch to non-SSL, it will work fine. Switch back, hang-time-out. Exact same results on Outlook Express and Thunderbird, on multiple workstations, and multiple servers. BTW: if you are trying to convert from local e-mail to centralized IMAP storage, that hang-and-timeout SUCKS BIG-TIME...you will either end up with duplicates in the IMAP server or spend hours trying to figure out which ones made it and which ones didn't. After switching my purely in-house system from SSL to non-SSL with dovecot, I must say it Sucks Less, but I'm going to be doing at home what I did with the project I'm working on at work: Give up on Dovecot. The last straw for me was seeing a note from someone seeing the same problem I was seeing, a reply from the author saying, I guess the SSL stuff still isn't working...then a new (and current) release, which had the exact same problem. I give up. I tried. I really did. Several years of patience. It is getting better, but I'm not betting my reputation on it yet. And yes, Maildir, packages when available, ports when testing new releases before packages were made. The author says the right things. The results say the wrong things. 8-/ Yes, Courier IMAP is more complex. However, it took far less time to get going than I spent fighting with the Dovecot SSL problem. I really wish I hadn't believed all the Courier is too complex stuff before. It isn't that bad, and not only have I had no issues so far, some of the things I wasn't really blaming Dovecot for got a lot easier, too. Yeah, I know, there are people using it without problem. Great. Didn't work for me...over and over. Maybe I do cruel and unusual things with IMAP, but I didn't think THAT horrible... Nick.
Re: Kernel panic ... Unknown source ...
Scott Plumlee wrote: o?= wrote: Hello, My OpenBSD 3.9-stable Box is quite unstable. I don't have physical access to my box so I can't debug it directly. I've recompiled a GENERIC kernel with DEBUG support and set ddb.panic to 0 in sysctl.conf so that it's rebooting automaticly. But no kernel dump is made after a kernel panic. I searched on the web without finding a solution. Everytime the kernel panic is different. I tried the -current (and also 3.8). The result is nearly the same: no more kernel panics but the system freeze but it's still responding to the ping. You totally lost me on that one. Something panicked, something else didn't. However, system freeze but still responds to ping can also be a memory exhaustion issue -- all RAM+swap got used, and all tasks end up getting deadlocked waiting for additional RAM to become available. As I said before in another mail, this is NOT due to an hardware failure. Many SAME machines work perfectly. The only difference is the revision of the bios (vcore updated and Pstate disabled). I want to find the source of the bug to correct it if I could. I'm still awfully new to *nix, but isn't saying that it's not hardware just because other boxes like this don't fail the same as my car can't be out of gas because other cars of the same model are still driving by me? pretty darned close. I can understand if you mean that it's not due to an unsupported piece of hardware, in which case I would think the kernel panic would be the same, but how do you know it's not bad insert your choice of memory, disk, cables, processor, heatsink, fan, etc etc here? Anyone who hasn't seen a broken piece of HW that works fine with X but not Y is new to the game. Anyone who trusts a HW diagnostic to give them the answer is really, really new to the game. By themselves, diagnostics are like a screwdriver: in the hands of a knowledgeable person, very useful. In the hands of an idiot, dangerous. Without a brain engaged in their use and analysis of the results, they are just an inert object. The OP already answered his own question (and been told this by others). The machine has a buggy BIOS. One version works, another doesn't. Why do you think there is more than one revision? Because bugs were found. Odds are, those bugs were NOT found on OpenBSD, they were probably found running Windows, maybe Linux. OpenBSD *may* expose those bugs more clearly...but odds are, if you use that same buggy BIOS with another OS, you may learn to regret it. Would it be possible to fix OpenBSD to work around this bug? Maybe. Completely pointless and self-defeating, however. Fix it for the buggy BIOS, you probably broke it for the correct BIOSand now you have a chunk of code usable on precisely one variant of one bad computer. The code will not be properly maintained, and will probably do more bad than good some day in the future, if not immediately. Sometimes buggy hardware has to be worked around, because no fix is available or possible from the manufacturer and there is a clear benefit to adding special case code. When a proper fix IS available from the vendor, it is usually preferable to use it than to work around it. Hey, if this problem turns out to expose a true logic bug in OpenBSD, go ahead, find it, show us, and get credit for the fix. But if everytime the panic is different, it sounds like things are Just Plain Broke on the system, if a BIOS upgrade fixes it, sounds like the hardware wasn't set up properly, and the manufacturer figured that out, and FIXED THE PROBLEM. Nick.
Re: ftp problems with OpenBSD 3.9
Smith wrote: This will answer two post: It does work in 3.8 still. As a matter a fact, I have two servers on the intranet. The 3.8 works fine but not the 3.9. I tried the passive/active and still the problem persist. If I use the command line or filezilla (another windows ftp client that's open source), it works just fine in both versions. At this point I'm thinking something change on the OpenBSD side, especially since 3.9 has the new ftp-proxy. I don't use pf or ftp-proxy for this situation but maybe OpenBSD ftpd was modified to make ftp-proxy work. If there really hasn't been any change in ftpd from 3.8 to 3.9, I'll focus the problem as being on Microsoft's side. Curiously, I've noticed the MS-whatever-it-is feature didn't work with a 3.9 FTP server, too. I kinda figured it was just MS being stupid with something other than a MS FTP server on the other side. I have not tried 3.8, however. I was about to try to figure out how I'd find the time to take a look at this, both to verify your claim (which I'd always do first) then to try to troubleshoot it a bit. But then I realized...HEY! I can get YOU to do the work! :) Here's what I'd do... Install a 3.9 test machine, verify the problem exists. Checkout the source tree, or at least, the src/libexec/ftpd section, but using the OPENBSD_3_8 tag, to get the 3.8 version, and see if it 1) compiles easily and 2) works on 3.9. It just might. Or it might not. Assuming it does...do you still have a problem? Or is it fixed? If you still have a problem...there is something else going on (which COULD possibly be a library or some other system change...but I'd also look for a configuration difference. IF changing the FTP source code from 3.9's to 3.8's Fixes the problem, just start putting in change after change until it breaks. :) Nick.
Re: ftp problems with OpenBSD 3.9
Smith wrote: how do I compile it. I know I can look at previous patches and possible figure it out but I wouldn't know if it's the proper way to do it. I have a test machine all setup and ready and my pwd is /usr/src/libexec/ftpd. Just replied privately, but since you asked publicly also, should reply for the list, in case anyone else wants to try... And since replying to you, I've tested it. It at least seems to work. Not sure it fixes your problem, however. make obj make make install Stop and restart ftpd if you are running it as a daemon (ftpd -D), and you should be able to test... Nick.
Re: dmesg warning, ahc0: Illegal cable configuration!!
Daniel Hammett wrote: ... ahc0: Illegal cable configuration!!. Only two connectors on the adapter may be used at a time! [Full dmesg posted below] yay! :) This isn't unique to OpenBSD: I've seen similar reports in the dmesg from SuSE Linux using the 2.4.xx series kernels and also from FreeBSD version 6. It doesn't appear to affect the machine in anyway that I can tell, e.g. there are no unexpected hangs, slowdowns, disk problems, etc. The AIC-7880 wide SCSI is connnected to a single disk but there are multiple (unused) connectors on the ribbon cable which end in a terminator block. The AIC-7860 narrow SCSI is connected to a single CD-RW drive. Again, there are multiple (unused) connectors on the ribbon cable and this, too, ends in a terminator block. this isn't the issue, as that's ahc1 according to the dmesg. I have used multiple drives in the system and the same message appears. It occurs to me that there might be some issue with the disk drive itself providing SCSI termination, or some other jumper configuration error. Alternatively, doe this message imply that I can only use either the AIC-7860 or the AIC-7880 but not both? I might try unplugging the CD-RW before booting this evening. nope, again, ahc0 and ahc1 are two different devices, if it is whining about X, the problem is with X. Probably. :) As I recall, there are some variants of the Adaptec cards that use the ahc(4) driver that are kinda...curious. I think it is the 29160 (or some variant) which has both LVD U160 and a single-ended U2, plus a 50 pin connector...and the rule is, you can use two of the three connectors, but not all three at the same time. I may be misremembering this...it might involve the external connector on the spine of the card, rather than the 50 pin connector. But the rule was..only two of the connectors. And note: it's the connectors in use, not the number of devices attached. As I recall, all it can do is look for terminators. If it finds more terminators than it expects, it apparently sets a whine flag that the driver looks for. Are there any extra terminators on the system? You indicate the cable has a terminator...could the drive also be terminated? Also make sure any unused SCSI connectors are just left unconnected. Otherwise...if everything is correct, and performance is appropriate, don't worry about it...probably a quirk in implementation on this machine. I don't recall ever seeing any ability to see messages like this under Windows, so I suspect HP may have been a little sloppy about how they implemented things. Nick. --- dmesg included --- OpenBSD 3.9 (GENERIC.MP) #598: Thu Mar 2 02:37:06 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 300 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real mem = 536453120 (523880K) avail mem = 482435072 (471128K) using 4278 buffers containing 26927104 bytes (26296K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(a1) BIOS, date 10/28/98, BIOS32 rev. 0 @ 0xfd77d apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xfd710/0x8f0 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/192 (10 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x4800 mainbus0: Intel MP Specification (Version 1.4) (HP XU/XW ) cpu0 at mainbus0: apid 1 (boot processor) cpu0: apic clock running at 66 MHz cpu1 at mainbus0: apid 0 (application processor) cpu1: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 300 MHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type ISA ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443LX AGP rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82443LX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 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 Intel 82371AB PIIX4 ISA rev 0x01 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: MATSHITA, CD-ROM CR-585, ZP18 SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 0, DMA mode 1 pciide0: channel 1 ignored (disabled) uhci0 at pci0 dev 7 function 2 Intel 82371AB USB rev 0x01: apic 2 int 19 (irq 11) usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2
Re: latest sendmail patch
Monah Baki wrote: Hi all, I'm trying to apply the latest patch for sendmail and on my make, I get the following error: ... OpenBSD 3.9-current (GENERIC) #685: Mon Apr 10 14:00:41 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC Patches are for RELEASE. Not -current. You are running a -current, so you are committed to running -current, your (only) option is to upgrade to the most recent snapshot...which will have the fix, and you won't have to compile anything. Nick.
Re: latest sendmail patch
Nick Holland wrote: Monah Baki wrote: Hi all, I'm trying to apply the latest patch for sendmail and on my make, I get the following error: ... OpenBSD 3.9-current (GENERIC) #685: Mon Apr 10 14:00:41 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC Patches are for RELEASE. Not -current. You are running a -current, so you are committed to running -current, your (only) option is to upgrade to the most recent snapshot...which will have the fix, and you won't have to compile anything. eh... In *this case*, there are other options. But I'm not going to detail those. I don't like special cases... especially when it might encourage people to do things wrong and think they got away with it. Nick.
Re: Errors with IDE DMA beyond FAQ 14.11
[from a few days ago] Chris Smith wrote: I am a n00b. you missed: http://www.openbsd.org/faq/faq2.html#Bugs ... The system still chokes with a DMA timeout after ~30mins of heavy stuff (I was compiling /usr/ports/x11/gnome as something I knew would take forever). Is this a self-inflicted wound?: possibly, though sounds like a bug. However, lack of dmesg and precise messages/symptoms leaves doubt. OpenBSD is the only partition on wd0, and I hurried through the partitioning, basically chunking the disk evenly across /, /usr, /var, and /usr/x11 per the installation pamphlet. If I got the disk, I got to allocate it. Don't do that. Allocate what you need, and save the rest for later. Otherwise, you will spend lots of time watching your 99.9% empty partition fsck. Do you have ANY IDEA how big 300G is? Can you imagine how much paper tape it would take to back it up?? (years ago, when I first started working in the computer industry, a friend and I were drooling over the potential of a hard disk...and we asked that question. The endless hard disk in question? 10M. Hint: 10 bytes per inch on paper tape). Questions: a) Could naive partitioning on a fat IDE drive put enough latency into the system that a DMA timeout will inevitably happen? no. Not even sure what you are saying, but no. I have 500M partitions on 1T drives in production (three 500G drives in an Accusys RAID5 box). Works great. b) Should I punt and beg my wife for enough cash to replace the motherboard? possibly. Or a $30 add-on card that works better. Or $5 for a better cable. :) c) Given C/H/S values of 36481, 255, and 63 what would be a reasonable partition scheme for a home server box? (Failing that, pointers to previous discussion would be great). http://www.openbsd.org/faq/faq4.html#Partitioning However, your partitioning can be a problem without it being the problem you are complaining about. Nick.
Re: FYI SK(4) D-Link DGE-530T Rev B1 does not appear in dmesg.
[EMAIL PROTECTED] wrote: ... The dmesg with the B1 card only lacks the three appropriate lines which appear for the Rev A1 card when it is inserted in the same PCI slot: IF that is true, your card wasn't inserted properly. PCI cards show up. SOMETHING will show up...even if it isn't recognized. The only exceptions are if the card is behind a broken or unrecognized bridge. Nick.
Re: Doubts about OpenBSD security.
Bob Beck wrote: ... IMNSHO, a root password for single user makes the system *LESS* secure, and I'm dead serious. I would object to any attempt to commit changes to OpenBSD to have one by default. Why? Real simple: *because you asked this question*. - Now I'm not just crapping on you, every new sysadmin I know asks this. The point is, if OpenBSD put a root password on single user, you might be tempted to think that somehow, someway, a not-physically secured machine was secure, and be tempted to deploy it that way. And don't laugh, I've seen the assumption made (I work at a university). My point is that putting security measures in place that do not do anything because of equivalent access make people believe that they *do* do something, and therefore people make incorrect assumptions and do things insecurely. Physical access is everything highness. Anyone who says differently is selling something. -Bob Here's another example: My boss feels that it is important that he have a list of administrative passwords to all servers in our company. Now, call me no fun, but the idea of a password for the perimeter security firewalls sitting in an Excel spreadsheet on a laptop he selected because it was small and expensive and he likes to carry around to impress people scares the hell out of me..and thus, the PWs are not there. Now, he's got a point...yes, we have multiple administrators, but we are friends outside of work, so we are not infrequently in the same place at the same time, so the possibility of us both being killed in the same Celtic Music Riot or explosion of the same Mongolian Grill can't be discounted. If something happens to both of us, someone will need to be able to get into those systems. So...I just wrote up and showed him (and had him try) the lost my PW process in the FAQ, and had him force the root PW. And he was satisfied (other than the look on his face that seemed to be slightly pissed that I was denying him something he wanted, even though he knows I satisfied the goal of the demand he made). NOW...if we had something that had some kind of master password that was required even with physical access, we'd probably have to have either created an unused account for him (bad idea) or recorded a master password on his magic Excel spreadsheet (another bad idea). I don't think that would have improved security one bit. Sometimes, you got to make it easy to get in in a controlled way to make it harder for the wrong people to get in in a less controlled way. Nick.
Re: Crashes and HDD params
Przemys3aw Pawe3czyk wrote: Hi, How to change HDD parameters like this: wd1 at pciide0 channel 1 drive 0: FUJITSU MPD3084AT wd1: 16-sector PIO, LBA, 8063MB, 16514064 sectors wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 to get rid off the crashes I register several times a day? With very bad results on my files. What parameters are you trying to change? Why do you think it will have ANYTHING to do with fixing your crashes? The disk's parameters are what they are. The disk knows what they are, the OS asks, the disk responds. The OS reports and utilizes them. Other than the DMA and PIO modes, there isn't much to change. Yes, crashes are bad on lots of things. Altering the disk parameters is bad in much the same way...you will just add problems, not fix them. Nick.
Re: FYI SK(4) D-Link DGE-530T Rev B1 does not appear in dmesg. (SOLVED)
[EMAIL PROTECTED] wrote: Quoting [EMAIL PROTECTED]: Quoting Nick Holland [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: ... The dmesg with the B1 card only lacks the three appropriate lines which appear for the Rev A1 card when it is inserted in the same PCI slot: IF that is true, your card wasn't inserted properly. I tried it in all the other slots and neither OpenBSD nor Windows detected it. PCI cards show up. SOMETHING will show up...even if it isn't recognized. The only exceptions are if the card is behind a broken or unrecognized bridge. I tried it in a different PC and the card was shown in the dmesg as a DGE-560T_2. So it seems that first PC is a quirky one. Sorry about the bogus FYI. ah. ok...there's a reason why a PCI card won't show up, which I have experienced, but forgot about... Apparently, some newer cards require PCI2.2 spec, and many machines of your vintage (PII) are only PCI2.1. I should have remembered this, once spent many hours trying to figure out why a PCI wireless card (wi(4) based) didn't show up on the vast majority of the machines I have...finally found one computer that it worked in...the second newest, fastest machine I had (ok, I got a lotta old junk). Kinda a special case of incompatible PCI bridge, sorta, kinda. Nick.
Re: Partitions
John Brahy wrote: ... and over time I have learned to appreciate these, but lately I have been creating more partitions /usr/src /usr/obj are two of the ones that are suggested when rebuilding my system and I definitely like the speed of doing a newfs to /usr/obj Certainly handy. On the other hand...I pretty much build by script files now, so I'm not waiting for the rm -r /usr/obj/* step anyway...just start and walk away for anywhere from an hour to a week. :) I also have been putting mysql on it's own partition and then I got a little crazier and added more partitions and my list has grown to this: / /home /tmp /var /var/mysql /usr /usr/local /usr/src /usr/obj /usr/Xbld /usr/XF4 /usr/local /virtualhosts So am I going overboard? or am I missing any good partions. yes, I'd say you are going a bit overboard. On the other hand, you can make a case for most of the examples you list under some circumstances, and I don't see any Blatently Bad ones (here are some Bad Examples: /usr/X11R6, /root /etc), though I can't think of any benefit to src or XF4 on separate partitions (though I do have an NFS src directory on my mvme88k, due to 4G not being nearly enough to build on anymore)...nor do I see any real-life benefit to a /usr/local partition. I also would not guess that you would be doing much building in /usr/src on the same system you had that was so busy you put mysql on its own partition...so again, just because you can make a case for a separate partition on system X doesn't mean every system will see any benefit from that same partition. when I first posted Nick Holland replied with several reasons to have multiple partions. Those being security, fragmentation, protecting the filesystem from overfilling, organization and space tracking. I think I over-convinced you. :) does increasing the amount of partitions increase access to the files on that partition? Not sure I know what you mean by this... It COULD increase access time if you have partitions which are commonly being used together at opposite ends of the disk -- for example, perhaps src and obj, or src and /usr (where the compiler and libraries are), though if speed really matters that much to you, get more disks. Any feedback would be appreciated. As with most things in life, ask why, don't just do by formula. There are still some cases where the / and swap solution fits for testing, even though I now use it rarely (though I've wished I did a couple times!). A long time ago, I had a nice little webserver set up, then my friend Henning said, Here, try this chroot'ed Apache patch...which absolutely hosed my grand plans, as my /var partition was too small, as all the web documents were served from /home/user directories. You may note the warnings about this in the FAQ are perhaps a little over-emphasized... if you read the FAQ carefully, you can sometimes guess when something has bitten me personally. :) There are other reasons I've since found for partitioning, however...data partitions have become my favorite lately. MULTIPLE data partitions, in fact. And yes, multiple data partitions for one application. Here's why: if your application can be forced to split data across multiple partitions, it can be easily expanded later. SO...you can start out with a 200G drive today, in a year add a 700G drive, and not have to migrate everything from one to the other (btw: it takes a long time for even a fast machine to migrate 200G of data). It also means if something goes Horribly Wrong on one partition or drive, you can (probably) get away with recovering only that one partition from backup. Just had that happen to me this week -- E-mail archive system with well over 1T of data blew out one of its drives in a most spectacular way (short across the power supply pins), blowing out a power supply and a RAID box in the process. So..the survivors of this drive set had to be migrated to a spare RAID box, and then I made an error -- I missed the fact that the new box was set for RAID0 rather than RAID5, so after I beat on it a bit, it finally gave in and did what I apparently told it to: initialized the remaining data to zeros. So, off to the backups we went. FORTUNATELY, this system had several drive modules, and the one that failed (fortunately again!) was the least full of the bunch, so I only had 40 or so days of restore to do. I'm rather glad the other nine months of data in the thing escaped injury! Even if the same event happened on one of the other storage modules, it wouldn't have been as catastrophic as if I had it all in one pile. Related reason: in the case of partitions that fill with data, then you move on to another, you can remount the filled partitions as RO, so if, for example, a disk tosses a dead short across the power supply and you have 2T of storage suddenly lose power, you don't have to fsck the entire 2T, just the part that was mounted RW
Re: openwebmail with chrooted apache
FTP wrote: I installed openwebmail from the ports and when trying to launch: http://your_server/cgi-bin/openwebmail/openwebmail.pl I get a 500 error. I suppose that this is due to the chrooted apache but how do I find the dependencies for a perl script? 1) you think really hard about what a program does and how it does it. * It runs as setuid root, so it can jump to any logged in user to fetch their mail. (hint: chrooting a suid root program is kinda pointless) * It accesses /var/mail (can't recall if directly or via pop3) * It accesses Sendmail binary directly (another setuid root program). * it accesses /home/* directly (that's from memory, from a few years back's version. I suspect there is a lot more. Some details may have changed, including my memory) 2) you think really hard about how much of the system you would have to pull into the chroot to do what you want. * Too much dangerous stuff...and much of the file system. The benefit of chrooting is mostly lost. 3) Decide if the effort is worth it. * No, it isn't IN THIS CASE. Give it up. See the last sentence in: http://www.openbsd.org/faq/faq10.html#httpdchroot OpenWebmail is one of these apps. Making it work in a chroot would require a major rewrite and restructure, not simply copying files over...then you STILL have to trust the mechanism used to do those root-like things. (contrast this to Squirrelmail, which does (amazingly) run in a chroot relatively easily...but then, Squirrelmail uses an IMAP server to move your mail data around...so instead of worrying about a hole in Apache or the web-app, you have to worry about a hole in your IMAP server) Nick.
Re: openwebmail with chrooted apache
FTP wrote: On Mon, Jul 03, 2006 at 08:49:03PM +0200, Sigfred Heversen wrote: Stuart Henderson wrote: On 2006/07/03 13:52, Nick Holland wrote: (contrast this to Squirrelmail, which does (amazingly) run in a chroot Same for Hastymail and Roundcube. I guess it's not too much of a stretch with IMP either (though I haven't actually used IMP recently enough to have checked chroot). In tree mail/imp depends on devel/horde that has exploit(s) in the wild. /Sigfred I had a look on IMP and looks fine to me cause you can have POP3 too as well. I actually dodn't intend to isntall an IMAP server. Using IMP to avoid an IMAP server is like cutting off your hands because you don't wish to trim your fingernails. A Bit Drastic, I do think. And similarly crippling, as IMP is less than 100% effective without IMAP, apparently: http://www.horde.org/imp/docs/?f=INSTALL.html IMAP is recommended over POP3 in order to let users maintain mail folders other than INBOX and is required to allow messages to be flagged. IMAP is also much faster than POP3 in displaying a mailbox of messages. In short, do not use POP3 unless IMAP is not available. If you want IMP, IMAP is the least of your tasks. I think once you have IMP configured, you will forget that IMAP was even involved. As a result is IMP a good solution for a small e-mail server? I've never got IMP all the way running...but I very quickly came to the conclusion that small and IMP or any other Horde-based product have nothing to do with each other. That's not to say that IMP isn't a (potentially) cool product, and I'd like to come back to it, but the setup and config is much more involved than I'd find justified for a small e-mail server. OpenWebmail is very charming because of how very little it needs to bring into base OpenBSD to get working. I set it up for a school of about 200 students on a PII-450, worked well (once I set up MASSIVE amounts of swap space...having 25 students change their PWs at the same time burned through something like 600M of RAM+swap very quickly...swap-to-file to the rescue!). I must say, at this point, being not written in PHP is starting to look Really Nice, too. Nick.
Re: Preventing password reuse
Rod.. Whitworth wrote: ... Test with well known cracker tools and weep. I have (as root) fed a slice of master.passwd to John the Ripper with a few nologin users added using dictionary words of 7 or 8 chars as passwords and after 10 days it had not cracked one of them. I bet it takes less time on lesser hashes to get some results. actually, I've had somewhat different results using ports/security/crack to look at how people entered a system. A PII-450 was able to find an eight-letter dictionary PW (which was a particularly bad choice for a root PW) in a day or two, and at least one other trivial PW as well. So there is potentially some difference in the tools used. Nick.
Re: openwebmail with chrooted apache
FTP wrote: ... bottom line, your suggestion is to stick with openwebmail (if I don't want to intsall IMAP) and run 'insecure' apache? Would that be a 'good' solution for a small e-mail server? MY suggestion..yes. Reasonable people may (and probably will) have differing opinions. Here's a better idea: why don't you grab a bunch of different solutions and try 'em out? Don't trust us, make your own decision. Keep the Big Picture in mind... Yes, it's the insecure use of apache, but this eliminates a bunch of other programs that would have to do the same thing, creating similar potential holes, anyway. Nick.
Re: Upgrading questions
Rob Baldassano wrote: I have been running OpenBSD 3.6 since the day it came out, and am now in need up going to 3.9 The question is: What upgrade issues have folks run into? Very few, myself. I've got at least one machine running which started out with OpenBSD 3.1, and has been remotely upgraded to 3.9, and will be to 4.0 (unless I replace it for other reasons, and as it is a P1, there is a lot of merit to doing so) (and yes, the upgrade over the 3.3 - 3.4 ELF conversion was darned scary, but done without a trip to the box). I'm running it on a DELL desktop. you realize that doesn't help much, right? However, I've found few desktop Dell machines that have difficulty with OpenBSD, and can't think of any reason why a machine that ran 3.6 fine would do anything other than run 3.9 at least as well (and likely, better). BTW, some of the reasons I want to upgrade: ... you missed the important reasons. A biggie being that 3.6 is no longer supported by security patches. You do need to upgrade. Whether that means start over and reload from scratch, or follow the upgrade process, that's for you to decide, but you need to stop running 3.6 and start running 3.9. So... Any hints, pitfalls, suggestions that people have run into before? in general is it safe to do an Upgrade? a former co-worker says NO don't do that, never trust upgrades. I tend to disagree. On most systems, upgrades work Just Fine. On the other hand...you haven't upgraded this machine in three releases, so you have a bit of work to do (three separate upgrade processes). Some thoughts, mostly without conclusions: * If your disk layout is perfect, or at least sufficient, upgrade, don't reload. If the disk layout turned out to be wrong, good time to fix it with a reload, rather than upgrade. (warning: your /usr partition will grow by a huge amount for 3.9, 'specially if you have to build -stable from source on this machine). * New applications may need a new disk layout. On the other hand, you may not know what that disk layout should be until after you are testing. * Disk is cheap. Buying a new disk, install fresh and test on that. If things go right, you are done, if they go wrong, you can easily revert to your existing config until you figure out what went wrong. * Used computers that run OpenBSD well for many apps are also cheap...you could just swap out the whole machine...downtime measured in minutes, and a fully tested replacement at that (and very fast reversion if your testing sucks)... Granted, you mentioned Java...so this may not apply. * Look at why you have rejected the advice about keeping your machine up-to-date with a supported version of OpenBSD (recommended upgrades every six months, no less frequently than annually). Fix that. * If you have installed a lot of software without the packages mechanism, you may have stuff all over the place that you have no idea how to get rid of. * In your case, you will end up dumping all your installed packages due to the 3.6-3.7 compiler upgrade. Not that this is bad, your installed packages usually need to be updated more critically than the base system anyway, but something to be aware of. It does give you a chance to say, THIS is what I want on the system, and not that. As for your co-worker's advice about not doing upgrades, he's wrong. Of course, there is some risk of doing anything to a running system, but there is also a risk to doing nothing. You need to have the systems in place to contain the risk of doing the upgrades, so that when there is a security hole which turns out to be important, you can IMMEDIATELY and without issue implement a practiced and understood process, not a oh, sh*t, now what do we do?. The upgrade process must be part of your plans. Nick.
