- Community-list - lists.vpsfree.cz

by Kamil Kukura

Ve vpsAdmin vidím v sekci "DNS resolver (/etc/resolv.conf)" možnost výběru lokálních DNS: ns{1,2}.prg.vpsfree.cz Když ale zkouším jakou mají IP adresu, tak dostávám status: NXDOMAIN, ani zvenku to moc není vidět: https://mxtoolbox.com/SuperTool.aspx?action=dns%3ans1.prg.vpsfree.cz&run=to… Možná má být: ns{1,2}.vpsfree.cz -- Kamil

6 years, 7 months

2
1
0 0

Pomoc s autofs

by Michal Zuber

Zdravim, mam Debian 9 na VPSku a pri instalacii autofs mi sluzba padne s: Oct 02 12:45:08 vps systemd[1]: Starting Automounts filesystems on demand... Oct 02 12:45:08 vps automount[24837]: /usr/sbin/automount: test mount forbidden or incorrect kernel protocol version, kernel protocol version 5.00 or above required. Oct 02 12:45:08 vps systemd[1]: autofs.service: Control process exited, code=exited status=1 Oct 02 12:45:08 vps systemd[1]: Failed to start Automounts filesystems on demand. uname -a Linux nevilleweb.freevps.cz 3.16.6-042stab131.42 #1 SMP Tue Jun 26 21:15:19 CEST 2018 x86_64 GNU/Linux Pozeram lsmod Module Size Used by ale je prazdne, co je novinka pre mna :) Predpokladam bude to kvoli tech. realizaii VPS architektury. Vo vpsAdmin mam povolene FUSE, nevidim automount :( Bolo by fajn to rozchodit. Chcem s nim mountovat sshfs.

6 years, 7 months

2
1
0 0

Přijďte o víkendu na LinuxDays

by Petr Krcmar

Ahoj všem, o víkendu jedeme jako tradičně na LinuxDays, máte možnost nás tam potkat, popovídat si na stánku, podpořit vpsFree.cz a poslechnout si nějaké přednášky. Vstup je zdarma, stačí se zaregistrovat a přinést transparent „vpsFree.cz je nejlepší!“ :-) https://www.linuxdays.cz/2018/ -- Petr Krčmář vpsFree.cz

6 years, 7 months

1
0
0 0

Re: [vpsFree.cz: community-list] Grafické zpracování letáčku

by Petr Krcmar

Dne 27. 09. 18 v 9:19 Vojtěch Havlíček napsal(a): > Ahoj muzu s letackem pomoc Díky všem za rychlé odpovědi, domluvím se zatím s Vojtou napřímo. Mějte hezký prodloužený víkend. -- Petr Krčmář vpsFree.cz

6 years, 7 months

1
0
0 0

Grafické zpracování letáčku

by Petr Krcmar

Ahoj všem, sháním grafika, který by pro vpsFree udělal malý letáček, který se bude rozdávat na konferencích. Podklady mám, potřeboval bych jen někoho, kdo je schopen z toho udělat něco rozumného k vytištění. Pomůžete, prosím, někdo? Díky -- Petr Krčmář vpsFree.cz

6 years, 7 months

1
0
0 0

CouchDB - praktické zkušenosti

by Jan B. Kolář

Ahoj, nemáte tu prosím někdo praktické zkušenosti s CouchDB? Možná si vzpomínáte, že jsem tu před časem psal ohledně pokladního software. Po zvážení všech odpovědí jsem dospěl k názoru, že největší problém pro mne je udržovat synchronizovaná data mezi pokladnami a serverem. Jak věřím, tak CouchDB by pro mne tyto věci dokázala ohlídat, trochu se ale potýkám s nedostatkem informací. Kromě oficiálního manuálu se mi nepodařilo najít příliš stránek, které by o nasazení CouchDB v praxi psaly. Nejsem si jist, zda jsem zcela správně pochopil vnik a řešení konfliktů v CouchDB. Aktuálně řeším problém skladů a skladových položek - myslel jsem, že bych vytvořil dokument "produkt", který by jako jednu z položek měl pole s dvojicemi "sklad":"počet ks". Každá z pokladen by pak odečítala ze svého řádku "sklad":"počet ks". Jestli jsem to však z manuálu pochopil správně, tak každá změna vyvolá změnu celého dokumentu. A v případě, že dojde k výpadku jedné z pokladen, dojde k vytvoření velkého množství konfliktů, které se budou muset řešit ručně. Nebo se mýlím? Napadlo mne to vyřešit tak, že bych vytvořil dokument "sklad" a v něm bych udržoval dvojice "produkt_id":"počet ks". Kvůli nedostatku informačních zdrojů si však nejsem jist, zda je tohle správný přístup k problému. Mohl by mi prosím někdo zkušenější poradit? Díky, Honza -- Jan B. Kolář Zažeň nudu Hodolanská 17, 779 00 Olomouc e-mail:janbivoj.kolar@zazen-nudu.cz www.zazen-nudu.cz

6 years, 7 months

4
5
0 0

vpsAdminOS: AppArmor pro Docker a snap, FUSE, mknod, runlevely a boot OS

by Jakub Skokan

Ahoj, pokud jste na stagingu zkoušeli Docker a při startu kontejnerů jste narazili na chyby ala permission denied při nějakém mountu, bylo to kvůli AppArmoru. Prošli jsme logy z AppArmoru a povolili několik zakázaných mountů, což by vám mělo pomoci. Pokud by stále někomu něco nešlo, napište prosím na podporu nebo IRC. Potřebujeme vědět: chybovou hlášku, ID VPS a jak to reprodukovat. Důležitým posunem vpřed je je podpora pro AppArmor namespaces. Každé VPS nyní běží ve svém AppArmor namespace, kde si může spravovat vlastní profily, ale stále je omezeno nadřazeným profilem z nodu, ze kterého nemůže utéct. To nám umožnilo zprovoznit snap [1] a už není potřeba upravovat službu pro Docker [2]. Aby všechno fungovalo, bylo potřeba do našeho kernelu doplnit patche pro AppArmor, které se zatím nedostaly do upstreamu [3]. Návod na instalaci snapu v Ubuntu viz KB: https://kb.vpsfree.cz/navody/vps/vpsadminos/snap snap ve VPS vyžaduje squashfuse, což je možné díky tomu, že jsme aktualizovali na Linux 4.18, který podporuje FUSE v user namespace. Tím pádem fungují i další souborové systémy využívající FUSE, např. sshfs. Linux 4.18 přinesl změnu v chování `mknod` v user namespace. Do verze 4.18 `mknod` v user namespace nebyl povolen, takže se všechny zařízení v `/dev` ve VPS musely bind-mountovat z nodu. Linux 4.18 `mknod` v user namespace povoluje, ale trochu zvláštně [4]. `mknod` je povolen nad souborovými systémy, které patří do user namespace volajícího procesu (např. když si mountnete tmpfs), ale pak s těmi zařízeními nejde pracovat, a to vůbec. `open()` skončí s "permission denied". Je to zpětně nekompatibilní změna, která rozbíjí userspace [5, 6]. Nemohli jsme to takto nasadit, protože by přestaly fungovat systemd služby využívající `PrivateDevices`. Rozhodli jsme se `mknod` ve VPS povolit [7] na libovolném souborovém systému a současně umožnit s takto vytvořenými zařízeními pracovat. Můžeme si to dovolit, protože přistup k zařízením ve všech VPS hlídá `devices` cgroupa. Teď jsme dosáhli stejného chování jako na OpenVZ: vytvořit jde jakékoli zařízení, používat lze jen ty, u kterých to node povolí. Takže např. není problém ve VPS rozbalit nebo vytvořit libovolný archiv nějakého systému obsahující jakékoli zařízení, to do teď nebylo možné. vpsAdminOS dostal runlevely [8], zatím máme dva: `default` a `single`. V `default` naskočí všechny služby a startují VPS, v `single` se spustí jen getty pro login. Výchozí runlevel se vybere buď při sestavení OS, nebo při bootu v zavaděči. Runlevel `single` bude důležitý zejména při řešení problémů a manuálním zásahům na nodech. No a nakonec jsem pracoval na několika potřebných optimalizacích při bootu OS. Na OpenVZ nodech jsou v bootovacím procesu následující problémy: při importu ZFS poolů a připojování datasetů se nejde do systému přihlásit a neukazuje se žádný postup. VPS se začnou startovat až když jsou všechny datasety připojeny, což na velkém a delším dobu používaném poolu může trvat 5, 10 nebo i 15 minut. Během této doby nemáte tušení, jestli se pool importuje, datasety připojují, nebo jestli se to na něčem zaseklo a nic se neděje... Reboot do single user režimu, kde si pool importneme svépomocí, pak zbytečně prodlužuje dobu výpadku. Ve vpsAdminOS to řešíme mnohem lépe. Za prvé, ZFS pooly se importují paralelně se spouštěním ostatních služeb a neblokují tak přihlášení do systému. Na konzoli se jde přihlásit hned a spustí se i SSH. Postup importu a připojování datasetů pak jde sledovat v syslogu [9], takže admin má přehled co se děje a jak dlouho to ještě může trvat. Za druhé, nepřipojujeme všechny datasety najednou, ale postupně až když jsou potřeba pro start VPS. VPS se startují hned po importu poolu a každé pak čeká jen na připojení svého vlastního datasetu a ne na datasety všech ostatních VPS na nodu. Tyto změny nám mohou ušetřit až desítky minut při výpadcích. [1] https://snapcraft.io [2] https://kb.vpsfree.cz/navody/vps/vpsadminos/docker?do=diff&rev2[0]=15287438… [3] https://gitlab.com/apparmor/apparmor/tree/master/kernel-patches [4] https://patchwork.kernel.org/patch/10422495/ [5] https://patchwork.kernel.org/patch/10509655/ [6] https://github.com/systemd/systemd/pull/9483 [7] https://github.com/vpsfreecz/vpsadminos/blob/master/os/packages/linux/patch… [8] https://vpsadminos.org/os/runlevels/ [9] https://vpsadminos.org/os/pools/#monitoring-import-progress Jakub

6 years, 8 months

1
0
0 0

mailbox

by Petr Bolf

zdravím, nechci na vpsfree řešit maily. Používám vpsfree na webový server, na git repozitáře, na databáze, ale maily řešit enchci a rád bych to přenechal nějaké službě. Měl jsem to doteď na hostingu, ale ten hodlám zrušit (nač hosting, když mám vpsfree :-) ). Uvažoval jsem o přesun mailů na profi seznam mail, ale narazil jsem na to, že nepodporují vnořené složky, tedy klasickou stromovou strukturu adresářů. Mají jen něco, čemu říkají "vlastní složky" a mohou být jen v kořenovém adresáři malilů. Hledám tedy dobrý mailbox hosting. Jak to řešíte Vy? Provozujete na vpsfree weby a máte maily někde jinde? Kde? díky Petr Bolf

6 years, 8 months

20
30
0 0

FirewallD

by Jan Khardix Staněk

Ahoj lidi, hraju si s nastavováním firewallu na VPS, a pokouším se o přechod ze Shorewall na FirewallD. U toho druhého mám ale problém se startem, kdy vyhodí následující chybu a neuplatní žádná pravidla: > ERROR: Failed to read file > "/proc/sys/net/netfilter/nf_conntrack_helper": > [Errno 2] No such file or directory: > '/proc/sys/net/netfilter/nf_conntrack_helper' Tahle chyba ve mě budí podezření, že mi se stávajícím jádrem (a potažmo tedy pod OpenVZ) firewalld nepojede, protože je jádro moc staré. Dá se s tím něco dělat, nebo musím počkat na vpsAdminOS? Díky za rady, Khardix

6 years, 8 months

3
3
0 0

NBD OnSite Supermicro

by Libor Boldan

Ahoj, zatim jsme vyuzivali sluzeb Abacusu, ale ted jsem zjistil, ze Supermicro ma i vlastni. Nevite, kdo to pro ne u nas zajistuje? A jake jsou s tim zkusenosti? Libor Boldan

6 years, 8 months

3
2
0 0

Navod pre NixOps (priklad nginx / phpfpm)

by sorki

Ahoj, do kb som pridal navod pre pouzitie NixOps na vpsFree - https://kb.vpsfree.cz/navody/vps/vpsadminos/nixops Pomocou NixOps je mozne spravovat NixOS virtualy podobne ako Ansible/salt a vsak s mnohymi vyhodami (atomicke update-y, rollbacky). NixOps je teraz mozne testovat oproti vpsFree VPSkam - idealne nahodit NixOS VPS na staging node a skusat. Navod odkazuje na vzorovy deployment, ktory obsahuje priklady konfiguracie nginx a php-fpm: https://github.com/vpsfreecz/example-nixops-deployment/ - machines/hello.nix obsahuje priklad statickej konfiguaracie nginx - machines/world.nix pouziva nginx a fgci spolu s php-fpm poolom definovanym v modules/phpfpm.nix Pokial narazite na problemy alebo mate otazky nevahajte sa opytat (mailom sem alebo 'srk' na IRC kanaloch). -- Richard Marko

6 years, 8 months

1
0
0 0

Konfigurace a užití nginx + php-fpm - jak na to?

by Martin Myška

Zdravím, tak jsem se dokopal k zaměření se na nginx a to způsobem úplného odstranění apache a jetí pouze na nginx. Každopádně by mě zajímalo, zda někdo z Vás u sebe hostuje weby na nginx s php-fpm jakou používáte konfiguraci? Dost by mi to pomohlo, kdyby se někdo podělil. Díky moc a open-source zdar! S pozdravem, *Martin Myška*

6 years, 8 months

15
24
0 0

Jak udelat patch pro https://vpsadmin.vpsfree.cz/ ?

by Wolf

Ahoj, rad bych udelal maly patch pro https://vpsadmin.vpsfree.cz/, ale nejsem schopen nikde najit prislusny repozitar, proti kteremu by se to dalo udelat. Na github jsem koukal, ale nenasel :/ Mohl by mne nekdo postrcit spravnym smerem? Diky, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

6 years, 8 months

5
11
0 0

vpsAdminOS: instalace, aktualizace, nasazení a síťování

by Jakub Skokan

Ahoj, během prázdnin jsme pracovali na spoustě zajímavých věcí, které bychom vám chtěli ukázat. I když je vpsAdminOS primárně live systém, občas se hodí možnost nainstalovat systém na disk, např. když ho chcete provozovat na jednom serveru a nemáte PXE. Instalace probíhá stejně jako byste instalovali NixOS: naformátujete disky, vygenerujete config, upravíte ho a spustíte instalační program, viz dokumentace [1]. Jako zavaděč je podporován grub a snadno lze integrovat i SSH v initrd pro odemykání šifrovaných disků, stejně jako v NixOS. Pro aktualizování běžícího nebo nainstalovaného systému jsme připravili dva nástroje: os-rebuild [2] (ala nixos-rebuild) a nixops [3, 4] (fork, který přidává podporu pro vpsAdminOS). os-rebuild se dá použít přímo z nainstalovaného systému, ale dá se tím aktualizovat i jiný stroj přes SSH. nixops pak řeší správu větší sítě serverů, asi něco jako terraform+ansible v jednom pro NixOS. S naší verzí nixops je možné spravovat v jedné síti NixOS i vpsAdminOS stroje. Pro migraci dat při aktualizaci OS jsme vytvořili nástroj zvaný osup [5]. vpsAdminOS se při aktualizaci "přeplácne" novou verzí a níc víc se řešit nemusí, nicméně o konfiguraci a data kontejnerů na ZFS poolech je nutné se starat. Ne vše se podaří dobře navrhnout hned na začátku a změny mohou vyžadovat reorganizaci datasetů, adresářů, atd. [6]. osup umožňuje takové změny provádět automatizovaně, spouští se spolu s aktualizací systému, ať už přes os-rebuild nebo nixops. Změny provádějí migrační skripty, kterými se pool buď aktualizuje na vyšší verzi, nebo se vrátí na verzi starší. Už jsem se tu zmiňoval o nutnosti předělat správu IP adres ve vpsAdminu, OS už teď k tomu umí vše potřebné. K síťovým rozhraním VPS se nyní dají zvlášť přidělovat routované adresy a adresy přiřazené na rozhraní, ala ip addr/route add. Takže je např. možné routovat síť /64 a na rozhraní přidělit jen vybrané adresy z dané sítě. Spojovací adresy nadále nebudou muset být na prvním místě, což komplikovalo nastavení sítě v dockeru a obecně maškarádu. Integrace do vpsAdminu je rozdělaná, ale je to poměrně složité a ještě to bude chvíli trvat. [1] https://vpsadminos.org/os/installation/ [2] https://vpsadminos.org/os/updates/ [3] https://vpsadminos.org/os/deployment/ [4] https://nixos.org/nixops/ [5] https://man.vpsadminos.org/osup/man8/osup.8.html [6] https://vpsadminos.org/containers/administration/#pools Jakub

6 years, 8 months

1
0
0 0

Sdileny hardware - co dal

by Pavel Snajdr

Ahojte, jak asi vite, s Intelovskym hardware to vypada bidne. Od zacatku roku to mame uz nejmin 5 kritickych bezpecnostnich chyb, kvuli kterym se mi hodne spatne spi. To mame spectre, meltdown, ruzny varianty, ted L1TF jako posledni zabijak... Abychom nase systemy patchnuli, nezbyde nam, nez vypnout hyperthreading (HT). To znamena prijit o cca 30% vykonu. Aktualni myslenka, kterou mame, je vyhodit vsechny 6ti jadrovy procesory a nakoupit bazarovy Ivy Bridge E5-2670v2, co je 10 jader @ 2.5 GHz za 150 EUR kus. To by nam melo umoznit vypnout HT. Nejvetsi otazkou je, jak dlouho bude jeste Intel vydavat opravy mikrokodu pro Ivy - zatim to vypada, ze bude + nektery opravy tech chyb od komunity mikrokody nepotrebuji a fungujou lip (napr. retpolines proti spectre, pokud to neni na nejnovejsich Intelech). My mame majoritu systemu jeste Sandy Bridge, vykonem by nam dostacovaly, pokud bychom nebyli nuceni vypnout HT. Financne je to jednou z mala funkcnich variant, co mne napada, jak se proti tomuhle branit a neco s tim delat. Co si o tom myslite, nemate nekdo lepsi napad? Bohuzel kupovat novy systemy s AMD ma dve downsides: 1. za chvili je tu EPYC2, takze to bude hned outdated; 2. DDR4 a teda novy pameti obecne jsou aktualne skoro preplaceny zlatem, jak je jich malo. Vitam jakykoliv komentare a otazky na tohle tema ;) Osobne to vidim na upgrade na 2x 10core Ivy Bridge ve vsech masinach (SNB a IVB maji stejne desky, nastesti) a vypnuti HT. Otazka je, jaka dalsi spekulace prijde dal a jestli nam to nahodou plan s Ivy nepolozi... /snajpa

6 years, 8 months

9
24
0 0

Přechod z OpenVZ na vpsAdminOS a spuštění testovacího prostředí / Migration from OpenVZ to vpsAdminOS

by Jakub Skokan

Ahoj, (English version below) aktuálně na všech nodech k provozu VPS používáme kontejnerovou virtualizaci OpenVZ Legacy. Protože už dosluhuje, vývoj skončil a nové distribuce jej přestávají podporovat, řešíme přechod na novější řešení v podobě vpsAdminOS [1,2]. Jedná se o distribuci založenou na NixOS [3] a not-os [4], která bude na nodech sloužit jako hypervizor pro provoz VPS. Pro správu VPS (kontejnerů) jsme vytvořili vlastní utilitu `osctl`, která se funkcemi vyrovná `vzctl` z OpenVZ, popř. LXD [5]. Řeší hlavně nastavení user namespaces [6] pro správnou izolaci VPS a cgroups pro limity paměti, CPU, atd. Ke spouštění kontejnerů se používá LXC [5]. vpsAdminOS není omezen jen na infrastrukturu vpsFree.cz. Pokud někde provozujete OpenVZ Legacy a nevíte co dál, můžete zvážit vpsAdminOS, který je na migraci kontejnerů z OpenVZ připraven [7]. Na vpsAdminOS pracujeme zhruba od podzimu 2017 a nyní si všichni členové mohou vyzkoušet, jak VPS nad novým systémem fungují. Naším cílem je, aby migrace VPS z OpenVZ na vpsAdminOS proběhly bezpovšimnutí, nicméně záleží na tom, co ve VPS provozujete. Doporučujeme všem, aby si novou VPS vyzkoušeli a hlásili nám případné problémy a nedostatky. Než přistoupíme k migraci produkčních VPS, je potřeba ten OS a integraci s vpsAdminem vyladit. V podstatě máte k dispozici další playground VPS, podmínky jsou podobné. Jen to může být trochu divočejší -- nehlášené výpadky, restarty když budeme potřebovat něco aktualizovat, atd. Ve vpsAdminu ve formuláři na vytvoření VPS vyberte lokaci *Staging*. K dispozici jsou zatím tyto distribuce: Alpine, Arch, CentOS, Debian, Fedora, Gentoo, NixOS, Ubuntu. Časem budou přibývat další. Na testování a hlášení chyb máte cca několik týdnů až měsíců, podle toho jak nám to půjde. Více informací o změnách v OS, vpsAdminu a plánu přechodu viz KB: https://kb.vpsfree.cz/navody/vps/vpsadminos ENGLISH: We're currently using container virtualization OpenVZ Legacy to run VPS. Since it's slowly dying, isn't developed anymore and modern distributions stopped supporting it, we're going to upgrade to a newer solution we've called vpsAdminOS [1,2]. It's a Linux distribution based on NixOS [3] and not-os [4], which will serve as a hypervisor for VPS on our nodes. VPS are managed using our own utility called `osctl`, which is comparable to `vzctl` from OpenVZ or LXD [5]. It's main purpose is to set up user namespaces [8] to isolate VPS and to configure cgroups for resource management, such as CPU or memory. Under the hood, it's using LXC [5] to start containers. vpsAdminOS is not limited to vpsFree.cz, it's designed to be independent of the specifics of our infrastructure. If you're using OpenVZ Legacy on some servers and you're looking for a replacement, you can consider vpsAdminOS. We've also made a tool [7] which can convert containers from OpenVZ into vpsAdminOS. We've been working on vpsAdminOS since the fall of 2017 and now all members can finally give it a try and test VPS on the new system. Our goal is to make the transition from OpenVZ to vpsAdminOS as seamless as possible, but it depends on what programs and configuration you're using. That's why we're giving everyone the opportunity to try out a VPS on the new system and report issues. Before we can start migrating production VPS, we need to implement missing functions and iron it out. Essentialy, what you get is another playground VPS, the terms of use are very similar. It can be a bit rougher though, there may be unexpected reboots and outages when we need to fix issues and deploy new system versions. To create a VPS on vpsAdminOS, select location *Staging* in the form for VPS creation. The following distributions are supported: Alpine, Arch, CentOS, Debian, Fedora, Gentoo, NixOS, Ubuntu. More will be added in the future. The staging environment will remain open for several weeks or months, depending on how many issues we'll discover. You can read more information about changes in the OS and vpsAdmin in KB: https://kb.vpsfree.org/manuals/vps/vpsadminos [1] https://vpsadminos.org [2] https://github.com/vpsfreecz/vpsadminos [3] https://nixos.org [4] https://github.com/cleverca22/not-os [5] https://linuxcontainers.org [6] https://kb.vpsfree.cz/navody/vps/vpsadminos#user_namespaces [7] https://vpsadminos.org/migration-paths/openvz-legacy/ [8] https://kb.vpsfree.org/manuals/vps/vpsadminos#user_namespaces Jakub

6 years, 8 months

6
12
0 0

Mailcow docker a vpsAdminOs

by Tomáš Zmek

Ahoj, chci si vyzkoušet Mailcow, abych si na něm případně postavil mailový server. https://mailcow.email Mám tedy spuštěný testovací vps s vpsAdminOs a nainstaloval si docker podle návodu na KB. Pak jdu podle návodu https://mailcow.github.io/mailcow-dockerized-docs/install/ Když ale se dostanu do stavu, kdy mám spustit mailcow docker-compose up -d tak skončím s chybou. ERROR: for mailcowdockerized_unbound-mailcow_1 Cannot start service unbound-mailcow: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused \"rootfs_linux.go:58: mounting \\\"/opt/mailcow-dockerized/data/conf/unbound/unbound.conf\\\" to rootfs \\\"/var/lib/docker/vfs/dir/d85669b549311cb1226b821c4140f764db94e9da9fd6fefa409eacce016d5b46\\\" at \\\"/Creating mailcowdockerized_dockerapi-mailcow_1 ... error 46/etc/unbound/unbound.conf\\\" caused \\\"permission denied\\\"\"": unknown Je to pro každou službu, co tam mám spustit. Skončí to stejně. A teď slušně prosím o případné vysvětlení, co by mohl být problém. Pokud by někdo tušil. Zatím jsem se googlením moc k ničemu nedostal. :-( Dělá to jak u Ubuntu 18.04 tak i Debian 9 (tam to je teď). Na localu na pc jsem na ubuntu 18.04 Tomáš

6 years, 8 months

2
1
0 0

Končí CfP na LinuxDays, přihlaste přednášku

by Petr Krcmar

Ahoj všem, za pár dnů končí možnost přihlásit témata na LinuxDays. Máte co říct? Přihlaste přednášku nebo workshop na téma, kterým se zabýváte: https://www.linuxdays.cz/2018/cfp/ Jako obvykle bude mít vpsFree na konferenci stánek a rádi vás tam potkáme. -- Petr Krčmář vpsFree.cz

6 years, 8 months

1
0
0 0

Re: [vpsFree.cz: community-list] Community-list Digest, Vol 85, Issue 9

by Andrei Toupinets

Ahoj, pouzival jsem drive https://dmarcian.com/ , ale pak me to prestalo bavit :) Andrei Toupinets Dne 16/08/2018 v 13:28 community-list-request(a)lists.vpsfree.cz napsal(a): > Send Community-list mailing list submissions to > community-list(a)lists.vpsfree.cz > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.vpsfree.cz/listinfo/community-list > or, via email, send a message with subject or body 'help' to > community-list-request(a)lists.vpsfree.cz > > You can reach the person managing the list at > community-list-owner(a)lists.vpsfree.cz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Community-list digest..." > > > Today's Topics: > > 1. Zpracování DMARC reportů (Matěj Koudelka) > 2. Re: Zpracování DMARC reportů (Vaclav Dusek) > 3. Re: Zpracování DMARC reportů (Matěj Koudelka) > 4. Re: Blacklist (Jiri Vesely) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Aug 2018 12:35:50 +0200 > From: Matěj Koudelka <matej(a)hxpro.cz> > To: "vpsFree.cz" <Community-list(a)lists.vpsfree.cz> > Subject: [vpsFree.cz: community-list] Zpracování DMARC reportů > Message-ID: > <CA+jsTBKq5DqbiY4R9TpkEMuiSr5+k6uZ_08tUtn-aME50x7EZg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Zdravím borci, > rád bych se zeptal jestli máte někdo nějaké tipy na automatizované > zpracování DMARC reportů. Zavedl jsem to teprve nedávno, takže to ručně > stahuju z emailu a pak to importuju do django-dmarc. > Co používáte vy? >

6 years, 9 months

2
1
0 0

Poděkování za podporu TDE

by Slávek Banko

Ahoj, podle rozcestníku Kam psát jsem usoudil, že poděkování pravděpodobně nepatří na podporu. A tak bych zde na community-listu chtěl poděkovat vpsFree za podporu. Jsou to bezmála tři roky, kdy jsme pro Trinity Desktop Environment (TDE) jako sponzorský dar dostali jednu VPS. Postupně na této VPS zabydlujeme další a další služby, díky kterým je pro projekt velkým přínosem. Proto je v Release Notes pro nedávno vydanou verzi TDE R14.0.5 oficiální poděkování vpsFree za tuto podporu. Děkuji! -- Slávek

6 years, 9 months

1
0
0 0

Chodí vám emaily na seznam.cz?

by Stanislav Kocanda

Ahoj, v "Blacklist" vlákně jsem si toho nikde nevšiml, proto bych se chtěl zeptat: Chodí vám z vpsek maily na seznam.cz? Na mém mailserveru s tím celé roky nebyl problém, ale teď se asi něco stalo, protože maily chodit přestaly. A vzhledem k procentu českých uživatelů, kteří mají maily na seznamu, je to docela zásadní problém. Průběh je přitom dost zvláštní - přijímací smtp server seznamu mail přijme, žádné zamítnutí, mail je na jejich straně "queued for delivery in session", ale v cílové schránce se zpráva neobjeví, ani v inboxu, ani ve složce spam, prostě nikde. Mail se u nich zkrátka někde ztratí, ani odesílatel, ani příjemce se o tom nedozví. Řeším to s jejich helpdeskem, ale už pár dnů čekám na odpověď a nic. Na mailserveru mám 4 IP adresy, zkoušel jsem všechny, a mail se úspěšně nedoručil ani z jedné. Proto mě napadlo se zeptat, jestli se to neděje ještě někomu z vpsfree. Jinak SPF/DKIM bych měl mít OK, resp. doteď s tím problém nebyl a ostatní mailservery mi problém nedělají (až na Microsoft, o tom už tu byla řeč). Díky! Standa

6 years, 9 months

11
17
0 0

Blacklist

by Jiri Vesely

Čau, bylo by možné něco udělat s blokováním našich vps na cca 30 blacklistech? http://www.eakcorp.net http://www.robtex.com/ip-lookup/37.205.9.62 -- S pozdravem Jiri V. -- S pozdravem Jiri Vesely

6 years, 9 months

20
55
0 0

Blacklist - filtr

by Libor Boldan

Ahoj, pred mnoha lety se mi tady tento problem stal. Ale neslo o napadeni serveru, jednomu zakaznikovi (spis jen jednomu cloveku s jednim mailem z jedne domeny z mnoha bezich ze serveru) se asi zaviroval PC a utocnik se dostal k jeho heslu (treba keyloggerem) a zacal pres server "legalne" odesilat maily. Zmena hesla/upozorneni a nasledne zadosti na blacklisty. Pak mi kamarad na server napsal nejaky script, ktery mi posle mail, pokud se zvetsi fronta. Pak musim rucne v logu zjistit, kdo to je a zmenit heslo. Od te doby jsem se na blacklist nedostal, ale stalo se to asi jen 2x a vzdy jsem byl "v dosahu", takze jsem to stihl. Sel by napsat nejaky script, ktery by zautomatizoval i ten zbytek a jak pres nejakou adresu odejde vic jak treba 100 mailu za hodinu, tak ho to primo zjisti a zmeni mu to heslo za me? A me jen oznami, ze se to stalo a ja to s dotycnym vyresim? Libor Boldan

6 years, 9 months

3
2
0 0

Zpracování DMARC reportů

by Matěj Koudelka

Zdravím borci, rád bych se zeptal jestli máte někdo nějaké tipy na automatizované zpracování DMARC reportů. Zavedl jsem to teprve nedávno, takže to ručně stahuju z emailu a pak to importuju do django-dmarc. Co používáte vy? -- *Matěj Koudelka* +420 604 266 933

6 years, 9 months

2
2
0 0

Vysypavani kose v IMAP

by Libor Boldan

Ahoj, na serveru mam ispCP Omega a zakaznika, ktery pouziva 1 mail info(a)domena.cz na 3 PC pres IMAP, vse v Thunderbirdu. Pry se mu pred nedavnem stalo, ze se mu zacal po tydnu vysypavat kos. Sleduje to uz pry par dni a mizi to presne po dnech, takze to neni tim, ze by jeden z nich omylem vysypal kos. V Thunderbirdu vidim jen nastaveni "Pri ukonceni vysypat kos", ale nastaveni, aby to delal po x dnech jsem nenasel. Nenapada nekoho, kde by to mohlo byt? Dik Libor Boldan

6 years, 9 months

4
3
0 0

Terraform pro vspfree

by ondrej platek

Ahoj, koukam na https://kb.vpsfree.cz/navody/vps/api Pro spravu Amazonu pouzivam v praci Terraform, skvely nastroj pro managovani cloudovych resourcu. Viz - https://www.terraform.io/docs/providers/aws/index.html - https://www.terraform.io/ Uvazovali jste nad vytvoreni providera pro vpsfree? Ja okamzite jak jsem vpsfree uvidel :) Otazky: a) mel bys zajem pouzivat Terraform pro managovani vpsfree? -> Napis mi jake resources (API) byste chteli implementovat jako prvni b) byl bys ochotny prispivat do opensource repa na github pokud se o featuru ukaze zajem? -> staci rict ANO :) c) na koho se mam obratit v pripade ze zkusim udelat prototyp a narazim na problemy s API? Diky za odpovedi/feedback Ondra PS: Zatim se ptam jestli o featuru by byl zajem, neslibuju, ze neco udelam. Ale snad to prijde :) -- Ondřej Plátek

6 years, 9 months

7
8
0 0

Výpadek konektivity 2018-08-03 13:50-14:30

by zd nex

Ahojte, chtěl jsem se zeptat jestli dnes vypadla celá konektivita jak v Praze tak v Brně kolem 13:50 až 14:30? Máte někdo bližší informace? Procházel jsem munin a je tam u některých node prázdné okno a nestat u velkého množství spojení ukazuje failed. Plánujeme totiž začít používat DNS Made easy a jaksi se dnes ukázalo, že to stačit pro failover nebude i když jsou to jiné lokality. -- S pozdravem, Zdeněk Dlauhý Web: www.pripravto.cz

6 years, 9 months

2
3
0 0

Oficialni konec tezeni kryptomen ve VPS

by Pavel Snajdr

Ahojte, rozsiril se nam tu takovy nesvar - nove prichozi clen prijde, vyrobi si VPSky, kde jen muze; tam naspousti minery a kdyz mu to vypneme, strasne se takovy dotycny divi, ze to preci nebylo nikde napsane... Tak ted uz to bohuzel napsane je: https://kb.vpsfree.cz/informace/co_nedelat#co_na_vps_nedelat Vsichni, co vpsFree delame kazdy den, bytostne nenavidime zakazy. Ale jestli neco nesnasime vic, je to ocividny zneuzivani dobry vule :( Diky moc za pochopeni. /⁠snajpa PS.: ... abych sem taky propasoval neco pozitivniho... Kdo mate zajem osahat si Debian na 64bit ARMu, se kterym pujdeme kreslit system, napiste, dam pristup do kontejneru ;) Mam zatim rozbehane LXC nad 4.9.111 jadrem a vypada to slibne, Wordpress v defaultu to chrousta za 42ms :) Cortex A72 @ 1.8 GHz + DDR4 Unregistered ECC @ 2100MHz, aneb prvni ARM co nepovazuju za hracku :))

6 years, 9 months

1
0
0 0

Re: [vpsFree.cz: community-list] KVM na Ubuntu 16.04

by René Langer

Ahoj, KVM chodí, ale nesmíš pouzivat libvirt, ten v OpenVZ kontajnéru chodí jen pod Debian 8. Renda ______________________________________________________________ > Od: <mochour(a)email.cz> > Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> > Datum: 03.07.2018 22:46 > Předmět: [vpsFree.cz: community-list] KVM na Ubuntu 16.04 > >Ahoj, > > > >podařilo se někomu rozchodit KVM na Ubuntu 16.04? > > > > >Po instalaci podle návodu na https://kb.vpsfree.cz/navody/vps/kvm (Debian >8), končím s chybou > > > > > >Jul 03 22:33:04 vps01 systemd[1]: Starting LSB: QEMU KVM module loading >script... > >Jul 03 22:33:04 vps01 qemu-kvm[68]: * Configuring kvm qemu-kvm > >Jul 03 22:33:04 vps01 qemu-kvm[68]: modprobe: ERROR: ../libkmod/libkmod.c: >586 kmod_search_moddep() could not open moddep file '/lib/modules/3.16.6-042 >stab131.42/modules.dep.bin' > >Jul 03 22:33:04 vps01 qemu-kvm[68]: modprobe: FATAL: Module kvm_intel not >found in directory /lib/modules/3.16.6-042stab131.42 > >Jul 03 22:33:04 vps01 qemu-kvm[68]: mknod: /dev/kvm: File exists > >Jul 03 22:33:04 vps01 qemu-kvm[68]: ...done. > >Jul 03 22:33:04 vps01 systemd[1]: Started LSB: QEMU KVM module loading >script. > > > > > >KVM mám na VPS povolené. > >Dík > >H > >---------- > >_______________________________________________ >Community-list mailing list >Community-list(a)lists.vpsfree.cz >http://lists.vpsfree.cz/listinfo/community-list > >

6 years, 10 months

1
0
0 0

Re: [vpsFree.cz: community-list] OT - PHP, MSQL a sdílení dat

by Jan B. Kolář

Díky všem za jejich reakci a omlouvám se za moje poněkud delší odezvy. Sedím zrovna za pultem a zatím co odpovídám, tak ještě obsluhuji zákazníky :-D V podstatě se mi zdá jako nejjednodušší řešení to, co míše Martin. Můj problém ale je, že úplně přesně nevím, jak bych to měl v PHP implementovat. Tedy první, co mě napadlo je, že bych použil dvě databáze - vzdálenou přes SSH tunel a lokální. Standardně bych pracoval se vzdálenou databází a pokud by se PHP nepodařilo ke vzdálené databázi připojit, tak by začalo pracovat s lokální databází a ukládalo si účtenky, které vystavilo pro pozdější synchronizaci. Jakmile by se spojení obnovilo, tak by se appka pokusila všechno z lokální databáze nahrát do vzdálené databáze na server. Hned první, co mě ale napadá je, jak appka pozná, že je spojení přerušeno/ navázáno? Tedy pokud budu při každém požadavku čekat na timeout vzdálené databáze, tak se ta aplikace asi brutálně zpomalí, ikdyž tam dám třeba jen 1s timeout. Čím si však vůbec nejsem jistý, jakým způsobem bych měl řešit tu cache produktů? To mám třeba co hodinu stahovat celou produktovou tabulku ze vzdálené databáze a ukládat ji lokálně? Jde sice jen o cca. 2 tisíce produktů a dvě pokladny, ale přesto... Neviděl jste někdo nějakou implementaci takového problému, že bych se mohl podívat na kód? Dne pondělí 2. července 2018 13:18:36 CEST jste napsal(a): > Dne 2.7.2018 v 11:26 Jan B. Kolář napsal(a): > > Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na > > každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a > > na server si dělal jen replikaci databází, abych pak mohl dělat z > > pokladen výkazy, aniž by byly v běhu. > > Nebylo by jednodušší používat lokální databázi na pokladnách jen jako > cache produktů a buffer účtenek? Databáze na serveru bude hlavní. > Pokladny si z ní v definovaných intervalech budou aktualizovat cache > produktů a průběžně do ní budou zapisovat nové účtenky, které se > serverem Ministerstva vyřídí samy. Když ale selže spojení s hlavní > databází, účtenka se zapíše do bufferu a na server se uloží až > dodatečně, až se spojení zase obnoví. > > S pozdravem, > Maritn Doucha -- Jan B. Kolář Zažeň nudu Hodolanská 17, 779 00 Olomouc tel: +420 605 800 859 e-mail: janbivoj.kolar(a)zazen-nudu.cz www.zazen-nudu.cz

6 years, 10 months

5
5
0 0

OT - PHP, MSQL a sdílení dat

by Jan B. Kolář

Ahoj, chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším. Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat, takže jsem si byl schopen do programu udělat implementaci EET). Celá věc mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu. Co mi však začalo dělat starosti jsou výpadky připojení. Za celý rok jich bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době výpadku nedávám lístky. Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a na server si dělal jen replikaci databází, abych pak mohl dělat z pokladen výkazy, aniž by byly v běhu. Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu mám přistoupit :-( Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data druhou databázi, která by byla na serveru a replikovala se na pokladny. Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master databáze na serveru a čtení z lokální slave databáze na pokladně. Ocením jakoukoliv radu nebo odkaz. Všechny zdraví Honza -- Jan B. Kolář Zažeň nudu Hodolanská 17, 779 00 Olomouc tel: +420 605 800 859 e-mail: janbivoj.kolar(a)zazen-nudu.cz www.zazen-nudu.cz

6 years, 10 months

4
4
0 0

quagga

by Panagiotis Palias

Hello all, has anyone managed to make quagga work in a vps? I am interested in ospf mostly, but bgp will also do if there is no other way. The problem I am getting so far is that zebra cannot be started and is a dependency for ospfd. Ιουν 13 16:08:28 vps systemd[24880]: zebra.service: Failed to set up kernel keyring: Permission denied Ιουν 13 16:08:28 vps systemd[24880]: zebra.service: Failed at step KEYRING spawning /sbin/ip: Permission denied -- Subject: Process /sbin/ip could not be executed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The process /sbin/ip could not be executed and failed. -- -- The error number returned by this process is 13. Ιουν 13 16:08:28 vps systemd[1]: zebra.service: Control process exited, code=exited status=237 Ιουν 13 16:08:28 vps systemd[1]: zebra.service: Failed with result 'exit-code'. Ιουν 13 16:08:28 vps systemd[1]: Failed to start GNU Zebra routing manager. -- Subject: Unit zebra.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit zebra.service has failed. -- -- The result is RESULT. Ιουν 13 16:08:28 vps systemd[1]: Dependency failed for OSPF routing daemon. -- Subject: Unit ospfd.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit ospfd.service has failed. Thank you! -- -p

6 years, 11 months

3
4
0 0

[brigadka] Pomocnici pro OpenAlt

by Pavel Snajdr

Cauves vsichni, zaciname (ehm, vcelku vcas) resit letosni rocnik OpenAltu a jelikoz jako vpsFree pomahame tuhle brnenskou akci poradat a ja absolutne nestiham byt klukum jakkoliv uzitecny, hledam za sebe nahradu. Hledam nekoho, kdo by byl ochotny pomoct OpenAltakum s nasledujicim: - obvolani/omailovani partneru/sponzoru a komunikace s nimi (tj. nekdo, koho bavi mluvit s lidma a delat obchod, na tomhle se to fajne da cvicit "na necisto", protoze vcelku o "prd" jde) -⁠ komunikace se stankari (ktere dodaji prave partneri) -⁠ a obecne proste vypomoct na podobny organizacni veci Jak rikam, jelikoz to vpsFree pomaha poradat a ja nestiham, udelejme to letos tak, ze dejme brigadku nekomu ze clenu, kdo by to ocenil. Pojdme se dohodnout na rozumny ukolovy/⁠hodinovy odmene a pojdme do toho. Potrebuju idealne 2-⁠3 lidi, casova narocnost na tak 15h/⁠tyden. Prosim prosim :) Kdyztak preposlete dal. /⁠snajpa

6 years, 11 months

1
0
0 0

Re: [vpsFree.cz: community-list] Přechod z OpenVZ na vpsAdminOS a spuštění testovacího prostředí / Migration from OpenVZ to vpsAdminOS

by René Langer

Zdravím, * při vytváření VPS ve Staging, nelze přiřadit Private IPv4. Budou Private IPv4 podporovány pro produkční VPS? Případně lze je nyní na žádost k VPS Staging přidělit? * v editaci VPS (Staging), nelze přidat IPv6 z nabízených IPv6 adres, hodí to chybu "Cannot add an interconnecting IP". IPv6 lze přidat pouze při vytváření VPS. * u VPS (Staging), která má pouze IPv6, nechodí překlad názvů DNS. Tedy pokud neznám konkrétní IPv6 adresu, na domény se po IPv6 nedostanu. V nastavení VPS mám IPv6 DNS zvolen. * No a když při vytváření VPS (Staging) nepřiřadím při vytváření public IPv4 ani IPv6, VPS se vytvoří s IPv4 v rámci spojovací sítě, ale bez konektivity do internetu. Bylo by také fajn, kdyby spojovací IPv4 na sebe viděli v rámci jednoho účtu na vpsfree.cz, pokud tedy nebudou Private IPv4 podporován. Renda ______________________________________________________________ > Od: Jakub Skokan <jakub.skokan(a)vpsfree.cz> > Komu: news-list(a)lists.vpsfree.cz, > Datum: 21.05.2018 09:41 > Předmět: [vpsFree.cz: community-list] Přechod z OpenVZ na v > Ahoj, (English version below) aktuálně na všech nodech k provozu VPS používáme kontejnerovou virtualizaci OpenVZ Legacy. Protože už dosluhuje, vývoj skončil a nové distribuce jej přestávají podporovat, řešíme přechod na novější řešení v podobě vpsAdminOS [1,2]. Jedná se o distribuci založenou na NixOS [3] a not-os [4], která bude na nodech sloužit jako hypervizor pro provoz VPS. Pro správu VPS (kontejnerů) jsme vytvořili vlastní utilitu `osctl`, která se funkcemi vyrovná `vzctl` z OpenVZ, popř. LXD [5]. Řeší hlavně nastavení user namespaces [6] pro správnou izolaci VPS a cgroups pro limity paměti, CPU, atd. Ke spouštění kontejnerů se používá LXC [5]. vpsAdminOS není omezen jen na infrastrukturu vpsFree.cz. Pokud někde provozujete OpenVZ Legacy a nevíte co dál, můžete zvážit vpsAdminOS, který je na migraci kontejnerů z OpenVZ připraven [7]. Na vpsAdminOS pracujeme zhruba od podzimu 2017 a nyní si všichni členové mohou vyzkoušet, jak VPS nad novým systémem fungují. Naším cílem je, aby migrace VPS z OpenVZ na vpsAdminOS proběhly bezpovšimnutí, nicméně záleží na tom, co ve VPS provozujete. Doporučujeme všem, aby si novou VPS vyzkoušeli a hlásili nám případné problémy a nedostatky. Než přistoupíme k migraci produkčních VPS, je potřeba ten OS a integraci s vpsAdminem vyladit. V podstatě máte k dispozici další playground VPS, podmínky jsou podobné. Jen to může být trochu divočejší -- nehlášené výpadky, restarty když budeme potřebovat něco aktualizovat, atd. Ve vpsAdminu ve formuláři na vytvoření VPS vyberte lokaci *Staging*. K dispozici jsou zatím tyto distribuce: Alpine, Arch, CentOS, Debian, Fedora, Gentoo, NixOS, Ubuntu. Časem budou přibývat další. Na testování a hlášení chyb máte cca několik týdnů až měsíců, podle toho jak nám to půjde. Více informací o změnách v OS, vpsAdminu a plánu přechodu viz KB: https://kb.vpsfree.cz/navody/vps/vpsadminos <https://kb.vpsfree.cz/navody/vps/vpsadminos> ENGLISH: We're currently using container virtualization OpenVZ Legacy to run VPS. Since it's slowly dying, isn't developed anymore and modern distributions stopped supporting it, we're going to upgrade to a newer solution we've called vpsAdminOS [1,2]. It's a Linux distribution based on NixOS [3] and not-os [4], which will serve as a hypervisor for VPS on our nodes. VPS are managed using our own utility called `osctl`, which is comparable to `vzctl` from OpenVZ or LXD [5]. It's main purpose is to set up user namespaces [8] to isolate VPS and to configure cgroups for resource management, such as CPU or memory. Under the hood, it's using LXC [5] to start containers. vpsAdminOS is not limited to vpsFree.cz, it's designed to be independent of the specifics of our infrastructure. If you're using OpenVZ Legacy on some servers and you're looking for a replacement, you can consider vpsAdminOS. We've also made a tool [7] which can convert containers from OpenVZ into vpsAdminOS. We've been working on vpsAdminOS since the fall of 2017 and now all members can finally give it a try and test VPS on the new system. Our goal is to make the transition from OpenVZ to vpsAdminOS as seamless as possible, but it depends on what programs and configuration you're using. That's why we're giving everyone the opportunity to try out a VPS on the new system and report issues. Before we can start migrating production VPS, we need to implement missing functions and iron it out. Essentialy, what you get is another playground VPS, the terms of use are very similar. It can be a bit rougher though, there may be unexpected reboots and outages when we need to fix issues and deploy new system versions. To create a VPS on vpsAdminOS, select location *Staging* in the form for VPS creation. The following distributions are supported: Alpine, Arch, CentOS, Debian, Fedora, Gentoo, NixOS, Ubuntu. More will be added in the future. The staging environment will remain open for several weeks or months, depending on how many issues we'll discover. You can read more information about changes in the OS and vpsAdmin in KB: https://kb.vpsfree.org/manuals/vps/vpsadminos <https://kb.vpsfree.org/manuals/vps/vpsadminos> [1] https://vpsadminos.org <https://vpsadminos.org> [2] https://github.com/vpsfreecz/vpsadminos <https://github.com/vpsfreecz/vpsadminos> [3] https://nixos.org <https://nixos.org> [4] https://github.com/cleverca22/not-os <https://github.com/cleverca22/not-os> [5] https://linuxcontainers.org <https://linuxcontainers.org> [6] https://kb.vpsfree.cz/navody/vps/vpsadminos#user_namespaces <https://kb.vpsfree.cz/navody/vps/vpsadminos#user_namespaces> [7] https://vpsadminos.org/migration-paths/openvz-legacy/ <https://vpsadminos.org/migration-paths/openvz-legacy/> [8] https://kb.vpsfree.org/manuals/vps/vpsadminos#user_namespaces <https://kb.vpsfree.org/manuals/vps/vpsadminos#user_namespaces> Jakub _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>

6 years, 11 months

2
1
0 0

GDPR: posledni sance pro komentare

by Pavel Snajdr

Ahojte, po zapracovani pripominek vypada navrh na nas Organizacni rad takhle: https://github.com/vpsfreecz/oficialni-dokumenty/blob/gdpr/organizacni_rad.… Projdete si to prosim; ja k tomu jenom dodam, ze veci ohledne detailniho auditovani pristupu a la "kdo z nas kdy vykonal jaky prikazy s jakym vysledkem" apod. - budeme resit certifikaci ISO 27001 nekdy v pristim roce. Takze zatim je Organizacni rad krome logu "co se deje s disky" neupravuje. pls pls komentujte, je "pet minut po dvanacte", jestli vas neco napada, sem s tim. Diky :) /snajpa

6 years, 12 months

4
3
0 0

Re: [vpsFree.cz: community-list] Supermicro, zkušenosti?

by Pavel Hruška

