- Community-list - lists.vpsfree.cz

Re: [vpsFree.cz: community-list] GDPR a uvedení do praxe
by Martin Myška 02 Mar '18

02 Mar '18

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

1 0

TPM chip
by Libor Boldan 02 Mar '18

02 Mar '18

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

1 0

GDPR a uvedení do praxe
by Martin Myška 01 Mar '18

01 Mar '18

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*

2 1

Posfix+dovecot+mysql problém s přijmem pošty
by Petr Parolek 01 Mar '18

01 Mar '18

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

2 1

Supermicro
by Libor Boldan 27 Feb '18

27 Feb '18

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

2 1

vpsFree mirror pro Debian
by Jan B. Kolář 25 Feb '18

25 Feb '18

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

3 5

Load average
by Caesar Consulting 23 Feb '18

23 Feb '18

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.

4 3

Pomoc na Linux Tage
by Petr Krcmar 21 Feb '18

21 Feb '18

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

1 0

Převoz věcí z Liberce na InstallFest
by Petr Krcmar 19 Feb '18

19 Feb '18

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

1 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 14 Feb '18

14 Feb '18

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

19 63

Nastavení firewalu
by slimbit 14 Feb '18

14 Feb '18

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?

2 2

Pozvánka na první Pyvo v Liberci 14. února
by Ondřej Caletka 12 Feb '18

12 Feb '18

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ář

1 0

Jak tunelovat přes SSH
by Jaroslav Týc 12 Feb '18

12 Feb '18

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!

5 4

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 02 Feb '18

02 Feb '18

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 7

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 02 Feb '18

02 Feb '18

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

1 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 02 Feb '18

02 Feb '18

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

3 2

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 01 Feb '18

01 Feb '18

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

1 0

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 01 Feb '18

01 Feb '18

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

2 1

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 01 Feb '18

01 Feb '18

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

2 1

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Lukáš Jelínek - AIKEN 31 Jan '18

31 Jan '18

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

5 4

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Pavel Snajdr 31 Jan '18

31 Jan '18

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

3 2

vpsFree.cz a GDPR
by Ing. Jan Dvořák 30 Jan '18

30 Jan '18

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

4 6

Re: [vpsFree.cz: community-list] vpsFree.cz a GDPR
by Petr Juhaňák 30 Jan '18

30 Jan '18

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

1 0

Padajici guest v KVM
by Jindrich Skacel 29 Jan '18

29 Jan '18

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

2 1

vytvoreni debian init scriptu
by Jakub Podlaha 25 Jan '18

25 Jan '18

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

6 8

php7-fpm + shell_exec
by Jozef Sroka 16 Jan '18

16 Jan '18

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

3 2

Konfiguracia mailoveho servera
by Oto Peťura 16 Jan '18

16 Jan '18

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

2 2

Přihlas přednášku na InstallFest
by Petr Krcmar 16 Jan '18

16 Jan '18

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

1 0

Meltdown + Spectre
by Pavel Snajdr 09 Jan '18

09 Jan '18

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

9 15

Přednášky na InstallFest
by Petr Krcmar 08 Jan '18

08 Jan '18

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

1 0

Je mozne automaticky lxc-console po tom co host nabootuje? Jak na to?
by Wolf 06 Jan '18

06 Jan '18

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.

1 0

OT: Frontendista - Javascriptový vývojář (Angular, React)
by Lubor Kemza 03 Jan '18

03 Jan '18

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

10 13

Budoucnost OpenVZ
by Pavel Bařina 03 Jan '18

03 Jan '18

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

19 30

vpsfree - překvapivě nízký CPU výkon
by Věroš Kaplan 31 Dec '17

31 Dec '17

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/

5 7

Chybejici logy na Debian 9 se systemd a syslog-ng
by Tomáš Jelínek 22 Dec '17

22 Dec '17

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

8 9

KVM na Alpine - práva na /dev/kvm
by David 22 Dec '17

22 Dec '17

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

2 2

Arch Linux a problem s glibc >=2.26
by Jakub Skokan 02 Dec '17

02 Dec '17

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

2 2

test
by Tomas Srnka 02 Dec '17

02 Dec '17

Test po upgrade mailmana, pekny vikend! :)

1 0

CentOS 6 - yum update error
by Honza KAŠPÁREK 24 Nov '17

24 Nov '17

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

2 1

nastavenie datumu a casu
by kypo 15 Nov '17

15 Nov '17

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

3 2

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

11 Nov '17

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

6 8

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

11 Nov '17

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

8 9

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

05 Nov '17

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

3 13

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

18 Oct '17

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

9 10

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

06 Oct '17

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

1 0

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

06 Oct '17

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

2 1

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

05 Oct '17

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

3 2

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

03 Oct '17

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

2 1

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

26 Sep '17

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

6 8

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

21 Sep '17

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

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list