unixpowered.com » solaris tips

Installing and patching Data Protector client on standalone Solaris machine

somedude — Fri, 07 May 2010 16:24:39 +0000

I needed to install HP Data Protector 5.5 client on an old machine running Solaris 2.6. I also needed to apply some Data Protector patches to that machine. The problem was I had no Data Protector Install Server for Data Protector version 5.5.

Normally, Data Protector clients are installed from Data Protector Install Server. When you need to deploy patches, first you patch the Install Server and then you push out patches to you Data Protector clients.

Installing the client itself on standalone machine is not a big deal. All you need is an appropriate Data Protector software depot and off you go. The problem was installing patches without the Install Server.

Here is the process I took installing and patching this machine:

B6960-15041_DP55_HPUX_PA_IS_CD.tar – HPUX Install Server – contains Solaris 2.6 client
DPSOL_00168.zip – Patch
DPSOL_00180.zip – Patch

First, I decompressed Data Protector software depot that contains Solaris 2.6 client and installed Disk Agent on the machine:

root@client # tar xf B6960-15041_DP55_HPUX_PA_IS_CD.tar root@client # cd LOCAL_INSTALL root@client # ./omnisetup.sh -install da

After that was done, it was time to patch Data Protector installation. First, I decompressed the patch archive. Then I located and decompressed the proper packet.Z file for Solaris 2.6:

root@client # unzip DPSOL_00168.zip root@client # cd OB2-SOLUX/root/opt/omni/databases/vendor/da/sun/sparc/solaris-26/A.05.50/ root@client # uncompress packet.Z

Finally I installed the packet, which is really Solaris package:

root@client # pkgadd -d ./packet all

The whole patch process has to be repeated for all patches you are trying to install. Note, that when you unzip the patch, you kind of have to know what you are looking for, so you need to pay attention to the PATH to packet.Z file; i.e. in the above case I was installing Data Agent patch on a Sun box, running Solaris 2.6 and Data Protector version 5.5.

Trussing processes on Sun Cluster?

somedude — Fri, 02 Apr 2010 15:41:02 +0000

One of the apps running on Sun Cluster was randomly crashing. So, I decided to take a look what was happening. Yeah, there is DTrace in Solaris 10. Since I am pretty comfortable with truss I decided to give that a shot first:

root@node1 # truss -p 27462 truss: process is traced: 27462 root@node1 #

That’s it. No truss output, nothing. That was weird. truss will not work if there is a debugger attached to the process to be traced, which was not the case. So, I figured it might have something to do with the fact that the process is handled by the cluster software.

Finaly, NOTES section of pmfadm manpage gave me the answer:

To avoid collisions with other controlling processes. truss(1) does not allow tracing a process that it detects as being controlled by another process by way of the /proc interface. Since rpc.pmfd(1M) uses the /proc interface to monitor processes and their descendents, those processes that are submitted to rpc.pmfd by way of pmfadm cannot be traced or debugged.

So, Dtrace it was. Thankfully, Brendan Gregg already did the hard work for me, by creating DTrace version of truss. The more you know…

Jetadmin and non-HP network printers

somedude — Sun, 21 Mar 2010 17:38:47 +0000

I was trying to get Dell 3130cn printer working with Jetadmin in Solaris. But, I was not able to create the print queue even though the printer was reachable, SNMP was working and so was telnet. Fortunately, there is a workaround I found somewhere on the Internet. Of course, I failed to keep the link to the workaround. Anyways, the non-HP printer that you are trying to configure has to have Jetdirect card. The workaround:

Take an HP Jetdirect printer that you already have configured.
Edit /etc/hosts file on the print server and add entry with Dell printer name. The IP address for that entry has to be the one belonging to the working HP printer.
Add a print queue as you normally would.
Remove the /etc/hosts file entry.
Test printing.

Of course, this assumes that you have some sort of name resolution mechanism in place such as NIS, so the printer names get resolved properly. Also, your /etc/nsswitch.conf file has to specify that /etc/hosts file is the first place the server goes to when resolving names.

