Removing Local Zone File Systems On Solaris 10 Unix

Hey There,

Today's post is a follow-up to our very recent posts on modifying existing local zone filesystems and creating new file systems in a local zone on Solaris 10. Today, we're moving to completion with this simple how-to on removing filesystems on local zones. We'll follow up with another simple post on how to create and destroy (all in one) local zones on Solaris 10. Even though I can write 500 hundred words on why I can't write less than 500 words, that post should be short ;) It almost "has" to be!

NOTE: This note is the same as in the last two posts. Nothing has changed ;) For those of you who haven't read those (or find this post all on its lonesome ;) here it is: When removing existing filesystems on a Solaris 10 local zone, all changes must be made to the filesystem from the global zone (assuming that you originally mounted it from there)!

1. First things first; you can't unmount a filesystem from within a local zone if it was created in the global zone. As per our notation in the post on creating filesystems on local zones, this does not apply to NFS, NAS or any other remote-or-network-mounted filesystems. These are mounted directly from the local zone and, as such, can be unmounted directly from the local zone.

One interesting thing, if you have your filesystem set up under the local zone's root, is that it won't show up on the global zone's "df -k" or "df -h," etc output. If you want to see the mount from the global zone (assuming you forgot where you put it or you just want to make sure), you can find out what filesystems are mounted in your local zone, from the global zone, (at least, this is one way) by running:

host # zoneadm list -vc <-- To list out the zones on your system from the global zone (DING is our example zone).
host # zonecfg -z DING info <-- This will list out more information than you need. Basically, look for the line at the top titled "zonepath:" You can then look under that zone path to see your local zone's root filesystem mounts. Note that you could just use "grep" to find all the lines in /etc/vfstab that include your local zone's name.

2. Back to cold harsh (but mercifully swift ;) reality. From the global zone, simply unmount your local zone filesystem, like so:

host # umount /zones/DING/root/DONG

3. Then, all that's left to do is to remove the local zone from the overall zone configuration (we're assuming that you've unmounted all of "your" local zone's filesystems before continuing and executing the steps here :) Again, this can all be done very simply by using the zonecfg command:

zonecfg –z DING
zonecfg:DING> remove fs dir=/DONG
zonecfg:DING:fs> commit
zonecfg:DING:fs> quit

4. Okay; step 3 included a white lie ;) If you don't want to get error messages or, worse, cause your system not to boot properly, it's recommended that you remove the local zone filesystem entries from /etc/vfstab in the global zone, as well.

And now (I kind of promise ;) you should be all set :) We'll post that creation/destruction post very soon, if not tomorrow. After that, we'll get back to Linux, AIX or any Operation System other than Solaris 10. We try to keep a fair spread given the sheer amount of distro's the term "Linux and Unix" actually encompasses. On the bright side, this blog's subject matter could easily be much more vague ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Creating New File Systems In Local Zones On Solaris 10

Hey There,

A while ago (back in May, 2008, I believe), we took a look at working with storage pools using ZFS on Solaris 10. As we know, ZFS stands for the Zettabyte File System and not the Zone File System (which some folks think it does. Not criticizing. It makes more sense than a lot of other things you might get from those initials ;). The point being, we never stopped to take a look at zones and lay down some simple procedures for working with them. Since this blog attempts to serve as some sort of a reference (hopefully folks come here and find some help or usable information/advice), today I thought we'd start taking a look at Solaris zones. Today, we'll start looking at Solaris 10 zones by looking at "local zones." There are many important distinctions to be made between local and global zones in Solaris, but, for now, let's just leave the meaning as vague as possible. Global = All Zones. Local = Specific Zones. Perhaps I could make it simpler to understand than that. Suggestions are, of course, always welcome. But, enough dwelling on that...

Here's one of (I'm sure) many ways to add a new filesystem to a Solaris 10 local zone. Note that all of this work needs to be done "from" the global zone.

1. Once you've logged onto your global zone (usually just the main host name, like you would log in to any other zone-less version of Solaris), create the volume and filesystem "on the global zone" using standard filesystem creation commands. For this instance, we'll assume VxFS (the Veritas File System), but you could use any filesystem Solaris supports. If you are using VxFS, Solaris Volume Manager or however you prefer to do your disk partitioning and management, it's always a good idea to try to include the name of your local zone in the disk group, etc. This way, in the future, you'll never have to wonder what belongs to which when you have 15 zones on the same box!

2. Add an entry for your new local zone in /etc/vfstab file on the global zone. You should use best practice and make the mount point under /zones/MyNewZone/root. So if you wanted to add a filesystem name "DONG" to the "DING" local zone, your mount point would be:

/zones/DING/root/DONG

3. Now, still on the global zone, modify the "DING" local zone:

host # zonecfg –z DING
zonecfg:DING> add fs
zonecfg:DING:fs> set dir=/DONG
zonecfg:DING:fs> set special=/dev/vx/dsk/DINGdg/DONGvol
zonecfg:DING:fs> set raw=/dev/vx/rdsk/DINGdg/DONGvol
zonecfg:DING:fs> set type=vxfs
zonecfg:DING:fs> end
zonecfg:DING:fs> commit
zonecfg:DING:fs> quit

