Beiträge von franc

  • Storagespace - Quota setzen funktioniert nicht

    Zitat von julian-w

    Hast du ausprobiert ob du mehr als 100GB belegen kannst? Also einfach mal mit Daten füllen über die 100GB Grenze hinweg?

    Nein, geht nicht:

    Zitat

    #cp /mnt/storagespace/26gb-datei /mnt/storagespace/26gb-dummy

    cp: Fehler beim Schreiben von '/mnt/storagespace/26gb-dummy': Auf dem Gerät ist kein Speicherplatz mehr verfügbar


    EDIT: Ich hab jetzt mal den Support angeschrieben...

  • Storagespace - Quota setzen funktioniert nicht

    Hallo


    Ich habe seit 16.7.2015 einen Root-Server L SATA v6.
    Ich habe zu 5.- Euro das 250 GB Paket Storagespace gebucht, schon seit Jahren. Seit 2017 wurde das Paket geändert, vorher 100 GB zu 3.-, dann 250 GB für 5.-

    Im Customer Control Panel unter Produkte lese ich bei Storagespace:


    Zitat

    Aktuell genutzter Speicherplatz (inkl. Hardlinks): 85GB von 100GB

    ...

    Vereinbartes Abrechnungsmodell: 250 GB für 5,00 Euro / Monat zzgl. 0,03 Euro / zusätzlichem GB

    Speicherplatz begrenzen: 250 GB [Quota setzen]

    ...

    Die Quota war vorher auf 100 GB gestanden und ich habe sie auf 250 GB erhöht, danach den Server neu gestartet.


    Aber immer noch sehe ich 85 GB von 100 GB und mit df -h zeigt es auch nur ein 100 GB Laufwerk an:


    Code
    # df -h
...
46.38.201.203:/voln24137a2  100G     85G   16G   85% /mnt/storagespace
...


    Was kann ich tun, damit ich die 250 GB auch nutzen kann?


    Danke


    franc

  • Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

    Ich habe noch ein Problem mit dem Storagespace, der wird nicht mehr eingehängt:

    Code
    #mount -t nfs 1.2.3.4:/voln12345a6 /mnt/storagespace
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified


    Was kann das sein?

    nfs-common ist (noch) installiert, Version 1.2.8-9ubuntu12.2

  • Festplattentreiber - VIRTIO oder SCSI?

    Ich habe es noch zurück gestellt, zugunsten des Systemupgrades, das mir primär wichtiger erschien :)

    Ich kann es ja nur am Wochenende abends machen und da auch nur, wenn nichts anderes ist, das ist rar.


    Mir ist auch immer noch nicht klar, ob es überhaupt wichtig ist, von VIRTIO auf SCSI umzustellen, also was das bringt?

    Ist es so, dass ich aber vor einem Paketwechsel (also wenn ich ein Image ziehe und das dann auf ein neues netcup-Paket einspiele) besser gleich schon SCSI habe oder ist das dann egal?

  • Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

    Uff. Hat geklappt. Das "No new release found" lag an meinem schon vor langem editiertem:

    Code
    /etc/update-manager/release-upgrades
