On Tue, 31 Dec 2019 04:37:10 -0500 Gene Heskett <ghesk...@shentel.net> wrote:
> On Tuesday 31 December 2019 02:30:05 ghe wrote: > > > > On Dec 30, 2019, at 05:47 PM, Sven Hartge <s...@svenhartge.de> > > > wrote: > > > > > > Please show the output of > > > > > > systemctl cat YOUR_SERVICE_UNIT > > > > > > This will show all additions and overrides to the unit. > > > > root@test:~# systemctl cat ipfilter > > # /usr/lib/systemd/system/ipfilter.service > > [Unit] > > Description=packetFilter > > > > [Service] > > ExecStart=/etc/ipfilterfiles/ipfilter.sh on > > ExecStop=/etc/ipfilterfiles/ipfilter.sh off > > > > [Install] > > WantedBy=multi-user.target > > > > > Your shell script isn't really daemon, so it is normal to not stay > > > running after it setup the iptables rules. > > > > I guess I misunderstood the term 'daemon.' I thought it was just a > > piece of software that, when run, stays run until it's through -- > > when it's started at boot and has no exit, hangs around in the > > background doing stuff. Unless somebody tells it to stop. > > > > This code has, under the old init system, been thinking it's a > > daemon for a couple decades now. But you're right. On other systemd > > computers, I have to start my local firewall by hand, like I have to > > with BIND on the DNS server. > > > > > I think your unit is missing the following: > > > > > > ,---- > > > > > > | [Service] > > > | Type=oneshot > > > | RemainAfterExit=yes > > > > > > `---- > > > > That makes sense. I'll insert those lines and see what happens. > > > > I knew it'd be trivial when it came to light what I was missing. > > Thanks a lot. > > > > (grumble, grumble, systemd, grumble, grumble) > > > > >> And how did that file get in /usr? When I wrote it, it was in > > >> /lib/systemd/system. > > > > > > usr-merge is the keyword here. > > > > What's that? I never heard of that before, and I certainly didn't > > ask for it. One of the reasons I run Debian was that the config > > stuff is all in /etc. And, it goes without saying, stays there. > > > > As I said before, (grumble, grumble, systemd, grumble, grumble). It > > seems to be pretty nicely done system code, but with an absolutely > > abominable user interface. So far, I know of systemd dirs in /lib, > > /etc, and /usr. That's no way to run a *nix railroad. > > > +100 (or more) > > > While I have you on the hook, Sven, how/where did you get your > > systemd knowledge? I've looked around, and I haven't seen any > > mention of what you just told me. > > I had that same didn't start after a reboot problem, but found this > script started iptables ok when executed by hand as ./start-iptables > while root in the /etc/iptables dir. > > #!/bin/bash > iptables-restore <saved-rules > > And whenever I add a new rule, I resave the saved-rules with this > > #!/bin/bash > iptables-save >saved-rules > > A executed from /etc/iptables with ./iptables-saveem > > It seems to me, that if iptables has been intalled, there ought to be > a start script in /etc/init.d, or someplace in the /etc/systemd path, > but there is not such a critter in either path (nothing in /usr, > but /lib/systemd has 100 or so files) in this stretch install. > > This works, but leaves me open until I get around to starting it, so > I doubt its the approved method. IMO it ought to be the first active > line in the ifup script so its active before the net is brought up. > Does iptables-persistent work for you? I made my own pseudo-daemon before this existed, stealing a LFS skeleton, allowing multiple rulesets for various environments. -- Joe