MS Visual Code klávesové zkratky

Zkrakta Vyznam
⇧⌘V Nahled MD souboru
⌘K V MD view the preview side-by-side

The BASH Guide

http://guide.bash.academy

JWT: JSON Web Token

jwt-handbook (PDF)

Microsoft Visual Studio Code

Alternativně jsem vedle Atomu začal používat Microsoft Visual Studio Code.

Několika prvních postřehů:

  1. Editor je pěkně rýchlý…
  2. Jeho konfigurační možnosti vypadají srovnatelně s Atomem…
  3. Existují stejné pluginy, které používám v Atomu, ale s různými klávesovými zkratkami. Dá se přenastavit a editor pro key-binding je povedený, přehledný…

Jediný problém, na který jsem narazil, nicméně jej hned odstranil bylo, že jsem nemohl v iTermu pohodlně spouštět Code přimo s obsahem daného aktuálního adresáře.
Řešením je přidání následující funkce do .bash_profile a pak už spustíte MSVS Code odkudkoliv jednoduše zadáním příkazu code

IOPS

Inuput Outpu Operations Per Second

Obecná horizontálně škálovatelná architektura MongoDB clusteru.

Zvýšení performance IOPS rozdělením dat, indexů a logs na samostatné disky
–directoryperdb
–wiredTigerDirectoryForIndexes

NodeJS: NODE_ENV dev || production

Taková ta uplná klasika: vyvíjíte aplikaci na svém stroji, kde máte samozřejmě úplně jinou konfiguraci, než na produkčním serveru, respektive také odlišnou od konfigurace kolegy, který se snaží psát pod Windejsi.
Tou jinou konfigirací může být cokoliv. Od propojení na externí služby až po způsob logování toho co a jak chcete vidět. Jasně že na developu vás zajíma víc věcí, které chcete na produkci vidět až když řešíte nějaký problém…

A řeči o tom, že byste měli kontejnerovat, dokrovat a tak vás taky nebaví. Nevidím jediný důvod, proč bych měl na svém lokále sestavovat nějaký dokr a pak spouštět virtuální stroj… WTF! Jediné co chci je spustit apku na mém mekovi prostě jinak nakonfigurovanou, ale funkčně pokud možná co nejvíc identickou s produkčním prostředím…

Dřív jsem rozdílnou konfiguraci do aplikace zaváděl skrze parametr příkazové řadky. Vstupní JS modul aplikace rozparsoval parametry příkazové řádky. Pokud našel parametr udávající soubor s konfigurací, pak se jej pokusil naimportovat. Pokud nic takové, pak natáhnul nějakou defaultní konfiguraci… Super. Funguje skvěle a umožnuje opravdu dobře nakonfigurovat kde co a to pokaždé úplně jinak. Prostě jak je libo…

Jenže jsem línější a línější a i tohle mi připadalo jako opruz. Je to přece jen nějaký kód navíc.. Já vím, že ne moc, ale je… Stačilo mi prostě něco lehčího.

NODE_ENV

A tak jsem se vrátil k NODE_ENV. Ne že bych o ní nevěděl, ale protože jsem vytvářel přece jen složitější struktury, mírně jsem podcenil možnosti této enviroment proměnné, a proto jí nějak moc rychle přeskočil. Chyba. NODE_ENV mi umožňuje dál lenošit a odpadl problém s konfigurací.

Jediné co jsem musel ořešit je jak NODE_ENV propašovat v různých způsobech spouštění, či využívání přímo do aplikace. Apku spouštím různě a nechtěl jsem se připravit o konfort kastomizovaných konfiguráků specifikovaných z příkazové řádky.

Základní implementace v package.json skrze sekci script:

Pokdud spouštíte apku z shellu, pak takto:

No a pokud potřebujete NODE_ENV sdílet s dalšími nástroji, jako je gulp, nebo cokoliv jiného, pak:

Samotný JS kód se pak k proměnné prostředí dostane odkudkoliv skrze globální promenou process, která obsahuje celý ENV, včetně toho co sami nějak nadefinujete:

