SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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!
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.
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
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).
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!!
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.