Beiträge von franc

Zitat von franc

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:

#df -h
Dateisystem                Größe Benutzt Verf. Verw% Eingehängt auf
udev                        5,9G       0  5,9G    0% /dev
tmpfs                       1,2G    121M  1,1G   11% /run
/dev/vda2                   307G     54G  237G   19% /
tmpfs                       5,9G       0  5,9G    0% /dev/shm
tmpfs                       5,0M    4,0K  5,0M    1% /run/lock
tmpfs                       5,9G       0  5,9G    0% /sys/fs/cgroup
cgmfs                       100K       0  100K    0% /run/cgmanager/fs
46.47.47.210:/voln12345a6  250G    104G  147G   42% /mnt/storagespace
tmpfs                       1,2G       0  1,2G    0% /run/user/0

Zitat von m_ueberall

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:

Zitat

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

#systemctl enable rpc.statd
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:

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.

Nach dem netcup letzte Woche die Server runter gefahren hatte geht es wieder nicht.

Was kann ich denn tun, um den storagespace dauerhaft eingebunden zu lassen?

Die eigene Dummheit auch noch bezahlen lassen

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

Geht

Muss ich das -o nolock ins fstab eintragen?

Oder das rpc.statd automatisch beim Booten starten lassen?

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

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:

# 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

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

#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

Übrigens ging das Erstellen des Image sehr schnell, sekundenschnell vielleicht sogar. Die Speicheroptimierung dauerte ca. 3/4 h, dann beim 2. Mal auch ganz schnell.

Scheints ist ein Image "nur" ein Snapshot.

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:

/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):

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!

Mist, es zeigt mir an, dass kein neues Release da wäre:

#do-release-upgrade
Checking for a new Ubuntu release
No new release found

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

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.

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:

*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

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:

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.