Příspěvky

3316

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 10:57:20 »

Musíte mít názvy web1.ddns.com a www.web1.ddns.com nastavené v DNS a nasměrované na váš server.

Kód: [Vybrat]

<VirtualHost *:80>
    ServerName web1.ddns.com
    ServerAlias www.web1.ddns.com

    RewriteEngine on
    RewriteRule ^(.*)$ https://web1.ddns.com$1 [R=301,NE,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName www.web1.ddns.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/web1.ddns.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/web1.ddns.com/privkey.pem

    RewriteEngine on
    RewriteRule ^(.*)$ https://web1.ddns.com$1 [R=301,NE,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName web1.ddns.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/web1.ddns.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/web1.ddns.com/privkey.pem

    DocumentRoot /var/www/web1.ddns.com
</VirtualHost>

Předpokládá to, že v souboru [tt]/etc/letsencrypt/live/web1.ddns.com/cert.pem[/tt] je certifikát vystavený na obě jména [tt]web1.ddns.com[/tt] i [tt]www.web1.ddns.com[/tt]. Můžete pak doplnit k oběma HTTPS virtualhostům posílání HSTS hlavičky, jak to máte ve vašem úvodním příkladu. A pokud chcete použít PHP, musíte ho samozřejmě mít správně nakonfigurované.

3317

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 10:05:47 »

1/ pridat do Server alias snad neni neprekonatelny problem - nebo ano?

Problém to není, akorát to bude k ničemu, když uživatel zadá do prohlížeče web1.ddns.com a přesměruje ho to na úplně jiný web https://web2.ddns.com.

dokumenty pocitam ze budou spolecne pro vsechny domeny

To by byla pěkná hloupost. Přínos toho mít jeden obsah pod dvěma doménami by nebyl žádný, za to by z toho vznikal zmatek a vyhledávače by to vyhodnotily jako duplicitní obsah a penalizovaly.

BTW - pro HTTPS musi mit patricne certifikaty, ale to je snad samozrejmost

To už má ale darebacik vyřešeno.

Když má být na jednom serveru hostováno několik webů, je nejjednodušší mít pro každý z nich dva virtualhosty, jeden pro HTTP a druhý pro HTTPS. Aspoň je hned na první pohled v konfiguraci vidět, kde je který web nakonfigurován. Pokud by si chtěl darebacik později konfiguraci zkrátit, může si nastudovat, jak se u přepisovacích pravidel používají proměnné a všechno přesměrování na HTTPS spojit do jednoho virtualhosta – protože pro weby chce použít jen kanonické názvy, bez přesměrování z prefixu www. Pokud by chtěl přesměrování i z webů s www (měl by to v DNS), pak by bylo rozumné mít na to druhý virtualhost.

3318

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 09:31:52 »

2 virtualhosty, jeden na HTTP:

Kód: [Vybrat]

                ServerName domena.cz
                ServerAlias *.domena.cz

                RewriteEngine on
                RewriteCond %{HTTP_HOST} ^(.+)\.domena\.cz$ [NC]
                RewriteRule ^(.*)$ http://domena.cz$1 [R=301,NE,L]
        	RewriteCond %{HTTPS} off
                RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Druhy na HTTPS:

Kód: [Vybrat]

                ServerName domena.cz
                ServerAlias *.domena.cz

                RewriteEngine on
                RewriteCond %{HTTP_HOST} ^(.+)\.domena\.cz$ [NC]
                RewriteRule ^(.*)$ https://domena.cz$1 [R=301,NE,L]

Takhle určitě ne. Za prvé tam počítáte pouze s jednou doménou, darebacik chce dvě domény. Za druhé tam máte jenom přesměrování a nikde neřešíte samotné dokumenty. Za třetí úplně zbytečně variantu s prefixem a bez HTTPS přesměrováváte nadvakrát, o čemž jsem psal výše.

3319

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 03. 06. 2018, 08:33:10 »

Pokud chcete mít virtualhosty pro dva různé weby pro HTTP i HTTPS, budete mít pro každou ze čtyř variant jeden virtualhost, na virtualhostech pro HTTP nakonfigurujete přesměrování na HTTPS a na virtualhostech pro HTTPS nakonfigurujete klasický DocumentRoot. Podívejte se na  Name-based Virtual Host Support.

