Привет всем!Вся пляска вокруг BackupPC.
Итак, было:
1. Операционные системы RFR-14 на хосту в центральном оффисе (PDC) и RFR-15 (соответственно с самбами) на ремутном хосту (BDC).
2. И там и там поднят был BackupPC, для бэкапов юзерских данных с их рабочих станций (под оффтопиком.
Эта конфигурация - работала.
Стало:
1. В центральном офисе ось изменилась на CentOS 6.3. Самба подняла верию до 3.6.10.
2. В ремутном офисе самба осталась прежней версии - 3.5.15-74.fc15 (соответственно на федоре 15).
3. Конфиги самбовые - не менялись.
Проблема:
Отвалилась возможность бэкапить виндовые станции ремутного офиса средствами BackupPC. Поскольку этот пакет пользует smbclient'а, то исследуем его:
1. Проверяем регистрацию клиента на оффтопике:
Консоль:
# smbclient -L sclad -Uroot
Server's Role (logon server) NOT ADVISED with domain-level security
Enter root's password:
Domain=[ALMANEW] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
IPC$ IPC Удаленный IPC
print$ Disk Драйверы принтеров
ADMIN$ Disk Удаленный Admin
C$ Disk Стандартный общий ресурс
Domain=[ALMANEW] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Server Comment
--------- -------
Workgroup Master
--------- -------
Видим, что работает, список шар получаем. Пробуем зарегистрироваться на шаре C$ (с целью её последующего бэкапа:
Консоль:
# smbclient //sclad/C$ -Uroot
Server's Role (logon server) NOT ADVISED with domain-level security
Enter root's password:
Domain=[ALMANEW] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
tree connect failed: NT_STATUS_ACCESS_DENIED
То есть видим, что аутентификация доменного юзера "root" (а он является админом домена) успешна, но доступа к системной шаре у него нет. Абыдно.
При этом - если конектится к системым шарам рабочих станций центрального оффиса, то все намано. Получаем нужный доступ и можем бэкапиться. А вот в ремутном офисе - обломс.
====
Хотя, уточнение - в центральной лавке бэкапы проводит юзер вписанный в 2000-ный честный домен. А вот в ремутной - компьютеры стоят уже в самбовском домене и им - обломс выходит.
Да, и в центральном тоже - обломс. Если юзерский комп центрального офиса с офтопиком стоит в самбовом, а не виндовом домене - те же ойцы: NT_STATUS_ACCESS_DENIED
===========
И еще. Если идем на компьютер административным юзером root, то получаем серпом по самые гланды. А вот если идем на тот же компьютер обычным доменным юзером, то smbclient нормально на компьютере к системной шаре цепляется.
Коллеги, подскажите, где могла собака зарыться? Как её откопать?
-----------------------------
еще чудеса нашлись. Есть у меня в самбе пара административных аккаунтов, admin и administrator. Так вот с ними - еще забавнее. Входят на офтопичный компьютер только со второй попытки. После первой - тот же NT_STATUS_ACCESS_DENIED... А вот административный юзер root - тот ни со второй попытки не может, ни с третьей...
ЗЫ. строчка Server's Role (logon server) NOT ADVISED with domain-level security на том сервере жила всегда. Как от неё избавиться - не знаю. Но она (раньше) не мешала проводить бэкапы.
***********************************
Сам себе злобный буратин. Когда ставил новые сервера, то поставил их на новые IP-адреса. А юзерские компьютеры искали WINS по старым записям. Обновил настройки на юзерских компах, всё заработало. Вот только одного не могу понять (найти в Интете), как правильно надо настраивать самбу+winbind, чтобы иметь территориально распределенный домен, когда PDC стоит в центральном офисе, а BDC раскинуты по ремутным филиалам (каждый со своей IP-сетью). И, соответственно связь по openVPN+TUN-интерфейс.]]>