Jump to content

graterlia-scripts 0.1.66


Guest Setu

Recommended Posts

Witam!

Dziś rano wklepałem odruchowo opkg update i upgrade (robiłem to również przed wczoraj) w moje ADB5800

i wyskoczyło mi coś niepokojącego :

 

GraterliaOS:~# opkg upgrade

Upgrading graterlia-scripts from 0.1.62 to 0.1.66 on root.

Downloading http://graterlia.xunil.pl/repodata/release/sh4/graterlia-scripts_0.1.66_sh4.ipk.

Configuring graterlia-scripts.

Collected errors:

* resolve_conffiles: Existing conffile /etc/sysconfig/system.conf is different from the conffile in the new package. The new conffile will be placed at /etc/sysconfig/system.conf-opkg.

 

No i rzeczywiście znacząco się te pliki różnią.

Podmienić je ręcznie ? Czy coś jest nie tak ?

Link to comment
Share on other sites

To nowa funkcjonalność w opkg w GOS (pierwsze testy niecały miesiąc temu były).

 

W GOS, jak w każdym systemie masz pliki konfiguracyjne, które zmieniasz zależnie od własnych potrzeb. Z drugiej strony masz osoby, które systemem zarządzają i wprowadzają konieczne zmiany. Na ekranie dostałeś informacje, że pewne zmiany zostały wprowadzone i teraz powinieneś we własnym zakresie sprawdzić co zostało zmienione i skorygować wpisy w pliku konfiguracyjnym, który został zmieniony. Skorygować znaczy "sprawdzić co się zmieniło i pomyśleć, czy wprowadzić to u siebie". Jeżeli nigdy nie zmieniałeś fragmentu, który został zmieniony przez developerów (jak to będzie po polsku?), to możesz wprowdzić zmianę u siebie.

Link to comment
Share on other sites

@mickey → bardzo dobrze to opisałeś.

Ja dodam, że sukcesywnie poprawię paczki, w których są pliki konfiguracyjne. Dzięki temu np. OSCam będzie mógł mieć konfigurację w paczce czy też inne oprogramowanie. Nic się nie nadpisze.

Dodatkowo dzisiaj dam aktualizację, w której system sprawdzi czy w ogóle jest plik. Jak jest to załaduje ustawienia z niego, a jak go nie będzie to załaduje ustawienia predefiniowane:

#deklaracje zmiennych
MODDIR=/lib/modules #ścieżka do katalogu z modułami jądra
if [ -e /etc/sysconfig/system.conf ]; then #załadowanie zmiennych z pliku system.conf
        . /etc/sysconfig/system.conf
else
        fscheck=on
        tmptmp=off
        varrun=64k
        varlog=32k
        sshd=on
        dts=off
        sci=nbox
        led=off
        vfd=off
fi

 

Plik system.conf dużo się zmienił w sensie usunięcia wielu ustawień. Sukcesywnie przechodzą na model Systemu Operacyjnego dużo ustawień realizowanych jest inaczej a od strony użytkownika wystarczy instalacja paczki przez system opkg.

Link to comment
Share on other sites

A nie lepiej byłoby odwrotnie. Zwykły user nie rozumiejąc poszczególnych parametrów konfigu nie wie przy czym zostać ( stary|nowy) a patrząc w dal zrobi się bałagan bo jeśli zaistnieje problem będziemy drążyć wątek zgadując na której konfiguracji user "jedzie".  Jest gałąź test i dajmy jej się rozwijać. Jeśli konfiguracja okaże się istotna dla funkcjonalności systemu niech widnieje w release już bez wyboru (stary|nowy) a w repo test proponowałbym nadpisanie konfiguracji po wcześniejszym wykonaniu kopii pliku np. z opcją backup.

Link to comment
Share on other sites

Nie, nie lepiej odwrotnie, bo już np. po dwóch zmianach nie masz oryginalnego pliku ... a sam coś tam zmieniałeś, co ma istotne znaczenie dla Ciebie. Robiłeś to tak dawno, że zapomniałeś co, ale jak nagle jakaś funkcja przestanie działać, to sobie przypomnisz... [miałem tak ostatnio z cronem].

 

A tak masz plik z końcówką "-opkg" i świadomość, że taki się pojawił, bo był komunikat na ekranie. Porównasz sobie diff-em, jeżeli coś kiedyś zmieniałeś w oryginalnym pliki i uzupełnisz. Jak nie zmieniałeś, to pewnie jesteś tego świadomy i możesz podmienić na nowy "bezmyślnie" (nie polecam tej metody).

Link to comment
Share on other sites

No tak tylko że jeśli już zmienię któryś parametr w oryginalnym konfigu na ten z "-opkg"  to i tak "pies pogrzebany" bo żaden update nie pomoże mi doszukać się co zmieniłem w oryginale bo plik "*.conf-opkg"  będzie niósł z sobą kolejne zmiany w stosunku do tego w którym zmieniałem, czyli reasumując całość na jedno wyjdzie.

Link to comment
Share on other sites

Trochę mylisz się. Zasada jest taka - chyba od zawsze.

Instaluje się system i są jakieś pliki konfiguracyjne. Traktuje się je jako przykładowe ale z nimi system wystartuje. Potem dopieszczasz sobie system, zmieniasz parametry itd. My tego nie wiemy - co użytkownik może być inaczej. Dlatego jak stwierdzamy, że jakiś parametr jest konieczny do zmiany to modyfikujemy plik. Jeżeli jakiś parametr będzie KONIECZNY do dodania będzie stosowny komunikat podczas aktualizacji/instalacji.

Podobnie będzie z innymi paczkami np. OSCam, ntpd, vsftpd, openvp, inne. W każdej paczce określimy jakie pliki to pliki konfiguracyjne i w razie zmian będzie osobny plik.

 

Mamy też wyjście inne. Możemy wrócić do modelu IMAGE. Wtedy dylematu nie będzie. Co aktualizacja każdy chcący mieć najnowszy system wgra wszystko od nowa i skonfiguruje raz jeszcze. Jednak uważam, że na obecnym etapie przyzwyczajenia się użytkowników Graterlia do aktualizacji z opkg jest to wyjście nie do przyjęcia.

 

Link to comment
Share on other sites

Guest j00zek

...

Mamy też wyjście inne. Możemy wrócić do modelu IMAGE. Wtedy dylematu nie będzie. Co aktualizacja każdy chcący mieć najnowszy system wgra wszystko od nowa i skonfiguruje raz jeszcze. Jednak uważam, że na obecnym etapie przyzwyczajenia się użytkowników Graterlia do aktualizacji z opkg jest to wyjście nie do przyjęcia.

 

A może trzecia droga? Dla tych co lubią koncpecję OS tak jak jest, a dla tych cowolą gotowca, koncepcja IMAGE. A ta wcale nie oznacza konfigurowanie wszystkiego po ugrade. Od tego jest kopia ustawień. ;)

Link to comment
Share on other sites

Guest j00zek

A jesteś pewny, że oba nie zawierają po prostu snapshotu graterii z danej chwili?

Koncepcja IMAGE oznacza, mamy wszystko po instalacji i nie musimy się przejmować jakimś opkg.

Link to comment
Share on other sites

Zastanawiałem się nad tym. Kiedyś zainstalowałem to co jest w OPKG ze skórek i pluginów. Zabrakło 128MB. Jak założę, że osoba A czy B potrzebuje tego czy tamtego to nagle wejdą osoby C i D...

Dlatego co do skórek i pluginów to te najczęściej używane są po prostu do instalacji z pilota (PPanel).

Ja osobiście nie jestem w stanie określić co komu może być potrzebne.

 

 

Można by co najwyżej rozważyć kombajn all-in-one. Ale też pytanie ile osób będzie chciało to monstrum zassać i odpalić z PENa :)

Link to comment
Share on other sites

Dziękuje za szybką odpowiedź.

Jak dla mnie wszystko jasne. Poradziłem sobie bez problemu bo w systemie nie zmieniałem wiele. Podmieniłem pliki i śmiga.

 

Link to comment
Share on other sites

  • 1 month later...

Witam,

Dzisiaj po restarcie (a dawno nie restartowałem) za nic nie mogłem zmusić do działania swojego VFD wciśniętego do BSKA.

Przejrzałem pliki i znalazłem wpis w /etc/sysconfig/gfunctions, który parsuje /etc/sysctl.conf zamiast /etc/sysconfig/system.conf

 

 

Po zamianie na /etc/sysconfig/system.conf wszystko działa idealnie.

 

 

Nie wiem czy planujecie przejście ze zmiennymi do sysctl.conf czy to po prostu mała pomyłka ;)

 

 

Pozdrawiam!

Link to comment
Share on other sites

Nie czytałeś na stronie :)

 

Tłumaczę bo pewnie będą pytania. Mamy teraz plik sysctl.conf (standardowy dla Linux) + sysctl.gos (nasz). Ten drugi będzie konfigurowany z Menu w Systemie. Pierwsza odsłona niedługo. Póki co dopisz sobie zmienną do sysctl.gos.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...