Here is a brief account of how we applied the most critical Drupal security update in the past couple of years to web projects we support and monitor.
Hey all! Today, we shall show you some examples of master-slave replication setups.
A bit of theory first
Why do you need replication in the first place? There are at least two reasons to set it up. First off, it is your insurance that helps avoid downtime when/if your master MySQL server goes down: with replication, slave server picks up and fills for the master. Secondly, replication allows decreasing load suffered by the master server: you use it for writing only and pass read queries to slave.
In the previous article, we covered How to stay out of SPAM folder? and today we will learn how to secure our Drupal web server.
Setting up Firewall
So, we have Debian OS powering our Drupal web server, and we need to make it secure, adjust everything so as to minimize all risks. First of, we want to configure the firewall. Basic stuff. Our "weapon of choice" here is IPTables.
In the previous article, we covered teaching your Drupal installation to send mail to users. But that is only half the battle, now we need to make sure the mail we send hits Inbox and not Spam folder. This article describes some options you have that offer relevant solutions. Unfortunately, no one can guarantee 100% inbox hits, but keeping the amount of mail filtered to Spam to a minimum is quite possible.
Once you have the web server set up and running, you need to make sure your Drupal site can send emails, like registration confirmation, password change etc.
For inbound email, you may want to use email services like that offered by Google Apps. They offer good spam protection and secure storage.
To send email from a Drupal-powered site, you can use an SMTP module and do it all through a third party mail service. Alternatively, you can set up your own SMTP server. This article describes setting up an Exim server that allows sending emails.
This installment of the Drupal-friendly server series covers the process of setting up MySQL to work flawlessly with Drupal. Previous article of the series described the nuances of tuning nginx web server, now is the time to deal with the database. The OS of choice for us is Debian.
Installing MySQL 5.5 or 5.6
First off, we need to update the package list:
In the previous article Setting up Nginx on a Debian server as front-end for Apache of the series of articles for Drupal sysadmins we explained Nginx configs that allow it working through static queries while Apache serves dynamic content. This article offers a look at an alternative setup, where Php-fpm takes the place of Apache. The operating principle for our web server will be as follows:
Hi, fellow Drupalers. Today, I’d like to share with you a project of ours that allows automating web server setup for Drupal-powered websites.
At Drupal Admin team, we often set up and fine tune servers for Drupal websites, so it was only natural for us to develop a routine that automates the related processes. We picked Ansible configurations management system for initial setups and further servers maintenance.
Why Ansible? This systems allows:
Welcome to the next installment of the series of articles for Drupal sysadmins. Today, you are going to learn the process and nuances of setting up Nginx so it works as Apache’s front-end on a Debian server.
In the previous article, we covered setup of a web server on a Debian machine and Drupal installation. The solution offered there has a couple of drawbacks:
Today i published the first article from the curriculum of Drupal Admin sysadmin training organized by our team.
What does it take to set up a web server from scratch and install Drupal to that server?
Let’s find it out.
The web server we will be using runs under Linux Debian / Ubuntu and has the standard set of Apache, MySql, Php on board, all with default configs. We will also consider basic set up of Drupal and some nuances about that environment.