running virtualbox 4 on a synology iscsi device

quick notes to get vms running on iscsi luns.

1) create a lun on the synology. give it a reasonable name. (see left image)

2) create an iscsi target for it, with a sensible iqn. (see right image)

NOTE: the naming is what works for me. iqn is mostly RFC3721 compliant with exception of the date: I set the date to the general ballpark of when I created the iscsi target. Not when I created my first antoonhuiskens.com domain.

3) I really should set up lun masking.

Though the manual state that virtualbox runs its own initiator, this didn't sink in until I set masking up: I initially mapped the iscsi lun to the microsoft iscsi initiator, but that doesnt work, since the iqn of the vbox adapter is different.

a brief snoop (with wireshark) showed that the iqn is:

iqn.2009-08.com.sun.virtualbox.initiator:01:

as an example: iqn.2009-08.com.sun.virtualbox.initiator:01:192.168.1.104

I expect that the "01" in the iqn serves a function as well, but we'll find that out later I suppose.

4) create the vm on the host.

Needs to be done commandline:

vboxmanage is to be found in:

\program files\oracle\virtualbox

vboxmanage createvm --name dc-utr-01-vmtest --ostype WindowsXP --register

I found that its convenient to register immediately. This means from now on, the vm shows up with "vboxmanage list vms" and also in the gui.

I set the ostype to win xp for no other reason than hoping (yes, hoping) it would set me up with some sensible defaults.

5) add a disk controller to the vm. Choose wisely I'd say. after all ide means only a master and a slave device. scsi, sas etc do not suffer from these limitations. For now, I dont care enough.

vboxmanage storagectl dc-utr01-vmtest --name controller0 --ide

6) attach a port on the controller of the vm to the virtual machine:

vboxmanage storageattach dc-utr01-vmtest \

--storagectl controller0 # as created in step 5

--port 0

--device 0 # Not sure. it works though. prolly related to how I setup the controller in step 5.

--type hdd # goes without saying

--medium iscsi

--server 192.168.1.10

--target iqn.2011-03-com.antoonhuiskens:VBOX-LUNS.dc-utr01-vmtest

Now all you need to do is fumble through the settings in the gui to see if you missed some sensible defaults (video memory for instance is one).

zfs dedup helps me more than I expected...

reading the FAST10 proceedings article on deduplication

$ zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c6t0d0s0 ONLINE 0 0 0

errors: No known data errors
$ zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
rpool 232G 99.6G 132G 42% 1.43x ONLINE -

Dedup helps out more than I expected for just a simple laptop running build 133: I try to keep my folders as clean as time permits...

how web 2.0 is opensolaris anyways?

