Volume 3 Of The Linux/Unix SysAdmin Covert File Storage Method

Cheers,

Today's post is the third volume in our series on covert file storage. If you're interested in reading up on the 57th installment of this series, please feel free to click the link that's way behind the anchor text right here ;) Today, we're going to be looking at the tip discussed in volume 57, but with respect, specifically, to the ZFS filesystem. The meaning of those initials is included in the hyperlink, again, preceding the sentence that should land you at your anchor text. Of course, one connecting theme of these three posts is that everything is out of order; hence the signature sign-off in place of the usual greeting. We're trying really hard to be clever and, if we're lucky, we'll unintentionally create a perpetually-looping self-parody that unexpectedly creates infinite depths of recursion as we explore the meaning of the meaning of the meaning of... In the meantime, we'll plow straight ahead and bring you Volume 3 (which, of course, is the second entry) in our series of posts on hiding things in and under your Unix or Linux partitions and overlay-mounts (one's the same as the other but the other isn't necessarily the same as the one ;)

This post's twist is that we'll be specifically approaching hiding data in ZFS mountpoints. For the purposes of our demonstration and experimentation, we'll assume that the version of ZFS we're using is the one that roughly corresponds with the date of this post. If any feature mentioned didn't work a year ago, or you're reading this in the future and find yourself disgusted with the lack of an "obvious" and simple solution that didn't exist yet, we beg your pardon. This blog is written in the present (over and over and over again), edited in the very near relative-future and published before the aforementioned activities become distant recollections from the past ;)

Again, you can refer to our previous post on finding space hogs on multiple-overlay mountpoints if you want to look into that aspect a little bit deeper. Also, we'll be using the /usr/local overlay mount, mounted on top of /usr, for our models.

ZFS is actually quite a robust files system and is improving with each release. One really nice thing about it is that it's available for both commercial Solaris and OpenSolaris, so we don't have to exclude the open source community in this post like we have to with most of our Solaris posts. You're always welcome to read of course, but we prefer to only advertise or offer-up relevant content to our readers (Meaning that, since most of our traffic has been (and still is) the result of shameless self-promotion -- but, thank you Google for indexing us! -- we try not to forget to fail to "drop bombs" on purely Open Source forums when we write about proprietary, and unbelievably costly, Operating Systems).

Today's experiment will have us butting into a few problems along the way. But we'll still be able to get away with hiding our stuff. Like Rocky Balboa, we're about to be repeatedly punched in the face (and if you've ever seen that movie, you know that he gets hit around 70 or 80 times at full-force in the last fight alone) and yet still manage to lose the fight... okay; that was a bad allegory, not to mention a bad analogue. Think "Rocky II" instead. He get's his face smashed in some more, but we're pretty sure he wins at the end of that movie ;)

Step 1: Take stock of your surroundings. You're going to, first and foremost, ensure that the information you're hiding won't be compromised by the little things (like putting big things in small spaces or using big spaces with little room to store any things ;) Just like in the 57th method, we've got it pretty good, with regards to the amount of space available on /usr. The space on /usr is, ultimately, more important than the space available on /usr/local, since that's were our hidden files will actually reside and any changes in size might get noticed by tools like "du,""df" or the people who get paid to keep an eye on you (Sorry - that one was just way too easy to let it go ;)

Since our example output (aside from the ZFS-specific errors) will be the same, we're going to assume the example output from our post on the 57th method, which you can refer back to, before this post gets even longer than way-too-long!

Step 2: Pry that floorboard loose. This is where you still have to be nimble, and is one part of this operation that you'll want to execute as quickly as possible (putting everything back to normal would be the other thing you want to do quickly. Restoration of seeming-normality in as little time as possible is key).

First, we'll unmount the /usr/local filesystem, which leaves us with "df -k" (or "df -whatever" - however you like it) showing that /usr/local is now simply a directory on the /usr mountpoint. It's no longer a mountpoint, which is good. If you haven't been storing stuff here already, the directory should be empty.

Step 3: Throw all that stuff you're not supposed to have into the /usr/local directory and then nail the floorboards back down by remounting /usr/local.

NOTE: This is where ZFS bites you in the arse, if you've set it up using its defaults. Now you're in it deep because you're half-invested in a conspiracy to cover something up (we won't judge) and you have to decide if you want to put off until the future what you could figure out today, or just figure everything out right now.

An important distinction to be made at this point is that ZFS doesn't use the standard "mount" and "umount" commands that, say, UFS, does. It uses the very-similar "zfs mount" and "zfs umount" commands, instead. Assuming that your ZFS filesystem is a default ZFS filesystem and you've run the following commands (so far), you'll get the error at the end of the output below:

host # zfs umount rootdg/usr/local <-- NOTE HERE: The ZFS filesystems are part of a data pool or dataset, so the output looks slightly different in df, mount, du, etc.
host # mv /tmp/coworkers_salaries.db /usr/local/.
host # zfs mount rootdg/usr/local
cannot mount '/usr/local': directory is not empty <-- Also notice that the error message will usually use the "mountpoint" name as opposed to the "dataset" name. In this instance, the mountpoint /usr/local is actually mounted on rootdg/usr/local.

OUCH! Now the important thing to do is not to be like Rocky! Completely ignore Mickey while he calls you a tomato and goes on to explain some insanity about how he's not running some goddamn soup kitchen ;) You can escape from this situation - on the fly - quite easily if you know your command line options (or look them up really quickly):

host # zfs mount -O rootdg/usr/local
host #

Phew...

Step 4. Ensure everything looks good, and, if you have the time, consider one other option that might make your life easier later on (although it may draw unwanted attention. Each situation is unique. If your boss and/or co-workers are paranoid, they're probably out to get you and are all in on it ;) If you're reasonably confident you have a good excuse prepared and can set this up (if you'll permit us one more chug of spite from the "Rocky" well), Mickey also told you to keep hitting that bastard in the ribs, ya see? "Don't let him breathe." Your ZFS filesystem can be modified to keep your future covert operations more efficient. We'll look at that before we bid you adieu, since statistics show that the average human's attention span is ...something less than optimal. The specifics are fuzzy, but it's definitely not "above average" ;) That sentence couldn't have made more sense, by adhering to its own logic, if we paid it to...

The way to do this is, of course, to make your ZFS filesystems into legacy filesystems, rather than remembering to use "-O" at the command line every time (which won't work on a reboot or automated remount), and keep them that way! This other method doesn't rob you of all of the benefits of ZFS, but does make it so that commands like "zfs mount -a" won't auto-mount your ZFS mountpoint. In fact, "zfs mount" won't work for that mountpoint anymore, and you'll need to include it in /etc/vfstab, just like the UFS and VXFS, etc, filesystems if you want it to mount at boot, etc. So, for our rootdg/usr/local filesystem/mountpoint/dataset, we'll need to do the following (and you'll see how incredibly obvious this move can be ;)

host # zfs set mountpoint=legacy rootdg/usr/local
host # mount -F zfs rootdg/usr/local /usr/local

Actually, that isn't "so" bad, but, as we mentioned, if you want to automate this, you'll need to add a line to /etc/vfstab that looks odd and out of place:

rootdg/usr/local -  /usr/local     zfs  -  yes  -

This is particularly easy to spot because the logical device has a different format than most (/dev/dsk/c0t0d0s0, for example) and the "device to fsck" and "fsck pass" columns are both not used and need to be set to "-" rather than the standard "/dev/rdsk/c0t0d0s0" and "1" that might usually go there. Also, and this is the worst part, you have to put the name of the filesystem in there, so "zfs" is spelled out right in the middle of the entry. Nasty...

Step 5: Make sure things look relatively the same, so you don't get in trouble, and walk away. Don't look back. People who regret past decisions often look over their shoulders compulsively. Most people know this even if they don't "know" that they know this. Kind of in the same way some folks might make you feel uneasy or suspicious, although you couldn't say for exactly what reason.

And bang, zoom; you're all set, yet again. Unless you're incredibly unlucky, or tragically misinformed, your stuff should be there waiting for you when you go to get it back.

Well be back with our final self-referencing 437th Issue in this three part series. As it began, so shall it start. As above, so it goes. When God opens one door, He closes another :)

Howdy,

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

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.

---

Dealing With ZFS-Rooted Zones on Solaris 10 Unix

Hey there,

Today, we're going to take a look at a problem that's been haunting Solaris 10 (and, to a degree, Open Solaris) for almost 3 years now. This ties back pretty closely to earlier posts we put out on migrating zones, patching local and global zones and working with zfs filesystems, since it has exactly to do with a problem concerning zfs, Solaris 10 zones and one specific way in which they can be created.

Theoretically, it would seem, that the one way that's causing the most problems is the one way that should be the most desirable way to configure your setup (???)

Here's a little something to think about when considering creating zones with a zfs filesystem. Although this quote is taken out of context, directly from Sun, it was actually put out there as a selling point (in its own context actually):

zones are integrated into the operating system, providing seamless functionality and a smooth upgrade path.

However, as many of you may be aware by now (it being July 2nd, 2008 and, officially, version 5/08 of Solaris 10 is on the market), although creating bootable zfs zones and zones with zfs root filesystems is now finally possible (I believe it was originally introduced, in a small way, back in 6/05 -right before the 06/06 official release), it still suffers from some severe issues, that may not be initially evident. That is to say, if you didn't do your homework before you took advantage of this seemingly great feature, you've probably gotten burned in one fashion
or another, with regards to the upgrade process. Per Sun, again:

Solaris 10 6/06 supports the use of ZFS file systems. It is possible to install a zone into a ZFS fs, but the installer/upgrader program does not yet understand ZFS well enough to upgrade zones that "live" on a ZFS file system.

Because of this (and repeating this ;) upgrading a system that has a zone installed on a ZFS file system is not yet supported. To this day (to my knowledge) the problem still hasn't been completely resolved. Again, from Sun's bug list (And, I know I sound like I'm Sun-bashing here, but I am coming to a positive point. I swear :)

zoneadm attach command Might Fail (6550154)
when you attach a zone, if the original host and the new host have packages at the same patch level but at different intermediate patch histories, the zone attach might fail. various error messages are displayed. The error message depends on the patch histories of the two hosts.
workaround: Ensure that the original host and the new host machines have had the same sequence of patch versions applied for each patch.

Basically, the way things stand now, if you have a zone built on a zfs root filesystem (rather than, say ufs), if you need to upgrade, you officially have 3 options:

l. Be pro-active and "Don't do it!"

2. Go ahead and do it, but be sure to uninstall your zones before upgrading to a new release of Solaris 10, and then reinstall them when your upgrade to the new release is completed.

3. Go ahead and do it, but instead of following the more traditional upgrade-path, completely reinstall the system in order to perform the upgrade. This option makes the least sense, since reinstallation and upgrading aren't synonymous.

Now, for the rainbow after the storm. Yes, rainbows are somewhat illusory and their beauty isn't necessarily the matched-opposite of the horrors of nature you may have had to endure in order for it to bring you to that phenomenon, but it's a lot better than nothing, right ;)

The situation, as you may have guessed, is still pretty much up-in-the air, but there is hope; and in more than one area. For x86 (and possibly Sparc), this initiative is being fast-tracked by Sun for Open Solaris/Solaris 10 (Note that it's dated June 27th, 2008 :) - It basically proposes a -b flag to zoneadm attach, to be used in conjunction with the -u flag, to allow for backing patches out of a zone before an OS update. The full discussion, to date, is located here on openSolaris.org.

Why is this important?

As we noted above, the biggest problem Solaris 10 has with upgrading the OS on machines that have zones with zfs roots is that every single patch and package must be the same after the upgrade in order for it to be considered successful and Solaris 10's update software doesn't work with ZFS well enough to be able to guarantee that patches that get installed in one zone will necessarily get installed in another (global vs. local, zfs vs. ufs/vxfs, even zfs vs. zfs). If we were allowed to ignore certain patches and/or packages in our upgrades, this might make the likelihood of failure drop dramatically!

And here's one more ray of hope (which might be even better by the time you need to apply it). Here's how to upgrade your OS, assuming it has zones mounted on zfs roots, and (possibly) get away with not having to go to the extremes Sun is obligated to recommend. It's actually fairly simple. Mostly because it isn't guaranteed to work ;) The one good thing is that, if it doesn't work, you'll have your data saved off, so (if this procedure fails) you can still do it the hard way and not lose anything, except time, by trying :)

Do the following. We'll assume you've read our previous posts on migrating and patching both local and global zones and understand the basic system-down commands that would necessarily precede the following:

l. Halt and detach each of your zones that sits on a zfs root (I'd personally do this for all of my zones), like so:

host # zoneadm -z ZONENAME1 halt
host # zoneadm -z ZONENAME1 detach

2. Export all of your zfs pools:

host # zpool export ZONENAME1 <-Make sure that you note the names here, for the reverse process, just in case!
host # zpool export ZONENAME2

3. Perform your upgrade however you prefer.

4. Import all of your zfs pools

host # zpool import <--If this doesn't work, use the names you specified during the export previously.

or

host # zpool import ZONENAME1
host # zpool import ZONENAME2

5. Reattach and boot/install your zones using the -F flag to force the issue (of course you can leave it out if you want, just to see what happens. Sometimes forcing makes things work that are flagged as errors, but aren't really. You can also use the -n flag to do a dry-run):

host# zoneadm -z ZONENAME1 attach -F
host# zoneadm -z ZONENAME1 boot -F <--Note that for the zoneadm command. if you don't list a zone name with the -z flag, the subcommand (halt, detach, attach, boot, etc) would apply to all zones!

And you should either be all set or have a more limited set of issues to deal with (probably mostly patch related).

Later on in the week (if we don't run out of screen space ;) we'll look at ways to troubleshoot a Solaris 10 zfs-root zone upgrade gone bad.

Until that bright and sunny day:)

, Mike

Destroying Storage Pools And File Systems On Solaris 10 Unix ZFS

Hey once more,

Today we're finally ready to wrap up our series of posts on using ZFS and storage pools on Solaris 10 Unix. We started out with a post on ZFS and storage pool creation commands, followed that up with a two-parter on maintenance and usage commands and even more helpful usage commands, and have finally arrived here, today.

This post marks the end in this little series, and, befittingly, it has to deal with destroying ZFS file systems and storage pools. It's wonderful how that worked out so appropriately ;)

I hope this series has been as much a help to you as it has been in crippling my fingers ;) Seriously, here's hoping we all got something out of it :)

Let the end begin:

1. If you decide you want to get rid of your storage pool (none of my business... ;), you can do so like this:

host # zpool destroy zvdevs
host # zpool list zvdevs
cannot open 'zvdevs': no such pool

2. You can also easily remove mirrors from storage pools by doing the following:

host # zpool detach zvdevs /vdev3
host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  ONLINE       0     0     0

errors: No known data errors

3. In a Solaris 10 storage pool, you can't remove any active disks using "zpool remove." If you attempt to, it's not a big deal, because you'll just get an error, like this:

host # zpool remove zvdevs /vdev3
cannot remove /vdev3: only inactive hot spares can be removed

But, you can still remove active disks (as long as doing so isn't detrimental...) with the -f flag to force it. To do it the polite way, you just need to "detach" the virtual device in the exact same way you'd detach a mirror from a storage pool, like so:

host # zpool detach zvdevs /vdev3
host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: resilver completed with 0 errors on Mon May  5 10:05:33 2008
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  ONLINE       0     0     0

errors: No known data errors

4. Of course, you can easily remove vdevs from a storage pool if they're "hot spares" and they're "inactive." Here, we'll add a spare and then remove it:

host # zpool add zvdevs spare /vdev3
host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: resilver completed with 0 errors on Mon May  5 10:05:33 2008
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  ONLINE       0     0     0
        spares
          /vdev3    AVAIL

errors: No known data errors
host # zpool remove zvdevs /vdev3
host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: resilver completed with 0 errors on Mon May  5 10:05:33 2008
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  ONLINE       0     0     0

errors: No known data errors

5. If you want to remove ZFS file systems, just use the "destroy" option, shown below:

host # zfs destroy zvdevs/vusers4
host # zfs list|grep zvdevs
zvdevs                             200M   784M  28.5K  /zvdevs
zvdevs/vusers                     24.5K   200M  24.5K  /zvdevs/vusers
zvdevs/vusers@backup                  0      -  24.5K  -
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3

6. Of course, there's a catch to destroying ZFS file systems. It won't work straight off if the file system has "children" (Unix has always been a family-oriented OS ;)

host # zfs destroy zvdevs/vusers
cannot destroy 'zvdevs/vusers': filesystem has children
use '-r' to destroy the following datasets:
zvdevs/vusers@backup

In this instance, we either need to recursively delete the file system ( with the -r flag ), like so:

host # zfs destroy -r zvdevs/vusers
host # zfs list|grep zvdevs
zvdevs                             100M   884M  27.5K  /zvdevs
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3

or promote the filesystem so that it's no longer a clone and no longer dependant on its origin snapshot, at which point we can destroy it like this (If you recall, many moons ago - this gets confusing - we took a snapshot of zvdevs/vusers. Then we cloned the snapshot to a new file system, zvdevs/vusers4, in order to do a rollback... That's why we have to promote zvdevs/vusers4 to remove zvdev/vusers):

host # zfs promote zvdevs/vusers4
host # zfs list|grep zvdevs
zvdevs                             100M   884M  29.5K  /zvdevs
zvdevs/vusers                         0   884M  24.5K  /zvdevs/vusers
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3
zvdevs/vusers4                    24.5K   884M  24.5K  /zvdevs/vusers4
zvdevs/vusers4@backup                 0      -  24.5K  -
host # zfs promote zvdevs/vusers4
host # zfs destroy zvdevs/vusers
host # zfs list|grep zvdevs
zvdevs                             100M   884M  28.5K  /zvdevs
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3
zvdevs/vusers4                    24.5K   884M  24.5K  /zvdevs/vusers4
zvdevs/vusers4@backup                 0      -  24.5K  -

7. If you've had enough and you want to destroy your storage pool, that's your call. Just remember the hierarchical nature of ZFS and don't get discouraged ;)

host # zpool destroy zvdevs

The only time this won't work is if your pool is not empty (which means containing data, rather than containing file systems) or if it has mounted file systems. Simple variations on regular UFS commands can fix the mounting/unmounting issue for you. Destroying individual ZFS filesystems in your pool will take care of the other issue (So will the "-f" flag, if you just want to use force and be done with it):

host # zpool destroy zvdevs
cannot destroy 'zvdevs': pool is not empty
use '-f' to force destruction anyway
 Can’t destroy a pool with active filesystems.  
host # zfs mount myzfs/zvdevs
host # zfs unmount myzfs/zvdevs

Note that you may have to unmount filesystems overlay-mounted on top of the main file system. No problem. Again, you can use "-f" to save you the hassle.

And that's all she wrote about this subject... for now...

Have a great weekend :)

, Mike

linux unix internet technology

More Helpful Usage Commands For Solaris 10 Unix ZFS

Hey there,

Today we're here with part three of our four-part mini-series on ZFS and storage pool commands and tips. We started out with ZFS and storage pool creation commands, and followed that up with yesterday's post on maintenance and usage commands. Today's post is actually a continuation of yesterday's post, which was originally going to be part two of three. The inmates must be running the asylum ;)

For any notes pertaining to this entire four-post series, please refer to the first ZFS and storage pool post. I'm getting tired of hearing my own voice in my head ;)

Today, we'll keep on going with usage and maintenance tips. Enjoy and don't be afraid to come back for seconds :)

