simpleadmin Nov 13 2015 at 16:03

А был ли who на сервере?

22 min

25K

Configuring Linux *System administration **nix *

+17

Comments 15

koldyr Nov 13 2015 at 16:34

логи должны дублироваться на сервер логов.

Gendalph Nov 13 2015 at 18:21

а если его нет, то должен работать logcheck

koldyr Nov 13 2015 at 18:27

а если его нет, то логчек вам тоже пропатчат

simpleadmin Nov 15 2015 at 13:00

А если он есть, то выполнят SYSLOG_ACTION_CLEAR до того как буфер достигнет LOG_BUF_LEN

koldyr Nov 15 2015 at 21:30

а разве это не касается только логов ядра?

chaturanga Nov 13 2015 at 21:40

да вроде статья о том, что нельзя пользоваться для логирования ТОЛЬКО системными средствами
и Вы её не поняли

Askon Nov 13 2015 at 23:41

Основной вопрос — зачем вообще заходить было? ;) login, history…

mickvav Nov 14 2015 at 17:44

На history -c вы, вероятно убьете всю историю. Что тоже вызовет вопросы. В bash можно все команды с пробела начинать, чтобы в историю не попадали.

Gendalph Nov 14 2015 at 18:53

ЕМНИП, это управляется глобальной переменной HISTCONTROL

simpleadmin Nov 14 2015 at 19:10

на самом деле

# history -c

здесь вообще лишнее, т.к. история фиксируется в ~/.history про логауте, а при

# kill -9 $$

у нас не будет корректного выхода и как следствие история не зафиксируется

senia Nov 14 2015 at 20:26

Это если в PROMPT_COMMAND нет history -a. Например: unix.stackexchange.com/a/1292/50217

simpleadmin Nov 14 2015 at 20:37

это не актуально для

# `echo $SHELL` --version
tcsh 6.18.01 (Astron)

senia Nov 14 2015 at 20:47

Для этого случая актуально history -S в postcmd.

simpleadmin Nov 14 2015 at 21:11

В этом случае и history -c будет бесмысленным, т.к. при history -S буфер сбросится в ~/.history, но дефолтный alias postcmd отсутствует, поэтому это уже отличные от «по умолчанию» настройки.
Тут, возможно, чтобы подчистить придётся подредактировать ~/.history перед уходом.
Хотя скорее всего даже kill -9 $$ при этом отлогируется в ~/.history

grossws Nov 14 2015 at 21:52

В journald пошли более заковыристым путём, чтобы пресечь подобные правки: используется криптографическая подпись для запечатывания лога на определенный момент, производится новый ключ (который может также быть получен из секретного ключа, который не хранится на сервере), а старый затирается.

Естественно, такой подход является полумерой, т. к. имеет окно на правку логов. И отправка важных логов на другую машину остаётся основным методом борьбы с их компрометацией.