firewalld is the /etc/init.d/iptables replacement Centos7.
I was ok with the way iptables were handled on Centos6. This firewalld is an unbelievable mess.
Shorewall is something even an imbecile could configure. Dunno how secure it is compared to other stuff, but I only need masquerading and traffic routing.
hm, to be honest, never heard of firewalld - another F*ck poetering is trying to force on the rest of the world?
I used to use ferm as iptables frontend, nice syntax.
for shure lartc.org is something to browse through before starting with ip and friends.
Subject: Re: firewalld, the next hot shit after systemd
Really though, if iptables is the order of the day, it's a whole lot easier to just put your iptables commands into /etc/rc.d/rc.local and no system daemon will ever mess with them.
Dipping my toes into Linux recently, I felt a need to support systemd for starting some customer services. It was, initially, a major pain in the ass to figure out why something wasn't quite working correctly, but eventually I worked through the problem (the code was not quite working correctly, but system v approaches hid the issue), and got it to work reasonably well.
I'm still a little fuzzy about how it deals with dependencies... most specifically, the various names for various dependencies, which can be different depending on distributions... but I muddled through.
Philosophically, though, I don't like systemd. Unix has a tradition of 'do one thing, and do it well,' that systemd violates from what I can see. It feels to me as if systemd needs to be broken down into more discrete pieces that have a common api through which to communicate.
uptime13:07:37 up 33 days, 19:33
It is so disapointing when linux makes me reboot. I really would like to get my desktop to go for months
without a reboot.
How long have we been on this lifeboat?
Thirty-three days, sir?
Dipping my toes into Linux recently, I felt a need to support systemd
for starting some customer services. It was, initially, a major pain
The problem now is that if you're packaging an application you have to support *both* sysvinit and systemd. Although systemd can be configured to honor sysvinit scripts, there is no guarantee that your underlying OS has it built that way.
What a pity, I really enjoyed just running services directly out of /etc/inittab, with each service's "don't go into the background" flag set. If a daemon crashed for whatever reason, init would just restart it. The "upstart" init replacement which was included in nonstandardbuntu for a while had a way to configure auto-respawns, but one line in inittab was TEH R0X0R.
Now, if it doesn't exist already, someone's going to have to write an "install this as a service" script that feels-out the underlying environment and does the right thing.
The tricky bit, for me, was dealing with the daemonization of the service.
systemd can react in one of three ways, if I recall, to this... it can expect the executable to run as if it were being run on a command line, without relinquishing control and all that. It can expect the executable to run as if it were fully daemonized (gives up the console, pushes itself in the background, and all that jazz). And I forget the third option... but I think it's kind of a half-way between those two.
But detecting that is apparently non-trivial. I forget the name of the tool I used to trace what was going on with my executable, but it didn't do a great job of informing me of what was happening with the spawned threads, and I think it did nothing to tell me of whether or not the console was relinquished.
That said, the only other tricky bit involved ensuring other things that I needed running were in fact running when my service started. But, y'know, Windows has this problem, too. I think systemd is more flexible in its approach, but it's complicated. Like a lot of relationships.
Hm... dunno what consequences exist if you don't daemonize the code and let systemd deal with it. Maybe none... although writing your code to work only with systemd might not be ideal if you want your stuff to work on other systems.
Well, if systemd takes over the universe, we'll eventually get to the point where the few init scripts that are left will have ampersands in them.
They seem to have a pretty good run, but Solaris will not likely shift to that model. We'll have init scripts for a long time yet.
Make sure you update.
Hrm... I don't expect you're looking for something like:
(by way of enumerating services)
Gah, I didn't even get that right...
This said, apparently, Red Hat prefers 'systemctl' commands.
To list services:
systemctl list-unit-files --type service
unless you're talking about an old Red Hat. Older Red Hat apparently did: