Как установить PostgreSQL Linux часть 4.

Введение.

Изучая основы работы сервера PostgreSQL, переходим к рассмотрению вопросов обеспечения безопасности пользователей использующих БД PgSQL. В статье PostgreSQL Linux часть 4, мы будем рассматривать такие важные понятия как пользователи и роли.

Основу защиты учётных записей пользователей PgSQL формируют пользовательские роли и пароли.

Все статьи посвящённые PostgreSQL см.

тэг БД или поиск postgres

Подготовка PostgreSQL Linux часть 4.

  • Стенд
    • Cервер ALT Linux, имя: lin-pq; IP 10.0.2.11;
      • Simply Linux, имя: lin-sl, IP=10.0.2.30
      • Пользователь, имя: trt

Роль — это пользователь СУБД или, если пользоваться терминологией ОС Linux, Windows — группа. Роли не связаны с именами пользователей ОС. Роли являются общими объектами для PgSQL, могут подключаться к разным базам и быть владельцами для объектов различных БД.

Команды управления ролями PostgreSQL Linux часть 4.

  • Список основных команд для управления ролями:
    • CREATE ROLE — вызывается из psql
    • DROP ROLE — вызывается из psql
    • ALTER ROLE — вызывается из psql
    • createuser — вызываются из командной строки ОС
    • dopuser — вызываются из командной строки ОС
  • CREATE ROLE — создать роль в базе данных
    • CREATE ROLE имя [ [WITH] параметр [ …] ]
      • параметр
        • LOGIN — вход на сервер
        • SUPERUSER — суперпользователь
        • CREATEDB — создавать базы данных
        • CREATEROLE — создавать, изменять, удалять роли
        • REPLICATION — выполнять репликации
        • и другие…

Параметры (атрибуты) имеют два варианта, пример, CREATEDB (дает право на создание БД) и NOCREATEDB (не дает такого права), по умолчанию выбирается ограничивающий вариант.

  • DROP ROLE — удалить роль в базе данных
    • DROP ROLE [ IF EXISTS ] имя [, …]
      • IF EXISTS — не считать ошибкой, если роль не существует
  • ALTER ROLE — изменяет атрибуты роли
  • ALTER ROLE имя [ [WITH] параметр [ …] ]
    • параметр
      • SUPERUSER
      • NOSUPERUSER
      • CREATEDB
      • NOCREATEDB
      • CREATEROLE
      • NOCREATEROLE
      • INHERIT
      • NOINHERIT
      • LOGIN
      • NOLOGIN
      • REPLICATION
      • NOREPLICATION
      • BYPASSRLS
      • NOBYPASSRLS
      • CONNECTION LIMIT предел_подключений
      • [ ENCRYPTED ] PASSWORD ‘пароль
      • PASSWORD NULL
      • VALID UNTIL ‘дата_время
  • createuser — создать новую учётную запись PostgreSQL
    • createuser [параметр…] [имя_пользователя]
      • параметр
        • -c номер количество соединений
        • -d может создавать базы данных
        • -D не может создавать базы данных
        • -g role роль, к которой будет добавлена текущая роль
        • -i наследовать права ролей
        • -I не наследовать права ролей
        • -l может подключаться к серверу
        • -L не может подключаться к серверу
        • -r может создавать, изменять и удалять роли
        • -R не может создавать, изменять и удалять роли
        • -s имеет права суперпользователя
        • -S не имеет права суперпользователя
        • —interactive диалоговый режим для параметров
        • и другие…

createuser — та же функциональность, что и команда CREATE ROLE

  • dopuser — удалить учётную запись пользователя PostgreSQL
    • dropuser [параметр…] [имя_пользователя]
      • параметр
        • -i диалоговый режим
        • -e журнал выполнения команд

dopuser — та же функциональность, что и команда DROP ROLE

Управление ролями PostgreSQL Linux часть 4.

Перейдём к практическим действиям использования ролей. Для начала посмотрим, какие роли, пользователи, БД существуют после установки и первичной настройки PgSQL.

Для сокращения фрагментации кода, строки

