MikeJ

Not exactly what you are looking for, but the easiest method is to let cPanel do the work for you. You can use something like the script I wrote to cron the cpanel backup that will FTP the entire account backup to a remote server every time it's run. Otherwise, you are basically asking for some rather specific scripts to be written for you.

Oh... and if you want to install other perl modules for MT that aren't installed on the system... the format is basically this... If the module is called Foo::Bar, then you will want to put a file called Bar.pm into the subdirectory extlib/Foo/ under your MT base cgi directory (in many cases you'll have to create the directory).

Ok. Your server doesn't have the Geo::WeatherNWS perl module, so you'll want to install it locally (as it looks like you attempted). Download Geo::WeatherNWS v1.03, pull out the WeatherNWS.pm file, and place it in extlib/Geo/ directory underneath your base MT directory (where mt.cgi is installed). You'll probably need to create the Geo directory. Then you should be good to go.

Btw, if you want to try installing WeatherNWS manually, I looked at the XML of the plugins listings and here's a link that will grab the file from the same place the plugin manager gets it: weathernws.zip ... just put the weathernws.pl file into your plugins directory. I still highly recommend getting the plugin manager, though, because when you find other plugins you want, it's soooo easy to install them then.

Ok, here we go (and using the Plugin Manager won't require you to login to his site to install it). For the most part, you just follow the Plugin Manager. You just need to install XML::Simple perl module for it to work. But to make it simple, here's how to do it... Btw, I setup all MT installations suExec (CGI Wrapper), so that it can write files as the account user. So if you don't run MT suExec'd, there might be more you have to do (particularly permissions). Installing Plugin Manager Download the Plugin Manager from mt-plugins.org. Grab the .tar.gz version. Make a directory somewhere in your account and upload the file to it, and extract the contents. Then, following the author's instructions: Manager.pm should be placed in the extlib/MT/Plugins/ directory (you may need to create this directory). mt-pm.cgi should be placed in the base MT directory (where mt.cgi is located). Make sure it can be executed (e.g. chmod 755). License should be read. tmpl/*.tmpl (all tmpl files) should be placed in the tmpl/plugins/ directory. It will have to be created. tmpl/styles-pm.css needs to be placed in the same directory as styles.css (i.e. the static directory) tmpl/dot.gif needs to be placed in the images/ directory (within your static directory, along with all the other MT images) Now, install the XML::Simple perl module (download from [here] - you may need to right click and save as...). Make sure the file is named Simple.pm, upload it to your account and place it into your extlib/XML/ directory. You should now be able to run it (mt-pm.cgi in your MT directory.) You should click details on a plugin and click check requirements before installing to make sure you have what's needed. But then you can one-click install the plugin. The only issue I haven't had a chance to look into yet is that for some reason the plugin manager keeps showing all the plugins as new plugins all the time, but it doesn't stop it from working (just makes you scroll more). When you get WeatherNWS installed then... if you want to see how I have it setup in my weather block on my weblog, the following is the code including the location code for Chicago (and including an unrelated link for a forecasts page since WeatherNWS doesn't do forecasts). ><MTWeatherNWS place="kmdw"> Location: Chicago, IL ... [ <a href="http://www.crh.noaa.gov/forecasts/ILZ014.php?warncounty=ILC031&city=chicago">Forecast</a> ]<br /> <$MTWeatherConditionstext$>: <$MTWeatherTemperature_f>°F (<$MTWeatherTemperature_c>°C)<br /> Windchill: <$MTWeatherWindchill_f$>°F (<$MTWeatherWindchill_c$>°C)<br /> Wind: <$MTWeatherWinddirtext$> at <$MTWeatherWindspeedmph$> mph (<$MTWeatherWindspeedkph$> kph)<br /> Humidity: <$MTWeatherRelative_humidity$>% <br /> Visibility: <$MTWeatherVisibility_mi$> mi. (<$MTWeatherVisibility_km$> km)<br /> Barometric: <$MTWeatherPressure_inhg$> in (<$MTWeatherPressure_kpa$> kPa)<br /> </MTWeatherNWS>

I do not believe so. I'm pretty certain every user belongs to their own group, not a shared group.

You can control PHP.INI settings in your .htaccess: phpinfo() output before .htaccess addition: >Directive Local Value Master Value magic_quotes_gpc On On After adding php_value magic_quotes_gpc 0 to .htaccess: >Directive Local Value Master Value magic_quotes_gpc Off On I haven't used either CMS so can't help you there. The difference between permissions 707 and 777 is that an account that is a member of the group that owns the file, but is not the owner of the file themselves, would be denied access. I would guess that the recommendation is based on an assumption that all users on a shared host belong to the same group, but all non-users (webserver and other processes) do not belong to that group. The problem with 755 is that if the CMS needs to write files out, it would be attempting to do so as the account the webserver runs as, not as you, unless it's running suExec'd. But since those sound like PHP systems (as opposed to CGI scripts), they likely won't be running under suExec.

Even sending half of a customers information via email is risky. Email is probably one of the least secure methods of transmitting information. It's almost equivalent to sending a postcard through the postal system. Anyone who handles it, or sees it on it's way, can easily read it's contents. I would recommend looking at some way to encrypt the contents if you can since you control the sending and the receiving ends (so can control all the keys). I'm not so certain about encrypted connections to the database, in most cases it's not really necessary unless you are making connections to that database over a public line (like the internet). If you are connecting to the database from the same machine it's on, then your exposure is minimal. There are ways to encrypt fields in a database. However, I'm not a database guru or a real developer to tell you exactly how to do that off the top of my head. But it may be one area to look into. The best way, by far, though, in my opinion, is if your intent is strictly to capture credit card information in order to process an order, and then you don't have any intent of reusing that information, then don't store it at all. There are ways to accept credit card information, pass it on to payment processers, and get a response code for that transaction, and then store that. I know on at least some payment processors you can even get a code back that can be used for automatic repeat billing against that customers credit card without you having to store the credit card information. This would greatly reduce your liability, because that code used to do repeat billing cannot be used in any other transaction (so if someone else got ahold of it, it would be useless to them). Keep in mind, that according to California law now, if your system is compromised (hacked) or you believe it has been compromised, and some of your customers are residents of California, you are required to contact them, or publically announce, that their personal information may have been stolen. Besides the liability issues, that might be some more weight to put on the powers that be to convince them to "get with the times."

TCH has an enforced 50 email per minute sending rate limit, however, that you'll have to be aware of. (I believe that's the limit, I didn't look it up) I haven't administered mailman myself, but I understand.... Mailman does support double-opt in. As far as HTML vs plain, it looks like there's an option to specify MIME or Plain Text if you (a member of the list) are receiving emails in digest mode, but not if you are receiving individual emails. You might be stuck with sending a MIME newsletter with text and HTML. You can have a non-discussion list in mailman by making it a moderated list, and just not approving any emails sent to the list.

Oh...and btw, I don't believe that the interceptvector plugin works anymore. I think that service went offline (I've never seen weather.interceptvector.com up in several months).

I use WeatherNWS on my blog. It works well. It doesn't do forecasts, though. The best thing is to install Plugin Manager, then with one click you can install plugins, instead of downloading them, untarring them, etc... If you're interested, I can give you the directions to install the Plugin Manager. I've done it a few times on TCH so far.

If you reallly want to get an idea of speed, try this little tip: Goto Keynote. Login as demo with the password of demo. Go to Diagnose tab. Enter a URL. Select Instant Measurement. Select an Agent from wherever you want to see the speed. Then select Perform Diagnostic. I just ran one against your site from a Chicago agent and the results: URL http://www.fentermine.info Agent Chicago UUNET DNS Lookup Time * Connection Time 0.04 sec Time To First Byte 0.04 sec Redirection Time * Base Page Download Time 0.1 sec Total Download Time 0.19 sec. Content Error Count No errors Bytes Downloaded 13728 bytes

When you login to cPanel, it should say near the top "Welcome to Server#."

In my line of work... that's when I really get busy, and sleep deprived. It also sucks that holidays and weekends tend to be referred to as "good maintenance periods".

You won't. This type of problem is so rampant, that people are smart enough today to completely ignore the "From:" address when setting up bans (and instead banning based on where the email truly originated from).

It's been years since I've worked on exchange. The main thing to look for is if there's a way to discard double bounces, or better... to just not accept mail that is addressed to an invalid user. (not really a solution, just an area to look, hence I'm not PM'ing you).

I've updated the script to include SSL support. Although not so important if you run the script on the server you are generating the backup (besides, I don't believe the PHP on the TCH servers has SSL support compiled in)... the SSL support would be quite important if you decide to run this script somewhere else to connect to your TCH account. ><?php // PHP script to allow periodic cPanel backups automatically. // Based on script posted by max.hedroom in cpanel.net forums // This script contains passwords. KEEP ACCESS TO THIS FILE SECURE! // ********* THE FOLLOWING ITEMS NEED TO BE CONFIGURED ********* // Info required for cPanel access $cpuser = "username"; // Username used to login to CPanel $cppass = "password"; // Password used to login to CPanel $domain = "example.com"; // Domain name where CPanel is run $skin = "monsoon"; // Set to cPanel skin you use (script won't work if it doesn't match) // Info required for FTP host $ftpuser = "ftpusername"; // Username for FTP account $ftppass = "ftppassword"; // Password for FTP account $ftphost = "ftp.example.com"; // Full hostname or IP address for FTP host $ftpmode = "ftp"; // FTP mode ("ftp" for active, "passiveftp" for passive) // Notification information $notifyemail = "you@example.com"; // Email address to send results // Secure or non-secure mode $secure = 0; // Set to 1 for SSL (requires SSL support), otherwise will use standard HTTP // Set to 1 to have web page result appear in your cron log $debug = 0; // *********** NO CONFIGURATION ITEMS BELOW THIS LINE ********* if ($secure) { $url = "ssl://".$domain; $port = 2083; } else { $url = $domain; $port = 2082; } $socket = fsockopen($url,$port); if (!$socket) { echo "Failed to open socket connection... Bailing out!\n"; exit; } // Encode authentication string $authstr = $cpuser.":".$cppass; $pass = base64_encode($authstr); $params = "dest=$ftpmode&email=$notifyemail&server=$ftphost&user=$ftpuser&pass=$ftppass&submit=Generate Backup"; // Make POST to cPanel fputs($socket,"POST /frontend/".$skin."/backup/dofullbackup.html?".$params." HTTP/1.0\r\n"); fputs($socket,"Host: $domain\r\n"); fputs($socket,"Authorization: Basic $pass\r\n"); fputs($socket,"Connection: Close\r\n"); fputs($socket,"\r\n"); // Grab response even if we don't do anything with it. while (!feof($socket)) { $response = fgets($socket,4096); if ($debug) echo $response; } fclose($socket); ?>

