[9fans] sharing the ndb(6) database

[9fans] sharing the ndb(6) database

[Akshat Kumar]

My new auth server is completely standalone:
it uses the kfs file system and boots off its own
(solid state) disk. The rest of the network, for
which it performs the authentication tasks, is
based on a separate file server node. The auth
server also runs dhcpd, tftpd, and a dns server.
As such, its /lib/ndb/local file contains a
description of the whole network, as well as
dns root stuff.

Now, the rest of the network also needs much
of the same info as the auth server, in order to
easily call each computer by sysname, etc..
This means that when a new node is added to
the Plan 9 network, changes will be needed
to be made in two places: the main network's
/lib/ndb/local and the auth server's /lib/ndb/local.
What's a better way to achieve this? Is there
some method by which the auth server can share
its ndb file(s) with the network? Or should it also
rely on the file server for the root filesystem, and
use local disks only for keyfs, secstore, etc.
databases?

Input and other suggestions welcome.


Thanks,
ak

Re: [9fans] sharing the ndb(6) database

[erik quanstrom]

> Now, the rest of the network also needs much
> of the same info as the auth server, in order to
> easily call each computer by sysname, etc..
> This means that when a new node is added to
> the Plan 9 network, changes will be needed
> to be made in two places: the main network's
> /lib/ndb/local and the auth server's /lib/ndb/local.
> What's a better way to achieve this? Is there
> some method by which the auth server can share
> its ndb file(s) with the network? Or should it also
> rely on the file server for the root filesystem, and
> use local disks only for keyfs, secstore, etc.
> databases?

since the keyfs and secstore databases are encrypted
on disk, i just boot the auth server from the fs and
leave the secstore and keyfs databases on the fs.

perhaps i'm being a bit blithe, but i don't see any
obvious problems with that.

- erik

Re: [9fans] sharing the ndb(6) database

[Akshat Kumar]

Hi Lucio,

Thanks for your message! I tried to reply
to you directly, but got the following
error when I sent you my message:

> Delivery to the following recipient failed permanently:
>
>      lucio@proxima.alt.za
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Rejected: 209.85.160.48 listed at rbl.proxima.alt.za (state 13).
>
> ----- Original message -----
...

I'm using Google mail servers to send
mail - this shouldn't be in the RBL.


Best,
ak

Re: [9fans] sharing the ndb(6) database

[Lucio De Re]

On Mon, Sep 06, 2010 at 11:45:01PM -0700, Akshat Kumar wrote:
>
> I'm using Google mail servers to send
> mail - this shouldn't be in the RBL.
>
Damn right.  The criterion for dumping IP addresses into my private RBL
is that an attempt was made to send mail to a local, unregistered address.
In this case, I have:

/var/tmp/iptrash.err:Registered: o2IFSlFZ009429: - 209.85.160.48 for from=<saxxonenterprisegroup@gmail.com>, -> <carsten@myrtle.proxima.alt.za>...

which is certainly unsolicited as Carsten hasn't been around for years,
and Myrtle has been decommissioned almost equally long ago.

Of course, I have corrected the problem, but I wonder if google should
be alerted.  Can I prevail upon you to confirm that the problem
is cleared?

Lucio.

Re: [9fans] sharing the ndb(6) database

[Lucio De Re]

On Tue, Sep 07, 2010 at 09:09:11AM +0200, Lucio De Re wrote:
> On Mon, Sep 06, 2010 at 11:45:01PM -0700, Akshat Kumar wrote:
> >
> > I'm using Google mail servers to send
> > mail - this shouldn't be in the RBL.
> >
> Damn right.  The criterion for dumping IP addresses into my private RBL
> is that an attempt was made to send mail to a local, unregistered address.

Oops.  I ought to have redirected this to private correspondence.  Apologies.

++L