7 Replies Latest reply on Feb 12, 2013 3:24 PM by Marco Milo-Oracle

    OUD start issue

      I installed OUD with my oracle user and not root. It worked fine until I restarted my server.

      I am now getting this error.

      [11/Feb/2013:09:54:36 -0500] category=PROTOCOL severity=SEVERE_ERROR msgID=2359728 msg=The LDAP connection handler defined in configuration entry cn=LDAP Connection Handler,cn=Connection Handlers,cn=config was unable to bind to IOException(Address already in use)

      After some research, I am seeing where my oracle account does not have the right access and that I should have done the install with root.

      Is there anything I can do to fix this issue, or should I just do a reinstall?
        • 1. Re: OUD start issue
          Marco Milo-Oracle
          the error message refers an error due to the fact that the process was unable to bind because the address was already in use... are you sure there's no other server process bound port 389?

          # netstat -na | grep ESTABLISHED | grep 389

          If it's just a matter of 'granting' the privilege to bound on a TCP "priivleged port" (<1024) and you're on Solaris 10, then you can use the following command (as root) to grant the privileges:

          # pfexec usermod -K defaultpriv=basic,net_privaddr <USER>

          • 2. Re: OUD start issue
            Yeah nothing else is using that port.

            I'm running Oracle Linux 6.3. Any idea what that same command would be in Linux?

            Edited by: 949865 on Feb 11, 2013 3:19 PM
            • 3. Re: OUD start issue
              Marco Milo-Oracle
              Well, this is then something that should be accomplished at O.S. level: granting the privileges (or 'capabilities'), which in Linux is accomplished through the 'setcap' command:

              # setcap 'cap_net_bind_service=+ep' <FULL_PATH_TO_EXECUTABLE>

              That in your case should be the 'java' executable...

              But that's a completely reverse approach: since it basically assigns the capability to the binary file itself to bind to the privileged port, not to the user owner of the process. And this may lead to other intrinsic insecurities/limitations, since every user that is granted to run that binary is able to bind to a privileged port.

              • 4. Re: OUD start issue
                I'm assuming this would be the executable I am trying to load?

                setcap 'cap_net_bind_service=+ep' /Middleware/Oracle_OUD1/bin/start-ds

                This is the executable to start the directory. I have tried to run the command as root, but am still getting the same error when trying to load the directory with my oracle user.

                Edited by: 949865 on Feb 12, 2013 2:57 AM
                • 5. Re: OUD start issue
                  Marco Milo-Oracle
                  Well, strictly speaking, this IS NOT the binary executable that binds to the TCP port, this is just the wrapper script that is used to setup the environment and start the binary.

                  And since as I said before, the 'setcap' command sets the capabilities on the 'file' itself, rather than on the user/process launching that file... you would need to set the capabilities for the 'java' command/JRE environment that you're using [which is set in the /Middleware/Oracle_OUD1/lib/_script-util.sh ]

                  • 6. Re: OUD start issue
                    Not sure what I did wrong... I set the permission on my java executable (/jdk/bin/java).

                    After I did that, I was unable to load Weblogic anymore.

                    Maybe I should do the install completely with the root user? Starting over...
                    • 7. Re: OUD start issue
                      Marco Milo-Oracle
                      Well, changing the capabilities of the system wide JVM, probably it's not the best choice...
                      I would have used a 'custom' JRE installed alongside OUD to have more control over the version, and also because all the changes wouldn't have impacted the whole system.


                      P.S.: but ... I would have preferred Solaris ;-)