Idiomatyczna lokalizacja gniazd opartych na plikach w systemach Debian


13

Piszę proces demona dla systemu Debian, Cktóry używa Unix Domain Socket .

Jeśli katalog roboczy procesu demona jest katalogiem głównym, czy istnieje katalog idiomatyczny do umieszczenia gniazda w systemie plików?


Dlaczego po prostu nie pozwalasz na konfigurację?
BatchyX

3
@BatchyX Cóż, pewna wartość domyślna (zamiast zmuszania każdego administratora do samodzielnego podjęcia decyzji) z pewnością może być przyjemna. :)
CVn

Odpowiedzi:


17

Zazwyczaj znajdują się w /tmplub w jego podkatalogu. Zauważ, że wszystko, co się /tmpdzieje, może zostać skasowane podczas zamykania - niekoniecznie musi zostać usunięte, tylko strzeż się, że może być , więc jeśli z niego korzystasz, sprawdź, czy musisz za każdym razem tworzyć podkatalog. Będziesz chciał skorzystać z podkatalogu, jeśli chcesz ograniczyć dostęp poprzez uprawnienia, ponieważ /tmpjest on czytelny na całym świecie.

/runi /var/run(które mogą być symbolicznie połączone) są używane w podobny sposób, ale ogólnie są montowane jako systemy plików tmpfs - co oznacza, że ​​są tworzone podczas rozruchu i znajdują się w pamięci , a nie na dysku (więc nie używaj tego jako miejsca zrzutu) duże ilości danych). W przypadku gniazda uruchomieniowego jest to prawdopodobnie dobry wybór.

Zauważ, że /runi wszystkie inne wymienione tutaj katalogi oprócz /tmp , są zapisywalne tylko przez root. W przypadku procesu systemowego jest to w porządku, ale jeśli aplikacja może być uruchamiana przez nieuprzywilejowanego użytkownika, albo chcesz użyć /tmplub utworzyć gdzieś stały katalog i ustawić na nim uprawnienia, albo użyć lokalizacji w $ HOME użytkownika.

Możliwe jest utworzenie katalogu w /usr/share(lub /usr/local/share) podczas instalacji. Katalogi i zawartość nie są potencjalnie zbierane w obu butach, tak jak byłyby w /tmplub /run. Jednak, jak wskazuje jordanm w komentarzach, /usrmoże być montowany tylko do odczytu i odzwierciedlają to wytyczne dotyczące hierarchii systemu plików Linux . Oczywiście nie można go używać tylko do odczytu, gdy aplikacja jest zainstalowana, więc jeśli wygodnie jest utworzyć tam gniazdo, możesz je zostawić i użyć później (nadal będziesz mógł pisać w gnieździe, mimo że plik jest tylko do odczytu).

Jeśli chcesz mieć coś trwałego w obu butach, które nie zostaną zamontowane tylko do odczytu, /etcjest dość bezpiecznym zakładem, ponieważ jest to często używane w konfiguracjach systemowych i ponownych konfiguracjach. OTOH, możliwe jest posiadanie systemów, w których urządzenie leżące u podstaw całego głównego systemu plików jest tylko do odczytu (np. Systemy osadzone), z / tmp i / działa na innym urządzeniu (prawdopodobnie: tmpfs w pamięci). Tak więc wydaje się, że dwie najbardziej niezawodne strategie:

  • Zainstaluj gniazdo w stałej lokalizacji, gdy aplikacja jest zainstalowana.

  • Utwórz katalog w /runlub /var/runw czasie wykonywania i umieść tam gniazdo.

  • Zrób to samo tylko w /tmp.

Zaletą pierwszego jest to, że bez względu na wszystko, po zainstalowaniu aplikacji będziesz mieć gniazdo do użycia. Zaletą drugiego jest to, że może bardziej sprzyjać rozsądnemu programowaniu. Zaletą trzeciego jest to, że nie wymaga uprawnień administratora. Przejście z jednej implementacji na drugą powinno być łatwe, jeśli później zmienisz zdanie.

Wreszcie, jak przywołał BatchyX , powinieneś przynajmniej zaoferować opcję konfiguracji, cofając się od wyboru domyślnego.


2
/runlub /var/runjest często używany do procesów rootowania.
BatchyX

Dobrze. To są nawet więcej tmp niż /tmp. Zmienię to w.
goldilocks

/usrmoże być zamontowany jako tylko do odczytu. Pliki nigdy nie powinny być tam tworzone w czasie wykonywania. Inne sugestie są dobre.
jordanm

1
Dziękuję wszystkim za wkład, dyskusja była bardzo pouczająca. Zdecydowałem się ustawić domyślną lokalizację, /tmp/.APPNAME/.APPSOCKponieważ demon nie potrzebuje stałych danych.
recursion.ninja

1
Kolejna kluczowa różnica między /tmpi/run jest to, że tylko root ma uprawnienia do zapisu /run.
BatchyX,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.