WiredTron

Setting up TP Link Kasa Devices without Smart Home app

2023-11-28T00:00:00+00:00

Kasa plugs and switches are some of the best smart home devices on the market and have been for many years. One of their most attractive attributes is the existence of a local LAN API that can be interacted with. Even though this use is not officially supported by Kasa, in recent years they have gone from actively blocking local access to more or less accepting it and even fixing bugs that arise when users use their switches exclusively offline. For me one of the biggest annoyances was manually having to do setup and configuration through their app, so I did some digging to see if there was a better way, and luckily there is! In this post I will walk you through the steps to take a Kasa smart plug from out of the box to fully configured. This was tested using a HS103 running firmware 1.0.6 (which is what is came with from the faactory) but I have used these same commands against HS220 and other switches as well and they have all worked.

A big thanks to softScheck for posting a full list of commands on Github.

Setup the TPLink CLI

In order to use these commands you will need a somewhat recent version of node. Once you have node, you will need to install the tplink-smarthome-api using npm install -g tplink-smarthome-api. This API has a lot of commands available, all of which can be listed by running tplink-smarthome-api --help.

Connect to the Device

When the device is plugged in it automatically creates a network containing the last 4 of it’s MAC address at the end. This network is unsecured so you can just connect to it with your computer. In my testing, the devices always come up with the IP 192.168.0.1 but you can verify this information by running ifconfig (or ipconfig on Windows). Once you are on the devices network you can finalize setup.

Setup the Device

Use the TPLink smarthome CLI to query the device by running tplink-smarthome-api getInfo 192.168.0.1. This information includes the MAC address which I use to assign a static IP in my router.
(Optional) Before connecting it to your network you can give it a name by running tplink-smarthome-api setAlias 192.168.0.1 'Device Name'.
Run tplink-smarthome-api send 192.168.0.1 '{"netif":{"set_stainfo":{"ssid":"<ssid>","password":"<password>","key_type":3}}}' to set your WIFI. This will cause the device to automatically disconnect and join the specified WIFI network.

From there you can jump back over to your WIFI network and send commands directly to the device at it’s IP address on your network. For example, to turn the device on/off run tplink-smarthome-api setPowerState <new-ip> 1 to turn the device on.

And that’s it, enjoy managing your devices without an app!

Setting up a ratgdo + Homebridge with MQTT

2023-11-25T00:00:00+00:00

With the recent lockdown of the myQ APIs, I recently became very interested in alternative options. After having easy garage door control for a few months from my watch or phone, going back to not having this control didn’t seem like a very appealing option. For my specific garage door opener I found there were 2 options that were supported, Meross and ratgdo. I ended up choosing the latter since it was able to natively interface with my garage door opener and didn’t require me to run any additional sensors and could read the current door state directly. Since the ratgdo does not yet have native Homekit support, I went ahead and utilized my Homebridge installation that I already have running for other devices in my home. As a note, this guide will no longer be relevant once homekit-ratgdo is more mature. With that out of the way, lets get started.

Step 0 - Homebridge

This guide assumes you already have a Homebridge server running on your network. If you do not there is very good documentation on how to get that setup on https://homebridge.io/.

Step 1 - Setup Mosquitto MQTT Server

I was not very familiar with MQTT before this so at first I did not realize that it would be necessary for me to run a separate MQTT server, since ratgdo does not bundle it’s own. In order to overcome this I went ahead and installed Mosquitto on my Raspberry Pi that also runs Homebridge. This was as simple as running

sudo apt install mosquitto

You can optionally also install the mosquitto-clients package if you would like to be able to inspect the contents of the queues. Once this is complete you can check the service status by running sudo systemctl status mosquitto.

Ratgdo requires your MQTT server to have username and password authentication setup. In order to enable authentication I created a file at /etc/mosquitto/passwd with the following contents:

homebridge:YourUnencryptedPassword
garagedoor:YourUnencryptedPassword

Note: Change the passwords above and make a note of their values, you’ll need them later.

I then ran sudo mosquitto_passwd -U /etc/mosquitto/passwd to hash the password into the form that mosquitto expects.

Next up I had to update /etc/mosquitto/mosquitto.conf and append the following 3 lines:

password_file /etc/mosquitto/passwd
allow_anonymous false
listener 1883 0.0.0.0

The password_file is the one we just created. The allow_anonymous setting disables anonymous access, and the listener specifies that mosquitto is available on port 1883 to any machine on our local network.

Step 2 - Flash the ratgdo

The next step was flashing the firmware to the ratgdo. This step took the longest for me only due to the fact that I could only find charging only micro USB cables. Make sure the cable you are using is a data USB cable. The installation guide also mentions a driver that potentially needs to be installed but things seemed to work fine for me without the driver installed, so I believe the driver is bundled on Windows and Mac. Flashing happens completely through the browser and can be done here.

After flashing you will be prompted to setup your wifi network. I currently have this running on an isolated network without internet access and have added a firewall rule allowing access from the ratgdo to the MQTT server. You know your network better than I do so I won’t add much more here.

Next up, configuring the ratgdo. Once the device is flashed you can navigate to the IP address of the ratgdo on your network and you will be greeted with a configuration screen. Below is a screenshot of my current configuration.

Note that the IP is my Homebridge/MQTT IP, and the username and password combination are the one from the /etc/mosquitto/passwd file we setup above. I have my MQTT topic prefix set to /home/ since ratgdo automatically adds the device name to the MQTT prefix. This means the resulting queue name in my case is /home/garagedoor/status/availability for the availability queue.

One final note, it seems that providing a bad MQTT configuration here can cause the ratgdo to hang causing it’s configuration webpage to become inaccessible. In my case this was fixed by adding a firewall rule allowing traffic between my 2 subnets.

Step 3 - Install the ratgdo

This one will vary a bit based on your setup however the instructions on how to do this can be found here.

Step 3- Setup Homebridge

Note: A big thanks to ozpaulb and specifically this comment for providing basically everything I needed for this section.

In order to connect Homebridge to MQTT, you will need the Homebridge MQTT-Thing plugin. I use the Homebridge UI so this was just a matter of searching for the plugin and clicking install. Once the plugin is installed you will need to add an accessory to your config file for your garage door. The accessory block in my homebridge config now looks as follows:

"accessories": [
  {
    "type": "garageDoorOpener",
    "name": "Garage Door",
    "url": "mqtt://127.0.0.1:1883",
    "username": "homebridge",
    "password": "<your password>",
    "logMqtt": true,
    "topics": {
      "getOnline": "/home/garagedoor/status/availability",
      "getCurrentDoorState": "/home/garagedoor/status/door",
      "getDoorMoving": "/home/garagedoor/status/motion",
      "getLockCurrentState": "/home/garagedoor/status/lock",
      "getLockTargetState": "/home/garagedoor/status/lock",
      "setLockTargetState": "/home/garagedoor/command/lock",
      "getObstructionDetected": "/home/garagedoor/status/obstruction",
      "setTargetDoorState": "/home/garagedoor/command/door",
      "getTargetDoorState": {
          "topic": "/home/garagedoor/status/door",
          "apply": "if(message == 'opening') message='open'; if(message == 'closing' || message=='closed') message='close'; return message;"
      }
    },
    "doorCurrentValues": [
      "open",
      "closed",
      "opening",
      "closing",
      "stopped"
    ],
    "doorTargetValues": [
      "open",
      "close"
    ],
    "lockValues": [
      "unlocked",
      "locked"
    ],
    "doorValues": [
      "open",
      "closed",
      "opening",
      "closing",
      "stopped"
    ],
    "accessory": "mqttthing"
  }
]

Go ahead and update the username and password to match what you set above in step 1 in mosquitto. In my case since my Homebridge server and MQTT server are running on the same host I was able to specify mqtt://127.0.0.1:1883, if you are hosting yours on different machines then you will need to update the IP accordingly.

That should be it, enjoy taking control of your garage door once again!

Using chrome debug tools to debug flaky Capybara system tests

2022-11-15T00:00:00+00:00

Chrome debug tools are super useful when trying to debug an issue while running Capybara system tests. In order to debug this failing test I really wanted the Chrome devtools Network tab open in order to see what requests were going between the server and browser. Unfortunately in my case the tests had to be run many times in order to reproduce the failure, and the Chrome network tab only begins logging requests after it is opened. This means unless the Network tab was opened right when the test began there was no way to see the traffic I was curious about. In order to achieve the desired result I ended up registering a new Capybara driver with the following config:

Capybara.register_driver :chrome_with_network_tab do |app|
  options = Selenium::WebDriver::Chrome::Options.new(args: %w[auto-open-devtools-for-tabs])
  options.add_preference(
    'devtools',
    'preferences' => {
      'currentDockState' => '"bottom"',
      'panel-selectedTab' => '"network"',
    }
  )

  Capybara::Selenium::Driver.new(
    app,
    browser: :chrome,
    options: options,
  )
end

I then ran my failing test in a loop until it failed:

while true; do                                                                    
    bundle exec rspec ./spec/system/spec_that_fails_spec.rb:<line number of failing spec>
    if [ $? -ne 0 ]; then
        break
    fi
    sleep 1
done

At this point I was able to see all of the network requests and was able to narrow down the problem. If you prefer a different dock location or need a different active tab, feel free to change the setting to fit your needs.

Using twilio-video.js with esbuild

2022-03-28T00:00:00+00:00

ESBuild is an extremely fast bundler for javascript. Unfortunately speed doesn’t matter if your app doesn’t work! While migrating from Webpacker to esbuild with a Rails 7 application I ran into an issue where esbuild would compile successfully, however the twilio-video.js library (and accompanying twilio-ruby gem) were not able to startup. The error was as follows:

Uncaught ReferenceError: process is not defined
...

This is happening due to a call to require('twilio-video') which expects process.env to be available globally. There is a good writeup on the cause of this in an issue on twilio-video.

The trick to working around this issue with esbuild is to leverage the @esbuild-plugins/node-modules-polyfill package. It provides a polyfill for built-in modules for the browser meaning things that would not normally be available inside a browser will still work. Below is how I included this using an esbuild configuration file.

esbuild.config.mjs:

import NodeModulesPolyfills from '@esbuild-plugins/node-modules-polyfill'
import esbuild from 'esbuild'

esbuild.build({
  entryPoints: ['app/javascript/application.js'],
  outdir: 'app/assets/builds',
  plugins: [NodeModulesPolyfills.default()]
}).catch(() => process.exit(1))

From there, I was able to execute esbuild using the command node esbuild.config.mjs and twilio-video.js was once again working successfully..

Setting up a Content Security Policy for Ruby on Rails Applications

2021-02-19T00:00:00+00:00

A Content Security Policy(CSP) is an important piece of mitigating multiple different types of attacks including XSS, Clickjacking, and other various types of code injections attacks. It does this by informing the end-users browser to not make requests or perform actions that don’t meet the CSP. Unfortunately, writing a generic CSP is not possible, and instead requires the developer to analyze their requirements and make appropriate exceptions before rolling out a CSP. In this article I will cover two sections: overall observations, and examples of Ruby on Rails specific gotcha’s I encountered along the way.

Overall Observations

My first step in writing a CSP was to enable the default one which Rails provides, and inspect what errors I received on the console. I was greeted with a few errors right away that looked very strange, which I quickly realized were not related to the application. They were caused by extensions which I had installed, specifically Vue Devtools and React Devtools. This lead me to my first takeaway: Use Private Browsing mode when testing your CSP to ensure the errors you are seeing are relevant!

Second, I noticed that the CSP messages in Firefox were not quite as helpful as the ones in Chrome. I ended up having a lot more luck tracking down the root cause of CSP issues in Chrome than in Firefox.

Rails-Specific Observations

