Community-list

community-list@lists.vpsfree.cz

1077 discussions

vpsAdmin 2: popis důležitých změn
by Jakub Skokan 03 Aug '15

03 Aug '15

Ahoj, v tomto mailu popisuji důležité změny v nové verzi vpsAdminu pro koncové uživatele. Je to trochu delší text, ale doporučuji to aspoň proletět. Návody na používání nových funkcí budou během několika dní k dispozici v KB. Doporučuji se na ně před použitím funkce podívat a v případě nejasnosti se raději zeptat. Nové funkce zatím nedoporučuji využívat na produkční nasazení. Počkejte prosím pár týdnů, než se to vyladí. Jsou to tisíce řádek nového kódu a není reálné očekávat na 100 % vyladěnou věc. Nalezené chyby prosím hlaste na podporu. Prostředí --------- Všechny nody jsou rozděleny do "prostředí" (environment). V našem případě jsou zavedeny prostředí produkce, playground a storage praha. Každý člen má v rámci prostředí přiděleny prostředky (paměť, CPU, diskový prostor a IP adresy), které na nodech spadajících do daného prostředí můžou využívat. Prostředí můžou mít různé nastavení - dovolené počty VPS, apod. Přehled přidělených prostředků v prostředích je vidět v Edit profile -> Cluster resources. Nastavení prostředí v Edit profile -> Environment configs. VPS - vytváření ---------------- Členům je dovoleno vytvářet VPS v playground i produkci a to za předpokladu, že má k dispozici dostatek prostředků a umožňuje to jeho nastavení prostředí. Vytvoření nové VPS se skládá ze tří kroků - výběr prostředí, výběr lokace a následně hostname, distribuce a parametry. Vytváření více produkčních VPS je zatím povoleno pouze uživatelům, kteří o to požádají a chtějí tuto funkci otestovat. VPS - IP adresy --------------- Člen má přidělenu 1 IPv4 adresu a 32 IPv6 adres v každém prostředí. Tyto adresy může libovolně rozdělit mezi VPS. Více IPv4 je stejně jako předtím za poplatek [1], IPv6 na dotaz. Při přidělení adresy k produkční VPS se adrese nastaví vlastník. Takovou IP adresu potom nemůže nikdo jiný vybrat, i když zrovna není používána. Člen musí nejdříve využít všechny vlastněné IP adresy a až poté lze vybrat adresy nové. VPS - heslo roota ----------------- Při nastavování hesla roota lze vybrat ze dvou typů generovaných hesel. Jednoduché heslo se snadněji opíše do webové konzole VPS, kde bohužel nefunguje copy&paste a opisovat dlouhé heslo je otrava. VPS - volba distribuce ---------------------- Formulář pro reinstalaci distribuce nyní umožnuje pouhou aktualizaci informace o distribuci, která je ve VPS. Toto můžete použít, když např. systém aktualizujete na novou verzi a distribuce zobrazená ve vpsAdminu pak neodpovídá realitě. Reinstalace systému _maže_ všechny subdatasety VPS, více o datasetech níže. VPS - parametry --------------- V detailu VPS je možné měnit parametry VPS. Minimální konfigurace VPS je 1 CPU, 1 GB RAM a 10 GB disku. Maximální konfigurace je 8 CPU, 16 GB RAM, diskový prostor není omezen. Swap se sice zobrazuje mezi parametry, ale standardně jej nepřidělujeme, protože swap v OpenVZ se chová jako rozšíření paměti [2]. Pokud chcete vytvořit novou VPS, je nutné pro ni udělat místo - snížit parametry jiné VPS. VPS - features -------------- Features lze zapínat/vypínat jednotlivě. Při jakékoliv změně dojde k restartu VPS. Doporučuji si nastavit jen features, které potřebujete. Např. zapnuté NFS nebo bridge blokuje online migraci. VPS - swap ---------- Teď nemám na mysli odkládací prostor paměti, ale swap ve smyslu prohození VPS mezi nody, v našem případě nejčastěji mezi playground a produkcí. Prohodit jde pouze VPS, které se nacházejí v odlišných lokacích (Praha, Playground, Brno). V rámci jedné lokace můžete jednoduše přehodit IP adresy a je to. Před vykonáním akce je v tabulce zobrazen stav VPS před a po provedení swapu. VPS - klonování --------------- Klonovat lze buď do nové nebo do existující VPS. V případě klonování do existující VPS je původní VPS se všemi subdatasety smazáno! Datasety -------- Dataset ve vpsAdminu reprezentuje přímo ZFS dataset na disku. Datasety se používají na data VPS i NAS. Koncept datasetu nahrazuje exporty z NASu. S datasetem VPS lze pracovat stejně jako s NASem. Proč se vůbec s datasety obtěžovat? Zejména kvůli možnosti nastavení kvóty a ZFS properties pro různé data/aplikace. Datasety VPS se nacházejí v detailu VPS a datasety NASu v menu NAS. Operace, které s nimi jdou provádět, jsou stejné. vpsAdmin umožňuje vytváření subdatasetů a nastavování ZFS properties. Pomocí properties lze optimalizovat výkon databází, apod. Ve většině případů je nemusíte vůbec řešit. Rozdíl mezi datasety VPS a NASu je v nastavování kvóty. Pro datasety VPS se používá refquota - místo zabrané snapshoty není zahrnuto. Datasety NASu naopak quota - místo zabrané snapshoty je zahrnuto. vpsAdmin automaticky nabízí správný typ kvóty. Rezervovaná jména datasetů jsou: private, vpsadmin, branch-*, tree.*. Tyto názvy nelze použít. Snapshoty --------- Zálohování probíhá pomocí zfs snapshotů, které jsou vidět v menu Backups, kde jdou také vytvářet a mazat. Zálohování VPS probíhá tak, že každý den v 01:00 se v rámci jednoho node udělá snapshot všech datasetů najednou. Poté jsou snapshoty přesunuty na backuper.prg. Pozor na to, že NAS _není_ zálohován na backuper.prg. Snapshoty jsou pouze lokální a slouží jen jako ochrana proti nechtěnému smazání dat, apod. Mounty ------ Mounty byly přesunuty z menu NAS do detailů VPS. Mountovat lze datasety i snapshoty. Do jakékoliv VPS jde mountnout jakýkoliv dataset či snapshot. Mounty jednotlivých snapshotů nahrazují trvalý mount záloh do /vpsadmin_backuper. Každý snapshot může být v jednu chvíli připojen pouze jednou, datasety toto omezení nemají. Nedoporučuji mountpointy zanořovat v nesprávném pořadí. Situace, kdy dataset 'raz/dva' je připojen nad dataset 'raz' není ošetřena. Mount lze pouze vytvořit a smazat. Nelze jej v průběhu jen tak odpojit a znovu připojit. Obnova záloh ------------ Obnovení VPS ze zálohy (snapshotu) funguje stejně, jako doposud. Obnova vždy funguje na úrovni datasetu. Když má VPS subdatasety a rootfs je obnoven ze zálohy, subdatasety obnoveny nejsou. Tzn. je možno obnovit jakýkoliv dataset, aniž by to mělo vliv na ostatní datasety. Při obnově jsou všechny snapshoty zachovány, díky větvení záloh [3] na backuperu. NAS je možné snapshotovat pouze manuálně. Jelikož ale není zálohován na backuper, obnova se chová stejně jako zfs rollback -r, tzn. obnova na starší snapshot _smaže_ všechny novější snapshoty. Je to nevratná operace. Pro obnovu dat ze zálohy na NASu bez smazání snapshotů si zvolený snapshot moutněte do VPS a data vykopírujte. Stahování záloh --------------- Stahování snapshotů je nyní součástí vpsAdminu. Vygenerované archivy jsou vidět v menu Backups -> Downloads. Odkazy jsou platné týden místo původních 3 dní. Transakce --------- Transakce nyní spadají do skupin nazvaných "transaction chain". Každá operace (vytvoření VPS, start, stop, klon, atd.) je reprezentována jedním chainem, který seskupuje více transakcí. V transaction logu v pravém panelu se zobrazuje seznam 10 posledních chainů a jejich postup v procentech. Kliknutím na ID chainu lze vidět, jaké transakce obsahuje. V ideálním případě se chain buď provede úplně a nebo vůbec. Pokud k dojde k neočekávané či neošetřené chybě, bude muset zasáhnout administrátor. Chainy se starají také o udržování konzistence databáze. Změny v databázi se provedou, jen když chain doběhne úspěšně. Může to být trochu matoucí, když se např. po změně hostname stále zobrazuje to staré. Po dokončení chainu se hostname aktualizuje a bude správně. Zatím nevím, jak to udělat víc user-friendly. Zámky objektů ------------- S každým objektem (VPS, dataset, snapshot, apod.) lze v jednu chvíli provádět jen jednu operaci. Zámky slouží k zaručení konzistence, aby si pod sebou vpsAdmin sám nepodřezal větev, což se občas stalo. Pokud na vás vyskočí chybová hláška "Resource is locked. Please try again." znamená to, že objekt, se kterým chcete něco udělat, je uzamčen a musíte počkat, až bude k dispozici. Pozastavování objektů, expirace ------------------------------- Administrátoři mají nově možnost pozastavit jednotlivé VPS, což budeme využívat v případě hacknutí VPS. Expirace členství už nebude hlídat člověk, ale vpsAdmin. Pokud členský příspěvek neuhrádíte do data uvedeného v notifikačním mailu, účet bude pozastaven. Za další tři týdny dojde k ukončení členství, viz finanční řád [4]. Networking ---------- Je možné se podívat na datové přenosy z minulých let. Autentizace ----------- vpsAdmin nyní ukládá hesla pomocí bcrypt. Heslo se při přihlášení automaticky aktualizuje. V Edit profile -> Authentication tokens je seznam autentizačních tokenů, které se používají při vybrání autentizační metody 'token' v HaveAPI [5]. Webové rozhraní vpsAdminu tokeny využívá. Zmiňuji se o tom, protože přes CLI nebo klientskou knihovnu obecně si můžete vytvořit token s trvalou platností. Na této stránce můžete tokenu nastavit popisek či ho smazat (odepřít přístup aplikaci, která jej využívá). Mód údržby ---------- Do módu údržby (maintenance mode) můžeme přepnout buď celý cluster, jednotlivé protředí, lokace, nody či VPS. V titulku ikony módu údržby je napsán důvod. API --- Většina aplikační logiky vpsAdminu byla přesunuta do API [6]. Webové rozhraní teď slouží prakticky jen jako prostředník mezi uživatelem a API. Využívá k tomu klientské knihovny v PHP [7] a JS [8]. API obsahuje vše krom správy přihlášek k členství, změn uživatelských účtů a datových přenosů. Aktuální stav funkcí -------------------- - Klonování VPS - zakázáno, musí se ověřit - Swapování VPS - zakázáno, musí se ověřit - Vytváření více produkčních VPS umožněno na dotaz [1] https://github.com/vpsfreecz/oficialni-dokumenty/blob/devel/financni_rad.md… [2] http://openvz.org/VSwap [3] https://projects.vpsfree.cz/vpsadmin-doc/storage/branching/ [4] https://github.com/vpsfreecz/oficialni-dokumenty/blob/devel/financni_rad.md [5] https://github.com/vpsfreecz/haveapi-client-php#usage [6] https://api.vpsfree.cz [7] https://github.com/vpsfreecz/haveapi-client-php [8] https://github.com/vpsfreecz/haveapi-client-js Jakub

