Я выполнял rsync и случайно отменил команду, так что он перезаписал кучу файлов с нашего резервного сервера на основном сервере.
Сервер резервного копирования находится в chroot jail, поэтому он перезаписал эти файлы:
bin dir:
bash chroot-jail cp ls mkdir mv rm rmdir sh su
dev dir:
null tty urandom zero
каталог lib:
pam_access.so pam_ecryptfs.so pam_issue.so pam_listfile.so pam_passwdqc.so
pam_rps.so pam_tally.so pam_unix_auth.so
pam_ccreds.so pam_env.so pam_keyinit.so pam_localuser.so pam_permit.so pam_securetty.so pam_tally2.so pam_unix_passwd.so
pam_chroot.so pam_exec.so pam_krb5 pam_loginuid.so pam_pkcs11.so pam_selinux.so pam_time.so pam_unix_session.so
pam_console.so pam_faildelay.so pam_krb5.so pam_mail.so pam_postgresok.so pam_shells.so pam_timestamp.so pam_userdb.so
pam_cracklib.so pam_filter pam_krb5afs.so pam_mkhomedir.so pam_pwhistory.so pam_smb_auth.so pam_tty_audit.so pam_warn.so
pam_debug.so pam_filter.so pam_lastlog.so pam_motd.so pam_rhosts.so pam_stack.so pam_umask.so pam_wheel.so
pam_deny.so pam_ftp.so pam_ldap.so pam_namespace.so pam_rhosts_auth.so pam_stress.so pam_unix.so pam_xauth.so
pam_echo.so pam_group.so pam_limits.so pam_nologin.so pam_rootok.so pam_succeed_if.so pam_unix_acct.so
lib64:
ld-linux-x86-64.so.2 libaudit.so.0 libcrypt.so.1 libglib-2.0.so.0
libpam.so.0 libresolv.so.2 libsepol.so.1 libz.so.1
libacl.so.1 libc.so.6 libcrypto.so.6 libkeyutils.so.1 libpam_misc.so.0 librt.so.1 libtermcap.so.2
libattr.so.1 libcom_err.so.2 libdl.so.2 libnsl.so.1 libpthread.so.0 libselinux.so.1 libutil.so.1
sbin:
unix_chkpwd
После этого на нашем основном сервере теперь я могу войти только как root, ни одна из дополнительных учетных записей не работает, поскольку разрешения, похоже, полностью испорчены. Apache только обслуживает 403 страницы и т. Д. Есть идеи, как я могу это исправить или система закрыта?
Учетные записи по-прежнему отображаются в passwd и shadow.
В будущем вы, возможно, захотите изучить rdiff-backup как альтернативу rsync. В частности, поскольку rdiff-backup имеет флаг только для увеличения существующей резервной копии, по крайней мере, тогда риск повторения исчезнет.
Как говорит Билл Вайс, возможно, вам будет проще и безопаснее выполнить восстановление из заведомо исправной резервной копии в чистой системе. Вы не только испортили разрешения, но и заменили файлы. Даже если исходная и целевая машины были одним и тем же дистрибутивом, нет гарантии, что они будут идентичными файлами, а это может вызвать всевозможные дурацкие проблемы.
Если вы чувствуете, что должны попытаться восстановить, я думаю, что есть два способа сделать это. Первый - использовать диспетчер пакетов вашего дистрибутива для принудительной переустановки пакетов, в которых находятся затронутые файлы. Второй - более ручной подход:
Вы мощь затем обнаружите, что у вас снова есть рабочая система, но я бы не стал ей доверять, и, вероятно, это займет больше времени, чем путь очистки / восстановления.
Вот полезная команда, которую вы можете запустить в списке полные пути затронутых файлов, чтобы получить список затронутых пакетов (Debian / Ubuntu):
for a in `cat files.txt`; do dpkg -S $a |cut -d':' -f1; done |sort -u