On Mon, Nov 12, 2012 at 10:54 AM, Oleg Goldshmidt <p...@goldshmidt.org>wrote:
> On Mon, Nov 12, 2012 at 10:40 AM, Elazar Leibovich <elaz...@gmail.com> > wrote: > > > No problem with my scheme, if sshd won't kill old sessions, new sessions > > will... (or maybe I misunderstand you). > > No, I misunderstood you... Sorry. > > Killing existing active sessions in mid-flight seems hairy. You want > to prevent two admins from tweaking the server simultaneously, and the > latecomer may kill the session of the one who is already working, > maybe in the middle of editing a configuration file, moving a bunch of > data, whatever? Is it possible to leave a server in an > unknown/inconsistent state? > Of course, the user should be notified beforehand and decide if he indeed want to kill other session, the killed user should also get a notification on his terminal. (it was just a draft, it's probably not even working, I didn't run it). Joe will see that Moe has a session, and will ask him what he's doing. But he'll never be able to log in simultaneously. Yeah, that policy might force a kill -9 in some rare state (someone left an active session and was sick, now we have to log in and kill his session). But in the long run I think it'll prevent more problems. Hey, this session might have something to do with what you're working on, so if you don't kill it, you might also end up in an inconsistent state. Moreover, you should probably look at at the log before killing this session, and make sure you understand what he was doing. Understanding that from a concurrent log, is a much more difficult job. Enforcing the rule of one-session-at-a-time have benefit in this area as well. You could accomplish that with a read-only user which can log in concurrently.
_______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
