Press "Enter" to skip to content

Socialized Geek Posts

Unifi Cloud Key and SMTP

TLDR: You can’t test the SMTP email feature of a Unifi Cloud Key from the cloud. You have to connect to the controller directly.

Longer version:
I recently upgraded my wi-fi to a Ubiquiti Unifi system including the Unifi Cloud Key which allows me to connect to, manage, and report on my network via a hybrid cloud service. Everything has been working a treat…except for email notifications. The Unifi Cloud Key acts as a controller and part of its configuration allows you to setup a connection to an email server so that events / alerts can be raised and delivered via email. I had setup a specific mailbox on my O365 account for this and after confirming that it was able to send mail, I entered its credentials into the Controller and hit the “Send test email” button…which resulted in an error. Hmm. I scratched my head, double checked my settings and tried it again. Still failed. What’s going on? I checked my O365 account. Everything is fine there. Tried telnet to smtp.office365.com on port 587…yeah,server is there. Tried another app to test credentials and that was OK. Finally I gave in, wised up and pinged Ubiquiti support in a live chat (oh, didn’t I mention that the Unifi controller supports live chat with support? It does!). The Ubiquiti rep had me connect to the controller directly rather than to the Unifi Cloud Service and test it there et voila! Works like a charm. So the net is that to test the controllers email functionality you have to connect to it directly rather than over the cloud service. Lesson learned and I hope this helps someone else out there.

Leave a Comment

It’s been a while

Well, obviously my ingenious plan to post a new blog post each week has not only failed, but failed spectacularly. Blah blah I’ve been busy. Blah Blah I really meant to do it.

None of that really matters, because I didn’t do it. No excuses.

Hey, on a positive note my diet is going super.

Leave a Comment

I’ve been very slothful

Well, carp. The whole “New year, new commitments” plan hasn’t really worked out the way I had planned. As always with the best laid plans of mice and men things get in the way. And yet, isn’t there an old phrase about this? Something like “fall down six times, get up seven?” Whatever the phrase or inspirational quote I am going to honor my commitment even if that means basically spamming my own site with articles.

‘Tis a lesson you should heed:
Try, try, try again.
If at first you don’t succeed,
Try, try, try again.

Leave a Comment

Ruminations on risk management, fault tolerance, and Amazon’s HQ2

Yes.  I know.  I committed to posting at least one post per week, and I’ve failed.  However, I am going to try to make it up by posting two articles this week.  First off, some simple thoughts on Amazon’s “HQ2”, fault tolerance, and risk management.  Last year Amazon started the process to find a suitable location for a second headquarters that they are calling “HQ2”.  This is a pretty unique scenario and it got me to thinking. While some news articles have called it a “marketing ploy” to attract tax incentives and offers from regions, I’m taking a different (albeit probably wrong) angle that while their choice to be so public about the selection process most likely is a marketing move,  the underlying thought could be to introduce some redundancy and fault tolerance into their headquarters operations as a method of risk management. As Sancho Panzo said to Don Quixote: “…to retire is not to flee, and there is no wisdom in waiting when danger outweighs hope, and it is the part of wise men to preserve themselves to-day for to-morrow, and not risk all in one day; and I thought this could be a good time to talk about risk management in general.

According to NIST  risk “…is the net negative impact of the exercise of a vulnerability, considering both the probability and the impact of occurrence.  Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level. ” which in human terms means that risks are bad things that can happen to your stuff and that to avoid or mitigate risk to an acceptable level, you want to identify your stuff (assets or operations), the bad things that could happen to that stuff (hazards or vulnerabilities), a scenario for that bad thing occurring, the probability of that scenario occurring, and finally the severity of that scenario playing out (what could happen, how likely is it to happen, and what is the final impact).  Based on that information you can determine if the cost of a mitigation is worth the investment in that mitigation as the cost to mitigate a risk shouldn’t exceed the value of the asset itself.  For example, let’s say a business is based in a wooden building (our asset).   One potential hazard for that building is a fire and one potential scenario (there could be multiple) is a total loss of the building.  If in our scenario we have an employee who likes to play with matches and lighter fluid, then we have a higher likelihood of that scenario occurring and this could have a catastrophic impact on our business (all our stuff got burnt up).  However, if we believe that the investment in a fire suppression system is worth the expenditure, we could mitigate this risk by installing sprinklers (or just replace Jane Firebug, but that’s for HR to decide).  Another potential mitigation could be to duplicate operations so that if we did have a fire (Jane didn’t get replaced because she wrote all the code for the companies primary product), we could resume operations in another location.  This would deal with not just the risk of fire, but also other potential risks to the building.  Granted this could be a much more expensive mitigation than sprinklers but it can also be more effective in terms of operational recovery, uptime, etc.  Keep in mind that hazards aren’t just physical in nature.  A hazard (or threat) could be that a vulnerability in software which could exploited by a malicious actor. While it’s a different type of hazard, the process for assessing the risk is the same:  identify the threat, a scenario for that threat, it’s likelihood of occurring, and finally its impact.  From there you can then determine the acceptable risk or mitigation.

If we consider that Amazon has said that it will be “…a complete headquarters for Amazon – not a satellite office. and that they are expecting to allow their staff and executives to be able to choose which headquarters they want to work at, move groups around, etc. then that sounds to me like a basic fault tolerance design.  In 1976, Dr. Algirdas Avizienis wrote that “The most widely accepted definition of a fault-tolerant computing system is that it is a system which has the built-in capability(without external assistance) to preserve the continued correct execution of its programs and input/output (I/O) functions in the presence of a certain set of operational faults.” (sorry, the original paper is behind a paywall ?) That certainly sounds like the concept that Amazon is taking here doesn’t it? (ok, roughly taking here.  This isn’t a doctoral thesis folks, it’s just me musing on a Saturday morning).  And while duplication of a system as a method of mitigating risk is an expensive one, I think Amazon has the cash.

Leave a Comment

Commitment vs. Resolution

It’s January first, “Day One” of 2018,  and of course that means it’s time to do the annual dance of New Year Commitments. “Um, Matt, it’s a New Year Resolution not a ‘commitment'” you say, and normally you’d be right.  But let’s think about the words “resolution” and “commitment”.  Dictionary wise, they’re about the same;

Resolution, noun “a firm decision to do or not to do something”

Commitment, noun, “the state or quality of being dedicated to a cause, activity, etc.: ”

But what’s more interesting is the synonyms for each word:

Resolution:  synonyms: intention · resolve · decision · intent · aim · plan · commitment · pledge · promise

Commitment: synonyms: dedication · devotion · allegiance · loyalty · faithfulness · fidelity

There’s a subtle difference there.  A resolution is an intention to do something, but a commitment is a dedication.  It’s holding yourself accountable to the resolution.  So, at least in my view, the New Year should start with a commitment to do something, and not just the intention. We intend to do the right thing all the time.  However, we only really dedicate ourselves to those things that matter to us.  Intent is a great thing as it lets us feel good that we want to do something, but it doesn’t have any, well, commitment to it.   To that end, here is my commitment for this site / podcast / blog:

In 2018, I commit to:

  • Writing at least one entry per week
  • Recording and posting at least one podcast session per month.

Whew.  There.  That wasn’t so hard.  I’ve made a commitment.  Now to follow up on it.

Leave a Comment