teddysun/across: shell scripts for WireGuard, BBR, KMS and backups

What teddysun/across actually is

This repository is a folder of unrelated shell scripts that happen to share an author and a licence. The README lists each one with a one-line description and a link to a blog post on teddysun.com that serves as the real documentation. There is no installer, no shared library, no version number and no release artefact. The top level holds InstallNET.sh, backup.sh, bbr.sh, bench.sh, ftp_upload.sh, kms.sh, l2tp.sh, pptp.sh, unixbench.sh and wireguard.sh, plus deb/, rpm/, docker/, kms and kms-debian directories.

The audience is narrow and specific: someone with root on a Linux server, usually a VPS, who wants to enable TCP BBR, stand up a WireGuard endpoint, run a benchmark, or push encrypted database dumps to remote storage. Each task is a separate file you download and run. If you are looking for a project with a CLI entry point, a config schema or a plugin system, this is not it. Several scripts are also explicitly dead: the README marks l2tp.sh and pptp.sh as "Deprecated, DO NOT USE", so the working surface is smaller than the file listing suggests.

One script per job, and no shared machinery

The architecture is copy-paste-and-execute. You fetch a single file from the master branch, run it as root, and it performs its task using the host's own tools: bbr.sh installs a newer kernel and enables the BBR congestion control module, wireguard.sh writes WireGuard configuration and starts the interface, kms.sh installs a KMS server (the README also points to a Docker image at hub.docker.com/r/teddysun/kms), bench.sh measures I/O and upload and download speed, and unixbench.sh installs and runs UnixBench.

The two backup-oriented scripts carry an explicit precondition that the others do not: the README says "You must modify the config before run it" for both backup.sh and ftp_upload.sh. That is the whole configuration story. There is no environment variable layer, no config file format documented in the README, and no argument parsing described there. Everything is edited in place inside the script. backup.sh can dump MySQL or MariaDB databases and files or directories, optionally encrypt the archive with AES-256-CBC and a sha256 message digest via the openssl command, optionally transfer the result to Google Drive through rclone or to an FTP server through the ftp command, and optionally delete the remote copy afterwards. Every one of those capabilities is marked "(option)" in the README, which tells you the defaults are conservative but also that you must read the script to learn which flags are on.

The consequence of this design is that there is no shared state to corrupt and no upgrade migration to perform. It also means there is no way to ask the collection for a version, and no place where the scripts agree on logging, error handling or exit codes.

Installing and first run: wireguard.sh and backup.sh

There is no package to install. The README gives no install command, only per-script descriptions and blog links, so the practical route is to download the script you need from the repository and run it. A typical fetch looks like this, using the raw file on the master branch:

curl -O https://raw.githubusercontent.com/teddysun/across/master/wireguard.sh
chmod +x wireguard.sh
./wireguard.sh

The script configures and starts a WireGuard VPN server according to its own description. Because the README documents no prompts or flags, expect to read the file before executing it as root; there is no --help documented here.

For backup.sh the order is different. The README states you must modify the config before running it, so the first run is an edit, not an execution. Clone the repository, open backup.sh in an editor, and change the database credentials and the file or directory list inside the script before you execute it. The README does not document a dry-run mode, so the first execution is the real one.

If you enable the encryption option, the script depends on the openssl command being present; if you enable remote transfer, it depends on rclone for Google Drive or ftp for an FTP server. For a container-based KMS instead of the shell script, the README points to the published image at hub.docker.com/r/teddysun/kms, but it does not give the run command for that image.

Where these scripts will bite you

The largest limitation is the absence of any rollback. bbr.sh installs a newer kernel, and the README says nothing about reverting to the previous one. If the new kernel does not boot on your VPS provider's virtualisation, recovery is your problem, not the script's. The same applies to wireguard.sh: it starts a VPN server, and the README documents no uninstall path, so removing it means undoing the changes by hand.

backup.sh has a quieter failure mode. Its remote deletion option removes files from Google Drive or an FTP server. Combined with encryption and an unattended cron entry, a misconfigured retention setting can delete the copy you wanted to keep. The README does not document a verification step or a restore procedure, so the script's own correctness is not something you can check from the repository. The dependency chain is also implicit: encryption needs openssl, Google Drive transfer needs rclone, FTP transfer needs ftp, and none of these are checked by an installer because there is no installer.

The deprecation notices matter too. l2tp.sh and pptp.sh are still in the tree and still downloadable, but the README says DO NOT USE. Anyone arriving from an old blog post could easily run one of them. Finally, the last push to the repository was on 2026-04-04, so this is not a project with a recent change history you can lean on when a distro moves a package name.

Compared with a configuration management tool

The obvious alternative for the same job is Ansible, or any other configuration management system. The difference is not quality, it is the unit of work. Ansible describes a desired end state in YAML, is idempotent by design, and can be re-run against many hosts from one control machine; a playbook that enables BBR or installs WireGuard will report what changed and can be run twice without duplicating the effect. teddysun/across does the opposite: each script is imperative, assumes it is running on the machine it is changing, and is written to be read and edited rather than parameterised.

That makes the two approaches suited to different scales. For one or two servers, editing backup.sh in place is faster than writing an inventory, a playbook and a role. For twenty servers, the script collection gives you no way to know which host has which edit, because the configuration lives inside the file you copied. There is also a middle option for one of the tasks: the README points to a published KMS Docker image, which sidesteps the shell script entirely for that component. The repository itself does not offer a container for WireGuard, BBR or backups.

Licence and what a future upgrade costs

The repository is licensed Apache-2.0, and the LICENSE file sits at the top level alongside the scripts. That licence permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes. It does not cover the blog posts on teddysun.com that the README links to for each script, and it says nothing about the Docker image published separately on Docker Hub. This is a description of the licence text, not legal advice; if you redistribute a modified script inside a product, read the LICENSE file yourself.

Upgrade cost is the part the repository does not address. There are no releases, so there is no changelog to read and no version to pin. The practical upgrade procedure is to diff the file you edited against the current master and merge by hand, which means every local change you made to backup.sh is a potential conflict. Because the scripts have no self-update mechanism and no configuration file, there is nothing to migrate; there is also nothing that tells you a script has changed since you downloaded it. If you run these from cron, you are running a frozen copy, and the only signal that upstream moved is a manual git pull.

Editorial conclusion

Adopt it if you administer a handful of Linux VPSes and want a readable script you can inspect before running as root, and if you accept that backup.sh, ftp_upload.sh and the kms files must be edited first. Skip it if you need a managed VPN product, a supported backup agent, or anything with a rollback path, because the repository provides none. Before running anything, open the script in a text editor and check the kernel or package versions it pulls, and read the LICENSE file for the Apache-2.0 terms that cover every script in the tree.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. teddysun/across on GitHub