dmohs

Normally I would build this table to make sure my suggestion is accurate, but I have an idea about the problem: I believe you essentially have a problem with parenthesis. Right now, you are saying, "For each customer, get existing TypeA and TypeB proposals." What you should be saying is, "For each customer, get the TypeA proposal if it exists. Then, take the resulting set of customers and TypeAs and get the TypeB proposals if they exist." Use parenthesis to say this to MySQL: SELECT * FROM (Customers LEFT JOIN TypeA ON ..) LEFT JOIN TypeB ON... You get the idea. Let me know if that works. -Dave

You are nearing the end as I also am getting tired of addressing this issue, but until I am satisfied or fed up, I will continue to post. Honestly, I do not care nor even want to know what is happening with the other accounts on my server. I care only that my web site is functioning. If it so happens that my web site's continued presence can be achieved only by shutting down another account, then that is what I want. However, for the particular issue we have been discussing here, there exist a number of solutions that do not require this drastic action. This does not solve my problem. If my intention is to render my web site inaccessible, there are many ways I can achieve this behavior without writing a faulty script. I have chosen to host the site with TotalChoice, rather than host it on my own server, because I want someone who specializes in this area to be in charge. It ceases to be a benefit when those I have enlisted to keep my site running are the same who bring it down. I understand your frustration at having to constantly discuss this issue. As someone who abhors politics, I would certainly not take this route. I would instead write or contract a program to manage the server load for me so that it was never an issue for either my customers or myself. Perhaps you should also consider such a solution.

When you create a new Perl script in Cpanel, the "blank" script contains these lines: >#!/usr/bin/perl use CGI::Carp qw(fatalsToBrowser); That second line will dramatically improve your life. It's like having shell access, except the output is nicely formatted HTML. From the day of discovery, I haven't left that line out of a single script I've created. -David

The following line is suspicious: >if ($output!=~m/$xmms/) Is it your intention to have this if statement be true if "xmms" is not found in the output? If so, it would need to be: >if ($output !~ m/xmms/) The proper syntax for "match if not" is "!~". In the above, $xmms will match the variable $xmms which is not defined as you have presented your script.

As I mentioned earlier, it is my full intention to abide by the rules you have set forth both in the Terms of Service and Acceptable Use Policy, as well as any more that are added without my knowledge. My concern has always been the statement that my site will be suspended without notice if I do not abide perfectly by these rules, even if the infringement is accidental. You and I will both agree that the rules, especially those on server resources, are vague. However, your above post indicates that there is a very good reason behind this. I appreciate your reasoning and agree. So, allow me to highlight what I believe to be the most important thing you said: If you truly adhere to this policy, I can be completely at ease. I would have no problem making a correction to a script (or removing it completely) immediately following a warning. If my account was suspended because I did not heed the warning, I would consider the action to be completely fair. It is the notice that makes all of the difference. Even though I am quite certain TotalChoice will never have reason to terminate my account, I would prefer my first contact be from them, rather than a client who has just lost a days worth of productivity. I am only concerned about the cases where the gray area is larger, or the "abuse" unintentional. I am sure there are cases like this. This needs to be revisited. If you truly ban all scripts of this nature, you will be eliminating approximately 50% of scripts hosted by TotalChoice (50% is conservative. I have been given higher numbers by developers with more experience than myself). Not many web applications can do without this ability. I respect your time, Mr. Kish. You have certainly earned it - TotalChoice is a phenomenal hosting company and a testament to your ability. Rest assured that it has not been wasted by answering my questions. I have spoken privately with two other TotalChoice customers who were concerned with these issues and wanted clarification. Hopefully this topic will provide that for all of us.

I would like to respond to the last post in that topic, by Head Guru. My response follows. I certainly agree. The list is quite clear. What is not clear is the reasoning behind these choices, and therein lies my concern. You see, my "suggestion" was that under the reasoning given behind banning these scripts, almost every program that runs within a shell environment should be banned. If additional scripts are added to this list using the same arbitrary reasoning, I have no way of knowing, short of constant forum polling, that I am running a legal script. If a new script is added, then found on my account, immediate termination would not only disrupt my business, but could also result in a lawsuit by a client using my software to run their own operations. When I want a directory listing in Perl, I sometimes write: >$listing = `ls`; This is a convenient way to get a listing of the current directory's contents. It does so by running the shell command /bin/ls. By the above statement, this technique is not allowed. Am I to remove all instances of this from my programs? I have read both the Terms of Service and the Acceptable Use Policy and have not found a reference to this anywhere. If this is the case, I feel the time required to update all of these scripts would be prohibitive. In addition, since some scripts rely on this type of functionality, I am unsure whether I would be able to reproduce their behavior using another method. This would suggest that if my script were using 10% of the server resources, but the server was busy, my site could be shut down without notice. Since I have no way of knowing the ongoing server load, my only option is to ensure my script never uses more than some fixed amount – perhaps 1%? However, I know of no way to control this number besides using server tools that I do not have permission to run. Can you suggest a strategy for me to follow that will ensure my script will always behave under these guidelines? To summarize my concern, it does me no good to find a web host who has impeccable uptime if I am under the constant risk of having my site shut down. It is my intention to abide by the rules you have set forth in order to ensure this does not happen, but the topic as discussed here seems to suggest that the rules are not well defined and, therefore, impossible to follow.

I just received my support ticket answer. Apparently, TotalChoice cannot support WebDAV because "The installation of such a software may cause serious changes in the settings of webserver and other related services and we cannot allow that." The installation of mod_dav for Apache would indeed change things. However, there are standard ways to ensure this change wouldn't cause problems. Since WebDAV is an extremely useful technology, I hope TotalChoice will consider installing this module as part of the standard Apache package in the future. -Dave

I thought it would be helpful to note that WebDAV is enabled on at least some TotalChoice servers. I just tried it on my own domain and it worked exactly as expected - took about 10 seconds to set up the connection in Windows 2000. Unfortunately, I can only manipulate the root directory. Navigation to any sub-folder fails. I have a friend who tried it with Mac OSX and cannot access it at all. So, it appears there is work to be done. -Dave

While this is one use of a proxy server, it is certainly not the only one. I have seen them used in library systems to allow users to access special materials from home. I've seen them used in secure environments to hold unauthenticated hosts hostage until their credentials could be verified. Really, anytime a user is aided by having a program request pages on their behalf, some sort of proxying is going on. The possible applications are too numerous to list. I would also have to disagree with this statement. An application that listens on a port must still run at the privilege level of the user who executed it. If I were to run a proxy application on a port and allow my application to be completely compromised, providing a shell to the attacker, the attacker would only have enough privileges to wipe out my entire space. The rest of the user space would remain unaffected as long as other users have set up their permissions correctly. If we consider this scenario as "leaving the server vulnerable," then the same argument could be made to stop allowing any CGI programs as well. With the same ease of writing a vulnerable program that listens on a port, I could write a vulnerable program that listens to STDIN (as in CGI). Again, since the CGI program runs as me, the attacker would have complete control over my own space. Disallowing proxies has no effect on TCH's rocking status. Frankly, this hosting company is so competently run that a simple, "because we said so" would be enough for me on many topics. That being said, it is always nice to have a reasonable explanation. You would have a difficult time convincing me that a proxy application puts more load on a server than a CGI script on average, but if this is the reasoning, so be it. -Dave