Do not trust "localhost": It is just a name

Like any other domain name or host name, "localhost" is yet another name. It needs to be resolved first when it is used. Usually, the entries needed to resolve it are already in the `hosts` file when the OS is installed.

$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.140 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.147 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.148 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.126 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3059ms
rtt min/avg/max/mdev = 0.126/0.140/0.148/0.008 ms

$ ping6 localhost
PING localhost(ip6-localhost (::1)) 56 data bytes
64 bytes from ip6-localhost (::1): icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from ip6-localhost (::1): icmp_seq=2 ttl=64 time=0.175 ms
64 bytes from ip6-localhost (::1): icmp_seq=3 ttl=64 time=0.221 ms
64 bytes from ip6-localhost (::1): icmp_seq=4 ttl=64 time=0.161 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.099/0.164/0.221/0.043 ms

The pitfall here is, if you simply use "localhost" in your application, it could behave differently when deployed in different environments. In extreme cases, I have seen "localhost" get resolved to its IPv4 and IPv6 entries (i.e., "127.0.0.1" and "::1") randomly within a single integration test run. Think about it! What if the service, that your application is trying to connect to, ONLY listens to its ports on the IPv4 address? In such a case, a connection request sent to "::1" will be refused.

Tips

1. If you see "connection refused", always check if the ports are open on both "127.0.0.1" and "::1". Do not preclude this possibility even if the error is intermittent.
   
2. Docker containers' forwarded ports might be open on "127.0.0.1" only on the host.
3. If you cannot solve the resolving issue in the environment, there might be workarounds where you can configure your application to prefer the IPv4 stack when resolving host names.
   

I am closing my old unused online accounts

If you do not manage it, you do not own it.

For some reasons, I registered a lot of online accounts in the old days, on many websites, and sometimes many accounts on the same website. When the total number increases, it eventually became impossible for me to frequently check through all of them.

The lack of maintenance could lead to severe security problems.

1. The online accounts that I created earlier are more likely to have weaker security settings, like passwords and security questions. At the same time, without frequent checkup, many security settings expire, like recovery emails and phone numbers; some credentials may simply get lost, like answers to the security questions. This means that I may be locked out of my own accounts indefinitely, not being able to improve the accounts' security.
   
2. Data breaches are happening way more frequently than I assumed in the old days. Once the databases are dumped, weak passwords are highly vulnerable and will eventually get cracked, then the accounts will be compromised. Do not underestimate this chance. In the past 5 years, 2 of my major online accounts were once hacked. Those accounts were associate with email boxes, which contained a lot of personal data. In order to gain access back to those accounts, I had to contact their online customer service and upload even more sensitive personal data to prove my account ownership. If these uploaded data are not handled appropriately by the websites, they could lead to bigger security issues in the future.
3. Attackers are much more capable than us. They know the vulnerabilities of online services and can get access to our accounts much easier than ourselves. While a piece of missing security information can lock me out of my own accounts, the attackers might leverage the exploits to circumvent the security checks, claiming ownership of my accounts. In the most recent hack, the attackers seemed to have leveraged an obsolete and insecure security path, which allowed them to override my recover phone number, without triggering even a single alert that was supposed to be delivered to my old number.
   

The lesson is, close unused online account when you still can, especially if they contain sensitive person data, like past email conversations. Depending on the security implementation of the websites, this might not make your data completely secure, but it is supposed to be more secure than if you do not do anything.

This is not a simple task for me due to the amount of data that need to be migrated, but I have added it to my TODOs.

Becareful when you transfer your Blogger site to a different Google account

It appears that the images I upload and use in my Blogger posts are stored within either my Google account, or my Blogger account, which is now just one part of my Google account.

The key point is, when I transfer my Blogger site to a different Google account, like what I have recently done to this site, the uploaded images do not go together. After deleting my old Google account, these images are just gone and the links are broken. Since the posts are so old, there is nowhere I can find the original images back. I have no choice but delete their links completely to make the posts look slightly better.

