Дмитрий Шицков

Клудфлэйр подписывает все своим сертификатом, что у вас настроено на сервере вообще не сильно важно. Клудфлэйр сам работает по принципу похожему на mitm, он получает данные от вас по защищенному или незащищенному каналу и отправляет конечному пользователю подписанную своим сертификатом инфу.

Сертификат будет работать так, как он собственно выдан и подписан. Есть мультидоменные сертификаты, есть для одного домена, есть вайлдкард и т.д. Self-signed барахло это вообще отдельная история.

1) Храните несколько разных хешей, есть другие алгоритмы помимо md5
2) Перед md5 сравнивайте еще и просто размер
3) Если уж ВСЕ совпало - для полного исключения - сравните побайтово

Saboteur неплохо ответил(что не отменяет того что все остальные ответившие тоже правы)
Девопс - это практики. Это не набор инструментов( инструменты используются на определенных этапах, реализация которых необходима для приближения к идеалу), однако определенные необходимые инструменты опять же есть.
Про девопс можно прочитать очень много информации, но я, как админ (win-админ :D) вижу ситуацию для вас, как и любого, с опсовой основой, примерно так:

1. Жирным вы выделили вопросы который для вас вот конкретно сейчас не играют ни малейшей роли. Дмитрий Шицков и Saboteur написали почему: зависит от проекта.
   
2. Завет любого ops-а: автоматизируй всё что можно
   Если выбор между configuration management (chef, ansible, puppet и тд) и скриптами - то лучше первое. Хотя и тут можно поспорить, у меня в проекте chef-ом автоматизированное не очень-то используется на последнем этапе доставки в прод, поскольку мы все равно запечатываем машину и запускаем в AWS с asg без пост-конфигурации. Тут можно до посинения спорить хорошо это или нет, но скрипты в идеальном мире проигрывают DSL
   
3. Вы пишете код для автоматизации
   Вам понадобится git (который тянет за собой git-хостинг: bitbucket, github, gitlab и тп.) и навыки правильной работы с гитом. Для отслеживания и планирования изменений - понадобится какой-нибудь таск трекер (jira, таск трекер встроенный в gitlab, что-то другое).
   
4. Инфраструктура как код
   Автоматизируй всё означает автоматизацию развертывания инфраструктуры
   Здесь уже вступают в силу особенности вашего окружения - в облаках вы скорее всего захочете использовать terraform или, например, CloudFormation в AWS - встроенное средство оркестрации, или же будете сразу все запускать в контейнерах - docker , kubernetes используя соответствующие инструменты.
   
5. Мониторинг
   Без правильного и подходящего вашему продукту мониторинга(+логирования) жить нельзя. И это было еще до DevOps тренда - это классика администрирования. Здесь ничего не посоветую, с Zabbix-ом сам не ужился, переехал на influx и прилегающие (TICK stack). Для логирования - graylog, ELK. В некоторых частях используется prometheus который в том числе и для кубера удобен. В общем - с чем подружитесь.
   

Это только то, что вы уже должны знать и вам легче будет к ним приступить.
Будете хорошо ориентироваться (не только знать, но и выбрать правильные инструменты, уметь построить правильный пайплайн) - вас с руками оторвут, несмотря на то что вы можете быть слабы в других областях (тестирование, билд и проч.)

Для примерного осознания всего цикла можно посмотреть на (картинка относительно рандомная,таких много, два года назад я ориентировался по другой, с более подходящим мне списком инструментов, но найти не могу =( )


P.S. Еще раз хочу отметить что описанное выше основано на личном опыте и это - движение в devops со стороны ops. Есть те, кто сразу пытаются строить все по девопсу параллельно обучаясь опсовой части и девелоперской( видел таких, не у всех получалось ). Есть те, кто двигается в девопс со стороны Dev. Все будут иметь разные мнения что важно для того, чтобы начать

Если про уже запущенный контейнер, то
docker rename oldname newname
Если про не запущенный, то
docker run --name my_cool_name hello-world

Мигрировал с pdd в Connect, но проблему это не решило.

Обратился в тех.поддержку Яндекс по email: connect@support.yandex.ru
Где попросил объяснить как работать в Connect через API, например, чтобы менять ip-адрес в DNS-имени, на что получил ответ:

К сожалению, в API Коннекта на данный момент отсутствует возможность управлять DNS-записями. Приношу извинения за неудобства!

Если для Вас критичен данный функционал, наши специалисты могут вернуть Ваш домен обратно в Почту для домена.

Попросил меня вернуть обратно на pdd.yandex.ru, но после возврата, API так и не заработал.
Я вновь написал в тех.поддержку и сказал о проблеме, сказали что разберутся и вопрос передан куда надо, но по прошествии недели - тишина. Короче, я бросил это занятие и отказался от yandex.

Вывод: pdd убили, а новое еще не работает. Зачем так делать, я не понимаю.

Написал сюда, может кому будет интересно.

Тему закрываю.

-------------------------------------------
Прошло 2 недели после прошлого сообщения от Яндекса, и неожиданно пришел новый ответ от Яндекса, что нужно:
"Чтобы получить доступ к API, пожалуйста, получите новый токен."

Удалил старый токен и создал новый, все заработало.
PS. Очень долго отвечают.
24.07.2018

---------------------------------

Прошло 4 месяца, при попытке зарегистрировать новый домен на pdd, сайт перекидывает на коннект.
Написал в тех.поддержку, чтобы уточнить что за дела. Мне ответили.
PS. Что интересно, что ответили в тот же день, ну дела ))

Ответ от тех.поддержки Яндекса:

Подключать новые домены к Почте для домена действительно уже нельзя. Сейчас есть возможность подключиться только к сервису Коннект.
Разработчики сервиса знают о пожелании пользователей добавить возможность редактировать DNS в API Коннекта и работают над этим. Конкретных сроков появления этой функции мы, увы, пока назвать не можем.

У нас хорошо идет coreos

1. Создание tcp-соединения медленное;
   
2. Создание tls-соединения ещё медленнее;
   
3. Установка соединения протокола уровня приложения ещё медленнее;
   
4. Аутентификация подключения на порядок медленнее;
   
5. Создание сессии для соединения системой управления базами данных такая же медленная;
   
6. Завершение сессии и освобождение ресурсов медленное;
   
7. Закрытие соединение относительно быстрое, но тоже не мгновенное.
   

Если 500 раз в секунду соединение создаётся, через него выполняется один простой запрос, и соединение закрывается, то СУБД и клиент часть пропускной способности тратят на выполнение бессмысленных действий. Намного разумнее один раз открыть соединение, прогнать через него два миллиона запросов и только потому может быть закрыть.

Крон в этом случае плохое решение. По факту вам надо оперировать только таймерами. Начисление денег за время что не были в игре делается легко. Просто берете разницу между последним начислением и текущем временем и даете денег юзеру сохраняя время начисления. Увеличение атаки можно сделать следующим образом. Например у нас есть таблица с эффектами которые цепляются на юзера. Основная задача этой таблицы - хранить таймпштамп когда этот эффект будет не активен. При активации эффекта мы его добавляем в эту таблицу, а дальше каждый раз когда считаем урон просто проверяем не истекло ли еще время действия эффекта. Проверка будет происходить каждый запрос. Это будет сильно дешевле чем раз в секунду пинать крон, да и более правильно как по мне.

Поднимайте что-то на базе любого движка Вики (MediaWiki, DokuWiki или другое что-то) и храните все там. Удобно.

Открываем IP – DHCP Server, выбираем гостевой dhcp и устанавливаем опцию «Add ARP For Leases».



Переходим в раздел Bridge, выбираем гостевой бридж, напротив опции ARP необходимо указать «reply-only».

Источник.

добавь в /etc/sysctl.conf
net.ipv4.ip_default_ttl=65

postgresql

Прописать в ChrootDirectory /var/www/site_dev/assets. не могу, поскольку права на запись в /var/www/ нужны многим группам пользователям.

Не совсем понимаю, как права других пользователей связаны с Chroot'ом, в Вашем случае... Ну да не суть.

Есть вариант забирать кроном каждую секунду фаилы из /home/%u/ и перемешать в кнечную папку, но это както не правильно.

Крон изначально запускается 1 раз в минуту (минимум) и не очень приспособлен для того, что бы делать что-то каждую секунду. В этом случае, проще было бы написать скрипт с бесконечным циклом и не забивать крон как минимум 60-ю заданиями (что бы они запускались через секунду). А если правильнее - использовать для этого какую-то систему синхронизации, например, Rsync.

А ещё можно попробовать mount --bind, не знаю, поможет ли это в Вашем случае, но попробовать стоит.