Disgusting DirectAdmin

Having had a hard day with a repository subscriber which claimed that the NGINX PageSpeed package did not work, the root cause of the issue was pretty simple to find.

Through a light email exchange, it was discovered that the subscriber was using DirectAdmin.

So here I decided to write a simple explanation on why you should not be coming even close to using DirectAdmin unless it’s only for a hobby/developer task.

Similar to cPanel, you should never use it, if you’re after a properly set up server.

Why is DirectAdmin so bad?

This is a control panel for those who are lazy to use the proper server configuration techniques and for whatever reason want to edit their config via GUI.

I remind you, what you should do instead of using control panels:

• Sanely use Terminal and set up your system once, so that there is no control panel “nightmare” process eats the server resources later
• Use only packages in the production system, as compiling software will never lead to good results, security-wise
• Use Ansible for templating configuration

If you opt to use control panels, you end up with a non-standard system, non-standard paths, and processes just hanging in there and eating up your RAM.

DirectAdmin does exactly that, and far more! It is so disgusting that it requires compilation software from the get-go, and then compiles much of its things (yuck! disgusting!)

DirectAdmin should never be used because:

• It is a control panel that installs over a hundred packages just as pre-requisite of its own installation!
• It is a control that disables SELinux on CentOS! It brings insecurity after just being installed!
• It is a control panel that modifies init scripts and other things rendering it impossible to remove it without reinstalling the entire server!!!
• It is simply a “compiled install” with custom paths to everything!
• It uses Apache by default.

All these things are just way too bad in the year 2020.

Packaged installation evolved so much that the need for control panels is very none unless you’re hosting a gazillion of sites on the same server.
In which case (hosting many sites via control panel), those who are being hosted on that server are the main victims, because a website running in a control panel, is likely to never scale its traffic to the level that brings profit.

Why you need a control panel? Because you lack SSH skills? But installing the “control panel” required SSH skills, no?
What do you need to really control on a server?

Set it up once. Set it up in a solid way. There is no need to “control” anything.

There, ranting complete 🙂

If you must use the disgust (c)

Keeping DirectAdmin use is highly discouraged for security reasons.

If you have to use it anyway, you can still use any of our available NGINX modules with it.

First, ensure NGINX is the webserver that is used in DirectAdmin:

./build set webserver nginx
./build set php1_mode php-fpm
./build update
./build all d
./build rewrite_confs

As with all-things-DirectAdmin, it is going to recompile the universe of apps and will take a sh** load of time.

Now you have the latest mainline NGINX installed from DirectAdmin.

Let’s set up the NGINX PageSpeed module for our example:

sudo yum -y install https://extras.getpagespeed.com/release-latest.rpm
sudo yum -y install nginx nginx-module-pagespeed

Because our shitty DirectAdmin does not allow customizing global NGINX configuration, you have to edit its “template” file which can be overwritten in case you update it

Change directory to /usr/local/directadmin/custombuild and edit ./configure/nginx/conf/nginx.conf:

load_module modules/ngx_pagespeed.so;

#user  nginx;

worker_processes  auto;
pid /var/run/nginx.pid;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

events {
    include /etc/nginx/nginx-events.conf;
}


http {
    pagespeed FileCachePath /var/cache/pagespeed; 
    include       /etc/nginx/mime.types;

    # For user configurations not maintained by DirectAdmin. Empty by default.
    include /etc/nginx/nginx-includes.conf;

    # Supplemental configuration
    include /etc/nginx/nginx-cloudflare.conf;
    include /etc/nginx/nginx-modsecurity-enable.conf;
    include /etc/nginx/nginx-defaults.conf;
    include /etc/nginx/nginx-gzip.conf;
    include /etc/nginx/directadmin-ips.conf;
    include /etc/nginx/directadmin-settings.conf;
    include /etc/nginx/nginx-vhosts.conf;
    include /etc/nginx/directadmin-vhosts.conf;
}

The additions to the file that we made are load_module modules/ngx_pagespeed.so; at the top, and pagespeed FileCachePath /var/cache/pagespeed; in the http {} section.

Regenerate actual NGINX configuration by running:

./build rewrite_confs

Finally, we can ensure that each website NGINX configuration generated by DirectAdmin, contains the necessary locations for PageSpeed:

• Go to DirectAdmin panel, switch to Admin settings
• Select “Custom HTTPD Configurations”
• Click nginx.conf alongside a domain name
• Click “Customize”
• In the “nginx.conf customization for example.com” enter:

pagespeed on;

# Ensure requests for pagespeed optimized resources go to the pagespeed handler
# and no extraneous headers get set.
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
  add_header "" "";
}
location ~ "^/pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }

• Click “Save” then regenerate NGINX configuration again by running ./build rewrite_confs in SSH again.

That’s all there is to it.

As you can clearly see, things can work with DirectAdmin, but it adds some direct(c), completely unnecessary complexity.