Opened 13 years ago

Closed 13 years ago

#32718 closed update (fixed)

sslh updated to 1.10

Reported by: macports@… Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch maintainer Cc: nerdling (Jeremy Lavergne)
Port: sslh

Description

Please see the attached diff.

Attachments (1)

patch-portfile.diff (1008 bytes) - added by macports@… 13 years ago.

Download all attachments as: .zip

Change History (5)

Changed 13 years ago by macports@…

Attachment: patch-portfile.diff added

comment:1 Changed 13 years ago by drkp (Dan Ports)

Owner: changed from macports-tickets@… to dports@…
Status: newassigned

I noticed you added this line to the destroot phase:

    delete /var/run/sslh.pid 

What is this for? I don't see why it's needed, but if it is, it shouldn't be in the destroot phase because it removes a file outside the destroot.

comment:2 Changed 13 years ago by macports@…

Good question. That line is there because users of the previous version of sslh (1.9) will have a preexisting /var/run/sslh.pid file that is owned by root, but in 1.10 the program drops to a lower-privileged user before writing the pid file. This causes the write to be denied and the program to exit on launch. The best solution seems to be to remove the existing pid file and allow sslh to recreate it with appropriate permissions.

Your point about destroot being inappropriate is well taken; where would you suggest we put it instead? If you feel that it shouldn't be included at all and that solving the above permissions problem is an exercise best left to the user, then I suppose that's also a logical solution.

comment:3 in reply to:  2 Changed 13 years ago by drkp (Dan Ports)

Replying to macports@…:

Good question. That line is there because users of the previous version of sslh (1.9) will have a preexisting /var/run/sslh.pid file that is owned by root, but in 1.10 the program drops to a lower-privileged user before writing the pid file. This causes the write to be denied and the program to exit on launch. The best solution seems to be to remove the existing pid file and allow sslh to recreate it with appropriate permissions.

Ah, that makes sense. Wouldn't removing the pidfile on upgrade mean that it could be deleted even if there's a running sslh? Is that a problem? I suppose not, since AFAICT there's nothing checking for the pidfile.

Your point about destroot being inappropriate is well taken; where would you suggest we put it instead? If you feel that it shouldn't be included at all and that solving the above permissions problem is an exercise best left to the user, then I suppose that's also a logical solution.

It should probably be in pre- or post-activate; that'll make sure it works even if the user gets a pre-built binary archive (and thus doesn't run the destroot phase). I think it's better to do that than just adding a note and leaving it to the user.

comment:4 Changed 13 years ago by nerdling (Jeremy Lavergne)

Cc: snc@… added
Resolution: fixed
Status: assignedclosed
Version: 2.0.3

Updated in r88569. Warning message about PID added in r88570. License set in r88571.

Note: See TracTickets for help on using tickets.