Creating And Deleting Local Zones On Solaris 10 Unix

Hey There,

Today's post is the final post in our quick series on dealing with local zones on Solaris 10. If you want to check the previous entries out, finish this paragraph. If you don't (or already have), just skip past this one :) The previous posts in this series have dealt with already-created local zones and how to create new file systems in a local zone on Solaris 10, modify filesystems in existing local zones and remove file systems in a local zone.

Today's "how to" is going to cover the bookends of this mini-series; creating local zones in Solaris 10 and destroying them.

NOTE: This notation is fairly obvious in this post (it was more appropriate in the following three), but I'll include it for completeness' sake. You have to be in the global zone to create or destroy a new local zone. See what I mean? ;) Also, resource/storage pools, etc, are outside the scope of this series of posts. If you're curious to learn a bit more about that aspect, check out our older series of posts dealing with using storage pools in Solaris 10. The link is to the final post, but all the preceding posts are linked to on that page; much like they are on this one.

Now, we'll go, step by step, through creating a local zone (up through the final "installation" phase) and, subsequently, undoing all of our hard work by destroying it ;)

1. First of all, fire up your old friend zonecfg and we'll get the party started. For our examples, we'll call our new local zone "DING" to maintain consistency with our other posts and we'll call our pool "CLOCK" (ding dong, yeah, it's sappy ;) You'll notice that you define the zone name when you invoke zonecfg, although just doing that doesn't actually "create" it, like so:

host # zonecfg -z DING <-- This is going to give you an error, but you can safely ignore it. Basically, the error just indicates that you're trying to configure a zone that hasn't been created yet. That's o.k., because we're just about to :)
zonecfg:DING> create

2. Next, we'll set up all of the minimally necessary parts of this local zone (note that we've already checked that enough resources (disk, IP, etc) exist in order for us to be able to install our new zone):

zonecfg:DING> set zonepath=/zones/DING/
zonecfg:DING> set autoboot=true <-- I would recommend leaving this as "false" until you know you're good, but the worst that can happen isn't really all that bad, since a local zone caught in an auto-boot-loop won't cause you the same headache a straight-up box with the same issue would.
zonecfg:DING> add net <-- Notice how this puts you in a sub-menu, which shows up in the prompt. This happens for most device configuration and is pretty helpful if you have to walk away from your build for a while and come back to a screen where someone's hit enter 500 times ;)
zonecfg:DING:net> set address=99.99.99.1
zonecfg:DING:net> set physical=bge0
zonecfg:DING:net> end <-- and this, universally, takes us back down (or up, depending on how you look at it) a menu, so we end up back at
zonecfg:DING>

3. Then, with the process just about completed, we'll assign the zone to the "CLOCK" storage pool (outside the scope of these posts, but you can checkout our older 4-part post on working with storage pools). Once that's complete, we'll verify our zone and commit the configuration, like this:

zonecfg:DING> set pool=CLOCK
zonecfg:DING> verify
zonecfg:DING> commit <-- This writes the configuration, which, up until this point, is held in-memory.
zonecfg:DING> exit (or ^D [Ctrl d])

4. The last step in creating a zone isn't entirely obvious. The first time I did this, I thought I was done when I completed step three. The zone was created, I'd assigned it all of the resources it required (and tweaked all of those) and then verified and committed the zone. Alas, I was wrong, there was still one last thing left to do.

The final act, in creating and enabling your new local zone is to "install" the zone with the zoneadm command. This will not only re-verify all of your zone's resources, check and see if your new zone will run on your system (or any other, for that matter), but also installs all the necessary files in the local zone's root filesystem and creates all mount points as necessary. It's very simple to run and very easy to deal with (Although it may take a little bit more time, even if your setup is good :) - Just run it, simply, like this:

host # zoneadm -z DING install
Preparing to install zone email-zone
...
Zone DING is initialized.

And that's, basically, all you need to do to set up a local zone :) Of course, you should run "zoneadm -z DING boot," zlogin, etc, to boot the zone up, login and run your own tests, just to be sure everything is the way you like it. If you need to make any adjustments, you can still use zonecfg to modify your zone's configuration (theoretically ad infinitum).

Now let's get to work ruining it all, by destroying our local zone ;) It's actually very simple and only includes one "real" step. We'll do the first part, just do to be polite, and shutdown the zone before we destroy it, like so:

host # zoneadm -z DING halt <-- Totally unnecessary if you're going to utterly destroy your zone anyway

Then, all we need to do is run one command to end it all:

host # zonecfg -z DING delete <-- You can also use the -F flag if it won't go away. Note, also, that no commit is necessary, as it was when we created the local zone.

And there we have it; the poignant story a local zone from birth to death ;)

Cheers,

, Mike

---

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

---

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.

---

Modifying Existing Local Zone File Systems On Solaris 10 Unix

Hey There,

Today's post is a follow-up to yesterday's post on creating new file systems in a local zone on Solaris 10. Today, we're moving on to a simple how-to on modifying existing local zones. As some of you may have noticed, with yesterday's post, I managed to blithely bypass the creation of the local zone we were working on. It's generally required that you create (or make) a local zone before you can add a filesystem to it ;) Although this topic is covered within our previous post on setting up Branded Linux zones in Solaris 10, we'll attack zone creation and initial setup at the end of this short series of posts, just so it has its own place and isn't presented in a, possibly, unfamiliar context.

Today's bit of work is a nifty trick because, although it seems that there should be some "special way" to modify an existing filesystem in a Solaris 10 zone, it's really about as simple, or as difficult, as you make it ( For this example, we'll be consistent with yesterday's post and have the "DING" local zone's "DONG" filesystem be of the type VxFS ).

NOTE: This caveat carries over from our previous post, as well. When modifying existing filesystems on a Solaris 10 local zone, all changes must be made to the filesystem from the global zone!

1. Log into your global zone again. This is generally just the "host" or what we used to think of (before zones or containers) as "the box" or "the computer." Then, check out the filesystem you want to modify, with "df -k|grep DONG" (or something similar), like so:

host # df -h|grep DONG
/dev/vx/dsk/DINGdg/DONGvol 6547824 24356 6523468 1% /DONG

2. Now, you can simply resize (shrink, grow, etc -- this part is heavily dependent on your filesystem and its capabilities) as you would normally. We've attacked the following procedure in much more depth in our previous post on adding and managing storage with Veritas Volume Manager, so we'll leave this example boiled down to the essentials. For our example, we want to add 10 Gb of space to the "DONG" filesystem. And, we can do so, just as simply as if we were modifying any other VxFS filesystem, like this:

host # vxresize -g DINGdg DONGvol +10g

3. And that's it! Now all we have to do is verify that the filesystem actually grew, by issuing the exact same command we did in step 1. It should be noted that we used "vxresize" specifically (rather than "vxassist -growby") so that we wouldn't have to run two commands to increase the capacity of the volume and grow the filesystem on it. Depending on your situation, you may need to do both separately, but you'll still be following standard protocol for whatever disk management tool you prefer to use, rather than modifying your method to suit Solaris:

host # df -h|grep DONG
/dev/vx/dsk/DINGdg/DONGvol 17033584 24356 17009228 1% /DONG

And, there you go. Simple as pie, and the work week is just about half over :)

Cheers,

, Mike

---

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

---

Solaris 10 - 5/08 Release: ZFS-Rooted Zones Getting Better!

Hey There,

Before anyone starts phoning in, I do realize this is not "brand new" :) It's just brand new to me and the place I work. Now that we're starting to pull in some of those Mx000 Series Boxes, we're finally up to date on Solaris 10! Plus, I'm sure it's patched to the gills ;)

Today's post is going to be almost like a press release, because the folks at Sun have released so much more information than I can process in a day that I felt it was best to let them figuratively speak for themselves ;) As you can tell by the headline today, Solaris 10 is finally starting to move in a few directions I've been hoping it would for a long long time!

Although there are a number of significant improvements in the OS, I think the home run on this release (5/08) is the ability to, at last, create zones that support zfs root filesystems without as many hassles and limitations as their previous releases! (For more whining about the headaches you may have become accustomed to already, and how to get around some of them, check out our older post on dealing with ZFS rooted zones on Solaris 10 ;) Strangely enough it's one of the things they tout the least. Another very interesting thing (for me, anyway ;) is that they've included the freeware 7-Zip utility that has long been a favorite of mine. It's, also, the last thing on the page. I'm starting to get the feeling Sun doesn't take me all that seriously...

Without further ado, check out the latest and greatest list of augmentations to Solaris 10. You can access the Official Sun 5/08 Release Notes Page if want to have easier access to past release notes and other relevant information.

Enjoy! I'm going to play around with this release a bit and see if I haven't been deluding myself ;)

Cheers,

---

Chapter 1 What's
New in the Solaris 10 5/08 Release

For a summary of features that were introduced in the Solaris 9, Solaris
8, or Solaris 7 releases, see What's New in the Solaris 9 Operating
Environment at http://docs.sun.com.

System Administration Enhancements

The following system administration features and enhancements have been
added to the Solaris 10 5/08 release.

Solaris Trusted Extensions Administrator Procedures

Starting with this release, the Solaris^TM Trusted
Extensions packages are installed when the Solaris OS is installed. The ExtraValue directory is no longer present. This directory previously
included the Solaris Trusted Extensions packages. The Solaris Trusted Extensions
functionality is managed by the service management facility (SMF) as the svc:/system/labeld:default service. This service must be enabled.
After the service is in the online state, reboot the system to activate Solaris
Trusted Extensions. Additional configuration is required after the reboot.
For more information, see Solaris
Trusted Extensions Configuration Guide.

The Solaris 10 5/08 release also includes the following features:

• 
  

  The domain of interpretation (DOI) is configurable. For more
  information, see Network Security Attributes in Trusted Extensions in Solaris Trusted Extensions Administrator’s Procedures.

  
  
  
  


• 
  

  The NFSv3 protocol supports multilevel mounts. For more information,
  see Trusted Extensions Software and NFS Protocol Versions in Solaris Trusted Extensions Administrator’s Procedures.

  
  
  
  


• 
  

  The name service cache daemon, nscd, can
  be separately configured per labeled zone. This configuration supports environments
  where each zone is connected to a subnetwork that runs at the label of the
  zone, and the subnetwork has its own name server for that label.

  
  
  
  

For more information about Solaris Trusted Extensions, see Solaris Trusted Extensions
Administrator’s Procedures.

Flash Update Tool

fwflash(1M) is a new Solaris command for the manipulation
of firmware for PCI-X, and PCI-Express HBA and HCA cards. Currently, the command
enables listing, reading, and writing the firmware for the InfiniBand HCA
cards.

For more information about this command, see the fwflash(1M) man page.

PPD File Management Utility

The PostScript^TM Printer Description (PPD) file
management utility, /usr/sbin/ppdmgr, manages PPD files
that are used with the Solaris print subsystem.

By using the ppdmgr utility, you can perform the
following tasks:

• 
  

  Add a PPD file to a PPD file repository on a system

  
  
  
  


• 
  

  Supply a label to group PPD files within a PPD file repository

  
  
  
  


• 
  

  Update the cache of the PPD file information that is used
  by the Solaris Print Manager (printmgr) GUI to display
  supported printer information

  
  
  
  

You can add a new PPD file by using the ppdmgr utility
or by using the lpadmin -n command. When
you add a new PPD file, you automatically update the cache of the PPD file
information that the printmgr GUI uses to display supported
printer information.

---

Note –

The delivery location of PPD files in the Solaris OS has changed.
During a software upgrade, any print servers with print queues that were defined
by using PPD files from the previous PPD file delivery location are automatically
updated to reflect the new PPD file delivery location.

---

In addition, a new SMF service, print/ppd-cache-update, has been introduced.
The print/ppd-cache-update service is enabled by default. This service runs
one time during system reboot to update the printer cache information with
changes from all the PPD file repositories on the system. The service might
take longer to transition to an online state during a system reboot after
a software installation or upgrade. Also, if any changes were made to the
PPD file repositories since the last PPD cache update, during system reboot,
the service might take longer to come online. Changes made to the PPD file
repositories on a system are not reflected in the PPD cache used by Solaris
Print Manager until the print/ppd-cache-update service is online.

For more information, see the following:

• 
  

  
  ppdmgr(1M) man
  page

  
  
  
  


• 
  

  
  Chapter
  9, Administering Printers by Using the PPD File
  Management Utility (Tasks), in System
  Administration Guide: Solaris Printing
  

  
  
  
  

Internet Printing Protocol Client-Side Support

Client-side support for the Internet Printing Protocol (IPP) enables
Solaris client systems to communicate with IPP-based print services, such
as those on the Linux and Mac OS X operating systems, as well as other platforms.

Small improvements are also featured in the server-side support for
the IPP listening service. These improvements promote better interoperability,
including some minor changes that result in a more standard representation
of printer and job attribute data.

The IPP server and client implementation in the Solaris OS is one of
several OpenSolaris^TM printing projects that are currently
under development. OpenSolaris printing provides a set of specifications and
implementations of software that enables you to create standardized, scalable
printing components for the Solaris and Linux software, or any operating system
that contains a set of POSIX interfaces.

For more information, see the System Administration Guide: Solaris Printing.

For more information about OpenSolaris Printing, see http://opensolaris.org/os/community/printing/.

Selectable Use of localhost for
Solaris Print Server Database Hostname

This printing feature enables the Solaris print system to recognize
and use localhost as the local host in the print system
databases. In prior releases, /bin/hostname was used
solely to generate the print hostname. The print system depended on this name
remaining constant. The ability to use localhost as the
name of the current system enables print servers to maintain the same print
hostname, independent of the system's host name.

---

Note –

The modification applies to the setup of local print queues exclusively.

---

