Příspěvky

16

Hardware / Re:Eaton 5E 1100i nepokrývá výpadky

« kdy: 20. 07. 2020, 14:45:09 »

V rozumné míře platí, že čím silnější zdroj, tím lépe. Naddimenzování nevadí, naopak je ve výsledku úspornější (nepřeměňuje energii na teplo v takové míře). Osobně bych nešel po 450 W a nad to bych se rozhodoval podle ceny. Vzal bych nějakou stálici - např. Fortron 500+, je o stovku dražší, než 400W model (pak už cena víc skáče).

Mimochodem, abyste posoudil, jestli na to zdroj stačí, musel byste změřit proud na jednotlivých větvích. Často se stane, že jedna větev je přetížená a zbytek s rezervami. Proto 350W zdroj nemusí stačit, i přestože trvale odebírá 100W. Ošemetné je třeba napájení silnější grafiky a více disků.

Na CZC mají za stejnou cenu 500W a 600W model.
https://www.czc.cz/fortron-hydro-pro-600-600w/276962/produkt
Takže zkusím asi ten 600W, to by mělo stačit snad i na případné přetížené větve.

17

Hardware / Re:Eaton 5E 1100i nepokrývá výpadky

« kdy: 20. 07. 2020, 13:26:27 »

Nejjednodušší bude asi vyzkoušet jiný silnější zdroj, ten co tam je už běží 5 let nonstop, takže nemusí být už uplně v kondici. Máte nějaký tip? Jak silný by měl pro spotřebu do 100W být? Myslel jsem že 350W je dostatečné.

Nejpravděpodobnější se mi jeví, že server (jeho zdroj) je moc háklivý i na to malé zpoždění. Může to být důsledek poddimenzování zdroje, nebo i vada. Nejjednodušeji bych otestoval do serveru vrazit silnější zdroj (350 W je opravdu mrňousek).

18

Hardware / Eaton 5E 1100i nepokrývá výpadky

« kdy: 20. 07. 2020, 13:09:59 »

Ahoj.

Několik měsíců mám novou UPS Eaton 5E 1100i USB. Je k ní připojen malý domácí server se spotřebou cca 75-100W. Bohužel se téměř pokaždé stane, že UPS nevykryje nečekaný výpadek. Při výpadku se server restartuje, znovu naběhne a funguje dokud se napájení neobnoví nebo ho nevypne sám systém. Zajímavé je, že následné výpadky v řádu hodin již UPS pokrývá, jen ten první po dlouhé době ne. Jinak výdrž ups je velmi dobrá a odpovídá hodnotám udávaným výrobcem.
Zajímalo mě, zda nemá někdo podobnou zkušenost. Myslím že UPS není poddimenzována, pro zálohování 100W by měla být dostatečná. Nemůže být problém například ve zdroji serveru? Je tam Seasonic 350W gold.

Díky za případné rady a nápady.

19

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 26. 06. 2020, 13:37:49 »

Podle mne je pro vás nejjednodušší přestat používat ODVR CZ.NICu. Pokud vím, např. žádný z poskytovatelů „4x“ DNS resolverů (Cloudflare, Google, IBM) RFC1918 adresy neblokuje, takže alternativy jsou. Já ODVR CZ.NICu právě kvůli tomu blokování RFC1918 nepoužívám. Protože sice chápu, co se tím sleduje, a že starší doporučení tvrdí, že se RFC1918 nemají objevit ve veřejné DNS, ale v současné situaci, kdy veřejné IPv4 adresy nejsou, považuji privátní adresy ve veřejném DNS za nejmenší zlo – a veřejný DNS resolver by je podle mne neměl blokovat, rozhodnutí by mělo být na koncové síti.

Přesně tak to teď mám nastaveno, CZ.NIC jsem zakomentoval.

Můj dotaz byl míněn obecně, protože do protokolu DNS zase tak detailně nevidím.
Hledal jsem řešení, jak ty blokace obejít a vypadá, že aktuálně je nejjednodušší pouze dané resolvery nepoužívat.

20

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 25. 06. 2020, 19:29:04 »

Můj záměr byl, zda jde knot resolver nastavit tak, že pokud aktuálně použitý resolver DNS název z nějakého důvodu nepřeloží, tak použít jiný ze seznamu definovaných. Takových domén asi nebude mnoho, takže by to nemuselo nijak vytěžovat knot, pokud jde o tohle. Fuknce by mohla být volitelná.
To, že různé veřejné DNS služby blokují různé domény, tomu se asi nevyhneme, ale bylo by dobré to umět nějak vyřešit a nebrat negativní odpověď jednoho resolveru jako definitivní.

Co se týká zmínky o Turrisu, tak nevím o čem je přesně řeč. Píšu z pohledu uživatele Knot Resolveru 5.1 na FC32.

...jak velká šance v různých kombinacích je že posláním na další adresu dostaneme lepší odpověď, aby nešlo skoro vždy o plýtvání.

21

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 25. 06. 2020, 13:01:53 »

Knot Resolver mám nastaven na tyto forwardy...

Kód: [Vybrat]

policy.add(policy.all(policy.TLS_FORWARD({
        { '193.17.47.1', hostname='odvr.nic.cz' },
        { '2001:148f:ffff::1', hostname='odvr.nic.cz' },
        { '1.1.1.1', hostname='cloudflare-dns.com' },
        { '2606:4700:4700::1111', hostname='cloudflare-dns.com' },
        { '8.8.8.8', hostname='dns.google' },
        { '2001:4860:4860::8888', hostname='dns.google' },
})))

Mimochodem, s tímhle se (mi) kresd ani nenačte:

Kód: [Vybrat]

lib/knot-resolver/kres_modules/policy.lua:149: TLS_FORWARD supports at most four targets (in a single call)

Jo to bude tím, že jsem si nic.cz dočasně zakomentoval, takže mám jen 4

Veřejné DNS na localhost se využívá např. při vývoji webů. Pro některé věci je třeba reálná doména, a aby si ji každý vývojář nemusel nastavovat na svém stroji sám, tak se použije veřejná. Blokování localhostu mi přijde zbytečné.

22

Server / Re:Knot resolver a překlad blokovaných domén

« kdy: 25. 06. 2020, 07:14:41 »

CZ.NIC blokuje všechny privátní adresy dle https://www.nic.cz/odvr/ včetně localhostu. U Cloudflare si už nepamatuju, které to byly.

Knot Resolver mám nastaven na tyto forwardy...

Kód: [Vybrat]

policy.add(policy.all(policy.TLS_FORWARD({
        { '193.17.47.1', hostname='odvr.nic.cz' },
        { '2001:148f:ffff::1', hostname='odvr.nic.cz' },
        { '1.1.1.1', hostname='cloudflare-dns.com' },
        { '2606:4700:4700::1111', hostname='cloudflare-dns.com' },
        { '8.8.8.8', hostname='dns.google' },
        { '2001:4860:4860::8888', hostname='dns.google' },
})))

REFUSED to opravdu vrací...

Kód: [Vybrat]

# nslookup fuf.me 193.17.47.1
Server:         193.17.47.1
Address:        193.17.47.1#53

** server can't find fuf.me: REFUSED

Pokud CZ.NIC resolver zakomentuji, fuf.me se přeloží.

Pro forwarding Knot Resolveru jde "najednou" nastavit až čtyři adresy

Tohle se udělá jak? Nebo je to myšleno tak, jak už to mám?

A řešení, že bych vyjmenované domény nastavoval někde natvrdo mi nepřijde správné.

Díky!

23

Server / Knot resolver a překlad blokovaných domén

« kdy: 23. 06. 2020, 21:58:22 »

Ahoj,

CZ.NIC nebo Cloudflare blokují překlad některých domén. Jde nějak nastavit knot resolver, aby refused request byl přeložen jiným resolverem?
Mám nastaveno několik resolverů (CZ.NIC, Cloudflare, Google), pokud je inkriminovaná doména přeložena tím, který jí blokuje, tak je prostě nedostupná.

