Nextcloud

[Nils Lange]

Hallo zusammen,

ich komme hier nicht weiter. Was will das Installationsscript hier? Der
Webserver läuft.

nextcloud version (eisfair-1): v1.6.4
Database type : sqlite
Database server: localhost
Trusted domain(s): mail.killa.eisfair.net
Apache2 SSL support: enabled
SQLite3 PHP7 support: enabled
Mail support: enabled
PHP7-WEB Redis cache: enabled
PHP7-CLI Redis cache: enabled
Redis support: enabled
PHP7-WEB memory limit: >= 512M
PHP7-CLI memory limit: >= 512M
PHP7-CLI configuration access: possible
PHP7-WEB module test failure, make sure that the web server is running!
PHP7-WEB IMAGICK module: enabled, but not loaded!
PHP7-WEB INTL module: enabled, but not loaded!
PHP7-WEB OPCACHE module: enabled, but not loaded!
PHP7-WEB PCNTL module: enabled, but not loaded!
PHP pre-requisites not met, fix it and re-run configuration!

Wäre sehr nett, wenn ihr mir hierbei Unterstützung zukommen lassen
würdet. Danke!

Gruß, Nils

[Peter Bäumer]

Am 28.04.2019 um 04:40 schrieb Nils Lange:
> Hallo zusammen,
>
> ich komme hier nicht weiter. Was will das Installationsscript hier? Der Webserver läuft.
>
> nextcloud version (eisfair-1): v1.6.4
> Database type  : sqlite
> Database server: localhost
> Trusted domain(s): mail.killa.eisfair.net
> Apache2 SSL support: enabled
> SQLite3 PHP7 support: enabled
> Mail support: enabled
> PHP7-WEB Redis cache: enabled
> PHP7-CLI Redis cache: enabled
> Redis support: enabled
> PHP7-WEB memory limit: >= 512M
> PHP7-CLI memory limit: >= 512M
> PHP7-CLI configuration access: possible
> PHP7-WEB module test failure, make sure that the web server is running!
> PHP7-WEB IMAGICK module: enabled, but not loaded!
> PHP7-WEB INTL module: enabled, but not loaded!
> PHP7-WEB OPCACHE module: enabled, but not loaded!
> PHP7-WEB PCNTL module: enabled, but not loaded!
> PHP pre-requisites not met, fix it and re-run configuration!

Da müssen noch Pakte installiert werden:
php7-imagick, php7-intl, php7-opcache, php7-pcntl

Das Kommando müsste das Problem lösen:
eisman update && eisman install php7-imagick php7-intl php7-opcache php7-pcntl

>
> Wäre sehr nett, wenn ihr mir hierbei Unterstützung zukommen lassen würdet. Danke!
>
> Gruß, Nils

MfG
Peter B.

[Hilmar Böhm]

Hallo Nils,

offensichtlich bin ich nicht der Einzige, der Probleme mit dem Nextcloud-Setup unter Eisfair hat... :)

> PHP7-WEB module test failure, make sure that the web server is running!
> PHP7-WEB IMAGICK module: enabled, but not loaded!
> PHP7-WEB INTL module: enabled, but not loaded!
> PHP7-WEB OPCACHE module: enabled, but not loaded!
> PHP7-WEB PCNTL module: enabled, but not loaded!
> PHP pre-requisites not met, fix it and re-run configuration!

Ich würde in der nextcloud Config setzen: OWNCLOUD_WEB_ROOT='/'
Musste ich direkt in /etc/config.d/nextcloud eintragen.

Hab's aufgegeben mit Nextcloud/Eisfair, vermutlich 2 Meter vor dem Ziel...
Es läuft nicht, bei mir.

Grüße. / Hilmar.

[Sebastian Ertz]

Hallo Hilmar,

probier mal folgendes:
eisman uninstall --auto nextcloud
eisman install --auto nextcloud=1.5.4

Dann einrichten, probieren, und danach:
eisman install --auto nextcloud

Gruß
Sebastian

[Juergen Edner]

Hallo Nils,

> ich komme hier nicht weiter. Was will das Installationsscript hier? Der
> Webserver läuft.

> ...

> PHP7-WEB module test failure, make sure that the web server is running!
> PHP7-WEB IMAGICK module: enabled, but not loaded!
> PHP7-WEB INTL module: enabled, but not loaded!
> PHP7-WEB OPCACHE module: enabled, but not loaded!
> PHP7-WEB PCNTL module: enabled, but not loaded!
> PHP pre-requisites not met, fix it and re-run configuration!
>
> Wäre sehr nett, wenn ihr mir hierbei Unterstützung zukommen lassen
> würdet. Danke!

mit einem laufenden Webserver allein ist es leider nicht getan. Viel
wichtiger ist, dass Du auch die PHP7-Unterstützung für den Web-Zugriff
aktiviert hast. D.h. es muss entweder das apache2_php7- oder php7-fpm-
Paket installiert und aktiviert sein.
Sobald dieser Schritt durchgeführt wurde, solltest Du mittels eines
Webbrowser prüfen, ob die PHP-Unterstützung auch korrekt aktiviert
wurde.
Wenn Du PHP7_INFO='yes' bzw. PHP7FPM_INFO='yes' in der Konfiguration
gesetzt hast, solltest Du dann die URL
http://<dein-server-name>/info.php eingeben können und eine
entsprechende PHP-Statusseite
angezeigt bekommen.

Gruß Jürgen

--
Mail: jue...@eisfair.org

[Hilmar Böhm]

Hallo Sebastian,

vielen Dank für Deinen Vorschlag.
Ich frage mich allerdings, warum ich erst ein Downgrade machen muss, damit ich dann konfigurieren kann, um dann wider up zugraden?

Ich habe bereits eine Konfiguration (1.6.4), die ohne Fehlermeldung hoch fährt (MySQL. PHP7, Apache, Nextcloud 1.6.4).Ich
scheitere allerdings daran, den NC-Server so zu konfigurieren, dass ich mit https://<server>/nextcloud auf die
Nextcloud-Loginseite komme...

Wie's auch sei, es klappt nicht - bei mir :)
Bist Du inzwischen weiter gekommen? Wenn ja, würde mich interessieren, womit.

Viele Grüße. / Hilmar.

Frage an alle, was hier falsch sein könnte:
Auch mit Sebastians Vorschlag laufen ich bei der Nextcloud-Konfig in die gleichen Probleme wie Nils und ich anfangs auch. Hier
die Meldungen, die ich bei einer 1.5.4. Konfiguration bekomme:
-----------------------------------------------------------------------------------
Checking configuration file ...

Configuration file was saved as nextcloud.2019-04-28-22-06-41 in /etc/backup.d.

Activate configuration now (y/n) [yes]?
nextcloud version (eisfair-64): v1.5.4
Database type : mysql (mariadb102)
Database server: localhost:3306
Trusted domain(s): e64nc.hiro.corp
Apache2 SSL support: enabled
MySQL PHP7 support: enabled
MySQL support: enabled
MySQL binary logging: disabled
APC PHP7 cache: enabled
Redis PHP7 cache: enabled

Redis support: enabled
PHP7-WEB memory limit: >= 512M
PHP7-CLI memory limit: >= 512M

PHP7-CLI configuration access: possible # Alles ok soweit...

PHP7-WEB module test failure, make sure that the web server is running! <--- !!

PHP7-WEB IMAGICK module: enabled, but not loaded! |
PHP7-WEB INTL module: enabled, but not loaded! |

PHP7-WEB OPCACHE module: enabled, but not loaded! v

PHP7-WEB PCNTL module: enabled, but not loaded!
PHP pre-requisites not met, fix it and re-run configuration!

--------------------------------------------------------------------------------------
(Btw.: IMAGIK,INTL,OPCACHE,PCNTL sind vorhanden!)

https://<server>info.php zeigt die längliche und sehr ausführliche "PHP 7.2.14"-Infoseite.

https://<server>gd.php zeigt:
--------------------------------------------------------------------------------------
GD support: yes
FreeType Support: yes
FreeType Linkage: yes
GIF Read Support: yes
GIF Create Support: yes
JPEG Support: yes
PNG Support: yes
WBMP Support: yes
XPM Support: yes
XBM Support: yes
WebP Support: yes
BMP Support: yes
JIS-mapped Japanese Font Support: no

--------------------------------------------------------------------------------------

Danach müsste PHP funktionieren und der Apache laufen?







Am 28.04.19 um 10:41 schrieb Sebastian Ertz:

[Hilmar Böhm]

Am 28.04.19 um 22:34 schrieb Hilmar Böhm:

> https://<server>info.php zeigt die längliche und sehr ausführliche "PHP 7.2.14"-Infoseite.
>
> https://<server>gd.php zeigt:

Sorry, Dreckfuhler:
https://<server>/info.php
https://<server>/gd.php

Hilmar.

[Hilmar Böhm]

Hallo,

Am 28.04.19 um 22:34 schrieb Hilmar Böhm:

> PHP7-WEB module test failure, make sure that the web server is running!   <--- !!
> PHP7-WEB IMAGICK module: enabled, but not loaded!                          |
> PHP7-WEB INTL module: enabled, but not loaded!                             |
> PHP7-WEB OPCACHE module: enabled, but not loaded!                          v
> PHP7-WEB PCNTL module: enabled, but not loaded!
> PHP pre-requisites not met, fix it and re-run configuration!
> --------------------------------------------------------------------------------------
> (Btw.: IMAGIK,INTL,OPCACHE,PCNTL sind vorhanden!)

ich habe mir die "PHP7-WEB xyz module: enabled, but nut loaded" Fehlermeldungen noch mal angeschaut.
PHP7-WEB bezieht sich vermutlich auf die PHP7-Module, die von Apache2 bei Nextcloud verwendet werden.

Die fraglichen PHP-Module sind "inst"alliert!

START_PHP7='yes' ist gesetzt (setup-1- <Apache2 Webserver> -2-4-1-2).
Die Konfiguration in "PHP7-Administration" ist gemacht und der entsprechende Check beim Verlassen des Dialog ist ohne Fehler.

Dann fragt sich, ob die zu den PHP7-Modulen zugehörigen Libs in "/usr/lib/php7/extensions/" geladen wurden?
Nachzuprüfen z.B. mit:

# cat /proc/*/maps | awk '{print $6;}' | grep '\.si' | sort |uniq
-----------------------------------------------------------------------------------
...
/usr/lib/apache2/modules/libphp7.so
/usr/lib/php7/extensions/apcu.so
/usr/lib/php7/extensions/bz2.so
/usr/lib/php7/extensions/curl.so
/usr/lib/php7/extensions/gd.so
/usr/lib/php7/extensions/gettext.so
/usr/lib/php7/extensions/iconv.so
/usr/lib/php7/extensions/imagick.so
/usr/lib/php7/extensions/intl.so
/usr/lib/php7/extensions/mcrypt.so
/usr/lib/php7/extensions/opcache.so
/usr/lib/php7/extensions/openssl.so
/usr/lib/php7/extensions/pcntl.so
/usr/lib/php7/extensions/pdo.so
/usr/lib/php7/extensions/pdo_dblib.so
/usr/lib/php7/extensions/pdo_mysql.so
/usr/lib/php7/extensions/redis.so
/usr/lib/php7/extensions/zlib.so
...
-----------------------------------------------------------------------------------

Die fraglichen PHP7-Libs müssten also geladen sein bzw geladen werden können.

Ich frage mich, ob dann etwas in der Config/Check-Routine (/var/install/config.d/nextcloud.sh) nicht korrekt geprüft wird.
(irgendwas in der Subroutinen print_php_modules_status() und is_php_module_loaded() stimmt da m.E. nicht).

Ich habe btw. jetzt auch wider mit der V1.6.4 die o.g. PHP7-WEB - Fehlermeldungen. Komisch...


Vielen Dank für eine Lösung :-)

Grüße. / Hilmar.

[Juergen Edner]

Hallo Hilmar,

> ich habe mir die "PHP7-WEB xyz module: enabled, but nut loaded"
> Fehlermeldungen noch mal angeschaut.
> PHP7-WEB bezieht sich vermutlich auf die PHP7-Module, die von Apache2
> bei Nextcloud verwendet werden.
>
> Die fraglichen PHP-Module sind "inst"alliert!

bei PHP gillt es zwischen den WEB-Modulen, die vom Webserver verwendet
werden, und dem PHP-Kommandozeilenprogramm zu unterschieden. Eine
Prüfung, ob die PHP-Web-Module korrekt geladen wurden, kann nur durch
einen Browser-Zugriff erfolgen. Da dieser fehlschlägt, kommt es zu
der besagten Fehlermeldung.

> Ich frage mich, ob dann etwas in der Config/Check-Routine
> (/var/install/config.d/nextcloud.sh) nicht korrekt geprüft wird.
> (irgendwas in der Subroutinen print_php_modules_status() und
> is_php_module_loaded() stimmt da m.E. nicht).

Du kannst ja einmal im nextcloud.sh-Skript in Zeile 215 das
Kommentarzeichen vor dem "#debug=true" entfernen, dann die Konfiguration
neu erzeugen lassen und mir die erzeugten /tmp/nextcloud-config-.*log-
Dateien per PM zusenden damit ich mir dies einmal ansehen kann.

[Hilmar Böhm]

Hallo Jürgen,

Am 29.04.19 um 16:50 schrieb Juergen Edner:

> Du kannst ja einmal im nextcloud.sh-Skript in Zeile 215 das
> Kommentarzeichen vor dem "#debug=true" entfernen, dann die Konfiguration
> neu erzeugen lassen und mir die erzeugten /tmp/nextcloud-config-.*log-
> Dateien per PM zusenden damit ich mir dies einmal ansehen kann.
>

Mail ist unterwegs. Danke.

> Eine Prüfung, ob die PHP-Web-Module korrekt geladen wurden, kann nur durch
> einen Browser-Zugriff erfolgen.

Wo bitte genau stehen diese Browser-"Abfragen" (in nextcloud.sh)?

Grüße. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> > Eine Prüfung, ob die PHP-Web-Module korrekt geladen wurden, kann nur
> > durch einen Browser-Zugriff erfolgen.
> Wo bitte genau stehen diese Browser-"Abfragen" (in nextcloud.sh)?

Ich würde in einem ersten Schritt mal nach "enabled, but not loaded!" oder
einem Teil davon suchen.

--
Gruss Marcus

[Hilmar Böhm]

Ja klar, Marcus,



Am 29.04.19 um 22:53 schrieb Marcus Roeckrath:

das habe ich gemacht und auch geschrieben. und bin dabei bis "is_php_module_status()" vorgedrungen, um festzustellen,
wie _ppms_status gefüllt wird - und das auch mit entsprechenden zusätzl. echo's im Script getestet.
Ich habe aber nicht die Zeilen gefunden, in denen Browser-Abfragen gemacht werden, ob die betreffenden Apache-PHP7-Module auch
verfügbar/verwendbar sind.
Die fraglichen 4 PHP7-Module/Libs sind in "/usr/lib/php7/extensions" (--> _ppms_extfile) vorhanden und in den jeweiligen *.ini
files in "/etc/php7/conf.d" als Libs aufgeführt (-->php_web_inifile). Müsste das nicht ausreichen? Warum noch mal ein weitere
explizite Web-Abfragen?

Sicherlich verstehen das andere besser... :)

Grüße. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

>> Ich würde in einem ersten Schritt mal nach "enabled, but not loaded!"
>> oder einem Teil davon suchen.
>>
> das habe ich gemacht und auch geschrieben. und bin dabei bis
> "is_php_module_status()" vorgedrungen,

Es ist die Funktion get_loaded_php_modules, in der jeweils für cli und web
ein php-Skript erzeugt wird und dann mit php (für cli) und einmal mit wget
(für web) ausgeführt wird.

Du könntest das Skript aus den Zeilen 5834-5838 mal manuell in eine Datei
nextcloudcheck packen, ins Webroot des Apachen kopieren und dann (eine
Zeile)

/usr/bin/wget.sh --max-redirect=5 --tries=2 --timeout=2 -qO-
"http://localhost/nextcloudcheck"

ausführen.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Hilmar, hallo Jürgen,

Marcus Roeckrath wrote:

> Du könntest das Skript aus den Zeilen 5834-5838 mal manuell in eine Datei
> nextcloudcheck packen, ins Webroot des Apachen kopieren und dann (eine
> Zeile)
>
> /usr/bin/wget.sh --max-redirect=5 --tries=2 --timeout=2 -qO-
> "http://localhost/nextcloudcheck"
>
> ausführen.

Das habe ich mal getan, aber der wget-Aufruf zeigt mir schlicht nur das
Skript selber an.

Mit php ausgeführt, bekomme ich die Liste der geladenen Module.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Hilmar,

Marcus Roeckrath wrote:

>> Du könntest das Skript aus den Zeilen 5834-5838 mal manuell in eine Datei
>> nextcloudcheck packen, ins Webroot des Apachen kopieren und dann (eine
>> Zeile)
>>
>> /usr/bin/wget.sh --max-redirect=5 --tries=2 --timeout=2 -qO-
>> "http://localhost/nextcloudcheck"
>>
>> ausführen.
>
> Das habe ich mal getan, aber der wget-Aufruf zeigt mir schlicht nur das
> Skript selber an.

Fehler gefunden: Das Skript muss die Dateiendung php haben, dann
funktionierts.

Machs also mal und poste hier die Ausgabe.

--
Gruss Marcus

[Hilmar Böhm]

Hallo Marcus,

Am 30.04.19 um 08:04 schrieb Marcus Roeckrath:

> Hallo Hilmar,
>
> Marcus Roeckrath wrote:
>
>>> Du könntest das Skript aus den Zeilen 5834-5838 mal manuell in eine Datei
>>> nextcloudcheck packen, ins Webroot des Apachen kopieren und dann (eine
>>> Zeile)
>>>
>>> /usr/bin/wget.sh --max-redirect=5 --tries=2 --timeout=2 -qO-
>>> "http://localhost/nextcloudcheck"
>>>
>>> ausführen.
>>