Ahoj, pro zajímavost co máš za konfigurace? Zhruba - kategorie, deska, chipset, procesor, ramka atd... A nějaký dodavatel, který by stál za doporučení? P Dne po 7. 5. 2018 18:22 uživatel Jaroslav Skrivan <skrivy(a)skrivy.net> napsal: > Proslo mi rukama kolem 200 supermicer (ted jich mame v provozu asi 100) a > odhad umrtnosti je za 10 let cca 3-4%. Nemuzu rict, ze nikdy nic neumrelo, > ale bylo toho s ohledem na mnozstvi malo. > > Jarda > ------------------------------ > From: Stepan Liska <stepan(a)comlinks.cz> > Sent: ‎5/‎7/‎2018 5:46 PM > To: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz> > Subject: Re: [vpsFree.cz: community-list] Supermicro, zkušenosti? > > Ahoj, > > spravoval jsem a spravuji několik SuperMicro serverů (a "serverů"). Šlo > spíše o nižší třídu serverů, dokonce jsem měl pár let pod palcem i několik > kousků s Atomem. Bylo jich celkem asi 8 a z toho jen jeden měl nějaké > problémy s hardwarem a to ještě až po několika letech provozu. Pro mě zatím > z hlediska spolehlivosti a za danou cenu s vybavením IPMI 2.0 s iKVM jasná > volba pro cokoliv co potřebuji (SOHO + SmallBusiness). NBD záruky sice > vezmou něco navíc, ale mají několik různých levelů včetně onsite a ceny mi > přišly vcelku adekvátní ceně serverů, nicméně se mi zdálo, že se to vyplatí > spíš u těch dražších. U levnějších jsem se spíš snažil o stejný nebo > podobný typ a měl jsem jeden ve skříni navíc. > > Nicméně masivní nasazení jako vpsFree jsem nikdy nezažil a taky to co > nasazuje vpsFree je o nějaký ten level výš. > > Štěpán. > > Dne 7.5.2018 v 09:27 Pavel Hruška napsal(a): > > Díky, jde mi o to, jaké jsou dlouhodobé zkušenosti, hlavně co se > spolehlivosti týče. Rád bych měl nějakou alternativu k serverům HP apod., > tedy mít možnost udělat si vlastní server a nebýt úplně vázán vendor > specific komponentami, především u řešení, kde je kladen důraz na rozpočet. > > Ještě (možná hloupý) dotaz, ale když mám teda E3-12x0, tedy bez int. VGA, > musím ještě koupit nějakou grafiku k té desce? Uvažoval jsem spíš o > E3-1245, tedy s integrovanou grafikou. Pro, proti? > > Díky, > P. > > Dne 7. května 2018 9:08 Miroslav Šedivý <sedivy(a)kvetakov.net> napsal(a): > >> Tuhle desku máme, funguje to jako router společně s E3-1240 v6. nevím co >> k tomu říct, prostě to funguje :-) >> >> *S pozdravem* >> >> *Ing. Miroslav Šedivý* >> >> Dne 6. května 2018 19:30 Pavel Hruška <mrpear(a)mrpear.net> napsal(a): >> >>> Ahojte, stručně a jasně, jaké máte zkušenosti se Supermicro? Mám v merku >>> jejich desku, konkrétně X11SSH-F. Díky za názory. >>> _______________________________________________ >>> Community-list mailing list >>> 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 >> >> > > > -- > Ing. Pavel Hruška > http://www.mrpear.net > mrpear(a)mrpear.net > > web, webdesign, web-aplikace: > http://www.pearfect.cz > > > _______________________________________________ > Community-list mailing listCommunity-list@lists.vpsfree.czhttp://lists.vpsfree.cz/listinfo/community-list > > > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list >

7 years

7
10
0 0

Problém se sítí ve Fedo?e 27

by Jiří Eischmann

Ahoj, chtěl bych se zeptat, jestli někdo nenarazil na problém se sítí ve VPS s nějakou distribucí s aktuálními verzemi balíčků. Mně se to stalo po upgradu na Fedoru 27, ale předpokládám, že takový Arch by mohl mít podobný problém. Po upgradu mi nefunguje síť, protože se nevytvořilo síťové rozhraní venet0. No a na základě toho selžou následně další věci závisející na funkčním síťovém rozhraní. Taky bych se chtěl zeptat, jak to vypadá s řešením postaveným na LXC. Přijde mi, že provozovat moderní distribuci na OpenVZ je běh čím dál hustějším minovým polem. Už teď musím mít v systému docela dost obezliček, aby na OpenVZ běžel. Pokud by byl nějaký early access, tak bych se hlásil jako dobrovolník. Počítám, že by mi to hodně problémů vyřešilo. Jirka

7 years

7
11
0 0

Supermicro, zkušenosti?

by Pavel Hruška

Ahojte, stručně a jasně, jaké máte zkušenosti se Supermicro? Mám v merku jejich desku, konkrétně X11SSH-F. Díky za názory.

7 years

5
7
0 0

GPU Mining z vody :)

by Pavel Snajdr

Zdarec vsichni, posledni dobou si hraju s miningem altcoinu a docela se dari, tak zase pro jednou, kdyz resim neco pro sebe, proc to nezresit skupinoveji :) Naskytla se moznost umistit az 10kW HW do prostor u vodni elektrarny, takze energie s prehledem rovnou pod 2 Kc; premyslim o modelu, ze bychom poresili mining rigy ve vetsim a vy byste pak meli moznost poslat nam jenom svoje karty. Ty by pak byly pres klasicky chain vpsAdmin-OpenVZ zpristupnene do QEMU pod vasi rezii, takze na tech kartach muzete pocitat, co chcete. S konektivitou bude asi kapku problem, takze pocitam s tvrdym QoS/shapovanim, dostatecnym pro mining a SSH, ale zatim nevim o moznosti sehnat tam lepsi linku na cokoliv narocnejsiho. Kdo byste mel zajem a jak velky? :) /snajpa (Pavel Snajdr) (Predseda vpsFree.cz) (+420 720 107 791)

7 years

32
50
0 0

Ubuntu 18.04 a Arch v playground VPS

by Jakub Skokan

Ahojte, snajpovi se podařilo vyřešit problém s nefunkčními distribucemi se systemd a glibc >= 2.26. Chyběl nám v kernelu prlimit syscall, který systemd využívá. Nody s kernelem 042stab127.46 už mají prlimit backportovaný a díky tomu tam spustíte i Ubuntu 18.04. Dneska v noci to snajpa nasadil na node1.pgnd a ještě ho máme na node2.brq. Ostatní nody by měly být aktualizovány někdy o víkendu. Takže na playgroundu můžete nové ubuntu a další distra s glibc>=2.26 zkoušet už teď, v produkci snad po víkendu. Do té doby produkční VPS s Ubuntu na 18.04 neaktualizujte, nebo budete muset systém obnovovat ze zálohy. Zkoušel jsem na playgroundu i plně aktualizovaný Arch a taky funguje. Akorát jsme řešili nastavení sítě, po aktualizaci na nejnovější systemd to přestalo fungovat a musel se upravovat skript ve vzctl, aby generoval trochu jiný config pro netctl. Pokud to budete zkoušet, nezapomeňte v /etc/pacman.conf zakomentovat IgnorePkg. Jakub

7 years

2
4
0 0

Často padající Sidekiq v GitLabu

by Petr Parolek

Ahoj, setkali jste už někdy s často padajícím Sidekiq v GitLab? Používám verzi 10.7.1 sestavenou ze zdrojáků. Omnibus je ještě víc nenažraný a 4 GB RAM je málo. Navíc nepoužívám Postgress, jen MariaDB V logu mi vypíše tuny výpis pádu. Deebugovat v C a v Ruby vůbec neumím. Co jsem vypozoroval, padá při spuštění pipeline po commitu nebo při merge MR a háže 502 nebo chybu 503 Nemá v tom psty staré jádro a dosloužilé openVZ? Díky moc za rady. Petr

7 years

6
11
0 0

GDPR: draft Provozniho radu

by Pavel Snajdr

Ahojte, platnost GDPR se nam blizi, takze je na case zresit nejakou konkretnejsi implementaci pro nas. Z toho, co jsem se kde byl poradit, jsem zatim stvoril tenhle commit do Provozniho radu: https://github.com/vpsfreecz/oficialni-dokumenty/commit/3a09c71eb992293fe2d… Jeste bod cislo 3 prijde k rozpracovani, hlavne ve smyslu co maji ti kteri odpovedni clenove delat k ochrane (treba jako vyhnout se pouzivani 3rd party infrastruktury mailu, takze pa-pa Gmaily, zaheslovane/zasifrovane mobilni zarizeni, zakazane zobrazeni textu bez odemceni atd.). Uvital bych komentare, co jsem zapomnel, co bych mel predefinovat, apod. Diky moc, /snajpa

7 years

1
0
0 0

Bez Hostovani ARM & RISC-V & dalsich desek

by Pavel Snajdr

Ahojte, od zacatku roku bojujeme spolu se vsemi ostatnimi, co chteji sdilet vykonne masiny, se zranitelnostmi procesoru. Blizici se GDPR (na ktere uz konecne pripravujeme smernici, btw) a celkove stav kyberprostoru myslim pro ty z nas, co si ceni soukromi vic, znamena neklidny spanek. Spectre a Meltdown mame softwarove workaroundnute, po par mesicich boje, uff. Branchscope? Zatim ani naznak reseni, to zas pristane do upstreamu jeden fajny patch a pak budeme vymyslet backporty na vsechno mozne, ze... No. Jake to ma reseni? Pokud nemuzu pro citliva data v RAM v kazdy moment 100.0% verit, ze se na ne nemuze divat nekdo jiny, nepomuze ani sifrovani, protoze staci najit v dumpu sifrovaci klice a je to. Resenim je tedy mit svoji RAM pod kontrolou. Jak na to? Virtualizace? Kde ze, napr. Spectrem prolezete i pres ni. Jediny, co mne napadlo, je dat clenum moznost mit ciste svoji RAM pro sebe, pro citliva data. Tedy, kdo mate potrebu realne chranit nejake zaznamy, dostanete moznost mit tu ci onu databazi na samostatnem pocitaci, na ktery nema primy pristup nikdo jiny. Jak? Zaciname varit hardware, ktery bude fungovat jako podpurny management pro jednodeskove pocitace, ktere si: - donesete sami a my je umistime do datacentra - nakoupime spolecne hromadne Ja mam vysoke standardy a tak muzu rict, ze mi Rasberry Pi stacit nebude, ani trojka (za mne moc pomale, no). Cortex-A53 s 1 GB LPDDR2 RAM mi prijde OK tak pro testovani a hrani si s takovou "secure enklavou", nebo pro uplne nekriticke pouziti; ja bych osobne uvital vykonnejsi desky s vice RAM. Moje uvaha je, ze kdyz budu mit kombo CPU a RAM pro sebe, mam vcelku pod kontrolou, jestli se mi z te moji enklavy da vyladovat data nejakou zranitelnosti v CPU. Ale nechtel bych behat do datacentra menit SD karty - bohuzel, vetsina desek bootovat ze site naprimo neumi; u nekterych se PXE-bootovat da pomoci chainloadu z u-bootu z SD karty, ale taky ne u vsech. Ja bych chtel mit storage zalohovany a na nejakem solidnejsim ulozisti, nez je SD karta. Proto v Base48 startujeme projekt HW emulatoru SD karty & managementu SBCs (napisu mail behem par dni, o co jde). S tim se taky sveze podpora power on/off, resetu a serioveho portu pro remote consoli. Zaroven s tim jeste resime sifrovani remote konzole, protoze pokud mam mit data na cizim ulozisti, budu je sifrovat - a nejak musim v pripade rebootu/vypadku napajeni dodat klic k tomu pocitaci tak, abych te ceste mohl verit. Pravdepodobne to bude obnaset fyzickou navstevu v nekterem z hackerspaces po republice, abyste zanesli nejaky svuj klic/heslo na hardwarovy token, ktery bude pouzivan k sifrovane komunikaci s management deskou - aby nebylo mozne precist klic k sifrovanym diskum po ceste, kdyz ho do toho pocitace budete zadavat. Chteli bychom management "secure enklav" zaintegrovat do vpsAdminu, aby se dalo: - tomu systemu pristoupit na konzoli pri odrezani se - zapnout/vypnout "natvrdo" - ale taky vymenit "virtualni SD kartu" - udelat snapshot, obnovit ze zalohy - pripadne SD kartu zpristupnit do nektereho z kontejneru na x86 infrastrukture a oddebugovat si to pod QEMU Co se tyce "BYOD", tedy "dones si svoje zarizeni", pozadavky budou: - rozumna spotreba a rozmery (5V napajeni, rozmery max okolo rozmeru 3.5" pevneho disku) - microSD/SD slot z ktereho se bootuje (pripadne boot ze site bez potreby SD karty je taky v poho) - 1/2 ethernety (1000/100/10M) No a co se tyce hromadnejsiho sehnani HW: - chtel bych, abychom meli aspon par desek RISC-V a mohli to zpristupnit tem, kteri na tom potrebuji odladit open-source balicek a podobne -> kdo budete chtit RISC-V pro sebe, muzete se pridat - potom bych chtel rozumne ARMv8 (64bit) desky s aspon 4 GB RAM (zatim je muj favorit SoC RK3399) - nejaky pool Raspberrycek asi taky neuskodi A co mne laka uplne nejvic, cela open-source komunita by tak mela moznost si umistit nekam HW, ktery muze delat dokola automatizovane testovani software na tech deskach, protoze: 1. reset 2. remote storage 3. remote console 4. remote GPIO 5. to cele vzdalene pres API/CLI Predstavy o clenskych prispevcich jeste uplne nemam, ale cilim to tak, ze jedna deska by znamenala maximalne cca standardni clensky prispevek (tj. 300/mes) a budto v tom bude nejakej defaultni Rasp Pi a XYZ GB storage, nebo si prinesete svoji desku a budete k tomu pak mit storage o ABC GB navic oproti prvni variante. Kdo jste docetl az sem a koho to zaujalo, prosim? Ozvete se s feedbackem. Hodil by se lepsi nazev, nez "secure enclave", protoze to uz ma hodne dlouho moc jablecny zavan :) Diky za reakce, /snajpa

7 years

3
3
0 0

Infrastruktura vpsfree.cz

by Pavel Hruška

Ahojte, četl jsem si ve znalostní bázi o infrastruktuře vpsfree.cz ( https://kb.vpsfree.cz/informace/infrastruktura), můj dotaz jestli je popsaný stav aktuální? Jsem u vpsfree.cz přes dva roky a řeším teď infrastrukturu ve firmě, tedy v menším měřítku (3 fyzické servery) a také díky vpsfree.cz se začínám zajímat více o (opensource) linuxovou virtualizaci a především ZFS. Dozvědět se více o tom, jak funguje infrastruktura vpsfree.cz by byla skvělá inspirace, např. zkušenosti se servery, jak přesněji je řešeno úložiště, co výpadky nodů (jestli jsou a jak se to případně řeší) atp. Nedá někde zjistit více, nebude nějaká konference, přednáška, ...? Díky, Pavel

7 years, 1 month

11
45
0 0

Prevoz kabelu z Prahy do Brna

by Pavel Snajdr

Ahojte, potreboval bych z Prazskeho datacentra (Vrsovice) prevezt nekolik 10Gbit kabelu do Brna, nejedete nahodou nekdo zitra smer Brno? Kdyztak bych to nechal poslat kuryrem, ale pokud jezdite nekdo pravidelne, nemusel bych s tim otravovat nekoho, kdo netusi poradne, co je datacentrum... Dik za pomoc :) /snajpa PS. kabely pujdou na instalaci 10Gbit patere do Brna, tam s 10Gbity zacneme v novem racku (presuneme stavajici HW ze sdileneho racku, pristanou tam 10Gbit switche a casem tam prijde i NAS).

7 years, 1 month

1
1
0 0

vpsFree + docker + openjdk-9 = SIGSEGV

by Martin Sivák

Ahoj, napadá Vás někoho co může za následující chování? Dělají to jen ty na debianu založené kontejnery. Alpine (8-jre-alpine) funguje v pohodě. [root@vps ~]# docker run openjdk:9-jre java --version Unable to find image 'openjdk:9-jre' locally Trying to pull repository docker.io/library/openjdk ... 9-jre: Pulling from docker.io/library/openjdk 2115d46e7396: Already exists daa734ed5aa0: Already exists 801e6e5516c1: Already exists 404c3612208c: Already exists 258506b48a3e: Already exists b8ae0883616a: Already exists a9b93d536da3: Already exists Digest: sha256:aea139f395628bcc1ec57ecba8b319ee395d31158a47754f56286afe09220700 Status: Downloaded newer image for docker.io/openjdk:9-jre # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f3bf98f1324, pid=1, tid=12 # # JRE version: OpenJDK Runtime Environment (9.0+12) (build 9.0.4+12-Debian-2) # Java VM: OpenJDK 64-Bit Server VM (9.0.4+12-Debian-2, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libc.so.6+0x36324] abort+0x244 # # Core dump will be written. Default location: //core.1 (may not exist) # # An error report file with more information is saved as: # //hs_err_pid1.log library initialization failed - unable to get max # of allocated fds # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Díky Martin Sivák

7 years, 1 month

8
13
0 0

(no subject)

by Caesar Consulting

Ahoj, zdá se mi to, nebo po aplikaci posledního patche klesla celkem o dost zátěž serverů? Jak jsem zjistil ve vlastních sledováních na mém VPS, kde zátěž klesla tak o polovinu, tak i ve VPS adminu vidím, že servery jsou mnohem méně vytížené než dříve, tedy alespoň podle údaje o CPU. U mě kleslo zatížení jader i RAM, a to celkem o dost. Tak nevím, jestli za to může ten patch, nebo nějaká jiná aktualizace, ale zajímá mě to. :) S přátelským pozdravem Caesar

7 years, 1 month

2
1
0 0

Mohl mi reverzní DNS záznam rozbít domény?

by Jaroslav Týc

Ahoj, nechával jsem si přes podporu VPS free přidat reverzní DNS záznam 77.93.223.244 -> mail.jaroslavtyc.com a 2a01:430:17:1::ffff:169 -> mail.jaroslavtyc.com Jenže od té doby požadavky na jakoukoli doménu na této IP adrese skončí na mail.jaroslavtyc.com ping drdplus.info PING drdplus.info (77.93.223.244) 56(84) bytes of data 64 bytes from mail.jaroslavtyc.com (77.93.223.244): icmp_seq=1 ttl=56 time=3.48 ms Měl jsem za to, že PTR ovlivňuje *pouze* e-mail, respektive že servery přijímající poštu ode mě si přes PTR ověří, že odesílatel není podvod? Poraďte mi prosím, co jsem nedomyslel, díky, Jarda

7 years, 2 months

3
4
0 0

Drupal - 28.3. 18-19:30 UTC - vyjde patch na highly critical zranitelnost

by Jiri Volf

Ahoj vespolek, kdo provozujete Drupal, udelejte si pristi tyden ve stredu vecer cas... vyslo upozorneni na budouci bezpecnostni zaplatu vysoce kriticke chyby... Jirka Volf ---------- Forwarded message ---------- From: <security-news(a)drupal.org> Date: 2018-03-21 20:41 GMT+01:00 Subject: [Security-news] Drupal 7 and 8 core critical release on March 28th, 2018 PSA-2018-001 To: security-news(a)drupal.org View online: https://www.drupal.org/psa-2018-001 * Advisory ID: DRUPAL-PSA-2018-001 * Project: Drupal Core * Version: 7.x, 8.x * Date: 2018-March-21 -------- DESCRIPTION --------------------------------------------------------- There will be a security release of *Drupal 7.x, 8.3.x, 8.4.x, and 8.5.x on March 28th 2018 between 18:00 - 19:30 UTC*, one week from the publication of this document, that will fix a highly critical security vulnerability. The Drupal Security Team urges you to reserve time for core updates at that time because exploits /might/ be developed within hours or days. Security release announcements will appear on the Drupal.org security advisory page [1]. While Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases [2], given the potential severity of this issue, we /are/ providing 8.3.x and 8.4.x releases that includes the fix for sites which have not yet had a chance to update to 8.5.0. The Drupal security team strongly recommends the following: * Sites on 8.3.x should immediately update to the 8.3.x release that willbe provided in the advisory, and then plan to update to the latest 8.5.x security release in the next month. * Sites on 8.4.x should immediately update to the 8.4.x release that willbe provided in the advisory, and then plan to update to the latest 8.5.x security release in the next month. * Sites on 7.x or 8.5.x can immediately update when the advisory isreleased using the normal procedure. The security advisory will list the appropriate version numbers for all three Drupal 8 branches. Your site's update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x, but temporarily updating to the provided backport for your site's current version will ensure you can update quickly without the possible side effects of a minor version update. The Security Team or any other party is not able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at www.drupal.org/security [3], over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab. Journalists interested in covering the story are encouraged to email security-press(a)drupal.org to be sure they will get a copy of the journalist-focused release. The Security Team will release a journalist-focused summary email at the same time as the new code release and advisory. If you find a security issue, please report it at https://www.drupal.org/security-team/report-issue [4]. [1] https://www.drupal.org/security [2] https://www.drupal.org/core/release-cycle-overview [3] www.drupal.org/security [4] https://www.drupal.org/security-team/report-issue _______________________________________________ Security-news mailing list Security-news(a)drupal.org Unsubscribe at https://lists.drupal.org/mailman/listinfo/security-news

7 years, 2 months

1
0
0 0

nameserver

by vpsfree＠taborpolana.cz

ahoj, poradíte, mám od někoho koupenou domenu a u nich nastavene presmerovani na vpsfree na moji IP adresu (A a AAA záznamy). Kdybych chtěl nastavovat přímo nameserver, musel bych na svém vps provozovat vlastní nameserver (dns), nebo můžu použít něco jaklo ns1.brq.vpsfree.cz? díky Petr Bolf

7 years, 2 months

10
18
0 0

Re: [vpsFree.cz: community-list] GDPR a uvedení do praxe

by Martin Myška