...
[DEFAULT]
Prompt=never
...

    Das hab ich wieder auf lts gestellt und die Datei release-upgrade-available wieder erstellt (damals gelöscht):

    Code
    touch /var/lib/ubuntu-release-upgrader/release-upgrade-available

    Danach wurde das Update auf 16.04 LTS wieder gezeigt.


    Das Update hat eine gute Weile gebraucht und ich musste zig mal bestätigen, dass ich die bestehenden Konfigurationsdateien (für die ganzen aktualisierten Programme) beibehalten will.


    Zuvor hatte ich natürlich ein Image gezogen, das ging aber wiederum erst, nachdem ich mehrfach eine Speicherplatzoptimierung durchgeführt hatte (Defrag also, kenn ich ja von VMware usw.). Die Speichernutzung war am Schluss bei nur noch 60 von 312 GB (von vorher 312 von 312) ich hatte vorher aber auch einiges gelöscht (entschlackt).

    Jetzt werde ich beim Login (per SSH) mit:


    Zitat


    Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-150-generic x86_64)

    empfangen :)


    Ich muss "nur" noch mindestens Logwatch ( /etc/cron.daily/00logwatch: Wrong configuration entry for "Service", if "All" selected, only "-" items are allowed) und certbot (/bin/sh: 1: certbot: not found) reparieren. Aber ich vermute, da sind schon noch andere Programme nicht mehr so kompatibel.
    Das Wichtigste, Mail und Apache scheinen aber noch zu funktionieren :)

    Danke!

  • Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

    Gestern habe ich nun angefangen damit (hatte zuvor noch kein freies Wochenende) und erst mal eine "Serveroptimierung" durchgeführt. Wurde zuvor gesagt, dass es bis 1h47min dauern könne, dauerte aber nur eine 3/4 h.

    Zuvor war der Speicherplatz mit 312 von 312 GB angegeben, danach mit 68 von 312, scheint also funktioniert zu haben.

    Heute abend dann mache ich ein Image und versuche den Upgrade...

  • Festplattentreiber - VIRTIO oder SCSI?

    Hallo


    ich habe seit 2015 einen alten root Server L SATA v6 den ich von 14.04 auf 18.04 Ubuntu upgraden will, siehe:


    Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten


    Im Rahmen der vorherigen Aufräumarbeiten sehe ich, dass im SCP unter: Medien > Festplatte der Festplattentreiber auf VIRTIO steht.

    Man kann das ändern auf SCSI, was scheints empfohlen wird:


    Bildschirmfoto 2019-06-15 um 07.35.41.png


    Kann ich das gefahrlos umstellen oder birgt das ein Risiko?

    Es wird ja davor gewarnt, aber auch gesagt, dass der empfohlene Treiber genutzt werden soll.


    Danke für Tipps.


    Gruß franc

  • Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

    Zitat von m_ueberall

    Wie von alhazred geschrieben, kann man mittels sudo do-release-upgrade von 14.04 auf 16.04, und danach von 16.04 auf 18.04 wechseln. Dank der KVM-Virtualisierungstechnik ist auch der Kernel Bestandteil Deiner isolierten Umgebung (VM), ein Wechsel ist also beliebig möglich. Es ist sogar ratsam, zu überlegen, ob man aktuelle Kernel regelmäßig manuell einspielt/einspielen läßt; unter Ubuntu gibt es zudem einen Livepatch Service, der unbedingt einen Blick wert ist (für bis zu drei Rechner kostenlos!)

    Bzgl. Paketwechsel: (1) Man kann den Server herunterfahren, um ein Abbild zu erstellen und dieses Abbild danach auf einen anderen Server aufzuspielen (IP-Adressen sind anzupassen). Das sollte relativ problemlos/zügig gehen.

    (2) Es ist möglich, gegen Gebühr zusätzliche IPv4/IPv6-Adressen zu buchen, welche man dynamisch oder via Auftrag "umziehen" kann – also an den neuen Server übertragen. Ein Umzug der "Standard-IP-Adressen" des Pakets ist wahrscheinlich in dieser Form nicht möglich, aber hier empfiehlt sich eine Nachfrage beim Support. Ob sich das rechnet ggü. einer Neuaufsetzung oder der Akzeptanz, dass der neue Server eben neue IP-Adressen hat, muss man individuell entscheiden.

    Danke, das klingt ja vielversprechend :)

    Ich würde dann zunächst abends ein Image machen, falls was schief geht, dann den release upgrade.


    Laufen die unter 14.04 installierten Programme (namentlich postfix und dovecot) problemlos nach so einem Upgrade?

    Oder laufen die Programme dann erst wieder, wenn ich auch die dann aktualisiere?


    Es ist ein Produktivserver, ungern wäre ich damit einen halben Tag offline, wenn ich dann notfalls ein Image zurück spielen müsste.

    Ein Paketwechsel (das Paket: RS 1000 G8, Intel® Xeon® Gold 6140, 8 GB DDR4 RAM, 2 dedizierte Kerne, 40 GB SSD / 320 GB SAS) für 9.- im Monat (bei 1 Monat Vertragslaufzeit) würde eigentlich reichen, damit würde ich im Monat 10.- sparen.

    Allerdings hatte mich gerade der IP-Wechsel beim letzen Wechsel immens aufgehalten (namentlich DNS-Probleme), das hat mich Tage Arbeit und Ärger gekostet. Allerdings behalte ich es im Hinterkopf.





  • Root Server Systemupdate - Ubuntu 14.04 auf 18.04 updaten

    Hallo

    ist es eigentlich möglich, einen (virtuellen) Root Server über die normale Aktualisierung mit Ubuntu 14.04 LTS auf 18.04 LTS zu aktualisieren?


    Im Juli 2015 habe ich diesen Root-Server gebucht:


    Root-Server L SATA v6 für 18.99 / Monat (monatlich kündbar)

    Virtualisierungstechnik: KVM

    Prozessor: Intel®Xeon® E5-26xxV3 (min. 2,3 GHz je Kern)

    RAM: 12 GB DDR4

    HDD: 320GB SATA ( / 240GB SSD)

    RAID: RAID10

    CPU-Kerne: 4 dediziert

    Ich hab da das damals aktuelle Ubuntu 14.04 LTS drauf gespielt und seit dem lauft er auch so.

    Ich hatte vorher, bei einem anderen Provider (hosteurope) ein Ubuntu 12.04 laufen, da hieß es, dass ich wg. dem Kernel des Wirtssystems (also der Host, auf dem der virtuelle Server lauft) gar kein neueres Ubuntu aufspielen könnte.

    Ist das hier genauso?


    Ich hab das nie gefragt, ich ging davon aus, dass auf einem vServer so was halt nicht geht.
    Ansonsten würde ich natürlich updaten, da mittlerweile einiges veraltet ist.

    Auch der Preis zwar.

    Aber ein neues Paket buchen, das zwar für die selbe Leistung (oder mehr) viel billiger ist, geht wohl sicher nicht ohne kompletten Umzug (was sehr aufwendig, lästig und somit teuer wäre).

    Oder gibt es da auch Möglichkeiten, mit Erhalten der IP usw.?


    Danke für Hinweise die zu sachdienlichen Ergebnissen führen ;)


    Gruß franc

  • storagespace wurde von netcup ausgehängt

    So geht es nicht, sondern mit:


    Code
    *filter
-A INPUT -s 1.2.3.4/32 -p tcp -m tcp --dport 111 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -p tcp -m tcp --dport 111 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 111 -j REJECT
-A INPUT -p udp -m udp --dport 111 -j DROP
COMMIT


    in der Datei /etc/iptables/rules.v4



    PS.: ich hätte das ja in meinem vorigen Post korrigiert, aber in diesem Forum kann man den nach sehr kurzer Zeit nicht mehr bearbeiten, warum auch immer :(

  • storagespace wurde von netcup ausgehängt

    Ich hatte mich wohl zu wenig über iptables eingelesen, die Regeln sind ja flüchtig und überleben keinen Reboot lese ich im Ubuntuforum:


    Zitat

    ...

    Die mit iptables erstellten Regeln sind flüchtig, d.h. sie bleiben nur bis zum Ausschalten des Computers erhalten! Will man dauerhaft Regeln einrichten, so sollten diese in einem entsprechenden Skript hinterlegt werden, das bei Systemstart automatisch gestartet wird (siehe hierzu rc.local und / oder Upstart bzw iptables-persistent).

    ...

    Habe daher das iptables-persistent installiert und dort in der Datei:


    /etc/iptables/rules.v4


    eingetragen:


    Code
    iptables -I INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 111 -j REJECT
iptables -A INPUT -p udp --dport 111 -j DROP
iptables -I INPUT -p tcp -s 1.2.3.4 --dport 111 -j ACCEPT

    (1.2.3.4 steht für die IP vom Storagespace Server)

    Ich hoffe jetzt bleibt es.

  • storagespace wurde von netcup ausgehängt

    iptables -I INPUT -p tcp -s 46.38.248.199 --dport 111 -j ACCEPT


    Bei dieser Regel war ein winziger Fehler vor dem "dport", da war ein langer Bindestrich, statt zwei Minuszeichen.

    Aber damit geht es jetzt :)

    Danke!!!


    Code
    root@FRANC-MACBOOK:/# rpcinfo -T udp -p 1.2.3.4
