Помогите разобраться с проблемой!!!

[BDmV]

Есть 3 OES сервера:
Сегодня обнаружил, что на основном сервере через iManager не могу создать пользователя, а на другом пользователь создаётся без проблем, но в сеть войти не может.
iMonitor показал, что Master реплика не синхронизируется (ошибка 6003).
Тут же запустил "Repairing replica ring" - ситуацию это не спасло.
Запустил "Repairing Local Database" и теперь при попытке войти в iMonitor на сервер с Master репликой получаю ошибку "Invalid credentials. Please Re-enter."

Replica Status
Read/Write Replica .ISERVER.fino.VIDNOE. On 3 05/24/25 08:17:18 553:48:58 0:05:46 06/03/25 01:49:39
Master Replica .server7.fino.VIDNOE. On 1 05/24/25 08:17:18 0:00:00 553:54:45 06/03/25 02:09:33 Remote Error -663 .VIDNOE. 0000801E
Read/Write Replica .server6.fino.VIDNOE. On 4 05/24/25 08:17:18 553:54:44 0:00:00

DSRepair.log

Repair utility for NetIQ eDirectory 9.0 - 9.2.4 v40205.00, DS 40205.00.

** Automated Repair Mode **
Repairing replica ring
Start: Вторник, Июнь 03, 2025 12:14:47 Local Time

Replica Ring for replica: .[Root].
Remote server's local ID: 00008035
Remote server's replica root ID: 0000801d
Remote server name is: .ISERVER.fino
OK - Authenticated to server
Remote server's local ID: 00008033
Remote server's replica root ID: 00008031
Remote server name is: .server7.fino
OK - Authenticated to server
Remote server's local ID: 0000872b
Remote server's replica root ID: 0000801e
Remote server name is: .server6.fino
OK - Authenticated to server

** Automated Repair Mode **
Finish: Вторник, Июнь 03, 2025 12:14:47 Local Time
Total repair time: 0:00:00

/****************************************************************************/
Repair utility for NetIQ eDirectory 9.0 - 9.2.4 v40205.00, DS 40205.00.
Repairing Local Database
Start: Вторник, Июнь 03, 2025 12:30:15 Local Time

** All disk amounts are approximations **
Disk space currently available: 36665 MB
->DSRepair may need to use: 385 MB
->Disk space remaining after operation: 36549 MB

Current transaction ID is 0 (0x0). Allowed limit of transaction is 4294959104 (0xffffe000)
NOTICE: Unable to update repair status. Error: -663

Repair process aborted

Места в корне, вроде хватает.

server7:/etc # df -h
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
devtmpfs 16G 0 16G 0% /dev
tmpfs 16G 196K 16G 1% /dev/shm
tmpfs 16G 1,6G 15G 10% /run
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/sda2 66G 30G 35G 46% /
admin 4,0M 0 4,0M 0% /_admin
/dev/pool/DATA_POOL 1,9T 1,8T 116G 94% /opt/novell/nss/mnt/.pools/DATA_POOL
/dev/pool/WORK 3,7T 1,9T 1,8T 52% /opt/novell/nss/mnt/.pools/WORK
DATA 1,9T 1,6T 116G 94% /media/nss/DATA
WORKDATA 1,9T 159G 116G 58% /media/nss/WORKDATA
TWDATA 3,7T 1,9T 1,8T 52% /media/nss/TWDATA
tmpfs 3,2G 16K 3,2G 1% /run/user/1000
tmpfs 3,2G 0 3,2G 0% /run/user/0

Подскажите, пожалуйста что ещё можно предпринять чтобы доступ восстановить?
Перегружать сервер не рискую, вдруг не поднимется?

[Dimerson]

Удалить eDir с сервера и по новой ввести в дерево. Реплики другие же же живые. Все подтянется с них. Хотя подождите других коллег.

[Иван Левшин aka Ivan L.]

Объяснение - всем объяснениям объяснение. Что происходило до того, как проблема была обнаружена? Error -663 - это DS_LOCKED, ndsd не может базу открыть из-за блокировки. Причин - миллиард, гадать устанем гарантированно.
В частности, сервер могли дернуть по питанию, остался старый PID-файл. Или lck висит в dib. Много чего, в общем, может быть причиной блокировки.
"Удалить и вставить" тут не поможет, заклинило мастера. Сначала надо его передать на RW - при этом очень желательно, чтобы RW таки были в живом состоянии, а то на похохотать хватит всем с запасом. Без предварительной передачи мастера на RW синхронизация в кольце просто не сойдется и привет.

Все описываемые спецэффекты в духе "не могу зайти в сеть" легко объяснимы: при заблокированной базе доступ к ней получить вряд ли можно, а данные для аутентификации, авторизации и прочего интересного - все в ней. Разбирайтесь с блокировкой.

Перегружать ничего не надо. Восстановите, для начала, что случилось с сервером. И покажите, что у Вас в /var/opt/novell/eDirectory/data/dib из файлов. ls -la оттуда покажите.
Вот Вам еще сборник кодов ошибок, стащил, пока его наноинноваторы не похерили... Очень полезный файлик, многократно выручал...

[BDmV]

Иван. Мне не до смеха
В прошлый раз все решилось после dsrepair -R и перезагрузки сервера. в этот раз таже самая проблема. (только тогда проблемы были только с управлением eDir, в это раз пропал доступ к CIFS и NSS)

Может подскажите, как понять из-за чего на ровном месте ложится мастер?
И что в этом случае можно предпринять?

ЗЫ. Или на какой софт можно уйти с OES? (желательно аналогичный по управляемости, но не AD) (нужен чисто файл сервер + почтовый сервер)

ЗЗЫ. Как-то в NW5.1, NW6.5 всё было понятнее и логичнее для меня, чем в этом SLES+OES

[Иван Левшин aka Ivan L.]

Дмитрий, я и не смеюсь. Я недоумеваю. Вы не даете никакой информации, но просите совета - как, полагаете, мы можем что-то посоветовать, когда Вы - там, мы - тут и нам отсюда не очень хорошо видно, что у Вас там происходит?
OES в текущей версии ничуть не хуже по надежности, чем нетварь, по функционалу сравнивать уже давно нечего - хотя бы потому, что ту же проблему многопроцессорности в нетвари до конца так решить и не удалось, в последних версиях не так много приложений в принципе могли использовать несколько процессоров.
Если ndsrepair -R и перезагрузка помогли, я бы предположил, что что-то не так с дисковой подсистемой. Вероятно, даже перезагрузка не была нужна, достаточно было бы сделать systemctl restart ndsd.
Что у Вас с CIFS и NSS - я не знаю, Вы одного бита информации по этим проблемам не предоставили, а гадать я давно уже отчаялся и перестал практиковать. Что именно не так с CIFS и NSS? Не стартуют (NSS вообще работает на уровне ядра, там все должно быть прям очень заметно), стартуют, но нет томов, тома есть, но недоступны по сети? Ошибки какие-то, сообщения и т.д.?
Для того, чтобы понять, что с Вашим мастером, надо иметь очень сильно больше информации (логов), чем нам доступно прямо сейчас.
Чем заменить OES - не знаю, прямых альтернатив нет. По части каталога - смотрите FreeIPA/АЛД Про, мне лично оно показалось интересным. Хотя я очень и очень сомневаюсь, что оно реально в состоянии заменить eDirectory в промышленной эксплуатации под нагрузкой в 1000+ активных пользователей - лично не тестил, но вот сомнения меня не отпускают. По части файловой системы: BTRFS, XFS выглядят интересно, но убогие права доступа - это приговор. NSS был, есть и будет лучше всего, что придумают во фрюниксе до тех пор, как минимум, пока они будут использовать эти их дурацкие "два притопа, три прихлопа" и наворачиваемыми поверх идиотизмами в духе setfacl/getfacl. По части печати взамен iPrint предложить, по моему, просто нечего - есть специализированный софт "за деньги", который, наверное, будет не хуже, но CUPS/OpenPrinting - точно нет, не конкурент и вряд ли им станет в перспективе ближайших лет 5-10.
GroupWise заменить можно, в сети полно примеров, как можно собрать почтарь из компонентов - не так удобно, как с ГВ, где "все в одном", но вот тут как раз пободаться есть чем. К сожалению, после того, как новель слили, GW почти не уделяли внимания и он, по моему мнению, в глубоком застое. При этом, на мой вкус, он даже в этом состоянии остается одним из лучших решений для организации почты, которое просто работает годами.
Все, конечно - мое глубоко скромное (и, наверняка - ошибочное) оценочное суждение.

По части "нетварь была лучше" - нет, она не была лучше. Она была проще, в ней было кратно меньше сервисов и она кратно меньше могла. Просто почитайте документацию, там несложно, да и с имеющейся базой Вы точно с этим справитесь. Поймете, что OES сейчас - это не первый OES на базе SLES9, который и в самом деле был одним сплошным глюком и тогда нетварь, в самом деле, была лучше. Беда в том, что с тех пор прошло лет около 15, за которые все кардинально поменялось.

Еще раз: хотите помощи? Делитесь информацией. У Вас есть понимание того, когда именно случилась та или иная проблема? Начните с анализа /var/log/messages вокруг этой временной метки. Лог eDirectory, к сожалению, будет, скорее всего, малоинформативен, а вот общесистемный - хорошая стартовая точка.

[BDmV]

Иван, спасибо за информацию.
Теперь я знаю,хотя бы в каком логе пытаться найти информацию.
С CIFS и NSS как раз проблем и нет, до тез пор пока не ложится реплика.

А про NW я и не говорю что лучше, я говорю проще и понятнее. Меньше точек администрирования и мониторинга.

Еще раз: хотите помощи? Делитесь информацией. У Вас есть понимание того, когда именно случилась та или иная проблема? Начните с анализа /var/log/messages вокруг этой временной метки. Лог eDirectory, к сожалению, будет, скорее всего, малоинформативен, а вот общесистемный - хорошая стартовая точка.

В том-то и дело что нет. Всё работает штатно, пока не появляется необходимость залезть в iManager, где и выясняется, что в eDir ошибка 6003. и iMonitor тоже мне много полезного не даёт (читать его не умею)