Re: Perpetually Current
I'm also fairly new to OpenBSD. As I understand from this thread, having installed -current (4.4) from a snapshot CD, the easiest way to keep -current is to burn a subsequent snapshot to a CD and follow the upgrade process from there?
Re: Perpetually Current
On Sun, Nov 2, 2008 at 4:39 PM, Doug Milam [EMAIL PROTECTED] wrote: I'm also fairly new to OpenBSD. As I understand from this thread, having installed -current (4.4) from a snapshot CD, the easiest way to keep -current is to burn a subsequent snapshot to a CD and follow the upgrade process from there? I don't know if this is the recommended way or not, but I just download the bsd.rd (ramdisk) kernel for each successive snapshot, reboot, and use that downloaded bsd.rd kernel to perform an upgrade via ftp. Once the system is upgraded, I upgrade my packages -- having previously set PKG_PATH to point to the package snapshot directory. -- Chess Griffin GPG Public Key: 0x0C7558C3 http://www.chessgriffin.com
Re: Perpetually Current
On Sun, Nov 02, 2008 at 01:39:04PM -0800, Doug Milam wrote: I'm also fairly new to OpenBSD. As I understand from this thread, having installed -current (4.4) from a snapshot CD, the easiest way to keep -current is to burn a subsequent snapshot to a CD and follow the upgrade process from there? Boot bsd.rd and update, just make sure you select the snapshots dir. There are more ways to do it, however this one is fairly safe.
Re: Perpetually Current
Thanks; that's straightforward and refreshingly more direct than I thought. A hallmark of OpenBSD! * * http://milam.homeunix.net --- On Sun, 11/2/08, Tobias Ulmer [EMAIL PROTECTED] wrote: From: Tobias Ulmer [EMAIL PROTECTED] Subject: Re: Perpetually Current To: Doug Milam [EMAIL PROTECTED] Cc: Misc OpenBSD misc@openbsd.org Date: Sunday, November 2, 2008, 3:04 PM On Sun, Nov 02, 2008 at 01:39:04PM -0800, Doug Milam wrote: I'm also fairly new to OpenBSD. As I understand from this thread, having installed -current (4.4) from a snapshot CD, the easiest way to keep -current is to burn a subsequent snapshot to a CD and follow the upgrade process from there? Boot bsd.rd and update, just make sure you select the snapshots dir. There are more ways to do it, however this one is fairly safe.
Re: Perpetually Current
On Dec 27, 2007 11:17 AM, new_guy [EMAIL PROTECTED] wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. I have quite the same problem. my OBSD routers are usually old PII boxes and doing this kind of upgrade on them is not trivial. other, I have some remote routers I cant do this, so They run FBSD. I'd rather use OBSD on my routers, but this thing of not been able to make 4.1 become 4.2 without a cdrom (as is recommended) makes me use OBSD only in the closest routers. i'm not here to make comparissons from OSes, or to make trouble. I just felt that would be good to say that if anytime in OBSD this upgrade was possible it would be a great feature (well, at least for me an the new_guy :) ) :) matheus -- We will call you cygnus, The God of balance you shall be
Re: Perpetually Current
On Wed, Jan 02, 2008 at 01:42:01PM -0300, Nenhum_de_Nos wrote: I have quite the same problem. my OBSD routers are usually old PII boxes and doing this kind of upgrade on them is not trivial. other, I have some remote routers I cant do this, so They run FBSD. I'd rather use OBSD on my routers, but this thing of not been able to make 4.1 become 4.2 without a cdrom (as is recommended) makes me use OBSD only in the closest routers. i'm not here to make comparissons from OSes, or to make trouble. I just felt that would be good to say that if anytime in OBSD this upgrade was possible it would be a great feature (well, at least for me an the new_guy :) ) While it's not recommended the instructions for remote upgrading found in the installation guide work flawlessly. I've used those instructions on my colo boxes many times now. Nick doesn't just update them in the FAQ, he tests them. I will say this, though: read the instructions all the way through before doing anything. Make sure you understand what's going on. Then *follow* the instructions. Remotely upgrading without console really does work, and it's pretty quick. Try it some time on a machine you have physical access to, just so you can run through it and see for yourself. -- 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: Perpetually Current
* Nenhum_de_Nos [EMAIL PROTECTED] [2008-01-02 17:49]: On Dec 27, 2007 11:17 AM, new_guy [EMAIL PROTECTED] wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. I have quite the same problem. my OBSD routers are usually old PII boxes and doing this kind of upgrade on them is not trivial. other, I have some remote routers I cant do this, so They run FBSD. I'd rather use OBSD on my routers, but this thing of not been able to make 4.1 become 4.2 without a cdrom (as is recommended) makes me use OBSD only in the closest routers. i'm not here to make comparissons from OSes, or to make trouble. I just felt that would be good to say that if anytime in OBSD this upgrade was possible it would be a great feature (well, at least for me an the new_guy :) ) inline updates (i. e. without boot media) work just fine. the risk is a little higher, thus we don't recommend that method - which doesn't prevent you from doing it that way (I do) -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Perpetually Current
On Wed, Jan 02, 2008 at 01:42:01PM -0300, Nenhum_de_Nos wrote: On Dec 27, 2007 11:17 AM, new_guy [EMAIL PROTECTED] wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. I have quite the same problem. my OBSD routers are usually old PII boxes and doing this kind of upgrade on them is not trivial. other, I have some remote routers I cant do this, so They run FBSD. I'd rather use OBSD on my routers, but this thing of not been able to make 4.1 become 4.2 without a cdrom (as is recommended) makes me use OBSD only in the closest routers. i'm not here to make comparissons from OSes, or to make trouble. I just felt that would be good to say that if anytime in OBSD this upgrade was possible it would be a great feature (well, at least for me an the new_guy :) ) There has to be a way without CD. Can't you put the 4.2 rd kernel on the root filesystem and boot that then run the installer, pulling the install sets via ftp? I suppose for remote units you need some sort of remote shell (e.g. serial terminal via modem). Doug.
Re: Perpetually Current
On Wed, Jan 02, 2008 at 12:40:40PM -0500, Douglas A. Tutty wrote: There has to be a way without CD. Can't you put the 4.2 rd kernel on the root filesystem and boot that then run the installer, pulling the install sets via ftp? I suppose for remote units you need some sort of remote shell (e.g. serial terminal via modem). Or yaifo, which is essentially bsd.rd + sshd. Handy as hell if some form of console is not available, especially if you need to do something like reslice your disk. -- 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: Perpetually Current
Hi Matheus, Nenhum_de_Nos wrote on Wed, Jan 02, 2008 at 01:42:01PM -0300: my OBSD routers are usually old PII boxes and doing this kind of upgrade on them is not trivial. Saying this kind of upgrade, you refer to the official upgrade process, i presume? The official upgrade process is completely trivial on any imaginable kind of i386 Pentium II box, believe me. A Pentium II may seem old to you, but for running a standard router, it is more than enough, including the handling of the official upgrade process, of course. The dmesg of my own three-leg (internal/dmz/Internet) statefully filtering and NATing main router (saturating a 100 Mbit/s uplink, about 200 user accounts in the internel network, about 50 users regularly accessing us from the Internet, plus multiple web sites and mailing list hosting) is included below. Ya, i do have a couple of 600-900 MHz boxen on the shelf that people have been throwing away recently, so i could upgrade for free, but there's simply no need to hurry... About five years ago, i had to use an old 486-SX25, 24 MB RAM, Harddisk 160 MB (yes, zero dot one six Gigabytes) for the same task. With 16 MB of RAM, i saw occasional shortages of memory - although the users did not even notice that - but with 24 MB, even that crappy thing saturated our 100 Mbit/s uplink just fine. I just checked my notes, it was installed on May 13, 2001 with OpenBSD 2.8, upgraded to OpenBSD 2.9 on June 3, upgraded to OpenBSD 3.1 on June 22, 2002, upgraded to OpenBSD 3.2 on Jan 17, 2003. No, for those upgrades with 160 MB of total disk space, i could not use the official upgrade process, go figure... :-) But honestly, with any kind of Pentium II, what's your problem? All the best for the New Year, Ingo -- Ingo Schwarze [EMAIL PROTECTED] Serverbetrieb usta.de / studis.de - 8 - schnipp - 8 - 8 - schnapp - 8 - OpenBSD 4.2-current (GENERIC) #71: Tue Dec 4 02:15:05 CET 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD-K6tm w/ multimedia extensions (AuthenticAMD 586-class) 234 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,MMX real mem = 133787648 (127MB) avail mem = 121483264 (115MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 07/18/98, BIOS32 rev. 0 @ 0xfb480 apm0 at bios0: Power Management spec V1.2 (slowidle) apm0: AC on, battery charge unknown pcibios0 at bios0: rev 2.1 @ 0xf/0xb8f8 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdc40/128 (6 entries) pcibios0: PCI Exclusive IRQs: 10 11 15 pcibios0: PCI Interrupt Router at 000:07:0 (Acer Labs M1533 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Acer Labs M1541 PCI rev 0x04 agp0 at pchb0: aperture at 0xe000, size 0x100 ppb0 at pci0 dev 1 function 0 Acer Labs M5243 AGP/PCI-PCI rev 0x04 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 Acer Labs M1533 ISA rev 0xc3 rl0 at pci0 dev 8 function 0 Realtek 8139 rev 0x10: irq 15, address 00:e0:7d:93:13:e7 rlphy0 at rl0 phy 0: RTL internal PHY rl1 at pci0 dev 9 function 0 Realtek 8139 rev 0x10: irq 11, address 00:e0:7d:93:13:ea rlphy1 at rl1 phy 0: RTL internal PHY rl2 at pci0 dev 10 function 0 Realtek 8139 rev 0x10: irq 10, address 00:e0:7d:93:13:e6 rlphy2 at rl2 phy 0: RTL internal PHY pciide0 at pci0 dev 15 function 0 Acer Labs M5229 UDMA IDE rev 0xc1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: FUJITSU MPB3032ATU E wd0: 16-sector PIO, LBA, 3093MB, 6335280 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard vga0 at isa0 port 0x3b0/48 iomem 0xa/131072 wsdisplay0 at vga0 mux 1: console (80x25, vt100 emulation), using wskbd0 wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask 73fd netmask fffd ttymask softraid0 at root dkcsum: wd0 matches BIOS drive 0x80 root on wd0a swap on wd0b dump on wd0b
Re: Perpetually Current
On Jan 2, 2008 4:57 PM, Ingo Schwarze [EMAIL PROTECTED] wrote: Hi Matheus, Nenhum_de_Nos wrote on Wed, Jan 02, 2008 at 01:42:01PM -0300: my OBSD routers are usually old PII boxes and doing this kind of upgrade on them is not trivial. Saying this kind of upgrade, you refer to the official upgrade process, i presume? The official upgrade process is completely trivial on any imaginable kind of i386 Pentium II box, believe me. A Pentium II may seem old to you, but for running a standard router, it is more than enough, including the handling of the official upgrade process, of course. The dmesg of my own three-leg (internal/dmz/Internet) statefully filtering and NATing main router (saturating a 100 Mbit/s uplink, about 200 user accounts in the internel network, about 50 users regularly accessing us from the Internet, plus multiple web sites and mailing list hosting) is included below. Ya, i do have a couple of 600-900 MHz boxen on the shelf that people have been throwing away recently, so i could upgrade for free, but there's simply no need to hurry... About five years ago, i had to use an old 486-SX25, 24 MB RAM, Harddisk 160 MB (yes, zero dot one six Gigabytes) for the same task. With 16 MB of RAM, i saw occasional shortages of memory - although the users did not even notice that - but with 24 MB, even that crappy thing saturated our 100 Mbit/s uplink just fine. I just checked my notes, it was installed on May 13, 2001 with OpenBSD 2.8, upgraded to OpenBSD 2.9 on June 3, upgraded to OpenBSD 3.1 on June 22, 2002, upgraded to OpenBSD 3.2 on Jan 17, 2003. No, for those upgrades with 160 MB of total disk space, i could not use the official upgrade process, go figure... :-) But honestly, with any kind of Pentium II, what's your problem? All the best for the New Year, Ingo -- first of all I'd like to thank everyone that responded me in so short time. my problem is not running it, ingo. I do love my PII and they do just fine to keep my home lan security :) the problem for me is to take a cdrom, burn the iso, and have to do it not from a remote ssh window ;) but as many stated that it works, just have to be carefull about the steps :) I'll install a fresh 4.1 just to practice and walk through this process. thank you all for your attention :) I'm kinda new in OpenBSD, a user for about one year, but I already liked it :) I learned too much in this time :) thanks, matheus -- We will call you cygnus, The God of balance you shall be
Re: Perpetually Current
I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. This is how a lot of issues get debugged... I've stumbled across a lot of stuff by doing this. I pretty much only run some variation of -CURRENT on my prod boxes, but to be fair, I don't have all my eggs in one basket, so I can handle some breakage and downtime.
Re: Perpetually Current
On Dec 28, 2007 4:07 AM, Ingo Schwarze [EMAIL PROTECTED] wrote: [...] Keeping a system up to date involves manual work, either a little easy work for manual upgrades now and then, or lots of hard and scary work for building and maintaining an automatic system. You choose according to your skill, and according to your time budget... [...] The closest I have come to automation to stay -current is a small shell script run through cron, which pulls current.html and diffs it with a previous version. Any change, and it sends me an email so that I know I have to go and look at current.html. That's about it. As Ingo rightly mentions, full automation to stay -current is a very scary thought! -Amarendra
Perpetually Current
I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. Thanks, Brad -- View this message in context: http://www.nabble.com/Perpetually-Current-tp14513618p14513618.html Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: Perpetually Current
On Thu, Dec 27, 2007 at 04:07:00PM +0100, Henning Brauer wrote: The second problem are flag days, when something has changed such that you almost certainly want to reinstall the OS. The move from a.out to ELF binary format is a good example of that. ah yeah, and that happens every second week. reality check: how often does that happen really? the last real flag day on i386 was the a.out - ELF move. When was that? 3.3 I think. almost 5 years ago. I think the OP may have wanted something automated/scripted. While true flag days are rare, -current often has some steps to perform as listed on current.html. Since I've been following -current those steps have been simple and easy to perform, but -current isn't something you should do unattended from a cron job. -- 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: Perpetually Current
* STeve Andre' [EMAIL PROTECTED] [2007-12-27 15:43]: On Thursday 27 December 2007 09:17:37 new_guy wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. that will work fine as long as you keep an eye on current.html and maybe source-changes, it is what many of us do. There are two problems with what you are talking about. The first is that by its vary nature -current is a moving target, and there could be a time when upgrading to the latest -current for a security fix might introduce some new feature which you don't want. why wouldn't you want a new feature? we're being extremely careful to not break existing behaviour wherever possible. of course, that is not always possible, but exceptions are rare and well documented. The second problem are flag days, when something has changed such that you almost certainly want to reinstall the OS. The move from a.out to ELF binary format is a good example of that. ah yeah, and that happens every second week. reality check: how often does that happen really? the last real flag day on i386 was the a.out - ELF move. When was that? 3.3 I think. almost 5 years ago. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Perpetually Current
On Thursday 27 December 2007 09:17:37 new_guy wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. Thanks, Brad There are two problems with what you are talking about. The first is that by its vary nature -current is a moving target, and there could be a time when upgrading to the latest -current for a security fix might introduce some new feature which you don't want. In other words, you can't just apply patches to -current, you need to move to the lastest code. The second problem are flag days, when something has changed such that you almost certainly want to reinstall the OS. The move from a.out to ELF binary format is a good example of that. You should always have a fall back procedure in place too, but thats always the case. --STeve Andre'
Re: Perpetually Current
On Thursday 27 December 2007 10:07:00 Henning Brauer wrote: * STeve Andre' [EMAIL PROTECTED] [2007-12-27 15:43]: On Thursday 27 December 2007 09:17:37 new_guy wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. that will work fine as long as you keep an eye on current.html and maybe source-changes, it is what many of us do. There are two problems with what you are talking about. The first is that by its vary nature -current is a moving target, and there could be a time when upgrading to the latest -current for a security fix might introduce some new feature which you don't want. why wouldn't you want a new feature? we're being extremely careful to not break existing behaviour wherever possible. of course, that is not always possible, but exceptions are rare and well documented. I didn't express that well enough, I guess. How about a change, such as disks formerly showing up as wd but now sd? By problem, I mean something that has to be dealt with, not just insurmountable ones. The second problem are flag days, when something has changed such that you almost certainly want to reinstall the OS. The move from a.out to ELF binary format is a good example of that. ah yeah, and that happens every second week. reality check: how often does that happen really? the last real flag day on i386 was the a.out - ELF move. When was that? 3.3 I think. almost 5 years ago. Perhaps I'm wrong here, but I thought about every other release there was a change that was a flag day. I see that the upgrade faq doesn't have a history so I'd have to dig for it. Still, my point was they do happen from time to time so the idea of living on -current won't always work. As I read his posting, new_guy is getting the concepts down. Though they are few, flag days still need to be understood. --STeve Andre'
Re: Perpetually Current
On 12/27/07, new_guy [EMAIL PROTECTED] wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. What you probably want is to go the upgrade-every-6-months route. -Nick
Re: Perpetually Current
* STeve Andre' [EMAIL PROTECTED] [2007-12-27 16:42]: On Thursday 27 December 2007 10:07:00 Henning Brauer wrote: * STeve Andre' [EMAIL PROTECTED] [2007-12-27 15:43]: On Thursday 27 December 2007 09:17:37 new_guy wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. that will work fine as long as you keep an eye on current.html and maybe source-changes, it is what many of us do. There are two problems with what you are talking about. The first is that by its vary nature -current is a moving target, and there could be a time when upgrading to the latest -current for a security fix might introduce some new feature which you don't want. why wouldn't you want a new feature? we're being extremely careful to not break existing behaviour wherever possible. of course, that is not always possible, but exceptions are rare and well documented. I didn't express that well enough, I guess. How about a change, such as disks formerly showing up as wd but now sd? By problem, I mean something that has to be dealt with, not just insurmountable ones. that is one of those rare changes, and it is well documented. The second problem are flag days, when something has changed such that you almost certainly want to reinstall the OS. The move from a.out to ELF binary format is a good example of that. ah yeah, and that happens every second week. reality check: how often does that happen really? the last real flag day on i386 was the a.out - ELF move. When was that? 3.3 I think. almost 5 years ago. Perhaps I'm wrong here, but I thought about every other release there was a change that was a flag day. nope. we sometimes have mini-flagdays. they usually only affect people building from source. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Perpetually Current
On Thursday 27 December 2007 10:46:26 Henning Brauer wrote: * STeve Andre' [EMAIL PROTECTED] [2007-12-27 16:42]: On Thursday 27 December 2007 10:07:00 Henning Brauer wrote: * STeve Andre' [EMAIL PROTECTED] [2007-12-27 15:43]: On Thursday 27 December 2007 09:17:37 new_guy wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. I understand the implications of being current and that things might change and break and may need re-configuring on occasion. I'm OK with that... I just don't want to reinstall a -release every year... although I'll still buy CDs as they are released to support the project. that will work fine as long as you keep an eye on current.html and maybe source-changes, it is what many of us do. There are two problems with what you are talking about. The first is that by its vary nature -current is a moving target, and there could be a time when upgrading to the latest -current for a security fix might introduce some new feature which you don't want. why wouldn't you want a new feature? we're being extremely careful to not break existing behaviour wherever possible. of course, that is not always possible, but exceptions are rare and well documented. I didn't express that well enough, I guess. How about a change, such as disks formerly showing up as wd but now sd? By problem, I mean something that has to be dealt with, not just insurmountable ones. that is one of those rare changes, and it is well documented. The second problem are flag days, when something has changed such that you almost certainly want to reinstall the OS. The move from a.out to ELF binary format is a good example of that. ah yeah, and that happens every second week. reality check: how often does that happen really? the last real flag day on i386 was the a.out - ELF move. When was that? 3.3 I think. almost 5 years ago. Perhaps I'm wrong here, but I thought about every other release there was a change that was a flag day. nope. we sometimes have mini-flagdays. they usually only affect people building from source. Thats my point: running -current means building from source and thus being affected.
Re: Perpetually Current
* STeve Andre' [EMAIL PROTECTED] [2007-12-27 17:31]: Thats my point: running -current means building from source and thus being affected. huh? not at all. you use snapshots of course. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Perpetually Current
On Dec 27 06:17:37, new_guy wrote: I would like to install OpenBSD *once* and keep it patched and secured for many years there after (5 - 7 years) in a production environment. That's what upgrades are for. Would it be feasible to get a snapshot today and follow -current for many years w/o having to reinstall? Basically, this approach would skip -stable and -release and always be -current. You would just use the snaphots. Is that reinstalling for you? I understand the implications of being current and that things might change and break and may need re-configuring on occasion. So why do you want to use it in production? I'm OK with that... I just don't want to reinstall a -release every year... That's about one hour of work twice a year - what's wrong with that? Why do you want to stay -current? What problem are you trying to solve, or what are you trying to achieve by doing that? Jan
Re: Perpetually Current
On Dec 27, 2007 8:35 AM, Henning Brauer [EMAIL PROTECTED] wrote: * STeve Andre' [EMAIL PROTECTED] [2007-12-27 17:31]: Thats my point: running -current means building from source and thus being affected. huh? not at all. you use snapshots of course. STeve understands that but I don't think the original poster does. Greg -- Ticketmaster and Ticketweb suck, but everyone knows that: http://ticketmastersucks.org Obsession in the low desert: http://lodesertprotosites.org Dethink to survive - Mclusky
Re: Perpetually Current
On Dec 27, 2007 10:47 AM, Jan Stary [EMAIL PROTECTED] wrote: That's about one hour of work twice a year - what's wrong with that? Why do you want to stay -current? What problem are you trying to solve, or what are you trying to achieve by doing that? obviously automation. regardless of personal administration ethics it seems like a fair question. Brad, you could crontab the cvs update on the local source tree, compile and install kernels and userland out of crontab however often you want. likewise if you wanted a binary route (snapshots).
Re: Perpetually Current
On Thu, Dec 27, 2007 at 11:21:54AM -0800, Karsten McMinn wrote: On Dec 27, 2007 10:47 AM, Jan Stary [EMAIL PROTECTED] wrote: That's about one hour of work twice a year - what's wrong with that? Why do you want to stay -current? What problem are you trying to solve, or what are you trying to achieve by doing that? obviously automation. regardless of personal administration ethics it seems like a fair question. Brad, you could crontab the cvs update on the local source tree, compile and install kernels and userland out of crontab however often you want. likewise if you wanted a binary route (snapshots). Yes, but in either case, you should very carefully check to see that http://www.openbsd.org/faq/current.html has not changed first. (Obviously, that's not the correct way to go about it, but it's certainly the easiest.) Joachim P.S. No, I am not dead. I hope to find some more time to read this list Real Soon Now. -- PotD: x11/ogle - DVD player
Re: Perpetually Current
Karsten McMinn wrote on Thu, Dec 27, 2007 at 11:21:54AM -0800: obviously automation. regardless of personal administration ethics it seems like a fair question. If you understand the OP's question that way, you should also provide the following answer to the OP: There is no standard way for automated upgrades on OpenBSD. The standard upgrade procedure requires booting an install system, usually from floppy, CD-ROM or bsd.rd, and rebooting once more when the upgrade is done to get back to the production system. I'm not aware of any sensible approach to automation of this standard upgrade process. Brad, you could crontab the cvs update on the local source tree, Combined with what follows, this is certainly bad advice. HEAD is a moving target. Sometimes, HEAD won't even compile if you hit right in between two related commits. So, installing self-compiled HEAD stuff via cron on a production system is asking for trouble. When you simply want to run -current, snapshots are recommended. compile and install kernels And reboot from cron after installing the kernel? On a production system? I would call that scary. On the other hand, not rebooting after installing the new kernel is even worse. Some mini flag day might suffice to break part of your userland. That won't happen often, but on a production system, you probably do not want to break things even once or twice a year. You know, *if* cron brings your server down, it will very probably be right after the start of your long holiday. and userland out of crontab however often you want. Upgrading userland from cron? I wouldn't call that impossible, but... Have a look at http://www.openbsd.org/faq/upgrade42.html Specifically, you need the section entitled Upgrading without install kernel starting with This is NOT the recommended process. Use the install kernel method if at all possible! There are several steps to perform. Some of them are not trivial, but they require thought. There is no guarantee these steps are always the same: Already the filename upgrade42.html is giving that away. Almost certainly, some things will change during the five years to come. So, scripting this is certainly possible, but it will be *much* more fragile than upgrading manually, keeping the scripts up to date will certainly be more work than doing manual upgrades twice a year, und it is definitely not a job for newbies. likewise if you wanted a binary route (snapshots). A bit better, but still: - Do you reboot from cron? - How will you make cron read, interpret and act according to http://www.openbsd.org/faq/current.html? - How will you make cron keep /etc in sync with the system? Keeping a system up to date involves manual work, either a little easy work for manual upgrades now and then, or lots of hard and scary work for building and maintaining an automatic system. You choose according to your skill, and according to your time budget...
