ubuntuusers.de

Hallo zusammen, ich bin gerade umgestiegen von Windows auf Ubuntu wegen Nextcloud.

Ich hätte versucht Let's Encrypt nach dieser Anleitung zu installieren. https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-16-04

Nur wenn ich

sudo letsencrypt --apache -d meinedomain.de

ausführe, bekomme ich folgende Fehlermeldung.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(('There has been an error in parsing the file (%s): %s', u'/etc/apache2/sites-available/default', u'Syntax error'),)

Was heißt das genau für mich.

Vielen Dank im Voraus!

Gruß Christoph

Hallo Christoph, ich habe gestern auch mit Hilfe von Forenmitgliedern Zertifikate von let's encrypt erstellt. Ich habe zuerst certauto-bot benutzt und muss sagen, dass das Script getssl wesentlich angenehmer ist.

Hier findest du diesen Thread von vor einigen Tagen.

Ich würde dir gerne weiterhelfen. Könntest du mal deine vhost Konfiguration von Apache zeigen als auch den Namen der vHost Datei posten? Sie liegt im Verzeichnis /etc/apache2/sites-available/

Gruß Volker

Hallo Volker, vielen Dank für deine Antwort! Ja diesen Thread habe ich schon gesehen, dachte aber dass es bei Dir (kann ich jetzt sagen) da andere Probleme gab als bei mir.

Datei 000-default.conf:

<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	# 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
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

default:

/etc/phpmyadmin
/etc/letsencrypt

default-ssl.conf:

<IfModule mod_ssl.c>
	<VirtualHost _default_:443>
		ServerAdmin webmaster@localhost

		DocumentRoot /var/www/html

		# 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

		#   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

		#   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

	</VirtualHost>
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Danke das Du mir helfen möchtest!

Gruß Christoph

Hallo karpfensami, aus deinem vHost wird nicht klar unter welcher domain deine Nextcloud eigentlich laufen soll.

Hier habe ich mal einige Schritte für dich die als Anleitung bzw. Leitfaden dient. Bitte ersetze example.local durch deine domain oder deine DynDNS Adresse. Die Befehle wurden alle als root ausgeführt. Anmelden als root kannst du dich mit

sudo -i

Zertifikate erstellen mit Let's Encrypt und getssl Herunterladen von getssl

cd ~
git clone https://github.com/srvrco/getssl.git

Verschieben unter /etc

mv ~/getssl /etc

Domain anlegen für getssl

/etc/getssl/getssl -c example.local

getssl config deiner Domain anpassen unter

nano ~/.getssl/example.local/getssl.cfg

Hier mal ein Ausschnitt aus meiner Konfiguration

# Uncomment and modify any variables you need
# see https://github.com/srvrco/getssl/wiki/Config-variables for details
#
# The staging server is best for testing
#CA="https://acme-staging.api.letsencrypt.org"
# This server issues full certificates, however has rate limits
CA="https://acme-v01.api.letsencrypt.org"

#AGREEMENT="https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"

# Set an email address associated with your account - generally set at account level rather than domain.
ACCOUNT_EMAIL="webmaster@example.local"
ACCOUNT_KEY_LENGTH=4096
ACCOUNT_KEY="/etc/ssl/private/ca/ca.key"
PRIVATE_KEY_ALG="rsa"

# Additional domains - this could be multiple domains / subdomains in a comma separated list
# Note: this is Additional domains - so should not include the primary domain.
# SANS=www.example.local

# Acme Challenge Location. The first line for the domain, the following ones for each additional domain.
# If these start with ssh: then the next variable is assumed to be the hostname and the rest the location.
# An ssh key will be needed to provide you with access to the remote server.
# If these start with ftp: then the next variables are ftpuserid:ftppassword:servername:ACL_location
# These should be of the form "/path/to/your/website/folder/.well-known/acme-challenge"
# where "/path/to/your/website/folder/" is the path, on your web server, to the web root for your domain.
#ACL=('/var/www/cryptic.systems/web/.well-known/acme-challenge'
#     'ssh:server5:/var/www/cryptic.systems/web/.well-known/acme-challenge'
#     'ftp:ftpuserid:ftppassword:cryptic.systems:/web/.well-known/acme-challenge')
ACL=('/var/www/letsencrypt/.well-known/acme-challenge')

#Enable use of a single ACL for all checks
USE_SINGLE_ACL="true"

