bringing down a linux server

we are running build 10 and have raised this issue before but seams its still to easy for users to bring down a complete linux server if controlled by HC.
 
Its still a big issue what important directorys are deletable by the FTP account. Even with the few domains we have moved to HC we often see users that delete all dirs or some of them becasue they think "im just going to clean this a bit" or they delete all because they are getting ready to upload a new site.
 
Down goes apache and cannot be restarted untill You change the config file manually or delete the website in HC (and this also does not always work).
 
There are also the situations where a customer is using HC and trying to do things like doing a redirect or stranger things. This can also easy bring down apache and You have to manually work the server to figure out who did what and fix it.
 
example "website redirect". The user might enter www.conviator.com not the correct http://www.conviator.com - this will bring down apache. You cannot expect the user to know this small but important difference. But HC should know and I would expect a product like HC to do input validation. 
 
this week alone we have had 3 breakdowns of one of the apache servers simply because of user "errors" like this. Every time it takes time to react, find the problem and fix it, easy 30 min. 
It makes us look unprof. and unstable and not at all in sync with the image we want and the prices we charge. And the reason behind - simply because we selected to run HC. Not bad hardware, failure of internet lines, firewalls, performance issues, but simply running HC - not the point of using a controlpanel :)
 
Is this a issue for HC? Working on it? 

agermose

 Its still a big issue what important directorys are deletable by the FTP account. Even with the few domains we have moved to HC we often see users that delete all dirs or some of them becasue they think "im just going to clean this a bit" or they delete all because they are getting ready to upload a new site.

Down goes apache and cannot be restarted untill You change the config file manually or delete the website in HC (and this also does not always work).

There are also the situations where a customer is using HC and trying to do things like doing a redirect or stranger things. This can also easy bring down apache and You have to manually work the server to figure out who did what and fix it.

 

 
If a user removes his www or cgi-bin directory, apache crashes on next rehash/restart because it doesnt find the directory. this why I hate sometime Linux due to 1 line or word crash the whole server. why don't they change configuration like IIS.
I have used directAdmin panel once and from there ftp user can remove their own domain directories as well.
 

dont hate linux because of apaches conf files :)
 
anyway, what Im thinking is that we have a controlpanel, HC, that should go in between the customers and linux/windows - make sure things are setup correct and working. Its not.
 
it could even use apaches own ability to test the config file before reloading :) It does not catch everything but I think all of the issues we have seen would all have been found by simply running a configtest first and then only restart if its reporting no errors - and maybe alerting the admin of the problem if there is an error and not reload. THen you would have ONE customer that would not see his changes but 100s others that would still be running.
 
if you look at the URL redirect issue - its a simply matter of input validation. How can you not have input validation especially when the result is bringing down a server?
 
at least "dont restart/reload if the config is off" - best "fix it and restart". I should not be a big issue to have a small tool that will check the needed structure and recreate. Except of cause for the issue of the config that seams to change a bit from build to build :) Again - it could try and if it cannot figure out what to do then dont reload/restart.
 

agermose

 it could even use apaches own ability to test the config file before reloading :) It does not catch everything but I think all of the issues we have seen would all have been found by simply running a configtest first and then only restart if its reporting no errors - and maybe alerting the admin of the problem if there is an error and not reload. THen you would have ONE customer that would not see his changes but 100s others that would still be running.

 
 
We can't implement check on HC functionality, what if apache status is down and other customers are performing other task. In current case at least HC is not preventing user to perform any action. This could be inconvenience for the customers. In current case apache goes down if user remove the error_log file in the log folder and awstats directory in the /special folder. This could be a suggestion if we move the error-log file from domain.com/log folder to other location which wouldn't be visible to the user. Now if user remove the log /www/db folder it will not crash the apache. But again some customers could raise the question that they need that file to check website error history. Anyway we will collect more info on it from our beta tester and then will finalize it.
 

 
if you look at the URL redirect issue - its a simply matter of input validation. How can you not have input validation especially when the result is bringing down a server?

at least "dont restart/reload if the config is off" - best "fix it and restart". I should not be a big issue to have a small tool that will check the needed structure and recreate. Except of cause for the issue of the config that seams to change a bit from build to build :) Again - it could try and if it cannot figure out what to do then dont reload/restart.

Yes we have noticed this problem at windows panel end there is no restriction to enforce user by using http:// as pre define label, we will escalate this toward concern department for resolution.

:D
 
WELL, "This could be inconvenience for the customers" - what is really inconveniend is when apache does not restart and ALL customers lose uptime because of one customers mistake so thats really a bad argument for not having a check.
 
But in anycase im not really sure I follow your arguments because is what you are saying is true you are also sort of saying you have absolutly no transaction control and protection agenst concurrent updates. Thats how I read what you write. I would not be suprised - just more sad.
You would in any case have to make sure that only one is reading/writing to the conf files. The same mecanisme would of cause also be used to extend to include running a check and possible reload of the config before the next update is going to happen.
 
Anyway (transactions or not, exclusive access or not) what im sugesting is not to prevent users from working and doing updates simply that before a reload/restart simply run the test and only reload/restart if it does not fail the test. All customers will be able to update - maybe just not see the results (in any case they will be able to do absolutly NOTHIGN if the test fails since then you would reload and apache go down so - same difference. But testing before reloading would at least keep the server responding to all other sites until the admin would have had a chance to fix the config problem.
 
so I dont really see any agruments supporting not caring about input validation and test.
 
(and again a small tool to run through the sites and check the needed filestructure is also a possible good investment :)
 
Oh, and about log dirs. Its actually brilliant that the logs (especially error logs) are visible for the customer so better simply check for this and possible recreate than removing this fine feature.