subject:"Re\: Linux\: concerns over systemd adoption and Debian's decision to switch"

- Original Message -
 From: Barry Shein b...@world.std.com

 On October 21, 2014 at 13:44 brun...@nic-naa.net (Eric
 Brunner-Williams) wrote:
   systemd is insanity.
 
  see also smit.
 
 SMIT! Rhymes with 

For the record, smit is crazy cause AIX isn't really Unix; it's VM with a
thin POSIX skin overtop.

Very thin in places.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

- Original Message -
 From: Lamar Owen lo...@pari.edu

 Speaking from my own experience, the actually relevant and
 package-specific guts of the typical initscript could be easily
 replaced by a simple text configuration that simply gives:
 
 1.) What to start
 2.) When to start it (traditional initscripts work on a linear
 timeline
 of priority slots; systemd units have more flexibility)
 3.) How to start it (command line options)
 
 This should not need to be an executable script. This is what systemd
 brings to the table (Upstart brought some of this, too). 

That is a perfectly valid point.  We don't dislike systemd because it does
that. We dislike it because it doesn't *only* do that.

Cheers,
-- jr 'see also IPv6' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Linux: concerns over systemd adoption and Debian's decision to switch

 Original Message -
 From: Jeffrey Ollie j...@ocjtech.us

  If that doesn't suffice, then I suspect it will only require waiting
  a little while until a demonstration of why monolithic integration
  is a bad idea will be provided by someone who is at this moment
  studying the large-and-growing attack surface presented by systemd.
 
  I hope I'm wrong about that. I'm probably not.
 
 Software is software. I'm sure that bugs (including security bugs)
 will be found. Film at 11. Nothing new here.

Nope, Jeff; you've entirely missed it:

On a non-systemd distribution, the odds are good that a) that bug is in code
not running as root nor b) in PID1 where if it locks up it takes the whole
box with it, and also c) I can just put my thumb down on that one piece and
turn it off; that's almost certainly and almost always not true in systemd.

That's what's new here.

As I noted in another posting, that Unix Philosophy happened for a reason.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Linux: concerns over systemd adoption and Debian's decision to switch

- Original Message -
 On 22-10-2014 17:30, Jeffrey Ollie wrote:
  Hardly. The discussion so far has been weighted very heavily on the
  side of Dana Carvey's Grumpy Old Man-style whining. That's the way
  it was and we liked it!. The people that like systemd (like myself)
  have wisely learned that the people that hate systemd, hate it mostly
  because it's different from what came before and don't want to change.
  There's no way to argue rationally with that.

That's not true, Jeff.  Nearly all the anti-systemd arguments I have seen
have itemized the design features of the package which we don't like, and
provided what seem to us to be good and cogent reasons why we don't like 
those, in many cases backed up with examples of how earlier similar designs
failed that way.

Grumpy Old Man is a strawman argument, and there's no way to argue with
that at all: you merely identify it as fallacious and ignore it.

And if the same proponent keeps doing it, you demonstrate the sound an
idiot makes falling to the bottom of your killfile.  Please don't.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-24 Thread Chris Adams

Once upon a time, Jay Ashworth j...@baylink.com said:
 Try to do everything *inside PID 1* is the real problem.

And that is not what systemd is doing; make sure you know what you are
complaining about.  systemd-the-project != systemd-the-pid-1.  PID 1 is
responsible for managing services/daemons, and AFAIK that's all
systemd's PID 1 does.

-- 
Chris Adams c...@cmadams.net

RE: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-24 Thread Jeff Masiello

As  lurker I just wanted to say this has been highly educational. (I'm new)

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of *
Sent: Wednesday, October 22, 2014 12:57 PM
To: nanog@nanog.org
Subject: Re: Linux: concerns over systemd adoption and Debian's decision to 
switch

On 10/21/2014 05:20 PM, Jimmy Hess wrote:
 The all-in-one approach of systemd might have a place on some 
 specialized desktop distros,  but outside that niche its' IMO a 
 terrible idea.

 The proper fix is probably a go back to Upstart or SysVInit  and 
 rewrite systemd,  so all the pieces are separated  and exist as a 
 higher layer on top of init.

That is how systemd works, there are many parts and systemd is the sum of all 
those parts. It has a PID1 that replaces sysvinit/upstart, but afaik it doesn't 
do a whole lot extra.
I don't use systemd, and I don't know a lot about it, but it seems lots of 
people don't get that it's not all lumped in PID1, there are a lot of processes 
that do different things that are mostly tightly held together (I think only 
udev and a couple other things still work without the rest of systemd.) Then 
again, the systemd people do spread FUD about sysvinit as well, Poettering's 
own blog for example even misleads on how systemd and sysvinit work 
http://0pointer.de/blog/projects/why.html
A lot of things in the comparison chart have sysvinit listed as no, when it's 
obviously not init's job directly, but a subprocess/script, except it lists 
yes for systemd on some, where systemd still passes it off to a subprocess! 
(They really are taking advantage of the PID1 and the entire bundle of software 
both being named systemd I guess.)

[Insert obligatory No I don't think sysvinit is perfect, but... here]

ps. What's with all the fear/hate of shell scripts? I realize the init scripts 
on most Linux distros are messy (200 LOC just to start sshd?
Come on debian.) but the solution isn't to run away from them; rewrite scripts 
to have saner logic and not do a dozen redundant/unnecessary checks.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Stephen Satchell

On 10/22/2014 08:20 PM, Simon Lyall wrote:
 On Wed, 22 Oct 2014, Miles Fidelman wrote:
 And maybe, you should check out some of the upstream bug reports re.
 systemd interactions with NTP.
 
 If you think the current situation is all good then maybe you should
 look at other bugs for ntp. eg this one I that affected me with Ubuntu
 Disktop. They only run time syncing when the network is bounced so if
 you have a stable network then your machine will never sync:
 
 https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933
 
 Note that the importance of this has been set to wishlist.
 

Looking at the ticket you submitted, I see this statement:

 On Ubuntu 12.04 desktop, in System Settings  Time  Date, when the
 time is set to update Automatically from Internet it syncs once but
 then drifts out over a period of days.
 
 In Syslog I can see that ntpdate is called on boot but is never called again.

I'm a long-time user of NTP, and what you are asking for is a no-good
way of doing things.  What you are supposed to do is use the ntpdate(8)
utility *ONCE* on boot to initially set the system clock, then you have
ntpd(8) running to do two things for you:  sync up to one or more time
sources, and discipline the local clock.

What is discipline the local clock?  This is the process of
determining the *exact* frequency of the crystal clock in your local
computer, and tuning your local clock hardware so that local real time
is in sync with the world.  This is because the accuracy of the crystal
is specified to be rather loose (hundreds of parts per million), but the
relative accuracy of a crystal is actually within tens of parts or even
single-digit parts per million.  So if you can measure the drift, you
can in software compensate for it so you get a true-chimer.  That's what
the ntpd daemon does.

Now, what is supposed to start the ntpd daemon in Ubuntu?

DHCP has no significant effects on the filters used in ntpd(8).

I didn't have any problem getting this to work the right way on
Slackware, Red Hat, and Debian.  It works out of the box with Fedora
and CentOS, to the point that I don't even think much about it other
than in the GUI to point to my local time source on system install.

It even works with the Ubuntu 8.04.4 LTS server that was forced down my
throat a few years back, which I'm in the process of trying to retire in
favor of a CentOS 6.5 server implementation.  (At least THAT
Ubuntu-loving sysadmin is gone now.)

What happens on your box when you do /etc/init.d/ntp start?  And how
frequently do you reboot your box?  It sounds like it's up all the time,
which means the local clock can be trimmed very accurately indeed.

That's the SERVER way of running a time synchronization.  So it would
appear that you have a quarrel with GUI support, not with NTP itself.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Rahul Sawarkar

Systemd Blackhole  is a very apt term as I am discovering.
I was once a linuxfromscratch  superuser 10 years back, in a sense that
if anyone asked me the location of a lib.so and how to resolve a version
mismatch, I could fix it in a matter of minutes even if woken up at 4am in
the morning. Likewise for almost any other  complex debugging challenge.
Take it with a pinch of salt though - it is more a statement of my
confidence in my own abilities then, than  something absolute and
ahistorical.  I have since downgraded to being a mere power user over the
years who just wants to get the job done with the focus being my objective
as an end-user. Right now I am having difficulty auto mounting an NFS
partition at boot from /etc/fstab, and systemd isn't telling me if it even
attempted to and why it failed. Google and wiki isn't helping either. No
log line ...absolutely nothing.  A manual mount -a works flawlessly. In
the older days I would read a log line and navigate to the init script if I
had to, read and understand  the sequencing and dependencies and learn to
fix things.  Right now I am clueless and helpless. My confidence about
fixing problems on a Linux with systemd is very low. I am reduced to being
a Googler searching for answers in the unknown rather than upgrade my
skills level back to where I was earlier.

I am glad this topic came up and I discovered early enough that there now
has to be a strategic choice and decision making I need to make in the
Linux world that is not going to be a dead-end for me if I choose to go the
init way - one that stays loyal to the original Unix philosophy. I am glad
to hear there is a substantial movement and backing for this that might
pave the way for a non -systemd  alternative.

I wonder what Mr. Linus Trovaldis himself thinks on this matter though. I
am curious to find out.

Rahul
Sent from MiPad
On Oct 22, 2014 1:18 AM, Jim Popovitch jim...@gmail.com wrote:

 On Tue, Oct 21, 2014 at 3:41 PM, Eugeniu Patrascu eu...@imacandi.net
 wrote:
 
  I think systemd wants to become the next Emacs ;))

 Or the next user activity collection point.   Systemd really is a
 black hole to 99.9% of the people who will use/deploy it... seems
 perfect for lots of things.

 -Jim P.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 10:05:30PM -0500, Jeffrey Ollie wrote:
 To achieve the level of integration that timedated has with the rest
 of systemd would require more than just putting code into timedatectl
 to write out /etc/ntpd.conf and starting a service.  timedated talks
 to networkd (that
 DHCP server that everyone is hating on as well) in real-time to
 determine the state of the network and to get any NTP servers that
 were sent in DHCP packets.  To do that for chronyd or ntpd in the same
 way would require code changes and the systemd developers didn't want
 to do the work,

This is the core problem with systemd, in my mind -- and what has gotten
Linus, amongst other people, so thoroughly cheesed off with the systemd
devs.  They don't play well with other children.  They don't appear
particularly interested in reusing any existing code, because it's a lot
more fun to write new code.  I'm a strong proponent of Joel Spolsky's views
on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the
same problems will come to haunt systemd on its way from being the new kid
on the block to being legacy code[1].

- Matt

[1] A computer industry term which means, it works.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Robert Kisteleki

On 2014-10-23 9:15, Matt Palmer wrote:
 On Wed, Oct 22, 2014 at 10:05:30PM -0500, Jeffrey Ollie wrote:
 To achieve the level of integration that timedated has with the rest
 of systemd would require more than just putting code into timedatectl
 to write out /etc/ntpd.conf and starting a service.  timedated talks
 to networkd (that
 DHCP server that everyone is hating on as well) in real-time to
 determine the state of the network and to get any NTP servers that
 were sent in DHCP packets.  To do that for chronyd or ntpd in the same
 way would require code changes and the systemd developers didn't want
 to do the work,
 
 This is the core problem with systemd, in my mind -- and what has gotten
 Linus, amongst other people, so thoroughly cheesed off with the systemd
 devs.  They don't play well with other children.  They don't appear
 particularly interested in reusing any existing code, because it's a lot
 more fun to write new code.  I'm a strong proponent of Joel Spolsky's views
 on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the

http://www.joelonsoftware.com/articles/fog69.html

 same problems will come to haunt systemd on its way from being the new kid
 on the block to being legacy code[1].
 
 - Matt
 
 [1] A computer industry term which means, it works.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Joe Loiacono

NANOG nanog-boun...@nanog.org wrote on 10/22/2014 10:47:46 PM:

 The arguments against systemd that I've seen so far:
 
 1) It's different so it's bad.
 2) There's a lot of code, there must be some really bad security
 problems just waiting to happen, so it's bad.
 3) It doesn't do things the way we've always done them, so it's bad.
 4) The systemd developers are jerks, so it's bad.

Hmmm. It seems that list is missing its most important item.

As an impartial lurker, the primary objection I've seen is:

1. Try to do everything software is not optimal, and will lead to 
heartache.


Joe

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread *

On 10/21/2014 05:20 PM, Jimmy Hess wrote:
 The all-in-one approach of systemd might have a place on some
 specialized desktop distros,  but outside that niche its' IMO a
 terrible idea.

 The proper fix is probably a go back to Upstart or SysVInit  and
 rewrite systemd,  so all the pieces are separated  and exist as a
 higher layer on top of init.

That is how systemd works, there are many parts and systemd is the sum
of all those parts. It has a PID1 that replaces sysvinit/upstart, but
afaik it doesn't do a whole lot extra.
I don't use systemd, and I don't know a lot about it, but it seems lots
of people don't get that it's not all lumped in PID1, there are a lot of
processes that do different things that are mostly tightly held together
(I think only udev and a couple other things still work without the rest
of systemd.) Then again, the systemd people do spread FUD about sysvinit
as well, Poettering's own blog for example even misleads on how systemd
and sysvinit work
http://0pointer.de/blog/projects/why.html
A lot of things in the comparison chart have sysvinit listed as no,
when it's obviously not init's job directly, but a subprocess/script,
except it lists yes for systemd on some, where systemd still passes it
off to a subprocess! (They really are taking advantage of the PID1 and
the entire bundle of software both being named systemd I guess.)

[Insert obligatory No I don't think sysvinit is perfect, but... here]

ps. What's with all the fear/hate of shell scripts? I realize the init
scripts on most Linux distros are messy (200 LOC just to start sshd?
Come on debian.) but the solution isn't to run away from them; rewrite
scripts to have saner logic and not do a dozen redundant/unnecessary checks.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Jamie Lawrence

On 10/22/14, 9:01 AM, Jeffrey Ollie j...@ocjtech.us wrote:

Bull.  If you've been around the FOSS community even for a short
while, you'd know that systemd has become a religious topic akin to


On 10/22/14, 10:41 AM, Jeffrey Ollie j...@ocjtech.us wrote:

sums up my thoughts on the unix philosophy.  It's not the
be-all-end-all that you make it out to be.  Again, this sounds a lot
like Grumpy Old Man complaining.

You appear to be the only one here having difficulties being civil on the
topic. The rest of us are having an interesting, pleasant discussion about
a rather huge operational shift.


You like systemd. Great. More power to you. You apparently don’t like it
that many others have differing views or are still reserving judgment.
Also great, you can ignore the thread.



That said, my take on the mess.

I need to see systemd running for while in large-scale production before
I’m moving anything to it. I do rather hate the NIH-itis, the
svchost.exe-ish nature of the technical approach, the core devs'
attitudes, the tightly-coupled nature of the approach to doing the various
things it wants to do, and the devs' stated goal of forcing every linux
distro in to using it. And fu’ing binary logs.

OTOH, it does offer some nice things that can become annoying with other
tools. The single-sourced APIs for userspace apps might be appreciated by
some developers, especially refugees from MSFT-land.

It is immature compared to the competition with a radically un-unix
approach developed by people with a track record of being extremely
difficult to collaborate with, and it does several specific things I
really don’t like.  That adds up to a hard sell for me.

Some may see me as a grumpy old man for that. I see it as a technical
conservatism for my production environments borne of having been burned by
shiny-cool-new before one too many times, and a tired dislike of being
paged out of bed over some chrome plated new hotness that crapped itself
again.

There is a deeper argument about the unix way here as well. I do see a
lot of people become frustrated by what they see as impedance mismatched
between tools as they learn (why should I have to care about what the IFS
is?), or because a tool fails to react in accordance with their
expectations, or because they are using the wrong tool (I want to match
these HTML tags with a regex...), or because they realize a problem they
thought should be easy, isn't. I think that’s natural, to some extent. I
did (and still do, sometimes - there seems to be a hard limit on the
number of awk implementation differences that fit in my brain, for
instance). And there are things that could be made a lot better.

But when I start wondering if my init system has a flight simulator easter
egg, well, there’s a problem, at least for me. It is funny to see people
use but that approach is 40 years old! on both sides of the argument. I
do love playing with new toys, and think the systemd folks should write
whatever they want. I have major issues with the monoculture they want to
establish. (And yes, a core developer clearly stated that as a goal[1].)

Most of my systems are Linux these days, and I am mostly distro-agnostic,
although my default does happen to be Debian. I do think I’m going to have
to get back up to speed on FreeBSD again.

-j

[1] https://lists.fedoraproject.org/pipermail/devel/2011-June/152672.html
: [...]we want to gently push the distros to standardize on the same
components for the base system[...]

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Randy


I've enjoyed kernel hot patches (ksplice) until now.

So my primary concern is that updates to systemd appears to require a 
full reboot:


http://forums.fedoraforum.org/showthread.php?t=300166

Is systemd really like a 2nd 'kernel' -- demanding mass reboots every 
time a security issue is discovered?


I hope not!

--
~Randy

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Jim Popovitch

On Wed, Oct 22, 2014 at 12:57 PM, * turm...@privacyrequired.com wrote:
 Poettering's own blog for example even misleads on how systemd
 and sysvinit work http://0pointer.de/blog/projects/why.html

Oh look... he's related to PulseAudio and Avahi .

If you've ever tried above average audio on Linux, then you know all
about PulseAudio issues.If you've ever secured a subnet, then you
know all about Avahi (aka mDNS).

-Jim P.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Miles Fidelman


Jamie Lawrence wrote:

SNIP


Some may see me as a grumpy old man for that. I see it as a technical
conservatism for my production environments borne of having been burned by
shiny-cool-new before one too many times, and a tired dislike of being
paged out of bed over some chrome plated new hotness that crapped itself
again.


SNIP
and


But when I start wondering if my init system has a flight simulator easter
egg, well, there’s a problem, at least for me.


So nicely put! :-)



It is funny to see people
use but that approach is 40 years old! on both sides of the argument.


I think I'll stick with 4 wheels on cars for the long term. (3-wheeled 
motorcycles, on the other hand, are somewhat intriguing as I get older)



Most of my systems are Linux these days, and I am mostly distro-agnostic,
although my default does happen to be Debian. I do think I’m going to have
to get back up to speed on FreeBSD again.


Boy would I be happy if I could get Xen Dom0, ZFS, and a DRBD-equivalent 
on BSD or SmartOS.  Sigh...

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Valdis . Kletnieks

On Thu, 23 Oct 2014 11:25:36 -0400, Jim Popovitch said:
 On Wed, Oct 22, 2014 at 12:57 PM, * turm...@privacyrequired.com wrote:
  Poettering's own blog for example even misleads on how systemd
  and sysvinit work http://0pointer.de/blog/projects/why.html

 Oh look... he's related to PulseAudio and Avahi .

And he has a Grand Design for Everything:

http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html




pgpIIy2MXKyuL.pgp
Description: PGP signature

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Miles Fidelman


Randy wrote:

I've enjoyed kernel hot patches (ksplice) until now.

So my primary concern is that updates to systemd appears to require a 
full reboot:


http://forums.fedoraforum.org/showthread.php?t=300166

Is systemd really like a 2nd 'kernel' -- demanding mass reboots every 
time a security issue is discovered?




Well, in the sense that:
- it starts out as PID1 and really, really, wants to take over lots of 
low level functions, it sure looks like it's trying to be a 2nd kernel


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Mike.



On 10/23/2014 at 10:56 AM Randy wrote:

|I've enjoyed kernel hot patches (ksplice) until now.
|
|So my primary concern is that updates to systemd appears to require
a 
|full reboot:
|
|http://forums.fedoraforum.org/showthread.php?t=300166
|
|Is systemd really like a 2nd 'kernel' -- demanding mass reboots
every 
|time a security issue is discovered?
|
|I hope not!
 =

GNU/Linux is morphing into GNU/systemd

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Jim Popovitch

On Thu, Oct 23, 2014 at 12:04 PM, Mike. the.li...@mgm51.com wrote:


 On 10/23/2014 at 10:56 AM Randy wrote:

 |I've enjoyed kernel hot patches (ksplice) until now.
 |
 |So my primary concern is that updates to systemd appears to require
 a
 |full reboot:
 |
 |http://forums.fedoraforum.org/showthread.php?t=300166
 |
 |Is systemd really like a 2nd 'kernel' -- demanding mass reboots
 every
 |time a security issue is discovered?
 |
 |I hope not!
  =

 GNU/Linux is morphing into GNU/systemd 


Let's start calling it Systemd/Linux... that will get RMS on their
case real fast. :-)

-Jim P.

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

2014-10-23 Thread Lamar Owen


On 10/22/2014 03:51 PM, Barry Shein wrote:

I wish I had a nickel for every time I started to implement something
in bash/sh, used it a while, and quickly realized I needed something
like perl and had to rewrite the whole thing.


Barry, you've been around a long time, and these words are pearls of wisdom.

This seems to be the reasoning behind replacing the spaghetti known as 
'initscripts' currently written in sh with something written in a real 
programming language.  Upstart and systemd are both responses to the 
inflexible spaghetti now lurking in the initscript system, of which the 
pile steaming in /etc/init.d is but a part.



Sure, one can insist on charging forward in sh but at some point it
becomes, as Ken Thompson so eloquently put it on another topic
entirely, like kicking a dead whale down the beach.

This seems to be the attitude of the systemd developers, although 
they're not as eloquent as Thompson in saying it.  But I remember being 
just as abrasive, just on a smaller scale, myself...


Now, I've read the arguments, and I am squarely in the 'do one thing and 
do it well' camp.  But, let's turn that on its head, shall we? Why oh 
why do we want every single package to implement its own initscript and 
possibly do it poorly?  Wouldn't it be a case of 'do one thing well' if 
one could do away with executable shell code in each individual package 
that is going to run as root?  Wouldn't it be more 'do one thing well' 
if you had a 'super' inetd setup that can start services in a better way 
than with individually packaged (by different packagers in most cases) 
shell scripts that are going to run as root?  Shouldn't the 
initialization logic, which is 'one thing that needs doing' be in one 
container and not thousands?


Now, I say that having been a packager for a largish RPM package several 
years ago.  I waded the morass of the various packages' initscripts; 
each packager was responsible for their own script, and it was a big 
mess with initscripts doing potentially dangerous things (mine included; 
to clear it up, I maintained the PostgreSQL packages for the PostgreSQL 
upstream project from 1999 to 2004). Ever since 1999 there have been 
issues with distributed initialization logic (that runs as *root* no 
less) under hundreds of different packagers' control.  It was and is a 
kludge of the kludgiest sort.


Having a single executable program interpret a thousand config files 
written by a hundred packagers is orders of magnitude better, 
security-wise, than having thousands of executable (as *root*) scripts 
written by hundreds of different packagers, in my experienced opinion.  
If anything, having all initialization executable code in one monolithic 
package very closely monitored by several developers (and, well, for 
this purpose 'developers with attitudes' might not be the worst thing in 
the world) is more secure.  It *is* a smaller attack surface than the 
feeping creaturism found in the typical /etc/init.d directory.  And 
Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit 
and its cousin /etc/rc.local.


Now, as much as I dislike this magnitude of change, it seems to me that 
systemd actually is more inline with the traditional Unix philosophy 
than the current initialization system is.  But I always reserve the 
right to be wrong.  And I am definitely not fond of the attitudes of the 
various systemd developers; systemd assuredly has its shortcomings.  But 
it *is* here to stay, at least in RHEL-land, for at least the next ten 
years.