It could be someone else, too, with a virus, spoofing his domain name, in which case setting your default address to :blackhole: will delete any mail that arrives for a user that doesn't exist (since you are getting bounces back to "from" addresses that are faked). But definitely make sure you aren't the one who's infected.

The stories I could tell... Naughty

cPanel itself doesn't have an option to cron individual cPanel accounts. I put this together based on some info I found on cpanel.net and looking at cPanel itself. It works by posting a request to cPanel to run the backup (so it can maintain the same method of backup as cpanel is upgraded). You could actually run this on any machine that has web access to your TCH host and PHP installed, you wouldn't necessarily need to run it on your account. Disclaimers: I wouldn't recommend using this script unless you at least minimally understand what it does. This does contain passwords, so I recommend setting the permissions on this file to 600 and not placing this file within your public_html subdirectories. Use this script at your own risk! To run it as a cron job (at 3:30am like you wanted), put something in your crontab like the following (if the script is in your top directory): >30 3 * * * /usr/local/bin/php /home/youraccount/fullbackup.php Here's the actual script (name it something like fullbackup.php and make sure to set all of the configuration variables). Make sure when you cut and paste it that the $data line remains one line (the if statement is the beginning of the next line). ><deleted> See updated version in new post below.

I'll third that.... I personally have over a dozen domains with godaddy.

iPod: $250-$500 depending on storage capacity (I have the 40GB iPod). I also use the following for use in my Tahoe: Belkin TuneDok Car Holder - $30 (note: won't work for iPod mini) Belkin Auto Charger w/Audio - $40 Sony CPA-9C Car Cassette Adapter - $20 You can find some of the pieces cheaper by using a different or simpler type (like charger without audio and plug audio into iPod itself... just like the the ability to only have to plug in one cable when I hook up since audio is already plugged into charger cable, plus it's cleaner cabling.) It isn't cheap, and won't likely save you money over Sat Radio until you've used it for a couple years, but it has the advantage that you can take it anywhere, and make your own playlists.

You cannot (you don't have the rights to change owners). But if you submit a helpdesk ticket, maybe TCH can.

Apache does run under the user "nobody". You would have to make the directory world writeable to allow an apache process to write to it. The only other option would be running PHP as a CGI that is suExec'd, but I'm not sure that's possible in the TCH configuration (or desired).

Since I've gotten my iPod hooked up in my truck, I've got thousands of songs to make my own radio with no subscription fee. Sorry... I know that doesn't help.