Удалённый логгинг (несистемный порт syslog)

Удалённый логгинг (несистемный порт syslog), UniFi Network

Frank_E

Guest

28.10.2015 13:22:00

Привет! Я включил удалённый логгинг в UniFi Controller (опция «Enable remote syslog server») с указанием хоста и нестандартного порта, после чего запустил профилирование USG и UAP. Но устройства всё равно пытаются отправлять данные на стандартный порт 514 (который не разрешён).

Посмотрев в /tmp/system.cfg на устройствах, я не вижу того нестандартного порта, который указал в контроллере:

"syslog": { "global": { "facility": { "all": { "level": "notice" }, "protocols": { "level": "debug" }}}, "host": { "REMOTEHOST": { "facility": { "all": { "level": "notice" }, "protocols": { "level": "debug" }}}}}

Либо я чего-то упустил, либо контроллер не передаёт правильную конфигурацию устройствам. Кто-нибудь использует удалённый логгинг с нестандартным syslog-портом?

С уважением,
Фрэнк

mwahlert

Guest

21.05.2017 16:10:00

Controller: 5.4.15
USG: 4.3.41.4975503

Включение удалённого syslog-сервера с нестандартным портом всё ещё неправильно настраивает USG. Удалённый syslog-сервер добавляется в /etc/rsyslog.d/vyatta-log.conf, но к записи не добавляется нужный порт. Ручное изменение /etc/rsyslog.d/vyatta-log.conf с добавлением номера порта и перезапуск службы rsyslog даёт ожидаемый результат.

Я думал, это уже должно было быть исправлено?

lti-dan

Guest

11.02.2016 04:03:00

Обновление: прошивка USG версии 4.3.9.4843893 по-прежнему использует стандартный порт 514, несмотря на то, что в контроллере Unifi задан другой порт для логирования. Также спасибо @kaybeng за совет вручную редактировать файл /etc/rsyslog.d/vyatta-log.conf. Это действительно работает, но после перезагрузки настройки сбрасываются.

Frank_E Guest	#4 28.01.2016 07:09:00 Спасибо за решение проблемы, но надеюсь, что будет полноценное исправление, ведь теперь UBNT официально признала этот баг.

Frank_E Guest	#5 28.01.2016 07:06:00 Да, именно в этом и проблема.

kaybeng Guest	#6 28.01.2016 00:52:00 @Frank_E, возможно, стоит попробовать добавить порт удалённого syslog-сервера в файл /etc/rsyslog.d/vyatta-log.conf и перезапустить службу rsyslog. https://community.ui.com/questions/f4eca6ca-398b-446e-8896-1a1239193245

lti-dan

Guest

27.01.2016 19:37:00

Вот в чем проблема, которую я вижу. На этом самом «сайте» у меня есть syslog-сообщения с моделей U7LT (AP-AC-Lite), U7E (AP-AC, самая первая версия) и, кажется, US24P250 — все они используют свой порт для syslog, а вот USG3 работает на стандартном (514).

UI-Team

Guest

27.01.2016 19:10:00

@Frank_E,

Мы проверили пользовательский порт и на точках доступа, и на USG с версией 4.8.12. Точки доступа показывали данные правильно, а USG не сообщал на пользовательский порт. Это та проблема, с которой вы столкнулись?

UI-Team Guest	#9 27.01.2016 16:40:00 Привет, @Frank_E, Я сейчас проверю этот вопрос и скоро вернусь к тебе с ответом.

Frank_E

Guest

#10

27.01.2016 13:24:00

В прошлую пятницу я наконец-то получил ответ от поддержки (ура, всего три месяца ожидания), и мне посоветовали попробовать последнюю прошивку, чтобы посмотреть, поможет ли это. Сюрприз: нет, бета-версия 4.8.12 всё ещё содержит эту проблему.

lti-dan

Guest

#11

26.01.2016 18:02:00

Я тоже с этим столкнулся. Я установил пользовательский порт для логирования через контроллер Unifi (v4.7.6) для одного сайта, и большинство устройств теперь используют этот кастомный порт, но USG на этом сайте всё ещё отправляет логи на 514 порт. Ниже приведён соответствующий фрагмент конфигурационного файла, IP-адреса замаскированы:

X.X.X.X:
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
host X.X.X.X {
facility all {
level notice
}
facility protocols {
level debug
}
}
}

Кажется, что можно было бы собрать это локально на USG и сгенерировать для него .json файл, но это должно быть довольно простое для воспроизведения багом.

P.S. Я не могу найти нужную команду в USG. По моему мнению, в этой версии (4.2.11.4796630) просто нет способа указать порт.

Frank_E Guest	#12 03.12.2015 10:27:00 Небольшое обновление по этой проблеме: с 29 октября команда поддержки Ubiquiti пытается подтвердить этот баг, но, к сожалению, они так и не получили ответа от своей «внутренней команды». Может, кто-то из сотрудников Ubiquiti здесь поможет это ускорить?

Читают тему (гостей: 1)