Mopar1973Man

Your First Rust Server: Hosting It on Your Home Server and Playing From Two PCsIf you've never set up a game server before, this is the beginner version — no anti-cheat rabbit holes, no plugin frameworks, just enough to get a private Rust server running on a Linux box at home and get two PCs connected to it so you can actually play. Once this works, you can grow into the more advanced stuff later. What you needA Linux machine on your home network to act as the server (this can be a spare PC, or a home server if you've already got one running) Two gaming PCs on the same local network, each with Rust installed through Steam That's it — for a small private server with just the two of you, you don't need anything fancy. A modest amount of RAM (8–16GB is plenty to start) and some free disk space will get you going. You can always upgrade later if the map feels sluggish. Step 1: Install SteamCMD on the serverSteamCMD is the tool that downloads and updates the actual Rust server files. On most Linux distributions you can install it from your package manager, or download it directly from Valve. Once it's installed, create a folder for your server, for example: mkdir -p ~/rustserver cd ~/rustserverStep 2: Download the Rust dedicated server filesFrom inside SteamCMD, you tell it to grab the Rust dedicated server app and install it into that folder: steamcmd +force_install_dir ~/rustserver +login anonymous +app_update 258550 +quitThat app ID (258550) is Rust's dedicated server on Steam — the anonymous login works fine since it's a public server download, no account needed. This step can take a while the first time since it's pulling down the full server package. Step 3: Write a simple start scriptYou don't need a complicated configuration for a first server. A small startup script with the basics is enough. Create a file called start.sh in your server folder: #!/bin/bash ./RustDedicated -batchmode +server.hostname "My First Rust Server" \ +server.port 28015 \ +server.level "Procedural Map" \ +server.seed 12345 \ +server.worldsize 3000 \ +server.maxplayers 10 \ +server.saveinterval 300 \ +server.secure 0A quick note on what matters here for a beginner: server.worldsize controls how big the map is (3000 is small and generates fast — good for testing), server.maxplayers is your player cap, and server.secure 0 turns off anti-cheat enforcement. That last one sounds scary, but for a private server with just you and one other person on your own network, it's completely fine — anti-cheat exists to stop strangers from cheating on public servers, which doesn't apply here. Make the script runnable and start it: chmod +x start.sh ./start.shThe first time it runs, it'll generate the map, which can take a few minutes depending on the world size. Once you see it settle and start printing regular status lines in the console, it's up and waiting for players. Step 4: Find your server's local IP addressSince both PCs are on the same home network, you just need the server machine's local IP — you don't need to mess with port forwarding on your router for this. On the server, run: ip addrand look for the address on your local network (usually something like 192.168.x.x). That, plus the port from your start script (28015), is what each PC will connect to. Step 5: Connect from each gaming PCOn each Windows PC, launch Rust through Steam like normal. Once you're at the main menu: Press F1 to open the console Type client.connect 192.168.x.x:28015, using your server's actual local IP Press Enter Do this on both PCs and you should both land in the same world. If a connection doesn't go through, double check that the server is actually up and printing normal console output, and that both machines are genuinely on the same local network (same router/subnet). A couple of things to expectWipes — nothing wipes your map automatically unless you tell it to. For a private server, you decide when to start fresh; just stop the server, delete the save files, and restart it. Performance — a small worldsize like 3000 with two players will run comfortably on modest hardware. If you later want a bigger map or more players, that's when RAM and CPU start to matter more. Plugins — none of this setup includes plugin support (Oxide/Carbon). That's a good next step once the basics feel comfortable, but it's not needed to just get two people playing together. That's genuinely all it takes to get a private Rust server running for two people on your own network. Once you're comfortable with this, the earlier post on the full production-style setup (hardware planning, LinuxGSM, plugin frameworks, and the EAC workaround for a public-facing server) is the natural next step.

Building RaymondRaymond is our local AI assistant — but it doesn't run on the server itself. It's Ollama split across two GPU gaming rigs, fronted by Open WebUI and a wake-on-demand dispatcher on the headless server that ties it all together. Here's how it's built and how it works. The hardwareAll three machines share the same board and CPU (ASUS ROG STRIX X870-A GAMING WIFI, Ryzen 5 7600X, 32GB DDR5, Intel I226-V networking) — the difference is what each one is for. Machine Role GPU Runs server Coordinator None — onboard AMD Radeon only Dispatcher + Open WebUI (Docker) michael-desktop Inference node RTX 5060 Ti, 16GB VRAM Ollama (set up first) suzanna-desktop Inference node RTX 5060 Ti, 16GB VRAM Ollama (identical build to michael) Why the server doesn't do the thinkingThe server has no dedicated GPU, so it was never a candidate for running inference itself. Both desktops have RTX 5060 Ti cards sitting idle most of the day, so the split is deliberate: inference happens on the workstations, and the server only coordinates — waking a workstation, routing the request to it, and serving the chat interface. Sharding one model across both GPUs as a single cluster was considered and passed over in favor of two fully independent Ollama instances, load-balanced by the dispatcher. Workstation use has no fixed schedule, so a wake-on-demand proxy fits better than any fixed sleep/wake timer. Architecture[ Browser ] --ask Raymond--> [ Open WebUI :3000 ] | v [ Dispatcher :11500 ] /michael /suzanna | | (WoL if asleep)| |(WoL if asleep) v v [ michael-desktop ] [ suzanna-desktop ] Ollama :11434 Ollama :11434 RTX 5060 Ti 16GB RTX 5060 Ti 16GBA request comes into Open WebUI, which is just the chat front end. It hands off to the dispatcher, which checks whether the target workstation is awake, sends a Wake-on-LAN magic packet if it isn't, and proxies the request through once it's up. Ports at a glancePort Service Host Notes 3000 Open WebUI server Chat UI, Docker container 11500 Dispatcher server /michael and /suzanna paths — wakes + proxies 11434 Ollama michael-desktop Bound to 0.0.0.0 via systemd override 11434 Ollama suzanna-desktop Same fix applied Build logOllama installed on michael-desktop — first workstation stood up, using its RTX 5060 Ti. Tested with qwen2.5:14b before anything else was wired up. Open WebUI deployed on the server — Docker container brought up at :3000, initially pointed straight at michael-desktop's Ollama instance. Fixed a network-binding snag — Open WebUI couldn't reach Ollama. Cause was Ollama listening on localhost only; fixed with OLLAMA_HOST=0.0.0.0 via a systemd override. (ufw was checked and confirmed inactive — not the culprit.) Grew the model lineup — michael-desktop's Ollama now also carries qwen3.5:9b, qwen3.5:4b, and qwen3.5:2b alongside the original 14b. Confirmed suzanna-desktop as a matching second node — same RTX 5060 Ti, 16GB VRAM, built identically to michael-desktop. Built the dispatcher and load-balanced routing — the server got a dispatcher on :11500 exposing /michael and /suzanna, each waking that workstation over Wake-on-LAN if asleep and proxying to its Ollama instance. Named it — Raymond — voice replies go out through Open WebUI's built-in text-to-speech, using the browser's Web Speech API. Not built yetObsidian integration is still just an idea: either feed notes into Open WebUI's Knowledge/RAG feature, or use an Obsidian plugin that queries Ollama directly. No decision made yet on which way to go. Software usedOllama — local model runtime, loads and serves the models on each workstation's GPU. (source) Open WebUI — self-hosted chat front end for Raymond, running in Docker on the server; also drives the TTS voice. (docs / source) Docker — container runtime hosting Open WebUI. Wake-on-LAN — protocol + wakeonlan tool the dispatcher uses to wake a sleeping workstation. (Debian Wiki) systemd — used for the OLLAMA_HOST override that got Ollama listening on the network. UFW — firewall checked (and ruled out) while debugging the WebUI ↔ Ollama connection. Web Speech API — browser TTS engine behind Raymond's voice output. Build notes — will update this thread as the setup grows. Example run of Raymond while discussing my cancer story and creation of Titanium

Landslide Cleanup — Progress SummaryThe Slide (May 29, 2025, 8:15 AM)The first photo captures the immediate aftermath of the landslide that came down off the hillside behind the property. A section of the slope let go, taking several large pine and fir trees down with it — they're shown lying flattened across the debris field, still rooted at the base but toppled toward the yard. The slide plowed straight through the diesel shop, leaving it sheared apart and tipped at a steep angle, its wood siding torn open and insulation hanging out. In front of it, an old pickup truck sits crushed and half-buried under the debris pile. Scattered across the foreground is the material that had to be sorted afterward: broken cinderblock, sheets of pink foam insulation, coiled blue tubing, splintered lumber, a mattress, and general shop contents thrown clear by the slide. Bare dirt is exposed high on the hillside where the slope failed. The Site Today (September 8, 2026, 11:00 AM)The second photo, taken from an elevated spot on the property looking back over the same ground, shows how much has changed in the roughly fifteen months since. The debris field and the wrecked shop are gone — that whole section has been cleared, graded, and turned back into usable yard and driveway. Where the wreckage once sat, there's now a mounded dirt berm running along the base of the hill (likely holding back the remaining slide material), with a low stone retaining wall marking the edge of the driveway in the foreground. The driveway itself has been re-cut and is drivable, with a car parked partway up it. Off to the right, the property has clearly moved on to normal use again: a solar panel array is set up on a post, vehicles and a small tractor implement are parked near a shop-type building, and stacks of sorted rock and cinderblock sit staged nearby rather than scattered as rubble — material kept back for reuse. A dog sits in the yard, and the grass and fruit tree in the foreground show the place is lived-in and maintained again. What the Photos Show Getting DoneBetween the two shots, the work visible is: clearing the collapsed shop and downed trees, hauling out the debris pile, separating reusable material (stone/concrete) from junk, regrading and re-establishing the driveway, and rebuilding the yard's infrastructure (solar setup, parking area) on top of the cleared ground. What was a fresh disaster scene in May 2025 reads, by September 2026, as an active, functioning yard again — with a visible stockpile of salvaged stone/block still on hand, presumably for the next phase of work. Ongoing WorkThe cleanup isn't finished. Dirt from the slide is still being worked through — pulling remaining garbage and debris out of it — and the cleaned dirt is being moved to the back yard to level out the ground back there. So the front area shown in the September photo is largely squared away, but the back yard is now the active project, being built up and leveled with what's salvaged out of the slide dirt. There's also no shop or dry covered space to work out of the weather, so as fall turns toward winter, this work has to keep pushing forward as long as outdoor conditions allow before the weather shuts it down.

Fuel pressure is controlled by a spring and check ball in the return port of the Fass. AirDog does the same. Now if you can find the right size washer you can shim the spring too increase pressure if needed. As for stability there is a spring mod I do. FASS and Airdog are known to push the checkball into the coil of the spring. So if you bend the last coil over 90° through the center this prevents the check from pushing into the coil causing pressure drop. One project ive gotta do is replace Thor's pressure spring with the new one and modify it too.