[BlueOnyx:21727] Unable to add vsite after update

[Brian Dowding]

BlueOnyx 5209R
I am unable to add a vsite since last night's yum update. When adding a site I 
get "cantEditVhost" as an error message. Any quick fix on this?


Best Regards


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


The message does not contain any threats
AVG for MS Exchange Server (2013.0.3556 - 4793/15394)___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

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

[Chris Gebhardt - VIRTBIZ Internet]

Hi Brian,

On 2/12/2018 5:29 AM, Brian Dowding wrote:

BlueOnyx 5209R
I am unable to add a vsite since last night's yum update. When adding a site I get 
"cantEditVhost" as an error message. Any quick fix on this?


Yes, we've seen similar behavior.   You should be able to clear this up 
by ensuring that the system has been fully yum updated and then give it 
a reboot.   Here's one line that will accomplish this for you:

yum -y update && shutdown -r now

That should get it running for you.

--
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

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

[Brian Dowding]

Hi Brian,

On 2/12/2018 5:29 AM, Brian Dowding wrote:
> BlueOnyx 5209R
> I am unable to add a vsite since last night's yum update. When adding a site 
> I get "cantEditVhost" as an error message. Any quick fix on this?

Yes, we've seen similar behavior.   You should be able to clear this up 
by ensuring that the system has been fully yum updated and then give it 
a reboot.   Here's one line that will accomplish this for you:
yum -y update && shutdown -r now

That should get it running for you.

--
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated www.virtbiz.com | toll-free (866) 4 
VIRTBIZ ___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

Hi Chris

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

I was able to add sites yesterday, though I did get the IPV6 message. Today the 
IPV6 message has gone but I can't add sites. The only thing that's changed on 
the server between yesterday and today is the overnight automatic yum update, 
so I'm assuming there's a problem with that.


Best Regards


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


The message does not contain any threats
AVG for MS Exchange Server (2013.0.3556 - 4793/15394)___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

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

[Michael Stauber]

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 -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

[BlueOnyx:21731] Broken mailman since last yum

[Chris Gebhardt - VIRTBIZ Internet]

Not sure that there is anything particularly related to Mailman in the 
most recent updates, but since Saturday we have a site that is unable to 
use their Mailman install.  Upon logging in to administer a list, the 
following output goes to browser:

Bug in Mailman version 2.1.15

We're sorry, we hit a bug!

Please inform the webmaster for this site of this problem. Printing of 
traceback and other system information has been explicitly inhibited, 
but the webmaster can find this information in the Mailman error logs.


The Mailman error log (snipped below) seems to reference a permissions 
issue.   Changing the directory permissions on /var/lock/mailman to 777 
alleviates the error, but that seems like it could be a bit of a 
security issue.


Thoughts?


Feb 12 12:59:58 2018 admin(21407): 


admin(21407): [- Mailman Version: 2.1.15 -]
admin(21407): [- Traceback --]
admin(21407): Traceback (most recent call last):
admin(21407):   File "/usr/lib/mailman/scripts/driver", line 112, in 
run_main

admin(21407): main()
admin(21407):   File "/usr/lib/mailman/Mailman/Cgi/admindb.py", line 
167, in main

admin(21407): mlist.Lock()
admin(21407):   File "/usr/lib/mailman/Mailman/MailList.py", line 161, 
in Lock

admin(21407): self.__lock.lock(timeout)
admin(21407):   File "/usr/lib/mailman/Mailman/LockFile.py", line 243, 
in lock

admin(21407): self.__write()
admin(21407):   File "/usr/lib/mailman/Mailman/LockFile.py", line 422, 
in __write

admin(21407): fp = open(self.__tmpfname, 'w')
admin(21407): IOError: [Errno 13] Permission denied: 
'/var/lock/mailman/broadcast.lock.5209r.21407.0'

admin(21407): [- Python Information -]
admin(21407): sys.version =   2.7.5 (default, Nov  6 2016, 00:28:07)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)]
admin(21407): sys.executable  =   /usr/bin/python
admin(21407): sys.prefix  =   /usr
admin(21407): sys.exec_prefix =   /usr
admin(21407): sys.path=   ['/usr/lib/mailman/pythonlib', 
'/usr/lib/mailman', '/usr/lib/mailman/scripts', '/usr/lib/mailman', 
'/usr/lib64/python27.zip', '/usr/lib64/python2.7/', 
'/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', 
'/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', 
'/usr/lib/python2.7/site-packages']

admin(21407): sys.platform=   linux2
admin(21407): [- Environment Variables -]
admin(21407):   HTTP_REFERER: 
https://lists.radiolists.net/mailman/admindb/broadcast

admin(21407):   CONTEXT_DOCUMENT_ROOT: /usr/lib/mailman/cgi-bin/
admin(21407):   SERVER_SOFTWARE: Apache
admin(21407):   CONTEXT_PREFIX: /mailman/
admin(21407):   SERVER_SIGNATURE:
admin(21407):   REQUEST_METHOD: POST
admin(21407):   PATH_INFO: /broadcast
admin(21407):   SERVER_PROTOCOL: HTTP/1.1
admin(21407):   QUERY_STRING:
admin(21407):   SSL_TLS_SNI: lists.radiolists.net
admin(21407):   CONTENT_LENGTH: 38
admin(21407):   HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; 
x64; rv:58.0) Gecko/20100101 Firefox/58.0

