Posts by fuerni

Quote from KB19

Gerüchten zufolge ist das tatsächlich eher eine Sache aus Ostösterreich. Im Westen dürfte es seltener der Fall sein.

Also laut österreichischem Wörterbuch gibt es die Schreibweise mit Fugen-S nicht. Korrekt wäre somit in ganz Österreich nur „Adventkalender“. Zumindest in der Steiermark ist auch in der Umgangssprache kein Fugen-S zu hören.

Der Duden bezeichnet den Gebrauch als österreichisch: https://www.duden.de/rechtschreibung/Adventkalender

oewb_adventkalender.jpg

Eine wirkliche Regel, wann ein Fugenlaut zum Einsatz kommen soll, gibt es aber anscheinend nicht. ?‍♂️
Mehr dazu auf Wikipedia: https://de.wikipedia.org/wiki/Fugenlaut

Coole Idee.
Für den ersten Polizeieinsatz brauchte ich einen Hinweis. Kam nicht auf die Idee, diesen Namen einzugeben. Vielleicht hab ich aber auch einfach zu schnell aufgegeben. Der Rest ging dann innerhalb weniger Minuten, aber vielleicht auch, weil ich bereits alles genau durchgelesen hatte.

Ein kleiner Tippfehler ist mir aufgefallen in gps.php, da fehlt ein Buchstabe bei für: "Wir haben leider eine schlechte Nachricht fü Euch."

Die Großschreibung von "Euch" usw. finde ich auch nicht mehr wirklich zeitgemäß.

Und noch einer /hannah/ beim Klick auf den Gratis-Button: "nachträglichen Kauf eine Codes freuen", da fehlt das s bei "eines"

Chat und Blog sind vom Design her sehr schön gestaltet. Beim Spiel-Interface fehlen mir teilweise Abstände und es ist etwas zu sehr Standard-Bootstrap. Da könnte man also noch etwas Kreativität einfließen lassen.

Und eventuell beim Chat noch echte Unicode-Emojis. ?

Quote from mainziman

hat jemand eine Ahnung, ob der Teil, den ich beim Englischen rot eingerahmt habe, hier tatsächlich etwas ist,

das man einfach nur im Englischen Win10 hat, oder hab ich irgendwas übersehen, dass man das abdrehen kann?

Also bei meinen drei deutschen Win 10 2004 Installationen fehlt der "Help from the web" Teil auch. Englische habe ich aktuell keine.

Seltsam das ganze. Eventuell gibt es die verlinkten Webseiten nur auf Englisch? Könntest ja mal anklicken und dir die Seiten ansehen, ob man da die Sprache ändern kann.

Wenn deine externen Clients eine statische öffentliche IP-Adresse haben, spricht im Prinzip nichts dagegen, dass du den Zugriff direkt erlaubst. Aber Achtung: Es erfolgt keine weitere Authentifizierung, freigegebene IP-Adressen haben vollen Zugriff auf deinen Storage-Space.

Welches Anwendungsszenario möchtest du mit der Freigabe für deinen PC abdecken? Nur lesender Zugriff? Oder lesend und schreibend? Möglichkeiten gäbe es viele: Webdav, SFTP, FTPS, Nextcloud, SMB via VPN ... Je nach Anwendungsszenario eben.

Allerdings musst du bedenken, dass der Storage-Space externer Speicher für deinen Server ist und mit der Performance von einer lokalen SSD nicht mithalten kann. Sofern dir also 320 GB reichen, würde ich dir einfach ein Upgrade auf einen VPS 2000 G9 empfehlen. Mehr Performance zum gleichen/ähnlichen Preis, und weniger zu konfigurieren.

Quote from ASS

Ein kleinet Tipp: Bevor du zuviel auf den Server lädtst, setze ihn als Erstes mit Debian 10 neu auf!

Gut gemeint, nur leider unterstützt Plesk Debian 10 noch nicht.

Siehe https://docs.plesk.com/release…an/software-requirements/

Quote from H6G

Das Interface ist Übersichtlicher und hat auch weniger Bugs.

Das Interface ist nicht nur übersichtlicher sondern auch durchgehend responsive.

