it's a local issue of instance. That's why it didn't work on bastion1 while it did on bastion 2 and 3. Also from bastion you can already do lot of stuff - tunnel to your sql server, etc.
It's still better than nothing. Or you can debug the situation at least. On Wed, Mar 6, 2013 at 6:58 PM, 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." :-) > > Tim > > > _______________________________________________ > 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
