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 <[email protected]> wrote: > On Wed, Mar 6, 2013 at 9:58 AM, Tim Landscheidt <[email protected]> > wrote: >> >> Petr Bena <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/labs-l > _______________________________________________ Labs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/labs-l
