Hello, I have spamassassin installed in webmin but it isn’t showing up in my Virtualmin.
I haven’t set up any servers yet, but it still isn’t displayed under Virtualmin -> System Settings -> Features and Plugins
as “Spam Filtering”
as I’ve seen in other installations. How do I get this enabled/installed?
Did you use our automated install script? Sounds like no. If at all possible, we’d recommend you start with a freshly installed supported OS and run install.sh, which will install all dependencies and configure them correctly for use with Virtualmin.
If this isn’t an option: Are you sure you have SpamAssassin installed? The SpamAssassin Webmin module is not the same as SpamAssassin. It is a GUI for controlling SpamAssassin. But, you have to install SpamAssassin separately (we recommend using packages provided by your OS).
Yes, I am sure that it is installed and working correctly. Starting a fresh install unfortunately is not an option.
Output from spamassassin:
$ spamassassin -V
SpamAssassin version 3.2.4
running on Perl version 5.8.5
If I copy over the spam, spamclear, spamclear.pl, etc from another installation and change the config files to point ot the right things, would this work?
It should also be noted that I haven’t set up any virtual servers yet, I don’t think this really matters though.
Is there any other information that would help you give a informed response to getting this feature enabled?
Thanks for your time!
When you say it’s not an option, where are you looking for that? For example, does “spam filtering” show up in Features and Plugins?
-Eric
From original post:
It additionally doesn’t show up anywhere else in the virtualmin panel. It does show up (and is working) in the webmin panel. Let me know any more info I can provide. Thanks!
Sorry, that’s what I get for trying to help quickly without reading the entire thread 
You may need to go into Webmin -> Servers -> SpamAssassin -> Module Config, and verify that all the paths for the various SpamAssassin components are correct.
I couldn’t really say whether or not copying that from another server would work… it depends on a lot of factors
-Eric
All info in webmin module config is there and module is functioning correctly…
After you’ve confirmed that SpamAssassin is configurable in Webmin (but please don’t use the Webmin module to setup procmail, as that conflicts with the way Virtualmin uses procmail), run the configuration check in Virtualmin. Then look in Features and Plugins again. I’m guessing Webmin didn’t know about SpamAssassin to start with…the only reason spam options wouldn’t show up is if the tools Webmin needs to perform spam filtering aren’t present. You also need procmail (make sure Webmin knows about it, too), and procmail-wrapper if you’re using Postfix as your mail server (depending on your OS, we may have prebuilt packages for you, or you may need to compile and install it yourself).
Hmm… this still isn’t working. I can verify that webmin can edit spamassassin settings but virtualmin after recheck still isn’t picking it up.
If I attempt to reinstall as was originally suggested. Is there a way to make sure that things are going to be set up the same as they are now? If I uninstall/reinstall it also doesn’t uninstall any packages that are currently in place like stat reporting, etc, etc?
Will the re-install find everything that was there before?
Is there anything else I can do to troubleshoot the spam filtering optinos in virtualmin?
Don’t reinstall. Because the answer to “Will the re-install find everything that was there before?” is no. Uninstalling Virtualmin deletes Virtualmin and Webmin’s metadata…like users, mail preferences, and tons of other stuff. Of course you have backups (everybody has good backups, right!?!), but you don’t want the hassle of that just to find that the problem you’re trying to solve still exists. Why would it be different on reinstall? Are you planning to install differently than you did last time? I don’t really understand the mind-set of thinking a reinstall will do anything useful…doing the same things and expecting different results isn’t really the right way to solve problems. 
I’m not sure if you answered my question about how you installed to start with. Did you use install.sh? (If the answer is “no”, and you could now safely start over and use install.sh, then you should definitely do so. If you already have virtual servers setup, then you can’t “safely” start over.)
What OS are you running?
If an RPM based distro, what is the output of the following:
rpm -q spamassassin
rpm -q procmail-wrapper
rpm -q procmail
rpm -q virtualmin-base
rpm -q webmin
webmin-1.470-1.rs
Thanks again for your time!
OK, multiple problems.
You need procmail-wrapper. Get it from our repos. (http://software.virtualmin.com/gpl/centos/4/i386 or x86_64)
This is not a full Webmin. Rackspace has a custom Webmin that has been stripped of a number of necessary modules. I don’t know if it’s missing any related to spam, but you definitely need to switch to our Webmin package.
There are docs about Rackspace systems here:
I can see the issues here, everything is much clearer now!
I haven’t actually started using Virtualmin yet, only have it installed. Would it be ‘wiser’ to just go ahead and get a clean install as I don’t have any ‘meta-data’ stored yet?
I do use webmin itself fairly extensively.
What possible difficulties would I be looking at with a clean install?
Thanks for the help thus far.
Yes, if installing fresh is a good and safe option for you, I would recommend it. Installation of the Virtualmin-related software (like Postfix, Apache, procmail, Dovecot, SpamAssassin, ClamAV, etc.) and configuring it in a reasonably nice way for virtual hosting is a non-trivial task and takes a lot of work. Most of it really isn’t even Virtualmin related. It’s just the stuff you have to do to setup a full-feature virtual hosting system with reasonable security, decent spam and AV filtering, and reasonable mail functionality. And install.sh just happens to do it in a way that Virtualmin is configured to work with, by default (which saves you an additional bunch of steps, since you don’t then have to teach Virtualmin what your system looks like).
The difficulties should only be those documented in the link above. If you follow the necessary steps to kill off their Webmin package, and make sure it never comes back (by making sure yum knows not to install it), the installation should go as smoothly on a RackSpace system as on any other CentOS 5 system. Which is to say, "very smoothly".
Oh, wait, just realized you said RHEL 4. Why did you choose RHEL4? That’s a pretty old system at this point. RHEL 5 would be a better choice for pretty much anything, if you have the option.
But, RHEL 4 is historically pretty well supported and tested, but it’s been a long time since we had anyone report good or bad things about it, so I don’t know if there have been any changes in the install that might break on older operating systems.
Yeah, if you’re considering a clean install, you might find that you have a much more recent system – more up to date packages and the like – by going with RHEL 5, or perhaps even CentOS 5 if cost is an issue.
And if you hadn’t used the install.sh script to get things up and running, you’ll find Virtualmin much more awesome after using it, as all sorts of stuff comes configured out of the box!
Just make sure you read the link Joe posted above before performing the Virtualmin install
-Eric
Well, this is a production server at the moment so starting over from scratch completely really isn’t an option. Will things not work as expected if I don’t use RHEL 5 and more recent packages?
Ah, I misunderstood you when you said, “Would it be ‘wiser’ to just go ahead and get a clean install as I don’t have any ‘meta-data’ stored yet?” I thought you meant “clean install of the system”.
I don’t exactly know what you mean. What more recent packages? Our Virtualmin packages from the virtualmin-universal repo should work on any RPM-based distribution, including RHEL4. All binaries should be coming from repos that are built explicitly for your OS and version (so the virtualmin repo ought to be pulling from /centos/4/i386 or /centos/4/x86_64). It wouldn’t be safe to mix and match builds intended for RHEL5.