1. You can run statistics specifically against your ZFS storage pools (which can help in identifying a bottleneck on a system with a lot of virtual devices, zones and pools). These stats aren't too exciting since I just created the pool for this little cheat-sheet:

host # zpool iostat zvdevs 1 5
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zvdevs        92K  1016M      0      0     83    633

<--- As with regular iostat, this is a summary line

zvdevs        92K  1016M      0      0      0      0
zvdevs        92K  1016M      0      0      0      0
zvdevs        92K  1016M      0      0      0      0
zvdevs        92K  1016M      0      0      0      0

2. If you ever need to list out your ZFS file systems, just use the "list" option, like this:

host # zfs list |grep zvdevs
zvdevs                             120K   984M  26.5K  /zvdevs
zvdevs/vusers                     24.5K   984M  24.5K  /zvdevs/vusers

3. One problem you might note with new ZFS files systems and listing them out, is that they all have access to the entire storage pool. So, theoretically, any of them could fill up the entire storage pool space and leave the other two out of disk space. This can be fixed by setting "reservations" to ensure that each VFS file system gets to keep a certain amount of space for itself no matter what (here, vusers gets at least 100 Megabytes, and vusers2 and 3 will get at least 50 Megabytes each):

host # zfs set reservation=100m zvdevs/vusers
host # zfs set reservation=50m zvdevs/vusers2
host # zfs set reservation=50m zvdevs/vusers3
host # zfs list -o name,reservation|grep zvdevs
zvdevs                              none
zvdevs/vusers                       100M
zvdevs/vusers2                       50M
zvdevs/vusers3                       50M

