Suppose you have a set of hosts S that you can only reach via ssh from host V
by authenticating against a RADIUS server R and tunnelling your connections
through a proxy server P from R.

So you set up an ssh config with the appropriate tunnels on V and everything
is well. When you're on V, you can reach any host in S via ssh.

Now suppose that host R can only be reached from V, but not from your local
host L. So what you want is an ssh configuration that allows you to tunnel
every connection to a host in S through V to R (and thus from there through P
to the final host).

The configuration below allows you to do just that:

On V, add to your ~/.ssh/config:

Host proxy_from_v
        HostName R
        LocalForward 9342 P:22              

Host *.S
        ProxyCommand /usr/bin/ssh -p 9342 localhost /usr/local/bin/nc %h %p

On L, add the following to your ~/.ssh/config:

Host proxy_to_v
        HostName V
        LocalForward 9922 localhost:9342

Host *.S
        ProxyCommand /usr/bin/ssh -p 9922 localhost /usr/local/bin/nc %h %p

Then, to setup the ssh tunnel, run:

ssh -t proxy_to_v "ssh -t proxy_from_v"

This gets you to V and from there sets up the proxy through R to P.

Having sorted this out without a whiteboard makes me feel like after having a
Pangalactic Gargleblaster. You may draw yourself the corresponding picture
with clouds representing the interweb and pipes with numbers on them the
tunnels. Don't forget to get the arrows right! :-)

A presentation on Shell Coding given at SCALE 2007: Useless Use of *.

netmeister.org is now brought to you by NetBSD/macppc.

It's running on a Mac Mini, using this kernel config file (this actual kernel). Installation was done using these instructions -- whoever wrote them clearly was a genius.

While migrating our NFS server, I had to also make sure that quotas are migrated as well. Unfortunately, Solaris's edquota(1M) does not have any switch to read quotas from a file generated by repquota(1M) (as IRIX's edquota(1M) does).

To export and import all quotas, I did the following:

On the IRIX host:

$ cd /home
$ for i in *; do
>    quota -v $i > /tmp/quotas/$i
> done
$ cd /tmp
$ tar cf quotas.tar quotas

On the Solaris host:

# touch /export/people/quotas
# chmod 600 /export/people/quotas
# quotaon /export/people
# cd /tmp
# tar xf quotas.tar
# cd quotas
# setenv EDITOR /bin/ed
# foreach i (*)
>    sh /tmp/mkquota.sh $i
> end

/tmp/mkquota.sh:

#!/bin/sh

LINE=`awk '/people/ { print "fs /export/people blocks (soft = " $3 ", hard = " $4 ") inodes (soft = " $6 ", hard = " $7 ")"}' $1`

(
        echo "/people"
        echo d
        echo a
        echo $LINE
        echo .
        echo w
        echo q
) | edquota $i

(Here, I'm just enstating the quota on the "/export/people" filesystem, obviously.)

Now any files already existing on the filesystem do not count towards the quota if they have been created before the quotaon(1M) command was run. To fix this, run

# quotacheck -afp

Finally, edit /etc/vfstab to add rq to the mntflags field for the relevant filesystem.

Still trying to figure out what exactly is going on here, I took somebody else's advise and tried to see if maybe there is a relation between the size of the zpool and the NFS performance.

Connecting the machine in question to a different XRaid with a 745 GB Raid-5 disk, I tried to create a single zpool on that disk. Again, the same performance problems as noted earlier. Then I partitioned the disk into a 100 GB partition and tried to create a zpool on that. Again, no luck. Performance still stinks.

FWIW, format reports the xraid disks as:

       2. c3t0d0 <APPLE-Xserve RAID-1.50-2.73TB>
          /pci@0,0/pci1022,7450@b/pci1000,1010@1,1/sd@0,0
       3. c3t1d0 <APPLE-Xserve RAID-1.50-2.73TB>
          /pci@0,0/pci1022,7450@b/pci1000,1010@1,1/sd@1,0
       4. c3t2d0 <APPLE-Xserve RAID-1.26-745.21GB>
          /pci@0,0/pci1022,7450@b/pci1000,1010@1,1/sd@2,0

Related patches and bugs:

* Solaris x86 patch 122641-06 (applied, but does not fix the problem)
* Bug ID 6365101
* Bug ID 6413510

I've also posted my experience to the zfs-discuss mailing list. Maybe somebody there can figure this out.