Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

We're using HP DataProtector for our backup environment. The installation method leaves something to be desired, and we're attempting to automate it in such a way that it makes our Unix admins cringe less often. We're a SLES/OpenSUSE shop, so we're attempting to make up a YUM repository with the DP patches.

I can make the repo just fine, it's just that the patch RPMs aren't configured right. The 'Revision' field in the RPM is not set correctly, they're all "1" even though the master RPM I pulled them out of is correctly incrementing.

I would really like to be able to rebuild these RPMs with the correct Revision, as that would allow the normal update process to deal with these patches instead of the strange way HP wants to handle these.


The strange way HP wants to handle these requires:

  • Setting up an Installation Server with all of the software. No problem.
  • Allowing root to ssh into client stations to install software that affects xinitd config
    • Which in turn requires a passwordless SSH public-key to be placed on all target machines so the install process can remote in w/o prompting.
    • Before any deployments can be made, each client must be manually SSHed to by root on the repo server in order to populate known_hosts

Since we don't allow root logins via SSH, every time we get a patch we have to touch each server's sshd_config to allow them temporarily. We've also proven that after the initial install, subsequent patches can just be installed via rpm just peachy. So, we'd like to get that into a YUM repo if at all possible.

share|improve this question
    
Can you elaborate on 'they're all "1" even though the master RPM I pulled them out of is correctly incrementing.'? How are you pulling them out? –  Mikel Feb 2 '11 at 1:30
    
@Mikel The install-server patch-RPM drops RPMs in specific locations in the Install Server. These RPMs are then installed to clients via the ssh-install process, using the -Uvh flag. rpm -qip filename.rpm on the install-server RPM shows a version of 6.11.3, where the sub-RPMs show a version of 6.11.1, the same version as the original installed software. –  sysadmin1138 Feb 2 '11 at 1:42
add comment

1 Answer

up vote 1 down vote accepted

Rather than re-package the existing RPM, inspired by HP I packaged it in an additional RPM. The new RPM is very simple in that it just has the single patch-RPM inside it, and invokes the rpm command to install it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.