[Labs-l] second attempt to request alternative login server

[Ryan Lane]

On Wed, Mar 6, 2013 at 3:13 PM, Matthew Walker <mwalker at wikimedia.org>wrote:

> I'm not sure if it's worth pursuing under the assumption that storage
> stability will happen in the immediate future, but...
>
> What if, instead of mounting the keys with NFS; we stored the keys
> locally. IE: Distribute them with rsync or what we're considering for
> deployment on the cluster?
>
>
We could do that, but it adds a whole new set of instabilities and also
adds in a giant set of inconsistency. The inconsistency will drive me
insane, as I'll probably end up being the one who needs to debug issues
like: "I can log into the bastion, and to instance A, but can't log into
instance B". We have some issues with this right now, due to folks that
aren't very familiar with Linux/ssh, so agents aren't forwarded, or proxy
command is set up incorrectly. If we start distributing the keys, then
we'll have issues where some nodes updated properly, others didn't, etc.

This is also dangerous from the perspective of security. If a user knows
their key is compromised, it's possible that some instances aren't updating
properly and they are vulnerable for long periods of time.

If we fix the filesystem issues, then none of this matters. A dependable
shared filesystem is a blocker for lots of things. I'd rather focus on
fixing this, than workaround it.

- Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/labs-l/attachments/20130306/9b098eb6/attachment.html>