Actually, they are promoted as being for IBM’s OpenOffice derivative Symphony, but given they are all ODF format files, they should work fine with OpenOffice and for that matter LibreOffice.
Quick post – I have an Ubuntu 10.04 system configured to authenticate LDAP users. I found that after installing Thunderbird, LDAP users cannot launch the application without it crashing with a segmentation fault instead.
Turns out this is a known and widespread issue, and the workaround (which worked in my case) is to install nscd.
This thread has some more detail: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/571308
Really interesting set of videos recorded during a recent gathering of the minds behind the companies developing and using Illumos, including Garrett D’Amore (of Nexenta), Adam Leventhal (of Delphix) and Bryan Cantrill (of Joyent), amongst others. These people represent the star talent behind some revolutionary technology developed at Sun Microsystems as used in Solaris and OpenSolaris.
You can find the full set of videos on Deirdré Straughan’s YouTube channel. I found the comments made in the fifth part especially juicy:
An excerpt of some of the comments:
“What I’ve seen on the mailing list is actually a higher level of support than I think frankly Oracle’s own customers were getting at Oracle…if you ask a question about DTrace, you’re going to get the authors of DTrace involved very often, just by asking a question on the list.” Garrett D’Amore (asked about support)
“Right now…we have extensions to DTrace for example that cannot go back into Solaris. Oracle would be violating – in an act of poetic justice – the license that they themselves created, if they took that back.” – Bryan Cantrill
“They’ve made a lot of changes [in Solaris 11] that frankly I would not take, that I think are unnecessary changes. Solaris 11 I think is going to be a real opportunity for Illumos.” – Bryan Cantrill
“It [Solaris 11] represents a huge departure from Solaris 10. So, it’s going to ask the customers who are on Solaris 10 ‘do you want to invest a tremendous amount of time going to Solaris 11, going to Linux, or going to something else?’.” – Adam Leventhal
“Solaris 11 is mutating into what some people would call the bootloader for the Oracle database. Oracle’s priorities are clearly way different from what Sun’s were…I would not be entirely unsurprised if it turns that out you can’t actually license Solaris 11 separately…I would be actually very surprised if there’s ever a Solaris 12.” – Garrett D’Amore
“There’s a huge installed base of Sun hardware out there in datacenters around the world, billions of dollars worth of equipment, and Oracle has basically given it the finger.” – Garrett D’Amore
“Oracle has removed sun4u from Solaris 11. So there is no sun4u support in Solaris 11, which means that there is this huge amount of hardware, this installed base (anything earlier than a year or two ago) that can’t run, will not run Solaris 11 at all. And that’s a huge Illumos opportunity.” – Bryan Cantrill and Adam Leventhal
Meanwhile, Larry Ellison is suing his neighbour over some trees blocking his view.
Garrett D’Amore has posted an interview made of him and Alasdair Lumsden (of OpenIndiana) by Constantin Gonzalez. (Constantin has always struck me as a pretty cool guy, so much so that he’s been in my blogroll ever since starting this blog.)
The first few minutes of the podcast are in German, but the interview itself is in English. Encounraging listening!
The procedure for migrating an OpenSolaris Zone on a ZFS file system is not adequately documented anywhere in Oracle’s documentation set (which makes a bunch of assumptions about how the systems involved are configured), nor could I find a clearly written blog or guide anywhere on how to do this seemingly simple and straightforward task.
In this post, we are going to migrate a zone from one OpenIndiana oi_148 x86 machine (“Machine 1”) to another running the same build (“Machine 2”). Both systems are configured with a ZFS root filesystem. I’m assuming some prior basic familiarity with creating, installing, and booting zones.
Our example zone is called afterburnerzone-2. It has its zonepath on the source machine at /rpool/zones/zone_roots/afterburnerzone-2.
On Machine 1:
Prepare the zone for migration on the source system
First, halt the zone, then run the detach command:
# zoneadm -z afterburnerzone-2 halt # zoneadm -z afterburnerzone-2 detach
This creates an XML file in the zone’s zonepath (named SUNWdetached.xml) containing its configuration properties – these properties (physical network interface, IP address and so forth) can be modified later using the zonecfg utility when the zone is attached on the target system.
Make ZFS snapshots of the zone’s filesystems
Recursively snapshot the ZFS filesystems relevant to our zone:
# zfs snapshot -r rpool/zones/zone_roots/afterburnerzone-2@snap1
This create snapshots of the zone’s filesystems, which in this example are:
We can see this in the output of zfs list -t snapshot:
# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT ... rpool/zones/zone_roots/afterburnerzone-2@snap1 0 - 34.5K - rpool/zones/zone_roots/afterburnerzone-2/ROOT@snap1 0 - 31K - rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe@snap1 0 - 3.72G -
Create archives of the snapshots in preparation for sending to the target system
The zfs send command is used to archive a ZFS dataset. We’re going to archive all three snapshots of our detached zone to separate files (these will eventually be restored on the target system):
# zfs send rpool/zones/zone_roots/afterburnerzone-2@snap1 > /export/home/davek/afterburnerzone2.snap1 # zfs send rpool/zones/zone_roots/afterburnerzone-2/ROOT@snap1 > /export/home/davek/afterburnerzone2_root.snap1 # zfs send rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe@snap1 > /export/home/davek/afterburnerzone2_root_zbe.snap1
Copy the archives to the target system
Self explanatory – in my case I simply scp the .snap files to the target system, but copying them via a USB flash drive or whatever will work fine too.
The next steps are all performed on the target system.
On Machine 2:
Import the zone on the target system
We are assuming that our zones are being stored at /rpool/zones/zone_roots on the target system, i.e. the same relative location as on our source system. Before proceeding, make sure that the rpool/zones and rpool/zones/zone_roots ZFS file systems exist – if not, you’ll need to manually create them, e.g.:
# zfs create rpool/zones # zfs create rpool/zones/zone_roots
Restore the ZFS snapshot archives
Let’s assume we have coped the archives into a user’s home directory at /export/home/davek on the target system. We now use the zfs receive command to the restore the ZFS snapshot archives into the ZFS filesystems specified (which will be created when each command is run):
# zfs receive rpool/zones/zone_roots/afterburnerzone-2 < /export/home/davek/afterburnerzone2.snap1 # zfs receive rpool/zones/zone_roots/afterburnerzone-2/ROOT < /export/home/davek/afterburnerzone2_root.snap1 # zfs receive rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe < /export/home/davek/afterburnerzone2_root_zbe.snap1
Run zfs list to verify the snapshots have been restored to the correct location:
# zfs list NAME USED AVAIL REFER MOUNTPOINT rpool/zones 3.72G 213G 32K /rpool/zones rpool/zones/zone_roots 3.72G 213G 32K /rpool/zones/zone_roots rpool/zones/zone_roots/afterburnerzone-2 3.72G 213G 35.5K /rpool/zones/zone_roots/afterburnerzone-2 rpool/zones/zone_roots/afterburnerzone-2/ROOT 3.72G 213G 32K /rpool/zones/zone_roots/afterburnerzone-2/ROOT rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe 3.72G 213G 3.72G /rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
Change the mountpoint property for ZFS filesystems to legacy
We do this for the following restored filesystems only:
# zfs set mountpoint=legacy rpool/zones/zone_roots/afterburnerzone-2/ROOT # zfs set mountpoint=legacy rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe
Mount one ZFS filesystem using a legacy mount procedure
We do this for the following filesystem only:
We want to mount it to /rpool/zones/zone_roots/afterburnerzone-2/root:
# mount -F zfs rpool/zones/zone_roots/afterburnerzone-2/ROOT/zbe /rpool/zones/zone_roots/afterburnerzone-2/root
Configure the zone
Using the zonecfg command, we are going to recreate the afterburnerzone-2 zone’s configuration on the target system using the configuration file generated when it was detached.
First, configure the afterburnerzone-2 zone:
# zonecfg -z afterburnerzone-2 afterburnerzone-2: No such zone configured Use 'create' to begin configuring a new zone.
Note the prompt to create a new zone – we will do this, but point to the XML file migrated across with the zone for our settings:
zonecfg:afterburnerzone-2> create -a /rpool/zones/zone_roots/afterburnerzone-2
If this is successful, you won’t see any confirmation in the positive, only an error if the preexisting zone configuration file cannot be found. By running the info command here, one can check the zone settings and they should match what was originally set on the source machine:
zonename: afterburnerzone-2 zonepath: /rpool/zones/zone_roots/afterburnerzone-2 brand: ipkg autoboot: true bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: fs-allowed: net: address: 192.168.51.14 allowed-address not specified physical: rge1 defrouter not specified
The remaining configuration using zonecfg in this particular example involves checking the zone’s physical network interface and IP address and changing if necessary, for example, if the physical network interfaces are different on the target machine (which in this example are):
zonecfg:afterburnerzone-2> select net physical=rge0 zonecfg:afterburnerzone-2:net> set physical=bge1 zonecfg:afterburnerzone-2:net> set address=192.168.51.9 zonecfg:afterburnerzone-2:net> end zonecfg:afterburnerzone-2> info zonecfg:afterburnerzone-2> commit zonecfg:afterburnerzone-2> exit
Attach the zone
Finally, let’s attach the zone to the system:
# zoneadm -z afterburnerzone-2 attach Log File: /var/tmp/afterburnerzone-2.attach_log.lRayVj Attaching... preferred global publisher: openindiana.org Global zone version: firstname.lastname@example.org,5.11-0.148:20101125T013212Z Cache: Using /var/pkg/download. Updating non-global zone: Output follows Packages to install: 16 Create boot environment: No Evaluation: Packages in zone afterburnerzone-2 are out of sync with the global zone. To proceed, retry with the -u flag. Result: Attach Failed.
Okay – so let’s try again, this time using the -u flag as instructed:
# zoneadm -z afterburnerzone-2 attach -u Log File: /var/tmp/afterburnerzone-2.attach_log.eWaWok Attaching... preferred global publisher: openindiana.org Global zone version: email@example.com,5.11-0.148:20101125T013212Z Cache: Using /var/pkg/download. Updating non-global zone: Output follows Packages to install: 16 Create boot environment: No PHASE ACTIONS Install Phase 485/485 PHASE ITEMS Package State Update Phase 16/16 Image State Update Phase 2/2 No updates necessary for this image. Updating non-global zone: Zone updated. Result: Attach Succeeded.
Done! We can now proceed to boot and log in to the zone.