Hi Florian, hi Juerg,
> It says " su SITE78-logs site10"
Ok, there we have the culprit. It should say:
su SITE10-logs site10
> BlueOnyx 5210R
Very well. I just checked how we fix this.
Running the script /usr/sausalito/sbin/update_vsite_logrotate.pl does
generate new /etc/logrotate.d/siteX files for all Vsites.
The information is written out by the handler
/usr/sausalito/handlers/base/sitestats/set_logrotate.pl and it does a
good job.
BUT: So far it fetched both the name of the logfile owner and the site
group from CODB and implicitly trusted that this information is correct.
But in your case the CODB NameSpace 'SiteStats' of your Vsite with the
name 'site10' has an incorrect owner for the logfiles stored. So the
handler set_logrotate.pl happily wrote the incorrect owner back into the
logrotate config without giving a damn that this was wrong.
I just extended the handler
/usr/sausalito/handlers/base/sitestats/set_logrotate.pl with a sense
check. It now takes the group name, puts it in uppercase, appends
'-logs' to it and compares if that is identical with the logfile owner
that was stored in CODB.
If it is not identical, it will fix the owner name in CODB and will
write out logrotate configs with the correct owner name.
Summary of the changes in SVN:
https://devel.blueonyx.it/trac/changeset/4578
I just published these YUM updates for 5210R and 5211R. Upon install of
the updates the script /usr/sausalito/sbin/update_vsite_logrotate.pl
will be automatically run to fix any lingering logrotate ownership
issues in CODB.
--
With best regards
Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
