Beiträge von TuxSv748

  • nach Update 42.2 -> 42.3: VirtualBox (5.1.18) startet nicht mehr, bzw. die installierten VMs

  • nach Update 42.2 -> 42.3: VirtualBox (5.1.18) startet nicht mehr, bzw. die installierten VMs

    uname -a

    Code
    # uname -a
Linux diadora512 4.4.114-42-default #1 SMP Tue Feb 6 10:58:10 UTC 2018 (b6ee9ae) x86_64 x86_64 x86_64 GNU/Linux

  • nach Update 42.2 -> 42.3: VirtualBox (5.1.18) startet nicht mehr, bzw. die installierten VMs

    Hallo Forum,


    nach einem Update auf 42.3 nach einer Anleitung von SDB:System upgrade - openSUSE lief zunächst alles glatt, keine Fehlermeldungen etc.


    Wenn ich jetzt aber versuche die im zuvor schon installierten VMs (unter Version 5.1.18 r114002 (Qt5.6.2)) zu starten kommt zunächst die Fehlermeldung via Popup:


    Code
    Kernel driver not installed (rc=-1908)
The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing
'/sbin/vboxconfig'
as root.
where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT


    also habe ich versucht /sbin/vboxconfig aufzurufen. Dies führt zu:

    Code
    # /sbin/vboxconfig
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: failed: Look at /var/log/vbox-install.log to find out what went wrong.


There were problems setting up VirtualBox.  To re-start the set-up process, run
  /sbin/vboxconfig
as root.

    und das log-File /var/log/vbox-install.log:


    hier dann erst mal make oldconfig && make prepare aufgerufen, ... und weiter versucht mit /sbin/vboxconfig alles zu bauen. . .




    mein /usr/src/ sieht folgendermaßen aus:


    Code
    # ll /usr/src/
insgesamt 12
lrwxrwxrwx 1 root root  39 25. Feb 16:17 linux -> linux-4.4.114-42/
drwxr-xr-x 1 root root 448  6. Jan 11:27 linux-4.4.104-18.44
drwxr-xr-x 1 root root  12  6. Jan 11:27 linux-4.4.104-18.44-obj
drwxr-xr-x 1 root root 528 25. Feb 15:59 linux-4.4.114-42
drwxr-xr-x 1 root root  12 25. Feb 12:48 linux-4.4.114-42-obj
drwxr-xr-x 1 root root  12  7. Feb 00:52 linux-obj
drwxr-xr-x 1 root root  70 10. Mai 2017  packages
lrwxrwxrwx 1 root root  34 15. Apr 2017  vboxhost-5.1.18 -> /usr/share/virtualbox/src/vboxhost


    und /lib/modules:


    Code
    ll /lib/modules/