Sorry, netušil jsem že už něco řešíte :-) No, z mojí strany to nebylo ani tak o tom to za vpsFree vyřešit jako spíš se nad tím zamyslet.. Omlouvám se - příště budu psát věcně přímo tobě. Dne 1. 3. 2018 21:12 napsal uživatel "Pavel Snajdr" <snajpa(a)snajpa.net>: Joj Martine, kdybys mi prv napsal, tak bys vedel, ze uz to mam rozreseny s Petrem Capkem, vsechno totok ;-) V tom, co pises, podporujes spoustu FUDu, co se o GDPR siri, tak ja bych to byt tebou nechal, az co nam Petr navrhne. Kazdopadne ale si vazim iniciativy, nicmene si s tim nemusis lamat hlavu, nechme to starsim borcum, co maji za sebou i reseni nejakych tech situaci ci dvou ;) Akorat vcera jsem Petrovi poslal vsechny potrebny podklady ;-) A ono nejde jenom o GDPR, pro info sem hodim scope spoluprace, jak jsme se s Petrem dohodli, citace z myho mailu: """ - tedka prvni tri mesice, jak jsme se dohodli [ze poresis vpsFree GDPR compliance], clenstvi za 0 - dalsi spolupraci bych videl trvale onboard vpsFree tymu, aby legal bylo v pohode; -> pokud bude potreba, draftovat zmeny nasich dokumentu a vytvaret dokumentaci -> az budeme resit blockchain, bude potreba to checknout legalne napric Evropou, atd. a spravne naimplementovat minimalne do CZ stanov z fleku -> vyst vyrobu vyrocni zpravy, aby kazdy z tymu dodal jeho cast a spolu s Petrem Krcmarem z toho udelat nejakou publikovatelnou vec (tohle nam strasne chybi IMHO, aj pro nas samotny pro ohlidnuti do historie). -> trvale se zasazovat o otevreny principy v IT ve jmenu vpsFree a byt videt -> publikovat clanky u nas na blogu a na dalsich mediich na souvisejici temata ^ -> celkove resit za nas trochu "legal" aktivismu -> za to ti umime nabidnout do 10k/mes na fakturu. => jde o to, abys dostal prilezitost vic dupnout do veci, co te bavi a nebyl treba tolik cas/motivace :) """ Toz tak ;) /snajpa On 2018-03-01 21:01, Martin Myška wrote: > Zdravím všechny z vpsFree! > Společně s kolegou pracuji na GDPR a jeho praktických dopadech na > jednotlivé technické úpravy. Potřeboval bych tak nějak vysondovat > pár věcí, které já sám nejsem schopný z vlastní zkušenosti > dát dohromady, nebo se mi nedaří na ně najít v google správné > odpovědi. > > - Povinností která nám GDPR uděluje bude zaznamenávat takřka > všechno, co se týče manipulace s údaji, ty se obvykle ukládají v > databázi a je k nim nějak přistupováno (ať už pseudonymizovaně > nebo ne) - zajímalo by mě, jak moc je datově náročné logovat > všechno, co se v databázi děje? Měl bych být schopný mít > zpětně k dispozici ideálně roční log.. popravdě ale netuším > zda takový log může mít 1gb, 20gb nebo třeba rovnou 1TB.. jak to > máte vy? > > - Mají snajpa (a další "výše postavení) nějaký přímý > přístup k souborům serveru? > > Jde o velkou věc, probírali jsme spolu také situaci vpsfree a > dobrali jsme se k několika bodům.. > > - Měli bychom mít s poskytovatelem (Master Internet) housingu a > konektivity smlouvu, která by jasně stanovovala kdo má k serveru > fyzický přístup (z jejich strany.. tj. jejich zaměstnanci a tak > vůbec) - kde jsou umístěny kamery, jak dlouho se ukládají > záznamy z kamer.. > > - Člen by pak měl mít se spolkem skutečně sepsanou smlouvu, s > kterou by se přenášely práva.. co je však teoreticky možné, je > jednotná forma smlouvy, která by se nějak zakomponovala do > "podmínek členství", pak by mělo stačit nějak zaznamenat souhlas > každého člena s tímto a měli bychom být za vodou :-) Snažil > jsem se spojit s někým z vpsfree abychom mohli detailněji probrat > celou situaci a případně s mým kolegou rovnou domluvit nějaké > sepsání papírů a projetí právníkem, abychom byli v suchu, ale > nikdo mi nereagoval.. tak možná si mě teď někdo všimne? :-) > > Moc díky za každou reakci! > > S pozdravem, > > MARTIN MYŠKA > > _______________________________________________ > Community-list mailing list > 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

7 years, 2 months

1
0
0 0

TPM chip

by Libor Boldan

Ahoj, nemame u nas, nebo nekdo ze clenu na zapujceni TPM chip: AOM-TPM-9665V-S - TPM 2.0 modul (2U+) Mam zakaznika, ktery potrebuje rychle neco otestovat. Mozna by na otestovani stacil i ten horizontalni modul, jde o klasickou stanici "pod stul" a E5 CPU. Dik Libor Boldan

7 years, 2 months

1
0
0 0

GDPR a uvedení do praxe

by Martin Myška

Zdravím všechny z vpsFree! Společně s kolegou pracuji na GDPR a jeho praktických dopadech na jednotlivé technické úpravy. Potřeboval bych tak nějak vysondovat pár věcí, které já sám nejsem schopný z vlastní zkušenosti dát dohromady, nebo se mi nedaří na ně najít v google správné odpovědi. - Povinností která nám GDPR uděluje bude zaznamenávat takřka všechno, co se týče manipulace s údaji, ty se obvykle ukládají v databázi a je k nim nějak přistupováno (ať už pseudonymizovaně nebo ne) - zajímalo by mě, jak moc je datově náročné logovat všechno, co se v databázi děje? Měl bych být schopný mít zpětně k dispozici ideálně roční log.. popravdě ale netuším zda takový log může mít 1gb, 20gb nebo třeba rovnou 1TB.. jak to máte vy? - Mají snajpa (a další "výše postavení) nějaký přímý přístup k souborům serveru? Jde o velkou věc, probírali jsme spolu také situaci vpsfree a dobrali jsme se k několika bodům.. - Měli bychom mít s poskytovatelem (Master Internet) housingu a konektivity smlouvu, která by jasně stanovovala kdo má k serveru fyzický přístup (z jejich strany.. tj. jejich zaměstnanci a tak vůbec) - kde jsou umístěny kamery, jak dlouho se ukládají záznamy z kamer.. - Člen by pak měl mít se spolkem skutečně sepsanou smlouvu, s kterou by se přenášely práva.. co je však teoreticky možné, je jednotná forma smlouvy, která by se nějak zakomponovala do "podmínek členství", pak by mělo stačit nějak zaznamenat souhlas každého člena s tímto a měli bychom být za vodou :-) Snažil jsem se spojit s někým z vpsfree abychom mohli detailněji probrat celou situaci a případně s mým kolegou rovnou domluvit nějaké sepsání papírů a projetí právníkem, abychom byli v suchu, ale nikdo mi nereagoval.. tak možná si mě teď někdo všimne? :-) Moc díky za každou reakci! S pozdravem, *Martin Myška*

7 years, 2 months

2
1
0 0

Posfix+dovecot+mysql problém s přijmem pošty

by Petr Parolek

Ahoj, záhadně mi přestaly chodit mail na Debianu 8. Chci mít zabezpečený přístup k poště přístupný pouze přes webmail a když je potřeba povolím externí IP adresu. Log: https://pastebin.com/1zEeyPgk SQL. INSERT INTO `virtual_users` (`id`, `domain_id`, `password`, `email`, `allow_nets`) VALUES (5, 6, '', 'petr.parolek(a)webnazakazku.cz', '127.0.0.1,::1,77.93.223.248,a01:430:17:1::ffff:153'), /etc/dovecot/dovecot-sql.conf.ext ... password_query = SELECT email as user, password, allow_nets FROM virtual_users WHERE email='%u'; ... Zkoušel jsem různé kombinacev databazi, nikdy mi mail nedošel nebo jsem se dokonce nemohl přihlásit přes webmail. Díky moc za pomoc. Pezr

7 years, 2 months

2
1
0 0

Supermicro

by Libor Boldan

Ahoj, jenom technicko-obchodni dotaz - kupujeme severy v Abacusu, nebo v Anafre? Mate zkusenosti v rozdilech? Libor Boldan

7 years, 2 months

2
1
0 0

vpsFree mirror pro Debian

by Jan B. Kolář

Ahoj, prosím, funguje Vám vpsFree mirror pro Debian? Na playgroundu si zkouším upgrade z Debian 8 na 9 a když si upravím sources.list na: ===== deb http://mirror.vpsfree.cz/debian/ stretch main deb-src http://mirror.vpsfree.cz/debian/ stretch main deb http://mirror.vpsfree.cz/debian/ stretch-updates main deb-src http://mirror.vpsfree.cz/debian/ stretch-updates main deb http://security.debian.org/ stretch/updates main deb-src http://security.debian.org/ stretch/updates main ===== tak mi to hází následující: Hit http://security.debian.org stretch/updates InRelease Možná mi něco uniká, ale když tam zadám klasické "ftp.cz.debian.org/debian/" tak to jede v pohodě. Díky Honza

7 years, 2 months

3
5
0 0

Load average

by Caesar Consulting

Ahoj, chtěl jsem jen zeptat, jaké hodnoty jsou ještě v pořádku, a jaké už ne. V závislosti na různých konfiguracích SQL, webserveru a PHP dochází ke snížení nebo zvýšení zátěže procesoru. Chtěl bych vědět, kde je nějaká hranice, kterou bych neměl dosahovat nebo překračovat, Něco ve stylu 0.5 je v pohodě, ale 1.5 už třeba ne. Ne, že bych danou hranici chtěl nějak atakovat a využívat povolený výkon na doraz, ale jen pro klid v duši, abych se nemusel bát, že mě to při nějaké hodnotě začne shapovat výkon, atd. Taky se mi zdá, že VPSAdmin ukazuje vyšší hodnoty než ostatní utility, které používám. Jak u paměti, tak u server load. Ovšem nevím, za jakou dobu to VPSAdmin zobrazuje. Díky a hezký den.

7 years, 2 months

4
3
0 0

Pomoc na Linux Tage

by Petr Krcmar

Ahoj, zase chceme letos se stánkem vpsFree.cz jet na Linux Tage do Saské Kamenice. Potřebujeme někoho do party, upřímně: někoho s autem, kdo nám tam pomůže odvézt věci. Budete mít 10. a 11. března čas na výlet do Německa? https://chemnitzer.linux-tage.de/2018/de -- Petr Krčmář vpsFree.cz

7 years, 3 months

1
0
0 0

Převoz věcí z Liberce na InstallFest

by Petr Krcmar

Ahoj, jede někdo z vás za dva týdny z Liberce na InstallFest? Mám tu pár věcí, které je potřeba tam hodit, dá se to do tašky nebo batohu, ale já to tam nemůžu odvézt, budu před tím cestovat a pak pojedu rovnou do Prahy na IF, takže to nemůžu tahat. Najde se někdo ochotný, kdo si to tento týden vyzvedne a pak tam přiveze? Dík -- Petr Krčmář vpsFree.cz

7 years, 3 months

1
0
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Je to tak jak rika Jirka. VpsFree si udela samo datovy audit z hlediska osobnich udaju ktere eviduje o clenech a sepise si na papir kde a v jakem rozsahu jsou a hlavne zadokumentuje jaka opatreni uz ma (procesy a technicka nastaveni) aby to vypadalo jako rizena prace s riziky. Pak pravni dokumenty typu informovane souhlasy. To same si udelaji clenove ale v jinem ramci, uz na urovni jejich provozovane technologie php eshopy a podobne a zase seznam opatreni, proces kdyz nekdo odvola souhlas se zpracovanim, seznam opatreni. To jsou veci ktere si kazdy muze pripravit uz ted. Predstava, ze vpdfree je tu od toho aby zajistila soulad s gdpr je mylna. To si musi zajistit kazdy clen sam, tj. nemluvim o technickem svete. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Jindřich Sadílek <jindrich.sadilek(a)gmail.com> Datum: 31.01.18 1:41 (GMT+01:00) Komu: community-list(a)lists.vpsfree.cz Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Jedna věc je, co si musí pořešit VPSfree jako organizace, zcela jiná pak jendotliví správci vlastních žiletek. Provozujete nějaký jednoduchý eshop, máte uživatelské registrace a pošlete semtam email, natož považovatelný za reklamní? Jste v tom až po uši... Dne St, 31. leden 2018 v 00:30 h uživatel Jirka Bourek napsal: Problém je, že tohle všechno řeší technické věci, které udělat chceš, ale neřeší to chybějící papíry, které potřebuješ pro úřad. Jasně, v oboru "no tak nám procesory trochu leakujou paměť, hlavně že jsem náhodou včas prodal akcie" nějakou skutečnou ochranu osobních údajů v podstatě řešit nejde. Jenže to úředníky z EU nezajímá - ti vymysleli směrnici na ochranu osobních údajů, takže se osobní údaje chrání tak, jak nařizuje směrnice. Až přijde kontrola, argumentace "dyť je to nesmysl!" nic nezachrání. Takže správce potřebuje se zpracovatelem mít smlouvu nebo jiný právní akt. Pokud je právním aktem - dostatečným pro úřad - členství v vpsfree, tak je asi všechno v poho. (http://www.privacy-regulation.eu/cs/28.htm) Pokud ne, tak je problém. Jinak teda > Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou ma zodpovednost, best practices v ohledu bezpecnosti davno sleduje. Co když to neví, nebo na to dlabe? :-) Pavel Snajdr wrote: Stejne jako oskenovat, co ti tam bezi a dostat se ti tam bez zvednuti my pohodlny zadele, obzvlast pokud jedes nejakou PHPkovinu a data, ktery by bylo potreba chranit, jsou primo v DB, kam ty PHP spagety vidi. A co ted s tim, vypneme to vsehno? ;) Chci tim rict, ze panikrit IMHO neni na miste a kdyz se nad tim clovek zamysli, zasifrovat vsechno taky neni reseni. Jinak ja jsem za GDPR rad, mam vymluvu, proc si sebou budu nosit klicenku s trhavinou na flashkach, mame vymluvu, proc plosne nasadit sifrovani, proc se nam nepujde dostat do racku neautorizovane, aniz by to neodmazlo klice a neshodilo vsehno chraneny (tj. abys nam fakt nechtel otevrit ten rack). Ne ze by GDPR neco resilo, ale dava van super vymluvu, jak muzem nase systemy postupne posouvat vic smerem plausible deniability, tj. soukromi je level jedna, level nuda, ale co nam to umozni je ochranit i adminy pred tim, aby vedeli, co clen bezi. Neumel jsem si bez GDPR predstavit, jak zvysovat zabezpeceni bez toho, aby to vypadalo, jako kdyz se chystame hostovat tunu detskyho porna a lokalni pobocku CIA. Jenom to nebude vsehno hned - a nektery levely zabezpeceni na sharovanym hardwaru ani nepujde udelat. Chci: - sifrovani v ZoL - aby clen mel moznost klic per dataset neulozit, ale zadat si ho sam pres bezpecny kanal (ssh/https api call) - monitoring otevreni racku co bez nahlaseni predem donuti masiny smazat klice z RAM Ale tohle je furt malo, pokud admini nemaji vedet, co clen bezi. Ani fullvirt ani se sifrovanou RAM na AMD nam nepomuze, takze resim, jak zahostovat single board desky pro cleny, kteri chteji mit moznost nejcitlivejsi data mit fakt soukrome. Ve finale: - budes mit moznost data na VPS sifrovat svymi hesly, ktera se u nas nebudou ukladat (prusvih je, ze my nemame jak dokazat, ze jsme to nikde neulozili) - pri neautorizovanym pristupu do racku se klice smaznou, to samy pri rebootu/resetu a je pak na tobe zvazit, jestli je OK data uz odemknout - budes mit moznost nejcitlivejsi data vysoupnout vedle po siti na svuj dedikovanej systemek kalibru ARM Cortex A53, do budoucna RISC-V Problem nastava, kdyz s adminkem pujde do datacentra nekdo sebedulezitejsi, nez GDRP byrokrat s kulometem u palice, pak admin nema moznost ani nejak kliknout smazani klicu, nebo aspon nejakej counter na webu ve smyslu kanarka, ktery bude pocitat pocet podobnych incidentu. Shared computing ma svoje limity, bohuzel, jestli sledujes, kam tim mirim. GDPR podle mne vyzaduje nutne jenom nejaky papirovani, ale do budoucna nam dava zaminku jit na to vic z husta, co se soukromi tyce. Muze nam pak nekdo nadavat, ze delame hosting detskyho porna a teroristum, kdyz mame racky obehnany pomalu ziletkovym dratem? Nemuze, at si stezuje v Bruselu. Za mne dobry, ale nebude to hned. A v prvni vlne bude hlavne to papirovani. V druhy vlne se musime zbavit nedostacujiciho OpenVZ, vpsAdminOS ma podstatne lip ovladatelnejsi bezpecnostni politiku - a je odspoda nahoru cely podepsany a verifikovatelny. /snajpa On 30 Jan 2018, at 23:41, Jaroslav Skrivan <skrivy(a)skrivy.net> wrote: Jenom moje osobni zkusenost - odnest si cizi disky z datacentra neni zas takovy problem, jak se na prvni pohled muze zdat. From: Pavel Snajdr Sent: ‎1/‎30/‎2018 10:49 PM To: vpsFree.cz Community list Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj, GDPR je, pokud to dobre chapu, totalni nesmysl, z kteryho jsou vsichni vyjukani uplne, ale naprosto totalne zbytecne. Podivej se, co bezime za procesory. Jak ma nekdo neco v takovym stavu vubec industry-wide za neco rucit? Za mne je GDPR o tom a pouze o tom, ze musime podepsat papir s lidmi, co maji admin pristupy, aby acknuli oficialne svoji zodpovednost. V seznamu clenu uz ted mame jenom nejnutnejsi udaje (podle posledni zkusenosti s PCR a PSR jim k identifikaci ani to nemusi stacit...). Ve stanovach mame zakotvenou ochranu dat clenu uz od zacatku. Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou ma zodpovednost, best practices v ohledu bezpecnosti davno sleduje. A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to vyresi, tak se rovnou zeptam - a borci, jak se k tomu asi programy na ty masine dostanou? Hint: stejne musi byt data odemcena pri behu. A ze se k nim neco dostane za behu je mnoooohem pravdepodobnejsi, nez ze nam z hlidanyho datacentra nekdo ukradne disky a vycte si neco offline. Tedy, muj nazor je, ze vubec neni potreba panikarit a natoz se uchylovat k reseni stylem ‘radsi to na vpsFree nedam vubec’. To ty servery muzeme rovnou vypnout totiz - a cely to zabalit s tim, ze jsme se nechali prevalcovat byrokratama. /snajpa (Pavel Snajdr) (Predseda vpsFree.cz) (+420 720 107 791) On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN <lukas(a)aiken.cz> wrote: Ahoj, pokud si vzpomínám, tak něco podobného už se řešilo na valné hromadě (byť ještě nebylo nařízení GDPR). A situace je v podstatě taková, že to asi příliš řešit nelze, protože by to pro spolek znamenalo velkou administrativní zátěž a značný nárůst nákladů. Čili asi nejčistším řešením v tuto chvíli je, nevyužívat servery vpsFree.cz k ukládání osobních údajů - přinejmenším do doby, než se všechny záležitosti vyřeší (a než vůbec vznikne nějaký závazný výklad různých ustanovení směrnice). Lukáš Jelínek Ahoj ve spolek! Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree. Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten webserver, kde se logují IP adresy, které jsou rovněž považovány za osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě správci osobních údajů a vpsFree je zpracovatelem osobních údajů. Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree? V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách jsou kompetentnější členové v této věci jako já a tak bých rád otevřel diskusi. Honza. _______________________________________________ Community-list mailing list 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 _______________________________________________ Community-list mailing list 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 _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

19
63
0 0

Nastavení firewalu

by slimbit

Dobrý den, všechno se teprve učím a opravte mne, jestli melu kraviny. Hraji si s nastavením iptables a nemohu použít ipset, hashlimit? Jde mi o to, že jsem chtěl udělat omezení počtu spojení na jednu ipadresu. Jak to tedy mám udělat?

7 years, 3 months

2
2
0 0

Pozvánka na první Pyvo v Liberci 14. února

by Ondřej Caletka

Ahoj, již tuto středu se v Liberci uskuteční první Pyvo – tedy setkání programátorů nejen v Pythonu. Kdo jste z okolí a máte čas a chuť, doražte: https://pyvo.cz/liberec-pyvo/2018-02/ A pokud to máte daleko, vězte, že Pyva jsou i v dalších českých a moravských městech – určitě tam doražte a šiřte povědomí o spolku vpsFree.cz a o tom, co všechno svým členům přináší! Na všechny se ve středu v Liberci těšíme. Ondřej Caletka a Petr Krčmář

7 years, 3 months

1
0
0 0

Jak tunelovat přes SSH

by Jaroslav Týc

Ahoj, snažím se o spojení s jedním Redis serverem přes SSH tunel a nějak se mi nedaří. Nakopněte mě prosím správným směrem. - Na server se přes SSH mohu připojit přes /ssh jaroslavtyc(a)example.com/ - Protože ale nechci zadávat heslo, tak mám v .ssh/config nastaveno Host example-production HostName example.com User jaroslavtyc IdentityFile ~/.ssh/id_rsa_example_com - A heslo si za mě pamatuje ssh-agent, takže /ssh example-production/ šlape dobře. - Server example.com vidí na Redis na dalším serveru přes lokální DNS jméno a port /redis1.foo:6380/ - Zkouším tedy /ssh -L 6379:redis1.foo:6380 example-production/, ale ssh mě pouze připojí k serveru přes SSH, takže koukám na konzoli na example-production serveru a tunel se nekoná... Jak můžu tunelovat přes SSH s identifikací přes klíč? Díky!

7 years, 3 months

5
4
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Ahoj,uzivatel chodi za nejakou sluzbou ne za routerem. Myslim ze je v poradku pokud spravce vpsky seznami uzivatele v politice o zpracovani osobnich udaju, ze jeho relace ( Ip adresa a cookie( se loguje po dobu 1mesice a pak je smazana ( rotaci logu) Stejne tak i pozadavek na odstraneni osobniho udaje bude vyreseb ve lhute 30 dnu. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Matěj Koudelka <matej(a)hxpro.cz> Datum: 02.02.18 14:39 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Dne 2. února 2018 14:26 Ondrej.Flidr <Ondrej.Flidr(a)seznam.cz> napsal(a): Tohle je prave ta zasadni otazka - pokud je podle GDPR IP adresa osobni udaj uzivatele tak ji smazat z logu, zaloh apod. musis. A nikoho nezajima ze ji nemas jak sparovat, to jsi si mel zajistit. Defakto pujde o to ze veskery data, ktery muzou bejt osobnim udajem musime mit sparovatelny s konkretni osobou a smazatelny. OK, no takže chcete-li vstoupit na můj web, ukažte občanku.. super. To je fakt absurdistán tady toto. Si asi budu muset najít čas si to nařízení přečíst. Neexistuje nějakej opensource od NSA, který by uměl takové informace získávat a evidovat? -- Matěj Koudelka+420 604 266 933

7 years, 3 months

7
7
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Ahoj, vymaz ihned lze provest jedine tehdy, pokud jsou vsechny osobni udaje na jednom miste. Asi tezko nekdo bude chodit po infrastrukture a promazavat logy. To by ta zarizeni musela byt na to pripravena. Takze ve skutecnosti to dopadne tak, ze nektere udaje treba jako ip adresa v logu proste budou ulozeny) ale budou se premazavat treba denne.(pokud zde neni jiny zakony pozadavek na drzeni je dele). Na aplikacni urovni to bude jeste horsi, protoze nelze uplne ovlivnit web aplikace a frameworky php ktere jen tak nekdo rychle neprekoduje Takze jde o to udelat prakticke maximum a pockat na zakonou praxi (kauzy, postup uradu a vyklady) Pokud provozuji kvetinarstvi a mam 100 zakazniku tak jdyz utece cela moje databaze tak ten dopad je porad maly. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: "Ondrej.Flidr" <Ondrej.Flidr(a)seznam.cz> Datum: 02.02.18 15:14 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ta lhuta 30 dnu na vymazani neprojde: právo na výmaz údajů (právo být zapomenut) - subjekt údajů má za určitých podmínek stanovených v nařízení, právo vznést požadavek na výmaz údajů. Správce dat má povinnost tyto údaje bez odkladu vymazat s ohledem na zákonné povinnosti evidence. OF ---------- Původní e-mail ---------- Od: Petr Juhaňák <petr(a)juhanak.cz> Komu: vpsFree.cz Community list <community-list(a)lists.vpsfree.cz> Datum: 2. 2. 2018 15:07:58 Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj,uzivatel chodi za nejakou sluzbou ne za routerem. Myslim ze je v poradku pokud spravce vpsky seznami uzivatele v politice o zpracovani osobnich udaju, ze jeho relace ( Ip adresa a cookie( se loguje po dobu 1mesice a pak je smazana ( rotaci logu) Stejne tak i pozadavek na odstraneni osobniho udaje bude vyreseb ve lhute 30 dnu. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Matěj Koudelka <matej(a)hxpro.cz> Datum: 02.02.18 14:39 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Dne 2. února 2018 14:26 Ondrej.Flidr <Ondrej.Flidr(a)seznam.cz> napsal(a): Tohle je prave ta zasadni otazka - pokud je podle GDPR IP adresa osobni udaj uzivatele tak ji smazat z logu, zaloh apod. musis. A nikoho nezajima ze ji nemas jak sparovat, to jsi si mel zajistit. Defakto pujde o to ze veskery data, ktery muzou bejt osobnim udajem musime mit sparovatelny s konkretni osobou a smazatelny. OK, no takže chcete-li vstoupit na můj web, ukažte občanku.. super. To je fakt absurdistán tady toto. Si asi budu muset najít čas si to nařízení přečíst. Neexistuje nějakej opensource od NSA, který by uměl takové informace získávat a evidovat? -- Matěj Koudelka+420 604 266 933 _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

1
0
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Obetujte prachy za skoleni a zeptejte se Evy https://www.gdpr.cz/skoleni/ S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Jiří Pucherna <pucherna(a)reklalink.cz> Datum: 02.02.18 8:10 (GMT+01:00) Komu: community-list(a)lists.vpsfree.cz Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj (znovu a lepe tentokrat do listu misto snajpova emailu), pravniku je vsude dost problem je ze musi sam rozumet tomu co po nem budeme chtit a tady uz z vlastni zkusenosti vim, ze to neni vubec snadny ukol... Ono totiz u pravniku je dost casto silny pocit ze pokud to napisou hodne slozite tak = nikdo tomu nerozumi = nemusi tomu rozumet sam = nikdo to nebude resit (i za cenu uvedeni naprostych technickych nesmyslu). Takze pokud nekdo kvalitniho pro tenhle ucel zna (a nebere 5k za hodinu) tak si tak rad vezmu kontakt. K tomu podepisovani -> pokud se nepletu tak ceske pravo umoznuje uzavirat smlouvy ustne, telefonicky a snad i emailem takze pokud bude nejaky papir, ktery budeme ztvrzovat ustni / jakoukoli jinou dohodou tak za me proc ne. Sice u toho GDPR se to nejak nedoporucuje ale to se tyka spis konkretniho zpracovani osobnich udaju pro marketing. Zaverem si myslim, ze pokud bude vpsfree hrat jednomyslne to co psal snajpa tj. bezpecnost hraje prim v kazdem pripade a jen to nejaky advokat co vi co bude psat hezky zavaze maslickou tak bych se taky moc nebal. Minimalne zatim budou kontroly jen na udani protoze tech co to maji kontrolovat je jako safranu to zaprve a zadruhe tomu budou rozumet asi jako zbytek lidi... Ja zastavam nazor ze dokud v necem nerozhodne soud tak si kazdej v GDPR muze vytvaret co chce :)). Hezky den Jirka On 2.2.2018 01:03, Pavel Snajdr wrote: > On 2018-02-02 00:19, Jirka Bourek wrote: >>> Jestli to nepujde udelat bez papiru, poplatku a pravniku, tak silne >>> zvazuju se presunout mimo EU nadobro. >> >> Zcela chápu, ale pak spousta členů bude muset odejít, protože z GDPR >> AFAIK vyplývá i povinnost mít data v EU. >> >>> Pokud EU zacina vymyslet pravidla prohibitivni pro moje fungovani v >>> jejim ramci, nastava pro mne pomalu cas zvazovat odchod mimo EU. To >>> neprehanim, uvazuju nad tim uz nejakou dobu a pri tom, jak se tu >>> blyska na lepsi casy, co se svobody tyce, po vsech strankach, mam >>> celkovou chut se tu na to vykaslat. >> >> Až vymyslíš, KAM odejít, aby to nebylo horší, tak dej vědět :-) > > Jo, je videt, ze uz mne kousek znas :D > > No, a tak - hlavni je, se z toho neposr*ti, ze. Baleni a vybirani > destinace pro jednosmernou letenku muzu na chvili jeste odlozit, pokud > se jsme schopni dohodnout na tom, > ze budeme hledat nejakou vlastni cestu, jak tyhle vymysly > implementovat a ze budeme vzdycky hledet to implementovat s co > nejmensim dopadem na cleny. Velmi by se mi libilo, kdyby vpsFree mohla > byt takova trochu oaza normalnosti. Kde se soukromi respektuje a ne si > na nej jenom hrajeme. > > Treba s tim logovanim - kde je nejaka ochrana soukromi, pokud zacneme > logovat spojeni pres routery? > > Jsem toho nazoru, ze auditovatelnost by mela byt na aplikacnim levelu > tam, kde je potreba - a pak by mela taky prikladat do audit logu > patricne metadata, na ktere vidi jenom ta aplikace sama. Jako treba, > ktery konkretni uzivatel to spojeni udelal a jake pouzil klice, IP > adresy a porty z netflow jsou nedostatecne. > > Nebo tedka podepisovani papiru vyjmenovavajici, jake udaje si nas clen > chrani, to preci vytvari dalsi velmi citlivou databazi (at uz > papirove, nebo na pocitaci), ktera je automaticky velmi vysoko v > DOWANT listu, pokud chci nejakou organizaci pwnout... Takhle tedy ne. > Plausible deniability is the key here. Nechci vedet, co kdo u nas > bezi. Pro mne je to vsechno apriori citlive. > > Mate nekdo kontakt na rozumny pravniky? Kdyz uz to budem resit... > > Zaroven teda, jaky jsou vsechny situace, ktery potrebujeme vystihnout? > > Mame tu eshopisty, webhostery, ruzne webove aplikace; koho dalsiho > bychom meli zahrnout, kdyz budem nejako stavet reseni pro vsechny? > > Nejaky rozpocet na rozumneho pravnika by asi byl (otazka je, kolik > konkretne - jestli to bude vic, nez nejakych 100k, tak se to da ). > > Rozhodne nechci nikam do chainu pridavat nejakou autogramiadu, musime > to vymyslet bez ni. > > Ale muzeme ten chain-of-GDPR-trust vymyslet napric az do konce. > > Hledame tedy nekoho, kdo nam pomuze prorazit nejakou nasi vlastni GDPR > implementaci. > > Dik predem za tipy :) > > /snajpa > >> _______________________________________________ >> Community-list mailing list >> 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 -- ------------------------------------------------- Reklalink s.r.o. | A. Jiráska 260 | Příbram | 261 01 Telefon: +420 724 330 493 | Web: http://www.reklalink.cz _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

3
2
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Ahoj, pozor na prizivniky kteri chteji z gdpr vykresat penize. Netvrdim ze jejich toolky nemaji zadnou hodnotu ale to ma spise smysl dohodnout externiho poradce, ktery uz v gdpr jede (ale je problem jej sehnat, odborniku je malo a uz jsou alokovani na projektech a zadarmo to neni) Zaregistroval jsem tento nastroj doufam ze je zdarma delaji to frantici a ma to i ceskeho prekladatele https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protec… S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Stepan Liska <stepan(a)comlinks.cz> Datum: 01.02.18 11:13 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj, a) nedávno jsem se účastnil prezentace od firmy 24LCS. Byl tam právník a evidentně se zabývá poslední rok hlavně GDPR. Mají cosi co stojí nějakých 30-40tis. za první rok a potom cca 16tis. roční fee. Za to poskytují jakousi online aplikaci, kde si vedete svojí GDPR dokumentaci. Ale hlavně - v ceně je možnost zvednout telefon a zavolat na helpdesk. Druhá věc - snaží se získat jakousi certifikaci - aby měli oficiální právo vydat bumážku GDPR-compliant co by ÚOOÚ uznával. Je to samozřejmě aby se vlk nažral a koza zůstala celá, ale z nabídek co jsem viděl na zpracování GDPR to byla jedna z nejnižších a přitom nejrozumnějších. b) z toho co jsem na různých prezentacích pochytil, tak se bohužel obávám, že mít nějaký dokument pro všechny není možné. Jediné co by bylo možné je vytvořit šablony v ODF, které by si mohl každý povyplňovat. Ono ta aplikace v a) je v podstatě něco takového. Naklikáte tam informace o firmě, předmětech činnosti, pobočkách, odděleních, na nich zpracovávaných typech údajů a zodpovědných lidech a ono to vygeneruje wizard s milionem zaškrtávátek a pak z toho vypadne jakási obrovská přehledová tabulka. Štěpán. Dne 1.2.2018 v 10:46 Petr Juhaňák napsal(a): Ahoj, to je dobry napad, bohuzel papiry jsou nekdy dulezitejsi nez realita. A udelat zakladni chybu by bylo popreni dosavadniho usili. Nename tady kolegu z korporatu ktery provozuje IasS sluzbu a je v konceptech a vzorech dokumentu dal? Pravnik ty dokumenty nepostavi na zelene louce. S pozdravem Petr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: "Ing. Jan Dvořák" <jan.dvorak(a)dvorak-sw.com> Datum: 01.02.18 10:31 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj, taky bych se přikláněl v této možnosti řešení. Pokud by byl problém s financemi tak bych navrhoval se nějakým způsobem na právní služby složit. Upřímně, nerad ale opravdu velmi nerad bych se dostal do situace, kdybych byl nucen migrovat jinam jenom kvůli tomuto. Honza. Dne 2018-02-01 10:19, Lapčík Miroslav napsal: > Ahoj, > > nebylo by vhodnější, abychom jako sdružení kontaktovali právníka, který > by nám připravil potřebné dokumenty pro sdružení vč. vzoru pro > jednotlivé členy? Předpokládám, že cca 90% členů bude mít stejné > dokumenty tzn. zpracovává "podobný" typ dat pro "podobné"účely. > > Sdružení by mělo dokumenty po právní stránce v pořádku, využití a > úprava > vzoru už by bylo na zodpovědnost každého člena. > > Možná by se to dalo uhradit jednorázovým poplatkem na GDPR od každého > člena? > > Budeme to muset řešit téměř všichni, tak si myslím, že by mohlo být > výhodnější to řešit společně, ale netuším zda je to vůbec takhle možné. > > --- > > Mirek > > Dne 31.1.2018 v 21:15 Pavel Snajdr napsal(a): >> Cauko Honzo, >> >> diky za obsahlou odpoved. >> >> Co mi neni jasny: >> >> musime mit explicitni smlouvu s kazdym clenem, pokud rada spolku >> proste vyda potreba narizeni/opatreni v ramci soucasnych organizacnich >> radu spolku? >> >> Tj. proste to bude platit pro vsechny cleny naprosto stejne, ze: >> >> - data jsou na specifikovanych mistech viz dokumentace infrastruktury >> na wiki >> - k datum maji pristup specifikovane osoby viz dokumentace na wiki >> - k datum ma potencialne, ale ne primo ani vyslovne pristup >> subdodavatel (Master Internet) >> - lidi s pristupem k datum maji pridanou motivaci neskodit pomoci >> nejake hmotne zodpovednosti/NDA, kde se specifikuje, za co a proc maji >> zodpovednost (root access, vpsAdmin-level access). >> >> A vymalovano, plus minus par drobnosti - tak si to jednoduse >> predstavuju. >> >> Nebo to neni tak jednoduche? >> >> Pokud ne, proc? >> >> Jak konkretne to poresilo FORPSI? >> >> A jinak, kdyby prislo tvrde na tvrde, za co, pekne prosim, muzeme >> dostat pokutu zrovna my, transparentni organizace, pokud: >> >> - seznam lidi, co maji pristupy, mame uz daavno verejny >> - umisteni dat - je verejne od zacatku >> - pouzite technologie jsou publikovane od zacatku >> - primo ve stanovach mame, ze o citlivych datech ma rada i kontrolni >> komise zachovavat mlcenlivost >> >> V cem konkretne nejsme pripraveni, kdyz se teda budem bavit o nejake >> dokazatelnosti toho, ze nejsme pripraveni, pripadne u soudu? >> >> Za co muzem dostat pokutu, kdyz rizika mame takhle jasne popsana >> davno, kazdy je (doufam) chape (jako kde jsou masiny, kdo ma pristup, >> co to znamena bezet na sdilenem HW... co to znamena bezet ve sdilenem >> datacentrum). Vzdyt to pisem vsude od zacatku, jak co delame. >> >> Prosim, moc pekne prosim, lidi, dejte mi proti tomu neco >> konkretnejsiho nez "IMHO" nazory motivovane strachem z byrokratu. >> Nepodelal jsem se zatim z financniho uradu, nepodelam se na svoji >> zodpovednost ani z GDPR, jenom musim vedet absolutne presne, s cim mam >> tu cest, abych si to "na svoji hubu" umel obhajit. >> >> Ucetniho jsem pro vpsFree taky hledal podle toho, aby stal za nami, ze >> to co delame, proste *NENI* podnikani a stojim si za tim a stat budu u >> soudu, pokud na to nekdy prijde. >> >> Obdobny pristup bych rad praktikoval ohledne GDPR, prosim linkujte >> relevantni info, proc to neni, jak si myslim, proc si myslim kraviny. >> Tedy, idealni endgame je ne, ze se nas zpracovani nijak netyka, ale ze >> co delame, je dostatecne transparentni a je dostatecne dohledatelna >> zodpovednost uz ted, aniz by bylo v podstate potreba cokoliv menit. >> >> Diky moc za feedback ;) >> >> /snajpa >> >> On 2018-01-31 20:46, Ing. Jan Dvořák wrote: >>> Ahoj! >>> >>> IMHO to co je ve stanovách rozhodně stačit nebude. Nechci teď řešit >>> členskou evidenci, apod. To je další věc k řešení, ale teď začnu >>> trochu ze široka. Poskytování VPS je služba IaaS (infrastruktura jako >>> služba). vpsFree, jako ten kdo tuto službu poskytuje je dle GDPR >>> zpracovatelem osobních údajů. To jestli má přístup k osobním údajům >>> členů na VPS nebo ne není rozhodující. Pokud vpsFree nebude mít >>> smluvní ujednání se správci (členy) tak může být považován přímo za >>> správce sám. Toto vše je novinka GDPR. Doposud se na tyto >>> zpracovatele >>> legislativa v oblasti osobních údajů nevztahovala nebo se dala >>> obejít. >>> >>> Takže vpsFree má IMHO dvě možnosti. Buď jasně deklaruje, že >>> poskytnutá >>> VPS jsou pouze pro osobní potřebu a zakáže členům zpracovávat na VPS >>> jakékoliv osobní údaje. Tím pádem nebude muset řešit žádné GDPR, což >>> ale bude znamenat odchod členů, na které se GDPR vztahuje. Nebo bude >>> muset s každým členem, který bude na VPS zpracovávat osobní údaje >>> uzavřít zpracovatelskou smlouvu. GDPR poměrně jasně stanovuje co >>> taková smlouva má obsahovat a tak jen heslovitě: >>> - předmět a trvání zpracování >>> - povaha a účel zpracování >>> - typ osobních údajů a kategorii subjektů údajů >>> - povinnosti a práva správce >>> - povinnosti zpracovatele (zpracování osobní údajů jen na základě >>> dokumentovaných pokynů správce, zajistit důvěrnost, přijmout vhodná >>> bezpečnostní opatření) >>> Co z toho by se vztahovalo na smlouvu mezi vpsFree a členem, to je >>> otázka na právníka. Dokázal bych si představit, že členové s takovou >>> smlouvou by mohli mít třeba o něco vyšší členský poplatek, aby se >>> pokryly vícenáklady >>> >>> Termín účinnosti se pomalu ale jistě blíží. Ve firmách se provádí >>> různé audity a je třeba aby vpsFree co nejdříve jasně deklarovalo jak >>> se ke GDPR postaví, aby Ti členové, kterých se to týká (bohužel jsem >>> to i já) se mohli zařídit. >>> >>> Tento problém budou řešit všichni poskytovatelé hostingu, VPS, >>> cloudových služeb. V ČR je situace zatím tristní, zatím toto nikdo >>> neřešil, jedině FORPSI, co jsem viděl se k tomu zatím nějak >>> postavili. >>> Co jsem tak sondoval v zahraničí tak úplně připraveny jsou jen ti >>> největší (Microsoft, Amazon, apod.) a ti menší se postupně >>> připravují. >>> Nicméně ke změnám v Service Agreementech v souvislosti s GDPR určitě >>> bude docházet. >>> >>> Je třeba si taky říct, že s GDPR také přichází jedna zásadní změna. >>> Doposud porušení zákona správcem musel prokazovat úřad, ale s GDPR je >>> to naopak. Správce je ten, který musí prokazovat, že nic neporušil. >>> >>> A malá poznámka na závěr, jak zaznělo na jednom semináři. Největším >>> rizikem GDPR není vlastní nařízení, úřady, kontroly, pokuty apod. >>> Největším rizikem jsou lidé. Díky mediální masáži a bublině se může >>> objevit spoustu trollů, kteří díky GDPR dostanou do ruky jednoduchou >>> možnost škodit. >>> >>> Honza. >>> >>> >>> Dne 31.1.2018 v 08:12 zd nex napsal(a): >>>> Ahojte, >>>> >>>> také si tu směrnici vykládám tak, že každý člen musí za data na VPS >>>> zodpovídat sám (mít pověřenou osobu, která s tím pracuje + papír, že >>>> je o tom seznámená.) Co se týče dat na VPSFree, tak tam půjde >>>> primárně o to, jestli stačí to co je ve stanovách - či jestli nějak >>>> bude také potřeba tedy domluvit (sepsat smlouvu) mezi členem(jeho >>>> daty) a vpsfree nějak odděleně, nebo bude pouze stačit, aby to bylo >>>> ve stanovách - že jsou zde admini a následně jednotlivý členové co >>>> pracují s VPS(kteří jsou zodpovědní za data)? Tzn tím pádem, by >>>> nemělo být nutné nic měnit, kromě té specifikace - kdo a jaký má >>>> přístup k VPS a jakou zodpovědnost (plnou). >>>> >>>> -- S pozdravem, >>>> >>>> Zdeněk Dlauhý >>>> >>>> Email:support@pripravto.cz <mailto:support@pripravto.cz> >>>> Mobil: +420 702 549 370 >>>> Web: www.pripravto.cz <http://www.pripravto.cz> >>>> >>>> Dne 31. ledna 2018 6:21 Petr Juhaňák <petr(a)juhanak.cz >>>> <mailto:petr@juhanak.cz>> napsal(a): >>>> >>>> Je to tak jak rika Jirka. >>>> >>>> VpsFree si udela samo datovy audit z hlediska osobnich udaju >>>> ktere >>>> eviduje o clenech a sepise si na papir kde a v jakem rozsahu >>>> jsou a >>>> hlavne zadokumentuje jaka opatreni uz ma (procesy a technicka >>>> nastaveni) aby to vypadalo jako rizena prace s riziky. Pak >>>> pravni >>>> dokumenty typu informovane souhlasy. >>>> >>>> To same si udelaji clenove ale v jinem ramci, uz na urovni >>>> jejich >>>> provozovane technologie php eshopy a podobne a zase seznam >>>> opatreni, >>>> proces kdyz nekdo odvola souhlas se zpracovanim, seznam >>>> opatreni. >>>> >>>> To jsou veci ktere si kazdy muze pripravit uz ted. >>>> >>>> Predstava, ze vpdfree je tu od toho aby zajistila soulad s gdpr >>>> je >>>> mylna. To si musi zajistit kazdy clen sam, tj. nemluvim o >>>> technickem >>>> svete. >>>> >>>> >>>> >>>> S pozdravem >>>> Petr Juhaňák >>>> >>>> petr(a)juhanak.cz <mailto:petr@juhanak.cz> | +420 739 639 132 >>>> <tel:+420%20739%20639%20132> >>>> >>>> >>>> -------- Původní zpráva -------- >>>> Od: Jindřich Sadílek <jindrich.sadilek(a)gmail.com >>>> <mailto:jindrich.sadilek@gmail.com>> >>>> Datum: 31.01.18 1:41 (GMT+01:00) >>>> Komu: community-list(a)lists.vpsfree.cz >>>> <mailto:community-list@lists.vpsfree.cz> >>>> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR >>>> >>>> Jedna věc je, co si musí pořešit VPSfree jako organizace, zcela >>>> jiná >>>> pak jendotliví správci vlastních žiletek. >>>> >>>> Provozujete nějaký jednoduchý eshop, máte uživatelské registrace >>>> a >>>> pošlete semtam email, natož považovatelný za reklamní? Jste v >>>> tom až >>>> po uši... >>>> >>>> >>>> Dne St, 31. leden 2018 v 00:30 h uživatel Jirka Bourek napsal: >>>>> Problém je, že tohle všechno řeší technické věci, které udělat >>>>> chceš, >>>>> ale neřeší to chybějící papíry, které potřebuješ pro úřad. >>>>> >>>>> Jasně, v oboru "no tak nám procesory trochu leakujou paměť, >>>>> hlavně že >>>>> jsem náhodou včas prodal akcie" nějakou skutečnou ochranu >>>>> osobních >>>>> údajů >>>>> v podstatě řešit nejde. Jenže to úředníky z EU nezajímá - ti >>>>> vymysleli >>>>> směrnici na ochranu osobních údajů, takže se osobní údaje >>>>> chrání tak, >>>>> jak nařizuje směrnice. Až přijde kontrola, argumentace "dyť je >>>>> to >>>>> nesmysl!" nic nezachrání. >>>>> >>>>> Takže správce potřebuje se zpracovatelem mít smlouvu nebo jiný >>>>> právní >>>>> akt. Pokud je právním aktem - dostatečným pro úřad - členství v >>>>> vpsfree, >>>>> tak je asi všechno v poho. >>>>> (http://www.privacy-regulation.eu/cs/28.htm >>>>> <http://www.privacy-regulation.eu/cs/28.htm>) >>>>> Pokud ne, tak je problém. >>>>> >>>>> Jinak teda >>>>> >>>>> > Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou >>>>> ma >>>>> zodpovednost, best practices v ohledu bezpecnosti davno >>>>> sleduje. >>>>> >>>>> Co když to neví, nebo na to dlabe? :-) >>>>> >>>>> >>>>> Pavel Snajdr wrote: >>>>> >>>>> Stejne jako oskenovat, co ti tam bezi a dostat se ti tam >>>>> bez >>>>> zvednuti my pohodlny zadele, obzvlast pokud jedes nejakou >>>>> PHPkovinu a data, ktery by bylo potreba chranit, jsou primo >>>>> v >>>>> DB, kam ty PHP spagety vidi. >>>>> >>>>> A co ted s tim, vypneme to vsehno? ;) >>>>> >>>>> Chci tim rict, ze panikrit IMHO neni na miste a kdyz se nad >>>>> tim clovek zamysli, zasifrovat vsechno taky neni reseni. >>>>> >>>>> Jinak ja jsem za GDPR rad, mam vymluvu, proc si sebou budu >>>>> nosit klicenku s trhavinou na flashkach, mame vymluvu, proc >>>>> plosne nasadit sifrovani, proc se nam nepujde dostat do >>>>> racku >>>>> neautorizovane, aniz by to neodmazlo klice a neshodilo >>>>> vsehno >>>>> chraneny (tj. abys nam fakt nechtel otevrit ten rack). >>>>> >>>>> Ne ze by GDPR neco resilo, ale dava van super vymluvu, jak >>>>> muzem nase systemy postupne posouvat vic smerem plausible >>>>> deniability, tj. soukromi je level jedna, level nuda, ale >>>>> co >>>>> nam to umozni je ochranit i adminy pred tim, aby vedeli, co >>>>> clen bezi. >>>>> >>>>> Neumel jsem si bez GDPR predstavit, jak zvysovat >>>>> zabezpeceni >>>>> bez toho, aby to vypadalo, jako kdyz se chystame hostovat >>>>> tunu >>>>> detskyho porna a lokalni pobocku CIA. Jenom to nebude >>>>> vsehno >>>>> hned - a nektery levely zabezpeceni na sharovanym hardwaru >>>>> ani >>>>> nepujde udelat. >>>>> >>>>> Chci: >>>>> >>>>> - sifrovani v ZoL >>>>> - aby clen mel moznost klic per dataset neulozit, ale zadat >>>>> si >>>>> ho sam pres bezpecny kanal (ssh/https api call) >>>>> - monitoring otevreni racku co bez nahlaseni predem donuti >>>>> masiny smazat klice z RAM >>>>> >>>>> Ale tohle je furt malo, pokud admini nemaji vedet, co clen >>>>> bezi. Ani fullvirt ani se sifrovanou RAM na AMD nam >>>>> nepomuze, >>>>> takze resim, jak zahostovat single board desky pro cleny, >>>>> kteri chteji mit moznost nejcitlivejsi data mit fakt >>>>> soukrome. >>>>> >>>>> Ve finale: >>>>> >>>>> - budes mit moznost data na VPS sifrovat svymi hesly, ktera >>>>> se >>>>> u nas nebudou ukladat (prusvih je, ze my nemame jak >>>>> dokazat, >>>>> ze jsme to nikde neulozili) >>>>> >>>>> - pri neautorizovanym pristupu do racku se klice smaznou, >>>>> to >>>>> samy pri rebootu/resetu a je pak na tobe zvazit, jestli je >>>>> OK >>>>> data uz odemknout >>>>> >>>>> - budes mit moznost nejcitlivejsi data vysoupnout vedle po >>>>> siti na svuj dedikovanej systemek kalibru ARM Cortex A53, >>>>> do >>>>> budoucna RISC-V >>>>> >>>>> Problem nastava, kdyz s adminkem pujde do datacentra nekdo >>>>> sebedulezitejsi, nez GDRP byrokrat s kulometem u palice, >>>>> pak >>>>> admin nema moznost ani nejak kliknout smazani klicu, nebo >>>>> aspon nejakej counter na webu ve smyslu kanarka, ktery bude >>>>> pocitat pocet podobnych incidentu. >>>>> >>>>> Shared computing ma svoje limity, bohuzel, jestli sledujes, >>>>> kam tim mirim. >>>>> >>>>> GDPR podle mne vyzaduje nutne jenom nejaky papirovani, ale >>>>> do >>>>> budoucna nam dava zaminku jit na to vic z husta, co se >>>>> soukromi tyce. >>>>> >>>>> Muze nam pak nekdo nadavat, ze delame hosting detskyho >>>>> porna a >>>>> teroristum, kdyz mame racky obehnany pomalu ziletkovym >>>>> dratem? >>>>> Nemuze, at si stezuje v Bruselu. >>>>> >>>>> Za mne dobry, ale nebude to hned. A v prvni vlne bude >>>>> hlavne >>>>> to papirovani. V druhy vlne se musime zbavit >>>>> nedostacujiciho >>>>> OpenVZ, vpsAdminOS ma podstatne lip ovladatelnejsi >>>>> bezpecnostni politiku - a je odspoda nahoru cely podepsany >>>>> a >>>>> verifikovatelny. >>>>> >>>>> /snajpa >>>>> >>>>> On 30 Jan 2018, at 23:41, Jaroslav Skrivan >>>>> <skrivy(a)skrivy.net <mailto:skrivy@skrivy.net>> wrote: >>>>> >>>>> Jenom moje osobni zkusenost - odnest si cizi disky z >>>>> datacentra neni zas takovy problem, jak se na prvni >>>>> pohled >>>>> muze zdat. >>>>> From: Pavel Snajdr >>>>> Sent: ‎1/‎30/‎2018 10:49 PM >>>>> To: vpsFree.cz Community list >>>>> Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a >>>>> GDPR >>>>> >>>>> Ahoj, >>>>> >>>>> GDPR je, pokud to dobre chapu, totalni nesmysl, z >>>>> kteryho >>>>> jsou vsichni vyjukani uplne, ale naprosto totalne >>>>> zbytecne. >>>>> >>>>> Podivej se, co bezime za procesory. >>>>> >>>>> Jak ma nekdo neco v takovym stavu vubec industry-wide >>>>> za >>>>> neco rucit? >>>>> >>>>> Za mne je GDPR o tom a pouze o tom, ze musime podepsat >>>>> papir s lidmi, co maji admin pristupy, aby acknuli >>>>> oficialne svoji zodpovednost. >>>>> >>>>> V seznamu clenu uz ted mame jenom nejnutnejsi udaje >>>>> (podle >>>>> posledni zkusenosti s PCR a PSR jim k identifikaci ani >>>>> to >>>>> nemusi stacit...). >>>>> >>>>> Ve stanovach mame zakotvenou ochranu dat clenu uz od >>>>> zacatku. >>>>> >>>>> Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, >>>>> jakou ma zodpovednost, best practices v ohledu >>>>> bezpecnosti >>>>> davno sleduje. >>>>> >>>>> A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to >>>>> vyresi, tak se rovnou zeptam - a borci, jak se k tomu >>>>> asi >>>>> programy na ty masine dostanou? Hint: stejne musi byt >>>>> data >>>>> odemcena pri behu. A ze se k nim neco dostane za behu >>>>> je >>>>> mnoooohem pravdepodobnejsi, nez ze nam z hlidanyho >>>>> datacentra nekdo ukradne disky a vycte si neco offline. >>>>> >>>>> Tedy, muj nazor je, ze vubec neni potreba panikarit a >>>>> natoz se uchylovat k reseni stylem ‘radsi to na vpsFree >>>>> nedam vubec’. To ty servery muzeme rovnou vypnout totiz >>>>> - >>>>> a cely to zabalit s tim, ze jsme se nechali prevalcovat >>>>> byrokratama. >>>>> >>>>> /snajpa >>>>> (Pavel Snajdr) >>>>> (Predseda vpsFree.cz) >>>>> (+420 720 107 791 <tel:+420%20720%20107%20791>) >>>>> >>>>> On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN >>>>> <lukas(a)aiken.cz <mailto:lukas@aiken.cz>> wrote: >>>>> >>>>> Ahoj, >>>>> >>>>> pokud si vzpomínám, tak něco podobného už se řešilo >>>>> na >>>>> valné hromadě >>>>> (byť ještě nebylo nařízení GDPR). A situace je v >>>>> podstatě taková, že to >>>>> asi příliš řešit nelze, protože by to pro spolek >>>>> znamenalo velkou >>>>> administrativní zátěž a značný nárůst nákladů. >>>>> >>>>> Čili asi nejčistším řešením v tuto chvíli je, >>>>> nevyužívat servery >>>>> vpsFree.cz k ukládání osobních údajů - přinejmenším >>>>> do >>>>> doby, než se >>>>> všechny záležitosti vyřeší (a než vůbec vznikne >>>>> nějaký >>>>> závazný výklad >>>>> různých ustanovení směrnice). >>>>> >>>>> Lukáš Jelínek >>>>> >>>>> >>>>> >>>>> Ahoj ve spolek! >>>>> >>>>> Datum 25.5.2018, kdy nám vstupuje v účinnost >>>>> GDPR >>>>> se pomalu ale jistě >>>>> blíží. Bohužel jsem byl, ač neprávník do této >>>>> problematiky trochu >>>>> zatlačen a byly na mě již vzneseny dotazy >>>>> týkající >>>>> se GDPR a vpsFree. >>>>> >>>>> Myslím, si, že je nás více, kteří na VPS máme >>>>> uloženy nějaké ty osobní >>>>> údaje (adresy, emaily, apod.) a skoro všichni >>>>> máme >>>>> nějaký ten >>>>> webserver, kde se logují IP adresy, které jsou >>>>> rovněž považovány za >>>>> osobní údaje. Díky tomu jsme z pohledu GDPR >>>>> považování za správce >>>>> osobních údajů. Podle článku 4 GDPR se >>>>> zpracovaním >>>>> osobních údajů >>>>> rozumí také ukládání osobních údajů. Z toho >>>>> plyne, >>>>> že jakýkoliv >>>>> poskytovatel cloudových služeb, hostingu, VPS, >>>>> atd. je vůči správci v >>>>> postavení zpracovatele osobních údajů. Článek >>>>> 28 >>>>> GDPR potom řeší vztah >>>>> zpracovatele a správce, kde mj. požaduje nějaký >>>>> smluvní vztah mezi >>>>> nimi. Když to převedu na protředí vpsFree tak >>>>> členové jsou v podstatě >>>>> správci osobních údajů a vpsFree je >>>>> zpracovatelem >>>>> osobních údajů. >>>>> >>>>> Můj dotaz zní, zda a jak bylo nebo bude GDPR >>>>> řešeno na úrovní vpsFree? >>>>> V podstatě asi jde o to, aby bylo v případě >>>>> kontroly z UOOÚ možno >>>>> něčím nebo nějak prokázat, že vpsFree je v >>>>> souladu >>>>> s GDPR a taky >>>>> garantuje, že data nebudou uložena mimo EU. >>>>> Věřím, >>>>> že v našich řadách >>>>> jsou kompetentnější členové v této věci jako já >>>>> a >>>>> tak bých rád otevřel >>>>> diskusi. >>>>> >>>>> Honza. >>>>> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>> >>>> >>>> _______________________________________________ >>>> Community-list mailing list >>>> Community-list(a)lists.vpsfree.cz >>>> <mailto:Community-list@lists.vpsfree.cz> >>>> http://lists.vpsfree.cz/listinfo/community-list >>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Community-list mailing list >>>> Community-list(a)lists.vpsfree.cz >>>> http://lists.vpsfree.cz/listinfo/community-list >>>> >>> >>> >>> -- >>> Ing. Jan Dvorak >>> **************************************** >>> Ing. Jan Dvorak >>> Fischerova 690/23 >>> 779 00 Olomouc, Nove Sady >>> Czech Republic >>> **************************************** >>> Tel: +420-603 444 240 >>> E-mail: jan.dvorak(a)dvorak-sw.com >>> Web: http://www.dvorak-sw.com >>> **************************************** >>> _______________________________________________ >>> Community-list mailing list >>> 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 > > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list -- Ing. Jan Dvorak **************************************** Ing. Jan Dvorak Fischerova 690/23 779 00 Olomouc, Nove Sady Czech Republic **************************************** Tel: +420 603 444 240 E-mail: jan.dvorak(a)dvorak-sw.com Web: http://www.dvorak-sw.com **************************************** _______________________________________________ Community-list mailing list 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

7 years, 3 months

1
0
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Ahoj, to je dobry napad, bohuzel papiry jsou nekdy dulezitejsi nez realita. A udelat zakladni chybu by bylo popreni dosavadniho usili. Nename tady kolegu z korporatu ktery provozuje IasS sluzbu a je v konceptech a vzorech dokumentu dal? Pravnik ty dokumenty nepostavi na zelene louce. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: "Ing. Jan Dvořák" <jan.dvorak(a)dvorak-sw.com> Datum: 01.02.18 10:31 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj, taky bych se přikláněl v této možnosti řešení. Pokud by byl problém s financemi tak bych navrhoval se nějakým způsobem na právní služby složit. Upřímně, nerad ale opravdu velmi nerad bych se dostal do situace, kdybych byl nucen migrovat jinam jenom kvůli tomuto. Honza. Dne 2018-02-01 10:19, Lapčík Miroslav napsal: > Ahoj, > > nebylo by vhodnější, abychom jako sdružení kontaktovali právníka, který > by nám připravil potřebné dokumenty pro sdružení vč. vzoru pro > jednotlivé členy? Předpokládám, že cca 90% členů bude mít stejné > dokumenty tzn. zpracovává "podobný" typ dat pro "podobné"účely. > > Sdružení by mělo dokumenty po právní stránce v pořádku, využití a > úprava > vzoru už by bylo na zodpovědnost každého člena. > > Možná by se to dalo uhradit jednorázovým poplatkem na GDPR od každého > člena? > > Budeme to muset řešit téměř všichni, tak si myslím, že by mohlo být > výhodnější to řešit společně, ale netuším zda je to vůbec takhle možné. > > --- > > Mirek > > Dne 31.1.2018 v 21:15 Pavel Snajdr napsal(a): >> Cauko Honzo, >> >> diky za obsahlou odpoved. >> >> Co mi neni jasny: >> >> musime mit explicitni smlouvu s kazdym clenem, pokud rada spolku >> proste vyda potreba narizeni/opatreni v ramci soucasnych organizacnich >> radu spolku? >> >> Tj. proste to bude platit pro vsechny cleny naprosto stejne, ze: >> >> - data jsou na specifikovanych mistech viz dokumentace infrastruktury >> na wiki >> - k datum maji pristup specifikovane osoby viz dokumentace na wiki >> - k datum ma potencialne, ale ne primo ani vyslovne pristup >> subdodavatel (Master Internet) >> - lidi s pristupem k datum maji pridanou motivaci neskodit pomoci >> nejake hmotne zodpovednosti/NDA, kde se specifikuje, za co a proc maji >> zodpovednost (root access, vpsAdmin-level access). >> >> A vymalovano, plus minus par drobnosti - tak si to jednoduse >> predstavuju. >> >> Nebo to neni tak jednoduche? >> >> Pokud ne, proc? >> >> Jak konkretne to poresilo FORPSI? >> >> A jinak, kdyby prislo tvrde na tvrde, za co, pekne prosim, muzeme >> dostat pokutu zrovna my, transparentni organizace, pokud: >> >> - seznam lidi, co maji pristupy, mame uz daavno verejny >> - umisteni dat - je verejne od zacatku >> - pouzite technologie jsou publikovane od zacatku >> - primo ve stanovach mame, ze o citlivych datech ma rada i kontrolni >> komise zachovavat mlcenlivost >> >> V cem konkretne nejsme pripraveni, kdyz se teda budem bavit o nejake >> dokazatelnosti toho, ze nejsme pripraveni, pripadne u soudu? >> >> Za co muzem dostat pokutu, kdyz rizika mame takhle jasne popsana >> davno, kazdy je (doufam) chape (jako kde jsou masiny, kdo ma pristup, >> co to znamena bezet na sdilenem HW... co to znamena bezet ve sdilenem >> datacentrum). Vzdyt to pisem vsude od zacatku, jak co delame. >> >> Prosim, moc pekne prosim, lidi, dejte mi proti tomu neco >> konkretnejsiho nez "IMHO" nazory motivovane strachem z byrokratu. >> Nepodelal jsem se zatim z financniho uradu, nepodelam se na svoji >> zodpovednost ani z GDPR, jenom musim vedet absolutne presne, s cim mam >> tu cest, abych si to "na svoji hubu" umel obhajit. >> >> Ucetniho jsem pro vpsFree taky hledal podle toho, aby stal za nami, ze >> to co delame, proste *NENI* podnikani a stojim si za tim a stat budu u >> soudu, pokud na to nekdy prijde. >> >> Obdobny pristup bych rad praktikoval ohledne GDPR, prosim linkujte >> relevantni info, proc to neni, jak si myslim, proc si myslim kraviny. >> Tedy, idealni endgame je ne, ze se nas zpracovani nijak netyka, ale ze >> co delame, je dostatecne transparentni a je dostatecne dohledatelna >> zodpovednost uz ted, aniz by bylo v podstate potreba cokoliv menit. >> >> Diky moc za feedback ;) >> >> /snajpa >> >> On 2018-01-31 20:46, Ing. Jan Dvořák wrote: >>> Ahoj! >>> >>> IMHO to co je ve stanovách rozhodně stačit nebude. Nechci teď řešit >>> členskou evidenci, apod. To je další věc k řešení, ale teď začnu >>> trochu ze široka. Poskytování VPS je služba IaaS (infrastruktura jako >>> služba). vpsFree, jako ten kdo tuto službu poskytuje je dle GDPR >>> zpracovatelem osobních údajů. To jestli má přístup k osobním údajům >>> členů na VPS nebo ne není rozhodující. Pokud vpsFree nebude mít >>> smluvní ujednání se správci (členy) tak může být považován přímo za >>> správce sám. Toto vše je novinka GDPR. Doposud se na tyto >>> zpracovatele >>> legislativa v oblasti osobních údajů nevztahovala nebo se dala >>> obejít. >>> >>> Takže vpsFree má IMHO dvě možnosti. Buď jasně deklaruje, že >>> poskytnutá >>> VPS jsou pouze pro osobní potřebu a zakáže členům zpracovávat na VPS >>> jakékoliv osobní údaje. Tím pádem nebude muset řešit žádné GDPR, což >>> ale bude znamenat odchod členů, na které se GDPR vztahuje. Nebo bude >>> muset s každým členem, který bude na VPS zpracovávat osobní údaje >>> uzavřít zpracovatelskou smlouvu. GDPR poměrně jasně stanovuje co >>> taková smlouva má obsahovat a tak jen heslovitě: >>> - předmět a trvání zpracování >>> - povaha a účel zpracování >>> - typ osobních údajů a kategorii subjektů údajů >>> - povinnosti a práva správce >>> - povinnosti zpracovatele (zpracování osobní údajů jen na základě >>> dokumentovaných pokynů správce, zajistit důvěrnost, přijmout vhodná >>> bezpečnostní opatření) >>> Co z toho by se vztahovalo na smlouvu mezi vpsFree a členem, to je >>> otázka na právníka. Dokázal bych si představit, že členové s takovou >>> smlouvou by mohli mít třeba o něco vyšší členský poplatek, aby se >>> pokryly vícenáklady >>> >>> Termín účinnosti se pomalu ale jistě blíží. Ve firmách se provádí >>> různé audity a je třeba aby vpsFree co nejdříve jasně deklarovalo jak >>> se ke GDPR postaví, aby Ti členové, kterých se to týká (bohužel jsem >>> to i já) se mohli zařídit. >>> >>> Tento problém budou řešit všichni poskytovatelé hostingu, VPS, >>> cloudových služeb. V ČR je situace zatím tristní, zatím toto nikdo >>> neřešil, jedině FORPSI, co jsem viděl se k tomu zatím nějak >>> postavili. >>> Co jsem tak sondoval v zahraničí tak úplně připraveny jsou jen ti >>> největší (Microsoft, Amazon, apod.) a ti menší se postupně >>> připravují. >>> Nicméně ke změnám v Service Agreementech v souvislosti s GDPR určitě >>> bude docházet. >>> >>> Je třeba si taky říct, že s GDPR také přichází jedna zásadní změna. >>> Doposud porušení zákona správcem musel prokazovat úřad, ale s GDPR je >>> to naopak. Správce je ten, který musí prokazovat, že nic neporušil. >>> >>> A malá poznámka na závěr, jak zaznělo na jednom semináři. Největším >>> rizikem GDPR není vlastní nařízení, úřady, kontroly, pokuty apod. >>> Největším rizikem jsou lidé. Díky mediální masáži a bublině se může >>> objevit spoustu trollů, kteří díky GDPR dostanou do ruky jednoduchou >>> možnost škodit. >>> >>> Honza. >>> >>> >>> Dne 31.1.2018 v 08:12 zd nex napsal(a): >>>> Ahojte, >>>> >>>> také si tu směrnici vykládám tak, že každý člen musí za data na VPS >>>> zodpovídat sám (mít pověřenou osobu, která s tím pracuje + papír, že >>>> je o tom seznámená.) Co se týče dat na VPSFree, tak tam půjde >>>> primárně o to, jestli stačí to co je ve stanovách - či jestli nějak >>>> bude také potřeba tedy domluvit (sepsat smlouvu) mezi členem(jeho >>>> daty) a vpsfree nějak odděleně, nebo bude pouze stačit, aby to bylo >>>> ve stanovách - že jsou zde admini a následně jednotlivý členové co >>>> pracují s VPS(kteří jsou zodpovědní za data)? Tzn tím pádem, by >>>> nemělo být nutné nic měnit, kromě té specifikace - kdo a jaký má >>>> přístup k VPS a jakou zodpovědnost (plnou). >>>> >>>> -- S pozdravem, >>>> >>>> Zdeněk Dlauhý >>>> >>>> Email:support@pripravto.cz <mailto:support@pripravto.cz> >>>> Mobil: +420 702 549 370 >>>> Web: www.pripravto.cz <http://www.pripravto.cz> >>>> >>>> Dne 31. ledna 2018 6:21 Petr Juhaňák <petr(a)juhanak.cz >>>> <mailto:petr@juhanak.cz>> napsal(a): >>>> >>>> Je to tak jak rika Jirka. >>>> >>>> VpsFree si udela samo datovy audit z hlediska osobnich udaju >>>> ktere >>>> eviduje o clenech a sepise si na papir kde a v jakem rozsahu >>>> jsou a >>>> hlavne zadokumentuje jaka opatreni uz ma (procesy a technicka >>>> nastaveni) aby to vypadalo jako rizena prace s riziky. Pak >>>> pravni >>>> dokumenty typu informovane souhlasy. >>>> >>>> To same si udelaji clenove ale v jinem ramci, uz na urovni >>>> jejich >>>> provozovane technologie php eshopy a podobne a zase seznam >>>> opatreni, >>>> proces kdyz nekdo odvola souhlas se zpracovanim, seznam >>>> opatreni. >>>> >>>> To jsou veci ktere si kazdy muze pripravit uz ted. >>>> >>>> Predstava, ze vpdfree je tu od toho aby zajistila soulad s gdpr >>>> je >>>> mylna. To si musi zajistit kazdy clen sam, tj. nemluvim o >>>> technickem >>>> svete. >>>> >>>> >>>> >>>> S pozdravem >>>> Petr Juhaňák >>>> >>>> petr(a)juhanak.cz <mailto:petr@juhanak.cz> | +420 739 639 132 >>>> <tel:+420%20739%20639%20132> >>>> >>>> >>>> -------- Původní zpráva -------- >>>> Od: Jindřich Sadílek <jindrich.sadilek(a)gmail.com >>>> <mailto:jindrich.sadilek@gmail.com>> >>>> Datum: 31.01.18 1:41 (GMT+01:00) >>>> Komu: community-list(a)lists.vpsfree.cz >>>> <mailto:community-list@lists.vpsfree.cz> >>>> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR >>>> >>>> Jedna věc je, co si musí pořešit VPSfree jako organizace, zcela >>>> jiná >>>> pak jendotliví správci vlastních žiletek. >>>> >>>> Provozujete nějaký jednoduchý eshop, máte uživatelské registrace >>>> a >>>> pošlete semtam email, natož považovatelný za reklamní? Jste v >>>> tom až >>>> po uši... >>>> >>>> >>>> Dne St, 31. leden 2018 v 00:30 h uživatel Jirka Bourek napsal: >>>>> Problém je, že tohle všechno řeší technické věci, které udělat >>>>> chceš, >>>>> ale neřeší to chybějící papíry, které potřebuješ pro úřad. >>>>> >>>>> Jasně, v oboru "no tak nám procesory trochu leakujou paměť, >>>>> hlavně že >>>>> jsem náhodou včas prodal akcie" nějakou skutečnou ochranu >>>>> osobních >>>>> údajů >>>>> v podstatě řešit nejde. Jenže to úředníky z EU nezajímá - ti >>>>> vymysleli >>>>> směrnici na ochranu osobních údajů, takže se osobní údaje >>>>> chrání tak, >>>>> jak nařizuje směrnice. Až přijde kontrola, argumentace "dyť je >>>>> to >>>>> nesmysl!" nic nezachrání. >>>>> >>>>> Takže správce potřebuje se zpracovatelem mít smlouvu nebo jiný >>>>> právní >>>>> akt. Pokud je právním aktem - dostatečným pro úřad - členství v >>>>> vpsfree, >>>>> tak je asi všechno v poho. >>>>> (http://www.privacy-regulation.eu/cs/28.htm >>>>> <http://www.privacy-regulation.eu/cs/28.htm>) >>>>> Pokud ne, tak je problém. >>>>> >>>>> Jinak teda >>>>> >>>>> > Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou >>>>> ma >>>>> zodpovednost, best practices v ohledu bezpecnosti davno >>>>> sleduje. >>>>> >>>>> Co když to neví, nebo na to dlabe? :-) >>>>> >>>>> >>>>> Pavel Snajdr wrote: >>>>> >>>>> Stejne jako oskenovat, co ti tam bezi a dostat se ti tam >>>>> bez >>>>> zvednuti my pohodlny zadele, obzvlast pokud jedes nejakou >>>>> PHPkovinu a data, ktery by bylo potreba chranit, jsou primo >>>>> v >>>>> DB, kam ty PHP spagety vidi. >>>>> >>>>> A co ted s tim, vypneme to vsehno? ;) >>>>> >>>>> Chci tim rict, ze panikrit IMHO neni na miste a kdyz se nad >>>>> tim clovek zamysli, zasifrovat vsechno taky neni reseni. >>>>> >>>>> Jinak ja jsem za GDPR rad, mam vymluvu, proc si sebou budu >>>>> nosit klicenku s trhavinou na flashkach, mame vymluvu, proc >>>>> plosne nasadit sifrovani, proc se nam nepujde dostat do >>>>> racku >>>>> neautorizovane, aniz by to neodmazlo klice a neshodilo >>>>> vsehno >>>>> chraneny (tj. abys nam fakt nechtel otevrit ten rack). >>>>> >>>>> Ne ze by GDPR neco resilo, ale dava van super vymluvu, jak >>>>> muzem nase systemy postupne posouvat vic smerem plausible >>>>> deniability, tj. soukromi je level jedna, level nuda, ale >>>>> co >>>>> nam to umozni je ochranit i adminy pred tim, aby vedeli, co >>>>> clen bezi. >>>>> >>>>> Neumel jsem si bez GDPR predstavit, jak zvysovat >>>>> zabezpeceni >>>>> bez toho, aby to vypadalo, jako kdyz se chystame hostovat >>>>> tunu >>>>> detskyho porna a lokalni pobocku CIA. Jenom to nebude >>>>> vsehno >>>>> hned - a nektery levely zabezpeceni na sharovanym hardwaru >>>>> ani >>>>> nepujde udelat. >>>>> >>>>> Chci: >>>>> >>>>> - sifrovani v ZoL >>>>> - aby clen mel moznost klic per dataset neulozit, ale zadat >>>>> si >>>>> ho sam pres bezpecny kanal (ssh/https api call) >>>>> - monitoring otevreni racku co bez nahlaseni predem donuti >>>>> masiny smazat klice z RAM >>>>> >>>>> Ale tohle je furt malo, pokud admini nemaji vedet, co clen >>>>> bezi. Ani fullvirt ani se sifrovanou RAM na AMD nam >>>>> nepomuze, >>>>> takze resim, jak zahostovat single board desky pro cleny, >>>>> kteri chteji mit moznost nejcitlivejsi data mit fakt >>>>> soukrome. >>>>> >>>>> Ve finale: >>>>> >>>>> - budes mit moznost data na VPS sifrovat svymi hesly, ktera >>>>> se >>>>> u nas nebudou ukladat (prusvih je, ze my nemame jak >>>>> dokazat, >>>>> ze jsme to nikde neulozili) >>>>> >>>>> - pri neautorizovanym pristupu do racku se klice smaznou, >>>>> to >>>>> samy pri rebootu/resetu a je pak na tobe zvazit, jestli je >>>>> OK >>>>> data uz odemknout >>>>> >>>>> - budes mit moznost nejcitlivejsi data vysoupnout vedle po >>>>> siti na svuj dedikovanej systemek kalibru ARM Cortex A53, >>>>> do >>>>> budoucna RISC-V >>>>> >>>>> Problem nastava, kdyz s adminkem pujde do datacentra nekdo >>>>> sebedulezitejsi, nez GDRP byrokrat s kulometem u palice, >>>>> pak >>>>> admin nema moznost ani nejak kliknout smazani klicu, nebo >>>>> aspon nejakej counter na webu ve smyslu kanarka, ktery bude >>>>> pocitat pocet podobnych incidentu. >>>>> >>>>> Shared computing ma svoje limity, bohuzel, jestli sledujes, >>>>> kam tim mirim. >>>>> >>>>> GDPR podle mne vyzaduje nutne jenom nejaky papirovani, ale >>>>> do >>>>> budoucna nam dava zaminku jit na to vic z husta, co se >>>>> soukromi tyce. >>>>> >>>>> Muze nam pak nekdo nadavat, ze delame hosting detskyho >>>>> porna a >>>>> teroristum, kdyz mame racky obehnany pomalu ziletkovym >>>>> dratem? >>>>> Nemuze, at si stezuje v Bruselu. >>>>> >>>>> Za mne dobry, ale nebude to hned. A v prvni vlne bude >>>>> hlavne >>>>> to papirovani. V druhy vlne se musime zbavit >>>>> nedostacujiciho >>>>> OpenVZ, vpsAdminOS ma podstatne lip ovladatelnejsi >>>>> bezpecnostni politiku - a je odspoda nahoru cely podepsany >>>>> a >>>>> verifikovatelny. >>>>> >>>>> /snajpa >>>>> >>>>> On 30 Jan 2018, at 23:41, Jaroslav Skrivan >>>>> <skrivy(a)skrivy.net <mailto:skrivy@skrivy.net>> wrote: >>>>> >>>>> Jenom moje osobni zkusenost - odnest si cizi disky z >>>>> datacentra neni zas takovy problem, jak se na prvni >>>>> pohled >>>>> muze zdat. >>>>> From: Pavel Snajdr >>>>> Sent: ‎1/‎30/‎2018 10:49 PM >>>>> To: vpsFree.cz Community list >>>>> Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a >>>>> GDPR >>>>> >>>>> Ahoj, >>>>> >>>>> GDPR je, pokud to dobre chapu, totalni nesmysl, z >>>>> kteryho >>>>> jsou vsichni vyjukani uplne, ale naprosto totalne >>>>> zbytecne. >>>>> >>>>> Podivej se, co bezime za procesory. >>>>> >>>>> Jak ma nekdo neco v takovym stavu vubec industry-wide >>>>> za >>>>> neco rucit? >>>>> >>>>> Za mne je GDPR o tom a pouze o tom, ze musime podepsat >>>>> papir s lidmi, co maji admin pristupy, aby acknuli >>>>> oficialne svoji zodpovednost. >>>>> >>>>> V seznamu clenu uz ted mame jenom nejnutnejsi udaje >>>>> (podle >>>>> posledni zkusenosti s PCR a PSR jim k identifikaci ani >>>>> to >>>>> nemusi stacit...). >>>>> >>>>> Ve stanovach mame zakotvenou ochranu dat clenu uz od >>>>> zacatku. >>>>> >>>>> Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, >>>>> jakou ma zodpovednost, best practices v ohledu >>>>> bezpecnosti >>>>> davno sleduje. >>>>> >>>>> A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to >>>>> vyresi, tak se rovnou zeptam - a borci, jak se k tomu >>>>> asi >>>>> programy na ty masine dostanou? Hint: stejne musi byt >>>>> data >>>>> odemcena pri behu. A ze se k nim neco dostane za behu >>>>> je >>>>> mnoooohem pravdepodobnejsi, nez ze nam z hlidanyho >>>>> datacentra nekdo ukradne disky a vycte si neco offline. >>>>> >>>>> Tedy, muj nazor je, ze vubec neni potreba panikarit a >>>>> natoz se uchylovat k reseni stylem ‘radsi to na vpsFree >>>>> nedam vubec’. To ty servery muzeme rovnou vypnout totiz >>>>> - >>>>> a cely to zabalit s tim, ze jsme se nechali prevalcovat >>>>> byrokratama. >>>>> >>>>> /snajpa >>>>> (Pavel Snajdr) >>>>> (Predseda vpsFree.cz) >>>>> (+420 720 107 791 <tel:+420%20720%20107%20791>) >>>>> >>>>> On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN >>>>> <lukas(a)aiken.cz <mailto:lukas@aiken.cz>> wrote: >>>>> >>>>> Ahoj, >>>>> >>>>> pokud si vzpomínám, tak něco podobného už se řešilo >>>>> na >>>>> valné hromadě >>>>> (byť ještě nebylo nařízení GDPR). A situace je v >>>>> podstatě taková, že to >>>>> asi příliš řešit nelze, protože by to pro spolek >>>>> znamenalo velkou >>>>> administrativní zátěž a značný nárůst nákladů. >>>>> >>>>> Čili asi nejčistším řešením v tuto chvíli je, >>>>> nevyužívat servery >>>>> vpsFree.cz k ukládání osobních údajů - přinejmenším >>>>> do >>>>> doby, než se >>>>> všechny záležitosti vyřeší (a než vůbec vznikne >>>>> nějaký >>>>> závazný výklad >>>>> různých ustanovení směrnice). >>>>> >>>>> Lukáš Jelínek >>>>> >>>>> >>>>> >>>>> Ahoj ve spolek! >>>>> >>>>> Datum 25.5.2018, kdy nám vstupuje v účinnost >>>>> GDPR >>>>> se pomalu ale jistě >>>>> blíží. Bohužel jsem byl, ač neprávník do této >>>>> problematiky trochu >>>>> zatlačen a byly na mě již vzneseny dotazy >>>>> týkající >>>>> se GDPR a vpsFree. >>>>> >>>>> Myslím, si, že je nás více, kteří na VPS máme >>>>> uloženy nějaké ty osobní >>>>> údaje (adresy, emaily, apod.) a skoro všichni >>>>> máme >>>>> nějaký ten >>>>> webserver, kde se logují IP adresy, které jsou >>>>> rovněž považovány za >>>>> osobní údaje. Díky tomu jsme z pohledu GDPR >>>>> považování za správce >>>>> osobních údajů. Podle článku 4 GDPR se >>>>> zpracovaním >>>>> osobních údajů >>>>> rozumí také ukládání osobních údajů. Z toho >>>>> plyne, >>>>> že jakýkoliv >>>>> poskytovatel cloudových služeb, hostingu, VPS, >>>>> atd. je vůči správci v >>>>> postavení zpracovatele osobních údajů. Článek >>>>> 28 >>>>> GDPR potom řeší vztah >>>>> zpracovatele a správce, kde mj. požaduje nějaký >>>>> smluvní vztah mezi >>>>> nimi. Když to převedu na protředí vpsFree tak >>>>> členové jsou v podstatě >>>>> správci osobních údajů a vpsFree je >>>>> zpracovatelem >>>>> osobních údajů. >>>>> >>>>> Můj dotaz zní, zda a jak bylo nebo bude GDPR >>>>> řešeno na úrovní vpsFree? >>>>> V podstatě asi jde o to, aby bylo v případě >>>>> kontroly z UOOÚ možno >>>>> něčím nebo nějak prokázat, že vpsFree je v >>>>> souladu >>>>> s GDPR a taky >>>>> garantuje, že data nebudou uložena mimo EU. >>>>> Věřím, >>>>> že v našich řadách >>>>> jsou kompetentnější členové v této věci jako já >>>>> a >>>>> tak bých rád otevřel >>>>> diskusi. >>>>> >>>>> Honza. >>>>> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> >>>>> >>>>> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>>> >>>>> _________________________________________________ >>>>> Community-list mailing list >>>>> Community-list(a)lists.vpsfree.cz >>>>> <mailto:Community-list@lists.vpsfree.cz> >>>>> http://lists.vpsfree.cz/listinfo/community-list >>>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>> >>>> >>>> _______________________________________________ >>>> Community-list mailing list >>>> Community-list(a)lists.vpsfree.cz >>>> <mailto:Community-list@lists.vpsfree.cz> >>>> http://lists.vpsfree.cz/listinfo/community-list >>>> <http://lists.vpsfree.cz/listinfo/community-list> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Community-list mailing list >>>> Community-list(a)lists.vpsfree.cz >>>> http://lists.vpsfree.cz/listinfo/community-list >>>> >>> >>> >>> -- >>> Ing. Jan Dvorak >>> **************************************** >>> Ing. Jan Dvorak >>> Fischerova 690/23 >>> 779 00 Olomouc, Nove Sady >>> Czech Republic >>> **************************************** >>> Tel: +420-603 444 240 >>> E-mail: jan.dvorak(a)dvorak-sw.com >>> Web: http://www.dvorak-sw.com >>> **************************************** >>> _______________________________________________ >>> Community-list mailing list >>> 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 > > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list -- Ing. Jan Dvorak **************************************** Ing. Jan Dvorak Fischerova 690/23 779 00 Olomouc, Nove Sady Czech Republic **************************************** Tel: +420 603 444 240 E-mail: jan.dvorak(a)dvorak-sw.com Web: http://www.dvorak-sw.com **************************************** _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

2
1
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Cau, ja jako spravce dat na "moji vps" nemam povinost nekomu rikat kde ty data jsou (jen v jakem rozsahu je zpracovavam a k cemu). Pokud by tyto informace chtel videt nejaky dozorovy organ, tak pak se s nim o tom budu bavit. Samozrejme ze pro svoji interni potrebu to na lejstro dam, abych to v pripade potreby mohl dolozit. Jako clen VpsFree se potrebuji ujistit, ze mi moji Vpsku administruji radne a prijmou opatreni (neco) a budu se muset oprit o nejaky pravni dokument. Z hlediska VPSFree je to dle meho soudu tak, ze poskytuje pouze technicke nastroje a administruje ty systemy a bude se snazit byt v souladu aby clenove neodesly. Kdyz to prezenu, pokud by clenove meli prazdne vpsky, jak by priprava na gdpr vypadala? S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Pavel Snajdr <snajpa(a)snajpa.net> Datum: 01.02.18 1:28 (GMT+01:00) Komu: "vpsFree.cz Community list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Jo, tohle by slo presne tam, cca tak, jak rikas. Jako pani, to fakt GDPR resi ochranu dat tim, ze vsem naokolo vykeca, kde ty data jsou a pak jakoze proti podpisu mame delat, ze na ne nevidime? Nechapu to. Neni pro nas lepsi vubec nevedet, jestli tam neco takovyho vubec je a za soukrome proste povazovat cokoliv z datasetu clena, kterehokoliv? Komu pomuze, ze nam presne vyslepici a jeste podepise, kde ta data ma? /snajpa On 2018-02-01 01:22, Slávek Banko wrote: > Ve Stanovách je odkazován Provozní řád, který je schvalovaný Radou. > > Pokud by navrhované prohlášení typu "všechní informační zařízení jejíž > použití poskytovává VPSFree a na které se zpracovává data jsou v EU" a > další pravidla související s GDPR mohl podchytit Provozní řád, pak by > možná mohl by být tím společným dokumentem závazným pro všechny? > > -- > Slávek > > On Thursday 01 of February 2018 00:12:28 Timothy Hobbs wrote: >> Já teď koukám na stanovy >> https://vpsfree.cz/download/stanovy_vpsfree.pdf a nevidím kde je >> napsáno, že "všechní informační zařízení jejíž použití poskytovává >> VPSFree a na které se zpracovává data jsou v EU". >> >> On 01/31/2018 08:12 AM, zd nex wrote: >> > Ahojte, >> > >> > také si tu směrnici vykládám tak, že každý člen musí za data na VPS >> > zodpovídat sám (mít pověřenou osobu, která s tím pracuje + papír, že >> > je o tom seznámená.) Co se týče dat na VPSFree, tak tam půjde >> > primárně o to, jestli stačí to co je ve stanovách - či jestli nějak >> > bude také potřeba tedy domluvit (sepsat smlouvu) mezi členem(jeho >> > daty) a vpsfree nějak odděleně, nebo bude pouze stačit, aby to bylo >> > ve stanovách - že jsou zde admini a následně jednotlivý členové co >> > pracují s VPS(kteří jsou zodpovědní za data)? Tzn tím pádem, by >> > nemělo být nutné nic měnit, kromě té specifikace - kdo a jaký má >> > přístup k VPS a jakou zodpovědnost (plnou). >> > >> > -- >> > S pozdravem, >> > >> > Zdeněk Dlauhý >> > >> > Email:support@pripravto.cz <mailto:support@pripravto.cz> >> > Mobil: +420 702 549 370 >> > Web: www.pripravto.cz <http://www.pripravto.cz> >> > >> > Dne 31. ledna 2018 6:21 Petr Juhaňák <petr(a)juhanak.cz >> > <mailto:petr@juhanak.cz>> napsal(a): >> > >> > Je to tak jak rika Jirka. >> > >> > VpsFree si udela samo datovy audit z hlediska osobnich udaju >> > ktere eviduje o clenech a sepise si na papir kde a v jakem rozsahu >> > jsou a hlavne zadokumentuje jaka opatreni uz ma (procesy a technicka >> > nastaveni) aby to vypadalo jako rizena prace s riziky. Pak pravni >> > dokumenty typu informovane souhlasy. >> > >> > To same si udelaji clenove ale v jinem ramci, uz na urovni jejich >> > provozovane technologie php eshopy a podobne a zase seznam >> > opatreni, proces kdyz nekdo odvola souhlas se zpracovanim, seznam >> > opatreni. >> > >> > To jsou veci ktere si kazdy muze pripravit uz ted. >> > >> > Predstava, ze vpdfree je tu od toho aby zajistila soulad s gdpr >> > je mylna. To si musi zajistit kazdy clen sam, tj. nemluvim o >> > technickem svete. >> > >> > >> > >> > S pozdravem >> > Petr Juhaňák >> > >> > petr(a)juhanak.cz <mailto:petr@juhanak.cz> | +420 739 639 132 >> > <tel:+420%20739%20639%20132> >> > >> > >> > -------- Původní zpráva -------- >> > Od: Jindřich Sadílek <jindrich.sadilek(a)gmail.com >> > <mailto:jindrich.sadilek@gmail.com>> >> > Datum: 31.01.18 1:41 (GMT+01:00) >> > Komu: community-list(a)lists.vpsfree.cz >> > <mailto:community-list@lists.vpsfree.cz> >> > Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR >> > >> > Jedna věc je, co si musí pořešit VPSfree jako organizace, zcela >> > jiná pak jendotliví správci vlastních žiletek. >> > >> > Provozujete nějaký jednoduchý eshop, máte uživatelské registrace >> > a pošlete semtam email, natož považovatelný za reklamní? Jste v tom >> > až po uši... >> > >> > Dne St, 31. leden 2018 v 00:30 h uživatel Jirka Bourek napsal: >> >> Problém je, že tohle všechno řeší technické věci, které udělat >> >> chceš, ale neřeší to chybějící papíry, které potřebuješ pro úřad. >> >> >> >> Jasně, v oboru "no tak nám procesory trochu leakujou paměť, >> >> hlavně že jsem náhodou včas prodal akcie" nějakou skutečnou ochranu >> >> osobních údajů >> >> v podstatě řešit nejde. Jenže to úředníky z EU nezajímá - ti >> >> vymysleli >> >> směrnici na ochranu osobních údajů, takže se osobní údaje chrání >> >> tak, jak nařizuje směrnice. Až přijde kontrola, argumentace "dyť je >> >> to nesmysl!" nic nezachrání. >> >> >> >> Takže správce potřebuje se zpracovatelem mít smlouvu nebo jiný >> >> právní akt. Pokud je právním aktem - dostatečným pro úřad - členství >> >> v vpsfree, >> >> tak je asi všechno v poho. >> >> (http://www.privacy-regulation.eu/cs/28.htm >> >> <http://www.privacy-regulation.eu/cs/28.htm>) >> >> Pokud ne, tak je problém. >> >> >> >> Jinak teda >> >> >> >> > Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou ma >> >> >> >> zodpovednost, best practices v ohledu bezpecnosti davno sleduje. >> >> >> >> Co když to neví, nebo na to dlabe? :-) >> >> >> >> >> >> Pavel Snajdr wrote: >> >> >> >> Stejne jako oskenovat, co ti tam bezi a dostat se ti tam bez >> >> zvednuti my pohodlny zadele, obzvlast pokud jedes nejakou >> >> PHPkovinu a data, ktery by bylo potreba chranit, jsou primo >> >> v DB, kam ty PHP spagety vidi. >> >> >> >> A co ted s tim, vypneme to vsehno? ;) >> >> >> >> Chci tim rict, ze panikrit IMHO neni na miste a kdyz se nad >> >> tim clovek zamysli, zasifrovat vsechno taky neni reseni. >> >> >> >> Jinak ja jsem za GDPR rad, mam vymluvu, proc si sebou budu >> >> nosit klicenku s trhavinou na flashkach, mame vymluvu, proc >> >> plosne nasadit sifrovani, proc se nam nepujde dostat do >> >> racku neautorizovane, aniz by to neodmazlo klice a neshodilo vsehno >> >> chraneny (tj. abys nam fakt nechtel otevrit ten rack). >> >> >> >> Ne ze by GDPR neco resilo, ale dava van super vymluvu, jak >> >> muzem nase systemy postupne posouvat vic smerem plausible >> >> deniability, tj. soukromi je level jedna, level nuda, ale co >> >> nam to umozni je ochranit i adminy pred tim, aby vedeli, co >> >> clen bezi. >> >> >> >> Neumel jsem si bez GDPR predstavit, jak zvysovat zabezpeceni >> >> bez toho, aby to vypadalo, jako kdyz se chystame hostovat >> >> tunu detskyho porna a lokalni pobocku CIA. Jenom to nebude >> >> vsehno hned - a nektery levely zabezpeceni na sharovanym >> >> hardwaru ani nepujde udelat. >> >> >> >> Chci: >> >> >> >> - sifrovani v ZoL >> >> - aby clen mel moznost klic per dataset neulozit, ale zadat >> >> si ho sam pres bezpecny kanal (ssh/https api call) >> >> - monitoring otevreni racku co bez nahlaseni predem donuti >> >> masiny smazat klice z RAM >> >> >> >> Ale tohle je furt malo, pokud admini nemaji vedet, co clen >> >> bezi. Ani fullvirt ani se sifrovanou RAM na AMD nam >> >> nepomuze, takze resim, jak zahostovat single board desky pro cleny, >> >> kteri chteji mit moznost nejcitlivejsi data mit fakt soukrome. >> >> >> >> Ve finale: >> >> >> >> - budes mit moznost data na VPS sifrovat svymi hesly, ktera >> >> se u nas nebudou ukladat (prusvih je, ze my nemame jak >> >> dokazat, ze jsme to nikde neulozili) >> >> >> >> - pri neautorizovanym pristupu do racku se klice smaznou, to >> >> samy pri rebootu/resetu a je pak na tobe zvazit, jestli je >> >> OK data uz odemknout >> >> >> >> - budes mit moznost nejcitlivejsi data vysoupnout vedle po >> >> siti na svuj dedikovanej systemek kalibru ARM Cortex A53, do >> >> budoucna RISC-V >> >> >> >> Problem nastava, kdyz s adminkem pujde do datacentra nekdo >> >> sebedulezitejsi, nez GDRP byrokrat s kulometem u palice, pak >> >> admin nema moznost ani nejak kliknout smazani klicu, nebo >> >> aspon nejakej counter na webu ve smyslu kanarka, ktery bude >> >> pocitat pocet podobnych incidentu. >> >> >> >> Shared computing ma svoje limity, bohuzel, jestli sledujes, >> >> kam tim mirim. >> >> >> >> GDPR podle mne vyzaduje nutne jenom nejaky papirovani, ale >> >> do budoucna nam dava zaminku jit na to vic z husta, co se soukromi >> >> tyce. >> >> >> >> Muze nam pak nekdo nadavat, ze delame hosting detskyho porna >> >> a teroristum, kdyz mame racky obehnany pomalu ziletkovym >> >> dratem? Nemuze, at si stezuje v Bruselu. >> >> >> >> Za mne dobry, ale nebude to hned. A v prvni vlne bude hlavne >> >> to papirovani. V druhy vlne se musime zbavit nedostacujiciho >> >> OpenVZ, vpsAdminOS ma podstatne lip ovladatelnejsi >> >> bezpecnostni politiku - a je odspoda nahoru cely podepsany a >> >> verifikovatelny. >> >> >> >> /snajpa >> >> >> >> On 30 Jan 2018, at 23:41, Jaroslav Skrivan >> >> <skrivy(a)skrivy.net <mailto:skrivy@skrivy.net>> wrote: >> >> >> >> Jenom moje osobni zkusenost - odnest si cizi disky z >> >> datacentra neni zas takovy problem, jak se na prvni >> >> pohled muze zdat. >> >> From: Pavel Snajdr >> >> Sent: ‎1/‎30/‎2018 10:49 PM >> >> To: vpsFree.cz Community list >> >> Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a >> >> GDPR >> >> >> >> Ahoj, >> >> >> >> GDPR je, pokud to dobre chapu, totalni nesmysl, z >> >> kteryho jsou vsichni vyjukani uplne, ale naprosto totalne zbytecne. >> >> >> >> Podivej se, co bezime za procesory. >> >> >> >> Jak ma nekdo neco v takovym stavu vubec industry-wide za >> >> neco rucit? >> >> >> >> Za mne je GDPR o tom a pouze o tom, ze musime podepsat >> >> papir s lidmi, co maji admin pristupy, aby acknuli >> >> oficialne svoji zodpovednost. >> >> >> >> V seznamu clenu uz ted mame jenom nejnutnejsi udaje >> >> (podle posledni zkusenosti s PCR a PSR jim k >> >> identifikaci ani to nemusi stacit...). >> >> >> >> Ve stanovach mame zakotvenou ochranu dat clenu uz od >> >> zacatku. >> >> >> >> Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, >> >> jakou ma zodpovednost, best practices v ohledu >> >> bezpecnosti davno sleduje. >> >> >> >> A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to >> >> vyresi, tak se rovnou zeptam - a borci, jak se k tomu >> >> asi programy na ty masine dostanou? Hint: stejne musi byt data >> >> odemcena pri behu. A ze se k nim neco dostane za behu je mnoooohem >> >> pravdepodobnejsi, nez ze nam z hlidanyho datacentra nekdo ukradne >> >> disky a vycte si neco offline. >> >> >> >> Tedy, muj nazor je, ze vubec neni potreba panikarit a >> >> natoz se uchylovat k reseni stylem ‘radsi to na vpsFree >> >> nedam vubec’. To ty servery muzeme rovnou vypnout totiz >> >> - a cely to zabalit s tim, ze jsme se nechali prevalcovat >> >> byrokratama. >> >> >> >> /snajpa >> >> (Pavel Snajdr) >> >> (Predseda vpsFree.cz) >> >> (+420 720 107 791 <tel:+420%20720%20107%20791>) >> >> >> >> On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN >> >> <lukas(a)aiken.cz <mailto:lukas@aiken.cz>> wrote: >> >> >> >> Ahoj, >> >> >> >> pokud si vzpomínám, tak něco podobného už se řešilo >> >> na valné hromadě >> >> (byť ještě nebylo nařízení GDPR). A situace je v >> >> podstatě taková, že to >> >> asi příliš řešit nelze, protože by to pro spolek >> >> znamenalo velkou >> >> administrativní zátěž a značný nárůst nákladů. >> >> >> >> Čili asi nejčistším řešením v tuto chvíli je, >> >> nevyužívat servery >> >> vpsFree.cz k ukládání osobních údajů - přinejmenším >> >> do doby, než se >> >> všechny záležitosti vyřeší (a než vůbec vznikne >> >> nějaký závazný výklad >> >> různých ustanovení směrnice). >> >> >> >> Lukáš Jelínek >> >> >> >> >> >> >> >> Ahoj ve spolek! >> >> >> >> Datum 25.5.2018, kdy nám vstupuje v účinnost >> >> GDPR se pomalu ale jistě >> >> blíží. Bohužel jsem byl, ač neprávník do této >> >> problematiky trochu >> >> zatlačen a byly na mě již vzneseny dotazy >> >> týkající se GDPR a vpsFree. >> >> >> >> Myslím, si, že je nás více, kteří na VPS máme >> >> uloženy nějaké ty osobní >> >> údaje (adresy, emaily, apod.) a skoro všichni >> >> máme nějaký ten >> >> webserver, kde se logují IP adresy, které jsou >> >> rovněž považovány za >> >> osobní údaje. Díky tomu jsme z pohledu GDPR >> >> považování za správce >> >> osobních údajů. Podle článku 4 GDPR se >> >> zpracovaním osobních údajů >> >> rozumí také ukládání osobních údajů. Z toho >> >> plyne, že jakýkoliv >> >> poskytovatel cloudových služeb, hostingu, VPS, >> >> atd. je vůči správci v >> >> postavení zpracovatele osobních údajů. Článek 28 >> >> GDPR potom řeší vztah >> >> zpracovatele a správce, kde mj. požaduje nějaký >> >> smluvní vztah mezi >> >> nimi. Když to převedu na protředí vpsFree tak >> >> členové jsou v podstatě >> >> správci osobních údajů a vpsFree je >> >> zpracovatelem osobních údajů. >> >> >> >> Můj dotaz zní, zda a jak bylo nebo bude GDPR >> >> řešeno na úrovní vpsFree? >> >> V podstatě asi jde o to, aby bylo v případě >> >> kontroly z UOOÚ možno >> >> něčím nebo nějak prokázat, že vpsFree je v >> >> souladu s GDPR a taky >> >> garantuje, že data nebudou uložena mimo EU. >> >> Věřím, že v našich řadách >> >> jsou kompetentnější členové v této věci jako já >> >> a tak bých rád otevřel >> >> diskusi. >> >> >> >> Honza. >> >> > _______________________________________________ > Community-list mailing list > 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

7 years, 3 months

2
1
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Lukáš Jelínek - AIKEN

Může být. Z hlediska "správců osobních údajů" je v první řadě důležité, aby měli vše v pořádku papírově. Pak kdyby se tohle opravdu stalo, tak jsou krytí. > Jenom moje osobni zkusenost - odnest si cizi disky z datacentra neni > zas takovy problem, jak se na prvni pohled muze zdat. > ------------------------------------------------------------------------ > From: Pavel Snajdr <mailto:snajpa@snajpa.net> > Sent: ‎1/‎30/‎2018 10:49 PM > To: vpsFree.cz Community list <mailto:community-list@lists.vpsfree.cz> > Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR > > Ahoj, > > GDPR je, pokud to dobre chapu, totalni nesmysl, z kteryho jsou vsichni > vyjukani uplne, ale naprosto totalne zbytecne. > > Podivej se, co bezime za procesory. > > Jak ma nekdo neco v takovym stavu vubec industry-wide za neco rucit? > > Za mne je GDPR o tom a pouze o tom, ze musime podepsat papir s lidmi, > co maji admin pristupy, aby acknuli oficialne svoji zodpovednost. > > V seznamu clenu uz ted mame jenom nejnutnejsi udaje (podle posledni > zkusenosti s PCR a PSR jim k identifikaci ani to nemusi stacit...). > > Ve stanovach mame zakotvenou ochranu dat clenu uz od zacatku. > > Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou ma > zodpovednost, best practices v ohledu bezpecnosti davno sleduje. > > A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to vyresi, tak se > rovnou zeptam - a borci, jak se k tomu asi programy na ty masine > dostanou? Hint: stejne musi byt data odemcena pri behu. A ze se k nim > neco dostane za behu je mnoooohem pravdepodobnejsi, nez ze nam z > hlidanyho datacentra nekdo ukradne disky a vycte si neco offline. > > Tedy, muj nazor je, ze vubec neni potreba panikarit a natoz se > uchylovat k reseni stylem ‘radsi to na vpsFree nedam vubec’. To ty > servery muzeme rovnou vypnout totiz - a cely to zabalit s tim, ze jsme > se nechali prevalcovat byrokratama. > > /snajpa > (Pavel Snajdr) > (Predseda vpsFree.cz) > (+420 720 107 791) > > > On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN <lukas(a)aiken.cz> wrote: > > > > Ahoj, > > > > pokud si vzpomínám, tak něco podobného už se řešilo na valné hromadě > > (byť ještě nebylo nařízení GDPR). A situace je v podstatě taková, že to > > asi příliš řešit nelze, protože by to pro spolek znamenalo velkou > > administrativní zátěž a značný nárůst nákladů. > > > > Čili asi nejčistším řešením v tuto chvíli je, nevyužívat servery > > vpsFree.cz k ukládání osobních údajů - přinejmenším do doby, než se > > všechny záležitosti vyřeší (a než vůbec vznikne nějaký závazný výklad > > různých ustanovení směrnice). > > > > Lukáš Jelínek > > > > > > > >> Ahoj ve spolek! > >> > >> Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě > >> blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu > >> zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree. > >> > >> Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní > >> údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten > >> webserver, kde se logují IP adresy, které jsou rovněž považovány za > >> osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce > >> osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů > >> rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv > >> poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v > >> postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah > >> zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi > >> nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě > >> správci osobních údajů a vpsFree je zpracovatelem osobních údajů. > >> > >> Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree? > >> V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno > >> něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky > >> garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách > >> jsou kompetentnější členové v této věci jako já a tak bých rád otevřel > >> diskusi. > >> > >> Honza. > >> > > > > _______________________________________________ > > Community-list mailing list > > 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 > > > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

5
4
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Pavel Snajdr

Stejne jako oskenovat, co ti tam bezi a dostat se ti tam bez zvednuti my pohodlny zadele, obzvlast pokud jedes nejakou PHPkovinu a data, ktery by bylo potreba chranit, jsou primo v DB, kam ty PHP spagety vidi. A co ted s tim, vypneme to vsehno? ;) Chci tim rict, ze panikrit IMHO neni na miste a kdyz se nad tim clovek zamysli, zasifrovat vsechno taky neni reseni. Jinak ja jsem za GDPR rad, mam vymluvu, proc si sebou budu nosit klicenku s trhavinou na flashkach, mame vymluvu, proc plosne nasadit sifrovani, proc se nam nepujde dostat do racku neautorizovane, aniz by to neodmazlo klice a neshodilo vsehno chraneny (tj. abys nam fakt nechtel otevrit ten rack). Ne ze by GDPR neco resilo, ale dava van super vymluvu, jak muzem nase systemy postupne posouvat vic smerem plausible deniability, tj. soukromi je level jedna, level nuda, ale co nam to umozni je ochranit i adminy pred tim, aby vedeli, co clen bezi. Neumel jsem si bez GDPR predstavit, jak zvysovat zabezpeceni bez toho, aby to vypadalo, jako kdyz se chystame hostovat tunu detskyho porna a lokalni pobocku CIA. Jenom to nebude vsehno hned - a nektery levely zabezpeceni na sharovanym hardwaru ani nepujde udelat. Chci: - sifrovani v ZoL - aby clen mel moznost klic per dataset neulozit, ale zadat si ho sam pres bezpecny kanal (ssh/https api call) - monitoring otevreni racku co bez nahlaseni predem donuti masiny smazat klice z RAM Ale tohle je furt malo, pokud admini nemaji vedet, co clen bezi. Ani fullvirt ani se sifrovanou RAM na AMD nam nepomuze, takze resim, jak zahostovat single board desky pro cleny, kteri chteji mit moznost nejcitlivejsi data mit fakt soukrome. Ve finale: - budes mit moznost data na VPS sifrovat svymi hesly, ktera se u nas nebudou ukladat (prusvih je, ze my nemame jak dokazat, ze jsme to nikde neulozili) - pri neautorizovanym pristupu do racku se klice smaznou, to samy pri rebootu/resetu a je pak na tobe zvazit, jestli je OK data uz odemknout - budes mit moznost nejcitlivejsi data vysoupnout vedle po siti na svuj dedikovanej systemek kalibru ARM Cortex A53, do budoucna RISC-V Problem nastava, kdyz s adminkem pujde do datacentra nekdo sebedulezitejsi, nez GDRP byrokrat s kulometem u palice, pak admin nema moznost ani nejak kliknout smazani klicu, nebo aspon nejakej counter na webu ve smyslu kanarka, ktery bude pocitat pocet podobnych incidentu. Shared computing ma svoje limity, bohuzel, jestli sledujes, kam tim mirim. GDPR podle mne vyzaduje nutne jenom nejaky papirovani, ale do budoucna nam dava zaminku jit na to vic z husta, co se soukromi tyce. Muze nam pak nekdo nadavat, ze delame hosting detskyho porna a teroristum, kdyz mame racky obehnany pomalu ziletkovym dratem? Nemuze, at si stezuje v Bruselu. Za mne dobry, ale nebude to hned. A v prvni vlne bude hlavne to papirovani. V druhy vlne se musime zbavit nedostacujiciho OpenVZ, vpsAdminOS ma podstatne lip ovladatelnejsi bezpecnostni politiku - a je odspoda nahoru cely podepsany a verifikovatelny. /snajpa > On 30 Jan 2018, at 23:41, Jaroslav Skrivan <skrivy(a)skrivy.net> wrote: > > Jenom moje osobni zkusenost - odnest si cizi disky z datacentra neni zas takovy problem, jak se na prvni pohled muze zdat. > From: Pavel Snajdr > Sent: ‎1/‎30/‎2018 10:49 PM > To: vpsFree.cz Community list > Subject: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR > > Ahoj, > > GDPR je, pokud to dobre chapu, totalni nesmysl, z kteryho jsou vsichni vyjukani uplne, ale naprosto totalne zbytecne. > > Podivej se, co bezime za procesory. > > Jak ma nekdo neco v takovym stavu vubec industry-wide za neco rucit? > > Za mne je GDPR o tom a pouze o tom, ze musime podepsat papir s lidmi, co maji admin pristupy, aby acknuli oficialne svoji zodpovednost. > > V seznamu clenu uz ted mame jenom nejnutnejsi udaje (podle posledni zkusenosti s PCR a PSR jim k identifikaci ani to nemusi stacit...). > > Ve stanovach mame zakotvenou ochranu dat clenu uz od zacatku. > > Ja v tom vidim mnoho povyku pro nic, ajtak, ktery vi, jakou ma zodpovednost, best practices v ohledu bezpecnosti davno sleduje. > > A kdyz si nekdo mysli, ze Vsechno Zasifrovat(tm) to vyresi, tak se rovnou zeptam - a borci, jak se k tomu asi programy na ty masine dostanou? Hint: stejne musi byt data odemcena pri behu. A ze se k nim neco dostane za behu je mnoooohem pravdepodobnejsi, nez ze nam z hlidanyho datacentra nekdo ukradne disky a vycte si neco offline. > > Tedy, muj nazor je, ze vubec neni potreba panikarit a natoz se uchylovat k reseni stylem ‘radsi to na vpsFree nedam vubec’. To ty servery muzeme rovnou vypnout totiz - a cely to zabalit s tim, ze jsme se nechali prevalcovat byrokratama. > > /snajpa > (Pavel Snajdr) > (Predseda vpsFree.cz) > (+420 720 107 791) > > > On 30 Jan 2018, at 22:10, Lukáš Jelínek - AIKEN <lukas(a)aiken.cz> wrote: > > > > Ahoj, > > > > pokud si vzpomínám, tak něco podobného už se řešilo na valné hromadě > > (byť ještě nebylo nařízení GDPR). A situace je v podstatě taková, že to > > asi příliš řešit nelze, protože by to pro spolek znamenalo velkou > > administrativní zátěž a značný nárůst nákladů. > > > > Čili asi nejčistším řešením v tuto chvíli je, nevyužívat servery > > vpsFree.cz k ukládání osobních údajů - přinejmenším do doby, než se > > všechny záležitosti vyřeší (a než vůbec vznikne nějaký závazný výklad > > různých ustanovení směrnice). > > > > Lukáš Jelínek > > > > > > > >> Ahoj ve spolek! > >> > >> Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě > >> blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu > >> zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree. > >> > >> Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní > >> údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten > >> webserver, kde se logují IP adresy, které jsou rovněž považovány za > >> osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce > >> osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů > >> rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv > >> poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v > >> postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah > >> zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi > >> nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě > >> správci osobních údajů a vpsFree je zpracovatelem osobních údajů. > >> > >> Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree? > >> V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno > >> něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky > >> garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách > >> jsou kompetentnější členové v této věci jako já a tak bých rád otevřel > >> diskusi. > >> > >> Honza. > >> > > > > _______________________________________________ > > Community-list mailing list > > 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 > _______________________________________________ > Community-list mailing list > Community-list(a)lists.vpsfree.cz > http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

