idallen

I'm fine. How about you?

SpamAssassin uses the .spamkey to tag email that it will dump into your "spam" mailbox. The .gnupg directory contains GNU Privacy key information.

A private IP means that your web hosting account has been given its own IP address on your web host server, and that IP address is not shared with anyone else. It has nothing to do with the IP address you use at home to connect to the Internet. Most web hosting accounts share IP addresses. For example, here on TCH the sites cracow.redo.net and wc3.triton-teamice.com both share the IP address 216.180.243.122 along with many other web sites. A "static IP address" is an IP address that does not change. The term is usually used to describe how your home IP address is assigned. (It has nothing to do with your web host server.) Your home computer can be given an IP address that does not change ("static"), or one that is taken from a pool of IP addresses ("dynamic", usually via DHCP). Servers must have always have static IP addresses, otherwise, you wouldn't know what address to use to connect to them. Most homes don't run servers, so the home address can be dynamic, possibly changing every time you log in to the Internet.

I don't personally know of public resources that will show you how to set up a secure site using a passworded CGI script. (I teach Linux, not CGI!) I would hope that others more familiar with this Web Hosting business might know of something? If not, I can draft something to show you one way of doing it. Let's hope someone already has done this ...

There is no difference between the two links you describe. In both cases, the requesting client uses your server to supply the image. The server that contains the link text is breaking no law in either case. It's not "illegal"; it's just unfriendly.

But the person who makes the link is *not* using the copyrighted image. The link itself isn't copyrighted. (If it were, Google wouldn't be able to save it!) It's the person who browses the web page and downloads the image that is making the copy of the image, based on what the link points to. The link itself is legal. Has anyone been successfully prosecuted for cross-linking images? (I also see the words "illegal input" coming out of computer programs and ask myself if I am really risking a jail term for what I just typed in...)

Is cross-linking illegal? It might be impolite; but, I don't think you can get arrested for it!

If it is your userid that is doing the rewriting of your own files and directories, you don't need to give the files or directories general permissions; you need only grant specific permissions for your own userid. (Grant Unix "user" or "owner" permissions.) Granting yourself write permissions on your own files and directories does not let PHP scripts tamper with them. PHP needs general write permission ("other"-type write permissions in Unix-speak) to change your files or directories. Examples: File mode 644 - you (your userid) can read/write; everyone else (including PHP) can only read. Directory mode 755 - you can read/write/search; everyone else (including PHP) can only read and search. Nothing in your account should have general write permissions.

Note that when I said "directories" (plural), I really did mean *all* directories in the path from the root of the file system to your address file. If *any* of those directories has general write permissions, anyone's PHP (or CGI, or shell) script can rename or remove anything under that directory and replace it with its own stuff. On a shared server, make sure there are no general write permissions anywhere in your account.

Depends what you mean by "safe". If the file is owned by you and has no general write permissions, and all the directories in which it resides are owned by you with no general write permissions, then PHP cannot write the file, rename it, or remove it from the directory. It's safe from writing. If the file has general read permissions, and the directories in which it resides all have at least general execute permissions, PHP can access and read the file. (Execute permissions on a Unix directory means "you can pass through this directory to the files it contains".) But, since PHP can read it, so can *all* PHP scripts written on your server, which might not be what you want if you want the address itself to be kept secret!

But remember that web folder passwords don't protect your data against PHP or CGI scripts running on the same server as you. Web passwords only apply to web browsers, not to scripts that can access your files on the server directly. An effective way to secure information on a shared server is by making the data readable only by you and by writing a passworded CGI script to grant access to it.

