Příspěvky

3091

Software / Re:Atributy v XML

« kdy: 10. 07. 2018, 17:45:42 »

Tak do této úvahy se vůbec nepouštějte, to je velmi složité téma, prosté srovnání zde z důvodu rozdílných podstat a účelů jazyků nemůže fungovat.

Proč by to srovnání nemohlo fungovat? Proč někteří vzývají stručnost u programovacích a podobných jazyků? Aby toho programátor mohl číst a psát co nejméně, aby se nemusel zabývat balastem. Psaná můžeme zanedbat, protože je za prvé méně časté, za druhé zrovna pro tyhle technické jazyky máme perfektní IDE, která ten „balast“ umí generovat sama. Takže zbývá čtení. A v čem se liší čtení programu od čtení novinového článku nebo diplomky, že by ta redundance u přirozených jazyků byla přínosná, ale u technických jazyků byla naopak škodlivá?

3092

Software / Re:Atributy v XML

« kdy: 10. 07. 2018, 15:04:30 »

Jenže ze všeho nejlepší zůstává stále XML, u kterého jsou vyřešeny problémy, kterými předchozí formáty trpí. Při správném návrhu je také dobře čitelný, je validovatelný a dá se zpracovávat standardními nástroji. Jen je poslední dobou vývojáři poněkud opomíjený.

No jo, jenže než na tohle většina lidí přijde, že to, co řeší s JSONem nebo YAML, má XML už dávno vyřešené, a že ty takzvané výhody JSONu nebo YAMLu jsou ve skutečnosti nevýhody…

Nejprve se mi XML moc nelíbil kvůli ukecanosti.

Tohle je zvláštní zcestná představa, kterou má ovšem spousta vývojářů – totiž že by jazyk (ať už programovací, formátovací nebo pro zápis strukturovaných dat) měl být maximálně stručný. Přitom si můžeme vzít za vzor přirozené jazyky, které přílišnou stručností rozhodně neoplývají. A to se lidský jazyk vyvinul z nějakých skřeků, takže se určitě rozvíjel od stručnosti směrem k rozvinutosti a redundanci. Už jenom tohle by mělo stačit k tomu, abychom si uvědomili, že určitá redundance v jazyce je pro člověka prospěšná (například proto, že nás při čtení utvrzuje v tom, že čteme správně).

3093

Software / Re:Certifikáty Let's Encrypt nefungují na Androidu

« kdy: 10. 07. 2018, 14:43:19 »

Ty konfiguráky jsou pomocí Include vložené do hlavního souboru, takže z pohledu Apache je to pak jeden velký konfigurák. Soubory se ale opravdu vkládají v abecedním pořadí, pokud je v Include uvedena maska s hvězdičkou.

3094

Software / Re:Certifikáty Let's Encrypt nefungují na Androidu

« kdy: 10. 07. 2018, 12:05:19 »

Aha, takze bez parametru servername to vybere vzdy prvy virtualhost podla abecedy.

Ne podle abecedy, ale první v pořadí jak jsou uvedené v konfiguračním souboru.

Avsak klientovi (web prehliadacu), apache poskytne vzdy spravny certifikat (neviem to overit na androide (ale to nevadi)).

Prohlížeči s podporou SNI pošle server správný certifikát (pokud tedy máte přiřazené správné certifikáty ke správným virtualhostům). Dnes už podporují SNI všechny používané prohlížeče, konkrétní prohlížeč si můžete najít na Can I use…

3095

Server / Re:Deploy web aplikace na linuxový server

« kdy: 10. 07. 2018, 10:24:16 »

Rad by som sa vyhol custom skriptom (treba ich pisat, odladovat a udrzovat)

To ale budete muset dělat vždy, protože máte nějakou svou aplikaci, takže nějak musíte popsat, jak se má nasadit. Jestli to budete popisovat skriptem nebo nějakou konfigurací je už vedlejší. Ostatně pokud nasazení spočívá jen v rozbalení zipu, ten skript je triviální.

3096

Software / Re:Certifikáty Let's Encrypt nefungují na Androidu

« kdy: 10. 07. 2018, 10:21:40 »

Když máte na jedné IP adrese a portu víc virtualhostů na HTTPS (rozlišených jménem), musí klient poslat na začátku SSL komunikace požadované jméno – ta technologie se jmenuje SNI. S OpenSSL tedy musíte navíc přidat parametr -servername.

Kód: [Vybrat]

openssl s_client -connect moj_web.com:443 -servername moj_web.com
openssl s_client -connect moj_web1.com:443 -servername moj_web1.com
openssl s_client -connect moj_web2.com:443 -servername moj_web2.com

Bez SNI server neví, které jméno serveru požadujete, tedy který má poslat certifikát, a použije první virtualhost v konfiguračním souboru.

3097

Server / Re:Deploy web aplikacie na Linuxovy server

« kdy: 10. 07. 2018, 09:31:26 »

Tu mam problem s krokom 3, je to samsostane beziaca aplikacia, ziadne skripty, ktora bezi na danom porte a ten nejde prehodit pocas behu.

Udělal bych na to jednoduchý skript, který rozbalí noovu verzi do nového adresáře, zastaví službu, přehodí symlink na novou verzi a službu nastartuje.

Kód: [Vybrat]

#!/bin/sh
set -e
cd "$(dirname "$0")"

VERSION=`cat upload/version.txt`

mkdir /opt/server/$VERSION
unzip -q upload/server-$VERSION.zip -d /opt/server/$VERSION

sudo systemctl stop server.service
ln -sn --backup=simple $VERSION /opt/server/current
sudo systemctl start server.service

3098

Software / Re:Atributy v XML

« kdy: 09. 07. 2018, 20:47:01 »

Primárně používám elementy. Mohou se opakovat, mohu do nich vkládat další elementy, můžu je zakomentovat atd. Atributy chápu jako něco, co chci jen přidat k nějakému elementu, ale samotné to nemá smysl – typicky při použití XML pro značkování textu. To, že se u ukončovacího tagu musí opakovat název elementu, bych vůbec neřešil – od toho přece máme editory.

3099

Server / Re:Deploy web aplikacie na Linuxovy server

« kdy: 09. 07. 2018, 20:15:37 »

• Oddělí se konfigurace od samotné aplikace, aby nebylo při instalaci nové verze dávat pozor, aby se něco nepřepsalo.
• Aplikace se rozbaluje do nového umístění (původní služba stále běží).
• Aplikace se přehodí do nového umístění

Ten třetí krok záleží na konkrétním způsobu fungování aplikace – pokud běží pod webovým serverem, který pouze servíruje soubory z disku (třeba PHP aplikace nebo statický web), stačí web serveru změnit symlink na kořenový adresář aplikace. Pokud má ta aplikace integrovaný web server a umí spolupracovat se socketovou aktivací systemd, dá se použít k bezvýpadkové změně to. Jinak je pro co nejkratší výpadek potřeba spolupráce aplikace, aby si uměla prohodit port se starou verzí. A pokud krátký výpadek nevadí, tak se prostě zastaví stará verze služby a pak nastartuje nová verze.

Puppet, Kubernetes, Ansible, distribuční balíčkovací nástroje a další mají smysl tehdy, pokud tím chcete spravovat víc aplikací, nebo vám ta aplikace běží v několika instancích. Pokud ta aplikace běží na jednom serveru, stačí shell skripty – bylo by pracnější starat se o ty automatizační nástroje než o tu samotnou aplikaci.

3100

Server / Re:SSL certifikáty pro „krabičky“

« kdy: 09. 07. 2018, 20:00:40 »

LE s DNS je samozřejmě řešení, pokud Vám nevadí, že v kritické infrastruktůře ( DNS ) se Vám hrabe nějaký skript.

Ten skript se nepotřebuje v DNS nijak hrabat, potřebuje pouze oprávnění k publikování TXT záznamů ve tvaru _acme-challenge.*. K ničemu jinému mu práva dávat nemusíte.

3101

Server / Re:SSL certifikáty pro "krabičky"

« kdy: 09. 07. 2018, 15:03:00 »

Ještě doplním, že domény pro Let's Encrypt lze ověřovat i čistě přes DNS, takže není potřeba nai ten web server. Takže stačí mít veřejnou doménu a umět do ní vložit správné TXT záznamy.

3102

Software / Re:problem s letsencrypt na androide

« kdy: 06. 07. 2018, 20:22:57 »

Ten serverový certifikát máte vystavený pro obě domény (bez www i s www)? Zkontrolujte ještě pomocí openssl x509 (příklad jsem uváděl), jestli v tom /etc/letsencrypt/live/moj_web.com/chain.pem je správný certifikát Let's Encrypt. Žádnou jinou možnou chybu tam nevidím.

Když to testujete (z Androidu nebo tím OpenSSL), jste si jistý, že se připojujete na tenhle server?

3103

Software / Re:problem s letsencrypt na androide

« kdy: 06. 07. 2018, 15:38:37 »

Cize ak tomu spravne chapem, tak v apache vhost configu pouzijem vzdy privkey.pem (to je tajny kluc, ktory sa nesmie nikdy dostat nikomu do ruk).
A nasledne pouzijem fullchain.pem (alebo na miesto neho, chain.pem a cert.pem).

Ano.

Takze by to malo byt jedno ci v configu pouzijem

Kód: [Vybrat]

privkey.pem
fullchain.pem

alebo

Kód: [Vybrat]

privkey.pem
chain.pem
cert.pem

Ano, jenom musíte ty soubory uvést u správných direktiv, ale to asi máte, příklady tu byly několikrát.

Ale nefungovalo mi to ani z jednou z moznosti.

Buď v těch souborech máte špatné certifikáty, nebo měníte v Apache konfiguraci něčeho jiného (jiného virtualhosta, jiného serveru), než pak testujete. Těmi příkazy výše si můžete překontrolovat obsah těch certifikátů. Spíš bych to ale viděl na tu špatnou konfiguraci Apache – pak by bylo vhodné ji sem celou vložit, protože jinak můžeme jen hádat.

Co sa tyka certifikatov (ci k sebe sedia alebo nie) to ja asi ovplivnit neviem, spolieham sa na vygenerovane certifikaty letsencryptom

Předpokládám, že ta utilita generuje správné soubory. Ale mohl jste něco pokazit při tom testování.

3104

Software / Re:problem s letsencrypt na androide

« kdy: 06. 07. 2018, 14:55:34 »

Ved presne tak som to spravil ako uvadzate.

Ne, v tom vašem výpisu jste měl navíc druhou volbu SSLCertificateChainFile.

Co sa tyka overenia, tak mam tam len 0 (1 nie)

To znamená, že Apache ten mezilehlý certifikát neposílá a to je ten důvod, proč tomu certifikátu Android nedůvěřuje. Podívejte se na ty soubory cert.pem a chain.pem. V každém by měl být jeden certifikát (jeden blok  -----BEGIN CERTIFICATE----- […] -----END CERTIFICATE-----). V souboru cert.pem by měl být jen certifikát vašeho serveru, v souboru chain.pem jen certifikát /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3. Následující příkazy vám obsah těch souborů a certifikátů v nich vložených vypíšou:

Kód: [Vybrat]

openssl x509 -text -noout -in /etc/letsencrypt/live/web/cert.pem
openssl x509 -text -noout -in /etc/letsencrypt/live/web/chain.pem

A mimochodem, pokud ty certifikáty k sobě nesedí (což je asi důvod, proč Apache ten mezilehlý certifikát neposílá), předpokládám, že o tom Apache něco napíše do logu, takže bych se podíval i tam. Předpokládám, že bude něco špatně v tom chain.pem. Možná tam máte vložený i ten serverový certifikát – pak ten soubor použijte pro SSLCertificateFile.

3105

Vývoj / Re:Placená Java SE?

« kdy: 06. 07. 2018, 14:42:47 »

Java11 nebude public

„Java 11“ je označení verze programovacího jazyka, ne JRE nebo JDK. Od Oraclu existují dvě JDK – OpenJDK a OracleJDK. OracleJDK obsahuje nějaké funkce navíc, např. to, co bylo dříve součástí placeného JRockitu. OpenJDK bude vycházet každý půlrok a bude stále veřejné a dostupné komukoli, ale nebudou udržovány (alespoň ne Oraclem) staré verze. Vedle toho bude OracleJDK, které má ty funkce navíc pro platící zákazníky, a tam bude každá hlavní verze podporována několik let (záleží na úrovni podpory).

Navíc ještě ta „Oracle podpora“ neznamená, že si musíte koupit samostatnou podporu pro Javu – pokud má někdo WebLogic nebo další podporované produkty Oraclu, má v rámci toho i podporu pro Javu.