graterlia-scripts 0.1.66

[Gość Setu]

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 ?

[mickey]

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.

[tux]

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

[sunfizz]

Czyli np. system.conf pozostaje bez zmian a w pliku system.conf-opkg, są poprawki dla konfiguracji wdrożone przez dev i którymi możemy nadpisać dotychczasowe parametry konfiguracyjne ? czy odwrotnie :)

[tux]

system.conf-opkg →nowy

system.conf → ten co macie na boxie

[sunfizz]

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.

[mickey]

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

[sunfizz]

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.

[tux]

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.

 

[sunfizz]

Jak zawsze masz rację.

[Gość j00zek]

  W dniu 18.06.2014 o 13:09, tux napisał(a):

...

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ń. ;)

[mickey]

  W dniu 18.06.2014 o 15:01, j00zek napisał(a):

(...) a dla tych co wolą gotowca, koncepcja IMAGE. (...)

 

Dla tych pewnie jest to, pojawiająca się co jakiś czas info info na stronie z historią aktualizacji:

 

aktualizacja obrazów Graterlia OS w dziale Pobierz do wersji release 2014-06-16;

 

oraz praca richtera: http://forum.xunil.pl/index.php/topic,1444.0.html :)

[Gość 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.

[tux]

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 :)

[Gość j00zek]

Albo czwarta droga, o ile nie ma bo nie wiem, instalacja paczek z gui z informacją co za cuda to są?

[tux]

Czwarta opcja docelowo będzie :)

Najpierw muszę wyprowadzić system na prostą.

[Gość Setu]

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.

 

[Romulus]

Czyki plik system.conf-opkg stanowi wzorzec na podstawie ktòrego dostosowujemy potrzebną nam funkcjonalność przepisując odpowiednie parametry do pliku system.conf?

 

Napisano przy użyciu Tapatalka.

 

 

[tux]

Można tak napisać.

Brak pliku == ustawienia standardowe umożliwiające start systemu.

[pajretX]

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!

[tux]

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.