Aktuell führen wir noch einige Anpassungen durch, das Forum wurde jedoch bereits live geschaltet.
-
Hi,
wir haben unsere HNs mit 1 GBit angebunden und drosseln die VPS mit folgendem Shell Script auf 100 MBit/s (nur ausgehend).
#!/bin/sh
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 100mbit
tc class add dev eth0 parent 1: classid 1:1 cbq rate 50000kbit allot 1500 prio 5 bounded isolated
tc qdisc add dev eth0 parent 1:1 sfq perturb 10
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.52 flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.53 flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.54 flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.55 flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.56 flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.57 flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip src XXX.XXX.231.58 flowid 1:1
usw. (nur die IPs der VPS, nicht die IP des HNs!)
Alles anzeigen
-
Unser FTP hört nur auf unsere VPN IP und Webserver IP.
Kann dir nur ein vServer Kunden Zugang geben.
Aber ersetze doch einfach in der alten mvserver.php das "vmguarpages" durch "ram" - schon funktioniert es.
Ich denke nicht, dass noch jemand einen Kernel im produktiven Einsatz hat, der mit den alten UBC Parametern arbeitet. Und wenn doch, können diejenigen dann ja die alte mvserver.php manuell hochladen.
Danke.
-
Weil er Debian nutzt und das auch so bleiben soll wie ich schätze.
Das ist natürlich DIE Begründung veraltet Software einzusetzen.
Ist ja schön wenn er vServer vermieten möchte, aber dafür diesen Kernel zu nutzen sehe ich als fahrlässig.
Wenn es die vServer privat nutzt ist das natürlich seine Sache und ich nehme alles zurück 
-
-
Hi,
gemacht, zeigt allerdings immer noch einen Minus-Wert an 
-
Hi,
einfach das Rechnungsmodul bestellen und beim letzten Bestellschritt in die Kommentarbox eintragen, dass das Modul der Lizenz unter der Domain http://blablabla.de/admin.php hinzugefügt werden soll.
-
Ja damit funktioniert es, soll aber auch bitte mit "ram" funktionieren 
-
Ok, super! Update kommt dann mit 6.2.5 die nächsten Tage?
-
{%TSTART%}cpuunits{%TD%}cpuunits{%TD%}input{%TD%}60{%TD%}1000{%TD%} {%TD%} {%TEND%}
{%TSTART%}diskspace{%TD%}diskspace{%TD%}input{%TD%}40{%TD%}35G:37G{%TD%} {%TD%} {%TEND%}
{%TSTART%}diskinodes{%TD%}diskinodes{%TD%}input{%TD%}60{%TD%}300000:330000{%TD%} {%TD%} {%TEND%}
{%TSTART%}hostname{%TD%}hostname{%TD%}input{%TD%}255{%TD%}vsXXX.X.X.X.X.blablabla.org{%TD%} {%TD%} {%TEND%}
{%TSTART%}nameserver{%TD%}nameserver{%TD%}input{%TD%}255{%TD%}8.8.8.8,8.8.4.4{%TD%} {%TD%} {%TEND%}
{%TSTART%}onboot{%TD%}onboot{%TD%}select{%TD%} {%TD%}yes,no{%TD%}Ja,Nein{%TD%} {%TEND%}
{%TSTART%}ram{%TD%}ram{%TD%}input{%TD%}20{%TD%}512M{%TD%} {%TD%} {%TEND%}
{%TSTART%}swap{%TD%}swap{%TD%}input{%TD%}20{%TD%}1G{%TD%} {%TD%} {%TEND%}
Alles anzeigen
-
Also im Webinterface sucht er sich den vmguarpages Eintrag, schaut welche Angabe das ist z.B M oder G, gegebenfalls Umrechnung auf M bei G. Nun nimmt er die KB und rechnet die / 1024 für M.
Dann rechnet er vmguarpages Wert - Wert vom Skript = Freier Speicher
Schön dass mein Post überhaupt nicht zur Kenntnis genommen wurde. vmguarpages ist veraltet und gibt es nicht mehr ! (!!) 
Eigentlich muss ja nur der Parameter (früher "privvmpages") auf den neuen (RHEL6) Parameter "ram" geändert werden. An diesem wird der verbleibende RAM berechnet.
An den Root-Scripten muss da eigentlich nichts geändert werden, der verwendete RAM wird ja richtig ausgelesen.
Eher an der TekBase - denn die Berechnung (Gesamt-RAM minus verwendeten-RAM) läuft falsch. (Er nutzt als Gesamt-RAM immer den Wert "0")
-
Darf man wenigsten erfahren wie die werte an das Interface übergeben werden dass ichs mir selbst schreiben kann?
Ganz ruhig, CF wird das schon hin bekommen
Was genau das Problem ist verstehe ich allerdings auch noch. Eigentlich muss ja nur der Parameter (früher "privvmpages") auf den neuen (RHEL6) Parameter "ram" geändert werden. An diesem wird der verbleibende RAM berechnet.
An den Root-Scripten muss da eigentlich nichts geändert werden, der verwendete RAM wird ja richtig ausgelesen.
Eher an der TekBase - denn die Berechnung (Gesamt-RAM minus verwendeten-RAM) läuft falsch. (Er nutzt als Gesamt-RAM immer den Wert "0")
-
Kann (muss) ich bestätigen.
Wie schon geschrieben wurde muss der zur Verfügung stehende RAM anhand des Parameters "ram" berechnet werden.
-
Hi,
nein, der DNS Eintrag für den rDNS ist nur in der MySQL auf unserem Master Nameserver hinterlegt (Die Redundanz- Nameserver werden automatisch abgeglichen).
http://docs.solusvm.com/powerdns
Also der Kunde muss den Eintrag in der MySQL DB auf dem Master NS ändern können. (Natürlich nur für die ihm zugeordnete(n) IP(s).)
-
Aber bitte nichts ändern, was funtkioniert - den Salat hatten wir ja erst beim 6.0 Release.
Das mit dem RAM muss unbedingt angepasst werden (An den Parameter --ram)
-
Meiner Meinung nach spricht in den TekLab AGB nichts dagegen. Würde aber nochmal sicherheitshalber CF fragen.
-
Verstehe die Frage nicht.
Mit deinen Rootservern kannst du doch machen was du willst.
-
denn ein Zwang finde ich nit so gut.
Das sowieso nicht. Es gibt ja auch Anbieter die keine eigenen IP Netze haben und mit diesem Feature sowieso nichts anfangen könnten.
Aber das wäre ja kein Problem. Die Backupfunktion, Retsart Funktion, Prozess Einsicht, Dienste, etc. lässt sich ja alles aktivieren, bzw. deaktivieren.
-
Das TekRWI funktioniert ja auch nur mit OpenVZ und nicht mit XEN, KVM, Linux-vServer, etc.
Alle möglichen DNS Server zu unterstützen ist nicht machbar. Man müsste sich schon auf ein System einigen. Und PowerDNS ist das populärste und funktioniert auch mit SolusVM (was wir für KVM Server nutzen).
-
Aber halt nicht nur auf eine Software beschränken.
Anders geht es aber nicht, denke ich. Ansonsten müsste CF eine eigene DNS Server Software schreiben.
Und PowerDNS ist meines Erachtens das unkomplizierteste aufgrund MySQL.
-
Ich möchte meinen vServer Kunden gerne die Möglichkeit bieten die rDNS Einträge ihrer IPs anzupassen. (Ãœber Tekbase, im vServer Bereich)
Zur Verwaltung unserer Reverse-DNS-Zoneneinträge nutzen wir DNS Server unter "PowerDNS" - wie die meisten anderen hier vermutlich auch.
Das ganze wäre also sehr leicht über MySQL realisierbar. Müsste nur in Tekbase integriert werden. (MySQL Login zu PowerDNS im Tekbase hinterlegen, Kunde kann alle rDNS für die ihm zugeteilten IPs im vServer Bereich ändern, Bei Löschung des vServers wird Zone ebenfalls per MySQL gelöscht.)
Es ist ein ziemlicher (unnötiger) Supportaufwand die rDNS Einträge für die Kunden zu setzen und dem Kunden wegen einer IP Adresse einen Login zum PowerDNS Verwaltung Panel zu erstellen ist auch etwas unnötig und nur ein weiterer Login für den Kunden, wo er sich ein Passwort merken muss.
Außerdem ist die Möglichkeit den rDNS anzupassen Standard in einem vServer Verwaltungs- Interface
