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

Wed Mar 6 23:13:40 UTC 2013

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?

~Matt Walker
Wikimedia Foundation
Fundraising Technology Team

On Wed, Mar 6, 2013 at 12:00 PM, Petr Bena <benapetr at gmail.com> wrote:

> Okay and that's my point. Problem is only on 1 instance or multiple
> instances but not on all of them. So being able to get into bastion
> alternative way doesn't mean you won't get elsewhere
>
> On Wed, Mar 6, 2013 at 8:58 PM, Ryan Lane <rlane at wikimedia.org> wrote:
> > On Wed, Mar 6, 2013 at 11:50 AM, Petr Bena <benapetr at gmail.com> wrote:
> >>
> >> But I already replied to that once.
> >>
> >> If this problem was affecting all instances - why bastion2 was working
> >> hm? it's a local problem - I don't believe we wouldn't get into other
> >> instances, I was able to ssh to all of them from bastion when my
> >> session was still open while others just couldn't get into bastion
> >>
> >
> > SSH keys are NFS. All NFS access goes to a specific host. Glusterfs has
> an
> > issue where a single client can have issues connecting while others do
> not,
> > but it doesn't really work that way with NFS.
> >
> > - Ryan
> >
> > _______________________________________________
> > Labs-l mailing list
> > Labs-l at lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/labs-l
> >
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/labs-l/attachments/20130306/5d335734/attachment.html>