$ sudo su - postgres -s /bin/bash
-bash-4.4$ psql
будут в дальнейшем опущены, мы внутри psql
$ postgres=# \l Список баз данных Имя | Владелец | Кодировка | LC_COLLATE | LC_CTYPE | Права доступа -----------+----------+-----------+-------------+-------------+----------------------- postgres | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | template0 | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | ru_RU.UTF-8 | ru_RU.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres postgres=# \du Имя роли | Атрибуты, Список ролей | Член ролей ----------+-------------------------------------------------------------------------+------------ postgres | Суперпользователь, Создаёт роли, Создаёт БД, Репликация, Пропускать RLS | {}

Создадим новую базу данных.

postgres=# CREATE DATABASE trest;

Введём в нашу БД новую роль (пользователя)

postgres=# CREATE ROLE trt LOGIN CREATEROLE;

Установим пароль для пользователя trt.

postgres=#  \password trt
Введите новый пароль для пользователя "trt":********** 
Повторите его:**********

Проверяем наши действия, пробуем подключится.

$ psql -U trt
Пароль пользователя trt: 
...
trt=> 

Используя ключ du смотрим роли.

trt=> \du Список ролей Имя роли | Атрибуты | Член ролей ----------+-------------------------------------------------------------------------+------------ postgres | Суперпользователь, Создаёт роли, Создаёт БД, Репликация, Пропускать RLS | {} trt | Создаёт роли | {}

Пользователь trt не обладает привилегированной ролью, мы вынужденны, для управления, обращаться к роли postgres. Это неправильно, тем более, что консольные команды createuser и dopuser для postgres не доступны, он не имеет регистрации в OC и это хорошо. Узко — целевое значение пользователя postgres, один из элементов безопасности БД — postgres владеет только теми данными, которыми управляет сервер БД.

Рекомендуется не назначать пользователя postgres владельцем исполняемых файлов PgSQL, чтобы их нельзя было подменить в случае компрометации серверного процесса.

Не совсем удобно постоянно пользоваться записью postgres, поэтому наделим пользователя trt привилегированными ролями.

Добавление административной роли.

Пользователь trt может только создавать роли, добавим ему некоторые привилегированные права, что бы разгрузить запись postgres.

postgres=# ALTER ROLE trt SUPERUSER CREATEDB CREATEROLE; ALTER ROLE postgres=# \du Список ролей Имя роли | Атрибуты | Член ролей ----------+-------------------------------------------------------------------------+------------ postgres | Суперпользователь, Создаёт роли, Создаёт БД, Репликация, Пропускать RLS | {} trt | Суперпользователь, Создаёт роли, Создаёт БД | {}

Заключение.

Тема управления ролями PostgreSQL широка и требует более глубокого рассмотрения. Читайте продолжение статьи в следующей части PostgreSQL Linux часть 5.

Полезные ссылки.

Как установить PostgreSQL Linux часть 2.

Введение.

Продолжая изучение PostgreSQL переходим к рассмотрению вопросов управления и контроля работы, PostgreSQL часть 2.

Все статьи посвящённые PostgreSQL см.

тэг БД или поиск postgres

Подготовка PostgreSQL.

  • Стенд
  • Cервер ALT Linux, имя: lin-pq; IP 10.0.2.11;
    • PostgreSQL X.X
  • ПК Simply Linux, имя: lin-sl, IP=10.0.2.30
  • Пользователь. имя: trt

Ввод команд PqSQL.

Прежде чем перейти к описанию дальнейших действий, PostgreSQL часть 2, выясним, как формируются команды и SQL запросы.

Для ввода команд и управление запросами в среде PostgreSQL существует три способа:

Консоль пользователя.

Находясь в сеансе консоли, пользователь должен иметь право для работы с БД. Под правами подразумевается присвоение роли, терминология PgSQL, для выполнение команд в БД.

Из консоли можно выполнить ограниченное число команд.

Оболочка BASH.

Из среды BASH управление осуществляет пользователь с именем postgres. Пользователь создаётся в процессе установки PgSQL, ему присваивается роль администратора всего кластера.

Это, пока, единственный пользователь, имеющий привилегированные права для управления PgSQL.

