In my case this is absolute nonsense as I _KNOW_ that the local network is working, but it doesn’t have an internet connection for now. So I want a way to get out of the stupid wizard. Tapping on the various buttons as well as turning off/on the device will not help in exiting the setup wizard.

At last, just keeping the “BACK” button pressed for a few seconds will sound an acustic signal (multiple beeps) and drop you out to the main menu.
And if you – as me – configured your WiFi settings, these will still be kept intact.

You now can connect your local SqueezeBox media server from the “My Music” menu.

Missing accomplished. I just wonder why this is not officially documented.

After all, I had to take additional hurdles to get the new firmware onto my Squeezebox Radio.

Whenever I access my website using it’s plain domain name (http://phunsites.net), I’d end up with a password prompt from my DSL router.

Thinking about DNS it would be an easy asumption that there was likely to be a wrong resource record like this in my DNS zone:

@ IN A 192.0.2.1

But it turned there wasn’t – why should it anyway?
Looking further into this, I did a DNS trace. It was strinking that querying for www.phunsites.net would yield another result …

$ dig A www.phunsites.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> A www.phunsites.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24771
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;www.phunsites.net.		IN	A

;; ANSWER SECTION:
www.phunsites.net.	86170	IN	A	82.195.224.130

;; AUTHORITY SECTION:
phunsites.net.		60583	IN	NS	ns1.genotec.ch.
phunsites.net.		60583	IN	NS	ns2.genotec.ch.
phunsites.net.		60583	IN	NS	ns3.genotec.ch.
phunsites.net.		60583	IN	NS	ns4.genotec.ch.

;; ADDITIONAL SECTION:
ns1.genotec.ch.		58593	IN	A	82.195.224.5
ns1.genotec.ch.		58593	IN	AAAA	2001:1b50::82:195:224:5
ns2.genotec.ch.		58593	IN	A	82.195.225.5
ns2.genotec.ch.		58593	IN	AAAA	2001:1b50::82:195:225:5
ns3.genotec.ch.		58593	IN	A	82.195.235.37
ns3.genotec.ch.		58593	IN	AAAA	2001:1b50::2:82:195:235:37
ns4.genotec.ch.		58593	IN	A	82.195.235.69
ns4.genotec.ch.		58593	IN	AAAA	2001:1b50::3:82:195:235:69

;; Query time: 12 msec
;; SERVER: 82.195.225.6#53(82.195.225.6)
;; WHEN: Tue Apr  5 13:43:27 2011
;; MSG SIZE  rcvd: 309

... than phunsites.net:

$ dig A phunsites.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> A phunsites.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60489
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Messages has 1 extra bytes at end

;; QUESTION SECTION:
;phunsites.net.			IN	A

;; ANSWER SECTION:
phunsites.net.		60	IN	A	192.0.2.1

;; Query time: 1 msec
;; SERVER: 82.195.225.6#53(82.195.225.6)
;; WHEN: Tue Apr  5 13:43:47 2011
;; MSG SIZE  rcvd: 48

That was very bizare. As it turned out, the DrayTek Vigor does DNS proxying by default.
There's usually nothing too wrong about that, but in my case, it was pretty annoying, because the router seemed to inject it's own IP address for queries destined to its domain name.

So my intent was to remove the domain name which I had earlier configured on the router GUI. Unfortunately that was not possible. Whenever I deleted my domain name it would show up again later on in the GUI, even after a reboot.

So I gave it a shot through the Telnet CLI, where I tried to remove the domain name using this command "sys domainname clear".

Checking back with dig it turned out to give me the proper DNS reply I expected earlier for qerying phunsites.net:

$ dig A phunsites.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> A phunsites.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50148
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;phunsites.net.			IN	A

;; ANSWER SECTION:
phunsites.net.		83205	IN	A	82.195.224.130

;; AUTHORITY SECTION:
phunsites.net.		59427	IN	NS	ns2.genotec.ch.
phunsites.net.		59427	IN	NS	ns1.genotec.ch.
phunsites.net.		59427	IN	NS	ns3.genotec.ch.
phunsites.net.		59427	IN	NS	ns4.genotec.ch.

;; ADDITIONAL SECTION:
ns1.genotec.ch.		57437	IN	A	82.195.224.5
ns1.genotec.ch.		57437	IN	AAAA	2001:1b50::82:195:224:5
ns2.genotec.ch.		57437	IN	A	82.195.225.5
ns2.genotec.ch.		57437	IN	AAAA	2001:1b50::82:195:225:5
ns3.genotec.ch.		57437	IN	A	82.195.235.37
ns3.genotec.ch.		57437	IN	AAAA	2001:1b50::2:82:195:235:37
ns4.genotec.ch.		57437	IN	A	82.195.235.69
ns4.genotec.ch.		57437	IN	AAAA	2001:1b50::3:82:195:235:69

;; Query time: 44 msec
;; SERVER: 82.195.225.6#53(82.195.225.6)
;; WHEN: Tue Apr  5 14:02:43 2011
;; MSG SIZE  rcvd: 305

So to summarize: The DrayTek Vigor injects the "domain name suffix" as configure through the "sys domainname" command into the DNS proxy.
This is very odd, as I would suppose, that it would do so only for the fully qualified domain name (FQDN), which would make perfectly sense then.

Checking into this I made a lookup for the FQDN called phn-vgw-dsl-001.phunsites.net and got this reply promptly:

$ dig A phn-vgw-dsl-001.edge.phunsites.net.

; <<>> DiG 9.6.0-APPLE-P2 <<>> A phn-vgw-dsl-001.phunsites.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19107
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Messages has 4 extra bytes at end

;; QUESTION SECTION:
;phn-vgw-dsl-001.phunsites.net. IN	A

;; ANSWER SECTION:
phn-vgw-dsl-001.phunsites.net. 60 IN A	192.0.2.1

;; Query time: 1 msec
;; SERVER: 82.195.225.6#53(82.195.225.6)
;; WHEN: Tue Apr  5 14:11:31 2011
;; MSG SIZE  rcvd: 72

I could live with this behaviour if I think that one would perhaps prefer to set a more memorizable FQDN for the device, let's say "router.phunsites.net", which would automagically appear even if no matching DNS recource records exist.

However, it feels absolutely inappropriate for the DrayTek Vigor to inject a spoofed A resource record for the domain name suffix as well. This holds especially true when a matching resource record in the zone indeed already exists.

As a IT professional I tend to always configure all settings properly on my devices. In this case, this attitude unconvered a very odd and in my opinion erronous behaviour.

As there is no current firmware to fix this, there's only two ways to work around this: Either unconfigure the domain name as shown above through the "sys domainname clear" command or use a domain name suffix, that does not collide with a real domain name or FQDN.

After all, this is surely no big deal, but a pitfall nevertheless. As DrayTek routers are still four to five times more expensive than the usually cheap home routers I wouldn't expect to see such misbehaviour.

The most painful experience in this situation was that I suddenly sat there without working computer around. More dramatically was the fact that my TimeMachine backup was from the evening before, so I had some real nightmares about having partially lost my essay I was writing at that time.
Well, for a fast (and final) fix, I just got myself one of these fancy new MacBook Pro modells, so I could just go on with my work.

Albeit having a new computer, I just wondered about possible reasons for my MacBook failure. While digging around I found that there was well-known issue with 3rd generation MacBook pro with Nvidia graphics adapter, wich was even officially aknowledged by Apple. Actually, Apple even offered free repair of such defective MacBook Pro within four years of purchase (according to their support article).

Defective MacBooks affected by this issue are typically considered having a “blank screen” or distorted video. In case of “blank screen”, affected systems are still playing the “Mac chime” upon power-on and the CAPS-LOCK LED being lit when pressing the key. You could even boot the system and at least “hear” audible feedback to several keystrokes (e.g. the volume up/down keys, etc).

So that qualifies clearly for a MacBook Pro being affected by the Nvidia chip issue.

There’s the problem, however: You need to prove your purchase. If you don’t have an original receipt, Apple gently refuses to repair the broken MacBook Pro, as I was assured after talking to the helpline. Oh well … out of warranty, no proof of purchase … absolute failure! (BAD RANT at Apple for this!!!)

Oh, well, so no fix for me as I don’t have the prove of purchase. Baaah …

To fix the MacBook, I would have needed to exchange the LogicBoard. These do cost however several hundred Swiss Francs, definitely way beyond what’s worthwile to invest into a 4-year-old device.

During my research on the web I came along other sites covering this topic. Some of these sites did even propose fixing the LogicBoard by butting it into your oven and baking it for 5-10 mins at around 200°-220° (392 – 448 F). The idea behind this is simple: By exposing the board to heat in the oven, the reflow soldering assembling conditions are reproduced, which can eventually fix broken soldering points.

I found the best instructions on Philip May’s blog (in german language).
Instruction to disassemble the MacBook Pro were found on ifixit.com.

So tonight I took on the challenge to put my MacBook into the oven … ok, ok, just the plain LogicBoard
Below you’ll find some pictures of the process. And guess what? It really worked. My “broken” 3rd gen is now up and running again.
That leaves me only to this question: I’ve bought a new one already, what would I do with the old one now?

I used to do hot-plugging before, but I’ve never done this with a whole enclosure at once. Well worth a try?

Some things to be considered for my scenario:

• The Sun StorEdge Multipack auto-assigns SCSI-IDs ascending through it’s internal slots. Depending on the mode switch, it’ll assign IDs 1 through 6 or 9 through 15. On the Netra T1 105 only IDs 1 through 7 are supported. This is no big deal, unless you already have two disks plugged into the internals bays (they take IDs 0 and 1).
  So you can add a maximum of 5 additional disks (IDs 2 through 6). This actually means that you can only add disks to bays 2 through 6, leaving bay 1 empty. If you keep a disk inside, it’ll get ID 1, which won’t work out as this is already taken by an internal bay hard drive.
• Also important is that the enclosure is not powered-up. Attach it to the SCSI bus first, before you power on.

After powering on the enclosure it’ll take a few moments to initialize and spin-up the drives.

I recommend waiting for the SCSI ID LED to light up, before you proceed.
Before you rescan the bus, check which devices you see.


[root@rohan ~]# camcontrol devlist
IBM DDYST1835SUN18G S96H at scbus0 target 0 lun 0 (da0,pass0)
IBM DDYST1835SUN18G S96H at scbus0 target 1 lun 0 (da1,pass1)


The you can either add each new divice one by one, issuing a “scan” command for the respective SCSI-ID:


[root@rohan ~]# camcontrol rescan scbus0:2:0
[root@rohan ~]# camcontrol devlist
IBM DDYST1835SUN18G S96H at scbus0 target 0 lun 0 (da0,pass0)
IBM DDYST1835SUN18G S96H at scbus0 target 1 lun 0 (da1,pass1)
FUJITSU MAN3184M SUN18G 1502 at scbus0 target 2 lun 0 (da2,pass2)


Or you could try to rescan to whole bus at once:


[root@rohan ~]# camcontrol rescan scbus0
Re-scan of bus 0 was successful
[root@rohan ~]# camcontrol devlist
IBM DDYST1835SUN18G S96H at scbus0 target 0 lun 0 (da0,pass0)
IBM DDYST1835SUN18G S96H at scbus0 target 1 lun 0 (da1,pass1)
FUJITSU MAN3184M SUN18G 1502 at scbus0 target 2 lun 0 (da2,pass2)
FUJITSU MAJ3182M SUN18G 0804 at scbus0 target 3 lun 0 (da3,pass3)
IBM DDYST1835SUN18G S96H at scbus0 target 4 lun 0 (da4,pass4)
SEAGATE ST318203LSUN18G 034A at scbus0 target 5 lun 0 (da5,pass5)
SEAGATE ST318203LSUN18G 034A at scbus0 target 6 lun 0 (da6,pass6)


Conclusion: If you first connect to the bus and then power-up the enclosure so all disks can properly initialize, adding the enclosure and it’s disks while online is definitely possible. Of course, you should only be doing this with hot-plug ready equipment, which supports auto-termination.

Today I took the time to shutdown the Phunsites’ Lab. During all these years, it served a good purpose. Most of my ideas and PoCs were initially developped on these machines, before they evolved in some detailed design specs.

I can’t count how often I re-installed these machines, compiled new kernels and complete userland. It was definitely a lot.

As you see from the pictures, there’s quiet a few machines, which made up my lab: 3 Sun Enterprise 450, 2 Sun Netra T1, 1 Sun SparcStation 20, 1 Sun Ultra 5, 1 Sun Ultra 2, a DEC Workstation and a Standard Intel-based Dual-CPU Machine.
Additionally there where a Cisco 2900-EN-XL switch, a serial console server, some external SCSI disk enclosures and zillions of spare material like CPU, Memory, Hard Drivers, and so on.

Originally, this equipment was joined by some SGI machines: 1 Indy, 1 Indigo and 2 O2 workstations. These have however been sold off last year already.

Now, finally, it seems to have come to an end. As with todays virtualization technology, there’s no real need all these machines to me anymore.

I will definitely keep some of the machines, the two Netra T1, as I have an idea already on how to put them to good use.
The others will be cleaned, repaired if needed, and then sold off on eBay.

So to concluded: Phunsites’ Lab WILL return. But it will be all different than it used to be.

I use a very basic Aten UC-232A dongle. There exist various variations out there, but most of them contain a PL-2303 chip, so despite some of them looking very different in design they’re basically the same thing.
Obviously mine stopped working after upgrading from OS X 10.5.x to 10.6.x “Snow Leopard”.

Looking for alternate drivers I came along a few sites, including some driver update pages which requered me to pay for it.
Oh wait a minute … paying for a device driver? Gosh … get lost!

I then found this site which actually has some drivers.
I though that the MAC OS10.x Intel Base driver would work, but it didn’t. Checking with the sudo kextstat command in an OS X Terminal would show, that it was never to get loaded.

Looking furtger, I found PL2303 USB to Serial Driver for Mac OS X at SourceForge. Giving it a try I sound found, that it wouldn’t work for me, neither.

But reading through the forums of that project I found an interesting reference to another PL2303 project site at github.com.
There I found an indeed working PL2303 driver for OS X Snow Leopard.
I keep a copy of this driver hosted at this blog, just in case that it disappears one day from github.

After installing the updated driver Snow Leopard immediately recognized the dongle and added it to network device list.
Following that, the new “PL2303-” serial port was then selectable in ZTerm to work with.

Well, thank you guys, for getting this driver to work on OS X. You saved my day!

Ok, I must admit, that I took a glimpse at the tiny netbooks more than once. My dream was to actually run it with OS X instead of Windows or Linux.

So, just the next-day my netbook was OS X-ified (a topic, which I’ll cover later on), only to notice some more or less annoying issues.

One of the most annoying issues was the stock WiFi, which required a very ugly 3rd party tool for configuration and was so absoluty not OS X-alike.

Two weeks ago I finally ordered a DW1390 mini PCIe WiFi card. It arrived today, so I went for immediate installation to see if it seamlessly works with my eeePC (or should it be called eeeBook instead?).

Here’s some pictures about the “unboxing experience”, though it’s not served up Apple-style

It’s almost as tiny as a standard USB stick:

Ready to open up the back-cover:

Disconnecting both antenna wires …

This is the empty socket after having the original card removed:

And here’s the new card plugged-in:

After re-assembly I booted into OS X to configure the new WiFi the real OS X-style.

Finally, one of the most annoying things on the eeeBook is gone now

The task was to review if it could serve its purpose as (expandable) external storage system for my company’s (then still new-to-be-built, now in service) ftp mirror, a disk-based backup system and other possible areas of working.

This hardware was available for testing:

• 1 SuperMicro 6014P-T Server stocked with 2 Intel Xeon CPUs @ 3.0 GHz, 4 GB RAM, 2 x 160 GB SATA (internal RAID1), 2 Intel Pro/1000 adaptors (network connectivity) and 2 Intel Pro/1000MT adaptors for dedicated iSCSI storage network
• 1 Transtec PROVIGO 410E stocked with 1 Intel P4 CPU, 1 GB RAM, 15 x 400 GB SATA drives, single controller with 2 Broadcam Gigabit adaptors
• HP ProCurve J4903A Switch 2824 (for Gigabit Testing with Jumbo Frames)

This article will look into intial setup of the Provigo, especially step-by-step via serial console, which is not covered in the official manuals.
Furthermore connecting the device to a frontend server (single-host configuration via iSCSI, global file system not considered for now) running RedHat Enterprise Linux will be outlined.

#1 Getting Rid Of The Packaging

Initially, the device was ordered back in April 2007. Due to some stock shortage delivery was first scheduled for mid of May 2007 and was later re-scheduled for June.

When it arrived there came that incredibly huge box which had to be lifted around by two people because of its size and weight (~ 50 kg’s).

Finally, after opening the box, I stood in front of the device. Along with it a pair of heavy rails, a serial cable and a documentation CD-ROM were included. Needless to say that a power cable with a german plug was shipped. Amazing that there are still some vendors who have not realized that we have a different power plug in Switzerland which is physically totally incompatible to the german ones.

Well, let’s leave this aside for now and look into the configuration stuff.

#2 Preparing the Frontend Server

First things first, I prepared the frontend server with a clean minimum install of RedHat Enterprise Linux 5.0.
While the basic installation is clearly beyond the scope of this article, below are the additional steps I have gone through.

#3 Disable Xen Console

If you happen to have only one serial port and also a Xen-enabled kernel installed, the serial console must be released from Xen.
This is done by adding xencons=off to the kernel appen line(s) in /etc/grub.conf like this:

default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-8.el5xen)
        root (hd0,0)
        kernel /boot/xen.gz-2.6.18-8.el5
        module /boot/vmlinuz-2.6.18-8.el5xen ro root=/dev/md0 xencons=off
        module /boot/initrd-2.6.18-8.el5xen.img

