LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   change order of scripts in rc.M to accomodate nfs over wireless (https://www.linuxquestions.org/questions/slackware-14/change-order-of-scripts-in-rc-m-to-accomodate-nfs-over-wireless-917731/)

vdemuth 12-08-2011 07:12 AM

change order of scripts in rc.M to accomodate nfs over wireless
 
Hi all,

Just after some thoughts really. The picture here is that I have a server with my media on served over nfs, so that when I boot my laptop it is available from KDE.
Problem is, the rc.M script seems to assume that mounting nfs happens directly after the wired network is setup, but prior to wireless setup.
So, any danger here if I move the mount instruction further down the script, or conversely move the call to wireless networking further up the script?
Also, is it worth letting PV know about this, perhaps for modification at his end so that everyone benefits?

Cheers to all

vulcan59 12-08-2011 08:43 AM

Not exactly answering your question but here's another solution for you which is the way I do it. I use wicd to establish the connection on my laptop and have a post-connection script defined in wicd which just runs /sbin/mount -a -t nfs.

vdemuth 12-08-2011 10:54 AM

Hi vulcan59. I do use WICD, but if you have a look in the rc.M file and see where WICD starts, it is after the command to mount other (including nfs) file systems. I am still able to utilise my nfs mounts as fstab takes care of it anyway. Just thought it might be worth pointing out, and check whether changing the rc.M script was the right way to go about it while mitigating any potential detrimental effects that action might cause while at the same time getting rid of the annoying error message on boot up.

FeyFre 12-08-2011 11:32 AM

vdemuth, you have /etc/rc.d/rc.inet1 /etc/rc.d/rc.wireless, /etc/rc.d/rc.inet1.conf and /etc/rc.d/rc.wireless.conf. And this is only places where you must configure your network to be accessible during boot. And you will never require wicd for you task.

vdemuth 12-08-2011 11:47 AM

Quote:

Originally Posted by FeyFre (Post 4545261)
vdemuth, you have /etc/rc.d/rc.inet1 /etc/rc.d/rc.wireless, /etc/rc.d/rc.inet1.conf and /etc/rc.d/rc.wireless.conf. And this is only places where you must configure your network to be accessible during boot. And you will never require wicd for you task.

Then what's the point of WICD, or for that matter NetworkManager as provided by AlienBob.

Still doesn't answer the question, but thanks anyway.

tuxrules 12-08-2011 05:16 PM

Not exactly a solution you're looking for but you can use autofs and that way NFS partitions will be mounted on-demand. I'm in the same boat as you and I could have probably changed rc.M but then I came across rc.autofs and it has worked well enough for me.

With autofs, there's a timeout after which NFS is unmounted but it is remounted automatically if you try to access your nfs share via Thunar or Dolphin.

There's a tutorial out there if you google it.

Thanks,

FeyFre 12-08-2011 05:48 PM

Quote:

Then what's the point of WICD, or for that matter NetworkManager as provided by AlienBob.
Probably to have pretty balloon to popup when network subsystem fails. ;) I'm really don't know. I never used neither wicd nor NM nor any other tool to configure network. /etc/rc.d/rc.(inet1|wireless).conf was enough form me.
I reread your message
Quote:

the rc.M script seems to assume that mounting nfs happens directly after the wired network is setup, but prior to wireless setup.
In Slackware officially wireless network is setup in the same moment as setup wired network - in rc.inet1, i.e before mounting network filesystems. If you dig deeply into rc.M, you will probably notices rc.wicd is started after startup of some critical system daemons(console-kit, messagebus). I don't thinks it is good idea to move start of rc.wicd before them, or move mount of other fs's after them.

bonixavier 12-08-2011 06:26 PM

FeyFre, if you never take your computer out with you, doing all your networking using inet1.conf makes sense. Otherwise, those network managing programs are really handy.

Mark Pettit 12-08-2011 11:00 PM

Without a shadow of doubt, the best way (as @tuxrules says - and never argue with a penguin !), is to use autofs. One of the problems with NFS is that if the server goes down, it can hang your connection, sometimes requiring a reboot. The auto-disconnect when not in use is a tremendous feature. And it's damn fast - you won't even notice it. Slight learning curve. If you want to try this, we can post our configs !

vdemuth 12-09-2011 07:05 AM

Thanks for all the feedback so far. I will look closely at autofs, and feedback here when completed as it seems the way to go.

vdemuth 12-10-2011 09:40 AM

Thanks to all for the advice. Ended up using autofs. Pretty straightforward once you get around deciphering the not so easy instructions and it does just what I am looking to achieve.

tux_dude 12-10-2011 09:54 AM

I have a similar requirement as the OP. I have a wireless laptop which needs nfs during boot, and I also need the flexibility of GUI network manager for when I'm on the road. My solution was to use both rc.inet1 and WICD. Configure rc.inet1 with your wireless setting with wpa_supplicant if you are using encryption (which you should be using). This will enable your wireless connection before your nfs volumes are mounted. When rc.M gets to WICD, it takes over the network settings allowing GUI control.

This was a complete accidental discovery on my part. I have been using rc.inet1 without the need of a GUI network manager. Since I am more of a road worrier now, I was getting annoyed with having to restart my wireless connection after reboot. I installed WICD, without changing rc.inet1 and everything just worked. When I got my second laptop, I only setup WICD which cause my NFS mounts to fail during boot. Upon comparing the rc scripts of both laptops, I discovered that rc.inet1 was still required.

I also explored autofs but it does not support nested nfs mounts. It was too much of a hassle to reconfigure my nfs mounts and the above solution didn't require any extra utility.

Richard Cranium 12-10-2011 12:41 PM

Quote:

Originally Posted by tux_dude (Post 4546571)
I also explored autofs but it does not support nested nfs mounts. It was too much of a hassle to reconfigure my nfs mounts and the above solution didn't require any extra utility.

Well, you end up using symlinks to the /net/blah/blah autofs mount point at the places you want to nest to do that.

tux_dude 12-10-2011 02:19 PM

Symlinks wouldn't work in my case. The mounts are not the same path on all my systems. The links would resolved to different path on each system. IMO, not supporting nested mount is a major limitation of autofs.

Richard Cranium 12-10-2011 10:19 PM

Quote:

Originally Posted by tux_dude (Post 4546734)
Symlinks wouldn't work in my case. The mounts are not the same path on all my systems. The links would resolved to different path on each system. IMO, not supporting nested mount is a major limitation of autofs.

Sorry, that doesn't make any sense. Could you provide a simple example of what you would like to do?


All times are GMT -5. The time now is 05:58 AM.