# Location for all your certs, these can either be on the server (so full path name) or using ssh as for the ACL
DOMAIN_CERT_LOCATION="/etc/ssl/public/example.local/domain.crt"
DOMAIN_KEY_LOCATION="/etc/ssl/private/example.local/domain.key"
CA_CERT_LOCATION="/etc/ssl/public/example.local/chain.crt"
#DOMAIN_CHAIN_LOCATION="" # this is the domain cert and CA cert
#DOMAIN_KEY_CERT_LOCATION="" # this is the domain_key and domain cert
#DOMAIN_PEM_LOCATION="" # this is the domain_key. domain cert and CA cert

# The command needed to reload apache / nginx or whatever you use
RELOAD_CMD="service apache2 reload"
# The time period within which you want to allow renewal of a certificate
#  this prevents hitting some of the rate limits.
RENEW_ALLOW="30"

# Define the server type. This can be https, ftp, ftpi, imap, imaps, pop3, pop3s, smtp,
# smtps_deprecated, smtps, smtp_submission, xmpp, xmpps, ldaps or a port number which
# will be checked for certificate expiry and also will be checked after
# an update to confirm correct certificate is running (if CHECK_REMOTE) is set to true
#SERVER_TYPE="https"
#CHECK_REMOTE="true"

# Use the following 3 variables if you want to validate via DNS
#VALIDATE_VIA_DNS="true"
#DNS_ADD_COMMAND=
#DNS_DEL_COMMAND=
#AUTH_DNS_SERVER=""
#DNS_WAIT=10
#DNS_EXTRA_WAIT=60

Anlegen der SSL-Verzeichnisstruktur

mkdir /etc/ssl/private/example.local -p
mkdir /etc/ssl/private/ca -p
mkdir /etc/ssl/public/example.local -p

.well-known Verzeichnisstruktur anlegen

/var/www/letsencrypt/.well-known/acme-challenge -p

.well-known als Alias in Apache config setzen

mkdir /etc/apache2/conf-available/ -p
touch /etc/apache2/conf-available/letsencrypt.conf
echo "Alias /.well-known /var/www/letsencrypt/.well-known" > /etc/apache2/conf-available/letsencrypt.conf

Alias config aktivieren unter apache2

a2enconf letsencrypt

SSL und Rewrite Modul von Apache aktivieren

a2enmod ssl
a2enmod rewrite

Apache Neustarten

service apache2 restart

Zertifikate erstellen mit getssl, die Zertifikate sollten nun in der SSL-Verzeichnisstruktur erstellt worden sein

/etc/getssl/getssl -f example.local

Zertifikate regelmäßig automatisch updaten durch cronjob

crontab -e -u root

Folgende Zeile am ende einfügen

# Zertifikate updaten
        0       0       *       *       *       /etc/getssl/getssl -a -q

Nextcloud einrichten unter Apache2 OPTIONAL: Falls nextcloud nicht unter /var/www/example.local/nextcloud installiert sein sollte

1
2

mkdir /var/www/example.local
mv /<pfad>/<von>/<nextcloud>/<Verzeichnis> /var/www/example.local

Am ende muss es das Verzeichnis /var/www/example.local/nextcloud geben, in diesem Verzeichnis befindet sich beispielsweise das Unterverzeichnis config.

vHost-Datei unter /etc/apache2/sites-availible/nextcloud.conf

<VirtualHost *:80>
        # Server Details
        ServerName      example.local
        ServerAlias     example.local
        ServerAdmin     webmaster@example.local

        # Wurzelverzeichnis und deren Einstellungen
        DocumentRoot /var/www/example.local/nextcloud
        <Directory /var/www/example.local/nextcloud>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                #Deny from all
                Allow from all
        </Directory>

        # Logs
        ErrorLog ${APACHE_LOG_DIR}/example.local/nextcloud/error.log
        CustomLog ${APACHE_LOG_DIR}/example.local/nextcloud/access.log combined

        # Umleiten auf HTTPS
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:443>
	# Server Details
        ServerName      example.local
        ServerAlias     example.local
        ServerAdmin     webmaster@example.local


	# SSLEngine aktivieren (Dafür muss das Modul ssl aktiviert sein, a2enmod ssl)
	#  Um Generelle SSL Optionen einstellen zu können. Diese SSL Optionen sind gültig für die Verbindung zwischen Client und Server.
	SSLEngine		on
	
	# SSLCertificateFile
	#  Pfadangabe der Zertifikatsdatei. Das Zertifikat beinhaltet die Signatur der Certificate Authority (CA) als Gültigkeitsnachweis.
        SSLCertificateFile      /etc/ssl/public/example.local/domain.crt

        # SSLCertificateKeyFile
	#  Pfadangabe des Privatekeys.
        SSLCertificateKeyFile   /etc/ssl/private/example.local/domain.key

        # SSLCertificateKeyFile
	#  Pfadangabe des Root-Bundles. Das Root-Bundle ist das Zertifikat der (CA). Es muss angegeben werden, damit der Client unter Angabe
	#  des Signierten Zertifkates seine eigene Prüfsumme bilden kann um der Seite das vertrauen aus zu sprechen.
        SSLCertificateChainFile /etc/ssl/public/example.local/chain.crt

	# SSLProtocol
	#  Legt fest, welcher SSL-Version genutzt werden soll zwischen Client und Server.
	SSLProtocol             all -SSLv2 -SSLv3

	# SSLCipherSuite
        #  Gibt die CiperSuite an, den Algorythmus, mit dem eine SSL-Verbindung zwischen Client und Server aufgebaut werden soll.
        SSLCipherSuite     	ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

	# SSLHonorCipherOrder 
	#  Wenn SSLHonorCipherOrder aktiviert ist (on), kann der Client keine CiperSuite vorgeben, die beim Aufbau der SSL Verbindung genutzt werden soll.
	#  Der Server gibt indemfall die CiperSuite vor.
	SSLHonorCipherOrder 	on 

	
	# HTTP Strict-Transport-Security
	#  Den Client anweisen, in Zukunft direkt per SSL eine Verbindung auf zu bauen, sodass die RewriteRule nicht gebraucht wird.
	Header always set Strict-Transport-Security "max-age=31536000;"


	# Wurzelverzeichnis und deren Einstellungen
        DocumentRoot /var/www/example.local/nextcloud
        <Directory /var/www/example.local/nextcloud>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                #Deny from all
                Allow from all
        </Directory>
	

	# Logs
        ErrorLog ${APACHE_LOG_DIR}/example.local/nextcloud/ssl_error.log
        CustomLog ${APACHE_LOG_DIR}/example.local/nextcloud/ssl_access.log 	combined

</VirtualHost>

Erstellen des Logverzeichnisses

mkdir /var/log/apache2/example.local/nextcloud -p

Optional: Alle anderen config's unter site-availible unter Apache deaktivieren

a2dissite *

Nextcloud unter Apache2 aktivieren

a2ensite nextcloud

Änderungen von Apache neu einlesen lassen

service apache2 reload

Das sollte soweit alles sein. Ich hoffe du hast keine Probleme, wenn du alles in der Reihenfolge machst.

Falls du wo stecken bleibst ruhig melden

Volker

Hallo Volker, vielen vielen DANK für die ausführliche Anleitung.

Leider bleibe ich hier hängen:

.well-known Verzeichnisstruktur anlegen

/var/www/letsencrypt/.well-known/acme-challenge -p

Da sich 1. der Ordner letsencrypt nicht auf dem Verzeichnis befindet, 2. sonder unter /etc/letsencrypt und dieser ist leer.

Gruß Christoph

karpfensami schrieb:

Leider bleibe ich hier hängen:

.well-known Verzeichnisstruktur anlegen

/var/www/letsencrypt/.well-known/acme-challenge -p

Da sich 1. der Ordner letsencrypt nicht auf dem Verzeichnis befindet, 2. sonder unter /etc/letsencrypt und dieser ist leer.

Der Ordner ist zu erstellen. Unter /etc/letsencrypt werden die Zertifkate, Keys und Einstellungen gespeichert, der ist keinesfalls zu veroeffentlichen!

sebix schrieb:

Der Ordner ist zu erstellen. Unter /etc/letsencrypt werden die Zertifkate, Keys und Einstellungen gespeichert, der ist keinesfalls zu veroeffentlichen!

Genau, Sebix hat Recht. Du darfst den nicht veröffentlichen. Du sollst das Verzeichnis /var/www/letsencrypt/.well-known/acme-challenge anlegen und veröffentlichen. In diesem Verzeichnis werden Validierungsdateien abgelegt, damit lets encrypt deine Domain verifizieren kann. Wenn das nicht überprüft werden kann, gibt es keine Zertifikate. Daher muss dieses Verzeichnis öffentlich sein und ist später unter <deine Domain oder DynDNS-Adresse>/.well-known verfügbar.

karpfensami schrieb:

Leider bleibe ich hier hängen:

.well-known Verzeichnisstruktur anlegen

/var/www/letsencrypt/.well-known/acme-challenge -p

Hier handelt es sich nur um einen Tippfehler, es hätte heißen müssen

mkdir /var/www/letsencrypt/.well-known/acme-challenge -p

Mir fällt gerade ein, solltest du zum Abschluss kommen, überprüfe bitte mal deine Verzeichnis Berechtigungen. Da du mir root arbeitest kann es sein dass der Benutzer www-data keine Berechtigung mehr unter /var/www hat.

