Forum Debian Users Gang

# Wartości tylko do odczytu. Określają rodzaj systemu operacyjnego oraz numerek kernela. Dodatkowo "#1" w
# parametrze version oznacza, że jest to pierwszy kernel zbudowany z tego źródła, a data na końcu wskazuje
# kiedy ów kernel został zbudowany.
#kernel.ostype = Linux
#kernel.osrelease = 3.14-1-amd64
#kernel.version = #1 SMP Debian 3.14.4-1 (2014-05-13)

# W przypadku gdy opcja jest ustawiona na inną wartość niż "0" i dojdzie do zdarzenia, które wybudzi dysk ze
# stanu uśpienia, wszystkie dirty pages zostaną automatycznie zapisane na dysk w czasie określonym w tym 
# parametrze. Rozsądne wartości od 2s do 5s. Wartość "0" wyłącza laptop mode.
vm.laptop_mode = 0

# Czasami dysk rozkręca talerze z niewiadomego powodu. Kiedy tego typu sytuacja występuje, można spróbować
# ustalić jej przyczynę przy pomocy parametru block_dump . Zanim się jednak uaktywni tę opcję, trzeba, albo
# wyłączyć logi kernela w syslogu, albo wyłączyć sysloga całkowicie. W przeciwnym wypadku, system się zapętli,
# bo informacje o aktywności dysku zbierane będą przez syslog, a ten je będzie zapisywał na dysk, a to
# wygeneruje więcej informacji o aktywności dysku i tak dalej. Po wyłączeniu sysloga lub ukryciu logów
# kernela, by odczytać informacje, które zostaną pokazane za sprawą block_dump, trzeba posłużyć się dmesg.
#
# Przykładowe logi mogą wyglądać jak poniżej:
# bash(273): READ block 3242 on hda1
# bash(273): dirtied inode 10237 (.bash_history) on hda1
# pdflush(6): WRITE block 3242 on hda1
#
# Mówią one, że proces nazwany bash, o numerze ID 273, odczytał blok 3242 na urządzeniu hda1. Ten sam proces
# zmienił plik .bash_history ale dane z tej zmiany nie zostały jeszcze zapisane na dysk (figurują w pamięci
# RAM jako dirty pages). Z kolei proces pdflush zapisał blok 3242 -- dirty pages zostały zapisane na dysk.
# -- http://www.linuxjournal.com/article/7539
vm.block_dump = 0

# W przypadku ustawienia na "1", napęd wysunie płytkę od razu po wydaniu polecenia umount -- nie trzeba
# dodatkowo korzystać z eject .
dev.cdrom.autoeject = 0

# Jeśli ustawione na wartość "1", napęd zamknie tackę po wydaniu polecenia mount i po chwili zamontuje płytkę.
# W przeciwnym wypadku zostanie zwrócony błąd o niemożliwości zamontowania krążka.
dev.cdrom.autoclose = 1

# Włącza ochronę symbolicznych dowiązań w katalogach z ustawionym sticky bitem, np. w /tmp/ . Ustawienie tego
# bitu chroni przed usuwaniem nieswoich plików w danym katalogu ale pojawia się znów problem z eskalacją
# uprawnień, np. w sytuacji gdy proces posiadający uprawnienia root przechodzi przez link symboliczny innego
# użytkownika. Ustawienie wartości "1" zezwoli na podążanie za dowiązaniami tylko w przypadku katalogów bez
# sticky bitu. W przypadku folderów, które mają ustawiony sticky bit, utworzenie symlinku będzie możliwe
# dopiero wtedy gdy UID dowiązania oraz użytkownika przechodzącego będą do siebie pasować, albo właściciel
# katalogu jest taki sam co w przypadku dowiązania. To ustawienie może popsuć część źle napisanych programów
# ale daje gwarancję, że uprawnienia nie zostaną przekroczone za pomocą dowiązań symbolicznych.
fs.protected_symlinks = 1
#
# Ochrona twardych dowiązań działa na podobnej zasadzie co w przypadku dowiązań symbolicznych, z tym, że tutaj
# sytuacja nie ogranicza się tylko do katalogów z ustawionym sticky bitem. W przypadków systemów bez
# oddzielnej partycji na katalog /home/, użytkownik może utworzyć link do /etc/shadow w swoim katalogu
# domowym. W prawdzie właściciel pliku i prawa dostępu są takie same jak były ale jakiś proces z prawami roota
# mógłby przez przypadek zmienić prawa dostępu tego dowiązania, np. w wyniku:
#
# # chown -R morfik:morfik /home/morfik/
#
# Co definitywnie zmieni nie tylko prawa dowiązania ale także prawa do pliku /etc/shadow . Jeśli wartość
# poniższego parametru zostanie ustawiona na "1", tworzenie twardych dowiązań będzie możliwe tylko w przypadku
# plików, do których użytkownik, tworzący owe dowiązanie, posiada prawa zapisu lub jest ich właścicielem.
fs.protected_hardlinks = 1

