Wandering Thoughts archives


Oracle's future for Sun's hardware and OS business is now clear

The alternate title for this entry is 'how to persuade us to never buy your hardware again'.

The old Sun had both a general server business and a general OS business, and people used both; they bought Sun servers to run lots of operating systems and they ran Solaris on lots of non-Sun hardware. It is now clear that Oracle is nothing like this. Solaris now exists only to run on Oracle hardware, and Oracle hardware exists only to run Solaris and a few other Oracle-supported operating systems.

Why do I say this? Well, it's due to the latest bit of Oracle news, to wit that Oracle has restricted access to firmware updates (via Slashdot). In order to get firmware updates, your hardware either has to be under its one-year warranty or you have to have an Oracle support contract for it. Older than a year and without a support contract? You lose. This policy change was introduced abruptly and with no advance warning; it appears that even (ex-)Sun and Oracle support people may not understand it yet.

(Note that you must have a support contract that includes hardware support. A Solaris software support contract is not good enough, as I have verified.)

This is much more important than it looks from the outside. For most systems, server firmware updates are relatively unimportant; few people ever apply BIOS updates. But Sun servers have integrated lights out management processors, which are network accessible under some circumstances, and they have had security vulnerabilities. These security vulnerabilities are fixed with, you guessed it, firmware updates.

As far as I am concerned, this makes access to firmware updates somewhere between very important and vital for running production Sun servers, especially since their excellent ILOMs were much of the reason to prefer them in the first place.

But wait, it gets better: you cannot buy hardware support without buying Oracle software support (at least for new support contracts), and software support is twice as expensive as the hardware support. Software support costs 8% of the net hardware purchase cost per year, and adding hardware support costs an additional 4% per year (per here, found via Hacker News). Oracle very explicitly won't sell hardware support by itself, and have said so clearly.

This makes it very clear that Oracle intends their hardware almost exclusively for running Oracle-supported operating systems, since if you run a non-supported OS on Oracle hardware, you are completely wasting the 8% a year Oracle software support fee.

(If you do not get hardware support, you are gambling on there not ever being an ILOM security vulnerability that affects you. Since the ILOM is accessible from the server itself under some circumstances, this is not a bet that I would want to take.)

There are two immediate corollaries to this firmware access policy change. First, if you still have systems under hardware warranty (or hardware support contract), get the latest firmware updates now while you still can, even if you don't plan to apply them. Second, smart people buying second-hand Sun servers are likely to either demand that they be at the latest firmware version or require a potentially significant price discount, or both.

(Hence one reason to get the latest firmware updates even if you never plan on applying them yourself.)

solaris/OracleSunFuture written at 21:20:07; Add Comment

The right way and the wrong way to disable init.d services

First, a quote from the (Ubuntu) manpage for update-rc.d (pointed out in the comments on a recent entry):

The correct way to disable services is to configure the service as stopped in all runlevels in which it is started by default. In the System V init system this means renaming the service's symbolic links from S to K.

Here is one difference between a developer and a sysadmin: to a developer, something is disabled if it only runs harmless code or only runs code in harmless situations. To a sysadmin, something is only disabled if it doesn't run any code at all.

The wrong way to disable init.d scripts is to leave K* symlinks around for them; it is the developer answer, not the sysadmin answer. The init.d scripts are still running, they are just theoretically only doing harmless things or only running in harmless situations (when the system will soon reboot anyways). In practice, no; there are too many init.d scripts that feel free to have their stop action do things that range from undesirable to dangerous, and any number that blithely assume that any instance of the daemon that they start must have been started by them.

(This is especially the case if stop or restart actions are going to run during package upgrades, instead of just when the system is shutting down. And if you actually use multiple runlevels, your life hurts.)

The right way to disable init.d scripts is to remove all rcN.d symlinks, both start and stop, and keep them removed (one way or another). That way I do not have to trust that the authors of the daemons that we aren't actually running all got it right, because I'm pretty certain that they didn't.

Systems that insist on doing things the developer way instead of the sysadmin way are broken, whether their developers realize this or not.

(I'm aware that I'm not going to persuade anyone important of this, and I'm sure that the Debian people will be happy to tell me that I'm totally wrong and they always get init.d scripts perfect and thus their way is the correct one. Sorry, I'm a sysadmin, I don't believe in systems where everyone has to get everything right all the time.)

(The comments on the recent entry both corrected my original mistaken ideas and caused me to think about all of this.)

linux/DisablingInitScripts written at 01:18:28; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.