Archive for August 30th, 2008

ipv6 in a Solaris zone

2008-08-30

This is a continuation of my saga of Solaris zones. In this episode, you’ll be presented with a ipv6 routing problem on Solaris.

Looking for information about ipv6 in Solaris zones, you’ll be likely to get across this page. It will tell you, how to assign an ipv6 address to your zone: get into the global zone and use zonecfg.

netra / $ zonecfg -z wibble
Sorry, I don't know anything about your "screen" terminal.
netra / $ export TERM=vt100
netra / $ zonecfg -z wibble
zonecfg:wibble> add net
zonecfg:wibble:net> set address=2001:0:0:1::4/64
zonecfg:wibble:net> set physical=eri0
zonecfg:wibble:net> end
zonecfg:wibble> verify
zonecfg:wibble> commit
zonecfg:wibble> exit
netra / $ zoneadm -z wibble reboot

After zone reboot:

bash-3.00# ifconfig -a
lo0:1: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
eri0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.0.1.63 netmask ffffff00 broadcast 10.0.1.255
lo0:2: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
eri0:4: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 2001:0:0:1::4/64

Nice, we have an ipv6 address.

bash-3.00# ping ipv6.google.com
ICMPv6 No Route to Destination from gateway 2001:0:0:1::4
for icmp6 from 2001:0:0:1::4 to 2001:4860:0:1001::68
^C

The address resolves, but there’s no routing. The aforementioned page does actually say something about it:

Starting in the Solaris 10 8/07 release, the /etc/hosts and /etc/inet/ipnodes files are unified and are symbolic links to each other. Routing must be done in the global zone as is discussed in the Trusted Extensions and Zones forums.

The question is, what’s the URL to the relevant thread? I couldn’t find it. Maybe my Google seach-fu isn’t good enough. My friend and me found a way to make this work, although we have no idea whether this solution is correct. All we know is that is somehow… works.

If you look at the ipv6 routing table in the global zone, you’ll see something like this:

Routing Table: IPv6
Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
2001:0:0:1::/64             netra.home.blizinski.pl     U       1       6 eri0:1
fe80::/10                   fe80::203:baff:fe0b:fd4b    U       1       1 eri0
ff00::/8                    fe80::203:baff:fe0b:fd4b    U       1       0 eri0
default                     fe80::213:a9ff:fe80:43be    UG      1       1 eri0
localhost                   localhost                   UH      1       0 lo0

It seems like routing is done via a link-local type address. If you look at the correspoding table in your non-global zone, you’ll see:

Routing Table: IPv6
Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
2001:0:0:1::/64             2001:0:0:1::4               U       1       0 eri0:4
ff00::/8                    2001:0:0:1::4               U       1       0 eri0:4
localhost                   localhost                   UH      1       0 lo0:2

Apparently, there is no link-local address here. Normally, link-local addresses are derived from the MAC addresses of network cards. Here, we have just one network card, and one MAC address – hence one link-local address, and it’s already assigned to the global zone. We need one more link-local address here… why not make one up?

netra / $ ifconfig -a | ggrep -B1 fe80
eri0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 fe80::203:baff:fe0b:fd4b/10

We’ll just pick the next address.

netra / $ zonecfg -z wibble
zonecfg:wibble> add net
zonecfg:wibble:net> set address=fe80::213:a9ff:fe80:43c0/10
zonecfg:wibble:net> set physical=eri0
zonecfg:wibble:net> end
zonecfg:wibble> verify
zonecfg:wibble> commit
zonecfg:wibble> exit
netra / $ zoneadm -z wibble reboot

After logging (using ‘zlogin wibble’) to the zone:

netra / $ zlogin wibble
[Connected to zone 'wibble' pts/3]
Last login: Sat Aug 30 11:57:01 on pts/3
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# bash -l
bash-3.00# ifconfig -a | /opt/csw/bin/ggrep -B1 fe80 # GNU grep FTW!
eri0:5: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
inet6 fe80::213:a9ff:fe80:43c0/10

We’ve got our address! It’s completely arbitrary and probably makes no sense. But the probability of collision is low and…

bash-3.00# ping ipv6.google.com
ipv6.google.com is alive

…it works!

UPDATE 2008-09-05: Another way of doing it is creating an IPv6 route on the global zone, using a global IPv6 address (as opposed to link-local).

sshd doesn’t start in Solaris zone

2008-08-30

This describes a quite silly problem I once had. Google had no useful search results, so I’m putting the solution here for the sake of all the lost souls not knowing why their pet sshd doesn’t want to run in a Solaris zone. Yes, you can solve it using truss and analyzing SMF startup methods. But I think there are better ways to spend your time.

The solution was found by me and my friend one warm Polish summer night. Here we go, then!

Solaris zone tutorials will tell you something along the lines of:

netra / $ zonecfg -z wibble
Sorry, I don't know anything about your "screen" terminal.
netra / $ export TERM=vt100
netra / $ zonecfg -z wibble
wibble: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:wibble> create
zonecfg:wibble> set autoboot=true
zonecfg:wibble> add net
zonecfg:wibble:net> set address=10.0.1.63
zonecfg:wibble:net> set physical=eri0
zonecfg:wibble:net> end
zonecfg:wibble> set zonepath=/zones/wibble
zonecfg:wibble> verify
zonecfg:wibble> commit
zonecfg:wibble> exit
netra / $ zoneadm -z wibble install
Preparing to install zone <wibble>.
Creating list of files to copy from the global zone.
Copying <8442> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <239> packages on the zone.
Initialized <239> packages on zone.
Zone <wibble> is initialized.
The file </zones/wibble/root/var/sadm/system/logs/install_log> contains a log of the zone installation.
netra / $ zoneadm -z wibble boot

At this point, I was pretty convinced I would already be able to log into the zone via ssh and IP address 10.0.1.63. But there was nothing listening on port 22 in the zone. I logged into it to find the problem.

netra / $ zlogin wibble
[Connected to zone 'wibble' pts/2]
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# ▊

I spent a bit of time there, looking for reasons. Ssh service was offline.

bash-3.00# svcs -a | grep ssh
offline         1:48:51 svc:/network/ssh:default

Using svcs -x -v, I’ve found out that sshd was not running because of network/rpc/gss, which depends on network/inetd, which depends on system/sysidtool. And sysidtool is ‘starting’.

It turns out, after booting a zone, you need to zlogin to its console, that is you have to use ‘zlogin -C wibble’ command. You’ll then be presented with a text installer interface.

This means, that even though ‘zoneadm -z wibble install’ completes, your zone isn’t quite as installed as you would wish. It still doesn’t know its locale, terminal settings, it doesn’t have ssh public/private key pairs, hostname, DNS server (name service configuration), NFSv4 domain configuration, time zone and root password.

zlogin -C zonename

…is your friend!


Follow

Get every new post delivered to your Inbox.

Join 474 other followers