Reclaim Hosting‘s Ramones server was experiencing some extremely high loads this afternoon, and D’Arcy gave Tim and I a heads-up on Twitter to let us know as much. The A-Team was on the job, and more than up to the task! The first thing we check when we’re getting unusually high loads is the Apache Status in WHM (the GUI interface for managing a CPanel server). We look to see if there is one particular site getting hammered with requests—which is often, though not always, the case with random load spikes. In the instance earlier today, one WordPress blog was getting hit very hard with login attempts, often referred to as brute force login attempts. But rathe than the wp-login.php file, it was the xmlrpc.php file which has been a vulnerability for years because it provides, in the words of my server sensei Tim Owens, “a huge target for brute force login attempts because it bypasses the traditional wp-login.php and goes right for logging in via API.” This was precisely the case with the intense load on Ramones this afternoon.
Tim has started collecting snippets of code in our internal documentation, like the one below, that we can just add to the .htaccess file in the affected WordPress install to block all calls to xmlrpc.php. Below is the code snippet we copied into .htaccess this afternoon that brought the load back down almost immediately. Hope you find it helpful. Continue reading “XML-RPC Blocking using htaccess”
Anyway, the image above is a look at a potential setup for a large WordPress Multisite instance on AWS. It has a couple of elements worth discussing in some detail because I want to try and get my head around each of them. The first is a load balancer that runs in its own EC2 instance.
What the load balancer does is direct traffic to the Ec2 instance running the WordPress core files with the least load. So if you have four EC2 instances each running WordPress’s core files, the one with the least usage get the next request. Additionally, if all the instances have too great a load another could, theoretically, be spun up to meet the demand. That’s one of the core ideas behind elastic computing. The load balancer Tim used for UMW Blogs was HAProxy.
As mentioned above, you can setup a series of instances of EC2 on AWS with the core WordPress files save the wp-content directory, which is the only directory folks write to. But you will notice in the fourth instances Tim switched things up. He suggested here that we could have an EC2 instance running Docker that could then run several WordPress instances within it. What’s the difference? And this is where I am still struggling a bit, but from what I understand this allows you to spin up new instances quicker, isolate instances from each other for more security, and upgrade and switch out instances seamlessly. It effectively makes WordPress upgrades in a large environment trivial.
We have yet another EC2 instance that is the Network File Storage, this holds the wp-content files. The uploads, plugins, themes, upgrades, etc. And each of the above instances share this instance. The all write to this, but one of the issues here is that this can be a single point of failure, kinda like the load balancer. So, Tim suggested there is BitTorrent Sync (BTSync), which I still don’t totally understand but sounds awesome. It’s basically technology that synchs files from your computer to spot on the internet, or between spaces in the internet, etc. So, what if we had several bucket where the various instances of WordPress core files were writing the upload files, themes, plugins, etc, and those buckets used BTSync to share between them almost immediately. So then you wouldn’t have a single point of failure, you would have the various instances writing to various buckets of files that would be constantly synching using the technology behind BitTorrent. Far out, right?
Another option, and I think this was before we started talking about BTSync, but not sure if this would be in possible in addition to BTync, is have the blogs.dir folder for a WordPress Multisite that handle all the individual site files uploaded be sent to S3, Amazon’s file storage service.
You get the sense that part of what’s happening when you move an application like WordPress Multisite onto AWS, or some other cloud-based, virtualized server environment, is each element is abstracted out to it basic functions. Core files that are read-only are separate from anything that is written to, whether that be themes, plugins, or uploads. Additionally, the database is also abstracted out, and you can run an EC2 instance on AWS with Docker containers each running MySQL (with a sharDB or HyberDB to further break up load) that can also replicate various writes and calls using BTSync? No single point of failure, and you greatly reduce the load on a WPMS which is completely I’m out of my depth here, but if I I accomplished anything here it might be giving you an insight to my confusion, which is also my excitement about figuring out the possibilities.
I have no idea if this makes sense, and I would really love any feedback from anyone who knows what they are talking about because I’m admittedly writing this to try and understand it. Regardless, it was pretty awesome hearing Tim lay it out because it certainly provides a pretty impressive solution to running large, resource intensive WordPress Multisite instance.
The more I work with faculty and students on managing their own web hosting and domain, the more I am convinced it’s not only manageable for just about anyone, but it’s near on getting dead simple. This is by no means to suggest Christina isn’t tech savvy—quite the opposite! However, she’s represents a demographic of faculty who’ve been rocking open source applications like WordPress for teaching and leanring on amazing platforms like UBC Blogs or UMW Blogs for a while now. Given that, they’ve come to the point where they want to start managing some of their own sites, and exploring beyond the confines of these systems. That’s awesome because in my mind that’s why we started platforms like this in the first palce, so folks would start to move beyond them.
Nonethless, I emphasize some of her sites above because Christina is not planning on exporting and managing all of her numerous course sites on her own domain. Rather, she’s bringing in a few sites that make sense to be on her own domain: her blog, her portfolio site, her ds106 tumblr, etc. It’s not all or nothing, rather the two systems working brilliantly together, and the above video is a testament to how awesome open publishing platforms like UBC Blogs and UMW Blogs can be when faculty (or students, staff, etc.) can export their work from a university’s platform and seamlessly import that work into their own domain. THAT’S PROGRESS, KIDS!
In effect, by setting up her own WordPress multisite she is able to move from the concept of a site to that of a network of sites that she manages and controls. It’s weird for me, but I just really wrapped my head around this idea of the personal network while talking to Christina over the last couple of days. The WordPress Multisite network nomenclature gets at the idea that you, by way of your domain, become a multichanneled space for publishing, sharing, syndicating, aggregating, etc. As Andy Rush has noted before, a “Network of One’s Own!” And that’s exactly what Christina is demonstrating in this walk-through.
If you are interested in how to install your own WordPress Multisite (via Installatron, which you can get through Reclaim Hosting ), manage WordPress Multisite, export/import WP, oand/or use FeedWordPress this video might prove very useful. I am hoping Christina and I can get together again and do a few more about managing your own domain and demonstrating that managing your own oiece of a server has never been simpler!
This is part 3 of a series Howard Rheingold and I have been working on to demonstrate out the open how to create a learning environment using open source tools like WordPress, MediaWiki, and more. go here for all the videos so far. The idea behind this series is to get faculty and students interested in how they might fashion their own learning environments in a web hosting environment using their own domains. The first fifteen minutes of this video focuses on Howard’s approach to assessment in his Social Media Issues course, which will be experimenting with contract grading. From there we explored a few things in regards to the open source framework we are building.
Finding and installing WordPress themes
Integrating signins between WordPress and MediaWiki
Just how clunky MediaWiki still is after all these years
Customizing menus in WordPress
Uploading header images and changing the background color in WordPress Themes
The point about how clunky MediaWiki remaisn was the source of a broader mini-rant about how long we have been using these tools, but how difficult some absic things remains. Integrating signups between MediaWiki and WordPress is still a major pain in the ass six years on—the WPAUTH extension for MediaWiki that I’ve been using since 2007 remains the gold standard. Also, to change the logo in my MediaWiki install I need to FTP in and change code in localsettings.php file—WTF?!
I truly would like to see a robust platform like MediaWiki become a lot more ubiquitous in the teaching and learning space, but an application that makes simple administrative necessities that difficult will not be an options for your average user. Also, why haven’t we made some of this stuff easier? And this goes for syndication as well. My thoery is because we’ve wasted too much time chasing the next platform that will sovle our problems and finally truly disrupt education—in other words, most technologists are fools and zombies.
This is part two of a series Howard Rheingold and I are working on wherein we’re openly building the framework for his Social Media Issues course using a variety of open source tools, plugins, themes, extensions, etc. This is really a blast for me because I haven’t gotten into the nitty gritty of a one-off open source learning environment like this since 2007 or 2008 (although ds106 was exactly this in 2011, but I gotta a lot of help). I’m really loving the work with Howard to build out his course site, and once again explore for myself what’s possible with tools like WordPress and MediaWiki. In fact, the whole idea around ds106, Domain of One’s Own, Reclaim Hosting, etc., is that you dig into stuff like this and have a community of support to help you. A huge reason why folks wouldn’t even consider this option is that it’s way too onerous to do alone, but we may just solve that by working on this stuff as a community. Open and distributed edtech—you have a problem, we can help you fix it! We’re DEDtech! Anyway, that’s the dream.
As for this episode, Howard and I spent some time in the beginning on the WHYs. Why have your students blog openly? Why have them take control of their digital domain? Why build these aggregated spaces? What has been the biggest treat about pairing up with Howard is that he makes me explain some of the assumptions I’ve been carrying around for years. I’ve been pushing syndication of student blogs into course hubs at UMW for six or seven years now. We’ve been using the FeedWordPress plugin for five or six of them. This stuff is like water to us, and while others might be waking up to it recently—it’s been part of our edtech DNA at UMW for a while. So having Howard have me try and actually explain why a faculty member might want to do this is awesome. What’s more, as we go through these sessions it’s a real conversation between two people who are negotiating what the course framework might look like. The coolest part is we’re sharing it in hopes that others get some ideas, frame their own questions, and potentially work through a similar model. I feel like I am doing the best kind of instructional technology again: exploratory, customized frameworks that scale to the size of a single professor—a hub that reflects the personality of a course, but refuses to subsume the students within it. This is the kind of instructional technology that truly rocks—LMSs still suck!
After the WHYs, we covered a few customizations to his WordPress hub such as adding a widget for the Twitter conversation around his #comm182 course hashtag. Thanks to Tim Owens, I recommended the native widget from Twitter that actually works well. Just go to Your Twitter settings–>widgets and you have all sorts of options.
After that we discussed how to create custom menus in WordPress to organize pages on the course hub. What’s more, the links option in custom menus is a very useful feature that I think a ton of faculty will find appealing for loosely integrating a range of external sites into one central hub. We flirted with the idea of themes, but we’ll be spending more time in the next episode—which is Tuesday, August 20th btw—talking about the myriad possibilities in that department. About half way through we installed a MediaWiki and went over the affordances of that technology. I particularly liked our discussion about wikis because we actually went back-and-forth about what he may or may not need. I don’t recommend MediaWiki lightly because it can be a real pain in the ass, at the same time it is powerful and every time I set one up for a class I see the immense possibilities all over again. That said, when I soon realize I have to edit a localsettings.php file to get a attractive icon for branding a new wiki some of that luster is lost. Truly a love hate relationship.
I’ve demonstrated some basic editing for MediaWiki that we have document for the course here, and I am working on a broader HowTo wiki page for this class that I’m expecting other folks who want to do a course like this might use, copy, or customize for their own course. I’ll be talking about integrating WordPress and MediaWiki more tightly in the next episode, as well as the possibilities with plugins like Wiki Embed—which I think is awesome. I also found this cool MediaWiki extension I hadn’t seen before that enables seamless Poem formatting, which is a complete nightmare in WordPress. Who knew? I’ll highlight all these MediaWiki extensions, integration, and WordPress themes and more in the next episode. Until then, stay syndicated baby!