Добрый вечер, летом решил по примеру добавить мониторинг портов, чтобы удобнее корректировать работы в удаленных офисах.
Из закладок как раз воспользовался упомянутым примером: habrahabr.ru/post/154723/
Сейчас еще не спеша обновляю ее, но уже работает с оригинальным LLD шаблонами. И можно добавить в интерфейс zabbix, выбирать группы, видно разницу между shutdown портами и link down, а также выводить чуть больше информации и еще по мелочи.
Но не будучи хорошим PHP программистом, не все пока красиво.
Идею со связаными устройствами, в частности отображение MAC адресов, я не добрался, но хотел бы переложить бы на трапы. Возможно для начала воспользуюсь вашим вариантом.
Master ветка, пока не обновляется, я недавно получил от автора последний вариант скриптов и еще не смержил.
Последний рабочий вариант тут: github.com/pioneerit/zabbix_switch_ports/tree/ver_0.2
Желающие воспользоваться и улучшить могут смело обращаться тут или через github.
Вполне интерестный вариант. Настройка доступов для GIT у нас происходить автоматически. Но все же интерестно, Jenkins обработал был переменную GIT_SSH из настроек окружения?
Тогда бы можно использовать wrapper для доступа. В скриптах я использую такой вариант:
А чем это отличается от описаного автором способа?
Возможно, что-то поменялось, я давно не добавлял домены. Но сейчас у меня больше 10 доменов подключено.
И все это значит, что у меня будет еще 10 алиасов, только вместо дургого имени, будет другой домен.
А кол-во пользователей не увеличивалось.
Я могу сделать еще 20 адресов в рамках одного домена. Для этого вы можете использовать группы или настроить алиасы. Я точно лимиты не помню, но предполагаю что их тоже по 10.
А вообще можете пересылать всю почту на несуществующий адрес в домене на вашу почту, и тогда комбинацией уже намного больше.
Есть вопрос. Как контролируете какие билды, на каких нодах выполнять?
Поведение по-умолчанию, запускать билд на свободной ноде.
Я знаю два варианта, явно указать в доп. настройках, опция «Restrict where this project can be run»
Или использовать Matrix проекты для сборок.
Сейчас кол-во слейвов не большое, так что пробую по немногу оба способа.
А у вас как?
Прежде чем «придумывать» минусы двухуровневой авторизации как в Google, лучше бы сначала ознакомились с ней.
Управляем авторизацией, в целом — https://accounts.google.com/b/0/SmsAuthConfig. В частности настраиваем доступ приложению Google Authenticator, чтобы не ждать СМС.
Управляем паролями для приложений, которые не поддерживают двухэтапную авторизацию, например на вашем Android — accounts.google.com/b/0/IssuedAuthSubTokens
Один минус который я могу предположить, что при отсуствии смартфона, вы зависите от СМС, но даже будучи в такой ситуации я нажал ссылку — не пришло СМС и мне на телефон позвонил робот и продиктовал код. Так что в плане ее реализации в Google, я не сталкивался с недостатками или проблемами.
Посредники. С хорошей базой больших клиентов. Разумеется вменяемые тарифные планы и техническая часть должны соответствовать. Но в целом, есть технические требования, дальше клиент волен выбирать шлюз который ему нравятся. В случае если вы используете СМС как сервис очень удобно.
На самом деле свои реализации работы через REST API, SOAP, HTTP и даже вставку в MySQL я видел у шлюзов, но всегда рядом радовало наличие SMPP. Я не очень люблю самописные велосипеды, особенно когда нет альтернативы. И удивился, что тут отсутствует упоминания об имеющемся протоколе SMPP.
Способ мало применим в другой стране и тем кто не хочет использовать SMSPilot.
Исходя из описания они работают, по какому-то своему протоколу поверх http, вместо использования SMPP.
Используя SMS шлюзы с поддержкой SMPP, вы можете вольно выбирать любой и переключаться, и даже резервировать оповещения. Давно использую самописный perl скрипт на 20 строк, для оповещения мониторинга, на основе Net:SMPP для оповещений и не жалею. При необходимости могу быстро подключиться к другому шлюзу, полезно если нужна отправка СМС в другую страну.
Обожаю chmod 777 –v –R *
Особенно когда copy-paste сделают, не вчитываясь, от "/"
Неужели так тяжело обучать работе в правами сразу? После таких мануалов десятки и приходится у горе пользователей систему восстанавливать.
В следующем примере статика будет прозрачно проксироваться с сервера в Hetzner и кэшироваться на российском сервере, таким образом повторная загрузка будет происходить только при изменениях на сервере в Hetzner.
К сожалению, вы не показали решение. Так что я не могу согласится с вашим конфигом. Не смотря на имеющееся дополнение про css. Максимум это «конфиг для проксирования статитики, а для обновления нужно обновить алгоритм построенние ссылок, для внесение хеша к измененным элементам». А это не малое упущение, иначе действительно еще один пример обычного конфига, с добавлением хеша, даже не через location, а через аргументы с добавлением IfIsEvil.
Я не имел ввиду, что нельзя подменить путь к favicon. Я не отрицал возможности добавление хеша и к изображением.
Я не нахожу ответа на самый обычный вопрос, который часто возникает вообще при кешировании.
У меня >80 Гб статики. Ваше предложение? Держать для каждой ссылки свой хеш?
Если, да, то если строить его по данным файла прибавить не мало i/o нагрузки. Не говоря о дополнительной части в изменении кода.
Есть второй 1 хеш для обновления сайта, как часто делают для css & js. Но если взять один хеш для всех изображений, то все что я хотел донести, при замене пару Кб простого favicon, у вас весь кеш станет не валидным и будет заново наполнятся заливая все 80 Гб.
Все это я описал сразу. И хочу услышать общее решение в этом случае, как управлять обновлением контента.
И сколько времени пройдет, после замены на сервере основном сервере /favicon.ico до его обновления в кеше?
Я не нашел в приведенном примере настройки или описания, что позволить обновить изображение, только аргументы для css.
Исходя из того, что после обновления сайта мы меняете хеш для всех css и возможно js, для медиа контента такой вариант не имеет смысла, хотя по вашему конфигу можно, иначе браузер заново загружает все изображения, а кеш заново наполняется.
Так, что я думаю 30 дней ждать обновления баннера или иконки это не совсем верный вариант. Как вы решаете эту задачу?
Urban Airship совсем другой размах. У меня меньше 10 пользователей, так что самый минимальный план уже перебор. А вот Basic план интерестно посмотреть.
7500 на каждое приложение. В данном случае я влажу в лимит. Если нужно будет немного больше, проблем разделить по пользователем не составит труда. А там возможно появится официальный прайс, который выйдет дешевле SMS.
От SMS целиком отказываться не буду. Для критических уведомлений точно оставлю.
Более года назад рассматривал Prowl для iOS уведомлений от мониторинга, App тоже платное. Но без поддержки Android, так и не решил использовать. Спасибо за наводку. 3.99 USD у меня отобьются очень быстро, после первых 200 уведомлений вместо SMS. А если учесть размер уведомлений, который часто больше 160 символов и того раньше.
Я бы с радостью прочитал статью, как переехать в облака за час.
На РИТ++ был интересный доклад "Почему вам еще рано в облако" от Clodo, рекомендую ознакомиться.
Мы обращаем внимание на облака. Но мы еще не готовы к работе в облаке. Одна из причин — у нас высокие требования. Сейчас у нас есть хорошо масштабируемый проект на физических серверах, ресурсы которых более контролируемы чем облачные ресурсы. Когда мы будем готовы, обязательно попробуем разместить часть проекта в облаке.
Из закладок как раз воспользовался упомянутым примером: habrahabr.ru/post/154723/
Сейчас еще не спеша обновляю ее, но уже работает с оригинальным LLD шаблонами. И можно добавить в интерфейс zabbix, выбирать группы, видно разницу между shutdown портами и link down, а также выводить чуть больше информации и еще по мелочи.
Но не будучи хорошим PHP программистом, не все пока красиво.
Идею со связаными устройствами, в частности отображение MAC адресов, я не добрался, но хотел бы переложить бы на трапы. Возможно для начала воспользуюсь вашим вариантом.
Master ветка, пока не обновляется, я недавно получил от автора последний вариант скриптов и еще не смержил.
Последний рабочий вариант тут: github.com/pioneerit/zabbix_switch_ports/tree/ver_0.2
Желающие воспользоваться и улучшить могут смело обращаться тут или через github.
P.S. Спасибо за напоминание про LLDP, нужно будет воспользоваться для построения карты — blog.zabbix.com/maps-for-the-lazy/2898/
Тогда бы можно использовать wrapper для доступа. В скриптах я использую такой вариант:
И клонируем:
Таким образом один общий ключ только на чтение нужных реп, на всех нодах. И нет проверок known_hosts.
Возможно, что-то поменялось, я давно не добавлял домены. Но сейчас у меня больше 10 доменов подключено.
И все это значит, что у меня будет еще 10 алиасов, только вместо дургого имени, будет другой домен.
А кол-во пользователей не увеличивалось.
А вообще можете пересылать всю почту на несуществующий адрес в домене на вашу почту, и тогда комбинацией уже намного больше.
Поведение по-умолчанию, запускать билд на свободной ноде.
Я знаю два варианта, явно указать в доп. настройках, опция «Restrict where this project can be run»
Или использовать Matrix проекты для сборок.
Сейчас кол-во слейвов не большое, так что пробую по немногу оба способа.
А у вас как?
Управляем авторизацией, в целом — https://accounts.google.com/b/0/SmsAuthConfig. В частности настраиваем доступ приложению Google Authenticator, чтобы не ждать СМС.
Управляем паролями для приложений, которые не поддерживают двухэтапную авторизацию, например на вашем Android — accounts.google.com/b/0/IssuedAuthSubTokens
Один минус который я могу предположить, что при отсуствии смартфона, вы зависите от СМС, но даже будучи в такой ситуации я нажал ссылку — не пришло СМС и мне на телефон позвонил робот и продиктовал код. Так что в плане ее реализации в Google, я не сталкивался с недостатками или проблемами.
На самом деле свои реализации работы через REST API, SOAP, HTTP и даже вставку в MySQL я видел у шлюзов, но всегда рядом радовало наличие SMPP. Я не очень люблю самописные велосипеды, особенно когда нет альтернативы. И удивился, что тут отсутствует упоминания об имеющемся протоколе SMPP.
Исходя из описания они работают, по какому-то своему протоколу поверх http, вместо использования SMPP.
Используя SMS шлюзы с поддержкой SMPP, вы можете вольно выбирать любой и переключаться, и даже резервировать оповещения. Давно использую самописный perl скрипт на 20 строк, для оповещения мониторинга, на основе Net:SMPP для оповещений и не жалею. При необходимости могу быстро подключиться к другому шлюзу, полезно если нужна отправка СМС в другую страну.
chmod 777 –v –R *Особенно когда copy-paste сделают, не вчитываясь, от "/"
Неужели так тяжело обучать работе в правами сразу? После таких мануалов десятки и приходится у горе пользователей систему восстанавливать.
К сожалению, вы не показали решение. Так что я не могу согласится с вашим конфигом. Не смотря на имеющееся дополнение про css. Максимум это «конфиг для проксирования статитики, а для обновления нужно обновить алгоритм построенние ссылок, для внесение хеша к измененным элементам». А это не малое упущение, иначе действительно еще один пример обычного конфига, с добавлением хеша, даже не через location, а через аргументы с добавлением IfIsEvil.
Я не нахожу ответа на самый обычный вопрос, который часто возникает вообще при кешировании.
У меня >80 Гб статики. Ваше предложение? Держать для каждой ссылки свой хеш?
Если, да, то если строить его по данным файла прибавить не мало i/o нагрузки. Не говоря о дополнительной части в изменении кода.
Есть второй 1 хеш для обновления сайта, как часто делают для css & js. Но если взять один хеш для всех изображений, то все что я хотел донести, при замене пару Кб простого favicon, у вас весь кеш станет не валидным и будет заново наполнятся заливая все 80 Гб.
Все это я описал сразу. И хочу услышать общее решение в этом случае, как управлять обновлением контента.
Я не нашел в приведенном примере настройки или описания, что позволить обновить изображение, только аргументы для css.
Исходя из того, что после обновления сайта мы меняете хеш для всех css и возможно js, для медиа контента такой вариант не имеет смысла, хотя по вашему конфигу можно, иначе браузер заново загружает все изображения, а кеш заново наполняется.
Так, что я думаю 30 дней ждать обновления баннера или иконки это не совсем верный вариант. Как вы решаете эту задачу?
От SMS целиком отказываться не буду. Для критических уведомлений точно оставлю.
На РИТ++ был интересный доклад "Почему вам еще рано в облако" от Clodo, рекомендую ознакомиться.
Мы обращаем внимание на облака. Но мы еще не готовы к работе в облаке. Одна из причин — у нас высокие требования. Сейчас у нас есть хорошо масштабируемый проект на физических серверах, ресурсы которых более контролируемы чем облачные ресурсы. Когда мы будем готовы, обязательно попробуем разместить часть проекта в облаке.