# Jeśli nie ma odpowiedzi na rozpoczynający połączenie pakiet SYN, kernel spróbuje ponowić zapytanie kilka
# razy i będzie robił to w ciągle zwiększających się odstępach czasu. Ustanawiając limit dla prób połączeń,
# można tym samym ograniczyć czas, przez który kernel będzie próbował ustanowić nowe połączenie. Przykładowo:
#
#     próby  | czas na retransmisje (sekundy)
#    --------|-------------------------------
#        1    |    1
#        2    |    1+2=3
#        3    |    1+2+4=7 
#        4    |    1+2+4+8=15 
#        5    |    1+2+4+8+16=31 
#        6    |    1+2+4+8+16+32=63 
#        7    |    1+2+4+8+16+32+64=127 
#
# Wartość 4 oznacza zatem, że kernel, po nieudanej próbie nawiązania połączenia, spróbuje zretransmitować
# pakiet SYN 4 razy i jeśli żadna z tych prób się nie powiedzie, po czasie 15 sekund kernel odpuści.
net.ipv4.tcp_syn_retries = 4

# Gdy serwer otrzymuje zapytanie SYN, natychmiast wysyła odpowiedź w postaci pakietu z ustawionymi flagami
# SYN i ACK umieszczając jednocześnie to połączenie w kolejce (backlog queue) do chwili aż nadejdzie od
# klienta pakiet z ustawioną flagą ACK . Gdy taki pakiet nie nadchodzi, serwer retransmituje swój pakiet
# SYN-ACK kilka razy, dając tym samym szanse klientowi by spróbował odesłać pakiet ACK jeszcze raz. Jeśli
# adres klienta został zespoofowany, taka odpowiedź nigdy nie nadejdzie i serwer usunie to półotwarte
# połączenie. Połączenia w stanie SYN RCVD zajmują cenne zasoby i by odciążyć trochę maszynę można
# przyśpieszyć proces zamykania tego typu połączeń przez zmianę ilości retransmisji (działa na takiej samej
# zasadzie co tcp_syn_retries). Obniżenie wartości tego parametru w przypadku słabych łącz może powodować
# problemy z połączeniem.
# -- http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks
net.ipv4.tcp_synack_retries = 2

# Maksymalna ilość osieroconych połączeń. Osierocone połączenie to takie gniazdo, które nie jest powiązane z
# żadnym deskryptorem pliku i żaden deskryptor nie odnosi się do tego gniazda ale samo gniazdo ciągle istnieje
# w pamięci i czeka aż protokół TCP z nim skończy. Każde takie połączenie może zjeść do 64KiB pamięci i tych
# danych nie da rady przenieść do SWAP. Jeśli wartość tego parametru zostanie przekroczona, wszystkie sieroty
# zostaną natychmiast zresetowane i kernel wyrzuci ostrzeżenie. Domyślna wartość zależy od ilości posiadanej
# pamięci RAM. Ilość sierot można sprawdzić przez  /proc/net/sockstat .
# -- http://kaivanov.blogspot.com/2013/01/troubleshooting-out-of-socket-memory.html
#net.ipv4.tcp_max_orphans = 4096
#
# Poniższy parametr określa ile razy próbować zabić osierocone połączenie odpytując przy tym drugą stronę
# zanim połączenie zostanie ubite lokalnie.
#net.ipv4.tcp_orphan_retries = 0

