Beiträge von gunnarh

    Vom Support wurde mit hierzu noch mitgeteilt:

    Zitat

    Unsere Entwicklungsabteilung ist informiert.

    Ob und wann das Problem gelöst wird kann ich Ihnen jedoch momentan nicht sagen.


    Für mich ist die Umstellung erledigt, wer eine .at Glue-Record-Änderung in nächster Zeit vor hat, sollte das evtl. vorab schon mal "probieren" solange der alte Server noch läuft, und nötigenfalls 1-2 Tage Zeit für eine allenfalls nötige Support-Ticket-Bearbeitung im geplanten Ablauf mit einkalkulieren.

    Danke eripek für deine Tests.

    Mal sehen was mein geöffnetes Ticket beim Support für Erkenntnisse liefert. Dass da wohl irgend ein API/Script-Problem vorliegt scheint mir mittlerweile recht klar zu sein. Danke für den Tipp mit dem Workaround über den kurzfristigen Wechsel zu den Netcup Nameservern, wenn der Support keine kurzfristig andere Lösung hat werde ich das demnächst auch so versuchen.

    Was Deinen Rant betreffend des Support angeht hast Du denke ich eine falsche Erwartungshaltung. Wenn Du zu einer Autovermietung gehst erwartest Du ja auch nicht, dass Dir diese bei Anmietung eines Fahrzeuges Fahrstunden gibt, um die Nutzung von Kupplung und Schaltgetriebe zu erlernen.


    Der Bedarf ein fertiges Image zu nutzen ergibt sich offenbar deshalb, weil Du Dir damit erhoffst mit geringerer Expertise ans Ziel zu kommen.


    Warum aber konkret willst du unbedingt LVM einsetzen? Welche Anforderungen sollen damit konkret bei euch gelöst werden?

    Customer Control Panel, Domains => DNS,

    ich betreibe meine Domain hitco.at seit Jahren mit drei Dual-Stack IPv4+IPv6 konfigurierten Nameservern.

    Hierzu verwende ich Glue-Records.


    Bedingt durch einen Systemwechsel änderte sich nun meine IPv4 Adresse des ns3.

    Im Webinterface kann ich das zwar eingeben, und wird auch angenommen und im CCP angezeigt, es schlägt sich jedoch nicht in die Datenbank von nic.at durch. Der Zeitstempel des Whois-Records ändert sich, aber die IP-Adresse die im Whois aufscheint und nach einem Reload der nic.at Nameserver weiterhin als Glue-Record aufscheint ist die alte IP-Adresse 23.97.171.64 und nicht die neue 51.116.232.243



    pasted-from-clipboard.png


    Ein Mail an den Support blieb bislang noch ohne Reaktion.

    Hat jemand von euch schon mal bei einer .at Domain die Glue-Records erfolgreich geändert?


    Bevor nun Hinweise kommen, ich solle doch X-stunden warten: Das ist mir bewusst. Mir sind auch die Zeiten bekannt wann NIC.at ihre Nameserver reloaded. Der aktuelle Glue-Record schafft es aber nichteinmal in die NIC.at Whois-Datenbank, und das geht "live".


    Als Workaround habe ich folgende Alternativen erfolglos versucht:


    Versuch die ns3 IPv4 zu entfernen (leer zu lassen):


    Fehler:
    Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Data management policy violation:
    Frame contains no update operation



    Versuch nur ns1 und ns2 anzugeben und ns3 vorläufig ganz wegzulassen (delete-Button):


    Fehler:
    Die Nameserver konnten nicht aktualisiert werden. Domain update at registrar failed. Command syntax error:
    Parser error at line [0], column [1871]: Element \'{urn:ietf:params:xml:ns:domain-1.0}hostAddr\': This element is not expected. Expected is ( {urn:ietf:params:xml:ns:domain-1.0}hostAttr ).


    Beide Fehlermeldungen erscheinen mir sachlich falsch. Ich vermute hier eher ein Problem mit der API die Netcup bei NIC.at benutzt.


    Meine Nameserver antworten autoritativ mit allen drei Servern:


    Die nic.at Registry hat weiterhin die alte ns3-IPv4 gelistet:

    Die nic.at Nameserver beinhalten weiterhin den falschen Glue-Record:

    Let's Encrypt wechselt seine Intermediate-CA.

    Wer seinen (SMTP-)Mailserver mit DANE / TLSA unter Verwendung der Let's Encrypt X3 CA gepinnt hat, sollte jetzt handeln und zumindest die R3-CA ergänzen:


    https://community.letsencrypt.…ng-le-issuer-certs/134172


    pasted-from-clipboard.png


    Derzeit ist bei den meisten vermutlich nur die X3-CA in Verwendung, folgende TLSA-Records empfiehlt es sich zu ergänzen:


    X3 _25._tcp.each.mx.host. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
    X4 _25._tcp.each.mx.host. IN TLSA 2 1 1 b111dd8a1c2091a89bd4fd60c57f0716cce50feeff8137cdbee0326e02cf362b
    E1 _25._tcp.each.mx.host. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
    E2 _25._tcp.each.mx.host. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
    R3 _25._tcp.each.mx.host. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
    R4 _25._tcp.each.mx.host. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03

    Mein OwnCloud-Client nervt mich seit ein paar Wochen alle paar Minuten mit der Nachricht, dass mein OwnCloud 10.3.2 Server veraltet wäre und ich doch auf 10.4.1 upgraden soll. Das klappt allerdings nicht, weil 10.4 nicht mehr auf PHP7.0 lauffähig ist und ich mich bislang nicht überwinden konnte auf meiner Ubuntu 16.04 LTS Maschine eine neuere PHP-Version aus einem Fremd-Repo zu installieren.


    Gut... Heute Regenwetter - dann mach ich das mal.

    Eine Stunde später, PHP 7.4 mit allen Modulen die ich auch unter 7.0 genutzt habe läuft.

    Ich will das OwnCloud-Update machen => und .... Fehlermeldung 7.4 wird nicht unterstütz.


    Freilich könnte man die Systemanforderungen auch vorher lesen. Aber was solls... jetzt habe ich mir eine unstable Owncloud 10.5 Beta 2 draufgebügelt, auf PHP 7.3 downgraden tu ich mir jetzt auch nicht an wegen der paar Wochen bis OwnCloud 10.5 production stable ist.

    Wie viele Stunden pro Monat soll diese Windows-VM denn eingeschaltet sein? Wenn da nur eine Banksoftware darauf läuft, dann ja eventuell nur wenige Stunden pro Monat?


    Die Windows-10-VM wirst du bei Netcup soweit ich das beurteile leider nicht korrekt lizenzieren können. In der hauseigenen Cloud des Betriebssystemherstellers (Az...) ist das Windows-OS bereits in den Kosten für die VM-Laufzeit enthalten. Sofern die VM nur wenige Stunden pro Monat benötigt wird (z.b. nur 10% der Zeit des Monats läuft) und den Rest ausgeschaltet verbleibt, ist der Betrieb dort sogar günstiger als eine kleine VM hier den vollen Monat Laufzeit zu bezahlen. Und da bereits angesprochen wurde, dass es sinnvoll ist ein Windows hinter eine Firewall zu packen: Die VMs in der Cloud des Betriebssystemherstellers hängen standardmäßig hinter einem Load-Balancer der nur freigeschaltete Ports (z.B. RDP) weiterleitet. (Sorry dafür, dass ich hier ausnahmsweise nicht zu Netcup rate, aber Windows 10 und Netcup, das geht meiner Meinung nach rechtlich nicht sauber - daher sehe ich da, solange Netcup kein geeignetes Angebot ins Sortiment aufnimmt - keine andere Lösung).

    Du meinst diese Fehlermeldung?


    IP des Nameserver ns1.box.domain.tld im falschen Format. Bitte geben Sie die IP des Nameservers als IPv4 oder IPv6 an.


    Sind die beiden Nameserver korrekt autoritativ für die Zone box.domain.tld konfiguriert und antworten?
    Ist die Schreibweise der IPv4 und/oder IPv6 korrekt? Gerade bei IPv6 gibt es da ja mehrere Varianten - hier meine Settings mit IPv4 + IPv6 Glue-Records:


    2020-05-13 20_50_55-netcup ccp und 3 weitere Seiten - Gunnar – Microsoft​ Edge.png

    Die Formulierung "access it remotely" bzw "remote User" bezieht sich nicht darauf, ob man mittels eines Netzwerkprotokolls wie RDP zugreift, sondern auf den physischen Standort des Blechs auf dem die VM läuft. Und für "zuhause" gilt ohnehin "wo kein Kläger da kein Richter". Man kann jedoch kein öffentlich von Netcup beworbenes Produkt basierend auf einer nicht korrekt lizenzierbaren Softwarelösung anbieten, dieses Risiko würde ein seriöses mitteleuropäisches Unternehmen wohl kaum eingehen. Und wie gesagt: Es gibt ja Lösungen dies zu lizenzieren, nicht aber für den Endkunden sondern für den Serviceprovider.

    Die Windows 10 Lizenzbestimmungen untersagen es folgendes zu tun:

    install the software on a server and allow users to access it remotely, or install the software on a device for use only by remote users


    Microsoft sieht die Installation von Win10 auf einem Server der nur remote genutzt wird als VDI Lösung - mit einer Retail-Version von Windows kann man dies meines Wissens daher nicht korrekt lizenziert betreiben.

    Im heutigen Thread nebenan "Anfänger sucht hilfe ^^ (Windows 10 Server)" ging es heute ja wieder rund. Da versuchte ein Neuling Win10 Home auf einem NetCup vServer zu betreiben.


    Der Thread-Hersteller hat eingesehen die VM herunterzufahren und zu kündigen... alle sind happy.


    Alle? Nun ja - eigentlich nicht, denn bei genauerer Betrachtung wurde der Thread-Ersteller vergrault und Netcup hat einen Kunden verloren.

    Ich frage mich, ob das so sein muss?

    Das meine ich jetzt nicht in Bezug auf jene die hier im Thread beraten haben - sondern ich stelle mir ernsthaft die Frage, ob es für den Bedarf des Thread-Erstellers nicht ein Produkt-Angebot geben kann.


    Was müsste passieren, damit man tatsächlich eine Windows 10 VM bei NetCup mit wenig Aufwand "mieten" und betreiben könnte.

    1. Es bräuchte VMs die über keine öffentliche IP-Adresse verfügen sondern zumindest über ein NAT geroutet werden und Incoming-Connections unterbunden werden

    2. Die Bandbreite sollte vielleicht zur Sicherheit auf ein auch für den Home-Betrieb gängiges Maß von z.B. 100MBit reduzierbar sein

    3. Eine Firewall die ungewöhnlichen Traffic der auf BotNet etc... hindeutet sollte die VM abschirmen


    1-3 sind technische Komponenten, die man mit gängiger Hard- oder Software jedoch seitens NetCup für dieses Produktangebot bereitstellen könnte.


    4. Die Lizenzfrage wäre zu klären. Es gibt keinen legalen Weg Windows 10 auf einer Netcup VM zu installieren. Diesen Weg könnte nur NetCup selbst ebnen, indem es VMs mit Windows-OS-Lizenz die über ein Microsoft Service Provider Licensing Agreement (SPLA) lizenziert sind anbietet


    Ist soetwas angedacht?

    Wenn nein, warum nicht? Zu hoher Aufwand? Kein Interesse seitens NetCup? Will man dieses Kundensegment bewusst nicht bedienen sondern anderen überlassen?

    Um die Auswertung für uns leichter zu machen, ersuchen wir euch, diesen Thread ausschließlich für das Feedback von Bugs zu nutzen.

    Gibt es einen separaten Thread für Feature-Wünsche?


    • Habe zwar zur Kenntnis genommen, dass es nicht eure Absicht ist in der App auch einen aktuellen Konsolen-Screenshot anzuzeigen - hätte einen solchen aber dennoch gerne und wüsste auch nicht warum das technisch anspruchsvoll wäre (im SCP bekomme ich ja in der Desktop-Ansicht in der Zusammenfassung auch einen angezeigt).
    • Und wie bereits erwähnt fehlt mir der Mehrwert den diese App mir hier bereitstellen soll. Für all das was aktuell hier an Möglichkeiten skizziert wurde brauche ich die App nicht, das geht mit der mobilen Website bereits genauso ohne eine App installieren zu müssen. Ich würde daher tatsächlich gerne irgendwo einen Ausblick haben welche Möglichkeiten man mit der App zukünftig unterstützen möchte, welche mit der (mobilen) Website nicht oder nur ungenügend adressiert werden können.
    • Stichwort "Monitoring" => ein tatsächlicher Mehrwert wäre es z.B. wenn mich die App benachrichtigen würde, wenn konfigurierbare Schwellwerte des Servers überschritten wurden.
    • Weitere Notify-Wünsche
      • wenn z.B. im SCP wieder mal neue Hinweise wie "neue KVM Version verfügbar, Server hierzu rebooten" oder ähnliches auftauchen, wäre es nett wenn die App mich hierüber aktiv notifiziert (ohne in die App einsteigen zu müssen)
      • wenn Wartungstätigkeiten oder Restarts geplant sind (z.B. wie letztes Jahre im Zuge der Spectre/Meltdown-Patches) würde ich mir erwarten das mich die App hier live notifiziert.
      • Man hätte über die App endlich einen von E-Mail unabhängigen Kommunikationskanal um in Echtzeit Aktivitäten die Server betreffend zum Kunden zu pushen.

    Mir erschließt sich die Notwendigkeit und der Vorteil den diese App bieten soll derzeit (noch) nicht.

    Das https://www.servercontrolpanel.de/ funktioniert völlig zufriedenstellend auch am Smartphone in der mobilen Ansicht im Browser, das Design ist responsive und die Bedienung OK.


    Worin soll der Vorteil bestehen sich die App zu installieren? Der Funktionsumfang ist geringer. Momentan merkt sich die App leider nicht einmal die Zugangsdaten - im Browser kann ich die Daten wenigstens mittels Passwort-Manager automatisch befüllen.


    Habe die App kurz durchgeklickt, folgendes Feedback hierzu:

    • Die Traffic-Anzeige in der App meint Traffic aktueller Monat 118GB, im servercontrolpanel.de sehe ich hingegen 149,31 angegeben. Bei gleicher Datenbasis erscheint mir das doch bemerkenswert.
    • Die Möglichkeiten der Steuerung sind in der App nicht die gleichen wie im servercontrolpanel.de, die App stellt weniger bereit.
    • Statistiken: Die Skalierung bzw. Skala der X-Achse ist etwas merkwürdig. Man würde doch erwarten, dass das Grid einen Stundenraster abbildet und nicht irgendwelche krummen/unerwarteten Werte.
    • Konfigurationsmöglichkeiten die im servercontrolpanel.de existieren (HDD, CPU Sockets etc...) existieren in der App nicht. Unterwegs am Smartphone brauche ich diese allerdings auch nicht - in der mobilen Version des SCP wären diese jedoch vorhanden.
    • Eine Konsolen-Ansicht stellt die App leider auch nicht bereit. Auch in der mobilen Ansicht des servercontrolpanel.de gibt es leider keine Konsolen-Ansicht. Dass man am Smartphone eher kaum zuverlässig die Konsole bedienen wird können ist mir klar - aber zumindest einen aktuellen Screenshot der Konsole würde ich gerne sehen (und zwar sowohl in der App, als auch in der mobilen Ansicht des servercontrolpanel.de)

    1. Ich fragte nach der tatsächlichen Netzwerk-Konfiguration die aktuell wirksam ist, Du hast uns aber lediglich config-Files gezeigt. Ein "ip addr show eth0" wäre hilfreich.


    2. Ich fragte nach der Routing-Table, Du hast uns nur deine IPv4 Routing-Table gezeigt, gemeint habe ich freilich die IPv6 Routing Table, also z.B. "route -6 -n"