4. On the other hand, you may want to restrict space-hogs from taking up too much space. You can do this with quota's, almost just like on older versions of Solaris Unix:

host # zfs set quota=200m zvdevs/vusers
host # zfs set quota=100m zvdevs/vusers2
host # zfs set quota=100m zvdevs/vusers3
host # zfs list -o name,quota|grep zvdevs
zvdevs                             none
zvdevs/vusers                      200M
zvdevs/vusers2                     100M
zvdevs/vusers3                     100M

5. You can also set up file systems to use compression, selectively, like so (Whether or not this is worthwhile is debatable):

host # zfs set compression=on zvdevs/vusers2
host # zfs list -o name,compression|grep zvdevs
zvdevs                                 off
zvdevs/vusers                          off
zvdevs/vusers2                          on
zvdevs/vusers3                         off

6. ZFS also has built-in snapshot capabilities, so you can prep yourself (like, before you're about to try something crazy ;) and be able to rollback to an earlier point in time (We'll call our snapshot "backup"), like this:

host # zfs snapshot zvdevs/vusers@backup
host # zfs list|grep zvdevs
zvdevs                             200M   784M  28.5K  /zvdevs
zvdevs/vusers                     24.5K   200M  24.5K  /zvdevs/vusers
zvdevs/vusers@backup                  0      -  24.5K  -
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3

