Redmine 3.3.0-1 E-mail értesítés auth probléma

Linux-haladó

Sziasztok!

Van egy Redmine 3.3.0-1 verzó telepítve az egyik Debian szerveremre, ami egyben mail szerver is.

A napokban szigorítottam némileg az smtp konfigon, és sajnos azokkal a beállításokkal nem igazán hajlandó együttműködni a redmine.

Adott a configuration.yml file, amely esetemben a /var/redmine-3.3.0-1/apps/redmine/htdocs/config - könyvtárban helyezkedik el.

Itt szeretném az SMTP settings szekciót úgy beállítani, hogy az működjön a login tipusú authentikacioval is.

Jelenleg is biztonságosnak mondható a küldés plain authentikációval, mert kizárólag 587-es porton lehet küldeni, és pl. thunderbird esetében nem működik, csak felhnév és jelszó megadása után a levélküldés, de ha ebben az esetben a configuration,yml filet módosítom oly módon, hogy az login mdon authenticaljon és ne plain módon, illetve beadom a user_name és password combót, akkor konkrétan összeomlik a redmine és a főoldal sem tölt be, az allábbi hibára hivatkozva az apache error logban:

 age/Hel/Req/CheckoutSession.cpp:252 ]: [Client 3-1] Cannot checkout session because a spawning error occurred. The identifier of the error is aa2621a9. Please see earlier logs for details about the error.

 

Jelenleg így néz ki az smtp szekció a configuration.yml-ben, ami működik is:

default:
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: mail.mydomain.hu
      port: 587
      domain: mail.mydomain.hu
      authentication: :plain
      enable_starttls_auto: true
      openssl_verify_mode: 'none'

ezzel viszont összeomlik, pedig ez lenne a biztonságosabb megoldás:

default:
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: mail.mydomain.hu
      port: 587
      domain: mail.mydomain.hu
      authentication: :login
      user_name: hibajelentes@mydomain.hu
      password: Passw0rrd
      enable_starttls_auto: true
      openssl_verify_mode: 'none'

Igazság szerint nekem bőven elég lenne, ha elfogadná a login authot az e-mail értesítések küldéséhez, mert így fogalmam sincs, hogy küld e-mailt, amikor a 25-ös port tiltva van, az 587-en meg elvileg csak login auth után lehet küldeni levelet, legalábbis minden kliensen kizárólag így működik, ez a redmine viszont "localhoston" üzemel.

 

Valaki, aki esetleg jobban belemélyedt a redmine lelkivilágába tudna segíteni, hogy mit ronthatok el?

Előre is köszönöm a segítő hozzászólásokat!

  • 157 megtekintés

( neutrino v | 2022. 06. 23., cs – 09:33 )

Na és ha az address helyére 127.0.0.1-et írsz? Minek megjáratni a FQDN-t, miközben ugyanazon a gépen van?

1904.04.08.
RIP Jákub.
neut @

( NevemTeve | 2022. 06. 23., cs – 09:40 )

Szerkesztve: 2022. 06. 23., cs – 11:15

Use the source, Luke: ez a 'spawning error' úgy hangzik, mint egy lehetőség egy izgalmas hibakeresésre. (Mondjuk valamilyen extrém alacsony ulimit érték miatt nem tudott forkolni?)

Szerk: mondjuk itt látni vélek egy kisebb lemaradást a RedMine-verzióban.

Kicsit zavaró, hogy nincs semmilyen CheckoutSession.cpp a RedMine-ban; lehet, hogy a ruby interpreter-ben van ilyen. (Kicsit furcsállom, hogy miért nincsenek egyes részek PL/I-ben, mások meg Turbo Pascal 2.0-ban megalkotva.)

Random google-találatok szerint a httpd.conf-ban (vagy máshol?) van egy ilyen sor:

PassengerRuby /usr/bin/ruby2.0

és esetleg ez romlott el a frissítés alkalmából.

Szerk: Persze teoretikusan nincs kizárva, hogy a szoftver igazat mond, és a korábbi üzeneteket is meg kellene nézni. Pl. itt is egy hasonló eset van.

( ggallo | 2022. 06. 23., cs – 21:20 )

Úgy gondolom, hogy nem a Redmine lesz a gond, hanem a PLAIN és a LOGIN értelmezése körül lesz inkább a hiba... Ugyanis nem úgy van, hogy a PLAIN jelszó nélküli, a LOGIN meg jelszavas kapcsolódás.

Az első példában PLAIN hitelesítés van név/jelszó nélkül, míg a második példában LOGIN hitelesítés névvel/jelszóval. De ha a szerver nevet/jelszót vár, akkor mindkét esetben küldeni kell nevet/jelszót, a PLAIN és a LOGIN metódus között mindössze annyi a különbség, hogy PLAIN esetébe cleartext-ben kell küldeni a név/jelszó párost, míg LOGIN esetében BASE64 kódolva. Ettől eltekintve tök egyformán működnek. De akár úgy is konfigurálhatod a szervert, hogy localhost-ról hitelesítés és TLS nélkül is fogadjon kézbesítésre levelet (elvileg nincs nagy kockázat), máshonnan meg csak hitelesítve (plusz TLS felett).

A levelező szerver beállítást nem ismerjük (egyáltalán, a PLAIN és/vagy a LOGIN módszer engedélyezve van-e), de az biztos, hogy ha a LOGIN elérhető, akkor BASE64 kódolás kell (ami a példában nincs). Vagy csak simán maradjon PLAIN, localhost-on elég kicsi a valószínűsége, hogy lelopja valaki a jelszót traszpont közben (meg aztán a BASE64-es dekódolni azért nem atomfizika)...