From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <b0b668139a669dfb3bbe1dd82ca28193@proxima.alt.za>
To: 9fans@9fans.net
Date: Sun, 28 Apr 2013 13:57:11 +0200
From: lucio@proxima.alt.za
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] CPURC and starting SSH
Topicbox-Message-UUID: 49920a3e-ead8-11e9-9d60-3106f5b1d025

Unless my copy of /rc/bin/cpurc is out of date, it contains a
self-confessed "dicey check" to ensure that TCP services are not
started twice.  In the list of possible candidates to be checked is
"22" (ssh, of course) which, at least in my case, is started in
/cfg/$sysname/cpurc as it may not be appropriate on all CPU servers.

I believe that "22" ought to be dropped from that list, in my
situation it caused the services not to be started, I assume my
situation is not unique.

A few additional points from my experience:

.	I'm not convinced that the "dicey check" is even necessary: what
	is the worst-case scenario?  That a slew of error messages may
	arise from a second invocation of aux/listen?  I suspect even that
	isn't likely.  If it is, redirecting

		>[2]/dev/null

	would not be a novel idea.

.	Eventually, the documentation starts to make sense, but there are
	a few issues that can be cleared up here: netssh is essential, but
	I'm not sure it belongs in /rc/bin/cpurc, it goes better in
	/cfg/$sysname/cpurc, in my opinion, where it can directly precede

		aux/listen -t /rc/bin/service.auth ssh

	Note the "ssh" that links to "ssh22" as the name of the service
	recommended in the man page.  I have a feeling that this idea is
	not yet cast in stone, but it is interesting.

++L