In a high-density web hosting environment, the modern developer’s toolkit—Node.js, NPM, Composer, and Redis—is no longer an optional “extra” but a baseline requirement for deploying performant PHP and JavaScript applications. However, on a cPanel infrastructure hardened with CloudLinux and Virtual Environments (LVE), providing these tools globally presents a unique challenge: balancing developer flexibility with the strict isolation of CageFS.

This article outlines the professional approach to orchestrating a global development stack. We will move beyond basic installations to focus on the systematic configuration of symlinks, the mapping of CageFS paths, and the critical security layers required to prevent “noisy neighbor” syndrome in a multi-tenant ecosystem.

Core Components of the Stack

  • Node.js & NPM: Providing both EA-Nodejs (cPanel native) and Alt-Nodejs (CloudLinux Selector) versions to cater to different application requirements.
  • Composer: The industry standard for PHP dependency management, optimized for global execution.
  • Redis: Leveraging a persistent, in-memory data structure store to drastically reduce database load and improve application response times.
  • CageFS Integration: Ensuring that while these tools are “global,” they remain securely encapsulated within each user’s private environment.

Why Global Access Matters

Without global configuration, users are often forced into manual path exports or local installations that consume unnecessary disk space and create support overhead. By centralizing these binaries, you ensure:

  • Standardization: Every user operates on the same vetted versions.
  • Simplicity: Commands like node -v or composer install “just work” out of the box.
  • Performance: Proper CageFS mapping ensures no latency penalty when entering the virtualized environment.
Continue reading

When some users switch to a new email naming policy, they may need to duplicate email content. This process can be very demanding in terms of inodes and memory space.

In my experience, one client had over a hundred addresses. They needed to retain the old email addresses while maintaining a complete history of previous emails and setting up forwarding.

The transitions were as follows:

  • ceo@example.com => firstname1.lastname1@example.com
  • hr@example.com => firstname2.lastname2@example.com
  • it@example.com => firstname3.lastname3@example.com, firstname4.lastname4@example.com

We use Maildir, and to avoid content redundancy. I wrote a basic script with the understanding that mail operations won’t alter the original emails. As the user can only:

  • Remove the email message, which will result in the removal of the symlink.
  • Or move the email message from one directory to another (e.g., Inbox => Archive, or Trash); which will be interpreted as moving the symbolic link to the directories .archives/cur or .trash/. Since we use full paths to describe the links, this won’t cause any issues and won’t alter the original files.

I have also excluded some maildir system files from being linked, starting usually with dovecot* or maildir*.

The script usage is straightforward:

./mailinker.sh mycpuser oldbox@example.com newbox@example.com
Continue reading

You can use hooks in SolusVM 2 to automatically run custom scripts before or after specific events take place. Hooks should be set under this directory: /usr/local/solus/hooks/, they can be written using Bash, PHP, Python or else.

 
Basically what it does is whenever there is an event it sends in stdin a json snap with the event and the action (e.g.: new installation, os reinstall, restart, etc) to all files under the hooks’ folder.
 
Example of JSON code:
{
  "action": "server-restart",
  "stage": "pre",
  "data": {
    "uuid": "915b5ca2-ff02-45ab-ba73-2e90793e6819",
    "virtualization_type": "vz"
  }
}

Continue reading

Amongst the PHP malwares targeting WP plugins’ vulnerabilities I encounter, some generate hundred of thousand of empty files with 0KB size in all folders and sub-folders recursively . which create diversion and affects the inodes capacity of an account. But diversion may not the only goal. as they are generated through an obfuscated code, so I can imagine that these filenames may be part of an obfuscation process. Instead of writing the directives directly in a PHP or text file, the information is gathered through the listing and ordering of the filenames, possible no? Or maybe I’m over-complicating it.
Continue reading

Any service that is exposed to the network is a potential target, and SSH being so widely deployed across the internet means that it represents a very predictable attack surface or attack vector through which people can try to gain access.

If you review the logs for your SSH service running on any widely trafficked server, you will often see repeated, systematic login attempts that represent brute force attacks by users and bots alike.

tail /var/log/auth.log
Continue reading

