<div dir="ltr"><div><div>Okay, good to know about the permissions and deleting everything below mason_data/obj. I re-created the obj directory and set it to www-data:www-data 755.<br><br></div>I ran perl -c on the main config file, with the two plugin lines commented out and not, and on the RT_SiteConfig.d/70-plugins file I made that holds those lines. In all three cases, Perl reports that the syntax is okay.<br><br></div>To make sure I'm not going nuts from all the things I've tried recently, I tested things once more. I commented out the plugin lines, ran update-rt-siteconfig and update-rt-siteconfig-4 (what's the difference?), and tried to spawn the FCGI server. It worked. Uncommented, and the FCGI server exited with status code 255 when not commented. Oh, between the two attempts I also ran the delete command you sent. Is there a step I'm missing? Maybe something so obvious you didn't think to mention it? This is clearly atypical for RT plugins, so it almost has to be something I'm missing/doing wrong.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 2:49 PM, Matt Zagrabelny <span dir="ltr"><<a href="mailto:mzagrabe@d.umn.edu" target="_blank">mzagrabe@d.umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alex,<br>
<span class=""><br>
<br>
On Fri, Sep 23, 2016 at 12:15 PM, Alex Hall <<a href="mailto:ahall@autodist.com">ahall@autodist.com</a>> wrote:<br>
> Sorry for not replying in-line. I'd like to, but Google seems to have broken<br>
> something in their accessibility, and I can't navigate the quoted text in my<br>
> reply. The joys of using a screen reader.<br>
<br>
</span>It's okay. :)<br>
<span class=""><br>
> To your questions: I ran strace, and I have a 1.5mb file of output. I don't<br>
> pretend to understand any of it, but I was scanning backwards from the<br>
> bottom, and I may have found the problem.<br>
><br>
> 12875 stat("/var/cache/request-<wbr>tracker4/mason_data/obj",<br>
> {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0<br>
> 12875<br>
> stat("/var/cache/request-<wbr>tracker4/mason_data/obj/.__<wbr>obj_create_marker",<br>
> 0x1bf8238) = -1 ENOENT (No such file or directory)<br>
> 12875<br>
> open("/var/cache/request-<wbr>tracker4/mason_data/obj/.__<wbr>obj_create_marker",<br>
> O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)<br>
><br>
> When i cleared my mason cache, I deleted the obj folder as directed. It<br>
> looks like this process can't re-create the necessary structure inside the<br>
> mason_data directory.<br>
<br>
</span>Hmmm. Okay. It looks like my install of RT recreates the obj directory<br>
- sorry for the assumptive advice.<br>
<br>
Here is a better command for clearing your mason cache, but leaving<br>
the obj directory:<br>
<br>
% sudo find /var/cache/request-tracker4/<wbr>mason_data/obj -mindepth 1 -delete<br>
<span class=""><br>
 I've made www-data the owner, but as I'm invoking this<br>
> command as root, perhaps I need to do something different? I've also given<br>
> /var/cache/request-tracker4/<wbr>mason_data 777 permissions recursively, and that<br>
> did the trick! What permissions should I set, though, to be sure it's as<br>
> secure as it needs to be?<br>
<br>
</span>On my installs:<br>
<br>
www-data:www-data and 0755<br>
<br>
You should only need to set that for the "obj" directory as the RT<br>
process will build the rest of hierarchy.<br>
<span class=""><br>
 Oh, I should say, the FCGI command I use is:<br>
><br>
> spawn-fcgi -u www-data -g www-data -a 127.0.0.1 -p 9876<br>
> /usr/share/request-tracker4/<wbr>libexec/rt-server.fcgi<br>
><br>
> www-data is the same user used in Nginx, and I gather they have to match.<br>
><br>
> Anyway, back to the extension. Now that RT is running, I once again enabled<br>
> the plugin and updated my settings (yes, my main configuration file updates<br>
> as it should). But when I ran my FCGI command, I once again got the exit<br>
> code 255 message. I deleted sason_data/obj again, but that didn't help. I<br>
> reset the permissions, but that, too, did nothing. There's something odd<br>
> happening with the extension enabled that doesn't seem to happen with it<br>
> disabled. I'm not sure what the deal is, though. Has anyone ever seen this<br>
> happen with an extension?<br>
<br>
</span>It almost sounds like your RT_SiteConfig.pm has invalid perl syntax.<br>
<br>
Run:<br>
<br>
perl -c /etc/request-tracker4/RT_<wbr>SiteConfig.pm<br>
<br>
Both before and after enabling and disabling your extension and<br>
running the update-rt-siteconfig.<br>
<span class="HOEnZb"><font color="#888888"><br>
-m<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div>Alex Hall<br></div>Automatic Distributors, IT department<br></div><a href="mailto:ahall@autodist.com" target="_blank">ahall@autodist.com</a><br></div></div>
</div></div>