Posts by franc

    fstrim -a sollte da die Lösung sein.

    Ich hatte im SCP die Speicheroptimierung durchgeführt, dauerte ca. 40 Minuten, danach war das System wieder "schlank" :)
    Danach das do-release-upgrade, das lief auch eine Weile, wobei man dabei sitzen muss und immer wieder die bestehenden Konfigurationsdateien erhalten (mit "N") und dann ging alles noch.

    Ubuntu 18.04 jetzt :)


    Im Moment bin ich an PHP dran, will die 7.4 haben, Ubuntu 18.04 kommt mit der 7.2. Ein Kunde hätte aber gerne die 7.4 (obwohl es eigentlich egal ist, weil die 7.2 ja auch noch eine Weile gepflegt wird, siehe LTS).

    So, heute abend gegen 20 Uhr ist es geplant, das do-release-upgrade auf 18.04 von 16.04 aus.

    Zuerst dann wieder Systemoptimierung durchführen, bin bei 159 von 312 GB belegt:

    df zeigt allerdings nur belegte 54 G an:

    In diesem Fall kann man natürlich beide Schritte kombinieren: Neuen Server anmieten (geht ja auch monatsweise), Snapshot-Abbild mit 14.04-Image transferieren, auf neuem Server alles unter 18.04 zum Laufen bringen (da die neue IP-Adresse nicht im DNS hinterlegt ist, stört das den laufenden Betrieb nicht), und danach DNS-Einträge anpassen. In der Zwischenzeit aufgelaufene Änderungen sind anwendungsspezifisch zu synchronisieren. Dieser Vorgang reduziert eine für Kunden sichtbare Ausfallzeit auf ein Minimum.

    So, heute abend gegen 20 Uhr ist es geplant, das do-release-upgrade auf 18.04 von 16.04 aus.

    Zuerst dann wieder Systemoptimierung durchführen, bin bei 159 von 312 GB belegt:

    Quote


    Es ist eine intensive Speicher-Optimierung notwendig. Diese kann bis zu 54 Minuten andauern.

    Code
    1. #systemctl enable rpc.statd
    2. Failed to execute operation: No such file or directory

    Hm. Ich glaube ich muss erst mal verstehen, was das ist, "rpc.statd".

    Ich habe in der Zwischenzeit in fstab den Parameter eingefügt:

    Code
    1. 1.2.3.4:/voln12345a1 /mnt/storagespace nfs rw,suid,dev,exec,auto,nouser,async,nolock 0 0

    also indem ich defaults durch rw,suid,dev,exec,auto,nouser,async,nolock ersetzt habe, also das nolock angehängt habe.

    Vermutlich hätte ich das nolock auch ans defaults anhängen können, wollte aber nicht so viel experimentieren, immerhin ist es ein "Produktivserver"

    Scheint aber zu gehen - nach Neustart ist er noch da, der storagespace, bis jetzt.

    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 :(