> Machs also mal und poste hier die Ausgabe.
>

vielen Dank für den Pointer! Genau das hatte ich gesucht und (noch) nicht gefunden :-)

Output des PHP-Scripts s.u.
Von den 4 zu prüfenden PHP-Modulen (imagick, intl, opcache, pcntl) ist opcache nicht vorhanden.
In der Liste der geladenen .so's (s. vorige Posts von mir) ist opcache aber enthalten.

Somit:
/usr/lib/php7/extensions/opcache.so ist vorhanden. Ebenso /etc/php7/conf.d/opcache.ini mit diesem Inhalt:
----------------------------------------------------------------------------------------------------------
zend_extension=opcache.so
opcache.enable=On
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
----------------------------------------------------------------------------------------------------------

Warum wird also das opcache Modul nicht als geladen angezeigt?
Warum zeigt nextcloud.sh auch die anderen 3 PHP-Module als nicht geladen an?
(Vielleicht läuft in nextcloud.sh auch noch was in der nachfolgenden Prüfung der erhaltenen PHP-Modulliste
nicht richtig. Vielleicht wird opcache grundsätzlich nicht angezeigt? Ich schau mir das noch mal an.)

Warum überhaupt diese Kirchenarbeit mit der PHP-Modulprüfung? Ich versteh's (noch) nicht.

Grüße. / Hilmar.

nextcloudcheck.php
----------------------------------------------------------------------------------------------------------
<pre>Array
(
[0] => Core
[1] => date
[2] => libxml
[3] => pcre
[4] => bcmath
[5] => calendar
[6] => ctype
[7] => dba
[8] => dom
[9] => hash
[10] => fileinfo
[11] => filter
[12] => ftp
[13] => SPL
[14] => session
[15] => json
[16] => mbstring
[17] => standard
[18] => mysqlnd
[19] => mysqli
[20] => bz2
[21] => posix
[22] => Reflection
[23] => imap
[24] => shmop
[25] => SimpleXML
[26] => sockets
[27] => exif
[28] => sysvmsg
[29] => sysvsem
[30] => sysvshm
[31] => tokenizer
[32] => wddx
[33] => xml
[34] => xmlreader
[35] => xmlwriter
[36] => xsl
[37] => zip
[38] => apcu
[39] => openssl
[40] => curl
[41] => gd
[42] => gettext
[43] => iconv
[44] => mcrypt
[45] => zlib
[46] => PDO
[47] => pdo_dblib
[48] => Phar
[49] => imagick
[50] => intl
[51] => pdo_mysql
[52] => pcntl
[53] => redis
[54] => Zend OPcache
)
<pre/>
----------------------------------------------------------------------------------------------------------

[Nils Lange]

On 28.04.2019 08:51, Peter Bäumer wrote:

>
> Da müssen noch Pakte installiert werden:
> php7-imagick, php7-intl, php7-opcache, php7-pcntl
>
> Das Kommando müsste das Problem lösen:
> eisman update && eisman install php7-imagick php7-intl php7-opcache
> php7-pcntl
>

Hallo Peter,

habe ich versucht, hat leider nichts gebracht. Die Pakete wurden
installiert, es erscheinen jedoch die selben Meldungen wie vorher:

PHP7-WEB module test failure, make sure that the web server is running!
PHP7-WEB IMAGICK module: enabled, but not loaded!
PHP7-WEB INTL module: enabled, but not loaded!
PHP7-WEB OPCACHE module: enabled, but not loaded!
PHP7-WEB PCNTL module: enabled, but not loaded!
PHP pre-requisites not met, fix it and re-run configuration!

Gruß, Nils

[Nils Lange]

Hallo zusammen,

Version 1.5.4 läuft wieder. Diesmal mit PHP7, hatte ich vorher nur mit
PHP5 benutzt. Aber nach einem Update auf 1.6.4 oder 1.7.0 geht es wieder
nicht mehr.

Merkwürdig ist, dass die Installation der 1.5.4 die
Nextcloud-Verzeichnisse anlegt, bei Installation der 1.6.4 oder 1.7.0
bleiben die Verzeichnisse leer und es kommen die Meldungen der PHP-Module.

domain/info.php liefert einen ausführlichen Bericht.

Gruß Nils

[Hilmar Böhm]

Hallo Nils,

Am 01.05.19 um 00:55 schrieb Nils Lange:

> Merkwürdig ist, dass die Installation der 1.5.4 die Nextcloud-Verzeichnisse anlegt, bei Installation der 1.6.4 oder 1.7.0
> bleiben die Verzeichnisse leer und es kommen die Meldungen der PHP-Module.

Nach meiner Erfahrung werden diese Verzeichnisse erst dann angelegt und befüllt, wenn die Nextcloud-Konfiguration einwandfrei,
ohne Fehlermeldungen durchgelaufen ist. Also auch diese PHP7_WEB-Fehlermeldungen müssen weg sein.

Mit der 1.6.2/4 (kein Upgrade von einer früheren Version) habe ich es 1x hingekommen, jetzt geht es plötzlich auch nicht mehr.

Grüße. / Hilmar.

[Hilmar Böhm]

Hallo Nils,

Am 01.05.19 um 00:55 schrieb Nils Lange:

> Version 1.5.4 läuft wieder. Diesmal mit PHP7, hatte ich vorher nur mit PHP5 benutzt. Aber nach einem Update auf 1.6.4 oder 1.7.0
> geht es wieder nicht mehr.

Deine Erwähnung einer Nextcloud 1.7.0, die ganz neu sein musste, brachte mich auf die Idee, meine Version 1.6.4 auf die 1.7.0
upzugraden.

Gesagt, getan: Das Upgrade lief einwandfrei durch, jede Menge Changes, auch in den Nextcloud-Verzeichnissen, die bei mir schon
bestanden und gefüllt waren (1.6.0).

Auch die Nextcloud-Konfig am Ende war ohne die PHP/-WEB-Fehlermeldungen. Um zu prüfen, ob das nicht nur eine einmalige Sache
ist, habe ich mehrmals über setup->...->Nextcloud die Konfiguration aufgerufen und wieder beendet/gespeichert (--> nextcloud.sh):
Keine Fehlermeldungen. Der Output des Scripts sieht jetzt so aus:

----------------------------------------------------------------------------------------------------------

Activate configuration now (y/n) [yes]?

nextcloud version (eisfair-64): v1.7.0

Database type : mysql (mariadb102)
Database server: localhost:3306

Trusted domain(s): localhost e64nc

Apache2 SSL support: enabled
MySQL PHP7 support: enabled
MySQL support: enabled
MySQL binary logging: disabled

PHP7-WEB APC cache: enabled
PHP7-WEB Redis cache: enabled
PHP7-CLI APC cache: enabled
PHP7-CLI Redis cache: enabled

Redis support: enabled
PHP7-WEB memory limit: >= 512M
PHP7-CLI memory limit: >= 512M
PHP7-CLI configuration access: possible

creating logrotate configuration ...
creating cron script ...
setting access rights of '/var/www/htdocs/nextcloud' ...
wait [ . ]
setting access rights of '/var/nextcloud' ...
wait [ . ]

checking nextcloud install/upgrade requirements ...
Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Done.

All tables already up to date!
creating nextcloud configuration ...
creating cron job ...
nextcloud maintenance mode: disabled

checking nextcloud install/upgrade requirements ...
Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Done.

All tables already up to date!
finished.
Configuration messages appeared, please check configuration

Continue (y/n) [yes]?
...
(Messages-Box.)
...

Nach Bendigung der Box (<F10>):
Do you want to restart webserver now (recommended) (y/n) [yes]
*Restarting Apache...
Press return to continue
----------------------------------------------------------------------------------------------------------

Das sieht m.E. besser aus. Ach ja, ich hatte vorher noch Owner:Group des /var/www/htdocs/nextcloud/ - Trees
auf wwwrun:nogroup geändert. Die standen auf root:nogroup.

Jetzt habe ich noch das Problem. dass beim Client-Browser bei Eingabe der URL: https://e64nc/nextcloud/
die URL sofort umgeschrieben wir in: https://e64nc/index.php/login und als Meldung erscheint:
-----------------------------------------------------------

Not Found
The requested URL /index.php/login was not found on this server.

Apache/2.4 Server at e64nc Port 443

------------------------------------------------------------

/var/www/htdocs/nextcloud/index.php/login gibt es auch nicht, auch nicht 1 Level höher.
Da fehlt mir noch eine Einleuchtung. Vielleicht hat ja jemand einen Rat für mich? :)

Grüße. / Hilmar.

[Hilmar Böhm]

...es war ein letzter Versuch...
Ich fass' es nicht: Ich bekomme einen Nextcloud-Login Screen mit URL: https://e64nc
Nix: .../nextcloud

Nichtsdestotrotz ist jetzt finis. Ich leg' mich flach.
(Das Backup knipst jetzt ohne hin gleich die Systeme aus...)
Gute Nacht und Grüße. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> ...es war ein letzter Versuch...
> Ich fass' es nicht: Ich bekomme einen Nextcloud-Login Screen mit URL:
> https://e64nc Nix: .../nextcloud

Hattest du nicht einen VirtualHost in der Apache-Konfiguration erstellt?

--
Gruss Marcus

[Juergen Edner]

Hallo Nils,

> Version 1.5.4 läuft wieder. Diesmal mit PHP7, hatte ich vorher nur mit
> PHP5 benutzt. Aber nach einem Update auf 1.6.4 oder 1.7.0 geht es wieder
> nicht mehr.
>
> Merkwürdig ist, dass die Installation der 1.5.4 die
> Nextcloud-Verzeichnisse anlegt, bei Installation der 1.6.4 oder 1.7.0
> bleiben die Verzeichnisse leer und es kommen die Meldungen der PHP-Module.
>
> domain/info.php liefert einen ausführlichen Bericht.

wenn Du mit "domain/info.php" meinst, dass Du im Webbrowser nach
Eingabe der Adresse "http://<domain>/info.php" eine Anzeige bekommt,
dann möchte ich Dich bitten einmal den optionalen Parameter
OWNCLOUD_WEB_ROOT='/' zu setzen.

[Juergen Edner]

Hallo Hilmar,

> Jetzt habe ich noch das Problem. dass beim Client-Browser bei Eingabe
> der URL: https://e64nc/nextcloud/
> die URL sofort umgeschrieben wir in: https://e64nc/index.php/login und
> als Meldung erscheint:
> -----------------------------------------------------------
>
> Not Found
> The requested URL /index.php/login was not found on this server.
>
> Apache/2.4 Server at e64nc Port 443
>
> ------------------------------------------------------------
>
> /var/www/htdocs/nextcloud/index.php/login gibt es auch nicht, auch nicht
> 1 Level höher.
> Da fehlt mir noch eine Einleuchtung. Vielleicht hat ja jemand einen Rat
> für mich? :)

leider hast Du bis dato nicht auf meine PM bezüglich der zugesandten
Trace-Datei geantwortet, ansonsten wären wir vermutlich hier schon
etwas weiter :-(
Gemäß der zugesandten Trace-Datei hast Du aktuell den Parameter
OWNCLOUD_WEB_ROOT='/' gesetzt. Bitte _entferne_ diesen optionalen
Parameter aus Deiner Konfiguration (Taste F8 im ECE), sodass wieder
der Standard-Webpfad "/nextcloud" verwendet wird.

[Hilmar Böhm]

Hallo Jürgen,

Am 01.05.19 um 10:48 schrieb Juergen Edner:

> leider hast Du bis dato nicht auf meine PM bezüglich der zugesandten
> Trace-Datei geantwortet, ansonsten wären wir vermutlich hier schon
> etwas weiter:-(

ich habe leider Deine Mail in diesem Postfach übersehen und bitte um Entschuldigung. (Ich hatte eher auf eine Antwort im Forum
gewartet...)

Das PHP-Check-Prog hatte ich vorher schon auf Marcus' Anleitung gebaut und ausprobiert.

Wirklich weiter gekommen bin ich erst durch das Upgrade auf die 1.7.0 (auf wunderbare Weise).

Trotzdem Danke und Grüße. / Hilmar.

[Juergen Edner]

Hallo Hilmar,

> ich habe leider Deine Mail in diesem Postfach übersehen und bitte um
> Entschuldigung. (Ich hatte eher auf eine Antwort im Forum gewartet...)

kein Problem.

> Das PHP-Check-Prog hatte ich vorher schon auf Marcus' Anleitung gebaut
> und ausprobiert.
>
> Wirklich weiter gekommen bin ich erst durch das Upgrade auf die 1.7.0
> (auf wunderbare Weise).

>> Wenn Du in diesem Verzeichnis testweise eine Datei 'nctest.php'
>> anlegst mit folgendem Inhalt, kannst Du diese dann durch Eingabe
>> von 'http://e64nc.hiro.corp/nextcloud/nctest.php' zur Ausgabe
>> der verfügbaren Module bewegen?

Und wie lautet jetzt die Antwort auf meine Frage? Bestätigst Du, dass
Du durch die Eingabe der genannten URL eine Ausgabe erhältst? Wenn ja,
hast Du den genannten Parameter aus der Konfiguration gelöscht und wird
die Weiterleitung bei Nextcloud nun korrekt durchgeführt?

[Hilmar Böhm]

Hallo Jürgen,

Am 01.05.19 um 21:27 schrieb Juergen Edner:

>>> Wenn Du in diesem Verzeichnis testweise eine Datei 'nctest.php'
>>> anlegst mit folgendem Inhalt, kannst Du diese dann durch Eingabe
>>> von 'http://e64nc.hiro.corp/nextcloud/nctest.php' zur Ausgabe
>>> der verfügbaren Module bewegen?

> Und wie lautet jetzt die Antwort auf meine Frage? Bestätigst Du, dass
> Du durch die Eingabe der genannten URL eine Ausgabe erhältst? Wenn ja,
> hast Du den genannten Parameter aus der Konfiguration gelöscht und wird
> die Weiterleitung bei Nextcloud nun korrekt durchgeführt?

Also, bei folgenden Gegebenheiten:

OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
OWNCLOUD_WEB_ROOT='/'

PHP-Check-Loaded-PHP-Modules-Programm (nextcloudcheck.php) in: '/var/www/htdocs/nextcloud/'

Client-URL: https://e64nc/nextcloudcheck.php

=> erhalte ich die erwartetete Liste der geladenen PHP-Module

(btw.: mit "https://e64nc" erhalte ich auch den Nextcloud-Login-Screen!)
----------------------------------------------------------------

Wenn ich als Client-URL: https://e64nc/nextcloud/nextcloudcheck.php verwende,
Erhalte ich einen "not found" Error.

----------------------------------------------------------------

Wenn ich OWNCLOUD_WEB_ROOT='/' lösche, endet die nextcloud-Konfig wieder mit den bekannten PHP7-WEB-Fehlermeldungen (enabled,
not loaded)
(aber immer noch: OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud)

mit Client.URL "https://e64nc/nextcloudcheck.php erhalte ich die erwartet PHP-Modulliste.
mit "https://e64nc" erhalte ich den Nextcloud-Login-Screen.

mit "https://e64nc/nextcloud/nextcloudcheck.php erhalte ich einen "not found" Error.

------------------------------------------------------------------

mit: OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs' (ohne: /nextcloud!) und OWNCLOUD_WEB_ROOT='/nextcloud'
erhalte ich die Nextcloud-PHP7-WEB-Fehlermeldungen,

aber mit: "https:/e64nc/nextcloudcheck.php" wird die Liste der geladenen PHP-Module angezeigt.

Mit "https://e64nc/nextcloud/nextcloudcheck.php" erhalte ich einen "Not Found" Error. Das scheint mir bei dieser Konstellation
auch logisch

-------------------------------------------------------------------

War es das, was Du wissen wolltest?

Ich hoffe, Du blickst noch durch. Ich gestehe, meine Schwierigkeiten damit zu haben.
BTW: Ich wäre mit einem (funktionierenden) Nextcloud-Aufruf in der Form: "https://e64nc" zufrieden;
er muss nicht "https://e64nc/nextcloud" lauten.

Diese Konstellation hätte m.E. nur den Nachteil, dass ich den Apache nur noch mit Nextcloud als Web-Anwendung betreiben kann(?),
d.h. "https://e64nc/<andere Webanwendung>" wäre das nicht mehr ohne weiteres möglich.
Aber auch das wäre ok.

Grüße. / Hilmar.

[Juergen Edner]

Hallo Hilmar,

> Also, bei folgenden Gegebenheiten:
>
> OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
> OWNCLOUD_WEB_ROOT='/'
>
> PHP-Check-Loaded-PHP-Modules-Programm (nextcloudcheck.php) in:
> '/var/www/htdocs/nextcloud/'
>
> Client-URL: https://e64nc/nextcloudcheck.php
>
> => erhalte ich die erwartetete Liste der geladenen PHP-Module
>
> (btw.: mit "https://e64nc" erhalte ich auch den Nextcloud-Login-Screen!)

genau dies habe ich erwartet, da als Web-Root '/' angegeben ist.

> ----------------------------------------------------------------
>
> Wenn ich als Client-URL: https://e64nc/nextcloud/nextcloudcheck.php
> verwende,
> Erhalte ich einen "not found" Error.
>
> ----------------------------------------------------------------

Dies ist meines Erachtens aber dann der Konfiguration des Apache2
geschuldet, dessen Konfiguration nicht korrekt vorgenommen wurde.

> Wenn ich OWNCLOUD_WEB_ROOT='/' lösche, endet die nextcloud-Konfig wieder
> mit den bekannten PHP7-WEB-Fehlermeldungen (enabled, not loaded)
> (aber immer noch: OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud)

Wenn der Parameter OWNCLOUD_WEB_ROOT gelöscht wurde, wird er
automatisch intern für den Test auf den Wert '/nextcloud' gesetzt.

> mit Client.URL "https://e64nc/nextcloudcheck.php erhalte ich die
> erwartet PHP-Modulliste.
> mit            "https://e64nc"                   erhalte ich den
> Nextcloud-Login-Screen.
>
> mit            "https://e64nc/nextcloud/nextcloudcheck.php erhalte ich
> einen "not found" Error.
>
> ------------------------------------------------------------------
>
> mit: OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs' (ohne: /nextcloud!) und
> OWNCLOUD_WEB_ROOT='/nextcloud'
> erhalte ich die Nextcloud-PHP7-WEB-Fehlermeldungen,
>
> aber mit: "https:/e64nc/nextcloudcheck.php" wird die Liste der geladenen
> PHP-Module angezeigt.
>
> Mit "https://e64nc/nextcloud/nextcloudcheck.php" erhalte ich einen "Not
> Found" Error. Das scheint mir bei dieser Konstellation auch logisch
>
> -------------------------------------------------------------------

Standardmäßig muss auch OWNCLOUD_DOCUMENT_ROOT nicht gesetzt werden.
Wenn Du diesen aber bewusst auf das Stammverzeichnis des Webserver
setzt, wundern mich die Effekte nicht.

> BTW: Ich wäre mit einem (funktionierenden) Nextcloud-Aufruf in der Form:
> "https://e64nc" zufrieden;
> er muss nicht "https://e64nc/nextcloud" lauten.
>
> Diese Konstellation hätte m.E. nur den Nachteil, dass ich den Apache nur
> noch mit Nextcloud als Web-Anwendung betreiben kann(?),
> d.h. "https://e64nc/<andere Webanwendung>" wäre das nicht mehr ohne
> weiteres möglich.
> Aber auch das wäre ok.

Um es noch einmal zusammen zu fassen, wenn Du den Webserver _korrekt_
konfiguriert hast, ist weder erforderlich +OWNCLOUD_DOCUMENT_ROOT,
noch OWNCLOUD_WEB_ROOT zu setzen, da dann als Installationspfad für
die Dateien '<apache2-doc-root/nextcloud' und als Web-Root '/nextcloud'
verwendet wird. In diesem Fall würdest Du einen Aufruf mittels der
URL "http[s]://<domain>/nextcloud" problemlos durchführen können.

Benutzt Du den Webserver momentan schon für etwas anderes oder könnte
man dessen Konfiguration einmal etwas anpassen? Falls ja, würde ich
das Konfigurationschaos gerne einmal per Remote-Zugriff ansehen.

[Hilmar Böhm]

Hallo Jürgen

Am 02.05.19 um 08:31 schrieb Juergen Edner:

> Um es noch einmal zusammen zu fassen, wenn Du den Webserver _korrekt_
> konfiguriert hast, ist weder erforderlich +OWNCLOUD_DOCUMENT_ROOT,
> noch OWNCLOUD_WEB_ROOT zu setzen, da dann als Installationspfad für
> die Dateien '<apache2-doc-root/nextcloud' und als Web-Root '/nextcloud'
> verwendet wird. In diesem Fall würdest Du einen Aufruf mittels der
> URL "http[s]://<domain>/nextcloud" problemlos durchführen können.

Dieser Hinweis hat in mir eine Ahnung geweckt, wie es eigentlich laufen sollte...
Jetzt habe ich es so konfigurieren können wie ich es ursprünglich haben wollte.

Wenn ich mal zusammen fassen darf: :-)

1. Die vielen ROOT-Verzeichnisangaben für DOCUMENT, WEB, LOG, DIR verwirren solche Anfänger wie mich:

-----------------------------------------------------------------------------------------------------
/etc/config.d/apache2:APACHE2_DOCUMENT_ROOT='/var/www/htdocs'
/etc/config.d/apache2:APACHE2_DIR_2_PATH='/var/www/htdocs/geheim/'
/etc/config.d/apache2:APACHE2_VHOST_1_DOCUMENT_ROOT='/var/www/foo/htdocs'
/etc/config.d/apache2:APACHE2_VHOST_1_DIR_1_PATH='/var/www/htdocs/geheim'
/etc/config.d/apache2:APACHE2_VHOST_2_DOCUMENT_ROOT='/var/www/foo/htdocs'
/etc/config.d/apache2:APACHE2_VHOST_2_DIR_1_PATH='/var/www/htdocs/geheim'
/etc/config.d/nextcloud:OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
/etc/config.d/nextcloud:OWNCLOUD_WEB_ROOT="/"
/etc/config.d/nextcloud:OWNCLOUD_APPS_1_DIR='/var/www/htdocs/nextcloud/apps2'
-----------------------------------------------------------------------------------------------------

2. OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
ist (im Wesentlichen) dafür da, dass das Nextcloud-Konfigurationsscript
"nextcloud.sh" seine "Dokumente" und "Pfade" findet. Für den Client-Zugriff
auf Nextcloud ist APACHE2_VHOST_N_DOCUMENT_ROOT bzw. APACHE2_DOCUMENT_ROOT
zuständig.

3. Wenn ein VHOST_N konfiguriert wurde mit
APACHE2_VHOST_1_DOCUMENT_ROOT='/var/www/foo/htdocs' oder wenn nur
APACHE2_DOCUMENT_ROOT='/var/www/htdocs' gesetzt wurde,
dann muss die Client-URL lauten: "http(s)://<nc-host>/nextcloud"

Wenn an diese beiden DOCUMENT_ROOT-Pfade ein ".../nextcloud" angehängt,
dann muss die Client-URL lauten: "http(s)://<nc-host>", also ohne "/nextcloud"

4. Ich habe jetzt folgende Kombination konfiguriert, bei der die Client-URL lautet:
"https://e64nc/nextcloud"

Die Parameter dazu lauten:
/etc/config.d/apache2:APACHE2_VHOST_1_DOCUMENT_ROOT='/var/www/htdocs' # Port 80
/etc/config.d/apache2:APACHE2_VHOST_2_DOCUMENT_ROOT='/var/www/htdocs' # Port 443

/etc/config.d/nextcloud:OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
(kein OWNCLOUD_WEB_ROOT !)

die Nextcloud-"Dokumente" liegen in /var/www/htdocs/nextcloud/"

Mit dieser Kombination könnte ich über die gleiche Apache Instanz auch weitere Apache-Anwendungen fahren, die dann mit
"http(s)://<host>/<Web_Anwendung>" aufgerufen werden können. (So läuft das auch bei meinen anderen Own-/Nextcloudinstallationen
under Debian und ArchLinux...)

Mein Denkfehler, glaube ich, bisher war, dass ich der Meinung war, dass OWNCLOUD_DOCUMENT_ROOT -->
APACHE2_VHOST_N_DOCUMENT_ROOT bzw. APACHE2_DOCUMENT_ROOT überschreibt...
Ich sag's ja: Anfänger! :)

Grüße. / Hilmar.

[Juergen Edner]

Hallo Hilmar,

> Dieser Hinweis hat in mir eine Ahnung geweckt, wie es eigentlich laufen
> sollte...
> Jetzt habe ich es so konfigurieren können wie ich es ursprünglich haben
> wollte.

freut mich zu hören :-)

> 1. Die vielen ROOT-Verzeichnisangaben für DOCUMENT, WEB, LOG, DIR
> verwirren solche Anfänger wie mich:

Deswegen habe ich im nextcloud-Paket auch darauf verzichtet diese
standardmäßig anzuzeigen.

> 2. OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
>         ist (im Wesentlichen) dafür da, dass das
> Nextcloud-Konfigurationsscript
>         "nextcloud.sh" seine "Dokumente" und "Pfade" findet. Für den
> Client-Zugriff
>         auf Nextcloud ist APACHE2_VHOST_N_DOCUMENT_ROOT bzw.
> APACHE2_DOCUMENT_ROOT
>         zuständig.

Korrekt, wobei Du diesen Parameter normalerweise ebenfalls aus
der Konfiguration löschen kannst, da in diesem Fall standardmäßig
APACHE2_DOCUMENT_ROOT + '/nextcloud' gesetzt wird.

> Mit dieser Kombination könnte ich über die gleiche Apache Instanz auch
> weitere Apache-Anwendungen fahren, die dann mit
> "http(s)://<host>/<Web_Anwendung>" aufgerufen werden können. (So läuft
> das auch bei meinen anderen Own-/Nextcloudinstallationen under Debian
> und ArchLinux...)

Genau.

> Mein Denkfehler, glaube ich, bisher war, dass ich der Meinung war, dass 
> OWNCLOUD_DOCUMENT_ROOT --> APACHE2_VHOST_N_DOCUMENT_ROOT bzw.
> APACHE2_DOCUMENT_ROOT überschreibt...

Der Parameter OWNCLOUD_DOCUMENT_ROOT dient in der Tat dazu einen
vom Standard abweichenden Pfad zu setzen, denn wie zuvor geschrieben,
wird standardmäßig APACHE2_DOCUMENT_ROOT + '/nextcloud' verwendet
wenn der Parameter _nicht_ gesetzt ist.

[Hilmar Böhm]

Hallo Jürgen,

das freut mich auch... :-)

Allerdings habe ich noch eine Anmerkungen:

> Der Parameter OWNCLOUD_DOCUMENT_ROOT dient in der Tat dazu einen
> vom Standard abweichenden Pfad zu setzen, denn wie zuvor geschrieben,
> wird standardmäßig APACHE2_DOCUMENT_ROOT + '/nextcloud' verwendet
> wenn der Parameter _nicht_ gesetzt ist.
>

Dies suggeriert, dass man diesen Parameter auch einfach löschen könnte. Dem ist aber nicht so, der ece verhindert das. Er muss
offenbar immer (sichtbar) gesetzt sein und auf das /var/www/htdocs/nextcloud - Verzeichnis zeigen. Während OWNCLOUD_WEB_ROOT bei
korrekter Konfiguration nicht explizit gesetzt werden muss und nicht angezeigt wird.

Weglassen oder falsches Setzen führt bei OWNCLOUD_DOCUMENT_ROOT zu den bekannten PHP7_WEB-Fehlermeldungen.

Btw.: Gibt es eine Möglichkeit z.B. unsichtbaren Parameter OWNCLOUD_WEB_ROOT direkt im Konfigurationsdialog einzusetzen (Taste?
Tastenkombination?)? Bisher musste ich das mit einem Editor direkt in die /etc/config.d/nextcloud eintragen.

Grüße. / Hilmar.


Am 02.05.19 um 13:41 schrieb Juergen Edner:

[Hilmar Böhm]

...sorry, habe vergessen, den unteren Teil zu löschen...
Hilmar.

Am 02.05.19 um 14:33 schrieb Hilmar Böhm:

[Juergen Edner]

Hallo Hilmar,
Böhm:

> Hallo Jürgen,
>
> das freut mich auch... :-)
>
> Allerdings habe ich noch eine  Anmerkungen:
>
>> Der Parameter OWNCLOUD_DOCUMENT_ROOT dient in der Tat dazu einen
>> vom Standard abweichenden Pfad zu setzen, denn wie zuvor geschrieben,
>> wird standardmäßig APACHE2_DOCUMENT_ROOT + '/nextcloud' verwendet
>> wenn der Parameter _nicht_ gesetzt ist.
>>
> Dies suggeriert, dass man diesen Parameter auch einfach löschen könnte.
> Dem ist aber nicht so, der ece verhindert das. Er muss offenbar immer
> (sichtbar) gesetzt sein und auf das /var/www/htdocs/nextcloud -
> Verzeichnis zeigen.

wie schon geschrieben, der Parameter kann entfernt werden, da er
_automatisch_ auf den genannten Wert gesetzt wird. Ich habe dies
gerade noch einmal bei mir getestet und es wurde mir dabei _keine_
Fehlermeldung angezeigt.

APACHE2_DOCUMENT_ROOT='/var/www/htdocs'
OWNCLOUD_DOCUMENT_ROOT - nicht gesetzt.

=> intern wird '/var/www/htdocs/nextcloud' verwendet.

> Weglassen oder falsches Setzen führt bei OWNCLOUD_DOCUMENT_ROOT zu den
> bekannten PHP7_WEB-Fehlermeldungen.

Dann würde ich eigentlich erwarten, dass der Parameter
APACHE2_DOCUMENT_ROOT bei Dir abweichend gesetzt ist.

> Btw.: Gibt es eine Möglichkeit z.B. unsichtbaren Parameter
> OWNCLOUD_WEB_ROOT direkt im Konfigurationsdialog einzusetzen (Taste?
> Tastenkombination?)? Bisher musste ich das mit einem Editor direkt in
> die /etc/config.d/nextcloud eintragen.

Natürlich gibt es im ECE diese Funktion(en). Sobald es optionale
Parameter gibt wird Dir beim Öffnen der Konfiguration folgende
Meldung angezeigt. Die Information findest Du auch in der Fußzeile.

┌────────────────────[ Info ]─────────────────────┐

│ │
│ This config has some optional
values that are │
│ currently hidden. │
│
│
│ Press F4 to see all values │
│ │
│ [< OK >] │

└─────────────────────────────────────────────────┘

D.h. durch Drücken von F4 kannst Du dir die optionalen Parameter
anzeigen lassen. Weiterhin kannst Du mittels 'F8=Delete', einen
solchen Parameter wieder löschen - dies wird ebenfalls in der
Fußzeile angezeigt ;-)

[Nils Lange]

Hallo zusammen,

>>
>>> Der Parameter OWNCLOUD_DOCUMENT_ROOT dient in der Tat dazu einen
>>> vom Standard abweichenden Pfad zu setzen, denn wie zuvor geschrieben,
>>> wird standardmäßig APACHE2_DOCUMENT_ROOT + '/nextcloud' verwendet
>>> wenn der Parameter _nicht_ gesetzt ist.
>>>

was ist jetzt aber, wenn ich den Standardpfad gerne ersetzen möchte? Das
war vermutlich das Problem, warum es bei mir mit den Updates nie
geklappt hat, jedenfalls nach Version 1.5.4.

Es wäre schon ganz gut, den Ort ändern zu können, da der Platz im
webroot begrenzt ist.

Gruß, Nils

[Juergen Edner]

Hallo Nils,

> was ist jetzt aber, wenn ich den Standardpfad gerne ersetzen möchte? Das
> war vermutlich das Problem, warum es bei mir mit den Updates nie
> geklappt hat, jedenfalls nach Version 1.5.4.
>
> Es wäre schon ganz gut, den Ort ändern zu können, da der Platz im
> webroot begrenzt ist.

genau dafür ist der Parameter OWNCLOUD_DOCUMENT_ROOT gedacht. Er sorgt
dafür, dass die Dateien an einem anderen Ort, z.B. außerhalb des von
/var/www/htdocs, abgelegt werden können. Es ist nur sicher zu stellen,
dass auf den Ordner dann auch korrekt vom Server zugegriffen werden
kann. Üblicherweise geschieht dies durch eine entsprechende VHost-
Konfiguration.

[Marcus Roeckrath]

Hallo Jürgen,

Juergen Edner wrote:

>> Es wäre schon ganz gut, den Ort ändern zu können, da der Platz im
>> webroot begrenzt ist.
>
> genau dafür ist der Parameter OWNCLOUD_DOCUMENT_ROOT gedacht. Er sorgt
> dafür, dass die Dateien an einem anderen Ort, z.B. außerhalb des von
> /var/www/htdocs, abgelegt werden können.

Nun kommt noch OWNCLOUD_WEB_ROOT ins Spiel und dann ist die Verwirrung -
auch bei mir - dann wieder da.

Kannst du nochmal ganz langsam die Zusammenhänge zwischen den beiden
Parametern aufzeigen.

--
Gruss Marcus

[Juergen Edner]

Hallo Marcus,

> Nun kommt noch OWNCLOUD_WEB_ROOT ins Spiel und dann ist die Verwirrung -
> auch bei mir - dann wieder da.
>
> Kannst du nochmal ganz langsam die Zusammenhänge zwischen den beiden
> Parametern aufzeigen.

Ich weiß ehrlich gesagt nicht, was ich dazu noch groß schreiben
soll. Sieh den ..WEB_ROOT-Parameter als einen symbolischen Link
auf die Programmdateien an.

Nehmen wir an, Du befindest Dich auf einem Linux-Server, auf dem
kein Suchpfad gesetzt ist. Willst Du nun das ssh-Programm aufrufen,
welches sich ausgehend vom Root-Verzeichnis der Festplatte im
Verzeichnis /usr/bin befindet, so gibst Du den folgenden Befehl ein,
um das Programm zu starten: /usr/bin/ssh

Aus welchen Gründen auch immer verschiebst Du nun aber das ssh-Programm
in das Verzeichnis /usr/geheim und legst gleichzeitig aber einen
symbolischen Link in /usr/bin an, so lautet nun das DOCUMENT_ROOT
/usr/geheim, aber der Aufrufpfad ist immer noch gleich /usr/bin
(WEB_ROOT).

Ein anderes Mal richtet sich ein ganz schlauer jetzt aber eine
chroot-Umgebung ein, um sein System weiter abzusichern. Das chroot-
Hauptverzeichnis ist z.B. /home/chroot/dumbo. Um nun das ssh-Programm
nutzen zu können, legt er in diesem Verzeichnis einen Link auf das
ssh-Programm im Verzeichnis /usr/bin an (DOCUMENT_ROOT). Wenn er sich
nun aber in diese Umgebung einloggt, greift er über /ssh auf das das
Programm zu, da es sich für ihn ja vermeintlich im Root (WEB_ROOT)
befindet.

Um nun wieder der Bogen zu spannen, die Verlinkung wird durch die
apache2-Konfiguration hergestellt, welche ich der nextcloud-
Konfiguration irgendwie bekannt machen muss, damit die Software
weiß wo sich etwas befindet bzw. wie man darauf zugreifen kann.

[Nils Lange]

Hallo Jürgen,

> Es ist nur sicher zu stellen,
> dass auf den Ordner dann auch korrekt vom Server zugegriffen werden
> kann. Üblicherweise geschieht dies durch eine entsprechende VHost-
> Konfiguration.

