Вот за это я и не люблю PHP
В смысле, не просто язык (иногда мне самому случается на нём писать), а типичных похапешных программистов, пишущих уродские программы.
Итак, имеется софтина SSH Key Management, которая предназначена для автоматизированного раскладывания ssh-ключей на удалённые сервера. Идея полезная, так гораздо удобнее и быстрее добавлять и удалять юзерские ключи, чем вручную, и заодно можно в одном месте посмотреть, у кого на какой сервер какой доступ есть, а не лазить на каждый сервер и не искать там вручную.
Раньше она везде успешно работала, а сегодня про один новый сервер внезапно стала ругаться, что не может там скопировать authorized_keys2, что она всегда делает в качестве бэкапа. Зашёл на сервер, посмотрел - а копии-то вполне себе есть.. Так как же она их успешно создаёт, и при этом считает, что не вышло?!
Пошёл копаться в коде, и, как водится, обнаружил множество идиотизмов.
Во-первых, оказалось, что эта софтина для КАЖДОЙ команды, которую надо выполнить на удалённой машине, запускает ОТДЕЛЬНЫЙ экземпляр ssh.
Во-вторых, в некоторых командах заложены явно видимые грабли:
Например, для поиска домашней директории юзера запускается ssh $sudouser@$host grep $username /etc/passwd
А ведь так вместо нужного юзера по имени user могут найтись также fuser, luser, usermanager, и т.п. Видать, эти быдлокодеры не имели понятия о регулярных выражениях.
Создание бэкапной копии файла производится таким же образом: ssh $sudouser@$host cp $homedir/.ssh/authorized_keys2 $homedir/.ssh/authorized_keys2-$now 2>&1
А отсутствие у cp опции -p приводит к тому, что владельцем бэкапного файла становится $sudouser (обычно root), а не тот юзер, у которого был оригинал. И дата выставляется текущая, так что потом определить, какая дата была у оригинального файла, будет уже невозможно.
Но самый идиотизм оказался в проверке успешности копирования. Нормальные люди как проверяют, успешно программа сработала, или нет? Ага, по коду завершения. Причём он даже через ssh передаётся. А эти быдлокодеры проверяют выводимые данные. Если вывод пустой, то всё нормально, а если нет, то, типа, ошибка случилась..
Но поскольку это ж не просто cp, а внутри ssh, то выводимые ими данные склеиваются вместе. А на этом новом сервере в sshd_config‘е оказался Banner /etc/issue, вот он всегда и выводился, и потому эта идиотская софтина считала, что копирование не удалось.
Есть там и другие глупости. Например, authorized_keys2 перед выкладкой на удалённый сервер сначала генерируется на локальной машине, причём всегда в одном и том же файле в одной и той же директории. Так что если одновременно воспользоваться этой софтиной для раскладывания разных ключей в разные места (а это вполне возможно, если ей пользуются несколько администраторов, или даже один начинает работать над следующим сервером, пока ещё не закончилось выкладывание на предыдущий), то процесс основательно испортится.
Оригинал этой записи в личном блоге.
(
| Комментировать в Dreamwidth)