Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=523540 --- Comment #56 from Romain Wartel <romain.wartel@xxxxxxx> 2010-04-14 08:52:35 EDT --- Thanks for the update Simon. I have had some discussions with Dirk Engling (opentracker author) and he kindly fixed the root cause of the segmentation fault, changed the default chroot behavior, and enabled the opentracker uid to be selected in the configuration time. Just what we needed, thanks Dirk! I am a bit concerned with having multiple packages and if at all possible, given the chroot issue is fixed upstream, I would like to avoid having a separate RPM based on the chroot configuration. Note also that it is not necessary to move the configuration file into the chroot jail, only the white/black list needs to be. In our environment, the configuration file is in /etc/opentracker-ipv4/opentracker-ipv4.conf, and our whitelist is /var/opentracker/torrents.conf. I have disabled the whitelist option in the configuration file as a default. In other words, opentracker is now completely open by default, unless "access.whitelist" is later populated in the configuration file, then the option becomes active upon service restart. I hope this is a good compromise for everyone. To summarize, from the CVS snapshot from 2010-04-14, there are patches to: - change slightly the default configuration file - enable a "daemon mode" - modify some of the Makefile parameters - have init.d scripts to enable service start/stop/restart Thanks to the fixes made by Dirk upstream, opentracker is now integrated nicely within our environment. Given the files are extremely small, I will attach below the tarball, SRPM and the x86_64 build we use here, for those interested. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review