Das ist ja das, was unter Version 1.5.4 noch ohne Konfiguration eines
VHosts geklappt hat. Ich hatte dort einen anderen Pfad eingetragen und
es lief.

Falls das in der aktuellen Version nicht mehr so einfach klappt, würde
ich in der Konfiguration einen Hinweis einfügen.

Oder gibt es da eventuell doch noch ein anderes Problem?

Gruß, Nils

[Marcus Roeckrath]

Hallo Nils,

Nils Lange wrote:

> Das ist ja das, was unter Version 1.5.4 noch ohne Konfiguration eines
> VHosts geklappt hat. Ich hatte dort einen anderen Pfad eingetragen und
> es lief.
>
> Falls das in der aktuellen Version nicht mehr so einfach klappt, würde
> ich in der Konfiguration einen Hinweis einfügen.
>
> Oder gibt es da eventuell doch noch ein anderes Problem?

Ich sehe derzeit nicht, dass Jürgen da gravierend die Struktur des Paketes
geändert hat.

--
Gruss Marcus

[Hilmar Böhm]

Am 05.05.19 um 09:22 schrieb Marcus Roeckrath:

>
> Ich sehe derzeit nicht, dass Jürgen da gravierend die Struktur des Paketes
> geändert hat.
>

Das glaube ich auch nicht. Die Grundstruktur stammt wohl von "Creation: 2012 Schlotze" (s. nextcloud.sh und nextcloud-update.sh)
Sie ist etwas m.E. ungewöhnlich im Vergleich den mir bekannten nextcloud-Installationen in Debian und ArchLinux/Antergos)

Ich bin der Meinung, dass OWNCLOUD_WEB_ROOT dazu dient, dass damit die in Nextcloud verwendeten Webapps gefunden werden werden
können, wenn Sie in einem anderen Verzeichnis als in /var/www/htdocs/nextcloud liegen sollten.

In der ArchLinux/Antergos liegen sie z.B. (default mäßig) in: /usr/share/nginx/nextcloud/apps/ auf das in einem config.php
referenziert wird. (hier nginx statt apache als Webserver)

Aber wenn man man alles im OWN/NEXTCLOUD-Eisfair-Standard beläßt mit der (optionalen)
OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud' (das auch weglassen werden kann, da default) und der (nicht standardmäßig
angezeigten, optionalen) OWNCLOUD_WEB_ROOT,
dann liegen die Nextcloud-Files und die zugehörigen PHP-Apps in '/var/www/htdocs/nextcloud' (und drunter). Die zugehörige
Client-URL für Nextcloud muss dass lauten: "http(s)://<NCServer-Hostname>/nextcloud, damit das für Nextcloud zuständige
index.html bzw index.php gefunden werden kann.

Die Nextcloud-Daten liegen unter /var/nextcloud/data/, an das man ggf. eine (externe) Partition mounten kann.

Ich kann natürlich auch (völlig) daneben liegen... :-)

Grüße. / Hilmar.

[Ich habe btw mal die nextcloud.sh Skripte aus V1.64 und V1.70 gedifft: keine Unterschiede. Aber im meiner 1.64 gab es die
bekannten PHP-WEB7 Fehlermeldungen; in V1.7.0 nach einem Upgrade auf diese (fehlerhafte) V1.64 waren die
PHP7-WEB-Fehlermeldungen weg und Nextcloud lief. Eine Antwort auf meine Anfrage dazu habe ich nicht bekommen. Magisch halt... :-) ]

[Marcus meinte mal, man könne jetzt auch PHP7-FPM statt PHP7 mit Nextcloud nutzen? hat das mal jemand gemacht?]

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

>> Ich sehe derzeit nicht, dass Jürgen da gravierend die Struktur des
>> Paketes geändert hat.
>>
> Das glaube ich auch nicht. Die Grundstruktur stammt wohl von "Creation:
> 2012 Schlotze"

Sebastian hat owncloud bis 2013 betreut, dann hat es Jürgen übernommen;
seitdem hat es garantiert große Umstrukturierungen gegeben, aber aktuell in
den letzten Versionen sehe ich da keine.

> [Ich habe btw mal die nextcloud.sh Skripte aus V1.64 und V1.70 gedifft:
> [keine Unterschiede.

Das meinte ich.

> [Marcus meinte mal, man könne jetzt auch PHP7-FPM statt PHP7 mit Nextcloud
> [nutzen? hat das mal jemand gemacht?]

Statt APACHE-PHP7.

--
Gruss Marcus

[Juergen Edner]

Hallo Hilmar,

> [Marcus meinte mal, man könne jetzt auch PHP7-FPM statt PHP7 mit
> Nextcloud nutzen? hat das mal jemand gemacht?]

mein Server läuft damit problemlos.

[Hilmar Böhm]

Hallo Jürgen,

>> [Marcus meinte mal, man könne jetzt auch PHP7-FPM statt PHP7 mit
>> Nextcloud nutzen? hat das mal jemand gemacht?]
>
> mein Server läuft damit problemlos.

Das ist schön für Dich. :-)

Ich habe versucht, Nextcloud 1.7.0 neu zu installieren
und erhalte folgende Fehlermeldung bei der Apache PHP7 Configuration:
------------------------------------------------------------------
Checking configuration file ...

Configuration file was saved as php7-fpm.2019-05-01-21-38-48 in /etc/backup.d.

Activate configuration now (y/n) [yes]?

You have mod_php (apache2_php7) enabled. You cannot use mod_php and php7-fpm at the same time. <===
START_PHP7_FPM will be set to 'no' [ FAIL ]
* Stopping php7-fpm ... Not running. [ WARN ]
Press ENTER to continue
------------------------------------------------------------------

Ein mod_php kann ich in dieser Konfiguration kann ich nicht finden. Wo kann ich nach dem Problem suchen?

Kannst Du mir bitte sagen, welche PHP7* Pakete ich unbedingt installiert haben muss, um Nextcloud 1.7.0 mit PHP7-FPM nutzen zu
können.

Vielen Dank und Grüße. / Hilmar.

[Juergen Edner]

Hallo Hilmar,

> Activate configuration now (y/n) [yes]?
> You have mod_php (apache2_php7) enabled. You cannot use mod_php and
> php7-fpm at the same time. <===
> START_PHP7_FPM will be set to 'no'                                    [
> FAIL ]
>  * Stopping php7-fpm ...   Not running.                               [
> WARN ]
> Press ENTER to continue
> ------------------------------------------------------------------
>
> Ein mod_php kann ich in dieser Konfiguration kann ich nicht finden. Wo
> kann ich nach dem Problem suchen?
>
> Kannst Du mir bitte sagen, welche PHP7* Pakete ich unbedingt installiert
> haben muss, um Nextcloud 1.7.0 mit PHP7-FPM nutzen zu können.

die etwas missverständliche Meldung wird vom PHP-Paket erzeugt. Wie hier
u.a. von Marcus schon mehrfach geschrieben wurde, kannst Du nicht das
apache2_php7-Paket, welches das Apache2-Modul "mod_php" enthält, und das
php7-fpm-Paket gleichzeitig aktivieren und verwenden.

Öffne, die apache2_php7-Konfiguration und _deaktiviere_ diese.
Anschließend öffnest Du die php7-fpm-Konfiguration und _aktivierst_ sie.
Die Parameter solltest Du analog von apache2_php7-Paket in die php7-fpm-
Konfiguration übernehmen können.

Gruß Jürgen
PS: Für den Wechsel ist eine Neuinstallation des nextcloud-Paketes
_nicht_ erforderlich ;-)
--
Mail: jue...@eisfair.org

[Holger Bruenjes]

Hallo Hilmar

Am 06/05/2019 um 12.17 schrieb Hilmar Böhm:

> Ein mod_php kann ich in dieser Konfiguration kann ich nicht finden. Wo kann ich nach dem Problem suchen?
>
> Kannst Du mir bitte sagen, welche PHP7* Pakete ich unbedingt installiert haben muss, um Nextcloud 1.7.0 mit PHP7-FPM nutzen zu
> können.

setup
4. Service administration
x Apache2 Webserver
2. onfiguration
4. Modules configuration

PHP7 Administration
PHP7-FPM Administration

und lade in der apache2 config _nicht_ das 'prefork' Modul

APACHE2_MPM='event'

Holger

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm schrieb am Mon, 06 May 2019 12:17

> >> [Marcus meinte mal, man könne jetzt auch PHP7-FPM statt PHP7
> mit
> >> Nextcloud nutzen? hat das mal jemand gemacht?]
> >
> > mein Server läuft damit problemlos.

> Das ist schön für Dich. :)

>
> Ich habe versucht, Nextcloud 1.7.0 neu zu installieren
> und erhalte folgende Fehlermeldung bei der Apache PHP7
> Configuration:
> ------------------------------------------------------------------
> Checking configuration file ...
>
> Configuration file was saved as php7-fpm.2019-05-01-21-38-48 in
> /etc/backup.d.
>
> Activate configuration now (y/n) [yes]?
> You have mod_php (apache2_php7) enabled. You cannot use mod_php and
> php7-fpm at the same time. <===
> START_PHP7_FPM will be set to 'no'
> [ FAIL ]
> * Stopping php7-fpm ... Not running.
> [ WARN ]

Steht doch da; Wenn du php7_fpm nutzen willst, musst du apache2_php7
deaktivieren.
--
Gruß Marcus

[Hilmar Böhm]

Hallo Jürgen,

Danke für die Info.

Ich will nicht APACHE2_PHP7 durch PHP7_FPM ersetzen also wechseln, sondern PHP mit PHP7-FPM, Apache und Nextcloud 1.7.0 neu
installieren, wie ich auch geschrieben habe.

Danke für den Hinweis, nicht APACHE2_PHP7 zu installieren, sondern stattdessen PHP7_FPM.
Die Liste der installierten PHP7-Kits sieht jetzt so aus:

-----------------------------------------------------------------------------------------------------
IS │Name │Version│Status│Date │Short
│─────┼──────────────┼───────┼──────┼──────────┼───────────────────────────────────┼
│- │apache2_php7 │1.1.4 │stable│2019-01-22│Apache2 Modul: Mod PHP7 │
│- │php7-apcu │1.1.3 │stable│2019-01-18│php7 APC User Cache │
│- │php7-cli │1.1.4 │stable│2019-01-22│php7 Command Line Interface │
│inst.│php7-common │1.1.3 │stable│2019-01-18│php7-common │
│- │php7-firebird │1.1.3 │stable│2019-01-18│php7 firebird Extension │
│inst.│php7-fpm │1.1.4 │stable│2019-01-22│php7-fpm - FastCGI Process Manager │
│inst.│php7-imagick │1.1.3 │stable│2019-01-18│php7 ImageMagick Extension │
│inst.│php7-intl │1.1.3 │stable│2019-01-18│php7 Internationalization extension│
│- │php7-ldap │1.1.3 │stable│2019-01-18│php7 ldap Extension │
│inst.│php7-mysql │1.1.3 │stable│2019-01-18│php7 MySQL Extension │
│inst.│php7-opcache │1.1.3 │stable│2019-01-18│php7 opcache Extension │
│inst.│php7-pcntl │1.1.3 │stable│2019-01-18│php7 Process Control Extension │
│- │php7-pdflib │1.1.3 │stable│2019-01-18│php7 PDF Extension │
│- │php7-smbclient│1.1.3 │stable│2019-01-18│php7 smbclient Extension │
│- │php7-soap │1.1.3 │stable│2019-01-18│php7 soap Extension │
│- │php7-sqlite │1.1.3 │stable│2019-01-18│php7 sqlite Extension │
│- │php7-xz │1.1.3 │stable│2019-01-18│php7 xz Extension │
│─────┼──────────────┼───────┼──────┼──────────┼───────────────────────────────────┼
-----------------------------------------------------------------------------------------------------

Ist das ok soweit. Brauche ich auch noch "php7-cli"?
Natürlich fehlt noch Apache2 und die Konfig dessen und das eigentliche Nextcloud-Kit.

Gruß. / Hilmar.


Am 06.05.19 um 12:40 schrieb Juergen Edner:

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Ich will nicht APACHE2_PHP7 durch PHP7_FPM ersetzen also wechseln, sondern
> PHP mit PHP7-FPM, Apache und Nextcloud 1.7.0 neu installieren, wie ich
> auch geschrieben habe.

APACHE2_PHP7 und PHP7_FPM bedienen die gleiche Funktionalität, du musst dich
also zwischen einem der beiden entscheiden, eine gleichzeitige Aktivierung
geht NICHT!

> Danke für den Hinweis, nicht APACHE2_PHP7 zu installieren, sondern
> stattdessen PHP7_FPM. Die Liste der installierten PHP7-Kits sieht jetzt so
> aus:

Ist ja nach erster Durchsicht auch i. O.

> Ist das ok soweit. Brauche ich auch noch "php7-cli"?

Ja, denn der Wartungsjob aus nextcloud erfordert den Kommandozeilen-PHP.

> Natürlich fehlt noch Apache2 und die Konfig dessen und das eigentliche
> Nextcloud-Kit.

Mich wundert, dass nicht irgendetwas schon als require den Apache2
mitgezogen hat; aber seis drum, ohne Apachen geht natürlich nichts.

Mich wundert ebenso, wieso man nicht mit dem Apachen anfängt, den zum laufen
bringt, dann php und dann die Anwendungen installiert.

Das Pferd von hinten aufzuzäumen, ist in der Regel keine gute Idee.

--
Gruss Marcus

[Hilmar Böhm]

Hallo marcus

Am 06.05.19 um 16:38 schrieb Marcus Roeckrath:

>> ...sondern PHP mit PHP7-FPM, Apache und Nextcloud 1.7.0 neu installieren, wie ich
>> auch geschrieben habe.
>

>eine gleichzeitige Aktivierung geht NICHT!

das hatte ich auch gar nicht gesagt!
mir ging es um eine Neuinstallation. Und dass beides nicht gleichzeitig geht, hatten wir ja schon geklärt!...

>
>
> Mich wundert ebenso, wieso man nicht mit dem Apachen anfängt, den zum laufen
> bringt, dann php und dann die Anwendungen installiert.
>
> Das Pferd von hinten aufzuzäumen, ist in der Regel keine gute Idee.
>

Warum nicht. Wenn alles richtig required ist, muss es auch so rum gehen.
Außerdem habe ich mir bei meiner Tabelle (aus: setup-2-5-"php") nur PHP-Kits aufgeführt; vom Apache2-Kit war gar nicht die Rede.
Btw. Apache2 (inkl. certs) ist natürlich dabei auch installiert worden, wenn Dich das beruhigt. :-)



Viele Grüße. / Hilmar.

[Hilmar Böhm]

Am 06.05.19 um 13:07 schrieb Holger Bruenjes:

> und lade in der apache2 config _nicht_ das 'prefork' Modul
>
> APACHE2_MPM='event'

Hallo Holger,
vielen Dank für den Tip.
Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

>> Mich wundert ebenso, wieso man nicht mit dem Apachen anfängt, den zum
>> laufen bringt, dann php und dann die Anwendungen installiert.
>>
>> Das Pferd von hinten aufzuzäumen, ist in der Regel keine gute Idee.
>>
> Warum nicht.

Nextcloud hat z. B. keine require auf apache2-php7 oder php7-fpm, weil man
hier die Wahl hat.

> Btw. Apache2 (inkl. certs) ist natürlich dabei auch installiert worden,
> wenn Dich das beruhigt. :-)

Gut.

--
Gruss Marcus

[Hilmar Böhm]

Hallo Marcus,

> Nextcloud hat z. B. keine require auf apache2-php7 oder php7-fpm, weil man
> hier die Wahl hat.

Das muss man wissen!?

Anmerkung: Könnte man das nicht in die Apache2-Konfig für apache2-php und/oder php-fpm einbauen, das sich diese Module/Pakete
ausschließen
oder das zumindest in der Doku erwähnen?
Gruß. / Hilmar.

[Kay Martinen]

Am 01.05.2019 um 01:21 schrieb Hilmar Böhm:
> Hallo Nils,
>
> Am 01.05.19 um 00:55 schrieb Nils Lange:
>
>> Merkwürdig ist, dass die Installation der 1.5.4 die
>> Nextcloud-Verzeichnisse anlegt, bei Installation der 1.6.4 oder 1.7.0
>> bleiben die Verzeichnisse leer und es kommen die Meldungen der
>> PHP-Module.

Hier: Nicht nur die!
>
> Nach meiner Erfahrung werden diese Verzeichnisse erst dann angelegt und
> befüllt, wenn die Nextcloud-Konfiguration einwandfrei, ohne
> Fehlermeldungen durchgelaufen ist. Also auch diese
> PHP7_WEB-Fehlermeldungen müssen weg sein.

Das klappt natürlich nur wenn das apps2 verzeichniss auch da wäre. Was
es nicht ist und es auch nicht angelegt wird weil die konfig dies als
fehlend moniert und auch beim speichern trotzdem moniert, es nicht
anlegt und danach kommen die ganzen anderen Fehlermeldungen. Die mich im
Übrigen zu dem schluß kommen lassen das ein memorylimit von 512M bei
einer VM die nur 512M hat nicht funktionieren kann.

Man könnte den verzeichnis-index auf null setzen aber das produziert
eine Rote Warnmeldung, d.h. SO geht es auch nicht.

Ich habs auch aufgegeben. Owncloud und Nextcloud sind nach meinem
Dafürhalten auf dem Eisfair uninstallierbar!

Jedenfalls SO lange wie der Installationsversuch eines dieser Pakete
rekursiv über 120 andere Pakete mit insg. ca. 400MB auf die Platte
spült, bei diesen aber nicht in der Lage ist die Konfiguration so zu
verändern das sie für dieses Paket ohne fehler durchläuft.

