PATCH mod_fcgid compile fails
Hello! When you want to compile mod_fcgid als build in static module it fails with: modules/fcgid/.libs/libmod_fcgid.a(fcgid_mutex_unix.o): In function `fcgid_mutex_create': fcgid_mutex_unix.c:(.text+0x65): warning: the use of `tmpnam' is dangerous, better use `mkstemp' make[1]: Leaving directory `/root/rpmbuild/SOURCES/httpd-2.2.21' The following patch helps, but i dont know if its the right solution. 1129#centos6-build:diff modules/fcgid/fcgid_mutex_unix.c ../mod_fcgid-2.3.6/modules/fcgid/fcgid_mutex_unix.c 118c118 mkstemp(lockfile); --- tmpnam(lockfile); Can someone check it? thx Stefan Novak
Re: PATCH mod_fcgid compile fails
2011/10/5 stefan novak lms.bruba...@gmail.com: Hello! When you want to compile mod_fcgid als build in static module it fails with: modules/fcgid/.libs/libmod_fcgid.a(fcgid_mutex_unix.o): In function `fcgid_mutex_create': fcgid_mutex_unix.c:(.text+0x65): warning: the use of `tmpnam' is dangerous, better use `mkstemp' make[1]: Leaving directory `/root/rpmbuild/SOURCES/httpd-2.2.21' this is only a warning, are You sure httpd fails to build ? The following patch helps, but i dont know if its the right solution. 1129#centos6-build:diff modules/fcgid/fcgid_mutex_unix.c ../mod_fcgid-2.3.6/modules/fcgid/fcgid_mutex_unix.c 118c118 mkstemp(lockfile); --- tmpnam(lockfile); Can someone check it? I think this won't work from man The mkstemp() function generates a unique temporary filename from template, creates and opens the file, and returns an open file descriptor for the file. The tmpnam() function returns a pointer to a string that is a valid filename, and such that a file with this name did not exist at some point in time tmpnam() creates a temporary filename in lockfile which is used by apr_global_mutex_create() mkstemp() won't touch lockfile so apr_global_mutex_create() will get always same empty string, i think this might work on some platforms where default lock mechanism doesn't need a filename -- Michal Grzedzicki
ap_log_error wants a string literal in mod_lua
Hey folks, When trunk with (hardened) gcc 4.6 on Ubuntu beta, I get: lua_config.c: In function 'cmd_log_at': lua_config.c:177:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors The appropriate source: lua_Debug dbg; lua_getstack(L, 1, dbg); lua_getinfo(L, Sl, dbg); msg = luaL_checkstring(L, 2); ap_log_error(dbg.source, dbg.currentline, APLOG_MODULE_INDEX, level, 0, cmd-server, msg); Is there anything we can do to fix this so it builds again with paranoia options? So long, i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
RE: ap_log_error wants a string literal in mod_lua
-Original Message- From: Igor Galić [mailto:i.ga...@brainsware.org] Sent: Mittwoch, 5. Oktober 2011 16:51 To: dev Subject: ap_log_error wants a string literal in mod_lua Hey folks, When trunk with (hardened) gcc 4.6 on Ubuntu beta, I get: lua_config.c: In function 'cmd_log_at': lua_config.c:177:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors The appropriate source: lua_Debug dbg; lua_getstack(L, 1, dbg); lua_getinfo(L, Sl, dbg); msg = luaL_checkstring(L, 2); ap_log_error(dbg.source, dbg.currentline, APLOG_MODULE_INDEX, level, 0, cmd-server, msg); Is there anything we can do to fix this so it builds again with paranoia options? How about: ap_log_error(dbg.source, dbg.currentline, APLOG_MODULE_INDEX, level, 0, cmd-server, %s, msg); Regards Rüdiger
Re: Make loglevel of File does not exist configurable
On 05.10.2011 02:38, William A. Rowe Jr. wrote: On 10/4/2011 1:00 PM, Stefan Fritsch wrote: I think this one has been controversial in the past, therefore I thought I'd ask for comments before making this change: I believe you are right, but I don't see a reason for the extra directive... The File does not exist log messages are logged at level error, while not providing additional information over the 404 access log line (at least in many setups). There have been requests to lower the loglevel for these messages (PR 35768), which have been denied in the past because of compatibility and it's an error. The per-module loglevels help not much, because most of the File does not exist messages come from core, and one usually does not want to set LogLevel core:crit. As you say, it *is* logged (404) and is *not* an administrator's error (either the web content has invalid links, someone ELSE'S web content has invalid links, or the user is simply trying arbitrary resource names. Ergo, this is not a [warn]. Never was. Because we are talking about *user input* which has no negative connotations except to the user. Proposed, we drop this to [info] or [debug] and be done with it already. I therefore intend to add a LogLevelFileNotFound config directive that allows to make it configurable and a int ap_loglevel_file_not_found(request_rec *) API that allows modules to query the setting. I think per-virtual server would be enough for the setting, but with this API that could be changed to per-dir later on. Sounds like a bikeshed. I suggest we simply tear it down and replace this with greenspace, nothing to be confused by, nothing to fill up loglevel warn logs. I agree that this log message does more harm than use. In most cases people ignore it but don't see any additional useful messages, because they are to lazy to grep the file not found away. So I also suggest to tone it down to info and if it makes sense and isn't to risky move the default_handler into the http module. I would not add a separate config option, because that opens a can of worms: everyone has a favourite annoying log message he or she wants to tone down. Level info for this message is the better default and whether there needs to be a separate apparatus to control some message levels is another discussion with much bigger impact. Regards, Rainer
Re: PATCH mod_fcgid compile fails
this is only a warning, are You sure httpd fails to build ? yes, httpd fails to build with this lines :( maybe another compile flag will help, i'm not sure... The following patch helps, but i dont know if its the right solution. 1129#centos6-build:diff modules/fcgid/fcgid_mutex_unix.c ../mod_fcgid-2.3.6/modules/fcgid/fcgid_mutex_unix.c 118c118 mkstemp(lockfile); --- tmpnam(lockfile); Can someone check it? I think this won't work from man The mkstemp() function generates a unique temporary filename from template, creates and opens the file, and returns an open file descriptor for the file. The tmpnam() function returns a pointer to a string that is a valid filename, and such that a file with this name did not exist at some point in time tmpnam() creates a temporary filename in lockfile which is used by apr_global_mutex_create() mkstemp() won't touch lockfile so apr_global_mutex_create() will get always same empty string, i think this might work on some platforms where default lock mechanism doesn't need a filename sounds not so good. is anyone able to produce a better patch, i'm not a C programer :( thx S.Novak
Re: PATCH mod_fcgid compile fails
2011/10/5 stefan novak lms.bruba...@gmail.com: this is only a warning, are You sure httpd fails to build ? yes, httpd fails to build with this lines :( maybe another compile flag will help, i'm not sure... i ran similar test on my system without problems (only this warning) # ./configure --enable-fcgid # make ... /usr/share/apr-1.0/build/libtool --silent --mode=link i486-linux-gnu-gcc -pthread-o httpd modules.lo buildmark.o -export-dynamic server/libmain.la modules/aaa/libmod_authn_file.la modules/aaa/libmod_authn_default.la modules/aaa/libmod_authz_host.la modules/aaa/libmod_authz_groupfile.la modules/aaa/libmod_authz_user.la modules/aaa/libmod_authz_default.la modules/aaa/libmod_auth_basic.la modules/fcgid/libmod_fcgid.la modules/filters/libmod_include.la modules/filters/libmod_filter.la modules/loggers/libmod_log_config.la modules/metadata/libmod_env.la modules/metadata/libmod_setenvif.la modules/metadata/libmod_version.la modules/http/libmod_http.la modules/http/libmod_mime.la modules/generators/libmod_status.la modules/generators/libmod_autoindex.la modules/generators/libmod_asis.la modules/generators/libmod_cgi.la modules/mappers/libmod_negotiation.la modules/mappers/libmod_dir.la modules/mappers/libmod_actions.la modules/mappers/libmod_userdir.la modules/mappers/libmod_alias.la modules/mappers/libmod_so.la server/mpm/prefork/libprefork.la os/unix/libos.la -lm /usr/src/test_ap/httpd-2.2.21/srclib/pcre/libpcre.la /usr/lib/libaprutil-1.la /usr/lib/libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl modules/fcgid/.libs/libmod_fcgid.a(fcgid_mutex_unix.o): In function `fcgid_mutex_create': fcgid_mutex_unix.c:(.text+0x47): warning: the use of `tmpnam' is dangerous, better use `mkstemp' make[1]: Opuszczenie katalogu `/obr/src/test_ap/httpd-2.2.21' # ./httpd -l|grep fcgid mod_fcgid.c so httpd biulds correctly if it still fails for you please paste more make logs and your configure options -- Michal Grzedzicki
Re: Make loglevel of File does not exist configurable
On Tue, 4 Oct 2011, Daniel Ruggeri wrote: On 10/4/2011 2:12 PM, Graham Leggett wrote: On 04 Oct 2011, at 8:00 PM, Stefan Fritsch wrote: I think this one has been controversial in the past, therefore I thought I'd ask for comments before making this change: The File does not exist log messages are logged at level error, while not providing additional information over the 404 access log line (at least in many setups). There have been requests to lower the loglevel for these messages (PR 35768), which have been denied in the past because of compatibility and it's an error. The per-module loglevels help not much, because most of the File does not exist messages come from core, and one usually does not want to set LogLevel core:crit. I therefore intend to add a LogLevelFileNotFound config directive that allows to make it configurable and a int ap_loglevel_file_not_found(request_rec *) API that allows modules to query the setting. I think per-virtual server would be enough for the setting, but with this API that could be changed to per-dir later on. Hmmm... it seems unclean to me and counterintuitive. Definitely unclean. From the comments in the PR I got the impression that changing the loglevel was not an option. But I would definitely prefer changing it rather than adding an additional directive. How about moving the default_handler() into the http module? Big +1 on achieving this objective. One question, though, about moving the handler into http... Does that also imply adjusting the logging level by using http:crit? Wouldn't we swallow several other important messages by changing logging levels there? Yes, IMO moving the default_handler around doesn't solve the problem (and similar messages are logged by mod_action and mod_asis at level error, too). Besides, default_handler() mostly deals with stuff from core_dir_config. It's not obvious that it would fit better in mod_http, IMHO.
Re: Change loglevel of File does not exist messages
On Wed, 5 Oct 2011, Rainer Jung wrote: So I also suggest to tone it down to info and if it makes sense and isn't to risky move the default_handler into the http module. I would not add a separate config option, because that opens a can of worms: everyone has a favourite annoying log message he or she wants to tone down. Level info for this message is the better default and whether there needs to be a separate apparatus to control some message levels is another discussion with much bigger impact. True. But a generic apparatus for even more fine-grained log configuration won't happen in time for 2.4. So, if there is consensous to change the messages to info, I will commit that after waiting a bit more for possible objections. BTW, debug would be fine for me, too. Cheers, Stefan
Re: svn commit: r1178079 - in /httpd/httpd/trunk: CHANGES
On Tue, 4 Oct 2011, Gregg L. Smith wrote: It looks as if ap_max_mem_free was not originally intended to be exported. But if it is going to be used in mod_ssl, it's is going to need to be no? Oops, I missed that. In principle there is the same problem with mod_mpm_event, but that is only built under Unix where the missing AP_DECLARE_DATA makes no difference. Fixed in r1179448. Cheers, Stefan Linking... Creating library .\Release/mod_ssl.lib and object .\Release/mod_ssl.exp ssl_engine_init.obj : error LNK2001: unresolved external symbol _ap_max_mem_free .\Release\mod_ssl.so : fatal error LNK1120: 1 unresolved externals This seems to work for Win Netware Index: include/mpm_common.h === --- include/mpm_common.h(revision 1178660) +++ include/mpm_common.h(working copy) @@ -314,7 +314,7 @@ int ap_signal_server(int *, apr_pool_t *); void ap_mpm_rewrite_args(process_rec *); -extern apr_uint32_t ap_max_mem_free; +AP_DECLARE_DATA apr_uint32_t ap_max_mem_free; extern const char *ap_mpm_set_max_mem_free(cmd_parms *cmd, void *dummy, const char *arg); Cheers, Gregg
Re: Change loglevel of File does not exist messages
On 10/5/2011 4:18 PM, Stefan Fritsch wrote: True. But a generic apparatus for even more fine-grained log configuration won't happen in time for 2.4. I have toyed with the idea of this... do you have suggestions on how this might be implemented? One of the ideas I heard (or thought of - don't recall) was to implement an error log filter such that messages matching a certain regex get dropped. To me that seems like it would be very expensive for busier sites, but would serve the purpose for some of the user base. So, if there is consensous to change the messages to info, I will commit that after waiting a bit more for possible objections. BTW, debug would be fine for me, too. +1 for info level -- Daniel Ruggeri
Re: Change loglevel of File does not exist messages
On 06.10.2011 01:07, Daniel Ruggeri wrote: On 10/5/2011 4:18 PM, Stefan Fritsch wrote: True. But a generic apparatus for even more fine-grained log configuration won't happen in time for 2.4. I have toyed with the idea of this... do you have suggestions on how this might be implemented? One of the ideas I heard (or thought of - don't recall) was to implement an error log filter such that messages matching a certain regex get dropped. To me that seems like it would be very expensive for busier sites, but would serve the purpose for some of the user base. Interesting idea! Rainer
