LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   openvpn in rc.inet1 script (https://www.linuxquestions.org/questions/slackware-14/openvpn-in-rc-inet1-script-4175505087/)

gustavoc 05-15-2014 08:58 AM

openvpn in rc.inet1 script
 
Hi,

I have my system configured and running openvpn to connecto to a remote office via an untrusted lan. Both endpoints are slackware machines. The vpn runs fine. The server also runs hostapd to create a wifi network. Now I want to "polish" the configs because a lot of the initialization is done in rc.local and this causes issues with other services such as dnsmasq ntpd, etc. This happens because the services start before the vpn and the wlan interfaces are up and running. I want to include the openvpn and hostapd initialization in the network init scripts (i suppose rc.inet1).
Has anyone faced this problem? I guess that I can just cut the relevant lines from rc.local and put them on rc.inet1 but I'm wondering if a better solution has been developed. I must say that my scripting skills are very limited.

Thanks in advance!

Gustavo
Patagonia
Argentina

rigelan 05-15-2014 10:48 AM

I put the openvpn start in my rc.local script. I've never had a need for it to be initialized earlier.

You might consider giving a sleep command to wait for openvpn to initialized before running the other part of rc.local

gustavoc 05-15-2014 01:41 PM

Hi Rigelan, thanks for your answer. I realized that my first post is not very clear (sorry for my bad english!). The initialization process goes well. In rc.local I add vlans to the eth interface, configure the wlan card, start hostapd and openvpn. Since rc.local is executed in the last place, the services that start before this don't consider the new network interfaces. The workaround that i'm using is to start all in rc.local, I don't use neither rc.ntpd nor rc.dnsmasq. I think that this is not very tidy and this is why I'm looking for a better solution.
Hope this time I can put it more clearly!

Thanks!

Gustavo.

Slax-Dude 05-16-2014 01:19 PM

You can create a script called /etc/rc.d/rc.netdevice and use it to create the virtual network interfaces you want.
This file will be executed (provided it is executable) before network services.

Code:

touch /etc/rc.d/rc.netdevice
chmod +x /etc/rc.d/rc.netdevice

I still use this method to create bonding interfaces (used for bridging interfaces as well, but that now is supported in rc.inet1)

gustavoc 05-21-2014 06:27 PM

Hi Slax-Dude,

Thanks for your answer, I didn't know this possibility. As far as I can see, this script is called from rc.modules (called in rc.S) before the initialization of the real network interfaces. This is not what I need because in that point of the boot process there are no network devices up and I can't bring up any vpn connections.
For the moment I modified the original rc.inet1 script so it executes another script inside the start block. In the new script I included all the initialization that was done in rc.local. This solution is very similar to rc.netdevice. I should call it rc.netinterface!

Insert the following after line 211 in rc.inet1:

Code:


    if [ -x /etc/rc.d/rc.netinterface ]; then
      echo "/etc/rc.d/rc.inet1: Starting virtual network interfaces" | $LOGGER
      /etc/rc.d/rc.netinterface
    fi

Then put all the startup lines in /etc/rc.d/rc.netinterface and chmod +x /etc/rc.d/rc.netinterface

Thanks all for your answers!

Slax-Dude 05-22-2014 05:20 AM

Quote:

Originally Posted by gustavoc (Post 5174914)
As far as I can see, this script is called from rc.modules (called in rc.S) before the initialization of the real network interfaces.

This is only true if your real network interfaces are not created by udev (ie: you disable udev and load modules manually through rc.modules).

Nevertheless, for your vpn to work you must have internet working already... so the right place should be rc.local anyway.

I always make custom scripts for each task, which are then called by rc.local so it doesn't get to cluttered and unreadable.

in the case of rc.netdevice I had this in it:
Code:

if [ -x /etc/rc.d/rc.bridge ]; then
      echo "/etc/rc.d/rc.bridge : Starting briges" | $LOGGER
      /etc/rc.d/rc.bridge
fi

if [ -x /etc/rc.d/rc.bond ]; then
      echo "/etc/rc.d/rc.bond : Starting bonds " | $LOGGER
      /etc/rc.d/rc.bond
fi

rc.bridge and rc.bond excuted after all real network devices were created by udev then, by the time rc.inet1 executes, all virtual network interfaces are already there and treated like any other (configured in rc.inet1.conf).

gustavoc 05-22-2014 12:50 PM

Slax-Dude, many thanks for all the info, I've learned a bit more about slackware. I've put all the initialization needed in rc.netdevice, maybe in the future I will split into separate scripts.
Thanks again!!

Gustavo.

Richard Cranium 05-23-2014 08:56 AM

Slightly OT, but I ended up putting this function at the top of my /etc/rc.d/rc.local file:
Code:

# The standard way to start a service                                         
# $1 is the name                                                               
# $2 is the log message                                                       
std_start() {
    if [ -x /etc/rc.d/rc.${1} ]; then
        if [ -z "${2}" ]; then
            echo "starting ${1} service" | $LOGGER
        else
            echo ${2} | $LOGGER
        fi
        /etc/rc.d/rc.${1} start
    fi
}

That way, I can add lines such as
Code:

std_start vde2
std_start libvirt

without having to re-type all the boilerplate.

I have another function that looks almost the same to stop things in my rc.local_shutdown file.

gustavoc 05-23-2014 01:11 PM

Hi Richard, Thanks for your solution. It should work too. Anyway the point is that I want to start the virtual interfaces before the launch of the network related services such as dnsmasq and ntpd, because, in the case of using rc.local the services does not run on the new interfaces. For example, the ntpd daemon only listens on the ethx interfaces and not on the vlans or tunnels.
For the moment both the modified rc.inet1 and rc.netdevice solutions are working fine.

Thanks.

Gustavo.

Richard Cranium 05-23-2014 06:51 PM

I guess that I should have said that my reply was "Really OT" versus "Somewhat OT".

The point that I should have made was that the function definition that I gave in the first code block would be generally useful in these init/configuration scripts so that you aren't always entering the "if [ blah ]; stuff; stuff; fi" blocks.

But I didn't actually say that and instead gave an example about rc.local to show how it's used in my case versus suggesting that you could put the same or similar function in your rc.netdevice script. Like this...
Code:

# The standard way to start a service                                         
# $1 is the name                                                               
# $2 is the log message                                                       
std_start() {
    if [ -x /etc/rc.d/rc.${1} ]; then
        if [ -z "${2}" ]; then
            echo "starting ${1} service" | $LOGGER
        else
            echo ${2} | $LOGGER
        fi
        /etc/rc.d/rc.${1} start
    fi
}

std_start bridge "/etc/rc.d/rc.bridge : Starting bridges"
std_start bond "/etc/rc.d/rc.bond : Starting bonds"

or even better
Code:

# $1 is the name                                                               
std_start() {
    if [ -x /etc/rc.d/rc.${1} ]; then
        echo "/etc/rc.d/rc.${1} : starting ${1}s" | $LOGGER
        /etc/rc.d/rc.${1}
    fi
}

std_start bridge
std_start bond

You might think that's too much of a PITA for whatever benefit it provides, and I certainly have no problem with that. :)


All times are GMT -5. The time now is 02:53 PM.