Пытаюсь установить gitea

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

Это не обязательно про пакеты. Это use флаги, а относятся ли он к пакетам нужно смотреть.

git никуда не денется, это пакет «групповых политик»

Как мы ставим USE флаги? Нужен git - добавляем такой USE глобально и во всех программах добавляется поддержка git. Аналогично с gitea. И вот, когда два флага глобально - такая фигня. Гента - это просто!

Это не всё еще. В сообщении pkg_postinst не написано, как создавать базу в postgress, или какую web-страницу про это читать. Я не хочу sqllite. И на генту-странице (https://wiki.gentoo.org/wiki/Gitea) тоже про конфигурирование базы ничего не сказано.

# cat /etc/gitea/app.example.ini
cat: /etc/gitea/app.example.ini: Нет такого файла или каталога

Поняятно.

действуй через docker-compose - куда проще будет

USE-флаг git у acct-user/git имеет другую семантику, что хорошо видно из ебилда. А вот то, что нет локального описания этого флага в metadata.xml у acct-user/git - это просчет, заведи на это багрепорт, если тебя это действительно волнует.

В сообщении pkg_postinst не написано, как создавать базу в postgress, или какую web-страницу про это читать.

pkg_postinst никогда не задумывался как исчерпывающий источник документации

И на генту-странице (https://wiki.gentoo.org/wiki/Gitea) тоже про конфигурирование базы ничего не сказано.

А прочитать официальную документацию по Gitea мешает что?

зачем нужен ssh-доступ пользователю git, если все другие пользователи имеют каждый своё имя, под которым и будут заходить через ssh?

В gitea доступ по ssh идёт только через пользователя git

У тебя бы не возникали такие вопросы, если бы ты хотя бы раз разворачивал gitea/gitlab или gitolite

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

Про настройку посгресса:
https://docs.gitea.io/en-us/database-prep/#postgresql
написано не всё, что можно было бы написать

Например что, если хочется TLS, но не хочется доменных имён, можно ли так настроить?

А на что ты без доменных имён будешь выпускать SSL сертификат?

на локальное имя, не доменное.

GiteaDbServer, GiteaDbClient

В конце концов, они друг друга узнают по приватному ключу, а не по имени.

А сертификаты нужны для шифрования соединения, а не для того, чтобы узнавать куда коннектиться.

Может я оба сертификата на имя «localhost» выдам, и поставлю в две соседние виртуалки, а в строке соединения буду IP-адрес указывать.

А чем локальное имя отличается от доменного?

Сходи почитай про систему доменных имён.

Выпусти самоподписанный сертификат, добавь корневой сертификат твоего самоподписанного сертификата в доверенные и заходи по SSL.

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

Ну и не совсем уверен, что без доменной зоны будет работать, но думаю должно.

Если нет - сделай FQDN имя для твоей системы.

Если всё же нужна будет DNS зона в твоей сети, то, чтобы системы в твоей локальной сети смогли нормально работать тебе придётся поднять DNS сервер для твоей зоны в локальной сети и раздавай его твоим клиентам через DHCP, либо они должны его прописать в настройках подключения, ну либо в файле hosts прописать привязку IP адреса твоего сервера к полному (FQDN) или короткому доменному имени.

Сходи погугли все неизвестные тебе термины.

Тебе на заметку, без доменного имени - это по IP адресу.

Я два самоподписанных сертификата выпущу. Один для сервера, другой для клиента. Чтобы не содержать корневой сервер, на который может полезь ПО для проверки валидности сертификатов.

Кроме доменных имён ещё бывают локальные имена, разрешаемые по другим протоколам.

Без разницы как разрешается имя и по какому протоколу, WINS (Winbind), NETBIOS, DNS, запись в hosts файле.

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

git клиенту сертификат не нужен.

Имя localhost отлично подходит под эти условия.

Я пока только gitea и postgres между собой связываю.

Чтобы не содержать корневой сервер, на который может полезь ПО для проверки валидности сертификатов.

Тебе всё равно придётся добавить твой сертификат в доверенные.

ПО в любом случае полезет проверять валидность сертификатов, в этом смысл SSL.

Имя localhost отлично подходит под эти условия.

Ну попробуй.

Но если клиент и сервер на разных ПК, то localhost на другом ПК - это ссылка на другой ПК, т.е. на 127.0.0.1.

Если клиент и сервер на одном ПК, то вообще смысла в SSL сертификате нет.

Я пока только gitea и postgres между собой связываю.

Если gitea и postgres на одном сервере, то зачем SSL между ними?

Адрес сервера прописывается в строке коннекта, а не в сертификате.

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

Для работы SSL адрес сервера должен быть указан через доменное имя.

При коннекте к гитеа серверу по SSL если ты пропишешь в качестве адреса сервера localhost - то подключаться будешь к клиенту, а не к гитеа серверу.

Нет ты конечно можешь прописать в hosts, что localhos разрешается в IP адрес гитеа сервера, но у тебя развалится работа всех прочих сервисов запускаемых на клиенте.

Т.к. localhost всегда должно разрешаться в 127.0.0.1.

Они в разных виртуальных машинах

Тогда localhost в качестве доменного имени сервера гитеа на которое ты выпускаешь SSL сертификат использовать нельзя.

localhost всегда должно соответствовать адресу в сети 127.0.0.0/8.

Используй другое.

Если доменные имена будут в нормальных зонах, ru, com, org, прочее, а не в .local, то ты можешь попробовать получить сертификат в одном из удостоверяющих центрах, например letsencrypt, но для этого нужно соблюсти ряд условий.

Погугли.

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

Что у тебя там за корпоративная сеть, которой нельзя доверять?

Может ну его из такой корпорации.

Делай тогда проброс портов через SSH туннель.

Что у тебя там за корпоративная сеть, которой нельзя доверять?

Любой корпоративной сети нельзя доверять. Ведь в каждой работают сотни излишне любопытных сотрудников.

Для работы SSL адрес сервера должен быть указан через доменное имя.

Чем это обусловлено, где это написано?

У тебя короткая память?

Прочти ещё раз: Пытаюсь установить gitea (комментарий)

«WINS (Winbind), NETBIOS, DNS, запись в hosts файле» - представляют пространства имён.

Запись из любого из этих пространств имён может быть использована как доменное имя сервера.

Главное, чтобы имя из любого из этих пространств имён разрешалось в IP адрес.

Сходи ещё почитай про nsswitch.

Это всё не техническая спецификация SSL. Имена, которые будут разрешаться в адрес, записаны не в сертификате, а в строке соединения клиента СУБД. Сходить почитать я много чего могу, но зачем читать про nsswitch мне не стало ясно из Вашего комментария.

У тебя короткая память?

Дело не в том, что память короткая, а в том, что мы опираемся на разные факты в процессе построения логических цепочек.

Имена, которые будут разрешаться в адрес, записаны не в сертификате, а в строке соединения клиента СУБД.

Для того, чтобы сертификат использовался для SSL подключения по доменному имени в его поле CN должно быть указано доменное имя на которое он выпущен.

Посмотри свойства сертификата linux.org.ru:

CN = linux.org.ru

что мы опираемся на разные факты в процессе построения логических цепочек.

Ты вообще не опираешься на факты.

Тебе не хватает знаний и ты не понимаешь большую часть того, что я тебе написал.

но зачем читать про nsswitch мне не стало ясно из Вашего комментария.

В nsswitch указывается в том числе и очерёдность просмотра (приоритет) пространств имён.

Иди учись.

для SSL подключения по доменному имени

Мне не очевидно, что в случае соединения SQL-клиента с SQL-сервером требуется подключение по доменному имени. Потому что то, что требуется для подключения указывается в строке соединения.

Иди учись

Нет ты. Ведь ты не смог доказать твои слова ссылкой на спецификации и/или стандарты.

В случае подключения по ssl к СУБД в качестве cn имени нужно указывать имя пользователя СУБД. В случае подключения по ssl через web то есть по https в качестве cn нужно указывать имя домена.

Я не собираюсь тебе ничего доказывать, ты пришёл с вопросом, Я тебе даю знания, можешь им не верить, можешь сам проверять, я доказывать ничего никому не собираюсь.

Кто ты такой, чтобы я тебе что-то доказывал, Я в своих знаниях уверен, если ты в своих не уверен - иди проверяй и учи.

Ты вообще ни слова не сказал что ты хочешь чтобы у тебя гитеа подключался к постгрес по ssl.

Ты написал что хочешь чтобы у тебя гитеа работал по ssl.

А это в первую очередь веб-интерфейс гитеа, либо выполнение гит клоне по https.

Определись в начале что ты имеешь в виду. Ты даже не понимаешь разницу этого.

действуй через docker-compose - куда проще будет

единственный правильный совет в этой теме, +1

Написал, вот здесь: Пытаюсь установить gitea (комментарий) «про настройку постргеса» «хочется TLS»

Ты додумываешь и клевещешь. Если мне покажется, что ты пидарас, ты же не станешь оправдываться?

«В случае подключения по ssl к СУБД в качестве cn имени нужно указывать имя пользователя СУБД.»

Ты же видишь, что имя пользователя - это не то же самое, что имя домена, как ты говорил ранее? Да и указывать имя пользователя можно не в CN, а в «Subject Alternative Name». И написано это в документации по gitea, а на самом деле надо поискать в документации к postgress.

В документации https://www.postgresql.org/docs/current/auth-pg-hba-conf.html вообще написано, что шифрование канала это одно, а аутентификация клиента это другое.

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

Написал, вот здесь: Пытаюсь установить gitea (комментарий) «про настройку постргеса» «хочется TLS»

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

Ты додумываешь и клевещешь.

Согласен, напутал.

Если мне покажется, что ты пидарас, ты же не станешь оправдываться?

Мне без разницы что тебе кажется. На случай, если ты ищешь пару - ищи в другом месте.

«В случае подключения по ssl к СУБД в качестве cn имени нужно указывать имя пользователя СУБД.»

Вот пример настройки SSL сертификатов для пользователей

openssl req -new -x509 -days 365 -nodes -out ca.crt -keyout ca.key -subj "/CN=root-ca"
openssl req -new -nodes -out server.csr -keyout server.key -subj "/CN=dev-psql"
openssl x509 -req -in server.csr -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt openssl req -new -nodes -out client01.csr -keyout client01.key -subj "/CN=client01"
openssl x509 -req -in client01.csr -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -out client01.crt

Вот пример настройки сертифкатов для сервера:

openssl req -new -x509 -days 365 -nodes -out ca.crt -keyout ca.key -subj "/CN=root-ca"
openssl req -new -nodes -out server.csr -keyout server.key -subj "/CN=dev-psql"
openssl x509 -req -in server.csr -days 365 -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt

Ты же видишь, что имя пользователя - это не то же самое, что имя домена, как ты говорил ранее?

Я такого не говорил. Я сказал, что в случае выпуска SSL сертификата для HTTPS в поле CN указывается доменное имя. А в случае выпуска SSL сертификата для подключения к postgresql указывается имя пользователя.

В документации https://www.postgresql.org/docs/current/auth-pg-hba-conf.html вообще написано, что шифрование канала это одно, а аутентификация клиента это другое.

Молодец, что погуглил, в этом сообщении есть пример.

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

Вперёд.