# SmartMachine SSH public key authentication from a non-root account

This has been documented for Joyent SmartMachines, in particular for allowing users other than root to use SSH public key authentication, but is just as applicable for getting SSH public key authentication to work in general. SmartMachine reference: http://wiki.joyent.com/wiki/display/jpc2/Managing+SSH+Keys#ManagingSSHKeys-MultipleSSHKeys

First create the Unix account on the server, e.g.

[root@im ~]# useradd -g staff -d /home/davek -m davek
128 blocks
[root@im ~]# passwd davek
passwd: password successfully changed for davek


On the server, create the authorized_keys file in the user’s ~/.ssh directory.

On the client, generate an SSH public/private key pair in the ~/.ssh directory of the user you wish to connect as:

davek@mymachine:~/.ssh$ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/davek/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/davek/.ssh/id_rsa. Your public key has been saved in /home/davek/.ssh/id_rsa.pub. The key fingerprint is: davek@mymachine:~/.ssh$


Copy the SSH public key up to the server:

davek@mymachine:~/.ssh# scp id_rsa.pub root@xxx.xxx.xxx.xxx:/home/davek/.ssh
id_rsa.pub           100% |*****************************************************************************************************|   401       00:00
davek@mymachine:~/.ssh#


On the server, copy the public key into the target user’s ~/.ssh/authorized_keys file:

[davek@im /home/davek/.ssh]$cat id_rsa.pub > authorized_keys  On server, change file modes for ~/.ssh/authorized_keys to 600, and to the ~/.ssh directory to 700. On the client, change file modes for the ~/.ssh directory to 700, and check that file modes on the private key are set to 600. Test SSH public key authentication: davek@mymachine:~/.ssh$ ssh davek@xxx.xxx.xxx.xxx
Last login: Mon Dec 10 02:41:18 2012 from xxx.xxx.xxx.xxx
__        .                   .
_|  |_      | .-. .  . .-. :--. |-
|_    _|     ;|   ||  |(.-' |  | |
|__|   --'  -' ;-| -' '  ' -'
/  ; SmartMachine base 1.8.1
-'  http://wiki.joyent.com/jpc2/SmartMachine+Base


# System hard freezes with the AMD FX-8350

As an update to my post here, I observed seemingly random freezes on my system upgraded with the AMD FX-8350. The behaviour encountered was a total freeze of the desktop environment, no response to local keyboard nor mouse, no response to attempting to launch a virtual console, no reponse to pings over the network, and no ability to log in remotely. The only way to restore system operation was to perform a hard reset. Interestingly I could also consistently crash the system running a GraphicsMagick benchmark. Additionally, the freezes were OS-agnostic, occurring under both OpenIndiana and Ubuntu Linux.

Looking around online you can find several posts from folks on AMD Bulldozer rigs with very similar issues (such as detailed here), including a few from people who have rather alarmingly downgraded to a Phenom or Intel CPU as a “fix”, after having received advice to alternately update the motherboard BIOS, faff around with multiple BIOS settings, test and replace the RAM, power supply and hard disk, RMA-ing the new CPU (!?), and on and on and on. Most of this didn’t really add up, and similarly my problems were encountered on a system that was hitherto generally stable using an older-generation CPU (the Phenom II X6 in my case).

To cut a long story short, this quite simply turned out to be the motherboard not stably supporting the FX-8350. Although the ASRock 870iCafe 2.0 is an AM3+ compatible part and advertised as being “8 Core Ready” (to the point of specifically claiming compatibility with the FX-8350), the reality is that the latest BIOS release was in December of 2011 – a major red flag. After upgrading my motherboard to a Gigabyte GA-990FXA-UD3 with the recent F9 BIOS, the system is now stable. And yes, this is using the original PSU, RAM, graphics card etc.

For the OpenIndiana readers, the GA-990FXA-UD3 works fine, although don’t expect USB3.0 support:

# AMD “Piledriver” FX-8350 on OpenIndiana

I’ve recently acquired a brand-spanking-new AMD FX-8350 CPU as an upgrade to my Phenom II X6 box. All the recent benchmarks of this CPU seem to fairly consistently point to it being a multithreaded monster. Plus, AMD has dropped the price of the new FX CPUs compared to the original Bulldozer architecture parts – and the icing on the cake is that the upgrade path is as simple as performing a BIOS update on my budget ASRock motherboard, and swapping out the old CPU for the new. Bliss!

So, given that AMD’s Piledriver archtecture might be a bit of an unknown as far as compatibility with Illumos and OpenIndiana goes, how does it fare? Well, the system seems to boot fine and run: here is the CPU as detected by Peter Tribble’s Solview app:

8 cores, running at 4.0GHz – good. Let’s throw half a dozen VMs its way and see what happens:

CPU utilization as measured by Solview is in the foreground. I should mention that this is also with a couple of OpenIndiana Zones running: GlassFish serving up a wiki, and a local BIND resolver.

In the time since I’ve installed the CPU I’ve experienced a couple of system freezes, so I’ve disabled core power saving features in BIOS to see if that changes anything. Yes, this is a new CPU architecture on a development build of an OS, but all in all, it’s working fairly well. Assuming I can iron out any stability issues, the FX-8350 is easily an incredible bargain.

Update 1: After further investigating the system hanging issues, it’s not limited to OpenIndiana, and is also encountered with Ubuntu Linux installed. Further updates to happen as I get to the bottom of this 🙂

Update 2: See here.

# “Fork Yeah! The Rise & Development of illumos”

Great presentation here from Bryan Cantrill (formerly of Sun, currently at Joyent) about the story behind illumos. Some great comments on the (destructive) role management and marketing can play in innovation, related comments about how badly Oracle don’t get this (and never will really), and a few fascinating tidbits about the history of Solaris at Sun to boot.

Updated: the video itself is now available:

# Oracle announces DTrace for Linux, DTrace creators denounce it as “low quality” and “a joke”

Much interest and (sadly) amusement to be had over Oracle’s announcement of what they claim to be a port of the Solaris DTrace dynamic tracing technology to Oracle Enterprise Linux:

http://blogs.oracle.com/linux/entry/looking_back_at_oracle_openworld

In short, this provoked some classic reactions from two thirds of the team that created DTrace to begin with, first from Adam Leventhal:

http://dtrace.org/blogs/ahl/2011/10/10/oel-this-is-not-dtrace/

An excerpt:

“While I’d like to give this obviously nascent port the benefit of the doubt, its current state is frankly embarrassing. It’s very clear now why Oracle wasn’t demonstrating this at OpenWorld last week: it doesn’t stand up to the mildest level of scrutiny…announcing a product of this low quality and value calls into question Oracle’s credibility as a technology provider.”

And as Bryan Cantrill succinctly puts via Twitter – “Oracle’s “port” is a joke”:

More relevant commentary to be found here: http://news.ycombinator.com/item?id=3096211

EDIT: sure enough, from who I believe to be another former Sun software engineer:

http://dtrace.org/blogs/ahl/2011/10/10/oel-this-is-not-dtrace/#comment-2147

In case you haven’t already heard, OpenIndiana development release 151a is out. The critical change in this release is that it’s now based on the Illumos kernel, developed by star ex-Sun Microsystems talent in the wake of Oracle’s compeltely styleless killing off of OpenSolaris. Substantial new features which you won’t be seeing in Solaris 11 anytime soon such as KVM support are built-in and tightly integrated. And yes, KVM support for AMD CPUs is on the way – hopefully in time for the 8-core AMD Bulldozer architecture desktop CPUs…

There are also a nice set of desktop software additions, some of which OpenIndiana and OpenSolaris before it has been needing for ages, for example a capable suite of multimedia playback applications. OpenIndiana now has dedicated SFE repositories from which VLC and Mplayer can be installed, as well as bonus goodies such as Scribus and more.

After running 151a for a few days (the upgrade from release 148 was completely seamless by the way), I was presented with something I hadn’t seen for a long time, not since OpenSolaris development was closed off a couple years back…

# Intel makes Ars Technica staffer’s head hurt (and mine too)

Great article published recently by Ars Technica on the product differentiation methods used by Intel in the marketing and pricing of their CPUs:

Gotta agree with most of what Peter Bright has written about here. I also happen to be one of the poor saps that got caught out by Intel’s shitty marketing, having purchased an Intel quad core part that as it turned out was missing Intel VT-x. Ever since that discovery I’ve vowed to look for alternatives in future upgrades, and over the weekend I made good on this by upgrading the OpenIndiana oi_148 box to an AMD Phenom II X6. Six cores on the desktop, great for heavily threaded workloads, a no-unwelcome-surprises feature set and all for a terrific price.

# OpenIndiana based on Illumos is almost here!!

Finally, great news on the OpenIndiana and Illumos front:

So, this means the first official development release of OpenIndiana based on Illumos is imminent, the latter being the first truly open-sourced, community-driven Solaris-derived kernel. This is big, big news, as many of Sun Microsystems’ brightest engineers have worked on Illumos via the companies they have since joined (ex-Oracle…) that are actively using Illumos for their business.

Seriously, I can’t wait 🙂

# Yet another scathing appraisal of how Oracle is handling Solaris…

…by those who know it best, in this case Eric Schrock:

http://dtrace.org/blogs/eschrock/2011/05/31/beyond-oracle/

“It is with a sad heart, however, that I look at the work so many put into making OpenSolaris what it was, only to see it turned into the next HP-UX – a commercially relevant but ultimately technologically uninteresting operating system. This is not to denigrate the work of those at Oracle working on Solaris 11, but I personally believe that a truly innovative OS requires an engaged developer base interacting with the source code, and unique technologies that are adopted across multiple platforms. With no one inside or outside of Oracle believing the unofficial pinky swear to release source code at some abstract future date, many may wonder what will happen to the bevy of cutting edge technologies that made up OpenSolaris.

“…suffice to say that OpenSolaris is alive and well outside the walls of Oracle, so give it a spin and get involved!”

Amen.