Несанкционированное использование команды tc
Я работаю в небольшой продуктовой компании. Я являюсь частью команды размера 4, которая строит конвейер развертывания для нашего продукта
Моя компания также наняла внештатного консультанта devops, который помогает нам в управлении нашей платформой CI/CD. У этого парня около 15 лет опыта и он горячий, и я ему не доверяю.
Мы используем инструмент jenkins CI\CD и установили его на экземпляр aws ec2. Все мои товарищи по команде и консультант devops имеют root-доступ к экземпляру ec2.
Сегодня в 11 утра неожиданно перестал работать пользовательский интерфейс Jenkins. Он загружался очень медленно. Мы перезапустили Дженкинс, увеличили размер кучи и все, что могли придумать, но не смогли найти решение.
Мы тратим от 3 до 4 часов, пытаясь решить проблему. Внезапно этот парень (консультант devops) пришел и исправил проблему за 5 минут. Когда я спросил его, что он сделал, он сказал, что удалил некоторые временные файлы. Будучи скептиком, я немедленно пошел и проверил историю команд
Он выполнил следующие команды
8 tc qdisc del dev eth0 root
229 tc qdisc del dev lo
230 tc qdisc ls
231 tc qdisc del dev lo root
232 echo -n "CPU" "100 99 166"
233 echo -n "CPU" -n "100 190 188" -n
234 yc qdisc del dev eth0 root
235 tc qdisc del dev eth0 root
236 tc qdisc del eth0
237 ifconfig
238 tc qdisc del eth0 root
239 tc qdisc del eth0 root 1
240 tc qdisc del dev eth0 root
241 at now +38 minutes
Я сделал быстрый поиск в Google и обнаружил, что команда tc используется для контроля трафика. Он используется для имитации задержки в сети, вызывая задержку или потерю пакетов
Из вышеприведенных команд похоже, что он удалил некоторые правила, которые вызывали потерю или задержку пакетов в исходящих пакетах.
Я понимаю, что этот парень добавил некоторые правила, используя команду tc, которая вызвала задержку или потерю пакета, потому что наш пользовательский интерфейс jenkins не загружался, а затем удалила те правила, которые исправили проблему.
Я разработчик и имею небольшой опыт в системном администрировании и разработке. Может ли кто-нибудь подтвердить это, чтобы я мог обратиться к руководству и подать официальную жалобу.
2 ответа
Невозможно определить состояние системы до того, как эти команды были запущены, и, следовательно, невозможно определить, удалял ли он внесенное изменение или выполняемая им работа действительно не вызывала изменений.
Чисто из того, что было выполнено, можно предположить, что на месте была система управления движением.
Обратите внимание, что tc используется не только для задержки или потери пакетов, но также для изменения приоритетов трафика и распределения полосы пропускания. Вполне возможно, что то, что парень пытался сделать, должно было быть полезным, но как-то облажалось.
Назовите меня циничным, но что с at now +38 minutes? Это явно требует выполнения некоторых команд и / или сценария через 38 минут. Это не запись в истории Bash, конечно.
Вполне возможно, что снова существует дисциплина очередей, и вот что at делал. Вы можете попробовать войти в эту систему и запустить tc qdisc ls чтобы проверить, был ли изменен qdisc по умолчанию.
В любом случае, если этот парень скажет, что он удалил некоторые временные файлы, я определенно буду циничен в этом - ничто из того, что он сделал, не удаляет временные файлы.
Я не смог распознать, что echo Команды пытались манипулировать. По крайней мере, в командной строке перенаправление не происходит (сама команда предполагает, что его следует поместить в файл где-нибудь).
Я бы посоветовал поискать еще немного, чтобы увидеть, какие текущие qdiscs находятся на месте.
После ответа @Matthew Ife, вы можете посмотреть в at Каталог спула и изучите файлы, доступные там. В моей системе это находится в /var/spool/at/spool и вы можете увидеть, если и что планируется к исполнению в будущем.