This skill should be used when the user asks to "ssh into isu1/isu2/isu3", "check the production server", "look at webapp logs", "tail webapp.log", "look at mysql slow log", "check nginx on the competition host", "deploy", "restart the webapp", or otherwise needs to connect to or inspect the ISUNARABE 2026 competition servers (isu1, isu2, isu3) from the local workstation. Do NOT use this skill if already running on one of the isu hosts — outbound SSH between competition hosts is not configured.
This skill should be used when the user asks to "ssh into isu1/isu2/isu3", "check the production server", "look at webapp logs", "tail webapp.log", "look at mysql slow log", "check nginx on the competition host", "deploy", "restart the webapp", or otherwise needs to connect to or inspect the ISUNARABE 2026 competition servers (isu1, isu2, isu3) from the local workstation. Do NOT use this skill if already running on one of the isu hosts — outbound SSH between competition hosts is not configured.
isu-hosts
Connect to and operate the three ISUNARABE 2026 competition servers (isu1,
isu2, isu3) from the local workstation. See repo-root CLAUDE.md for
project topology and deploy flow; this skill covers the SSH/operations side.
Roles may shift during the competition to rebalance load; re-check
env.all.sh and nginx.conf before assuming. Update this section when the
assignment changes.
Pre-flight self-check (mandatory)
Before issuing any ssh isuN ... command, confirm the current machine is the
local workstation, not a competition host. Outbound SSH from isu1/isu2/
isu3 to the others is not set up, and trying it will fail confusingly.
Check with:
hostname; hostname -I 2>/dev/null
Abort and tell the user to operate locally if any of these match:
hostname is / / (or any string containing )
isu1
isu2
isu3
isu
hostname -I shows an address in 192.168.0.0/24
A file /home/isucon/env.sh exists (only present on competition hosts)
On the competition host, run commands directly (no ssh isuN prefix) and
treat isuN references in this skill as "the current host."
Connecting
SSH aliases isu1, isu2, isu3 are configured in the workstation's
~/.ssh/config. Default user is isucon. Prefer one-shot commands
(ssh isuN '<command>') over interactive sessions for log peeks and status
checks — easier to capture output and parallelize.
To run the same probe on all three hosts in parallel, issue three Bash tool
calls in a single message rather than sequentially.
Service control
Service unit: nrb2026-webapp.service (defined in systemd/system/ in this
repo, mirrored to /etc/systemd/system/ on hosts by deploy.sh).
Webapp listens on port 80 directly (no TLS). nginx config: nginx.conf in
this repo, deployed to /etc/nginx/nginx.conf. Reload with
ssh isuN 'sudo nginx -t && sudo nginx -s reload'.
Logs
Webapp stdout+stderr: /var/log/webapp.log — rotated by deploy.sh to
/var/log/webapp.log.<timestamp> at every deploy.
MySQL slow log: /var/lib/mysql/mysql-slow.log — same rotation pattern.
DB host follows DATABASE_URL in env.all.sh (currently isu3). Re-check
that file before assuming — the team may move MySQL between hosts to balance
load.
ssh isu3 'sudo mysql nrb2026'
ssh isu3 "sudo mysql nrb2026 -e 'SHOW PROCESSLIST'"
Schema and seed data live at /home/isucon/webapp/sql/ on the host (and
webapp/sql/ in the repo). POST /api/initialize resets to bench-expected
initial state.
Deploying changes
From the local workstation (not from a host):
./push.sh # build + upload binary to S3
ssh isu1 './git/deploy.sh'# then on each host that should update
ssh isu2 './git/deploy.sh'
ssh isu3 './git/deploy.sh'
deploy.sh self-updates from git first, so commit and push before invoking
it. It restarts nrb2026-webapp.service, reloads nginx, and rotates the
webapp + slow logs — the rotation is convenient for "fresh log per bench
run" workflows.
To deploy to all three in parallel, issue the three ssh ... ./git/deploy.sh
calls in a single message.
Slow-query digestion (run on the host that has the log file, typically isu3):
ssh isu3 'sudo mysqldumpslow -s t /var/lib/mysql/mysql-slow.log | head -50'
If pt-query-digest or alp is installed, prefer those for richer output.
Don't install heavy tooling on the hosts mid-competition without a clear
reason — keep changes reversible.
What not to touch on the hosts
Per regulation (docs/regulation.md § 5, manual § 4.1) — modifying any of
these disqualifies the team:
/etc/systemd/system/isuwari.* and anything under /opt/isuwari/
the isuadmin user, its account, group, sudoers, or ~/.ssh/authorized_keys
frontend static files at /home/isucon/webapp/public/ (and the repo's
webapp/public/ — never edit)
For all other changes, edit files in this repo and deploy via push.sh +
deploy.sh. Direct edits on the hosts are fine for ad-hoc diagnosis
(mysql queries, tail, systemctl restart) but should not be the source
of truth for config — deploy.sh will overwrite nginx.conf and the
systemd unit on next run.
Competition-end constraint
All 3 hosts must be running at competition end (manual § 4.4, § 7). Stop
or reboot hosts via the AWS console freely during the competition, but
restart them all before the deadline — a stopped host means the 追試 reboot
check fails and the team is disqualified.
