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 <[email protected]> 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
[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
