OmniOS - Pierwszy start
Jeżeli instalacja przebiegła pomyślnie i nasz sprzęt nie powoduje problemów niepozwalających na uruchomienie systemu, to po zakończeniu instalacji i restarcie maszyny znajdujemy się właśnie w tym miejscu. Naszym oczom ukaże się czarna konsola systemu z wesoło migającym kursorem zachęty do pierwszego logowania:
SunOS Release 5.11 Version omnios-b281e50 64-bit
Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved.
Loading smf(5) service descriptions: 137/137
Hostname: test-builder
Configuring devices.
Loading smf(5) service descriptions: 1/1
test-builder console login: _
W świeżo zainstalowanym systemie nie mamy jeszcze utworzonych użytkowników, logujemy się przy pomocy konta root bez z pustym hasłem.
Pierwszą czynnością jest zabezpieczenie konta administratora nowym hasłem:
root@test-builder:~# passwd
passwd: Changing password for root
New Password: _
Re-enter new Password: _
passwd: password successfully changed for root
root@test-builder:~# _
Będziemy potrzebować konto użytkownika pozwalające na zdalne logowanie. Zaczynamy od utworzenia nowej grupy:
root@test-builder:~# groupadd -g 501 admin
root@test-builder:~# _
Tworzymy nowego użytkownika dodając go do powyższej grupy oraz zdefiniujemy dla niego nowe hasło. Domyślnym katalogiem domowym w systemach wywodzących się z OpenSolaris jest /export/home/$username$ i zachowamy tą konwencję.
root@test-builder:~# useradd -g admin -s /bin/tcsh -c 'Administrator' \
-m -b /export/home admin
64 blocks
root@test-builder:~# passwd admin
New Password: _
Re-enter new Password: _
passwd: password successfully changed for admin
root@test-builder:~# _
Możemy teraz zezwolić użytkownikom z grupy admin na użycie polecenia sudo bez konieczności wprowadzania hasła:
root@test-builder:~# echo "%admin ALL=(ALL) NOPASSWD: ALL" \
> /etc/sudoers.d/admin
root@test-builder:~# logout
> sudo su -
OmniOS 5.11 006 June 2014
root@test-builder:~# _
By ułatwić sobie pracę nad dalszą konfiguracją systemu, będziemy potrzebować zdalnego dostępu do serwera. W tym celu należy oczywiście skonfigurować interfejsy sieciowe oraz demona sshd. Rozpoczynamy od identyfikacji sprzętowych interfejsów sieciowym maszyny:
root@test-builder:~# dladm show-phys
LINK MEDIA STATE SPEED DUPLEX DEVICE
rge0 Ethernet unknown 0 unknown rge0
root@test-builder:~# _
Tworzymy adresację interfejsu, do wyboru mamy dwie metody: dhcp lub statyczną, poniżej prezentuję obie:
root@test-builder:~# ipadm create-if rge0
root@test-builder:~# ipadm create-addr -T dhcp rge0/v4
root@test-builder:~# ipadm show-addr
ADDROBJ TYPE STATE ADDR
lo0/v4 static ok 127.0.0.1/8
rge0/v4 dhcp ok 192.168.88.244/24
lo0/v6 static ok ::1/128
root@test-builder:~# _
root@test-builder:~# ipadm create-if rge0
root@test-builder:~# ipadm create-addr -T static -a 192.168.88.10/24 rge0/v4static
root@test-builder:~# ipadm show-addr
ADDROBJ TYPE STATE ADDR
lo0/v4 static ok 127.0.0.1/8
rge0/v4static static ok 192.168.88.10/24
lo0/v6 static ok ::1/128
root@test-builder:~# _
Jeżeli skorzystaliśmy ze statycznej metody, to konieczne będzie również zaktualizowanie tablicy routingu:
root@test-builder:~# route -p add default 192.168.88.1
add net default: gateway 192.168.88.1
add persistent net default: gateway 192.168.88.1
root@test-builder:~# _
Pozostaje konfiguracja resolvera:
root@test-builder:~# echo "nameserver 192.168.88.1" >> /etc/resolv.conf
root@test-builder:~# cp /etc/nsswitch.conf{,.bak}
root@test-builder:~# cp /etc/nsswitch.{dns,conf}
root@test-builder:~# _
W tym momencie dysponujemy już skonfigurowanym połączeniem sieciowym i resztę czynności możemy wykonywać już zdalnie.
root@test-builder:~# host wp.pl
wp.pl has address 212.77.100.101
wp.pl mail is handled by 5 mx5.wp.pl.
wp.pl mail is handled by 0 mx.wp.pl.
root@test-builder:~# ping wp.pl
wp.pl is alive
root@test-builder:~# _