Díky!

24

Server / Autorizace webu v Apachi (mod_auth_form pro virtualhost s proxy)

« kdy: 09. 11. 2019, 13:01:30 »

Zdravim,
resim nasledujici problem s autorizaci webu, bohuzel jsem nikde nenasel vyhovujici funkcni reseni.
Pozadavky jsou:

• prihlasovani probina na stejne domene webu (idealne stejne adrese), tj. prohlizec muze ukladat zadane prihlasovaci udaje domeny
• prihlaseni prezije vypnuti browseru i vyprseni session, do doby nez je vyvolano uzivatelem

Mam virtualhosty na Apachi, vetsina z nich jsou proxy na jine adresy.

Kód: [Vybrat]

<VirtualHost *:80 *:443>
    ServerName test.example.com
    ProxyRequests Off
    ProxyPreserveHost On
    <Location />
        Order allow,deny
        Allow from all
        ProxyPass http://192.168.1.1:8002/
        ProxyPassReverse 192.168.1.1:8002/
    </Location>
</VirtualHost>

Chtel bych tyto virtualhosty zabezpecit prihlasovanim jmenem a heslem.
Jedine reseni, ktere jsem nasel a nejak omezene funguje je, pomoci AuthType basic. Kde se pred nacteni stranky zobrazi dialog, po zadani spravneho jmena a hesla se pokracuje v jeji nacitani. Tato metoda ale udrzi prihlaseni pouze po dobu behu browseru a to je zasadni problem.

Vydal jsem se tedy cestou AuthType form, coz umoznuje customizovat prihlasovaci stranku, ale hlavne uchovat prihlasovaci udaje v sifrovane cookie po prakticky neomezenou dobu, to je to co potrebuji. Bohuzel navod na https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html pro inline login neni funkcni.

Existuje nejake jine funkcni reseni nebo se nekomu povedlo zprovoznit inline login z mod_auth_form?

Predem diky.

25

Server / Re:Knot Resolver - překlad neznámých adres

« kdy: 08. 10. 2019, 20:51:56 »

Tak primární příčina byla jinde, dhcpd server propagoval

Kód: [Vybrat]

option domain-name "example.com"

a ve spojení s wildcards u domény to pak ve Windows provádělo zmíněné psí kusy 

26

Server / Re:knot resolver - překlad neznámých adres

« kdy: 07. 10. 2019, 21:53:07 »

...zrovna na potvoru existuje v té doméně i wildcard který sežere všechny překlepy jako nalezené...

Je to tak, vypada, ze za to muzou wildcards u domeny serveru...

Kód: [Vybrat]

kresd[20751]: [52359.16][iter]   <= rcode: NOERROR
kresd[20751]: [52359.16][iter]   <= cname chain, following
kresd[20751]: [00000.00][plan] plan 'example.com.' type 'A' uid [52359.17]
kresd[20751]: [52359.16][cach]   => stashed aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbb.example.com. CNAME, rank 030, 30 B total, incl. 0 RRSIGs
kresd[20751]: [52359.16][resl]   <= server: '2606:4700:4700::1111' rtt: 27 ms
kresd[20751]: [52359.17][iter]   'example.com.' type 'A' new uid was assigned .18, parent uid .00
kresd[20751]: [52359.18][cach]   => satisfied by exact RRset: rank 030, new TTL 470
kresd[20751]: [52359.18][iter]   <= rcode: NOERROR
kresd[20751]: [52359.18][resl]   AD: request NOT classified as SECURE
kresd[20751]: [52359.18][resl]   finished: 0, queries: 7, mempool: 32800 B
kresd[20751]: [11239.16][iter]   <= rcode: NOERROR
kresd[20751]: [11239.16][iter]   <= cname chain, following
kresd[20751]: [00000.00][plan] plan 'example.com.' type 'AAAA' uid [11239.17]
kresd[20751]: [11239.16][cach]   => not overwriting CNAME aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbb.example.com.
kresd[20751]: [11239.16][resl]   <= server: '2606:4700:4700::1111' rtt: 27 ms
kresd[20751]: [11239.17][iter]   'example.com.' type 'AAAA' new uid was assigned .18, parent uid .00
kresd[20751]: [11239.18][cach]   => satisfied by exact RRset: rank 030, new TTL 470
kresd[20751]: [11239.18][iter]   <= rcode: NOERROR
kresd[20751]: [11239.18][resl]   AD: request NOT classified as SECURE
kresd[20751]: [11239.18][resl]   finished: 0, queries: 7, mempool: 49200 B

