Uninitialized string offset: 0 in /var/www/piler/view/theme/default/templates/message/headers.tpl
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?
Comments (15)
-
repo owner -
selinux is disabled.
This is Centos 6.5 with piler 1.1.0
-
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.
-
Apache ? nginx ? mod-php ? php-fpm ? hhvm ? which version ?
-
- attached forpiler.out
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.
-
repo owner 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.
-
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?
-
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?
-
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?
-
repo owner 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.
-
Having this issue also. Any resolutions or work arounds?
-
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
-
repo owner Uhh, when someone opens an issue, I expect that everything is installed properly :-)
-
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...
-
repo owner - changed status to resolved
- Log in to comment
Do you have selinux enabled? Btw. what OS, what piler version?