reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ondřej Caletka

Stran: [1] 2 3 ... 43
1
Dobry den.

Rad bych pozadal o radu. Presouvam servery z fyz. zeleza do virtualizace. Narazil jsem na neprijemny problem. Pokud mam u sitove sluzby definovanu adresu, na ktere ma poslouchat, casto se stava, ze prestoze v definici systemd unity je

After=sysinit.target network.target basic.target system.slice systemd-journald.socket

sluzba nenastartuje, protoze sitove rozhrani v ten moment jeste neni k dispozici.
Na tohle téma je poměrně obsáhlý text v dokumentaci systemd. Jinak obecně, ten nejefektnější způsob, jak toto vyřešit, je použít režim soketové aktivace, kdy soket vytvoří přímo systemd a teprv až na něj přijde spojení, nastartuje příslušného démona. To ale vyžaduje podporu na straně démona. Spousta démonů takovou podporu už má.

2
Sítě / Re:Android v IPv6 only siti
« kdy: 12. 09. 2019, 09:20:55 »
Co vím, tak NAT64 tu není. V prohlížeči přístup na lokální web přes IPv6 i na https://[2606:4700:4700::1111]/ funguje normálně, takže spojení existuje, jen nepřekládá DNS :/
Aha, zajímavé. To vypadá, že někteří výrobci skutečně podporu pro IPv6 DNS z Androidu odstraňují.

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/

3
Sítě / Re:Android v IPv6 only siti
« kdy: 11. 09. 2019, 20:19:33 »
A máš v té síti i NAT64? Protože je možné, že to zařízení se odpojí, když se mu nepovede připojit k nějakému IPv4-only serveru výrobce.

4
Sítě / Re:Android v IPv6 only siti
« kdy: 10. 09. 2019, 17:21:09 »
Zdravim.

Podarilo se nekomu pripojit Android zarizeni do IPv6 only site?

Ano, používám to tak běžně. RDNSS by mělo stačit, DHCPv6 beztak Android nepodporuje. Nepoužívám ale radvd, mám odhcpd z OpenWRT.

6
Odkladiště / Re:Streaming TV do webu
« kdy: 27. 08. 2019, 15:54:55 »
Tohle je obecně právní oříšek, se kterým si lámou hlavu i soudy. Opravdu si myslíte, že vám na fóru někdo může poradit?

Tak já to zkusím. Podobnou kampaň pod heslem „odkaz není zločin“ kdysi spustila Pirátská strana. Orgánům činným v trestním řízení to stačilo k zahájení trestního stíhání. Je klidně možné, že u soudu nakonec takové stíhání neskončí, ale že by podobná činnost byla zcela bez rizika, to se říct nedá.

7
Odkladiště / Re:Auta na baterky - má to budoucnost?
« kdy: 27. 08. 2019, 14:31:38 »
Navíc výfuk to má v elektrárně.
Někdo někdy spočítal, že na výrobu jednoho galonu benzínu z ropy se spotřebuje zhruba 5 kWh elektřiny, což v elektrickém autě vystačí na ujetí přibližně stejné vzdálenosti, jakou ujede benzínové auto na onen jeden galon. Pokud bychom tedy dokázali přes noc všechna benzínová auta přestrojit na elektrická a ukončit výrobu benzínu, světová spotřeba elektřiny by se dramaticky nezměnila, nezměnily by se tedy ani její účinky na prostředí, jen by ubylo exhalací benzínových aut.

Do te doby nez budou odstaveny vsechny tepelne elektrarny, tak bych zmenil nazev na uhlomobil, at vime z ceho ta energie opravdu je.
Dokud bude v síti aspoň jedna fotovoltaická elektrárna, změnil bych název na solární auto, ať víme, z čeho ta energie opravdu je.

8
Sítě / Re:IPv6 Poda
« kdy: 26. 08. 2019, 09:44:42 »
Kód: [Vybrat]
ipv6 dhcp-client print detail
Flags: D - dynamic, X - disabled, I - invalid
 0    interface=ether1-gateway status=bound duid="0x00030001d4ca6ded1f87" dhcp-server-v6=fe80::f61d:6bff:fed4:31eb request=address,prefix
      add-default-route=no use-peer-dns=yes pool-name="poda" pool-prefix-length=64 prefix-hint=::/0 dhcp-options=""
      prefix=2a00:xxxx:xxxx:a8b4::/64, never address=2a00:xxxx:xxxx:a8b4::5, never
Tohle je velmi zajímavé. Znamená to, že ISP ti přiděluje prefix /64 (aargh!) a zároveň adresu z toho stejného prefixu. To mi nepřipadá jako úplně ideální nastavení. V každém případě protože máš jen jeden prefix /64, nemáš jak oadresovat WAN linku, takže ta musí zůstat bez veřejných adres.

Čili nastavení DHCP klienta změň, aby žádal pouze o prefix, ne o adresu:
Kód: [Vybrat]
/ipv6 dhcp-client set 0 request=prefix add-default-route=yes
Ruční záznamy ze směrovací tabulky smaž, nech tam jen default route, kterou tam vloží DHCP klient.

No a konečně na rozhraní bridge-local nech přiřadit adresu z poolu (všechny ostatní adresy předtím smaž):
Kód: [Vybrat]
/ipv6 address add from-pool=poda interface=bridge-local address=::1
Nastavení ND nech výchozí:
Kód: [Vybrat]
/ipv6 nd
set [ find default=yes ] advertise-dns=yes advertise-mac-address=yes disabled=no hop-limit=unspecified interface=\
    all managed-address-configuration=no mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m \
    ra-lifetime=30m reachable-time=unspecified retransmit-interval=unspecified
/ipv6 nd prefix default
set autonomous=yes preferred-lifetime=1w valid-lifetime=4w2d

Takhle by to mělo fungovat. Na WAN straně bys neměl vidět žádné veřejné adresy, na LAN straně bude na routeru tvůj prefix končící ::1. Ostatní zařízení si vylosují adresy ze stejného prefixu.


9
Sítě / Re:IPv6 Poda
« kdy: 23. 08. 2019, 21:39:45 »
Pošli pokud možno nefiltrovaný výpis těchto příkazů:
Kód: [Vybrat]
/ipv6 dhcp-client print detail
/ipv6 pool used print detail
/ipv6 route print detail

Bohužel zkracování v podobě „2a00../64“ činí jakoukoli analýzu nemožnou. Chceš-li adresu znečitelnit, vyhvězdičkuj druhý a třetí blok, zbytek je důležitý pro pochopení situace.

10
Hardware / Re:Adaptér HDMI (Display Port) → USB-C
« kdy: 19. 08. 2019, 17:09:14 »
Já to chápu tak, že ten protokol je normální DisplayPort, takže zkonvertovat to by nemělo být až tak složité. Že tam nějaká logika bude muset být, s tím počítám – a ten adaptér od Delinku v sobě nějaký čipset má.
Ano, tak to nejspíš bude, ostatně i převod HDMI na DP není úplně triviální, HDMI je jen zdigitalizované analogové video, takže jde o soustavný proud bitů popisující jednotlivé pixely, zatímco DP je spíš něco jako síťová karta, kterou proudí pakety.

Čeho bych se ovšem bál je toto:

Díky, ten konvertor video → USB-C je pro mne nejdůležitější, konverze HDMI → DP by měla být bezproblémová a doplnit k USB-C napájení snad také půjde (zatím jsem to tedy nenašel, ale předpokládám, že to s Power Delivery bude naprosto běžný use case – chci přes USB-C konektor připojit periferii, ale zároveň přes něj potřebuju notebook napájet – Delock takové USB huby má).

Protože ano, je běžný use case připojit k notebooku hub a zároveň skrz hub notebook nabíjet, ale bude velký problém sehnat takový hub, který takto dokáže přenést některý z alternativních modů. Už jenom sehnat hub, který bude mít downstream konektor typu C bude problém (většinou mají typ A), jsem si ale téměř jist, že přes žádný z nich neproleze alternativní režim.

11
Hardware / Re:Nahradenie tabletu netbook-om s linuxom
« kdy: 25. 07. 2019, 10:18:42 »
Pro tyhle účely používám Chromebook – je to bezúdržbové zařízení, které dostává nejnovější upgrady ještě víc než 5 let (!) po datu výroby. Teď navíc s podporou aplikací pro Android a linuxových kontejnerů (LXD) se to dá používat i na mnohem víc, než jen brouzdání po webu a SSH. Můžete tam třeba spustit Firefox  ;D

Samozřejmě, pokud máte problém s Google, není to zařízení pro vás. Já jsem nedávno pořídil starší ASUS Chromebook Flip C101PA za cca. 3000 Kč a jsem velmi spokojen.

12
Nic takového podle mě neexistuje. Pokud chceš souběžný provoz v pásmech 2,4 a 5 GHz, je potřeba mít dvě karty. Bez problému funkční jsou třeba ty, co jsou vestavěné v Turris Omnia: Compex WLE900VX pro 802.11ac a Compex WLE200N2 pro 802.11n.

