Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Jack M. Nilles
Eureka!! I found a new or recently revised file: /etc/apache2/listen.conf. That 
had a pair of listen lines under NameVirtualHost that I commented out. 
Restarting apache then produced a running server.

Thanks, guys, for your patience and help! I will keep your emails in my 
Whatthehell? folder for future reference.




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Frank Gingras
vhosts do not bind to ports - the Listen directive does.

On Thu, Oct 4, 2018 at 3:17 PM Filipe Cifali 
wrote:

> Because something else could be listening on those ports, preventing httpd
> from starting. This is not so uncommon to happen. httpd is complaining on
> listening to both IPv4 and IPv6, so maybe a greedy virtualhost is trying to
> map more addresses than it should?
>
> On Thu, Oct 4, 2018 at 3:59 PM Jack M. Nilles  wrote:
>
>> Of course, since Apache isn't running -- failed to start -- why would I
>> get any LISTEN ports?
>>
>> On 4 Oct 2018, at 11:46, Jack M. Nilles  wrote:
>>
>> Here's what I get for the first part of that:
>>
>> * #* netstat -napo | egrep "(:80|:443)"
>> tcp0  0 1.2.3.4:43160 23.210.206.246*:443*
>> ESTABLISHED 1961/(squid-1)  off (0.00/0/0)
>> tcp0  0 1.2.3.4:59116 107.14.47.80*:80*
>> TIME_WAIT   -   timewait (45.97/0/0)
>> tcp0  0 1.2.3.4:48181 52.20.156.66*:443*
>> ESTABLISHED 1961/(squid-1)  off (0.00/0/0)
>> tcp0  0 1.2.3.4:41114 17.248.129.179*:443*
>> TIME_WAIT   -   timewait (58.11/0/0)
>> tcp0  0 1.2.3.4:55151 52.32.170.59*:443*
>> ESTABLISHED 1961/(squid-1)  off (0.00/0/0)
>> tcp0  0 1.2.3.4:59019 172.217.14.74*:443*
>> TIME_WAIT   -   timewait (33.72/0/0)
>> tcp0  0 1.2.3.4:52752 216.17.8.47*:443*
>> ESTABLISHED 710/javakeepalive (320.48/0/0)
>>
>>
>> and I get no return for *#* netstat -napo | egrep "(:80|:443)" | grep
>> LISTEN
>>
>> On 4 Oct 2018, at 11:13, Filipe Cifali  wrote:
>>
>> netstat -napo|egrep "(:80|:443) |grep LISTEN
>>
>>
>>
>>
>
> --
> [ ]'s
>
> Filipe Cifali Stangler
>


Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Filipe Cifali
Because something else could be listening on those ports, preventing httpd
from starting. This is not so uncommon to happen. httpd is complaining on
listening to both IPv4 and IPv6, so maybe a greedy virtualhost is trying to
map more addresses than it should?

On Thu, Oct 4, 2018 at 3:59 PM Jack M. Nilles  wrote:

> Of course, since Apache isn't running -- failed to start -- why would I
> get any LISTEN ports?
>
> On 4 Oct 2018, at 11:46, Jack M. Nilles  wrote:
>
> Here's what I get for the first part of that:
>
> * #* netstat -napo | egrep "(:80|:443)"
> tcp0  0 1.2.3.4:43160 23.210.206.246*:443*
> ESTABLISHED 1961/(squid-1)  off (0.00/0/0)
> tcp0  0 1.2.3.4:59116 107.14.47.80*:80* TIME_WAIT
>   -   timewait (45.97/0/0)
> tcp0  0 1.2.3.4:48181 52.20.156.66*:443*
> ESTABLISHED 1961/(squid-1)  off (0.00/0/0)
> tcp0  0 1.2.3.4:41114 17.248.129.179*:443*  TIME_WAIT
>   -   timewait (58.11/0/0)
> tcp0  0 1.2.3.4:55151 52.32.170.59*:443*
> ESTABLISHED 1961/(squid-1)  off (0.00/0/0)
> tcp0  0 1.2.3.4:59019 172.217.14.74*:443*   TIME_WAIT
>   -   timewait (33.72/0/0)
> tcp0  0 1.2.3.4:52752 216.17.8.47*:443*
> ESTABLISHED 710/javakeepalive (320.48/0/0)
>
>
> and I get no return for *#* netstat -napo | egrep "(:80|:443)" | grep
> LISTEN
>
> On 4 Oct 2018, at 11:13, Filipe Cifali  wrote:
>
> netstat -napo|egrep "(:80|:443) |grep LISTEN
>
>
>
>

-- 
[ ]'s

Filipe Cifali Stangler


Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Jack M. Nilles
Of course, since Apache isn't running -- failed to start -- why would I get any 
LISTEN ports?

> On 4 Oct 2018, at 11:46, Jack M. Nilles  wrote:
> 
> Here's what I get for the first part of that:
> 
>  # netstat -napo | egrep "(:80|:443)"
> tcp0  0 1.2.3.4:43160 23.210.206.246:443  ESTABLISHED 
> 1961/(squid-1)  off (0.00/0/0)
> tcp0  0 1.2.3.4:59116 107.14.47.80:80 TIME_WAIT   -   
> timewait (45.97/0/0)
> tcp0  0 1.2.3.4:48181 52.20.156.66:443ESTABLISHED 
> 1961/(squid-1)  off (0.00/0/0)
> tcp0  0 1.2.3.4:41114 17.248.129.179:443  TIME_WAIT   -   
> timewait (58.11/0/0)
> tcp0  0 1.2.3.4:55151 52.32.170.59:443ESTABLISHED 
> 1961/(squid-1)  off (0.00/0/0)
> tcp0  0 1.2.3.4:59019 172.217.14.74:443   TIME_WAIT   -   
> timewait (33.72/0/0)
> tcp0  0 1.2.3.4:52752 216.17.8.47:443 ESTABLISHED 
> 710/javakeepalive (320.48/0/0)
> 
> and I get no return for # netstat -napo | egrep "(:80|:443)" | grep LISTEN
> 
>> On 4 Oct 2018, at 11:13, Filipe Cifali > > wrote:
>> 
>> netstat -napo|egrep "(:80|:443) |grep LISTEN
> 



Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Jack M. Nilles
Here's what I get for the first part of that:

 # netstat -napo | egrep "(:80|:443)"
tcp0  0 1.2.3.4:43160 23.210.206.246:443  ESTABLISHED 
1961/(squid-1)  off (0.00/0/0)
tcp0  0 1.2.3.4:59116 107.14.47.80:80 TIME_WAIT   - 
  timewait (45.97/0/0)
tcp0  0 1.2.3.4:48181 52.20.156.66:443ESTABLISHED 
1961/(squid-1)  off (0.00/0/0)
tcp0  0 1.2.3.4:41114 17.248.129.179:443  TIME_WAIT   - 
  timewait (58.11/0/0)
