• Практическое использование схем в Postgresql - когда они нужны?

    В целом, понимайте схемы как пространства имен. Схемы помогают логически организовать структуру БД. Различные приложения или компоненты приложений внутри себя имеют более высокую связность, чем между собой, тоже самое и с данными в БД - часто таблицы сами по себе организуются в логические группы, причем внутри группы связей довольно много (внешние ключи, какие-то общие хранимые процедуры и т.д.), а между этими группами - мало или нет вовсе.

    Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

    Если сформулировать коротко, то разбиение на базы данных - это для администраторов БД, а разбиение на схемы - это для администраторов данных и разработчиков приложений, чтобы им же было легче.

    А что будет если несколько юзеров будут на одну public-схему коннектиться?

    Помимо того, что схема - это пространство имен, в большинстве СУБД это еще и пространство безопасности. Даже в рамках одного многокомпонентного приложения имеет смысл ставить границы безопасности для ограничения возможных потерь и разрушений в случае компрометации одного из компонент.

    Вот допустим, у вас есть отдельная схема для таблицы авторизации и аутентификации и отдельная - для корпоративного форума. Сервис авторизации у вас выполнен отдельно от форума (например, авторизация выдаёт токены пользователю, с которыми он потом может зайти на форум). С точки зрения безопаности было бы логичным выдать сервису авторизации и форума различных пользователей в базе - тогда, при взломе форума невозможно будет получить доступ к паролям в базе или изменить права на портале, подправив данные в таблице ролей. Конечно, многие СУБД разрешают ставить права на отдельные таблицы, однако схема в данном случае играет роль контейнера и позволяет проставить единые правила для всех таблиц внутри неё.

    то есть при работе в постгре предпочтительнее вместо отдельных баз делать разные схемы в одной

    Как вы уже поняли - для независимых приложений, которые могут и должны существовать отдельно друг от друга - лучше делать разные базы. Тогда администраторы смогут спокойно переносить базы с сервера на сервер, независимо их бэкапить и т.д. Для компонентов одного приложения нужно использовать схемы.

    Вот вам еще хороший пример. У вас есть приложение для ведения бухгалтерии и складского учёта на фирме. При этом сложилось так, что вам нужно хранить на одном сервере данные нескольких разных фирм (например, вы предоставляете готовый сервис под ключ нескольким клиентам). В этой ситуации более чем логично хранить данные разных клиентов в разных БД, а данные бухгалтерского и складского учета - в различных схемах в рамках одной БД конкретного клиента.
    Ответ написан
    2 комментария
  • ProxyCommand в SSH

    ParkeTg
    @ParkeTg Автор вопроса
    Итак, я все же решил проверить, что там творится с пайпами ( говорить «трубами» язык не поворачивается ).
    Запускаем ssh, без указания опции ProxyCommand:

    ssh root@0.0.0.0
    

    В соседней владке терминала смотрим, пытаемся отгрепать все открытые процессом пайпы:

    lsof | grep -E "^ssh.*FIFO"
    

    И ничего, пустота. Не удивительно, мы ведь ничего не пишем в stdin. Давайте попробуем что-то пописать:

    pv /dev/zero | ssh root@0.0.0.0 "cat > /dev/null"
    

    Прогресс-бар зашевелился, переходим в соседнюю вкладку, и снова пытаемся отгрепать

    lsof | grep -E "^ssh.*FIFO" 
    

    В ответ получаем:
    ssh       23782       svon    0r     FIFO           0,8       0t0   2401849 pipe
    ssh       23782       svon    4r     FIFO           0,8       0t0   2401849 pipe
    

    Так, отлично, ssh читает из stdout (0r), и еще откуда-то(4r). На этом этапе еще интересно посмотреть, какие TCP подключения использует ssh. Отгрепаем по TCP:

    lsof | grep -E "^ssh.*TCP" 
    

    На выходе получим:
    ssh  24344  svon  3u  IPv4  2432025  0t0  TCP  arch:59472->super-vps.hell:ssh (EST.)
    

    Далее, запускаем ssh в связке с netcat (ProxyCommand )

    ssh -o "ProxyCommand nc %h %p" root@0.0.0.0
    

    Идем в соседнюю вкладку и опять грепаем, но только уже и netcat тоже:
    
    lsof | grep -E "(^ssh|^nc).*FIFO" 
    

    И, что у нас на выходе?
    ssh       24899       svon    4w     FIFO           0,8       0t0   2449781 pipe
    ssh       24899       svon    5r     FIFO           0,8       0t0   2449782 pipe
    nc        24900       svon    0r     FIFO           0,8       0t0   2449781 pipe
    nc        24900       svon    1w     FIFO           0,8       0t0   2449782 pipe
    


    А вот что. И если мы внимательно посмотрим на номера нод, то мы заметим.
    Что 4w (ssh ?) пишет в 0r (netcat stdin), а 5r (ssh ?) читает из 1w (netcat stdout).
    Забыли посмотреть подключения. Исправляем:

    lsof | grep -E "(^ssh|^nc).*IPv4" 
    

    И имеем в итоге:
    nc  24900  svon  3u  IPv4  2449789  0t0  TCP arch:59476->super-vps.hell:ssh (EST.)
     

    Видим, что из наших 2-х программ, подключение только одно, принадледжит оно неткету.

    Если посмотреть лог запуска ssh (с опциями -vvv), можно увидеть, что все прекрасно шифруется, и вообще, во всем мире — мир.

    Опираясь на факты, которые я привел выше, осмелюсь быть уверенным, что все работает именно по предполагаемой мной схеме (еще выше).

    Что нам это позволяет? Вообще, много чего, но мне интересно было пробросить ssh туннель, через тор на свою VPS. Зачем? Хотя бы потому, что это прикольно. Спасибо что читаете, жду дополнений.
    Ответ написан
    Комментировать
  • Какие существуют open source PKI?

    @Kek420
    Ответ написан
    Комментировать
  • Можно ли использовать несколько атрибутов SelectField в одном объекте?

    @pcdesign
    На мой взгляд должно быть так.
    Вместо if form.validate_on_submit():
    if request.method == 'POST' and form.validate_on_submit():


    И вызвать request
    from flask import request
    Ответ написан
    4 комментария
  • Мое дело или Бухгалтерия.Контур

    risik
    @risik
    Программист
    Я пользуюсь Мое Дело. ИП на упрощенке. По мне — все ок, только дорого для моего случая. Я захожу туда 1-2 раза в месяц + 2-3 раза в квартал.

    Контуром не пользовался — сравнить не могу.
    Ответ написан
    Комментировать