When you install an update to a package on an RPM-based system, any configuration files which were originally distributed by the package and that have been changed are not replaced when the package is updated. Instead, rpm creates a new file with the extention ".rpmnew". It is then necessary to manually compare the existing file and the new one and decide how to deal with the new file.

So, the pattern I often need to use is "list all .rpmnew files and the corresponding original file". This is not a particularly complex issue, but is one that I don't use often enough to have at my fingertips. The trick is bash variable substitution; specifically pattern matching: ${variable%pattern}. This deletes the shortest possible match for pattern from the right of the contents of $variable.

An example using .rpmnew files created when upgading OpenNMS:

# ls -1 *.rpmnew| while read f ; do ls -l ${f%\.rpmnew}* ; done
-rw-rw-r-- 1 root root 7285 Jun  3 12:43 database-reports.xml
-rw-rw-r-- 1 root root 8232 Aug 10 19:01 database-reports.xml.rpmnew
-rw-rw-r-- 1 root root 333092 Aug 25 09:25 datacollection-config.xml
-rw-rw-r-- 1 root root 314141 May 11 01:31 datacollection-config.xml.rpmnew
-rw-rw-r-- 1 root root 3395 Jun  3 12:43 jasper-reports.xml
-rw-rw-r-- 1 root root 3664 Aug 10 19:01 jasper-reports.xml.rpmnew
-rw-rw-r-- 1 root root 25887 Aug 10 19:01 log4j.properties
-rw-rw-r-- 1 root root 25887 May 11 01:31 log4j.properties.rpmnew
-rw-rw-r-- 1 root root 19319 Apr 22 16:56 opennms.properties
-rw-rw-r-- 1 root root 19635 Aug 10 19:01 opennms.properties.rpmnew
-rw-rw-r-- 1 root root 9252 Apr 22 16:59 rrd-configuration.properties
-rw-rw-r-- 1 root root 9604 May 11 01:31 rrd-configuration.properties.rpmnew
-rw-r--r-- 1 root root 669444 Jun  3 13:51 snmp-graph.properties
-rw-rw-r-- 1 root root 604457 Aug 10 19:01 snmp-graph.properties.rpmnew

One of my clients uses Tripp Lite  PDUMH20AT power distribution units. They are rather primitive, and upgrading firmware on the management cards is done via ftp; you start an ftp session, upload the firmware image and the device reboots when you quit.

I recently ran into problems with the ftp sessions – I could connect OK, but any attempt to transfer files would fail.

It turns out the ftp server on the devices can't do passive ftp, only active. The fix is simple – issue the "passive" command before uploading the firmware image. Of course, this means it won't work very well through a firewall/NAT router, but that's not a problem as I do the upgrades from a local machine.

The full session looks something like this:

[root@a001 Files4step2]# ftp 8.pdu.a
Connected to 8.pdu.a (
220 NET+ARM FTP Server 1.0 ready.
Name (8.pdu.a:root): admin
331 User admin OK, send password.
230 Password OK.
Remote system type is NET+ARM.
ftp> bin
200 Type set to I.
ftp> passive
Passive mode off.
ftp> put rom.bin
local: rom.bin remote: rom.bin
200 PORT command Ok.
150 About to open data connection.
226 Transfer complete
2109474 bytes sent in 2.35 secs (8.8e+02 Kbytes/sec)
ftp> put pwralert.dat
local: pwralert.dat remote: pwralert.dat
200 PORT command Ok.
150 About to open data connection.
226 Transfer complete
679080 bytes sent in 0.793 secs (8.4e+02 Kbytes/sec)
ftp> bye
221 Goodbye.