3
2
0 0

vpsFree.cz a GDPR

by Ing. Jan Dvořák

Ahoj ve spolek! Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree. Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten webserver, kde se logují IP adresy, které jsou rovněž považovány za osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě správci osobních údajů a vpsFree je zpracovatelem osobních údajů. Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree? V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách jsou kompetentnější členové v této věci jako já a tak bých rád otevřel diskusi. Honza. -- Ing. Jan Dvorak **************************************** Ing. Jan Dvorak Fischerova 690/23 779 00 Olomouc, Nove Sady Czech Republic **************************************** Tel: +420 603 444 240 E-mail: jan.dvorak(a)dvorak-sw.com Web: http://www.dvorak-sw.com ****************************************

7 years, 3 months

4
6
0 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR

by Petr Juhaňák

Ahoj, podle mojí interpretace vpsFree poskytuje pouze technické prostředky nad kterými členové teprve zpracovavaji (ukládají) osobní udaje. Tj. kdyby došlo na lámání chleba, tak člen (správce dat) nemůže prokázat v jakém rozsahu vlastně písemné někoho pověřil (vpsFree), aby mu pomáhal data zpracovávat bez ohledu na to, komu patří železo a kdo spravuje OS. Bezpečnost zajišťuje spravce dat. Situace by se zkomplikovala jen v případě, pokud by technické prostředky nebyly bezpečné a uživateli by se mazal med kolem huby, ale to je extrem. S pozdravemPetr Juhaňák petr(a)juhanak.cz | +420 739 639 132 -------- Původní zpráva -------- Od: Lukáš Jelínek - AIKEN <lukas(a)aiken.cz> Datum: 30.01.18 22:10 (GMT+01:00) Komu: "community-list(a)lists.vpsfree.cz >> community-list" <community-list(a)lists.vpsfree.cz> Předmět: Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR Ahoj, pokud si vzpomínám, tak něco podobného už se řešilo na valné hromadě (byť ještě nebylo nařízení GDPR). A situace je v podstatě taková, že to asi příliš řešit nelze, protože by to pro spolek znamenalo velkou administrativní zátěž a značný nárůst nákladů. Čili asi nejčistším řešením v tuto chvíli je, nevyužívat servery vpsFree.cz k ukládání osobních údajů - přinejmenším do doby, než se všechny záležitosti vyřeší (a než vůbec vznikne nějaký závazný výklad různých ustanovení směrnice). Lukáš Jelínek > Ahoj ve spolek! > > Datum 25.5.2018, kdy nám vstupuje v účinnost GDPR se pomalu ale jistě > blíží. Bohužel jsem byl, ač neprávník do této problematiky trochu > zatlačen a byly na mě již vzneseny dotazy týkající se GDPR a vpsFree. > > Myslím, si, že je nás více, kteří na VPS máme uloženy nějaké ty osobní > údaje (adresy, emaily, apod.) a skoro všichni máme nějaký ten > webserver, kde se logují IP adresy, které jsou rovněž považovány za > osobní údaje. Díky tomu jsme z pohledu GDPR považování za správce > osobních údajů. Podle článku 4 GDPR se zpracovaním osobních údajů > rozumí také ukládání osobních údajů. Z toho plyne, že jakýkoliv > poskytovatel cloudových služeb, hostingu, VPS, atd. je vůči správci v > postavení zpracovatele osobních údajů. Článek 28 GDPR potom řeší vztah > zpracovatele a správce, kde mj. požaduje nějaký smluvní vztah mezi > nimi. Když to převedu na protředí vpsFree tak členové jsou v podstatě > správci osobních údajů a vpsFree je zpracovatelem osobních údajů. > > Můj dotaz zní, zda a jak bylo nebo bude GDPR řešeno na úrovní vpsFree? > V podstatě asi jde o to, aby bylo v případě kontroly z UOOÚ možno > něčím nebo nějak prokázat, že vpsFree je v souladu s GDPR a taky > garantuje, že data nebudou uložena mimo EU. Věřím, že v našich řadách > jsou kompetentnější členové v této věci jako já a tak bých rád otevřel > diskusi. > > Honza. > _______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

