Hlavní navigace

Vlákno názorů k článku Caddy: web server s Let's Encrypt v základní výbavě od Ondřej Surý - V případě 64bitového Linuxu má binárka velikost téměř...

  • Článek je starý, nové názory již nelze přidávat.
  • 14. 3. 2016 14:50

    Ondřej Surý

    V případě 64bitového Linuxu má binárka velikost téměř 23 MB. Pro srovnání: balíček nginx-full v Debian Jessie sice zabírá po rozbalení jen lehce přes 1 MB, pokud jej však instalujete na minimální systém, vyvolá stažení dalších závislostí, které si řeknou o dalších 62 MB.

    Snažíte se naznačit, že si nginx do paměti po startu natáhne i veškerý obsah /usr/share/doc? Místo na disku, které zabírají balíčky, je veličina, která je opravdu nezajímavá z libovolného úhlu pohledu
    Co je zajímavé, je spotřebovaná paměť per nakonfigurovaný web, per spojení, atp. Sdílené knihovny zabírají v paměti místo jenom jednou (zjednodušeně řečeno).

    Aneb fakt mě na závodní dráze nezajímá, že má trabant opravdu ale opravdu lehkou karosérii...

    A osobně si myslím, že Go se svým statickým linkováním je security nightmare. CVE-2015-8618, které Vás donutí překompilovat veškerý Go kód používající TLS (resp. RSA klíče) je fakt bezva.

    Taky zbožňuji instalaci náhodných binárek z náhodných webových serverů, kde není zjevné, s čím a jak bylo co zkompilováno. Přijde mi to jen o úroveň horší než `wget foo | sudo bash`. Bavíme se tady o kontrole kontrolních součtů a tady není ani vidět jaké verze knihoven výsledná binárka používá. Řekněme, že je v miekově DNS knihovně v nějaké verzi bezpečnostní chyba, tak a teď mi řekněte, jestli jsem v bezpečí nebo ne? Těžko říct, co? GH/miek/dns je jenom git repozitář, který zatím nemá ani jeden release, tj. se při každém sestavení použije aktuální verze z gitu? A mám vlastně správnou verzi z webu, když autor nevystavuje podepsané kontrolní součty, nebo už mám na serveru nějakou pěknou čínsko-rusko-americkou binárku, a tajné služby se přetahují, kdo rychleji stáhne obsah mého disku? No bezva, půlka bezpečnostního týmu právě podala výpověď a druhá půlka se preventivně opila do němoty...

    Na takové to domácí hraní, kde to na klik nasadím v throw-away kontejneru, je to dobrý, ale pro seriózní použití směrem ven do Internetu, kde jsou zapotřebí nějaké garance, bych raději pouvažoval o projektu, který bezpečnost bere vážněji.

  • 14. 3. 2016 16:12

    . . (neregistrovaný)

    Go a bezpečnostní aktualizace je docela peklo, jednak je vždy nutné vše nutně kompilovat svépomocí právě kvůli statickému linkování.

    Go trpí (teda spíše většina aplikací nad ním) neduhem v podobě definování závislostí pouze na master. Nejenže nedokážu zpětně zkompilovat stejné verze závislostí jako před týdnem, nemám ani přehled o tom, která oprava je již součástí masteru závislosti a která ne.

    Peklíčko, pánové. Řešením je si všechny závislosti složitě spravovat třeba přes godeb, trackovat si commity, z kterých se buildí a k tomu si automaticky generovat changelogy a hledat opravy konkrétní bugů a případně redeployovat. Nemáte náhodou někdo lepší řešení?

    Caddy je ale opravdu docela návyková věc na takovéto jednoduché spouštění interních appek pro různé potřeby, běží stabilně, snese se supervizorem, v paměti toho tolik nebere. Nezvládá ale vysokou konkurenci a v zatížení není porovnatelný s haproxy/nginx/var­nish. Necpěte ho ale na produkci :)

  • 14. 3. 2016 17:40

    lzap

    Kde to mám podepsat? :-) To srovnání oproti systémovému balíku bylo opravdu zbytečné, nicméně jinak je článek pěkný, taky mě ten software zaujal (na takovéto "domácí webserverování").

    Pamatujete na DLL-hell? Pak na JAR-hell? Teď máme Go-hell... Jako občasný balíčkář jsem se s tím už potkal a je to hodně špatně řešitelná situace, pokud se upstream k tomu bude stavět a nadále chladně. Ono to do sebe "zapadá" - kontejner plný CVEček, v něm běží mega-statická binárka s další várkou CVEček a přes to všechno se odesílá spam, dolují bitcoiny a DDoSuje zatímco autor rajdí na skateboardu a na zádech v batohu MacOS.

  • 15. 3. 2016 10:21

    Michal Halenka

    Snažíte se naznačit, že si nginx do paměti po startu natáhne i veškerý obsah /usr/share/doc? Místo na disku, které zabírají balíčky, je veličina, která je opravdu nezajímavá z libovolného úhlu pohledu
    Co je zajímavé, je spotřebovaná paměť per nakonfigurovaný web, per spojení, atp. Sdílené knihovny zabírají v paměti místo jenom jednou (zjednodušeně řečeno).

    Aneb fakt mě na závodní dráze nezajímá, že má trabant opravdu ale opravdu lehkou karosérii...

    Děkuji za váš názor. Natahování /usr/share/doc do paměti při normálním použití je samozřejmě nesmysl. Pokud podle vás toto vyplývá z některé části článku, tak se omlouvám, nebyl to záměr. Pokus o srovnání velikosti s nginx je zde zmíněn z toho důvodu, že jsem se s otázkami ohledně přiměřenosti velikosti binárky již několikrát setkal. Proto jsem se snažil číslo zasadit do kontextu pro porovnání.

    Spotřeba paměti samozřejmě je zajímavý údaj, nicméně se tady snažíte o zařazení Caddy serveru do kategorie, do které nemíří. Jeho hlavním cílem není rychlost nebo nenáročnost na prostředky, ale jednoduchost nasazení a konfigurace. Vaše přirovnání se závodní dráhou je tedy stejně zcestné, jako byste samořídící automobil od Google hodnotil podle výsledku na oné závodní dráze.

    Bezpečnost, kontrolní součty, a komplikace s reprodukovatelností sestavení jsou samozřejmě nezanedbatelná kriteria, ale jsou dána použitým jazykem, a nikoliv projektem či konceptem jako takovým.

  • 15. 3. 2016 15:23

    . . (neregistrovaný)

    Bezpečnost, kontrolní součty, a komplikace s reprodukovatelností sestavení jsou samozřejmě nezanedbatelná kriteria, ale jsou dána použitým jazykem, a nikoliv projektem či konceptem jako takovým.

    tady v tom jazyk s tím tolik nesouvisí, go get je výchozí balíčkovací/ses­tavovací nástroj a je možné použít jiný (godeb si třeba umí uložit konkrétní verze závislostí a poté je znovupoužít), použít git submodules či jiným způsobem sestavit závislosti ke kompilaci. Hlavní problém jsou vývojáři, kteří s tím dělají a kašlou na to.

  • 15. 3. 2016 15:57

    Ondřej Surý

    S tím srovnáváním jste začal Vy v článku. Jen tak mimochodem, nginx(-full) binárka a všechny sdílené knihovny, což je přibližně[*] tento seznam:

    14544 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
    14664 /lib/x86_64-linux-gnu/libdl-2.19.so
    20648 /usr/lib/x86_64-linux-gnu/libXdmcp.so­.6.0.0
    35176 /lib/x86_64-linux-gnu/libcrypt-2.19.so
    62376 /usr/lib/x86_64-linux-gnu/libjbig.so.0
    64024 /lib/x86_64-linux-gnu/libpam.so­.0.83.1
    72136 /lib/x86_64-linux-gnu/libgpg-error.so.0.13.0
    72904 /usr/lib/x86_64-linux-gnu/libXpm.so­.4.11.0
    87912 /usr/lib/x86_64-linux-gnu/libexslt.so­.0.8.17
    109144 /lib/x86_64-linux-gnu/libz.so.1.2.8
    113024 /lib/x86_64-linux-gnu/libaudit.so­.1.0.0
    137440 /lib/x86_64-linux-gnu/libpthread-2.19.so
    138016 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
    141752 /lib/x86_64-linux-gnu/liblzma.so­.5.0.0
    158616 /lib/x86_64-linux-gnu/libpng12.so­.0.50.0
    165864 /lib/x86_64-linux-gnu/libexpat.so­.1.6.0
    195616 /usr/lib/x86_64-linux-gnu/libGeoIP.so­.1.6.2
    248816 /usr/lib/x86_64-linux-gnu/libfontcon­fig.so.1.8.0
    256144 /usr/lib/x86_64-linux-gnu/libxslt.so­.1.1.28
    289464 /usr/lib/x86_64-linux-gnu/libjpeg.so­.62.1.0
    392312 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
    426216 /usr/lib/x86_64-linux-gnu/libgd.so.3.0.0
    448440 /lib/x86_64-linux-gnu/libpcre.so­.3.13.1
    479528 /usr/lib/x86_64-linux-gnu/libtiff.so­.5.2.0
    696008 /usr/lib/x86_64-linux-gnu/libfreety­pe.so.6.11.1
    924096 /lib/x86_64-linux-gnu/libgcrypt­.so.20.0.3
    1051056 /lib/x86_64-linux-gnu/libm-2.19.so
    1215032 /usr/sbin/nginx
    1319088 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
    1465816 /usr/lib/x86_64-linux-gnu/libxml2.so­.2.9.1
    1738176 /lib/x86_64-linux-gnu/libc-2.19.so
    1776592 /usr/lib/x86_64-linux-gnu/libvpx.so.1.3.0
    2062720 /usr/lib/x86_64-linux-gnu/libcrypto­.so.1.0.0

    zabírají celkem cca 15MB.

    * - přibližně, protože některé z knihoven můžou do paměti natahovat nějaké kousky dynamicky.

    Z toho minimálně dva největší kousky (libc a libcrypto) jsou už natažené do paměti kvůli něčemu jinému.

    Kdyby to Vaše srovnání nebylo takový do očí bijící nesmysl, tak bych nad tím asi i mávl rukou.

    > nikoliv projektem či konceptem jako takovým.

    Nepodepsané binárky bez kontrolních součtů na web dal taky onen jazyk? Aha, to je pekelná potvora to Go... No tak to jó.

  • 19. 3. 2016 11:14

    Vít Šesták

    "Bezpečnost, kontrolní součty, a komplikace s reprodukovatelností sestavení jsou samozřejmě nezanedbatelná kriteria, ale jsou dána použitým jazykem, a nikoliv projektem či konceptem jako takovým."

    I kdyby to byla pravda (jakože není), tak:

    1. Je mi asi celkem jedno, jestli mám děravý server kvůli jazyku, kvůli standardní knihovně, kvůli samotnému projektu webserveru, nebo kvůli distribuci. Prostě mám děravý server a otázkou potom jsou rizika, možnosti řešení atd.
    2. Volba jazyka atd. je taky záležitostí autorů, to není volba, která by jim byla vnucena zvenku...