Escalated to Bugzilla from IssueTracker
Is the installation date recorded on the Satellite Server database when a particular RPM gets installed on a client server from the Satellite server? This event sent from IssueTracker by jwest [SEG - Feature Request] issue 108691
Let me make sure I have your question correctly. You want to know if the installation date of a particular rpm is recorded on the satellite server? jwilleford assigned to issue for US Courts. Internal Status set to 'Waiting on Customer' Status set to: Waiting on Client This event sent from IssueTracker by jwest [SEG - Feature Request] issue 108691
Correct. We are aware that the installation date resides on the client server under the "Installationtime tag" . However, we need this info on the Satellite server for management purposes. Internal Status set to 'Waiting on Support' Status set to: Waiting on Tech This event sent from IssueTracker by jwest [SEG - Feature Request] issue 108691
Fred, I received this response from an RHN engineer. I am currently awaiting a response from RHN project management. <snip> This data by default is not collected by up2date to be sent to the RHN satellite/RHN Hosted. So, right now, without any changes to both the client and server side, it could not be done. That being said, it is most certainly possible to use the rpm-python binding to query the local rpm DB for package install date - same way we do for what packages are currently installed, and send that data up to RHN. This event sent from IssueTracker by jwest [SEG - Feature Request] issue 108691
Can we look at getting this into Spacewalk? Or, in lieu of this can I get some help on creating a script to get this information from a clients rpm database?
I would say this is possible. Not sure why assigned to the 'Monitoring' group of product. Need to have PM review. I feel that this does make sense. Generation of a script would be easy, using remote commands or some other utility to connect to all systems and perform a query to that systems rpm DB of dates and report them back to a central place. I do not see why Sat Engineering would be involved though, since that script would not be tired into Satellite product, just using say the remote command capabilities. Spacewalk changes/proposal can be sent to the spacewalk lists/IRC channels. Features you wish added for Satellite should be chased through the Satellite Product Management chain/process. Ideally though, to me, the customer should look at some type of lower level rpm macro to ensure all rpm transactions are logged/audited to a central location, something we could not provide, due to fact that customers can install rpms outside of Satellite/up2date/yum usage. Cliff.
Moving to 5.3.1 blockers. If, for whatever reason this requires a schema change, it will be repunted to the next major release.
I investigated it and even made first commit to spacewalk (78f52b089c82e725b77b2e38e68fb02d49fe1512). This changes will currently record date when rhn client tools report, that the package is installed. But if you install it using "rpm -i" then the date will be incorrect. I will leave it on place, but will report value of package['installtime'] (equivalent of "rpm -q --queryformat '%{NAME}-%{INSTALLTIME}' foo.rpm") in rhnPackageInfo.updatePackageProfile. Best option will be create new backend API. Updating s.registration.update_packages may break compatibility. Nevertheless this work requires schema changes and could not go to Sat 5.3.1. Assigning to next major release. I will continue in this work to prepare patch for client tools.
We had to change format in which package is sent to rhnServer from array to dictionary and sent new value installtime, which is then stored to new column of the same name in table rhnServerPackage. Changes are between commits 836214ad373a67c227459dd07bc9660f70e94253 and 9de19da46d7e2d35d7c437b4c8e71968ff881e0c (24 commit). It is only client changes and backend changes. Collected data are not visible in WebUI yet. Will clone this this BZ for client changes for next release of RHEL.
Find small bug during testing. Commit 34c1aab76cde52d15ee7332b8752acaf4b3fe12b
This has been fixed. I forgot to flip status of this BZ. Client part of this bug (BZ 530369) has been released in RHEL5.5 All code is in in Spacewalk already, so server part, which display rpm installation date in webui, will be part of next major release of RHN Satellite.
The 5.4.0 RHN Satellite and RHN Proxy release has occurred. This issue has been resolved with this release. RHEA-2010:0801 - RHN Satellite Server 5.4.0 Upgrade https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10332 RHEA-2010:0803 - RHN Tools enhancement update https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10333 RHEA-2010:0802 - RHN Proxy Server 5.4.0 bug fix update https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10334 RHEA-2010:0800 - RHN Satellite Server 5.4.0 https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10335 Docs are available: http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/index.html Regards, Clifford