From vbart at nginx.com Thu Oct 3 16:38:28 2019 From: vbart at nginx.com (Valentin V. Bartenev) Date: Thu, 03 Oct 2019 19:38:28 +0300 Subject: Unit 1.12.0 release Message-ID: <6334549.l9gM9tyqz1@vbart-workstation> Hi, I'm glad to announce a new release of NGINX Unit. This is an ad-hoc release that focuses on fixing several annoying bugs and adds compatibility with the upcoming PHP 7.4, scheduled for release on November 28, 2019. Changes with Unit 1.12.0 03 Oct 2019 *) Feature: compatibility with PHP 7.4. *) Bugfix: descriptors leak on process creation; the bug had appeared in 1.11.0. *) Bugfix: TLS connection might be closed prematurely while sending response. *) Bugfix: segmentation fault might have occurred if an irregular file was requested. Regarding our plans for the near future, see our earlier announcement: - https://mailman.nginx.org/pipermail/unit/2019-September/000167.html To know more about some features introduced recently, you can follow posts about Unit in the official blog: - https://www.nginx.com/blog/tag/nginx-unit/ We also updated our Docker images with an initialization script that significantly simplifies the initial configuration of Unit daemon inside a container. Please check the documentation for instructions: - https://unit.nginx.org/installation/#initial-configuration wbr, Valentin V. Bartenev From geraldonetto at gmail.com Fri Oct 11 14:39:59 2019 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Oct 2019 16:39:59 +0200 Subject: Does Unit support anything equivalent to Tomcat Valve Message-ID: Dear Friends, How are you doing? Sorry for disturbing you with such a newbie question but I couldn't find any specific documentation on this topic But does Nginx Unit support any kind of application-wide filter like Tomcat Valve? Thank You Very Much/Kind Regards, Geraldo Netto Sapere Aude => Non dvcor, dvco site: http://exdev.sf.net/ github: https://github.com/geraldo-netto linkedin: https://www.linkedin.com/in/geraldonetto/ facebook: https://web.facebook.com/geraldo.netto.161 From max.romanov at nginx.com Fri Oct 11 15:16:12 2019 From: max.romanov at nginx.com (Max Romanov) Date: Fri, 11 Oct 2019 18:16:12 +0300 Subject: Does Unit support anything equivalent to Tomcat Valve In-Reply-To: References: Message-ID: <066634EE-277F-4BB3-A99C-EFD42C1955E5@nginx.com> Hello Geraldo, Unit does not have exact equivalent of Tomcat Valve, which is Java- and Tomcat-specific. To advise equivalent feature, it would be nice to know which Valves used. In some cases Unit routing functionality (see http://unit.nginx.org/configuration/#routes) may be useful. This functionality is actively developing and extending now. Please describe your use cases. It will help us to advise you existing Unit feature or think of a way we can improve it. Best regards, Max > On 11 Oct 2019, at 17:39 , Geraldo Netto wrote: > > Dear Friends, > > How are you doing? > > Sorry for disturbing you with such a newbie question but I couldn't > find any specific documentation on this topic > > But does Nginx Unit support any kind of application-wide filter like > Tomcat Valve? > > > Thank You Very Much/Kind Regards, > > Geraldo Netto > Sapere Aude => Non dvcor, dvco > site: http://exdev.sf.net/ > github: https://github.com/geraldo-netto > linkedin: https://www.linkedin.com/in/geraldonetto/ > facebook: https://web.facebook.com/geraldo.netto.161 > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit From geraldonetto at gmail.com Fri Oct 11 15:27:54 2019 From: geraldonetto at gmail.com (Geraldo Netto) Date: Fri, 11 Oct 2019 17:27:54 +0200 Subject: Does Unit support anything equivalent to Tomcat Valve In-Reply-To: <066634EE-277F-4BB3-A99C-EFD42C1955E5@nginx.com> References: <066634EE-277F-4BB3-A99C-EFD42C1955E5@nginx.com> Message-ID: Hello Max! Thanks for your quick response The situation is that we have a legacy application that depends on tomcat valve to share authentication and other filters in the request flow Routing seems a much cleaner solution, I might give it a try :) Thanks Once Again, Geraldo Netto Sapere Aude => Non dvcor, dvco site: http://exdev.sf.net/ github: https://github.com/geraldo-netto linkedin: https://www.linkedin.com/in/geraldonetto/ facebook: https://web.facebook.com/geraldo.netto.161 On Fri, 11 Oct 2019 at 17:16, Max Romanov wrote: > > Hello Geraldo, > > Unit does not have exact equivalent of Tomcat Valve, which is Java- and Tomcat-specific. > > To advise equivalent feature, it would be nice to know which Valves used. In some cases > Unit routing functionality (see http://unit.nginx.org/configuration/#routes) may be useful. > This functionality is actively developing and extending now. > > Please describe your use cases. It will help us to advise you existing Unit feature or > think of a way we can improve it. > > Best regards, > Max > > > > On 11 Oct 2019, at 17:39 , Geraldo Netto wrote: > > > > Dear Friends, > > > > How are you doing? > > > > Sorry for disturbing you with such a newbie question but I couldn't > > find any specific documentation on this topic > > > > But does Nginx Unit support any kind of application-wide filter like > > Tomcat Valve? > > > > > > Thank You Very Much/Kind Regards, > > > > Geraldo Netto > > Sapere Aude => Non dvcor, dvco > > site: http://exdev.sf.net/ > > github: https://github.com/geraldo-netto > > linkedin: https://www.linkedin.com/in/geraldonetto/ > > facebook: https://web.facebook.com/geraldo.netto.161 > > _______________________________________________ > > unit mailing list > > unit at nginx.org > > https://mailman.nginx.org/mailman/listinfo/unit > > _______________________________________________ > unit mailing list > unit at nginx.org > https://mailman.nginx.org/mailman/listinfo/unit From abbot at monksofcool.net Mon Oct 28 16:18:19 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Mon, 28 Oct 2019 17:18:19 +0100 Subject: Preventing the build from adding options like '-pipe' et al Message-ID: <874kzsdet0.fsf@wedjat.horus-it.com> Hello, I maintain the Unit ebuild for Gentoo Linux, and I am currently trying to figure out how to prevent the configure/build process from extending compiler or linker flags. I use ./configure --cc-opt="${CFLAGS}" --ld-opt="${LDFLAGS}" [...] to pass Gentoo's user-defined options along, but find that flags like '-pipe' or '-g' are being added without my say-so. Gentoo QA is quite rigorous about not allowing builds to use options not provided by the user, so I am looking for the best way to enforce this restriction. Can any of you provide me with pointers? Thanks. -Ralph From vbart at nginx.com Mon Oct 28 16:40:02 2019 From: vbart at nginx.com (Valentin V. Bartenev) Date: Mon, 28 Oct 2019 19:40:02 +0300 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <874kzsdet0.fsf@wedjat.horus-it.com> References: <874kzsdet0.fsf@wedjat.horus-it.com> Message-ID: <3576825.c25bKJafJJ@vbart-workstation> On Monday 28 October 2019 17:18:19 Ralph Seichter wrote: > Hello, > > I maintain the Unit ebuild for Gentoo Linux, and I am currently trying > to figure out how to prevent the configure/build process from extending > compiler or linker flags. I use > > ./configure --cc-opt="${CFLAGS}" --ld-opt="${LDFLAGS}" [...] > > to pass Gentoo's user-defined options along, but find that flags like > '-pipe' or '-g' are being added without my say-so. > > Gentoo QA is quite rigorous about not allowing builds to use options not > provided by the user, so I am looking for the best way to enforce this > restriction. Can any of you provide me with pointers? Thanks. [..] Hi Ralph, Could you provide a link to the policy with this requirement? I'm curious how it's solved with other ebuilds... e.g. nginx building scripts work absolutely the same way, but I don't see anything special in nginx ebuild to prevent additional flags. It's quite normal for a build system to add some additional flags, that developers see reasonable for their software. wbr, Valentin V. Bartenev From abbot at monksofcool.net Mon Oct 28 17:08:28 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Mon, 28 Oct 2019 18:08:28 +0100 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <3576825.c25bKJafJJ@vbart-workstation> References: <874kzsdet0.fsf@wedjat.horus-it.com> <3576825.c25bKJafJJ@vbart-workstation> Message-ID: <875zk83iib.fsf@wedjat.horus-it.com> * Valentin V. Bartenev: > Could you provide a link to the policy with this requirement? Thanks for the quick response. [1] section "Makefile Variables" states: "Sometimes, badly behaved Makefile.am files will override user variables such as CFLAGS. This must not be allowed (...)" [2] offers additional information, especially the "Not Filtering Variables" section. I actually have open QA bugs for these build issues, so it is not me being overzealous. [1] https://devmanual.gentoo.org/general-concepts/autotools/index.html [2] https://devmanual.gentoo.org/general-concepts/user-environment/index.html > I'm curious how it's solved with other ebuilds Unless better methods are available, we usually patch autotools files which don't comply with Gentoo's rules. However, it is obviously much nicer if the upstream build process can be configured to use only the flags we provide at build time. > It's quite normal for a build system to add some additional flags, > that developers see reasonable for their software. I think that depends on the situation and/or target platform, and Gentoo supports some non-mainstream platforms. Forcing options like '-pipe' on the user which have effects during build time, or '-g' which adds debug symbols the user might not want, clashes with Gentoo's idea of providing users with the widest range (within reason) of choices. Note that individual Gentoo developers have individual views in this matter, and the above is how I understand the Gentoo QA team's opinion. I am not a team member though, so don't take what I wrote as scripture. However, the Gentoo developer manual defines the rules by which Gentoo devs have to abide, so just ignoring the additional flags is not really an option I have. -Ralph From abbot at monksofcool.net Mon Oct 28 17:41:48 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Mon, 28 Oct 2019 18:41:48 +0100 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <875zk83iib.fsf@wedjat.horus-it.com> References: <874kzsdet0.fsf@wedjat.horus-it.com> <3576825.c25bKJafJJ@vbart-workstation> <875zk83iib.fsf@wedjat.horus-it.com> Message-ID: <87k18on4wz.fsf@wedjat.horus-it.com> * Ralph Seichter: > Unless better methods are available, we usually patch autotools files > which don't comply with Gentoo's rules. You asked me about the NGINX build. The current ebuild's src_prepare() function[1] exemplifies how patches are applied and how sed is used to replace 'make' with '$(MAKE)', update the installation configuration, etc. I'd rather avoid doing things that way, because I would have to revisit it with every Unit release to check if it still works. Hence my hope that you can add a '--cc-and-ld-flags-are-immutable' option or something similar. ;-) -Ralph From vbart at nginx.com Mon Oct 28 18:09:07 2019 From: vbart at nginx.com (Valentin V. Bartenev) Date: Mon, 28 Oct 2019 21:09:07 +0300 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <875zk83iib.fsf@wedjat.horus-it.com> References: <874kzsdet0.fsf@wedjat.horus-it.com> <3576825.c25bKJafJJ@vbart-workstation> <875zk83iib.fsf@wedjat.horus-it.com> Message-ID: <3251985.qxLvCtUlnN@vbart-workstation> On Monday 28 October 2019 18:08:28 Ralph Seichter wrote: > * Valentin V. Bartenev: > > > Could you provide a link to the policy with this requirement? > > Thanks for the quick response. [1] section "Makefile Variables" states: > "Sometimes, badly behaved Makefile.am files will override user variables > such as CFLAGS. This must not be allowed (...)" [2] offers additional > information, especially the "Not Filtering Variables" section. > > I actually have open QA bugs for these build issues, so it is not me > being overzealous. > > [1] https://devmanual.gentoo.org/general-concepts/autotools/index.html > [2] https://devmanual.gentoo.org/general-concepts/user-environment/index.html > This isn't the case nighter with nginx nor with Unit. Unit build scripts don't override user's CFLAGS. In fact, it's constructed out of three variables: CFLAGS = $NXT_CFLAGS $NXT_CC_OPT $CFLAGS http://hg.nginx.org/unit/file/tip/auto/make#l18 where: $NXT_CFLAGS - internal flags set by the build scripts; $NXT_CC_OPT - flags provided by the --cc-opt ./configure options; $CFLAGS - original CFLAGS from the user's environment. It's not the case like in the example in [1]: CFLAGS="-Wall" Our build scripts honor user's defined CFLAGS and give them the preference as they come after all other flags. The user can override any of the flags previously set if he wishes. Note, that setting --cc-opt="${CFLAGS}" is a bad idea. Because this way all CFLAGS will be duplicated. > > I'm curious how it's solved with other ebuilds > > Unless better methods are available, we usually patch autotools files > which don't comply with Gentoo's rules. However, it is obviously much > nicer if the upstream build process can be configured to use only the > flags we provide at build time. I've checked patches and ebuild files for nginx: - https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/nginx and couldn't find anything that prevents nginx from setting a bunch of flags by default: -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g nginx ebuild is maintained more than 14 years and the rhetorical question is why it's not a problem for it, but a problem for Unit. You've pointed out on $(MAKE), but it's another matter. I agree to make "make" configurable if it's required in some cases. > > > It's quite normal for a build system to add some additional flags, > > that developers see reasonable for their software. > > I think that depends on the situation and/or target platform, and Gentoo > supports some non-mainstream platforms. Forcing options like '-pipe' on > the user which have effects during build time, or '-g' which adds debug > symbols the user might not want, clashes with Gentoo's idea of providing > users with the widest range (within reason) of choices. Unit build script doesn't blindly add -pipe and -g. The platform and compiler are checked and relevant flags are added (different in each case). If the platform is unknown, then no flags are added. We have a buildbot that builds each commit with wide range of platforms. It's not limiting users choices, as there's an easy way to overwrite any of these flags. The "-g" flag is very important. Most users don't have it by default, but it allows to have at least some information in case of crash. Considering tiny size of Unit sources it adds negligible overhead to the binary. If we won't force "-g", we will have more meaningless bug reports with all the negative consequences. > > Note that individual Gentoo developers have individual views in this > matter, and the above is how I understand the Gentoo QA team's > opinion. I am not a team member though, so don't take what I wrote as > scripture. However, the Gentoo developer manual defines the rules by > which Gentoo devs have to abide, so just ignoring the additional flags > is not really an option I have. Could you raise a question, what's special with Unit that additional flags aren't allowed, while they are ok for other mature ebuilds? With all due respect, if there's some policy then it must be equally applied for everything, otherwise it's not really a policy, but just a matter of view of some individual. wbr, Valentin V. Bartenev From abbot at monksofcool.net Mon Oct 28 18:55:40 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Mon, 28 Oct 2019 19:55:40 +0100 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <3251985.qxLvCtUlnN@vbart-workstation> References: <874kzsdet0.fsf@wedjat.horus-it.com> <3576825.c25bKJafJJ@vbart-workstation> <875zk83iib.fsf@wedjat.horus-it.com> <3251985.qxLvCtUlnN@vbart-workstation> Message-ID: <87d0eg4s43.fsf@wedjat.horus-it.com> * Valentin V. Bartenev: > Unit build scripts don't override user's CFLAGS. In fact, it's > constructed out of three variables: > > CFLAGS = $NXT_CFLAGS $NXT_CC_OPT $CFLAGS Actually, having CFLAGS on the left hand side of this assignment *does* override the existing environment-provided CFLAGS. Even if you used something like $(CC) $(CFLAGS) $(NXT_CFLAGS) $(NXT_CC_OPT) it would still be overriding, or call it extending, the existing compiler flags as set by the environment. > Our build scripts honor user's defined CFLAGS and give them the > preference as they come after all other flags. Your build does however add flags like '-pipe' or '-g' which the user has not set. That's what I need to address. > Note, that setting --cc-opt="${CFLAGS}" is a bad idea. Because this > way all CFLAGS will be duplicated. Yeah, that's what I figured. My hope was that if I explicitly pass --cc-opt, the build would not add any other options. > nginx ebuild is maintained more than 14 years and the rhetorical > question is why it's not a problem for it, but a problem for Unit. I cannot give you the reasoning behind the NGINX build, because I don't maintain it. I introduced the NGINX Unit build to Gentoo, and that's the build I am responsible for. The QA bugs have not been filed by myself, but I cannot ignore them. > If we won't force "-g", we will have more meaningless bug reports with > all the negative consequences. I understand your reasoning as much as that of our QA team, and I am caught in the middle. I like Unit a lot and personally would not mind '-g', but my opinion does not count for much when I submit merge requests and they get rejected because of Gentoo's house rules. Note also that I don't intend to pressure you into anything. If you don't feel like modifying your working build because of "the world according to Gentoo", I can understand that. > Could you raise a question, what's special with Unit that additional > flags aren't allowed, while they are ok for other mature ebuilds? I can notify the Gentoo QA team of this thread. Perhaps a member is willing to elaborate why Gentoo policies are the way they are, and why/when exceptions are made. -Ralph From vbart at nginx.com Tue Oct 29 15:10:50 2019 From: vbart at nginx.com (Valentin V. Bartenev) Date: Tue, 29 Oct 2019 18:10:50 +0300 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <87d0eg4s43.fsf@wedjat.horus-it.com> References: <874kzsdet0.fsf@wedjat.horus-it.com> <3251985.qxLvCtUlnN@vbart-workstation> <87d0eg4s43.fsf@wedjat.horus-it.com> Message-ID: <2555928.ZMuDKWL7ra@vbart-workstation> On Monday 28 October 2019 19:55:40 Ralph Seichter wrote: > * Valentin V. Bartenev: > > > Unit build scripts don't override user's CFLAGS. In fact, it's > > constructed out of three variables: > > > > CFLAGS = $NXT_CFLAGS $NXT_CC_OPT $CFLAGS > > Actually, having CFLAGS on the left hand side of this assignment *does* > override the existing environment-provided CFLAGS. Even if you used > something like > > $(CC) $(CFLAGS) $(NXT_CFLAGS) $(NXT_CC_OPT) > > it would still be overriding, or call it extending, the existing > compiler flags as set by the environment. By overriding I ment that user's flags get priority, and environment CFLAGS can negate most of the flags set before, e.g. -g0 negates -g The example by the link demonstrates different case, when CFLAGS are replaced completely without picking up environment flags. BTW, "Basic guide to write Gentoo Ebuilds" for an example application uses Makefile that overrides all flags, and they are: -g -O0 -pipe. - https://wiki.gentoo.org/wiki/Basic_guide_to_write_Gentoo_Ebuilds [..] > > nginx ebuild is maintained more than 14 years and the rhetorical > > question is why it's not a problem for it, but a problem for Unit. > > I cannot give you the reasoning behind the NGINX build, because I don't > maintain it. I introduced the NGINX Unit build to Gentoo, and that's the > build I am responsible for. The QA bugs have not been filed by myself, > but I cannot ignore them. Well, searching over Gentoo Bugzilla shows about 100 tickets related to CFLAGS. Some of them are similar and 5+ years old, e.g: - https://bugs.gentoo.org/385995 (note the reporter). And sometimes users ask quite the opposite, respect for the upstream CFLAGS: - https://bugs.gentoo.org/687920 > > > If we won't force "-g", we will have more meaningless bug reports with > > all the negative consequences. > > I understand your reasoning as much as that of our QA team, and I am > caught in the middle. I like Unit a lot and personally would not mind > '-g', but my opinion does not count for much when I submit merge > requests and they get rejected because of Gentoo's house rules. > > Note also that I don't intend to pressure you into anything. If you > don't feel like modifying your working build because of "the world > according to Gentoo", I can understand that. > If there will be users who suffering somehow and those flags cause problems for them, then we will look for a solution. Right now it very much looks like nit-picking. I see no real problem with adding "-g -pipe" on systems where they are supported. Moreover, nginx has been doing it since 2004 and there were no reports about any issues with that. It seems that someone sees his mission in checking various software for -g and -pipe flags added. Sorry, but it doesn't really a valuable reason to change things. If you will end up with decision to patch sources, then patch this script: - https://hg.nginx.org/unit/file/tip/auto/cc/test wbr, Valentin V. Bartenev From abbot at monksofcool.net Thu Oct 31 15:10:27 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Thu, 31 Oct 2019 16:10:27 +0100 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <2555928.ZMuDKWL7ra@vbart-workstation> References: <874kzsdet0.fsf@wedjat.horus-it.com> <3251985.qxLvCtUlnN@vbart-workstation> <87d0eg4s43.fsf@wedjat.horus-it.com> <2555928.ZMuDKWL7ra@vbart-workstation> Message-ID: <875zk56jdo.fsf@wedjat.horus-it.com> * Valentin V. Bartenev: > It seems that someone sees his mission in checking various software > for -g and -pipe flags added. Sorry, but it doesn't really a valuable > reason to change things. Like I said, I understand your position. I have not heard from Gentoo QA in this matter since I last asked, so I decided to patch Unit's auto/* files. Something that is also relevant but probably less controversial: The build currently does not honor variables $(AR) or $(MAKE), but commands like uses definitions like NXT_STATIC_LINK="ar -r -c" instead. Would you consider adding support for these variables, like you already do for CC or CFLAGS? -Ralph From vbart at nginx.com Thu Oct 31 16:51:13 2019 From: vbart at nginx.com (Valentin V. Bartenev) Date: Thu, 31 Oct 2019 19:51:13 +0300 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <875zk56jdo.fsf@wedjat.horus-it.com> References: <874kzsdet0.fsf@wedjat.horus-it.com> <2555928.ZMuDKWL7ra@vbart-workstation> <875zk56jdo.fsf@wedjat.horus-it.com> Message-ID: <3105083.2ZifurCluQ@vbart-workstation> On Thursday 31 October 2019 16:10:27 Ralph Seichter wrote: > * Valentin V. Bartenev: > > > It seems that someone sees his mission in checking various software > > for -g and -pipe flags added. Sorry, but it doesn't really a valuable > > reason to change things. > > Like I said, I understand your position. I have not heard from Gentoo QA > in this matter since I last asked, so I decided to patch Unit's auto/* > files. > > Something that is also relevant but probably less controversial: The > build currently does not honor variables $(AR) or $(MAKE), but commands > like uses definitions like > > NXT_STATIC_LINK="ar -r -c" > > instead. Would you consider adding support for these variables, like you > already do for CC or CFLAGS? > [..] Yes, we will add $(AR). As of $(MAKE), Unit doesn't call "make". Btw, nginx doesn't call "make" too. The line from nginx ebuild that you mentioned earlier actually does nothing. wbr, Valentin V. Bartenev From abbot at monksofcool.net Thu Oct 31 22:36:58 2019 From: abbot at monksofcool.net (Ralph Seichter) Date: Thu, 31 Oct 2019 23:36:58 +0100 Subject: Preventing the build from adding options like '-pipe' et al In-Reply-To: <3105083.2ZifurCluQ@vbart-workstation> References: <874kzsdet0.fsf@wedjat.horus-it.com> <2555928.ZMuDKWL7ra@vbart-workstation> <875zk56jdo.fsf@wedjat.horus-it.com> <3105083.2ZifurCluQ@vbart-workstation> Message-ID: <874kzoleyd.fsf@wedjat.horus-it.com> * Valentin V. Bartenev: > Yes, we will add $(AR). Thank you. > Btw, nginx doesn't call "make" too. The line from nginx ebuild that > you mentioned earlier actually does nothing. Ha, so that's a vestigal sed call. ;-) Good to know. -Ralph