Server status data is not available

[todd_dsm]

Please check the logs for errors. I would check: /var/log/
1) messages
2) secure
3) zimbra.log

In my case I found that zimbra was unable to connect to some services because of PAM (above). Once that was fixed the stats started working again.

Thanks in advance,
todd_dsm

Don't forget to Vote for this RFE:
RFE: A place To Display the contents of 'My Documents'
Reasoning: It's new, bold, and cool.

[yogesh2tech]

When I log in with the admin user, I get this message "Server status data is not available. To see the server status, logger service must be installed."

crontabs, logrotate, anacron and file are installed.

zmcontrol status is showing everything running.

I am using zcs-6.0.5_GA_2213.RHEL5_64.20100203001950 on rhel5.4 on rackspace cloud server.

I have also updated it from zcs-6.0.4 to the above version but still getting the same.

[todd_dsm]

Did you check the logs? If so were there any suspect errors? Show the people what you're seeing.

Thanks in advance,
todd_dsm

Don't forget to Vote for this RFE:
RFE: A place To Display the contents of 'My Documents'
Reasoning: It's new, bold, and cool.

[yogesh2tech]

Dear Todd

I think everything is ok with the logs.If any thing you require i can just post them.

[yogesh2tech]

tail -f /var/log/zimbra.log

May 2 15:55:16 mail clamd[11438]: Database correctly reloaded (759749 signatures)
May 2 15:55:25 mail zmmailboxdmgr[20105]: status requested
May 2 15:55:25 mail zmmailboxdmgr[20105]: status OK
May 2 15:55:26 mail zmmailboxdmgr[20171]: status requested
May 2 15:55:26 mail zmmailboxdmgr[20171]: status OK
May 2 15:56:05 mail zmmailboxdmgr[20552]: status requested
May 2 15:56:05 mail zmmailboxdmgr[20552]: status OK
May 2 15:56:08 mail slapd[6377]: slap_queue_csn: queing 0x42f574f0 20100502155608.910228Z#000000#000#000000
May 2 15:56:08 mail slapd[6377]: slap_graduate_commit_csn: removing 0xcc064b0 20100502155608.910228Z#000000#000#000000
May 2 15:56:48 mail zmmailboxdmgr[21909]: status requested
May 2 15:56:48 mail zmmailboxdmgr[21909]: status OK
May 2 15:56:49 mail zmmailboxdmgr[21975]: status requested
May 2 15:56:49 mail zmmailboxdmgr[21975]: status OK

[yogesh2tech]

tail -f /var/log/messages
May 2 15:50:41 mail saslauthd: auth_zimbra_init: zimbra_cert_check is off!
May 2 15:50:41 mail saslauthd: auth_zimbra_init: 1 auth urls initialized for round-robin
May 2 16:02:47 mail saslauthd: auth_zimbra_init: zimbra_cert_check is off!
May 2 16:02:47 mail saslauthd: auth_zimbra_init: 1 auth urls initialized for round-robin

[todd_dsm]

When I had this problem, I believe it was either in /var/log/messages or audit.log. It's been some time so I'm not sure. But you can grep it out or watch it...

$ grep -i pam /opt/zimbra/log/messages
$ grep -i pam /opt/zimbra/log/audit/audit.log

# Or just watch it while you test:
watch grep -i pam /opt/zimbra/log/messages

If you watch it in term1 you can test in term2 and see if you can trigger the log entry. If it's reproducible you can at least be sure that you've found 1 condition. Of course there may be other conditions you are not aware of, then - more testing.

In my case, to gen the right pam config file (on CentOS) you run authconfig and it configures your pam stack, /etc/ldap.conf, and /etc/nsswitch.conf. These files are absolutely critical to the proper functioning of your system.
NOTE: I am using zimbra in conjunction with samba. So you can omit the --enablemkhomedir if not using samba.

$ authconfig --test > /tmp/before.out
$ authconfig --enableldap --enableldapauth --disablenis --enablecache \
           --ldapserver=${LDAPSERVER} --ldapbasedn=${LDAPBASEDN} \
           --enablemkhomedir \
           --updateall

# LDAPSERVER=host.domain.tld
# LDAPBASEDN=dc=domain,dc=tld
# This will work for a simple install but you should also do your own research. I am not an expert.
$ authconfig --test > /tmp/after.out

Anyway, this generates a system-wide pam stack:

$ cat /etc/pam.d/system-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     optional      pam_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

It looks like you're using RHEL so this should be enough to get your system-auth-ac file in a good spot

grep/watch the logs again and run the same tests you did at the beginning. You should see the errors are no longer populating your logs. Then, check your status in the Admin UI once again. Then you should be in business.

Cheers mate!

Thanks in advance,
todd_dsm

Don't forget to Vote for this RFE:
RFE: A place To Display the contents of 'My Documents'
Reasoning: It's new, bold, and cool.