Привет! Не так давно, в нашей организации встала задача узаконить wifi доступ, но чтобы в дальнейшем использование системы было бесплатно. (Согласно постановлению Правительства №758 от 31 июля 2014г. и №801 от 12 августа 2014 г. — все публичные WIFI сети обязаны производить идентификацию пользователей). У нас 10 залов для мероприятий (от 30 до 400 человек), а в день в среднем проходит от 4 до 12, плюс постоянная текучка народа и капризные пользователи.
Zabbix позволяет легко и удобно настроить мониторинг большого количества разных счетчиков со множества устройств. Он был открыт под GPL в 2001г, и за последние 15 лет в нем безусловно было сделано множество улучшений, позволяющих еще лучше собирать еще больше данных.
Но почему же все улучшения обошли стороной навигацию по такому большому количеству собранных графиков и их отображение?
Читать полностью »
Сегодня мы расскажем о том, как решить, пожалуй, самую актуальную проблему современной телефонии – интеграцию со сторонними информационными системами, прежде всего, CRM системами. Необходимо отметить, что сейчас существует много облачных сервисов телефонии, предлагающих, также, базовый функционал CRM. С другой стороны, многие производители CRM пытаются интегрировать базовые функции телефонии непосредственно в интерфейс пользователя. Также существуют готовые системы “два-в-одном”, в которых уже при проектировании закладывались коммуникационные возможности.
Одним словом, производители этих решений услышали требования пользователей и двигаются в правильном направлении. В целом, так оно и есть. Однако подход “два-в-одном” имеет ряд недостатков, самый главный из которых – неудовлетворительная гибкость. Согласитесь, создание функциональной системы объединенных коммуникаций и первоклассной CRM требует совершенно разных компетенций. В результате пользователь сталкивается либо с ограниченными коммуникационными возможностями, либо с бесполезной “обрезанной” CRM с неясными перспективами развития.
В системах, где CRM изначально объединена с телефонией, также существует ряд недостатков:Читать полностью »
Поскольку объем данных, которыми оперируют различные компании растет, а эти данные нужно где-то хранить, крупнейшие провайдеры облачных сервисов стали предлагать своим клиентам «холодное хранение» данных. По всей видимости, cold storage сервисы могут занять какую-то часть рынка традиционных услуг хранения данных.
При этом cold storage в качестве облачного сервиса может в значительной степени изменить способ работы компаний с данными, включая хранение информации и ее доставку. Amazon Web Services, Google Cloud Platform, и теперь еще и Microsoft Azure предлагают клиентам cold storage сервис. При этом у каждого из названных сервисов свои особенности.
Читать полностью »
Прошла неделя с моей второй поездки на IETF, мысли и эмоции немного улеглись и я решил поделиться своими впечатлениями об IETF.
Читать полностью »
«Зеркальный» кластер с синхронными вычислительными процессами, вид спереди
Пока тут весь интернет кричит про наш отечественный жёсткий диск на целых 50 Мегабайт массой 25 килограмм, не очень-то понимая, что эта штука может пережить две ядерных войны на дне бассейна, расскажу про серьёзные отказоустойчивые серверы и их отличия от обычного железа. К счастью, к нам как раз поступили на тестирование такие, и была возможность хорошенько над ними поиздеваться.
Эти решения особенно интересны для админов. Дело в том, что они защищены не физически — кожухами, отказоустойчивыми интерфейсами или чем-то ещё, а на уровне именно архитектуры вычислений.
Нам в руки попал флагман ftServer 6800 от Stratus. Это корпус с двумя идентичными вычислительными узлами, объединёнными в один кластер, причем обе его половинки работают синхронно и делают одно и то же «зеркально». Это старая добрая «космическая» архитектура, когда вычислительный процесс проходит сразу два независимых аппаратных пути. Если где-то возникнет баг (не связанный с кривостью кода), то один из результатов точно достигнет цели. Это важно для критичных систем в самых разных областях от банкинга до медицины, и это очень важно там, где есть «тихая потеря данных». То есть там, где во весь рост встают баги процессоров, связанные с тем, что кристаллы всё же уникальные и двух одинаковых машин не бывает в природе. Обычно это не проявляется, но на ответственных задачах требуется защититься от случайного влияния помех и возможных более явных проблем. Поэтому вот так и сделано. Читать полностью »
В Интернете доступно некоторое количество статей по настройке антивирусной защиты в связке squid + ClamAV, но нет полного материала по настройке полной связки под CentOS 7. В рамках данной статьи будет показан процесс настройки прокси сервера со следующими возможностями:
Системные администраторы Linux
Задумываясь над дальнейшим апгрейдом собственной домашней тестовой песочницы в целях экономии пространства дома и экономии денежных средств, я подумал — а не перейти ли со стоечных серверов на напольные? С одной стороны стойка имеет собственные преимущества, но в условиях небольшой квартиры её размещение и организация нормального теплового режима вызывает у меня некоторые проблемы. Тем более что оборудование достаточно старое, и что бы обеспечить должный уровень производительности его требуется большое количество.
Благодаря нашему ОпСоСу (оператору сотовой связи), поставившему к нам в офис 2G/3G базовую станцию, у нас наконец-то сделалась нормальная связь. Кроме того, вместе со станцией мы обрели новую стойку. Была договорённость, что в эту стойку мы перебросим еще и своё оборудование, потому что места было немного и третья стойка сильно мешала. И если серверное железо поместилось без проблем, то пристроить монитор было затруднительно. В стойке оставалось где-то 5U свободного места, что для полки с монитором недостаточно.
Вообще-то, мы очень любим стоечные KVM — максимум функционала при 1U размера, но совершенно не нравятся цены. 80 тыс.руб за то, что нас бы устроило.
А что если понищебродить попытаться сделать нечто подобное самостоятельно? После проверки склада, мы обнаружили что:
Задайте себе вопрос — как правильно хранить пароль от базы данных, которая используется вашим сервисом? В отдельном репозитории с секретами? В репозитории приложения? В системе деплоя (Jenkins, Teamcity, etc)? В системе управления конфигурациями? Только на личном компьютере? Только на серверах, на которых работает ваш сервис? В некоем хранилище секретов?
Зачем об этом думать? Чтобы минимизировать риски безопасности вашей инфраструктуры.
Начнём исследование вопроса с определения требований к хранению секретов.