Weiters kommen monatlich stabile Updates heraus.

Danke für eure Bemühungen - besonders an False fürs testen.

Seltsamerweise funktioniert es heute problemlos. Ohne reboot, ohne sonst etwas geändert zu haben...

Obwohl es mich brennend interessieren würde, was das war - schade um die Zeit. Ich freu mich, dass es jetzt geht.

Hallo liebe Netcup-Community,

ich war gerade dabei ein Issue bei Mailcow-Dockerized zu erstellen, da die UI hängen blieb, wenn man beim Ändern des Passwortes eines nimmt, welches ein = enthält.

Nun musste ich leider feststellen, dass es bei direktem Zugriff auf den Mailcow-nginx problemlos funktioniert. Versuche ich es aber über den Apache Reverse Proxy, liefert der Mailcow-nginx auf den API-POST-Request einen 404-Fehler.

Habt ihr vielleicht eine Idee, woran das liegen könnte?

Ich verwende eine Apache VHost Config wie in https://mailcow.github.io/mail…/firststeps-rp/#apache-24 empfohlen.

Die UI sendet einen POST-Request mit einem typischen GET-Query-String als Body, wobei der relevante attr-Parameter ein (URL-encoded) JSON enthält.
Und dieser Request wird vom Mailcow nginx mit 404 beantwortet, wenn die Anfrage durch den Apache (v2.4.38-3, Debian Buster) geht - sie kommt nicht in der verantwortlichen PHP-Datei an.

Was läuft hier falsch?

Quote from geekmonkey

Aber ist leider immer noch nicht standalone.

Ich hatte https://github.com/kiswa/TaskBoard im Einsatz;
werde aber wohl auch zu SOGo oder Nextcloud Tasks wechseln, da es gesynct werden kann.

Danke für eure Rückmeldungen.

Quote from alhazred

Es gibt im ISP Forum eine Anleitung für den Umstieg auf rspamd.

Hast du dazu vllt. einen Link?

Habe bis jetzt nur https://forum.howtoforge.de/th…mavis-spamassassin.10821/ gefunden, schaut nicht ganz nach "Anleitung" aus.

Hast du rspamd mit ISPConfig selbst im Einsatz? Läuft das, auch in Verbindung mit DKIM?

Hallo Mikebazz,

wenn der Netzwerk-Adapter nicht erscheint, solltest du im Geräte-Manager unter "Andere Geräte" ein Gerät haben mit einem gelben Dreieck mit Rufzeichen.

Dafür kannst du dann per Rechtsklick die Treiber installieren.

Falls die von Netcup zur Verfügung gestellte DVD nicht die erforderlichen Treiber enthält, kannst du diese auch bei Fedora herunterladen: https://docs.fedoraproject.org…rtio-win-direct-downloads

Sollte die "Stable virtio-win iso" nicht funktionieren, kannst du es noch mit der Latest versuchen.

Die DVD kannst du auch direkt unter Windows laden und mounten/entpacken - musst du nicht über das SCP machen.

Im Unterordner NetKVM findest du für diverse Windows-Versionen die notwendigen Netzwerktreiber.

Viel Erfolg,

Fürni

Liebe Community,

ich betreibe seit einigen Jahren einen eigenen Mailserver, bisher auf Basis von ISPConfig (Postfix, Dovecot, Spamassasin, Postgrey).

Bei den normalen Postfächern habe ich kaum Spam, aber in Postfächern, deren E-Mail-Adresse im Internet steht (Homepage, Firmenverzeichnisse etc.) kommt täglich Spam herein, den der Spamfilter nicht erkennt. Meist handelt es sich um die Themen Erotik, Medikamente, Kredit/Darlehen und Bitcoin.

Folgende Einstellungen habe ich in ISPConfig getroffen, trotzdem kommt der genannte Spam fast täglich durch.

• Greylisting aktiviert
• Spamfilter Richtlinie "Normal"
• Realtime Blackhole Listen:
  • ix.dnsbl.manitu.net
  • cbl.abuseat.org
  • bl.spamcop.net
  • zen.spamhaus.org
  • b.barracudacentral.org