Having said that, if you want to use Upstart, by all means use Upstart; 
RHEL6 (and rebuilds) will have Upstart until 2020.  So you're covered 
for quite a while yet, if you use CentOS, Scientific Linux, or another 
RHEL6 rebuild (or actual RHEL6).


And for those who bugle that systemd will be the 'end of unix as we know 
it' I just have one thing to trumpet:


Death of Internet Predicted.  Film at Eleven.

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

2014-10-23 Thread Zachary

This is a good point, but it is perfectly possible to have a sysvinit
system not written in shell scripts.  I had rewritten most of the init
system in python at one point for example.  And its only been made easier
to do over time now that #! Interpertation was moved kernelside.  A system
like this could solve all the problems of both sides since it is now a
proper programming language so we can do more config style initscripts
without the blob that is systemd.  And for parallel init, you can do it in
bash, iirc Gentoo does parallel init in bash.
On Oct 23, 2014 1:45 PM, Lamar Owen lo...@pari.edu wrote:

 On 10/22/2014 03:51 PM, Barry Shein wrote:

 I wish I had a nickel for every time I started to implement something
 in bash/sh, used it a while, and quickly realized I needed something
 like perl and had to rewrite the whole thing.


 Barry, you've been around a long time, and these words are pearls of
 wisdom.

 This seems to be the reasoning behind replacing the spaghetti known as
 'initscripts' currently written in sh with something written in a real
 programming language.  Upstart and systemd are both responses to the
 inflexible spaghetti now lurking in the initscript system, of which the
 pile steaming in /etc/init.d is but a part.

  Sure, one can insist on charging forward in sh but at some point it
 becomes, as Ken Thompson so eloquently put it on another topic
 entirely, like kicking a dead whale down the beach.

  This seems to be the attitude of the systemd developers, although
 they're not as eloquent as Thompson in saying it.  But I remember being
 just as abrasive, just on a smaller scale, myself...

 Now, I've read the arguments, and I am squarely in the 'do one thing and
 do it well' camp.  But, let's turn that on its head, shall we? Why oh why
 do we want every single package to implement its own initscript and
 possibly do it poorly?  Wouldn't it be a case of 'do one thing well' if one
 could do away with executable shell code in each individual package that is
 going to run as root?  Wouldn't it be more 'do one thing well' if you had a
 'super' inetd setup that can start services in a better way than with
 individually packaged (by different packagers in most cases) shell scripts
 that are going to run as root?  Shouldn't the initialization logic, which
 is 'one thing that needs doing' be in one container and not thousands?

 Now, I say that having been a packager for a largish RPM package several
 years ago.  I waded the morass of the various packages' initscripts; each
 packager was responsible for their own script, and it was a big mess with
 initscripts doing potentially dangerous things (mine included; to clear it
 up, I maintained the PostgreSQL packages for the PostgreSQL upstream
 project from 1999 to 2004). Ever since 1999 there have been issues with
 distributed initialization logic (that runs as *root* no less) under
 hundreds of different packagers' control.  It was and is a kludge of the
 kludgiest sort.

 Having a single executable program interpret a thousand config files
 written by a hundred packagers is orders of magnitude better,
 security-wise, than having thousands of executable (as *root*) scripts
 written by hundreds of different packagers, in my experienced opinion.  If
 anything, having all initialization executable code in one monolithic
 package very closely monitored by several developers (and, well, for this
 purpose 'developers with attitudes' might not be the worst thing in the
 world) is more secure.  It *is* a smaller attack surface than the feeping
 creaturism found in the typical /etc/init.d directory.  And Barry's pearl
 of wisdom above most definitely applies to /etc/rc.sysinit and its cousin
 /etc/rc.local.

 Now, as much as I dislike this magnitude of change, it seems to me that
 systemd actually is more inline with the traditional Unix philosophy than
 the current initialization system is.  But I always reserve the right to be
 wrong.  And I am definitely not fond of the attitudes of the various
 systemd developers; systemd assuredly has its shortcomings.  But it *is*
 here to stay, at least in RHEL-land, for at least the next ten years.

 Having said that, if you want to use Upstart, by all means use Upstart;
 RHEL6 (and rebuilds) will have Upstart until 2020.  So you're covered for
 quite a while yet, if you use CentOS, Scientific Linux, or another RHEL6
 rebuild (or actual RHEL6).

 And for those who bugle that systemd will be the 'end of unix as we know
 it' I just have one thing to trumpet:

 Death of Internet Predicted.  Film at Eleven.

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

2014-10-23 Thread Valdis . Kletnieks

On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said:

 Now, I've read the arguments, and I am squarely in the 'do one thing and
 do it well' camp.  But, let's turn that on its head, shall we? Why oh
 why do we want every single package to implement its own initscript and
 possibly do it poorly?

Umm.. because maybe, just maybe, the package maintainers know more about
the ugly details of what it takes to start a given package than the init
system authors know?

If they botch the boilerplate section of an initscript, maybe they shouldn't
be releasing packages.  On the other hand, the *non*-boilerplate section of
the initscript is something that *only* the package maintainers are qualified
to write.


pgpy6DpFXXIp5.pgp
Description: PGP signature

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

2014-10-23 Thread Lamar Owen


On 10/23/2014 02:22 PM, valdis.kletni...@vt.edu wrote:

On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said:


Now, I've read the arguments, and I am squarely in the 'do one thing and
do it well' camp.  But, let's turn that on its head, shall we? Why oh
why do we want every single package to implement its own initscript and
possibly do it poorly?

Umm.. because maybe, just maybe, the package maintainers know more about
the ugly details of what it takes to start a given package than the init
system authors know?


Speaking from my own experience, the actually relevant and 
package-specific guts of the typical initscript could be easily replaced 
by a simple text configuration that simply gives:


1.) What to start
2.) When to start it (traditional initscripts work on a linear timeline 
of priority slots; systemd units have more flexibility)

3.) How to start it (command line options)

This should not need to be an executable script.  This is what systemd 
brings to the table (Upstart brought some of this, too).  It allows the 
packager to declare those details that the packager knows about the 
package and eliminates the boilerplate (that is different between 
versions of the same distribution; I for one maintained initscripts 
across multiple versions of multiple distributions, all of which had 
different boilerplate and different syntax).  I should not have needed 
to learn all the different boilerplate, as that was a distraction from 
the real meat of packaging (it could be argued that the presence of 
syntactically arcane boilerplate is a problem in and of itself: as a for 
instance, the nice 'daemon' function most RPM-based distributions supply 
in /etc/init.d/functions works for some initscripts and not for others; 
PostgreSQL is one for which it doesn't work and it's not obvious at 
first glance why it doesn't); I should simply have been able to tell the 
init system in a declarative syntax that I needed to start the program 
'/usr/bin/postmaster' with the command line options for database 
directory and listening port (among some other items).


And that includes 99% of what the various initscripts do (yeah, the 
PostgreSQL script of which I was one author did one thing that in 
hindsight should simply not have been in the initscript at all). Many of 
the 1% exceptions perhaps don't belong in code that is run as root every 
single time that particular daemon needs to start or stop.  The perhaps 
0.5% remaining that absolutely must be run before starting or stopping, 
well, yes, there should be an option in that declarative syntax to say, 
for instance, 'before starting /usr/bin/postmaster, check the version of 
the database and fail if it's older with a message to the log telling 
the admin they need to DUMP/RESTORE the database prior to trying to 
start again' .. (the systemd syntax does allow this).


I have personally compared the current PostgreSQL systemd unit 
(/usr/lib/systemd/system/postgresql.service on my CentOS 7 system) to 
the old initscript.  I wish it had been that simple years ago; the 
.service file is much cleaner, clearer, and easier to understand; no 
funky shell quote escapes needed.  And it doesn't execute as root, nor 
does it source arcane boilerplate functions, the source of some of which 
will make your eyes bleed.  And to do a customized version you just drop 
your edited copy in /etc/systemd/system/ and you're done, since it won't 
get overwritten when you update packages.


When configuring Cisco IOS, we use a declarative syntax; the systemd 
.service file's syntax is as readable as the typical startup-confg is.  
Imagine if we used the typical bash initscript syntax to bring up 
interfaces and services on our routers.

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

2014-10-23 Thread Stephen Satchell

On 10/23/2014 10:43 AM, Lamar Owen wrote:
 Wouldn't it be more 'do one thing well' if you had a 'super' inetd
 setup that can start services in a better way than with individually
 packaged (by different packagers in most cases) shell scripts that are
 going to run as root?  

inetd versus xinetd -- I thought that was an excellent change.  It was
closely targeted, well documented, and did indeed do one thing well:
accept connections and pass them off to a handler.

I'm not so sure about systemd yet.  I've not tried to create a daemon of
my own to run under the setup.  I have tried to use upstart, and found
the execution of upstart (CentOS 6) didn't match the documentation.
Further, there was no here's how you go from sysvinit to upstart that
made sense.

I did see that systemd *does* have a paper for people needing to move
from the old sysvinit to systemd, which is a plus on the surface.  I'll
be trying that in the future.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Thu, Oct 23, 2014 at 12:12:13PM -0400, Jim Popovitch wrote:
 On Thu, Oct 23, 2014 at 12:04 PM, Mike. the.li...@mgm51.com wrote:
  GNU/Linux is morphing into GNU/systemd 
 
 Let's start calling it Systemd/Linux... that will get RMS on their
 case real fast. :-)

I don't think they've done anything to deserve *that*...

- Matt

-- 
I don't do veggies if I can help it.-- stevo
If you could see your colon, you'd be horrified.-- Iain Broadfoot
If he could see his colon, he'd be management.  -- David Scheidt

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Thu, Oct 23, 2014 at 10:56:40AM -0400, Randy wrote:
 I've enjoyed kernel hot patches (ksplice) until now.
 
 So my primary concern is that updates to systemd appears to require
 a full reboot:
 
 http://forums.fedoraforum.org/showthread.php?t=300166
 
 Is systemd really like a 2nd 'kernel' -- demanding mass reboots
 every time a security issue is discovered?

But it's OK, because it reboots so *fast*!

- Matt

-- 
[O]ne of the requirements for writing code in Python seems to be that one
spends as least as much time promoting the language as coding in it.
-- Matt Roberds, in the Monastery

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Miles Fidelman


Matt Palmer wrote:

On Thu, Oct 23, 2014 at 12:12:13PM -0400, Jim Popovitch wrote:

On Thu, Oct 23, 2014 at 12:04 PM, Mike. the.li...@mgm51.com wrote:

GNU/Linux is morphing into GNU/systemd 

Let's start calling it Systemd/Linux... that will get RMS on their
case real fast. :-)

I don't think they've done anything to deserve *that*...




PulseAudio, systemd - yeah... maybe they have :-)


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Thu, Oct 23, 2014 at 04:17:14PM -0400, Miles Fidelman wrote:
 Matt Palmer wrote:
 On Thu, Oct 23, 2014 at 12:12:13PM -0400, Jim Popovitch wrote:
 On Thu, Oct 23, 2014 at 12:04 PM, Mike. the.li...@mgm51.com wrote:
 GNU/Linux is morphing into GNU/systemd 
 Let's start calling it Systemd/Linux... that will get RMS on their
 case real fast. :-)
 I don't think they've done anything to deserve *that*...
 
 PulseAudio, systemd - yeah... maybe they have :-)

Of all the PoetteringStuff out there, PA's the one that's caused me the
least problems.  I know that I'm in some vanishingly small minority there,
because it seems to cause problems for everyone around me.  One of my
colleagues needs to jiggle the wires every time he wants to use gHangouts
because PA gets itself in a tizzy.

Now *Avahi*, on the other hand... FML.

- Matt

RE: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Tony Hain

Randy wrote:
 I've enjoyed kernel hot patches (ksplice) until now.
 
 So my primary concern is that updates to systemd appears to require a full
 reboot:
 
 http://forums.fedoraforum.org/showthread.php?t=300166
 
 Is systemd really like a 2nd 'kernel' -- demanding mass reboots every time
