Такая ошибка блокирует доступ к базе, особенно если вы подключаетесь как postgres, но системного пользователя с таким именем нет. Мы пройдем по причинам, найдем файл конфигурации и применим проверенные фиксы. Это сэкономит часы поиска и вернет работу в норму.

Что значит peer authentication в PostgreSQL

Peer authentication — это метод проверки в PostgreSQL, который работает только для локальных подключений через Unix-сокеты. Он проверяет, совпадает ли имя системного пользователя (из ОС) с именем пользователя БД. Если вы запускаете psql -U postgres, а в системе нет пользователя postgres, сервер отвергает подключение с ошибкой «peer authentication failed».

Это защитный механизм по умолчанию в Linux-дистрибутивах вроде Ubuntu. Он удобен для разработки, где имена совпадают, но мешает в продакшене или при установке MIMIC, Docker-контейнерах и CI/CD. Представьте: вы клонируете репозиторий, пытаетесь загрузить данные в БД — и стоп. Типичный пример из GitHub-issues: разработчик не может запустить psql для MIMIC, потому что pg_hba.conf настроен на peer для всех локальных подключений.

Сервер ищет строку local all all peer в конфиге и отказывает, если пользователь не matches. Это не баг, а фича для безопасности — без пароля, но строго по именам. Теперь перейдем к поиску и редактированию файла.

• Где искать pg_hba.conf: Запустите sudo find / -type f -name "pg_hba.conf" 2>/dev/null, чтобы найти путь (обычно /etc/postgresql/*/main/pg_hba.conf).
• Редактирование: Измените local all all peer на local all all md5 или trust для тестов.
• Перезапуск: sudo service postgresql restart или sudo systemctl restart postgresql.

Пошаговое исправление ошибки peer

Сначала убедитесь, что проблема именно в peer: запустите psql без параметров — если войдет под вашим системным именем, то да, дело в несоответствии. В Ubuntu postgres часто не создается как системный юзер при установке через apt, особенно в контейнерах или VM. Поэтому psql -U postgres фейлит.

Решение №1: отредактировать pg_hba.conf. Найдите файл, откройте sudo nano /path/to/pg_hba.conf. Строка # TYPE DATABASE USER ADDRESS METHOD с local all all peer меняется на local all all md5. Сохраните, перезапустите сервис. Теперь psql -U postgres -W запросит пароль — если его нет, создайте через sudo -u postgres psql и ALTER USER postgres PASSWORD 'yourpass';.

Если вы в Docker или CI вроде AppVeyor, peer мешает скриптам вроде createdb. Там фикс — не юзать PGUSER=postgres, а полагаться на текущего юзера или менять conf на лету. В Confluence или Atlassian стеке pg_dump падает по той же причине: хост не имеет pg_hba.conf или он строг.

1. Создайте системного пользователя: sudo adduser postgres — редко нужно, но решает root-причину.
2. Подключитесь под своим юзером: psql -d yourdb -U yourlinuxuser вместо postgres.
3. Автоматизация в скриптах: Добавьте sed -i 's/peer/md5/' pg_hba.conf перед рестартом.

Нюанс: После правок проверьте pg_lsclusters — убедитесь, что кластер на правильном порту и версии.

Альтернативы и продвинутые настройки

Если md5 не подходит, настройте ident или pam — они похожи на peer, но гибче. В pg_hba.conf можно указать local postgres postgres peer для конкретного юзера. Для продакшена комбинируйте: peer для локалки, scram-sha-256 для TCP.

В CI/CD (AppVeyor, GitHub Actions) часто юзают init-скрипты: меняют conf перед стартом postgres сервиса. Пример: в yml добавьте шаг echo 'local all all md5' >> pg_hba.conf. Это решает createdb: FATAL: Peer authentication failed for user "postgres". В MIMIC-code issues рекомендуют именно это + рестарт.

Если база в контейнере, монтируйте volume с измененным conf или юзайте POSTGRES_HOST_AUTH_METHOD=md5 в docker-compose. Для Atlassian/Confluence: проверьте, есть ли pg_hba.conf вообще — иногда bundled Postgres его игнорирует.

• scram-sha-256: Современный метод (PostgreSQL 10+), хэширует пароли солиднее md5.
• TCP-подключения: Всегда md5 или выше, peer не работает по сети (host all all 127.0.0.1/32 md5).
• Логи: /var/log/postgresql/ покажет точную причину отказа.

Когда peer все-таки стоит оставить

Peer хорош для командной работы: каждый dev подключается под своим Linux-именем без паролей. Но только если все юзеры в БД созданы заранее. В крупных проектах это упрощает деплой — нет нужды хранить пароли в env.

Если ошибка persists после фиксов, проверьте SELinux/AppArmor — они блокируют сокеты. Или версия PostgreSQL: в 14+ peer строже с группами. Подумать стоит над миграцией на роли с GRANTами вместо суперюзера postgres.

Другие аспекты: ротация паролей, аудит логов, миграция на облачные RDS с IAM-аутентификацией. Там peer неактуален, но базовые принципы те же.