Re: [Klara FreeBSD #2159] Second bug in our web server: mod_perl2 Apache2::Upload upload method silently dies
Alex Aminoff <[email protected]> Tue, 22 Jul 2025 12:10:22 -0400
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------3YgzDQw32gFX6UvaBbqd006V Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I am very sorry, I did not remove [email protected] from my email to Klara systems. This was not intended for the list. To answer your question, I don't want to compile and install from source, although I could, I would prefer to use the FreeBSD ports / packages system. On 7/22/25 12:01, [email protected] wrote: > Why is effort being put into patching libapreq2 v2.17 when simply > compiling v2.18 from source already solves the problems? > > > We now know how to fix this problem. The installation I have for testing mixes > > packages from poudriere and ports installed from /usr/ports, which is not best > > practice. The question is how to apply a fix in production in the "right" way? > > > > A) make a poudriere based on an older snapshot of the ports tree that includes > > libapreq2 version 2.16. I am 85% sure that the bug was introduced in 2.17. > > Build only the libapreq2 package (which unfortunately has a lot of > > dependencies, including Apache itself), then have a repo pointing to that with > > priority higher than FreeBSD default "Latest" as well as higher than our own > > current "Latest" poudriere. The problem with this approach is we will end up > > with an older version of Apache and a lot of other important packages. > > > > B) Klara convinces [email protected] (mailto:[email protected]) to put out an > > official upgrade in the ports tree version 2.17_1 with the patch that Xavier > > created > > > > C) We create a poudriere with Xavier's patch applied to libapreq2, or rather > > apply the patch to our existing "default" poudriere. I don't know how to do > > that, but it seems like a use case poudriere must have been designed for. > > > > D) I use my existing mix of ports & packages in prod, perhaps with some pkg > > lock, on the grounds that we know it works and we can roll forward to a better > > solution when one comes out soon. I have done worse things in the past. > > > > I hope this makes sense. > > > > - Alex > > > > > > On 7/18/25 19:31, Alex Aminoff wrote: > > > > I did this, and I believe it has fixed the problem! > > > > You can test this here > > > > http://backdev.nber.org/uploadtest > > > > What I did was apply your patch in /usr/ports on our diskless root > > FreeBSD-14.2-root-202507, after running make extract in www/libapreq2. Then > > I had to re-compile in ports mod_perl and p5-libapreq2 and some other > > stuff, and install those from ports. > > > > root@bsdalt:/usr/ports/www/p5-libapreq2 # pkg info | grep apreq > > libapreq2-2.17_1 Generic Apache2 Request Library > > p5-libapreq2-2.17 Perl binding for the Generic Apache2 Request Library > > > > Now the next question is what is the best way to have this "in production". > > Can we apply your patch in some sensible way on poudriere? Or will you > > contact the libapreq2 maintainers and try to get it accepted there? > > > > Also, there is now a weird problem where /usr/local/etc/rc.d/apache24 > > always takes a really long time to run, like a minute. I need to track down > > what is slowing it down. > > > > - Alex > > > > > > On 7/18/25 02:22, Xavier Beaudouin wrote: > > > > Hello Alex, > > I made a try to integrate the 3 commits into current port. > > Can you have a try on your side, with the following patch (from current > > port tree)? > > Kind regards,/Xavier > > > > Le 18 juil. 2025 à 03:06, Alex Aminoff > > <[email protected]> (mailto:[email protected]) > > a écrit : > > Ticket URL: > > https://support.klarasystems.com/Ticket/Display.html?id=2159 (https://support.klarasystems.com/Ticket/Display.html?id=2159) > > > > I did a bit of googling and found this unfortunately rather > > vitriolic thread > > > > https://lists.apache.org/[email protected]:2024-2:apreq > > > > I could not quite follow which of those people if any are the > > nominal maintainers of apreq. Patches to the current version might > > be a way forward. OTOH maybe the maintainers of the FreeBSD port > > know some of those people or are some of those people and are aware > > of or involved in the politics? > > > > - Alex > > > > > > On 7/17/25 15:58, Allan Jude wrote: > > > > There only appear to be 3 changes since 2.17, all from 2023. > > > > The first one talks specifically about a regression in 2.17, > > and restoring the behaviour from 2.16 > > > > Might be the one > > > > > > Allan Jude > > -- > > Principal Solutions Architect @ Klara Inc. > > W: klarasystems.com (https://klarasystems.com/) > > M: +1 289-260-5944 > > > > > > On 2025-07-17 3:54 p.m., Kyle Evans wrote: > > > > Ticket URL: > > https://support.klarasystems.com/Ticket/Display.html?id=2159 (https://support.klarasystems.com/Ticket/Display.html?id=2159) > > > > Hi, > > > > If we knew which commits from libareq2 fix it, we could try > > to convince the port maintainer to accept them as patches > > to the current version if they don't want to hop to a > > snapshot of a development version -- assuming the patches > > aren't incredibly invasive. > > > > Thanks, > > > > Kyle Evans > > > > On 7/17/25 14:52, Alex Aminoff wrote: > > > > Ticket URL: > > https://support.klarasystems.com/Ticket/Display.html?id=2159 (https://support.klarasystems.com/Ticket/Display.html?id=2159) > > > > On 7/17/25 15:23, Alex Aminoff wrote: > > > > > > Meanwhile I will try wrapping upload() in an eval. > > > > > I tried this, and it is successful in that it returns control to the > > perl code, but the result of the upload call is undef. As I demonstrated > > in my initial post, if there are multiple file fields, any of them being > > un-filled triggers the bug, so I can not get the info for the file the > > user actually uploaded. > > > > Therefore one possible way forward will indeed be to download the > > bleeding edge libapreq2 from source and compile and install it. I can do > > that, or you could. But please if you can do some more investigation first. > > > > - Alex > > > > > > > > -- > > Kyle Evans > > FreeBSD Engineering Manager, Klara Inc. > > > > > > Xavier Beaudouin-System Engineer @ Klara Inc.W: klarasystems.com (http://klarasystems.com) > > > > > > > Randolf Richardson, CNA [email protected] > Inter-Corporate Computer & Network Services, Inc. > Beautiful British Columbia, Canada > https://www.inter-corporate.com/ > > --------------3YgzDQw32gFX6UvaBbqd006V Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>I am very sorry, I did not remove <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> from my email to Klara systems. This was not intended for the list.</p> <p>To answer your question, I don't want to compile and install from source, although I could, I would prefer to use the FreeBSD ports / packages system. <br> </p> <p><br> </p> <div class="moz-cite-prefix">On 7/22/25 12:01, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <pre style="white-space: pre-wrap; font-family: monospace;"> Why is effort being put into patching libapreq2 v2.17 when simply compiling v2.18 from source already solves the problems? > We now know how to fix this problem. The installation I have for testing mixes > packages from poudriere and ports installed from /usr/ports, which is not best > practice. The question is how to apply a fix in production in the "right" way? > > A) make a poudriere based on an older snapshot of the ports tree that includes > libapreq2 version 2.16. I am 85% sure that the bug was introduced in 2.17. > Build only the libapreq2 package (which unfortunately has a lot of > dependencies, including Apache itself), then have a repo pointing to that with > priority higher than FreeBSD default "Latest" as well as higher than our own > current "Latest" poudriere. The problem with this approach is we will end up > with an older version of Apache and a lot of other important packages. > > B) Klara convinces <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> (<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>) to put out an > official upgrade in the ports tree version 2.17_1 with the patch that Xavier > created > > C) We create a poudriere with Xavier's patch applied to libapreq2, or rather > apply the patch to our existing "default" poudriere. I don't know how to do > that, but it seems like a use case poudriere must have been designed for. > > D) I use my existing mix of ports & packages in prod, perhaps with some pkg > lock, on the grounds that we know it works and we can roll forward to a better > solution when one comes out soon. I have done worse things in the past. > > I hope this makes sense. > > - Alex > > > On 7/18/25 19:31, Alex Aminoff wrote: > > I did this, and I believe it has fixed the problem! > > You can test this here > > <a class="moz-txt-link-freetext" href="http://backdev.nber.org/uploadtest">http://backdev.nber.org/uploadtest</a> > > What I did was apply your patch in /usr/ports on our diskless root > FreeBSD-14.2-root-202507, after running make extract in www/libapreq2. Then > I had to re-compile in ports mod_perl and p5-libapreq2 and some other > stuff, and install those from ports. > > root@bsdalt:/usr/ports/www/p5-libapreq2 # pkg info | grep apreq > libapreq2-2.17_1 Generic Apache2 Request Library > p5-libapreq2-2.17 Perl binding for the Generic Apache2 Request Library > > Now the next question is what is the best way to have this "in production". > Can we apply your patch in some sensible way on poudriere? Or will you > contact the libapreq2 maintainers and try to get it accepted there? > > Also, there is now a weird problem where /usr/local/etc/rc.d/apache24 > always takes a really long time to run, like a minute. I need to track down > what is slowing it down. > > - Alex > > > On 7/18/25 02:22, Xavier Beaudouin wrote: > > Hello Alex, > I made a try to integrate the 3 commits into current port. > Can you have a try on your side, with the following patch (from current > port tree)? > Kind regards,/Xavier > > Le 18 juil. 2025 à 03:06, Alex Aminoff > <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> (<a class="moz-txt-link-freetext" href="mailto:[email protected]">mailto:[email protected]</a>) > a écrit : > Ticket URL: > <a class="moz-txt-link-freetext" href="https://support.klarasystems.com/Ticket/Display.html?id=2159">https://support.klarasystems.com/Ticket/Display.html?id=2159</a> (<a class="moz-txt-link-freetext" href="https://support.klarasystems.com/Ticket/Display.html?id=2159">https://support.klarasystems.com/Ticket/Display.html?id=2159</a>) > > I did a bit of googling and found this unfortunately rather > vitriolic thread > > <a class="moz-txt-link-freetext" href="https://lists.apache.org/[email protected]:2024-2:apreq">https://lists.apache.org/[email protected]:2024-2:apreq</a> > > I could not quite follow which of those people if any are the > nominal maintainers of apreq. Patches to the current version might > be a way forward. OTOH maybe the maintainers of the FreeBSD port > know some of those people or are some of those people and are aware > of or involved in the politics? > > - Alex > > > On 7/17/25 15:58, Allan Jude wrote: > > There only appear to be 3 changes since 2.17, all from 2023. > > The first one talks specifically about a regression in 2.17, > and restoring the behaviour from 2.16 > > Might be the one > > > Allan Jude > -- > Principal Solutions Architect @ Klara Inc. > W: klarasystems.com (<a class="moz-txt-link-freetext" href="https://klarasystems.com/">https://klarasystems.com/</a>) > M: +1 289-260-5944 > > > On 2025-07-17 3:54 p.m., Kyle Evans wrote: > > Ticket URL: > <a class="moz-txt-link-freetext" href="https://support.klarasystems.com/Ticket/Display.html?id=2159">https://support.klarasystems.com/Ticket/Display.html?id=2159</a> (<a class="moz-txt-link-freetext" href="https://support.klarasystems.com/Ticket/Display.html?id=2159">https://support.klarasystems.com/Ticket/Display.html?id=2159</a>) > > Hi, > > If we knew which commits from libareq2 fix it, we could try > to convince the port maintainer to accept them as patches > to the current version if they don't want to hop to a > snapshot of a development version -- assuming the patches > aren't incredibly invasive. > > Thanks, > > Kyle Evans > > On 7/17/25 14:52, Alex Aminoff wrote: > > Ticket URL: > <a class="moz-txt-link-freetext" href="https://support.klarasystems.com/Ticket/Display.html?id=2159">https://support.klarasystems.com/Ticket/Display.html?id=2159</a> (<a class="moz-txt-link-freetext" href="https://support.klarasystems.com/Ticket/Display.html?id=2159">https://support.klarasystems.com/Ticket/Display.html?id=2159</a>) > > On 7/17/25 15:23, Alex Aminoff wrote: > > > > Meanwhile I will try wrapping upload() in an eval. > > > I tried this, and it is successful in that it returns control to the > perl code, but the result of the upload call is undef. As I demonstrated > in my initial post, if there are multiple file fields, any of them being > un-filled triggers the bug, so I can not get the info for the file the > user actually uploaded. > > Therefore one possible way forward will indeed be to download the > bleeding edge libapreq2 from source and compile and install it. I can do > that, or you could. But please if you can do some more investigation first. > > - Alex > > > > -- > Kyle Evans > FreeBSD Engineering Manager, Klara Inc. > > > Xavier Beaudouin-System Engineer @ Klara Inc.W: klarasystems.com (<a class="moz-txt-link-freetext" href="http://klarasystems.com">http://klarasystems.com</a>) > > Randolf Richardson, CNA - <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> Inter-Corporate Computer & Network Services, Inc. Beautiful British Columbia, Canada <a class="moz-txt-link-freetext" href="https://www.inter-corporate.com/">https://www.inter-corporate.com/</a> </pre> </blockquote> </body> </html> --------------3YgzDQw32gFX6UvaBbqd006V--