a
 security issue is discovered?
 
 I hope not!
 
 --
 ~Randy

Given that their focus is on reducing boot-time, why wouldn't they want to
highlight that point by making you do it often??

It is clear that the systemd developers are on a solid track to catch up
with Windows-9x/ME. At the timeframe of Win9x/ME development, Gates was
hammering boot-time : boot-time : boot-time on a regular basis. My
feedback to him and his direct reports was that getting rid of reasons to
reboot was much more important than making an all too common activity less
unpleasant. Clearly a monolithic super ker-daemon will be at least as easy
to use and maintain as a Win9x machine ...  ;)

Tony

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Simon Lyall


On Wed, 22 Oct 2014, Stephen Satchell wrote:

On 10/22/2014 08:20 PM, Simon Lyall wrote:

On Wed, 22 Oct 2014, Miles Fidelman wrote:

And maybe, you should check out some of the upstream bug reports re.
systemd interactions with NTP.


If you think the current situation is all good then maybe you should
look at other bugs for ntp. eg this one I that affected me with Ubuntu
Disktop. They only run time syncing when the network is bounced so if
you have a stable network then your machine will never sync:

https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933

[..]

I'm a long-time user of NTP, and what you are asking for is a no-good
way of doing things.  What you are supposed to do is use the ntpdate(8)
utility *ONCE* on boot to initially set the system clock, then you have
ntpd(8) running to do two things for you:  sync up to one or more time
sources, and discipline the local clock.

[..]

That's the SERVER way of running a time synchronization.  So it would
appear that you have a quarrel with GUI support, not with NTP itself.


What my point was is that the simple default for end users [1] is 
already significantly broken in Ubuntu (that is just one bug that bit me, 
there are plenty of others).


The systemd system seems to offer and improvement on the existing 
simple default setup while still enabling experts to run a full ntpd 
install if they wish.


[1] - I know how to setup and run ntpd, I didn't expect to need to do it 
on my workstation however.


--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
To stay awake all night adds a day to your life - Stilgar

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Larry Sheldon


On 10/23/2014 02:15, Matt Palmer wrote:


This is the core problem with systemd, in my mind -- and what has gotten
Linus, amongst other people, so thoroughly cheesed off with the systemd
devs.  They don't play well with other children.  They don't appear
particularly interested in reusing any existing code, because it's a lot
more fun to write new code.  I'm a strong proponent of Joel Spolsky's views
on rewrites (sorry, no URL, I'm on the train) and I don't doubt that all the
same problems will come to haunt systemd on its way from being the new kid
on the block to being legacy code[1].

- Matt

[1] A computer industry term which means, it works.


...and has for more than a month.


--
The unique Characteristics of System Administrators:

The fact that they are infallible; and,

The fact that they learn from their mistakes.


Quis custodiet ipsos custodes

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-23 Thread Doug Barton


On 10/23/14 4:01 PM, Simon Lyall wrote:

On Wed, 22 Oct 2014, Stephen Satchell wrote:

On 10/22/2014 08:20 PM, Simon Lyall wrote:

On Wed, 22 Oct 2014, Miles Fidelman wrote:

And maybe, you should check out some of the upstream bug reports re.
systemd interactions with NTP.


If you think the current situation is all good then maybe you should
look at other bugs for ntp. eg this one I that affected me with Ubuntu
Disktop. They only run time syncing when the network is bounced so if
you have a stable network then your machine will never sync:

https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933

[..]

I'm a long-time user of NTP, and what you are asking for is a no-good
way of doing things.  What you are supposed to do is use the ntpdate(8)
utility *ONCE* on boot to initially set the system clock, then you have
ntpd(8) running to do two things for you:  sync up to one or more time
sources, and discipline the local clock.

[..]

That's the SERVER way of running a time synchronization.  So it would
appear that you have a quarrel with GUI support, not with NTP itself.


What my point was is that the simple default for end users [1] is
already significantly broken in Ubuntu (that is just one bug that bit
me, there are plenty of others).

The systemd system seems to offer and improvement on the existing
simple default setup while still enabling experts to run a full ntpd
install if they wish.

[1] - I know how to setup and run ntpd, I didn't expect to need to do it
on my workstation however.


If you are actually arguing that because Ubuntu made a mistake on how 
the Internet time synchronization option is configured, therefore we 
need systemd, you need to rethink your position. :)


FWIW, the problem you're describing with that option is real, and was 
revisited in later versions. As of 14.04 it was still broken, but for a 
different reason having to do with permissions on the ntpd install. 
However, fixing that problem doesn't require systemd, it requires fixing 
*that* problem.


I am not against systemd per se, I honestly don't know enough about it 
to form an intelligent opinion. The line of reasoning (I believe to be) 
espoused here is quite concerning, If there is a problem, we need to 
bring the solution into systemd. To the extent that's accurate, it's 
overwhelmingly likely to be wrong.


I could say a lot more about Unix system design philosophies from my 
time in the FreeBSD project, but this thread started off-topic, and has 
only gotten worse. :)


Doug

Re: Linux: concerns over systemd adoption and Debian's decision to switch [OT]

2014-10-23 Thread Barry Shein


All those init.d scripts do about 95% the same thing, all hacked
together in shell. Most of them are probably just slightly edited
versions of some few paleo-scripts.

Set the location of the pid file, set the path of the executable, set
the command line flags/options, maybe change some flags/options based
on some options in another file like /etc/sysconfig/daemon_name (also
shell commands which are just executed inline), then the
start/stop/reload/restart/status case statements. And the dependencies
of course.

It really could just be config files like xinetd or logrotate except
for a few hard cases where you could have a run this script
attribute.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Måns Nilsson

Subject: Re: Linux: concerns over systemd adoption and Debian's decision to 
switch Date: Tue, Oct 21, 2014 at 01:44:17PM -0700 Quoting Eric 
Brunner-Williams (brun...@nic-naa.net):
 systemd is insanity.
 
 see also smit.

(assumption, we're talking about AIX smit here) 

smit is transparent, comprehensible and automatable, not to mention
bypass-able. My wife, who is running an impressive AIX farm at her place
of work, tells me that (and I've done it myself) F4 is the key to escape.

systemd is hellspawn crap compared to this. I'm really concerned
because I run complicated process control software on Linux and this
software is shipped by Vendors who believe in if there is a support
contract for the OS, all is well fairy tales. This leaves you having
to buy DeadRat licenses, unless you can convince them that Centos is
functionally equivalent.

Time to ask for BSD ports, I think. Linux will be unusable very soon. 
-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
WHOA!!  Ken and Barbie are having TOO MUCH FUN!!  It must be the
NEGATIVE IONS!!


signature.asc
Description: Digital signature

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Rich Kulawiec

On Tue, Oct 21, 2014 at 06:17:09PM +0100, Israel G. Lugo wrote:
 The binary logs for example worry me, especially corruption issues:

As they should.  Binary logs occasionally make sense in environments
where the amount of information to be logged is huge and the rate at
which it accumulates is very high -- but those situations are few and far
between, and certainly not in play in the normal operation of a 'nix
system.  For everything else, text -- which is and has been the lingua
franca of 'nix systems since they've existed -- is perfectly adequate,
and strongly preferable.

I've seen similar tactical mistakes when developers insist that
information *must* be stored in a relational database -- even though
plain old ordinary text files are perfectly adequate for the task,
are easier to debug, are easier to fix, and easier to maintain.
There is an unfortunate tendency among many developers to attempt
to wring the very last bit of performance out of systems and not
to take into consideration that the scarcest and most expensive
resource is the system administrator.  Saving a few microseconds
or a handful of bytes here and there is a horribly bad idea if it
chews up an extra hour or week of SA time.

---rsk

RE: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Jamie Bowden

 From: Bryan Tong


 The final fact is that bash itself is a dirty language that developers hate
 and system administrators love.

Excuse me?  I've been administering systems for over twenty years now and I 
can't say that I've ever even once chosen to use bash over any alternative; no 
matter how much that alternative might suck, bash sucks more.  Your Linux 
addicts who've never used another flavor of Unix may be addicted to bash, but 
there's no helping some people.

Jamie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Stephen Satchell

On 10/22/2014 04:04 AM, Rich Kulawiec wrote:
 I've seen similar tactical mistakes when developers insist that
 information *must* be stored in a relational database -- even though
 plain old ordinary text files are perfectly adequate for the task,
 are easier to debug, are easier to fix, and easier to maintain.

Right on, bro.  I'm in the middle of a system where the architect
insists on just that.  Never mind that I brought the relational database
server to its knees (even flat on its back) because of the sheer number
of processes I'm running, and the load on the engine that causes.  My
*ONLY* option was to replicate the information in the database and store
it in files on the servers I'm running on -- semi-permanent data on the
hard drives, working data in a RAM disk system.  But updates don't
happen instantly, we have to wait for your replication daemon to run!
Yep.  Amazing how that makes the entire system considerably more stable
when you don't change horses mid-flight.  Not to mention the
considerable reduction in inter-server network traffic.

How did this discussion get into NANOG?  :)

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Andre Tomt

On 22. okt. 2014 03:40, Matt Palmer wrote:
 On Tue, Oct 21, 2014 at 07:20:12PM -0500, Jimmy Hess wrote:
 Yikes.   What's next?   Built-in DNS server + LDAP/Hesiod + Kerberos +
 SMB/Active Directory  client and server + Solitaire + Network
 Neighborhood functionality built into the program ?
 
 You missed font renderer. 
 https://technet.microsoft.com/library/security/ms14-058

I am not convinced having font rendering *IN THE KERNEL* is much better
for security.. and I doubt they put it in pid 1.

Now, should consoled, the new ntp and dhcp services have been stuffed
into the systemd tarball.. I dont know.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo israel.l...@lugosys.com wrote:

 Not intending to start a flame war here.

Bull.  If you've been around the FOSS community even for a short
while, you'd know that systemd has become a religious topic akin to
Emacs vs. Vi discussions etc.  I realize that many of the people
that read the NANOG list also use Linux systems, but that's not what I
come here for.

Please, take the systemd discussions to the mailing lists for your
distribution of choice.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch


Jeffrey Ollie wrote:

On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo israel.l...@lugosys.com wrote:

Not intending to start a flame war here.

Bull.  If you've been around the FOSS community even for a short
while, you'd know that systemd has become a religious topic akin to
Emacs vs. Vi discussions etc.  I realize that many of the people
that read the NANOG list also use Linux systems, but that's not what I
come here for.

Please, take the systemd discussions to the mailing lists for your
distribution of choice.



Seems to me, this has been a very rational discussion, confined to one 
very identifiable thread, containing what at least this reader finds 
very useful (operational impacts of systemd in server-side environments, 
and what alternatives people are looking at).


If you're not interested, you have a delete key.  Please use it, and 
don't turn this into a flame war.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 11:12 AM, Miles Fidelman
mfidel...@meetinghouse.net wrote:

 Seems to me, this has been a very rational discussion,

Hardly.  The discussion so far has been weighted very heavily on the
side of Dana Carvey's Grumpy Old Man-style whining. That's the way
it was and we liked it!.

The people that like systemd (like myself) have wisely learned that
the people that hate systemd, hate it mostly because it's different
from what came before and don't want to change.  There's no way to
argue rationally with that.

 confined to one very identifiable thread,

Thank goodness!

 containing what at least this reader finds very useful
 (operational impacts of systemd in server-side environments, and what
 alternatives people are looking at).

Just because it's useful, doesn't mean that it isn't off-topic for
NANOG.  At least until Cisco starts using systemd as pid 1 in IOS XE I
suppose...

 If you're not interested, you have a delete key.  Please use it, and don't
 turn this into a flame war.

Sure, I have a delete key, but it'd still be better if people moved
this discussion somewhere more appropriate.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Israel G. Lugo

On 22-10-2014 17:12, Miles Fidelman wrote:
 Seems to me, this has been a very rational discussion, confined to one
 very identifiable thread, containing what at least this reader finds
 very useful (operational impacts of systemd in server-side
 environments, and what alternatives people are looking at).

 If you're not interested, you have a delete key.  Please use it, and
 don't turn this into a flame war.

Agreed.

I've found this thread to be very interesting, and appreciate listening
to everyone's opinions on the matter. It does have a meaningful
operational impact, and from what I've read it seems we should at least
think about how to deal with this.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread C. Jon Larsen




Hardly.  The discussion so far has been weighted very heavily on the
side of Dana Carvey's Grumpy Old Man-style whining. That's the way
it was and we liked it!.

The people that like systemd (like myself) have wisely learned that
the people that hate systemd, hate it mostly because it's different
from what came before and don't want to change.  There's no way to
argue rationally with that.


Incorrect assumption. systemd is a massive security hole waiting to happen 
and it does not follow the unix philosophy of done 1 thing and do it 
well/correct. Its basically ignoring 40 years of best practices. Thats why 
folks that have been there, done that, dont want any part of it. Not 
because its new, but because its a flawed concept.


You are free to use it, but it would be a poor choice for system that has 
hopes of being secure.



--
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Israel G. Lugo

On 22-10-2014 17:30, Jeffrey Ollie wrote:
 Hardly. The discussion so far has been weighted very heavily on the
 side of Dana Carvey's Grumpy Old Man-style whining. That's the way
 it was and we liked it!. The people that like systemd (like myself)
 have wisely learned that the people that hate systemd, hate it mostly
 because it's different from what came before and don't want to change.
 There's no way to argue rationally with that.

Not everyone hates it. I for one would be very much interested in
listening to what you have to say about systemd, if you find it to be a
positive change. How is it better, and how you look at some of the
concerns raised in this thread. At least for me, a balancing opinion
would be welcome.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Andrew Sullivan

On Wed, Oct 22, 2014 at 12:43:53PM -0400, C. Jon Larsen wrote:

 Incorrect assumption. systemd is a massive security hole waiting to happen
 and it does not follow the unix philosophy of done 1 thing and do it
 well/correct. 

It does seem to me that this angle, at least, is on-topic for NANOG,
and I hope someone has suggestions for how to mitigate it.  It seems
that we've had two or, arguably, three recent examples (heartbleed,
shellshock, arguably poodle) of complicated code that too few people
understood and that led to widespread, late-night-inducing emergency
action once a serious vulnerability was discovered.  Surely that
direction of development in a process that runs as PID 1 is something
that has significant follow-on effects for network security.

But I have no clue what one can do about it.  For many years, I liked
to keep some Linux and some BSD systems around, because it seemed to
me that the different styles tended to encourage diversity and that
was a good thing.  But management of BSD systems -- particularly the
nonsense of rebuilding things from source all the time -- started to
look mighty onerous compared to apt-get update; apt-get upgrade.
Others apparently agreed, and now there are enough things that work
well on Linux but not as well (or not at all) on BSD that the
diversity argument isn't as strong.  (Also, of course, certain kinds
of things, like some kinds of database replication, don't work well
across platforms, so there's another reason to converge on a single
system.)  Debian was always the Linux platform that seemed most
insistent on having more than one way to do it, but in recent years
that philosophy has made it more work to use than the alternatives;
and the alternatives have often gotten good enough that one doesn't
care (Ubuntu is the obvious example here).

So, now we have an encroaching monoculture, and no real option to do
anything about it.  Maybe this is just the way the Internet is, now.

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread George Herbert





 On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie j...@ocjtech.us wrote:
 
 The people that like systemd (like myself) have wisely learned that
 the people that hate systemd, hate it mostly because it's different
 from what came before and don't want to change.  There's no way to
 argue rationally with that.

I think you are monumentally misreading the situation.

A) Change is the constant in IT. Staying relevant and employable has put me 
through five or more generational shifts in enterprise OS, plus diversions to 
Mach, Plan 9, MacOS, etc.  Change is normal.  

B) Systemd and the Solaris SMF that it conceptually followed have a number of 
technical flaws, ranging from obscure interfaces (sometimes requiring source 
code to understand) to lack of human readable configs to (at least with SMF, 
and as far as I can tell systemd) a lack of ability to even print/dump out the 
current dependencies and ordering tree.

C) In both systemd and SMF a tremendous unpreparedness of training and 
documentation accompanied rollout.  These were not reasonably enterprise ready 
at launch, or now.

D) The architectural case that the services adopted in systemd over time belong 
there or are safe there is not proven, and not that I see well argued or 
documented.  Conglomerated services are at least to be eyed skeptically.

I did not closely follow systemd's development but it is evident from a 
distance that operator feedback in the community and to Sun regarding SMF flaws 
was somehow missed in systemd's development as they did the same wrong things.

A change this big deserves architectural clarity and justification.  We get 
snide comments about change being good and core developers Linus  evidently 
feels are unsafe.


George William Herbert
Sent from my iPhone

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Daniel Corbe

Andrew Sullivan asulli...@dyn.com writes:

 On Wed, Oct 22, 2014 at 12:43:53PM -0400, C. Jon Larsen wrote:

 Incorrect assumption. systemd is a massive security hole waiting to happen
 and it does not follow the unix philosophy of done 1 thing and do it
 well/correct. 

 But I have no clue what one can do about it.  For many years, I liked
 to keep some Linux and some BSD systems around, because it seemed to
 me that the different styles tended to encourage diversity and that
 was a good thing.  But management of BSD systems -- particularly the
 nonsense of rebuilding things from source all the time -- started to
 look mighty onerous compared to apt-get update; apt-get upgrade.
 Others apparently agreed, and now there are enough things that work
 well on Linux but not as well (or not at all) on BSD that the
 diversity argument isn't as strong.  (Also, of course, certain kinds
 of things, like some kinds of database replication, don't work well
 across platforms, so there's another reason to converge on a single
 system.)  Debian was always the Linux platform that seemed most
 insistent on having more than one way to do it, but in recent years
 that philosophy has made it more work to use than the alternatives;
 and the alternatives have often gotten good enough that one doesn't
 care (Ubuntu is the obvious example here).

 So, now we have an encroaching monoculture, and no real option to do
 anything about it.  Maybe this is just the way the Internet is, now.

 A

Not to get even further off topic here but when was the last time you
maintained a BSD system?   FreeBSD (at least) adopted binary package
management as its preferred interface to ports through pkg-ng somewhere
in the 9-RELEASE cycle.  

As long as you don't need exotic compile-time options you should be good
to go.  Which is in contrast to the Linux package management paradigm
where you basically enable everything at compile time.  

If you do need to compile something by source though you still have that
option.  

This systemd debacle is an excellent reason to look into stuff that
isn't Linux.  The Linux camp all too often become victims of not
invented here and because we can is not a good enough reason to
replace something that has worked just fine for 30 or 40 some-odd years.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 11:43 AM, C. Jon Larsen jlar...@richweb.com wrote:

 Hardly.  The discussion so far has been weighted very heavily on the
 side of Dana Carvey's Grumpy Old Man-style whining. That's the way
 it was and we liked it!.

 The people that like systemd (like myself) have wisely learned that
 the people that hate systemd, hate it mostly because it's different
 from what came before and don't want to change.  There's no way to
 argue rationally with that.

 Incorrect assumption. systemd is a massive security hole waiting to happen

The same can be said for any software.  Shellshock anyone?  How many
security issues remain in bash?  One of the reasons systemd was first
written was to get rid of the the tangle of shell scripts that are
used to start up a system using sysvinit.

 and it does not follow the unix philosophy of done 1 thing and do it
 well/correct. Its basically ignoring 40 years of best practices. Thats why
 folks that have been there, done that, dont want any part of it. Not because
 its new, but because its a flawed concept.

I was going to write a longer response here, but this:

http://lwn.net/Articles/576078/

sums up my thoughts on the unix philosophy.  It's not the
be-all-end-all that you make it out to be.  Again, this sounds a lot
like Grumpy Old Man complaining.

 You are free to use it, but it would be a poor choice for system that has
 hopes of being secure.

I would disagree, especially since systemd makes it practical to use
many of the capabilities of the Linux kernel that can improve
security, like filesystem namespaces, cgroups, etc.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 12:35 PM, George Herbert
george.herb...@gmail.com wrote:




 On Oct 22, 2014, at 9:30 AM, Jeffrey Ollie j...@ocjtech.us wrote:

 The people that like systemd (like myself) have wisely learned that
 the people that hate systemd, hate it mostly because it's different
 from what came before and don't want to change.  There's no way to
 argue rationally with that.

 I think you are monumentally misreading the situation.

 A) Change is the constant in IT. Staying relevant and employable has put me 
 through five or more generational shifts in enterprise OS, plus diversions to 
 Mach, Plan 9, MacOS, etc.  Change is normal.

I agree with you about change, but there are a number of people that
vocally resist any kind of change, no matter what.  There's little
that can change their mind other than time.  It's a useful skill to be
able to recognize these people and not to let them get you down.

 B) Systemd and the Solaris SMF that it conceptually followed have a number of 
 technical flaws, ranging from obscure interfaces (sometimes requiring source 
 code to understand) to lack of human readable configs to (at least with SMF, 
 and as far as I can tell systemd) a lack of ability to even print/dump out 
 the current dependencies and ordering tree.

I have no experience with Solaris SMF so I can't comment on it
specifically, but in my opinion systemd:

1) has excellent documentation, especially when you compare it to
other open source documentation.
2) What's more readable than .ini files?  They even avoided the
temptation to use XML.  I can't tell you how much time I've wasted
reading shell script spaghetti trying to figure out exactly how a
service is started up.  Services implemented in Java and Ruby seem to
be especially bad at that.
3) systemctl list-dependencies, although since service start-up in
systemd is highly dynamic it's difficult to predict what order
services will start up.

 C) In both systemd and SMF a tremendous unpreparedness of training and 
 documentation accompanied rollout.  These were not reasonably enterprise 
 ready at launch, or now.

In 2010/2011 when systemd was first being integrated into Fedora (and
I believe SuSE) I would have agreed with you.  However this is four
years later and I couldn't disagree with you more.  More to the point,
Red Hat disagrees with you, given that they have put their money where
their mouth is and integrated systemd into RHEL7.

 D) The architectural case that the services adopted in systemd over time 
 belong there or are safe there is not proven, and not that I see well argued 
 or documented.  Conglomerated services are at least to be eyed skeptically.

 I did not closely follow systemd's development but it is evident from a 
 distance that operator feedback in the community and to Sun regarding SMF 
 flaws was somehow missed in systemd's development as they did the same wrong 
 things.

 A change this big deserves architectural clarity and justification.

I don't follow systemd development closely either, but Lennart
Poettering, Kay Sievers, et. al. have made extraordinary attempts to
communicating about systemd.  They've appeared at numerous conferences
and given talks about systemd, written blog posts, documentation, etc.
I don't know what else they can do other than to be invited over to
everyone's home for tea and a systemd discussion.

 We get snide comments about change being good and core developers Linus  
 evidently feels are unsafe.

We also get snide comments about change being bad.  As for Linus,
other than the fact that he has an extraordinary amount of influence
over what goes into the kernel, I've learned to take his comments on
other matters with a very large grain of salt.  I have a lot of
respect for the guy, but his attitude and behavior towards other
people is appalling.

What's really surprising about some of Linus' comments WRT to systemd
is that one of systemd's main goals is to make it easier to use some
of the advanced functionality of the Linux kernel that were little
used or ignored before.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch


On October 21, 2014 at 13:44 brun...@nic-naa.net (Eric Brunner-Williams) wrote:
   systemd is insanity.
  
  see also smit.

SMIT! Rhymes with 


-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Andrew Sullivan

On Wed, Oct 22, 2014 at 01:35:26PM -0400, Daniel Corbe wrote:

 Not to get even further off topic here but when was the last time you
 maintained a BSD system?   FreeBSD (at least) adopted binary package
 management as its preferred interface to ports through pkg-ng somewhere
 in the 9-RELEASE cycle.  

Yeah, it was some time ago (fortunately, people keep me far away from
systems administration now).  But that doesn't exactly help: since
others drew the same conclusion, _even if BSD is now a perfectly
rational choice_, I've lost functionality I desire.  Docker is a great
example of this.  For many use cases, it's obviously better than the
alternatives.  So now I _can't_ pick FreeBSD.  And so on.

 This systemd debacle is an excellent reason to look into stuff that
 isn't Linux.  The Linux camp all too often become victims of not
 invented here

I don't think the latter is restricted to the Linux world!  But as I
suggested, the network security implications of all that stuff hidden
in one critical system sure seem to require some thinking.

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread John Schiel



On 10/22/2014 10:43 AM, C. Jon Larsen wrote:



Hardly.  The discussion so far has been weighted very heavily on the
side of Dana Carvey's Grumpy Old Man-style whining. That's the way
it was and we liked it!.

The people that like systemd (like myself) have wisely learned that
the people that hate systemd, hate it mostly because it's different
from what came before and don't want to change.  There's no way to
argue rationally with that.


Incorrect assumption. systemd is a massive security hole waiting to 
happen and it does not follow the unix philosophy of done 1 thing and 
do it well/correct. 


i was beginning to wonder how secure systemd is also.

--John

Its basically ignoring 40 years of best practices. Thats why folks 
that have been there, done that, dont want any part of it. Not because 
its new, but because its a flawed concept.


You are free to use it, but it would be a poor choice for system that 
has hopes of being secure.



--
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 2:13 PM, John Schiel jsch...@flowtools.net wrote:
 On 10/22/2014 10:43 AM, C. Jon Larsen wrote:

 Incorrect assumption. systemd is a massive security hole waiting to happen
 and it does not follow the unix philosophy of done 1 thing and do it
 well/correct.

 i was beginning to wonder how secure systemd is also.

Personally, I feel that the systemd developers have given a lot of
thought to security, both in the systemd code itself and because
systemd makes it practical to use advanced features of the Linux
kernel that can improve security.

One example is the fact that systemd makes it very easy to give a
service a private /tmp and /var/tmp directory that no other service
uses by using Linux's filesystem namespaces.  That can avoid all sorts
of tmpfile race conditions that have caused problems in the past.

Doing that in sysvinit, while possible, wasn't easy because you'd have
to modify each init.d script (and redo the change every time upstream
released a new update) to create/manage the filesystem namespace.  In
practice it was never done.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Valdis . Kletnieks

On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said:

 i was beginning to wonder how secure systemd is also.

One of the 3 CIA pillars of security is availability.  And if
it's oh-dark-30, figuring out what symlink is supposed to be where
for a given failed systemd unit can be a tad challenging.  At least under
sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*).

And if they carry through on their systemd-console threat, that could get
even worse - that introduces a whole new pile of risks for being unable
to diagnose early boot bugs

So yeah, there's security issues other than can it be hacked because
it's got a huge surface area.

(*) Unless you're really having a bad night and it's a hard link to /dev/sda1
or something. :)


pgpbIkuVZXJ5e.pgp
Description: PGP signature

Re: Linux: concerns over systemd adoption and Debian's decision to switch


On October 22, 2014 at 07:04 r...@gsp.org (Rich Kulawiec) wrote:
  I've seen similar tactical mistakes when developers insist that
  information *must* be stored in a relational database -- even though
  plain old ordinary text files are perfectly adequate for the task,
  are easier to debug, are easier to fix, and easier to maintain.
  There is an unfortunate tendency among many developers to attempt
  to wring the very last bit of performance out of systems and not
  to take into consideration that the scarcest and most expensive
  resource is the system administrator.  Saving a few microseconds
  or a handful of bytes here and there is a horribly bad idea if it
  chews up an extra hour or week of SA time.

Obviously it depends on the application, generalities are dangerous.

But one advantage of DBs are that you automatically get all the
mechanics of failover, distribution, backup and recovery, atomicity,
consistency, integrity, security, etc. that come with the DB
essentially for free.

There is a tendency that one starts with this idea of keeping it
simple, such as text files, and then proceeds to build all these
mechanisms themselves, usually poorly.

Look at how many different formats of configuration files we have on a
typical *ix system, nearly one per application/daemon that needs a
config file. Why do I have to know how to properly modify a passwd
file, named config, logrotate, tcp wrappers, mail daemon configs,
anti-spam configs, etc etc etc (usually in /etc!) down to what they
will each take for a comment or separator or stanza syntax.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

RE: Linux: concerns over systemd adoption and Debian's decision to switch


On October 22, 2014 at 11:36 jamie.s.bow...@raytheon.com (Jamie Bowden) wrote:
   From: Bryan Tong
  
  
   The final fact is that bash itself is a dirty language that developers hate
   and system administrators love.
  
  Excuse me?  I've been administering systems for over twenty years now and I 
  can't say that I've ever even once chosen to use bash over any alternative; 
  no matter how much that alternative might suck, bash sucks more.  Your Linux 
  addicts who've never used another flavor of Unix may be addicted to bash, 
  but there's no helping some people.

I wish I had a nickel for every time I started to implement something
in bash/sh, used it a while, and quickly realized I needed something
like perl and had to rewrite the whole thing.

Sure, one can insist on charging forward in sh but at some point it
becomes, as Ken Thompson so eloquently put it on another topic
entirely, like kicking a dead whale down the beach.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: Linux: concerns over systemd adoption and Debian's decision to switch


On October 22, 2014 at 05:43 l...@satchell.net (Stephen Satchell) wrote:
  
  How did this discussion get into NANOG?  :)

Because in the field of automotive engineering we are the ones who
actually need to get down the road on time, reliably, and consistently
while the automotive engineers probably take the bus where they can
continue their design discussions.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool  Die| Public Access Internet | SINCE 1989 *oo*

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread John Schiel



On 10/22/2014 01:30 PM, valdis.kletni...@vt.edu wrote:

On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said:


i was beginning to wonder how secure systemd is also.

One of the 3 CIA pillars of security is availability.  And if
it's oh-dark-30, figuring out what symlink is supposed to be where
for a given failed systemd unit can be a tad challenging.  At least under
sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*).

And if they carry through on their systemd-console threat, that could get
even worse - that introduces a whole new pile of risks for being unable
to diagnose early boot bugs

So yeah, there's security issues other than can it be hacked because
it's got a huge surface area.


Agreed, the oh-dark-thirty call outs will be harder to resolve but I'm 
sure some folks will learn to deal with it. It's new and changes the job 
but as was noted earlier, there is always change.


My concern is with the large surface area. Does that expose the daemon 
to more vulnerabilities because it does more or does one daemon make it 
easier to protect against multiple vulnerabilities? I don't know, that's 
where the research needs to be done.


--John



(*) Unless you're really having a bad night and it's a hard link to /dev/sda1
or something. :)

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 2:30 PM, valdis.kletni...@vt.edu wrote:
On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said:

i was beginning to wonder how secure systemd is also.

One of the 3 CIA pillars of security is availability. And if
it's oh-dark-30, figuring out what symlink is supposed to be where
for a given failed systemd unit can be a tad challenging. At least under
sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*).

How long has it been since you've looked at/used systemd? Manual
management of symlinks to control what services are started at boot
time are a thing of the past. systemctl enable|disable|status
service will handle all of that for you. I agree, managing
symlinks was annoying in the early systemd days, but I haven't messed
with those symlinks manually in a long time, except to remove orphan
symlinks caused by services that weren't removed cleanly from the
system.

I think your fear comes more from a lack of familiarity with systemd,
rather than a true technical deficit.

Personally I find systemd services much easier to debug, especially
since stderr and stdout from all services is captured, rather than
being lost to /dev/null.

I find it VERY annoying that many init.d scripts eventually boil down
to /usr/sbin/program --someflags 21 /dev/null .

And if they carry through on their systemd-console threat, that could get
even worse - that introduces a whole new pile of risks for being unable
to diagnose early boot bugs

I haven't seen much about systemd-console, but I thought that this
reddit thread was interesting.

http://www.reddit.com/r/linux/comments/1rmj9e/systemd_is_about_to_gain_a_system_console_boot/

It seems to me that moving VTs out of the kernel and into a userspace
process would be a good thing. I guess one could argue about whether
systemd is the right place for it, but as you can see from that reddit
thread there have been a number of other projects that have attempted
to do that but have failed to gain traction for one reason or another.
One thing that the systemd developers are undeniably good at is
getting their work adopted by the distributions.

So yeah, there's security issues other than can it be hacked because
it's got a huge surface area.

Nothing new here. And before you get started, Bash and OpenSSL prove
that old code isn't necessarily secure code.

--
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 3:22 PM, John Schiel jsch...@flowtools.net wrote:

 On 10/22/2014 01:30 PM, valdis.kletni...@vt.edu wrote:

 On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said:

 i was beginning to wonder how secure systemd is also.

 One of the 3 CIA pillars of security is availability.  And if
 it's oh-dark-30, figuring out what symlink is supposed to be where
 for a given failed systemd unit can be a tad challenging.  At least under
 sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*).

 Agreed, the oh-dark-thirty call outs will be harder to resolve but I'm
 sure some folks will learn to deal with it. It's new and changes the job but
 as was noted earlier, there is always change.

I disagree.  I believe that the features of systemd will make
oh-dark-thirty call outs easier to resolve, but only if you take the
time to familiarize yourself with the tools at hand *before* problems
happen.

But really, there's nothing new here.  *Of course* systems that are
unfamiliar to you will be more difficult to fix.  It'd take *me*
*forever* to fix a problem on the HP-UX systems at work, mainly
because I'd spend too much time figuring out where everything was.
However the guy in the cube next to me wouldn't have that problem...

To borrow Barry's automotive metaphor, this is like saying that
electric motors are bad because I only know how to fix gasoline
engines.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch


Jeffrey Ollie wrote:

On Wed, Oct 22, 2014 at 3:22 PM, John Schiel jsch...@flowtools.net wrote:

On 10/22/2014 01:30 PM, valdis.kletni...@vt.edu wrote:

On Wed, 22 Oct 2014 13:13:29 -0600, John Schiel said:


i was beginning to wonder how secure systemd is also.

One of the 3 CIA pillars of security is availability.  And if
it's oh-dark-30, figuring out what symlink is supposed to be where
for a given failed systemd unit can be a tad challenging.  At least under
sysvinit, either /etc/rc5.d/S50foobar is there or it isn't(*).

Agreed, the oh-dark-thirty call outs will be harder to resolve but I'm
sure some folks will learn to deal with it. It's new and changes the job but
as was noted earlier, there is always change.

I disagree.  I believe that the features of systemd will make
oh-dark-thirty call outs easier to resolve, but only if you take the
time to familiarize yourself with the tools at hand *before* problems
happen.


Easier said then done.

1. Experimentation and learning curve take time.  That's a real cost 
that's being imposed.  It's not clear that the benefits outweigh the 
costs of the status quo.


2. Assumes good documentation.  Not a given with systemd, as it stands now.

