Pgadmin как сделать сервер

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Установка и настройка pgAdmin 4 в режиме сервера

Установка и настройка pgAdmin 4 в режиме сервера

pgAdmin — это приложение с открытым исходным кодом для администрирования и разработки баз данных PostgreSQL которое позволяет выполнять множество задач, начиная от мониторинга и обслуживания и заканчивая выполнением SQL-запросов. pgAdmin 4 можно установить на локальный компьютер, но в наше время, когда доступ может потребоваться в любое время и из любого места, это не очень удобно. Гораздо удобнее установить pgAdmin 4 в режиме сервера и иметь доступ к нему через браузер из любой точки мира. О том как это сделать мы расскажем в данной статье.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Для установки сервера pgAdmin мы будем использовать платформу Linux и дистрибутив Debian 10, при этом также поддерживаются Debian 9 и Ubuntu 16.04 (Xenial), 18.04 (Bionic), 19.10 (Eoan), 20.04 (Focal).

Мы не рекомендуем устанавливать pgAdmin на сервер с PostgreSQL если вы используете версию СУБД отличную от размещенной в репозитории, например, если вы используете PostgreSQL для 1С, потому что pgAdmin имеет в зависимостях ряд библиотек PostgreSQL, и вы с большой долей вероятности столкнетесь с конфликтом версий. Поэтому мы рекомендуем устанавливать pgAdmin на отдельный сервер, лучше всего виртуальную машину или контейнер. Все приведенные ниже команды следует выполнять с правами суперпользователя (root) или через sudo.

Установка и настройка pgAdmin 4

Для начала установим пакет gnupg для работы с цифровыми подписями:

Затем перейдем в домашнюю директорию, скачаем и установим публичный ключ для репозитория pgAdmin:

Теперь создадим файл со списком источников пакетов и внесем туда запись о репозитории pgAdmin:

Затем обновим список пакетов и установим сервер pgAdmin для работы в web-режиме:

По окончании установки запустите скрипт начальной настройки сервера:

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

На этом установка и первичная настройка закончена, для доступа к серверу наберите в браузере http://имя_или_ip_сервера/pgadmin4. Если все сделано правильно, то вы увидите страницу входа.

После авторизации вы попадете в привычную среду pgAdmin, можете подключать свои сервера и работать с базами данных. Инструмент поддерживает любые версии PostgreSQL и платформы установки (Windows, Linux и т.п.). В тестовых целях мы подключили сборку PostgreSQL 10 от 1С на платформе Linux и PostgreSQL 11 от Postgres Pro установленную на Windows Server.

Настраиваем SSL с самоподписанным сертификатом

Вроде бы все хорошо, все настроено и работает. Но есть одно но! По умолчанию pgAdmin 4 работает по незащищенному протоколу HTTP, что в начале третьего десятилетия 21-го века неправильно, даже если вы работаете только в пределах локальной сети. Тем более что в случае несанкционированного доступа некто получит полный доступ ко всем вашим базам данных.

Как быть? Если у вас есть собственное доменное имя, то можно настроить работу с сертификатами от Let’s Encrypt, подробнее читайте в нашей инструкции: Настраиваем Apache для работы по HTTPS (SSL) с сертификатами Let’s Encrypt

В остальных случаях будет вполне достаточно самоподписанного сертификата. Существует расхожее мнение, что шифрование с помощью самоподписанных сертификатов ненадежно, однако это не так. Единственный и существенный недостаток данного вида сертификатов — это отсутствие доверительных отношений. Т.е. мы не знаем кем именно он выпущен и можно ли ему доверять. Для публичных сервисов такой вариант не подходит, так как злоумышленник всегда может подменить такой сертификат своим и перехватить трафик, а пользователь даже не заметит разницы. Но для служебных узлов, когда администратор всегда может убедиться в том, что этот сертификат выпущен именно этим сервером, самоподписанные сертификаты вполне имеют право на существование.

Для создания такого сертификата выполните команду:

На что здесь следует обратить внимание? На ключ -days, который указывает срок действия сертификата в днях, в нашем случае мы указали 3560 дней или 10 лет,

