Хочу немного поговорить про "Sqlite vs PostgreSQL".
Вчера Алексей правильно сказал, что инструмент выбирается под задачу, но не объяснил почему PostgreSQL - плохой выбор для небольших пет-проектов, которые делаются быстро и без команды.
Короткий ответ: Проблема любого сложного инструмента - это сопровождение. Если у вас не открыто достижение "администрирование PostgreSQL", то использовать его вредно дляздоровья безопасности вашего проекта.
Длинный ответ: Я знаю, что программисты с рождения умеют учить, лечить и админить серваки, но правда в том, что "петух - не птица, программист - не сисадмин". У меня был забавный случай, нас попросили помочь коллегам разобраться с тем, почему им на прод постоянно заливали малварь. Это была небольшая компания, в которой работало несколько разрабов и приходящий админ. Самый "опытный" программист сразу объяснил, что "это долбанный Wordpress настолько дырявый, что мы его замучились патчить". Их версия была в том, что им заливают вирусы через дыры в WordPress. На что "грешили", то и "лечили".
Мы провели стандартный набор мероприятий по аудиту безопасности: прошлись сканерами, посмотрели логи, запустили тестовые транзакции и т.д. В итоге нашли много чего интересного, но проблема была связана с тремя детскими ошибками конфигурирования:
- файрвол настроен криво: SSH поднять на дефолтном порту и открыт для всех
- дефолтный юзер postgreSQL работает с паролем postgres
- на пользователя postgres назначен шел
Зачем на postgres нацепили sh так и осталось загадкой, я думаю, что где-то был кривой туториал без пометки "не для прода". Сама проверка postgres/postgres черезе SSH есть во многих сканерах безопасности, ботнеты тоже сканят такие вещи.
Интересен не факт такого раздолбайства со стороны программистов, они и не должны были заниматься администрированием. Интересно то, что программисты уверены, что именно с ними ничего подобного не случится, что они уж точно все настроят и будет все на высшем уровне. На практике же, использование сложных инструментов приводит к появлению сложных проблем, поэтому, если ваш проект небольшой, и вы не хотите оставлять скрытые дыры и баги, то использовать лучше те инструменты, которые вам понятны, и которые проще всего решают поставленную задачу.
В небольшом приложении апнуть SQLite до PostgreSQL - это дело пары часов, максимум одного дня. Главное, чтобы при это админ был толковый и грамотно настроил инфраструктуру. Я, кстати, не умею грамотно настраивать PostgreSQL, поэтому даже и не пытаюсь, а беру SQLite для своих пет-проектов и еще не разу об этом не пожалел. )
#мысли #postgreSQL
Вчера Алексей правильно сказал, что инструмент выбирается под задачу, но не объяснил почему PostgreSQL - плохой выбор для небольших пет-проектов, которые делаются быстро и без команды.
Короткий ответ: Проблема любого сложного инструмента - это сопровождение. Если у вас не открыто достижение "администрирование PostgreSQL", то использовать его вредно для
Длинный ответ: Я знаю, что программисты с рождения умеют учить, лечить и админить серваки, но правда в том, что "петух - не птица, программист - не сисадмин". У меня был забавный случай, нас попросили помочь коллегам разобраться с тем, почему им на прод постоянно заливали малварь. Это была небольшая компания, в которой работало несколько разрабов и приходящий админ. Самый "опытный" программист сразу объяснил, что "это долбанный Wordpress настолько дырявый, что мы его замучились патчить". Их версия была в том, что им заливают вирусы через дыры в WordPress. На что "грешили", то и "лечили".
Мы провели стандартный набор мероприятий по аудиту безопасности: прошлись сканерами, посмотрели логи, запустили тестовые транзакции и т.д. В итоге нашли много чего интересного, но проблема была связана с тремя детскими ошибками конфигурирования:
- файрвол настроен криво: SSH поднять на дефолтном порту и открыт для всех
- дефолтный юзер postgreSQL работает с паролем postgres
- на пользователя postgres назначен шел
Зачем на postgres нацепили sh так и осталось загадкой, я думаю, что где-то был кривой туториал без пометки "не для прода". Сама проверка postgres/postgres черезе SSH есть во многих сканерах безопасности, ботнеты тоже сканят такие вещи.
Интересен не факт такого раздолбайства со стороны программистов, они и не должны были заниматься администрированием. Интересно то, что программисты уверены, что именно с ними ничего подобного не случится, что они уж точно все настроят и будет все на высшем уровне. На практике же, использование сложных инструментов приводит к появлению сложных проблем, поэтому, если ваш проект небольшой, и вы не хотите оставлять скрытые дыры и баги, то использовать лучше те инструменты, которые вам понятны, и которые проще всего решают поставленную задачу.
В небольшом приложении апнуть SQLite до PostgreSQL - это дело пары часов, максимум одного дня. Главное, чтобы при это админ был толковый и грамотно настроил инфраструктуру. Я, кстати, не умею грамотно настраивать PostgreSQL, поэтому даже и не пытаюсь, а беру SQLite для своих пет-проектов и еще не разу об этом не пожалел. )
#мысли #postgreSQL
👍197❤9🤡9🔥4⚡2👎2😁1👨💻1
Для справки, в postgresql параметры окружения лежат в юните с конфигурацией. Их легко найти в /usr/lib/systemd/system/postgresql.service (в разных ОС могут быть косметические отличия в пути). По дефолту там указывается только один параметр:
Проверял на Ubuntu и Manjaro.
Systemd, естественно, работает нормально и так, и так.
#postgresql #tip
Environment=PGROOT=/var/lib/postgresВ env пользователя в режиме nologin различие будет только в том, что в PATH не будет пути к ~/.local/bin, остальное будет точно таким же как с /bin/bash
Проверял на Ubuntu и Manjaro.
Systemd, естественно, работает нормально и так, и так.
#postgresql #tip
🔥19🆒6👍4🤡4