3. Assumes that problems are easy to track down.  Harder to do with 
murky and monolithic code.  (I still shudder the first time udev did 
something completely counter-intuitive at 0-dark-30, and that's from the 
same cast of characters.


4. More fundamentally, 0-dark-30 events are almost always unexpected 
(other than in the sense of Murphy's Law), and tricky to resolve - one 
has hopefully prepared for the expected.  Hence, it's not completely 
clear that one CAN familiarize oneself in a meaningful way - 
particularly when talking about something as monolithic as systemd.  
That's one of the major reasons for keeping things modular, and keeping 
modules simple.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Randy Bush

 4. More fundamentally, 0-dark-30 events are almost always unexpected
 (other than in the sense of Murphy's Law), and tricky to resolve - one
 has hopefully prepared for the expected.

If it was part of the 'plan' it’s an event; if it is not then it’s a
'disaster'

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Rich Kulawiec

On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote:
 The people that like systemd (like myself) have wisely learned that
 the people that hate systemd, hate it mostly because it's different
 from what came before and don't want to change.

That's an entirely unfair characterization.

Some of us, including a lot of people on this list, have been pushing the
envelope on change for decades.  We've run alpha software on beta hardware,
cobbled together networks with duct tape, and burned a lot of midnight oil
while making innumerable mistakes and learning from them.

Speaking for myself, after migrating through far too many Unix
and Linux distributions to count, starting with Research Unix v6,
my entire professional career has been *constant* change.  I suspect
that the same is true of everyone else who's been doing this for a while.
Anyone who doesn't embrace change as a way of life probably isn't on
this list; they're somewhere else, maintaining Cobol written during
the Nixon administration.

My problem with systemd is not that it's a change: it's just one more
out of tens of thousands and so, in that sense, it's really not a big deal.
My problem with it is that I think it's a bad change, one not in keeping
with the software tools philosophy that has served us ridiculously
well for a very long time and -- so far -- has not been shown itself
to be in need of replacement.

A Leatherman pocket multitool is highly useful: I've had one for years.
It's great.  Until you need two screwdrivers at the same time...at which
point it becomes obvious why serious mechanics/craftsmen carry around a
toolbox with dozens of tools and why glomming all of those into one
supertool would be A Very Bad Move.

Similarly, the monolithic (and ever-expanding) nature of systemd is a
strategic design error.  That's probably not obvious to people who
measure their experience in years instead of decades -- it wouldn't
have been obvious to me back in the day either.  But it's pretty clear
from here, and dismissing it as hey you kids get off my lawn geezer
whining is not going to advance the discussion.  It would be better,
I think, to pull out a copy of Kernighan and Plauger's book -- which
is rather brief, actually -- read it cover-to-cover, and then consider
carefully whether the myriad-and-steadily-increasing number of functions
being subsumed by systemd should actually be in one program.

If that doesn't suffice, then I suspect it will only require waiting
a little while until a demonstration of why monolithic integration
is a bad idea will be provided by someone who is at this moment
studying the large-and-growing attack surface presented by systemd.

I hope I'm wrong about that.  I'm probably not.

(By the way, this should not be read to express unabashed support
for *any* of the various init systems that have been present in SysV
or BSD or AIX or Debian or Dynix or Red Hat or HPUX or Mint or Ultrix
or Solaris or or or or.  They all have their issues, some of which
were or are sporadically annoying.)

---rsk

Re: Linux: concerns over systemd adoption and Debian's decision to switch


Well said, Rich.

Rich Kulawiec wrote:

On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote:

The people that like systemd (like myself) have wisely learned that
the people that hate systemd, hate it mostly because it's different
from what came before and don't want to change.

That's an entirely unfair characterization.

Some of us, including a lot of people on this list, have been pushing the
envelope on change for decades.  We've run alpha software on beta hardware,
cobbled together networks with duct tape, and burned a lot of midnight oil
while making innumerable mistakes and learning from them.

Speaking for myself, after migrating through far too many Unix
and Linux distributions to count, starting with Research Unix v6,
my entire professional career has been *constant* change.  I suspect
that the same is true of everyone else who's been doing this for a while.
Anyone who doesn't embrace change as a way of life probably isn't on
this list; they're somewhere else, maintaining Cobol written during
the Nixon administration.

My problem with systemd is not that it's a change: it's just one more
out of tens of thousands and so, in that sense, it's really not a big deal.
My problem with it is that I think it's a bad change, one not in keeping
with the software tools philosophy that has served us ridiculously
well for a very long time and -- so far -- has not been shown itself
to be in need of replacement.

A Leatherman pocket multitool is highly useful: I've had one for years.
It's great.  Until you need two screwdrivers at the same time...at which
point it becomes obvious why serious mechanics/craftsmen carry around a
toolbox with dozens of tools and why glomming all of those into one
supertool would be A Very Bad Move.

Similarly, the monolithic (and ever-expanding) nature of systemd is a
strategic design error.  That's probably not obvious to people who
measure their experience in years instead of decades -- it wouldn't
have been obvious to me back in the day either.  But it's pretty clear
from here, and dismissing it as hey you kids get off my lawn geezer
whining is not going to advance the discussion.  It would be better,
I think, to pull out a copy of Kernighan and Plauger's book -- which
is rather brief, actually -- read it cover-to-cover, and then consider
carefully whether the myriad-and-steadily-increasing number of functions
being subsumed by systemd should actually be in one program.

If that doesn't suffice, then I suspect it will only require waiting
a little while until a demonstration of why monolithic integration
is a bad idea will be provided by someone who is at this moment
studying the large-and-growing attack surface presented by systemd.

I hope I'm wrong about that.  I'm probably not.

(By the way, this should not be read to express unabashed support
for *any* of the various init systems that have been present in SysV
or BSD or AIX or Debian or Dynix or Red Hat or HPUX or Mint or Ultrix
or Solaris or or or or.  They all have their issues, some of which
were or are sporadically annoying.)

---rsk



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 3:49 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:

 1. Experimentation and learning curve take time.  That's a real cost that's
 being imposed.

What makes systemd different from any other technology in that respect?

 It's not clear that the benefits outweigh the costs of the status quo.

Ultimately this is a very personal decision, but given the adoption
rate of systemd by distributions I don't think that it's going to be
that long before people (at least if you want to be employed managing
Linux systems) don't have a choice but to become at least passably
familiar with systemd.  Even if Debian steps back from systemd,
Canonical and Red Hat have committed to systemd.

 2. Assumes good documentation.  Not a given with systemd, as it stands now.

Why does everyone assume that systemd doesn't have good documentation?
 I personally have found the documentation to be excellent.

 3. Assumes that problems are easy to track down.  Harder to do with murky
 and monolithic code.

Statements that are equally valid for sysvinit.

  (I still shudder the first time udev did something
 completely counter-intuitive at 0-dark-30, and that's from the same cast of
 characters.

Udev predates systemd, by a long long time.  If you have problems with
udev don't blame systemd.

 4. More fundamentally, 0-dark-30 events are almost always unexpected (other
 than in the sense of Murphy's Law), and tricky to resolve - one has
 hopefully prepared for the expected.  Hence, it's not completely clear that
 one CAN familiarize oneself in a meaningful way - particularly when talking
 about something as monolithic as systemd.  That's one of the major reasons
 for keeping things modular, and keeping modules simple.

This really has nothing to do with systemd.  I believe that systemd
has made things better in this respect, but you're welcome to believe
that the pile of shell scripts in /etc/init.d is better.  sarcasmI
mean really, what could go wrong when we configure boot-up with a
Turing complete language?/sarcasm  Really... I know of several
instances a poorly-written init script caused boot-up to fail because
they had infinite loops in them.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 4:43 PM, Rich Kulawiec r...@gsp.org wrote:
 On Wed, Oct 22, 2014 at 11:30:57AM -0500, Jeffrey Ollie wrote:
 The people that like systemd (like myself) have wisely learned that
 the people that hate systemd, hate it mostly because it's different
 from what came before and don't want to change.

 That's an entirely unfair characterization.

 Some of us, including a lot of people on this list, have been pushing the
 envelope on change for decades.  We've run alpha software on beta hardware,
 cobbled together networks with duct tape, and burned a lot of midnight oil
 while making innumerable mistakes and learning from them.

 Speaking for myself, after migrating through far too many Unix
 and Linux distributions to count, starting with Research Unix v6,
 my entire professional career has been *constant* change.  I suspect
 that the same is true of everyone else who's been doing this for a while.
 Anyone who doesn't embrace change as a way of life probably isn't on
 this list; they're somewhere else, maintaining Cobol written during
 the Nixon administration.

Been there, done that, got the T-shirt.

 My problem with systemd is not that it's a change: it's just one more
 out of tens of thousands and so, in that sense, it's really not a big deal.
 My problem with it is that I think it's a bad change, one not in keeping
 with the software tools philosophy that has served us ridiculously
 well for a very long time and -- so far -- has not been shown itself
 to be in need of replacement.

 A Leatherman pocket multitool is highly useful: I've had one for years.
 It's great.  Until you need two screwdrivers at the same time...at which
 point it becomes obvious why serious mechanics/craftsmen carry around a
 toolbox with dozens of tools and why glomming all of those into one
 supertool would be A Very Bad Move.

I carry a Leatherman too, and indeed it is a very useful tool.  But
it's useful in the real world because physical tools have mass, and
there's only so much mass that a person wants to carry around with
them all of the time. In all other respects the tools on a Leatherman
are far less superior than a tool purposely designed for a task.

Software doesn't have mass so your analogy doesn't quite work.

systemd is a tool designed to get the system to a state where real
work can be done.  NTP servers, DHCP clients, consoles, aren't the
real work of a system, or at least I hope not, because that would be
boring to me.

I'm not going to justify everything that the systemd developers have
done here, but I've been convinced that the functions that they have
moved into systemd have been justified because it'll make systems work
better and more robustly.

 Similarly, the monolithic (and ever-expanding) nature of systemd is a
 strategic design error.  That's probably not obvious to people who
 measure their experience in years instead of decades -- it wouldn't
 have been obvious to me back in the day either.  But it's pretty clear
 from here, and dismissing it as hey you kids get off my lawn geezer
 whining is not going to advance the discussion.

You may have been in the biz longer than I have, but not by as much
as you think.  I didn't immediately see the value of systemd, but it
didn't take me long.

Your arguments still come off as appeal to tradition.  It was impolite
to call it old geezer whining was impolite but that doesn't change the
nature of your argument.

  It would be better,
 I think, to pull out a copy of Kernighan and Plauger's book -- which
 is rather brief, actually -- read it cover-to-cover, and then consider
 carefully whether the myriad-and-steadily-increasing number of functions
 being subsumed by systemd should actually be in one program.

It's been a while since I've read it, but ISTR that the modularity
that KP speak of refers to procedures and functions, they didn't seem
especially afraid of big programs.  And from what I've seen the
systemd code is properly modularized in the sense that KP use.
Speaking of which, did you know that sysvinit has no unit tests (or
tests of any other kind)?  And since every init script is code (even
though many people treat it like configuration data) why don't they
have unit tests either?  systemd has an extensive test suite, that
gives me some reassurance that bugs, once found, won't be
reintroduced.

And I'm sure that if we went through the Elements of Programming Style
point by point there is much more in systemd's favor.

 If that doesn't suffice, then I suspect it will only require waiting
 a little while until a demonstration of why monolithic integration
 is a bad idea will be provided by someone who is at this moment
 studying the large-and-growing attack surface presented by systemd.

 I hope I'm wrong about that.  I'm probably not.

Software is software.  I'm sure that bugs (including security bugs)
will be found.  Film at 11.  Nothing new here.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Stephen Satchell

On 10/22/2014 02:43 PM, Rich Kulawiec wrote:
 A Leatherman pocket multitool is highly useful: I've had one for years.
 It's great.  Until you need two screwdrivers at the same time...at which
 point it becomes obvious why serious mechanics/craftsmen carry around a
 toolbox with dozens of tools and why glomming all of those into one
 supertool would be A Very Bad Move.

I find this analogy very, very interesting.  I'm looking at my
Leatherman tool, and see that every single tool is based on a standard;
nothing invented here just for the Leatherman.  The Phillips
screwdriver is the standard P2 shape, not some off-the-wall grinding.
And so forth.

 Similarly, the monolithic (and ever-expanding) nature of systemd is a
 strategic design error.  That's probably not obvious to people who
 measure their experience in years instead of decades -- it wouldn't
 have been obvious to me back in the day either.  But it's pretty clear
 from here, and dismissing it as hey you kids get off my lawn geezer
 whining is not going to advance the discussion.  

It's one thing to integrate a bridge to existing functions into a
system.  It's another to re-invent things for the sake of re-inventing
them.  If you have a perfectly good DHCP package, work *with* it instead
of going through the trial of building and debugging your own version.
Why duplicate effort?  Why have two of something that has to be
maintained instead of concentrating on improving the one you have?

Now, sometimes you do have to sit down and say this is hopeless, let's
start from scratch -- particularly when it was done to a bad spec and
tried to do too much without step-wise refinement.  (healthcare.gov,
anyone?)  But even when HeartBleed-SSH was forked, it wasn't abandoned
and started from scratch; the BSD people just pruned all the non-POSIX
guck and stripped it down to essentials.  And did a proper security audit.

We don't need systemd to turn into a hydra.  If there is an issue with
NTP or DHCP or whatever, systemd developers should go to the upstream
and fix the issue in that package, not clone its own version and,
perhaps, make the same mistakes all over again.

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Israel G. Lugo


On 10/23/2014 12:05 AM, Jeffrey Ollie wrote:

 systemd is a tool designed to get the system to a state where real
 work can be done.  NTP servers, DHCP clients, consoles, aren't the
 real work of a system, or at least I hope not, because that would be
 boring to me.

That idea sounds interesting. I can see where you're coming from.
Basically, these things are details, that shouldn't really be all that
important, so systemd is supposed to take care of it all and leave you
to worry about the actual bread and butter. That about it?

Legitimate question, not trying to be sarcastic: would you concede that
the amount to which something is a detail may vary significantly per
the use case, and requirements? On my desktop I might not care about
whatever the DHCP client is doing, or the NTP server, but on a server
that may very well be a different story.

For example, I'm very interested in NTP and accurate timekeeping --
mostly as a personal hobby, but it's been useful at work as well. I for
one would definitely not consider NTP one of those details that just
come with the bootup process.


 [regarding the Leatherman]
 Software doesn't have mass so your analogy doesn't quite work.

Analogies can only be taken so far before they cease to make sense.
However, in the software world you could consider a mass equivalent:
code size / complexity. Building on that, just as the Leatherman can't
be as good as all the individual tools combined without weighing too
much, one could say systemd can't be as good as all the individual tools
it aims to replace without being too big and complex.

Program mass, in this case, may impact anything from performance, to
ease of configuration, to complicated dependencies, to security problems.

I did find it interesting, however, what you mentioned in another email,
about systemd implementing certain isolation features such as separate
filesystem namespaces and so on. That may be very useful.


I think the main point that we could hopefully all agree on here, is
that it would be very difficult to have a single one size fits all
solution. The requirements and concerns of the desktop, for example, are
simply too different from those of the server or router space. systemd,
for better or for worse, can't be the one magic bullet. Great or
terrible as though it may be, I don't much like the total break in
compatibility (correct me if I'm wrong). I'm not saying SysV is all that
good, but there are other replacements, and new ones can be designed,
but don't make it so that everyone-has-to-use-yours-or-else! I guess we
have GNOME to thank for that... And that's what troubles me the most:
the lack of choice that seems to be creeping up, with everyone just
ganging up and jumping to systemd like the floor is on fire. I'm with
Jay Ashworth on this one: what gives??

Also, for the person who considered this OT for not being about Cisco,
keep in mind all the world is not a VAX^H^H^HCisco ;)

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 7:36 PM, Israel G. Lugo israel.l...@lugosys.com wrote:

 For example, I'm very interested in NTP and accurate timekeeping --
 mostly as a personal hobby, but it's been useful at work as well. I for
 one would definitely not consider NTP one of those details that just
 come with the bootup process.

As you can see in another email I posted, it's trivially easy to
disable systemd's NTP implementation and replace it with another.

The same goes for systemd's DHCP server, as far as I know there's no
distribution using it by default yet.  Fedora is still using
NetworkManager,  I think that RHEL 7 defaults to the same network
scripts that have always been used, although it's very easy to switch
to NetworkManager if that's what you want.

So a lot of the whining you see about systemd forcing a NTP or DHCP
server on you is hyperbole by people that have read a few articles on
slashdot/reddit/whatever and take that as gospel.

 I did find it interesting, however, what you mentioned in another email,
 about systemd implementing certain isolation features such as separate
 filesystem namespaces and so on. That may be very useful.

Yes, indeed, very useful.

 I think the main point that we could hopefully all agree on here, is
 that it would be very difficult to have a single one size fits all
 solution. The requirements and concerns of the desktop, for example, are
 simply too different from those of the server or router space.

I have found the desktop vs. server arguments with respect to
systemd unconvincing.  I find many/most of the features of systemd
useful in both contexts.

I think that the problem with the desktop/server dichotomy is that
servers are no longer what they used to be.  Servers used to be these
things that sat in the back room and would reboot once or twice a year
when a kernel upgrade needed to be applied.

With the advent of the cloud and related technologies servers have
become much more dynamic and then the advantages of systemd become
much more obvious.

 systemd,
 for better or for worse, can't be the one magic bullet. Great or
 terrible as though it may be, I don't much like the total break in
 compatibility (correct me if I'm wrong).

total break in compatibility is a bit much, as the systemd
developers went to great lengths to make sure that init scripts
continue to work pretty much as you would hope them to under systemd.

 I'm not saying SysV is all that
 good, but there are other replacements, and new ones can be designed,
 but don't make it so that everyone-has-to-use-yours-or-else!

No one forced Debian to adopt systemd except Debian.  If Debian does
go through with the switch no one is forcing you to stick with Debian.

 I guess we have GNOME to thank for that...

Well, I guess the Gnome developers saw some value in systemd
integration that others don't.  There are other desktop environments
out there.

 And that's what troubles me the most:
 the lack of choice that seems to be creeping up, with everyone just
 ganging up and jumping to systemd like the floor is on fire. I'm with
 Jay Ashworth on this one: what gives??

Somehow I doubt that Lennart Poettering has the hypnotoad (ALL HAIL
THE HYPNOTOAD!) in his pocket.  I don't think that Lennart Poettering
is a billionaire and can afford to bribe everyone in charge of all of
the distributions (and I'm sure that most of them wouldn't take one
anyway).

Why do people keep assuming some sort of evil conspiracy on the part
of the systemd developers and refuse to believe that systemd is
becoming the default because the right people in the right places have
been convinced of systemd's technical benefits over sysvinit?

The reason that there's lack of choice is because the people that
don't want systemd haven't stepped up to do the work and create their
own distribution.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch


Israel G. Lugo wrote:

On 10/23/2014 12:05 AM, Jeffrey Ollie wrote:


systemd is a tool designed to get the system to a state where real
work can be done.  NTP servers, DHCP clients, consoles, aren't the
real work of a system, or at least I hope not, because that would be
boring to me.


Depends on the system.


Legitimate question, not trying to be sarcastic: would you concede that
the amount to which something is a detail may vary significantly per
the use case, and requirements? On my desktop I might not care about
whatever the DHCP client is doing, or the NTP server, but on a server
that may very well be a different story.


Re. NTP: Timekeeping is rather essential in lots of applications - like, 
for example, transit operations, where I currently spend my work life.  
An accurate, accessible central clock tends to be a rather important 
system component.  And we're talking concerns in the range of seconds.  
When you start getting into serious real-time systems (laboratory 
instrumentation, utility operations, warfighting, ) - yeah, NTP 
servers start getting really interesting, to a lot of people.


Miles Fidelman



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 8:35 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:

 Re. NTP: Timekeeping is rather essential in lots of applications - like, for
 example, transit operations, where I currently spend my work life.  An
 accurate, accessible central clock tends to be a rather important system
 component.  And we're talking concerns in the range of seconds.  When you
 start getting into serious real-time systems (laboratory instrumentation,
 utility operations, warfighting, ) - yeah, NTP servers start getting
 really interesting, to a lot of people.

As I've already said a couple of times, systemd does not force a
particular NTP implementation on you.  It comes with one (timedated),
and has a utility to manage it (timedatectl) but the admin can install
and use a different one if they like.

The only thing that has changed recently with respect to that is that
timedatectl can no longer be used to manage chronyd or ntpd.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch

Hey... how about not using selective editing to change the thread of 
discussion (see below)


Jeffrey Ollie wrote:

On Wed, Oct 22, 2014 at 8:35 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:

Re. NTP: Timekeeping is rather essential in lots of applications - like, for
example, transit operations, where I currently spend my work life.  An
accurate, accessible central clock tends to be a rather important system
component.  And we're talking concerns in the range of seconds.  When you
start getting into serious real-time systems (laboratory instrumentation,
utility operations, warfighting, ) - yeah, NTP servers start getting
really interesting, to a lot of people.

As I've already said a couple of times, systemd does not force a
particular NTP implementation on you.  It comes with one (timedated),
and has a utility to manage it (timedatectl) but the admin can install
and use a different one if they like.

The only thing that has changed recently with respect to that is that
timedatectl can no longer be used to manage chronyd or ntpd.



What you snipped out of the message was YOUR previous statement, to 
which I was responding:



systemd is a tool designed to get the system to a state where real
work can be done.  NTP servers, DHCP clients, consoles, aren't the
real work of a system, or at least I hope not, because that would be
boring to me. 


If you're going to simply keep repeating I like systemd, everything is 
copacetic - maybe you should take your fanboy attitude elsewhere, and 
let those of us concerned with operational impacts have a meaningful 
conversation here.  And maybe, you should check out some of the upstream 
bug reports re. systemd interactions with NTP.


Plonk.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux: concerns over systemd adoption and Debian's decision to switch

2014-10-22 Thread Valdis . Kletnieks

On Wed, 22 Oct 2014 20:45:01 -0500, Jeffrey Ollie said:

 As I've already said a couple of times, systemd does not force a
 particular NTP implementation on you.  It comes with one (timedated),
 and has a utility to manage it (timedatectl) but the admin can install
 and use a different one if they like.

Yeah, and if you want anything else to integrate in with systemd other than the
supplied SNTP, you can pretty much go pound sand, according to Marcel Holtmann:

So this means that you get a really good basis where clocks are synchronized.
If you want something better, you can install it. It is a waste of time trying
to integrate anything else than timesyncd since if you use anything else, you
will manually configure it and use its advanced options. If you do not need the
advanced features, then why install other NTP clients in the first place.

http://lists.freedesktop.org/archives/systemd-devel/2014-August/022572.html

You should read the whole thread at freedesktop - it's pretty obvious that
there's a really heavy bias towards we have a solution that's good for
desktops, and if you have a different use case, go pound sand.


pgpIUDLIyLsTr.pgp
Description: PGP signature

Re: Linux: concerns over systemd adoption and Debian's decision to switch

On Wed, Oct 22, 2014 at 9:08 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:
 Hey... how about not using selective editing to change the thread of
 discussion (see below)


 If you're going to simply keep repeating I like systemd, everything is
 copacetic - maybe you should take your fanboy attitude elsewhere, and let
 those of us concerned with operational impacts have a meaningful
 conversation here.

Sigh, this is *exactly* why I should have stayed out of this.  I
hadn't seen much in terms of meaningful conversation before I posted,
just a lot of hand-wringing about the doom about to happen.

The arguments against systemd that I've seen so far:

1) It's different so it's bad.
2) There's a lot of code, there must be some really bad security
problems just waiting to happen, so it's bad.
3) It doesn't do things the way we've always done them, so it's bad.
4) The systemd developers are jerks, so it's bad.

 And maybe, you should check out some of the upstream bug
 reports re. systemd interactions with NTP.

While I don't have infinite amounts of time to read every mailing list
thread or bug report, I have seen quite a few of them.

And I think that a lot of the time, people are forgetting that it's
difficult in email/textual communication to convey emotional subtlety
and that can easily cause problems.

 Plonk.

Have fun in your nice quiet world where no one disagrees with you.

-- 
Jeff Ollie

Re: Linux: concerns over systemd adoption and Debian's decision to switch