0

Attempting to join a new CentOS 6.4 client to an existing OpenVPN network. Running service openvpn start gives the error:

Options error: In [CMD-LINE]:1: Error opening configuration file: client.conf
Use --help for more information

If I use 

bash -vx service openvpn start

the service starts successfully.

If I run the cmd-line from the init.d script the service starts successfully.

It just doesn't want to start like it needs to if this process is going to work at reboot.

I am using SELinux in enforcing mode but I'm not seeing any messages in /var/log/secure or /var/log/messages indicating that SELinux is getting involved.

Suggestions?

dawud
  • 14,918
  • 3
  • 41
  • 61
ethrbunny
  • 2,327
  • 4
  • 36
  • 72
  • Try `ausearch -m avc -ts today`, and the log you need to watch is `/var/log/audit/audit.log`. – dawud Jul 15 '13 at 18:10
  • It reports "" – ethrbunny Jul 15 '13 at 18:18
  • then, either SELinux is not involved, or the AVC denials are in `dontaudit` mode. Can you please add the output of `ls -lrtZ /path/to/client.conf`? – dawud Jul 15 '13 at 18:20
  • -rw-rw-r--. root root unconfined_u:object_r:user_tmp_t:s0 /etc/openvpn/client.conf – ethrbunny Jul 15 '13 at 18:25
  • now check if that is the proper context: `matchpathcon /etc/openvpn/client.conf` and restore it if it doesn't: `restorecon -v /etc/openvpn/client.conf` – dawud Jul 15 '13 at 18:27
  • Interesting. Did the `restorecon` and it set values. Running `service openvpn start` shows that it's reading the config file now. It reports `cannot load certificate file...`. Is this the same process to update / repair? – ethrbunny Jul 15 '13 at 18:33
  • I don't know. Go check it out. Use the same commands (with the appropriate paths, of course) – dawud Jul 15 '13 at 18:35
  • To avoid me becoming a 'help vampire' please summarize your suggestions in an answer and I'll accept it. – ethrbunny Jul 15 '13 at 18:38

2 Answers2

1

The SELinux contexts on your OpenVPN configuration and certificate files are incorrect. Most likely this is because you moved them into place instead of copied them.

To resolve the issue, restore their default security contexts (this is safe to do even if they already have the right security context). This command will recursively fix the security contexts on /etc/openvpn and every file and directory under it.

restorecon -r -v /etc/openvpn
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
1

The problem seems to be the security context of some files.

The steps you need to take are:

  1. check if trying to start the service generates AVC denials

    # ausearch -m avc -ts today

    it could be the case that there were no output. You could try to disable dontaudit rules temporarily

    # semodule -DB

  2. check the permissions and security labels of the affected files and/or directories

    # ls -lrtZ /path/to/file
# ls -lrtdZ /path/to/dir

  3. query the current policy to see what is the expected security label

    # matchpathcon /path/to/file
# matchpathcon /path/to/dir

  4. if the current security label and the expected security label don't match, restore it. Note that you can restore directories recursively

    # restorecon -v /path/lo/file
# restorecon -v -R /path/to/dir

  5. try again to start the service and repeat the steps if necessary

dawud
  • 14,918
  • 3
  • 41
  • 61