DEV Community: Perttu Ehn

DynDNS with OVH hosting

Perttu Ehn — Sat, 29 Jan 2022 15:07:39 +0000

I use my own domain to access some specific services when I am not home or just feel lazy because I can do things over my mobile like this. Typing and remembering IP addresses isn't too much fun so I use my own domain to simplify my life.

I have opened some services to be accessed only from my home wifi network. Some services I have opened also are accessible from outside my home.

I did not want to pay for a fixed IP address and hence the internet service provider (ISP) may change my IP whenever they like. This would usually make reaching those services unreliable.

Since I have a few other things hosted at OVH Hosting and they offer DynDNS as well I went and set up a couple of subdomains with it. DynDNS is a dynamic domain name system service which allows some specified domain to be updated automatically. The update is initiated by some device behind the changing IP address (ie. your home).

Earlier I have had NASs' (tiny linux servers) which I used to update my home domains. All of my NASes have been turned off for a while now. Also I prefer handling the incoming traffic based on domain name rather than port so I can use nginx in my word facing Raspberry PI's to proxy the traffic where needed.

Proxying means I forward my incoming traffic coming to my hypothetical fridge domain with nginx to the fridge but the access to the fridge would happen via address https://fridge.example.com and the outer most Raspberry PI would pass the request coming with that domain to the fridge. This way it is easy to handle incoming requests with one nginx in cheap Raspberry PI.

Updating DynDNS IP address

I wrote this small script I run for each of my home domains in the Raspberry PI. What the script does is it checks the currently configured IP address for the given domain, compares it with the public IP address it has and updates the OVH Hosting DNS with the new IP address if necessary.

Because the IP address comparison script can be run every few minutes with no worries querying the OVH side too often. Basically it sends update requests to OVH only when the IP address has been changed.

Setup

Let's put the script under path /path/to/ and the domain we configure is home.example.com. Let's assume also that our username is janedoe and the matching password is mysecret

The credentials file format is very strict since we pass it forward with the request to update domain - exactly one line and username and password separated with a single colon.

Save the files
```
$ cd /path/to
```

You need to have credentials for your request (so only you can update your domains):

echo "home.example.com-janedoe:mysecret" > dyndns-update.sh_home.example.com.creds.txt

Make the script executable and owned by root and credentials files readable only by root:

$ sudo chmod 700 dyndns-update.sh # the main script
$ sudo chown root:root dyndns-update.sh
$ sudo chmod 400 dyndns-update.sh_home.example.com.creds.txt
$ sudo chown root:root dyndns-update.sh_home.example.com.creds.txt

Execute the script manually to see it works:
```
$ sudo sh dyndns-update.sh home.example.com
```
If the execution fails uncomment the DEBUG=1 line to get more output.
When the script works, set up cronjob to run the script every few minutes.

The longer time between the executions you have the longer time it takes for the domain IP address to get corrected.

Edit your cronjob table with sudo crontab -e (or however the similar scheduled jobs configuration is done in your system).
```
*/10 * * * * sh /path/to/dyndns-update.sh home.example.com
```

Script

This script works with OVH Hosting. You may need to adjust the curl command if your DynDNS host has a different API to update the domain IP addresses. Check with your hosting provider for the details.

#!/usr/bin/env bash
# /path/to/dyndns-update.sh

# 1. Create a credentials file in the same folder with this script named 
# dyndns-update.sh_EXAMPLE.COM.creds.txt 
# with user credentials, such as 
# example.com-username:USER-PASSWORD
# 
# 2. Try this at least once. The output of curl commands tells if update is successful, not necessary or if something was wrong.
# sudo sh /path/to/dyndns-update.sh
#
# 3. Run this as a cronjob
# $ sudo crontab -e
# and add something like this to your crontab (this checks IP every 10 mins):
# */10 * * * * sh /path/to/dyndns-update.sh EXAMPLE.COM

# Disable to get less output:
DEBUG=1

USER_ID=$(id -u)
if [ "$USER_ID" -ne "0" ]; then
  echo This script must be run as a root.
  exit 0
fi

DOMAIN=$1
if [ -z "$DOMAIN" ]; then
  echo "Usage: "
  echo "${0} example.com"
  exit 1
fi

SCRIPT=`realpath $0`
SCRIPT_FOLDER=$(dirname $SCRIPT)
SCRIPT_NAME=$(basename $SCRIPT)

