I have init scripts that need to run after SuSEfirewall2_setup (because they make entries in the iptables).
Managing iptables through Yast not really an option. Has to be the scripts.
The problem is the $ALL in the ‘should-start’ section of the SuSEfirewall2_setup takes precedence over everything else; I can’t depend (required-start) on SuSEfirewall2_setup from my script because of the $ALL, and even if my scriptss also depends on $ALL, and is alphabetically after SuSEfirewall2_setup, my scripts still run before SuSEfirewall2_setup. (This was not always the case, but is the behavior in 12.1; used to be sufficient to make them alphabetically after).
Two questions really:
Why does SuSEfirewall2_setup depend on $ALL? Seems to be a sledgehammer where a scalpel would be better, since it’s perfectly reasonable to want to run things after the firewall is up and running.
Given that’s the way it is for the moment, is there any way to workaround the problem without changing the distro scripts and removing the $ALL?
On 2012-03-31 22:56, zanetrock wrote:
>
> I have init scripts that need to run after SuSEfirewall2_setup (because
> they make entries in the iptables).
The proper place would be to use the hook in “/etc/sysconfig/SuSEfirewall2”:
Of course, it doesn’t need to be that file, but you can use that one as
example. The advantage is that it will run not only as boot, but any time
you restart the firewall or the network.
> The problem is the $ALL in the ‘should-start’ section of the
> SuSEfirewall2_setup takes precedence over everything else; I can’t
The problem is that 12.1 ignores all that. It uses systemd, so that the
decision logic is /different/. Don’t ask me, I don’t understand it. If you
are booting with the old systemv then the old logic would apply, and then
you would use “/etc/init.d/after.local” as a hook to run scripts guaranteed
to run after anything. Only if you use systemv.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
You can still use the after.local script in openSUSE 12.1 and with systemd running as the default. Stop swimming upstream and give my blog instructions a try:
> ‘systemd and using the after.local script in openSUSE 12.1 - Blogs -
> openSUSE Forums’ (http://tinyurl.com/6r8hxpd)
Interesting.
Question: I see that you talk of boot.local and after.local. In systemv,
boot.local is executed before any of the init scripts, and after.local runs
after all the scripts.
What’s the situation with systemd? Where exactly does the service you
describe run?
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
The after.local and boot.local scripts both run as a multi-user.target (with my fix) and their meanings are not the same as before systemd. Basically, before I knew much at all about systemd, I figured out that boot.local was running while after.local was not running. I copied the boot-local.service over and modified it to be the after-local.service. So, there is little difference between the two. Since then, I have found out how to get one service to run another first, but one really needs to know what you are trying to do and the order you need to happen. Some of my research into systemd was based on trying to get dkms to work with systemd, which was setup as a runlevel task, that did not run properly under systemd. There I determined that if there is a service that does not work under the simulated runlevel stuff and systemd, you can move it from its old /etc/init.d folder location, so there are no conflicts, and create a new .service file for it. So, if you need to get an old bash script to run, that was a runlevel service before, why not make it a new systemd .service and see if it works for you then?
So one must ask yourself, as you start to bring back these bash scripts and such if you will be losing the benefits of systemd? I would say perhaps, but if you can not get an important service to work with systemd, what good is it? Further, as time goes forward, such packages as dkms, will undoubtedly be modified to work properly with systems that use systemd with no need for kluges like mine. One other interesting side note is getting to know how systemd works when using other distributions like Fedora 16. I can use my make-after-local script from here: systemd and using the after.local script in openSUSE 12.1 - Blogs - openSUSE Forums in Fedora 16 and then use the resulting after.local script to load the VirtualBox drive mappings automatically in a VM.
Another benefit of creating such scripts and thanks for asking Carlos.
Thanks for the thorough responses. I’ve looked at the postings and done some research and think I have a better handle on the situation. I was unaware of the systemd change.
I ended up removing the ‘$ALL’ from the SuSEfirewall2_setup requirements and everything is working fine. Maybe that would break with some other combination of services, but for what I have, it was the least change that worked, and since it appears that all the changes require making some change to distro-mediated files and configuration, I figured the least change was best.
Is the fact that the ‘after.local’ doesn’t work out of the box, and cannot simply be turned on, a bug?
is that 12.1 ignores all that. It uses systemd, so that the