Notes |
|
(0005725)
|
ihsan
|
2009-03-24 15:46
|
|
The smf manifest is provided by cswclassutils. I'll transfer this bug to cswlcassutils. |
|
|
(0005730)
|
bonivart
|
2009-03-24 22:04
|
|
Ok, I have to do some tests to reproduce the problem. In the meantime, I guess you can just install the package into each zone manually, I hope it's not too many. |
|
|
(0005995)
|
bonivart
|
2009-04-21 19:03
|
|
Still haven't had time to test but wondering if it's just cswclassutils not being present in the (sparse) zones? |
|
|
(0006218)
|
bonivart
|
2009-05-28 16:42
|
|
I really can't get any further without more info. I will have to assume that the install was done from a sparse zone so CSWcswclassutils (which contains files in /usr) failed. The fix is to install CSWcswclassutils from the global zone. |
|
|
(0006219)
|
bonivart
|
2009-05-28 16:43
|
|
I have added info about the sparse zone issue on the wiki. |
|
|
(0006221)
|
user2169
|
2009-05-29 11:36
|
|
|
|
(0006223)
|
bonivart
|
2009-05-29 13:38
|
|
Why is that a fix and for what? Please explain what's the problem first? Is it a problem with syslog_ng or cswclassutils?
And who are you? automaciej from IRC, wahwah from Sourceforge? |
|
|
(0006225)
|
user2169
|
2009-05-29 13:54
|
|
Yes, it's the same person: automaciej from irc == wahwah from sourceforge == maciej from the mailing list
In short: The original problem was that syslog_ng didn't get started in non-global zones. Changeset 5096 fixes that.
Longer explanation: I don't think that the SMF manifest was provided by cswclassutils. There was an XML file in the 'files' folder. Changeset 5096 ports syslog_ng to mgar v2 and switches SMF handling to cswclassutils. As a side note, I don't think this bug belongs to cswclassutils or common, it belongs to syslog_ng. |
|
|
(0006226)
|
bonivart
|
2009-05-29 14:09
|
|
Ok, thanks for the clarification. :-)
According to your link Ihsan already used the SMF support through cswclassutils:
SPKG_CLASSES = none cswinitsmf
That class autogenerates a manifest and that's what gets imported so even if he somehow packaged another manifest I doubt very much it was used, it may have been there as some contrib stuff.
But as I have tried to mention before, cswclassutils contains files in /usr so if you're running a sparse zone and tries to install, in this case, syslog_ng from it, the dependency installation of cswclassutils will fail since /usr is read-only. The fix is to have cswclassutils installed from the global zone so the dependency is fulfilled beforehand. |
|
|
(0006227)
|
user2169
|
2009-05-29 14:14
|
|
I see, you thought that I installed the package in a sparse zone -- that wasn't the case.
Say, you have machine foo with zones foo-zone1 and foo-zone2. You install syslog_ng in the global zone of foo. When you do that, foo-zone1 and foo-zone2 will inherit syslog_ng. What I expect to happen is to have syslog_ng up and running on foo-zone1 and foo-zone2 as well as in the global zone. This wasn't happening, hence this bug. |
|
|
(0006228)
|
bonivart
|
2009-05-29 14:42
|
|
Ok, so your changes only to syslog_ng has made it work for you? Then I agree that this is a syslog_ng bug and not a cswclassutils one. We mistakenly transferred the bug to cswclassutils. Is it ok to transfer it back to syslog_ng (Ihsan)? |
|
|
(0006229)
|
user2169
|
2009-05-29 15:45
|
|
Yes, changes to syslog_ng only fixed the issue. |
|
|
(0006735)
|
maciej
|
2009-09-21 00:29
|
|
This issue is fixed. syslog-ng installs and runs fine in non-global zones. |
|