MartinsDen

I ran through  3-4 tanks of CO2 in 2021 because of a slow leak in my keezer.  While that is resolved, it occured to me that the CO2 doesn't need to be on all the time. Not only does it waste money if there is a leak, it is inconvenient and there is some environmental impact.  So for the past 6 months I've defaulted to shutting off when not in use. Since we have friends over every Wednesday (for FreeWill Wednesday) I have an alarm on my phone each Wed. reminding me to shut off the CO2.

But hey, I live in a smart home and I can solve this problem. 

I started thinking about this a month ago and went looking for parts.  First I found this zigbeen module that controls a relay.  Then I found this water valve that is controlled by a 24v solenoid.  Since the valve has John Guest push-in fittings, I knew it would fit right into my system.

  > 

The idea is pretty simple.  The zigbee module is attached to power and the relay switches the 24v on to open the normally closed valve.  The valve is inserted in the CO2 path after main the regulator but before the kegs (which in my keezer have their own individual regulators.  Fortunately, this zigbee module can convert 24v down to 5v to run the zigbee part, so I only needed on power source. 

Once put together, I can join the zigbee module to my Home Assistant install (or Smartthing, Alexa, etc.) and build some automations that control the valve and CO2

Next in my docker journey was to bring up SWAG - Secure Web App Gateway.  It's a container from Linuxserver.io that combines nginz reverse proxy setup with LetsEncrypt acme client to provide a secure front-end to self-hosted web apps.  When SWAG is built in a docker-compose with web apps, it provides a secure (contained within a docker network) backend as well as HTTPS to all client connections.

SWAG  provides a bunch of predefined app-specific proxy config files.  Of course, there isn't one for tiki so I made one by modifying an existing sample for a subdomain.confg.  Code for that is below.

When I first fired it up, I was directed to the default SWAG landing page.  Some research reminded me that SWAG talks to the app via the internal network/port, not the external host & ports.  I had mistakenly set the upstream port to the external port I had defined for the tiki container.  Changing this to use port 80 against the container name fixed this.

I was also concerned that I needed to configure tiki with a cert in ordr to get a clean SSL experince for the client.  But nginx handles this nicely as the proxy server.  Very nice.

tiki.subdomain.conf:

# REMOVE THIS LINE BEFORE SUBMITTING: The structure of the file (all of the existing lines) should be kept as close as possible to this template.

# REMOVE THIS LINE BEFORE SUBMITTING: Look through this file for <tags> and replace them. Review other sample files to see how things are done.

# make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url

I'm moving  all my self-hosted services to docker - specifically, docker compose.  I'm using this config for prometheus:

prometheus:

    image: prom/prometheus:latest

    # privileged: true

    volumes:

      -  /mnt/samba/Docs/docker/config/prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml

      -  /mnt/samba/Docs/docker/config/prometheus/data:/prometheus

      # -  /data/prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml

      # -  /data/prometheus/data:/prometheus

      # -  ./alertmanger/alert.rules:/alert.rules

    command:

      - '--config.file=/etc/prometheus/prometheus.yml'

    ports:

      - '9090:9090'

I ws getting this  error  on startup:
ERROR: for prometheus Cannot start service prometheus: OCI runtime create failed: container_linux.go:367: starting container process caused: chdir to cwd ("/prometheus") set in config.json failed: permission denied: unknown

After much testing, I added the user:"1000" command to force the container to run as my account.  I'll admit I  have a lot to learn about docker and permissions.

Here is the final yml:

prometheus:

    image: prom/prometheus:latest

    user: "1000"

    # privileged: true

    volumes:

      -  /mnt/samba/Docs/docker/config/prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml

      -  /mnt/samba/Docs/docker/config/prometheus/data:/prometheus

      # -  /data/prometheus/config/prometheus.yml:/etc/prometheus/prometheus.yml

      # -  /data/prometheus/data:/prometheus

      # -  ./alertmanger/alert.rules:/alert.rules

    command:

      - '--config.file=/etc/prometheus/prometheus.yml'

    ports:

      - '9090:9090'

Here are the list of services or feature I want in DC. 
"x" are done.

•  x volumes for all gpm/samba shares  
•  x single mysql install
•  x .env file
• SWAG /let's encrypt
•  x Tiki
•  x greyhole
• Nextcloud
• plex
• subsonic
• booksonic
• ghost
• TinyPin
• Cockpit
• portainer

I'm real late to the docker game, but listenting to the Self Hosted podcast recently has helped me realize the simplicity of this configuration.  Well, simple once  you understand it.  I spent the day today moving my native webservices to docker.  Here's how it went

Things I needed to move and make work

• TikiWiki - been running this CMS for 18 years now.  Iit has to go with me
• mariadb - it currently holds greyhole and tiki dtabases
• greyhole connection to mariadb
• nextcloud - I don't really need this, but I have it running in a standalong container and I want it in DC

It took me all day to get a working config just for mariadb.  All the issues were authentication related once the db spun up in a container.  Here's what I think I know:

• apps in a container connect using "%" as the host
• apps outside a container use localhost

Greyhole was a special case.  Since mariadb is in a container, localhost no longer works as a db_host.  I changed it to 127.0.0.1 and it worked fine.  One other issue - retstarting the docker-compose disconnects the session and greyhole must be restarted. I may consider a separate mariadb instance for this

For mariiadb migration, I was hoping if i simply mounted the physical mariadb folder into th container, that the container version would just use it, but that didn't work.  I h ad to dump and import the existing data and recreate users.