Как добавить пользователя в привилегированную группу, читайте в следующих частях.

Команда для входа в BASH.

$ sudo su - postgres -s /bin/bash
  • sudo — выполнить команду от имени другого пользователя
  • su — добавить права суперпользователя
  • s — путь к оболочке
  • /bin/bash — имя оболочки

Среда BASH позволяет выполнять основные команды управления сервером БД.

Интерактивный клиент psql.

Интерактивный клиент psql имеет расширенные и более гибкие возможности для работы с PqSQL, включая сложные SQL запросы.

Установленный сервер из коробки имеет метод авторизации trust. Это означает, что при подключению к серверу, находясь в консоли, пароль вводить не требуется.

Все доступные методы авторизации читайте в других частях.

Команда для входа в окружение psql выглядит так.

$ psql -Uuser -p[port]
  • Ключи.
  • -d имя базы данных
  • -h имя сервера
  • -p номер порта сервера, можно не указывать если стандартный
  • -U имя пользователя

Таким образом, основными средами управления PgSQL являются BASH и Psql.

Настройка клиента.

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

Осуществить удалённое подключение к PgSQL с помощью клиента psql можно изменив параметр listen_addresses в настройках postgresql.conf сервера.

Указанный параметр использует протокол TCP/IP. По умолчанию в listen_addresses указанно значение localhost — только для локальных подключений к серверу через unix-domain socket. Это значение можно оставить без изменений при условии, что сервер PgSQL и приложения установленные на нём, например Zabbix, работают на одном сервере.

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

используя права пользователя postgres.

Теперь рассмотрим вариант, где требуется доступ пользователей к БД из сетей разных диапазонов организации.

Значение listen_addresses из коробки.

-bash-3.2$ psql
postgres=# SHOW listen_addresses;
 listen_addresses
------------------
 localhost
(1 строка)
\q

Меняем параметр listen_addresses с localhot на  *.  Переменная * позволяет разрешить подключение к серверу PgSQL из всех сетевых диапазонов организации по протоколу TCP/IP.

Корректировка listen_addresses .

-bash-3.2$ psql postgres=# \! sed "s/.*listen_addresses =.*/listen_addresses = '*'/" -i /var/lib/pgsql/data/postgresql.conf

Перегружаем сервер для перечитывания новых значений.

-bash-3.2$ pg_ctl restart

Контролируем фиксацию значение.

-bash-3.2$ psql 
postgres=# SHOW listen_addresses;
 listen_addresses 
------------------
 *
(1 row)
\q

При желание параметр  *  можно сузить до нужного диапазона сети.

Журнал PqSQL.

Сервер PqSQL позволяет вести журнал производительности и ошибок своей работы. При установке сервера, режим журналирования отключен. Пользователь, при желании, может включить контроль записи работы сервера с помощью журнала, отредактировав файл postgresql.conf. После наших действий в дереве каталога /var/lib/pgsq/data создаётся папка log, для хранения файлов журналов

Папка журналов PgSQL.
Папка журналов PgSQL.

Команда включающая режим журнала.

# \sed "s/.*logging_collector =.*/logging_collector = 'on'/" -i /var/lib/pgsql/data/postgresql.conf

Перегружаем сервер для перечитывания новых значений.

-bash-3.2$ pg_ctl restart

Контролируем фиксацию значения.

-bash-3.2$ psql
postgres=# SHOW listen_addresses;
 listen_addresses 
------------------
 *
(1 строка)

Заключение.

В этой части конспекта рассмотрены базовые основы конфигурации и первичного управления сервером PgSQL. Понимание основ позволяет уверенно чувствовать себя при погружение в тему управления сервером баз данных PostgeSQL в дальнейшем.

Полезные сылки.

Восстановление Zabbix PostgreSQL.

Ведение.

После того, как была создана резервная копия Zabbix PostgreSQL, переходим к рассмотрению вопроса восстановления сервера Zabbix PL/pgSQL из backup.

Все статьи посвящённые Zabbix см. полезные ссылки.

или тэг zabbix

