9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: sirjofri <sirjofri+ml-9fans@sirjofri.de>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Content of your /rc/bin/service or /dis/svc ?
Date: Tue, 5 Mar 2024 22:59:28 +0100 (GMT+01:00)	[thread overview]
Message-ID: <8ecb415d-7785-4f49-b209-253def72de30@sirjofri.de> (raw)
In-Reply-To: <878r2w1hsa.fsf@rdklein.fr>

Hi,

05.03.2024 22:38:59 Edouard Klein <edou@rdklein.fr>:

> Hi,
>
> Thank you for your answer.
>
>
> sirjofri <sirjofri+ml-9fans@sirjofri.de> 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
>> <protocol><port> 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

  reply	other threads:[~2024-03-05 21:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-02 10:34 Edouard Klein
2024-03-02 11:54 ` sirjofri
2024-03-05 21:28   ` Edouard Klein
2024-03-05 21:59     ` sirjofri [this message]
2024-03-05 22:47       ` a
2024-03-06  0:53         ` hiro
2024-03-06 11:03           ` Edouard Klein
2024-03-06 10:42         ` Edouard Klein
2024-03-06 11:06         ` Edouard Klein
2024-03-06 10:28       ` Edouard Klein
2024-03-06 12:52         ` sirjofri
2024-03-06 15:12           ` Edouard Klein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8ecb415d-7785-4f49-b209-253def72de30@sirjofri.de \
    --to=sirjofri+ml-9fans@sirjofri.de \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).