I haven’t posted in a while and I figured I was due. I usually blog specifically for Linux users, but this really applies to anyone on any operating system (Apple, Microsoft, Android, etc).
I want to encourage the use of a password manager to anyone not already using one. There are a lot of them out there, but I’m specifically interested in focusing the attention on KeePassX. There are a number of reasons why and I’ll eventually get to most of them. But for starters KeePassX is completely free (GPLv2) and as I mentioned above, it works on just about every platform!
It’s sole purpose in life is to remember passwords for you so you don’t have to. It’s used to prevent you from using the same 1-3 passwords you’re using today for everything. Instead of using your birthday, engagement and/or pets name, you’ll use passwords like: JP83bW93wwrJsZ2x6tQy3aD6W or SLJUhoQWPBRtwTwmzsCxWXqOV. Again, I emphasis that the password manager does all the memorizing for you. Not only that, but it’ll easily generate you these passwords too.
KeePassX InterfaceNow before you roll your eyes and decide you don’t need such a thing, just here me out. Give me a chance to sell you the reasons why you seriously need to consider this. I’ll attempt to do this with respect to The 5 Stages of Loss and Grief.
Stage 1: Denial
What’s the point of a password manager? I never needed one before!
A password manager is kind of like social media was to us back in February of 2004. The ideology is the same: “You didn’t know you needed it until it was shown to you”. So trust me when I tell you that you need one now. The thing is, the internet is filled with people whose sole intent is to gain access to your identity and exploit it for their own personal gain. The passwords we’ve all used up to this date are too simple; I know this because we’ve all remembered/memorized them. Even the complicated ones we confidently memorized are no good.
Food for Thought
Most of us just acknowledge there is risk, but we do nothing about it. We belive that if no one has figured out our password yet, they never will. Well the scary thing is: some of them might know our password(s) already. But these people don’t want to make that evident to us. Don’t expect someone to advertise themselves once they’ve gained access to something we had protected. Instead, you’re only going to find out once the damage has been done.
Stage 2: Anger
Why would I put all my passwords in one file? Something just sounds wrong with that statement.
You would do it for the same reason you trust a bank’s security with your money. The same reason you trust your wallet or purse with your personal identity. The same reason you go to work and secure all your belongings and pets behind in your home. We put all of our eggs into one basket every day, but we’re all smart about it. We all put trust in the decision that our belongings will remain in tact until we return to it. KeePassX works exactly the same way.
Both a Password and a Key File can be used keep your password database safe.The passwords that reside in your KeePassX database are encrypted, so no one will gain access to it unless you allow it to happen. The encryption means the password database is completely useless to anyone who has it without the keys required to access it. You can even go as far as to lock it using a keyfile (KeePassX will generate for you) as well as a password.
There is no question that if a hacker gains access to your password database and has all the keys he/she needs to unlock it, then you’ve defeated it’s purpose. Your passwords are only as secure as the conscious effort you take to keep them that way. If you keep the keys to your house under the welcome mat, or your car keys in the vehicle they pair with, it’s just a matter of time before you suffer a theft in that regard too.
Stage 3: Bargaining
Can’t I just change the passwords after I read about the compromising?
The answer is No and here is why:
People are attempting to exploit us ever day through phishing, viruses, spyware, false advertising, and even through everyday tasks we didn’t even know we were a victim of. Take Sony and eBay for example. Both are very reputable companies with an entire team of security experts working with them every day, yet they still fell prey when their systems were compromised by a hacker. As a result, it’s the clients and customers that become the victims too (all of us). If you used the same password on these sites as you do everywhere else, then you’re already at risk for identity theft. The point is, sh*t happens and sometimes it’s just out of our control.
We can’t expect every organization to be like eBay and Sony either. Not all of them will alert their customers of the threat they faced or the security breach they sustained. The few that do go public may have been exploited long before they did. Hence, our personal information was at risk last week when they told us today. There are even some companies who don’t want to admit to any privacy invasions to protect their own reputation. Then there are the companies that might not even know they’ve already been compromised. So if they don’t tell us; how will we ever know?
Therefore, consider taking the extra time to change every password on every site you visit once you get KeePassX installed.
Stage 4: Depression
I don’t want to change my password everywhere. I don’t want the burden of a another application just to manage my passwords.
I was stuck at this stage for a while. It takes a while to change passwords everywhere. But after it’s done, you have to remember that this program does absolutely everything in its power to make your life easy from this point on. You only need to add everything once; so the burden doesn’t linger.
How can such complicated password make my life easier?
Ctrl+B and Ctrl+C are all you ever need to use once KeePassX is setup.Your life ‘will’ be simpler with KeePassX because your every day tools are now accessible by just a few keystrokes:
Press ctrl-b in Password Manager: Copy the username into the clipboard
Press ctrl-v in Web Browser or App: Paste the username (into the username field)
Press ctrl-c in Password Manager: Copy the password into the clipboard
Press ctrl-v in Web Browser or App: Paste the password (into the password field)
That’s it; don’t worry about the password (you just copied) being left in the clipboard. KeePassX looks after clearing the clipboard after a few idle seconds elapse that you configure (the default is 20 seconds). The point of me explaining this is: instead of memorizing your secret passwords you use everywhere, you only need to remember the 4 key combinations identified above. The same 4 keystrokes are used for all sites/apps you ever use/visit from this point forward. Not to mention that each password is a unique from the other and unguessable by any hacker. I can’t stress enough that the effort level decreases with a password manager. At the same time your online privacy is more secure than ever.
Stage 5: Acceptance
What about my Phone? What about my other computer? Can access my password file on other systems?
Yes! This is one of the most amazing features of KeePassX! People even place their password file on locations such as DropBox or their Google Drive so they can access it between the systems. It’s compatible with Microsoft Windows, Mac OS (including Apple iOS), Android, and Linux (of course!).
So Where Do I Get It?
Microsoft Windows and Mac OS users can just download it directly from the download area at the official KeePassX website here.
KeePassX Password Generator will keep your passwords diverse and complicated.
For obvious reasons, password protect your password database. This is the one password you ‘will’ need to remember. So I encourage you to use a new original one, but don’t forget it!
Consider using a keyfile as well as the password for securing your password database. The nice thing about the keyfile is you can move it with you; keep it on a usb drive that is kept with you or in another location. This way if someone ever did get a hold of your password database, they can’t do anything without the key file even if they know your password.
Configure KeyPassX to lock itself after it’s been idle or minimized. By default it won’t, but it’s a simple option that will allow you to walk away from your desk and know that no one is snooping where they shouldn’t be.
Log onto your remote sites and consider changing your passwords every now and then. Even if it’s only once a year. Just changing your passwords annually is still better than never changing them at all! You can optionally configure KeePassX to remind you to change your passwords after they get to a certain age. Just using the built in password generator will greatly simplify your life and keep your passwords complex.
Speaking of Passwords…
Consider that your neighbors (or even someone you don’t know) could be using your wireless network while you’re at work. They could be using it even when your around. Have you been connecting to your wireless router lately to see if you can account for everyone connected to it? Now would be a good time to change this password too!
Pay attention to the sites you use and make sure they use some form of login encryption. For example, logging into a website that isn’t secure means anyone can easily extract your username password combination without your knowledge.
May 2014 – eBay announces it was hacked and forces all users to change their password on their next login
April 2014 – Heartbleed Exploit potentially compromised millions of systems and had been doing so since December of 2011. The amount of privacy breaches that occured over the 3 years this bug went undetected for is scary to think about.
April 2011 – Sony gets hacked and loses 77 million customers passwords to hackers. It took them a full week before they made it public.
Just do a Google search for +breach +password +hacked to get an idea of how many companies are getting hacked constantly and how easy it is for someone to figure out your password and re-use it elsewhere.
Final Notes
Sure, Password Managers aren’t for everyone; don’t worry, I get that. But if you truly want to prepare yourself and prevent having to deal with unnecessary online fraud, or identity theft… If you truly wasn’t to avoid venturing through The 5 Stages of Loss and Grief which follows these awful crimes, then you should consider protecting yourself now. Take the plunge and get a password manager and diversify your passwords.
It’s better to be safe than sorry.
Credit
If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. It’s really all I ask.
As you know, Mail Server tutorials are all over the internet. So if you stumbled upon mine, then you were like me trying to assemble one based on how others do it to save reading the manual. A mail server is NOT a walk through the park like some other servers are (such as Web, Database, etc). They can be very complicated to master; and frankly, when you’re short on time, it’s easier to just get one going right away. Don’t dismiss the need to learn how it works once you’ve set it up otherwise you may not know how to recover from a unexpected situation. But instead, learn about how it works (and how to further tweak it) after the deadlines have been met. Besides, your boss will be impressed when you show him your successful results sooner then later.
You’re reading this blog because your needs were/are similar to what mine were:
You’re looking for an automated solution to installing a mail server with little effort because you’re on a tight deadline.
You want a central configuration point; you want everything to be easy to maintain after it’s all set up.
You want everything to just work the first time and you want to leave the figuring it out part to the end.
Package management and version control is incredibly important to you.
Here is what my tutorial will be focused on:
A Database Backend (PostgreSQL) giving you central configuration. This tutorial focuses on version 8.4 because that is what ships with CentOS and Red Hat. But most (if not all) of this tutorial should still work fine if you choose to use version 9.x of the database instead.
Spam Control (SpamAssasin v3.3.x, Amavisd-new v2.8, and Clam AntiVirus v0.98) gives you some spam and anti-virus control. I’ve been looking into DSPAM but haven’t implemented it yet. I figure I’ll make a part 2 to this blog once i get around to working with it and mastering it’s setup.
Dovecot Pigeonhole v2.0.x provides you a way of routing mail in the users inbox based on it’s content. You can key off of certain content within a received message and mark it as spam, or flag it as important because it was sent by a certain individual, etc. It basically gives you the ability to custom some of the post processing of a received message that passed through all the other checks (spam, anti-virus, etc).
Security Considered
Mail Delivery Agent (MDA) (DoveCot v2.0.x):
Secure POP3 (POP3S) Access
Secure IMAP (IMAPS) Access
WebMail (RoundCube) Access
MDA Configuration
Mail Transport Agent (MTA) (PostFix v2.6.x): Secure SMTP (SMTPS)
MTA Configuration
Web Based Administration (PostFixAdmin v2.3.6). Life is made easier when you don’t have to do very much once everything has been set up. Run your server like an ISP would:
Virtual Domain Administration: Add/Remove as many as you want
Unlimited Virtual Aliases (or restrict if you want) per domain
Unlimited Mailboxes (or restrict if you want) per domain
Administrative Delegation: Grant enough privileges to another administrator who only has rights to his/her domain you granted them access to.
Away on Vacation Support (automatic replies)
Central Configuration
Please note the application versions identified above as this tutorial focuses specifically on only them. One big issue I found while researching how to set up a mail server was that the other tutorials I found didn’t really mention the software versions they were using. Hence, when I stumbled upon these old article(s) with new(er) software, it made for quite a painful experience when things didn’t work.
Please also note that other tutorials will imply that you setup one feature at a time. Then test it to see if it worked correctly before moving on to the next step. This is no doubt the proper way to do things. However, I’m just going to give it all to you at once. If you stick with the versions and packages I provide… If you follow my instructions, it will just work for you the first time. Debugging on your end will be a matter of tracing back to see what step you missed.
I tried to make this tutorial as cookie cutter(ish) as I could. Therefore you can literally just copy and paste what I share right to your shell prompt and the entire setup will be automated for you.
Hurdles
Just to let you know, I had many hurdles in order to pull this feat off. They were as follows:
postfix as shipped with CentOS and in the EPEL repository is not compiled with PostgreSQL support. I had to recompile this package as well just to enable this extra database support.
postfixadmin in the EPEL repository has qwirks I wasn’t happy with. I needed to fix a php error that kept coming up. I needed to adjust the database schema and permissions as well as fixing the Vacation Notification feature. I also did not want the mandatory MySQL dependency; so I removed that too.
perl Yes… that’s right, I had to patch perl :(. I had to recompile it due to a bug that I don’t belive was correctly addressed. In a nutshell, prior to my custom rebuild, perl-devel would haul in absolutely every development package including kernel headers and the GCC compiler. In the past the perl-devel package could be installed by itself providing us some tools spamassassin and amavisd-new depended on. You’re welcome to use the official version of perl over the one I recompiled; but be prepared to have a ton of compilation tools and source code in your production environment. This is not something I wanted at all. Interestingly enough; after the developers at RedHat said they wouldn’t tackle the issue of rolling their changes back, they seem to be entertaining this new guy’s request who’s asking for a similar alternative. So who knows, maybe newer versions of perl will accommodate mail servers again!
This blog itself was a massive hurdle. There are just so many configuration files and important points to account for that I found it easier to package my own rpm (nuxref-templates-mxserver) containing a series of configuration templates. The templates themselves took a while to construct in such a way that they could all be used together.
Installation
The following seven steps below will get you up and running.
Step 1 of 7: Setup Your Environment
This is the key to my entire blog; it’s going to make all of the remaining steps just work the first time for you. All; I repeat All of the steps below (after this one) assume that you’ve set this environment up. You will need to reset up your environment at least once before running through any of the remaining steps below or they will not work.
# The commands below should all work fine on a PostgreSQL v9.x
# database too; but your mileage may vary as I've not personally
# tested it yet.
# Only init the database if you haven't already. This command
# could otherwise reset things and you'll loose everything.
# If your database is already setup and running, then you can
# skip this line
service postgresql initdb
# Now that the database is initialized, configure it to trust
# connections from 'this' server (localhost)
sed-i -e 's/^[ t]*(local|host)([ t]+.*)/#12/g'
/var/lib/pgsql/data/pg_hba.conf
cat<< _EOF >> /var/lib/pgsql/data/pg_hba.conf
# Configure all local database access with trust permissions
localall all trust
host all all 127.0.0.1/32trust
host all all ::1/128trust
_EOF
# Make sure PostgreSQL is configured to start up each time
# you start up your system
chkconfig --levels 345 postgresql on
# Start the database now too because we're going to need it
# very shortly in this tutorial
service postgresql start
To simplify your life, I’ve made the configuration of all the steps below reference a few global variables. The ones identified below are the only ones you’ll probably want to change. May I suggest you paste the below information in your favorite text editor (vi, emacs, etc) and adjust the variables to how you want them making it easier to paste them back to your terminal screen.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
# Identify the domain name of your server here
DOMAIN=nuxref.com
# Setup what you want to be your Administrative email account
# Note: This does 'NOT' have to be of the same domain even though
# thats how I set it up to be. Don't worry if the email
# address doesn't exist, because when you're all done
# following this blog, you'll be able to create it!
ADMIN=hostmaster@$DOMAIN
# The following is only used for our SSL Key Generation
COUNTRY_CODE="7K"
PROV_STATE="Westerlands"
CITY="Lannisport"
SITE_NAME="NuxRef"
Now for the rest of the global configuration; There really should be no reason to change any of these values (but feel free to). It’s important that you paste the above information (tailored to your liking’s) as well as the below information below to your command line interface (CLI) of the server you wish to set up.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# PostgreSQL Database
PGHOST=localhost
PGPORT=5432
PGNAME=system_mail
# This is the Read Only access user (or very limited access)
PGROUSER=mailreader
PGROPASS=mailreader
# This is for administration
PGRWUSER=mailwriter
PGRWPASS=mailwriter
# VHost Mail Directory
VHOST_HOME=/var/mail/vhosts
VHOST_UID=5000
# No real reason to make them differ
# but define tis variable anyway for
# below configuration to work
VHOST_GID=$VHOST_UID
# RoundCube Configuration
MXHOST=$PGHOST
PGRQNAME=system_roundcube
PGRQUSER=roundcube_user
PGRQPASS=roundcube_pass
# This is where our templates get installed to make your life
# incredibly easy and the setup to be painless. These files are
# installed from the nuxref-templates-mxserver RPM package you
# installed above. If you do not have this RPM package then you
# must install it or this blog simply won't work for you.
Once all of this has been set you can proceed to do any of the below steps! Keep in mind that if you decide to change any of the variables above, you may need to redo every single step identified below.
Step 2 of 7: System Preparation
First off, Make sure you’ve set up your environment correctly (defined in Step 1 above) or you will have problems with the outcome of this step! General:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Create vmail user; this will be a secure user no one else has
# permissions to that we can lock and keep our mail private
# from any prying eyes of people who have or gain access to our
Now you can setup NginX to host your administration; in the below example, I set up https://postfixadmin.<your.domain>/ to go to the postfixadmin page.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
# Create dummy favicon.ico for now (silences some log entries)
# You may have to bump php-fpm to be safe (if it's not already running)
service php-fpm status 2>/dev/null&& service php-fpm restart || service php-fpm start
# make sure it starts on every reboot too:
chkconfig php-fpm --level 345 on
# Restart NginX if it's not already
service nginx status 2>/dev/null&& service nginx restart || service nginx start
chkconfig nginx --level 345 on
Once you’re complete that, you’re now ready to access the administrator interface and set up a new account. Simply visit https://postfixadmin.<your.domain>/setup.php. The templates I provided will set the system password to admin. You’ll need to always enter this value prior to creating an account below.
Once you’re done creating an account, just change the setup.php script to read-only as a security precaution. You can preform every other action you’ll ever need using the account you already created.
# You may have to bump php-fpm to be safe (if it's not already running)
service php-fpm status 2>/dev/null&& service php-fpm restart || service php-fpm start
# make sure it starts on every reboot too:
chkconfig php-fpm --level 345 on
# Restart NginX if it's not already
service nginx status 2>/dev/null&& service nginx restart || service nginx start
chkconfig nginx --level 345 on
You can simply access https://roundcube.<your.domain>/ now and access any mailboxes you configured. Just remember to tell your users that they must specify their full email address as their username.
Each mailbox you create using PostfixAdmin you’ll be able to access with your Roundcube webpage.
Step 7 of 7: Security
If you aren’t familiar with Fail2Ban; now would be an excellent time to learn about it. I wrote a blog about securing your CentOS system a while back and encourage you to read it. At the very least, read the section on Fail2Ban. The below explains how you can protect yourself from brute force.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# Monitor for multiple failed SASL Logins into postfix
You will want to additionally add the following to your iptables /etc/sysconfig/iptables:
#---------------------------------------------------------------
# Web Traffic (for PostfixAdmin and RoundCube)
#---------------------------------------------------------------
# Allow non-encrypted port so we can redirect these users to the
# encrypted version. It's just a nicer effect to support
# redirection
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
#---------------------------------------------------------------
# SMTP /Message Transfer Agent Communication
#---------------------------------------------------------------
-A INPUT -m state --state NEW -m tcp -p tcp --dport 465 -j ACCEPT
#---------------------------------------------------------------
# IMAP
#---------------------------------------------------------------
-A INPUT -m state --state NEW -m tcp -p tcp --dport 993 -j ACCEPT
#---------------------------------------------------------------
# POP3
#---------------------------------------------------------------
-A INPUT -m state --state NEW -m tcp -p tcp --dport 995 -j ACCEPT
Useful Commands When Running Your Mail Server
doveconf -a: Display Dovecot configuration
postconf -n: Display Postfix configuration
postqueue -p: Display mail queue information
Sometimes when first playing with quotas, you may or may not want to recalculate them against a user. This can be done as follows:
01
02
03
04
05
06
07
08
09
10
11
12
13
# Recalculate a specific users quota
doveadm quotarecalc -u foobar@your.domain.com
# Or you can do this and recalculate ALL user quotas
doveadm quotarecalc -A
# You will also want to run the following command if you decide
# to recalculate someone (or all) in your database:
# UPDATE domain_quota SET bytes=sq.sb, messages=sq.sm
# FROM (SELECT 'your.domain.com',
# sum(bytes) as sb, sum(messages) as sm from quota2 WHERE
# username like '%@your.domain.com') AS sq
# WHERE domain = 'your.domain.com';
Note: If you delete a mailbox for a specified domain, remember to manually remove: /var/mail/vhosts/domain/user
So… That’s it? Now I’m done?
Yes and No… My blog pretty much hands over a working mail server with little to no extra configuration needed on your part. But to properly accept mail from other people around the world, you will need:
This mail server (ideally) must be accessible to the internet via a static IP address. This means that if you’re hosting this at home, the IP address your ISP provides you may not work (Dynamic IP vs Static IP). That said; a lot of ISPs can offer you a static IP if you don’t already have one for little (to no) extra cost.
Your own domain name (if you don’t have an official one already) because you can’t have an email@your.domain.com if your.domain.com isn’t publicly recognized.
A Mail Exchange (MX) Record that points to your new mail server by via it’s accessible IP on the internet. This is the only way the outside world will be able to send mail back to you; this step is not required if the only thing you’re doing is sending email out.
Most Domain Registars allow you to set your own MX record (GoDaddy.com, NameCheap.com) which can simply be entered right from their webpage with little to no effort. If you’re paying someone else to host your websites for the domain you own, then most likely they have the MX record already pointing to them. You may need to open a support ticket (or call them) and tell them you want the MX record changed to point back to your own server instead or forward it.
Please keep in mind that there are risks involved with running your own mail server. You can get yourself temporarily (or permantenly) blacklisted if you’re not careful. Once you’re blacklisted, you’ll have a very hard time getting other mail servers on the internet to accept your emails for delivery. Blacklisting occurs when mail servers (which you will now be interacting with) detect abuse. In most cases, the mail server administrator (this is YOU) won’t even know you’re abusing other peoples servers. The abuse will start under your nose from emails that originated from your system by those you given mailboxes too. In fact, once your domain is blacklisted; it can be a pain in the @$$ to get de-listed later. A Blacklisted domain’s emails usually never reaches their intended recipient. Instead, they are immediately flagged as spam and sent to the deleted items (by the remote server). The configuration I provided considers most of the cases, but you still need to consider:
Don’t create mailboxes for people that you know intend to use it for derogatory purposes or for the intentions of spamming others. Hence; don’t allow users to send out hundreds of thousands of emails a day to a massive distribution on a regular bases even if it’s meaningful mail. Consider that the same stuff that you don’t like in your inbox is the same stuff that nobody else likes in theirs either.
Don’t allow your mail server to relay mail from untrusted sources. Hence; make sure you only allow users you create accounts for to send mail from your server.
Throttle all outbound mail delivery to each of their relay locations. With respect to the first point, even if you have to send massive amounts of mail from your system on a regular basis, do it in small batches. This way you won’t overwhelm the remote servers accepting your mail you want delivered.
If you followed my blog and are using the settings I put in place, then you’re already configured for the last 2 options above. The first option is governed by your own decisions.
No system is bulletproof; disaster can always strike when you’re least expecting it. To cover yourself, always consider backups of the following:
Your PostgreSQL Database: This is where all of your mail configuration is for both your MTA and MDA. You definitely do not want to lose this. May I suggest you reference my other blog entry here where I wrote a really simple backup/restore tool for a PostgreSQL database.
/etc/postfixadmin/*: Your Postfix Admin flat file configuration allowing you to centrally manage everything via a webpage.
/etc/postfix/*: Your Postfix flat file configuration which defines the core of your MTA. It’s configuration allows you to centrally manage everything else through the Postfix Administration website.
/etc/roundcube/*: Your Roundcube flat file configuration which allowing users to check their mail via a webpage you host.
/etc/dovecot/*: Your Dovecot flat file configuration which defines the core of your MDA. It’s configuration allows you to centrally manage everything through the Postfix Administration website.
/var/mail/vhosts/*: All of your user’s mailboxes are defined here. This is a vast storage of unread and read mail that resides on your server.
Oct 20th, 2014 Security Update: Handles The Poodle SSLv3 Exploit
Last week a security exploit was found specifically targeting web hosting making use of the SSLv3 (see here for details) protocol. Previously, the NginX templates (residing in nuxref-templates-mxserver version 1.0.1 or less) I provided did not protect you from this vulnerability. As a result; earlier readers of this blog entry may be susceptible to a man-in-the-middle attack. I just recently posted an update to the nuxref-templates-mxserver (v1.0.2) which will automatically cover any new bloggers building a mail server. For the previous readers, you just need to make 2 changes to correct yourself of this exploit:
Open up /etc/nginx/conf.d/roundcubemail.conf and /etc/nginx/conf.d/postfixadmin.conf and change this:
This information was based on a great blog entry on securing your NginX configuration found here.
Finally you will want to reload your NginX configuration so it takes on the new updates you applied:
1
2
# Reload NginX
service nginx reload
What about Apache?
Apache is a perfectly fine alternative solution as well! I simply chose NginX because it is much more lightweight approach. In fact, PostfixAdmin and RoundCube mail already come with Apache configuration out of the box located in /etc/httpd/conf.d/. Thus, if you simply start up your Apache instance (service httpd start), you will be hosting its services right away. Please keep in mind that the default (Apache) configuration does not come with all the SSL and added security I provided with the NginX templates. Perhaps later on, I will update the template rpm to include an Apache secure setup as well.
Credit
This blog took me a very (,very) long time to put together and test! The repository hosting alone now accommodates all my blog entries up to this date. If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. It’s really all I ask.
Repository
This blog required me to set up my own repository of which I was thinking that some people might want me to continue to maintain. Such as fetching and applying the latest security updates after testing them first for the continued promise of stability. Personally, I believe I may be setting up a new can of worms for myself by offering this service because bandwidth costs money and updates cost time. But I’ll share it publicly and see how things go anyway.
If you’d like me to continue to monitor and apply updates as well as hosting the repository for long terms, please consider donating or offering a mirror server to help me out! This would would be greatly appreciated!
Sources
This blog could not have been made possible without the tons of resources that I used. Some of these resources including other peoples blogs too which I picked and chose approaches they took.
As a Developer or even a System Administrator, experiencing database corruption is a scary thing. Usually when something you’re responsible fails… it fails hard. It’s important to always make frequent backups of your database(s) your in charge of. The internet is filled with solutions and one liners you can consider. But there is a lot of contradiction everywhere too as each site tells you how it should be done. Personally, I’m not going to tell you the way I do it is the correct way or not. But I will tell you it works, and it’s saved me in numerous occasions.
I’m lazy, and when I look for solutions online, I always hope someone is just going to spell it right out for me. It’s so much easier when someone else does all the work; but usually that’s wasn’t the case for me. Stack Overflow is fantastic for getting the quick 1 liners you need to build your solution, but I prefer automation. I don’t want to remember all of the different options one tool has from another. I want simplicity because when something fails, I don’t want to learn the complicated steps to do a database restoration.
As a strong supporter of PostgreSQL, I want to provide the solution I use to hopefully speed along someone else’s research in the future. I can’t stress enough also that if you aren’t taking regular backups of databases you are responsible for, then you really should reconsider and at use the scripts defined below.
The rest of this blog contains a simplified version of the content found in the attached RPMs but should still suit the needs of most!
Database Backup
Assuming you you are the global system administrator responsible for a PostgreSQL database and have root privileges, here is a simple backup script you can use:
001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
057
058
059
060
061
062
063
064
065
066
067
068
069
070
071
072
073
074
075
076
077
078
079
080
081
082
083
084
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
#!/bin/bash
# Author: Chris Caron <lead2gold at gmail.com>
# Name: pgnux_backup
# Description: Preform a backup of one ore more PostgreSQL Database(s)
# Returns: 0 on success, a non-zero value if a failure occurred
# Syntax: pgnux_backup [db1 [db2 [db3 [...]]]
#
# Note: If no database is specified to be backed up, then all of
# databases hosted by the postgresql instance are used.
##################################
# Define some simple variables
##################################
PGENGINE=/usr/bin
PGPORT=5432
PGHOST=localhost
DUMPDIR=/var/pgbackup
##################################
# System Tweaks
##################################
# if COMPRESSION is enabled, then all database backups are
# gzipped to save space. The trade off is more cpu power will
# be used to generate your backups and they will take longer
# to create. But you can save yourself significant amounts of
# disk space. Set this value to 0 if you do not wish to use
# compression. COMPRESSION can be set to a value between 0 and
# 9 where a setting of 0 is used to disable it.
# Please keep in mind also, that if you choose to use
# compression, the PostgreSQL restores will be a bit slower since
# the data needs to be first uncompressed before it can be
# reloaded.
COMPRESSION=6
# For SELinux we need to use 'runuser' not 'su'
if[ -x /sbin/runuser]; then
SU=/sbin/runuser
else
SU=/bin/su
fi
# Safety Check
if[ $(whoami) != 'root']; then
echo"Error: You must be 'root' to use this script."
exit1
fi
# List of databases you wish to back up by default. If you
# leave this blank, then the system will automatically detect
# all of the databases hosted by the PostgreSQL instance.
#
# You can use Space, Tab or some form of white space delimiter
# between each database you specify if you need to specify more
# than one.
# If nothing is specified on the command line (when this script
# is called, then this is the default list that will be used in
# it's place.
DBLIST=""
# If anything was specified on the command line; we over-ride it here
[ ! -z "$@"] && DBLIST="$@"
# Capture the current time to make it easy to locate our backups later
Consider creating a few crontab entries to manage backups during off hours as well as some tool that can keep your backups from growing out of control on your hard drive. Feel free to adjust the numbers as you see fit. The below assumes you copied the 2 scripts above in /usr/bin
1
2
3
4
5
6
cat<< EOF > /etc/cron.d/nuxref_postgresql_backup
# Create a backup of all databases every hour
0 * * * * root /usr/bin/pgnux_backup&>/dev/null
# Only keep the last 30 days of backups (check run every hour on the 40 min mark)
If worst case scenario happens, and the restore process seems to be failing you, your not out of options. As long as you’ve been taking frequent backups, there is always a way back!
Remember that restores will fail if the database is being accessed by someone else. The below is a dirty little scripted trick that boots everyone accessing your system off. It’s somewhat dangerous to do, but if restoring is your final goal, then the danger is mitigated.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#!/bin/bash
# Author: Chris Caron <lead2gold at gmail.com>
# Name: pgnux_kickusers
# Description: Kicks all users off of a PostgreSQL instance being
# accessed.
# Syntax: pgnux_kickusers
##################################
# Define some simple variables
##################################
PGENGINE=/usr/bin
PGPORT=5432
PGHOST=localhost
# For SELinux we need to use 'runuser' not 'su'
if[ -x /sbin/runuser]; then
SU=/sbin/runuser
else
SU=/bin/su
fi
# Safety Check
if[ $(whoami) != 'root']; then
echo"Error: You must be 'root' to use this script."
exit1
fi
# Get a list of all PIDS accessing our system while kicking
# -c \"SELECT pg_stat_activity.procpid,pg_terminate_backend(pg_stat_activity.procpid) FROM pg_stat_activity WHERE procpid <> pg_backend_pid();\"" 2>/dev/null | egrep -v 't' | cut -d'|' -f1)
# Iterate over the left over pids that we couldn't otherwise
# handle and attempt to kick them by sending each of them a SIGTERM.
forPID in$PIDS; do
RETRY=3
while[ $RETRY -gt 0 ]; do
kill$PID &>/dev/null
ps-p $PID &>/dev/null
if[ $? -ne0 ]; thenbreak; fi
letRETRY-=1
done
# All PostgreSQL Documentation will tell you SIGKILL
# is the absolute 'WORST' thing you can do.
# The below code should only be uncommented in
# catastrophic situations where a restore is inevitable
# ps -p $PID &>/dev/null
# [ $? -eq 0 ] && kill -9 $PID
done
exit0
They can also fail if PostgreSQL data directory contents has been corrupted. Corruption can occur:
From a system that is experiencing harddrive failures.
From another processes accessing /var/lib/pgsql/data/* that shouldn’t be. Only the database itself should be modifying/accessing the contents of this directory unless you know what you’re doing.
From just a simple power outage. A busy system that isn’t backed up by a UPS device or redundant power sources can have it’s file system corrupted easily during a loss of power. What usually happens is PostgreSQL is writing content to the database when the power is pulled from the machine. At the end of the day, you’re left with a database that wasn’t correctly written to and in some cases can be seriously damaged from this as a result.
In some cases, the corruption can be so bad the database instance (PostgreSQL) won’t even start. Evidently, you can’t restore a working copy of a database if the service itself isn’t working for you.
Sometimes attempting to repair the write-ahead logging can help you recover. Obviously this completely depends on the type of failure you’re experiencing. /var/lib/pgsql/data/pg_xlog/* can help shed some light on this subject as well. The below script assumes your instance of PostgreSQL is stopped.
1
2
3
# Make sure your database is NOT running if you intend to run the below
# command:
service postgresql stop
Here is the the simple wrapper to the read-ahead write log repair:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#!/bin/bash
# Author: Chris Caron <lead2gold at gmail.com>
# Name: pgnux_repair
# Description: Simple wrapper to pg_resetxlog
# Syntax: pgnux_repair
##################################
# Define some simple variables
##################################
PGENGINE=/usr/bin
PGDATA=/var/lib/pgsql/data
# For SELinux we need to use 'runuser' not 'su'
if[ -x /sbin/runuser]; then
SU=/sbin/runuser
else
SU=/bin/su
fi
# Safety Check
if[ $(whoami) != 'root']; then
echo"Error: You must be 'root' to use this script."
If it still doesn’t work, as a last resort consider these simple commands to bring your system back up again. Note that you should be the root user prior to preforming these steps:
# Just in case, for SELinux Users, make sure we're set okay
restorecon -R /var/lib/pgsql
# Start your database up
service postgresql start
# Now restore your databases using pgnux_restore and make sure you
# include the double dash '--' so that you load the system globals
# back as well:
# pgnux_restore --,db1,db2,db3,db4,...
#
# If you've always been backing them all together, then you can
# restore them with a single command:
pgnux_restore --
# Your done! You should be back and running now and hopefully with
# minimal downtime.
Disclaimer
I can not be held responsible or liable for anything that goes wrong with your system. This blog is intended to be used as a resource only and will hopefully help you out in the time of need. These tools work for me and have been tested thoroughly using PostgreSQL v8.4 (which ships with CentOS 6.x). I have not tried any of these tools for PostgreSQL v9.x or higher and can not promise you anything, but I honestly can’t see a reason why they wouldn’t work.
Credit
Please note that this information took me several days to put together and test thoroughly. I may not blog often; but I want to re-assure the stability and testing I put into everything I intend share.
If you like what you see and wish to copy and paste this HOWTO, please reference back to this blog post at the very least. It’s really all I ask.