Saturday Feb 25, 2006

McKinsey on Strategy. Services and Product

The most recent McKinsey Quarterly is pretty relevant. The keynote article, "Distortions & deceptions in strategic decisions" looks at the flawed human values often inserted into major business decisions. They quote a major aquisition decision taken by a dominant player and suggest that the major advocate of the merger wanted it for personal political gain. They look at ways in which these human factors can be brought into the open and evaluated in the decision making process. Despite identifying over-optimism as a frequent occurence once a proposal has been made, the decision not to proceed is often taken in private and so collaborative decision making cannot neutralise these human shortcomings. One suggestion is to ask the proposer, what their next best proposal is.

The second article of interest is entitled "The right service strategies for product companies". I last wrote about this subject last year, when I reviewed Gordon Moore's article "Don't shoot the messenger", where he talks about aligning service offerings with the product life cycle. The McKinsey article offers a two by two matrix. The goal of the services business is either to enhance or enable product sales or to deepen the value proposition to the customer (and hence earn money). The service vendor can then seek to leverage economies of skill or scale. Like most strategy analysis, its important to understand your choices and then focus on that choice. The choices affect pricing, sales, delivery and organisation. This varies from some of the things covered in my previous reviews in that they have reduced the choice to a 2x2 matrix and conern themselves with questions of strategy.

My previous article, concerning aligning service to the product life cycle is here... and the article concerning alignment ideology (the economies of skill?) is here....


Tuesday Jan 03, 2006

Dave's Adventures in Qubeland; shells and boot configuration

Isn't chkconfig a good idea. The first time I came across it, it seemed to be just a status and service requirment function. (See also what I said last time here...). I used it via GNOME and Red Hat's service manager,and Red Hat's documents are here.... While working on my Qube I have been pointed at it again by ddclient (see also my blog here... about DDNS), I've come to the conclusion that its really rather good. Here is Linux About's link and here is the SGI link.

This works with rc start|stop scripts. Actually they encourage a "status" branch, and also a restart branch aka "stop; start". All you need is a configuration line and a description line in the script. Immediately below is the code from ddclient, the first line states the run levels for which this program is required , the start level priority and the stop level priority. (This contrasts with Solaris SMF, which does not state priority as scalar but as relative).

# chkconfig: 2345 65 35
# description: ddclient provides support for updating dynamic DNS services.

Copy the rc file to the /etc/rc.d/init.d directory, make the directory current and then issue the chkconfig -add command and the rc.d links will be created for you. i.e. the first string on the chkconfig: line defines the run levels at which the program will run

I have added the following (final two) lines to the opensshd script to permit chkconfig to work with it.

# Donated code that was put under PD license.
# Stripped PRNGd out of it for the time being.
# Inserted by Dave Levy
# chkconfig: 2345 92 95
# description: This is the secureshell daemon

Running chkconfig --add ${opensshd_script_name} ensure that the links in the rc.d directory structure are created. This is neat; I've forgotten where to put it, and I don't have to muck around with remembering. Frankly I added the last two lines from the above to my rc script using vi, but it would be nice to automate it.

An additional problem however, is that the openssh project distributes the rc script with an incorrect directory for the shell. For Cobalt (and maybe other) Linux(es), you'll need to substiture the first line with #!/bin/sh, the code string below fixes this,

cat ${opensshd_script_name} | sed -e "s?\\#\\!/sbin/sh?\\#\\!/bin/sh?g" \\
    >> ${opensshd_script_name}.${script_ver}

We might want some version control code. The code above assumes that ${opensshd_script_name} and ${script_ver} have been set appropriately. I have considered using ls -t, head -1 and cut to create a version control semantic but the original script file has no version control suffix, and I am expecting to create a Linux variant. So

if [ `unname` -eq 'Linux' ]
# Change the shell interpreter
  cat ${opensshd_script_name} | sed -e "s?\\#\\!/sbin/sh?\\#\\!/bin/sh?g" \\
    >> ${opensshd_script_name}.${script_ver}

This will create a file called However, once you get started, there are so many ways to do this.-

exec_shell=`which sh`

and use ${exec_shell} as the substitution string in the sed command or maybe best of all; this works for all UNIXes without a /sbin/sh, and tightly aligns the implemented execution shell with its existence

if [ ! -x /sbin/sh ]&& [ -x /bin/sh ]
# Change the shell interpreter
  cat ${opensshd_script_name} | sed -e "s?\\#\\!/sbin/sh?\\#\\!/bin/sh?g" \\
    >> ${opensshd_script_name}.${script_ver}

Maybe this is all too complicated, why they've selected /sbin/sh as the execution shell I have no idea, surely all the UNIXes on the port list have a /bin/sh and its guaranteed to be available at run level 1. Perhaps, they should just change the shell interpreter in the rc script source (, and add the chkconfig comment controls at the same time).

I've copied this article to the opensshd developer list, although while I hope they take notice of the shell issue, chkconfig is a Linux thing and hence many other UNIXes will have problems with it. So writing an if Linux test is a bit more complex than I have suggested above and they may feel that this is not a porting issue.





« July 2016