Language:
switch to room list switch to menu My folders
Go to page: First ... 109 110 111 112 [113] 114 115 116 117 ... Last
[#] 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]

uptime
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.

Heh.

[#] 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:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

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

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

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


(src:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/ System_Administrators_Guide/sect-Managing_Services_with_systemd-Services.html

)

[#] Fri May 01 2015 10:52:29 EDT from LoanShark @ Uncensored

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


netstat -an | grep LISTEN. Find out what process owns those ports, whether they are truly necessary for your use case, and if not, shut them down.



next, think about local security. Can you enable selinux in strict mode without breaking anything critical?

Red Hat used to have a simple "enable the firewall" script that would install some basic packet filters. I don't remember the name of it anymore, might have been system-config-firewall

Use the "find" command to hunt down setuid/setgid binaries that might not be necessary.


This is basic stuff. I'm not a security guru anymore, if I ever was. Google "Red Hat hardening" or something.

[#] Fri May 01 2015 21:17:13 EDT from Sig @ Uncensored

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

Thank you. At the least, those give me more useful search terms.

[#] Sun May 03 2015 02:10:29 EDT from ax25 @ Uncensored

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

List listening sockets and proggies):

netstat -aonp

List the users of the port, and userid:

lsof -ni :portnumber
i.e.:
lsof -ni :25

Show the individual process info:

cat /proc/[pid]/cmdline
i.e.:
cat /proc/11104/cmdline

(and many other items under /proc/[pid] that interest you (cat is your friend).

Feel free to share anything you learn as well.



Go to page: First ... 109 110 111 112 [113] 114 115 116 117 ... Last