Re: Request for links to BSD adminstration docs
J.C. Roberts wrote on Fri, Mar 23, 2007 at 06:36:34AM -0700: On Thursday 22 March 2007 22:08, Darrin Chandler wrote: On Fri, Mar 23, 2007 at 12:40:48AM -0400, Douglas Allan Tutty wrote: Do you run the rebuild niced? I don't. I want it to be done as soon as possible. This makes very little sense to me. Nice is not designed for wasting CPU cycles or something. As long as no other processes are competing for cpu time, nice does little harm, as far as i know. If you want your build done as soon as possible, then you would use nice(1) as root to have the build process run at a higher priority and hence receive more processing time. # nice -n -20 make build Is building at maximum priority, or even higher priority, a smart thing to do? -I don't know. I think that's a bad idea. Sometimes, you need to log in during the build, checking top(1), systat(1), tail(1)ing logs and the like. You want good interactive system response for that. If you want to finish the build quickly, just refrain from running bloatware like kde and openoffice and firefox and thunderbird while you are about it, in particular in case you are short on memory. But do not try to make time longer or generate additional cpu cycles or whatever. It won't work, not even by negative nice(1) incantations. Besides, remember that the default settings tend to be sane for standard applications. Fiddling with random knobs is not recommended unless you have very special needs.
Re: Request for links to BSD adminstration docs
On Thursday 22 March 2007 22:08, Darrin Chandler wrote: On Fri, Mar 23, 2007 at 12:40:48AM -0400, Douglas Allan Tutty wrote: Sounds similar to debian which also has to reboot a new kernel. Do you run the rebuild niced? I don't. I want it to be done as soon as possible. If you want your build done as soon as possible, then you would use nice(1) as root to have the build process run at a higher priority and hence receive more processing time. # nice -n -20 make build Is building at maximum priority, or even higher priority, a smart thing to do? -I don't know. But I can say the examples in the release(8) man page suggest *lowering* the priority and hence receive less processing time -- the default operation of nice(1) is to lower priority. # nice make build which is equivalent to # nice -n 10 make build The range of numbers used with nice(1), from 20 to -20, are somewhat counter intuitive since (positive) 20 is the lowest priority and (negative) -20 is the highest priority. If you're using csh(1), the syntax for nice(1) is different because it's built into the shell -- see the BUGS section of the nice(1) man page. But of course, building the system with anything other than the default shell, ksh(1), is unsupported. As for the wisdom and/or reasoning of lowering the priority of the build as suggested in release(8), I would guess it has something to do with the pain the developers endure when building releases on very slow archs where the source tree is mounted read only via nfs over very slow network connections (i.e vax). -It's just a guess and may be wrong. Kind Regards, JCR
Re: Request for links to BSD adminstration docs
On 3/23/07, Douglas Allan Tutty [EMAIL PROTECTED] wrote: Thanks for your suggestions re used books. I'll try some of Kingston's used book stores and see what I can get at the Queen's book store. You can also check Amazon.com. For example used copy of Absolute OpenBSD costs less than 15 bucks there. Andrey
Re: Request for links to BSD adminstration docs
J.C. Roberts [EMAIL PROTECTED] writes: as suggested in release(8), I would guess it has something to do with the pain the developers endure when building releases on very slow archs It's always better to run batch processing with nice. The only reason is not to affect normal work on the machine. This of course implies that it doesn't make sense to use nice when the machine is only doing this one lengthy job. Darrin Chandler [EMAIL PROTECTED] writes: run the rebuild niced? I don't. I want it to be done as soon as possible. This doesn't give you much. But it may hurt responsiveness of your system as a whole. Regards, Frank
Re: Request for links to BSD adminstration docs
On Fri, Mar 23, 2007 at 12:07:54AM -0500, Marco Peereboom wrote: However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Minutes on a fast machine. I have seen a HPPA B180 take like 25 minutes but that is the exception and not the norm. The OpenBSD man pages are outstanding. Start with the FAQ and then move on to the man pages and life will be good. How does an HPPA B180 compare with a 486? I think I'll see if I can download the manpages separatly and view them with debian's groff (or more simply, with Midnight Commander). Thanks, Doug.
Re: Request for links to BSD adminstration docs
On Thu, Mar 22, 2007 at 10:08:02PM -0700, Darrin Chandler wrote: On Fri, Mar 23, 2007 at 12:40:48AM -0400, Douglas Allan Tutty wrote: However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Yes, you must reboot and perform the upgrade. If you read the upgrade guide and get your ducks in a row you can be all done *easily* in 30 minutes. If there were some kind of contest with cash prizes it could probably be done much quicker. However, it's much more important to get the steps right than to do it quickly, IMHO. So on a production machine, it has to be off-line for 30 minutes every six months (not complaining, just clarifying). history you can pick up some interesting bits around the net. The Wikipedia pages on this aren't as bad as they could be. http://en.wikipedia.org/wiki/OpenBSD http://en.wikipedia.org/wiki/Berkeley_Software_Distribution I've read them and they seem like a good introduction. I'd like to track down the origional BSD SMM (assuming that it was released under a BSD licence), from before it was printed by O'Reily and hense copywritten. Thanks Doug.
Re: Request for links to BSD adminstration docs
Hi Douglas, Just bumping into this thread. So on a production machine, it has to be off-line for 30 minutes every six months (not complaining, just clarifying). Basically, yes. But, that would mean no patches applied to your production system during those six months. If you were to build a new release(8) any time -stable changes (and you should), then it'd be more. Any update between upgrades takes significantly less time than an upgrade. HTH... Nico
Re: Request for links to BSD adminstration docs
On Friday 23 March 2007 8:30 am, Douglas Allan Tutty wrote: On Thu, Mar 22, 2007 at 10:08:02PM -0700, Darrin Chandler wrote: On Fri, Mar 23, 2007 at 12:40:48AM -0400, Douglas Allan Tutty wrote: However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Yes, you must reboot and perform the upgrade. If you read the upgrade guide and get your ducks in a row you can be all done *easily* in 30 minutes. If there were some kind of contest with cash prizes it could probably be done much quicker. However, it's much more important to get the steps right than to do it quickly, IMHO. So on a production machine, it has to be off-line for 30 minutes every six months (not complaining, just clarifying). Or every year since the previous release version is also supported. For example, if you installed 3.9 last year you don't have to worry about upgrading until 4.1 comes out. -- Tim Kuhlman Network Administrator ColoradoVnet.com
Re: Request for links to BSD adminstration docs
On Fri, Mar 23, 2007 at 06:36:34AM -0700, J.C. Roberts wrote: I don't. I want it to be done as soon as possible. If you want your build done as soon as possible, then you would use nice(1) as root to have the build process run at a higher priority and hence receive more processing time. # nice -n -20 make build I shouldn't EVER use absolute terms ;) On the boxes I deal with (from old slooow, to pretty darned fast) I'm happy to let the build process run as is. None of my production machines are close to the edge on performance, and continue to be responsive enough during builds. Having watched top friends during builds I don't think I'd get much out of nicing -20 except for worse performance on the production services. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Request for links to BSD adminstration docs
On Fri, Mar 23, 2007 at 10:30:43AM -0400, Douglas Allan Tutty wrote: Yes, you must reboot and perform the upgrade. If you read the upgrade guide and get your ducks in a row you can be all done *easily* in 30 minutes. If there were some kind of contest with cash prizes it could probably be done much quicker. However, it's much more important to get the steps right than to do it quickly, IMHO. So on a production machine, it has to be off-line for 30 minutes every six months (not complaining, just clarifying). In practice it should be less than that. But yes, following the normal process you will have downtime/reboots every six months for upgrading. If you search the archives for this list, you'll find WAY TOO MUCH discussion about uptime and rebooting. I'll condense it for you: it's OK to reboot and 'ruin' your uptime for scheduled maintenance. Bragging about uptime means your system is unpatched. If you have critical systems that can't be down for upgrades, then you need redundant servers anyway. In which case you upgrade one at a time. ;) -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Request for links to BSD adminstration docs
On 3/23/07, Douglas Allan Tutty [EMAIL PROTECTED] wrote: On Fri, Mar 23, 2007 at 12:07:54AM -0500, Marco Peereboom wrote: However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Minutes on a fast machine. I have seen a HPPA B180 take like 25 minutes but that is the exception and not the norm. The OpenBSD man pages are outstanding. Start with the FAQ and then move on to the man pages and life will be good. How does an HPPA B180 compare with a 486? I think I'll see if I can download the manpages separatly and view them with debian's groff (or more simply, with Midnight Commander). Or http://www.openbsd.org/cgi-bin/man.cgi Greg
Request for links to BSD adminstration docs
Hello, I'm considering moving my 486 from Debian to OpenBSD. I haven't the money to spend on a new e.g. UNIX System Administration. 4.4 BSD System Manager's Manual is out of print. I haven't been able to google anything freely available on the internet. My local library has had their only UNIX book stolen (not by me). Since BSD came from a university, did they ever publish under the BSD licence a SMM, and if so is it avilable free anywhere? Is there a BSD repository of free documents similar to IBM's for AIX? I've got the basic Linux CLI admin skills. What I'm looking for is indoctrination into the BSD way of doing things and the wisdom behind it. I'm looking for a bit of the historical culture; the wisdom of ages past. As a simple example. I'm used to Debian where updates can happen without disturbing users (clones of myself mostly). On a new fast box, one can build a patch in a short time, but then the system has to be brought down, install the patch, then bring it back up. In years past, how did a sysadmin with one VAX handle that? Take the computer off line at 1700, do the build, install, and hope to have everything back up by 0800? I figure that if I get an old BSD book and combine it with the OpenBSD FAQ plus man pages, I'll be off to a good start. I'm not, as someone here referred to themselves as, an old fart. I'm not _that_ old (40), but I don't want a book that starts off Click on I wouldn't mind one that starts Turn on your terminal and hit enter. Thanks, Doug.
Re: Request for links to BSD adminstration docs
On 3/22/07, Douglas Allan Tutty [EMAIL PROTECTED] wrote: I figure that if I get an old BSD book and combine it with the OpenBSD FAQ plus man pages, I'll be off to a good start. If you know your way around Linux just start with the FAQ and manpages. That's what I started with and the FAQ is even better now than when I started. You can supplement with the books at the top of this page: http://openbsd.org/books.html when you feel like delving deeper. Greg
Re: Request for links to BSD adminstration docs
On Thu, Mar 22, 2007 at 11:30:06PM -0400, Douglas Allan Tutty wrote: Hello, I'm considering moving my 486 from Debian to OpenBSD. I haven't the money to spend on a new e.g. UNIX System Administration. 4.4 BSD System Manager's Manual is out of print. I haven't been able to google anything freely available on the internet. My local library has had their only UNIX book stolen (not by me). Since BSD came from a university, did they ever publish under the BSD licence a SMM, and if so is it avilable free anywhere? Is there a BSD repository of free documents similar to IBM's for AIX? I've got the basic Linux CLI admin skills. What I'm looking for is indoctrination into the BSD way of doing things and the wisdom behind it. I'm looking for a bit of the historical culture; the wisdom of ages past. As a simple example. I'm used to Debian where updates can happen without disturbing users (clones of myself mostly). On a new fast box, one can build a patch in a short time, but then the system has to be brought down, install the patch, then bring it back up. In years past, how did a sysadmin with one VAX handle that? Take the computer off line at 1700, do the build, install, and hope to have everything back up by 0800? I figure that if I get an old BSD book and combine it with the OpenBSD FAQ plus man pages, I'll be off to a good start. Since you've already found the FAQ, you've got a good start. Add the Books that help page. If you don't have much money to spend, look for them used. I've got both Building Firewalls with OpenBSD and PF by Jacek Artymiak, and Secure Architectures with OpenBSD by Palmer and Nazario. Both are good, both walk you through quite a bit from installing to typical administration, and a bit of history thrown in. Though I knew most of what was in both books, I learned more than a few things I'm glad to know. As for your simple example above, I've seen more than once someone talk about bringing a box down for extended periods to update. I just don't get that. It's easy enough to update sources or apply the patch and rebuild while the system is up. Sure, it can add a lot of load, but OpenBSD is fairly stable under load in terms of still serving web pages, or doing mail, etc. Then the only total downtime is during reboot if you've updated the kernel, or restart time on daemons if you've only updated userland. Last, but not least, check for a user group in your area! Also check out http://metabug.org/, where you can get streaming and recorded presentations (one coming in a week). -- Darrin Chandler | Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/darrin/ |
Re: Request for links to BSD adminstration docs
On Thu, Mar 22, 2007 at 09:00:01PM -0700, Darrin Chandler wrote: On Thu, Mar 22, 2007 at 11:30:06PM -0400, Douglas Allan Tutty wrote: I'm considering moving my 486 from Debian to OpenBSD. I haven't the money to spend on a new e.g. UNIX System Administration. 4.4 BSD System Manager's Manual is out of print. I haven't been able to google anything freely available on the internet. My local library has had their only UNIX book stolen (not by me). I figure that if I get an old BSD book and combine it with the OpenBSD FAQ plus man pages, I'll be off to a good start. As for your simple example above, I've seen more than once someone talk about bringing a box down for extended periods to update. I just don't get that. It's easy enough to update sources or apply the patch and rebuild while the system is up. Sure, it can add a lot of load, but OpenBSD is fairly stable under load in terms of still serving web pages, or doing mail, etc. Then the only total downtime is during reboot if you've updated the kernel, or restart time on daemons if you've only updated userland. Sounds similar to debian which also has to reboot a new kernel. Do you run the rebuild niced? However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Thanks for your suggestions re used books. I'll try some of Kingston's used book stores and see what I can get at the Queen's book store. Doug.
Re: Request for links to BSD adminstration docs
However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Minutes on a fast machine. I have seen a HPPA B180 take like 25 minutes but that is the exception and not the norm. Thanks for your suggestions re used books. I'll try some of Kingston's used book stores and see what I can get at the Queen's book store. The OpenBSD man pages are outstanding. Start with the FAQ and then move on to the man pages and life will be good.
Re: Request for links to BSD adminstration docs
On Fri, Mar 23, 2007 at 12:40:48AM -0400, Douglas Allan Tutty wrote: Sounds similar to debian which also has to reboot a new kernel. Do you run the rebuild niced? I don't. I want it to be done as soon as possible. However, is it correct that when a new release comes out every six months, you have to reboot into that? How long does an upgrade from one release to the next take? Yes, you must reboot and perform the upgrade. If you read the upgrade guide and get your ducks in a row you can be all done *easily* in 30 minutes. If there were some kind of contest with cash prizes it could probably be done much quicker. However, it's much more important to get the steps right than to do it quickly, IMHO. Thanks for your suggestions re used books. I'll try some of Kingston's used book stores and see what I can get at the Queen's book store. Not to take away from that, but if you're interested in learning BSD history you can pick up some interesting bits around the net. The Wikipedia pages on this aren't as bad as they could be. http://en.wikipedia.org/wiki/OpenBSD http://en.wikipedia.org/wiki/Berkeley_Software_Distribution -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
