Re: bedingte Ausgabeumleitung
On 13.07.2018 08:23, Rene Terlecki wrote: > der Ansatz mit tee war vielversprechend, doch leider funktioniert er bei > mir nicht Autsch, bei mir auch nicht: rm non-empty-file.txt echo -e "1. Zeile\n2. Zeile" | xargs --no-run-if-empty tee non-empty-file.txt Die Datei wird zwar angelegt, ist aber leer. Typischer Fall von den Test für den Fall von dem ich weiß, dass er funktioniert, kann ich weglassen. > denke, dass tee keinen Input mehr hat, der angezeigt und in eine Datei > geschrieben werden kann Ja, es ist so wie Heiko in der anderen Antwort schrieb: xargs nimmt die in der Pipe ankommenden Daten als Argumente für das Kommando und damit ist der Input leer. Und es gibt kein Kommando, das seine Argumente in eine Datei schreibt, weil es dafür ja die Ausgabeumleitung gibt ... Also leider keine Lösung :-( -- Uwe
Re: Apache Virtual Host´s | Nextcloud
Probiers mal mit folgendem Setup: Config-Datei für den VirtualHost: `/etc/apache2/sites-available/cloud.example.com.conf` ``` ServerName cloud.example.com Redirect permanent / https://cloud.example.com/ ServerName cloud.example.com RequestHeader unset X-Forwarded-Proto RequestHeader set X-Forwarded-Proto https env=HTTPS ErrorLog /var/log/apache2/cloud.example.com/error.log CustomLog /var/log/apache2/cloud.example.com/access.log combined SSLEngine on SSLCertificateFile /etc/letsencrypt/live/cloud.example.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/cloud.example.com/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/cloud.example.com/chain.pem Header always set Strict-Transport-Security "max-age=15768000" DocumentRoot /var/www/cloud.example.com # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.25=1.1.0f=yes=modern # modern configuration, tweak to your needs SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off # OCSP Stapling, only in httpd 2.3.3 and later SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCacheshmcb:/var/run/ocsp(128000) ``` Da du vmtl eine andere Apache/openssl Version hast (sudo apachectl -v/sudo openssl version), kannste dir den unteren Teil unter dem Mozilla-Link selber generieren. Damit hast du alles konfiguriert, was du brauchst. Der erste VirtualHost ist für die Weiterleitung, der zweite kümmert sich um das eigentliche Hosten der Anwendung. `sudo a2enmod ssl` nicht vergessen. Das SSL-Zertifikat bekommst du von Letsencrypt, wie das geht, findest du auf https://certbot.eff.org Am Ende dann `sudo a2ensite cloud.example.com` und ab dafür… GM Am 2018-07-12 10:46, schrieb René: Hallo Liste, Ich hab mir auf einem Bananapi Pro mit SATA Platte Nextcloud installiert unter armbian - also einem Debian Derivat für raspberry & Co. So weit so gut - DynDNS Domäne ist auch angelegt - funktioniert auch - derzeit noch abgeschalten / nicht aktiviert (Sicherheit) Nextcloud funktioniert jetzt also im Heimnetz - derzeit noch mit http Zugriff statt https. Entsprechend (Tutorial) hab ich mir unter /etc/apache2/sites-enebled eine nextcloud.conf eingerichtet. Nextcloud [1] schreibt nun, dass für den HTTPS Zugriff eine virtual Host´s Datei angelegt werden soll. Das hab ich kapiert. Was ich nicht kapiere, ist, kann ich das ServerName cloud.nextcloud.com Redirect permanent / https://cloud.nextcloud.com/ und ServerName cloud.nextcloud.com Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" (entsprechend abgeändert) direkt in meinen bestehende nextcloud.conf reinschreiben ? Die sieht bisher so aus: Alias /nextcloud "/var/www/html/nextcloud/" Options +FollowSymlinks AllowOverride All Dav off SetEnv HOME /var/www/html/nextcloud SetEnv HTTP_HOME /var/www/html/nextcloud oder braucht es dazu eine weitere *.conf, die dann enabled werden muss ? Danke ! Links: -- [1] https://docs.nextcloud.com/server/13/admin_manual/configuration_server/harden_server.html signature.asc Description: OpenPGP digital signature
Re: bedingte Ausgabeumleitung
Uwe Koloska (Do 12 Jul 2018 23:38:09 CEST): > Aber damit fehlt dir doch nur noch ein Baustein: Was könnte xargs > *nicht* starten, wenn der Eingang der Pipe keinen Input liefert. > > Und da wären wir bei einer schicken Lösung für beide Probleme, denn die > Datei wird weder überschrieben noch angelegt: > > echo "non empty file" > non-empty-file.txt > echo "" | xargs --no-run-if-empty tee non-empty-file.txt Ja, das dachte ich auch, ABER, wenn jetzt aus der Pipe Daten kommen, dann entstehen Kommandozeilen der Art tee non-empty-file.txt ZEILE1 ZEILE2 ZEILE3 tee non-empty-file.txt ZEILE4 ZEILE5 ZEILE6 Das macht nicht, was er braucht, er möchte die Zeilen ja dann in sein File haben. -- Heiko signature.asc Description: PGP signature
Re: Hilfe mit Gesetzt: löschen der E-Mails
Zitat von Jochen Topf : Hallo Wenn die Ressourcen des Servers nicht ausreichen, soll die E-Mail temporär (Fehler-Code 4xx) abgelehnt werden. Das ist explizit im SMTP-Protokoll vorgesehen... Wie gesagt, das sollte man so machen in einer idealen Welt. Realität ist aber, dass man manchmal E-Mails in eine Queue schicken muss, die man dann nacheinander abarbeitet (also ihren Inhalt auf Spam/Viren checkt). Hält man die Verbindung zum Absendeserver so lange offen, blockiert man den, das will man auch nicht unbedingt (oder schlimmer: der macht irgendwann einen Timeout und probiert es erneut). Benutzt man 4xx codes, dann hat man keine Kontrolle darüber, wann der Absender es nochmal versucht, man Man soll (und darf!) keine Kontrolle auf dem Absendersystem haben. Hauptsache wird die E-Mail richtig behandelt und dann wenn die E-Mail nicht ankommt wird mindestens eine Seite (der Absender) darüber informiert. Ohne weitere Aufwände... kann also nicht effektiv Lastspitzen verteilen. In der Praxis ist das E-Mail-System halt mehr als nur das SMTP-Protokoll. Naja, solange das SMTP-Protokoll für die E-Mail benutzt wird, soll dieser auch richtig implementiert werden, nicht wahr? ;) Ein Bounce wird vom ABSENDER-Server generiert. Der Empfängerserver gibt nur ein 5xx-Fehler und lehnt die E-Mail ab. Der Absenderserver (bei dem der Absender sich eingeloggt hat) generiert den Bounce. So sollte es sein in einem idealen System. Aber es kann halt gut sein, dass z.B. ein Firmengateway eine Mail annimmt und dann intern weiterschickt. Wenn dann das interne Mailsystem die Mail nicht annimmt, dann muss das Gateway den Bounce erzeugen. FALSCH! Der Bounce wird vom ABSENDER-System generiert! Der Empfänger lehnt nur die E-Mail ab! Und wenn mehrere Systemen zusammen "verkettet" sind, soll natürlich die Virusprüfung gleich am Anfang gemacht werden, so dass Virus-E-Mail gar nicht "intern" kommen. Das ist wirklich der normale E-Mail-Fluss seit über 30 Jahre... So einfach ist das weltweite E-Mail-System und auch unser Rechtssystem halt nicht. Juristisch glaube ich nicht, dass da was zu holen ist. Vielleicht wäre ein freundlicher Vorschlag besser, dass sie ihre AGBs anpassen sollen oder in Erwägung ziehen, ihre Policy zu ändern. Ich glaube, ich muss mit dem Anwalt der Firma sprechen... Hier wurden wichtige Geschäfts-E-Mail spurlos vernichtet, das kann wirklich nicht akzeptiert werden. Und natürlich kennen wir nur 3 konkrete Fälle vom gestern, wissen aber natürlich nicht, wie oft noch das passiert ist... Grüße Luca Bertoncello (lucab...@lucabert.de)
Re: Hilfe mit Gesetzt: löschen der E-Mails
Zitat von Jochen Topf : Hallo Jochen, In einer idealen Welt bekommt ein Mailserver eine Mail angeboten, checkt sie sofort und entscheidet dann, ob er sie zustellen will oder ablehnen. Aber die Welt ist nicht ideal und es gibt genug Gründe, warum man manchmal eine Mail annehmen muss, die man eigentlich lieber nicht angenommen hätte. Z.B. weil man so kurzfristig die Ressourcen nicht hat, um eine Virenprüfung durchzuführen oder weil man einen wilden Verhau von vielen Mailservern hat, die die Mails weiterleiten. Wenn die Ressourcen des Servers nicht ausreichen, soll die E-Mail temporär (Fehler-Code 4xx) abgelehnt werden. Das ist explizit im SMTP-Protokoll vorgesehen... Und dann hat man also eine Mail angenommen und nachträglich festgestellt, dass sie "schlecht" ist in der einen oder anderen Form. Dann steht man halt vor der Wahl: Lasse ich die Mail leise verschwinden, stelle ich sie in einen Spam-Ordner zu oder erzeuge ich einen Bounce, schicke die Mail also zurück. Was man dann macht hängt sinnvollerweise davon ab, was denn das Problem mit der Mail ist. Viren will man auf keinen Fall in einen Spam-Ordner ausliefern, weil User dann halt trotzdem draufklicken. Spam schon eher, weil es ja sein kann, dass man das falsch klassifiziert hat. Bouncen will man eher nicht, weil der Mailabsender gefälscht sein kann und man dann das Problem noch schlimmer macht, in dem man die Mail an einen Unschuldigen "zurück" liefert. Das ist also eine Abwägung, die man da vornehmen muss, was das geringste Übel ist. Und da würde ich durchaus sagen, dass ein erkannter Virus das Löschen der Mail rechtfertigt. Ein Bounce wird vom ABSENDER-Server generiert. Der Empfängerserver gibt nur ein 5xx-Fehler und lehnt die E-Mail ab. Der Absenderserver (bei dem der Absender sich eingeloggt hat) generiert den Bounce. Im Falle von Virus, wenn kein richtiger Server die E-Mail geschickt hat, wird der Bounce nicht generiert und Schluss, aber wenn jemand aus Versehen ein Virus schickt (bzw. seine E-Mail wird fälschlicherweise als Virus erkannt) kann er problemlos ein Bounce kriegen, ohne dass der Server des Empfängers was anderes macht, als die E-Mail abzulehnen. Das ist alles ganz explizit und detailliert in dem SMTP-Protokoll vorgesehen. Im diesen Sinne, kann ich mit deiner Analyse überhaupt nicht einverstanden sein. Leider brauche ich ein Paragraph vom Gesetz, damit ich mich beim Provider beschweren kann. Seine AGB habe ich heute nochmal gelesen und sie schreiben, dass sie E-Mail __ABLEHNEN__ oder in die Quarantäne schieben, wenn man diesen Dienst explizit aktiviert (nicht der Fall). Sowohl der Provider als auch unsere Tochterfirma unterliegen dem deutschen Recht (der Provider ist bei Mainz und die Tochterfirma in Hamburg). Grüße Luca Bertoncello (lucab...@lucabert.de)
Re: bedingte Ausgabeumleitung
Am 12.07.2018 um 23:38 schrieb Uwe Koloska: Du hast zwar bereits deine Anforderung um 180° umgedreht und aus "Die Datei soll nicht geschrieben werden, wenn es keinen Input gibt" zu "Die bestehende Datei soll nicht überschrieben werden, wenn es keinen Input gibt", aber der folgende Ansatz liefert doch eine interessante Lösung für beide Problemstellungen. Am 12.07.2018 um 16:29 schrieb Rene Terlecki: allerdings habe ich auch schon folgenden Ansatz versucht . | xargs --no-run-if-empty --null > file Heiko hat ja schon darauf hingewiesen, dass Die Datei trotzdem zum Schreiben geöffnet und daher geleert wird, bevor überhaupt irgendein Prozess der Pipe läuft. echo "non empty file" > non-empty-file.txt echo "" | xargs --no-run-if-empty > non-empty-file.txt Aber damit fehlt dir doch nur noch ein Baustein: Was könnte xargs *nicht* starten, wenn der Eingang der Pipe keinen Input liefert. Und da wären wir bei einer schicken Lösung für beide Probleme, denn die Datei wird weder überschrieben noch angelegt: echo "non empty file" > non-empty-file.txt echo "" | xargs --no-run-if-empty tee non-empty-file.txt Hallo, der Ansatz mit tee war vielversprechend, doch leider funktioniert er bei mir nicht denke, dass tee keinen Input mehr hat, der angezeigt und in eine Datei geschrieben werden kann Danke Rene
