|
|
| Author |
Message |
| 25 new of 237 responses total. |
davel
|
|
response 172 of 237:
| 
Aug 27 01:12 UTC 2003 |
I've seen this too, sometimes, recently. Had to give up & dial in later.
|
tod
|
|
response 173 of 237:
|
Aug 27 19:19 UTC 2003 |
This response has been erased.
|
naftee
|
|
response 174 of 237:
|
Aug 29 03:34 UTC 2003 |
re 170 I never noticed, but thanks for pointing it out
|
dah
|
|
response 175 of 237:
|
Aug 29 14:56 UTC 2003 |
polytarp's password has been changed.
|
cmcgee
|
|
response 176 of 237:
|
Aug 29 21:03 UTC 2003 |
sometimes green text showed up on my screen yesterday. Then it went away,
this happened about 4 times, two different sessions.
|
mcnally
|
|
response 177 of 237:
|
Aug 29 21:43 UTC 2003 |
re #176: that's likely because polytarp's conferencing name has been
changed to something which contains terminal-control escape sequences
which select a different font color..
|
dah
|
|
response 178 of 237:
|
Aug 29 21:57 UTC 2003 |
U.p.
|
gull2
|
|
response 179 of 237:
|
Aug 30 02:12 UTC 2003 |
/a is full again. I created another loginid in the hopes I'd get space
on one of the home partitions that doesn't fill up quite so often, but
it stuck that one on /a too. :P
|
rcurl
|
|
response 180 of 237:
|
Aug 30 05:13 UTC 2003 |
I got polytarp's green too. I figured it was his as it showed up
simultaneously with a response from him. What would have been the simplest
online way to neutralize it? I logged off and back in.
|
gelinas
|
|
response 181 of 237:
|
Aug 30 13:07 UTC 2003 |
Hmmm . . . I don't know about 'simplest', but you could set your terminal
software to not execute escape sequences. Unfortunately, I don't know
how to do that; my terminal was not affected by that little . . . joke.
|
russ
|
|
response 182 of 237:
|
Aug 30 14:43 UTC 2003 |
I'm not sure if this is a problem or by design, but when I try
to ftp to Grex to download files, my ssh connection gets dropped
almost instantly.
|
pvn
|
|
response 183 of 237:
|
Aug 31 06:19 UTC 2003 |
Why not use scp in the first place?
|
russ
|
|
response 184 of 237:
|
Aug 31 15:30 UTC 2003 |
I have a problem completely unrelated to the disk-eating assholes:
I'm having a difficult (read: impossible) time trying to transfer
files to and from Grex.
First, FTP seems to be blocked. Hard. Here is the result of
two attempts to log in to Grex; in both cases ftp simply froze
until I hit ^\, no user prompt, no password prompt:
[russ@localhost russ]$ ftp cyberspace.org
Connected to cyberspace.org (216.93.104.34).
Quit
[russ@localhost russ]$ ftp cyberspace.org
Connected to cyberspace.org (216.93.104.34).
Quit
A trial of ftp from ftp.sri.com immediately after this worked fine.
This proves that there is no problem between my keyboard and the
greater Internet; it is a Grex problem. (M-Net doesn't work either,
but it lets me log in and only fails when I try to transfer data.)
Second, I've been trying to tunnel ftp through ssh in order to get
around these blocks. I forwarded port 8021 to Grex port 21, and
got a reward:
[russ@localhost russ]$ ftp
ftp> open localhost 8021
Connected to localhost (127.0.0.1).
220 grex.cyberspace.org FTP server (Version wu-2.6.1-GREX(10) Mon Dec 3
00:09:59 EST 2001) ready. Name (localhost:russ): russ 331 Password required for
russ. Password: 230->>>NO PSYBNC<<< >>>NO EGGDROP<<< NO NO NO!!!!! Won't run
here! 230- [much deleted] 230 User russ logged in. Remote system type is UNIX.
Using binary mode to transfer files. ftp> binary 200 Type set to I. ftp> get
agora.Z.26 local: agora.Z.26 remote: agora.Z.26 227 Entering Passive Mode
(216,93,104,34,247,62) 425 Possible PASV port theft, cannot open data
connection. ftp>
So there you go. I can run a terminal session over TCP/IP, but I can't
pull down copies of my mail or anything else of use. What do I have to
do to get the functionality of a lousy dial-in user?
|
goose
|
|
response 185 of 237:
|
Aug 31 16:11 UTC 2003 |
Dial in? ;-)
|
cross
|
|
response 186 of 237:
|
Aug 31 17:12 UTC 2003 |
This response has been erased.
|
russ
|
|
response 187 of 237:
|
Aug 31 17:46 UTC 2003 |
Interesting. I'd tried scp but got error messages and didn't see
how to relate them to corrective action, so I gave up. Tried just
now and it actually works. It's clunky but I think I can manage.
Thanks!
|
remmers
|
|
response 188 of 237:
|
Aug 31 18:59 UTC 2003 |
The /a partition was full, preventing users whose home directories are
located on it from responding in bbs, saving their mail, and doing anything
else requiring writing data to the disk. I identified the major disk
hogs and did some cleaning up, giving us a bit of breathing room.
|
i
|
|
response 189 of 237:
|
Aug 31 20:11 UTC 2003 |
[Loud cheer for the Grexasaurus from the /a users]
|
rcurl
|
|
response 190 of 237:
|
Aug 31 22:58 UTC 2003 |
I've had no trouble ftp-ing with the client Fetch over TCP/IP.
|
naftee
|
|
response 191 of 237:
|
Sep 2 19:27 UTC 2003 |
re 177 polytarphs account got spalttered?
|
davel
|
|
response 192 of 237:
|
Sep 4 12:49 UTC 2003 |
/a was full a few minutes ago. It's now got a little space, hopefully
enough to let me enter this response without crashing something.
|
asddsa
|
|
response 193 of 237:
|
Sep 7 20:38 UTC 2003 |
Like your brain?
|
keesan
|
|
response 194 of 237:
|
Sep 9 21:53 UTC 2003 |
A friend with an email account at mymailbox.com reports that every mail he
gets from grex (but not my ISP), including my account and jdeigert, arrives
in 4-7 copies. What might be causing this? Other people don't tell me they
get multiple copies of mail from me.
|
keesan
|
|
response 195 of 237:
|
Sep 9 22:17 UTC 2003 |
myrealbox.com not mymailbox.com
|
gelinas
|
|
response 196 of 237:
|
Sep 10 01:59 UTC 2003 |
He should look at the full headers of the copies, to compare the lines that
begin "Received:" The ones at the bottom should be the same in every copy,
but then there will be some that have different time-stamps. Those lines will
show where the transfer is failing.
Most likely, a machine passes it on, but then does not get the acknowledgement
of receipt, so it re-queues the message, to try again later. The machine that
received, but did not acknowledge, the message delivers it. Result: the
message is duplicated when delivery is attempted later.
|
