api Call fails / authz_core- Modul

Apache, Lighttpd, nginx, Cherokee
thor_pfosten
Posts: 19
Joined: 2016-02-03 14:35

api Call fails / authz_core- Modul

Post by thor_pfosten » 2018-01-18 15:36

Hallo,

auf meiner Webplattform (myownserver.com) habe ich Probs in Bezug mit dem Aufrufen einer API.
Es ist eine Lernplattform wie z.B. für Programmieren. Auf einem bestimmten HTML-Eingabeformular sollen
User ein Soucecode-Snippet reinpasten önnen. Nach Klick auf „den OK“ - Button des Formulars soll
das Snippet an einen anderen Server geschickt werden mit einer JUNIT-Umgebung. Die UNIT-Testresulte
sollen dann wieder im ursprünglichen Eingabeformular angezeigt werden.


Leider klappt der Call auf den JUNIT - Server nicht. Auf dem Server kommt nichts an. Nach Klicken des OK-Buttons kommt eine graue Seite im Browser.
Diese Seite funktioniert nicht

myownserver.com kann diese Anfrage momentan nicht verarbeiten.

HTTP ERROR 500

Die dazugehörigen Logs (Apache Error log):

[Thu Jan 18 21:35:35.838893 2018] [ssl:trace3] [pid 18671] ssl_engine_kernel.c(2027): [client 141.22.89.11:51685] OpenSSL: Exit: error in SSLv2/v3 read client hello A

[Thu Jan 18 21:35:35.838945 2018] [ssl:debug] [pid 18671] ssl_engine_io.c(1308): (70014)End of file found: [client 141.22.89.11:51685] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]

[Thu Jan 18 21:35:35.838955 2018] [ssl:info] [pid 18671] [client 141.22.89.11:51685] AH01998: Connection closed to child 7 with abortive shutdown (server myownserver.com:443)

[Thu Jan 18 21:35:36.162870 2018] [ssl:info] [pid 19007] [client 141.22.89.11:51694] AH01964: Connection to child 2 established (server myownserver.com:443)

[Thu Jan 18 21:35:36.162944 2018] [ssl:trace2] [pid 19007] ssl_engine_rand.c(126): Seeding PRNG with 656 bytes of entropy

[Thu Jan 18 21:35:36.163006 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1989): [client 141.22.89.11:51694] OpenSSL: Handshake: start