Прежде всего необходимо определить причину и степень аварии.

  • Что могло сломаться:
    • не запускается БД
    • вышел из строя диск
    • сервер не запускается
    • сломаться могло всё что угодно

Подготовка.

  • Стенд
    • ALT Linux сервер, имя lin-zab; ip-10.0.2.13;
    • PostgreSQL
    • zabbix_23_back.tar.bz2 — созданный архив

Установив, предварительно, причину отказа Zabbix, приступаем к действиям, которые помогут полностью восстановить работу системы мониторинга. Мы, «придя в сознание», вспоминаем — у нас есть файл(ы) созданные резервным копированием, которые не поленились сделать. «Buckup наше всё!»

Ошибка связанна с БД.

Неисправность БД zabbix— сервер не запускается, в журнале читаем сообщения об отказе при запуске. Самое простое решение, не требующее большого времени на поиск неисправности — удаляем старую БД и восстанавливаем новую из backup. Конечно, мы сначала попытаемся исправить ситуацию, запустив команду проверки и исправления БД.

$ sudo su - postgres -s /bin/bash
-bash-X.X$ pg_amcheck -a
-bash-X.X$ pg_ctl restart

Если база не восстановилась, даже после перезагрузки PqSQL, переходим к процедуре восстановлению из резервной копии.

Восстановление БД PL/pgSQL.

Сразу надо отметить — резервное копирование БД Zabbix, выполнялось в режиме backup одной базы.

PqSQL допускает два режима создания резервной копии — целевой базы с помощью программы pg_dump и кластера pg_dumpall.

в архиве zabbix_23_back.tar.bz2 хранится только бд zabbix

Для начала следует разархивировать актуальную резервную копию в которой, вместе с другими файлами, находится dump БД zabbix.

# tar xvf zabbix_23_back.tar.bz2
# cd /tmp/zbk
...

Восстановить БД можно только при наличие «чистой» базы zabbix, иначе некуда буде копировать данные.

$ sudo su - postgres -s /bin/bash
-bash-X.X$ createdb zabbix

Теперь можно запустить процесс восстановления.

# psql -d zabbix -f zabbix.bd
  • d — имя БД
  • f — имя_файла

Восстановление сервера PL/pgSQL

Ранние было рассмотрено восстановление Zabbix после того, как обнаружили разрушенную БД. Это при наличие backup, задача не очень трудная, занимает мало времени и практически не влияет на аналитику сбора мониторинга сети.

Другое дело если выходит из строя сервер или отказывает HDD. Здесь уже требуется больше времени на поиски «железа» и установки базовой конфигурации сервера для восстановления Zabbix.

На новом оборудовании, требуется выполнить действия, которые осуществлялись при развёртывание сервера.

  • Восстановить:
    • имя сервера
    • IP сервера
    • пароль PgSQL
    • ту же версию Zabbix

После того, как сервер заработал и система мониторинга Zabbix пришла в готовность. Выполните действия по восстановлению БД из резервной копии, как описывалось выше.

Заключение.

Работа Zabbix обычно проходит ровно, в штатном режиме. Информация потихоньку собирается, аналитические отчёты, после прохождения проверки, отправляются в архив. Вся эта идиллия внезапно может закончится после того, как что-то выходит из строя. Вот здесь то, на первое место и выходит знание технологического порядка восстановления сервера Zabbix и практическое его применение.

Проверьте на стенде свои действия при восстановление Zabbix PgSQL.

выручит в дальнейшем

Полезные ссылки.

Резервное копирование Zabbix PostgreSQL.

Введение.

Продолжая публикации о Zabbix, см.полезные ссылки, переходим к обсуждению вопроса создания резервной копии Zabbix PostgreSQL.

Многие админы согласятся — «Buckup наше всё!» и это действительно так. Что бы мы не делали и какие бы усилия не прикладывали, всё окажется бесполезным если нет возможности к восстановлению программы после краха.

Подготовка.

  • Стенд
    • ALT Linux сервер, имя lin-zab; ip-10.0.2.13;
    • БД PostgreSQL

План создания резервной копии.

  • Что надо сохранить:
    • dump БД
    • настройки сервера
    • настройки серверного агента
    • журналы

