Forwarded from HABR FEED + OPENNET
Майкл Библь ушёл с поста мэйнтейрнера systemd в Debian
http://www.opennet.ru/opennews/art.shtml?num=49969
Майкл Библь (Michael Biebl), участвующий в разработке Debian с 2004 года и один из основных участников перевода проекта на системный менеджер systemd, демонстративно ушёл с поста мэйнтейрнера пакетов systemd в Debian, назвав сложившуюся ситуацию с исправлением ошибок в systemd глупостью и безумством, а также пообещав больше не отправлять разработчикам systemd отчёты об ошибках. #opennet
http://www.opennet.ru/opennews/art.shtml?num=49969
Майкл Библь (Michael Biebl), участвующий в разработке Debian с 2004 года и один из основных участников перевода проекта на системный менеджер systemd, демонстративно ушёл с поста мэйнтейрнера пакетов systemd в Debian, назвав сложившуюся ситуацию с исправлением ошибок в systemd глупостью и безумством, а также пообещав больше не отправлять разработчикам systemd отчёты об ошибках. #opennet
Forwarded from HABR FEED + OPENNET
Amazon представила сервис AWS Backup для резервного копирования
https://habr.com/ru/post/436414/
Tags: Облачные сервисы, Резервное копирование, Amazon, AWS Backup, бэкапы
Author alizar on #habrahabr
https://habr.com/ru/post/436414/
Tags: Облачные сервисы, Резервное копирование, Amazon, AWS Backup, бэкапы
Author alizar on #habrahabr
Хабр
Amazon представила сервис AWS Backup для резервного копирования
Amazon анонсировала полностью управляемый централизованный сервис резервного копирования AWS Backup. Компания рекламирует новое предложение как более быстрое и простое для клиентов резервное...
Forwarded from HABR FEED + OPENNET
Миграция с Mongo на Postgres: опыт газеты The Guardian
https://habr.com/ru/post/436416/
Tags: Блог компании ITSumma, MongoDB, PostgreSQL, Администрирование баз данных, Системное администрирование, перевод, базы данных, миграция, mongodb, postgresql
Author eapotapov on #habrahabr
https://habr.com/ru/post/436416/
Tags: Блог компании ITSumma, MongoDB, PostgreSQL, Администрирование баз данных, Системное администрирование, перевод, базы данных, миграция, mongodb, postgresql
Author eapotapov on #habrahabr
Хабр
Миграция с Mongo на Postgres: опыт газеты The Guardian
The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко...
@servers уже писал на своем канале об мониторинг SSL на своем канале
Но что-то он никак не запилит пост об:
1) https://servermonitoring.me - умеет в:
- мониторинг SSL,
- uptime ip
- uptime domain
- server monitoring по средством клиента.
- удаленное выполнение комманд ч/з установленный клиент, но только если включить эту опцию при добавлении нового сервера в админ панели, по дефолту такого нет.
- шлет оповещалки на почту
upd: можно боту в skype😏 + боту в Slack
2) https://uptimerobot.com - умеет разные штуки, но проще чем сервис выше:
- uptime ip
- uptime domain
- port monitoring
- проверка доступности сайта по keyword, по авторизации пользователя.
- шлет алерты на почту, есть поддержка webhooks
3) http://ping-admin.ru - тут уже все на русском но:
- Ping
- Детальная разовая проверка сайта
- Traceroute
- Проверка обратных ссылок
- Регулярная проверка сайта
- Проверка ИКС ( хз что это, но для xyz домена видно не применимо )
К чему это я пишу? К тому, что вдруг вам лень ставить всякие Nagios, Zabbix и тд. и тп., а простой мониторинг с разных мест будет вам вещать о проблемах на почту.
PS: там кстати при регистрации присылают от https://servermonitoring.me email, и говорят, что за 5 френдов приведенных с фейсбука иди ревью сервиса, вас переводят в premium акаунт, где можно подключать в мониторинг 25 серверов, а если вы сделаете оба условия - дадут возможно мониторинга 50 серверов. Дерзайте🤘
Но что-то он никак не запилит пост об:
1) https://servermonitoring.me - умеет в:
- мониторинг SSL,
- uptime ip
- uptime domain
- server monitoring по средством клиента.
- удаленное выполнение комманд ч/з установленный клиент, но только если включить эту опцию при добавлении нового сервера в админ панели, по дефолту такого нет.
- шлет оповещалки на почту
upd: можно боту в skype😏 + боту в Slack
2) https://uptimerobot.com - умеет разные штуки, но проще чем сервис выше:
- uptime ip
- uptime domain
- port monitoring
- проверка доступности сайта по keyword, по авторизации пользователя.
- шлет алерты на почту, есть поддержка webhooks
3) http://ping-admin.ru - тут уже все на русском но:
- Ping
- Детальная разовая проверка сайта
- Traceroute
- Проверка обратных ссылок
- Регулярная проверка сайта
- Проверка ИКС ( хз что это, но для xyz домена видно не применимо )
К чему это я пишу? К тому, что вдруг вам лень ставить всякие Nagios, Zabbix и тд. и тп., а простой мониторинг с разных мест будет вам вещать о проблемах на почту.
PS: там кстати при регистрации присылают от https://servermonitoring.me email, и говорят, что за 5 френдов приведенных с фейсбука иди ревью сервиса, вас переводят в premium акаунт, где можно подключать в мониторинг 25 серверов, а если вы сделаете оба условия - дадут возможно мониторинга 50 серверов. Дерзайте🤘
Telegram
Записки админа
🔒 Мониторинг SSL.
Вот вам ещё в коллекцию ссылок - сторонний сервис для мониторинга SSL и доступности ресурса. Для дополнительных проверок, и случаев, когда что-то своё поднимать не хочется.
https://letsmonitor.org/
#ssl #линк #фидбечат
Вот вам ещё в коллекцию ссылок - сторонний сервис для мониторинга SSL и доступности ресурса. Для дополнительных проверок, и случаев, когда что-то своё поднимать не хочется.
https://letsmonitor.org/
#ssl #линк #фидбечат
Да, вот и моя реферальная ссылка 🤷♂️😅
Server Monitoring.me
Best Server Monitoring Software | CloudStats
Нетак давно я делал пост об Gotify, которая работает на бинарнике Go и принимает, а потом и пушит вам в вебпанель браузера или в приложение на телефоне.
И вот решил сделать +1 способ получать алерты от Zabbix .
Ссылка на репозиторий - https://github.com/denisgolius/zabbix-to-gotify-alert
PR и Issues приветствуются.🖖🏻
Есть конечно и https://github.com/ableev/Zabbix-in-Telegram от Ильи, но если уж кто боится за Телеграм и его блокировки, то такой вариант вполне себе.
PS: gotify умеет ИзКаРоБкИ в letsencrypt, sqlite/MySQL/PostgreSQL можно использовать как базу для хранения истории пушей и всего прочего.
И вот решил сделать +1 способ получать алерты от Zabbix .
Ссылка на репозиторий - https://github.com/denisgolius/zabbix-to-gotify-alert
PR и Issues приветствуются.🖖🏻
Есть конечно и https://github.com/ableev/Zabbix-in-Telegram от Ильи, но если уж кто боится за Телеграм и его блокировки, то такой вариант вполне себе.
PS: gotify умеет ИзКаРоБкИ в letsencrypt, sqlite/MySQL/PostgreSQL можно использовать как базу для хранения истории пушей и всего прочего.
Telegram
sysadmin_books
Интересная штука для нотификаций - Gotify 👍
Self Hosted
You control your data.
Free and open source
Gotify is licensed under the MIT license.
Simple
Both Gotify's API and user interface is designed to be as simple as possible.
Cross Platform
Gotify is…
Self Hosted
You control your data.
Free and open source
Gotify is licensed under the MIT license.
Simple
Both Gotify's API and user interface is designed to be as simple as possible.
Cross Platform
Gotify is…
February 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support
Let’s Encrypt allows subscribers to validate domain control using any one of a few different validation methods. For much of the time Let’s Encrypt has been operating, the options were “DNS-01”, “HTTP-01”, and “TLS-SNI-01”. We recently introduced the “TLS-ALPN-01” method. Today we are announcing that we will end all support for the TLS-SNI-01 validation method on February 13, 2019.
In January of 2018 we disabled the TLS-SNI-01 domain validation method for most subscribers due to a vulnerability enabled by some shared hosting infrastructure 358. We provided temporary exceptions for renewals and for a small handful of hosting providers in order to smooth the transition to DNS-01 and HTTP-01 validation methods. Most subscribers are now using DNS-01 or HTTP-01.
If you’re still using TLS-SNI-01, please switch to one of the other validation methods as soon as possible. We will also attempt to contact subscribers who are still using TLS-SNI-01, if they provided contact information.
We apologize for any inconvenience but we believe this is the right thing to do for the integrity of the Web PKI.
Вобщем-то и целом нужно пересмотреть, что там у кого наставлено 🤨
https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209
Let’s Encrypt allows subscribers to validate domain control using any one of a few different validation methods. For much of the time Let’s Encrypt has been operating, the options were “DNS-01”, “HTTP-01”, and “TLS-SNI-01”. We recently introduced the “TLS-ALPN-01” method. Today we are announcing that we will end all support for the TLS-SNI-01 validation method on February 13, 2019.
In January of 2018 we disabled the TLS-SNI-01 domain validation method for most subscribers due to a vulnerability enabled by some shared hosting infrastructure 358. We provided temporary exceptions for renewals and for a small handful of hosting providers in order to smooth the transition to DNS-01 and HTTP-01 validation methods. Most subscribers are now using DNS-01 or HTTP-01.
If you’re still using TLS-SNI-01, please switch to one of the other validation methods as soon as possible. We will also attempt to contact subscribers who are still using TLS-SNI-01, if they provided contact information.
We apologize for any inconvenience but we believe this is the right thing to do for the integrity of the Web PKI.
Вобщем-то и целом нужно пересмотреть, что там у кого наставлено 🤨
https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209
Let's Encrypt Community Support
March 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support
Let’s Encrypt allows subscribers to validate domain control using any one of a few different validation methods. For much of the time Let’s Encrypt has been operating, the options were “DNS-01”, “HTTP-01”, and “TLS-SNI-01”. We recently introduced the “TLS…
Forwarded from Andrew Nikulkin
Завтра в 18:00 будет крутой вебинар по Azure Services and Microsoft Business Applications от MVP Александра Ермакова :))
http://aka.ms/mspceelive
http://aka.ms/mspceelive
Forwarded from Vasiliy Ozerov
Как чистить место на диске?
Вроде и вопрос банальный и проблеме сто лет в обед, но в последнее время он возникает так часто, что я решил написать несколько строк по этому поводу. С технической стороной вопроса все вроде бы понятно. Мониторинг настроили, алерты приходят, rm -rf отрабатывает. Но как быть с организационной частью?
Если мы говорим про данные (пользовательские, логи, статистика и тд), то непременно встает вопрос о том как долго их хранить. Без ответа на этот вопрос невозможно настроить автоматическую очистку старых данных, невозможно рассчитать объем хранилища, которое потребуется, да вообще ничего сделать нельзя.
Когда в ответ на этот вопрос вам говорят что храните столько сколько влезет на диск, то это не ответ. Хотя выглядит похоже. По сути этим ответом, проблему с политикой хранения переложили на диск. А диск ни черта не знает про то, что это за данные, кто их использует и как их используют.
Простой пример. У вас есть статистика по продажам вашего продукта. И вот вы поставили задачу хранить столько, сколько влезет на диск. Отлично! В какой-то момент на этой же базе разрослась тестовая таблица. Действуя согласно плану по хранению статистики продаж вы взяли и дропнули все данные за последний год и оставили там последние пару дней. Под условие подходит? Да. Мы нарушили инструкцию? Нет. Все правильно сделали? Да. А бизнес только что продолбал все историю продаж благодаря условию "храним сколько влезет".
Если бы у вас была политика хранения и очистки статистики продаж, то вы бы не смогли взять и удалить эти данные. Вы бы пошли искать что еще занимает место на диске, попытались бы очистить что-то другое. И в конце пришли бы к бизнесу с вопросом - нам нужны деньги на диск. И смогли бы это обосновать за 10 секунд. Примерно так: "Согласно политике, эти данные надо хранить 5 лет. Диск у нас на 1Тб - он закончился. Так что либо докупаем диск, либо меняем политику хранения".
Поэтому ответ на вопрос "Сколько и какие данные хранить?" безумно важен. Вы должны четко понимать кто и как использует какие данные и в зависимости от этого выработать политику очистки, агрегации и архивации этих данных. Совместно с продуктом, конечно.
Если вам отвечают хранить столько сколько влезет, то это означает ровно одно: Тот кто отвечает абсолютно не понимает кто и как использует эти данные. И вы со спокойной душой можете взять и дропнуть все нафиг, оставив данные за последний день. Чтобы такого не случилось - сходите и выясните политику очистки ваших данных.
Вроде и вопрос банальный и проблеме сто лет в обед, но в последнее время он возникает так часто, что я решил написать несколько строк по этому поводу. С технической стороной вопроса все вроде бы понятно. Мониторинг настроили, алерты приходят, rm -rf отрабатывает. Но как быть с организационной частью?
Если мы говорим про данные (пользовательские, логи, статистика и тд), то непременно встает вопрос о том как долго их хранить. Без ответа на этот вопрос невозможно настроить автоматическую очистку старых данных, невозможно рассчитать объем хранилища, которое потребуется, да вообще ничего сделать нельзя.
Когда в ответ на этот вопрос вам говорят что храните столько сколько влезет на диск, то это не ответ. Хотя выглядит похоже. По сути этим ответом, проблему с политикой хранения переложили на диск. А диск ни черта не знает про то, что это за данные, кто их использует и как их используют.
Простой пример. У вас есть статистика по продажам вашего продукта. И вот вы поставили задачу хранить столько, сколько влезет на диск. Отлично! В какой-то момент на этой же базе разрослась тестовая таблица. Действуя согласно плану по хранению статистики продаж вы взяли и дропнули все данные за последний год и оставили там последние пару дней. Под условие подходит? Да. Мы нарушили инструкцию? Нет. Все правильно сделали? Да. А бизнес только что продолбал все историю продаж благодаря условию "храним сколько влезет".
Если бы у вас была политика хранения и очистки статистики продаж, то вы бы не смогли взять и удалить эти данные. Вы бы пошли искать что еще занимает место на диске, попытались бы очистить что-то другое. И в конце пришли бы к бизнесу с вопросом - нам нужны деньги на диск. И смогли бы это обосновать за 10 секунд. Примерно так: "Согласно политике, эти данные надо хранить 5 лет. Диск у нас на 1Тб - он закончился. Так что либо докупаем диск, либо меняем политику хранения".
Поэтому ответ на вопрос "Сколько и какие данные хранить?" безумно важен. Вы должны четко понимать кто и как использует какие данные и в зависимости от этого выработать политику очистки, агрегации и архивации этих данных. Совместно с продуктом, конечно.
Если вам отвечают хранить столько сколько влезет, то это означает ровно одно: Тот кто отвечает абсолютно не понимает кто и как использует эти данные. И вы со спокойной душой можете взять и дропнуть все нафиг, оставив данные за последний день. Чтобы такого не случилось - сходите и выясните политику очистки ваших данных.
..Modlishka..
Modlishka is a flexible and powerful reverse proxy, that will take your phishing campaigns to the next level (with minimal effort required from your side).
Modlishka is a flexible and powerful reverse proxy, that will take your phishing campaigns to the next level (with minimal effort required from your side).
Forwarded from DevOps Deflope News
И подборка интересных утилит, которые попались на глаза недавно.
* ctop — top для контейнеров http://amp.gs/Vhpp
* bashful — красивая замена баша на стероидах http://amp.gs/Vhpv
* scenery — удобная штука, чтобы сделать лог терраформа более читаемым http://amp.gs/VhpV
* git-chglog — генератор ченжлога из истории коммитов http://amp.gs/Vhpf
* bob (Bob Build Tool) — кроссплатформенное решение автоматизации билдов http://amp.gs/Vhp4
* act — утилита для локальной отладки GitHub Actions http://amp.gs/VhpO
* chezmoi — интересная утилита для безопасной организации работы с dot файлами http://amp.gs/VhpU
* krew — менеджер плагинов для kubectl http://amp.gs/VhpG
* helm-diff — плагин для helm, который покажет что изменится при выполнении helm upgrade. http://amp.gs/Vhpk
* kubectl-debug — решение для дебага подов, запускает новый контейнер с кучей установленных тулов http://amp.gs/Vhpy
* netshoot — контейнер с разными утилитами для отладки сети в Docker + Kubernetes http://amp.gs/Vhpg
#digest #tools
* ctop — top для контейнеров http://amp.gs/Vhpp
* bashful — красивая замена баша на стероидах http://amp.gs/Vhpv
* scenery — удобная штука, чтобы сделать лог терраформа более читаемым http://amp.gs/VhpV
* git-chglog — генератор ченжлога из истории коммитов http://amp.gs/Vhpf
* bob (Bob Build Tool) — кроссплатформенное решение автоматизации билдов http://amp.gs/Vhp4
* act — утилита для локальной отладки GitHub Actions http://amp.gs/VhpO
* chezmoi — интересная утилита для безопасной организации работы с dot файлами http://amp.gs/VhpU
* krew — менеджер плагинов для kubectl http://amp.gs/VhpG
* helm-diff — плагин для helm, который покажет что изменится при выполнении helm upgrade. http://amp.gs/Vhpk
* kubectl-debug — решение для дебага подов, запускает новый контейнер с кучей установленных тулов http://amp.gs/Vhpy
* netshoot — контейнер с разными утилитами для отладки сети в Docker + Kubernetes http://amp.gs/Vhpg
#digest #tools
Forwarded from DevOps&SRE Library
Попытался немного консолидировать список полезных материалов для подготовки к интервью на позицию SRE. Список сделал на основе своего небольшого опыта прохождения интервью на такую позицию в разные компании (GitLab, Google, Revolut, etc).
Очень приветствуется обратная связь. Пишите в личку свои замечания и предложения - @mxssl, ставьте звездочки на гитхабе если список показался вам полезным.
https://github.com/mxssl/sre-interview-prep-guide
Очень приветствуется обратная связь. Пишите в личку свои замечания и предложения - @mxssl, ставьте звездочки на гитхабе если список показался вам полезным.
https://github.com/mxssl/sre-interview-prep-guide
Forwarded from Українська девопсарня via @like
Интересная статья о том, как тяжело дебажить и приводить в чуства большие распределенные системы. Вывод, к которому приходит автор статьи - лучше больше меньших кластеров, чем один большой.
https://medium.com/@daniel.p.woods/on-infrastructure-at-scale-a-cascading-failure-of-distributed-systems-7cff2a3cd2df
https://medium.com/@daniel.p.woods/on-infrastructure-at-scale-a-cascading-failure-of-distributed-systems-7cff2a3cd2df
Medium
On Infrastructure at Scale: A Cascading Failure of Distributed Systems
At Target, we run a heterogeneous infrastructure in our datacenters (and many other places), where we have multiple different backend…
Forwarded from HABR FEED + OPENNET
Выявлены следы взлома PHP-репозитория PEAR и модификации пакетного менеджера
http://www.opennet.ru/opennews/art.shtml?num=49998
Сообщается об обнаружении следов взлома официального репозитория пакетов PEAR (PHP Extension and Application Repository), предлагающего дополнительные функции и классы для языка PHP. В ходе атаки злоумышленникам удалось получить доступ к web-серверу проекта и внести изменения в файл "go-pear.phar", в котором содержится установочный комплект с пакетным менеджером "go-pear". Модификация была осуществлена 6 месяцев назад. #opennet
http://www.opennet.ru/opennews/art.shtml?num=49998
Сообщается об обнаружении следов взлома официального репозитория пакетов PEAR (PHP Extension and Application Repository), предлагающего дополнительные функции и классы для языка PHP. В ходе атаки злоумышленникам удалось получить доступ к web-серверу проекта и внести изменения в файл "go-pear.phar", в котором содержится установочный комплект с пакетным менеджером "go-pear". Модификация была осуществлена 6 месяцев назад. #opennet