4. Next, mount your new "DONG" filesystem while still in the global zone:

host # mount /zones/DING/root/DONG

5. Now, hop on out of the global zone (or log out, whichever works for you ;). Then, login to the "DING" local zone and you should be able to see your new filesystem:

/dev/vx/dsk/DINGdg/DONGvol 6547824 24356 6523468 1% /DONG

NOTE: The only exceptions to the "create your local zones in the global zone ONLY" rule, have to do with NFS, and the like, filesystems. When you are adding a filesystem of this type to your local zone, you need to add it while "in" the local zone.

Tomorrow, we'll take a look at maintaining/modifying your new "DING" local zone. Until then, enjoy the peace and quiet :)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Doing Search And Replace In Multiple Files With Unix and Linux Perl - Easy Or Hard?

Hey There,

For this weeks "Lazy Sunday" post we're going to take a look at the versatility of Perl on Linux or Unix. While I'm fairly certain there's little argument that it's the best tool for most "extraction" and "reporting" functions when used in complicated situations, it's always been more interesting to me because of the wide range of ways you can complete any sort of task.

Today we're going to take a look at two different ways to do search and replace in multiple files using strictly Perl. The first way will be obnoxiously long and the second way will be almost invisible ;)

For both situations, we'll assume that we have 15 files all in the same directory. We'll also assume that we're logged into our favorite flavour of Linux or Unix OS and, coincidentally, in the same directory as those files. All the files are text files and are humungous. And, finally, all of the files are stories where the main character's name is Waldo, they've never been published and the writer's had a change of heart and decided to name his main character Humphrey. It could happen ;)

1. The hard way (or, if you prefer, the long way):

We'll write a script to read in each file and scour it, line by line. For lines on which the name Waldo appears, we'll replace that with Humphrey. We're taking into account, also, that Waldo may be named more than once on any particular line and that the name Waldo may have accidentally been mistyped with a leading lowercase "w," which needs to be corrected. That script would look something like this:

#!/usr/bin/perl

#
# replace_waldo.pl - change Waldo to Humphrey in all files.
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#
 
@all_files = `ls -1d *`;
$search_term = "Waldo";
$replace_term = "Humphrey";

foreach $file (@all_files) {
 $got_one = 0;
 chomp($file);
 open(FILE, "<$file");
 @file=<FILE>;
 close(FILE);
 foreach $line (@file) {
  if ( $line =~ /Waldo/i ) {
   $line =~ s/Waldo/Humphrey/gi;
   $got_one = 1
  }
 }
 if ( $got_one ) {
  open(NEWFILE, ">$file.new");
  print NEWFILE @file;
  close(NEWFILE);
  rename("$file.new", "$file");
 }
}

2. The easy way (or, again, the short way):

Assuming the exact same convoluted situation, here's another way to do it (which we've covered in a bit more detail in this older post on using Perl like Sed or Awk):

From the command line we'll type:

host # perl -p -i -e 's/Waldo/Humphrey/gi' *

And we're done :)

Of course, the longer method is better suited for situations in which there are other extenuating circumstances. Or, perhaps, even more work to do. For the sort of limited situation we've laid out today, I will almost always go with the second method (Who wants pie? :)... Unless I have lots of time on my hands ;)

Cheers,

, Mike

Patching Solaris 10 Zones - Global And Local Issues

Hello Again,

In a long overdue continuation of our coverage of Solaris 10 (as in our previous post on migrating between local and global zones) today, we're going to take a look at patching on Solaris 10, insofar as it relates to zones. There are a lot of questions going around about how to patch appropriately and what's permissible. This is completely understandable since, if you do it wrong, the consequences can be disastrous and irreversible (and none of us wants to stay up all night... working ;)

We'll start off with the concept of patching and zones. As far as patching is concerned, each zone actually has it's own patch (and package) database. This makes it possible for you to, theoretically, patch single zones on a host individually or patch all of them at once by patching the "global" zone.

There are a few things to keep in mind though, before you go ahead and apply your patches, either way...

1. Even if you have "umpteen" number of zones on a single machine, they all run off of the same kernel, so if you have to patch your kernel (or anything kernel-related) you need to do that from the "global" zone. If you apply a kernel patch on a local zone, and bring its kernel patch revision to a different level than the "global" zone's (and other zones') calamity will ensue (Let's see how many different ways I can write that something bad is going to happen ;)

2. "patchadd" will eventually drive you nuts, anyway, so the following proviso's should be no surprise ;).

a. If you run patchadd with -G in a "global" zone, any packages that have SUNW_PKG_ALLZONES set to true will cause the entire patch operation to fail.

b. If you run patchadd with -G in a "global" zone and "no" packages have SUNW_PKG_ALLZONES set to true, you should be able to install the patch to all zones from the "global" zone.

c. If you run patchadd without -G in a "global" zone, regardless of the setting of SUNW_PKG_ALLZONES, you can install the appropriate patches to any individual zones or the global zone (which will patch all the zones, by default).

d. If you run patchadd in a "local" zone, with or without -G specified, any packages that have SUNW_PKG_ALLZONES set to true will fail and not install, and if none have SUNW_PKG_ALLZONES set to true, everything should work in each "local" zone you apply the patch to.

3. Any software that can be installed at the "local" zone level, can also be patched independently at the "local" zone level, on whatever zones it was installed. This is true regardless of your zone type (whole root or sparse root).

4. The "-G" option to patchadd doesn't stand for "global zone," rather it stands for "the current zone." I can't think of a good mnemonic for this so "G"ood Luck ;) Of course, if you use this flag in the "global" zone, you can pretend it makes sense and stands for that. I do...

