1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
**********************************************************************
****************** README from reworked UNTAMO ***********************
**********************************************************************
The original Purdue University UNTAMO has been totally reworked, session
limits now work and thresholds do what the manual says.
A large amount of effort was put in with the allocation of variables to
registers, and the logging was reworked. This has resulted in a noticable
speed increase.
The above work was eased by a clean and quite clever design, any future
changes are likely to be just as easy.
More work will need to be done in the future to detect a user relogging in
after a session timeout, as well as a more flexible configuation syntax
at the moment several desirable system limits cannot be enforced.
Craig Bishop
Deakin University
**********************************************************************
**********************************************************************
**********************************************************************
**********************************************************************
******************** README from original UNTAMO *********************
**********************************************************************
Untamo is a locally developed daemon which periodically wakes up and
logs off idle terminals; it also can deal with multiply-logged in
users. It is configurable without recompilation, and features tunable
parameters such as maximum allowed idle time, maximum allowable
multiple logins, exemption lists, and so on.
We use this program to ensure availability of one of our scarcer
resources: terminals. Others may find it useful for different reasons;
preventing users from leaving a terminal logged-in and unattended
for hours is probably a reasonable security measure.
The original posting caused a deluge of mail, as the sources contained
references to local include files. This has been fixed by #ifdef'ing
the code which applies only locally. This version has been successfully
compiled on a Sequent Balance 21000 running Dynix v2.0.6, a CCI 6/32
running 4.3bsd, a DEC VAX-8600 running 4.3bsd, a Gould PowerNode 9080
Running UTX-32 Release 1.3, and and a VAX-11/780 running 4.2bsd.
**********************************************************************
**********************************************************************
**********************************************************************
**********************************************************************
***************** DOC file from original UNTAMO **********************
**********************************************************************
The 'Untamo' Project
Andy Wilcox and Marc Mengel
Purdue University Computing Center
The Purdue University Computing Center needs more machines and
terminals to provide better services to our users. The purchase
of more machines and terminals will come in time. However, ways are needed
now to more evenly distribute our present resources.
The Untamo project is an attempt to solve these and related problems.
There is always a problem at the beginning of the semester with naive
users who turn their terminals off without logging out. Many of these
unfortunate souls will soon be in the consultants office explaining
how their account was booby trapped by a malicious user. Untamo will
decide that a terminal is idle if the keyboard has not been touched
for thirty minutes (this choice of time is under investigation). Untamo
will then log out idle terminals after a warning message has been sent to them.
This will help combat this serious security problem, and save large
amounts of work on the user's part if his or her files were deleted.
Sometimes it is advantageous to have idle terminals, for example, a
Vaxen console. Untamo also provides an 'exemption' feature that allows
such cases.
Late in the semester when final projects are due, there are inevitably
waiting lines for the terminals, and ideally we would prefer one user to
be logged on only once. With job control in c-shell, there is no
need to be logged in more than once. Untamo looks for these multiple logins,
warns each one of them, and then will log out all but the first terminal
to be logged on.
Once again, there are exceptions to the case of multiple logins.
Many times the consultants can log a person in again and fix a hung terminal
by killing a runaway process without having to call the console room.
Untamo allows a few minutes of multiple login time, which is enough time
to locate and kill a runaway process.
Another problem has arisen since the advent of unrestricted terminal access,
namely people staying logged on for long periods of time, and causing huge
queues to build up waiting for ports on busy machines.
We have recorded times in the queue in excess of 2 hours, and have had eight
deep rlogins on ports from people avoiding going back out to the switch.
The apparently neccesary solution to these problems is session limits.
Untamo will now enforce session limits -- after the specified session limit
has expired, the user is given a warning, and soon thereafter logged off.
Similar to idle time, there are terminals and/or people who need to be
logged on indefinitely.
Untamo provides exemptions for session limits to provide for theses situations.
Untamo is also usage sensitive.
It can be configured with a threshold number of users for both multiple login
restriction and session limit enforcement.
This allows Untamo to enforce these policies only when they are needed
(i.e. when ports are scarce), and not at other times.
It is important to note that Untamo will primarily affect our public
terminals. Most other terminals will be 'exempt'.
Untamo is a dynamically reconfigurable program, so if there is a
problem with someone needing more idle time, or a multiple login,
it can be added without killing Untamo, recompiling, reinstalling,
and restarting. These changes take effect in a few minutes, so the
wait is not long.
The amount of time Untamo 'sleeps' between checking logins and idle times
is also redefinable, it can be made larger by the operator on a
heavily loaded machine to allow more time for a multiple login. This
necessary human interaction with Untamo is questionable, and
ways of making the sleep time a function of the
load are being investigated. In any case, the operator always has
final control of Untamo.
**********************************************************************
**********************************************************************
**********************************************************************
|
