MikeJ

That IP actually belongs to MXLogic. Are you perhaps using MXLogic anti-spam service for anything, or sending your emails out through your Internet service provider instead of through TCH? Although I find it ironic that one anti-spam service is blacklisting another.

Just pull up a service manual: http://support.dell.com/support/edocs/syst...en/sm/index.htm It includes the instructions for removing and reinstalling the keyboard.

Just to elaborate a little on what was already said... Dedicated IP's are available for the purpose of SSL. Any other request for a dedicated IP will have to go through the help desk to see if it's something TCH will accomodate (but in most cases, the answer will likely be no). As for Movable Type, we don't support the package itself, but we do support users running it. We have numerous Movable Type users on our servers. You are responsible for installing it and configuring it.

My suspicion is that it is your keyboard. And plugging in an external one does NOT disable the onboard keyboard. (I have a Dell XPS Gen2, which is really just a beefy Inspiron).

The author mentioned making it a plug-in at some point, so you may want to bookmark his page at least. Maybe he'll eventually modify it to work via a browser.

On a shared hosting platform with the webserver running as 'nobody', there is really little difference between a world writable directory, and a directory owned by 'nobody', so either method will really provide you almost the same level of security (or lack of it). Just as David stated, use those permissions sparingly.

For starters, this script will only work from a command line, not through as a CGI using a browser to access it, which pretty much rules using this script on your shared hosting account right there. The script would have to be rewritten to make it work in a browser. Secondly... >use Net::MovableType; <---- use File::Basename; use File::Find::Rule::Type; <---- use Term::ReadLine; # Term::ReadLine::Gnu use Image::Magick; use strict; It requires modules (the two above and some supporting modules) that are likely not installed on the TCH servers which is the other reason the script fails. But like I said, it's a command line script, not a brower accessible script, so it won't do you any good even if the modules are installed. You'll be better off finding something that is designed for browser access.

Well, WHT can give you a hard time for just crossing your T's wrong. Glad to hear things are going well for you. Thanks for the review.

Two threads were merged as it was the same discussion.

In mailman, for a moderated list, you should have the following settings (make sure to hit Submit Your Changes after modifying each page): Under General Options, Where are replies to list messages directed? should be set to Poster (so replies go to you, not the list, but some people have a habit of hitting Reply-All, so you need to do the following as well...). Under Privacy options..., and then Sender filters, make sure to set By default, should new list member postings be moderated? to Yes. Then go to Membership Management..., scroll down to the bottom where it says Set everyone's moderation bit, including those members not currently visible, make sure On is selected, and hit Set. Then find yourself in the list, and uncheck the mod column. At that point you should be properly setup for a moderated list. There are additional tweaks you can do if you like, such as autodiscarding messages sent from moderated members of the list, having a response go back to them that tells them their message is held for moderation, etc...

Hi Martin, Which wiki software are you trying to install? In general, what you will need to do is create a database ahead of time through your control panel as well as a userid and password for an user to have access to it, then provide that information to the installation. If the software installation is attempting to "create" this database (instead of just create the tables within a pre-created database), that won't work because you don't have root mysql access. Most software installations these days should allow you to create the database ahead of time. If you provide some information about the wiki package you are trying to install (like it is phpwiki, tikiwiki, etc...) someone with experience with it may be able to provide better information.

Submit a help desk ticket. They'll fix it.

Yea, it is, but it's less annoying than finding out your account was brute forced compromised.

Hey Basil, It's difficult to go through all the code to look for vulnerabilities, especially in something as complex as a content management system like PostNuke. The best thing you can do is make sure the software you use is up to date and trusthworthy. Also monitor for disclosed security vulnerabilies (For example, monitor the products own website). But also keep up to date with any modules you add, and any other software you install. Many of the cases of compromised sites I see are largely due to site owners who don't keep their software up to date. You can also watch your logfiles for suspicious activity (often there will be probes before the actual compromises, sometimes even days before), but unless you have experience going through them, that can be a tedious process. And welcome to the forums.

Typically those are used in environments that have certain kinds of load balancing or content distribution across multiple servers. Basically, they are used more often in some large volume website setups.

>Forbidden You don't have permission to access /images/banner.gif on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Apache/1.3.33 Server at www.475.redlineriders.org Port 80 Folder has the right permissions, images don't. Make sure all of the images have at least 644 permissions.