7 years, 3 months

1
0
0 0

Padajici guest v KVM

by Jindrich Skacel

Ahoj, nesetkal se nekdo z vas s padajicim guestem v KVM? Jedine, co vzdy najdu v logu je: qemu-system-x86_64: Virtqueue size exceeded nebo qemu-system-x86_64: virtio: bogus descriptor or out of resources Bohuzel jsem stale neprisel, cim by to mohlo byt. Host system jsem upgradoval z Alpine 3.5 na Alpine 3.7 s tim, ze to byl nejaky bug, ale nevypada to. Guest system je Debian 8. CPU v guestu vytizene vubec neni a memory taky vypada OK az do "zaseknuti" stroje. // J

7 years, 3 months

2
1
0 0

vytvoreni debian init scriptu

by Jakub Podlaha

Zdravim, rad bych se zeptal, jak vytvorim na Debianu init script pro appku (vetsinou node.js) a nastavim ho aby se spoustel pri startu systemu. Aktualne pouzivam detasovany screen a v nem shell pro kazdou appku, ale nechce se mi vse manualne spoustet po kazdem "Neplanovanem vypdadku". Uz jsem stravil nekolik hodin snahou dohledat, jak to v Debianu chodi. Zkusil jsem treba tenhle script: https://gist.github.com/peterhost/715255 (a nekolik dalsich) upravit a dat do /etc/init.d/my-simple. Dostavam chyby: $ service my-simple start Failed to start my-simple.service: Unit my-simple.service failed to load: No such file or directory. $ update-rc.d "my-simple" enable update-rc.d: error: no runlevel symlinks to modify, aborting! Myslel jsem, ze .service soubory patri pod systemd a ze Debian pouziva init scripty a ze service je tool na spravu init scriptu podobne jako v Gentoo je treba rc-update. Chyby jsem zkousel googlit, ale nasel jsem jen problemy se spatne nainstalovanymi aplikacemi. Jestli me muzete nakopnout, nebo poradit, budu rad. Zdar, Jakub

