Tuning: wyłączamy core-dump

-
W przypadku nieoczekiwanego wyłączenia się programu, automatycznie uruchamiany jest proces coredump, który powoduje zrzut różnych informacji, które programistom mogą pomóc w rozwiązaniu problemu. Niemniej jednak, dla zwykłego użytkownika jest to proces zbyteczny, zajmuje miejsce, a nadto w owych zrzutach mogą być różne informacje, do których niekoniecznie chcielibyśmy, by ktokolwiek miał dostęp (co prawda są one niby czytelne wyłącznie dla roota, jednakże nie jest to w zasadzie żadne zabezpieczenie przed osobą, która potrafi się do partycji głównej "dobrać", nawet nieznając hasła root).
Z punktu widzenia zwykłego użytkownika usługa ta może być po prostu zbędna.
Wyłączenie można przeprowadzić w zasadzie na dwu poziomach. W przestrzeni użytkownika (userspace) oraz pozostałej. Wyłączenie pierwszej powoduje, że programy uruchamiane w userspace nie będą dokonywały zrzutów, jeśli niespodziewanie się wyłączą. Wyłączenie również drugiej powoduje, że coredump jest wyłączone dla wszystkich sytuacji.
Pamiętajmy jednak, że wyłączając coredump możemy jednocześnie pozbawić się możliwości usunięcia jakichś awarii związanych z oprogramowaniem.

1. Wyłączenie coredump w userspace
Dokonujemy edycji pliku /etc/systemd/coredump.conf, odnajdujemy linijkę, którą domyślnie ma postać:
# Storage=external
i zmieniamy na:
Storage=none
Teraz jeszcze musimy o tym poinformować systemd:
# systemctl daemon-reload

2. Zerujemy przestrzeń dyskową dla zrzutów
Edytujemy plik /etc/security/limits.conf i dopisujemy:
* hard core 0
pod sekcją, która wygląda tak:
#<domain>      <type>  <item>         <value>

3. Zmieniamy ustawienia sysctl
Edytujemy bądź tworzymy plik: /etc/sysctl.conf i dopisujemy w nim:
fs.suid_dumpable = 0
Można też przekompilować kernel i w ogóle wyłączyć taką możliwość.

Komentarze

Prześlij komentarz

Popularne posty z tego bloga

Brak możliwości aktualizacji lub instalacji pakietów - zablokowana baza

-
Arch oferuje doprawdy świetne narzędzie do obsługi pakietów. Niemniej jednak zbliża się już koniec drugiej dekady XXI w. i przyzwyczajenia użytkowników, czy też ich oczekiwania w zakresie jakiegoś prostego, graficznego menedżera paczek są duże i poniekąd można je uznać za uzasadnione. Tymczasem pacman czuje się jak ryba w wodzie wyłącznie w konsoli. Natura nie znosi próżni, stąd też już od dawna powstają takie graficzne menedżery. Ostanio - głównie za sprawą ich domyślnego instalowania w dystrybucjach pochodnych - popularność zyskały pamac oraz octopi. Oba te programy oferują, działające nieustannie w tle, małe narzędzia monitorujące możliwość aktualizacji pakietów. W ich konfiguracji można sobie zmienić częstotliwość aktualizacji. Jeśli nic nie zmienimy w systemie, to owe narzędzia zainstalują się wraz ze wspomnianymi menedżerami i ustawione będą (o ile pamiętam) na sprawdzanie aktualizacji raz dziennie. Zwykle oznacza to, że rozpoczynają swe działanie zaraz po pierwszym uruchomieniu
Czytaj więcej

Radzimy sobie z: GPG: odbiór z serwera kluczy nie powiódł się: brak dirmngr

-
Od dłuższego już czasu Arch wprowadził podpisywanie paczek kluczem gpg. W zasadzie wszystko winno przebiegać bezboleśnie nawet, gdy trzeba owe klucze dodać. Niestety zdarza się (mi się niegdyś zdarzyło), że próba dodania klucza GPG zwraca następujący błąd: sudo pacman-key -r ID_KEY gpg: connecting dirmngr at '/root/.gnupg/S.dirmngr' failed: Wywołanie connect dla IPC nie powiodło się gpg: odbiór z serwera kluczy nie powiódł się: Brak dirmngr Na nic nie zdają się również "zwykłe" próby poradzenia sobie w takich przypadkach, jak: # pacman-key --init # pacman-key --refresh-keys # pacman-key --populate Dalej otrzymujemy powyższy błąd. Nic straconego. Prawdopodobnie wydanie następującej komendy: dirmngr < /dev/null && sudo -i dirmngr < /dev/null spowoduje, że po jej użyciu klucze będzie już można dodawać bez żadnych problemów.
Czytaj więcej

Przywracamy działanie drukarek w CUPS 2.3.0

-
Co najmniej wraz z nastaniem CUPS 2.3.0 (choć problemy zgłaszane były już w późnych wersjach serii 2.2.x) część (i to spora) drukarek odmówiła współpracy. Nie było też możliwości ich zainstalowania. Problem związany był ze zmianą dokonaną w CUPS polegającą na tym, że przestał on "przyjmować" te PPD (czyli ogólnie sterowniki drukarek), które miały wpisane "Custom" w różnych deklaracjach. Obecnie CUPS przyjmował tam "Other", a "Custom" powodowało, że drukarki stawały się tańszą lub droższą, niemniej jednak wyłącznie ozdobą naszych biur i domów. Sama zmiana dokonana w CUPS nie była zachcianką jego deweloperów, a powodowana była chęcią uniknięcia sygnalizowanego innego błędu powodującego wykrzaczanie się cupsd. I wszystko dobrze, ale spowodowała unieruchomienie znacznej ilości urządzeń. Problem nie dotyczy wyłącznie Archa i jego pochodnych, ale dotknął niemal wszystkich w miarę świeżych dystrybucji. Oczywiście owe PPD winny zostać przerobione prze
Czytaj więcej