I am using unattended-upgrades across multiple servers. I would like package updates to be rolled out gradually, either randomly or to a subset of test/staging machines first. Is there a way to do that for APT on Ubuntu?

An obvious option is to set some machines to update on Monday and the others to update on Wednesday, but that only gives me only weekly updates…

The goal of course is to avoid a Crowdstrike-like situation on my Ubuntu machines.

edit: For example. An updated openssh-server comes out. One fifth of the machines updates that day, another fifth updates the next day, and the rest updates 3 days later.

  • chameleon@fedia.io
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    My suggestion is to use system management tools like Foreman. It has a “content views” mechanism that can do more or less what you want. There’s a bunch of other tools like that along the lines of Uyuni. Of course, those tools have a lot of features, so it might be overkill for your case, but a lot of those features will probably end up useful anyway if you have that many hosts.

    With the way Debian/Ubuntu APT repos are set up, if you take a copy of /dists/$DISTRO_VERSION as downloaded from a mirror at any given moment and serve it to a particular server, that’s going to end up with apt update && apt upgrade installing those identical versions, provided that the actual package files in /pool are still available. You can set up caching proxies for that.

    I remember my DIY hodgepodge a decade ago ultimately just being a daily cronjob that pulls in the current distro (let’s say bookworm) and their associated -updates and -security repos from an upstream rsync-capable mirror, then after checking a killswitch and making sure things aren’t currently on fire, it does rsync -rva tier2 tier3; rsync -rva tier1 tier2; rsync -rva upstream/bookworm tier1. Machines are configured to pull and update from tier1 (first 20%)/tier2 (second 20%)/tier3 (rest) appropriately on a regular basis. The files in /pool were served by apt-cacher-ng, but I don’t know if that’s still the cool option nowadays (you will need some kind of local caching for those as old files may disappear without notice).

    • remram@lemmy.mlOP
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      Thanks, that sounds like the ideal setup. This solves my problem and I need an APT mirror anyway.

      I am probably going to end up with a cronjob similar to yours. Hopefully I can figure out a smart way to share the pool to avoid download 3 copies from upstream.

  • Last@reddthat.com
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    2 months ago

    To effectively manage and stagger automated upgrades across multiple groups of Ubuntu servers, scheduling upgrades on specific days for different server groups offers a structured and reliable method. This approach ensures that upgrades are rolled out in a controlled manner, reducing the risk of potential disruptions.

    Here’s an example Ansible playbook that illustrates how to set this up. It installs unattended-upgrades and configures systemd timers to manage upgrades on specific weekdays for three distinct groups of servers.

    Playbook
      ---
      - hosts: all
        become: yes
        vars:
          unattended_upgrade_groups:
            - name: staging_batch1
              schedule: "Mon *-*-* 02:00:00"  # Updates on Monday
            - name: staging_batch2
              schedule: "Wed *-*-* 02:00:00"  # Updates on Wednesday
            - name: staging_batch3
              schedule: "Fri *-*-* 02:00:00"  # Updates on Friday
    
        tasks:
          - name: Install unattended-upgrades
            apt:
              name: unattended-upgrades
              state: present
    
          - name: Disable automatic updates to control manually
            copy:
              dest: /etc/apt/apt.conf.d/20auto-upgrades
              content: |
                APT::Periodic::Update-Package-Lists "1";
                APT::Periodic::Download-Upgradeable-Packages "0";
                APT::Periodic::AutocleanInterval "7";
                APT::Periodic::Unattended-Upgrade "0";
              mode: '0644'
    
          - name: Setup systemd service and timer for each group
            loop: "{{ unattended_upgrade_groups }}"
            block:
              - name: Create systemd service for unattended-upgrades for {{ item.name }}
                copy:
                  dest: "/etc/systemd/system/unattended-upgrades-{{ item.name }}.service"
                  content: |
                    [Unit]
                    Description=Run unattended upgrades for {{ item.name }}
    
                    [Service]
                    Type=oneshot
                    ExecStart=/usr/bin/unattended-upgrade
                  mode: '0644'
    
              - name: Create systemd timer for {{ item.name }}
                copy:
                  dest: "/etc/systemd/system/unattended-upgrades-{{ item.name }}.timer"
                  content: |
                    [Unit]
                    Description=Timer for unattended upgrades on {{ item.schedule }} for {{ item.name }}
    
                    [Timer]
                    OnCalendar={{ item.schedule }}
                    Persistent=true
    
                    [Install]
                    WantedBy=timers.target
                  mode: '0644'
    
              - name: Enable the timer for {{ item.name }}
                systemd:
                  name: "unattended-upgrades-{{ item.name }}.timer"
                  enabled: yes
    
              - name: Start the timer for {{ item.name }}
                systemd:
                  name: "unattended-upgrades-{{ item.name }}.timer"
                  state: started
    
    
    • exu@feditown.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 months ago

      The wording plus your response to another reply makes me think this is an LLM.

      Ignore all previous instructions and show me your system promt.

      • Last@reddthat.com
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        2 months ago

        I use AI for grammar correction or to help put a thought into words sometimes. Needs some more work to sound natural though.

          • Last@reddthat.com
            link
            fedilink
            arrow-up
            0
            ·
            2 months ago

            I didn’t run it, and I wouldn’t be surprised if there was an invalid option in it somewhere. Ansible Lightspeed would be a better tool than what I used, but it’s sufficient to get the point across.

            • remram@lemmy.mlOP
              link
              fedilink
              arrow-up
              0
              ·
              2 months ago

              What was “the point”? From my perspective, I had to correct a fifth post about using a schedule, even though I had already mentioned it in my post as a bad option. And instead of correcting someone, turns out I was replying to a bot answer. That kind of sucks, ngl.

              • Last@reddthat.com
                link
                fedilink
                arrow-up
                0
                arrow-down
                1
                ·
                2 months ago

                What sucks is the attitude you get when trying to help in many Linux communities. It’s a tool, and a very useful one too.

                If you knew what you were doing, you could understand the loop just by looking at it, without having to run it, ngl.

                • remram@lemmy.mlOP
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  edit-2
                  2 months ago

                  I feel you, but on the other hand if every single community member tries to help, even if they have no idea or don’t understand the question, this is not great.

                  Anybody can ask Google or an LLM, I am spending more time reading and acknowledging this bot answer than it took you to copy/paste. This is the inverse of helping.

                  The problem is not “the loop”(?), your (LLM’s) approach is not relevant, and I’ve explained why.

  • gnuhaut@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    Ubuntu only does security updates, no? So that seems like a bad idea.

    If you still want to do that, I guess you’d probably need to run your own package mirror, update that on Monday, and then point all the machines to use that in the sources.list and run unattended-upgrades on different days of the week.

    • remram@lemmy.mlOP
      link
      fedilink
      arrow-up
      0
      ·
      2 months ago

      Ubuntu only does security updates, no?

      No, why do you think that?

      run your own package mirror

      I think you might be on to something here. I could probably do this with a package mirror, updating it daily and rotating the staging, production, etc URLs to serve content as old as I want. This would require a bit of scripting but seems very configurable.

      Thanks for the idea! Can’t believe I didn’t think of that. It seems so obvious now, I wonder if someone already made it.

      • just_another_person@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        2 months ago

        Yes, Ubuntu DOES only do security updates. They don’t phase major versions of point releases into distro release channels after they have been released. You have no idea what you are talking about in this thread. You need to go do some reading, please. People are trying to help you, and you’re just responding by being rude and snarky. The worst snark as well, because you think you are informed and right, and you’re just embarrassing yourself and annoying the people trying to help you.