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.
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.
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.
Today’s post is a quick tip that will help you keep your robots.txt after you update the site’s Drupal core with drush.
Most likely, you know the problem, too: each time you update the Drupal core (with drush, first of all), you lose all changes you may have introduced to robots.txt manually. A good idea is to always have a backup of this file handy, but every now and then you only have an outdated version of robots.txt and you learn that only when you check the updated site with webmaster tools.
Security of a website is a crucial thing that sometimes does not receive the attention it should.
Today, I’d like to share the routines we apply when checking up security of a Drupal-powered website. For the most part, this article is a summary of the report Dmitry Kochetov, our Drupal security specialist, made at DrupalCamp Krasnodar 2016.