Beiträge von femur

This error also happened when I wanted to log in. I could log in again after clearing the cookies for the page in my browser. Maybe that helps you regaining access to the CCP.

Zitat von TBT

- eine neue IP muss bei T-Online whitegelistet werden, hierfür muss man ein Impressum auf einer Website unterhalb der Maildomain nachweisen können (also auf http://www.meinedomain.de , wenn der rDNS Eintrag und Haupt MX auf mail.meinedomain.de auflöst/verweist).

Ich habe nur den Link zum Whois-Auszug der DENIC an die Telekom weitergeleitet und wurde auch freigeschaltet.

Vielleicht hilft es schon ein anderes Tool zu nutzen. Ich verwende gerne `dua` (https://github.com/Byron/dua-cli). In meinem Home-Ordner mit ~1,7 Mio Dateien und Ordnern gibt sich folgendes Bild:

Benchmark 1: dua .
  Time (mean ± σ):      1.478 s ±  0.016 s    [User: 2.577 s, System: 5.283 s]
  Range (min … max):    1.456 s …  1.504 s    10 runs

Benchmark 2: du -s
  Time (mean ± σ):      5.249 s ±  0.029 s    [User: 1.647 s, System: 3.545 s]
  Range (min … max):    5.223 s …  5.310 s    10 runs

Summary
  dua . ran
    3.55 ± 0.04 times faster than du -s

Ansonsten gäbe es mit Btrfs (und vermutlich ZFS) die Möglichkeit mittels Subvolumes und offenen Quotas das ganze mitzuzählen. Allerdings nimmt man da natürlich alle Vor- und Nachteile des Dateisystems mit und ich erwähne das nur der Vollständigkeit halber.

NAME                                  TYPE    REFER     EXCL  MOUNTPOINT
xxxxxxxx                                fs       -   361.23G (single, 565.06G/931.32G free, 60.67%)
    [main]                         mainvol   16.00k   16.00k /
    root                            subvol    8.09G    7.41G /
        snapshots/root-20230101     rosnap    3.55G    2.88G
    boot                            subvol   54.54M   54.54M
        snapshots/boot-20230101     rosnap  129.25M  129.25M
    srv                             subvol  311.09G   14.04G /srv
        snapshots/srv-20230101      rosnap  309.97G   12.92G
    home                            subvol    2.25G  896.54M /home
        snapshots/home-20230101     rosnap    1.84G  480.01M
    var                             subvol   11.51G    8.37G /var
        snapshots/var-20230101      rosnap    8.82G    5.68G

Auch wenn wir hier bei Netcup sind: Kann man dem orangenen Server auch reverse DNS Namen vergeben?

Das Netcup SCP ist deutlich schöner/funktionaler als die Admin-Oberfläche dort..

Danke Moderatoren dafür, dass ihr die QA-Session aufgezeichnet habt und uns zur Verfügung stellt!

Ich fand interessant, was Netcup im Hintergrund unternimmt und wie ihr bestimmte Features und Marktbewegungen bewertet (z.B. Mailplattform, Kreditkartenzahlung, ARM-Server). Ich war überrascht, dass Netcup schon ARM-Server intern testet und bin gespannt ob/wie ihr euch entscheidet daraus Produkte zu schnüren.

Gebt das Dankeschön gerne auch an eure Kollegen weiter, die nicht so publikumswirksam wie die Moderation sind.

Zitat von frank_m

Aber den A Eintrag einfach auf irgendeine Shopify IP umzubiegen, ist auch gefährlich. Die haben mehr als eine davon. Es gibt schon einen Grund dafür, dass sie CNAMEs fordern.

Der CNAME für @ geht grundsätzlich nicht, auch bei anderen Anbietern nicht. Den CNAME für * solltest du wieder rausnehmen.

Tatsächlich gibt Shopify das so vor, damit der Shop auch ohne Subdomain aufrufbar ist. Deshalb finde ich es kein Problem, die IP-Adresse direkt anzugeben.

https://help.shopify.com/de/manual/domains/add-a-domain/connecting-domains/connect-domain-manual

Der Eintrag "@ A 23.227.38.85" sollte reichen, damit deine Domain auf Shopify zeigt. Die Einträge mit "*" als Host würde ich wieder löschen. Die werden sowieso nicht verwendet, wenn die Domain ohne "www" abgefragt wird.

Die Eintragungen sind soweit richtig. Hast du lange genug (1 Tag) gewartet, bevor du es probiert hast? Wird die Domain bei Shopify als verbunden angezeigt?

Wenn ein CNAME Eintrag existiert, muss dieser der einzige für diesen "Host" sein. Deshalb ist im Bild oben der Eintrag "* A 23.227.38.85" unnötig bzw. ungültig. Daraus ergibt sich auch, dass der Apex (@) nicht mit CNAME als Alias verwendet werden kann, schließlich existieren die SOA und NS Einträge auch. Nur Subdomains können mit CNAME weitergeleitet werden.

Mittlerweile arbeite ich im Schichtdienst Früh/Tag/Spät und Nacht auch an Wochenenden. Ich bin fast erstaunt wie gut ich damit zurechtkomme. Die Büroarbeitszeiten waren natürlich bequemer, aber jetzt hab ich unter der Woche freie Tage und Feierabend bedeutet Freizeit. Kein "Aber das muss doch heute noch fertig werden" oder "das geht noch schnell". Hat halt alles seine Vor- und Nachteile.

Den Absatz zum delegieren kann ich nur unterstreichen. Oft fällt zusätzliche Arbeit nur an, weil andere Arbeitszeit nicht nutzbringend eingesetzt wurde, Kommunikation sich verirrt hat oder sehr viele Arbeitsschritte in der kritische Kette (Critical Chain) liegen.

Ein Beispiel: Die Domain netcup.shop ist noch frei. Wenn sich diese jemand registriert und diese Mail gut imitiert, dann habe ich praktisch keine Chance den Phishingversuch zuverlässig zu erkennen. Schließlich gibt es ja netcup.news, netcup.de, netcup.net, netcup.com, netcup.eu und netcup-sonderangebote.de.

EDIT: netcup.news leitet auch nicht zur netcup-Hauptseite weiter, man erhält nur eine "Forbidden" Seite. Das ist gar nicht gut..

Ich mag die Ironie direkt nach dem Link darauf hinzuweisen nicht auf Links zu klicken. Und dieser Link führt dann auch noch auf mautic.netcup.news, entgegen dem Linktext, der zum Customer Control Panel führt. Wie soll man denn da noch Leuten beibringen was eine Phishing-Mail ist und was nicht? Wenn schon verlinkt dann doch bitte direkt, oder müsst ihr in dieser Warnung auch noch die Reichweite messen?

So macht ihr, Netcup, es den Spammern auch einfacher sich zu tarnen. Woher soll denn ein Nutzer wissen, dass netcup.news auch Netcup gehört? Warum ist es hier in Ordnung, dass der Linktext und das Linkziel auf verschiedene Domains zeigt? Das wird in vielen Phishing-Trainings in den Firmen sogar explizit als Hinweis auf Phising genannt!

Ich habe das Gefühl, dass hier auch wieder keine 5 Minuten über das Problem "authentische Mail / Phishing" nachgedacht wurde.

Ich denke, dass diese Meldung nur eine Folge aus dem Absturz des smtp Prozesses ist. Der Socket zwischen qmgr und smtp wird unvermittelt geschlossen wodurch qmgr einen Fehler loggt. Eine externe Anfrage erreicht den abstürzenden smtp Prozess nicht, dafür sind andere Prozesse zuständig.

Zitat von Interessent

Feb 26 15:24:35 mein-server postfix/qmgr[436133]: warning: private/smtp socket: malformed response

Ich sehe gerade, dass ich oben einen Fehler gemacht habe, denn die Option -v sollte in master.cf nicht beim smtpd sondern bei smtp angegeben werden. Kannst du das bitte nochmal prüfen? (smtp: SMTP-Client zum Senden von Mails, smtpd: SMTP-Server zum Emfangen von Mails)

Ansonsten wäre ein Coredump bestimmt aufschlussreich. Das ist zwar die Holzhammer-Methode, aber was anderes fällt mir nicht wirklich ein. Weißt du wie du an einen Coredump kommen kannst?

Um die Absturzursache einzugrenzen schlage ich ein paar Tests vor:

Versuche zum Beispiel mit sendmail eine Mail an einen anderen Empfänger zu verschicken. Damit möchte ich herausfinden, ob der smtp-Prozess auch bei Verbindungen zu anderen Mailservern abstürzt, oder es irgendwie an der Kommunikation bei den Systemmails liegt.

Außerdem könnte es helfen mehr Logging zu aktivieren. Ein Weg ist das -v Flag an den smtp Prozess in master.cf anzuhängen. Vielleicht gibt uns das einen Tipp was kurz vor dem Absturz passiert.

Zitat von Postfix Debugging Howto

Making Postfix daemon programs more verbose

Append one or more "-v" options to selected daemon definitions in /etc/postfix/master.cf and type "postfix reload". This will cause a lot of activity to be logged to the syslog daemon. For example, to make the Postfix SMTP server process more verbose:

Code

/etc/postfix/master.cf:    smtp      inet  n       -       n       -       -       smtpd -v

To diagnose problems with address rewriting specify a "-v" option for the cleanup(8) and/or trivial-rewrite(8) daemon, and to diagnose problems with mail delivery specify a "-v" option for the qmgr(8) or oqmgr(8) queue manager, or for the lmtp(8), local(8), pipe(8), smtp(8), or virtual(8) delivery agent.

Hi,

da dürften die Optionen RandomizedDelaySec und eventuell FixedRandomDelay helfen. Damit wird der Timer um eine zufällige Zeit verschoben und die Hosts verteilen sich. Mit FixedRandomDelay bleibt dabei das Intervall trotzdem konstant.

Zitat von Manual page systemd.timer(5)

RandomizedDelaySec=

Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. Each timer unit will determine this

delay randomly before each iteration, and the delay will simply be added on top of the next determined elapsing time, unless modified with FixedRandomDelay=, see below.

This setting is useful to stretch dispatching of similarly configured timer events over a certain time interval, to prevent them from firing all at the same time, possibly resulting in resource congestion.

Note the relation to AccuracySec= above: the latter allows the service manager to coalesce timer events within a specified time range in order to minimize wakeups, while this setting does the opposite: it stretches timer

events over an interval, to make it unlikely that they fire simultaneously. If RandomizedDelaySec= and AccuracySec= are used in conjunction, first the randomized delay is added, and then the result is possibly further

shifted to coalesce it with other timer events happening on the system. As mentioned above AccuracySec= defaults to 1 minute and RandomizedDelaySec= to 0, thus encouraging coalescing of timer events. In order to optimally

stretch timer events over a certain range of time, set AccuracySec=1us and RandomizedDelaySec= to some higher value.

Alles anzeigen

Signal 11 ist SIGSEGV, salopp gesagt stürzt der smtp Prozess ab. Dieser Prozess stellt die Verbindung zum anderen Mailserver her und versendet die Mail schlussendlich.

Die übliche Frage zum Anfang: Hast du den Postfix-Service schon mal neu gestartet, um z.B. ein teilweises Update ausschließen zu können? Kannst du den Absturz auch bei Mails an andere Empfänger beobachten? Sind Coredumps vorhanden, die die Absturzursache klären könnten? (coredumpctl falls systemd genutzt wird).

Das sind meine ersten Ideen zu diesem Problem.

Zitat von iKameo

Firefox.

Sowohl aufm Desktop als auch Mobil.

Mobil wegen den Addons und aufm Desktop weil ich mit Firefox Sync alles zwischen mobil und Desktop synchron halten kann

Dito

Außerdem läuft Firefox bei mir im Linux problemlos unter Wayland mit HiDPI. Chrome hat da so seine Probleme. Ob Edge das kann muss ich Mal ausprobieren.

Zitat von sla

• Pakete müssen ZWINGEND über deren GW weil sie sonst blockiert werden,

Was meinst du damit genau? Ist das hier nicht auch so, oder meinst du mit GW nicht den IP(v6)-Nexthop?

Viele Router blockieren allerdings DNS-Antworten von öffentlichen Resolvern, die lokale IPs (bzw. private IPs, 192.168/16, 172.16/12, 10/8) enthalten. Also nicht wundern, wenn die Namensauflösung nicht funktioniert, obwohl der DNS-Eintrag richtig gesetzt wurde. (z.B. grafana.example.com. A 192.168.178.1)

Bei meinem custom-NAS erreiche ich ~940Mbit/s via SMB. Da limitiert dann die Gigabit-Anbindung.

Im Fefe-Artikel geht es allerdings nicht um Software, die lokal verschlüsselt und dann hochlädt, sondern um Verschlüsselung innerhalb der Cloud mit dem Schlüssel in der Cloud. Mit der Einschränkung, dass man dem Client vertrauen muss, den Schlüssel nicht doch irgendwie in die Cloud zu schieben.

Boxcryptor und vermutlich auch 1Password haben in der Cloud nur verschlüsselte Inhalte und man bekommt die auch nur in verschlüsselter Form an den Client geliefert. Lokal kann dann entschlüsselt werden. Da sind die Daten trotz eines Leaks in der Cloud geschützt. Wenn aber der Schlüssel in der Cloud daneben liegt (im Kundenkonto hochgeladen z.B.), dann hilft die Verschlüsselung nicht mehr.

Verschlüsselung verlagert das Problem die Daten gegen Angriffe zu schützen auf den Schlüssel. Also sollte der Schlüssel nicht da liegen wo die Daten auch sind.