Tag: administration

Marrying Multisite
While there’s really no practical difference, server usage wise, between 100 separate sites and a multisite with 100 sites, a lot of us prefer to use Multisite for a variety of reasons. And today, assuming you have thought long and hard about those reasons, let’s talk about how to take 100 sites and fold them into one multisite. And yes, this will suck. If you read about how to break up a multisite, you may already have an inkling of the pain you’re about to embark on.

Make A Temporary Site

The first thing that makes it hard is that you have to keep your existing site up and running while you import it, no matter how you chose to import. So regardless of if you’re moving subdomains or subfolders, you need to make a temporary site. I like to keep the site names similar, and the same length because it’s easier for me. So if I’m moving a site with the slug ‘donnanoble’ then I’m going to make the new site on my network named ‘donnanobl1‘

There’s a practical reason for this. When I’m all done with everything, I can do a search/replace with any tool to change it back to ‘donnanoble’ and I don’t have to use a tool like the interconnectit Search/Replace DB script that has serialization safe super powers. If you use WP-CLI, the built in wp search-replace tool has this already, and I’d be using that personally. The point is that you will be renaming everything at the end to the original name eventually.

Bring in the Content

I personally do this via the WordPress Import/Export feature.

Now look, I know you can port over the tables and rename them but … I wouldn’t. Why? The users. The tables for the users have to be pulled over with the right user meta, and you would have to marry the wp_users and wp_usermeta tables in a way that no user ID was duplicated. Frankly, I don’t think it’s really possible to do that well. If I had to, I would actually manually create the new users on my Multisite and make a note of that new ID. Oh and of course the user names can’t both be admin. You can’t have two Doctors at once. Well. You can. And I’m sure they all use the same username, but you’re using WordPress and not a TARDIS, so if two users have the same username, then either they’re going to be the same user or you’re going to have to make one a new account.

There are number of you thinking about how many people use ‘admin’ as their username, and yes, that’s exactly what I’m talking about. But if we’re lucky and doctor11 and doctor10 used different login IDs on their sites, then you’re just going to need to copy over the one line in wp_users for that:

See how he has an ID of 10? That has to match all of these:

They don’t match right now, do they? Nope. The Doctor has an ID of 10, but the snippet I took from his site was for a user ID of 2, so I have to edit everything in wp_usermeta. Next, I have to rename my tables for wp_posts, wp_postmeta, etc etc over to wp_x_posts and so on, to make them match the new site ID. Oh and don’t forget wp_user_roles! You have to fix that for your new site ID too! And then reattribute all your posts!

You see this slope and how it’s getting really slippery really fast? That’s why I won’t do it. It’s certainly possible, but it’s neither simple nor easy nor safe. Importing and exporting via WP’s built in tools has only two downsides as I see it:
1. Your users have to make new passwords
2. You have to reconfigure your theme and plugin settings
That first one doesn’t bother me. The second one doesn’t either, since not all the plugins and themes work the same way on Multisite, so I probably want to take the time to do it all cleanly anyway. That does mean that I can’t automate things, but at the same time, I’m not particularly sure I want to. Taking each site one at a time will take longer, but it will let me be careful and test everything every step of the way.

Either way, once you have the site content in place, and your site settings look and feel how you want them to, it’s time to do a flip.

Flip The Sites

Take your original site, donnanoble, and rename it. If it’s a subdomain, turn off whatever weirdness you did in your panel to map the subdomain. For most types of server panels, having both named subdomains and a wildcard can live happily together, because the ‘real’ subdomain will supersede the wildcard. If not, you’ll need to change that subdomain to point to the location of your main install of WordPress. So if you’re in /public_html/donnanoble/ then that becomes /public_html/ on it’s own.

Either way, you have this real folder on your server called donnanoble and that needs to be renamed to anything else. At this point, I tend to use donnanoble-disabled because it is. Also it’s not supposed to work anymore.

Once you’ve broken donnanoble, it’s time to go into your network admin, go to the sites page, and edit the donnanobl1 site. Rename that to donnanoble, and check the box to change both home and site URL. Oh, and remember I mentioned search and replace before? Run that now. Change donnanobl1 to donnanoble all over the whole database.

I told you it wasn’t super easy

If you’re like me, you now have a bit of a headache, thinking about doing this 100 times. It’s one of those things that should conceivably be easier than it is, but right now WordPress really only has a way to export content and not settings (which is pretty much why we have such nightmares segregating content and code).

