12. 6. 2014 v 10:45, Tim Boudreau via smartos-discuss <[email protected]>:
> Just FYI, if you feel brave, I believe you can add the URL for a newer > release to /opt/local/etc/pkgin/repositories.conf - e.g. > > http://pkgsrc.joyent.com/sdc6/2012Q2/x86_64/All > http://pkgsrc.joyent.com/packages/SmartOS/2013Q4/x86_64/All > > Just tried it on a test zone I had lying around without mishap. > > Someone can correct me if this is likely to have unanticipated side effects, > other than the ones already mentioned in this thread (i.e. you need to be > *really* confident that the packages you update will update cleanly - and do > a snapshot first!). > Yes, definitely make a snapshot before you start, and if the VM provides any public service and you can’t just take it out of a balanced pool, make sure you handle it as a planned downtime. Of course, ideally you’d have your entire VM scripted up in Chef or similar (heck, even Bash scripts are better than nothing), but sometimes that’s just sometimes not possible. (One those "I’ll just handle this one update manually and I swear I’ll script up the setup next time” things.) For the records again (since I write from a Joyent address), Joyent doesn’t recommend that you do this. I’ve done this myself way too many times (not recently though) and we even tried to come up with a script that takes the user through known obstacles. However, it turned out there’s just no way to prepare for all possible consequences and factors, and providing a script immediately makes this a supported procedure in many eyes, so… In general, issues are less likely to crop up if you’re only moving by a quarter, compared to two years, and if you have a minimum number of packages (e.g. started from ‘base’) rather than way too many (started from ‘standard’ or even the old ‘smartosplus’). It’s crucial to check the initial “I’m going to upgrade all these packages for you” message that pkgin gives you (and yes, it’s annoying difficult to read and parse) and look for any major upgrades of MySQL or PostgreSQL. Especially PostgreSQL updates (e.g. moving from 9.1 to 9.2) are a pain, because you need to create a full dump of your storage before you even start the update, then import it into a blank one again. This may just apply to any package that stores user data in its own format. Another typical problem you may hit is when a config file changes significantly or even stops working because of a major update. One of the good things about pkgsrc is that every single file that a package installs under $PREFIX/etc is copied there at installation time from an example under $PREFIX/share/examples/$package. So what you could do diff each config file against the *old* example file and save that as a patch. If you get stuck on the updated VM later on, you could take the *new* example config file, apply the patch to it (or transplant the changes manually) and fix the problem. -F ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
