ICMP-Antworten zurückschicken, ist nicht mehr unbedingt, was man heute im wilden Internet haben will.
nein? was denkst Du damit verstecken zu können?
als user will ich einen timeout nicht abwarten wollen.
Beiträge von hoedlmoser
-
-
huch, und das schon länger als ein jahr. schade.
-
ich werf als dyndns dienst noch nsupdate dot info in den ring.
-
warum nicht im DNS einen CNAME setzen und jeden beliebigen dyndns verwenden?
-
sehr gut zusammengefasst!
Der reverse DNS Record zur IP des Mailservers muss auf den gleichen FQDN verweisen wie der, der im MX Record steht.
nein. aber die domain im ptr record und im ehlo sollten matchen.
es spricht also nichts dagegen wenn dein mailserver überall mx.example.com heißt, lediglich im reverse dns franz.example.com.
sich um gültige SSL Zertifikate kümmern.
das spielt keine rolle für den mailversand. und den einliefernden mailservern ist das vollkommen egal, da reicht auch ein selbstsigniertes.
-
die Hoffnung stirbt zuletzt
aber sie stirbt.
-
Wie lange behaltet ihr tägliche/wöchentliche/monatliche Backups?
7/4/6 ist meine standardeinstellung
-
Unterteilung von vda2 und vda3
was steht dazu in der fstab?
bzw wie sieht der output von blkid und lsblk aus?
-
statische Adressen für Heimserver etc., aber halt per DHCP zugeteilt.
würde das je nach verfügbarkeitsanforderung unterschiedlich machen.
a) statisch konfiguriert
b) statisch zugewiesen
c) dynamisch
infrastruktur bekommt statisch konfiguriert, damit kommst dann auf diese komponenten auch noch drauf wenn der dhcp server kaputt ist.
-
möglichst immer statisch konfiguriert. Alles andere ist nur eine zusätzliche Fehlerquelle, die in 99% der Fälle keinen wirklichen Mehrwert hat.
auch zuhause sollte man bei den wichtigsten komponenten auf statische IPs setzen.
-
installierst bei netcup das Betriebssystem Deiner Wahl neu und kopierst danach ausgewählte Konfigurationen und Daten manuell z.B. mittels rsync über SSH rüber.
wenn ich das richtig verstanden habe ist diese J1ffyB0x ein container. müsste man also in einem proxmox zb zum laufen bekommen.
einen container mit nginx davorsetzen und in einem dritten container ein gänzlich frisches setup beginnen und die inhalte von der J1ffyB0x kontinuierlich migrieren.
-
lustig wie hier die meinungen divergieren.
die großen wie sendgr1d, ma1lgun, cl0udflare, … zumindest sind sich einig dass mails von einem client gefälligst über den smtp submission port 587 einzuliefern sind.
-
mir gefällt ja am besten der append-only mode von borgbackup.
-
wozu dann rsync und nicht scp?
-
unprivilegierten Backup-Nutzers
wie restorest Du dann die permissions?
-
zu einem Thema die falsche Meinung
glaub mir, die hab ich. bin militanter straßenbaugegner. 😂
Das "Ich habe doch nichts zu verbergen" Argument
hab nicht ich eingebracht. datensparsamkeit ist mein dritter vorname.
lediglich wollte ich abwägen zwischen den rechtsfolgen aus falschen angaben im impressum und dem gefährdungspotential aus einem korrekten impressum.
-
mit steigendem Alter und mehr Bewusstsein für die Gefahren
ich war im fido und in newsgroups mit klarnamen unterwegs, damals war das noch üblich. im vereinsregister und im impressum findet man meine anschrift.
welche gefahren halten Dich zur datensparsamkeit an? mir hat noch keiner vor die tür defäkiert.
-
Domaininhaber ≠ Webseitenbetreiber.
es gibt die rollen registrant, admin-c, tech-c. und der domaininhaber wird auftraggeber vom webseitenbetreiber sein.
wobei ich bis jetzt nicht verstanden habe warum die DSGVO gegen ein whois anwendbar ist, aber nicht gegen ein vereinsregister oder ein unternehmensregister.
-
warum immer das herumgehampel mit snapshots? rsync (im recovery) ist der goldene weg imho.
- zielserver ins recovery booten
- partitionen erstellen (gdisk) und filesysteme initialisieren (mkfs.ext4)
- filesysteme einhängen
- mkdir /target
- mount /dev/sda2 /target
- mkdir /target/boot
- mount /dev/sda1 /target/boot
- erster sync wenn der quellserver noch normal läuft ionice -c idle rsync -axHAXvP --numeric-ids --delete / root@<zielserver>:/target/
- quellserver ins recovery booten
- filesysteme wie am zielserver einhängen
- mkdir /source
- mount /dev/sda2 /source
- mount /dev/sda1 /source/boot
- finaler sync rsync -axHAXvP --numeric-ids --delete /source/ root@<zielserver>:/target/
- ins chroot wechseln (hoffentlich gibts das prepare auch im netcup recovery)
- chroot-prepare /target
- chroot /target
- grub installieren
- grub-mkdevicemap -n
- grub-install /dev/sda
- in der /etc/fstab noch die uuids aus blkid anpassen
- je nach bedarf sollte man noch /etc/udev/rules.d/70-persistent-net.rules und /etc/mdadm/mdadm.conf anpassen
- es empfiehlt sich auch jetzt schon die IP adresse anzupassen, die stellen findet man mit fgrep -sir "<IP>" /
- boot-fähig machen
- update-initramfs -u -k all
- update-grub2
- reboot
- in der console aufgeregt zusehen wie der zielserver erfolgreich bootet
mkswap und lvm oder eine notwendige uefi partition darf sich jeder selbst dazubasteln.
-
hinter einer paywall gäbs noch einen bauvorschlag der c‘t https://www.heise.de/ratgeber/Bauvo…ro-9597584.html