Nun habe ich im Forum öfter von Mailcow gelesen, und da ich gerade den Server umziehe, bin ich am überlegen, ob ich nicht statt der in ISPConfig verwalteten Maildienste auf Mailcow setze.

Was habt ihr für Erfahrungen? Bekommt man mit Mailcow Spam besser in Griff? Oder gehört mein Postfix/ISPConfig nur besser konfiguriert?

Oder klappt das bei öffentlichen Adressen sowieso nicht und ich bräuchte kommerziellen Spamschutz?

Bitte um eure Meinung - Danke schon mal!

Hat jemand Erfahrung mit frischen Debian-stable-Versionen bzw. mit Buster?

Ich hab eine Empfehlung gelesen, dass man ein halbes Jahr mit der Installation warten sollte - aber irgendwie glaube ich das nicht ganz.

Ich möchte im Juli/August einen neuen Server einrichten (Web, Mail, MySQL, Docker) mit ISPConfig.

Sollte ich da gleich auf Buster setzen oder sind da einige Kinderkrankheiten zu erwarten, und deshalb besser noch Stretch?

Mein aktueller Server wird nämlich Ende August gekündigt.

Danke für die schnelle Hilfe vmk.

fsck sagt "clean". Dann werd ichs mal beim Support versuchen.

Hallo,

mein RS 1000 SAS G7SE läuft seit fast 2 Jahren problemlos. Seit Anfang Juni meldet mir mein Monitoring allerdings alle paar Tage ein HTTPS-Timeouts auf eine PHP-Website mit lokaler Datenbankanbindung.

Im Kernel-Log finde ich zu diesem Zeitpunkt folgendes:

Jun 10 14:13:37 kaiser kernel: [306917.576563] INFO: task jbd2/sda4-8:701 blocked for more than 120 seconds.
Jun 10 14:13:37 kaiser kernel: [306917.576775]       Not tainted 4.9.0-9-amd64 #1 Debian 4.9.168-1+deb9u2
Jun 10 14:13:37 kaiser kernel: [306917.576925] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 10 14:13:37 kaiser kernel: [306917.577056] jbd2/sda4-8     D    0   701      2 0x00000000
Jun 10 14:13:37 kaiser kernel: [306917.577061]  ffff9847340e9c00 0000000000000000 ffff9847334cf000 ffff98473fd18980
Jun 10 14:13:37 kaiser kernel: [306917.577063]  ffff984599846040 ffffaec4410e7a70 ffffffff99c15aa9 0000000000000000
Jun 10 14:13:37 kaiser kernel: [306917.577066]  00ffaec4410e7ab8 ffff98473fd18980 0000000000000046 ffff9847334cf000
Jun 10 14:13:37 kaiser kernel: [306917.577068] Call Trace:
Jun 10 14:13:41 kaiser kernel: [306917.577114]  [<ffffffff99c15aa9>] ? __schedule+0x239/0x6f0
Jun 10 14:13:41 kaiser kernel: [306917.577116]  [<ffffffff99c16760>] ? bit_wait+0x50/0x50
Jun 10 14:13:41 kaiser kernel: [306917.577118]  [<ffffffff99c15f92>] ? schedule+0x32/0x80
Jun 10 14:13:41 kaiser kernel: [306917.577119]  [<ffffffff99c1932d>] ? schedule_timeout+0x1dd/0x380
Jun 10 14:13:41 kaiser kernel: [306917.593358]  [<ffffffff9965af3a>] ? kvm_clock_get_cycles+0x1a/0x20
Jun 10 14:13:41 kaiser kernel: [306917.593425]  [<ffffffff99c16760>] ? bit_wait+0x50/0x50
Jun 10 14:13:41 kaiser kernel: [306917.593432]  [<ffffffff99c1580d>] ? io_schedule_timeout+0x9d/0x100
Jun 10 14:13:42 kaiser kernel: [306917.593456]  [<ffffffff996bd377>] ? prepare_to_wait+0x57/0x80
Jun 10 14:13:42 kaiser kernel: [306917.593466]  [<ffffffff99c16777>] ? bit_wait_io+0x17/0x60
Jun 10 14:13:42 kaiser kernel: [306917.593469]  [<ffffffff99c16335>] ? __wait_on_bit+0x55/0x80
Jun 10 14:13:42 kaiser kernel: [306917.593486]  [<ffffffff99782ea8>] ? find_get_pages_tag+0x158/0x2e0
Jun 10 14:13:42 kaiser kernel: [306917.593495]  [<ffffffff9978210f>] ? wait_on_page_bit+0x7f/0xa0
Jun 10 14:13:42 kaiser kernel: [306917.593497]  [<ffffffff996bd7e0>] ? wake_atomic_t_function+0x60/0x60
Jun 10 14:13:42 kaiser kernel: [306917.593500]  [<ffffffff99782210>] ? __filemap_fdatawait_range+0xe0/0x140
Jun 10 14:13:42 kaiser kernel: [306917.593519]  [<ffffffff99907d96>] ? submit_bio+0x76/0x140
Jun 10 14:13:42 kaiser kernel: [306917.593522]  [<ffffffff9978227f>] ? filemap_fdatawait_range+0xf/0x30
Jun 10 14:13:42 kaiser kernel: [306917.593564]  [<ffffffffc03bf7c5>] ? jbd2_journal_commit_transaction+0x735/0x17c0 [jbd2]
Jun 10 14:13:42 kaiser kernel: [306917.593568]  [<ffffffff99c1a9a4>] ? __switch_to_asm+0x34/0x70
Jun 10 14:13:42 kaiser kernel: [306917.593570]  [<ffffffff99c1a9a4>] ? __switch_to_asm+0x34/0x70
Jun 10 14:13:42 kaiser kernel: [306917.593572]  [<ffffffff99c1a9b0>] ? __switch_to_asm+0x40/0x70
Jun 10 14:13:42 kaiser kernel: [306917.593580]  [<ffffffff996a1d21>] ? finish_task_switch+0x71/0x210
Jun 10 14:13:42 kaiser kernel: [306917.593585]  [<ffffffffc03c4c72>] ? kjournald2+0xc2/0x260 [jbd2]
Jun 10 14:13:42 kaiser kernel: [306917.593587]  [<ffffffff996bd740>] ? prepare_to_wait_event+0xf0/0xf0
Jun 10 14:13:42 kaiser kernel: [306917.593591]  [<ffffffffc03c4bb0>] ? commit_timeout+0x10/0x10 [jbd2]
Jun 10 14:13:42 kaiser kernel: [306917.593599]  [<ffffffff9969a969>] ? kthread+0xd9/0xf0
Jun 10 14:13:42 kaiser kernel: [306917.593601]  [<ffffffff99c1a9a4>] ? __switch_to_asm+0x34/0x70
Jun 10 14:13:42 kaiser kernel: [306917.593603]  [<ffffffff9969a890>] ? kthread_park+0x60/0x60
Jun 10 14:13:42 kaiser kernel: [306917.593605]  [<ffffffff99c1aa37>] ? ret_from_fork+0x57/0x70
Jun 10 14:13:42 kaiser kernel: [306917.594216] rs:main Q:Reg   D    0   867      1 0x00000000
Jun 10 14:13:42 kaiser kernel: [306917.594222]  ffff984737530000 ffff984733d2e800 ffff984733ba6040 ffff98473fd18980
Jun 10 14:13:42 kaiser kernel: [306917.594225]  ffff9847334bc040 ffffaec44101fa20 ffffffff99c15aa9 0000000000000000
Jun 10 14:13:42 kaiser kernel: [306917.594228]  0000000000000000 ffff98473fd18980 0000000000000000 ffff984733ba6040
Jun 10 14:13:42 kaiser kernel: [306917.594231] Call Trace:
Jun 10 14:13:42 kaiser kernel: [306917.594236]  [<ffffffff99c15aa9>] ? __schedule+0x239/0x6f0
Jun 10 14:13:42 kaiser kernel: [306917.594238]  [<ffffffff99c16760>] ? bit_wait+0x50/0x50
Jun 10 14:13:42 kaiser kernel: [306917.594241]  [<ffffffff99c15f92>] ? schedule+0x32/0x80
Jun 10 14:13:42 kaiser kernel: [306917.594243]  [<ffffffff99c1932d>] ? schedule_timeout+0x1dd/0x380
Jun 10 14:13:42 kaiser kernel: [306917.594265]  [<ffffffff996f14fe>] ? ktime_get+0x3e/0xb0
Jun 10 14:13:42 kaiser kernel: [306917.594268]  [<ffffffff99c16760>] ? bit_wait+0x50/0x50
Jun 10 14:13:42 kaiser kernel: [306917.594271]  [<ffffffff99c1580d>] ? io_schedule_timeout+0x9d/0x100
Jun 10 14:13:42 kaiser kernel: [306917.594273]  [<ffffffff996bd377>] ? prepare_to_wait+0x57/0x80
Jun 10 14:13:42 kaiser kernel: [306917.594275]  [<ffffffff99c16777>] ? bit_wait_io+0x17/0x60
Jun 10 14:13:42 kaiser kernel: [306917.594277]  [<ffffffff99c16335>] ? __wait_on_bit+0x55/0x80
Jun 10 14:13:42 kaiser kernel: [306917.594279]  [<ffffffff99c1a9a4>] ? __switch_to_asm+0x34/0x70
Jun 10 14:13:42 kaiser kernel: [306917.594280]  [<ffffffff99c16760>] ? bit_wait+0x50/0x50
Jun 10 14:13:42 kaiser kernel: [306917.594282]  [<ffffffff99c1649e>] ? out_of_line_wait_on_bit+0x7e/0xa0
Jun 10 14:13:42 kaiser kernel: [306917.594284]  [<ffffffff996bd7e0>] ? wake_atomic_t_function+0x60/0x60
Jun 10 14:13:42 kaiser kernel: [306917.594289]  [<ffffffffc03bdbe1>] ? do_get_write_access+0x1f1/0x450 [jbd2]
Jun 10 14:13:42 kaiser kernel: [306917.594294]  [<ffffffffc03bde8c>] ? jbd2_journal_get_write_access+0x4c/0x60 [jbd2]
Jun 10 14:13:42 kaiser kernel: [306917.594405]  [<ffffffffc0415a36>] ? __ext4_journal_get_write_access+0x36/0x70 [ext4]
Jun 10 14:13:42 kaiser kernel: [306917.594425]  [<ffffffffc03e35f0>] ? ext4_reserve_inode_write+0x70/0x90 [ext4]
Jun 10 14:13:42 kaiser kernel: [306917.594437]  [<ffffffffc03e8373>] ? ext4_dirty_inode+0x43/0x60 [ext4]
Jun 10 14:13:42 kaiser kernel: [306917.594448]  [<ffffffffc03e365f>] ? ext4_mark_inode_dirty+0x4f/0x200 [ext4]
Jun 10 14:13:42 kaiser kernel: [306917.594458]  [<ffffffffc03e8373>] ? ext4_dirty_inode+0x43/0x60 [ext4]
Jun 10 14:13:42 kaiser kernel: [306917.594482]  [<ffffffff9983b02b>] ? __mark_inode_dirty+0x16b/0x360
Jun 10 14:13:42 kaiser kernel: [306917.594485]  [<ffffffff998284d9>] ? generic_update_time+0x79/0xd0
Jun 10 14:13:42 kaiser kernel: [306917.594487]  [<ffffffff998286e6>] ? current_time+0x36/0x70
Jun 10 14:13:42 kaiser kernel: [306917.594488]  [<ffffffff998287df>] ? file_update_time+0xbf/0x110
Jun 10 14:13:42 kaiser kernel: [306917.594495]  [<ffffffff996fb4a4>] ? futex_wake+0x94/0x170
Jun 10 14:13:42 kaiser kernel: [306917.594498]  [<ffffffff99784ef9>] ? __generic_file_write_iter+0x99/0x1b0
Jun 10 14:13:42 kaiser kernel: [306917.594510]  [<ffffffffc03da200>] ? ext4_file_write_iter+0x90/0x380 [ext4]
Jun 10 14:13:42 kaiser kernel: [306917.594518]  [<ffffffff9984f81e>] ? fsnotify+0x3ae/0x500
Jun 10 14:13:42 kaiser kernel: [306917.594526]  [<ffffffff9980b450>] ? new_sync_write+0xe0/0x130
Jun 10 14:13:42 kaiser kernel: [306917.594528]  [<ffffffff9980bc40>] ? vfs_write+0xb0/0x190
Jun 10 14:13:42 kaiser kernel: [306917.594531]  [<ffffffff9980d082>] ? SyS_write+0x52/0xc0
Jun 10 14:13:42 kaiser kernel: [306917.594558]  [<ffffffff99603b7d>] ? do_syscall_64+0x8d/0x100
Jun 10 14:13:42 kaiser kernel: [306917.594561]  [<ffffffff99c1a88e>] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
Jun 10 14:13:42 kaiser kernel: [306920.558700] sd 2:0:0:0: [sda] tag#0 abort
Jun 10 14:13:42 kaiser kernel: [306920.558856] sd 2:0:0:0: [sda] tag#2 abort
Jun 10 14:13:42 kaiser kernel: [306920.559012] sd 2:0:0:0: [sda] tag#3 abort