7 years, 3 months

6
8
0 0

php7-fpm + shell_exec

by Jozef Sroka

Nazdar, mam server s nginix + php7-fpm + ispconfig vsymol som si jednu nebezpecnu vec, ked zavola v php funkciu shell_exec a vykonam prikaz napriklad cat, tak viem citat subory aj inych webov napriklad viem precitat subor -rw-r--r-- 1 web2 client1 /var/www/clients/client1/web2/web/index.php z pricinku drwxr-x--x 8 web2 client1 /var/www/clients/client1/web2/web pricom php skritp je spusteny ako web1:client0 chcel by som zvysit bezpecnost na servery, a zamedzit moznost citat takto data z inych webov potreboval by som poradit nejaky dobry sposob, - som otvoreny aj inemu control panelu ako ispconfig, ale musi obsohovat podobnu funkcionalitu - nechcem zakazat shell_exec v php potrebujem ho - rozmyslal som na chroot alebo kontajnermy ale potrebujem trocha poradit

7 years, 4 months

3
2
0 0

Konfiguracia mailoveho servera

by Oto Peťura

Zdravim, mam na VPS nakonfigurovany postfix, dovecot a spamassasin. Spam je spravne detekovany ale chcel by som, aby sa hadzal do osobitneho adresara (SPAM alebo Junk...). Nemam velke skusenosti s mailovymi servermi. Toto je moj osobny mail kde sa snazim naucit co ako funguje. Skusal som hladat navody na internete a nieco som aj skusal ale maily mi potom nechodili vobec alebo chodili s velmi velkym oneskorenim a neviem preco. Mohol by ma niekto nasmerovat? Chcel by som v prvom rade pochopit ako veci funguju, lenze co som videl boli vsetko iba navody krok za krokom bez vysvetlenia principu. Potom sa tazko hlada chyba ked neviem ani co robim. Vdaka za akukolvek pomoc. Oto

