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

Issue #488 resolved
Former user created an issue

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)

  1. 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.

  2. 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.

  3. Janos SUTO 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.

  4. 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?

  5. 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?

  6. 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?

  7. Janos SUTO 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.

  8. 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

  9. 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...

  10. Log in to comment