Working on Scribe¶

My CEL analysis runs on Scribe, the UC Davis SSDS server — the restricted data and the right Stata setup live only there, so my pipelines run on Scribe, not on a laptop. This page covers getting set up, connecting, and running jobs (in batch, via the GUI, or under screen).

Status

Drawn from the lab's onboarding guides (XStata-on-Windows, Scribe How-To, screen) plus va_consolidated notes.

One-time setup¶

Connect to the DSS VPN. Scribe is only reachable over UC Davis's DSS VPN. Install OpenVPN Connect, connect to vpn.dss.ucdavis.edu, and sign in with your Kerberos (UC Davis) username and password.
Get Scribe access from CEL lab IT — they enable your Kerberos login for the lab's space. The host is Scribe.ssds.ucdavis.edu; password-prompt SSH is fine, no ~/.ssh/config alias or key setup needed.
Get your code onto Scribe by transferring the repo into the project folder (FileZilla, scp -r, rsync, drag-and-drop — your choice). Do not copy the .git/ folder onto Scribe.
Install required Stata packages once per account (each repo lists its packages, e.g. in .claude/rules/stata-code-conventions.md or the README).

Connecting¶

Connect to the DSS VPN first, then SSH in and run go_sbac:

ssh <your_kerberos_username>@Scribe.ssds.ucdavis.edu
go_sbac                          # set lab group permissions (run this each login)
cd /home/research/ca_ed_lab/projects/<project>/...

Run go_sbac after logging in

go_sbac sets the correct group permissions for the CA Education Lab. If you skip it, files you create may not be readable by the rest of the lab.

Keep the connection from timing out

For long or idle sessions, add a keepalive so the link isn't dropped for inactivity: ssh -o ServerAliveInterval=15 <user>@Scribe.ssds.ucdavis.edu (the same flag works with scp / sftp).

macOS: keep your laptop awake (caffeinate)

A session can also drop simply because your Mac went to sleep. caffeinate keeps it awake for as long as a wrapped command runs:

caffeinate -is ssh <user>@Scribe.ssds.ucdavis.edu   # -i = no idle sleep, -s = no sleep on AC power

Scope it honestly: this only fixes the laptop-slept cause. It won't stop a server-side idle timeout (that's what the keepalive above is for), and you don't need it for job survival — a batch run under screen / nohup (below) already outlives sleep, drops, and logout. Its real niche is keeping a live tail -f streaming overnight. (Standard macOS behaviour; I haven't stress-tested it against Scribe specifically.)

Running Stata: batch vs GUI¶

There are two ways to run Stata on Scribe. Batch is the recommended one; the GUI is there for quick interactive exploration, with real costs.

Batch (recommended)¶

stata-mp -b do do/main.do          # always stata-mp on the server, never plain `stata`

-b runs the script non-interactively and writes a log file. The win: the script is saved, so a dropped connection can't cost you any work. This is the mode the whole recommended workflow is built around — write the .do locally, sync it, run it in batch.

For long runs, detach so the job survives logout:

nohup stata-mp -b do do/main.do &
tail -f log/main_*.smcl            # follow the live log

GUI over X11 (for quick interactive poking)¶

You can run the full Stata GUI on the server with its windows showing on your laptop, via X11 forwarding. The GUI binaries on Scribe are xstata-mp (and xstata-se).

Mac (XQuartz). Install XQuartz, connect to the VPN, then SSH with trusted X11 forwarding (-Y):

ssh -Y <your_kerberos_username>@Scribe.ssds.ucdavis.edu
go_sbac
xstata-mp                        # or xstata-se

Windows (Xming + PuTTY). Install PuTTY and the Xming X server, then:

Launch Xming (it minimizes to the system tray).
In PuTTY, set the Host Name to Scribe.ssds.ucdavis.edu.
Under Category → Connection → SSH → X11, check Enable X11 forwarding and set the remote authentication protocol to MIT-Magic-Cookie-1. (Optionally save this as a session.)
With the DSS VPN connected, click Open, log in, run go_sbac, then xstata-mp.

See the full illustrated walkthrough (a screenshot for each PuTTY step): Stata GUI on Windows (Xming + PuTTY).

Good for a look, not your main editor

The GUI over X11 is handy for eyeballing data and poking at a few lines. You can write .do files in its do-file editor, but it's a slow place to do real work — laggy over the network, and a dropped connection takes whatever's unsaved in the buffer with it. I'd write in VSCode on my laptop instead and keep the GUI for quick exploration; anything worth keeping still lands in a saved .do file that runs in batch.

Keeping a session alive: `screen`¶

A dropped SSH connection normally kills whatever you were running. screen keeps a session alive on the server, so you can detach, log off, and reattach later — handy for long jobs and for keeping an interactive console open across disconnects.

screen -S ccylc          # start a named session
# ...launch your work, e.g.  stata-mp -b do do/main.do ...
# detach and leave it running: press Ctrl-a, then d
screen -ls               # list your sessions
screen -r ccylc          # reattach later (even after logging out and back in)

When you reattach, everything is exactly as you left it. (tmux does the same job if you prefer it.)

screen vs. nohup

For a fire-and-forget batch run, nohup stata-mp -b do do/main.do & (above) is simplest. Reach for screen when you want to come back to a live session — to watch progress, run several things, or keep a console open across disconnects.

If you can't reattach after a dropped connection

Sometimes a session doesn't detach cleanly. screen -list shows your sessions (one may read (Dead ???) or (Attached)). Force-detach a stuck one with screen -D, then screen -r to resume; clear dead ones with screen -wipe. To kill a session outright, screen -X -S <session> quit.