Denn es scheint als müsse man zuerst sqlite3 redis u.a.
nachinstallieren, den support dafür aktivieren, die memorylimits hoch
setzen ein php7-web modul installieren das ich nicht mal fand und dann
noch mehr. Und vielleicht noch mehr. Und den apachen muß man noch
aktivieren, redis aktivieren und und und....

Hat IRGEND jemand diese Cloud-pakete mal auf einem Neuen Eisfair
installiert - ohne Anleitung? Denn, es scheint für dieses Komplexe
Prozedere keine zu geben.

Die Installation von baikal scheint dagegen noch glatt einfach - obwohl
das auch eine menge details sind. Ob ich mir das antue weiß ich noch
nicht. Ich weiß nur das ich die Test-vm für die Cloud jetzt in die tonne
feuere und lieber neu starte.

Sorry, aber 50 Schritte zum funktionierenden Heimcloud-server... Jede
Windows Installation ist da mehr EASY als das hier. Mußte ich mal los
werden...


Kay

--
Sent via SN (Eisfair-1)

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

> Ich habs auch aufgegeben. Owncloud und Nextcloud sind nach meinem
> Dafürhalten auf dem Eisfair uninstallierbar!

Ich kenne die Installation eines aktuellen own/nextcloud-Paketes nicht, da
ich in der Schule immer noch eine älteres owncloud einsetze (nur für
internen Kalender und Adressbuch), denn während der Arbeitszeit kann ich
das nicht austauschen und abends von extern habe ich nicht den Zugriff auf
alle Clients, um die Kalender/Adressbuch-URLs zu ändern.

Owncloud war aber bei laufendem und konfigurierten apache/apache_php5 und
mariadb problemlos installierbar.

> Jedenfalls SO lange wie der Installationsversuch eines dieser Pakete
> rekursiv über 120 andere Pakete mit insg. ca. 400MB auf die Platte
> spült, bei diesen aber nicht in der Lage ist die Konfiguration so zu
> verändern das sie für dieses Paket ohne fehler durchläuft.

Ein Paket fummelt nicht an der Konfiguration anderer Pakete rum.

> Denn es scheint als müsse man zuerst sqlite3 redis u.a.
> nachinstallieren, den support dafür aktivieren, die memorylimits hoch
> setzen ein php7-web modul installieren das ich nicht mal fand und dann
> noch mehr. Und vielleicht noch mehr. Und den apachen muß man noch
> aktivieren, redis aktivieren und und und....

Ohne Erfüllung der Anforderungen von nextcloud geht es halt nicht.

Eventuell wäre es mal hilfreich, alle Vorschritte mal zusammenzustelen, d.
h. alle Paket und deren Konfiguration aufzuzählen, deren korrekte Funktion
unabdingbar ist.

Das könnte man ins Wiki stellen und bei der nextcloud-Installation einen
Hinweis auf den Wiki-artikel auszugeben, das unbedingt alle dort
angegebenen Punkte abzuarbeiten sind, bevor nextcloud erfolgreich
konfiguriert werden kann.

> Die Installation von baikal scheint dagegen noch glatt einfach

Ich überlege, da ja sowieso nur Kalender und Adressbuch gebraucht wird,
owncloud durch baikal zu ersetzen.

> Sorry, aber 50 Schritte zum funktionierenden Heimcloud-server... Jede
> Windows Installation ist da mehr EASY als das hier. Mußte ich mal los
> werden...

Und nextcloud auf Win (als Server) zu installieren, ist nur ein Klick? Da
muss man nicht erst dafür sorgen, dass man einen funktionierenden Webserver
oder Datenbankserver hat?

Wie sieht das unter anderen Linux-Distris aus?

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Kay,

Marcus Roeckrath wrote:

>> Sorry, aber 50 Schritte zum funktionierenden Heimcloud-server... Jede
>> Windows Installation ist da mehr EASY als das hier. Mußte ich mal los
>> werden...
>
> Und nextcloud auf Win (als Server) zu installieren, ist nur ein Klick? Da
> muss man nicht erst dafür sorgen, dass man einen funktionierenden
> Webserver oder Datenbankserver hat?
>
> Wie sieht das unter anderen Linux-Distris aus?

Ich habe hier eine Anleitung für Debian gefunden, bei der man auch erst alle
Bedingungen erfüllt (Installation und Konfiguration), bevor es an die
nextcloud-Installation geht.

https://www.c-rieger.de/nextcloud-installation-guide-debian/

--
Gruss Marcus

[Kay Martinen]

Am 15.05.2019 um 08:07 schrieb Marcus Roeckrath:
> Hallo Kay,
>
> Kay Martinen wrote:
>
>> Ich habs auch aufgegeben. Owncloud und Nextcloud sind nach meinem
>> Dafürhalten auf dem Eisfair uninstallierbar!
>
> Ich kenne die Installation eines aktuellen own/nextcloud-Paketes nicht, da
> ich in der Schule immer noch eine älteres owncloud einsetze (nur für
> internen Kalender und Adressbuch), denn während der Arbeitszeit kann ich

Mehr als Kalender; die man evtl. mal mit externen Teilen kann; und
Adressbuch-ablage für TB brauche ich eigentlich auch nicht. Schön, eine
Fileablage wäre ggf. mal nett aber das bekommt man auch anders leichter hin.

> Owncloud war aber bei laufendem und konfigurierten apache/apache_php5 und
> mariadb problemlos installierbar.

Dann mach dir mal den Spaß und setz in VB eine E1 VM auf und sag nur
"Own|next-cloud" installieren. Die jeweils aktuellsten versionen 1.7x
hab ich genommen. Du wirst dich wundern und umgucken. Als stünde man im
Urwald...

>> Jedenfalls SO lange wie der Installationsversuch eines dieser Pakete
>> rekursiv über 120 andere Pakete mit insg. ca. 400MB auf die Platte
>> spült, bei diesen aber nicht in der Lage ist die Konfiguration so zu
>> verändern das sie für dieses Paket ohne fehler durchläuft.
>
> Ein Paket fummelt nicht an der Konfiguration anderer Pakete rum.

Hmm, ja. Genau das ist das Problem denke ich. Aber, zumindest der Apache
bietet doch schon eine einfache Möglichkeit mit den mods-enabled und
conf-enabled Verzeichnissen dort eine dienst-spezifische Konfiguration
ab zu legen die er dann laden kann. IMHO wird das bei Debian ähnlich
gelöst, dort sind die Pakete m.W. aber besser aufeinander abgestimmt und
anderes wird wohl über "installations-trigger" erledigt. Z.b. ein
'update-grub' start nach neuem kernel oder das schlicht eine
owncloud-conf von available nach enabled kopiert wird und dem apachen
ein HUP gesendet wird (vermutung).

>> Denn es scheint als müsse man zuerst sqlite3 redis u.a.
>> nachinstallieren, den support dafür aktivieren, die memorylimits hoch
>> setzen ein php7-web modul installieren das ich nicht mal fand und dann
>> noch mehr. Und vielleicht noch mehr. Und den apachen muß man noch
>> aktivieren, redis aktivieren und und und....
>
> Ohne Erfüllung der Anforderungen von nextcloud geht es halt nicht.

Schon klar. Aber das Prozedere hier ist in etwa vergleichbar damit ein
Auto beim Händler zu bestellen und man bekommt einen Autobaukasten mit
vielen Teilen vor die Tür gekippt - aber keine Anleitung oder einen
Mechaniker der es zusammen setzt. Das ist weder Easy noch das was man
erwarten würde.

> Eventuell wäre es mal hilfreich, alle Vorschritte mal zusammenzustelen, d.
> h. alle Paket und deren Konfiguration aufzuzählen, deren korrekte Funktion
> unabdingbar ist.
>
> Das könnte man ins Wiki stellen und bei der nextcloud-Installation einen
> Hinweis auf den Wiki-artikel auszugeben, das unbedingt alle dort
> angegebenen Punkte abzuarbeiten sind, bevor nextcloud erfolgreich
> konfiguriert werden kann.

Ich hab in die Eisfair-doku geschaut, in die Leere FAQ und dann ins
Wiki. Dort fand ich zu "cloud" nur baikal. Nach dem Gestrigen hab ich
kein Interesse das noch mal intensiver durch zu kauen. Eine Auflistung
der Fehler und sachen die ab install nicht gehen und moniert werden
könnte ich eher liefern. Was aber nur die Ingredenzien sind, ein
Kochrezept wird daraus noch nicht.

>> Die Installation von baikal scheint dagegen noch glatt einfach
>
> Ich überlege, da ja sowieso nur Kalender und Adressbuch gebraucht wird,
> owncloud durch baikal zu ersetzen.

Ja, dito. Wolkenkram ist eh nicht das was ich gut fände oder brauche.
Kalender und Adressbuch sharing sind die einzig Interesanten Punkte.

>> Sorry, aber 50 Schritte zum funktionierenden Heimcloud-server... Jede
>> Windows Installation ist da mehr EASY als das hier. Mußte ich mal los
>> werden...
>
> Und nextcloud auf Win (als Server) zu installieren, ist nur ein Klick? Da
> muss man nicht erst dafür sorgen, dass man einen funktionierenden Webserver
> oder Datenbankserver hat?

Ist meine Annahme da
1. ich nicht nachgeschaut hab ob es außer einem Client auch einen Server
für Win gibt
2. Win-Installationen dinge wie Datenbank und Webserver üblicherweise
schlicht mit bringen, installieren und dem user kaum
konfig-möglichkeiten bieten. Der angebotene Client für Win braucht
vermutlich weder Web noch DB Server...
3. ich eh nicht vor hab ein Win als Cloudserver ein zu richten.

> Wie sieht das unter anderen Linux-Distris aus?

Ich fand beim Suchen eine Anleitung für Debian die im kern daraus
bestand, apache mit zwei modulen installieren, MariaBD installieren,
Nextcloud einrichten. Die Details hab ich nicht geprüft aber eine
gleichartige Anleitung für Eisfair wäre vermutlich einige Seiten länger.
Vielleicht irre ich auch und es ist nur die Frage was man zuerst
installiert und einrichtet. Ich hab mit dem Top-level Paket angefangen,
der rest kam rekursiv (wohl: durch require) auf die Platte.

Ehrlich gesagt: dieses rekursive installieren/require suggeriert m.E.
auch eine Funktionalität die offensichtlich nicht da ist. Das die
gesamte Konfiguration von einigen der 120 Pakete komplett von Hand
erledigt werden muß, und das offensichtlich auch noch in bestimmter
Reihenfolge (erst certs, dann apache ssl an z.b.?) gemacht werden muß.

Okay, um Fair zu bleiben, Ein Cloud-setup in einen großen Blob zu packen
ist auch nicht eisfair-style. Und wenn die Regel das ein paket nicht an
der Konfig der anderen manipuliert dazu gehört dann ist das so. Dann
fehlt es halt "nur" am Rezept aus 100 Einzelteilen einen Cloudserver zu
basteln. Und wenn der nur das macht gibt es hoffentlich auch weniger
Nebenwirkungen das andere Dienste nach den Änderungen nicht mehr laufen.

[Ulrich Hupe]

>
> Hat IRGEND jemand diese Cloud-pakete mal auf einem Neuen Eisfair
> installiert - ohne Anleitung? Denn, es scheint für dieses Komplexe
> Prozedere keine zu geben.

Ja ich habs geschafft,
2 Nachmittage, 2 Abende und eine Kiste Bier braucht man dafür.
:-)

Ulrich

[Ulrich Hupe]

> Mehr als Kalender; die man evtl. mal mit externen Teilen kann; und
> Adressbuch-ablage für TB brauche ich eigentlich auch nicht. Schön, eine
> Fileablage wäre ggf. mal nett aber das bekommt man auch anders leichter hin.
>

Nur als Fileserver ist das natürlich etwas mäßig.
Ich nutze die gpxPod App zum Planen von Touren und Urlaub
und natürlich talk für konferenzgespräche.

Gruß,
Ulrich

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

> Mehr als Kalender; die man evtl. mal mit externen Teilen kann; und
> Adressbuch-ablage für TB brauche ich eigentlich auch nicht. Schön, eine
> Fileablage wäre ggf. mal nett aber das bekommt man auch anders leichter
> hin.

Und das ist own/nextcloud Overkill, wenn man wirklich nur Bedarf für diese
beiden Komponenten hat.

Zudem haben kleinere Projekte, die dennoch den eigenen Bedarf abdecken, auch
Sicherheitsvorteile, weil sich in übersichtlichen Projekten weniger Fehler
"verstecken" können.

>> Eventuell wäre es mal hilfreich, alle Vorschritte mal zusammenzustelen,
>> d. h. alle Paket und deren Konfiguration aufzuzählen, deren korrekte
>> Funktion unabdingbar ist.
>>
>> Das könnte man ins Wiki stellen und bei der nextcloud-Installation einen
>> Hinweis auf den Wiki-artikel auszugeben, das unbedingt alle dort
>> angegebenen Punkte abzuarbeiten sind, bevor nextcloud erfolgreich
>> konfiguriert werden kann.
>
> Ich hab in die Eisfair-doku geschaut, in die Leere FAQ und dann ins
> Wiki. Dort fand ich zu "cloud" nur baikal. Nach dem Gestrigen hab ich
> kein Interesse das noch mal intensiver durch zu kauen. Eine Auflistung
> der Fehler und sachen die ab install nicht gehen und moniert werden
> könnte ich eher liefern. Was aber nur die Ingredenzien sind, ein
> Kochrezept wird daraus noch nicht.

Ein Wiki hat ja den Vorteil, das man zunächst ins unreine schreiben kann und
das dann unter Mithilfe vieler ausbaut.

Wenn niemand damit anfängt, dann wird das auch nichts. Ich habe nur
gewachsene Systeme, wo die Grundlagen schlicht erfüllt sind.

Bitte nicht vergessen, dass eisfair im Kern von 7 Leuten (ich hoffe ich habe
mich jetzt nicht verzählt) gemacht wird. Die Anwender sind also hier
gefordert, nach ihren Möglichkeiten etwas beizutragen.

>>> Die Installation von baikal scheint dagegen noch glatt einfach

Ich habe schonmal überlegt, ob man das nicht auch mal als Paket hinbekommt -
kurz- und mittelfristig kann ich mir sowas aber nicht ans Bein binden.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Ulrich,

Wer hats Bier getrunken? Du oder war das der Preis für den helfenden
Freund? ;-)

Also geht es doch.

Manchmal habe ich den Eindruck, dass man ein "Profi"-System haben will, was
einem aber eine externe Intelligenz so ganz aus der Glaskugel ohne eigenes
Zutun zusammenstellen soll.

Mein rat: Immer von unten nach oben und dann steht die
nextcloud-Installation ganz am Ende.

--
Gruss Marcus

[Kay Martinen]

Am 15.05.2019 um 17:03 schrieb Marcus Roeckrath:
> Hallo Ulrich,
>
> Ulrich Hupe wrote:
>
>>> Hat IRGEND jemand diese Cloud-pakete mal auf einem Neuen Eisfair
>>> installiert - ohne Anleitung? Denn, es scheint für dieses Komplexe
>>> Prozedere keine zu geben.
>>
>> Ja ich habs geschafft,
>> 2 Nachmittage, 2 Abende und eine Kiste Bier braucht man dafür.
>> :-)

Dann wird das hier nie was. Denn ich habe NIE Bier im Haus. :-)

> Wer hats Bier getrunken? Du oder war das der Preis für den helfenden
> Freund? ;-)

Ein "externer Berater" oder Consultant arbeitet nicht für ne Kiste Bier.
Dann bleibt ja nur das Helferlein übrig. Oder selbst getrunken (Frust
abbau!?)

> Also geht es doch.

Nach einer Kiste Bier würde bei mir nicht mehr viel gehen.
Glücklicherweise habe ich das Problem nicht. (Kein Bier=Kein Problem.)

Hmm, Marcus: Ich habe nie sagen wollen das es NICHT geht. Nur das es
sehr schwergängig ist... SEHR!

> Manchmal habe ich den Eindruck, dass man ein "Profi"-System haben will, was
> einem aber eine externe Intelligenz so ganz aus der Glaskugel ohne eigenes
> Zutun zusammenstellen soll.

Jaaaa, DAS wäre latürnicht die (Unerfüllbare) Idealvorstellung. Zwischen
DEM und dem aktuellen Problemfall liegen m.E. viele Eisfair Pakete die
diese Probleme nicht haben oder provozieren. Und ich meine immer noch
das "Cloud" heute eher heißt "Alles was früher separat war über eine
http(s) Verbindung" zu pressen. Darum finde ich "Cloud" oft im Ansatz
Bullshit aber es ist eben auch Hype und KANN ein Vorteil sein. Wenn
man's denn hin kriegt.

N.B. Arbeitet jemand an einem K.I. Paket? /dev/glaskugel not found or
broken. :-)

> Mein rat: Immer von unten nach oben und dann steht die
> nextcloud-Installation ganz am Ende.

Hardware: Nix
Software: Kernel,Base, apache, php7 und dann... muß man sich IMHO erst
mal entscheiden ob man mariadb oder was anderes nimmt/will. Ich wollte
sqlite aber das hat ja nun nich so recht geklappt.

Mal sehen. Ich bräuchte wohl erst mal einen Account um im Wiki zu
schreiben oder? Der foren-account geht dafür nicht!?

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

> Jaaaa, DAS wäre latürnicht die (Unerfüllbare) Idealvorstellung. Zwischen
> DEM und dem aktuellen Problemfall liegen m.E. viele Eisfair Pakete die
> diese Probleme nicht haben oder provozieren.

Kaum ein Paket hat aber so große Abhängigkeiten.

> Und ich meine immer noch
> das "Cloud" heute eher heißt "Alles was früher separat war über eine
> http(s) Verbindung" zu pressen. Darum finde ich "Cloud" oft im Ansatz
> Bullshit aber es ist eben auch Hype und KANN ein Vorteil sein. Wenn
> man's denn hin kriegt.

Warum sind solche Monster wie Word und Co kaum noch benutzbar, so
fehleranfällig, ...?

