Community-list

community-list@lists.vpsfree.cz

1077 discussions

MariaDB nefunguje se systemd 233 v kontejneru
by Jiří Eischmann ml. 11 Nov '17

11 Nov '17

Ahoj, při upgradu na Fedoru 26 jsem nebyl schopný nastartovat MariaDB s chybovými hláškami: mariadb.service: Failed at step KEYRING spawning /usr/libexec/mysql- check-socket: Permission denied Failed at step KEYRING spawning /usr/libexec/mysql-wait-stop: Permission denied Dočetl jsem se, že MariaDB má problémy se systemd 233 v kontejneru. Očividně to není problém jenom Fedory, protože v Ubuntu řeší něco podobného: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1691096 Ve Fedoře jsem to nahlásil: https://bugzilla.redhat.com/show_bug.cgi?id=1471306 a rollbackem se vrátil zpátky na F25. Tak si dejte na upgrade na systemd 233 pozor, používáte-li MariaDB. Jirka

6 8

Monitorovací software
by Jan B. Kolář 11 Nov '17

11 Nov '17

Ahoj všem, obracím se na Vás s prosbou o radu. U nás v rodině jsem v oblasti IT taková "holka pro všechno". Starám se jak o soukromé, tak firemní stroje, síť, server, webovky, atd. Nyní mi to však trochu začíná přerůstat přes hlavu a hledám nějaký monitorovací software, přes který bych byl schopen zjišťovat problémy, případně jim předcházet. Moji rodiče provozují 5 maloobchodních prodejen, já provozuji další dvě (ano, IT není můj hlavní obor činnosti :-D). Všechny lokality které spravuji mám obhospodařované Mikrotiky a propojené do jedné lokace pomocí IPSec tunelů. Na všech provozovaných PC mi běží Debian. Celkem se jedná o zhruba 7 routerů a 20 zařízení (PC, tiskárny, NAS). Moje představa je taková, že bych na centrální lokaci nainstaloval server, který by všechna zařízení monitoroval. Díval jsem se na internetu a zaujali mě dva programy - LibreNMS a Graylog. Můj první problém ale je, že nevím, co přesně chci sledovat. A tak si nejsem úplně jistý, jestli jsou tyto programy pro mě vhodné. Napadly mě v podstatě dvě věci, který by asi byly dobré: 1) Ukládání logů ze strojů - to bych asi využil v případě řešení problémů, proč něco nefunguje 2) Dlouhodobá statistika - třeba provozu na routerech, využití disku a paměti na PC. Dle toho, jak doufám, bych mohl problémům předcházet (např. zvýšený provoz na routeru nebo třeba nadměrné vytížení CPU by mohlo znamenat malware) Nedoporučili byste mi prosím nějaký vhodný zdroj informací (web, ebook), který by mě posunul dál? Určitě ocením i rady/komentáře, pokud jste už něco podobného řešili. Předem Vám děkuji! Honza

8 9

Vagrant libvirt - malý prostor na hdd
by Petr Parolek 05 Nov '17

05 Nov '17

Ahoj, nechápu jednu věc, která mě trápí a nedaří se mi vyřešit. Disk má při vytvoření virtuálu stále má velikost přes 9GB. Přitom mám ve Vagrantfile mám nastaveno mnohem vícr # -*- mode: ruby -*- # vi: set ft=ruby : Vagrant.configure("2") do |config| config.vm.synced_folder ".", "/vagrant", disabled: true config.vm.define :server do |server| server.vm.box = "debian/stretch64" server.vm.provider :libvirt do |domain| domain.storage :file, :size => '40G', :type => 'raw' domain.memory = 3648 domain.cpus = 8 domain.nested = true domain.volume_cache = 'none' domain.autostart = true end end end Setkal se tím někdo? Mám ho na playground VPS. Díky za rady. Petr Parolek

3 13

Klonování virtuálu opravuje aplikace?
by Stanislav Vasko 18 Oct '17

18 Oct '17

Zdravím, mám velice zajímavou zkušenost. Moje Django aplikace začala padat jakmile odešlu email. Nejspíše nějaký problém mezi Python-Django-WSGI, možná je v tom namočený i Apache. Nicméně, abych zjistil co se děje, virtuál a jsem oklonoval, zapl debug mód a …. žádná chyba. Email odešel, aplikace poděkovala a svět se točil dál… WTF? Vrátím do DEBUG=False, opět pohoda. No totok… Než si tu ukroutím hlavu a utestuju virtuál, může někdo chytřejší poradit zda je mezi VPS a VPS na playgroundu, které bylo klonováno, nějaký rozdíl co by mohl hrát roli pro výše zmíněné technologie a posílání emailu? Nebo Playground rovnou zdrojáky opravuje :)? Mám na virtuálu, tedy i na klonu, nějakou homo-domo konfiguraci posílání emailu aby to vůbec chodilo, ale to se zklonovalo i s chybami co jsem na tom spáchal a tak to asi nemůže mít vliv. Možná, pokud Django fungovalo, to asi stejně nehraje roli, protože posílám přes nastavení SMTP a smtp.seznam.cz. Co jsem tak pohledal, na Ubuntu 14 je údajně stará verze WSGI, nicméně před pár dny ještě vše jelo a opět: klonoval jsem, takže mám shodné nastavení, aplikaci i verze aplikací, tudíž neměl by být vliv, chyby by měly být shodné. Měly by… :) Díky za nápady, mezitím zkusím opravit tu verzi WSGI přes PIP a našroubováním do Apache, když už Ubuntu se nenamáhá po létech aktualizovat. Ale přesto budu rád za jakékoliv tipy, hlavně pro budoucnost, takto nikdy nevím zda na produkci poběží co mi běží doma i přes shodné verze knihoven. Hezký den, Standa Ing. Stanislav Vasko | výkonnostní marketing, webdesign a analytika tel: +420 602 282 686 <tel:%2B420%20602%20282%20686> email: vasko(a)vaskonsulting.cz <mailto:vasko@vaskonsulting.cz> web: www.vaskonsulting.cz <http://www.vaskonsulting.cz/>

9 10

Re: [vpsFree.cz: community-list] Prosba - nefunkncni virt-manager
by René Langer 06 Oct '17

06 Oct '17