admin(21407):   HTTP_CONNECTION: keep-alive
admin(21407):   SERVER_NAME: lists.radiolists.net
admin(21407):   REMOTE_ADDR: 208.77.151.18
admin(21407):   PATH_TRANSLATED: /home/.sites/112/site7/web/broadcast
admin(21407):   SERVER_PORT: 443
admin(21407):   SERVER_ADDR: 208.77.223.78
admin(21407):   DOCUMENT_ROOT: /home/.sites/112/site7/web
admin(21407):   PYTHONPATH: /usr/lib/mailman
admin(21407):   SCRIPT_FILENAME: /usr/lib/mailman/cgi-bin/admindb
admin(21407):   SERVER_ADMIN: admin
admin(21407):   SCRIPT_URI: 
https://lists.radiolists.net/mailman/admindb/broadcast

admin(21407):   HTTP_HOST: lists.radiolists.net
admin(21407):   SCRIPT_URL: /mailman/admindb/broadcast
admin(21407):   HTTPS: on
admin(21407):   HTTP_UPGRADE_INSECURE_REQUESTS: 1
admin(21407):   HTTP_CACHE_CONTROL: max-age=0
admin(21407):   REQUEST_URI: /mailman/admindb/broadcast
admin(21407):   HTTP_ACCEPT: 
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

admin(21407):   GATEWAY_INTERFACE: CGI/1.1
admin(21407):   SCRIPT_NAME: /mailman/admindb
admin(21407):   REMOTE_PORT: 62040
admin(21407):   HTTP_ACCEPT_LANGUAGE: en-US,en;q=0.5
admin(21407):   REQUEST_SCHEME: https
admin(21407):   CONTENT_TYPE: application/x-www-form-urlencoded
admin(21407):   HTTP_ACCEPT_ENCODING: gzip, deflate, br
admin(21407):   UNIQUE_ID: WoHkLp4UEeGi2zC2IOGJGwM

--
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

[BlueOnyx:21732] big problem SSL let's encrypt websites on server

[PESJA A & A]

Hi All,
 
About one hour ago, one of my customers complained that his website was down. I 
detected that al of the SSL (Let's Encrypt) websites where down. 
I can't figured out what is wrong. But when I request or renew a new certificat 
for a server, it takes a very long time (more then 15 minutes). It look's like 
it's stuck.
 
Please help!
 
Kind regards,
 
PESJA___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

[BlueOnyx:21733] Re: big problem SSL let's encrypt websites on server

[Richard Barker]

I have had the same thing. I just disable then enable ssl and all is good

RC

--

/*Richard C. Barker Sr.
CEO & President
1-813-873-8942
ProBass Networks Inc. */
www.probassnetworks.net 
www.probass.net 
***
DISCLAIMER : -
This e-mail is confidential and intended only for the use
of the individual or entity named above and may contain
information that is privileged. If you are not the intended
recipient, you are notified that any dissemination, distribution
or copying of this e-mail is strictly prohibited. If you have
received this email in error, please notify us immediately
by return email or telephone and destroy the original message.

___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

[BlueOnyx:21734] Re: big problem SSL let's encrypt websites on server

[Michael Stauber]

Hi Pesja,

> About one hour ago, one of my customers complained that his website was
> down. I detected that al of the SSL (Let’s Encrypt) websites where down.
> 
> I can’t figured out what is wrong. But when I request or renew a new
> certificat for a server, it takes a very long time (more then 15
> minutes). It look’s like it’s stuck.

Please do this:

Login by SSH as "admin" and "su -" to gain root access.

Stop and restart CCEd:

killall -9 cced
killall -9 pperld
/usr/sausalito/sbin/cced.init restart

Then make sure you're fully YUM updated:

yum clean all
yum update

Once that's done go to the GUI at "Server Management" / "Security" /
"PHP Settings" and make a small change there. What you change doesn't
really matter. Like: Bump "Memory limit" up one notch to the next higher
value and save the changes.

That will cause the GUI to redo the VirtualHost containers for all
Vsites and it'll bring the SSL certificates back for the Vsites that are
currently missing them.

-- 
With best regards

Michael Stauber
___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx

[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-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 -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

[BlueOnyx:21736] Re: big problem SSL let's encrypt websites on server

[Richard Barker]

Thank you

RC

--

/*Richard C. Barker Sr.
CEO & President
1-813-873-8942
ProBass Networks Inc. */
www.probassnetworks.net 
www.probass.net 
***
DISCLAIMER : -
This e-mail is confidential and intended only for the use
of the individual or entity named above and may contain
information that is privileged. If you are not the intended
recipient, you are notified that any dissemination, distribution
or copying of this e-mail is strictly prohibited. If you have
received this email in error, please notify us immediately
by return email or telephone and destroy the original message.

___
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx