[OpenSIPS-Users] 2.2.2 packaging

[Nathan Ward]

> On 9/01/2017, at 9:36 PM, Răzvan Crainea <razvan at opensips.org> wrote:
> 
> Hello, Nathan!

Hi!

> You have my answer inline.

Likewise.

> On 01/07/2017 11:10 AM, Nathan Ward wrote:
>> Hi,
>> 
>> I am running OpenSIPS 2.2.2 from RPMs from the opensips.org yum server.
>> 
>> I am trying to find out where the SPEC files to generate the CentOS (/el7) RPMs are. I don’t seem to be able to find these in GitHub. Can someone help with this?
> Nick (CC'ed) is maintaining the SPECS for the CentOS RPMs, but I am not sure all changes are integrated in the RPM files. But AFAIK, they are based on the public specs here:
> https://github.com/OpenSIPS/opensips/blob/2.2/packaging/rpm/opensips.spec.CentOS <https://github.com/OpenSIPS/opensips/blob/2.2/packaging/rpm/opensips.spec.CentOS>

I don’t believe this to be the case, as the “Version:” line says 2.2.0, while the published RPMs are 2.2.2.

>> I am hoping to submit a PR to move the ‘opensips’ binary to /usr/libexec, rather than a common $PATH location. We have had a problem where this binary was mistakenly run, rather than opensipsctl. Typically, daemon binaries that do not generally get run by users should be in /usr/libexec so that they are only very intentionally executed. This should probably go in to at the very least a minor version change as it may break some people’s custom init scripts etc.
> I am not sure I fully agree with this. /usr/libexec contain binaries that should never be run as stand-alone. But that is not OpenSIPS' case, where you can easily start it in debug mode or smth like that. For example, a similar daemon is sshd, which is located in /usr/sbin/sshd. However, internally triggered binaries, such as sftp-server are located in /usr/libexec/openssh/sftp-server. This exec should never be executed outside sshd.

Hmmm, I’ve seen other applications ship with the daemon binary in libexec.. though I can’t recall what it was off the top of my head. It seemed a sensible thing to do. It would be unusual on a production system to run the daemon binary as a user, stashing it off to the side means it’ll only be run when very clearly intended.

I am curious, why did “opensips monitor” allow it to run - I would have expected that to reject “monitor”.. the man page for “opensips” has nothing about accepting an argument like that. Perhaps a partial solution to this would be preventing the binary from running if there are unrecognised arguments?

>> On my search, I note change 9e406b2b3acfd61b39ba9679f0a599b95f56f5c2 under the 2.2.2 tag, which appears to be done with something like:
>> sed ’s/2.2.1/2.2.2/‘
>> 
>> Note the matches where . is ‘any’ not a literal period, so there are a lot of dates that get messed up:
>>  -* Mon Oct 12.2.19 Bogdan-Andrei Iancu <bogdan at opensips.org>
>>  +* Mon Oct 12.2.29 Bogdan-Andrei Iancu <bogdan at opensips.org>
> You are right, this is a bug in my changelog update script. I will update it now.

Great :)

--
Nathan Ward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170109/66d48968/attachment.html>