Check my current public IP. Convert a timestamp. Look at browser timezone info. Pretty-print a piece of JSON. None of these tasks are big, but together they somehow turn into a part-time job inside the browser.

So this time I tried a different approach: instead of collecting more bookmarks, I used Codex for a bit of vibe coding and built a small toolbox site that feels nice to use and stays out of the way.

It is live here:

https://tools.knktc.com

Here is the homepage:

The goal is not to make the biggest toolbox on the internet. It is more like a drawer of utilities that I actually expect to keep using myself. The guiding ideas were pretty simple:

1. Put common utilities in one place so I do less tab-hopping.
2. Keep things local in the browser whenever that is enough.
3. Favor “open and use” over flashy presentation.

Right now the site includes tools like:

• Client IP
• IP & Mask Check
• Base64 Converter
• JSON Pretty
• URL Encoder / Decoder
• Timestamp Converter
• Clock Drift Check
• Browser Info & Timezone
• UUID Generator

A couple of them are especially fun.

The first one is the clock drift checker. It compares your local device time with the server reference time, which is handy for problems that look random at first but are actually time-related, such as login failures, signed-request issues, or certificate oddities.

This is exactly the kind of utility you may not need every day, but when you do need it, it saves you from wandering in circles.

Another one I like is the browser info and timezone page. Whenever someone says “the time looks wrong here” or “the page behaves differently on my side,” checking timezone, language, user agent, and screen details is often a very good first move.

I also tucked Clock drift into that view, so it does not only show what the browser reports, but also how far it appears to be from the server reference time. It is a small detail, but a useful one.

Building this with Codex was also a genuinely pleasant experience. Compared with the more traditional “write a full spec first, then implement everything step by step” rhythm, vibe coding feels more like this:

• explain the idea clearly;
• let Codex build and revise quickly;
• keep iterating until the UI, behavior, and details feel right.

It ends up feeling a bit like pair programming with someone who never gets tired. You keep steering with comments like “this should feel smoother” or “this part needs to be clearer,” and the code keeps catching up.

The site is definitely not a finished monument, and that is part of the appeal. I would rather treat it as a small toolbox that can keep growing whenever I run into another oddly specific but genuinely useful little problem.

If this sounds like your kind of thing, you can bookmark it here:

https://tools.knktc.com

At the very least, the next time you need to check an IP, convert a timestamp, or confirm whether your local clock has drifted, you will have one less tab to hunt for.

1

Co-authored-by: Copilot <copilot@github.com>

It looked like this:

My first reaction was basically: Microsoft has quietly added another little default.

What this setting does is simple: when Copilot Chat or Agent participates in a code change, VS Code can automatically append an AI co-author trailer to the commit message. In some team workflows, that may be useful as a transparency signal. For everyday personal commits, though, it can make the history noisier than expected, especially because the default behavior is easy to miss.

To turn it off:

1. Open VS Code Settings.
2. Search for Add AI Co Author.
3. Find Git: Add AI Co Author.
4. Change the default value from chatAndAgent to off.

The setting looks like this:

After that, commits made from VS Code should stop automatically adding:

1

Co-authored-by: Copilot <copilot@github.com>

If your team wants to keep AI involvement visible in commit history, leaving it enabled is reasonable. If you prefer cleaner commit messages, switching it to off does the job.

The project is written in Go and keeps its goals simple: minimal dependencies, fast startup, and a straightforward way to inspect incoming HTTP requests.

If you often need to verify third-party callbacks, debug inbound requests to your own service, or just capture a few HTTP requests to see what is actually being sent, this tool is quite handy.

What this project does

tiny-requestbin is a lightweight HTTP request inspection and debugging tool. Once started, it captures HTTP requests sent to the service and presents them in a way that is easy to inspect, including:

• request method
• request path
• request headers
• request body
• and the full request details

The repository README also highlights a few core features clearly:

• Lightweight and fast: simple implementation with very few dependencies
• Request inspection: view detailed information about incoming HTTP requests
• Web UI: inspect captured requests in the browser
• CLI mode: print request details directly in the terminal
• Local-only runtime: everything stays on your machine without depending on an external service

I personally like tools with this kind of sharp scope. It does not try to be a huge platform. It just focuses on doing one thing well: helping you inspect requests.

Several easy installation options

The repository homepage offers multiple installation methods, which cover most common local debugging and deployment scenarios.

1. Docker

If you just want to get it running quickly, the README recommends using Docker directly:

1

docker run -p 8282:8282 knktc/tiny-requestbin

You can also pass custom parameters such as the listen address, port, and maximum number of stored requests:

1

docker run -p 8282:8282 knktc/tiny-requestbin -port 8282 -listen 0.0.0.0 -max 1000

