0003469: Zone support for syslog_ng

(0005725)
ihsan (developer)
2009-03-24 15:46

The smf manifest is provided by cswclassutils. I'll transfer this bug to cswlcassutils.

(0005730)
bonivart (developer)
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 (developer)
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 (developer)
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 (developer)
2009-05-28 16:43

I have added info about the sparse zone issue on the wiki.

(0006221)
user2169
2009-05-29 11:36

It is fixable, I've created http://apps.sourceforge.net/trac/gar/changeset/5096 [^] with a proposal.

(0006223)
bonivart (developer)
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 (developer)
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 (developer)
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 (reporter)
2009-09-21 00:29

This issue is fixed. syslog-ng installs and runs fine in non-global zones.

Issue History
Date Modified	Username	Field	Change
2009-03-14 16:34	user2169	New Issue
2009-03-24 13:09	ihsan	Status	new => assigned
2009-03-24 13:09	ihsan	Assigned To	=> ihsan
2009-03-24 15:46	ihsan	Note Added: 0005725
2009-03-24 15:46	ihsan	Status	assigned => acknowledged
2009-03-24 15:46	ihsan	Project	syslog_ng => cswclassutils
2009-03-24 22:02	bonivart	Status	acknowledged => assigned
2009-03-24 22:02	bonivart	Assigned To	ihsan => bonivart
2009-03-24 22:04	bonivart	Note Added: 0005730
2009-04-21 19:03	bonivart	Note Added: 0005995
2009-05-28 16:42	bonivart	Note Added: 0006218
2009-05-28 16:43	bonivart	Note Added: 0006219
2009-05-28 16:43	bonivart	Status	assigned => closed
2009-05-28 16:43	bonivart	Resolution	open => not fixable
2009-05-29 11:36	user2169	Note Added: 0006221
2009-05-29 11:36	user2169	Status	closed => feedback
2009-05-29 11:36	user2169	Resolution	not fixable => reopened
2009-05-29 13:38	bonivart	Note Added: 0006223
2009-05-29 13:54	user2169	Note Added: 0006225
2009-05-29 14:09	bonivart	Note Added: 0006226
2009-05-29 14:14	user2169	Note Added: 0006227
2009-05-29 14:42	bonivart	Note Added: 0006228
2009-05-29 14:57	bonivart	Project	cswclassutils => syslog_ng
2009-05-29 15:45	user2169	Note Added: 0006229
2009-07-08 16:01	guillaume	Issue Monitored: guillaume
2009-08-23 10:53	ihsan	Assigned To	bonivart =>
2009-08-23 10:53	ihsan	Status	feedback => confirmed
2009-09-21 00:29	maciej	Note Added: 0006735
2009-09-21 00:29	maciej	Status	confirmed => closed
2009-09-21 00:29	maciej	Resolution	reopened => fixed

Notes
(0005725) ihsan (developer) 2009-03-24 15:46	The smf manifest is provided by cswclassutils. I'll transfer this bug to cswlcassutils.

(0005730) bonivart (developer) 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 (developer) 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 (developer) 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 (developer) 2009-05-28 16:43	I have added info about the sparse zone issue on the wiki.

(0006221) user2169 2009-05-29 11:36	It is fixable, I've created http://apps.sourceforge.net/trac/gar/changeset/5096 [^] with a proposal.

(0006223) bonivart (developer) 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 (developer) 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 (developer) 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 (reporter) 2009-09-21 00:29	This issue is fixed. syslog-ng installs and runs fine in non-global zones.

Relationships

OpenCSW Bug Tracker