Two new posts

Add new software pages
Add Makefile to automate deployment

Config.ron

@@ -10,6 +10,6 @@
     entries: 3,
     feed: Some(Both),
     license: Some(CcBySa),
-    footer_links: [],
+    footer_links: [(url: "finger://hitchhiker-linux.org/nathan", display: "Finger")],
     show_email: true,
 )

Makefile

@@ -0,0 +1,13 @@
+all: build capsule.tar upload
+
+build:
+	zond build
+
+capsule.tar:
+	cd public && tar cvf ../capsule.tar *
+
+upload: capsule.tar
+	scp capsule.tar gimli:/home/nathan/capsule.tar
+	ssh gimli tar xvf capsule.tar -C /srv/gemini
+
+.PHONY: all build upload

content/gemlog/eva_0.4_released.gmi

@@ -0,0 +1,41 @@
+(
+    title: "Eva 0.4 released",
+    summary: Some("Eva 0.4.0 with Spartan support and various qol improvements"),
+    published: Some((
+        year: 2022,
+        month: 6,
+        day: 7,
+        hour: 3,
+        minute: 30,
+        second: 30,
+    )),
+    tags: ["eva", "rust", "software"],
+)
+---
+## Notes
+* Gemini - Use colored icons to differentiate link types
+* Gemini - Handle sensitive input requests
+* Gopher - handle http[s] links
+* Spartan - initial support (sans upload support)
+* Spartan - support Spartan uploads
+* Rewrite of gemtext parser in GemView
+* Major refactor of actions handing, removing 293 total lines of code
+=> https://codeberg.org/jeang3nie/eva/releases/tag/v0.4.0 Eva 0.4.0 release on Codeberg
+
+## Summary
+While there's still two glaring omissions (client certs and history) from Eva's feature set I consider Eva to be a solid application for browsing around the Smolweb at this point. I've put a lot of work into refining the code that doesn't factor into user facing features, but should not only make for a more stable piece of software but one that is now much easier to maintain going forward.
+
+The actions refactor mentioned above was an interesting case. The original code had a big struct where all of it's members were the same data type. Simple static arrays aren't often used in Rust, and generally I think a lot of people tend to think of arrays as old fashioned these days, but by switching to a static array strings (the names of every gtk::SimpleAction in Eva) it's possible to just loop over all of them to create the action, associate a keybinding to it, connect a closure and add it to the main window. So yeah, sometimes a simpler data structure is a big win.
+
+Although, had this been written in Zig, one could actually loop over struct fields...
+
+## Plans going forward
+Along with implementing the features I mentioned above, I would like to refine the way file uploads are brought into the program for Spartan. Currently when you click on a Spartan prompt line it just pops up a file chooser dialog. What I intend to have happen is to have a dialog with a text edit box, with a button on it which will open the file chooser instead, and possibly the option of using an external editor.
+
+Somewhat longer term, I want to start incorporating completions into the address bar. The completions should include bookmarks, any configured search engines, and eventually url's from the browser history once that lands. I'd like to reach a point where Eva is as satisfying of a tool for power users as it is a program that one can just pick up and use like a "regular" web browser.
+
+Still on the table is a possible switch to sqlite for handling bookmarks. I haven't decided. If I do go that route, then the current code which populates the bookmark creation/editor dialog will have to run in a background thread so as to not block the main thread on slow disks.
+
+I am still undecided about adding Titan support. It seems to me that supporting Gemini, Gopher, Finger, Spartan, File and Data url's is already quite a lot. And, I'm not convinced that Titan is going to have a very large user base.
+
+Another possible avenue to explore is gradient backgrounds. I put together a pretty nice gradient editor for Zterm a while back, and although the code is in Zig instead of Rust and is Gtk3, not Gtk4, the concepts would transfer pretty well to Eva. I have always wanted Eva to be the best looking program possible, and I think the added code complexity would add a lot of value. Images are possible as well, but I've found over a few years of using E-readers rather than physical books that every time I try to use an image background it gets distracting after a while. Gradients would be a way to give a nice dynamic feeling presentation while keeping the focus on the text, which is of course why we use Gemini in the first place.

content/gemlog/gemipedia_and_kennedy.gmi

@@ -0,0 +1,30 @@
+(
+    title: "Gemipedia and Kennedy",
+    summary: Some("Adding Gemipedia and Kennedy to default search engines in Eva"),
+    published: Some((
+        year: 2022,
+        month: 6,
+        day: 7,
+        hour: 19,
+        minute: 1,
+        second: 10,
+    )),
+    tags: ["search", "eva"],
+)
+---
+I love discovering a new site with some cool projects. Over on gemi.dev there's a really nice Wikipedia frontend, a weather service and a nice general search engine called Kennedy (among other things).
+=> gemini://gemi.dev/cgi-bin/chilly.cgi Chilly Weather service
+=> gemini://gemi.dev/cgi-bin/wp.cgi Gemipedia
+=> gemini://kennedy.gemi.dev/ Kennedy search engine
+
+I've added both Gemipedia and Kennedy to the default search engines in Eva. That means that in the next version of Eva you will be able to search Gemipedia by typing "gmp <your search query>" or Kennedy with "ken <your query>" into the address bar.
+
+As an aside, the author of those tools had this to say about implementing math formulas in Gemipedia:
+> Given all this complexity, I didn't even try to represent math formulas in gemtext.  Instead. to solve this in Gempedia, I detect math formulas and create link lines out to PNG images of the rendered math formula (And how are those math formula's written by Wikipedia authors? Funny enough, using LaTex, a modern day version of TeX!). I don't use SVG because I found no Gemini client that supported SVG rendering, and the PNGs look crisp enough.
+=> gemini://gemi.dev/gemlog/2022-06-06-unicode-sub-sup.gmi
+
+While I agree that it would be unwise to use an image format that isn't going to be widely supported, Eva has supported svg since the day it began supporting images of any kind. I don't really understand why it would be overlooked when writing a client. I love svg. It's one of the only image formats that can be represented as plain text. If you're a masochist you can even wrrite svg by hand.
+
+## And another thing..
+While exploring the site I read a post about hashtags and jabanana's hashtag crawler for Geminispace. I love this. I was thinking I might need to update my Zond capsule generator to put a page's tags into #hashtag format, but then discovered that the implementation bby jbanana already looks for a /tags/ directory, which Zond already has, and my capsule is in fact being indexed. Nice. Unfortunately the index is so large that it's causing eva to lock up. I tried with Lagrange and the page opens, so I guess I have some more optimizing to do.
+=> gemini://freeshell.de/hashtags/ The hashtag index

content/index.gmi

@@ -15,3 +15,4 @@
 Welcome to my capsule. I'm a recovering jack of all trades trying to focus more on software development and music while attempting to stop collecting more hobbies.
 {% posts %}
 => software Some software I develop
+

content/software/agis.gmi

@@ -0,0 +1,69 @@
+(
+    title: "Agis",
+    summary: Some("A multithreaded Spartan protocol server with virtua hosting and CGI"),
+    published: Some((
+        year: 2022,
+        month: 6,
+        day: 6,
+        hour: 19,
+        minute: 05,
+        second: 5,
+    )),
+    tags: ["software", "spartan", "rust"],
+)
+---
+=> https://codeberg.org/jeang3nie/agis Repo on Codeberg
+## Description
+Agis is be a Spartan [1] protocol server written in Rust. It is currently under active development and has reached a state of minimum viability.
+=> https://portal.mozz.us/spartan/spartan.mozz.us/ [1] Spartan protocol
+
+## Building
+Agis is written in Rust and requires the Cargo build tool.
+```
+# Build a release binary
+cargo build --release
+```
+## Features
+* Multithreaded worker pool
+* Static files
+* Virtual hosts (name based)
+* CGI
+* Redirects
+* Aliases
+* indexes
+
+## Configuration
+The configuration file is in Ron [2] format, which should be very simple to grasp if you are used to any programming languages with braces (such as C). There is an example config file with plenty of comments in `conf/config.ron`. This file can be copied to `/etc/agis/config.ron` and edited to match your actual desired configuration.
+=> https://github.com/ron-rs/ron Ron file format
+
+### Fields (Global)
+* address - The ip address to bind to. Change this to your server's public ip address.
+* port - The port to listen on. Spartan specifies port 300, so only change this if you have a specific use case for it.
+* user - The user which this server will run as. Agis must be started as root in order to bind to one of the lower ports, but will drop priviledges as soon as it is initialized.
+* group - The group which the server will run as.
+* threads - The number of threads to be started to handle requests. It is unlikely that you will have enough traffic to warrant increasing this.
+* access_log - If this is set to `None`, access will be logged to stdout. If it is set to `Some(path)` access will be logged to that file.
+* error_log - See access_log for specifics. Logs errors either to stderr or file.
+* vhosts - One or more name based virtual hosts.
+
+### Fields (per Vhost)
+Each vhost is looked up by a key, which is the domain name it will serve.
+* name - The domain name for which to serve requests.
+* root - The path to the root directory of this server's files.
+* directories - Path specific directives.
+
+### Directives
+Each directive is looked up via a key, which is the path which it applies to.
+* Allow - whether or not to allow access to this path. If not set, all files in the document tree under the server root are allowed. If set to false, all files under this path are disallowed.
+* Alias - Serves files requested for this path from a different path. This is handled by the server transparently to the client.
+* Redirect - Any request for this specific path will be sent a redirect to the new location, to be handled by the client.
+* Cgi - Any requests under this directory will be passed to the cgi program which is the direct child of the directory. If the Cgi directive is given the path '/cgi-bin/', and a client requests '/cgi-bin/foo/bar/baz.gmi?fizzbuzz=true' then the program located at '/server-root/cgi-bin/foo' will be run and given the rest of the path and query as environment variables. This implementation is a subset of CGI 1.1 with http specific environment vars removed.
+
+The default configuration runs the server as user 'agis' and group 'agis'. You will need to create that user and group on your system or Agis will not run.
+```
+useradd -r -s /sbin/nologin agis
+```
+## Running
+If you are running Linux with Systemd init, there is a unit file included in the conf/ subdirectory. It can be copied into /etc/systemd/system and then started and stopped like any other service.
+
+If you are on a Linux system that does not use systemd, or bsd, it should be straitforward to write your own init script. The default location for the configuration file is `/etc/agis/config.ron` but can be overridden on the command line with the `-c` or `--config` flag. This is currently the only command line option which is supported, making startup quite straightforward.

content/software/index.gmi

@@ -16,6 +16,8 @@
 => eva.gmi The Eva browser for the smol internet
 => gemview.gmi Gemview - a browser widget in gtk4 for the smol internet
 => zond.gmi Zond - a static gemini capsule generator
+=> toe.gmi Toe - a reimagined fingerd
+=> agis.gmi Agis - a multithreaded Spartan server with virtual hosting and CGI
 ### Non Gemini projects I develop
 => gfret.gmi Gfret - a tool for luthiers
 => zterm.gmi Zterm - a terminal emulator with tabs and panes

content/software/toe.gmi

@@ -0,0 +1,78 @@
+(
+    title: "Toe",
+    summary: Some("A reimagined Fingerd"),
+    published: Some((
+        year: 2022,
+        month: 6,
+        day: 6,
+        hour: 18,
+        minute: 54,
+        second: 5,
+    )),
+    tags: ["software", "finger", "rust"],
+)
+---
+=> https://codeberg.org/jeang3nie/toe Repo on Codeberg
+## Description
+Toe is a Finger[1] protocol server written in Rust which aims to be simple and (hopefully) more secure than historical implementations of the protocol. Toe shares less information with it's default settings, runs in a chroot and drops root priviledges as soon as possible during it's startup procedure. The increased security comes at the expense of a moderately more involved setup.
+=> https://datatracker.ietf.org/doc/html/rfc742 [1] - Finger spec
+
+## Building
+Toe requires no system dependencies besides libc and is built using Cargo.
+```
+git clone https://codeberg.org/jeang3nie/toe
+cd toe
+cargo build --release
+```
+## Setting Up Users
+In it's simplest setup one would set the server root to /home and the chroot option to false. Any user wishing to serve their .plan file would also have to have the permissions of their home directory set to world readable, as unlike fingerd Toe will not run as the root user.
+
+Toe wants to be run in a chroot. For increased security it is recommended that you create a dedicated directory for toe to run in, with a directory and .plan file for each user who will be sharing their plan using the server. The .plan file can then be symlinked into the user's home directory for easy editing.
+```
+# Users jack and jill want to share their .plan using toe
+# First, create those directories
+sudo install -dv /srv/toe/{jack,jill}
+# Now create their .plan files
+sudo touch /srv/toe/jack/.plan
+sudo touch /srv/toe/jill/.plan
+# Now we'll change ownership of those files so the users can edit them
+sudo chown -R jack:jack /srv/toe/jack
+sudo chown -R jill:jill /srv/toe/jill
+# Finally, we'll symlink them into the user's home directory so that the user
+# can just edit $HOME/.plan to change their plan
+ln -s /srv/toe/jack/.plan /home/jack
+ln -s /srv/toe/jill/.plan /home/jill
+```
+It is also neccessary to set up a user and group to run the server as. Feel free to use a different user and group here, but make sure that the user and group that you create matches what you put in toe.toml - see Configuration.
+```
+# Most Linux distros
+groupadd -r toe
+useradd -r -g toe toe
+```
+> Note the `-r` flag in the above commands - this creates a `system` user rather
+> than a regular user. The user which the server runs as should not have a login
+> shell, home directory, or own any files.
+## Configuration
+Configuration is in Toml[2] format. Toe wants to find it's config file at /etc/toe.toml. An example `toe.toml` file is included in the data directory of the source distribution. It is recommended in particular that the address field be changed from it's default value of "0.0.0.0", which binds on all interfaces, to whatever the machine's public IP is.
+=> https://toml.io/en/ [2] - Toml
+## System Info
+Traditionally, when no user is requested, fingerd would give out various system information such as uptime, users and processor stats. The internet was a less dangerous place back then than it is now and it is up to the user to decide if serving any of this information is appropriate for your use case. The various types of information which Toe is capable of serving up can be turned on and off via settings in toe.toml.
+
+If Toe is to be run in a chroot, more work must be done to make most of this information available, as it is gathered from the kernel virtual filesystems mounted at /proc and /sys. If desired, then those virtual filesystems can be mounted inside the chroot. Additionally, information about the number of users requires access to`/etc/passwd`. It is possible to either bind mount the actual /etc/passwd file or, preferably, to just crate a dummy version with only the users desired to be counted in the listing, leaving out all system user accounts.
+```
+# Create the directories proc and sys inside of the server root
+sudo install -dv /srv/toe/{proc,sys}
+mount the virtual filesystems
+sudo mount -t proc proc /srv/toe/proc
+sudo mount -t sysfs sysfs /srv/toe/sys
+# Create /srv/toe/etc
+install -dv /srv/toe/etc
+# Naive method - bind mounting /etc/passwd
+touch /srv/toe/etc/passwd
+mount -Bv /etc/passwd /srv/toe/etc/passwd
+# Better - filter users into a dummy file
+grep -v "bin/nologin" /etc/passwd > /srv/toe/etc/passwd
+```
+The virtual kernel systems could be made to be autmatically mounted inside Toe's root directory by placing appropriate lines in /etc/fstab.
+## Running
+Toe is started by invoking toe on the commandline. It must be started by the root user, after which it will drop priviledges and run as the user and group which are configured in `toe.toml`. If logging is desired, any startup script should direct the program's stdout and stderr to the appropriate logs.

public/software/eva.gmi

@@ -83,6 +83,8 @@ cargo xtask dist
 => ../tags/gtk.gmi gtk
 
 => .. Home
+
 All content for this site is released under the CC BY-SA license.
 © 2022 by JeanG3nie
+=> finger://hitchhiker-linux.org/nathan Finger
 => mailto:jeang3nie@hitchhiker-linux.org Contact