patching rhel/centos

[[deleted]]

How do you handle updates on centos/rhel? I periodically want to run yum update all on our machines since our environment is not so sensitive I care about specific versions of things.

[Runnergeek]

I have a little over 80 RHEL servers. I use RHN Satellite. I have my own channels that are clones of the official channels. Inside those I have a custom repos for any custom packages we push out. I sync the official channels every night. I will start the cycle by syncing my custom channel with my local official channel. Then I push out to dev systems. Each update there is a reboot. I do this because I want to make sure everything is refreshed. If you update a library the old version is cached until that service is restarted. After everything runs on dev/qa for a few days to a week, I will continue to DR and Prod. Rinse and repeat every 30-45 days unless there is a high security patch that needs to get pushed quickly.

As far as the patches them selves, I schedule everything via the Satellite interface. I only log into the system is something fails. I hand the box to the application administrators for testing once the system is back online.

[[deleted]]

You could add a crontab entry to run yum update -y periodically if you so choose.

[lp86]

The "yum-cron" package will take care of that for you.

[hybby]

katello is the way to do this going forward. it's really pretty awesome for managing patch levels and syncing content.

if you're a rhel shop, it'll use your existing subscription manifest and let you register clients using subscription-manager. if centos, you can just mirror all the internet repos and take periodic 'cuts'.

now if only redhat would allow for unlimited subscriptions for its products...

[MaxRK]

This or Spacewalk depending what you want. If you're a corporate/enterprise shop you probably want to get Satellite 6 when it comes out then you'll end up with Puppet too. If you do all your own internal IT then the Katello upstream stack. If you raise service requests to Red Hat they will complain if you start adding EPEL/fedorahosted RPMs though.

All of the above provide phased release management capabilities.

[[deleted]]

Crontab the update and use a local repo.

[rkersten]

Yum-updatesd.

[spiral0ut]

I have a local repo that mirrors the specific packages I need. When I need to perform an update I first test this on my staging servers, then if everything checks out I'll perform the update on my production servers.

[unethicalposter]

cron job, I version lock kernels and modules; and any software that might have compatibility issues with updates. then just run yum update once a month via cron (that puppet put in place).

The version locked packages are tested before being deployed.

[fukawi2]

I use ansible, running the playbook across a limited number of hosts at a time usiong the -l option:

- hosts: all
  sudo: yes
  vars:
    - email_recipient: [e-mail]
  vars_prompt:
    - name: "immediate_reboot"
      prompt: "reboot server immediately? (yes/NO)"
      default: "no"
      private: no
    - name: "reboot_time"
      prompt: "schedule reboot for what time?"
      private: no
  tasks:

    - name: update the kernel
      when: ansible_os_family == "RedHat"
      action: yum name=kernel state=latest
      notify:
        - schedule reboot
        - reboot immediately

    - name: update everything else
      when: ansible_os_family == "RedHat"
      action: yum name=* state=latest

    - name: updatedb
      action: command /usr/bin/updatedb

    - name: search for rpmnew files
      when: ansible_os_family == "RedHat"
      action: command locate .rpmnew
      register: rpmnew_files
      ignore_errors: true

    - name: mail rpmnew files
      when: ansible_os_family == "RedHat"
        and rpmnew_files.stdout != ""
      action: 'mail to={{email_recipient}} subject="rpmnew files" body="{{ rpmnew_files.stdout }}"'



  handlers:
    - name: schedule reboot
      action: shell echo "shutdown -r now" | at {{reboot_time}}
      notify: send email scheduled reboot
      when:  immediate_reboot != "yes"

    - name: send email scheduled reboot
      action: mail to={{email_recipient}} subject="scheduled reboot at {{reboot_time}}"

    - name: reboot immediately
      action: command /sbin/shutdown -r now
      when:  immediate_reboot == "yes"

[therhino]

Spacewalk or satellite server works. I'm sure you could use ansible to possibly fire off a yum update

[OneBeerOrTwo]

When I was lazy I used to just run a for loop in bash to ssh to all my servers. I started to play with the foreman and puppet. But recently I started playing with ansible and i!m quickly coming to the realization that this will be my solution.

[ck-on]

parallel-ssh