Over the years I've come to love and loathe the web, it's technologies and it's chaos. As with any evolving (in the darwinian sense) technology, there'll always be situation where your desktop environment just not (yet) provides what is needed to consume the leaves of a particular technology (no I'm not a vegetarian).

So what does actually work for me with my mostly standard opensolaris install from the point of view that I'm mostly a consumer of opensolaris?

browsing: firefox 3.5.7 works great. however, firefox is delivered with the OS distribution. Not much of a problem since I suck up the bits from the /dev repository, but still out of sync: What if a critical vulnerability arose in firefox? I'd be stuck waiting for new bits from /dev, which come about every two weeks, but that would put my window of vulnerability at a worst case of two weeks. Ideally, the mozilla foundation would host a pkg server which would allow you to suck up their freshest bits. setting up a pkg mirror is increadibly easy, I doubt they'd have a hard time dealing with the added load. (besides, how much opensolaris clients are out there anyway?).

On a separate thought, If I were to run a pkg server for my own domain with the intent of providing rapid, repeatable installs and updates from various sources, how would I infact provide a single pkg-space comprising several components with components from different sites? Worth looking into.

Generally, the browsing experience is very nice (I can do my work). With flash and java most of my needs are covered. I am very very content with these plugins: it was a long wait, but boy was it worth it. Truth is, I do occasionally run into silverlight components (haven't seen adobe air in fact!) I expect javafx to "just work" actually. In fact just hopping over to jjavafx shows it just works. Video plugins are pretty decently covered by totem, especially if you get some more of those gstreamer-plugins from say fluendo.

Coming back to the point I made earlier: fluendo provides for it's own update mechanism: codeina. Honestly: that ticks me off: I would say it should be a given that the update and install mechanisms should be mostly the same. Any deviation from that is in my opinion a significant barrier to enter. Let's look at the example of the pkg.sun.com/extra repository... For every user, issue a certificate. Expire the certificate once the license policy agreement expires (which is what fluendo seems to do for their free plugin) and Bob's your uncle. No new registration: no more updates. Then again: how would you provide for a "shop" like model where the certificates determine what you can see/download? (As is the case with fluendo and their paid for plugins which give added value on top of the free ones they provide?).

Other plugins which make my life on the web much more bearable: ad block plus, noscript. Good that they stopped pestering each other as well. They just work on opensolaris.

A thing about developing technology in the web 2.0 arena that greatly bothers me is the clash of the various titans in this space: the facebooks, flickr's, google's all add value to the internet for me. However, it seems as if they are hell bent on keeping the other ones out. Mining the user seems to quickly turn to be the priceless commodity (or fool's gold?) they are all after: you don't pay for the service you get, but the costs of running the service are (more than) covered by the knowledge about yourself that you surrender. Make no mistake: your identity or parts of it are monetised and sold off to the highest bidder. The obvious monetization here is targeted advertisement, which is what made google big, but there's more contenders: for a startup, getting to an IPO is a worthy goal in itself (as proven a few years ago now by google)

Google especially seems like a sink/magnet/strange attractor: Lot's of stuff goes in: my blog, my analytics, my rss reading, my mail, but none seems to come out at least not very easily. Ok fair: the degree of openness to the end user at google's products is not so bad compared to others: I read my mail locally via imap (thunderbird). Last time I checked hotmail didn't (but that was a long time ago). I managed to get my google calendar out as well, but do needed to digg around to find the appropriate plugin. There's more stuff that you can get out, but don't tell me it's easy let alone guaranteed.Bottom line: you're lucky if you get your data out, but you'll usually have to have a fair bit of knowledge of the underlying technology.

Come to this: what I like very much are tools who tie it all together: pidgin excels at joining my various identities together: I've got facebook, msn, google chat, company im, and a few more all tied into one neat little interface that behaves by and large the same for each and every protocol. Fantastic: If I were to nominate folks for the nobel prize... (only slightly kidding). Other tools which provide this kind of glue between the various services out there: drivel. gtg. thunderbird. openoffice. And a much overlooked feature of gnome: the clock: providing time, weather for various places around the globe. Haven't seen such a simple solution coming from microsoft or apple. The clock widget on os X does mostly the same, but seriously, I don't need all those bells and whistles, let alone the screen real estate it would consume for three or four clocks with a weather forecast to it. I just want tools that work, do their thing and don't get in the way of me being productive.Various chat protocols exist: facebook had (it changed a few weeks ago) a private chat protocol: they changed: thank you very much. No more hassling to dig up and build the purple plugin which enables facebook chat in pidgin. Kudos to the guys who wrote the plugin: admirable job, but reality is that you always played catch up. (Still goes for msn though).

So what then am I missing? proper support for my ATI Radeon. Not being able to run compiz is a major gripe. My point of view: intel gets it. NVidia gets it. AMD doesn't. Intel's worked hard to align with major opensource projects and I feel it's only fair to say that this will (in my opinion) pay out: support for their latest and greatest cpus: it's already in opensolaris (and I would presume in linux), and not only just the "getting things running" good enough kind of stuff: nope: their work on opensolaris made sure that a lot of the distinguishing features of their cpus are working. To a lesser extent this applies to NVidia as well, obviously with a lot smaller scope. AMD? They insist on chucking a binary over the fence every now and then for linux if you want more than the absolute basic functionality which you can find in the open source driver. It's closed. It won't help you. Rest assured, I'm not inclined to get an AMD graphics card or anything that has AMD in it (think laptop). Not now, not in the near future. It's as simple as that.

Another thing is mono and the development stuff around it (gtk-sharp etc) and quite a set of nice applications like F-spot, tomboy etc which are applications which fill a hole. Posting to flickr is a pain at the moment. gnome-sticky notes are ok, but no match for tomboy. And what about moonlight as an open source silverlight plugin? Honestly, I share the concerns about the entanglement between novell and microsoft and possible consequences if microsoft decided to pull the plug in some form or another (I strongly believe they can, not so sure if they would truly dare to do so). Also the thought of having mono as a first (or even second) class citizen in solaris would make my life a lot easier. I'm happy to run the risk of having to part with the applications running on mono when the time comes. yikes.bitter after all;-)

Darn. spotted.

I had hoped noone would actually read this garbage collection of random errors, mistakes and blatant exhibition of missing knowledge.

pidgin facebook plugin for opensolaris: make way for xmpp support at facebook!

I only recently noticed that the facebook plugin for opensolaris in the /contrib repository stopped working. A little digging:

$ pkg info pidgin-facebookchat
Unable to locate key '/export/home/ah115678/Downloads/OpenSolaris_extras.key.pem' for publisher 'extra.sun.com' needed to access 'https://pkg.sun.com/opensolaris/extra/'.
Unable to locate certificate '/export/home/ah115678/Downloads/OpenSolaris_extras.certificate.pem' for publisher 'extra.sun.com' needed to access 'https://pkg.sun.com/opensolaris/extra/'.
Name: pidgin-facebookchat
Summary: Facebook chat support for Pidgin
Description: Facebook chat support for Pidgin
Category: Applications/Internet
State: Installed
Publisher: contrib.opensolaris.org
Version: 1.50
Build Release: 5.11
Branch: 0.101
Packaging Date: April 30, 2009 06:41:16 PM
Size: 94.57 kB
FMRI: pkg://contrib.opensolaris.org/pidgin-facebookchat@1.50,5.11-0.101:20090430T184116Z

so version 1.50. That might explain why... The most current version is 1.64.
I tracked down the creator of the original 1.50 package via the source juicer an contacted him to let him know. Good news: he's working on it!

Additionally, I found that facebook moved to xmpp/jabber protocol, so it's no longer needed to have a dedicated plugin...

wonderful solution I'd say

gtg and hamster

On another note. hamster (from the opensolaris.org repository) and gtg work like a charm together! All you need to do is activate the co-delivered plugin in gtg's preferences... and off you go.

getting thing gnome for opensolaris

I've had my mind set on a task manager for gnome for sometime already. GTG seems like a nice quick and dirty tool which doesn't get in the way of actually getting things done. Getting it to actually work was another. Turns out this is rediculously simple:

Apart from python 2.6 there's just 1 single dependency: configObj.

To install: download (I chose the zip file).

unzip, modify the setup.py to have as a first line:
#!/usr/bin/env python

then
$ pfexec ./setup.py install

done.

For gtg: download
gzcat gtg* |tar xvf -
cd gtg...

$ pfexec ./setup.py install

All done.

Installs into /usr/bin

so
$ gtg

and on your way!

building enblend: another step closer to hugin?

Don't know why I just don't give up. I *need* to get my photo stuff into hugin I suppose.

So, having a go at building enblend; yet another dependency for hugin.

Downloaded and

#./configure
[..]
configure: error: libxmi is required to compile enblend.

so. Download libxmi and see what that brings us:
#./configure
# make
# make install

And works! Kudos to the developers of both libxmi and opensolaris... clean, portable code and a build environment that's starting to make sense of linux stuff!

Another go at building enblend (with LDFLAGS=-L /usr/local/lib) now fails for sake of boost headers missing. Which is not too bad doing this now, as hugin lists it as a requirement as well.

Let's have a go at those.

# ./configure
passed!

# make

[ ... quite a few errors relating to python stuff, but I'll leave it at that for now; just hoping python isn't used down the road ...]
#make install
works as well!

update 30/03: Managed to get ./configure to complete. However, make struggles. I filed an incident report at the good soureforge-folks of the project team:

See http://solaristerror.blogspot.com/2009/01/pidgin-facebook-plugins-and-opensolaris.html for details.

adhoc wireless, dhcp-serving and nat'ing with opensolaris

Lately, I've been in spots with multiple laptops and only wired-internet.

Time to fix that I'd say and take control: create a wireless ad-hoc network, with my laptop as the initiator and have the other laptops connect through me.

creating a wireless ad-hoc network is remarkably simple:

in preparation, I first disabled nwam (as my usual mode of operation)

#svcadm disable nwam
#svcadm enable physical:default

Create an ad-hoc wireless network with SSID "twitternet" (check first that the SSID doesn't exist yet):

# dladm connect-wifi -e twitternet -c -b ibss iwk0

Next plumb the TCP/IP part of it.

Not needed yet, but useful for DHCP is to add an entry for 192.168.0.0 to /etc/inet/netmasks.

# ifconfig iwk0 plumb
# ifconfig iwk0 192.168.0.1 netmask + broadcast + up

So, now an adhoc wireless network has been created.

In order to setup a DHCP server and provide some automated network services for generic clients:

Ok, I "cheated", and used the GUI to do the initial configuration of the macros etcetera: /usr/sadm/admin/bin/dhcpmgr. You should be able to achieve the same with:

# dhcpconfig -D -r SUNWfiles -p /var/dhcp -h files

dhcpconfig/dhcpmgr will setup with an ascii-file database in /var/dhcp and update /etc/hosts with the names. It'll also create some macros with as much stuff as it can find out about your network. (check the man page for dhcpconfig; it has a nice table).

With the dhcpmgr GUI, create a network (192.168.0.0 in my case) and set it up to your liking (no-nonse config, I just assigned a static router: 192.168.0.1 and in the end the network macro. I'll look into using RIP another time).

This can ofcourse also be done with pntadm.

As the network macro did not include the external DNS server, and I have not setup my laptop to run one, I checked the localhost macro, and noticed that it nicely implemented the DnsDomain and DnsServer options, pre-populated with the entries from /etc/resolv.conf. (that's why it was useful to put an entry into /etc/inet/netmasks) Nice!

As however the 192.168.0.0 network had the 192.168.0.0 macro assigned to it, the clients would not pick up the DnS* options. I opened the properties for the 192.168.0.0 macro and added a field "Include" with value "localhost"; Now the localhost macro is also provided to the clients!

All done with dhcp-server configuration (a 2 minute job really)

In order to prevent the dhcp-server from resonding to DHCP requests on all interfaces, I added a line to /etc/inet/dhcpsvc.conf:

INTERFACES=iwk0

As a final check:

1) is the wireless adhoc bit setup?
# dladm show-wifi
LINK STATUS ESSID SEC STRENGTH MODE SPEED
iwk0 connected twitternet none good b 54Mb
#

is iwk0 up and does the ipaddress match the router-ipaddress you're handing out?

# ifconfig iwk0
iwk0: flags=201100843 mtu 1500 index 2
inet 192.168.0.1 netmask ffffff00 broadcast 192.168.0.255
ether 0:1d:e0:19:e9:25
#

# dhtadm -P
Name Type Value
==================================================
192.168.0.0 Macro :Subnet=255.255.255.0:Router=192.168.0.1:Broadcst=192.168.0.255:Include=localhost:
localhost Macro :Include=Locale:Timeserv=127.0.0.1:LeaseTim=86400:LeaseNeg:DNSdmain="local":DNSserv=XX.YY.40.25 XX.YY.35.25:
Locale Macro :UTCoffst=3600:
#

next connect the network cable to my wired-network port and

# ifconfig e1000g0 dhcp start
# ifconfig e1000g0
e1000g0: flags=201104843 mtu 1500 index 3
inet XX.YY.27.76 netmask fffff800 broadcast XX.YY.31.255
ether 0:a0:d1:a2:f1:e3


Almost done!

run routeadm and make sure ipv4 routing and forwarwarding are enabled. (Usually, forwarding is disabled. enable with "routeadm -e ipv4-forwarding ; routeadm -u" where needed.

One more last hurdle: you'll need NAT on your wired port to have the clients utilise the single ip-address you've been given:

enable ipfilter (in a blank configuration like mine, ipfilter requires the network/physical:default service, so that's why it needs to be enabled).

# svcadm enable ipfilter

Check that you don't have any NAT mappings yet:
# ipnat -l
and if needed: clean them out with:
# ipnat -C ; ipnat -F

Next, setup a nat mapping:
# echo "map e1000g0 192.168.0.0/24 -> 0.0.0.0/32" | ipnat -f -

Enable the dhcp server:
# svcadm enable dhcp-server

do a final check:
# svcs -x

If everything's running (i.e. ipfilter, dhcp-server mainly) you should be ready to serve the rest of the room.

Ofcourse, you'll need additional (reverse) port mappings if your clients would like to perform server tasks, but that's beyond this scope (besides, my clients sofar were pretty bog standard windows users and laptops, so no fancy stuff needed).

building mono 2.2 from scratch on opensolaris

Ah the sweet taste of succes makes me long for more...

I had another look at hugin and remembered I'd need mono to get hugin (or one of it's dependencies) to work on my opensolaris laptop.

So once more I venture into the trenches and downloaded the mono sources.

I left my symlinks to ac_local and automake from a previous exercise in place, promoted /usr/sfw/bin to be the first in the $PATH, symlinked /usr/sfw/bin/ggrep to /usr/sfw/bin/grep to fix an initial grep error in a first pass of ./configure and:

#./configure passed!
I did see some grep errors, and with assuming that ggrep would fix that, I symlinked grep to grep in /usr/sfw/bin.

# make
crashed and burned with errors complaining about dtrace:

make[3]: Entering directory `/root/mono-2.2/mono/utils'
/usr/sbin/dtrace -32 -s ../../data/mono.d -o mono-dtrace.h
dtrace: script '../../data/mono.d' matched 0 probes
dtrace: no probes matched
make[3]: *** [mono-dtrace.h] Error 1
make[3]: Leaving directory `/root/mono-2.2/mono/utils'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/mono-2.2/mono'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/mono-2.2'
make: *** [all] Error 2

#./configure --enable-dtrace=true
fixed that!

(reading the ./configure --help I realise i should've used --enable-dtrace=yes, so I'm assuming dtrace support isn't enabled...)

I symlinked /usr/sfw/bin/gmake to /usr/sfw/bin/make and

# make
crashed on some u_int32_t errors:

googleing for this I found a solution: replace u_int32_t with uint32_t and try again. Seems most of them were ironed out before, except for three entries in

In file included from ../../mono/utils/freebsd-elf32.h:32,
from aot-compiler.c:67:
../../mono/utils/freebsd-elf_common.h:46: error: syntax error before "u_int32_t"
../../mono/utils/freebsd-elf_common.h:46: warning: no semicolon at end of struct or union
../../mono/utils/freebsd-elf_common.h:47: warning: type defaults to `int' in declaration of `n_descsz'
../../mono/utils/freebsd-elf_common.h:47: warning: data definition has no type or storage class
../../mono/utils/freebsd-elf_common.h:48: error: syntax error before "n_type"
../../mono/utils/freebsd-elf_common.h:48: warning: type defaults to `int' in declaration of `n_type'
../../mono/utils/freebsd-elf_common.h:48: warning: data definition has no type or storage class
../../mono/utils/freebsd-elf_common.h:49: warning: type defaults to `int' in declaration of `Elf_Note'
../../mono/utils/freebsd-elf_common.h:49: warning: data definition has no type or storage class
In file included from aot-compiler.c:67:
../../mono/utils/freebsd-elf32.h:144: error: syntax error before "Elf32_Nhdr"
../../mono/utils/freebsd-elf32.h:144: warning: type defaults to `int' in declaration of `Elf32_Nhdr'
../../mono/utils/freebsd-elf32.h:144: warning: data definition has no type or storage class
In file included from aot-compiler.c:68:
../../mono/utils/freebsd-elf64.h:162: error: syntax error before "Elf64_Nhdr"
../../mono/utils/freebsd-elf64.h:162: warning: type defaults to `int' in declaration of `Elf64_Nhdr'
../../mono/utils/freebsd-elf64.h:162: warning: data definition has no type or storage class
make[4]: *** [aot-compiler.lo] Error 1
make[4]: Leaving directory `/root/mono-2.2/mono/mini'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/root/mono-2.2/mono/mini'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/mono-2.2/mono'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/mono-2.2'
make: *** [all] Error 2

fixed that by changing the u_int32_t's to uint32_t's. and

# make
again.

now:
if test -w ../mcs; then :; else chmod -R +w ../mcs; fi
cd ../mcs && make NO_DIR_CHECK=1 PROFILES='net_1_1 net_2_0 net_3_5 net_2_1' CC='gcc' all-profiles
make[3]: Entering directory `/root/mono-2.2/mcs'
make profile-do--net_1_1--all profile-do--net_2_0--all profile-do--net_3_5--all profile-do--net_2_1--all
make[4]: Entering directory `/root/mono-2.2/mcs'
make PROFILE=basic all
make[5]: Entering directory `/root/mono-2.2/mcs'
usage: mcs [-cdpVz] [-a string] [-n name] file ...
make[6]: *** [build/deps/basic-profile-check.exe] Error 1
make[6]: Entering directory `/root/mono-2.2/mcs'
*** The compiler 'mcs' doesn't appear to be usable.
*** Trying the 'monolite' directory.
make[7]: Entering directory `/root/mono-2.2/mcs'
build/deps/basic-profile-check.cs(1,1): error CS8025: Parsing error
make[8]: *** [build/deps/basic-profile-check.exe] Error 1
make[8]: Entering directory `/root/mono-2.2/mcs'
*** The contents of your 'monolite' directory may be out-of-date

Ouch. What's that! Checking the readme.. it suggests that I'll have to run "make get-monolite-latest" (make sure gtar is found as tar in your $PATH and move solaris' mcs out of the way),
# make EXTERNAL_MCS=false

This works! (Ok, As I've been poking around a lot with getting this to work, I also installed the monolite-latest libs in /usr/local/lib/mono/1.0, so if the above doesn't work... Install em there).

I've also found that when make or ./configure fails, errors are seldomly reproducible even after make clean. I tend to rm -rf the dir and tar xvf again. This holds true for most of the stuff I build anyways.

anyways.

# make check runs fine as well:

339 test(s) passed. 3 test(s) did not pass.

Failed tests:

appdomain-unload.exe
thunks.exe
bug-459094.exe

Well. That does seem ok for now.

jUploadr for opensolaris

Sometimes (most of the times) using the standard web upload forms of flickr just won't do. Having worked before with jUploadr, I decided to give it another on my pretty recent install of nevada build 105.

There were a couple of odd tricks I had to perform to get it to work though as documented in Michal Pryc's blog. Still it strikes me as odd to have to replace a couple of libraries to get what essentially seems to be a java application to work, but I guess that's the nature of eclipse.

Be it as it is, jUploadr works like a charm!

dvd ripping for opensolaris with jRipper (I wish)

I more and more need the capability of being able to rip dvds (specifically the audio tracks). It's absolutely wonderful listening to some of those excellent live performances recorded on dvd.

In case you're wondering, my favorites have been cosi fan tutte and now since today diana krall's "live in paris" dvd dropped on my doormat. Unfortunately, I've got no video in my car and besides, it'd distract me from driving anyways...

remembering my positive experience with jUploadr as documented in a previous post, I found a tool which looks promising: jRipper. That page nicely lists (hopefully) a complete set of dependencies:

• cdda2wav
• lame
• oggenc/oggdec
• flac
• faac/faad

Seems I've got my work cut out for me. The times I haven't been lucky have been plenty...

Starting with cdda2wav...

# grep cdda2wav /var/sadm/install/contents
/usr/bin/cdda2wav f none 0555 root bin 997 18657 1228815120 SUNWmkcd
/usr/bin/cdda2wav.bin f none 0555 root bin 282732 54898 1228963666 SUNWmkcd
/usr/share/man/man1/cdda2wav.1 f none 0444 root bin 35235 53199 1228815116 SUNWsfman

Now that looks promising! Just as a sanity check, let's check if all the tools mentioned by the cdrecord site are included: cdrecord, readcd, cdda2wav, mkisofs, isodebug, isodump, isoinfo, isovfy, rscsi are mentioned.

# gawk '/SUNWmkcd/{print $1}' /var/sadm/install/contents /etc /etc/security /etc/security/exec_attr /usr /usr/bin /usr/bin/cdda2wav /usr/bin/cdda2wav.bin /usr/bin/cdrecord /usr/bin/cdrecord.bin /usr/bin/mkisofs /usr/bin/readcd /usr/bin/readcd.bin

Hmm. Well at least some of the tools are included. Where are the iso* tools though? Grep'ing /var/sadm/install/contents suggests they are not present. I'll leave it at this for now, as jRipper suggests it's only using cdda2wav.

Next: lame.
Digging through the contents-file again, I couldn't establish any presence of lame. So, first of the nastier (well. they may be) steps...

Download, and as per the suggestions in the INSTALL file:

# export CC=/usr/sfw/bin/gcc
# ./configure
# make
# make install

Seems to do the trick! (I'll need to look into optimising with a few CFLAGS later...)

To quickly test lame is actually functional, a few quick sanity tests:

# file `which lame`
/usr/local/bin/lame: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

So dynamically linked. Thus let's check if it can find it's libraries:

# ldd `which lame`
libcurses.so.1 => /lib/libcurses.so.1
libm.so.2 => /lib/libm.so.2
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1

Seems allright. Should I worry that none of the libs installed by lame in /usr/local/lib are used?

Let's go for a quick field test...

By default, there's a few .wav files in /opt/staroffice8/share/gallery/sounds/ I found:

# cd /opt/staroffice8/share/gallery/sounds/
# ls
apert.wav space3.wav theetone.wav untie.wav
[... output omitted ...]
# lame apert.wav apert.mp3
LAME 3.98.2 32bits (http://www.mp3dev.org/) Using polyphase lowpass filter, transition band: 8269 Hz - 8535 Hz Encoding apert.wav to apert.mp3 Encoding as 22.05 kHz single-ch MPEG-2 Layer III (11x) 32 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA 45/45 (100%)| 0:00/ 0:00| 0:00/ 0:00 | 29.388x | 0:00 ----------------------------------------------------------- kbps mono % long switch short % 32.0 100.0 93.3 4.4 2.2 ReplayGain: -11.5dB #

Works! Even playing the mp3 produces something sensible.


Next on the list: the ogg-vorbis stuff. Last time I checked, rhythmbox (installed by default) extracted a few cd's to .oga, so I'd say, the ogg-vorbis support would be included as well...

Digging through (again) /var/sadm/install/contents:

# grep SUNWogg-vorbis /var/sadm/install/contents | ...
[ ... output omitted ... ]
/usr/lib/libogg.so.0.5.3 f none 0755 root bin 21004 63931 1228487831 SUNWogg-vorbis /usr/lib/libvorbis.so.0.4.0 f none 0755 root bin 213708 28878 1228487831 SUNWogg-vorbis /usr/lib/libvorbisenc.so.2.0.3 f none 0755 root bin 1120516 56353 1228487831 SUNWogg-vorbis /usr/lib/libvorbisfile.so.3.2.0 f none 0755 root bin 33668 22505 1228487832 SUNWogg-vorbis [ ... output omitted ...] #

So that looks solid as well.

Onto flac then:

# grep SUNWflac$ /var/sadm/install/contents | grep " f "
[ ... output omitted ... ]
/usr/lib/amd64/libFLAC.so.8.2.0 f none 0755 root bin 366336 38583 1228468418 SUNWflac /usr/lib/libFLAC.so.8.2.0 f none 0755 root bin 261492 22875 1228468419 SUNWflac
[ ... output omitted ... ]

So flac's installed as well! (Geez. going pretty well I'd say!)

Last of the dep's (I hope): faac/faad.

# grep faac /var/sadm/install/contents
# grep faad /var/sadm/install/contents
# find /usr/local -name \*faa\*
#

No such luck.
So. download faad and faac.

# unzip faad2-2.7.zip 2>&1 >/dev/null
# cd faad2-2.7
# cat README.linux
To compile under Linux.
----------------------
just run : ./configure --with-mp4v2
make
sudo make install

about the xmms plugin.
---------------------
The xmms plugin need to be build after the install of the faad project. so after you have installed correctly faad (--with-xmms options) you need to configure and build the xmms plugin part in the plugins/xmms directory. Read the README and INSTALL files into the xmms directory.

As per usual, it looks pretty easy. Let's do it then!

# ./configure --with-mp4v2
ksh: ./configure: not found
# ls configure
configure: No such file or directory

No Configure!!?! So that's why they mentioned separate "bootstrapped" downloads. Let's see if I can get it to work anyways...

# ./bootstrap
ksh: ./bootstrap: cannot execute
# ls -l bootstrap
-rw-r--r-- 1 root root 333 Jul 27 2004 bootstrap
# chmod u+x bootstrap # ./bootstrap
ksh: ./bootstrap: not found

Stubborn little program! Vi'ing, I see that the first line has a space where I feel it shouldn't be... Let's correct that!

# ./bootstrap ksh: ./bootstrap: not found

Well. Let's fire it up via the shell then:

# sh bootstrap
bootstrap: ^M: not found
bootstrap: syntax error at line 4: `in^M' unexpected

Hmm. Would this be a dos file maybe?

# cat -v bootstrap
#! /bin/sh^M
^M
case $OSTYPE in^M
darwin*)^M
LIBTOOLIZE=glibtoolize^M
;;^M
*)^M
LIBTOOLIZE=libtoolize^M
;;^M
esac^M
^M
aclocal -I . && \^M
autoheader && \^M
$LIBTOOLIZE --automake --copy && \^M
automake --add-missing --copy && \^M
autoconf && \^M
echo "Ready to run ./configure"^M
# cat bootstrap | dos2unix > bootstrap2 ; mv bootstrap2 bootstrap ; chmod u+x bootstrap #

try again

# ./bootstrap
./bootstrap: aclocal: not found
#

This really warrants an $(echo 'f*ck' | sed 's/\*/s/') I'd say. Though I'd hate to give up! aclocal seems not installed indeed on opensolaris. Google reveals a trick that seems reliablyish though:

# ls /usr/bin/aclocal*
/usr/bin/aclocal-1.10 /usr/bin/aclocal-1.9

Let's set the 1.10 version to work:

# ln -s /usr/bin/aclocal-1.10 /usr/bin/aclocal
# which aclocal
/usr/bin/aclocal

# And again...

# ./bootstrap
/usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD
/usr/share/aclocal/libmikmod.m4:11: run info '(automake)Extending aclocal'
/usr/share/aclocal/libmikmod.m4:11: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
./bootstrap: automake: not found

Pfff. Read the blog entry again it says: and similarly for 'automake'.
So fix that as well:

# ls /usr/bin/automake* /usr/bin/automake-1.10 /usr/bin/automake-1.9 # ln -s /usr/bin/automake-1.10 /usr/bin/automake # which automake /usr/bin/automake

If that doesn't fix things...

# ./bootstrap
/usr/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD
/usr/share/aclocal/libmikmod.m4:11: run info '(automake)Extending aclocal'
/usr/share/aclocal/libmikmod.m4:11: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal configure.in:19: installing `./compile' configure.in:12: installing `./missing' configure.in:12: installing `./install-sh' common/mp4ff/Makefile.am: installing `./depcomp' Makefile.am: installing `./INSTALL' Ready to run ./configure

Well. wonderful! Let's see what she does!

# make
make all-recursive
Making all in libfaad
if /bin/bash ../libtool --tag=CC --mode=compile /usr/sfw/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -iquote ../include -g -O2 -MT bits.lo -MD -MP -MF ".deps/bits.Tpo" -c -o bits.lo bits.c; \ then mv -f ".deps/bits.Tpo" ".deps/bits.Plo"; else rm -f ".deps/bits.Tpo"; exit 1; fi mkdir .libs /usr/sfw/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -iquote ../include -g -O2 -MT bits.lo -MD -MP -MF .deps/bits.Tpo -c bits.c -fPIC -DPIC -o .libs/bits.o gcc: ../include: linker input file unused because linking not done
cc1: error: unrecognized command line option "-iquote"
cc1: ../include: No such file or directory

Ouch. Now what? Looks like gcc struggles. Digging through the man pages for gcc reveals no entry for -iquote. Now what? google (ironically: search for "gcc +iquote") tells me this:

  In GCC 3.5, we are considering replacing the -I- command line option
with a new -iquote option.

Ok, so. What gcc version am I running?

# gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I tried the older versions of aclocal and automake, different make (gmake) but that still generates the same error...
So, faad (and faac likely) are expecting a more recent version of a compiler... Not too weird considering that development is in the 4.something range.
Let's take it the other way and install the studio 12 suite. I had been planning on doing that anyways... (if not, I'll grab a more recent gcc somewhere else)

So with the following environment:

# env
_=/usr/bin/env
LANG=C
HZ=
PAGER=/usr/bin/less
PATH=/usr/sbin:/usr/bin:/usr/local/bin:/opt/SUNWspro/bin
SHELL=/usr/bin/ksh
HOME=/root
TERM=xterm
PWD=/root/faad2-2.7
TZ=Europe/Amsterdam
LESS=-X

# make
make all-recursive
Making all in libfaad
source='bits.c' object='bits.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/bash ../depcomp \
/bin/bash ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -iquote ../include -g -c -o bits.lo bits.c
cc -DHAVE_CONFIG_H -I. -I.. -iquote ../include -g -c bits.c -KPIC -DPIC -o .libs/bits.o
cc: illegal option -quote

Seems the "-iquote" flag is passed to studio cc as well. As I can't locate gcc 4.x (or 3.5+) quickly and don't want to put myself into the swamp called "building gcc 4 for opensolaris" just yet, I'll try and find out where the "-iquote" comes from...

Brute force approach:

# find . -type f -exec grep -l iquote {} \;
./libfaad/Makefile
./libfaad/Makefile.am
./libfaad/Makefile.in

Ah. So it's only in the libfaad makefiles! Let's see what they say:

# cd libfaad
# find . -type f -exec grep iquote {} \;
AM_CFLAGS = -iquote $(top_srcdir)/include
AM_CFLAGS = -iquote $(top_srcdir)/include
AM_CFLAGS = -iquote $(top_srcdir)/include

So what's the AM_CFLAGS in other makefiles?

# cd ..
# find . -type f -exec grep "^AM_CFLAGS" {} \+
./faad2-2.7/libfaad/Makefile:AM_CFLAGS = -iquote $(top_srcdir)/include
./faad2-2.7/libfaad/Makefile.am:AM_CFLAGS = -iquote $(top_srcdir)/include
./faad2-2.7/libfaad/Makefile.in:AM_CFLAGS = -iquote $(top_srcdir)/include
./faad2-2.7/plugins/mpeg4ip/Makefile:AM_CFLAGS = -D_REENTRANT -fexceptions
./faad2-2.7/plugins/mpeg4ip/Makefile.in:AM_CFLAGS = -D_REENTRANT -fexceptions
./faad2-2.7/plugins/mpeg4ip/Makefile.am:AM_CFLAGS = -D_REENTRANT -fexceptions

So. Let's find some recent gcc documentation and see what it suggests about it's workings. Maybe I can just replace it with a simple "-I" directive...

Quoting from the most recent (4.3.3) documentation:

-Idir

Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.

If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. The directory will still be searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.

-iquotedir

Add the directory dir to the head of the list of directories to be searched for header files only for the case of `#include "file"'; they are not searched for `#include <file>', otherwise just like -I.

So. If I just briefly chech the include files for their syntaxis of the #include statements, and make sure that they double quote their files, I should be able to replace the "-iquote" with "-I" and remain with the same compilers is my current theory.

Let's go about our work then:

# find . -name \*.h | wc -l
94

so 94 targets for includes. That may be a lot of work...

Looks like there's plenty of double-quoted #includes there:

# find . -name \*.h -exec fgrep '#include' {} \+ | head
./common/mp4ff/mp4ff.h:#include
./common/mp4ff/mp4ff.h:#include "mp4ff_int_types.h"
./common/mp4ff/mp4ffint.h:#include "mp4ff_int_types.h"
./common/mp4ff/mp4ffint.h:#include
./common/mp4ff/mp4ffint.h:#include "../../config.h"
./common/mp4ff/mp4ff_int_types.h:#include
./common/mp4ff/mp4ff_int_types.h:#include
./common/faad/aacinfo.h:#include "filestream.h"
./include/faad.h:#include "neaacdec.h"
./libfaad/syntax.h:#include "bits.h"

So. I'll assume that lines containing at least one single double-quote, will contain two. Also, (not too sure here) I'm assuming the bracketed includes (e.g. ) need no quoting.

So:

# find . -name \*.h -exec fgrep '#include' {} \+ | egrep -v '"|>'
#

Ergo, I'll assume for now that I can safely replace -iquote with -I. Since I couldn't find out easily where the -iquote gets set (I mean, the ./configure generates the makefiles, so it should be set there right? but can't find the clues in there to mitigate it.)

So. I replaced the offending "-iquote" with "-I", started from scratch with the 1.10 versions of aclocal and automake, configured with
CC=/usr/sfw/bin/gcc
#./configure --with-mp4v2
[ ... output omitted ... ]
and
# make
[ ... output omitted ... ]

completed!

I had a brief go at the xmms plugin, but that failed to build in the first go. Since it doesn't seem too releveant (I hope), I'll have a go at faac now, expecting to be able to mitigate the nasties I ran into rather quickly.

faac seems to suffer from similar woes: I'll leave the symlinks for aclocal and automake in place for now and apply similar fixes to the bootstrap file. All looks well (well. what do I know?) and a configure script is created.

The INSTALL file suggests nothing odd, no special flags, so let hit it:

# ./configure
[ ... output omitted ... ]
checking for off_t... yes
checking for in_port_t... yes
checking for socklen_t... yes
checking for fpos_t.__pos... no
configure: creating ./config.status
.infig.status: error: cannot find input file:
# ls .infig.status
.infig.status

Google for .infig.status suggests this may have to do with dos files screwing up this...

Hmm. I noticed a few more DOS files in faad as well, but they didn't seem to give me any trouble then...

Introducing a sledgehammer:
# find . -type f -exec file {} \; | egrep 'text|XML|script|html' | cut -d":" -f1 | while read f ; do cat $f | dos2unix > f ; mv f $f ; done

Now, let's see if we can make this puppy.

# make
fails.

I spotted:
psych.h:85:21: warning: no newline at end of file

and fixed that. Not that the make will complete because of that...

Next I spotted:
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -Wall -c -o 3gp.o 3gp.cpp
../../depcomp: line 566: exec: g++: not found
*** Error code 127
make: Fatal error: Command failed for target `3gp.o'

hmm. makes sense: /usr/sfw/bin is not in the path. So let's set CXX to /usr/sfw/bin/g++ and try again (funny that the configure didn't check for that...)

# make clean
# ./configure
# make

Now it completes!

# make install

So. That's the dependencies worked out! jripper is a jar file, so let's see what else needs to be done except a:

$ java -jar jripper.jar













Shows the config screen with the correct binary applications compiled above setup. Pity as oggenc and oggdec aren't present on opensolaris, so no ogg support.

Let's see if we can get this puppy to fly!

Well. I'll need to look into the cd device:
the log says:
19:49:40 ReadParam: /usr/bin/cdda2wav -D 1,0,0 -g -H -J -v toc,title,sectors
19:49:40 ProcessRunner::setStreams() thread.type=READ_STDERR_LINES thread.write=false aReadProcess=java.lang.UNIXProcess@94310b aReadFileName=null
19:49:40 /usr/bin/cdda2wav.bin: This is neither a scsi cdrom nor a worm device.
19:49:40 Can't read disc id number!
19:49:41 Exit code read process=1
19:49:41 Exit code write process=0
19:49:41 Has failed=true
19:49:41 Can't read disc id number!
19:49:42 Can't read disc id number!

So. I'll need to suppy something that's digestible for cdda2wav.
# cdda2wav
No target specified, trying to find one...
Using dev=0,1,0.

Configuring the setup page with 0,1,0 as the cd device, shows (with a dvd in the drive):
19:52:58 ReadParam: /usr/bin/cdda2wav -D 0,1,0 -g -H -J -v toc,title,sectors
19:52:58 ProcessRunner::setStreams() thread.type=READ_STDERR_LINES thread.write=false aReadProcess=java.lang.UNIXProcess@129645a aReadFileName=null
19:52:59 Type: ROM, Vendor 'HL-DT-ST' Model 'DVDRAM GSA-T20N ' Revision 'WP03' MMC+CDDA
19:52:59 274432 bytes buffer memory requested, transfer size 57344 bytes, 4 buffers, 24 sectors
19:52:59 /usr/bin/cdda2wav.bin: Read Full TOC MMC failed (probably not supported).
19:52:59 #Cdda2wav version 2.01.01a53_sunos5_5.11_i86pc_i386, real time sched., soundcard, libparanoia support
19:52:59 Tracks:1 255:57.74
19:52:59 CDINDEX discid: flplyXqMOiodZEDJeDw5Ci6OD_g-
19:52:59 CDDB discid: 0x023bfd01
19:52:59 CD-Text: not detected
19:52:59 CD-Extra: not detected
19:52:59 Album title: '' from ''
19:52:59 T01: 0 255:57.74
19:52:59 Leadout: 1151849
19:52:59 /usr/bin/cdda2wav.bin: This disk has no audio tracks.
19:53:00 Exit code read process=1
19:53:00 Exit code write process=0
19:53:00 Has failed=true

So. It looks like jripper is able to rip audio tracks from cd's, but isn't capable of ripping dvd's (with this bit of hardware anyways).
That's quite the disappointment I'd say after quite a bit of effort and I wasn't even expecting the regular "./configure ; make ; make install .

Well. off to bed.

ending LD_LIBRARY_PATH woes

As I have the habit of installing most of the hand built tools into /usr/local, I quite frequently run into troubles when secific apps require additions to the library path.

The rationale being that /usr/local seems to be somewhat of a default, and with various software repositories for solaris such as blastwave, sunfreeware etc have a tendency to install somewhere in /opt, This keeps at least some sanity to my filesystems.

As any lazy bastard, I normally would fix this by temporarily setting LD_LIBRARY_PATH to include the correct path and fire up the application.

Solaris and opensolaris have had a clean alternative to that a long time: via crle...

Here's how to add /usr/local/lib to it:

# crle

Default configuration file (/var/ld/ld.config) not found
Platform: 32-bit LSB 80386
Default Library Path (ELF): /lib:/usr/lib (system default)
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
# crle -u -l /usr/local/lib
# crle

Configuration file [version 4]: /var/ld/ld.config
Platform: 32-bit LSB 80386
Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)

Command line:
crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib

#

Note: when the config file exists, the single "-l" will overwrite the previous entries, however in the "special" case of a nonexistent /var/ld/ld.config, it will add the directory after the -l path.

pidgin, facebook plugins and opensolaris (nevada)

I recently stumbled over a facebook-plugin for pidgin and thought I'd give it a try and build it on my fresh install of nv_105.

Downloaded both the icons and the source...

# bunzip2 pidgin-facebookchat-source-1.47.tar.bz2
# /usr/sfw/bin/gtar xvf pidgin-facebookchat-source-1.47.tar
# cd pidgin-facebookchat

# make libfacebook.so
# cp libfacebook.so /usr/lib/purple-2/

# cd /usr/lib/purple-2/
# chgrp bin libfacebook.so

Icons were easy...

# bunzip2 pidgin-facebookchat-1.47.tar.bz2
# /usr/sfw/bin/gtar xvf pidgin-facebookchat-1.47.tar
# cp ./usr/share/pixmaps/pidgin/protocols/22/facebook.png /usr/share/pixmaps/pidgin/protocols/22/
# cp ./usr/share/pixmaps/pidgin/protocols/48/facebook.png /usr/share/pixmaps/pidgin/protocols/48/
# cp ./usr/share/pixmaps/pidgin/protocols/16/facebook.png /usr/share/pixmaps/pidgin/protocols/16/

Damn. by far the easiest I've run into...

Act one: No.1 Duetto "Bashing the SMF scripts for sake of a sane DHCP client config"

So I've been able to pick up a DHCP address from my ISP. I've resolved the client name issue. Big deal. But now, every time I log in, be it via X or via shell, I am told the hostname is the same as whatever my external interface has. Counterintuitive I would say: Wasn't the whole purpose of /etc/nodename to overcome this? (at least, this is the way it works if you configure interfaces statically!)

So I decided to start digging in the SMF framework to work around this. (I'll regret this when I start patching or upgrading again is my guess)

It was pretty easy to dig up the files related to the SMF framework:

• the XML files are in /var/svc/manifest//....
• the methods defined in the XMLs are located in /lib/svc/method.

A "fgrep -l '/etc/nodename' /lib/svc/method/* | xargs less" revealed that the hostname is set to the contents of /etc/nodename in two locations:

at the end of /lib/svc/method/identity-node:

# If the netstrategy was unsuccessful and we haven't got a locally configured
# name, default to "unknown"
#
if [ -z "$hostname" ]; then
hostname="`shcat /etc/nodename 2>/dev/null`"
if [ -z "$hostname" ]; then
hostname="unknown"
fi
fi

And then there's a similar snippet in /lib/svc/method/net-physical:

#In order to avoid bringing up the interfaces that have
# intentionally been left down, perform RARP only if the system
# has no configured hostname in /etc/nodename
hostname="`shcat /etc/nodename 2>/dev/null`"

I went for the easy way out. I modified both scripts to read the entry from a new file /etc/machine, containing the machinename.

Rebooted, and voila. Logging in showed the hostname I wanted all along for this machine.

routing table looks a clean as well:

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
192.168.200.0 dc-utr01-int U 1 495 hme1
XX.XXX.XXX.0 dc-utr01-ext U 1 999 hme2
BASE-ADDRESS.MCAST.NET dc-utr01-ext U 1 0 hme2

Act one: recitative "my server as a DHCP client"

the manuals say it's so easy. all you have to do is the following:

# touch /etc/hostname.hme2
# touch /etc/dhcp.hme2

reboot and you're done.
Which I did.

And cursed.

And cursed again.

I always forget that solaris doesn't stick to it's own hostname when it has DHCP configured addresses. And since windows clients do, no ISP in their right mind provides a hostname over DHCP. Endresult: the hostname is set to "unknown".

So: my initial attempt was to put the hostname in /etc/nodename.
In my opinion, an IP-address is tied to an interface. When naming them, I prefer to have some logical description as their name. in this case: the ip-address on hme2 should be associated with "dc-utr01-ext" which is short for "the external (ISP facing) interface in my datacenter in Utrecht, location #1"
A bit over the top for just a single box, but hey. think big.
following the same logic, I assigned hme2 a static address and name: "dc-utr01-int". This makes for easy interpretation of lots of network stuff like network snoops, dhcp server, firewall rules etc etc

So I did:

# echo "dc-utr01-ext" > /etc/nodename
and rebooted.

Only to find out that when I log in, the hostname has changed to this as well!
e.g.:
# uname -a
SunOS dc-utr01-ext 5.10 Generic_118822-30 sun4u sparc SUNW,Ultra-2

that doesn't make sense at all! It's ugly!

At this point I left it for what it was and went for some sleep.

Ouverture "copperjet anger"

For about 6 months now, I've been running solaris 10 at home as my primary server. I've got a bundle of all SUN/sparc branded hardware from the stone ages, which I try to utilize as much as possible, and ever since I threw my ISP provided Copper Jet 816-2p against the wall and swore never ever again to use it as something more than just a dumb modem (yes I know, it *can* be setup as a router, I've done that and cursed it every time it hung for some unknown reason) I've been struggling to set my Ultra 2 up as a proper replacement.

It was about time however that I started documenting my struggles as I think I've come a long way since I started out configuring and my guess is I'll never be able to reconfigure it like that again. (my OS grows organically).

As an overview, I think a diagram is always useful, but since I loathe diagram drawing software (or any graphics stuff for that matter), I put my white board & brand new camerato good use:

[ note: I got it wrong here: hme2 is attached to the copperjet. and hme1 is connected to the hub ]

Yup. I know. handwriting and drawing is not my thing either (this explains as well my craze for anything with a keyboard attached). For the record: the copperjet is attached to the hme1 and a very old 3Com superstackII 24 port hub is attached to hme2.

the cursed copperjet
The copperjet comes factory configured with an ip-address of 172.19.3.1/16 but for now, that's not really relevant since it's in bridging mode.

superstack hub
I can't exactly say why, but the superstack hub and I have had a loving relationship ever since I found and bought it at a flea market for about 5 euros. There's simply something magical about being able to observe and manage your network. It's not really fancy, since managing is limited to switching ports off and on, but a mighty fine set of ethernet statistics is gathered round the clock. Simply wonderful despite all it's shortcomings (i.e. 10 MBit, half duplex, and not being a switch). A long time ago, when I was still running a 10.0.0.0/8 network at home, I assigned it an address of 10.0.1.3/8 which I'll leave like that for now.

The clients
Talk about overkill: I've got two clients semi-permanent clients in my network! one is my primary interface to the net: my faithul iBook G4, the other one is my upstairs neighbour. The flat above me is apparently some kind of company owned flat where they put up all their international trainees. So every six months or so, a new trainee from (usually) France settles in. It's not that I mind helping them get around in the Netherlands, but we tend to go through the same cycles... "Can you help me set up my internet?" etc etc. I even ended up in assisting them to talk to some of the ADSL and cable-internet providers... Every six months or so, for about two years. So I decided to make life easy for myself and just connect her onto my pretty fat ADSL wire.

The server
my faithful Ultra 2! what a beauty she is! Such stability! So much perseverance when faced with adversity! We go a long way back, my Ultra 2 and me... I got her about 3 years ago, when I traded my Ultra 10 for her. I've lovingly upgraded her since, with 2x 18GB disks, a HVD scsi card, a SE scsi card, a quad ethernet card, additional external disks, and finally: 2x400MHz ultra sparc II procs which enabled me to run solaris 10, without dirty hacks to get it running.
The latest addition is a 7 slot DLT4000 autoloader, which I intend to use for the incidental backup.