I've been using 2.0 for a little while, and it's really becoming a nice product. So long MS Office...

Specific cases of blocks or other service problems should be submitted via the help desk instead of the forums. I took a look in the help desk, however, and the account that caused the problem had already been taken care of. It'll just take a little time for AOL's dynamic block to release the address so it should be available by tomorrow.

Valid values for the "dest" parameter are homedir, ftp, ftppassive, and scp. So if you only want to do a local backup, in your modified script set $savedir to homedir (as in $savedir="homedir" literally, not to "/home/stblogs/") and try that (or in my original script, just set $ftpmode to homedir and leave the other $ftp variables blank). If you still have a problem, do a backup manually through your control panel and see if you still are getting backup files not owned by you (and if so, open a help desk ticket). On my own server I'm not able to reproduce that problem.

If you are using serverXX.totalchoicehosting.com/~client/ to preview the sites before changing the DNS, absolute links like that won't work (because accessing the site that way, their public_html is not the document root), but they will work when the domain points to them and they are accessed the regular way via www.yourclientdomain.com. I'm guessing that's the problem you are seeing.

It looks like your redirect that happens when you attempt to access a page that you need to be logged in for (but aren't) is missing the site name info (causing what David sees above as well as the problem with accessing the admin section, at least if you are not logged in). For example: >$ lynx "http://www.kodoclan.com/forums/admin/" Looking up www.kodoclan.com Making HTTP connection to www.kodoclan.com Sending HTTP request. HTTP request sent; waiting for response. HTTP/1.1 302 Found Allowing this cookie. Allowing this cookie. Data transfer complete HTTP/1.1 302 Found Using http:///forums/login.php?redirect=admin/index.php&sid=61ce62fbefc6d6c68cc9b74e6e41663e Looking up Unable to locate remote host . alert!: Unable to connect to remote host. You can see the redirect to the login.php is missing the site name in the URL as David mentioned. This appears to be the case with anything that redirects to the login page. As for how to correct that or where phpBB stores that, I'm not as familiar with phpBB, so maybe someone else who's experienced with phpBB can expand on that... Anyway, Kodo, welcome to the forums from a fellow Kodo rider...

Interesting view on "freedom".

Well, you are also talking about the country that is forcing online gaming companies that host in China to limit online usage to 3-hours at a time (GameSpot Article). As well as one that at least in some areas (according to my brother who lives in China) bans the use of HTTPS protocol (encryption) because they can't monitor it.

Command line curl was indeed disabled because it was being abused by vulnerable scripts just like the other command line programs were. A simple way to continue to use your cron.php file the way it's currently configured (the trial amember has cron.php encoded so I can't even see if it could be modified to work from a command line) is to use php to call the php page. Create a file in your account called something like "runcron.php": >#!/usr/local/bin/php <?php include('http://indiemanagers.com/amember/cron.php'); ?> Make sure the file is executable (permissions 755). Then change your cron job to run "/home/youraccount/runcron.php > /dev/null" (if it's in your top directory, for example). This will give you the same net effect as what you were doing before. We understand it's a little more of a pain to setup, but it's much less exploitable by random scripts searching for vulnerable websites.

In general I would agree with you, but in practice I've sometimes found that not to always be true, possibly due all the factors involved in the processing including the front side bus. For example, a particular CPU intensive game I have hammers my Athlon 3200+ desktop system (2.2Ghz, 512KB L2 Cache, 400Mhz FSB) but performs rather well on my Pentium M 770 (2.13Ghz, 2MB L2 Cache, 533Mhz FSB) laptop (using the same game settings). Now the cache size and the bus speed might give the pentium the edge in this particular application. However, across the board, an equivalent Mhz AMD Athlon XP will outperform the P4. But despite AMD's claim, the performance numbers are probably a bit lower... for example, Tom's Hardware's benchmarks show that an AMD Athlon XP 3200+ compares closer to a 2.8 Ghz P4 (which means a 3000+ would probably be close in performance to the 2.66 you are referring to). Well, the Athlon 64 is a newer 64-bit processor. The P4 3.06 is likely not, unless it's the Prescott 2M core which comes with the EM64T extensions enabled.