13
Sítě / Re:Jde vám www.seznam.cz po IPv6?
« kdy: 15. 07. 2019, 09:07:56 »
Děje se to přímo na koncovém bodu tunelu, nebo až na dalším počítači? Skutečně to vypadá na problém s nefunkční Path MTU Discovery. Doporučuji sledovat wiresharkem, co chodí v tunelu. Pokud to občas chodí a občas ne, je možné, že někdo v cestě mezi koncem tunelu na straně HE a Seznamem částečně filtruje ICMPv6 zprávy.

Jako workaround pro TCP spojení by mělo pomoci na odchozím směru nakonfigurovat MSS clamping na hodnotu MTU tunelu, nebo snížit hodnotu MTU v celé síti.

EDIT: Na mém koncovém bodu tunelu od HE to funguje bez problému.

14
Server / Jak dohlížet zdraví serveru Dell
« kdy: 03. 07. 2019, 20:21:48 »
Dlouhá léta používáme servery Dell/Dell EMC. Zdraví hardwaru (zdroje, větráky, teploty, firmwary,…) dohlížíme pomocí pluginu check_openmanage, který je pomocí NRPE spouštěn centrální Icingou.

Problém je, že tenhle plugin potřebuje ke své činnosti balík softwaru zvaný Open Manage Server Administration. Ten je oficiálně dodáván pro RedHat a SUSE, neoficiálně pro Ubuntu. My používáme většinou Debian, kde poslední verze OMSA vyšla pro Debian Jessie, ale ještě se dala nainstalovat na Debian Stretch. Na Debianu Buster už se tomu moc chodit nechce.

Takže řeším, co s tím. Teoreticky by mělo jít dohlížet všechny důležité věci přímo v OOB rozhraní iDrac pomocí SNMP, nezávisle na operačním systému serveru. Než kolem toho rozjedu vlastní výzkum, zajímalo by mě, jestli to tak někdo už provozuje, případně jestli má zkušenosti s nějakou třetí cestou, která mě zatím nenapadla.

Předem díky za odpovědi.

15
někdy jsou ty tlustý části na jacku různě široký a nejde to správně zasunout do telefonu (naráží na okraj telefonu nebo na různé plastové protinárazové obaly), není to ten případ?

Myslim, ze ne. Vypada to, ze je to tam az nadoraz.
Schvalne sem ted zkusil s tim trochu hybat a je to divny...
Kdyz to malinko vytahnu tak se ztrati sum, ale i vokaly... To vubec nechapu.
Hrajou nastroje, ale zpev zmizi. A pritom je to stereo a vokaly jsou na obou kanalech.
Asi nejaka ducharina.

Když hrajou sluchátka bez vokálů, znamená to, že se ti odpojila zem. Sluchátka jsou pak zapojena v sérii: výstup levého kanálu - levé sluchátko - plovoucí zem - pravé sluchátko - výstup pravého zesilovače. Takže proud sluchátky teče jen v případě rozdílné okamžité hodnoty výstupního napětí pravého a levého kanálu. Protože vokály (a bicí) se ve stereofonii typicky umisťují doprostřed a hrají tedy z obou kanálů souhlasně, mění se i okamžitá hodnota napětí obou výstupů souhlasně a žádný zvuk tedy negenerují.

Jinak s jacky je hlavně potíž v tom, že jsou dva druhy zásuvek. Jedny mají doraz vymezující maximální zasunutí a vzdálenost jednotlivých kontaktů odměřují od špičky, jiné doraz nemají a vzdálenost odměřují od kořene. Ten druhý typ zásuvek je asi častější, proto velmi často pomáhá nepatrně povytahovat konektor.

Aby to nebylo tak jednoduché, u čtyřpólových jacků existují dvě varianty zapojení:
  • levý, pravý, mikrofon, zem – tradiční varianta, používaná v éře tlačítkových telefonů Nokií a podobnými.
  • levý, pravý, zem, mikrofon – varianta, se kterou přišel iPhone a postupně tu předchozí převálcovala.
Dnešní telefony by měly umět autodetekovat obě varianty, tedy přinejmenším ty, které podporují analogová sluchátka přes USB-C, tam se totiž orientace země a mikrofonu mění podle otočení konektoru. Pro zapojení třípólových sluchátek by to nemělo mít vliv, mikrofon se tak jako tak zkratuje, rozdíl variant se projevuje hlavně při zapojení čtyřpólových sluchátek do třípólových konektorů, kde hraje roli jak je řešen kontakt země.


Nicméně k původnímu dotazu ohledně šumícího levého kanálu je to skutečně záhada. Zřejmě tam někudy zatéká proud pro napájení mikrofonu, ale jak přesně, to si nedokážu představit. Je ale klidně možné, že se to opraví softwarově.



Stran: [1] 2 3 ... 43

reklama