On Thu, 12 Dec 2019 at 05:28, Matthew Blissett <mbliss...@gbif.org> wrote: > > On 13/11/2019 20:44, Stephen John Smoogen wrote: > > On Tue, 12 Nov 2019 at 17:06, Ingvar Hagelund <ingvar(a)redpill-linpro.com> > > wrote: > >> 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? > > This was discussed at today's EPEL meeting and approved. Please push > > this to epel-testing and let users know in any tickets that it can be > > used there. After that, push to stable after regular feedback time. > As anticipated by Ingvar, this update broke my production systems. > > The EPEL site [1] says > > > it is possible that occasionally an incompatible update will be released > > such that administrator action is required. By policy these are announced > > in advance in order to give administrators time to test and provide > > suggestions. > > > > It is strongly recommended that if you make use of EPEL, and especially > > if you rely upon it, that you subscribe to the epel-announce list. > > Traffic on this list is kept to a minimum needed to notify administrators > > of important updates. > > This update wasn't announced there -- is that an oversight, or should I > change my approach to updates to account for possible incompatible > updates in the future? >
So by policy an update should have been announced to epel-announce. It wasn't, it was an oversight but there isn't anything we can do about that :(. This is very much a volunteer effort and things like this will happen. I apologize for the problems it caused you, and will reword that paragraph however it should be. > Thanks, > > Matthew Blissett > > [1]https://fedoraproject.org/wiki/EPEL#Can_I_rely_on_these_packages.3F > > _______________________________________________ > 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 -- Stephen J Smoogen. _______________________________________________ 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
