Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

Hi,

Thank you for your answer.


sirjofri  writes:

> Hello,
>
> I don't use /rc/bin/service anymore, but I use /cfg/machinename/service 
> instead. My contents are copies of what's in /rc/bin/service or my own 
> scripts:

I assume that you then bind-mount /cfg/machinename/service to that
machine's /rc/bin/service ?

>
> tcp80 - web server
> tcp443 - web server but wrapped in tls
> ...
>
> I have some cifd running, some irc server that translates to grid chat, my 
> mail
> server (smtp and imap4), and fingerd, the files follow the usual scheme 
> tcpXXX.
> I probably missed one service or the other, but aux/listen is simple enough to
> set up custom servers with arbitrary functionality.
>

Would you mind sharing your fingerd and irc server ? For finger my plan
is to turn this one:
https://github.com/michael-lazar/finger2020/blob/master/finger2020 into
a multi-user version, but if there already is one I won't bother.


> If you have exact questions about aux/listen functionality or you don't 
> understand something, just ask :)
>

- I noticed some tcpXXX files use exec for their last line, and some
don't. Is there a reason ? My understanding is that exec saves one call
to fork per connection, and thus it would be best if it was always used.

- I noticed Inferno makes great use of servers that speak 9P on their
  stdstream, with its
  mount {some-program} /mnt/toto
  These programs are trivial to expose thanks to listen:
   listen -v 'tcp!*!toto' {some-program&}
  On Plan9, I ran into rc's cmd <[0=1] | echo 0 > /srv/name, then mount
  /srv/name /n/toto.
  - Is there a inferno-like shorthand for Plan 9 ?
  - Why the "echo 0" ? (I'm not familiar with rc).

> Btw it's quite common to "deactivate" services by renaming the files to have a
> leading "!". In general, everything that follows the naming scheme
>  and is executable will work.
>
why not just chmod -x them ? In a multiuser system, users may not have
the right to rename them.

Thank you for your help :)

Cheers,

Edouard.

> 
> sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Maa2def04fcfcb1e92523c45d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[sirjofri]

Hi,

05.03.2024 22:38:59 Edouard Klein :

> Hi,
>
> Thank you for your answer.
>
>
> sirjofri  writes:
>
>> Hello,
>>
>> I don't use /rc/bin/service anymore, but I use /cfg/machinename/service 
>> instead. My contents are copies of what's in /rc/bin/service or my own 
>> scripts:
>
> I assume that you then bind-mount /cfg/machinename/service to that
> machine's /rc/bin/service ?

Nope, because bind would only change my own namespace (or I have to bind it 
becore aux/listen starts).

In fact, it's much easier. I don't know if it's a 9front feature or if it's 
also in plan 9, but if there is a /cfg/$sysname/service directory it will use 
that instead of /rc/bin/service (see the cpurc file, 
https://git.9front.org/plan9front/plan9front/36478171be59721dcc5252043fe2955cb37fc9b3/rc/bin/cpurc/f.html
 ).

If you think about how plan 9 should run on a network, imagine a single fs with 
many cpu servers all using the same fs. All the configuration is on the fs, and 
the service directories are in the /cfg/machinename/service. The cpu servers 
will run their individual configuration automatically using that mechanism. It 
just makes sense.

>>
>> tcp80 - web server
>> tcp443 - web server but wrapped in tls
>> ...
>>
>> I have some cifd running, some irc server that translates to grid chat, my 
>> mail
>> server (smtp and imap4), and fingerd, the files follow the usual scheme 
>> tcpXXX.
>> I probably missed one service or the other, but aux/listen is simple enough 
>> to
>> set up custom servers with arbitrary functionality.
>>
>
> Would you mind sharing your fingerd and irc server ? For finger my plan
> is to turn this one:
> https://github.com/michael-lazar/finger2020/blob/master/finger2020 into
> a multi-user version, but if there already is one I won't bother.

Sure, here it is:

https://shithub.us/sirjofri/fingerd/HEAD/info.html

Note that I got some notice of potential .. path issues and I'm not sure if I 
fixed that, but just in case, you might want to fix that (and maybe send me a 
patch). Fix could be as easy as a newns or what it is in C.

>> If you have exact questions about aux/listen functionality or you don't 
>> understand something, just ask :)
>>
>
> - I noticed some tcpXXX files use exec for their last line, and some
> don't. Is there a reason ? My understanding is that exec saves one call
> to fork per connection, and thus it would be best if it was always used.

There might be some difference, maybe with log redirectors or something, but I 
don't know about that. I guess someone else can tell us more about this (and 
the following topic, which is very similar)

> - I noticed Inferno makes great use of servers that speak 9P on their
>   stdstream, with its
>   mount {some-program} /mnt/toto
>   These programs are trivial to expose thanks to listen:
>    listen -v 'tcp!*!toto' {some-program&}
>   On Plan9, I ran into rc's cmd <[0=1] | echo 0 > /srv/name, then mount
>   /srv/name /n/toto.
>   - Is there a inferno-like shorthand for Plan 9 ?
>   - Why the "echo 0" ? (I'm not familiar with rc).
>
>> Btw it's quite common to "deactivate" services by renaming the files to have 
>> a
>> leading "!". In general, everything that follows the naming scheme
>>  and is executable will work.
>>
> why not just chmod -x them ? In a multiuser system, users may not have
> the right to rename them.

I think that _would_ work, but I think it's about readability in this case. I 
can just lc in that directory and immediately see what's relevant and what not. 
With executable flag I have to run ls -l to see what's executable, and it's 
also harder to parse it (sorting and filtering). A simple ! is easier to read, 
and also probably more stable in case of copying files via different filesystem 
types (like, copying the file to fat32 and back, or even having a filesystem 
without executable flags, which often results in all files bein executable).

sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-M1b1379582bb9751cff6ba2ce
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[a]

I wonder what percentage of people who reply are going to be running a finger 
server they wrote. :-) My tcp79 comes from my implementation, here: 
http://txtpunk.com/finger/index.html

I think we've got enough interoperable unicode-aware implementations we can 
start working on the update to the RFC now.

I have a service which allows some unix hosts I run to submit vac scores after 
they perform a backup to my venti; a slightly outdated version is here: 
https://9p.io/sources/contrib/anothy/bin/rc/tcp17038

tcp411 calls pqsrv, I think the same version as on the "extra" page: 
http://9p.io/sources/extra/

I usually have at least one "poor man's nat traversal" thing running with 
aux/trampoline.

I love how easy aux/listen makes sticking trivial little services up on the 
net. I used to have one that provided a menu of MUDs to connect to. Another 
gave the weather, as the telnet service at Weather Underground started to go 
unmaintained (of course, mine used darksky, which is now also defunct). I made 
a little text-based zine server (inspired by Cara Esten's 
https://github.com/caraesten/dial_a_zine, which powered the things at 
anewsession.com); that's up, although very lightly used: 
http://txtpunk.com/zine/ 

Before life got away from me last year, I was trying to get a VoIP bridge 
working so I could plug a POTS line into my modem and get telcodata working 
again. I think 'cp tcp2323 telcodata' should be enough to make that zine server 
dialable. (Sadly, I've only gotten the bridge to *place* calls over my crummy 
DSL line.)

As a young unix sysadmin back in the 1900s, aux/listen was one of the first 
things that caught my eye about Plan 9, in comparison to inetd and the 
direction everyone else was headed from there. Certainly the growth (in 
multiple senses) of systemd has only tightened my grip on that particular tool.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Mb37884661621aa08e1f8449c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[hiro]

all this makes sense. thank you.
i might be dense, but what's the problem with inetd exactly?

On 3/5/24, a...@9srv.net  wrote:
> I wonder what percentage of people who reply are going to be running a
> finger server they wrote. :-) My tcp79 comes from my implementation,
> here: http://txtpunk.com/finger/index.html
> 
> I think we've got enough interoperable unicode-aware implementations we can
> start working on the update to the RFC now.
> 
> I have a service which allows some unix hosts I run to submit vac scores
> after they perform a backup to my venti; a slightly outdated version is
> here: https://9p.io/sources/contrib/anothy/bin/rc/tcp17038
> 
> tcp411 calls pqsrv, I think the same version as on the "extra"
> page: http://9p.io/sources/extra/
> 
> I usually have at least one "poor man's nat traversal" thing running with
> aux/trampoline.
> 
> I love how easy aux/listen makes sticking trivial little services up on the
> net. I used to have one that provided a menu of MUDs to connect to. Another
> gave the weather, as the telnet service at Weather Underground started to go
> unmaintained (of course, mine used darksky, which is now also defunct). I
> made a little text-based zine server (inspired by Cara
> Esten's https://github.com/caraesten/dial_a_zine, which powered the things
> at anewsession.com); that's up, although very lightly
> used: http://txtpunk.com/zine/ 
> 
> Before life got away from me last year, I was trying to get a VoIP bridge
> working so I could plug a POTS line into my modem and get telcodata working
> again. I think 'cp tcp2323 telcodata' should be enough to make that zine
> server dialable. (Sadly, I've only gotten the bridge to *place* calls over
> my crummy DSL line.)
> 
> As a young unix sysadmin back in the 1900s, aux/listen was one of the first
> things that caught my eye about Plan 9, in comparison to inetd and the
> direction everyone else was headed from there. Certainly the growth (in
> multiple senses) of systemd has only tightened my grip on that particular
> tool.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-M32b1f1b0e1eeedd875aee9d9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription