Welcome to my bit of the web, it has existed in some form since October 2000.

Personal Software Projects Portfolio

By in Blog Tags: , , , , , ,

Welcome to my collection of hobby software projects. This page catalogs various programming experiments and tools I’ve developed in my spare time. In the future, I’ll expand this section with more detailed explanations of the code, methodologies, and availability options. For now, you can explore each project by following the links below, which will take you to interactive demonstrations.

Hosting Infrastructure

Each project is containerised and hosted using Docker images running on a dedicated server. While I make these available for demonstration purposes, please note:

  • These projects are hosted on modest hardware with no uptime guarantees
  • Functionality may occasionally change, typically to fix issues or improve the user experience
  • The original code is generally preserved when creating new versions, allowing for comparison between iterations

Update (5 February 2024): Due to increasing popularity, all tools have been migrated to a dedicated server running a reverse proxy system. This infrastructure upgrade means all projects now use secure connections (HTTPS) and are served from my domain rather than direct IP addresses.

Project Catalogue

Magic Eight Ball

Magic Eight Ball

  • A simple interactive fortune-telling toy implemented in Python
  • Uses a minimalist HTML design with basic templating
  • Provides random answers to yes/no questions in the spirit of the classic toy

Sudoku Solver Evolution

My Sudoku solver has gone through several iterations, each improving upon the previous version:

Sudoku Solver v1

  • Initial proof-of-concept built with Flask and Python
  • Extremely basic user interface with minimal styling
  • Uses a fundamentally inefficient solving algorithm
  • Can be overwhelmed by complex or impossible puzzles

Sudoku Solver v1.1

  • Maintains the same core solving algorithm as v1
  • Features an improved web interface that better visualises the puzzle
  • Shares the same limitations and inefficiencies of the original version

Sudoku Solver v2

  • Significant rewrite of the codebase while still using Python and Flask
  • Implements intelligent validation to detect impossible puzzles early
  • Employs a smarter solving approach that eliminates testing numbers that can no longer be used
  • Drastically reduces solving time compared to earlier versions
  • Provides more accurate iteration counting
  • Enhanced HTML interface with replay functionality and improved SEO elements

Sudoku Solver v2 (January 2024 Update)

  • Resolves reliability issues when handling impossible puzzles
  • Significantly improved accessibility with keyboard navigation (tabbing between cells)
  • Revolutionary new solving methodology:
    • Prioritises cells with the fewest possible candidates
    • Focuses on solving surrounding cells first
    • Uses intelligent backtracking when no immediate solution is available
    • Reduces solution attempts to approximately 1/100th of the v2 algorithm
    • Completely abandons the brute-force approach used in earlier versions

Noughts and Crosses v1

  • Slightly fuller implementation of Noughts and Crosses than the other projects.
  • More like a mini-site with better formatting and the starts of a user system
    • Pretend you are in the 80’s and do a little bit of Wargaming!

Technical Implementation Details

While not extensively documented yet, these projects share some common technical characteristics:

  • Backend development primarily in Python
  • Web interfaces built with Flask
  • Containerisation using Docker for consistent deployment
  • Reverse proxy setup for secure HTTPS access
  • Modular design allowing for iterative improvements

Future Developments

I plan to expand this portfolio with:

  • More detailed technical documentation for each project
  • Source code availability information
  • Additional projects currently in development
  • Performance metrics and comparison between different versions
  • Design rationale and lessons learned

Check back periodically for updates, as I’ll be adding new projects and enhancing documentation for existing ones.

Update Your Windows Programs with Ease: Mastering the winget upgrade Command

By in Blog Tags: , , , , , ,

Keeping your software up-to-date is crucial for optimal performance and security on your Windows machine. Traditionally, this involved visiting individual websites or manually checking for updates within each program. Thankfully, Windows 11 offers a more streamlined approach through the Windows Package Manager (winget).

In this post, I’ll show you how to use the powerful winget upgrade command with the --all flag to effortlessly update all your installed programs at once. I’ll also share some alternative commands that give you more control over the update process.

Updating Everything with winget upgrade --all

The winget upgrade --all command is like a one-stop shop for updating all your installed applications through winget. Here’s how to use it:

  1. Open Command Prompt: Press the Windows key + R, type “cmd,” and press Enter.
  2. Execute the Command: Type winget upgrade --all and press Enter.

That’s it! Winget will scan your system for software updates and, after prompting for confirmation (if applicable), proceed with the download and installation process. It really is that simple.

Beyond --all: Exploring Other winget upgrade Commands

