problem has been fixed by upgrade to subrel 1, changing the requires from php-smarty to php-smarty2 and adding the package php-smarty2

Status: NEW => ASSIGNED
Assignee: bugsquad => qa-bugs

I've installed and tested the packages on my i586 system.  Once confirmed to
also be ready on a 64 bit system, the packages
kolab-webadmin
php-smarty2-doc
php-smarty2

are ready to move from Core Updates Testing to Core Updates.

CC: (none) => davidwhodgins

Just realized there is a problem. The symlink in /etc/rc.d/init.d
kolabd -> ../../../usr/bin/kolabd is broken.

I don't think a program should be linked to in init.d.

Shouldn't there be an init script that starts it, and puts it in the background?

I'm not clear on what the kolabd daemon does though. as the kolab service
is running, and the https://hodgins.homeip.net/kolab/admin/ is
accessible.

Does /usr/bin/kolabd accept start and stop as argument ? If yes, it might be suitable as an init script.

CC: (none) => boklm

The symlink kolabd in /etc/rc.d/rc.init is broken.  It points to
/usr/bin/kolabd, which does not exist.

/usr/sbin/kolabd does exist, and is started by /etc/rc.d/rc.init/kolab.

I think the broken symlink is a leftover from some previous version, that
never got cleaned up properly.

While I don't like seeing broken symlinks in a package, this seems to be
purely a cosmetic issue.  Also, it's from the package perl-kolab-2.2.4-2.mga1,
not from any of the packages in this update.

Still need someone to test kolab-webadmin on a 64 bit system.

Installing it will pull in php-smarty2.  php-smarty2-doc should be manually
selected, just to ensure it installs without any conflicts.

I've found another problem.

From my /var/log/cron/info.log ...
crond[2078]: (root) BAD FILE MODE (/etc/cron.d/kolabquotawarn)

ll /etc/cron.d/kolabquotawarn 
-rwxr-xr-x 1 root root 53 Jan 30 08:55 /etc/cron.d/kolabquotawarn*

From man 5 crontab ...
"CAVEATS
       crontab  files have to be regular files or symlinks to regular files, they must not be executable
       or writable for anyone else but the owner."

I see these. They (kolabquotawarn) have been in mdv this way since Oden maintained it or even longer, but good catch, they need to be fixed.
But for mga1 I need to do more testing before I want to apply this change.

I fixed the permission and removed kolabd in /etc/rc.d/rc.init I don't think it's needed. If it is, I could add the link and it needs to point to /usr/sbin/kolabd
Updated perl-kolab and kolab is now in updates_testing

Still getting crond[2132]: (root) BAD FILE MODE (/etc/cron.d/kolabquotawarn)

The CAVEATS is badly worded.  It should read ...
They must not be executable.
They must not be writable for anyone else but the owner.
"chmod a-x /etc/cron.d/kolabquotawarn" fixes that.

I'm also having some problem with email ...
amavis[3761]: (03761-03) (!)run_av (Clam Antivirus-clamd) FAILED - unexpected , output="/var/amavis/amavis-20110713T040443-03761/parts: lstat() failed: Permission denied. ERROR\n"

# ll /var/amavis/amavis-20110713T040443-03761/
total 8
-rw-r----- 1 amavis amavis  629 Jul 13 17:15 email.txt
drwxr-x--- 2 amavis amavis 4096 Jul 13 17:16 parts/

This happens when cron is mailing it's output, or I (as root) use the mail
command to send a test message, to my userid.

Reading /etc/amavisd/amavisd.conf, it says
# NOTE: run clamd under the same user as amavisd;
which is not currently the case.

I think the CAVEATS wording is very clear. It may be wrong. 
(Are you going to file a bug?)
OK, I will change the permission of /etc/cron.d/kolabquotawarn to 644.It seems to work.

