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

[Matthew Walker]

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>