kolo2012: думаю все популярные встраиваемые БДшки, у которых заявлена persistence, умеют эту persistence делать правильно. Иначе бы не были популярными. Чтобы на 100% быть уверенными - просто возьмите и проверьте Ваш кейс.
gubber: ну, я такой идеи не предлагал, это Вы уже себе спасибо скажите, что пришло в голову =) Зато я подкину Вам идею не создавать этот аппендер, а сначала поискать готовый. Java мир, по-моему, и славится тем, что там есть всё на каждый чих.
Что касается фоновых процессов, то я всегда обрабатываю ситуации, когда они отваливаются, иначе доверия к корректности/стабильности работы приложения нету. Касательно "по тихому не получится, так как пропадут логи" - это понятно, но вопрос в том, когда это будет обнаружено, и когда поправлено, и как это скажется на бизнесе. Супервизор же просто перезапустит процесс, и все дальше будет работать корректно, а о случившемся Вы узнаете уже в результате анализа логов/алертинга, а не внезапно в 3 часа ночи с потребностью спросонья лезть в терминал и рестартовать сервис.
Если Ваш бизнес допускает подобные ситуации - нет проблем. В конечном итоге принятие решения за Вами. Да и Вы его уже приняли. Я лишь делюсь собственным кровавым опытом, и объясняю почему он именно такой, не более.
gubber: если у Вас более одного долгоживущего процесса в контейнере, Вам нужны гарантии что они живы и бегут. Можно просто позапускать вторичные процессы в background через &, но что будете делать когда какой-то процесс по-тихому упадет?
Все зависит от конкретного container runtime. Например в Kubernetes есть понятие Pod. Pod - это связка контейнеров которые являют собою экземпляр приложения. У них единый жизненный цикл, единая сеть, если кто-то умирает - перезапускается весь Pod. Располагая подобным инструментом удобнее держать отдельные процессы в отдельных контейнерах, потому что можно тонко настроить ресурсы выделяемые тому или иному процессу, отдельно смотреть логи каждого контейнера, и т.д. Часто даже достаточно просто компоновать связку из уже существующих официальных образов, полностью минуя шаг построения своего образа.
Если же Вам удобнее в Вашем случае запаковать все в один контейнер, то ничего страшного в этом тоже нет. Только здесь уже появляется необходимость использовать какой-то супервизор, что само по себе не являет грехом, а всего лишь необходимой мерой.
kolo2012: ну sqlite и есть строку в файл со всеми граблями. Помимо sqllite есть куча Go'шных встраиваемых БД, пошерстите их, может чего для себя найдете. Вот Вам даже релевантное обсуждение Reddit'е: https://www.reddit.com/r/golang/comments/2ldd2l/lo...
demon_od: как правило - да. В самом конце INPUT chain у Вас стоит -j DROP, а перед ним уже вставляете ACCEPT правила. Таким образом, все что не за'ACCEPT'ится в конце-концов DROP'нется.
Николай: "кажется" и догадки это все хорошо, но лучше смотреть на реальное состояние дел.
Если Вам нужно померить скорость дисковых операций - так заверните какой-то дисковый бенч в контейнер и померяйте, после чего сравните с результатами с чистого хоста.
Если Вам нужно добиться вменяемой производительности БД, то тюнингуйте её, либо хотя бы приведите конфиг в соответствие с хостовым. Незатюненая БД очень сильно влияет на производительность.
Не спешите из одного делать выводы о другом, пока не будет цифр доказывающих это явным образом.
Что касается разработки и аудита, то это в любом случае должны быть 2 независимых действия, иначе аудит честным считать будет тяжело.
Чтобы и разработчики были в курсе Ваших ожиданий в плане безопасности, и Вам не приходилось надеяться на "авось сделают безопасно", этот момент нужно четко закрепить как условие задачи в договоре. Можно прям так и сформулировать, мол разработанная система на выходе должна соответствовать PCI стандартам. Если после разработки, система не проходит аудит на соответствие стандартам, значит разработчики не выполнили свою часть договора.
Bjornie
> Правильно ли я понимаю, что это делается так: Client -> VPN_1 -> VPN_2 -> Internet.
> allow only for VPN_1.
Ну, такую трубу никто не мешает сделать, но это уже хакерство какое-то. Не хватает в схему добавить ещё пару проксей, Tor'ов, и i2p в самом конце =)
Идея примерно следующая:
Client -> VPN_1 -> SSH_2
Client -> VPN_2 -> SSH_1
Client -> VPN_1 либо VPN_2 -> Internet
Смысл в том, чтобы ограничить доступ к управляющим ресурсам, и пускать только с определенного белого списка адресов. Это почти на корню отсекает попытки добраться к этим ресурсам всяким левым людям/хакерам/ботам.
Bjornie
> Имеется ввиду если я переустановлю систему?
Угу. Или банально понадобится +1 сервер. Плюсов много.
> Могу ли я писать нужные мне утилиты только на пайтоне?
Все вменяемые и стандартные дистрибутивы поддерживают пайтон. А которые нет - ставится с пол-пинка. Так что да. Но вообще, понимать лучше все. Мне приходилось править/разбирать и python скрипты, и ruby (привет Chef'у), и даже в Perl'ах всяких копаться (как поэтично звучит то!). Для своих мелких скриптиков предпочитаю чистый sh, в крайнем случае - bash. Их понимать и владеть хотя бы на минимальном уровне - очень полезно.
Bjornie
7. TLS - это промышленный стандарт шифрования. Современное шифрование обеспечивает не только то, что данные никто не прочитает, но и то, что их никто не подделает. TLS использует приватные ключи и сертификаты. Браузеры и всякое ПО просто так любой левый сертификат не принимают. Сертификат должен быть выпущен доверенными лицом. Доверенным считается то лицо, корневой сертификат которого присутствует в системе. Если Вы самостоятельно создадите свое CA (Certificate Authority) и нагенерите своих сертификатов, которые и подпишите своим CA (потому и называются самоподписанными), то это его не делает доверенным для всего остального интернета, так как у них нету Вашего корневого сертификат в списке доверенных. Потому и заказываются сертификат у разных доверенных фирм, которые их выпускают. Самоподписанные сертификаты же используются для свои внутренних нужд и не светятся наружу. Например, у Вас в OpenVPN для аутентификации на VPN сервер и используются самоподписанные сертификаты.
Bjornie
По iptables можно попробовать и с временными правилами, на всякий случай. Лично я не пользовался ими. Чтобы проверить что правило работает - нужно проверить что правило работает. Капитанство, но так и есть. То есть, если Вы закрыли какой-то порт, пробуйте на него постучаться (например, через telnet) и убедиться что он недоступен как надо.
Чтобы не влететь с SSH в начале - не трогайте его порт, пока не овладеете инструментом. На самом деле в iptables ничего сложного нет. Нужно просто открыть мануал и внимательно, усидчиво почитать, понять несложную концепцию блуждания трафика по цепочкам правил, и закрепить практикой, пока не прийдет полное понимание того, что Вы делаете и зачем, и как сделать то что Вам нужно. Возьмите, подымите на каком-то порту какой-то сервис, и развлекайтесь с этим портом. Наличие VPN, кстати, будет плюсом, так как параллельно сможете этот порт и по FORWARD цепочкам помучить.
6. Это не совсем настройка безопасности. Я просто это добавил как обязательный шаг при настройке любого сервера. Со временем любые часы начинают сбоить, и разница в пару секунд за пару месяцев может набежать легко. Пока у Вас один сервер - это, возможно, и не важно. А когда у Вас сервера уже два, и они как-то взаимодействуют активно, и у них расходятся часы, то приходит время всяких веселых багов. Не все приложения написаны идеально с точки зрения работы с временем. Далеко не все разработчики уделяют этому должное внимание. Например, сайт на PHP может генерировать timestamp'ы у себя прямо в скриптах и потом их записывать в БД в одном месте, а в другом месте он этот timestamp генерирует уже непосредственно в SQL-запросе. В результате вылезают забавные моменты, когда пользователь входит на сайт за 2 секунды до того как зарегистрируется. Бизнесу, правда, совершенно не забавно, особенно когда дело касается денег. Потому лучше чтобы часы были синхронизированы везде и тикали корректно.
https://passingcuriosity.com/2013/dnsmasq-dev-osx/