Hinnavaatlus.ee Wiki - Kasutaja kaastööd [et]

Ajalugu

2005-12-07T21:21:52Z

Cbr:

[[Kategooria:HV]]
'''1998''' - Hinnavaatlus alustas (ametlikult 26.01.1998). Õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997. aasta detsembrist alates, www.angelfire.com serveris. 
Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/. 
Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi HTML-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal aadressilt http://hinnavaatlus.ebs.ee/.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

'''1999''' ja '''2000''' - EBS-i välisühendus tõmmati HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

'''2001''' - oktoobris alustas Hinnavaatluse foorum. Juba novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või 3000 EEK kuus juurde maksta.

'''2002''' - aasta alguses kolis Hinnavaatlus Eesti Telefoni hostingserverisse.

'''2003''' - lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.
Aasta keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/.

'''2004''' - aasta alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et tulenevalt suurest andmebaasikoormusest ei olnud Eesti hostingfirmad huvitatud Hinnavaatluse hostimisest oma serverites. 
Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti 2004. aasta lõpus.

'''2005''' - alles maikuus saime jagu probleemidest Elioni ühenduse stabiilsuse ja tulemüüri konfimisega. Hinnavaatlus läks üle uuele serverile. Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

Praegune Hinnavaatlust jooksutav server:
[[Pilt:PRIMERGY_TX300.jpg|thumb|right|300px|Hinnavaatluse server]]
<blockquote>Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

1998

2005-12-07T21:20:26Z

Cbr: 1998 teisaldati: Ajalugu

#redirect [[Ajalugu]]

Ajalugu

2005-12-07T21:20:26Z

Cbr: 1998 teisaldati: Ajalugu

[[Kategooria:HV]]
'''1998''' - Hinnavaatlus alustas (ametlikult 26.01.1998). Õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997. aasta detsembrist alates, www.angelfire.com serveris. 
Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/. 
Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi HTML-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal aadressilt http://hinnavaatlus.ebs.ee/.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

'''1999''' või '''2000''' - EBS-i välisühendus tõmmati HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

'''2001''' - oktoobris alustas Hinnavaatluse foorum. Juba novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või 3000 EEK kuus juurde maksta.

'''2002''' - aasta alguses kolis Hinnavaatlus Eesti Telefoni hostingserverisse.

'''2003''' - lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.
Aasta keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/.

'''2004''' - aasta alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et tulenevalt suurest andmebaasikoormusest ei olnud Eesti hostingfirmad huvitatud Hinnavaatluse hostimisest oma serverites. 
Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti 2004. aasta lõpus.

'''2005''' - alles maikuus saime jagu probleemidest Elioni ühenduse stabiilsuse ja tulemüüri konfimisega. Hinnavaatlus läks üle uuele serverile. Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

Praegune Hinnavaatlust jooksutav server:
[[Pilt:PRIMERGY_TX300.jpg|thumb|right|300px|Hinnavaatluse server]]
<blockquote>Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

Ajalugu

2005-12-07T15:22:35Z

Cbr:

[[Kategooria:HV]]
'''1998''' - (ametlikult 26.01.1998) alustas Hinnavaatlus. Õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997. aasta detsembrist alates, www.angelfire.com serveris. 
Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/ 
Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi html-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal http://hinnavaatlus.ebs.ee/ aadressilt.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

'''1999''' või '''2000''' - tõmmati EBS-i välisühendus HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

'''2001''' - oktoobris alustas Hinnavaatluse foorum. Juba 2001. aasta novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või maksta juurde 3000 EEK kuus.

'''2002''' - Hinnavaatlus kolis 2002. aasta alguses Eesti Telefoni hostingserverisse.

'''2003''' - lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.
2003 keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/

'''2004''' - aasta alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et hostingfirmad Eestis ei olnud huvitatud Hinnavaatlus hostimisest enda serverites, tulenevalt suurest andmebaasikoormusest. 
Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti 2004 aasta lõpus.

'''2005''' - alles maikuus saime jagu Elion ühenduse stabiilsuse ja tulemüüri konfimisprobleemidest. Hinnavaatlus läks üle uuele serverile. Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

Praegune Hinnavaatlust jooksutav server:
[[Pilt:PRIMERGY_TX300.jpg|thumb|right|300px|Hinnavaatluse server]]
<blockquote>Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

Ajalugu

2005-12-07T15:22:00Z

Cbr:

[[Kategooria:HV]]
'''1998''' - (ametlikult 26.01.1998) alustas Hinnavaatlus. Õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997. aasta detsembrist alates, www.angelfire.com serveris. 
Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/ 
Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi html-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal http://hinnavaatlus.ebs.ee/ aadressilt.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

'''1999''' või '''2000''' - tõmmati EBS-i välisühendus HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

'''2001''' - oktoobris alustas Hinnavaatluse foorum. Juba 2001. aasta novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või maksta juurde 3000 EEK kuus.

'''2002''' - Hinnavaatlus kolis 2002. aasta alguses Eesti Telefoni hostingserverisse.

'''2003''' - lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.
2003 keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/

'''2004''' - aasta alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et hostingfirmad Eestis ei olnud huvitatud Hinnavaatlus hostimisest enda serverites, tulenevalt suurest andmebaasikoormusest. 
Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti 2004 aasta lõpus.

'''2005''' - alles maikuus saime jagu Elion ühenduse stabiilsuse ja tulemüüri konfimisprobleemidest. Hinnavaatlus läks üle uuele serverile. Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

[[Pilt:PRIMERGY_TX300.jpg|thumb|right|300px|Hinnavaatluse server]]
Praegune Hinnavaatlust jooksutav server:
<blockquote>Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

Ajalugu

2005-12-07T15:20:46Z

Cbr: Väike formaadiviga ;)

[[Kategooria:HV]]
'''1998''' - (ametlikult 26.01.1998) alustas Hinnavaatlus. Õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997. aasta detsembrist alates, www.angelfire.com serveris. 
Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/ 
Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi html-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal http://hinnavaatlus.ebs.ee/ aadressilt.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

'''1999''' või '''2000''' - tõmmati EBS-i välisühendus HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

'''2001''' - oktoobris alustas Hinnavaatluse foorum. Juba 2001. aasta novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või maksta juurde 3000 EEK kuus.

'''2002''' - Hinnavaatlus kolis 2002. aasta alguses Eesti Telefoni hostingserverisse.

'''2003''' - lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.
2003 keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/

'''2004''' - aasta alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et hostingfirmad Eestis ei olnud huvitatud Hinnavaatlus hostimisest enda serverites, tulenevalt suurest andmebaasikoormusest. 
Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti 2004 aasta lõpus.

'''2005''' - alles maikuus saime jagu Elion ühenduse stabiilsuse ja tulemüüri konfimisprobleemidest. Hinnavaatlus läks üle uuele serverile. Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

Praegune Hinnavaatlust jooksutav server:

<blockquote>[[Pilt:PRIMERGY_TX300.jpg|thumb|right|300px|Hinnavaatluse server]]
Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

Statistika

2005-12-07T15:16:35Z

Cbr:

[[Kategooria:HV]]2005 aasta novembris külastati Hinnavaatlust rekordiliselt 521697-l korral (Total Visits), kuvati üle 20 miljoni lehekülje (Total Pages) ja päringuid tehti 85652-lt erinevalt aadressilt (Total Unique Sites). Hinnavaatlus kuulub Eesti 10-ne suurima portaali hulka.

Eesti arvutifoorumite statistika 2005 leiab [http://www.tlu.ee/~tiiger/stats/ siit].

Ajalugu

2005-12-04T16:17:10Z

Cbr: tegin stiili veits kergemini jälgitavaks

[[Kategooria:HV]]
'''1998''' - (ametlikult 26.01.1998) alustas Hinnavaatlus. Õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997. aasta detsembrist alates, www.angelfire.com serveris. 
Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/ 
Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi html-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal http://hinnavaatlus.ebs.ee/ aadressilt.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

'''1999''' või '''2000''' - tõmmati EBS-i välisühendus HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

'''2001''' - oktoobris alustas Hinnavaatluse foorum. Juba 2001. aasta novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või maksta juurde 3000 EEK kuus.

'''2002''' - Hinnavaatlus kolis 2002. aasta alguses Eesti Telefoni hostingserverisse.

'''2003''' - lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.
2003 keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/

'''2004''' - aasta alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et hostingfirmad Eestis ei olnud huvitatud Hinnavaatlus hostimisest enda serverites, tulenevalt suurest andmebaasikoormusest. 
Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti 2004 aasta lõpus.

'''2005''' - alles maikuus saime jagu Elion ühenduse stabiilsuse ja tulemüüri konfimisprobleemidest. Hinnavaatlus läks üle uuele serverile. Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

Praegune Hinnavaatlust jooksutav server:
<blockquote>Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

Ajalugu

2005-12-04T16:07:27Z

Cbr:

[[Kategooria:HV]]
Aastal 1998 (ametlikult 26.01.1998) alustas Hinnavaatlus.

(õigupoolest sai üheleheküljelist hindadevaatlust tehtud juba 1997-nda aasta detsembrist alates, www.angelfire.com serveris)

Stiilinäidet vanemast versioonist näeb siit: http://classic.hinnavaatlus.ee/vanahv/20.02.1998/

Alguselt oli Hinnavaatlus EBS-i serveris (486 100MHz, 64MB), hindade uuendamine toimus puhtalt käsitsi html-is loengute vahel.
Kättesaadav oli Hinnavaatlus tollal http://hinnavaatlus.ebs.ee/ aadressilt.
Siinkohal tänud Priit Kadastikule, kes EBS-i adminnina leidis aega ja tahtmist serveris HV-le ruumi teha.

Millalgi 1999 või 2000 tõmmati EBS-i välisühendus HV külastatavuse kasvu tõttu kooma ja HV oli sunnitud kolima TELE2 hostingserverisse.

2001 aasta oktoobris alustas Hinnavaatluse foorum.

Kuid juba 2001 aasta novembri alguses vihjati TELE2-st, et Hinnavaatlus on nende jaoks liiga suur tükk ja soovitati uus teenusepakkuja otsida või maksta juurde 3000 EEK kuus.

Loomulikult otsustasime esimese variandi kasuks ja Hinnavaatlus koliski 2002 aasta alguses Eesti Telefoni hostingserverisse. 2003-ndal aastal lisandus domeen http://www.hv.ee, mis suunab http://www.hinnavaatlus.ee peale.

2003 keskpaigas muutis Hinnavaatlus oma välimust ja funktsionaalsust.
Vana Hinnavaatluse andmebaas on aga siiski endiselt kättesaadav aadressilt
http://classic.hinnavaatlus.ee/

2004 alguses sai selgeks, et ka Elioni hostingserverid ei suuda Hinnavaatluse koormust taluda ja tihti esines stabiilsusprobleeme. Hakkasime otsima erinevaid lahendusi, kuid sai selgeks, et hostingfirmad Eestis ei olnud huvitatud Hinnavaatlus hostimisest enda serverites, tulenevalt suurest andmebaasikoormusest.

Seoses sellega sai langetatud otsus Hinnavaatluse omaenda serveri ostuks.
Server osteti küll juba 2004 aasta lõpus, kuid Elion ühenduse stabiilsuse ja tulemüüri konfimisprobleemidest saime jagu alles 2005 a. maikuus, kui lõpuks uuele serverile üle läksime.

Esialgu piisab ühest serverist nii veebi kui andmebaasi jooksutamiseks, kuid tulevikus plaanime laiendada serveriparki, et koormusekasvuks valmis olla.

Praegune Hinnavaatlust jooksutav server:

<blockquote>Fujitsu Siemens PRIMERGY TX300r 
Dual XEON DP 3.2GHz 1M/533MHz 
6GB DDR-RAM PC2100 lp ECC 
6x HDD U320 15k 73GB hot plug 
RAID U320 4-ch 2i/4e 256MB, PCI-X 133MHz LSI 
Tape Drv VXA-2 80GB 6MB/s int. 
2x power supply module 400W (hot plug) 
RemoteView Service Board S2 
RemoteView Service Board S2 Batteryboard 
Red Hat Enterprise Linux ES</blockquote>

Jätkub...

MediaWiki:Sidebar

2005-11-27T21:53:24Z

Cbr:

Kasutaja arutelu:194.204.62.228

2005-11-24T20:21:04Z

Cbr:

Jumala eest, 2rge parandage vigu sisse! s6ne != s6na!!!
s6nE = string = tekstmuutuja.

A.

See olin mina, kes selle parandas :$ sorri, arvasin tõesti, et äkki trükiviga ;) Eks ma nüüd olen targem. [[Kasutaja:Cbr|Cbr]] 24. november 2005, kell 22.21 (EET)

Hallatav Võrgulüliti (Managed Switch) ja selle lisavõimaluste lühikirjeldus

2005-11-15T15:10:35Z

Cbr:

[[Kategooria:Andmeside]]
[[Kategooria:Füüsilise kihi juhendid]]
Nagu näha, vajadus on. Seega, alustame päris algusest ning teeme hakatuseks hästi lihtsalt selgeks, misasi on etherneti switch.

== Mis on switch ==
Etherneti switch on layer 2 seade, mis lihtsustatult võtab vastu siseneva etherneti kaadri, puhverdab selle, ning saadab mõnest teisest pordist välja.

Switch erineb hub'ist selle poolest, et switch puhverdab kaadri, analüüsib etherneti kaadris olevaid MAC aadresse ning teeb otsuse nende (ja mõnel juhul ka eeldefineeritud policy) põhjal. Hub isegi mitte ei puhverda kaadrit vaid olles preamble kätte saanud, hakkab kohe sissetulevat bitijoru teistesse portidesse edasi saatma. See on põhjuseks, miks me hub'i korral kunagi ei saa rääkida full duplexist.

Iga switchi sees on mingi kogus mälu, kus on tabel, milles on kirjas, millised MAC aadressid millise pordi küljes on. Seda tabelit täidetakse ning muudetakse vastavalt sissetulevatele kaadritele. Kuna etherneti kaadris on nii lähte kui ka sihtaadress (MAC aadress siis, eks), saab switch kasutada lähteaadresse oma tabeli uuendamiseks ning juhul kui switch teab, millise pordi taga on antud kaadris olev sihtaadress, edastab switch selle kaadri ainult sellesse konkreetsesse porti.

On aga ilmselge, et alati ei ole teada, millise pordi taga vajatav MAC aadress asub, samuti on olemas broadcast aadressid, millele saadetud kaader peab minema kõigile (lisaks on veel multicast aadressid, millele saadetud liiklus võiks minna ainult nendele, kes seda soovivad, kuid ei ole mõtet asja hetkel keerukaks ajada).

Nüüd. Olukorras, kus üks kahest, kas on tegemist broadcast/multicast liiklusega või switch ei tea, millise pordi taga on konkreetse kaadri puhul sihtaadress, edastab switch sellise kaadri kõikidesse portidesse, välja arvatud see port, kust ta selle sai (andmeside kuldreegel: ära kunagi saada midagi muutmata kujul tagasi sinna, kust sa selle said).

Ahjaa... Paneme tähele, et switch mitte kunagi ei muuda mitte midagi etherneti kaadris (välja arvatud 802.1Q puhul, kus switch lisab etherneti kaadrisse vastavad väljad või ISL puhul, kus switch kapseldab etherneti kaadri ISL kaadri sisse).

== Mis saab kui switchde vahel on rohkem kui üks ühendus ==

Olgu. Uurime juhtumit, kui meil on kahe switchi vahel rohkem kui üks ühendus (näiteks kaks kaablit). Oletame, et sellisesse võrku siseneb broadcast kaader, näiteks ARP pakett(suure tõenäosusega on ARP või DHCP esimene pakett, mille sisselülitatud arvuti saadab). Kuna tegemist on broadcasti aadressile saadetud kaadriga, peab switch selle edastama kõikidesse portidesse, välja arvatud sinna, kust ta selle sai. Teine switch saab selle kaadri kätte ning jällegi edastab selle kõikidesse portidesse va. see, kust ta selle sai. Kuna meil on aga switchide vahel topelt ühendus, tuleb see kaader tagasi esimesse switchi, mis jällegi edastab selle igale poole, kuhu saab ja nõnda jääbki meie ARP pakett switchide vahele lõputult ringlema, sest etherneti kaadris ei ole välja, kus oleks kirjas selle kaadri vanus.
http://telecom.tbi.net/frmlan.html

Nõndaks, me märkame, et ühendades kaks switchi üksteisega rohkem kui ühe kaabli abil, tuleb sellest suur jama ning tolku pole mitte kopika eest.
Targemad switchid räägivad Spanning Tree (802.1D), lühendatult STP või siis Rapid Spanning Tree (802.1w) protokolli. Spanning Tree on selline vahva naiselik protokoll, mille puhul switchid, perioodiliselt saates välja BPDU'sid (teatud kindla struktuuriga etherneti kaadreid), teevad selgeks võrgu topoloogia, hääletavad juurswitchi ning lähtuvalt sellest, muudavad topoloogia puu kujuliseks, blokeerides teatud reeglite alusel ühe või mitu topeltühendust. Tulemuseks saab garanteeritult loop'ide vaba võrk.
Ehk siis, kui meie kaks switchi, mille me ühendasime kahe kaabliga, räägivad STP'd, siis ühe switchi üks portidest blokeeritakse liikluse jaoks (endiselt saadetakse sealt kaudu BPDU'sid) ning kasutusele jääb vaid üks ühendustest. Kui see ühendus peaks katkema, saavad switchid sellest teada ning mõne aja pärast, kui ollakse veendunud, et enne blokeeritud olnud ühendus on ainuke, mis switchide vahele alles on jäänud, eemaldatakse blokeering.
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm

Me näeme, et STP annab küll garanteeritult "loop free" topoloogia, kuid peale reduntantsuse ei ole topeltühendusest mitte midagi kasu - andmeid mahub kahe switchi vahel liikuma ikka niipalju, kui ühe kaabli sisse läheb.

Selleks, et rohkem kui üks etherneti ühendus üheks bundle'iks kokku liita, saab kasutada näiteks EtherChannel'it (nagu cisco seda nimetab) või Trunking'ut (nagu paljud teised seda nimetavad - mitte segamini ajada 802.1Q'ga) või Bonding'ut(nagu Linux seda kustub). Sellisel juhul liidetakse mitu etherneti ühendust kokku üheks suurema läbilaskevõimega ühenduseks(bundle), kusjuures, kui mõni nendest ühendustest, mis bundle moodustavad, peaks katkema, jääb bundle endiselt tööle (küll väiksema jõudlusega siis). Et seda protsessi automatiseerida, on olemas Link Aggregation Control Protocol (802.3ad), mis võimaldab switchidel automaatselt kokku leppida, millised ühendused switchide vahel bundle'ks kokku liita.

http://www.cisco.com/en/US/tech/tk389/tk213/technologies_white_paper09186a0080092944.shtml

On muidugi ilmselge, et 300 krooni maksval TrendNet, HyperCom, SuperTrust vms. switchil sellist võimekust ei ole, tavaliselt ei räägi nad isegi kõige lihtlabasemat STP'd mitte.
Samas, ma oletaks, et umbes 10000 eesti raha eest võiks juba saada switchi, millega on, mõnel ülal kirjeldatud moel, võimalik mitmest ühendusest bundle'id moodustada.

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=20974 wookie]

Võrguühenduse kontrollimine

2005-11-13T13:48:31Z

Cbr: väike wikiseerimine

[[Kategooria:Võrgukihi juhendid]]
See sobib kasutamiseks siis kui mis iganes põhjustel ei ole võimalik võrguühenduse olemasolu operatsioonisüsteemi seirevahenditega seirata. Mõeldud kasutamiseks Microsoft'i operatsioonisüsteemis.
==Käivitatava faili loomine==
Selleks sobib näiteks [http://en.wikipedia.org/wiki/BAT_file Batch file]
Batch faili loomiseks on kõige sobivam lihtne tekstiredaktor. Näiteks kas notepad või edit.
failis peab olema järgmine.

REM Pingib teenusepakkuja lüüsi lisab pingimise kellaaja ja kuupäeva ning kirjutab tulemused tekstifaili.

ping ''[siia kirjuta oma teenusepakkuja lüüsi IP aadress]'' >> tulemus.txt
date /T >> tulemus.txt
time /T >> tulemus.tst

fail tuleb salvestada laiendiga .bat

Selle toimimist saab kontrollida käivitades faili kas käsurealt või failihaldurist.

Edukal käivitamisel peab tulemus.txt sisu välja nägema umbes selline :

T 08.11.2005
09:58
Pinging neti.ee [194.126.101.79] with 32 bytes of data:
Reply from 194.126.101.79: bytes=32 time=10ms TTL=58
Reply from 194.126.101.79: bytes=32 time=12ms TTL=58
Reply from 194.126.101.79: bytes=32 time=13ms TTL=58
Reply from 194.126.101.79: bytes=32 time=14ms TTL=58
Ping statistics for 194.126.101.79:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 14ms, Average = 12ms

Uuemate Windowside käsuinterpretaator on pisut võimekam. Järgenev CMD fail töötab kindlasti Windows 2K, XP ja 2K3 keskkonnas. NT4 keskkonnas võiks see asi teoreetiliselt t88tada, kuigi usutavasti ei ole seal seatud keskkonnamuutujaid %TIME% ja %DATE%. Sellisel juhult tuleb vastavad keskkonnamuutujad ise seada:
FOR /F "usebackq tokens=*" %%A IN (`DATE /T`) DO @SET KUUP=%%A
Seab muutuja KUUP väärtuseks käsu DATE väljundi. Kellaajaga tuleb toimida analoogiliselt.
Soovitav on faili nimeks panna CMD, mitte BAT, sest siis teab Windows, et faili interpreteerimiseks tuleb kasutada laiendatud võimalustega käsuinterpretaatorit

@FOR /F "usebackq tokens=*" %%A IN (`ping -n 1 host-mida-tahame-pingida ^| sort`) DO @SET ANS=%%A
@ECHO %DATE% %TIME% "%ANS%"

Annab umbes seesuguse väljundi

P 11/13/2005 12:08:34,06 "Reply from 192.168.1.1: bytes=32 time<1ms TTL=255"

Sedasi satub iga vastus ilusasti koos kuupäeva ja kellaajaga oma reale ja seda faili on oluliselt mugavam töödelda. NB! kuna Windowsi tekstiparser on pehmelt öeldes "piiratud", siis ei tohiks ping käsu n-parameetrit muuta. Kui hosti soovitakse mitu korda pingida tuleks terve ülalviidatud koodilõik asetada käsuskripti (näiteks png.cmd) ja kutsuda välja teisest käsuskriptist FOR tsükli abil.

fail mpng.cmd
@FOR /L %%I IN (1,1,3) DO @PNG.CMD

fail png.cmd
@FOR /F "usebackq tokens=*" %%A IN (`ping -n 1 192.168.1.1 ^| sort`) DO @SET ANS=%%A
@ECHO %DATE% %TIME% "%ANS%" >> ans.txt

fail ans.txt (tekib meile)
P 11/13/2005 12:31:05,37 "Reply from 192.168.1.1: bytes=32 time<1ms TTL=255"
P 11/13/2005 12:31:05,50 "Reply from 192.168.1.1: bytes=32 time<1ms TTL=255"
P 11/13/2005 12:31:05,60 "Reply from 192.168.1.1: bytes=32 time<1ms TTL=255"

On siililegi selge, et pingimiskordade arvu muudame me failis mpng mängides IN seti kolmanda parameetriga, mis hetkel omab väärtust "3". Samuti on soovitav näites toodud IP aadress vahetada selle IP aadressi vastu mida soovime pingida.

==Faili perioodiline käivitamine==
Perioodiliseks käivitamiseks on mõistlik kasutada Windowsi operatsioonisüsteemis olevat Task Sheduleri.
Kiirtee seadistaja leidmiseks ja käivitusrutiini loomiseks on järgmine Start menüü > programs > Accessories > System tools > Scheduled Tasks > Add Scheduled Task.

Käivitatavaks programmiks on eelnevalt loodud Batch fail.
Detailne seadistamine sõltub kasutatavast operatsioonisüsteemist ning sellega tutvumiseks on soovitav kasutada operatsioonisüsteemi spikrit (help).

==Praktilised näpunäited==
Teenusepakkuja lüüsi pingimine on soovitatav selle pärast, et kui te pingite suvalist hosti internetis ei ole tulemuseks mitte see kas teie ühendus on töökorrast vaid kas see host on töökorras. Samuti ei pruugi see anda ka ikkagi reaalseid tulemusi kuna tegelikuses on teenusepakkuja arvutivõrgu infrastruktuur keerulisem ning viga võib olla ka tekkinud peale esimest lüüsi.
Testi liiga tihe käivitamine pika ajajooksul (näiteks iga minuti tagant) ei pruugi anda soovitud tulemusi ning võib hoopis vähendada võrguühenduse läbilaskevõimet või operatsioonisüsteemi jõudlust.

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=12170 silverk]

Live CD

2005-11-11T19:47:46Z

Cbr: /* Linuxil põhinevad Live CD-d */

Live CD all mõeldakse tavaliselt bootivat CD-d või DVD-d, millel on peal operatsioonisüsteem ning tihti ka muid vajalikke programme. Live CD saab käivitada oma arvutis nii, et teed arvutile restardi, paned plaadi lugejasse ning, kui BIOS-ist on märgitud CD-seade esimeseks bootivaks seadmeks, siis käivitub su arvutis plaadil olev operatsioonisüsteem. Töötamiseks kasutab plaadil olev operatsioonisüsteem RAM-i. Seega pole kõvaketta olemasolu arvutis tingimata vajalik.

Live CD eeliseks on see, et sellega saad töötada nii, et sellest ei jää arvutisse mingit jälge. Sellega pääsed ligi ka juba arvuti kõvakettal olevale operatsioonisüsteemile, et selle juures näiteks parandusi teha.



===Live CD nimekirjad===

*[http://www.livecdlist.com/ FrozenTech's LiveCD List] (Väga põhjalik ning väga heade sorteerimisevõimalustega nimekiri.)

====Linuxil põhinevad Live CD-d====
(Vähemalt hetkel on toodud siia nimekirja ainult mõned populaarsemad distibutsioonid. Põhjalikuma nimekirja leiad ülalpool toodud lingilt.)
* [http://www.knoppix.com/ Knoppix] - Üks tuntumaid. Põhineb Debian GNU/Linuxil.
* [http://slax.linux-live.org/ SLAX] - Põhineb Slackware Linuxil.
* [http://www.ubuntulinux.org/ Ubuntu Linux]
* [http://www.damnsmalllinux.org/ Damn Small Linux] - Väike ega nõua võimast arvutit.
* [http://www.dynebolic.org/ dyne:bolic] - Saab ka sulhteliselt aeglasel süsteemil hästi hakkama
* [http://featherlinux.berlios.de/ Feather Linux]
* [http://www.sysresccd.org/ Ubuntu Linux]

====BSD-l põhinevad Live CD-d====
* [http://www.dragonflybsd.org/main/ DragonFly]
* [http://frenzy.org.ua/eng/ Frenzy]
* [http://www.freesbie.org/ FreeSBIE]

====Muudel süsteemidel põhinevad Live CD-d====
* [http://www.dragonflybsd.org/main/ BeleniX] (Solaris)
* [http://schillix.berlios.de/ SchilliX] (OpenSolaris)

Kõvaketta seisukorra hindamine

2005-11-11T15:58:18Z

Cbr: /* Kõvaketta seisukorra hindamine Linuxis */

[[Kategooria:Tarkvara]]
[[Kategooria:Linux]]
==Kõvaketta seisukorra hindamine Linuxis==
Vigadest teab üldiselt siiski kõige rohkem see koht, kus pauk käib, ehk siis ketas ise.

Installeeri oma masinale smartmontools ja siis lase käima kood:

# smartctl -a /dev/hda

Väikesed vihjed:

* Esimese asjana tuleks vaadata "SMART Attributes Data Structure". Kõik muu peale ATTRIBUTE_NAME ja RAW_VALUE tulpade on enamasti ebaoluline.

* Suured numbrid väärtustes Raw_Read_Error_Rate, Hardware_ECC_Recovered ja Seek_Error_Rate on uuemate ketaste juures normaalsed.

* Kui Reallocated_Sector_Ct ning Offline_Uncorrectable väärtused on nullist erinevad, viitab see lähitulevikus surevale kõvakettale.

* Kui SMART error logist midagi leiad, siis tähendab see, et kettal on lugemise/kirjutamisega juba probleeme olnud.

* Abiks on veel lasta kettal oma sisemisi teste teha kood:

# smartctl -t short /dev/hda
ning hiljem
# smartctl -t long /dev/hda

ning peale soovitatavat minutite arvu SMART self-test logi piiluda.

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=17219 integor]

Toimetaja: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=7521 Death]

Kõvaketta seisukorra hindamine

2005-11-11T15:57:14Z

Cbr:

[[Kategooria:Tarkvara]]
[[Kategooria:Linux]]
==Kõvaketta seisukorra hindamine Linuxis==
Vigadest teab üldiselt siiski kõige rohkem see koht, kus pauk käib, ehk siis ketas ise.

Installeeri oma masinale smartmontools ja siis lase käima kood:

> smartctl -a /dev/hda

Väiksed vihjed:

* Esimese asjana tuleks vaadata "SMART Attributes Data Structure". Kõik muu peale ATTRIBUTE_NAME ja RAW_VALUE tulpade on enamasti ebaoluline.

* Suured numbrid väärtustes Raw_Read_Error_Rate, Hardware_ECC_Recovered ja Seek_Error_Rate on uuemate ketaste juures normaalsed.

* Kui Reallocated_Sector_Ct ning Offline_Uncorrectable väärtused on nullist erinevad, viitab see lähitulevikus surevale kõvakettale.

* Kui SMART error logist midagi leiad, siis tähendab see, et kettal on lugemise/kirjutamisega juba probleeme olnud.

* Abiks on veel lasta kettal oma sisemisi teste teha kood:

> smartctl -t short /dev/hda
> #ning hiljem
> smartctl -t long /dev/hda

ning peale soovitatavat minutite arvu SMART self-test logi piiluda.

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=17219 integor]

Toimetaja: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=7521 Death]

Kategooria:Muu

2005-11-05T21:32:46Z

Cbr:

Siia artiklid, mis ei sobi teistesse alajaotusesse.

Esileht

2005-11-05T21:31:43Z

Cbr:

__NOTOC__
'''Tere tulemast Hinnavaatlus.ee Vikisse.'''

Siit leiate vastuseid levinumatele küsimustele, mis puudutavad [http://www.hinnavaatlus.ee Hinnavaatlust] ja [http://foorum.hinnavaatlus.ee Hinnavaatluse foorumit].

{| cellspacing="0" style="border:0px;margin-right:10%;"
|- valign="top"
|width="60%"|

= Sisu: =

*'''[[:Category:HV|Hinnavaatlus]]'''
*'''[[:Category:Andmeside|Andmeside]]'''
*'''[[:Category:Tarkvara|Tarkvara]]'''
*'''[[:Category:Riistvara|Riistvara]]'''
*'''[[:Category:Turvalisus|Turvalisus]]'''
*'''[[:Category:Mõisted|Mõisted]]'''
*'''[[:Category:Muu|Muu]]'''

*'''[[:Category:Kasulikud Näpunäited|Kasulikud Näpunäited]]'''

'''Muu:'''

[[Viki kirjutamine]] 
[[Kuidas saada Viki kirjutajaks]] 
[[Ettepanekud/TODO]]

'''Kes kirjutavad Vikit?'''

Hinnavaatlus.ee Vikit kirjutavad kõik, kes on mainitud [http://foorum.hinnavaatlus.ee/groupcp.php?g=21801 Hinnavaatluse foorumi grupis "wiki"]. Selline teguviis tagab esitatud andmete korrektsuse ning ka selle, et pahateod on lihtsamalt ärahoitavad. 

|width="24px"|
   
|width="40%"|
= Uudised: =
'''Uus kategoriseerimine''' 
Esmaspäev, 24. Oktoober 
Arutluse tulemusena selgus fakt, et viki tuleb natuke teistmoodi kategoriseerida. Nüüdsest on kategooriad natuke arusaadavamad ning artiklid tsipa rohkem ligipääsetavad.
----
'''Kraanid kinni''' 
Esmaspäev, 17. Oktoober 
Nüüdsest on Viki muutmine võimalik [http://foorum.hinnavaatlus.ee/groupcp.php?g=21801 Hinnavaatluse foorumis grupiga Wiki liitudes]. Liitudes selle grupiga, saad koheselt siin sisse logida oma Hinnavaatluse kasutajanime ja parooliga.

'''''NB! Anonüümne muutmine on taas lubatud!'''''
----
'''Viki kohal''' 
Esmaspäev, 17. Oktoober 
Nüüdseks on Viki ilusasti HV serveris, ootamas sisu ja järge. Siiamaani tundub, et projekt edeneb jõudsasti ning jagub ka entusiaste kes sisu lisaksid.
----
|}

Kõvakettad - statistikat ja palju muud kasulikku infot

2005-11-05T14:50:20Z

Cbr: Mis plussid? :roll:

[[Kategooria:Riistvara]]

==Koondtabel toodetavatest kõvaketastest (3,5" ATA/SATA 7200+)==
Pere Seeria Liides Cache NCQ MTBF Olemasolevad-toodetavad-kettamahu-variandid-GB Tähistus
_________________________________________________________________________________________

[Seagate]

NearLine NL35 SATA 16 NCQ 1.0 ---/400/---/---/250/---/---/---/---/---/---/--- ST3...6p.NS
NearLine NL35 SATA 8 NCQ 1.0 ---/400/---/---/250/---/---/---/---/---/---/--- ST3...8p.NS
Barracuda7200.9 SATA2 16 NCQ 500/400/---/300/---/---/---/---/---/---/---/--- ST3...6p.AS
Barracuda7200.9 SATA2 8 NCQ ---/---/---/---/250/200/160/120/080/---/---/--- ST3...8p.AS
Barracuda7200.9 ATA 16 500/400/---/300/---/---/---/---/---/---/---/--- ST3...6p.A
Barracuda7200.9 ATA 8 ---/---/---/---/250/200/160/120/---/---/---/--- ST3...8p.A
Barracuda7200.9 ATA 2 ---/---/---/---/---/---/160/120/080/---/040/--- ST3...21.A
Barracuda7200.8 SATA 8 NCQ ---/400/---/300/250/200/---/---/---/---/---/--- ST3...8p.AS
Barracuda7200.8 ATA 8 ---/400/---/300/250/200/---/---/---/---/---/--- ST3...8p.A
Barracuda7200.7 SATA 8 NCQ ---/---/---/---/---/---/160/120/080/---/---/--- ST3...8p7AS
Barracuda7200.7 SATA 8 ---/---/---/---/---/200/160/120/080/---/---/--- ST3...0p.AS
Barracuda7200.7+ ATA 8 ---/---/---/---/---/200/160/120/---/---/---/--- ST3...0p.A
Barracuda7200.7+ ATA 2 ---/---/---/---/---/200/---/---/---/---/---/--- ST3200021A
Barracuda7200.7 ATA 8 ---/---/---/---/---/---/---/---/080/---/---/--- ST380013A
Barracuda7200.7 ATA 2 ---/---/---/---/---/---/160/120/080/---/040/--- ST3...0p.A

[Western Digital]

WD Caviar RE2 SATA 16 NCQ 1.2 ---/400/---/---/---/---/---/---/---/---/---/--- WD4000YR
WD Caviar RE SATA 8 1.0 ---/400/320/---/250/---/160/120/---/---/---/--- WD...0SD
WD Caviar RE ATA 8 1.0 ---/---/320/---/250/---/160/120/---/---/---/--- WD...0SB
WD Caviar SE16 SATA2 16 ---/400/---/---/250/---/---/---/---/---/---/--- WD2500KS
WD Caviar SE16 SATA 16 NCQ ---/400/---/---/---/---/---/---/---/---/---/--- WD4000KD
WD Caviar SE SATA2 8 ---/---/---/---/250/200/160/120/---/---/---/--- WD...0JS
WD Caviar SE SATA 8 0.7 ---/---/320/300/250/200/160/120/080/---/040/--- WD...0JD
WD Caviar SE ATA 8 0.7 ---/---/320/300/250/200/160/120/080/---/040/--- WD...0JB
WD Caviar ATA 2 ---/---/---/---/250/200/160/120/080/---/040/020 WD...0BB
WD Raptor 10000 SATA 8 TCQ 1.2 ---/---/---/---/---/---/---/---/074/---/036/--- WD...0GD

[Hitachi]

Deskstar 7K500 SATA2 16 500/---/---/---/---/---/---/---/---/---/---/--- HDS725050KLA360
Deskstar 7K500 ATA 8 500/---/---/---/---/---/---/---/---/---/---/--- HDS725050KLAT80
Deskstar 7K400 SATA 8 ---/400/---/---/---/---/---/---/---/---/---/--- HDS724040KLSA80
Deskstar 7K400 ATA 8 ---/400/---/---/---/---/---/---/---/---/---/--- HDS724040KLAT80
Deskstar T7K250 SATA2 8 ---/---/---/---/250/---/160/---/---/---/---/--- HDT7225..DLA380
Deskstar T7K250 ATA 8 ---/---/---/---/250/---/160/---/---/---/---/--- HDT7225..DLAT80
Deskstar 7K250 SATA 8 ---/---/---/---/250/---/160/120/080/---/---/--- HDS7225..VLSA80
Deskstar 7K250 ATA 8 ---/---/---/---/250/200/160/120/---/---/---/--- HDS7225..VLAT80
Deskstar 7K250 ATA 2 ---/---/---/---/---/---/160/120/080/---/040/--- HDS7225..VLAT20
Deskstar 7K80 SATA2 8 ---/---/---/---/---/---/---/---/080/---/---/--- HDS728080PLA380
Deskstar 7K80 SATA2 2 ---/---/---/---/---/---/---/---/---/---/040/--- HDS728040PLA320
Deskstar 7K80 ATA 2 ---/---/---/---/---/---/---/---/080/---/040/--- HDS7280..PLAT20

[Samsung]

SpinPoint T133 SATA2 8 NCQ 0.6 ---/400/---/300/---/---/---/---/---/---/---/--- HD...LJ
SpinPoint T133 ATA 8 0.6 ---/400/---/300/---/---/---/---/---/---/---/--- HD...LD
SpinPoint P120 SATA2 8 NCQ 0.6 ---/---/---/---/250/200/---/---/---/---/---/--- SP2.04C
SpinPoint P120 ATA 8 0.6 ---/---/---/---/250/200/---/---/---/---/---/--- SP2.14N
SpinPoint P80SD SATA2 8 NCQ 0.6 ---/---/---/---/---/---/160/120/080/---/040/--- HD....J
SpinPoint P80 SATA 8 0.5 ---/---/---/---/---/---/160/120/080/---/---/--- SP..1.C
SpinPoint P80 ATA 8 0.5 ---/---/---/---/---/---/160/120/080/---/---/--- SP..1.N
SpinPoint P80 ATA 2 ---/---/---/---/---/---/160/120/080/060/---/--- SP....N

[Maxtor]

MaXLine Pro SATA2 16 NCQ 1.0 500/---/---/---/---/---/---/---/---/---/---/--- 7H500F0
MaXLine Pro ATA 16 1.0 500/---/---/---/---/---/---/---/---/---/---/--- 7H500R0
MaXLine +III SATA 16 NCQ 1.0 ---/---/---/300/250/---/---/---/---/---/---/--- 7B...S0
MaXLine +III ATA 16 1.0 ---/---/---/300/250/---/---/---/---/---/---/--- 7B...R0
MaXLine +II SATA 8 1.0 ---/---/---/---/250/---/---/---/---/---/---/--- 7Y250M0
MaXLine +II ATA 8 1.0 ---/---/---/---/250/---/---/---/---/---/---/--- 7Y250P0
QuickView 500 SATA2 16 NCQ 500/400/---/---/---/---/---/---/---/---/---/--- 3H...F0
QuickView 500 ATA 16 500/400/---/---/---/---/---/---/---/---/---/--- 3H...R0
QuickView CE SATA 16 NCQ ---/---/---/300/250/---/---/---/---/---/---/--- 6L...S0
QuickView CE SATA 8 NCQ ---/---/---/---/---/200/160/120/080/100/---/--- 6L...M0
QuickView CE SATA 2 NCQ ---/---/---/---/---/---/---/---/---/---/040/--- 6K040T0
QuickView CE ATA 16 ---/---/---/300/250/---/---/---/---/---/---/--- 6L...R0
QuickView CE ATA 8 ---/---/---/---/---/200/160/120/080/100/---/--- 6L...P0
QuickView CE ATA 2 ---/---/---/---/---/---/---/---/---/---/040/--- 6K040L0
DiamondMax 11 SATA2 16 NCQ 500/400/---/---/---/---/---/---/---/---/---/--- 6H...F0
DiamondMax 11 ATA 16 500/400/---/---/---/---/---/---/---/---/---/--- 6H...R0
DiamondMax 10 SATA 16 NCQ ---/---/---/300/250/---/---/---/---/---/---/--- 6B...S0
DiamondMax 10 SATA 8 NCQ ---/---/---/---/---/200/160/120/080/---/---/--- 6B...M0
DiamondMax 10 ATA 16 ---/---/---/300/250/---/---/---/---/---/---/--- 6B...R0
DiamondMax 10 ATA 8 ---/---/---/---/---/200/160/120/080/---/---/--- 6B...P0
DiamondMax +9 SATA 8 ---/---/---/---/250/200/160/120/080/060/---/--- 6Y...M0
DiamondMax +9 ATA 8 ---/---/---/---/250/200/160/120/080/---/---/--- 6Y...P0
DiamondMax +9 ATA 2 ---/---/---/---/---/---/160/120/080/060/---/--- 6Y...L0
DiamondMax +8 ATA 2 ---/---/---/---/---/---/---/---/---/---/040/--- 6E040L0

[Excelstor]

JupiterCallisto SATA2 8 ---/---/---/---/---/---/---/---/080/---/---/--- J880S
JupiterCallisto ATA 2 ---/---/---/---/---/---/---/---/080/060/040/--- J8..
JupiterGanymede SATA 8 ---/---/---/---/---/---/---/---/080/---/---/--- J680S
JupiterGanymede ATA 2 ---/---/---/---/---/---/---/---/080/060/040/020 J6..
JupiterEuropa ATA 2 ---/---/---/---/---/---/---/---/---/060/040/--- J3..
'''Märkused:'''
* MTBF (Mean Time Between Failures) on statistilis-teoreetiline töökindluse näitaja, miljonites tundides. Avaldatakse peamiselt vaid enterprise ehk professionaalidele mõeldud seeriatel. Neil laiatarbeseeriatel, millel siin tabelis MTBF number puudub, on see tavaliselt 0.2-0.7 vahemikus.
* Maxtor QuickView on mõeldud kasutamiseks olmeelektroonikas (Consumer Electronics = CE), näiteks videosalvestites. Parendatud on striimingut ja kõrge temperatuuri taluvust.
* Maxtoril on enamusel seeriatest lisaks olemas ka "Versions of drive that conform with the requirements of the European Union Directive in Restriction of Hazardous Substances (RoHS)". Nende tähistus on näiteks 7L300S0 (tavamudeli 7B300S0 analoog).
* Seagate tüübitähises märgib platterite arvu "p" ehk paremalt lugedes 2.number. Cache mahtu märgib paremalt lugedes 3.number (0=2..8MB, 2=2MB, 8=8MB, 6=16MB).
* Samsung P120 SATA seeriaga on väike segadus: Samsungi enda väitel on tegemist SATA2 ketastega, kuid meie poodides pakutavad needsamad mudelid on tavaline SATA.


===Reaalse populaarsuse edetabel===

Maailma populaarseimad kõvakettaseeriad viimase 5 aasta kohta (turuosa %):

#11% - WD Caviar SE (JB/JD)
#8% - IBM/HITACHI Deskstar 75GXP
#7% - MAXTOR DiamondMax +9
#7% - IBM/HITACHI Deskstar 60GXP
#6% - SEAGATE Barracuda 7200.7
#6% - SEAGATE Barracuda IV
#6% - WD Caviar (BB)
#5% - MAXTOR DiamondMax D740X
#3% - HITACHI Deskstar 7K250
#2% - SAMSUNG SpinPoint P80
#2% - SEAGATE Barracuda V
#2% - WD Raptor
#1% - MAXTOR DiamondMax +8
#34% - (Ülejäänud mitmed sajad eri aegade IDE ja kõik SCSI mudelid kokku)

===Reaalse töökindluse edetabel===

Populaarsemate uuemate kõvakettaseeriate töökindluse indeksid (Drive is more reliable than NN% of others) kokku ligi 40000 kõvaketta reaalse kasutamise tööstatistikast:

====IDE(ATA/SATA)====
#89% - SEAGATE Barracuda 7200.7
#85% - SEAGATE Barracuda IV
#82% - WD Raptor 36 GB
#78% - WD Caviar SE (JB) 40,80,120 GB
#77% - WD Raptor 74 GB
#53% - HITACHI Deskstar 7K250
#44% - SAMSUNG SpinPoint P80
#32% - MAXTOR DiamondMax +9
#28% - MAXTOR DiamondMax +8
#24% - WD Caviar SE (JB/JD) 250 GB
#23% - WD Caviar SE (JB/JD) 200 GB

====SCSI====
#97% - SEAGATE Cheetah 15K.3
#96% - SEAGATE Cheetah X15-36LP
#76% - MAXTOR Atlas 10K IV
#70% - MAXTOR Atlas 10K III
#61% - SEAGATE Cheetah 10K.6
#19% - IBM Ultrastar 36LZX

''Enamusel Seagate SCSI kasutajatel 3...5 aastat 24/7 töös ja lõppu pole näha...''

====Uued mudelid...====
Viimase aasta moodsad seeriad (HITACHI Deskstar 7K400/500/T7K250, MAXTOR DiamondMax10/MaXLine+III, SEAGATE Barracuda 7200.8/9 ja NL, WD Caviar SE/SE16/RE/RE2 400,320,300,(250) GB) ei ole veel piisavalt aega eksisteerinud, et töökindlust objektiivselt hinnata. Samuti on nende kasutajaid veel vähe usaldusväärse statistika tegemiseks. Siiski, mingigi esialgse ettekujutuse saamiseks kirjutasin välja raporteeritud jälgimises olevate ketaste koguarvu ja nendest juba ära surnud ketaste arvu (sulgudes on ketta esialgse turuletuleku aasta ja kvartal):

*HITACHI Deskstar 7K400... (2004q2) 27: 3
*MAXTOR MaXLine+III(DM10) (2004q3) 129:25
*SEAGATE Barracuda 7200.8 (2004q4) 296:30
*WD Caviar SE WD3200JB/JD (2005q1) 53: 5
*WD Caviar SE16 WD2500KS (2005q2) 4: 0

Paljude uute seeriate kohta aga pole esialgu üldse mingit töökindluse tagasisidet.

Põnevateks võivad kujuneda äsja uueks trendiks võetud väidetavalt 2...3 kordse töökindlusega enterprise(pro) seeriad SATA 7200rpm soodsa hinnaga ketaste valdkonnas:
*SEAGATE NL35 (250.1, 400.1)
*WD Caviar RE (WD3200SB/SD, WD2500SB/SD, WD1600SB/SD, WD1200SB/SD)
*WD Caviar RE2 (WD4000YR)

allikas: ''StorageReview''

==Võrdlustabelid ja kasulikku abiinfot kõvaketta valimiseks==

*Veelkord tehtud 22 kõvaketta võrdlustest ja hetkeseisu lühiülevaade (NB! Artiklis on palju vigu!):
**http://www.tomshardware.com/storage/20050927/index.html

'''''NB! Järgnevalt vaadake võrdlusgraafikuid, mitte konkreetset ketast, mis pealkirjas on!'''''

#Kettalt järjestlugemise ja kettale järjestkirjutamise kiirused:
#*http://www.tomshardware.com/storage/20050927/hd_round_up-34.html
#*http://www.tomshardware.com/storage/20050714/hitachi_deskstar-04.html
#*http://www.storagereview.com/comparison.html (valida "Maximum Transfer Rate")
#Otsingukiirus (SeekTime+LatencyTime) ja puhvri väljundkiirus (tähtsusetu):
#*http://www.tomshardware.com/storage/20050927/hd_round_up-33.html
#*http://www.tomshardware.com/storage/20050714/hitachi_deskstar-05.html
#*http://www.storagereview.com/comparison.html (valida "Average Random Access Time")
#Mängude benchmark'id:
#*http://www.storagereview.com/articles/200510/Testbed4_5.html
#Ketta müratase:
#*http://www.storagereview.com/articles/200510/Testbed4_7.html
#*http://www.storagereview.com/comparison.html (valida "Idle Noise")
#Kettapinna temperatuur:
#*http://www.tomshardware.com/storage/20050927/hd_round_up-34.html
#*http://www.tomshardware.com/storage/20050714/hitachi_deskstar-06.html
#Ketta võimsustarve:
#*http://www.storagereview.com/articles/200510/Testbed4_7.html
#*http://www.storagereview.com/comparison.html (valida "Power Dissipation")
#Ketta käivitamise tippvõimsustarve:
#*http://www.storagereview.com/articles/200510/Testbed4_7.html
#*http://www.storagereview.com/comparison.html (valida "Maximum Power Dissipation")

*'''Konspekt kõvaketaste ehitusest ja tööst (väga mahukas, 1000+ lehekülge!):'''
**http://www.storagereview.com/guide/guide_index.html

*'''KKK kõvaketastest ja levinumatest probleemidest:'''
**http://faq.storagereview.com/
**http://www.seagate.com/support/kb/disc/index_faq.html
**http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_alp.php
**http://maxtor.custhelp.com/cgi-bin/maxtor.cfg/php/enduser/std_alp.php?p_sid=vBjQByQh&p_lva=&p_sp=&p_li=

===Suuremad kõvaketaste tootjad tänapäeval===

[http://www.seagate.com/ SEAGATE]

[http://www.westerndigital.com/ WESTERN DIGITAL] ehk [http://www.wdc.com/ WD]

[http://www.hitachigst.com/ HITACHI]

[http://product.samsung.com/cgi-bin/nabc/product/b2c_product_type.jsp?eUser=&prod_path=%2fComputers+and+Related%2fHDD SAMSUNG]

[http://www.maxtor.com/ MAXTOR]

[http://www.excelstor.com/ EXCELSTOR]

===Üksikute uute kõvaketaste ülevaated ja testid===

''NB! Enamasti iga artikkel läheb edasi päris mitmel leheküljel!''

====[2005]====

*WD CaviarRE2 WD4000YR (400GB/RAID/Pro):
**http://www.storagereview.com/articles/200510/WD4000YR_1.html
**http://www.wdc.com/en/products/Products.asp?DriveID=158&Language=en (tootja infoleht)

*WD CaviarSE16 WD4000KD (400GB):
**http://www.tomshardware.com/storage/20051003/index.html

*Seagate NearLine NL35 (400GB,250GB/Pro):
**http://www.storagereview.com/articles/200510/ST3400832NS_1.html
**http://www.seagate.com/cda/products/discsales/enterprise/family/1,1086,699,00.html (tootja infoleht)
**http://www.seagate.com/products/enterprise/nl35.html (tootja infoleht)
**http://www.seagate.com/docs/pdf/marketing/Seagate_NL35.pdf (tootja infoleht)
**http://www.seagate.com/content/docs/pdf/datasheet/disc/ds_nl35series.pdf (tootja infoleht)

*Seagate Barracuda 7200.9 (500GB,400GB,300GB,250GB,200GB,160GB,120GB,80GB,40GB):
**http://www.storagereview.com/articles/200510/ST3500641AS_1.html
**http://www.anandtech.com/storage/showdoc.aspx?i=2577
**http://www.anandtech.com/storage/showdoc.aspx?i=2559
**http://www.seagate.com/cda/products/discsales/personal/family/0,1085,724,00.html (tootja infoleht)
**http://www.seagate.com/pdf/marketing/PO-Cuda7200.9.pdf (tootja infoleht)

*WD CaviarRE WD3200SB/SD,WD2500SB/SD (320GB,250GB,160GB,120GB/RAID/Pro):
**http://www.xyzcomputing.com/index.php?option=content&task=view&id=416&I
**http://www.xbitlabs.com/articles/storage/display/wd2500sd.html
**http://www.gamepc.com/labs/view_content.asp?id=caviarre&page=1

*Hitachi Deskstar 7K500 (500GB):
**http://www.storagereview.com/articles/200511/HDS725050KLA360_1.html
**http://www.tomshardware.com/storage/20050714/index.html

*Hitachi Deskstar T7K250 (250GB, 160GB/SATA-II):
**http://www.tomshardware.com/storage/20050523/index.html
**http://www.anandtech.com/storage/showdoc.aspx?i=2454

*WD CaviarSE16 WD2500KS (250GB/SATA-II/16MB):
**http://www.storagereview.com/articles//200507/20050705WD2500KS_1.html

*WD CaviarSE WD1600JS (250GB, 200GB, 160GB, 120GB/SATA-II):
**http://www.anandtech.com/storage/showdoc.aspx?i=2454

*Samsung Spinpoint P120 (250GB):
**http://www.tomshardware.com/storage/20050427/index.html

*Samsung Spinpoint P80SD (160GB, 120GB, 80GB, 40GB/SATA-II):
**http://www.anandtech.com/storage/showdoc.aspx?i=2454

*Maxtor DiamondMax10 (300GB, 250GB, 160GB, 80GB):
**http://www.tomshardware.com/storage/20050418/index.html

*Seagate Barracuda 7200.8 (400GB, 300GB, 250GB, 200GB):
**http://www.tomshardware.com/storage/20050317/index.html
**http://www.storagereview.com/articles/200504/20050414ST3400832AS_1.html
**http://www.anandtech.com/storage/showdoc.aspx?i=2396

*WD CaviarSE WD3200JB/JD (320GB):
**http://www.tomshardware.com/storage/20050217/index.html
**http://www.storagereview.com/articles/200505/20050518WD3200JD_1.html

====[2004]====

*Samsung Spinpoint P80 SP1614C, SP1213C, SP0812C (160GB, 120GB, 80GB):
**http://www.storagereview.com/articles/200410/20041016SP1614C_1.html

*Samsung Spinpoint P80 SP1614N, SP1213N, SP0812N (160GB, 120GB, 80GB):
**http://www.storagereview.com/articles/200401/20040112SP1614N_1.html

*Hitachi Deskstar 7K400 (400GB):
**http://www.tomshardware.com/storage/20040820/index.html
**http://www.storagereview.com/articles/200407/20040729revisit_1.html
**http://www.xbitlabs.com/articles/storage/display/hitachi-7k400.html
**http://www.anandtech.com/storage/showdoc.aspx?i=2116

*Maxtor MaXLine+III (300GB, 250GB):
**http://www.tomshardware.com/storage/20040820/index.html
**http://www.storagereview.com/articles/200406/200406207B300S0_1.html
**http://www.storagereview.com/articles/200410/200410087B300S0-2_1.html
**http://www.anandtech.com/storage/showdoc.aspx?i=2094

*Seagate Barracuda 7200.7 (200GB):
**http://www.tomshardware.com/storage/20040209/index.html
**http://www.storagereview.com/articles/200407/20040729revisit_1.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*Seagate Barracuda 7200.7 (160GB, 120GB, 80GB, 40GB):
**http://www.tomshardware.com/storage/20040123/index.html
**http://www.tomshardware.com/storage/20031219/index.html
**http://www.storagereview.com/articles/200306/20030615ST3160023A_1.html
**http://www.xbitlabs.com/articles/storage/display/seagate-barracuda72007.html

*WD Raptor WD740GD (74GB/10000rpm):
**http://www.tomshardware.com/storage/20040123/index.html
**http://www.storagereview.com/articles/200401/20040126WD740GD_1.html
**http://www.xyzcomputing.com/index.php?option=content&task=view&id=206&Itemid=2
**http://www.xbitlabs.com/articles/storage/display/wd-raptor2.html
**http://www.anandtech.com/storage/showdoc.aspx?i=2073

====[2003]====

*Samsung Spinpoint P80 SP1604N (160GB, 120GB, 80GB, 60GB):
**http://www.tomshardware.com/storage/20031219/index.html

*Excelstor J360 (60GB, 40GB, 30GB, 20GB):
**http://www.tomshardware.com/storage/20031219/index.html

*WD Caviar WD800JB (80GB, 120GB):
**http://www.tomshardware.com/storage/20031219/index.html
**http://www.storagereview.com/articles/200205/20020529WD800JB_1.html

*Hitachi Deskstar 7K250 (250GB, 160GB, 80GB):
**http://www.tomshardware.com/storage/20031001/index.html
**http://www.tomshardware.com/storage/200311141/index.html
**http://www.storagereview.com/articles/200310/20031007HDS722525VLSA80_1.html
**http://www.xbitlabs.com/articles/storage/display/hitachi-7k250.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*Maxtor MaXLine+II (300GB/5400rpm/2MB):
**http://www.tomshardware.com/storage/20031008/index.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*WD Raptor WD360GD (36GB/10000rpm):
**http://www.tomshardware.com/storage/20030501/index.html
**http://www.storagereview.com/articles/200303/20030320WD360GD_1.html
**http://www.anandtech.com/storage/showdoc.aspx?i=1799

*WD CaviarSE WD2500JD (250GB):
**http://www.tomshardware.com/storage/200311141/index.html
**http://www.storagereview.com/articles/200309/20030904WD2500JD_1.html
**http://www.storagereview.com/articles/200407/20040729revisit_1.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*Maxtor MaXLine+II (250GB):
**http://www.tomshardware.com/storage/20030402/index.html
**http://www.storagereview.com/articles/200305/200305227Y250P0_1.html
**http://www.storagereview.com/articles/200309/200309147Y250M0_1.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*WD CaviarSE WD2500JB (250GB):
**http://www.tomshardware.com/storage/20030402/index.html
**http://www.storagereview.com/articles/200304/20030417WD2500JB_1.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*Maxtor DiamondMax Plus9 (250GB, 200GB, 160GB, 120GB, 80GB):
**http://www.tomshardware.com/storage/20030314/index.html
**http://www.tomshardware.com/storage/200311141/index.html
**http://www.storagereview.com/articles/200302/200302276Y200x0_1.html
**http://www.xbitlabs.com/articles/storage/display/4-maxtor-hdds.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

====[2002]====

*WD CaviarSE WD2000JB (200GB):
**http://www.tomshardware.com/storage/20021011/index.html
**http://www.storagereview.com/articles/200210/20021018WD2000xB_1.html
**http://www.xbitlabs.com/articles/storage/display/16hdd-200.html

*WD CaviarSE WD1200JB (120GB):
**http://www.tomshardware.com/storage/20020305/index.html
**http://www.storagereview.com/articles/200201/20020124WD1200JB_1.html

*Samsung SV1204H (120GB):
**http://www.tomshardware.com/storage/20020920/index.html

''NB! Viimased review'd on mitu aastat vanad, vahepeal võib olla samu mudeleid (kui neid veel toodetakse) uuendatud-parendatud!''

==Soovitused kõvaketta valimiseks (3,5" ATA/SATA 7200rpm)==
===Maht===
*40GB asemel tasub igal juhul valida 80GB, hinnavahe on olematu.
*120GB kettaid ei soovita, parem valida siis juba 80GB või 160GB.
*200GB kettaid ei soovita, ainsana on sobilikud Seagate 200GB mudelid.
*Soodsaima hinnaga 1GB kohta on hetkel (10/2005) 200-250-300 GB kettad.
===Kiirus===
*Hitachi on kõige kiirema seek'iga 7200rpm IDE ketas, sobib boot-kettaks.
*Hitachi 160GB,250GB puhul eelista seeriat T7K250 (T=Turbo), mitte 7K250.
*Seagate 7200.8 ja 7200.9 on miskipärast eriti aeglase seek'iga (11 ms).
*Suurema mahuga High-Density platterid annavad kiirema järjestlugemise.
*Kiireima järjestlugemisega on Seagate 7200.8 ja 7200.9 (133/160 platter).
*Kiirem järjestlugemine on kasulik suurte failide puhul (nt. videoarhiiv).
*Reaalselt ei saavuta testide kiirusi (väiksed failid, fragmenteerumine).
===Jahedus ja vaikus===
*WD 3200xx ja KS,JS seeriad ning Samsung on jahedad, vaiksed ja kiired.
*Seagate enamus mudeleid on samuti vaiksed, eriti just idle-rezhiimis.
*Seagate on kuumemat sorti tüüp, kuid talub seda hästi ka ilma jahutuseta.
*Maxtor DiamondMax 7,8,9 seeriad on liiga kuumad ja enamasti ka lärmakad.
*Hitachi 400,500GB puudus on palju päid ja plattereid (kuum, kapriisne).
*Mida vähem plattereid kettas on, seda jahedam, vaiksem, töökindlam.
===Töökindlus===
*Seagate uus NL35 (NearLine) seeria on "enterprise pro" töökindlusega.
*WD3200SB/SD,WD4000YR on "enterprise pro" töökindlusega ja RAID'is sobiv.
*Enterprise pro mudelite peamine erinevus on valitud paremad eksemplarid.
*RAID pro-mudelite täiendav erinevus on optimeeritud ketta firmware (TLER).
*RAID pro-mudeleid ei ole soovitav kasutada üksiku (non-RAID) kettana!
*Seagate annab 5a garantii kõigile oma toodetele, ka laiatarbeseeriatele.
*Väldi Maxtor DiamondMax 7, 8, 9 seeriaid, WD2000JB/JD, WD2500JB/JD mudeleid.
*Maxtori puhul eelista MaXLine+III seeriat, teine valik on DiamondMax 10.
*Excelstor on low-end bränd, võrreldavat kvaliteeti ei saagi temalt nõuda.
===Puhver===
*Valida tuleb 8MB (või 16MB) puhvriga ketaste hulgast. 2MB on eilne päev.
*NCQ funktsioon toimib vaid koos seda toetava emaplaadi või kontrolleriga.
*NCQ reaalne efekt on erinevate testide andmetel tühine 5...15% (kui sedagi).
===Liides===
*SATA ketaste peamine eelis ATA ees on peenike kaabel ja omaette datakanal.
*SATA ei anna kiirusevõitu ATA suhtes, kuid SATA kettad on kaasaegsemad.
*SATA-II ei anna kiirusevõitu SATA suhtes, kuid SATA-II on kaasaegsemad.
===Toide===
*Kõvaketas võtab käivitamisel lühiajaliselt ca. 2...3A voolu +12V toiteahelas.
*Tööolukorras tarbivad tänapäeva kõvakettad (+5 ja +12V kokku) 8...16 W.
===KOKKUVÕTE===
*Ühe kettamudeli eksemplarid võivad erineda rohkem kui kahe tootja kettad!
*Pole olemas absoluutselt üheselt parimate kõikide omadustega kõvaketast!
*Pole olemas absoluutselt töökindlat kettamudelit, igaüks võib tõrkuda!
*Soovid ikka parimat? Vali WD3200(JD/JB), WD2500KS, Hitachi:T7K250(250/160)
*Soovid ikka ProLine? Vali WD3200(SD/SB), WD4000YR, NL35, MaXLine(+III/Pro)

==Kasulikku teavet==
===Platterid===

====Tavalised üldlevinud kõvakettad====
*040GB = 1 x 80 (nuditud)
*080GB = 1 x 80
*120GB = 2 x 80 (nuditud)
*160GB = 2 x 80
*200GB = 3 x 80 (nuditud)
*250GB = 3 x 80
*400GB = 5 x 80

====Erandid ehk uued high-density platteritega kõvakettad====
*Seagate 7200.9 040GB = 1 x 160 (nuditud) või 1 x 133 (nuditud)
*Seagate 7200.9 080GB = 1 x 160 (nuditud)
*Seagate 7200.9 120GB = 1 x 160 (nuditud) või 1 x 133 (nuditud)
*Hitachi T7K250 160GB = 2 x 125 (nuditud)
*Seagate 7200.9 160GB = 1 x 160
*Seagate 7200.7 200GB = 2 x 100
*Seagate 7200.8 200GB = 2 x 100
*Seagate 7200.9 200GB = 2 x 133 (nuditud)
*Samsung spP120 200GB = 2 x 125 (nuditud)
*Hitachi T7K250 250GB = 2 x 125
*Samsung spP120 250GB = 2 x 125
*Seagate 7200.8 250GB = 2 x 133 (nuditud)
*Seagate 7200.9 250GB = 2 x 133 (nuditud)
*Seagate NL35 250GB = 2 x 133 (nuditud)
*Seagate 7200.8 300GB = 3 x 100
*Seagate 7200.9 300GB = 2 x 160 (nuditud)
*Samsung spT133 300GB = 3 x 133 (nuditud)
*Maxtor DM 10 300GB = 3 x 100
*Maxtor ML III 300GB = 3 x 100
*WDcavSE WD3000 300GB = 3 x 107 (nuditud)
*WDcavSE WD3200 320GB = 3 x 107
*WDcavSE;RE2 WD4000 400GB = 4 x 107 (nuditud)
*Seagate 7200.8 400GB = 3 x 133
*Seagate 7200.9 400GB = 3 x 133
*Seagate NL35 400GB = 3 x 133
*Samsung spT133 400GB = 3 x 133
*Maxtor DM 11 400GB = 3 x 133
*Maxtor QuickView 400GB = 3 x 133
*Hitachi 7K500 500GB = 5 x 100
*Seagate 7200.9 500GB = 4 x 133 (nuditud)
*Maxtor DM 11 500GB = 4 x 133 (nuditud)
*Maxtor QuickView 500GB = 4 x 133 (nuditud)
*Maxtor ML Pro 500GB = 4 x 133 (nuditud)
''NB! nimekiri pole täielik...''

===Kõvaketaste reaalsed (''binary'') mahud===

*HDD 040 GB = 037.25 GiB
*HDD 080 GB = 074.50 GiB
*HDD 120 GB = 111.76 GiB
*HDD 160 GB = 149.01 GiB
*HDD 200 GB = 186.26 GiB
*HDD 250 GB = 232.83 GiB
*HDD 300 GB = 279.40 GiB
*HDD 320 GB = 298.02 GiB
*HDD 400 GB = 372.53 GiB
*HDD 500 GB = 465.66 GiB

''Tegelik maht võib olla tehtud veidi suurem (ca. 25 MB iga 100 GB kohta). Täpse mahu väljendab konkreetse ketta labelile trükitud LBA number (512-baidiste kasutajasektorite arv).''

*'''Praktiline kasutusnäide:'''
**HDD 500 GB = 200000/570000 digitaalfotot (resolutsiooniga 5 megapix / 2 megapix)
**HDD 500 GB = 15000/150000 muusikapala (keskmise pikkusega 3:10) wav/mp3-formaadis
**HDD 500 GB = 1000 muusika-CD plaati (keskmise pikkusega 47 minutit) wav-formaadis
**HDD 500 GB = 50...500+ tundi digitaalvideot (oleneb resolutsioonist ja pakkimisest)

===Garantii===

Kehtib tootmises olevate 3,5" 7200rpm kettaseeriate puhul, vanadega on midaiganes muudmoodi, ka 2,5" ja väliste kettakarpidega võib teistmoodi olla (välistel on tavaliselt 1a); Samuti on kõik SCSI kettad tavaliselt 5a garantiiga igal tootjal; Eesti edasimüüjad võivad aga üldse piirduda 1a garantiiga.

*SEAGATE'i garantii: 5a
*WD garantii: 5a (Caviar RE, Raptor); 3a (Caviar SE), alates 18.07.2005, osalt ka varem.
*HITACHI garantii: 3a, alates 25.04.2005
*SAMSUNG'i garantii: 3a
*MAXTOR'i garantii: 5a (MaXLine); 3a (DiamondMax), alates 12.09.2004
*EXCELSTOR'i garantii: 3a

''Tehasegarantii arvestatakse tavaliselt ketta tehasest hulgimüüjale saatmise kuupäevast, mitte ketta valmistamise kuupäevast (aga võib olla ka teisiti).''

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&u=19480 8]

[[Kasutaja:Taifunk|Taifunk]] 21:23, 16 okt 2005 (EEST)

Arutelu:Lihtsa võrguanalüsaatori ehitamine

2005-11-03T22:29:15Z

Cbr:

Keegi võiks mingid alapealkirjad panna. Mulle kui mittepädevale võrguinimesele on suht keeruline teksti jälgida ja veel raskem seda lõigutada ;) [[Kasutaja:Cbr|Cbr]] 4. november 2005, kell 00.29 (EET)

Lihtsa võrguanalüsaatori ehitamine

2005-11-03T22:25:06Z

Cbr:

[[Kategooria:Kasulikud Näpunäited]]
[[Kategooria:Andmeside]]
[[Kategooria:Võrgukihi juhendid]]
Ilmselt on mõistlik tutvust teha [http://www.ethereal.com Ethereali] nimelise programmiga (võib kasutada ka mõnda teist võrguanalüsaatorit, näiteks tcpdump), mille abil tasuks uurida nii "sisevõrgu" masinasse tulevat (ning ehk ka väljuvat) liiklust kui ka seda liiklust, mis toimub kaablimodemi ning NAT'iva routeri vahel.

Sisevõrgus olevasse masinasse saabuvat liiklust saab analüüsida sisevõrgu masinas endas, kaablimodemi ning routeri vahelise liikluse analüüsimiseks on kõige lihtsam laenata või osta HUB (kindlasti hub, mitte switch), mille abil siis ühendada sellesse võrku veel üks seade, mis kuulab seda liiklust pealt.

Testimiseks on kõige lihtsam hankida ligipääs mõnesse Internetis asuvasse Unixilaadsesse süsteemi (paremal puudumisel võib ju muidugi ka naabrimees või keegi teine oma lauaarvutist üritada ühenduda), mille aadress (ma mõtlen reaalne interneti aadress) on teada. Teadaolev Internetis asuva süsteemi aadress anda etherealile filtriks kujul ip.addr == aadress (see konstruktsioon määrab filtrisse nii sellelt aadressilt tulevad kui ka sellele aadressile saadetavad paketid). Kaval on Etherealile öelda, et kõik paketid, mis püütakse, ka kohe välja näidataks (loomulikult on sellisel juhul mõistlik, kui võrgu peal on nii vähe liiklust kui võimalik).

Olles sedasi analüsaatori püsti saanud (ahjaa promisc moodis (sellisel juhul edastab võrgukaart OSile ka selle liikluse, mis ei ole talle mõeldud, vajalik kaablimodemi ja routeri vahelise liikluse pealt kuulamiseks) kuulamiseks on reeglina vaja superkasutaja õigusi), tuleks luua väljastpoolt ühendus oma välisaadressi sellesse porti, kus me eeldame teenust olevat. Kõige lihtsam on seda teha telneti abil: <code>telnet 1.2.3.4 1234</code>, kus <code>1.2.3.4</code> on IP aadress ning <code>1234</code> on vastav TCP port.

Algatuseks on mõistlik kuulata teenust pakkuvast masinast - kui välisilmast ühendust luues filtrisse ühtegi paketti ei tulnud, on ilmselge, et viga tuleb otsida routerist(vt. ka allapoole nn. "keerulisem olukord"). Kui aga ühendus ilmub, tuleb hakata analüüsima, mis siis valesti on.

Et asjatundmatu kasutaja ei pruugi esimese hooga Ethereali väljundist suurt midagi aru saada, siis toome siinkohal ühe pisikene näite õnnestunud ühendusest (ehk siis... nõnda peavad asjad olema, kui ei ole, on analoogia põhjal ilmselt üsna lihtne oletada, mis on valesti):

Olukord on järgmine: võrgu väline (reaalselt eksisteeriv) interneti aadress on <code>217.159.159.181</code>, millel vastab router, milles on TCP/666 DNAT'itud "sisevõrgus" asuva masina, aadressiga <code>192.168.2.20</code>, pordile TCP/22, millelt vastab SSH. Selle teenusega üritatakse ühendust võtta süsteemist aadressiga <code>194.204.19.34</code> järgmiselt:

<pre>
wookie@piixus:~$ telnet 217.159.159.181 666
Trying 217.159.159.181...
Connected to 217.159.159.181.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.9p1
^]
telnet> quit
Connection closed.
</pre>

Sisevõrgus asuva masina seisukohalt näeb ühendus välja järgmine:

[[Pilt:ethereal1.png|800px]]

ISP ning minu routeri vahel toimus samal ajal aga järgmine:

[[Pilt:ethereal-yhendus-valine.png|800px]]

Olulised on siinkohal kolm esimest paketti:
Iga TCP ühendus algab ühenduse alustaja poolt saadetud [SYN] paketiga. Me märkame, et sisevõrgu masina jaoks on paketi sihtaadress (''destination adress'') <code>192.168.2.20</code>, kuid teiselt pildilt näeme, et tegelikult saabus pakett muidugi aadressile <code>217.159.159.181</code> - router transleeris paketi sihtaadressi selliselt, et see sai edasi liikuda meie privaatvõrgu aadressile, samuti me märkame, et antud juhul jättis router paketi lähteaadressi (source address) muutmata. Samasugust transleerimist võime tähele panna pordi numbritega - routerisse saabus pakett pordile TCP/666, kuid sisevõrgu masinasse pordile TCP/22 (ssh).

Kuna [SYN] pakett saabus antud juhul õige masina õigesse porti (sellisesse, mida mõni teenus kuulab), vastab meie masin [SYN, ACK] paketiga, antud juhul aadressile <code>194.204.19.34</code> (sealt ju ühendus tuli). Nüüd on äärmiselt oluline uurida, kas see pakett ruuterist <code>194.204.19.34</code> aadressile välja ikka saadeti. Vaatame välise ühenduse pilti ning näeme, et router saatis [SYN, ACK] paketti aadressilt <code>217.159.159.181</code> aadressile <code>194.204.19.34</code>, samal ajal kui meie sisevõrgus olev masin hoopis aadressilt <code>192.168.2.20</code> aadressile <code>194.204.19.34</code> - loogiline, pakett peab antud juhtumil väljuma routeri source aadressiga, ehk siis reaalselt internetis eksisteeriva aadressiga. Kui paketi lähteaadress oleks teistsugune, näiteks <code>192.168.2.20</code>, ei oleks ühenduse loomine õnnestunud, sest ühendust algatava masina jaoks oleks see olnud kui SYN,ACK pakett mingilt täiesti tundmatult aadressilt, millega ta pole kunagi üritanud suhelda. Seda, et meie routeris <code>217.159.159.181</code>'st saab maagiliselt <code>192.168.2.20</code>, <code>194.204.19.34</code> ei tea ega saa ka kunagi teadma. Samuti, täpselt samasugune transleerimine toimub pordinumbritega - sisevõrgu masin vastab pordist (source port) TCP/22 (ssh), kuid routerist väljuv pakett lähtub pordist TCP/666.

Kui siiamaale juba asjad õnnestusid, siis üldiselt õnnestub ka TCP ühenduse loomiseks vajaliku kolmanda paketi (ühenduse algataja poolne vastus [ACK] "serveri" [SYN, ACK]'le) saatmine. Me märkame, et selle paketiga käitutakse sarnaselt päris esimesele paketile.

Sellest hetkest alates on ühendus loodud ning järgneb juba data: Server (meie näites siis sisevõrgus olev masin) ütleb: <code>SSH-2.0-OpenSSH_3.9p1</code>. Mida kliendis jooksev applikatsioon sellega peale hakkab, on juba tema enda mure - meie näites kasutatav telnet ei oska sellega mitte mütsigi teha, kuid kuna me juba nägime serveri poolset vastust, oleme me veendunud, et ühendust on võimalik luua ning paneme telneti hoopis kinni (mis toimub ühenduse sulgemisel võib igaüks ise jälgida, uurides kolme viimast paketti). Ahjaa.. küsite, et mida kuradit teeb siis viies, [ACK] pakett? See on lihtsalt kliendi poolne vastus, et ta sai eelmises paketis saadetud teate (<code>SSH-2.0-OpenSSH_3.9p1</code>) kenasti kätte.

Ma usun, et igaüks teab aga igaks juhuks kordame veel üle, et iga sellise NAT'itud ühenduse peale teeb router kuhugile oma mälus asuvasse tabelisse kirje, milles on kirjas, mida täpselt muudeti ning oskab selle järgi vastassuunas liikuvate pakettide välju vastupidiselt muuta, et kõik ikka õnnelikud oleks - kuidas see käib, pole antud hetkel meie asi, lihtsalt jätame meelde, et selline tabel kuskil routeri kõhus on.

Tähelepanelik lugeja kindlasti märkab, et suunal klient (kuskil interneti avarustes asuv purk) -> server (meie sisevõrgu masin) muudeti ainult pakettide sihtaadressi (destination address) ning suunal server -> klient ainult paketi lähteaadressi (source address). Enamik selliseid pordisuunamisi töötab selliselt. Niisuguses lahenduses, kus sisevõrgust interneti poole suunduvate pakettide lähteaadressi tuleb nii ehk naa transleerida, pole mõtet vastupidise NAT'i korral välisilmast saabuvate pakettide lähteaadressi muuta.

Samas... eksisteerib ka keerulisem olukord - router muudab nii siseneva paketi lähte- kui ka sihtaadressi. Sellisel juhul jääb meie sisevõrgus olevale serverile mulje nagu ta suhtleks routeri endaga. Niisugusel juhul sisevõrgus filter ip.addr == ip_aadress ei kõlba (sest sisevõrgus ju mitte keegi ei suhtle selle välise aadressiga) ning tuleks asendada keerulisema filtriga, minu puhul siis näiteks: ip.addr == <code>192.168.2.254</code> (<code>192.168.2.254</code> on minu ruuteri sisevõrgu aadress, me püüame liiklust, mida peetakse selle seadmega) või suisa ip.addr == <code>192.168.2.254</code> && tcp.port == 22 (TCP liiklus, mida peetakse routeriga, mille lähte- või sihtport on 22). Igaks juhuks ühest sellisest ühendusest pilt kah (vaadatuna siis sisevõrgu masina poolt - väljastpoolt ei muutu midagi).

[[Pilt:ethereal-yhendus-full-nat.png|800px]]

Üldiselt peaks nendest teadmistest piisama, et lihtsamate pordisuunamise probleemide põhjuseid diagnoosida. Tavaliselt, kui sellist õnnestunud ühendust võrrelda ebaõnnestunud ühenduse korral püütud pakettidega, hakkab viga vähegi tähelepaneliku süvenemise korral ise silma ning parandamine on tavaliselt juba triviaalne tegevus.
Keerukamate probleemide korral võib muidugi ka Õpetatud Kogu[tm] tunde või suisa päevi ladinakeeles päid vangutada, et välja mõelda, mis siis ikkagi peetis on, kuid praktika näitab, et enamik probleeme on tegelikult lihtsad.

Tjah, kindlasti tasub meeles pidada, et Ethereal oskab püütud pakette salvestada (jah, just nimelt File::Save) - sellised ethereali failid võivad probleemide lahendamisel vägagi abiks olla, mistõttu maksab selliste hädade korral abiküsimise kõrvalt ka mõni niisugune Ethereali fail kätesaadavaks teha.
Et kõik saaks ise uurida, siis juurde ka antud näites kasutatud ühenduste salvestused:
http://rio.ee/~wookie/tcp-yhendus
http://rio.ee/~wookie/tcp-yhendus-valine
http://rio.ee/~wookie/tcp-yhendus-full-nat

P.S.
Jah ma tean küll, et antud juhul ei ole routerist rääkimine päris korrektne, sest klassikaline router ei muuda edastatavates pakettides ei IP aadresse ega pordi numbreid, kuid antud juhul, kuna probleem on selgelt seotud NAT'iga, tundus sõna router kasutamine otstarbekam, sest NAT'iv router või NAT'i purk vms. oleks lihtsalt kohutavalt kohmakas.
Seega lugege sõna "router" antud juhul kui "see router selles konkreetses seadistuses võrguaadresse transleerimas (NAT)".

P.P.S.
Ehki meie kasutasime näites SSH teenust, mis peale ühenduse loomist ise mingit mula välja hakkab ajama, ei prugi sellist igaühel käepärast olla. Sageli on tarvis testida näiteks WWW (TCP/80) teenuse töötamist, mille puhul server jääb peale ühenduse loomist ootama, et talle mõni käsk antaks. Sellisel juhul on mõistlik telneti sisse peale ühenduse saamist kirjutada suvaline esimesena meelde tulev vandesõna või roppus ning taguda paar korda enterit. WWW server peab vastama HTML'iga, mis tahab meile öelda, et 501 Method Not Implemented või midagi muud sama roppu.

Fail:Ethereal-yhendus-full-nat.png

2005-11-03T22:23:57Z

Cbr:

Lihtsa võrguanalüsaatori ehitamine

2005-11-03T22:22:45Z

Cbr:

[[Kategooria:Kasulikud Näpunäited]]
[[Kategooria:Andmeside]]
[[Kategooria:Võrgukihi juhendid]]
Ilmselt on mõistlik tutvust teha [http://www.ethereal.com Ethereali] nimelise programmiga (võib kasutada ka mõnda teist võrguanalüsaatorit, näiteks tcpdump), mille abil tasuks uurida nii "sisevõrgu" masinasse tulevat (ning ehk ka väljuvat) liiklust kui ka seda liiklust, mis toimub kaablimodemi ning NAT'iva routeri vahel.

Sisevõrgus olevasse masinasse saabuvat liiklust saab analüüsida sisevõrgu masinas endas, kaablimodemi ning routeri vahelise liikluse analüüsimiseks on kõige lihtsam laenata või osta HUB (kindlasti hub, mitte switch), mille abil siis ühendada sellesse võrku veel üks seade, mis kuulab seda liiklust pealt.

Testimiseks on kõige lihtsam hankida ligipääs mõnesse Internetis asuvasse Unixilaadsesse süsteemi (paremal puudumisel võib ju muidugi ka naabrimees või keegi teine oma lauaarvutist üritada ühenduda), mille aadress (ma mõtlen reaalne interneti aadress) on teada. Teadaolev Internetis asuva süsteemi aadress anda etherealile filtriks kujul ip.addr == aadress (see konstruktsioon määrab filtrisse nii sellelt aadressilt tulevad kui ka sellele aadressile saadetavad paketid). Kaval on Etherealile öelda, et kõik paketid, mis püütakse, ka kohe välja näidataks (loomulikult on sellisel juhul mõistlik, kui võrgu peal on nii vähe liiklust kui võimalik).

Olles sedasi analüsaatori püsti saanud (ahjaa promisc moodis (sellisel juhul edastab võrgukaart OSile ka selle liikluse, mis ei ole talle mõeldud, vajalik kaablimodemi ja routeri vahelise liikluse pealt kuulamiseks) kuulamiseks on reeglina vaja superkasutaja õigusi), tuleks luua väljastpoolt ühendus oma välisaadressi sellesse porti, kus me eeldame teenust olevat. Kõige lihtsam on seda teha telneti abil: <code>telnet 1.2.3.4 1234</code>, kus <code>1.2.3.4</code> on IP aadress ning <code>1234</code> on vastav TCP port.

Algatuseks on mõistlik kuulata teenust pakkuvast masinast - kui välisilmast ühendust luues filtrisse ühtegi paketti ei tulnud, on ilmselge, et viga tuleb otsida routerist(vt. ka allapoole nn. "keerulisem olukord"). Kui aga ühendus ilmub, tuleb hakata analüüsima, mis siis valesti on.

Et asjatundmatu kasutaja ei pruugi esimese hooga Ethereali väljundist suurt midagi aru saada, siis toome siinkohal ühe pisikene näite õnnestunud ühendusest (ehk siis... nõnda peavad asjad olema, kui ei ole, on analoogia põhjal ilmselt üsna lihtne oletada, mis on valesti):

Olukord on järgmine: võrgu väline (reaalselt eksisteeriv) interneti aadress on <code>217.159.159.181</code>, millel vastab router, milles on TCP/666 DNAT'itud "sisevõrgus" asuva masina, aadressiga <code>192.168.2.20</code>, pordile TCP/22, millelt vastab SSH. Selle teenusega üritatakse ühendust võtta süsteemist aadressiga <code>194.204.19.34</code> järgmiselt:

<pre>
wookie@piixus:~$ telnet 217.159.159.181 666
Trying 217.159.159.181...
Connected to 217.159.159.181.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.9p1
^]
telnet> quit
Connection closed.
</pre>

Sisevõrgus asuva masina seisukohalt näeb ühendus välja järgmine:

[[Pilt:ethereal1.png|800px]]

ISP ning minu routeri vahel toimus samal ajal aga järgmine:

[[Pilt:ethereal-yhendus-valine.png|800px]]

Olulised on siinkohal kolm esimest paketti:
Iga TCP ühendus algab ühenduse alustaja poolt saadetud [SYN] paketiga. Me märkame, et sisevõrgu masina jaoks on paketi sihtaadress (''destination adress'') <code>192.168.2.20</code>, kuid teiselt pildilt näeme, et tegelikult saabus pakett muidugi aadressile <code>217.159.159.181</code> - router transleeris paketi sihtaadressi selliselt, et see sai edasi liikuda meie privaatvõrgu aadressile, samuti me märkame, et antud juhul jättis router paketi lähteaadressi (source address) muutmata. Samasugust transleerimist võime tähele panna pordi numbritega - routerisse saabus pakett pordile TCP/666, kuid sisevõrgu masinasse pordile TCP/22 (ssh).

Kuna [SYN] pakett saabus antud juhul õige masina õigesse porti (sellisesse, mida mõni teenus kuulab), vastab meie masin [SYN, ACK] paketiga, antud juhul aadressile <code>194.204.19.34</code> (sealt ju ühendus tuli). Nüüd on äärmiselt oluline uurida, kas see pakett ruuterist <code>194.204.19.34</code> aadressile välja ikka saadeti. Vaatame välise ühenduse pilti ning näeme, et router saatis [SYN, ACK] paketti aadressilt <code>217.159.159.181</code> aadressile <code>194.204.19.34</code>, samal ajal kui meie sisevõrgus olev masin hoopis aadressilt <code>192.168.2.20</code> aadressile <code>194.204.19.34</code> - loogiline, pakett peab antud juhtumil väljuma routeri source aadressiga, ehk siis reaalselt internetis eksisteeriva aadressiga. Kui paketi lähteaadress oleks teistsugune, näiteks <code>192.168.2.20</code>, ei oleks ühenduse loomine õnnestunud, sest ühendust algatava masina jaoks oleks see olnud kui SYN,ACK pakett mingilt täiesti tundmatult aadressilt, millega ta pole kunagi üritanud suhelda. Seda, et meie routeris <code>217.159.159.181</code>'st saab maagiliselt <code>192.168.2.20</code>, <code>194.204.19.34</code> ei tea ega saa ka kunagi teadma. Samuti, täpselt samasugune transleerimine toimub pordinumbritega - sisevõrgu masin vastab pordist (source port) TCP/22 (ssh), kuid routerist väljuv pakett lähtub pordist TCP/666.

Kui siiamaale juba asjad õnnestusid, siis üldiselt õnnestub ka TCP ühenduse loomiseks vajaliku kolmanda paketi (ühenduse algataja poolne vastus [ACK] "serveri" [SYN, ACK]'le) saatmine. Me märkame, et selle paketiga käitutakse sarnaselt päris esimesele paketile.

Sellest hetkest alates on ühendus loodud ning järgneb juba data: Server (meie näites siis sisevõrgus olev masin) ütleb: <code>SSH-2.0-OpenSSH_3.9p1</code>. Mida kliendis jooksev applikatsioon sellega peale hakkab, on juba tema enda mure - meie näites kasutatav telnet ei oska sellega mitte mütsigi teha, kuid kuna me juba nägime serveri poolset vastust, oleme me veendunud, et ühendust on võimalik luua ning paneme telneti hoopis kinni (mis toimub ühenduse sulgemisel võib igaüks ise jälgida, uurides kolme viimast paketti). Ahjaa.. küsite, et mida kuradit teeb siis viies, [ACK] pakett? See on lihtsalt kliendi poolne vastus, et ta sai eelmises paketis saadetud teate (<code>SSH-2.0-OpenSSH_3.9p1</code>) kenasti kätte.

Ma usun, et igaüks teab aga igaks juhuks kordame veel üle, et iga sellise NAT'itud ühenduse peale teeb router kuhugile oma mälus asuvasse tabelisse kirje, milles on kirjas, mida täpselt muudeti ning oskab selle järgi vastassuunas liikuvate pakettide välju vastupidiselt muuta, et kõik ikka õnnelikud oleks - kuidas see käib, pole antud hetkel meie asi, lihtsalt jätame meelde, et selline tabel kuskil routeri kõhus on.

Tähelepanelik lugeja kindlasti märkab, et suunal klient (kuskil interneti avarustes asuv purk) -> server (meie sisevõrgu masin) muudeti ainult pakettide sihtaadressi (destination address) ning suunal server -> klient ainult paketi lähteaadressi (source address). Enamik selliseid pordisuunamisi töötab selliselt. Niisuguses lahenduses, kus sisevõrgust interneti poole suunduvate pakettide lähteaadressi tuleb nii ehk naa transleerida, pole mõtet vastupidise NAT'i korral välisilmast saabuvate pakettide lähteaadressi muuta.

Samas... eksisteerib ka keerulisem olukord - router muudab nii siseneva paketi lähte- kui ka sihtaadressi. Sellisel juhul jääb meie sisevõrgus olevale serverile mulje nagu ta suhtleks routeri endaga. Niisugusel juhul sisevõrgus filter ip.addr == ip_aadress ei kõlba (sest sisevõrgus ju mitte keegi ei suhtle selle välise aadressiga) ning tuleks asendada keerulisema filtriga, minu puhul siis näiteks: ip.addr == <code>192.168.2.254</code> (<code>192.168.2.254</code> on minu ruuteri sisevõrgu aadress, me püüame liiklust, mida peetakse selle seadmega) või suisa ip.addr == <code>192.168.2.254</code> && tcp.port == 22 (TCP liiklus, mida peetakse routeriga, mille lähte- või sihtport on 22). Igaks juhuks ühest sellisest ühendusest pilt kah (vaadatuna siis sisevõrgu masina poolt - väljastpoolt ei muutu midagi) http://rio.ee/~wookie/tcp-yhendus-full-nat.png

Üldiselt peaks nendest teadmistest piisama, et lihtsamate pordisuunamise probleemide põhjuseid diagnoosida. Tavaliselt, kui sellist õnnestunud ühendust võrrelda ebaõnnestunud ühenduse korral püütud pakettidega, hakkab viga vähegi tähelepaneliku süvenemise korral ise silma ning parandamine on tavaliselt juba triviaalne tegevus.
Keerukamate probleemide korral võib muidugi ka Õpetatud Kogu[tm] tunde või suisa päevi ladinakeeles päid vangutada, et välja mõelda, mis siis ikkagi peetis on, kuid praktika näitab, et enamik probleeme on tegelikult lihtsad.

Tjah, kindlasti tasub meeles pidada, et Ethereal oskab püütud pakette salvestada (jah, just nimelt File::Save) - sellised ethereali failid võivad probleemide lahendamisel vägagi abiks olla, mistõttu maksab selliste hädade korral abiküsimise kõrvalt ka mõni niisugune Ethereali fail kätesaadavaks teha.
Et kõik saaks ise uurida, siis juurde ka antud näites kasutatud ühenduste salvestused:
http://rio.ee/~wookie/tcp-yhendus
http://rio.ee/~wookie/tcp-yhendus-valine
http://rio.ee/~wookie/tcp-yhendus-full-nat

P.S.
Jah ma tean küll, et antud juhul ei ole routerist rääkimine päris korrektne, sest klassikaline router ei muuda edastatavates pakettides ei IP aadresse ega pordi numbreid, kuid antud juhul, kuna probleem on selgelt seotud NAT'iga, tundus sõna router kasutamine otstarbekam, sest NAT'iv router või NAT'i purk vms. oleks lihtsalt kohutavalt kohmakas.
Seega lugege sõna "router" antud juhul kui "see router selles konkreetses seadistuses võrguaadresse transleerimas (NAT)".

P.P.S.
Ehki meie kasutasime näites SSH teenust, mis peale ühenduse loomist ise mingit mula välja hakkab ajama, ei prugi sellist igaühel käepärast olla. Sageli on tarvis testida näiteks WWW (TCP/80) teenuse töötamist, mille puhul server jääb peale ühenduse loomist ootama, et talle mõni käsk antaks. Sellisel juhul on mõistlik telneti sisse peale ühenduse saamist kirjutada suvaline esimesena meelde tulev vandesõna või roppus ning taguda paar korda enterit. WWW server peab vastama HTML'iga, mis tahab meile öelda, et 501 Method Not Implemented või midagi muud sama roppu.

Fail:Ethereal-yhendus-valine.png

2005-11-03T22:22:06Z

Cbr:

Lihtsa võrguanalüsaatori ehitamine

2005-11-03T22:20:48Z

Cbr:

[[Kategooria:Kasulikud Näpunäited]]
[[Kategooria:Andmeside]]
[[Kategooria:Võrgukihi juhendid]]
Ilmselt on mõistlik tutvust teha [http://www.ethereal.com Ethereali] nimelise programmiga (võib kasutada ka mõnda teist võrguanalüsaatorit, näiteks tcpdump), mille abil tasuks uurida nii "sisevõrgu" masinasse tulevat (ning ehk ka väljuvat) liiklust kui ka seda liiklust, mis toimub kaablimodemi ning NAT'iva routeri vahel.

Sisevõrgus olevasse masinasse saabuvat liiklust saab analüüsida sisevõrgu masinas endas, kaablimodemi ning routeri vahelise liikluse analüüsimiseks on kõige lihtsam laenata või osta HUB (kindlasti hub, mitte switch), mille abil siis ühendada sellesse võrku veel üks seade, mis kuulab seda liiklust pealt.

Testimiseks on kõige lihtsam hankida ligipääs mõnesse Internetis asuvasse Unixilaadsesse süsteemi (paremal puudumisel võib ju muidugi ka naabrimees või keegi teine oma lauaarvutist üritada ühenduda), mille aadress (ma mõtlen reaalne interneti aadress) on teada. Teadaolev Internetis asuva süsteemi aadress anda etherealile filtriks kujul ip.addr == aadress (see konstruktsioon määrab filtrisse nii sellelt aadressilt tulevad kui ka sellele aadressile saadetavad paketid). Kaval on Etherealile öelda, et kõik paketid, mis püütakse, ka kohe välja näidataks (loomulikult on sellisel juhul mõistlik, kui võrgu peal on nii vähe liiklust kui võimalik).

Olles sedasi analüsaatori püsti saanud (ahjaa promisc moodis (sellisel juhul edastab võrgukaart OSile ka selle liikluse, mis ei ole talle mõeldud, vajalik kaablimodemi ja routeri vahelise liikluse pealt kuulamiseks) kuulamiseks on reeglina vaja superkasutaja õigusi), tuleks luua väljastpoolt ühendus oma välisaadressi sellesse porti, kus me eeldame teenust olevat. Kõige lihtsam on seda teha telneti abil: <code>telnet 1.2.3.4 1234</code>, kus <code>1.2.3.4</code> on IP aadress ning <code>1234</code> on vastav TCP port.

Algatuseks on mõistlik kuulata teenust pakkuvast masinast - kui välisilmast ühendust luues filtrisse ühtegi paketti ei tulnud, on ilmselge, et viga tuleb otsida routerist(vt. ka allapoole nn. "keerulisem olukord"). Kui aga ühendus ilmub, tuleb hakata analüüsima, mis siis valesti on.

Et asjatundmatu kasutaja ei pruugi esimese hooga Ethereali väljundist suurt midagi aru saada, siis toome siinkohal ühe pisikene näite õnnestunud ühendusest (ehk siis... nõnda peavad asjad olema, kui ei ole, on analoogia põhjal ilmselt üsna lihtne oletada, mis on valesti):

Olukord on järgmine: võrgu väline (reaalselt eksisteeriv) interneti aadress on <code>217.159.159.181</code>, millel vastab router, milles on TCP/666 DNAT'itud "sisevõrgus" asuva masina, aadressiga <code>192.168.2.20</code>, pordile TCP/22, millelt vastab SSH. Selle teenusega üritatakse ühendust võtta süsteemist aadressiga <code>194.204.19.34</code> järgmiselt:

<pre>
wookie@piixus:~$ telnet 217.159.159.181 666
Trying 217.159.159.181...
Connected to 217.159.159.181.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.9p1
^]
telnet> quit
Connection closed.
</pre>

Sisevõrgus asuva masina seisukohalt näeb ühendus välja järgmine:

[[Pilt:ethereal1.png|800px]]

ISP ning minu routeri vahel toimus samal ajal aga järgmine: http://rio.ee/~wookie/tcp-yhendus-valine.png

Olulised on siinkohal kolm esimest paketti:
Iga TCP ühendus algab ühenduse alustaja poolt saadetud [SYN] paketiga. Me märkame, et sisevõrgu masina jaoks on paketi sihtaadress (''destination adress'') <code>192.168.2.20</code>, kuid teiselt pildilt näeme, et tegelikult saabus pakett muidugi aadressile <code>217.159.159.181</code> - router transleeris paketi sihtaadressi selliselt, et see sai edasi liikuda meie privaatvõrgu aadressile, samuti me märkame, et antud juhul jättis router paketi lähteaadressi (source address) muutmata. Samasugust transleerimist võime tähele panna pordi numbritega - routerisse saabus pakett pordile TCP/666, kuid sisevõrgu masinasse pordile TCP/22 (ssh).

Kuna [SYN] pakett saabus antud juhul õige masina õigesse porti (sellisesse, mida mõni teenus kuulab), vastab meie masin [SYN, ACK] paketiga, antud juhul aadressile <code>194.204.19.34</code> (sealt ju ühendus tuli). Nüüd on äärmiselt oluline uurida, kas see pakett ruuterist <code>194.204.19.34</code> aadressile välja ikka saadeti. Vaatame välise ühenduse pilti ning näeme, et router saatis [SYN, ACK] paketti aadressilt <code>217.159.159.181</code> aadressile <code>194.204.19.34</code>, samal ajal kui meie sisevõrgus olev masin hoopis aadressilt <code>192.168.2.20</code> aadressile <code>194.204.19.34</code> - loogiline, pakett peab antud juhtumil väljuma routeri source aadressiga, ehk siis reaalselt internetis eksisteeriva aadressiga. Kui paketi lähteaadress oleks teistsugune, näiteks <code>192.168.2.20</code>, ei oleks ühenduse loomine õnnestunud, sest ühendust algatava masina jaoks oleks see olnud kui SYN,ACK pakett mingilt täiesti tundmatult aadressilt, millega ta pole kunagi üritanud suhelda. Seda, et meie routeris <code>217.159.159.181</code>'st saab maagiliselt <code>192.168.2.20</code>, <code>194.204.19.34</code> ei tea ega saa ka kunagi teadma. Samuti, täpselt samasugune transleerimine toimub pordinumbritega - sisevõrgu masin vastab pordist (source port) TCP/22 (ssh), kuid routerist väljuv pakett lähtub pordist TCP/666.

Kui siiamaale juba asjad õnnestusid, siis üldiselt õnnestub ka TCP ühenduse loomiseks vajaliku kolmanda paketi (ühenduse algataja poolne vastus [ACK] "serveri" [SYN, ACK]'le) saatmine. Me märkame, et selle paketiga käitutakse sarnaselt päris esimesele paketile.

Sellest hetkest alates on ühendus loodud ning järgneb juba data: Server (meie näites siis sisevõrgus olev masin) ütleb: <code>SSH-2.0-OpenSSH_3.9p1</code>. Mida kliendis jooksev applikatsioon sellega peale hakkab, on juba tema enda mure - meie näites kasutatav telnet ei oska sellega mitte mütsigi teha, kuid kuna me juba nägime serveri poolset vastust, oleme me veendunud, et ühendust on võimalik luua ning paneme telneti hoopis kinni (mis toimub ühenduse sulgemisel võib igaüks ise jälgida, uurides kolme viimast paketti). Ahjaa.. küsite, et mida kuradit teeb siis viies, [ACK] pakett? See on lihtsalt kliendi poolne vastus, et ta sai eelmises paketis saadetud teate (<code>SSH-2.0-OpenSSH_3.9p1</code>) kenasti kätte.

Ma usun, et igaüks teab aga igaks juhuks kordame veel üle, et iga sellise NAT'itud ühenduse peale teeb router kuhugile oma mälus asuvasse tabelisse kirje, milles on kirjas, mida täpselt muudeti ning oskab selle järgi vastassuunas liikuvate pakettide välju vastupidiselt muuta, et kõik ikka õnnelikud oleks - kuidas see käib, pole antud hetkel meie asi, lihtsalt jätame meelde, et selline tabel kuskil routeri kõhus on.

Tähelepanelik lugeja kindlasti märkab, et suunal klient (kuskil interneti avarustes asuv purk) -> server (meie sisevõrgu masin) muudeti ainult pakettide sihtaadressi (destination address) ning suunal server -> klient ainult paketi lähteaadressi (source address). Enamik selliseid pordisuunamisi töötab selliselt. Niisuguses lahenduses, kus sisevõrgust interneti poole suunduvate pakettide lähteaadressi tuleb nii ehk naa transleerida, pole mõtet vastupidise NAT'i korral välisilmast saabuvate pakettide lähteaadressi muuta.

Samas... eksisteerib ka keerulisem olukord - router muudab nii siseneva paketi lähte- kui ka sihtaadressi. Sellisel juhul jääb meie sisevõrgus olevale serverile mulje nagu ta suhtleks routeri endaga. Niisugusel juhul sisevõrgus filter ip.addr == ip_aadress ei kõlba (sest sisevõrgus ju mitte keegi ei suhtle selle välise aadressiga) ning tuleks asendada keerulisema filtriga, minu puhul siis näiteks: ip.addr == <code>192.168.2.254</code> (<code>192.168.2.254</code> on minu ruuteri sisevõrgu aadress, me püüame liiklust, mida peetakse selle seadmega) või suisa ip.addr == <code>192.168.2.254</code> && tcp.port == 22 (TCP liiklus, mida peetakse routeriga, mille lähte- või sihtport on 22). Igaks juhuks ühest sellisest ühendusest pilt kah (vaadatuna siis sisevõrgu masina poolt - väljastpoolt ei muutu midagi) http://rio.ee/~wookie/tcp-yhendus-full-nat.png

Üldiselt peaks nendest teadmistest piisama, et lihtsamate pordisuunamise probleemide põhjuseid diagnoosida. Tavaliselt, kui sellist õnnestunud ühendust võrrelda ebaõnnestunud ühenduse korral püütud pakettidega, hakkab viga vähegi tähelepaneliku süvenemise korral ise silma ning parandamine on tavaliselt juba triviaalne tegevus.
Keerukamate probleemide korral võib muidugi ka Õpetatud Kogu[tm] tunde või suisa päevi ladinakeeles päid vangutada, et välja mõelda, mis siis ikkagi peetis on, kuid praktika näitab, et enamik probleeme on tegelikult lihtsad.

Tjah, kindlasti tasub meeles pidada, et Ethereal oskab püütud pakette salvestada (jah, just nimelt File::Save) - sellised ethereali failid võivad probleemide lahendamisel vägagi abiks olla, mistõttu maksab selliste hädade korral abiküsimise kõrvalt ka mõni niisugune Ethereali fail kätesaadavaks teha.
Et kõik saaks ise uurida, siis juurde ka antud näites kasutatud ühenduste salvestused:
http://rio.ee/~wookie/tcp-yhendus
http://rio.ee/~wookie/tcp-yhendus-valine
http://rio.ee/~wookie/tcp-yhendus-full-nat

P.S.
Jah ma tean küll, et antud juhul ei ole routerist rääkimine päris korrektne, sest klassikaline router ei muuda edastatavates pakettides ei IP aadresse ega pordi numbreid, kuid antud juhul, kuna probleem on selgelt seotud NAT'iga, tundus sõna router kasutamine otstarbekam, sest NAT'iv router või NAT'i purk vms. oleks lihtsalt kohutavalt kohmakas.
Seega lugege sõna "router" antud juhul kui "see router selles konkreetses seadistuses võrguaadresse transleerimas (NAT)".

P.P.S.
Ehki meie kasutasime näites SSH teenust, mis peale ühenduse loomist ise mingit mula välja hakkab ajama, ei prugi sellist igaühel käepärast olla. Sageli on tarvis testida näiteks WWW (TCP/80) teenuse töötamist, mille puhul server jääb peale ühenduse loomist ootama, et talle mõni käsk antaks. Sellisel juhul on mõistlik telneti sisse peale ühenduse saamist kirjutada suvaline esimesena meelde tulev vandesõna või roppus ning taguda paar korda enterit. WWW server peab vastama HTML'iga, mis tahab meile öelda, et 501 Method Not Implemented või midagi muud sama roppu.

Fail:Ethereal1.png

2005-11-03T22:16:21Z

Cbr:

Lihtsa võrguanalüsaatori ehitamine

2005-11-03T19:36:15Z

Cbr:

[[Kategooria:Kasulikud Näpunäited]]
[[Kategooria:Andmeside]]
[[Kategooria:Võrgukihi juhendid]]
Ilmselt on mõistlik tutvust teha Ethereali ( http://www.ethereal.com ) nimelise programmiga (võib kasutada ka mõnda teist võrguanalüsaatorit, näiteks tcpdump), mille abil tasuks uurida nii "sisevõrgu" masinasse tulevat (ning ehk ka väljuvat) liiklust kui ka seda liiklust, mis toimub kaablimodemi ning NAT'iva routeri vahel.

Sisevõrgus olevasse masinasse saabuvat liiklust saab analüüsida sisevõrgu masinas endas, kaablimodemi ning routeri vahelise liikluse analüüsimiseks on kõige lihtsam laenata või osta HUB (kindlasti hub, mitte switch), mille abil siis ühendada sellesse võrku veel üks seade, mis kuulab seda liiklust pealt.

Testimiseks on kõige lihtsam hankida ligipääs mõnesse Internetis asuvasse Unixilaadsesse süsteemi (paremal puudumisel võib ju muidugi ka naabrimees või keegi teine oma lauaarvutist üritada ühenduda), mille aadress (ma mõtlen reaalne interneti aadress) on teada. Teadaolev Internetis asuva süsteemi aadress anda etherealile filtriks kujul ip.addr == aadress (see konstruktsioon määrab filtrisse nii sellelt aadressilt tulevad kui ka sellele aadressile saadetavad paketid). Kaval on Etherealile öelda, et kõik paketid, mis püütakse, ka kohe välja näidataks (loomulikult on sellisel juhul mõistlik, kui võrgu peal on nii vähe liiklust kui võimalik).

Olles sedasi analüsaatori püsti saanud (ahjaa promisc moodis (sellisel juhul edastab võrgukaart OSile ka selle liikluse, mis ei ole talle mõeldud, vajalik kaablimodemi ja routeri vahelise liikluse pealt kuulamiseks) kuulamiseks on reeglina vaja superkasutaja õigusi), tuleks luua väljastpoolt ühendus oma välisaadressi sellesse porti, kus me eeldame teenust olevat. Kõige lihtsam on seda teha telneti abil: telnet 1.2.3.4 1234, kus 1.2.3.4 on ip aadress ning 1234 on vastav TCP port.
Algatuseks on mõistlik kuulata teenust pakkuvast masinast - kui välisilmast ühendust luues filtrisse ühtegi paketti ei tulnud, on ilmselge, et viga tuleb otsida routerist(vt. ka allapoole nn. "keerulisem olukord"). Kui aga ühendus ilmub, tuleb hakata analüüsima, mis siis valesti on.

Et asjatundmatu kasutaja ei pruugi esimese hooga Ethereali väljundist suurt midagi aru saada, siis toome siinkohal ühe pisikene näite õnnestunud ühendusest (ehk siis... nõnda peavad asjad olema, kui ei ole, on analoogia põhjal ilmselt üsna lihtne oletada, mis on valesti):

Olukord on järgmine: võrgu väline (reaalselt eksisteeriv) interneti aadress on 217.159.159.181, millel vastab router, milles on TCP/666 DNAT'itud "sisevõrgus" asuva masina, aadressiga 192.168.2.20, pordile TCP/22, millelt vastab SSH. Selle teenusega üritatakse ühendust võtta süsteemist aadressiga 194.204.19.34 järgmiselt:

wookie@piixus:~$ telnet 217.159.159.181 666
Trying 217.159.159.181...
Connected to 217.159.159.181.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.9p1
^]
telnet> quit
Connection closed.

Sisevõrgus asuva masina seisukohalt näeb ühendus välja järgmine: http://rio.ee/~wookie/tcp-yhendus.png
ISP ning minu routeri vahel toimus samal ajal aga järgmine: http://rio.ee/~wookie/tcp-yhendus-valine.png

Olulised on siinkohal kolm esimest paketti:
Iga TCP ühendus algab ühenduse alustaja poolt saadetud [SYN] paketiga. Me märkame, et sisevõrgu masina jaoks on paketi sihtaadress (destination adress) 192.168.2.20, kuid teiselt pildilt näeme, et tegelikult saabus pakett muidugi aadressile 217.159.159.181 - router transleeris paketi sihtaadressi selliselt, et see sai edasi liikuda meie privaatvõrgu aadressile, samuti me märkame, et antud juhul jättis router paketi lähteaadressi (source address) muutmata. Samasugust transleerimist võime tähele panna pordi numbritega - routerisse saabus pakett pordile TCP/666, kuid sisevõrgu masinasse pordile TCP/22 (ssh).

Kuna [SYN] pakett saabus antud juhul õige masina õigesse porti (sellisesse, mida mõni teenus kuulab), vastab meie masin [SYN, ACK] paketiga, antud juhul aadressile 194.204.19.34 (sealt ju ühendus tuli). Nüüd on äärmiselt oluline uurida, kas see pakett routerist 194.204.19.34 aadressile välja ikka saadeti. Vaatame välise ühenduse pilti ning näeme, et router saatis [SYN, ACK] paketti aadressilt 217.159.159.181 aadressile 194.204.19.34, samal ajal kui meie sisevõrgus olev masin hoopis aadressilt 192.168.2.20 aadressile 194.204.19.34 - loogiline, pakett peab antud juhtumil väljuma routeri source aadressiga, ehk siis reaalselt internetis eksisteeriva aadressiga. Kui paketi lähteaadress oleks teistsugune, näiteks 192.168.2.20, ei oleks ühenduse loomine õnnestunud, sest ühendust algatava masina jaoks oleks see olnud kui SYN,ACK pakett mingilt täiesti tundmatult aadressilt, millega ta pole kunagi üritanud suhelda. Seda, et meie routeris 217.159.159.181'st saab maagiliselt 192.168.2.20, 194.204.19.34 ei tea ega saa ka kunagi teadma. Samuti, täpselt samasugune transleerimine toimub pordinumbritega - sisevõrgu masin vastab pordist (source port) TCP/22 (ssh), kuid routerist väljuv pakett lähtub pordist TCP/666.

Kui siiamaale juba asjad õnnestusid, siis üldiselt õnnestub ka TCP ühenduse loomiseks vajaliku kolmanda paketi (ühenduse algataja poolne vastus [ACK] "serveri" [SYN, ACK]'le) saatmine. Me märkame, et selle paketiga käitutakse sarnaselt päris esimesele paketile.

Sellest hetkest alates on ühendus loodud ning järgneb juba data: Server (meie näites siis sisevõrgus olev masin) ütleb: "SSH-2.0-OpenSSH_3.9p1". Mida kliendis jooksev applikatsioon sellega peale hakkab, on juba tema enda mure - meie näites kasutatav telnet ei oska sellega mitte mütsigi teha, kuid kuna me juba nägime serveri poolset vastust, oleme me veendunud, et ühendust on võimalik luua ning paneme telneti hoopis kinni (mis toimub ühenduse sulgemisel võib igaüks ise jälgida, uurides kolme viimast paketti). Ahjaa.. küsite, et mida kuradit teeb siis viies, [ACK] pakett? See on lihtsalt kliendi poolne vastus, et ta sai eelmises paketis saadetud teate (SSH-2.0-OpenSSH_3.9p1) kenasti kätte.

Ma usun, et igaüks teab aga igaks juhuks kordame veel üle, et iga sellise NAT'itud ühenduse peale teeb router kuhugile oma mälus asuvasse tabelisse kirje, milles on kirjas, mida täpselt muudeti ning oskab selle järgi vastassuunas liikuvate pakettide välju vastupidiselt muuta, et kõik ikka õnnelikud oleks - kuidas see käib, pole antud hetkel meie asi, lihtsalt jätame meelde, et selline tabel kuskil routeri kõhus on.

Tähelepanelik lugeja kindlasti märkab, et suunal klient (kuskil interneti avarustes asuv purk) -> server (meie sisevõrgu masin) muudeti ainult pakettide sihtaadressi (destination address) ning suunal server -> klient ainult paketi lähteaadressi (source address). Enamik selliseid pordisuunamisi töötab selliselt. Niisuguses lahenduses, kus sisevõrgust interneti poole suunduvate pakettide lähteaadressi tuleb nii ehk naa transleerida, pole mõtet vastupidise NAT'i korral välisilmast saabuvate pakettide lähteaadressi muuta.

Samas... eksisteerib ka keerulisem olukord - router muudab nii siseneva paketi lähte- kui ka sihtaadressi. Sellisel juhul jääb meie sisevõrgus olevale serverile mulje nagu ta suhtleks routeri endaga. Niisugusel juhul sisevõrgus filter ip.addr == ip_aadress ei kõlba (sest sisevõrgus ju mitte keegi ei suhtle selle välise aadressiga) ning tuleks asendada keerulisema filtriga, minu puhul siis näiteks: ip.addr == 192.168.2.254 (192.168.2.254 on minu routeri sisevõrgu aadress, me püüame liiklust, mida peetakse selle seadmega) või suisa ip.addr == 192.168.2.254 && tcp.port == 22 (TCP liiklus, mida peetakse routeriga, mille lähte- või sihtport on 22). Igaks juhuks ühest sellisest ühendusest pilt kah (vaadatuna siis sisevõrgu masina poolt - väljastpoolt ei muutu midagi) http://rio.ee/~wookie/tcp-yhendus-full-nat.png

Üldiselt peaks nendest teadmistest piisama, et lihtsamate pordisuunamise probleemide põhjuseid diagnoosida. Tavaliselt, kui sellist õnnestunud ühendust võrrelda ebaõnnestunud ühenduse korral püütud pakettidega, hakkab viga vähegi tähelepaneliku süvenemise korral ise silma ning parandamine on tavaliselt juba triviaalne tegevus.
Keerukamate probleemide korral võib muidugi ka Õpetatud Kogu[tm] tunde või suisa päevi ladinakeeles päid vangutada, et välja mõelda, mis siis ikkagi peetis on, kuid praktika näitab, et enamik probleeme on tegelikult lihtsad.

Tjah, kindlasti tasub meeles pidada, et Ethereal oskab püütud pakette salvestada (jah, just nimelt File::Save) - sellised ethereali failid võivad probleemide lahendamisel vägagi abiks olla, mistõttu maksab selliste hädade korral abiküsimise kõrvalt ka mõni niisugune Ethereali fail kätesaadavaks teha.
Et kõik saaks ise uurida, siis juurde ka antud näites kasutatud ühenduste salvestused:
http://rio.ee/~wookie/tcp-yhendus
http://rio.ee/~wookie/tcp-yhendus-valine
http://rio.ee/~wookie/tcp-yhendus-full-nat

P.S.
Jah ma tean küll, et antud juhul ei ole routerist rääkimine päris korrektne, sest klassikaline router ei muuda edastatavates pakettides ei IP aadresse ega pordi numbreid, kuid antud juhul, kuna probleem on selgelt seotud NAT'iga, tundus sõna router kasutamine otstarbekam, sest NAT'iv router või NAT'i purk vms. oleks lihtsalt kohutavalt kohmakas.
Seega lugege sõna "router" antud juhul kui "see router selles konkreetses seadistuses võrguaadresse transleerimas (NAT)".

P.P.S.
Ehki meie kasutasime näites SSH teenust, mis peale ühenduse loomist ise mingit mula välja hakkab ajama, ei prugi sellist igaühel käepärast olla. Sageli on tarvis testida näiteks WWW (TCP/80) teenuse töötamist, mille puhul server jääb peale ühenduse loomist ootama, et talle mõni käsk antaks. Sellisel juhul on mõistlik telneti sisse peale ühenduse saamist kirjutada suvaline esimesena meelde tulev vandesõna või roppus ning taguda paar korda enterit. WWW server peab vastama HTML'iga, mis tahab meile öelda, et 501 Method Not Implemented või midagi muud sama roppu.

Lihtsa võrguanalüsaatori ehitamine

2005-11-03T19:34:44Z

Cbr: Lihtsa v6rguanalysaatori ehitamine teisaldati: Lihtsa võrguanalüsaatori ehitamine

[[Kategooria:Kasulikud Näpunäited]]
[[Kategooria:Andmeside]]
[[Kategooria:Võrgukihi juhendid]]

==Lihtsa Võrguanalüsaatori Ehitamine võrguprobleemide tuvastamiseks==

Ilmselt on mõistlik tutvust teha Ethereali ( http://www.ethereal.com ) nimelise programmiga (võib kasutada ka mõnda teist võrguanalüsaatorit, näiteks tcpdump), mille abil tasuks uurida nii "sisevõrgu" masinasse tulevat (ning ehk ka väljuvat) liiklust kui ka seda liiklust, mis toimub kaablimodemi ning NAT'iva routeri vahel.

Sisevõrgus olevasse masinasse saabuvat liiklust saab analüüsida sisevõrgu masinas endas, kaablimodemi ning routeri vahelise liikluse analüüsimiseks on kõige lihtsam laenata või osta HUB (kindlasti hub, mitte switch), mille abil siis ühendada sellesse võrku veel üks seade, mis kuulab seda liiklust pealt.

Testimiseks on kõige lihtsam hankida ligipääs mõnesse Internetis asuvasse Unixilaadsesse süsteemi (paremal puudumisel võib ju muidugi ka naabrimees või keegi teine oma lauaarvutist üritada ühenduda), mille aadress (ma mõtlen reaalne interneti aadress) on teada. Teadaolev Internetis asuva süsteemi aadress anda etherealile filtriks kujul ip.addr == aadress (see konstruktsioon määrab filtrisse nii sellelt aadressilt tulevad kui ka sellele aadressile saadetavad paketid). Kaval on Etherealile öelda, et kõik paketid, mis püütakse, ka kohe välja näidataks (loomulikult on sellisel juhul mõistlik, kui võrgu peal on nii vähe liiklust kui võimalik).

Olles sedasi analüsaatori püsti saanud (ahjaa promisc moodis (sellisel juhul edastab võrgukaart OSile ka selle liikluse, mis ei ole talle mõeldud, vajalik kaablimodemi ja routeri vahelise liikluse pealt kuulamiseks) kuulamiseks on reeglina vaja superkasutaja õigusi), tuleks luua väljastpoolt ühendus oma välisaadressi sellesse porti, kus me eeldame teenust olevat. Kõige lihtsam on seda teha telneti abil: telnet 1.2.3.4 1234, kus 1.2.3.4 on ip aadress ning 1234 on vastav TCP port.
Algatuseks on mõistlik kuulata teenust pakkuvast masinast - kui välisilmast ühendust luues filtrisse ühtegi paketti ei tulnud, on ilmselge, et viga tuleb otsida routerist(vt. ka allapoole nn. "keerulisem olukord"). Kui aga ühendus ilmub, tuleb hakata analüüsima, mis siis valesti on.

Et asjatundmatu kasutaja ei pruugi esimese hooga Ethereali väljundist suurt midagi aru saada, siis toome siinkohal ühe pisikene näite õnnestunud ühendusest (ehk siis... nõnda peavad asjad olema, kui ei ole, on analoogia põhjal ilmselt üsna lihtne oletada, mis on valesti):

Olukord on järgmine: võrgu väline (reaalselt eksisteeriv) interneti aadress on 217.159.159.181, millel vastab router, milles on TCP/666 DNAT'itud "sisevõrgus" asuva masina, aadressiga 192.168.2.20, pordile TCP/22, millelt vastab SSH. Selle teenusega üritatakse ühendust võtta süsteemist aadressiga 194.204.19.34 järgmiselt:

wookie@piixus:~$ telnet 217.159.159.181 666
Trying 217.159.159.181...
Connected to 217.159.159.181.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.9p1
^]
telnet> quit
Connection closed.

Sisevõrgus asuva masina seisukohalt näeb ühendus välja järgmine: http://rio.ee/~wookie/tcp-yhendus.png
ISP ning minu routeri vahel toimus samal ajal aga järgmine: http://rio.ee/~wookie/tcp-yhendus-valine.png

Olulised on siinkohal kolm esimest paketti:
Iga TCP ühendus algab ühenduse alustaja poolt saadetud [SYN] paketiga. Me märkame, et sisevõrgu masina jaoks on paketi sihtaadress (destination adress) 192.168.2.20, kuid teiselt pildilt näeme, et tegelikult saabus pakett muidugi aadressile 217.159.159.181 - router transleeris paketi sihtaadressi selliselt, et see sai edasi liikuda meie privaatvõrgu aadressile, samuti me märkame, et antud juhul jättis router paketi lähteaadressi (source address) muutmata. Samasugust transleerimist võime tähele panna pordi numbritega - routerisse saabus pakett pordile TCP/666, kuid sisevõrgu masinasse pordile TCP/22 (ssh).

Kuna [SYN] pakett saabus antud juhul õige masina õigesse porti (sellisesse, mida mõni teenus kuulab), vastab meie masin [SYN, ACK] paketiga, antud juhul aadressile 194.204.19.34 (sealt ju ühendus tuli). Nüüd on äärmiselt oluline uurida, kas see pakett routerist 194.204.19.34 aadressile välja ikka saadeti. Vaatame välise ühenduse pilti ning näeme, et router saatis [SYN, ACK] paketti aadressilt 217.159.159.181 aadressile 194.204.19.34, samal ajal kui meie sisevõrgus olev masin hoopis aadressilt 192.168.2.20 aadressile 194.204.19.34 - loogiline, pakett peab antud juhtumil väljuma routeri source aadressiga, ehk siis reaalselt internetis eksisteeriva aadressiga. Kui paketi lähteaadress oleks teistsugune, näiteks 192.168.2.20, ei oleks ühenduse loomine õnnestunud, sest ühendust algatava masina jaoks oleks see olnud kui SYN,ACK pakett mingilt täiesti tundmatult aadressilt, millega ta pole kunagi üritanud suhelda. Seda, et meie routeris 217.159.159.181'st saab maagiliselt 192.168.2.20, 194.204.19.34 ei tea ega saa ka kunagi teadma. Samuti, täpselt samasugune transleerimine toimub pordinumbritega - sisevõrgu masin vastab pordist (source port) TCP/22 (ssh), kuid routerist väljuv pakett lähtub pordist TCP/666.

Kui siiamaale juba asjad õnnestusid, siis üldiselt õnnestub ka TCP ühenduse loomiseks vajaliku kolmanda paketi (ühenduse algataja poolne vastus [ACK] "serveri" [SYN, ACK]'le) saatmine. Me märkame, et selle paketiga käitutakse sarnaselt päris esimesele paketile.

Sellest hetkest alates on ühendus loodud ning järgneb juba data: Server (meie näites siis sisevõrgus olev masin) ütleb: "SSH-2.0-OpenSSH_3.9p1". Mida kliendis jooksev applikatsioon sellega peale hakkab, on juba tema enda mure - meie näites kasutatav telnet ei oska sellega mitte mütsigi teha, kuid kuna me juba nägime serveri poolset vastust, oleme me veendunud, et ühendust on võimalik luua ning paneme telneti hoopis kinni (mis toimub ühenduse sulgemisel võib igaüks ise jälgida, uurides kolme viimast paketti). Ahjaa.. küsite, et mida kuradit teeb siis viies, [ACK] pakett? See on lihtsalt kliendi poolne vastus, et ta sai eelmises paketis saadetud teate (SSH-2.0-OpenSSH_3.9p1) kenasti kätte.

Ma usun, et igaüks teab aga igaks juhuks kordame veel üle, et iga sellise NAT'itud ühenduse peale teeb router kuhugile oma mälus asuvasse tabelisse kirje, milles on kirjas, mida täpselt muudeti ning oskab selle järgi vastassuunas liikuvate pakettide välju vastupidiselt muuta, et kõik ikka õnnelikud oleks - kuidas see käib, pole antud hetkel meie asi, lihtsalt jätame meelde, et selline tabel kuskil routeri kõhus on.

Tähelepanelik lugeja kindlasti märkab, et suunal klient (kuskil interneti avarustes asuv purk) -> server (meie sisevõrgu masin) muudeti ainult pakettide sihtaadressi (destination address) ning suunal server -> klient ainult paketi lähteaadressi (source address). Enamik selliseid pordisuunamisi töötab selliselt. Niisuguses lahenduses, kus sisevõrgust interneti poole suunduvate pakettide lähteaadressi tuleb nii ehk naa transleerida, pole mõtet vastupidise NAT'i korral välisilmast saabuvate pakettide lähteaadressi muuta.

Samas... eksisteerib ka keerulisem olukord - router muudab nii siseneva paketi lähte- kui ka sihtaadressi. Sellisel juhul jääb meie sisevõrgus olevale serverile mulje nagu ta suhtleks routeri endaga. Niisugusel juhul sisevõrgus filter ip.addr == ip_aadress ei kõlba (sest sisevõrgus ju mitte keegi ei suhtle selle välise aadressiga) ning tuleks asendada keerulisema filtriga, minu puhul siis näiteks: ip.addr == 192.168.2.254 (192.168.2.254 on minu routeri sisevõrgu aadress, me püüame liiklust, mida peetakse selle seadmega) või suisa ip.addr == 192.168.2.254 && tcp.port == 22 (TCP liiklus, mida peetakse routeriga, mille lähte- või sihtport on 22). Igaks juhuks ühest sellisest ühendusest pilt kah (vaadatuna siis sisevõrgu masina poolt - väljastpoolt ei muutu midagi) http://rio.ee/~wookie/tcp-yhendus-full-nat.png

Üldiselt peaks nendest teadmistest piisama, et lihtsamate pordisuunamise probleemide põhjuseid diagnoosida. Tavaliselt, kui sellist õnnestunud ühendust võrrelda ebaõnnestunud ühenduse korral püütud pakettidega, hakkab viga vähegi tähelepaneliku süvenemise korral ise silma ning parandamine on tavaliselt juba triviaalne tegevus.
Keerukamate probleemide korral võib muidugi ka Õpetatud Kogu[tm] tunde või suisa päevi ladinakeeles päid vangutada, et välja mõelda, mis siis ikkagi peetis on, kuid praktika näitab, et enamik probleeme on tegelikult lihtsad.

Tjah, kindlasti tasub meeles pidada, et Ethereal oskab püütud pakette salvestada (jah, just nimelt File::Save) - sellised ethereali failid võivad probleemide lahendamisel vägagi abiks olla, mistõttu maksab selliste hädade korral abiküsimise kõrvalt ka mõni niisugune Ethereali fail kätesaadavaks teha.
Et kõik saaks ise uurida, siis juurde ka antud näites kasutatud ühenduste salvestused:
http://rio.ee/~wookie/tcp-yhendus
http://rio.ee/~wookie/tcp-yhendus-valine
http://rio.ee/~wookie/tcp-yhendus-full-nat

P.S.
Jah ma tean küll, et antud juhul ei ole routerist rääkimine päris korrektne, sest klassikaline router ei muuda edastatavates pakettides ei IP aadresse ega pordi numbreid, kuid antud juhul, kuna probleem on selgelt seotud NAT'iga, tundus sõna router kasutamine otstarbekam, sest NAT'iv router või NAT'i purk vms. oleks lihtsalt kohutavalt kohmakas.
Seega lugege sõna "router" antud juhul kui "see router selles konkreetses seadistuses võrguaadresse transleerimas (NAT)".

P.P.S.
Ehki meie kasutasime näites SSH teenust, mis peale ühenduse loomist ise mingit mula välja hakkab ajama, ei prugi sellist igaühel käepärast olla. Sageli on tarvis testida näiteks WWW (TCP/80) teenuse töötamist, mille puhul server jääb peale ühenduse loomist ootama, et talle mõni käsk antaks. Sellisel juhul on mõistlik telneti sisse peale ühenduse saamist kirjutada suvaline esimesena meelde tulev vandesõna või roppus ning taguda paar korda enterit. WWW server peab vastama HTML'iga, mis tahab meile öelda, et 501 Method Not Implemented või midagi muud sama roppu.

Arutelu:Viki kirjutamine

2005-11-01T21:01:39Z

Cbr:

Viidates nr 2-le... pigem soovitaks kategooria lehe lõppu panna (nagu ka Wikipedias on tehtud), kuna selle üles paigutamine jätab leheküljel pealekirja alla ühe tühja rea, mis pole eriti ilus. --[[Kasutaja:EssOEss|EssOEss]] 30. oktoober 2005, kell 21.55 (EET)

proovisin just. Muideks ei jäta [[Kasutaja:Cbr|Cbr]] 1. november 2005, kell 23.01 (EET)

Viki kirjutamine

2005-11-01T21:01:04Z

Cbr:

Hinnavaatluse Wiki kirjutamisel on paar põhiasja, mida silmas vaja pidada:

'''1.''' Uue lehe tegemiseks ilma lingita lisage index.php järele aadressiribal "/Uue lehe nimi". Seejärel avaneb tühi lehekülg mida saab muuta ning seejärel salvestada, et leht muutuks aktiivseks. Näide:

:Et teha uut wiki lehte nimega "Kuidas kasutada Linuxit", peab aadressiriba välja nägema selline: "http://wiki.hinnavaatlus.ee/index.php/Kuidas kasutada Linuxit" ning peale klahvi Enter vajutamist selline: "<nowiki>http://wiki.hinnavaatlus.ee/index.php/Kuidas_kasutada_Linuxit</nowiki>"

'''2.''' Lehe kategooriasse lisamiseks lisage tühja faili algusesse "[[Kategooria:Kategoorianimi]]". Kategooriate nimetused on '''tõstutundlikud''', st. "Kasulikud näpunäited" ja "Kasulikud Näpunäited" on kaks erinevat kategooriat. Kasulike näpunäidete alla lisamiseks kasutage teist varianti, st. "Kasulikud Näpunäited" ja faili algusesse lisage "[[Kategooria:Kasulikud Näpunäited]]".

'''3.''' Kasulike näpunäidete kirjutamisel lisage lõppu kindlasti algse näpunäite kirjutanud autor, nt nii:

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&un=kasutaja%20nimi kasutaja nimi]

Tulemus:

Autor: [http://foorum.hinnavaatlus.ee/profile.php?mode=viewprofile&un=kasutaja%20nimi kasutaja nimi]

----
[[Kategooria:Juhend]]

Kategooria:HV

2005-11-01T18:17:11Z

Cbr:

Korduma Kippuvad Küsimused ning näpunäited [[Hinnavaatlus|Hinnavaatluse]] edukaks kasutamiseks. 
[[Hinnavaatlus|Mis on Hinnavaatlus?]] 
[[Hinnavaatlus|Mis on Hinnavaatluse foorum?]]

Sisselogimine ja registreerumine

2005-10-31T15:11:05Z

Cbr: /* Kuidas peita oma online-olekut? */

[[Category:HV]]
== Miks ma ei saa sisse logida? ==
Kas sa oled ennast üldse kasutajaks registreerinud? Ega sa bannitud ei ole (sisselogimisel kuvatakse sulle vastav teade)? Kui sa oled bannitud, siis kontakteeru foorumi administraatoriga, et selgitada välja põhjus. Kui oled registreerunud ja bannitud ei ole, siis kontrolli oma kasutajatunnust ja parooli. Kui sul ikka ei õnnestu sisse logida, siis kontakteeru administraatoriga.

== Miks ma üldse peaksin registreeruma? ==
Registreeruma pead selleks, et saaksid postitada oma küsimusi/vastuseid. Lisaks sellele saavad ainult registreerunud kasutajad kasutada avatare, privaatsõnumeid, kasutajategruppe jms.

== Miks mind automaatselt välja logitakse? ==
Kui sa sisselogimisel ei märgista kasti "logi mind automaatselt sisse, kui ma foorumit külastan", siis teatud aja jooksul logitakse sind automaatselt välja. Sellega vähendatakse riski, et keegi võiks sinu kasutajakontot kuritarvitada. Kui sa ei soovi automaatset väljalogimist, siis märgista kast "logi mind automaatselt sisse, kui ma foorumit külastan" (NB! Seda funktsiooni ei ole soovitatav kasutada avalikuks kasutamiseks mõeldud arvutites - koolis, raamatukogus, avalikus internetipunktis jne.).

== Kuidas muuta oma seadeid? ==
Kliki nupul "profiil", kõiki muudetavaid seadeid ja eelistusi saad muuta sealt. Rohkem sellest võid lugeda [[Foorumi_efektiivne_kasutamine|siit]]

=== Kuidas peita oma online-olekut? ===
Oma profiili alt leiad valiku "tee oma online-i staatus nähtamatuks". Kui peidad oma online-oleku, siis "näevad" sinu kohalolekut ainult administraatorid (ja sa ise).

== Ma unustasin oma parooli, mida teha? ==
Sisselogimise lehel on nupp "ma unustasin oma parooli". Järgi ekraanil antud juhiseid ja peagi on probleem lahendatud.

== Ma registreerusin kunagi, kuid ei saa enam sisse logida?! ==
Arvatavasti sisestasid sa vale kasutajatunnuse ja/või parooli. Kui asi ei ole selles, siis võta ühendust administraatoriga.

== ID kaardiga autoriseerimine ==
Sul on võimalik oma kasutaja ID-kaarti kasutades usaldusväärsemaks teha. Tegevus on ühekordne ning selle tulemusena ilmub Ärifoorumites sinu kirjade juurde ning profiili vastav logo: http://foorum.hinnavaatlus.ee/images/id.gif või http://foorum.hinnavaatlus.ee/images/id_black.gif (logo värvus sõltub valitud foorumi välimusest).
Selle jaoks pead sa läbima järgmised sammud:

* Sisesta ID-kaart lugejasse
* Ava sirvijas leht https://web.hinnavaatlus.ee/
* Logi sisse HV foorumi kasutajana
* Salvesta andmed
* Ette tuleb valge aken, sulge see

'''NB!''' Peale seda toimingut pead foorumisse uuesti sisse logima.

MediaWiki:Uploadedimage

2005-10-26T15:17:26Z

Cbr:

laadis üles "[[$1]]"

MediaWiki:Already steward

2005-10-26T15:14:34Z

Cbr:

See kasutaja on juba stjuuard

MediaWiki:Group-steward-name

2005-10-26T15:14:15Z

Cbr:

Stjuuard

MediaWiki:Group-steward-desc

2005-10-26T15:13:54Z

Cbr:

Täielik ligipääs

MediaWiki:Already sysop

2005-10-26T15:12:44Z

Cbr:

See kasutaja on juba administraator

MediaWiki:Makesysoptext

2005-10-26T15:11:57Z

Cbr:

Seda vormi kasutavad bürokraadid, et anda tavalistele kasutajatele administraatoriõigused.
Et teha kasutajast administraator, trüki ta kasutajanimi kasti ja vajuta nupule

MediaWiki:Group-bureaucrat-name

2005-10-26T15:09:54Z

Cbr:

Bürokraat

MediaWiki:Group-bureaucrat-desc

2005-10-26T15:09:22Z

Cbr:

Bürokraadid saavad jagada sysopi staatusi

MediaWiki:Bureaucratlogentry

2005-10-26T15:08:18Z

Cbr:

tõstis $1 ($2 → $3)

MediaWiki:Bureaucratlogentry

2005-10-26T15:05:04Z

Cbr:

tõstis $1 grupist $2 gruppi $3

MediaWiki:Bureaucratlogentry

2005-10-26T15:04:40Z

Cbr:

tõstis kasutaja $1 grupist $2 gruppi $3

MediaWiki:Bureaucratlog

2005-10-26T15:02:37Z

Cbr:

Bürokraadi_logi

MediaWiki:Already bureaucrat

2005-10-26T15:01:55Z

Cbr:

See kasutaja on juba bürokraat

MediaWiki:Allmessagestext

2005-10-26T14:59:40Z

Cbr:

See on nimekiri saadaolevatest süsteemiteadetest MediaWiki: nimeruumis.

MediaWiki:Allmessagesdefault

2005-10-26T14:58:51Z

Cbr:

Vaiketekst

MediaWiki:Watcheditlist

2005-10-26T14:57:05Z

Cbr:

Siin on tähestiku järjekorras kõik sinu poolt jälgitavad artiklid.
Pane linnuke nende artiklite ette, mida sa tahad jälgimisloendist
eemaldada ja vajuta nuppu "Eemalda märgitud" (artikli eemaldamine eemaldab
loendist ka artikliga kaasasoleva arutelu ja vastupidi).

MediaWiki:Removechecked

2005-10-26T14:54:42Z

Cbr:

Eemalda märgitud

MediaWiki:Watchlistcontains

2005-10-26T14:53:35Z

Cbr:

Sinu jälgimisloendis on $1 lehte.