Příspěvky

526

Sítě / Re:Vzdálené připojení k řídící jednotce

« kdy: 30. 11. 2012, 08:55:40 »

asi jsem nasel problem... vypada to, ze mi poslali spatnou verzi jednotky, ktera neobsahuje podporu TCP IP protokolu... achjo, tak to budu muset jeste overit.

A když neobsahuje podporu TCP/IP protokolu, jak je možné, že se k ní z lokální sítě webovým prohlížečem dostaneš?

Začíná to být víc a víc záhadné.

527

Distribuce / Re:Pomalé otvírání stránek v Arch Linuxu

« kdy: 30. 11. 2012, 08:50:36 »

Pokud vam drhne DNS, zkuste si rozchodit pdnsd nebo DNSmasq jako caching DNS.

Zrovna DNSmasq bych jako caching DNS nedoporučoval, protože nemá cache, což je u caching serveru poměrně zásadní problém. Mnohem lepší je použít Unbound, instalace na dvě minuty a jako bonus navíc DNSSEC. Ale původní tazatelův problém to s největší pravděpodobností stejně nevyřeší.

528

Distribuce / Re:Pomalé otvírání stránek v Arch Linuxu

« kdy: 30. 11. 2012, 08:47:37 »

Zmenil som /etc/resolv.conf a dal som namiesto dns, ktory mi pridava sam network manager ip google dns: 8.8.8.8 a ide to lepsie....ale rychlost na speedmetroch v porovnani s windows je horsia....takze je mozne ze to robi to ipv6.
Viete poradit ako to vypnut v archlinux? kedze to je priamo v kerneli? a taktiez pre dhcpd?

IPv6 se dá vypnout v pomocí

Kód: [Vybrat]

# echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Ale nic se tím nejspíš nevyřeší, Windows 7 mají IPv6 taky zapnuté.

529

Distribuce / Re:pomale otvranie stranok, internetu na archlinuxe....

« kdy: 29. 11. 2012, 12:46:46 »

Ked pustam testy(speedtest), alebo otvaram stranky internet mi funguje pomaly...celkovo aj odozva je zla. Toto pocitujem ako som preinstaloval archlinux na novy - so systemd. Neviete poradit? kde by mohol byt problem?

Křišťálová koule se nám trošku mlží, takže by to chtělo nějaké další informace o typu připojení, o jmenovité rychlosti, o tom, jestli se to děje jen v archlinuxu, nebo i v ostatních OS. A v neposlední řadě trochu kvantifikovat slovo „pomaly“. Pro někoho to může být sekundové zdržení, pro jiného třeba 30 sekund.

530

Sítě / Re:Vzdálené připojení k řídící jednotce

« kdy: 29. 11. 2012, 11:11:43 »

takhle pres web rozhrani se na jednotku pripojim, jen se mi nedari ten portforward na UDP port, abych se pripojil z venku

A z venku se chceš připojovat čím? Pokud web rozhraním, tak protřebuješ rozhodně TCP portforward, nikoli UDP.

531

Sítě / Re:Statický ARP záznam

« kdy: 28. 11. 2012, 10:36:37 »

Jenom na okraj: ifconfig v jiných OS umí i "nové" věci jako víc adres nebo třeba nastavení WPA. Takže ten důvod, proč Linux zavedl ip není v tomhle, to je spíš důsledek než příčina.

Až na to, že ifconfigy mezi různými OS jsou zcela různé a téměř kompletně nekompatibilní. Takže aby byla splněna podmínka, že ifconfig i v linuxu umí „nové věci“, stačí vytvořit symlink z ip na ifconfig. Co na tom, že se bude ovládat úplně jinak než starý ifconfig, ve Windows se ifconfig taky ovládá jinak než ten v Solarisu a ten zase jinak než ve FreeBSD.

Kdyby někde existoval standard, jak se má chovat ifconfig pro všechny moderní funkce TCP/IP stacku, asi bych byl za to, aby se používal. Ale pokud standardní ifconfig zamrzl někde v osmdesátých letech a od té doby si do něj každý připisuje svá vendor-specific rozšíření, pak je lepší navrhnout to celé znovu a lépe, jako v případě iproute2.

532

Windows a jiné systémy / Re:Zmenšený obraz přes HDMI

« kdy: 23. 11. 2012, 13:26:01 »

Vysoké DPI neznamená malé písmo. A je to nastavení systému, u linuxu konkrétně Xek a ne každé aplikace. To tvoje kolečko dělá úplně něco jiného.

Kéž by to byla pravda. Návrháři aplikací, zejména těch webových, si prostě zvykli, že monitor má vždy 96 DPI a tak bezostyšně míchají bitmapovou grafiku a vektorová písma a počítají s tím, že když to na jejich monitoru ukazuje správně, bude to správně všude. A vývojáři webových prohlížečů jim jdou na ruku, takže třeba Google Chrome renderuje vždy v 96DPI a pokud máte jiné DPI na monitoru, je oficiálním řešením použití funkce zoom (která zajistí škálování bitmap, aby se grafika stránky nerozpadla). Nehledě na to, že vývojáři Xorg toto podporují také a ve výchozím nastavení mají všechny displeje 96 DPI, přestože v dřívějších verzích docházelo k autodetekci.

Dost by mě zajímalo, jakým způsobem toto řeší Apple, ale ani bych se nedivil, kdyby webový prohlížeč taky renderoval stránky na 96DPI a následně je nazoomoval. Co se týče nativních aplikací, tam asi nebude problém, když jsou všechny iPady stejné, můžou vývojáři klidně míchat vektory a bitmapy dál, jen zvolí jinou konstantu DPI.

533

Sítě / Re:_ v domenovem jmenu

« kdy: 20. 11. 2012, 17:46:20 »

V doménovém jménu, přesněji v labelu, může být skoro jakýkoli znak, dokonce i takové šílenosti jako *, nebo /. Existuje ale jakýsi požadavek, že host names, tedy záznamy které vedou na nějaký počítač (tedy A/AAAA záznamy a zřejmě také CNAME mířící na A/AAAA) by měly používat pouze alfanumerické znaky a pomlčky s tím, že pomlčka nemá být na začátku.

Ale žádný zásadní význam to nemá, jen BIND při nedodržení pravidel nadává (pomůže volba check-names).

534

Vývoj / Re:Git - získat soubory které se změnily

« kdy: 20. 11. 2012, 11:26:41 »

Nejjednodušší je mít i na serveru git repozitář a provádět na něj push. Tím se přenesou jen změny.

BTW: nejjednodušší způsob, je nainstalovat do bare repo (třeba v gitolite) takovýto post-receive hook:

Kód: [Vybrat]

$cat repo.git/hooks/post-receive
#!/bin/sh
echo "*** Publishing new repository status in webroot ***"
GIT_WORK_TREE=/var/www/webroot/ git checkout -f

Jinak na přenos změn by nejspíš měl fungovat git-bundle, ale nezkoušel jsem to, tak nemám blužší informace.

535

Sítě / Re:Alternativa k VPN Hamachi

« kdy: 19. 11. 2012, 16:16:02 »

Otazkou je jestli je tedy n2n vhodne reseni a neni lepsi cesta?

Záleží, co přesně potřebuješ. Lepší cesta může být například IPv6 

536

Hardware / Re:USB 2.0 zařízení v USB 3.0 hubu

« kdy: 19. 11. 2012, 14:58:49 »

USB 2.0 klíče půjdou naprosto stejně jako v USB 2.0 HUBu.
USB 3.0 HUB nepřekládá komunikaci mezi USB 1.1/2.0 a USB 3.0.
USB 3.0 HUB obsahuje uvnitř dva v zásadě samostatné HUBy jeden USB 1.1/2.0, druhý USB 3.0 a k USB hostu je HUB propojený paralelně oběma způsoby 1.1/2.0 + 3.0.

Více info zde:
http://www.ti.com/lit/ds/symlink/tusb8040.pdf

Díky za odkaz. USB3 je evidentně, ještě větší bastl, než jsem se bál. Zlatá eSATA. Beztak větší rychlost než USB2 potřebují jen disky.

537

Sítě / Re:Mikrotik IPv6 - sixxs a neveřejná IPv4

« kdy: 19. 11. 2012, 14:52:57 »

Ano, je to možné, pokud Mikrotik podporuje protokol AYIYA (realizovaný klientem AICCU). Jenže podle všeho Mikrotik tenhle protokol nepodporuje. Takže vyměnit HW, nebo sehnat veřejnou adresu. Nebo v Mikrotiku rozjet OpenWRT, pro které AICCU existuje.

538

Hardware / Re:usb 2.0 zariadenia v 3.0 hub-e

« kdy: 14. 11. 2012, 20:46:44 »

.... Pokud neexistuje nejake inteligentnejsi zarizeni, ktere by prijimalo data jako USB 3, bufferovalo by je a rvalo na USB 2 storage, jak to stihaji. Ale to asi bude utopie.

Myslím si, že přesně tak USB3 hub funguje (pokud tedy vůbec něco takového existuje). Tedy přinejmenším tak funguje USB2 hub, do kterého jsou zapojeny USB1 zařízení. Nevidím důvod, proč by to stejně nemohlo fungovat u USB3.

539

Sítě / Re:Přesměrování portů s IPtables

« kdy: 08. 11. 2012, 14:23:37 »

Vypadá to všechno dobře. Povolovat nepřesměrovaný port je zbytečné, k přemapování dochází ještě před vstupem do tabulky filter. Podle mě to bude nějaká banalita jako překlep. Doporučuji pomocí iptables -t nat -L PREROUTING -v sledovat stav počítadel. Pokud tam jsou nuly, někde je chyba. Pak bych začal postupně odebírat omezující podmínky a případně přidával sledovací target LOG.

Taky by mohl být problém, pokud je z dané kombinace zdrojové a cílové adresy a portu už vedené nějaké spojení, které eviduje conntrack − tabulka nat se totiž prochází jen pro paket začínající nové spojení. Sice si nedokážu představit, jak by k něčemu takovému mohlo dojít, ale je potřeba na to myslet.

540

Sítě / Re:Zjištění cizí veřejné IP adresy

« kdy: 08. 11. 2012, 13:37:40 »

K dispozici mám jenom log, který přijde každé čtyři hodiny, mac adresu stroje a ID stroje. Takže jsem dost omezen. Nicméně se vzdáleně na stroj přes webové rozhraní dostanu. Chtěl jsem tedy vědět, jestli existuje nástroj, něco jako traceroute, který by mi dokázal říct, kde ten stroj stojí.

Takže si to shrňme:

• Tiskárna je neznámo kde.
• Tiskárna pravidelně navazuje spojení se serverem výrobce a sděluje mu, jak se jí daří.
• Ty máš u výrobce účet ve kterém přes web vidíš část informací, které tiskárna výrobci prozradila.

Pokud to tak skutečně je, tak neexistuje způsob, jakým bys od sebe zjistil, kdo se kdy připojil k serveru výrobce. Jediná možnost je požádat provozovatele serveru, ke kterému se ta tiskárna hlásí, ten jediný bude schopen identifikovat která tiskárna se ohlásila ze které adresy.