Misha Vodsedalek wrote:
> I am supposed to fix the problem with the installation of localization 
> packages in the main stream (http://track.sipfoundry.org/browse/XECS-1557). 
> There are at least three possible options - I was wondering if anyone would 
> have an opinion with regard to which one to select. :-)
> 
> The implementation of the support for localization packages (added in 3.10) 
> included the ability to install 3rd party localization files.  As far as I 
> know, this feature was used only for an external conferencing solution which 
> is not used in 3.11.  Anyway, the directory used for these 3rd party files 
> in the 3.10 implementation was /etc/sipxpbx/third_party - that was a bad 
> choice because all these 3rd party files were included in snapshots.  Due to 
> that, early in 3.11 the directory for 3rd party files was changed to 
> /usr/share/sipxecs/third_party (well, to "sysdir.share"/third_party as used 
> by sipXconfig).  With recent changes (in revision 13080), the directory 
> "sysdir.share" was changed to /usr/share/java/sipXecs, so now the 
> destination is /usr/share/java/sipXecs/third_party.  The actual problem is 
> that the directory /usr/share/java/sipXecs has the owner and group both set 
> to root.  Due to that, sipXconfig (which runs under sipxchange) cannot 
> create the subdirectory third_party where there 3rd party files should be 
> stored.  A check in the installation script if the directory is writable 
> fails and due to that, the installation of a localization package fails 
> before any files are installed.
> 
> Option #1:
> The third party localization file support could be removed from the 
> localization context implementation and the installation script (thus 
> removing the problem with where to put the 3rd party localization files and 
> with the permissions, too).
> 
> Option #2:
> The destination for 3rd party localization files could be changed back to 
> /usr/share/sipxecs.  This directory has the correct permissions 
> (sipxchange:sipxchange), so the initial check would pass and 3rd party files 
> could be installed just fine (if any).  From looking at sipXconfig, this 
> directory (/usr/share/sipxecs) is not used anywhere in the code anymore - 
> I'd have to either hard code the directory in the localization context 
> implementation or come up with another sysdir member.  If this option is 
> eventually selected, suggestions would be welcome.
> 
> Option #3:
> The destination for 3rd party localization files could be left unchanged 
> (/usr/share/java/sipXecs/third_party), but the user and group of the 
> directory /usr/share/java/sipXecs would be changed to sipxchange:sipxchange. 
> This directory is actually used by six RPMs (subdirectories are created in 
> this directory and files stored in them).  The directory itself is not 
> specified in any of these RPMs, so default attributes are used and that's 
> why it gets root:root.  So, the solution would be adding the directory with 
> appropriate attributes to the 6 RPM spec files.
> 
> Personally, I am tempted to suggest #1 as the option to choose, but I don't 
> know if it's safe to assume that nobody started to use this functionality 
> since it was documented as few months back.  My second choice would be the 
> option #2.
> 
> Misha 
> 
> 
> 

Looks like it's been couple of days and no-one complained yet...
So I would suggest you go with #1 and if someone needs it they can re-add
it in a way described in #2
D.

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to