tcp0  0 1.2.3.4:55151 52.32.170.59:443ESTABLISHED 
1961/(squid-1)  off (0.00/0/0)
tcp0  0 1.2.3.4:59019 172.217.14.74:443   TIME_WAIT   - 
  timewait (33.72/0/0)
tcp0  0 67.52.184.146:52752 216.17.8.47:443 ESTABLISHED 
710/javakeepalive (320.48/0/0)

and I get no return for # netstat -napo | egrep "(:80|:443)" | grep LISTEN

> On 4 Oct 2018, at 11:13, Filipe Cifali  wrote:
> 
> netstat -napo|egrep "(:80|:443) |grep LISTEN



Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Eric Covener
On Thu, Oct 4, 2018 at 2:01 PM Jack M. Nilles  wrote:
>
> Here's what I get:
>
> # lsof -i:443
> COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> java 710  root  245u  IPv6  49204  0t0  TCP 
> server.site1.com:52752->central.crashplanpro.com:https (ESTABLISHED)
> squid   1961 squid   13u  IPv4  19134  0t0  TCP server.site1.com 
> 55151->ec2-52-32-170-59.us-west-2.compute.amazonaws.com:https (ESTABLISHED)
> squid   1961 squid   20u  IPv4 164585  0t0  TCP server.site1.com 
> 43093->a23-210-206-246.deploy.static.akamaitechnologies.com:https 
> (ESTABLISHED)
> squid   1961 squid   26u  IPv4  18354  0t0  TCP server.site1.com 
> 48181->ec2-52-20-156-66.compute-1.amazonaws.com:https (ESTABLISHED)
>
> and
>
> # apache2ctl restart
> httpd not running, trying to start
> (98)Address already in use: AH00072: make_sock: could not bind to address 
> [::]:443
> (98)Address already in use: AH00072: make_sock: could not bind to address 
> 0.0.0.0:80
> no listening sockets available, shutting down
> AH00015: Unable to open logs
>
> So four established connections, one of which is IPV6 (a backup resource). 
> Why am I limited to 4 connections?

Those aren't listening sockets. Your problem is more likely
overlapping Listens in Apache config files, not processes outside of
Apache.


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

-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Filipe Cifali
Jack, don't confuse INCOMING/OUTGOING connections with LISTEN.

Seems this site is gathering some info from other sites, you can see the
commands running *Java* and *squid*, if you have netstat installed
(otherwise just install it because it's super flexible and easy to use?)
run a `netstat -napo|egrep "(:80|:443) |grep LISTEN`

On Thu, Oct 4, 2018 at 3:01 PM Jack M. Nilles  wrote:

> Here's what I get:
>
> *#* lsof -i:443
> COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> java 710  root  245u  IPv6  49204  0t0  TCP server.site1.com:52752
> ->central.crashplanpro.com:https (ESTABLISHED)
> squid   1961 squid   13u  IPv4  19134  0t0  TCP server.site1.com
>  55151->ec2-52-32-170-59.us-west-2.compute.amazonaws.com:https
> (ESTABLISHED)
> squid   1961 squid   20u  IPv4 164585  0t0  TCP server.site1.com
>  43093->a23-210-206-246.deploy.static.akamaitechnologies.com:https
> (ESTABLISHED)
> squid   1961 squid   26u  IPv4  18354  0t0  TCP server.site1.com
>  48181->ec2-52-20-156-66.compute-1.amazonaws.com:https (ESTABLISHED)
>
> and
>
> *#* apache2ctl restart
> httpd not running, trying to start
> (98)Address already in use: AH00072: make_sock: could not bind to address
> [::]:443
> (98)Address already in use: AH00072: make_sock: could not bind to address
> 0.0.0.0:80
> no listening sockets available, shutting down
> AH00015: Unable to open logs
>
> So four established connections, one of which is IPV6 (a backup resource).
> Why am I limited to 4 connections?
>


-- 
[ ]'s

Filipe Cifali Stangler


Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Jack M. Nilles
Here's what I get:

# lsof -i:443
COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java 710  root  245u  IPv6  49204  0t0  TCP 
server.site1.com:52752->central.crashplanpro.com:https (ESTABLISHED)
squid   1961 squid   13u  IPv4  19134  0t0  TCP server.site1.com 
55151->ec2-52-32-170-59.us-west-2.compute.amazonaws.com:https (ESTABLISHED)
squid   1961 squid   20u  IPv4 164585  0t0  TCP server.site1.com 
43093->a23-210-206-246.deploy.static.akamaitechnologies.com:https (ESTABLISHED)
squid   1961 squid   26u  IPv4  18354  0t0  TCP server.site1.com 
48181->ec2-52-20-156-66.compute-1.amazonaws.com:https (ESTABLISHED)

and

# apache2ctl restart
httpd not running, trying to start
(98)Address already in use: AH00072: make_sock: could not bind to address 
[::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 
0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs

So four established connections, one of which is IPV6 (a backup resource). Why 
am I limited to 4 connections?

Re: [users@httpd] 403 error upon upgrade

2018-10-04 Thread Frank Gingras
http://wiki.apache.org/httpd/CouldNotBindToAddress will help you
troubleshoot that error.

On Wed, Oct 3, 2018 at 8:21 PM Filipe Cifali 
wrote:

> Jack, the logs saying you can't bind the addresses:
>
> Oct 03 14:44:01 donner start_apache2[3998]: (98)Address already in use:
> AH00072: make_sock: could not bind to address [::]:443
> Oct 03 14:44:01 donner start_apache2[3998]: (98)Address already in use:
> AH00072: make_sock: could not bind to address 0.0.0.0:80
> Oct 03 14:44:01 donner start_apache2[3998]: AH00015: Unable to open logs
>
> This are the important bits, also, you should set error_log and put debug
> level on it if you can't find out why.
>
> On Wed, Oct 3, 2018 at 7:15 PM Jack M. Nilles  wrote:
>
>> A few minutes later I get:
>>
>> apache2.service - The Apache Webserver
>>Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled)
>>Active: *failed* (Result: exit-code) since Wed 2018-10-03 15:10:27
>> PDT; 38s ago
>>   Process: 5147 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND
>> -k graceful-stop (code=exited, status=0/SUCCESS)
>>   Process: 5140 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND
>> -k start *(code=exited, status=1/FAILURE)*
>>  Main PID: 5140 (code=exited, status=1/FAILURE)
>>
>> This after I tracked down some port interference.
>>
>>
>>
>>
>
> --
> [ ]'s
>
> Filipe Cifali Stangler
>


Re: [users@httpd] 403 error upon upgrade

2018-10-03 Thread Filipe Cifali
Jack, the logs saying you can't bind the addresses:

Oct 03 14:44:01 donner start_apache2[3998]: (98)Address already in use:
AH00072: make_sock: could not bind to address [::]:443
Oct 03 14:44:01 donner start_apache2[3998]: (98)Address already in use:
AH00072: make_sock: could not bind to address 0.0.0.0:80
Oct 03 14:44:01 donner start_apache2[3998]: AH00015: Unable to open logs

This are the important bits, also, you should set error_log and put debug
level on it if you can't find out why.

On Wed, Oct 3, 2018 at 7:15 PM Jack M. Nilles  wrote:

> A few minutes later I get:
>
> apache2.service - The Apache Webserver
>Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled)
>Active: *failed* (Result: exit-code) since Wed 2018-10-03 15:10:27
> PDT; 38s ago
>   Process: 5147 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k
> graceful-stop (code=exited, status=0/SUCCESS)
>   Process: 5140 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND
> -k start *(code=exited, status=1/FAILURE)*
>  Main PID: 5140 (code=exited, status=1/FAILURE)
>
> This after I tracked down some port interference.
>
>
>
>

