Greetz,

How can I determine which version of a particular package my Red Hat system is running based on the patch level of a particular RPM?

For instance, on *BSD systems and other GNU/Linux systems that I administer, I generally find a package that has been fully updated parallel to the vendor's package version. Take for example OpenSSH; the current version from the vendor is 3.7.1. On my slackware 9 box, I am running 3.7.1 and therfore I know that my openssh version is up to date. I can also telnet to port tcp/22 on the server and see the banner report 3.7.1 to me. On my OpenBSD 3.3 box, I have updated openssh via CVS and rebuilt it, and now telnet'ing to the tcp/22 reveals that I am running 3.7.1

However on Red Hat, I am running some convoluted patch version of the 3.1 (openssh-server-3.1p1-10, to be exact.) Now I realize that this is 3.1p1 patched up to patch level 10, but telnet'ing to this port says I am running 3.1, and I can't quite map the patch level to the vendor's release version to determine if this box is up to date. 2 months down the road from now, how will I know which vulnerabiliities I am patched against given the patch level?

How can I work this out?

openssh-server-3.1p1-10, to be exact.
Can I first ask you what compelling reasons you have to keep a way old version of SSH loaded? Even if you can't check out the patch level, there's no excuse for updating: building the rpm's from the current OpenSSH/portable tarball is a no-brainer.
Don't mix up your priorities.

My inclination is to do just that, and in the past that's precisely what I've done. It seems that sometimes though, Red Hat is a little ahead in producing updated binary RPMs than the obsd team is in producing a src RPM.

The other reason is in keeping things in order with up2date; for instance, new 3.1.x-x rpms will not apply over a built-from-source 3.6.1 RPM because it sees the higher version as being newer. So for standardizing on up2date as a method of updating the system, one is still left in the same rut.