#3 Install minicom

For serial management a terminal emulator is required. I choose minicom which requires these rpm’s to be installed (sample applies to x86_64).

rpm -i lockdev-1.0.1-10.x86_64.rpm  minicom-2.1-3.x86_64.rpm

If your RHEL is configured to use a local repository via yum, you may run this instead:

yum install minicom-2.1-3.x86_64

To configure minicom run:

minicom -s

This will enter the setup dialog where I choose serial port setup first.

The Provigo has a 115200 8N1 factory default for the serial console, so I changed my settings as shown below.
I assumed /dev/ttyS0 (COM1) from my current hardware configuration.

    ┌───────────────────────────────────────────────────────────────────────┐
    │ A -    Serial Device      : /dev/ttyS0                                │
    │ B - Lockfile Location     : /var/lock                                 │
    │ C -   Callin Program      :                                           │
    │ D -  Callout Program      :                                           │
    │ E -    Bps/Par/Bits       : 115200 8N1                                │
    │ F - Hardware Flow Control : No                                        │
    │ G - Software Flow Control : No                                        │
    │                                                                       │
    │    Change which setting?                                              │
    └───────────────────────────────────────────────────────────────────────┘

Back to the main menu I entered modem and dialing where I removed the init strings so no AT init commands are sent to the host accidentally.