There are 4 gems and 1 javascript code block I had to refactor as part of this exercise. I will include a link to my full set of changes at the end of the article since this was done on an open source project. Note that testing changes to your CSP in rails is slightly annoying since you need to reload the server after every change, since the CSP is saved in an initializer. If you feel like your changes aren’t taking effect, this is probably the reason.

Code Refactoring

Rewriting Inline Scripts

CSP Settings

The default CSP in rails looks as follows (any items commented out were done by me):

# Be sure to restart your server when you modify this file.

# Define an application-wide content security policy
# For further information see the following documentation
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Rails.application.config.content_security_policy do |policy|
  policy.default_src :self, :https
  policy.font_src    :self, :https, :data
  policy.img_src     :self, :https, :data
  policy.object_src  :none
  policy.script_src  :self, :https
  policy.style_src   :self, :https

# Specify URI for violation reports
# policy.report_uri "/csp-violation-report-endpoint"
end

# If you are using UJS then enable automatic nonce generation
Rails.application.config.content_security_policy_nonce_generator = -> request { SecureRandom.base64(16) }

# Set the nonce only to specific directives
Rails.application.config.content_security_policy_nonce_directives = %w(script-src)

# Report CSP violations to a specified URI
# For further information see the following documentation:
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only
# Rails.application.config.content_security_policy_report_only = true

In this application, //= require jquery_ujs was included, so I went ahead and enabled the content_security_policy_nonce_generator feature. The only caveat was I also had to enable the content_security_policy_nonce_directives setting and limit it to only apply to script-src since all of the Chartkick inline styles broke and there was no straightforward way to pass the nonce to stylesheets.

Nonce Helpers

First of all, what is a nonce? A nonce is a one-time-use code which is changed every time the page is refreshed.

With the settings in the previous section enabled, it was necessary to modify the code in a few places to use the nonce. Specifically the following was the diff of the lines change in my application.html.haml:

+ = csp_meta_tag
- = javascript_include_tag "application"
+ = javascript_include_tag "application", nonce: true

The csp_meta_tag adds the a new tag to every page, and the nonce: true adds that same nonce to the javascript assets tag, for example:

<meta name="csp-nonce" content="Zp+yENSM5K9BKStdB22IbQ==" />
<script src="/assets/application-1798ca4812645a78f896665e43c690d14f965504736ca9fe705e2d59cce6d622.js" nonce="Zp+yENSM5K9BKStdB22IbQ=="></script>

This same nonce is accessible through the content_security_policy_nonce method and an example is used later on in the file.

Gems

Bootstrap 3

Bootstrap adds an inline style to navbar dropdowns. In my case the line:

%button.navbar-toggler{"aria-controls" => "navbarSupportedContent", "aria-expanded" => "false", "aria-label" => "Toggle navigation", "data-target" => "#navbarSupportedContent", "data-toggle" => "collapse", :type => "button"}

was throwing an error stating that the inline style

color: #fff

was not able to be applied. I was not applying a custom style to the navbar with an inline style, so this must be something that Bootstrap 3 adds on. Chartkick (below) also requires inline styles enabled, so I fixed this by ensuring the following was set in my CSP.

policy.style_src   :unsafe_inline, :self, :https

jQuery Rails

This application was relying on an old version of jQuery without realizing it. In our application.js there was an include for //= require jquery. This was causing an error inside jQuery itself on the following lines:

// Support: IE<9 (lack submit/change bubble), Firefox (lack focus(in | out) events)
for ( i in { submit: true, change: true, focusin: true } ) {
  eventName = "on" + i;

  if ( !( support[ i ] = eventName in window ) ) {

    // Beware of CSP restrictions (https://developer.mozilla.org/en/Security/CSP)
    div.setAttribute( eventName, "t" );
    support[ i ] = div.attributes[ eventName ].expando === false;
  }
}

It turns out the jquery-rails gem includes jQuery 1, 2, and 3. I found that switching to //= require jquery2 or //= require jquery3 fixed the issue.

Chartkick

Chartkick has a really good writeup on what is required to make it work with CSP: chartkick CSP guide

In my case, I already had to enable unsafe_inline styles across the whole application due to Bootstrap 3, so this setting in conjunction with adding Chartkick.options[:nonce] = true to config/initializers/chartkick.rb solved all of my Chartkick issues.

reCAPTCHA

The documentation for reCAPTCHA states that whitelisting a few domains is required in order to allow reCAPTCHA to work with CSP enabled. This does not reflect what I experienced. I added invisible_recaptcha_tags nonce: content_security_policy_nonce (note that I am using the ambethia/recaptcha gem and afterwards reCAPTCHA worked fine for me. The nonce used here pulls in the same nonce that is added as described in the nonce helpers section above.

Code Refactoring

Rewriting inline scripts

There was one instance of an inline script which used data from the controller to show the time remaining countdown. In order to still pass the data needed into Javascript, I had to add the data to a data attribute. The transformation can be seen from here to here.

Resulting CSP

With all of my investigation completed, I found the following CSP worked best for the application:

# Be sure to restart your server when you modify this file.

# Define an application-wide content security policy
# For further information see the following documentation
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Rails.application.config.content_security_policy do |policy|
  policy.default_src :self, :https
  policy.font_src    :self, :https, :data
  policy.img_src     :self, :https, :data
  policy.object_src  :none
  policy.script_src  :self, :https
  policy.style_src   :unsafe_inline, :self, :https
end

# If you are using UJS then enable automatic nonce generation
Rails.application.config.content_security_policy_nonce_generator = -> request { SecureRandom.base64(16) }

# Set the nonce only to specific directives
Rails.application.config.content_security_policy_nonce_directives = %w(script-src)

Relevant commit: mitre-cyber-academy/ctf-scoreboard

Expanding LVM Storage with Proxmox 5.2

2018-07-28T05:00:00+00:00

Proxmox is an Open Source virtualization solution that provides very easy installation at an irresistible price point. The biggest issue I have encountered so far after messing with it for 2 days is its lack of customization for installing across multiple drives. My initial goal was to have a setup that I have accomplished before with ESXi where I have a main drive and a secondary storage drive. In this setup, the main OS drive contains my OS and the secondary drive stores the VMs. Unfortunately, after the installation completed I found myself with both the root and data stores built on the main drives. This meant that I didn’t have enough space to store my ISOs or VMs. In order to fix this I needed to extend both the data and root volumes. Fortunately this is not my first go with LVM. The steps I used are as follows:

Open up fdisk for the secondary drive, in my case this was fdisk /dev/sdb. You will need to choose d to delete any partitions on the disk and then w to write changes.
Run sgdisk -gN 1 /dev/sdb in order to convert this disk to GPT format. the -g option here even if If sgdisk finds a valid MBR or BSD disklabel but no GPT data.
pvcreate /dev/sdb1 initializes Physical Volume for later use by the Logical Volume Manager.
vgextend pve /dev/sdb1 extends the pve volume group (which all 3 Proxmox volumes are a part of) to include the newly allocated Physical Volume.
This step can be adjusted as needed. For my use case I decided extending my root volume by 80g was sufficient, so I ran lvresize -L +80g --resizefs /dev/pve/root. If you need more space, go ahead and change that 80g to something else.
I then allocated the rest of my space to the data volume for my VMs, using the command lvresize -l +100%FREE --resizefs /dev/pve/data.

Setting up Raspberry PI with Huawei E397u-53 dongle on Metro PCS

2018-07-07T05:00:00+00:00

The Huawei E397u-53 dongle is a low cost dongle which is available on Amazon for around $20. It is possible to get it working on startup on a Raspberry PI, and there is some very good documentation which I will mention in the credits of this post. Even with the documntation I was able to find, I still hit a decent number of roadblocks during setup.

First up, I am going to summarize the actual steps I used, which are mostly the same as the one from the first blog post. I opted to use the NDISDUP method since WvDial is slower and harder to reliably bring up on startup.

Also as a note, most blog posts mention needing to mess with usb_modeswitch. As of the time of this posting, with Raspbian 9 (Stretch) on a Raspberry PI 3 Model B version 1.2 this was not necessary since the device already showed up on /dev/ttyUSB0

Install screen using sudo apt-get install screen and then run screen /dev/ttyUSB0
This will put you in a console that will look hung. If you type AT and hit enter you should get a response of OK back.
In the new console, type AT^NDISDUP=1,1,"<APN>" where <APN> is the APN for your carrier. In my case it was fast.metropcs.com.

You will now need to install libqmi-utils. Unfortunately this is where I ran into the biggest issue. The current version of libqmi-utils in Rasbian has a bug (see 2nd link in credits) where you will get an error stating:

sudo APN=fast.metropcs.com /usr/bin/qmi-network /dev/cdc-wdm0 start
Loading profile at /etc/qmi-network.conf...
 APN: fast.metropcs.com
 APN user: unset
 APN password: unset
 qmi-proxy: no
Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-format '...
error: couldn't create client for the 'wda' service: QMI protocol error (31): 'InvalidServiceType'
Device link layer protocol not retrieved: WDA unsupported
Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network=apn='fast.metropcs.com'  --client-no-release-cid '...
error: couldn't start network: QMI protocol error (64): '(null)'
Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 1)
error: network start failed, no packet data handle
Clearing state at /tmp/qmi-network-state-cdc-wdm0...

In order to workaround this, I first removed the version of libqmi-utils I installed by running sudo apt remove libqmi-utils and then reinstalled it from source by running

wget http://www.freedesktop.org/software/libqmi/libqmi-1.16.0.tar.xz
tar -vxf libqmi-1.16.0.tar.xz
cd libqmi-1.16.0
sudo apt-get install glib-networking libmbim-glib-dev libgudev-1.0-dev
./configure --prefix=/usr --disable-static
make && sudo make install
sudo qmi-network /dev/cdc-wdm0 start

Once I was able to verify that sudo qmi-network /dev/cdc-wdm0 start worked, I went ahead and rebooted the machine. From there I then edited /etc/network/interfaces.d/wwan0, replacing <APN> with my APN settings and added

allow-hotplug wwan0
iface wwan0 inet dhcp
  pre-up for _ in $(seq 1 10); do /usr/bin/test -c /dev/cdc-wdm0 && break; /bin/sleep 1; done
  pre-up for _ in $(seq 1 10); do /usr/bin/qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength && break; /bin/sleep 1; done
  pre-up APN=<APN> /usr/bin/qmi-network /dev/cdc-wdm0 start
  post-down /usr/bin/qmi-network /dev/cdc-wdm0 stop

I was then able to reboot the PI and the networking came up successfully.
At this point everything was working, however I did not have any DNS resolution. In order to fix this I had to edit /etc/resolv.conf.head and add
```
#OpenDns Servers
nameserver 1.1.1.1
nameserver 1.0.0.1
```

Credits:

https://robpol86.com/raspberry_pi_project_fi.html This article got me about 90% there, the biggest issue being the current version of libqmi-utils being broken.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845979 This bug report tipped me off to roll the libqmi-utils version back to before 1.16.2.
https://gist.github.com/alvaro893/f5b8dd026eb98959e8c6c59a45b63cc2

Using Packer vmware-iso builder on Ubuntu 16.04 server with Workstation Player 14

2017-10-19T15:59:42+00:00

Getting VMWare Workstation Player 14 (the free one) to work with Packer on Ubuntu 16.04 is possible and not very difficult, however it is very undocumented. In order to get it working you will need a few different packages, listed below

Packer (Download the Linux 64-bit version, at the time of this guide the latest version is 1.1.1)
VMWare Workstation Player 14 (I downloaded the version for Linux 64-bit from the previous link)
VMWare Vix 1.17 (I downloaded the version for Linux 64-bit from the previous link)
In order to build kernel modules you will need to sudo apt install libxt6 libxtst6 libxcursor-dev libxinerama-dev build-essential
Install additional dependencies by running sudo apt install qemu-utils libxi6

