|
|
| Author |
Message |
| 18 new of 251 responses total. |
krokus
|
|
response 234 of 251:
| 
Mar 15 21:55 UTC 2003 |
The putty screen is still clearing, right after motd. Hence, I can't
ready motd, nor the new mail alert.
|
anderyn
|
|
response 235 of 251:
|
Mar 15 22:05 UTC 2003 |
No mail here today either.
|
gelinas
|
|
response 236 of 251:
|
Mar 16 00:11 UTC 2003 |
krokus, take a look at your termtype. I've seen something like that with
vs100, I think it is. I have to set my xterm's termtype to vt100 when
connecting to grex.
|
gull
|
|
response 237 of 251:
|
Mar 16 00:52 UTC 2003 |
My screen has always cleared after login.
|
remmers
|
|
response 238 of 251:
|
Mar 16 02:52 UTC 2003 |
One could make 'motd' the last line of one's .login or .profile.
|
krokus
|
|
response 239 of 251:
|
Mar 16 03:37 UTC 2003 |
re 236
I can't change the emulation, as such. PuTTY only allows you to change
certain aspects of the intereaction.
re 238
That was something I tried, but motd is displayed by the system, along
with the new mail status, prior to the .login or .profile. (I know,
it can be displayed again.)
|
russ
|
|
response 240 of 251:
|
Mar 16 04:20 UTC 2003 |
Re #234: I believe that some tset or other commands clear the screen;
check your .login file for things you don't need.
|
gull
|
|
response 241 of 251:
|
Mar 16 05:13 UTC 2003 |
I have .hushlogin set to prevent the motd from being displayed during
login. The reason is I have a script in my .profile that diffs the motd
against what it was last time I logged in and displays just the changes.
|
remmers
|
|
response 242 of 251:
|
Mar 16 13:31 UTC 2003 |
By the way, are you aware that the motd displayed by the system
on login, and by the motd command, displays more than just the
contents of the file /etc/motd?
|
gull
|
|
response 243 of 251:
|
Mar 16 17:27 UTC 2003 |
I wasn't. Why is that?
|
carson
|
|
response 244 of 251:
|
Mar 16 19:06 UTC 2003 |
(are you aware that, if using a ssh client, the system does *not*
display more than the contents of /etc/motd?) ;)
|
remmers
|
|
response 245 of 251:
|
Mar 16 21:25 UTC 2003 |
(Yeah, I recently became aware of that. I'm hoping that's
a problem that magically goes away when Grex moves to new
hardware and a modern, well-supported OS.)
Re #243: I imagine it's so that parts of the login message
can be generated automatically without collisions. For
example, the birthday part of the motd is in
/usr/local/lib/motd.birthday. This file is regenerated
daily by a program that scans the birthday database and
selects people whose birthday matches the current date.
It would be unfortunate if the program wrote directly to
/etc/motd at the same time somebody was editing /etc/motd
manually.
|
gull
|
|
response 246 of 251:
|
Mar 17 13:41 UTC 2003 |
For what it's worth, yesterday morning my IDS at work logged what
appeared to be an attempt to exploit the sendmail vulnerability
mentioned earlier in this message. Unfortunately I didn't have full
logging turned on, so I can't say whether it had any shellcode attached
or whether the goal was just to crash sendmail on vulnerable servers.
|
keesan
|
|
response 247 of 251:
|
Mar 17 23:20 UTC 2003 |
I dialed in and was told (twice) Unable to find your tty (ttyu1) in uutmp
file. What does this mean and what stupid thing did I do that caused it?
Bbs works anyway.
|
russ
|
|
response 248 of 251:
|
Mar 19 00:20 UTC 2003 |
Mail still cannot be sent from wwnet.com to Grex.
It appears that Grex is applying an unreasonably strict definition
of what constitutes "legitimate conduct". Shutting off spammers
is one thing; cutting ourselves off from major ISPs is quite another.
|
goose
|
|
response 249 of 251:
|
Mar 21 15:49 UTC 2003 |
The ssh daemon must have died. I can telnet in, but not ssh.
|
jhudson
|
|
response 250 of 251:
|
Mar 21 17:33 UTC 2003 |
$ ps -ax | grep sshd
1045 ? IW 0:05 /usr/local/libexec/sshd
1293 ? S 1:44 /usr/local/libexec/sshd
2212 ? IW 0:04 /usr/local/libexec/sshd
2763 ? IW 0:05 /usr/local/libexec/sshd
3372 ? IW 0:03 /usr/local/libexec/sshd
3569 ? IW 0:02 /usr/local/libexec/sshd
3664 ? IW 0:02 /usr/local/libexec/sshd
3989 ? S 0:05 /usr/local/libexec/sshd
23951 ? S 2:08 /usr/local/libexec/sshd
26686 ? IW 0:26 /usr/local/libexec/sshd
27290 ? IW 0:08 /usr/local/libexec/sshd
27652 ? IW 0:12 /usr/local/libexec/sshd
28254 ? IW 0:21 /usr/local/libexec/sshd
28434 ? S 0:08 /usr/local/libexec/sshd
28706 ? IW 0:09 /usr/local/libexec/sshd
4292 qc S 0:00 grep sshd
$
It is running now.
|
tonster
|
|
response 251 of 251:
|
Mar 22 03:49 UTC 2003 |
resp:250: not necessarily. That output doesn't tell me if the main sshd
daemon is running or not. All of those could very well just be user
sessions, and the main daemon could be dead so no new sessions could
start.
|
