Příspěvky

766

Sítě / Re: Provider internetu na palouku v lese

« kdy: 22. 04. 2010, 09:54:23 »

Já bych se zaměřil na CDMA, ať už O2, nebo U:fon. Pokud zjistíš, kde je základnová stanice, můžeš dát na střechu směrovou televizní anténu pro UHF 21. kanál (474 MHz) a tím by se ti nejspíš podařilo i připojit se přes nějaké ty stromy.

Pokud jsi to ještě neudělal, tak se určitě zeptej na ADSL. Je to sice nepravděpodobné, ale občas se stane, že funguje i na vzdálených a odlehlých lokalitách.

767

Desktop / Re: Jak spustit novou X session pod jiným uživatelem

« kdy: 20. 04. 2010, 16:34:34 »

Zkusil bych

Kód: [Vybrat]

su <username> -c startx &

768

Vývoj / Re: Jak si vygenerovat kalendář?

« kdy: 20. 04. 2010, 16:33:00 »

To vypadá zas na domácí úkol… 

Začal bych něčím takovým:

Kód: [Vybrat]

for i in $(seq 1 31); do date -d "2010-04-${i}" +'%A%t%d.%B' 2>/dev/null; done

769

Sítě / Re: Více rozsahů na jedné síťové kartě

« kdy: 16. 04. 2010, 09:09:03 »

Pojem linux je v tomto případě příliš obecný, evidentně jde o problematiku nastavení konkrétní distribuce.

Jinak pro volatilní (dočasné) nastavení zřejmě bude stačit přidat adresu příkazem

Kód: [Vybrat]

ip addr add dev eth0 a.b.c.d/mm

770

Server / Re: Nastaveni DNS

« kdy: 16. 04. 2010, 08:35:08 »

Jinak v systému DNS toto v principu nejde – do něj se posílají jen názvy hostů, bez čísel portů.

771

Vývoj / Re: Přenesení souboru v unixu

« kdy: 15. 04. 2010, 18:28:38 »

Kód: [Vybrat]

ssh sunray1 -C 'tar -cf - $HOME/uloha16 | gzip' | gunzip | tar xvf -C $HOME/pom16

Spíš takhle:

Kód: [Vybrat]

ssh sunray1 -C 'tar -cf - -C $HOME/uloha16 . | gzip' | gunzip | tar xvf - -C $HOME/pom16

Ale to už je jen drobný detail.

772

Vývoj / Re: Přenesení souboru v unixu

« kdy: 15. 04. 2010, 14:48:20 »

Ad #1:
Podle mě by to mohlo fungovat takto:

Kód: [Vybrat]

find . \! -name "*temp*" - newer "timestamp" | tar cvf - -I - | gzip > uloha16.tar.gz 

A ještě k #1: možná je trochu problém, že zatímco find vypíše jeden každý soubor, tar zabaluje celé adresáře, takže vlastně každý soubor v podadresáři zabalí dvakrát (jednou jako součást podadresáře a podruhé jako vlastní soubor), v podpodadresáři třikrát, atd. GNU tar má na to volbu --no-recursion, ale Solaris zřejmě ne. Takže to chce asi přemluvit find, aby nevypisoval samostatné adresáře.

#2
Zde si nejsem jistý tím konečným přesměrováním, je to takhle možné prosím?

Kód: [Vybrat]

ssh sunray1@... -C 'tar -cf - $HOME/uloha16 | gzip' | gunzip | tar xvf - > $HOME/pom16

Nikoli. Program tar rozbaluje do aktuálního adresáře. Přesměrování výstupu akorát způsobí, že nebude vypisovat na konzoli jména souborů, které vytváří ale zapíše je do uvedeného souboru. Pokud chceš změnit adresář, do kterého má tar rozbalovat, je na to volba -C <jméno adresáře>.

Nejak nechapu, co chcete delat. Vy chcete zatarovat, co jiz bylo zatarovano, poslat to to gzipu a hned zase do gunzipu, aby se CPU zahralo a nasledne to zase roztarovat?

Předpokládám, že $HOME/uloha16 je adresář. A pokud se na ten příkazový řádek podíváš pořádně, zjistíš, že gzipování se provádí na vzdálené straně, zatímco gunzipování na lokální – jde tedy o efektivní využití přenosového kanálu.

Btw, zkousel jste se divat na rsync? Pokud vim, existuje i na Solaris a treba by se vam podarilo ho presne napasovat na to, o co se pokousite. Presne zadani znate vy, me porad trochu unika, o co *presne* se pokousite.

Vzhledem k tomu, že jde o školní úlohu s předepsanými nástroji není třeba přemýšlet nad účelností takového řešení

773

Sítě / Re: [APACHE] problem se sdilenim

« kdy: 15. 04. 2010, 09:52:17 »

Toto není problém s Apache httpd, tam může klidně zůstat adresa *:80.

Jde o problém s routerem, ten totiž provádí NAT, takže počítače za ním už mají jen privátní adresy a jsou z principu z veřejného Internetu nedostupné. Řešením je v administraci routeru nastavit přesměrování určitého portu (v tomto případě TCP/80) na vnitřní IP adresu počítače, na kterém běží Apache httpd)

Vzhledem k výstupům traceroute by asi taky neškodilo trochu nastavit (= vypnout) firewall vestavěný v routeru.

774

Vývoj / Re: Přenesení souboru v unixu

« kdy: 15. 04. 2010, 09:46:59 »

Tak jsem tu první část vyřešel takhle:
find . - name "*temp*" - newer "timestamp" > tar.list | tar cvf archivace -I tar.list | gzip > archivace.tar.gz