The /etc/hosts file entry temporarily overrides your global name resolution mechanism. This way you can create print queue with the Dell printer, but you are actually talking to the HP printer when creating the queue. You might also want to use generic network printer driver in Jetadmin. Anyways, I got that Dell printer working.

Failed Repository Integrity Check

somedude — Wed, 10 Feb 2010 14:54:38 +0000

Last week I was presented with the following error on one of the Solaris 10 boxes:

svc.configd: smf(5) database integrity check of:

/etc/svc/repository.db

failed. The database might be damaged or a media error might have prevented it from being verified. Additional information useful to your service provider is in:

/etc/svc/volatile/db_errors

The system will not be able to boot until you have restored a working database. svc.startd(1M) will provide a sulogin(1M) prompt for recovery purposes. The command:

/lib/svc/bin/restore_repository

can be run to restore a backup version of your repository. See http://sun.com/msg/SMF-8000-MY for more information.

Having never seen this error, I was thinking: “this is gonna be interesting…”. Thankfully the error was pretty verbose so I started to disect it section by section. Yeah, service repository got hosed, somehow, and I can potentially find some usefull info in /etc/svc/volatile/db_errors. Unfortunatelly, there was nothing of use in there.

The restore_repository script mentioned gave me little more hope. I also went and checked out the page URL. After reading the page I decided to go ahead and try to restore the service repository.

I logged in to the box in single user mode and took a look at the restore script to get an idea of what it might do. Then, I ran it. Fortunatelly, the script was pretty good at doing checks and told me that I can not proceed any further because / filesystem is mounted RO. To fix this I was asked to run:

bash-3.00# /lib/svc/method/fs-root bash-3.00# /lib/svc/method/fs-usr

Once the filesystems were fixed up I ran the restore_repository script. I was asked which backup copy I wanted to restore and that was it. The system rebooted and came back up fine. This turned out to be a pretty good learning experience and http://www.sun.com/msg/SMF-8000-MY is very well worth reading.

Moving Solaris Container to a different host

somedude — Thu, 05 Nov 2009 16:56:45 +0000

Cloning Solaris Container is pretty straight forward. But what if you want to have an identical container on another host? In a nutshell:

Make a clone of an existing container on host A
Detach the clone
Compress it and move it to host B
Create configuration for the moved container
Decompress the container on host B
Attach the decompressed container

I have done this on Solaris 10 8/07. Before going any further, it is important that both host A and host B are running the same release of Solaris and they are both at the same patch level. Otherwise, you will almost certainly run into a situation where the container will refuse to attach to the new host.

I have created a cloned container called mx2. First, I have detached the container:

bash-3.00# zoneadm -z mx2 detach

Then I compressed the container directory so I could move it to host B. It does not really matter which tool you use to compress the directory. Just make sure you preserve permissions, ownership or ACL’s . For me, for some reason tar had a little of an ordeal compressing the container directory:

bash-3.00# cd /export/home/zones bash-3.00# tar cf mx2.tar mx2 tar: mx2/root/usr/jdk/instances/jdk1.5.0/jre/lib/sparc/cpu/sparcv9+vis/sparcv9/libclib_jiio.so: symbolic link too long tar: mx2/root/usr/jdk/instances/jdk1.5.0/jre/lib/sparc/cpu/sparcv9+vis2/sparcv9/libclib_jiio.so: symbolic link too long

Once I had the directory compressed I scp-ied it to host B. Then I decompressed it in the zones directory:

bash-3.00# cd /export/home/zones bash-3.00# tar xf mx2.tar

I have recreated the problematic symlinks mentioned above manually. If you are having trouble attaching the container check that container configurations are the same on both systems.

Before you can attach a container, you need to have container configuration in place. Without it you will not be able to attach the container.

Make sure your configuration is correct. I was attaching full root container and the system was complaining that the container being attached is missing some packages. In reality, my container configuration was for sparse root container. It turned out that when I was importing container configuration, some inherit-package-dir statements were added which has caused attach operation to fail. I had to remove those manually.

