Příspěvky

271

Server / Re:Kde koupit/jak postavit nový server

« kdy: 27. 08. 2022, 19:47:49 »

Výsledek server za téměř cenu desktopu. Bohužel se ale nevyhnu tomu si to poskládat sám, protože nikdo se neobtěžuje podobné sestavy prodávat jako hotové.

Přece byste se nepřipravil o tu nejzábavnější a nejnapínavější část :-) Ten adrenalin, když poprvé cvaknete vypínačem, a ta úleva, když slyšíte krátký spokojený POST beep.

Zas na druhou stranu, pokud chcete hrotit ECC RAM, tak by nemuselo být od věci, nechat to dodavatele poskládat do nové bedny s tím, že samozřejmě provedou testovací zážeh, a případně dohledají RAMky, které do toho pasujou. Firmy jako CZC nebo SMICRO bohužel asi nebudou montovat nový board do staré bedny, a nějaký menší montér zase nejspíš nebude mít po kapsách několik variant ECC unbuffered RAM. Možná by se někdo z první ligy nechal ukecat, že to ze zvědavosti testnou, jenom jako vrabčí hnízdo na dílně - když od nich takto otestovanou hromádku koupíte (třeba by se dalo dohodnout na nějakém poplatku za takovou službičku). Zkuste jim zavolat, pracují tam živí lidé a vyskytují se tam jako technici nadšenci. Firem, které staví skládané servery podle přání a mají zkušenosti, je tady víc. Napadá mě třeba ještě Abacus nebo Compos. Akorát zase neslibuju, že budou ochotni dodat konkrétní board od AsRocku - zrovna u těchto dvou bych hledal spíš SuperMicro. Možná pokud jste ten AsRock našel u smicro.cz, tak se jich zrovna zkuste zeptat. Tuším jsou tu relativně noví, snaží se urvat kus trhu...

https://www.obchudecek.cz/detail.php?zbozi=V163305_asus-pn51-r7-5700u-1-m-2-slot-2-5-slot-0g-bez-os[/url], tak že to bude fungovat špatně nebo se to pokazí.  Ono to totiž potíže s chlazením předchází tím že to moc tepla nevyrobí a průměrná zátěž  určitě bude pod 30%. 

K pasivním kompům, zejména consumer-grade, chovám značnou nedůvěru. V práci prodáváme průmyslové fanless počítače, a vyskytují se různé konstrukce, některé povedenější, některé méně. Tohle prověří až čas. A taky jsem viděl pár konzumních fanless mini-desktopů, které jsou na tom s chlazením a teplotou obecně hůře, než srovnatelně vybavené průmyslové modely. Jak je to fanless, tak nevěřím ničemu, co jsem neviděl rozebrané, a obecně chovám nedůvěru k fanless kompům s plnotučnými procesory. ATOM apod. se dá, pokud výrobce nešetří na rozměrech (chlazení). Všelijaké ty i3/i5-U dost často pod intenzivní zátěží smrdí jak se potí. A i pokud je fanless komp udělaný dobře, tak se dá chlazení velice snadno pokazit suboptimálním umístěním v prostoru. Pokazit jako že o řád.

272

Sítě / Re:Ukazatel LTE vs. 4G na mobilu

« kdy: 27. 08. 2022, 19:16:17 »

Ještě mě napadá, že já tohle řešil zatím jedině na GSM atd. modemech = krabička nebo modul s rozhraním RS232 nebo USB (s emulací sériové linky), a jaké sítě jsou v doslechu a kam se modem registroval, to se dozvídám pomocí vendor-proprietary AT příkazů, kde jsou používány jednoznačné termíny.
Přikládám screenshot.
Buď modem řekne typ RAN (GERAN/UTRAN/E-UTRA) nebo jiná značka říká GSM/WCDMA/LTE. Modem ve screenshotu neumí 5G RAN "new radio". Příkazy mají "polymorfní" vstupy a hlavně výstupy v závislosti na typu RAN - dost různé množiny atributů.
Zatím co jsem viděl, tak ve výpisu viditelných transpondérů je vždycky vidět číslo kanálu, známé též jako "EARFCN" - toto lze dohledat v tabulce a zjistit tak frekvenci (pokud neznáte sekvence EARFCN podle pásem zpaměti).

Co vím je to že co se vám na telefonu ukáže (4G nebo LTE) je věc operátora, jak to má definované a jak si to u výrobce telefonu(ů) sám definuje. Je to součást "operator settings" které může operátor do telefonu i poslat přes síť.

Tzn. telefon ukazuje string, který koupil od sítě? To je zábavná informace, které věřím tak na 80% :-) Nejsem profík, jenom kutil. Možná taky jak který telefon...?

Jisté je, že telefon může být sítí poňoukán, které RAN a kterého pásma se má držet přednostně, má-li na výběr. Takže by mi dávalo smysl, že pak vykoukne na displeji příslušný "symbol pro typ sítě".
Takže se telefony občas (často?) chytají vysokých frekvenčních pásem, ve kterých je horší plošné pokrytí a fakticky horší dosah. Síť k tomu telefony navádí proto, že je v těchto pásmech méně účastníků = nižší vytížení = větší dostupná datová kapacita. Taky už jsem viděl, že různé telefony s těmito doporučeními zřejmě zacházejí různě, tzn. jabko a vedle jiná značka se chytí klidně každý jiného pásma. A podle toho vlastníci různých značek na střídačku vrní blahem, jak to hezky funguje, nebo nadávají na ustavičné výpadky a slabý signál - v té samé kanceláři, ten samý operátor. A spektrákem jsem je pak viděl, jak při hovoru jedou každý v jiném pásmu. Tuším Samsung má v GUI modul pro explicitní volbu pásma. A nejstabilnější hovory má Jabko (konkrétní starší model) které kašle na doporučení a jede si hlasové hovory v pásmu GSM 900MHz (2G=GERAN) - zaujal mě jeho frequency hopping, viděl jsem to na spektráku poprvé.

273

Sítě / Re:Ukazatel LTE vs. 4G na mobilu

« kdy: 27. 08. 2022, 17:16:02 »

https://www.androidauthority.com/4g-vs-lte-274882/

Tohle je docela zajímavý povídání, má jen jednu nevýhodu. Termín 4G+ se objevuje jen v nadpisu. A mně se u toho O2 právě objevilo i 4G+.

Koukám na to jak bagr na modrej beton...

To já taky. Osobně rozlišuju generace podle technologie rádiové sítě. On už to zmiňoval pan Caletka. 3G = WCDMA/HSPA = UTRAN, 4G=LTE=E-UTRA. 5G = "new radio". Pokud je tu dneska 5G, které jede nad E-UTRA, tak je to IMO zase nějaký marketing.

Vrtá mi hlavou, jestli je zmatenější ten článek na Androidauthority, nebo moje představa.

274

Distribuce / Re:Zpomalení Kubuntu 20.04 při běhu na baterie

« kdy: 27. 08. 2022, 16:46:46 »

HM tyjo. Aby tak BD-PROCHOT...
To by mohlo být zapečené v hardwaru (nebo EC firmwaru), nezávislé na OS.
Zkusit v procesoru zakázat BD-PROCHOT = zakázat vstupní směr tohoto signálu...

275

Server / Re:Kde koupit/jak postavit nový server

« kdy: 27. 08. 2022, 10:53:05 »

Vzhledem k poměru výkon/spotřeba a to že elektřina se mnohonásobně zdražila, kupovat repasované se už nevyplácí.

Není pravda. Jestli novým serverem ušetříte 50W (optimistický odhad) a cena bude 12 Kč za kWh, tak za rok ušetříte cca 5 tisíc (matematika prvního stupně základní školy). Vícejádrový server s low-power procesorem a 16+ GB RAM sežete bezpečně za míň než 10 tisíc. Na m.2 se u serverů, pochopitelně, moc nehraje, protože se počítá s hot-swapem (třeba i ve verzi NVMe, ale to je zas o jiných penězích).

No repasovaný server má obvykle nejen dvojnásobnou spotřebu, ale také poloviční výkon. A když si něco nového pořídím, chci aby to fungovalo ne rok ale spíše 5 a více let.  Zkuste porovnat výkon většiny repasovaných serverů s tímto https://www.obchudecek.cz/detail.php?zbozi=V163305_asus-pn51-r7-5700u-1-m-2-slot-2-5-slot-0g-bez-os  AMD Ryzen 7 5700U   Který má spotřebu v klidu 7.5 W a  při maximální zátěži maximálně několikanásobek.

Jinak díky všem za rady.

Najdu to nejlevnější: https://www.czech-server.cz/dell-poweredge-t320-6-core_x79737.html Cena je včetně paměti, SAS řadiče a ad. Výkon bude dost podobný. Resp. zatím nikdo neví, jaký výkon potřebujete. Jestli bude procesor většinu doby v idle, tak je jedno, jestli má 6 nebo 8 jader. Hlavní rozdíl je v tom, že tohle je skutečný server a ne kancelářský mini počítač, který díky mizernému chlazení při provozu 24/7 odejde v lepším případě během záruční doby, v horším chvíli po ní.

...jako je to opravdu krásnej kousek, ale obavu ze spotřeby potlačuji obtížně :-) Plnotučný E5 Xeon šestijádro s HT na 32nm litografii, včetně 15 MB cache... pravda, udávají tomu pouhých 60W TDP, což na papíře trochu uklidní, taky takt 2 GHz není horentní - ale přesto... Taky je na desce serverový čipset, paměti odhaduji ECC REG... kolik je tam ventilátorů a jakých nemám tušení.

Prostě spotřebou je to každopádně jinde než U-čkové "Core i" nebo Ryzen (mobilní procesory), nemluvě případně o ATOMech. Boardy s onboard ATOMem jsou teď trochu těžko k sehnání... generačně bych doporučil aspoň Apollo Lake, a docela se těším, jestli Intel doopravdy začne prodávat Alder Lake N (zajímavě vypadá taky Alder Lake U).

276

Windows a jiné systémy / Re:Pomalá odezva PC s Windows

« kdy: 26. 08. 2022, 17:37:46 »

Ano ano, "sledování prostředků", jinak též "resmon.exe". Je hloupé, že dnešní noťasy často nemají kontrolku vytížení disku. Jinak pod Windows je snad deset různých věcí, které občas z ničeho nic začnou vytěžovat systém, a pokud je to od Microsoftu, tak se navíc můžou částečně maskovat v task manageru... Defrag, antivirák, Windows Update, indexing service, "optimalizace složek" mailového klienta (vytěsnění prázdného místa po smazaných emailech), někdo tu zmínil .NET apod.

Taky se může stát, vinou bugu v nějakém ovladači nebo v BIOSu (např. v ACPI tabulkách) že se "zblázní interrupt". Pod Windows toto tuším není vidět přímo, zaznamenal jsem zmínky že snad Process Explorer od Sysinternals zobrazí vytížení taky v interruptech, nebo se dá zkusit LatencyMon od Resplendence, kde by se zaseklý interrupt měl projevit vysokou zátěží v DPC (Deferred Procedure Calls - něco jako SoftIRQ pod Linuxem), dokonce by z toho mohl vypadnout ovladač, kterému patří obsluha, kterou to spouští (ovšem není jisté, že zrovna tenhle ovladač za to může, pokud mu to IRQ chodí vinou chybného routování IRQ). Splašené IRQčko dokáže způsobit i zadrhávání kurzoru myši a podobné žertovné příznaky :-)

Ten současný a předchozí počítač - nejsou to noťasy?
Zejména pokud jsou to noťasy, hrozí taky "throttling" při přehřívání.
Zkuste nainstalovat windowsové utilitky Core Temp a ThrottleStop, co Vám k tomu řeknou.

Zajímavý je údaj o aktivaci BD PROCHOT, plus aktuální stav MSR registrů MSR_CORE_PERF_LIMIT_REASONS, MSR_GRAPHICS_PERF_LIMIT_REASONS a MSR_RING_PERF_LIMIT_REASONS - netuším, zda je ThrottleStop už umí, jsou vývojově mladší než klasické IA32_THERM_STATUS a IA32_PACKAGE_THERM_STATUS které obsahují flagy starobylého PROCHOTu.  V zimě jsem kolem toho trochu bádal, mám v šuplíku pár hrubě neotesaných kousků softwaru, které se na to umí mrknout pod Windows, ale nějak nebyl čas to celé zdokumentovat a v kostce publikovat...

