Why GitLab?

While GitHub Pages (and GitHub in general) is a more popular way to go, it’s not that good. GitLab Pages on the other hand provides more features and uses a relatively simple CI script.

First, GitHub serves your blog from gh-pages branch so you need to write CI script to commit your Hugo output public dir to your repository’s gh-pages branch for it to work. GitLab however serves your blog from CI artifact directly which means you write CI script just to build the Pages and that’s all.

Second, The thing I like more about GitLab Pages is its Pages Settings. Unlike GitHub, you don’t need CNAME file committed in your Hugo site to specify domain/sub-domain. While there’re GitHub Actions that don’t require a CNAME file, you don’t get much control over your domain and SSL certificate settings. GitLab gives you all that with a simple interface under Repository Settings > Pages. GitLab also allows you to specify more than one domain/subdomains.

Last, although your blog source is already kind of public when you publish the blog still there are reasons when you want to keep the blog source private. For any reason, if you want that, GitLab gives you the option to keep your blog source repo private and still be able to serve pages (free of cost).

How?

1. Create a GitLab repo and push your blog source to it.

2. Click Settings > Visibility, project features, permissions and enable Pages for everyone.

3. Create a .gitlab-ci.yml file in your root dir of your repo and paste this in it:

   image: registry.gitlab.com/pages/hugo/hugo_extended:latest
   
   variables:
       GIT_SUBMODULE_STRATEGY: recursive
   
   pages:
       script:
           - hugo
       artifacts:
           paths:
           - public
       only:
           - master #default branch of your repo
   

4. Now if you don’t have a domain then you can rename the repo to your-gitlab-username.gitlab.io and your blog should be available on https://your-gitlab-username.gitlab.io. But if you have a domain and you want to serve your blog on it then do the following:

   • Click on Settings > Pages > New Domain on your repo and enter your domain/sub-domain in there and select Create New Domain. You’ll see text-boxes in front of DNS(CNAME) & Verification status(TXT). These are 2 DNS records you need to add to your domain’s DNS settings(most probably on your domain registrar’s site). Copy both the values somewhere and click Save Changes.
   • Open your domain’s DNS settings and add those above 2 DNS records along with one A record pointing to 35.185.44.232 and that’s it. For more info about adding your domain, check the official guide.

   For this blog(domain: surendrajat.xyz) I’ve added the following DNS records:

    | Key                                | Type | Value                       |
    | ---------------------------------- | ---- | --------------------------- |
    | *                                  | A    | 35.185.44.232               |
    | _gitlab-pages-verification-code... | TXT  | [Verification status value] |
   

   For another site(sub-domain: apklab.surendrajat.xyz) I’ve added the following DNS records:

    | Key                           | Type  | Value                            |
    | ----------------------------- | ----- | -------------------------------- |
    | *                             | A     | 35.185.44.232                    |
    | apklab.surendrajat.xyz        | CNAME | apklab.gitlab.io [DNS txt value] |
    | _gitlab-pages-verification... | TXT   | [Verification status value]      |
   

And that’s it. There you have it. Your Hugo blog.

TeamViewer is one of the most popular remote desktop (control) application available out there. It’s also cross-platform and offers a ‘free for personal use’ license. So I use it to help out friends & family with their issues sometimes.

Now it works fine until you start seeing a random popup with ‘Commercial use detected’ before each connection. At this point, TeamViewer becomes pretty much useless as each session will be disconnected after 5 minutes and so on…

“Okay, I get it, but what’s the solution?” - well. If you have a lot of patience and are lucky enough then go fill this official support form and your TeamViewer ID will be unblocked within a few weeks. I tried this way but unfortunately by the time they unblocked it, I had done some tinkering and lost that TeamViewer ID to a new one so no luck.

“Yeah Neh. I don’t think I can wait that long. You got something faster?” - hmmm. Using Linux? Yes, then I got it… follow along. If not then I’m sure the machine detection works in a similar way on other OSs too so you can get an idea from here.

“I tried a fresh reinstall, but still blocked” - They label your machine as evil. You gotta change its ID.

What is machine detection and how does it work?

To uniquely identify your machine in the crowd and eliminating the need of a new TeamViewer ID each time you run/reinstall it, some of your machine’s unique IDs and parameter hashes are stored on the TeamViewer server and each time you go online those hashes are sent to the server again to retrieve TeamViewer ID.

Below is an example of such an exchange obtained from TeamViewer menu Extras > Open log file… > TeamViewer14_Logfile.log

