WebVM is a virtual machine (VM) that executes entirely within a web browser. It’s an innovative project that brings the power of a Linux environment straight to your browser, eliminating the need for traditional virtual machine setups. WebVM operates within a sandboxed environment, ensuring secure execution of applications without affecting the host system.

Understanding WebVM

The source repository provides a frontend for the WebVM demo. By forking the repository and following the instructions outlined in the GitHub Actions, you can build an image using the Dockerfile located at:

• Debian Large Dockerfile

This image can then be hosted on GitHub Pages, as demonstrated in my demo.

WebVM’s primary functionality is to stream resources to the browser, minimizing client-side resource consumption. It enables the execution of various applications that are typically restricted to virtual machines, all within a browser. Additionally, WebVM allows for the embedding of these applications through custom front-ends.

Default Image and Capabilities

The default WebVM image is Debian-mini, which may have limited capabilities. To enhance its functionality, I have opted for the Debian-large image, which has been extended to a 2GB disk capacity. This provides a more robust environment with additional tools and packages.

Usage and Benefits

WebVM offers a range of applications and capabilities:

1. Custom Image Creation: Create custom images tailored to your specific requirements, allowing for a personalized virtual environment.

2. Web-Based Linux Terminal: Access a web-based Linux terminal to execute Linux commands directly within the browser. This includes:

   • SSH/SCP File Transfers: Securely transfer files using SSH and SCP protocols.
   • HTTP Server Initiation: Start an HTTP server using python3 -m http.server.

3. Sandboxed Security: Operates within a sandbox environment, ensuring secure execution of applications without affecting the host system.

4. Serverless Architecture: Embraces a serverless architecture by executing entirely on the client side. Running a Linux server within a browser presents a unique and innovative approach to virtualization.

Alternative Options

Yes, there are alternative options. JSLinux is a preferred and faster option. However, it does not allow modifications to the image, which can be a limitation if you require a customized environment.

Additional Tips

• Internet Connectivity via Tailscale:

  WebVM can connect to the internet via Tailscale. It utilizes the first available node as an exit node. If you execute:

  curl https://ifconfig.me
  

  You will obtain your current node’s IP address.

• DNS Functionality:

  The DNS functionality of Tailscale is currently experiencing issues. It’s recommended to use IP addresses to connect to other nodes within your Tailscale network instead of domain names.

• Default Credentials:

  You can obtain the default user:password and root:password credentials by checking the Dockerfile:

  • Default Credentials in Dockerfile

Conclusion

WebVM is a powerful tool that brings the versatility of a Linux environment to your browser. Whether you’re looking to experiment with Linux commands, develop applications, or require a portable and sandboxed environment, WebVM offers a serverless and secure solution. Its ability to create custom images and operate entirely on the client side sets it apart from other web-based virtual machines.

Feel free to explore WebVM and customize it to suit your needs. Happy coding!

Discovering Tailscale Through WebVM

My journey with Tailscale began when I came across WebVM, an impressive project that allows you to run a virtual machine directly in your browser. Intrigued by the possibilities, I delved deeper and discovered that Tailscale could help me create a seamless, private network across all my devices.

What is Tailscale?

Tailscale is a mesh VPN network built on top of WireGuard, specifically using the WireGuard-go implementation. It allows you to create a secure, encrypted network between your devices, no matter where they are located.

Key Features

• Free Plan Available: Tailscale offers a free plan that is sufficient for personal use, allowing up to 20 devices.
• Ease of Use: Setting up Tailscale is straightforward. With minimal configuration, you can have your own network up and running quickly.
• Cross-Platform Support: Tailscale works exceptionally well across the Apple ecosystem, including iOS, tvOS, and macOS.
• Magic DNS Service: It provides a built-in DNS service that makes it easy to address your devices by name.

Performance on Different Platforms

While Tailscale shines on Apple devices, in my experience, it hasn’t performed as well on Windows. I encountered some connectivity and stability issues on Windows machines, which may vary based on individual setups.

My Tailscale Setup

Here’s how I leveraged Tailscale to connect my devices and access my home network seamlessly.

Running Tailscale on Apple TV

I installed Tailscale on my Apple TV, which stays online 24/7. This makes it an excellent candidate for a consistently available node in my network.

• Enabling Subnet Routing: By enabling subnet routing on the Apple TV, I can access other devices on the same local network, such as my NAS and router, as if I were connected locally.
• Setting Up an Exit Node: I configured the Apple TV as an exit node, allowing me to route internet traffic through my home network. This is useful when I need to access geo-restricted content or ensure a secure connection.

Connecting Other Devices

I also installed Tailscale on my MacBook and iPhone, which allows all my personal devices to communicate over the secure network, no matter where I am.

Benefits I’ve Enjoyed

• Secure Remote Access: I can securely access my home network devices from anywhere.
• Consistent Environment: All my devices appear on the same network, simplifying file sharing and remote management.
• No Need for Complex VPN Setups: Tailscale eliminates the need for traditional VPN configurations, port forwarding, or dynamic DNS services.

Conclusion

Tailscale has transformed the way I interact with my devices across different locations. Its ease of use and robust feature set make it an excellent choice for anyone looking to create a personal, secure network.

If you’re interested in simplifying your network setup and want a hassle-free way to connect your devices, I highly recommend giving Tailscale a try.

Links:

• Tailscale Official Website
• WebVM Project on GitHub
• WireGuard-go on GitHub

Note: This post reflects my personal experiences with Tailscale. Performance may vary based on individual configurations and devices.

After researching, I found that this problem is not unique. For instance, in a discussion on V2EX, many users encountered similar issues. The solution is to run warp-cli set-mode proxy before executing warp-cli connect to bypass the local address. Surprisingly, Cloudflare’s official documentation does not mention this crucial step, undoubtedly increasing the complexity and risk of configuration.

In the process of exploring solutions, I found that some users suggested repairing by rebuilding the instance or using VNC connection. However, since I am using AWS Lightsail, VNC is not applicable. Ultimately, I decided to try the method mentioned in this article: creating a snapshot backup of the current VPS, then creating a new instance from the snapshot, and loading a script to execute warp-cli set-mode proxy when the new instance starts.

After checking the existing instance, I found that no snapshot had been created. This discovery reminded me of the importance of regular backups. Without other options, I could only attempt a snapshot backup as guided by the aforementioned article. However, no matter what startup script command I tried, it failed to execute successfully. The execution result of AWS Lightsail’s startup script is not visible, making problem-solving more difficult.

In near desperation, I found an old snapshot dated 2022 on the snapshot page. Although this snapshot was created using old technology, and many important updates might be lost after recovery, it was my last hope. After starting the snapshot recovery process, I unexpectedly discovered through the history command that this snapshot contained all the important updates. This discovery allowed the entire recovery process to be completed smoothly.

This experience re-emphasized the importance of backups. Careful backups from the past ultimately avoided severe data loss. Furthermore, AWS’s static IP retention feature also played a crucial role. The new instance could immediately bind to the IP once the old instance released the static IP, achieving a seamless switch.

Conclusion

1. Backups are essential: Regular backups are key to ensuring stable system operations.
2. Operate with caution: Before executing critical commands, thoroughly review and understand relevant documentation and user feedback to avoid potential risks.
3. Trust your past self: Meticulous work done in the past can often prove invaluable at critical moments.

I hope this experience can serve as a reference and help for others, preventing similar issues from occurring.

After moving house, there are many more devices at home that need internet access. However, I don’t want to configure a proxy on each device, so I thought of using a transparent gateway.

Transparent Gateway

After some research, I found that the easiest way is to use the premium version of Clash, although I didn’t know when Clash released a premium version. I mainly referred to this article. It’s much simpler than setting up iptables.

Network Topology

I have a 10-year-old Thinkpad x230 at home, which is perfect for this purpose. Here is a simple topology diagram.

Router1 is a fiber-optic modem with routing capabilities, Router2 is a regular router, with the gateway and DNS pointing to the Thinkpad, where Linux is running to act as a transparent gateway with Clash on top.

                                 +------------+
                                 |            |
                                 |  Internet  |
                                 |            |
                                 +-----+------+
                                       |
                                 +-----+------+
                                 |            |
                      +----------+  Router1   +-----------+
                      |          |            |           |
                      |          +------------+           |
                      |                                   |
                      |                                   |
                +-----+-----+                       +-----+------+
                |           |                       |            |
     +----------+  Router2  +----------+            |  Thinkpad  |
     |          |           |          |            |            |
     |          +-----+-----+          |            +------------+
     |                |                |
     |                |                |
     |                |                |
+----+-----+     +----+-----+    +-----+-----+
|          |     |          |    |           |
|   Mac    |     |  iPad    |    |  iPhone   |
|          |     |          |    |           |
+----------+     +----------+    +-----------+

Add DNS Section in Clash Configuration

dns:
enable: true
listen: 0.0.0.0:53
enhanced-mode: fake-ip
nameserver:
  - 114.114.114.114
fallback:
  - 8.8.8.8

Clash tun Feature Section

tun:
enable: true
stack: system # or gvisor
dns-hijack:
  - any:53
  - tcp://any:53
auto-route: true
auto-detect-interface: true

For traffic forwarding, simply edit /etc/sysctl.conf on the Thinkpad and add net.ipv4.ip_forward=1, then execute sysctl -p to apply it. After that, point the gateway and DNS of Router2 to the Thinkpad, and you’re done.

Network Protocols

Initially, I used native HTTP2 for unblocking, but it cannot proxy UDP. When only a few devices need unblocking, it doesn’t matter whether UDP is used, but with many devices at home, some of them can only use UDP. I considered socks + tls, but it didn’t feel secure and required opening odd ports like UDP 443. It felt like giving away my intentions. Eventually, I chose Trojan, which essentially mimics native HTTPS. Trojan has two versions; I used Trojan-go simply because I didn’t want to manage dependencies. Also, I’m more familiar with Go.

Trojan-go has a requirement for a genuinely accessible HTTP server, so I used the simplest Python http.server. Back in Python 2, it was called simplehttp. You can simply use python3 -m http.server 80 and optionally add --directory to specify a directory.

Additionally, Trojan-go requires the client to fill in the SNI, which means using the domain used during key application. Therefore, prerequisites like applying for the domain, applying for Let’s Encrypt certificates, and configuring crontab must all be completed. There’s a learning curve, but I had done it before, so I just skipped that part.

For the client part, you can use Clash directly, and refer to here for guidance.

Recently, both of my kids have become interested in Minecraft, and some of their peers are also playing it. We previously bought the Switch version, but its online capabilities are quite poor, and the device performance is subpar, resulting in a less-than-ideal experience. Thus, I began considering the idea of setting up our own server. Of course, you can play in multiplayer with friends, but the game ends as soon as the host goes offline, which is not as good as having a server that is always online.

For version selection, there is the NetEase version, the official Java version, and the Bedrock version. Based on my previous understanding, the NetEase version has all sorts of anti-addiction regulations, so that’s a no-go. The Java version server setup seems to rely on third-party launchers, resembling piracy to some extent. Therefore, I decided on the Bedrock version. Another reason for choosing the Bedrock version is its origins as the mobile version of Minecraft, and Microsoft later expanded support to more platforms, making it the most versatile. Additionally, its core is written in C++, which should offer better performance and resource efficiency.

Downloading the Server Software

I downloaded the Ubuntu version. While I also downloaded the Windows version and managed to run it, I’m not experienced in managing Windows Server, and the Windows version has some quirks. I won’t delve into those here.

Local Network Server

Initially, I intended to use an old Thinkpad, but couldn’t find it, and ended up using an old Macbook. After updating everything, I found that the old Macbook was still quite robust, outperforming the Thinkpad. So, I set up a virtual machine. I discovered that Ubuntu Server no longer supports direct ISO downloads, requiring Multipass to launch instead.

What is Multipass?

Developed by the Ubuntu team, it is a lightweight virtualization platform. Multipass consists of multipass and multipassd. The former provides both GUI and CLI, while the latter requires root permissions and runs in the background. It can be downloaded directly or installed via brew cask.

Multipass seems to only install Ubuntu Server, with some customization, such as automatically creating a user named “ubuntu” and key pairing. Once installed, you get a 1C 1GB virtual machine called “primary” that automatically mounts the user’s home directory.

multipassd is more of a pluggable virtual hypervisor supporting hyperkit and qemu by default, with hyperkit intended for Intel macOS and qemu for M1.

multipassd can also use Virtualbox as a backend hypervisor, which is more recommended because it offers bridging capabilities, whereas relying solely on port mapping would be cumbersome. It’s not that qemu doesn’t support bridging, but there’s an easy-to-follow Virtualbox bridging tutorial on Multipass’s official documentation.

I set up Virtualbox first. I must say, Oracle is generous here as it’s still free to use. Then, I followed the steps from the link above. It’s essential to reboot the machine after running the first step sudo multipass set local.driver=virtualbox, as the variable might not take effect immediately. Otherwise, the primary created will still use the old backend. Since there’s already a default virtual machine, I didn’t want to create another one to avoid extra resource usage. Additionally, note a few things:

1. For modifying primary configuration, I didn’t find a way to do it using Multipass, so I used vbox’s command sudo VBoxManage controlvm "primary" --cpus 2 --memory 4096 (where memory is in MB).
2. The primary mount point in Multipass can automatically unmount in some situations, resulting in errors. Therefore, Minecraft data shouldn’t be stored in the mount point permanently to avoid core dumps.

After extracting the server files, just start it in tmux/screen.

Lastly, I used Amphetamine from the App Store to ensure that the laptop continues working when closed by disabling the default sleep setting after the screen is closed. You’ll see some warnings when doing this, but just be aware of them.

Update:

For systemd startup, you can refer to this gist. The server’s console has some commands, like “stop”, that perform graceful shutdowns, so it’s necessary to rely on a screen session to create it. Additionally, the server startup has some environmental dependencies, so it’s best to write a small script for starting it, like:

#!/bin/bash

cd /home/user/bedrock-server
LD_LIBRARY_PATH=. ./bedrock_server

Using absolute paths can lead to core dumps.

Public Network Server

For public network servers, the choices are to map the internal network to the public network or purchase a cloud server. Due to security concerns, I opted to buy a cloud server. Although the official site mentioned Ubuntu support, I found that Debian servers also run without issues. The only thing to note is that the Bedrock version uses UDP, and China Unicom’s 5G network disables UDP, so without WiFi, you cannot connect.

Server Monitoring

To monitor the server’s status, monitoring is necessary, especially for cloud servers, as provider information might be insufficient. I used Grafana Cloud.

Using the free version is fine, just follow the guide to select a Linux server integration, then run the Grafana Agent installation and verification on the server to be monitored. Note to change the hostname in the Grafana Agent configuration file to differentiate between different servers, which acts as a label.

I understand that Grafana Agent is a lightweight node exporter with some Prometheus functionalities, but it can also remote write, so there’s no need to worry about the disk filling up.

One day, I impulsively turned on GitHub’s Vigilant mode.

As a result, all my commits started looking like this.

To figure out how to make them Verified, I found the following method.

Method

I actually referred to this link. However, it wasn’t quite enough, as there might be authentication-related issues on MacBooks that lead to commit errors. So, I found this solution.

In summary, to verify, you need to enter a password. The issue on a Mac is the prompt for entering the password, which needs to be replaced with pinentry-mac, which most people install via homebrew.

Moreover, this solution thoughtfully provides a way to verify:

echo "test" | gpg --clearsign

GPG Experience