1 0

Scientific Linux 6 - opakovane se rozbiji rpmdb
by Ondrej Mikle 31 Jul '15

31 Jul '15

Ahoj, zacala se mi na VPS opetovne rozbijet rpmdb. Projevuje se to napriklad tak, ze autoupdater neupdatuje a pri manualnim updatu to vyplivne: # yum update rpmdb: Thread/process 8471/139911281358592 failed: Thread died in Berkeley DB library error: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm CRITICAL:yum.main: Error: rpmdb open failed Vechny nalezene reseni funguji jen docasne (napr. smazani a rebuild rpmdb). Yum ani rpm se tento rok neupdatoval. Vcera, kdyz jsem to debugoval, tak se rpmdb rozbila po kazdem druhem "yum history info", dnes to po smazani a rebuildu zas magicky drzi pohromade. Nestalo se to nekomu jinymu, nebo netusite, cim by to mohlo byt zpusobeny? Napada me jedine filesystem corruption, ale nevim jak by to slo odladit. OM

3 3

setsockopt (SO_DEBUG): Permission denied
by Branislav Viest 27 Jul '15

27 Jul '15

Ahoj, nesetkali jste se někdo s hláškou setsockopt (SO_DEBUG): Permission denied při pokusu o připojení k SMTP server přes telnet na openvz kontejneru ? Je tam debian. Problém je, že nefungují odchozí emaily z openvz kontejneru (connection timed out) na jakýkoliv server. V rámci debugu jsem zjistil tuto hlášku při použití telnetu. Google mi toho bohužel moc neřekl. Doteď fungovalo vše ok ale dnes dochází k tomuto problému na dvou virtuálech. Ještě mně napadá blokace portu 25 ze strany ISP u IP adres těchto virtuálů. Díky S pozdravem Branislav Viest