Pokud přesměrováš výstup do souboru, pak už nepotřebuješ rouru mezi find a tarem. Lepší by bylo u taru použít jako název souboru - pak by to četlo ze standardního vstupu.

Poznámka na okraj:
Příště prosím dej jasně na vědomí, že jde o Solaris a ne Linux. Solarisácký tar je poněkud odlišný od GNU taru.

Jen bych se chtěl zeptat, jak udělám, aby to vyhledalo soubory kam NEpatří "temp". Když dám před to vykřičník, jak psal kolega, tak to nefunguje.

Mně to takto funguje:

Kód: [Vybrat]

find . \! -name "*temp*"

Ale nemám k dispozici Solaris, takže nemůžu vyzkoušet.

Druhou část pomocí ssh jsem vyřešil následovně, ale nevím jestli je obojí dobře, mohl bych Vás poprosit o kontrolu? Děkuji mnohokrát

tar cvf $HOME/uloha16 | gzip > uloha16.tar.gz | scp sunray1@192.168.0.1:/$HOME/uloha16 /$HOME/pom16 -c' gunzip < uloha16.tar.gz | tar xvf – '

Zcela špatně. Opět stejný problém – když už přesměruješ výstup, nemá tam roura co dělat. Samozřejmě můžeš to udělat tak, že soubor na jednom PC zabalíš, pak pomocí scp zabalený soubor přeneseš a třetím příkazem na druhé straně rozbalíš. Ale cílem této úlohy bylo přenést to najednou bez vytváření mezisouborů, tedy s použitím SSH. Navíc pokud jsem zadání pochopil dobře, tak to máš přenést ze vzdáleného na lokální počítač. Takže by to mělo vypadat zhruba takhle:

Kód: [Vybrat]

ssh vzdaleny -C 'tar -cf - soubory | gzip' |gunzip |tar xvf - 

775

Vývoj / Re: Přenesení souboru v unixu

« kdy: 14. 04. 2010, 20:51:50 »

V podstatě je to dobře, až na to, že:

• Podmínku je na neobsahování temp, nikoli obsahování. Asi pomůže oescapovaný vykřičník.
• Výstupem findu je seznam souborů, ovšem tar v této konfiguraci žádný vstup nepředpokládá, místo toho chce seznam souborů na příkazovém řádku. Mohla by to pomoci vyřešit volba --files-from u taru. Já bych ale možná raději zkusil find zahodit a použít přímo volby taru --exclude a --newer, viz man tar.

Když se ti podaří tato první úloha, pak bude druhá snadná – stačí si uvědomit, že ssh umožňuje spustit na vzdáleném počítači jakýkoli proces (třeba i tar, nebo gunzip, nebo obojí) a předávat na jeho standardní vstup data. Takže stačí spojit <zabalení> | <komprese> | ssh vzdaleny -c '<dekomprese> | <rozbaleni>'

776

Sítě / Unbound a forwarding

« kdy: 14. 04. 2010, 10:23:08 »

Pro validaci DNSSEC používám Unbound. V základní konfiguraci všechno funguje, jak má, jenže všechny dotazy se řeší rekurzí přímo až od kořenových serverů, což si nemyslím, že by bylo úplně vhodné – obvykle jsem s notebookem v dosahu nějakého rekurzivního DNS serveru, který (s trochou štěstí) ani nestripuje DNSSEC data.

Přidal jsem tedy do konfiguračního souboru konfiguraci pro forwardování:

Kód: [Vybrat]

forward-zone:
        name: "."
        forward-addr: 8.8.8.8
        forward-addr: 8.8.4.4

Toto funguje vcelku obstojně. Problém ale nastane, když se mezi forwardery dostane DNSserver, který nepodporuje DNSSEC a navíc DNSSEC data kazí. Očekával bych, že Unbound zkusí ostatní servery (v ideálním případě i přímou cestu, jestliže všechny selžou). Místo toho na provedený dotaz odpoví SRVFAIL.

Dělám něco špatně, nebo je to opravdu takhle navržené?

777

Software / Re: TAR bez výpisu

« kdy: 13. 04. 2010, 11:13:19 »

A co LZMA? Někde jsem slyšel, že by měla být náročnější na paměť, ale zase se údajně oproti bzip2 mnohem rychleji dekomprimuje.

778

Hardware / Re: Vypnutí disku při nečinnosti

« kdy: 11. 04. 2010, 23:02:49 »

Kód: [Vybrat]

hdparm -S 241 /dev/sdb

Podrobnosti viz man hdparm

779

O serveru Root.cz / Re: Barva textu v blocích u černého skinu

« kdy: 11. 04. 2010, 15:40:36 »

Rád bych připomněl tento problém, který stále trvá. Mohl by se na to někdo podívat?

EDIT: Evidentně je problém jen u právě druhé citace.

Teď koukám, že stejný problém je u sudých zanořených citací:

První citace je ještě dobrá…

Druhá už je nečitelná.

A jak bude vypadat třetí? Zase dobře.

780

Distribuce / Re: Má smysl použít 64bitový systém?

« kdy: 09. 04. 2010, 14:31:48 »

Nemyslím si, že 64bitový systém přinese něco lepšího, než 32-bitový, na druhou stranu nevidím důvod, proč ho nepoužít. Problémy s Flashem a Javou už byly vyřešeny, takže u všech běžně používaných aplikací by neměl být problém.

Pokud však hodláte instalovat a používat nějaký proprietární software třetích stran, můžete narazit na problémy, že půjde o 32-bitový build, který bude potřebovat 32-bitové knihovny.