A u bindu to nedelalo, protoze, tam byl pro tuhle domenu (example.com) lokalni zonovy soubor bez wildcards.

Diky!

27

Server / Knot Resolver - překlad neznámých adres

« kdy: 07. 10. 2019, 20:46:59 »

Zdravím.

Nasadil jsem na serveru knot resolver místo bindu. Narazil jsem na problém, že knot překládá i nesmyslné názvy bez domény.

Kód: [Vybrat]

ping asdgdfgetiwoejds

Na PC s Windows, které tento resolver používá jako DNS server, dochází k pingu na ip adresu serveru.
S bindem to ve Windows hodí

Kód: [Vybrat]

Ping request could not find host ...

Konfigurace knotu...

Kód: [Vybrat]

modules = {
        'hints > iterate',  -- Load /etc/hosts and allow custom root hints
        'stats',            -- Track internal statistics
        'predict',          -- Prefetch expiring/frequent records
        'policy > hints',   -- Policy AFTER hints
        'view   < cache'    -- View BEFORE cache
}

-- Cache size
cache.size = 100 * MB

policy.add(policy.all(policy.TLS_FORWARD({
        { '1.1.1.1', hostname='cloudflare-dns.com' },
        { '2606:4700:4700::1111', hostname='cloudflare-dns.com' },
        { '193.17.47.1', hostname='odvr.nic.cz' },
        { '2001:148f:ffff::1', hostname='odvr.nic.cz' },
})))

V čem může být problém?

Předem díky.

28

Odkladiště / Re:Kvalitní kancelářská židle do 2-3 tisíc

« kdy: 23. 09. 2019, 09:00:30 »

Bacha na tyhle plastove bederni operky za sitovymi operaky. Sedim ted na jedne hodne podobne (https://kancelarska-kresla.heureka.cz/antares-mija/) a po hodine to desne tlacilo do zad. Musel jsem udelat tuning a operku nahradit polstarem. Bez vyzkouseni je to tezke rozhodovani.
Jeste muzu nabidnout alternativu https://kancelarska-kresla.heureka.cz/managi-f-3000/, kterou si kupoval kolega a je s ni pry moc spokojen.

A co, prosím vás, říkáte na tuto kancelářskou židli?

https://kancelarska-kresla.heureka.cz/b2b-partner-essen/

Nikde nemohu najít recenze.

29

Sítě / Re:Android v IPv6 only siti

« kdy: 13. 09. 2019, 22:55:09 »

Tak se ukázalo, že na tabletu Huawei funguje IPv6 only (i bez DNS64) bez problémů. Bylo nutné restartovat zařízení, aby se smazala DNS cache. Problém přetrvává pouze na Xiaomi (MIUI 10, Android 9).

30

Sítě / Re:Android v IPv6 only siti

« kdy: 12. 09. 2019, 19:09:39 »

No v každém případě bych doporučoval ještě vyzkoušet chování s DNS64, například tak, že adresu DNS serveru anoncovanou v RDNSS použiješ některou z těchto: https://go6lab.si/current-ipv6-tests/nat64dns64-public-test/

Při použití Jool DNS64 jako RDNSS překlad funguje. ipv6-test.com ukazuje DNS4+IPv6 i DNS6+IPv6 Reachable. Úplně tedy nerozumím, jak to na pozadí funguje, musím dostudovat, ale alespoň částečný úspěch. Je vidět, že plná podpora IPv6 na zařízeních není ještě samozřejmost. Díky za rady!