APIs are the 21st centuries new lever, as in: “Give me a place to stand and I will move the earth”


oops, i just wanted to save title and image as draft, but as i’m still tinkering with setting up this new blogging environment it got published accidentally and somehow made it to twitter where it got favorited. Fast paced social media world. Anyhow, to not let the tweet link into the nowhere I updated this yet non-written post to be public.

Once I put my insights organized I’ll update this.

ok, ok, not all things work, but we have DNS now at least!

and thats not bad! as you might have seen I revived my old blog from its 2008 SQL database dump. Today I tried moving it back to its old domain. In short, so far the steps where reloading old sql backup to mysql in docker, wordpress in docker upgrading database, exporting from wordpress as XML, importing XML to blog instance on https://sofasportler.wordpress.com/. Now I want to be reachable under it’s old domain htttp://sofasportler.de/.

The “normal” way with WordPress.com seems to be ordering the domain with them. But also when you already own the domain they have an option, its call “map” your domain. Sounds good, so i went that way (13euro per blog per year). Problem is, in the next step they ask you to change your nameserver to the ones from wordpress.com, which i didn’t want because i use AWS route53 for DNS.

So heres what i did. First i asked (and payed) to map my sofasportler.de domain to sofasportler.wordpress.com, but did NOT continue to change the sofasportler.de nameserver over to wordpress.

Than i moved over to Amazon Route53 to add an A record to make sofasportler.de resolve to the sofasportler.wordpress.com IP. Now https://sofasportler.de/ is working, but what is with http://www.sofasportler.de? The missing link is to have someplace where to redirect http://www.sofasportler.de to sofasportler.de. This place is AWS S3, the have the redirect feature to host static websites directly from S3.  To do so, you need to have an AWS S3 bucket, what i created for http://www.sofasportler.de. Once you have it, you can find out its endpoint, in my case something like www.sofasportler.de.s3-website.eu-central-1.amazonaws.com. This endpoint is what you add as target in the AWS route53 entry for http://www.sofasportler.de. Still with me? Last step is, adding the redirect all traffic to sofasportler.de for the http://www.sofasportler.de bucket, this is an AWS S3 feature.

Once all this is in place, it works like this:

  1. go to http://www.sofasportler.de/
  2. resolved to S3 bucket,
  3. bucket gets hit, redirects to sofasporler.de
  4. sofasportler.de resolves sofasportler.wordpress.com
  5. wordpress.com sees in coming request for sofasportler.de and happily serves the blog,

and http://sofasportler.de just starts with step 4 of course.

still missing, comments and some image links, but i still have to look into this,

makes sense? I’m not sure, hacked this together in a rush, not sure whether there might be a more reasonable setup. But hey, back from the dead, and that’s ok, for now.

keep pushing,

resurrection, kind of, or how to rebirth an old wordpress blog database,

hi folks, i’m back ;)

taking an old mysql database backup from August 2008 of my blog and running it in a docker container’ed wordpress to upgrade it to wordpress 4.3 from where i exported it and than imported it to the wordpress.com site (this one here) for checking. Amazing technology, me luv wordpress, that was all sooo smooth. I might post some journal of the steps involved for the docker/wordpress interessted ones, but for,


yours, truly

disable DIGEST-MP5 to xmpp4r connect with your openfire jabber server

in my typical love and hate relationship with opensource  (aka open sore) i stumbled over SASL induced configuration pains again today. To cut a long story short, just disable DIGEST-MD5 sasl out on the openfire jabber server and immediatly xmpp4r works like a charm for me.

How to disable digest md5 on Openfire? Not so easy to find out and in a beautiful amateuristic way lots of the advice you find is actually plain wrong.

Put this into your openfire.xml:

<!-- but put it inside the <jive>...</jive> tags somewhere -->

, because when you know the name of the right openfire property, and are able to read(in openfire.xml):

    This file stores bootstrap properties needed by Openfire.
    Property names must be in the format: "prop.name.is.blah=value"
    That will be stored as:

,then you easily know that <sasl><mechanisms>….</mechanisms></sasl> is bogus.

you usually find your openfire.xml at ${OPENFIRE_HOME}/conf/openfire.xml. and you must restart the the server afterwards, like /etc/init.d/openfire restart.

there is another option, like making the xmpp4r implementation don’t even try to use the digest-md5 mechanism which the openfire server offers. Just disabling DIGEST-Md5 acceptance at /opt/local/lib/ruby/gems/1.8/gems/xmpp4r-0.3.2/lib/xmpp4r/client.rb:108 in Jabber::Client.auth does work, but i will try to get it implemented a littel more selective before posting a xmpp4r fix here. Who knows, there even might be two SASL DIGEST-MD5 implementations on this planet which actually do match? i doubt it, an even then, i don’t care. vote for alt.source.sasl-must-die-die-die and

have fun

Technorati Tags: , , , , ,