Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
).
...
mod_rewite ? ten jsem párkrát použil, ale jen v opravdu jenoduchych pravidlech...
No, mod_rewrite ani mod_vhost vám pravda moc nepomohou. Máte-li stav "www.mujserver.cz/uzivatel1" až "www.mujserver.cz/uzivatelN" a chcete to převrtět na "uzivatel1.mujserver.cz" až "uzivatelN.mujserver.cz", pak musíte postupovat takto:
Nejprve je nutné upravit DNS záznamy domény mujserver.cz tak, aby uzivatel1.mujserver.cz až uzivatelN.mujserver.cz byly CNAME na kanonické jméno toho webserveru, na němž to celé běží. (Podotýkám, musí to být CNAME záznamy. Existují prasata, která vyrobí 150 A záznamů na jednu IP adresu, a konzistenci A záznamů s PTR záznamy mají zřejmě u prdele. Proto se to korektně řeší přes CNAME.)
No a následně toho vašeho Apače naučíte virtuální servery, což je úplná trivialitka, stačí v konfiguráku dostatečně hodněkrát napsat <VirtualHost ...>. Dokonce nemusíte ani číst dokumentaci (to je přece jenom moc práce, seznámit se s produktem, který používám), bude stačit nakouknout na vzorový httpd.conf, nejspíš to dáte dohromady i podle něj.
A kromě toho, když už se o tom bavíme, titulek "doména 3. řádu" je věcně úplně špatně, protože nejde o žádné domény 3. řádu, alébrž o mnoho (virtuálních) serverů v doméně 2. řádu (za předpokladu, že mujserver.cz je doména 2. řádu, spory na téma počítání od nuly nebo jedničky mě nebaví).
Pokud totiž začnete mluvit o doméně "o řád vyšší, než je ta moje stávající", tak to podle běžně uznávané terminologie znamená autonomní nameserver této domény a autonomní řešení reverzů. To je docela hodně jiné téma.
Ano, omlouvám se, to je samozřejmě pravda. Nicméně, začátek celé záležitosti je v DNS, to jaksi okecat ani ob něco_modovat nejde.
* CNAME www.
(RFC 1912, sekce 2.7)
Mně na tom nic pěkného nepřijde a 150 CNAME záznamů v DNS mi nepřipadá ani trochu jako něco divného:
# grep CNAME /var/named/zone/jednadomena.cz | wc -l 1417A dokonce mi ani nepřijde nic zvláštního na tom, mít v konfiguraci Apache 150 sekcí <VirtualHost>. Je to jenom otázka toho, jestli je mi úplně jedno, co můj server dělá, anebo jestli se starám o to, aby dělal přesně jenom to, co dělat má.
Ne každý CNAME existuje kvůli virtuálnímu webu, sekcí VirtualHost je v konfiguráku Apache jenom 329
. Želbohu, není to celé podle jednotného mustru, takže ten automatizující postup nejde použít.
To je jenom otázka času... 
mujserver.cz nijak neovlivníte to, na jakou IP adresu se budou překládat jména typu uzivatel.mujserver.cz - takže pokud byste udělal jen to, co jste napsal, fungovat to nebude. Na tom trvám, přes to vlak nejede. Pokud máte v tom zónovém souboru ještě něco jiného, pak je docela dobře možné, že to fungovat bude, ale rozhodně ne zásluhou toho, co jste napsal…
v CNAME záznamu mám *.mojedomena.cz na www.mojedomena.cz :)To bych sem radsi nepsal...
pokud máte jiný nápad, jak všechny dotazy na "mojedomena.cz" směrovat na můj server, rád se přiučím a možná i opravím to co jsem spáchal doposudJa ne...
Nějak mi pořád uniká, co je špatného na tom, mít pro každý virtuál jeden CNAME záznam. Kolik těch virtuálů týdně nastavujete? Desítky, stovky, tisíce? I kdyby tisíce, tak snad máte nějaký evidenční systém, co kde kdo a jak, ne? A pokud jej máte, tak není až tak těžké z jeho databáze generovat i záznamy do DNS, ne?
Já se přiznám, že naprosto a úplně nechápu přístup "* CNAME www.mojedomena.cz". Teď nejde o korektnost síťových protokolů, ale jde mi o čistě faktografickou stránku věci. Snad na tom serveru provozuju konečnou (a mnou administrovanou) množinu webů. A tom okamžiku si snad spojím administraci spojenou se zakládáním uživatelů, virtuálů, ftp přístupů a podobně i s administrací DNS, to přece není žádná práce navíc. Anebo na tom serveru provozuju něco, a sám nevím co? No pokud je to tak, pak je další debata zbytečná.
Chápejte, mi nejde o "purismus" podle RFC, ale jde mi o "technický přístup k věci". A ten mi jednoznačně velí definovat v DNS přesně a právě jenom to, co existuje. Kdyby pro nic jiného, tak proto, že ping jakákolivsračka.mojedomena.cz mi bude nepochopitelně pingat. A to bych třeba já opravdu nesnesl.
edu viděla něco úplně jiného. Jestli je vám tohle málo, pak to bude opravdu těžké…
Jinak už z vašeho druhého odstavce je patrné, že máte jen velmi mlhavé tušení, jak funguje DNS, a prakticky nulové povědomí o tom, co přesně znamená wildcard záznam. Pak je ale asi zbytečné snažit se vám něco vysvětlovat…
Aha, ten přístup znám. A modrá, hnědá a zeleno-žlutá jsem přece jenom barvy, té mědi je to jedno, v čem je obalená, ne? S váma bych fakt chtěl mít dvojdomek.
Už jsem to psal. Špatného je to, že úplněnaprostocokoliv.mojedomena.cz se bez potíží převede na IP adresu. ping jsemnapsalnějakoukravinu.mojedomena.cz bude pingat. Já třeba docela často někam pingám kvůli diagnostice, tu a tam se překlepnu v názvu, a ping mi odpoví "unknown host". Kdybych ovšem měl v DNS tu zvrácenou hvězdičku, tak se jakákoliv hovadina resolvne na IP webserveru a jakýkoliv překlep mi bude tajemně pingat.
V tom "nicneříkajícím RFC" hovoří navíc o problémech s "domain searching", což je věc, kterou zajišťuje direktiva search v /etc/resolv.conf. Zjednodušeně řešeno, je to automatické doplňování domén v DNS dotazech - nastavím třeba search mojedomena.cz jinadomena.cz nebo tak něco, a pak můžu zadat host cosi - hledá se cosi, cosi.mojedomena.cz a cosi.jinadomena.cz, dokud se něco z toho nenajde. Featura, kterou třeba taky docela používám - a pokud by mi první nameserver díky zhůvěřilé hvězdičce na každou moji pitomou otázku vrátil IP adresu webserveru, tak je mi to k ničemu.
To nastavení je prostě matoucí - vzbuzuje dojem existence věcí, které neexistují, a to je špatně.
BTW, on vam tu hvezdicku nekdo vnucuje? Kdyz vam nevyhovuje, tak ji nepouzivejte, ale co takhle nechat ostatni lidi zit? Jinym zase nevyhovuje, aby kvuli kazde pitome subdomene, kde potrebuji na pul hodiny neco otestovat, museli menit DNS zaznamy.
Tiskni
Sdílej: