unixpowered.com

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. Continue Reading

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… Continue Reading

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:

1. Take an HP Jetdirect printer that you already have configured.
2. 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.
3. Add a print queue as you normally would.
4. Remove the /etc/hosts file entry.
5. 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. Continue Reading

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. Continue Reading

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

1. Make a clone of an existing container on host A
2. Detach the clone
3. Compress it and move it to host B
4. Create configuration for the moved container
5. Decompress the container on host B
6. 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
Continue Reading