Hi. Good comment about the Binary v Source - thats actually the strength of this recipe as I a see it, it blends source packages and provides a neat rpm install
The challenge is not so much the disk space as the memory requirement to compile clam on the machine once the machine is deployed - man I dread the freshclam message (despite the large friendly letters ) DON'T PANIC! *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 3/05/2011 2:14 AM, Dan McAllister wrote: > Just to throw my 2-cents worth in here... > > Binary packages are fine in a well-controlled environment, but source > packages offer far more flexibility -- especially if the Makefiles are > sophisticated enough to recognize advanced features and take advantage > of them (without REQUIRING them). And while binary packages of > SpamAssassin and ClamAV are likely available in binary form (and it > may not be a bad idea to make the QMT dependent on the "standard" > installation features and locations of each of these), the fact is > that QMT grew up in a time when QMail itself was REQUIRED to be > distributed in a source format -- part of the licensing requirement of > Daniel Bernstein, author of QMail. (I don't think that's true anymore, > since Daniel put QMail truly into the Public Domain, but I never > worried about that so I'm not totally up-to-date on QMail licensing > requirements). > > NOTE: I already use QMail in a VM environment (CentOS 5.6 is the host > OS, Xen is the VM environment, and CentOS 5.5 is my current guest OS > running QMT -- I'll update that at some time in the future, but I'm > honestly expecting to wait for CentOS 6 before I upgrade the base QMT > again). The point is, you are right that there is a sizable disk-space > requirement to rebuild the entire QMT from source (*esp*. ClamAV)... > but there is an easy way to "patch" that! Specifically, I mount an NFS > volume from my Xen Host to supplement my Xen Client's storage while I > build, then unmount and destroy the "temp space" when I'm done. > > NOTE: For ME this works especially well because I administer so many > QMT installs -- I update the VM image, then "distribute" it to my > clients. All of their actual data (the queue, the mailboxes, the > control folder, etc.) are kept on NFS-mounted drives on the HOST OS -- > so only the binary QMT is actually run on the Xen-Client... this is > not a NORMAL config, and wouldn't be MY config if it weren't for my > need to manage so many installs at the same time. > > Take from this what you wish -- discard the rest. It's worth every > penny you paid for it! > > Dan > IT4SOHO > > On 4/30/2011 1:23 AM, Martin Waschbüsch IT-Dienstleistungen wrote: >> Am 30.04.2011 um 05:40 schrieb David Bray: >> >>> Thanks for the Feedback >>> >>> Understand about the Fedora Lifetime etc. I use VM's and Fedora 13 is the >>> current Fedora. Tried Ubuntu, CentOS and keep coming back to Fedora - >>> mainly because the php is more up to date >>> >>> The driving line is not so much SA - SpamAssassin as Clam, on my last >>> server - Fedora 12 based, there was an issue with spam and the update to SA >>> 3.3 did get me into later rule sets (via sa-update) >>> >>> You can - in the Fedora 13 case, substitute in yum install spamassassin >>> with little difficulty, basically install the package, it pulls in what it >>> needs, then create the scripts to run under daemontools. >>> >>> The clamav is harder, but I have it running, though untested. The end aim >>> is just to let the rpm system update clam, rather than having to recompile >>> to src rpm >>> >>> so why is that so bad ? >>> >>> well the toaster works fine on a VM with 20Gb HDD and 512k ram .... but to >>> recompile the clam package you have to stop the services to free up memory >>> ... so having a recipe for utilizing then yum package is nice ... >>> >>> which brings you back to your argument, Fedora 13 will only have a short >>> life for clamav updates via yum .... >>> >>> >>> David Bray >>> http://www.brayworth.com.au >>> da...@brayworth.com.au >> Not everything is perfect with QMT, I would agree, but at the same time: it >> works! And as Eric pointed out, CentOS / RHEL 5.x is the most current >> version of the recommended OS for QMT. >> Jake is working on QMTv2 which will incorporate some changes and it will >> actually address some of the things you mention (like an option to just >> install binary packages instead of compile from source). >> That being said, if you'd like to help with QMT, please join the >> qmailtoaster-devel list as well! >> >> Cheers, >> >> Martin >> --------------------------------------------------------------------------------- >> Qmailtoaster is sponsored by Vickers Consulting Group >> (www.vickersconsulting.com) >> Vickers Consulting Group offers Qmailtoaster support and installations. >> If you need professional help with your setup, contact them today! >> --------------------------------------------------------------------------------- >> Please visit qmailtoaster.com for the latest news, updates, and >> packages. >> >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> >>
