[EPEL-devel] Incompatible upgrades: Upgrading varnish in epel7
Varnish is a web cache. It is extremely fast, reliable, modern, and programmable. It may also be used as a level-7 router or swiss army knife. I maintain the varnish package in Fedora and EPEL. epel7 has varnish-4.0.5. The varnish-4.0.x branch reached end of life in 2017. Current supported LTS version of varnish is 6.0.x, which Red Hat has adopted for el8, and probably el9 too. The latest 7.0.x is in rawhide. There is a security vulnerability http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23959 in all previous versions of varnish. It is fixed in the latest releases (6.0.10, 6.6.2, 7.0.2), see https://varnish-cache.org/security/VSV8.html . Red Hat has classified their security update for el8 as "Important", https://access.redhat.com/errata/RHSA-2022:0418 . Upstream has not shown any interest in supporting the EOLed 4.0 branch of Varnish, and backporting the fix to 4.0.5 is non-trivial, as much of that part of the code has been changed and rearranged since 4.0 was active. There does exist a mitigation (with a performance hit) that may be added by the varnish configuration language (VCL), see the VSV8 page for details. It seems to work also for varnish-4.0. At least, the mitigation VCL snippet compiles on varnish-4.0.5. Providing security for EPEL7 users: * Force mitigation: It will be very difficult, not to say impossible, to automatically enforce the mitigation in VCL. A valid VCL configuration may be split over many files, and is compiled in the order it is read. Doing tricks like adding the mitigation in an extra VCL file may break working setups. * Provide a new package with the current LTS version: One solution may be to provide a new package "varnish60" or similar, and in some way giving users a warning if they continue using varnish- 4.0, pushing them towards the new package and documentation. * Upgrade varnish to the current 6.0.x LTS This will break the rule about keeping the API/ABI stable ABI: It is possible to build external binary compiled varnish modules (vmods) that are loaded into varnish via VCL. They are closely bound to the varnish version, so any vmod that is built for a particular version of varnish must be rebuilt for another. There are ABI changes from 4.0 to 6.0, so any custom built vmods may have to be refactored to match the new ABI. I have not found any vmods in epel7, though there exists external repos that does this, for example my own https://copr.fedorainfracloud.org/coprs/ingvar/varnish40/packages/ API: Varnish' configuration language VCL is versioned. varnish-4.0.x supports VCL version 4.0. Varnish-6.0.x LTS uses VCL-4.1 by default, but does support 4.0, possibly with a few changes. Upgrading should be quite easy for most users. Many setups will just work without changes. But it is not trivial as in "may be automated by a script". Or perhaps it is? To test properly this would need a lot of varnish-4.0 users to volunteer to test. I'd like EPEL's advice on how to proceed on this. br, Ingvar Hagelund ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] hitch is broken in epel7, fix in fedora may or may not break production systems (bz #1731420)
Hello hitch is a TLS terminating network proxy, made to be lean and mean and do nothing else than terminating TLS. It fits hand-in-glove with varnish cache. I maintain hitch in Fedora and EPEL. There is a bug in the current epel7 config that is fixed in the latest rawhide update. In short, the bug is that with the default config, hitch forks a daemon, while the systemd hitch service says Type=simple. See Bugzilla bug #1731420. The fedora update fixes the problem by changing the systemd service to Type=forking. There were two ways to get around the bug: - Set daemon=off in hitch.conf. That file is marked with noreplace, so the update will not overwrite this fix. As this does not match the updated Type=forking in hitch.service, hitch will not start after the update. - Set Type=forking in hitch.service. This is the same fix as in the update, so this should be safe. Also, the Fedora update adds a systemd limits.conf including LimitNOFILE=10240 that is important, as the default value (1024) would trig network problems on a medium busy site (true story). Is it safe to push this update to epel7? Ingvar ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Please test varnish-6.0.4-2.fc29
I just submitted a Bodhi update for varnish-6.0.4-2.fc29, [ https://bodhi.fedoraproject.org/updates/FEDORA-2019-8a85a90af6 | https://bodhi.fedoraproject.org/updates/FEDORA-2019-8a85a90af6 ] It fixes a medium risk security update, VSV3 aka CVE-2019-15892. Please test and add karma. br, Ingvar Hagelund ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: LD_LIBRARY_PATH vs rpath and libtool
> On Thursday, March 28, 2019 11:58:21 AM CET Ingvar Hagelund wrote: > > Fedora prohibits the use of rpath (...) to., 28.03.2019 kl. 13.27 +0100, skrev Pavel Raiskup: > With new enough libtool script, you can use this instead: > > %configure LT_SYS_LIBRARY_PATH=%_libdir > > or if that makes sense in your case: > > %configure LT_SYS_LIBRARY_PATH=%_libdir: Great, thanks. This seems to work well. Should I just get rid of the old sed edit of libtool then? make check works fine with just adding the variable to configure, and I no longer get warnings about rpath from mock/rpmbuild. Or should I keep the the sed hack, while changing it to use "LT_SYS_LIBRARY_PATH" instead of "DIE_RPATH_DIE" > This is unfortunately needed because it is not easy to detect whether > the linker uses /usr/lib64 path by default. Ideas? Libtool attempts > to parse ld.so.conf & friends, but the desired info isn't there Make rpm put %_libdir in something like /etc/ld.so.conf.d/libtool.conf , is that too intrusive? > > I have gotten around this by putting in LD_LIBRARY_PATH where I > > need, but rpmlint gives me a warning on that. > > Can you post the warnings? I've been using LD_LIBRARY_PATH in %check > for quite some time [1], and rpmlint did not complain... Ah, this is fixed now in fedora. Great! Ingvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
LD_LIBRARY_PATH vs rpath and libtool
Fedora prohibits the use of rpath, ref https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath When compiling varnish with litbool, I ensure this by the usual sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g; s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool However, during build and check, I need access to a library in the build. For example, the test suite uses the binary varnishtest to access libvarnishapi.so.2, which is not visible as the package is not installed yet. I have gotten around this by putting in LD_LIBRARY_PATH where I need, but rpmlint gives me a warning on that. Are there other possibilities to solve this? Ingvar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Rebuild bro and blender (Was: [HEADS-UP] jemalloc-4.0.0 for rawhide, please test)
jemalloc-4.0.0 was pushed to rawhide a few days ago. Some of the packages mentioned below have been rebuilt already. bro and blender remains to be rebuilt. It would be great if a provenpackager or the package owners could rebuild them. Thanks, Ingvar - On Aug 20, 2015, at 8:54 AM, Ingvar Hagelund <ing...@redpill-linpro.com> wrote: > I'm about to push jemalloc-4.0.0 for rawhide. Scratch builds for f23 and > f24 are available here: > http://users.linpro.no/ingvar/jemalloc/4.0.0/ > There are a few packages that requires jemalloc, and they should be > recompiled and tested against the new package. > $ repoquery --whatrequires jemalloc |\ > sed 's,\(.*\)-.*-.*,\1,g;' | sort | uniq > blender > blenderplayer > bro > gridengine > gridengine-execd > gridengine-qmaster > gridengine-qmon > jemalloc-devel > nfs-ganesha > nfs-ganesha-ceph > nfs-ganesha-gluster > nfs-ganesha-proxy > nfs-ganesha-utils > nfs-ganesha-vfs > nfs-ganesha-xfs > redis > varnish > Please report back any problems or comments. > Ingvar > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADS-UP] jemalloc-4.0.0 for rawhide, please test
I'm about to push jemalloc-4.0.0 for rawhide. Scratch builds for f23 and f24 are available here: http://users.linpro.no/ingvar/jemalloc/4.0.0/ There are a few packages that requires jemalloc, and they should be recompiled and tested against the new package. $ repoquery --whatrequires jemalloc |\ sed 's,\(.*\)-.*-.*,\1,g;' | sort | uniq blender blenderplayer bro gridengine gridengine-execd gridengine-qmaster gridengine-qmon jemalloc-devel nfs-ganesha nfs-ganesha-ceph nfs-ganesha-gluster nfs-ganesha-proxy nfs-ganesha-utils nfs-ganesha-vfs nfs-ganesha-xfs redis varnish Please report back any problems or comments. Ingvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Native vagrant packages for Fedora
Vagrant offers scripted provisioning and deployment of virtual instances, removing the infamous but it works om my laptop obstacle. Vagrant is well-known and much used and praised in the devops community. Its home page is http://vagrantup.com/ Though VirtualBox is the current supported target, future versions of vagrant may support other hypervizors as well, including kvm. Being in itself free software under the MIT license, I think vagrant could be included in fedora. While an upstream rpm exists (putting all dependent packages in /opt) a native fedora package of vagrant was missing. So I wrapped one up. Review request: https://bugzilla.redhat.com/show_bug.cgi?id=905396 It depends on the following packages missing from fedora 18: rubygem-log4r = 1.1.9 2.0.0 Fix: Build new package. Package review request: https://bugzilla.redhat.com/show_bug.cgi?id=905240 rubygem-childprocess =0.3.1 0.4.0 (0.3.6 in rawhide) Fix: Grab 0.3.6 package from rawhide rubygem-json = 1.5.1, 1.6.0 (1.6.5 in f18, 1.9.1 in rawhide) Fix: Build rubygem-json15, roughly based on current package. Package review request: https://bugzilla.redhat.com/show_bug.cgi?id=905389 rubygem-net-ssh = 2.2.2 2.3.0 (2.2.1 in rawhide) Fix: Build 2.2.2 package based on current package. Update request: bz https://bugzilla.redhat.com/show_bug.cgi?id=905393 yum repo with prebuilt packages for f17 and f18 available here: http://users.linpro.no/ingvar/vagrant/ Ingvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please test varnish-2.1.0-2 for F-13
I think it's important that varnish-2.1.0-2.fc13 is included in F-13, and hope that it's not too late. It was submitted by bodhi today, and can also be downloaded from koji. Please test the update and give feedback through bodhi. Snipped from the bodhi update request: Details Upgrade to new upstream release 2.1.0. This upgrade is important because * The previous 2.0 series will be discontinued within the lifetime of F-13 * 2.1.0 contains a fix for CVE-2009-2936. It is not probably that upstream will backport this fix for the 2.0 series These changes should be important enough to include varnish-2.1.x in F-13, even after the freeze. Ingvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-up: Configuration language changes in new varnish version
varnish is a high performance http accellerator. I'm just to tag and build the new upstream version 2.1.0 of varnish. This new version has a change in the vcl configuration language that may need changes to existing vcl code. If you are using varnish, please read the release notes carefully., http://varnish-cache.org/wiki/changelog_2.0.6-2.1.0 Ingvar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