7. Now, assuming that you screwed everything up so badly that you need to back out your changes (but not so bad that you can't access Solaris ;), you can use ZFS's built-in rollback capability. Here we'll do a rollback, based on our snapshot, and clone that to a separate ZFS file system, so we can move back whatever files we need to their original locations (Unfortunately, the extra cloning steps are necessary, as snapshots are not directly accessible and you also can't clone to an existing vdev! ):

host # zfs rollback zvdevs/vusers@backup
host # zfs clone zvdevs/vusers@backup zvdevs/vusers
cannot create 'zvdevs/vusers': dataset already exists <--- Didn't I just remind myself that I can't do this ;)

host # zfs clone zvdevs/vusers@backup zvdevs/vusers4
host # zfs list|grep zvdevs
zvdevs                             200M   784M  29.5K  /zvdevs
zvdevs/vusers                     24.5K   200M  24.5K  /zvdevs/vusers
zvdevs/vusers@backup                  0      -  24.5K  -
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3
zvdevs/vusers4                        0   784M  24.5K  /zvdevs/vusers4

8. Another cool thing you can do is to rename your file systems, like this (note that any attached snapshots will be renamed as well):

host # zfs rename zvdevs/vusers4 zvdevs/garbage
host # zfs list|grep zvdevs
zvdevs                             100M   884M  28.5K  /zvdevs
zvdevs/garbage                    24.5K   884M  24.5K  /zvdevs/garbage
zvdevs/garbage@backup                 0      -  24.5K  -
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3

9. You can also rename snapshots, if you don't want anybody (including yourself in a few months ;) to be able to easily tell what file system is a backup of what other file system, like this:

host # zfs rename zvdevs/garbage@backup zvdevs/garbage@rollbacksys
host # zfs list|grep zvdevs
zvdevs                             100M   884M  28.5K  /zvdevs
zvdevs/garbage                    24.5K   884M  24.5K  /zvdevs/garbage
zvdevs/garbage@rollbacksys            0      -  24.5K  -
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3

10. And, just in case you need to have all the information you could ever want about your ZFS file systems, you can "get" it "all" :

host # zfs get all zvdevs
NAME    PROPERTY       VALUE                  SOURCE
zvdevs  type           filesystem             -
zvdevs  creation       Mon May  5 10:00 2008  -
zvdevs  used           100M                   -
zvdevs  available      884M                   -
zvdevs  referenced     28.5K                  -
zvdevs  compressratio  1.00x                  -
zvdevs  mounted        yes                    -
zvdevs  quota          none                   default
zvdevs  reservation    none                   default
zvdevs  recordsize     128K                   default
zvdevs  mountpoint     /zvdevs                default
zvdevs  sharenfs       off                    default
zvdevs  checksum       on                     default
zvdevs  compression    off                    default
zvdevs  atime          on                     default
zvdevs  devices        on                     default
zvdevs  exec           on                     default
zvdevs  setuid         on                     default
zvdevs  readonly       off                    default
zvdevs  zoned          off                    default
zvdevs  snapdir        hidden                 default
zvdevs  aclmode        groupmask              default
zvdevs  aclinherit     secure                 default
zvdevs  canmount       on                     default
zvdevs  shareiscsi     off                    default
zvdevs  xattr          on                     default

