With older version of NFS, this usually meant that the filesystem was not exported with read/write access to the host, but, since this had already been done quite some time ago, it looked like the problem was related to NFSv4.   Some quick investigation showed this to be the case.

The resolution was two fold:

1.  On the Netapp, I make sure that “nfs.v4.id.domain” was set to the domain name.  It defaults to nothing “”.
2. Again, on the Netapp, since we are not using a centralized location for accounts (we have < 12 accounts across all of the systems), I had to populate /etc/passwd with all of the accounts on the rest of the systems and /etc/group with all of the groups defined on the rest of the systems.

That brought the behavior back to what was expected.

Now, you can do this in two steps:

# lofiadm -a /export/temp/software.iso /dev/lofi/1

# mount -F hsfs -o ro /dev/lofi/1 /mnt

But that requires some cleanup afterwards (rm /dev/lofi/1) otherwise, over time, you end up with a bunch of mapped block devices pointing to files that are no longer on the system. It is a “best practice” to combine the commands in to a single command:

# mount -F hsfs -o ro `lofiadm -a /export/temp/software.iso` /mnt

However, in my case, we were looking at ways to incorporate other systems in to our RAC cluster. Due to the way that Oracle RAC is designed, the public (primary) interface on all of the systems in the RAC cluster MUST be the same. In other words, they must all be “ce0″ or “hme0″ or whatever the device name is.

This isn’t really a problem under linux since you can easily define which interface gets to be named “eth0″, but under Solaris, this can be a bit of a problem when you try to incorporate different machine types in to the cluster. Because Solaris assigns an interface name based upon the chipset of the NIC, some systems might have “ce0″ (such as on the V480) while others might have “ipge0″ (such as on the T2000).

So.. how do you add a machine with a different primary device name in to the cluster? Well, the answer is actually quite simple: create an alias to it. It’s just not the same alias that you get from plumb’ing an interface.

In the /dev tree, simply create a symbolic to the primary interface using the name that you want. For example:

# cd /dev

# ln -s ce public

# ifconfig public0 plumb

# ifconfig public0
public0: flags=1000842<UP,RUNNING,MULTICAST,IPv4> mtu 1500 index 5
inet 0.0.0.0 netmask 0
ether 0:3:ba:2a:e8:c5

And you are done. You now have an interface called “public0″ which is known as your primary interface. Be aware, though, that this will BE DESTROYED if you reboot the system with the “-r” flag as this will force a rebuild of the entire device tree.

One of the difficulties I recently encountered was changing the IP of an interface on Solaris 10. Now, this is usually not a difficult task, so I was surprised when a simple edit of /etc/hosts and /etc/nodename, and /etc/hostname.ipge0 didn’t have the normal impact upon rebooting.

After some digging around, it seems that Solaris 10 relies on /etc/inet/ipnodes rather than /etc/hosts. Yes, you should update both, but the important one for interface specifics is /etc/ipnodes.

I tried it out in an environment where both ends were Fedora Core Linux systems and the installation went extremely well. In fact, it was almost simple. The tough part was getting the configuration fine-tuned enough such that it would be both secure yet easy to use.

The real key was an article in SysAdmin that covered how someone installed OpenVPN on a Linux server, and built a customized OpenVPN install on a Windows desktop system using the NullSoft Install System.

It was not long before the environment was completely off of the Cisco VPN hardware (part of the PIX) and fully on OpenVPN. The trick, however, was battling the situation where the single Linux server was down for one reason or another (a failed mirrored drive). The only secondary system that was available was a Solaris 8 system which is the predominant system in our environment anyhow.

So, I set about getting OpenVPN up and running. Unfortunately, Solaris 8 does not have a built in tunnel device (aka: tun) that OpenVPN requires. The documentation within the OpenVPN readme was a little misleading:

* Solaris

For 64 bit, I used the tun-1.1.tar.gz source and compiled it.

Of course there is a but
In the tun-1-1\solaris\Makefile I changed a line so it compiles with 64 bit

CFLAGS = $(DEFS) -m64 -O2 -Wall -D_KERNEL -I.

I just added -m64 and it worked.

The tun driver works fine as said previously, however we noticed there is a minor problem when creating multiple tunnels on Solaris.
Mr Tycho Fruru changed the code in tun.c file where he locked the tun device number to -1. This way it is impossible to specify the name of the tun device but it is still possible to have multiple devices.
The modification will increment automatically meaning starting from tun0 —> tunX I know you are not responsible for the tun coding but if you think the modification can be useful for you feel free to use it.

http://openvpn.net/solaris/tun.c

Now, that tells me that you need to add the option to the CFLAGS to build it as a 64-bit binary and that, if you are creating multiple tunnels, you need to patch the tun.c file.

BZZT. Wrong. You need to do both if you want to do anything with the device, otherwise Solaris will not make any of the /dev/tun* devices, and, hence, OpenVPN will not work.

Of course, that minor difference in terminology resulted in about 4 business days of effort on-again/off-again effort to get OpenVPN working on Solaris 8.

Another individual contacted me regarding his troubles getting the “tun” driver to build and install properly under Solaris 8, and I helped walk him through it. Oddly, he couldn’t even get it to compile (through no failure of his own)! I sent him a tar file of my patched and compiled version and he was able to get things up! So, I thought I would make it available here (not sure why, but wordpress stripped out some of the periods.  The file should be named tun-1.1-patched.tar.gz). Perhaps I was lucky (seems that way) to get it to compile.