Ahoj, není to problém virt-manageru, ale hlavně libvirt. Nespustí se hypervisor libvirt qemu:///system, jak je v logách níže a virt-manager se nemá k čemu připojit. Libvirt chodí jen na OpenVZ šablonách distribuce Alpine Linux, Debian 8 a CentOS 7.1, viz. KB https://kb.vpsfree.cz/navody/vps/kvm. Jinak Qemu/KVM chodí například na Debian 9 či Ubuntu 16.04, jen se musí ovládat pomocí init skriptů, místo libvirt (virt-manageru). Renda _____________________________________________________________ > Od: Tomas Meszaros <meszaros(a)advice.sk> > Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> > Datum: 06.10.2017 20:10 > Předmět: Re: [vpsFree.cz: community-list] Prosba - nefunkncni virt-manager > mne sa to podarilo rozchodit na debian 8 jedine arty Dňa 6. 10. 2017 o 17:07, Richard Korinek <richard.korinek(a)gmail.com <richard.korinek(a)gmail.com>> napísal: Zdravím, snažím se rozchodit KVM a chtěl bych použít virt-manager. Zkoušel jsem ArchLinux 3.6 i Centos 7.3 ale zatím bez úspěchu. Naistaluju qemu, dokonce i spustím image pomocí konfiguračního souboru. Když ale zkouším virt-amanger (po nainstalování všech dependencies, pro Centos viz KB KVM / Centos), tak virt-manager padá s nic neříkající chybou. Kompletní debug:[root@majestatix log]# virt-manager --debug[Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (cli:261) Launched with command line: /usr/share/virt-manager/virt-manager --debug[Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:183) virt-manager version: 1.4.1[Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:184) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-manager:214) PyGObject version: 3.22.0[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-m anager:218) GTK version: 3.22.10Gtk-Message: Failed to load module "canberra-gtk-module"[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:496) libguestfs inspection support: False[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (systray:156) Showing systray: False[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1037) processing cli command uri= show_window= domain=[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1039) No cli action requested, launching default window[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (manager:203) Showing manager[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:401) window counter incremented to 1[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:161) Loading stored URIs:qemu:///system[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:140) Initial gtkapplication activated[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to s tate=Con necting[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:989) Scheduling background open thread for qemu:///system[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1039) libvirt version=3002000[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1041) daemon version=3002000[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1042) conn version=1005003[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1044) qemu:///system capabilities:<capabilities> <host> <uuid>4e56d8c3-7406-4b81-9a01-39d12aae0b60</uuid> <cpu> <arch>x86_64</arch> <pages unit="KiB" size="4"/> </cpu> <power_management/> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> <uri_transport>rdma</uri_transport> </uri_transports> </migration_features> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> <baselabel type="kvm">+107:+107</baselabel> <baselabel type="qemu">+107:+107</baselabel> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default="o n" toggl e="yes"/> <apic default="on" toggle="no"/> <pae/> <nonpae/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default= "on" tog gle="yes"/> <apic default="on" toggle="no"/> </features> </guest> </capabilities> [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:845) Using domain events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:882) Using network events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:902) Using storage pool events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:921) Using node device events[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1426) Error polling connection qemu:///systemTraceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 1404, in tick_from_engine self._tick(*args, **kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1294, in _tick self._hostinfo = self._backend.getInfo() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3739, in getInfo if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self)libvirtError: An error occurred, but the cause is unknown[Pá, 06 říj 2017 16 :47:39 virt-manager 943] DEBUG (connection:1436) An error occurred, but the cause is unknown[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:937) conn.close() uri=qemu:///system[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to state=Disconnected[Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (error:99) error dialog message:summary=Error polling connection 'qemu:///system': An error occurred, but the cause is unknowndetails=Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 385, in _handle_tick_queue conn.tick_from_engine(**kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1437, in tick_from_engine raise e # pylint: disable=raising-bad-typelibvirtError: An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (manager:214) Closing manager[Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:405) window counter decremented to 0[Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:467) No windows found, requesting app exit[Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:491) Exiting app normally.Vypadá to, že na něco nedostane odpověď "ret is None" .... ale netuším na co. Jak v ArchLinuxu tak i v Centosu jsem našel tythle hlášky:Oct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.371+0000: 1420: warning : virNumaGetNodeCPUs:276 : NUMA topology for cell 0 is not available, ignoringOct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.372+0000: 1420: warning : virQEMUCapsInit:1138 : Failed to get host CPUNa Centosu si potom ještě stěžuje KSMTUNEDOct 6 16:57:56 majestatix ksmtuned: /usr/sbin/ksmtuned: line 61: /sys/kernel/mm/ksm/run: No such file or directoryOct 6 16:58:06 maje statix / usr/sbin/irqbalance: WARNING, didn't collect load info for all cpus, balancing is brokenAle netuším, jestli to s tím souvisí. Nemáte někdo nějakou radu co dál prosím? Vzhledem k tomu, že jsem ke stejnému výsledku dospěl jak na Centos tak i na Arch LInux, tak myslím že problém bude někde v nastavení VPSky? Nebo se pletu? Díky za tipy jak dál.R.-- Richard Kořínek ^^^^^^^^^^^^^^ email: richard.korinek(a)gmail.com <richard.korinek(a)gmail.com>phone: +420 604 777 044 _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz <Community-list(a)lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list ---------- _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>

1 0

Prosba - nefunkncni virt-manager
by Richard Korinek 06 Oct '17

06 Oct '17

