Re: Upgrading from 6.3 to 7.1 -- how dangerous?
On Sunday 19 April 2009 19:42:39 Doug Hardie wrote: > While most of the update process is > waiting for things to complete, mergemaster requires a lot of > responses to a ton of questions about updates to configuration files. > The vast majority of those will be to install the new version. > However, there are some where you really need to review the changes > and make sure your unique configuration gets carried over into the new > files. Its really easy to get into the "i" mode and skip right > through some of those. The recovery from that will be painful. -iU is your friend. Only painful if you have custom rc.d files that depend on functionality in other rc.d files. -i => install files that do not exist yet -U => upgrade files that you have not modified It's a blessing and reduces much of mergemaster's operator attention. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Upgrading from 6.3 to 7.1 -- how dangerous?
On Sunday 19 April 2009 19:06:55 John Almberg wrote: > I've thought about setting up a dummy server, just to practice on. Is > this a good idea? If this is to get a feel for the upgrade process, sure. But if the hardware is different, you won't be much wiser for the production box in question. I'm not upgrading a 6.4 for a client, because a previous upgrade to 7.0-STABLE hosed the data on the disk, due to an ata-regression. This is fixed most likely in 7.1-STABLE, but I'm not gambling just yet. Regressions are rare in FreeBSD (technically it's not a regression, the original 6.3 ran in UDMA mode and the 7.0 thought it could handle SATA, but it didn't), but they do happen. Either way with 7.2 around the corner, I would wait till that's out or do the testing with 7.2-PRERELEASE, since it's getting an awful lot of testing now. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Upgrading from 6.3 to 7.1 -- how dangerous?
how i do this (but this is probably not "politically correct" ;) 1) get all files of new version in one place (subdir) say at /7.1 2) separate out manually all configs - it's /etc, /var/namedb and maybe few more 3) using livecd just put all other files with tar|tar to the place 4) manually update configs - put all except what you modified 5) turn off all services in rc.conf, reboot 6) install compat6x from ports so your existing ports will work, then turn on services On Sun, 19 Apr 2009, John Almberg wrote: I need to upgrade a live, production server from 6.3 to 7.1. I can't afford to have any troubles with this server. I have Absolute FreeBSD and a few other BSD books, and the upgrade process looks fairly straightforward. That's the theory... Real world question: how scared should I be? I've thought about setting up a dummy server, just to practice on. Is this a good idea? Or am I just a nervous Nellie? -- John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Upgrading from 6.3 to 7.1 -- how dangerous?
John Almberg wrote: > I need to upgrade a live, production server from 6.3 to 7.1. I can't > afford to have any troubles with this server. I have Absolute FreeBSD > and a few other BSD books, and the upgrade process looks fairly > straightforward. That's the theory... > > Real world question: how scared should I be? > > I've thought about setting up a dummy server, just to practice on. Is > this a good idea? Or am I just a nervous Nellie? > I concur with the concept of doing it on a test box first. I only have two servers at home and 7 at work, so the ones at home are my "fudge" factor in that upgrades are run by them first before I try the ones at work. Since I don't have large numbers whenever I go from one major release to another, e.g., like 6.x to 7.x I first use dump and back up everything. Then I usually install the new from scratch, build whatever ports, and copy configs over from the backup. Doesn't have to get done this way, but there are a few things of which you should be aware. Whenever there is a major version bump it is because of an ABI difference between old and new. Sometimes this will cause installed ports that were built against the libs from the previous install to malfunction. The proper fix is to rebuild them after the update so they get built against the new versions of system libraries. This can be automated with portupgrade. The other common approach is to install the "compat" shim, in this case it would be the compat6x. With this installed when you reboot to the new kernel in theory the existing ports built against 6.x libs will still function. Since I'm still using csup and the make build/install/kernel/world dance I can't speak to freebsd-update. There is also a target for ensuring old libs are deleted, I believe it is make delete-old-libs, or something like. It is a good idea to remove the old libs so that when later on when you are updating installed ports they can only get linked against the new 7.x libs. The situation you do not want to get yourself in is having a mix of some ports built against 7.x and some other(s), e.g., dependencies built against the 6.x libs. Sounds like a lot but it really isn't if you break it up into individual steps and are aware of the potential pitfalls. These are mostly easy to deal with by simply doing things in the proper order. What you are proposing is doable, and has been done by many - I just wanted you to know the traps not to fall into. But I would recommend you dry run it on a non production box first, just to get a feel for it. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Upgrading from 6.3 to 7.1 -- how dangerous?
Glen Barber wrote: On Sun, Apr 19, 2009 at 1:06 PM, John Almberg wrote: I need to upgrade a live, production server from 6.3 to 7.1. I can't afford to have any troubles with this server. I have Absolute FreeBSD and a few other BSD books, and the upgrade process looks fairly straightforward. That's the theory... Wise man (who I won't name to keep his identity private) once said: "In theory, there is no difference between practice and theory. In practice, there is." Real world question: how scared should I be? I've done several 6.x to 7.x upgrades on live systems. There are some tricky bits, but once you have been through the process it's fairly routine. One big gotcha is that in oder to upgrade all the ports, you first need to make sure that the software you're using and any dependencies it has are all up to date too. For portmaster this is not a problem, as it is a shell script with no dependencies except on the base system. For portupgrade, you should delete portupgrade and all of it's dependencies (some or all of: ruby, ruby-bdb, bdb, openssl -- depending on your configuration choices) and then reinstall by: # cd /usr/ports/port-mgmt/portupgrade # make install I've thought about setting up a dummy server, just to practice on. Is this a good idea? Or am I just a nervous Nellie? Get a test box to do this on first. :) Absolutely. A dummy run before the real thing is a really good idea. One great benefit of using a test server is that you can also use it as a package building machine (assuming it's the same CPU architecture of course). Being able to upgrade all the installed software by installing pre-compiled and tested packages will a) save you a lot of time when you have to have your production server out of action to work on it and b) it lets you discover all those little glitches and tweaks that you will need to deal with *before* you have to do it for real. If you do have a spare server with appropriate capabilities, one approach that you might consider is building a duplicate upgraded system image on the spare machine and then simply swapping hard drives with your production box. That is probably about the minimum time impact on production service[*] for you to do this sort of upgrade and it has the really useful benefit that there is a simple back-out path should things not work out. Just swap the old disks back in. Cheers, Matthew [*] Well, modulo time required for disks to resynchronise if you're using mirroring and can't swap both halves of the mirror simultaneously. For the whole RAID 1 thing to be effective your server /should/ run pretty much normally while this is going on though. -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Upgrading from 6.3 to 7.1 -- how dangerous?
On Apr 19, 2009, at 10:06, John Almberg wrote: I need to upgrade a live, production server from 6.3 to 7.1. I can't afford to have any troubles with this server. I have Absolute FreeBSD and a few other BSD books, and the upgrade process looks fairly straightforward. That's the theory... Real world question: how scared should I be? Not at all if you prepare properly (see below). I've thought about setting up a dummy server, just to practice on. Is this a good idea? Or am I just a nervous Nellie? That is an excellent approach. I keep a couple of spare machines around just for that purpose. While most of the update process is waiting for things to complete, mergemaster requires a lot of responses to a ton of questions about updates to configuration files. The vast majority of those will be to install the new version. However, there are some where you really need to review the changes and make sure your unique configuration gets carried over into the new files. Its really easy to get into the "i" mode and skip right through some of those. The recovery from that will be painful. Take lots of time on the dummy upgrade to think through the merge and keep good records. You are likely to find that you still have to make some changes to those files after the update is complete. Go back and update the records so you don't have to do that a second time on the production server. I also recommend you not let weeks go by between updating the dummy and the production systems. No matter how good you write stuff down, some will get forgotten. Often memory will save you, but if its been too long, perhaps not. The dummy update process will also give you a much better estimate of the time you need to have the production system down. I have been using this approach since FreeBSD 2.5 and have had a couple of disasters in updating my test system. After a few retries I figured it out and none of the production system updates has encountered any issues. I create a script for each update and save them. Often they come in handy in a later update. The script is really helpful when updating a number of production servers. I tend to forget about some steps otherwise after a few iterations. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Upgrading from 6.3 to 7.1 -- how dangerous?
On Sun, Apr 19, 2009 at 1:06 PM, John Almberg wrote: > I need to upgrade a live, production server from 6.3 to 7.1. I can't afford > to have any troubles with this server. I have Absolute FreeBSD and a few > other BSD books, and the upgrade process looks fairly straightforward. > That's the theory... Wise man (who I won't name to keep his identity private) once said: "In theory, there is no difference between practice and theory. In practice, there is." > Real world question: how scared should I be? > > I've thought about setting up a dummy server, just to practice on. Is this a > good idea? Or am I just a nervous Nellie? > Get a test box to do this on first. :) -- Glen Barber ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"