sternenseemann / spacecookie Goto Github PK

Add systemd support for the server executable (socket activation and notify service type).

Work in Progress, see the systemd-support branch

Current Progress:

• Write rudimentary Systemd-Support using a patched version of the systemd haskell package
• Further testing
• Either rewrite the integration or patch the systemd haskell package, so spacecookie does not have to depend on network
  • Wait for feedback on the PR
• Update documentation and suggested systemd .service files.
• Test on non-systemd and non-linux (see #9) systems
• Get a NixOS service into nixpkgs

This is the new feature I am planning for 0.2.1.0.

We have a map like this:

M.Map FilePath GopherFileType

The configuration option could look like this, allowing to override the mapping:

{
  "file-types": {
    "apng": "I"
  }
}

Also the default fallback should be configurable (currently File).

Would be mostly just to have it or as a gimmick.

Probably best option is to add manpages:

• spacecookie(1) Usage, Configuration, License, …
• spacecookie.json(5)
• spacecookie-gophermap(5)
• Redo README.md

To reproduce curl -vv -s -f an gopher url for spacecookie a few times, eventually you will have curl failing with 56 similar to this:

…
The file type characters are defined in [RFC1436](https://tools.ietf.org/html/rfc1436#page-10).
* Recv failure: Connection reset by peer
* Closing connection 0
Detailed documentation on the gophermap format [can be found here](./docs/gophermap-pygo⏎         

BSD support would be nice, socket depends on GNU/Linux Socket API though.

We always use the binary file response which we should probably resolve to call ourselves a RFC1436 implementor although binary file responses work well enough.

Currently all exceptions except IOExceptions are kind of ignored. This should be fixed and handled properly™. Probably removing MonadError altogether would do the trick.

Most notably it is not possible to handle SocketExceptions with MonadError.

Optional CGI support could be interesting. Could starting point could be looking at how geomyidae (gopher://bitreich.org/1/scm/geomyidae/) passes info to CGI scripts. Also should check how/whether other server implementations do CGI.

On my server I have two different gopherholes I want to expose to the world. Currently they run on different ports. I'd like to be able to configure spacecookie to act as a reverse proxy to sort incoming gopher requests to a configured gopherhole. For example, a simple configuration could be detecting the base directory of "forum/" in the selector and forwarding selector to a configured gopherhole and sending its response back.

I suppose all I really want is the ability to have spacecookie map certain base directories to certain gopherholes, and everything can be communicated via a consistent port.

Would you like me to work on a PR for this concept? Would you like to implement?

I'm posting using my phone and sorry if my English is poor.

Probably have to check the source since the documentation is ambiguous. This should best be addressed in 0.3.0.0 to avoid consecutive breaking changes to gophermaps.

Seems like we need to introduce an dependency on async for #42, so converting the other threading stuff to async could be interesting.

• Test build of example program, sanity check
• integration tests
• Unit tests for library
  • gophermaps
  • gophermap parse failures
  • path sanitization
  • file type detection
  • ...
• Test config parsing for server

• Allow it to be disabled when using the library
• Allow Configuration of log format (disable timestamp, more?)
• Make less verbose, i. e. only one log line per successful connection.
• Option to hide IP addresses

This behavior can already be achieved when using a systemd based setup, but we should probably support it also in a systemd-less scenario. Binding to a specified address could be how to solve it, but link local is the most important in case you want to proxy spacecookie somehow or point a TOR hidden service to it without leaking the gopher space on the regular address.

       selector
              The  selector  is  the  name  of  the file on the server.  If it
              begins with a slash, it is an absolute path;  otherwise,  it  is
              interpreted relative to the directory that the gophermap file is
              in.  If no selector is specified, the description is  also  used
              as the selector.

spacecookie currently interprets relative selectors wrong.

• Tutorial
• Detailed function documentation

Recently it seems to be a trend to TLS-enable gopher servers and even some gopher clients seem to support TLS. I don't think it's a good idea to support it in spacecookie, since it is a non-standard feature, but it seems like a good idea to figure out, how TLS typically is set up for gopher and provide an stunnel (?) based example configuration for TLS with spacecookie.

The best way to set up an encrypted spacecookie remains to use a hidden service (but we should close #13 for that).

A lot of the times a error occurs, the default exception is thrown.

• Premature disconnect
• File read errors (config file)

The bad thing currently is that the configuration has to match in two places: a) the spacecookie.socket file and b) the spacecookie.json config. This can be improved by:

• Learning more about the socket from systemd if possible without a direct dependency?
• Logging a warning if something is strange about the socket, i. e. addresses not matching.

Useful for Tor Onion Services.

The current log system is alright, but doesn't allow the user to log anything. I'm also kind of unhappy that we always have a TimeFastLogger although it may not be used (glcTimed = False).

I think a good way forward is to rework logging again completely and let the user set an IO action for logging. Additionally I think the LogMessage sum type needs to be simplified somehow, without sacrificing the ability to hide private data.

This should be done before 0.3.0.0 since I don't want to break the API twice in a row.

JSON is not a configuration file format. I'll keep supporting it in the future, since it is convenient for the NixOS module.

As we keep JSON, we should maybe look into something aeson based, maybe YAML? Otherwies toml or ini seems fine.

Would break library interface unfortunately, but having something like

data GopherRequest
  = GopherRequest
  { grSelector :: ByteString
  , grAddress :: (Word16, Word16, Word16, Word16, Word16, Word16, Word16, Word16)  -- ipv6 address
  }

Could be very useful for applications which want to kind of differentiate different users.

• Enable RTS-opts in compilation
• Provide optimized systemd service file using RTS opts

Really a shame that there is no self hosted page for spacecookie yet. Shouldn't be too hard to set up with existing NixOS infrastructure and my tries towards generating project pages.

Feature request.

It would be great if I could arbitrarily launch spacecookie when I build random gopherholes as a test and I just want to see what the product looks like after I build it, without having to create a config file to test locally.

I want to, for testing purposes, be able to use spacecookie without specifying a config file.

I keep forgetting to do this.

Also: deal with empty lines (related)

I was poking through your code and noticed the filetypeMap.

Would you like a more thorough utility for such? I have a half-baked, but functional utility filesig which provides a mapping for a ton of files based off of file signatures (and I think even file extensions? although hit's been a while). I can update this library if you are interested in it.

• Description of Search transaction
• Module would just be a small parser which splits the path selector, the search string and (optionally) parses the latter into the search expression (supporting and, or and not).

Sometimes I want to have multiple gophermaps per directory and I want to use the .gophermap parsing behavior. I noticed I have to use "manually" written gophermaps if I want to have multiple gophermaps in one directory. The solution is to adhere to the RFC (I forget the number) convention on URIs in gopherspace, where /1/ in the beginning/as the prefix of the selector, for instance, denotes that the selector targets a menu and should be interpreted as such.

My specific use case: In burrow I want to provide an index per phlog tag in separate menus, and I don't like that I would have to create a directory and a .gophermap for each tag index in order to take advantage of the .gophermap parsing behavior.

I believe network should now offer everything we need and socket has become unmaintained, dropping out of Stackage Nightly recently.