> On 9/01/2017, at 9:36 PM, Răzvan Crainea <raz...@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 <bog...@opensips.org>
>> +* Mon Oct 12.2.29 Bogdan-Andrei Iancu <bog...@opensips.org>
> You are right, this is a bug in my changelog update script. I will update it
> now.
Great :)
--
Nathan Ward
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