-- 
[ ]'s

Filipe Cifali Stangler


Re: [users@httpd] 403 error upon upgrade

2018-10-03 Thread Jack M. Nilles
A few minutes later I get:

apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled)
   Active: failed (Result: exit-code) since Wed 2018-10-03 15:10:27 PDT; 38s ago
  Process: 5147 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k 
graceful-stop (code=exited, status=0/SUCCESS)
  Process: 5140 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k 
start (code=exited, status=1/FAILURE)
 Main PID: 5140 (code=exited, status=1/FAILURE)

This after I tracked down some port interference.





Re: [users@httpd] 403 error upon upgrade

2018-10-03 Thread Jack M. Nilles
Well, I have now set SuSE's YaST to reconfigure apache2 using the same 
vhosts.conf file while ensuring that php5 is running. Now apache won't start. I 
have moved from a 403 error to a site can't be reached error. I get the 
following output from systemctl status apache2.service:

apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled)
   Active: failed (Result: exit-code) since Wed 2018-10-03 14:44:01 PDT; 6min 
ago
  Process: 4006 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k 
graceful-stop (code=exited, status=0/SUCCESS)
  Process: 3998 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k 
start (code=exited, status=1/FAILURE)
 Main PID: 3998 (code=exited, status=1/FAILURE)

Oct 03 14:44:01 donner start_apache2[3998]: (98)Address already in use: 
AH00072: make_sock: could not bind to address [::]:443
Oct 03 14:44:01 donner start_apache2[3998]: (98)Address already in use: 
AH00072: make_sock: could not bind to address 0.0.0.0:80
Oct 03 14:44:01 donner start_apache2[3998]: no listening sockets available, 
shutting down
Oct 03 14:44:01 donner start_apache2[3998]: AH00015: Unable to open logs
Oct 03 14:44:01 donner systemd[1]: apache2.service: main process exited, 
code=exited, status=1/FAILURE
Oct 03 14:44:01 donner start_apache2[4006]: httpd (no pid file) not running
Oct 03 14:44:01 donner systemd[1]: Failed to start The Apache Webserver.
Oct 03 14:44:01 donner systemd[1]: Unit apache2.service entered failed state.

Any hints?




Re: [users@httpd] 403 error upon upgrade

2018-10-03 Thread Frank Gingras
The main document root does not interfere with your vhosts. See:

http://httpd.apache.org/docs/current/vhosts/name-based.html#using (See note
about "Main host goes away")

On Wed, Oct 3, 2018 at 2:40 PM Jack M. Nilles  wrote:

> I just noticed, upon running 'apache2ctl -S', that the server root is
> listed as "/srv/www" and the document root as "/srv/www/htdocs" while the
> actual document roots are elsewhere (such as /home/data/site1/htdocs). I'm
> assuming that the vhosts.conf file takes care of this linkage. If it
> doesn't might that be the problem?
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>


Re: [users@httpd] 403 error upon upgrade

2018-10-03 Thread Jack M. Nilles
I just noticed, upon running 'apache2ctl -S', that the server root is listed as 
"/srv/www" and the document root as "/srv/www/htdocs" while the actual document 
roots are elsewhere (such as /home/data/site1/htdocs). I'm assuming that the 
vhosts.conf file takes care of this linkage. If it doesn't might that be the 
problem?



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Filipe Cifali
Jack, you have to either load mod_php (which comes from compiling /
installing PHP in a certain way) or change the way you are using PHP on the
overall with httpd. Searching for how to install mod_php on SUSE X (being X
the version you are running) should provide frutiferous info, but I'm a
debian/rhel user so I'm not sure how YaST does things its way.

On Tue, Oct 2, 2018 at 6:47 PM Jack M. Nilles  wrote:

> Frank,
>
> My main concern is to get apache to run with php at all, never mind
> scalability issues. So far everything looks fine except that it doesn't
> work. Maybe somewhere in the bowels of SuSE 42.1 there is an error.
>
> Jack
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-- 
[ ]'s

Filipe Cifali Stangler


Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Jack M. Nilles
Frank,

My main concern is to get apache to run with php at all, never mind scalability 
issues. So far everything looks fine except that it doesn't work. Maybe 
somewhere in the bowels of SuSE 42.1 there is an error.

Jack


-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Frank Gingras
Jack,

The point is not to use non-threaded to increase your performance and
scalability. The event mpm has the ability to run many threads per process,
which in turn can drastically increase the number of simultaneous clients
you can serve.

On Tue, Oct 2, 2018 at 4:34 PM Jack M. Nilles  wrote:

> mpm_prefork_module is/was loaded.
>
> On 2 Oct 2018, at 8:24, Frank Gingras  wrote:
>
> http://wiki.apache.org/httpd/php is a good starting point - I would
> recommend not using mod_php, unless you have a good reason to use it.
>
> Nowadays, mod_proxy_fcgi and php-fpm is trivial to set up, and allow you
> to use a threaded mpm, such as event.
>
> On Tue, Oct 2, 2018 at 11:21 AM Jack M. Nilles  wrote:
>
>> Sure enough, there seems to be no php module loaded:
>>
>> Loaded Modules:
>>  core_module (static)
>>  so_module (static)
>>  http_module (static)
>>  mpm_prefork_module (static)
>>  unixd_module (static)
>>  systemd_module (static)
>>  actions_module (shared)
>>  alias_module (shared)
>>  auth_basic_module (shared)
>>  authn_file_module (shared)
>>  authz_host_module (shared)
>>  authz_groupfile_module (shared)
>>  authz_user_module (shared)
>>  autoindex_module (shared)
>>  cgi_module (shared)
>>  dir_module (shared)
>>  env_module (shared)
>>  expires_module (shared)
>>  include_module (shared)
>>  log_config_module (shared)
>>  mime_module (shared)
>>  negotiation_module (shared)
>>  setenvif_module (shared)
>>  ssl_module (shared)
>>  userdir_module (shared)
>>  reqtimeout_module (shared)
>>  authn_core_module (shared)
>>  authz_core_module (shared)
>>  rewrite_module (shared)
>>  version_module (shared)
>>
>> How do I get it on  board?
>>
>>
>>
>


Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Jack M. Nilles
mpm_prefork_module is/was loaded.

