1. Prepare the runtime​

Install the runtime and dependencies required by the OpenClaw release used by the project. Keep the application, plugin, and model-provider versions pinned, and store configuration outside source control.

After installation, start the service locally and confirm its health endpoint and logs before exposing any network port.

2. Configure the model provider​

Create credentials for the selected model provider and place them in environment variables or a secret manager. Configure the model name, API endpoint, timeout, retry policy, and token or spending limits.

Do not embed model keys in frontend code, screenshots, bot messages, or committed configuration files. Use a separate key and account for production.

3. Configure the OpenClaw gateway​

The gateway receives Feishu events and sends messages to the model-backed agent. Configure a stable public HTTPS callback URL, request timeouts, allowed tenants, and logging that excludes message content and credentials.

Place the service behind a reverse proxy when appropriate, and restrict administrative endpoints to trusted networks.

4. Create the Feishu application​

In the Feishu developer console:

1. Create an internal application.
2. Enable the bot capability.
3. Record the App ID and App Secret securely.
4. Add only the message and user permissions required by the assistant.
5. Configure the event-subscription callback URL and verification token.
6. Subscribe to the message events required by the integration.
7. Publish the application to the intended organization scope.

Permission names and console locations can change, so follow the exact UI and documentation for the current Feishu platform version.

5. Verify event handling​

Feishu first verifies the callback endpoint. The service must validate the request signature or verification token before accepting events.

Test with a dedicated chat and account. Confirm that:

• the callback receives the event once;
• duplicate event IDs are ignored;
• bot messages do not trigger an infinite reply loop;
• user and tenant scope are enforced;
• long model responses are split or formatted correctly;
• timeouts return a controlled message instead of failing silently.

6. Security and operations​

Treat chat messages as potentially sensitive business data. Define what content may be sent to the model provider, apply redaction where required, and make retention and audit behavior explicit.

Use least-privilege Feishu permissions, rotate secrets, verify webhook signatures, rate-limit requests, and isolate tool execution. Any feature that can read files, invoke commands, query internal systems, or send messages should require explicit authorization and allowlisted operations.

Monitor callback errors, model latency, token use, failed replies, duplicate events, and provider outages. Add a circuit breaker or fallback response so a model failure does not overload Feishu retries.

7. Production checklist​

Before rollout, complete a small pilot with synthetic or low-sensitivity data. Document the bot's scope, supported commands, escalation path, model limitations, and data policy. Test secret rotation, service restart, network interruption, duplicate delivery, and rollback of the OpenClaw configuration.

Prerequisites​

Install Docker Engine and the Docker Compose plugin, then verify them:

docker version
docker compose version

Create directories for persistent data and configuration:

sudo mkdir -p /srv/minio/data
sudo chown -R 1000:1000 /srv/minio

Docker Compose configuration​

Create compose.yaml:

services:
  minio:
    image: quay.io/minio/minio:RELEASE.2024-09-22T00-33-43Z
    container_name: minio
    command: server /data --console-address ":9001"
    restart: unless-stopped
    environment:
      MINIO_ROOT_USER: ${MINIO_ROOT_USER}
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
    volumes:
      - /srv/minio/data:/data
    ports:
      - "9000:9000"
      - "9001:9001"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 10s
      retries: 3

Store credentials in a local .env file and keep it out of version control:

MINIO_ROOT_USER=minio-root
MINIO_ROOT_PASSWORD=replace-with-a-long-random-secret

Start the service and inspect its health:

docker compose up -d
docker compose ps
docker compose logs --tail=100 minio

The S3 API listens on port 9000; the administration console uses 9001.

Configure the MinIO client​

Install the official mc client, then create an alias:

mc alias set local http://127.0.0.1:9000 minio-root 'your-password'
mc admin info local
mc mb local/example
mc ls local

Applications should not use the root account. Create a dedicated user and attach only the policy it needs:

mc admin user add local app-user 'another-long-random-secret'
mc admin policy attach local readwrite --user app-user

For production, replace the broad readwrite policy with a bucket-specific policy.

Production checklist​

A running container is not yet a resilient storage service:

• Terminate TLS at MinIO or a trusted reverse proxy, and do not expose the console publicly without access controls.
• Pin an image release, test upgrades in staging, and read the release notes before changing versions.
• Use multiple drives and nodes when availability matters. A single data directory has no disk redundancy.
• Back up configuration and critical objects to a separate failure domain.
• Monitor disk capacity, request errors, latency, and node health.
• Restrict ports with a firewall and rotate credentials regularly.

Common problems​

If the container exits immediately, check directory ownership and docker compose logs. If S3 requests work locally but fail through a proxy, verify forwarded headers, the public server URL, TLS configuration, and request-size limits. Clock drift can also break signed S3 requests, so keep the host synchronized with NTP.

Docker Compose configuration​

Create a dedicated directory and a .env file containing a stable encryption key:

N8N_HOST=n8n.example.com
N8N_ENCRYPTION_KEY=replace-with-a-long-random-value
TZ=UTC

Never change or lose N8N_ENCRYPTION_KEY after credentials have been saved. Without it, encrypted credentials may become unreadable.

Create compose.yaml:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:2.0.0
    container_name: n8n
    restart: unless-stopped
    environment:
      - N8N_HOST=${N8N_HOST}
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - WEBHOOK_URL=https://${N8N_HOST}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${TZ}
      - TZ=${TZ}
    volumes:
      - n8n_data:/home/node/.n8n
    expose:
      - "5678"

volumes:
  n8n_data:

Start and inspect the container:

docker compose up -d
docker compose logs -f --tail=100 n8n

Using expose keeps port 5678 off the public host interface. Place n8n behind an HTTPS reverse proxy on the same Docker network or publish the port only to 127.0.0.1.

Reverse proxy requirements​

Your proxy must forward the original host, protocol, and client address. For Nginx, the core location is:

location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Incorrect WEBHOOK_URL, proxy headers, or proxy-hop settings are common reasons test webhooks work but production webhooks point to localhost or use HTTP.

Backups​

Back up both the database and the encryption key. With the default SQLite setup, the named volume contains the database and instance data. Stop writes or use an application-consistent method before copying it. Larger teams should evaluate PostgreSQL and test a complete restore regularly.

Exporting workflows is useful, but workflow JSON alone is not a full disaster-recovery backup because credentials, executions, users, and instance configuration live elsewhere.

Security checklist​

• Use HTTPS and restrict editor access with an identity-aware proxy, VPN, or firewall.
• Run the container as its default non-root user.
• Keep secrets out of workflow logs and source control.
• Limit community nodes and review any node that executes code.
• Configure execution retention so old payloads do not grow forever.
• Pin versions, read release notes, and back up before upgrades.
• Protect public webhooks with signatures, tokens, rate limits, and input validation.

Updating n8n​

Pull and recreate the service after reviewing breaking changes:

docker compose pull
docker compose up -d
docker compose logs --tail=100 n8n

For important workflows, rehearse upgrades against a restored backup before updating production.

1. Configure source and destination aliases​

Install a recent MinIO Client release and configure both endpoints:

mc alias set old https://old-minio.example.com ACCESS_KEY SECRET_KEY
mc alias set new https://new-minio.example.com ACCESS_KEY SECRET_KEY
mc admin info old
mc admin info new

Avoid placing real secrets in shell history. Prefer environment variables, a restricted configuration file, or a secrets manager.

2. Inventory the source​

Before copying data, record the bucket list and important settings:

mc ls old
mc admin info old
mc ilm rule ls old/my-bucket
mc version info old/my-bucket

Also inventory users, groups, policies, bucket notifications, object-lock settings, replication rules, and server-side encryption keys. mc mirror focuses on objects; it does not automatically reproduce every administrative setting.

3. Run the initial mirror​

Create the destination bucket if needed and start the full copy:

mc mb --ignore-existing new/my-bucket
mc mirror --preserve --overwrite old/my-bucket new/my-bucket

Use --remove only when the destination must be an exact mirror and you are certain that destination-only objects may be deleted. Test that behavior on a disposable bucket first.

For a long migration, run the command in a managed terminal session and save logs:

mc mirror --preserve --overwrite --json old/my-bucket new/my-bucket

4. Catch up new writes​

While applications still write to the old cluster, repeat the mirror to transfer changes. Shortly before cutover:

1. Put writers into maintenance or read-only mode.
2. Run one final incremental mirror.
3. Compare source and destination.
4. Switch application endpoints and credentials.
5. Keep the old service read-only until validation is complete.

This sequence minimizes downtime without losing objects written during the first copy.

5. Validate the result​

Compare object counts and total sizes, but do not treat matching totals as sufficient proof. Sample critical objects and verify metadata, content type, ETag or checksums, application reads, presigned URLs, and permissions.

mc du --recursive old/my-bucket
mc du --recursive new/my-bucket
mc stat old/my-bucket/path/to/object
mc stat new/my-bucket/path/to/object

Multipart uploads and encrypted objects can make ETags unsuitable as universal content hashes. Use application-level checksums when correctness is critical.

Versioning and deletion caveats​

Confirm how the client version you use handles object versions and delete markers. If legal retention, object lock, or historical versions matter, test the complete behavior with representative data before migrating production. For very large or continuously changing datasets, MinIO replication may be a better fit than repeated mirroring.

Rollback plan​

Do not delete the source immediately. Define a rollback window, preserve DNS or endpoint settings, and document how writes will be reconciled if traffic must return to the old cluster. A successful migration ends only after monitoring confirms normal error rates, latency, permissions, and object integrity.

After installing the packages, initialize and start an instance with the supplied management tools, then connect through gsql. Create a dedicated application user and database instead of using the administrator account:

CREATE USER app_user IDENTIFIED BY 'long-random-password';
CREATE DATABASE app_db OWNER app_user;

For remote access, update the listening address and host-based authentication rules, then restrict the database port with a firewall. Test with:

gsql -d app_db -U app_user -h 127.0.0.1 -p 5432

Before production use, configure TLS, backups, archive or replication strategy, resource limits, monitoring, and tested restore procedures.

The extension only chooses a configured proxy server; it does not provide a proxy service itself. Before importing a third-party rule list, verify its source and avoid routing passwords or other sensitive traffic through an untrusted proxy.

Install the extension​

Download a release from the ZeroOmega project:

• Chrome and Chromium-based browsers use the .crx package when manual installation is supported.
• Firefox uses the .xpi package.

Release page:

https://github.com/zero-peak/ZeroOmega/releases

Browser extension policies change over time. On managed Chrome installations, manual .crx installation may be blocked, so use an approved extension store or the organization's deployment policy when required.

Create a proxy profile​

Open the extension and create a proxy profile. Enter the proxy protocol, host, and port supplied by your own proxy service. Test the profile directly before adding automatic switching rules.

Configure automatic switching​

Open the Auto Switch profile, add a rule-list condition, and enter a trusted rule-list URL, for example:

https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt

Choose the proxy profile for requests that match the rule list. Configure a direct or fallback profile for unmatched requests, then apply the changes.

Troubleshooting​

When a site does not use the expected route:

1. Confirm that the proxy profile works when selected manually.
2. Refresh the external rule list and inspect whether the domain is included.
3. Check rule order because earlier rules may take precedence.
4. Verify that another VPN, system proxy, or browser policy is not overriding the extension.
5. Review DNS behavior, authentication errors, and the proxy server logs.

The following example appends .json to filenames made of six digits:

import java.io.File;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

String directory = "C:\\tests";
String matchRegex = "(\\d{6})";
String replaceRegex = "$1.json";

Pattern pattern = Pattern.compile(matchRegex);
File folder = new File(directory);

if (folder.isDirectory()) {
    File[] files = folder.listFiles();
    if (files != null) {
        System.out.println("files: " + files.length);

        for (File source : files) {
            Matcher matcher = pattern.matcher(source.getName());
            if (!matcher.matches()) {
                continue;
            }

            String targetName = matcher.replaceAll(replaceRegex);
            File target = new File(source.getParentFile(), targetName);

            System.out.printf("%s -> %s%n", source.getName(), targetName);

            if (target.exists()) {
                System.err.println("Skipped because the target already exists: " + target);
                continue;
            }

            if (!source.renameTo(target)) {
                System.err.println("Rename failed: " + source);
            }
        }
    }
}

