Vacation - odmor koji to nije

Program "vacation" možda ne koristi previše naših korisnika, ali oni koji ga koriste ne mogu bez njega. Sve je to u redu, ali što ako vacation prestane raditi? Kako je to uopće moguće, kada je sve radilo još prošle godine? Je li uzrok nadogradnja na jessie?

Neki kolege sistemci su primjetili čudan problem: korisnicima koji koriste vacation odgovor nije stizao pošiljateljima, ali samo na neke servere. Kako je vacation podešavan preko plugina u squirrelmailu, a u međuvremenu je izvršena nadogradnja na distribuciju jessie, nije bilo jasno u čemu je zapravo problem.

Ručno podešen vacation (iz terminala), je radio uredno, barem se tako činilo.

Prvo što smo provjerili je squirrelmailov plugin. Njih ima nekoliko, i svi su zastarjeli, odnosno više se ne održavaju. No, plugin koji se koristio na serveru je ispravno kreirao datoteke .vacation.db i .vacation.msg, kao i ispravan unos u datoteci .forward (istina, malo drugačiji, u jednom retku, ali to je u redu):

\korisnik, "|/usr/bin/vacation korisnik"

No, bilo da smo koristili squirrelmailov plugin, bilo da smo ručnim podešavali vacation, rezultat je bio isti: na neke servere poruke o odsutnosti idu, na druge ne. U čemu je problem, možda nešto s DNS-om? Ne, sve se adrese uredno mogu resolvati.

Sada sumja pada na nadogradnju na jessie. Možda se promijenio program vacation, možda sada ima neke dodatne provjere? No, vacation je manje-više identičan onom u wheezyju, dakle ponaša se jednako. U man stranicama se ne spominju nikakve nove ili dodatne restrikcije. Ono što i dalje zbunjuje je kako to da neki serveri dobiju odgovor, a neki ne?

Slučaj je prilično zanimljiv, pa je jedino rješenje malo razmisliti, eksperimentirati i na kraju isprobati moguća rješenja. Nakon nekoliko dana zajedničkih napora s kolegama, pronašli smo da je problem djelomično u ljudskom faktoru, a djelomično u CARNetovom paketu Postfix (ne da paket nešto krivo radi, nego da ono što radi može prouzrokovati ovakav problem). Na ovo razmišljanje nas je naveo redak u logu:

Aug  14 13:39:41 server postfix/smtp[19586]: BC02F92924: to=<ime.prezime@domena.hr>, relay=127.0.0.1[127.0.0.1]:10024, delay=5.9, delays=0.13/0/0/5.8, dsn=2.0.0, status=s
ent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as AABF39292D)
Aug  14 13:39:41 server postfix/local[19647]: AABF39292D: to=<korisnik@domena.hr>, orig_to=<ime.prezime@domena.hr>, relay=local, delay=0.01, delays=0/0/0/0.01, dsn=2.0
.0, status=sent (delivered to command: /usr/bin/vacation korisnik)

Oznaka "orig_to" u logu označava da se adresa na neki način transformirala putem nekog od mehanizama postfixa. Uz oblik adrese s imenom i prezimenom, ova nas je oznaka asocirala da provjerimo situaciju sa aliasima.

Vacation podržava aliase, u slučaju da imate potrebu primati mail na neki alias. Ukoliko ste sad pomislili "pa koji alias, ne primam mail na nikakav alias", varate se. Svaki server koji koristi CARNetove pakete automatski dodaje alias svakom korisniku na sistemu (u datoteci /var/lib/postfix-cn/aliases_gecos).

Upravo u tim aliasima leži problem, jer je tijekom testiranja netko koristio oblik adrese "username@<server>.domena.hr", a netko standardniji oblik "Ime.Prezime@domena.hr". Otuda potiču šareni rezultati da nekome vacation radi, a drugome ne radi.

Rješenje je jednostavno, treba uz username staviti i pripadajući alias u datoteku .forward:

\korisnik, "|/usr/bin/vacation korisnik -a ime.prezime"

Domenu ne treba pisati, sistem će to sam dodati.

Što ovo znači za korisnike? Ovo znači da neće moći koristiti plugin iz squirrelmaila. Morat ćete ljudima koji žele koristiti vacation ručno dodati alias ili to napraviti promjenom u izvornom kodu plugina. Ni jedno ni drugo nije idelano rješenje, ali ukoliko korisnici žele da im radi vacation na oba oblika adrese, nešto od toga ćete morati napraviti.

Možemo se tješiti, barem smo našli što uzrokuje ovaj zanimljiv problem.