Afterwards I choose save setup as dfl and exit from minicom.

#4 Configure the Provigo

To configure the Provigo attach the serial cable shipped with the device to the RJ11 jack on the Provigo and the RS232 connector on the frontend host.
No start minicom and press enter. If everything works out you should receive a login prompt.

Welcome to minicom 2.1

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Jul 26 2006, 06:38:09.

Press CTRL-A Z for help on special keys

login:

The login name is root with a default password of root.

You may do the initial setup by running the ‘dasetup’ command for Q&A based setup.
This will however only cover some basic settings like IP address and hostname. Advanced configuration is still to be done manually.
For this reason I’ll apply all configuration manually.

First of all, set some arbitary hostname, a name server and – if required – a default route.

# dahostname SAN001
# dans -a 192.0.2.2
# daroute add default gw 192.0.2.1

Now the network interface must be configured for either default a mtu of 1500…

# daifconfig local da0 192.0.2.11 netmask 255.255.255.0 mtu 1500
***************** local diskarray controller ID 0 ******************
Set local host interface da0 192.0.2.11 netmask 255.255.255.0 mtu 1500
********************************************************************

or a mtu of 9000 aka jumbo frames.

# daifconfig local da0 192.0.2.11 netmask 255.255.255.0 mtu 9000
***************** local diskarray controller ID 0 ******************
Set local host interface da0 192.0.2.11 netmask 255.255.255.0 mtu 9000
********************************************************************

Even if source addresses can be spoofed eventually, adding an IP access control list is never wrong.
So this will first remove the default acl and add the test network and loopback range to the access list:

# daacl -d 0.0.0.0/0
# daacl -a 192.0.2.0/24
# daacl -a 127.0.0.0/8

And don’t forget to set new passwords for guest (unprivileged login) and root (admin login).

# dapasswd -p newpasswd guest
# dapasswd -p newpasswd root

Mind that the dapasswd command does not support single and double quotes.
If you have a password which includes special characters, it must be set like this:

# dapasswd -p my!special:32 root

You should also set the time zone and time/date of the device.
Refer to dadate -h for the input format.

# dadate -z UTC +2
# dadate -s 0702152607.00

Optionally email notification can be enabled as seen in daaddrbk -h command.

#5a Create Custom iSCSI Targets

Now that the basic configuration is complete it’s about time to define our custom iSCSI targets.
In client-server terminology, an iSCSI target refers to the server-side, which exports a block device to a client.

Some basic rules for iSCSI target names, which are also known as IQNs (iSCSI qualified names), define that an IQN consists of multiple tokens separated by dots and colons.

1st part is always the keyword ‘iqn’
2nd part equals to year and month when the domain name (see also 3rd part) was acquired, eg. 2004-07
3rd part is the reversed domain name, e.g. phunsites.net becomes net.phunsites
4th part is a colon as delimiter
5th part is a string or serial number which should refer to the storage system, eg. mac address, hostname, etc