[Thu Jan 18 21:35:36.163019 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: before/accept initialization

[Thu Jan 18 21:35:36.163093 2018] [ssl:debug] [pid 19007] ssl_engine_kernel.c(2115): [client 141.22.89.11:51694] AH02043: SSL virtual host for servername myownserver.com found

[Thu Jan 18 21:35:36.163113 2018] [ssl:debug] [pid 19007] ssl_engine_kernel.c(2115): [client 141.22.89.11:51694] AH02043: SSL virtual host for servername myownserver.com found

[Thu Jan 18 21:35:36.163118 2018] [core:debug] [pid 19007] protocol.c(2211): [client 141.22.89.11:51694] AH03155: select protocol from , choices=h2,http/1.1 for server myownserver.com

[Thu Jan 18 21:35:36.163124 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: unknown state

[Thu Jan 18 21:35:36.163132 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: unknown state

[Thu Jan 18 21:35:36.163194 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: unknown state

[Thu Jan 18 21:35:36.163218 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: unknown state

[Thu Jan 18 21:35:36.163260 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: unknown state

[Thu Jan 18 21:35:36.429827 2018] [ssl:info] [pid 18837] [client 141.22.89.11:51695] AH01964: Connection to child 1 established (server myownserver.com:443)

[Thu Jan 18 21:35:36.429901 2018] [ssl:trace2] [pid 18837] ssl_engine_rand.c(126): Seeding PRNG with 656 bytes of entropy

[Thu Jan 18 21:35:36.429977 2018] [ssl:trace3] [pid 18837] ssl_engine_kernel.c(1989): [client 141.22.89.11:51695] OpenSSL: Handshake: start

[Thu Jan 18 21:35:36.429993 2018] [ssl:trace3] [pid 18837] ssl_engine_kernel.c(1998): [client 141.22.89.11:51695] OpenSSL: Loop: before/accept initialization

[Thu Jan 18 21:35:36.496403 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1998): [client 141.22.89.11:51694] OpenSSL: Loop: unknown state

[Thu Jan 18 21:35:36.496426 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(1993): [client 141.22.89.11:51694] OpenSSL: Handshake: done

[Thu Jan 18 21:35:36.496437 2018] [ssl:debug] [pid 19007] ssl_engine_kernel.c(2042): [client 141.22.89.11:51694] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

[Thu Jan 18 21:35:36.498399 2018] [ssl:debug] [pid 19007] ssl_engine_kernel.c(366): [client 141.22.89.11:51694] AH02034: Initial (No.1) HTTPS request received for child 2 (server myownserver.com:443), referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.498513 2018] [authz_core:debug] [pid 19007] mod_authz_core.c(809): [client 141.22.89.11:51694] AH01626: authorization result of Require all granted: granted, referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.498522 2018] [authz_core:debug] [pid 19007] mod_authz_core.c(809): [client 141.22.89.11:51694] AH01626: authorization result of <RequireAny>: granted, referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.498526 2018] [core:trace3] [pid 19007] request.c(304): [client 141.22.89.11:51694] request authorized without authentication by access_checker_ex hook: /question/preview.php, referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.526446 2018] [http:trace3] [pid 19007] http_filters.c(1089): [client 141.22.89.11:51694] Response sent with status 500, referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.526759 2018] [ssl:trace3] [pid 19007] ssl_engine_kernel.c(2008): [client 141.22.89.11:51694] OpenSSL: Write: SSL negotiation finished successfully

[Thu Jan 18 21:35:36.526863 2018] [ssl:debug] [pid 19007] ssl_engine_io.c(1044): [client 141.22.89.11:51694] AH02001: Connection closed to child 2 with standard shutdown (server myownserver.com:443)


Interessant ist der untere Teil, wo u.a. die Meldung "Response sent with status 500" mitgeloggt wurde.
Davor scheint das Apache-Modul "authz_core" in Aktion zu treten. Da scheint die Authorisierung nicht zu klappen.
"request authorized without authentication by access_checker_ex hook"

Ich will letztendlich, dass das obig genannte HTML-Formular fehlerfrei gesendet werden kann.
Wie kann ich hier vorgehen ?
Schätze das ist eine Authorisierings Prob. Gibt es Conf-Einstellung, um die Authorisierung zu erlauben ?
Modul authz_core ?

Jegliche Hilfe, Howtos diesbezüglich wären super.



Hier meine Systemdaten:
OS:Debian


root@myownserver.com:/var/log/apache2# apachectl -M
[Thu Jan 18 22:16:18.955184 2018] [core:trace3] [pid 20326] core.c(3289): Setting LogLevel for all modules to trace3

Loaded Modules:
core_module (static)
so_module (static)
watchdog_module (static)
http_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
unixd_module (static)
access_compat_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgi_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
filter_module (shared)
headers_module (shared)
mime_module (shared)
mpm_prefork_module (shared)
negotiation_module (shared)
php5_module (shared)
reqtimeout_module (shared)
rewrite_module (shared)
setenvif_module (shared)
socache_shmcb_module (shared)
ssl_module (shared)
h264_streaming_module (shared)
root@myownserver.com:/var/log/apache2#


root@myownserver.com:/var/log/apache2# apachectl -V
[Thu Jan 18 22:17:32.960351 2018] [core:trace3] [pid 20359] core.c(3289): Setting LogLevel for all modules to trace3
Server version: Apache/2.4.25 (Debian)
Server built: 2017-09-19T18:58:57
Server's Module Magic Number: 20120211:56
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"
root@myownserver.com:/var/log/apache2#
Danke an alle!

Beste Grüße

Thor

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: api Call fails / authz_core- Modul

Post by Joe User » 2018-01-18 16:01

Der Zugriff wird dreimal zugelassen, jeweils fett markiert:
[Thu Jan 18 21:35:36.498513 2018] [authz_core:debug] [pid 19007] mod_authz_core.c(809): [client 141.22.89.11:51694] AH01626: authorization result of Require all granted: granted, referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.498522 2018] [authz_core:debug] [pid 19007] mod_authz_core.c(809): [client 141.22.89.11:51694] AH01626: authorization result of <RequireAny>: granted, referer: https://myownserver.com/question/previe ... urseid=237

[Thu Jan 18 21:35:36.498526 2018] [core:trace3] [pid 19007] request.c(304): [client 141.22.89.11:51694] request authorized without authentication by access_checker_ex hook: /question/preview.php, referer: https://myownserver.com/question/previe ... urseid=237
Der Fehler tritt danach auf (http_filters.c), wobei die genaue Ursache nicht aus dem Log hervorgeht.

Wie sieht denn die betreffende VirtualHost-Config aus?
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

thor_pfosten
Posts: 19
Joined: 2016-02-03 14:35

Re: api Call fails / authz_core- Modul

Post by thor_pfosten » 2018-01-18 16:45

Hi,

super ...

Ich poste hier mal die entsprechende site - conf mit den Virtualhost-Einträge.
... hoffe das geht ok:
<VirtualHost _default_:443>
ServerName myownserver.com
ServerAdmin webmaster@localhost

DocumentRoot /var/www/html/learnplattform

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf

# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on

# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
# SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
# SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

# SSLCertificateFile /etc/ssl/myownserver.com/myownserver.com.pem
SSLCertificateFile /etc/ssl/myownserver.com/linux_intermediate.pem
SSLCertificateKeyFile /etc/ssl/myownserver.com/myownserver.com.key

# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt
#SSLCertificateChainFile /etc/ssl/myownserver.com/myownserver.com.csr

#SSLCertificateChainFile /etc/ssl/backup/linux_intermediate.pem

# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10

# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>
</IfModule>
Nachzutragen wäre das die HTML-Prog nicht in der oben angegebenen DocRoot liegt.
"/var/www/html/learnplattform" ist ein Symlink auf ein anderes Verzeichnis
ungefähr
"/home/git/plattform"
schädlich.
Ich schau grad noch mal nach FIlter-Logs.

Dank Dir für das schnelle Echo!

Beste Grüße
Thor

thor_pfosten
Posts: 19
Joined: 2016-02-03 14:35

Re: api Call fails / authz_core- Modul

Post by thor_pfosten » 2018-01-18 17:06

an anderer Stelle kommen folgende Logs hinsichtlich der filter:
[Thu Jan 18 23:57:05.107038 2018] [authz_core:debug] [pid 22455] mod_authz_core.c(809): [client 1.2.3.4:57896] AH01626: authorization result of Require all granted: granted, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.107145 2018] [authz_core:debug] [pid 22455] mod_authz_core.c(809): [client 1.2.3.4:57896] AH01626: authorization result of <RequireAny>: granted, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.107210 2018] [core:trace3] [pid 22455] request.c(304): [client 1.2.3.4:57896] request authorized without authentication by access_checker_ex hook: /question/edit.php, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.204593 2018] [filter:trace2] [pid 22455] mod_filter.c(188): [client 1.2.3.4:57896] Content-Type condition for 'deflate' did not match, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.204761 2018] [filter:trace2] [pid 22455] mod_filter.c(188): [client 1.2.3.4:57896] Content-Type condition for 'deflate' did not match, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.204859 2018] [filter:trace2] [pid 22455] mod_filter.c(188): [client 1.2.3.4:57896] Content-Type condition for 'deflate' did not match, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.204923 2018] [filter:trace2] [pid 22455] mod_filter.c(188): [client 1.2.3.4:57896] Content-Type condition for 'deflate' did not match, referer: https://myserver.com/course/view.php?id=237
[Thu Jan 18 23:57:05.204982 2018] [filter:trace2] [pid 22455] mod_filter.c(188): [client 1.2.3.4:57896] Content-Type condition for 'deflate' matched, referer: https://myserver.com/course/view.php?id=237
...trage mich jetzt mit dem Gedanken "mod_deflate" einfach zu deaktivieren.
... weiß aber grad nicht, was dadurch kaputt geht.

