Suexec permissions question

[monttyle]

This is not a question on how to use suexec, that's fairly clear.  The 
strict, hardwired conditions its willing to suexec under are also 
spelled out pretty clear.  My question is the nature of these 
requirements -- why they're the way they are.  The user and group 
requirements specifically.


suexec insists that the file being executed needs to be the same owner 
and group as what the web server will be running as after suexec.  
Doesn't this requirement make things *less* secure?  You can't really 
protect a file against its own owner overwriting it.  The same 
requirement is on the folder, leaving the web server two legal chmods 
away from allowing an exploit to create, delete, and modify files inside 
the vhost at will.

Re: where to put update_mime_types.pl?

[Rich Bowen]

On Feb 26, 2016 04:45, "Ruediger Pluem"  wrote:
>
>
>
> On 02/26/2016 01:46 AM, Roy T. Fielding wrote:
> > I have a perl script (see below) for updating the mime.types file with
the latest
> > registered IANA media types.  I would like to add it to our version
control,
> > but I am unsure whether to place it in
> >
> >   httpd/trunk/support/
> >
> > or in
> >
> >   httpd/docs-build/trunk/
>
> For now I would would vote for
>
> httpd/docs-build/trunk/
>

Agreed. Updating the mime.types file tends to fall to the docs folks.

Re: apache-swat project - need feedback!

[Alexey Melezhik]

Please also consider these 2 variables as tests time tuning , in cases of
dead locks or hanging requests they also could be helpful



   -

   curl_connect_timeout - maximum time in seconds that you allow the
   connection to the server to take, follow curl documentation for full
   explanation.
   -

   curl_max_time - maximum time in seconds that you allow the whole
   operation to take, follow curl documentation for full explanation.


   All, these parameters like curl_max_time, try_num, ignore_http_err,
   could be set in per project or per request basis, please follow this link
   for details - https://github.com/melezhik/swat#swat-ini-files

пятница, 26 февраля 2016 г. пользователь Eric Covener написал:

> On Thu, Feb 4, 2016 at 6:07 AM, Alexey Melezhik  > wrote:
> > * what things could be improved
>
> I notice that failed (bad status code for example) tests hang for a
> many seconds which makes iterating over stuff a little slow.
>
> --
> Eric Covener
> cove...@gmail.com 
>

Re: apache-swat project - need feedback!

[Alexey Melezhik]

Hi , not sure if I completely understand the question, but if you ask about
mapping http requess into swat language,  then this is my answer :

In terms of swat request is just a directories and file paths  so GET
/58854/denied/
would be a
directory 58854/denied/ with a file get.txt in it.

$ mkdir -p 58854/denied/
$ echo 200 0K > 58854/denied/get.txt

More on this is written here
https://github.com/melezhik/swat#write-your-swat-story

Please let me know if it helps

пятница, 26 февраля 2016 г. пользователь Eric Covener написал:

> On Fri, Feb 26, 2016 at 11:23 AM, Eric Covener  > wrote:
> > On Thu, Feb 4, 2016 at 6:07 AM, Alexey Melezhik  > wrote:
> >> * what things could be improved
> >
> > I notice that failed (bad status code for example) tests hang for a
> > many seconds which makes iterating over stuff a little slow.
>
> The harness uses a path like this to request missing.txt:
>
> 58854/denied/missing.txt/get.txt
>
> How would you phrase a a request for /58854/denied/ ?
>

Re: apache-swat project - need feedback!

[Alexey Melezhik]

Hi Eric! Have you made these three steps ?

1. Make sure that http.conf.templ has all your changes ( concerning
MPM modules loading )

2. # generate httpd.conf

./configure.bash /path/to/apache/server/root

3. # run apache with new http do.conf

sudo /path/to/apache/install/prefix/bin/apachectl -f `pwd`/httpd.conf

Step one is not described at apache swat docs, probably I need to update this.


пятница, 26 февраля 2016 г. пользователь Eric Covener написал:

> Whoops, I realized this is not true -- it's got some modules, but it
> didn't have MY modules -- notably my MPM.
>
> On Fri, Feb 26, 2016 at 10:52 AM, Eric Covener  > wrote:
> > I tried to take this for a spin, because I had a bad fix (1 step
> > forward, 10 steps back!) fix for an issue you later wrote a test for.
> >
> > But the httpd.conf template doesn't load any modules, so my (typical)
> > DSO config didn't work at all.
> >
> > Did I do something wrong?  Our Apache::Test harness copies the
> > loadmodules in the installed config file as a bootstrap for the new
> > config IIUC.
>
>
>
> --
> Eric Covener
> cove...@gmail.com 
>

