Since I heard of Phoenix, the Elixir framework on The Changelog Podcast, I’ve spent some time getting familiar with the framework.
However when time came to deploy the application onto Heroku there were a couple of things that weren’t initially obvious to me, like how to run brunch to compile the assets or how to parse the DATABASE_URL environment variable.

Buildpacks

First we have to change the currently used buildpack to the multi buildpack which makes it possible to run the Node.js besides the Elixir buildpack.

Compile the assets

Now that we have multiple buildpacks we need to tell the Node.js one to run the postinstall hook after all the dependencies are installed. Just add the scripts part to your package.json and you’re all set for Heroku to run the brunch build command.

Parse the environment variable

When deploying the application to Heroku, the configuration variables will be exposed to the application via environment variables. For the database that means there will be a single String from which the username, password, host, etc. will have to be extracted. You could theoretically do that by hand defining those variables individually, however what happens if your database provider has an issue and suddenly decides to change the value behind your environment variable? - in order to avoid that, just put the code below in your prod.secret.exs file to help you split the configuration variable for the database.

While starting on a new project the other day I decided to automate as much as possible. One of those tasks was deploying to Heroku when pushing the master branch to Github. It took me some time to figure certain parts out, even though the documentation is quite extensive; guess it being a beta feature didn’t help.

Start by going into the Settings > Webhooks & Services view and add the HerokuBeta Service.

Create the app on Heroku via the command line heroku create myapp

Fill in myapp as the Name in the HerokuBeta settings view and leave Github api url empty.

Then for the Heroku token, you’ll need your Heroku api token, which you get via heroku auth:token (eg. token123) and your email address you’re using to login to Heroku (eg. [email protected]). Then convert the two into a base64 hash for the Authorization header by issuing this command on a Unix system echo "[email protected]:token123" | base64 (eg. base64-123).

For the Github token follow the instructions and head to https://github.com/settings/applications where you can click Create new token, then give it a name and leave the default settings before hitting Generate token. Then copy this token and fill it into the form.

Save the configuration with Add service.

I first thought the hook is already working, however it’s only working with Github deployment events, which you can add by adding another service called Github Auto-Deployment.

Repeat step 5 to acquire a new Github token and add it there, save and from now on your automatic Heroku deployment should be fully working.

Personal NAS-es are quite handy, however their wide spread usage and the fact that people don’t often check their system via the web dashboard makes it a perfect target for crackers trying to extort you for money or just using your machine to mine bitcoins for them.

In this case I had a DS213j delivered to me with SynoLocker on it. A malicious piece of code that encrypts all your files and holds them hostage until you give in and pay them what they ask for. Please don’t ever give in. Just accept that your data is lost forever and you hopefully have a backup of it somewhere else, if not, now would be a good time to start thinking about one.

So on that basis, the fix is fairly trivial.

Open the lid and take out all of the drives.

Put one into a desktop computer or use a S-ATA to USB docking station to connect it to a working machine so you can format the drive with FAT.

Put the one drive back into the NAS and boot it up.

As soon as it’s booted, reset it by taking a paperclip and pressing the reset button on the back for 4 seconds until it beeps. Release. Press again for 4 seconds until it beeps again for 3 times. This will initiate a restart.

If your NAS isn’t already showing up, give it some time to finish the booting process and then click the search button in the Synology Assistant.

Double click on the entry for your NAS which will open a browser window.

Download the latest Diskstation Firmware (DSM) from the Synology Download Center and go through the questions in the browser.

Upload your firmware and let the NAS re-format your disk, then give it some time for it to re-install.

When all is done, format all the other drives with the same process you used for the first drive. Shutdown the NAS and put them back in. Restart and go into the Storage Manager > Volume where you can add the newly inserted drives to your volume. Once added it will take a while for them to be added and re-index, partitiend, etc., you can safely use your NAS from now on however.

Now you might want to re-add your video, music and photo folders. That’s it.

On a further note, since crackers were able to get into your NAS once, I’d ask yourself whether you really need external access to it and otherwise make sure there are no ports being forwarded by your router. Also I recommend changing your router password, especially in case it’s still the factory default one. If you really do need remote access, at least change the ports which are used externally, eg. map 3001 to 5000 internally.

Lastly, I’ve used automatic DNS updating services quite a bit too, however they could have been the enabling party for the attack. Once such a provider is compromised, crackers can check their attacks against all your ports which makes the previous advice in-effective. Since routers nowadays don’t change their ip addresses that much I usually look up my home address via the GMail login history and use the naked IP. Less convenient, but more secure.

Hope this short summary helped during your reset and it’s the last time something like that happened.