Re: [9front] aux/listen changes

[Stanley Lieber <sl@stanleylieber.com>]

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]



> On Apr 18, 2017, at 6:39 PM, Steve Simon <steve@quintile.net> wrote:
> 
> 
>> On 18 Apr 2017, at 21:23, Stanley Lieber <sl@stanleylieber.com> wrote:
>> 
>> 
>> 
>>> On Apr 18, 2017, at 4:12 PM, Kurt H Maier <khm@sciops.net> wrote:
>>> 
>>> As it stands, on an unconfigured 9front:
>>> 
>>> 7/tcp   open  echo
>>> 9/tcp   open  discard
>>> 19/tcp  open  chargen
>>> 21/tcp  open  ftp
>>> 23/tcp  open  telnet
>>> 25/tcp  open  smtp
>>> 53/tcp  open  domain
>>> 110/tcp open  pop3
>>> 113/tcp open  ident
>>> 143/tcp open  imap
>>> 513/tcp open  login
>>> 993/tcp open  imaps
>>> 995/tcp open  pop3s
>>> 
>>> 
>>> this is super grody.
>> 
>> This, too, is still a problem:
>> 
>> http://bugs.9front.org/open/too_many_listeners_with_broken_configurations_are_started_in_rcbinservice/
>> 
>> sl
>> 
> 
> Ah, I am still on the labs distort (sorry) - they used to prefix all the scripts in /rc/bin/service (and /rc/bin/service.auth) with a hash to make it invalid and thus disable that listener. To enable the service
> The administrator then has to rename the entries they want to enable.
> 
> Perhaps that is different on 9 front.
> 
> I agree that listen can get over-excited starting server processes - I used to run many services facing
> The sewer, sorry, internet, and script kiddies could bring listen down by hammering it. I have a distant memory that Erik changed his listen to restrict the number of children (perhaps per service) that it would start.
> 
> -Steve

I think all versions of listen do ignore scripts that begin with the ! character, but what we've been talking about here are two different but related problems:

1. Multiple systems sharing one disk who want to run (or not run) a different mix of services.

2. Tracking a sane default set of enabled services in the Mercurial repository.

Aiju's suggestion solves both.

Of course, it's easy to just disable all services by default (as khm and I have asked in the past: why do we enable services that are broken -- without further configuration -- by default?). The net effect of aiju's suggestion is analogous to the way cpurc sources /cfg/$sysname/cpurc: If nothing more specific is found, devolve to the defaults.

sl


[-- Attachment #2: Type: text/html, Size: 4243 bytes --]