Recommended improvements​

For production code, use java.nio.file.Files.move so failures produce useful exceptions:

Files.move(source.toPath(), target.toPath());

Before applying changes:

1. Build the complete source-to-target mapping.
2. Reject duplicate target paths and existing files.
3. Print or export a preview.
4. Store a reverse mapping for rollback.
5. Apply moves only after validation succeeds.

Also decide explicitly whether symbolic links, hidden files, directories, and recursive traversal are allowed.

1. Capture detailed logs​

Run the install with verbose output:

npm install --verbose

Also record the active toolchain and configuration:

node --version
npm --version
npm config get registry
npm config list

A line such as idealTree:userRequests describes the dependency-resolution stage; it is not the root cause by itself. Inspect the requests and messages immediately before and after it.

2. Test registry and DNS access​

Verify that npm can reach the registry:

npm ping
npm view lodash version
curl -I https://registry.npmjs.org/

If these commands are slow, check DNS, VPN, firewall, corporate TLS inspection, and proxy settings. Review both npm-specific and environment proxies:

npm config get proxy
npm config get https-proxy
env | grep -i proxy

Remove stale npm proxy values when they are no longer required:

npm config delete proxy
npm config delete https-proxy

Do not disable TLS verification as a permanent workaround. Install the correct organization CA certificate instead.

3. Verify the cache​

Use npm's built-in verification first:

npm cache verify

Cache deletion should be a targeted experiment, not the default first step. If verification reports corruption and you have ruled out network problems, use:

npm cache clean --force

4. Separate dependency resolution from scripts​

Packages may run preinstall, install, or postinstall scripts that download binaries or compile native modules. Test without scripts:

npm install --ignore-scripts

If that completes, inspect lifecycle scripts and rerun the relevant one with foreground output:

npm install --foreground-scripts --verbose

Native builds may require Python, a C/C++ toolchain, and platform development headers.

5. Check the lockfile and Node version​

For CI and reproducible installs, prefer:

npm ci

It requires package.json and package-lock.json to agree. Do not delete a committed lockfile casually; doing so changes the resolved dependency graph. Confirm the project's supported Node version through .nvmrc, .node-version, the engines field, or project documentation.

6. Find the slow package​

Useful experiments include:

npm install --timing
npm explain package-name
npm ls

Check the npm debug log path printed by the failed command. Git-based dependencies may be waiting on SSH credentials, inaccessible hosts, or Git LFS. Browser automation packages often download large binaries and can be blocked by proxies.

A reliable cleanup sequence​

After preserving the original error, a controlled local retry is:

rm -rf node_modules
npm cache verify
npm ci --verbose

Keep the lockfile unless you intentionally want to update dependencies. In CI, add explicit timeouts and cache keys based on the lockfile so a stalled registry request cannot block a runner indefinitely.

Use a multi-stage build: compile FreeSWITCH and required codecs in the builder stage, then copy only runtime libraries, modules, sounds, and binaries into the final image. Run as a non-root user where practical.

Mount configuration, recordings, certificates, and persistent databases deliberately rather than hiding important state inside the container filesystem.

SIP signaling commonly uses ports such as 5060 and 5080, while RTP requires a configured UDP range. Publishing only the SIP port is not enough for two-way audio. Ensure the container, host firewall, cloud security group, NAT, and FreeSWITCH external IP settings agree on the RTP range.

For production, avoid host networking unless justified, protect the event socket and management interfaces, rate-limit unauthenticated traffic, monitor registrations and call quality, and test one-way-audio, codec negotiation, and NAT traversal from external networks.

An open proxy can be abused quickly, so restrict source IP addresses, listening interfaces, and firewall rules before exposing the service.

Optional test container​

docker run -itd --name ubuntu-test -p 8888:8888 ubuntu:22.04
docker exec -it ubuntu-test bash

Install Tinyproxy​

apt update
apt install tinyproxy -y

Create a configuration​

Create /tmp/tinyproxy.conf:

Port 8888
Listen 0.0.0.0
Timeout 600
BindSame yes
MaxClients 1024
DisableViaHeader Yes

# Replace with trusted client networks.
Allow 192.168.1.0/24

Do not leave Allow 0.0.0.0/0 enabled on a public server.

Start the service​

tinyproxy -d -c /tmp/tinyproxy.conf

For long-running deployments, use the distribution service unit and store configuration under /etc/tinyproxy/.

Verify the proxy​

export PROXY_IP=203.0.113.10
curl --proxy "http://$PROXY_IP:8888" https://httpbin.org/ip

The response should show the proxy server's public address. If it fails, inspect the Tinyproxy log, firewall, cloud security group, Allow rules, and whether the proxy can resolve DNS and reach the destination.

Run all tests:

mvn test

Run one class:

mvn -Dtest=UserServiceTest test

Run one method:

mvn -Dtest=UserServiceTest#shouldCreateUser test

Run several methods or wildcard patterns:

mvn -Dtest='UserServiceTest#shouldCreate*' test
mvn -Dtest='UserServiceTest,OrderServiceTest' test

For a multi-module project, select a module and build required dependencies:

mvn -pl service-module -am -Dtest=UserServiceTest test

• -pl selects projects from the reactor.
• -am also builds required upstream modules.
• -DskipTests compiles tests but skips execution.
• -Dmaven.test.skip=true skips both test compilation and execution.

Integration tests commonly run through Maven Failsafe during integration-test and verify, so use the plugin's include properties and lifecycle rather than assuming mvn test runs them.

Download Flutter​

A Windows stable archive can be downloaded from the official release storage:

https://storage.googleapis.com/flutter_infra_release/releases/stable/windows/flutter_windows_3.29.2-stable.zip

Verify the current stable version before installation.

Configure package mirrors​

In environments where the default endpoints are slow, configure approved mirrors:

FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn
PUB_HOSTED_URL=https://pub.flutter-io.cn

Diagnose a slow assembleDebug​

cd android
.\gradlew.bat clean
.\gradlew.bat assembleDebug --info

Use the verbose output to identify the dependency or repository causing the delay. Avoid manually copying artifacts into Gradle caches unless you fully understand the expected directory and checksum layout.

Configure the Gradle distribution​

Edit android/gradle/wrapper/gradle-wrapper.properties:

# distributionUrl=https\://services.gradle.org/distributions/gradle-8.10.2-all.zip
distributionUrl=https\://mirrors.cloud.tencent.com/gradle/gradle-8.10.2-all.zip

Configure a Maven mirror​

For Kotlin DSL projects, edit android/build.gradle.kts or the repository-management block used by the project:

maven { url = uri("https://mirrors.tencent.com/nexus/repository/maven-public/") }

Create a project​

flutter create my_app
cd my_app
flutter run

Keep Flutter, Android Gradle Plugin, Gradle, Kotlin, and Java versions compatible rather than upgrading them independently.

Record the versions of Chrome, ChromeDriver, Selenium, the operating system, and the CPU architecture when troubleshooting. Current Selenium releases can usually manage the driver automatically, which is preferable to maintaining a driver manually.

Check the Chrome version​

Open the following page in Chrome:

chrome://settings/help

For older ChromeDriver releases, the browser and driver generally had to share the same major version. For current Chrome for Testing releases, use the official version-selection data instead of relying on an old three-part matching rule.

Download ChromeDriver​

Use the official Chrome for Testing page:

https://googlechromelabs.github.io/chrome-for-testing/

Download the package for the correct operating system and architecture, extract it, and either add the executable directory to PATH or pass its path explicitly.

Verify with Selenium​

With a modern Selenium version, Selenium Manager can resolve the driver automatically:

from selenium import webdriver

options = webdriver.ChromeOptions()
# Set this only when Chrome is installed in a non-standard location.
# options.binary_location = "/path/to/chrome"