> On 2 Oct 2018, at 8:24, Frank Gingras  wrote:
> 
> http://wiki.apache.org/httpd/php  is a good 
> starting point - I would recommend not using mod_php, unless you have a good 
> reason to use it.
> 
> Nowadays, mod_proxy_fcgi and php-fpm is trivial to set up, and allow you to 
> use a threaded mpm, such as event.
> 
> On Tue, Oct 2, 2018 at 11:21 AM Jack M. Nilles  > wrote:
> Sure enough, there seems to be no php module loaded:
> 
> Loaded Modules:
>  core_module (static)
>  so_module (static)
>  http_module (static)
>  mpm_prefork_module (static)
>  unixd_module (static)
>  systemd_module (static)
>  actions_module (shared)
>  alias_module (shared)
>  auth_basic_module (shared)
>  authn_file_module (shared)
>  authz_host_module (shared)
>  authz_groupfile_module (shared)
>  authz_user_module (shared)
>  autoindex_module (shared)
>  cgi_module (shared)
>  dir_module (shared)
>  env_module (shared)
>  expires_module (shared)
>  include_module (shared)
>  log_config_module (shared)
>  mime_module (shared)
>  negotiation_module (shared)
>  setenvif_module (shared)
>  ssl_module (shared)
>  userdir_module (shared)
>  reqtimeout_module (shared)
>  authn_core_module (shared)
>  authz_core_module (shared)
>  rewrite_module (shared)
>  version_module (shared)
>  
> How do I get it on  board?
> 
> 



Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Jack M. Nilles
The package manager (YaST) shows php5.5 as installed so it should have php-fpm 
in its code base.  

I notice that /etc/php5/apache2/php.ini at present has short_open_tag = Off 
which might be the clue to its ignoring all the code in these sites that use 
 -- or not. The commented text is a tad ambiguous.



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Filipe Cifali
Also double check what version of PHP SUSE server pkg manager is providing
now, this seems like a change of version where the pkg manager gone rogue
(maybe missing dependency on tree?)

On Tue, Oct 2, 2018 at 12:24 PM Frank Gingras  wrote:

> http://wiki.apache.org/httpd/php is a good starting point - I would
> recommend not using mod_php, unless you have a good reason to use it.
>
> Nowadays, mod_proxy_fcgi and php-fpm is trivial to set up, and allow you
> to use a threaded mpm, such as event.
>
> On Tue, Oct 2, 2018 at 11:21 AM Jack M. Nilles  wrote:
>
>> Sure enough, there seems to be no php module loaded:
>>
>> Loaded Modules:
>>  core_module (static)
>>  so_module (static)
>>  http_module (static)
>>  mpm_prefork_module (static)
>>  unixd_module (static)
>>  systemd_module (static)
>>  actions_module (shared)
>>  alias_module (shared)
>>  auth_basic_module (shared)
>>  authn_file_module (shared)
>>  authz_host_module (shared)
>>  authz_groupfile_module (shared)
>>  authz_user_module (shared)
>>  autoindex_module (shared)
>>  cgi_module (shared)
>>  dir_module (shared)
>>  env_module (shared)
>>  expires_module (shared)
>>  include_module (shared)
>>  log_config_module (shared)
>>  mime_module (shared)
>>  negotiation_module (shared)
>>  setenvif_module (shared)
>>  ssl_module (shared)
>>  userdir_module (shared)
>>  reqtimeout_module (shared)
>>  authn_core_module (shared)
>>  authz_core_module (shared)
>>  rewrite_module (shared)
>>  version_module (shared)
>>
>> How do I get it on  board?
>>
>>
>>

-- 
[ ]'s

Filipe Cifali Stangler


Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Frank Gingras
http://wiki.apache.org/httpd/php is a good starting point - I would
recommend not using mod_php, unless you have a good reason to use it.

Nowadays, mod_proxy_fcgi and php-fpm is trivial to set up, and allow you to
use a threaded mpm, such as event.

On Tue, Oct 2, 2018 at 11:21 AM Jack M. Nilles  wrote:

> Sure enough, there seems to be no php module loaded:
>
> Loaded Modules:
>  core_module (static)
>  so_module (static)
>  http_module (static)
>  mpm_prefork_module (static)
>  unixd_module (static)
>  systemd_module (static)
>  actions_module (shared)
>  alias_module (shared)
>  auth_basic_module (shared)
>  authn_file_module (shared)
>  authz_host_module (shared)
>  authz_groupfile_module (shared)
>  authz_user_module (shared)
>  autoindex_module (shared)
>  cgi_module (shared)
>  dir_module (shared)
>  env_module (shared)
>  expires_module (shared)
>  include_module (shared)
>  log_config_module (shared)
>  mime_module (shared)
>  negotiation_module (shared)
>  setenvif_module (shared)
>  ssl_module (shared)
>  userdir_module (shared)
>  reqtimeout_module (shared)
>  authn_core_module (shared)
>  authz_core_module (shared)
>  rewrite_module (shared)
>  version_module (shared)
>
> How do I get it on  board?
>
>
>


Re: [users@httpd] 403 error upon upgrade

2018-10-02 Thread Jack M. Nilles
Sure enough, there seems to be no php module loaded:

Loaded Modules:
 core_module (static)
 so_module (static)
 http_module (static)
 mpm_prefork_module (static)
 unixd_module (static)
 systemd_module (static)
 actions_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_file_module (shared)
 authz_host_module (shared)
 authz_groupfile_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 cgi_module (shared)
 dir_module (shared)
 env_module (shared)
 expires_module (shared)
 include_module (shared)
 log_config_module (shared)
 mime_module (shared)
 negotiation_module (shared)
 setenvif_module (shared)
 ssl_module (shared)
 userdir_module (shared)
 reqtimeout_module (shared)
 authn_core_module (shared)
 authz_core_module (shared)
 rewrite_module (shared)
 version_module (shared)
 
How do I get it on  board?




Re: [users@httpd] 403 error upon upgrade

2018-10-01 Thread Frank Gingras
It is indeed recommended *not* to use  for that very reason. If
the module isn't loaded, then those directives will not be evaluated. Run
apachectl -M to see loaded modules.

On Mon, Oct 1, 2018 at 5:27 PM Filipe Cifali 
wrote:

