Forums

cltech
cltech
Offline
Resolved
0 votes
Hello, unless I missed a bug report. openvpn in the 32bit iso is not working here is the offending statement


Dec 1 13:08:55 ca yum[22163]: Installed: 1:app-openvpn-plugin-core-1.1.0-1.v6.noarch
Dec 1 13:10:08 ca yum[22163]: Installed: openvpn-2.2.2-1.el6.i686
Dec 1 13:10:18 ca yum[22163]: Installed: 1:app-openvpn-core-1.5.5-1.v6.noarch
Dec 1 13:10:19 ca yum[22163]: Installed: 1:app-openvpn-1.5.5-1.v6.noarch

Dec 1 13:30:59 ca kernel: tun: Universal TUN/TAP device driver, 1.6
Dec 1 13:30:59 ca kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Dec 1 13:30:59 ca openvpn[7247]: PLUGIN_INIT: could not load plugin shared object /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so: /usr/lib64/openvpn/plugin/lib/openvpn-auth-pam.so: cannot open shared object file: No such file or directory: No such file or directory (errno=2)


In the 32bit install, the lib64 directory does not exist, so, for the fun of it, i made a new directory /usr/lib64/openvpn/plugin/lib/ and copied the contents of /usr/lib/openvpn/plugin/lib/ and openvpn worked fine.

I am not sure where the config file is for this, otherwise I would have attempted to correct that.

Please let me know if you need any other info.
Tuesday, December 03 2013, 11:05 AM
Share this post:
Responses (6)
  • Accepted Answer

    cltech
    cltech
    Offline
    Friday, December 06 2013, 10:11 AM - #Permalink
    Resolved
    0 votes
    Peter Baldwin wrote:

    That issue was just fixed a couple of days ago and pushed to the "clearos-updates-testing" repository yesterday. This should resolve the issue:



    Thank you for the reply. Ok, I will try the testing repo, but, I first need to address the following issue before I can start that server back up again. :)

    ClearOS 6.x in Proxmox on Dedicated server with /32 subnet
    http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,28/func,view/id,57753/
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 04 2013, 03:21 PM - #Permalink
    Resolved
    0 votes
    That issue was just fixed a couple of days ago and pushed to the "clearos-updates-testing" repository yesterday. This should resolve the issue:

    yum --enablerepo=clearos-updates-testing upgrade app-openvpn

    It was just a simple copy/paste error. Doh. We should really patch OpenVPN and push it upstream -- it's not goo practice to have embedded lib/lib64 paths in a configuration file.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 04 2013, 10:46 AM - #Permalink
    Resolved
    0 votes
    The devs may see it but no guarantees. You need a bug-tracker account to report it. I may get some time today to check the bug tracker and report it if nothing is there.
    The reply is currently minimized Show
  • Accepted Answer

    cltech
    cltech
    Offline
    Wednesday, December 04 2013, 10:43 AM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    , but really the bug needs to be fixed.


    oh, do I need to do anything different to report this? I assumed the devs would see this post since it is the development section.
    The reply is currently minimized Show
  • Accepted Answer

    cltech
    cltech
    Offline
    Wednesday, December 04 2013, 10:28 AM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:
    The config files are /etc/openvpn/clients.conf and /etc/openvpn/clients-tcp.conf.

    Also, as an easier cheat, you could have created a symlink between /usr/lib64 and /usr/lib rather than replicating the files, but really the bug needs to be fixed.



    Hello Nick. Thanks for the reply. I will take a look at the config files and see if i can fix my install...good point about the symlink! thanks :)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, December 04 2013, 08:44 AM - #Permalink
    Resolved
    0 votes
    The config files are /etc/openvpn/clients.conf and /etc/openvpn/clients-tcp.conf.

    Also, as an easier cheat, you could have created a symlink between /usr/lib64 and /usr/lib rather than replicating the files, but really the bug needs to be fixed.
    The reply is currently minimized Show
Your Reply