Thursday, December 01, 2005

How do I customise an SMF service?

After a conversation on #opensolaris I thought it would be useful to explain how to get SMF to run services that you have installed yourself that are really updated versions of ones that ship with solaris.

The one in question was DNS. "Solaris10" had installed his own version of named in /usr/local/sbin/named and wanted to get SMF to start it. When I arrived there was discussion about editing the manifest file (/var/svc/manifest/network/dns/server.xml) or copying it and making another.

As it turns out, neither of those is needed or particularly good. Edits to the system supplied file may be overwritten by a future patch or upgrade and making your own service means you won't get the benefits of those upgrades and patches.

So, how is it done?

The answer is that many attributes of services are parameterized into properties of the service. Those properties can be changed on your system without editing the manifest files, and they are not broken by updates.

You can view the properties for a service with:

# svcprop dns/server

This lists them all. The one we're interested in is called "exec" in the property group "start", so to just see that one:

# svcprop -p start/exec dns/server

To change a property, use svccfg as follows:

# svccfg
svc:> select dns/server:default
svc:/network/dns/server:default> listprop start/exec
start/exec astring /usr/sbin/named
svc:/network/dns/server:default> setprop start/exec = /usr/local/sbin/named
svc:/network/dns/server:default> listprop start/exec
start/exec astring /usr/local/sbin/named
svc:/network/dns/server:default> quit

Then you need to refresh the service:

# svcadm refresh dns/server

And now, start it:

# svcadm start dns/server

Finally, you can actually make the svccfg part much shorter with:

# svccfg -s dns/server:default setprop start/exec = /usr/local/sbin/named

Tuesday, November 15, 2005

A fool and..

Many product areas have got to the point where they have a problem. Modern technology and manufacturing techniques have made it possible to create perfectly adequate items for very low cost. The watch market is a perfect example. The Swiss industry built a reputation on making quality items in an age where dozens of moving parts needed to be precision manufactured to make a good watch. There was an actual functional difference between a cheap watch and an expensive one.

Quartz movements ruined all that. Suddenly it was possible to make a watch that was more accurate, reliable and robust than the best mechanical one for about five bucks. So what did they do? With some exceptions, they continued to make "prestige" watches, which these days consist of mercurial fashions made from ludicrously decadent materials. (I'd provide links to examples, but the industry seems to revel in the most egregious use of Flash that I've seen anywhere).

High-end audio has, like any other field catering to those with more money to spend than is needed to build a well-performing product, produced a whole subset of the industry that sells stuff that is sold as "premium" but has absolutlely nothing to support that claim. The "audiophile" area seems to attract an unusually high level of pseudo-science. With all that in mind, I think it's worth mentioning that it is at least fun to point and laugh at some of the more extreme examples of what those idiots will buy:
Apparently, "OPUS MM unleashes thrilling levels of performance...". That may well be so, but OPUS MM also unleashes thrilling amounts of cash from your obviously overfull audiophile wallet. Your shiny new speaker cable will set you back a truly outstanding thirty thousand, seven hundred and fifty dollars, and no cents. I'll say that again: $30,750.00

Enter Nexenta

Well, I had a whole post ready to go following the announcement of Debian GNU/Solaris the other day. It didn't make it to the net, however, since I was tied up with flights and what-not. Anyway, it's now irrelevant, since it was based on speculation about the new kid on the OpenSolaris block. Who knew that they would be launching the actual software within 3 days?

So, now I've tried it out, and I've gotta say it's nice. It's not fast on QEMU (that wasn't helped by my Xserver crashing part way through the first ever boot, leaving it unusable), but it's nice, nonetheless.

I do wonder how some decisions were made, though. For example, it looks like the ls command used is the GNU version, not the OpenSolaris version. I can see that some people would like the --color option that the GNU version provides (I'm not one of them), but some functionality is lost as a result. For example, the Solaris ls has long included the ability to show the presence of ACLs and extended attributes (with -@), as well as the new -e and -E options. I hope they haven't thrown out the baby with the bathwater.

Thursday, November 03, 2005

Good Morning...

So what should I say in a first post? No idea, except to that that I'm stoked that the wait for ZFS is almost over.

If you haven't been following the details of ZFS - or you have been following by reading the trade press, which amounts to the same thing - the best recent technical description of ZFS than I know of is the set of slides that James McPherson used at the recent SOSUG4 meeting

I think it will be a great paradigm shift in how we look at filesystems. Not all the concepts are new for those of us with an interest in filesystems (pooled storage, compression, quotas and copy-on-write have been seen before in production filesystems) but it's the combination of these features with other unique approaches to performance, reliability and usability that I'm excited about.

One question nags at the back of my mind... once I have a system with large ZFS pools including many filesystems and snapshots, how do I back the whole thing up? Not just the contents of one filesystem, but the whole thing?

James mentions "real-time remote replication" so for offsite backups that may be a moot point. Sun's recent purchase of StorageTek suggests that they don't think the era of tape backup is over yet, though. Maybe the Data Management Unit (DMU) layer will do heirarchical storage...

The other intriguing aspect of James' slides is the part about using DMU as a "general purpose transactional data store". Apart from the awful, frankensteinesque beast that is UFS/zvol/DMU I think there's some real potential for innovation at this level... Reiser4 semantics on top of ZFS foundations, anyone?