5. The "-t" option to patchadd is available for people who got used to the old patch error code numbers and know them by heart (like me. Well... most of them). Even on a system with zones, they make it so only a return code of "0" indicates absolute success. Any other number indicates a problem.

6. The "-R" option to patchadd (with zones enabled) cannot be used to reference the root filesystem in any zone other than the "global" zone. If you choose to ignore this warning and use it on a "local" zone anyway, side effects may include damage to the "local" zone's filesystem, damage to the "global" zone's filesystem, security problems with the "global" zone's filesystem, nauseau, fatigue, dry-eye, constipation, arthritis and random "night terrors." Contact your doctor if you have any trouble breathing calmly while patching "global" zones, as this may be the sign of a rare, but serious, side effect ;)

Happy patching. Here's to eventually being allowed to do it on the weekdays :)

, Mike

linux unix internet technology

Migrating Non-Global Zones Between Machines On Solaris 10

Apologies for the length of this post. I couldn't find any reasonable way to make it any shorter - so I'm including a link to where Sun is officially keeping all their documentation on this subject, should you want to explore it beyond this post. You can acess that info here!

As I always say when working with Solaris 10 (or whatever the latest version of Solaris is) you should do a trial run of a zone migration before you actually move any zone from one machine to another. Make up a bogus zone (like "origzone") set up the basic attributes and use that before you risk your important data!

The move is fairly simple at a high level (I will avoid breaching the subject of Solaris' RBAC to keep this at least somewhat short!):

1. The zone is halted and detached from its current host.
2. The zone is packed up.
3. The zonepath is moved to the target host, where it's attached.

In order to migrate the zone, you have to meet a few pre-requisites:

1. The global zone on the target system has to be running the same Solaris release as the original host.

2. To ensure that the zone will run properly, the target system needs to have the same versions of required OS packages and patches as the original. Any other packages and packages can be different; for instance any third party products and their respective patches don't need to be the same. Any packages that are OS-related and/or zone-inheritable must be included!

3. The host and target systems have to be of the same machine architecture (easily verifiable using "uname -m").

Once that's all been cofirmed, we're off! Running "zoneadm detach" on the original host sets the zone up so it can be attached to the target system. Running "zoneadm attach" on the target system attaches the migrated zone and verifies that the new system can host it.

Now we'll walk step-by-step through migrating the non-global zone from the original machine to the target host. Again, this process must be run as root in the global zone in order to ensure that it works without error (not to mention at all ;)

1. Become the root user and halt the zone to be migrated ("origzone" in this procedure).

orighost.xyz.com# zoneadm -z origzone halt

2. Now detach the zone.

orighost.xyz.com# zoneadm -z my-zone detach

3. Move the zonepath for origzone to the new host.

You can do this any way you want, basically. Just cd into /export/zones, and tar up the contents of the origzone directory. Then move the tarred up zone file to the target server using whatever file transfer facility you prefer, so that you have /export/zones/origzone set up on your target host.

4. On the target host, configure the zone:

targethost.xyz.com# zonecfg -z origzone

You will get a message from Solaris letting you know that origzone doesn't exist on the target machine, and needs to be created. This is only partially true ;)

5. To create the zone origzone on the target host, run "zonecfg -a /export/zones/origzone" on the target host. Then do the following:

zonecfg:origzone> create -a /export/zones/origzone

6. Make any necessary modifications to the configuration. For instance, to borrow from the example on sun.com, the NIC on the target host may be different, or other devices may not be the same. To change the NIC:

zonecfg:origzone> select net physical=ce0
zonecfg:origzone:net> set physical=bge0
zonecfg:origzone:net> end

7. Now, commit the new configuration and exit.

zonecfg:origzone> commit
zonecfg:origzone> exit

8. Attach the zone on the target host using the included validation.

targethost.xyz.com# zoneadm -z origzone attach

Note that, at this point, you'll be warned if you didn't meet any of the pre-requisites regarding required-same packages and patches on the target host, as we mentioned above.

As an additonal end-note, you can force the attach operation without performing the validation if you're absolutely sure that everything is okay and the message is in error. Of course, if the message is correct, and you're not, forcing the attach may result in random and bizarre zone behaviour later on. It's not recommended (By Sun or by me :)

targetzone.xyz.com# zoneadm -z origzone attach -F

Hopefully now you've gotten your zone migrated, and can script out as much as possible, to make mass migrations as simple and expeditious as possible in the future!

, Mike

linux unix internet technology