Wygodniejsze logowanie przez SSH

Logowanie przez SSH może być upierdliwe, zwłaszcza jeśli serwery są dostępne tylko przez IP lub przez długą domenę, a SSH działa na niestandardowym porcie. Mam pod swoją opieką kilka takich serwerów i spamiętanie adresów i portów nie bardzo mi szło. Swego czasu ułatwiałem sobie życie przez dodawanie adresów do pliku /etc/hosts, ale to niezbyt sensowne rozwiązanie. Jest lepsze, które odkryłem przy lekturze podręcznika ssh.

W pliku ~/.ssh/config można zdefiniować sobie parametry dostępu do poszczególnych hostów. Wygląda to tak:

Host challenger
  HostName challenger.femina.com.pl

Host bigtruck
  HostName s74.vdl.pl
  Port 59184
  User bigtruck

Dzięki temu żeby zalogować się na serwer bigtruck zamiast wpisywać:

ssh -p 59184 bigtruck@s74.vdl.pl

wystarczy:

ssh bigtruck

Dodatkową zaletą jest to, że na serwery wpisane w konfigurację ssh działa automatyczne uzupełnianie, więc w powyższym przykładzie wystarczy wklepać tylko pierwsze litery nazwy, a potem tab.

Pozostaje kwestia haseł. Temat autoryzacji przez klucze jest opisany w różnych HOWTO milion razy, ale w większości wypadków przepis zaleca ręczne skopiowanie pliku w odpowiednie miejsce na docelowym serwerze. Można prościej:

ssh-copy-id bigtruck

Dzięki tym dwóm zabiegom logowanie przez SSH jest szybkie jak mrugnięcie okiem i proste jak konstrukcja cepa.

VV Brown czyli o pożytku z oglądania kiepskich filmów

Lubię oglądać różne filmy, nawet te kiepskie. „Dobre złe filmy” bywają zabawne w swej miernocie, ale nie da się ukryć, że poza śmiechawką nie można wiele z nich wynieść. Ale zdarzają się wyjątki. Takim wyjątkiem jest „Lesbian Vampire Killers”. Mocarny tytuł obiecuje dobrą zabawę, ale niestety film jest cienki jak guma w gaciach. Jego największą zaletą są napisy początkowe, bo właśnie tam po raz pierwszy usłyszałem VV Brown, a konkretnie piosenkę „Crying Blood”.

Po mojemu to jest zajefajne pod każdym względem: VV ma świetny głos, muzyka to, poprawcie mnie jeśli pomyliłem style, to świeże połączenie rock and rolla, twista i popu, teledysk takoż łączy nowe ze starym, a przede wszystkim piosenka strasznie wpada w ucho.

Pudelki, Plotki, MTV, Vivę, RMF-y, Eski i takie tam przyjmuję w dawkach homeopatycznych, ale nigdzie w polskich mediach nie natknąłem się na choćby wzmiankę o VV Brown, więc chyba nie pomylę się, jeśli napiszę, że nie jest u nas znana. Jeśli jej nie znacie to warto poznać, bo to nie jest gwiazda jednej piosenki. Zobaczcie choćby „Game Over”, trudno by mi było zdecydować, która z tych dwóch piosenek jest bardziej zajebista.

Frycowe na raty

Naiwnego internautę można wydoić z kasy na różne sposoby. Jednym z łatwiejszych jest skłonienie go do rozwiązania bzdurnego testu, a za pokazanie wyników kazać sobie płacić 60 zeta w SMS-ach premium.

Naiwnego internautę można wydoić z kasy na różne sposoby. Jednym z łatwiejszych jest skłonienie go do rozwiązania bzdurnego testu, a za pokazanie wyników kazać sobie płacić 60 zeta w SMS-ach premium.

Przedwczoraj dostałem propozycję reklamowania na anime.com.pl strony pozwalającej poznać datę własnej śmierci. Zanim spuściłem ich na bambus dla porządku zajrzałem na ową stronę. Jakież było moje zdziwienie, gdy w regulaminie przeczytałem, że poznanie wyniku testu wymaga wysłania SMS-a, który kosztuje tyle co zwykły SMS w ofercie naszego operatora. Pomyłka? Promocja? Większy wałek? Na jasne, że większy wałek! Wyjaśnienie przynosi czwarty punkt regulaminu, który pozwoliłem sobie przytoczyć poniżej (pisownia oryginalna, wyróżnienia moje):

Wysłanie sms o treści START ZYCIE na numer 60128 oznacza zapisanie się na serwis typu SMS MT (Mobile Terminated). Urzytkownik będzie otrzymywał jedną wiadomość sms dziennie. Całkowity koszt odebrania jednej wiadomości sms z serwisu MT ZYCIE to 1,23PLN. Regulamin serwisu jest dostępny na stronie http://www.wapster.pl/Regulamin_SMS_MT.pdf.