Zdravím, snažím se rozchodit KVM a chtěl bych použít virt-manager. Zkoušel jsem ArchLinux 3.6 i Centos 7.3 ale zatím bez úspěchu. Naistaluju qemu, dokonce i spustím image pomocí konfiguračního souboru. Když ale zkouším virt-amanger (po nainstalování všech dependencies, pro Centos viz KB KVM / Centos), tak virt-manager padá s nic neříkající chybou. Kompletní debug: [root@majestatix log]# virt-manager --debug [Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (cli:261) Launched with command line: /usr/share/virt-manager/virt-manager --debug [Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:183) virt-manager version: 1.4.1 [Pá, 06 říj 2017 16:47:38 virt-manager 943] DEBUG (virt-manager:184) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'> [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-manager:214) PyGObject version: 3.22.0 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (virt-manager:218) GTK version: 3.22.10 Gtk-Message: Failed to load module "canberra-gtk-module" [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:496) libguestfs inspection support: False [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (systray:156) Showing systray: False [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1037) processing cli command uri= show_window= domain= [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:1039) No cli action requested, launching default window [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (manager:203) Showing manager [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:401) window counter incremented to 1 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:161) Loading stored URIs: qemu:///system [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (engine:140) Initial gtkapplication activated [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to state=Connecting [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:989) Scheduling background open thread for qemu:///system [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1039) libvirt version=3002000 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1041) daemon version=3002000 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1042) conn version=1005003 [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1044) qemu:///system capabilities: <capabilities> <host> <uuid>4e56d8c3-7406-4b81-9a01-39d12aae0b60</uuid> <cpu> <arch>x86_64</arch> <pages unit="KiB" size="4"/> </cpu> <power_management/> <migration_features> <live/> <uri_transports> <uri_transport>tcp</uri_transport> <uri_transport>rdma</uri_transport> </uri_transports> </migration_features> <secmodel> <model>none</model> <doi>0</doi> </secmodel> <secmodel> <model>dac</model> <doi>0</doi> <baselabel type="kvm">+107:+107</baselabel> <baselabel type="qemu">+107:+107</baselabel> </secmodel> </host> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default="on" toggle="yes"/> <apic default="on" toggle="no"/> <pae/> <nonpae/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <emulator>/usr/libexec/qemu-kvm</emulator> <machine maxCpus="240">pc-i440fx-rhel7.0.0</machine> <machine canonical="pc-i440fx-rhel7.0.0" maxCpus="240">pc</machine> <machine maxCpus="240">rhel6.0.0</machine> <machine maxCpus="240">rhel6.1.0</machine> <machine maxCpus="240">rhel6.2.0</machine> <machine maxCpus="240">rhel6.3.0</machine> <machine maxCpus="240">rhel6.4.0</machine> <machine maxCpus="240">rhel6.5.0</machine> <machine maxCpus="240">rhel6.6.0</machine> <domain type="qemu"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> <domain type="kvm"> <emulator>/usr/libexec/qemu-kvm</emulator> </domain> </arch> <features> <cpuselection/> <deviceboot/> <disksnapshot default="off" toggle="no"/> <acpi default="on" toggle="yes"/> <apic default="on" toggle="no"/> </features> </guest> </capabilities> [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:845) Using domain events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:882) Using network events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:902) Using storage pool events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:921) Using node device events [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1426) Error polling connection qemu:///system Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/connection.py", line 1404, in tick_from_engine self._tick(*args, **kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1294, in _tick self._hostinfo = self._backend.getInfo() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3739, in getInfo if ret is None: raise libvirtError ('virNodeGetInfo() failed', conn=self) libvirtError: An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:1436) An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:937) conn.close() uri=qemu:///system [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (connection:571) conn=qemu:///system changed to state=Disconnected [Pá, 06 říj 2017 16:47:39 virt-manager 943] DEBUG (error:99) error dialog message: summary=Error polling connection 'qemu:///system': An error occurred, but the cause is unknown details=Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 385, in _handle_tick_queue conn.tick_from_engine(**kwargs) File "/usr/share/virt-manager/virtManager/connection.py", line 1437, in tick_from_engine raise e # pylint: disable=raising-bad-type libvirtError: An error occurred, but the cause is unknown [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (manager:214) Closing manager [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:405) window counter decremented to 0 [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:467) No windows found, requesting app exit [Pá, 06 říj 2017 16:47:44 virt-manager 943] DEBUG (engine:491) Exiting app normally. Vypadá to, že na něco nedostane odpověď "ret is None" .... ale netuším na co. Jak v ArchLinuxu tak i v Centosu jsem našel tythle hlášky: Oct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.371+0000: 1420: warning : virNumaGetNodeCPUs:276 : NUMA topology for cell 0 is not available, ignoring Oct 6 17:04:35 majestatix libvirtd: 2017-10-06 15:04:35.372+0000: 1420: warning : virQEMUCapsInit:1138 : Failed to get host CPU Na Centosu si potom ještě stěžuje KSMTUNED Oct 6 16:57:56 majestatix ksmtuned: /usr/sbin/ksmtuned: line 61: /sys/kernel/mm/ksm/run: No such file or directory Oct 6 16:58:06 majestatix /usr/sbin/irqbalance: WARNING, didn't collect load info for all cpus, balancing is broken Ale netuším, jestli to s tím souvisí. Nemáte někdo nějakou radu co dál prosím? Vzhledem k tomu, že jsem ke stejnému výsledku dospěl jak na Centos tak i na Arch LInux, tak myslím že problém bude někde v nastavení VPSky? Nebo se pletu? Díky za tipy jak dál. R. -- Richard Kořínek ^^^^^^^^^^^^^^ email: richard.korinek(a)gmail.com phone: +420 604 777 044

