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 [mailto:blueonyx-boun...@mail.blueonyx.it] On Behalf Of Michael
Stauber
Sent: 12 February 2018 16:40
To: blueonyx@mail.blueonyx.it
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/vsite_create.pl. 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/virtual_host.pl runs before
base/vsite/vsite_create.pl has run.
So it's essentially a timing issue where something
(base/apache/virtual_host.pl) is run earlier than it should have.
CCEd has three stages for handler runs:
- CONFIGURE
- EXECUTE
- CLEANUP
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:
/usr/sausalito/base/vsite/vsite_create.pl
/usr/sausalito/base/apache/virtual_host.pl
Somewhere near the top you will find ...
$DEBUG = "0";
... in both. Change the "0" to "1" in both and save the changes. Then restart
CCEd:
/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/vsite_create.pl runs before
base/apache/virtual_host.pl does.
If debugging is enabled, then the "correct" handler wins the execution lottery
like clockwork.
I'll try to move base/apache/virtual_host.pl 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/virtual_host.pl in another fashion.
--
With best regards
Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
The message does not contain any threats
AVG for MS Exchange Server (2013.0.3556 - 4793/15395)
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
