32 new of 251 responses total.
This response has been erased.
It hasn't been patched with the 'official' patch yet, at very least. So it's probably vulnerable. AFAIK there's no working exploit for this on SunOS (or any other OS) yet, not that anyone should be reassured much by that.
Backtalk isn't responding but telnet is working fine.
This response has been erased.
Web server was probably down for some reason.
Incidentally, if you haven't already, you might want to email staff about the sendmail thing. They tend to read email a lot more often than they read this item.
I tried the Backtalk interface today, and could not get the Abelone(sp?) one to work, it just sat there.
They all just sit there for a while. Be patient. This screen took 2min to come up.
This response has been erased.
Re #228: That may not be Grex, it might be your browser (or web proxy server) timing out more quickly than Grex responds.
This response has been erased.
Almost no mail has been delivered today. Something's wrong.
I've gotten a fair amount of mail. About as much as I normally expect, anyway.
Same here.
The putty screen is still clearing, right after motd. Hence, I can't ready motd, nor the new mail alert.
No mail here today either.
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.
My screen has always cleared after login.
One could make 'motd' the last line of one's .login or .profile.
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.)
Re #234: I believe that some tset or other commands clear the screen; check your .login file for things you don't need.
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.
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?
I wasn't. Why is that?
(are you aware that, if using a ssh client, the system does *not* display more than the contents of /etc/motd?) ;)
(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.
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.
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.
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.
The ssh daemon must have died. I can telnet in, but not ssh.
$ 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.
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.
You have several choices: