Re: Enabling extensions in RT4.2.8?

Matt Zagrabelny <[email protected]>
Newsgroups gmane.comp.bug-tracking.request-tracker.user
Message-ID <CAOLfK3WjkLTBPGPveuYnuguHgMbY45zJNyFPzdKRp7J50quxdg@mail.gmail.com>
Hi Alex,


On Fri, Sep 23, 2016 at 12:15 PM, Alex Hall <[email protected]> wrote:
> Sorry for not replying in-line. I'd like to, but Google seems to have broken
> something in their accessibility, and I can't navigate the quoted text in my
> reply. The joys of using a screen reader.

It's okay. :)

> To your questions: I ran strace, and I have a 1.5mb file of output. I don't
> pretend to understand any of it, but I was scanning backwards from the
> bottom, and I may have found the problem.
>
> 12875 stat("/var/cache/request-tracker4/mason_data/obj",
> {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
> 12875
> stat("/var/cache/request-tracker4/mason_data/obj/.__obj_create_marker",
> 0x1bf8238) = -1 ENOENT (No such file or directory)
> 12875
> open("/var/cache/request-tracker4/mason_data/obj/.__obj_create_marker",
> O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
>
> When i cleared my mason cache, I deleted the obj folder as directed. It
> looks like this process can't re-create the necessary structure inside the
> mason_data directory.

Hmmm. Okay. It looks like my install of RT recreates the obj directory
- sorry for the assumptive advice.

Here is a better command for clearing your mason cache, but leaving
the obj directory:

% sudo find /var/cache/request-tracker4/mason_data/obj -mindepth 1 -delete

 I've made www-data the owner, but as I'm invoking this
> command as root, perhaps I need to do something different? I've also given
> /var/cache/request-tracker4/mason_data 777 permissions recursively, and that
> did the trick! What permissions should I set, though, to be sure it's as
> secure as it needs to be?

On my installs:

www-data:www-data and 0755

You should only need to set that for the "obj" directory as the RT
process will build the rest of hierarchy.

 Oh, I should say, the FCGI command I use is:
>
> spawn-fcgi -u www-data -g www-data -a 127.0.0.1 -p 9876
> /usr/share/request-tracker4/libexec/rt-server.fcgi
>
> www-data is the same user used in Nginx, and I gather they have to match.
>
> Anyway, back to the extension. Now that RT is running, I once again enabled
> the plugin and updated my settings (yes, my main configuration file updates
> as it should). But when I ran my FCGI command, I once again got the exit
> code 255 message. I deleted sason_data/obj again, but that didn't help. I
> reset the permissions, but that, too, did nothing. There's something odd
> happening with the extension enabled that doesn't seem to happen with it
> disabled. I'm not sure what the deal is, though. Has anyone ever seen this
> happen with an extension?

It almost sounds like your RT_SiteConfig.pm has invalid perl syntax.

Run:

perl -c /etc/request-tracker4/RT_SiteConfig.pm

Both before and after enabling and disabling your extension and
running the update-rt-siteconfig.

-m
---------
RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.