The repository also ships with a docker-compose.yml, so docker-compose up -d works as well.

2. Helm

If you already have a Kubernetes environment, the project also provides a Helm chart:

1

helm install my-requestbin helm/tiny-requestbin/

The README includes examples for customizing config.max, service.type, and enabling HTTPRoute, which makes the Kubernetes path pretty convenient.

3. go install

Since the project itself is written in Go, installing it that way is also very natural:

1

go install github.com/knktc/tiny-requestbin@latest

4. Build from source

If you prefer compiling it yourself, that is straightforward too:

1
2
3

git clone https://github.com/knktc/tiny-requestbin.git
cd tiny-requestbin
go build

How to use it

The default startup command is intentionally simple:

1

tiny-requestbin

Default flags:

• -port: listening port, default 8282
• -listen: listening address, default 127.0.0.1
• -max: maximum number of stored requests, default 100
• -cli: whether to enable CLI output mode, default false

For example, the following command makes the service listen on 0.0.0.0:9000, keeps up to 1000 requests, and also prints them to the terminal:

1

tiny-requestbin -port 9000 -listen 0.0.0.0 -max 1000 -cli

Its basic workflow is very simple:

1. Start the service.
2. Send requests to http://[listen-address]:[port]/any/path.
3. Visit the root path in the browser to inspect captured requests.
4. If -cli is enabled, the terminal will print them as well.

That makes it useful both for temporary local troubleshooting and as a small internal request sink inside a private network.

Two ways to inspect requests: terminal and web

The repository homepage includes two screenshots, and I also placed them here so the actual experience is easier to picture.

CLI mode screenshot

When -cli is enabled, incoming HTTP requests are printed directly in the terminal in a formatted way:

This mode is especially convenient when working on a server, in a container, or through a remote shell where opening a browser is less convenient.

Web UI screenshot

If you prefer a graphical view, you can simply open the web page and inspect request history there:

From the screenshot, the UI looks intentionally minimal. The focus is on showing request contents clearly without unnecessary distractions.

Good use cases

Based on the repository itself, I think tiny-requestbin is particularly useful for:

• debugging webhook callbacks from third-party platforms
• verifying what an application is actually sending over HTTP
• quickly spinning up a local request receiver during development
• temporarily observing request traffic in containers or Kubernetes
• inspecting request details directly in the terminal with -cli

The fact that it is explicitly local only is also reassuring for many internal debugging scenarios, because the captured data stays on your machine.

A few extra points worth mentioning

There are also a few details on the GitHub page that I think are nice touches:

• the container image supports multiple architectures, including linux/amd64 and linux/arm64
• multi-architecture images are built and published automatically with GitHub Actions
• the repository offers multiple entry points: Docker, Helm, and source builds
• the project uses the MIT License, which makes adoption and redistribution straightforward

The README also mentions that the project initially started with Gemini and was later iterated on with GitHub Copilot. That somehow fits the project’s overall character as well: lightweight, direct, and quick to evolve.

Final thoughts

If you are looking for a lightweight, Go-based, locally runnable HTTP request debugging tool that supports both web and CLI usage, I think tiny-requestbin is worth trying.

Project link:

• GitHub: https://github.com/knktc/tiny-requestbin

Feel free to star the repository, and PRs or issues are always welcome.

Once the switch was done, we noticed that the default setup was no longer behaving well in a high-availability scenario. If multiple memcached backends were configured and one of them went down, any cache-related code could fail with an exception instead of degrading gracefully.

After checking the official documentation, the reason became clear: by default, pymemcache raises exceptions on connection failures unless you explicitly set ignore_exc = True.

So the fix is simply to add that option to your Django CACHES settings:

1
2
3
4
5
6
7
8
9
10
11
12

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': [
            'host1:11211',
            'host2:11211',
        ],
        'OPTIONS': {
            'ignore_exc': True,
        }
    }
}

If you expect memcached nodes to fail independently and still want your application to continue running, this setting is easy to miss but important to have.

Compared with ARM, the Sunway architecture is much more niche. In practice, support seems limited mainly to UOS and Kylin. The customer provided a SW64 build of Kylin V10, so this post records the issues I ran into while installing pandas in that environment.

Create a virtual environment

Kylin V10 comes with Python 3.7.4. Start by creating a venv:

1
2

python3 -m venv --copies knktc-env
source knktc-env/bin/activate

Install numpy

My first instinct was to install numpy directly with pip:

1

pip install numpy

That failed with an error like this:

error: #error Unknown CPU, please report this to numpy maintainers with information about your platform (OS, CPU and compiler)

So yes, the architecture was niche enough that numpy’s build logic did not recognize it.

