[BlueOnyx:21735] Re: Unable to add vsite after update

[Brian Dowding]

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-bounces at mail.blueonyx.it] On Behalf Of Michael Stauber
Sent: 12 February 2018 16:40
To: blueonyx at 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 at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: AVG Certification.txt
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20180212/ac6f5ec8/attachment.txt>