I'm planning a libsigsegv-2.9 (rawhide) update relatively soon which
includes an abi change. According to repquery, only the following
packages should be affected:
(I'll help take care of these requisite rebuilds)
devel-announce mailing list
I recently rebuilt a failing mail server (sendmail and cyrus-imapd), replacing the hardware and building the replacement machine offline (leaving the current server in place while I did so).
This would seem normal enough to do, but had some unintended pitfalls that really should be more addressable.
Because the new machine was built offline while the old machine was still in-place, all of the packages that generate certificates--and there are a fair number of them:
did so incorrectly. That is, they ended up using localhost.localdomain as the identity of the machine... and once I had the machine in place, I brought it up to find that various clients were now complaining about invalid certs.
So I had to dig through what had happened, why, and what needed to be done (or redone) to fix this.
Here are some observations and their accompanying conclusions.
* A lot of packages generate their certs silently as part of the %post scripting
This is certainly true of mod_ssl and cyrus-imapd.
* A lot of packages also provide default answers to the certificate fields:
# rpm -q --scripts mod_ssl
will get you:
at<< EOF | /usr/bin/openssl req -new -key /etc/pki/tls/private/localhost.key \
-x509 -days 365 -set_serial $RANDOM \
-out /etc/pki/tls/certs/localhost.crt 2>/dev/null
# rpm -q --scripts cyrus-imapd
/bin/cat<< EOF | make cyrus-imapd.pem
etc. It seems to be fairly common.
Openssl provides the script /etc/pki/tls/certs/make-dummy-cert, which contains the function answers():
which is used to pipe form data to "openssl req" when generating a new certificate request.
This seems to be duplicated in several places, and indeed some of the information could easily be captured statically at install time, and other data gleaned from the running system (such as the last two fields).
* The certificate fields should be consistent
The easiest way to do this is to have a standard file containing the first 5 fields above (C, ST, L, O, OU). This file could be populated by Anaconda/Kickstart during installation.
It's presence would then be a requirement for other packages that dynamically create certs at install time.
* A permanent or 'real' identity should be an RPM requirement
Packages should have the ability to have the system configured as its ultimate identity before being installed.
This could be accomplished by an RPM pseudo-requirement that some package generates (via Provides:) as part of its installation.
This could be the same package that provides the certificate "seed" information, but would also check to make sure that hostname, the domain, etc. were proper values.
* If a machine gets relocated, it should be able to re-seed its certificates
This last one is perhaps the most obscure change.
If I build a machine "offline", test it with a temporary identity, and decide its "ready for prime-time", I should be able to reboot it with its new identity, and manually re-run the RPM scripts (or some idempotent portion of them) that regenerates all of the identity-derived information... typically this would be based on hostname, domain, IP address, and the certificate seed information (C, ST, L, O, and OU).
We'd need a %post subsection that could be run idempotently to generate new certificates, for instance.
In the examples of the above packages (openssl, mod_ssl, cyrus-imapd, etc) new .crt, .key, or .pem files would be generated... the serial number incremented (where necessary), and the service restarted.
* This affects a lot more than just the packages that generate certs and keys
This also would affect rpm (and possibly yum as well), in addition to the Anaconda/Kickstart.
It might even be necessary to have a new package that runs early at boot time that checks packages (services) for "refreshed" certificates, and disables (chkconfig service off) any services that have out-of-date certificates/keys.
So how far into left field am I on this, anyway?
I was looking for a method to send text from a vim buffer to the system
clipboard. I came across this.
The fedora Vim package has clipboard facility disabled:
[ankurGuest@070905042 PhD]$ vim --version | grep -i clipboard
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info
Ubuntu apparently has a package vim-full where the clipboard facilities
etc. is enabled. Is there a similar package in Fedora? I'd really like
to stick to fedora packages. Is there a reason why this is turned off?
today I was very surprised that updating my F13 system required me to
install ~20 fonts packages. Digging around a bit showed me that change
in the java-1.6.0-openjdk package:
Can anyone tell me the reason for all these fonts dependencies?
I think it is not the business of packages to require specific fonts.
Fonts are something that should be entirely under control of the system
[Apologies if this has been covered before, but I cannot find anything
in the archives]
When building a package I noticed that binaries in the package were
still getting unnecessary DT_NEEDED entries. Example:
binary ---> depends only on libfoo.so
| libfoo depends on
but the binary was getting built with DT_NEEDED entries for both
'libfoo.so' and 'libbar.so', which is wrong.
ld had the '--no-add-needed' flag, so ld wasn't adding the extra
DT_NEEDED entry. (See:
I tracked this down to our old friend libtool. Basically because the
binary and the library were being built out of the same source tree,
there was a 'libfoo.la' file which contained:
and this causes libtool to decide to "helpfully" add -lbar to the
linker command line, even though it is completely unnecessary.
(This is not a problem if libfoo and the binary were in separate
source packages, because we already nuke the *.la files, which avoids
this brokenness across different packages. The problem is
specifically confined to the case where binaries and libraries are
built from the *same* source package).
I was able to work around this by adding a libtool wrapper which set
dependency_libs='' in the *.la file.
I notice that Debian, Ubuntu and Gentoo have proposed something
except they are unilaterally modifying libtool downstream instead of
using my hackish wrapper, which is a better idea. Apparently either
no one has tried to get this upstream, or libtool developers weren't
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
I have a collection of virtual machines that I use to test
cross-platform compatibility of some code I'm developing. Today, the
virtual machine I was working on kept getting slower and slower
whenever a window refresh was needed. It got to the point that
refreshing a terminal window was taking nearly half a second per line.
My eyes could easily track the refresh going on. Moving a window was
impossible, as I could see the entire window being redrawn, pixel by
pixel, and it would just keep going long after I had released the
mouse. Keys were repeating right and left, probably because of a
sequence like <KeyDown, refresh action that takes a really long time,
I shut everything down, logged out, and even rebooted, to see if it
was some weird behavior caused by a recent update that had only partly
taken effect. When I started my VM back up, it was very snappy. But
then, over time, it got a little slower and a little slower, until
eventually I was back to watching refreshes happen line by line again.
This never happened before today. I looked through the recent updates
my machine has received. All I can see that might be relevant was an
update to gtk-vnc-0.4.2-1.fc14.x86_64. The machine in question is a
quad-core Intel with 8GB of RAM and an Nvidia video card of some kind.
(Sorry, should have checked which one before leaving work.) The host
is fine; it's just the virtual machines I open with virt-manager that
are affected. I tried several, and they're all behaving like this
today, which argues for the problem being on the host side.
Is anybody else seeing this? Is there any other component besides
gtk-vnc that I should examine as a possible source of the slowdown?
thanks to great work of Daiki Ueno and Colin Watson, we are reintroducing
Japanese support in groff and therefore in manual pages!
Japanese was never supported by upstream. In the times of groff 1.18 (released
in February 2002), there were very huge and unmaintainable patches adding
Japanese. These were dropped with F13 and we switched to groff 1.20 (released
in January 2009).
groff-1.20.1-3.fc15 brings new set of patches created by Colin Watson, who
added character class support; and Daiki Ueno, who made groff to determine
glyph width using wcwidth(). Upstream has some remarks to these patches, but
we hope we manage to get them included.
I'm not aware of any other distribution using groff 1.20 with working
Japanese. Kudos to Fedora! ;-)
Base Operating Systems Brno
Red Hat Inc.