So, again, before attaching the container make sure your container configuration is good, you are inheriting correct package directories, etc. Once you have that right, you can attach the new container:

bash-3.00# zoneadm -z mx2 attach

That’s it. Depending on your needs you might want to change hostname, ip address and so on.

Some interesting linkage:

Solaris Containers replication

Mounting Linux NFS share: Not owner

somedude — Sun, 11 Oct 2009 12:03:22 +0000

I was trying to mount a RHEL 4 NFS share in Solaris 10. But for whatever reason I just could not seem to get it mounted. It would always come back with “Not owner” error:

bash-3.00# mount -F nfs carbon:/media/cdrecorder /mnt/carbon nfs mount: mount: /mnt/carbon: Not owner

So, I checked and rechecked my settings with no success. Then, I remembered reading something somewhere about NFS v4 in Linux being not so great at one time. Since the Linux box was running RHEL 4 I tought this might be my problem. So, I decided to force mount using NFS v3, since Solaris 10 will try to mount the Linux share using NFS v4 first.

bash-3.00# mount -F nfs -o vers=3 carbon:/media/cdrecorder /mnt/carbon bash-3.00# cd /mnt/carbon bash-3.00#

That worked well. Since this was one time mounting job, I did not bother any further. If I would be doing this on regular basis I would probably edit /etc/default/nfs on the Solaris box and force maximum NFS client version to be v3.

Weird disk label after using ZFS on a LUN

somedude — Sun, 04 Oct 2009 15:42:49 +0000

If you ever used ZFS on a LUN and then tried to reuse that LUN for UFS you might have noticed a “weird” disk label on it. This is known as EFI label.

Here is how it looks in format command:

partition> p Current partition table (original): Total disk sectors available: 73383902 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector 0 usr wm 34 34.99GB 73383902 1 unassigned wm 0 0 0 2 unassigned wm 0 0 0 3 unassigned wm 0 0 0 4 unassigned wm 0 0 0 5 unassigned wm 0 0 0 6 unassigned wm 0 0 0 8 reserved wm 73383903 8.00MB 73400286

If you use straight format command there is no way to get rid of EFI label. Instead, you have to use -e option with format to get to expert features:

bash-3.00# format -e

With -e options when you label the LUN you will be asked about the type of label you want to put on the disk:

format> label [0] SMI Label [1] EFI Label Specify Label type[1]: 0 Warning: This disk has an EFI label. Changing to SMI label will erase all current partitions. Continue? y Auto configuration via format.dat[no]? yes

I suppose you could alternatively use dd command and blank out the whole disk.

Corrupt superblock, now what?

somedude — Thu, 17 Sep 2009 19:41:54 +0000

This is an oldie, but a goodie. For some reason I was asked about it 3 times in a span of a week. Suppose your system was not shut down cleanly and it refuses to come up. During bootup fsck refuses to run, complaining about corrupt superblock. So, what do you do? First, get the alternate superblock locations and then run fsck using one of the alternate superblocks.

To get alternate superblock locations do:

newfs -Nv /dev/rdsk/c0t0d0s3

This will not actually format the slice. It will only print what it would do, if it was actually formating the slice. Basically, it is newfs dry run. It will also give you locations of alternate superblocks on the slice. I guess it should be mentioned that if you used non-default values while formating the slice originally, and you did not make a note of those values, this might not give you valid superblock numbers.

After you have your alternate superblock numbers you can use them to help out fsck (in this case superblock I am using is in block 8192):

fsck -y -F ufs -o b=8192 /dev/rdsk/c0t0d0s3

It might not hurt to run the above with -n option instead of -y to make sure it produces the results you are looking for.

Hopefully, the filesystem is not hosed so badly that it can not be repaired. This was more of an issue when Solaris did not have ufs logging. Nevertheless, it does not hurt to know this for one of those emergencies.

Cloning Solaris Container

somedude — Mon, 10 Aug 2009 19:23:33 +0000

