GhostBSD – pierwsze wrażenie i pierwsza porażka
Ostatnia aktualizacja: 25 sierpnia 2024, 11:30
GhostBSD jest drugim systemem z rodziny BSD (pierwszym był PC-BSD), który postanowiłem zainstalować w wirtualnej maszynie i przetestować.
Instalacja GhostBSD przebiegła bez problemu, przyznam szczerze, że było bardzo prosta i intuicyjna, nikt nie powinien mieć z nią problemu.
Kolejnym etapem jest przetestowanie systemu używając podstawowych programów preinstalowanych w systemie. Drugim zadaniem jest wykonanie operacji przy użyciu menadżera pakietów: aktualizacja systemu, instalacja i usuwanie pakietów.
Tyle, jeśli chodzi o założenia.
Uruchomienie systemu zainstalowanego na dysku odbyło się bez problemów.
Pulpit MATE bez wodotrysków, lecz wyposażony w podstawowe aplikacje.
Użycie pamięci RAM w systemie 64 bitowym na poziomie 170 MB, co uważam za bardzo dobry wynik.
Teraz czas na pierwszy i najważniejszy test: menadżer pakietów. GhostBSD nie posiada preinstalowanego menadżera pakietów, który działa w trybie graficznym, lecz dostępny jest konsolowy 'pkg’.
I tu zaczęły się schody…
System nie przyjmuje hasła admina (root).
System nie przyjmuje poleceń z użyciem 'sudo’ (hasło użytkownika jest poprawne), lecz mój user nie należy do grupy 'sudo’ (tylko: wheel i operator), pomimo preinstalowanego w systemie pakietu sudo.
OK, instalację GhostBSD wykonałem ponad miesiąc temu, hasła root nie zapisałem, pewnie po prostu zapomniałem i wpisuję niewłaściwe.
W takim wypadku wykonałem świeżą instalację wersji 4.0, hasła zapisałem w notatniku i…
Ciągle to samo – użytkownik skonfigurowany prawidłowo, a admin znowu nie.
Straciłem już dużo czasu i nerwy trochę mnie ponoszą, więc grzecznie zadaję pytanie : What the f%$#! is going on?
Walnąłem kawę, bo ciśnienie na dworze właśnie spadło (mnie chyba też) i zassałem testową wersję GhostBSD 10.1 beta1.
Jeśli wieczorem znajdę chwilę czasu to zrobię kolejną, tym razem instalację testowego obrazu i będę kontynuował to co zacząłem.
Czytaj dalej-> GhostBSD – drugie podejście
Zainstalowałem wersję 10.0 beta1. Poza drobnymi błędami, su działa prawidłowo, więc będę mógł dokończyć wpis. Możliwa jest również inna przyczyna. Zamiast błędnej konfiguracji konta root-a – niewłaściwa konfiguracja układu klawiatury.
Może testuj na zwykłej maszynie zamiast pod VM, bo co prawda nie powinno mieć to związku z hasłami, ale za chwile trafisz na koleją porażkę – w guest GhostBSD 9.x+ nie da się zainstalować vmtools i w zasadzie tak kończy się przygoda GhostBSD pod vmware. Koledzy z developmentu gbsd problem znają i olewaja, wiec to jest system raczej tylko na żywa blachę.
Nie popełnię gafy i nie zainstaluję nieznanego mi systemu na zwykłej maszynie, jeśli nie działa prawidłowo na wirtualu.
Nie samym VMware człowiek żyje. My większość testów robimy na VirtualBox, a z dostępnością guest-additions pod FreeBSD (bo wszak Ghost korzysta z ich portów) nie ma problemu. 😉
CTRL+ALT+F1 i logujesz się na roota bez żadnego hasła 😉
Czekaj, czekaj… Jak to się nazywało w naszych kręgach? Aaaa, już wiem: „security fail” 😛
Pavroo: żeby sudo działało użytkownik nie musi należeć do grupy „sudo”, żeby z niego korzystać, przeważnie wystarczy, że należy do grupy „wheel” (czyli grupy administracyjnej). Niektóre dystrybucje nie pozwalają na bezpośrednie logowanie na konto „root”. Możliwe, że tak jest i tutaj. Próbowałeś użyć starej, dobrej komendy „su”?
Generalnie uproszczony model logowania (hasło „root” takie samo, jak pierwszego użytkownika) to zbrodnia, która wypłynęła z Ubuntu i de facto zwindowsawia (pierwsze konto użytkownika Windows jest też kontem administracyjnym!!) model administracji użytkowników w systemach unixowych. Dodatkiem do tej „zbrodni” jest „sudo”, które jest bardzo wygodne, jednak stwarza zagrożenia bezpieczeństwa (pierwsze o czym myśli użytkownik: elewacja uprawnień do „root” bez wpisywania hasła).
Standardowy model zakłada:
– różne hasła dla „root” i zwykłego użytkownika.
– użytkownicy, którzy mają potrzebę podnoszenia uprawnień powinni należeć do grupy „wheel” i używać w tym celu polecenia „su” („sudo” to luksus, a nie konieczność);
– niektóre systemy/dystrybucje wyłączają możliwość bezpośredniego logowania na użytkownika „root”;
Podczas instalacji ustawione były dwa oddzielne hasła dla root i usera. User należy do grupy wheel lecz nie można uruchomić aplikacji z sudo. su nie reaguje na hasło roota, wszystko jest na zrzucie. Na fejsie zasugerowano abym odzyskał hasło root – instalacja systemu i jego używanie jest koniecznością aby maszyna działała. Jednak szeroka dostępność umożliwia nam wybór co ułatwia decyzję – to system jest dla mnie, a nie ja dla systemu. Skoro coś nie działa, większość ludzi weźmie kolejny, podobny, itd. Jeśli w Sparku byłby podobny problem, to sam rozumiesz…
No to faktycznie wtopa. Nie spojrzałem na screena, a że nie napisałeś nic o „su”, to stwierdziłem, że napiszę. Generalnie cały artykuł wraz z Twoim komentarzem wskazują na poprawną, dobrze skonfigurowaną instalację, więc teoretycznie nie powinno być problemów z zalogowaniem się. W praktyce to pewnie jakiś szczegół, ale użytkownik chce mieć działający system, a nie bawić się w poprawianie konfiguracji zaraz po instalacji.
A takie miałem plany względem GhostBSD… 🙁