Re: Upgrading 3.8 to current
On Sat, Oct 13, 2012 at 11:47:50AM -0500, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) The 3.9 upgrade guide says: pfsync(4) http://www.openbsd.org/cgi-bin/man.cgi?query=pfsyncsektion=4 has changed format, so it can not keep state between a 3.8 and a 3.9 box. Mismatched systems will lose all connections when you switch which box is master, as states will not be transfered between systems. You can minimize the impact of this by upgrading your backup boxes first, so there is only one loss of active states. Can anyone explain what that means in terms of my existing pf configuration working as a simple router with a port forward? Does this simply mean that during the upgrade, if I had multiple servers running, that boxes would temporarily lose connectivity during the upgrade as they wouldnt switch over to a backup server automatically? Do you *really* want to go from 3.8 to 5.2 one release at a time ?.. I think this is just one case where I would backup, reinstall, fix things...
Re: Upgrading 3.8 to current
On Sat, Oct 13, 2012 at 11:47:50AM -0500, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) The 3.9 upgrade guide says: pfsync(4) http://www.openbsd.org/cgi-bin/man.cgi?query=pfsyncsektion=4 has changed format, so it can not keep state between a 3.8 and a 3.9 box. Mismatched systems will lose all connections when you switch which box is master, as states will not be transfered between systems. You can minimize the impact of this by upgrading your backup boxes first, so there is only one loss of active states. Can anyone explain what that means in terms of my existing pf configuration working as a simple router with a port forward? Does this simply mean that during the upgrade, if I had multiple servers running, that boxes would temporarily lose connectivity during the upgrade as they wouldnt switch over to a backup server automatically? Are you running carp? If so, syncing the two filrewalls will not happen while you are upgrading. BTW, I think it makes more sense to backup your exsting config, do a fresh install and then do the work to rebuild the config. Doing 10 or more upgrade steps looks like way to much time wasted. -Otto
Re: Upgrading 3.8 to current
On 10/13/2012 9:47 AM, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) The 3.9 upgrade guide says: pfsync(4) http://www.openbsd.org/cgi-bin/man.cgi?query=pfsyncsektion=4 has changed format, so it can not keep state between a 3.8 and a 3.9 box. Mismatched systems will lose all connections when you switch which box is master, as states will not be transfered between systems. You can minimize the impact of this by upgrading your backup boxes first, so there is only one loss of active states. Can anyone explain what that means in terms of my existing pf configuration working as a simple router with a port forward? Does this simply mean that during the upgrade, if I had multiple servers running, that boxes would temporarily lose connectivity during the upgrade as they wouldnt switch over to a backup server automatically? I am assuming you are using CARP in a master/backup configuration and that's what you mean when you talk about switching over to a backup server automatically. Please disregard if that is not true. It seems pretty straight forward from the notes: 1) Upgrade your backup box. 2) Fail over to it, losing all current states -- dropping all established connections, but being immediately available to create new ones. It's not a full loss of connectivity, but any established connections will be dropped. 3a) Optionally change the advskew of the carp interfaces on your primary box so they don't automatically takeover as master before you get a chance to verify pfsync is working. 3b) Upgrade your primary box, verify pfsync is working (pfctl -s states), and takeover as master in carp (if you haven't already). 4) Keep upgrading! So, like it said, there would only be one loss of established/active states. You will hit this issue at least one more time going from 4.4 to 4.5 as well: http://www.openbsd.org/faq/upgrade45.html#pfsync
Re: Upgrading 3.8 to current
You will need some planning. Pf syntax changed quite a bit a couple releases back. I'd consider backing up the files converting pf.conf to the new syntax and doing a clean install of 5.2 (out soon). -Bryan On Oct 13, 2012, at 9:47 AM, Matt Morrow cmorrow...@gmail.com wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) The 3.9 upgrade guide says: pfsync(4) http://www.openbsd.org/cgi-bin/man.cgi?query=pfsyncsektion=4 has changed format, so it can not keep state between a 3.8 and a 3.9 box. Mismatched systems will lose all connections when you switch which box is master, as states will not be transfered between systems. You can minimize the impact of this by upgrading your backup boxes first, so there is only one loss of active states. Can anyone explain what that means in terms of my existing pf configuration working as a simple router with a port forward? Does this simply mean that during the upgrade, if I had multiple servers running, that boxes would temporarily lose connectivity during the upgrade as they wouldnt switch over to a backup server automatically?
Re: Upgrading 3.8 to current
On Sat, Oct 13, 2012 at 11:47:50AM -0500, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) Upgrading to the newest release is the right way to go. And the best way to do it is to back up your data and do a full clean 5.2 install, skipping over in one step a dozen+ upgrades, then restoring from backup. BTW, how is it that you came to be running a 3.8 system? Did you inherit a machine from someone who was fired? You may need to rewrite some pf rules and familiarize yourself with a few changes, such as the rc.d system, DUIDs, and lots of other improvements. Nicolai
Re: Upgrading 3.8 to current
On 10/13/12 13:18, Marc Espie wrote: On Sat, Oct 13, 2012 at 11:47:50AM -0500, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) ... Do you *really* want to go from 3.8 to 5.2 one release at a time ?.. I think this is just one case where I would backup, reinstall, fix things... As the guy who writes the upgrade guides... I agree 100% with this. Pop out the existing disk, pop in a new one, install to it, bring it up. Problem that takes you outside your downage window? revert to original disk. Nick.
Re: Upgrading 3.8 to current
+1 Done this by myself. Less hassle. On 13 okt 2012, at 20:28, Bryan Irvine sparcta...@gmail.com wrote: You will need some planning. Pf syntax changed quite a bit a couple releases back. I'd consider backing up the files converting pf.conf to the new syntax and doing a clean install of 5.2 (out soon). -Bryan On Oct 13, 2012, at 9:47 AM, Matt Morrow cmorrow...@gmail.com wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) The 3.9 upgrade guide says: pfsync(4) http://www.openbsd.org/cgi-bin/man.cgi?query=pfsyncsektion=4 has changed format, so it can not keep state between a 3.8 and a 3.9 box. Mismatched systems will lose all connections when you switch which box is master, as states will not be transfered between systems. You can minimize the impact of this by upgrading your backup boxes first, so there is only one loss of active states. Can anyone explain what that means in terms of my existing pf configuration working as a simple router with a port forward? Does this simply mean that during the upgrade, if I had multiple servers running, that boxes would temporarily lose connectivity during the upgrade as they wouldnt switch over to a backup server automatically?
Re: Upgrading 3.8 to current
On Sat, Oct 13, 2012, at 12:18 PM, Marc Espie wrote: On Sat, Oct 13, 2012 at 11:47:50AM -0500, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) [...] Do you *really* want to go from 3.8 to 5.2 one release at a time ?.. I think this is just one case where I would backup, reinstall, fix things... While technically this method is unsupported, what I would do if faced with this predicament is backup, upgrade the 3.8 install directly to 5.2 and then make all the changes that have taken place in between. (This assumes it's i386, btw.) If for some reason I wound up with a busted system (I'm really not sure how well 5.2 would react to a 3.8-era ports database, for example), I'd start over with a clean 5.2 install and restore what I needed from the backups. That said, going through each individual release upgrade may be a bit safer, but it's a lot more time consuming. -- Shawn K. Quinn skqu...@rushpost.com
Re: Upgrading 3.8 to current
And make sure you buy a CD for each individual upgrade. On Sat, Oct 13, 2012, at 12:18 PM, Marc Espie wrote: On Sat, Oct 13, 2012 at 11:47:50AM -0500, Matt Morrow wrote: After dealing with a number of issues due to an old 3.8 install which have been resolved in current releases, I think I'm going to do the individual release upgrades (3.8-3.9-4.0, etc etc) [...] Do you *really* want to go from 3.8 to 5.2 one release at a time ?.. I think this is just one case where I would backup, reinstall, fix things... While technically this method is unsupported, what I would do if faced with this predicament is backup, upgrade the 3.8 install directly to 5.2 and then make all the changes that have taken place in between. (This assumes it's i386, btw.) If for some reason I wound up with a busted system (I'm really not sure how well 5.2 would react to a 3.8-era ports database, for example), I'd start over with a clean 5.2 install and restore what I needed from the backups. That said, going through each individual release upgrade may be a bit safer, but it's a lot more time consuming.
