Forum Debian Users Gang

Można używać także (szybszego?) dasha zamiast basha czy zsh. Ja tego nie robię bo po co, wole zsh ;)

Naturalnie że szybszego. Nie posiada zbędnego bloatu, bashizmów, itd itp, porównaj choćby wielkość binarki.

Wykonuje skrypty shellowe po prostu szybciej od basha czy zsh. bash lub zsh mogą pozostać twoją powłoką logowania (wpis w /etc/passwd), ale /bin/sh niech będzie symlinkiem do /bin/dash — to po prostu pod niemal każdym względem lepsze rozwiązanie (i w wielu dystrybucjach domyślne).

Używanie gdm/kdm i innych

TO akurat ma jedną, ogromną zaletę, a nawet dwie, zwłaszcza jeśli uruchamiasz podczas startu kilka niekoniecznie niezbędnych usług (u mnie nfs, lighttpd, mysql, itp). Otóż, wystarczy umieścić ?DM *przed* tamtymi usługami, a otrzymasz ekran logowania ?DM *zanim* system skończy się ładować :) w czasie gdy init startuje jeszcze nfs, httpd, i chujwiecojeszcze, ty możesz już wpisywać swoje hasło. No i masz o jedno "startx" mniej do wpisywania.

Druga zaleta to łatwe i szybkie przełączanie użytkowników i wyłączanie kompa z menu w KDE, Gnome czy Xfce. W przypadku kdm można nawet poprosić o nowe okno logowania poleceniem dcop (aczkolwiek nie pamiętam jak ono szło, chyba coś w stylu "dcop kdm reserve", kto wie do czego dcop służy z pewnością będzie w stanie znaleźć komendę).

==

I jeszcze moje 0.03$:

Podczas użytkowania systemu normalne jest, że co jakiś czas instalujemy, testujemy i wywalamy różne programy. Wiele z nich ma swoje skrypty startowe w "/etc/init.d/". Niestety, dpkg i apt są tak pomyślane, aby nie usuwać tych skryptów :) tym oto sposobem:

$ ls /etc/init.d/ |wc -l
95

Z czego większość to śmieci:

$ file /etc/init.d/samba 
/etc/init.d/samba: POSIX shell script text executable
$ dpkg -s samba | grep install
Status: deinstall ok config-files

Byłem w trakcie pisania skryptu, który użyje "apt-find file" aby dowiedzieć się, które z tych plików należą do jakiej paczki, oraz "dpkg --get-selections" aby sprawdzić, czy paczka jest zainstalowana, a następnie odśmieci ten katalog i usunie martwe symlinki w "/etc/rc?.d/". Niestety wysiadł prąd, a potem straciłem wenę :P jak będzie gotowy, wrzucę.

Po takiej akcji warto przyjrzeć się zawartości "/etc/rc2.d/" (jeśli domyślny runlevel to 2), i tam pozmieniać kolejność symlinków w taki sposób, aby gdm/kdm (ORAZ ich zależności) startowały jak najwcześniej.

==

Kolejna rzecz to fsck. W /etc/fstab znajdują się na końcu każdego wpisu dwa tajemnicze numerki. Ostatni z nich oznacza, w jakiej kolejności będzie wykonywany fsck dla tego wolumenu podczas startu systemu. Prawdopodobnie ustawienie tego na zero dla rzadko używanych partycji (np. u mnie /mnt/szparagi) won't kill kittens (u mnie działa(TM)).

==

Jeśli potrzebujesz systemu REALLYFASTJUSTNOWIMMEDIATELY, a potrzebujesz jedynie np. rzucić okiem na jeden plik lub zapisać krótką notkę, możesz stworzyć sobie wpis w /boot/grub/menu.lst zawierający w linii poleceń kernela "init=/bin/sh" (czy inna powłoka). Około 5 sekund po jego wybraniu będziesz w powłoce roota (bez sieci, podmontowanych dysków, itp). Dajesz "mount -a", "su - $USER", robisz co trzeba, robisz "umount -a" i "poweroff". Ewentualnie będąc w owej "macierzystej" konsoli roota możesz dać "exec /sbin/init" aby uruchomić normalnie resztę systemu.

==

Logowanie przez USB.

Tak, bardzo miła opcja :) praktycznie wszystkie dystrybucje Linuksa (poza Slackware), a nawet chyba FreeBSD, używają PAM. Zasada działania PAM jest prosta — zamiast używać hasła do logowania się do systemu, możesz używać czegoś innego — czytnika smartcardów, linii papilarnych, albo pendrive'a. To ostatnie da się zrealizować następująco:

$ apt-get install libpam-usb

Następnie, edytujemy plik "/etc/pam.d/common-auth", i dopisujemy przed linijką "auth required pam_unix.so nullok_secure", linijkę:

auth    sufficient      pam_usb.so

Następnie, podłączamy pendraka do portu USB, i zapodajemy poleceniem (jako root):