It may be plausible to use tools like BackupBuddy to import, but you still will find yourself at a tense moment when you have to flip the real and temporary sites around.
29 August, 2014
Mailbag: I Don’t Woo, But I Do CPT
A preface to this, I don’t actually use WooCommerce so I can’t give anyone a specific answer to that, but Geovanni asks:

Im in a pinch. I have a woocommercesite and i want to make a part where i can have users who already registered can have their your own URL and page where they can make post. I read a post u made on http://wordpress.org/support/topic/allow-users-to-post-events-on-their-own-page?replies=6 ,but u didnt say anything about how u got it to work or if u have. Can you help me?

This was a post from two years ago, where someone asked the following:

I’m working on a WordPress site that will allow artists to post their own events. I can’t find a plugin that will allow these posts to link up to their own pages. Each user that registers has their own URL and this page has all of their information. I’m trying to make sure that the tour dates posted aren’t ending up on every users page!!

Any help would be greatly appreciated!

I suggested that one could accomplish this with Custom Post Types, which was a theoretical remark, since I didn’t have the details, but when the OP later said “I need everyone to be able to create an event and post it on their own page…” I agreed it would probably be a better fit for Multisite, since they may have more than one of their own events.

So what did I mean about Custom Post Types? Well sometimes the answer is to think about the problem in different ways. Obviously the easiest thing in the world is to tell people ‘their’ page is http://example.com/author/name, and then have them post in a specific category (say… events). Thus all events are in an event group, and everyone has their own page. But I also know users can be a little confused by WordPress and categories, so you have some options here, when it comes to management.

First of all, there are plugins like Restrict Categories, which let you restrict users to a category. That works, but if you don’t want the URLs to have
```
/category/
```
in the slug for just that one thing, you really do need to look at Custom Post Types. That leads us down the road of things like AAM – Advanced Access Manager which will let you make a custom role for ‘Event Manager’ who can perhaps manage all events, and ‘Event Poster’ who can only post.

All this does highlight a flaw/annoyance in WordPress, and that is complex roles. WordPress’s role system is, at once, stupid simple and crazy complex. It’s a total headache to restrict people to specific areas, and in general, I hate having to do it because I find I spend more time messing with that than I do working on the site. At the same time, I dislike giving people more ‘power’ than they need. I can’t make a person a ‘comment moderator’ without giving them access to write/edit posts, for example, which is not a far-fetched wish. You can use plugins, like Disqus, to do that, but that means you’ve offloaded comments, and I don’t like that.

Of course… for the question posited by Geovanni the answer is “Use WordPress Multisite.” Install WordPress, activate Multisite, give the user a site, let them go to town.

That, of course, may not answer all his questions.
8 August, 2014
Home Affects Your Website
There’s a vulnerability with an old version of MailPoet, which according to Sucuri, is the reason for the breaking of ‘thousands’ of WordPress sites. I do not doubt their claim, nor the validity of the statement, but I did wince mightily at their wording.

At the time of the post, the root cause of the malware injections was a bit of a mystery. After a frantic 72 hours, we are confirming that the attack vector for these compromises is the MailPoet vulnerability. To be clear, the MailPoet vulnerability is the entry point, it doesn’t mean your website has to have it enabled or that you have it on the website; if it resides on the server, in a neighboring website, it can still affect your website.

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account (cross-contamination still matters).

I bolded the important part here.

I disagree with the broad, sweeping, implication that statement makes. While they do mitigate that with the next paragraph (and yes, you should read the links), it gives a bad impression as to what the issue really is there. If the vulnerable code resides on your server, under your user account, in a web-accessible directory, then yes, it can affect your website. However for any decent webhost, your site being vulnerable will not result in my domain being hacked.

Good hosts don’t permit users to access each other’s files. I know it’s semantics, but the implication is that a stranger’s website on your server will make you vulnerable. And that’s just not a given. I know that explaining the nature of relationships between user accounts and access is fraught with complexity, but this is a place where I look at security sites and bang my head on the table because they’re not educating people.

The way security works for most people is entirely an FUD scenario. They fear what they don’t understand, which generates more uncertainty and doubt. I spent time recently trying to break down that wall and talk about the behaviors in us that make things risky, and I’ll be speaking at WordCamp LA about it in September of this year. I understand totally why Sucuri, and many other people, phrase it this way, but since I firmly believe that education is the only true way to mitigate hacked sites, I want to explain the relationship of files to people.

If you’ve ever FTPd or SSHd into your website, you know you have a user ID. That ID owns the files on your server, but it’s not the only account on a server. Your ID is yours and yours alone. You can give someone else the password, but please don’t unless you trust them with your car. Once you’re logged in with your account, everything you see is connected. This means if you can see it, then anyone else who gets into your account can see it.