Takže můj konfig dnes může vypadat i takto:

Samozřejmě se i tohle dá napsát jinak, dle libosti… 🙂

Nicméně tohle je obecný přístup, kterým se dá do vaší apky propašovat jakákoliv proměnná z prostředí operačního systému…

__main__ v NodeJS

Kdysi jsem tady popisoval jak v NodeJS připodobnit chování runtime při spouštění daného modulu. Něco, co se běžně v Pythonu dělá takto, ale v NodeJS se to moc nevidí:

Původně jsem v NodeJS tohle řešil následovně:

Další, možná o něco lépe vypadající řešení

Tahle podmínka mi prostě připadá logičtější 🙂

A k čemu je to dobré?

No třeba k samotnému testování… Jsem líný a někdy mi dělá problém dokopat se udělat nějaké testování nad modulem, kyterý je přece úplně jasnej: tady nemůže být žádná chyba…. A právě proto přímo dodaného modulu napíšu tuhle podmínku, která má nějakou sekci, která se provádí jen v případě, že modul spouštím přímo pod NodeJS a nerequiruji ho do nějakého dalšího, nadřazeného modulu.

Blokování SSH útoku

Součástí mé každodenní práce je deploy aplikací na různé linuxové servery (Fedora, Centos) umístěných někde v Internetu. Pro tohle používám kombinaci nástrojů BASH, SSH a GIT. Plus mínus nějake další věci, které jsem si sám napsal, nebo někde okoukal…

Základem všeho je ale korektně se připojit na server. Absolutní bezpečnostní minimum konfigurace SSH daemona je přihlášení se přes klíče, zakázané hesla a zakázaný účet root. I přesto je neuvěřitelné, jak rychle po oživení nového serveru, se pokusí na něj někdo z Číny, Ruska nebo z podobně zajímavé ciziny přihlásit jako admin, nebo někdo podobný…

Nejdříve jsem se čas od času snažil geolokalizovat IP cizince, a pak jej podle lokality buď zakázal, nebo nechal žít. Ano, v podstatě jsem jej vždy zakázal:

No a po posledním přihlášení a zadání sudo su – jsem byl docela zděšen: více než 2.000 pokusů a SSH login roota někde z Tramtárie…
Je jasné, že jakýkoliv neautomatizovaný způsob řešení tohoto robotizovaného napadení je absolutně neúčelný, a proto jsem chvíli gůgloval a studoval, abych našel 2 nástroje, které toto rozumně řeší.

DenyHOSTS

DennyHOSTS je pěkný, jodnoduchý nástroj, který prozkoumává váš /var/log/secure a v případě opakovaného neúspěšného pokusu o přihlášení zaznamené IP adresu vtipálka do /etc/hosts.denny a skrze iptable tuto adresu zablokuje. Vedle toho máte možnost v /etc/hosts.allow specifikovat IP adresy, které mají být vždy povolené. Vedle těchto 2 souborů máte jen /etc/denyhosts.conf, kde specifikujete samotná nastavení služby, jako je způsob reportování a podobně.
Významnou předností této aplikace vidím právě v jednoduchosti a přímosti. Nemá fičury jako Fail2ban, ale ty jsem ani zatím nepotřeboval.

Fail2ban

Fail2ban pracuje podobným způsobem jako DenyHOSTS, ale přidává další užitečné funkce, které z něj dělají ještě mocnější nástroj. Jednou z nich je například možnost nastavit automatického odbanování IP adresy po uplynutí zadané doby a podobné věci.

Geolokalizace IP adresy

Z důvodů pořešení nějakých bezpečnostních praktik jsem potřeboval nějak blíže geolokalizovat IP přihlašovaného uživatele, respektive záškodníka, abych věděl odkud se fyzicky přihlašuje:

NodeJS: geolokalizace IP adresy

Python: geolokalizace IP adresy

Reference Cards for MongoDB

Reference Cards for MongoDB (PDF format)

© 2017 pepa.holla.cz

Theme by Anders NorénUp ↑