Beiträge von [netcup] Kai S.

    Danke Leute! Hatte es auch nur so eingetragen, aber noch nicht getestet. Taucht bei euch die interne IPv4 im SCP auf? sonst füge ich mal nen zweiten Server hinzu und versuche die anzupingen


    Edit: Also pingen klappt schon mal nicht :/


    Das SCP zeigt nur IPs an die es kennt, also IPs die von uns zugeteilt wurden. Da uns nicht bekannt ist welche IPs auf den vlan Interfaces konfiguriert werden, werden diese IPs auch nicht angezeigt.

    Unsere Enthusiasten bei Funkfeuer haben das mit Baumarktteilen gelöst. Kreativ, aber gerade keine Schienen. Aber, ob das eine Industrienorm erfüllt?! Wohl kaum.


    Mit solchen Lösungen braucht man aber in einem RZ erst gar nicht anfangen. Da braucht man vernünftige Lösungen die einen einfachen Zugang ermöglichen, das ganze auf 1-2 HE pro Einschub, mit vernünftigen Kabelmanagement, passenden Stromschienen/Verteilungen etc. Gerade bei der Stromverteilung darf man sich keinen Fauxpass erlauben, sonst sagt die Versicherung "selbst schuld". Alles andere wäre Pfusch.


    Sicherlich kann man das alles irgendwie umsetzen. Lohnt sich halt vom Aufwand absolut nicht. Da kann man dann lieber einen 19" 2HE ARM Server mit ein paar hundert Kernen ins Rack Schrauben wenn man denn unbedingt arm CPUs haben will.

    Na, dann wird's Zeit für ein netcup Raspi-Hosting. ;)

    Naja, dazu gehört halt einiges. Zum einen überhaupt erstmal ein Rackmount Schienensystem inkl. flexibler Kabelführung entwickeln mit dem man die PIs vernünftig ins Rack schrauben kann und auch noch zum SD-Card Tausch überall dran kommt. Ist zwar kein Hexenwerk das im CAD zu entwerfen, dann brauchst aber auch Immer noch jemanden der es fertigt (in entsprechend kleinen Stückzahlen).

    Im Großen und ganzen ist es viel Aufwand für geringen nutzen.

    Bei mir ist es schwer zu beantworten. Die Sprache die für die Aufgabe gerade die richtige ist. Das meiste wird sich auf bash und php belaufen. Hier und da mal Kleinkram mit ruby oder perl..


    Privat für die ein oder andere Arduino Spielerei auch mal etwas C/C++ oder bei einem Raspi auch mal Python, wobei ich mit Python noch nicht wirklich warm geworden bin.

    Generell Dazu zum Hintergrund: Wir bieten neben den PHP Versionen die durch Plesk bereitgestellt werden auch PHP Versionen an die wir selber kompilieren. Da gibt es natürlich Überschneidungen bei den Versionen, daher gibt es PHP Versionen die Doppelt angezeigt werden (einmal mit voller Versionsangabe und einmal nur die kurze Versionsangabe). Eine Version ist dann die, die von Plesk kommt, die andere ist die, die von uns gepflegt wird.

    Wie man Phalcon auf einen selbstverwalteten Server installiert ist mir klar - das machen wir ja momentan auch.


    Die Frage ist eben wie es bei einem managed Server von netcup aussieht.

    muss individuell geprüft werden (Sicherheit, Wartungsaufwand, Art und weise wie es zu implementieren ist). Von daher am besten eine eMail an den support schreiben.

    Das klingt interessant. Was würde das in Laiensprache bedeuten? Quasi eine zusätzliche Festplatte?

    bei den Storage Volumes handelt es sich in "Laiensprache" ausgedrückt um eine Netzwerkfestplatte. Wir betreiben große Netzwerk-Speicher-Systeme (Storages) auf denen Wir Speicherplatz anbieten. Eine solche Platte kann man dann z.b. per NFS auf einem Server in das Verzeichnis einhängen in das Plesk seine Backups schreibt. Somit würden die durch Plesk angelegten Backups automatisch auf einem physikalisch getrennten System landen.


    Details zu den Storage Volumes findet man hier: https://www.netcup.de/vserver/storagespace.php

    Ich hatte vermutet, dass Cloud vLAN Giga BF mit 12 Monaten Vertragslaufzeit daher kommt, jetzt waren es aber doch nur 6 Monate. Hatte dann schon Cloud vLAN medium bestellt.


    Nun die Frage: doch noch schnell beim Gigabit zuschlagen und nach 6 Monaten wissen welches besser ist, oder mit dem medium leben.


    ist halt die Frage welche Bandbreite im VLAN benötigt wird. sollen dort große Datenmengen durch die Gegend geschoben werden, oder soll es dazu dienen interne Kommunikation zwischen mehreren VMs abgekapselt vom öffentlichen Netz zu ermöglichen (z.b. für die Verbindung zwischen Web und DB Server)?

    Wir fertigen dort standardmäßig nur Backups von den Konfigurationen der Systemdienste etc an. Für jegliche Daten die direkt oder Indirekt vom Kunden erstellt werden ist letztlich der Kunde Verantwortlich.


    Wir bieten standardmäßig Backup Lösungen auf Basis von BackupPC an: https://www.netcup.de/professi…iterungen.php#backupspace


    Darüber hinaus lassen sich auch individuelle Lösungen (z.b. auf Basis eines Storage Volumes) finden wenn man die Backups über die Plesk eigene und dort integrierte Backup Lösung machen möchte.


    Soweit ich die Produktlinie "managed Server" bei netcup richtig verstanden habe, ist das quasi ein dediziertes Webhosting über Plesk gemanaged.

    Extra-Dienste wie TeamSpeak kann man da nicht installieren und auch nicht installieren lassen.

    Das ist schlicht falsch.

    Kunden erhalten bei einem managed private Server einen Linux vServer den wir für den Kunden pflegen. Im Preis ist neben dem Grundpreis des Servers noch eine entsprechende Plesk Lizenz, sowie das Server management einkalkuliert.


    Das Servermanagement deckt dabei die allgemeine Administration des Servers inkl. Monitoring und Updatemanagement der Systemdienste ab. Zusätzliche Dienste können, sofern wir diese nicht als Sicherheit für den Server betrachten auch System weit installiert werden (hierfür können je nach Software zusätzliche Kosten aufgrund des erhöhten Aufwandes anfallen).

    Dienste die nur einen normalen SSH Zugriff benötigen kann der Kunde auch selber starten (liegt dann aber außerhalb unseres Managements und muss vom Kunden eigenständig gepflegt werden)


    Weiterhin geht es über ein normales Webhosting deutlich heraus, da der Kunde in Plesk eigenständig Service Pläne definieren und seine Leistungen auch beliebig viele Endkundenaccounts verteilen kann.

    Auf der Produktseite steht "NAT ins WAN: nein" - klingt als wenn es da noch andere Varianten gibt.

    (Würde man das sonst extra aufzählen?)

    Dies ist eher um zu verdeutlichen, dass dies Interne Netze sind von denen aus kein Routing ins öffentliche Netz erfolgt.

    Wenn einem die Abschottung wichtig ist, dann kommen solche Geräte hinter eine Firewall auf einem anderen physikalischen Gerät - in einem internen Netzwerk. - Und nicht in ein RZ mit NIC an eine Global Unicast Adresse.

    Sprich: Ein Server der in einem internen vlan hängt und nur über eine interne IP erreichbar ist, also genau das was ich beschrieb. Das VPN Gateway bildet dann nur generell die Brücke um von Extern selber irgendwie dran zu kommen.

    Naja sauber ist etwas anderes. Server 2 müsste dann ja über Server 1 ins Internet, dieser muss dann das NAT übernehmen.

    Schließlich will Server 2 ja auch Updates bekommen und dafür nicht ständig das Interface rauf- und runterfahren müssen.

    und daran ist was problematisch? Im Optimalfall läuft auf dem Server 1 dann ein Mirror für die Paketverwaltung der jeweiligen Distribution. Wenn einem die Abschottung von Internen Systemen wichtig ist, muss man so was eben in Kauf nehmen.