Here is what a EV1 tech replied in my ticket:
QUOTE
Dear Customer,
The cPanel backend does all the urchin processing itself; it doesn't use the urchin daemon or scheduler at all (and in fact forcibly shuts them off). Urchin profiles are created automatically (in theory) for each domain by cpanellogd, and the logs are processed by the same script at the same time that the analyzer stats etc. are updated. The actual data for each site is stored separately per-domain (normally under /home/domainname/tmp/urchin), not in the global urchin location (normally under /usr/local/urchin). The urchin stats link available for each site via the cPanel interface uses the per-site data (under /home/domainname/tmp/urchin), not the data stored under the global urchin directory.
So there are basically two ways to use urchin with cpanel:
1. Install urchin and run the urchin daemon (usually on port 9999) and scheduler; set up profiles for the domains you care about manually using the urchin administration interface, and schedule periodic updates via the urchin scheduler --- users can log into the urchin interface on port 9999 and view their stats that way, but not via the link in their cPanel interface: that link will point to the per-domain urchin data created by cPanel and show zeroes (at best) or errors (at worst) for the domain. You'll also have to live with cpanellogd shutting down your urchin daemons every time it processes the logs; alternatively you can hack cpanellogd to have it skip urchin processing or install a monitoring script to restart the urchin daemons as required. Obviously this approach is not the one intended by cpanel.
2. Use the cPanel urchin integration. Shut off the urchin daemons and remove them from your startup scripts so they won't get started. Let cPanel process urchin data and store it per-domain, for each domain on your site. Users can see their urchin stats via the urchin link in their cPanel interface.
I suspect that most people would opt for #2 if it actually worked. Unfortunately it really doesn't, for the following reasons:
1. There's a bug in cpanellogd (not sure if it's corrected as of 9.1.0-C118) that prevents the profiles from getting created automatically for each domain, leading to errors of the " unable to find profile" variety when users click on the urchin stats link. That problem can be worked around -- simply create the profiles manually in the urchin interface, or via /usr/local/urchin/util/uconf-driver. Profiles must be named the same as the domain, without the leading www, e.g. mydomain.com, and log file sources must be labelled the same way, i.e. mydomain.com.
2. Urchin can't actually read the log files in a default cPanel installation -- log files are by default 640 permission and need to be 644 for urchin to read them. Change that in your cPanel settings if you need to. If you don't, no urchin data will be generated for any of the profiles. Manually chmoding the log file permissions won't work -- cpanel will just change it back to 640 (or whatever you've got it set to).
3. To use cpanel's Urchin integration, direct-linking must be enabled in Urchin. It's not clear whether cPanel's setting this flag in the urchin database -- it's supposed to, but if you're experiencing problem #1 you may be experiencing this problem as well. Solution: enable direct-linking from the urchin admin interface (or uconf-driver) if necessary.
3. Assuming you fix problems #1, #2 and #3, Urchin itself seems to have an error creating backup data when run from the per-domain locations set up by cPanel. The same error doesn't exist if you run it from the global urchin location. You can see this yourself as follows:
cd /usr/local/urchin
bin/urchin -p mydomain.com
That should process the logs for the profile called " mydomain.com" , in the global urchin data location (which is actually unusable by cpanel). Then for the sake of comparison try this:
cd /home/mydomain/tmp/urchin
bin/urchin -p mydomain.com
That does the same thing, only storing the urchin data under /home/mydomain/tmp/urchin, and it results in errors of the " unable to create backup" variety. In Urchin 5.1 the error is fatal -- the data remains " locked" for that profile and when the logs are next processed for that profile Urchin attempts an auto-rollback (which also fails, actually). In Urchin 5.5 the error still occurs but it's not fatal; you'll get no backups or rollback capability but you should at least be able to see the data that was generated. Solution: upgrade to Urchin 5.5, or keep 5.1 but edit each profile manually to turn off the backup and auto-rollback functions.
Long story short, urchin and cpanel don't really play very well together at this time... mostly because cpanel's doing a bunch of things that don't quite work, and partly because of an issue in urchin 5.1. You can work around the problems using the info above if you're industrious or bored and you really, really must have urchin stats available from cpanel, or if you can live with running the urchin daemons yourself and screwing the cpanel integration. But people running the urchin daemons themselves should at least be aware that they're not operating in the way cpanel's designed to. I suspect (from reading various forums) that a lot of people are trying to get things to work by running the urchin daemons themselves, processing the logs manually or via the urchin scheduler and storing the resulting data in the global urchin location, and then seeing zeroes when they try to view urchin stats in cpanel (because the right profile exists but the data can't be found in /home/domain/tmp/urchin/data). If I hadn't already spent a bit of time this weekend getting things to work I wouldn't advise exerting a lot of effort here -- just wait for cPanel to fix the broken urchin integration or better yet use a different stats/reporting package (one that isn't so heavyweight and slow).
I am starting to think about how he said:
QUOTE
If I hadn't already spent a bit of time this weekend getting things to work I wouldn't advise exerting a lot of effort here -- just wait for cPanel to fix the broken urchin integration or better yet use a different stats/reporting package (one that isn't so heavyweight and slow).
Gonna give in I think unless anyone else can help!