[Kolab-devel] Interest in RPMs

[Stuart Bingë]

On Wednesday, 12 May 2004 21:29, Nathan Toone wrote:
> On Wednesday 12 May 2004 01:15 pm, Stuart Bingë wrote:
> > > Adding spam and virus filtering to Kolab
> >
> > Which spam/virus packages? As far as I know there is support in the Kolab
> > CVS for Amavis/Spamassassin/Clamd to do virus and spam filtering, but
> > more options in this field would be very beneficial.
>
> Sorry - it's Amavisd-new with spamassassin (using razor, pyzor, and dcc)
> and clamd.  It also has a postfix monitoring script that emails statistics
> on a daily basis (#messages processed, #viruses, #spams, etc)  I just took
> the howto at
> http://www.kolab.org/howtos/amavis_spamassassin_clam/amavis_spamassassin_cl
>am.pdf and combined it with a lot of tips from
> http://www.flakshack.com/anti-spam/ and made rpms from it.

Well from what you describe we can definitely use your work, so it won't be 
wasted. We can combine what you've done into the existing stuff.

> > Does your package include the latest version of the Webclient, that was
> > released on 2004-04-27? If so, I would definitely be interested in seeing
> > your RPM (as I'm sure many other would be).
>
> I basically took the howto at http://www.kolab.org/cvs-kolab.html and
> turned it into an RPM.  (Using a CVS checkout from yesterday - 5-12)

Excellent! This will save many a headache - going through that monster of a 
howto yourself, I'm sure you'll agree :-)

> > What about moving the configuration files that these packages rely on
> > over to the new metadata template system (assuming they contain
> > configuration options that rely on other Kolab configuration data)?
> >
> > With the new system, you can then distribute the "templatised" version of
> > your configuration files in your packages, and set them up to install to
> > @l_prefix@/etc/kolab/templates - Kolab will then automatically pick up
> > the new template and configure your packages when you run kolabconf.
> >
> > All you need to do is add some metadata to the top of the template
> > telling Kolab where you want the final config file to reside, and put in
> > all the @@@blah@@@ variables you need to get kolab-configured.
>
> I'd love to do this...what do I need to do to use this system?

OK, all you need is the following, which should go right at the top of your 
configuration files:

-------- cut below --------
destination : @l_prefix@/etc/wherever/your/conf/file/goes
diff_cmd : diff -q ${OLD_CONFIG_FILE} ${NEW_CONFIG_FILE}
on_change : @l_prefix@/etc/rc your_service restart
 
__END_KOLAB_META__
-------- cut above --------

'destination' tells Kolab where to put the final configuration file once it's 
replaced all the @@@ variables.

'diff_cmd' tells Kolab what to use to check if there was a change between the 
old and new config files when you run kolabconf - if there was a change then 
whatever 'on_change' specifies will be run. This is basically used to restart 
any services that need restarting, if their configuration files were updated. 
You can most probably leave 'diff_cmd' as it is here, unless you have some 
other fancy way of change detection.

I'll also be adding support for specifying the permissions of the final 
configuration file, so in future you'll be able to add something like 
'file_perms : 0600' if there are any security issues with the config file.

> Currently, my RPMs only use certain configurations that are already
> defined. (I use @@@postfix-mydomain@@@ whenever I need my domain, and
> @@@base_dn@@@, @@@bind_dn@@@, etc...)

You can run "kolabconf -d" if you want to see all the variables that you can 
use in between the @@@'s.

> I have just included a patch 
> for /kolab/lib/perl/vendor_perl/5.8.3/Kolab/Conf.pm to know the mapping of
> template to conf file.  However, I'd love to port it to the new system.

With the new system Conf.pm is not needed any more - there is no longer a 
'list' of configuration files that constantly need updating. All you do now 
is drop the config file in @l_prefix@/etc/kolab/templates, and kolabconf 
automatically picks it up when run.

> Along those lines, the RPMs might not be the most stable or portable - they
> might be quite architecture-dependent.  I had to go through learning how to
> write .spec files (I had never done them before...I didn't even know about
> how to use .src.rpms before this project...) so I could sure use some help
> refining those...however, they "work for me".

I'm sure the OpenPKG guys can help us out with this. They are grandmasters 
when it comes to writing spec files.

> It looks like I'm going to try to find a place to post them...here is a
> list of the RPMs I created...if anyone has quite a bit (like 300-400MB -
> total for working suse binary kolab distribution and my src rpms.) of
> server space that they are willing to share, I'd appreciate it.

What about ZfOS? Or even kolab.org?