Dietpi-Software | Hugo: A static-site generator for building websites

[mtekman]

This is a nice small static server for easily building blogs in markdown.

Best of all, it supports multiple markup languages like org-mode and plain text, and others I can't seem to name.

It is highly themeable: https://themes.gohugo.io/

I've created a systemd deamon for it and the first post on the website explains how to create more posts.

More config options: https://gohugo.io/getting-started/quick-start/

[mtekman]

@MichaIng
Unrelated: I've got nice caddy setup running on DietPi as well as on my proxy server. Should I do PR for caddy too? I remember we talked about this once

[Joulinar]

Should I do PR for caddy too?

Keep in mind, it is not about installation of Caddy software only. It would need to be integrated into with all apps which requires a web server 😉

[mtekman]

Keep in mind, it is not about installation of Caddy software only. It would need to be integrated into with all apps which requires a web server wink

I was of that opinion too a few weeks ago, but now I'm happy to run my usual web servers in the background (fileserver, jellyfin, synapse, etc.) and use Caddy to collect/proxy to them. I haven't seen much overhead either with this setup.

Edit: Ah, if you mean I'll have to do some custom config that captures all the custom stuff you guys did with Nginx, then I'm not sure how hard that will actually be.

My current Caddyfile looks like:

## Main Domain
:80 {
        # Set this path to your site's directory.
        root * /usr/share/caddy

        # Enable the static file server.
        file_server

        redir /filebrowser /filebrowser/
        handle /filebrowser/* {
            ## Here we tell filebrowser what it's baseurl should be:
            ##  sudo -u filebrowser /opt/filebrowser/filebrowser config set \
            ##   -d /mnt/dietpi_userdata/filebrowser/filebrowser.db \
            ##   -p 11223 -b "/filebrowser"
            ## (the forward slash in the baseurl is very important.)
            reverse_proxy localhost:11223
        }

        redir /jellyfin /jellyfin/
        handle /jellyfin/* {
            ## Make sure to change jellyfin settings so that the baseURL is "jellyfin"
            reverse_proxy localhost:1234
        }

        redir /blog /blog/
        handle /blog/* {
            # Hugo needs to let the websockets through
            @websockets {
                header_regexp Connection Upgrade
                header        Upgrade websocket
            }
            # Make sure to change hugo server's -b argument to my.example.com/blog
            # and also set appendPort=false
            reverse_proxy @websockets localhost:8131
            reverse_proxy localhost:8131
        }

        ## This part is currently not working, but it might with the right "rewrite" clause.
        ##redir /synapse /synapse/
        ##handle /synapse/* {
        ##    reverse_proxy localhost:58008
        ##}
}

## Subdomains:
synapse.mywebsite.com:80 {
   reverse_proxy http://localhost:58008
}

I can't foresee doing the others being too much work, though admittedly it'd be pretty hard to test that it's 100% working for everything. Hmm... maybe I have underthought this :-)

[mtekman]

@MichaIng Other than Caddy, which I will implement in another PR elsewhere. Is there anything in this PR preventing it from being merged?

[MichaIng]

Suggested change

	G_AGP hugo
	G_AGP hugo
	[[ -f '/mnt/dietpi_userdata/hugo' ]] && G_EXEC rm -R /mnt/dietpi_userdata/hugo

[MichaIng]

Does it really log to /var/log/hugo, or can it be configured to log to STDOUT instead?

[MichaIng]

People will know, but of course any text editor will so:

Suggested change

	You can then modify the file with a markdown editor, and it will
	You can then modify the file with a text or markdown editor, and it will

[MichaIng]

Is there anything in this PR preventing it from being merged?

I just did not find the time to look into it/think about it, sorry for the delay. One thing I am not sure about is that currently a website with a hardcoded name and hardcoded initial content is created, and the service serves this one explicitly. I guess usually users would want to create an own site from scratch, with an individual name, in which case the one we created becomes obsolete and the service won't work (as intended). I am not sure whether there is a way to have the service serving the first/only page dynamically. At least we could introduce a variable via /etc/default/hugo environment file or so, which could then include a variable for the port as well. And maybe we should add an interactive prompt to input the name of the site, and have this added automatically to /etc/default/hugo. Or is this name (directory name) never seen anywhere else, i.e. just a formality?