Install packer by downloading the zip and moving the packer executable into /usr/local/bin. Next, download the VMWare Workstation Player 14 bundle and install it by running sudo sh VMWare-Player-14.bundle . Finally, download the VMWare Vix bundle and install it by running sudo sh VMWare-Vix.bundle .

Next you will need to run sudo vmware-modconfig --console --install-all to install all of the required kernel modules.

You should now be able to do packer builds using the vmware-iso builder on your headless machine running Ubuntu 16.04.

If the execution fails here with an error such as “Error: The operation was canceled”, then run packer with the command PACKER_LOG=1 packer build -debug <yourpackerfile>.json which will allow you to step through each step of the packer build and pause before cleanup to inspect the logs written to your output directory, which is normally output-<vmname>. Inside that folder will be a vmware log file which should give you some hints towards what is going wrong.

Credits:

https://kradalby.no/setup-vmware-player-headless-on-debian.html got me the final undocumented step required to setup vmware-modconfig kernel modules.

Enabling Poltergeist inspector while using capybara accessible + cucumber rails

2017-04-25T18:51:45+00:00

I know this is a very specific toolset to be using and doesn’t affect many people, however it took me some time to get it working so it seems that it may be worth documenting. If you are working on a project that uses rails + cucumber + capybara accessible + poltergeist for automated in browser tests and want the ability to use the poltergeist remote debugging feature then you are in luck. Add the following to your features/support/env.rb

Capybara.register_driver :poltergeist_debug do |app|
  driver = Capybara::Poltergeist::Driver.new(app, inspector: true)
  adaptor = Capybara::Accessible::SeleniumDriverAdapter.new
  Capybara::Accessible.setup(driver, adaptor)
end

Next update your Capabara default_driver and javascript_driver to use your newly registered driver:

Capybara.default_driver    = :poltergeist_debug
Capybara.javascript_driver = :poltergeist_debug

Once the above code is inserted you can then follow the instructions on the poltergeist wiki on how to attach to the remote debugger.

Setting up MaaS + Juju on one Node on Ubuntu (using Virsh)

2016-08-18T12:17:30+00:00

Using MaaS and Juju to deploy Openstack on Ubuntu is pretty easy to do, however often requires a large number of machine sitting around in order to host everything. Fortunately it is possible to run your Juju controller alongside your MaaS machine using virsh. For the purpose of this guide we will be using MaaS 2.0 and Juju 2.0.

First you will need to install MaaS and get it working. In my case I have 2 interfaces, my private interface which is managed by MaaS and my public interface which is managed by my router. My initial config looked as follows:

# The loopback network interface

auto lo

iface lo inet loopback

# MaaS network interface

auto eth0

iface eth0 inet static

address 172.16.0.1

netmask 255.255.0.0

# The primary network interface

auto eth1

iface eth1 inet dhcp

This config worked fine for commissioning machines inside MaaS, however it failed when I went to create a virtual machine on my MaaS node to run Juju. In order to get virtual machines working I had to do the following:

Install virsh and other required packages:

sudo apt-get -y install libvirt-bin linux-image-extra-virtual kvm virt-manager

Add the MaaS user to the libvirtd group:

sudo usermod -G libvirtd -a maas

Update my networking config to look as follows:

# The loopback network interface
auto lo
iface lo inet loopback
iface enp9s0f0 inet manual

# The primary network interface
auto enp9s0f1
iface enp9s0f1 inet dhcp
auto br0
iface br0 inet static
bridge_ports enp9s0f0
address 172.16.0.1
netmask 255.255.0.0

After updating your config, reboot the MaaS machine! This step is very important as networking will not work until this step is completed.

Finally, I was then able to spin up a virtual machine using the following command:

virt-install \
–name Juju-Controller-Node \
–ram 8192 \
–disk path=/var/kvm/images/Juju-Controller-Node.img,size=150 \
–network=bridge:br0 \
–vcpus 4 \
–os-type linux \
–os-variant ubuntu16.04 \
–graphics none \
–pxe \
–accelerate \
–boot network

Success! The node then showed up in MaaS. I then configured the power settings on the newly added machine to look as follows:

I was then able to commission and deploy the node successfully.