So when getting this altogether a valid IQN could read like this:

iqn.2004-07.net.phunsites:san001

If you do now own a domain name or want to be strictly internal something like this could also be used:

iqn.2007-07.localnet.localhost:storage1

After having defined the proper IQN string it can be set and verified as follows:

# datarget -set iqn.2004-07.net.phunsites:san001
Target names are set for both controllers.

# datarget -show
Target name (local):    iqn.2004-07.net.phunsites:san001.0
Target name (remote):   iqn.2004-07.net.phunsites:san001.1

#5b Configure Disk Groups

Let’s have a look into disk groups, which are actually the RAID sets.
Disk groups may be created from all empty/unassigned disks. List them by means of the dadg command.

# dadg -Ldisk
Drive    View from controller 0    View from controller 1
Slot 0 (xda) ....................SPARE
Slot 1 (xdb) ....................SPARE
Slot 2 (xdc) ....................SPARE
Slot 3 (xdd) ....................SPARE
Slot 4 (xde) ....................SPARE
Slot 5 (xdf) ....................SPARE
Slot 6 (xdg) ....................SPARE
Slot 7 (xdh) ....................SPARE
Slot 8 (xdi) ....................SPARE
Slot 9 (xdj) ....................SPARE
Slot 10 (xdk) ....................SPARE
Slot 11 (xdl) ....................SPARE
Slot 12 (xdm) ....................SPARE
Slot 13 (xdn) ....................SPARE
Slot 14 (xdo) ....................SPARE

To create three disk groups with five disks per group forming a RAID5 use these commands:

#dadg -a DG1 -o 0 -l 5 -v 95 -m "Disk Group 1" /dev/xd[a-e]
#dadg -a DG2 -o 0 -l 5 -v 95 -m "Disk Group 2" /dev/xd[f-j]
#dadg -a DG3 -o 0 -l 5 -v 95 -m "Disk Group 3" /dev/xd[k-o]

Then verify how it looks like:

# dadg -Lall
------------------------------------------------------------
Information for all the disk groups in controller 0:
Disk group "DG1": active (vg_510842bddb23d1ed44cab1b242cdea52)
Disk group "DG2": active (vg_e944dd0ebcb7427aeea37cefdfc9c895)
Disk group "DG3": active (vg_a0e7be409536a4dd195cbead5986416b)
------------------------------------------------------------
Information for all the disk groups in controller 1:

# dadg -Ldisk
Drive    View from controller 0    View from controller 1
Slot 0 (xda) ............IN DG ("DG1")
Slot 1 (xdb) ............IN DG ("DG1")
Slot 2 (xdc) ............IN DG ("DG1")
Slot 3 (xdd) ............IN DG ("DG1")
Slot 4 (xde) ............IN DG ("DG1")
Slot 5 (xdf) ............IN DG ("DG2")
Slot 6 (xdg) ............IN DG ("DG2")
Slot 7 (xdh) ............IN DG ("DG2")
Slot 8 (xdi) ............IN DG ("DG2")
Slot 9 (xdj) ............IN DG ("DG2")
Slot 10 (xdk) ............IN DG ("DG3")
Slot 11 (xdl) ............IN DG ("DG3")
Slot 12 (xdm) ............IN DG ("DG3")
Slot 13 (xdn) ............IN DG ("DG3")
Slot 14 (xdo) ............IN DG ("DG3")

You may also get specific information about any existing disk group.

# dadg -Ldg DG1
Disk-Group Name : DG1
Status : active
Raid status : healthy
Owner controller : 0
Alarm level : 95
Raid Level : 5
Desired number of disks : 5
Actual number of disks : 5
Member disks : xda(0), xdb(1), xdc(2), xdd(3), xde(4)
DG size : 1525248 MB
Allocated size : 0 MB
Free size : 1525248 MB
Comment : Disk Group 1

#5c Create Volumes

Volumes are created from disk groups. Each disk group can host multiple volumes which will be exported to either one single host at a time or – by using an abstraction layer like global filesystem – to multiple hosts at once.

Volumes are maintained by the the davd command. Refer to davd -h for details on the arguments.

# davd -a DG1VOL1 -g DG1 -m 2 -r 0 -s 1525248
DG1VOL1 successfully created and available.

# davd -a DG2VOL1 -g DG2 -m 2 -r 0 -s 1525248
DG2VOL1 successfully created and available.

# davd -a DG3VOL1 -g DG3 -m 2 -r 0 -s 1525248
DG3VOL1 successfully created and available.

