Uninitialized string offset: 0 in /var/www/piler/view/theme/default/templates/message/headers.tpl

[Former user]

I'm trying to get mail piler installed on my system. After a bit of work I have it installed. I was able to import messages in to the archive and am now trying to test it out.

While searching as the main auditor I see the messages in the list. However, when pressing the view messages or view headers buttons I do not see any text there. When downloading the messages I see empty files downloaded.

Looking at the logs I see a lot of these:

[Tue Jan 27 12:24:52 2015] [error] [client 1.2.3.4] PHP Notice: Uninitialized string offset: 0 in /var/www/piler/view/theme/default/templates/message/headers.tpl on line 23, referer: http://myhost/search.php [Tue Jan 27 12:24:52 2015] [error] [client 1.2.3.4] PHP Notice: Uninitialized string offset: 0 in /var/www/piler/view/theme/default/templates/message/headers.tpl on line 31, referer: http://myhost/search.php

Any thoughts on what that is or why it comes up?

[Janos SUTO]

Do you have selinux enabled? Btw. what OS, what piler version?

[Scott Savarese]

selinux is disabled.

This is Centos 6.5 with piler 1.1.0

[Scott Savarese]

Some other weird behaviors that may help you isolate this...

In the search view, if a message has an attachment, the attachment is 0 bytes as well. When I go to download the attachment it is empty. When it tries to display the attachment, it comes up with an error.

All messages are showing "Message Failed Verification" next to the print button.

[eXtremeSHOK]

Apache ? nginx ? mod-php ? php-fpm ? hhvm ? which version ?

[Scott Savarese]

Attached is the output of rpm -qa and a cat of the piler config files. I'm probably missing something silly.

You'll notice that there is a piler rpm in the RPM output. I'm playing with the piler spec file and making this an RPM package. I can send you that as well if you want.

[Janos SUTO]

Check if you can retrieve an email with pilerget, eg.

pilerget 4000000054ca1700217e6cbc00e31e7ba50b

Look at the maillog for existing piler ids. Run the command as user piler.

[Scott Savarese]

Yes. I am able to retrieve mails with pilerget (I tried several) including ones I know not working in the web page. Messages with attachments show them as encoded. I guess this means the problem is limited to PHP somewhere?

[Scott Savarese]

I'm a step closer, but I think the issue is very different now...

After scanning the PHP it looks like pilergetd wasn't started (had to set the path to PEM file in the config). Once I got that going I'm starting to see better errors in the maillot:

#!

Jan 30 11:05:21 myhost pilerget[54758]: /var/piler/store/00/89/03/f6/4000000054c7bd9728cab5fc009cad8903f6.m: cannot open()
Jan 30 11:05:21 myhost pilerget[54761]: /var/piler/store/00/89/03/f6/4000000054c7bd9728cab5fc009cad8903f6.m: cannot open()
Jan 30 11:05:23 myhost pilerget[54766]: /var/piler/store/00/3c/2c/b4/4000000054c7cd04348b83e400a20f3c2cb4.m: cannot open()
Jan 30 11:05:23 myhost pilerget[54769]: /var/piler/store/00/3c/2c/b4/4000000054c7cd04348b83e400a20f3c2cb4.m: cannot open()

However, I can definitely see those messages when I run pilerget directly (works as piler user as well):

#!

[root@myhost store]# pilerget 4000000054c7bd9728cab5fc009cad8903f6
Subject: test mail for archiving

asdkcjnasdkcasdc
asdcasdc
asdcasdc
asdc
testing 123
[root@myhost store]# pilerget 4000000054c7cd04348b83e400a20f3c2cb4
Subject: test123

casdcasd
casdc
asdcasdcasdca

It actually looks like pilerget is going to the wrong place when called via the webui but when called on the command line it goes properly. The files do exist:

#!

[root@myhost store]# find /var/piler/store/00 -name 4000000054c7bd9728cab5fc009cad8903f6*
/var/piler/store/00/54c/03/f6/4000000054c7bd9728cab5fc009cad8903f6.m
[root@myhost store]# find /var/piler/store/00 -name 4000000054c7cd04348b83e400a20f3c2cb4*
/var/piler/store/00/54c/2c/b4/4000000054c7cd04348b83e400a20f3c2cb4.m

Any thoughts?

[Scott Savarese]

OK... so digging in to the C code I see that there are two different strings piler uses to find a message in the store directory. If it can't find it the first way (checked by stat) it tries the second way and if it can't find it, it reports it in the logs. I originally thought that the webui called pilergetd which called pilerget, but that is wrong. pilerget is called directly from the webui which runs as apache. But the store is set so that apache can't see the files. pilerget and pileraget need to be setuid piler.

One suggestion I would make here is that there are several of these:

   snprintf(*buf, buflen, "%s/%02x/%c%c%c/%c%c/%c%c/%s", cfg->queuedir, cfg->server_id, f[8], f[9], f[10], f[RND_STR_LEN-4], f[RND_STR_LEN-3], f[RND_STR_LEN-2], f[RND_STR_LEN-1], f);
   if(!stat(*buf, &st)) return st.st_size;

   snprintf(*buf, TINYBUFSIZE-1, "%s/%02x/%c%c/%c%c/%c%c/%s", cfg->queuedir, cfg->server_id, f[RND_STR_LEN-6], f[RND_STR_LEN-5], f[RND_STR_LEN-4], f[RND_STR_LEN-3], f[RND_STR_LEN-2], f[RND_STR_LEN-1], f);
   if(!stat(*buf, &st)) return st.st_size;

in the code. Perhaps moving all of them to use stat_file instead of having it all over would allow you to trap the stat command differently. Instead of erroring "Can't open file" you can trap the permission denied error and if that is seen output something different?

[Janos SUTO]

Good idea, I'll think about it. Older versions featured a different directory layout, so that's why the fallback approach you spotted above. Perhaps I'll add an extra configure option, eg. --compat-layout or something, and recent version won't give a misleading report where they can't find the message.

[wgs_da]

Having this issue also. Any resolutions or work arounds?

[Scott Savarese]

My issue was permissions related. Check to make sure that the apache process which runs pilerget has the permissions to read the files in the store.... For me that means chmod u+s the pilerget and pileraget executable which I didn't do originally in the RPM I built. I believe those binaries are supposed to setuid according to the docs I've seen

[Janos SUTO]

Uhh, when someone opens an issue, I expect that everything is installed properly :-)

[Scott Savarese]

Yeah, that was my bad... I was trying to use the spec file to build an RPM file. It turns out that the spec file is way old and didn't have it...