Beiträge von Hecke29

Prüf mal auf was das "Stammverzeichnis" der "externen (Sub-)domain" im WCP eingestellt ist und guck, ob in jenem Ordner auch wirklich was drin liegt. Ggf. musst du das Stammverzeichnis auf das einer bereits bestehende Installation ändern.

Ich habe auch diverse Zugangsdaten von Kunden, die ich hier her gebracht habe und fühle mich damit recht unwohl Aber ist halt mit das Praktikabelste, wenn ich Mal ins SCP muss (selten, aber dann halt dringend)

Meines Wissens nach nicht.

Der nodeJs Support bei Plesk bezieht sich auf Webanwendungen nicht auf serverseitig dauerhaft laufende Anwendungen.

Die App wird meines Wissens nach beim Request gespawnt und nach Ende wieder beendet.

Man könnte im konkreten Fall auch die PHP max_execution_time z.B. auf 1 Minute setzen.

Ich weiß auch generell nicht ob die globale max_execution_time im Webhosting 4000 überhaupt länger als 5 Minuten ist.

Zitat von m_ueberall

Benachrichtigungen lassen sich nämlich nicht selektiv ausblenden, soweit ich gesehen habe

Das geht ganz leicht auf der entsprechenden Profilseite.

Ich meine dadurch bekommt man auch keine Benachrichtigung mehr bei Posts

Bildschirmfoto 2018-08-05 um 22.49.16.png

Und für Threads geht es hier:

Bildschirmfoto 2018-08-05 um 22.51.17.png

Der Lookup des DNS Namen (z.B. nslookup jeff.example.org) ist wie folgt zu interpretieren:

Server:        127.0.0.1
Address:    127.0.0.1#53

Non-authoritative answer:
Name:    jeff.example.org
Address: 37.221.123.0

127.0.0.1 ist der DNS-Server, der deine Anfrage beantwortet; die IP ist für dich relativ egal. Address ist nur das Ganze noch mit dem entsprechenden Port

Wichtig ist die Antwort. Dort sollte der Name auf die IP auflösen. Damit das klappt ist ein normaler A-DNS-Record notwendig, den du mutmaßlich nicht haben wirst. Du bekommst bestimmt das hier als Antwort:

server can't find jeff.example.org: NXDOMAIN

Richtig?

Dann ist wie bereits erwähnt nicht der rDNS das Problem (das hat damit gar nichts zu tun), sondern ein Fehlender DNS-Eintrag, der den Namen auf die IP auflöst.

Zitat von chrisie

Der vServer ist nach wie vorunter der alten rDNS erreichbar.

Ein rDNS Eintrag ist dazu da einen DNS-Namen zu einer IP zu liefern.

tfoerster@jeff:~$ nslookup jeff.example.org
Name:    jeff.example.org
Address: 37.221.123.0

tfoerster@jeff:~$ nslookup 37.221.123.0
0.123.221.37.in-addr.arpa    name = jeff.example.org

Wenn jeff.example.org nicht auf deinen Server auflöst, liegt das nicht am rDNS Eintrag, sondern am fehlenden / falschen A-Record.

Es wird soweit ich weiß an einer API gearbeitet mit der man entsprechend Server starten kann.

Die aktuelle "Lösung" ist meiner Meinung nach auch nichtmal halbgar. Was nützt die Stundenbasis, wenn es Zufall ist wann ein Mitarbeiter die Bestellung bestätigt und somit "die erste Stunde" zu einem zufälligen Zeitpunkt startet?

Noch dazu wird ja vorschüssig abgerechnet: Man zahlt erstmal für 3 (?) Monate im Voraus (weiß Grade nicht wie lange) und bekommt dann das Geld zurück, wenn man kündigt... Ob die Kündigung wenigstens automatisch sofort durchgeführt wird, weiß ich nicht.

Zitat von vmk

WIP?

Zitat

Das Dokument bezeichnet sich selbst halt als WIP

Zitat von IETF TLS 1.3 DRAFT

It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

Aber danke für das gute Bild. Hatte mich selbst bisher nicht mit dem Prozess ansich auseinander gesetzt.

Habe oben meine Antwort auch noch editiert gehabt mit dem aktuellen Status (AUTH48)

Zitat von killerbees19

Afaik wird die finale Version genau wie Draft 28 sein. Warum es noch immer kein offizielles und finales RFC-Dokument gibt, ist eine andere Frage.

Ich glaube durch das "Auslaufen" des Drafts (am 21. September dann) entsteht automagisch der "fertige" RFC. Bis dahin ist quasi die Frist noch Änderungen einzubringen. Das Dokument bezeichnet sich selbst halt als WIP, weshalb ich es fragwürdig finde zu sagen, dass es schon offiziell "draußen" ist.

Ok, das ist kompletter Blödsinn. Hier der aktuelle Stand: https://www.rfc-editor.org/auth48/C357

Zitat von florian2833z

Dauert noch so ungefähr -4 Monate. TLS 1.3 ist schon seit Ende März 2018 freigegeben.

Wenn ich das richtig sehe ist es seit Ende März ein Entwurf, der im September ausläuft https://tools.ietf.org/html/draft-ietf-tls-tls13-28 Seite 1 "Status of this memo"

Also mitnichten "offiziell freigegeben"

Vielleicht n bisschen mehr informieren bevor man bissige Kommentare ablässt.

It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

Zitat von killerbees19

Gut erkannt, Hecke29!

Genau... "Erkannt"

Der Context http ist laut Doku zumindest korrekt...

Vielleicht vor den includes setzen?

Damit sich der netcup-Server für die Domain zuständig fühlt, ist das nötig, was DerRené verlinkt hat.

Es sollte dabei auch kein Problem mit Shopify geben:

Der netcup-Server fühlt sich zwar für die gesamte Domain example.org zuständig, aber solange der @ A-Record noch auf Shopify zeigt und nur eine Subdomain auf netcup, landet man bei Eingabe der Hauptdomain auch bei Shopify (deren Webserver fühlt sich auch für die gesamte Domain zuständig; so kannst du per DNS regeln was genau wohin geleitet werden soll)

Im netcup-Webhosting kannst du dann einstellen, dass das Stammverzeichnis für bla.example.org dein /mst/ Verzeichnis sein soll (dann verschwindet der Pfad in der URL auch gleich)

Eine HTTP-Weiterleitung ist das was du suchst. Mit DNS hat das nur zweitrangig zu tun. Eine HTTP-Weiterleitung funktioniert allerdings nur mithilfe eines Webservers, der sich für die Subdomain beispiel.example.org zuständig fühlt und dann entsprechend weiterleiten kann.

You can upload your own ISOs to the selected server in the SCP under Media > Images. You'll find credentials for FTP upload there (bottom of the page)

CURL_BODY='<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://enduser.service.web.vcp.netcup.de/"> <SOAP-ENV:Body> <ns1:changeIPRouting> <loginName>LOGINNAME</loginName> <password>PASSWORD</password> <routedIP>FAILOVERIP</routedIP> <routedMask>32</routedMask> <destinationVserverName>DESTINATIONVSERVER</destinationVserverName> <destinationInterfaceMAC>DESTINATIONMAC</destinationInterfaceMAC> </ns1:changeIPRouting> </SOAP-ENV:Body> </SOAP-ENV:Envelope>'

    CURL_OUTPUT=$(curl -s -H "Content-Type: text/xml; charset=utf-8" -H "SOAPAction:" -d "$CURL_BODY" -X POST https://www.servercontrolpanel.de:443/WSEndUser?xsd=1)

    printf "Subject: DESTINATIONVSERVER now master lb\n\nBody:\n$CURL_BODY\n\nResponse:\n$CURL_OUTPUT" | ssmtp lb@example.com

Dirty af.

Davon liegt jeweils eines auf den drei Nodes im Corosync/Pacemaker Setup. Die Werte (LOGINNAME, FAILOVERIP etc.) sind dort fix im String eingetragen (per ansible verteilt).

Zitat von MarcelloW

Was ist wenn ich die normale IP aber garnicht am Server haben möchte, sondern einfach nur die Failover sowie meine über vNIC/VLAN eingerichtete IP?

Das VLAN ist glaube ich ein eigenes Interface, (also keines auf ens3?), dann kann das ja so bleiben wie es ist.

Ob du die "native" IP "abschalten" kannst und nur die FailOver-IP aufschalten kannst, weiß ich ehrlich gesagt nicht, da ich nicht weiß, wie das technisch genau funktioniert (ob die Pakete an die FailOver-IP auf die MAC weitergeleitet wird oder irgendwie auf die "native" IP) Aber vielleicht kennt sich da jemand anders mit aus

Statt da eine schöne Race-Condition zu bauen, könntest du dir merken welche Bilder schon kopiert wurden (oder kopierte löschen) und alle anderen rüberkopieren. So kopierst du im Zweifel erst eine Minute später, aber das Verfahren derzeit klingt auch nicht sonderlich zeitkritisch...

Im SCP am entsprechenden Server unter "Netzwerk", kannst du die IP zuweisen.

Im Fehlerfall musst du die IP dann (z.B. automatisiert per API-Call) auf einen anderen Server zuweisen.

Wichtig: Der Server dem die IP zugewiesen ist muss sich auch für die IP zuständig fühlen, also ein (virtuelles) Interface damit einrichten bzw. die IP zusätzlich auf ein Interface aufschalten.