3 3

HaveAPI v0.3
by Jakub Skokan 24 Jul '15

24 Jul '15

Ahoj, vydal jsem novou verzi frameworku HaveAPI v0.3.0, na němž je postaven vpsAdmin 2.0. HaveAPI [1] je framework na tvorbu self-describing RESTful API [2]. Součástí vydání jsou klienti pro Ruby (obsahuje CLI) [3], PHP [4] a JavaScript [5]. Mezi novinky patří: - aliasy akcí - abstrahované propojení s ActiveRecord - abstrahované výstupní formáty - podpora pro JS klienta v browseru (HTTP hlavičky pro Ajax apod.) - dynamické vytváření resources a akcí - jednodušší použití stejných parametrů ve vícero akcích v rámci resource - možnost dopředu načíst asociované (n:1) resources - dokumentace protokolu a další Do další verze plánuji udělat vlastní validátor vstupních parametrů, v současné době to spoléhá na validátory z ActiveRecord. Použitý protokol pro dokumentaci API a přenos dat budu v rámci semestrálního projektu ve škole formálně specifikovat. Poté můžou vzniknout implementace API serveru i v jiných jazycích. [1] https://github.com/vpsfreecz/haveapi/ [2] https://github.com/vpsfreecz/haveapi/#what-is-self-describing-api [3] https://github.com/vpsfreecz/haveapi-client [4] https://github.com/vpsfreecz/haveapi-client-php [5] https://github.com/vpsfreecz/haveapi-client-js Jakub

