Tag Archives: apache

General, Technical

WordPress File Permissions: Always Check and Reset

You’d think after over a decade of troubleshooting WordPress permission issues that I’d have learned my lesson by now.

I’ve been diagnosing site performance issues with my garden blog (the Site Health tool was complaining). One of the issues that constantly kept coming up was a REST API error that reported cURL timeout issues. This usually manifested itself in agonizingly slow page load times. I went through the plugin/theme deactivation dance to hone in on the culprit: Fast Secure plugins that had been defunct for several years but still useful for buffering brute force attempts. I finally decided to move on to a different ReCaptcha solution and retire Fast Secure. Oddly enough, my primary site had the identical plugins installed but never encountered the same issues.

Moving on, I noticed that the Media Library thumbnails never displayed and that I had issues uploading/adding new media (cannot create directory). Now ordinarily my main media storage is in an S3 bucket, but I sometimes might need to make local posts unique to the garden theme of the site.

I spent hours and days researching this issue, thinking it had to be some kind of ownership issue. I kept flipping user and group ownership on files and directories, only to break ownership of other WordPress files and directories. I poured over logs looking for some indication of access errors.

Ultimately, I just had to reset all the file and directory permissions in my WordPress wp-content folder to get things working again:

$sudo find /path/to/website/wp-content -type f -exec chmod 644 {} \;
$sudo find /path/to/website/wp-content -type d -exec chmod 755 {} \;

Then I reset ownership of wp-content to my wp-user:

$sudo chown wp-user:wp-user -R wp-content/

Then finally, to make sure media uploads and thumbnails worked again:

$sudo chown www-data:www-data -R wp-content/uploads/

Of course while I was resetting file/directory permissions, it was worth reading the updated Permissions topic over at WordPress codex. Turns out I could have a functional site even with wp-config.php set to 440/400.

Last issue that drove me a little crazy. View Details on the Plugin page always resulted in an error: refused to connect. I was so sure that my restrictive firewall settings needed to open an IP block to the WordPress plugin repository. But it turned out to be an SSL issue. Because the details page was in an iFrame, an SSL setting needed to be set to permit this. In my case, I change this setting in the appropriate ssl parameter .conf file:

Header always set X-Frame-Options sameorigin

Then restarted Apache for settings to take effect. Now…does this toggling the option make my site less secure? I’m assuming that if the request came directly from localhost that the traffic should be permitted. I just have to ensure my servers are sufficiently secure against being hacked, a lesson I learned earlier this year, and a story for another day.

Technical

Automation challenges: troubleshooting and fixing my own problems with a paid WP plugin

Published content has been sparse lately due to an issue I faced with a premium plugin that assisted automating feeds to multiple social networking platforms, aka NextScripts Social Network Auto Poster. The issue came to my attention in late October, early November, when I resumed tinkering around with my main (source) site. WordPress, of course, had released upgrades since I last posted in September, which also prompted a slew of plugin updates. Bizarrely, only self-hosted WP cross-posting was affected; other networks such as Instagram, Blogger/Google, and WordPress.com were not experiencing the issue. Thinking the plugin might be at fault (specifically the WP code/api), I opened a ticket at NextScripts for support on November 1.

Well, it’s 6 weeks later and NOT A SINGLE RESPONSE FROM DEV about my still-open ticket. The only feedback I had was from a forum participant who suggested my SNAP woes (parse error not well formed) were due to an encoding issue. A few Google searches seemed to agree with this diagnosis.

So I checked and cleaned up databases at my source and target self-hosted WP sites–it was remotely possible that interim WP updates might have “corrupted” my databases. But quick peeks under the db hoods seem to suggest nothing fishy with the collation or character sets–and I had seen no evidence of junk characters appearing in my blog. Just to be certain, I exported all my data, recreated databases and users anew, deleted stale data leftover from bygone plugins and past WP iterations, and uploaded data into the new tables. To no avail!

I implemented WP hardening, thanks to a bit of paranoia that suggested a compromised install. To make sure that my WP install wasn’t corrupted, hacked or even hijacked, I checked file permissions on the source host, downloaded fresh copies of WordPress core, and uploaded them to the host. I ran Wordfence security scans to ensure I wasn’t missing an errant bit of code or a hole I missed. I looked over every line in wp_config.php to make sure the options were correct and even enabled/disabled WP debugging to see if I could find the issue. I changed my WP passwords to ensure that non-alphanumerics weren’t the cause of the problem. And just to test my PHP coding knowledge, I started looking over the WP code for XMLRPC until I went bleary eyed with all lines I had to sift through. I went so far as to sign up for WordPress beta testing in case some outdated WP code might not be passing muster with the host configs. No dice!