В процессе генерации сертификата вам потребуется ответить на ряд вопросов, в большинстве их них можно указать произвольные данные и только в поле Common Name следует указать IP-адрес сервера или его FQDN-имя.

Затем откроем файл /etc/apache2/sites-available/default-ssl.conf в котором найдем и приведем к следующему виду две строки:

После чего создадим файл с настройками SSL:

И внесем в него следующие строки:

Мы не будем в рамках данной статьи подробно разбирать эти параметры, они достаточно сложны, но для получения актуальных настроек SSL вы всегда можете воспользоваться ресурсом ssl-config.mozilla.org, рекомендуемый уровень настроек — Intermediate. Указанный выше блок получен именно оттуда.

Сохраняем изменения и включаем нужные модули, конфигурации и виртуальные хосты:

Проверяем конфигурацию Apache на ошибки:

И перезапускаем веб-сервер:

Теперь подключимся к серверу pgAdmin 4 через браузер с явным указанием защищенного протокола https://имя_или_ip_сервера/pgadmin4:

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

Несмотря на ряд серьезных ошибок все достаточно неплохо. Первая ошибка сообщает нам, что имя сертификата не соответствует нашему узлу, что действительно так, сертификат мы выпустили для FQDN debian-pgadm4.interface31.lab, а обращаемся к серверу по IP-адресу 192.168.233.142. Вторая ошибка предупреждает о том, что сертификат выпущен центром сертификации (CA), который не является доверенным. Но так как мы знаем кто именно выпустил данный сертификат и что указанный IP-адрес совпадает с FQDN сертификата, то смело игнорируем эти ошибки.

Следующие пункты сообщают нам о том, что соединение использует протокол TLS 1.3, прямую секретность на базе 128-битной эллиптической кривой Curve25519 и шифрование AES128-GCM, также на странице нет незащищенных элементов. Это очень неплохой результат, соответствующий современным требованиям к безопасности.

После того, как мы убедились, что наш сервер нормально работает по защищенному протоколу, настроим автоматическую переадресацию с HTTP на HTTPS. Откроем файл /etc/apache2/sites-available/000-default.conf и в пределах секции VirtualHost внесем следующие строки:

Подключим необходимые модули:

И перезапустим веб-сервер:

После чего убедимся, что все запросы к нашему серверу автоматически перенаправляются на защищенную версию. Как видим, настроить pgAdmin 4 в режиме сервера достаточно несложно, получив удобный и безопасный инструмент для управления вашими базами данных.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Server Deployment¶

pgAdmin may be deployed as a web application by configuring the app to run in server mode and then deploying it either behind a webserver running as a reverse proxy, or using the WSGI interface.

When deployed in server mode, there are two notable differences for users:

Users must login before they can use pgAdmin. An initial superuser account is created when server mode is initialised, and this user can add additional superusers and non-superusers as required.

File storage is restricted to a virtual root directory for each individual user under the directory configured using the STORAGE_DIR configuration parameter. Users do not have access to the complete filesystem of the server.

The following instructions demonstrate how pgAdmin may be run as a WSGI application under Apache HTTPD , using mod_wsgi , standalone using uWSGI or Gunicorn , or under NGINX using using uWSGI or Gunicorn .

For detailed instructions on building and configuring pgAdmin from scratch, please see the README file in the top level directory of the source code. For convenience, you can find the latest version of the file here, but be aware that this may differ from the version included with the source code for a specific version of pgAdmin.

Requirements¶

Important: Some components of pgAdmin require the ability to maintain affinity between client sessions and a specific database connection (for example, the Query Tool in which the user might run a BEGIN command followed by a number of DML SQL statements, and then a COMMIT). pgAdmin has been designed with built-in connection management to handle this, however it requires that only a single Python process is used because it is not easily possible to maintain affinity between a client session and one of multiple WSGI worker processes.

On Windows systems, the Apache HTTP server uses a single process, multi-threaded architecture. WSGI applications run in embedded mode, which means that only a single process will be present on this platform in all cases.