After some searching, I found discussions on the UOS forums saying that building with pip did not work, and that the only practical route was using a prebuilt package from the OS vendor. Kylin indeed provides one:

1

yum search numpy

Example output:

1

python3-numpy.sw_64 : A fast multidimensional array facility for Python

So install that package first:

1

yum install python3-numpy

After installation, copy the vendor-provided numpy package from the system site-packages directory into the virtual environment manually:

1

cp -r /usr/lib/python3.7/site-packages/numpy* knktc-env/lib/python3.7/site-packages

Then check the version:

1
2
3

>>> import numpy
>>> numpy.__version__
'1.16.5'

That takes care of numpy.

Install pandas

For pandas, the remaining workable route was to build from source.

Install the dependencies first:

1
2
3
4
5

pip install setuptools --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install wheel --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install Cython --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install pytz==2018.7 -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install python-dateutil -i https://pypi.tuna.tsinghua.edu.cn/simple

Then download the source package from:

https://github.com/pandas-dev/pandas/releases

We were still using pandas 1.1.5, so I used:

https://github.com/pandas-dev/pandas/releases/download/v1.1.5/pandas-1.1.5.tar.gz

After extracting the source, install it the old-fashioned way:

1
2

cd pandas-1.1.5/
python setup.py install

This step takes a while, so it is a good idea to run it inside screen.

Thankfully, even though the build was slow, it finished without major errors.

Finally, verify the version:

1
2
3

>>> import pandas
>>> pandas.__version__
'1.1.5'

At that point, pandas was working.

1
2

Permission denied (publickey).
fatal: Could not read from remote repository.

After repeatedly confirming that my public key was still present on GitLab, I found discussions مثل this one:

https://superuser.com/questions/1749364/git-ssh-permission-denied-in-macos-13-ventura

The likely cause is that the bundled OpenSSH_9.0p1 in macOS 13 disables RSA/SHA-1 by default.

There are two main ways to fix it.

Option 1: Generate a new key

This is the cleaner option, though it can be more expensive if you need to update the key in multiple places:

1

ssh-keygen -t ed25519

Option 2: Re-enable RSA in SSH config

Edit ~/.ssh/config and add:

1
2
3

Host *
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

This can also help when the remote server is too old to support newer algorithms.

1
2
3
4

memcache.py:1303: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if key is '':
memcache.py:1304: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if key_extra_len is 0:

After checking the python-memcached source code, which is basically a single file, the problematic lines were easy to find:

1
2

if key is '':
    if key_extra_len is 0:

That pattern is no longer acceptable in Python 3.8.

Even though it is “just” a warning, it is still noisy and unpleasant in logs, so I wanted to fix it.

I then checked the official GitHub repository and found that the project has not really been maintained for quite a while. Even though there is already a PR for this issue, it has not been merged:

https://github.com/linsomniac/python-memcached/issues/176

So there are basically two practical options:

1. Patch memcache.py directly in your environment and replace is with == in those lines.
2. Since we distribute a requirements.txt, I published a fixed package to PyPI, which you can install directly if needed:

1

pip install python-memcached-py38fix

At this point, moving to pymemcache is probably the more sensible long-term direction anyway, especially since Django has already dropped support for python-memcached.

1
2
3

location ~ ^/myconf/(?<filename>.*)$ {
    alias /home/knktc/myconf/$filename;
}

The problem is that when the requested file does not exist, Nginx returns its default 404 page. To make this easier for frontend code to handle, I changed the configuration so that missing files return an empty JSON object instead:

1
2
3
4
5
6
7
8
9

location ~ ^/myconf/(?<filename>.*)$ {
    alias /home/knktc/myconf/$filename;
    error_page 404 = @not_found_fallback;
}

location @not_found_fallback {
    add_header Content-Type text/plain;
    return 200 "{}";
}

Now, if the file is missing, the response is an empty JSON object.

But there is still another issue: Nginx will log the 404 event in error.log even though the client gets the fallback response.

So the configuration needs one more change to suppress the not-found log:

1
2
3
4
5
6
7
8
9
10

location ~ ^/myconf/(?<filename>.*)$ {
    alias /home/knktc/myconf/$filename;
    error_page 404 = @not_found_fallback;
    log_not_found off;
}

location @not_found_fallback {
    add_header Content-Type text/plain;
    return 200 "{}";
}

That does the trick. Using Nginx’s static file handling for simple lightweight interfaces can be quite convenient.

In this setup, the operating system is Ubuntu 20.04, DNS is managed with Cloudflare, and Nginx is used as the web server.

Following the steps below is enough to get it working.

Install Certbot

You can install it with the following commands. In some environments, snap install can be slow and may need to be retried once or twice:

1
2
3
4

apt install snapd
snap install core
snap refresh core
snap install --classic certbot

After installation, run certbot --version. If it prints a version number, the installation is successful.

Install the Cloudflare plugin

To renew certificates automatically, you also need the plugin for your DNS provider. Since I use Cloudflare for DNS, I installed the Cloudflare plugin like this:

1
2
3

snap set certbot trust-plugin-with-root=ok

snap install certbot-dns-cloudflare

Create a Cloudflare API token

To use the Cloudflare plugin, first log in to Cloudflare and create an API token that is only allowed to manage DNS records.

You can create it here after signing in:

https://dash.cloudflare.com/profile/api-tokens

Once the token is created, save it somewhere safe and then create the Certbot credentials file:

1
2
3

mkdir -p ~/.secrets/certbot

vim ~/.secrets/certbot/cloudflare.ini

The file should contain:

1

dns_cloudflare_api_token = YOUR_API_TOKEN

After saving it, tighten the file permissions. Otherwise Certbot will warn that the credentials file is insecure:

1

chmod 600 ~/.secrets/certbot/cloudflare.ini

Request the certificate

Now you can generate the certificate Nginx will use:

1
2
3
4
5

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d knktc.com

Note the use of --dns-cloudflare-propagation-seconds 60. I increased the wait time to 60 seconds because the default 10 seconds sometimes caused validation failures.

The issued certificate and private key will be placed under:

/etc/letsencrypt/live/YOUR_HOST/

For reference, here is a related Nginx configuration snippet:

1
2
3
4
5
6
7
8
9

listen 443 ssl http2;
server_name knktc.com;
ssl_certificate /etc/letsencrypt/live/knktc.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/knktc.com/privkey.pem; # managed by Certbot

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         HIGH:!aNULL:!MD5;
keepalive_timeout   70;
ssl_session_timeout  5m;

Scheduled renewal

You can verify whether Certbot’s scheduled renewal task has been added successfully with:

1

systemctl list-timers

If you want Nginx to reload automatically whenever a new certificate is issued, add a renewal hook script:

1

vim /etc/letsencrypt/renewal-hooks/post/reload-nginx

Put the following into the file:

1
2
3

#!/bin/sh

systemctl reload nginx

Then make it executable:

1

chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx

With that in place, Nginx will automatically reload after every successful certificate renewal.

1

pip config --user set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

Then download the Poetry installer script locally, for example as install-poetry.py:

1

curl -sSL https://install.python-poetry.org -o install-poetry.py

Open the script and find this function:

1
2

def pip(self, *args, **kwargs) -> subprocess.CompletedProcess:
        return self.python("-m", "pip", "--isolated", *args, **kwargs)

Remove "--isolated" from that call. After that, when the installer invokes pip, it will use the mirror you configured earlier.

Then run the installer:

1

python3 install-poetry.py

Because the system is deployed with multiple instances, those agents may need to run the same task at the same time. Since we were already using Celery, its broadcast feature turned out to be a good fit: the same task can be delivered to every worker.

To test the idea, I first wrote a simple task:

1
2
3
4
5
6
7
8
9

# filename: agent.py
import datetime
from celery import shared_task

@shared_task(bind=True)
def test(self):
    name = self.request.hostname
    with open(f'/tmp/{name}', 'w') as f:
        f.write(str(datetime.datetime.now()))

This task reads the worker hostname from self.request.hostname, then creates a file under /tmp with that hostname as the filename and the execution time as the content.

In other words, if the broadcast works correctly, multiple files should appear in /tmp at the same time, one for each worker bound to the queue.

Then I added the following Celery app configuration:

1
2
3
4
5
6
7
8
9

from kombu.common import Broadcast

app.conf.task_queues = (Broadcast('broadcast_tasks'),)
app.conf.task_routes = {
    'agent.test': {
        'queue': 'broadcast_tasks',
        'exchange': 'broadcast_tasks'
    }
}

This defines a queue named broadcast_tasks, and the agent.test task is routed through the broadcast_tasks exchange.

On the worker side, I started two workers bound to broadcast_tasks, one named agent1 and the other agent2:

1
2

celery -A boss2_manager worker --pidfile=/var/run/celeryworker_agent1.pid -Q broadcast_tasks -n agent1@%h
celery -A boss2_manager worker --pidfile=/var/run/celeryworker_agent2.pid -Q broadcast_tasks -n agent2@%h

If RabbitMQ is used as the broker, you can also see this in its management UI: a Celery broadcast queue is effectively a fanout exchange plus one queue per worker bound to it.

Then I simply triggered the task with delay():

1
2
3

from agent import test

test.delay()

Checking /tmp afterward, I found two files:

