Re: httpd error.log
Hi Paul!
> Am 02.09.2022 um 14:52 schrieb Paul Pace :
>
> On 2022-09-01 13:20, Mike Fischer wrote:
>>> Am 01.09.2022 um 21:49 schrieb latin...@vcn.bc.ca:
> Am 01.09.2022 um 11:13 schrieb latin...@vcn.bc.ca:
> historia.agroena.org
Right, try something like this and watch the error.log:
curl --url 'https://historia.agroena.org/i-dont-exist.php' >/dev/null
HTH
Mike
>>> ok now:
>>> first i stop http rcctl stop httpd, then deleted error.log; and rcctl
>>> restart http! It is working correctly.
>>> thanks Mike
>> Not sure how that (or my advice for a test) would help, but I’m glad it did
>> :-)
>>> PS:
>>> Dokuwiki was working ok, but after the test, the browser says "file not
>>> found" and i am not able to access install.php! i did first # rcctl enable
>>> php74_fpm and rcctl start php74_fpm the httpd.con says root "www/dokuwiki"
>>> directly using consultores.ca/install.php!
>> root "www/dokuwiki" does not sound right. Are you using the standard
>> /var/www/dokuwiki directory for DW? If so it should be:
>> root "/dokuwiki"
>> Here is a similar setup I am using with DW from ports (Hogfather):
>> server "wiki.example.com" {
>> listen on $my_ipv6 tls port 443
>> tls {
>> certificate "/etc/ssl/acme/fullchain.pem"
>> key "/etc/ssl/acme/private/privkey.pem"
>> }
>> log style combined
>> authenticate "Private area" with "/conf/htpasswd-admin"
>> root "/dokuwiki"
>> directory index doku.php
>> connection max request body 2097152 # Default is 2M for
>> upload_max_filesize and 8M for post_max_size.
>> location "*.php" {
>> fastcgi socket "/run/php-fpm.sock"
>> }
>> location "/*.inc" { block }
>> location "/*.ht*" { block }
>> location "/data/*" { block }
>> location "/conf/*" { block }
>> location "/bin/*" { block }
>> location "/inc/*" { block }
>> location "/vendor/*" { block }
>
> The DokuWiki security page[1] states:
>
> The following directories should not be accessible from the web:
>
>data
>conf
>bin
>inc (isn't dangerous when accessible, though)
>vendor (leaks info about your environment)
>
>
> And httpd.conf(5)[2] states:
>
>> In case of multiple location statements in the same context, the first
>> matching location statement will be put into effect, while all later ones
>> will be ignored. Therefore it is advisable to match for more specific paths
>> first and for generic ones later on.
>
> In regards to the current configuration, I believe the matches that pass
> should be last and matches that block directories should be listed first. Or,
> alternatively, and better, would be to figure out exactly which .php files
> are required for the package to run, then make a location rule for each file
> (unless someone can figure out how to make something the equivalent of a
> logical or statement (regex: (this|that)) in a single location or location
> match block to have each of the required .php files pass.
>
> When I read the configuration, it appears in the reverse order of what is
> recommended by DokuWiki, so in the above configuration a request for:
>
> https://wiki.example.com/data/acl.auth.php
>
> will be passed to php-fpm.sock because that will be matched by the first
> location. I have no idea the damage to be done with this or other files, but
> it is against the security guidance of the project.
>
> It seems like the correct order should be to have the following order of
> locations:
>
> location "/*.inc" { block }
> location "/*.ht*" { block }
> location "/data/*" { block }
> location "/conf/*" { block }
> location "/bin/*" { block }
> location "/inc/*" { block }
> location "/vendor/*" { block }
> location "*.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
>
> However, I have not tested this.
I just did test this and you are absolutely correct! Thanks for pointing that
out. I had missed this in httpd.conf(5). I’ll change all of my configs
accordingly.
Mike
Re: httpd error.log
> Am 01.09.2022 um 11:05 schrieb Mischa :
>
> Those are indeed reasons for it to present the error.
> In my experience this also happens when a non-existent PHP script is
> requested, as the match is on *.php.
I tried to create a testing setup to verify this, but I keep getting „Access
denied“ or log entries such as "Access to the script '/test' has been denied
(see security.limit_extensions)“ instead of „Primary script unknown“ if I
request non-existant .php paths.
As I am still getting spurious „Primary script unknown“ entries I’ll try
monitoring using:
tail -f /var/www/logs/error.log /var/www/logs/access.log
to see which requests led to these entries.
(Having timestamps in error.log would make this so much easier!)
Mike
>
> Mischa
>
> On 2022-09-01 10:41, Mike Fischer wrote:
>> This happens when PHP-FPM can’t find the script to execute.
>> One reason could be that you fiddled with the settings and let PHP-FPM run
>> without chroot(2), while httpd(8) is running with chroot(2).
>> But it might also be a misconfiguration of in httpd.conf. Not sure about all
>> of the potential reasons but I occasionally see this error as well on a
>> setup which should be configured correctly. I have not checked wether some
>> spurious external HTTP requests could be causing this.
>> My httpd.conf basically looks like this:
>> server "servername.example.com" {
>>…
>>location "*.php" {
>>fastcgi socket "/run/php-fpm.sock"
>>}
>> }
>> It’s a bit sad that these logs don’t contain timestamps. Makes matching
>> against access logs harder.
>> HTH
>> Mike
>>> Am 01.09.2022 um 10:12 schrieb latin...@vcn.bc.ca:
>>> Hello
>>> OBSD 7.1 amd64, vultr vm:
>>> This is my httpd error.log, does somebody know what is happening please?
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
>>> Primary script unknown
Re: httpd error.log
>
>> Am 01.09.2022 um 21:49 schrieb latin...@vcn.bc.ca:
>>
>>>
Am 01.09.2022 um 11:13 schrieb latin...@vcn.bc.ca:
historia.agroena.org
>>>
>>> Right, try something like this and watch the error.log:
>>>
>>> curl --url 'https://historia.agroena.org/i-dont-exist.php' >/dev/null
>>>
>>> HTH
>>> Mike
>>>
>>
>> ok now:
>>
>> first i stop http rcctl stop httpd, then deleted error.log; and rcctl
>> restart http! It is working correctly.
>> thanks Mike
>
> Not sure how that (or my advice for a test) would help, but Iâm glad it
> did :-)
>
>
>> PS:
>> Dokuwiki was working ok, but after the test, the browser says "file not
>> found" and i am not able to access install.php! i did first # rcctl
>> enable
>> php74_fpm and rcctl start php74_fpm the httpd.con says root
>> "www/dokuwiki"
>> directly using consultores.ca/install.php!
>
> root "www/dokuwiki" does not sound right. Are you using the standard
> /var/www/dokuwiki directory for DW? If so it should be:
> root "/dokuwiki"
>
> Here is a similar setup I am using with DW from ports (Hogfather):
> server "wiki.example.com" {
> listen on $my_ipv6 tls port 443
>
> tls {
> certificate "/etc/ssl/acme/fullchain.pem"
> key "/etc/ssl/acme/private/privkey.pem"
> }
>
> log style combined
>
> authenticate "Private area" with "/conf/htpasswd-admin"
>
> root "/dokuwiki"
> directory index doku.php
>
> connection max request body 2097152 # Default is 2M for
> upload_max_filesize and 8M for post_max_size.
>
> location "*.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
>
> location "/*.inc" { block }
> location "/*.ht*" { block }
> location "/data/*" { block }
> location "/conf/*" { block }
> location "/bin/*" { block }
> location "/inc/*" { block }
> location "/vendor/*" { block }
> }
>
> You can leave out the authenticate line if you donât want HTTP Basic
> authentication (on top of DokuWiki authentication). This is running with
> php74_fpm but I also have instances of DW manually updated to Igor running
> with php80_fpm. php81_fpm is probably fine as well for Igor but I have not
> tested that yet. For Hogfather (from ports) you need php74_fpm.
>
> Notes for Igor: Some plugins are still a WIP. Youâll see some PHP
> Warnings in logs and I needed to manually patch a few things in DW and
> some of the plugins I am using. In most cases I have opened issues
> upstream an some of them are already fixed in master. So some post-Igor
> release will see those fixes. For the plugins the process seems slower as
> they are less actively maintained.
>
>
> HTH
> Mike
>
>
Hey thanks again Mike
/dokuwiki works perfect, and the config is better than mine thank you very
much.
Re: httpd error.log
> Am 01.09.2022 um 21:49 schrieb latin...@vcn.bc.ca:
>
>>
>>> Am 01.09.2022 um 11:13 schrieb latin...@vcn.bc.ca:
>>>
>>> historia.agroena.org
>>
>> Right, try something like this and watch the error.log:
>>
>> curl --url 'https://historia.agroena.org/i-dont-exist.php' >/dev/null
>>
>> HTH
>> Mike
>>
>
> ok now:
>
> first i stop http rcctl stop httpd, then deleted error.log; and rcctl
> restart http! It is working correctly.
> thanks Mike
Not sure how that (or my advice for a test) would help, but I’m glad it did :-)
> PS:
> Dokuwiki was working ok, but after the test, the browser says "file not
> found" and i am not able to access install.php! i did first # rcctl enable
> php74_fpm and rcctl start php74_fpm the httpd.con says root "www/dokuwiki"
> directly using consultores.ca/install.php!
root "www/dokuwiki" does not sound right. Are you using the standard
/var/www/dokuwiki directory for DW? If so it should be:
root "/dokuwiki"
Here is a similar setup I am using with DW from ports (Hogfather):
server "wiki.example.com" {
listen on $my_ipv6 tls port 443
tls {
certificate "/etc/ssl/acme/fullchain.pem"
key "/etc/ssl/acme/private/privkey.pem"
}
log style combined
authenticate "Private area" with "/conf/htpasswd-admin"
root "/dokuwiki"
directory index doku.php
connection max request body 2097152 # Default is 2M for
upload_max_filesize and 8M for post_max_size.
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
location "/*.inc" { block }
location "/*.ht*" { block }
location "/data/*" { block }
location "/conf/*" { block }
location "/bin/*" { block }
location "/inc/*" { block }
location "/vendor/*" { block }
}
You can leave out the authenticate line if you don’t want HTTP Basic
authentication (on top of DokuWiki authentication). This is running with
php74_fpm but I also have instances of DW manually updated to Igor running with
php80_fpm. php81_fpm is probably fine as well for Igor but I have not tested
that yet. For Hogfather (from ports) you need php74_fpm.
Notes for Igor: Some plugins are still a WIP. You’ll see some PHP Warnings in
logs and I needed to manually patch a few things in DW and some of the plugins
I am using. In most cases I have opened issues upstream an some of them are
already fixed in master. So some post-Igor release will see those fixes. For
the plugins the process seems slower as they are less actively maintained.
HTH
Mike
Re: httpd error.log
> Am 01.09.2022 um 11:13 schrieb latin...@vcn.bc.ca: > > historia.agroena.org Right, try something like this and watch the error.log: curl --url 'https://historia.agroena.org/i-dont-exist.php' >/dev/null HTH Mike
Re: httpd error.log
> This happens when PHP-FPM canât find the script to execute.
>
> One reason could be that you fiddled with the settings and let PHP-FPM run
> without chroot(2), while httpd(8) is running with chroot(2).
>
> But it might also be a misconfiguration of in httpd.conf. Not sure about
> all of the potential reasons but I occasionally see this error as well on
> a setup which should be configured correctly. I have not checked wether
> some spurious external HTTP requests could be causing this.
>
> My httpd.conf basically looks like this:
> server "servername.example.com" {
> â¦
> location "*.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
> }
>
> Itâs a bit sad that these logs donât contain timestamps. Makes
> matching against access logs harder.
>
> HTH
> Mike
>
>> Am 01.09.2022 um 10:12 schrieb latin...@vcn.bc.ca:
>>
>> Hello
>>
>> OBSD 7.1 amd64, vultr vm:
>> This is my httpd error.log, does somebody know what is happening please?
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>> Primary script unknown
>
Hello Mike thanks to respond.
My 3 httpd.conf tested individually:
# $OpenBSD: httpd.conf,v 1.22 2020/11/04 10:34:18 denis Exp $
server "agroena.org" {
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI;
}
}
server "agroena.org" {
listen on * tls port 443
root "/htdocs/agroena.org"
tls {
certificate "/etc/ssl/agroena.org.fullchain.pem"
key "/etc/ssl/private/agroena.org.key"
}
location "/pub/*" {
directory auto index
}
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
}
After the error y tested:
server "consultores.ca" {
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI;
}
}
server "consultores.ca" {
listen on * tls port 443
root "/htdocs/consultores.ca"
tls {
certificate "/etc/ssl/consultores.ca.fullchain.pem"
key "/etc/ssl/private/consultores.ca.key"
}
location "/pub/*" {
directory auto index
}
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
}
And that one with Dokuwiki, having the same error:
server "historia.agroena.org" {
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI;
}
}
server "historia.agroena.org" {
listen on * tls port 443
root "/htdocs/historia"
tls {
certificate "/etc/ssl/agroena.org.fullchain.pem"
key "/etc/ssl/private/agroena.org.key"
}
location "/pub/*" {
directory auto index
}
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
location "*~" {
block drop
}
location match "/kb/data/" {
block drop
}
location match "/kb/conf/" {
block drop
}
location match "/kb/bin/" {
block drop
}
location match "/kb/inc/" {
block drop
}
location match "/kb/vendor/" {
block drop
}
}
PS:
I did not touch php_fpm, i jost did the installation with # rcctl enable
php_fpm and rcctl start pp_fpm i used the correct command indicated in
docs.
Re: httpd error.log
Those are indeed reasons for it to present the error.
In my experience this also happens when a non-existent PHP script is
requested, as the match is on *.php.
Mischa
On 2022-09-01 10:41, Mike Fischer wrote:
This happens when PHP-FPM can’t find the script to execute.
One reason could be that you fiddled with the settings and let PHP-FPM
run without chroot(2), while httpd(8) is running with chroot(2).
But it might also be a misconfiguration of in httpd.conf. Not sure
about all of the potential reasons but I occasionally see this error as
well on a setup which should be configured correctly. I have not
checked wether some spurious external HTTP requests could be causing
this.
My httpd.conf basically looks like this:
server "servername.example.com" {
…
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
}
It’s a bit sad that these logs don’t contain timestamps. Makes matching
against access logs harder.
HTH
Mike
Am 01.09.2022 um 10:12 schrieb latin...@vcn.bc.ca:
Hello
OBSD 7.1 amd64, vultr vm:
This is my httpd error.log, does somebody know what is happening
please?
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Primary script unknown
Re: httpd error.log
This happens when PHP-FPM can’t find the script to execute.
One reason could be that you fiddled with the settings and let PHP-FPM run
without chroot(2), while httpd(8) is running with chroot(2).
But it might also be a misconfiguration of in httpd.conf. Not sure about all of
the potential reasons but I occasionally see this error as well on a setup
which should be configured correctly. I have not checked wether some spurious
external HTTP requests could be causing this.
My httpd.conf basically looks like this:
server "servername.example.com" {
…
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
}
It’s a bit sad that these logs don’t contain timestamps. Makes matching against
access logs harder.
HTH
Mike
> Am 01.09.2022 um 10:12 schrieb latin...@vcn.bc.ca:
>
> Hello
>
> OBSD 7.1 amd64, vultr vm:
> This is my httpd error.log, does somebody know what is happening please?
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
> Primary script unknown
httpd error.log
Hello OBSD 7.1 amd64, vultr vm: This is my httpd error.log, does somebody know what is happening please? Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown Primary script unknown
