UNIX Shell services, what’s the fuss?

Wowzers, quite a little thread going on in a newsgroup, but really, what’s the big deal?

I think I know…

Not everyone uses the Internet for viewing web pages and downloading pr0nself-help videos and television shows. The Internet itself has become much easier for the layman to use, and with that, these historical services are no longer needed and support for them is harder and harder to come by.

In the past, most service providers (especially the ISPs that service residential users) used to offer some kind of UNIX shell for their paying clientele. Over time, the number of service providers has decreased, and of those that are left, the percentage of them that offer this type of environment has decreased by orders of magnitude. I’ll speculate on why further down this post.

UNIX shells are fascinating experiments in shared computing resources with a very long history.

UNIX shells are not for everyone, but for some of us (me in this case), it is my interface to my email, my day to day work flow, and integral to the operations of ipHouse.

  • I can write scripts that do fancy things, even if my script writing fu is horrendous
  • I can do network diagnosis via a multitude of tools, from simple ping and traceroute to using packet capture diagnostic utilities to figure out a protocol failure
  • I can cruise through email at lightning speed, no mouse makes for both hands on the keyboard
  • I can batch up commands to run in sequence or concurrently to finish whatever task I need done
  • I can use the ever present ‘cron‘ (see reference) facility to run recurring tasks, and I can change my task without changing the cronjob itself (reference scripting above)

UNIX systems make this very easy though the learning curve is quite steep. Yes, I see the oxymoron in the sentence…

Why an experiment? Because it hasn’t finished yet! I don’t think anyone knows what the outcome will be, and who knows, maybe it will never really have an end result. I do know that living within a point and click world slows me down or reduces the number of options I have available to get’r’done. I type faster than I can click all those option boxes!

Today, many of the operators and support staff of service providers no longer have the gumption (or, in many cases, the knowledge) to continue operation of service (and servers) providing UNIX shell access. This is not a bad thing – it is just an observation. The eventual removal of UNIX shell services was posted on the wall long ago and this retirement of service should not surprise anyone.

I don’t blame those service providers who are retiring their UNIX shell account offerings. This kind of operation requires a labor of love, since revenue on offering this service is almost non-existent. ie: unless you want to generate good-will…

With all that said, I hope to have some of this ‘good-will’ (not free, some charge will need to be done, but hopefully pretty nominal) ready to go by the end of the weekend for the refugees who needwant this kind of thing, but with it comes with warnings:

Not officially supported by anyone at ipHouse, can be taken down at any time (with notice), services not guaranteed for any use or usefulness, and abuse will not be tolerated in any fashion.

Normal ipHouse service extras are not included including access to our clustered service offerings and official technical support via email and telephone.

No, it does not mean that this service would be substandard, just that for the price…I just can’t offer the same level of service and support that our normal paying customers receive. Also, the number of people who can support this kind of service is dwindling – read above again if you need to.

The servers themselves (yes, plural) will be maintained and are operating on highly reliable hardware and the data storage will come from the ever present NetApp NFS data storage that we use throughout our infrastructure.

The layout will be simple

  • one Ubuntu Linux (8.04/Hardy LTS) server
  • one FreeBSD 8-STABLE server
  • one server (OS matters not) to receive and process email (no user access)
  • reasonable disk quota (haven’t decided yet)
  • standard developer tool chain
  • mail server itself (see above) will support IMAP/POP3/SMTP including SSL and STARTTLS

Items missing at this time:

  • Web services
  • single password database to rule them all and in the darkness bind them
  • <I am sure something else was missed>

I want to resolve the password database issue immediately before any type of rollout and that will slow things down. Web services are way down the list right now, sorry.

If you have read this and have some interest, drop me email at my work address – you know where to find it…

Thanks!

Comments are closed.