Scott

That got a good laugh out of me

I have blade servers, they are smaller than 1u

I would hope you are not putting a professor in a 1u chassis, that sounds kinda mean

I was using the watchtower updater until it got archived, thankfully there is a maintained fork now

https://github.com/nicholas-fedor/watchtower

I still need to figure out a auto update solution for my Argo managed services

For a lot of my remote hosted services managed with compose, I’ve just been hand rolling the compose files and ssh’ing in.

Portainer was outdated 5 years ago, and it sucked at the job it did.

I’ma stick with dockge and argocd

They already have GDID which tracks you everywhere you go on the Internet and is tied to your $M💩 account

I’ve heard a lot of people like the LackRack, that is if you have an IKEA nearby.

https://nenimein.fi/blog/post/lackrack-v3/

I’ve only used it on 80/443 but this issue has been happening on numerous different VMs enough to the point I’ve just stopped using it for new installs.

I’ve been having constant issues for over a year where it’s not able to auto update any of my certs. It has been erroring when I even try to do a manual update, but the second it’s deleted and reset up it’s fine (for the time being).

My work requires the use of a MacBook, and I hate it

I would like to see a thief try and take my server rack down a flight of stairs

🐟🐟🐟

You could see if you could swap to the 8311 WAS-110. It’s not the cheapest but it can entirely mimic a ONT and be the new gateway for your ISP.

https://pon.wiki/

I’ve mostly been working with VueJS 2 projects with the goal to upgrade to 3.

I can’t stand working with any JS/TS projects. I’ve spent days trying to update very simple SPA sites without any success.

Why not just have everything on the hard drive instead? If you did want to write a tool you could use the Plex webhooks, but I haven’t heard of anyone wanting to do this before.

You would likely need to build a NAS with a HBA (Host Bus Adapter). I’m not aware of any low-end NAS systems that support SAS

Incoming wall of text

Here is my install script to set up Ubuntu since it has a bit of extra steps for privileged ports https://gitlab.meme.beer/-/snippets/1

Docker compose example, note that my config has a shared network with containers in another compose called nginx to keep traffic inside docker.

name: "gitlab"
services:
  gitlab:
    image: 'gitlab/gitlab-ce:latest'
    #command: update-permissions
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.example.com'

        pages_external_url 'https://pages.example.com'
        pages_nginx['enable'] = true
        pages_nginx['listen_port'] = 6000
        pages_nginx['listen_https'] = false
        pages_nginx['redirect_http_to_https'] = false

        #puma['per_worker_max_memory_mb'] = 2048 # 2GB

        gitlab_rails['gitlab_email_from'] = 'gitlab@mailer.example.com'
        gitlab_rails['gitlab_email_display_name'] = 'GitLab'
        gitlab_rails['smtp_enable'] = true
        gitlab_rails['smtp_address'] = "smtp.sendgrid.net"
        gitlab_rails['smtp_port'] = 587
        gitlab_rails['smtp_user_name'] = 'apikey'
        gitlab_rails['smtp_password'] = '$SENDGRID_API_KEY_HERE'
        gitlab_rails['smtp_domain'] = "smtp.sendgrid.net"
        gitlab_rails['smtp_authentication'] = "login"
        gitlab_rails['smtp_enable_starttls_auto'] = true
        gitlab_rails['smtp_tls'] = false

        gitlab_rails['gitlab_default_theme'] = 2

        gitlab_rails['gitlab_shell_ssh_port'] = 2224

        gitlab_rails['gitlab_default_projects_features_container_registry'] = true
        gitlab_rails['registry_enabled'] = true
        gitlab_rails['registry_api_url'] = 'https://registry.example.com'
        gitlab_rails['registry_issuer'] = 'gitlab-issuer'
        registry['log_level'] = 'info'
        registry_external_url 'https://registry.example.com'
        registry_nginx['enable'] = true
        registry_nginx['listen_port'] = 5050
        registry_nginx['listen_https'] = false
        registry_nginx['redirect_http_to_https'] = false

        gitlab_shell['log_level'] = 'INFO'
        letsencrypt['enable'] = false
        nginx['error_log_level'] = 'info'
        nginx['listen_https'] = false
        #nginx['proxy_protocol'] = true
        #nginx['trusted_proxies'] = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]

        # Workhorse
        gitlab_workhorse['enable'] = true
        gitlab_workhorse['ha'] = false
        gitlab_workhorse['listen_network'] = "tcp"
        gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
        gitlab_workhorse['log_directory'] = "/var/log/gitlab/gitlab-workhorse"

        # Errors
	# for sentry error logging the GitLab service
        #gitlab_rails['sentry_enabled'] = true
        #gitlab_rails['sentry_dsn'] = ''
        #gitlab_rails['sentry_clientside_dsn'] = ''
        #gitlab_rails['sentry_environment'] = 'production'
        # Add any other gitlab.rb configuration here, each on its own line
    networks:
      - nginx
    ports:
      # gitlab loves https on 443
      #- '80:80'
      #- '443:443'
      - '2224:22'
    volumes:
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab
    shm_size: '256m'
    #deploy:
    #  resources:
    #    limits:
    #      cpus: '6'
    #      memory: 12G
    #    reservations:
    #      cpus: '4'
    #      memory: 6G
    # disable healthcheck for restoring backup
    #healthcheck:
    #  disable: true
networks:
  nginx:
    external: true
    name: nginx

The VM is a 6 thread 16gb

OS is currently Ubuntu 22.04.5 LTS (cloud image which is lightweight) just running a very simple docker engine install using the script (plus a few other options since I script the install)

The load averages as of this current moment are 0.12, 0.15, 0.10 so not even a full thread is being used.

I let the container run unmetered on the CPU and memory.

I can provide both the compose and my install script (which is on the GitLab instance) if you are curious.