OES 11 проблема со стартом.

[skoltogyan]

чото пробовали с "долгой загрузкой" ?

[Доменика]

чото пробовали с "долгой загрузкой" ?

Пробовали
Вариант 1.
Изменения ntp.conf

Код: Выделить всё

server time.yyy.zzz.ru   prefer iburst
server time2.yyy.zzz.ru  prefer iburst
server 127.127.1.0
restrict 127.0.0.1
restrict 172.16.14.0 mask 255.255.255.0 nomodify notrap
restrict 172.16.1.0  mask 255.255.255.0 nomodify notrap
restrict 172.16.0.0  mask 255.255.255.0 nomodify notrap


При старте ни каких изменений. Остановка, якобы на старте NDS.

Вариант 2.
Изменения ntp.conf

Код: Выделить всё

server time.yyy.zzz.ru   prefer iburst
server time2.yyy.zzz.ru  prefer iburst
server 127.127.1.0
restrict 127.0.0.1
restrict 172.16.14.0 mask 255.255.255.0 nomodify notrap
restrict 172.16.1.0  mask 255.255.255.0 nomodify notrap
restrict 172.16.0.0  mask 255.255.255.0 nomodify notrap


Плюс изменения в hosts. Добавлена строка указывающая на сервер с репликой.
Старт происходит быстро, но NDS не запускается. И приходиться делать больше телодвижений, чтоб привести сервер в рабочее состоянии.
Строку из hosts убрана.
Изменения в ntp.conf оставлены.
Сейчас именно такая диспозиция.

[skoltogyan]

а пробовали , если такое возможно, ограничить список сетевых интерфейсов, к которым привязывается nds , например
- только "lo"
или
- только "lo" и "eth0"(аппаратным езернет интерфейсов с ipадресом, статическим(если таковой есть)).
как при этом будет происходить запускание edir ?
?
+
такой еще вариант - изменить(перепрописать) последовательность запуска сервисов( в oes11 вродк initV, а гне systemd ) , типа как в доке SLES
говорится:
https://www.suse.com/support/kb/doc/?id=000016866

или еще в этой ветке обсуждается как это сделать:
https://serverfault.com/questions/17605 ... boot-order

что-бы ndsd стартовало точно после поднятия сети и службы синхронизации времени.

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

В двух словах если:
1. LDAP не стартует из-за того, что время, внезапно, прыгает назад на три часа - у любого сервиса, использующего SSL, при этом точно "дернет крышу"
Dimerson: не стартует именно LDAP, сам едыр - в порядке, он запускается и работает. Ну мы же помним, что через всякие UNIX socket умеет работать, т.е. сетевой интерфейс ему самому для работоспособности вроде как и никак не нужен? LDAP, к слову, тоже умеет - но вот он как раз без интерфейса не работает никак.
2. С сетью проблем нет, проверять разрешение имен и прочее смысла не вижу. Надо понять, что не так с временем.

Не помню, как оно там было в SLES11 по части настройки NTP, потому спрошу: если в YaST -> System ткнуть в Date and Time, там, часом, не стоит галка "Hardware clock set to UTC"? Прыжок назад на 3 часа - это ровно из GMT+3 мы возвращаемся в GMT...

Не надо трогать никаких hosts и порядок загрузки - тут Вы рискуете налететь на то, что все, что от eDirectory зависит, заматерится хором... Разбирайтесь со временем.

Я бы убрал из конфига 127.127.1.0, всякие рестрикты, оставил бы только пару внешних NTP-источников в сети (ну или три). И 127.0.0.1 - тоже к аллаху. Чем решение проще, тем оно надежнее. VMware Tools можно и нужно вообще вынести, сама VMware миллион лет как рекомендует использовать open-vm-tools из состава дистрибутива.

[skoltogyan]

imho - подобную проблему обсуждают и решают
https://community.microfocus.com/img/oe ... and-reboot
копипаст текста оттуда:

OES 2015sp1 ndsd very slow to start after updates and reboot
frickc over 4 years ago
4-5 minutes

OES2015sp1/SLES11sp4 on VMware 6.5
Online updates installed last night - last updated in Nov 2017.
After update install finished - server was rebooted - as required.
After reboot - very slow starting
Stalled for a long time at Executing customized settings after starting the NetIQ eDirectory server…
Then shows:
Starting Novell Storage Services (NSS)
..dead
..dead
..dead
nss: ERROR: required eDirectory(ndsd) is not running. Exiting.
………. ABORTING /sbin/rcnovell-nss ……….

I suspect a time issue.
When server restarts messages log shows UTC time which then reverts to Eastern (-04:00) soon after.
This setup is configured the same as other sites that are running OES11sp2/SLES11sp3 on VMware 5.5 with respect to all time settings - that I can find.

Any thoughts?
Thanks
Tags:

Mathias Braun

There are quite a few things which can go wrong as for time stuff, most them get evident when a box gets rebootet after a shift to or from DST. But before chasing in this direction: did the server certificates expire by chance?

frickc

Server certificate is good.
Additional info:
After 4 hours elapsed novell-named started (when it caught up to the time showing in the log just after restarting)
I manually started novell-nss in the morning without any problem.