insgesamt 0
drwxr-xr-x 1 root root 408 25. Feb 14:29 4.4.104-18.44-default
drwxr-xr-x 1 root root 400 25. Feb 14:03 4.4.114-42-default
drwxr-xr-x 1 root root  14 15. Apr 2017  4.4.27-2-default
drwxr-xr-x 1 root root  14 25. Feb 14:03 4.4.76-1-default
drwxr-xr-x 1 root root  14 25. Feb 12:50 4.4.79-4-default

    hab ich was übersehen - oder -


    Ich weiß nicht wie und wo die Pfadinformation /usr/src/linux-4.4.57-18.3 zustande kommt im log-File und wie ich diese auf den aktuellen kernel angepasst bekomme.


    Das war jetzt ziemlich umfangreich.
    Für jede Hilfe - Danke schon mal -


    Grüße
    ?(

  • apache/2.2.22: https://<VirtualHost> ja, aber Zugriff auf https://<public ipadress> unterbinden

    GitHub - Neilpang/acme.sh: A pure Unix shell script implementing ACME client protocol


    mir ist noch eingefallen, dass ich im Rahmen der Installation dieses script mehrmals aufgerufen habe mit unterschiedlichen Optionen, weil es nicht gleich beim ersten Mal funktioniert hat.
    Darunter mit der Option '--apache -d <domain1> -d <domain2> -d <domain3>'
    Später mit u.a. mit der option(en) '-d <domain1> -w /etc/apache2/ssl/<domain1> -d <domain2> -w /etc/apache2/ssl/<domain2> -d <domain3> -w /etc/apache2/ssl/<domain3>', und die jeweils in der VirtualHost Section händisch eingetragen.


    /etc/letsencrypt
    existiert nicht, die Daten wurden vom script anderweitig abgelegt, bzw. von mir der Pfad /etc/apache2/ssl/<domain>/. angegeben zum Erzeugen



    Ich geh momentan davon aus, dass jeder Aufruf weitere Certs hinzugefügt hat und insb. der erste Aufruf mit --apache Option noch weiterhin aktiv ist und durch die weiteren Aufrufe des Scripts nicht deaktiviert wurde. Das würde erklären, dass ich bei Aufruf https://<ipadresse> das Cerf mit allen 3 domains geliefert bekomme.


    z.B. eine VirtualHost Section, meine eigentliche domain ist durch <***> ersetzt

    Ok, ich denke ich muss den Server erst mal putzen, d.h. versuchen insb. das per --apache Option erzeugte Cert/Daten mit den 3 domains wieder loszuwerden, dann dürfte sich das ein oder andere Problem damit schon erledigt haben.


    (ps: scheint nicht beschrieben zu sein wie ich zuviel beantragte Certs durch mehrfache acme.sh Aufrufe wieder aus dem System entfernen kann)


    :)

  • apache/2.2.22: https://<VirtualHost> ja, aber Zugriff auf https://<public ipadress> unterbinden

    @Berichtigung, danke erst mal soweit.


    Vielleicht liest das ja noch jemand die nächsten Tage und hat mir noch den einen oder anderen Tip, evtl kommen apache-ich-https auch gar nicht zueinander, denn was mich stört sind 2 Punkte.


    1) unter http/port 80 kann ich mir virtuelle hosts einrichten und behalte das Wissen über die domains bei mir, bzw. demjenigen dem ich es mitteile. Sobald ich den Apache für https/port 443 einrichte posaunt mir der Indianer das hinaus sobald man per https://<ipadresse> darauf zugreift. Direkt sichtbar im Browser und evtl. nicht zu unterbinden (?)


    2) Scheint das Cert selbst zu sein, oder die Weise wie ich es generiert habe. In meinem Fall per acme.sh script, das auch dafür sorgen sollte diese rechtzeitig bei Ablauf zu erneuern. Hierbei habe ich 3 domains angegeben, für 2 domains wurden die Daten *.cer, *.ket etc auf Platte geschrieben, warum eine Domain fehlt muss ich noch ergründen. Auf jeden Fall scheinen in jedem Cert die Informationen über alle 3 domains enthalten zu sein - oder ist das nur mein Eindruck? Ich schließe zumindest darauf, da mir der Indianer bei Zugriff auf https://<ipadresse> ein solches Zertifikat liefert und darin alle 3 domains aufgeführt sind.



    Meine Haustüre sagt ja auch nicht, der Schlüssel passt hier nicht, aber es gibt noch die 3 anderen Türen wo er passt. 8o



    ?(

  • apache/2.2.22: https://<VirtualHost> ja, aber Zugriff auf https://<public ipadress> unterbinden

    Hallo,


    ich habe einen Apache in Version 2.2.22 am Laufen und so aufgesetzt, dass er ganz normal auf http (also port 80) bei ipAdresse und virtual host reagiert.
    Nun wollte ich den Server so erweitern, dass auch https (port 443) unterstützt wird.
    Dies ist mir soweit gelungen, dass die entsprechenden Zertifikate vorliegen und auch für domain1 und domain2 übertragen werden und somit der Zugriff auf die entsprechenden Seiten funktioniert.


    Was mich jetzt noch stört ist, dass wenn man einen Zugriff auf meine öffentliche ipAdresse https://<xxx.xxx.xxx.xxx> macht, im Browser z.B. Firefox eine Fehlermeldung angezeigt wird dass das übertragene Zertifikat nicht passt und nur für die Domains domain1, domain2, ... ausgestellt wurde.


    Dies würde ich nun gerne noch unterbinden, dass das Zertifikat in diesem Fall bei Zugriff per ipAdresse übertragen wird und somit auch die Information über die gehosteten virtuellen Adressen.


    Zusammengefasst:
    http://<ipAdresse> - ja
    https://<ipAdresse> - soll stumm bleiben
    http:// bzw https://<virt.Server> - soll funktionieren


    ps: ich habe auch bereits mit 'SSLStrictSNIVHostCheck off/on' experimentiert, jedoch ohne den entsprechenden Erfolg.


    Gedanken: Ich denke, dass ich mit einer passenden Konfiguration einer default-ssl Einstellung, wie versucht, für den Apache auch nicht unbedingt weiterkommen werde, da das Zertifikat bereits im Vorfeld übertragen wird bevor irgendwelche Konfigurationen wie redirects zum tragen kommen ... ich andererseits für eine ipAdresse kein Zertifikat ausgestellt bekomme und diese sich zudem ja alle 24h ändert.


    Also: wie bekomme ich mein https Zugriff auf die ip Adresse Stumm und behalte gleichzeitig die Anfragen für die virtuellen hosts am Laufen.


    Grüße & Danke
    ?(