Beiträge von gunnarh

    Alle Dateien die mit "dovecot-..." starten kann man ignorieren, das sind nur Verwaltungsinformationen/Indizes etc...

    Die eigentlichen Mails haben leider nicht die Dateiendung .eml -> würde einfach ein kleine Script schreiben, das alle Dateien auf .eml umbenennt. Diese kann man dann einfach per drag&drop in Thunderbird hineinziehen und so importieren bzw. wieder per imap auf den Server laden.


    Wenn man sich umfangreiche Ordnerstrukturen angelegt hat müsste man das für jeden Ordner tun, oder doch recherchieren ob es ein komfortableres Import-Tool gibt.

    MTA-STS ist furchtbar,

    Habe MTA-STS zwar erst seit ein paar Tagen laufen, bis auf hardenize.com und ein weiterer MTA-STS Validator den ich manuell die Einträge prüfen habe lassen jedoch exakt 0 (in Worten: Null) Zugriffe. Mein Server ist MTA/MX für ca. 30 Mail-Domains, ca. 500 eingehende/angenommene Mails pro Tag.

    Der Xeon Gold 6140 ist mit Speed Shift ausgestattet.

    Es gibt daher keinen Grund sinnlos Wärme zu produzieren und die Nutzbarkeit der benachbarten Cores zu senken. Dank Speed Shift wirst Du auch bei nur kurzzeitiger Single-Threaded Last kaum bemerken, dass die CPU erst im Bedarfsfall "hochgetaktet" wird.

    Zur Umzugs-Timing-Sache:

    Wenn es nur darum geht den Registrar zu wechseln, und die Nameserver erhalten bleiben, dann ist die Sache relativ easy. Die Nameserver sind 2min nach der Registrierung bei NetCup schnell wieder eingefüllt. Und man müsste schon extremes Pech haben, wenn der Zone-Reload der TLD genau in diesen 2 Minuten erfolgt. Wer auf Nummer sicher gehen will schaut vorher eben noch nach, zu welchen Zeiten die Nameserver der TLD konkret reloaded werden und führt den Vorgang zwischen zwei Reloads geplant durch.


    Wenn auch der Nameserver-Anbieter zu NetCup gewechselt wird, dann kann das freilich etwas mehr "geklicke" bedeuten. Aber auch hier würde ich meinen, das man das zwischen zwei Reloads hinbekommt (vorausgesetzt wir sprechen hier von 10-20 Records, und nicht von 1000). Hier würde ich aber im Vorfeld tatsächlich die Reload-Zeiten recherchieren.


    Was DNSSEC angeht: Um sich hier nicht ins Knie zu schießen würde ich rechtzeitig vor dem Transfer die DS-Records noch beim alten Registrar entfernen (also z.B. 48h vorher) und erst nach erfolgtem Umzug die neuen DS-Records wieder eintragen.

    Warum sollte Netcup die Install-Images für WS2012 und WS2016 allen Kunden zugänglich machen, wenn sie sie dann nicht nützen dürfen?


    Meine Meinung zur Windows-Lizenzierung habe ich vor ein paar Wochen hier in einem Thread nebenan gepostet.


    Die NetCup AGB sagen hierzu:

    Zitat
    Bei der Überlassung von Fremd-Software (auch open-source-Software) hat der Kunde die Lizenz- und Nutzungsbedingungen des Herstellers zu beachten.

    Mit dem Installationsmedium ist es nicht getan.


    Du würdest Nested Virtualiziation benötigen. Suche mal hier im Forum mit diesem Stichwort, dann wirst Du Beiträge finden das der Support dies gegen Aufpreis auf manchen Servertypen aktivieren kann.


    Die Nutzung einer Windows Server Testversion in einem produktiven Rechenzentrum ist rechtlich fraglich, lies Dir lieber die Produktnutzungsrechte durch - ich gehe davon aus, dass dies nicht erlaubt ist. Ich würde Dir daher empfehlen dir z.B. einen Test-Account beim Cloud Dienst von Microsoft (Name "Axxxx" hier aus Gründen der Forenregeln nicht nennbar) anzulegen und dort eine VM mit Windows Server anlegen zu lassen. Da musst Du gar nicht erst selbst installieren sondern bekommst das fertig und gepatcht vorinstalliert, und die Lizenz ist im Mietpreis inbegriffen. Der Test-Account bei Axxxx sollte dir einige kostenfreie Betriebsstunden ermöglichen (insbesondere wenn Du die Maschine nur dann hochfährst wenn Du damit "übst" kommst Du sicherlich auch wochenlang über die Runden). Axxxx dürfte Nested Virtualization unterstützen.

    Trotz intensiver Verhandlungen unsererseits mit der nic.at, erkennt sie nicht die Vorteile von Aktionen mit dauerhaften Preissenkungen.

    Dazu kann man vielleicht erklärend anmerken: Die Erlöse der nic.at dienen zur (Quer-)Finanzierung anderer Themenbereiche der Internet Privatstiftung Austria (IPA), so zum Beispielt des cert.at und anderer Aufgaben die andernfalls hier (vermutlich) aus Steuermitteln finanziert werden müssten.

    Ginge bei der Gelegenheit auch gleich 15 und 16? Ich muss gestehen, ich bin ein großer Fan von Ed25519 :P

    Siehst Du hier jetzt im Jahr 2018 schon einen praktischen Einsatz-Zweck?

    Ich orientiere mich bei der Verwendung von DNSSEC Algorithmen gerne am Verbreitungsgrad der unterschiedlichen BIND-Versionen und deren Fähigkeiten. Für Ed25519 würde man Bind 9.12 benötigen, der ist denke ich in keiner Stable-Distribution aktuell bereits enthalten. Somit wird es bis zu einer praktischen Relevanz vermutlich noch mindestens 2 Jahre brauchen, für eine solide Verbreitung eher noch länger. Bis dahin müsste man zumindest zwei Algorithmen parallel verwenden, da #15 von keinem Resolver verstanden werden wird.

    kerberos da lest man ja Sachen, dachte immer daß der SSL/TLS-Handshake und so vom Programm gemacht wird und das OS darauf keinen Einfluß hätte ob jetzt TLS1.0, 1.2 od. sonstwas zum Zug kommt ...:/

    Der TLS-Handshake wird zwar von der Applikation gemacht - somit außerhalb des Einflussbereiches des Betriebssystems. Allerdings nutzen diverse Applikationen hierzu die von Windows bereitgestellten Schannel SSP Bibliotheken. Es hängt also von der Applikation (im angesprochenen Fall vom Browser) ab, ob die Entwickler die Betriebssystem-Bibliotheken nutzen oder hierfür eigenen Code mitbringen.

    Die Aktivierbarkeit der Lizenz als Indikator für Legalität zu betrachten ist nicht zweckmäßig.

    Hier ein Artikel eines Microsoft Österreich Verantwortlichen zu diesem Thema: https://windowsblog.at/2016/09…tsch-original-um-390-eur/


    Mir ist übrigens keine Möglichkeit bekannt, wie man ein Windows 10 in einer VM eines IaaS Anbieters korrekt lizenziert betreiben könnte. Konkret verstößt man da nämlich gegen die PUR (Product Use Rights) (siehe https://www.microsoft.com/en-u…roduct-licensing/products) die in Bezug auf Desktop-Betriebssysteme folgendes besagen:

    Zitat

    Der Kunde ist je erworbener Lizenz berechtigt, eine Kopie der Software auf einem Lizenzierten Gerät oder innerhalb eines lokalen virtuellen Hardwaresystems auf einem Lizenzierten Gerät zu installieren.

    Die Lizenz in einer VM in einem Rechenzentrum zu installieren ist nicht "lokal virtuell". Und auch die anderen Spielarten die erläutert werden (Remote-Verwendung, typische VDI Szenarien) sind meines erachtens in dieser Konstellation nicht erfüllt. Studentenlizenzen schließen übrigens gar keine Virtualisierungsrechte mit ein (siehe Anhang H). Meiner Auffassung nach wäre die einzig korrekte Lizenzierungsmöglichkeit ein Microsoft Services Provider License Agreement (SPLA) - das müsste aber der Service-Provider (in diesem Fall Netcup) anbieten.

    janxb - die Foren-Regeln (die ich jetzt ad-hoc hier nirgends finden konnte?) untersagen meines Wissens das Diskutieren von Konkurenz-Angeboten hier in diesem Forum. Dass das ein mehrfaches des Preises von Netcup kostet ist korrekt, allerdings nicht 3-stellig, eine Single-Core-VM geht sich auch um ca. 40-50 Euro pro Monat aus, und wie gesagt, da ist die Lizenzierung mit dabei - und eine korrekt lizenzierte Windows Server VM kostet mindestens einen höheren dreistelligen Einmal-Betrag, wenn Client-Access-Lizenzen noch dazukommen auch deutlich vierstellig. Das relativiert dann die laufenden Kosten doch wieder erheblich.

    Hätte ich diese Anforderung würde ich - auch wenn Netcup dies in seinem Forum hier vermutlich nicht gerne hört - zu einem anderen Anbieter raten. Der Hersteller von Windows kann in seinem hauseigenen Cloud-Dienst eine Installierbarkeit mittels weniger Mausklicks anbieten, die Betriebssystem-Lizenz ist im Compute-Preis gleich inklusive und eine Firewall vor der Maschine ist auch schon mit dabei.

    Wie lautet Deine Frage?


    Dein Server kann ganz offenkundig keine der konfigurierten Paketquellen erreichen.

    Die Namensauflösung klappt scheinbar noch korrekt, der Zugriff aber nicht.


    Was hast Du schon geprüft? Klappt ein manueller Zugriff mit Lynx o.ä. oder wie kommt die Diagnose wonach "apt-update" ein Problem hätte zustande? Ich sehe ohne weitere Details eher ein Netzwerk-Problem (z.B. kein Default-Gateway konfiguriert o.ä.).

    Nachdem ich das vLAN derzeit nicht produktiv benötige werde ich wegen der (derzeit) bescheidenen Performance nicht nachstochern - aber eventuell hängt die Performance ja davon ab wie "nahe" die Maschinen beinanderstehen (im besten Fall vielleicht sogar am selben Host liegen, oder am selben Switch hängen).

    Mein Performance-Test des Cloud-vLAN Free mit iPerf zeigt mir nur einen eher enttäuschenden Throughput von 15MBit/sec.

    Code
    ------------------------------------------------------------
    Client connecting to 192.168.200.100, TCP port 5001
    TCP window size: 85.0 KByte (default)
    ------------------------------------------------------------
    [  3] local 192.168.200.200 port 36589 connected with 192.168.200.100 port 5001
    [ ID] Interval       Transfer     Bandwidth
    [  3]  0.0-10.2 sec  18.8 MBytes  15.4 Mbits/sec

    Fein, dass meine vorgeschlagene socat Lösung den Zweck nun erfüllt.


    Betreffend der Aussage:

    Zitat

    Wenn auf der externen Arbeitsstation ein VPN-Client läuft und sich mit dem Server verbindet, bekommt er eine IP aus demselben Netz.


    Wenn die zugreifenden Clients einen VPN-Client nutzen könnten, dann bräuchte man überhaupt kein DNAT, sondern Windows-Server und Clients könnten direkt miteinander kommunizieren. Das war aber in der ursprünglich diskutierten Variante keine Option und im weiteren Diskussionsverlauf explizit ausgeschlossen.

    mainziman Die Route die der VPN-Client am Windows-Server automatisch konfiguriert ist lediglich eine für das 10.8.0.0/24 Netz. Durch das DNAT am Linux-VPN-Server ändert sich die Source-IP-Adresse nicht. Aus Sicht des Windows-Servers kommt da eine Verbindung mit einer öffentlichen IPv4 Source-Adresse daher. Wenn er auf diese antworten möchte, dann geht das nicht durch die 10.8.0.0/24er Route zum Linux VPN-Server zurück sondern geht über die öffentliche Internet-Anbindung direkt hinaus ins Web (mit unerwarteter Source-IP-Adresse des Windows-Servers, nämlich seine im Internet vom Carrier Grade Nat verwendete Adresse). So wird das aber nichts, denn selbst wenn diese Pakete das Ziel erreichen sollten werden sie dort mangels Zuordenbarkeit zu einer bestehenden IP-Verbindung verworfen.


    Ich sehe daher mehrere Lösungsmöglichkeiten:

    a) nicht nur DNAT sondern auch SNAT am VPN-Linux-Server

    b) viel einfacher gleich wie von mir bereits erwähnt mit "socat" arbeiten und die Verbindung am Linux-Server terminieren.