Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: servers

  • Reset the Net Gotchas

    Reset the Net Gotchas

    All my domains will not be HTTPS by the end of 2014.

    Sorry. It’s one of those things that just isn’t (at this time) something I can pull off. If I only had one domain and everything was subs, I could get one wildcard subdomain cert and be done with it. But with the number of domains I have it’s not feasible. Which brings me to what I think one of the major issues with our desire to protect the net is… But let’s step back!

    Yesterday, as you may have noticed, was Reset The Net day. It was a call to action, much like we did when we went dark one day.

    Now on this site, I’m using the Internet Cat Signal, which cleverly updates itself as I need to alert people to crap like this. The tldr is that the NSA is spying on us. I leave that plugin on all the time, it fires up when there’s something people need to know. It doesn’t slow down my site, and I hope it brings awareness to folks who otherwise have no idea about this stuff. About 75% of my traffic on this server can be described as people who don’t know about any of this.

    What have I done for this? The recommendations are to use HTTPS, HSTS, and PFS. Since HeartBleed, I enabled PFS. This is a non-logical sort of thing to do, in that few people seem to explain how to do it. On my box, which uses WHM, it was pretty easy. In my WHM Panel, I went to Apache Configuration -> Global Configuration -> SSL Cipher Suite. Then I picked the PCI Recommended suite, not the default, and rebuilt the configuration. Then I went to Apache Configuration -> Include Editor -> Pre Main Include and, for all builds of Apache, added this:

    # Enabling PFS
    SSLHonorCipherOrder On
    SSLProtocol All -SSLv2
    # CVE-2011-3389
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    

    The last bit lets me support any IE 6 users who visit my store. But as I said, I don’t have SSL on for all my domains. So what are my HTTPS issues?

    The cost is insane. Let’s look at wildcard ssl, which is what you want for *.example.com situations. It’s pretty much $100 a year. That’s not too bad until you factor in how many domains I have on this server. Six family members, six of my own sites (including short domains like helf.us). So that’s either $1200 a year, which is obscene, or $145 a year at the cheapest I could find, and that’s for the simple green lock and no wildcards. For the big green bar, it’s back to around $1000 a year. Oh and I forgot one of my domains, so that’s $164 and $1047. Now I could totally afford the $164 a year, it’s doable with my ad revenue (which pretty much breaks me even at the end of a year) but….

    It’s slower. Look, I get it how it’s important to be secure, but right now, the nginx proxy setup I’m using doesn’t work on HTTPS. That sets me back some since using it has sped up my site considerably. I know how to (and have) set Google Pagespeed to play nicely with HTTPS, so I’d be back to where I was before. This isn’t bad, it’s just not a great experience. Right now I have a secure login, secure email, a fully secure store, and ssh/sftp only, so the only place your data could get ‘sniped’ is when you’re leaving a public comment on my public site, which makes me less worried than I might be. Even my git repo is secured.

    Twig in a net

    Also it’s hard. And no, that’s not an excuse. PFS (Perfect Forward Secrecy) isn’t easy to add to your servers, and it’s way outside the realm of what most people can do. Hell, it’s outside the realm of what I’m comfortable doing. It took until my server had the specs for OpenSSL that will support PFS for me to do it. The point is, this part has to be done by the webhost for most people, and that is a big issue. It’s not easy or fast to upgrade servers, and it’s far, far more persnickety than updating WordPress. It’s complex, and you have to think about everyone on the server. Again, not an excuse, just a caution that it takes a while to finish up.

    Speaking of WordPress, multisite isn’t great at it. In fact, it’s less great than normal WP. I have two sites with SSL right now, ipstenu.org and store.halfelf.org. Ipstenu is only SSL on the back end, but even with that, there are inconsistencies. First, all the links are HTTPS, so when I click on “My Sites” the link to NON HTTPS sites are using HTTPS, which doesn’t work. Also if I made a new domain, it defaults to HTTP and not HTTPS. So I have to edit that manually. This is annoying, thought not insurmountable, and I know it’s something being worked on.

    In the end, the absolute biggest reason I’m not switching to HTTPS is that the only person who needs secure communication are the people logging in or the people buying things, and I’ve taken care of that. For the rest of you, know that my store is secure, my logins are secure, and if you’re commenting on the site, for god’s sack, don’t post anything you don’t want people to know!

    I’m sure in a few years if not months all this will change, but this is where I am today. The racket with SSL certs costing that much needs an easier solution, and then the rest will fall into place.

  • Nginx Proxy

    Nginx Proxy

    Will you all quit nagging me now? I kid. Very few of you actually got on my case about nginx.

    Nginx is a HTTP server and reverse proxy, which is a really fancy way of saying “It runs websites.” Most people still use Apache, and Nginx is perceived as being faster with how it serves static files. My issues with it are twofold:

    1. I don’t just run WordPress here
    2. I need my .htaccess for those other things

    Yes, there are older webapps that don’t support nginx. But at the same time, what if I could have my cake and eat it too? What if I could use nginx to serve up the static files and apache for the rest? That would mean I would be able to install nginx on my CentOS 6 box as a reverse proxy.

    It’s actually not that hard, but let me explain why this is a good idea. Apache takes up a lot of server memory, which nginx does not. Nginx is awesome at static files, but not the best at dynamic, and you’ll need a module like php-fpm for that. But… One of the sites on this server has a gallery that takes up 50% of the webspace of all accounts on the server. Stop and ponder that for a moment. While I do have server-side caching (memcached and ZendOptimizerPlus) running, adding in nginx up front means my images would be served faster.

    Speaking of faster, by putting nginx in front, it makes it so only true http requests get passed on, which protects against attacks like DDOS and other brute-force attacks that aren’t nginx-related. I still have (and use) mod security, of course, as well as ConfigServer Firewall. More on that later. Let’s get this sucker installed!

    yum install nginx
    

    Nginx Community (background image enhanced)Install Nginx

    Oh, sorry? Was that supposed to be harder? It’s not. This is pretty much the simple part.

    Install nginxCP

    Normally my next step would be to configure nginx (see Ben Tasker’s CentOS: Using NGinx to serve static files and Apache for dynamic for details) and apache. Unlike Ben, I have WHM on my server, which means when I build apache it’s with Easy Apache, which means any edits I make to my httpd.conf file get lost when I rebuild, which I do for when I need to upgrade PHP. It’s not super rare, nor is it super common. Still, I don’t really want to mess with it more than I have to.

    So I took the time to research my options, and came up with nginxCP and cpnginx. The real difference is CPNginx comes with a service to help you (yes, it’s pay). Since I’m an Open Source woman, I did nginxCP. The cost ($55 a year) for cpnginx was not a deal breaker, since they had a trial.

    The install directions are quick:

    cd /usr/local/src
    wget http://nginxcp.com/latest/nginxadmin.tar 
    tar xf nginxadmin.tar
    cd publicnginx
    ./nginxinstaller install 
    

    A reboot of the httpd service and now all my non-SLL sites are served up on nginx!

    Configure nginxCP and Apache

    I love when I can just slap it on and go, but I run ConfigServer Firewall to save my ass from DDoS, so I knew I’d be getting a slew of ‘Suspicious process’ alerts from my firewall once I added in a new feature. The fix is to add this to csf.pignore:

    # nginxCP
    exe:/usr/local/sbin/nginx
    

    That was all I needed! Emails, by the way, from CSF have plummeted. I was worried I wasn’t getting any emails or logs from my servers for a while. But then I re-checked my logs to see what was happening. See I used to get a lot of emails like this:

    Failures: 5 (mod_security)
    Interval: 300 seconds
    Blocked:  Permanent Block
    

    They stopped, because nginx didn’t let them get to Apache and CSF. Mind. Blown.

    Results?

    Some server stats, showing a 0.00 load average for 1minEverything worked out of the gate, so I sat and watched my server load. Per-expected, since an httpd restart flushes my PageSpeed cache, the load spiked at .52 (this is still low). Then it dropped to .31 and then to .20, and it pretty much stuck around the .10 area. Memory, however, dropped for a while. That’s good! Slowly as things settled in, I made sure to post something new on a news/fan site, and watched things not go up very much.

    Nothing is weirder than watching your load drop to 0. The 93% memory is not a bad thing. On this server setup, I want to see somewhere around that at any point in time. The first time I saw it, though, I flipped out and my friend Benny (who is a cPanel goddess) calmed me down and explained how the ‘storm’ server worked. Real memory usage is about 40%, when load is above .40.

    Graph of server load, showing a big spike and then settling down

    The big spike was installing. The normal spikes at 14:00 and 14:30 were posts made in WordPress before nginx was installed. The ones at 16:00 and just after 17:00 are WP posts as well. That’s a nice change.

    Problems?

    SSL. Wouldn’t you know? Now you can use nginx as an SSL revese proxy, but it would obviate my cpanel add in, which right now seems a little smarter for long term sustainability than doing it 100% manually. The less I have to remember when I’m rebuilding apache, after all, the better.

    Still. Part of why I’m looking at nginx seriously is to speed up my SSL site which gets less caching by it’s nature. Weighing the pros and cons, I decided to stick with nginxCP as my theory is that by speeding up the rest, SSL will in turn be faster since there’s less memory being sucked up. Oh and I did check cpnginx about SSL, and they don’t support it either. That’s alright for now. I’m sure the future will change.

  • Apache 2.4 Kiboshed SPDY

    Apache 2.4 Kiboshed SPDY

    I have a store running on SSL for security reasons. I mean, you kind of have to, right? The problem is you don’t really want to cache SSL pages, as I reminded myself lately. At best, I was able to work around PageSpeed’s idiosyncrasies and compress the HTML and JS somewhat, but still I know that there has to be a better way.

    Everyone told me to look at SPDY. Now… this came with some issues. I needed Apache 2.2.4 (I was on 2.2.2):

    	httpd >= 2.2.4 is needed by mod-spdy-beta-0.9.4.1-397.x86_64
    	mod_ssl >= 2.2 is needed by mod-spdy-beta-0.9.4.1-397.x86_64
    

    race car driving very fastWhat’s an elf to do? Well… what about Apache 2.4? After all, it’s the latest and greatest. This is when my eyebrows jumped. There’s no support for Apache 2.4. And the mod release is only on SPDY 2 when the release is on SPDY 3.1? What on earth is Google doing!? Apparently giving up on mod_spdy which is horrible. Love the open source community though. Patrick Buckley forked it. I cannot stress enough the requirements in life to check into some random stranger before you just download and use their code. Especially when we’re talking servers! Sadly, looking into his code I saw it would upgrade apache and SSL.

    Well. No. It’s not that I don’t trust this guy, the code looks okay. It’s trying to install HTTPD 2.4.7 which is not the latest and greatest for my server’s OS (currently 2.4.9). Not to mention some research on cPanel showed issues with mod_spdy and CentOS (including the note that Patrick’s code caused random coredumps). However. The odds are that when, eventually, the stars align and there is mod_spdy (or some alternative) for Apache, it’ll be for 2.4.x so I may as well put the effort into updating today.

    Sidebar. Yes I know about nginx. Yes I’m aware of the package for CentOS. Yes I know it’s faster for static files and CSS and JS (and arguably even for PHP). Yes I know it’s easier to use default nginx than to tune Apache. But. I like having my .htaccess file to edit, and I’m not ready to do a total switch yet since this is not my server for me alone. Eventually yes, I will. Today is not that day.

    So Apache 2.4! There aren’t a lot of Apache 2.4 issues, but what they have are major enough for me to sit up and pay attention. For example, MPM-itk is no longer provided as an easy install from cPanel, they wanted me to use mod_ruid2, which isn’t compatible with memcache. I really hate that. However. Many people informed me you can still use memcached, and besides which, Apache 2.4 doesn’t support Memcache. I still find it amusing that Cpanel outright says mod_ruid2 is just as dangerous as MPM-itk, but would rather use the one that’s less compatible. It’s not that I can’t install it on my own, of course, it’s as the amount of effort put into working around a problem gets large, the less pleased I am with that as a solution. Work smarter. By the way, mod_ruid2 is available on Apache 2.4. I learned a lot when I installed it myself, now I’ll learn more.

    There was a catch in things of course. I’d set up mpm.conf files in /usr/local/apache/conf/userdata/std/2/ and had to roll those back, as they borked deployment. Took me an hour to sort out that. Remember to read the complete errors, folks. Of course I tested things once Apache 2.4 was up, before starting to make sure all my modules etc were still running. I was lucky, I only had to configure pagespeed for Apache 2.4. Everything else worked out of the box. Since I was using MPM Prefork already (worker is not available due to mod_ruid2) I didn’t have to edit anything there.

    Devil food cakeWhat did I notice? Memory and load stayed the same. And you’d think that meant this was for nothing. I should mention this happened to be on the same day I got nailed by a 60% bump in traffic on my busiest site. So … that would be better then.

    I’m bummed that SPDY isn’t being actively developed for Apache right now, though. For folks who are pushing the HTTP 2.0 world, they seem intent on ignoring or not committing to getting others up to speed. While nginx is awesome, there will always be a reason for people to use other server types. I hope to either see mod_spdy get picked up and loved again, or for someone else (Microsoft’s HTTP S&M?) to pick up the thread and remember that abandonment doesn’t move things forward as fast as you’d think.

  • Polyphemus Problem Pans Out

    Polyphemus Problem Pans Out

    I use PHP in DSO mode, which is (woefully) insecure because it lives to save files as ‘nobody.’ Now, previously I found a ‘fix’ to this with WordPress, by tweaking some file permissions and a define in my wp-config.php file, and all was well. But if you know me, you know I’m polyamorus with my CMS, and WordPress ain’t the only game in town.

    I love, love, love Zenphoto for a gallery that is larger than my thumbdrive. But I’ve been having an annoyance that acrylian and sbillard have been really patient with me ranting about for a while now. See, when you upgrade Zenphoto, it narked at me that I had bad permissions:

    zenphoto-perms

    Oh how I cried. My work-around became to make those 777, upgrade, and change ’em back to 755, because that did work for nobody, but when Zenphoto moved the config file and had it be writable by the upgrader, I had to make that owned by nobody and the slippery slope was happening. This was not good. I brought it up again, but we all agreed this was very much a me-problem.

    A new PHP

    Now my choices were to deal with it, or change to a new PHP. Well there are problems with that, and neither suPHP nor FastCGI met my needs for speed and memory consumption. Also I tend to get error 500s when I try any of them on this server, which means I would have to do a total overhaul which I don’t have time for. Instead, I decided to look into why mod_php (aka DSO) likes to have nobody own this stuff. In my research, I stumbled across mod_ruid2, which is included in EasyApache.

    Gruppo_di_polifemo,_sperlonga_0In reading up on cPanel’s notes on mod_ruid2, I hit the incompatibilities list and winced. Right there near the top was MemCache. When I switched over to ZendOptimizer, I also switched to MemCache, and I really was not ready to give it up and go to XCache. Worse? It’s not compatible with mod_security. Epic fail. I absolutely cannot use this. Back to the drawing board until cPanel figures out a way to force it to work with those.

    More searching introduced me to MPM-itk. This was something categorically not supported by cPanel (they backed mod_ruid2), but they still had some directions on how to do this in their forums: Using MPM ITK as a Custom Opt Module

    I need to stress two very important things here:

    1) This is NOT supported by cPanel.

    They do include it in their Custom Mods, but they don’t support it’s use, and won’t include it by default because of issue number 2 (see below). Mind you, I’m no stranger to unsupported installs. I have ImageMagick in a higher version than they do, I installed wp-cli, and I have Pagespeed. So I pretty much run around always upgrading what I need. I am smarter than I used to be, and I have all this documented in a Word Doc called “Custom Installs on my server” which lives on Dropbox, for emergencies. Everything is written with code examples and as much copy/pasta as I can.

    2) There is a security risk with mpm-itk because it runs as root.

    I will quote the author:

    Since mpm-itk has to be able to setuid(), it runs as root (although restricted with POSIX capabilities and seccomp v2 where possible) until the request is parsed and the vhost determined. This means that any code execution hole before the request is parsed will be a potential root security hole. (The most likely place is probably in mod_ssl.) This is not likely to change in the near future, as socket passing, the most likely alternative solution, is very hard to get to work properly in a number of common use cases (e.g. SSL).

    Obviously this is a choice you need to make yourself. Perhaps ironically, by using setuid(), you’re protected from users cross-contaminating but this is not really a perfect fix for everyone. And frankly, this is not my preferred long term fix. My long term fix is this: Build a brand new server, from scratch, with FastCGI, and move sites over one at a time, testing as I go. That’s not today. Instead, it took me about an hour to figure this stuff out and install. And it worked out of the box. Well, except for one thing which I’ll get to.

    Installing mpm-itk

    These directions are pretty easy for cPanel/WHM. You install:

    cd ~/tmp
    wget http://docs.cpanel.net/twiki/pub/EasyApache3/CustomMods/MPMitk.tar.gz
    tar -C /var/cpanel/easy/apache/custom_opt_mods -xzf MPMitk.tar.gz
    

    Then you run EasyApache (/scripts/easyapache) and select mpm-itk from the Exhaustive Options list for PHP (it will give you a warning about the dangers, Will Robinson). Once the update is done, make sure all your normal settings are back in place, if you have anything special, and now you have to actually tell every virtual host what ID to use.

    mkdir -p /usr/local/apache/conf/userdata/std/2/username
    echo "AssignUserID username username" >> /usr/local/apache/conf/userdata/std/2/username/mpm.conf
    /scripts/ensure_vhost_includes --user=username
    

    Replace ‘username’ with your user name (you saw that coming, right?) and off you go. Of course, I had 10 users, so instead I scripted it:

    #!/bin/bash
    for user in `ls /var/cpanel/users`; do
        mkdir -p /usr/local/apache/conf/userdata/std/2/${user}
        echo "AssignUserID ${user} ${user}" >> /usr/local/apache/conf/userdata/std/2/${user}/mpm.conf
        /scripts/ensure_vhost_includes --user=${user}
    done
    

    Huzzah!

    Cleanup, Aisle PHP

    Once I had it installed, and it really was painless, I tested uploads on WordPress and everything worked. But I remembered what I had done back in 2011:

    The last step I had was chowning the folder for uploads and 2011 to nobody:nobody.

    This time I did it in reverse and chowned everything back to my user IDs. I did this for all sites, for all users, and all cache folders. Then I decided to look for all files and folders that were 777 (which I do at work when scanning for hacks) just in case I’d been stupid. I try to not be, but…

    find . -type d -perm 0777
    

    That listed all directories, and I was appalled to find some! That’s right. Up until recently, there were folders permission’d as 777 on my server. I bow my head in shame and embarrassment. Please forgive me, as I run this command to fix that:

    find . -type d -perm 777 -print -exec chmod 755 {} \;
    

    I also ran find . -group nobody to see if I had anything left over, and it happily came up empty. Then I went to double check everything worked. When I’d tested before, I did it on my single install of WP, my wiki, my gallery, another blog, and it worked. So I came here to post and I couldn’t upload images. Horror! Shock! I decided to scan my error log, and right away got a warning on cPanel: Out of disk quota.

    Well that was an easy fix!

    Now everything’s owned by the user it runs for, and nobody owns anything. Everything is secure (except for that ‘running setuid as root for a millisecond’ issue, and yes I’m keeping tabs on that), and everyone is happy. Especially me.

    Bonus Internet points if you get the joke with the title.

  • Separate Users Are Good

    When you create a new domain on DreamHost, you can chose to make a ‘new’ user to ‘own’ the site, or use an existing one. There are pros and cons to both, but for anyone who comes from the cPanel world (where separate accounts are de rigueur), it’s pretty normal to expect your separate site to have a separate login name and password.

    Explaining how all this works on DreamHost is a little different, because we have users and then we have users and … well let me explain.

    There’s more than one kind of user

    The first type of ‘user’ you have at DreamHost is your panel user. This user is the one you make when you sign up, and it’s usually your email. Don’t share this password with anyone, okay?

    Next we have your ‘users’ which you can find in your panel. Those users are the ones who have access to things like ‘shell’ and ‘sftp’ and so on.

    Then there are also those ‘other’ users you think of, like the login accounts on your blog, or your email, or maybe even the billing account for DreamHost.

    When I talk about separate users, I’m only talking about the ones who have access to shell and stuff.

    Users own sites

    Those user accounts own sites. That means I have a specific user who ‘owns’ the folder on the server where all my web code lives. And you can see it’s that user because there it is, in the path: /home/USERID/domain.com/

    Only one user can own, and access, a domain. However a user can own multiple domains.

    So here’s what this looks likes. One user owning multiple domains:

    one user multiple domains

    And only one user can access the domain, user two cannot:

    User 2 has no access

    This is cool because if there’s a domain under User 2, and it gets hacked, there’s no way for User 1 to get hacked, even if both users are you!(Unless there’s a server wide security flaw, which yes, can happen, but we spend a lot of time trying to prevent that.)

    Logical User/Domain Groups

    If you own 50 domains (and I’ve seen users with 200!), having them all owned by one user sure seems easier, but it means if that user gets hacked, they’re all vulnerable, and you’ll probably end up having to de-hack 50 domains at the same time. Instead, it’s wiser to group your domains ‘logically.’ For example, my elftest.net domains have subdomains, all of which are owned by the same user. However my other top-level domains are each owned by their own user. But that doesn’t work for everyone.

    Recently I was helping a customer with a hacked site, and he complained that the sites he hosted for his clients were being hacked, and his clients were pissed off. I took a look and saw that all his client sites were under one user ID. I asked him if the clients had more than one domain, or if they all had their own, and he replied that each client had 4 or 5 of the domains. After cleaning up the hack, together we made new user accounts, one for each client, and moved the domains to those accounts. If possible, I always clean before moving, but in one case the customer had 75+ hacked sites, so we moved and then cleaned each one, prioritizing the accounts on the way. It took a very long time.

    109649_D_0989 The extra benefit to this is the clients can now have FTP access to their domains and do wild and crazy stuff! But we don’t want them to have FTP.

    Moving The Domain

    Obviously first you need to setup users. When I set up a new user, the first thing I do is make it secure. That means I turn off FTP, forcing SFTP only, and if needed, give them Shell access. Personally? I love shell access, so I always leave it available. If you’re using DreamPress, we have Shell turned off by default, but you can activate it.

    Secure User Settings

    There is a downside, which is that the WebFTP app won’t work. Personally? I find 99.999% of WebFTP apps to be total drek. They’re messy, kludgy, and there are some great free apps like Cyberduck which even let you connect with DreamObjects!

    Now that you have the user, we want to move the domain. This is so easy, anyone can do it. Go into Panel, click on domains, click on edit for the domain. Go to “Users, Files, and Paths” and change the user in “Run this domain under the user:”

    Changing Users

    Really, it is that simple.

  • Why We Don’t Auto-Update Plugins

    Since the push of DreamPress (which I’m totally digging), the ‘One Click Install’ feature of DreamHost has become a little more obvious to people, and it’s benefits and disadvantages.

    What’s this auto-upgrade thing?

    To make this simple, if you use DreamPress or our One-Click installer, we automatically upgrade WordPress for you! It doesn’t happen the very second WP has a new version, mind you, we spread it out to not destroy our servers, but you will get upgraded unless the upgrade feature was disabled (of course, you would never disable them, right?). Any time you want to see if you have automatic upgrades enabled, or want to run your own, head over to the DreamHost Panel.

    Why not plugins and themes?

    So why do we only do this for core WordPress? Because plugins and themes are messy.

    Easy Update Button!

    The safest upgrade in the world is the minor upgrade (like WP 3.6 to 3.6.1), as it’s exceptionally rare that it breaks anything. It’s not perfect, of course, sometimes we find out that a plugin or theme was doing something in a very non-optimal way before (if you hear ‘doing_it_wrong()’ please keep in mind that is not a value judgement, just a code comment, we all do it wrong in the beginning). But rarely will this kind of upgrade break your site.

    Similarly, the major releases (3.5 to 3.6) are perhaps surprisingly stable. They’re tested, a lot. At DreamHost there are two people (me and Shredder) on the core contributor list, and we’re heavily involved in WordPress development every single day, at work and at home. We keep up with WP changes, test them on DreamHost, and work with the core team to resolve issues before they even release a beta! We’re on the job!

    “But hang on!” I hear you say. “I upgraded to 3.6 and it broke my theme!”

    And THAT is why we don’t upgrade themes.

    I know, I know, it sounded counter-intuitive. You have to look at it a different way. Your theme stopped working with WordPress 3.6. That means something in the theme is not compatible with the best practices in WordPress core. Translation: WP didn’t break, your theme had a bug.

    It sounds like semantics, or hair-splitting, and I totally get that. It also sounds like we’re passing the buck. We’re not! And we’re not trying to imply the theme (or plugin) developer who now has a broken product is a bad coder, or doesn’t pay attention to WordPress. What we mean is that themes and plugins, as they are used by much smaller segments of the WordPress community (everyone uses core, but maybe only 1000 use that theme), it just can’t be tested as robustly. This is especially true of the solo-developers. Speaking as one, I used to develop WP only in my free time, so any time WP had a new release coming up, I had to take days to test all my plugins, and pray I got everything. Invariably I missed stuff. It happens. We’re humans.

    Breaking isn’t the only reason, though. Sometimes an upgrade is messy and complicated.  Take, for example, NextGEN Gallery. When version 2.0 came out, it inadvertently broke a lot of installs. There was chaos, drama, and finally an open letter. How did this happen? It happened because NextGEN is hella complex, and it’s used in myriad different ways. It happened because plugins and themes can do anything with WordPress.

    Police_man_update.svg

    Blindly updating core is safe. It’s tested and easy to roll back. Blindly updating themes and plugins are not always easy to roll back, they’re not always easy to upgrade (some require a massive upgrade script to run), and they may require you to make other changes in your theme. For that, we just don’t.

    If DreamPress is MANAGED Hosting, like WordPress.com, how come THEY do it?

    You mean why do the plugins on WordPress.com get auto-updated? Because you can’t install any plugins on Wordpress.com! That’s all. They control everything, and simply activate various plugins depending on what package you buy. It’s not really the same thing at all, but I get why people think it is.

    I don’t care! Can I auto-upgrade anyway?

    Are you sure? Okay, then! Install the plugin Automatic Updater (by Gary P.) and set it to upgrade your themes and plugins. I personally use it on all my sites, but I’ve also personally vetted each and every plugin on my sites.