Как известно, список команд, запускаемых пользователем из командной строки, сохраняется bash’ем в файле ~/.bash_history . Но там они записываются просто в порядке запуска, а когда конкретно они запускались, неизвестно.

Внезапно обнаружилось, что информацию о времени запуска добавить очень просто, а она бывает очень полезна в процессе расследования всяких хаков и глюков.
Надо просто приделать к bash’у переменную HISTTIMEFORMAT – через /etc/profile, /etc/bash/bashrc, или персональные ~/.bashrc и ~/.profile:
export HISTTIMEFORMAT='%F %T '

Значение HISTTIMEFORMAT влияет только на формат вывода даты/времени при запуске history, его можно поменять в любой момент. Главное, чтоб при запуске bash’а эта переменная была хоть как-то определена, и тогда в .bash_history будут подписываться timestamp’ы:
#1491997427
cat .bashrc
#1491998079
tail .bash_history

и вот как посмотреть дату и время этих команд:
$ date -d '@1491997427'
Wed Apr 12 12:43:47 IST 2017
$ date -d '@1491998079'
Wed Apr 12 12:54:39 IST 2017

Оригинал этой записи в личном блоге.

Грабли начинаются прямо с названия: “Олимпиада для Unix администраторов”. А на деле существенное количество вопросов было линукс-специфичными:

Как в Linux узнать текущий рабочий каталог процесса с pid = 4556?

Вы зашли на сервер с Linux с помощью ssh. Как перегрузить этот сервер по sysrq-b?

Как в Linux смонтировать файловую систему tmpfs размеров 2Гб в /tmpfs?

и т.п. И даже очень хороший администратор соляриса или freebsd пролетает, потому что таких тонкостей про линукс не знает. Не нужны они ему. А в тех вопросах, где речь шла о юниксах вообще, было совершенно непонятно, какой должен быть ответ. То ли универсальный, который работает во всех, то ли про каждую систему надо писать отдельно, то ли про какую-нибудь одну. Ни в вопросах, ни в правилах это не оговорили. Пример см. ниже.

Несколько вопросов, причём очень узконаправленных, зачем-то было про базы данных, хотя DBA – это вообще отдельная профессия:

Какие из перечисленных типов хранилищ в MySQL поддерживают транзакционность:  MyISAM, Memory, InnoDB, Archive, NDB, CSV?

Как в PostgreSQL очистить файлы баз данных от уже удалённых записей?

Ну вот нафига администратору _UNIX_ это знать?

Некоторые вопросы были сильно надуманные:

Напишите чему будет равен mss, если Вы используете IPv6 и mtu=1450?

Вот сколько лет работаю администратором, а с IPv6 на практике ни разу не встречался. А уж такие тонкости, как размер служебных полей и подавно наизусть не помню.

Или вот Как в терминале bash при помощи одной служебной комбинации клавиш слово dpgk превратить в dpkg, если курсор стоит на букве k?

Ну положим, есть там какая-то хитрая комбинация, которая переставляет буквы местами, но зачем оно на практике нужно? Быстрее будет одну букву стереть и набрать заново. И кто бы мне рассказал, что такое “терминал bash”, а?

Но это бы ещё ничего. Наиболее существенная проблема — в некорректной или неоднозначной формулировке вопросов. Прежде чем отвечать, надо было сначала догадаться, чтО имели в виду организаторы, задавая вопрос. Вот, например:

В bash вы хотите сравнить два числа. Какой оператор сравнения нужно применить, если нужно узнать, что первое значение больше или равно второму?

Ответ >= по мнению организаторов неправильный. Его засчитали только на апелляции, после демонстрации его работы. А подразумевался, вероятно -ge, только он ни разу не от bash, а от программы test, она же [. И использовать её, понятное дело, можно вовсе не только в bash.

Или вот: Как в Unix посмотреть какие файлы или устройства использует процесс с pid = 85003?

Ответ ls -l /proc/85003/fd не засчитали. Потому что, как написали организаторы,  "Мы принимали ответы на вопрос 6:
1. Для Linux: никак или в ответе должно было быть упоминание, что это можно сделать с помощью дополнительной настройки ядра, например, sysctl -w kernel.pid_max = (число > 85003). По умолчанию значение переменной kernel.pid_max = 32768;

Но вопрос-то был не про то, как сделать возможным такой номер процесса, а про то, как посмотреть на открытые им файлы. Естественно предположить, что процесс уже есть, иначе и смотреть не на что. А вот под ж ты, надо было догадаться, что они хотели с упоминанием. И этого одного балла мне как раз не хватило для попадания в следующий тур. И спорить уже не дозволено, ответ пришёл после закрытия апелляций.

2. Для FreeBSD: fstat -p 85003 или установить lsof, а потом посмотреть с помощью lsof -p 85003. Утилиты lsof и procfs по умолчанию не установлены;

Ага, а ещё можно самому написать ядрёный модуль и программу, которая с его помощью  будет извлекать нужные данные из внутренних структур. Я писал когда-то аналогичную штуку для FreeBSD.

3. В для Solaris мы принимали ответ, что можно сделать с помощью утилиты pfiles.". А теперь угадайте, который из вышеперечисленных трёх ответов хотели увидеть организаторы. Или все три сразу.

Как очистить лог-файл /var/log/log, открытый работающим процессом?

Что значит “очистить”? Удалить и создать новый — считается? А что, файл /var/log/log есть, очищенный, задача выполнена. Подразумевалась, вероятно, операция truncate, но как об этом догадаться?

Как посмотреть версию и возможные параметры модуля e1000e для загруженного в настоящий момент ядра в Linux?

Я этот вопрос понял так: “как посмотреть, с какими конкретно параметрами, если они были указаны,  загружен работающий в настоящий момент модуль”. И написал про /sys/module/e1000e/parameters/. А оказывается, имелись в виду вообще все возможные параметры, а правильный ответ — modinfo.

Какова последовательность пакетов tcp при установке соединения (укажите типы пакетов)?

Угадайте какие могут быть “типы пакетов” в TCP? Ответ про SYN/SYN+ACK/ACK был засчитан, но это же флаги, а  никакие не типы.

Какой параметр ядра отвечает за максимальный размер памяти, доступный для выделения процессам в Linux?

В моём понимании “параметр ядра” – это то, что в его командной строке указано. А которые можно на ходу менять через /proc или sysctl — это переменные. Тут, конечно, можно спорить, но это и означает, что вопрос интерпретируется неоднозначно.

Короче, тщательнЕе надо, товарищи, тщательнЕе. Системным администраторам задачи надо формулировать чётко, чтоб потом не удивляться последствиям ;)

Оригинал этой записи. Комментировать можно тут или там.

Знаете, некоторые учебники для начинающих юниксоводов рекомендуют в целях безопасности в скриптах явно указывать PATH. Ну, типа, мало ли, в каких условиях его  запускать будут, лучше указать явно, чтоб не запустилось чего лишнего из ~/bin, /usr/local/,  и т.п.

Вот начитавшись таких учебников, тут некоторые товарищи и написали в скрипте PATH=/usr/bin:/usr/local/bin

А я потом три дня бился головой об стенку, пытаясь понять, чего ж оно не работает при переносе на другую систему. А на этой системе tar, rm, mv и прочая стандартная лабуда оказались в /bin. Ну и, конечно, сообщения об ошибках были заботливо перенаправлены в /dev/null, чтоб их случайно никто не увидел.

Уроды.

Оригинал этой записи. Комментировать можно тут или там.

никого не интересует? https://slonik-v-domene.livejournal.com/45265.html

P.S. Я не знал, что в Рамблере всё так печально.

Оригинал этой записи. Комментировать можно тут или там.