Half-Elf on Tech

Thoughts From a Professional Lesbian

Category: How It Works

  • DoS/DDoS and You

    DoS/DDoS and You

    Attack! Attack!To a lot of people, you say ‘DoS’ and they think MS DOS, that old command line tool we used to control Windows.

    DoS stands for denial-of-service attack and DDoS is distributed denial-of-service attack. It’s a fancy way of saying ‘Someone’s hitting my server with a hammer so hard, it can’t get up.’ Sometimes you can cause an accidental DoS, like by embedding an image from your server into a public Google Spreadsheet.(Which would have happened to poor Panos when he self-attacked.) And sometimes other people will do it to you by hotlinking your images.(Which is why we block that, children.) Even the scanning people have done for TimThumb can look like an attack.

    Some people like to say that this sort of attack is new, that the Internet used to be good and kind and safe. In the 90s, I remember clearly accidental DoS attacks happening when a site was so popular, having over 500 people log into it at once would crash it. And once it was learned that this happened on accident, it was used as a weapon. Even before then, you could demon dial a number over and over again, until it crashed. I probably just showed my age, but the point is we could always take down a site via overwhelming it, it’s just easier to do it now and not get caught. Picture a thousand people all coming and knocking at your door, or ringing your doorbell, over and over and over.

    So now that you have a general idea of what a denial of service attack is, what can you do about it? If you’re on shared hosting, not a whole lot. The vast majority of ‘good’ fixes for this sort of thing has to take place on a server level. It’s sort of like trying to prevent your house from flooding when a water main bursts. You can put up sand bags, but until the city turns off the water, or diverts the flow, you’re probably going to lose.

    A lot of people suggest blocking by IP address, or using a tool like Bad Behavior to stop the trouble making bots. The problem with this is the troublemakers are still ringing the doorbell. Not as many, perhaps, but quite a lot. I’ve said this many times. IP blocking is a bad idea. Yes, blocking by IP address can work, it’s amazingly powerful, and it’s easily circumvented. The TOR Project is consistently lowering the bar for people to get a new IP even faster than the old days, when I could just re-dial my modem. This is a great thing for groups like Anonymous, and annoying for anyone who has to fight the hidden masses. While I fully support your freedoms, I also retain the right to defend mine, and sometimes that means I have to dig in and sort out how to handle the crazy.

    The first thing you can do on Shared Hosting is protect yourself against hotlinking. I don’t know how many times I’ll have to say it for the world to pay attention, but linking directly to images on someone else’s website, unless they specifically say it’s okay, is bad. I firmly feel hotlinking is theft of services (bandwidth) as well. Please don’t do it. Every half-baked host in the world now supports mod_rewrite, so grab Perishable Press’ ultimate anti-hotlinking strategy and protect yourself.

    Mr. ProtectionAnother useful tool is applying the http:bl (HTTP Blacklist) to your server. That sounds like a lot of work, but the payoff is surprisingly awesome. You see, catching more flies with honey is easy when Project Honey Pot tracks all the naughty people. Naturally there are a few WP plugins for that. In addition, if you just need to punt people who are trying to hack you, I would use the 5G Blacklist 2012 by Perishable Press. Combine that with Bad Behavior and most script kiddies are turned away without you having to fuss.

    That may seem a little contradictory, since I don’t advocate blocking IPs. There’s a subtle difference between you running around blocking every IP for every jerk, and using a well supported tool to do so. When you get around to blocking IP ranges, you shouldn’t be trying to block individual people, but the robots.

    If you get hit anyway, the thing to do is contact your webhost and start a dialogue. They’ll be as helpful as they can, and if not, may I suggest Liquidweb as an alternative? I pay more because I get great service. A good host will take a look at what’s going on and tweak their servers to help carry the load. A good host will help you tweak what you can. Of course, their DOS service runs about $500 a month and I don’t know about you, but I can’t afford that. The little guy has to survive too. Thankfully the other reason I support Liquidweb is that I, as the little guy, get fantastic support. The point is you need to have a good rapport with your host. It’s like they’re your landlord. Respect them, and they come fix your dishwasher ASAP.

    Sadly, at the end of it all, the only thing to do about a DOS attack when you’re on shared hosting is to wait it out. Shared hosting is great for what it is, but if that kind of downtime is cutting into your bottom line, you need to consider moving up to the next level. Remember, if this is something that earns you your living, treat it well! It’s like your car. If you make your living driving, you put money into preventative maintenance, and a VPS (or dedicated server) is very much the same. You can only get out of it what you put into it, so put the effort in to make it secure, or hire someone to do if for you. There’s no shame in hiring a mechanic, after all.

  • Tiny Tiny RSS

    Tiny Tiny RSS

    Tiny Hippo Had a Tiny Train
    Credit: Poorly Drawn Lines
    The majority of my ‘I am going to learn this if it kills me!’ lessons come from when I’m just dead frustrated with a product. Today it’s Google Reader.

    I like RSS feeds. They work well for me, I like having them sitting there, waiting for me to pay attention. It keeps news out of my email (which is for communication) and makes sure even if I miss a tweet, I see the article later. The world comes to me. This is also a part of my evil ploy to keep myself at Inbox Zero (current status – Inbox has 7 emails at home, 11 at work). I only leave emails in my queue when I know I need to hang on to them for a good reason, and even then I’m likely to save them off line (I use IMAP) to keep anything long term.

    For the last few years I’ve been using Google Reader because I check my RSS feeds at work (Windows XP, still) and home (Mac), and it lets me sync between the two. Google Reader remembers what I’ve read, and I don’t have to re-read things. But recently Google screwed me over, hard, with their inability to update feeds in anything resembling realtime. Specifically, all my WordPress.org feeds were days, if not weeks behind, and I couldn’t force them to update! What was going on?

    At first I thought it had to do with WP’s recent(ish) server upgrade to nginx, as certainly the problem started around that time, so I asked Otto and Nacin if there was a thing going on. Otto replied that there was, but it was Google. See, Google uses PubSubHubbub, which allows for updates in near-real-time. Sounds cool. If it worked. Now before you say it’s clearly me having the problem, it’s not. I asked around, and everyone who monitors WordPress.org related feeds with Google Reader has agreed: the feeds ain’t in real time anymore.

    I switched to another feed reader and, lo and behold, it worked just fine. Well that sucks. Now how can I handle all this? I could use a dedicated feed reader, but then I’m stuck only reading on one computer, which I certainly could do, but it’s 2012, and I like portability. What sort of options am I left with? After two weeks of experimenting and testing with various web-based readers, I decided that Google really was the best of them, and I was depressed. But I wasn’t defeated. I knew, I just knew, that some clever soul felt my pain and wanted to help me out. And I was right.

    Enter Tiny Tiny RSS. Tiny Tiny RSS is an open source web-based news feed (RSS/Atom) reader and aggregator, designed to allow you to read news from any location, while feeling as close to a real desktop application as possible.

    Tiny Tiny RSS

    Update daemon is not running.On the grand scheme of things, it’s easier to set up than RSS2Email (which I use on another account on this server), but due to me being on CentOS, which doesn’t really daemonize well for users, I had to cron job my feed updates at first. I set it at 15 minutes, after I ran it manually a few times to catch up. There are a few ‘quirks’ that aren’t as nice as Google reader. Like I have to manually refresh the back to get the read/unread counts to work right, and even with define('ENABLE_UPDATE_DAEMON', false); set, it keeps telling me that the update daemon is off. Turns out I also had to delete the /lock/update_daemon.lock file.

    Meanwhile, I dug further into this and found the pretty easy setup for ‘screen’:

    $ cd /public_html/tt-rss
$ screen -S updaterss
$ php ./update.php -daemon

    And detach from the screen with CTRL+A+D shortcut. Now someone mentioned that this will ‘break’ if the server is rebooted, so I left my cron job running just in case. I’m happy with cron, if it comes down to brass knuckles.

    I’m happy with this, and it’s only been a couple hours. The actually install process was easy, but this isn’t something I’d suggest if you’re the sort who wants a lot of help and hand holding for an app. I’m monitoring my CPU/memory consumption right now, but it seems pretty minimal, so I’m really pleased I have an alternative I like. My wish list is insanely small:

    1. A ‘click to refresh all feeds’ button, instead of relying on cron/command line(I could probably code this myself, just haven’t yet)
    2. Auto-refresh of the page resets the read/unread counts correctly

    And the ‘fix’ for now for those is cron/cli and refresh the page. So I’ll live, quite happily.

    Tiny Tiny RSS lives at http://tt-rss.org but they’re also on GitHub.

  • Don’t Use WWW

    Don’t Use WWW

    It was asked why I don’t recommend using www in your URL for Multisite in WP Multisite 101.

    To quote me:

    You should not use www in your URL
    A lot of people complain about this. The simple fact is that any well built server will automatically redirect www.example.com to example.com seamlessly. By removing it from our install, we avoid any possible conflicts with subdomains. Your SEO will not be impacted.

    What I didn’t say, but I told the fellow with the question, is that some servers see www as a subdomain, and not an ‘alias’ (for lack of a better term) of example.com, which is my main reason for not using it. I’ve also seen a very rare, but infuriating, problem where, after upgrading, a site that happens to use www in their URL can no longer get to the network admin page, and instead gets a redirection loop. Since this only happens with www in the URL, and never when it’s not, it’s safer to drop the www.

    I’ve never yet heard a good technical reason to use it, though I do totally accept ‘But I like it!’ as a justification. Everyone has a preference. I don’t feel that the www makes your site more or less professional, mostly because I don’t think anyone really looks except, maybe, you. As long as the redirect is seamless, the user will never notice, and 99.999% of them won’t care. Yes, Google and Facebook both use the www, though newer sites like Tumblr and Twitter don’t. WordPress doesn’t, but I’ve been advocating no-www longer than I’ve used WordPress.

    My technical reasons for not using it stem from the No WWW guys.

    By default, all popular Web browsers assume the HTTP protocol. In doing so, the software prepends the ‘http://’ onto the requested URL and automatically connect to the HTTP server on port 80. Why then do many servers require their websites to communicate through the www subdomain? Mail servers do not require you to send emails to recipient@mail.domain.com. Likewise, web servers should allow access to their pages though the main domain unless a particular subdomain is required.

    Succinctly, use of the www subdomain is redundant and time consuming to communicate. The internet, media, and society are all better off without it.

    To explain what that means, www used to be the protocol to say ‘If data comes for www.example.com, it’s web traffic.’ Similarly, mail is the protocol for email, and mail.example.com sends traffic to your mail server. You could email me at mail.halfelf.org. And the point of all that all web browsers today know that http://example.com is a website. In fact, you can just type example.com into any browser, and it’ll know ‘Oh, this is a website.’ How does it know that? Because you’re in a web browser.

    It’s like when you dial a phone number, you don’t have to press a button to say ‘Phone number.’ Look at your cell phone. If you open up your text messaging app, enter a cell phone number, and send a message, the phone magically knows ‘This is a text!’ and sends it. But if you open the phone app and enter the exact same number, it knows ‘This is a phone call!’ You, the user, have to do nothing.

    That www in your URLs is telling the browser something it already knows. It’s redundant, it takes up space, and it’s unnecessary.

    Now people I respect, like Michael Hampton, maker of Bad Behavior (my out and out favorite add-on to any PHP web app), is the brain behind Yes WWW. His counter argument concludes with:

    The main reason I argue for leaving the www. in URLs is that it serves as a gentle reminder that there are other services than the Web on the Internet. Some of these, such as FTP and DNS, users typically use transparently without even realizing it. Others, such as e-mail, users access through separate applications. Even so, I know of many users who will claim with a straight face that e-mail is not part of the Internet.

    While I disagree (mostly since, if that holds true, we should use mail.example.com and so on), the question comes up that if we’re not using www, how do we differentiate between http://example.com and ftp://example.com in cases where they’re not on the same server? You can, easily, redirect ftp.example.com to a different IP, if needed, via DNS. Thankfully, there are some easy answers to this. First, you can route the requests via ports. If a request comes via FTP, that’s a different port, send it to the other server. What you can’t do, however, is serve HTTP and FTP over the same port, but … you shouldn’t do that anyway.

    There are many personal reasons to use www or non-www, and they are all perfectly valid. But there’s on big technical reason I would never consider it on a Multisite install of WordPress. Once in a blue moon, after an upgrade, someone finds out they can’t get to their network admin. This is, normally, due to a miss-match in URLs, where they’ve put http://example.com and http://www.example.com for their site and home URLs, back before they turned on Multisite. Fixing that is a monumental effort, and it doesn’t always take. (This is probably related to http://core.trac.wordpress.org/ticket/9873 now that I think about it.) Also, even more rare is the case where just having the www forces your subdomains to be subdomain.www.example.com.

    Both situations are frustrating. Both are avoidable by using just http://example.com

    As long as you redirect the www to non-www, your users will never notice. Except the geeks like me. And while we may disagree, it’s unlikely we’ll stop using your site over something that trivial. Go www free. It’s the way to be.

  • Phishing Games

    Phishing Games

    One night, not so very long ago, I got a scam email that reminded me how few people actually pay attention to these things. It’s funny, but we’re all pretty lazy about these scams. You rarely get them from your real banks and money places anymore, or they’re very obviously not real, so you ignore them. Far more people fall for cold-calls on their cell, you know, like ‘This is Mary from Cardmember Services, calling about…’ And I always just hang up. But with so many emails, a lot of us blindly follow them. We click a link, we go to the site, and we don’t think.

    This not thinking lead to a few WordPress developers being phished. This is not being ‘hacked’, this is a simple ‘You accidentally gave someone your password’ type mistake. While sites do the best they can to protect you from yourself, we can’t stop you from posting with your real name and not your handle (someone did this recently and asked me to remove the post, which I did), and we can’t stop you from not paying attention.

    So we repeat this over and over again. Read the email, look at the site you end up on, use your brain.

    Here was the email I got (one of three copies, from two separate email addresses):

    Dear WordPress Plugin Developer,

    Unfortunately, a plugin you are hosting has been temporarily removed from the WordPress repository. We’are going to manually review your plugin because it has been reported for violating our Terms of Service. If your plugin is not approved by this review then your plugin will be permanently removed from the WordPress repository.

    You can check if your plugin has been approved or rejected at

    http://wordpress.org/extend/plugins/my-plugins-status/

    Four things were wrong with this.

    1. The email did not come from plugins@wordpress.org – the only official email for plugin yanks.
    2. The email didn’t come from someone I know on the pluginrepo ‘team.’
    3. None of my friends who work for WP poked me directly (and I’m fairly sure Otto, Nacin or Mark would have).
    4. The email source showed the wrong URL.

    I quickly did a few checks on the email source, traced it back, verified it wasn’t WordPress, posted on the forums, and alerted the masses. Because ignorance is where this sort of thing festers. I’m a little impressed, though, since I’ve not seen a phishing attempt aimed at WordPress like this before.

    Clearly it’s time to go over a quick reminder about what phishing is, it’s goals, and how it works.

    Phishing is when you try to get someone else’s login credentials by mimicking a real site, so you can log in as them and do naughty things. It works by having people not pay attention to a URL when they go to a site. PayPal was an early hit on this, and they finally said “We will never send you an auto-login link or a link to our site in our emails. Just go to paypal.com and log in.” I don’t know if they still do it, but it was a very smart idea.

    Too often we blindly trust our emails. The email appears to come from our bank? We click the link, log in, and … hey, it didn’t work? Banks are a huge target for this, and as I work for one, I’m very familiar with making sure we’re not phished. I mean, an email like this looks pretty safe right?

    That link, if you’d clicked on it, would take you to a fake site. Now some of those fake sites are smart, and when you enter your ID and password, will redirect you to the real site’s bad password page! That would make you think you only typoed, which happens to all of us.

    You may have noticed that most banks and money-type places have you enter your username and then take you to a page with a picture and a passphrase. As long as those are yours, you know you’re on the right site. That helps take care of a lot of attempts, but when you’re faced with something like a phishing attempt on WordPress, there’s less security because there’s less at stake. A bank can make it annoying and inconvenient to log in and get your money and you’ll put up with it because, well, it’s your money. You’ll put up with a lot to get to your money.

    But if you have to jump through the same hoops to log in to a forum, or check in code to open source, you’d probably walk away. This is a complicated problem, trying to balance out the needs of the many and the protection of all. I’m not going to delve into possible answers, since they’re always going to be specific to your community.

    Also, you can usually easily spot the fake emails. Here’s one I got today:
    Fake Delta Email

    This came from “Delta Air Lines – support_8312@delta.com” which looks ‘legitish’, but as soon as you look at the email body, it seems weird. No real airline sends out your tickets in a ZIP file for one. Without looking any further, I know this is fake and I can delete it. But what if they’d sent a link? Would I have clicked on it? Again, no, since I’ve only been to Newark twice in my life, and I know I’m not going any time soon, but that’s not the point. The point is the email would have been less off if there’d been a link. If I’d really been concerned, I would have looked at the email headers, but before we jump into that, let’s review what you can do!

    The rules to not be phished:

    1. Look at the URL before you enter your password and ID.
    2. Copy and paste those URLs, never click.
    3. If the email looks ‘off,’ don’t click.
    4. If there’s an attachment and there isn’t normally, delete the email.

    That’s really the best you can do for most people. The rest of us, though, can go the extra level. When you get that weird email, the one that looks just a little off and hits your spider sense, view the email source, which looks like this:(This is the actual header from the phising email, by the way. You can see the whole thing here)

    Return-path: 
Envelope-to: ipstenu@ipstenu.org
Delivery-date: Sat, 24 Mar 2012 18:14:57 -0500
Received: from blu0-omc4-s14.blu0.hotmail.com ([65.55.111.153]:4132)
	by gamera.ipstenu.org with esmtp (Exim 4.77)
	(envelope-from )
	id 1SBaAh-0001wn-Sk
	for ipstenu@ipstenu.org; Sat, 24 Mar 2012 18:14:56 -0500
Received: from BLU0-SMTP348 ([65.55.111.135]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
	 Sat, 24 Mar 2012 16:14:54 -0700

    By the way, notice how this came from Hotmail? 1990 called, it wants Nirvana back. WordPress emails don’t come from Hotmail, and I really hope that I’m not about to get a comment from someone at Automattic about how they still use it. Hotmail is like an AOL account. You’re not old school, you’re living in the icky past.

    Now in that email, once you have the raw source, you scroll down to the body of the email and see this:

    <HTML><HEAD>
<META name=GENERATOR content="MSHTML 8.00.7601.17744"></HEAD>
<BODY>
<P>Dear WordPress Plugin Developer,</P>
<P>Unfortunately, a plugin you are hosting has been temporarily removed from&amp;nbsp;the WordPress repository. We&amp;nbsp;are going to manually review your&amp;nbsp;plugin because it has been reported for violating our Terms of Service. If your plugin does not get approved then it will be permanently removed from the WordPress repository.</P>
<P>You can check if your plugin has been approved or rejected at</P>
<P><A href="http://wordpresss.comule.com/bb-login.php">http://wordpress.org/extend/plugins/my-plugins-status/</A> </P>
<P>&amp;nbsp;</P></BODY></HTML>

    I don’t know about you, but something’s fishy in that email. comule.com has nothing to do with WordPress, we have a winner.

    How do you see your raw source? For most email apps, select the message, go to the view menu and look for ‘message’ or ‘message source.’ If there are further options, like in mail.app, you want ‘Raw Source.’ Outlook has it under options, I believe. Once you get that view, just take the time to look at the ‘content’ of the email. If you’re extra paranoid, you can even turn off your email’s ability to automatically render HTML, so you’d see that right away (I actually no longer do that because of the values in HTML emails).

    Now you know how to protect yourself just a little bit more. What are your best anti-phish-tips?

  • Alfred.app

    Alfred.app

    My friend Trepmal loves Alfred.app. Since she touts it, I decided I should try it.

    What I Had To Do

    Generally I use Spotlight to search for things. I type in ‘Transmit’ and hit enter and there it is. To make myself use the alt-spacebar of Alfred, I knew I had to hide that from my menu bar. Thankfully, that’s pretty easy. Run these two commands in Terminal.app and the magnifying glass is gone:

    $ sudo chmod 600 /System/Library/CoreServices/Search.bundle/Contents/MacOS/Search
    $ killall SystemUIServer

    Now I start to move the mouse up there, see it go, and know to alt-spacebar it.

    What I Like

    It’s fast and it’s versatile!

    What I Don’t Like

    One of my (few) issues with it is Growl. I just don’t like Growl. There’s something about how it pops up that bangs away at my ADHD/OCD nature and makes it harder to pay attention to anything. Instead, I like apps that change color in my doc, or on my menu bar (think how the Twitter icon goes blue when you have something to pat attention to). That catches my eye in a non-demanding way, which is what I need most of the time. When I need pop-up replies, or audio/visual alerts, each app (Skype or my IRC app) has settings I can refine to give me just what I need.

    Sadly, some of Alfred.app’s code needs Growl to pop up and alert me of things. I wanted a whois extension, so I could type in ‘whois xxx.xx.xxx.xxx’ and get back ‘That’s foo in blah.’ All the extensions I found use Growl. Trepmal asked me what I’d rather use, and I said “I really don’t know.” And I don’t. A terminal window would probably be fine, but the problem is Growl really does fit the bill here. It pops up, you click and it goes away, and it’s not another app running.

    Still, everything else about it I really like. Once I solved my (silly) problem with not showing contacts, which was entirely my fault, I’ve been having a blast.

    http://twitter.com/Ipstenu/status/179683776497061888

    Right now, I’m using it instead of spotlight. I’ve started using the basic calculator, and I picked up the Power Pack for more goodies.

    Suggestions for how best to use it? Lay it on me!

  • Once GITten, Twice SVN

    Once GITten, Twice SVN

    I’ve been putting off learning git. I’m lazy, svn works fine what what I need, and … oh. Look. MediaWiki switched to git. This is a problem for me, because I upgrade my MediaWiki install via svn. When it comes time for a new version, I just run something like svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/ and I’m off to the races. But now I have to git off my ass and learn it.

    Before someone asks, I use svn to update my code because I like it better than wget-ting files, unzipping, and copying over. I can certainly do that, but I prefer svn. It runs fast, it lets me see what changed, and it’s easy for me to back out, just by switching back to the previous version. It never touches my personal files, and I’m happy. The more I looked at git, and how it works, I started to wonder if this was a practical idea for upkeep anymore.

    Now, I actually like git for development when you’re working with a team. It’s great. So any posts about how I’m stupid for wanting to do this weird thing will just be deleted. Constructive or GTFO. The rest of this post details the journey of going from ‘This is what I do in svn, how do I replace it with git?’ The tl;dr of it is that I can’t.

    What I want to do

    I want to check out a specific branch (or tag) of code and upload it to a folder called ~/www/wiki/

    That’s it.

    The road…

    First up, I have to install git on my server. Unlike SVN, which has been bog-standard on servers for a hog’s age, git is the new kid in town, and the odds are it’s not on your server. Thankfully, my host had note perfect directions on installing git on CentOS 5.(I’ll probably upgrade to CentOS 6 this summer, when my sites are less busy.)

    Second I have to ‘install’ the git repository. This was weird. See, I’m used to svn, where you check out code, use ‘svn up’ to upgrade it, or ‘svn sw URL’ to switch to a new branch/tag. The official directions for gitting MediaWiki were: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git

    That doesn’t tell me what version I’m getting, and I only want the latest stable release. It was unclear at this point what this cloning did, but I was told over an over that I had to clone to get the version I wanted. Thankfully, git knows a lot of us are in the WTF world, and have a nice crash course for SVN users. Most important to me was this:

    So git clone URL is svn co URL and that’s how I first installed MediaWiki. But… I know MediaWiki is working on a million versions and I’m not specifying one here. The git doc goes on to say that for git, you don’t need to know the version, you use the URL and it’ll pull the version named ‘master’ or ‘default.’ That basically means I’m checking out ‘trunk,’ to use an svn term. This is exactly what I do not want. I have no need for trunk, I want this special version.

    After more reading I found git checkout --track -b branch origin/branch which they say is the same as svn switch url which is excellent. I can also use git checkout branch to check out the specific version I want!

    I’m very used to SVN, where I can browse and poke around to see the tags, branches, and so on. When I go to https://gerrit.wikimedia.org however, all I see are the latest revisions. The directions said I should get the file /r/p/mediawiki/core.git which makes me presume that’s what tells git the version I’m checking out, but I can’t see that. I don’t like obfuscation when I’m checking out code. After some digging, I found the URL I wanted was https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git and that shows me the files, and their tags.

    The tags were important for the command I wanted to run: git checkout tags/NAME where NAME is the tag. I want version 1.18.2, which is the latest stable, so I want to do is git clone -b tags/1.18.2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git

    I tried it with pulling a copy of 1.18.1, and it ended up pulling about 89 megs and put it in a subfolder called ‘core’. Oh and it told me it couldn’t fine tags/1.18.2 and used ‘HEAD’ instead, which put me on bleeding edge. It took a while to find something that looked a little better:

    cd ~/www/wiki/
git init
git remote add -t REL1_18 -f origin https://gerrit.wikimedia.org/r/p/mediawiki/core.git
git checkout REL1_18

    In theory, that would get me the latest and greatest of release 1.18, be that 1.18.1 or 1.18.2 and then, when 1.19 was released, I could switch over to that by doing this: git checkout REL1_19

    It was time to test it! I pulled REL1_17 and … ran out of memory. Twice. fatal: Out of memory? mmap failed: Cannot allocate memory happened right after resolving deltas. Everyone said ‘You need more swap memory’ but when I looked, it was fine (not even using half). So that was when I said ‘screw it, I’ll go back to tarballs.’

    Just as I hit that wall, some Twitter peeps stepped in to explain that, no matter what, I have to clone the whole archive first. I’m not really happy about it. I like SVN, since even when I switch, it’ll only update my changed files. I wanted to be able to do that in git without needing to pull down the whole repo, since I only use it to update, and not develop.

    And that there is my one and only issue with git. It’s entirely for developers. Sometimes, some of us just want to pull down the latest version to play with, and not the bleeding edge. With git, I have to clone the repository, then export the version I want to play with. That’s not optimal for what I want to do. On the other hand, I totally get why it’s done that way. It’s akin to the basic svn check out, where I get all the branches and tags, only much much cleaner. And that’s cool! Smaller and leaner is fantastic.

    And yet I’m not a developer in this instance. I don’t need, or want, the whole release, just a specific stable release. So now my workflow would be…

    Install

    On Git:(Of note, every time I try to run checkout I get “fatal: Out of memory, malloc failed (tried to allocate 1426604 bytes)” and I get the same thing when I try to archive. If I use the tool to change memory allocation, it also fails … out of memory. I’m taking this as a sign.)

    mkdir ~/mediawiki/
cd mediawiki
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git .
git checkout 1.18.1 -f
cp -R ./mediawiki /home/user/public_html/wiki/

    On svn: 

    mkdir ~/www/wiki/
svn co http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/

    Upgrading
    On Git:

    git pull /home/user/mediawiki/
git checkout 1.18.2 -f
cp -R ./mediawiki /home/user/public_html/wiki/

    On svn: 

    svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_2/phase3/ ~/www/wiki/

    You see how that’s much easier on svn?

    Now, someone wanted to know why I like this. Pretend you’re trying to test the install. You often need to test a specific install version, say version 1.17.1, against some code to see how far back something was broken. Being able to quickly pull that, without coding any extra steps, is crucial to fast testing and deploying. The tool we use at my office required me to reverse engineer and script a way to do that with an ant script, and certainly I could script all that here. It’s not even that hard. But what’s one line in svn is three in git, on it’s best day, and you’re always pulling the latest and reverting back to the one you want, which seems a little silly.

    Now, someone pointed out I could use this: git checkout-index -a --prefix=/home/user/public_html/wiki/ When I read the man page, it doesn’t say you can pick a tag/branch to push, though. If you have some advice on how to fix that, I’ll give it a shot, but I suspect my memory issues will block me.

    I will be using git for a lot of things, but a fast way to update, spawn versions, and test will not be one. For development, however, I totally adore it.