1
2

agent1@knktc-rmbp.local
agent2@knktc-rmbp.local

The timestamps inside them were almost the same.

That was enough to confirm the approach, so I ended up using this method for the Agent feature.

Reference

• Celery broadcast documentation: https://docs.celeryq.dev/en/stable/userguide/routing.html#broadcast

The plugin itself is easy enough to configure, but translating OIDs into readable names depends on snmptranslate, and snmptranslate in turn depends on having the correct MIB files installed and configured properly.

I recently used this setup to collect alerts from H3C switches, so I thought it would be useful to record how to import MIB files on Ubuntu.

Before configuration

Before changing anything, try running snmptranslate first. The -L n option simply suppresses error output:

1

snmptranslate -L n .1.3.6.1.4.1.25506.2.38.1.6.3.0.1

This example OID comes from an H3C switch. If the MIB files are not installed, the result will only look like this:

1

SNMPv2-SMI::enterprises.25506.2.38.1.6.3.0.1

That is obviously not very helpful if you want to know what the device actually sent.

Import and configure

First, obtain the MIB files from H3C and extract them into a directory. In this example, I put them under:

/usr/share/mibs/h3c_mibs

After placing the MIB files there, edit the snmp.conf file:

1

vim /etc/snmp/snmp.conf

If the file does not exist, you may need to install the required package first:

1

apt install snmp

The original configuration usually looks like this:

1
2
3
4

# As the snmp packages come without MIB files due to license reasons, loading
# of MIBs is disabled by default. If you added the MIBs you can reenable
# loading them by commenting out the following line.
mibs :

To enable your custom MIB files, change it like this:

1
2
3
4
5
6

# mibs :

mibdirs +/usr/share/mibs/h3c_mibs
mibdirs +/usr/share/mibs/another_mib_dir  # for example

mibs +ALL

A quick explanation:

• Comment out the original mibs : line so the system is allowed to load third-party MIBs.
• Use mibdirs to specify directories that contain MIB files. You can use it multiple times if needed.
• Use mibs +ALL to search through all available MIB files.

Once the file is updated, save and exit. No service restart is required.

Test

Now try translating the OID again. If the MIB files are placed correctly and the config is right, it should work:

1
2

root@knktc.com:/root# snmptranslate -L n .1.3.6.1.4.1.25506.2.38.1.6.3.0.1
HH3C-TRAP-MIB::hh3cPeriodicalTrap

References

• Telegraf snmp_trap plugin: https://github.com/influxdata/telegraf/tree/master/plugins/inputs/snmp_trap
• snmp.conf man page: https://linux.die.net/man/5/snmp.conf

So I ended up creating a new SSH key pair on the build server and configuring Git-related SSH access to use that new key explicitly.

In the examples below, assume the Git server hostname is gitlab.knktc.com.

First, create a new SSH key pair:

1
2

mkdir -p /home/knktc/gitlab_ssh_keys
ssh-keygen -f /home/knktc/gitlab_ssh_keys/id_rsa

In this example, the new private key is stored at:

/home/knktc/gitlab_ssh_keys/id_rsa

Then create or edit the SSH config file under the current user’s home directory:

1

vim ~/.ssh/config

Add the following configuration:

1
2

Host gitlab.knktc.com
    IdentityFile /home/knktc/gitlab_ssh_keys/id_rsa

This means that when connecting to gitlab.knktc.com over SSH, the newly created key will be used.

Finally, test cloning the repository:

1

git clone git@gitlab.knktc.com:blog/knktc-com.git

That should work.

For more details about SSH config, see:

https://linux.die.net/man/5/ssh_config

We previously relied on uWSGI legion mode to make sure only one Beat instance was active at a time, but that depends on having a reliable network connection. Recently I ran into a case where the network between two Beat nodes could be unstable, so uWSGI legion no longer felt safe enough. That led me to look for a way to make Celery Beat enter a “standby” mode: the service stays up, but it stops generating scheduled tasks.

After reading the Celery Beat source code, I found that the celery CLI eventually calls the start method on the Service class from celery.beat. So the easiest approach seemed to be patching that method.

Here is a simple monkey patch:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

import os
import time
from celery.beat import info, debug, humanize_seconds, signals, platforms

STANDBY_CHECK_INTERVAL = 5


def is_standby():
    return True if os.path.isfile('/tmp/standby.flag') else False


