<div dir="ltr">On Wed, Mar 6, 2013 at 3:13 PM, Matthew Walker <span dir="ltr"><<a href="mailto:mwalker@wikimedia.org" target="_blank">mwalker@wikimedia.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I'm not sure if it's worth pursuing under the assumption that storage stability will happen in the immediate future, but...</div>

<div><br></div>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?<div>
<br clear="all"></div></blockquote><br></div><div class="gmail_quote">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.<br>

<br></div><div class="gmail_quote">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.<br>

<br></div><div class="gmail_quote">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.<br><br>

</div><div class="gmail_quote">- Ryan<br></div></div></div>