SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
My question is, if a user is using, say rc.networkmanager, then presumably rc.wicd should be chmod 644 and vice versa. This appears to be borne out by the logic in rc.M.
If you want to keep both installed, like I prefer wicd, but keep along NetworkManager because it simplifies VPN connection, then disable execution for the one you don't use regularly. Otherwise I'd suggest uninstalling the one you don't use.
Originally Posted by xflow7
However, when using either rc.networkmanager or rc.wicd, should/could rc.inet1 also be disabled?
You definitely shouldn't. rc.inet1 activates network interfaces defined in /etc/rc.d/rc.inet1.conf and set default route (if defined in rc.inet1.conf). Unless you want to disable networking, don't disable this script.
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
@elvis4526: everything, but bringing up a loopback interface.
I can't say a word about NetworkManager which I didn't use yet, but for wicd there is no problem with rc.inet1 staying executable, provided that rc.inet1.conf stay or be brought back to its initial state, i.e. with no line uncommented in it.
Last edited by Didier Spaier; 08-29-2012 at 11:18 PM.
I hadn't seen any problems having both rc.inet1 (with default rc.inet1.conf) and rc.networkmanager running. I was more just interested in what was considered best practice and/or if there was an opportunity to eliminate redundant execution at boot.
Interestingly, I've just experimented with disabling rc.inet1 (chmod 644) and my loopback device still appears to get set up at boot:
Well, now I'm sure that what I wrote isn't correct. What I meant was rc.inet1 brings up network interfaces (if defined or use DHCP) and rc.wicd or rc.networkmanager only starts it's deamons. Which in fact brings up network interaces, even if these scripts don't do the same, result is the same.
My guess is network interfaces are added by udev, at least these listed in /etc/udev/rules.d/70-persistent-net.rules. I'm not sure what brings loopback up. So, yes it's possible to disable rc.inet1, but if you use DHCP I think rc.inet1 subjectively speeds booting up to "everything-is-loaded-and-ready" state, because network connection is set up during boot before Xorg starts.
I made a fool of myself, but at least I learnt something
Last edited by yenn; 08-30-2012 at 09:37 AM.
Reason: typo correction