# Ilość stron pamięci (pages) przeznaczonych dla gniazd TCP. Gniazdo TCP identyfikuje konkretne połączenie, 
# w skład którego wchodzi lokalny adres, lokalny port, zdalny adres, zdalny port oraz protokół. By przeliczyć
# strony pamięci na faktyczną jej objętość, trzeba przemnożyć ilość stron przez rozmiar strony. Z kolei
# rozmiar strony można uzyskać porównując dwa parametry z /proc/meminfo oraz /proc/vmstat , przykładowo:
#
#    $ cat /proc/meminfo | egrep -i "Mapped" && cat /proc/vmstat | egrep -i "nr_mapped"
#    Mapped:   67408 kB
#    nr_mapped 16852
#
# Rozmiar strony to  Mapped/nr_mapped , czyli 67408KiB/16852=4KiB albo 4096 bajtów. Poniższe 3 wartości
# określają minimalną, umiarkowaną i maksymalną ilość stron pamięci, które mogą wykorzystać wszystkie gniazda
# TCP łącznie i odpowiadają odpowiednio za 64MiB, 96MiB i 144MiB pamięci. Ten parametr domyślnie jest
# kalkulowany przy starcie systemu w oparciu o ilość dostępnej pamięci RAM. 
net.ipv4.tcp_mem = 16500 24750 37125

# Każda niezerowa wartość wskazuje na fakt, że kernel ma załadowane moduły, które nie są do końca free, 
# prawdopodobnie sterowniki do grafik lub bezprzewodowych kart sieciowych. Deweloperzy kernela nie są zbytnio
# zainteresowani problemami występującymi w takich jądrach, bo nie mogą ustalić przyczyny, której nie można 
# dostrzec z racji, że takie moduły posiadają zamknięty kod. Poniżej znajduje się lista wartości, które mogą
# być dodane do siebie, dając tym samym wynikową wartość:
#
#      1 - A module with a non-GPL license has been loaded, this includes modules with no license. Set by
#          modutils >= 2.4.9 and module-init-tools.
#      2 - A module was force loaded by insmod -f. Set by modutils >= 2.4.9 and module-init-tools.
#      4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
#      8 - A module was forcibly unloaded from the system by rmmod -f.
#     16 - A hardware machine check error occurred on the system.
#     32 - A bad page was discovered on the system.
#     64 - The user has asked that the system be marked "tainted".  This could be because they are running
#          software that directly modifies the hardware, or for other reasons.
#    128 - The system has died.
#    256 - The ACPI DSDT has been overridden with one supplied by the user instead of using the one provided
#          by the hardware.
#    512 - A kernel warning has occurred.
#   1024 - A module from drivers/staging was loaded.
#   2048 - The system is working around a severe firmware bug.
#   4096 - An out-of-tree module has been loaded.
#   8192 - An unsigned module has been loaded in a kernel supporting module signature.
#
# Dla przykładu wartość "4097" to suma "4096" i "1", czyli załadowany jest moduł na licencji nie GPL. W logu
# kernela można odszukać informacje wskazujące na moduły, które plamią opensourcowe imię kernela:
#
#    # dmesg | grep -i taint
#    [Tue Jun 10 06:19:38 2014] nvidia: module license 'NVIDIA' taints kernel.
#    [Tue Jun 10 06:19:38 2014] Disabling lock debugging due to kernel taint
#
# W tym przypadku winne są sterowniki nvidii. Po ich usunięciu poniższy parametr powinien wskazywać wartość
# "0".
#kernel.tainted = 4097

# Pamięć współdzielona (shared memory) jest to taki obszar pamięci, który może być dzielony przez kilka
# różnych procesów w celu wymiany informacji między tymi procesami. Takie rozwiązanie jest szybsze od
# standardowej międzyprocesowej komunikacji (Inter Process Communication), bo w przypadku gdy pamięć jest
# mapowana na przestrzeń adresową procesu, który współdzieli dany obszar pamięci, kernel nie bierze udziału w
# przekazywaniu danych między procesami, bo nie ma potrzeby by te dane kopiować. Wiele aplikacji korzysta z
# tego ficzeru, np. oprogramowanie od baz danych. By ustalić jakie limity są w systemie, można skorzystać
# z "ipcs -lm", przykładowo:
#
#    $ ipcs -lm
#    ------ Shared Memory Limits --------
#    max number of segments = 4096                       - shmmni
#    max seg size (kbytes) = 65536                       - shmmax
#    max total shared memory (kbytes) = 524288           - shmall
#    min seg size (bytes) = 1                            - minimalny rozmiar segmentu do współdzielenia
#
# Poniższy parametr kontroluje całkowitą ilość pamięci współdzielnej, która może być wykorzystana w tym samym
# czasie na danym systemie. Ten parametr nie jest definiowany w bajtach, tylko w stronach (page) i by uzyskać
# maksymalną ilość pamięci przeznaczoną do współdzielenia, trzeba pomnożyć wartość tego parametru przez
# rozmiar strony, zwykle 4096 bajtów.
kernel.shmall = 131072
#
# Definiuje maksymalny rozmiar dla pojedynczego segmentu współdzielonego (w bajtach).
kernel.shmmax = 67108864
#
# Ten parametr jest używany do ustawienia maksymalnej ilości współdzielonych segmentów w systemie. 
kernel.shmmni = 4096
#
# W przypadku ustawienia shmall na "0", czyli usunięcia górnego limitu dla pamięci współdzielonej, istnieje
# możliwość, że użytkownik systemu będzie w stanie wykorzystać całą dostępną pamięć na segmenty SHM. Jeśli
# tego typu sytuacja wystąpi, OMM-killer nie będzie w stanie uwolnić tych zasobów pamięci. Jednym z dwóch
# rozwiązań jest włączenie opcji shm_rmid_forced , która wymusza aby każdy segment SHM był tworzony z flagą 
# IPC_RMID , która to gwarantuje, że dany segment SHM jest przypisany do co najmniej jednego procesu, co z
# kolei zapewnia, że w przypadku wyczerpania się pamięci, OMM-killer zdoła ubić winny proces, a segment SHM
# zniknie razem z tym procesem. Drugą opcją jest ustawienie górnego limitu dla pamięci współdzielonej w
# parametrze shmall .
# -- http://lwn.net/Articles/595638/
#
# Jeśli poniższy parametr zostanie ustawiony na "1", wszystkie segmenty zostaną przeznaczone do usunięcia, w
# momencie gdy liczba dołączonych do nich procesów spadnie do 0 i co z tym się wiąże, nie da się utworzyć
# współdzielonych segmentów pamięci istniejących niezależnie od procesów. Tego typu zachowanie może popsuć
# pewne aplikacje.
kernel.shm_rmid_forced = 0

# PageCache/BufferCache przyspiesza odczyt plików przez buforowanie danych w pamięci RAM przy pierwszym
# odczycie lub zapisie plików na dysku. Jeśli zajdzie potrzeba by w późniejszym czasie odczytać te dane
# ponownie, to system odwoła się do pamięci RAM zamiast do dysku twardego, co przyśpieszy znacznie operacje na
# plikach. W przypadku gdyby system potrzebował więcej pamięci pod aplikacje, zwolni on część obszaru 
# wykorzystywanego w danej chwili przez PageCache, 
#
# W zależności od sprecyzowanej wartości, część cache w pamięci RAM zostanie wyczyszczona. W przypadku
# przesłania "1", kernel uwolni cały PageCache, w przypadku "2", cache pod inody i dentry zostanie zwolniony.
# Można także przesłać "3", co spowoduje uwolnienie tych dwóch powyżej. Jednak dirty pages nie zostaną w ten
# sposób wyczyszczone. Jeśli istnieje potrzeba wyczyszczenia całego cache, trzeba pierw wydać polecenie sync ,
# po czym przesłać "3" via:
#
#    # echo "3" > /proc/sys/vm/drop_caches
#
# Przy czym ta operacja nie ma trwałego efektu, tj. po wydaniu powyższego polecenia, cache i tak będzie się
# zbierał i by go zwolnić, ponownie trzeba zapisać drop_caches .
vm.drop_caches = 0