Cisco Linksys WRT54GH

Tani i niezawodny router do prostej sieci domowej Cisco Linksys WRT54GH. Cena: poniżej 90 pln za nowy. Testowałem przez niecałe 2 tygodnie – żadnych zarzutów. Kilka informacji o tym routerku, którymi chaciałbym się podzielić:

• AP-client: nie
• Zasilanie: 12V 0,5A (a więc nie więcej niż 6W).
• DDNS (Dynamic DNS): tak
• Protokoły transmisji: 802.11b i/lub 802.11g
• Zakres WiFi: 2,4 GHz
• Bezpieczeństwo: WEP, WPA-Personal, WPA2-Personal
• Szyfrowanie: TKIP / AESForward portów: tak
• IP dla MAC: tak
• Klonowanie (zmiana) MAC: tak
• DMZ: tak
• Zdalne zarządzanie: tak, bez szyfrowania, dowolny port, możliwość ograniczenia zarządzania do 1 IP.
• Ethernet: 100BASE-T (2 pary)

Router był testowany na firmowym oprogramowaniu (firmware), wersja: 1.0.01. Niestety, nie można tu wrzucić DD-WRT (RT3050 CPU, 2MB Flash/8MB RAM ). Dobrze pokrywa zasięgiem obszar mieszkania 50-80m², ale poza nim sygnał już jest nikły – router ma jedną wbudowaną antenę. Nie grzeje się i jest energooszczędny. Testowałem na 2 lapkach + 2 nokia z wifi. Test wypadł bez zastrzeżeń.

Warto wspomnieć, że router NIE POSIADA przyjaznego użytkownikowi włamywaczowi bajeru WPS (Wi-Fi Protected Setup) co w moich oczach stanowi dodatkowy atut.
Szerzej o niebezpieczeństwie związanym z WPS można poczytać u kolegi, na niebezpiecznik.pl.

Moi drodzy! Jeśli skusiliście się na zakup routera Cisco Linksys E1000 v2.1 to szczerze gratuluję Wam zakupu. W mojej opinii to świetny sprzęt dla sieci 2,4 GHz.

Moje zaskoczenie jednak wzbudził HTTP/0.9 w zarządzaniu po SSL. Wystarczy podejżeć sobie co jest przez routerek zwracane.

HTTP/0.9

Najnowsze przeglądarki wymiękają: Opera (11.60), Iceweasel (7.0.1) również. Konqueror (4.7.3) dał radę. Nie testowałem jeszcze tego na windowsowych przeglądarkach, ale powiem szczerze, że jestem zszokowany. Obsługi HTTP/1.0 czy HTTP/1.1 dla połączeń szyfrowanych SSL do zarządzania routerkiem niestety brak. Upgrade firmware do wersji 2.1.02 nie pomógł.

Jak na razie to jedyny minus tego urządzenia. Połączenie wifi stabilne. Bez problemu obsługiwanych jest 5 urządzeń bezprzewodowych.

# find . -type f -name "*.gz" -exec gunzip -v {} \;

a następnie spakowałem xz:

# find . -type f -name "*.txt" -exec xz -v {} \;

Spakowane w ten sposób plilki zajmują 818MB. Odzyskałem połowę miejsca zużytego przez te pliki. Właśnie robię test z plikami ~60kB w stanie bez kompresji i zobaczymy jak wyjdzie. Oczywiście, zdaję sobie sprawę, że ~800MB to w dzisiejszych czasach przestrzeń która nie powala na kolana, ale jeśli liczyć więcej plików i przestrzenie w TB, to różnica będzie na prawdę zauważalna.

Dla logrotate wystarczy w /etc/logrotate.conf wpisać:

compresscmd /usr/bin/xz

i cieszyć się oszczędnością przestrzeni. Wadą xz jest jak na razie brak wielo-wątkowości, co jest niestety dość boleśnie odczuwalne :(


$ cat ./x.php
<?php
mysql_connect('::1', 'mysql', 'TAJNE_HASŁO')
or die('Nie można się połaczyć: ' . mysql_error());
?>


Teraz spróbujemy zainicjować połączenie.


$ php -f ./x.php
PHP Warning: mysql_connect(): Can't connect to local MySQL server through socket '1' (2) in /home/users/wojtosz/x.php on line 2
Warning: mysql_connect(): Can't connect to local MySQL server through socket '1' (2) in /home/users/wojtosz/x.php on line 2
Nie można się połaczyć: Can't connect to local MySQL server through socket '1' (2)


Połączenie bezpośrednio do MySQL na ::1 przechodzi bez problemu:


$ mysql -u mysql -p -h ::1
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 17
Server version: 5.5.13-log PLD/Linux Distribution MySQL RPM
[...]
mysql> \s
--------------
mysql Ver 14.14 Distrib 5.5.13, for Linux (x86_64) using readline 6.2
Connection id: 17
Current user: mysql@localhost
SSL: Not in use
Server version: 5.5.13-log PLD/Linux Distribution MySQL RPM
Protocol version: 10
Connection: ::1 via TCP/IP
[...]

Wyciąłem [...] zbędne rzeczy. Jak widać, niewielu jest takich, którzy IPv6 używają na codzień, a szkoda :(

Jeśli strona http://ipv6.google.com wyświetli się – połączenie via IPv6 jest zestawione.

Dlaczego o tym piszę ?
Wszyscy trąbią, że IPv4 się kończy.  Ja trąbię, żeby IPv6 wreszcie się w Polsce zaczęło, nie tylko w home.pl, ale u innych dostawców hostingu i Internetu.

BTW, jeśli używasz Linuksa, tu jest ładny opis jak “wtunelować” się do providera IPv6 (opis dla PLD Linux).

Tcpdump dla opery zeznał:

# tcpdump -i any -vv port 80 -nn
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
08:26:04.712879 IP (tos 0×0, ttl 64, id 35010, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.42421 > 127.0.0.1.80: Flags [S], cksum 0xfe30 (incorrect -> 0x01b5), seq 317793938, win 32792, options [mss 16396,sackOK,TS val 372304 ecr 0,nop,wscale 1], length 0
08:26:04.712910 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
127.0.0.1.80 > 127.0.0.1.42421: Flags [R.], cksum 0xd244 (correct), seq 0, ack 317793939, win 0, length 0

Została więc z przeglądarki opera wysłana bzdura, bo Apache nie słucha na 127.0.0.1 tylko na ::1.

Ot, ciekawostka :)

mkdir /etc/vservers/${pld-th-64}/cgroup/

W katalogu umieszczamy pliki:

cpuset.cpus – ile rdzeni ma być wykorzystywanych przez Vserver: 0-4
cpuset.mems – migracja pamięci: 1
cpu.shares – liczba wskazująca część zasobów CPU jakie zostaną przydzielone do Vservera: 256
memory.limit_in_bytes – pamięć RAM przydzielona dla vserwera: 256M

Jeśli posiadamy udev i najnowsze rc-scripts – cgroup zostanie automatycznie zamontowny :)

Ot, działa :)

