|
|
| Author |
Message |
| 25 new of 293 responses total. |
jp2
|
|
response 25 of 293:
| 
Dec 27 16:15 UTC 2001 |
This response has been erased.
|
flem
|
|
response 26 of 293:
|
Dec 27 17:50 UTC 2001 |
Grex will snicker at you?
|
mvpel
|
|
response 27 of 293:
|
Dec 27 18:24 UTC 2001 |
I wonder what the issues are? Seems like if you just insert a queue check
after the authentication but before forking the shell, and only fork the shell
after the queue countdown program exits, it would do the trick.
|
gull
|
|
response 28 of 293:
|
Dec 27 19:42 UTC 2001 |
Hmm...would the UseLogin option to sshd help with implementing that? I
only have a vague idea how this works, though.
|
mvpel
|
|
response 29 of 293:
|
Dec 27 20:04 UTC 2001 |
I don't see that UseLogin is supported in the ssh v2 config file. Probably
a ripe target for security holes. However, it would appear that the
"Subsystem" mechanism (used to implement sftp) might be usable in this
respect.
|
mvpel
|
|
response 30 of 293:
|
Dec 28 02:57 UTC 2001 |
The network time protocol service is not working on Grex at the moment, and
the time is off by some 30 seconds into the future.
|
janc
|
|
response 31 of 293:
|
Dec 28 03:17 UTC 2001 |
Re #25: It doesn't use reverse lookup. It knows what IP numbers Grex owns.
|
katie
|
|
response 32 of 293:
|
Dec 28 04:44 UTC 2001 |
A friend of mine is having loads of trouble emailing me because his email
path goes through "pacbell-dot-something." He said grex has a policy of
not receiving email from this server. What's up with that???
|
davel
|
|
response 33 of 293:
|
Dec 28 14:40 UTC 2001 |
You probably should email Marcus about it, Katie. At a guess it's a friendly
home for spam or something of that sort.
|
malymi
|
|
response 34 of 293:
|
Dec 29 18:33 UTC 2001 |
re #14: only if you've been cracked or it's just been rotated. however
for all i know grex logs elsewhere and that file is never larger.
|
davel
|
|
response 35 of 293:
|
Dec 30 01:34 UTC 2001 |
That seems likely, since that file was last updated in 1997.
|
janc
|
|
response 36 of 293:
|
Dec 30 04:00 UTC 2001 |
Yes, /var/log/messages is where that lives.
|
janc
|
|
response 37 of 293:
|
Dec 30 04:09 UTC 2001 |
You already know that Comcast changed all their customer's email addresses,
discontinued usenet news service, discontinued allowing multiple email
addresses, increased prices, and mailed out a CD to all their customers that
"eases the transition" by installing lots of irrelevant software, sticks
Comcast's name all over your desktop, and hoses your system configuration.
For additional fun, they've installed a proxy web server that filters out
Grex. So Comcast customers can not access Grex's web pages now.
Valerie has spent about an hour and half on the phone with them trying to
convince them that there was a problem. She ran out of time and hand to hang
up on the them without success. If anyone more annoying and persistant wants
to call Comcast, that would be OK with us.
|
janc
|
|
response 38 of 293:
|
Dec 30 04:29 UTC 2001 |
Oops, I missed few: Comcast also supplied instruction to their customers
who were paying for static IP addresses for how to "maintain their
connectivity". The instructions reconfigure your computer to use a
dynamic IP. They have a typo in the IP address of one of their two DNS
servers. The correct addresses turn out to both be on the same subnet,
largely nullifying the utility of having two.
In otherwords, the entire new Comcast network was thrown together overnight
by a bunch of people who had barely any idea what they were doing.
|
gelinas
|
|
response 39 of 293:
|
Dec 30 04:35 UTC 2001 |
You think it took them that long?
|
valerie
|
|
response 40 of 293:
|
Dec 30 04:49 UTC 2001 |
This response has been erased.
|
kaplan
|
|
response 41 of 293:
|
Dec 30 14:55 UTC 2001 |
I can telnet to grex but I can't connect to grex's web server via
Comcast's network. Is this because Comcast is blocking only some TCP
ports? Can Grex run another instance of the web server listening on a
different TCP port that's not blocked by Comcast so I could point my web
browser to http://grex.org:2300 or something like that?
|
other
|
|
response 42 of 293:
|
Dec 30 16:25 UTC 2001 |
I spent some time talking with a Comcast tech support guy yesterday, and
here is what came of it:
Comcast tech support were thrown into the this transition with no
specific training in dealing with the current configuration, and a lot of
angry customers.
Comcast's DHCP servers are so overloaded right now that they are not
fully functional, leaving many customers with no connectivity at all. (I
have not been able to use my broadband connection since yesterday
morning.)
I checked out the websites suggested on the back of the "install" CD, and
the support site only gave me a black screen which said "mac is not
supported" while the main website was so heavily dependent on imagemaps
that it would have required an hour just to navigate the site for
information on a dialup connection, assuming they actually have anything
useful on the site at all.
|
remmers
|
|
response 43 of 293:
|
Dec 30 16:35 UTC 2001 |
(Item 39 is dedicated to the current Comcast hassles.)
|
davel
|
|
response 44 of 293:
|
Dec 30 19:16 UTC 2001 |
Item 39 in what conference? 8-{)]
|
remmers
|
|
response 45 of 293:
|
Dec 30 19:32 UTC 2001 |
Oh sorry, didn't notice that this is a linked item. Agora item 39.
|
janc
|
|
response 46 of 293:
|
Dec 30 20:34 UTC 2001 |
Yeah, you can add the fact that Comcast's technical support has recieved no
training about anything to the list of their amazing screwups. My main reaons
for entering my rant here was to explain to people who suddenly can't access
our web site that it ain't our fault. I'm pretty sure the problem lies in
the web proxy servers used by Comcast. The general theory is that they want
to log all your web browsing so they can generate customer profiles to sell
to advertizers. Their end-user-agreement reserves the right to do so.
However, given the general quality of their technology, I think we can count
on them failing to extract any meaningful information from this.
|
gelinas
|
|
response 47 of 293:
|
Dec 31 01:32 UTC 2001 |
Hmm... Wonder if this might be relevant or useful:
} Date: Sun, 30 Dec 2001 20:14:03 -0500
} From: David E. New <den@densbe.com>
} To: gregc@pm-tech.com
} Cc: semislug@semislug.mi.org
} Subject: Re: Reverse DNS.
{Ellipsis. JLG.}
} They have been trying to get Verio, et al, to 'help' them with their
} problems (maybe trying to convince the various web server
} providers to shut off their reverse DNS authentication?),
} but *they* are all on holiday staff, and have no one to
} spare (and I suppose have little sympathy to spare at this
} point, either).
|
gull
|
|
response 48 of 293:
|
Dec 31 14:18 UTC 2001 |
Re #46: I suspect that logging activity is a side benefit, if they plan
to do it at all. The main idea is probably to save on their bandwidth
usage by reducing the amount of web traffic that goes out to the
Internet. I'm guessing Internet bandwidth is probably a significant
part of the cost of running their network.
|
janc
|
|
response 49 of 293:
|
Dec 31 16:18 UTC 2001 |
For Comcast users who want to access Grex's web pages, I've taught Grex to
accept http connections both on port 80 and port 8080. Only port 80 is
blocked by comcast, so Comcast users can access Grex's pages, including
backtalk via 'http://www.grex.org:8080/'. I'm not sure all pages will
work entirely correctly. There could be some links and some images that
don't work on port 8080 (or actually redirect you to port 80). Email reports
to me if you encounter some.
|
