не, какой там территориально разделенный)
кто мне даст то так развернуться))
не, я больше смотрю на реальное существование на объектах, где сервера с Нго года обслуживались пару раз всего....
и часто есть такие где сервак можно просто взять и уйти в ребут, причем не про программной части)
99% объектов:
2 сервака, один другого стоят... оба на ладан дышут, перезапускаются от чиха мартовского кота в соседнем переулке, видел даже порты ethernet выгоревшие
замены ждать еще лет 50...
в таком случае из обоих серваков поднять один кластер, уж если кластер ляжет - то ляжет просто ВСЁ, а не так: тут что-то робит, а что-то нет
такую ситуацию я уже обкатал и вроде даже что-то живое и работоспособное получилось.
неее, с cifs это один единственный такой object, надеюсь таких больше не будет(хотя как оказалось проблема в DNS)
... прошу принять извинения за свои 5 копеек.
Честно говоря, с некоторым облегчением увидел строчки про "тонкое место" в виде ALD-сервера.
Ещё в мае 18-го, когда только начиналось наполнение этого ресурса участвовал в высказывании мысли о том, что подавляющему большинству коллег эти грабли в виде домена совершенно не нужны. За истекшее время уже были несколько раз "сработавшие" мины в виде этих "внедрённых" решений. И тут ваши обсуждения "за жизнь" в атмосфере ALD. Наши "наставники" до сих пор не научились ставить системы по -минимуму наверняка, ставить без деградации того, что было поставлено во времена "табуреткина"....
Жаль (несколько) что столько времени прошло, но "радует", что осознание пришло не к тем, кто принимает решение.
Ну да никто не отменял ни платья голого короля, ни того, что история учит только тому, что ничему не учит.
энти грабли нужны тока службе на три буквы, в начале З... пароли менять, права раздавать, админить можно все с одной машины из каропки
связистам и рядовым пользователям ПОФИГ откуда учетка, где хранится пароль и документы юзера, главное чтобы он мог с ними работать))
сам "программный" ald сервер готов работать хоть годами - тока правильно настрой.
вся проблема в старом и не обслуженном железе, которое устаревает все сильнее и сильнее, а новое не поставляют.
тот же доступ от вннис мог делать это, правда работал с пятое на десятое при определенных фазах планет и влияниях всех спутников солнечной системы...
p.s. такой случай касательно времени жизни тикетов...
машина работает 24\7, ald-renew-tikets on, почему все равно через 7 суток надо перезаходить на ЭВМ? на что тогда влияет ald-renew-tikets?
и как тогда автоматизировать обновление принципалов и тикетов?
ald-renew-tikets был поставлен в on под логином root. (sudo ald-renew-tikets on)
"в правильно поставленном вопросе уже половина ответа"
Это надо не "трём_буквам" на "З" Это надо даже не трём буквам на "Ф", хотя они здесь хорошо "покувыркалисть". Зхх было достаточно продукта от НПО Марс. Да и то что пришло совсем не замена тому, что было. Даже с учётом хрени с тикетами.
Для меня вопрос не в том, что АЛД "работает...", а в том, что потребуется, если он ляжет. Это называется "мина замедленного действия". Они уже несколько раз сработали. Так что...
Начальники мечтают, что в нашей системе никогда не будет ситуации как с коронавирусом, хотя за то, чтобы не мечтать они и получают деньги...
*в сторону*
Вопрос не в том, что IPv4 работает, а в том, что делать, когда диапазон закончится...
Вопрос не в том, что АЭС работает, а в том, что делать, когда взорвется реактор...
Вопрос не в том, что атмосфера работает, а в том, что делать, когда мы окажемся на Марсе...
Вопрос не в том, что... Attention! Module-of-rhetorical has been crashed... Segmentation fault...
это что надо такое сделать, чтобы в локальных сетях закончилось Ipv4? (про глобалнет сейчас не говорим)
по второму - тикать оттудова, да побыстрее ветра
по третьему - а мы там точно будем?
четвертый - смотреть какой прием был использован в логах перед падением
а вы думали))))
с других стороны карантина(при котором государство берет на себя заботу, чтобы народ не помер от голода) нет. выживать то людям надо))
я сам сдал тест, правда пришлось сказать, что мол видел одного заражённого по телевизору и я с ним в одном автобусе ехал, просто так хрен кто тестирует, даже за деньги... вердикт - не болен. пока что... так как что будет 19.04 + 2 недели инкубации - представляется мрачные дни...
Кто-нибудь настраивал почту с ALD и SSL? У меня что-то не получается.
Настроил в Astra Linux SE 1.6 электронную почту с аутентификацей GSSAPI в домене ALD согласно руководству администратора РУСБ.10015-01 95 01-1. При выключенном SSL сообщения приходят и уходят — всё хорошо. При включении в Thunderbird STARTTLS для сервера входящей почты подключение к серверу завершается с ошибкой, в журнале Dovecot фиксируется сообщение:
Код:
Jun 01 15:42:31 imap-login: Fatal: FATAL_ERROR: failed to set MAC for fd_ssl (fd_ssl = 8 pid=17693, fd_ssl_lev=0 Operation not permitted)
Все действия производятся в нулевом мандатном контексте.
Здравствуйте. Пытаюсь поднять почту по https://forum.astralinux.ru/threads/84/page-22#post-11492 руководству выше с 22й страницы и рук. админа, перепробовал как мог и вынужден задать вопросы. AL SE 1.6 без ald на виртуалке, делаю минималку с PAM (и в случае непонимания ставлю иногда shadow).
Итак:
1) В методике выше не сказано про auth-system.conf.ext в 10-auth.conf, а без него идёт ошибка "auth: FATAL: No passdb specified in configuration file. PLAIN mechanism needs one.". Если раскомментировать !include auth-system.conf.ext, а в самом этом файле passdb { driver pam } и userdb { driver = passwd }, вход происходит.
Но про это не было описано. В минималке должно работать без определения userdb passdb?
2) Почта по стандартному /var/mail/ - директории создаются с именем пользователя, uid/gid пользователя, права 700 со stick-битом. Кое как подключился через Thunderbird по руководству, в логе /var/log/dovecot/main.log спамит вот такое:
2020-09-21 15:26:05imap(username): Info: /usr/sbin/astrase-fix-maildir /var/mail/username
2020-09-21 15:26:05imap: Error: parsec_suid() failed: Operation not permitted
а в /var/log/dovecot/debug.log появляется 15 строк, последняя намекает как-то словами "maildir++" на такое же действие:
2020-09-21 16:31:17imap(username): Debug: Effective uid=1000, gid=1000, home = /home/username
2020-09-21 16:31:17imap(username): Debug: maildir++: root=/var/mail/username, index=, indexpvt=, control=, inbox = /var/mail/username, alt=
Команда astrase-fix-maildir делает все директории и файлы 3:0:2:0:CCNRA и 0:0:0:0:ehole в папке с почтой, но не могу найти где именно ей самой прав на выполнение не хватает. В консоли от этого пользователя команда проходит. После её выполнения через консоль ничего не меняется. Что делать для устранения ошибки? Почему она происходит? Про parsec_suid() вообще ничего не нашёл, видимо это вписано в давкот астровый.
to Iskatel
Много времени прошло с того мануала, виртуалок уже не осталось с результатами...
Собственно, там не пошаговка по настройке описана была, а основные моменты, не указанные в Руководстве администратора (часть 1, "защищенный комплекс программ электронной почты"). Посмотрите его внимательно, выполните все шаги совместно с моими записями. Должно заработать...
Кстати, конфигурацию dovecot лучше разбить на несколько файлов, как у меня указано. И для realm лучше использовать fqdn-имя домена, а не сокращенное и не localhost...
to Iskatel
Проверил у себя навскидку: Руководство администратора + мои записи по принципу "если опция указана и отсутствует в файлах по умолчанию - дописать; если присутствует - раскомментировать"...
Заработало все, но с правкой auth_username_format = %Ln вместо auth_username_format = %Lu. Судя по мануалу, эта опция отбрасывает "@имя_домена" при аутентификации. Подозреваю, что в этот раз (равно как и у вас) вся загвоздка в отсутствии настроенного DNS-сервера для резолва домена (у меня в примере - astra.lan). Читай, при настройке всех резолвов через правку /etc/hosts. Помнится, DNS-сервер всегда настраивал априори (NS-записи, MX-записи, все вот это, ага)...
И еще, там в конфигах мелкая ошибка: auth_default_realm, а не auth_default_realms...
Благодарю. Для посылки письма себе же и пользователям своей сети помогло выставить Exim в настройке той базовой dc_relay_nets='192.168.83.0/24;172.16.2.0/24', была неверная подсеть и я только разобрался как они работают, выставил нужную (83). Окончание realms было как надо, я вручную перепечатываю с другой виртуалки, а не копирую просто. Формат только %Ln нормально работал на PAM, но выяснилось необходимо делать на ALD всё-таки
и сейчас трудность с Kerberos'ом. Основная жалоба: While processing incoming data: Unspecified GSS failire. Minor code may provide more information.... Request ticket server imap/server.astra16.hom@ASTRA16.HOM kvno 8 not found in keytab, ticket is likely out of date.
При проверке в кейтабе kvno 9. При замене и повторе процесс повторился и там на единичку меньше чем в кейтабе он ожидает вечно. Эта ошибка чередуется с такой:
Код:
auth: Panic: file auth-request.c: line 862 (auth_request_is_disabled_master_user): assertion failed (request->request_login_user != NULL)
auth: Error: backtrace... /usr/lib/dovecot/dovecot.so.0 и куча вызовов с разными dovecot/auth
imap-login: Warning: Auth connection closed with 1 pending request.
auth: Fatal: master: service (auth): child 14461 killed with signal 6 (core dumps disabled).
imap-login: Info: Disconnected (auth process communication failure): user = <>, method=GSSAPI
Есть две виртуалки AL1.6. Поднял ALD, NTP, пользователи u1 и u2 входят в систему, обоим добавил доступ входа в обе виртуалки. Одна машина зовётся server (server.astra16.hom), другая client (client.astra16.hom). Сам кейтаб /var/lib/dovecot/dovecot.keytab доступен (getfacl'ен) и показывает свежие kvno (sudo klist -kt /var/lib/dovecot/dovecot.keytab). Консольно по нему инициализация идёт (sudo kinit imap/server.astra16.hom -kt /var/lib/dovecot/dovecot.keytab).
Чтобы в Thunderbird добавилась учётная запись долго бился, пока не обнаружил, что надо всего лишь оставить пустым поле пароля, и тогда он не будет пытаться его проверить и выкидывать ошибку "пароль не подходит, ведь disabled_plaintext стоит". Но сейчас при входе во u1@astra16.hom вкладку "входящие" говорит "Билет Kerberos/GSSAPI не был принят imap-сервером <astra16.hom>".
Настроил всё по руководству администратора 1, добавив imap/server.astra16.hom и smtp/server.astra16.hom в службы, дав им mac и mail. Конфиги вот:
VERSION = 1.7
DOMAIN = .astra16.hom
SERVER = server.astra16.hom
$TTL = 604800
@ IN SOA astra16.hom. root.astra16.hom. { 1410202001 604800 68400 2419200 604800 }
@ IN NS dns.astra16.hom.
@ IN mx 10 mx.astra16.hom.
; A блок
@ IN A 192.168.83.130
www IN A 192.168.83.130
dns IN A 192.168.83.130
mx IN A 192.168.83.130
server IN A 192.168.83.130
ntp IN A 192.168.83.130
kdc IN A 192.168.83.130
client IN A 192.168.83.133
$TTL = 604800
@ IN SOA astra16.hom. root.astra16.hom. { 1410202001 604800 68400 2419200 604800 }
@ IN NS dns.astra16.hom.
dns IN A 192.168.83.130
www IN A 192.168.83.130
130 IN PTR server.astra16.hom.
133 IN PTR client.astra16.hom.
Прежде чем задать вопрос, прочитал заново всю ветку, интернет, все инструкции и много пытался сам.
to Iskatel
Извиняюсь, каша у вас какая-то, из которой мало что понятно... Primo, ориентируйтесь на мой мануал в этой теме, в котором про 1.6 с учетом ALD. Насколько помню, там все четко по Руководству (за исключением описанных в мануале моментов)... Secundo, было два момента: если коннект идет по другому dns-имени, зарегистрированном в bind9 (например, по mx., а не по server.), то принципалы нужно создать и для этого имени тоже. И еще была бага с очередностью создания imap/smtp-принципалов ДО ввода всех машин в ALD-домен как раз с расхождением билетов Kerberos. Возможно, это ваш случай...
если коннект идет по другому dns-имени, зарегистрированном в bind9 (например, по mx., а не по server.), то принципалы нужно создать и для этого имени тоже.
- Wireshark'а нет в Астре, как вижу, не подглядеть.
- логи не помогли (/var/log/kerberos/kdc.log, kadmin_server.log, /var/log/dovecot/*,
- /var/log/syslog при попытке получения почты говорит только Parsec integrity level: 1
- /var/log/exim4/exim_main.log не может войти в свой logcheck@astra16.hom по 10 раз ежечасно, ему tmp/* не пермиттед
- Пересоздать принципалов imap/server.astra16.hom не помогло (Ваш вариант ещё одной баги).
- Затереть и сделать просто imap/astra16.hom без слова 'server' тоже (просто для исключения варианта). Принципалы под каждый сервер нужно создавать, понимаю.
Просмотр входящих в thunderbird встречает всё тем же "билет не был принят imap-сервером. Проверьте, что вы вошли в домен", что и у людей с конца 9 страницы данного топика.
В /etc/bind/zones/db.astra16.hom прописаны mx для реалма astra16.hom и для машины server.astra16.hom. Команды dig server.astra16.hom -t MX и host -t MX server.astra16.hom показывают наличие нужных записей (NS, MX, A).
Давкот работает - sudo telnet server.astra16.hom 143 -> a authenticate gssapi выдаёт +
Правда, после этого никакие команды не обрабатываются - list " * или select inbox и даже a logout все как ошибки показаны.