# davd -L DG1VOL1 -g DG1
Virtual-Disk Name : DG1VOL1
Type : Data Virtual Disk
Date/Time Created : Mon Jul  2 15:45:43 2007
Operational State : Available
Disk Group : DG1
Cache Policy : Write Back
Read Ahead Policy : Enabled
Capacity : 1525248 MB

#5d Add Initators

To allow any arbitary host to connect it must be added to the Provigo initiator list.

Again in client-server terms, the initator refers to the client connecting the the target (server).

The dahost command servers that purpose and will also allow to use initiator secrets for additional security.
I omitted the latter one for the sake of simplicity.

# dahost -a -w iqn.2004-07.net.phunsites:testhost -n testhost.phunsites.net -t "Test Host for iSCSI" -b 0 -o 1

#5e Export LUNs to Initators

Now that our initiators are known to the system, the Volumes must be exported to the iniators.
For that purpose the dalun is used, which will assign a LUN (logical unit numbers) for each volume.

# dalun -a -n testhost.phunsites.net -g DG1 -k DG1VOL1
# dalun -a -n testhost.phunsites.net -g DG2 -k DG1VOL1
# dalun -a -n testhost.phunsites.net -g DG3 -k DG1VOL1

#6 Configure Networking

The Provigo manual points out multiple possibilities on network connections which include variants of channel bonding and different MTU sizes.

These may or may affect the effective transfer rate for all frames, however this depends heavily on the usage of the iSCSI resource and how the data looks like (e.g. many small file transfers or less big file transfers).

If you want to use jumbo frames (MTU 9000) you will need to alter your /etc/sysconfig/network-scripts/ifcfg-ethX file. Add an MTU statement to set the value for the new MTU size.

# Intel Corporation 82546GB Gigabit Ethernet Controller
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPADDR=192.0.2.21
NETMASK=255.255.255.0
MTU=9000

If you want to try your luck with channel bonding, add this to /etc/modprobe.conf:

alias bond0 bonding
options bond0 mode=1 miimon=100

This will enable active-backup mode, which usually works best.
Refer also to README.bonding, which should be somewehre on your systems, for other bonding modes.

If your bonding devices includes eth2, your network configuration should read like this for /etc/sysconfig/network-scripts/ifcfg-eth2:

DEVICE=eth2
ONBOOT=yes
HWADDR=00:07:e9:1f:bc:08
USERCTL=no
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

And for /etc/sysconfig/network-scripts/ifcfg-eth3 eventually:

DEVICE=eth3
ONBOOT=yes
HWADDR=00:07:e9:1f:bc:09
USERCTL=no
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

The network configuration goes to /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPADDR=192.0.2.21
NETMASK=255.255.255.0

Again you may include the MTU=9000 option to enable jumbo frames.

To bring up the bonding interface manually use this for example:

# modprobe bonding mode=1
# ifconfig bond0 192.0.2.21 netmask 255.255.255.0 mtu 9000
# ifenslave bond0 eth2
# ifenslave bond0 eth3

#7 Configure iSCSI Initiator

Now the frontend host needs to be configured.
First of all installation of an iSCSI initiator software is required.

On RedHat Enterprise Linux 5.0 this can be installed as easy as:

rpm -i iscsi-initiator-utils-6.2.0.742-0.5.el5.x86_64.rpm

or

yum install iscsi-initiator-utils.x86_6

Then make sure the services are enabled properly, but not yet started.

# chkconfig iscsid on
# chkconfig iscsi on
# chkconfig --list iscsid
# chkconfig --list iscsi
# service iscsid stop
# service iscsi stop

Add the initiator name to /etc/iscsi/initatorname.iscsi. This should correspond to the initator name used earlier with the dahost command and also comply to existing host name entries in the dns zone if they also exist.

InitiatorName=iqn.2004-07.net.phunsites:testhost

Then the iscsid daemon may be started at first.

# service iscsid start
Turning off network shutdown. Starting iSCSI daemon:       [  OK  ]

Run a discovery against the iSCSI target’s IP address or hostname.
This should reveal the iSCSI target and bind a persistent connection to it.

# iscsiadm -m discovery -t sendtargets -p 192.0.2.11
192.0.2.11:3260,1234 iqn.2004-07.net.phunsites:san001.0

# iscsiadm -m discovery
192.0.2.11:3260 via sendtargets

# iscsiadm -m node
192.0.2.11:3260,1234 iqn.2004-07.net.phunsites:san001.0

Then the iscsi service may be started:

# service iscsi start
Turning off network shutdown. Starting iSCSI daemon:       [  OK  ]
Setting up iSCSI targets: Login session [192.0.2.11:3260 iqn.2004-07.net.phunsites:san001.0]

If everything went well something like this should arise in the system logs:

# dmesg
scsi1 : iSCSI Initiator over TCP/IP
Vendor: Transtec  Model: PROVIGO1100-SAN0  Rev: 1.00
Type:   Direct-Access                      ANSI SCSI revision: 04
SCSI device sdb: 3123707904 512-byte hdwr sectors (1599338 MB)
sdb: Write Protect is off
sdb: Mode Sense: 17 00 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 3123707904 512-byte hdwr sectors (1599338 MB)
sdb: Write Protect is off
sdb: Mode Sense: 17 00 00 00
SCSI device sdb: drive cache: write back
sdb: unknown partition table
sd 1:0:0:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg3 type 0
Vendor: Transtec  Model: PROVIGO1100-SAN0  Rev: 1.00
Type:   Direct-Access                      ANSI SCSI revision: 04
SCSI device sdc: 3123707904 512-byte hdwr sectors (1599338 MB)
sdc: Write Protect is off
sdc: Mode Sense: 17 00 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 3123707904 512-byte hdwr sectors (1599338 MB)
sdc: Write Protect is off
sdc: Mode Sense: 17 00 00 00
SCSI device sdc: drive cache: write back
sdc: unknown partition table
sd 1:0:0:1: Attached scsi disk sdc
sd 1:0:0:1: Attached scsi generic sg4 type 0
Vendor: Transtec  Model: PROVIGO1100-SAN0  Rev: 1.00
Type:   Direct-Access                      ANSI SCSI revision: 04
SCSI device sdd: 3123707904 512-byte hdwr sectors (1599338 MB)
sdd: Write Protect is off
sdd: Mode Sense: 17 00 00 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 3123707904 512-byte hdwr sectors (1599338 MB)
sdd: Write Protect is off
sdd: Mode Sense: 17 00 00 00
SCSI device sdd: drive cache: write back
sdd: unknown partition table
sd 1:0:0:2: Attached scsi disk sdd
sd 1:0:0:2: Attached scsi generic sg5 type 0

The device should then also be visible in /proc/scsi/scsi:

# cat /proc/scsi/scsi
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: Transtec Model: PROVIGO1100-SAN0 Rev: 1.00
Type:   Direct-Access                    ANSI SCSI revision: 04
Host: scsi1 Channel: 00 Id: 00 Lun: 01
Vendor: Transtec Model: PROVIGO1100-SAN0 Rev: 1.00
Type:   Direct-Access                    ANSI SCSI revision: 04
Host: scsi1 Channel: 00 Id: 00 Lun: 02
Vendor: Transtec Model: PROVIGO1100-SAN0 Rev: 1.00
Type:   Direct-Access                    ANSI SCSI revision: 04

#8 Working With Disks

Now you can work with the disks as if they were locally installed to the system.
They are initialized like any other disk device would be, too:

# fdisk /dev/sdb
# fdisk /dev/sdc
# fdisk /dev/sdd

# mkfs -t ext3 /dev/sdb1
# mkfs -t ext3 /dev/sdc1
# mkfs -t ext3 /dev/sdd1

If you want the iSCSI block devices to be mounted via fstab on startup, the entry should include the _netdev keyword.
This will ensure that the network is available before the device is to be mounted.

/dev/sdc1               /mnt/sdc1   ext3    _netdev 0 0

#9 Conclusions

While I’m still hacking up some good benchmark scripts, I can tell for sure that the system performs very well and definitily fits my purpose.
As this is the first iSCSI based device I’ve ever got, implementation and usage is very simple and works reliable.

I’m in doubt however wether an iSCSI device is good enough when it comes to high-load scenarios where every bit of I/O counts.
This is definitely one thing I want to test out in-depth during the next weeks.

Despite still in evaluation, this review has already left its markings on the wall.
There were some odd’s and evens which I came along and as such are to be mentioned here.

First, and already mentioned earlier, is the fact why I didn’t get a power cable with a swiss power plug.
It _may_ actually sound pedantic, but when ordering anything from a vendor in Switzerland I do expect to receive to correct equipment.

My second thoughts care about the documentation.
I must admit that the guys at Transtec did a very good job in writing the handbook. It is very detailed and covers almost everything one needs to know.
It lacks however a step-by-step description how setup is done via the serial console.
While all commands are properly documented, one get’s no idea whatsoever in which order they must be run.
It’s a matter of puzzling it together by logical evaluation and a bit of trial and error.
One might argue that the docs cover step-by-step configuration for the web management interface. Acknowledged. This exists and is indeed very detailed and to the point.
But still, I know a lot of poeple who don’t trust in web interfaces (me included). Providing a little check list would be sufficient enough but still of great help to get things done faster.

The third thing noted is the inconsequent usage of command line arguments within the CLI.
This can be seen for example when it comes to reviewing settings.

dadg -Lall (List)
dahost -l (list)
dalun -p (print)
daroute (nothing required at all to 'list')

As the da* commands are clearly part of the Provigo firmware, I can’t follow the reason why the all have different syntax.
It would be more straight-forward if they’d follow a common guideline and define the same arguments for particular functions to be identical accross all utilities.

To make things even worse in the current implementation, there exist also variations which require the admin to _know_ in advance what he is querying for. An example of this:

davd -L DG1VOL1 -g DG1

davd is unable to show all defined volumes at once, there’s simply no option for this. So I _must_ know the exact names of my volumes. But where do I get them from if I happen to forget the volume names one day?

Also the error reporting could be better or clearer.
What would this error message mean:

# dalun -a -n hostXYZ -g DG1 -k DG1VOL1
Host not found

Host not found. Errr… First thing coming into my mind: host not found. Where? In DNS. In /etc/hosts? Where!?
Making the error message say something like ‘Please add Host “HostXYZ” with “dahost” command first’ would make things much more obvious.

Fourth thing to note is protocol support in Provigo.
It supports beneath http protocol also the serial console for management and … telnet.
Huh!? telnet? Telnet to be used for management purpose looks like an ancient dinosaur to me!? Guys, we have 2007!
Even if an iSCSI-based storage network is supposed to be separated from public networks and therefore be closed down, using telnet for remote management is neither state-of-the-art nor secure.
I see no reason why Provigo could not support SSH. It has plenty of RAM, a decent CPU. Also the base OS image, which is build on some Linux, is around ~52 MiB with ~48 MiB free space, so room enough to include the SSH daemon. Why don’t you do so?

