For a long time I’ve maintained a memory aid in the form of a list of useful commands which can be used on the command line for Linux, macOS (OS X), BSD, Solaris, etc., so I thought I’d list them in a blog post in case they come in useful for others. Most of these will run on any Unix-type operating system, though I’ve usually indicated where a command is OS-specific.
My article Security hardening on CentOS 7, Red Hat Enterprise Linux 7 & Amazon Linux was seen by Red Hat guru Karoly Vegh, who helpfully suggested it would be a good idea to automate the process with Ansible.
So here in my GitHub repository are some Ansible playbooks and related support files that I’ve created, which can be used for hardening servers running CentOS 7 and related Linux distributions such as Red Hat Enterprise Linux 7 and Amazon Linux. With some tweaking these playbooks could be easily modified for use with Ubuntu, Debian and other types of distro.
To use these playbooks, check out the repo and you can run them with
ansible-playbook in the usual way. They assume the target servers are defined in your Ansible inventory as centosservers, but of course you can modify that if needed.
If you’ve been running a web application on just one or two servers which contain your web server, application framework and database, there will likely come a time when you need to scale to cope with higher load from more incoming traffic. Whilst the web/application side of things can usually be scaled horizontally across multiple servers without too much trouble, a MySQL database is not so straightforward.
You may be using one or two EC2 instances, or your infrastructure may be hosted somewhere other than AWS. We’ll assume here that you’re migrating the whole app to AWS (if it’s not there already) and that you need to put the database somewhere within AWS as part of the scaling-up process. There are basically two options: install MySQL on one or more EC2 instances and administer it yourself; or use Amazon’s RDS (Relational Database Service) as a simpler way of hosting and managing your database.Continue reading “Migrating a MySQL database to AWS (with specific focus on RDS)”
When you want to run your web application on more than one EC2 instance for scaling and redundancy purposes, you will probably require some form of load balancer to distribute incoming requests evenly across the instances. There are various possible solutions for this.
One option is to launch another EC2 instance and install a load balancer on it yourself. There are quite a few open source load balancing options, though I would tend to recommend HAProxy as it’s fast, efficient, secure, and very flexible. This option involves setting up your Linux instance and installing the software you need yourself, then configuring your chosen load balancer and installing your SSL certificates, etc. Additionally you would need to estimate the necessary instance size to run the load balancing software without getting overloaded and slowing the site down (bearing in mind that SSL termination can be particularly CPU-intensive), then monitoring it accordingly.
Unless there’s a particular reason to take the approach of installing a load balancer on an EC2 instance, a simpler and more effective option – especially for companies taking their first steps into scaling multiple instances for their application – is likely to be Amazon’s own ELB (Elastic Load Balancer). This doesn’t require an EC2 instance with Linux setup, software installation and configuration, etc. It provides a simple interface with easy SSL termination and it will scale itself automatically as needed, so there is little required in the way of planning and monitoring.Continue reading “Choosing and setting up a load balancer in AWS”
This article describes the process of creating a Slack notification from a CloudWatch alarm generated from an undesirable state in an SQS (Simple Queue Service) queue, via SNS (Simple Notification Service) and Lambda.
You can of course modify any of these to suit your differing requirements. For example, the source could be a different SQS state, or the source could be some other AWS service rather than SQS, or you may want to send the notification to somewhere other than Slack (in which case a different Lambda function may be required), etc.Continue reading “Creating a Slack notification from a CloudWatch alarm for an SQS queue, via SNS and Lambda”
It was necessary to build an updated mail system for a client which would handle all incoming and outgoing email, and which could handle successfully sending out an average of one million emails per day. This was based on Postfix, since Postfix is known for reliability, robustness, security, and relative ease of administration. Building a Postfix mail system capable of handling so many emails is quite a significant aim at a time when establishing a positive reputation for independent mail servers delivering high volumes of email is quite a challenging goal.Continue reading “Building a Postfix-based mail system for incoming and outgoing email, capable of successfully sending one million emails per day”
A few years ago I wrote a quite popular post for security hardening on Ubuntu 14.04, and now here’s a new version for CentOS 7 and RHEL 7. Much of it should apply to CentOS/RHEL versions 6 and 8, with some tweaks required here and there. It should also largely work with Amazon Linux and Amazon Linux 2, although again some tweaks will be required for those.
I wanted to get notified of any new machines connecting to my local network so that I could be reasonably sure there would be no unauthorised devices connecting wirelessly to use my network for unknown and potentially malicious purposes. I therefore wrote a simple script to detect new MAC addresses appearing on the network and notify me accordingly. The script requires nmap to be installed and should ideally be run from cron with the output going to a valid email account. The script can be obtained from my GitHub.
Fairly recently I made some notes for a setup of Elastic Stack on a network of CentOS 6 machines. I found it relatively involved so thought it was worth sharing.
My original post for monitoring HP storage hardware in CentOS is now out of date, so I decided to write an updated post for monitoring all hardware, not just storage hardware, and for optionally including this hardware monitoring in Nagios.
This is written primarily for CentOS 6. It should be largely fine for CentOS 5 and CentOS 7 too, although one or two modifications may be needed. It should also work with some other HP ProLiant servers such as the DL380.