driver = webdriver.Chrome(options=options)
try:
    driver.get("https://www.example.com")
    driver.maximize_window()
finally:
    driver.quit()

For older Selenium versions, create a Service explicitly instead of using the deprecated executable_path argument:

from selenium import webdriver
from selenium.webdriver.chrome.service import Service

service = Service("/path/to/chromedriver")
driver = webdriver.Chrome(service=service)
driver.quit()

Common errors​

• Session not created: compare the installed Chrome major version with the selected driver.
• Chrome binary not found: set options.binary_location to the actual browser executable.
• Driver executable not found: fix PATH, file permissions, or the Service path.
• Browser exits immediately: inspect ChromeDriver logs, sandbox restrictions, display availability, and container shared-memory limits.

A successful process start is only the first step. You should also verify the management port, protocol ports, persistence directory, user accounts, JVM settings, disk capacity, permissions, and monitoring.

Prerequisites​

Artemis is a Java application. JDK 17 is a suitable baseline for current releases:

export JAVA_HOME=/usr/local/jdk17
export PATH="$JAVA_HOME/bin:$PATH"
java -version

Download and extract​

wget -O apache-artemis-2.39.0-bin.tar.gz \
  'https://www.apache.org/dyn/closer.cgi?filename=activemq/activemq-artemis/2.39.0/apache-artemis-2.39.0-bin.tar.gz&action=download'

tar -zxvf apache-artemis-2.39.0-bin.tar.gz
cd apache-artemis-2.39.0

Create a broker instance​

./bin/artemis create broker

The setup wizard asks for the default administrator username and password. Use a strong password and do not reuse development credentials in production.

Start the broker from the instance directory:

cd broker
./bin/artemis run

Run it in the background with the service integration appropriate for your operating system.

Optional configuration​

Adjust JVM memory in:

broker/etc/artemis.profile

Review the JAVA_ARGS or Java options section rather than changing memory values blindly.

To change Jolokia CORS rules, edit:

broker/etc/jolokia-access.xml

For example:

<allow-origin>*://*</allow-origin>

Allowing every origin is convenient for testing but unsafe on an Internet-facing console. Restrict origins in production.

To listen on all network interfaces, edit:

broker/etc/bootstrap.xml

<binding name="artemis" uri="http://0.0.0.0:8161">

Expose port 8161 only to trusted networks and protect it with authentication and firewall rules.

1. Download and verify the package​

Choose the archive that matches your CPU architecture and glibc version from the official MySQL downloads page. The example filename below is illustrative:

wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.39-linux-glibc2.28-x86_64.tar.xz
sha256sum mysql-8.0.39-linux-glibc2.28-x86_64.tar.xz

Compare the checksum with the value published by MySQL. Install required runtime libraries through your operating system package manager.

2. Create a service account and directories​

sudo groupadd --system mysql
sudo useradd --system --gid mysql --shell /usr/sbin/nologin mysql
sudo tar -xf mysql-8.0.39-linux-glibc2.28-x86_64.tar.xz -C /opt
sudo ln -s /opt/mysql-8.0.39-linux-glibc2.28-x86_64 /opt/mysql
sudo mkdir -p /var/lib/mysql /var/log/mysql /run/mysqld
sudo chown -R mysql:mysql /var/lib/mysql /var/log/mysql /run/mysqld

Keep program files owned by root and writable data directories owned by mysql.

3. Configure MySQL​

Create /etc/my.cnf:

[mysqld]
basedir=/opt/mysql
datadir=/var/lib/mysql
socket=/run/mysqld/mysqld.sock
pid-file=/run/mysqld/mysqld.pid
log-error=/var/log/mysql/error.log
user=mysql
bind-address=127.0.0.1
character-set-server=utf8mb4

[client]
socket=/run/mysqld/mysqld.sock
default-character-set=utf8mb4

Binding to localhost is a safe default. If remote clients are required, use a private interface, firewall rules, TLS, and least-privilege database accounts.

4. Initialize the data directory​

sudo -u mysql /opt/mysql/bin/mysqld   --defaults-file=/etc/my.cnf   --initialize
sudo grep 'temporary password' /var/log/mysql/error.log

