In the first article of these series “Setting up a LPYR PART1”, I essentially delved with how to setup a LPYR. That is I provided you with clear and comprehensive 11 steps that you may follow and have a LPYR ready.
In this article, I intend to illustrate a couple of things:
1) How to generate GPG signature that can be used to sign RPM packages.
2) How to build RPM packages (both source rpm as well as binary rpm) from source code and spec files.
Instead of bugging you with persuasive arguments pertaining to the benefits of what I am about to demonstrate, I would rather give you a quick run down (step-by-step) instructions to reach the above cited objectives. Then, in my closing statement, I will present you with a group of people who may benefit from going through the pain of following these step-by-step instructions.
For the purpose of this lab, please, do not use a privileged account such as root. Use any other regular account: if you don’t have one available, create one on the fly.
Deploying firmware and package updates may pose significant challenges on system administrators (SAs). These challenges can even become cumbersome depending on the size of a network or the number of systems a SA manages. In datacenter environments for instance, the challenges might create a need of having a centralized package distribution system from which updates are either pulled or pushed. Depending upon your needs, this centralized deployment system might be a sophisticated commercial software (developed solely for this purpose) or simply a test server, where all packages are compile and tested, which is also setup to play the role of LPYR. There are numerous advantages of having such a system. However, instead of bugging you with a list of advantages, let me just provide you with a quick run down on how to setup a LPYR. Then, once you have one already deployed, you may evaluate it for yourself and come up with your own list of its benefits.
Here we go again:
1. Verify if ‘createrepo’ is already installed. If it is installed, skip step 2 and continue from step 3. Otherwise, proceed to the next step.
Have you ever had your root hard drive fail and found that your shell prompt has forgotten every command? It isn’t fun. What you first notice is that whatever you type, it’s the same answer.
bash: /bin/vi: Input/output error
Or a similar effect has been witnessed after the famous “
rm -rf *” got executed under the
/usr directory. This kind of thing would happen:
bash: ls: command not found
This is because most of the commands you use at the shell command line are binary files residing under /usr/sbin, /usr/bin, /sbin or /bin, depending on your distribution. Once they’re gone, you’re dead in the water.
So if all you have is a CLI shell prompt, but no commands work, what can you actually do?
If the problem is due to a corrupted disk, you may be able to resolve the issue by rebooting into single user mode and running an fsck on the root filesystem. In the case of missing binary directories you’d probably need to rebuild your host completely. But before you do restore from your backups (you’ve got backups, right?), you may need to make a few tweaks or check a few file contents in order to get things back up and running again.