Ve chvíli, kdy je to tuhé, jak vypadá frekvence procesoru, udávaná v device manageru v záložce "výkon" nebo tak něco? Nevím jak to vypadá v desítkách/jedenáctkách, naposledy jsem si o to natloukl nos pod Windows 2012 R2 (= cca 8.1). Projevem zádrhele na bázi throttlování může být, pokud je udávaná frekvence bizardně nízká hodnota (v mém případě 220 MHz), přitom počítač se vleče.

277

Server / Re:Kde koupit/jak postavit nový server

« kdy: 26. 08. 2022, 16:52:19 »

Pokud jde o M.2 NVMe, tak mě napadá leda nacpat to do redukcí v PCI-e slotech. Bacha ta redukce je široká x4 = do slotů z1 leda pokud jsou prořízlé.

Našel jsem i čtveřitou nosnou kartu, ale bacha, nemá bridge, vyžaduje motherboard s podporou "PCI-e bifurcation" v x16 slotu.

Edit: RDa byl rychlejší. Taky je tu služebně starší :-)

278

Studium a uplatnění / Re:Rozcestí v kariéře

« kdy: 21. 08. 2022, 08:57:27 »

Tvl co to je bodyshop?

...jinak taky auto-klempírna/lakovna ;-)

279

Sítě / Re:Minimalistická implementace PoE 802.3af

« kdy: 25. 07. 2022, 18:16:57 »

Kvalitou odrušení toho PoE od Číňana si nejsem moc jistý, ostatně to je zřejmé ze schéma zde:

Teď když jsem trochu zaostřil své vetché oči na fotky plošáku, vidím tam "činku" tlumivku na vstupu a druhou na výstupu. Zjevně v sérii s + napájením (mínus = pracovní zem je zřejmě bez tlumivky). Před i za tlumivkou keramika proti zemi. Inu proč ne, jako základní odrušení to není špatné. Jenom bych na primár i sekundár přece jenom přidal nějaký větší koďan - na sekundár polymer, na primár asi malý hybridní polymer, nebo i vlhký hliníkový elyt (Panasonic FR series).
Ale pokud mají výkon do keramiky vyhnaný vysokou frekvencí PWM (pár MHz), tak by se tam ty polymery stejně asi moc neuplatnily a VF ztrátám v trafu+FETu+schottce by to taky neulevilo.

Vnitřní schéma jsem tam nikde nepozoroval, ale viděl jsem několik schémat vnějšího zapojení.
Tam mě zaujal doporučený elyt 470 uF zvenčí na výstupu - dává to jistě smysl. Akorát jak jsem psal výše, pokud je až za odrušovací cívkou, tak už se moc nezapotí.
Taky jsem si všiml, že doporučují přiblokovat "středy odboček z primárů signálového trafa" RC členem proti kostře, kde R je asi 75 Ohmů... inu asi proč ne. Se soufázovou terminací párů to zjevně nemá nic společného, spíš je to způsob, jak zmařit nějakou energii indukovaných rušivých polí.

BTW nechápu, proč je RPI PoE hat tak drahý....

Jsem myslel že taky vyvíjíte HW na kšeft :-)

To je ten s ventilátorem?
Musím říct, že moc nechápu vnitřní schéma. Jako odhadnu PWM kontrolér, ale co z toho je FET na primáru a co je usměrňovač na sekundáru, to bez schématu moc netuším...

Pokud se týče ceny, je tam ten ventilátor, je tam hezkej kondík od Panasonicu, bude tam zřejmě i nějaká dost velká keramika, ta taky není zadarmo... plus samozřejmě přiměřená marže výrobce a distribučního řetězce. A je to přizpůsobené Malině. Nasadíte a jede. Tohle není kus univerzálního čínkého šrotu na Alíku.

280

Sítě / Re:Minimalistická implementace PoE 802.3af

« kdy: 25. 07. 2022, 14:26:39 »

Změř si to, že se ti z těch stepdownů nešíří rušení zpátky do sítě, resp. dej tam pořádnou filtraci.

Přimlouvám se. A přidám jeden konkrétní tip:

Pokud má ten DC/DC měnič primár a sekundár plně oddělený trafem, zaměřte se na možný VF průsak mezi vinutími VF trafíčka uvnitř. Když necháte oddělený sekundár se zátěží volně plovat proti zemi na vstupu, vidíte sekundární zem skopem oproti primární zemi "chlupatou"? Dělají to třeba malé 1-2Wattové převodníky MinMax MAU200 series. Tyto nemají ani zpětnou vazbu ze sekundáru (= stabilizace nic moc) ale především neobsahují blokovací kondík, který by zkratoval ten parazitní VF průsak. Dal bych tak 1n-10n / 400+V mezi primární a sekundární zem. Je to DC-DC, takže nemusíte řešit kompromis proti průsaku 240V 50Hz jako u měničů se střídavým vstupem.

Jak jste (@CPU) posílal odkaz na ten PoE měnič na Alíku, ten vypadá, že blokovací kondík obsahuje - tipuju tu žlutou věc vedle zpětnovazebního optočlenu na rubu desky.

A dál je samozřejmě možnost dát nějaké ty indukčnosti do série s napájením i zemí na vstupu i na výstupu, a kondíky napříč... prostě LC filtr. Dají se koupit i složitější filtry hotové pouzdřené. Akorát bych dával bacha, ať se nerozvlní zpětná vazba měniče v rytmu toho LC filtru, jestli to nemá moc velkou filtrační kapacitu na primáru a sekundáru...

281

Server / Re:Mailová domena na dvou serverech

« kdy: 24. 07. 2022, 20:03:29 »

No já bych řekl, že Vám tento příznak říká dost přesně, kterým směrem dál pátrat :-) Zjevně getmail (mmchdm verze 5 nebo 6 ? ale nakonec je to asi jedno) neodvodí správně adresu odesilatele pro rekonstruovanou SMTP obálku. Pokud se o to vůbec pokusí. Zjevně getmail @ hostname.local je jakýsi default, který v dokumentaci nikde nevidím, ale měl by být dohledatelný v konfiguraci nebo zdrojákách. Buď jsou všechny zprávy doručeny s touto jedinou adresou, nebo si getmail vylámal zuby na hlavičce From: v konkrétní zprávě, pro kterou toto pozorujete.
Klíčové slovo je "envelope sender". V dokumentaci getmailu 5 nebo 6 je tento pojem letmo zmíněn, ovšem není popsáno, odkud se bere, a zda se vůbec getmail pokusí o rekonstrukci.

Fetchmail má toto jasně dokumentováno a definováno:
https://www.fetchmail.info/fetchmail-man.html#interaction-with-rfc-822

Ano, překonal jsem odpor a začetl jsem se do dokumentace Getmailu. A ještě než jsem vůbec našel dokumentaci, resp. "kde to roste", dozvěděl jsem se, že původní getmail v5 zůstal závislý na Pythonu v2, kdežto nový fork Getmail v6 už je portovaný do Pythonu v3. No hlavně že se v dokumentaci pochválili, že Python garantuje odolnost proti buffer overflow útokům, na které je údajně citlivý starý fetchmail. Mimochodem poslední release (patchlevel) fetchmailu je týden starý - žeby se bugy neopravovaly? :-) Tolik na okraj k volbě fetchmail vs. getmail , v širším kontextu C vs. Python... myslím velmi dobrá ilustrace.

Ještě mi vrtá hlavou, že by Dovcot/Pigeonhole "vacation message" extension nemusela reagovat na adresu z obálky, ale z těla zprávy - resp. kolik by dalo práce to dopsat, a jaká to má případně úskalí. Zdá se, že celý Dovecot je napsaný v céčku... aha tady jsou podrobnosti. Doporučuji hledat klíčové slovo "sender". No na první pohled nevidím, co se tam přesně děje, znamenalo by to trochu ladit, já na to čas nemám. Trochu mě mate, k čemu je dobré pole _sender_headers. Možná spíš je směrodatné volání funkce

Kód: [Vybrat]

sender = sieve_message_get_sender(aenv->msgctx);

ale co s tím dál... nechávám koňovi.

282

Sítě / Re:Minimalistická implementace PoE 802.3af

« kdy: 24. 07. 2022, 10:15:58 »

No vidim, ze to asi budu muset prakticky vyzkouset. Moje otazka smerovala k tomu, jestli tady neni nejaky podobny vymyslec kol jako ja, ktery uz timto znovuobjevem prosel.

Konkretne v LLDP jsou nejake bity k PoE, tam treba netusim jestli ty injektory s tim nejak nepracuji.

RDet se zda ma byt cca 25kOhm, ten by asi mohl zustat.

Nejjednodušší splitter, proti tomu Vašemu injektoru, je nakrimpovat si patchcord, ze kterého do slave zařízení nakrimpujete standardně zelený a oranžový pár do RJ45, a modrý a hnědý si vytáhnete mimo do čokolády :-)

Že jsou nějaké bity k PoE v LLDP jsem netušil, díky za doplnění vzdělání. Každopádně čipy které implementují košer 802.3af/at PoE injektor a splitter se vážně baví po drátech jenom tím stejnosměrem, do datového toku na dvou/čtyřech signálových párech nijak nevstupují. Pokud se má PoE PSE neb PD role nějak koordinovat s LLDP, musí to dělat buď firmware MAC čipu nebo spíš celého síťového elementu (switche, koncového zařízení) který se jednak baví LLDP, druhak má nějaký svůj kanál ke "stejnosměrným" PoE čipům (co já vím I2C, SPI, nebo jenom diskrétní dráty) a může s těmi daty ohledně napájení nějak pracovat. Standardně managed PoE switche (PSE) umí ukázat status per port a případně ovládání toho stejnosměru (PoE povolit/zakázat) - k tomu není ani zapotřebí podpora v LLDP...
Popravdě mám podezření, že na "slave" konci (PD) toho down-konvertor o sobě mnoho neřekne, nad rámec diskrétního signálu "power good", takže moc netuším, o čem by se měl skrz LLDP vlastně bavit. Ostatně slave zařízení je buď živé, takže napájení má, nebo napájení nemá, a v tom případě živé není :-) Možná má PD čip představu o teoreticky dostupném příkonu...

283

Sítě / Re:Minimalistická implementace PoE 802.3af

« kdy: 23. 07. 2022, 23:36:04 »

Víte, kdo vynalezl kolo? Češi! Naposledy včera!

Přesně! Je to moje oblíbená zábava.

Jinak, pokud to má být PoE, tak proč nepoužít hotové moduly?
Inspirace je hromada:
...

Zajímavej kousek.
Ono to má galvanické oddělení trafem!

Moc mi nejde pod nos, že na výstupu a koukám i na vstupu je jenom nějaká maličká keramika. Určitě bych přidal ještě polymer. Netuším, co je zač ten elyt na vstupu - na 16 voltů? Žeby filtr napájení pro PWM kontrolér? A hlavní silovou větev filtruje jenom keramika? Navíc kapacita na vstupu nepůjde přidat, protože takový pokus zmaří odrušovací tlumivka...

Jestli správně koukám, má to zřejmě zpětnou vazbu (oddělenou optočlenem) tzn. stabilizace bude fungovat. A má to i potřebné dva graetze už onboard, takže ty čtyři vstupy půjdou připojit rovnou na středové odbočky čtyř primárů "magnetik" - ale mělo by taky stačit přivést jenom natvrdo modrý a hnědý.

Usměrňovač na výstupu vypadá jako dioda (nejspíš schottky) - škoda že tam není synchronní usměrnění FETem, ale to bych za ty prachy asi nečekal. Taky asi proto to má na 3.3V udávaný nižší dostupný výkon na výstupu. Protože něco kolem 10% ztráty udělá jenom úbytek na té schottce na výstupu.

Mile bizardní prvek na té fotce je ulomený kus feritového jadérka na vstupní odrušovací tlumivce. Technicky to v podstatě ničemu nevadí.

Obecně tyhle levné čínské pidi-věci mívají ošizené chlazení. Viz např tady rayerova recenze.

284

Sítě / Re:Minimalistická implementace PoE 802.3af

« kdy: 23. 07. 2022, 19:59:34 »

Na detekční odpor bych se vykašlal... Stejně mám podezření, že je potřeba ho po nějakém timeoutu odepnout. Hlavně ho ale k tomu Vašemu injektoru nepotřebujete.

