Hallo,
Eine selbst hochgeladene v0.23.0-1 startet sofort problemlos. Kann das jemand bestätigen?
Ja, kann ich! Alles nach v0.23 hat mit meinem VPS20 nicht funktioniert. Ich bin von einem Problem mit der Speichergröße ausgegangen, aber wenn es auch bei einem VPS50 passiert...
Viele Grüße!
Hallo Kraeutergarten,
Nun würde ich mir wünschen, das es eine Funktion gäbe die das umgeht und direkt einen exportierten Snapshot erstellt.
für meinen Ansatz braucht man einen passwortgeschützten ssh-Zugang (mit Schlüsseln wird komplizierter) zu einem Rechner mit ausreichend FP-Speicher:
VM mit Gparted-Image starten, Kommandozeile reicht.
Als root (ggf. sudo su) in der VNC-Konsole für den Export:
dd if=/dev/sda bs=4M | gzip | ssh account@remote 'cat - > /archive/sda.gz'Für eine Prüfsumme (ungetestet)
dd if=/dev/sda bs=4M | md5sum | ssh account@remote 'cat - > /archive/sda.md5'für den Import (Image einspielen)
ssh account@remote 'cat /archive/sda.gz' | gunzip | dd bs=4M of=/dev/sdaAus der VM heraus ist es vermutlich einfacher, als von aussen.
Das gesicherte Image kann man dann auch nach qcow2 konvertieren:
gunzip /archive/sda.gz && qemu-img convert -O qcow2 /archive/sda /archive/sda.qcow2Ach ja, und auch wenn ich die Befehle gewissenhaft aufgeschrieben habe, dd hat nicht ohne Grund Spitznamen wie "DestroyDisk" oder "DeleteData".
VG
Hier mal ein Vergleich zwischen Debian Jessie 32bit und 64bin:
64bit / Netcup-Image
root@jessie64:~# cat /proc/version
Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02)
root@jessie64:~# free
total used free shared buffers cached
Mem: 248168 61432 186736 4416 812 18784
-/+ buffers/cache: 41836 206332
Swap: 3993596 0 399359632bit / Debian-ISO
root@jessie32:~# cat /proc/version
Linux version 3.16.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02)
root@jessie32:~# free
total used free shared buffers cached
Mem: 252092 76168 175924 4420 7752 39876
-/+ buffers/cache: 28540 223552
Swap: 524284 0 524284Beides kurz nach dem Systemstart und mit der Minimal-Installation - Image und ISO enthalten hier bis auf das zusätzlich libc-386 in der 64bit-Version die gleiche Software.
Ich probiers also mal mit der 32bit-Version für die Streichholzschachtel.!
Viele Grüße!
Hallo,
Warum der Server auf dem du bist hier einen Autorisierung erfordert ist natürlich die große Frage.
Gibt es denn noch andere Wege? Ich dachte, das sei normal bei den Netcup-Webhosting-Tarifen?!
Als ich zu Netcup umgezogen bin, hatte ich ein ähnliches Problem: ich wollte mit meinen Perl-Skripten Mails verschicken.
Schließlich habe ich dafür einen StartTLS-Mailclient geschrieben, um über eine im Webhosting Panel erstellte Mailadresse authentifiziert verschicken zu können.
Den Perl-Ansatz habe ich im Thread als ZIP angehängt: Mailversand per Perlskript
Ist nur ohne Perl-Kenntnisse vermutlich nicht verwendbar.
Viele Grüße
Hallo,
Sollte das öfter als einmal pro Woche laufen, oder wieso ist das dort eingefügt worden?
Hintergrund-Infos zum "Wieso" gibts im Thread Neuer Server: Plötzlich sda (anstelle vda)
Ich nehme an, dass der CronJob /etc/cron.d/kernel von Netcup in jedes neue Image eingebaut wird. /etc/cron.d/kernel existiert in der originalen Jessie nicht, ist aber nach meiner Image-Installation da gewesen. Ist der cron.weekly-Aufruf von ubuntu?
cron /bin/sh: 1: fstrim: not found
Bei Debian Jessie liegt fstrim in /sbin. Wo liegt es denn bei ubuntu? Eigentlich sollte der Suchpfad von root ja bei einem Root-CronJob berücksichtigt werden.
Funktioniert der Aufruf aus cron.weekly denn tatsächlich? Was sagt
root@vserver:~# which fstrimViele Grüße.
Hallo,
die Alternative ist ein Webhosting-Paket. Da ist es einfacher, solche Sachen wie Emails anzulegen, und es ist professionell administriert.
Zum Spielen und spezielle Aufgaben kann man immer noch einen VPS hinzumieten und dem einen Namen aus der eigenen Domain geben.
Jedenfalls mache ich es so, denn ich will wegen Schludrigkeit keine Mails verlieren.
Viele Grüße.
Hallo,
Die shell schein .bash_aliases und .bashrc einfach zu ignorieren.
Versuchs mal mit .bash_profile statt .bashrc . Bei mir gehts damit.
Ich hätte übrigens gerne, um die Logs über die Shell zu durchforsten und zu analysieren,
Viele Grüße
Hallo,
-: /usr/bin/perl: No such file or directory
Hab gerade selbst einen CronJob eingerichtet.
Dafür habe ich ein Shell-Skript geschrieben:
ssh account@webhost
$ mkdir /local
$ vi /local/script.sh
#!/bin/bash
echo "Hello world"
$ chmod 700 /local/script.sh"/local/script.sh" habe ich dann als Befehl des Systembenutzers in der Weboberfläche angegeben. Funktioniert.
Also laufen die CronJobs anscheinend im chroot-Kontext des Systembenutzers. Nur das, das über ssh geht, geht auch in den Cronjobs. Perl gibt es nicht über ssh:
$ ls /bin
basename curl file gzip more pwd svn unix2dos
bash date find head mv rm tail unzip
bzip2 diff ftp id mysql rmdir tar vi
cat dos2unix git less mysqldump scp touch vim
chmod du grep ln nano sed tr wget
convert env groups ls patch sh true zip
cp false gunzip mkdir php ssh unameViele Grüße.
Hallo,
wir können die Konfigurationsumgebung nur ändern, wenn wir wissen das der Kunde definitiv ein neues Image installiert. Wir können ja derartige Änderungen nicht auf ein laufendes System anwenden. Denn spricht der Kunde in der VM bislang /dev/vda an, wäre es eine Katastrophe wenn wir statt dessen einfach /dev/sda bereitstellen
Davon gehe ich aus!
Meine Frage ging eher in die Richtung, ob es OS-spezifische Vorkonfigurationen der Betriebsumgebungen in den Images gibt. Und werden - sofern man nach einer Image-Installation eine ISO-Installation durchführt - bei einer ISO-Installation immer Standard-Betriebsumgebungen oder die letzte verwendete Image-Betriebsumgebung ausgeführt. Sorry, bin halt neugierig! 
Das würde der Image-Installation gegenüber der ISO-Installation einen klaren Vorteil verschaffen.
Dann sind grundsätzlich die optimierten Images gegenüber den ISOs zu bevorzugen!
Viele Grüße!
Hallo,
Wäre es denn noch möglich das mir einer den Cronjob verrät der standartmäßig hinterlegt ist
? Oder wäre die discard option im fstab besser?
klar: Standard-CronJob & Fstab-Beispiel
$ cat /etc/cron.d/kernel
...
59 6 * * * root /sbin/fstrim /
$ cat /etc/fstab
...
UUID=b580a07d-4a51-43a8-b028-997d26fcc7f1 / ext4 discard,errors=remount-ro 0 1
...Besser ist vermutlich der CronJob, weil der zu einem Zeitpunkt, zu dem keine Last besteht, das Trimmen durchführen kann.
Ich frage mich trotzdem, warum man das als RootServer/VPS-Kunde haben möchte. Der Vorteil der effizienten Festplattenverwaltung liegt im Host, nicht in der VM. Deutliche Performance-Vorteile sehe ich persönlich nicht!
Aber eine andere Frage: Gehören zu einem Netcup-Image neben dem OS in der VM und den Konfigurationsskripen in der VM auch Parameter, die die Betriebsumgebung der VM fest definieren?
Der Unterschied zwischen virtio und virtio-scsi beispielsweise wird ja genau über diese Betriebsumgebung gesteuert, das OS in der VM reagiert nur (sofern es dazu in der Lage ist).
Hallo,
beim Erstellen des Zertifikats erscheint u.a. folgende Meldung:
Hier ein paar Screenshots:
https://forum.netcup.de/index.php?page=Attachment&attachmentID=1115
mit dem Satz
Zitatsolange Sie nichts an den DNS-Einstellungen der Domain ... ändern
Wie ist das zu verstehen?
Ich würde gerne die eine oder andere Subdomain auf eine andere IP zeigen lassen. Eine hatte ich schon zuvor angelegt, die auf meinen VPS zeigt, und dort dann ein weiteres Zertifikat für diese Subdomain erstellt. Noch bin ich also save. Aber eigentlich möchte ich mir Option, weitere Zertifikate auf diese Weise auf dem VPS zu erstellen und zu nutzen, nicht verschließen.
Welche DNS-Einstellungen darf man konkret nicht ändern, damit das Erneuern nicht schief geht?
Hat da jemand Erfahrungen? Oder kann der Support das erläutern?
Viele Grüße
Hallo,
Es hat nichts mit den neuen Tarifen zu tun, sondern mit einer Umstellung der vorgefertigten Images. Bei einer Neuinstallation eines jeden auf KVM basierenden Server mit einem aktuellen Image (Debian Jessie, Ubuntu 16, Fedora 24 etc.) erfolgt die Umstellung von "vda" auf "sda".
das verstehe ich anders. Es hat nichts mit den Images aber alles mit dem kvm-Aufruf zu tun.
Der Thread hat mich dazu gebracht, damit auf meiner Entwicklermaschine zu experimentieren. Dort herrscht ständig Platzmangel, da alle Projekte ihre eigene KVM-Jessie haben. Ich starte meine VMs immer direkt per Kommandozeile mit kvm.
Bisher habe ich meine Images mit
-drive file=$DISK_IMG,index=0,media=disk,format=$DISK_IMG_FORMAT,if=virtio,cache=none
eingebunden und die Partitionen waren vda's.
Nach der Änderung in
-drive file=$DISK_IMG,index=0,media=disk,format=$DISK_IMG_FORMAT,if=none,cache=none,id=drive0,discard=unmap \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,bus=scsi0.0,drive=drive0
waren die Partitionen in sda's geändert.
Dank der allgemein bei Jessie verwendeten UUIDs in der fstab war keine weitere Änderung notwendig.
Den großen Vorteil bringt nun die Option discard=unmap. Damit kann nicht benutzter Speicherplatz im Host wieder freigegeben werden (eigentlich ne SSD-Geschichte: killerbees19 hat ja fstrim erwähnt).
Das kann man dann an den Images sehen, wenn man in der VM mal trimmt:
xxx@yyy:~/Qemu VMs/zzz$ ssh root@zzz
root@zzz:~# fstrim -a -v
/: 25,2 GiB (27044970496 bytes) trimmed
root@zzz:~# exit
xxx@yyy:~/Qemu VMs/zzz$ ls -lhs
insgesamt 1,9G
1,9G -rw------- 1 xxx xxx 3,4G Aug 14 22:09 zzz.qcow2
0 -rw-r--r-- 1 xxx xxx 0 Aug 14 19:13 kvm.log
4,0K -rwx------ 1 xxx xxx 849 Aug 13 17:59 vm.sh
xxx@yyy:~/Qemu VMs/zzz$Der Effekt ist also deutlich: links der tatsächlich belegte Platz von zzz.qcow2, rechts die Dateigröße: qcow2 als Sparse-File.
Das Potential liegt IMHO vor allem in dem Shrinken der Images ohne Rumhampeln (s. z.B. Shrink Qcow2 Disk Files - Proxmox VE).
Dieser Vorteil wird in den Netcup-Images auch genutzt. Das von mir genutzte Jessie-Image (installiert in den letzten Tagen) hatte zwar keine discard-Option in der /etc/fstab, mit der der Speicherplatz von der VM sofort zurückgegeben wird, es existiert aber ein Netcup-spezifischer CronJob, der fstrim ausführt.
Der Vorteil für Netcup ist, dass der Festplattenplatz effizienter genutzt werden kann. Der mittelbare Vorteil für den Kunden ist der gute Preis.
Falls ich falsch liege oder was vergessen habe, bitte Rückmeldung!
Viele Grüße!
Hallo perryflynn,
danke für den Tip!
Einen Userspace-Packagemanager für Perl kenne ich zwar nicht, aber nachdem ich die entsprechenden Verzeichnisse von meinem lokalen Centos6 und meinem lokalen Debian8 kopiert und zum Library-Path hinzugefügt habe, funktioniert es jetzt auch.
Ich hätte nur gedacht, wenn Perl-Unterstützung im Paket angeboten wird, dann stehen solche grundlegenden Module zur Verfügung.
Hab das Ergebnis nochmal angehängt. Wer mir nicht traut (warum auch), kann sich sein eigenes Paket aus Centos6 und Debian8 zusammenstellen.
Das Skript mailcgi muss natürlich mit einem selbst erstellten Mailaccount angepasst werden.
Viele Grüße.
Tja, die Lösung lautet
ZitatBitte haben Sie Verständnis, dass wir in einer Shared Webhosting Umgebung keine individuellen Anpassungen vornehmen können.
Alternativ verwenden Sie PHP statt Perl für den Mailversand.
Dann nicht.
Hallo,
habe seit kurzem einen Webhosting-Account. Bisher (alter Provider) habe ich immer Perl-Skripte für mein Mail-Formular verwendet und den lokalen SendMail aufgerufen. Dies geht anscheinend nicht.
Wie kann ich das jetzt bewerkstelligen? Meine bisherigen Skript-Versuche verwenden die Module Net::SMTPS oder Net::SMTP::TLS::ButMaintained, um eine von mir erstellte Mailadresse mit STARTTLS und Authentifizierung anzusprechen. Von meiner Jessie zuhause kann ich so Mails per Perl verschicken. Diese Module stehen aber im Webhosting-Account nicht zur Verfügung.
Insgesamt scheint die Perlversion auf meinem Webhosting-Account mit 5.10 ziemlich alt zu sein. Meine Jessie, die ich für meine Versuche verwendet habe, hat 5.20 und selbst Wheezy hat 5.14.
Gibt es einen Standardweg für den Mailversand aus Perl heraus oder können noch die erforderlichen Module nachinstalliert werden?
Im angehängten Archiv ist ein Skript, dass funktionieren würde, wenn das Perl-Modul Net::SMTP::SSL bereitgestellt würde.
Wird es aber nicht, deshalb auch kein Archiv mehr.
Viele Grüße!
