Transact all the THINGS - sorting out my personal infra
an invention by RBrownSUSE
Updated almost 5 years ago. No love.

I currently have a lot of personal infrastructure that is in need of some tender loving care and transactionalisation

https://rootco.de is running on a Leap 42.3 Hetzner box. I'd like to replace this with something transactional (either Kubic, Leap 15 or Tumbleweed transactional server)

I conducted experiments with various cloud/VPS providers over a weekend recently

  • https://twitter.com/sysrich/status/1010926954432823298
  • https://twitter.com/sysrich/status/1010521143537750016
  • https://twitter.com/sysrich/status/1010504846389235714

This found Linode, Vultr, and Packet.net all perfectly suited for hosting transactional openSUSE, so I'm likely to move my blog, salt master, and other public facing services there.

My home "server" is currently a Leap 42.3 LXC container running on my Turris Omnia router https://omnia.turris.cz/en/

However as the routers kernel is so old, it is not viable to upgrade the container to Leap 15.0

Therefore I'm now the proud owner of a fanless i5 Zotac mini-PC which will dramatically upgrade my home server options

https://www.zotac.com/at/product/mini_pcs/ci547-nano

Setting this up with Kubic, Leap 15 or Tumbleweed, transactional of course, with services like my ssh jump host, backup, NextCloud, mail, etc should keep me busy for the rest of hackweek

Looking for hackers with the skills:

transactionalupdates

This project is part of:

Hack Week 19 Hack Week 17

Activity

  • over 6 years ago: RBrownSUSE added keyword "transactionalupdates" to this project.
  • over 6 years ago: RBrownSUSE started this project.
  • over 6 years ago: RBrownSUSE originated this project.


    • Comments

    • RBrownSUSE
      almost 5 years ago by RBrownSUSE | Reply

      After a few hackweeks this is finally done. It went through various minor steps over the last years with a major rework as part of Hackweek 19

      https://github.com/sysrich/salt-states shows the basic layout, but to give a tl;dr here for Hackweek 19

      • luke.rootco.de was a Leap 15.1 server running at Hetzner, hosting https://rootco.de , my ZNC bouncer, and my salt-master
      • k2so.dyn.rootco.de was a Leap 15.1 LXC container running on a armv7 turris omnia, hosting my backup service and acting as an SSH jumphost
      • r2d2.home.rootco.de is a MicroOS NUC hosting only a containerised nextcloud accessible via cloud.dyn.rootco.de

      As part of this hackweek I accomplished the following:

      Decommissioned k2so.dyn.rootco.de, replacing it with the following container running on r2d2.home.rootco.de:

      registry.opensuse.org/home/rbrownsuse/containers/containers/backer-srv https://build.opensuse.org/package/show/home:RBrownSUSE:containers/backer-srv-image

      This is now acting as both my backup target for all of my other services, and also an SSH jumphost for my personal infra, running on port 80 so I can get to it even from restricted wireless networks. With all this custom magic, it's not suitable for reuse as a generic container in Tumbleweed sadly, but it's WAY easier for me to manage than before.

      Decommissioned luke.rootco.de and replaced it with d0.rootco.de, a freshly installed MicroOS host running on Hetzner Cloud

      Salt-master was replaced with a custom salt-master container registry.opensuse.org/home/rbrownsuse/containers/containers/salt-master https://build.opensuse.org/package/show/home:RBrownSUSE:containers/salt-master-image

      This container automatically git pulls from https://github.com/sysrich/salt-states and uses the existing keys from luke.rootco.de to continue working as before the migration. However this magic unfortunately means the salt-master container is not easily reusable for others, but again, way easier for me to manage than the old salt-master.

      ZNC bouncer was replaced with a rather generic znc container registry.opensuse.org/home/rbrownsuse/containers/containers/znc https://build.opensuse.org/package/show/home:RBrownSUSE:containers/znc-image

      With a bit of polish this ZNC image can easily be submitable for all of Tumbleweed

      The rootco.de website was a bit more of a challenge, because it's a jekyll generated website, with letsencrypt

      As openSUSE's jekyll packaging is a mess, and as it's not internet facing, I opted to use the upstream jekyll container, using a systemd service to generate the site automatically on a timer:

      https://github.com/sysrich/salt-states/blob/master/rootco/containerhost/d0/rootco-jekyll.service

      The output of this jekyll run is then consumed by the recently created opensuse-nginx container

      https://github.com/sysrich/salt-states/blob/master/rootco/containerhost/d0/rootco-web.service

      As the upstream container is a mess and because it's internet/security related, I built a custom certbot container, including the nginx plugins for ease of use

      registry.opensuse.org/home/rbrownsuse/containers/containers/certbot https://build.opensuse.org/package/show/home:RBrownSUSE:containers/certbot-image

      With a bit of tweaking this might be suitable for including in tumbleweed, though will always behave very differently from the upstream equivalent because I strongly disagree with the approach upstream take with containerised certbot.

      This was used to generate the certificates with a run of:

      podman run --rm -v /var/opt/rootco-web/data/etc:/etc/nginx -v /var/opt/rootco-web/data/htdocs:/srv/www/htdocs -v /var/opt/rootco-web/letsencrypt:/etc/letsencrypt -p 80:80 -p 443:443 -it registry.opensuse.org/home/rbrownsuse/containers/containers/certbot:latest certbot --standalone --installer nginx

      and will now be automatically renewed on a periodic basis using the container also https://github.com/sysrich/salt-states/blob/master/rootco/containerhost/d0/rootco-certbot.service

      And so, not only is everything in my life free from regular releases, but everything I need is containerised too :)

    • RBrownSUSE
      almost 5 years ago by RBrownSUSE | Reply

      Posted Blog Post about this project: Regular Releases Are Wrong

    Similar Projects

    Ansible for add-on management by lmanfredi

    Description

    Machines can contains various combinations of add-ons and are often modified during the time.

    The list of repos can change so I would like to create an automation able to reset the status to a given state, based on metadata available for these machines

    Goals

    Create an Ansible automation able to take care of add-on (repo list) configuration using metadata as reference

    Resources