[9fans] playing with namespaces

[9fans] playing with namespaces

[frank]

Hi,

While setting up a diskless auth (only) server, that boots from a
cpu/file server, I decided to take a closer look at namespaces because
I wanted to keep the cpu/file server functionality separate from the
auth server functionality (i.o.w. share the common stuff, separate the
differences).

More specifically, I decided to move the auth server specific
functionality, which I had initially enabled on the fileserver itself
(e.g. /rc/bin/service.auth/tcp567) to the auth host specific
configuration (/cfg/<sysname-of-diskless-auth-server>).

The first step in doing this, was to setup all auth specific things in
the cpustart script of the auth host:

- I copied /rc/bin/service.auth to /cfg/<authhost>/slash and enabled
  tcp567 and then added a bind -b of that directory to the original
  /rc/bin/service.auth.

- I also moved startup of keyfs, cron and the listeners for
  /rc/bin/service.auth and /rc/bin/service to the cpustart script.

With this, the auth server was separated from the cpu/file server.

Then however, I started to look at netstat -n and ps | grep -i
listen's output and noticed a lot of services, most of which I wanted
to disable (on the auth server only for now).

My first take at it:

- I copied /rc/bin/service to /cfg/<authhost>/slash, disabled most of
  the services and added a bind to replace the original
  /rc/bin/sesrvice directory.

- However, I found out that, even though /rc/bin/service showed those
  services as being disabled, netstat and ps still showed them as
  being enabled.

- A closer look at /rc/bin/cpurc and re-reading man 8 listen indicated
  that those services were actually run as user none and with
  /lib/namespace as default. Thus, in /rc/bin/cpurc, aux/listen is
  executed before cpustart and runs as user none with namespace
  /lib/namespace; changing the namespace in cpustart is too late,
  doing it in cpurc should be ok but proved not to be... No idea why
  not?

My second take at it: I then found out that /lib/namespace sources
/cfg/$sysname/namespace. After adding the bind to disable the startup
of unnecessary services, the output of netstat and ps looked fine.

As this looked much cleaner, I then also moved the bind for
/rc/bin/service.auth to /cfg/<authhost>/namespace but this did not
work. The directory with tcp567 enabled was not bound and so
aux/listen in cpustart did not start the listener on port 567. I tried
to find out where the initial namespace was actually setup and from my
understanding, the sequence is as follows: boot -> init -c ->
namespace -> cpurc so the modified directory (with tcp567 enabled)
should have been visible. What am I missing here?


Kind regards,

--
Frank Lenaerts ---------------------------------------- frank@inua.be

Re: [9fans] playing with namespaces

[erik quanstrom]

> - I copied /rc/bin/service.auth to /cfg/<authhost>/slash and enabled
>   tcp567 and then added a bind -b of that directory to the original
>   /rc/bin/service.auth.

the traditional way of doing this is to create directories
service.$function and/or service.$function.auth and use them
as arguments to listen.  the exact arguments to listen should
depend on $sysname (whaever your cpurc setup).  that way,
you don't have stuff that's mucking with the namespace depending
to much on construction of the namespace.

for example, i start this on the public interface of my auth server
(i knew the fancy new way to do this is with /cfg/$sysname/cpurc, but
you get the point):

...
	switch($sysname){
	...
	case ladd:
		...
		aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service.ext /net.alt/tcp
...

; cd /rc/bin; lc service.ext
!tcp17007	tcp17010		tcp25
tcp17009		tcp17013
; lc service.auth
!il566	tcp22	tcp566	tcp567	tcp993	tcp995

- erik

Re: [9fans] playing with namespaces

[frank]

On Sun, Sep 26, 2010 at 05:41:24PM -0400, erik quanstrom wrote:
> > - I copied /rc/bin/service.auth to /cfg/<authhost>/slash and enabled
> >   tcp567 and then added a bind -b of that directory to the original
> >   /rc/bin/service.auth.
>
> the traditional way of doing this is to create directories
> service.$function and/or service.$function.auth and use them
> as arguments to listen.  the exact arguments to listen should

I see what you mean but I wanted to avoid changing /rc/bin/cpurc so
that it could stay the way it was distributed and updated as if it was
never touched.[*]

In addition to that, I also wanted the play around with namespaces
(hence the subject of the e-mail). All in all, the traditional way of
doing this isn't that different: both have an extra directory
containing the services; in one case, listening is done using that
directory, in the other case, listening is done as usual but with an
"overlay". I have to admit however, that the traditional way of doing
it is cleaner (easier to understand, more transparant).

[*] I haven't yet looked at how pull updates the system.

> depend on $sysname (whaever your cpurc setup).  that way,
> you don't have stuff that's mucking with the namespace depending
> to much on construction of the namespace.

I agree but as I'm trying to understand the mechanisms, the questions
I had still remain:

- Why is it that, when the namespace is changed in
  /cfg/$sysname/cpurc, it does not seem to be taken into account by
  the aux/listen in /rc/bin/cpurc?

- Why can't a modified rc/bin/service.auth not be bound via
  /cfg/$sysname/namespace?

Has it something to do with user none versus user bootes or so?

> - erik

--
Frank Lenaerts ---------------------------------------- frank@inua.be

Re: [9fans] playing with namespaces

[erik quanstrom]

> - Why is it that, when the namespace is changed in
>   /cfg/$sysname/cpurc, it does not seem to be taken into account by
>   the aux/listen in /rc/bin/cpurc?

dynamicly, or on reboot?

> - Why can't a modified rc/bin/service.auth not be bound via
>   /cfg/$sysname/namespace?

$sysname is not set when cpurc is started.

- erik

Re: [9fans] playing with namespaces

[frank]

On Mon, Sep 27, 2010 at 06:16:04PM -0400, erik quanstrom wrote:
> > - Why is it that, when the namespace is changed in
> >   /cfg/$sysname/cpurc, it does not seem to be taken into account by
> >   the aux/listen in /rc/bin/cpurc?
>
> dynamicly, or on reboot?

first reaction: I thought cpurc was only run when booting.

> > - Why can't a modified rc/bin/service.auth not be bound via
> >   /cfg/$sysname/namespace?
>
> $sysname is not set when cpurc is started.

first reaction: It is not set before /rc/bin/cpurc is started, but
/rc/bin/cpurc sets sysname in the very beginning, then possibly
executes /rc/bin/cpurc.local, then possibly executes
/cfg/$sysname/cpurc and then finally, possibly /cfg/$sysname/cpustart.

reading and thinking it over:

Booting: init -> newns -> uses /lib/namespace which also sources
/cfg/$sysname/namespace -> /rc/bin/cpurc -> ...

As $sysname is not yet known at the time, /cfg/$sysname/namespace
cannot be resolved yet (cpurc is not yet involved). Now I also
understand why you asked about "dynamically versus reboot". The lines
containing $sysname in /lib/namespace are there for changes to the
namespace after booting.

The different handling for service.auth and service is due to the fact
that listening for normal services is done as user none and that a new
namespace is created (using /lib/namespace but now $sysname can be
resolved).

This explains why /cfg/$sysname/namespace worked for service and not
for service.auth (no new namespace is created). So, to summarize:

- trusted services: no new namespace is created so cannot be handled
  by a namespace file

- normal services: a new namespace is created so has to be handled by
  a namespace file

Thanks for thinking along with me, even though I didn't do it the
traditional way in the first place (how could I know?). Now that I
understand these things (or at least hope so;-)), it's time to convert
it to the traditional way of doing it.


Kind regards,

> - erik

--
Frank Lenaerts ---------------------------------------- frank@inua.be