Mathias Braun

Things to check:
- make sure that the hardware clock(s) of the ESX host(s) is / are set to UTC
- make sure the virtual bios clock of the VM is the to UTC
- in /etc/sysconfig/clock check for HWCLOCK="-u", SYSTOHC="yes" and the proper timezone
- in /etc/sysconfig/ntp check for NTPD_FORCE_SYNC_ON_STARTUP="yes" and NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes"
(of course assuming a reliable ntp source)

maybe you don't have a chance to bounce the entire host right now, but at least you can
- make sure ntp is configured properly and syncing (if not -> configure it to do so)
- stop ndsd
- stop ntpd
- make the changes to the sysconfig files
- down the VM
- configure the VM to start into the virtual bios on the next startup
- start the VM, make sure bios time is set to UTC, save the changes
- let the VM boot

frickc

Thanks for the info.

I have never set this before
" in /etc/sysconfig/ntp check for NTPD_FORCE_SYNC_ON_STARTUP="yes" and NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes" "
but I will give it a try.

Everything else, except checking with the VM BIOS, is OK.
Time is showing correctly everywhere I look.

It may be a few days before I get a chance to reboot the host server or the VM.

Mathias Braun

All these items (VM BIOS is vital, too) will help to avoid that eDir initialization falls into a gap where the system time is simply wrong. The latter would (depending on your timezone (really)) cause stuff such as VERY delayed init of ndsd, ndsd skipping SLP registrations on every 2nd. cycle and little purple monster creeping around in the racks.

frickc

Thank you Mathias for pointing me in the right direction.
I had a chance to reboot the host and the guest last night.
The guest VM BIOS time was 4 hours fast. The difference between UTC and current local time.
Somewhere in the initial setup the VM BIOS must have got local time instead of UTC.
OES server boots normally now and all services start as required.
Regards,
Chris

Mathias Braun

Good to hear, thanks for reporting back.

[Доменика]

imho - подобную проблему обсуждают и решают
https://community.microfocus.com/img/oe ... and-reboot
.....

Что сделали
- в ntp.conf заменили имена серверов на ip-адреса этих серверов
- установлен потерянный атрибут DNIP:ServerIPAddress для объекта DNS_server
И заработало.

Попытки прописать или удалять NTPD_FORCE_SYNC_ON_STARTUP="yes" and NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes" - на результата не влияют.
При записи в hosts данных по серверу с репликой на окончательный результат влияние не оказывает, как было раньше. Может старт самой NDS проходит быстрее. Но может это и субъективно.
Все изменения в ntp.conf сделанные ранее оставлены.
В логах время не скачет.

Вопрос ......закрывается!

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

Видимо, DNS этому серверу был указан он сам? Тогда NTP просто не мог найти сервера времени. Как только время устаканилось - все, внезапно, заработало. Поздравляю.
И что-то при обновлении Вы упустили/сделали не так: атрибуты у объектов сами по себе не теряются. Проверьте, на всякий случай, логи обновления, там может еще что-нибудь обнаружиться.

[Dimerson]

Иван, в данном случае помогает грамотно составленный /etc/hosts

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

Вне всякого сомнения. Я обычно NTP указываю айпишниками. "Во избежание", так сказать

[Доменика]

Иван, в данном случае помогает грамотно составленный /etc/hosts

Пример - происходит смена сервера или консолидация на который Вы сделали ссылку в host.
Как Вы представляете изменения при наличии нескольких десятков серверов.
Наполнения host чем-то оригинальным - это экстраординарные случай. Или при отсутствии серверов DNS.

[Доменика]

Вне всякого сомнения. Я обычно NTP указываю айпишниками. "Во избежание", так сказать

Имеется эталонный сервер времени или сервер с репликой.
При проблеме можно сделать быстрое переназначения используя CNAME. И через 5 минут работа в сети нормализуется.

При разборе полётов по проблемному серверу были выявленные несколько неприятных моментов в настройках.
Так в настройках nds.conf альтернативный сервер смотрел своим ипишников на то что было убрано их сети несколько лет назад.
Может именно по этой причине IP хорошо, а CNAME - это правильная альтернатива.

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

Оба подхода, на самом деле, имеют право на существование. И в том, и в другом случае есть плюсы и минусы. Лично моя практика: DNS - для веб-сервисов и всякого прикладного, с чем работают пользователи, IP - для инфраструктуры (к которой я всегда отношу и NTP). DNS - лишний уровень абстракции, добавляющий сложности в систему. Просто в силу этого общая надежность решения, на мой вкус, страдает.
При этом, повторяю, я не могу сказать, что использовать DNS для указания адреса NTP-источника - неправильно.
IP-адреса там, где я к настройке и управлению имею доступ/отношение, меняются крайне редко, серверный и пользовательский сегмент жестко разделены и не пересекаются никак вообще. Смена IP-адреса - это вообще огромная боль, если говорить, например, о eDirectory (да и кроме него есть еще масса сервисов, где прям надо полсистемы перековырять, чтобы заработало). Неработающий DNS я лично вижу чаще, чем смену IP-адреса. Ровно на этих соображениях моя личная практика и базируется.