To support this feature, the following modifications are effective for
the lpadmin command and the Solaris Print Manager graphical
user interface (GUI):

• 
  

  The lpadmin command uses the -s option
  when creating a local print queue.

  
  
  

  To use localhost as
  the host name that is specified within the print server, set the print hostname
  to localhost, as shown:

  
  
  
  
  
  
  

  # lpadmin -p <new-print-queue> -s localhost -v <device>

  
  

  For example:

  
  
  
  
  
  
  

  # lpadmin -p foo -s localhost -v /dev/term/a

  
  

  ---

  
  Note –
  

  The default behavior of the lpadmin command
  has not changed.

  
  
  

  ---

  
  
  
  


• 
  

  Solaris Print Manager now includes an added tool attribute
  check box, Use localhost for Printer Server. The localhost attribute is selected by default. To deselect the localhost attribute,
  uncheck the box. Unchecking the box selects the previously chosen behavior
  for this attribute.

  
  
  
  

For more information, see the following:

• 
  

  
  printmgr(1M) man
  page

  
  
  
  


• 
  

  
  lpadmin(1M) man
  page

  
  
  
  


• 
  

  
  System
  Administration Guide: Solaris Printing
  

  
  
  
  

Fault Management for T5140/T5240 Platforms

The Solaris predictive self-healing technology is available on Sun SPARC
Enterprise T5140 and T5240 platforms. Predictive self-healing features include
the following:

• 
  

  Automated error handling

  
  
  
  


• 
  

  Automated diagnosis

  
  
  
  


• 
  

  Automated recovery for CPU, memory and I/O subsystems

  
  
  
  


• 
  

  Clear and concise error messages

  
  
  
  

For more information, see http://www.sun.com/software/solaris/ds/self_healing.jsp and http://opensolaris.org/os/community/fm.

SunVTS 7.0

SunVTS^TM is a comprehensive system validation and
test suite designed to support Sun hardware platforms and peripherals. SunVTS
7.0 is the next generation of SunVTS 6.0 and its compatible versions.

SunVTS 7.0 includes the following features:

• 
  

  Introduction of the concept of purpose-based testing

  
  
  
  


• 
  

  Improved diagnostics effectiveness

  
  
  
  


• 
  

  Web-based user interface

  
  
  
  


• 
  

  Simplified usage

  
  
  
  


• 
  

  New architecture framework

  
  
  
  


• 
  

  Enterprise View

  
  
  
  

SunVTS 7.0 follows a conventional three-tier architecture model. This
model is composed of a browser-based user interface, a Java based middle server,
and a diagnostic agent.

System Resource Enhancements

The following system resource features and enhancements have been added
to the Solaris 10 5/08 release.

CPU Caps

CPU caps provide absolute fine-grained limits on the amount of CPU resources
that can be consumed by a project or a zone. CPU caps are provided as a zonecfg resource, and as project and zone-wide resource controls.

• 
  

  The zonecfg capped-cpu resource provides
  an absolute limit on the amount of CPU that can be consumed by a project or
  a zone.

  
  
  
  


• 
  

  The following resource controls are available:

  
  
  
  

  
  

  zone.cpu-cap

  
  

  
  

  Absolute limit on the amount of CPU resources that can be
  consumed by a non-global zone.

  
  
  

  
  

  project.cpu-cap

  
  

  
  

  Absolute limit on the amount of CPU resources that can be
  consumed by a project.

  
  
  

  
  

  
  
  
  

For more information, see the following:

• 
  

  
  zonecfg(1M) man
  page

  
  
  
  


• 
  

  
  zones(5) man
  page

  
  
  
  


• 
  

  
  System
  Administration Guide: Solaris Containers-Resource Management and Solaris Zones
  

  
  
  
  

projmod(1M) Option

Use the projmod command with the -A option
to apply the resource control values defined in the project database to the
active project. Existing values that do not match the values defined in the
project file, such as values set manually by prctl(1),
are removed.

Device Management Enhancements

The following device management features and enhancements have been
added to the Solaris 10 5/08 release.

Tape Self-Identification

The tape self-identification feature configures the tape automatically,
with the parameters provided by the tape drive. Previously, the configuration
data for a tape drive was statically supplied through user-editable configuration
files, built-in configuration tables, or default values. The tape-self identification
feature uses a few SCSI commands to directly query the required parameters
from the tape drive. When the st driver gets the parameters,
the tape drive uses them on the Solaris OS.

The advantages of tape-self identification over the traditional file-based
configuration are:

• 
  

  Simple and no user intervention is needed

  
  
  
  


• 
  

  Faster support for new tape drives

  
  
  
  


• 
  

  Easy to use, standard-based interface

  
  
  
  

x86: Enhanced Speedstep CPU Power Management

Starting with this release, Intel's Enhanced Speedstep^TM technology
is supported on the Solaris OS. Enhanced Speedstep support enables Solaris
platform users to manage the power consumption of their Intel processors by
lowering the processor frequency during idle periods.

For more information about how to enable Solaris CPU power management,
see the power.conf(4) man
page.

x86: PowerNow! CPU Performance Management

Starting with this release, AMD's PowerNow! technology is supported
on the Solaris OS. PowerNow! support enables Solaris platform users to manage
the power consumption of their Opteron 10h family of processors by adjusting
the processor operating frequency and voltage according to the task being
performed.

For more information about how to enable Solaris CPU power management,
see the power.conf(4) man
page.

iSNS Support in the Solaris iSCSI Target

This Solaris release provides support for the Internet Storage Name
Service (iSNS) protocol in the Solaris iSCSI target software.
The iSNS protocol enables automated discovery, management, and configuration
of iSCSI devices on a TCP/IP network.

The Solaris iSCSI target software does not include native iSNS server
support. However, in this Solaris 10 release, you can add access to an existing
iSNS server to automatically discover the iSCSI devices in your network.

The iscsitadm command is used to configure the Solaris
iSCSI target to discover the iSNS server and enable or disable the iSNS discovery.
Use the hostname or the IP address to specify the iSNS server.

For more information, see the iscsitadm(1M) man page and Chapter 14, Configuring
Solaris iSCSI Targets and Initiators (Tasks), in System Administration Guide: Devices and File Systems.

Security Enhancements

The following security features and enhancements have been added to
the Solaris 10 5/08 release.

Solaris Trusted Extensions Supports Mounting Labeled
File Systems With the NFSv3 Protocol

Starting with this release, the Solaris Trusted Extensions software
can mount labeled file systems by using NFS Version 3 (NFSv3) in addition
to NFS Version 4 (NFSv4). Solaris Trusted Extensions has no restrictions on
using TCP as an underlying transport protocol for NFS. However, users cannot
choose User Datagram Protocol (UDP) as the underlying protocol for read-down
NFS access for NFSv3. The use of UDP for the initial mount operation is supported,
but UDP is not supported for subsequent multilevel NFSv3 operations.

SPARC: Hardware -Accelerated Elliptical Curve
Cryptography (ECC) Support

The UltraSPARC T2 (Niagara 2) based platforms support hardware acceleration
of Elliptical Curve Cryptography (ECC) algorithms. The Solaris OS now supports
high performance ECDSA and ECDH on these platforms. These new ECC algorithms
are accessible to all users of the Solaris Cryptographic Framework including
Java technology and OpenSSL users.

Networking Enhancements

The following networking features and enhancements have been added to
the Solaris 10 5/08 release.

Sockets Direct Protocol

The Sockets Direct Protocol (SDP) is a transport protocol layered over
the Infiniband Transport Framework (IBTF). SDP is a standard implementation
based on Annex 4 of the Infiniband Architecture Specification Vol1. SDP provides
reliable byte-stream, flow controlled two-way data transmission that is very
similar to TCP.

For more information see sdp(7D) man
page.

inetd Backlog Queue Size

Starting with this release, a tunable to set the backlog queue size
of the inetd managed services is introduced. This feature
adds an SMF property to inetd called connection_backlog that enables the queue size to be modified. The default value of
the connection_backlog queue size is 10. You can modify
the connection_backlog property by using the inetadm command.
For example:

• 
  

  To list the properties, type:

  
  
  
  
  
  
  

  #inetadm -l fmri/pattern

  
  
  


• 
  

  To change the value for a specific service, type:

  
  
  
  
  
  
  

  #inetadm -m fmri/pattern conection_backlog=new value

  
  
  


• 
  

  To change the value globally, type:

  
  
  
  
  
  
  

  #inetadm -M connection_backlog=newvalue

  
  
  

For more information, see the inetadm(1M) man page.

X11 Windowing Enhancements

The following X11 windowing features and enhancements have been added
to the Solaris 10 5/08 release.

Xvnc Server and Vncviewer Client

VNC provides a remote desktop session over the Remote Frame Buffer (RFB)
protocol. RFB clients, better known as VNC viewers, are available for most
platforms, in both open-source and commercial releases.

The Solaris 10 5/08 release now includes Xvnc. Xvnc is an X server that
is based on the open-source releases from the RealVNC project and X.Org Foundation.
Xvnc is displayed to an RFB protocol client over the network without requiring
an existing X server session display on the local video hardware. This release
also includes RealVNC's vncviewer RFB client to connect to remote VNC servers,
and several associated programs for managing these servers.

For more information, see System Administration
Guide: Virtualization Using the Solaris Operating System. See
also the Xvnc(1) and vncviewer(1) man
pages.

Desktop Tools Enhancements

The following desktop tools features and enhancements have been added
to the Solaris 10 5/08 release.

StarOffice 8

Starting with this release, StarOffice has been enhanced to the latest
version, StarOffice 8.

For more information about StarOffice, see http://www.sun.com/software/star/staroffice/whats_new.jsp.

Flash Player 9

Stating with this release, the Solaris OS includes the Adobe Flash Player
9. For more information about this Flash Player, see http://www.adobe.com/products/flashplayer/productinfo/features/.

Pidgin 2.0

Pidgin is a popular open-source instant messaging client. Pidgin 2.0
includes the following features:

• 
  

  Many improvements to the UI modules including status system,
  Buddy List, Conversation, and the chat window

  
  
  
  


• 
  

  New Yahoo features including Stealth Settings, Doodle, and
  the /list command

  
  
  
  


• 
  

  Improved AIM and ICQ file transfers

  
  
  
  


• 
  

  Improved Log Viewer module

  
  
  
  


• 
  

  Support for the new version of ICQ file transfer

  
  
  
  


• 
  

  New IRC features including SSL support, and the new commands /whowas, /nickserv, /memoserv, /chanserv, and /operserv
  

  
  
  
  


• 
  

  Jabber features including support for SRV lookups, buddy icons,
  and Jabber User Directory searching

  
  
  
  

PAPI Print Commands

The Free Standards Group (FSG) Open Printing API (PAPI) commands replace
several commonly used print commands, which include the following:

• 
  

  
  cancel(1)
  

  
  
  
  


• 
  

  
  disable(1)
  

  
  
  
  


• 
  

  
  enable(1)
  

  
  
  
  


• 
  

  
  lp(1)
  

  
  
  
  


• 
  

  
  lpstat(1)
  

  
  
  
  


• 
  

  
  lpc(1B)
  

  
  
  
  


• 
  

  
  lpq(1B)
  

  
  
  
  


• 
  

  
  lpr(1B)
  

  
  
  
  


• 
  

  
  lprm(1B)
  

  
  
  
  


• 
  

  
  accept(1M)
  

  
  
  
  


• 
  

  
  lpmove(1M)
  

  
  
  
  


• 
  

  
  reject(1M)
  

  
  
  
  

The implementations of the Open Printing API commands are layered on
top of the Free Standards Group Open Printing API in the Solaris OS. This
implementation enables the commands to run on top of multiple protocols or
services.

Some advantages of the new print command implementations include the
following:

• 
  

  Improved consistency between desktop applications and command-line
  interfaces

  
  
  
  


• 
  

  Multiple print protocols and service support from the command
  line

  
  
  
  


• 
  

  Internet Print Protocol (IPP) client-side support for improved
  interoperability with Linux, Mac OS X, and other IPP-based print services

  
  
  
  


• 
  

  Enhanced remote capability and data when using IPP between
  print client and server

  
  
  
  


• 
  

  The capability to disable network services and retain access
  to local printers

  
  
  
  

For more information about the PAPI print commands, see the following:

• 
  

  
  PAPI Implementation in the Solaris OS (Reference) in System Administration Guide: Solaris Printing
  

  
  
  
  


• 
  

  OpenSolaris Printing Community web pages at http://opensolaris.org/os/community/printing/projects/papi_client_commands/
  

  
  
  
  

System Performance Enhancements

The following system performance features and enhancements have been
added to the Solaris 10 5/08 release.

64-bit SPARC: Memory Placement Optimization
Support for sun4v Platforms

Memory Placement Optimization (MPO) enables operating systems to allocate
memory local to the core where the threads or processes are being executed.
The sun4v architecture runs on virtualized hardware environment. The MPO for
sun4v platforms feature provides the required standard accessors in the sun4v
layer to provide locality information for the generic MPO framework. This
feature is effective on platforms that have multiple sockets with differences
in memory access latency. The MPO feature enhances the performance of various
applications by enabling the OS to allocate memory local to the nodes.

SPARC: Shared Contexts Support

The context mechanism, which is used by the Memory Management Unit (MMU)
hardware to distinguish between the use of the same virtual address in different
process address spaces, introduces some inefficiencies when shared memory
is used. The inefficiencies in shared memory are because the data at a particular
shared memory and the address in different processes might really be identical,
but the context number associated with each process is different. Therefore,
the MMU hardware cannot recognize a match. This inability to recognize a match
results in mappings being unnecessarily evicted from the MMU translation cache
and the Translation Lookaside Buffer (TLB), only to be replaced by identical
mappings with a different context number.