Dies kannst du ändern mit

chown www-data:www-data /var/www -R

Hallo Volker, Hallo Sebix, vielen Dank für die Hilfe.

Jetzt bin ich weitergekommen, hänge aber bei diesem Punkt.

Nextcloud einrichten unter Apache2 OPTIONAL: Falls nextcloud nicht unter /var/www

Nextcloud läuft bei mir unter /var/www/html/nextcloud und nicht /var/www/nextcloud.

Wie fahre ich hier fort?

Vielen DANK im Voraus!

Gruß Christoph

In all den scripts bzw. configs habe ich die Annahme getroffen, dass du seine Seiten unter dem Oberverzeichnis deiner Domain laufen. Für mich ist das Oberverzeichnis html (/var/www/html/nextcloud) keine Domain sondern ein einfaches Verzeichnis.

Daher habe ich immer folgende Annahme getroffen, dass nextcloud unter /var/www/<deine Domain oder DynDNS-Adresse>/nextcloud läuft. In den scripten heißt das Verzeichnis /var/www/example.local/nextcloud.

Das hat den einfachen hintergrund, dass falls du später auf dem gleichen Maschine noch eine Domain hostest kannst du die Verzeichnisstruktur klar voneinander trennen. Beispielsweise für meine-domain.local und example.local sähe das dann so aus

/var/www/example.local      -> Als Wurzelverzeichnis für alle Seite die unter example.local laufen
/var/www/meine-domain.local -> Als Wurzelverzeichnis für alle Seite die unter meine-domain.local laufen

Ändern kannst du das dann mit

mkdir /var/www/<meine Domain oder DynDNS-Adresse/nextcloud> -p
mv /var/www/html/nextcloud /var/www/<meine Domain oder DynDNS-Adresse/nextcloud>

Zur Überprüfung würde ich dich einfach bitten mal die Ausgabe dieser zwei Befehle zu posten.

ls -la /var/www/
ls -la /var/www/<meine Domain oder DynDNS-Adresse> 

Hallo Volker, vielleicht bin ich noch zu sehr Xampp lastig von Windows. Hier kopiert man alles rein und das war es. Keine Berechtigungen etc. wir hier. Aber das kapiere ich auch noch. 😉

Es sollen in Summe dann nur zwei Sachen laufen. a) Nextcloud und b) Prestashop den ich gerade erstelle.

Ich habe jetzt noch nichts geändert!

ls -la /var/www/:

insgesamt 20
drwxrwxr-x  5 www-data    www         4096 Okt 15 19:08 .
drwxr-xr-x 16 root        root        4096 Okt 14 15:54 ..
drwxr-xr-x  2 www-data    www-data    4096 Okt 14 15:54 nextcloud
drwxrwxrwx  7 www-data    www-data    4096 Okt 16 13:21 html
drwxrwxr-x  3 username username 4096 Okt 16 13:00 letsencrypt

ls -la /var/www/<meine Domain oder DynDNS-Adresse>:

drwxrwxrwx  7 www-data    www-data     4096 Okt 16 13:21 .
drwxrwxr-x  5 www-data    www          4096 Okt 15 19:08 ..
drwxr-xr-x 25 username username  4096 Jul  9 18:36 prestashop.de
drwxrwxr-x 15 username www-data     4096 Okt 16 13:36 nextcloud
-rw-rw-r--  1 username username     0 Okt 16 13:20 .htaccess
-rw-r--r--  1 www-data    www-data    11321 Okt 14 14:00 index.html
drwxrwxr-x 11 username username  4096 Okt 15 15:23 mysqldumper
-rw-r--r--  1 www-data    www-data       20 Okt 14 14:04 phpinfo.php
lrwxrwxrwx  1 www-data    www-data       22 Okt 14 15:11 phpmyadmin -> /usr/share/phpmyadmin/
drwxrwxr-x 26 www-data    username  4096 Okt 14 20:04 prestashop
drwxr-xr-x  5 username username  4096 Okt 14 19:45 wordpress

Gruß Christoph

karpfensami schrieb:

Hallo Volker, vielleicht bin ich noch zu sehr Xampp lastig von Windows. Hier kopiert man alles rein und das war es. Keine Berechtigungen etc. wir hier. Aber das kapiere ich auch noch. 😉

Es sollen in Summe dann nur zwei Sachen laufen. a) Nextcloud und b) Prestashop den ich gerade erstelle.

Okay, von zwei Seiten war bisher nie die rede. Dann wären jetzt ein paar mehr Infos relevant um die configs eventuell an zu passen.