Souhlasím, že za dvě kila ta věc nebude košer 802.3af/at, tzn. jedná se o "pasivní" (nestandardní, levné) PoE. Na odkazu co jste poslal se netvrdí nic o 802.3af/at, ale píšou, že je to "aktivní" napájení... pozor na zmatení terminologie.
Případně by mě zajímalo, jestli je ten injektor nějak jištěný proti zkratu na výstupu :-)

RJ45 do plošáku se dá koupit buď holý bez signálových traf, nebo včetně signálových traf = "magnetics". Jednou jsem takový konektor "s trafem uvnitř pod kapotou" rozpáral a našel jsem tam prostě čtyři maličké toroidy (= pro gigabit čtyři páry), na každém dvě vinutí. Pokud tenhle "konektor včetně magnetics" nemá vyvedeny středové odbočky z primárních vinutí, tak z toho žádné DC napájení nedostanete, protože vyvedený sekundár už je jaksi oddělený :-)

Ve Vašem případě, pokud nechcete prostě jenom vyvést modrý a hnědý pár natvrdo do jednoho Graetze (a i ten Graetz tam bude "pro jistotu"), můžete se inspirovat třeba v datasheetu čipu PD70201, jak jsou zapojeny dva Graetze na čtyřech párech gigabitového ethernetu - je třeba k tomu použít externí "magnetics" = signálové trafo, které obvykle nabízí na primární straně středovou odbočku z každého vinutí. Na středové odbočce teoreticky není žádná VF střídavina, takže si ušetříte externí výhybku (dalších několik cíveček). Ale pokud máte to zařízení stovkové, tak je asi blbost, dávat signálová trafa na modrý a hnědý pár. Pokud v tom Vašem zařízení není uvnitř hotová kompletní síťovka už se signálovým trafem, tzn. navrhujete plošák a na něj budete osazovat holý PHY čip, budete potřebovat signálové trafíčko (magnetics) aspoň na ty dva datové páry = oranžový a zelený.

Pozor, PoE je stejnosměr! Tohle obyčejným trafem nezpřevodujete! Potřebujete snižující DC-DC měnič. Píšete 5W, koukejte pro jistotu po 10W modelu. Dá se bavit o prostém "buck" konvertoru se společnou zemí, nebo můžete zkusit najít něco s galvanickým oddělením, pokud o to jde. Vyrábí se to nejvíc asi jako hotové moduly pouzdřené v plechovém nebo plastovém kalíšku, zalité epoxidem. Docela hezký sortiment mají v TME, jenom ten jejich vyhledávací filtr je trochu na hlavu. Zrovna teď jsem dosáhl svého následujícím způsobem: každý filtrovatelný parametr má dlouhatánský výčet škrtacích políček, a nad ním hledací okénko. Našel jsem si parametr "výstupní napětí", do hledacího okénka vepsal číslici 5, rovnou se mi omezil seznam checkboxů - ale už jsem v něm dokázal najít checkbox "5V" (přesně). Ten jsem kliknul, následně dole pod filtry je tlačítko "zobrazit výrobky". Jde naklikat víc pravidel a teprve pak "zobrazit", nebo vždycky "zobrazit" a pak přidat další filtr. Pokud zadáte číslo do hledacího okénka filtru, a jenom bouchnete do enteru, automaticky se zaškrtnou všechny vyhovující "checkboxy". A že zrovna u kategorie "vstupní napětí" je jich hodně, to byste se naklikal - protože DC/DC převodníky mají typicky rozsah vstupu od-do, a každý model to má jinak...

285

Server / Re:Mailová domena na dvou serverech

« kdy: 23. 07. 2022, 19:17:08 »

Tak já to zkusím ještě jednou a jinak - podle toho, co jste mi dovysvětlil. Že de facto jediný MX pro example.com je stroj v polské správě, ať už se jmenuje jakkoli - já mu budu říkat třeba pl.example.com. Pro něj to je "vlastní" doména, ve které si resolvuje uživatelské aliasy.

Podle mého je špatně, že na stroji cz.example.com považujete doménu example.com za lokální. V konfiguraci Postfixu podle mého nejde tolik o

Kód: [Vybrat]

mydomain

, jako spíš o její uvedení v

Kód: [Vybrat]

mydestination

a snad

Kód: [Vybrat]

virtual_alias_domains