Save the temporary password securely. Do not use --initialize-insecure on a production server.

5. Create a systemd unit​

Create /etc/systemd/system/mysql.service:

[Unit]
Description=MySQL Server
After=network.target

[Service]
Type=notify
User=mysql
Group=mysql
ExecStart=/opt/mysql/bin/mysqld --defaults-file=/etc/my.cnf
TimeoutStartSec=90
Restart=on-failure
LimitNOFILE=65535
RuntimeDirectory=mysqld
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

Load and start it:

sudo systemctl daemon-reload
sudo systemctl enable --now mysql
sudo systemctl status mysql

6. Finish hardening​

Connect with the temporary password and set a strong replacement, then run:

/opt/mysql/bin/mysql_secure_installation

Remove anonymous accounts and test databases, review root access, configure backups, and monitor disk capacity and replication if used. Add /opt/mysql/bin to a system-wide PATH only after confirming it cannot be modified by untrusted users.

Upgrades and rollback​

Never replace the symlink and start a new MySQL binary without reading that release's upgrade procedure. Take a tested backup, stop cleanly, preserve the old binaries, and rehearse the change on a copy of the data. Package-managed installations are usually easier to patch; use tarballs only when their control is worth the additional maintenance.

spring:
  mail:
    host: smtp.qiye.163.com
    port: 465
    username: user@example.com
    password: ${MAIL_PASSWORD}
    protocol: smtp
    properties:
      mail.smtp.auth: true
      mail.smtp.ssl.enable: true
      mail.smtp.connectiontimeout: 10000
      mail.smtp.timeout: 10000
      mail.smtp.writetimeout: 10000

A basic send operation:

SimpleMailMessage message = new SimpleMailMessage();
message.setFrom("user@example.com");
message.setTo("receiver@example.com");
message.setSubject("Test message");
message.setText("Mail sent by Spring Boot");
mailSender.send(message);

Some accounts require an app-specific authorization code rather than the login password. Authentication failures can also result from an incorrect sender address, blocked SMTP service, TLS/port mismatch, DNS, firewall rules, or provider rate limits. Keep credentials outside source control.

Use ADB automation only on devices and applications you own or are authorized to test. Respect the target platform's rules, verify that the intended device is connected, and add delays and stop conditions so the loop cannot run out of control.

Install the dependency​

pip install adbutils==2.7.2

Enable USB debugging, authorize the computer, and verify the connection:

adb devices

Example​

import time
from datetime import datetime

import adbutils


def main() -> None:
    devices = adbutils.adb.device_list()
    if not devices:
        raise RuntimeError("No authorized Android device is connected")

    device = devices[0]

    try:
        while True:
            filename = datetime.now().strftime("%Y%m%d%H%M%S") + ".png"
            remote_path = "/sdcard/DCIM/screenshot.png"

            device.shell(f"screencap -p {remote_path}", encoding=None)
            device.sync.pull_file(remote_path, filename)
            print(f"screenshot: {filename}")

            device.shell("input swipe 760 1600 760 800 200")
            time.sleep(2)
    except KeyboardInterrupt:
        print("Stopped")


if __name__ == "__main__":
    main()

The swipe coordinates depend on the screen resolution and orientation. For a reusable script, query the display size first, calculate coordinates proportionally, check command results, and use a bounded loop instead of while True.

Configure request limits​

Set limits appropriate for the application:

spring:
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 25MB

Also configure limits at the reverse proxy and load balancer. Proxy and application limits should agree so oversized requests are rejected predictably.

Store uploads with generated names​

@Service
public class FileStorageService {
    private final Path root = Path.of("/srv/myapp/uploads")
            .toAbsolutePath()
            .normalize();

    public FileStorageService() throws IOException {
        Files.createDirectories(root);
    }

