From: Skyebee Date: Tue, 30 Jun 2026 12:53:34 +0000 (-0400) Subject: Transfer old files to new structure X-Git-Url: https://skyeroc.xyz/gitweb/?a=commitdiff_plain;h=d17a89499f4418e79c7300af3f4e64a5a882f11d;p=flatmark Transfer old files to new structure --- diff --git a/.htaccess b/.htaccess index 86050b3..b513539 100644 --- a/.htaccess +++ b/.htaccess @@ -4,4 +4,5 @@ RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d +RewriteCond %{REQUEST_URI} !^/plantuml RewriteRule ^(.+)$ index.php [L,QSA] diff --git a/pages/01-header.md b/pages/01-header.md index 721ce1f..aa48ab8 100644 --- a/pages/01-header.md +++ b/pages/01-header.md @@ -1,13 +1,9 @@ {extras} -- [English](/en) -- [Deutsch](/de) +- [plantuml](https://skyeroc.xyz/plantuml/) {/extras} -![Logo](/files/logo.gif) +[SkyeRoc.xyz](/home) -[flatMark](/de) -A lightweight, flat-file Markdown-based website generator - -- [Home](/en/home) -- [Examples](/en/examples) -- [Download](/en/download) \ No newline at end of file +- [Home](/home) +- [Examples](/examples) +- [Download](/download) diff --git a/pages/Game-Setup.md b/pages/Game-Setup.md new file mode 100644 index 0000000..915f60c --- /dev/null +++ b/pages/Game-Setup.md @@ -0,0 +1,136 @@ +This page is to document some hints about the chroot environment. The scripts that all the various people have written and touched over the years are useful in creating and maintaining a dgamelaunch environment, but to be honest it's more helpful to understand exactly what is required for its basic functionality. + +Reading the scripts, reading the dgamelaunch source code if you know (or can work your way through) C, and reading the public documentation from various sources is enough to get you going, but I hope this repository can contribute some previously-undocumented requirements and precise instructions for setting up NetHack and Crawl in dgamelaunch on a Debian system. + +# General Tips +* There _must_ be a file called "dgamelaunch" at the root of your chroot for shmem to work correctly and allow for shared games. +* Adding a file owned by games:games to the root of your chroot called `dgldebug.log` will let dgl actually write to dgldebug.log +* When building the chroot, and installing and testing games there, it's +tempting to run as root instead of using `sudo` all the time -- don't do it. +The primary reason for my recommendation against is that if you chroot as root, +all the programs you run are run as root instead of (evidently) dropping +privileges to the sudoer user... and this actually breaks NetHack. You get +segfaults from getmailstatus(). + +# Game setup +## All Games +dgamelaunch is relatively-fragile, and not that good about reporting its errors. +* always chown variable data dirs to games:games (good reason to keep them in /var ) +* Make sure `inprogressdir` and `ttyrecdir` exist +* Make sure all game definitions in dgamelaunch.conf have valid settings + +## NetHack 5.0.0 +### Notes +* If you build NetHack in an environment that contains `/usr/bin/gdb`, you will +have to modify your `sysconf` file to comment out a line and 0 out another: +```bash +#GDBPATH=/usr/bin/gdb +GREPPATH=/bin/grep +# Values are priorities: 0 - do not use this method, 1 - low priority, +# 2 - high priority. Non-zero priority methods are tried in order. +PANICTRACE_GDB=0 +PANICTRACE_LIBC=2 +``` +* If you're getting a crash on startup and you see "getmailstatus" as one of the function calls, that was happening for me when I ran `chroot . ` while I was already root. Try it from a normal user account. +### dgamelaunch.conf entry +``` +DEFINE { + game_path = "/bin/nh500" + game_name = "NetHack 5.0.0 (curses)" + short_name = "nh500curses" + game_args = "/bin/nh500", "-u", "%n", "-wcurses" + spooldir = "/mail/" + rc_template = "/etc/dgl-default-rcfile.nh500" + rc_fmt = "%ruserdata/%n/%n.nh500rc" + inprogressdir = "%rinprogress/nh500curses/" + ttyrecdir = "%ruserdata/%n/ttyrec/" + commands = cp "/var/nh500/save/%u%n.gz" "/var/nh500/save/%u%n.gz.bak", + setenv "NETHACKOPTIONS" "@%ruserdata/%n/%n.nh500rc", + setenv "MAIL" "/mail/%n", + setenv "SIMPLEMAIL" "1", + unlink "/mail/%n" +} +``` +## Dungeon Crawl Stone Soup 0.34.1 +### Notes +* You might want to check out the supplied install instructions, the .h files, etc, for extra configuration. +* Explore mode is not disabled by USE_DGAMELAUNCH -- you'd have to do that yourself by modifying the source. + +### Configuration +```bash +make prefix=/ DESTDIR=/srv/dgamelaunch DATADIR=/etc/dcss0341 \ + SHAREDDIR=/var/dcss-common SAVEDIR=/var/dcss0341 USE_DGAMELAUNCH=1 install +``` +### dgamelaunch.conf +``` +# Defining DCSS +DEFINE { + game_path = "/bin/crawl" + game_name = "Dungeon Crawl Stone Soup 0.34.1" + short_name = "dcss0341" + game_args = "/bin/crawl", "-name", "%n", + "-dir", "/var/opt/dcss0341/saves", + "-morgue", "/var/opt/dcss0341/morgue" + spooldir = "/mail/" + rc_template = "/etc/dcss0341/settings/init.txt" + rc_fmt = "%ruserdata/%n/%n.dcss0341rc" + inprogressdir = "%rinprogress/dcss0341/" + ttyrecdir = "%ruserdata/%n/ttyrec/" + commands = setenv "CRAWL_RC" "@%ruserdata/%n/%n.dcss0341rc", + setenv "MAIL" "/mail/%n", + setenv "SIMPLEMAIL" "1", + unlink "/mail/%n" +} +``` +``` +DEFINE { + game_path = "/bin/crawl" + game_name = "Dungeon Crawl Stone Soup 0.34.1 Sprint" + short_name = "dcss0341sprint" + game_args = "/bin/crawl", "-name", "%n", + "-dir", "/var/opt/dcss0341/saves", + "-morgue", "/var/opt/dcss0341/morgue", + "-sprint" + spooldir = "/mail/" + rc_template = "/etc/dcss0341/settings/init.txt" + rc_fmt = "%ruserdata/%n/%n.dcss0341rc" + inprogressdir = "%rinprogress/dcss0341sprint/" + ttyrecdir = "%ruserdata/%n/ttyrec/" + commands = setenv "CRAWL_RC" "@%ruserdata/%n/%n.dcss0341rc", + setenv "MAIL" "/mail/%n", + setenv "SIMPLEMAIL" "1", + unlink "/mail/%n" +} +``` +## Angband 4.2.6 +### Notes: +* Haven't figured out if there's anything like an 'RC file'; I was just excited to get it working +* Angband might (or might not) be insecure +### Configuration +```bash +./configure --prefix=/. --bindir=/bin --sysconfdir=/opt/ang426 \ + --datarootdir=/var/opt/ang426 --localstatedir=/var/opt/ang426 \ + --without-x --disable-x11 --with-gamedata-in-lib --disable-borg \ + --enable-stats --with-private-dirs +make DESTDIR=/srv/dgamelaunch install +``` +### dgamelaunch.conf +``` +DEFINE { + game_path = "/bin/angband" + game_name = "Angband" + short_name = "ang426" + game_args = "/bin/angband", + "-duser=/var/userdata/%n/ang426", + "-dsave=/var/userdata/%n/ang426/save", + "-dpanic=/var/userdata/%n/ang426/panic", + "-darchive=/var/userdata/%n/ang426/archive", + "-dscores=/var/opt/angband-common/scores" + inprogressdir = "%rinprogress/ang426/" + ttyrecdir = "%ruserdata/%n/ttyrec/" + +# Organization +My chroot is structured loosely in the same way as a real root in the standard POSIX filesystem hierarchy. This makes installing and configuring games pretty easy, and it made troubleshooting missing locale-archive file easy also, so I recommend it. + +See [In Depth Chroot](in-depth-chroot) for more... +``` \ No newline at end of file diff --git a/pages/Home.md b/pages/Home.md new file mode 100644 index 0000000..663bce1 --- /dev/null +++ b/pages/Home.md @@ -0,0 +1,19 @@ +# dgamelaunch 1.6.1-roc +See the README for fast installation. + +## dev branch +As of this writing, the dev branch contains more upgrades to the menu system -- in particular, support for background colors and flashing text. See here: + +1.6.0-hdf + +![1.6.0-hdf](img/colors/1.6.0-hdf.png) + +1.6.1-roc dev branch + +![1.6.1-roc dev](img/colors/1.6.1-roc-dev-jul26.gif) + +Sections here: + +* [In-depth setup guide](#!dgamelaunch/Server-Setup.md) +* [Hints for a handful of games](#!dgamelaunch/Setup-Hints.md) +* [Some resources from over the years](#!dgamelaunch/resources.md) diff --git a/pages/Server-Setup.md b/pages/Server-Setup.md new file mode 100644 index 0000000..a4b773f --- /dev/null +++ b/pages/Server-Setup.md @@ -0,0 +1,539 @@ +# dgamelaunch from scratch +## pre(r)amble; chroot structure and installing games +If you're like me you might want to know how to construct the chroot on +your own. If you're installing dgamelaunch on a public server, you probably +_should_ know. There are good reasons for understanding the chroot: a +necessary step for getting Crawl to work right (not to mention Angband and +others) is copying locale data, just like terminfo. This is not done by the +provided scripts, and is not hinted at anywhere that I've seen... now you +know, at least. It's accomplished below by binding the entire `/usr/lib` +directory instead of copying specific libraries individually. + +We almost might as well construct an _entire_ gnu-like chroot, but that's +a project for a different time. The primary thing one must understand is that +the chroot environment you set up for dgamelaunch must contain every dependency +for every game and program installed in it (other than dgamelaunch itself). + +This actually makes installing most games into the system trivial, except that +modifications must typically be made either to the source code or the build +environment to secure the game so that players can't use it to clobber or +otherwise interfere with the chroot. If the game has even an almost-typical +build process, you just have to set `prefix=/` (or accept having your games +buried in `//usr`) and set `DESTDIR=/`. You might have to get +clever with some games that stray too far from this near-typicality with their +build process and ignore/have strange behaviour when using prefix or DESTDIR. +You also might have to set other build options specific to the game, pointing +to specific directories for save data etc in order to place the game where +you want within the chroot. See my Angband hints for an example. + +After that, you sometimes have to copy required libraries. Look for cpbin in +this repo for a helper script (provided without warranty). The final result is +a game that only runs if you call it like this: +`sudo chroot / ` -- because the game is looking for files +in the real root that only exist in the chroot envrionment. + +The only requirement for the game is, if you want players to have a unique +identity from the perspective of the game, there must be some way to pass in a +username whether by command line or environment variable. For example, you can +run NetHack with `-u `. Any features of the game which rely upon a +private directory -- sometimes games construct entire directory trees inside +the user's HOME under normal conditions -- must be controllable through similar +means. For example, you can set `NETHACKOPTIONS` environment variable to an +arbitrary file prior to running NetHack, so per-user RC files are a thing. + +Obviously the game also has to run in ascii/unicode mode. By the by, unicode +seems to work fine for me once you move the right locale files into the chroot. +The stripgfx stuff is designed for 'downgrading' graphics -- so that you can +watch (maybe play) a game that is sending characters your software can't render, +with reasonable replacements provided. + +## everything the makefile is supposed to do but dgl-create-chroot does instead +So, if installing most games is relatively-easy, the hard part is of course +creating the chroot environment. In practice it isn't hard, really, but it is +kind of obscure. You are using `mknod`. You are using `ldd`. Who ever needs to +use these fundamental tools? You do, if you're reading this. + +The title of this section is misleading -- this deviates from +dgl-create-chroot's patterns, primarily in the structure of the chroot. But in +my humble opinion, this is the way. + +### fetching dependencies, configuring, and compilation +First, let's compile dgamelaunch. After cloning dgamelaunch (a/o right now +versioning will be broken if you don't clone it), navigate to the directory +containing all of the source code. This is henceforth known as the "source +directory". dgamelaunch uses autoconf to make itself portable -- here is the +full command I use. Change anything you like, just make sure you remember what +you changed! That will make upgrading it later a lot easier. Refer to +`config.log` after the fact, if you forget. + +**NOTICE that** (a/o 1.6.1) our input for `--prefix` is the chroot and +`--with-config-file` _includes_ the chroot, while `--with-sqlite-db` does not! + +**NOTICE that** also, we do not use `make install`. For some reason, +dgamelaunch has never (afaik) been able to install itself without +`dgl-create-chroot` or other scripts. For funsies, we're +going to perform all of the operations dgl-create-chroot would, by ourselves. + +```bash +./autogen.sh --prefix=/srv/dgamelaunch --enable-debugfile --enable-sqlite \ + --enable-shmem --with-sqlite-db=/var/dgl/dgamelaunch.db \ + --with-config-file=/srv/dgamelaunch/etc/dgl/dgamelaunch.conf +make all +``` + +You might have to install some development libraries, for example +`libncursesw-dev` or `libsqlite3-dev`. You will have to do this with most games +also, because we are building them specifically for this weird chroot-system. +You will usually get reasonably-descriptive errors out of the configure scripts, +which can help you know what packages to install. + +### Building the chroot by hand +#### make the whole directory tree +Next let's start making the chroot directory. Historically, examples use +`/opt/nethack/nethack.alt.org`. Just a moment ago we used `/opt/dgamelaunch`. +`/opt/<...>` or `/srv/<...>` both seem like reasonable options. +```bash +mkdir -p /srv/dgamelaunch +``` + +Now make locations for static data (menus, configuration) and variable/runtime +data (database, inprogress games directory, userdata), and everything else in +the chroot. The `--with-config-file` option above points at a file in our +static directory. Within the config file, the `chroot_path` and `dglroot` +settings point to the chroot directory/prefix and the variable directory, +respectively. Historically, the chroot itself held config/menu files, and +`/dgldir` held variable stuff. I use `/etc` and `/var`, and put game data in +subdirectories there too. This is already obviously like a filesystem +hierarchy, so let's create some of the other recognizable directories too. +```bash +cd /srv/dgamelaunch +mkdir -p ./etc/dgl/menu ./var/dgl/userdata ./var/dgl/inprogress ./mail \ + ./usr/lib ./usr/lib64 ./usr/share/terminfo ./bin ./dev + +``` + +#### installing system libraries +We'll use a read-only bind mount instead of copying whole libraries. This will +mount the `/usr/lib` directory inside our chroot, in addition to its canonical +location, so it can be accessed from there without any copying (and without +the risk of an installer or security flaw messing with our server's actual +libraries). We'll also create a symlink to the new mount from +`/srv/dgamelaunch/lib`. + +**NOTICE that** libraries by default might not be under `/usr/` -- it depends +on your system. It might not matter except that for ease of installation with +games, I found it best to closely-mirror my real system's hierarchy. I am using +Debian, things are typically installed in the `/usr/` hierarchy by default, so +that's what I'm sticking with. Check by using `ls -l /` -- if `/lib` is a +symlink to `/usr/lib`, it'll look like this; the same goes for `/lib64`: +`lrwxrwxrwx 1 root root 7 Aug 11 2025 lib -> usr/lib` +If it's not, it won't have the `-> usr/lib` and the first letter flag will +be `d` instead of `l`: +`drwxrwxrwx 1 root root 7 Aug 11 2025 lib` + +**NOTICE that** the first argument to `ln -s` has to be +valid from within whatever context the link is being followed -- that is, after +running `ln -s` below, `/srv/dgamelaunch/lib` will point to your system's +`/usr/lib` directory. But after the chroot, it will point to +`/srv/dgamelaunch/usr/lib` -- at that point, from the program's perspective, +`/srv/dgamelaunch` will just be `/`. + +In principle, you could mount the entirety of `/usr`; it is meant to be +mountable read-only. But I'm not sure about how secure that would be. +If you don't want to use mount for /lib either, feel free to instead populate +/lib by hand with the necessary libraries. Use `ldd ` to find out what +libraries a program is using, and where they are supposed to live -- and see +`cpbin` and the source of `dgl-create-chroot` for hints/automatic copying. +```bash +# Since util-linux 2.27, you can just use one mount command: +# mount -o bind,ro /usr/lib ./usr/lib +mount --bind /usr/lib ./usr/lib +mount -o remount,bind,ro /usr/lib ./usr/lib +mount --bind /usr/lib64 ./usr/lib64 +mount -o remount,bind,ro /usr/lib64 ./usr/lib64 +# /usr/lib(64) will still point to the corect place after chroot +ln -s /usr/lib ./lib +ln -s /usr/lib64 ./lib64 +``` + +**NOTICE DO NOT mount /lib or /lib64 as writable!!!** You will _undoubtedly_ +someday be tempted to nuke everything and start over, and if you do that after +mounting your own system's /lib and /lib64 as writeable directories inside the +chroot, you're going to get to rebuild a lot more than dgamelaunch. + +#### installing terminfo data +While we're doing this kind of thing, we'll also make a link to `terminfo`. As +I mentioned with `/usr/lib`, the exact location of the `terminfo` directory +will depend upon your system's configuration. On Debian, it's in +`/usr/share/terminfo`. Other possible locations, which are searched in this +order by ncurses, are the `${HOME}/terminfo`, `/etc/terminfo`, and +`/lib/terminfo` (sometimes aka `/usr/lib/terminfo`) directories. +(`/usr/share/terminfo` is searched last) + +```bash +mount --bind /usr/share/terminfo ./usr/share/terminfo +mount -o remount,bind,ro /usr/share/terminfo ./usr/share/terminfo +``` + +After these mount operations, if you type `mount` alone, you should see lines +something like this (maybe with different device files for your drive): +```bash +$ mount | grep "/srv/dgamelaunch" +/dev/sda2 on /srv/dgamelaunch/usr/lib type ext4 (ro,relatime) +/dev/sda2 on /srv/dgamelaunch/usr/lib64 type ext4 (ro,relatime) +/dev/sda2 on /srv/dgamelaunch/usr/share/terminfo type ext4 (ro,relatime) +``` + +**NOTICE that** if you do use `mount --bind`, you'll have to run it every time +your system reboots -- or, you'll have to add lines to `/etc/fstab`, in your +real root (not the chroot /etc), like this: +```bash +# /etc/fstab: static file system information +# [...] +# dgamelaunch bind mounts +/usr/lib /srv/dgamelaunch/usr/lib none bind 0 0 +/usr/lib /srv/dgamelaunch/usr/lib none remount,bind,ro 0 0 +/usr/lib64 /srv/dgamelaunch/usr/lib64 none bind 0 0 +/usr/lib64 /srv/dgamelaunch/usr/lib64 none remount,bind,ro 0 0 +/usr/share/terminfo /srv/dgamelaunch/usr/share/terminfo none bind 0 0 +/usr/share/terminfo /srv/dgamelaunch/usr/share/terminfo none remount,bind,ro 0 0 +``` + +#### creating the user database +Next, we'll create the sqlite3 database real quick, so that it exists when we +chown the whole /var hierarchy in a minute. +```bash +sqlite3 "./var/dgl/dgamelaunch.db" "create table dglusers \ + (id integer primary key, username text, \ + email text, env text, password text, \ + flags integer);" +chown games:games ./var/dgl/dgamelaunch.db +``` + +#### chowning the whole /var hierarchy +We need to chown some parts of this hierarchy, and all files that go in there +for the most part, to the user/group specified in dgamelaunch.conf. +Historically, this is games:games. At this stage we can just do this: +```bash +chown -R games:games var mail +``` + +#### make a randomness device file +Now I mentioned that all of the dependencies for every game have to be in this +root, so let's start doing that. First we'll make the urandom device, which is +used to produce pseudo-randomness. Remember that we changed directory into the +chroot a while ago. +```bash +cd dev +mknod urandom c 1 9 +cd .. +``` + +### Installing dgamelaunch +So, the chroot is basically complete now. Our next step is to copy +dgamelaunch's static files, and make the database. I'm assuming here that you +compiled with sqlite3 -- if you didn't, I haven't looked at how the flatfile +version works. It might create the db for you. + +We'll use `cp` to actually copy the static stuff, rather than mounting that... +`` is where we ran autogen.sh/built dgamelaunch. + +**NOTICE that** we went back to the chroot at the end of the last code sample. +```bash +cp /examples/dgl_menu*.txt /examples/dgl-banner \ + ./etc/dgl/menu +cp /examples/dgamelaunch.conf.orig ./etc/dgl/dgamelaunch.conf +cp /dgl-default-rcfile ./etc/dgl +``` + +Finally, we'll copy dgamelaunch itself, and virus and ee (text editors modified +for the chroot and shipped with dgamelaunch) We have to set the owner of +dgamelaunch to `root`, so that it has the authority to set the chroot before +dropping privileges to the `games` user/group. `chmod a+s` allows unprivileged +users to run the program, even though it is owned by root. (it should already +have the e(x)ecutable mode flag) + +**NOTICE that** due to an unresolved bug/early design choice, you need a file +called `dgamelaunch` directly in the root directory for watching to work. ergo +`touch dgamelaunch`. +```bash +cp /ee /virus /dgamelaunch \ + ./bin +chown root:root ./bin/dgamelaunch +chmod a+s ./bin/dgamelaunch +touch dgamelaunch +``` +We're done! If you run `dgl-create-chroot`, or `install-dgl-nh500`, this is +essentially what the scripts are doing, with the exception of the remount +stuff. Instead of remounting `/usr/lib` and `/usr/share/terminfo`: those +scripts automate copying the correct libraries and terminfo directory. + +Open `/srv/dgamelaunch/etc/dgl/dgamelaunch.conf`, and modify the chroot_path, +dgl_root, and the locations of menus and the rc file, if necessary. + +Now, you should be able to just run /srv/dgamelaunch/bin/dgamelaunch, and +create a user. It may be a bug I introduced, I haven't checked, but right now +you have to send some input once before dgamelaunch hears your input. + +Now, as a bonus, let's install Dungeon Crawl Stone Soup, so that we can see +what I meant about installing games being reasonably-trivial. Crawl, +ironically, is probably more-trivial than NetHack, which needs some +more-detailed attention at the minute (although this appears to be addressed by +the efforts of the dev team, including one of the original developers of +dgamelaunch, paxed). + +```bash +cd ${HOME} +wget https://github.com/crawl/crawl/releases/download/0.34.1/stone_soup-0.34.1.zip +# (or clone the git repo) +unzip stone_soup-0.34.1.zip +cd stone_soup-0.34.1/source +make prefix=/ DESTDIR=/srv/dgamelaunch DATADIR=/etc/dcss0341 \ + SHAREDDIR=/var/dcss-common SAVEDIR=/var/dcss0341 USE_DGAMELAUNCH=1 install +chown -R games:games /srv/dgamelaunch/var +``` + +If your CPU has more than one core, Consider adding `-jn` to the options you +pass to make, where `n` is the number of cores. Also, Read +`stone_soup-0.34.1/source/Makefile`, for more information about the options. It +also lists necessary dependencies, like `liblua5.4-dev`. This is true of most +Makefiles, and most of the time where a `configure` script is involved (or +`autogen`) you can pass `--help` to it (like `./autogen.sh --help`) to learn +more about the options available for a specific package. Try it with +dgamelaunch! + +We still have to update dgamelaunch.conf, and the menus, to make crawl +accessible. I leave that as an exercise for the determined user. Uncomment/ +modify one of the examples in the dgamelaunch.conf. Find the default RC file at +`etc/dcss0341/settings/init.txt`. Make sure the `inprogressdir` exists. Make +sure `ttyrecdir` is set to something with a trailing slash. + +There may also be some commands you will have to copy into `/bin`, in general +-- often programs use `grep` and `gzip`, for example. By now you should +understand generally how this works, though. :) (you can just copy `/bin/grep` +etc) + +# Server Setup +To allow non-root users to use dgamelaunch, you have to `chmod` it because it has special privileges. +```bash +sudo chmod a+s /dgamelaunch +``` + +**NOTICE that** this is a relatively-dangerous thing to do... any user can run dgamelaunch on your system, which might potentially create a vulnerability if they somehow have write access to the binary. + +If you've installed dgamelaunch on a multi-user system, then users can just call the binary directly. If you want people to connect over the internet, but you don't want each of them to have their own logins, here are the steps. + +Set up a new user -- on Debian: +```bash +sudo adduser nethack +``` +And follow the prompts. Name the user whatever you like, and give bogus info +for everything other than password. + +Now edit `/etc/passwd`. The new user's line will look like this: +```bash +nethack:x:::nethack,1,1,1,1:/home/nethack:/bin/bash +``` + +You need to modify the new user's line: +```bash +nethack:x:::nethack,1,1,1,1:/home/nethack:/opt/dgamelaunch/bin/dgamelaunch. +``` + +What we are doing there is setting the user nethack's login shell to the +dgamelaunch binary. This way, when someone uses SSH to connect to your server, +and logs in as nethack, they will be presented immediately with dgamelaunch, and +will not see a shell when it exits. + +## Security +Just extremely-basic stuff, in case you've never set up a webserver before. I'm +not an expert. Nonetheless, listen -- as soon as you set your server up, and +open it to the internet, it will start getting bombarded with attackers +spamming ssh authorization attempts with various common usernames (including +root) and probably some kind of dictionary attack script. + +If you set up a really good password on root, or if you have other common +usernames on your system (see `journalctl -u ssh` example below), it's a matter +of time before someone breaks in and maybe wreaks havoc. + +Here's sshd log from my server's first breath. It took only two hours! +``` +Jun 16 06:18:30 dedirock-26589877 systemd[1]: Starting ssh.service - OpenBSD Secure Shell server... +Jun 16 06:18:30 dedirock-26589877 sshd[670]: Server listening on 0.0.0.0 port 22. +Jun 16 06:18:30 dedirock-26589877 sshd[670]: Server listening on :: port 22. +Jun 16 06:18:30 dedirock-26589877 systemd[1]: Started ssh.service - OpenBSD Secure Shell server. +Jun 16 06:42:54 dedirock-26589877 sshd-session[868]: Connection reset by 178.130.47.195 port 46334 [preauth] +Jun 16 07:26:27 dedirock-26589877 sshd-session[892]: banner exchange: Connection from 52.14.238.54 port 56106: invalid format +Jun 16 08:14:51 dedirock-26589877 sshd-session[906]: banner exchange: Connection from 172.235.41.245 port 41596: invalid format +Jun 16 08:36:16 dedirock-26589877 sshd-session[916]: Unable to negotiate with 172.236.228.86 port 52748: no matching host key type found. Their offer: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nist> +Jun 16 08:39:37 dedirock-26589877 sshd-session[921]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=160.187.174.22 user=root +Jun 16 08:39:39 dedirock-26589877 sshd-session[921]: Failed password for root from 160.187.174.22 port 53978 ssh2 +Jun 16 08:39:41 dedirock-26589877 sshd-session[921]: Connection closed by authenticating user root 160.187.174.22 port 53978 [preauth] +Jun 16 08:39:43 dedirock-26589877 unix_chkpwd[926]: password check failed for user (root) +Jun 16 08:39:43 dedirock-26589877 sshd-session[924]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=160.187.174.22 user=root +Jun 16 08:39:44 dedirock-26589877 sshd-session[924]: Failed password for root from 160.187.174.22 port 57230 ssh2 +Jun 16 08:39:45 dedirock-26589877 sshd-session[924]: Connection closed by authenticating user root 160.187.174.22 port 57230 [preauth] +Jun 16 08:39:46 dedirock-26589877 sshd-session[927]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=160.187.174.22 user=root +Jun 16 08:39:48 dedirock-26589877 sshd-session[927]: Failed password for root from 160.187.174.22 port 57236 ssh2 +Jun 16 08:39:50 dedirock-26589877 sshd-session[927]: Connection closed by authenticating user root 160.187.174.22 port 57236 [preauth] +Jun 16 08:39:52 dedirock-26589877 unix_chkpwd[932]: password check failed for user (root) +Jun 16 08:39:52 dedirock-26589877 sshd-session[930]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=160.187.174.22 user=root +Jun 16 08:39:54 dedirock-26589877 sshd-session[930]: Failed password for root from 160.187.174.22 port 58674 ssh2 +Jun 16 08:39:55 dedirock-26589877 sshd-session[930]: Connection closed by authenticating user root 160.187.174.22 port 58674 [preauth] +Jun 16 08:39:58 dedirock-26589877 sshd-session[933]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=160.187.174.22 user=root +Jun 16 08:40:00 dedirock-26589877 sshd-session[933]: Failed password for root from 160.187.174.22 port 58684 ssh2 +Jun 16 08:40:01 dedirock-26589877 sshd-session[933]: Connection closed by authenticating user root 160.187.174.22 port 58684 [preauth] +Jun 16 08:40:03 dedirock-26589877 unix_chkpwd[938]: password check failed for user (root) +Jun 16 08:40:03 dedirock-26589877 sshd-session[936]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=160.187.174.22 user=root +Jun 16 08:40:05 dedirock-26589877 sshd-session[936]: Failed password for root from 160.187.174.22 port 36888 ssh2 +Jun 16 08:40:07 dedirock-26589877 sshd-session[936]: Connection closed by authenticating user root 160.187.174.22 port 36888 [preauth] +``` +### sshd +The simplest way to protect against this, from the very first, is to disable +password authentication and use ssh keys. + +#### "wait idek how to make a key" +Here's the simple way to set up an ssh key. You have two computers, your LOCAL +computer, and your REMOTE computer. The REMOTE is the one you are shelling +into, using your LOCAL computer. + +**On your LOCAL computer:** open your command prompt, on windows or linux or +probably mac it's the same command: +```bash +ssh-keygen +``` +You will see: +```bash + Generating public/private ed25519 key pair. + Enter file in which to save the key (/home/skye/.ssh/id_ed25519): +``` + +You enter a filename, make sure it is in your .ssh folder. If you like, enter a +password. You can also pass options to ssh-keygen to change the type of key that +is generated, etc. Out of scope for this document. + +**On your REMOTE computer:** I'm assuming linux here. If you already have an +`authorized_keys` file in `${HOME}/.ssh`, skip this next step. Otherwise, run +the following commands: +```bash +$(umask 0066; touch ~/.ssh/authorized_keys) +``` +`$()` executes the commands in a subshell (so umask doesn't mess with your head +later); `umask` sets a mask over the default file creation mode. tl;dr it sets +`authorized_keys` so no one else can read or write but you. `touch` creates a +file or updates it. + +Now, open `~/.ssh/authorized_keys` with whatever text editor you like. I just +use nano, it's pretty intuitive: +```bash +nano ~/.ssh/authorized_keys +``` + +Back **on your LOCAL computer**, take a look in the directory you saved your +key to (eg `/home/skye/.ssh/`) and open `key_file.pub` where `key_file` is +whatever you saved the key as. (eg id_ed25519) + +There should be only one line of text. Copy this line of text from that file, +and paste it into the `authorized_keys` file **on your REMOTE computer**. Note +-- DO NOT copy or upload the other key_file` file; that is your "private" key, +and is what will allow you to access your server as you. + +Save the file there. **on your LOCAL computer**, type the following command: +```bash +ssh-add +``` + +This will, for at least the current session, tell ssh that this is among the +keys you wish to use. If you have some keyring or other software designed to +manage this, I trust you know what you're doing by yourself. + +#### /etc/ssh/sshd_conf +We should be done locally, so **on your REMOTE computer**, edit +`/etc/ssh/sshd_conf` (again using `nano` or whatever editor you prefer) and +add these lines to the bottom: +```bash +# local changes/site configuration +PasswordAuthentication no +# Match User nethack,nethackdev +# PasswordAuthentication yes +``` +These lines turn off password authentication. + +If you uncomment the last two lines, it will do so except for the `nethack` and +`nethackdev` users. If an attacker guesses one of these passwords, they'll be +dropped into dgamelaunch. Whether they can do anything from there, I don't know. +Many public servers in the wild either have no password on the `dgamelaunch` +login user, or have a publicly-available private key for logging into the +server. The choice is yours. + +Now, run `systemctl restart sshd`, and BEFORE you log out of your current SSH +session, try logging in with a second session. You might have to `ssh-add` your +key again. You might have to check the permissions on `authorized_keys` -- they +should be 0600, or readable/writable for owner only. Double-check that your +public key is copied exactly. + +If it works, then you're all set. Those dictionary attacks will probably just +stop at this point, but we're going to take another couple of precautions. + +### Firewall +Download and install `ufw` or your preferred firewall. +```bash +apt install ufw +``` + +Set ufw up like so: +```bash +ufw default deny incoming +ufw default allow outgoing +ufw allow 80 +ufw allow 443 +ufw limit 22 +``` +This will allow deny incoming traffic by default, allow it on 80 and 443, and +limit it on 22. "Limit" means rate-limit, if someone connects some number of +times in too-quick succession, it will just start refusing to connect. + +Don't forget to enable it: +```bash +ufw enable +``` + +And use `ufw status` to double-check your settings. Output: +```bash +Status: active + +To Action From +-- ------ ---- +443 ALLOW Anywhere +22 LIMIT Anywhere +80 ALLOW Anywhere +443 (v6) ALLOW Anywhere (v6) +22 (v6) LIMIT Anywhere (v6) +80 (v6) ALLOW Anywhere (v6) +``` + +If you run other services on your server, you'll have to allow those ports. + +### fail2ban +fail2ban performs a kind of similar function to ufw's rate-limiting on port 22: +it will automatically ban IP addresses guilty of failed authorization attempts, +for a configurable period of time. This one worked out of the box for me. + +```bash +apt install fail2ban + +# later... +fail2ban-client banned +``` + +Example output from `fail2ban-client banned`: +```bash +[{'sshd': ['91.xx.xx.xx']}] +``` + +It is probably worthwhile to learn how to configure fail2ban for yourself. I +plan on doing so, but since it worked immediately, I didn't feel a pressing +need. Truth be told, once I changed ssh config and installed ufw, fail2ban +stopped catching quite as many attackers; presumably it stopped being worth +their effort to try. But it caught that one just above, that's real output +(with "x"s superimposed by me). \ No newline at end of file diff --git a/pages/home.md b/pages/home.md index 9e6ad7b..cdb8966 100644 --- a/pages/home.md +++ b/pages/home.md @@ -1,22 +1,36 @@ ---- -title: flatMark - lightweight, flat-file Markdown-based website generator -description: No database required, no overhead in sight — just Markdown and a sprinkle of PHP. Ideal for small websites, portfolios, or documentation, it delivers content directly from the filesystem. Just edit your Markdown files and go. -robots: index, follow ---- - -{background color-02}{columns 33-66} -{img-rounded} -![Pic](/files/example-pic-01.jpg) -{/img-rounded} -{columns-seperator} -# flatMark -No database required, no overhead in sight — just Markdown and a sprinkle of PHP. Ideal for small websites, portfolios, or documentation, it delivers content directly from the filesystem. Just edit your Markdown files and go. -{/columns}{/background} - -{columns 33-66} -![Pic](/files/example-pic-02.jpg) -{columns-seperator} -![Pic](/files/example-pic-03.jpg) -{/columns} - -{readme} \ No newline at end of file +#skyeroc.xyz +##Services +Here are some of the things you can find around here. + +* Armagetron AD (aka Retrocycles) servers: + * 6x6 - Skyebee's Friendly Fortress +* dgamelaunch instance + * SSH user: nethack@skyeroc.xyz + * password:leninwalks + * private key + * Currently-available games: + * NetHack 5.0.0 + * Crawl Stone Soup 0.34.1 + * Angband 4.2.6 +* git repos (see section below) + +## git repos +Mildly-interesting, you can view my local (public) git repos, thanks to gitweb. + +If you see one you're interested in, you can clone it from git://skyeroc.xyz/--e.g. the dgl-simpleconf project can be cloned using `git clone git://skyeroc.xyz/dgl-simpleconf` + +I have some repos out there with no local mirror, athough I will likely change that in the future. + +### dgamelaunch v1.6.1-roc +dgamelaunch is ~23 years old, a program that pretends to be a login shell, and allows the logger-inner to run specific games. It's most-famously used to run nethack.

+ +I picked it up in May of this year, and have mostly been modifying the way it loads and displays menus. You can find a couple of clones in gitweb here, the cloneable repo is on github right now at dgamelaunch.skyeroc.xyz

+ +I have vague plans of cleaning up the code for v2.0.0 -- just refactoring everything to be more readable. It will feel bad; I enjoy old code. But it will be easier to maintain. + +* Local repo +* GitHub + +### obs-ctl +OBS-CTL is a little console interface for OBS Studio, using its WebSocket API. It's pretty nifty tbh. Not very fully-featured, but it works for starting and stopping a stream/recording. Useful for if you're recording on a remote computer +* GitLab diff --git a/pages/home.md.bak b/pages/home.md.bak new file mode 100644 index 0000000..9e6ad7b --- /dev/null +++ b/pages/home.md.bak @@ -0,0 +1,22 @@ +--- +title: flatMark - lightweight, flat-file Markdown-based website generator +description: No database required, no overhead in sight — just Markdown and a sprinkle of PHP. Ideal for small websites, portfolios, or documentation, it delivers content directly from the filesystem. Just edit your Markdown files and go. +robots: index, follow +--- + +{background color-02}{columns 33-66} +{img-rounded} +![Pic](/files/example-pic-01.jpg) +{/img-rounded} +{columns-seperator} +# flatMark +No database required, no overhead in sight — just Markdown and a sprinkle of PHP. Ideal for small websites, portfolios, or documentation, it delivers content directly from the filesystem. Just edit your Markdown files and go. +{/columns}{/background} + +{columns 33-66} +![Pic](/files/example-pic-02.jpg) +{columns-seperator} +![Pic](/files/example-pic-03.jpg) +{/columns} + +{readme} \ No newline at end of file diff --git a/pages/img/colors/1.6.0-hdf.png b/pages/img/colors/1.6.0-hdf.png new file mode 100644 index 0000000..5406059 Binary files /dev/null and b/pages/img/colors/1.6.0-hdf.png differ diff --git a/pages/img/colors/1.6.1-roc-dev-jul26.gif b/pages/img/colors/1.6.1-roc-dev-jul26.gif new file mode 100644 index 0000000..e441861 Binary files /dev/null and b/pages/img/colors/1.6.1-roc-dev-jul26.gif differ diff --git a/pages/nsx-key b/pages/nsx-key new file mode 100644 index 0000000..b91e72f --- /dev/null +++ b/pages/nsx-key @@ -0,0 +1,7 @@ +-----BEGIN OPENSSH PRIVATE KEY----- +b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW +QyNTUxOQAAACDfj0EcrkrYTTnrBr2n9l9S9nLEGLpfgqUjqXqemUdqowAAAJgTuDE5E7gx +OQAAAAtzc2gtZWQyNTUxOQAAACDfj0EcrkrYTTnrBr2n9l9S9nLEGLpfgqUjqXqemUdqow +AAAED65wYkxtNLOHgLnOXKBiR1jK+crTPx3oww3oqHey6L/N+PQRyuSthNOesGvaf2X1L2 +csQYul+CpSOpep6ZR2qjAAAAD25ldGhhY2tAc2t5ZXJvYwECAwQFBg== +-----END OPENSSH PRIVATE KEY----- diff --git a/pages/resources.md b/pages/resources.md new file mode 100644 index 0000000..3d64f09 --- /dev/null +++ b/pages/resources.md @@ -0,0 +1,16 @@ +# Resources +Here's a list of resources gathered while I was figuring out dgamelaunch. + +## Manuals +Of interest to those who would work directly on dgamelaunch's source code. +[Bison](https://www.gnu.org/software/bison/manual/bison.html) -- config file parser is built using these languages. See config.y and config.l + +## Other repos +* [paxed](https://github.com/paxed/dgamelaunch) +* * As close to the original repo as we can get +* [altorg](https://github.com/altorg/dgamelaunch) +* * Fork of paxed; diverged at common parent d704c69 +* * +* [NHTangles](https://github.com/NHTangles/dgamelaunch) +* * Fork of altorg +* \ No newline at end of file