On 16/02/2015 5:19 AM, Orion Poplawski wrote:
> On 02/15/2015 08:53 AM, Steven Haigh wrote:
>> On 16/02/2015 2:29 AM, David Sommerseth wrote:
>>>> From: "John Lauro" <[log in to unmask]>
>>>> To: "David Sommerseth" <[log in to unmask]>
>>>> Cc: "scientific-linux-users" <[log in to unmask]>,
>>>> [log in to unmask]
>>>> Sent: 15. februar 2015 14:33:25
>>>> Subject: Re: systemd (again)
>>>>
>>>> Sounds just what hackers would like. A nice web interface that
>>>> doesn't even show up as a resource after it's been idle for 10
>>>> minutes so admins might not even realize if it's wide open...
>>>
>>> Gee ... if you look at netstat, I'm sure you'd notice that systemd
>>> is listening to that port. I'm sure any responsible sysadmin will
>>> always double check which ports are truly open. In addition, there
>>> is firewalling which any responsible sysadmin would not ignore to
>>> ensure is properly configured.
>>
>> netstat isn't the default way anymore... In fact, on some systems it
>> isn't even available anymore unless you include the net-tools package.
>
> ? This has always been the case. Perhaps the improvement is the
> reduction of dependencies that may have brought in net-tools by default
> before. But this is a good thing. If you need/want net-tools (or
> anything else for that matter) you install it.
>
>>> The advantage is that no system resources are spent on processes
>>> not being actively in use. Yes, it requires another mindset. But
>>> those who depend on evaluating system security primarily based on
>>> the output of 'ps' does a fairly poor job.
>>
>> So its xinetd? :)
>
> Yes, it replaces that as well.
>
>> I've done a little bit of work with Xen packages using SystemD - and to
>> be honest, it isn't *that* bad. If systemd is needed at all is a
>> different question - although we're just adding another wrapper layer
>> around an initscript that now gets called via systemd.
>
> You're actually removing a bunch of shell scripting layers.
You're not removing anything. Its a binary daemon replacing a shell
script. And because it has its fingers in everything about your system,
it opens up amazing problems the minute you get a buffer overflow bug.
>> In the end, it doesn't do anything more functional than the old init
>> system did - just now that instead of throwing stuff in /etc/init.d, you
>> now have to write another file to then call the init script.
>>
>> Web interfaces and other junk aside, systemd doesn't seem to do much in
>> the way of improvement - in fact, most features of priorities and
>> parallel start exist in sysvinit - but were never implemented properly
>> by distributions... So instead, we reinvent the wheel again...
>
> It does a whole lot more that the old init system did, which an internet
> search and a few minutes of reading would have made abundantly clear.
> Just a couple points:
Oh I know - I don't know exactly if its a good thing or not.
> - It monitors the processes that is starts and can restart them if they
> die.
This is not always good. I can think of many reasons why you don't want
to automatically restart processes. There are some good as well, but not
as many imho.
> - It can configure the environment of the processes it starts in a
> number of ways: cgroups, namespaces, etc.
and none of this can be done via shell scripts?
> - It can log the output in the journal that would have otherwise been lost.
Which is a binary logfile that most people ignore and end up with syslog
anyway. There is a reason syslog is found just about everywhere.
> Please people, let's do some research before just putting out our first
> impressions as facts.
I'd hardly say its first impressions. Not being impressed at all isn't a
good feature - and 'but but but you don't know it!' is like that saying
"He's a good bloke when you get to know him"... What that really means
is that he's an asshole until you learn to put up with it - and that's
what we're really dealing with here ;)
--
Steven Haigh
Email: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
|