I'm also having some problem with email ...
amavis[3761]: (03761-03) (!)run_av (Clam Antivirus-clamd) FAILED - unexpected ,
output="/var/amavis/amavis-20110713T040443-03761/parts: lstat() failed:
Permission denied. ERROR\n"

I don't see this error in any of my virtual installations. Did you run kolabconf after the upgrade? This should fix the path of the socket location to /var/lib/clamav/clam.socket
kolab doesn't provide the clamd.conf file.

Created attachment 722 [details]
Error messages when sending mail

Sorry for the delay getting back to this.

I did not run kolabconf.  I ran "/usr/sbin/kolab_bootstrap -b", as
indicated by the README.urpmi, which in turn appears to run kolabconf.

I then used the web interface to add my userid.

To get around the permission problem, I added amavis to the clamav group,
and clamav to the amavis group, so they can read each others output.

I think that step should be added to the postinstall scriptlet.

Now, when trying to send an email from root, to my id, I get the syslog
errors shown in the attachment.

What is supposed to create the cyrus.header file?

In addition to the sending mail problem, the init.d scripts that are run
by the kolab service should be turned off using chkconfig, so they don't
get run by both prcsys and kolab.

Ingore the question about the cyrus.header file.  I figured out how
to run the imapcreate to fix it.  I think that was caused by me uninstalling
and then reinstalling, without cleaning the directories properly.

I now have the email working.

The adding of the amavis an clamav to each others group still needs to be done.

You shouldn't need to run any imapscripts or other scripts. kolab_bootstrap or 
after installing kolabconf -n should do it for you.
Also adding clamav and amavis to a group doesn't need to be done. All group 
adding happens at installation. The pid files will be at the correct location 
done by the templates.
I am trying not to change much on a released installation. This has worked in 
Mandriva (and production environment) for a long time, original packager was 
Oden. All that screwed it up was Magaia (and Mandriva) moving to Smarty 3
I am now working on kolab-2.3.2 and that version is very different, using a lot 
of pear-horde (and ezcomponents) packages. You may have already seen them in 
the build server
In any case, I will double check the update in my virtual this Saturday just 
to be safe.

-- 
Thomas

what is the status of this update request ?

CC: (none) => dmorganec

Currently waiting for Thomas to confirm whether or not the
postinstall scriptlet should add clamav and amavis to each others groups,
to fix the problem shown in Comment 10.

I just run this testing:
Removed the kolab, perl-kolab and kolab-webadim packages
removed in /etc/kolab/ all files except the pem related, renamed them
re-installed kolab (updates-testing disabled)
did a "kolab-bootstrap -b"
moved the pem files back
started kolab with "service kolab start"
tried to read e-mail using thunderbird-> could not find user as expected, need to be added in web interface (that as the erro says doesn't work

added update-testing to the sources, did an upgrade of the kolab, perl-kolab and kolab-webadmin packages
restarted kolab
Opened the webinterface and added the users I had before

Opened thunderbird, read an existing e-mail and replied. The reply showed in the recipient inbox in 3 seconds (all internal, localhost e-mail addresseWend through all the logs, mail, syslog and to me they looks all good.
The /etc/cron.d/kolabquotawarn file has the perm -rw-r--r-- roor root (the same as php in the same dir.)
I would consider this ready to go.

This bug fixes the problem ofkolab-webadmin shows an empty page. As a result Kolab could not be configured through the web interface.

The reason is that kolab-webadmin hasn't been updated by upstream to php-smarty
Ver. 3 and mageia did upgrade php-smarty to Ver 3.

Please push the update as the tests show the problem as fixed.

update pushed.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Reopening, as the srpm
perl-kolab-2.2.4-2.1.mga1.src.rpm
was missed in the request for pushing to updates.

Can someone from the sysadmin team push the srpm
perl-kolab-2.2.4-2.1.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory:
This update removes /etc/rc.d/init.d//kolabd, which is not
used by koloab.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

update pushed.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED