[Systems] nfs on sunjammer
dfarning at sugarlabs.org
dfarning at sugarlabs.org
Mon Nov 30 14:32:47 EST 2009
On Mon, Nov 30, 2009 at 1:04 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> On Mon, 2009-11-30 at 06:35 -0600, dfarning at sugarlabs.org wrote:
>> I have created a /srv/nfs namespace on sunjammer so we have a central
>> location to put NFS exports. For a.sl.o we need two shares:
>> /srv/nfs/activities/files and
> I did not know that you had already picked another location, so I've
> picked /export for the NFS root, which was the standard on SunOS and
> seems to be still very popular also on Linux.
That makes sense.
> Anyway, it doesn't matter much: if we stick to nfs4 on the clients, the
> prefix on the server does not have to be specified. All we need to do on
> the server is add a bind mount in fstab for each share.
> VERY IMPORTANT: we must make absolutely sure we do not backup the nfs
> shares on the clients. Our system-full-backup script should probably be
> calling duplicity with --exclude-other-filesystems, but this is
> dangerous for machines which happen to have multiple local filesystems
> (like sunjammer).
> The bottom line is that we need to manually tweak the list of paths to
> exclude when we add nfs shares on a machine. And We should add a
> mechanism to change the list in /etc/system-full-backup.conf reather
> than customizing the backup script on every client.
> So, the full procedure for adding an export on sunjammer is:
> * mkdir /export/<share>
> * edit /etc/fstab and add:
> /<original-path> /export/<share> none bind 0 2
> * edit /etc/exports and add:
> /export/<share> <host>.crosslink(rw,nohide,async,no_root_squash,no_subtree_check)
> * edit /etc/hosts in case you need to add <host>.crosslink
> (maybe one day we'll create a DNS zone for these)
> * Perform the bind-mount manually the first time:
> mount /export/<share>
> * Update nfs exports:
> exportfs -av
> SECURITY NOTES:
> - never use public IPs for NFS. It is easy to spoof.
Can you post the private IPs we are using for each machine? We need to go through and make sure that the databases and memcached instatnces are only available via the private ips.
> - no broad exports: only share filesystems with hosts that need them
> - do not export filesystems rw unless really needed
> - don't set no_root_squash, unless really needed
> - always set the nosuid option on the client
>> Imports web node:
>> Both shares need to be imported (RW) to each web-node.
>> - on sunjammer /srv/www-sugar/activities/files
>> - on aslo-web /srv/activities/files
> Ok, I added these under the nfs4 hierarchy on sunjammer.
> Do they have to be rw? (scary)
Yes, web node need to be able to read and write to the file systems
>> Imports download.sl.o:
>> The staging dir will need to be imported read only to the download
>> - on sunjammer staging is imported as /srv/upload/activities.
> Ok, this will be done when we have a separate download server?
> (are we planning to?)
No plans -- no need yet -- just keeping the interfaces clean and consistent so we can think about and work on individual parts.
>> -- each of the nfs shares on sunjammer is set up with a symlink as a
>> place holders.
>> -- There are a few test nfs shares and mounts on aslo-root, these can
>> all be deleted replace with proper mount as stated above.
> I did not touch the client-side.
Ok thanks, I'll wait until you are on IRC
>> If you ping me, I'll try to be on IRC while you work on this.
> I have to run, but I'll be at the fsf shortly.
> // Bernie Innocenti - http://codewiz.org/
> \X/ Sugar Labs - http://sugarlabs.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 271 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/private/systems/attachments/20091130/4aefda55/attachment.pgp
More information about the Systems