Ahoj,
na podpore bylo par lidi, kterym nefungoval Docker pod Debian 8, tak
jsem se na to podival a bezi v poradku, jen se to musi udelat trochu
sloziteji nez uvadi dokumentace Dockeru. Aby Docker fungoval, je potreba
verzi 1.7+. Nize jsou kroky, kterymi jej rozhodit.
1) VpsAdmin / VPS -> Enable features -> musis zapnout (vpska se zrestartuje)
2) echo "JoinControllers=cpu,cpuacct,cpuset freezer,devices" >>
/etc/systemd/system.conf
3) mount -t tmpfs tmpfs /sys/fs/cgroup
mkdir /sys/fs/cgroup/freezer,devices
mount -t cgroup cgroup /sys/fs/cgroup/freezer,devices -o freezer,devices
mkdir /sys/fs/cgroup/cpu,cpuacct,cpuset
mount -t cgroup cgroup /sys/fs/cgroup/cpu,cpuacct,cpuset/ -o
cpu,cpuacct,cpuset
4) apt-get install curl -y
5) curl -sSL https://get.docker.com/ | sh (vyhodi chybu ohledne kernel
modulu -> ignore a cekat :))
6) usermod -aG docker $USER
7) vim /lib/systemd/system/docker.service
-ExecStart=/usr/bin/docker -d -H fd://
+ExecStart=/usr/bin/docker -d -H fd:// -s vfs
8) systemctl daemon-reload
9) systemctl enable docker
10) systemctl start docker
11) systemctl status docker -> mel by v poradku bezet
12) test -> docker run --rm hello-world
Medved
Cau,
kdyz uz je to tady posledni dobou tak krasne aktivni, napadla me jeste
jedna vec - e-mail s DKIM poslanej do mailinglistu prijde s doplnenou
patickou, coz samozrejme poskodi body hash v DKIM, takze jsou problemy s
dorucenim. Myslim si ze by mailserver mel pri preposilani zpravy do
mailinglistu odstranit starou DKIM hlavicku a pripadne pridat novou,
obsahujici podpis domeny lists.vpsfree.cz a s odpovidajicim body hash po
doplneni paticky mailinglistu. Nebo mate nekdo jinej napad jak to resit?
--
Stanislav Petr
glux(a)glux.org
stanislav(a)petr.email
+420 602 620 026
Ahoj,
konečně se blížíme k nasazení nové verze vpsAdminu. O novinkách a
změnách budu podrobněji informovat později. Teď jen ve zkratce, nová
verze vám členům přinese např.:
- rozšířené možnosti API
- vytváření, klonování, swapování a mazání produkčních i playground VPS
- přerozdělování prostředků (CPU, paměť, disk) mezi VPS
- možnost využít více IPv6 adres, IPv4 za doplatek
- vytváření subdatasetů VPS a NAS, nastavování kvót a jiných ZFS properties
- atomické snapshoty
- mounty datasetů, snapshotů
- robustnější a bezpečnější systém transakcí, atd.
To vše skrze webové rozhraní, CLI nebo API, bez nutnosti psát na podporu.
Předběžně, aktualizace vpsAdminu a související infrastruktury bude
probíhat 17-19.7. Datum se může ještě posunout, pokud bychom nestíhali.
Během aktualizace bude vpsAdmin nedostupný. Nutné věci budeme řešit na
podpoře. Neplánujte si prosím nic, k čemu by byl vpsAdmin v tuto dobu
zapotřebí. Přihlášky k členství půjdou zasílat, avšak budou schvalovány
až bude nová verze zaběhnutá.
Dojde k výpadku nasbox.prg. Všechny mounty NASu budou na čas odpojeny a
následně znovu připojeny. /vpsadmin_backuper bude zrušen, zálohy se
budou připojovat jednotlivě přes vpsAdmin.
Přesnější časový rozvrh dodám později.
Jakub
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
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
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
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
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
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