2 1

Pomoc se stánkem Alpine Linuxu na LinuxDays
by Jakub Jirutka 05 Oct '17

05 Oct '17

Ahoj, Hody mě ukecal, abych na LinuxDays udělal stánek pro Alpine Linux. Problém je, že nikomu z komunity se do Prahy nějak moc nechce, takže jsem na to sám. Chtěl bych se tedy zeptat, zda by mi s tím někdo nechtěl pomoci. Hlavně s fyzickým bytím na stánku, abych taky mohl na nějaké přednášky. :) Jakub J.

3 2

Přivez staré knížky na LinuxDays
by Petr Krcmar 03 Oct '17

03 Oct '17

Ahoj všem, vymyslel jsem si takovou věc: mám tu hromadu různých knížek o Linuxu, vývoji, sítích a podobně a chci se jich zbavit. Odvezu je proto na LinuxDays na stánek vpsFree a nechám je tam rozebrat. Máte taky takové? Vezměte je taky, udělají radost někomu dalšímu! Říjen, měsíc linuxové knihy zdarma. -- Petr Krčmář vpsFree.cz

2 1

GDPR - řešení reálných dopadů
by Jiří Pucherna 26 Sep '17

26 Sep '17

Ahoj, právě v rámci jednoho nového projektu začínáme řešit reálné dopady GDPR (General Data Protection Regulation) a to jak ze strany dodavatele aplikace tak ze strany správce serverů (a samozřejmě i pro vlastní interní potřeby). Protože už dva dny procházím internet a na nějaké pořádné informace sem nenarazil (jen spousta obecných řečí) tak otázka zní: nemáte už někdo nějaké konkrétní zkušenosti? Případně jestli by měl někdo zájem se společně se mnou touto problematikou nějak více zabývat a případně pak výstup poskytnou komunitě? Představa je vytvořit soubor konkrétních doporučení pro správce a vývojáře. Jirka -- ------------------------------------------------- Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01 Telefon: +420 724 330 493 | Web: http://www.reklalink.cz --- Tato zpráva byla zkontrolována na viry programem Avast Antivirus. https://www.avast.com/antivirus

6 8

Re: [vpsFree.cz: community-list] GDPR - zkusme to odspoda
by Petr Juhaňák 21 Sep '17

21 Sep '17

Ahoj doplnim treba smluvni ujednani s mzdovou ucetni, uklizeckou A co zalohovani telefonu do cloudu pres gmail? Nas maly datovy audit se nam pomalu rozsiruje. Gdpr jsem jeste nestudoval, ale je mozne ze podnikatele s malym poctem zamestnancu budou na tom lepe. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Libor Boldan <libor(a)boldan.eu> Datum: 21.09.17 20:49 (GMT+01:00) Komu: community-list(a)lists.vpsfree.cz Předmět: [vpsFree.cz: community-list] GDPR - zkusme to odspoda Ahoj, vidim, ze je tu i dost lidi, kteri to resi na firemni urovni. Nicmene bych navrhl to zkusit odspoda. Treba muj pripad. Par stovek zakazniku, na ktere povedu: - fakturacni udaje - na to podle me neni treba souhlas a nelze pozadovat smazani. Tady bych si predstavoval, ze zabezpeceni resi dodavatel ucetniho programu. - mail jednak v lokalnim klientu (Thunderbird/Outlook a pod.) a pak v cloudu (Gmail, Seznam a pod.). Jak budu prokazovat zabezpeceni a pripadne po vyzadani smazani? - telefoni/mobilni cislo vedene jednak v sw u mailu a pak v telefonu. Opet - jak budu prokazovat zabezpeceni a pripadne po vyzadani smazani? Predstavuji si to tak, ze zakaznikum poslu mail s oznamenim co na ne vedu a ze mail a cislo mobilu muzou pozadovat smazat. Napiste vase pohledy na tuhle zakladni formu. Dal to pak muzeme rozsirovat. Libor Boldan _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list