Site auditing modules in Drupal need to be installed in the codebase and require certain modules to be present on the server for gathering the required metrics. Moreover, traditional site auditing tools cannot be customized. In this blog post, we will be exploring Drutiny, an open-source Symfony Console based application used to audit Drupal 7 or Drupal 8 sites.
What is Drunity?
Drutiny stands for Drupal and Scrutiny. It offers an automation layer for auditing and reporting the Drupal 7 and 8 sites with a library of predefined policies. All checks are run from the outside looking in and require no special code or modules to be enabled on the remote site. This means you can audit all environments from development to production and not have any lasting performance degradation.
Why Drutiny?
- With traditional Drupal modules like Checklist API and the Security Review module, we need to deploy the code to the server or enable the module on the site and if you fail to enable the module, then no auditing will take place.
- Other extensions like (site_audit Drush extension) are limited to running only Drush based checks and you cannot customise the checks.
Benefits of Drutiny
Drutiny does all the checks from the outside, which means that we don’t need to run the code or enable the module on the remote site or server.
1. You can audit all the environments from development to production and there will be no performance degradation as it will not put the load on the server
2. Drutiny also integrates seamlessly with the other tools to ensure that you have maximum flexibility when it comes to running checks, e.g.
- Drush (e.g. check the status of a module, or get a variable value)
- SSH (e.g. filesystem checks, directory size checks)
- Phantomas (e.g. check the actual rendering of the site and ensure there are no in-page 404s)
3. You can run site audits against Drupal 7 or Drupal 8 sites using the same Drutiny codebase
4. It ensures the site state against performance and security best practices
5. It offers automation of sanity testing
6. Different types of report formats are available with Drutiny
Installation of Drutiny
Step 1: Drutiny can be installed in 2 ways:
In your project folder using composer - Add the composer dependency.
OR
As a standalone tool - Clone the Drutiny framework using composer
Note: We are using a standalone tool installation approach in this blog.
Step 2: Installing Drush for getting Drush aliases
The version of Drush to be used will depend on the site you're auditing. For instance, Drush 8 is recommended for D7 and D8 sites.
Step 3: Test the Drutiny installation
- If using Drutiny inside the project folder: Run the following command from the composer vendor bin directory
- If using Drutiny as a standalone tool
Step 4: Download Drush Aliases from Acquia Cloud (Optional)
Download the Drush 8 aliases for all of your sites and extract the archive into $HOME
This folder will contain two hidden folders named .acquia and .drush. Both of these folders should be placed in the $HOME directory on your system. The .acquia folder contains your Acquia Cloud API credentials and the .drush folder contains your Drush aliases for the sites you currently have access to on Acquia Cloud.
Note: Step 4 is only useful to get site aliases for the multiple sites on the Acquia cloud.
How to use Drutiny
When you're running Drutiny as a standalone tool use this basic command
Drutiny works with Policies and Profiles. These are the key elements of Drutiny.
Policy
Policies are structured YAML files that provide the human-readable context for an audit. You can see the predefined list of policies with the policy:list command.
Syntax:
Example: If you want to make sure that user # 1 is locked down, Cron is running, JS aggregation, Certain Modules are enabled or disabled.
What does a policy do?
You can view the policy details using thepolicy:info command and just pass the policy name.
Syntax:
Auditing a Policy
The user can run the single policy audit against a site using policy:auditcommand where policy is the name of the policy to run and the target is the Drush site alias.
Syntax:
Examples
- Audit a site for anonymous sessions via Drush
- Specifying a URL
In multisite scenarios, you will need to specify which site to connect to via a --uri option.
- Customize policy parameters
A policy may contain parameters that can be customised at the time of execution. To know what parameters are available, use the policy:info command
In this policy, the max_size and warning_size parameters can be specified. These parameters can be passed in at runtime like this:
Profile
Profiles are a collection of policies that audit a target against a specific context or purpose. Examples of the profile are Production-ready Drupal 8 site and Security or performance audit.
To view the list of available profiles in Drutiny, use the command profile:list
Syntax:
What does a profile do?
To know which policies are included in the profile, use the command called profile:info
Syntax:
Running a profile audit
The profile:run command allows you to run a profile against the target
Syntax:
Building a custom profile
The user can create a profile that is specific to their internal guidelines with the desired policies. Profiles are YAML files with a file extension of .profile.yml. To create a profile, use the command called profile:generate
Syntax:
The Drutiny will prompt you for the mandatory fields such as profile title, brief description about the profile, policies to be added in the profile and the file location.
And further, you can use your custom profile in the same way as built-in profiles.
Reports
Drutiny allows the use of 3 types of reporting formats:
- CLI
- HTML
- JSON
If you do not specify any report format, the CLI format will be used by default.
You can use the following parameters for the reports:
- -f parameter to write the format of the report
- -o parameter to specify where to store the report.
Syntax:
Open the HTML report in your browser to view the report. From there you can also print it to PDF. Refer to the report attached in the image below.
Conclusion
- The Drutiny is a very flexible tool as we can customize the policies, profiles and HTML reports and it also has support for other tools
- It is a highly useful tool when we want to support a lot of sites in the long term
- It allows business and product owners to check the existing automated reports, thereby helping them improve the site
- It is also helpful to technical leads to improve team processes and standardise site builds within the team
- It can also save development time and avoid mistakes when used before launching the sites
Happy Testing!