Qemu - KVM - langsam und behäbig

vendredi 4 août 2017

Hallo Freunde der Sonne,

Ich mache gerade meine allerersten Erfahrungen mit virtuellen Maschinen + Hardwarevirtualisierung.
Mein Fazit: Die ganze ******e ist kompliziert, fehlerhaft, langsam, und für einen ahnungslosen Anfänger eine echte Qual.

Ich habe folgendes getan:

Ich habe Qemu und KVM installiert.
Ich habe sichergestellt, dass mein Prozessor Hardwarevirtualisierung unterstützt und alle notwendigen Hebel umgelegt, um diese auch benutzen zu können.
Ich habe eine virtuelle Maschine mit qemu installiert.

Ich starte sie immer mit folgendem Befehl:
qemu-system-x86_64 -enable-kvm -hda Windows7.img -cdrom /dev/cdrom -boot d -m 4024 -full-screen

Das funktioniert auch. Aber dann fangen die Probleme erst richtig an. Obwohl ich diese ganze Hardware-Virtualisierungs******e aktiviert habe, ist der Mauszeiger, das Verschieben von Fenstern usw. langsam und schwerfällig. Bereits alte Spiele wie Titan Quest funktionieren nicht, weil das Spiel "die Grafik Engine" nicht initialisieren konnte.

Kann mir jemand sagen, was ich noch machen muss, um ein System aufzusetzen, dass die viel heraufbeschworenen 99% der nativen Performance auch wirklich erreicht, und nicht nur beschissenen Ärger macht und in Wirklichkeit garnicht funktioniert? Meine Hardware ist super, ich habe einen AMD FX6300 Prozessor (6x 3,5 GHz), eine Geforce GTX 1050 TI, 8GB Ram, 240 GB SSD, also recht vernünftige Hardware. Muss ich die Hardwaretreiber im Gastsystem selbst NOCHMAL installieren oder reicht das, wenn die Treiber auf dem Gastsystem funktionieren?

Nochwas: Die Einbindung des CD-Laufwerks ist auch verkackt. Die CD, die ich als erstes einlege, wird erkannt. Wenn ich die CD rausnehme und eine andere einlege, tut die virtuelle Maschine so, als würde immernoch die alte drinnliegen. Wie bitteschön kommt dieser Mist zustande?

Entschuldigt meinen Frust, aber es war wirklich zum Kotzen. Ich könnte nur brechen über diese ******e. Falls ihr trotzdem noch Lust habt mir zu helfen, wäre ich euch LIEBEND dankbar.


openSUSE-Virtualisierung für Debian GNU/Hurd üb. kvm - Paketinstallation schlägt fehl

jeudi 3 août 2017

Hallo zusammen,

ich verwende derzeit einen Acer-Extensa 5230E Laptop und wollte auf meinem openSUSE "Tumbleweed" System, ein Image von GNU/Hurd mit Unterstützung von kvm ausprobieren.

Das Image habe ich heruntergeladen und entpackt und wollte es nun laut README mit folgenden Befehl starten:
Code:

kvm -drive file=debian-hurd*.img,cache=writeback -m 1G
Als Ausgabe bekomme ich (obwohl ich kvm mit zypper install kvm installiert habe) nur folgende Ausgabe:

Code:

If 'kvm' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf kvm

Anschließend habe ich versucht über YaST -> Virtualisierung -> Hypervisor und Tools installieren versucht, kvm zu installieren. kvm-Server habe ich dazu ausgewählt, bekomme aber die Fehlermeldung "Die Paketinstallation ist fehlgeschlagen" und leider keine weiteren Information.


fehler bei osmc dist-upgrade

mercredi 2 août 2017

Hallo

Wollte seit längeren mein osmc/kodi upgrraden.


Code:

sudo apt-get update

sudo apt-get upgrade

Lief nicht sauber durch. Und ich bekam die Meldung es mit "sudo apt-get -f install" zu reparieren.
Leider funktioniert das nicht und ich bekomme immer folgende Meldung:

Code:

dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/perl-modules_5.20.2-3+deb8u8_all.deb (--unpack):
 »/usr/share/perl/5.20.2/App/Prove/State.pm.dpkg-new« kann nicht auf sichere Weise entfernt werden: Die Operation ist nicht erlaubt
dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/perl-modules_5.20.2-3+deb8u8_all.deb

Hatte verucht mittels sudo su / su - und mv /usr/share/perl/5.20.2/App/Prove/State.pm.dpkg-new /tmp
die problematische Datei ins tmp zu verschieben.

Habe die Rechte nicht dazu,
Meine Frage ist was kann eine Datei schützen(move/remove) obwohl man root ist?

Gruß
Klaus


Softwaretests - Einarbeiten in die Erstellung von Testcases?

Hallo zusammen,

ich arbeite bei openSUSE im Übersetzungsteam mit und melde ab und an auch Bugs. Mich würde interessieren, wie man sich in Eigeninitiative zum Softwaretester entwickeln und eventuell kleine Testcases schreiben kann.


Firewall und Emails

Morgen zusammen,

hatte eigentlich nie Probleme mit Emails und meinem Server, aber nun ist irgendwie der Wurm drin. Ich habe vor 2 Tagen eine Firewall mit iptables eingerichtet und sie arbeitet hervorragend. Natürlich habe ich auch getestet ob alle meine Dienste erreichbar sind und ich kann Emails verschicken und empfangen. Nur irgendwie bekomme ich seit dem von 2 Anbietern keine Email. Ich habe mein Passwort auf qt.io geändert und es hat auch geklappt, aber ich habe in den letzten 10 Stunden keine Verifikation Email bekommen, obwohl die rausgegangen sein soll. Das selbe Problem habe ich mit Steam, da kann ich mein Passwort nicht ändern, weil ich keine Email mit einem Code zugeschickt bekomme, den ich brauche. Ist auch 10 Stunden her und hab das nun mehrmals probiert.

Eigentlich glaube ich nicht, dass das an meiner Firewall liegt, da ich mir ja selbst von einem anderen Account auf gmail eine Mail zugeschickt habe und ich auch Mails von anderen Servern bekomme. Hab auch schon in die Logs reingeguckt und von den 2 Anbietern sind keine Mails angetroffen oder wurden abgelehnt. Oder liegt das vielleicht doch an der Firewall? Hier mal meine iptables.

Code:

#!/bin/bash
iptables -F

#important
iptables -A INPUT -m state --state NEW,ESTABLISHED -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -p tcp --sport 22 -j ACCEPT

#http/s
iptables -A INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -p tcp --sport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -p tcp --sport 443 -j ACCEPT

#email
iptables -A INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 143 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -p tcp --sport 143 -j ACCEPT
iptables -A INPUT -m state --state NEW,ESTABLISHED -p tcp --dport 587 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED -p tcp --sport 587 -j ACCEPT

#dns
iptables -A OUTPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT

#apt
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p tcp --sport 443 -j ACCEPT

#localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#ping
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#Drop all other
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP



IP-Adressen in anderen Subnets sichtbar?

mardi 1 août 2017

Guten Tag,

ich habe hier mehrere VLANs für unterschiedliche Zwecke. Mein Server, ein WLAN-Router sowie ein Raspberry Pi sind allerdings tagged am Switch angeschlossen und in allen diesen 3 VLANs.
Nur der Server hat in allen 3 eine entsprechende IP-Adresse, die anderen Geräte nur im 1. VLAN.

VLAN1: 10.0.1.0/26 (Management)
VLAN2: 10.0.2.0/27 (Gast)
VLAN3: 10.0.3.0/28 (Isolated, kein Internetzugriff)

Nun ist es mir letztens passiert, dass ich auf dem Handy das falsche WLAN-Netz gewählt habe und mir letzten Endes im VLAN2 eine IP-Adresse statisch zugewiesen habe (10.0.1.2), welche aber im VLAN1 ist. Natürlich hat der Internetzugriff nicht funktioniert, aber ein Scan via der App Fing (funktioniert auch mit nmap) listete mir dann den Server sowie den Raspberry Pi mit der entsprechenden IP-Adresse aus dem VLAN1 auf. Zugreifen konnte man auf diese zwar nicht, trotzdem fand ich es schon merkwürdig, dass selbst der Raspberry (ohne IP im eigentlichen Subnet) so IP-Adressen ausspuckt, welche er an anderen Interfaces verwendet.

Mein OpenWRT-WLAN-Router hat da nicht mitgespielt, somit scheint es hier auf Debian zurückzuführen, was auf dem Server und dem Pi läuft.

Derzeit stehe ich da ein wenig auf dem Schlauch und wüßte gerne wieso das so ist... Besonders weil ich jedlichen unkontrollierten Zugriff der VLANs untereinander gerne unterbinden würde. Geräte im VLAN3 sollten unmöglich in andere VLANs kommen bzw. durch solche IP-Tricks auch andere Geräte sehen können.

Code:

iface enp1s0 inet static
        address 10.0.1.3
        netmask 255.255.255.192
        gateway 10.0.1.1
        dns-nameserver 10.0.1.3 10.0.1.1
iface enp1s0.2 inet static
        address 10.0.2.1
        netmask 255.255.255.240
iface enp1s0.3 inet static
        address 10.0.3.1
        netmask 255.255.255.248

Vielleicht hat es ja auch was damit zu tun:
Ich habe einen Unterschied bei einem Traceroute festgestellt: Sofern ich bei meinem Router (einer FRITZ!Box 7430) meine externe IP verfolge bekomme ich erst einen Hop auf die interne Router-IP und dann erst auf die Zeil-Adresse. Sofern ich nun bei meinem Server aus z.B. VLAN1 die IP die er im VLAN3 hat verfolge hopt dieser direkt beim 1. Mal dorthin.


Netzwerkprobleme

Hi,
Ich hab Folgendes Problem seit einem Neustart meines Heimservers
Der Ping schwankt extrem sogar im Heimnetz das Problem ist nur von und zu diesem rechner, alle anderen laufen normal
Code:

--- 192.168.178.41 ping statistics ---
16 packets transmitted, 16 received, 0% packet loss, time 15231ms
rtt min/avg/max/mdev = 0.412/283.442/902.381/290.826 ms

Der Bandwdth Test ergibt:
Code:

[ ID] Interval          Transfer    Bandwidth      Retr
[  4]  0.00-10.00  sec  259 KBytes  212 Kbits/sec  38            sender
[  4]  0.00-10.00  sec  157 KBytes  129 Kbits/sec                  receiver

Ausgabe von Ifconfig:
Code:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.40  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 XXXXX  prefixlen 64  scopeid 0x20<link>
        inet6 XXXXXXX  prefixlen 64  scopeid 0x0<global>
        ether d0:50:99:24:a0:60  txqueuelen 1000  (Ethernet)
        RX packets 5026  bytes 3050013 (2.9 MiB)
        RX errors 546  dropped 93  overruns 0  frame 273
        TX packets 5213  bytes 621763 (607.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xf0500000-f0520000

LSPCI:
Code:

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 05)
ETHtool -i
Code:

driver: e1000e
version: 3.3.5.3-NAPI
firmware-version: 0.13-4
expansion-rom-version:
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no


System ist Gentoo mit einem 4.9 Kernel

Hat jemand eine idee woran es liegen kann?
Neustart wurde gemacht, und kabel und ports wurden auch gewechselt ohne erfolg


 

Lorem

Ipsum

Dolor