[9fans] CPURC and starting SSH

[l***@proxima.alt.za]

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

[erik quanstrom]

Post by l***@proxima.alt.za
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.
. 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