$ pamusb-conf --add-device jakaśdowolnanazwadlaurządzenia

Sprawdzamy czy nazwa producenta, model, itp zgadzają się z tym, co mamy podłączone, i dajemy "yes". Następnie zapodajemy poleceniem:

$ pamusb-conf --add-user twojanazwaużytkownika

Potwierdzamy, że "twojanazwaużytkownika" ma od teraz prawo autentykować się za pomocą urządzenia "jakaśdowolnanazwadlaurządzenia". Wydaje mi się, że potrzebny jest restart niektórych usług (z pewnością gdm/kdm, i/lub wylogowanie się).

Jak to działa w praktyce? Gdy urządzenie jest podłączone:

$ sudo su -
* pam_usb v0.4.2
* Authentication request for user "harry" (sudo)
* Device "USBPenis" is connected (good).
* Performing one time pad verification...
* Regenerating new pads...
* Access granted.
#

A gdy odłączę:

$ sudo su -
* pam_usb v0.4.2
* Authentication request for user "harry" (sudo)
* Device "USBPenis" is not connected.
* Access denied.
[sudo] password for harry:

Jeżeli teraz połączymy to z GDM, i wybierzemy "standardową przeglądarkę użytkowników" w okienku (bez żadnego theme'a), logowanie do systemu odbywa się JEDNYM KLIKNIĘCIEM :)

FAQ:
Q: Czy to jest bezpieczne?
A: Tak.

Q: Dlaczego?
A: libpam-usb używa numeru seryjnego twojego pendraka oraz tz. "one-time pad" do zweryfikowania twojego urządzenia. Do podrobienia pierwszego potrzeba odrobinę specjalistycznego sprzętu, no i aby zdobyć jedno i drugie potrzeba fizycznie zdobyć pendraka i skopiować te dane. Jeśli zauważysz brak pendraka (ja swojego noszę z kluczami, więc raczej zauważę), alarm. Z kolei jeśli ktoś ci go po tej akcji podrzuci z powrotem, skopiowane dane będą bezużyteczne gdy tylko podłączysz pendraka do kompa — komputer wygeneruje nowy one-time pad (dlatego są nazywane one-time, duh), i stary pad złoczyńca może sobie w dupę wsadzić.

Q: Wolę hasło.
A: Spoko, a ja wolę szybkość i wygodę. A jeśli ktoś ma fizyczny dostęp do twojego komputera masz większe problemy.

No i masz o jedno "startx" mniej do wpisywania.

u mnie startx (z opcjami) wpisuje się samo jeśli loguję się na TTY1

Byłem w trakcie pisania skryptu, który użyje "apt-find file" aby dowiedzieć się, które z tych plików należą do jakiej paczki, oraz "dpkg --get-selections" aby sprawdzić, czy paczka jest zainstalowana, a następnie odśmieci ten katalog i usunie martwe symlinki w "/etc/rc?.d/". Niestety wysiadł prąd, a potem straciłem wenę :P jak będzie gotowy, wrzucę.

Pozwolisz, że cię wyręczę?

dpkg -l | grep "^rc" | awk '{print $2}' | xargs dpkg --purge

urug napisał(-a):

A dlaczego nie po prostu:
aptitude purge $( dpkg -l | awk '/^rc/{ print $2 }' ) ?

jeśli pakiet ma status rc, to jest niezainstalowany (jedynie pliki konfiguracyjne pozostały z byłej instalacji) i nie można go usunąć za pomocą APT-a.

ale awka masz lepszego ;)

alez przy pomocy aptitude mozna:

root@pc-rrp:~# dpkg -l | awk '/^rc/{ print $2 }'
exim4-daemon-light
fam
iamerican
ipolish
libgd2-noxpm
libglew1
root@pc-rrp:~# aptitude purge $( dpkg -l | awk '/^rc/{ print $2 }' )
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności
Reading state information... Gotowe
Odczyt dodatkowych informacji o stanie
Inicjalizacja stanów pakietów... Gotowe
Odczyt opisów zadań... Gotowe
Następujące pakiety zostaną USUNIĘTE:
  exim4-daemon-light{p} fam{p} iamerican{p} ipolish{p} libgd2-noxpm{p}
  libglew1{p}
0 pakietów uaktualnianych, 0 instalowanych, 6 do usunięcia i 938 nie uaktualnian
ych.
Do pobrania 0B archiwów. Zajęte po rozpakowaniu: 0B.
Kontynuować? [Y/n/?] Y
Zapisywanie dodatkowych informacji o stanie... Gotowe
(Odczytywanie bazy danych ... 192247 plików i katalogów obecnie zainstalowanych.                                                                           )
Usuwanie exim4-daemon-light ...
Czyszczenie z plików konfiguracyjnych dla exim4-daemon-light ...
Usuwanie fam ...
Czyszczenie z plików konfiguracyjnych dla fam ...
Usuwanie iamerican ...
Czyszczenie z plików konfiguracyjnych dla iamerican ...
Usuwanie ipolish ...
Czyszczenie z plików konfiguracyjnych dla ipolish ...
Usuwanie libgd2-noxpm ...
Czyszczenie z plików konfiguracyjnych dla libgd2-noxpm ...
Usuwanie libglew1 ...
Czyszczenie z plików konfiguracyjnych dla libglew1 ...
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności
Reading state information... Gotowe
Odczyt dodatkowych informacji o stanie
Inicjalizacja stanów pakietów... Gotowe
Zapisywanie dodatkowych informacji o stanie... Gotowe
Odczyt opisów zadań... Gotowe

root@pc-rrp:~# dpkg -l | awk '/^rc/{ print $2 }'
root@pc-rrp:~#

w domu mam jeszcze chyba na jakiejs partycji sarge ... wiec jak wroce to sprawdze, a Ty szykuj nozyczki :-)

smigacz:~# dpkg -l | grep ^rc
rc  iptstate                              2.2.1-1.1                  Top-like state for netfilter/iptables
rc  libnetfilter-conntrack1               0.0.96-1                   Netfilter netlink-conntrack library
rc  libnfnetlink0                         0.0.39-1                   Netfilter netlink library
smigacz:~# apt-get purge $( dpkg -l | awk '/^rc/{ print $2 }' )
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności       
Odczyt informacji o stanie... Gotowe
Pakiet iptstate nie jest zainstalowany, więc nie zostanie usunięty.
Pakiet libnetfilter-conntrack1 nie jest zainstalowany, więc nie zostanie usunięty.
Pakiet libnfnetlink0 nie jest zainstalowany, więc nie zostanie usunięty.
0 aktualizowanych, 0 nowo instalowanych, 0 usuwanych i 4 nieaktualizowanych.
smigacz:~#

Ale tego już rzeczywiście nie potrafi.

fnmirk, chodzi o to że ta pakiety już są usunięte. Pozostały tylko pliki konfiguracyjne (stan rc), więc remove już nic nie da.

fnmirk napisał(-a):

Chodzi o usunięcie pozostałości po odinstalowanych pakietach. Jak ponownie zainstalujesz i równocześnie usuniesz z opcją ,,purge'' to wychodzi na to samo.

tylko po co instalować (a więc często pobierać) potencjalnie duży pakiet?

Mam często tak, że jak odinstalowuje pakiet (aptitude purge), a on wywala zależności  - to te zależności są tylko usuwane, i trzeba zrobić na nich purge. W sumie to nie wiem czy jest jakiś przełącznik do tego, nie szukałem.

Do czego zmierzam - przydaje się jednak czasem możliwość czyszczenia usuniętych pakietów.

Optymalizacja startu systemu fajna sprawa, także w końcu i mnie dopadło :)

Pole do popisu trochę się kurczy - Debian już domyślnie korzysta z dasha, skrypty startowe uruchamiane są w oparciu o zależności (correct me if I'm wrong). Jedyne co właściwie zrobiłem w tym kierunku to doinstalowanie readahead, co faktycznie urwało ze startu systemu dwie sekundy :) Kernel - Liquorix - jeżeli komuś nie chce się kompilować własnego, to lepszego dla Debiana (na desktop) raczej się nie znajdzie. Liquorix jest zbudowany ze źródeł Zen w oparciu o konfigi z Siduxa, czyli ruszy na niemal każdym sprzęcie, ale zawiera kilka dających kopa nowinek (jak planista BFS - The Brain Fuck Scheduler).

Dobrze dobrane skrypty startowe (choćby za pomocą sysv-rc-conf) oczywiście zawsze w cenie :) Do tego zauważyłem na Gentoo (w Debianie nie sprawdzałem), że system podnosi się trochę szybciej na uvesafb niż na vesafb (jeżeli ktoś w ogóle korzysta ze sterownika bufora ramki). Jeszcze co do kernela - pomijając samą optymalizację pod sprzęt - wywalenie fragmentu typu root=/dev/sda10 z linii kernela przyspiesza start systemu (w przypadku kompilacji na danym sprzęcie/konfiguracji partycji, nie jest on konieczny).

No to jeszcze wykresy bootchart (bootchart też spowalnia start systemu):

Bez readahead =>     Z dodanym readahead =>

A czemu nie? U mnie lata szybciej niż siduxowe, sprawdzić zawsze możesz... Wystarczy wpis do sources.list:

deb http://liquorix.net/debian sid main

I instalujesz pakiet z kernelem tak jak każdy inny przez aptitude.

ArnVaker musze powiedziec ze po instalacji tego kernela praca na moim lapku znacznie sie poprawiła. Wiatraki tak nie warcza jak na siduxowym kernelu oraz poprawiła sie akceleracja na sterach otwartych:)

Ostatnio edytowany przez marian6 (2010-01-14 19:12:19)