There are two way to create a new container: create one from scratch, which takes a little while or you can clone an existing container. Cloning is quite faster than the actual creation so it is handy to have a “gold” master container which is used for cloning. Another reason for having a “gold” master container is the fact that the container from which you are making a clone has to be halted during cloning. I did this on Solaris 10 8/07 release. Cloning consists of the following:

Export configuration of an existing container or create a new configuration from scratch
Customize the exported configuration for the new container
Import the new container configuration
Clone the “gold” master container
Configure the new container

First you need configuration for the new container. You can either make one from scratch or export one from existing container and customize it.
The following command will export the configuration from “gold” master container and save it into /tmp/mx1.cfg file:
bash-3.00# zonecfg -z gold export -f /tmp/mx1.cfg

Now you can edit the configuration. Word of caution, importing seems to be a little flaky. For example, if an existing container has bootargs variable set, you will need to put quotes around them in the config file. So, if my bootargs are set to -m verbose, the string will have to be enclosed in “”. Otherwise the new container configuration will not be imported properly.

Once you have the configuration ready you can import it:
bash-3.00# zonecfg -z mx1 -f /tmp/mx1.cfg

Now you can perform actual clone operation:

bash-3.00# zoneadm -z mx1 clone -m copy gold Cloning zonepath /export/home/zones/gold...

This should not take very long. Once the operation is done you can see that the new container has been installed:

bash-3.00# zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / native shared - mx1 installed /export/home/zones/mx1 native shared - gold installed /export/home/zones/gold native shared

At this point you can boot the new container. You will be taken through initial configuration of the container. This initial container configuration can be pain if you are rolling out a lot of containers. You can simplify the process by creating a sysidcfg file and putting it into /etc directory of the container before performing the first boot.

In my case I would put the following sysidcfg into /export/home/zones/mx1/root/etc:

system_locale=C terminal=vt100 network_interface=primary { hostname=mx1 } security_policy=NONE name_service=DNS { domain_name=example.com name_server=192.168.1.1 search=example.com } nfs4_domain=dynamic timezone=US/Central root_password=n2GSHfh

The nice thing about cloning is the fact that it’s fairly quick. So if you hose up a container, you can simply run

bash-3.00# zoneadm -z mx1 uninstall Are you sure you want to uninstall zone mx1 (y/[n])? y

followed by

bash-3.00# zonecfg -z mx1 delete Are you sure you want to delete zone mx1 (y/[n])? y

and start all over again.

How to get HP Jetadmin working inside Solaris Container

somedude — Tue, 07 Jul 2009 18:57:42 +0000

I needed to build a print server and I had to use HP Jetadmin. I also wanted to use the Containers technology for the job. Here are few things I found out in the process. This was done on Solaris 10 08/07 and Jetadmin version E.10.34.

I did a little bit of searching, and all I found were conflicting reports: it should work, it does not work, it works, but not really…

First of all the container that will host Jetadmin has to be full-root, as Jetadmin install will put some files into /usr/spool. I suppose it would be possible to work around it and use sparse-root, even though it might be a little messy.

The problem I ran into was while creating print queues using hppi tool. During the process mknod command is called to create printer device file in /dev directory of the container. You can not use mknod inside a container and creation of the device file will fail. Sure enough, greping for mknod in Jetadmin’s admin directory yields the following:

bash-3.00$ grep mknod * addptrtoq: mknod $DFILE c 13 2

Closer look at addptrtoq reveals the following:

HPNPMODEL=$HPNP/sh/hpnp.model #DFILE=$HPNP/etc/$SPOOLNAME DFILE=/dev/$SPOOLNAME if [ ! -c $DFILE ] then mknod $DFILE c 13 2 fi chmod 666 $DFILE

So to get around the problem, first you manually have to create the special file in the global zone inside /dev directory of the print server container. Then you can proceed with installing the printqueue using hppi tool.

bash-3.00# cd /export/home/zones/prtsvr/dev/ bash-3.00# mknod laser c 13 2 bash-3.00# chmod 666 laser

Now you should be able to add a printer queue without any problems. So Jetadmin works just fine inside Solaris 10 Container. For me, anyways…