How does WordPress play into this? Well if you can see it logged in, then so can WordPress, to an extent. If a plugin or a theme has a specific kind of vulnerability, then it can be used to extract information like everything under that user account. A pretty common vulnerability I see is where the plugin allows you to read any file on the system, including the wp-config.php file, which gives people your database username and password (and it’s why I tell people to change all their passwords).

A very common thing for people to do, and I do this myself, is to run multiple domains under one user account. Many times they’re called ‘add on’ domains. In this case, you can actually visit https://ipstenu.org/helf.us/ and see the same site as you would at https://helf.us. This is problem fairly easily fixed with .htaccess (though if, like me, you also have mapped domains, it gets much messier):
```
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?example.com$ [NC]
RewriteCond %{REQUEST_URI} ^/addon1/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/addonN/(.*)$
RewriteRule ^(.*)$ - [L,R=404]
```
All that said, if someone knows that helf.us and ipstenu.org are on the same server, and the software I use on one is vulnerable, it can be shockingly trivial to infect the other.

What is not trivial would be using an exploit on ipstenu.org to hack ipstenu.com. Yes, it redirects you to ipstenu.org, but it is a real website. The reason I would be shocked to find it infected, if ipstenu.org was, is that they’re under separate user accounts. If you logged in with the ipstenuorg ID, you would not, could not, see ipstenucom.
```
ipstenuorg@ipstenu.org [/home]# ls -lah
/bin/ls: cannot open directory .: Permission denied
```
And even if they knew there was a folder called ipstenucom, the couldn’t do anything about it except get in:
```
ipstenuorg@ipstenu.org [/home]# cd ipstenu.com
ipstenuorg@ipstenu.org [/home/ipstenu.com]# ls -lah
/bin/ls: cannot open directory .: Permission denied
ipstenuorg@ipstenu.org [/home/ipstenu.com]# cd public_html
-bash: cd: public_html: Permission denied
```
The separation of the users is going to protect me.

So to reiterate, if a site (or the account that owns a site) has access to other sites, and is hacked, yes, those other sites are at high risk. If the site has no access to anything but itself, they will not be hacked. And as I said before, most hosts go to tremendous lengths to ensure you cannot read someone else’s files or folders. The whole reason I can get into the ipstenucom is that the permissions on that folder allow it. Would it be safer to prevent it? Sure! And actually that’s not what you normally see when you’re on my servers.
```
ipstenuorg@ipstenu.org [~]# cd ../
ipstenuorg@ipstenu.org [/home]# ls -lah
total 12K
drwx--x--x 37 ipstenuorg ipstenuorg 4.0K Jul 23 02:04 ipstenu.org/
ipstenuorg@ipstenu.org [/home]# cd ipstenu.com
-jailshell: cd: ipstenu.com: No such file or directory
```
That’s right, I use jailed shell to prevent shenanigans, and even when I don’t, things are remarkably safe because I don’t permit users to snoop on other users. That said, as I was reminded we must never underestimate the ability of a fool, playing at sys admin work, to take their own pants down. It’s possible for a user to set up their own domain to be searchable by other accounts on the server, and to make it writable to those other users, which can cause a lot of problems.

Here’s your takeaway. Everything that is installed on your domain, active or not, is a potential vulnerability. Upgrade everything as soon as you can, delete anything you’re not using, don’t give more people the keys to the castle than you have to, and try really, really hard to think about what you’re doing.
28 July, 2014
La Vitesse 2: Cruise Control

Now you know all about caching and how it works. But what about speeding up the server itself?

Near the end of the previous post, I mentioned that all the caching in the world didn’t really speed up the server. This is somewhat of a lie, since if, say, you’re using Varnish to cache your site, then your visitors won’t be hitting your WordPress install, speeding it up for you to do work. But it’s not the full picture.

WordPress is big and it’s getting bigger and more complex and more impressive. So is Drupal and … well pretty much everything else. In order to make your site do more, like all that super fancy layout transformations, we have to upgrade and innovate. But then you start getting into extending these apps, like using custom fields and extra meta values to store more information so you can change search results in more impressive ways! Your site scrolls and changes backgrounds! Your site dynamically changes what products are available based on check boxes, without reloading!

What did that have to do with caching? Well … how do you cache things that aren’t static?

