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

Wed Mar 6 19:50:00 UTC 2013

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

On Wed, Mar 6, 2013 at 8:41 PM, Ryan Lane <rlane at wikimedia.org> wrote:
> On Wed, Mar 6, 2013 at 9:58 AM, Tim Landscheidt <tim at tim-landscheidt.de>
> wrote:
>>
>> Petr Bena <benapetr at gmail.com> wrote:
>>
>> > [...]
>>
>> >>> Set up a cron script that sync a local folder on bastion with
>> >>> /public/keys so that when gluster is down or that folder isn't working
>> >>> login to bastion's still works.
>>
>> >> That might be feasible. But really the solution is don't let people
>> >> kill the bastion. idk how we do that. and idk why the past social
>> >> restrictions aren't sufficient. maybe we need ulimit or cgroups or
>> >> something. :-(
>>
>> > it weren't people who kill them it was gluster or something like that
>> > - we need reliable storage for keys if it's only way to login
>>
>> What's the point of allowing people to log into bastion only
>> to find that they can't use their instances due to a gluster
>> error? :-)  Let's rephrase your request: "We need reliable
>> storage." :-)
>>
>
> ^^ This. I don't see the point of arguing about changing authentication to
> fix a storage problem. The real problem here is an unreliable filesystem.
> Let's not make things less secure  to workaround a more serious issue.
>
> - Ryan
>
> _______________________________________________
> Labs-l mailing list
> Labs-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>