11. It's better to send than to receive :) Maybe not... In any event, you can use the ZFS send and receive commands to send snapshots to other filesystems locally or remotely (much in the same way you can use the system subshell to move content using tar), like so:

host # zfs send zvdevs/vusers@garbage | ssh localhost zfs receive zvdev/newbackup
host # zfs list
host # zfs list|grep zvdevs
zvdevs                             100M   884M  28.5K  /zvdevs
zvdevs/garbage                    24.5K   884M  24.5K  /zvdevs/garbage
zvdevs/vusers@backup                  0      -  24.5K  -
zvdevs/vusers2                    24.5K   100M  24.5K  /zvdevs/vusers2
zvdevs/vusers3                    24.5K   100M  24.5K  /zvdevs/vusers3
zvdevs/newbackups                 24.5K   100M  24.5K  /zvdevs/newbackup

12. If you get nostalgic from time to time, or you need to figure out why something bad happened, you can use the ZFS filesystem history command, like so (Note that no history will be available after you destroy a pool -- I did that already, to zvdevs, so this output is for another storage pool on the same system):

# zpool history
History for 'datadg':
2008-02-27.20:25:32 zpool create -f -m legacy datadg c0t1d0
2008-02-27.20:27:57 zfs set mountpoint=legacy datadg
2008-02-27.20:27:58 zfs create -o mountpoint -o quota=5m datadg/data
2008-02-27.20:27:59 zfs create -V 20gb datadg/swap
2008-02-27.20:31:47 zfs create -o mountpoint -o quota=200m datadg/oracleclient

Cheers,

, Mike

linux unix internet technology

Maintenance And Usage Commands For ZFS On Solaris 10 Unix

Hey again,

Today, we're back with part two of what was going to be a three part series on working with ZFS and storage pools. Actually, this was originally going to be one post, but (luckily ?) it's grown into four gigantic ones ;) This one, and tomorrow's, are going to be the "big daddies" of the bunch.

Yesterday we looked at ZFS storage pool and file system creation and today we're going to move on to commands that we can use to manipulate those storage pools and file systems that we've made.

Please note, again, that for all commands where I specifically name a virtual device or storage pool, you can get a full listing of all available devices by simply not specifying any storage pool at all.

And, without a moment to spare, here come those maintenance/usage commands (please enjoy responsibly ;)

1. If you need to know as much as possible about your storage pools, you can use this command:

host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          /vdev1    ONLINE       0     0     0
          /vdev2    ONLINE       0     0     0
          /vdev3    ONLINE       0     0     0

errors: No known data errors

2. In Solaris 10 storage pool management, you can also "online" and "offline" virtual devices. You might need to do this from time to time if you need to replace an "actual" device that may be faulty. Here's an example of offlining and then onlining a vdev. Note that, if you use the "-t" flag when offlining, the device will only be temporarily disabled. Normal offlining is persistent and the storage pool will maintain the vdev in an offline state even after a reboot:

host # zpool offline zvdevs /vdev2
Bringing device /vdev2 offline
host # zpool status -v zvdevs
  pool: zvdevs
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
 scrub: resilver completed with 0 errors on Mon May  5 10:05:33 2008
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      DEGRADED     0     0     0
          mirror    DEGRADED     0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  OFFLINE      0     0     0

errors: No known data errors
host # zpool online zvdevs /vdev2
Bringing device /vdev2 online
host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: resilver completed with 0 errors on Mon May  5 10:18:34 2008
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  ONLINE       0     0     0

errors: No known data errors

