Hello All, I've just build the solaris package via solbuild/rules. When i was doing this i was wondering about a few things. These is a nice init.d file in the solbuild directory. solbuild/syslog-ng.init.d After the build it cant be found in the package at all. When i copy the above mentioned init.d script it uses the config file /opt/syslog-ng/etc/syslog-ng/syslog-ng.conf. Would /etc/syslog-ng/syslog-ng.com a better location? I adapted the script for this now. Why is the package in stalled in /opt/syslog-ng in stead of /usr/local? By the way Sun uses /opt/sfw for gnu software. Why are to init.d packages available in the source, being solbuild/syslog-ng.init.d and contrib/init.d.solaris . The first one is realted to /opt/syslog-ng the second one to /usr/local . Regards, Joop Boonen.
Joop Boonen wrote:
Hello All,
I've just build the solaris package via solbuild/rules. When i was doing this i was wondering about a few things.
solbuild/rules isn't intended for generic usage, this file is used for our internal packaging which is used with the Zorp firewall on Solaris.
These is a nice init.d file in the solbuild directory. solbuild/syslog-ng.init.d After the build it cant be found in the package at all.
This init script is installed into the docdir, not into /etc.
When i copy the above mentioned init.d script it uses the config file /opt/syslog-ng/etc/syslog-ng/syslog-ng.conf. Would /etc/syslog-ng/syslog-ng.com a better location? I adapted the script for this now.
The package uses the /opt/syslog-ng prefix
Why is the package in stalled in /opt/syslog-ng in stead of /usr/local? By the way Sun uses /opt/sfw for gnu software. Why are to init.d packages available in the source, being solbuild/syslog-ng.init.d and contrib/init.d.solaris . The first one is realted to /opt/syslog-ng the second one to /usr/local .
As I mentioned solbuild/ is for BalaBit's environment, not for generic usage. -- Sandor Geller wildy@balabit.hu
Hello Sandor, Are the spec files in in the decompressed directory for the same perpose. Only for Zorp? Wouldn't it be a good idea to create a generic Solaris package? especially because no standard syslog-ng packages (sunfreeware for example) with spoof-source option enabled. What is the risk to use the solbuild/rules? The problem is that sun doesn't use a package manager like rpm (spec file i.e. srpm). It's quite difficult to build a package with the extra options but the same file permissions and locations as the for instance sunfreeware one. Regards, Joop Boonen. On Fri, July 28, 2006 3:14 pm, Sandor Geller wrote:
Joop Boonen wrote:
Hello All,
I've just build the solaris package via solbuild/rules. When i was doing this i was wondering about a few things.
solbuild/rules isn't intended for generic usage, this file is used for our internal packaging which is used with the Zorp firewall on Solaris.
These is a nice init.d file in the solbuild directory. solbuild/syslog-ng.init.d After the build it cant be found in the package at all.
This init script is installed into the docdir, not into /etc.
When i copy the above mentioned init.d script it uses the config file /opt/syslog-ng/etc/syslog-ng/syslog-ng.conf. Would /etc/syslog-ng/syslog-ng.com a better location? I adapted the script for this now.
The package uses the /opt/syslog-ng prefix
Why is the package in stalled in /opt/syslog-ng in stead of /usr/local? By the way Sun uses /opt/sfw for gnu software. Why are to init.d packages available in the source, being solbuild/syslog-ng.init.d and contrib/init.d.solaris . The first one is realted to /opt/syslog-ng the second one to /usr/local .
As I mentioned solbuild/ is for BalaBit's environment, not for generic usage.
-- Sandor Geller wildy@balabit.hu _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
Joop Boonen wrote:
Hello Sandor,
Are the spec files in in the decompressed directory for the same perpose. Only for Zorp?
Hi, Well, some of the spec files are in use by BalaBit's build servers, especially the RHEL3 and RHEL4 ones. Of course you can use these files as a basis for your own packaging, problem reports and patches are welcome. Unfortunately the packages aren't a drop-in replacement for the standard syslogd on RHEL or on Solaris. The users have to modify their syslogd configuration manually. In the RHEL-specific configuration file parts of the configuration (which collide with the standard syslogd) are commented out. The /opt comes from the Zorp Professional 3.0, every package created by BalaBit use the /opt prefix on Solaris. Otherwise the Solaris packaging isn't in a tight correlation with Zorp.
Wouldn't it be a good idea to create a generic Solaris package? especially because no standard syslog-ng packages (sunfreeware for example) with spoof-source option enabled.
Well, I can't promise that we will build binary packages. It would be nice hovewer, when a consensus could be made on the proper configure options, and several volunteers can create the packages themself. Several vendors (like Debian, Suse/Novell) support syslog-ng already, others not. BalaBit has several Solaris support packages which include the availability of the binary packages built from the latest sources, but these support packages aren't free.
What is the risk to use the solbuild/rules?
Nothing special except the errors I made :)) solbuild/rules instructs gcc to use the sparc v9 instruction set, so several older sparc processors aren't supported out of the box (but it is a trivial change to optimize for other processors).
The problem is that sun doesn't use a package manager like rpm (spec file i.e. srpm). It's quite difficult to build a package with the extra options but the same file permissions and locations as the for instance sunfreeware one.
As I wrote you can use the files in the solbuild directory. The Solaris packaging isn't a nice one, but I was in a hurry when I made it, and I don't like that old packaging method Solaris use - dpkg and rpm are far better from a packager's point of view - maybe I'm not skilled enough to create proper Solaris packages :)) Regards, -- Sandor Geller wildy@balabit.hu
participants (2)
-
Joop Boonen
-
Sandor Geller