While the --all option is incredibly convenient, sometimes you might want a more targeted approach. Here are some useful variations of the winget upgrade command that I’ve found helpful:

  • winget upgrade <package-id>: This updates a specific program. Find the package ID using winget list.
  • winget upgrade --source <source-name>: Updates from a specific software repository (source).
  • winget upgrade --include-unknown: Upgrades even uninstalled applications with available updates.
  • winget upgrade --silent: Performs the upgrade silently, without prompting for confirmation. (Use with caution!)

Additional Tips for Power Users

If you really want to get the most out of winget, here are a few extra tips I’ve picked up:

  • Schedule Updates: Create a scheduled task to run winget upgrade --all periodically for automated updates. This is perfect if you want to keep things up-to-date without having to remember to run the command.
  • Review Updates First: Before running --all, consider reviewing the update list with winget upgrade --info to identify any potential conflicts. This can save you headaches if certain updates might cause problems with your workflow.
  • Official Resources: For detailed information on winget commands and functionality, check out the official Microsoft documentation: https://learn.microsoft.com/en-us/windows/package-manager/winget/upgrade

By leveraging these winget upgrade commands, you can streamline your software update process, ensuring a secure and optimized Windows environment. I’ve found this approach saves me tons of time compared to the old manual update method.

Just remember to implement these commands with caution, especially when using the --silent option or when updating critical software. A quick review before hitting Enter can prevent unexpected issues!

Have you tried using winget to manage your software updates?

Navigating Email Spam Filters: Understanding and Adjusting Sieve Scripts on Plesk Servers

By in Blog Tags: , , , , , , ,

Sieve scripts — a tool used in Plesk servers outfitted with Dovecot and Warden Anti-Spam — which can lead to rules that filter emails in unexpected ways. If you’ve noticed emails mysteriously disappearing or ending up in spam folders when they shouldn’t, Sieve scripts could be the culprit worth investigating.

The Role of Sieve Scripts in Email Management

Sieve scripts offer a robust mechanism for filtering emails on the server side. They empower users to automate actions such as sorting emails into designated folders, setting up auto-replies, and filtering out spam. Implemented on the server, these scripts process emails before they even hit your email client, serving as a critical defence line against unwanted communications.

A Case Study: The Journey to INBOX.Spam

A recent examination revealed an interesting case where an email, marked as clean by the content filter Amavis, was nonetheless directed to the INBOX.Spam folder. The culprit? A specific fileinto action within a Sieve script, instructing Dovecot to categorise the email as spam. This instance highlights the significant impact Sieve scripts can have on email routing.

How to Access and Modify Sieve Scripts in Plesk

Plesk server users can manipulate Sieve scripts through the web interface or by shell access for those requiring a deeper level of customization. Within the Plesk interface, the “Mail” section offers a gateway to adjusting spam filter settings and managing rules at the individual email account level. For more advanced modifications, including direct Sieve script edits, shell access will be necessary. This approach demands a good grasp of Linux commands and familiarity with Dovecot’s structure.

Sieve Script File Paths and Patterns

Sieve scripts are typically located in the user’s mail directory, with paths varying based on the server’s configuration. Common locations include:

  • /var/qmail/mailnames/domain.com/username/.dovecot.sieve
  • /var/qmail/mailnames/domain.com/username/sieve/

When editing Sieve scripts, you might encounter patterns like:

if address :all :comparator "i;ascii-casemap" :is ["From", "Sender", "Resent-From"] ["example@domain.com"] {
 fileinto "INBOX.Spam";
 stop;
}

This rule directs emails from example@domain.com straight to spam, showcasing how specific patterns in Sieve scripts govern email sorting.

Adjusting Filtering Rules

The Sieve script shared earlier delineates various rules for email handling, from whitelisting certain addresses to blacklisting others, and employing spam filters based on the X-Spam-Level header. For instance, it includes conditions to file emails from specific senders into INBOX.Spam, underlining the necessity of precise rule configuration to avoid ensnaring legitimate emails.

Best Practices for Sieve Script Management

  1. Review Rules Periodically: Keep an eye on your Sieve script rules, especially after changes in email communication patterns.
  2. Proceed With Caution: Be careful when modifying Sieve scripts! Small syntax errors can have big consequences for email delivery.
  3. Back Up Before Modifying: Always back up your existing scripts before making adjustments:
    cp /path/to/username/.dovecot.sieve /path/to/username/.dovecot.sieve.backup
  4. Use Comments for Clarity: Add comments to remember why you created certain rules:
    # Rule to handle marketing emails
if header :contains "Subject" "Newsletter" {
 fileinto "INBOX.Marketing";
}
  5. Monitor After Changes: After tweaking rules, keep an eye on your email for a few days to make sure everything’s working as expected.

Troubleshooting Common Issues

If emails seem to go missing, first check your spam folder! It’s amazing how often this simple step resolves the mystery.

For syntax issues after editing, you can verify your script with:

sievec /path/to/script.sieve

If your changes don’t seem to take effect, check that the file ownership matches the mail user and consider restarting Dovecot to reload scripts.

Efficient email management hinges on a fine-tuned approach to spam filtering. By getting comfortable with Sieve scripts on your Plesk server, you can take control over which emails land in your inbox versus spam. Regular reviews and cautious customisation of these scripts will ensure your email system remains effective and secure, tailored to your specific needs.

Expanding the Root Partition on Debian with LVM: A Step-by-Step Guide

By in Blog Tags: , , , , , ,

Expanding your Debian server’s root partition without downtime is a critical skill for managing server resources efficiently, especially when you’re using Logical Volume Manager (LVM) for disk management. This guide provides a detailed walkthrough, including command outputs for clarity and copy-paste commands for ease of use.

Prerequisites

Before beginning the partition expansion process:

  • Ensure you have backed up all critical data
  • Verify you have root access or the ability to use sudo
  • This guide assumes familiarity with basic Linux terminal commands
  • Your system should be using LVM for volume management

Step 1: Verify Current Disk Layout

Identify your disk’s current layout to determine the partition you need to resize. Use lsblk to list all block devices and their mount points:

lsblk

Example output:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT 
sda 8:0 0 160G 0 disk 
├─sda1 8:1 0 487M 0 part /boot 
└─sda2 8:2 0 20G 0 part
 ├─vg00-lv01 254:1 0 8G 0 lvm /
 └─vg00-lv00 254:0 0 2G 0 lvm [SWAP]

This output shows:

  • A 160GB disk (sda)
  • A boot partition (sda1) of 487MB
  • An LVM partition (sda2) of 20GB, containing:
    • An 8GB root logical volume (vg00-lv01)
    • A 2GB swap logical volume (vg00-lv00)

Step 2: Resize the Partition with fdisk

Caution: Deleting and recreating the partition must be done carefully to avoid data loss.

  1. Launch fdisk on Your Disk: 
    bash
    sudo fdisk /dev/sda
  2. Delete the Existing Partition: First, print the partition table:
    Command (m for help): p
    Example output:
    Disk /dev/sda: 160 GiB, 171798691840 bytes, 335544320 sectors
Disk model: Virtual Disk
Units: sectors of 1 * 512 = 512 bytes
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 999424 20971519 19972096 20G 8e Linux LVM
    Note the Start sector of /dev/sda2. Delete /dev/sda2:
    Command (m for help): d
Partition number (1,2, default 2): 2
  3. Recreate the Partition: Create a new primary partition:
    Command (m for help): n
Partition type
 p primary (1 primary, 0 extended, 3 free)
 e extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (999424-335544319, default 999424): 999424
Last sector, +/-sectors or +/-size{K,M,G,T,P} (999424-335544319, default 335544319):
    Important: Use the same starting sector as noted earlier (999424 in this example). If prompted about removing the signature, choose No:
    Partition #2 contains a LVM2_member signature.
Do you want to remove the signature? [Y]es/[N]o: N
  4. Set the Partition Type: Change the partition type to Linux LVM:
    Command (m for help): t
Partition number (1,2, default 2): 2
Hex code (type L to list all codes): 8e
  5. Write Changes and Exit:
    Command (m for help): w

Step 3: Reboot the System

After modifying the partition table, reboot your system:

sudo reboot

This step is necessary for the kernel to recognise the new partition table.

Step 4: Resize the Physical Volume

Once the system has rebooted, notify LVM of the partition’s new size:

sudo pvresize /dev/sda2

This command adjusts the physical volume to use the newly expanded partition space.

Step 5: Extend the Logical Volume

Increase the size of the logical volume to use all available space:

sudo lvextend -l +100%FREE /dev/vg00/lv01

This command allocates all available free space in the volume group to the logical volume.

Step 6: Resize the Filesystem

Finally, resize the filesystem on the logical volume to use the newly allocated space.

For ext4 filesystem:

sudo resize2fs /dev/vg00/lv01

For xfs filesystem:

sudo xfs_growfs /dev/vg00/lv01

Verification

After completing all steps, verify that your root partition has been successfully expanded:

df -h /

This will show the new size of your root filesystem.

Troubleshooting Common Issues

Issue: Unable to Delete Partition

If you receive errors when trying to delete the partition, ensure no process is using it:

lsof | grep sda2

Issue: LVM Not Recognising New Size

If pvresize doesn’t recognise the new size, try rescanning the SCSI bus:

echo 1 > /sys/class/block/sda/device/rescan

Issue: Filesystem Not Expanding

If the filesystem doesn’t expand despite successful LV extension, check the filesystem type:

df -T /

And use the appropriate resize command based on the filesystem type.

Conclusion

You’ve now successfully expanded your root partition to utilise additional disk space, enhancing your Debian server’s capacity without significant downtime. Remember, the key to a smooth operation is careful planning and ensuring you have backups before starting.

This technique is particularly useful for virtual machines where disk space can be allocated dynamically, allowing you to adjust storage resources as your requirements grow.

Block WordPress XML-RPC Requests on Linux Servers

By in Blog Tags: , , , , , ,

The XML-RPC Security Challenge

If you run a server hosting multiple websites, you may encounter issues with WordPress installations due to a feature called XML-RPC. This remote admin functionality allows third-party applications to connect to WordPress sites and post new articles or perform other administrative actions.

While XML-RPC is excellent in theory, in practice it has become a significant avenue for attack by bot networks. Server administrators often observe hundreds or thousands of malicious connection attempts per minute across multi-domain hosting environments. On one of our servers hosting 40 sites (nearly all WordPress), these attacks are a constant concern.

Impact on Server Performance

These malicious XML-RPC requests consume valuable server resources even when they fail to compromise a site. With multiple WordPress installations managed by people with varying technical skills, some sites may become vulnerable due to outdated software or poor maintenance practices.

The cumulative impact of these requests can significantly degrade server performance, causing:

  • Increased response times for legitimate visitors
  • Higher CPU and memory usage
  • Potential service disruptions during peak attack periods
  • Premature need for hardware upgrades

Implementing a Solution with mod_security

If you’re running mod_security (which is strongly recommended for protecting your sites and your clients’ sites), you can add the following rule to block malicious XML-RPC requests:

#Block requests to xmlrpc.php with no referring URL
SecRule REQUEST_METHOD "POST" "deny,status:401,id:5000900,chain,msg:'xmlrpc.php request blocked, no referer'"
SecRule &HTTP_REFERER "@eq 0" "chain"
SecRule REQUEST_URI "xmlrpc.php"

Adapted from a post on cPanel forums by ‘dalem’ (https://forums.cpanel.net/threads/xmlrpc-spam.646765/)

How This Solution Works

Once implemented, any request to xmlrpc.php that doesn’t originate from a link or trigger from a legitimate website (i.e., has no referrer) will be blocked with a 401 (Forbidden) response. This effectively stops the vast majority of automated attacks whilst allowing legitimate XML-RPC usage.

Enhanced Protection with Firewalls

For additional protection, if you have a firewall or IP banning software such as CSF Firewall or Fail2ban, you can configure these tools to scan your log files and automatically ban repeat offenders that trigger this mod_security rule.

This layered security approach provides both immediate request blocking and longer-term protection against persistent attackers.

When This Approach May Not Be Suitable

This solution may not be appropriate in all scenarios, particularly:

  • If you or your customers actively use third-party services that utilise the XML-RPC functionality
  • When legitimate applications need programmatic access to WordPress without a referrer

If you have specific IPs that need to access XML-RPC (such as from a content management system or publishing tool), you could modify the rule to exclude those IP addresses. However, this approach may become difficult to maintain over time, especially with services that don’t use fixed IP addresses.

Alternative Approaches

If the solution above doesn’t suit your needs, consider these alternatives:

  1. Selective enabling: Only enable XML-RPC on specific WordPress sites that genuinely need it
  2. Plugin solutions: Use security plugins that provide more granular control over XML-RPC access
  3. IP whitelisting: Configure your web server to only allow XML-RPC requests from trusted IP addresses
  4. Request throttling: Implement rate limiting for XML-RPC endpoints

Conclusion

By implementing this mod_security rule, you can significantly reduce server load and improve security across multiple WordPress installations. The approach is particularly valuable for shared hosting environments where WordPress sites of varying ages and maintenance levels coexist.

Monitor your server logs after implementation to ensure legitimate services aren’t being inadvertently blocked, and adjust your rules as needed to balance security and functionality.

cPanel: How to Combine Apache Logs for Easier Troubleshooting

By in Blog Tags: , , , , , , ,

Default Location of Logs

By default, cPanel places its log files in /usr/local/apache/domlogs/DOMAIN. These logs are split up by domain, which keeps things organised but can make troubleshooting difficult when you need to identify patterns across multiple domains or determine where a specific problem might lie.

The Challenge with Separate Domain Logs

When managing a server with multiple websites, having logs separated by domain creates several challenges:

  1. You need to check multiple files when troubleshooting server-wide issues
  2. It’s difficult to identify patterns that might affect several domains
  3. When investigating suspicious activity, you can’t easily see if it’s targeting multiple sites
  4. Resource usage analysis becomes more complex

Creating Combined Logs

While combining logs can be done with a bash script that concatenates existing files, this approach is time-consuming and doesn’t provide real-time insight. A more efficient solution is to modify the Apache configuration to create a new combined log file that captures all domain activity in a single location.

Edit Your vhost.default File

For Apache 2.4 (the current version at the time of writing), you’ll need to edit the vhost template file:

nano /var/cpanel/templates/apache2_4/vhost.default

Add the following lines just before the </VirtualHost> tag at the bottom of the file:

LogFormat "%V %a %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\"" vcommon
CustomLog /usr/local/apache/logs/vhost-access_log vcommon

Understanding the Log Format

This configuration creates a custom log format called “vcommon” with the following components:

  • %V – The server name according to the UseCanonicalName setting
  • %a – Client IP address
  • %l – Remote logname (usually ‘-‘)
  • %u – Remote user if authenticated
  • %t – Time the request was received
  • \"%r\" – First line of request (method, path, protocol)
  • %s – Status code
  • %b – Size of response in bytes
  • \"%{Referer}i\" – Referer header
  • \"%{User-agent}i\" – User-agent header

The %V at the beginning is particularly important as it identifies which domain the log entry is associated with, allowing you to still filter by domain when needed while keeping everything in one file.

Rebuilding the Apache Configuration

To implement these changes, you need to rebuild the Apache configuration and restart the service:

/scripts/verify_vhosts_includes
/scripts/rebuildhtpdconf
/scripts/restartsrv_httpd

After completing these steps, a new combined log file will be created at /usr/local/apache/logs/vhost-access_log that contains entries from all your domains.

SSL Considerations

If you want to track SSL accesses in the combined log as well, you’ll need to make a similar modification to the SSL vhost template. However, as the author notes, this may not be necessary if you have a limited number of SSL sites, as they tend to stand out more in normal monitoring.

If you do wish to include SSL logs, edit:

nano /var/cpanel/templates/apache2_4/ssl_vhost.default

And add the same LogFormat and CustomLog lines as above.

Log Rotation Considerations

Remember that creating a new log file requires proper log rotation configuration to prevent it from growing too large. This topic will be covered in a future post, but it’s important to implement log rotation for any new log files you create.

A basic approach would be to add an entry to /etc/logrotate.d/apache to ensure your new combined log is rotated alongside the standard Apache logs.

Benefits of Combined Logs

With this configuration in place, troubleshooting becomes significantly easier:

  1. One file to tail or grep instead of dozens
  2. Ability to see patterns across multiple domains
  3. Easier identification of distributed attacks targeting multiple sites
  4. Simplified log analysis with tools like AWStats or GoAccess

This simple configuration change can save considerable time and effort when managing a multi-domain cPanel server, making it a valuable addition to your server administration toolkit.

cPanel/Linux – ApacheTop for Real-time Server Monitoring

By in Blog Tags: , , , , , ,

Introduction

Apache is a powerful web server, and cPanel offers excellent management capabilities, but when you need to diagnose what’s consuming resources or causing slowdowns, the built-in tools can be limited. ApacheTop helps by providing real-time analysis of your web server traffic.

One of the most useful diagnostic methods is examining raw Apache logs. However, if you’re managing a busy site or a server with dozens (or more) domains, ApacheTop becomes an invaluable tool for getting a clear picture of what’s happening on your server.

cPanel Preparation

If you’re using cPanel, I recommend combining your domain logs first to make analysis more straightforward. You can find instructions for combining Apache logs here. While there are alternative methods for consolidating logs, any approach that combines your logs will work with ApacheTop.

Installation on CentOS

The following installation instructions are specific to CentOS, though you can install ApacheTop on most Linux distributions with similar package management commands.

Enable EPEL Repository

First, enable the EPEL (Extra Packages for Enterprise Linux) repository. This gives you access to third-party repositories not directly maintained by CentOS. As with any third-party repository, appropriate caution is warranted.

Run the following command:

yum install epel-release

If this command doesn’t work, search for the appropriate epel-release RPM package for your version of CentOS.

Note: Installing this package will clear your YUM cache files, so the next command may take a few minutes longer than usual to complete.

Install ApacheTop

Once EPEL is enabled, installing ApacheTop is straightforward:

yum install apachetop

That’s all there is to the installation process!

Using ApacheTop

To run ApacheTop, simply execute the command and direct it to your Apache log file. The tool will begin reading logs from that point onwards. Press the space bar to refresh the statistics more frequently than the default interval.

apachetop -f /usr/local/apache/logs/vhost-access_log

Useful Tips

While using ApacheTop, press ? to access the help menu for a complete list of commands and options.

Here are some particularly useful features:

  • Press d to cycle through different statistical views
  • The host view displays the number of hits and data transfer for each host, making it easy to identify poorly behaving clients
  • The referrer view shows where your traffic is coming from—especially useful if a site has received publicity and is experiencing heavy traffic

For the most meaningful analysis, I recommend leaving ApacheTop running for at least 5 minutes to gather sufficient data before evaluating the results.

Practical Applications

ApacheTop can help you:

  • Identify individual IP addresses causing excessive traffic
  • Determine which pages or resources are most frequently requested
  • Monitor bandwidth consumption in real-time
  • Detect potential DDoS attacks or unusual traffic patterns
  • Optimise your server configuration based on actual usage patterns

Conclusion

ApacheTop is a lightweight yet powerful tool for real-time monitoring of Apache web servers. By providing immediate insights into server activity, it helps administrators quickly identify and address performance issues before they impact users.

For cPanel administrators, combining this tool with consolidated Apache logs creates an efficient monitoring solution that makes troubleshooting significantly easier.

Have fun and happy debugging!

How to Recover from the Latest JavaScript WordPress Hack

By in Blog Tags: , , , , , , , ,

Hack

In the last two weeks, a new hack has made the rounds. This exploits a weakness in either the hosting or the security of a WordPress blog and adds malicious code to every JavaScript file (.js). The code can vary a bit but typically starts like this (with a unique identifier):

/*3395379449f353892757e0b699dd2159*/;window["\\x64\\x6f"+"\\x63\\x75"+"\\x6d\\x65"

And ends like this (with the same unique identifier, which varies per site):

["\\x31\\x32\\"]].join(""));/*3395379449f353892757e0b699dd2159*/

Why This Hack Is Particularly Problematic

As this malicious code gets injected into all JavaScript files, it’s particularly tricky to remove. To date, the normal security tools do not detect this vulnerability (including Sucuri), but I am sure with the next major update they will incorporate detection.

The exact cause isn’t yet known, but most likely it’s due to out-of-date plugins which allow unauthorised modification of files. Once that vulnerability is exploited, the infection seeks out JavaScript files and appends the malicious code to the end of each one.

Cleaning Your WordPress Installation

Cleaning the infected files is not easy; in-situ it is almost impossible. If you have access to a Linux-based computer or a Mac (based on FreeBSD), these instructions can help you clean up your site. You should still update your plugins and WordPress version afterwards to prevent re-infection.

Step 1: Backup

Download all your files, including everything, to ensure a complete eradication is possible. Once downloaded, compress the files into a ZIP archive (keep a copy to work on; the ZIP is there in case you need to restore anything).

Step 2: Clean

The easiest way to clean is to restore an old backup from before the infection. If you have one, upload it (overwriting existing files) and proceed to the hardening step below.

If you don’t have a backup, or your backup was also compromised, you can try using the sed command. This command differs slightly between macOS and Linux:

For macOS (FreeBSD) users:

LC_ALL=C find /PATH_TO_YOUR_HACKED_FILES/ -type f -exec sed -i '' -E "s/(\/\*.{32}\*\/\;window\[.*\/\*.{32}\*\/)/ /" {} +

The LC_ALL=C prefix ensures it will work on Macs with a non-US locale. The expression looks for the starting window string with the unique comment identifier, then finds the matching ending comment and removes everything in between.

For Linux users:

find /PATH_TO_YOUR_HACKED_FILES/ -type f -exec sed -i -E "s/(\/\*.{32}\*\/\;window\[.*\/\*.{32}\*\/)/ /" {} +

Note that for Linux, you remove both the LC_ALL=C prefix and the empty quotes ('') after -i. In FreeBSD (macOS), these empty quotes prevent the creation of backup files, which aren’t needed in this case.

This approach could potentially affect legitimate code; however, as the malicious code is deliberately obfuscated, it’s generally safer to remove anything matching this pattern that you can’t easily read or verify.

Step 3: Upload & Hardening

Now upload your cleaned files, overwriting all existing files. Your site is (for now) clean. To harden your WordPress installation against future attacks, I recommend the following steps:

  1. Update your WordPress core to the latest version
  2. Update your themes (a more common vector for attack than most people realise)
  3. Update all your plugins to their latest versions

Finally, install security plugins to help prevent modifications. These can also warn you if someone logs into your blog and alert you to other important changes.

I recommend Sucuri Security. It has a free version with premium additions. The free version is sufficient for most sites, but if your site generates revenue, I recommend considering the paid version for enhanced protection.

Once installed, go through the setup process and enable as many protective features as feasible for your site, especially directory protection.

Troubleshooting: “My Site Stopped Working After Hardening”

Don’t panic! This usually happens because one of your plugins needs more access than the security settings allow. To identify the problematic plugin:

  1. Disable all plugins
  2. Re-enable them one by one
  3. When you find the one that doesn’t work with the security measures, you can create an exception rule for it

Final Check

After cleaning and hardening, it’s worth performing a quick check to see if you have any unrecognised directories or files that might indicate other compromises. Review your site structure carefully and look for anything unusual or unexpected.

By following these steps, you should be able to recover from this JavaScript hack and better protect your WordPress site against future attacks. Remember that security is an ongoing process—regular updates and monitoring are essential to keeping your site safe.

Why Is My Raspberry Pi Slow? Monitoring Performance with Htop

By in Blog Tags: , , , , , , , ,

After you’ve had your Raspberry Pi for a while and you’ve made it run a web server, media centre, Remote Desktop and more, you might find it’s becoming a bit sluggish. To diagnose performance issues and identify resource-hungry processes, there’s a brilliant tool called htop that can help.

Understanding System Performance

Traditionally in Linux, you would use the top command to view system processes and resource usage. However, this generally needs a bit more know-how to interpret the display, and it looks rather plain and difficult to parse at a glance.

Introducing Htop: A Better Process Viewer

An ideal replacement for top is ‘htop’, developed by Hisham Muhammad. This is an excellent process viewer with simple colour coding and a graphical output to show where resources might be used. Here’s a sample screenshot from my Pi:

Screen-Shot-2016-02-10-at-00.20.32 htop – a process viewer for the Raspberry Pi

Installing Htop on Your Raspberry Pi

Installation is straightforward. Simply open a terminal and enter:

sudo apt-get update
sudo apt-get install htop

That’s it! It’s extremely easy to install and has no real overhead when running, making it suitable even for resource-constrained devices like the Raspberry Pi.

Understanding the Htop Display

CPU Usage

At the top of the display, the numbers 1, 2, 3, 4 represent each processor core’s status (for multi-core models like the Raspberry Pi 4; older models will show fewer cores). The more a core is in use, the further the corresponding graph extends to the right. Different colours indicate different types of processes:

  • Blue: Low-priority processes
  • Green: Normal user processes
  • Red: Kernel processes

Memory Usage

The Mem/Swp bars show the utilisation of your RAM and Swap space:

  • RAM (Memory): Linux typically fills RAM for caching, so seeing high utilisation isn’t necessarily a problem. What’s important is the breakdown of used versus cached memory.
  • Swap: This is virtual memory on your SD card. Your swap should not be used too much—if it is, your system will often slow down as it swaps memory between the disk (or SD card) and RAM as required. Heavy swap usage is a key indicator that you need more physical RAM or need to reduce your workload.

Process List

The main section displays all running processes with details like:

  • PID (Process ID)
  • User (who owns the process)
  • Priority (PR) and Nice values (NI)
  • Virtual (VIRT), Resident (RES), and Shared (SHR) memory usage
  • CPU% and MEM% (percentage of CPU and memory used)
  • Time (how long the process has been running)
  • Command (what program the process is)

Running and Using Htop

Running htop is simple—just log in to the command line (via SSH or local terminal) and type:

htop

Useful Controls and Features

Htop offers many useful features through function keys:

  • F1: Help
  • F2: Setup (customise the display)
  • F3: Search for a process
  • F4: Filter processes by name
  • F5: Tree view (show parent-child relationships)
  • F6: Sort by a column
  • F7/F8: Decrease/increase process priority (nice value)
  • F9: Kill a process (useful for terminating unresponsive applications)
  • F10: Quit

You can also use traditional keyboard shortcuts like Ctrl+M to sort by memory usage or Ctrl+P to sort by processor usage.

Customising Htop

Using F2, you can access the setup menu to add more charts to the top section—on both left and right sides. Don’t forget to save your new default settings for future sessions.

This customisation allows you to focus on the metrics most relevant to your specific use case, whether that’s network I/O, memory breakdown, or CPU load averages.

Identifying Performance Issues

When diagnosing why your Raspberry Pi is running slowly, look for:

  1. Processes with high CPU usage (near 100% consistently)
  2. High swap usage (indicating memory pressure)
  3. Processes consuming large amounts of memory
  4. Many zombie processes (may indicate underlying issues)

Once you’ve identified problematic processes, you can decide whether to:

  • Kill unnecessary processes
  • Optimise applications
  • Reduce the services running simultaneously
  • Consider a hardware upgrade if possible

Availability on Other Linux Systems

If you use another flavour of Linux, it most likely has htop available as well. On CentOS-based systems, try:

yum install htop

Conclusion

Htop is an invaluable tool for monitoring and managing your Raspberry Pi’s performance. With its intuitive interface and detailed information, you can quickly identify what might be causing your Pi to slow down and take appropriate action to optimise its performance.

Regular monitoring with htop can help you maintain a smoothly running system by identifying issues before they significantly impact performance, making it an essential addition to any Raspberry Pi enthusiast’s toolkit.

Keeping Your Raspberry Pi Install Tidy After Upgrades and Changes

By in Blog Tags: , , , , , , , ,

Whilst Linux in general is very good at being neat and tidy, devices such as the Raspberry Pi, where resources can be much more limited than other computers, can sometimes suffer—usually from lack of space (performance will be dealt with in another post).

The Problem with Updates and Package Changes

If you’ve recently made changes—removed some packages, or manually updated some components—you may find your disk space getting a bit lower. This is because Linux package managers don’t always clean up perfectly after themselves. Some common scenarios that lead to wasted space include:

  • Cached package files that were downloaded during updates
  • Dependencies that are no longer needed after removing applications
  • Older versions of packages kept after upgrades
  • Temporary files created during installations

Simple Cleanup Commands

Fortunately, one of the tools you can use is built into apt-get and allows it to scan and remove dependencies no longer required. To reclaim your disk space, simply run the following commands:

1. Clean Up Package Archives

sudo apt-get autoclean

This removes old archive files that might have been left behind. Note you can use clean as well—however, this can cause slowness as it removes all archive files, and some may be needed again soon if you’re frequently installing and updating packages.

2. Remove Unused Packages

sudo apt-get autoremove

This removes any unused packages—often these can be left behind if you remove a programme which had optional dependencies, as these dependencies are not always removed by the system. Other system changes may have now marked certain packages as unused as well.

Results You Can Expect

The output of these commands will look similar to this:

Screen-Shot-2016-02-03-at-00.37.23 Claiming back some disk space using apt-get autoremove

In this particular example, I gained back 300MB of space. However, I’ve previously recovered as much as 1.2 gigabytes from a Raspberry Pi that had gone through multiple update cycles and application changes.

When to Run These Commands

For optimal system maintenance, consider running these cleanup commands:

  1. After removing large applications
  2. Following significant system updates
  3. When you receive low disk space warnings
  4. As part of a regular monthly maintenance routine
  5. Before creating a backup or disk image

Additional Space-Saving Tips

Beyond these basic commands, here are some other ways to keep your Raspberry Pi’s storage optimised:

Clear Logs

Log files can accumulate over time. To safely truncate them:

sudo journalctl --vacuum-time=7d

This keeps only the last seven days of logs.

Check for Large Files

You can find unexpected space-hogging files with:

sudo find / -type f -size +100M

This will list all files larger than 100MB, helping you identify potential candidates for removal.

Minimise Installed Packages

Consider running a minimal installation if your Raspberry Pi is dedicated to a specific task. Many Raspberry Pi OS installations include software you might not need.

Conclusion

Regular maintenance using these simple commands can help ensure your Raspberry Pi runs efficiently within its storage constraints. This is particularly important for models with smaller SD cards or for projects that generate or download significant amounts of data.

By integrating these cleanup steps into your routine maintenance, you can avoid the frustration of running out of space unexpectedly and extend the useful life of your SD card by reducing unnecessary write cycles.

1 2 3 4›»