3320

Server / Re:Ako vyriesit www a non www na apache2

« kdy: 02. 06. 2018, 19:17:22 »

Všechny ty domény, tj. web1.ddns.com i www.web1.ddns.com (případně varianty s dvojkou) musíte mít v DNS nasměrované na ten váš server.

Ta pravidla pro přepis nedávejte do .htaccess ale přímo do konfigurace Apache (je to pro server snazší na zpracování).

Ve virtualhostu pro HTTP bych nedával podmínku, že se port nerovná 443, prostě bych přesměroval vše. A zároveň bych tam vše přesměrovával rovnou na správné cílové hostname – aby se přesměrovávalo rovnou http://web1.ddns.com → https://www.web1.ddns.com a ne zbytečně nadvakrát http://web1.ddns.com → https://web1.ddns.com → https://www.web1.ddns.com. V konfiguraci virtualhsota pro HTTPS vám podle mne chybí přesměrování z web1.ddns.com na www.web1.ddns.com.

3321

Vývoj / Re:Java - Načtení JAR přidaného jako dependency v Mavenu

« kdy: 02. 06. 2018, 17:39:27 »

A nebude nakonec nejjednodušší, aby si ten test sahal pro ten JAR přímo do Maven repository?

A to jde nějak jednoduše udělat? Pokud jo, tak by to bylo asi nejlepsi.

Pokud ten soubor máte v lokálním repository, najdete to JARko normálně jako soubor na disku v adresáři uvnitř repository podle groupId, arifactId a verze. Ze vzdáleného repository jde stáhnout protokolem HTTP, vesta opět odpovídá uvedeným „souřadnicím“. V případě složitějších operací (např. potřeba najít poslední verzi) se dá embedovat buď Maven, a nebo pro práci s repository bych doporučil spíš Ivy.

3322

Vývoj / Re:Java - Načtení JAR přidaného jako dependency v Mavenu

« kdy: 02. 06. 2018, 13:14:05 »

JAR si nenačtete z classpath, je to opačně, classpath ukazuje na URL (třeba na JAR). Jedna metoda je, že přes metodu getResource() získáte URL nějakého souboru uvnitř toho JARka, a pak to URL rozdělíte na část k JARu a uvnitř JARu. Přičemž ale URL k souboru uvnitř JAR myslím není standardizované, takže se může v různých implementacích měnit. Druhá možnost je zjistit, zda je příslušné JAR nahrané pomocí třídy URLClassLoader nebo nějakého jejího potomka, a tato třída má přímo metodu getURLs(). Každopádně v obou případech závisíte na implementačních detailech, které se mohou měnit.

3323

Software / Re:chromium 66 opět zprasené rozhraní, ještě horší správa permissions a cookie? UI

« kdy: 01. 06. 2018, 22:51:50 »

proč do háje chromium broswer má s každou verzí tragičtější rozhraní pro správu permissions a cookie na stránce? dříve šlo před "http" kliknout a tam vidět cookeis a dáýt blokovat/smazt. nyní to už jen link na chrome:settings, kde ani  cookies není

Já teda když v Chrome 67 kliknu před „http://“, tedy na „(i) Nezabezpečeno“, rozbalí se mi panýlek, kde jsou mimo jiné položky „Soubory cookie“ a „Zabezpečení webu“. Opravdu to má Chromium jinak?

3324

Distribuce / Re:Nastavení DNS na lokální stanici

« kdy: 31. 05. 2018, 15:48:01 »

Pokud tam používáte resolved (komponenta systemd pro DNS resolving), konfiguruje se to v souboru /etc/systemd/resolved.conf. Viz man resolved.conf.

3325

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 15:45:14 »

Pokud není v cestě NAT, pak není přeci co řešit. Paket dorazí na cílovou adresu. Jediná komplikace nastává právě v případě NATU. A to lze usuzovat z popsané situace v kombinaci s problemem

Já jsem odpovídal na původní dotaz, kde se Jim ptá, jak komunikaci určenou pro jeden server (jednu IP adresu) přesměrovat na jiný server (jinou IP adresu). Což jde udělat NATem přímo přesměrováním paketů, jde to udělat proxy serverem (který v případě UDP bude pro vnějšího pozorovatele nejspíš k nerozeznání od NATu) a jde to udělat aplikační proxy (server data přijme a nějak zpracuje ve vlastní režii a následně je pošle dál).

3326

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 15:31:45 »

Ano, ale to jsou přesně ty helpery. Čisté UDP není jak trackovat, a musí existovat pomocníček, který conntracku poradí, jaký UDP packet souvisí s jakým. Na TCP potřebujete helper, co já vím, jen na aktivní FTP, kdy je potřeba otevřít prostup zpět na ftp-data.

Bez programování modulu jádra prostě UDP kolega neodtrackuje, není se čeho chytit.

Nemyslím si, že by NAT byl nejvhodnějším řešením. Na sledování UDP spojení na základě IP adres a portů není potřeba nic psát, je to už součástí netfilteru, stejně jako to sledování TCP spojení. A i kdybyste chtěl psát vlastní helper, není nutné psát to do jádra, conntrack helpery mohou fungovat i v uživatelském prostoru.

3327

Distribuce / Re:Nastavení DNS na lokální stanici

« kdy: 31. 05. 2018, 15:01:49 »

Co znamená „DNS servery na síťovce“? DNS servery se nastavují pro celý počítač – nejprve se musí převést DNS název na IP adresu, následně se použijí routovací pravidla a teprve tím se určí, kterým rozhraním („síťovkou“) paket odejde.

3328

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 14:59:37 »

Ta druhá varianta je přesně to, co dělá NAT, ale nejsem si jistý, zda je možné nastavit limity linuxového NATu tak, aby držel tabulku spojení po dobu několika hodin. A i pokud by to uměl, nevím, jak se to bude chovat, je to daleko za předpokládaným způsobem použití.

Souhlas, co píšete, jen se to týká TCP. U TCP je navázané spojení a na routeru je jasné, který packet směrem ven souvisí s s předchozím dovnitř. U UDP žádnou takovou možnost nemáte, musíte leda napsat helper, který to z něčeho vyvěští. Buďto, třeba, z kombinace portů, nebo, třeba, z obsahu packetu (L7).

Ne, týká se to obojího. Linuxový NAT nepracuje na úrovni spojení, ale na úrovni paketů. NAT si eviduje tabulku spojení (což nemusí být jen TCP/IP spojení, ale i komunikace založené na UDP, řídící a datové spojení FTP) a ke každému spojení si eviduje údaje o parametrech příchozích paketů a údaje pozměněných paketů. Na základě této tabulky pak jednotlivé pakety transformuje. Spoustu těch helperů pro sledování spojení obsahuje už Netfilter – pro FTP, SIP, DNS…

3329

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 31. 05. 2018, 10:32:31 »

Rossum Elis

Máš s tím zkušenost? Pracuje se s tím dobře a umí to opravdu vyřešit všechny běžné záležitosti, které sekretíčka dělá? Pokud sekretářka stráví nějakým typem faktury 3h měsíčně, myslíš, že se to vyplatí implementovat?

Jinak když mi mamka říkala, jaké faktury zpracovává a jak toho má hodně, tak jsem valil oči, jakou hrůzu ty malé firmy mají. 80% jejich práce by mohly dělat počítače a inf. systém. Ty lidi a firmy mají postupy zaseklé tak v 90. letech, a to už tehda existovalo OCR. Jsou tak 25 let pozadu v tomhletom. Jenže my programátoři jsme pro ně asi prostě moc drazí, západ tlačí ceny nahoru.

Zkušenost s tím nemám, je to veřejné asi tak měsíc. Řeší to jenom ten krok „parsování“ – ono nejde jen o OCR, protože každá faktura vypadá jinak.

Zároveň z těch vašich kroků je to „parsování“ a pak zadání do účetního software asi to jediné, co je typická činnost. Rozesílání e-mailů s poptávkou od jiných firem s fakturací nijak nesouvisí a je to asi pro vás specifické. Převod měn by měl řešit účetní program.

Nevím, zda má Pohoda nějaké API, každopádně napojení na Elis by primárně měli řešit autoři těch účetních programů. Ale třeba FlexiBee má API, takže se dá předpokládat, že i pokud by to neudělali oni, udělá to někdo třetí.

3330

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 31. 05. 2018, 09:40:11 »

Rossum Elis