[BlueOnyx:17701] Re: 5209R - did last apache updates crache mod ruid?

[Michael Stauber]

Hi Dirk,

> it seems that there is no command for the max 
> allowed disk space in the second line of the
> logfile.

Yes. There doesn't need to be. It uses "-1" as default on creation of a
Vsite. The actual disk quota for the Vsite is set separately later on.

This happens here in your logfile (I shortened the lines):

> SET  315 . Disk quota = "400"
> SET 315.Disk failed (-2)
> SET  315 . FTPNONADMIN enabled = "0"
> SET 315.FTPNONADMIN failed (-2)
> SET  315 . SSL enabled = "0"
> SET 315.SSL failed (-2)
> SET  315 . Shell enabled = "0"
> SET 315.Shell failed (-2)
> SET  315 . CGI enabled = "0"
> SET 315.CGI failed (-2)
> SET  315 . AnonFtp enabled = "0" quota = "20" maxConnections = "10"
> SET 315.AnonFtp failed (-2)
> SET  315 . subdomains vsite_enabled = "1" max_subdomains = "3"
> SET 315.subdomains failed (-2)
> SET  315 . PHP enabled = "0" mod_ruid_enabled = "0" suPHP_enabled="0"
> SET 315.PHP failed (-2)
> SET  315 . USERWEBS enabled = "0"
> SET 315.USERWEBS failed (-2)
> SET  315 . MYSQL_Vsite enabled = "0" destroy = "1432712667"
> SET 315.MYSQL_Vsite failed (-2)
> SET  315 . SSI enabled = "0"
> SET 315.SSI failed (-2)
> SET  315 . Java enabled = "0"
> SET 315.Java failed (-2)

As you can see: *All* of these transactions fail with the (-2) error
message. Which means: "Unknown Object".

This leaves me pretty puzzled. From the logfile I can see that the
"CREATE Vsite" command went through without errors. It created the Vsite
as CODB Object 315.

While it did so, that should also have automatically created the usual
"NameSpaces" within the Vsite Object. Which these are can be checked
with CCEclient by running the "names" command against a Vsite object:

[root at 5209r ~]# /usr/sausalito/bin/cceclient
100 CSCP/0.99
200 READY
find Vsite
104 OBJECT 93
104 OBJECT 39
104 OBJECT 83
104 OBJECT 66
201 OK
names 93
105 NAMESPACE SiteStats
105 NAMESPACE Shell
105 NAMESPACE FTPNONADMIN
105 NAMESPACE UserDefaults
105 NAMESPACE SSL
105 NAMESPACE CGI
105 NAMESPACE AnonFtp
105 NAMESPACE subdomains
105 NAMESPACE DNS
105 NAMESPACE PHP
105 NAMESPACE USERWEBS
105 NAMESPACE PHPVsite
105 NAMESPACE Disk
105 NAMESPACE MYSQL_Vsite
105 NAMESPACE SSI
105 NAMESPACE Java
201 OK

These NameSpaces are integral part of a BlueOnyx Vsite and get created
automatically with default values when a Vsite object is created.
Depending on which PKGs you have installed you might get some extra
NameSpaces such as "solbackup" for example.

The subsequent "SET <Object> . <NameSpace> <key> = <value>" transactions
such as ...

> SET  315 . Disk quota = "400"
> SET 315.Disk failed (-2)

... should therefore not fail with an "Unknown Object" error. Especially
not when it (successfully) did a SET transaction against Object 315 just
a few seconds earlier:

webapp_install.pl: SET  315 . PHPVsite force_update = 1432712658
memory_limit = 64M upload_max_filesize = 5M

If the NameSpaces were a problem (like them not being there), then we
actually would get a (-4) error message ("Unknown Space") instead.

The *only* suspicion I have at the moment is this: It could be related
to a problem with the WebApp installer.

The auto-install of RoundCube startet at 09:44:18. *While* it was
running the SET transactions for Diskspace and Vsite NameSpaces did
start at 09:44:27 and all failed. After the failed NameSpace
transactions at 09:44:27 the WebApp installer did the last "SET 326
idirectory = ''" SET transaction.

This might be related, because the NameSpace SET transaction fell right
into the middle of these. Usually that shouldn't be a problem. But at
this time I don't want to rule it out as contributing factor.

I do have a couple of 5209R running myself, but I am unable to replicate
this problem on any of them. So if possible at all I would *really*
appreciate it if I could login to your problem server so that I can run
some diagnostics. Can you send me the login details offlist?

-- 
With best regards

Michael Stauber