I don't see any advantage to moving the 2 config files into share/examples/openfire/conf rather than just keeping them in share/examples/openfire as they are now.
On 5 May 2014 09:52:09 BST, Marc Peters <m...@mpeters.org> wrote: >On 05/04/14 10:36, Joachim Schipper wrote: >> On Sat, May 03, 2014 at 04:52:29PM +0200, Marc Peters wrote: >>> Hi, >>> >>> this update needs a new file in /usr/local/openfire/conf and a new >patch >>> for this new file. It is /usr/local/openfire/conf/security.xml and i >>> wanted to clear the value for <property>, so that any user can >define >>> him-/herself, what will be encrypted by openfire at the next start. >>> >>> I would like to know, how to include this new file in PLIST and add >a >>> patches directory with a new file, so that openfire will start >without >>> any further user intevention after upgrade. >> >> Just: >> + add the file to do-install (look at the existing openfire.xml?) >> + make update-plist, and ensure security.xml is added >> + copy the security.xml under the source directory to >security.xml.orig >> + make the changes you want >> + make update-patches >> >> That said, all else being equal, it's better for ports to behave as >the >> author intended/as they work elsewhere. >> >> Joachim > >The new file security.xml, can be used to encrypt properties in the >openfire.xml. The downside is, that openfire won't start without it, >and >i was not able to found any documentation about it. Just one post in >the >communityforum, where it broke authenticatin of another user, because >of >the default listing in it. > >http://community.igniterealtime.org/message/238720 > >Therefore i patch the initial list out (list can be edited at runtime >via the "System Properties" page in the Openfire console) and add the >file to the correct directory for a smoother upgrade than i initially >had ;). > >Should this issue be mentioned in the README? I rearranged the examples >section a bit. > >Patch is attached. Comments, OKs?
