Archive for December, 2008

SysAdmin Advent Calendar Blog In Review

Wednesday, December 31st, 2008

If you missed this years excellent Systems Administration Advent Calendar Blog you missed some great content. But do not despair! Its all there for your reading pleasure. Articles on scripting, new technology, primers, and workflow are there to help you into the new year. I even contributed an entry: Day 17 – Time Management.

A warm round of applause goes to Jordan Sissel for organizing it and rallying various bloggers to participate.

SA Pro: Episode 3

Wednesday, December 31st, 2008

Just before the end of the year, the third episode of SA Pro, featuring a 1 hour interview with OmniTI Founder & CEO Theo Schlossnagle.

Its a bit long, I admit, but Theo is an amazing guy and refreshing to talk with. Fire it up while you tweek on something fun for New Years.

Crossbow Experiements and Elation

Wednesday, December 31st, 2008

I wanted to play a little deeper with Crossbow, and in particular get my mind around Etherstubs and inter-stub routing. So I devised the following experimental architecture:

Etherstub0
        |----> vnic0    ---> zone001
        |----> vnic1    ---> zone002
        +----> vnic2  --
Etherstub1               +-> router01
        |----> vnic3  --/
        |----> vnic4    ---> zone003
        +----> vnic5    ---> zone004

The idea is to have 2 zones on one etherstub (virtual switch) on one subnet, 2 on another, and then an additional zone that sits on both acting as a router.

So I set forth to do this. Create a template zone, cloned it out and brought them all up. I created all the vnic’s assigned to the appropriate etherstubs and gave them to the zones as exclusive-ip interfaces and then configured each zones networking stack by plumbing and ifconfig’ing.

root@quadra ~$ dladm create-etherstub etherstub0
root@quadra ~$ dladm create-etherstub etherstub1
root@quadra ~$
root@quadra ~$ dladm create-vnic -l etherstub0 vnic0
root@quadra ~$ dladm create-vnic -l etherstub0 vnic1
root@quadra ~$ dladm create-vnic -l etherstub0 vnic2
root@quadra ~$ dladm create-vnic -l etherstub1 vnic3
root@quadra ~$ dladm create-vnic -l etherstub1 vnic4
root@quadra ~$ dladm create-vnic -l etherstub1 vnic5
root@quadra ~$
root@quadra ~$ dladm show-link
LINK        CLASS    MTU    STATE    OVER
e1000g1     phys     1500   up       --
e1000g2     phys     1500   down     --
e1000g0     phys     1500   unknown  --
etherstub0  etherstub 9000  unknown  --
etherstub1  etherstub 9000  unknown  --
vnic0       vnic     9000   up       etherstub0
vnic1       vnic     9000   up       etherstub0
vnic2       vnic     9000   up       etherstub0
vnic3       vnic     9000   up       etherstub1
vnic4       vnic     9000   up       etherstub1
vnic5       vnic     9000   up       etherstub1

Here is the zone configuration:

zonecfg:template0> info
zonename: template0
zonepath: /quadra/zones/template0
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: exclusive
inherit-pkg-dir:
        dir: /lib
inherit-pkg-dir:
        dir: /platform
inherit-pkg-dir:
        dir: /sbin
inherit-pkg-dir:
        dir: /usr
inherit-pkg-dir:
        dir: /opt
net:
        address not specified
        physical: vnic0
        defrouter not specified

I then decided on the following IP scheme:

IPs:
vnic0   10.0.90.10      /24
vnic1   10.0.90.11
vnic2   10.0.90.12
vnic3   10.0.91.12
vnic4   10.0.91.11
vnic5   10.0.91.10

Zones up, and it looks like this:

root@quadra ~$ zoneadm list -vc
  ID NAME             STATUS     PATH                           BRAND    IP
   0 global           running    /                              native   shared
   3 zone001          running    /quadra/zones/zone001          native   excl
   4 zone002          running    /quadra/zones/zone002          native   excl
   5 zone003          running    /quadra/zones/zone003          native   excl
   6 zone004          running    /quadra/zones/zone004          native   excl
   7 router01         running    /quadra/zones/router01         native   excl
   - template0        installed  /quadra/zones/template0        native   excl

Now we play!

First things first… can I touch an interface other than the one explicit assigned to it? And, do dladm commands work in a zone?