Re: apache-swat project - need feedback!

[Alexey Melezhik]

Hi ! Please try to set try_num variable , which defines number of attempts
in case of unsuccessful return , swat makes exponential delays on every
retry , so to get things fast you probably need try_num=1, please follow
https://github.com/melezhik/swat#curl-parameters for details, also please
consider ignore_http_err variable to test unsuccessful http responses, I
hope this could be helpful.

пятница, 26 февраля 2016 г. пользователь Eric Covener написал:

> On Thu, Feb 4, 2016 at 6:07 AM, Alexey Melezhik  > wrote:
> > * what things could be improved
>
> I notice that failed (bad status code for example) tests hang for a
> many seconds which makes iterating over stuff a little slow.
>
> --
> Eric Covener
> cove...@gmail.com 
>

state of h2 (long)

[Stefan Eissing]

Things winding down here a bit before the weekend (at least I try) and I 
thought 
I'd summarize a bit the state of HTTP/2 in our little project, because...well, 
some
might be interested and certainly no one has the time to follow all my crazy 
submits.

* trunk <-> 2.4.x
  the version in 2.4.x has gathered a bit dust, as we made several tweaks in 
trunk
  in regard to async connection handling and scoreboard updates. These have all 
been
  backported, except one. Once that is through, I'll make a backport of 
mod_http2,
  so that 2.4.x gets all the nice new things.

* nice new things
  in trunk we have the following additions:
  - http/2 connections get queued properly when they become idle on the event 
mpm.
that should be nice for people with many connections or long keepalives 
configured.
  - timeouts and keepalive timeouts are respected as for http/1 connections, no 
extra
configuration.
  - stability: with the interim releases in github and the help of nice people, 
several
improvements have been made here and the 1.2.5 github has no reported open 
blockers,
hanging connections or segfaults. All those changes are in trunk.
  - server push: the module now remembers in each open connection which 
resources
have already been pushed, using hash digests. This also implements an 
outsketched
extension https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest/ 
whereby
clients can send a highly compressed digest of the resources they have. 
This is
very early and experimental and we'll see how/if browsers adapt this and how
it will change over time. 
  - To offload worker threads, the module allows a number of file handles to 
have
open. So, ideally, when serving static content, workers just lookup the 
file,
return and the master connections streams them out. This number existed 
before
as number per master connection. Now this number is multiplied by the 
number of
workers and made a process wide pool where h2 connections can borrow 
amounts.
Still, I am not totally satisfied with this. This should not be 
configurable, but
httpd itself should check for ulimits of the process and configure itself, 
I think.
  - the scoreboard shows more information for h2 connections, such as its 
connection
state and some stream statistics. Maybe the h2 workers should show up in a 
separate
section on day...
 127.0.0.1  http/1.1test2.example.org:12345 wait, streams: 
1/100/100/0/0 (open/recv/resp/push/rst)
  - request engines! which leads us to:

 * mod_proxy_http2
   is configured just like other proxy modules with by using 'h2' or 'h2c' as 
url prefix
   in the configuration directives. 
   
   
   BalancerMember "h2://test2.example.org:12346"
   
ProxyPass "/h2proxy" "balancer://h2-local"
ProxyPassReverse "/h2proxy" "balancer://h2-local"

Initially, it used one h2 connection for one request. The connection, and 
the http2
session associated with it, was reused via the nice proxy infrastructure.

This is how things still are when the original connection is http/1.1
When this is http/2 itself, however, the first such request will register a 
"request engine" that will accept more requests while the initial one is 
still
being served and use the same backend connection for it. When the last 
assigned
request is done, it unregisters and dissolves into fine mist.
The connection and h2 session stays as before, so a new request can reuse 
the connection
in a new engine.

This works quite (but not 100%) reliable at the moment. There are still 
some races when
requests are sent out while the backend is already shutting down and the 
retry does
not catch all cases.

Important here is that requests for engines process all the usual hooks and 
filters
and yaddayadda of our infrastructure, just like with http/1.1. This works 
as follows:

- incoming request is handed to a worker thread as is done for all by 
mod_http2
- httpd/proxy identifies the handler of mod_proxy_http2 as the responsible
- mod_proxy_http2 finds out what backend it shall talk to and ask from 
mod_http2
  (if present, the usual optionals) if there is already an engine for this 
backend,
  and that it is willing to host one if there is not.
- mod_http2, if it has one, *freezes* the task for this request (which 
holds the
  replacements for the core input/output filters on this slave connection) 
and
  returns that it will take care of it, once the handler is done. The 
handler then
  just returns as if it had processed the request.
  Upon return of the worker, the mod_http2 sees a frozen task and makes it 
ready
  for processing in an engine. Next time the engine polls for more 
requests, it is
  forwarded.

- What is this freezing? Basically, an additional output filter that saves 
all 
  incoming buckets for later. So, the EOR 

Re: apache-swat project - need feedback!

[Eric Covener]

On Fri, Feb 26, 2016 at 11:23 AM, Eric Covener  wrote:
> On Thu, Feb 4, 2016 at 6:07 AM, Alexey Melezhik  wrote:
>> * what things could be improved
>
> I notice that failed (bad status code for example) tests hang for a
> many seconds which makes iterating over stuff a little slow.

The harness uses a path like this to request missing.txt:

58854/denied/missing.txt/get.txt

How would you phrase a a request for /58854/denied/ ?

Re: apache-swat project - need feedback!

[Eric Covener]

On Thu, Feb 4, 2016 at 6:07 AM, Alexey Melezhik  wrote:
> * what things could be improved

I notice that failed (bad status code for example) tests hang for a
many seconds which makes iterating over stuff a little slow.

-- 
Eric Covener
cove...@gmail.com

Re: apache-swat project - need feedback!

[Jim Jagielski]

Any hints would be appreciated...

I'd also like to dig deeper into using it.

> On Feb 26, 2016, at 10:54 AM, Eric Covener  wrote:
> 
> Whoops, I realized this is not true -- it's got some modules, but it
> didn't have MY modules -- notably my MPM.
> 
> On Fri, Feb 26, 2016 at 10:52 AM, Eric Covener  wrote:
>> I tried to take this for a spin, because I had a bad fix (1 step
>> forward, 10 steps back!) fix for an issue you later wrote a test for.
>> 
>> But the httpd.conf template doesn't load any modules, so my (typical)
>> DSO config didn't work at all.
>> 
>> Did I do something wrong?  Our Apache::Test harness copies the
>> loadmodules in the installed config file as a bootstrap for the new
>> config IIUC.
> 
> 
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: httpd + systemd

[Reindl Harald]

Am 26.02.2016 um 17:11 schrieb Tim Bannister:

On 26 February 2016, Reindl Harald wrote:




in case of a SIGTERM the daemon is supposed to do a clean shutdown
anyways

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
Restart=always
RestartSec=1


Maybe add an ExecStop as well which calls graceful-stop? This is more reliable 
than a signal.

After DefaultTimeoutStopSec seconds, systemd will intervene regardless


it works not the way you likely think and may make things worser than a 
controlled SIGTERM


https://www.freedesktop.org/software/systemd/man/systemd.service.html

Note that it is usually not sufficient to specify a command for this 
setting that only asks the service to terminate (for example, by queuing 
some form of termination signal for it), but does not wait for it to do 
so. Since the remaining processes of the services are killed using 
SIGKILL immediately after the command exited, this would not result in a 
clean stop. The specified command should hence be a synchronous 
operation, not an asynchronous one.




signature.asc
Description: OpenPGP digital signature

Re: httpd + systemd

[Tim Bannister]

On 26 February 2016, Reindl Harald wrote:
>
>
>
>in case of a SIGTERM the daemon is supposed to do a clean shutdown
>anyways
>
>[Service]
>Type=simple
>EnvironmentFile=-/etc/sysconfig/httpd
>ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
>ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
>Restart=always
>RestartSec=1
>
Maybe add an ExecStop as well which calls graceful-stop? This is more reliable 
than a signal.

After DefaultTimeoutStopSec seconds, systemd will intervene regardless.
-- 
Tim Bannister – is...@c8h10n4o2.org.uk

Re: apache-swat project - need feedback!

[Eric Covener]

Whoops, I realized this is not true -- it's got some modules, but it
didn't have MY modules -- notably my MPM.

On Fri, Feb 26, 2016 at 10:52 AM, Eric Covener  wrote:
> I tried to take this for a spin, because I had a bad fix (1 step
> forward, 10 steps back!) fix for an issue you later wrote a test for.
>
> But the httpd.conf template doesn't load any modules, so my (typical)
> DSO config didn't work at all.
>
> Did I do something wrong?  Our Apache::Test harness copies the
> loadmodules in the installed config file as a bootstrap for the new
> config IIUC.



-- 
Eric Covener
cove...@gmail.com

Re: apache-swat project - need feedback!

[Eric Covener]

I tried to take this for a spin, because I had a bad fix (1 step
forward, 10 steps back!) fix for an issue you later wrote a test for.

But the httpd.conf template doesn't load any modules, so my (typical)
DSO config didn't work at all.

Did I do something wrong?  Our Apache::Test harness copies the
loadmodules in the installed config file as a bootstrap for the new
config IIUC.

