Friday 1st June 2007
Local Packages
Updated curl to include libcurl.m4 in the devel subpackage, as per the Fedora version
Fedora Project
Pushed perl-MailTools for inclusion in the Fedora 7 updates-testing repository
Built perl-MailTools for EPEL-4 and EPEL-5 by request of MikeMcGrath
Monday 4th June 2007
Fedora Project
Raised Bug #242480 regarding python-crypto failing to build on ppc64; my interest in this is that bittorrent requires python-crypto and hence had broken dependencies in the ppc64 release
Local Packages
I set up my buildsystem to create packages for Fedora 7, and to label Rawhide packages with the fc8 tag. I've tweaked my buildsys-build package to not require buildsys-macros for Fedora 7 onwards since the required rpm macros are now included in redhat-rpm-config
My biggest concern was what to do with the merged Core and Extras repository. For all previous releases, I used a loopback-mounted DVD ISO image as a local repository for the base OS, and grabbed extras packages over the network via a local squid cache (much as is described in PackageMaintainers/MockTricks).
In order to build arbitrary packages for Fedora 7, I need the Everything repository (the full merged Core and Extras set) in the mock configuration. However, I also want to speed things up by using packages from my local DVD image where possible. The difficulty here is that the DVD image contains the same packages as the Everything repository, and there's no documented way to get yum to pick packages from the DVD ISO first and only go to the network if the package isn't found there.
It does appear though that yum currently searches through repositories in order of repository ID (I realise that this may change without warning at any given moment...) so the following mock config is serving my needs for x86_64:
$ cat /etc/mock/fedora-7-x86_64.cfg #!/usr/bin/python -tt import os config_opts['root'] = 'fedora-7-x86_64' config_opts['target_arch'] = 'x86_64' config_opts['yum.conf'] = """ [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86 # repos [zzz-everything] name=zzz-everything baseurl=http://sunsite.mff.cuni.cz/MIRRORS/fedora.redhat.com/fedora/7/Everything/x86_64/os proxy=http://localhost:3128/ priority=1 protect=1 [local-media] name=local-media baseurl=file:///srv/nb/distros/fc7/os/x86_64 [updates-released] name=updates baseurl=file:///srv/nb/distros/fc7/updates/x86_64 [groups] name=groups baseurl=file:///srv/nb/distros/fc7/groups [city-fan.org] name=city-fan.org repository for Fedora 7 (x86_64) baseurl=file:///home/paul/cfo-repo/yum-repo/fc7/x86_64 enabled=0 """
(the priority and protect lines were copied from a similar arrangement that CentOS uses, but doesn't seem to have any effect)
Wednesday 6th June 2007
Local Packages
- Updated a large number of packages, particularly perl modules, that had not been updated during the Fedora 7 development cycle and hence hadn't been built with an appropriate dist tag to identify themselves to my repository-building script for Fedora 7
Updated perl-HTML-Tidy to 1.08, for recent distributions only. Older distributions had to stick with 1.06 because the new version uses some UTF8 functionality that older perls don't have. I was also bitten by CPAN RT#26875 on Fedora 7 due to incompatibility between recent versions of libtidy and HTML::Tidy, so the fact that my own libtidy packages are still made from the 20051025 snapshot was actually an advantage
Thursday 7th June 2007
Local Packages
Updated getmail to 4.7.5
Updated perl-IO-Socket-SSL to 1.07
I also had a hack at the repoclosure script from yum-utils so that I could check the repositories for each distribution much more quickly. The standard repoclosure script checks all of the packages in all of the enabled repositories to make sure that their dependencies can be satisfied. My repositories are small relative to the main distribution repositories, and the majority of the time it takes repoclosure to run is spent checking the main distribution repositories for dependency closure against themselves (and very often finds problems with them too). The problem is even worse on x86_64 with all of the multilib crap increasing the number of packages in the repos. However, I'm only actually interested in broken dependencies for packages in my own repositories, so most of the time spent by repoclosure is wasted for me.
My hack adds another option, --checkrepo, which works like the existing --repoid option, which specifies a repository that I'm interested in checking. Any other enabled repositories from the configuration file are used only to satisfy the dependencies and the packages there don't get their own dependencies checked. I'm seeing an order of magnitude improvement in checking times now, which is nice. Unfortunately my knowledge of python is very limited and hence it's a very horrible hack to get this working, and an unpleasant side effect is that I'm getting two copies of every logged message (i.e. every line of output) because I've now got two instances of the RepoClosure class rather than one. I can get rid of those using awk but I'd much rather find a cleaner solution. Must actually learn python someday.
Friday 8th June 2007
Local Packages
Updated gtkwave to 3.0.29; I'd intended to skip this release for Fedora as it didn't include the sample .gtkwaverc file, but after I reported this to Tony (gtkwave author), he reissued 3.0.29 with the missing file included
Fedora Project
Updated gtkwave to 3.0.29, but only for Rawhide; there are no user-visible fixes worthy of an update for earlier releases
Saturday 9th June 2007
Fedora Project
Updated lat in Rawhide due to a missing dependency on yelp, the Gnome Help Viewer (Bug #243403)
Allotment
- Dug up all of the Pentland Javelin new potatoes as their foliage had died down already; quite a decent crop and I'll enjoy eating them (had a few last week)
Monday 11th June 2007
Local Packages
Updated fetchyahoo to 2.10.8
Fedora Upgrade
Made a start on upgrading my home machines to Fedora 7. First up was my firewall/web/DNS/ftp/mail server machine, which I've set up to be able to run two different OS releases, with the data shared between them. I only had time to do the base Fedora 7 install, and the only point of interest really was that I needed the libata.ignore_hpa=1 hack (see Bugs/F7Common) to get the partition table on the smaller of my 80GB disks to be recognised.
I wanted a way to choose between the two OS releases at boot time. With grub having been installed on the MBR, I only had the option of booting into the new Fedora 7 installation. As a quick fix, I copied the Fedora Core 6 boot entries from the Fedora Core 6 version of /etc/grub.conf and appended them to the Fedora 7 /etc/grub.conf file. That gave me a way to get into Fedora Core 6. A more long-term fix was to have each OS release's version of grub able to load the other OS's version.
I added the following to the Fedora Core 6 /etc/grub.conf:
title Fedora 7 Boot Menu
rootnoverify (hd0,1)
chainloader +1and this to the Fedora 7 /etc/grub.conf
title Fedora Core 6 Boot Menu
rootnoverify (hd0,0)
chainloader +1I have disks on this system installed as pairs and everything mirrored (RAID1). The Fedora Core 6 /boot is the first partition of my first hard disk pair, and the Fedora 7 /boot is the second partition. All that was needed now was to install each OS release's version of grub into the /boot partition for that OS release and then my two grub versions would be able to load each other.
I used the standard RAID1 grub installation route:
On Fedora Core 6:
# grub grub> device (hd0) /dev/hda grub> root (hd0,0) grub> setup (hd0,0) grub> device (hd0) /dev/hdb grub> root (hd0,0) grub> setup (hd0,0) grub> quit
On Fedora 7:
# grub grub> device (hd0) /dev/sda grub> root (hd0,1) grub> setup (hd0,1) grub> device (hd0) /dev/sdb grub> root (hd0,1) grub> setup (hd0,1) grub> quit
Note that in Fedora 7 all disks are regarded as being SCSI disks, so the device names change (check /boot/grub/device.map too).
Wednesday 13th June 2007
Fedora Upgrade
My firewall/web/DNS/mail/everything server is now running live with Fedora 7, and I have to say it was fairly painless to get it going, mainly thanks to the detailed install notes I kept when I did a fresh install of Fedora 6 many months ago.
Biggest issue was probably the need to update the SELinux policy for mod_fcgid (and hence this wiki), which was broken due to its use of deprecated permissions names. I've now fixed that, plus incorporated a boolean for allowing FastCGI applications to send mail, something I've been meaning to do for at least six months. I'll need to issue a Fedora 7 update for mod_fcgid containing this fix, which I'll look at doing tomorrow. A prerequsite for that is figuring out the version of selinux-polcy-devel that is now required to build the policy module; I suspect it won't build on FC5 and maybe not FC6 either.
Friday 15th June 2007
Local Packages
Updated mod_fcgid to enhance the SELinux policy and allow mod_fcgid to actually work under SELinux on Fedora 7; I'm now including two versions of the fastcgi.te file in the SRPM and selecting the appropriate one for the target distribution at build time
Fedora Project
Updated mod_fcgid to be the same as the local package; unfortunately I tagged and built the Rawhide package before remembering to update the fastcgi.te (not used in Rawhide) and READNE.SELinux (just a doc) files. They're updated in CVS now and I don't think it's worth a bump and release just to fix these. The Fedora 7 package will be in updates-testing for a while so I'll hold off the Fedora Core 6 update until it emerges. I'm not going to do a Fedora Core 5 update because I don't have a Fedora Core 5 box to test it on any more.
Saturday 16th June 2007
Fedora Upgrade
Bit the bullet and upgraded my desktop/server/buildsystem machine from Fedora Core 6 to Fedora 7. The upgrade itself went OK until it was time to reboot. It wouldn't. I'd been bitten by Bug #242334, which resulted in my /etc/mdadm.conf having only one entry in it instead of the 6 it had originally. The result: no volume groups found at boot time. Having identified the problem, the fix was easy using the DVD in rescue mode, and the rest of the upgrade was relatively painless.
Monday 18th June 2007
Local Packages
Updated contagged to support building with included SELinux policy on RHEL5
Created php-Smarty packages for some older distributions that don't have it (needed for contagged)
Updated dovecot to 1.0.1 and merged in the change in the Rawhide version to put SQL support in DSOs and separate subpackages
I had a problem running repoview on Fedora 7:
ImportError: No module named elementtree.SimpleXMLWriter
This is Bug #232590. The quick workaround was to build and install the python-elementtree package from Fedora CVS, though it'll be removed courtesy of an obsolete as soon as a python update comes around. Hopefully there will be an update to repoview before then.
The recent pam update to version/release 0.99.7.1-5.1.fc7 caused failed dovecot logins due to SELinux denials:
type=AVC msg=audit(1182087900.637:32303): avc: denied { execute } for pid=25443 comm="dovecot-auth" name="unix_update" dev=dm-0 ino=384037 scontext=user_u:system_r:dovecot_auth_t:s0 tcontext=system_u:object_r:updpwd_exec_t:s0 tclass=fileThis was easily fixed in a local policy module and will apparently be fixed in selinux-policy 2.6.4-17 (Bug #244534).
Friday 22nd June 2007
Local Packages
Updated dkms to 2.0.17
Updated perl-YAML to 0.65
Merged the recent changes in Fedora's sendmail spec (mostly from feedback from my review) back into my own package; the current Fedora sendmail doesn't actually build on Rawhide due to the upgrading of m4 to version 1.4.9 - versions later than 1.4.8 return a non-zero exit code when a file to be included is not found, which breaks the sendmail build. I've fixed this locally and will feed it back into Fedora next week.
Merged in a curl patch from Rawhide that fixes Bug #236981 (curl prints like crazy)
Sunday 24th June 2007
Fedora Project
Requested mod_fcgid be moved from updates-testing (where it's been for a week) to updates for Fedora 7; updated the FC-6 version to the same package, although it builds a different SELinux policy on the older distribution
Monday 25th June 2007
Local Packages
Updated bittorrent to 5.0.8
Updated curl to 7.16.3
Updated perl-Net-DNS to 0.60
Updated ppp to update the bundled Fedora spec in the source package
Updated proftpd to add auditing modules to the PAM configuration where appropriate
Updated tidy to the same CVS snapshot from February that Fedora has
Whilst building these packages, I noticed a worrisome problem in the buildsystem: mock was occasionally failing to download a package needed as a build requirement for something, but this was not preventing it from attempting to build the package. I noticed because the missing build requirements caused the actual package build to fail, but that might not always happen, and a package built with reduced functionality might be the result instead.
I raised this on fedora-buildsys-list and was asked for an easy way to reproduce the problem, which I managed to find. It remains to be seen whether it's a mock or a yum problem. Something to watch out for when doing builds though.
Tuesday 26th June 2007
Local Packages
I noticed a comment by MatthiasSaou in his changelog for proftpd:
* Fri Jun 15 2007 Matthias Saou <http://freshrpms.net/> 1.3.0a-4 - Fix PAM entry for F7+ (#244168). Still doesn't work with selinux, though.
Given that I use both proftpd and SELinux without problems, I wondered what this was about. Anyway, I tried doing a non-anonymous login (something I don't normally do as I use sftp for that sort of thing), and I saw these SELinux denials in the audit log:
type=AVC msg=audit(1182852462.003:103279): avc: denied { write } for pid=23852 comm="proftpd" scontext=root:system_r:ftpd_t:s0 tcontext=root:system_r:ftpd_t:s0 tclass=key
type=AVC msg=audit(1182852462.003:103279): avc: denied { link } for pid=23852 comm="proftpd" scontext=root:system_r:ftpd_t:s0 tcontext=root:system_r:dovecot_t:s0 tclass=key
type=AVC msg=audit(1182852462.003:103280): avc: denied { audit_control } for pid=23852 comm="proftpd" capability=30 scontext=root:system_r:ftpd_t:s0 tcontext=root:system_r:ftpd_t:s0 tclass=capabilityI raised this on fedora-selinux-list and the requisite policy changes were made in CVS. For the time being, I added the following in a local policy module:
# Allow ftpd to set the login uid and create a session keyring
logging_set_loginuid(ftpd_t)
logging_send_audit_msg(ftpd_t)
allow ftpd_t self:key { write search link };I was then left with some remaining annoyances in /var/log/secure, such as:
Jun 26 12:09:42 goalkeeper proftpd: PAM audit_log_user_message() failed: Operation not permitted Jun 26 12:09:42 goalkeeper proftpd[25559]: goalkeeper.intra.city-fan.org (::ffff:192.168.2.20[::ffff:192.168.2.20]) - PAM(setcred): System error Jun 26 12:09:42 goalkeeper proftpd: pam_unix(proftpd:session): session closed for user paul Jun 26 12:09:42 goalkeeper proftpd[25559]: goalkeeper.intra.city-fan.org (::ffff:192.168.2.20[::ffff:192.168.2.20]) - PAM(close_session): System error Jun 26 12:09:42 goalkeeper proftpd[25559]: goalkeeper.intra.city-fan.org (::ffff:192.168.2.20[::ffff:192.168.2.20]) - FTP session closed.
To prevent these errors, proftpd needs to retain the CAP_AUDIT_WRITE capability when changing UID. It already has the facility to set capabilities (in mod_cap, enabled by default), but CAP_AUDIT_WRITE is not one of the capabilities handled by the module. I made a patch to support this and incorporated it into my local proftpd package (1.3.0a-5.2.CF). The result was the following messages for a session in /var/log/secure:
Jun 26 14:33:44 goalkeeper proftpd: pam_unix(proftpd:session): session opened for user paul by (uid=0) Jun 26 14:33:44 goalkeeper proftpd[30169]: goalkeeper.intra.city-fan.org (::ffff:192.168.2.20[::ffff:192.168.2.20]) - USER paul: Login successful. Jun 26 14:33:48 goalkeeper proftpd: pam_unix(proftpd:session): session closed for user paul Jun 26 14:33:48 goalkeeper proftpd[30169]: goalkeeper.intra.city-fan.org (::ffff:192.168.2.20[::ffff:192.168.2.20]) - FTP session closed.
Annoying error messages gone 
I passed the patch on to Matthias to see what he thinks; if all seems well, I'll forward it upstream too.
Thursday 28th June 2007
Local Packages
Updated perl-HTML-Tidy to build against the older version of libtidy in the repository (CPAN RT#26875)
Updated perl-XML-SAX to 0.16
Friday 29th June 2007
Local Packages
New package perl-Crypt-GPG
New package perl-IPC-Run (imported from Fedora)
New package perl-IO-Tty (imported from Fedora)