Sam,
I don't bother with Solaris since Oracle closed the source. Instead I
use the open-sourced branch for the kernel called Illumos which is being
developed by the upstream commercial distros as well as other contributors.
There are three main distributions for x86 platforms.
OpenIndiana -- This is the continuation of OpenSolaris. Good for server
and desktop. This was the distribution I have used for years. There is
a lot of reorganization (compilers, userland, etc.) recently which tends
to break things. The package repositories are also in flux as well
(broken dependencies). It's a good distro but no longer stable and no
reasonable release schedule.
SmartOS -- You can get support from Joyent. It's a cloud-based
implementation and the OS is booted from USB drive to provide a memory
resident hypervisor. It has regular releases and uses NetBSD pkgsrc as
it's package system which has pretty much everything you'd want
(including spamdyke). It's designed for VM farms.
OmniOS -- You can get support from OmniTi. It's a minimalistic server
with regular releases (bloody, stable, LTS). It comes with IPS but you
can use pkgsrc from SmartOS as well. This is the distro I'm moving to.
It's very stable. IPS is nice because it allows you to freeze and
rollback packages. However, it's hard to find something missing in
pkgsrc so that's what I've chosen for my userland.
I've worked with several Linux distros (my company is a Linux house) and
have found they need much more care than illumos-based servers.
SInce we're just using qmail backend as a delivery agent, I'm not sure
what the strength of a proxy-based approach is other than to broaden
it's appeal (which makes a lot of sense). However, it's spamdyke that
kept me using qmail for so long.
Gary
On 8/18/15 8:05 PM, Sam Clippinger via spamdyke-users wrote:
That's good to know, thanks for posting that info. I'm always amazed
to hear people still use Solaris any more... I endured it a few years
ago because ZFS was worth the pain, but finally had to abandon it
because it was impossible to get security updates without an
enterprise contract.
spamdyke's next version is nearly ready but I'm still running tests.
It fixes the recipient validation code in spamdyke-qrv when vpopmail
is being used, which has increased the number of test scripts to 4-6
million (from about 200K-300K). So it's taking a lot longer to test
(about 2 weeks straight on 20 EC2 instances). They say familiarity
breeds contempt, and lately I've become very familiar with vpopmail's
code, so it's very hard to regard it with anything but contempt. I'll
write up a complete rant about it later; for now I'll just say I will
never install it on a new server again and I'm giving serious thought
to deleting it from my current server. If anyone out there has
vpopmail running on a server where users can edit their own .qmail
files inside their mail folders, be very very afraid. Crashes and
fork bombs are easy to do and cooking up a denial of service attack
would probably be simple. I haven't been looking for exploitable
holes, but I'm positive they're in there.
Anyway, sadly spamdyke's next version doesn't include any
earth-shattering features but it does add one small thing -- the
ability to block authorization attempts unless SSL/TLS is active.
IPv6 is certainly on my radar, but frankly I'm far more interested in
adding a real "proxy mode" to spamdyke so it will work with other mail
servers beyond qmail. Qmail has become an anachronism and I'm
convinced it's time to let it go. If spamdyke can forward connections
from port 25 to port X while doing all the filtering it does now, it
should work nicely with just about any other mail server.
-- Sam Clippinger
On Aug 18, 2015, at 12:03 PM, Gary Gendel via spamdyke-users
<spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org>> wrote:
I use port 22 for non-auth mail and 587 for TLS with auth mail. On
587 I ended up using postfix because I could never get spamdyke
working. It always failed valid authorizations.
I was putting together a new server and I decided to take another
look. The problem ended up in the checkpassword-pam module on
Illumos (Solaris). Illumos (and possibly other Unix derivatives)
require that pam has PAM_TTY set before starting a session. The
checkpassword-pam module doesn't do this. I posted a bug report but
my solution was to add the following code just before opening the pam
session (in pam-support.c).
retval = pam_set_item(pamh, PAM_TTY, "/dev/null");
if (retval != PAM_SUCCESS) {
fatal("Setting PAM_TTY failed: %s", pam_strerror(pamh, retval));
return 1;
}
I just thought I'd send this information along in case anyone else
was having issues with spamdyke authorization.
Sam,
How's the "next gen" version coming? Will it support IPv6?
Gary
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org <mailto:spamdyke-users@spamdyke.org>
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