Re: BufferedLogs and docs

[Reindl Harald]

Am 26.02.2016 um 15:01 schrieb Reindl Harald:

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html#bufferedlogs
Context: server config

is that a documentation error or a error in the module that
"BufferedLogs Off" inside a vhost is accepted

the config below at least gives no error and it's unclear if it disables
the BufferedLogs from the global config entirely or is silently ignored


  
   BufferedLogs Off
   ...
  



looking with "tail -f" to a different bhost-specific logfile in fact it 
disables BufferedLogs globally instead  for only that vhost or raise a 
error witch "apachectl -t" that it is not allowed here


so it's a bug



signature.asc
Description: OpenPGP digital signature

BufferedLogs and docs

[Reindl Harald]

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html#bufferedlogs
Context: server config

is that a documentation error or a error in the module that 
"BufferedLogs Off" inside a vhost is accepted


the config below at least gives no error and it's unclear if it disables 
the BufferedLogs from the global config entirely or is silently ignored



 
  BufferedLogs Off
  ...
 




signature.asc
Description: OpenPGP digital signature

Re: httpd + systemd

[Reindl Harald]

Am 26.02.2016 um 10:57 schrieb Graham Leggett:

Hi all,

I am trying to come up with a vanilla systemd unit file so that our RPM 
packaging contains a sensible startup on systemd environments, but I’m 
struggling.

With the unit file below the “systemctl restart httpd” command hangs. Usually 
the server starts fine, but then the server is stopped by something a short 
while afterwards for no clear reason. According to google the hang in systemctl 
happens for many people, systemctl is waiting for a message that never comes, 
but the causes are widely varied and I am struggling to figure out exactly what 
is wrong.

What I am trying to achieve is a simple daemon start, with no mod_systemd 
(which isn’t part of core httpd).

Can anyone point out any obvious errors in the following?


i would recommend the following which is in use here starting in 2012 on 
all servers, with the no-forking the mainpid for systemd is clear and by 
stop the service all processes get a SIGTERM from systemd


that works also with mpm-prefork perfectly (we use prefork)

while i understand the "give httpd some time to finish gracefully" in 
case of a hard restart it has the drawback that new connections are not 
accepted for that time-period and so it has negative impact


in case of a SIGTERM the daemon is supposed to do a clean shutdown anyways

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
Restart=always
RestartSec=1


[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Service]
Type=forking
PIDFile=/var/run/httpd.pid
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
# We want systemd to give httpd some time to finish gracefully, but still want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true

[Install]
WantedBy=multi-user.target




signature.asc
Description: OpenPGP digital signature

httpd + systemd

[Graham Leggett]

Hi all,

I am trying to come up with a vanilla systemd unit file so that our RPM 
packaging contains a sensible startup on systemd environments, but I’m 
struggling.

With the unit file below the “systemctl restart httpd” command hangs. Usually 
the server starts fine, but then the server is stopped by something a short 
while afterwards for no clear reason. According to google the hang in systemctl 
happens for many people, systemctl is waiting for a message that never comes, 
but the causes are widely varied and I am struggling to figure out exactly what 
is wrong.

What I am trying to achieve is a simple daemon start, with no mod_systemd 
(which isn’t part of core httpd).

Can anyone point out any obvious errors in the following?

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Service]
Type=forking
PIDFile=/var/run/httpd.pid
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
# We want systemd to give httpd some time to finish gracefully, but still want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Regards,
Graham
—

Re: where to put update_mime_types.pl?

[Stefan Eissing]

+1 

> Am 26.02.2016 um 10:45 schrieb Ruediger Pluem :
> 
> 
> 
> On 02/26/2016 01:46 AM, Roy T. Fielding wrote:
>> I have a perl script (see below) for updating the mime.types file with the 
>> latest
>> registered IANA media types.  I would like to add it to our version control,
>> but I am unsure whether to place it in
>> 
>>  httpd/trunk/support/
>> 
>> or in
>> 
>>  httpd/docs-build/trunk/
> 
> For now I would would vote for
> 
> httpd/docs-build/trunk/
> 
> Regards
> 
> Rüdiger
> 

Re: where to put update_mime_types.pl?

[Ruediger Pluem]

On 02/26/2016 01:46 AM, Roy T. Fielding wrote:
> I have a perl script (see below) for updating the mime.types file with the 
> latest
> registered IANA media types.  I would like to add it to our version control,
> but I am unsure whether to place it in
> 
>   httpd/trunk/support/
> 
> or in
> 
>   httpd/docs-build/trunk/

For now I would would vote for

httpd/docs-build/trunk/

Regards

Rüdiger