To the WordPress 3.0.1 we need to add to the wp-config.php a line:

define('DB_SSL', true);

and patch the wp-db.php file wich is located in the wp-includes directory.

$ svn diff ./wp-includes/wp-db.php
Index: wp-includes/wp-db.php
===================================================================
--- wp-includes/wp-db.php       (wersja 15639)
+++ wp-includes/wp-db.php       (kopia robocza)
@@ -1025,9 +1025,13 @@
         */
        function db_connect() {
                global $db_list, $global_db_list;
+
+                if(defined('DB_SSL') && DB_SSL === true ){
+                    $this->dbh = @mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true , MYSQL_CLIENT_SSL);
+                }else{
+                    $this->dbh = @mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true );
+                }

-               $this->dbh = @mysql_connect( $this->dbhost, $this->dbuser, $this->dbpassword, true );
-
                if ( !$this->dbh ) {
                        $this->bail( sprintf( /*WP_I18N_DB_CONN_ERROR*/"
 <h1>Error establishing a database connection</h1>

That’s all :)

O ile przepisów na stworzenie macierzy z użyciem mdadm są w sieci tysiące, o tyle chciałbym zwrócić uwagę na 3 istotne fakty. W tej chwili mam do zagospodarowania 4 dyski SATA 1TB w serwerze 1U. Postanowiono, że wykorzystane to będzie pod swap (4GB), /boot (500 MB), / (50GB) oraz /home (reszta). Zabawmy się zatem.

1. Tworzenie partycji.

Warto, aby każda z patrycji miała ustawiony typ “raid autodetect”. Pomaga to przy późniejszej identyfikacji i składaniu macierzy.

# fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x30f6ea17

Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         249     2000061   fd  Linux raid autodetect
/dev/sda2   *         250         312      506047+  fd  Linux raid autodetect
/dev/sda3             313        3473    25390732+  fd  Linux raid autodetect
/dev/sda4            3474      121601   948863160   fd  Linux raid autodetect

2. Jak najwięcej danych dotyczących samej macierzy powinno zostać zduplikowanych.

Pamiętajcie o opcji bitmap, dobrze jest ustawić ją na internal. Wówczas dane odnośnie samej macierzy uywane przy jej składaniu są przechowywane w metadanych tej macierzy i zreplikowane na wszystkie urządzenia wchodzące w skład macierzy.

mdadm -C /dev/md1 –level=10 –bitmap=internal -n 4 /dev/sd{a,b,c,d}1
mdadm -C /dev/md2 –level=1 –bitmap=internal -n 4 /dev/sd{a,b,c,d}2
mdadm -C /dev/md3 –level=10 –bitmap=internal -n 4 /dev/sd{a,b,c,d}3
mdadm -C /dev/md4 –level=10 –bitmap=internal -n 4 /dev/sd{a,b,c,d}4

3. RAID 5 czy RAID 10 ?

Dotychczas mając do dyspozycji 3 lub 4 dyski wybierałem RAID 5. Więcej miejsca niż w 10, ale też i o wiele dłuższy czas ewentualnego rebuildu macierzy po padzie zasilania w stosunku do RAID10. Dlatego też dziś chętnie wybieram ten drugi wariant. Dyski są duże i tanie, a więc nie żal jest miejsca, jeśli chodzi o bezpieczeństwo danych. No i oczywiście prętkość :) Ta macierz będzie składać się do końca z prętkoscią rzędu 200000K/sec.

# cat /proc/mdstat
Personalities : [raid10] [raid1]
md4 : active raid10 sdd4[3] sdc4[2] sdb4[1] sda4[0]
1897726080 blocks 64K chunks 2 near-copies [4/4] [UUUU]
[>....................]  resync =  1.6% (31655168/1897726080) finish=153.5min speed=202512K/sec
bitmap: 224/227 pages [896KB], 4096KB chunk

md3 : active raid10 sdd3[3] sdc3[2] sdb3[1] sda3[0]
50781312 blocks 64K chunks 2 near-copies [4/4] [UUUU]
bitmap: 5/194 pages [20KB], 128KB chunk

md2 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
505920 blocks [4/4] [UUUU]
bitmap: 0/62 pages [0KB], 4KB chunk

md1 : active raid10 sdd1[3] sdc1[2] sdb1[1] sda1[0]
3999872 blocks 64K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/123 pages [0KB], 16KB chunk

unused devices: <none>