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.
View Poll Results: I reviewed this proposal, and I think:
Thought I would propose this idea here and open it up for review, so I can find out how stupid it might be.
During multiuser startup, rc.firewall, if it exists, is called as rc.firewall start by rc.inet2, just before any network daemons are started.
But it is not called during shutdown as rc.firewall stop. This is problematic not because there's a need to lower shields during shutdown, but because there's sometimes a need to do something during shutdown.
In my case, a package I'm developing snapshots the running firewall ruleset to disk during shutdown.
This is not what I'm proposing, though. I'm just proposing that a call to rc.firewall stop should be added to rc.6. This could be just before running rc.inet1 stop, but maybe a bit sooner, before unmounting remote filesystems, to give it the broadest option to save something to disk.
The package I'm developing works around the lack of rc.firewall stop by adding K-type links to rc.firewall in rc[016].d. But it would be best to avoid using System V initscripts in a package because Slackware is BSD-initscript-centric.
# If there is a firewall script, run it before enabling packet forwarding.
# See the HOWTOs on http://www.netfilter.org/ for documentation on
# setting up a firewall or NAT on Linux. In some cases this might need to
# be moved past the section below dealing with IP packet forwarding.
if [ -x /etc/rc.d/rc.firewall ]; then
/etc/rc.d/rc.firewall start
fi
You are right to say this, in the sense that an rc.firewall is not distributed, and there is only a hook provided in rc.inet2 to run it, if one gets created. So yes, you could say rc.firewall is not a "part" of Slackware. But the name exists as a hook in rc.inet2. What is missing is the analogous hook in rc.6. The proposed change to rc.6 would be an exact parallel to what rc.inet2 already does at startup.
Since a hook exists in rc.inet1, I see no reason not to have a similar hook in rc.6 (or where ever appropriate) for completeness. Any service/daemon that Slackware (optionally) starts, Slackware should stop on shutdown or reboot.
Personally, I do currently use rc.local_shutdown as a workaround for rc.firewall.
Since when Slackware became a democracy? you should convince our BDFL
Quite right. For me, step one was to ask for reactions from other Slackware enthusiasts [edit: to find out if my idea is stupid before trying that]. A poll seemed like an effective way to see the reactions in a nutshell.
That's a fair question. A package shouldn't create or modify an rc.local_shutdown because it is likely to break the operator's existing carefully crafted one.
The package can certainly give the operator instructions for doing it on their own, and that's a reasonable "plan B" if this proposal gets shot down. But I don't prefer that approach because any manual procedure is error prone. I'd rather that a package install process involve as little manual post-installation as possible.
IMHO, as an rc.firewall is supposed (in any of the implementation I have seen) to start from a blank set of iptables rules, not with loading existing ones, a call in rc.6 shouldn't be needed to save the existing rules.
what you are asking looks related to settings specific to your application so, IMHO, it should be fine loading it with a dedicated rc.yourapp called in rc.local with the "start" option (and loading of existing rules, if present) and shutted down with the "stop" option (with saving of the rules) in rc.local_shutdown (like all the third-party scripts on SBo do).
it seems to me that, also if they do similar things rc.firewall and the script you are referring to should be separate.
I see no reason not to have a similar hook in rc.6 (or where ever appropriate) for completeness. Any service/daemon that Slackware (optionally) starts, Slackware should stop on shutdown or reboot.
The problem here is that rc.firewall is not distributed with Slackware and different custom rc.firewall from different sources might behave differently. Some of those scripts might not care about any arguments like "start", "stop", "restart" or "status" and regardless of argument only start the firewall again. Depending upon how the script is done it might be more or less bad to start it a second time.
That's a fair question. A package shouldn't create or modify an rc.local_shutdown because it is likely to break the operator's existing carefully crafted one.
I have created some custom packages where doinst.sh checks with grep if the startup script already contains what it wants there and otherwise adds it at the end of the script something like this:
However, in my case, I have a fixed /etc/rc.d/rc.local and /etc/rc.d/rc.shutdown which calls my custom scripts like /usr/local/etc/rc.d/rc.local and those scripts might call other more machine custom scripts like /usr/local/etc/rc.d/rc.custom
Still, here is an example of such doinst.sh which might modify not only a startup script but also a configuration file for snmpd:
Code:
#!/bin/bash
(cd opt/lsi/snmp/lib ; ln -sf libstorelib.so.4.02-0 libstorelib.so)
(cd usr/lib64 ; ln -sf libsas_objects.so.1.43-1 libsas_objects.so)
grep lsi_mrdsnmpmain etc/snmp/snmpd.conf
if [ $? -ne 0 ]; then
echo "# This pass is required for MegaRAID SCSI/iSCSI SNMP" >> etc/snmp/snmpd.conf
echo "pass .1.3.6.1.4.1.3582 /etc/lsi_mrdsnmp/lsi_mrdsnmpmain" >> etc/snmp/snmpd.conf
fi
grep lsi_mrdsnmpagent usr/local/etc/rc.d/rc.custom
if [ $? -ne 0 ]; then
grep /bin usr/local/etc/rc.d/rc.custom
if [ $? -ne 0 ]; then
echo "#!/bin/sh" >> usr/local/etc/rc.d/rc.custom
echo >> usr/local/etc/rc.d/rc.custom
chmod u+x usr/local/etc/rc.d/rc.custom
fi
echo "if [ -x /etc/lsi_mrdsnmp/lsi_mrdsnmpagent ]; then" >> usr/local/etc/rc.d/rc.custom
echo " /etc/lsi_mrdsnmp/lsi_mrdsnmpagent -c /etc/snmp/snmpd.conf" >> usr/local/etc/rc.d/rc.custom
echo "fi" >> usr/local/etc/rc.d/rc.custom
fi
But these custom packages are only intended for machines where I am the administrator.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
