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.
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.
I do not recall that interaction. Are you sure you don't have memory corruption? ;-)
Seriously, sorry :/ I have no recollection at all of that exchange though, so no negative opinion was formed here :-)
That has also been my typical method for doing anything that isn't supported by the stock scripts - just replace them wholesale and keep on trucking.
No memory corruption, just less neurons, you loose them with age, so they (health experts) say. I just hope I lost the bad ones, the lazy and boring ones. https://www.linuxquestions.org/quest...ml#post5948677
I'm glad you didn't take it negative/personal, I wasn't either. I do however take the format of that damned changelog very personal, struggling to fish the important "Added"&"Removed" tags out of that rather messed up - disordered formatting.
Back to rc.inet1. Now please go back to work, Mr. workman, finish the new rc.inet1 so I can throw it in /etc/rc.d/bak/ together with a few other of his friends and keep on trucking
Hopefully Robby will be able to check it over when he gets a few minutes and kick out a new package.
But in the mean time, please grab the netconfig script (which is all that has been updated since the last package) from the above link and test test test!
I do like how the init scripts have become more flexible for admins over the past few years. rc.local_shutdown and rc.4.local are two such examples.
One thing I'd like to see added to rc.inet1 is a call-out system, pre- and post-exec. Network setup can be a chore, and specialized scripting is sometimes appropriate. Two simple opportunities come to mind.
1. Pre-exec rc.inet1 could be a place to load firmware for a network card. This way, if networking isn't started (we booted into runlevel 1), this step is skipped. NB: this is only a guess. I've actually never had to load firmware for a network interface. Other people will have their own ideas for this step.
2. Post-exec rc.inet1, once networking is set up, could be a place to grab the time from a local NTP server. Most Slackware systems wouldn't require this, but a Raspberry Pi doesn't have an on-board clock. It's better to set the system time ASAP, in case something else fails during network service startup in rc.inet2.
Having pre- and post-exec call-outs, IMHO, is better than wholesale replacement of rc.inet1 on a host. As it stands, rc.inet1 has picked up improvements over time, including some security matters. It would be nice to incorporate future improvements through the normal Slackware update process, while keeping the pre- and post-exec hooks in place.
I'm not putting this forth as a "feature request." It's simply a convenience that's on my wish list for rc.inet1.
1. Pre-exec rc.inet1 could be a place to load firmware for a network card. This way, if networking isn't started (we booted into runlevel 1), this step is skipped. NB: this is only a guess. I've actually never had to load firmware for a network interface. Other people will have their own ideas for this step.
By default, Slackware runs /etc/rc.d/rc.netdevice before rc.inet1, if the file exists and is executable (you have to create it.
Check http://www.slackware.com/config/init.php
You can use this file to load any firmware for network interfaces, as that is the original funcion of this script, although I used it in the past as a means to load virtual interfaces like bridges, bondings, VPNs, tunnels, etc... so I could configure them through inet1.conf
As others have pointed out we already have scripts that are more or less pre-rc.inet1 call outs, those being rc.netdevice and rc.modules; and post would be rc.M.
The problem with this approach is either packages don't create it and users have to "discover" the magic script name by reading the parent rc script (which admittedly the probably should do but..) or consult the man page etc and/or it means each new package has to create a .new file for the script if it is there. Had I a nickle for every rc.local.new I have deleted over 20 years...
There probably are good reasons for most people to want to pre/post network scripts and not have to hack stuff into rc.M and merge it with every update. Maybe an inet1.d directory where users could just drop their custom script-lets and have rc.inet1 either source or execute them if they have the execute bit set?
Another good example of something a user might want to do as post step is run some script that updates dynamic dns. I have script that does this from cron; but it would super handy if I could symlink it into rc.d someplace as well and have it also trigger whenever inet1 brings up an interface just in case the IPs have changed.
There probably are good reasons for most people to want to pre/post network scripts and not have to hack stuff into rc.M and merge it with every update. Maybe an inet1.d directory where users could just drop their custom script-lets and have rc.inet1 either source or execute them if they have the execute bit set?
The problem with starting to accept pre/post scripts is, where do you stop?
It's a pre/post script now; but next it will be a per interface script, or a pre/post <operation> script...
As for a inet1.d directory - when would you call the scripts in there? Before bringing up the interface? After? Or are we looking at an inet1-pre.d and inet1-post.d?
I can't see Robby going for that.
Quote:
Originally Posted by chemfire
Another good example of something a user might want to do as post step is run some script that updates dynamic dns. I have script that does this from cron; but it would super handy if I could symlink it into rc.d someplace as well and have it also trigger whenever inet1 brings up an interface just in case the IPs have changed.
If you need to set up your network card before bringing up the interface, rc.netdevice is the spot for it. If you need to run other commands after rc.inet1, use rc.firewall.
Your dynamic DNS updater could be called from rc.firewall to solve your problem
So, we already sort of have pre/post scripts - sure it's a little hacky to use them for purposes other than their obvious names, but they're there.
The other obvious solution to needing to do stuff before/during/after interface configuration is to move the Slackware rc.inet1 out of the way and create your own script. The chances are, if you're needing pre/post scripts you are a competent admin and can write the replacement rc.inet1 just fine
# Initialize the networking hardware.
if [ -x /etc/rc.d/rc.inet1.local ]; then
/etc/rc.d/rc.inet1.local &>/dev/null
elif [ -x /etc/rc.d/rc.inet1 ]; then
/etc/rc.d/rc.inet1 &>/dev/null
fi
which would then allow people to do
rc.inet1.local:
... or alternatively, replace rc.inet1 entirely if that is their wish.
Of course, people can just replaced rc.inet1 as is but doing so makes it more complicated for anyone who still wants to run the stock rc.inet1 as part of the script as above.
The problem with this approach is either packages don't create it and users have to "discover" the magic script name by reading the parent rc script (which admittedly the probably should do but..) or consult the man page etc and/or it means each new package has to create a .new file for the script if it is there. Had I a nickle for every rc.local.new I have deleted over 20 years...
Yes, that's annoying. IMO Pat shouldn't be including an empty rc.local.new in the package. It's just something for people to remove every time they update the package (though admittedly only really an issue if you run current).
Personally, I think it's ok to leave people to "discover the magic".
The problem with starting to accept pre/post scripts is, where do you stop?
You are not wrong; and I already acknowledged we have in one form or another pre/post scripts around rc.inet1 already. I am not going to die on this hill beyond saying I still think it would be handy to have a source directory for doing this. If someone has to go back and figureout where something is getting called from its a lot quicker to find 10_update_dns.sh than to go picking thru scrips like rc.firewall and yes I am know how to "grep -rin"
We are realistically talking about the least complex thing rc.inet1 (a very complex script) would be doing here. It would be silly to have a bunch of directories. I would suggest something like call the scripts with args "$SCRIPT [up/down] [$ifname/all]" or source them after setting some variables in a similar fashion; a simple convention like that would allow keeping things compact.
That said none of this is really needed. Everyone including me has solved these problems in on one way or another for as long as Slackware has existed. Of course one might argue inet1 does not need to create briges, vlans, tun, and tap interfaces either, you could always do what I used to do and put custom script for all that stuff in rc.netdevice so the interfaces were ready to configure in rc.inet1. It really nice that rc.inet1 does that stuff though now.
So having made the suggestion I'll leave off here, as there is really nothing more to say on the subject :-)
By default, Slackware runs /etc/rc.d/rc.netdevice before rc.inet1, if the file exists and is executable (you have to create it.
I haven't used the following script since udev replaced hotplug. I'm sharing here for educational purposes how once upon a time I used the rc.netdevice script. I had several different systems in my home lab. I wanted a global/universal script to manage all of those systems.
Code:
#!/bin/bash
# /etc/rc.d/rc.netdevice
# Load module for network device.
# As originally intended, this script should be short and customized for
# each system. Just a few lines at most, with a modprobe command
# specific to each box. As written here, this script is intended to
# cover all machines and testing possibilities for personal use as used
# here.
Screen_Info () {
if [ "$ERRMSG" = "0" ]; then
echo "$MODULE module loaded"
else
echo "$MODULE module not loaded"
fi
}
Second_Card () {
# This card will be eth1.
# Remember to edit /etc/modprobe.d/aliases when using this card.
# If receiving the message "SIOCSIFFLAGS: device or resource busy,"
# then to avoid interrupt conflicts edit /etc/modprobe.d/options.
. /etc/rc.d/rc.inet1.conf
if [ -n "${IPADDR[1]}" ] || [ "${USE_DHCP[1]}" = "yes" ]; then
echo -n "3Com 3c509B ISA EtherLink-III 10 Mbps: "
/sbin/modprobe 3c509
ERRMSG="$?"
Screen_Info
fi
}
unset MODULE
if [ -x /etc/rc.d/rc.udev ] && [ -n "`ps ax | grep '/sbin/udevd --daemon' | grep -v grep`" ]; then
echo "Udev is enabled to probe for network cards."
else
echo "Probing for network cards:"
if [ -n "`grep \"CyrixInstead\" /proc/cpuinfo`" ]; then
# Used in 486 box.
echo -n "SMC EtherCard Plus Elite16T 8013WC 10 Mbps: "
MODULE="wd"
elif [ -n "`grep \"AMD-K6(tm)-III Processor\" /proc/cpuinfo`" ]; then
# Used in K6-III+ box.
echo -n "3Com 3c905 PCI Etherlink XL 10/100 Mbps: "
MODULE="3c59x"
elif [ -n "`grep \"Pentium II (Deschutes)\" /proc/cpuinfo`" ]; then
# Used in PII Deschutes box.
echo -n "ADMtek NC100 PCI Fast Ethernet 10/100 Mbps: "
MODULE="tulip"
elif [ -n "`grep \"AMD Athlon(tm) X2 Dual Core Processor BE-2400\" /proc/cpuinfo`" ]; then
# Used in BE-2400 box.
echo -n "Nvidia MCP51 Ethernet Controller 1 Gbps: "
MODULE="forcedeth"
elif [ -n "`grep \"AMD Athlon(tm) Dual Core Processor 5050e\" /proc/cpuinfo ]; then
# Used in 5050e box.
echo -n "Nvidia MCP78S Ethernet Controller 1 Gbps: "
MODULE="forcedeth"
fi
if [ -n "$MODULE" ]; then
/sbin/modprobe $MODULE
ERRMSG="$?"
Screen_Info
Second_Card
else
echo "This script is not configured correctly to find the expected network card."
echo "`/sbin/lspci`"
fi
fi
Quote:
The problem with starting to accept pre/post scripts is, where do you stop?
This discussion seems to be wandering down the NIH path. Conceptually, why not evaluate how other distro maintainers have solved this problem?
Quote:
I think it's ok to leave people to "discover the magic".
Discoverability is a challenge developers and engineers have struggled with since forever. How best to help users discover additional features? Remember the days of blinking clocks on VCRs?
I think you've misunderstood the comments made about rc.local. No one was suggesting removing it.
Not directly, only sarcasm (which I don't criticize, as I'm also making use of) and lack of proper/complete English formulation (also not criticizing, as I'm not a native English speaker and doing plenty of mistakes).
Anyway, thanks for the clarification.
- chemfire
Quote:
Had I a nickle for every rc.local.new I have deleted over 20 years...
- GazL
Quote:
Yes, that's annoying. IMO Pat shouldn't be including an empty rc.local.new in the package.
The complete form (the one that wouldn't mislead) would be:
"Yes, that's annoying. IMO Pat shouldn't be including an empty rc.local.new in the package, on every update."
On which I also agree, but I don't mind deleting the rc.local.new
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.