The first thing you'll notice when you login to your Joyent Accelerator is… its Solaris. More specifically, its OpenSolaris. Most of the containers in customer hands today are running on OpenSolaris B43, which has been extremely stable for us. You can learn more about OpenSolaris, download the code and install media, read docs, or get involved at www.opensolaris.org.

Your immediate question might be: Why OpenSolaris? Everyone uses Linux and BSD right? Well, they shouldn't. While Linux and BSD are great OS's, Solaris remains the de facto enterprise class operating system of choice. In years gone by that came with a price because Solaris wasn't free, wasn't open, and had utterly pathetic X86 support. This, however, has changed in the last 2 years. Solaris is now open source (under the CDDL license, view the complete source on line at http://cvs.opensolaris.org), it's free to both develop on and deploy, and brings features and functionality that simply aren't available from any other OS. These features include DTrace (a developers dream, now included in BSD and OSX), the Service Management Facility (SMF, an init replacement), the Fault Management Framework (FMA, together with SMF provides “self healing”), ZFS (the worlds most revolutionary 128-bit filesystem), and much much more. From our perspective the question isn't “Why are you using Solaris?”, but rather “Why isn't everyone else?”. Of course, the feature of Solaris you'll be getting to know best are Containers, a combination of Solaris Zones (virtualization) and Solaris Resource Management. Whereas most VPS's today are simply Linux distro's running on VMware, we're leveraging OpenSolaris from end-to-end on top-of-the-line Sun Galaxy class systems for maximum capability and value.

So lets start at the top and work our way down…

All of our servers are the same. Accelerators are deployed on Dell Poweredge 2950's: 8 Xeon 2.66Ghz cores with 32GB of ECC memory. Solaris is a 64bit OS with a unique ability to seamlessly run 32bit and 64bit applications. It is important to note that you can “burst” all the way up to the full capacity of the box so long as it's not being used by the other Accelerators on that system. The resource controls in place currently don't really cap the resources that you can use so much as it simply balances between you and the other customers on that system, so if you're on a 1/4th system you're sharing with 3 other customers, if you're on a 1/8th system you're sharing with 7 other customers, so on and so forth. I have yet to find a hosting provider that offers anywhere near this kind of power. Most VPS's on the market just give you a single 2Ghz Xeon core and a gig of memory and charge you way more than we do… we're giving you some serious value, but I'm biased.

Your zone sits on a local 10K RPM SAS (Serial Attach SCSI) drive and is limited to 5GB in size. Additional storage is supplied via NFS. Our NFS servers are Sun Fire X4500 “Thumper”s. Storage on the Thumper is managed by ZFS on a massive 18TB RAIDZ2 (Dual Parity RAID5) pool. If you want to buy 2TB of storage, trust me, we can sell it to you. Big storage isn't any use if its not fast, so each X4100 uses aggregated Gigabit Ethernet connections (2Gb/s) on a private storage network. In a standard container I'm able to achieve greater than 100MB/s performance over NFS.

Looking at the OS itself, most containers are currently deployed on OpenSolaris Build 43. We use “sparse zones”, meaning that filesystems such as /usr are loopback mounted to save space and as such are read-only. It's a Solaris custom never to install software into /usr anyway, and so you'll find most of your non-OS software installed in /opt.

While On-Demand Containers are technically a “Virtual Dedicated” or VPS product, we do supply a decent set of applications, most of which are configured or running out of the box. Because you have root access to your container we can not support any changes to this default configuration. You are entirely free to wipe out everything if you choose and build your own applications or use some other method, its your container and you can do what you want. In terms of support, we support the container itself, that it's running, available, and fast. We will support you if the default configured applications don't function properly, but as soon as you change the configuration we're not responsible. For instance, if you add DSpam support to Postfix and Postfix breaks, that's your problem, not ours. It's not that we don't want to support you, but we are human too and can't know every possible configuration of every single piece of software you want to run.

Most of the user-land applications in your container, such as Postfix, PostgreSQL, MySQL, Courier, Webmin, etc, are provided by pkgsrc. Before March 22, 2008, package management was provided by Blastwave.

You can start up software on Solaris in 1 of 2 ways: the legacy init script (/etc/init.d, /etc/rc3.d, etc) and SMF. If you put startup scripts in /etc/init.d please remember to symlink them into /etc/rc3.d, prefixed with S99 to indicate that it should be run at startup. You can symlink it to K99 as well, to ensure that its stopped when shutting down or rebooting. While the old init scripts still work, they aren't very intelligent. SMF on the other hand supports various dependencies, parallel startup, and actively monitors processes so that if your application stops suddenly for some reason it'll be restarted automatically. You can use the “svcs -a” command to view all the SMF services in your container and “svcs -vx” to view only services that should be running but aren't. Read the smf(5) man page for more information or visit the SMF OpenSolaris community: http://opensolaris.org/os/community/smf/

One great advantage of a Container is that there is only 1 kernel running on the server, which means that when you reboot a container you're only really changing state and running back through the run levels (or “milestones” in SMF-speak). Rebooting a container can take as little as 3 seconds, depending on how much you have starting up on “boot”.

Something that should be made very clear is the importance of making your container “reboot ready”. Whether we like it or not, things happen, servers need to be upgraded or tuned requiring reboots, a server panics, etc. A number of things can occur that may result in your container rebooting and it's very important that you've tested rebooting yourself so that everything starts up as you expect it to. If we are forced to do emergency maintenance at 3am, we don't want you to wake up and find that your server has been offline for 6 hours because Apache didn't automatically start.

Solaris is a System V based UNIX OS. To most people that just means “init” instead of “rc” and “ps -ef” instead of “ps aux”, but Sun hasn't forgotten the BSD fans out there, particularly because prior to SunOS 5 (aka: Solaris) it was a BSD based OS. You can find BSD “compatibility” tools in /usr/ucb (UCB for UC Berkeley), including BSD variants of common tools such as ps, whereis, and whoami.

Two other directories to know about are /usr/sfw and /usr/ccs.

In /usr/sfw (SFW stands for Sun FreeWare) you'll find various open source tools such as wget. In a full Solaris install a lot of useful tools will be found there, but because we use Blastwave we limit it to only a few.

In /usr/ccs you'll find various build tools (CCS stands for C Compiler Support), such as ar, as, ld, nm, m4, make, yacc, etc. Bear in mind that these are Sun tools, not GNU.

This brings us to a very important point about adjusting to Solaris. On most common *nix OS's today people are used to GNU tools being the default, however on OS's like Solaris, HP-UX, AIX and others that have been around for a long period of time these tools already existed. Remember that GNU tools were created as free replacements for UNIX standard tools found in commercial variants. Thus, GNU tools are almost always prefixed with a “g”, because they conflict with the default tool. Thus “tar” is the Solaris version and “gtar” is the GNU version. While this is entirely logical, it can be extremely frustrating to those who expect “tar” to be GNU Tar or “make” to be GNU Make. The best way to cope with this reality is to rely on aliases. For instance, I commonly put several aliases like this in my profile:

alias tar='gtar'

alias make='gmake'

Despite this logic of prefixing commands with “g”, it doesn't apply to BSD tools found in /usr/ucb, so be careful about how you include it in your path.

Finally, lets just share some quick points and tools that you might find useful on Solaris (a quick “Solaris Refresh” if you will):

• Solaris doesn't use “top”, although its provided with Blastwave. A much better tool is Solaris's “prstat”
• Solaris doesn't use “lsof”, instead use “pfiles”. Pfiles is one of a collection of tools known as the Ptools (read the man page proc(1)) which are extremely useful. Pfiles will list all open files for a given PID. You can return PID's based on process name with “pgrep” (ie: “pgrep httpd”).
• My favorite Ptool is “pstack” which can list the call stack of either a running process or a core fire! You can quickly look at a coredump without using a debugger with “pstack core.file”. Super handy! But I know your code never needs this. ;)
• View running services with “svcs -a”. View problem services with “svcs -vx”, which tells you what isn't running, what dependencies are blocked because of that service, and what is actually wrong with it in plain english.
• Ping is in /usr/sbin on Solaris! This is very weird to many people, so make sure to put it in your path. Also, by default ping only returns “Yes its alive” or “I think its dead, Jim”. To get the continuous ping response that your used to use “ping -s somehost” and it'll work just like you expect. If you don't want to add /usr/sbin to your path consider just aliasing it like above.
• The “useradd” tool doesn't add home directories for you. Again, this is something that most Linux users expect to be automatic and isn't. To create the directory simply use the ”-m” flag, ie: useradd -m -d /home/benr benr
• By default Solaris wants to put home directories in /export/home. When using “useradd”, specify ”-d /path/to/home” like above.
• Solaris culture dictates that /opt is where 3rd party software goes, and /export is the general purpose dumping ground for everything else, where that data is typically NFS exported (hence the name). This might not mean anything to you, but you should be aware of the convention. In the case of our containers, /home, having 25G or more of storage, is the preferred place to keep your data.

While your container might feel strange at first, especially if your used to developing on Mac OS X or Linux, we think that with a little time you'll come to appreciate the power that Solaris provides and the flexibility that our containers give you.

For more tips, tricks, HOWTO's, and docs please keep an eye on our Accelerator Forum: http://discuss.joyent.com/viewforum.php?id=37

For support issues, submit a ticket on our support page: http://help.joyent.com/

When submitting a ticket, please label the case as a “Accelerator Issue” and supply your zonename (login into your container and use the command “zonename”) in the “Server/Container Name” field. In the “UserName” field give us your IP or just a - will do.

Finally, our goal at Joyent is to provide you with the best development and deployment experience possible. We're working hard to improve our offerings every day to make your life easier and more productive. If you have questions or comments feel free to share them with others in our forum (link above).