The Niagara 2 system has an additional shared context, which is a hardware
feature that can be used to prevent the inefficiency in handling shared memory.
Searching the TLB for mapping a match on either the private or the shared
context results in a TLB hit. The current software support for shared context
activates the feature for processes that use the Dynamic Intimate Shared Memory
(DISM). In this case, the process text segment and DISM segments mapped at
the same virtual address with the same permissions for each process use the
shared context.

x86: CPUID-Based Cache Hierarchy Awareness

Modern Intel processors provide an interface for discovering information
about the cache hierarchy of the processor through the CPUID instruction.

Language Support Enhancements

The following language support features and enhancements have been added
to the Solaris 10 5/08 release.

Locale Creator

Locale Creator is a command line and graphical user interface tool that
enables users to create and install Solaris locales. Using locale creator
users can create installable Solaris packages containing customized locale
data of a specific locale. After the created package has been installed, the
user has a fully working locale on the system.

For more information, see the following:

• 
  

  The command /usr/bin/localectr -h
  

  
  
  
  


• 
  

  
  localectr man page

  
  
  
  


• 
  

  
  http://developers.sun.com/global/products_platforms/solaris/reference/techart/locale-creator.html
  

  
  
  
  

libchewing 0.3.0

Chewing input method (IM) is based on libchewing, which is an open-source
library for Traditional Chinese input. libchewing has been upgraded to the
libchewing 0.3.0 version. Some of the features of the new version include
the following:

• 
  

  Incompatibility with API/ABI.

  
  
  
  


• 
  

  UTF-8 based language engine core for common Unicode environment.

  
  
  
  


• 
  

  Includes the libchewing-data subproject.

  
  
  
  


• 
  

  Zuin fixes and symbol improvements.

  
  
  
  


• 
  

  New binary form of user hash data to speed up loading and
  solving hash data corruption.

  
  
  
  


• 
  

  Improved calculation of internal tree and phone constants.

  
  
  
  


• 
  

  Revised tsi.src for richer phrases and avoiding crashes.

  
  
  
  


• 
  

  Merge phone and phrase from CNS11643.

  
  
  
  


• 
  

  Improved Han-Yu PinYin to use table-lookup implementation.

  
  
  
  


• 
  

  Experimental frequency evaluation that re-computes chewing
  lifetime.

  
  
  
  


• 
  

  Implementation of the choice mechanism for symbol pairs.

  
  
  
  


• 
  

  Experimental, memory mapping-based, binary data handling to
  speed up data loading.

  
  
  
  

For further information, see the International
Language Environments Guide.

File Encoding Examiner

The File Encoding Examiner (fsexam) enables you to convert the name
of a file, or the contents of a plain-text file, from a legacy character encoding
to UTF-8 encoding. New features in the fsexam utility include the following:

• 
  

  Encoding list customization

  
  
  
  


• 
  

  Encoding auto-detection

  
  
  
  


• 
  

  Support for dry runs, logs, batch conversion, file filtering,
  symbolic files, command line, and special file types like compress file

  
  
  
  

For more information, see the fsexam(1) and fsexam(4) man pages.

Kernel Functions Enhancements

The following kernel functions features and enhancements have been added
to theSolaris 10 5/08 release.

x86: MONITOR and MWAIT CPU Idle Loop

The Solaris OS uses the SSE3 MONITOR and MWAIT instructions in the x86
processor idle loop. Using the SSE3 instructions in the processor idle loop
eliminates the overhead of sending and receiving an interrupt to wake up a
halted processor. MONITOR is used to specify a memory range to monitor the
idle loop. MWAIT halts the processor until the address previously specified
with MONITOR is accessed. With the new idle loop, a processor has to write
to memory only to wake up a halted processor.

Driver Enhancements

The following driver features and enhancements have been added to the
Solaris 10 5/08 release.

x86: Support Sun Fire X4540 Disk Status Indicators

Starting with this release, the Sun Fire X4540 disk status indicators
are supported. The amber Fault status LED and blue Ready to Remove status
LEDs are enabled by this feature.

For more information, see the Sun Fire X4540
Server Diagnostics Guide.

MPxIO Extension for Serial Attached SCSI Devices
on mpt(7D)

The mpt driver has been enhanced to support MPxIO
with supported storage devices. When MPxIO is enabled for Serial Attached
SCSI (SAS) and SATA devices, they are enumerated under scsi_vhci(7D)
just like fibre channel devices under fp(7D).

Starting with this release, stmsboot(1M) has also
been enhanced to support multipathed SAS devices. stmsboot(1D)
operates on all attached and multipath-capable controllers by default.

If you wish to only enable multipathing on fp or mpt controllers then you can use the new flag which has been added
to restrict operations. The command, /usr/sbin/stmsboot -D mpt -e, will enable MPxIO only on attached mpt controllers.
Replacing mpt with fp in this command
will make stmsboot enable MPxIO only on attached fp controllers.

x86: SATA ATAPI Support in AHCI Driver

The AHCI driver supports SATA ATAPI CD or DVD devices. Users can use
the SATA CD or DVD in AHCI mode instead of the compatible mode. The AHCI mode
has better error handling and hot-pluggable capabilities.

For more information, see the ahci(7D) man page.

x86: AMD–8111

The AMD-8111 HyperTransport I/O hub includes a 10/100 Mbps Ethernet
LAN controller. The driver is used by the Andretti platform.

SATA NCQ Support in AHCI Driver

The AHCI driver supports the SATA NCQ feature. NCQ support improves
performance of the driver.

For more information, see the ahci(7D) man page.

x86: bnx II Ethernet Driver

Starting with this release, support is provided for the Broadcom NetXtreme
(bnx) II Ethernet chipset, which includes BRCM5706C, BRCM5706S, BRCM5708C,
and BRCM5708S.

For more information, see the bnx(7D) man page.

USB-to-Serial Driver for Keyspan Adapters

Starting with this release, a new driver is provided for Keyspan USB-to-serial
adapters. This driver supports the USA-19HS model. This feature enables you
to choose between Edgeport adapters and Keyspan adapters.

For further information, see the usbsksp(7D) man page.

Freeware Enhancements

The following freeware features and enhancements have been added to
the Solaris 10 5/08 release.

32-bit: pgAdmin III

pgAdmin III is a popular and feature-rich, open-source administration
and development platform for PostgreSQL. The graphical interface supports
all PostgreSQL features and makes administration easy. This tool enables users
to write simple SQL queries and also to develop complex databases.

For more information, see http://www.pgadmin.org/.

p7zip

Starting with this release, the Solaris OS includes p7zip port. p7zip
is similar to the Windows compression and archiving utility, 7zip.

For more information, see http://p7zip.sourceforge.net/.

, Mike

---

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

---

Branded Linux Zones In Open Solaris?

Hey again,

Today, we're going to be looking at installing "branded" zones in Open Solaris; specifically, RedHat Enterprise Linux (although CentOS is also supported). We'll take a look at what Linux OS's and hardware are supported in Open Solaris, do a quick rundown of how to set up a Branded Linux zone and sneak a quick peak at some test results from Sun's site.

STOP: Please.. Before you go any further, read this paragraph regarding the question mark at the end of this post's title. Today's post is a bit lengthy (mostly due to examples of the configuration of Linux Branded zones on Open Solaris) so, if you're thinking to yourself something along the lines of "why in the world would I want to run Linux on top of Solaris on a machine that's perfectly capable of running Linux without Solaris?," or "I already use VMWare, or something similar, to virtualize Linux hosts on a single physical machine, so what do I need with an extra Operating System?" you should just stop reading right now. Following is a long list of specifications and walk-throughs that will probably not change your mind or your answer to either question. If you're just curious, hop on in. The water's fine ;)

Supported Hardware for Linux Branded zones (This definition is fairly loose, since all I could find were lists of supported processors - I guess the natural assumption would be that, if you can get Branded Linux to run on your Open Solaris box, you'd be able to use any other hardware that would normally be supported by RedHat or CentOS):

Intel Chipset - Pentium Pro, Pentium II, Pentium III, Celeron, Xeon, Pentium 4, PentiumM, PentiumD, Pentium Extreme Edition, Core, Core 2 (x86 in general)
AMD Chipset - Opteron, Athlon XP, Athlon 64, Athlon 64 X2, Athlon FX, Duron, Sempron, Turion 64, Turion 64 X2 (x64 in general)

Supported Linux Operating Systems: RedHat Enterprise Linux 3.x and the CentOS equivalent.

Supported Linux Kernels: kernel 2.4.21/glibc 2.3 is "emulated" by Sun's Branded Linux zone. If you attempt to install RedHat (or any Vendor's) Linux that doesn't use this kernel/gcc revision, there's no guarantee that it will work at all.

On to the good stuff. How to set up a Linux Branded zone on Open Solaris:

1. Download and install the Open Solaris/Solaris Express - Community Release from opensolaris.org. You have your choice of 6 CD's, a 2 segment DVD or a single image DVD. Extras, including a CentOS tarball and additional script for Scientific Linux 3.0.8 can be found at the Branded Zones Download Page.

NOTE: If you already have Open Solaris 10 Release 8/07 or newer installed, you probably won't need to re-install, upgrade or add any pkg's to your existing configuration. An easy way to tell if you already have support for Branded Zones installed (assuming you're running Open Solaris, of course :) is to use the zoneadm command's list option:

host # zoneadm list -v 
ID NAME             STATUS     PATH                           BRAND
0  global           running    /                              native
host # head -1 /etc/release
Solaris 10 8/07 s10x_u4wos_12b X86
host # uname -a
SunOS TheDeadZone 5.10 Generic_120012-14 i86pc i386 i86pc

since we see that there's a "BRAND" column, we know that we're okay to proceed. The output from /etc/release confirms the date. I always like to use "zoneadm list" to make extra sure, as I will generally replace the contents of /etc/release-type files on boxes I build with a generic security warning, so that I don't advertise what version of exploits people should look for when they're thinking about attacking my site. For this reason I also check the output of "uname -a" to be sure that we have an x86 or x64 processor. Sparc-based systems support Branded zones as well, but don't support the Linux Branded zone!

Finally, check that you have the Linux Branded zone pkg file installed:

host # pkginfo|grep SUNWlx

If you get an error that this package cannot be found, you should be able to download it from opensolaris.org or get it off of your installation media. Also, and this is a point that sometimes get missed, make sure that you're running "Open Solaris" and not "Solaris 10" - Some folks (like me, for instance, when they both first came out) confuse them with one another or, more commonly, may assume they're the same thing.

2. From the "global" zone on your system, use the zonecfg command to begin setting up the zone:

host # zonecfg -z linuxzone <-- You will probably receive an error here, like "No such zone. Use create..." etc. This is normal for the first time you invoke zonecfg with a not-yet-existent zone name.
zonecfg:linuxzone> create -t SUNWlx <-- here we're using the -t flag that, technically stands for "template." In this instance we're using the SUNWlx pkg as the template for the Branded zone, rather than a template from another similar zone that we'd already created. It's more confusing to explain than it is to do ;)

And then, we proceed to install the bare necessities (zonepath, network adapter address, etc), similar to the following (this example is very sparse compared to the amount of options you can set in the zone, but will allow you to build and run):

zonecfg:linuxzone> set zonepath=/export/linuxzone_root <-- this directory will be created for you when the "commit" step is taken.
zonecfg:linuxzone> add net
zonecfg:linuxzone:net> set address=10.10.99.99/16
zonecfg:linuxzone:net> set physical=ce1
zonecfg:linuxzone:net> end <-- This just ends the network part. If we were doing a more complex setup, we could continue to add more attributes after going from the net setup back to the basic setup (shown in the zonecfg prompt)
zonecfg:linuxzone> commit
zonecfg:linuxzone> exit <-- It should be noted that if you just "exit," the zonecfg command will attempt to do a "commit" anyway. This is okay, if you decided you didn't want the zone, because you can destroy it just as easily as you created it ("zonecfg -z linuxzone delete -F" should do it). Just FYI :)

If you're so inclined, you can also do this all from the command line in one fell swoop. Until you get comfortable with it, it's generally easier to use the interactive mode, as shown above, since your zone setup has the potential to be as incredibly complicated and specific as you'd like and interactive mode allows you to ask for context-relevant help.

host # zonecfg -z linuxzone "create -t SUNWlx; set zonepath=/export/linuxzone_root; add net; set address=10.10.99.99/16; set physical=c1; end; commit"

3. Now, we need to install our new Linux Branded zone, from the global zone on our host:

Ensure that "volfs" is running (unless you're not installing Linux from a CD or DVD):

host # svcs | grep volfs <-- It's not running, so we'll start it. It doesn't hurt either way.
host # svcadm enable svc:/system/filesystem/volfs:default
host # svcs | grep volfs
online 14:22 svc:/system/filesystem/volfs:default

Now, either install from a tarball on the local system, like so:

host # zoneadm -z linuxzone install -d /path/to/tarball

or you can be specific about where you want the CD image to be read from:

host # zoneadm -z linuxzone install -d /cdrom/cdrom0 <-- /cdrom/cdrom0 is actually the path that gets used by default if you don't supply the -d option on the command line.

or

host # zoneadm -z linuxzone install -d /path/to/your/RedHat/ISO <-- If you want to install from an ISO or other image

If you prefer to be as specific as you can, at this point, you can follow any of the above commands with a directive indicating a subset of packages that you want installed, instead of the entire distribution. Your options are: core, server, desktop, developer and all - with each subset of packages containing more stuff that you may or may not need. Each subset (in order) is hierarchical, so the "developer" subset contains all the packages in core, server and desktop, as well. I don't know exactly what packages are in which, but on the Open Solaris BrandZ Site it must be listed out somewhere. Or, maybe not ;) - So assuming we wanted to install the server subset, our command would only be altered to a slight degree from:

host # zoneadm -z linuxzone install -d /cdrom/cdrom0

to

host # zoneadm -z linuxzone install -d /cdrom/cdrom0 server

4. Now we'll verify that the zone is installed using the same command from step 1, except we'll add the "-i" flag to show "installed" zones as well as running ones:

host # zoneadm list -iv 
ID NAME             STATUS     PATH                           BRAND
0  global           running    /                              native
1  linuxzone        installed  /export/linuxzone_root         lx

5. And, finally, assuming all has gone well, we can boot the Branded Linux Zone, like so:

host # zoneadm -z linuxzone boot

double check it to make sure it's out of the "installed" state:

host # zoneadm list -iv 
ID NAME             STATUS     PATH                           BRAND
0  global           running    /                              native
1  linuxzone        running   /export/linuxzone_root          lx 

and then we can login (NOTE: You have to log in locally with Linux Branded zones at this point. Even though we configured networking in the zone, the network interface won't work properly until we do the next few quick steps. Goofy ;)

host # zlogin linuxzone

linuxzone # hostname
linuxzone

6. Now, we'll set up the networking. You do it pretty much exactly the way you do in RedHat, normally. At the very simplest (since we only have one NIC and one IP), we'd just edit /etc/sysconfig/network and add:

NETWORKING=yes
HOSTNAME=linuxzone

and then just type:

linuxzone # reboot

like you would on a normal machine and it should come back up with networking all set. You can bring up the network manually, in a number of ways, also, but (at least on the first go at installation) I like to do the reboot so I can see if there are any startup errors that I might need to check out. You can also do the whole reboot process from the global zone using the zoneadm command (zoneadm -z linuxzone reboot) after simply exiting from your login shell in the new zone.

And that's all there is to it :)

If you eventually find this to be a "huge" waste of your time, don't say I didn't warn ya ;) If you want, check out this page that lists Linux applications that are certified to run on Open Solaris in a Linux Branded zone. I thought it was interesting that pretty much everything that got a "green" rating (the best) already works fine on Linux and on Solaris (like Apache). But, don't take my word for it, go there and be pessimistic for yourself ;)

Have a great weekend!

, 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

Prtdiag And "Lane Width Failed" Errors On Solaris 10

A lot of admins who work with Solaris 10 Zones may have run into this situation already, but I'm just starting to hear it now from users who like to do their own diagnostics before coming to me with a possible system issue. Don't get me wrong folks; I love it when users show this kind of initiative (as long as they don't go into the data center and start pressing buttons ;)

This problem is similar to the problem Solaris 10 has with old style /usr/ucb/ps, but it isn't quite as prevalent.

The situation that occurs is that a user, trying to gather information on the system that may, or may not be, having a hardware or software issue, runs a pretty standard command called "prtdiag," probably like this:

host # /usr/platform/`uname -i`/sbin/prtdiag

Now, in Solaris 10, this doesn't always cause an error. The reason for this, and how it differs from the old style ps error, is that it only occurs when the user runs prtdiag on Solaris 10 with Zones enabled.

Another thing that makes this unusual error so rare is that, on most Zone-enabled Solaris 10 setups, users accounts are all setup in the non-global Zone and prtdiag will only run in the global Zone. Obviously, the "rules" aren't followed all the time, insofar as system setup and access are concerned. Like they say: the customer is always right, even if he's doing something he probably shouldn't be (or something like that ;)

So far, I've only seen this error on the Mx000 Series Servers from Sun, but that's probably because we use those the most. Generally, the error will present itself in some way similar to the following (Looks scarier than it is and the actual error may vary)

host # /usr/platform/`uname -i`/sbin/prtdiag <-- Stripping the 100 lines preceding the error in my ongoing effort to fight eye-strain ;)

... 
    IO                                                Lane/Frq 
LSB Type  LPID   RvID,DvID,VnID       BDF       State Act,  Max   Name                     Model               
--- ----- ----   ------------------   --------- ----- ----------- ------------------------ ------------------ 
    Logical Path 
    ------------ 
Getting lane width failed for path /pci@3,800000/SUNW,emlxs@0

And, again, just like our ps error on Solaris 10, running the command as root makes everything work just fine:

root@host # /usr/platform/`uname -i`/sbin/prtdiag

...
    IO                                                Lane/Frq 
LSB Type  LPID   RvID,DvID,VnID       BDF       State Act,  Max   Name                     Model               
--- ----- ----   ------------------   --------- ----- ----------- ------------------------ ------------------ 
    Logical Path 
    ------------ 
00  PCIe  3      1, fc21, 10af        1, 0,  0   okay     4,  4   SUNW,emlxs-pci10af,fc21   LPe110094-S           
    /pci@3,800000/SUNW,emlxs@0

Sun's stock answer, for now, is to change the permissions of the prtdiag command so that it runs setuid root (For those of us who are reading this and don't know what that means - A very small portion of the audience that bothered to read this far, I'm sure - when a program is setuid "username," it will run as that user - with that user's privileges - no matter what user actually executes it)

root@host # chmod 4755 /usr/platform/`uname -i`/sbin/prtdiag

or, if you prefer to change your file modes in alpha:

root@host # chmod u+s /usr/platform/`uname -i`/sbin/prtdiag

Probably the best way to work-around this, and keep with Sun's basic security requirement of not running programs like this setuid root, is to make use of a program called sudo (which comes with Solaris 10). Just include a rule like the one below, so that users can only run "/usr/platform/`uname -i`/sbin/prtdiag" straight up and can't run it with any additional flags or switches. This will allow them to get the information they want and safeguard you, the admin, against any unforeseen issues with this work-around. Example rule below:

ALL ALL = (root) /usr/platform/`uname -i`/sbin/prtdiag ""

Another promise from me that, eventually, we will get to a post devoted entirely to sudo. For now, here's a quick rundown on how this rule reads:

ALL <--- All users can use this sudo rule
ALL <--- This command can be used on any host.
= <--- The cement that connects the preceding user and host restrictions with the commands and options to follow
(root) <--- This command will be run as the user root
/usr/platform/`uname -i`/sbin/prtdiag "" <--- This is the only allowed command. This command specifies that /usr/platform/`uname -i`/sbin/prtdiag can only be run with no additional switches or flags (like "-v"). The "" (double-double quotes) indicate that no switches are allowed after the command.

Hopefully, and in all likelihood, this solution should keep everyone happy. You've kept the security flaw from being exploited, retained the original permissions on /usr/platform/`uname -i`/sbin/prtdiag and allowed users to be able to get their diagnostic output.

All that's left to do is thank your user base for helping make your job easier :)

, Mike

linux unix internet technology

Checking the State of Your DNS Setup Externally!

Every once in a while, it's good practice to take a look at any system you have setup (whether it be a single system, business process, program or computing environment) and make sure it's doing okay. Some sort of regular auditing also helps to find out if there are any areas in which you can make an improvement or fix errors.

One of the areas that seems to require looking over more consistently, is your DNS setup. New versions are released regularly, bugs are found just as regulary, and acceptable syntax can sometime change between releases and/or RFC's.

Note for today's script - It is intended only for your benefit, and I strongly urge you to use any free DNS reporting service you can find to accomplish what we're accomplishing here. I neither work for, nor do I do any afilliate marketing for, www.dnsstuff.com. We only use it where I work, because it's the standard. Probably, most readers already know about it. The site tools require a free registration, if you're not a paying member, but also require a payment for use after 30 DNS Reports. I have placed a very obvious "COMMENT" in the script above the only line you'd need to change to use another service. If you "do" find something equal, or better, I would recommend that you use it (and, maybe, send me an email to let me know the URL so I can check it out and update my scripts, too :) That being said, I'm not trashing them either. If you have to do this sort of thing a lot(for your employer, lets say), the company can probably shell out a few bucks a month for the service. It's worth the price if you need to use it regularly.

Aside from your own internal auditing, it's good to get a fair and objective third-party assessment of the state of your DNS setup. A great site to get this accomplished on the web is located at http://www.dnsstuff.com. They have a tool called "DNS Report" (which used to be its own domain - www.dnsreport.com) which can be used very effectively, even if you choose not to be a paying member of the site. A long long time ago, it was available to everyone for free, but since it's pay-for now, you really have to be careful not to deluge it with requests to check your DNS zones (all 30 of them, if you're doing this for free), or you'll get dumped on their blacklist and barred from using the service at all.

The little Perl script I've written below will help you to automate the usage of that web service for all of your DNS zones. The reports are nice and easy to understand, even for the highest of higher-ups (green = good, red = bad ;) and the service does a very good job of pointing out weaknesses, or areas that don't conform to current RFC expectations, in your DNS zones. This script does require that you have Perl installed (although it's just a script I whipped up so it's submitted under GPL (Gnu Public License), at best, and you can feel free to rewrite it to suite your own needs). It also makes use of curl. You can substitute lynx or wget or any other program that can download and save web pages to your Unix/Linux hard drive. And here it is, below (Please read the comments regarding use of dnsstuff's dnsreport tool):





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/usr/bin/perl

#
# 2007 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#
# Registration is now required to use this tool - It used to be free.
# When/If you register, be sure to uncheck the two opt-in mail
# checkboxes at the bottom unless you want to receive those emails.
#
# Login to dnsstuff.com before running this script or it will just return
# a page indicating that you need to log in before submitting a full request
# without that request being linked to from one of their pages
#
# Simple Error Checking here, just want to be sure that a file exists at all.
# Disregard everything else on the command line. This script will fail if the
# file named on the command line doesn't include one URL per line, anyway :)

if ( ! -f $ARGV[0] ) {
print "Usage: $0 fileWithUrls\n";
exit(1);
}
$dns_file = $ARGV[0];

open(URL_FILE, "< $dns_file");
@url_file = ;
close(URL_FILE);
$counter = 120;

foreach $url (@url_file) {
print "$url";
$| = 1;
if ($pid = fork) {
if ( $counter = 900 ) {
$counter = 120;
} else {
$counter = $counter+60;
}
print "next\n";
} else {
close (STDOUT);
chomp($url);
#
# COMMENT <--- The Obvious One :)
# CHANGE THE URL ON THIS LINE TO THE URL OF ANY OTHER SITE YOU FIND THAT
# PROVIDES AN EQUAL SERVICE!
#
@output = `curl http://www.dnsstuff.com/tools/dnsreport.ch?domain=$url`;
open(OUTPUT, ">$url.htm");
print OUTPUT @output;
close(OUTPUT);
exit(0);
}
if ( $counter = 900 ) {
$counter = 120;
} else {
$counter = $counter + 60;
}
sleep $counter;
}
exit(0);

And that's that! As I mentioned before, this tool will blacklist you if you hit dnsstuff too hard. My script assumes that you can hit the site at the rate I used last time I used it. Since it's a pay-for service now, I would recommend changing the wait times to at least twice as much. To give you an idea, I ran this when the service was free and ended up getting blacklisted in a under a few hours. Granted, there were certain other factors that contributed to my getting the boot; most prominently that I was checking the DNS for about 300 to 400 zones we were hosting. It could have been left at checking one and making sure all the others were the same, but, as noted above, some bosses like to see reports with lots of colors and lots of pages.

Also, just so you don't feel like I'm leaving you in a lurch, if you do happen to get blacklisted, just go to their member forums (you get access to post to these since you had to do the free registration - you can only browse them if you're not registered) at http://member.dnsstuff.com/forums/ and do a search on "banned," "blacklist" or "black list." Most folks just have to start a thread and request their access back in order to get off the blacklist.

So, be careful out there, and take it slow :)

, Mike

linux unix internet technology

Checking Huge Amounts of DNS Zones Easily

Most of the places I've ever worked, where I needed to manage Bind and DNS, it was a few little things at a slow pace. You had your main zone, maybe a few subzones and it all boiled down to a few files to manage in a relatively small setup. I'm talking about the kind of setup that a Sun Ultra5 could eat for lunch. The NIC was almost always the bottleneck.

However, some places (like ISP's and other service providers) will have gigantic amounts of zones that they serve. In those sorts of instances, doing things on the fly doesn't much cut it, unless you can afford to spend the majority of your work life doting over your DNS setup.

One of the main things that you need to worry about, after the initial setup and any time you do a migration or merge DNS zone depots, is making sure you didn't screw the pooch in the process. Thankfully, Bind comes with a few programs to make your life easy.

Given an unlimited amount of zones, you can use the named_checkzone command to verify them all while you surf the web ...or work really really hard ;). Its syntax is simple:

named_checkzone the_zone_name the_zone_filename

And, if you wrap that in a simple loop, iterating over the files in your DNS directory, you'll end up with a simple-to-analyze report in minutes. Consider the following:

#!/bin/ksh

chao=$$
date=`date +%m%d%y`

for x in `ls -1d /var/named/*`
do
file_name=$x
zone_name=`echo $x|sed s'/\/var\/named\/\(.*\).*\.db/\1/`
./named-checkzone $zone_name $file_name |tee -a confstate.$date.$chao
done

Above, very simply, we've taken every zone file (like most folks who like to keep things simple when they don't have to be complicated) and checked it, using Bind's own checker (how much better could that get?). In this case, I named my zone files using the convention ZoneName.db. To create the_zone_name variable, I use a simple sed command to capture every part of the filename except for the tailing ".db" - That output all gets dumped into the confstate file using tee.

You can do the same thing with your named.conf (using Bind's named_checkconf), but there's almost no reason to script that. Hopefully you've only got one configuration file and you can check that as simply as typing:

named_checkconf /etc/named.conf

or whatever you named your conf file and wherever it is.

Enjoy your snooze. Hopefully all of your zone files are in compliance :)

, Mike

linux unix internet technology