[9fans] CPURC and starting SSH

[9fans] CPURC and starting SSH

[lucio]

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

Re: [9fans] CPURC and starting SSH

[erik quanstrom]

On Sun Apr 28 07:58:26 EDT 2013, lucio@proxima.alt.za wrote:
> 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.

this is not sufficient because listen still syslogs.  /sys/log/listen gets large
in a hurry.  and in any event, i wouldn't want to lose messages.
furthermore, the spinning listens create quite a load on the system.

this test seems to be treating a symptom, not the root cause.
(a more accurate test would be "psu -a | grep 'listen \[tcp' ")
i'm not sure how we could get this situation unless either cpurc
is run twice or the specific startup starts listen itself with a
different directory specified.

so, how to attack the root causes....

since i still use the big case statement style, listen is either
started in one of the specific cases or case *.  either way,
it's started once.  so with the way sources organizes cpurc,
double-start of listen could be avoided by requiring any
/cfg/$sysname/cpurc to start listen itself and adding an
if not case.

	# cpu-specific startup
	if(test -e /cfg/$sysname/cpurc)
		. /cfg/$sysname/cpurc	# must start listen, if desired
	if not{
		aux/listen -q tcp
		# we don't use IL, maybe you do
		aux/listen -q il
	}

(it might be that this should be moved after the ip configuration.)

if you don't like the code duplication perhaps cpurc could define
	fn defaultlisten {
		aux/listen -q tcp
		aux/listen -q il
	}
etc.

to prevent cpurc from being run twice (which users have done!),
i added the following few lines to the beginning of cpurc

	#!/bin/rc

	if(! ~ $#boottime 0 && ! ~ $#sysname 0){
		echo dont run cpurc on $sysname >[1=2]
		exit boofhead
	}

- erik