World: r3wp

why not try using set-net [ email localhost ]

Thanks all. In the end I switched hosts and their mx records work 
so problem solved.

I mentioned the possibility (to overcome REBOL web-hosting) to place 
rebol executable directly in the /cgi-bin/ directory. Someone on 
ML mentioned I should not do that, security wise, as calling http://www.my-domain/cgi-bin/rebol
will spawn a process, which will run endlessly or so ...

I just wanted to ask - wasn't there some change in the past, to prevent 
such case? Would it be sufficient to rename rebol.exe to something 
like EDB433BDD7C13851C7C68CB31A5ACF33A80CD2CC? :-)

Or what about building special rebol version using SDK, running by 
default in cgi mode, quitting imediatelly, if there is not get or 
post string?

My understanding is the latter would be slower.  Also, QM (as an 
example) doesn't generally require a get query or post data (primarily 
uses path info).

petr, it is much better to just put rebol in another dir. there is 
no reason to have it in /cgi-bin/

aha, but can it be dir of my own site?

I mean - let's say I don't have telnet available - just ftp to upload 
my site ...

but even then, putting it in another dir, in order to be able to 
run rebol, I have to set it as runnable too, no? So what is the difference 
in having it in cgi-bin or other directory, if permissions have to 
be equal?

Pekr, well they don't have to. Script's permissons are different 
from some random visitor's permissions. Script is local and not remote.

the scripts have to be in cgi-bin, the interpreter can (and should) 
be somewhere else, where it is not accessible.

Gabriele - where it is not accessible? That means I need other then 
FTP access. That ruins easy REBOL deployment ...

why? ftp access only gives access to cgi-bin? usually, you have your 
own home dir, with www and cgi-bin dirs inside.

I'll check, but with hosting I have I seem to have root set to my 
web root.

So, in terms of my website, if I put rebol executable e.g. into /rebol/rebol.exe, 
is it any different security-wise to /cgi-bin/rebol.exe?

making rebol accessible is a security risk. i don't know of anything 
bad that you can make it do, but i'm sure it would not be too hard 
to make any interpreter do something bad if you allow it to be launched 
by anyone :)

yes, /rebol/rebol.exe will not be executed by the web server, unless 
it is specifically configured to do so.

if it's in cgi-bin, maybe i could do something like http://yoursite/cgi-bin/rebol?-s--do delete... 
etc.

hmm, then ice thing is, that when I run http://www.my-domain.com/cgi-bin/rebol
--do "print 123", Apache returns error, stating I have no permission 
to do that. If I run cgi-bin/rebol, my browser does not seem to return, 
so I expect interpreter to run infinitely?

(it shouldn't be that easy, but you get the idea)

hmm, woult there be an option to prepare special version of interpreter, 
using SDK, not allowing to accept any parameters, run only in CGI 
mode?

maybe, but is it really worth it? i don't think anyone would put 
perl in cgi-bin for eg. so why rebol?

because ppl endlessly complain, there are no rebol web-hosts. So 
I thought I might have universal solutoin. Just find yourself web-host, 
which allows cgi scripts, and you are done ...

I don't need it on my server, was trying to help other guys to not 
feel pressed from ISPs

afaik, any host that allows any cgi-bin will also allow you to upload 
rebol somewhere not in cgi-bin and then use it.

Any ISP that gives you FTP access to your account and CGI does provide

access for rebol

ah, so I really don't understand guys' point on ML, complaining that 
web-hosts are REBOL unfriendly. I tried with two, and those had no 
problem uploading rebol for me ...

What I have found to be a problem is accessing MySQL accounts from 
client based rebol scripts. They seem to only allow server based 
access.

amacleod. And how?

With one host, I e.g. have: /home, /www, /tmp, /logs ... should I 
put into /home?

indeed, i think they are just lazy, and want rebol to work out of 
the box. they just have to upload it. it will work with 99% of the 
hosts right away. and the host should be able to easily solve that 
1% case, unless they are morons and only allow php etc. by policy.

yes, /home, maybe /home/bin or something like that. (/home/rebol/... 
would be ok too)

But other hosting my friend has, is just and only his www root ....

Gabriele - exactly my opinion ....

mysql: some hosts only allow socket access and not tcp access to 
mysql (because that's the default config for some distros.) but, 
that's something that they can enable without problems.

I have a rebol view app that I use to acces a MySQL database. I had 
it working  and then ,y ISP decided to add security and no longer 
allow MySQL access unless its a script on the server. Ofcourse they 
did not inform me and it took some time to track down the problem..

That is why I was trying to suggest to rename rebol to some AAAAAAABBBBBBBCCCC 
name, unpredictable, so it will get hardly noticed, even if someone 
would try ... (unless you do some bug and your shabang line gets 
reported back to browser :-)

www root - well, you can put in www but outside cgi-bin, so it can 
be downloaded but not executed. or, worst case, hopefully they allow 
you to put a .htaccess to deny access to rebol itself.

At least that was the explanation I was given...\

OK, I feel I miss knowledge on Unix permissions. So if cgi-bin dir 
as a whole has execute bit, everything in there can be executed? 
Hmm, and don't I need execute bit for rebol itself, even if put into 
other directory?

it's not execute bit of the dir, and it has not much to do with unix 
permissions, it's web server config. normally, web server will only 
execute things from cgi-bin and not somewhere else.

eg. in apache you have ScriptAlias directive to tell it where to 
allow executables.

aha, ok ... so, if I put REBOL into other dir, even if it has execute 
bit in order to be runnable, Apache will not run it, as directive 
for the directory does not allow that, right?

exactly.

but then it will be probably downloadable :-) www.domain.com/some-other-dir/rebol

but maybe it could be prevented to be seen by setting some .httaccess 
option ...

yes, it will be downloadable unless you deny it with htaccess, but 
that's usually not a big problem.

Petr;  DON'T  :)  Suggesting that people try and sneak REBOL past 
sysadmins is a really really really bad idea.  If they can't be convinced 
to try it, then change ISP, or try to convinvce them again.  Don't 
be making REBOL look all cracky.   That is the kind of maneuver that 
could sink the ship.  The rest of us like the ship, and we fly the 
flag of peace and truth, not the Jolly Roger.  :)