Therefore, be careful when you transfer your Blogger site to a different Google account, and be even more careful when you delete your Google account data.

One way to workaround this is to use a third-party file hosting service or online album that supports external links. However, it is obvious that if you plan to go in this direction, you will need to start as soon as possible :-)

Here is how you move an individual user's profile folder in Windows 7+

In Windows 7 and higher, all users' profile folders (similar to users' home folders in UNIX systems) are located under `C:\Users\` (similar to `/home/`).
There are many articles talking about how you can move the entire "Users" folder to a different drive other than `C:`.

However, it has been hard for me to figure out how to move only one specific user's profile folder out of `C:\Users\` without touching those of other users.
This could be useful when I want to separate the profiles of certain users from the others.
For example, on a lab machine, I want to encrypt the system drive with BitLocker. This will also encrypt the user profile of my own account which is an administrator.
However, at the same time I would like to leave the profiles of some other users (e.g. a customized guest account with persistent settings) unencrypted so they can retrieve their data later from the hard drive without me, even using a different machine.

This is very straight forward in UNIX systems because the home folder location information is part of `/etc/passwd`.

Therefore the first thing that I tried was "Local Users and Groups" in "Computer Management". It appears to be promising -- basically I can find my user in the list of local users:

(Image expired...)

And there are two text-boxes in the user's properties:

(Image expired...)

However, as I annotated in the figure, none of these actually servers the purpose.
If I fill in any or both (yes, I tried all three combinations) of these two text-boxes with the desired path (e.g. `C:\desired\profile\folder\path\`), the next time the target users logs in he receives a warning that Windows could not find his profile folder hence is using a temporary one.
At the same time, an empty folder named with the desired path string plus ".V6" is created (e.g. `C:\desired\profile\folder\path.V6\`), and I have to first gain ownership of that folder before I could delete it.
This does not work even if I have moved the user's original profile folder from `C:\Users\` to that desired path.

Here is what actually works --
The profile path is stored in the system registry in `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-*\ProfileImagePath`. That `S-1-5-*` is the internal user ID associated with the target user which I have to click on each to figure out which is the corresponding one.

(Image expired...)

Note that this key in registry only exists after the target user has logged in successfully for at least once (i.e. its user profile has been created under `C:\Users\`).
After I change the path to the desired path, I also need to use the "Administrator: Command Prompt" (i.e. run "Command Prompt" as Administrator), and move the user's profile folder from `C:\Users\` to the desired path. The syntax is `move SOURCE DESTINATION`, e.g.

move C:\Users\user_name C:\desired\profile\folder\path

As long as the destination is consistent with the one I set earlier in the registry, the migration is successful; the target user will log in with no hassle and use the new profile path from now on.

The complaint here is: Why in the hell does Windows have the two text-boxes in the management console for local users to confuse us?
Possible excuse: It is probably some backward compatible feature. Materials that I found seem to say those boxes are for users whose profiles are located on other machines in the local network.
I do not care though...

Import a VM on VMware ESXi server with vSphere Client 6.0

Okay, so this is the second post in the "funky design" series.
I am writing these down, just in case that I forget about them myself in the future.

With vSphere Client 6.0, creating a VM is relatively easy, just as easy as how you achieve it in VMware Player or VMware Workstation.

(Image expired...)

I would expect importing a VM to be done in the same way, but I was totally wrong on this. I searched the client UI for quite a while but did not find anything related to importing.
What is importing?
After I transfer the files of a VM from one ESXi server to the other, I need to be able to edit it and run it. There needs to be some way to let the new ESXi server know about its existence.

Later I learned this from Google --
First, I need to open the data-store browser by right-click on the data-store in the "summary" page, which is anti-intuition enough...

(Image expired...)

Second, I need to find the file that I copied to this ESXi server, manually select the ".vmx" file, and click the "add to inventory" button.

(Image expired...)

Good job...