Und bei den Statistiken im SCP habe ich einen Peak in allen Diagrammen (CPU, Festplatte IOPS [Read], Netzwerk PPS [RX+TX], Netzwerk Bytes [TX]).

Liegt das an meinem System (dreht da eine Software durch), ist das ein Angriff oder gibt es da ein Problem an meinem Host?

Ich hoffe, jemand kann mir hier einen Tipp geben - danke schonmal.

Quote from mainziman

klar als VM ist man angreifbar, meinte natürlich so richtig Offline sprich, einfach das Kabel zum ISP ziehen ...

je nach Gegner reicht das ziehen des Kabels zum ISP aber nicht. Ist aber bestimmt der erste und wichtigste Schritt.

Jedoch sollte da gar kein Kabel zum PC gehen, sowie auch jegliche Strahlung und Schall verhindert werden.

Sprich Strom vom Akku, und das ganze in einem schallgedämmten Bleicontainer.

Als Restrisiko sehe ich dann noch Vibrationen von dem Container und die Raumtemperatur.

Quote from mainziman

wenn das Angriffspotential da ist, dann ist man nur dann auf der sicheren Seite, wenn man Offline ist;

nicht unbedingt. Gibt auch dafür einige Angriffsmöglichkeiten.

Und falls "offline" eine VM im Rechenzentrum ohne Netzwerkzugriff ist, sowieso.

