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

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>

Od ponad miesiąca dostępna jest wersja OpenSSL 1.0. Administratorów czeka zatem przeinstalowanie lwiej części oprogramowania, o ile deweloperom udało się już je przekompilować.

Dla PLD Linux samo OpenSSL w nowej wersji jak i przekompilowane paczki są już dostępne, a zabawę zapewnią nam:

links, ekg, tcpdump, rdesktop, squid, wget, syslog-ng, lynx, net-snmp(-libs), rsync, openldap-libs, exim, nagios-nrpe, pure-ftpd, poldek-libs, bind-libs, apache(-tools),  mysql(-libs),  i inne,

libcap i korzystające z niej: tcpflow, dsniff, arpwatch, trafshow, nmap, iftop, i inne,

heimdal-libs i reszta zależnych od Kerberosa paczek; postgresql-libs, cups-lib, openssh-server, i inne.

Dla posiadaczy desktopów (z kartą nVidia) możemy upgradnąć serwer X’ów do wersji xorg-xserver-server-1.8.0 wraz z xorg-driver-video-nvidia-195.36.24. Driver ten wspiera już OpenSSL 1.0.

Majowy weekend zapowiadany jest jako deszczowy, więc bez żalu można będzie przysiąść i upgradnąć to i owo. Have fun.

Próbowałem ostatnio utworzyć patrycję nieco większą niż zwykle, 2,3TB. Tradycyjnie do pracy został zagoniony cfdisk, w końcu od tego jest – pomyślałem. Z jakichś przyczyn jednak cfdisk w wersji z paczki util-linux-ng-2.16 zamiast utworzyć rządaną przezemnie partycję, utworzył ją w wielkości 300GB. Doczytałem, że cfdisk nie obsłuży patrycji powyżej 2TB, co nie zmienia faktu, że powinien zakrzyczeć o tym fakcie. Użyłem parted który poradził sobie z problemem wyśmienicie.

Zrobienie patrycji na całej dostępnej przestrzeni dysku:

# mkpart primary 0 -0

Warto zaznaczyć, że parted nie jest programem do zabawy – zmiany zapisywane są na dysk bez zatwierdzania, zaraz po ich “nakazaniu”.