1. It doesn’t replace the ssh key. After successfully setting it up, I deleted my GitHub ssh key and discovered that I couldn’t log in. Actually, it only verifies the legitimacy of commits.
2. On the local machine, in any repo, you only need to enter the password once, and that makes it a verified commit. It doesn’t affect daily use; it just adds a green check mark for verification.
3. Using the https protocol + token seems more reliable than this method, but I’m not sure if it provides a verified mark.

Go Action

Click on Actions on the repository page, and then New Workflow to see recommended actions. Since this blog uses Go code, it shows the Go Action.

The rest involves following Travis’s approach to set up the workflow.

1. Check out the blog’s repo
2. Check out the publishing site repo
3. make
4. Commit the changes to the publishing site

Note that write permissions are required for the publishing site, so you need to configure a token, similar to Travis.

1. Generate a token with only repo permissions
2. Go to a particular repo and set up secrets (enter the token). Ideally, this should be set up on the publishing site, but it works when set in the blog repo. I haven’t explored why yet.

You will need two actions in total: one is GitHub’s own checkout, and the other is a third-party action called “Push directory to another repository”. There might be better options available, and I’ll explore them when I have more time.

Finally, here is my simple GitHub Action CI file:

name: CI

on:
  push:
    branches: [ master ]

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:

    - name: Set up Go 1.x
      uses: actions/setup-go@v2
      with:
        go-version: ^1.13

    - name: Check out code into the Go module directory
      uses: actions/checkout@v2

    - name: Get dependencies
      run: |
        go get -v -t -d ./...
        if [ -f Gopkg.toml ]; then
            curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
            dep ensure
        fi

    - name: Check out my other private repo
      uses: actions/checkout@v2
      with:
        repository: jackysp/jackysp.github.io
        token: ${{ secrets.UPDATE_BLOG }}
        path: public

    - name: Build
      run: make
    
    - name: Pushes to another repository
      id: public
      uses: cpina/github-action-push-to-another-repository@cp_instead_of_deleting
      env:
        API_TOKEN_GITHUB: ${{ secrets.UPDATE_BLOG }}
      with:
        source-directory: 'public'
        destination-github-username: 'jackysp'
        destination-repository-name: 'jackysp.github.io'
        user-email: your@email.com
        commit-message: See ORIGIN_COMMIT

I had to install Docker on Windows to reproduce a bug.

Process

1. Using Windows 10 as an example, if you have the Home Basic version, you’ll need to pay to upgrade to the Pro version because you need to enable Hyper-V and Container features, which costs about 800 RMB.
2. Install everything with the default settings, and do not switch to Windows Containers, since most images are still under Linux. If you do switch, you can restore it after starting up.
3. If you encounter permission issues with shared folders, follow the instructions at link. However, this might not solve the problem, and you might encounter a sharing failure. In that case, go to the settings, troubleshoot, and reset to factory defaults. After resetting, ensure the shared folders are selected.
4. When you encounter errors during use, just try a few more times. It might work; if not, reset it.

Impressions

Initially, there were no issues using Docker on Linux; Docker itself was simple back then. Later, using it on Mac brought changes, including a user interface, various colors, and numerous bugs. Right from the start, I encountered bugs. Docker did not support Windows a long time ago, and given the various bugs on Mac, I didn’t have high expectations. The results were still quite surprising. In summary, here are a few points:

1. It’s easier to use.
2. There are more bugs. Do not expect much, and be prepared to reset at any time. Fortunately, resetting offers a shortcut, making it a pretty usable tool.
3. It’s incredibly slow.

At this point, I have no optimism for Docker, Kubernetes, or similar technologies. Done~

I tried this, but it didn’t work at all on my Thinkpad X230. I then tried changing some other options in the aforementioned file, but none worked, and surprisingly, Ubuntu even reported errors.

So, I reinstalled the more preferred Debian. Tried again, and it still didn’t work. Finally, I found a more brutal method.

systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

This directly points these units to /dev/null…

To revert, simply use:

systemctl unmask sleep.target suspend.target hibernate.target hybrid-sleep.target

It’s simple and effective.

Update:

If you only mask them, the CPU usage of systemd-logind will be very high because it continuously attempts to sleep. Therefore, you also need to change HandleLidSwitch and others to ignore. As follows:

HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

Then, execute systemctl restart systemd-logind. For more details, refer to this: SystemD-LoginD High CPU Usage.

The purpose of dynamic updates is pretty simple. As a long-term user of China Unicom’s broadband, although Unicom provides a public address, it is essentially a dynamic address, not a fixed one. If you want to access your home devices using an IP address from outside, you need to use dynamic DNS (DDNS).

Many routers come with built-in DDNS functionality, but they mostly wrap the interfaces of the commonly used service providers. These providers generally have a few characteristics: 1. Blocked by the Great Firewall; 2. Not cheap; 3. Domestic providers may have security issues; 4. The company might have gone out of business. Rather than relying on these unreliable services, it’s better to write your own script for updating.

Thus, the scripting approach comes into play. Initially, I planned to use Cloudflare, as it is the recommended way. Later, I discovered that my domain provider Namesilo offers an API to update DNS. However, it returns data in XML format, and I wasn’t sure how to parse this with shell scripts.

Then, I thought of using Go. Since this DDNS client would likely be deployed on a router-like device, languages like Python or Java require a runtime environment, and C might need some dynamic libraries to run, which I wasn’t sure how to handle. The fact that Go doesn’t require dynamic libraries was a significant advantage. So, I handwrote a tool called und.

