Tag: open source

Personal Version Control With Git
One thing I am personally bad at is version control. Oh, don’t get me wrong, I’m ~~great~~ decent at it for code at work, but I still have a tendency to cowboy code. Bad me.

Part of why is that I don’t want to have my stuff public. At the same time, I don’t want to pay Github while I’m learning, and I want a GUI. Why not overcomplicate my life! I’ll add on one more, I want a website where I can look at my changes all pretty like. Last time I did this via SVN, hated it, never used it, and walked away. This time I decided to use Git, and once I started using it via the command line, I realized how freaking awesome this was. And since I’m using CLI, I ran git config --global color.ui true to get pretty colors.

I should note that I use Coda2 by Panic and I love it. But. It doesn’t have an easy way to properly branch and tag in SVN or Git, which is something I’m used to having. And my master plan is this. Master will have the ‘live’ real code. The branches are releases. When a branch is ready to go live, I merge it with master.

So let’s get started.

Stage One: Install Git

I followed Gits official directions for installing Git on my server, so once you’ve got things like that up and running, it’ll be time for the webpage.

Cart comes after horse, though. I had a hell of a time getting my own SVN crap up and running, but git was way easier. There was far less to mess with to install, since I’d already done it before. With Git, I don’t need to mess with svnserve or daemons, since git isn’t the ‘server’ where my code is stored, it’s just another repository/clone. It breaks my head sometimes, but this is a case where it’s going to be easy. Install any Git dependencies (on CentOS that means I ran yum -y install zlib-devel openssl-devel cpio expat-devel gettext-devel ) and then install from command line:
```
cd /usr/local/src
wget http://git-core.googlecode.com/files/git-1.8.2.2.tar.gz
tar xvzf git-1.8.2.2.tar.gz
rm git-1.8.2.2.tar.gz
cd git-1.8.2.2

./configure
make
make install
```
Done, and now I’m on 1.8.2.2. Upgrading is as easy as doing the wget again.

Stage Two: Make Repositories

At this point, the official git directions say you should make a git account, but after some pondering, I decided to put my repos in /home/myuser/gitrepos/ so I can easily add my repositories to my local computer. Everything is locked down via RSA keys anyway, so I can secure connect from my computers and everything is basic and simple and safe. If I want to make more repositories for other accounts, I can do it as a one-by-one basis. Right now I have no need for group stuff, this is a me repository after all. If I did, I’d use git’s directions for making a git user instead.

I made projects for my domains (ipstenu and jfo) and then one for my server (mothra). I hooked into them with Coda2, which is my app of choice, and I tested that I could get and push files. I’ll come back to this in a second.

Stage Three: Webify it!

Next up was webifying things. I want to do this, even though I’m putting it behind a password, because I’m visual and being able to see what I’ve got going on is helpful to me. I went with GitList because it looked nice. The drawback to these things is that if I used a shared repository (say /home/gituser/gitrepos/ for example) then I’d have to web-alias to the gituser instead of having it hosted as ‘Ipstenu’ … which is okay. If I was really making a full blown shared group, I’d probably buy gitstenu.org and point it there.

Awesomesauce! It works! Except for this error Unnamed repository; edit this file ‘description’ to name the repository. That’s easily fixed on the server by editing the description file.

Those initial repositories are for my non-public files, actually. That’s where I keep copies of the obscure shell scripts I run, stuff that isn’t web accessible. After I got those set up, I made repositories for my themes and my mu-plugins. This gave me folders like ipstenu-mu-plugins and jfogenesis-wp because I named the theme ‘jfogenesis’ for WordPress, MediaWiki, and ZenPhoto. Still this let me progress to …

Stage Four: Control

The whole reason I did all the rest of that was so I could do this, which seems redundant, but bear with me.
1. I checked out all the code locally, edit it, and push it back up to the repos on my server
2. On the webserver, I check out the code with a simple git clone to folder2 (trust me)
3. switch folder and folder2 (you know how to move things)
4. Checkout the new code with a git pull. If I want to checkout a specific version, it’s git checkout -b mysite-REL_1.0 origin/REL_1.0(It’s worth mentioning that I made a branch for everything at the start as REL_1.0 because reasons.)
And that’s it.

Stage Five: Updates

Here’s my current process.

Locally, I start work on my new version so I make a new branch: git checkout -b REL_2.0

Edit my files and add and remove them as needed:
```
git rm <filename>
git add .
```
Check them in when I’m done with the files: git commit -m "Editing foo and bar, replacing baz."

When I’m ready with it to be tested, I push it: git push origin REL_2.0

Everything tests well on the dev server(Just pretend there is one.)? Okay! Let’s merge!
```
git checkout master
git merge REL_2.0
git push origin master
```
Summary

Since this is just me running stuff, it’s pretty easy to keep track of everything. Having the website makes it easy for me to see what’s I last did and what’s changed:

Again, yes, I put the git website behind password protection. I may change this later, if I determine I never put anything secret up there. But right now, this is good for me. After a couple days of using it, I liked it a lot. Enough that, unlike my foray into SVN, I kept using it. It was easy for me to keep my code organized and up to date. If I had to update ‘live’ I could still use branches easily and roll things back painlessly. That’s pretty darn cool.
13 May, 2013
WordPress False Security
Credit: Grafitti Verite
I wrote this months before the botnet attack of April 2013, but I kept putting off posting it. Clearly now is the time! So since people often ask me if I do certain things to protect my site, here’s what I don’t and do do.

What I don’t do

• Hide the WP version in my HTML
• Remove readme.html
• Hide login error messages
• IP blocking*
• Use a different prefix for your DB
• Move wp-config.php*

I don’t bother with the readme or the WP version because it doesn’t matter. People don’t actually search for ‘Who’s using WP 3.4.2? I’ll attack them!’ They let slip their dogs of kiddie cracker war and bury us in traffic. I learned that lesson with the TimThumb debacle. My server got slaughtered by people not searching for TimThumb, but slinging attacks at me as if I had it installed! Even better? They didn’t bother to differentiate where my install where WP was in a subfolder (domain.com/wp/) and just attacked domain.com/wp-content/themes directly. The same thing happened with the recent botnet attacks. Basically people are going to attack me, assuming I’m vulnerable. It’s only when I’ve pissed someone off directly that I’d worry about having a specific version being an issue. And since I keep up to date with upgrades and patches, I don’t worry so much at all.

The error messages thing stems from people worrying that failed logins to WP will tell you that you got the username or password wrong. So if I login as Lpstenu, it’ll say ‘ERROR: Incorrect username.’ That apparently spooks people, thinking that if you know that you’ve gotten a right username, you’ll hammer that. Do me a favor. Go to yourdomain.com/?author=1 and what happens?(This doesn’t work on this domain because I created it back when WP defaulted your first user to ‘admin.’ I made a second ID and deleted that one.) That’s how much effort it takes to find your username, folks. It’s even easier when you look at this post and see the author name, and a link to it, right there in front of you. Your username isn’t a secret. It’s dead easy to get. I’m not wasting time hiding something that easy to find.

That’s not really a valid “security” improvement, anyway. It’s irrelevant whether the attacker knows what he got wrong, as it provides no extra information that would help him to get in. Furthermore, the usernames are exposed in dozens of other places already as I showed you before. I often argue that you can’t remove doors: everyone has to be able to get into a house, so we put locks on our doors as deterrents, and signs up to say we’re watched by ATD or whomever. All of those can be circumvented, and you still have a door. Most crime is prevented by deterrents, however (a sufficiently motivated and skilled person will work around anything), so really all we do is make things inconvenient enough that they go somewhere else.

Part of security is knowing where to spend your time. Make a better mousetrap and you get smarter mice, true, but if you still want to get rid of the mice where do you start? I start with not hiding the obvious. Here’s my username, here’s my login location. They’re standard on most websites, because people have to be able to log in. Now when I really have a locked down site where I want no one but me to log in, I use .htaccess to limit login to just my IPs. This is a (minor) problem when I’m on the road, but I can always SSH in to fix that. Most of the time, though, I trust in my firewall, my server, and the basic security of WP to be enough.

IP blocking is totally useless to me. With a caveat. I use CSF and ModSecurity on my server which will block by IP if you hit very specific abuse parameters, including my newer ModSec rules for protecting logins. However I don’t pay much attention to it, save to whitelist my commonly used IPs. The point of the firewall is not to stop people I know are bad, but to dynamically catch them in the act, block them on the fly, and then let that IP gracefully expire after a certain amount of time. Years ago I may have had to use .htaccess for that, manually updating it to block specific IPs, but software’s come a long way, and letting the right tool do that job is huge. If you only have .htaccess, well, you can use some .htaccess protection of logins, or you can use Perishable Press’s 5G Blacklist. As I tell people frequently, you never know where legit traffic is coming from, don’t be foolhardy.(True story. A customer at work insisted he did too know better, and blocked China and India traffic. Then he went there on vacation and was pissed he couldn’t log in. Yes, I mentioned I had warned him before.)

Curiously controversially, I don’t mess with the DB prefix. I use wp_ much for the same reason I never move my wp-content folder unless I’m using CDN (and even then…) : Poorly written plugins and themes will kill me, and people can view my source code or use DB insertion calls in their code. They don’t have to know my prefix, and in fact, best coding practices are intended to work no matter where the folder is or what you use as a prefix. The other reason is I’m exceptionally lazy, and the less I have to remember that I did ‘differently’ in case of an emergency, the easier my life is. This is important when I’m ever hacked (yes, when), because I can restore faster from scratch if I didn’t go nuts reinventing the wheels or moving things around. Rebuilding a wp-config.php is very easy if I only have to change passwords and user IDs, after all.

Similarly, I don’t move my wp-config.php in most cases. I do on my localhost instance (so I can wipe the folder and DB and start over easily), but really it’s impractical in other situations for me. I think it would be safer to move it out of a web-accessible folder, and when possible I do that (sometimes I have WP in a subfolder) but I have other things I can do to protect that file.

What I Do

Besides a massive amount of work keeping my server up to date and tuning my firewall, I do some things that anyone using WordPress can do:

• .htaccess protect wp-config.php
• Lock file permissions
• Prevent plugins from writing to wp-config.php and .htaccess
• Prevent folder content browsing (for images mostly, but also plugins)
• Use strong passwords for WP/FTP/SQL accounts
• Use one-time passwords for WP/SQL/FTP/SSH accounts

I protect my wp-config.php from direct access with a really simple .htaccess directive:
```
<files wp-config.php>
order allow,deny
deny from all
</files>
```
I think nginx is this:
```
location ~* wp-config.php { 
    deny all; 
}
```
This means you can’t see https://halfelf.org/wp-config.php in your browser. It’s pretty minor, in so far as things go.

I lock down my file permissions as tight as I possibly can. Nothing is set to 777, and my .htaccess isn’t writable. This means if I use a plugin that wants to edit my .htaccess (or wp-config), I have to do it manually. This is good, in my opinion. I always know exactly what I’m doing. In my .htaccess I also have Options -Indexes, which stops people from being able to browse empty folders (this is important for plugins that don’t have an index.php file). Since I’m using SVN and Git, I also prevent people from seeing those:
```
	RewriteRule ^(.*/)?(\.svn|\.git)/ - [F,L]
	ErrorDocument 403 "Access Forbidden"
```
My passwords are stupid complex. I haven’t the foggiest idea what they are thanks to 1Password. I also don’t reuse passwords. This is very important for how my server is setup, as DSO requires you to enter in passwords to upgrade WordPress. While I can use my main account, I actually created an FTP only account for each and every website on my server, and then I hard coded that (and it’s password) into my wp-config file. So yes, I have a DB password (each account is used once for each DB) and an FTP password (again, one account for each account) in my config. And no, I’m not worried about that. Sometimes I have a generic SQL ID for all DBs under one account, though that’s a tiny bit more risky.

But, most importantly, I try to cure myself of being stupid. I don’t log in to my site via non-secure ways (SSH & SFTP only). The passwords I use for my login (which is not SSL protected on WP) are one-account/one-use. I try never to log in on someone else’s computer. I don’t do admin work on potentially unsafe wifi. You see, the greatest security risk in the world isn’t the software you’re using, it’s you. You do stupid things, like recite your credit card info (or password) over your cellphone while on a train trying to get your host to reboot a server. You use Starbucks’s wifi to pay your bills. You talk about how your mother changed her name.

Social engineering is way more dangerous than any server hack, and when it’s down to the wire, that’s what I’m more worried about. After all, I have good backups of my files.
16 April, 2013
Your Photos, Your Way

I’m funding PressGram on Kickstarter and you should too.

I like Open Source. Surprise!

I don’t mind paying for products (as witnessed by the fact that I have paid for this theme, and even the old DevPress and ThemeHybrid ones I don’t use anymore. I have a slew of plugins I paid for, and all in all, I think every dime was money well spent. Paying for open source makes sense.

So there’s this guy I know from the Internet, John Saddington, who likes taking photos, and he likes social media, but he wonders, like I often do, what happens when those outlets go away? Where are all my photos if TwitPic or YFrog vanishes? Or if Facebook deletes my account?

They’re gone.

John loves WordPress. So do I. John loves photos. Well. I fiddle around with them, but the point is he wants to built something that is way more than ‘just’ a plugin. He wants to make a free iPhone app… look, this is what he wants:

The premise is simple: I wanted to post filtered photos from my iPhone 5 but without worrying about any privacy or licensing issues (and we’re not interested in asking you to upload photo IDs). In other words, I wanted complete and total creative control of my images and content (as well as the pageviews).

And this will post to WordPress, which is so simple, we have a one-click installer at DreamHost for you to use to make it. Imagine that. You could have a photoblog with a couple clicks.

When I read that John was making PressGram, I had to poke at it, even though it’s not Open Source. It’s an Apple iOS app. I’m not shocked that it’s not open source, and after consideration, I don’t mind. It doesn’t have to be. As long as the plugin is open source (and frankly, given WordPress’s API, I can easily envision how it would be without stepping on closed source apps), it’s good to go.

John knows his shit. He shares the same concerns and doubts about social media as I do, he rails on Facebook for the same things I do. He’s a guy whose ethics I can get behind. And he’s a guy whose code I can get behind. Remember I review plugins. I’ve seen his code. It’s good.

So yeah, I’m supporting him so you can have a free app. Go figure. And as with most of the things I kickstart, I get no swag back (I think I get a kudos and a link somewhere), because I like to give for the spirit of giving most of the time. I’ll be getting the Veronica Mars DVD, but I’d be buying that anyway.

Give in. You know you want this. Pay $5 instead of risking your content belonging to someone else.

6 April, 2013
Chrome Dumps Webkit

Chromium, the machine behind Chrome, has dumped Webkit.

This speaks for us all:

Chrome is no longer using webkit. Every developer in the world:http://t.co/3wIT6XCaxO

— soully (@soully) April 3, 2013

I’m not sure what’s going viral first, that gif or a ‘Don’t blink’ joke that someone has yet to make up. Oh, the new system is called Blink, and it’s open source.

We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.

Yes, this means we all get to use even more browsers to make sure our sites look okay on all of them. Again. Thanks. And while they say it’s ‘based on’ webkit, that’s about as ‘related to’ as when Law & Order would say ‘The following episode is based on a true story, only names have been changed…’

This prompted my coworker Shredder to opine “Are Google and Mozilla late-april-fooling us?”

Did you miss the Mozilla/Samsung partnership? ~~Or maybe you didn’t notice that Opera moved too Webkit in February.~~ No wait! OPERA SWITCHES TO BLINK

Okay, Rarst is right: They’re out to screw over Apple.

Well, I don’t know about you, but I can’t wait to see the new ways in which my sites break!

3 April, 2013
Trading APC for Zend
The last thing I did before Passover was a totally unannounced, not telling anyone, surprise flip from my old standby, APC, to the new hotness, Zend.

As of PHP 5.5, Zend Optimizer+ will be included. Back in 2009, I decided to use APC for a couple reasons: It was made by the PHP blokes and it worked well with mod_php and MediaWiki. Since PHP decided to change, I joined in. Why the change? Zend went open source.

Installing Zend

I grabbed the latest tagged version from the official GitHub repository, since I don’t cotton to using bleeding edge all the time.
```
$ wget https://github.com/zend-dev/ZendOptimizerPlus/archive/v7.0.1.zip
$ unzip v7.0.1
$ cd ZendOptimizerPlus-7.0.1/
$ phpize
$ ./configure
$ make
$ make install
```
That gave me the final output of: Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20100525/ You want to hang on to that path, because we’re going to edit php.ini and put this in below the line for IonCube, if you have that installed:
```
 zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/opcache.so
```
Replace the path with your own.

I also followed their advice on the recommended config and put this in my php.ini as well:
```
[Zend]
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
```
Since I had APC there before, I removed all those lines while I was at it. Restarted PHP (well, httpd in my case, I like a clean slate) and I was done.

Cleanup

As I mentioned before, I removed the APC lines while I was in the php.ini and, since I installed it via a downloaded pecl, I just removed the apc.so file from the same folder where opcache.so was installed.

On WordPress, I also removed the APC Object Cache Backend plugin from the two sites that had it, since I’m not using APC. There doesn’t appear to be an equivilent for Zend, but I may or may not need that.

For MediaWiki, I had to edit LocalSettings.php and remove $wgMainCacheType = CACHE_ACCEL; as that’s no longer being used. Then I went into my maintenance folder and ran php rebuildLocalisationCache.php --force to flush everything and my errors went away. MediaWiki has a pretty different cache method than other apps, and for yonks flat out didn’t work with Zend. It does now, and there seemed to be no speed loss without an OpCode cache.

None of my other apps seemed to care, so I moved on to see how this all played out.

Results

Much like the ManageWP guys, I saw an immediate drop in memory and CPU. And I’m still on PHP 5.4! There was an initial spike while I was mucking around, which I expected, and then everything dropped. Some things did not so much drop as level out and change my ‘spike’ range. Normally my load average for 1 minute would spike at 0.8 or so every hour. Now it’s spiking at 0.5, give or take, which is a success in my book.

Can you guess when Zend went on?

Before someone points out that, hey, this is hardly a real check, I want to note that I was having one of those 200% traffic days. Actually I was having a few of them in a row, and I know it’s going to go up from there. Here’s a quick look at my traffic:

The real test will be tonight and tomorrow, though, as I push some large data (videos) on a popular topic, but frankly, this is looking good.

The benchmarks used in the ticket to include Zend in PHP (why are they using WP 2? I have no idea) were startling compared to normal PHP. Compared to APC it’s a minimal kick in the pants, but the assurance of bundling to come speaks for itself. This is where PHP is going.

Credit: Dimitry

I’m not yet on PHP 5.5, but I’ve already found that 5.4 is a notable kick to my speed. Zend took me from a B to an A in PageSpeed and YSlow (when you tell YSlow that I’m a small blog and not Amazon). Also it ‘feels’ faster, which is totally subjective, but still a valid remark. The site feels fast, it doesn’t hang (yet) and it didn’t crash over Passover!

Former bbPress regular, _ck_, went and wrote a neat little Control Panel for Zend Optimizer+ which I snagged and tossed into my secret bin for poking at later.

Since I’m the Zend Rookie, anyone have any tips and tricks for configuring it to make it sing? Remember, I don’t just use WordPress on this box!
2 April, 2013
Goodbye Google Reader
Credit: Poorly Drawn Lines
You know, I get it. RSS is not a popular tool for people who like the ‘river’ flow of data. If you like everything to flow into your stream and back out, like Tumblr or Twitter or Facebook, then the loss of Google Reader is meaningless to them. “Why do I want another inbox?” they argue. That’s all fine and dandy for you, but we have to accept that different people process data differently. Some people like to watch news come in live, like reading a CNN ticker, and if they miss it that’s okay. Others of us like to say ‘These are the things I like, save a note when they happen and I’ll read them when I can.’ They’re two different workflows, and they appeal to different people.

Me? I’ve been using Tiny Tiny RSS for just under a year now, and I’ve actually figured out how to do everything I want, with key-commands. Since I use multiple devices for my news consumption (two laptops, an iPad, etc etc) having this web-based was a real killer. And while I could use a cloud device, I’ve never found one that worked across Windows and Macintosh, and wasn’t blocked by The Bank. That’s less of an issue now, but having it all on my own server beings me back to my oldest bugaboo ever: Owning my data.

If there’s anything you get from the whole Google Reader fiasco, it should be this: Google gave, and Google has taken away. Everyone who is mad that Google “Broke their trust.” just hasn’t been paying attention to the last year or two at Google. Google Apps for Email anyone? It’s not free anymore. But let’s not belabor the I-told-you-so part and get to the meat of the post.

Tiny Tiny RSS

So installing this is really easy for anyone who’s installed any PHP/SQL app before, I’m not going to get into that, you can read the Install Notes yourself. What I will point out are the plugins I find most useful, and the quirks to keep in mind.

First of all, ttrss is more like MediaWiki than WordPress. This means the upgrade is mostly manual for some of us, and you activate plugins by editing the config.php file. However. There is also a plugin interface in settings, so the define’d plugins are basically like Network Activated, which is great if you have multiple users. The other plugins are in the preferences.

Plugins work like this:
```
define('PLUGINS', 'auth_internal, digest, updater');
```
And I am fond of the following:
- auth_internal – Authenticates against internal tt-rss database
- digest – Digest mode for tt-rss (tablet friendly UI) Turn this on if you use your iPad
- updater – Updates tt-rss installation to latest version.
Interestingly, I cannot run the web-updater from my server, and it’s certainly to do with my PHP settings. That said, the manual upgrade is like WP: upload files, refresh DB, drink beer. I don’t mind it at all. There are the other available plugins under Preferences -> Plugins, and they make a lot of sense just by looking at them. Obviously they’re easy to see based on what you’d want to use. There’s no Twitter Plugin since Twitter’s new API made it a hassle to tweet and I don’t blame them on this front.(Tangental: Speaking of asinine moves, Twitter’s new API may require us to use it to embed tweets. The answer to the direct question was predictably vague.)

But if you’re here today, you probably want a more Google Reader type experience. I would enable ‘Combined Feed Display’ under preferences and disable ‘Automatically expand articles in combined mode’. This will bring the ability to expand posts. It doesn’t collapse them quite right or at all via mouse, HOWEVER everything you want can be done via key commands.
- s – Mark an article as starred.
- n (or down-arrow) – go to the next article
- p (or up-arrow) – go to the next article
- u – toggle read/unread
That’s pretty much all I needed, and once I read them, they were blindingly obvious. You can see them when you’re

You can style CSS to fiddle with the layout, but so far I’ve not figured out how to make it display the title of the feed.

versus

On the other hand, I know the favicons of most of these sites so with a little CSS jiggering I was able to make it look a little better for myself. Here’s my CSS:
```
div.postReply div.postContent, body#ttrssMain, body#ttrssPrefs, body#ttrssLogin, body,blockquote,#content-insert blockquote, #headlines-frame blockquote, .dijitContentPane blockquote  { font-size:14px;}
div.postReply div.postHeader { font-weight:bold;font-size:14px;}
.hlScorePic {display:none;}
img.tinyFeedIcon {float:left;}
.Unread span.titleWrap  { font-weight:bold; }
```
From there on out, you can play with design as you like it. It’s clean, it’s simple, and best of all, it’s Open Source so if you like most of it, you can fork the rest!
14 March, 2013