Dev With Imagination

I recently moved my Unifi controller off of my Proliant MicroServer and on to a Raspberry Pi, which is powered via PoE from my main Unifi USW-Lite-16-PoE switch. This evening this Pi was unresponsive, and unlike on the MicroServer there is no out-of-band interface I could use to restart it. If this did not host the Unifi controller I could have used the controller to power-cycle the PoE port, but as the controller couldn’t be accessed either I needed another approach. While I could have just got up and went under the stairs to pull some cables, it would be preferable to be able to solve this via SSH.

There are many posts on the Unifi community forums with solutions for this involving telnet after connecting to the switch via SSH, but telnet is not available on the newer devices like the USW-Lite-16-PoE.

I came across this reddit post which pointed me in the direction of the swctrl poe command.

To list the PoE status of the ports on this device that support PoE:

NetworkRack-USW-Lite-16-US.6.2.5# swctrl poe show id 1-8
Total Power Limit(mW): 45000

Port  OpMode      HpMode    PwrLimit   Class   PoEPwr  PwrGood  Power(W)  Voltage(V)  Current(mA)
                              (mW)                                                               
----  ------  ------------  --------  -------  ------  -------  --------  ----------  -----------
   1    Auto        Dot3at     32000  Class 2      On     Good      1.38       53.24        26.00
   2    Auto        Dot3at     32000  Unknown     Off      Bad      0.00        0.00         0.00
   3    Auto        Dot3at     32000  Class 4      On     Good      3.40       53.11        64.00
   4    Auto        Dot3at     32000  Unknown     Off      Bad      0.00        0.00         0.00
   5    Auto        Dot3at     32000  Unknown     Off      Bad      0.00        0.00         0.00
   6    Auto        Dot3at     32000  Class 4      On     Good      6.81       53.24       128.00
   7    Auto        Dot3at     32000  Unknown     Off      Bad      0.00        0.00         0.00
   8    Auto        Dot3at     32000  Class 3      On     Good      4.63       53.24        87.00

This doesn’t include any of the port labels, but at a guess the highest current draw is likely the Pi that has hung.

This port can be turned off by running swctrl poe set off id 6, then switched back on with swctrl poe set auto id 6.

As a word of caution with this though - originally I had ran swctrl poe set off 6 (note the missing id between off and 6). This is the incorrect syntax, so it ignores the number and turned PoE off on all ports of the switch. This was a problem for me as the Wifi Access Points were also powered by this switch so I needed to go reconnect with a cable to re-enable PoE for the access points too.

I have recently been revisiting my home server setup and moving more “core” tools onto Raspberry Pis as opposed to my ageing HP MicroServer. As part of this, I had been checking if the way I had things set up was still a good way to go.

Up until last week I was using ddclient for updating a DNS record in Cloudflare with my home IP address for the (now rare) cases where I need remote access back into my home network. I had always found it strange that the Dynamic DNS options in Unifi did not support Cloudflare.

Now there is the Cloudflare DDNS for UniFi OS project.

Cloudflare Worker script that exposes a UniFi-compatible DDNS API to dynamically update the IP address of a DNS A record.

With this I can deploy a (free) Cloudflare worker that the Unifi OS can call to update my DNS record without requiring to run additional service containers on my local network.

I did initially have some problems setting this up (which have now fixed by a PR), and this blog post was very helpful in providing commands that could be ran from the USG-3P to force Dynamic DNS updates while I was testing changes: Configuring Ubiquiti UniFi USG to use Namecheap DDNS.

As part of ongoing maintenance and releases to application servers, I needed a quick way to determine the versions of various components to check if they were up to date or not.

Ideally what I was after was a shell command I could run against one or more components to extract version information, as ultimately this check would likely be run via an SSH session from a central management host.

This one-liner can do what I needed:

$ unzip -p component.jar 'META-INF/maven/*/pom.properties' | grep '^version=' | cut -d '=' -f 2
0.1.5-SNAPSHOT

Note that this may return more than one version number if the component is a fat or shaded jar file. If you at least know some of the groupId you can be more specific in the file path to extract the version from. The pom.properties file is always located in META-INF/maven/<groupId>/<artifactId>/pom.properties.

unzip -p component.jar 'META-INF/maven/com.devwithimagination*/*/pom.properties'

Around a year ago I published part 2 of this series, providing an approach for restricting the dependencies which could be downloaded through a Nexus repository server.

One struggle that became obvious when trying to implement this approach at scale is that you are required to approve all the transitive dependencies down the chain too. NPM projects especially become unreasonable to maintain quickly. As an example one of my pretty basic Homebridge plugins has a total of 15 dependencies between dependencies and devDependencies - after deduplication the dependency tree has more than 800 items. That is not maintainable through Nexus content selectors.

A different approach, which does not prevent downloading, is to integrate checks into the code quality analysis performed by SonarQube. There are no rules built in to do this though, so a custom plugin was required.

» Continue reading

I have now moved fully to using the openapi-generator for generating code from OpenAPI specifications, instead of the “official” swagger-codegen. This fork, by some of the original maintainers, has a much more active community & development pace over the original project. My PR to improve tag support in swagger-codegen is still sitting with no activity more than 6 months on.

Using tags as part of generation has been supported for all JAX-RS based generators as of version 5 of openapi-generator. I am using this through through the maven plugin, which correctly integrates with maven to add generated sources to the sources paths. We use this with the generate goal linked to the maven lifecycle so code generation is performed in every build of the project, so we can be sure that the code in the produced artefact reflects the specification in the repository.

The maven plugin has very detailed documentation with all the configuration options available for it, but going into this it is worth noting that some of the terminology is different between the two forks of the plugin. This is reflected in the documentation. Individual generators are documented here.

» Continue reading