VG
Thor

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: api Call fails / authz_core- Modul

Post by Joe User » 2018-01-18 18:26

Auch an mod_deflate liegt es nicht.

Die VirtualHost-Config ist quasi leer und das sollte definitiv nicht so sein.
Du musst für jeden einzelnen VirtualHost eine eigenständige und vollständige VirtualHost-Config anlegen und das sowohl für Port 80 (HTTP) als auch Port 443 (HTTPS).

Für Port 80 ist das absolute Minumum in etwa:

Code: Select all

<VirtualHost *:80>
    ServerName devnull.example.com
    ServerAdmin webmaster@example.com
    CustomLog "/data/www/vhosts/_default_/logs/access_log" combined
    ErrorLog "/data/www/vhosts/_default_/logs/error_log"
    DocumentRoot "/data/www/vhosts/_default_/data"
    <Directory "/data/www/vhosts/_default_/data">
        Options None +FollowSymLinks
        AllowOverride Options FileInfo AuthConfig Limit
        Require all granted
    </Directory>
    <IfModule rewrite_module>
        RewriteEngine On
    </IfModule>
</VirtualHost>
Für Port 443 ist das absolute Minumum in etwa:

Code: Select all

<VirtualHost *:443>
    ServerName devnull.example.com
    ServerAdmin webmaster@example.com
    CustomLog "/data/www/vhosts/_default_/logs/ssl_access_log" combined
    ErrorLog "/data/www/vhosts/_default_/logs/ssl_error_log"
    DocumentRoot "/data/www/vhosts/_default_/data"
    <Directory "/data/www/vhosts/_default_/data">
        Options None +FollowSymLinks
        AllowOverride Options FileInfo AuthConfig Limit
        Require all granted
    </Directory>
    <IfModule rewrite_module>
        RewriteEngine On
    </IfModule>
    SSLEngine on
    SSLCertificateFile "/data/pki/certs/devnull.example.com.crt"
    SSLCertificateKeyFile "/data/pki/private/devnull.example.com.key"