. Navrhuji, abyste ji v mydestination ani virtual_alias_domains neuváděl. V mydomain by to vadit nemuselo. Mluvím  example.com - subdomény jako cz.example.com nevadí. A bavíme se stále o doručování emailu, že.

Neznám getmail. Je na něm oproti třeba fetchmailu něco vážně super, kromě toho že je getmail napsaný v pythonu? Pravda je, že neznám vlastníma rukama ani fetchmail :-) ale přijde mi takový tradičnější. Svého času jsem o něm dost četl - to bylo cca v minulém století...
Každopádně když taháte maily fetchmailem/getmailem z uživatelských schránek přes POP3 nebo IMAP, a chcete je předávat lokálnímu SMTP serveru (Postfix) k doručení, tak jste tím průchodem skrz POP/IMAP schránku přišel o původní SMTP obálku každé jednotlivé zprávy. Vy víte, kterou schránku taháte, znáte její login a heslo, ale netušíte, na jakou adresu příjemce ta zpráva původně z divokého internetu přiběhla. Tzn. pro předání lokálnímu SMTP démonovi si fetchmail/getmail musí nějakou adresu příjemce "syntetizovat". Jestli správně čtu dokumentaci, fetchmail standardně použije lokálního uživatele, pod jehož účtem byl spuštěn - tzn. nikoli třeba login do vzdálené schránky, ani se nesnaží extrahovat adresu příjemce z hlavičky v obsahu zprávy (což by nakonec možná taky uměl, ale je to v několika ohledech problematické). Každopádně: tuhle lokální adresu lze nastavit. Konkrétně fetchmail se zřejmě musí spustit (samostatný proces) pro každého uživatele zvlášť. Přeskočím teď téma, odkud a jak fetchmail spouštět. Důležité je, že můžete fetchmailu na příkazovém řádku předat mj. adresu příjemce, se kterou má staženou zprávu předat lokálnímu SMTP démonovi (pokud nechcete provést rovnou lokální doručení, což by snad taky šlo). V manuálu fetchmailu k tomu vidím argumenty

Kód: [Vybrat]

-D <domain>

nebo specifičtější

Kód: [Vybrat]

--smtpname <user@domain>

. To pokud by lokální username nevyhovoval. Všimněte si v manuálu zmínky o RCPT TO: - to je konkrétní příkaz v SMTP protokolu, který uvádí adresu příjemce v "obálce" (tzn. to co skrz POP/IMAP neobdržíte).

Jestli příchozí emaily doručovat skrz SMTP nebo rovnou lokáním doručovatelem, a to buď přímo, nebo třeba skrz procmail, to záleží myslím zcela na Vás, na požadovaných vychytávkách a jejich uspořádání=konfiguraci (ještě to lokálně filtrovat proti virům a spamu apod., což lze myslím v Postfixu i třeba v procmailu).

Pokud se týče odesílání, nemusíte hned konfigurovat tvrdého všeobecného smarthosta stylem:

Kód: [Vybrat]

relayhost = pl.example.com

Jednak existuje diferencovanější možnost, opět nikoli pracná, použít explicitní transport pro konkrétní doménu:
/etc/postfix/main.cf :

Kód: [Vybrat]

transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport :

Kód: [Vybrat]

# Specifické pravidlo, ukazuje na server do polska:
example.com       smtp:pl.mydomain.com
# Alternativní zápis při doručování na IP adresu, ať už veřejnou nebo privátní:
#example.com       smtp:[192.168.30.40]
# A nakonec ještě "default" = všechno ostatní ať si Postfix doručí podle standardních pravidel = přímo (nepřehlédněte dvojtečku vpravo)
*                       :

Jo a mimochodem stejně jako mapa virtuálních aliasů (/etc/postfix/virtual) i mapa transportů se musí po úpravě zkonvertovat do binárního "hash" formátu, zde příkazem:

Kód: [Vybrat]

postmap transport

Osobně mám na tyhle konverze napsaný makefile...

Ale nakonec a především se domnívám, že specifické odesílání už ani řešit nemusíte! Protože Postfix na cz.example.com tímto už doménu example.com nepovažuje za "svoji" (mydestination), prostě zprávy komukoli @ example.com doručí standardním způsobem, tj. podle MX záznamu v DNS!