> On Mon, 2010-03-15 at 13:52 -0400, JOLY, ROBERT (ROBERT) wrote: > > > > > > > > Rather than putting them into the launch script, it would > be better > > > to create a setup hook script with a very low sort order > (they are > > > launched in order by name). > > > > > > The script will be run as root, but could create those > with whatever > > > permissions are needed. > > > > Interesting - I can look into that. Just for my own > curiosity, when > > you say better, do you mean functionally better or architecturally > > better? > > Architecturally - it's identical functionally. But, for > example, if it's a separate hook script, we can install it > only on platforms that use the IBM JVM. > > Mostly, the startup script had at one point become a giant > mess of stuff that was threatening to become a serious > maintenance headache. The hooks allow things to be much more modular.
I got it but on the other hand, I do not have the skills to do such a change quickly with a high level of confidence that RPMs, upgrades and ISO build won't be broken and I cannot afford the time to learn my way through this at the moment. I understand your argument about the blob-effect but I do not think that two additional lines are going to break that 850-line-camel's back. If that is okay with you, I'll quickly edit the sipxecs start-up script to get this blocking 4.1.7 issue off by back and open a tracker to do the clean-up. That clean-up activity will eventually get scheduled and assigned when time and resources allow for it. Is that acceptable to you? > > > > I'd like to know what that's being used for, and whether or not > > > there are security implications ... > > > > I think I found exactly what you are looking for: > > http://www-01.ibm.com/support/docview.wss?uid=swg21407964 > > My guess is that its content will raise a few eyebrows. > I'll wait to > > hear from you on this before doing anything else on that subject. > > I can't believe that they made the default state of this > facility be 'enabled'. > > I'd be more comfortable also turning the thing off directly > in all our startup scripts (or property files, if we've > gotten that cleanup done). Our startup scripts are already taken care of but I have not touched the openfire startup script and do not intend on changing it because of licensing issues. Once they do deliver the Apache 2.0-license version of Openfire, we can revisit this. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
