Beiträge von marinal

Guten Abend,

bei einem unserer Kunden schlägt immer die Installation von ownCloud fehl:

• Detected 'Debian GNU/Linux 7.11 (wheezy)'
• PHP 5.6.36 (code='php56', bin='/opt/php-5.6/bin/php-cgi', SAPI=CGI/FastCGI)
• PHP 7.0.30 (code='php70', bin='/opt/php-7.0/bin/php-cgi', SAPI=CGI/FastCGI)
• PHP 7.1.19 (code='php71', bin='/opt/php-7.1/bin/php-cgi', SAPI=CGI/FastCGI)
• PHP 5.5.38 [DEFAULT] (code='php5', bin='/usr/bin/php-cgi', SAPI=CGI/FastCGI)

Bei der Subdomain ist PHP7.0 zugewiesen. Die Logs zeigen folgendes:

Zitat

=== Fri, 17 Aug 2018 22:36:48 +0200 - wai-owncloud-10.0.9-1.php (install) ===
This version of ownCloud requires at least PHP 5.6.0
You are currently running PHP 5.5.38-1~dotdeb+7.1. Please update your PHP version.

Die custom.lua wurden die PHP-Einträge deaktiviert. Apache neu gestartet, Subdomain mehrmals verifiziert, damit die Dateien neu geschrieben werden.

Laut App-installationsdatei ist nur PHP5.3 notwendig. Wo ist der Fehler? Muss das Installationsskript von PHP5.6 ausgeführt werden?

Wer hat noch eine Idee?

Vielen Dank im Voraus.

Update lief problemlos durch; Verträge deaktivieren zu können ist top.
Ein Mehrwert wäre noch die Deaktivierung zu einem gewissen Datum.

Hallo zusammen,

ich habe auch gestern schon festgestellt, dass der Fehler das "Score"-Ergebnis nicht wirklich fett macht. Und das mit der Remote-Adresse kann man auch aus Ihrer Sicht, Herr Keppler, sehen und macht auch Sinn. Da hatte ich wohl einen Gedankenwurm drin.

Ich wünsche allen einen guten Rutsch!! (bitte nicht zu wörtlich nehmen).

Guten Morgen,
da habe ich wohl die Mail gestern zu spät getippt. Sollte Clamav heißen und ich habe bereits meinen Post berichtigt.
Ja, die Zeile sieht in etwa so aus wie bei Dir. Es geht mir um folgenden Teil:
"[...] rhost=localhost,raddr=127.0.0.1 [...]"

Hallo zusammen,

mir ist gerade wegen einer Kundenanfrage aufgefallen, dass der Spamassassin immer localhost als Remote-Adresse bekommt.

Folgende Infrastruktur:
- Liveconfig-Server u.a. mit Webhosting
- Mialserver mit Clamav und Spamassassin (lcsam)
Beide Systeme laufen mit Debian.
Alle Mails, welche beim Mailserver ankommen und bei denen der Kunde Spamerkennung aktiviert hat, werden im System mit der RemoteAdress "127.0.0.1" verarbeitet. Deswegen befindet sich sehr oft das Attribut "URIBL_BLOCKED" im Ergebnis.

Kann hier eventuell jemand von Keppler sagen, ob das ein Bug oder ein Feature ist?

Danke und schönen Abend

Alexander

Ich hatte mich verschrieben, ein umask(0022) brachte nicht den gewünschten Erfolg. Die in "media/tmp/ hochgeladenen Dateien sind weiterhin 0640.

Guten Tag,

ich habe heute festgestellt, dass egal, was ich mache, der "Sekundärer DNS #4" wird nicht angenommen. Man speichert, es heißt "DNS-Vorlage erfolgreich aktualisiert" und wenn ich wieder auf die Vorlage gehe, ist wieder kein 4. sekundärer DNS zugewiesen. Egal, wie oft ich dies durchführe und egal, ob es sich um eine neue oder bereits vorhandene Vorlage handelt.

Verwendet:
Debian 8.3 mit bind 1:9.9.5

Kann dies jemand bestätigen?

Hallo,

danke für die schnelle Antwort. Aber es geht um keine einmalige Vergabe von Berechtigungen. Die Berechtigungen für die Verzeichnisse und Dateien sind alle korrekt vergegeben. Nur Magento selbst erstellt z.B. beim Upload von Bildern noch Verzeichnisse und Dateien und für die passen die Berechtigungen nicht. Wobei das für mich auch nicht wirklich schlüssig ist, da sowohl fcgi als auch Magento selbst eine umask von 022 vorgegeben hat. Und trotzdem sind die Berechtigungen 0750.

