[Spacewalk-list] spacewalk: package updates and rollbacks

Kastytis kbsecos at gmail.com
Tue Nov 26 10:27:51 UTC 2013


Thank you a lot for the practical tips.

1.
-----
"The spacewalk server logs the action in its database and has the roll
back information there"

I still would like to find the full package install information. It should be logged somewhere. Simple test: "yum remove logrotate" deletes rsyslog and logrotate. If I schedule rsyslog install using the spacewalk webgui then logrotate gets installed too (as a prerequisite/dependency), but the latter is not mentioned in any log.

Does anyone know if this information gets logged on the client/server? Maybe logging is optional/configurable ?
----

2.
---
So osad and rhnsd pulls the information from spacewalk server to spacewalk client, pass this information to yum and yum updates the package. Did I understand this part correctly ? It's still hard for me to believe that yum is actually installing the package on the client because the information is not logged to /var/log/yum.log on the client.

Could anyone please confirm that yum is used for updating the package ?
---

Thanks,
Kastytis

On 11/25/2013 06:00 PM, Paul Robert Marino wrote:
> On Mon, Nov 25, 2013 at 9:52 AM, Kastytis <kbsecos at gmail.com> wrote:
>> Hi Spacewalkers!
>>
>> I try to find out what programs and services are providing the package
>> management functionality on spacewalk. When a package update is scheduled on
>> the webgui it gets installed on the client (Wolla!). The yum logs on the
>> client are empty and the the rpm -U does not log anything by default. Some
>> rhn* logs contain a lot of information but are had to interpret.
> The spacewalk server logs the action in its database and has the roll
> back information there
> however the safest bet is to take a package snapshots after the host
> has been built and after each update.
>
>> I tried looking at redhat documentation [1] but but could not find a clear
>> answer. Possible answers could be.
>>
>> up2date ? (even on when the client OS is Centos ???)
>> rpm ?
>> yum ?
>> rhn_register ?
> yum and rhn_register do work on CentOS with spacewalk but updates
> through yum do not get logged in spacewalk. spacewalk will become
> aware of them when it does its nightly checks but it will not store
> rollback information.
> its also important to remember not to include the default CentOS yum
> repos in your install or disable them.
>
> I always include a post snippet to ensure all non spacewalk repos are disables
>
> "
>   perl -npe 's/enabled=1/enabled=0/g' -i /etc/yum.repos.d/*
> "
>
>> Could anyone please enlighten me how the package gets updated?
>> - How the update package is pushed from the server to the client?
>> - what program/package-manager on the client side client installs the
>> package?
>> - Do detailed update logs exist on spacewalk server? I see the client
>> history logs, the actions scheduled for that client and the result; i.e.,
>> was that action was successful or not. But the information is not detailed
>> and lacks for example a list of additionally the installed dependencies.
>> What I would like to see is the list of all packages and their status, like
>> in YUM log (installed packages, installed dependencies, deleted packages,
>> failed packages). Do such logs exist somewhere on spacewalk server or at
>> least on the client?
>>
>> spacewalk server: Centos6
>> spacewalk client: Centos6
>>
>> This leads to one more question requiring some hands on experience with
>> spacewalk: would you consider spacewalk as a reliable system for package
>> management (updates) in a Centos5 and Centos6 server environment? I am
>> basically concerned about rolling back the updates using so called profile
>> snapshots (That's why I need to know how package gets updated on the
>> client). Is this feature designed (or safe enough) to be used for update
>> rollbacks? Is this functionality normally "enough" in real life scenarios to
>> bring the Server back to "before the update" state.
> Spacewalk is fine for managing CentOS, Scientific Linux, SuSE, etc..
> The snapshots work very well.
> By the way for support reasons Redhat Network Satellite explicitly
> Does not support any thing other than RHEL and the SuSE incarnation
> SuSE Manager only Supports SuSE and RHEL.
>
> That said I use spacewalk with CentOS, Scientific Linux, Fedora
> workstations, and even RHEL in production and its done a very good
> Job.
>
>
>> In other words: would it be reasonable to skip the step doing snapshots of
>> the virtual-servers before scheduling regular server update with spacewalk?
> That's up to you but its always safest to have rollback capability is
> to use snapshots.
> I always do my update, take a snapshot, then lock the host so people
> cant use yum to circumvent change control.
>
>> [1]
>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Network_Satellite/5.5/html-single/Reference_Guide/index.html
>>
>> Thank you and best wishes,
>> Kastytis
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list




More information about the Spacewalk-list mailing list