Page 298
First, we start the script with a %post statement and indicate that this script is for the client subpackage. As the comments indicate, we only want to perform the following tasks if this is the first time the client subpackage has been installed. To do this, we use the first and only argument passed to the script. It is a number indicating how many instances of this package will be installed after the current installation is complete.
If the argument is equal to 1, no other instances of the client subpackage are presently installed and this one is the first. Let's continue:
# Set disk devices so that bin can read them
# (This is actually done on Red Hat Linux; only need to add bin to
# group disk)
if grep "^disk::.*bin" /etc/group > /dev/null
then
true
else
# If there are any members in group disk, add bin after a comma...
sed -e `s/\(^disk::[0-9]\{1,\}:.\{1,\}\)/\1,bin/' /etc/group > /etc/group.tmp
# If there are no members in group disk, add bin...
sed -e `s/\(^disk::[0-9]\{1,\}:$\)/\1bin/' /etc/group.tmp > /etc/group
# clean up!
rm -f /etc/group.tmp
fi
One of amanda's requirements is that the user ID running the dumps on the client needs to be able to read from every disk's device file. The folks at Red Hat have done half the work for us by creating a group disk and giving that group read/write access to every disk device. Since our dumpuser is bin, we only need to add bin to the disk group. Two lines of sed, and we're done!
The next section is related to the last. It also focuses on making sure bin can access everything it needs while doing backups:
# Also set /etc/dumpdates to be writable by group disk chgrp disk /etc/dumpdates chmod g+w /etc/dumpdates
Since amanda uses dump to obtain the backups, and since dump keeps track of the backups in /etc/dumpdates, it's only natural that bin will need read/write access to the file. In a perfect world, /etc/dumpdates would have already been set to allow group disk to read and write, but we had to do it ourselves. It's not a big problem, though.
Next, we need to create the appropriate network-related entries so that amanda clients can communicate with amanda servers and vice versa:
# Add amanda line to /etc/services if grep "^amanda" /etc/services >/dev/null then
Page 299
true else echo "amanda 10080/udp # Added by package amanda-client" >>/etc/services fi
By using grep to look for lines that begin with the letters amanda, we can easily see whether
/etc/services is already configured properly. If it isn't, we simply append a line to the end.
We also added a comment so that sysadmins will know where the entry came from and either take our word for it or issue an rpm -q --scripts amanda-client command and see for themselves. We did it all on one line because it makes the script simpler.
Let's look at the rest of the network-related part of this script:
# Add amanda line to /etc/inetd.conf if grep "^amanda" /etc/inetd.conf >/dev/null then true else echo "amanda dgram udp wait bin /usr/lib/amanda/amandad amandad # added by package amanda-client" >>/etc/inetd.conf # Kick inetd if [ -f /var/run/inetd.pid ]; then kill -HUP `cat /var/run/inetd.pid` fi fi fi
Here, we've used the same approach to add an entry to /etc/inetd.conf. We then send a hangup signal to inetd so the change will take effect, and we're done!
Oh, and that last fi at the end? That's to close the if [ "$1" = 1 ] at the start of the script. Now let's look at the server's postinstall script:
%post server # See if they've installed amanda before... if [ "$1" = 1 ]; then # Add amanda line to /etc/services if grep "^amanda" /etc/services >/dev/null then true else echo "amanda 10080/udp # Added by package amanda-server">>/etc/services fi fi
Page 300
That was short! And this huge difference brings up a good point about writing install scripts: It's important to understand what you as the package builder should do for the users, and what they should do for themselves.
In the case of the client package, every one of the steps performed by the postinstall script was something that a fairly knowledgeable user could have done. But all these steps have one thing in common. No matter how the user configures amanda, these steps will never change. And given the nature of client/server applications, there's a good chance that many more amanda client packages will be installed than amanda servers. Would you like to be tasked with installing this package on 20 systems and performing each of the steps we've automated 20 times? We thought not.
There is one step we did not automate for the client package: the creation of an .rhosts file. Since this file must contain the name of the amanda server, we have no way of knowing what the file should look like. Therefore, that's one step we can't automate.
The server's postinstall script is so short because there's little else that can be automated. The other steps required to set up an amanda server include the following:
Since every step depends on the user making decisions, the best way to handle them is to not handle them at all. Let the user do it!
Where there are install scripts, there are uninstall scripts. While there is no ironclad rule to that effect, it is a good practice. Following this practice, we have an uninstall script for the client package, and one for the server. Let's take the client first:
%postun client # First, see if we're the last amanda-client package on the system... # If not, then we don't need to do this stuff... if [ "$1" = 0 ]; then
As before, we start out with a declaration of the type of script this is and which subpackage it is for. Following that, we have an if statement similar to the one we used in the install scripts, save one difference. Here, we're comparing the argument against zero. The reason is that we