rayners

Locked how? Password access only, or just no Directory Indexes (i.e. list of the files in the directory)?

You might be able to do something with the Mime Types in CPanel. Just associate the application/x-httpd-php type with the html extension.

You mean on the listinfo page for a given mailing list?

You can also setup SquirrelMail manually by editing config/config_default.php and renaming it to config/config.php. The conf.pl script makes it easy, but by no means is it the only way to set things up.

Out of curiousity, has anybody looked into/played with Postnuke? I noticed the latest version of Php-Nuke was possibly going closed source, which gives me the willies just on principle.

A sym link should be fine. Unfortunately, I haven't the slighest idea how to create one through FTP (or CPanel's File Manager). Anybody have a clue how to do that?

I'm glad to hear it.

After looking through some pages at the SquirrelMail site, it appears that some of the newer features in version 1.4 actually require PHP 4.3 or higher. As up-to-date as Head Guru keeps things around here, I don't imagine you have anything to worry about with regards to PHP itself.

That may have been because of the vulnerability in PHP 4.3.0, which has been patched here at TCH.

I recall hearing somewhere that mailing yourself something like that doesn't hold up in court, that it's just an urban myth. But I don't have the time to look up any sources for that, so you'll just have to take my word for it.

It should be displayed in the lower left of your CPanel page under Server Information. And it most likely is: >/usr/bin/perl

It appears to be wonderfully easy with CPanel. From your CPanel page, in the Site Management section, there should be a link to the Index Manager. Select what directory you'd like to protect, and then select "No Indexes" from the list. Voila!

Well, spamd is still part of the whole SpamAssassin package, it just operates a little differently. In looking through the mailer's config on the server I use, it would seem that it uses the spamc/spamd already (if you have activated it through CPanel), so you should be able to just filter based on the X-Spam-Status header without having to run spamassassin beforehand. I'll have to look into the .foward/procmail issue. But you did say it seems that some mail was making it through to procmail? So how have you tested procmail here?

Steps I've taken on the many installs of MT I've made here: Downloaded the MT archive to my home PC Uploaded the archive to my public_html directory Through CPanel's File Manager, clicked on the filename Selected Extract (Unpack?) Archive File (which just extracts the file in the current directory) Renamed the resulting directory (usually MT-Version.Number-etc) to mt/ Edited the mt.cfg in the mt/ directory as needed Off you go! I usually also often create an mt subdomain first, but that's just because I'm too fricken' organized sometimes.

The easiest way to ensure that all the files have the correct permissions is to upload the .tar.gz archive directly to your account here, and then unpack it through CPanel's File Manager. That's how I ended up doing it. Anyways, MT is a wonderful thing.

Well, the example .forward from the SpamAssassin site goes something like this (I don't use a .forward file myself): >"|IFS=' ' && exec /usr/bin/procmail -f- || exit 75 #user" I don't use procmail here, but I do use it and SpamAssassin on my home machine. Oddly enough, after looking though my config files, I can't seem to figure out where SpamAssassin is actually running. I know it's working, because most of the spam I get is routed to my caughtspam folder. I suppose using spamc/spamd instead of spamassassin may have something to do with it. All I've got in my rc.spam is: >:0: * ^X-Spam-Status: Yes caughtspam

I'll have to look into the sending them passwords thing. You could always unsubscribe and resubscribe them, and check the button to send a welcome message along with the subscription. As for docs, head on over to the Mailman homepage.

You need to add the following lines to your mt.cfg file (as you appear to currently not be using MySQL): >ObjectDriver DBI::mysql Database tchusername_databasename DBUser tchusername_dbuser

Ahh. I think I know what might have happened. The default for bulk subscriptions is not to send out Welcome messages, in which the password is included. That would explain that.

Each user is mailed individually with a randomly generated password for their particular address.

I imagine equals requires the block to make an exact match. Matching regex doesn't need to be exact.

What options did you chose for the blocker, and what text did you have it check for?

You might want to either rename that file to .php or the like (so the server will attempt to parse and render it instead of just passing the text of the file back to the browser) or move it to a directory not viewable from the web. Just a thought. Anyways, yeah, I agree. There is no need to be passing passwords around like that. Database users and system/script/whatever users should be seperate entities, at least in my opinion. You have a db user that has enough permissions to do whatever the system needs, and then system users that have their permissions defined and controled within the system, totally seperate from the database.

http://IPNUMBER/~mainaccount/ is the main page for your site. Once you get your DNS change request in, http://yourdomain/ and http://IPNUMBER/~mainaccount/ will point to the exact same place: your public_html directory.

I don't think anybody here would argue against limiting permissions on a database users to only what it needs and nothing more. For the most part, though, any non-homegrown scripts you install will probably need almost all of the permissions available. Invision Board, for example, has a web-based install and admin panel, in addition to the forum itself, therefore it needs create, insert, select, delete, drop, etc. permissions. Out of curiousity, my memory is a little fuzzy about when you started this discussion last time, Paul. Were you uncomfortable putting passwords in your scripts because it gave the script too much acess or that you were concerned that somebody might be able to take a look at the file and get your password out of it? And, I imagine that technically (from the database's perspective) you (i.e. your user) do not actually create the databases and users. I'm guessing CPanel, like Invision Board, is using an account seperate from yours that has full access to the MySQL server so that it can create databases and users. Or am I just babbling a little too much this morning?