Activating Router carrier
KeepAliveSessionOutgoing::ConnectSuccessHandler(): KeepAliveConnect to router16.teamviewer.com successful
KeepAliveSessionOutgoing::KeepAliveChannelInitialized(): KeepAliveConnection to router16.teamviewer.com initialized
KeepAliveSession::KeepAliveChannelInitialized(): KeepAlive-Connection initialized with ID 0 (IP: 0.0.0.0), SendQueue 0 (0 Bytes), SendIndex 0, AckIndex 0, RemoteSessionID 50
KeepAliveSession::SendCompleteQueue(): SendQueue: 0 (0 Bytes), RemoteSession 50 (ClientID 0), Time: 0 ms
IdentifyRequest: ID = 0, IC = -1801590255, IsTemporaryID = 0, InitiativeGUID = 1b59cb26-6e24-4b9d-8259-3602f206b401, CanStoreGUID = 1, MIDHistory = {-1801590255_3b5111c17_0a331900000001eb|l1feb69aabc5947c1867a812f32bb784f:fc3fdb21a48f:59d0c1db2fdc11111f0a38de39e472b|alinux021feb69aabc5947c1867a812f32bb784f:fc3fdb21a48f:59d0c1db2fdc11111f0a38de39e472b}, MIDv = 0, MaxSupportedMIDv = 2, RebootHash = {60830716-f6ae-3d38-bc5e-e99570d16f76}, MIDFlags = 16, MIDForceUpdateFlags = 0, AttractionGUID = 00000000-0000-0000-0000-000000000000
TVRouterClock: received router time: 20190312T025722.427851
TVRouterClock Schedule next request in 43200 seconds
Login::Identify::ManageLogin(): ID: 1066611234 IC 1495071111 MIDv1
CKeepAliveClientClient::OnKeepAliveSucceeded(): Protocol 4 proxy  xxx.xxx.xxx.xxx:8080, user= 
TeamViewerIDTracker::UpdateMachineID: New machineID = 1066611234
LicenseTracker::UpdateMachineLicense() local license differs from master license
SyncManagersFunction::Start: current managerlist size: 0
Client logged in and online

As you might have figured the actual request to the TeamViewer server is IdentifyRequest :

IdentifyRequest: ID = 0, IC = -1801590255, IsTemporaryID = 0, InitiativeGUID = 1b59cb26-6e24-4b9d-8259-3602f206b401, CanStoreGUID = 1, MIDHistory = {-1801590255_3b5111c17_0a331900000001eb|l1feb69aabc5947c1867a812f32bb784f:fc3fdb21a48f:59d0c1db2fdc11111f0a38de39e472b|alinux021feb69aabc5947c1867a812f32bb784f:fc3fdb21a48f:59d0c1db2fdc11111f0a38de39e472b}, MIDv = 0, MaxSupportedMIDv = 2, RebootHash = {60830716-f6ae-3d38-bc5e-e99570d16f76}, MIDFlags = 16, MIDForceUpdateFlags = 0, AttractionGUID = 00000000-0000-0000-0000-000000000000

Looks like mess? “Yes”. Alright. Let’s break down the important part.

• ID: TeamViewer ID (initially 0 at first run)
• IC: Some secondary ID
• MIDHistory: Unique Machine ID
  • 1feb69aabc5947c1867a812f32bb784f: /etc/machine-id or /var/lib/dbus/machine-id
  • fc3fdb21a48f: Current active MAC Address
  • 59d0c1db2fdc11111f0a38de39e472b: / (Root FS) partition UUID

and the responce is, of course, Login:

Login::Identify::ManageLogin(): ID: 1066611234 IC 1495071111 MIDv1

which contains correct values for ID & IC returned by the TeamViewer server.

“Ah. I see how it works. How do I hack it then?”

How to change machine identity?

Simple.

• Step 0: Cleanup

# completely remove the teamviewer app
sudo apt purge teamviewer
# remove all the residuals of it
rm -r ~/.config/teamviewer/
rm -r ~/.local/share/teamviewer/
sudo rm -r /root/.local/share/teamviewer14/
sudo rm -r /etc/teamviewer/
sudo rm -r /opt/teamviewer/
sudo rm -r /var/log/teamviewer14/

• Step 1: Change Machine ID

# remove current machine-id
sudo rm /etc/machine-id
sudo rm /var/lib/dbus/machine-id
# generate new machine-id
sudo systemd-machine-id-setup
# and copy(if don't fancy system reboot)
sudo cp /etc/machine-id /var/lib/dbus/

• Step 2: Change MAC address

# figure out the device id whose MAC address is  in the logfile 
# Menu>Extras>Open log files...>TeamViewer14_logfile.log
# let's say it's ethernet device with id elp7s0
sudo macchanger -r elp7s0

• Step 3: Profit!!! Just reinstall the TeamViewer and enjoy.

Final thoughts

Thankfully it works without changing / (Root FS) partition UUID which can’t be changed for a mounted partition and could be a headache. Changing only the MAC address will get you a new ID but you will still be blocked unless you reset machine-id. For Mac, it should be very similar but for Windows, the machine-id part will be totally different and the way MAC addressis updated is also different, but you get the idea.