Re: [9fans] sharing the ndb(6) database
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: lu...@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
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=saxxonenterprisegr...@gmail.com, - cars...@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
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
Re: [9fans] sharing the ndb(6) database
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
[9fans] sharing the ndb(6) database
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