My coworker, Mike, likes to talk about things that should be cached and things that should never be cached. Things that have to be dynamic and run without a page refresh, like ajax and javascript, can be cached to an extent, since those plugins and Varnish will just keep the code in-line, which means it’ll still run. But when you start looking at dynamic things like shopping carts, we hit a new world and a new wall. But I’m not even talking about that level of caching. I’m talking about going back a layer into the part where WordPress (or any app) has PHP query the database. If we speed that up, caching safe content, can’t we speed things up? You bet we can!

A few years ago I talked about APC and how I was using it to speed up PHP by having it cache things. Then less than a year later, I switched to Zend and memcached. I did those things because I decided that it would be better to have my server, a workhorse, do the hard work instead of asking WordPress to do it. And this was, in general, a pretty good idea.

Memcached is an add-on for your server, and acts as “an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.” In English? It remembers what you did and can retrieve results faster because of it. Of course, you have to tell your apps to play well with it, but once you do, the backend of your site starts to speed up because, hey, caching! The Illustrated Memcache’d story is kind of an awesome explanation (the images on the archive page are broken, but the links work). And yes, I do use memcached and ZendOptomizer+ on my server, because it really does make things faster, even when two of the ten domains are having a 10k pageviews in a day.

I keep telling everyone my server isn’t overkill….

The point of that, though is the other end of speed is totally separate from your application code. When you install WordPress, you know it runs SQL and PHP, so if you can make those faster, WordPress will be faster. The same applies to speeding up Apache, maybe by putting Nginx in front of it, or maybe by tuning the hard to understand settings in httpd.conf to make sure that it elegantly handles the 300 people who come running to your site at once.

But unlike plugins, this aspect of server speed is the hard stuff. When you look at WP Super Cache, you think it’s complicated until you see W3 Total Cache. Both are amazing and awesome, but they’re giving you a ton of options and asking you to make decisions. The same is true of the servers, but now you have even more options. The world is your oyster, and we haven’t even looked at hardware.

For me, it boils down to how can I make my server do it’s job fast and efficiently. If that means I hire someone to install software to cache better, or I pay for more memory, then that’s what I do. I also trim the fat and get ride of everything I’m not using and don’t need, so my server doesn’t have to do more than it needs to. And one day, one day, I’ll be looking at nginx for everything.

23 July, 2014
Diving Into Varnish
We use it at DreamPress a lot, and I’m still learning its ways, but with me, the best way to learn a thing is to do a thing. So when I had a random server crash with nginxcp, I decided to play around and see about using Varnish on my server instead.

Varnish is an HTTP accelerator designed for content-heavy dynamic web sites (like WordPress). Unlike nginx, there’s no support for SPDY or SSL, which I can’t use anyway unless I spring for another server in front of my Apache box to be a true nginx box. Since I wasn’t getting any benefits out of nginx for those, I’m not too worried about it here yet. Should the world go to SSL, then my POV will change. The Varnish gurus aren’t fans of SPDY as it happens, which I find fascinating.

Back on point. I’m going to use Varnish as a proxy, which means when someone comes to my server to ask for a file, Varnish will first check itself for a cache and then if it’s found, serve it without touching Apache. Apache is slow. This is good! While nginx can handle static files rather well, I found that where I ht slowness people told me to use a CDN. That’s nice, but I don’t want to right now, so it makes nginx less of a draw. On the other hand, Varnish will fill in the gap where Apache + mod_php == poor static-file performance. And yes, I’m using mod_php.

Installing Varnish

First change Apache non-SSL port to 8080. I’m on WHM for this particular box, so I go to WHM -> Server Configurarion -> Tweak Settings and set value of field Apache non-SSL IP/port to 8080

Next I install the Varnish RPM for RedHat REL6. This can be either Varnish 3x or 4x, but I picked the latest version.
```
rpm --nosignature -i https://repo.varnish-cache.org/redhat/varnish-4.0.el6.rpm
yum install varnish
```
Edit the config file – /etc/sysconfig/varnish – and set the VARNISH_LISTEN_PORT to 80.

Now we edit /etc/varnish/default.vcl with what we want.

Deep breath. A whole heckuvalot changed from 3.x to 4.x and it took me a couple hours to bang out, since my examples were all from Varnish 3.x. In the end, I made my own fork of DreamHost’s Varnish VCL. Grab my Varnish VCL Collection and I use the wordpress-example.vcl as my default. It’s a whole ‘nother post on how I did that one. A lot of trial and error.

The default VCL is skewed to WordPress in a specific way: If you’re logged in or have a cookie that isn’t the default WP cookie, or are on SSL, you do not get cached pages. This means my site will be slower for me.

