Příspěvky

181

Distribuce / Re:Raspberry - spuštění skriptu před vypnutím

« kdy: 04. 09. 2019, 13:46:55 »

https://www.freedesktop.org/software/systemd/man/systemd-halt.service.html

182

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á.

183

/dev/null / 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.

184

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.

185

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.

186

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.

187

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 

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.

188

Hardware / Re:Wi-Fi karta do PCI Express pro SoftAP s podporou standardu AC

« kdy: 23. 07. 2019, 10:08:25 »

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.

189

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.

190

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.

191

Hardware / Re:Třípólova sluchátka šumí se čtyřmi póly na telefonu

« kdy: 29. 06. 2019, 13:04:29 »

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ě.

192

Sítě / Re:Linuxový router a IPv6 forwarding

« kdy: 20. 06. 2019, 09:58:14 »

...Nebývá obvyklé, aby ISP router routoval celou /56 jako lokální sít, obvykle z ní vybere první /64, která bude sloužit jako spojovačka...

Měl jsem za to, že tohle se řeší linkovou adresou (fe80), aby nedocházelo k zbytečnému použití rozsahu a zanášení bordelu do něj. (Alespoň T-Motýle to tak má.)

Jenže router ISP obvykle neví, jestli za ním bude jen další router uživatele, nebo přímo nějaká koncová stanice. Pokud by na svém vnitřním rozhraní nebyly nastaveny žádné veřejné adresy, přímo připojená zařízení by nefungovala. Proto se neočíslované spojovačky používají jen tam, kde je zcela jisté, že je dané místo pouze spoj mezi routery. A i tak spousta lidí preferuje snadnější debuggovatelnost veřejných adres. Třeba DSL od O2 má i na WAN straně domácího modemu veřejný prefix /64.

193

Sítě / Re:Čtyřportová LAN karta mění MAC adresy

« kdy: 20. 06. 2019, 09:39:30 »

Děkuji za rady, ale 'net.ifnames=0' 'biosdevname=0' už mám v /etc/default/grub delší dobu a názvy portů eth0-3 mezi sebou nepřeskakují, protože na nich mám statické IPv4 a ty drží.

Tak jasně, že na těch názvech eth0 až eth3 drží IP adresy, protože IP adresy jsou přiřazeny k názvům. To, že se názvům pravidelně mění MAC adresy skutečně bude nejspíš znamenat, že se ve skutečnosti mění i porty, které jsou jednotlivým názvům přiřazeny.

Přechod na predikovatelné názvy, problém vyřeší, stejně tak přejmenování pomocí udevu, jen pozor:

Kód: [Vybrat]

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:00:00:01", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:00:00:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:00:00:03", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:00:00:04", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

Přejmenování do stejných názvů už není podporováno, ten kód nikdy dobře nefungoval a náhodně produkoval síťové karty pojmenované ve stylu rename_eth2. Když ale do pravého NAME= vložíte jakékoli jiné jméno než eth a číslo, aby bylo jisté, že dané cílové rozhraní v době přejmenování nebude existovat, bude to fungovat spolehlivě.

194

Sítě / Re:Linuxový router a IPv6 forwarding

« kdy: 19. 06. 2019, 12:55:08 »

(isp router) -- ([aaaa:bbbb:cccc:dd00::/56] linux router [aaaa:bbbb:cccc:dd01::/64]) -- (routovaná síť)

Prosím upřesni adresy. Nebývá obvyklé, aby ISP router routoval celou /56 jako lokální sít, obvykle z ní vybere první /64, která bude sloužit jako spojovačka. Tedy nějak takto:

Kód: [Vybrat]

(isp router: aaaa:bbbb:cccc:dd00::1/64 -- aaaa:bbbb:cccc:dd00::2/64: linux router: aaaa:bbbb:cccc:dd01::1/64 -- (routovaná síť)

V každém případě v ISP routeru ještě musí existovat cesta k podsíti aaaa:bbbb:cccc:dd01::/64, tedy záznam ve směrovací tabulce ve tvaru:
aaaa:bbbb:cccc:dd01::/64 via aaaa:bbbb:cccc:dd00::2.

Pokud je router od ISP trochu normální, takováhle cesta se v něm automaticky vytvoří, požádáš-li o prefix pomocí DHCPv6. Měl by ale umožňovat aspoň statickou konfiguraci.

195

Sítě / Re:IP kamera do internetu (jaký sled barev RJ45?)

« kdy: 13. 06. 2019, 10:00:33 »

Zdravím, jaký sled barev mám dodržet při připojení IP kamery přímo k routeru? Chci k ní mít přístup i zvenčí. Mám 20m kabel, udělal jsem ten standardní sled oranžová, zelená, modrá, zelená a hnědá ale přes tenhle kabel se ke kameře nepřipojím. Mám tu jiný krátký kabel, nedokážu rozeznat, jak má barvy, ale s ním se ke kameře připojím bez problému. Zkusil jsem ten dlouhý kabel vzít a připojit s ním notebook k internetu a normálně internet běžel, u kamery ale nefunguje.

Žádné jiné zapojení než T568B nedává smysl. Prakticky všechna zařízení dnes umí Auto MDI/MDI-X. Předpokládám, že problém bude ve špatném krimpování konektorů, kdy například všech 8 drátů není vodivě spojeno. Pokud má notebook jen Fast Ethernet a kamera Gigabit, může to být příčina.