Prawie miesiąc temu opublikowano stabilną wersję HAProxy 1.4 . W nowej wersji dodano bardzo przydatny check do MySQLa (option mysql-check). W końcu HAProxy potrafi monitorować stan bazy bez customizowanych skryptów czy innych wynalazków.
listen mysql 0.0.0.0:3306
mode tcp
option mysql-check
balance roundrobin
server mysql_server_1 1.1.1.1:3306 check port 3306
W niedawno wydanym Kernelu 2.6.32 dodano ciekawy ficzer z punktu widzenia wirtualizacji – Kernel Samepage Merging, wcześniej znany jako Kernel Shared Memory. Specjalny daemon kernel, ksmd skanuje pamięć w poszukiwaniu takich samych stron, które można zastąpić pojedyńczym wpisem. Jak podaje http://kernelnewbies.org przyczynia się to do bardzo dużego obniżenia zużycia pamięci w środowiskach wirtualizowanych.
Modern operative systems already use memory sharing extensively, for example forked processes share initially with its parent all the memory, there are shared libraries, etc. Virtualization however can’t benefit easily from memory sharing. Even when all the VMs are running the same OS with the same kernel and libraries the host kernel can’t know that a lot of those pages are identical and can be shared. KSM allows to share those pages. The KSM kernel daemon, ksmd, periodically scans areas of user memory, looking for pages of identical content which can be replaced by a single write-protected page (which is automatically COW’ed if a process wants to update it). Not all the memory is scanned, the areas to look for candidates for merging are specified by userspace apps using madvise(2): madvise(addr, length, MADV_MERGEABLE).
The result is a dramatic decrease in memory usage in virtualization environments. In a virtualization server, Red Hat found that thanks to KSM, KVM can run as many as 52 Windows XP VMs with 1 GB of RAM each on a server with just 16 GB of RAM. Because KSM works transparently to userspace apps, it can be adopted very easily, and provides huge memory savings for free to current production systems. It was originally developed for use with KVM, but it can be also used with any other virtualization system – or even in non virtualization workloads, for example applications that for some reason have several processes using lots of memory that could be shared.
http://lwn.net/Articles/306704/
http://lwn.net/Articles/330589/
Ostatnio pisałem o kernelu 2.6.27. Okazuje się, że od paru dni krąży exploit pozwalający na lokalny atak denial of service na wersje starsze niż 2.6.27.5 .
The __scm_destroy function in net/core/scm.c in the Linux kernel 2.6.27.4, 2.6.26, and earlier makes indirect recursive calls to itself through calls to the fput function, which allows local users to cause a denial of service (panic) via vectors related to sending an SCM_RIGHTS message through a UNIX domain socket and closing file descriptors.
Miesiąc temu wydano kernel 2.6.27, m.in. usprawniono w nim obsługę page cache’u dla systemów wieloprocesorowych. Ciekawe jak bardzo nowa funkcja get_user_pages_fast() potrafi poprawić wydajność systemu, może ktoś już to testował?
The page cache is the place where the kernel keeps in RAM a copy of a file to improve performance by avoiding disk I/O when the data that needs to be read is already on RAM. Each “mapping”, which is the data structure that keeps track of the correspondence between a file and the page cache, is SMP-safe thanks to its own lock. So when different processes in different CPUs access different files, there’s no lock contention, but if they access the same file (shared libraries or shared data files for example), they can hit some contention on that lock. In 2.6.27, thanks to some rules on how the page cache can be used and the usage of RCU, the page cache will be able to do lookups (ie., “read” the page cache) without needing to take the mapping lock, and hence improving scalability. But it will only be noticeable on systems with lots of cpus (page fault speedup of 250x on a 64 way system have been measured).
In 2.6.27, a new get_user_pages_fast() function has been introduced, which does the same work that get_user_pages() does, but its simplified to speed up the most common workloads that exercise those paths within the same address space. This new function can avoid taking the mmap_sem semaphore and the page table locks in those cases. Benchmarks showed a 10% speedup running a OLTP workload with a IBM DB2 database in a quad-core system.
Kilka przydatnych skryptów do Nautilus’a.
1) ściągamy
2) wypakowujemy
3) wrzucamy do ~/.gnome2/nautilus-scripts
4) i już
Jeżeli ktoś z Was chciałby skompilować natywnego Cisco VPN Client’a na Linuksie >= 2.6.19 i miał z tym problemy to polecam stronkę http://tuxx-home.at/archives/2007/05/29/T16_34_26/, gdzie znajduje się patch na kernel. Po jego nałożeniu problem z kompilacją znika.
Zauważyłem, że wiele osób nie korzysta jeszcze z dobrodziejstwa jakie daje ACPI (Advanced Configuration and Power Interface). Jeżeli posiadamy komputer z obecnej epoki;) (czyt. z płytą ATX) możemy wyłączać naszego Linuksa za pomocą przycisku Power na obudowie, zamiast wpisywać z shella poweroff. Co będzie potrzebne nam do tego rozwiązania?
1) Przede wszystkim wkompilowana obsługa ACPI w kernelu (jeżeli jeszcze tego nie masz).
Power management options (ACPI, APM) —>
ACPI (Advanced Configuration and Power Interface) Support —>
[*] ACPI Support
< M > Button
2) Oraz daemon acpid (Ubuntu way;))
# apt-get install acpid
Po reboocie z nowy kernelem upewnijmy się czy wszystko gra:
# dmesg | grep Button
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (FF) [SLPF]
ACPI: Power Button (CM) [PWRB]
Jeżeli otrzymamy komunikat podobny do powyższego to znaczy, że mamy już wkompilowaną obsługę ACPI. I to właściwie tyle, to wszystko co jest nam potrzebne. Teraz po naciśnięciu guzika ‘Power’ na obudowie Linux zatrzyma wszystkie daemony i na końcu wyłączy serwer. Całe rozwiązanie obsługiwane jest przez daemona acpid, który nasłuchuje w /proc/acpi/event, czy nie nastąpiło zdarzenie obsługiwane przez ACPI, jak np. nacisnięcie ‘Power’ na obudowie. Jeżeli coś takiego nastąpi, wówczas acpid wykonuje wcześniej zdefinowaną akcję w /etc/acpi/events i uruchamia w userspace’ie dowolne polecenie, np. poweroff lub shutdown -h now.
Bardzo ciekawą rzeczą, nieznaną jeszcze przez wiele osób jest technika port knockingu. Umożliwia ona, za sprawą wysłanej sekwencji pakietów (puknięć) do hosta, zdalne wykonanie wcześniej zdefiniowanego polecenia na wspomnianym hoscie, bez logowania się na niego. Niby nic nadzwyczajnego, ale ciekawą sprawą jest możliwość zdefiniowania sekwencji puknięć, które np. uruchamiają jakąś usługę, bez konieczności otwierania portów, na które przychodzi puknięcie.
Klasycznym zastosowaniem tego rozwiązania jest udostępnianie ssh na serwerze, wyłącznie gdy zachodzi taka potrzeba. Istnieje przynajmniej kilka implementacji tej techniki. Ja proponuję na początek projekt knock. Po zainstalowaniu demona knockd, w Ubuntu robimy to przez zwykłe
# apt-get install knockd
przechodzimy do jego konfiguracji.
logfile = syslog
logfile, chyba nie wymaga komentarza, ustawienie tego parametru na syslog spowoduje, że demon będzie pisać do sysloga.
sequence = 7000,8000,9000
sequence, to sekwencja, określająca porty, na które mają zostać wysłane puknięcia. Można też podać typ pakietów TCP i/lub UDP.
seq_timeout = 5
seq_timeout, czas w sekundach, w jakim musi zmieścić się sekwencja pukania.
command = /sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
command, polecenie systemowe jakie ma zostać wykonane
tcpflags = syn
tcpflags, knockd ma zwracać uwagę tylko na pakiety, z flagą podaną w tym parametrze.
Ostatecznie plik konfiguracyjny wygląda następująco
# cat /etc/knockd.conf
[options]
logfile = /var/log/knockd.log
[openSSH]
sequence = 7000,8000,9000
seq_timeout = 5
command = /sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn
[closeSSH]
sequence = 9000,8000,7000
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn
gdzie %IP% to IP maszyny, która wykonuje pukanie. W ten sposób wysyłając sekwencję pakietów tcp z ustawiona flagą syn na porty 7000,8000,9000 otworzymy dla siebie furtkę w firewallu na port 22, a zamkniemy ją wysyłając sekwencję pakietów na porty 9000,8000,7000. Do wysyłania sekwencji puknięć możemy wykorzystać np. SendIP, klienta knock lub dla Windowsa knockknock.
Polecam też stronę o port knockingu http://portknocking.org/. Nie twierdzę, że port knocking wpływa rewelacyjnie na poprawę bezpieczeństwa, jest jednak interesującą techniką, której warto się przyjrzeć.
Przeglądając www trafiłem na dwa mini projekty, które wizualizują historię powstawania dystrybucji Linuksa. Zamieszczam link do pierwszego jak i drugiego projektu.
Wraz z wydaniem kernela 2.6.14, dołączono do jego źrodeł projekt FUSE (Filesystem in Userspace). FUSE można używać jako moduł do kernela, pozwala on na montowanie systemu plików przez użytkownika, który nie posiada praw roota. Wraz z SSH Filesystem, dostajemy wygodne rozwiązanie dla ludzi posiadających kilka kont shellowych na różnych hostach, którym zbrzydło ciągłe kopiowanie plików pomiędzy maszynami za pomocą scp. Jak całość uruchomić?
Przede wszystkich trzeba skompilować kernel z obsługą FUSE, a następnie zainstalować sshfs. W Ubuntu robi się to przez zwykłe
# apt-get install sshfs
W drugiej kolejności dorzucamy moduł fuse
# modprobe fuse
Trzeba także dodać użytkownika do grupy fuse, tak by mógł mountować zasoby
# usermod -G fuse juggler
Teraz możemy potworzyć katalogi, w których będziemy montować zdalne zasoby i ostatecznie podmontować te zasoby
$ mkdir host1.domena.com
$ mkdir host2.domena.com
$ sshfs juggler@host1.domena.com:/home/juggler host1.domena.com
$ sshfs juggler@host2.domena.com:/home/juggler host2.domena.com
i to wszystko, od tego momentu w katalogu host1.domena.com i host2.domena.com mamy podmontowane zdalne zasoby po ssh. Możemy na nich wykonywać dowolne operacje jak kopiowanie, usuwanie, edycja, modyfikacja praw itd.
Gdy skończymy zabawę zdalne zasoby odmontowujemy poprzez
$ fusermount -u host1.domena.com
$ fusermount -u host2.domena.com
Jeżeli mamy wymienione klucze z wcześniej wspomnianymi hostami możemy je dodać na stałe do /etc/fstab
sshfs#juggler@host1.domena.com:/home/juggler /home/juggler/host1.domena.com fuse defaults 0 0
Trzeba oczywiście pamiętać o dopisaniu modułu fuse do /etc/modules, tak aby był ładowany przy uruchamianiu. W sumie żadna nowość, ale dużo osób nadal o tym nie wie. FUSE można oczywiście używać także pod 2.4.x.
Next,