Quote from Kraeutergarten

Ich glaube ja, dass das alles erst der Anfang sein wird. Ich denke da wird jetzt sehr viel Geld in die Forschung fließen und die nächsten riesen Lücken warten nur darauf gefunden zu werden.

Angeblich soll Intel einige Experten in diesem Bereich "gekauft" haben und in andere Richtungen forschen lassen.
Aber ja, gibt sicher noch genug Schwachstellen in der Hardware. Und halbwegs sicher ist derzeit wohl nur, wer keine geteilten Ressourcen verwendet. Also jede sicherheitsrelevante Software auf einem eigenen Computer.

Quote from killerbees19

https://futurezone.at/digital-…lionen-computer/400494343

Wurde mir heute schon an der Uni angekündigt - jetzt gibts endlich Infos dazu. Mich wundert etwas die Uhrzeit beim Futurezone-Artikel - eigentlich ging das NDA bis 19:00 Uhr CEST.

Da steht wohl die nächste Reboot-Welle bei netcup an...

Mich würde interessieren, ob netcup bei solchen Lücken im Vorfeld informiert wird. Einige Medien ja scheinbar schon.

In Zukunft werden virtuelle Maschinen wohl nochmals teurer werden/weniger CPU-Leistung haben.

... zumindest bis die CPUs halbwegs sicher sind. Gruss meinte, dass in 5 Jahren Intel soweit sein könnte, sichere Caches zu bauen.

Quote from mainziman

KB19 hatte Wien in Erinnerung, ist ein Grazer Bäcker

Man kann aber genauso mit Bargeld zahlen - nur wirds nicht gerne gesehen. Und man muss es halt "klein" haben - Wechselgeld gibt es nur aus der Trinkgeldkassa.