Konfigurujemy VPS - część 3, kilka ważnych drobiazgów

Trzeci artykuł z cyklu Konfigurujemy VPS. Tym razem kilka drobnych ale ważnych ustawień, o które przywykliśmy być pytani w trakcie instalacji systemu - ale na VPS musimy poprawiać post-factum: nazwa maszyny, data/czas i strefa czasowa, wersje językowe.

Nazwa maszyny

Oprócz konfiguracji nazw w DNS trzeba zadbać także o lokalną nazwę maszyny, tj. nazwę zwracaną przez polecenie hostname i funkcję biblioteczną gethostname).

Nazwa ta jest używana przez wiele programów. Pojawia się w znaku zachęty shella, w logach systemowych, korzystają z niej różne aplikacje i skrypty użytkowe.

Pod nieobecność /etc/hostname możemy np. znaleźć w /var/log/messages wpisy z słowem null:

Sep 10 08:05:50 (null) kernel: ...

Inne programy mogą reagować różnie, od odgadnięcia poprawnej nazwy po trudne do zdiagnozowania błędy.

Nie teoretyzując już dalej: wpisujemy właściwą nazwę do /etc/hostname (tworząc ten plik jeśli go nie było, usuwając poprzednią zawartość, jeśli był), na przykład:

superserwer.com.pl

Będzie to miało skutki od następnego reboot-u. By nie restartować, doraźną poprawkę wprowadzamy z palca:

$ sudo hostname superserwer.com.pl

a efekt sprawdzamy wołając:

$ hostname -f

Strefa czasowa

Musimy zdecydować, w jakiej strefie czasowej chcemy mieć domyślnie podawany czas (lokalny, ten który wypisuje polecenie date, ten który podaje większość wyświetlających czas programów). Sensowne możliwości są zwykle dwie - normalny czas polski albo czas uniwersalny (UTC). Domyślna konfiguracja ... może być różna (np. przewidywać czas lokalny dla sprzedawcy usługi). Ja zwykle ustawiam czas polski.

Na Debianie i Ubuntu najwygodniejszą metodą skonfigurowania strefy czasowej jest:

$ sudo dpkg-reconfigure tzdata

(program pozwoli wybrać z listy).

W innych dystrybucjach także zalecane jest zrekonfigurowanie jakiegoś analogicznego pakietu. W najgorszym wypadku można ustawić co trzeba ręcznie, np:

$ sudo echo 'Europe/Warsaw' > /etc/timezone
$ sudo cp -f /usr/share/zoneinfo/Europe/Warsaw /etc/localtime

Data i czas

Nie ma sensu na VPSie ustawiać daty i czasu, czy instalować programów synchronizujących czas po NTP. To już kompetencje maszyny głównej. Jeśli prezentowany czas jest błędny - i nie chodzi o źle wybraną strefę - trzeba po prostu skonsultować się z supportem VPSa.

Teoretyczna możliwość uniezależnienia się od czasu głównej maszyny istnieje, przynajmniej na Xen:

echo 1 > /proc/sys/xen/independent_wallclock

ale trudno mi sobie wyobrazić dla niej sensowne zastosowanie.

Na wypadek gdyby zerkał na ten poradnik ktoś konfigurujący pełną maszynę (nie VPS): w takim wypadku o synchronizację czasu warto zadbać. Można to robić bądź uruchamiając co pewien czas polecenie ntpdate, bądź utrzymując uruchomiony demon ntpd.

Locale

Kolejna sprawa to ustawienia językowe, czyli locale. Decydują one o języku w jakim są wyświetlane rozmaite komunikaty, formatach liczb, dat a także - co może najważniejsze - o kodowaniu znaków. Ot, na przykład (ale proszę doczytać parę akapitów dalej przed testowaniem poniższych poleceń):

$ export LANG=pl_PL.UTF-8

$ date
pią, 19 wrz 2008, 22:26:53 CEST

$ ls --help
Składnia: ls [OPCJA]... [PLIK]...
Wypisanie informacji o PLIKACH (...)

$ export LANG=fr_FR.UTF-8

$ date
vendredi 19 septembre 2008, 22:26:59 (UTC+0200)

$ ls --help
Usage: ls [OPTION]... [FICHIER]...
Afficher les informations au sujet des FICHIERS (...)

Piszę wyżej pl_PL.UTF-8 a nie pl_PL. To celowe. W chwili obecnej używanie polskich znaków w kodowaniu iso-8859-2 jest po prostu proszeniem się o niepotrzebne kłopoty. UTF-8 działa, nie sprawia żadnych problemów i pozwala raz na zawsze pozbyć się kłopotów z koniecznością pamiętania w jakim kodowaniu jest zapisany dany plik czy baza danych.

Konfigurowanie locale rozbija się na dwa elementy:

• skonfigurowanie jakie locale będą w ogóle dostępne w systemie,
• wybór domyślnego locale systemowego.

Nie wszystkie locale są domyślnie dostępne (każdy aktywowany język to kilkadziesiąt megabajtów na dysku). Wypróbowanie powyższych poleceń na VPSie najprawdopodobniej skończy się uzyskaniem anglojęzycznych odpowiedzi (tak zwany schemat C, ustawiany przez LANG=C jest zawsze dostępny, jest to zapis angielski w kodowaniu iso-8859-1, a właściwie ASCII). O braku odpowiednich danych dość agresywnie potrafi poinformować perl:

$ LANG=pl perl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
       LANGUAGE = "pl_PL:pl:en_GB:en",
       LC_ALL = (unset),
       LANG = "pl"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Niestety, sposób instalowania/aktywowania paczek językowych zależy od dystrybucji Linuxa a nawet jej wersji. W aktualnym Ubuntu (8.04 i nowsze) najwygodniej jest zainstalować odpowiedni language-pack, np:

$ sudo apt-get install language-pack-pl
$ sudo apt-get install language-pack-en

Listę takich modułów można znaleźć robiąc

$ apt-cache seach language-pack

Minimum, które na pewno warto zainstalować, to wymienione wyżej pakiety polski i angielski. Przydatność innych zależy od aplikacji jakie będziemy wykorzystywać (ot, np. od tego, czy jakaś webowa aplikacja którą zrobimy lub zainstalujemy, pozwoli jakiemuś użytkownikowi stosować francuski czy rosyjski zapis dat i liczb - a jeśli tak, czy dany język i framework korzysta w tym celu z funkcji biblioteki standardowej).

Instalacja pakietu language-pack-pl powoduje nagranie na dysku rozmaitych plików (.mo) z tłumaczeniami, a przede wszystkim:

• pojawienie się /var/lib/locales/supported.d/pl o treści pl_PL.UTF-8 UTF-8
• uruchomienie programu locale-gen w celu wygenerowania binarnych plików z opisem polskiego locale.

Gdyby ktoś naprawdę musiał użyć polskiego locale w iso-8895-2, aktualna metoda jego uzyskania to:

• dopisanie do pliku /var/lib/locale/supported.d/local nowej linijki o treści pl_PL ISO-8859-2
• przegenerowanie locale poleceniem locale-gen

Starsze wersje Ubuntu posługiwały się (Debian chyba ciągle to robi) plikiem /etc/locale.gen, do którego wpisywano (wiersz po wierszu) wszystkie locale jakie mogą być użyte, np:

en_US ISO-8859-1
en_US.UTF-8 UTF-8
pl_PL ISO-8859-2
pl_PL.UTF-8 UTF-8

Po uzupełnieniu powyższego, należało uruchomić

$ sudo dpkg-reconfigure locales

albo po prostu

$ sudo locale-gen

Na nie-Debianowych dystrybucjach może być jeszcze inaczej (np. generacja locale może się odbywać w trakcie konfiguracji pakietu glibc), niestety muszę tu już odesłać do poszukiwań we właściwym podręczniku instalacji.

Drugi element to ustawienie sensownego domyślnego locale. Bo oczywiście można ręcznie (czy w plikach .bashrc, czy gdzie bądź) ustawiać zmienne LANG czy LC_ALL, ale jest to kłopotliwe i trafi się w końcu sytuacja, gdy o tym zapomnimy.

Awaryjne LANG=C jest złym domyśłnym locale ze względu na używanie jednobajtowego kodowania znaków. Komu zdarzyło się niechcący założyć bazę Postgresa z wewnętrznym kodowaniem ASCII albo zmasakrować plik HTML przy kosmetycznej edycji, wie, że ograniczenie się do kodowań opartych na UTF-8 jest rozsądniejsze.

Decyzja o języku jest mniej oczywista. Osobiście na serwerach wolę wykorzystywać ustawienia angielskie, a nie polskie. Z dwóch przyczyn:

• polskie tłumaczenia nie zawsze są najlepszej jakości (tłumaczenia poleceń shellowych i manów, graficzne programy i środowiska wyglądają znacznie lepiej), a nawet gdy są przyzwoite, dokumentację czy wyjaśnienie błędu łatwiej wygooglować na podstawie angielskich zapisów,

• od czasu do czasu trafiają się skrypty czy programy oczekujące anglojęzycznego formatu odpowiedzi od jakiegoś ls -l czy date i głupiejące, gdy Friday stanie się piątkiem.

Na Debianie/Ubuntu (i paru innych dystrybucjach) najbardziej eleganckim miejscem na skonfigurowanie domyślnego locale jest /etc/default/locale. Ja wpisuję tam:

LANG="en_US.UTF-8"
LANGUAGE="en_US:en"

Osoba bardzo ceniąca polskie napisy może zastąpić en_US przez pl_PL, a en przez pl.

Ustawienia językowe bywają też czasem wpisywane do /etc/environment (plik ładowany przez kilka shelli). Jeśli /etc/default/locale jest i działa, lepiej pozostawić tam wyłącznie domyślną ścieżkę (PATH).

Podsumowanie

Wyszedł mi dość długi artykuł o trzech drobiazgach, ale zdecydowałem się wyjaśnić ich znaczenie, by nie były traktowane magicznie. W następnej części zajmiemy się ciekawszymi sprawami.

Ciąg dalszy nastąpił.