3. If you want to attach another disk to your storage pool mirror, it's just as simple. This process will create a simple mirror if you only have one device in your pool (???) or create a triplicate, quadruplicate, etc, mirror if you already have a simple mirror set up:

host # zpool attach zvdevs /vdev1 /vdev3 <--- Note that we're specifically saying we want to mirror /vdev1 and not /vdev2. It doesn't really matter, since they're both mirrors of each other, but you can't just attach a device without naming a device to mirror!

host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: resilver completed with 0 errors on Mon May  5 10:05:33 2008
config:

        NAME        STATE     READ WRITE CKSUM
        zvdevs      ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            /vdev1  ONLINE       0     0     0
            /vdev2  ONLINE       0     0     0
            /vdev3  ONLINE       0     0     0

errors: No known data errors

5. For a little shell-game, if you ever need to replace a vdev in your storage pool (say, with a hot spare), you can do it easily, like this:

host # zpool add zvdevs spare /vdev3 <--- This may not be necessary, but I removed the spare and am re-adding it.

host # zpool replace zvdevs /vdev1 /vdev3
host # zpool status -v zvdevs
  pool: zvdevs
 state: ONLINE
 scrub: resilver completed with 0 errors on Mon May  5 10:20:58 2008
config:

        NAME          STATE     READ WRITE CKSUM
        zvdevs        ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            spare     ONLINE       0     0     0
              /vdev1  ONLINE       0     0     0
              /vdev3  ONLINE       0     0     0
            /vdev2    ONLINE       0     0     0
        spares
          /vdev3      INUSE     currently in use

errors: No known data errors

6. If you suspect file system damage, you can "scrub" your storage pool. zpool will verify that everything is okay (if it is ;) and will auto-repair any problems on mirror or raid pools :)

host # zpool scrub zvdevs <--- Depending on how much disk you have and how full it is, this can take a while and chew up I/O cycles like nuts.

7. If you want to share storage pools between systems (real or virtual), you can "export" your storage pool like so (Note that this will make the storage pool not show up as being "owned" by your system anymore, although you can reimport it):

host # zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
datadg                 33.8G    191M   33.6G     0%  ONLINE     -
rootdg                 9.75G   5.11G   4.64G    52%  ONLINE     -
zvdevs                 1016M    127K   1016M     0%  ONLINE     -
host # zpool export zvdevs
host # zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
datadg                 33.8G    191M   33.6G     0%  ONLINE     -
rootdg                 9.75G   5.11G   4.64G    52%  ONLINE     -

8. In order to "import" an exported filesystem, you just need to have the system permission to do so (being root in the global zone is the perfect place to be when you try this. Just be careful ;)

host # zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
datadg                 33.8G    191M   33.6G     0%  ONLINE     -
rootdg                 9.75G   5.11G   4.64G    52%  ONLINE     -
host # zpool import -d / zvdevs
host # zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
datadg                 33.8G    191M   33.6G     0%  ONLINE     -
rootdg                 9.75G   5.11G   4.64G    52%  ONLINE     -
zvdevs                 1016M     92K   1016M     0%  ONLINE     -

You can run this command without -d (to specify the base directory of the storage pool) and zpool will search /dev/dsk for a place to import. In our case it won't find it, like this:

host # zpool import zvdevs
cannot import 'zvdevs': no such pool available

9. If you need to know what version of ZFS your system is using, you can use zpool's "upgrade" option. Don't worry. Without the proper flags, it just lets you know what version is running and some other information, like this:

host # zpool upgrade
This system is currently running ZFS version 4.

All pools are formatted using this version.

10. If you want to see what features your version of ZFS has, you can use the "upgrade" option with the -v flag. Everything is retro, so (in our case), since we're running version 4, we have all the capabilities of versions 3, 2 and 1 but not of versions 5 and higher (At the time of this post, ZFS is up to version 10):

host # zpool upgrade -v
This system is currently running ZFS version 4.

The following versions are supported:

VER  DESCRIPTION
---  --------------------------------------------------------
 1   Initial ZFS version
 2   Ditto blocks (replicated metadata)
 3   Hot spares and double parity RAID-Z
 4   zpool history
...

Now, go and have fun with those commands :)

Until we meet again,

, Mike

linux unix internet technology