|
|
| Author |
Message |
| 25 new of 248 responses total. |
danr
|
|
response 67 of 248:
| 
Oct 13 14:02 UTC 2002 |
Backtalk seems absolutely snappy this morning.
<sarcasm="on>Is there a system problem?<sarcasm="off>
|
rksjr
|
|
response 68 of 248:
|
Oct 13 17:58 UTC 2002 |
Why would there be a delay between one's making revisions in, for
example, the file:
www/test.html
and observing those revisions in the file:
http://www.cyberspace.org/~rksjr/test.html ?
|
jazz
|
|
response 69 of 248:
|
Oct 13 19:50 UTC 2002 |
Website caching somewhere along the line.
Try this:
http://www.cyberspace.org/~rksjr/test.html?this_actually_works
Just don't have a CGI variable named "this_actually_works".
|
gelinas
|
|
response 70 of 248:
|
Oct 13 20:20 UTC 2002 |
Make sure the changes have been written to the file (e.g., with ":w" in vi),
and then force your browser to reload the page.
|
gull
|
|
response 71 of 248:
|
Oct 13 20:34 UTC 2002 |
Note that you have to press Shift while clicking reload to force Netscape to
bypass any caches (including the on-disk one). There's no way I know of to
make IE do this.
|
spankie
|
|
response 72 of 248:
|
Oct 14 03:10 UTC 2002 |
does grex not support ssh2 protocol.////???
|
polytarp
|
|
response 73 of 248:
|
Oct 14 03:27 UTC 2002 |
wow.
|
rksjr
|
|
response 74 of 248:
|
Oct 14 03:46 UTC 2002 |
Re. #69, #70, and #71: Thanks. Informed with your advice I did a Google
search and found a description of how to "reload a Web page whose data has
changed" in my browser of choice, Grex's Lynx, using the Ctrl-R
combination.
|
gull
|
|
response 75 of 248:
|
Oct 14 13:01 UTC 2002 |
Re #72: Nope. Grex has a very ancient version of sshd.
|
albaugh
|
|
response 76 of 248:
|
Oct 21 16:58 UTC 2002 |
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Mon, 21 Oct 2002 11:51:47 -0400
from mwsc0223.mw4.mailwatch.com [204.253.83.164]
----- The following addresses had transient non-fatal errors -----
<someuser@cyberspace.org>
----- Transcript of session follows -----
<someuser@cyberspace.org>... Deferred: Connection timed out with
grex.cyberspace.org.
|
scott
|
|
response 77 of 248:
|
Oct 21 17:41 UTC 2002 |
finger: someuser: no such user.
|
other
|
|
response 78 of 248:
|
Oct 21 17:47 UTC 2002 |
Uptime Report for Grex
Current date and time: Mon Oct 21 13:44:04 EDT 2002
1:44pm up 16 days, 4:19, 65 users, load average: 22.83, 20.20, 17.64
1 waiting, 63 remote + 4 local users; 72 max remote users; 13371 head
|
albaugh
|
|
response 79 of 248:
|
Oct 21 17:48 UTC 2002 |
"someuser" was just a dummy value I edited in (sorry). The real problem was
the connection, not a user. Anyway, seems to be working now...
|
gull
|
|
response 80 of 248:
|
Oct 21 18:58 UTC 2002 |
There's one person I correspond with who cannot send mail to Grex at all
-- it always times out. I suspect, from my own experiences, that the
problem is his ISP firewalls the identd port. When mail connections are
made to Grex, Grex tries to get ident information from the remote host,
and the identd connection takes so long to time out that the sendmail
connection times out as well.
Since very few hosts actually run identd now, and since the information
is so easily forged as to be useless, I'm wondering if it would make
sense for Grex to stop trying to do these lookups. Besides the problem
of hosts that firewall that port being unable to connect, it also adds
overhead to every incoming mail connection, and Grex gets a lot of mail.
|
mdw
|
|
response 81 of 248:
|
Oct 22 01:41 UTC 2002 |
Ident is typically only suported by large timesharing hosts with a
diverse population of users. Since that describes few machines, it's
not surprising that "most" don't do it today. Where it *is* supported,
it's invaluable in terms of tracing e-mail forgeries down. One of those
hosts is grex, and since grex gets a lot of its mail from grex, it would
not make sense for us not collect this information. Besides, the SMTP
timeout value is much larger than the TCP timeout value - and none of
this would have helped Kevin, since it appears he was seeing a TCP
timeout on the initial SMTP, which means the ident protocol was never
involved. Most probably Kevin's failure was some sort of transient
router or network issue - something completely beyond grex's control.
|
russ
|
|
response 82 of 248:
|
Oct 22 03:46 UTC 2002 |
My file transfers with sz keep getting zapped by something. Is
the idle-killer dumb enough to send messages to an active tty
in binary mode?
|
russ
|
|
response 83 of 248:
|
Oct 22 04:20 UTC 2002 |
Yup, seems to be getting nailed about every 15 minutes. Somebody,
please provide a way to shut this idiot thing off...
|
iggy
|
|
response 84 of 248:
|
Oct 22 12:28 UTC 2002 |
*rimshot*
|
gull
|
|
response 85 of 248:
|
Oct 22 12:56 UTC 2002 |
Re #81: Are you sure about the timeout values? My experience indicates
the SMTP connection is not completed if the identd connection doesn't go
through. When I set up a mail system at work about a year ago, it was
unable to send mail to Grex until I unblocked the identd port. I was
completely puzzled by why the connections to Grex, and only Grex, always
timed out until a staffer filled me in on the identd requirement. It
works fine if the host rejects identd connections, but not if it
silently drops the packets.
|
polytarp
|
|
response 86 of 248:
|
Oct 23 00:47 UTC 2002 |
russ should just learn to use FTP.
|
mdw
|
|
response 87 of 248:
|
Oct 23 04:53 UTC 2002 |
I'm guessing that gull got a relatively quick "Connection reset by peer"
and not a slow "Connection timed out". This is one of those cases where
small wording differences in the error message can mean drastically
different things. In fact, grex is likely to work better with firewalls
that silently drop packets than ones that "reject" connections.
Unfortunately, for "reject" some firewalls return ICMP UNREACH messages,
instead of TCP reset (which would be the "expected" behavior if there
were in fact no listener on the port), and grex interprets this to mean
everything on the remote host is now unreachable, rather than just that
one connection. (Granted, there is a icmp subcode that can be used to
further distinguish cause - unfortunately the original bsd tcp/ip code
doesn't check this.) A firewall that rejects ident connections using
TCP reset should work fine with grex, and some are indeed capable of
doing this. Unfortunately, the sort of mentality that blocks ident
connections using a firewall instead of simply not running an ident
service is also the sort that is not likely to understand the difference
between ICMP UNREACH and a TCP reset.
|
gull
|
|
response 88 of 248:
|
Oct 23 14:53 UTC 2002 |
The usual recommended firewall practice is to block everything, then
only enable what you need, instead of trying to block things piecemeal.
I understand the problem with ICMP UNREACH vs. TCP reset, but I don't
have control over how developers choose to implement their firewalls.
Linux iptables, for example, can only respond with ICMP or by silently
dropping the packets. It *is* set to respond with
ICMP-port-unreachable, not ICMP-host-unreachable, by default.
In the case of the mail server I set up, I solved the problem by opening
the identd port specifically, but I don't have the ability to do that on
the mail server of everyone who wants to send me mail. Fortunately only
a minority seem to have this problem, but I expect it'll only get worse.
I also expect fewer and fewer sites will be running identd, since it
leaks information to potential hackers. You can, for example, use it to
determine what userid servers are running as.
|
keesan
|
|
response 89 of 248:
|
Oct 24 01:19 UTC 2002 |
Lynx is not letting me reset my options and save them to disk (I can reset
but it does not stay set despite checking off 'save to disk'). The tab to
next link has never worked and it still redraws the pages up to 5 times, but
reset used to work, I think. I am tired of having labels for images turned
on permanently (bluedot.gif bluedot.gif.....). 2.8.4 version.
|
davel
|
|
response 90 of 248:
|
Oct 29 14:56 UTC 2002 |
Attempts to send mail to Grex are timing out. Grex is up (obviously) and not
entirely off the net - I can telnet in. But attempting to connect to the
sendmail port just hangs until it times out.
Of course, this may be (say) a load-based restriction that will correct itself
eventually, or something like that. Grex feels slow enough to make that seem
all too likely.
|
keesan
|
|
response 91 of 248:
|
Oct 29 17:23 UTC 2002 |
I have not had trouble receiving mail at grex, but I am unable to send to a
particular address since late yesterday. I keep getting back rejected mail
notices. Has something changed at grex, or at their end? I could send
mail to them earlier yesterday.
From MAILER-DAEMON@cyberspace.org Tue Oct 29 12:16:01 2002
Date: Tue, 29 Oct 2002 09:09:24 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@cyberspace.org>
To: keesan@grex.cyberspace.org
Subject: Returned mail: Service unavailable
The original message was received at Tue, 29 Oct 2002 09:09:11 -0500
from keesan@localhost
----- The following addresses had delivery problems -----
<hold@shadow.net> (unrecoverable error)
----- Transcript of session follows -----
... while talking to mail.shadow.net.:
>>> DATA
<<< 552-MessageWall: Message score (1) has reached or exceeded maximum (1):
<<< 552- 1 RFC822/REJECT: keesan@grex.cyberspace.org: Source address must be
in From header <<< 552 MessageWall: This message is being rejected 554
<hold@shadow.net>... Service unavailable
----- Original message follows -----
[ Part 2: "Included Message" ]
Date: Tue, 29 Oct 2002 09:09:07 -0500 (EST)
Lynx also won't accept the command r while viewing the bookmarks file to
remove a line. I have to type e and edit it out instead.
|
