0301-0303.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 282 行
HTML
282 行
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):Real-World Package Building:EarthWeb Inc.-</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311054 //-->
<!-- TITLE=Maximum RPM (RPM)//-->
<!-- AUTHOR=Edward Bailey//-->
<!-- PUBLISHER=Macmillan Computer Publishing//-->
<!-- IMPRINT=Sams//-->
<!-- CHAPTER=20 //-->
<!-- PAGES=0275-0304 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0298-0300.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0304-0304.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-301"><P>Page 301</P></A>
<P>are trying to see whether there will be zero instances of this package after the uninstall is
complete. If this is the case, the remainder of the script needs to be run, since there are no
other amanda client packages left.
</P>
<P>Next, we remove bin from the disk group:
</P>
<!-- CODE //-->
<PRE>
# First, get rid of bin from the disk group...
if grep "^disk::.*bin" /etc/group > /dev/null
then
# Nuke bin at the end of the line...
sed -e `s/\(^disk::[0-9]\{1,\}:.\{1,\}\),bin$/\1/' /etc/group> /etc/group.tmp
# Nuke bin on the line by itself...
sed -e `s/\(^disk::[0-9]\{1,\}:\)bin$/\1/' /etc/group.tmp> /etc/group1.tmp
# Nuke bin in the middle of the line...
sed -e `s/\(^disk::[0-9]\{1,\}:.\{1,\}\),bin,\(.\{1,\}\)/\1,\2/'/etc/group1.tmp > /etc/group2.tmp
# Nuke bin at the start of the line...
sed -e `s/\(^disk::[0-9]\{1,\}:\)bin,\(.\{1,\}\)/\1\2/'/etc/group2.tmp > /etc/group
# Clean up after ourselves...
rm -f /etc/group.tmp /etc/group1.tmp /etc/group2.tmp
fi
</PRE>
<!-- END CODE //-->
<P>No surprises there. Continuing our uninstall, we start on the network-related tasks:
</P>
<!-- CODE //-->
<PRE>
# Next, lose the amanda line in /etc/services...
# We only want to do this if the server package isn't installed
# Look for /usr/sbin/amdump, and leave it if there...
if [ ! -f /usr/sbin/amdump ];
then
if grep "^amanda" /etc/services > /dev/null
then
grep -v "^amanda" /etc/services > /etc/services.tmp
mv -f /etc/services.tmp /etc/services
fi
fi
</PRE>
<!-- END CODE //-->
<P>That's odd. Why are we looking for a file from the server package? If you look back at the
install scripts for the client and server packages, you'll find that the one thing they have in
common is that both the client and the server require the same entry in
/etc/services.
</P>
<P>If an amanda server is going to back itself up, it also needs the amanda client software.
</P>
<P>Therefore, both subpackages need to add an entry to
/etc/services. But what if one of the packages is removed? Perhaps the server is being demoted to a client, or maybe the server is
no longer going to be backed up using amanda. In these cases, the entry in
/etc/services must stay. So, in the case of the client, we look for a file from the server subpackage, and if it's
there, we leave the entry alone.
</P>
<A NAME="PAGENUM-302"><P>Page 302</P></A>
<P>Granted, this is a somewhat unsightly way to see whether a certain package is installed.
Some of you are probably even saying, "Why can't RPM be used? Just do an
rpm -q amanda-server, and decide what to do based on that." And that would be the best way to do it, except for
one small point: Only one invocation of RPM can run at any given time.
</P>
<P>Since RPM is running to perform the uninstall, if the uninstall script were to attempt to
run RPM again, it would fail. The reason it would fail is because only one copy of RPM can
access the database at a time. So we are stuck with our unsightly friend.
</P>
<P>Continuing the network-related uninstall tasks…
</P>
<!-- CODE //-->
<PRE>
# Finally, the amanda entry in /etc/inetd.conf
if grep "^amanda" /etc/inetd.conf > /dev/null
then
grep -v "^amanda" /etc/inetd.conf > /etc/inetd.conf.tmp
mv -f /etc/inetd.conf.tmp /etc/inetd.conf
# Kick inetd
if [ -f /var/run/inetd.pid ];
then
kill -HUP `cat /var/run/inetd.pid`
fi
fi
fi
</PRE>
<!-- END CODE //-->
<P>Here, we're using grep's capability to return lines that don't match the search string, in
order to remove every trace of amanda from
/etc/inetd.conf. After issuing a HUP on inetd,
we're done.
</P>
<P>On to the server. If you've been noticing a pattern between the various scripts, you won't
be disappointed here:
</P>
<!-- CODE //-->
<PRE>
%postun server
# See if we're the last server package on the system...
# If not, we don't need to do any of this stuff...
if [ "$1" = 0 ];
then
# Lose the amanda line in /etc/services...
# We only want to do this if the client package isn't installed
# Look for /usr/lib/amandad, and leave it if there...
if [ ! -f /usr/lib/amanda/amandad ];
then
if grep "^amanda" /etc/services > /dev/null
then
grep -v "^amanda" /etc/services > /etc/services.tmp
mv -f /etc/services.tmp /etc/services
fi
fi
fi
</PRE>
<!-- END CODE //--><A NAME="PAGENUM-303"><P>Page 303</P></A>
<P>By now, the opening if statement is an old friend. As you might have expected, we are
verifying whether the client package is installed by looking for a file from that package. If the
client package isn't there, the entry is removed from
/etc/services. And that is that.
</P>
<P>Obviously, these scripts must be carefully tested. In the case of amanda, because the
two subpackages have some measure of interdependency, it's necessary to try different sequences
of installing and erasing the two packages to make sure the
/etc/services logic works properly in all cases.
</P>
<P>After a bit of testing, our install and uninstall scripts pass with flying colors. From a
technological standpoint, the client and server subpackages are ready to go.
</P>
<H4><A NAME="ch20_ 27">
20.4.3.3. Bits and Pieces
</A></H4>
<P>However, just because a package has been properly built and installs and can be erased
without problems doesn't mean that the package-builder's job is done. It's necessary to look at
each newly built package from the user's perspective. Does the package contain everything users
needs in order to deploy it effectively? Or will users need to fiddle with it, guessing as they go?
</P>
<P>In the case of our amanda packages, it was obvious that some additional documentation
was required so that the user would know what needed to be done to finalize the installation.
Simply directing the user to the standard amanda documentation wasn't the right solution,
either. Many of the steps outlined in the INSTALL document had already been done by the
postinstall scripts. No, an interim document was required. Two, actually: one for the client, and one
for the server.
</P>
<P>So two files were created, one to be added to each subpackage. The question was, how to do
it? Essentially, there were two options:
</P>
<UL>
<LI> Put the files in the amanda directory tree that had been used to perform the
initial builds and generate a new patch file
<LI> Create a
tar file containing the two files, and modify the spec file to unpack
the documentation into the amanda directory tree
<LI> Drop the files directly into the amanda directory tree without using
tar
</UL>
<P>Since the second approach was more interesting, that's the approach we chose. It required
an additional source tag in the spec file:
</P>
<!-- CODE SNIP //-->
<PRE>
Source1: amanda-rpm-instructions.tar.gz
</PRE>
<!-- END CODE SNIP //-->
<P>Also required was an additional %setup macro in the
%prep script:
</P>
<!-- CODE SNIP //-->
<PRE>
%setup -T -D -a 1
</PRE>
<!-- END CODE SNIP //-->
<P>While the %setup macro might look intimidating, it wasn't that hard to construct. Here's
what each option means:
</P>
<BLOCKQUOTE>
-T—Do not perform the default archive unpacking.
</BLOCKQUOTE>
<P><CENTER>
<a href="0298-0300.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0304-0304.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?