linux

tl;dr: The Orange Pi Plus offers much better specs, and much better performance, than a similarly-priced Raspberry Pi. Unfortunately—and this is the case with most RPi competitors at this time—setup, hardware support, and the smaller repository of documentation and community knowledge narrow this board's appeal to enthusiasts willing to debug annoying setup and configuration issues on their own.

A few months ago, I bought an Orange Pi Plus from AliExpress. It's a single-board Linux computer very similar to the Raspberry Pi, with a few key differences:

To use eMMC modules on the Orange Pi, Radxa, Milk-V, etc. as a writable volume in Linux, you need to delete the existing partitions (on my old Orange Pi, it was formatted as FAT/WIN32), create a new partition, format the partition, then mount it:

1. Delete the existing partitions, and create a new partition:
   1. sudo fdisk /dev/mmcblk1
   2. p to list all partitions, then d and a number, once for each of the existing partitions.
   3. n to create a new partition, then use all the defaults, then w to write the changes.
2. Format the partition: sudo mkfs.ext4 -L "emmc" /dev/mmcblk1p1
3. Create a mount point: sudo mkdir -p /mnt/emmc
4. Mount the disk: sudo mount /dev/mmcblk1p1 /mnt/emmc

Note your eMMC device may be a different ID, e.g. mmcblk2 or mmcblk0, depending on the order the board firmware loads multiple devices in. Check with lsblk to see which device you would like to modify.

When I'm developing using the Drupal Development VM, or checking into email processing on any of my servers, I usually use postfix to handle mail sending. Postfix is simple, preinstalled on most Linux distributions (and easy to set up if not), and is easy enough to use.

Here are the most common commands I use when either developing or troubleshooting email in production:

• mailq - print a list of all queued mail
• postcat -vq [message-id] - print a particular message, by ID (you can see the ID along in mailq's output)
• postqueue -f - process the queued mail immediately
• postsuper -d ALL - delete ALL queued mail (use with caution—but handy if you have a mail send going awry!)

There are many other helpful commands and scripts to help deal with mail (e.g. deleting all messages to a certain domain, or deleting specific message IDs easily), but these are the main ones I use during day-to-day development and troubleshooting.

When I set up new servers, I like to make sure any system messages like cron failures, server issues, or emails that are routed to [email protected] (where 'example.com' is the hostname of the server—meaning emails to that domain will get routed through the server itself and not hit an external MX server unless postfix/sendmail is configured correctly) are sent to my own email address.

It's relatively straightforward to route emails to internal users (like webmaster, root, etc.) to an external email address; you simply need to edit the /etc/aliases file, adding a rule like the one below, then run the command sudo newaliases:

By default, most internal users are routed to root as well (including webmaster), so setting an external email address (or a list of addresses, separated by comma) for the root account will allow you to more easily see what's happening on your server. Don't forget to run sudo newaliases to pick up the changes!

One one small LEMP VPS I manage, I noticed munin graphs that showed anywhere between 5-50 MB/second of disk IO. Since the VM has an SSD instead of traditional spinning hard drive, performance wasn't too bad, but all that disk I/O definitely slowed things down.

I wanted to figure out what was the source of all the disk I/O, so I used the following techniques to narrow down the culprit (spoilers: it was MySQL, which was using some swap space because it was tuned to use a little too much memory).

iotop

First up was iotop, a handy top-like utility for monitoring disk IO in real-time. Install it via yum or apt, then run it with the command sudo iotop -ao to see an aggregated summary of disk IO over the course of the utility's run. I let it sit for a few minutes, then checked back in to find:

On one server, where I have a custom directory where all the Apache (httpd) error and access logs are written, one set per virtualhost, I noticed the folder had grown to multiple gigabytes in size (found using du -h --max-depth=1)—in this situation, there's a handy utility on pretty much every Linux/UNIX system called logrotate that is made to help ensure log files don't grow too large. It periodically copies and optionally compresses the log files and deletes old logs, daily, monthly, or on other schedules.

For this server, to quickly fix the problem of growing-too-large log files, I added a file 'httpd-custom' at /etc/logrotate.d/httpd-custom, with the following contents:

Some notes:

I've been working on figuring out some interesting ways to use my revision A Raspberry Pi, and one of the things I'm doing with it requires it to work correctly behind a corporate proxy server. If you're in a similar situation, and need your Pi to work with a proxy server, it's simple to get set up:

You need to edit the ~/.profile file (where ~ is your home folder, e.g. /home/jeffgeerling, adding the following lines to the bottom of the file:

If you'd also like the proxy to apply when running sudo commands and when using your Pi as the root user, you need to add the same configuration to /root/.profile (this would be helpful if you need to use sudo apt-get to install or update software packages).

Nowadays, most people assume that all modern computers and operating systems have network time synchronization set up properly and switched on by default. However, this is not the case with many Linux servers—especially if you didn't install Linux and configure it yourself (as would be the case with most cloud-based OS images like those used to generate new servers on Linode).

After setting up a new server on Linode or some other Linux VPS or dedicated server provider, you should always do the following to make sure the server's timezone and date and time synchronization are configured and working correctly:

I've seen a ton of iptables configurations on the Internet, and none of them really got to the heart of what I need to do for the majority of my LAMP-based web servers (hosted on Linode, HostGator, Hot Drupal, and elsewhere). For these servers, I just need a really simple set of rules that restricts all incoming traffic except for web (port 80/443 for http/https traffic), ssh (usually port 22), smtp (port 25), and icmp ping requests.

The script below (save it as 'firewall.bash', chmod u+x it to make it executable, and run it with $ sudo /path/to/firewall.bash, then test your server (access websites, log on to it from another Terminal session, ping it, etc., and make sure that's all working)):