So you lost your Java Keystore and you need to update your APK on Google Play?

Well…. Not saying I ever did anything as stupid as this, or spent hours fixing things. Yesterday. But say I had, this is exactly what I would have done to fix this.

Disclaimer: These keys were for a pet project of mine and got lost during a reinstall of my OS. I’m much more careful with things like this for actual clients. Anyway.

So you’ve uploaded a build of your app to the Play store some time ago, then come to upload the next version and it complains about the SHA1 checksums not matching. You’ve built with the wrong key!

I wonder where the right one is? Your keys could have a number of file extensions: .jks (which stands for Java Keystore) .keystore .cer for instance. Find your backup drive, or whatever volume said keys are likely to be on and:

find /Volumes/YourDrive/ -name “*.jks”

repeat for other extensions until you get something. Lets see what SHAs those files have:

keytool -v -list -keystore ~/Code/Keystores/Android/your.keystore

Keystores will be passworded. If they’re “debug” keystores, they’ll have been autogenerated by the Android SDK and will have passwords set to “android”. If not, happy guessing…

Any matching strings of numbers and letters there? No? Well lets see what the APK was actually signed with. …presuming you have a copy of it. If not, I think there are various ways to get it direct from the Play Store if you have a Google…

APKs are zip files so:

unzip your.apk
keytool -printcert -file META-INF/CERT.RSA

What doe this show you? You’ll see the SHA1 fingerprint you’ve been nagged about to start with, and also the owner info. That will hopefully give you some clues as to where to search next for your keystore. In my case I had Owner: C=US, O=Android, CN=Android Debug because I was a complete idiot and had signed  the production build with my debug key. I found it in an old ~/.android/ folder on a backup disk. For some reason, the Play store was happy to accept the cert, despite what people say elsewhere. Congratulations: Your debug cert is now your production cert!

Hope that helps someone anyway.

I published my first app to the Play Store!

So a while back I decided to learn a bit of Unity3D. I’ve wanted to make some sort of drawing app for ages and tried various ways round of doing it (this Rails app was my first stab at it).

Anyway, progress has been glacially slow due to coding commitments that actually pay the bills, but I finally made something I was pleased with. Behold: Draww!

Should be a joyous time right? Well:

  1. Looks like I deployed it using my debug keystore, which I didn’t even know was possible. Now debug keystore = production keystore….
  2. Turns out that doesn’t matter anyway, because Google’s search doesn’t allow the extra “w” on the end of my app name unless you enclose it in inverted commas. …and who’s going to actually search with ” ever? No one.

So yeah, back to the drawing board on that one. Perhaps I’ll rebrand it “Swirly Drawing Thing” or something. What a pain. I’d made a logo too!

Anyway. At least I’ve learnt a few things from this complete anti climax…. Next up: A post about keystores!

The perils of “nulled” WordPress themes

Having the largest ecosystem of any CMS ever, WordPress users have a lot of choice when it comes to themes. There’s thousands of open source offerings on as well as many more paid for ones on marketplaces such as Envato.

I recently wanted to assess the code quality of a few different paid themes before deciding on one to buy, so I downloaded some “not quit legitimate” copies from one of the many shady “nulled theme” sites, to run in a sandbox. Obviously you’d have to be a) quite immoral and b) an idiot to use such things in production, but I figured what’s the harm if the winning one’s going to be bought anyway.

After choosing the winner I thought I’d diff the two copies I had. Just how bad was the malware going to be?

Continue reading “The perils of “nulled” WordPress themes”

Repairing buttons on an Elektron MonoMachine

Well, I always thought my MonoMachine was indestructible, but apparently not entirely. ….when one regularly gets carried away hammering the keys as hard as possible over the course of about 6 years anyway. Time to break out that iFixit Kit then!

First, lets pull all the knobs off and undo the 6 screws holding the top plate on. It should come right off. Note the cool old-school circuit boards inside! Here is where the key that came flying off SHOULD have been:

Continue reading “Repairing buttons on an Elektron MonoMachine”

Setting permissions for your Gitlab CI Runner & W3 Total Cache

So in the last post on this, I looked at setting up auto deploy for a WordPress site using GitLab’s CI runner.  I also wanted the W3TC cache to be cleared, and thanks to WP-CLI, that was possible by adding:

- sudo -u www-data wp w3-total-cache flush

to the end of the script node in .gitlab-ci.yml.

Now. “sudo?!?!?!?!” I hear you say? There’s a security risk if ever I saw one. Luckily this doesn’t have to be the case if things are set up right. Make a separate user for GitLab Runner and limit it to sudo-ing as only www-data and only running that command while doing so.

It’s a good idea to setup a separate user in general too, for security.

There wasn’t an awful lot of info on that when I Googled though, so (from inital user creation):

adduser gitlabrunner
usermod -a -G www-data gitlabrunner
passwd gitlabrunner # set a password for your new user
# ...then ssh into the box with that user & pass and:
ssh-keygen -t rsa
# Set a new deploy key in Gitlab admin setting using your new so your new user can "git pull"
vi /home/gitlabrunner/.ssh/authorized_keys
# copy the public key from your GitLab box in. For instance from /root/.ssh/
chown -R gitlabrunner:gitlabrunner /home/gitlabrunner/.ssh
chmod -R go-rwx /home/gitlabrunner/.ssh
# Edit your sudoers file
# add:
gitlabrunner ALL=(www-data:www-data) NOPASSWD: /usr/local/bin/wp 

Done! Your CI script will now be able to run WP-CLI commands as www-data. No root access, no entering passwords.

Using GitLab CI to Deploy WordPress Sites

So I work with a team that use Git to manage all the theme code for a large WordPress site. It’s a corporate, and as is the way with big organisations, they wanted their version control in house. Hence I set them up a GitLab box. Want to make an alteration to CSS or whatever?

  1. Code & test on your local dev stack
  2. Commit via git & push up to Gitlab
  3. SSH into the server, `git pull` the new code down
  4. Run `gulp build` to update the compiled assets

Job done. Wouldn’t it be great if you didn’t need steps 3 & 4 though? They don’t take long in the short term, but get very tedious after a while. They also introduce an element of risk if you have less technical people needing to deploy code that shouldn’t be let loose on the terminal of your production web server…. Hence: GitLab CI to the rescue!

Continue reading “Using GitLab CI to Deploy WordPress Sites”