Forum Debian Users Gang

Nie pamiętam w tej chwili dokładnego wyjaśnienia, ale przy podaniu none zamiast wskazania folderu /proc, pomimo że działa, chyba nie daje dostępu do niektórych pllików w /proc.
Jest to nawet porządane, kiedy pakuje się jakiś problematyczny program do chroota, żeby zwiększyć bezpieczeństwo systemu (np na serwerach) - główne zastosowanie chrootów we wszystkich Linuxach.

Natomiast montując

mount -t proc /proc /folder/proc

masz zamontowany i widoczny cały folder /proc, w /chroot/proc.

mount | grep proc | grep Deb
/proc on /Debian/proc type proc (rw)

Poza tym może w nowszych kernelach dodali jakieś zabezpieczenia podobne do Grsecurity (w przeszłości często do vaniliowego kernela brali conieco z Grsec/Paxa).
A w Grsec /proc jest pod specjalnym nadzorem. :D

np:

lsmod
Opening /proc/modules: Permission denied

Jeszcze a propos proc:

A w chroocie w /proc potrzebujesz dupę, czy /proc systemu gospodarza?
:D
W każdym razie w pełni kompatybilne względem siebie  te sposoby nie są.
Sznurek: http://forums.gentoo.org/viewtopic-p-6715139.html#6715139

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2011-12-27 15:01:01)

Jacekalex napisał(-a):

A w chroocie w /proc potrzebujesz dupę, czy /proc systemu gospodarza?

On tam montuje proc — nadając etykietę „dupa”. Tak jak wcześniej pisałeś też montuje proc — nadając etykietę „/proc”. Drugie pole to etykieta, jak dajesz tam „none”, to nie ma etykiety. Jaka etykieta? „none” — żadna. Logiczne, prawda? :)

Jacekalex napisał(-a):

W każdym razie w pełni kompatybilne względem siebie  te sposoby nie są.
Sznurek: http://forums.gentoo.org/viewtopic-p-6715139.html#6715139

W tym przykładzie po prostu komunikat błędu posługuje się nadaną etykietą lub jej brakiem.

dominbik napisał(-a):

jak mogę spóbować inny kernel?

aptitude install nazwa_pakietu_z_kernelem

Używanie sterowników i instalacja/usuwanie testdiska wydaje mi się bez związku, chyba że coś dziwnego tym testdiskiem robiłeś. ;)

A ten prelink czasem nie miesza? Możesz spróbować udeva ze stable — on nie używa /run, zatem może zadziała.

Teoretycznie:

aptitude reinstall ~i

(ale jak kiedyś próbowałem, to APT się zapętlał i trzeba było kilka pakietów pominąć, trzy czy cztery chyba)

PS Widzę, że na innym forum założyłeś wątek „Jak naprawić Debiana po aktualizacji?”. To w końcu stało się tak „po aktualizacji” czy „samo”?

udało mi się przełączyć na konsolę przez alt+sysrq+r i ctrl*alt*f1 na tym zaciętym kompie; podnieść net [dhclient eth0] i z drugiego kopmutera zalogowałem się po XDMCP (miałem włączone dla zdalnych terminali)

mam pytanie gdzie w logach znaleźć jakie komendy wpisywałem? (po pobieżnej analizie w xtermie [szczałka do góry i jedziemy]) wychodzi, że najbardziej inwazyjne z roota było prelink -amR ale chciałbym mieć pewność opierając się na /var/log/*

Ostatnio edytowany przez dominbik (2011-12-27 20:38:32)

tak. nie wiem dlaczego w .bash_history nie mogłem znaleźć; dopiero polecenie history dało mi wyniki, których szukałem. Mam ostatnie komendy, które wpisywałem z roota przed restartem (podam tylko te o jakimś znaczeniu).

 
  170  aptitude purge --purge testdisk                                 //razem z testdiskiem został usunięty pakiet o nazwie libntfs10
  171  shutdown -r now                                                            //OSTATNI UDANY RESTART ;(
  172  aptitude why libtrash
  173  aptitude -s remove libtrash
  175  nano /etc/ld.so.preload                                                       //OSTATNIE POLECENIE
  177  shutdown -r now                                                               //OSTATNI RESTART (już nieudany)
  178  aptitude -s remove udev                                              //wklepywane już przez chroota

poleceń wykonywanych między tymi restartami (zawsze restartuje przez konsolę) z poziomu użytkownika było bardzo mało a i tak z tego co wiem Linuxa nie da się rozwalić z poziomu użytkownika.
teraz sobie przypomniałem, że po restarcie chciałem przez livecd Arch Linuxa usunąć ten plik /etc/ld.so.preload (utworzyłem ten plik by ładować /usr/lib/libtrash/libtrash.so.2.4 //prawodpodobnei i tak nie działało) a już tego pliku tam nie było.
Przygotowuję się na to, że będę musiał zainstalować od początku system mając nadzieję że pójdzie to szybciej (mam trochę plików konfiguracyjnych), ale ma ktoś może pomysł co to mogło być? Obok prelink używam również preload.

wcześniejsze polecenia (przed linią 170)  ->   http://wklej.org/id/655762/

Ostatnio edytowany przez dominbik (2011-12-28 17:01:11)

BTW, zestaw prelink + preload faktycznie taki dobry jest (no nie licząc takich efektów jak tutaj oczywiście ;))? /me używa tylko e4rat i działa IMHO bardzo fajnie — ładnie przyśpiesza zarówno start systemu, jak i aplikacji. Porównywałeś może prelink/preload z e4rat?

dominbik napisał(-a):

rezygnuję z pre* i innych tego typu rozwiązań.

Oj tam, np. e4rat jest nieinwazyjny i konfiguruje się moment. Jeśli masz ext4, mógłbyś spróbować. :)

W repo nie ma, ale na stronie projektu są pakiety deb dla Debiana (amd64 oraz i386).

http://sourceforge.net/projects/e4rat/files/

dominbik napisał(-a):

tylko e4rat nie ma chyba w repo.

Nie ma. RFP wysyłałem w sierpniu (#637640), ale na razie bez odpowiedzi.

Niby, jak pisze ArnVaker, paczki są na stronie, ale jakoś im nie ufam. Gdyby była wersja w repozytorium Debiana, to bym instalował bez obaw.

Co do sposobów przyspieszania systemu: preload i readahead są zupełnie bezinwazyjne, więc można je zainstalować i zapomnieć. Będą sobie działać i może nawet w jakiś sposób optymalizować działanie systemu, ale na cuda nie ma co liczyć. AFAIR prelink modyfikuje biblioteki, więc go nawet nie ruszałem.