When securing a Linux server, simply using SSH keys and disabling passwords isn’t always enough—especially for root access, which is a prime target for attackers. Restricting IPs or VPN is a good approach but not always possible. To enhance protection, you can implement Port Knocking, ProxyJump/Bastion Host, and Google Authenticator 2FA—but exclusively for root users, while allowing normal users to log in more conveniently.

1. Port Knocking for Root Access

Port Knocking keeps SSH invisible unless a specific sequence of connection attempts is made first. This ensures that only authorized users can expose the SSH port.

  • Configure knockd to require knocking only for root login while normal users access SSH normally.
  • Example sequence to open SSH:
    sequence = 7000,8000,9000
    command = iptables -A INPUT -p tcp --dport 22 -s %IP% -j ACCEPT
    
  • Restrict SSH for root in sshd_config:
    Match User root
    Port 2222
    

Now, root users must “knock” to gain access, while normal users use standard SSH.


2. Google Authenticator 2FA for Root

Enforcing multi-factor authentication (MFA) for root ensures extra protection beyond SSH keys.

  • Install Google Authenticator:
    apt install libpam-google-authenticator
    dnf install google-authenticato
  • Require 2FA only for root in PAM:
    Match User root
    auth required pam_google_authenticator.so
    
  • Enforce multiple authentication methods:
    Match User root
    AuthenticationMethods publickey,password publickey,keyboard-interactive
    

This setup ensures root users need an extra authentication step, while normal users continue with SSH keys.
If 2FA providers are unavailable, emergency bypass OTP backup codes or physical security tokens can restore access.


3. Bastion Host for Root

A Bastion Host (Jump Host) acts as an intermediary, ensuring direct SSH access to root is not possible.

  • Restrict root login to only be allowed from the bastion:
    Match User root
    AllowTcpForwarding no
    AllowUsers root@bastion-ip
    
  • On the client side, enforce ProxyJump:
    Host myserver
        User root
        ProxyJump bastion_host
    

With this setup, attackers cannot SSH directly to the server as root.

Pros & Cons
A Bastion Host is a great security solution, but it comes with both benefits and drawbacks. Here’s a balanced look at its pros and cons.
Pros of Using a Bastion Host

✅ Enhanced Security Layer – It prevents direct SSH access to critical servers, reducing the risk of brute-force attacks.
✅ Centralized Access Control – Acts as a single entry point, making user authentication and permissions easier to manage.
✅ Logging & Auditing – Bastion hosts can record SSH sessions, helping with security monitoring and compliance.
✅ Reduced Attack Surface – Since users must go through the bastion, fewer ports are exposed on the actual servers.
✅ Multi-Factor Authentication (MFA) Support – You can enforce 2FA or biometric authentication for extra security.
Cons of Using a Bastion Host

❌ Single Point of Failure – If the bastion goes down, users may lose access to the entire infrastructure unless backup access is in place.
❌ Performance Bottleneck – If not scaled properly, it can slow down connections, especially with large numbers of users.
❌ Additional Complexity – Requires extra configuration and maintenance, including access rules and monitoring.
❌ Target for Attackers – Since all SSH traffic goes through it, attackers may try to compromise the bastion itself.
Final Thoughts

 

Verdict: A Bastion Host is an excellent security tool, but it must be hardened properly, monitored, and paired with backups to ensure reliability. E.g.:

iptables -A INPUT -p tcp –dport 22 -s BACKUP_IP -j ACCEPT


Final Thoughts

By combining Port Knocking, Bastion Host restrictions, and 2FA, you can make SSH access to root far more secure while ensuring redundancy in case of root access failure and allowing normal users to log in more conveniently. These techniques significantly reduce the risk of unauthorized access while maintaining a balance between security and usability.

If you have tried to install DirectAdmin on Ubuntu and received an error related to GNU C Library such as:

/usr/local/directadmin/directadmin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /usr/local/directadmin/directadmin)

This implies that you have chosen the wrong OS on the ordered license. Ubuntu isn’t yet specifically supported therefore choosing Ubuntu or Debian on the drop-list may not be helpful. Configure rather your license for Linux 64bits.

P.S.: If you encounter a different issue, search directly on DirectAdmin Forums, don’t rely on global search engines.