]> Posts for October 2019 🌐:aligrant.com

UniFi controller Java versions on Linux

Alastair Grant | Monday 7 October 2019

This is not the first time I've had trouble starting Ubiquti UniFi Controller on Linux.  I rarely use the controller in my home network, it's Java so resource intensive and only necessary if I need to reconfigure an access point.  Which is exactly what I wanted to do, but instead I was presented with in my systemd log:

unifi[31974]: WARNING: An illegal reflective access operation has occurred
unifi[31974]: WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils$2 (file:/usr/local/bin/unifi/lib/spring-core-3.2.8.RELEASE.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],i>
unifi[31974]: WARNING: Please consider reporting this to the maintainers of org.springframework.cglib.core.ReflectUtils$2
unifi[31974]: WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
unifi[31974]: WARNING: All illegal access operations will be denied in a future release

Seems like something has changed and Java isn't too happy about it.  Indeed, it has, UniFi is only supported on Java 8 - the JRE that won't die and is largely unsupported (Java 13 being the current version at the time of writing).

Still, the fix is relatively easy, you need to install a Java 8 runtime on your system.  This is usually available through your distribution's package manager.  You will then need to narrow down where the new JRE has been installed, in my instance it was: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/bin/java

You will need to update your systemd unit file (or whatever you use to launch) to point to the new (sorry, old) version of Java.  e.g.

ExecStart=/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/bin/java -jar /usr/local/bin/unifi/lib/ace.jar start
ExecStop=/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre/bin/java -jar /usr/local/bin/unifi/lib/ace.jar stop
Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

Enabling bitlocker hardware encryption

Alastair Grant | Friday 4 October 2019

Microsoft have recently adjusted the way Bitlocker will encrypt drives in light of some shockingly poor implementations of hardware encryption on hard drives/ssd.

The long and short is many SSDs from major manufacturers can have their enyption bypassed due to things such as default passwords. To protect us, Microsoft now assumes your drive is compromised.

But what if you're confident that your drive isn't impacted? How do you elect to use hardware encryption? Group policy of course.

  1. Run gpedit.msc
  2. Navigate to Computer Configuration; Administrative Templates; Windows Components; Bitlocker Drive Encryption; Fixed Data Drives.
  3. Here you can set the "Configure use of hardware-based enyption for fixed data drives"
  4. Enable the policy
  5. Deselect software-encryption
  6. Reboot for Good measure

 

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.

Entries for: October 2019

Previous