Dieses RechnungsWirrWarr macht die Buchhaltung ziemlich nervig.
Fühl ich... das ist supernervig. Bei anderen Anbietern gibt es eine simple Monatsrechnung und gut ist, das ist einfach zu handeln und man kann damit planen.
Dieses WirrWarr ist einfach nur noch unerträglich und schafft so viel Zusatzarbeit in der Buchhaltung, dass man die paar Cent Ersparnis im Vergleich zu anderen Anbietern ganz schnell wieder wegmacht...
Hi,
du müsstest die Postfächer hier bei Netcup neu anlegen und diese dann vom alten Anbieter umziehen/synchronisieren. ImapSync würde sich da anbieten.
Wir haben Jitsi auf einem RS 8000 G8SE SSD und das läuft gut. Wir hatten zwar noch nie derart viele User parallel - aber wenn ich da jetzt mal das Monitoring nehme und das ins Verhältnis setze, sollte das locker passen.
Bei netcup müsste mal halt noch Folgendes beachten: Entweder man hat ein zusätzliches ("geroutetes") IPv6-Subnetz für diesen Einsatzzweck oder man braucht auch noch einen NDP-Proxy o.ä. auf dem Tunnelserver.
(Mein Tunnelserver läuft jedenfalls auch nicht hier. Hat aber damit zu tun, dass mir /64 zu klein ist.)
Das ist aber auch in der H-Cloud so, wenn du mit dem Standard /64 des Servers hinkommen willst. Daher habe ich mir ja ein weiteres /64 gekauft/gemietet, welches ich route und im Heimnetz benutze.
Allerdings würde mir das /64 des Servers auch reichen, da der Server nur eine IP davon braucht.
Mal schauen, vielleicht probiere ich das mit dem NDP Proxy mal. Ohne hat es jedenfalls nicht geklappt - so viel kann ich sagen, aber das ist ja auch logisch.
Caspar mainziman m_ueberall KB19
"SIT" oder SIIT (Stateless IP/ICMP Translation, RFC 7915)?
Das Problem ist eher, dynamische Endpunkte zu aktualisieren. Wie hast Du das bei Dir gelöst? Oder hast Du eine statische IPv4-Adresse?
Gar nicht, ich habe eine statische IP Adresse. Das liegt einfach daran, dass mein Provider mich andernfalls in ein CGNAT stecken würde und da bringt dann auch keine Aktualisierung des Endpunktes was. Da hätte ich dann quasi final verloren.
Aber ich denke, dass man sich hier bestimmt über irgendwelche Scripts (z.B. per SSH) ohne größeren Aufwand eine automatische Aktualisierung bauen könnte.
Ansonsten funktioniert das ganze wie folgt:
Wir haben einen kleinen VPS mit einem eigenen /64 Netz - das lautet jetzt mal 2001:2002:2003:2004::/64. Da wir für unser Heimnetz (oder whatever) ein eigenes /64 brauchen, müssen wir das vom ISP dazu kaufen. Das sei jetzt mal als 2001:2002:2003:2005::/64 gegeben.
Unser Heimanschluss hat die statische IP 1.2.3.4 und unser VPS die 5.6.7.8
Wir legen uns ein Script an, was den Tunnel erstellen und löschen kann - der Inhalt ist eigentlich schon die halbe Miete. Wichtiger Hinweis noch: das Script geht davon aus, dass euer Interface am VPS eth0 heißt. Wenn es anders heißt, müsst ihr das ändern. Statt 6in41 kann für das Tunnel-Interface auch ein anderer Name gewählt werden - das muss dann halt im Script geändert werden.
#!/bin/bash
action=$1
case $action in
add)
ip tunnel add 6in41 mode sit remote 1.2.3.4 local 5.6.7.8 ttl 255 dev eth0
ip link set 6in41 up mtu 1480
ip addr add "2001:2002:2003:2004::1/64" dev 6in41
ip route add "2001:2002:2003:2005::/64" dev 6in41
;;
delete)
ip tunnel del 6in41
;;
*)
echo "Invalid action!"
;;
esacDas Script gehört im Optimalfall root:root und hat 700er Rechte.
Das ganz bastelt man sich dann noch in seine Netzwerkconfig rein...
auto eth0
iface eth0 inet static
address 5.6.7.8
netmask 255.255.255.255
pointopoint 172.31.1.1
gateway 172.31.1.1
iface eth0 inet6 static
address 2001:2002:2003:2004::1
netmask 64
gateway fe80::1
pre-up echo 0 > /proc/sys/net/ipv6/conf/eth0/accept_ra
post-up /opt/scripts/sit.sh add
pre-down /opt/scripts/sit.sh deleteUnd, sofern man eine iptables Firewall auf dem VPS hat, bindet man für IPv4 das hier ein:
/sbin/iptables -A INPUT -i eth0 -s 1.2.3.4 -d 5.6.7.8 -p 41 -j ACCEPTUnd für IPv6 das hier:
/sbin/ip6tables -A FORWARD -i eth0 -o 6in41 -d 2001:2002:2003:2005::/64,2001:2002:2003:2004::2 -j ACCEPT
/sbin/ip6tables -A FORWARD -i 6in41 -o eth0 -s 2001:2002:2003:2005::/64,2001:2002:2003:2004::2 -j ACCEPTWenn man das will kann man hier theoretisch gleich Firewalling fürs Heimnetz betreiben. In der Form wird aber einfach stupide alles weitergeleitet.
Die Konfiguration in der FritzBox sieht dann so aus:
Bildschirmfoto von 2020-11-15 14-35-27.png
Wo ich mir nicht sicher bin, weil es auf meinem Server per Default an ist (da VPN Gateway), sind die Forwarding Optionen vom Kernel des VPS. Ich vermute mal stark, dass man noch net.ipv6.conf.all.forwarding=1 setzen muss. IPv4 Forwarding sollte eigentlich nicht benötigt werden.
Bei mir läuft das in der Form so alles unter Alpine Linux 3.12 in der H-Cloud - aber das sollte eigentlich unter jeder Distro bei nahezu jedem Provider klappen, würde ich zumindest aus dem Bauch heraus sagen.
Könnt ihr das bitte bitte fixen?
Wie bereits im anderen Thread erwähnt... nein, wir können es nicht. Hierzu bitte den Netcup Support direkt kontaktieren. 
Könnt ihr bitte Roundcube auf eine sichere Version updaten, zu allermindest auf 1.2.12?
Nö, können wir nicht. Denn das ist ein Kundenforum und wir haben keinen Zugriff auf die Netcup Infrastruktur. 
Da musst du dich schon per Mail oder CCP an den Support wenden. 
So... ich habe mir jetzt erfolgreich einen eigenen 6in4 Tunnel Server gebaut. Das ganze funktioniert über SIT und ist total einfach. Ich erreiche jetzt fast 100% meiner nativen Bandbreite über IPv6 und die Latenz ist extrem runtergegangen.
Wenn Interesse besteht, kann ich gerne mal ein paar Zeilen dazu schreiben, wie das geht.
Dachte gerade ich sehe nicht richtig...
Das ist einer der beiden DNS Server, die mein ISP meinem Router per DHCP zuweist: https://www.shodan.io/host/217.17.207.132
Allein der OpenSSH Server ist laut Entwickler vom 31.03.2008. Und die CVE Liste ist gefühlt geschätzt 3 Kilometer lang.
Ich weiß ehrlich gesagt nicht, ob ich lachen oder weinen soll.
Zwei Szenarien:
1. Paket zu groß. Paket fehlt beim Empfänger. Paket wird nochmal angefordert.
2. Paket zu groß. Paket wird ausgepackt. Packet wird neu verpackt in zwei Pakete.Genau dieses Umpacken dauert ewig, weil es sehr aufwändig ist. Zudem muss das mit jedem großen Paket gemacht werden.
Ah verstehe... ich hätte nicht erwartet, dass die Fragmentierung derart lange dauert/aufwendig ist. Aber dann macht das natürlich Sinn.
Das sind halt wieder so Sachen, die einem keiner in der Berufsschule erklärt. :s
Bei Downloads von großen Dateien - hier gibt es dann Probleme mit der Geschwindigkeit. Ebenso bei iperf...
Naja - umso kleiner die MTU, desto mehr Pakete überträgt man und desto mehr Overhead in Form von Headern und Co. hat man... darauf läuft das doch hinaus, oder?
Solange keine MTU-Probleme auftreten, sicherlich!
Ich persönlich bin (außer in der Berufsschule in einer alten Prüfungsaufgabe bzgl. IPsec und künstlich erzwungenen no fragment) nie mit MTU Problemen in Kontakt gekommen...
Wann oder besser gesagt wie kann es denn passieren, dass man Probleme mit der MTU im produktiven Umfeld bekommen kann?
Also IPsec etc. klammer ich jetzt mal aus, weil man ja eher selten einen VPN Tunnel durch einen VPN Tunnel durch aufbaut.
Die Phishing Seiten werden durch den italienischen Hoster Aruba S.p.A. bereitgestellt.
Du kannst diese hier --> https://www.aruba.it/en/report-abuse.aspx melden.
Gibt es eigentlich außer den Telegramnews noch altmodische Mailinglists oder ähnliches für solche Bekanntmachungen?
Wäre mir nicht bekannt. 
Sehe ich nicht so. Bei meinen Minecraft Servern sehe ich immer sehr deutlich Auslastung auf mehreren Kernen, auch wenn ein Kern tatsächlich etwas mehr ausgelastet ist. Ich kann mir nicht vorstellen, dass man viel Spaß hat wenn man einen VPS mit 2 Kernen zu jeweils ~40-50% Steal hat und man dann viel herumläuft (Welt generiert) und/oder viele Tiere auf dem Server hat.
Das ist pures Glücksspiel gerade keinen Steal zu haben bei einem normalen VPS. Ich habe keine gute Erfahrung gemacht zu sehr daran zu sparen
Minecraft ist ein schlecht parallelisierter Java-Haufen, der primär viel Single Core Performance braucht. Da ist Steal dann das Todesurteil. Daher RS... machen wir auch so, mit gutem Grund.
Mittlerweile kann es zwar schon seine Last zum Teil auf mehrere Cores verteilen, aber nichtsdestotrotz geht es immer noch am stärksten auf einen einzelnen Kern bzw. Thread. Und da dann Steal... RIP
Für alle Mailcow Nutzer/Betreiber:
? Important security notice ?
Please update your mailcow instance as soon as possible due to a found vulnerabiliy.
What is affected?
The reason is a vulnerability where commands can be injected in an imapsync job by authenticated users.
Who is affected?
All instances updated before 6th of November 2020. This is most critical for shared or hosted mailcow instances with multiple users.
What is the fix?
This was addressed on 6th of November 2020 as part of this commit (https://github.com/mailcow/mailco…0f517c453df823b).
If you have further questions, please let us know in our Telegram group. More information will be disclosed approx. in the week of 16th of November 2020.
Hi,
ich glaube hier im Kunden Forum bist du damit an der falschen Adresse, weil wir als Community nicht das SCP entwickeln.
Damit bist du wohl beim Netcup Support besser aufgehoben.
Ich verwende Aegis. Das hat eine Zugangssperre (Fingerprint in meinem Fall), kann die Secrets (verschlüsselt) als Backup exportieren und ist Open Source.
In allen Belangen besser als GA (meine Meinung
Ich benutze diese App auch schon sehr lange und kann Sie nur wärmstens weiterempfehlen.
Das Abuse Formular von Aruba S.p.A. (dem Hoster, wo die ganzen Phishingseiten liegen) funktioniert wieder. --> https://www.aruba.it/en/report-abuse.aspx
Danke für den Tipp mit Mailcow. Ich habe es mir mal zum Testen in einer VM installiert. Da muss man ja echt nicht viel machen und hat direkt alles drin.
Richtig. Und wenn du da mal Hilfe brauchst, gibt es auf Telegram eine bzw. zwei Gruppen, wo man sich gegenseitig hilft oder sogar vom Entwickler Hilfe bekommt.
Wichtig ist hierbei nur zu Wissen, dass du mit einem eigenen Mailserver wie Mailcow auch selbst für die Zustellbarkeit verantwortlich bist. Ich denke da in Richtung Microsoft, aber das hast du ja vielleicht schon mitbekommen.
