aux/listen changes

aux/listen changes

[Julius Schmidt]

can we finally disable bullshit services in /rc/bin/service?
basically all services except 17019 and 17020 (i think)

i would also propose (as suggested by someone in #cat-v, sorry forgot 
whom) that we look for services in /cfg/$sysname/service first.
i think this is best done by changing cpurc, i.e. do something like

serviced=/rc/bin/service
if(test -d /cfg/$sysname/service)
 	serviced=/cfg/$sysname/service
aux/listen ... -d $serviced ...

this is useful both for server specific configuration but also since 
/rc/bin/service is under version control.

arguably, we could also use /rc/bin/service.$sysname, but i loathe putting 
more configuration under /rc/bin.

Re: [9front] aux/listen changes

[Stanley Lieber]

On Apr 18, 2017, at 11:18 AM, Julius Schmidt <aiju@phicode.de> wrote:
> 
> can we finally disable bullshit services in /rc/bin/service?
> basically all services except 17019 and 17020 (i think)
> 
> i would also propose (as suggested by someone in #cat-v, sorry forgot whom) that we look for services in /cfg/$sysname/service first.
> i think this is best done by changing cpurc, i.e. do something like
> 
> serviced=/rc/bin/service
> if(test -d /cfg/$sysname/service)
>    serviced=/cfg/$sysname/service
> aux/listen ... -d $serviced ...
> 
> this is useful both for server specific configuration but also since /rc/bin/service is under version control.
> 
> arguably, we could also use /rc/bin/service.$sysname, but i loathe putting more configuration under /rc/bin.

All sounds good to me.

sl

Re: [9front] aux/listen changes

[Steve Simon]

> On 18 Apr 2017, at 16:27, Stanley Lieber <sl@stanleylieber.com> wrote:
> 
> On Apr 18, 2017, at 11:18 AM, Julius Schmidt <aiju@phicode.de> wrote:
>> 
>> can we finally disable bullshit services in /rc/bin/service?
>> basically all services except 17019 and 17020 (i think)
>> 
>> i would also propose (as suggested by someone in #cat-v, sorry forgot whom) that we look for services in /cfg/$sysname/service first.
>> i think this is best done by changing cpurc, i.e. do something like
>> 
>> serviced=/rc/bin/service
>> if(test -d /cfg/$sysname/service)
>>   serviced=/cfg/$sysname/service
>> aux/listen ... -d $serviced ...
>> 
>> this is useful both for server specific configuration but also since /rc/bin/service is under version control.
>> 
>> arguably, we could also use /rc/bin/service.$sysname, but i loathe putting more configuration under /rc/bin.
> 
> All sounds good to me.
> 
> sl
> 

Too you really run different services on different servers?
All my cpu servers run the same services, whilst the terminals don’t even run listen.

Plan9 has plenty of problems but /rc/bin/service is not a significant one IMHO.

-Steve

Re: [9front] aux/listen changes

[Kurt H Maier]

On Tue, Apr 18, 2017 at 09:06:26PM +0100, Steve Simon wrote:
> 
> Too you really run different services on different servers?
> All my cpu servers run the same services, whilst the terminals don’t even run listen.
> 
> Plan9 has plenty of problems but /rc/bin/service is not a significant one IMHO.
> 
> -Steve
> 

http://www.jerkcity.com/jerkcity1110.gif

Problems don't need to be significant to be fixed.  Listening on ports
by default is gross and shouldn't happen.  People who want to run
services should set them up.  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.

khm

Re: [9front] aux/listen changes

[Stanley Lieber]

> On Apr 18, 2017, at 4:06 PM, Steve Simon <steve@quintile.net> wrote:
> 
> Too you really run different services on different servers?
> All my cpu servers run the same services, whilst the terminals don’t even run listen.
> 
> Plan9 has plenty of problems but /rc/bin/service is not a significant one IMHO.
> 
> -Steve

Yes, I run different services on several machines that share a disk file system.

Plan 9's best point of separation for integrity of processes is individual kernels. Sometimes you want to isolate stuff that might go nuts or is otherwise unreliable.

Example: crashing my web server (likely) does not cause my e-mail to stop processing.

The point about tracking in the repository is also salient. It makes sense to fall back on sane defaults but also check for site customized alternatives. That's why /cfg exists in the first place. It's a good idea to track (only) the sane defaults in the repository.

sl

Re: [9front] aux/listen changes

[Stanley Lieber]

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



> 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


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

Re: [9front] aux/listen changes

[Steve Simon]

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


> 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 <mailto: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/ <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


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

Re: [9front] aux/listen changes

[Stanley Lieber]

[-- 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 --]

Re: [9front] aux/listen changes

[cinap_lenrek]

> Erik changed his listen to restrict the number of children (perhaps per service)
> that it would start.

i'v done that (too?), implementing process limit flag (-p) for listen and
listen1 in december 2011.

--
cinap