def patched_start(self, embedded_process=False):
    """ monkey patched start method, will skip tasks when standby flag is set """
    info('beat: Starting...')
    debug('beat: Ticking with max interval->%s',
          humanize_seconds(self.scheduler.max_interval))

    signals.beat_init.send(sender=self)
    if embedded_process:
        signals.beat_embedded_init.send(sender=self)
        platforms.set_process_title('celery beat')

    try:
        while not self._is_shutdown.is_set():

            if is_standby():
                debug(f'beat: in standby mode, all tasks will be skipped, '
                      f'will check in [{STANDBY_CHECK_INTERVAL}] seconds')
                time.sleep(STANDBY_CHECK_INTERVAL)
                continue

            interval = self.scheduler.tick()
            if interval and interval > 0.0:
                debug('beat: Waking up %s.',
                      humanize_seconds(interval, prefix='in '))
                time.sleep(interval)
                if self.scheduler.should_sync():
                    self.scheduler._do_sync()
    except (KeyboardInterrupt, SystemExit):
        self._is_shutdown.set()
    finally:
        self.sync()

A quick explanation:

• This example checks whether /tmp/standby.flag exists.
• If the file exists, Beat is considered to be in standby mode.
• Inside the main loop, Beat checks for that file before scheduling tasks.
• If the file is present, it sleeps for 5 seconds and checks again.

To use it, just apply the patch at your startup entry point:

1
2
3

from celery.beat import Service

Service.start = patched_start

After that, once Celery Beat has started, you can run touch /tmp/standby.flag to put it into standby mode. It will stop generating scheduled tasks. Remove the file, wait a few seconds, and Beat will resume normal scheduling.

No wonder almost all of my traffic was coming from Google and Bing. Baidu had barely indexed anything. Since Baidu does not provide a sitemap submission API like Google does, the only practical option is to submit URLs directly. So I put together a small workflow that lets this Hexo blog submit sitemap URLs to Baidu automatically through GitHub Actions.

Prepare the script

First, write a small Python script that downloads a sitemap.xml, extracts the URLs, and submits them to Baidu:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

#!/usr/bin/env python3

"""
Script for submitting sitemap URLs to Baidu

visit: https://knktc.com

@author:knktc
@contact:me@knktc.com
@create:2022-02-12 22:49
"""

import time
import argparse
from urllib import request
from urllib.parse import urljoin
import xml.etree.ElementTree as ET


def chunker(seq, size):
    """ iterate list by chunk """
    return (seq[pos:pos + size] for pos in range(0, len(seq), size))


class BaiduSubmitter:
    def __init__(self, site: str, token: str, sitemap: str):
        self.submit_url = self.gen_submit_url(site, token)
        self.sitemap_url = self.gen_sitemap_url(site, sitemap)

    @staticmethod
    def gen_submit_url(site: str, token: str) -> str:
        """ generate url to submit to """
        return f'http://data.zz.baidu.com/urls?site={site}&token={token}'

    @staticmethod
    def gen_sitemap_url(site: str, sitemap: str) -> str:
        """ generate url path to get sitemap """
        return urljoin(site, sitemap)

    @staticmethod
    def get_links_from_sitemap(sitemap_url) -> list:
        """ download sitemap, parse and get urls """
        with request.urlopen(sitemap_url) as resp:
            data = resp.read()

        root = ET.fromstring(data)
        return [_.text for
                _ in root.findall('./{http://www.sitemaps.org/schemas/sitemap/0.9}url/{http://www.sitemaps.org/schemas/sitemap/0.9}loc')]

    @staticmethod
    def submit(submit_url: str, links: list):
        """ submit to baidu """
        data = '\n'.join(links).encode('utf8')
        req = request.Request(submit_url, data=data)
        return request.urlopen(req).read().decode()

    def run(self, chunk_size=20, sleep_time=0.1):
        """ submit process """
        links = self.get_links_from_sitemap(self.sitemap_url)
        print(f'Get {len(links)} links from sitemap: [{self.sitemap_url}]')

        for chunk in chunker(links, chunk_size):
            resp = self.submit(self.submit_url, chunk)
            print(resp)
            if sleep_time:
                time.sleep(sleep_time)

            time.sleep(1)


def get_args():
    """ get cli args """
    parser = argparse.ArgumentParser(description='Submit sitemap to Baidu')
    parser.add_argument('--site', '-s', type=str, dest='site', required=True,
                        help='your site, eg: https://knktc.com')
    parser.add_argument('--token', '-t', type=str, dest='token', required=True,
                        help='baidu ziyuan token, you may find your token in https://ziyuan.baidu.com/linksubmit')
    parser.add_argument('--sitemap', '-p', type=str, dest='sitemap', default='sitemap.xml',
                        help='url path to get sitemap.xml file, default: sitemap.xml')
    parser.add_argument('--chunk', '-c', type=int, dest='chunk_size', default=100,
                        help='how many urls should be submitted each time')

    args = parser.parse_args()

    return args


def main():
    """
    main process

    """
    args = get_args()
    site = args.site
    token = args.token
    sitemap_path = args.sitemap
    chunk_size = args.chunk_size

    submitter = BaiduSubmitter(site, token, sitemap_path)
    submitter.run(chunk_size=chunk_size)


if __name__ == '__main__':
    main()

This script only uses Python’s standard library, so there is no extra dependency to install.

Save it locally, get your Baidu submission token from Baidu Search Resource Platform, and run it like this:

1

python3 baidu_submit.py --site https://knktc.com --token AABBCCDD --sitemap sitemap.xml --chunk 100

A quick explanation of the arguments:

• --site or -s: your blog URL
• --token or -t: the submission token from Baidu
• --sitemap or -p: the sitemap path; for example, if your sitemap is at https://knktc.com/sitemap.xml, then sitemap.xml is enough here
• --chunk or -c: how many URLs to send in each request; the default is 100

The output looks like this:

1
2
3
4

Get 235 links from sitemap: [https://knktc.com/sitemap.xml]
{"remain":2585,"success":100}
{"remain":2485,"success":100}
{"remain":2450,"success":35}

For convenience, I also published the script as a GitHub Gist:

https://gist.github.com/knktc/846950067e60a92612c1befbe4213a32

That way, the GitHub Actions workflow can just fetch the script directly.

GitHub Actions

There is a small trick when adding GitHub Actions files to a Hexo repository. See my earlier post: Use GitHub Actions to Submit a Sitemap for a Hexo Blog.

Then create a workflow file named baidu_sitemap.yml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# workflow to summit urls from sitemap to baidu

name: Submit baidu Sitemap

on:
  schedule:
    - cron: '15 2 * * *'

jobs:
  submit:
    runs-on: ubuntu-latest

    steps:
      - name: get gist
        uses: andymckay/get-gist-action@0.1
        with:
          gistURL: https://gist.github.com/knktc/846950067e60a92612c1befbe4213a32

      - name: run script
        env:
          BAIDU_TOKEN: ${{ secrets.BAIDU_TOKEN }}
        run: python3 /tmp/baidu_submit.py --site https://knktc.com --token $BAIDU_TOKEN

There are a few important points in this workflow:

• It runs every day at 02:15 UTC, which is 10:15 in Beijing time.
• The script is fetched from a Gist instead of being committed into the Hexo repository.
• The Baidu token is passed through GitHub Secrets, so you need to configure BAIDU_TOKEN in the repository settings first.

After that, GitHub Actions can submit your latest sitemap URLs to Baidu automatically every day.

But after deploying to a test environment, I ran into a problem. There were two Nginx nodes behind a load balancer, and the same static file returned different ETags depending on which node handled the request. As a result, the browser kept receiving 200 responses instead of 304, so caching was effectively broken.

After looking into how Nginx calculates ETags, I found that Nginx uses the file size and the file modification time. The ngx_http_set_etag function in the Nginx source contains code like this:

1
2
3
4
5
6

etag->value.len = ngx_sprintf(etag->value.data, "\"%xT-%xO\"",
                                  r->headers_out.last_modified_time,
                                  r->headers_out.content_length_n)
                      - etag->value.data;

    r->headers_out.etag = etag;

Full source reference:

https://github.com/nginx/nginx/blob/1f01183b9e6658749934313fd72f7f16c1918b54/src/http/ngx_http_core_module.c#L1673

That makes it pretty clear: if two Nginx nodes return different ETags, the file modification time is probably different on each node.

Fortunately, changing file modification times is easy. You can use touch. The -t option is documented like this:

-t STAMP
use [[CC]YY]MMDDhhmm[.ss] instead of current time

So on both nodes, the following command sets the file timestamp to 2022-02-25 13:13:

1

touch -t 202202251313 myconf.json

If you want to do the same thing in Python, you can use os.utime:

1
2

import os
os.utime('myconf.json', (1645806368, 1645806368))

After doing that, both Nginx nodes returned the same ETag, and the second request correctly came back as 304 instead of 200.

Reference:

• Discussion of the Nginx ETag algorithm on Server Fault

Since Jira dashboards can already display a burndown chart, the idea is to make that same gadget available in Confluence.

First, open the Jira home page. If you already have a dashboard, there should be an “Add gadget” button somewhere near the top right:

After clicking it, a gadget dialog will appear. Choose the gadget you want, click “View XML”, and copy the XML URL:

Next, log in to Confluence as an administrator and open the site administration page. Under the “External Gadgets” section, on the gadget specification tab, paste the XML URL you copied and click “Add”:

After that, when you add a macro to a Confluence page, you should see the registered gadgets in the macro picker. At that point you can insert the same gadget that exists on the Jira dashboard:

One thing to note is that these gadgets are implemented with iframes, so in practice users usually need Confluence and Jira authentication to be connected properly, typically through OAuth or a similar integration.

Reference:

• Atlassian official documentation

For example, if the project is named test-poetry, after running poetry shell the prompt may look like this:

(test-poetry-FvrREBVp-py3.6) knktc@knktc-rmbp test_poetry %

Poetry includes both an encoded suffix and the Python version in the virtual environment name, and then uses that full directory name as the prompt prefix. On a small screen, that takes up a surprising amount of space.

Since Poetry environments are still activated through bin/activate, the easiest fix is to find that file and adjust the prompt manually.

From the project directory, as long as pyproject.toml is present, run:

1

poetry env info -p

This prints the path to the current virtual environment, for example:

1
2

(test-poetry-FvrREBVp-py3.6) knktc@knktc-rmbp test_poetry % poetry env info -p
/Users/knktc/Library/Caches/pypoetry/virtualenvs/test-poetry-FvrREBVp-py3.6

Then open the bin/activate file in that environment:

1

vim /Users/knktc/Library/Caches/pypoetry/virtualenvs/test-poetry-FvrREBVp-py3.6/bin/activate

Around line 68, you should see the logic that sets PS1. It uses the environment directory name as the prompt prefix:

1
2
3
4
5
6
7
8
9

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] ; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    if [ "x" != x ] ; then
        PS1="() ${PS1-}"
    else
        PS1="(`basename \"$VIRTUAL_ENV\"`) ${PS1-}"    # <--- this line
    fi
    export PS1