rpcinfo: can't contact portmapper: rpcinfo: RPC: Timed out


    root@FRANC-MACBOOK:/# rpcinfo -T udp -p 1.2.3.4

    rpcinfo: can't contact portmapper: rpcinfo: RPC: Timed out


    vorher war es aber:


    scheint also zu gehen :) :)

  • storagespace wurde von netcup ausgehängt

    Ich habe von netcup eine automatische Warnung bekommen:


    dabei geht es im rpcbind, das man mit nfs-common mit installiert, was man für den storagespace braucht.

    Ich habe bisher keine Möglichkeit gefunden, die Erreichbarkeit von außen zu stoppen ohne rpcbind zu deinstallieren, was ja vermutich den storagespace unerreichbar macht, was ich gar nicht ausprobieren will.


    Jemand eine Idee?

  • Snapshot exportieren nicht möglich

    Klar.
    Ich glaube ich bleibe dann bei diesem Konzept: Serverplatzbelegung klein halten (auf jeden Fall unter 50%) und möglichst regelmäßige Snapshot (diffs) zu machen.


    Die Snapshots kann man ja über den Firefox mit dem Add-On "iMacros for Firefox" automatisiert anstoßen. Das habe ich schon früher mal bei Host Europe im sog. Virtuozzo Panel erfolgreich gemacht. Man braucht "nur" einen Rechner mit GUI und Firefox mit iMacros (Windows, Mac oder Linux, kann auch virtuell sein) der immer läuft oder wenigstens für die Snapshots hoch fährt.
    Etwa so ein iMacros Makro:


    Ohne GUI, also per Kommandozeile ist es wesentlich komplizierter, weil diese Verwaltungsoberflächen wie das VCP usw. JavaScript verwenden und man das dann alles mühsam auslesen müsste, was man wo braucht und einsetzen muss.
    Am einfachsten wäre natürlich, wenn netcup solche Snapshot Erstellungen automatisiert anbieten würde, oder wenigstens eine Schnittstelle für die Kommandozeile, aber das wollen die ja nie.

  • Snapshot exportieren nicht möglich

    Danke.


    Also könnte ich meinen Server bis 50% füllen, ein Snapshot machen, danach noch zig weitere differentielle Snapshots, bis diese zusammen die andere Hälfte des Speicherplatzes ausmachen, dann belege ich den Speicherplatz auf meinem Server auf 100% (jetzt kann ich keine Snapshots mehr machen, aber habe ja noch die zuvor erstellten). Jetzt hätte ich physikalisch das 1.5 fache des eigentlichen Speicherplatzes belegt.


    Nicht dass ich diesen Unsinn tun wollte, ich frage das nur damit ich es verstehe.


    Sozusagen: netcup stellt mir die Snapshots zur Verfügung, passt aber auf, dass ich damit nicht viel mehr als meine gekaufte Speicherplatzgröße belege?

  • Snapshot exportieren nicht möglich

    Vielen Dank!
    Den Wiki Eintrag hatte ich übersehen, bzw. bin zum falschen Eintrag zu Snapshots geraten (zum Linux-VServer Artikel).


    Ich habe dann im Forum auch noch den Link über netcup-News zu Snapshots gefunden, da steht auch noch etwas dazu.


    Ich habe noch nicht ganz verstanden, wie das mit dem Speicherplatz ist. Wenn die Snapshots von meiner Festplattenplatz abgezwackt werden, wo liegen denn die nun physikalisch? Ich kriege ja immer noch den selben Platz auf meiner Platte angezeigt, nämlich nur 34% benutzt. Sind die snapshots auf einer partition die ich nicht sehen kann? Was passiert, wenn ich meinen Server jetzt z.B. zu 90% voll ramsche, werden die Snapshots dann automatisch gelöscht?
    Wo sind die denn?