Oznacza to, że opłata za bycie frajerem została rozłożona na wygodne raty 0%. Jeśli nasz hipotetyczny frajer wykaże odrobinę zdrowej nieufności, ma szansę zapłacić tylko kilka złotych frycowego. Jeśli jednak przyjmie przychodzące SMS-y za dobrą monetę, to dopiero przy płaceniu rachunku zobaczy w co się wpakował, a do tego czasu będzie uboższy o kilkadziesiąt złotych. Jest to ten sam mechanizm, co w głośnych ostatnimi czasy złodziejskich loteriach Ery i Orange, przy czym w loterii przynajmniej istniała jakaś szansa na wygranie interesujących nagród, zaś w opisywanym przypadku dostaniemy wyssaną z dupy datę śmierci i codzienną dawkę nie wartych funta kłaków porad zdrowotnych.

Mam nadzieję, że powyższy wywód skutecznie przestrzegł was przed pokusą poznania daty własnej śmierci. Jeśli już damy się złapać w sidła naciągaczy, trudno się z nich wydostać. Taki komunikat zobaczyłem przy próbie zamknięcia zakładki z testem:

data śmierci

/var/lock i /var/run w RAM-ie na Debianie

Na co dzień mam do czynienia z Debianem, Gentoo i Ubuntu. W tych dwóch ostatnich systemach katalogi /var/lock i /var/run zamontowane są na ramdysku. Ma to sporo sensu ponieważ do tych katalogów dość często zapisywane są małe pliczki, a dane są ulotne (po resecie i tak tracą znaczenie). Dzięki przeniesieniu tych danych do RAM-u oszczędzamy mechanikę dysku, miejsce, a i pewnie trochę przyspieszamy działanie systemu.

Debian prezentuje bardziej konserwatywne podejście, wspomniane katalogi są tworzone w głównym katalogu. Na szczęście przeniesienie ich do RAM-u sprowadza się do zmiany dwóch linijek w pliku /etc/default/rcS:

TMPTIME=0
SULOGIN=no
DELAYLOGIN=no
UTC=yes
VERBOSE=no
FSCKFIX=no
RAMRUN=yes
RAMLOCK=yes

Zmienione linijki pogrubiłem. Po wykonaniu tych zmian trzeba wykonać reset i voila:

System plików         rozm. użyte dost. %uż. zamont. na
/dev/mapper/gt500-root
                      7,4G  1,6G  5,5G  23% /
tmpfs                 999M     0  999M   0% /lib/init/rw
varrun                999M  420K  998M   1% /var/run
varlock               999M     0  999M   0% /var/lock
udev                  994M  160K  993M   1% /dev
tmpfs                 999M     0  999M   0% /dev/shm
/dev/sda1              89M   16M   69M  19% /boot
/dev/mapper/gt500-home
                      104G   17G   88G  16% /home

Jak wyczytałem w dokumentacji Debiana, niektóre starsze programy źle działają jeśli /var/lock i /var/run nie są obecne na dysku. Na moim serwerku mam sporo softu (m.in. Apache, MySQL, PostgreSQL, Exim, ProFTPd, memcached) i nie zauważyłem żadnych problemów. Dlatego zgaduję, że w większości instalacji Debiana, zarówno desktopowych jak i serwerowych, warto pokusić się o wykonanie omawianej zmiany.

Doctrine Query Cache w Symfony

Dzisiaj o odkrywaniu Ameryki w konserwie. Właśnie takie miałem wrażenie, gdy dłubiąc w projekcie trafiłem na rozdział na temat cache w dokumentacji Doctrine. Wcześniej tam nie trafiłem, bo całe keszowanie robiłem w Symfony – wszak do pamięci podręcznej najlepiej wrzucać efekt końcowy. Dodatkowo w dokumentacji Symfony nie rzuciło mi się w oczy nic na temat cacheowania w Doctrine.

Nie zamierzam streszczać dokumentacji Doctrine. W kontekście tej notki ważne jest, że Doctrine może zapamiętywać w cache dwa rodzaje danych:

  • skompilowane zapytania
  • wyniki zapytań

Dzięki zapamiętywaniu zapytań czasochłonny proces parsowania zapytania i budowania docelowej SQL-ki jest wykonywany tylko raz, kolejne wywołania będą korzystać z danych zapamiętanych w pamięci podręcznej. Problem aktualności danych w cache nie istnieje ponieważ zmiana zapytania spowoduje automatyczne wygenerowanie nowych danych. Korzyści są niebagatelne, użycie proste jak konstrukcja cepa, a problemów nie ma. Dlatego zgodnie z dokumentacją i zdrowym rozsądkiem, pamięć podręczna zapytań powinna być zawsze włączona, nawet w środowisku testowym.

Włączenie cache dla Doctrine w projekcie Symfony jest banalne i sprowadza się do dodania króciutkiej metody w klasie config/ProjectConfiguration.class.php.

public function configureDoctrine(Doctrine_Manager $manager)
{
    $manager->setAttribute(Doctrine_Core::ATTR_QUERY_CACHE, new Doctrine_Cache_Apc());
}

Powyższy kod spowoduje, że skompilowane zapytania będą zapamiętywane w pamięci APC. Oprócz APC Doctrine może współpracować z serwerem memcached lub inną bazą danych (np. SQLite).

Cache można włączyć nie tylko na poziomie managera, równie dobrze można zrobić to w samym zapytaniu:

$q = Doctrine_Query::create()
    ->useQueryCache(new Doctrine_Cache_Apc());

Jak wspomniałem wcześniej, pamięć podręczna zapytań powinna być włączona zawsze. Na poziomie konkretnego zapytania więcej sensu ma włączanie zapamiętywania wyników:

$q = Doctrine_Query::create()
    ->useResultCache(new Doctrine_Cache_Apc());

Wymiatacze z TVN-u

Irytuje mnie postawa „Polak potrafi… spierdolić”, która często pojawia się w dyskusjach na temat różnorakich dokonań Polaków. Jednak gdy widzę coś takiego, jak „Wymiatacze” to zaczynam wierzyć, że coś jest na rzeczy.

W tym miejscu należy się wyjaśnienie. Dawno temu japoński teleturniej „Takeshi’s Castle” zauroczył mnie od pierwszych sekund. Ponieważ jeden obraz mówi więcej niż tysiąc słów posłużmy się dowodem rzeczowym numer jeden:

Czytaj dalej „Wymiatacze z TVN-u”

Bidet

Ta notka będzie stanowić dla mnie katharsis i to w sensie dosłownym, gdyż rzecz będzie o oczyszczeniu, jednak nie duszy. Z niejakim zażenowaniem muszę przyznać, że dopiero niedawno poznałem funkcję bidetu. Wcześniej przez długie lata sądziłem, że służy on do mycia nóg. Z błędu wyprowadziła mnie moja ukochana, a śmiechu było co niemiara.

Laughs have been had i w tym miejscu można by postawić kropkę, ale zacząłem zastanawiać się skąd wzięły się moje wyobrażenia o funkcji bidetu i jakim sposobem przez blisko trzydzieści lat brutalna prawda nie zdołała się przebić przez mury mej ignorancji. Uzupełniając wspomnienia domysłami wyszło mi, że po raz pierwszy z bidetem spotkałem się na zdjęciu, zapewne w jakimś katalogu wyposażenia łazienek, a miałem wtedy lat małonaście. Ponieważ z kontekstu w którym zdjęcie występowało nijak nie wynikała funkcja tego urządzenia, więc musiałem dorobić sobie własną interpretację na podstawie doświadczeń. Z doświadczenia zaś wiedziałem, że jeśli chce się dokonać szybkiej ablucji to niewygodnie jest zadzierać nogę do umywalki. Logicznym remedium na te niedogodności zdawało mi się urządzenie z bieżącą wodą wysokości mniej więcej klopa. Wypisz, wymaluj bidet. Logiczne, nie?

Teraz zastanawiam się ile jeszcze takich bidetów kryje mój leksykon.

W ramach post scriptum bidet z tubki.

Powiązanie nazwy interfejsu sieciowego z adresem MAC

Numerowanie interfejsów sieciowych w Linuksie jest dość tajemniczym procesem, przynajmniej dla mnie. Dość powiedzieć, że przeważnie system nadaje im inne numerki niż bym sobie życzył. Co więcej, jeśli mamy już w systemie interfejs eth0, nie ma gwarancji, że po dołożeniu drugiej karty sieciowej zostanie ona wykryta jako eth1. Na szczęście obecnie można w łatwy sposób przekonać system do swoich racji. W Debianie (i Ubuntu) należy skierować się ku plikowi /etc/udev/rules.d/70-persistent-net.rules. Właśnie w tym pliku system zapisuje powiązanie pomiędzy adresem MAC karty sieciowej a nazwą interfejsu. Przykładowa zawartość pliku:

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="70:71:bc:b1:93:94", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:02:44:70:1f:3e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

W tym konkretnym wypadku chciałem zamienić interfejsy kolejnością, tak aby eth0 był połączony z modemem, a gigabitowy eth1 z siecią lokalną. Żeby to osiągnąć wystarczyło zamienić cyferki w parametrze NAME:

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="70:71:bc:b1:93:94", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:02:44:70:1f:3e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Korzystając z tego pliku można pójść dalej i nadać interfejsom bardziej czytelne nazwy np. eth-wan, eth-lan czy eth-intel.

Etykiety w YAML-u przyjacielem leniwego programisty

Sympatyczny wynalazek, jakim jest YAML, jest używany w Symfony niemal na każdym kroku. I bardzo lepiej, bo to bardzo przyjazny człowiekowi format zapisu. Dokumentacja Symfony na temat YAML-a jest jednak dość lakoniczna i nie opisuje wszystkich jego możliwości. Jednym z pominiętych zagadnień są na ten przykład etykiety, które pozwalają zredukować ilość wklepywanych danych.

Etykiety najbardziej przydają się przy definiowaniu danych statycznych aplikacji (fixtures). Załóżmy, że tworzymy katalog usług hostingowych. Usługę VPS można opisać chociażby tak:

  vps_hitme_openvz_128: &vps_hitme_openvz
    Company:            hitme
    name:               OpenVZ 128
    Virtualization:     openvz
    guaranteed_memory:  128
    burstable_memory:   256
    swap_memory:        0
    disk_space:         20
    uplink:             100
    downlink:           100
    bandwidth:          50
    ip_4_addresses:     1
    ip_6_mask:          64
    root_access:        true
    is_managed:         false
    url:                http://www.hitme.net.pl/openvz-details.php
    is_verified:        true
    is_active:          true

Kolejne pakiety różniące się od powyższego tylko nazwą, ilością dostępnej pamięci, powierzchnią dyskową i transferem można opisać o wiele krócej:

  vps_hitme_openvz_256:
    <<:                 *vps_hitme_openvz
    name:               OpenVZ 256
    guaranteed_memory:  256
    burstable_memory:   512
    disk_space:         20
    bandwidth:          100

Składnia i działanie etykiet w powyższym przykładzie są oczywiste, opiszę je jedynie dla porządku. Etykietę poprzedzamy znakiem &. Dane oznaczone etykietą włączamy używając operatora << jako klucza, którego wartością jest nazwa etykiety poprzedzona *. Spowoduje połączenie tablicy oznaczonej etykietą z bieżącą tablicą. Jeśli w obu tablicach występuje ten sam klucz to zostanie użyta wartość z bieżącej tablicy. Prawda, że przydatne?

Dane binarne w PHP

Przy pisaniu poprzedniej notki o base64_encode() przypomniało mi się inne zastosowanie base64, a mianowicie osadzanie danych binarnych w kodzie PHP. Poniższy kawałek kodu wypluwa przezroczysty obrazek w formacie GIF o rozmiarach 1 x 1 px. Jest to fragment skryptu, który zlicza otwarcia mailingu.

header('Content-Type: image/gif'); 
header('Expires: Wed, 11 Nov 1998 12:00:00 GMT'); 
header('Cache-Control: no-cache'); 
header('Cache-Control: must-revalidate'); 
die(base64_decode('R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOwA='));

Oczywiście równie dobrze plik można zapisać na dysku i wypluwać go przez file_get_contents() lub przekierować do niego przez wysłanie nagłówka Location, ale powyższe rozwiązanie ma tę zaletę, że plik jest osadzony w skrypcie. To może być istotne jeśli sprzedajemy skrypt zakodowany np. ionCubem i nie chcemy, żeby klient miał możliwość podmiany obrazka. Dodatkowo base64_decode() ma szanse być szybsze niż otwarcie i wczytanie zewnętrznego pliku, a od przekierowania przez nagłówek Location jest szybsze na bank.

Z drugiej strony osadzanie plików w skrypcie ma sens tylko dla niedużych plików, tak π razy oko do 2-3 KiB. Przy większych plikach wybrałbym file_get_contents(), ze względu na mniejszy rozmiar skryptu PHP i prawdopodobnie większą szybkość działania.

Z trzeciej strony, jeśli podstawowym celem jest szybkość działania, można pokusić się o jeszcze inne rozwiązanie.

define(EMPTY_GIF_IMAGE, "\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\xff\xff\xff\xff\xff\xff\x21\xf9\x04\x01\x0a\x00\x01\x00\x2c\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02\x4c\x01\x00\x3b\x00");
header('Content-Type: image/gif'); 
header('Expires: Wed, 11 Nov 1998 12:00:00 GMT'); 
header('Cache-Control: no-cache'); 
header('Cache-Control: must-revalidate'); 
die(EMPTY_GIF_IMAGE);

Jeśli korzystamy z APC lub podobnego rozwiązania to po kompilacji skryptu stała EMPTY_GIF_IMAGE będzie zawierała nasz pliczek GIF w postaci gotowej do użycia, odpada konieczność konwersji z base64. Zastrzegam, że nie sprawdzałem tego w praktyce, ale zdziwiłbym się, gdyby nie było to najszybsze z opisywanych rozwiązań.