Instalacja systemu

GhostBSD – pierwsze wrażenie i pierwsza porażka

Ostatnia aktualizacja: 25 sierpnia 2024, 11:30

felieton

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.

GhostBSD

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

 

Click to rate this post!
[Total: 2 Average: 5]

10 komentarzy do “GhostBSD – pierwsze wrażenie i pierwsza porażka

  • 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.

    Odpowiedz
  • 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ę.

    Odpowiedz
    • Nie popełnię gafy i nie zainstaluję nieznanego mi systemu na zwykłej maszynie, jeśli nie działa prawidłowo na wirtualu.

      Odpowiedz
    • 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. 😉

      Odpowiedz
    • Czekaj, czekaj… Jak to się nazywało w naszych kręgach? Aaaa, już wiem: „security fail” 😛

      Odpowiedz
  • 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”;

    Odpowiedz
    • 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…

      Odpowiedz
      • 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.

        Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna jest chroniona przez reCAPTCHA i Google Politykę Prywatności oraz obowiązują Warunki Korzystania z Usługi.

Skip to content