Dann vermute ich nicht Berechtigungen als Problem-Ursache.
Was mich stutzig macht ist:
Aus meiner Erfahrung sollte man nichts manuell ins VEnv reinkopieren. Schon wenn man das komplette VEnv an eine andere Stelle im Dateisystem verschiebt, gab es bei mir immer Probleme und es lies sich nicht mehr verwenden.
Also wenn wirklich was manuell verschoben oder kopiert wurde, dann würde ich empfehlen das VEnv neu aufzubauen. So wie @Gisman es exemplarisch gezeigt hat.
Ich habe mich schon länger nicht mehr mit Apache beschäftigt. Früher war es doch so, daß bei der Eingabe von localhost:80 der Inhalt der Datei /srv/www/htdocs/index.html im Browser angezeigt wurde; jetzt bekomme die Fehlermeldung 403 Zugriff verweigert, die Datei ist vorhanden.
sudo -u wwwrun cat /srv/www/htdocs/index.html
[sudo] Passwort für wwwrun:
<html>
<head>
<title> Test Apache </title>
</head>
<body>
<h1> Guten Tag </h1>
<p> Apache sollte funktionieren :-)</p>
</body>
</html>
systemctl status apache2
● apache2.service - The Apache Webserver
Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-04 10:40:54 CEST; 35min ago
Main PID: 1537 (httpd-prefork)
Status: "Processing requests..."
Tasks: 35
CGroup: /system.slice/apache2.service
├─1537 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
├─1763 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
├─1764 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
├─1765 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
├─1766 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
├─1767 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
├─1769 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
└─3348 /usr/sbin/httpd-prefork -DSYSCONFIG -Dpgadmin4.conf -C PidFile /var/run/httpd.pid -C Include /etc/apache2/sysconfig.d//loadmodule.conf -C Include /etc/apache2/sysconfig.d//>
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Hat sich da etwas verändert oder stimmt an meiner Apache-Installation etwas nicht. Ich habe Apache über YAST installiert.
Wo die Startpage gesucht wird, wird in der Apache Configuration über DocumentRoot, DirectoryIndex festgelegt.
Nur um sicher zu gehen, das die Apache-Threads wirklich als wwwrun ausgeführt werden, bitte das mal prüfen: ps -Ao pid,ppid,user,group,cmd | grep httpd | grep -v grep
Ich weiß, daß ich Apache unter einer früheren SuSe-Version am Laufen hatte. Ich werde mich mal im SuSe-Forum umschauen, vielleicht werde ich da fündig.
Ich melde mich dann wieder.
Hallo!
Zum Thema Apache:
Du kannst zwei Dinge tun:
PGadmin läuft mit seinem eigenen Server auf Port 5050, dann könntest du das direkt üver den Port ansprechen (muß in der FW freigegeben sein!) oder per mod_rewrite/mod_proxy eine Umleitung im Apachen einbauen.
Zur Portfreigabe: Wenn die FW nicht läuft habe ich den Eindruck, dass bei Suse per default alles gedroppt wird und nicht einfach weitergeleitet. Also mußt du die FW starten und in der Defaultzone die benötigten Dienste oder Ports freigeben.
PGAdmin wird über mod_wsgi eingebunden. Das ist die empfohlene Lösung. Hier steht wie das geht. Du musst nur aufpassen, das du mod_wsgi für Python3 installierst. (Hier ist auch der Punkt an dem ich hänge. Alle Pfade und Berechtigungen stimmen, allerdings wird die venv vom Apachen nicht erkannt )
So ist bei mir eine funktionierende Flask-App mittels Apache und WSGI konfiguriert.
Im letzten Abschnitt steht wie ich die VEnv in WSGI aktiviert habe.
Eventuell hilft das.
Privat verwende ich Arch und da habe ich auch kein activate_this.py mehr im VEnv.
Da sieht meine wsgi so aus.
import sys
import os
# Set real path
app_root_dir = '/path/to/website/'
os.chdir(app_root_dir)
sys.path.insert(0, app_root_dir)
# Load the application
from website import app as application
OS = linux2, welches ich als Pythonversion 2.* interpretiere
Version: Major: 2 Minor=7
Ich bräuchte aber wenigsten Version 3.4 von Python, welche ja installiert ist. Wo kann dem Environment beibringen, daß es bitte unter der Version 3.6.12 laufen soll ?
Ist ein bisschen doof, das Suse immer noch unter ‘python’ Python2 versteht. Der folgende Befehl sollte eine Virtuelle Umgebung mit Python 3 erzeugen. Wenn du mit WSGI arbeitest mußt du noch das Apache-Modul mod_wsgi tauschen.
zypper info apache2-mod_wsgi
Loading repository data...
Reading installed packages...
Information for package apache2-mod_wsgi:
-----------------------------------------
Repository : Main Repository
Name : apache2-mod_wsgi
Version : 4.5.18-lp152.4.7
Arch : x86_64
Vendor : openSUSE
Installed Size : 461.4 KiB
Installed : Yes
Status : up-to-date
Source package : apache2-mod_wsgi-4.5.18-lp152.4.7.src
Summary : A WSGI interface for Python web applications in Apache
Description :
The mod_wsgi adapter is an Apacheache module that provides a WSGI compliant
interface for hosting Python based web applications within Apache. The
adapter is written completely in C code against the Apache C runtime and
for hosting WSGI applications within Apache has a lower overhead than using
existing WSGI adapters for mod_python or CGI.