[ale] too many logins

[JD]

http://ubuntu-tutorials.com/2009/03/02/automatically-logout-ssh-sessions-after-period-of-inactivity/

or

autolog (never used this)

I'd have weekly reboots at 5am Sundays too, just to cleanup stuff on lab PCs
too. It would be posted on the door, clearly.

You could only allow 1 of the machines to be accessed from outside the lab
subnet, then use that machine to throttle remote connections with a mix of
sshd_config and iptables settings too.  tcp-wrappers will handle limiting on all
the other boxes.

I'm fairly certain there are small holes in these methods, but it should be good
enough for engineering students.

On 11/11/2014 11:55 AM, Todor Fassl wrote:
> Suggestions?
> 
> 
> 
> On 11/11/2014 10:47 AM, JD wrote:
>> Is there a question?
>>
>> On 11/11/2014 11:32 AM, Todor Fassl wrote:
>>> I have a problem in a lab I am responsible for. The lab has 7 debian stable
>>> machines. Students log in to check mail, browse the web, etc. But they
>>> frequently walk away without logging out. Soon enough, the screen saver comes on
>>> and the next person sits down and logs in as another user. Often, the first
>>> person comes back hours late or the next day and logs in a second time. Some of
>>> these machines have the same user logged in 5 or 6 times.
>>>
>>> The problem is that some of these students start matlab, sage, or magma jobs
>>> before they walk away from the workstation. Those are legitimate jobs and should
>>> not be killed.  In fact, sometimes students ssh to these machines and run
>>> computations. It's kind of a bad idea but I'd rather not tell them not to do
>>> that. Otherwise, I'd just have the machines reboot themselves every  night.
>>>
>>> We used to use a tool called timeoutd but it seems to have been removed from the
>>> debian stable and ubuntu archives.  I was never able to get it to work right
>>> anyway. Students would complain that their jobs had been killed or that they
>>> were logged out while they were typing away. At the same time, I could see that
>>> other users were still logged in after days/weeks of inactivity. I am not sure
>>> the problem really was with timeoutd because finger often gave me weird
>>> results.I'm not sure linux was giving timeoutd correct data to work with.
>>>