At this point, I concluded that it wasn’t the things I had complete control over that were the source of the problems. With plugin help visibly MIA/unavailable, it was time to investigate the hosted environments. What was so different with my self-hosted servers from the WordPress.com sites? Shared web hosting plans can be notoriously unreliable depending on the nature of your website, even if they aggressively advertise how “WordPress-friendly” they are. Usage limits, content restrictions, and hosting configurations can confound even the most basic vanilla WP installs.

While Google-shooting my plugin issue, I found similar complaints with the Jetpack plugin and other remote publishing apps, so I followed the technical support proffered for the competing product. Varnish Cache issues? Varnish validation seem to suggest otherwise. Problem .htaccess permission issues? Generated a new file, remarked out unneeded lines. PHP versions and missing libraries? Tried all the different flavors and checked configuration pages to make sure the appropriate extensions were loaded. Ran some cURL tests to validate this as well.

A noticeable difference among the hosts I worked on to serve my sites were in the database and web hosting software used. Some deployed Apache/MySQL in a traditional LAMP (Linux-Apache-MySQL-PHP) stack. Some hosts used Nginx, some used MariaDB. After researching MariaDB and confirming that hosts were using the latest stable build, I decided that the Apache/Nginx difference was key in trying to work around the issue. This explained why some .htaccess rules were being honored like the snippets below.

# Disable modsecurity filter for xmlrpc
<Files xmlrpc.php>
SecFilterInheritance Off
</Files>

<FilesMatch "xmlrpc\.php$">
Satisfy Any
#Allow from yourdomain.com
#Allow from yourdomainip
Require host yourdomain.com
Require ip yourdomainip
#Deny from all
</FilesMatch>

Nginx doesn’t allow user-level control in an .htaccess file; server blocks are implemented in server-level configs. It seemed likely that the Nginx environment was set up to block XMLRPC calls, and if Varnish/Nginx were conspiring in tandem, then there was no way I could implement a fix myself. My only recourse to solve the issue was to move my sites off the Nginx hosts. Once that happened, automation started working again.

What was most frustrating about all this is the utter lack of feedback from the plugin developer. There was nothing in the online FAQs that helped me research this problem, no activity on the ticket I raised, and zero leads in the plugin community. Even a reply as simple as “check your host” or “will get back to you” would have been appreciated, though not necessarily the premium support one would expect after weeks of no comment. A premium plugin would not be a good investment if my site had more than one user or more bandwidth to support (but silly me, I paid for the thing anyway). I wouldn’t recommend business-critical or high-traffic sites subscribing to this plugin unless it’s tested to work in their hosted environment. Of course, you get what you pay for in some hosting environments, particularly shared or free ones.

Technical

Free hosting: a quick look at x10Hosting

Free webhosting: sounds gimmicky and risky, right? Deliberately concocted to dupe and ensnare the miserly and unwary? Nearly a decade ago while I shopped for hosting companies to serve small business websites, I would have definitely scoffed at the notion of free hosting; I mean it was a scam, am I right? But in today’s ever-changing competitive hosting market, it’s considered savvy marketing and standard practice. For companies offering free hosting (like free domains were a scant few years ago), the service represents the proverbial foot in the door, a chance to pry open the wallets of potential customers.

Because moving out to a rural suburb forced a downgrade in my internet access speeds, self-hosting became problematic. Reliability of my home connection was a constant concern, and the blogging itch became too incessant to put off for much longer while I played in a Linux and Webmin/Virtualmin sandbox.

So as a consumer, I had already ticked off some boxes as to my needs since I already had my website backed up in cPanel, MySQL and WP exports. I was also bringing my own domain (registered at Sitelutions), and I had plenty of experience in web server administration and web design that didn’t require a 1-click solution.

Primary traits to determine my ideal hosting company were: Linux/Apache environment, cPanel administration, storage space and FTP access, PHP/MySQL for WordPress installs, forced ads, server location, and to a lesser degree, CPU/bandwidth limits and support options.

x10hostingEnter x10Hosting. For photo-heavy blogs, storage space is critical. A full backup of epicureasian.com and its garden subdomain weighs in the vicinity of 2GB, a size that most free hosts do not accommodate. Storage space isn’t front page marketing for x10Hosting; I had to sift through their site and community forum for the actual storage limits. Third party reviews of x10Hosting indicated unlimited storage, but x10Hosting restricts individual file sizes and the types of files stored on their servers per their TOS.  Unmetered disk space must also be requested after certain benchmarks have been surpassed.

After hurdling over some of the barriers of accessing the account (namely getting my account suspended after inactivity, initial storage being capped at 512MB), my experience in setting up a website and administering it was relatively painless and trouble-free. A solid and responsive community forum was key to my selecting x10Hosting for my website’s current home. The ability to switch cPanel themes from x10-branded to the original cPanel 11 skin made the migration seamless. English-speaking support, live status reporting, and a server located in the US (apparently in Tilton, NH) also relieved my anxieties over dealing with international hosting.

If I had a few quibbles with x10Hosting, I would have to argue that the 30-day login requirement is my biggest one. But self-hosting always ingrained in me the habit of checking my admin panel regularly. Another complaint would be the stale information about upgrades posted on their site. My positive experience with the free hosting so far encouraged me to commit to and pay for upgraded support, but it seems x10Hosting disabled this portal to reorganize and relaunch their offerings at a later date. PHP and MySQL limits also may put the brakes on any development work I might want to dabble in, since that might exceed x10Hosting’s restrictions. And caps on email, ftp, and domain accounts, though reasonable, seem lower than some of the competition. With no uptime guarantees and no automatic backups, it’s always a risk that I will lose access to my current content if I’m not vigilant with monitoring. But at this price point, my experience with  x10Hosting’s free product trumps my previous relationships with shared hosting services.

After setting up my account in December 2015, I am pleased to report that my site runs has run without disruption or performance issues so far, and therefore I recommend x10Hosting to anybody looking for an entry point into free webhosting.

Technical

WP auto upgrade/plugin updates, file owners and CHOWN

This has been a vexing activity lately: attempting to perform WP auto-updates and plugin updates on multiple WP installations end in failure. I thought the problem simply came down to deleting or chmodding 777 the offending directories (such as upgrades and/or uploads). When that turned out to be an unwieldy and insecure proposition, I turned to what I suspected might be an FTP issue, by switching to ProFTP server. Still unsuccessful, I suspected an SSH issue–no dice. A file system method switch in wp-config for WP? Nope, not that either. Trying to install suExec for PHP? It was already enabled, and forcing a recompile nearly crashed my server.

In the end, what gave me a clue was the section on file permissions in the WP codex and some forum posts suggesting ownership changes. A handy phpinfo-type script such as <--!? php echo(exec("whoami")); --> dropped in the appropriate directories aided in identifying ownership of certain folders.

It turns out that since I’ve been using FileZilla SFTP with root (yes, I know it’s highly insecure) credentials, I’d been carelessly uploading WordPress folders and plugins with root ownership, causing havoc with the auto-update system. Since the affected folders weren’t owned by the user, the user could not use their own ftp credentials to update their WP installations. I would either see error messages such as not being able to download files to the upgrades folder or unable to create plugin directories–all because the user did not own those folders.

Unfortunately, FileZilla doesn’t have a mechanism to check ownership. It only permitted chmodding file permissions, as far as I could tell. This of course created even more of a mess because I was chmodding under root, not user.

I used shell access (e.g. PuTTy) to identify ownership. To list folders and file ownership in a directory:

ls -l folderpath

To change ownership of a folderpath:

chown -R username:usergroup folderpath

where -R applies changes recursively. For my dedicated server setup, username and usergroup happened to be the same (I did not set up user groups in Apache). In this instance, folderpath referred to the root directory where WordPress was installed. Incidentally, changing the ownership of the folders reset all of the directory permissions to 755, and file permissions to 644–exactly how I wanted them.

This may have also corrected my issue with PHP sessions (still testing) with Captcha logins and form submission. I enabled PHP sessions and restored directory permissions on the working Captcha folders to 755. Will continue to test this.

Also, be wary of changing ownership on public_html. One of my sites had user:user ownership on the folder, causing the website to be inaccessible. Chown-ing the public_html back to user:nobody fixed the issue.