A fifth thing sawn was a bug in dastat command:

Name:                                  SAN001-0
Controller Slot#:                      0
Remote Controller:                     Not Installed
Operational State:                     Active/-
Total Capacity:                        4468.50 GB
Time:                                  Mon Jul  2 16:45:33 UTC+2 2007
Kernel Version (local):                K:2.7.155-20061114
CPLD Board Midplane Rev (local):       C:7 B:A04 M:2
BIOS Version (local):                  RN2_0110 05/23/06
/usr/sbin/dastat: [: !=: unary operator expected
Fibre Channel WWN:

Drive    View from controller 0    View from controller 1
Slot 0 (xda) ............IN DG ("DG1")
Slot 1 (xdb) ............IN DG ("DG1")
Slot 2 (xdc) ............IN DG ("DG1")
Slot 3 (xdd) ............IN DG ("DG1")
Slot 4 (xde) ............IN DG ("DG1")
Slot 5 (xdf) ............IN DG ("DG2")
Slot 6 (xdg) ............IN DG ("DG2")
Slot 7 (xdh) ............IN DG ("DG2")
Slot 8 (xdi) ............IN DG ("DG2")
Slot 9 (xdj) ............IN DG ("DG2")
Slot 10 (xdk) ............IN DG ("DG3")
Slot 11 (xdl) ............IN DG ("DG3")
Slot 12 (xdm) ............IN DG ("DG3")
Slot 13 (xdn) ............IN DG ("DG3")
Slot 14 (xdo) ............IN DG ("DG3")

No System Health Alert

Messages like [: !=: unary operator expected look definitely not good, especially when it's simply a matter of proper shell scripting syntax.
When looking at /usr/bin/dastat there is this line:

if [ $multiple_target != "yes" ]

Changing it as follows removes the error message:

if [ "$multiple_target" != "yes" ]

Despite these things, which could be regarded as minor glitches, I must admit that the Provigo 410E does an excellent job for a decent price.
Given it’s modular design it’s scalable and can fit multiple scenarios from single iSCSI environments up to mixed iSCSI and FC environments.

As mentioned before I’m doing some benchmarking currently, which I hope to reveal some interesting information in terms of throughput and I/O performance.

Bad enough that Adaptec Storage Manager (ASM) included with the Supermicro driver disk does not include a CLI.
Let’s not argue about whom had the great idea to provide a GUI-only java-based management application to be used on 19″ 1U rackmount servers.
Of course I’d never run such a server headless or without X11 installed so why would I ever need a CLI!?

At least they make it up by supplying a newer version of ASM which includes a CLI.
It’s only a shame that it’s hidden away on their ftp server within the driver disk of another disk controller, making it somewhat an adventure to find it eventually…

Look for the AOC-LPZCR1/AOC-SOZCR1 driver to get the x86 or x86_64 linux version of ASM.

Install ASM CLI

As I only need the ASM CLI without the java GUI stuff et all, the following will describe how to do it.

This command will download the x86 package and extract the “arcconf” binary.
When asked to “rename ./usr/StorMan/arcconf” simply provide the new location where it is to be stored, e.g. /usr/sbin/arcconf.
Replace the “ftp://url/to/rpmfile” stanza by the actual url.

# lynx -dump ftp://url/to/rpmfile | rpm2cpio - | cpio -ivmur '*arcconf'
rename ./usr/StorMan/arcconf -> /usr/sbin/arcconf

Afterwards the extracted binary needs to be assigned execute permissions:

# chmod 700 /usr/sbin/arcconf

Now since the binary is dynamically linked a check for eventually missing libraries is required:

# ldd /usr/sbin/arcconf
linux-gate.so.1 => (0xffffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7fdd000)
libdl.so.2 => /lib/libdl.so.2 (0xf7fd9000)
libstdc++-libc6.2-2.so.3 => not found
libm.so.6 => /lib/libm.so.6 (0xf7f6f000)
libc.so.6 => /lib/libc.so.6 (0x00afb000)
/lib/ld-linux.so.2 (0x00ade000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7f62000)

More recent distros, RHEL 5 in may case, usually require compatibility libraries to be installed.

Depending on your distro YMMV.
On RHEL, and other rpm-based distros with YUM support, missing libraries may be located like this:

# yum whatprovides libstdc++-libc6.2-2.so.3
Loading "rhnplugin" plugin
Loading "installonlyn" plugin
This system is not registered with RHN.
RHN support will be disabled.
Setting up repositories
Reading repository metadata in from local files

compat-libstdc++-296.i386                2.96-138
rhel-base
Matched from:
libstdc++-libc6.2-2.so.3

Finally the package named in yum is to be installed accordingly:

yum install compat-libstdc++-296.i386

So after getting arround these hurdles the CLI is ready to go.

To change this behaviour, two values need to be changed in OpenBoot.

So first we need to enter OpenBoot by sending a Break over the serial line or STOP-A.

Examine the environment values like this and look out for the variables called ‘input-device’ and ‘output-device’:

# printenv
Variable Name Value Default Value
[output omitted]
output-device screen screen
input-device keyboard keyboard
[output omitted]

Set them as follows to enable the serial console to be used by default:

#setenv output-device virtual-console
#setenv input-device virtual-console

Next time the machine is powered on, the serial console should come up at once.