</VirtualHost>
Beide Beispiele müssen zwingend angepasst und erweitert werden, die offizielle Doku hilft.

Auch der Rest der Konfiguration ist vermutlich noch nicht angepasst, so dass Du hier noch einiges an Arbeit vor Dir hast.

Danach schauen wir weiter.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

thor_pfosten
Posts: 19
Joined: 2016-02-03 14:35

Re: api Call fails / authz_core- Modul

Post by thor_pfosten » 2018-01-19 11:21

Hi Joe User,

ganz herzlichen Dank für deine Hilfe!
... bin jetzt mit deiner Hilfe und der Apache Doku am konfigurieren.
Grundsätzlich gibt es einiges an Conf-Einstellung schon in
/etc/apache2/apache2.conf
Sorry für die Frage aber ist hier die Litanei hier, dass
für meine beiden Hosts (i.e. Port 80 und 443 desselben Hosts)
die "/etc/apache2/apache2.conf" gleichsam gilt und diese dann
in den Einzelkonfigurationen , i.e.
/etc/apache2/sites-available/000-default.conf
/etc/apache2/sites-available/default-ssl.conf
überschrieben werden kann?
Dann bräuchte man evtl. nur
"/etc/apache2/apache2.conf" editieren.

Deine Empfehlung ?

in jedem Fall Danke für deine Hilfestellung...

Beste Grüße
Thor

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: api Call fails / authz_core- Modul

Post by Joe User » 2018-01-19 12:45

Alles was bereits in /etc/apache2/apache2.conf steht und für Dich passt, brauchst Du für Deine VirtualHosts nicht nochmal konfigurieren.
Alles was nicht passt oder nicht vorhanden ist aber benötigt wird, das musst Du für Deine VirtualHosts extra einzeln konfigurieren.

Die /etc/apache2/apache2.conf solltest Du nur bearbeiten, wenn Du genau weisst was Du tust. Davon bist Du aber noch etwas entfernt.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: api Call fails / authz_core- Modul

Post by Joe User » 2018-01-19 12:47

thor_pfosten wrote:
2018-01-19 11:21
Sorry für die Frage aber ist hier die Litanei hier, dass
für meine beiden Hosts (i.e. Port 80 und 443 desselben Hosts)
die "/etc/apache2/apache2.conf" gleichsam gilt und diese dann
in den Einzelkonfigurationen , i.e.
/etc/apache2/sites-available/000-default.conf
/etc/apache2/sites-available/default-ssl.conf
überschrieben werden kann?
Ja, so ist es.
thor_pfosten wrote:
2018-01-19 11:21
Dann bräuchte man evtl. nur
"/etc/apache2/apache2.conf" editieren.
Nein, das solltest Du nicht tun.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

thor_pfosten
Posts: 19
Joined: 2016-02-03 14:35

Re: api Call fails / authz_core- Modul

Post by thor_pfosten » 2018-01-26 11:45

Hi,

vielen Dank für die Hilfe.
Ich habe es inzwischen gefunden.

ich weiß nicht, ob es jemanden hilft aber...
Meine Situation war, dass ich auf Debian 9 upgegraded hatte.
Damit hat man dann auch mariadb und PHP 7 am Start. Das ist default-mäßig
auch "angesteuert". Leider hat man manchmal auch alte Applikationen
wie Moodle 2.9, alte Owncloud-Version etc. auf dem Server, die mit PHP 7 nicht klar kommen,
sondern PHP 5 brauchen. PHP 5 gibt es dann immer noch. Man kann
das über /etc/alternatives zuweisen. Leider fehlen hier aber viele
Plugins.
Was man braucht ist die PHP 5.6 Version vom PHP Packager Ondřej Surý.
Für das Einspielen über die sources.list git es How Tos im Netz.
Das funzt reibungslos. Dann muß man noch die Softlinks in /etc/alternatives
ändern (also php5 raus und php5.6 rein). Dann hat alle Plugins
am Start ... alles luppt!.

nur mal so falls es jemand interessiert..

Beste Grüße

Thor