В ОС был обнаружен баг: если в системном разделе полностью заканчивается свободное место - ОС перестаёт загружаться. Мало того, сотрудник дважды воспроизвёл ситуацию (хоть и не удалось понять причину): именно один из логов ОС разрастался настолько, что забивал абсолютно всё свободное место системного раздела, - буквально минут за 10.

А ещё логируется подключение устройств, в т.ч. USB; и если по ошибке было подключено ненужное устройство - нужно удалить его так, чтобы никто не возбуждался. Также данные алгоритмы пригодятся, если из ОС нужно вычистить всё лишнее: перед тем, как передать её новому человеку.

Проблема - комплексная:
- самое топорное решение, придуманное другими ребятами, - удалить файлы в /var/log: syslog, kern.log, messages, user.log и их производные ".1" ".2.gz" (логи за прошлое неизвестное время). Но это и очевидное действие для смотрящего логи, и опасность выхода ОС из строя: она имеет тонну багов - неизвестно, где выстрелит спустя время. Например, сейчас, при миграции сервера на другое железо: чуть-чуть изменились файлы в папке usr, неизвестно где, - и всё: чёрный экран с надписью "не могу записать какой-то там лог" при каждой загрузке ОС. Теперь целую программулину писать, которая найдёт эту нестыковку и исправит её - и написать её нужно за то время, пока старый сервер ещё жив;
- проанализировав предложенные log-файлы (в т.ч. дополнительные в директории логов), выяснилась обфускация и фрагментация записываемой информации. Например, дата в некоторых логах представлена в виде "5.142" - неизвестен формат и назначение. Или в одном из логов содержится запись о планшете - когда речь идёт о манипуляторе курсора в настройках виртуальной машины VirtualBox "USB планшет" (и находилась запись в логе "Xorg.0.log" - который не должен иметь к VirtualBox никакого отношения). То есть, невозможно предсказать: в каком файле логов, когда и что будет записано;
- технические сложности при просмотре логов: Kate не может запускаться под sudo - приходится изменять права самого файла. Далее выяснилось, что ОС после перезаписи лога возвращает права обратно - и если нажать "Перезагрузить файл", пользователь посылается на XXX;
- существует лог удаления логов, который тоже нужно править. Но вживую его - ещё не видел;
- в корне каждой учётной записи существует скрытый файл .bash_history, содержащий в себе все введённые команды в консоли;
- папка /var/cache тоже может содержать в себе ненужную информацию;
- напросился вывод, ввиду работы в условиях неопределённости. Нужно иметь эталонные логи, чтобы полностью зачищать логи текущие и разворачивать эталонные, - их можно взять из эталонного образа системы, на котором люди корректно поработали какое-то время. При этом, до удаления старых логов, размещения новых и назначения им требуемых пользователя и прав: нужно изменить в новых логах время записей и сделать все логи уникальными для каждого ПК. Для этого достаточно в массив строк лога вставлять другие изменённые строки из этого же лога. А также надо вычистить упоминание VirtualBox из эталонных логов.

Работа с логами на папке log не заканчивается:
- если стоит VirtualBox - нужно вычистить лог работы VirtualBox, вычистить список виртуальных машин в VirtualBox (включая список носителей, в т.ч. DVD), удалить логи виртуальных машин. И если требуется - изменить время создания и изменения у файлов настроек и всех носителей виртуальных машин;
- когда в ОС вставляется устройство - оно отображается, условно, sda, sdb. Папки с такими названиями содержатся где-то далеко (находится поиском по /). Внутри этой папки лежат папки sda1, sda2 и т.д. Проблема в том, что при подсоединении устройства sdb, отсутствующего в системе ранее: папки sdb, sdb1...sdbx создадутся - а при вынимании носителя удалятся или останутся. И нет разницы: есть информация об устройстве, которого уже нет (либо просто в разделе Ext4, либо в записях удалённых файлов раздела Ext4). А вычищать информацию об удалённых файлах из Ext4, в отличие от NTFS, - так и не научился: это что-то очень сложное (и не исключено, что потребуется написать свой софт, - но проще повеситься, см. смайлик колобка из QIP);
- логи Astra v.1.8.1 отличаются от логов v.1.7.4.0 (7);
- в общем, это не задачка на пару дней - а на несколько месяцев аналитики, алгоритмики, программирования и тестирования. При этом, техническую документацию и комментирование исходников ещё никто не отменял.