Posts by franc

    Der hat auch zügig geantwortet und geschrieben, dass meine Quota im CCP noch auf 100 GB stünde.

    Sowas.

    Ich hatte es sicher umgestellt, anscheinend wurde das nicht übernommen, möglicherweise meinem Browser geschuldet.

    Jedenfalls habe ich es also noch mal (auf einem anderen Rechner) auf 250 GB gestellt und Zack! geht es auf Anhieb.

    df -h zeigt mir 250 GB :)

    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:

    Quote

    #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...

    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:


    Quote

    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
    1. # df -h
    2. ...
    3. 46.38.201.203:/voln24137a2 100G 85G 16G 85% /mnt/storagespace
    4. ...


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


    Danke


    franc

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

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


    Was kann das sein?

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

    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?

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

    Code
    1. /etc/update-manager/release-upgrades
    2. ...
    3. [DEFAULT]
    4. Prompt=never
    5. ...

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

    Code
    1. 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:


    Quote


    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!

    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...

    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

    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.





    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

    So geht es nicht, sondern mit:


    Code
    1. *filter
    2. -A INPUT -s 1.2.3.4/32 -p tcp -m tcp --dport 111 -j ACCEPT
    3. -A INPUT -s 127.0.0.1/32 -p tcp -m tcp --dport 111 -j ACCEPT
    4. -A INPUT -p tcp -m tcp --dport 111 -j REJECT
    5. -A INPUT -p udp -m udp --dport 111 -j DROP
    6. 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 :(

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


    Quote

    ...

    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
    1. iptables -I INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
    2. iptables -A INPUT -p tcp -m tcp --dport 111 -j REJECT
    3. iptables -A INPUT -p udp --dport 111 -j DROP
    4. 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.

    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
    1. root@FRANC-MACBOOK:/# rpcinfo -T udp -p 1.2.3.4
    2. 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 :) :)

    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?