Nexenta Core Platform 2 Released
Nexenta Core Platform 2 Released
Posted May 26, 2009 14:58 UTC (Tue) by zooko (guest, #2589)In reply to: Nexenta Core Platform 2 Released by pranith
Parent article: Nexenta Core Platform 2 Released
Except I haven't tried it yet, because my personal server is in a co-lo a couple of thousand miles away, so if something goes wrong it will be awfully inconvenient to get console access. :-)
Anyway, there are the normal sorts of surprises and weirdnesses that you should expect when using a different operating system. "df" and "ps" and so forth don't have all the same fields and formats that you've gotten used to over the last ten or fifteen years.
It does have a full GNU userland, but not everything you care about is userland. Also there are a bunch of features like zfs and dtrace and Zones and SMF that you don't have to use if you don't want to, but which are there as part of the standard toolset.
I mostly just use mine as a GNU/POSIX userland and leave the advanced stuff alone. :-)
Posted May 26, 2009 16:02 UTC (Tue)
by hppnq (guest, #14462)
[Link] (8 responses)
The fact that you do not have access to the system sorts of defeats the idea of being able to boot back into a working OS. Otherwise it is, of course, a cool feature, and one that existed long before anyone had heard of ZFS. In any case, good luck, and let us know how it went. ;-)
But I think it is really in the proprietary world, where you have to watch out for binary incompatibility and have limited test resources, that this kind of functionality is very nice to have. For most users, it is much better to cleanly separate the OS files from their personal stuff, and simply overwrite the OS image with a working one in case an upgrade fails. Console access is *always* mandatory for remote systems. ;-)
Posted May 26, 2009 17:17 UTC (Tue)
by zooko (guest, #2589)
[Link] (7 responses)
The fact that you do not have access to the system sorts of defeats the idea of being able to boot back into a working OS. Otherwise it is, of course, a cool feature, and one that existed long before anyone had heard of ZFS. But I think it is really in the proprietary world, where you have to watch out for binary incompatibility and have limited test resources, that this kind of functionality is very nice to have. For most users, it is much better to cleanly separate the OS files from their personal stuff, and simply overwrite the OS image with a working one in case an upgrade fails. Console access is *always* mandatory for remote systems. ;-)
Posted May 26, 2009 19:31 UTC (Tue)
by hppnq (guest, #14462)
[Link] (6 responses)
AIX has had this for years. Solaris with Veritas as well, and I am sure there are more. The basic idea is the same as the ZFS one: you split a mirror or make a snapshot, keep one half untouched and upgrade the other one.
I think it is really cool that ZFS has made this available for home users, but it has existed for a long time in the proprietary Unix datacenter -- I used it. Technically, the possibility has or should have been there for years for Linux systems as well.
But I have never actually missed it. Especially with proprietary systems it is only *after* the reboot that you will find out whether an upgrade actually was successful (or rather, unsuccessful), because you are not upgrading a well-tested distribution, but a system typically consisting of a number of binary components not at all guaranteed to keep playing nicely together. It is mandatory that you have a way to actually go back to what worked before, and nothing else.
No problem, but that is not what I said. I prefer reinstalling the base system over making snapshots, if the very unlikely event of a completely screwed up upgrade occurs. Sorry if I was not clear, but all this has nothing to do with proprietary software, but with systems management.
Posted May 26, 2009 22:28 UTC (Tue)
by hppnq (guest, #14462)
[Link] (5 responses)
However, this kind of transactional package management has been an AIX feature since last century. In most serious environments, having a full, pristine copy of your operating system is a requirement anyway, so then having separate inline snapshots is simply overhead -- and note the obvious risk of not being able, for whatever reason, to get your hands on the snapshots, before or after boot.
Really, a console is all you need. ;-)
Posted May 26, 2009 22:32 UTC (Tue)
by dlang (guest, #313)
[Link] (4 responses)
Posted May 26, 2009 23:09 UTC (Tue)
by hppnq (guest, #14462)
[Link] (1 responses)
(It seems to have nothing to do with nix of LWN fame. ;-)
Posted May 27, 2009 17:51 UTC (Wed)
by nix (subscriber, #2304)
[Link]
It seems like the sort of thing I'd like to come up with if I was better
Posted May 27, 2009 10:23 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted May 27, 2009 15:05 UTC (Wed)
by dtlin (subscriber, #36537)
[Link]
Unlike LVM1, LVM2's snapshots are writable by default. It's very, very
cool. With sbuild, I use
r/w snapshots all the time: it can be set up to take a snapshot of a
minimal base system, add minimal dependencies to run a package compile in
this environment, and remove the snapshot when all is done.
The changes made to a snapshot go to the bit bucket when the snapshot is
removed. There's patches
which allow for merging a snapshot back into the origin device. They don't
seem to be upstream yet, though.
Nexenta Core Platform 2 Released
If the upgrade fails then apt-clone will have made a ZFS snapshot so that it doesn't actually boot to the new operating system.
Nexenta Core Platform 2 Released
What? Oh, I see, yes without console access I can't check whether the new version actually boots and then if not reboot to the old version. I should really get remote console working...
What I can do without console is observe whether the apt-get dist-upgrade completed without any errors before configuring it to boot into the new version on next boot.
Do tell -- when has it been possible to do something like this before? I know that you can, for example, use grub to select among different kernels, and different /lib/modules, for example, but that's much less than letting you select among entire different operating systems -- an entire set of core packages that get installed by an apt-get dist-upgrade. It does so using ZFS's very cheap and convenient snapshot feature so that you don't have to do something crazy like make a separate copy of your operating system before upgrading.
If anything like this has been possible before, I'd like to learn about it.
It's fine with me if you prefer reinstalling your operating system instead of having a transactional upgrade tool. But what does this have to do with proprietary vs. open source? As far as I know, proprietary operating systems such as Windows are typically fixed by reinstalling the OS or by manually patching it, and the only case of transactional operating system upgrade that I know of is Nexenta's apt-clone, which is open source. So it kind of sounds like to me that you got it backwards.
Nexenta Core Platform 2 Released
Do tell -- when has it been possible to do something like this before?
It's fine with me if you prefer reinstalling your operating system instead of having a transactional upgrade tool. But what does this have to do with proprietary vs. open source?
If you're interested, here's a 2004 article about using rpm's rollback feature when doing system upgrades. Not so long ago it was removed, because it was considered to be unreliable: think of scripts changing the system irreversibly. To be honest, I can't immediately see how ZFS would solve that. But I am no expert.
Nexenta Core Platform 2 Released
Nexenta Core Platform 2 Released
Indeed. Or check out the Nix package manager and NixOS!
Nexenta Core Platform 2 Released
Nexenta Core Platform 2 Released
name :)
at functional languages, though :) A very nifty piece of work indeed.
Nexenta Core Platform 2 Released
Nexenta Core Platform 2 Released