You cannot protect any publicly-accessible files that are writable from PHP scripts on cPanel sites. If your PHP script can write these files, anyone on your server can write a PHP script to also write these files (if they know the file names). If the files were created by the PHP script, the files are owned by the web server ("apache"). That means your userid cannot change their permissions. Any PHP script you write to change their permissions can be over-ridden by any other user on your server writing another PHP script to undo what you did. (All PHP scripts have equal permissions.) If the files were created by you and given full write permissions (666) so that your PHP scripts could write them, then anyone else's PHP scripts can also write them. (In fact, with general write permissions, anyone on your server can write the files even using CGI scripts or a login shell account. General write permissions are a Very Bad Idea when you are hosted on a shared server.) No, you cannot securely create a folder with general write permissions (777), let PHP create some files in the folder, then remove the general write permissions (755). The folder is secure; but, the files are not. The files will be owned by the web server, and although only you can remove the files from your protected folder, any PHP script can overwrite them (because the files themselves are owned by the web server). Yes, you can create a file, give it 666 permissions, let a PHP script write it, then you can set it back to 644 permissions to protect it again. That does create only a small "window" of general access. The file must be owned by you; PHP cannot create such a file. (If PHP creates it, you can't change the permissions.) Corollary: Anything your PHP script can access can be accessed the same way by any other PHP script run by anyone sharing your server. So don't even use PHP to *read* sensitive data. NOTE: Unlike PHP, CGI scripts can be made secure. CGI scripts run using the userid of the owner of the script (your userid), not the owner of the web server. Therefore, your CGI scripts can read/write files that only *you* can read/write, and nobody can mess with them but you.

Here's an article at another cPanel site explaining how to do subdomains: http://www.personalsitessupport.org/cgi-bi...=viewnews&id=50

All PHP code runs with the permissions of the userid of the web server, not with your userid's permissions. That means that you must give the web server permission to write in selected places in your account, and files created will be owned by the web server, not by you. The only way to let the web server write in your account using cPanel is to give parts of your account "general" write permissions (permissions for anyone to write), e.g. 666 for files and 777 for directories. The dark side of this is that anyone located on your server running PHP can write or delete those same files using their own PHP scripts, if they know where your files are. All PHP code has the same permissions, no matter where it is located or who runs it.

It works because cPanel sites all define a custom error page at /404.shtml If you supply this page on your site, it will be used. If you don't have a /404.shtml page, you'll see this error: Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

The ErrorDocument is a URL, it's not a Unix pathname. /~user/file is a URL that becomes /home/user/public_html/file when the web server fetches it. /home/user/file is a URL that becomes /usr/local/apache/htdocs/home/user/file (a pathname based in the root of the web server). You can specify any URL, even a URL on another machine...

If you look in the error log for your site you'll find the actual pathname that wasn't found. (In your cPanel, look under Stats.) That will tell you where to put the error document. For example: [sun Jun 15 01:50:47 2003] [error] [client 203.203.132.234] File does not exist: /home/something/public_html/404.shtml You may also have to check the server-wide error log at /usr/local/apache/logs/error_log : [sun Jun 15 01:49:49 2003] [error] [client 66.11.162.123] File does not exist: /usr/local/apache/htdocs/404.shtml I found that this path worked for a file located in /home/idallen/public_html/404.txt : ErrorDocument 404 /~idallen/404.txt

Different names have different cache times. If you asked a server for www.****, that entry gets cached in various name servers. After you changed your domain to point to TCH, using that name again still gets the cached entries. Asking for your domain by a name that wasn't cached, e.g. ****, requires that a fresh query be sent back up the DNS tree to the source. So you get the TCH name for that one.

Some TCH servers run an automatic script every 5 minutes that kills jobs that take more than a certain amount of CPU time. You can ask the sysadmin team to have the indexing script be exempted from the automated kill function. (This has been done on server20.) If you're lucky with your timing, you can start your indexing script just after the last process kill script ran, and this gives you five uninterrupted minutes to get your site indexed before the next time processkill runs. Maybe you can get it done in that time...

You can already do this. Install a .forward file and pipe your email into any script you want.

You can install a .forward file and .procmailrc; but, doing so appears to bypass SpamAssassin. Looks like you either get SpamAssassin *or* you can use a .procmailrc. Pehraps HG can explain how to have the .procmailrc execute after SpamAssassin instead of replacing it?

With all due respect, Canada has more than one city in it (despite what those Toronto snobs might wish to believe). That's 151 Front Street in *Toronto*, Ontario, Canada. You can tell because of the extra snow guards on top of the server racks. :-)

Yea, when you log in to Unix the login process puts your shell into $HOME as you log in. The jailshell chroot mechanism forgets to mimic this behaviour; so, you end up in the new root. If the jailshell were changed to be a script that did "cd $HOME; exec jailshell.real", it might work.

Please remember that we are not asking that the filtering be removed; merely, that those who wish to do so may turn it off. We are not anti-filter; we are pro-choice!

The jailshell has some problems - see here: http://www.totalchoicehosting.com/forums/i...=ST&f=37&t=1870