• Die Domain prestashop.de gehört dir?

• Hast du die Möglichkeit Subdomains unter prestahop.de an zu legen, bespielsweise nextcloud.prestahop.de?

• oder soll die Nextcloud unter einer anderen Domain laufen, wenn ja unter welcher?

• Soll prestahop.de auch ein SSL Zertifikat erhalten? (Müssten dann getssl noch anpassen)

ls -la /var/www/:

insgesamt 20
drwxrwxr-x  5 www-data    www         4096 Okt 15 19:08 .
drwxr-xr-x 16 root        root        4096 Okt 14 15:54 ..
drwxr-xr-x  2 www-data    www-data    4096 Okt 14 15:54 nextcloud
drwxrwxrwx  7 www-data    www-data    4096 Okt 16 13:21 html
drwxrwxr-x  3 username username 4096 Okt 16 13:00 letsencrypt

Okay, ich gehe davon aus dass nextcloud bei dir unter /var/www/nextcloud installiert ist.

ls -la /var/www/<meine Domain oder DynDNS-Adresse>:

drwxrwxrwx  7 www-data    www-data     4096 Okt 16 13:21 .
drwxrwxr-x  5 www-data    www          4096 Okt 15 19:08 ..
drwxr-xr-x 25 username username  4096 Jul  9 18:36 prestashop.de
drwxrwxr-x 15 username www-data     4096 Okt 16 13:36 nextcloud
-rw-rw-r--  1 username username     0 Okt 16 13:20 .htaccess
-rw-r--r--  1 www-data    www-data    11321 Okt 14 14:00 index.html
drwxrwxr-x 11 username username  4096 Okt 15 15:23 mysqldumper
-rw-r--r--  1 www-data    www-data       20 Okt 14 14:04 phpinfo.php
lrwxrwxrwx  1 www-data    www-data       22 Okt 14 15:11 phpmyadmin -> /usr/share/phpmyadmin/
drwxrwxr-x 26 www-data    username  4096 Okt 14 20:04 prestashop
drwxr-xr-x  5 username username  4096 Okt 14 19:45 wordpress

Du wirst diesen Befehl ausgeführt haben?

ls -la /var/www/html

Hallo Volker, vielen Dank wieder einmal dass Du dir so viel Mühe gibst.

Mein Plan ist mit dem Sever: a) Nextcloud beleibt fix am Server DNS-Link: wunschname.ddns.net/nextcloud

b) Prestashop.de bleibt nur so lang am Server bis ich mit dem Shop fertig bin und auf die endgültige Domaine umziehen kann. SSL-benötige ich bei der Entwicklung für den Shop nicht. Am endgültigen Hoster haben wir ein SSL-Zertifikat breits gekauft. Wenn ich nicht daheim bin, Arbeite ich auch am Shop von außen bzw. Mein Chef und das gesamte Team möchten gerne in der Entwicklung vom Shop gerne zugreifen können. Daher ist er ebenfalls über einen DNS-Link aufrufbar. DNS-Link: wunschname.ddns.net/prestashop.de

c) Im Falle weiterer Webprojekt sollte bei Bedarf die Seite über den DNS-Link: wunschname.ddns.net/zukunftprojekt aufrufbar sein. Zur Not, wenn ich keinen Zugriff von außen benötige, kann ich dies auch unter Xampp auf Windows machen. 😉

Nextcloud ist bei mir unter /var/www/html/nextcloud installiert und nicht unter /var/www/ installiert.

Ja genau, ich habe diesen

ls -la /var/www/html

ausgeführt.

Gruß Christoph

PS: Wie kann ich hier im Forum die Zeilenumbrüche machen?

karpfensami schrieb:

DNS-Link: wunschname.ddns.net/prestashop.de

Also kein eigenes Zertifikat hier.

c) Im Falle weiterer Webprojekt sollte bei Bedarf die Seite über den DNS-Link: wunschname.ddns.net/zukunftprojekt aufrufbar sein.

Also wird /var/www/html einfach der Webroot und es gibt nur eine Domain. Das einfachste aller Setups.

PS: Wie kann ich hier im Forum die Zeilenumbrüche machen?

Einen Absatz kannst du mit einer Leerzeile einfuegen. Zum Erstellen von Listen den Button im Editor klicken.

Hallo Sebix, genau bei prestashop brauche ich kein eigenes Zertifikat. Nur für die Nextcloud würde ich gerne SSL haben.

Bzgl. /var/www/html einfach der Webroot. Ja genau, so bin ich es von Xampp gewohnt, dass hier alles Webauftritte reinkommen.

Gruß Christoph