Beiträge von gunnarh

  • php wird auskommentiert

    Ja, als ich schrieb "Falls der Webserver nicht ohnehin schon so vorkonfiguriert ist, dass er dann impressum.php ausliefert ..." meinte ich Optionen wie MultiViews. Wer so etwas bereits aktiviert hat braucht meinen RewriteRule-Vorschlag also eventuell gar nicht. Persönlich habe ich gerne mehr Kontrolle darüber wie Apache das genau macht und verwende daher bevorzugt RewriteRules. Aber manche Leute stehen mit Regular Expressions und insbesondere Apache RewriteRules auf Kriegsfuß, denen ist vielleicht MultiViews lieber.

  • php wird auskommentiert

    Man verlinkt weder .html noch .php Dateien.

    Links setzt man stets auf technologie-neutrale URLs. Wenn die Datei also impressum.php heißt dann nur "impressum".


    Falls der Webserver nicht ohnehin schon so vorkonfiguriert ist, dass er dann impressum.php ausliefert hilft folgende generische Rewrite-Rule in der .htaccess-Datei oder vHost Konfiguration:


    Apache Configuration
    RewriteEngine on 
AddType application/x-httpd-php .php
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME}\.php -f 
RewriteRule ^(.*)$ $1.php [NC,L]

  • SCP Zugang für Unterkunden?

    Nein, aber Du kannst Dir ein kleines Verwaltungs-Panel mit den von Dir gewünschten Funktionen über die von NetCup bereitgestellte API selbst programmieren und dies dann authentifiziert Deinem Kunden bereitstellen. Vielleicht gibt es hier im Forum ja jemanden der soetwas schon umgesetzt hat und seinen Source teilen möchte.

  • Auf größeren Server upgraden - Leider doch nicht so einfach

    Andere Frage: Wie erstellst Du denn derzeit Dein Backup?


    Was würdest Du denn tun, wenn Dein Server heute unerwartet "crasht" (z.B. defektes Host-System, Disk-Image beschädigt, nicht mehr zu retten).

    Dann müsstest du ja aus Deinem Backup auch irgendwie Bare-Metal-restoren?


    Ich sichere z.B. mit VEEAM auf einen bei einem anderen Anbieter liegenden CIFS-Storage.

    Restore funktioniert durch Einlegen des VEEAM.iso Image und mount des CIFS-Storage + entsprechender Wartezeit. Letzteres teste ich ab und an mal in einer VM zuhause.

  • Auf größeren Server upgraden - Leider doch nicht so einfach

    Ich teile die Enttäuschung darüber, wie Netcup das mit den SnapShots löst. Also das Erstellen eines Snapshots nur dann zulässt, wenn <50% des Disk-Image-Files aus Sicht des Hypervisors belegt sind.


    Mir ist schon klar, dass ein CopyOnWrite-basierter Snapshot dazu führen KANN, dass im Worst-Case tatsächlich doppelt so viel Speicher benötigt wird wie aktuell belegt ist.


    ABER: Dieser Worst-Case würde ja nur eintreten, wenn man nach Erzeugen des SnapShots tatsächlich alle vorhandenen/belegten Blöcke verändert.


    Meist möchte man einen Snapshot anlegen, weil man für ein paar Stunden ein "Sicherheitsnetz" möchte (z.b. OS-Update). Oder weil man wie von Dir hier skizziert ein Image exportieren möchte. In diesen Fällen ändern sich aber keine 100% der Blöcke sondern nur wenige Prozent.


    Auch ich würde NetCup daher ersuchen hier eine bessere Lösung zu finden.


    Vorschlag:

    * Es müssen 15% (nicht wie bisher 50%) des Speichers frei sein

    * Wenn nach Erstellung des Snapshot die Belegung insgesamt (VHD + Snapshot) sich der Gesamtkapaziät nähert soll eine Warnung erfolgen.

    * Von mir aus kann - wenn die Gesamtkapazität erreicht ist - auch der Snapshot automatisch aufgelöst oder der Server nach entsprechender Vorwarnung gestoppt werden.


    => Wäre jedenfalls alles besser als der aktuelle eher unbrauchbare Status-Quo.

  • Das längste Thema

    Netcup bietet doch gar keine "Hoster-Firewall" (was auch immer das sein soll?).

    Wenn Du "Host-Firewall" meintest solltest Du noch einmal einen Moment inne halten und darüber nachdenken, wie Du einen root davon abhalten möchtest die einfach zu deaktivieren.

  • Wechsel der IP-Adresse des Glue-Record bei .at Domain wirkt nicht

    Nur zwecks Dokumentation.... das von mir hier vor fast zwei Jahren beschriebene Problem vom Oktober 2020 ist weiterhin in identischer Form vorhanden.


    Wurde also in den letzten zwei Jahren leider NICHT gelöst.

    Ich habe abermals ein Support-Ticket eingebracht, bislang keine Antwort - rechne auch mit keiner da ich inzwischen einen Workaround gefunden habe.


    Da ich diese Woche abermals 2x meine GLUE-Records der .at Domain anpassen musste (Übersiedelung auf neue Server) konnte ich folgenden Workaround "erarbeiten" und als funktionstüchtig validieren. So entgeht man diesem Bug:


    Vorbereitung: Nachschauen wann die NIC.at Reload-Zeiten sind, sich einen Zeitpunkt suchen zu dem kein Reload stattfindet (Die Reloads finden zu festgelegten Zeiten zur vollen Stunde statt, wenn man den Vorgang also um xx:20 durchführt dann hat man jedenfalls 40 Minuten Zeit bis zum nächsten potentiellen Reload der .at Zonen). Derzeit findet der Reload laut nic.at zu folgenden Zeiten statt: Unsere Reload-Zeiten sind um 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ) [Anmerkung: Jetzt im Sommer ist es getesteter Weise MESZ und nicht MEZ, oder einfacher ausgedrückt: Zeitzone Vienna].


    Weiters Vorbereitung: Wer DNSSEC benutzt notiert sich vor dem Umschalten die hierfür nötigen Parameter, damit man diese nicht erst nach dem Zurückschalten auf eigene Nameserver dann erst mühsam neu recherchieren werden müssen. Die DNSSEC-Parameter lassen sich nach dem Zurückschalten auf eigene Nameserver erst nach dem Speichern wieder eingeben.


    1. Im CCP bei der .at Domain von eigenen Nameservern auf die Netcup Nameserver umschalten und speichern (man muss dazu nichts befüllen, einfach umschalten und ohne zu befüllen auf speichern drücken reicht aus).

    2. Whois der eigenen .at Domain prüfen - nun sind die Netcup-Nameserver eingetragen, technisch wirksam würde das erst zum nächsten nic.at Reload-Zeitpunkt

    3. Nun wieder auf eigene Nameserver im CCP umstellen und die Daten vollständig neu eintippen, speichern

    3b. Optional: Falls DNSSEC benutzt wird, nun auch diese Daten eingeben und speichern (ist erst nach Speichern der eigenen Namserver-Namen + GlueRecords möglich)

    4. Whois prüfen ... voila - sofort übernommen. Die eigenen Nameserver mit den nun hinterlegten GLUE-Records scheinen im WHOIS auf.

    5. Abwarten bis zum nic.at Reload, dann werden die glue-Records in die .at Zone übernommen.

  • DKIM wird von mail testern moniert

    Zitat von mainziman

    seltsame Probleme ...

    (-2 points) Your "from" domain does not match your DKIM "from" domain or does not have DKIM signing.

    (-1 points) The DKIM signature is not from the author's or envelope-from domain.

    (ist doch logisch, wenn man f. alle Domains das selbe verwendet ...)

    Warum verwendest du für alle Domains "das selbe"?

    Wenn du OpenDKIM einsetzt ist "SigningTable" und "KeyTable" das Stichwort dies zu lösen. Selbst wenn du für alle das gleiche Schlüsselpaar verwendest, die Config hierfür sollte schon "pro Domain" erfolgen. Kann man für alle Postfix "local-host-names" (das können in einem Multi-Domain-Setup ja auch sehr viele sein) freilich auch automatisiert generieren.

  • Das längste Thema

    Notiz an mich selbst: Server Upgrade / Produkt-Wechsel ... auf größere Disk: LVM und Filesysteme nicht vergrößern


    Nachdem ich nun zwei meiner Server Upgegraded habe (was auch eine größere virtuelle Disk mit sich bringt) wollte ich mich eigentlich gerade daran machen die Partitionen zu vergrößern und den zusätzlichen Speicher nutzbar zu machen.


    ABER: Ich habe davon jetzt doch Abstand genommen.


    GRUND: Ich betreibe meine Server fast immer mit Snapshot. Das hat bei Netcup ja bekanntlich zur Folge, dass ich ohnehin nur 50% der Disk belegen darf, sonst kann ich im SCP keinen Snapshot mehr anlegen.


    Somit kann ich aber im Filesystem von bisher 240GB ohnehin nur 120GB belegen. Der neue Produkttyp hat 320GB Disk, also 80GB die ich vergrößern könnte. Da ich aber ohnehin nicht mehr als 160GB belegen darf um einen Snapshot zu erzeugen und mein aktuelles Filesystem 240GB bietet ergibt sich aus einer Vergrößerung der Partition / LV / FileSystem kein Mehrwert ... somit: Aktion nicht durchführen.

  • Das längste Thema

    Ich antworte mir nochmals selbst:


    Nachdem ich vorhin schon einen VPS per Upgrade testweise über das CCP umgestellt habe und dies tatsächlich nur 1min gedauert hat, habe ich nun auch meinen angesprochenen "RS 500 SAS G7SEa1" aus dem Jahr 2016 auf den nächstgrößeren "RS 1000 SAS G7SEa1" upgedatet.


    Der Vorgang war in unter 30 Sekunden Downtime erledigt. Ich hab parallel dazu im SCP auf den Server geklickt, da war er auch schon runtergefahren und für ca. 10sek nicht mehr steuerbar ("Die Server Einstellungen werden geändert") ... und dann war er auch schon wieder gestartet und hat gebootet.


    Somit haben ziemlich sicher alle 6 von mir gestellten Annahmen zugetroffen. Ein Verschieben dieser mehr als 100GB großen VM ohne Vorbereitung auf einen anderen Host ist in 30 Sekunden nicht machbar, dazu müsste - sofern das überhaupt möglich wäre - das Disk-Image auf einem Storagesystem liegen (was soweit wir wissen ja eher nicht der Fall sein dürfte).


    Und noch ein weiters Indiz dafür, dass der Host gleich blieb: Die SCP-Statistiken sind durchgängig vorhanden. Wenn die VM auf einen anderen Host verschoben wird sind diese grafischen Statistiken erfahrungsgemäß dann gelöscht und beginnen neu.


    Vermutung: Das ging mit ca. 30 Sek Durchführungszeit ja gar schnell, könnte damit Zusammenhängen, dass ich unmittelbar davor noch eine "Storage Optimierung" durchgeführt habe.

  • Das längste Thema

    Zitat von m_ueberall

    Ich habe nie ein Downgrade vorgenommen, würde aber meinen, es gibt nur drei Möglichkeiten:

    1. Wenn der genutzte Plattenplatz größer ist als die neue virtuelle Größe des Speichermediums, wird das Downgrade blockiert, bis der Nutzer eine entsprechende Verkleinerung vorgenommen hat
    2. Wenn der genutzte Plattenplatz kleiner ist als die neue virtuelle Größe des Speichermediums, wird bei Erkennen des Dateisystems automatisch eine Verkleinerung durchgeführt (halte ich für weniger wahrscheinlich, da das immer mit einem Restrisiko verbunden ist)
    3. Der in der Zielkonfiguration nicht mehr "unterbringbare" Speicherplatz wird tatsächlich verworfen (würde ich auch als eher unwahrscheinlich ansehen, auch wenn im Falle einer automatischen Anpassung mit Sicherheit ein explizites Einverständnis eingefordert wird)

    Gibt es hierzu noch keine Erläuterung im Wiki (habe nicht nachgesehen)? Das wäre ggf. einmal eine Ergänzung wert.

    Im Wiki ist keine meiner Fragen zum Upgrade erläutert.

    Und die Frage nach einem Dowgrade wie das bei der Disk technisch umgesetzt ist schon gar nicht.


    Die "Zustimmen" Häkchen sehen genauso aus, also keinerlei Hinweis auf Disk-Shrinking mit Datenverlust.

    Ein automatisches-Disk-Shrinking "bei erkennen des Filesystems" würde ich als Anbieter niemals durchführen, das hat hohes Potential schief zu gehen und wäre in meinem Fall (LVM) vermutlich zum Scheitern verurteilt.

  • Das längste Thema


    Ich beantworte mir meine Fragen mal selbst.

    Nachdem ich neben dem Server der mir heilig ist, und den ich upzugraden gedenke noch einen zweiten im Portfolio habe um den es mir nicht ganz so schade ist, habe ich so einen CCP Produkt-Upgrade-Vorgang soeben mit diesem Zweitserver "geübt" und kann berichten:


    Nach Betätigung des Buttons "Upgrade durchführen" wird der Server sofort heruntergefahren.

    Im SCP wird dann für ca. 1min bei Auswahl dieses Servers nur "Die Server Einstellungen werden geändert" angezeigt.

    Danach starte der Server wieder.


    Ich kann 1 + 4 + 5 + 6 somit bestätigen.

    Und ich vermute auch 2 + 3 treffen zu, da ein verschieben des Disk-Image in der kurzen Zeit von nur ca. 1min sicherlich nicht auf einen anderen physischen Host durchgeführt werden kann.


    Nun da das Upgrade durchgeführt wurde habe ich aber eine neue Frage: Mir wird nun im CCP bei eben diesem Server unter Verwaltung weiterhin der Wechsel des Produktes angeboten, und ich könnte zu meiner Überraschung nun auch downgraden auf mein bisheriges Produkt. Wie geht das bei so einem Downgrade, Netcup kann mir ja nicht einfach einen Teil des Disk-Images wegschneiden - vergrößern klar, aber verkleinern?

  • Das längste Thema

    Zitat von aRaphael

    Der Host, auf dem ein Server liegt, bleibt auch ohne Upgrade nicht notwendigerweise beständig gleich.

    Das ist mir bewusst. In den vergangenen 6 Lebensjahren dieses Servers wurde dieser meinen Notizen zufolge aber nur 2x umgezogen. Das weiß ich deshalb, da ich immer einen Snapshot eingerichtet habe und ich daher eine Ankündigungsmail für so einen Umzug erhalte und auch den Restart im Zuge des Umzuges bemerke (Live-Migration mit Snapshot ist nicht möglich).


    Und ja, der Hintergrund meiner Frage ist tatsächlich der, dass ich am aktuellen Host SEHR zufrieden bin und das zuvor nicht so war.

  • Das längste Thema

    Im Thread nebenan wird ja das Ende der Verfügbarkeit von "alten" Server-Varianten diskutiert. Meine dort gestellte Frage, ob das auch die "Upgrade-Möglichkeit" eines bestehenden Produktes betrifft ist bislang unbeantwortet. Ich spiele daher mit dem Gedanken noch heute Abend sicherheitshalber einen "RS 500 SAS G7SEa1" aus dem Jahr 2016 auf den nächstgrößeren "RS 1000 SAS G7SEa1" upzudaten.


    An die Profis mit Erfahrungen was so ein Upgrade im CCP angeht: Ist meine Annahme richtig, dass hierbei (erfahrungsgemäß):


    1. Die IP-Adresse bei diesem Vorgang gleich bleibt

    2. Der Serverstandort gleich bleibt

    3. Der physische Host auf dem ich liege gleich bleibt

    4. Ich außer einem Neustart des Servers davon erst mal nichts bemerke

    5. Ich außer dem Vorhandensein von mehr RAM und einer größeren virtuellen Disk hiervon nichts bemerke

    6. Im Nachgang muss ich dann also nichts tun, außer das LVM zu erweitern um den zusätzlichen Disk-Speicherplatz auch tatsächlich nutzen zu können.


    Ist diese Annahme korrekt?

    Ich vermute 1, 2, 4, 5, 6 kann mir jemand bestätigen und zu 3 zumindest eine Vermutungen äußern?


  • Postfix Benachrichtigung bei unbekannter E-Mail-Adresse

    Wenn die Mail erst mal abgewiesen ist weißt Du nicht mehr, ob das sinnloser Spam an $random@domain war oder tatsächlich was relevantes. Insofern hilft so ein Log-Eintrag und/oder eine Notify-Mail wenig.


    Ich würde ein separates Postfach anlegen und den Catch-All vorübergehend wieder damit versehen. Das was dort ankommt schaut man halt hin und wieder mal durch, ist es nur noch Spam kann man den Catch-All dann schließlich irgendwann stillegen.