    public String store(MultipartFile file) throws IOException {
        if (file.isEmpty()) {
            throw new IllegalArgumentException("Empty file");
        }

        String original = Optional.ofNullable(file.getOriginalFilename())
                .orElse("upload");
        String extension = safeExtension(original);
        String storedName = UUID.randomUUID() + extension;
        Path destination = root.resolve(storedName).normalize();

        if (!destination.getParent().equals(root)) {
            throw new SecurityException("Invalid destination");
        }

        try (InputStream input = file.getInputStream()) {
            Files.copy(input, destination, StandardCopyOption.COPY_ATTRIBUTES);
        }
        return storedName;
    }

    private String safeExtension(String filename) {
        String base = Path.of(filename).getFileName().toString();
        int dot = base.lastIndexOf('.');
        if (dot < 0) return "";
        String extension = base.substring(dot).toLowerCase(Locale.ROOT);
        return Set.of(".jpg", ".png", ".pdf").contains(extension)
                ? extension
                : "";
    }
}

Never use the client filename as the storage path. Persist the original display name separately after sanitizing control characters.

Validate actual content​

The multipart Content-Type and extension are user-supplied. For sensitive workflows, inspect file signatures with a maintained library, decode images before accepting them, and scan untrusted documents with malware tooling. Reject archives unless the product explicitly needs them; archive extraction introduces zip-slip paths and decompression bombs.

Serve files safely​

Resolve only server-generated identifiers and verify the normalized result remains under the storage root. For downloads, set a controlled content type and use Content-Disposition: attachment for formats that should not execute in the browser.

@GetMapping("/files/{id}")
public ResponseEntity<Resource> download(@PathVariable String id) throws IOException {
    if (!id.matches("[0-9a-fA-F-]{36}\\.(jpg|png|pdf)")) {
        return ResponseEntity.badRequest().build();
    }

    Path file = root.resolve(id).normalize();
    if (!file.getParent().equals(root) || !Files.isRegularFile(file)) {
        return ResponseEntity.notFound().build();
    }

    Resource resource = new FileSystemResource(file);
    return ResponseEntity.ok()
            .header(HttpHeaders.CONTENT_DISPOSITION,
                    "attachment; filename=\"" + id + "\"")
            .body(resource);
}

Authorization must be checked before returning a resource. Do not rely on an unguessable URL as access control.

Operational safeguards​

• Store uploads on a separate volume with no execute permission where practical.
• Apply per-user quotas and rate limits.
• Record ownership, checksum, size, and upload time in the database.
• Clean up abandoned temporary files and failed database transactions.
• Back up metadata and objects consistently.
• Use object storage and presigned uploads for large-scale systems.
• Test filename encoding, concurrent uploads, disk-full behavior, and interrupted requests.

A correct upload controller is only one layer. Reverse-proxy limits, storage permissions, authentication, antivirus policy, observability, and retention rules complete the security model.

Begin with a known call such as sqlite3_open, sqlite3_prepare_v2, or sqlite3_exec. Set a breakpoint at the verified function or wrapper and observe the calling convention for the target architecture. On 32-bit builds, arguments are commonly stack-based; on 64-bit Windows, the first arguments normally arrive in registers.

Follow the handle from the open call's output into later query calls. Validate it through repeated use and expected SQLite return codes rather than assuming any pointer to database-like memory is correct.

ASLR changes absolute addresses, so record module-relative offsets and the exact binary hash. Application and SQLite updates can change wrappers, signatures, and data flow.

Do not dereference arbitrary pointers or modify live database state. Use synthetic records, copies of test databases, and an isolated environment. Avoid logging credentials, keys, or real message content.

Start with a known SQLite build and identify stable strings, imported symbols, error messages, or nearby wrapper functions associated with sqlite3_exec. Search those strings in IDA and follow cross-references to candidate call sites.

Compare control flow, argument count, call relationships, and surrounding SQLite functions rather than trusting one byte pattern. Compiler optimization, link-time optimization, static linking, and SQLite version changes can alter the generated code substantially.

When the target uses ASLR, distinguish the module-relative virtual address from the runtime absolute address:

runtime address = module base + relative offset

Validate the candidate in an isolated test build with synthetic data and a debugger. Record the exact application hash, architecture, module version, image base, and offset. Never reuse an offset across versions without revalidation, and avoid collecting or modifying real user data.