How to view and move your iMessage history and attachments to a new Mac

2017/02/28

Last weekend I blew away my macOS and did a fresh install from scratch of all the things.

I was disappointed to learn that iMessage on macOS doesn’t preserve its message history. The link below explains how to restore/move your iMessage history.

Source: How to view and move your iMessage history and attachments to a new Mac


How I manage my work and personal GitHub accounts – Tom Limoncelli’s EverythingSysadmin Blog

2017/02/24

This post came through on my Twitter feed yesterday and Im going to implement it in the near future. I’ve been looking for a neat way to manage this issue recently.

Source: How I manage my work and personal GitHub accounts – Tom Limoncelli’s EverythingSysadmin Blog


VMware Fusion 8.5.X – Windows 10 – Shared Folders AWOL

2017/02/22

Updated: 20170228

The problem occurred again. This time, an uninstall and reinstall of VMware Tools didn’t fix the issue.

The fix was to:

  • Open the VMware Fusion Sharing preferences and leave “Enable Shared Folders” ticked but untick all the “Mirrored Folders”.
  • When prompted, log off and log back on.
  • Open the VMware Fusion Sharing preferences and select the folders you want under ‘Mirrored Folders’.
  • You will again be prompted to log off. Log off and then log back on.

The mirrored folders should be accessible again.

Originally:

VMware Fusion has a nifty feature called ‘Shared Folders’ thats lets you access data on the underlying Mac OSX host from within the guest OS. Fusion must be configured to enable it and VMware Tools must be running inside the guest for it to work.

Recently, mine stopped working. I hadnt disabled the feature in Fusion and nothing lept to mind about other changes I could have made that caused the problem.

Today I had some spare cycles to dig into the cause of the problem and find the fix. See the source below from Nov 2015.

TL;DR: Windows Update nerfs a registry value which VMware Tools uses. The fix was simple, uninstall VMware Tools, reboot, install VMware Tools, reboot.

 

Source: Shared Folders – Windows 10 upgrade from 15.11. | VMware Communities


JIRA, Confluence and Lets Encrypt

2017/02/17

I recently had to move a JIRA and Confluence environment to a new infrastructure stack. During the move, we also changed the TLS Certificates and instead of using one of the paid-for incumbents we decided to give Lets Encrypt a go.

Everything with the migration went smoothly. The first hurdle we hit was when we were checking the Application Integration between the two systems. The integration wasnt functioning and no amount of delete, change, recreate would fix it. The admin pages in JIRA and Confluence were both reporting SSL errors. When I dug into the actual Tomcat logs for each instance, the following errors were appearing:

Confluence:

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException
: unable to find valid certification path to requested target

JIRA:

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification
path to requested target

Some quick googlephoo found a few items on the internet about this, not specific to JIRA and Confluence though.

ttps://community.letsencrypt.org/t/will-the-cross-root-cover-trust-by-the-default-list-in-the-jdk-jre/134/3

http://stackoverflow.com/questions/34110426/does-java-support-lets-encrypt-certificates

The root cause of the problem is that the JRE thats included with our version JIRA and Confluence is too old and doesn’t include the Lets Encrypt root keychain in its included keystore. The above articles had references and code snippets to help get the Lets Encrypt certificates into the JRE keystore but they were all very ugly.

Its worth mentioning that Oracle JAVA JRE 1.8.0_101 DOES include the Lets Encrypt certificates.

Options at this point were:

  • Find a way to get the required certificates into the JRE keystore (the CLI method to do this is described in the Lets Encrypt community post above).
  • Install a new JRE on the servers and make JIRA and Confluence work with that. Most likely putting us out of support with Atlassian.
  • Find out if current JIRA and Confluence include the required JRE version and then upgrade JIRA and Confluence. This would need another round of testing to properly do the upgrade.

Moving to unsupported configuration was undesirable and I didnt have the time to properly dive into a new round of testing to see if newer JIRA and Confluence had the required JRE version. I did look for some detail on the Atlassian pages to determine the answer to this and wasn’t able to locate anything.

What I did find on an Atlassian page was this article https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-779355358.html which shows how to use a free JIRA and Confluence plugin to get third party root certificates into the JRE keystore using a simple web page GUI. Some small CLI steps (a cp) are still required after the plug-in does its thing but it does make the fix less likely to fail.

Recommended.