> Are you sure you have mod_php installed and active? This would explain the
> failing DirIndex and all of this sudden change
>
> On Mon, 1 Oct 2018 at 17:36 Jack M. Nilles  wrote:
>
>> /etc/apache2/conf.d/php5.conf is as follows:
>>
>> 
>>
>>SetHandler application/x-httpd-php
>>
>>
>>SetHandler application/x-httpd-php-source
>>
>> DirectoryIndex index.php4
>> DirectoryIndex index.php5
>> DirectoryIndex index.php
>> 
>>
>> Why this doesn't work is a mystery to me. Especially since it is included
>> as part of the vhosts.conf file. Should I put the '*Include
>> /etc/apache2/conf.d/*.conf*' directive earlier in the conf file? Does
>> the order make a difference?
>>
>> BTW, if I copy the current index.php file on site1 to index.html the
>> latter displays without the ssl decorations. However, the site still won't
>> display any php files.
>>
>>
>> --
> [ ]'s
>
> Filipe Cifali Stangler
>


Re: [users@httpd] 403 error upon upgrade

2018-10-01 Thread Filipe Cifali
Are you sure you have mod_php installed and active? This would explain the
failing DirIndex and all of this sudden change

On Mon, 1 Oct 2018 at 17:36 Jack M. Nilles  wrote:

> /etc/apache2/conf.d/php5.conf is as follows:
>
> 
>
>SetHandler application/x-httpd-php
>
>
>SetHandler application/x-httpd-php-source
>
> DirectoryIndex index.php4
> DirectoryIndex index.php5
> DirectoryIndex index.php
> 
>
> Why this doesn't work is a mystery to me. Especially since it is included
> as part of the vhosts.conf file. Should I put the '*Include
> /etc/apache2/conf.d/*.conf*' directive earlier in the conf file? Does the
> order make a difference?
>
> BTW, if I copy the current index.php file on site1 to index.html the
> latter displays without the ssl decorations. However, the site still won't
> display any php files.
>
>
> --
[ ]'s

Filipe Cifali Stangler


Re: [users@httpd] 403 error upon upgrade

2018-10-01 Thread Jack M. Nilles
/etc/apache2/conf.d/php5.conf is as follows:


   
   SetHandler application/x-httpd-php
   
   
   SetHandler application/x-httpd-php-source
   
DirectoryIndex index.php4
DirectoryIndex index.php5
DirectoryIndex index.php


Why this doesn't work is a mystery to me. Especially since it is included as 
part of the vhosts.conf file. Should I put the 'Include 
/etc/apache2/conf.d/*.conf' directive earlier in the conf file? Does the order 
make a difference?

BTW, if I copy the current index.php file on site1 to index.html the latter 
displays without the ssl decorations. However, the site still won't display any 
php files.




Re: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Frank Gingras
It worked before because you had other DirectoryIndex directives (mostly
unaware of that fact).

Now, you need DIrectoryIndex index.html index.php or just DirectoryIndex
index.php

On Sun, Sep 30, 2018 at 4:36 PM Jack M. Nilles  wrote:

> I don't have an index.html in that directory -- only index.php. I suppose
> I could put in an html file that immediately switches to the php page. That
> site has always worked before with no index.html file. Why not now?
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>


Re: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Jack M. Nilles
I don't have an index.html in that directory -- only index.php. I suppose I 
could put in an html file that immediately switches to the php page. That site 
has always worked before with no index.html file. Why not now?



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Frank Gingras
Make sure that /home/data/site1/htdocs/index.html exists, first.

If you want to allow directory listings, then use Options +Indexes (don't
mix relative and absolution options).

On Sun, Sep 30, 2018 at 3:14 PM Jerry Martinez  wrote:

> Also, it was not clear as to what exactly was upgraded - the SUSE OS,
> Apache
> or PHP? I assumed PHP since I experienced issues going from 5 to 7. mod_php
> with PHP 5 and ZTS worked fine but everything broke with PHP 7. It turns
> out
> PHP7 ZTS is broken. Once I transitioned to PHP-FPM, everything worked
> flawlessly.
>
>
> Jerry Martinez
> Owner & Lead Developer
>
> JM Web Services, Inc
> 786.412.1660 | www.jmweb.net
>
>
> -Original Message-
> From: Jerry Martinez [mailto:je...@jmweb.net]
> Sent: Sunday, September 30, 2018 2:47 PM
> To: 'users@httpd.apache.org'
> Subject: RE: [users@httpd] 403 error upon upgrade
>
> I am running PHP 7.2.10 on SUSE Linux Enterprise 12 SP2 via PHP-FPM. I have
> a hunch your issues are PHP-FPM related. When PHP5 was working for you were
> you running mod_php or PHP-FPM? If your PHP7 install is set to use PHP-FPM,
> I do not see anywhere in your config that ties each Apache Vhost to a
> PHP-FPM pool. This explains your path issues and PHP unable to parse your
> PHP files.
>
> This is a good resource to follow: https://wiki.apache.org/httpd/PHP-FPM
>
>
> Jerry Martinez
>
>
> -Original Message-
> From: Richard [mailto:lists-apa...@listmail.innovate.net]
> Sent: Sunday, September 30, 2018 2:14 PM
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] 403 error upon upgrade
>
>
>
> > Date: Sunday, September 30, 2018 10:44:28 -0700
> > From: "Jack M. Nilles" 
> >
> > Basically the same as before:
> >
> > [Sun Sep 30 10:29:05.708882 2018] [autoindex:error] [pid 3663] [client
> > 220.181.51.119:50416] AH01276: Cannot serve directory
> > /home/data/site1/htdocs/: No matching DirectoryIndex
> > (index.html,index.html.var) found, and server-generated directory
> > index forbidden by Options directive
>
> The "index.html.var" directoryindex option is part of the (default) global
> setting. I would suggest searching your config file(s) for "DirectoryIndex"
> to locate all the instance(s) of "index.html.var".
> That will help you get a sense of context and what is and isn't being read
> as you would expect.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>


RE: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Jerry Martinez
Also, it was not clear as to what exactly was upgraded - the SUSE OS, Apache
or PHP? I assumed PHP since I experienced issues going from 5 to 7. mod_php
with PHP 5 and ZTS worked fine but everything broke with PHP 7. It turns out
PHP7 ZTS is broken. Once I transitioned to PHP-FPM, everything worked
flawlessly.


Jerry Martinez
Owner & Lead Developer

JM Web Services, Inc
786.412.1660 | www.jmweb.net


-Original Message-
From: Jerry Martinez [mailto:je...@jmweb.net] 
Sent: Sunday, September 30, 2018 2:47 PM
To: 'users@httpd.apache.org'
Subject: RE: [users@httpd] 403 error upon upgrade

I am running PHP 7.2.10 on SUSE Linux Enterprise 12 SP2 via PHP-FPM. I have
a hunch your issues are PHP-FPM related. When PHP5 was working for you were
you running mod_php or PHP-FPM? If your PHP7 install is set to use PHP-FPM,
I do not see anywhere in your config that ties each Apache Vhost to a
PHP-FPM pool. This explains your path issues and PHP unable to parse your
PHP files.

This is a good resource to follow: https://wiki.apache.org/httpd/PHP-FPM


Jerry Martinez


-Original Message-
From: Richard [mailto:lists-apa...@listmail.innovate.net] 
Sent: Sunday, September 30, 2018 2:14 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] 403 error upon upgrade



> Date: Sunday, September 30, 2018 10:44:28 -0700
> From: "Jack M. Nilles" 
>
> Basically the same as before:
> 
> [Sun Sep 30 10:29:05.708882 2018] [autoindex:error] [pid 3663] [client 
> 220.181.51.119:50416] AH01276: Cannot serve directory
> /home/data/site1/htdocs/: No matching DirectoryIndex
> (index.html,index.html.var) found, and server-generated directory 
> index forbidden by Options directive

The "index.html.var" directoryindex option is part of the (default) global
setting. I would suggest searching your config file(s) for "DirectoryIndex"
to locate all the instance(s) of "index.html.var".
That will help you get a sense of context and what is and isn't being read
as you would expect. 



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



RE: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Jerry Martinez
I am running PHP 7.2.10 on SUSE Linux Enterprise 12 SP2 via PHP-FPM. I have
a hunch your issues are PHP-FPM related. When PHP5 was working for you were
you running mod_php or PHP-FPM? If your PHP7 install is set to use PHP-FPM,
I do not see anywhere in your config that ties each Apache Vhost to a
PHP-FPM pool. This explains your path issues and PHP unable to parse your
PHP files.

This is a good resource to follow: https://wiki.apache.org/httpd/PHP-FPM


Jerry Martinez


-Original Message-
From: Richard [mailto:lists-apa...@listmail.innovate.net] 
Sent: Sunday, September 30, 2018 2:14 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] 403 error upon upgrade



> Date: Sunday, September 30, 2018 10:44:28 -0700
> From: "Jack M. Nilles" 
>
> Basically the same as before:
> 
> [Sun Sep 30 10:29:05.708882 2018] [autoindex:error] [pid 3663] [client 
> 220.181.51.119:50416] AH01276: Cannot serve directory
> /home/data/site1/htdocs/: No matching DirectoryIndex
> (index.html,index.html.var) found, and server-generated directory 
> index forbidden by Options directive

The "index.html.var" directoryindex option is part of the (default) global
setting. I would suggest searching your config file(s) for "DirectoryIndex"
to locate all the instance(s) of "index.html.var".
That will help you get a sense of context and what is and isn't being read
as you would expect. 



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Richard



> Date: Sunday, September 30, 2018 10:44:28 -0700
> From: "Jack M. Nilles" 
>
> Basically the same as before:
> 
> [Sun Sep 30 10:29:05.708882 2018] [autoindex:error] [pid 3663]
> [client 220.181.51.119:50416] AH01276: Cannot serve directory
> /home/data/site1/htdocs/: No matching DirectoryIndex
> (index.html,index.html.var) found, and server-generated directory
> index forbidden by Options directive

The "index.html.var" directoryindex option is part of the (default)
global setting. I would suggest searching your config file(s) for
"DirectoryIndex" to locate all the instance(s) of "index.html.var".
That will help you get a sense of context and what is and isn't being
read as you would expect. 



-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-09-30 Thread Jack M. Nilles
Basically the same as before:

[Sun Sep 30 10:29:05.708882 2018] [autoindex:error] [pid 3663] [client 
220.181.51.119:50416] AH01276: Cannot serve directory /home/data/site1/htdocs/: 
No matching DirectoryIndex (index.html,index.html.var) found, and 
server-generated directory index forbidden by Options directive

Jack Nilles



Re: [users@httpd] 403 error upon upgrade

2018-09-29 Thread Frank Gingras
What does the error log say now?

On Sat, Sep 29, 2018 at 5:01 PM Jack M. Nilles  wrote:

> I have found another DirectoryIndex directive in
> /etc/apache2/conf.d/gitweb.conf. Since this is higher up the chain than the
> vhosts.d directory that might be what's producing the file download
> behavior. If I omit the DirectoryIndex line and restart apache then I at
> least just get the 403 error but no file download.
>
> I have revised the vhosts.conf file to look like this:
>
> 
>
>  ServerAdmin webmas...@site1.com
>  ServerName www.site1.com
>  ServerAlias site1.com *.site1.com
>  DocumentRoot "/home/data/site1/htdocs"
>  SSLEngine on
>  SSLProtocol all -SSLv2
>  SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt
>  SSLCertificateKeyFile /etc/apache2/ssl.key/www_site1_com.key
>  SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt
>  RewriteEngine On
>  RewriteOptions Inherit
>
>  
> ##  To make the blog work with pretty permalinks use the next 2
> uncommented lines.
> ##  Otherwise use 'Options None' and 'AllowOverride None'. Should this be
> in a separate directory block for the blog
> ##  with some way, other than 'AllowOverride all'  of rewriting the
> wordpress blog filename?
>   AllowOverride None
>   Options FollowSymlinks
>   Require all granted
>  
>
>   AccessFileName .htaccess
>
>  ErrorLog /var/log/apache2/site1.com-error_log
>  CustomLog /var/log/apache2/site1.com-access_log combined
>
>  ScriptAlias /cgi-bin/ "/home/data/site1/cgi-bin/"
>  
>   AllowOverride None
>   Options +ExecCGI -Includes
>   Require all granted
>  
>
>  
>AuthName "By Invitation Only"
>AuthType Basic
>AuthUserFile "/etc/apache2/passwd/password"
>Require user 
>  
>
>   Include /etc/apache2/conf.d/*.conf
> 
>
> This still produces the 403 error with this configuration. I'm not sure
> what FallbackResource I should use and where to put it. I don't see any
> references to a FallbackResource, such as module, in the links you provided.
>
> Still muddled,
>
> Jack Nilles
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>


Re: [users@httpd] 403 error upon upgrade

2018-09-29 Thread Jack M. Nilles
I have found another DirectoryIndex directive in 
/etc/apache2/conf.d/gitweb.conf. Since this is higher up the chain than the 
vhosts.d directory that might be what's producing the file download behavior. 
If I omit the DirectoryIndex line and restart apache then I at least just get 
the 403 error but no file download.

I have revised the vhosts.conf file to look like this:



 ServerAdmin webmas...@site1.com
 ServerName www.site1.com
 ServerAlias site1.com *.site1.com
 DocumentRoot "/home/data/site1/htdocs"
 SSLEngine on
 SSLProtocol all -SSLv2
 SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt
 SSLCertificateKeyFile /etc/apache2/ssl.key/www_site1_com.key
 SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt
 RewriteEngine On
 RewriteOptions Inherit

 
##  To make the blog work with pretty permalinks use the next 2 uncommented 
lines.
##  Otherwise use 'Options None' and 'AllowOverride None'. Should this be in a 
separate directory block for the blog
##  with some way, other than 'AllowOverride all'  of rewriting the wordpress 
blog filename?
  AllowOverride None
  Options FollowSymlinks
  Require all granted
 

  AccessFileName .htaccess

 ErrorLog /var/log/apache2/site1.com-error_log
 CustomLog /var/log/apache2/site1.com-access_log combined

 ScriptAlias /cgi-bin/ "/home/data/site1/cgi-bin/"
 
  AllowOverride None
  Options +ExecCGI -Includes
  Require all granted
 

 
   AuthName "By Invitation Only"
   AuthType Basic
   AuthUserFile "/etc/apache2/passwd/password"
   Require user 
 

  Include /etc/apache2/conf.d/*.conf


This still produces the 403 error with this configuration. I'm not sure what 
FallbackResource I should use and where to put it. I don't see any references 
to a FallbackResource, such as module, in the links you provided.

Still muddled,

Jack Nilles




-
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



Re: [users@httpd] 403 error upon upgrade

2018-09-29 Thread Frank Gingras
You still need to set AllowOverride none in the  block to
prevent .htaccess files from interfering.

As for the index file being downloaded, if it's static content, see:

http://httpd.apache.org/docs/current/mod/mod_mime.html#addtype

If it's a php file, see:

http://wiki.apache.org/httpd/php

Lastly, read about context here:

http://httpd.apache.org/docs/current/mod/directive-dict.html#Context

On Fri, Sep 28, 2018 at 7:56 PM Jack M. Nilles  wrote:

> Frank,
>
> Sorry for the typos. I've corrected the code below to be consistent. The
> error message was, and is (I am anonymizing the directory details):
>
> [Fri Sep 28 15:15:39.301689 2018] [autoindex:error] [pid 17591] [client
> 1.2.3.4:45731] AH01276: Cannot serve directory /home/data/site1/htdocs/:
> No matching DirectoryIndex (index.html,index.html.var) found, and
> server-generated directory index forbidden by Options directive
>
> Anywhere I put the DirectoryIndex line in the vhosts.conf file it results
> in apache downloading the html of the index page but not displaying it. So
> I've commented it out at present.
>
> Please explain what you mean by 'vhost context'. I am unfamiliar with the
> FallbackResource directive.
> Thanks for our help; I'm still head scratching here.
>
> Jack Nilles
>
> On 28 Sep 2018, at 15:14, Frank Gingras  wrote:
>
> There is no reference to "webdir" anywhere in your configuration, so you
> effectively munged it to the point that we cannot help you.
>
> Further, I would recommend setting AllowOverride none in every single
>  block - the last thing you want is for a rogue .htaccess file
> to interfere. If the sole purpose of said .htaccess file is to set up
> permalinks, all you need is likely a single FallbackResource in the vhost
> context instead.
>
> Also, set the DirectoryIndex in the vhost context instead.
>
> On Thu, Sep 27, 2018 at 1:29 PM Jack M. Nilles  wrote:
>
>> Two days ago I upgraded my SUSE server. It serves three websites as
>> virtual sites. All of the sites run php. Upon restarting apache 2.4 I got
>> the following error message:
>>
>> [Wed Sep 26 07:36:55.666104 2018] [autoindex:error] [pid 12345] [client
>> 1.2.3.4:50430] AH01276: Cannot serve directory /webdir/htdocs/: No
>> matching DirectoryIndex (index.html,index.html.var) found, and
>> server-generated directory index forbidden by Options directive
>>
>> I have visited many help pages and forums on apache, tried most of the
>> suggested remedies, such as adding DirectoryIndex index.php, to no avail.
>>
>> Here is the vhosts.conf code for one of the sites:
>>
>> 
>>
>>   ServerAdmin webmas...@site1.com
>>   ServerName www.site1.com
>>   ServerAlias site1.com *.site1.com
>>   DocumentRoot "/home/data/site1/htdocs"
>>   SSLEngine on
>>   SSLProtocol all -SSLv2
>>   SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt
>> 
>>   SSLCertificateKeyFile /etc/apache2/ssl.key/www.site1.com.key
>>   SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt
>>   RewriteEngine On
>>   RewriteOptions Inherit
>>
> # DirectoryIndex index.php
>
>
>>  
>>   DirectoryIndex index.php
>> #  To make the blog work with pretty permalinks use the next 2
>> uncommented lines.
>> #  Otherwise use 'Options None' and 'AllowOverride None'
>>   Options FollowSymlinks
>>   AllowOverride all
>>   Require all granted
>>  
>>
>>   AccessFileName .htaccess
>>
>>  ErrorLog /var/log/apache2/site1.com-error_log
>>  CustomLog /var/log/apache2/site1.com-access_log combined
>>
>>  ScriptAlias /cgi-bin/ "/home/data/site1/cgi-bin/"
>>  
>>   AllowOverride None
>>   Options +ExecCGI -Includes
>>   Require all granted
>>  
>>
>> Include /etc/apache2/conf.d/*.conf
>>
>> 
>>
>> Adding the DirectoryIndex line has the strange result that, if I click
>> twice on the site in a browser, the page gets downloaded but the error
>> message remains!
>>
>> Any help would be appreciated. I have already spent two days in a
>> fruitless search for a solution. The sites had worked perfectly before the
>> "upgrade".
>>
>>
>


Re: [users@httpd] 403 error upon upgrade

2018-09-28 Thread Jack M . Nilles
Frank,

Sorry for the typos. I've corrected the code below to be consistent. The error 
message was, and is (I am anonymizing the directory details):

[Fri Sep 28 15:15:39.301689 2018] [autoindex:error] [pid 17591] [client 
1.2.3.4:45731] AH01276: Cannot serve directory /home/data/site1/htdocs/: No 
matching DirectoryIndex (index.html,index.html.var) found, and server-generated 
directory index forbidden by Options directive

Anywhere I put the DirectoryIndex line in the vhosts.conf file it results in 
apache downloading the html of the index page but not displaying it. So I've 
commented it out at present.

Please explain what you mean by 'vhost context'. I am unfamiliar with the 
FallbackResource directive.
Thanks for our help; I'm still head scratching here.

Jack Nilles

> On 28 Sep 2018, at 15:14, Frank Gingras  wrote:
> 
> There is no reference to "webdir" anywhere in your configuration, so you 
> effectively munged it to the point that we cannot help you.
> 
> Further, I would recommend setting AllowOverride none in every single 
>  block - the last thing you want is for a rogue .htaccess file to 
> interfere. If the sole purpose of said .htaccess file is to set up 
> permalinks, all you need is likely a single FallbackResource in the vhost 
> context instead.
> 
> Also, set the DirectoryIndex in the vhost context instead.
> 
> On Thu, Sep 27, 2018 at 1:29 PM Jack M. Nilles  > wrote:
> Two days ago I upgraded my SUSE server. It serves three websites as virtual 
> sites. All of the sites run php. Upon restarting apache 2.4 I got the 
> following error message:
> 
> [Wed Sep 26 07:36:55.666104 2018] [autoindex:error] [pid 12345] [client 
> 1.2.3.4:50430 ] AH01276: Cannot serve directory 
> /webdir/htdocs/: No matching DirectoryIndex (index.html,index.html.var) 
> found, and server-generated directory index forbidden by Options directive
> 
> I have visited many help pages and forums on apache, tried most of the 
> suggested remedies, such as adding DirectoryIndex index.php, to no avail.
> 
> Here is the vhosts.conf code for one of the sites:
> 
> http://1.2.3.4:443/>>
> 
>   ServerAdmin webmas...@site1.com 
>   ServerName www.site1.com 
>   ServerAlias site1.com  *.site1.com 
>   DocumentRoot "/home/data/site1/htdocs"
>   SSLEngine on
>   SSLProtocol all -SSLv2
>   SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt 
> 
>   SSLCertificateKeyFile /etc/apache2/ssl.key/www.site1.com.key 
> 
>   SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt
>   RewriteEngine On
>   RewriteOptions Inherit
# DirectoryIndex index.php
> 
>  
>   DirectoryIndex index.php
> #  To make the blog work with pretty permalinks use the next 2 uncommented 
> lines.
> #  Otherwise use 'Options None' and 'AllowOverride None'
>   Options FollowSymlinks
>   AllowOverride all
>   Require all granted
>  
> 
>   AccessFileName .htaccess
> 
>  ErrorLog /var/log/apache2/site1.com -error_log
>  CustomLog /var/log/apache2/site1.com -access_log combined
> 
>  ScriptAlias /cgi-bin/ "/home/data/site1/cgi-bin/"
>  
>   AllowOverride None
>   Options +ExecCGI -Includes
>   Require all granted
>  
> 
> Include /etc/apache2/conf.d/*.conf
> 
> 
> 
> Adding the DirectoryIndex line has the strange result that, if I click twice 
> on the site in a browser, the page gets downloaded but the error message 
> remains!
> 
> Any help would be appreciated. I have already spent two days in a fruitless 
> search for a solution. The sites had worked perfectly before the "upgrade".
> 



Re: [users@httpd] 403 error upon upgrade

2018-09-28 Thread Frank Gingras
There is no reference to "webdir" anywhere in your configuration, so you
effectively munged it to the point that we cannot help you.

Further, I would recommend setting AllowOverride none in every single
 block - the last thing you want is for a rogue .htaccess file
to interfere. If the sole purpose of said .htaccess file is to set up
permalinks, all you need is likely a single FallbackResource in the vhost
context instead.

Also, set the DirectoryIndex in the vhost context instead.

On Thu, Sep 27, 2018 at 1:29 PM Jack M. Nilles  wrote:

> Two days ago I upgraded my SUSE server. It serves three websites as
> virtual sites. All of the sites run php. Upon restarting apache 2.4 I got
> the following error message:
>
> [Wed Sep 26 07:36:55.666104 2018] [autoindex:error] [pid 12345] [client
> 1.2.3.4:50430] AH01276: Cannot serve directory /webdir/htdocs/: No
> matching DirectoryIndex (index.html,index.html.var) found, and
> server-generated directory index forbidden by Options directive
>
> I have visited many help pages and forums on apache, tried most of the
> suggested remedies, such as adding DirectoryIndex index.php, to no avail.
>
> Here is the code for one of the sites:
>
> 
>
>   ServerAdmin webmas...@site1.com
>   ServerName www.site1.com
>   ServerAlias site1.com *.site1.com
>   DocumentRoot "/home/sites/site1/htdocs"
>   SSLEngine on
>   SSLProtocol all -SSLv2
>   SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt
>   SSLCertificateKeyFile /etc/apache2/ssl.key/www.site1.com.key
>   SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt
>   RewriteEngine On
>   RewriteOptions Inherit
>
>  
>   DirectoryIndex index.php
> #  To make the blog work with pretty permalinks use the next 2 uncommented
> lines.
> #  Otherwise use 'Options None' and 'AllowOverride None'
>   Options FollowSymlinks
>   AllowOverride all
>   Require all granted
>  
>
>   AccessFileName .htaccess
>
>  ErrorLog /var/log/apache2/site1.com-error_log
>  CustomLog /var/log/apache2/site1.com-access_log combined
>
>  ScriptAlias /cgi-bin/ "/home/sites/site1/cgi-bin/"
>  
>   AllowOverride None
>   Options +ExecCGI -Includes
>   Require all granted
>  
>
> Include /etc/apache2/conf.d/*.conf
>
> 
>
> Adding the DirectoryIndex line has the strange result that, if I click
> twice on the site in a browser, the page gets downloaded but the error
> message remains!
>
> Any help would be appreciated. I have already spent two days in a
> fruitless search for a solution. The sites had worked perfectly before the
> "upgrade".
>
>


[users@httpd] 403 error upon upgrade

2018-09-27 Thread Jack M. Nilles
Two days ago I upgraded my SUSE server. It serves three websites as virtual 
sites. All of the sites run php. Upon restarting apache 2.4 I got the following 
error message:

[Wed Sep 26 07:36:55.666104 2018] [autoindex:error] [pid 12345] [client 
1.2.3.4:50430] AH01276: Cannot serve directory /webdir/htdocs/: No matching 
DirectoryIndex (index.html,index.html.var) found, and server-generated 
directory index forbidden by Options directive

I have visited many help pages and forums on apache, tried most of the 
suggested remedies, such as adding DirectoryIndex index.php, to no avail.

Here is the code for one of the sites:



  ServerAdmin webmas...@site1.com
  ServerName www.site1.com
  ServerAlias site1.com *.site1.com
  DocumentRoot "/home/sites/site1/htdocs"
  SSLEngine on
  SSLProtocol all -SSLv2
  SSLCertificateFile /etc/apache2/ssl.crt/WWW.SITE1.COM.crt
  SSLCertificateKeyFile /etc/apache2/ssl.key/www.site1.com.key
  SSLCertificateChainFile /etc/apache2/ssl.crt/ov_chain.txt
  RewriteEngine On
  RewriteOptions Inherit

 
  DirectoryIndex index.php
#  To make the blog work with pretty permalinks use the next 2 uncommented 
lines.
#  Otherwise use 'Options None' and 'AllowOverride None'
  Options FollowSymlinks
  AllowOverride all
  Require all granted
 

  AccessFileName .htaccess

 ErrorLog /var/log/apache2/site1.com-error_log
 CustomLog /var/log/apache2/site1.com-access_log combined

 ScriptAlias /cgi-bin/ "/home/sites/site1/cgi-bin/"
 
  AllowOverride None
  Options +ExecCGI -Includes
  Require all granted
 

Include /etc/apache2/conf.d/*.conf



Adding the DirectoryIndex line has the strange result that, if I click twice on 
the site in a browser, the page gets downloaded but the error message remains!

Any help would be appreciated. I have already spent two days in a fruitless 
search for a solution. The sites had worked perfectly before the "upgrade".