unixpowered.com

I had a few users that needed their own Solaris Container. They would use Reflection X to connect to their Containers. It worked all fine. Well, for the most part. Every few days or so Containers would stop accepting X connection. When I looked at /var/dt/Xerrors logfile inside one of the containers, I would see a lot of complaints:

XIO: fatal IO error 146 (Connection refused) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining.
fbconsole: ioctl SRIOCSREDIR: Invalid argument
/dev/fb: No such file or directory
/dev/fb: No such file or directory
Graphics Adapter device /dev/fb is of unknown type

Fatal server error:
InitOutput: Error loading module for /dev/fb

That got me thinking there will be some problem with absence of frame buffer. And sure, Sun mentions this in article 1011661.1.

You have to comment out

:0 Local local_uid@console root /usr/openwin/bin/Xsun :0 -nobanner

in /etc/dt/config/Xservers. If that file is absent make a copy from /usr/dt/config/Xservers. This will prevent X-windows manager starting on the console. If you are using XDM, you will need to comment out:

:0 Local local /usr/openwin/lib/xdm/StartOW :0

in /usr/openwin/lib/xdm/Xservers. That had fixed the issue. Continue Reading

I had to create some containers for developers to do their work. Developers always seem to want root access to a machine. Containers work very nice in this scenario: if a developer messes up his container, I can just clone a new one off a “gold” container. ZFS can be very handy here as well: by installing a container on ZFS filesystem and assigning ZFS quota, you can limit how big the container can grow.

So, first I created a ZFS pool out of two slices on two disks. This is not really recommended way to create ZFS pool. You should really be using two whole disks. And, ignore the fact that those disks both reside on the same controller. Right after that I created dev1 filesystem within the zonepool:

bash-3.00# zpool create -m /export/home/zones zonepool mirror c0t0d0s3 c0t1d0s3
bash-3.00# zfs create zonepool/dev1
bash-3.00# zfs list
NAME               USED  AVAIL  REFER  MOUNTPOINT
zonepool           122K  55.6G  25.5K  /export/home/zones
zonepool/dev1     24.5K  8.00G  24.5K  /export/home/zones/dev1

Next I set ZFS quota on the filesystem to 8GB:

bash-3.00# zfs set quota=8G zonepool/dev1
bash-3.00# zfs get all zonepool/dev1
NAME              PROPERTY       VALUE                       SOURCE
zonepool/dev1     type           filesystem                  -
zonepool/dev1     creation       Fri Jun  4  9:17 2010       -
zonepool/dev1     used           24.5K                       -
zonepool/dev1     available      8.00G                       -
zonepool/dev1     referenced     24.5K                       -
zonepool/dev1     compressratio  1.00x                       -
zonepool/dev1     mounted        yes                         -
zonepool/dev1     quota          8G                          local
zonepool/dev1     reservation    none                        default
zonepool/dev1     recordsize     128K                        default
zonepool/dev1     mountpoint     /export/home/zones/dev1     inherited from zonepool
zonepool/dev1     sharenfs       off                         default
zonepool/dev1     checksum       on                          default
zonepool/dev1     compression    off                         default
zonepool/dev1     atime          on                          default
zonepool/dev1     devices        on                          default
zonepool/dev1     exec           on                          default
zonepool/dev1     setuid         on                          default
zonepool/dev1     readonly       off                         default
zonepool/dev1     zoned          off                         default
zonepool/dev1     snapdir        hidden                      default
zonepool/dev1     aclmode        groupmask                   default
zonepool/dev1     aclinherit     secure                      default
zonepool/dev1     canmount       on                          default
zonepool/dev1     shareiscsi     off                         default
zonepool/dev1     xattr          on                          default

Now, I should mention, that prior to configuring /export/home/zones to reside on ZFS I uninstalled dev1 container which was there previously. So, the container itself was gone, but the system still had knowledge of the container’s configuration. I wrote a post on configuring containers here.

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

Since the container was already configured, I went ahead and started installing it:

bash-3.00# zoneadm -z dev1 install
/export/home/zones/dev1 must not be group readable.
/export/home/zones/dev1 must not be group executable.
/export/home/zones/dev1 must not be world readable.
/export/home/zones/dev1 must not be world executable.
could not verify zonepath /export/home/zones/dev1 because of the above errors.
zoneadm: zone dev1 failed to verify
bash-3.00#

Woops, looks like the container directory permissions need some fixing:

bash-3.00# cd /export/home/zones/
bash-3.00# ls -l
total 3
drwxr-xr-x   2 root     sys            2 Jun  3 09:48 dev1
bash-3.00# chmod 700 dev1
bash-3.00# chown root:root dev1

One more try to install the container:

bash-3.00# zoneadm -z dev1 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <2561> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1086> packages on the zone.
Initialized <1086> packages on zone.
Zone  is initialized.
The file  contains a log of the zone installation.

That’s it. After the container install completed, before booting dev1, I stuck the following sysidcfg file into /etc directory of dev1 container:

bash-3.00# more sysidcfg
system_locale=en_US
timezone=US/Central
terminal=vt100
security_policy=NONE
network_interface=primary {
hostname=dev1
}
nfs4_domain=dynamic
name_service=NIS {
domain_name=example.com
name_server=nis1(10.1.1.1)
}

That way I would not be asked any container configuration questions during first container boot. Except for the root password, of course. 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

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:

1. Export configuration of an existing container or create a new configuration from scratch
2. Customize the exported configuration for the new container
3. Import the new container configuration
4. Clone the “gold” master container
5. 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. Continue Reading

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