Zenoss is a net-analyzer similar to Nagios, but it is running on Zope. I wrote an ebuild, but this one is for testing only. I may have jumped the gun here, but I have successfully emerged this one. :) The primary reason for posting such a immature ebuild is to make it available for other developers who are interested in getting Zenoss to work on their Gentoo. Zenoss has its quirks, and the package (37 MB) comes with all the dependencies except for mysql. It seems some of them have Zenoss-specific patches. Three dependencies are not satisfied, even. (simplejson-1.4, twistedsnmp-0.3.13, yapps-2.1.1). This one ignores these. I built an option to build the prebundled dependencies, or to use system-deps. I've no idea yet how this works. There also is an option to build Zenoss itself from SVN (it was introduced in the Makefile). This is my second ebuild, and this was quite a challenge. I hope it will be useful! :)
Created attachment 103780 [details] net-analyzer/zenoss/zenoss-1.0.1.ebuild
Simplejson can be found in the liquidx overlay. Also from http://bugs.gentoo.org/show_bug.cgi?id=129346
OK, a couple of notes: - The dependency syntax is invalid (needs to be full atoms, including category) - we have dodir, no need to use mkdir - enewuser already created homedir, no need to create it manually - do not install anything in pkg_setup - do NOT shut down any services in pkg_setup (!!!) - src_unpack is redundant - epatch belong to src_unpack, not src_compile - that src_compile stuff does a _nasty_ stuff that will bomb out with sandbox big time - drop svn use flag; it's not acceptable to use live svn sources with a regular ebuild (would need a separate ebuild using subversion eclass, that wouldn't be included in the tree anyway) - bundled stuff sucks, the ebuild should use dependencies already in the tree - _never_ install anything into /usr/local - interactive stuff and belong to pkg_config - never ever start/stop services from within ebuild - use elog, not einfo for anything that's not just a temporary info related to compile
Comment on attachment 103780 [details] net-analyzer/zenoss/zenoss-1.0.1.ebuild A couple of links that you could help you write better ebuilds: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 http://devmanual.gentoo.org/ Marking this as obsolete, it can't be included in the tree as it is...
Some more random notes - DESCRIPTION cannot be empty - HOMEPAGE cannot be empty - the usage of USE=doc is invalid; docs should always be installed when they are already included in the tarball, unless they require major dependencies to build them or additional huge download
Ok, thanks for the remarks. I'll go and fix the ebuild. :)
I need a bit of advice here. Zenoss needs patched versions of some packages. The patches are provided, and I can create ebuilds for them. Would it be good practise to write in a USE flag "zenoss-patches" for these dependencies? It seems that Zenoss also modifies some core Zope libraries. Since it is possible that another Zope is running on the same box than Zenoss, would it be preferred if the Zenoss-Zope is installed into /usr/zenoss/?
CCing zope folks, I can't help you with this.
Created attachment 104012 [details] dev-python/yapps/yapps-2.1.1.ebuild Here are ebuilds for the dependencies (with patches) that are not in portage. I found several of them from various overlays, but bumped the version up and hacked in the patches. I defined the USE flag 'zenoss-patches'. ATM these patched versions are hard-coded to specific versions, which may cause conflicts. At the moment 2/3 of them are the latest versions.
Created attachment 104013 [details] dev-python/twistedsnmp/twistedsnmp-0.3.13.ebuild
Created attachment 104014 [details] dev-python/simplejson/simplejson-1.4.ebuild
Created attachment 104015 [details] dev-python/pysnmp/pysnmp-3.4.3.ebuild
Created attachment 104016 [details] dev-python/mysql-python/mysql-python-1.2.0-r1.ebuild
Created attachment 104017 [details] dev-python path for overlay (contains the patches) The ebuilds are for checking, this tarbz2 is the patched dev-python tree for the experimentalists who'd like to try to emerge zenoss. I'll post the Zenoss ebuild after a bit of more work on it.
Created attachment 104046 [details] net-analyzer/zenoss/zenoss-1.0.2.ebuild I hope this ain't so broken as it the previous version was. :) A new Zope instance is created to /usr/zenoss, and the Zenoss Products copied over there. I haven't yet have managed to get into the Zope manage screen (somehow my other Zope instances - that are not running - interfere).
Created attachment 104048 [details, diff] net-analyzer/zenoss/files/mysql-setup.sql Here is the mysql script that *should* insert the database 'events' and set the user permissions properly. I used phpmyadmin as a reference. This does not give errors, but it seems that nothing is created into mysql.
Created attachment 104049 [details, diff] net-analyzer/zenoss/files/GNUmakefile.patch This is only needed if you run +prebundled. This enables logging to stdout.
This app is featured on the Slashdot frontpage today, fyi. http://it.slashdot.org/article.pl?sid=07/03/26/1058228&from=rss
WOW, I was impressed with zenoss, after I was impressed with cacti! Does anybody have an overlay with all the above patches? If not, I'll make an effort next week to gather them in my own overlay (unofficial) and post here back.
I've installed the source version from zenoss. I would suggest to use their step's and only add gentoo path (/usr/lib/python2.4) instead of ($ZENHOME/lib/python). Total directory size after installed is about 168M. My Install :- useradd -m zenoss mkdir /opt/zenoss && chown zenoss:\ /opt/zenoss export ZENHOME=/opt/zenoss # added to user zenoss ~/.bashrc export PYTHONPATH=/usr/lib/python2.4 # added to user zenoss ~/.bashrc export PATH=$ZENHOME/bin:$PATH # added to user zenoss ~/.bashrc I untar the source and ran the install.sh script as user zenoss. Can we do this instead ?? It looks more similar like using Binary Apps.
Upstream is still very much alive (with the free version of Zenoss now called Zenoss Core), so alive in fact that it is now four major versions ahead of what has been posted here. Is there still user demand for having it added to Portage? If so, the usual appeal: While this is still a viable package for the Gentoo Portage tree it appears this ebuild is lacking in community interest. If you (or another user) are still wanting this to make it into the Portage tree please let us know! It would be additionally helpful (but not required) if you were willing to help out with the package by becoming it's proxied maintainer; you have already done most of the work for this task. Gentoo even has a dedicated team[1] for assisting users in becoming proxied maintainers. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org or join #gentoo-proxy-maint on Freenode IRC. If this bug remains silent without further comments for 30 days i will close it with the resolution of WONTFIX. Beyond that the bug can always be reopened to get this package back on track for the Gentoo Portage tree. [1]: https://wiki.gentoo.org/index.php?title=Project:Proxy_Maintainers Kind regards, Marecki
