Monthly Archives: January 2020

Uncategorized

Turning off Windows feedback prompts

I use Windows, Linux and Mac. I hop between them several times a day and find that each has its own strengths and annoyances.

This evening, Windows presented me with a prompt, asking how hard it is to customize Windows. It took me out of my workflow, distracting me from the task I originally wanted to work on.

As a society, we get a lot of surveys. Because if asking a small sample of consumers what they think of a product will give useful information, then asking a large group will surely give the survey takers an even better idea of what’s going on.

And so, we get surveys on the receipts at restaurants and home improvement stores. We get feedback requests from apps on our phones. (We probably get surveyed on drug store receipts, but it’s hard to tell with all the coupons.) And now we’re being prompted for feedback from the computer’s operating system.

Here’s how to (hopefully) remove that one: At least, until they add another survey tool.

  1. Go to the settings app (Windows key + I
  2. In the search, type “Feedback”
  3. Select “Diagnostics & feedback settings.”
  4. Scroll down. About 2/3 of the way down the page, you’ll find a box for selecting “Feedback frequency”, labeled “Windows should as for my feedback.” By default, this will say “Automatically (Recommended).”
  5. Change the setting to suit. (I chose “Never.”)

I’ll update this post as I find other feedback prompts to disable.

(Image by Pixabay user mohamed_hassan, used under the Pixabay license.)

Uncategorized

Why do DNS changes take so long to show up?

My project manager asked me yesterday, “Why do DNS changes take so long to show up?” We were in the process of moving a web site to a new server and he hadn’t expected it to take 90 minutes for all the traffic to move to the new server.

As background, let’s talk about what the Domain Name System (DNS) is for a moment. Every computer connected to the internet has a unique address, called an IP address. You can think of this as being similar to a telephone number. For www.example.com, the IP address is 93.184.216.34.

The problem with IP addresses is, they’re hard to remember, which is why we have a system of domain names (example.com) for groups of computers and host names for individual computers. This is similar to a person having a family name and a given name.

The DNS system is similar to your phone’s contact list. Most people don’t know all the phone numbers in their phone’s contact list; instead, they know to look up Bob Smith in the contact list and when they press the dial button, the phone looks up Bob’s phone number and dials 732-555-1234.

Similarly, when you type www.example.com into the web browser, your computer contacts the DNS system, looks up the IP address, and connects the browser to 93.184.216.34.

Rather than look up the IP address on every request, your computer will remember (or cache) the address for a while. How long it should remember the address is controlled by whoever owns the domain name, it can range anywhere from a few seconds, up to days or longer. Commonly, it’s set to several hours. This is called the DNS record’s “time to live.”

So if you run www.example.com and move the website to a new host (this could be a new hosting provider, or simply a new server at the same provider), part of the move will be to update the DNS system (contact list) with the new server’s IP address (phone number).

Because of the DNS time to live, other computers may continue to contact the old server until the DNS record expires, at which time they’ll look up the address again and find the new IP address. (This is an important consideration when moving a web application which maintains any sort of application state information.)

Bonus: Looking up IP addresses

Most Linux and OSX computers will have a program called dig installed. (Alternatively, you can also use the Dig tool from Google’s online “G Suite Toolbox”) You can use this to look up the IP address of any computer connected to the internet:

blair@Squawk:~$ dig www.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16595
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.example.com.               IN      A

;; ANSWER SECTION:
www.example.com.        80319   IN      A       93.184.216.34

;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jan 14 02:01:45 EST 2020
;; MSG SIZE  rcvd: 60

blair@Squawk:~$

In the part labeled “;; ANSWER SECTION”, there’s a line which reads:

www.example.com.        80319   IN      A       93.184.216.34

The the server’s IP address is 93.184.216.34 and the computer will remember the IP address for another 80,319 seconds (about 22 hours). If you look up the same record several times in a row, you’ll notice that the number decreases over time. (It appears the record for www.example.com is configured with a time to live around 24 hours.)

Uncategorized

Considerations for Hosting a NODE Application

Spotted a question on Dev.to basically asking “How do you put a Node application in production?” and thought I’d copy my response here.

I’ll preface this by saying that although I’ve dabbled with Node, I don’t have anything in production right now that uses it. That being said, the way a Node web application runs – as a long-running external application instead of a module that’s part of the web server – is familiar enough for me to feel comfortable with the general principles.

How to use Node in production is actually a fairly broad topic, and a lot of it depends on exactly what the application is trying to do. It’s probably going to be useful to do some reading on Dev’s #node tag, but here’s my best high-level guidance.

Architecture
So, what’s your Node app doing? Is it running a public web site? Responding to URLs for a publicly available service? Or is it an application that your front end application just calls for specific calculations? This impacts literally everything else.

Hosting
A commodity PHP host won’t cut it for Node. You’re going to need one which allows for long-running applications. Generally that means a custom VM, or perhaps something that just allows you to deploy containers. That doesn’t have to be Digital Ocean or Heroku, though they do have the kind of set up you’re looking for.

Front end web server
There’s no requirement for a traditional web server, but it’s a common configuration. You can add middleware to Express to serve up static files, but it’s generally faster (and already written) to use Apache, Nginx, or something else to serve up files and act as a reverse proxy for the specific routes your application is handling.

Ports
This is a bit of a low-level implementation detail, but seeing as how others have touched on it…. I believe Express defaults to port 5000, but you can set it listen on whatever you want. If you’re using a front end server, you’d let the front end server handle port 80 and 443. If Express is handling all the traffic, then the Node app will need to handle those ports instead. (And note, I’m only assuming you’re using Express, that’s not required for a Node app that responds to HTTP requests; it’s just a very popular solution.)

Development vs. Production
I find it’s helpful if, to the extent possible, the development environment matches the production environment. You won’t install a compiler or an IDE on the production environment, but if the production environment will have a front end web server, it’s helpful to have the same front end web server running in the development environment. (I highly recommend you read about “The twelve-factor app for more about this topic, and other helpful guidance.)

Deployment
“Automate all the things.” This has nothing to do with Node. If you can’t automate everything, automate as much as you can. Can’t use Travis, Jenkins, or a similar Continuous Integration tool? Go with a shell script.

I have personal experience with deployments which took three hours per environment and tended to result in production outage because the deployment instructions were a 12 page Word document. Those same deployments dropped to three minutes and stopped breaking production once we wrote a script to handle the config file changes.

Uncategorized

Turning off the Home Assistant Cloud integration

Over the New Year holiday, I resurrected the Raspberry Pi I’d been using for Home Assistant. It crashed in early 2019 and when a reboot didn’t fix it, I thought perhaps a power spike had killed the Pi. So I put it aside with the intent of reformatting the micro SD card to see if that would fix it, but then Drupal happened at work and I didn’t get back to it for a very long time.

The new theory is that the Pi is just fine and the memory card got corrupted. It’s up and running now with the latest Home Assistant on HassOS 3.7.

Things have changed in the past year and one of the things I noticed was that the default configuration.yaml had a lot fewer entries. That’s fine in itself, but when I went to the main Configuration screen, I couldn’t figure out how to turn off the “Home Assistant Cloud” integration – previously, you would turn that off by removing the cloud property from the configuration.yaml, but the new leaner version of the file didn’t have that entry.

I eventually found a forum post asking the very question on my mind: “How can I disable the cloud component?” The answer, it turns out, is to remove one of the few default entries in the configuration.yaml.

Near the top of the file, there’s an entry for default_config. What this does is automatically enable more than a dozen other configurations for things you’d most likely want to have: along with the cloud integration, it also enables the front end, history, logbook, system_health and more.

So what you can do is remove the entry for default_config and add back the integrations you want. Don’t want the cloud integration? Don’t copy it in.

Here’s the whole list, suitable for copy and paste to your configuration:

automation:
cloud:
config:
frontend:
history:
logbook:
map:
mobile_app:
person:
script:
ssdp:
sun:
system_health:
updater:
zeroconf:

A number of these weren’t in the configuration file a year ago, which meant they couldn’t be turned off. Now they can be, though you should definitely check the individual integration’s detail page to make sure you know what the consequences are – it might be better to remove them from the UI instead.