dump БД — содержит структуру и контент базы данных

  • Каталоги Zabbix.
    • /etc/zabbix — файлы агентов
    • /var/www/webapps/zabbix/ui — рабочий каталог
    • /var/www/webapps/zabbix/ui/conf/zabbix.conf.php — настройки
    • /var/log/zabbix — журналы Zabbix
    • /usr/share/doc — пакеты Zabbix
    • /var/lib/pgsql — папки кластера БД PostgreSQL
    • /usr/share/pgsql -пакеты PostgreSQL

Содание dump PostgreSQL.

Для создания резервной копии воспользуемся программой pg_dump — выгрузить только одну БД zabbix.

# pg_dump -Upostgres zabbix > zabbix.db

Для backup кластера PgSQL используйте программу pg_dumpall.

pg_dumpall предназначена для «выгрузки» всех БД кластера

Копирование каталогов Zabbix.

Вся информация о работе агентов Zabbix и настройках подключённых узлов- хранится в БД

Для копирования каталогов используем утилиту cp.

# cp -r /etc/zabbix/zabbix_server.conf /home/bkz # cp -r /etc/zabbix/zabbix_agentd.conf /home/bkz # cp -r /var/www/webapps/zabbix/ui/conf/zabbix.conf.php /home/bkz # cp -r /var/log/zabbix /home/bkz

Мы сохранили необходимые файлы для восстановления сервера мониторинга вводя команды с консоли.

Автоматизация Backup PostgreSQL.

Консольное выполнение команд backup удобно для выборочного резервного копирования, но не достаточна, когда система включена в технологический процесс работы ИТ предприятия.

Для выполнения backup по заданному расписанию создадим файл zbk.sh командной оболочки bach, с инструкцией к исполнению при обращении к нему.

Напишем файл zbk.sh командной оболочки bach с инструкцией к исполнению при обращении к нему.

#!/bin/bash TEMPDIR=/tmp/zbk/ BACKUPDIR=/home/ mkdir -p $TEMPDIR # Создать dump PostgreSQL копировать во временный каталог pg_dump -Upostgres zabbix > $TEMPDIR/zabbix.db # Копировать конфиги во временную директорию cp -r /etc/zabbix/zabbix_server.conf $TEMPDIR cp -r /etc/zabbix/zabbix_agentd.conf $TEMPDIR cp -r /var/www/webapps/zabbix/ui/conf/zabbix.conf.php $TEMPDIR cp -r /var/log/zabbix $TEMPDIR # Сжать и добавить дату создания(максимально до 31 дня месяца) tar -cjf $BACKUPDIR/zabbix_`date +%d`_back.tar.bz2 $TEMPDIR # Очистить временный каталог rm -rf /tmp/zbk

Файл содержит всё необходимое для последовательного выполнения действий по созданию Backup Zabbix PostgreSQL

Созданный архив будет иметь название и формат записи: zabbix_23_back.tar.bz2

Выполнение Backup PostgreSQL Zabbix.

Сценарий zbk.sh следует поместить в /usr/local/bin с правами.

# chmod 744 /usr/local/bin/zbk

/usr/local/bin — пользовательский каталог хранения сценариев оболочки bash

Скрипт zbk.sh, для проверки, можно запускать с консоли.

# zbk.sh

Для выполнения запуска программ по расписанию используем cron.

cron — планирует выполнение команд в указанные даты и время

Формирование расписания для backup zabbix postgreSQL.

# crontab -e
minute (0-59),
| hour (0-23),
| | day of the month (1-31),
| | | month of the year (1-12),
| | | | day of the week (0-6 with 0=Sunday).
| | | | | commands
00 00 * * 0 zbk

Заключение.

В статье блога приведены рекомендации и приёмы создания резервной копии Zabbix установленного на PostgreSQL. Мы рекомендуем провести несколько контрольных операций построения резервной копии на стенде.

Созданные архивы лучше хранить на отдельном сервере или устройстве для резервных копий вашей компании.

Восстановление резервной копии читайте в разделе полезные ссылки.

Полезные ссылки.