Quote:
I don't mind using the shell. I can forget about GUI since this is the strongest point of Linux. Most of the settings shouldreally be done on the shell.
|
Only on desktop. GUI is of no use on a server specially if your too concern about security and resource conservation. Running unnecessary processes not just consume vital resources but may create vulnerabilities and put more burden when performing updates and your administration/troubleshooting skill will not advance. If you prefer GUI, just stick with windows and this is how Unix/Linux/BSD is differentiated. Even Longhorn, as I've read from an osnews.com review, is now switching to command line administration in order to reduce its codebase and in the hopes of improving security.
Quote:
I tried installing it on my newly installed CentOS 4.4. Most of my friends told me that CentOS 4.4 is a 100% rebuild of the Red Hat Enterprise. I got an error on courier-authlib section. The error says it has something to do with /lib/cpp.
|
This is not to discourage or to mean saying that a distro like this is not good. Each of the distro has its own strong feature/s or point/s. I've also tried CentOS, but only for a while because I want the one that would allow me to customize and specially if I want the latest stable release which as hot as a hot cake just taken out from a pan (or even an eagerness to try a release candidate) - compiling from source is the only way. This is the main reason that this method is not loosing in popularity and will not in any way for sure. Gurus love doing this.
I've even tried Ubuntu and OpenSuSE, and just the same, only for a while due to what have been mentioned above. I'm as well a loyal user of OpenBSD but when it comes to this kind of application, she's not a very good choice because there are some source compilation issues due to its strict security policy or that might have been due to its ProPolice patch on GCC. Not all compiles well from source like with PCRE (but its nice having a port at v6.4) and with ClamAV I have to wait for the port update within 1 - 2 weeks, and sometimes even longer but its not too late still. But OpenBSD is my only choice when it comes to firewall/gateway/router/IPSec VPN - so easy to use and proven secure. Its open source IPSec VPN is easy to deploy.
Thus we need balance in choices, like the food that we eat. We can't just stick with one, there should be some other else and in choosing/deciding, objectivity should be our guiding light and not emotions. This is the main reason why our universe and our earth was created in diversity to make our lives more enjoyable.
So for me, Slackware is FREEDOM and a versatility in simplicity! Slackware is really true to its words - making use of Linux simple. And allow me to add one - ENJOYABLE. ( BTW: Slackware has now a port of AppArmor though still in beta stage.
http://danieldk.org/apparmor/ ).
I actually started with RedHat 9 before trying Slack. Then after some happy moments with Slack, I went with OpenBSD (after it was introduced to me by an American open source enthusiasts now living here) during the time it was at version 3.5 and up to now (v4.0) and until the time when my old age will prevent me on typing to my keyboard and inserting CD on my drives and my eyes blur my console screen.
I don't want to make this long since this is not a review thread specific to a distro.
A note on ClamAV:
ClamAV will search for the openssl.pc during compile time. pc is package-config used to aid on searching for an installed program dependency. If you installed OpenSSL from a package, there should be no problem since most definitely, it is installed on where it should be - /usr/lib/pkgconfig or /usr/local/lib/pkgconfig. In my case I've installed it from source so it is in /usr/local/ssl/lib/pkgconfig. Just add to your environment variable the exact path:
$ export PKG_CONFIG_PATH = "/usr/..path/..path/pkgconfig"
$ ./configure
Also, don't run ClamAV as its own user name to give it a write access to amavisd-new's directory. I think this is not noted on the howto. If you don't do this, you endlessly see access denied error in your postfix logs and might as well affect its performance.
Code:
--disable-clamav \ # disable searching for user clamav
--with-user=amavisd-user \
--with-group=amavisd-group \
But do this after you have already installed Amavisd-new. The best thing to do when installing amavisd-new is simply read the included INSTALL text file with the source program.
Also for security's sake, I don't usually give login shell to daemons/programs when their usernames are created.
# groupadd amavis
# useradd -c "Amavis SMTP Proxy" -d /dev/null -s /bin/false -g amavis amavis
This is practical and very important, because they don't have passwords. Also don't always forgot to disable remote root login in sshd and allow only your useradmin name to logon since they can use mysql, amavis, postfix and other well known daemon users during brute force ssh dictionary attacks if your host connects directly to the internet.
/etc/sshd/sshd_config:
PermitRootLogin no
AllowUsers admin1 admin2
Make it to the least number of admin users for AllowUsers although we believe that the more is merrier but in security it is the opposite - grimmier.
The most practical thing to do when compiling is to save your configure option to a file like
filename: build.sh
Code:
./configure \
--sysconfdir=/etc \
--localstatedir=/var \
--madir=/usr/local/man \
--sbindir=/usr/local/sbin \
--others \
--etc \
--the last (no backslash)
Then:
$ sh build.sh
This is very usefull because sometimes, one ./configure run is not enough due to errors and you will tire out and prone to errors typing the options repeatedly. Then in order for you to save the output to a file for convinience on checking:
$ sh build.sh 2>&1 | tee build-messages
$ less build-messages
or
$ grep openssl build-messages
That file is now saved for future reference and in times that you will compile a latest release, just grab the original copy of the build.sh from the previous version directory. So it is advisable not to delete immediately the directory after successfully compiling. Just 'make clean' is enough.
To further add, as one of the many reasons why it's best to choose postfix, there is a Japanese contributor that created things like S25R and a patch for Postgrey for Tarpitting and combining S25R. Just google for S25R and go for an english version of its site. I'm already using this both on our own and the one I've intalled for a government hospital guarding their exchange server against spam and viruses. This is a strenghtening patch for postgrey because spammers are now getting even more smarter. Some knew now how to retry and most of them are getting dynamic/PPPoE lines for this purpose and S25R is designed for them. In a simple explanation, S25R will prevent or make it harder for the spammers sending direct from their subscriber lines through its regular expression rules. So it is nowadays wise to accept mails only sent through legitimate MTA and not those direct from workstations since mostly, it is a spam or might be zombies with spambots.
http://k2net.hakuba.jp/pub/targrey-0...rey-1.27.patch
http://k2net.hakuba.jp/spam/postfix.conf.2.tar.gz
http://k2net.hakuba.jp/pub/postfix-sleep.patch
/etc/postfix/main.cf:
Code:
... others ..
...
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_etrn_restrictions = reject
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_client_access hash:/etc/postfix/whitelist_client
check_client_access regexp:/etc/postfix/permit_client_nots25r
check_recipient_access mysql:/etc/postfix/mysql-recipient.cf
reject_invalid_hostname
reject_non_fqdn_sender
reject_non_fqdn_hostname
reject_unknown_sender_domain
reject_non_fqdn_recipient
reject_multi_recipient_bounce
check_policy_service inet:127.0.0.1:10023
check_client_access hash:/etc/postfix/prepend_client
check_sender_access regexp:/etc/postfix/filter_10024_catchall
permit
smtpd_data_restrictions = reject_unauth_pipelining
The fileter_10024_catchall is needed only if you installed dkim-filter. The files permit_client_nots25r, whitelist_client and prepend_client are in postfix.conf.2.gz. It is good to unpack that file within /etc/postfix and just copy or point that to that path.
postgrey startup arguments:
Code:
/usr/local/sbin/postgrey --inet=10023 \
--pidfile=/var/spool/postfix/postgrey/postgrey.pid \
--dbdir=/var/spool/postfix/postgrey \
--user=postgrey --group=postgrey \
--tarpit=65 --retry-count=2 \
--auto-whitelist-delay=3600 \
-d
Or create a start|stop|restart script out of this.
This is how I managed to install postgrey:
$ tar xvzf postgrey-1.27.tar.gz
$ patch -p0 < targrey-0.30-postgrey-1.27.patch
If it erred, change p0 to p1.
$ cd postgrey-1.27
$ su
# cp postgrey /usr/local/sbin
# chmod +x /usr/local/sbin/postgrey
# cp postgrey_whitelist_clients /etc/postfix
# cp postgrey_whitelist_recipients /etc/postfix
# groupadd postgrey
# useradd -c "Postfix Policy Service" -d /dev/null -s /bin/false -g postgrey postgrey
# mkdir /var/spool/postfix/postgrey
# chown postgrey.postgrey /var/spool/postfix/postgrey
Apply the sleep patch for postfix before doing compilation.
$ tar xvzf postfix-2.3.4.tar.gz
$ cd postfix<TAB>
$ patch -p0 < ../postfix-sleep.patch
Some manual pages that needs your attention:
$ perldoc postgrey
$ man postqueue
$ man postsuper
SpamAssassin's (SA) docs are accessed also using 'perldoc docname'.
This is how I've read to update SA rules and I'm so sure if this is just the things need done:
# sa-update
# ls /var/lib/spamassassin
3.001006 3.001007
That shows two directories both for 3.1.6 and 3.1.7 versions. I'm currently now using 3.1.7 and the pervious one is still there.
# /usr/local/sbin/amavisd -u amavis reload
That command is needed for me becuase I prefer to use SA within Amavisd-new. But if it is just integrated in your case with maildrop, no need for that. But I'm sure there is nothing wrong on using SA both in maildrop and amavisd-new.
------------
GANI