On Unix systems, the Apache HTTP server typically uses a multi-process, single threaded architecture (this is dependent on the MPM that is chosen at compile time). If embedded mode is chosen for the WSGI application, then there will be one Python environment for each Apache process, each with it’s own connection manager which will lead to loss of connection affinity. Therefore one should use mod_wsgi ’s daemon mode, configured to use a single process. This will launch a single instance of the WSGI application which is utilised by all the Apache worker processes.

Whilst it is true that this is a potential performance bottleneck, in reality pgAdmin is not a web application that’s ever likely to see heavy traffic unlike a busy website, so in practice should not be an issue.

Future versions of pgAdmin may introduce a shared connection manager process to overcome this limitation, however that is a significant amount of work for little practical gain.

Configuration¶

In order to configure pgAdmin to run in server mode, it may be necessary to configure the Python code to run in multi-user mode, and then to configure the web server to find and execute the code.

See The config.py File for more information on configuration settings.

Python¶

From pgAdmin 4 v2 onwards, server mode is the default configuration. If running under the desktop runtime, this is overridden automatically. There should typically be no need to modify the configuration simply to enable server mode to work, however it may be desirable to adjust some of the paths used.

In order to configure the Python code, follow these steps:

Create a config_local.py file alongside the existing config.py file.

Edit config_local.py and add the following settings. In most cases, the default file locations should be appropriate:

NOTE: You must ensure the directories specified are writeable by the user that the web server processes will be running as, e.g. apache or www-data.

Run the following command to create the configuration database:

Change the ownership of the configuration database to the user that the web server processes will run as, for example, assuming that the web server runs as user www-data in group www-data, and that the SQLite path is /var/lib/pgadmin4/pgadmin4.db :

Hosting¶

There are many possible ways to host pgAdmin in server mode. Some examples are given below:

Apache HTTPD Configuration (Windows)¶

Once Apache HTTP has been configured to support mod_wsgi , the pgAdmin application may be configured similarly to the example below:

Now open the file C:\Program Files\pgAdmin4\web\pgAdmin4.wsgi with your favorite editor and add the code below which will activate Python virtual environment when Apache server runs.

Note: The changes made in pgAdmin4.wsgi file will revert when pgAdmin4 is either upgraded or downgraded.

Apache HTTPD Configuration (Linux/Unix)¶

Once Apache HTTP has been configured to support mod_wsgi , the pgAdmin application may be configured similarly to the example below:

Note: If you’re using Apache HTTPD 2.4 or later, replace the lines:

Adjust as needed to suit your access control requirements.

Standalone Gunicorn Configuration¶

pgAdmin may be hosted by Gunicorn directly simply by running a command such as the one shown below. Note that this example assumes pgAdmin was installed using the Python Wheel (you may need to adjust the path to suit your installation):

Standalone uWSGI Configuration¶

pgAdmin may be hosted by uWSGI directly simply by running a command such as the one shown below. Note that this example assumes pgAdmin was installed using the Python Wheel (you may need to adjust the path to suit your installation):

NGINX Configuration with Gunicorn¶

pgAdmin can be hosted by Gunicorn, with NGINX in front of it. Note that these examples assume pgAdmin was installed using the Python Wheel (you may need to adjust the path to suit your installation).

To run with pgAdmin in the root directory of the server, start Gunicorn using a command similar to:

And configure NGINX:

Alternatively, pgAdmin can be hosted in a sub-directory (/pgadmin4 in this case) on the server. Start Gunicorn as when using the root directory, but configure NGINX as follows:

NGINX Configuration with uWSGI¶

pgAdmin can be hosted by uWSGI, with NGINX in front of it. Note that these examples assume pgAdmin was installed using the Python Wheel (you may need to adjust the path to suit your installation).

To run with pgAdmin in the root directory of the server, start uWSGI using a command similar to:

And configure NGINX:

Alternatively, pgAdmin can be hosted in a sub-directory (/pgadmin4 in this case) on the server. Start uWSGI, noting that the directory name is specified in the mount parameter:

Источник