DOMAIN_IP=$(host $DOMAIN |awk '{print $4}' | xargs)
PUBLIC_IP=$(curl --silent https://ipinfo.io/ip | xargs)

if [ "$DOMAIN_IP" != "$PUBLIC_IP" ]; then
  echo -n "Domain ${DOMAIN} public IP is ${DOMAIN_IP}. "
  echo "Your local IP is ${PUBLIC_IP}, so DynHost needs updating. "
  FILE="${SCRIPT_FOLDER}/${SCRIPT_NAME}_${DOMAIN}.creds.txt "
  # Reads the 1st line of a file $FILE  into a PASS varible.
  read -r PASS < $FILE
  if [ -z "$PASS" ]; then
    echo "No password (tried $FILE), exiting!"
    exit 1;
  fi
  [ ! -z "$DEBUG" ] && [ "$DEBUG" -ne "0" ] && echo "Next (with creds):" "https://www.ovh.com/nic/update?system=dyndns&hostname=${DOMAIN}&myip=${PUBLIC_IP}"
  curl --silent --user "${PASS}"                       "https://www.ovh.com/nic/update?system=dyndns&hostname=${DOMAIN}&myip=${PUBLIC_IP}"
elif [ ! -z "$DEBUG" ] && [ "$DEBUG" -ne "0" ]; then
  echo  "Domain ${DOMAIN} public IP is ${DOMAIN_IP}."
  echo "Your local IP is ${PUBLIC_IP}."
  echo "Domain ${DOMAIN} IP still ok."
fi

Source: https://gist.github.com/rpsu/7570c47ad3b5335087a0dee5170aac51

Security in Code Deployment - part 5: Patching with Composer and Deploy

Perttu Ehn — Wed, 19 Jan 2022 14:12:27 +0000

Part 5/5. The article was initially published in Drupal Watchdog 7.01, spring 2017.

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

Security in Code Deployment:

Part 1: Drush make file
Part 2: Patch modules with Drush
Part 3: Unknown Drupal codebase
Part 4: Advantages of using Composer JSON
Part 5: Patching with Composer and Deploy

Composer is able to apply patches if you are using drupal-composer/drupal-project or some other patching plugin for Composer (Listing 14).

LISTING 14: Composer Patching

"extra": {
  "patches": {
    "drupal/field_group": {
      "A patch with URL": "https://www.drupal.org/files/issues/ field_group-empty_group_nonnumeric_index-2761159-2-D8.patch", 
      "A local patch file, path relative to the composer.json file": "patches/field_group-fix_it.patch"
    }
  }
}

After you have added the patch files to the composer. json file, apply the changes and update the composer.lock file:

$ composer install
$ composer update --lock

Currently with Drupal 8, all contrib modules and other resources must be added manually one by one. If you are creating a composer.json file from a Drupal 7 site, you might benefit by using the Composer Generate module.

If you are interested in building your Drupal 8 projects with Composer, two good resources are Wolfgang Ziegler’s presentation from Drupal Iron Camp 2016 and the Composer documentation at Drupal.org.

Deployment Process

For codebase deployment, it is best to rely on a builder tool. Ideally, you commit only your custom code (e.g., modules and themes and a Drush make file or the composer.json and composer.lock files) to the project repository, with specific versions and, optionally, patching information. With proper versioning (think Git tags), you can test your next release’s code in development and staging environments and reduce the probability of reintroducing old or introducing new issues.

Web server configuration is very much related to deployment security, too. However, because it is too broad a topic to be covered here, just remember to make sure your server does not allow end users access to any files other than those they absolutely need. Patch files, Drupal core, and a module’s text files – especially CHANGELOG.txt and build time PATCHES.txt – are good examples of files that have no business being visible to the world. Even when most of the attacks against websites are automated, there is no reason to leave information about website internals in the open.

*Special thanks to Rami Järvinen for contributions to this blog post and to Anastasios Daskalopoulos and James Narraway for their help correcting my words to much better English.

Security in Code Deployment - part 4: Advantages of using Composer JSON

Perttu Ehn — Wed, 19 Jan 2022 14:08:33 +0000

Part 4/5. The article was initially published in Drupal Watchdog 7.01, spring 2017.

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

Security in Code Deployment:

Part 1: Drush make file
Part 2: Patch modules with Drush
Part 3: Unknown Drupal codebase
Part 4: Advantages of using Composer JSON
Part 5: Patching with Composer and Deploy

You are most probably familiar with Composer, at least on a conceptual level. It is a dependency manager with all of the functionality of Drush, and more. From the perspective of building the codebase, the difference between Drush and Composer is the recipe file format and the use or Composer, not Drush, as the build tool. Drush and Composer are not mutually exclusive, you can use both; you can even install Drush along with Drupal using Composer.

Composer uses JSON files, which use curly brackets instead of indentation, as in YAML files. However, unlike Drush make files, composer.json files are not meant to be edited in quite the same way. Composer keeps the composer.json and composer.lock files up-to-date according to your instructions. You still need to add some things manually to composer.json, such as the patches you want to use in modules.

From a code deployment perspective, using Composer is just a better way to manage all required resources, because it also makes sure all the module requirements are met; you could learn the hard way that something is missing with the use of an (incomplete) Drush make file.

Start by generating the project in a drupal.local folder. The following example uses the GitHub-based Composer template project. Before you start, make sure you have Composer installed:

$ composer create-project drupal-composer/drupal-project:8.x-dev drupal.local
--stability dev --no-interaction
$ cd drupal.local

Composer can be used with Drupal 7 projects, too. All you have to change is the branch name in the command to 7.x-dev. Now the composer.json and composer.lock files have been created. The Drupal root (the index.php file) is in the web folder, as are other Drupal modules and themes. Other resources (dependencies) are in the vendor folder. You might take a look at what is in the folders; just remember that composer.lock contains the whole dependency tree, which easily makes it quite long when compared with the composer.json file.

Start by adding Drupal.org as one of the package (module) sources; then, start adding your project dependencies. In Listing 13, I’m adding the very latest version of the Token module that is compatible with the defined Drupal core, as well as a specific version of the Field Group module and a specific commit (1fe3649) from Ctools module’s 8.x-3.x branch. Composer will update composer.json and composer.lock files when you add (or remove) dependencies.

LISTING 13: Add Modules with Composer

# Configure Drupal.org as a package source
$ composer config repositories.drupal composer https://packages.drupal.org/8
# Add some modules
$ composer require drupal/token
$ composer require drupal/field_group:1.0-rc4
$ composer require drupal/ctools:dev-3.x#1fe3649

Once you have committed and pushed changes, your colleagues can get exactly the same codebase every time, with all dependencies included. All they have to do is clone your repository and run:

$ composer install --prefer-dist --optimize-autoloader

Happy coding!

Security in Code Deployment - part 3: Unknown Drupal codebase

Perttu Ehn — Wed, 19 Jan 2022 14:07:31 +0000

Part 3/5. The article was initially published in Drupal Watchdog 7.01, spring 2017.

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

Security in Code Deployment:

Part 1: Drush make file
Part 2: Patch modules with Drush
Part 3: Unknown Drupal codebase
Part 4: Advantages of using Composer JSON
Part 5: Patching with Composer and Deploy

Some day you will receive a project that you must start maintaining - the unknown Drupal codebase. In the best case, you get an up-to-date Drush make file with properly declared resource versions, database dumps, and sites/example.com folder content.. In the worst case, you get a huge, uncompressed file containing the whole Drupal site starting from the Drupal root, including core and contrib modules and a database dump.

In the first case, codebase reviewing and building is fairly easy – all information for the codebase is written into the make file: Build the codebase, extract sites/example.com folder contents, import the database, and you’re good to go.

In the worst-case scenario, you must review the entire codebase and create the missing make file yourself. Provided you have Drush installed, generating a make file is fairly simple. Set up the site in your local development environment and enter:

$ cd DRUPAL_ROOT/sites/example.com  
$ drush make-generate path/to/example.com.make

Now you have at least a base for your make file, but the file is not ready yet. Open your example.com.make file and add the missing components. Components that require editing are clearly marked. For example, a missing component might be that the required libraries aren’t yet set because Drush has no way of knowing where they came from – Drush only queries information about the resources from Drupal.org. If you are lucky, you can find PATCHES.txt files or similar in the extracted codebase for help.

The next thing you must do is verify that the received codebase has not been tampered with. The previous maintainer might have changed the codebase in some manner. As with so many other things, you can use a Drupal module to offload this tedious and error-prone work to the machine.

The Hacked! module compares the codebase – Drupal core, modules, and themes – to the versions on Drupal. org by downloading the supposedly same files and verifying that they match the local versions. When you also use the Diff module, it is easy to see what has changed. Both of these modules have at least beta-versions available for both Drupal 7 and Drupal 8.

Security in Code Deployment - part 1: Drush make file

Perttu Ehn — Wed, 19 Jan 2022 14:07:19 +0000

Part 1/5. The article was initially published in Drupal Watchdog 7.01, spring 2017.

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

Security in Code Deployment:

Part 1: Drush make file
Part 2: Patch modules with Drush
Part 3: Unknown Drupal codebase
Part 4: Advantages of using Composer JSON
Part 5: Patching with Composer and Deploy

Considering the full life cycle of any website, REST service, or similar utility, development of secure code covers only part of the whole. A properly functioning backup process with tested recovery, along with hardened settings for the web server and database applications running the website, is key to running successful businesses on the web, be they profit or nonprofit. Add some load balancing, architecture with multiple servers, and strict firewall rules to the mix, and you’re good to go, even with bigger sites.

What is far too often ignored is the process of managing the codebase. We’ve all heard stories or seen practices in which nobody knows how exactly to rebuild the production server codebase, requiring it to be cloned from the production site.

You must be able to reproduce the codebase from any given point in time or release version, including each instance you need to have of the website, from local development up to the production site. The codebase must be predictable to the last line of code for each release of your website, and you have a few different ways to get there.

Full Codebase in Version Control

One way to control your website codebase is to store it entirely in a version control system such as Git. Although it is a pretty bulletproof way to manage the codebase, it might require quite a bit of manual work. Drupal core and contributed (contrib) modules and themes and external libraries are already stored elsewhere and are updated regularly, so each of these updates must be imported and committed manually. Additionally, any custom code changes need to be re-implemented during this process. Largely because of these issues, it is often considered unnecessary to store code that is hosted elsewhere in the project repository.

Fortunately, this problem has already been addressed: There is no need to store any publicly available code for Drupal sites in the project repository. With the help of a couple of tools, you can offload the manual processing of each update to your contributed code or libraries.

Drush Make File to the Rescue

A predictable way to build your Drupal codebase is to use Drush and its ability to take a simple text file and create a full Drupal codebase with core and contrib modules and themes and external libraries. This simple text file is called a "make file", because it usually has the file extension .make.
The make file comes in two flavors: in the older plain text (INI) format and in the newer YAML format. Whereas the old-style INI make files have fairly loose format requirements (Listing 1), YAML indenting is important and dictates how your data is interpreted (Listing 2). Both are human readable, but YAML might be easier to scan. If you are working with Drupal 8, the YAML format of Drush make files is recommended; however, INI-style files will also work.

LISTING 1: INI Make File

; Older format is in INI format  
; Line with comment starts with a semicolon  
; Attributes are declared like this:  
; attribute = value  
; Attribute values with spaces and float-like string values must be quoted: ; attribute = "long value with spaces"

; Core must be defined.
core = 8.x
; (Drush) api must be defined, always to '2'.
api = 2

; Here you see the format of an array in a .make-file. Text enclosed
; in brackets are array keys, and each set to the right of the last is
; a layer deeper in the array. Note that the root array element is
; not enclosed in brackets.
; root_element[first_key][next_key] = value

; Define the Drupal core version you need to the last digit projects[drupal][version] = "8.2.3"

; Then define contrib modules etc.
; Define OAuth version to 8.x-2.0, do not include Drupal core version
; This is the same as
; projects[views][version] = "2.0"
projects[oauth] = "2.0"

; Define the where to put the module (should be inside sites/all/modules)
projects[commerce][version] = "2.0-beta3"
projects[commerce][subdir] = "commerce"

; You may also provide default values to all projects
; Now OAuth and other modules with no subdir definition will be placed in
sites/all/modules/contrib defaults[projects][subdir] = "contrib"

LISTING 2: YAML Make File

# YAML format
# Line with comment starts with a hash
#
# Attributes are declared like this:
# attribute: value
# Attribute values with spaces and float-like string values must be quoted:
# attribute: 'long value'

# Core must be defined.
core: 8.x
# (Drush) api must be defined, always to '2'.
# Version numbers that can be interpreted as floats must be quoted.
api: '2'

# Here you see the format of an array in a .make.yml-file. Indented text
# "inside" a parent are array keys, and each set to the right of the last is
# a layer deeper in the array.
# Define the exact Drupal core version you need:
projects:
  drupal:
    # Version numbers that can't be interpreted as floats do not need quotes:
    version: 8.2.3
  # Then define contrib modules etc.
  # Note that we're still inside 'projects' -array/object, hence the indenting:
  oauth:
    version: '2.0'
  commerce:
    subdir: commerce
    version: 2.0-beta3

# You may also provide default values to all projects
# Now OAuth and other modules with no subdir definition will be placed 
# in sites/all/modules/contrib
defaults:
  projects:
    subdir: 'contrib'

Use Resource Versions

To make the codebase building process predictable to the last line of code, it is important to declare all versions, including core and contrib modules and themes and external libraries. Drupal core and module version declarations are explained in Listings 1 and 2, but you can set the contrib versions on the Git commit level, too (Listings 3 and 4).
You need to specify the source URL and some other information to download external libraries in the make file (Listing 5 and 6).

LISTING 3: INI Git Commit

; INI format, get a specific version of ctools module
; Download method defaults to git, so this is not necessary
; projects[ctools][download][type] = "git"
; Optionally provide git branch so Drush can write that to .info file
projects[ctools][download][branch] = "8.x-3.x"
; Git commit hash
projects[ctools][download][revision] = 1fe3649

LISTING 4: YAML Git Commit

# YAML format, get a specific version of ctools module
# Note continuous, we're still inside "projects" array.
  ctools:
    download:
      # Download method defaults to git, so this is not necessary
      # type: git
      # Optionally provide git branch so Drush can write that to
      # .info file
      branch: 8.x-3.X
      # Git commit hash
      revision: 1fe3649

LISTING 5: INI – Source URL

; INI format, get a specific version of ckeditor library
; ckeditor (library) will be extracted
; Drupal 8: libraries/ckeditor
; Drupal 7: sites/all/libraries/ckeditor
libraries[ckeditor][download][type] = file
libraries[ckeditor][download][request_type] = get
libraries[ckeditor][download][url] = "https://download.cksource.com/CKEditor%20for%20Drupal/edit/ckeditor_4.4.6_edit.zip"
libraries[ckeditor][directory_name] = "ckeditor"
libraries[ckeditor][type] = "library"

LISTING 6: YAML – Source URL

# YAML format, get a specific version of ckeditor module # ckeditor (library) will be extracted
# Drupal 8: libraries/ckeditor
# Drupal 7: sites/all/libraries/ckeditor
libraries: ckeditor:
  download:
    type: file
    request_type: get
    url: 'https://download.cksource.com/CKEditor%20for%20Drupal/edit/ckeditor_4.4.6_edit.zip'
  directory_name: ckeditor
  type: library

The library you want to use might not provide releases or files for download. If the code repository isn’t public or you are unable to follow the updates, there is not much to be done besides store that code to your project’s version control – or at least verify downloadable file checksums to prevent unpleasant surprises (Listing 7 and 8). (This project repository is in fact publicly available at GitHub, and you could, instead of relying on a file hash, use a specific commit.)

LISTING 7: INI – Verify Checksum

; INI format, make sure file has not changed verifying file hash
libraries[isotope][download][type] = get
libraries[isotope][download][url] = http://isotope.metafizzy.co/jquery.isotope.min.js
libraries[isotope][download][md5] = ac35f7863494170cddea8ddb144675d5
libraries[isotope][directory_name] = jquery.isotope
libraries[isotope][type] = library

LISTING 8: YAML – Verify Checksum

# Yaml format, make sure file has not changed verifying file hash
libraries:
  isotope:
    download:
      type: get
      url: 'http://isotope.metafizzy.co/jquery.isotope.min.js'
      md5: ac35f7863494170cddea8ddb144675d5
    directory_name: jquery.isotope
    type: library

Failing to provide versions or at least to verify the retrieved file checksums, you can’t be sure you have the same codebase when compared with other builds. It is time dependent in the sense that it can’t be predicted when a module will have an update available and will replace some previously downloaded older version of itself. In practice, this might mean one of your colleagues is facing an issue, bug, or even vulnerability that has already been fixed in your codebase – simply because you happened to build your local this week, and your colleague did the same the previous week (Listing 9 and 10).

LISTING 9: INI – Get Specific Version

; INI format
; Get the latest release within 8.x-1 -version:
; projects[role_expose] = 1
; Get the latest development version:
; projects[role_expose] = 1.x
; Get the specified version even when it is not the latest release:
projects[role_expose] = 1.0

LISTING 10: YAML – Get Specific Version

# Yaml format
# Note the indentation, we're still inside "projects" array.
role_expose:
  # Get the latest release within 8.x-1 -version:
  # version: 1
  # Get the latest development version:
  # version: 1.x
  # Get the specified version even when it is not the latest
  # release
  version: '1.0'

In short: Always use fixed versions and specific commits, or at least verify checksums if none are available.

Security in Code Deployment - part 2: Patch modules with Drush

Perttu Ehn — Wed, 19 Jan 2022 14:03:09 +0000

Part 2/5. The article was initially published in Drupal Watchdog 7.01, spring 2017.

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

Security in Code Deployment:

Part 1: Drush make file
Part 2: Patch modules with Drush
Part 3: Unknown Drupal codebase
Part 4: Advantages of using Composer JSON
Part 5: Patching with Composer and Deploy

Occasionally (or more often) your project could have needs that require you to modify the available module code. Maybe the module has a bug or lacks a required feature, which has in fact already been addressed in the module issue queue on Drupal.org (see “Checking the Issue Queue” box) – after all, Drupal has a large and active community. All you need to do is find out if a working patch is available that fits your needs or fixes the bug in question.

CHECKING THE ISSUE QUEUE
Go to the specific module’s page on Drupal.org, find the Issues for section in the sidebar, and search. If a proposed solution to your problem exists, patches can be found after the Issue de- scription. Be sure to read the whole discussion to see if it actually solves your problem.

A patch file is a recipe describing what changes should be made and to which files. Explaining and creating patch files is outside the scope of this article, but you should be able to find help on Drupal.org.

You could fix the issue manually or apply the patch and leave it fixed on the server, but this solution is against best practices, because the very next codebase update will override the changes you’ve made and reintroduce the issue.

You could also try to remember to apply the patch or changes each time you do updates, but that’s quite an error-prone process. You can and should offload this work to Drush. If you need a custom patch for your module, you have two options: (1) let Drush patch your module using a public patch file or (2) use a local patch file.

Drush is fully capable of patching your code as instructed in the make file. All it needs is the path to the patch file. The path can be a full URL or a path to a local file relative to the make file itself (e.g., Listings 11 and 12). When you build a codebase with patches in the make file, Drush will create a PATCHES.txt file for each patched module, which can be found next to the project .info file and Drupal core installation root.

LISTING 11: INI – Patching a Module

;  INI format, patching the module, both public and local patch files
projects[field_group][version] = "1.0-rc4"
; Explain briefly why this patch is needed.
; Get the file path from the drupal.org issue in question and
; use issue number as patch array key.
projects[field_group][patch][2761159] = https://www.drupal.org/files/issues/field_group-empty_group_nonnumeric_index-2761159-2-D8.patch
; Use file in patches-folder (relative to .make-file location)
projects[field_group][patch][other_fix] = patches/field_group-fix_it.patch

LISTING 12: YAML – Patching a Module

# Yaml format, patching the module, both public and local patch files # Note the indentation, we're still inside "projects" array.
field_group:
# Get the latest release within 8.x-1 -version:
# version: 1
# Get the latest development version:
# version: 1.x
# Get the specified version even when it is not the latest release
version: '1.0-rc4'
patch:
  # Explain briefly why this patch is needed.
  # Get the file path from the drupal.org issue in question and
  # use issue number as patch array key.
  2761159: 'https://www.drupal.org/files/issues/field_group-empty_group_nonnumeric_index-2761159-2-D8.patch'

  # Use file in patches-folder (relative to .make-file location)
  other_fix: 'patches/field_group-fix_it.patch'

In short, out of all possible solutions, do not simply fix the code on your server. Extract the changes regardless of how you’ve made them, patch your code with a Drush make file, and preferably use a public patch file from the Drupal. org issue queue.

Create new base box for Vagrant development

Perttu Ehn — Wed, 19 Jan 2022 08:00:22 +0000

This blog post has been initially released in Exove's Tech blog, but can only be found on the Archive Org's magnificient webarchive since the blog has disappeared after the publication day.

As turned out, the "first post" ended up being the only one, not a serie of blog posts.

This is a first post of series "Get your local [Drupal] development environment in decent shape". Although this is targeted to Drupal developers, first three parts are fully CMS agnostic. So you could use this as a basis to get any other - say Wordpress, Ez or any other PHP based CMS developing platform up and running.

Distro of our choise is Scientific Linux 7

We at http://www.exove.com are using http://scientificlinux.org/ [SL7] as development environment distribution. It is a close relative to Red Hat Entrerprice Linux (and therefore also Centos et.al.) and there are no significant differences to Red Hat used so often as production site platform. It is fairly lightweight and as easy to configure as any Red Hat derivative.

Here you can find a list of Scientific Linux source mirrors. Pick the closest one to you instad of blindly copy-pasting all URL in this blog post. It is really not that difficult.

http://scientificlinux.org/downloads/sl-mirrors/

For this blog post's purpose the closest mirror is the one in Finland, so URL's are something like this: http://www.nic.funet.fi/pub/mirrors/scientificlinux.org/scientific/7/x86_64/iso/

Tools you should have installed

These instructions assume you are using

OS X (10.9 or newer should be fine)
VirtualBox 5.0.0 or newer
Vagrant

Note that OS X El Capitano works best with VirtualBox 5 and Vagrant 1.7.3 or newer.

Download a Scientific Linux installation media

Start by downloading SL7 installation media. Netinst-image is the smallest and all we need here. Other images have a lot of stuff we have no need for.

http://www.nic.funet.fi/pub/mirrors/scientificlinux.org/scientific/7/x86_64/iso/SL-7.1-x86_64-netinst.iso

NOTE Check SHA1, SHA256 before using any such image.

Set up VirtualBox

Launch VirtualBox and start by creating new virtual machine instance with name 'SL7-server'. Do not power it up, but configure it's settings first (CMD + S sould bring up the configure options).

Turn off some unnecessary hardware options and configure network and "insert" the installation media:

General / Advanced / Shared clipboard

Set to none

General / Advanced / Drag'n'drop

Set to none

System / Motherboard / Pointing device:

Use PS/2 (instead of available USB -options)

Audio

Set disabled

Network - Adapter 1

Use NAT

Network - Adapter 1 / Advanced / Port Forwarding

Set forwarding SSH 2222 -> 22

Network - Adapter 2,3,4

Set disabled

Ports / USB

Enable USB Controller -> unchecked

SerialPort

Enable Serial port -> unchecked

Storage

Add installation media to DVD slot

Install SL7 server in virtual machine

Power up the machine and start regular installation using UI provided by VirtualBox. These setting may vary depending your needs. For example most people might not set timezone and keyboard like this.

Set used keyboards (feel free to skip this part)

Finnish Macintosh
English US

Set timezone (feel free to skip this part)

Europe/Helsinki

Enable networking (disabled by default)
Set installation source to the closest mirror to you

http://www.nic.funet.fi/pub/mirrors/scientificlinux.org/scientific/7/x86_64/os/
Wait for a while to fetch repository data from the mirror.

Choose installation type

We'll install now a minimal server with only limited amount of packages to
keep the box small.

Install

Start installation, and...

During the OS installation process (which will take a few minutes)

Set root passwd to vagrant
Add new user vagrant with password vagrant

REBOOT

The installation media will be "ejected" automatically.

Install/remove packages

Now you can install the tools you wish to have already in place in the base box. We'll add only two smallish packages, rest of the packages will be taken care of our Ansible roles when setting up the actual vagrant box instance.

Remove unnecssary packages

Stop and remove Postfix [optional]

systemctl stop postfix yum remove postfix

Install other packages

Install packages nano and wget (not required by any means, just my personally preferred tools over other options) [optional]
```
yum install nano bash-completion wget
```
Ensure networking in on at boot

grep -Hn '^ONBOOT' /etc/sysconfig/network-scripts/*

This should result to 2 files witn ONBOOT="yes" -values. If you see line /etc/sysconfig/network-scripts/ifcfg-enp0s3:ONBOOT="no", edit the file:

nano /etc/sysconfig/network-scripts/ifofg-enp0s3`

..and check again that the value is now changed.

grep -Hn '^ONBOOT' /etc/sysconfig/network-scripts/*

Pass Grub 2 bootloader faster [optional]

Set timeout 1 second, as default seems to be 5 seconds. This is changed only to make booting 4 seconds faster.

sed -i 's/GRUB_TIMEOUT=[\d]{1,2}/GRUB_TIMEOUT=1/' /etc/default/grub`

Compile Grub config using grub2-mkconfigtool:

grub2-mkconfig -o /boot/grub2/grub.cfg

Turn SELinux off [optional but recommended]

As this box is a base for a local development vagrant box, there is no need to have SELinux enabled. It will most probably just make your life more difficult.

Make sure to reboot after this; init 6 will do it for you, though.

sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config init 6`

Add sudo-permission to vagrant user

echo 'vagrant ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/vagrant

Update sshd-configuration where needed

nano /etc/ssh/sshd_config

Port 22 (or have Port -setting disabled by adding a # in front of the line)

PubKeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no`

Restart ssh daemon:

service sshd restart`

Install vagrant insecure key

  mkdir -p /home/vagrant/.ssh
  wget --no-check-certificate https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub -O /home/vagrant/.ssh/authorized_keys

Ensure we have the correct permissions set

chmod 0700 /home/vagrant/.ssh
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown -R vagrant:vagrant /home/vagrant/.ssh`

Test ssh'ing as vagrant-user from you current root session (create keys, test access, delete keys and known_hosts etc. after testing):

ssh -v vagrant@localhost

After succesful login exit and remove (all) keys from root's known_hosts -file:

echo > /root/.ssh/known_hosts

Disbable tty -requirement for sudoers

visudo

Comment out requiretty -setting changing this line

Defaults requiretty

#Defaults requiretty

NOTE You may use simpler text editor nano instad of vim if you change your EDITOR value with:

EDITOR=$(which nano)
export EDITOR`

This change is temporary and is valid only within current shell session.

Install DKMS -package required by VirtualBox Guest additions

..as described in http://www.linuxquestions.org/questions/linux-software-2/installing-dkms-on-rhel-7-0-a-4175510666/#post5239266

Closest download mirrors can be found in from http://rpmfind.net//linux/RPM/epel/7/x86_64/d/dkms-2.2.0.3-30.git.7c3e7c5.el7.noarch.html.

Downlaod DKMS pacakge:

wget ftp://rpmfind.net/linux/epel/7/x86_64/d/dkms-2.2.0.3-30.git.7c3e7c5.el7.noarch.rpm

Install DKMS requirements (these will install also 30+ other packages):

yum install gcc kernel-devel kernel-headers

Install the local DKMS package you've just downloaded:

yum localinstall dkms-2.2.0.3-30.git.7c3e7c5.el7.noarch.rpm --nogpgcheck

Install Development Tools (this will install also 60+ other packages):

yum groupinstall 'Development Tools'

Add/update kernel for VBoxGuestAdditions. This should install kernel version 3.10.0-229 or newer:

yum update kernel

Install VirtualBox guest additions:

.. as described in http://download.virtualbox.org/virtualbox/5.0.0/.

  wget http://download.virtualbox.org/virtualbox/5.0.0/VBoxGuestAdditions_5.0.0.iso
  sudo mkdir /media/VBoxGuestAdditions
  sudo mount -o loop,ro VBoxGuestAdditions_4.3.8.iso /media/VBoxGuestAdditions
  /media/VBoxGuestAdditions/VBoxLinuxAdditions.run

Correct missing locale -settings [optional]

Add locale -settings to avoid repeating error message when logging through ssh to your box (as in every single time you use vagrant ssh -command). Edit this file:

nano /etc/environments

Add these lines:

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

Save and exit.

Give box a hostname [optional]

Use nmcli tool to to set a more desctiptive hostname (default is localhost.localdomain)

nmcli general hostname sl7-dev.local

Check that changes was made with

nmcli general hostname`

REBOOT NOW:

init 6

Finalize and cleanup

Ensure all packages are up to date, once more.

yum update

Clean up yum cache

yum clean all

Minimize the size of VirtualBox virtual machine file

Run this command to 1st fill up the virtual drive with an empty file and then removing the empty file. It will help VirtualBox to minimize the virtual drive.

dd if=/dev/zero of=/EMPTY bs=1M
rm -f /EMPTY

Clean up bash history [optional]

Empty bash history and exit. Note that last session history is saved when exiting to the history file, so you might need to do this twice (and log out in between) to get empty history file:

echo > .bash_history

exit`

Package the virtual machine for vagrant -use

Package newly baked Scientific Linux ready for Vagrant and do a test run.

Assuming VBox server name SL7-server, change accoringly

vagrant box remove test-sl7 2&>/dev/null rm package.box 2&>/dev/null vagrant package --base SL7-server vagrant box add test-sl7 package.box mkdir test cd test vagrant init test-sl7 vagrant up vagrant ssh

Credit

Putting the credit wher it belongs! Main sources used to get this stuff in order are (but here just as a list without any spesific order of imortance):

Found a typo? Spotted grammar mistakes or confusing phrases?

If you've found a typo, a sentence that could be improved or anything else that should be updated on this blog post, you can access it through a git repository and make a pull request. Instead of posting a comment, please go directly to my Dev.to Github repository and open a new pull request with your changes.