<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>linsec.ca blog &#187; rpm</title>
	<atom:link href="http://linsec.ca/blog/tag/rpm/feed/" rel="self" type="application/rss+xml" />
	<link>http://linsec.ca/blog</link>
	<description>You can have it right, or you can have it now.  But you can&#039;t have it right now.</description>
	<lastBuildDate>Mon, 23 Jan 2012 23:38:17 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>rpm -V and prelinked binaries</title>
		<link>http://linsec.ca/blog/2012/01/23/rpm-v-and-prelinked-binaries/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=rpm-v-and-prelinked-binaries</link>
		<comments>http://linsec.ca/blog/2012/01/23/rpm-v-and-prelinked-binaries/#comments</comments>
		<pubDate>Mon, 23 Jan 2012 23:38:08 +0000</pubDate>
		<dc:creator>vdanen</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[aide]]></category>
		<category><![CDATA[prelink]]></category>
		<category><![CDATA[rpm]]></category>

		<guid isPermaLink="false">http://linsec.ca/blog/?p=1051</guid>
		<description><![CDATA[I&#8217;v been asked this question a few times over the last year or so, so I thought I would explain some of why you might see some issues on a Fedora or Red Hat Enterprise Linux system (or any other Linux distribution that uses prelinked binaries) when trying to track down strange MD5/SHA1 changes to [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;v been asked this question a few times over the last year or so, so I thought I would explain some of why you might see some issues on a Fedora or Red Hat Enterprise Linux system (or any other Linux distribution that uses prelinked binaries) when trying to track down strange MD5/SHA1 changes to binaries.</p>
<p>By default, and for nearly a decade now, prelink has shipped with Red Hat Enterprise Linux and Fedora.  What it does is modify the ELF code in binaries and libraries to speed up load times, so that fewer relocations need to be resolved when executing a program.  I can&#8217;t explain all the details and technicalities of it because, quite frankly, they are above my limited brainpower to explain.  Suffice it to say, prelinking is a good thing.  Unless you are using AIDE or Tripwire.  These programs determine whether or not a file has changed based on their MD5SUM or SHA1SUM (or any other *SUM of the binary).  So when you install a program, AIDE sees a certain MD5SUM of the binary.  Later, when prelink runs, that binary might be modified to do the aforementioned relocations.  This will result in a different MD5SUM of the binary, and AIDE will most certainly tell you about the change.  What does not inform you of the change, however, is rpm -V (or rpm &#8211;verify).</p>
<p>The verification command in RPM tells it to compare the MD5SUM of the files in certain package to what is on the filesystem.  It&#8217;s a poor man&#8217;s AIDE, and can also tell you what has changed on your system (from what RPM expects according to when it was installed).  In theory, you would expect rpm -V to report the same discrepancy that AIDE does.  The fact that it doesn&#8217;t is what&#8217;s led to a few questions regarding this.</p>
<p>The &#8220;problem&#8221; (if you can call it that) is that rpm knows about prelink, and knows how to deal with it.  As is succinctly explained in this <a href="http://www.redhat.com/archives/shrike-list/2003-April/msg00592.html">mailing list email</a>, &#8220;rpm when &#8211;verify will prelink &#8211;verify, which is essentially &#8211;undo followed by prelinking again and comparing.&#8221;  So the reason that rpm doesn&#8217;t fail the verification is that it is basically turning off prelink for the file(s) to check, running the verification, then turning prelink back on.  This is why rpm won&#8217;t report on a MD5SUM change, but AIDE will.</p>
<p>So for those of us who use AIDE, we know that we need to do things like daily runs to make sure nothing has changed.  The problem is that if you do this and run a yum update, X number of hours later you&#8217;ll get an email telling you that files have changed.  You might, at that point, update AIDE but there is a window of opportunity there where you may miss things.  We can minimize this by doing an AIDE check, then yum update, then force a prelink run, then update AIDE.  I&#8217;ve been doing this for a few years on Red Hat Enterprise Linux 5 and it essentially gets rid of all false positives.  It&#8217;s a little script called <b>do-update</b> that I execute as root and it runs this:</p>
<pre>
#!/bin/sh
aidecheck &#038;&#038; yum update -y &#038;&#038; /etc/cron.daily/prelink &#038;&#038; aideupdate
</pre>
<p>This doesn&#8217;t eliminate the window of opportunity completely, but it does lessen it considerably.  This uses my <a href="https://github.com/vdanen/AIDE_gpg">AIDE_gpg</a> scripts (aidecheck and aideupdate).  The rest is pretty self-explanatory.</p>
<p>Hopefully this information will be useful to someone.  It took me a bit to dig up the mailing list message I link to above; I knew that prelink was had some special relationship with rpm, but I didn&#8217;t know the particulars.  Now I do, and so do you.  =)</p>
]]></content:encoded>
			<wfw:commentRss>http://linsec.ca/blog/2012/01/23/rpm-v-and-prelinked-binaries/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Save time on downloads with delta RPMs in Fedora 11</title>
		<link>http://linsec.ca/blog/2009/09/08/save-time-on-downloads-with-delta-rpms-in-fedora-11/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=save-time-on-downloads-with-delta-rpms-in-fedora-11</link>
		<comments>http://linsec.ca/blog/2009/09/08/save-time-on-downloads-with-delta-rpms-in-fedora-11/#comments</comments>
		<pubDate>Tue, 08 Sep 2009 15:18:14 +0000</pubDate>
		<dc:creator>vdanen</dc:creator>
				<category><![CDATA[Red Hat]]></category>
		<category><![CDATA[fedora]]></category>
		<category><![CDATA[rpm]]></category>
		<category><![CDATA[techmail]]></category>

		<guid isPermaLink="false">http://linsec.ca/blog/?p=572</guid>
		<description><![CDATA[This week&#8217;s TechMail is Save time on downloads with delta RPMs in Fedora 11 which discusses the delta RPM feature in Fedora, how to set it up and use it, and why you would want to. Delta RPMs don&#8217;t make sense for everyone, but they will for quite a few people (i.e. low bandwidth situations [...]]]></description>
			<content:encoded><![CDATA[<p>This week&#8217;s TechMail is <a href="http://blogs.techrepublic.com.com/opensource/?p=904">Save time on downloads with delta RPMs in Fedora 11</a> which discusses the delta RPM feature in Fedora, how to set it up and use it, and why you would want to.  Delta RPMs don&#8217;t make sense for everyone, but they will for quite a few people (i.e. low bandwidth situations with decent processor speeds as opposed to high bandwidth and possibly lower processor speeds).  Regardless, delta RPMs are quite cool and I know at Mandriva we had wanted to do this years ago and it just never panned out, so it&#8217;s cool to see it working now.</p>
]]></content:encoded>
			<wfw:commentRss>http://linsec.ca/blog/2009/09/08/save-time-on-downloads-with-delta-rpms-in-fedora-11/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Converting new rpm databases to old format</title>
		<link>http://linsec.ca/blog/2009/01/30/converting-new-rpm-databases-to-old-format/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=converting-new-rpm-databases-to-old-format</link>
		<comments>http://linsec.ca/blog/2009/01/30/converting-new-rpm-databases-to-old-format/#comments</comments>
		<pubDate>Fri, 30 Jan 2009 20:33:43 +0000</pubDate>
		<dc:creator>vdanen</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[rpm]]></category>
		<category><![CDATA[urpmi]]></category>

		<guid isPermaLink="false">http://linsec.ca/blog/?p=393</guid>
		<description><![CDATA[I better post this before I forget about it. One of the issues I had today was getting corp3/x86_64 installed in a chroot with Mandriva 2009.0 as the host. Of course, the db4 version had changed, so I had to take advantage of some conversion tools. urpmi is supposed to do this magically, but it [...]]]></description>
			<content:encoded><![CDATA[<p>I better post this before I forget about it.  One of the issues I had today was getting corp3/x86_64 installed in a chroot with Mandriva 2009.0 as the host.  Of course, the db4 version had changed, so I had to take advantage of some conversion tools.  urpmi is supposed to do this magically, but it doesn&#8217;t seem consistent.  Anyways, the problem lies with 2009.0&#8242;s rpm using a newer version of the database than the older version.  For instance:</p>
<pre>
# file /var/lib/rpm/Packages
/var/lib/rpm/Packages: Berkeley DB (Hash, version 9, native byte-order)
# file /chroots/64/cs3/var/lib/rpm/Packages
/chroots/64/cs3/var/lib/rpm/Packages: Berkeley DB (Hash, version 8, native byte-order)
</pre>
<p>So the trick is to convert them from the new format to the old format, which is easy enough to do once you know <i>what</i> to do.  On the host (Mandriva 2009 in this case), make sure you have db46_utils and db42_utils installed:</p>
<pre>
# rpm -qa|grep "db.*\-utils"
db46-utils-4.6.21-9mdv2009.0
db42-utils-4.2.52-24mdv2009.0
</pre>
<p>Then you can use this rough-n-dirty script I wrote to convert them:</p>
<pre>
#!/bin/sh
#
# script to dump and reload the rpm db to convert from hash format 9 to format 8
# for older distribs (think cs3)

for i in $(ls -1); do
    if [ "`file ${i} | grep 9`" != "" ]; then
        db_dump ${i} >${i}.db46
        db42_load ${i}.db42 < ${i}.db46
        mv -f ${i} ${i}.org
        mv -f ${i}.db42 ${i}
    fi
done
</pre>
<p>That should fix the errors you would see in the chroot, plus make it so that rpm -qa and friends actually work.  </p>
]]></content:encoded>
			<wfw:commentRss>http://linsec.ca/blog/2009/01/30/converting-new-rpm-databases-to-old-format/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

