Das Ziel sollte natürlich IPv6 unterstützen, sonst wird das logischerweise nichts!
Ich kann mir aber nicht vorstellen, dass das klappt. ICMPv6 ist für jegliche IP-Kommunikation erforderlich, es wird ja kaum nur am Ping scheitern.
MfG Christian
Das Ziel sollte natürlich IPv6 unterstützen, sonst wird das logischerweise nichts!
Ich kann mir aber nicht vorstellen, dass das klappt. ICMPv6 ist für jegliche IP-Kommunikation erforderlich, es wird ja kaum nur am Ping scheitern.
MfG Christian
Wenn man die Keyfiles mit einem Passwort schützt, ist es eigentlich fast egal, ob diese in der Cloud abgelegt werden. Meine liegen am NAS, über mein VPN kann ich mir jederzeit fehlende auf z.B. Handy oder Notebook herunterladen. (Und eine Passphrase sollten Keyfiles immer haben, außer für automatisierte Aufgaben über Scripte!)
Ich finde Keyfiles extrem praktisch. So muss ich mir nur die Passphrase merken. Am Smartphone bzw. Tablet verwende ich VX Connectbot, dort werden sie einwandfrei unterstützt. Und auf fremden Rechnern würde ich niemals eine SSH-Verbindung zu meinen Servern herstellen! Das ist meiner Ansicht nach eine der schlimmsten Aktionen, die man machen kann. Würde bei mir aber sowieso nicht gehen, weil SSH nur über das VPN erreichbar ist.
MfG Christian
hat es eigentlich jemand mal hinbekommen die IPv6 Adressen aus dem /64 direkt an die Container zu verteilen?
Könnte es an NDP scheitern? Häng Dich mal mit "tcpdump -n -l -v -i eth0 icmp6" dran und beobachte, ob auf die Neighbor Solicitations überhaupt ein Neighbor Advertisement von Deiner VM folgt.
Ich weiß nicht, wie das bei LXD oder OpenVZ gehandhabt wird, aber vielleicht braucht man da auch etwas wie ndppd oder wenigstens ndp_proxy. Das standardmäßig enthaltene /64 ist nämlich nicht geroutet!
MfG Christian
Ich glaube, spätestens jetzt muss ich mich endlich mit Lets Encrypt und der DNS-Challenge beschäftigen. Lange genug vor mir her geschoben.
Die letzte Testphase meines Setups läuft zwar noch, aber es sieht bisher sehr gut aus. Wurde auch Zeit, in ungefähr zwei Wochen laufen meine ersten St***SSL-Zertifikate aus…
Dank getssl und der API meines Domainregistrars läuft es ohne jegliche Änderung auf den Zielservern von einer zentralen VM aus. Mal abgesehen von OCSP-Stapling, dafür muss ich einmalig Änderungen im jeweiligen vHost vornehmen. Danach aber nie wieder, weil ich das auf eine neue Struktur umstelle, wo es ebenfalls von getssl mit aktualisiert wird.
Einen kleinen Haken hat das Setup noch: Wenn der Zielserver nicht erreichbar ist, wird das Zertifikat wahrscheinlich erfolgreich angefordert, kann dort aber nicht installiert werden. Einen erneuten Versuch gibt es nicht. In diesem Fall bleibt mir nur die Benachrichtigung vom Cron-Daemon per E-Mail, woraufhin ich händisch eingreifen muss. Mal sehen, ob ich dafür noch eine simple Lösung finde… Wenn ich den Sourcecode richtig interpretiert habe, versucht er es beim nächsten Cron-Durchlauf (oder eben manuell) einfach nochmals zum hinüber Kopieren. Das Problem ist somit keines, da der Autor dran gedacht hat. Auch gut…
Herzlichen Glückwunsch!
Sorry, mein Fehler! Du hast natürlich vollkommen recht.
MfG Christian
bei letzterem wird wahrscheinlich der webuser keinen Zugriff haben...
Es könnte auch damit zusammenhängen, dass die Pfade über SSH/CLI durch die Chroot-Umgebung nicht stimmen: owncloud console (occ) funktioniert nur nach config Änderung und legt Weboberfläche lahm (eine Lösung gibt es dort auch!)
MfG Christian
Kannst Du vielleicht ein wenig erklären wie bei dir das DHCP eingerichted isst?
Ich bin gerade etwas im Stress, wenn etwas fehlt oder unverständlich ist, bitte einfach melden. Das sollte aber alles sein, exklusive meinem VPN-Kram…
# cat /etc/dnsmasq.conf | egrep -Ev '^(#|$)'
interface=br0
bind-interfaces
domain-needed
bogus-priv
no-hosts
read-ethers
dhcp-range=172.19.1.****,172.19.1.254,24h
dhcp-option=option:ntp-server,0.0.0.0
# cat /etc/ethers | egrep -Ev '^\s*(#|$)'
52:54:00:c2:**:** 172.19.1.***
52:54:00:bb:**:** 172.19.1.***
52:54:00:64:**:** 172.19.1.***
52:54:00:0e:**:** 172.19.1.***
# cat /etc/ndppd.conf | egrep -Ev '^\s*(#|$)'
route-ttl 30000
proxy eth0 {
router no
timeout 500
ttl 30000
rule 2a03:4000:10:****::/64 {
iface br0
}
}
# cat /etc/radvd.conf | egrep -Ev '^\s*(#|$)'
interface br0
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2a03:4000:10:****::/64
{
AdvOnLink on;
AdvAutonomous on;
};
prefix fd66:6e78:21a3:****::/64
{
AdvOnLink off;
AdvAutonomous on;
};
RDNSS fd66:6e78:21a3:****::1
{
};
};
# cat /etc/network/interfaces | egrep -Ev '^\s*(#|$)'
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
address 188.68.34.****
netmask 255.255.252.0
gateway 188.68.32.1
iface eth0 inet6 static
address 2a03:4000:10:****::bc44:22**/64
gateway fe80::1
post-up ip -6 route del 2a03:4000:10:****::/64 dev eth0
auto tap0 br0
iface tap0 inet manual
pre-up ip tuntap add tap0 mode tap
post-down ip link del dev tap0
iface br0 inet static
address 172.19.1.****
netmask 255.255.255.192
post-up ip -6 route add fd66:6e78:21a3:****::/56 dev lo metric 64
pre-down ip -6 route del fd66:6e78:21a3:****::/56 dev lo metric 64
post-up ip -6 addr add fd66:6e78:21a3:****::1/64 dev $IFACE nodad
pre-down ip -6 addr del fd66:6e78:21a3:****::1/64 dev $IFACE
post-up ip -6 addr add 2a03:4000:10:****::1/64 dev $IFACE nodad
pre-down ip -6 addr del 2a03:4000:10:****::1/64 dev $IFACE
bridge_stp off
bridge_ports tap0
bridge_maxwait 0
bridge_fd 0
# cat ~/scripts/iptables.sh (Auszug)
IPv6_SUBNET="2a03:4000:10:****::/64"
IPv4_PRIMARY="188.68.34.***"
IPv4_KVM="172.19.1.***/26"
IFACE_DEFAULT="eth0"
IFACE_KVM="br0"
$IPv4_BIN -N "fnx_kvm_srccheck"
$IPv6_BIN -N "fnx_kvm_srccheck"
$IPv4_BIN -A "fnx_kvm_srccheck" -i "$IFACE_KVM" -o "$IFACE_DEFAULT" ! -s "$IPv4_KVM" -j LOG_DROP
$IPv6_BIN -A "fnx_kvm_srccheck" -i "$IFACE_KVM" -o "$IFACE_DEFAULT" ! -s "$IPv6_SUBNET" -j LOG_DROP
$IPv4_BIN -A FORWARD -j "fnx_kvm_srccheck"
$IPv6_BIN -A FORWARD -j "fnx_kvm_srccheck"
$IPv4_BIN -A INPUT -j "fnx_kvm_srccheck"
$IPv6_BIN -A INPUT -j "fnx_kvm_srccheck"
$IPv4_BIN -N "fnx_kvm"
$IPv6_BIN -N "fnx_kvm"
$IPv4_BIN -A INPUT -i "$IFACE_KVM" -m state --state NEW -j "fnx_kvm"
$IPv6_BIN -A INPUT -i "$IFACE_KVM" -m state --state NEW -j "fnx_kvm"
$IPv4_BIN -A "fnx_kvm" -p udp --sport 68 --dport 67 -j ACCEPT
$IPv6_BIN -A "fnx_kvm" -p udp --sport 546 --dport 547 -j REJECT
$IPv4_BIN -A "fnx_kvm" -p udp --dport 53 -j ACCEPT
$IPv6_BIN -A "fnx_kvm" -p udp --dport 53 -j ACCEPT
$IPv4_BIN -A "fnx_kvm" -p udp --sport 123 --dport 123 -j ACCEPT
$IPv6_BIN -A "fnx_kvm" -p udp --sport 123 --dport 123 -j ACCEPT
$IPv4_BIN -A "fnx_kvm" -j LOG_REJECT
$IPv6_BIN -A "fnx_kvm" -j LOG_REJECT
$IPv4_BIN -N "fnx_kvm_fw"
$IPv6_BIN -N "fnx_kvm_fw"
$IPv4_BIN -N "fnx_kvm_fw_pub"
$IPv6_BIN -N "fnx_kvm_fw_pub"
$IPv4_BIN -N "fnx_kvm_from_pub"
$IPv6_BIN -N "fnx_kvm_from_pub"
$IPv4_BIN -A FORWARD -i "$IFACE_KVM" -m state --state NEW -j "fnx_kvm_fw"
$IPv6_BIN -A FORWARD -i "$IFACE_KVM" -m state --state NEW -j "fnx_kvm_fw"
$IPv4_BIN -A FORWARD -i "$IFACE_DEFAULT" -o "$IFACE_KVM" -m state --state NEW -j "fnx_kvm_from_pub"
$IPv6_BIN -A FORWARD -i "$IFACE_DEFAULT" -o "$IFACE_KVM" -m state --state NEW -j "fnx_kvm_from_pub"
$IPv4_BIN -A "fnx_kvm_fw" -o "$IFACE_KVM" -j ACCEPT
$IPv6_BIN -A "fnx_kvm_fw" -o "$IFACE_KVM" -j ACCEPT
$IPv4_BIN -A "fnx_kvm_fw" -o "$IFACE_DEFAULT" -m state --state NEW -j "fnx_kvm_fw_pub"
$IPv6_BIN -A "fnx_kvm_fw" -o "$IFACE_DEFAULT" -m state --state NEW -j "fnx_kvm_fw_pub"
$IPv4_BIN -A "fnx_kvm_fw_pub" -j ACCEPT
$IPv6_BIN -A "fnx_kvm_fw_pub" -j ACCEPT
$IPv4_BIN -A "fnx_kvm_fw" -j LOG_REJECT
$IPv6_BIN -A "fnx_kvm_fw" -j LOG_REJECT
$IPv4_BIN -A "fnx_kvm_from_pub" -j DROP
$IPv6_BIN -A "fnx_kvm_from_pub" -j DROP
$IPv4_BIN -t nat -A POSTROUTING -s "$IPv4_KVM" -o "$IFACE_DEFAULT" -j SNAT --to "$IPv4_PRIMARY"
Alles anzeigen
Betrieben werden die Gäste über libvirt/kvm, dort ist einfach br0 als Netzwerkschnittstelle angegeben.
In den Gastsystemen laufen resolvconf, rdnssd und ntp. Gäste und Host werden mit Debian 8/9 betrieben.
MfG Christian
PS: Mit dnsmasq gab es für RA/DHCPv6 ein paar gravierende Probleme, deshalb musste doch radvd herhalten.
PPS: Im Gastsystem ist "auto" für das inet6-Interface ganz praktisch, zusammen mit: pre-up ip -6 token set ::dead:affe dev $IFACE
Welche DNS-Einstellungen hast Du aktuell gesetzt?
MfG Christian
Wo genau bei google hast Du denn nachgesehen?
Er meinte wohl die von Felix verlinkten Bewertungen direkt bei Google Maps: http://bit.ly/2eN7Flf (über Kurzlink, weil die Forensoftware den Link vermurkst)
Also ist das wirklich eine Macke von fetchmail? Gepaart mit fehlern von mir?
In erster Linie definitiv ein Konfigurationsfehler. Allerdings kann man bei Fetchmail nie 100% ausschließen, dass so etwas während dem Betrieb nicht passieren wird. Und es hat auch noch ein paar andere Macken, die auf der Getmail-Website gut aufgeführt werden.
Getmail kann man zwar auch so konfigurieren, dass alles über einen Mailserver weiter zum Postfach zugestellt wird. Meistens macht man es aber so, dass man direkt an den LDA (z.B. Dovecot) oder den Spamfilter zustellt. Sogar die direkte Zustellung an ein Maildir ist möglich, umgeht dann aber eventuell vorhandene Sieve-Filter. Dadurch kann die Mail bzw. eine Bounce-Nachricht im Fehlerfall gar nicht erneut in der Queue landen.
MfG Christian
Synology setzt in manchen NAS-Geräten auch schon auf Btrfs, von daher ist die Tatsache, dass Ubuntu darauf setzt, nicht wirklich eine Entscheidungsgrundlage
Mit ZFS habe ich persönlich noch keine Erfahrung gemacht, dazu kann ich nichts sagen. Sorry.
Schau Dir mal Getmail an, das hat solche Designschwächen nicht!
MfG Christian
PS: So etwas ist mir bei meiner ersten Fetchmail-Konfiguration auch passiert. Damals hingen knapp 2.000 Mails in der Queue. Zum Glück fiel es mir nach ein paar hundert Mails auf…
Bei mir läuft aber alles zufriedenstellend und stabil. Daher würde mich interessieren, was deine Probleme mit BTRFS waren.
Die Stabilität war nicht das Problem, wenn man die Meldungen aus dem Internet ignoriert. Eher, dass dieses und jenes an Userspace-Tools noch nicht ganz oder gar nicht implementiert ist. Auch gefiel es mir nicht, dass ich immer den neuesten Kernel fast schon verwenden muss, wenn ich kein Risiko eingehen möchte. Das passt nicht zu einem Debian Stable System. Da die Dokumentation und das Wissen innerhalb der Community logischerweise auch noch nicht auf dem Stand von ext4 o.ä. ist, habe ich mich dann doch lieber dafür entschieden, bei einem bewährten Mix zu bleiben. Btrfs wird kommen, keine Frage, aber man muss es ja nicht überstürzen. Ich sammel lieber erst einmal Erfahrung mit unwichtigen Dingen in einer VM zu Hause. Für ein Produktivsystem ist mir das aktuell zu gefährlich.
Es gab da leider auch noch ein Problem, das sich neues ORF-Gesetz nannte, das genau solche Sachen relativ unmöglich gemacht hat…
Zu Zeiten mit den ganzen Medienpartnern und Sponsoren (ORF, SRF, FTV, Wagner, ...) war es durchaus interessant. Zwischen 2007 und 2010 waren jedes Jahr 300.000 oder noch mehr Spieler am Start. Da hast bei einem Rennen auf den hintersten Plätzen gar keine Weltcuppunkte mehr bekommen, weil nur die ersten 100.000 berücksichtigt wurden. Durch den Wegfall vom ORF und anderen sank auch die Bekanntheit und das Interesse. Davor gab es sogar fix Fernsehbeiträge über Ereignisse bei der SC und große Live-Events als Saisonabschluss, wo die Besten vor Publikum gegeneinander antraten. Dagegen waren die letzten Jahre Kinderkram...
Siehe mein Beitrag vom September. Ich persönliche habe die Snapshotfunktion bis auf wenige Ausnahmen nie benutzt. Als Backup taugt es am selben System eh nichts und somit ist es maximal etwas bei OS-Upgrades. Allerdings mit der erwähnten Einschränkung, dass man nur maximal 50% belegt haben darf.
MfG Christian
Zitator this file system doesn't support hardlinks
Überprüf mal das, ob Du dort manuell Hardlinks (nicht Softlinks!) erstellen kannst.
Ansonsten prüfe nochmals genau die Rechte des gemounteten Verzeichnisses.
MfG Christian
Dann hast Du definitiv genügend freien Speicherplatz...
MfG Christian