Wojciech Błaszkowski

Na lapku uruchamiam Apache i MySQL wyłącznie na ::1. Ku wielkiemu zdziwieniu, jedyną przeglądarką, która nie poradziła sobie z “localhostem IPv6″ była najnowsza opera (11.01). Konqueror i iceweasel bez problemu wyświetliły stronę.

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 :)

W katalogu ustawień vserwera tworzymy podkatalog cgroup

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 :)

Not always you have a www server (Apache) and database (MySQL) on same machine. If not, it’s good to use SSL during the database connection. The hosting provider have to support MySQL connection over SSL. See MySQL reference for details.

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 :)

26 czerwca 2010 roku

Używanie macierzy dyskowych nie jest czymś niecodziennym. Obecnie, nawet w laptopach spotykane są miejsca na 2 dyski.

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>