root@zone001 ~$ dladm show-vnic
root@zone001 ~$ dladm show-vnic vnic0
dladm: invalid vnic name 'vnic0': object not found
root@zone001 ~$ dladm show-vnic vnic1
dladm: invalid vnic name 'vnic1': object not found
root@zone001 ~$ dladm show-vnic vnic2
dladm: invalid vnic name 'vnic2': object not found
root@zone001 ~$ dladm show-ether
root@zone001 ~$ dladm show-usage
dladm: show-usage requires a file
root@zone001 ~$ dladm create-etherstub zonestub0
dladm: etherstub creation failed: object not found

root@template0 ~$ ifconfig vnic2 plumb
ifconfig: cannot open link "vnic2": DLPI link does not exist
root@template0 ~$ ifconfig vnic1 plumb

Ok, so dladm is useless and I can’t plumb an interface not assigned. Good.

Now, to setup our router. All we should have to do is enable IPv4 Forwarding on a zone with 2 interfaces, one on each network:

root@router01 ~$ routeadm -e ipv4-forwarding
root@router01 ~$ routeadm -u
root@router01 ~$ routeadm
              Configuration   Current              Current
                     Option   Configuration        System State
---------------------------------------------------------------
               IPv4 routing   enabled              enabled
               IPv6 routing   disabled             disabled
            IPv4 forwarding   enabled              enabled
            IPv6 forwarding   disabled             disabled

           Routing services   "route:default ripng:default"

Routing daemons:

                      STATE   FMRI
                   disabled   svc:/network/routing/legacy-routing:ipv4
                   disabled   svc:/network/routing/legacy-routing:ipv6
                   disabled   svc:/network/routing/ripng:default
                   disabled   svc:/network/routing/ripng:quagga
                     online   svc:/network/routing/ndp:default
                   disabled   svc:/network/routing/zebra:quagga
                   disabled   svc:/network/routing/rip:quagga
                   disabled   svc:/network/routing/ospf:quagga
                   disabled   svc:/network/routing/ospf6:quagga
                   disabled   svc:/network/routing/bgp:quagga
                     online   svc:/network/routing/route:default
                   disabled   svc:/network/routing/rdisc:default

root@router01 ~$ ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
vnic2: flags=201100843 mtu 9000 index 2
        inet 10.0.90.12 netmask ffffff00 broadcast 10.0.90.255
        ether 2:8:20:27:5f:6
vnic3: flags=201100843 mtu 9000 index 3
        inet 10.0.91.12 netmask ffffff00 broadcast 10.0.91.255
        ether 2:8:20:e9:65:94
lo0: flags=2002000849 mtu 8252 index 1
        inet6 ::1/128

Easy enough. In the old days you would enable the “ROUTER” flag on each interface and such, but now its all nicely wrapped by routeadm. Yeah!

I won’t bore you with the ping scenario details, but thanks to in.routed running in each zone by default the gateway just appeared auto-magically:

root@zone004 ~$ netstat -nr

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
default              10.0.91.12           UG        1          0 vnic5
10.0.91.0            10.0.91.10           U         1          1 vnic5
127.0.0.1            127.0.0.1            UH        1          0 lo0       

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
::1                         ::1                         UH      1       0 lo0
root@zone004 ~$ ping -s 10.0.90.10
PING 10.0.90.10: 56 data bytes
64 bytes from 10.0.90.10: icmp_seq=0. time=0.549 ms
64 bytes from 10.0.90.10: icmp_seq=1. time=0.091 ms
^C
----10.0.90.10 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 0.091/0.320/0.549/0.324
root@zone004 ~$ traceroute 10.0.90.10
traceroute to 10.0.90.10 (10.0.90.10), 30 hops max, 40 byte packets
 1  10.0.91.12 (10.0.91.12)  0.087 ms  0.041 ms  0.034 ms
 2  10.0.90.10 (10.0.90.10)  0.086 ms  0.056 ms  0.052 ms

How kool is that! I could take this further by adding in a public interface to the router and routing it as well, but I’d need to bring IP NAT into the mix and I’m not terribly interesting in that tonight.

Of course, one other test of interest is will snoop work properly? We know it works with IP Instances, but still work fine with vnic’s and etherstubs? Yes!