Weil aus einer reinen Textverarbeitung Programme geworden sind, die
Desktop-Publishing, Quark-XPress, Buchgestaltung, ... in sich vereinen
sollen.

Der Ansatz eine Aufgabe ein Tool ist sinnvoller - ich kann genau eines,
dafür das gut.

> Hardware: Nix
> Software: Kernel,Base, apache, php7 und dann... muß man sich IMHO erst
> mal entscheiden ob man mariadb oder was anderes nimmt/will. Ich wollte
> sqlite aber das hat ja nun nich so recht geklappt.

Ohne Entscheidungen geht es nicht.

Das macht es ja auch nicht möglich, dass nextcloud alles wirklich requiern
kann. Bei php kann man zwischen php5, php7 oder php7_fpm wählen.

Bei der DB ist es postgres, mariadb/mysql oder sqlite.

Übrigens ist eine echte DB performanter als sqlite und IMHO für nextcloud
nicht die erste Wahl.

Mal wird esay gefordert; wenn dann Freiheiten fehlen, ist dann auch wieder
easy Schuld.

Ohne Kompromisse geht es irgendwie nicht.

> Mal sehen. Ich bräuchte wohl erst mal einen Account um im Wiki zu
> schreiben oder? Der foren-account geht dafür nicht!?

Nein, der ist davon unabhängig.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

[Wiki]

> Mal sehen. Ich bräuchte wohl erst mal einen Account um im Wiki zu
> schreiben oder? Der foren-account geht dafür nicht!?

Es wäre schön, wenn Ulrich da dann auch seine Erfahrungen der "Bierprobe"
einbringt, also aus der Erinnerung mal eine Liste seines Vorgehens
erstellt:

1. Installiere XYZ
2. Konfiguriere XYZ
...

Dann kann man das auf einem frischen System nachspielen und das Vorgehen
ergänzen oder verfeinern.

--
Gruss Marcus

[Ulrich Hupe]

> 2 Nachmittage, 2 Abende und eine Kiste Bier braucht man dafür.
>> :-)
>
> Wer hats Bier getrunken? Du oder war das der Preis für den helfenden
> Freund? ;-)
>
> Also geht es doch.

Ich habs immer nach "Feierabend" getrunken". Erst aus Frust dann aus Freude.
Helfer gibt es in der Tat wenig. Viele haben Ahnung, aber keine Kenntnis.
Eine leichtere Einstiegsdroge ist DRUPAL installieren und gleichzeitig
von MySQL nach MariaDB wechseln.
Ich habe dann nextcloud 2-3 mal inst. bevor es dann ging.....
Meist waren es Kleinigkeiten. Die Probleme sind alle ähnlich.

Ulrich

[Ulrich Hupe]

Hallo,
Ja gut, das ist kein Hexenwerk,

> Es wäre schön, wenn Ulrich da dann auch seine Erfahrungen der "Bierprobe"
> einbringt, also aus der Erinnerung mal eine Liste seines Vorgehens
> erstellt:
>
> 1. Installiere XYZ
> 2. Konfiguriere XYZ
> ...

Mein Problem lag daran, dass ich zunächst owncloud installierte, damit
nicht zufrieden war und dann parrallel nextcloud installiert hatte.
Danach fiel Nextcloud in den Wartungsmdus, ich konnte keinen User inst.
und Redis gab Fehler.
Da ich User bin und kein Programmierer habe ich:
Alles (clouds) deinstalliert (Bier trinken!) und neu aufgesetzt.

Apache sollte laufen, wenn Zugang über HTTPs dann auch cert.
cron
samba
MC
PHP7 installieren
Datenbank inst. wie MariaDB102 incl. phpmyadmin55
-> Kurzum, es sollte/muß ein funktionierender "LAMP" Server laufen.

Dann REDIS und php7-cli installieren
und Anpassen

hier meine derzeitigen confs:
PHP7CLI_MAX_POST_SIZE='64M'
PHP7CLI_MAX_UPLOAD_FILESIZE='128M'
PHP7CLI_MEMORY_LIMIT='512M'
PHP7CLI_UPLOAD_DIR='/tmp'
PHP7CLI_EXT_CACHE='apcu+redis' wichtig!
PHP7CLI_EXT_SOAP='no'
PHP7CLI_EXT_LDAP='no'
PHP7CLI_EXT_MYSQL='yes'
PHP7CLI_EXT_MYSQL_SOCKET='/run/mysql/mysql.sock'
PHP7CLI_EXT_MYSQL_HOST='192.168.66.3' (z.B.)
PHP7CLI_EXT_MYSQL_PORT='3306'
PHP7CLI_EXT_MSSQL='no'
PHP7CLI_EXT_PGSQL='no'
PHP7CLI_EXT_INTER='no'
PHP7CLI_EXT_SQLITE3='no'

PHP7_MAX_POST_SIZE='128M'
PHP7_MAX_UPLOAD_FILESIZE='128M'
PHP7_MEMORY_LIMIT='512M'
PHP7_UPLOAD_DIR='/tmp'
PHP7_EXT_CACHE='apcu+redis' wichtig!
PHP7_EXT_SOAP='no'
PHP7_EXT_LDAP='yes'
PHP7_EXT_MYSQL='yes'
PHP7_EXT_MYSQL_SOCKET='/run/mysql/102/mysql.sock'
PHP7_EXT_MYSQL_HOST='192.168.66.3' (z.B.)
PHP7_EXT_MYSQL_PORT='3306'

-> dann die directories htdocs/nextcloud/apps2 anlegen
Ich habe hier bewußt den default "Ort" gewählt
Dies habe ich mit dem MC gemacht, nicht mit Samba! wegen der Rechte (777)!

-> Datenbank anlegen mit user (s.u.) und dem fast alle Rechte geben
localer Zugriff

-> Dann next cloud installieren:

trusted Domain ist wichtig! Die Adresse des eigenen Servers!

START_OWNCLOUD='yes'
OWNCLOUD_ADMIN_USER='Ulrich' # name of administrator
OWNCLOUD_ADMIN_PASS='geheim' # password of administrator
OWNCLOUD_DOCUMENT_ROOT='/var/www/htdocs/nextcloud'
OWNCLOUD_TRUSTED_DOMAIN='Eisbaer.mein.netz|192.168.66.3'

OWNCLOUD_DB_TYPE='mysql' # database type: e.g. mysql
OWNCLOUD_DB_HOST='' # fqdn of database host
OWNCLOUD_DB_USER='ncuser' # mysql database access username
OWNCLOUD_DB_PASS='ncuser' # mysql database access password

OWNCLOUD_SECURITY_LOWERING='no'
OWNCLOUD_SECURITY_HTACCESS_RW='no'

OWNCLOUD_SMTP_MANUAL_CONFIGURATION='no'
OWNCLOUD_SMTP_HOST='127.0.0.1'
OWNCLOUD_SMTP_AUTH='none'
OWNCLOUD_SMTP_AUTH_USER=''
OWNCLOUD_SMTP_AUTH_PASS=''
OWNCLOUD_SMTP_TRANSPORT='default'

OWNCLOUD_APPSTORE_ENABLED='yes' # enable apps installation: yes or no
OWNCLOUD_APPS_N='1' # number of apps directories
OWNCLOUD_APPS_1_DIR='/var/www/htdocs/nextcloud/apps2'
# 1. apps directory
OWNCLOUD_APPS_1_URL='/apps2' # apps URL
OWNCLOUD_APPS_1_WRITEABLE='yes' # writeable: yes or no

OWNCLOUD_LOG_COUNT='10' # number of log files to save
OWNCLOUD_LOG_INTERVAL='weekly' # interval: daily, weekly, monthly


Dann muß das laufen, oder ich hab was vergessen.

Gruß,
Ulrich

[Marcus Roeckrath]

Hallo Ulrich,

Ulrich Hupe wrote:

> Apache sollte laufen, wenn Zugang über HTTPs dann auch cert.
> cron
> samba
> MC
> PHP7 installieren
> Datenbank inst. wie MariaDB102 incl. phpmyadmin55
> -> Kurzum, es sollte/muß ein funktionierender "LAMP" Server laufen.

Das könnte Jürgen vielleicht in die Doku nochmal deutlich reinschreiben -
die Grundlage muss laufen, dann kann man sich an next/owcloud begeben.

Das kann das next/owncloud-Paket nicht alles selbst, prüfen, konfigurieren,
erahnen, ... denn manches ist ja sogar nach eigenem Gusto frei wählbar
(DB-System; PHP-Variante).

> Dann REDIS und php7-cli installieren

usw.

> -> dann die directories htdocs/nextcloud/apps2 anlegen

Das sollte IMHO aber das cloud-Paket erledigen.

> -> Datenbank anlegen mit user (s.u.) und dem fast alle Rechte geben
> localer Zugriff

Der in next/owncloud definierte Datenbankuser sollte aber vom cloud-Paket
angelegt werden; gemeint ist hier natürlich nicht der Root-User von
mariadb, der muss beim konfigurieren von mariadb gesetzt werden.

--
Gruss Marcus

[Ulrich Hupe]

>> -> dann die directories htdocs/nextcloud/apps2 anlegen
>
> Das sollte IMHO aber das cloud-Paket erledigen.

Apps2 hat er nicht selbst angelegt, also muß man dann auch nextcloud
vorher anlegen.
Es geht aber auch erstmal ohne apps2 wenn man erstmal keine zus. apps
braucht. Er meckert dann nur...

>
>> -> Datenbank anlegen mit user (s.u.) und dem fast alle Rechte geben
>> localer Zugriff
>
> Der in next/owncloud definierte Datenbankuser sollte aber vom cloud-Paket
> angelegt werden;

Da bin ich mir nicht so sicher ob das so geht.??
Ich mache das ohnehin lieber vorher selbst, ..

gemeint ist hier natürlich nicht der Root-User von
> mariadb, der muss beim konfigurieren von mariadb gesetzt werden.

ja natürlich! auf jeden Fall!!! sieht man ja auch in der conf

Was eventuell eine kleine Hürde darstellt, (ohne Doku) sind die
richtigen cache Einstellungen, dann verweigert er den Start.

Ulrich

[Marcus Roeckrath]

Hallo Ulrich,

Ulrich Hupe wrote:

>> Das sollte IMHO aber das cloud-Paket erledigen.
> Apps2 hat er nicht selbst angelegt, also muß man dann auch nextcloud
> vorher anlegen.
> Es geht aber auch erstmal ohne apps2 wenn man erstmal keine zus. apps
> braucht. Er meckert dann nur...

Ok, ich dachte das blockiert komplett.

>>> -> Datenbank anlegen mit user (s.u.) und dem fast alle Rechte geben
>>> localer Zugriff
>>
>> Der in next/owncloud definierte Datenbankuser sollte aber vom cloud-Paket
>> angelegt werden;
> Da bin ich mir nicht so sicher ob das so geht.??

Ist IMHO so vorgesehen.

> Ich mache das ohnehin lieber vorher selbst, ..

Das ist ja nicht verboten.

> Was eventuell eine kleine Hürde darstellt, (ohne Doku) sind die
> richtigen cache Einstellungen, dann verweigert er den Start.

Das könnte ja auch alles in einem Wiki-Artikel stehen.

--
Gruss Marcus

[Holger Bruenjes]

Hallo Ulrich

Am 16/05/2019 um 10.36 schrieb Ulrich Hupe:

Wenn der zugriff local ueber den socket erfolgen soll, sollte in
allen Anwendungen der selbe benutzt werden. Die Angabe von port und
host ist dann nicht erforderlich und wird auch nicht beachtet.


> PHP7CLI_EXT_MYSQL='yes'
> PHP7CLI_EXT_MYSQL_SOCKET='/run/mysql/mysql.sock'
^^^^^^^^^^^^^^^^

> PHP7CLI_EXT_MYSQL_HOST='192.168.66.3' (z.B.)
> PHP7CLI_EXT_MYSQL_PORT='3306'

> PHP7_EXT_MYSQL_SOCKET='/run/mysql/102/mysql.sock'
^^^^^^^^^^^^^^^^^^^^^^^^^^

> PHP7_EXT_MYSQL_HOST='192.168.66.3' (z.B.)
> PHP7_EXT_MYSQL_PORT='3306'

abgesehen davon ist es auch nur ein default fuer schlechte php
Anwendungen, die es nicht schaffen die Datenbankanbindung korrekt
vorzunehmen. Nextcloud und Owncloud beachten diese default
Einstellung nicht, dass behandeln sie selber korrekt in der
config.php siehe dadrin -> 'dbhost' .

Holger

[Juergen Edner]

Hallo Holger,

>> PHP7_EXT_MYSQL_SOCKET='/run/mysql/102/mysql.sock'
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> PHP7_EXT_MYSQL_HOST='192.168.66.3' (z.B.)
>> PHP7_EXT_MYSQL_PORT='3306'
>
> abgesehen davon ist es auch nur ein default fuer schlechte php
> Anwendungen, die es nicht schaffen die Datenbankanbindung korrekt
> vorzunehmen. Nextcloud und Owncloud beachten diese default
> Einstellung nicht, dass behandeln sie selber korrekt in der
> config.php siehe dadrin -> 'dbhost' .

die nextcloud-/owncloud-Pakete lesen die Pfadeinstellungen aus
den MySQL/MariaDB-Einstellungen aus und setzen die Parameter
entsprechend. Auf Wunsch kann ein Administrator diese aber auch
überschreiben ;-)

Gruß Jürgen
--
Mail: jue...@eisfair.org

[Kay Martinen]

Am 16.05.2019 um 11:26 schrieb Marcus Roeckrath:
> Hallo Ulrich,
>
> Ulrich Hupe wrote:
>
>> Apache sollte laufen, wenn Zugang über HTTPs dann auch cert.
>> cron
>> samba
>> MC
>> PHP7 installieren
>> Datenbank inst. wie MariaDB102 incl. phpmyadmin55
>> -> Kurzum, es sollte/muß ein funktionierender "LAMP" Server laufen.
>
> Das könnte Jürgen vielleicht in die Doku nochmal deutlich reinschreiben -
> die Grundlage muss laufen, dann kann man sich an next/owcloud begeben.

Hab ich gestern mit nextcloud 1.5.4 und apache2 laufend auf einem 32Bit
E1 noch mal versucht. Die Fehlermeldungen unterscheiden sich nicht zum
Test auf der 64bit VM und dem Virt-eisfair.

Mal sehen ob ich heute weiter komme. Ich hab den zuerst komplett
aktualisiert. Dann certs eingerichtet, dann apache, dann php7 geladen,
dann mariadb102 und erst dann nextcloud. Der wollte da nur noch 40
pakete nach laden. redis war nicht dabei!

>
> Das kann das next/owncloud-Paket nicht alles selbst, prüfen, konfigurieren,
> erahnen, ... denn manches ist ja sogar nach eigenem Gusto frei wählbar
> (DB-System; PHP-Variante).

Ja, und das ist eine Auswahl-alternative. Oder kann man ALLE datenbanken
parallel nutzen? Wer tut das?

Ich denke das konfigurieren unterscheidet sich je nach gewählter
Datenbank. Setup bildet das IMHO jedoch nicht ab.

>
>> Dann REDIS und php7-cli installieren
>
> usw.

Hier fehlt mir vor allem das verständnis wozu redis und das andere...
Wenn es nötig ist dann sollte es mit installiert werden.

>
>> -> dann die directories htdocs/nextcloud/apps2 anlegen
>
> Das sollte IMHO aber das cloud-Paket erledigen.

Tut es nicht. Ist ../nextcloud/apps2 ein Verzeichnis und /var/www/htdocs
oder effektiv ein alias des apache?

>> -> Datenbank anlegen mit user (s.u.) und dem fast alle Rechte geben
>> localer Zugriff
>
> Der in next/owncloud definierte Datenbankuser sollte aber vom cloud-Paket
> angelegt werden; gemeint ist hier natürlich nicht der Root-User von
> mariadb, der muss beim konfigurieren von mariadb gesetzt werden.
>

Der wird aber nicht angelegt. Selbst wenn man nicht mariadb nimmt, es
steht drin der default wäre "leer" aber das stimmt nicht. Den "nouser"
löschen geht ebenso wenig wie das passwort löschen. Und auch wenn man es
drin lässt und mariadb läuft wird der IMHO nicht angelegt.

[Juergen Edner]

Hallo Kay,

> Mal sehen ob ich heute weiter komme. Ich hab den zuerst komplett
> aktualisiert. Dann certs eingerichtet, dann apache, dann php7 geladen,
> dann mariadb102 und erst dann nextcloud. Der wollte da nur noch 40
> pakete nach laden. redis war nicht dabei!

dies ist seltsam, da im Paket die Anforderung 'php7-redis 1.1.3'
definiert ist, die wiederum ein installiertes redis-Paket erfordert.

Für eine optimale Performance sollte in den PHP-Einstellungen der
PHP-Pakete möglichst der Parameter PHP7*_EXT_CACHE='apcu+redis'
gesetzt werden. Wenn dies der Fall wird dies auch bei der Erstellung
der Konfiguration berücksichtigt.

> Ich denke das konfigurieren unterscheidet sich je nach gewählter
> Datenbank. Setup bildet das IMHO jedoch nicht ab.

Es gibt noch optionale Parameter im Paket, die bei Bedarf von den
Spezialisten gesetzt werden können, um die Datenbankauswahl beeinflussen
zu können ;-)

> Hier fehlt mir vor allem das verständnis wozu redis und das andere...
> Wenn es nötig ist dann sollte es mit installiert werden.

Wird es definitiv.

>>> -> dann die directories htdocs/nextcloud/apps2 anlegen
>>
>> Das sollte IMHO aber das cloud-Paket erledigen.

Wird es - zumindest prüfe ich an zwei verschiedenen Stellen die
Parameter und lege die Verzeichnisse an. Um hier im Detail etwas
prüfen zu können benötige ich jedoch DETAILLIERTE Informationen
wann eine Meldung wie, wo etc. angezeigt wird.

> Tut es nicht. Ist ../nextcloud/apps2 ein Verzeichnis und /var/www/htdocs
> oder effektiv ein alias des apache?

Diesen Satz verstehe ich leider nicht.

>>> -> Datenbank anlegen mit user (s.u.) und dem fast alle Rechte geben
>>> localer Zugriff
>>
>> Der in next/owncloud definierte Datenbankuser sollte aber vom cloud-Paket
>> angelegt werden; gemeint ist hier natürlich nicht der Root-User von
>> mariadb, der muss beim konfigurieren von mariadb gesetzt werden.
>
> Der wird aber nicht angelegt. Selbst wenn man nicht mariadb nimmt, es
> steht drin der default wäre "leer" aber das stimmt nicht. Den "nouser"
> löschen geht ebenso wenig wie das passwort löschen. Und auch wenn man es
> drin lässt und mariadb läuft wird der IMHO nicht angelegt.

Der von ownCloud-/Nextcloud benötigte Datenbank-User wird ebenfalls
angelegt. Um den User jedoch anlegen zu können ist einmal die Eingabe
eines Datenbank Admin-Accounts erforderlich.

[Marcus Roeckrath]

Hallo Kay,

Kay Martinen wrote:

> Ja, und das ist eine Auswahl-alternative. Oder kann man ALLE datenbanken
> parallel nutzen? Wer tut das?

Du kannst auf einem Server durchaus, mariadb, mysql, postgres, firebird und
sqlite parallel installieren, denn es gibt durchaus Anwendungen, die auf
einem bestimmten DB-System bestehen. Bei mysql/mariadb ist sogar eine
Parallelinstallation verschiedener Versionen möglich.

Und ungewöhnlich ist das auch nicht; ich habe in der Penne zwingend
firebird, mariadb und sqlite im Einsatz.

> Ich denke das konfigurieren unterscheidet sich je nach gewählter
> Datenbank. Setup bildet das IMHO jedoch nicht ab.

Wenn das für nextcloud gewünschte DB-System läuft, gibst du im
nextcloud-Setup eben dieses an. Dafür muss das aber fertig konfiguriert
sein.

--
Gruss Marcus

[Dirk Alberti]

Hallo zusammen,

was ich nicht verstehe:

Am 16.05.19 um 12:39 schrieb Ulrich Hupe:

>
>>
> Apps2 hat er nicht selbst angelegt, also muß man dann auch nextcloud
> vorher anlegen.
> Es geht aber auch erstmal ohne apps2 wenn man erstmal keine zus. apps
> braucht. Er meckert dann nur...

Wozu soll eigentlich dieses /apps2 gut sein? Beim "originalen"
Next-/Owncloud gibts den doch auch nicht und Apps werden ganz einfach
über die Weboberfläche gemanaged.  Oder wurde das für Eisfair rausgebastelt?


Gruß

Dirk

[Juergen Edner]

Hallo Dirk,

> Wozu soll eigentlich dieses /apps2 gut sein? Beim "originalen"
> Next-/Owncloud gibts den doch auch nicht und Apps werden ganz einfach
> über die Weboberfläche gemanaged.  Oder wurde das für Eisfair
> rausgebastelt?

dies ist nicht auf meinem Mist gewachsen. Gemäß den
ownCloud/Nextcloud-Installationsempfehlungen sollen in /apps nur die
Apps abgelegt werden die standardmäßig von der Software mitgebracht werden.
In einem weiteren Verzeichnis, z.B. /apps2, sollen dann alle weiteren
von den Anwendern installierte Anwendungen abgespeichert werden Auf
diese Weise wird eine saubere Trennung zwischen den mitgebrachten und
nachträglich installierten Apps sicher gestellt.

[Holger Bruenjes]

Hallo Juergen

Am 16/05/2019 um 14.11 schrieb Juergen Edner:

>> abgesehen davon ist es auch nur ein default fuer schlechte php
>> Anwendungen, die es nicht schaffen die Datenbankanbindung korrekt
>> vorzunehmen. Nextcloud und Owncloud beachten diese default
>> Einstellung nicht, dass behandeln sie selber korrekt in der
>> config.php siehe dadrin -> 'dbhost' .
>
> die nextcloud-/owncloud-Pakete lesen die Pfadeinstellungen aus
> den MySQL/MariaDB-Einstellungen aus und setzen die Parameter
> entsprechend. Auf Wunsch kann ein Administrator diese aber auch
> überschreiben ;-)

hmm, hatte ich doch geschrieben, dass das fuer nextcloud,owncluoud
keine Bewantniss hat, oder ist das wieder zu undeutlich ruebergekommen.

Holger

[Dirk Alberti]

Hallo Jürgen,

Am 16.05.19 um 17:56 schrieb Juergen Edner:

ach kuck an. Ich hatte nach "Nextcloud + apps2" gegoogelt, aber wohl zu
oberflächlich.

Wie Loddar sagen würde "Again what learned." und "Nothing for
un-good..."  ;-)   Danke für die Erleuchtung.

Gibts das mit apps2 schon lange in OC/NC, oder wurde das erst ziemlich
neu eingeführt?

> Gruß Jürgen
>

Gruß

Dirk

[Juergen Edner]

Hallo Dirk,

> ach kuck an. Ich hatte nach "Nextcloud + apps2" gegoogelt, aber wohl zu
> oberflächlich.
>
> Wie Loddar sagen würde "Again what learned." und "Nothing for
> un-good..."  ;-)   Danke für die Erleuchtung.
>
> Gibts das mit apps2 schon lange in OC/NC, oder wurde das erst ziemlich
> neu eingeführt?

die Unterstützung für ein separates /apps2-Verzeichnis habe ich
erst am 12. Dezember 2013 eingebaut ;-)

[Hilmar Böhm]

Hallo,

versuche gerade einen Nextcloud-Server auf Basis V1.7.1 und PHP-FPM neu aufzubauen.
MariaDB, Certs, Apache2, PHP7_CLI und PHP7-FPM (kein APACHE2_PHP7) sind konfiguriert.
Apache2 ohne VHOST, aber für https (Port 443) konf.

Was ungewöhnlich ist, dass die Konfiguration von PHP7-FPM(nach Abschluß des entspr.. Parameter-Dialogs sehr lange dauert:
Das gleiche (Zeit-)Problem zeigt sich auch beim Systemstart. Ich habe im "php7-fpm" Init-Script im "start)" bei loadproc die
Umleitung ins Null-Device entfernt. Da zeigt sich folgendes:

1. Fehlende libc-client
------------------------------------------------------------------------------------------
* Starting php7-fpm ...
/usr/sbin/php7-fpm: error while loading shared libraries: libc-client.so.2010: cannot open shared object file: No such file or
directory [ FAIL ]
...................................
------------------------------------------------------------------------------------------

Die Lib habe ich nachinstalliert. Das bringt:
------------------------------------------------------------------------------------------
* Starting php7-fpm ...
/usr/sbin/php7-fpm: error while loading shared libraries: libexslt.so.0: cannot open shared object file: No such file or
directory [
FAIL ]
...................................
------------------------------------------------------------------------------------------



Das bringt aber das nächste Problem: Eine fehlende libexslt. Ein Paket mit diesem Namen gibt es nicht. Habe deswegen "libxslt1"
installiert (mit den Abhängigkeiten: libgpg-error0 und libgcrypt20).
Jetzt kommt folgende Meldung bei start von /etc/init.d/php7-fpm:

------------------------------------------------------------------------------------------
* Starting php7-fpm ...
[18-May-2019 08:55:01] NOTICE: PHP message: PHP Warning: Cannot open '/etc/php7/apache2/browscap' for reading in Unknown on line 0
[18-May-2019 08:55:01] NOTICE: PHP message: PHP Fatal error: Directive 'register_globals' is no longer available in PHP in
Unknown on line 0

Fatal error: Directive 'register_globals' is no longer available in PHP in Unknown on line 0 [ FAIL ]
...................................

------------------------------------------------------------------------------------------

An dieser Stelle habe ich aufgegeben. Bei allen Versuchen wird php7_fpm nicht gestartet.

Fehlen da Requires? /etc/config.d/php7-fpm s.u.

Ich bitte um Hilfe. Gruß. / Hilmar.

--------------/etc/config.d/php7-fpm----------------------------------------------------------------------------------------

START_PHP7_FPM='yes'
PHP7FPM_MAX_EXECUTION_TIME='30'
PHP7FPM_DISPLAY_ERRORS='yes'
PHP7FPM_LOG_ERROR='yes'
PHP7FPM_REGISTER_GLOBALS='yes'
PHP7FPM_SENDMAIL_PATH=''
PHP7FPM_SENDMAIL_APP=''
PHP7FPM_DATE_TIMEZONE='Europe/Berlin'
PHP7FPM_DEFAULT_CHARSET='de_DE.UTF-8'
PHP7FPM_INFO='yes'
PHP7FPM_MAX_POST_SIZE='64M'
PHP7FPM_MAX_UPLOAD_FILESIZE='128M'
PHP7FPM_MEMORY_LIMIT='512M'
PHP7FPM_UPLOAD_DIR='/tmp'
PHP7FPM_EXT_CACHE='apcu+redis'
PHP7FPM_EXT_SOAP='no'
PHP7FPM_EXT_LDAP='no'
PHP7FPM_EXT_MYSQL='yes'
PHP7FPM_EXT_MYSQL_SOCKET='/run/mysql/mysql.sock'
PHP7FPM_EXT_MYSQL_HOST='localhost'
PHP7FPM_EXT_MYSQL_PORT='3306'
PHP7FPM_EXT_MSSQL='no'
PHP7FPM_EXT_PGSQL='no'
PHP7FPM_EXT_INTER='no'
PHP7FPM_EXT_SQLITE3='no'

------------------------------------------------------------------------------------------

[Holger Bruenjes]

Hallo Hilmar

Am 18/05/2019 um 09.20 schrieb Hilmar Böhm:

> ------------------------------------------------------------------------------------------
> * Starting php7-fpm ...
> [18-May-2019 08:55:01] NOTICE: PHP message: PHP Warning: Cannot open '/etc/php7/apache2/browscap' for reading in Unknown on line 0
> [18-May-2019 08:55:01] NOTICE: PHP message: PHP Fatal error: Directive 'register_globals' is no longer available in PHP in
> Unknown on line 0
>
> Fatal error: Directive 'register_globals' is no longer available in PHP in Unknown on line 0 [ FAIL ]
> ...................................
>
> ------------------------------------------------------------------------------------------
>
> An dieser Stelle habe ich aufgegeben. Bei allen Versuchen wird php7_fpm nicht gestartet.
>
> Fehlen da Requires? /etc/config.d/php7-fpm s.u.
>
> Ich bitte um Hilfe. Gruß. / Hilmar.
>
> --------------/etc/config.d/php7-fpm----------------------------------------------------------------------------------------
>
> START_PHP7_FPM='yes'
> PHP7FPM_MAX_EXECUTION_TIME='30'
> PHP7FPM_DISPLAY_ERRORS='yes'
> PHP7FPM_LOG_ERROR='yes'
> PHP7FPM_REGISTER_GLOBALS='yes'

^^^^^^^^^^^^^^
PHP7FPM_REGISTER_GLOBALS='no'


Holger

[Hilmar Böhm]

Hallo Holger,

Am 18.05.19 um 09:28 schrieb Holger Bruenjes:

>> PHP7FPM_REGISTER_GLOBALS='yes'
> ^^^^^^^^^^^^^^
> PHP7FPM_REGISTER_GLOBALS='no'
>
>
> Holger
>

Danke.
Habe ich gemacht: Gleiche Fehlermeldungen (die mit dem "browscap"). Habe libxslt1 und libc-client (nacheinander) wieder
deinstalliert. Dann kommen aber die gleichen Fehlermeldungen vorher, wie schon berichtet. Beides wieder installiert.

Neu ist die Meldung jetzt:
-----------------------------------------------------------------------------------------------------------------------
* Starting php7-fpm ...
[18-May-2019 10:06:12] NOTICE: PHP message: PHP Warning: Cannot open '/etc/php7/apache2/browscap' for reading in Unknown on line 0
[18-May-2019 10:06:12] WARNING: Nothing matches the include pattern '/etc/php7/fpm/*.conf' from /etc/php7/php7-fpm.conf at line
15. [ OK ]
-----------------------------------------------------------------------------------------------------------------------


/etc/php7/php7-fpm.conf enthält ein include auf /etc/php7/fpm/*.conf.. In /etc/php7/fpm/ gibt es aber keine .conf Dateien, auch
nicht im darunter liegenden conf.d/ Verzeichnis (dort nur .ini's).

Neu ist, dass PHP7-FPM jetzt gestartet wird. Allerdings wird der apache nicht gestartet:

-----------------------------------------------------------------------------------------------------------------------
Activate configuration now (y/n) [yes]?
Creating Apache2 configuration ...
activating modules...
done activating modules
* Restarting Apache ...
httpd not running, trying to start [ OK ]
-----------------------------------------------------------------------------------------------------------------------

Apache läuft NICHT.

Ideen? Danke und Grüße. / Hilmar.

[Holger Bruenjes]

Hallo Hilmar

Am 18/05/2019 um 10.28 schrieb Hilmar Böhm:

> deinstalliert. Dann kommen aber die gleichen Fehlermeldungen vorher, wie schon berichtet. Beides wieder installiert.
>
> Neu ist die Meldung jetzt:
> -----------------------------------------------------------------------------------------------------------------------
> * Starting php7-fpm ...
> [18-May-2019 10:06:12] NOTICE: PHP message: PHP Warning: Cannot open '/etc/php7/apache2/browscap' for reading in Unknown on line 0

Ja, kurios ;-)

es hilft im Moment nichts, Du musst auch apache2_php7 installieren,
weil die Datei in dem Paket steck. Aber nicht aktivieren.

Holger

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> * Restarting Apache ...
> httpd not running, trying to start
> [ OK ]

> Apache läuft NICHT.

Das gibt obige Meldung aber nicht her.

/etc/init.d/apache2 status

--
Gruss Marcus

[Holger Bruenjes]

Hallo Hilmar

Am 18/05/2019 um 10.28 schrieb Hilmar Böhm:
-----------------------------------------------------------------------------------------------------------------------
> Activate configuration now (y/n) [yes]?
> Creating Apache2 configuration ...
> activating modules...
> done activating modules
> * Restarting Apache ...
> httpd not running, trying to start [ OK ]
> -----------------------------------------------------------------------------------------------------------------------
>
> Apache läuft NICHT.
>
> Ideen? Danke und Grüße. / Hilmar.

hmm,

probier mal auf der cmd

/etc/init.d/apache2 start

oder dann

/usr/sbin/apachectl start

und gucken welche Meldungen geworfen werden.

Holger

[Marcus Roeckrath]

Hallo Holger,

Holger Bruenjes wrote:

>> httpd not running, trying to start
>> [ OK ]

>> Apache läuft NICHT.
>>
>> Ideen? Danke und Grüße. / Hilmar.
>
> hmm,

Die obige Meldung sagt doch garnicht, dass der Apache nicht läuft - eher das
Gegenteil, denn beim Restart wird versucht, den Apachen zu stoppen, was mit
"httpd not running" quittiert wird, das "trying to start" wird aber mit OK
gemeldet.

--
Gruss Marcus

[Hilmar Böhm]

Leute!
Wenn ich schreibe, dass der Apache nicht läuft, dann läuft er auch nicht. Und das habe ich natürlich mit "/etc/init.d/apache2
status" auch gecheckt!!!

>>> httpd not running, trying to start
>>> [ OK ]

Diese Meldung ist m.E. irreführend! Man sollte sie entweder weglassen oder anschließend einen (echten) Status ermitteln und den
ausgeben.

/usr/sbin/apachectl start ---> direkt Prompt, keine Meldung.
Status-Check danach: "Apache is not running"

---ps ax---Auszug!---------------------------------------------------------------
PID TTY STAT TIME COMMAND
...
...
3875 ? Ssl 0:07 /usr/sbin/redis-server 127.0.0.1:6379
3887 ? SNs 0:00 /usr/sbin/atd
3898 ? SNs 0:00 /usr/sbin/fcron
3931 ? S 0:00 /bin/sh /usr/lib/mysql/102/bin/mysqld_safe --defaults-file=/etc/mysql/my102.cnf
4096 ? Sl 0:05 /usr/lib/mysql/102/bin/mysqld --defaults-file=/etc/mysql/my102.cnf --basedir=/usr/lib/mysql/102
--datadir=/srv/mysql/102 --plugin-dir=/usr/lib/mysql/102/plugin --user=mysql --log-error=/var/log/mysqld/102/mysqld.log
--pid-file=/run/mysql/102/mysql.pid --socket=/run/mysql/102/mysql.sock --port=3306
4148 ? S< 0:00 [ipv6_addrconf]
4214 ? SNs 0:00 /usr/sbin/acpid
...
4328 ? SNs 0:00 php-fpm: master process (/etc/php7/php7-fpm.conf)
4329 ? SN 0:00 php-fpm: pool www
4330 ? SN 0:00 php-fpm: pool www
4903 tty1 R+ 0:00 ps ax
------------------------------------------------------------------------------------
Kein apache!

Auf apache2_php7 werde ich nicht zurück gehen. Ich habe ja bereits eine ("magic") lauffähige Version damit (VM) und will jetzt
eine Neuinstallation mit PHP7-FPM versuchen.

Danke und Grüße. / Hilmar.

Am 18.05.19 um 11:00 schrieb Marcus Roeckrath:

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Leute!
> Wenn ich schreibe, dass der Apache nicht läuft, dann läuft er auch nicht.
> Und das habe ich natürlich mit "/etc/init.d/apache2 status" auch
> gecheckt!!!

Und warum schreibst du dann nicht, wie du das geprüft hast?

> >>> httpd not running, trying to start
> >>> [ OK ]

Diese Zeile belegt deine Aussage nämlich nicht.

> Diese Meldung ist m.E. irreführend! Man sollte sie entweder weglassen oder
> anschließend einen (echten) Status ermitteln und den ausgeben.

Da hast du recht und ich suche schon, wo die überhaupt herkommt, denn mein
hiesiges Apache-Initskript hat die garnicht drin.

Welche Version vom Apache ist bei die installiert:

eisman query --installed apache2

mach mal ein

grep "trying to" /etc/init.d/apache2

> Auf apache2_php7 werde ich nicht zurück gehen. Ich habe ja bereits eine
> ("magic") lauffähige Version damit (VM) und will jetzt eine
> Neuinstallation mit PHP7-FPM versuchen.

Holger schrieb nicht, dass du auf apache2_php7 zurückgehen sollst, sondern
dass du das ohne Konfiguration oder Aktivierung installieren sollst, damit
die fehlende Datei auf System kommt.

Oder du wartest, bis Sebastian eine Lösung gefunden hat.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Hilmar,

Marcus Roeckrath wrote:

>> >>> httpd not running, trying to start

Die steckt im apache2-Binary selbst drin.

Schau mal in /var/www/log/error_log, ob da Fehler gemeldet werden, wenn du
versuchst den Apachen zu (re)starten.

Vielleicht in einer zweiten Konsole mal das Log mitlaufen lassen:

tail -f /var/www/log/error_log

--
Gruss Marcus

[Hilmar Böhm]

Hallo Marcus,

Am 18.05.19 um 13:01 schrieb Marcus Roeckrath:

> Welche Version vom Apache ist bei die installiert:
>
> eisman query --installed apache2
>
> mach mal ein
>
> grep "trying to" /etc/init.d/apache2

Nichts
Ich vermute eher, dass das aus einem PHP-Setup/Config-Script für Eisfair kommt


> ...sondern

> dass du das ohne Konfiguration oder Aktivierung installieren sollst, damit
> die fehlende Datei auf System kommt.

Das habe ich nicht verstanden?!

Da ist wahrscheinlich noch ein Fehler im apache Initscript:

Bei mir gibt "/usr/sbin/apachectl start" (auf Kommandozeile) und danach bei "echo $?" --> 1 aus.
Also Fehler!

Das stimmt auch im Initscript, wo "HTTPD start" eine 1 ausgibt (getestet mit einem "mecho")
Die Fehlerabfrage führt aber zur einer falschen "log_end_msg" die ein "[ OK ]" ausgibt, statt einer "[FAIL]".

Bitte checken!

Habe auch noch mal das Initscript und das config.d Script für aoache gecheck, ob da nicht irgenwelche Zeichen reingeraten sind
die die korrekte Ausführung behindern.

Also: PHP_FPM läuft, APACHE nicht

Gruß. / Hilmar.

[Hilmar Böhm]

Hallo Marcus,

unsere Beiträge haben sich gekreuzt.
Muss jetzt singen gehen (GP für morgen)

Bis heute Abend...
Gruß. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

>> Welche Version vom Apache ist bei die installiert:
>>
>> eisman query --installed apache2

?????

>> mach mal ein
>>
>> grep "trying to" /etc/init.d/apache2
> Nichts
> Ich vermute eher, dass das aus einem PHP-Setup/Config-Script für Eisfair
> kommt

Nein, aus dem apache-Binary.

>> ...sondern
>> dass du das ohne Konfiguration oder Aktivierung installieren sollst,
>> damit die fehlende Datei auf System kommt.
> Das habe ich nicht verstanden?!

Du hattest doch diese browsecap Meldung angemerkt, die wegen einer fehlenden
Datei erscheint, die also möglicherweise in php7-fpm fehlt, aber in
apache2_php7 enthalten ist.

Wenn du also das Paket apache2_php7 installierst, kommt diese Datei ins
System.

Du sollst aber apache2_php7 nicht aktivieren.

Nun klar.

> Da ist wahrscheinlich noch ein Fehler im apache Initscript:
>
> Bei mir gibt "/usr/sbin/apachectl start" (auf Kommandozeile) und danach
> bei "echo $?" --> 1 aus. Also Fehler!

Weil der Apache aus irgendeinem grunde nicht starten will.

Hast du übrigens bei der certs-Installation ein Serverzertifikat erzeugt?

Du schriebst, dass du im Apachen https aktiviert hast? Fehlt das Zertifikat,
startet der Apache nicht.

Bitte in die error-Logs des Apchen unter /var/www/log reinschauen, da gibt
es zwei - einmal normal und einmal für ssl.

> Das stimmt auch im Initscript, wo "HTTPD start" eine 1 ausgibt (getestet
> mit einem "mecho") Die Fehlerabfrage führt aber zur einer falschen
> "log_end_msg" die ein "[ OK ]" ausgibt, statt einer "[FAIL]".

Das ist ja inzwischen klar, aber das hilft dem Apachen auch nicht, dem ist
nämlich egal, was das Init-Skript ausgibt.

Aufgrund irgendeiner Fehlkonfiguration weigert sich der Apache.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> unsere Beiträge haben sich gekreuzt.
> Muss jetzt singen gehen (GP für morgen)

Du auch, komme gerade von der GP für morgen u. a. Bach "Jesu meine Freude"
oder wie es in 2007 eine Kirchengemeinde in Berlin vor unserem Konzert auf
einem Riesenplakat zwischen Bäume gehängt hatte:

"Jesu, mein Freunde" :-))))

Viel Spaß.

--
Gruss Marcus

[Hilmar Böhm]

Hallo Marcus,
vielen Dank für Deine Kommentare.



Am 18.05.19 um 19:18 schrieb Marcus Roeckrath:> Hast du übrigens bei der certs-Installation ein Serverzertifikat erzeugt?

>
> Du schriebst, dass du im Apachen https aktiviert hast? Fehlt das Zertifikat,
> startet der Apache nicht.
>
> Bitte in die error-Logs des Apchen unter /var/www/log reinschauen, da gibt
> es zwei - einmal normal und einmal für ssl.

Lass uns bitte erst mal die Certs-Dinge untersuchen, auf die anderen komme ich noch zurück.

Ich habe nach der certs Installation und Aktivierung folgenden gemacht:

1. Erzeugung einer CA (ca.key, ca.pem, ca.crt) mit der "Manage certificates"_Konfiguration (setup)

2. das "apache.pem" wird automatisch bei der ersten apache2-Konfig im setup erzeugt. Ich gehe davon aus, dass das dann auch
sofort nutzbar ist.
# ls /usr/local/ssl/certs/apache.pem
rwxrwxrwx 1 root root 43 May 17 01:42 /usr/local/ssl/certs/apache.pem -> /usr/local/ssl/certs/<FQDN-des-NCHosts>.pem

Beides das Server-Zertifikat und der Symbolik-Link darauf (apache.pem) wird von diesen konfig skript erzeugt. Ich gehe davon
aus, dass nichts weiter tun muss. Für was sollte diese Aktion sonst gut sein?...

Allerdings zeigt "/var/www/log/error_log.ssl" folgendes:
------------------------------------------------------------------------------------------------------------------------------
...
...

[Sat May 18 14:30:50.657989 2019] [ssl:emerg] [pid 32147:tid 140220035905408] SSL Library Error: error:140DC009:SSL
routines:use_certificate_chain_file:PEM lib
[Sat May 18 14:31:27.805272 2019] [ssl:emerg] [pid 32179:tid 140377830619008] AH02562: Failed to configure certificate
e64nc170.hiro.corp:443:0 (with chain), check /usr/local/ssl/certs/apache.pem
[Sat May 18 14:31:27.805302 2019] [ssl:emerg] [pid 32179:tid 140377830619008] SSL Library Error: error:0909006C:PEM
routines:get_name:no start line (Expecting: TRUSTED CERTIFICATE) -- Bad file contents or format - or even just a forgotten
SSLCertificateKeyFile?
[Sat May 18 14:31:27.805309 2019] [ssl:emerg] [pid 32179:tid 140377830619008] SSL Library Error: error:140DC009:SSL
routines:use_certificate_chain_file:PEM lib
------------------------------------------------------------------------------------------------------------------------------

Sind diese Meldungen relevant? Ich kann leider nichts damit anfangen. Was sollte ich tun?

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Hast du übrigens bei der
> certs-Installation ein Serverzertifikat erzeugt?
> >
> > Du schriebst, dass du im Apachen https aktiviert hast? Fehlt das
> > Zertifikat, startet der Apache nicht.
>

> Lass uns bitte erst mal die Certs-Dinge untersuchen, auf die anderen komme
> ich noch zurück.
>
> Ich habe nach der certs Installation und Aktivierung folgenden gemacht:
>
> 1. Erzeugung einer CA (ca.key, ca.pem, ca.crt) mit der "Manage
> certificates"_Konfiguration (setup)
>
> 2. das "apache.pem" wird automatisch bei der ersten apache2-Konfig im
> setup erzeugt. Ich gehe davon aus, dass das dann auch sofort nutzbar ist.
> # ls /usr/local/ssl/certs/apache.pem
> rwxrwxrwx 1 root root 43 May 17 01:42 /usr/local/ssl/certs/apache.pem ->
> /usr/local/ssl/certs/<FQDN-des-NCHosts>.pem

Das hat so die Apache2-Konfiguration gemacht?

Das wäre mir neu; IMHO legt das Apache-Paket ein apache.pem aber keinen Link
apache.pem auf ein anderes Zertifikat an.

Falls aber das Zertifikat, auf das verlinkt wird, ok ist, ist das auch egal.

Es wird allerdings seit einiger Zeit dazu geraten, auch das Serverzertifikat
über Manage certificates zu kreieren; in der Doku (HTML auf eisfair) ist
das mit Bilder genauestens beschrieben.

Bitte lass dir mal für das verlinkte Verzeichnis im certs-menu (Show
certificate related information) die chain und details anzeigen und poste
die Ausgaben hier.

> Beides das Server-Zertifikat und der Symbolik-Link darauf (apache.pem)
> wird von diesen konfig skript erzeugt.

Das hat so das Apache2-Paket angelegt?

> Allerdings zeigt "/var/www/log/error_log.ssl" folgendes:
>
------------------------------------------------------------------------------------------------------------------------------
> ...
> ...
>
> [Sat May 18 14:30:50.657989 2019] [ssl:emerg] [pid 32147:tid
> [140220035905408] SSL Library Error: error:140DC009:SSL
> routines:use_certificate_chain_file:PEM lib
> [Sat May 18 14:31:27.805272 2019] [ssl:emerg] [pid 32179:tid
> [140377830619008] AH02562: Failed to configure certificate
> e64nc170.hiro.corp:443:0 (with chain), check
> /usr/local/ssl/certs/apache.pem
> [Sat May 18 14:31:27.805302 2019] [ssl:emerg] [pid 32179:tid
> [140377830619008] SSL Library Error: error:0909006C:PEM
> routines:get_name:no start line (Expecting: TRUSTED CERTIFICATE) -- Bad
> file contents or format - or even just a forgotten SSLCertificateKeyFile?
> [Sat May 18 14:31:27.805309 2019] [ssl:emerg] [pid 32179:tid
> [140377830619008] SSL Library Error: error:140DC009:SSL
> routines:use_certificate_chain_file:PEM lib
>
------------------------------------------------------------------------------------------------------------------------------
>
> Sind diese Meldungen relevant? Ich kann leider nichts damit anfangen. Was
> sollte ich tun?

Ja, da irgendwas mit dem Zertifikat nicht stimmt, verweigert der Apachen den
Start!

--
Gruss Marcus

[Hilmar Böhm]

Am 18.05.19 um 19:20 schrieb Marcus Roeckrath:

> Du auch, komme gerade von der GP für morgen u. a. Bach "Jesu meine Freude"

Ich: Max Reger, Choralkantate "Meinen Jesum laß ich nicht", Melodie von Bach-Kantate bekannt,
aber zum (großen) Teil wahnsinnig verzwackte Harmonien (spätromantisch halt). Da kommt man sich manchmal wie in einem
komplizierten Eisfair-Config-Basch-Script vor... :-)
Sorry für das OT :)
Grüße. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Marcus Roeckrath wrote:

>> 2. das "apache.pem" wird automatisch bei der ersten apache2-Konfig im
>> setup erzeugt. Ich gehe davon aus, dass das dann auch sofort nutzbar ist.
>> # ls /usr/local/ssl/certs/apache.pem
>> rwxrwxrwx 1 root root 43 May 17 01:42 /usr/local/ssl/certs/apache.pem ->
>> /usr/local/ssl/certs/<FQDN-des-NCHosts>.pem
>
> Das hat so die Apache2-Konfiguration gemacht?
>
> Das wäre mir neu; IMHO legt das Apache-Paket ein apache.pem aber keinen
> Link apache.pem auf ein anderes Zertifikat an.

Habe mir das Apache-Konfigurationsskript angesehen; der fragt da wirklich
den Servernamen ab und erzeugt damit dann das Zertifikat.

--
Gruss Marcus

[Hilmar Böhm]

Hallo Marcus,

Am 18.05.19 um 22:49 schrieb Marcus Roeckrath:

>> Das wäre mir neu; IMHO legt das Apache-Paket ein apache.pem aber keinen
>> Link apache.pem auf ein anderes Zertifikat an.

> Habe mir das Apache-Konfigurationsskript angesehen; der fragt da wirklich
> den Servernamen ab und erzeugt damit dann das Zertifikat.

Siehste...
Die Frage ist aber, was daran falsch ist?

Als "Anleitung mit Bildern" habe ich nur das Wiki zur Erstellung ein exim.pem von Stefan Puschek gefunden.
Kannst Du mir bitte einen Pointer auf den von Dir gemeinten Wiki-Artikel geben.

[Hilmar Böhm]

Hallo Marcus,

Du schreibst:

> Bitte lass dir mal für das verlinkte Verzeichnis im certs-menu (Show
> certificate related information) die chain und details anzeigen und poste
> die Ausgaben hier.

Der Versuch, "apache.pem" (das von der apache2-Konfig erzeugte) mit "Show
certificate related information" anzeigen zu lassen schlug fehl, es konnte nicht geladen werden

--------------------------------------------------------------------------------------------------------------------------
Show certificate details


unable to load certificate
139920431855360:error:0909006C:PEM routines:get_name:no start line:crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
File '/usr/local/ssl/certs/apache.pem' has errors
---------------------------------------------------------------------------------------------------------------------------

Dann habe ich mir im certs Menü mit "manage certificates" CA und apache.pem geladen. Es wurden für apache.pem weitere
durchzuführende Schritte angezeigt ( [>] ), ab Step 12. Die habe ich der Reihe nach ausgeführt.

Danach konnte ich mir die Details von apache.pem mit "Show certificate related information" (ohne Fehler) anzeigen lassen.
Auch die Chain wurde einwandfrei ermittel und angezeigt.

Wenn ich jetzt versuche, mit "apachectl start" den Apachen zu starten, erhalte ich:

--------------------------------------------------------------------------------------------------------------------------
# apachectl start
AH00526: Syntax error on line 9 of /etc/apache2/apache2.conf:
Invalid command '\x1b[33m\x1b[40m\x1b[1mYou', perhaps misspelled or defined by a module not included in the server configuration
--------------------------------------------------------------------------------------------------------------------------

Wenn man sich die "apache.pem" durch die Apache2-Konfig erzeugen läßt, fehlt m.E- der Hinweis, dass noch weitere Certs-Steps
erforderlich sind.

Vielleicht weißt Du oder sonst wer, woher dieser AH00526-Fehler kommt und wie man ihn beheben kann.
Apache2 läugz nach dem "apachectl start" immer noch nicht. php7-fpm läuft (aber mit Fehlermeldung).

Nach Inst. von "apache2-php7" (nicht aktiviert) ist dieser Fehler weg:
==> "[18-May-2019 08:55:01] NOTICE: PHP message: PHP Warning: Cannot open '/etc/php7/apache2/browscap' for reading in Unknown
on line 0"

Beim /etc/init.d/php7-fpm, gibt es aber immer noch deisen Fehler:


--------------------------------------------------------------------------------------------------------------------------
* Starting php7-fpm ...
[19-May-2019 00:32:14] WARNING: Nothing matches the include pattern '/etc/php7/fpm/*.conf' from /etc/php7/php7-fpm.conf at line
15. [ OK ]
--------------------------------------------------------------------------------------------------------------------------
Es ist allerdings ein Warning -- apache2-fpm läuft.

Grüße. / Hilmar.

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Dann habe ich mir im certs Menü mit "manage certificates" CA und
> apache.pem geladen. Es wurden für apache.pem weitere durchzuführende
> Schritte angezeigt ( [>] ), ab Step 12. Die habe ich der Reihe nach
> ausgeführt.

Du hättest in diesem Menu besser das physikalische Zertifikat mit dem
Servernamen statt des Links nutzen sollen - mal sehen, ob dein Vorgehen
weitere Probleme verursacht.

> # apachectl start
> AH00526: Syntax error on line 9 of /etc/apache2/apache2.conf:
> Invalid command '\x1b[33m\x1b[40m\x1b[1mYou', perhaps misspelled or
> defined by a module not included in the server configuration

Was steht denn in Zeile 9?

> Wenn man sich die "apache.pem" durch die Apache2-Konfig erzeugen läßt,
> fehlt m.E- der Hinweis, dass noch weitere Certs-Steps erforderlich sind.

IMHO sollte diese Zertifikatserzeugung aus dem Apache-Paket komplett raus,
das ist Aufgabe des Certs-Paketes.

--
Gruss Marcus

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Als "Anleitung mit Bildern" habe ich nur das Wiki zur Erstellung ein
> exim.pem von Stefan Puschek gefunden. Kannst Du mir bitte einen Pointer
> auf den von Dir gemeinten Wiki-Artikel geben.

Nicht im Wiki, sondern in der PDF oder HTML Dokumentation zu eisfair im
Kapitel Certs.

--
Gruss Marcus