1. First, create a DNS record in Namesilo.
2. Obtain the binary of und suitable for your platform. I only provide binaries for arm64|linux and amd64|three mainstream OS in this case. For other platforms, you’ll need to compile it yourself. You can refer to the Makefile.
3. Generate an API key from Namesilo, then start und according to its usage documentation. You might need to run it in the background, so use nohup.

GitHub Features Experience

GitHub Actions

It feels like a replacement for chaotic third-party CI services. I directly chose the Go option for und. By default, it simply runs go build -v . in Ubuntu.

Release

I used this feature when releasing TiDB before, but didn’t remember to upload/automatically generate binaries. Since TiDB is not something that can run completely with just one component, releasing a single binary doesn’t make much sense.

This time, the experience led me to believe:

1. When releasing, tagging is best done directly using the release feature.
2. After the release, since you can edit it, it’s a good time to make each binary and upload them. Based on the Makefile setup, you can generate a version. This is quite an important feature.

These two steps are quite convenient.

C:\Users\name\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\`  

Start-Process -FilePath "C:\Users\name\bin\gost-windows-amd64.exe" -ArgumentList "-L=", "-F=" -RedirectStandardOutput "C:\Users\name\bin\gost-windows-amd64.log" -RedirectStandardError "C:\Users\name\bin\gost-windows-amd64.err" -WindowStyle Hidden

Note: Start-Process seems to perform a fork-like action, and by default, it opens a new PowerShell window to execute. That’s why -WindowStyle Hidden is added at the end. You can’t use -NoNewWindow here because it only prevents the creation of a new window for executing Start-Process, but the old window will not exit.
Note 2: After the old window exits, the forked process seems to become an orphan and is managed elsewhere, so permissions, such as network connection permissions, might need to be requested again.

One day, I came across an article by Chen Hao on Twitter. Having benefited from several of his blog posts, I instinctively felt it was reliable, so I read it and decided to write this practical guide.

Why Use an HTTPS Proxy

In the guide, it’s clearly explained why, plus my own experiences of several shadowsocks being banned, I felt it was necessary to switch to a more secure proxy method.

How to Deploy an HTTPS Proxy

gost

gost is the tool most recommended in the guide. At first, I misunderstood it as a method similar to kcptun, still relying on shadowsocks. In fact, gost implements multiple proxy types, meaning you don’t need other proxies if you have it. I never liked the method of continuously wrapping to accelerate/obfuscate shadowsocks, always feeling that longer pathways bring more problems.

Steps

• Directly download the latest release from the gost repo. Although I have a Golang environment both locally and on the VPS, downloading directly is the easiest. I downloaded version 2.9.0 here.

• Following certbot on a bare VPS doesn’t work… it requires:

  1. Starting an nginx server, as referenced in this guide. Of course, this requires having a domain name pointing an A record to the VPS.
  2. Verifying access through the domain.
  3. Stopping nginx.
  4. Using certbot’s –standalone mode, which will generate the certificates upon success.

• Here, I didn’t use Docker for deployment but used systemd instead, directly creating a systemd unit similar to kcptun. The difference is, because the certificate needs updating, the unit requires a reload method. This tutorial teaches a lot about using systemd, and the author’s article quality is also high, highly recommended for subscription.

  1. Create a /lib/systemd/system/gost.service file with the following content, replacing the domain with your own:

  [Unit]
  Description=gost service
  After=network.target
  StartLimitIntervalSec=0
  
  [Service]
  Type=simple
  Restart=always
  RestartSec=1
  User=root
  PIDFile=/home/admin/gost.pid
  ExecStart=/home/admin/bin/gost -L "http2://xxx:yyy@0.0.0.0:443?cert=/etc/letsencrypt/live/example.com/fullchain.pem&key=/etc/letsencrypt/live/example.com/privkey.pem&probe_resist=code:404"
  ExecReload=/bin/kill -HUP $MAINPID
  
  [Install]
  WantedBy=multi-user.target
  

  ExecStart is a simplified version of the Docker method in the guide. ExecReload just kills the process.

  1. Test whether it’s successful using systemctl start|status|restart|enable gost.

  2. Configure crontab to update the certificate. I didn’t use systemd because I’m not familiar with it.

  0 0 1 * * /usr/bin/certbot renew --force-renewal
  5 0 1 * * systemctl restart gost
  

• After completing the above, nginx can be directly stopped and disabled.

• Configure the client. This is simple; just refer to the guide. The principle is straightforward because gost implements the shadowsocks protocol using the shadowsocks Golang version. Therefore, the following command starts a local shadowsocks server, and you configure your client to add a local server configuration that matches the password.

  .\bin\gost-windows-amd64.exe -L=ss://aes-128-cfb:passcode@:1984 -F=https://xxx:yyy@example.com:443
  

PS: I still don’t know how to configure a global HTTPS proxy on Android without root, or how to set it up on iOS without a U.S. account. Also, I’m unsure how to elegantly configure startup scripts on Windows 10. These are issues to explore further…

Continuation

Regarding the mobile problem mentioned above, I found that HTTPS proxy client support is generally poor. Gost itself seems to have problems, possibly due to my usage. In short, if not using a local gost to connect remotely, authentication errors occur.

During the holiday break, I tinkered a bit more. First, I deployed a gost HTTP proxy on my home NAS using the simplest nohup + ctrl-D method to maintain it. It’s compiled with GOARCH=arm64. After a trial run for a day, Android’s weak built-in HTTP proxy worked well, but globally routing through it wasn’t great. Hence, I switched from HTTP to using SS to connect to HTTPS remotely. I essentially moved the local service on Windows to my NAS. Additionally, through simple double-port forwarding from NAS -> internal router -> optical modem router, I could also use the NAS as an SS server via the public IP.

The remaining issue is the DDNS. After researching, it seems Cloudflare’s API is a more reliable option. Seeing an official flarectl, I compiled it to the NAS and wrote a small script, revisiting the various (pitfalls) wonders of bash, especially remembering special writing for string comparisons such as [ $a != $b ] to [ $a != $b* ] to handle trailing “\r” “\n” characters. However, detaching the name server still takes some time. The final effect is to be tested.

Additionally, on the NAS, I currently use curl to fetch my public IP from a third-party. I have a hunch that this method might not work someday or might cause issues.

Among all these implementations, I personally think the most reliable and stable one is the original Python version. The reason is simple - it has the most users. The Golang version is said to have the most features and also performs very well, making it quite powerful. This might be due to Golang’s inherent high performance and ease of implementation. There’s also an implementation using libev, a pure C implementation, which also offers good performance and is very lightweight.

Additionally, updating the server is a necessary task for Shadowsocks users due to well-known reasons. The server should be updated frequently. If you’re using the Python implementation, you might be able to install updates via pip, although I haven’t confirmed this. The Golang version may require a Golang build environment, and then you can use go get -u. For updating libev, you can use apt on Debian-based systems, as apt includes shadowsocks-libev. I haven’t checked if it is available in the Red Hat-based yum repositories.

After this introduction, let’s go over the deployment steps, which are quite straightforward:

1. Deploy a Debian 9 or Ubuntu 17 VPS. Mainstream providers like Vultr should have these options available. Assume we are using Debian 9 here.
2. Run apt install shadowsocks-libev to install.
3. Edit the configuration file using vim /etc/shadowsocks-libev/config.json. It’s best to set the Server IP to 0.0.0.0 to avoid IP issues similar to those on AWS Lightsail. *. For AWS Lightsail, you need to bind a static IP and open firewall ports. Specific steps can be found on Google.
4. Restart the service using systemctl restart shadowsocks-libev to apply the changes.
5. Enable TCP BBR. Specific instructions can be found on Google.

Travis CI is generally used for automating tests without needing to update the repository with the test outputs. This article explains how to automatically commit the results from Travis CI.

Process

The basic process references this gist.

Below is the .travis.yml from the gist.

language: ruby
rvm:
  - 2.0.0
env:
  global:
  - USER="username"
  - EMAIL="username@mail.com"
  - REPO="name of target repo"
  - FILES="README.md foo.txt bar.txt"
  - GH_REPO="github.com/${USER}/${REPO}.git"
  - secure: "put travis gem output here => http://docs.travis-ci.com/user/encryption-keys/"
script:
  - ruby test.rb
after_success:
  - MESSAGE=$(git log --format=%B -n 1 $TRAVIS_COMMIT)
  - git clone git://${GH_REPO}
  - mv -f ${FILES} ${REPO}
  - cd ${REPO}
  - git remote
  - git config user.email ${EMAIL}
  - git config user.name ${USER}
  - git add ${FILES}
  - git commit -m "${MESSAGE}"
  - git push "https://${GH_TOKEN}@${GH_REPO}" master > /dev/null 2>&1

Note here that MESSAGE should be quoted when committing, which the original gist did not include.

Original README:

# Travis-CI tested push
Sometimes we have a private repository to hold both problems and solutions as a reference for the class projects.
The students can see only the problems in a public repository where they are able to clone/fork and develop their own solutions.
We do not want the solution files in the public repository and each bug found/feature added in the project requires a push for each repository.
It would be cool to work only with the reference repo and use tests to see if our modification is good enough for the public release.
This is possible with Travis-CI following simple steps:
- Create private and public repos
- Download Ruby
- Install the travis gem ``gem install travis``
- Generate a token in the Github website to allow others to play with your repos (copy the hash)
- Log into your git account
- Generate a secure token with the Travis gem (copy long hash)
- Fill the environment variables in the ```.travis.yml``` file (USER, EMAIL, REPO, FILES)
- Replace the value of **secure** with your long hash
- Replace **GH_TOKEN** with your Travis token name
- Push ```.travis.yml``` to private repo
- Go to Travis to unlock your private repo tests
- Push your files to the private repo to test

Travis now has a [deployment](https://docs.travis-ci.com/user/deployment/) feature, which may be better for certain scenarios.

A simple translation:

1. Create a GitHub project. The original seems to have created two projects, one for updating another.
2. Install Ruby. Usually, gem is installed alongside.
3. Install travis via gem install travis.
4. Apply for a token for your GitHub account. You can Google the details. When selecting token permissions, only tick all related to repo; others can be omitted.
5. Copy the generated token.
6. In the root directory of the local machine’s repo (not sure if it must be the root) run travis encrypt GH_TOKEN="copied token". This creates an encrypted token to use as ${GH_TOKEN}, essentially an environment variable. The command output, a string on the screen, needs to be pasted into the travis config file after secure:. Use travis encrypt GH_TOKEN="copied token" --add to write directly into the config file.
7. Commit the modified configuration file.

This translation is not strictly literal. The above content is more suited to the following personal configuration:

language: ruby
branches:
  only:
  - master
rvm:
- 2.4.1
exclude:
- vendor
sudo: false
env:
  global:
    - secure: rxKkyttLE1L4VsVIhhDUYGoLlER33ijKbdAAJPE8vNDSHwyANYnsP1GXK/rcwQqsL/KcJa55wEjVwEBzTMCqZM4UYNVIWqrJepVYo4rL1WhO+jT5sCqVR3qxK9KbgodcSXbmySJnJs0iLGMIQ2bo8yE91OxIC/GKkLCIwr9x4EGwFd5EcE5bOqmVqoSRk1q/1/5yA0aVF+Pohc5ATCZGw9+IyprU2Dx7qbA7F/T/4FQTOQZ4CLZAgyh/Gp1P+uxf1OK4IMCc/P6jVeTmbzQIbUcX0uG09pR7F0GnlV1ZOutMjY7SF8tQ7LNv2Wf8iWdiqehcwKNe/4TFHjs6rm3lEc6F1ELB5s4Z+QXjIM70haENSwM1FI8K5biL7tndAC1TujKESm0XadxORy5yOz7TfQZDTuMXvmmH3j+NFL3vTYPyMwwFca+IQBwD67a4PKD0PWBgEFD9Kn3rAlAzhV5OYdUuxZhx5zuQjKX5szUbL166fgoRnUwDp8dsOjLgOUqQa47IRqR3CTPzbf3zZIxGuX5x6mWySezCNprnXKCpyCegJBLoxQusA+EEYkvl4AOzhnmkhxFbEbHp+DYBjcSEEgpd06l67l3KzjMkpF02vr9CHNj8r7lAtZxwBVxYmczk289D5csOVR1SZKxQLwhx7k+CuEcYds685tLjIMmB0ZU=
    - USER="username"
    - FULLNAME="Your Name"
    - EMAIL="your-email@example.com"
    - REPO="your-username.github.io"
    - GH_REPO="github.com/${USER}/${REPO}.git"
before_script:
  - git clone https://${GH_TOKEN}@${GH_REPO}
script: bundle exec jekyll b -d ${REPO}
after_success:
  - MESSAGE=$(git log --format=%B -n 1 $TRAVIS_COMMIT)
  - cd ${REPO}
  - git config user.email ${EMAIL}
  - git config user.name ${FULLNAME}
  - git add --all
  - git commit -m "${MESSAGE}"
  - git push --force origin master

This configuration is used for automatically updating a blog created with Jekyll. There are two projects, one for source files and another for compiled HTML files. The purpose of this setup is to allow updating the blog without having to set up a Jekyll environment, even allowing updates directly from the GitHub website.

1. Disable SeLinux
   Edit the configuration file:

   vi /etc/selinux/config
   

   Modify as follows:

   #SELINUX=enforcing    # Comment out
   #SELINUXTYPE=targeted # Comment out
   SELINUX=disabled      # Add this line
   

   Then reboot the system:

   reboot  # Restart the system
   

2. Create a Directory
   Using the root user, create a directory named /nfs. Note: It’s best to check which partition has the most space by running df, as the root (/) partition may not have the most space. In some automatic partitioning setups, the /home partition may have the most space.

3. Install NFS Utilities and RPC Bind

   yum -y install nfs-utils rpcbind
   

4. Enable Services at Boot

   chkconfig nfs on
   chkconfig rpcbind on
   chkconfig nfslock on
   

5. Configure Exports
   Edit the NFS exports file:

   vi /etc/exports
   

   Add the following line:

   /home/nfs 192.168.1.0/24(rw,sync,no_all_squash)
   

6. Start NFS Services

   service rpcbind start
   service nfs start
   service nfslock start
   exportfs -a
   

7. Configure NFS Ports
   Edit the NFS configuration file:

   vi /etc/sysconfig/nfs
   

   Uncomment the following lines:

   LOCKD_TCPPORT=32803
   LOCKD_UDPPORT=32769
   MOUNTD_PORT=892
   

8. Restart NFS Services

   service rpcbind restart
   service nfs restart
   service nfslock restart
   

9. Verify RPC Services

   rpcinfo -p localhost
   

   Note down the ports and their types.

10. Configure Firewall Rules
    Adjust the IP range according to your network:

    iptables -I INPUT -m state --state NEW -p tcp -m multiport --dport 111,892,2049,32803 -s 192.168.0.0/24 -j ACCEPT
    iptables -I INPUT -m state --state NEW -p udp -m multiport --dport 111,892,2049,32769 -s 192.168.0.0/24 -j ACCEPT
    

11. Save Firewall Rules
    Test from the client side. If successful, save the iptables configuration:

    service iptables save
    

Client Side

1. Create Mount Point

   mkdir /nfs
   

2. Check RPC Services on Server

   rpcinfo -p [server_ip]
   

3. Show NFS Exports

   showmount -e [server_ip]
   

4. Mount NFS Share

   mount -t nfs -o soft,intr,bg,rw [server_ip]:/home/nfs /nfs
   

5. Unmount NFS Share

   umount /nfs
   

6. Configure Automatic Mounting
   Edit the fstab file:

   vi /etc/fstab
   

   Add the following line:

   [server_ip]:/home/nfs /nfs nfs soft,intr,bg,rw 0 0
   

Bridging highly simulates a network card, making the router believe that the virtual machine’s network card truly exists. Personally, I feel it’s similar to resistors connected in parallel, whereas NAT (another common virtual machine network connection method) is more like parasitizing on the host’s network card.

Why Use Bridging

It allows you to treat the virtual machine as a completely independent machine, enabling mutual access with the external network (which is not possible with NAT).

How to Configure Bridging

In CentOS 6, refer to the command-line method in this article.

We don’t use the GUI method because:

• We’re unsure which options to fill in on the last screen.
• We don’t know how to reset if we make a wrong selection.

Command-line steps:

1. Check if bridge-utils is installed:

   rpm -q bridge-utils
   

   Usually, it’s already installed. If not, install it:

   su -
   yum install bridge-utils
   

2. Verify your network interfaces:

   Run ifconfig to ensure you have at least three network interfaces:

   eth0      Link encap:Ethernet  HWaddr 00:18:E7:16:DA:65
             inet addr:192.168.0.117  Bcast:192.168.0.255  Mask:255.255.255.0
             inet6 addr: fe80::218:e7ff:fe16:da65/64 Scope:Link
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:556 errors:0 dropped:0 overruns:0 frame:0
             TX packets:414 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:1000
             RX bytes:222834 (217.6 KiB)  TX bytes:48430 (47.2 KiB)
             Interrupt:16 Base address:0x4f00
   
   lo        Link encap:Local Loopback
             inet addr:127.0.0.1  Mask:255.0.0.0
             inet6 addr: ::1/128 Scope:Host
             UP LOOPBACK RUNNING  MTU:16436  Metric:1
             RX packets:8 errors:0 dropped:0 overruns:0 frame:0
             TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:480 (480.0 b)  TX bytes:480 (480.0 b)
   
   virbr0    Link encap:Ethernet  HWaddr 52:54:00:2A:C1:7E
             inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
             TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:0 (0.0 b)  TX bytes:2793 (2.7 KiB)
   

3. Navigate to the network scripts directory:

   su –
   cd /etc/sysconfig/network-scripts
   

4. Bring down the eth0 interface:

   ifdown eth0
   

   This step is crucial and must be performed locally. When I first configured this, I didn’t shut down the network (since I was working remotely). I didn’t realize that updating the ifcfg-eth0 configuration without restarting the network would immediately apply changes, resulting in loss of network connectivity.

5. Edit ifcfg-eth0:

   In the ifcfg-eth0 file, include:

   DEVICE=eth0
   ONBOOT=yes
   BRIDGE=br0
   

   Keep only these three lines in the file. There’s no need to configure an IP address here. Bridging seems to replace the original network card with the bridge, so you can delegate the configuration to the bridge.

6. Create a new file ifcfg-br0:

   DEVICE=br0
   ONBOOT=yes
   TYPE=Bridge
   BOOTPROTO=static
   IPADDR=xxx.xxx.xxx.xxx   # Use the IP you originally had in ifcfg-eth0
   GATEWAY=xxx.xxx.xxx.xxx  # Your gateway address
   NETMASK=255.255.255.0    # Your netmask
   DNS1=xxx.xxx.xxx.xxx     # Your primary DNS server
   DNS2=xxx.xxx.xxx.xxx     # Your secondary DNS server (if any)
   STP=on
   DELAY=0
   

   Note: Replace xxx.xxx.xxx.xxx with your actual network settings.

7. Bring up the interfaces:

   ifup br0
   ifup eth0
   

8. Verify the bridge interface:

   Check ifconfig to ensure that br0 is now present.

9. Update firewall rules:

   Edit /etc/sysconfig/iptables and add:

   -A INPUT -i br0 -j ACCEPT
   

   (This is a general example; you may need to adjust it based on your specific firewall configuration.)

10. Restart the firewall:

    service iptables restart
    

11. Configure bridging in virt-manager:

    When creating a new virtual machine using virt-manager, you can now select br0 for the network interface. Without this bridge, the bridging option would not be available.

Note: When configuring the IP inside the virtual machine, be sure to specify the GATEWAY. Otherwise, the virtual machine will only be able to access the internal network and not the external network. At this point, the virtual machine won’t automatically discover the gateway.

Installed Version: CentOS 6.3

1. Using Win32DiskImager to create a USB flash drive image was unsuccessful; installing from an external USB optical drive was successful.
2. During the installation process, make sure to select the “Virtual Host” installation mode.
3. The rest can be set to default or slightly modified, such as choosing the time zone.
4. After installation, it will include the KVM suite and SSH.

Installation Notes

• No internet connection is needed throughout the process, which is much better than Debian and Ubuntu.
• You’re not forced to set up a non-root user.
• Before installation, be sure to check whether your CPU supports virtualization and enable the motherboard’s virtualization setting. If the motherboard supports virtualization but doesn’t have a virtualization option, you can still use virtualization as it’s definitely enabled by default. There’s a saying that Intel CPUs with a ‘K’ cannot perform virtualization. ‘K’ means Intel CPUs that can be overclocked. It seems that faster and newer CPUs are not necessarily better.