root@zone001 ~$ snoop
Using device vnic0 (promiscuous mode)
  10.0.91.10 -> zone001      ICMP Echo request (ID: 496 Sequence number: 5)
     zone001 -> 10.0.91.10   ICMP Echo reply (ID: 496 Sequence number: 5)
  10.0.91.10 -> zone001      ICMP Echo request (ID: 496 Sequence number: 6)
     zone001 -> 10.0.91.10   ICMP Echo reply (ID: 496 Sequence number: 6)

Furthermore, Etherstub does act as a switch. Other zones on the same etherstub will not see traffic unless its addressed to it.

As a sidenote, you’ll notice that Etherstub’s default to JumboFrame. You should be able to modify this, however the link-property shows as read-only… I’ll look into that later.

Ever wanted to roll out a functioning, routing, VLAN’ed, multicast network of hundreds of nodes to test your dream setup but only have a laptop? Now you can. All my test zones are consuming only 12MB of disk each, and I’ve got 300GB free on my home SATA RAIDZ2… so do that math. :)

BTW…. I did all this from architect to implementation and fully tested in 1 hour, including the time it took to install and configure all the zones. Solaris rules.

Can’t resist… lets try IP Filter within the Zone just to see that its happy. I’ll use a simple ruleset that blocks everything but SSH:

root@zone001 ~$ cat /etc/ipf/ipf.conf
#
# ipf.conf
pass in quick proto tcp from any to 10.0.90.10/32 port = 22
block in log from any to 10.0.90.10/32

root@zone001 ~$ svcadm enable ipfilter

Now we’ll test from another node:

root@zone004 ~$ ssh 10.0.90.10
The authenticity of host '10.0.90.10 (10.0.90.10)' can't be established.
RSA key fingerprint is 2e:fc:c7:36:33:70:db:16:d7:74:35:04:1a:3f:02:bb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.90.10' (RSA) to the list of known hosts.
Password: 

root@zone004 ~$ ftp 10.0.90.10
^C

Sweet. Now just a look at the IP Filter stats to make sure its not a fluke:

root@zone001 ~$ ipfstat
bad packets:            in 0    out 0
 IPv6 packets:          in 0 out 0
 input packets:         blocked 5 passed 25 nomatch 8 counted 0 short 0
output packets:         blocked 0 passed 15 nomatch 15 counted 0 short 0
 input packets logged:  blocked 5 passed 0

Perfect! Its actually blocking the packets. IP Filter works as you expect it too, in a zone on a vnic. Super sweet.

2008 Year in Review

Tuesday, December 30th, 2008

Here it is, big post 1,000. I’m fairly proud of that given that the vast bulk of all my blog entries are technical and not just brainless linkdumps. There is still a lot to blog about and I’ve still written a great many entries that ended with “more to come…”, never the less its a good milestone.

Looking back at 2008, we’ve had a very good a productive year in OpenSolaris land. COMSTAR arrived, Crossbow arrived, ZFS is getting stronger all the time, we got a new iSCSI Target, the first and second release in the 6 month cycle of Indiana went out on schedule, and Solaris 10 is now more or less on par with Nevada. Technically there is a lot to be proud of and excited about.

On the non-technical side we had another OpenSolaris Developers Summit and the first annual OpenSolaris Storage Summit. Ian Murdock gave a keynote at CommunityOne and there was a heavy emphasis on OpenSolaris at JavaOne. We did several good conferences this year, although not as many as in years prior. We had a dominant year at SNIA’s Developers Conference, helping solidify Sun’s role in the future of storage development.

On the Sun side, the mighty FISHworks released to the world and the response to the resulting offerings has been tremendous thus far and sets a new standard in storage particularly in the realm of the Sun-created buzzword “OpenStorage”. Business for Sun is poor but there are several areas of growth and although I think the MySQL acquisition was a massive blunder it may all pan out in the end.

On the OpenSolaris governance side, its been a sad year. Rather than moving forward the OGB decided to rehash old ground and fall right back into the same pitfalls. An all Sun OGB proved to be less effective than a mixed OGB. OpenSolaris governance in general is more closed off and insular than ever, but thats indirectly what Simon Phipps and others were shooting for.

The Silicon Valley OpenSolaris Users Group fell into significant decline over previous years, but tends to be a valley trend as technologies loose their initial buzz and become more established… the Silicon Valley Linux Users Group felt the same kind of declines, although not as sharply.