Configuring Your CMS

Speaking of WordPress… Here’s the major difference between it an nginx: I need a plugin for WordPress. I took over Varnish HTTP Purge last year in order to fix it (instead of fork it) for DreamPress, and in doing so I’ve added a lot of little tweaks, like a ‘purge all’ feature and a button on the toolbar.

Oddly, this is the reason I didn’t want to use Varnish. Where nginx just works, needing a plugin means I have to either install and activate for everyone using WordPress or any other CMS on my system, or I have to figure out a way to not need a plugin? Oh, and I don’t just used WordPress. Ugh.

This is moderately trivial to do with Mediawiki but I came up full short when I looked at Zenphoto. While I don’t post often to it (once a week generally), I do post a lot of data and I need the purge to be done. Certainly I could code in a system for it, like I did with WordPress, using a CURL call.

But it’s the need to do that for Varnish that made me make faces.

Not using Varnish

At the end of the day, while I did get Varnish up and running, I chose not to use it. Yet. I have to overcome some hurdles with other apps not knowing how to play well with purging, and figure out how to command purges like I do with WordPress. You can see I have my work cut out for me porting a WordPress plugin to Zenphoto.

In addition, I’m not really sure I like the fact that I have to do that. Certainly I can just let the cache expire on it’s own, but that seems to somewhat defeat the purpose of having it be able to handle dynamism as well as it does if it can’t magically detect when my content changes, and the cache needs a bump.
14 July, 2014
Yum!
I’ve touched on it a couple times, and it’s related to why I love things like Homebrew, but I like package installers. While I can, and have many times, installed and packaged from source, it scares me and I don’t like it. When I talked about Homebrew, I mentioned in passing that I use yum to manage packages on my servers, and someone asked me “What’s that?”

When I started this blog in 2009, the very first post was about understanding how to mess with my VPS and tweak it to work well with WordPress and everything else. In the five years since, I’ve learned a great deal about servers, tweaks, how to break things, but also how to upgrade them smartly. I’ve had struggles with SVN and GIT, but I understand that managing versions and revisions is a sane way to handle upgrades. But at the same time, not compiling code means I have more free time to mess with the stuff I like.

This brings us to Yum.

Yum is a software package manager manager, which means it checks various RPM Package Managers, sees if there is software you have that has an update, and updates it. An RPM Package Manager (or an RPM, yes, it’s a recursive acronym, just like PHP) stores packaged versions of code… I have a feeling someone’s looking at me like I spoke a new language.

Let’s step back further. Your server is a computer and runs software. Most people have the experience of installing software via packaged installers (I used to make them for a living). When you download an app onto your phone, the phone downloads the package and runs the installer. This is similar to WordPress, right? You download the zip, unpack it, and run an installer. But your server, well, for a very long time people didn’t have installer packages, they had source code. The source code was downloaded, unzipped (hush, you know what I mean), compiled, and then installed.

Credit: xkcd comic “Compiling”

Yes, compiling code takes a long time. That joke is less funny than it is accurate to some of us. It’s not something most of us do any more, though, because code now tends to come pre-compiled, and that’s where package managers come into play. You see, someone realized that they could pre-compile code for all servers. It’s not the same code for all the servers, though, because there are so many flavors of servers, it’s mind boggling.

But that said, if you know your flavor of server, you can use an RPM that matches to install software. So the RPM is like a massive server that has all the available installs for your server. When you add in yum, which installs the packages, you can then enter a world of automation where every night your server checks for new packages and installs them!

Yum has a meaning. “Yellowdog Updater, Modified.” I didn’t say it was a good meaning. Yum has a bunch of obvious commands like “yum install NAME” and “yum update” which you can use to install extra add-ons like Memcached and so on. There are also yum utilities (yum-utils, which let you further customize automation by scripting commands.

Just to touch on one at random, today I got an email from my server saying that it had run /usr/bin/yum -c /etc/yum.conf -y update for me. This is normal, I configured it to do that at midnight every day.

There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.

Now it did run the rest of the installs, so I did what any smart person does. I went and looked up this new command, only to find a string of bug reports from 2007-2009. It’s 2014, so I went and ran it once. It cleaned up one package and said I had another 244 left. Interesting. I ran it again. 243. I saw my day flash before my eyes and then decided to run the safer version:
```
yum-complete-transaction --cleanup-only
```
Safer and faster. Everything was cleaned, and update runs great now.

Is there a risk with this automation? Of course! Which is why I take a backup every night, right before the update happens. I’m not crazy after all.
18 June, 2014