Von welcher Korrektur im Config-File sprichst Du?

Viele Grüße

Hallo zusammen,

ich kämpfe gerade mit einem seltsamen Phänomen. Ich verwende bei einem Kunden PHP mit FastCGi und Liveconfig 2.1.0.
Der Kunde hat Magento im Einsatz und Magento auf den Server migiert. Bei FastCGI ist eine umask von 022 eingetragen, bei Magento in der index.php auch eine umask von 022. Angelegt werden jedoch alle Verzeichnisse mit 0750 und die Dateien mit 0640. Hat irgendjemand einen Tip, woher das kommen kann?

Das Verhalten ist bei einem neu installierten Magento absolut identisch.

Vielen Dank schon im Voraus.

Die Änderungen klingen sehr gut und auf diese habe ich schon sehnsüchtig gewartet. Vielen Dank schon mal im Voraus!!

Wahrscheinlich stehe ich gerade vollkommen auf dem Schlauch.
Bisher hatte ich immer auf jeden Server Mail-, Web- und Datenbankserver am Laufen. Wegen mehrerer Gründe möchte ich aber zukünftig einen Mailserver für alle verwenden und dazu jeweils einen kombinierten Web- und Datenbankserver.
Nun meine Frage:
Wie kann ich den aktuell lokal laufenden Mailserver "exportieren" Also wie sage ich beim Server a, dass zukünftig Server b für die Mails zuständig ist? Wie ich das per DNS erledige, ist mir klar, aber es muss ja auch noch irgendwie die Konfiguration der Postfächer auf Server b kommen.

Viele Dank für jeden Gedankenanstoß.

Wie siehst Du, ob der Server läuft?
Was sagt netstat?
Bekommst Du mit einem Paketsniffer auf dem Server die Verbindungsversuche Deines FTP-Clients?
Läuft eine Firewall?

Mit mir spricht Dein FTP-Server übrigens:
telnet 213.133.103.238 21
Trying 213.133.103.238...
Connected to 213.133.103.238.
Escape character is '^]'.
220 213.133.103.238 FTP server ready

Quota aus fstab rausnehmen, neu starten, quota auf allen Laufwerken stoppen, Datei auf /var/www löschen und alles nochmals durchspielen. Besteht dann der Fehler immer noch?

Na ja, man kann auch varchar auf mehr als 255 Zeichen setzen, ohne gleich auf text gehen zu müssen.

Nach einem quotacheck -f (ohne Fehler) und dem aktivieren mit Quotaon kommt immer noch der Fehler? Funktioniert ein "repquota -agv"?

Zitat von informant

Naja, wie gibst du -f in der fstab mit. manuell aufrufen mit -f geht, aber es muss ja auch automatisch klappen und bei Systemstart.

Ich bin fast dazu geneigt, jetzt zu schreiben ... Du musst "-f" mit einen spitzen Messer in Deinen Bildschirm einritzen, damit es funktioniert ...

quotacheck -fvgm /var/www

Ich persönlich würde quotacheck mit -f laufen lassen. Ich hatte bisher dabei noch nie ein Problem. Oder die Quota-Optionen aus der fstab entfernen und neu starten. Danach die quota beenden, die Datei löschen und das ganze nochmals von vorne aufziehen. Sollte auch keine Probleme verursachen.

Ja, die wird eingesetzt:
Version: 1.9.1
Platform: x86_64-unknown-linux-gnu
Revision: 3767

Und ja, sie haben mit den 255 Zeichen recht ... ich war einen Moment sprachlos ... Änderungen sind hier nicht geplant.

- bei einem 2048-Bit-Schlüssel kann er über die gewöhnlichen Mechanismen nicht abgerufen werden (der Schlüssel ist jedoch meines Erachtens in der ".db.jnl"-Datei
- in der '*.db'-Datei ist weder der 1024- noch der 2048-Bit-Schlüssel enthalten
- das 2048-Bit-Problem wurde schon in einem anderen Thread angemerkt (ich glaube zum Release von 1.9.1)

Beispieldomains wg. OpenDKIM gibt es per DN

So, ich konnte weiter verifizieren. Es gibt Probleme, wenn der OpenDKIM-Key 2048 Bit hat. 1024-Bit-Keys werden ohne Probleme verarbeitet.

@Liveconfig-Team: Gibt es zu dem 2048-Bit-OpenDKIM-Problem schon einen Lösungsansatz?