As we look to 2009, I think the word is “established”. OpenSolaris is here, Nevada is strong, we’ve proven that its not going to disappear. We now need to set the tone for the future by definitively establishing the future of Solaris 11 (or lack of one), upgrade path from Solaris 10 (if there is one beyond HP-UX like Update-forever), and wrapping extension technologies like xVM, Sun Cluster, and others around OpenSolaris. In general, customers are still largely unclear on where this is all ultimately going and what it means to them. If you have big SPARC box like Sun Fire E2900 in production running Sun Cluster, what does the future hold? S10 till you retire it? OpenSolaris makes a lot of sense to new adopting customers, but then a lot of them are running it on non-Sun hardware (Dell, HP, and Supermicro are popular)… how do we monetize them in a compelling way? And how do we continue to ramp Sun support of Nevada? To date most experiences with Sun Support over post-S10 releases are horrible as a lot of Sun’s Support organization simply doesn’t know it well enough.

So, the pave stones are on the ground, they now need to be shifted into a resting position so we can start walking people across the path. Its time to unify offerings and improve Sun’s sales, marketing and support around it.

Here’s to 2009!

Crossbow for Christmas

Monday, December 29th, 2008

After 2 years of waiting, Project Crossbow has arrived! It integrated into Nevada Build 105 on Dec 4th, and BFU’s became available around the middle of the month. SX:CE isn’t available just yet, but should be up in about a week I hope. Crossbow is huge. This is a monumental improvement to Solaris and continues to push the bar out of reach of its competitors.

Simply put, Crossbow redefines the nature of network virtualization. To date, virtualization was limited to creating traditional “virtual interfaces” like so:

root@quadra ~$ ifconfig e1000g1:1 plumb 10.0.0.50 netmask 255.255.255.0 up
root@quadra ~$ ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g1: flags=201000843 mtu 1500 index 2
        inet 10.0.0.18 netmask ffffff00 broadcast 10.0.0.255
        ether 0:1b:21:25:3e:7b
e1000g1:1: flags=201000843 mtu 1500 index 2
        inet 10.0.0.50 netmask ffffff00 broadcast 10.0.0.255

Creating virtual interfaces like this gets the job done but has a number of drawbacks, all based on the fact that its not a real interface. Stats are screwed up, you can’t snoop the interface, you can’t tune it, etc.

Crossbow changes all that. Now we can create Virtual NIC’s (vnic’s) which are, for all intents and purposes, real interfaces. They have their own network stack and queues, they can be tuned, the can be snooped, they can be VLAN’ed, etc. Anything you can do to a real interface you can do to a VNIC.

While VNICs are handy things to have in the globalzone, they really shine when used with virtualization such as Solaris Containers (zones) or Xen guests, because we now can hand off interfaces that are fully controllable from within the virtual environment without having to dedicate a physical NIC to each one. The result is virtualized environments that feel way more like real servers.

If you’re not already familiar with the dladm command its time for you to get acquainted. dladm is short for “Data Link Administration”, and now compliments ifconfig. For some time now its been used for managing WIFI, 802.11ad Link Aggregation (“teaming” or “trunking”, depending on your pedigree), and more recently VLANs. its even replacing the old (and crappy) ndd with dladm‘s “link properties”… a welcome improvement.

As of snv_105 several new options are available, namely sub-commands for creating VNICs and Etherstubs. A VNIC is a virtual network interface with all the trimmings of a real network interface. For the moment, it appears the max number of vnic’s is 799, but thats not set in stone, and frankly if you need more than that you need to re-architect. Etherstubs are in-software switches which can be used in concert with VNIC’s to create entirely virtualized in-software networks! In short, a standard VNIC will be associated with a physical GLDv3 network adapter, but we can also create a VNIC associated with an Etherstub to keep anything from ever touching the wire.

Lets ponder this. Why would you want a VNIC that uses a software switch (etherstub)? Seems completely useless right? Not entirely. On a traditional network you would create a DMZ with firewall and other goodies which routes to a private internal network… imagine that you can now do that all inside a single system!

Ok, so lets get cracking. Once you have snv_105 installed, we’ll create a VNIC associated with physical e1000g1, then an etherstub and 3 more VNICs that are internal using that etherstub:

root@quadra ~$ dladm show-link
LINK        CLASS    MTU    STATE    OVER
e1000g1     phys     1500   up       --
e1000g2     phys     1500   down     --
e1000g0     phys     1500   unknown  --

