Почему блокируется учетная запись root при попытке сброса пароля?
Доброго времени суток! Есть такая проблема, при сбросе пароля на CentOS 5.6, работающей под управлением гипервизора Xen, блокируется учетка root. При чем она блокируется при любых способах сброса. Пробовал и в shadow удалить хеш, и подцепится chroot и задать новый - passwd root. Пароль меняется, проверял в /etc/shadow, тоже там появлялся хеш пароля, но после перезагрузки при удалении пароля и при его смене с Chroot войти не удавалась, опять подцеплялся с LiveCD, проверял хеш в /etc/shadow, там вместо хеша нового пароля или вместо ничего (при способе удаления) появлялось два восклицательных знака (учетка заблокирована), а между ними два апострофа, то есть выглядело примерно так:
root:'!!': ..........
Насколько знаю, учетка заблокирована - это просто два !!, а если между ними два апострофа, это что значит? другие способы вообще не подошли, такие как
1) xm shutdown
xm create -c
прописать в первой строке загрузки pyBRUB -> e -> kernell -> e -> init=/bin/bash или /bin/sh (пробовал оба) -> Enter -> b. Пишет , хотя в initrd она есть, точно проверено. Еще пробовал прописать init=/bin/bash или /bin/sh (пробовал оба) в brub.conf. Та же песня.no such file or directory.
2) прописать single mode так же в pyGRUB или в grub.conf. При загрузке single mode требует пароль от root:
Give root password for maintenance (or type Control-D to continue):
При нажатии Control-D просто загружается как обычно и требует ввести имя пользователя и пароль.
Кто-нибудь сталкивался с подобной блокировкой? Подскажите пожалуйста?
Кстати я подумал, что может это я криворукий лопушара и блокирую его после перезагрузки сам неправильно вводя его и специально попробовал сбросить chroot'ом перезагрузиться, дождаться загрузки всех виртуалок, затем не пытаясь войти в виртуалку к которой я сбросил пароль снова перезагрузиться с LiveCD, и посмотреть заблокировалось ли? И да оно заблокировалось - '!!'. Что интересно новый пароль записывается после перезагрузки в файл /etc/shadow- (shadow с черточкой), а в etc/shadow (без черточки) '!!'.
Руслан Федосеев: Я в курсе, что это предыдущее состояние, так сейчас и стоит задача найти где он меняется, в /etc/rc* ничего не нашлось необычного. искал так: find /usr/ /etc -maxdepth 3 -type d -name xen\* | xargs grep -rl /etc/shadow и так: grep -rE 'shadow|passwd' /etc/rc*. И еще вручную искал.
Это только на одном сервере так или на всех?
Если на одном, значит это не штатные средства, и надо искать, где это срабатывает.
Это может срабатывать:
1. При загрузке, не уровне initrd. Можно попытаться загрузиться без initrd, взять initrd с другого сервера или пошариться на текущем.
2. При загрузке, на уровне startup-системы. Тогда надо искать по init-скриптам, особенно обратить внимание на /etc/rc.*. Может быть ещё в pam. Маловероятно, но я бы проверил.
3. На этапе shutdown. Тоже искать по скриптам startup-системы.
Никогда не сталкивался с подобными проблемами в Xen, но вот в ESXi настройки dom0 хранятся "своеборазным" образом. Директория /etc упаковывается в тарбол и при загрузке этот тарбол разворачивается поверх /. Соответственно, чего там ни делай с LiveCD - пароль рута все равно будет другой.
Мб в Вашем случае нечто подобное имеется?
Простой
