dehydrated (predtym letsencypt.sh) a DNS-01 s Bernsteinovym tinydns pouzivam od zaciatku. Dovodom je pythoni bordel a teda jeho absencia na serveroch. Nepochopim naco kodili aplikaciu v Pythone ked sa da napisat v bashi. Tie hooky sa IMHO daju sklbit s akymkolvek systemom, ked nic ine tak screenscraping nejakej remote sluzby
Nepochopim naco kodili aplikaciu v Pythone ked sa da napisat v bashi.
Protože parsování JOSE+JSON řetězců sérií sedů a grepů je prasárna*, která určitě určitě selže v některých okrajových případech. Na zpracovávání takto komplexních protokolů je je jenom správné používat dedikovanou a prověřenou knihovnu, která bude fungovat za všech okolností a bude správně reagovat napřáklad i na nevalidní vstup.
Ostatně, žádost o certifikát by taky určitě šlo vyrobit v bashi. Nepochopím, proč se někdo kódil s openssl. ;)
*) To nic nemění na tom, že v roli ACME klienta to funguje překvapivě dobře a vzhledem k zásadním omezením certbota jde často o jediné rozumně použitelné řešení.
Ked ide o parsovanie JSONu tak pochopim pouzitie jq (https://stedolan.github.io/jq/) a nie mastodonti jazyk, ktory ma problem jedna verzia od druhej, co sa plata cez rozne virtualne environmenty...
Python je na to naopak docela vhodny. Perl by byl jeste vhodnejsi (ve "strict" rezimu objevi uz pri "kompilaci" vyrazne vice chyb nez python), ale ma mene uzivatelu, a ma spatnou povest, protoze dava programatorum svobodu. Ale na skripty ktere maji byt bezpecne (coz by rozhodne skript na manipulaci s certifikaty mel byt) by to urcite chtelo jazyk, ktery odhali pri kompilaci i preklepy v atributech objektu/klicich pole. Bohuzel jsem jeste nenarazil na takovy, ktery by byl zaroven natolik rozsireny, ze by mu nechybela siroka baze kvalitnich knihoven. (Python mel problemy s kvalitou knihoven, to se teprve posledni roky zlepsuje. Perl mel knihovny kvalitni, ale dnes jiz budou stare.)
Na PERLe som vyrastol, ale ani v nom by som to nevidel radsej nez v Pythone. Veci ako spamassassin vyuzivajuce silnu stranku PERLu - regularne vyrazy a ich integraciu do jazyka su exemplarnym prikladom logickeho uvazovania.
ACEM klient ale nic take nerobi. Jeho jedina funkcia je robit requesty (curl) a pracovat so subormi.
Ked uz nie bash, tak to mali napisat v cpp. Bolo by to bezpecne a pri kompilacii by sa odhalili vsetky preklepy. Je sice pekne ze si viem pozriet zdrojak ktory spustam, ale v tom pythonom bordeli nie je sanca najst par riadkov ktore tam nepatria a kludne mozu preposielat privatne kluce mimo serveru. Kto to pouziva a overuje checksum pred kazdym spustenim?
Ale koncim to s tym, ze nech si kazdy pouziva co chce, dehydrated mi uplne vyhovuje
I am using jq in bash as is it needs and possible. It is not true that bash is obsolete or bad. Still is more faster and useful for lot of short scripts and utilities. And in general - is everywhere.. Someone can blame me but for part of “us” it can be view of daily “Linux” life.
To neděláte dobře. Otírat se na tomto serveru o takové jazyky obvykle dobře nekončí. Jinak pochopitelně máte pravdu, což ovšem v diskusi na rootu vždy předchází průšvihu. Já bych opravdu chtěla vidět odvážlivce, který ten jejich skript spustí. Pochopitelně s root právy, protože jinak to nejde. Zjistit z kodu co to dělá je fakt pythomně dlouhý příběh, navíc šance, že to něco rozbije, je značná. Existuje jiné řešení, sice také v pythomci, ale bez root práv. LE ho má na webu. Bohužel bez patchnutí jste v IPv6 prostředí v háji. Prošla jsem tím a zkusila to. Ovšem nejlepší na tom celém je, že jediné, co LE ověřuje, je to, že na webserver umístíte nějaký soubor. Jen jednou a proběhne to v předvídatelném čase. Proč si někdo myslí, že útočník dokáže přesměrovat na sebe náhodný traffic pro několik uživatelů, ale nedokáže to udělat pro JEDINÝ předvídatelný request z LE? Hm? Asi trochu přebujelé ego. Ale to se tady také říkat nesmí. Ach ano, máme tu ještě ty Mikrotiky...