🚀 go-pugleaf

In article <33belts1ktp6jaj45vc16l9m86b5qa5acd@4ax.com>
           Trevor@chelsoft.demon.co.uk "Trevor Dumbleton" writes:

> Demon have disabled telnet access to uk-upload (as some of you may
> already have found out).

I would suspect that, since they've disabled TWO different telnet
accesses to their systems, that there's some sort of "security concern"
with their particular telnetd, and that once the necessary patches have
been identified and installed, service will "return to normal".

So I would imagine 24--48h of patience are called for.

[Cross-posted, and follow-ups, to demon.service]
-- 
Brian {Hamilton Kelly}                                          bhk@dsl.co.uk
    "We have gone from a world of concentrated knowledge and wisdom to one of
    distributed ignorance.  And we know and understand less while being incr-
    easingly capable."              Prof. Peter Cochrane, formerly of BT Labs

In article <33belts1ktp6jaj45vc16l9m86b5qa5acd@4ax.com>, Trevor
Dumbleton <Trevor@chelsoft.demon.co.uk> writes

>Demon have disabled telnet access to uk-upload (as some of you may
>already have found out).

it will be restored as soon as a fix for the security problem is
available:

        http://www.securityfocus.com/archive/1/197804

the nature of this particular problem (and the existence of exploitation
code in bad people's hands) means that it would be negligent to leave
telnet enabled

I expect you will find other service providers taking the same attitude
unless they are lucky enough to have an operating system that is not
affected by this.

>We upload large amounts of files and normally these are sent as one
>large zip (to ensure integrity and for ease of uploading) then we
>telnet in and unzip them.
>
>Without telnet access - and with no date set for any resumption of
>telnet access - this is difficult to say the least!
>
>Any (polite) suggestions?
>
>Uploading the files individually isn't an option I want to explore...

you probably need to say more about your platform... there are quite a
lot of automated programs for uploading changed or new files - but no-
one will be able to recommend their favourite if they don't know which
O/S you're running

-- 
richard                       writing to inform and not as company policy

"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

Richard Clayton (richard@highwayman.com) wrote:
: In article <33belts1ktp6jaj45vc16l9m86b5qa5acd@4ax.com>, Trevor
: Dumbleton <Trevor@chelsoft.demon.co.uk> writes

: >We upload large amounts of files and normally these are sent as one
: >large zip (to ensure integrity and for ease of uploading) then we
: >telnet in and unzip them.
: >
: >Without telnet access - and with no date set for any resumption of
: >telnet access - this is difficult to say the least!
: >
: >Any (polite) suggestions?
: >
: >Uploading the files individually isn't an option I want to explore...

: you probably need to say more about your platform... there are quite a
: lot of automated programs for uploading changed or new files - but no-
: one will be able to recommend their favourite if they don't know which
: O/S you're running

I would gladly use "sitecopy", which mirrors local web sites to remote
ones in an efficient and reliable manner, except that I have to munge
the local web pages before uploading to cater for Demon's odd way of
accessing CGI scripts (http://cgi.primagraphics.co.uk/... prepended
before every script reference). I really wish they would change this.

-- 
Andrew Haylett                      Tel. +44 1763 852222 Fax. +44 1763 853324
Senior Software Engineer            Email: ajh@primagraphics.co.uk
Primagraphics, Nr. Cambridge, UK    Web: http://www.primagraphics.co.uk

On 20 Jul 2001 10:19:48 GMT, Andrew Haylett wrote:
>I would gladly use "sitecopy", which mirrors local web sites to remote
>ones in an efficient and reliable manner, except that I have to munge
>the local web pages before uploading to cater for Demon's odd way of
>accessing CGI scripts (http://cgi.primagraphics.co.uk/... prepended
>before every script reference). I really wish they would change this.

This isn't going to happen. In actual fact, you can refer to your CGI's
by any host that resolves to 193.195.0.187.

http://193.195.0.187/cgi-bin/www.primagraphics.co.uk/blah.pl

will work. (Until we change the IP.. which happened recently.)

The reason we do it this way is all the CGI scripts are run on a different
cluster of machines from which HTML is served. There has to be some way of
directing the CGI requests to these different machines, and this is it.


-- 
Chris Elsworth  -  Software & Systems Developer  /  Systems Administrator 
girls = time x money (and time is money)         .       chrise@demon.net
      = money^2 (money is root of all evil)     . .    tel: 020 8371 1041 
      = ( _/(evil) )^2 = evil               t h u s    mob: 07968 324 693

Chris Elsworth (chrise@demon.net) wrote:
: On 20 Jul 2001 10:19:48 GMT, Andrew Haylett wrote:
: >I would gladly use "sitecopy", which mirrors local web sites to remote
: >ones in an efficient and reliable manner, except that I have to munge
: >the local web pages before uploading to cater for Demon's odd way of
: >accessing CGI scripts (http://cgi.primagraphics.co.uk/... prepended
: >before every script reference). I really wish they would change this.

: This isn't going to happen. In actual fact, you can refer to your CGI's
: by any host that resolves to 193.195.0.187.

: http://193.195.0.187/cgi-bin/www.primagraphics.co.uk/blah.pl

: will work. (Until we change the IP.. which happened recently.)

That doesn't help. The problem is that, when I'm doing local testing,
the CGI references are to the local CGI scripts. When the files are
uploaded, all these references have to be to a hard-coded http://..
URL, whether specified as name or IP address.

: The reason we do it this way is all the CGI scripts are run on a different
: cluster of machines from which HTML is served. There has to be some way of
: directing the CGI requests to these different machines, and this is it.

Understood. However, I thought that you did load balancing for non-CGI
accesses, so there must be some front-end for directing such requests
to one of N machines when the request is to a single address, so why
not extend the same mechanism to handle CGI accesses? Of course, I am
not being so presumptuous as to imagine that I'm in a position to
redesign your system with virtually no knowledge of it, just trying to
satisfy my curiosity...

-- 
Andrew Haylett                      Tel. +44 1763 852222 Fax. +44 1763 853324
Senior Software Engineer            Email: ajh@primagraphics.co.uk
Primagraphics, Nr. Cambridge, UK    Web: http://www.primagraphics.co.uk

On 20 Jul 2001 13:39:58 GMT, Andrew Haylett wrote:
>: The reason we do it this way is all the CGI scripts are run on a different
>: cluster of machines from which HTML is served. There has to be some way of
>: directing the CGI requests to these different machines, and this is it.
>
>Understood. However, I thought that you did load balancing for non-CGI
>accesses, so there must be some front-end for directing such requests
>to one of N machines when the request is to a single address, so why
>not extend the same mechanism to handle CGI accesses? Of course, I am
>not being so presumptuous as to imagine that I'm in a position to
>redesign your system with virtually no knowledge of it, just trying to
>satisfy my curiosity...

The load balancers would need a mechanism to differentiate between
HTML and CGI requests. The only way they can do that is by the
destination IP - the load balancers we use don't have the facility to
read packets or anything like that - so there's really no other
alternative.

-- 
Chris Elsworth  -  Software & Systems Developer  /  Systems Administrator 
girls = time x money (and time is money)         .       chrise@demon.net
      = money^2 (money is root of all evil)     . .    tel: 020 8371 1041 
      = ( _/(evil) )^2 = evil               t h u s    mob: 07968 324 693