Thanks Michael, your workaround was successful, though the path to the files to 
edit was slightly different. I've just created 2 vsites.

Best Regards

Brian H. Dowding
Director, Eqwebs Ltd.,
t/a Equestrian Websites

-----Original Message-----
From: Blueonyx [] On Behalf Of Michael 
Sent: 12 February 2018 16:40
Subject: [BlueOnyx:21730] Re: Unable to add vsite after update

Hi Chris, hi Brian,

> I've just tried " yum -y update && shutdown -r now" and it changed 
> nothing as I'm still getting the same error message.

The error "cantEditVhost" has been around for years and I think we've all 
sporadically seen it at one point or another.

About a week or ten days ago I had a box that was persistently throwing it and 
was able to troubleshoot it to some degree by turning on debugging in the 
handlers and restarting CCEd until it went away on its own. Since then I've 
been unable to recreate the failure conditions for a more thorough debugging.

When you create a Vsite via GUI, CMU or "cceclient", then CCE executes the 
command "create Vsite". This triggers various handlers which perform the 
related steps of Vsite creation.

The first handler that needs to run is base/vsite/ That checks 
which siteX-number is free, creates the skeleton directories of the Vsite and 
creates the separate 'VirtualHost' object.

Once that handler has run, additional handlers run that deal with reserving 
email aliases, creating the <VirtualHost>-container for Apache, sorting FTP and 
mailing-lists and what not.

The error "cantEditVhost" happens when base/apache/ runs before 
base/vsite/ has run.

So it's essentially a timing issue where something
(base/apache/ is run earlier than it should have.

CCEd has three stages for handler runs:


Anything that's supposed to run in the "CONFIGURE" stage runs before anything 
from the "EXECUTE" stage and the "EXECUTE" stage happens before the "CLEANUP" 
stage. This allows us to get some order and structure into what should run 
when. There is more to this, as some stages are limited to what actions may be 
performed by a handler, but I'll leave it at that.

Still: If two handlers are in the same stage (and these two are), then it can 
arbitrarily happen that one runs before the other. Like in this case.

Here is a little band-aid that you can try until I have figured out a more 
permanent solution:

Edit the following two files:


Somewhere near the top you will find ...

$DEBUG = "0";

... in both. Change the "0" to "1" in both and save the changes. Then restart 

/usr/sausalito/sbin/cced.init restart

Run a "tail -f /var/log/messages" and then in the GUI hit "Save" to try to 
create the Vsite again. Chances are: It'll now work and in /var/log/messages 
you'll be able to see that base/vsite/ runs before 
base/apache/ does.

If debugging is enabled, then the "correct" handler wins the execution lottery 
like clockwork.

I'll try to move base/apache/ to the EXECUTE stage again (which 
isn't ideal for other reasons) and if that doesn't work I might have to tweak 
the events in the CONFIGURE stage a bit to force a later execution of 
base/apache/ in another fashion.

With best regards

Michael Stauber
Blueonyx mailing list
The message does not contain any threats
AVG for MS Exchange Server (2013.0.3556 - 4793/15395)
Blueonyx mailing list

Reply via email to