This content has been marked as final. Show 5 replies
I've never personally tested that but adding cap_net_bind capability to both the permitted and effective sets for the actual program file, in your case the Java interpreter you mentionned (Actual program file means the final binary, not a symlink) should do the trick.
command would be similar to sudo /sbin/setcap 'cap_net_bind_service=ep' <yourpath>/bin/java
Obviously any Java program using that interpreter can then bind to any port.
My 2 cents
Thanks for the response. If we don't use setcap and just start DPS with sudo is there anyway to manage DPS from the DSCC without the root password? This is the one thing I'm trying to avoid.
Yes this works since 11g (126.96.36.199.0) only. You can decide to run dps as foo and start it as root. The process will bind to the low tcp port as root then switch to foo.
You can use either the root credentials or the foo credentials to manage the instance via dscc.
So in 188.8.131.52.0 I can unregister the instance and change the port to 389 and then use sudo to start / stop dps?
If using sudo would the sudoer only need permissions to /install_root/dsee7/bin/dpadm ?
Hi Jeff,1 person found this helpful
Actually I doubled check and there is still one issue with 184.108.40.206.0:
If you start dpadm as root, you can log as the original user and administer dps via dscc. However you won't be able to (re)start it from the console if you don't log as root. So it might maye administration tricky.