root@quadra ~$ dladm create-vnic -l e1000g1 vnic0
root@quadra ~$ dladm create-etherstub etherstub0
root@quadra ~$ dladm create-vnic -l etherstub0 vnic1
root@quadra ~$ dladm create-vnic -l etherstub0 vnic2
root@quadra ~$ dladm create-vnic -l etherstub0 vnic3
root@quadra ~$ dladm show-link
LINK        CLASS    MTU    STATE    OVER
e1000g1     phys     1500   up       --
e1000g2     phys     1500   down     --
e1000g0     phys     1500   unknown  --
vnic0       vnic     1500   up       e1000g1
etherstub0  etherstub 9000  unknown  --
vnic1       vnic     9000   up       etherstub0
vnic2       vnic     9000   up       etherstub0
vnic3       vnic     9000   up       etherstub0

So we have a variety of VNIC’s at our disposal. We now treat these like regular interfaces, using ifconfig to plumb them and assign IP’s:

root@quadra ~$ ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g1: flags=201000843 mtu 1500 index 2
        inet 10.0.0.18 netmask ffffff00 broadcast 10.0.0.255
        ether 0:1b:21:25:3e:7b 

root@quadra ~$ ifconfig vnic0 plumb 10.0.0.19 up
root@quadra ~$ ifconfig vnic1 plumb 10.100.0.2 netmask 255.255.255.0 up
root@quadra ~$ ifconfig vnic2 plumb 10.100.0.3 netmask 255.255.255.0 up
root@quadra ~$ ifconfig vnic3 plumb 10.100.0.4 netmask 255.255.255.0 up

root@quadra ~$ ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g1: flags=201000843 mtu 1500 index 2
        inet 10.0.0.18 netmask ffffff00 broadcast 10.0.0.255
        ether 0:1b:21:25:3e:7b
vnic0: flags=201000843 mtu 1500 index 7
        inet 10.0.0.19 netmask ff000000 broadcast 10.255.255.255
        ether 2:8:20:3a:70:5a
vnic1: flags=201000843 mtu 9000 index 8
        inet 10.100.0.2 netmask ffffff00 broadcast 10.100.0.255
        ether 2:8:20:f2:56:4d
vnic2: flags=201000843 mtu 9000 index 9
        inet 10.100.0.3 netmask ffffff00 broadcast 10.100.0.255
        ether 2:8:20:bc:b1:a1
vnic3: flags=201000843 mtu 9000 index 10
        inet 10.100.0.4 netmask ffffff00 broadcast 10.100.0.255
        ether 2:8:20:55:11:56

Please notice that they all have individual MAC addresses! There are severla methods for how the MAC is chosen, but I won’t go into them here.

If you are using Solaris Containers these VNIC’s would be given to a Zone as an “IP-Instance” (exclusive mode), a feature which was added some time ago but untill now only usable by dedicating a physical interface. The same should apply to Xen or other virtualization tools.

Finally, in our whirlwind tour of this amazing technology, lets look at my favorite feature of Crossbow.

Crossbow is both Network Virtualization (we looked at that above) and Network Resource Control. With Crossbow we have a real network resource control capability that is free from the terror that is IPQoS.

There are three types of resource controls at present: max bandwidth (rate limiting), priority (relative to other traffic), and cpu’s. Please note that these controls are not cumulative, but rather apply to any given point in time. These controls can be applied either to an entire link (NIC or VNIC) or alternatively to a particular network flow.

Let me pause here. If your not familiar with a “network flow”, it is a defined collection of network communication. For instance, a flow might refer to all HTTP (port 80) traffic to a given IP address, or perhaps all TCP traffic, or perhaps a combination of FTP, SMTP, and HTTP ports. If you’ve worked with firewall rules your familiar with the concept, a flow simply allows us a way to apply some action to a specific flow of traffic.

Crossbow adds the new command flowadm to define and control network flows. Here is an example:

root@quadra ~$ flowadm add-flow -l vnic0 -a transport=tcp,local_port=80 httpflow
root@quadra ~$ flowadm add-flow -l vnic0 -a transport=tcp,local_port=443 httpsflow
root@quadra ~$ flowadm show-flow
FLOW        LINK        IP ADDR                        PROTO  PORT    DSFLD
httpflow    vnic0       --                             tcp    80      --
httpsflow   vnic0       --                             tcp    443     --

flowadm relies on attributes that describe a flow, and properties which assign some resource control. We’ll add bandwith control to the flows above by modifying the “maxbw” property:

root@quadra ~$ flowadm show-flowprop
FLOW         PROPERTY        VALUE          DEFAULT        POSSIBLE
httpflow     maxbw              50          --             50M
httpflow     priority        --             --
httpsflow    maxbw              80          --             80M
httpsflow    priority        --             --

Here the maxbw is specified in Mbps. Docs show that percentages, Kbps, etc are supported, but they don’t seem to work right now.

maxbw will rate limit to the specified throughput, priority can be set “low”, “normal”, “high” or “rt” (real time). Using these controls carefully you can partition off bandwidth pretty nicely.

In addition to all this, extended accounting has been extended to incorporate accounting based on links or flows, but I’ll save that for another day.

Congrats to everyone on the Crossbow team. This is a major achievement and an amazing technological advance!

Merry Christmas

Thursday, December 25th, 2008

To all my fellow administrators, a very merry Christmas to you and yours.

‘Carol of the Bells’ by The Bird and the Bee




Luke Chapter 2:

In those days a decree went out from Caesar Augustus that all the world should be registered.

2 This was the first registration when Quirinius was governor of Syria.

3 And all went to be registered, each to his own town.

4 And Joseph also went up from Galilee, from the town of Nazareth, to Judea, to the city of David,
which is called Bethlehem, because he was of the house and lineage of David,

5 to be registered with Mary, his betrothed, who was with child.

6 And while they were there, the time came for her to give birth.

7 And she gave birth to her firstborn son and wrapped him in swaddling cloths and laid him
in a manger, because there was no place for them in the inn.

To my fellow brothers and sisters in Christ, let us reflect on our Lord and the blessings He has poured out on us and our families. Let us also be reminded of His birth and fullness of His coming… God, second person of the trinity, become flesh and blood to reconcile us to Him. He pooped a diaper, got hungry, swung a hammer in the hot sun, was tempted, ministered, died for our sin, and rose again. I pray that He give you all a restful Christmas season, and then return with joy to the work He has put before us.

OpenSolaris 2008.11 Properly Released

Wednesday, December 10th, 2008

OpenSolaris 2008.11 is now fully and properly released. At opensolaris.com you’ll find several video interviews, including Sun’s all-star cast names like John Fowler, Tim Cramer, David Comey, and Dr. Stephen Hahn. There is a demo of Time Slider, Sun’s time-machine like functionality added to GNOME’s file browser which leverages ZFS snapshot navigation in an easy to use graphical way. There are also presentations with both Intel and AMD on leveraging their technologies both present and forthcoming.

If you haven’t downloaded the new release yet, make it your weekend project. It runs as a LiveCD so grab it and play.

Ode to Dave

Friday, December 5th, 2008

David Stewart, in a super-snazzy suit no less, at Tokyo Tech Days 2008, photo by Jim Gris.

Is there a reason for this post? Nope… Intel Dave is just awesome. Anyone that can make me not hate Intel has got to have some kind of super powers.

OpenSolaris 2008.11 Released

Wednesday, December 3rd, 2008

The crew was so busy getting everything ready for OpenSolaris 2008.11 that they forgot to tell anyone they released it…… so, guess what: Download OpenSolaris 2008.11 Now!

For a great run through of new features, especially from a desktop perspective, please watch Roman’s excellent Whats New in OpenSolaris 2008.11 Screencast.

I know the docs team spent a lot of time on the docs kit for OpenSolaris 2008.11, but I can’t seem to find it… so, think of it as an easter egg, search and be amazed. I’m sure the docs are within the ISO itself.

If your interested in graffiti or modern art, or whatever, behold the new OpenSolaris shirt:

… judge for yourself.

UPDATE: I’m told by several sources that a big launch/announcement event is scheduled for next week, complete with blog blitz, etc. I therefore infere that they wanted to get the release out as close to Nov as possible and thus released early and quiet until the marketing hubbub could occur.

SA Pro: Tom Limoncelli Interview

Monday, December 1st, 2008

The 2nd SA Pro podcast has arrived…

Tom Limoncelli, of Time Management for System Administators and The Practice of System and Network Administration fame, and I talk about his books, experience at Bell Labs, and time management in general in this 60 minute interview.

Available in MP3, AAC, and OggVorbis, Download SA Pro here, or directly:

Special Bonus: For my faithful readers, here is the original cut intro.