If you want to be to quickly install something, or try something out, but not pollute your environment, then docker is a great way to do that. Here is a one line command that will start new docker bash terminal (and mount the current working directory inside the docker container):
docker run -v $(pwd):/opt -w="/opt" --rm -it debian:latest bash
Add this to your .bashrc file as an alias so it can be run very quickly any time:
alias dock='docker run -v $(pwd):/opt -w="/opt" --rm -it debian:latest bash'
Customizing Your Container bash:
If you are often running this, then you might might find it handy to have your own custom .bashrc file mounted inside the container, so that all your aliases, and other settings are available by default. You can do this by simply mounting your .bashrc file.
-v $(echo ~)/.config/.docker_bash:/root/.bashrc
Naturally “/.config/.docker_bash” would be the path to your file .bashrc file that you want to use inside the container.
So the full command that I use myself:
alias dock='docker run -v $(pwd):/opt -w="/opt" --rm -v $(echo ~)/.config/.docker_bash:/root/.bashrc -it debian:latest bash'
I will be giving a talk about how we use serverless (AWS Lambda, API Gateway, etc…) at the AWS Stockholm event (May 3rd 2017). My talk is on the “Deep Dive on Serverless Stack” track. Presentation starts at 15:00 in room A 2.
For my part I will be going into:
AWS Lambda and how we use AWS SAM to make deployment easier
Amazon API Gateway integration with AWS Marketplace
How aws-serverless-express makes our lives easier
A few tips and pointers from our serverless adventure
Feel free to ask questions or come up to me after the presentation, I will hang around for a while to answer questions.
Just a tip, in order for API Gateway test / sandbox area to be able to execute (invoke) a Lambda function that was generated by CloudFormation, you need to explicitly grant the Sandbox permission in your CloudFormation file. As it is not documented and there is currently no way to “export” a manually created API as CloudFormation file, it is easy to overlook/miss. The simple solution for this is to add a new Lambda permission, with the “stage name” set to “null”.
Here is a complete example of a Lambda Permission Resource in CloudFormation:
If you are using Nginx as a reverse proxy and trying to inject client certificates you may run into a Server 400 “No required SSL certificate was sent” error. I spent a few hours debugging this issue and thought I’d share my findings. The problem is fairly subtle and easy to over look/miss, numerousotherpeople have ran into it. The problem is that the backend server is using SNI (Server Name Indication, basically allows multiple SSL/TLS certs on a single IP). You must explicitly tell Nginx to pass forward the domain name in the TLS handshake, so that the final destination (your backend) knows which SSL/TLS cert to serve.
Following the Nginx proxy documentation, you would set the required directives and expect it to work, so your configuration might look something like:
Just renewed my SSL certificate thanks to StartSSL (using their very nice and fairly straight forward automated system), it got me thinking on all the issues that I have encountered and heard about in regards to SSL certificate and domain renewal.
In a previous job there was an incident where a SSL certificate expired, this went unnoticed (it was a analytics service, not a core service) for 5 weeks, not too bad right? Well, unfortunately due to an additional oversight in the client code, if a request failed, it would retry the request after a time out of 0.5 seconds, indefinitely!. This lead to hundreds of thousands of clients hammering the (auto-scaling) load balancer with requests that were dropped as SSL verification failed. The end result, a large bill that could have been avoided. This issue is hardly unique, even the largest cloud providers have been hit by similar issues (see Windows Azure Service Disruption from Expired Certificate or Google.com domain getting transferred or Microsoft losing its Hotmail domain).
It is hard to have a universal list of best practices as it is dependent on the size of the organisation, but some good ideas:
Avoid single point of failure, never have an SSL cert (or domain name) associated with an individual developers email address. Instead use a specific mailing list.
Monitoring, even secondary services (that are considered ‘best effort’), need active monitoring.
Monitoring results should be sent to mailing list not a specific individual
When setting up monitoring, don’t forget about monitoring costs as well as uptime!
Consolidate all domain and SSL certs with a single trusted provider
Purchase with a Company credit card with auto renew
What best practices would you recommend? What bullets have you dodged (or got hit by!)? Any services out there that you use to avoid issues?
Note 2016/12/07: Since this article was written PIA have updated their config. While I have not personally tested this out, some commentators have reported success by doing 2 additional steps:
With the new CA file, you now need to specify the port under VPN settings (1198).
Specify encryption (AES-128-CBC) and authentication (SHA1).
Configuring OpenVPN to work on OpenWRT is relatively easy and straight forward, just not very well documented. This is an in depth, step-by-step guide to configure OpenVPN (VPN provider Private Internet Access – commonly called PIA) on an OpenWRT router.
You already have OpenWRT installed on your router
You know how to connect to your router via SSH and Web panel
Router is connecting to another device (Modem, other router, direct to ISP) that is supplying internet access
This tutorial will cover:
Installing and configuring OpenVPN
Configuring a network interface
Setting up some firewall rules & DNS Leak protection
Verify everything works
First step, open a SSH connection to your router, login as root. You should see something like Figure 1 below.
Figure 1 – SSH Login
Next we have to update packages and installed some required libraries, enter the following commands in the terminal:
Next, download the OpenVPN config files from PIA – https://www.privateinternetaccess.com/openvpn/openvpn.zip somewhere to your local machine. Extract all the files from the zip file. You are only interested in 2 files (ca.crt and crl.pem, we will get back to them later). You can safely delete the *.ovpn files.
Now open your broswer and go to your router web panel, by default this should be: http://192.168.1.1
Once logged in you should notice a new menu item called Services, goto it and click the OpenVPN option, see Figure 2 below.
Figure 2 – OpenVPN menu
Time to add our new configuration. At the bottom, in the text field, enter a new name “pia_client”, select “Simple client configuration for a routed point-to-point VPN” and click Add button (Figure 3)
Figure 3 – Create config
You will immediately be taken to the config page, click the link “Switch to advanced configuration”
Figure 4 – Advanced Menu
All settings on the Service page should be fine. Click the “Networking” link at the top.
See Figure 5 below for how the settings should look like. A few notes:
If there is a line missing, use the “Additional Field” drop down at the bottom, select the missing field and press Add button
Ensure that “dev” is set to “tun” and not “tap”
If there is a field called “ifconfig” with an IP address, remove the address (i.e. make field blank)
Figure 5 – Networking configuration
Click blue Save button on the bottom
Now click on the “VPN” link to change to the VPN tab. As in Networking, there will be some fields missing, use the “Additional Field” drop down at the bottom again to add them. A few notes:
“auth_user_pass” field value should be “/etc/openvpn/userpass.txt” (It doesn’t exist yet, but we will get back to it in a few minutes)
The “remote” field should be the hostname of which ever exit node you want to use – see PIA Networking page for a complete list.
Figure 6 – VPN configuration
Now click on the “Cryptography”. As before, use the “Additional Field” drop down at the bottom to add missing fields.
IMPORTANT: for the “ca” field, you will need to browse to the location of the ca.crt file from the openvpn.zip you downloaded in step 3.
The “crl_verify” path should be set to “/etc/openvpn/crl.pem”
Figure 7 – Cryptography configuration
We have the VPN configuration done now, but we still need to configure the interface as well as the Firewall.
From the Menu at the top select Networking -> Interfaces.
Click the “Add new interface…” button.
Name: “PIA_VPN”(IMPORTANT: Name must be exactly this)
Protocol of the new interface: Unmanaged
Cover the following interface: Custom Interface: tun0
Figure 8 – Create Interface
Enter in the details and click the Save button.
For the final few steps, we will switch back to SSH.
Next we have to create a file that will store your PIA username and password. It is just a simple text file, with first line username and second line your password. Then we will chmod it to set correct permissions.
Figure 9 – Create username and password file
Now have to add the crl.pem file (from the openvpn.zip), just open it in a text editor like notepad and copy the contents
Figure 10 – Create CRL file
Now we need to setup some firewall rules to forward the VPN traffic
In order to protect against DNS Leaks, we need to update the DHCP server to supply the PIA DNS servers instead of your ISP’s DNS.
From the main menu, goto: Network -> Interfaces -> LAN -> DHCP Server (below the “Common Configuration” section) -> Advanced Settingss. In the “DHCP-Options” field enter the value: “6,126.96.36.199,188.8.131.52”.
Click “Save & Supply”
Figure 11 – Interfaces – > LAN
Figure 12 – DNS settings
All done! Now we can start the VPN connection.
Goto: Services -> OpenVPN, check the Enabled checkbox beside our”pia_client”, then press the Start button, your VPN should now start up.
While playing around with Flux & React I ran into some issues using a yoeman flux generator. It kept failing on “node-gyp rebuild”. If you do any development on Windows you’ve likely run into issues with node-gyp before. The core of the problem is that node-gyp is no longer being actively developed and so it has some old dependencies that a modern development env might not have.
node-gyp rebuild failed
How to fix?
Goto Control Panel -> Programs and Features and uninstall “Microsoft Visual C++2010 x64 Redistributable” and “Microsoft Visual C++ 2010 x86 Redistributable” (if present)
Download and install Python 2.7.3 (if you have Python 3.x already installed, just leave it, both can coexist)
This post has been updated (on 2016/11/20) to reflect recent changes (version 0.3.2)
I got a few emails from people asking how to use the original Photobox Downloader. The initial idea of the app was to provide a clean API to allow people to interact with their Photobox account, however it seems that people just want a quick and easy to download their photos! With the new V2 version, you can much easier download your photos, no editing of files needed!
Installation & Usage
$ npm install -g photobox-downloader
$ mkdir albums
The new version will now prompt you for the 4 required items:
The domain that your photos are on (www.photobox.ie, www.photobox.co.uk, etc…)
The Authentication cookie value (see below for more detailed instructions)
The directory where to store the files (this directory must exist already!)
Whether to skip files, if they already exist inside the above folder (for resuming interrupted downloads)
Once you enter this info it will immediately start downloading all your photos.
How to get authentication cookie value?
When you log into your account on Photobox, Photobox sets an authentication cookie, first step is to log into your Photobox account, open the Developer Toolbar (press F12), goto the “Application” tab (Chrome), expand the “Cookies” drop down. Click on the base domain (e.g. https://www.photobox.ie), copy the value of the cookie called “pbx_www_photobox_ie” (the last part, “_ie”, will change depending on your domain).