1 0

Icinga2
by Jiří Medvěd 22 Jul '15

22 Jul '15

Ahoj lidi, mate prosim s ni nekdo zkusenosti? Za boha nemuzu najit, jak nastavit acknowledge :/. Dekuji moc Medved

2 1

Souborová práva pro nginx/php-fpm
by "Jan B. Kolář" 22 Jul '15

22 Jul '15

Ahoj, původně jsem měl napsaný detailní e-mail, ale pak jsem si řekl, že by Vás to asi obtěžovalo číst :-D Pročetl jsem už hodně článků, přesto bych potřeboval poradit s jednou věcí. Snažím se dosáhnout takového nastavení nginx a php-fpm, které by bylo bezpečné, ale zároveň mi umožňovalo snadnou úpravu souborů (přímou editaci, kopírování, mazání). Na serveru mám cca. 10 projektů a přistupuji k němu sám (momentálně nemám potřebu přístupu více uživatelů k souborům). Poradíte mi, jestli je toto dobré nastavení pro "projekt1" (u dalšího by pak byl "projekt2", atd.): php-fpm.conf ------------------ user = projekt1 group = projekt1 ... listen.owner = www-data listen.group = www-data listen.mode = 0660 nginx.conf ------------------ user = www-data (nginx součástí skupiny "projekt1") web-root: /hosting/projekt1/web_root/* (chown ja:projekt1, chmod 640) tpm :/hosting/projekt1/web_root/tmp/* (chown ja:projekt1, chmod 660) Budou takto projekty dostatečně odděleny? Pokud dojde k napadení "projektu1", nemůže nějak útočník využít přístupu nginxu k "projektu2" (nginx bude ve skupinách všech projektů)? Jelikož php i nginx budou využívat stejného oprávnění skupiny, nehrozí zneužití nginxu pro zápis do složky "tmp" (teoreticky tam potřebuje zapisovat jen PHP, avšak jak práva oddělit)? Předpokládám, že největší zranitelností bude php (možná mylně). Je dobré mít u projektů pro "ostatní" zcela zakázán přístup? Přemýšlel jsem totiž i o nastavení, kde by "skupinu" tvořil php-fpm pool a jako "ostatní" by přistupoval nginx. To by však dle mého názoru znamenalo dát práva pro čtení "ostatním". Tedy alespoň při mých pokusech odmítal nginx zobrazit php stránku v případě, že index.php měl práva 640 (nginx nebyl součástí skupiny). Předem díky za Vaše názory případně odkazy na nějaké dobré zdroje informací. Honza

1 0

Brute-force utok na SSH
by Lukáš Šembera 17 Jul '15

17 Jul '15

Ahoj, chtel jsem se zeptat, jak se vyporadavate s automatizovanymi brute force utoky na SSH. Dnes jsem si po loginu vsiml na me CentOS7 instanci varovani, ze od posledniho uspesneho prihlaseni probehlo desitek set pokusu o pristup na SSH pomoci hesla. To me zarazilo, podival jsem se do logu a nasledovalo zdeseni: [root@home ~]# cat /var/log/secure | grep Failed | wc -l 21302 Coz je hodnote pouze za dnesek! Cetl jsem, ze se vesmes doporucuje zmenit SSH port (coz IMO nic neresi) v kombinaci s blokaci pomoci DenyHosts, fail2ban apod. Jsem v administraci serveru zacatecnik, tak by me zajimaly vase nazory, jak se s timto vyporadavate vy. Predem diky! S pozdravem Lukas Sembera

11 15

Kontrola přístupu k datům na serveru a zákoné požadavky
by petr＠juhanak.cz 14 Jul '15

14 Jul '15

Ahoj všem, rád bych s Vámi probral jeden z legislativních požadavků, se kterým se můžete také setkat. Ti z Vás, co provozují eshopy a registrovali se na úřadě pro ochranu osobních údajů jako správci osobních údajů, jistě jste řešili analýzu rizik a ochraná opatření zákona na ochranu osobních údajů 101/2000 Sb. v paragrafu 13. Pokud uchováváme osobní údaje (např. údaje o objednávkách) na serverech VPSFree, posuzuje se zde také riziko kontroly přístupu k datům přímo na serveru superadminem. Chci se zeptat, zda existuje nějaký smluvní dokument, který by řešil kontrolu přístupu, sledování přidělení super oprávnění, auditovatelnost a závazek mlčenlivosti. Jediný dokument, který jsem nalezl byly stanovy a informaci, že mezi členy jsou i právnické osoby/firmy. Možná jsem, něco přehlédl. Technicky lze samozřejmně situaci řešit šifrováním dat (pokud se někomu nepodaří najít klíče v paměti) nebo data ze serveru odsuout co nejrychleji pryč. Budu rád, když se podělíte o svoje zkušenosti z realizace opatření. Vím, že sdružení raději řeší technické problémy, ale postihy za porušení této povinosti jsou docela likvidační, zejména jste-li podnikatel ručící veškerým svým majetkem. Předpokládám, že řada členů již nějaké weby, které jsou relevatní k zákonu 101 provozují. Děkuji za názory k diskuzi. Hezký den. S pozdravem Petr Juhaňák

3 5

seccomp po update kernelu
by Daniel Kolesa 14 Jul '15

14 Jul '15

Zdravím, od posledního update kernelu mi přestal fungovat vsftpd s tím, že při loginu "prctl PR_SET_SECCOMP failed". Takže to vypadá, že v aktualizovaném kernelu je asi vypnutá možnost "CONFIG_SECCOMP_FILTER"... zatím jsem dal do svého vsftpd.conf workaround "seccomp_sandbox=no", ale lepší by to asi bylo opravit přímo na serveru. Díky, Daniel

5 7

{Disarmed} Re: mysql aborted
by Michal Kovarcik 08 Jul '15

08 Jul '15

_______________________________________________ Community-list mailing list Community-list(a)lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Community-list