From: frank@inua.be
To: 9fans@9fans.net
Subject: [9fans] playing with namespaces
Date: Sun, 26 Sep 2010 23:21:08 +0200 [thread overview]
Message-ID: <20100926212108.GA20262@chiron.galaxy> (raw)
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
next reply other threads:[~2010-09-26 21:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-26 21:21 frank [this message]
2010-09-26 21:41 ` erik quanstrom
2010-09-27 20:33 ` frank
2010-09-27 22:16 ` erik quanstrom
2010-09-28 21:00 ` frank
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=20100926212108.GA20262@chiron.galaxy \
--to=frank@inua.be \
--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).