Rozważmy taki serwer bez headless: Typowe urządzenie x86 w zdalnej lokalizacji, które można zdalnie zainicjować za pomocą – powiedzmy – obrazu Ubuntu. Po zainicjowaniu możesz zalogować się tylko przez ssh – lub zdalnie go zresetować, tj. Nie możesz uzyskać dostępu do BIOS-u lub monitu menedżera rozruchu (na przykład Grub 1).

Być może dostępny jest jakiś rodzaj KVM, ale użycie KVM jest bardzo drogie i musisz rezerwować go co godzinę.

Biorąc pod uwagę ten scenariusz, można nabrać paranoi na temat problemów z rozruchem. Na przykład:

  1. Co się stanie, jeśli aktualizacja jądra się nie powiedzie?
  2. A co z monitem fsck we wczesnym procesie rozruchu? Prawdopodobnie ssh nie jest jeszcze dostępny …

Czy są inne pułapki, na które należy uważać?

W przypadku aktualizacji jądra konfiguruję grub (starszą wersję) tak, aby menu.lst preambuła zawierała 

default saved fallback 2 # counts from 0

, a pierwszy wpis kończy się na: 

savedefault fallback

Pierwszy wpis GRUB to zaktualizowane jądro, a trzeci to znany działający. Zobacz także sekcję podręcznika grub na temat awaryjnego rozruchu .

Zmieniłem skrypt startowy /etc/rc.local (w systemie podobnym do Debiana) z informacją, że w przypadku pomyślnego rozruchu ustawienie pozycji domyślnej jest resetowane: 

grub-set-default 0

Ta konfiguracja grubego działa, ale np w Ubuntu nie jest to ustawienie domyślne i po każdej aktualizacji jądra trzeba ręcznie dostosować menu.lst.

Podaję 

panic=60

jako parametr jądra taki, że np w przypadku nieprawidłowego parametru root= lub zepsutego jądra, system automatycznie uruchomi się ponownie w przypadku błędu.

O problemie z fsck Nie jestem pewien, co jest najlepsze sposób jest. W systemach podobnych do Debiana możesz ustawić 

FSCKFIX=yes

w /etc/default/rcS, co domyślnie informuje fsck o automatycznej naprawie .

Ale jeśli automatyczna naprawa się nie powiedzie, być może nadal otrzymuję komunikat, że nie mogę uzyskać dostępu zdalnego?

Alternatywnie mogę po prostu wyłączyć sprawdzanie fsck przez zero w szóstym kolumna /etc/fstab – w przypadku błędu fs po prostu ponownie zainicjuje system i przywróci kopie zapasowe – unikając w ten sposób wszystkich problemów z fsck?

Komentarze

  • Bardzo dobre pytanie. Serwer fizyczny bez zdalnej konsoli lub jeden drogi to duży problem.

Odpowiedź

Poważnie, jeśli Twój dostawca nie oferuje bezpłatnej (lub przynajmniej taniej) pomocy ręcznej w skrajnych przypadkach, czas się zmienić. W przeciwnym razie myślę, że wszystko jest w porządku ze swoją konfiguracją.

Kiedy twój system jest tak zepsuty, że fsck nie może go naprawić, nie pozostaje nic więcej do zrobienia poza całkowitą reinstalacją. Właściwie nie widziałem, żeby to się stało, chyba że wystąpiła krytyczna awaria sprzętu.

Jedna rzecz do zapamiętania. W przypadku takiej maszyny wybierz stabilną dystrybucję (Debian, RHEL, SLES) i zdecydowanie aktualizuj tylko po odpowiednio długim okresie (nowa wersja stabilizowana przez co najmniej 6 miesięcy).

Odpowiedź

Powinieneś szukać hostingu dostawca, który zapewni dostęp serial-over-ssh i skonfiguruje instalację Linuksa tak, aby używała (odpowiedniego) portu szeregowego jako konsoli (jak to zrobisz zależy od czy system używa inicjalizacji typu upstart czy sysV). Zwróć uwagę, że dostępny jest BIOS , który komunikuje się z portem szeregowym, a nie z wbudowanym urządzeniem ekranowym. Ale zwykle są dostępne tylko na drogim sprzęcie.

Musisz także powiedzieć grub , aby używał portu szeregowego, jeśli chcesz sterować nim przez DTE .

Odpowiedź

Coś, na co warto zwrócić uwagę, to stworzenie niestandardowego initrd, który będzie zawierał dropbear (oczywiście działający na innym porcie), wystarczającą logikę, aby uruchomić sieć i być może sposób na załadowanie niektórych narzędzi do odzyskiwania, jeśli będzie to wymagane. Na tej podstawie możesz stworzyć konfigurację jądra przywracania, która załaduje się z możliwościami sieciowymi i pozwoli ci na ssh, umożliwiając powrót do systemu i próbę odzyskania.

Komentarze

  • Tak, brzmi jak niezły projekt. Mógłbym nawet wyobrazić sobie mały system Linux, który jest zawsze uruchamiany jako pierwszy i działa jak menedżer rozruchu (zapewniając jednocześnie ssh -access i screen ) – mógłby wtedy uruchomić prawdziwe jądro za pomocą technik takich jak en.wikipedia.org/wiki/Kexec . Albo można zajrzeć do serwerów, które mają coreboot.org zamiast jakiegoś kiepskiego BIOS-u z lat 80-tych. Ale z pewnością to wszystko jest niczym, co można niezawodnie skonfigurować i utrzymać w ciągu kilku godzin – w tym momencie ze stabilną dystrybucją.
  • Wygląda na to, że ' będziesz w stanie zaoszczędzić trochę wysiłku, patrząc na tę stronę

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *