---
title: "E-mailowy Service Desk z self-hosted GitLab EE i iRedMail"
url: https://michalasobczak.pl/pl/posts/e-mail-service-desk-with-self-hosted-gitlab-ee-and-iredmail.html
author: "Michał Sobczak"
description: "Aby przetwarzać przychodzące wiadomości e-mail jako issues rejestrowane w GitLabie, potrzebujesz skrzynki catch-all i GitLaba skonfigurowanego do jej obsługi. Jest jednak kilka niuansów, które trzeba znać przy konfiguracji. Zakładam, że masz zainstalowany GitLab oraz iRedMail."
published: 2024-05-21T12:42:41.000Z
updated: 2024-05-21T12:43:14.000Z
language: pl
categories: ["Technology"]
tags: ["DevOps & Automation", "Mail & Messaging"]
license: CC BY-NC-ND 4.0 (https://creativecommons.org/licenses/by-nc-nd/4.0/)
---
# E-mailowy Service Desk z self-hosted GitLab EE i iRedMail

**Aby przetwarzać przychodzące wiadomości e-mail jako issues rejestrowane w GitLabie, potrzebujesz skrzynki catch-all i GitLaba skonfigurowanego do jej obsługi. Jest jednak kilka niuansów, które trzeba znać przy konfiguracji**.

Zakładam, że masz zainstalowany GitLab oraz iRedMail.

## iRedMail

Najpierw utwórz nową skrzynkę w panelu administracyjnym iRedMail. Następnie ręcznie utwórz rekord przekierowania. Możesz to pominąć, jeśli kupiłeś iRedMail Pro:

```sql
INSERT INTO forwardings 
  (address, forwarding, domain, dest_domain)
VALUES 
  ('domain.com', 'catchall@domain.com', 'domain.com', 'domain.com');
```

W tym momencie możesz sprawdzić, czy funkcja catch-all działa, wysyłając wiadomość do nieistniejącego użytkownika skrzynki. Szczególnie ważne jest sprawdzenie, czy wiadomości dotrą po wysłaniu na adres `catchall+something@domain.com`. Początkowo będą pojawiać się jako osobne foldery skrzynki, co z perspektywy GitLaba nie jest dobre. Łatwo to jednak naprawić, usuwając parametr extensions z dovecota. Zmień więc to:

```text
dovecot unix    -       n       n       -       -      pipe
    flags=DRh ... -m ${extension}
```

na to:

```text
dovecot unix    -       n       n       -       -      pipe
    flags=DRh ...
```

I uruchom /etc/init.d/postix restart

## GitLab

Jeśli chodzi o sam GitLab, sprawa jest prosta. Wystarczy edytować parametry incoming\_email\* w /etc/gitlab/gitlab.rb. Trzeba jednak użyć IMAP, więc wybierz między portami 143 i 993. Pierwszy jest przeznaczony do STARTTLS, a drugi do TLS. W przypadku domyślnej instalacji iRedMail będzie certyfikat self-signed i przychodzące e-maile nie będą działać, co swoją drogą możesz sprawdzić następującym poleceniem:

```bash
sudo gitlab-rake gitlab:incoming_email:check
```

Gdy uzupełnisz wszystkie wymagane parametry:

```bash
sudo gitlab-ctl reconfigure
```

Pamiętaj, że cała konfiguracja, którą zmieniłeś w PostgreSQL, zostanie odrzucona (/var/opt/gitlab/postgresql/data/pg\_hba.conf i /var/opt/gitlab/postgresql/data/postgresql.conf), więc musisz się tym zająć – albo przez szablony, albo umieszczając ją w głównej konfiguracji GitLaba.

Pobierz certyfikat iRedMail. Możesz go pobrać przez przeglądarkę. Zapisz go jako plik .crt w katalogu /etc/gitlab/trusted-certs. Następnie wykonaj ponownie reconfigure i jeszcze raz sprawdź łączność. Wszystko powinno działać.

## Jak z tego korzystać?

W GitLabie service desk jest automatycznie włączony we wszystkich tworzonych projektach. Znajdziesz go w Monitor – Service Desk. Znajdziesz tam również docelowy adres e-mail, na który będziesz wysyłać wiadomości do service desku. Po wysłaniu wiadomość pojawi się w tej sekcji jako issue. Możesz komentować i odpowiadać bezpośrednio z klienta poczty, bez potrzeby odwiedzania samego GitLaba.