Logrotate nie odczytuje już pliku konfiguracyjnego z dowiązaniem symbolicznym z powodu własności użytkownika innego niż root

15

Obecnie aktualizujemy z Ubuntu 12.04 LTS do 14.04 LTS na naszych serwerach aplikacji ruby on rails i zauważyliśmy, że pliki dziennika już się nie obracają.

Na obu komputerach mamy plik /var/app-name/config/logrotatenależący do naszego użytkownika unix, deployerktóry zawiera prawidłowy plik logrotate w następujący sposób:

/var/app-name/log/*.log {
  daily
  rotate 365
  delaycompress
  compress
  dateext
  dateformat -%Y%m%d
  missingok
  copytruncate
}

To jest następnie symlinkowane do /etc/logrotate.d/katalogu jakoapp-name

Na naszym serwerze Ubuntu 12.04 mamy logrotate 3.7.8, który działa dobrze. Przechodzi do var/app-name/log/katalogu i obraca wszystkie pliki dziennika

Ale na serwerze Ubuntu 14.04 mamy logrotate 3.8.7, która nie obraca plików logów dla naszej aplikacji.

Kiedy debuguję to za pośrednictwem sudo logrotate -d -f /etc/logrotate/.conf, otrzymuję następujące dane wyjściowe:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

Ścigając to w kodzie, wydaje się, że ta zmiana została dodana do strumienia wydania 3.8.x: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

Jeśli zmienię własność dowiązane do pliku /var/app-name/config/logrotate, aby rootnastępnie zacznie ponownie działać. Ale biorąc pod uwagę, że ten plik jest częścią mojej aplikacji i został utworzony przez środowisko wdrażania capistrano, którego używamy w tym stanie, wolałbym nie zmieniać jego własności, gdy działało dobrze.

Więc czy pliki konfiguracyjne z dowiązaniami symbolicznymi są polecane / obsługiwane przez logrotate?

A jeśli tak, to czy odmowę użycia mojego pliku (będącego własnością deployer), który jest dowiązany do /etc/logrotate.dkatalogu, należy uznać za błąd?

Czy istnieje inne zalecane podejście do rotacji dzienników specyficznych dla aplikacji?

(pytany także o Unix StackExchange )

ubuntu permissions logrotate

— fantomowy wieloryb
źródło

Dobre pytanie! Widzę, że później była dyskusja na temat sprawdzania nazwy użytkownika „root” zamiast uid == 0, ale nie spowodowało to pytania, dlaczego wymagana jest własność root.

— agtoever

6

Problem polega na tym, że plik konfiguracyjny logrotate może uruchamiać dowolne polecenie jako root (używając sekcji prerotate / postrotate). Dlatego skutecznie nadawałbyś deployeruprawnienia użytkownika root, umożliwiając mu zapis do plików /etc/logrotate.d/. Więc nie, to nie jest błąd.

Jeśli ufasz swojemu użytkownikowi wdrażającemu, myślę, że możesz rozwiązać problem, przyznając mu prawo sudo do kopiowania plików /etc/logrotate.d/. Zakładając oczywiście, że użytkownik wdrażający nie jest tym samym użytkownikiem, co aplikacja internetowa.

— pelle
źródło

Zawsze naszym podejściem było preferowanie dowiązania symbolicznego z katalogów zewnętrznych aplikacji do plików aplikacji, tak aby każde wdrożenie wypychało nie tylko nową aplikację, ale także wszelkie zmiany plików konfiguracyjnych. Nawet przyznanie wdrażającemu prawa do wdrażania kodu poza katalogiem aplikacji jest sprzeczne z tym podejściem - ale również konieczność przeglądania pliku aplikacji, który jest własnością root po wdrożeniu, również wydaje się złą rzeczą (tm). Być może oryginalne podejście nie działa już dobrze z logrotate 3.8.0+

— phantomwhale

2

@ phantomwhale Twoje oryginalne podejście domyślnie przyznało użytkownikowi wdrażającemu pełne uprawnienia roota. To nie jest nowe w Logrotate 3.8. Jeśli chcesz ograniczyć prawa wdrażającego, jednocześnie pozwalając mu na aktualizację konfiguracji, myślę, że musisz użyć czegoś innego niż logrotate.

— pelle

2

Zdaję sobie sprawę, że jestem trochę spóźniony na przyjęcie, ale miałem podobny problem i pomyślałem, że podzielę się moim rozwiązaniem.

Moje problemy zaczęły się, gdy logrotatenie przeczytałem konfiguracji, którą napisałem. Nie chciałem wdrażać nowych konfiguracji w folderze należącym do roota, ponieważ nie chciałem, aby użytkownik wdrażania miał dostęp do konta root do czegokolwiek .

Na początku próbowałem uruchomić logrotatejako użytkownik wdrażania, ale narzekał na dostęp do pliku stanu pod adresem /var/lib/logrotate/state. Potem przeczytałem stronę podręcznika. Możesz określić logrotateużywany plik stanu ! Wydawało mi się, że lepszym rozwiązaniem jest skonfigurowanie codziennego crona do wykonywania logrotatejako użytkownik wdrażania z niestandardowym plikiem stanu. W ten sposób użytkownik wdrażania ani aplikacja nie potrzebują dostępu do konta root.

Oto jak określić plik stanu:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

Teraz możesz uruchomić logrotate jako dowolny użytkownik i właściciel konfiguracji, który ci się podoba!

— dayer4b
źródło