It has been almost a week and yet again the new rpm packages have not been updated for both webmin and usermin.
I keep harping about this simply for the fact that when we bought and install virtualmin the install script insisted on installing webmin from the urpmi repo.
If you are not going to update webmin and usermin in the repositories then please remove that from the install scripts. It is pointless to install a old version when a new one will be installed the minute you go check for updates.
I have repeated this over and over and yet it just does not sink in. Joe and Jamie please pay attention to detail and if it is to much to remember to make the rpm's then update the install script and remove that function. You can spend time making the rpm's for everything else but the core program and that is just...
I can't express how frustration this is on end-users.
Post edited by: sgrayban, at: 2007/08/07 15:14<br><br>Post edited by: sgrayban, at: 2007/08/07 15:18
Howdy Scott,
Was there some bug in Webmin 1.350 that you needed addressed quickly? I wasn't aware of any problems that effected Virtualmin users, and since I was traveling when 1.360 rolled out and unable to talk to my build/deploy system, I didn't rush it into the repositories (it has been released now, and re-signed just for our Mandriva user).
If you really like to stay on the cutting edge of Webmin/Usermin releases, it is perfectly safe to use the Webmin update facility--we use the same package in our repository as the one distributed at Webmin.com (though the signature is now the Virtualmin sig rather than Jamie's Webmin sig).<br><br>Post edited by: Joe, at: 2007/08/08 02:14
--
Check out the forum guidelines!
If I use the standard webmin update it will break my RPM install. I will have to totally uninstall webmin, usermin and virtualmin and re-install from the tarballs.
Not exactly ideal is it?
<div class='quote'>If I use the standard webmin update it will break my RPM install. I will have to totally uninstall webmin, usermin and virtualmin and re-install from the tarballs.</div>
Why would it do that?
What's in /usr/libexec/webmin/install-type on your system?
--
Check out the forum guidelines!
If I don't remove the RPM's then when I install the tarball and you or Jamie make a new rpm for the versions then I'll have 2 copies on my drive. One that will be either old or new since neither will delete the other.
And all my plugins are installed through the rpm repo as well.
<div class='quote'>If I don't remove the RPM's then when I install the tarball and you or Jamie make a new rpm for the versions then I'll have 2 copies on my drive. One that will be either old or new since neither will delete the other.</div>
Whoah! Don't install tarballs! There's an RPM at Webmin.com (the same one we distribute, only ours here at Virtualmin.com is now re-signed), which you can easily use to upgrade. If you use the Upgrade Webmin form in Webmin Configuration, it'll get the right package for your automatically. No need to uninstall anything. Uninstalling would be a horrible horrible thing (you'd lose tons of Virtualmin meta-data). ;-)
--
Check out the forum guidelines!
Now if you try to install virtualmin pro clean, it blows up because of the Webmin 1.360.
That's not good....
<div class='quote'>Now if you try to install virtualmin pro clean, it blows up because of the Webmin 1.360.</div>
Crap. Something is wrong with the signature. Argh. I'm working on it. Re-signing the package seems to have confused something somewhere.
--
Check out the forum guidelines!
OK, so the original Webmin packages are built with an ancient version of RPM (3.0.mumble). I can't even believe Jamie still has a system old enough to run RPM 3, but he does. Anyway, I've now rebuilt the Webmin and Usermin packages from SRPM, signed them with our Virtualmin key, and added them to the repository with version 1.360-2 and 1.290-2. All should be well now. That turned out to be way more complicated than I expected.
--
Check out the forum guidelines!
I was wondering why the rpm's required rpm3 instead of rpm4 ....
Because packages built with RPM 4 won't install on a system that has RPM 3, while packages built with RPM 3 will install on a system with RPM 4. Webmin runs on every Linux distribution known to man, including some that are very old (but amazingly still in use--just the other day, there was a post on the Webmin forums about using Virtualmin and Webmin on Red Hat 7.2).
It's a valid practice. It just turned my head inside out trying to figure out why I couldn't sign the damned things. ;-)
--
Check out the forum guidelines!
lol errors or --sign wasn't working ?
Worse than either.
Watch this:
[joe@delilah universal]$ rpm --checksig -v wbt-virtual-server-theme-4.4-1.noarch.rpm
wbt-virtual-server-theme-4.4-1.noarch.rpm:
Header V3 DSA signature: OK, key ID a0bdbcf9
Header SHA1 digest: OK (0b1ca402687aea7dd9ddb036c1a945158593bd94)
MD5 digest: OK (5530b6016a1de20a7b283f6217db84a5)
V3 DSA signature: OK, key ID a0bdbcf9
So, we see that key ID a0bdbcf9 is valid and in the RPM key database. Cool.
Now, lets see what happens when we try to checksig the resigned Webmin package:
[joe@delilah universal]$ rpm --checksig -v webmin-1.360-1.noarch.rpm
webmin-1.360-1.noarch.rpm:
Header V3 DSA signature: NOKEY, key ID a0bdbcf9
MD5 digest: OK (7d2448200c6da7974cbe4b4f0817b3e4)
V3 DSA signature: OK, key ID a0bdbcf9
That NOKEY error is what you get when you don't have the key imported into RPM. And yet, we know it has been imported because the other package signed with it is "OK". Oh, wait, and so is the V3 DSA signature on the same package! That's just nasty.
Basically re-signing the packages silently failed (but also managed to remove Jamie's existing signature, so it didn't work for anyone, anymore). Now, I'll be rebuilding our Webmin/Usermin with a modern version of RPM, so I can sign them with a modern version of RPM. The other option is to off-load the extra signing to Jamie, but I think it's better to keep all repository maintenance on one box.
--
Check out the forum guidelines!
Oh that isn't good -- But I bet he signed that with the rpm3 version which has a nasty bug when resigning the package.
Actually he made me one that wasn't signed during the ordeal--that wasn't the problem. That was my first assumption, as well. RPM 3 allowed adding signatures to an already signed package, which freaks out modern package management tools like yum. But RPM 4 is supposed to remove all existing sigs and re-sign. But the old package format is seemingly just not quite compatible with modern signatures.
No worries...now that I've figured it out. It's just one more step in my ever growing list of "things to do to maintain the repositories" (crazy long at this point, but I'm automating some of it away).
--
Check out the forum guidelines!
RPM security has gotten more strict with version 4. That's a good thing though.