Hi,
I am unfortunately now allowed to post the code, but I can explain the architecture. First of all, we have setup groups : development servers, pre-production, production We have also one channel per OS type, from CentOS5-32b to CentOS7-64b Each month, we start a first script that clones each channel to another named “frozen-OS-arch” which stays the same for the whole month I have written a second script that lists systems in a group, looks for them via the vmware API to snapshot them, and create a snapshot deletion script. (for later) Then a third script schedules the updates this way : - Lists all systems in the selected group(s) - Move them to their respective “frozen” channel - Order the list depending on a custom value “priority” (allow us to distribute members of a cluster among the same group) - Then loop over the list and do this : o Verify that the VM has a correct snapshot, o Verify that the system has updates to apply (system.listLatestUpgradablePackages) o Log the packages to be updated o Schedule this remote command(system.scheduleScriptRun) : #!/bin/bash #avoid stacking dozens of kernels perl -pi -e \'s/installonly_limit=.*$/installonly_limit=3/\' /etc/yum.conf grep -q -v installonly_limit /etc/yum.conf && perl -pi -e \'s/\[main\]/[main]\ninstallonly_limit=3/\' /etc/yum.conf echo "Started : $(date)" yum update -y || exit -1 echo "Finished : $(date)” #Avoid boot loops [ $(cut -d'.' -f 1 /proc/uptime) -gt 900 ] && shutdown -r -t 30 now o Rename the scheduled action to something more meaningful (can’t be done with API, need to modify the database : public.rhnaction set name=’’ where id=’’) o Wait 30 seconds, then move to next system - Once all actions are scheduled, we wait for them to finish (schedule.listInProgressActions) for 30 minutes - And finally, we move back all systems to their normal channels Hope this gives you ideas. It is important to think first about your update process and the way you want to organize each cycle, and then go ahead with the code. We have choosen the perl API because of your skills here being way higher in this language, but python works even better, i’ve been told. Good luck. Maxime De : [email protected] [mailto:[email protected]] De la part de Matt Moldvan Envoyé : jeudi 14 avril 2016 22:03 À : [email protected] Objet : Re: [Spacewalk-list] Action Chains? We opted for Spacewalk last year over Katello/Foreman/Pulp/Candlepin because of the (somewhat) simplified install process. Overall it's still been a big learning curve. For us, we were thinking of setting up Spacewalk as a platform for our Operations personnel to log in and schedule patching for the many thousands of systems we manage. For that reason, having a set of action chains that is abstract enough to be reusable (e.g. schedule all security errata for group X during patch window at timestamp blah, back end code figures out the rest) isn't necessarily something that doesn't make sense; on the contrary it would make a lot of sense and save a lot of time. For smaller environments, or if we're thinking stricly in specifics (e.g. schedule errata CESA-2016:0519 to be applied on host xyz then reboot), I agree it doesn't make sense. With that said, the next step for us is like Maxime, to automate the update process using the API. Unfortunately I haven't found any examples in the wild yet... Maxime would you be able to share any of the code or how you implemented it? On Thu, Apr 14, 2016 at 3:50 AM Maxime VEROONE <[email protected]> wrote: Hi, We, here, at first sought for action chain templates or something similar. We have then moved to automating the update process with an extensive use of the API. Just FYI, Satellite 6 is built around Katello, (http://www.katello.org/) and not Spacewalk. Katello is using puppet as a core component. I hope that answers your question. Maxime De : [email protected] [mailto:[email protected]] De la part de Lachlan Musicman Envoyé : jeudi 14 avril 2016 08:19 À : [email protected] Objet : Re: [Spacewalk-list] Action Chains? Daniel, Yes, so long as you don't schedule or action them. Once you do that, they disappear. That section seems to be a holding zone for action chains that are "being built" - once the chain is run, it disappears. Would be nice to have some permanence - especially if pushing a new conf file from Configuration and you want to restart a service - on >3 machines, would be nice to automate. I guess at that point I should be using Ansible or fabric. Would just be nice to have everything in the same space. Does anyone know if the move to Satellite 6 will be more Ansible/Chef/Puppet like? cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 14 April 2016 at 15:36, Daniel Eather <[email protected]> wrote: Can you see your saved action chains in Schedule > Action Chains ? I can’t confirm as I don’t use them (yet) but the description of this page states “Below is a list of all Action Chains available to the current user. Click on a label to view or edit it.” Seems legit. From: [email protected] [mailto:[email protected]] On Behalf Of Matt Moldvan Sent: Wednesday, 13 April 2016 12:35 PM To: [email protected] Subject: Re: [Spacewalk-list] Action Chains? I don't think so, unfortunately. If I'm wrong I'd love to hear otherwise... would be nice if they could be saved, shared among other users, etc. But seems like they are one time use and they fly away... On Tue, Apr 12, 2016 at 9:20 PM Lachlan Musicman <[email protected]> wrote: I just set up an action chain, and was quite chuffed with myself. After I scheduled it, it executed, and now I can't find it any more? Surely actions chains are saved for repeated use? cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list ______________________________________________________________________ Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Fletcher Building or any related subsidiaries. _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
