Debian Live: jak uruchomić własny skrypt przy starcie (rc.local, prawa roota, problem z pytaniem o hasło)

ByTomasz Sanecki

Debian Live: jak uruchomić własny skrypt przy starcie (rc.local, prawa roota, problem z pytaniem o hasło)

Najprościej będzie dopisać go do /etc/rc.local.

Tak, rc.local jest wykonywany na prawach roota. W sysv-rc-conf na przykład. No tak... Jest tam ustawione 2,3,4,5 czyli tak jak powinno być :). Aktualnie jest tak: przy starcie systemu wyświetla (*) się: gdy miałem te dwie pozycje w moim skrypcie: to (*) przy starcie systemu też się pojawiało... No ale działało, czyli wyłączało bluta i sciemniało. Teraz gdy siedzi to w rc.local nie robi tego... No i moje rc wywołuje się na samy końcu... To ma się wywoływać na końcu, czyli jest OK.

Może te polecenia po prostu nie działają? Nie no, to działa! Ogólnie rc.local działa. Właśnie zrobiłem identyczny test wcześniej i okazało się, że to jest ok, ale problem jest taki, że te komendy nie działają... No, ale w tym moim skrypcie jak są to działają. Więc problem jest taki, że nie działają jak są w rc.local.

O_0 ale wstyd... Nie ma to jak świeże oko... Niestety jest problem bo p wisaniu takowego polecenia w konsoli jest pytanie o hasło.

Dlaczego w rc.local może pojawić się pytanie o hasło

/etc/rc.local jest wykonywany na prawach superużytkownika i samo su nie ma prawa pytać o hasło.

Natomiast może być tak, że skrypt który próbujesz uruchomić, pyta o jakieś hasło i Twoje pytanie dotyczy tego, jak z poziomu rc.local to hasło mu wprowadzić.

Może być również tak, że ten skrypt wywołuje gdzieś os.system("sudo costam") (czy jak tam się takie rzeczy zapisuje w Pythonie) i to sudo pyta o hasło. Z konsoli zwykłego użytkownika: Nie mam żadnego pytania o hasło. Nadal w konsoli zwykłego użytkownika: Pytanie o hasło. Gdy z konsoli roota wykonuje polecenie: to pytania o hasło nie ma.

To oznacza, że kluczowy problem nie leży w tym, czy rc.local działa na roocie-bo działa-tylko w tym, co dokładnie uruchamia skrypt i czy wewnątrz pojawia się sudo wymagające interakcji.

Co sprawdzić w Twoim skrypcie (żeby działał w starcie)

Takie podejście jest najbezpieczniejsze: napisz dokładnie jakie polecenia wpisujesz i jaki wynik otrzymujesz.

• Upewnij się, że w /etc/rc.local wywołujesz ten sam scenariusz co w konsoli, a nie „trochę inny” (np. inna ścieżka do pliku, inny user, inny tryb uruchomienia).
• Sprawdź, czy skrypt nie zawiera wywołań typu sudo, które w trybie startowym mogą zachować się inaczej niż przy normalnym uruchomieniu.
• Jeśli pojawia się pytanie o hasło, to pytanie musi pochodzić z miejsca, w którym uruchamiasz program wymagający autoryzacji (np. przez sudo), a nie z samego faktu, że to działa z rc.local.

PS. PS. live-build jest opracowana z wykorzystaniem systemu kontroli wersji Git. W systemach opartych na Debianie, jest on dostarczany przez pakiet git. Uwaga: Nie musisz instalować live-boot lub live-config w systemie do tworzenia niestandardowych systemów żywych. Jednak ten sposób nie zaszkodzi i jest przydatny do celów porównawczych.

Aby używać najnowszych źródeł z repozytorium GIT, użyj poniższego polecenia. Używaj osobistych konstruktorów takich jak pbuilder lub sbuild, jeżeli istnieje potrzeba zbudowania live-boot na dystrybucji docelowej, która różni się od systemu budowania. Na przykład, dla obrazów trixie live, zbuduj live-boot w środowisku chroot trixie.

Przez to, że live-boot i live-config są instalowane przez system live-build, instalacji pakietów w systemie gospodarza nie jest wystarczająca: należy traktować wygenerowane pliki deb jak inne pakiety niestandardowe.. Ponieważ z reguły celem budowania ze źródła jest testowanie nowe rzeczy w krótkim okresie przed oficjalną premierą, poinstruuj się Instalowanie zmodyfikowanych paczek innych firm, aby tymczasowo umieścić odpowiednie pliki w konfiguracji.

W szczególności należy zauważyć, że oba pakiety są podzielone na rodzajowe części, część dokumentacji i jeden lub więcej części dodatkowych. Obejmują część rodzajową, tylko jeden back-end (część dodatkowa) dopasowana do konfiguracji i ewentualnie część dokumentacji.

Praktyczna diagnostyka: jak odróżnić „rc.local nie działa” od „komendy w skrypcie nie działają”

Kluczowe jest rozróżnienie: rc.local jest wykonywany na prawach roota oraz sam skrypt/komenda może wymagać czegoś, co nie jest spełnione w środowisku startowym.

Najpierw upewnij się, że:

• rc.local działa (jeśli widzisz wyświetlanie (*) przy starcie, masz sygnał, że element startowy się odpala).
• To wywołanie jest osadzone w tym samym miejscu logiki uruchamiania co wcześniej (twoje rc wywołuje się na samy końcu-i to jest OK).

Jeżeli wcześniej działało w scenariuszu „w konsoli”, ale nie działa w rc.local, to najczęściej powodem są różnice w:

• środowisku wykonania (parametry, zmienne środowiskowe, kolejność startu usług),
• sposobie autoryzacji (np. sudo wymaga hasła w danym trybie),
• tym, co dokładnie skrypt robi „pod spodem” (np. z konsoli działa, bo masz inny kontekst niż podczas startu).

Wskazówka związana z pytaniem o hasło

Jeżeli „na żywo” podczas wpisania polecenia w konsoli pojawia się pytanie o hasło, to w rc.local problem może być jeszcze bardziej dotkliwy: z poziomu startu nie masz interakcji wpisywania hasła.

/etc/rc.local jest wykonywany na prawach superużytkownika i samo su nie ma prawa pytać o hasło, natomiast pytanie o hasło może wynikać z tego, że skrypt uruchamia element, który prosi o hasło (np. przez sudo).

Prosta checklista do skorygowania wywołania w rc.local

1. Sprawdź, czy w /etc/rc.local wywołujesz ten sam skrypt/te same polecenia co w konsoli, tylko uruchamiane automatycznie.
2. Jeśli pojawia się pytanie o hasło - prześledź, z którego fragmentu uruchomienia ono pochodzi (czy z samej logiki startu, czy ze środka uruchamianych poleceń).
3. Potwierdź, że test „jak root” nie pyta o hasło: „Gdy z konsoli roota wykonuje polecenie… to pytania o hasło nie ma”.
4. Porównaj to z tym, co dzieje się podczas normalnego uruchomienia poleceń z poziomu zwykłego użytkownika (tam „Pytanie o hasło”).

Gdy problem jest z interakcją (hasło), dopóki nie usuniesz przyczyny (np. wewnętrznego użycia sudo wymagającego hasła), komendy będą zachowywać się inaczej niż w trybie „ręcznym”.

Jak pogodzić „kolejność na końcu” z działaniem komend

To ma się wywoływać na końcu, czyli jest OK.

U Ciebie komendy w rc.local nie robią tego samego co wcześniej, mimo że „ogólnie rc.local działa”. To sugeruje, że nie chodzi o kolejność wywołania (bo końcówka jest OK), tylko o fakt, że te konkretne komendy w tym kontekście nie działają tak jak w skrypcie uruchamianym ręcznie.

Teraz gdy siedzi to w rc.local nie robi tego... No i moje rc wywołuje się na samy końcu... To ma się wywoływać na końcu, czyli jest OK.

Może te polecenia po prostu nie działają? Nie no, to działa! Ogólnie rc.local działa. Właśnie zrobiłem identyczny test wcześniej i okazało się, że to jest ok, ale problem jest taki, że te komendy nie działają... No, ale w tym moim skrypcie jak są to działają.

Więc problem jest taki, że nie działają jak są w rc.local...

Co z budowaniem środowiska Debian Live (live-build) ma wspólnego z uruchamianiem skryptów

PS. live-build jest opracowana z wykorzystaniem systemu kontroli wersji Git. W systemach opartych na Debianie, jest on dostarczany przez pakiet git.

Uwaga: Nie musisz instalować live-boot lub live-config w systemie do tworzenia niestandardowych systemów żywych. Jednak ten sposób nie zaszkodzi i jest przydatny do celów porównawczych.

Używaj osobistych konstruktorów takich jak pbuilder lub sbuild, jeżeli istnieje potrzeba zbudowania live-boot na dystrybucji docelowej, która różni się od systemu budowania.

Przez to, że live-boot i live-config są instalowane przez system live-build, instalacji pakietów w systemie gospodarza nie jest wystarczająca: należy traktować wygenerowane pliki deb jak inne pakiety niestandardowe.

Poinstruuj się Instalowanie zmodyfikowanych paczek innych firm, aby tymczasowo umieścić odpowiednie pliki w konfiguracji.

W szczególności należy zauważyć, że oba pakiety są podzielone na rodzajowe części, część dokumentacji i jeden lub więcej części dodatkowych.

Dlaczego warto o tym pamiętać przy automatyzacji startu

Jeżeli modyfikujesz zachowanie systemu startowego w obrazach live (np. logikę uruchamiania skryptów), to ważne jest, aby uwzględnić, w jaki sposób budowane są składniki live i jak trafią do gotowego środowiska. Skoro live-boot i live-config są instalowane przez live-build, to w praktyce liczy się to, co finalnie trafia do obrazu-w tym sposób umieszczenia plików i konfiguracji.