switch to room list switch to menu My folders
Go to page: First ... 17 18 19 20 [21] 22 23 24 25 ... Last
[#] Sun Jan 11 2015 13:57:38 EST from the_mgt @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Sun Jan 11 2015 14:52:57 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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 is something to browse through before starting with ip and friends.

[#] Sun Jan 11 2015 18:14:44 EST from nristen @ Uncensored

Subject: Re: firewalld, the next hot shit after systemd

[Reply] [ReplyQuoted] [Headers] [Print]

I use VyOS at home and at work in front of Virtual Development Lab. I really like the OpenVPN integration. I have had no stability issues which is more than I can say for some of our cicso equipment.

[#] Mon Jan 12 2015 08:26:33 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I don't think firewalld is a Poettering creation but it might as well be.

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.

[#] Mon Jan 12 2015 09:09:14 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Jan 14 2015 13:11:09 EST from zooer @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

13: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.

[#] Wed Jan 14 2015 20:03:30 EST from vince-q @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

My best - so far on this box - is 149 days.

[#] Thu Jan 15 2015 21:36:43 EST from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

How long have we been on this lifeboat?
33 days!
Thirty-three days, sir?

[#] Fri Jan 16 2015 09:39:20 EST from zooer @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

That's a rather personal question.

[#] Fri Jan 23 2015 07:29:19 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Fri Jan 23 2015 08:40:41 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.


[#] Fri Jan 23 2015 09:34:45 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

You know what, if systemd makes daemonization obsolete, then I am instantly going to be a fan of systemd.

[#] Fri Jan 23 2015 09:36:30 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Mon Jan 26 2015 16:03:39 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.


[#] Tue Jan 27 2015 06:22:46 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Wed Jan 28 2015 08:53:13 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Uh oh:

Make sure you update.

[#] Thu Apr 30 2015 21:36:19 EDT from Sig @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Can anyone recommend a good primer or even just checklist for enumerating services and getting a good start on locking down Red Hat-style Linux? Bonus points if it employs primarily commonly available command line tools. I'm much more familiar with Debian variants, but that's not likely to be the environment, and I'm not really a security guru.

[#] Fri May 01 2015 08:32:57 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Hrm... I don't expect you're looking for something like:

ls /etc/init.d

(by way of enumerating services)

[#] Fri May 01 2015 08:34:05 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Gah, I didn't even get that right...

ls /etc/rc.d/init.d

[#] Fri May 01 2015 08:36:24 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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:

chkconfig --list

Go to page: First ... 17 18 19 20 [21] 22 23 24 25 ... Last