7 years, 4 months

2
2
0 0

Přihlas přednášku na InstallFest

by Petr Krcmar

Hezký leden všem, pojďte s námi přednášet na InstallFest! Hledáme (spolu)přednášející, kteří by udělali nějaká témata pro začátečníky: best practices, jak začít s Linuxem, nějaké služby, klidně i hardware, vývoj, co vás napadne. Nebojte se do toho a pojďte s námi udělat super konferenci. https://installfest.cz/if18/ -- Petr Krčmář vpsFree.cz

7 years, 4 months

1
0
0 0

Meltdown + Spectre

by Pavel Snajdr

EN-TLDR: I have a patch for Meltdown ready. Do we deploy now or wait until after midnight? Mam naportovany patch z RHEL6 na nase OpenVZ jadro. Taky overenou funkcnost na trech serverech (jeden z toho je node1.pgnd, dva testovaci). Jdeme to aplikovat hned? Prezijete vypadek? /snajpa

7 years, 4 months

9
15
0 0

Přednášky na InstallFest

by Petr Krcmar

Ahoj, o víkendu 3. a 4. března proběhne desátý ročník obnovené konference InstallFest [1]. Máme se Snajpou přihlášené přednášky, opět tam budeme mít stánek s kávou a rádi vás tam potkáme. Píšu ale hlavně proto, že ještě běží přihlašování přednášek a bylo by fajn, kdyby se nám tam sešlo víc zajímavých témat – pomůže to vpsFree, ale hlavně konferenci jako takové, aby bylo co poslouchat. Pokud máte nějaký nápad, určitě ho přihlaste. Nebojte se toho, kdybyste potřebovali pomoct s obsahem přednášky, abstraktem nebo třeba přípravou osnovy, jsem vám k dispozici. [1]: https://installfest.cz/if18/ -- Petr Krčmář vpsFree.cz

7 years, 4 months

1
0
0 0

Je mozne automaticky lxc-console po tom co host nabootuje? Jak na to?

by Wolf

Ahoj, hraju si doma z lxc trochu, a napadlo mne, ze by se mi docela libilo mit moznost udelat dosahnout nasledujici sequence: 1) host nabootuje 2) auto-startne lxc container (let's call it `gui` from now on) 3) switchne na tty2 4) spusti lxc-console na `gui` takze se mi zobrazi jeho login prompt V podstate tedy chci replacenout login prompt hostu login promptem z containeru. Je neco takoveho rozumne mozne udelat? Host je up-to-date archlinux pokud je to relevantni. Snad to neni moc off-topic :) Diky za pomoc, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

7 years, 4 months

1
0
0 0

OT: Frontendista - Javascriptový vývojář (Angular, React)

by Lubor Kemza

Ahoj milí kolegové, do svého týmu sháním vývojáře frontendu - javascriptistu (Angular, React...). Zajímavé projekty, interní vývoj. Zevrubnější popis: https://www.rostemespolecne.cz/pozice/javascript-developer Kanceláře jsou v Praze, ubytování a auto případně zařídíme. Pokud by někdo z vás měl zájem, nebo mohl někoho doporučit, tak mi prosím dejte vědět. ;-) Omlouvám se za off topic. Lubor Kemza Analytik kemza(a)vshosting.cz +420 799 799 818

7 years, 4 months

10
13
0 0

Budoucnost OpenVZ

by Pavel Bařina

Ahoj, s kolegou řešíme jakou cestou virtualizace se ve firmě vydat. Jelikož jsou zde odborníci na OpenVZ rád bych se poradil. Já mám zkušenosti s KVM z jiné firmy a kolega zatím zkoušel OpenVZ na CentOS release 6.7. Vyšlo nové OpenVZ a jak jsem zahlídl i zde s pár poznámek budoucnost OpenVZ může být nejistá. Jakou cestou kontejneru byste se vydali vy? Nové OpenVZ, LXC nebo docker? Zároveň bychom chtěli na stejném stroji provozovat i KVM (pro chod Windows). Momentálně máme na stroji obojí. OpenVZ i KVM. Nicméně je problém se spouštěním virtuálního stroje v KVM, po druhém pokusu o spuštění virtuálního stroje již naběhne. Chyba při startu domény: Nelze vytvořit cgroup pro Debian-wheeze: Adresář nebo soubor neexistuje Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1355, in startup self._backend.create() File "/usr/lib/python2.7/dist-packages/libvirt.py", line 999, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: Nelze vytvořit cgroup pro Debian-wheeze: Adresář nebo soubor neexistuje KVM není spuštěno v kontejnerech jako u VPS ale samostatně vedle OpenVZ Děkuji moc za postřehy a nakopnutí správným směrem Pavel

7 years, 4 months

19
30
0 0

vpsfree - překvapivě nízký CPU výkon

by Věroš Kaplan

Ahoj, potřeboval jsem včera v noci zkomprimovat jeden 4GB .tar soubor pomocí `bzip2 -9`. Mám na stole docela pomalý stroj s Celeronem, a odhadovaná doba komprimace byla 20 minut. Soubor jsem tedy poslal na vpsfree a nechal jsem ho zkomprimovat tam. Oproti očekávání je komprimace na vpsfree pomalejší. Pokud by servery nebyly využité, tak by ten Xeon na vpsfree měl zhruba být o třetinu rychlejší. Ta samá komprimace se mi provedla dvakrát rychleji na tom Celeronu, a fakt by mne zajímalo proč. Je na vpsfree okolo půlnoci nějaká větší zátěž? Otázka: Je něco, co nevidím a Celeron G1610T může být o tolik rychlejší než Xeon na vpsfree? Domácí Celeron: Celeron G1610T @ 2.30 , na tom běží KVM a v něm emulovaný Intel i7 VPSfree: konfiguraci nevím, v kontejneru se tváří: Xeon E5-2630 @ 2.30 Věroš -- Věroš Kaplan http://navolnenoze.cz/prezentace/veroslav-kaplan/

7 years, 4 months

5
7
0 0

Chybejici logy na Debian 9 se systemd a syslog-ng

by Tomáš Jelínek

Ahoj, upgradoval jsem VPS z Debianu 8 na Debian 9 a po restartu jsem zjistil, ze se mi prestalo logovat do nasledujicich souboru ve /var/log: auth.log cron.log daemon.log kern.log mail.log messages syslog Kdyz spustim 'journalctl', tak tam vsechny zpravy, ktere se puvodne logovaly do tech souboru, vidim. Vypada to, ze logy se dostavaji do systemd, ale uz ne do syslogu. Ja ale potrebuju logovat do tech souboru, abych je mohl parsovat (munin, awstats, atd.). Prosel jsem vsechny configy syslog-ng, ktere jsem nasel, a nemam tam zadne zmeny oproti tomu, co je v balicich. Google mi nepomohl, zkusil jsem navod https://wiki.archlinux.org/index.php/syslog-ng#syslog-ng_and_systemd_journal a to postupne obe dve varianty, ale nepozoroval jsem zadnou zmenu. Ve /var/log/syslog vidim toto: WARNING: Default value changed for the prefix() option of systemd-journal source in syslog-ng 3.8; old_value='', new_value='.journald.' ale k nicemu me to nedovedlo. Jedina vec, co se mi loguje, jsou zpravy o nastartovani a ukonceni syslog-ng ve /var/log/syslog a /var/log/messages: Dec 20 18:48:12 vps syslog-ng[8169]: syslog-ng shutting down; version='3.8.1' Dec 20 18:48:40 vps syslog-ng[8204]: syslog-ng starting up; version='3.8.1' Prosim poradte. Diky, Tomas

7 years, 5 months

8
9
0 0

KVM na Alpine - práva na /dev/kvm

by David

Ahoj, snažím se rozjet KVM na Alpine linuxu - vždycky po rebootu mi ale zmizí skupina z alpine:~# ll /dev/kvm 201775056 crw------- 1 root root 10, 232 Nov 25 23:14 /dev/kvm alpine:~# ll /dev/net/tun 201775055 crw------- 1 root root 10, 200 Nov 25 23:14 /dev/net/tun Vždycky nastavím pomocí: chown :kvm /dev/kvm chmod g+rw /dev/kvm chown :netdev /dev/net/tun chmod g+rw /dev/net/tun Ale po rebootu to je skupina zase špatně. Netušíte někdo čím by to mohlo být? Postupuji podle návodu ze znalostní báze. Máte někdo podobný problém? Jakub Skokan mi poradil zeptat se tady: Ja jsem se to pred casem pokousel vyresit, ale neuspesne. Ty prava by mel nastavovat mdev, v konfiguraci v /etc/mdev.conf to nastavene je, takze netusim kde to vazne. V nejhorsim si muzes udelat vlastni init skript, ve kterem ty prava nastavis jak potrebujes, ale lepsi by bylo zjistit, proc se to deje, no :) Předem díky za reakce, David

7 years, 5 months

2
2
0 0

Arch Linux a problem s glibc >=2.26

by Jakub Skokan

Ahojte, dejte si pozor na aktualizaci Arch Linuxu, s glibc >= 2.26 vam VPS nenajede. Vypada to, ze glibc od 2.26 podporuje jen kernel 3.2+ [1], takze to u nas uz nemusi fungovat spravne. Zatim jsme narazili jen na problem se systemd, ktery je teda celkem zasadni, protoze nestartujou zadne sluzby, napr.: systemd-journald.service: Main process exited, code=exited, status=205/LIMITS Jedina cesta zda se bude zustat u glibc 2.25. Sablonu archu jsem upravil, nicmene existujici VPS si musite pohlidat sami -- pridat glibc do IgnorePkg v /etc/pacman.conf. Casem to zrejme bude problem i v jinych distribucich, kdyz tam ta glibc 2.26 probubla, ale to uz snad stihnem prejit na novejsi kernel + LXC. [1] https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html Jakub

7 years, 5 months

2
2
0 0

test

by Tomas Srnka

Test po upgrade mailmana, pekny vikend! :)

7 years, 5 months

1
0
0 0

CentOS 6 - yum update error

by Honza KAŠPÁREK

Ahoj, uz nejakou dobu se mi casto pri spusteni prikazu objevuji chyby: epel-source/metalink base https://ftp.sh.cvut.cz/6/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" a obdobne pro epel/primary-db a epel-httpd24. Vetsinou pomuze provest yum clean all, ale po case se to zase vrati. Ta adresa, odkud zkousi stahovat balicky opravdu neexistuje, daji se tam dohledat, ale pod jinou strukturou. Zrejme je ale nekde stale ulozena ta stara cesta a nemuzu se ji zbavit. Poradite, prosim? Diky. Honza

7 years, 5 months

2
1
0 0

nastavenie datumu a casu

by kypo

Prosim o pre odbornikov trivialnu radu, som v Linuxe zelenac. Mam na vps Ubuntu 14.04 a na tom nainstalovany web na Wordpress. Problem je s casom, resp po posune casu sa to vzdy nejak rozdrbe a neviem to nejak vyriesit nadobro. Ak sa pripojim na server cez putty terminal a dam prikaz date, vypise mi datum a cas, ale ten je o hodinu pozadu. Samozrejme to potom robi bordel na webe pod Wordpressom. SKusal som ho cez terminal prenastavit prikazom sudo date --set="2017-11-15 17:25:59.990" ale nezafunguje, vyhodi ze nemam permissions. Takze mam dve otazky: 1. Ako prenastavit cas a datum na serveru? (kludne si ho po kazdom posune casu zmenim) 2. Alebo je pripadne nejake riesenie ktore by posun casu robilo automaticky bez nutnosti zasahu? Diky

7 years, 6 months

3
2
0 0

MariaDB nefunguje se systemd 233 v kontejneru

by Jiří Eischmann ml.

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

7 years, 6 months

6
8
0 0

Monitorovací software

by Jan B. Kolář

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

7 years, 6 months

8
9
0 0

Vagrant libvirt - malý prostor na hdd

by Petr Parolek

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

7 years, 6 months

3
13
0 0

Klonování virtuálu opravuje aplikace?

by Stanislav Vasko

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

7 years, 7 months

9
10
0 0

Re: [vpsFree.cz: community-list] Prosba - nefunkncni virt-manager

by René Langer

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>

7 years, 7 months

1
0
0 0

Prosba - nefunkncni virt-manager

by Richard Korinek

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

7 years, 7 months

2
1
0 0

Pomoc se stánkem Alpine Linuxu na LinuxDays

by Jakub Jirutka

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.

7 years, 7 months

3
2
0 0

Přivez staré knížky na LinuxDays

by Petr Krcmar

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

7 years, 7 months

2
1
0 0

GDPR - řešení reálných dopadů

by Jiří Pucherna

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

7 years, 7 months

6
8
0 0

Re: [vpsFree.cz: community-list] GDPR - zkusme to odspoda

by Petr Juhaňák

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

7 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list