Posts by potato

    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:


    Code
    dd if=/dev/sda bs=4M | gzip | ssh account@remote 'cat - > /archive/sda.gz'


    Für eine Prüfsumme (ungetestet)


    Code
    dd if=/dev/sda bs=4M | md5sum | ssh account@remote 'cat - > /archive/sda.md5'


    für den Import (Image einspielen)


    Code
    ssh account@remote 'cat /archive/sda.gz' | gunzip | dd bs=4M of=/dev/sda


    Aus der VM heraus ist es vermutlich einfacher, als von aussen.


    Das gesicherte Image kann man dann auch nach qcow2 konvertieren:


    Code
    gunzip /archive/sda.gz && qemu-img convert -O qcow2 /archive/sda /archive/sda.qcow2


    Ach 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

    Code
    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    3993596


    32bit / Debian-ISO

    Code
    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     524284


    Beides 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

    Code
    root@vserver:~# which fstrim




    Viele 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,

    • cut
    • uniq
    • sort


    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:


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


    Code
    $ 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    uname


    Viele 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! :whistling:


    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

    Code
    $ 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:



    mit dem Satz

    Quote

    solange 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

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

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

    Code
    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

    Quote

    Bitte 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!