fi

You can replace that line with a shorter, fixed project name:

1
2
3
4
5
6
7
8
9

if [ -z "${VIRTUAL_ENV_DISABLE_PROMPT-}" ] ; then
    _OLD_VIRTUAL_PS1="${PS1-}"
    if [ "x" != x ] ; then
        PS1="() ${PS1-}"
    else
        PS1="(test-poetry) ${PS1-}"    # <--- hard-code the project name
    fi
    export PS1
fi

Save the file, then reactivate the environment:

1
2
3
4
5

knktc@knktc-rmbp test_poetry % poetry shell
Spawning shell within /Users/knktc/Library/Caches/pypoetry/virtualenvs/test-poetry-FvrREBVp-py3.6
Restored session: Wed Feb 9 23:12:53 CST 2022
knktc@knktc-rmbp test_poetry % . /Users/knktc/Library/Caches/pypoetry/virtualenvs/test-poetry-FvrREBVp-py3.6/bin/activate
(test-poetry) knktc@knktc-rmbp test_poetry %

Much better.

This post records a Dockerfile for installing Headless Chrome on Ubuntu 20.04 so I can find it again later.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

FROM ubuntu:20.04

ARG APT_MIRROR_HOST=mirrors.tuna.tsinghua.edu.cn
ENV DEBIAN_FRONTEND noninteractive

RUN sed -i "s/archive.ubuntu.com/${APT_MIRROR_HOST}/g" /etc/apt/sources.list \
    && sed -i "s/security.ubuntu.com/${APT_MIRROR_HOST}/g" /etc/apt/sources.list

RUN apt update
RUN apt install -y wget fonts-wqy-microhei
RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
RUN dpkg -i google-chrome-stable_current_amd64.deb;exit 0
RUN apt install -f -y
RUN ln -fs /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

Notes:

• The APT mirror is switched to Tsinghua’s mirror to speed up dependency installation.
• DEBIAN_FRONTEND=noninteractive is set because tzdata may otherwise prompt during installation and cause docker build to hang.
• Because of that non-interactive setting, the final timezone configuration is handled manually.
• fonts-wqy-microhei is installed so Chinese text can render correctly, especially when exporting PDFs.
• Installing Chrome with dpkg -i is expected to fail at first because dependencies are missing, so the command ends with exit 0.
• apt install -f -y is then used to repair dependencies and complete the installation.

One odd part of YApi’s design is that only the user created during installation is an administrator. Any users created later are normal members by default, and there is no obvious place in the UI to change that. If you need another admin account, the practical solution is to update the database directly.

YApi uses MongoDB on the backend, so start by entering the Mongo shell:

1

mongo

Then switch to the yapi database:

1

use yapi

Next, find the target user’s ID by username:

1

db.getCollection("user").find({"username":"knktc"})

You can also search by email:

1

db.getCollection("user").find({"email":"hello@world.com"})

Look at the returned _id field. That is the user ID you need.

Finally, update that user’s role to admin:

1

db.getCollection("user").update({"_id":2}, {$set: {"role":"admin"}})

If you ever need to revoke admin privileges, change role back to member.