I posted a snarky Twitter message about not wanting to spam the people following me with the features I’m now missing from GTalk, but I now really want to track them so…

Features that are now missing

1. Outside IM clients can no longer send messages to Google+ (aka GTalk, aka GMail) users
2. Outside IM clients can no longer receive messages from Google+
3. Presence updates to/from outside networks not allowed
4. Invisible status is missing
5. Unable to block other Google+ users from seeing my status
6. Contacts are now in whatever order some silly person at Google thinks is accurate/friendly/useful instead of the at-least-it’s consistent alphabetical order
7. The only way to remove someone from the active Contacts list is to … wait for it… block them!

ok, so it’s not the 15 that I said on Twitter but it’s still damn annoying

EDIT:
ok, so I may have been a bit harsh and in a really cranky mood when writing the above – here is a post from the G+ conversation where some of the community members correct me ;)

Buried in a conversation over on this post https://plus.google.com/u/0/107968525907303243288/posts/HFe3W7A9Dor is some comments from +Ben Eidelson about how XMPP support is still in the plans for Hangouts, just either not implemented or buggy.

So it could be that I’m just reacting poorly to some really bad coding and/or product management – don’t get me wrong, i’m still irked.

I just may be restructuring and changing my reaction over the next couple of updates.

Thanks to +Fernando Miguel for pointing that out.

and here is the conversation:

Ben Eidelson May 15, 2013

+Daniel Rose currently those settings affect who causes invites to you, not who shows up for you to send messages to. Once you start using Hangouts for a few days the list should re-order based on who you are contacting most often.

+Thomas Heinen Thanks for your report of the issue. Hangouts supports basic interop with XMPP, so you can-for the time being-continue to use 3rd party clients. It does not work the same way as Talk, and so I believe the issue you’re having with the XMPP bridge will not resolve in Hangouts.

yea, that’s a subtle title alright :/

I posted this earlier on Google+ and decided to cross-post it here as I realized that it was more hipster ironic than I wanted to be (to post about Google changing things on the same G+ stream they are changing things to focus on.)

So here is a cut-n-paste of what I said over there

I just found out the hard way that GTalk on Android has been silently replaced by Hangouts and the do-no-evil geniuses have removed everything dealing with XMPP from it … everything

The “hard way” is from the fact that I did not get a server alert on my phone because Hangouts no longer supports outside messages from XMPP sources (also known as Federation.)

This has me all worked up in a lot of ways:

Personally – a lot of my friends are XMPP users so now I no longer have a single client for my messaging needs and this means that GTalk will not be my primary tool, heck I may not load it at all now.

Professionally – I’m a member of the XMPP Software Foundation and we have been very proud about XMPP being the core of a lot of commercial communication products (Google, Facebook, Microsoft, Cisco and many others) and even tho each commercial entity does odd things (heck, breaks them also) the one thing that stood out was Federation.

Now Google is removing a core part of their messaging and replacing it with something that is not an Open standard and hell, to be blunt, is a horrible implementation of a messaging system. The Hangouts support forum is full of people wondering, like me, what happened to many features they depended on and also asking WTF

So even tho I know Google engineers may not ever see this, I just have to ask: when will you be changing your motto from “do no evil” to “meh, we just do what we want because we are now the new borg”

yea, I’m pissed, pissed enough that I won’t be buying Android as my next phone and I’m going to be putting my full effort behind the infrastructure behind Firefox OS

So, I just did this n00b mistake: rebooted a server without confirming that the saved iptables.rules matched what was currently active. Yep, upon reboot I was getting a weird error when starting one of the services and it turned out to be a test change that should have been persisted.

Two lessons come from this kind of mistake

1. Never make changes to your servers from the command line, and if you have to, always confirm your configuration tool gets updated
2. Before rebooting a server, ensure that your current environment is the same as what the restarted server will use

Now lesson 1 varies depending on what configuration management tool you use, Chef, Puppet or whatever – most of the time in those environments you just simple don’t make local changes – for me I was working on a server for our beta product that I then use as a reference for the configs, but that’s also just an excuse, not a reason :/

Lesson 2 tho, should have been handled by me running some sort of sanity check, and this is the crux of this post – how to sanity check your iptables environment (or at least how I do it.)

So without any further self-flagilation, here is my check_iptables.sh script:

#!/bin/bash

iptables-save | sed -e ‘/^[#:]/d’ > /tmp/iptables.check

if [ -e /etc/iptables.rules ]; then

  cat /etc/iptables.rules | sed -e ‘/^[#:]/d’ > /tmp/iptables.rules

  diff -q /tmp/iptables.rules /tmp/iptables.check

else

  echo “unable to check, /etc/iptables.rules does not exist”

fi

At &Yet I maintain and deploy a lot of little sites that are either mostly static or static with some variation of NodeJS, Python or whatever that lives behind a Nginx reverse-proxy. After the Nginx configuration is done and working, the maintenance aspect kicks in and that usually involves a lot of update/deploy iterations.

The method I’m outlining here to do the update/deploy cycle isn’t anything new or spectacular – heck some will probably critique it as being too simple, but that’s what I was striving for :)

Some assumptions:

1. Your site is in some repository: git, svn or whatever – it just needs to be ssh reachable
2. You have configured a ssh key for deploying (see how github does it)
3. You have an deploy user configured with minimal sudo privs

I will often use a single deploy user on a server if it has multiple sites or a site with multiple repos feeding into a single site – for this you will need to manage your deploy keys because GitHub does not allow you to share a deploy key across repos (it also happens, IMO, to be a good security-minded habit.) Fortunately ssh-agent comes to our rescue!

I add the following to my deploy user’s ~/.profile

SSHENV=~/.ssh/agent-${HOSTNAME}
if [ ! -f "${SSHENV}" ]; then
  ssh-agent > ${SSHENV}
fi
. ${SSHENV}

This will inherit any existing ssh-agent environment or start a new one and then make sure the SSH related environment variables all in place. Once that is in place you can manage your deploy keys using ssh-add.

Now we can create a helper script that handle the details – shown here is a really basic one that is verbosely written to illustrate how many details are available to tweak.

#!/bin/bash
SITENAME=static_site
BRANCH=deployable
DEPLOY_KEY=deploy-site-static-key REPO=git@github.com:foo/${SITENAME}.git
if [ -e /tmp/${SITENAME} ]; then
  rm -rf /tmp/${SITENAME}
fi
mkdir -p /tmp/${SITENAME}
ssh-add ~/.ssh/${DEPLOY_KEY}
git clone ${REPO} /tmp/${SITENAME}
cd /tmp/${SITENAME}
git checkout ${BRANCH}
sudo cp /tmp/${SITENAME}/* /srv/www/${SITENAME}/

Editors Note: I use the “/tmp/${VARNAME}” style out of an old habit of never allowing “rm -rf” to ever have a chance to reference a variable that could expand to “/” – I would rather delete the /tmp tree in that case

Again, the above is not rocket-science or even the latest DevOps craze, but it works and it allows you to encapsulate the deploy knowledge in a way that is also secure and repeatable… and that is always the first step to getting clean automation in place!

Just got back from a couple hours out in the Big Blue Room doing some Spring chores – branch and weed-tree removal, poison ivy clearing and other things that Normals do :)

I have the wonderful(?) ability to not be bothered by poison ivy or spruce and oak only bothers me a bit, so all my neighbors call me when a patch appears in their yards. :) Normally I let some grow along the back fence because I like the flowers and the birds it attracts, but I found out our new neighbors are allergic so I’m having to be more diligent than before to keep it off of the fence. Nothing ruins a good day than having a bunch of kids covered in ivy bumps!

I was also clearing out a junk pile that I had forgotten about and that a critter had dug a burrow underneath over the winter – had to cover the hole with fresh dirt and then check later for signs of activity before moving the pile. Last thing I wanted was to startle some skunk or possum – that just never ends well for both parties.

So yea, a good couple hours of work (which to my woefully out of shape body is a major workout!) and now I’m off to reward myself with a good book on the local pubs patio and a pint or two. mmmmm beer