Re: Linux: concerns over systemd [OT]

[Jeffrey Ollie]

On Thu, Oct 23, 2014 at 12:28 AM, George Herbert
 wrote:
>
> Ok.  As a highly on- list-topic example of why distrust is called for...
>
> Without referring to the systemd source code*, does anyone know what systemd 
> uses to select between networking subsystems (i.e. NetworkManager, the new 
> standard as of RHEL 7, vs /etc/ sysconfig/network-scripts/, etc.).  
> NetworkManager is default but disableable and it magically falls back to 
> network-scripts dir, but the fallback is nearly undocumented and the 
> selection behavior appears completely undocumented.

systemctl status NetworkManager.service
systemctl status network.service

I don't think that there's anything magic about it, you have one or
the other enabled.  Adding NM_CONTROLLED=yes/no to
/etc/sysconfig/network-scripts/ifcfg-* gives you per-interface control
over whether NetworkManager or the network scripts are used for
managing the interface.  If neither is enabled you probably end up
with no networking.

> If by some chance you do know this, where did you come by that knowledge?  
> Hopefully with URLs.

I have access to systems that run systemd and I tried a couple of
things...  Also, I've been managing Red Hat systems for a long time
and have known about this for a while.  But a little bit of googling
and I found this:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-NetworkManager_and_the_Network_Scripts.html

Unless you're running systemd-networkd, this is really distro-specific
stuff as I expect that most distros will want to preserve some
backward compatibility with "legacy" network configuration.

-- 
Jeff Ollie

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

[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 [OT]

[joel jaeggli]

On 10/22/14 9:29 PM, Larry Sheldon wrote:
> On 10/22/2014 23:02, Jim Mercer wrote:
> 
>> if reducing boot time from 20 minutes down to 1 minute, in a server
>> environment,
>> is a serious issue for you, maybe you should be looking at why you
>> need to
>> reboot so often?
> 
> 
> That is the question I have been asking myself.
> 
> Back in the day we took it a a failure if a reboot happened.  (I
> remember discussions about needing to reboot to keep counters from
> overflowing.  I thought programming for counter wrap was a better idea.)

Back over here in router-land when the cat65k vss pair went down it's at
least 20 minutes before it's back. If you enjoy what may be the longest
minutes of your life try tripping over a bug that takes out two pairs
and a whole pop. Having something come back quickly is part of having
flexibility since things do go pear-shaped, and responding to outages
rather than not having them is not tick box we get to decline.

Today my Arista reloada in about 220 seconds which is tolerable but if
it were half that I'd be even happier.





signature.asc
Description: OpenPGP digital signature

Re: NTT high packet loss from US and BR to AU?

[Javier J]

Thank you Andree,

This confirms it wasn't just us. I am curious if anyone knows what the
issue was. I can't find anything on NTT website.

On Thu, Oct 23, 2014 at 1:25 AM, Andree Toonk  wrote:

> Yup seeing the same. Following examples all show same loss pattern
> between ~ 3:30 and ~ 4:30 UTC:
>
> syd ntt - nyc ntt
> syd ntt - mia ntt
> syd ntt - cdg ntt (paris)
> syd ntt - ams ntt
>
> One example:
> http://i.imgur.com/TmCkd1B.png?1
>
> Cheers,
>  Andree
>
>
>
> .-- My secret spy satellite informs me that at 2014-10-22 9:54 PM
> Javier J wrote:
> > So we have a nagios box in the environment in Sydney and everything is
> 100%
> > ok.
> >
> > new relic kept loosing connectivity to 30 plus servers on and off.
> >
> > Guys from California can ssh in, some cant.
> >
> > AWS reports everything operating as normal.
> >
> > Guys from other parts of the world can and can't load web pages.
> >
> > All servers show low usage (if you can ssh to them)
> >
> > It seems to be getting better now but still not right.
> >
> > This is from a box in AWS(sys) to level 3 dns server.
> >
> > --- 4.2.2.2 ping statistics ---
> > 70 packets transmitted, 68 received, 2% packet loss, time 69744ms
> > rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms
> > [root@Webapp javier]#
> >
> > Before it was 70% packet lost to that host. There is a mtr traceroute in
> a
> > previous email. Look for AU-US
> >
> >
> >
> > On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner <
> > strei...@cluebyfour.org> wrote:
> >
> >> Do you see any other indications of performance problems?
> >>
> >> jms
> >>
> >>
> >> On Thu, 23 Oct 2014, Javier J wrote:
> >>
> >>  Anyone else notice this?
> >>> Or is this an AWS issue in APAC that hasn't been reported yet?
> >>>
> >>> AU-NY(aws)
> >>> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%
> >>>
> >>> BR(aws)-AU(aws)
> >>> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%
> >>>
> >>>
> >>> NJ/NYC to AU(aws)
> >>> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4
> 13.3
> >>> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2
> >>> 9.0
> >>>
> >>>
> >
>

Re: Linux: concerns over systemd [OT]

[George Herbert]

Ok.  As a highly on- list-topic example of why distrust is called for...

Without referring to the systemd source code*, does anyone know what systemd 
uses to select between networking subsystems (i.e. NetworkManager, the new 
standard as of RHEL 7, vs /etc/ sysconfig/network-scripts/, etc.).  
NetworkManager is default but disableable and it magically falls back to 
network-scripts dir, but the fallback is nearly undocumented and the selection 
behavior appears completely undocumented.

If by some chance you do know this, where did you come by that knowledge?  
Hopefully with URLs.

(* don't bother telling me to read the source.  I'm reading...)

If I cannot find credible documentation of this, as networking person as well 
as enterprise sysadmin, this is a Problem.)


George William Herbert
Sent from my iPhone

Re: NTT high packet loss from US and BR to AU?

[Andree Toonk]

Yup seeing the same. Following examples all show same loss pattern
between ~ 3:30 and ~ 4:30 UTC:

syd ntt - nyc ntt
syd ntt - mia ntt
syd ntt - cdg ntt (paris)
syd ntt - ams ntt

One example:
http://i.imgur.com/TmCkd1B.png?1

Cheers,
 Andree



.-- My secret spy satellite informs me that at 2014-10-22 9:54 PM
Javier J wrote:
> So we have a nagios box in the environment in Sydney and everything is 100%
> ok.
> 
> new relic kept loosing connectivity to 30 plus servers on and off.
> 
> Guys from California can ssh in, some cant.
> 
> AWS reports everything operating as normal.
> 
> Guys from other parts of the world can and can't load web pages.
> 
> All servers show low usage (if you can ssh to them)
> 
> It seems to be getting better now but still not right.
> 
> This is from a box in AWS(sys) to level 3 dns server.
> 
> --- 4.2.2.2 ping statistics ---
> 70 packets transmitted, 68 received, 2% packet loss, time 69744ms
> rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms
> [root@Webapp javier]#
> 
> Before it was 70% packet lost to that host. There is a mtr traceroute in a
> previous email. Look for AU-US
> 
> 
> 
> On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner <
> strei...@cluebyfour.org> wrote:
> 
>> Do you see any other indications of performance problems?
>>
>> jms
>>
>>
>> On Thu, 23 Oct 2014, Javier J wrote:
>>
>>  Anyone else notice this?
>>> Or is this an AWS issue in APAC that hasn't been reported yet?
>>>
>>> AU-NY(aws)
>>> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%
>>>
>>> BR(aws)-AU(aws)
>>> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%
>>>
>>>
>>> NJ/NYC to AU(aws)
>>> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
>>> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2
>>> 9.0
>>>
>>>
> 

Re: Linux: concerns over systemd [OT]

[Simon Lyall]

On Wed, 22 Oct 2014, Larry Sheldon wrote:

That is the question I have been asking myself.

Back in the day we took it a a failure if a reboot happened.  (I remember 
discussions about needing to reboot to keep counters from overflowing.  I 
thought programming for counter wrap was a better idea.)


When I see a machine with a long uptime I ask myself:

1. When was the last kernel update? 
2. Do we know it would come back cleanly when it is rebooted?

3. What would happen to the site if that machine went offline?

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

Re: NTT high packet loss from US and BR to AU?

[Javier J]

So we have a nagios box in the environment in Sydney and everything is 100%
ok.

new relic kept loosing connectivity to 30 plus servers on and off.

Guys from California can ssh in, some cant.

AWS reports everything operating as normal.

Guys from other parts of the world can and can't load web pages.

All servers show low usage (if you can ssh to them)

It seems to be getting better now but still not right.

This is from a box in AWS(sys) to level 3 dns server.

--- 4.2.2.2 ping statistics ---
70 packets transmitted, 68 received, 2% packet loss, time 69744ms
rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms
[root@Webapp javier]#

Before it was 70% packet lost to that host. There is a mtr traceroute in a
previous email. Look for AU-US



On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner <
strei...@cluebyfour.org> wrote:

> Do you see any other indications of performance problems?
>
> jms
>
>
> On Thu, 23 Oct 2014, Javier J wrote:
>
>  Anyone else notice this?
>>
>> Or is this an AWS issue in APAC that hasn't been reported yet?
>>
>> AU-NY(aws)
>> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%
>>
>> BR(aws)-AU(aws)
>> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%
>>
>>
>> NJ/NYC to AU(aws)
>> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
>> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2
>> 9.0
>>
>>

Re: NTT high packet loss from US and BR to AU?

[Justin M. Streiner]

Do you see any other indications of performance problems?

jms

On Thu, 23 Oct 2014, Javier J wrote:


Anyone else notice this?

Or is this an AWS issue in APAC that hasn't been reported yet?

AU-NY(aws)
18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%

BR(aws)-AU(aws)
11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%


NJ/NYC to AU(aws)
9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0

Re: NTT high packet loss from US and BR to AU?

[Paul S.]

Does it actually persist to your destination?

Loss in transit paths is simply ICMP de-prioritization unless it's 
losing packets all the way to the last hop.


On 10/23/2014 午後 01:18, Javier J wrote:

Anyone else notice this?

Or is this an AWS issue in APAC that hasn't been reported yet?

AU-NY(aws)
18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%

BR(aws)-AU(aws)
11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%


NJ/NYC to AU(aws)
9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0

Re: NTT high packet loss from US and BR to AU?

[Javier J]

On Thu, Oct 23, 2014 at 12:34 AM, Javier J 
wrote:

> from Newark, NJ
>
> 1. pfsense.home 0.0%   295
>  0.2   0.1   0.1   0.7   0.0
>  2. l100.nwrknj-vfttp-134.verizon-gni.net0.0%   294
>  1.1   8.7   0.9 297.7  31.3
>  3. g0-14-4-1.nwrknj-lcr-21.verizon-gni.net  0.0%   294
>  1.9   4.1   1.6  21.2   2.0
>  4. ae3-0.nwrk-bb-rtr1.verizon-gni.net   0.0%   294
> 30.6  13.3   1.6 127.7  22.0
>  5. ???
>  6. 0.ae1.br3.nyc4.alter.net 0.0%   294
> 22.1   5.0   4.6  36.0   2.2
>  7. 204.255.169.234  0.0%   294
>  3.3   4.0   2.9 221.6  12.7
>  8. ae-2.r23.nycmny01.us.bb.gin.ntt.net  2.4%   294
>  8.9   7.0   3.4  33.8   6.2
>  9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 47.3%   294
>  9.6  16.7   9.2  35.8   6.5
> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net  0.0%   294
> 71.5  72.2  71.3  91.8   1.9
> 11. xe-0-0-0.r02.lsanca03.us.bb.gin.ntt.net  5.1%   294
> 68.5  69.4  68.0 106.7   4.8
> 12. as-1.r05.sydnau01.au.bb.gin.ntt.net 13.6%   294
>  292.2 289.8 280.8 313.7   3.5
> 13. xe-0-1-0.a06.sydnau01.au.ra.gin.ntt.net 11.2%   294
>  288.5 290.3 281.5 348.9   5.5
> 14. 202.68.70.10 9.5%   294
>  294.3 289.7 280.6 308.9   3.3
> 15. 54.240.192.89   10.6%   294
>  291.4 288.7 279.5 299.8   3.2
> 16. 54.240.192.113  10.9%   294
>  290.1 287.5 279.2 298.7   3.0
> 17. 54.240.192.171  11.9%   294
>  296.2 291.4 282.1 299.1   3.1
> 18. 54.240.192.160  11.3%   294
>  296.2 292.2 283.9 299.6   3.2
> 19. s3-website-ap-southeast-2.amazonaws.com 15.4%   294
>  292.1 291.6 281.9 299.0   3.0
>
> From AWS brazil.
>
>
>  Host
>  Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. ec2-177-71-128-6.sa-east-1.compute.amazonaws.com
>0.0%  13640.6   0.8   0.5  41.3   3.1
>  2. 177.72.240.152
>  0.0%  13640.9   1.2   0.7  50.6   3.6
>  3. 177.72.240.134
>  2.8%  13641.0   1.2   0.7  23.1   2.4
>  4. 2-2-0-0-IPV4-GRASAOTM1
>  0.0%  13641.5   0.9   0.6  34.3   2.7
>  5. 5.53.5.246
>  0.0%  13641.6   9.7   1.3 117.4  21.1
>  6. Xe2-0-2-0-grtmiana2.red.telefonica-wholesale.net
>0.0%  1364  117.4 119.5 117.1 134.5   3.5
> TE-0-5-0-3-GRTMIANA4.red.telefonica-wholesale.net
> Xe2-0-0-0-grtmiana2.red.telefonica-wholesale.net
>  7. Xe2-1-3-0-grtmiabr4.red.telefonica-wholesale.net
>0.0%  1364  119.4 127.9 119.0 304.6  22.1
> Te0-10-0-6-grtmiabr6.red.telefonica-wholesale.net
>  8. Xe0-0-0-0-grtpaopx2.red.telefonica-wholesale.net
>0.0%  1364  181.9 184.2 181.8 250.1   8.0
> Xe1-3-0-0-grtpaopx2.red.telefonica-wholesale.net
>  9. 213.140.53.178
>  0.0%  1364  182.8 182.5 181.9 185.8   0.7
> 10. ae-15.r01.snjsca04.us.bb.gin.ntt.net
>0.8%  1364  525.1 535.6 497.8 546.8   6.1
> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net
>  52.1%  1364  200.8 192.8 180.5 214.9   9.3
> 12. ae-7.r21.lsanca03.us.bb.gin.ntt.net
>   0.3%  1364  183.5 184.4 182.5 263.8   6.1
> 13. xe-0-0-0.r02.lsanca03.us.bb.gin.ntt.net
>   2.5%  1364  183.9 183.8 182.5 224.1   4.4
> 14. as-3.r05.sydnau01.au.bb.gin.ntt.net
>   3.2%  1364  546.5 544.3 520.7 642.3   8.0
> 15. xe-0-1-0.a06.sydnau01.au.ra.gin.ntt.net
>   1.7%  1364  538.6 542.2 514.5 653.1   8.3
> 16. 202.68.70.10
>  2.3%  1364  411.3 413.8 384.3 445.4   3.5
> 17. 54.240.192.93
>   2.5%  1364  406.3 411.9 387.9 420.2   2.7
> 18. 54.240.192.117
>  2.2%  1363  405.5 412.5 394.0 482.0   6.6
> 19. 54.240.192.193
>  2.8%  1363  406.7 410.6 396.2 420.2   2.4
> 20. s3-website-ap-southeast-2.amazonaws.com
>   2.6%  1363  407.6 410.5 397.2 415.7   2.4
>
>
> From an AWS instance in Sydney to 4.2.2.2
>
>  1. ip-10-5-69-193.ap-southeast-2.co  0.0%  15450.8   5.3   0.6 180.5
>  17.3
>  2. 100.68.201.6  0.0%  15450.5   0.4   0.3  44.0
>   1.4
>  3. 100.68.201.46 0.0%  15450.4   0.3   0.3  28.9
>   0.9
>  4. 100.67.186.7  0.0%  15450.4   0.3   0.3  38.9
>   1.2
>  5. 100.67.185.2420.0%  15451.2   0.8   0.6   2.7
>   0.3
>  6. 100.64.135.1770.0%  15450.8   0.8   0.7   3.0
>   0.3
>  7. 100.64.128.2400.0%  15451.0   0.8   0.6   2.6
>   0.3
>  8. 100.64.57.50  0.0%  15450.4   0.7   0.3 148.8
>   7.3
>  9. 100.64.24.133 0.0%  15441.1   0.9   0.7   3.6
>   0.4
> 10. ec2-54-252-0-16.ap-southeast-2.c  0.0%  15440.6   0.8   0.2  52.6
>   4.7
> 11. 54.240.192.1080.0%  15442.2   2.0   1.9   9.4
>   0.6
> 12. 54.240.192.78

Re: Linux: concerns over systemd [OT]

[Larry Sheldon]

On 10/22/2014 23:02, Jim Mercer wrote:


if reducing boot time from 20 minutes down to 1 minute, in a server environment,
is a serious issue for you, maybe you should be looking at why you need to
reboot so often?



That is the question I have been asking myself.

Back in the day we took it a a failure if a reboot happened.  (I 
remember discussions about needing to reboot to keep counters from 
overflowing.  I thought programming for counter wrap was a better idea.)


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

NTT high packet loss from US and BR to AU?

[Javier J]

Anyone else notice this?

Or is this an AWS issue in APAC that hasn't been reported yet?

AU-NY(aws)
18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%

BR(aws)-AU(aws)
11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%


NJ/NYC to AU(aws)
9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0

Re: Linux: concerns over systemd [OT]

[Jim Mercer]

On Wed, Oct 22, 2014 at 09:48:51PM -0500, Jimmy Hess wrote:
> Optimizing reboot time down from 20 minutes  to  1 minute is a
> significantly meaningful improvement;  it's literally a 85%  reduction
> in time spent during each boot process  from the original time.

if reducing boot time from 20 minutes down to 1 minute, in a server environment,
is a serious issue for you, maybe you should be looking at why you need to
reboot so often?

i'm somewhat puzzled by the fanboi mantra of "i've been running whizzy weasel
and have 1574 days of uptime", which has now been supplanted by "geez, i
have to wait 3 minutes every time i reboot this thing".

running ntp, dhcp, dns, smtp, imap, http, that's what we do in serverland.

and in addition to that, we need to run whatever the latest and greatest
piece of crap that's being touted on slashdot (redis, mongo, couchbase,
elasticsearch, anything that uses ruby/forever).

we generally don't have alot of say in what we have to run because the fanboi's
run the media, and management tends to give media more credence than the
decades of experience they have in-house.  that's how linux made it into the
server environment in the first place.

systemd sounds like a really useful thing if you are running a desktop system.

as far as booting up a server, to run services, and to keep those services
running, the init.d/rc.d/etc systems do a good job, and its generally not
that hard to add/modify if you are half-assed competent.

before criticizing people for being afraid of new technology, make sure that
you yourself are not afraid of existing technology.

--jim

-- 
Jim Mercer Reptilian Research  j...@reptiles.org+1 416 410-5633
"He who dies with the most toys is nonetheless dead"

Re: Linux: concerns over systemd [OT]

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 9:48 PM, Jimmy Hess  wrote:
> On Wed, Oct 22, 2014 at 1:31 PM, Barry Shein  wrote:
>> And you whisk all that away with "it's not really clear to me that
>> 'reboots in seconds' is a think to be optimized"
>
> False dilemma.
> [ snip ]
> 10 seconds from power on to user interface for desktops, will
> meaningfully improve the user experience,  but not for servers.

It's a false dilemma only if you're thinking about traditional
physical servers.  Consider:

1) What if you're spinning up several thousand Hadoop nodes on AWS or
GCE so that you can do some sort of "big data" operation.

2) What if PewDiePie just mentioned one of your products in a video
and you need to quickly scale up the number of backend servers to
handle the load.

I'm sure that there are many other scenarios that I could devise where
a fast "server" boot time was important.

-- 
Jeff Ollie

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

[Simon Lyall]

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

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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 9:18 PM,   wrote:
> 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".

Yes, I've read the thread, and I think "go pound sand" is an unfair
characterization of what *I* saw in that thread.

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, as far as I know no one else has done the work, and
I'm skeptical of the chances that such patches would get accepted
upstream.

So, if you want/need to run chronyd or ntpd you can, it'll "integrate"
into the system just like any other service would, and you'll be no
better/worse off than before timedated came into existence.

-- 
Jeff Ollie

Re: Linux: concerns over systemd [OT]

[Jimmy Hess]

On Wed, Oct 22, 2014 at 1:31 PM, Barry Shein  wrote:
[snip]
> The unix community has exerted great amounts of effort over the
> decades to speed up reboot, particularly after crashes but also
> planned. Perhaps you don't remember the days when an fsck was
> basically mandatory and could take 15-20 minutes on a large disk.
>
> Then we added the clean bit (disk unmounted cleanly, no need for
[snip]
> And you whisk all that away with "it's not really clear to me that
> 'reboots in seconds' is a think to be optimized"

False dilemma.
Optimizing reboot time down from 20 minutes  to  1 minute is a
significantly meaningful improvement;  it's literally a 85%  reduction
in time spent during each boot process  from the original time.

Reducing boot time from 20 minutes to  10 seconds is not significantly
better than reducing it to 1 minute.


A different choice of tradeoffs is more appropriate to different kinds
of systems, depending on their use case  (Desktop vs Server)!

Especially, when the method of reduction  is subject to diminishing
returns and increasing fragility or increasing complexity -- greater
risk that something is breaking or more potential for unreliability is
introduced into the startup process.

Also, you may very well spend more time booting your system in order
to troubleshoot,  the fact that some applications are starting up in
an unexpected order  resulting in some issue.

> To me that's like saying it's not important to try to design so one
> can recover from a network outage in seconds.

If you need to ensure that a service is not disrupted for more than
seconds,  then reboot is not the answer. It is some form of
clustering.

Reboot as a troubleshooting procedure is for desktops.
10 seconds from power on to user interface for desktops, will
meaningfully improve the user experience,  but not for servers.


For servers, you ideally want to take the misbehaving node out of
service and let its failover partner takeover.

-- 
-JH

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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 9:08 PM, Miles Fidelman
 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

[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: Self destruction in open source systems (was Re: Linux: concerns over systemd [OT])

[Miles Fidelman]

Joe Hamelin wrote:

On Wed, Oct 22, 2014 at 4:58 PM, Larry Sheldon  wrote:


Now I have Thunderbird and Firefox--from people who are committed to the
notion that if it works, it must be replaced.  If people like it, it must
be redesigned.  If it is stable, it must be updated.  If there is a
useless, senseless "feature" somewhere in the world, these products must be
revised to make that feature the focus.


And where is my new 1967 VW Microbus?  That's all you need if you compile
it with --add-heater-fan.  So I had to upgrade to a 1998 Volvo V70 wagon.
Don't know where I'm going to get a new one when this one wears out.


Well hey, nobody's made a good 4WD station wagon since Toyota stopped 
making them.  At one point it seemed like every 3rd person in the BBN 
parking lot had one, and we all drove them into the ground for lack of a 
replacement.


Sigh...



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

[Miles Fidelman]

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
 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: Self destruction in open source systems (was Re: Linux: concerns over systemd [OT])

[Joe Hamelin]

On Wed, Oct 22, 2014 at 4:58 PM, Larry Sheldon  wrote:

>
> Now I have Thunderbird and Firefox--from people who are committed to the
> notion that if it works, it must be replaced.  If people like it, it must
> be redesigned.  If it is stable, it must be updated.  If there is a
> useless, senseless "feature" somewhere in the world, these products must be
> revised to make that feature the focus.


And where is my new 1967 VW Microbus?  That's all you need if you compile
it with --add-heater-fan.  So I had to upgrade to a 1998 Volvo V70 wagon.
Don't know where I'm going to get a new one when this one wears out.

Damn kids, GET OFF MY LAWN!

I actually feel with your there, Larry.  I really like the *nixes because
of the great app store with things like ls, grep, sed, cc and ssh.  It's
also why for most things I still use one of the BSDs.  (Should we call
/usr/ports an app store now?)

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474


>

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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 8:35 PM, Miles Fidelman
 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

[Miles Fidelman]

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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 7:36 PM, Israel G. Lugo  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: Jared Mauch

[Abdulkadir Egal (aegal)]

Congratulations Jared.
Excellent work as always.

Regards

Abdul

On 10/21/14 8:29 PM, "Larry Sheldon"  wrote:

>I don't remember seeing mention of this here:
>
>https://www.youtube.com/watch?v=69-qhoS9sSw
>
>h/t Suresh Ramasubramian on Facebook.
>
>(I didn't copy and paste any names--hope I got them right.)
>-- 
>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

[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 ;)

Self destruction in open source systems (was Re: Linux: concerns over systemd [OT])

[Larry Sheldon]

On 10/22/2014 06:01, Randy Bush wrote:

Which leads me to ask - those of you running server farms - what
distros are popular these days, for server-side operations?

been running bsd forever.  but moving to debian and ganeti, as bsd
does not host virtualization.

Simply not true; http://bhyve.org/
It is a bit immature compared to Xen+Ganeti or something like that.


apologies.  i thought we were talking about production systems.  my
mistake.


This may take us far enough away from BGP and prefix lengths to draw 
moderator fire, but it is a topic I would like to pursue somewhere.


What is it about seems to mandate that they develop a fatal rot from the 
inside out?


I don't have anything to add to the xX OSes (they Were Not Allowed 
when I was an active admin), but I have of late been grappling with what 
to do about replacing Firefox and Thunderbird in the four machines I 
have left in my world.


Early on I developed a fondness for Mosaic as a simple get-the-job done 
tool to add to elm and news to get the work done.


Netscape did a nice integration and I went with that until it went away.

Now I have Thunderbird and Firefox--from people who are committed to the 
notion that if it works, it must be replaced.  If people like it, it 
must be redesigned.  If it is stable, it must be updated.  If there is a 
useless, senseless "feature" somewhere in the world, these products must 
be revised to make that feature the focus.

--
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 [OT]

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 4:48 PM,   wrote:
> Bah, boot speed;
>
> On my server, boot is slow down by hardware initialization.
> The soft side is quite low.
>
> But the point is not "makes things faster from 15 to 14 sec is useless".
> The point is : it's good, but at what price ?

I agree that "boot speed" is a red herring.  Booting in a highly
dynamic environment is really one of systemd's key achievements.
True, this is most apparent in systems like laptops that can be
docked/undocked, tend to have a lot of USB devices added/removed, etc.
But servers have these same issues, if only in lesser degree.

sysvinit generally had to wait for a fixed interval for all hardware
to finish initializing.  It was a little more sophisticated than one
init script having a "sleep X" command in it, but not much.

systemd is able to start services as soon as all of the hardware it
needs is ready, rather than waiting arbitrary amounts of time and then
possibly failing anyway because it didn't wait long enough.

One main example of this is a large RAID array or LVM volume that's
used for data storage (not the OS).  systemd can let parts of the
system boot that don't require the data storage to be present start up
while waiting for all of the data storage drives to spin up and get
assembled.

> As you said, there were many improvements over the past.
> What was the "clean bit" cost ? None but benefits, right ?
> What about fs logs ? Does it have a cost ?
>
> If systemd is just about time, it will be fine.
> But why trying to recreate (ans thus, squeeze) some old daemons like
> cron or syslog ? Both of them are doing a perfect job.

Syslog didn't capture the stdout/stderr from daemon start up.  Syslog
did only a mediocre job of capturing dmesg from early boot.  If you
have access to a system running systemd/journald run "journalctl -k
-b".  That'll show you all of the kernel messages since the last boot.
At least on the RHEL systems that I have access to, /var/log/dmesg
doesn't timestamp the lines in the file, making it difficult to
impossible to correlate with other log lines.  The kernel messages in
/var/log/messages are timestamped with the time that rsyslog was able
to (finally) start and pull the messages out of the kernel message
buffer.

> Can I use systemd without any of journald stuff ?

I wouldn't want to.

> If not, then the 1sec speedup is far too expensive.

The boot speed up is a nice benefit, but not the only (or even the
best) reason to use systemd.

-- 
Jeff Ollie

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

[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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 4:43 PM, 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.

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 K&P 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 K&P 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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 3:49 PM, Miles Fidelman
 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.  I
mean really, what could go wrong when we configure boot-up with a
Turing complete language?  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

[Miles Fidelman]

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 [OT]

[nanog]

Bah, boot speed;

On my server, boot is slow down by hardware initialization.
The soft side is quite low.

But the point is not "makes things faster from 15 to 14 sec is useless".
The point is : it's good, but at what price ?

As you said, there were many improvements over the past.
What was the "clean bit" cost ? None but benefits, right ?
What about fs logs ? Does it have a cost ?

If systemd is just about time, it will be fine.
But why trying to recreate (ans thus, squeeze) some old daemons like
cron or syslog ? Both of them are doing a perfect job.

Can I use systemd without any of journald stuff ?
If not, then the 1sec speedup is far too expensive.


On 22/10/2014 20:31, Barry Shein wrote:
> 
> On October 21, 2014 at 16:43 morrowc.li...@gmail.com (Christopher Morrow) 
> wrote:
>  > On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan  wrote:
>  > > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote:
>  > >> But
>  > >> for example some of my servers boot in seconds.
>  > >
>  > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS
>  > > Handbook_, available at
>  > 
>  > it's really not clear to me that 'reboots in seconds' is a thing to 
> optimize...
> 
> The unix community has exerted great amounts of effort over the
> decades to speed up reboot, particularly after crashes but also
> planned. Perhaps you don't remember the days when an fsck was
> basically mandatory and could take 15-20 minutes on a large disk.
> 
> Then we added the clean bit (disk unmounted cleanly, no need for
> fsck), reorg'd the file system layout to speed up fsck considerably
> and make it more reliable/recoverable, added journaled file systems
> which really sped things up often eliminating the need to fsck after a
> crash entirely and recovering in seconds, various attempts to figure
> out the dependency graph of servers and services which need to be
> started so they could be started in parallel where dependencies are
> met, etc.
> 
> And learned how to do hot failover and master/slave servers etc.
> 
> And you whisk all that away with "it's not really clear to me that
> 'reboots in seconds' is a think to be optimized"
> 
> To me that's like saying it's not important to try to design so one
> can recover from a network outage in seconds.
> 
> Anyhow, if it's not clear: I disagree.
> 
>  > 
>  > I suppose the win is:
>  >   "Is the startup/shutdown process clear, conscise and understandable
>  > at 3am local time?"
>  > 
>  > followed by:
>  >   "Can I adjust my startup processes to meet my needs easily and
>  > without finding a phd in unix?"
>  > 
>  > If systemd is simply a change in how I think about /etc/init.d/* and
>  > /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility
>  > then it's a fail.
> 
> Actually, much of that is less important except perhaps to a hobbyist.
> 
> You only have to get the startup/shutdown process etc right once in a
> while and generally during a planned outage.
> 
> Recovering from a failure or going back into service quickly after a
> planned outage is critical and can be critical at any time.
> 
> Obviously one can appeal to extremum but what you say doesn't make
> sense to me. At any rate, you are disputing a huge, decades long, and
> widely fought battle. It's certainly not my opinion.
> 
> 

Re: Linux: concerns over systemd [OT]

[Gary Buhrmaster]

On Wed, Oct 22, 2014 at 9:17 PM, Jeffrey Ollie  wrote:

> I think that Debian's plan to allow multiple init systems
> (irregardless of which one is default) is a bad plan.  The non-default
> ones won't get any love - at some point they'll just stop working (or
> indeed, work at all).

Indeed.  I believe that point was made during the
debian technical committee discussions by one
of the members of the TC (Russ, I think, although
it was such a long discussion it could have been
one of the other participants).

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

[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

[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 [OT]

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 3:48 PM,   wrote:
> On Wed, 22 Oct 2014 19:35:51 -, David Ford said:
>
>> into a common bus. not everything in systemd is a requirement to run it.
>> just because a unit is offered for dhcp or ntp, doesn't mean you are
>> required to use it.
>
> Actually, systemd 216 will cram systemd-timesyncd down your throat even
> if you had ntpd installed.

Oh really?  From my Fedora 21 (alpha) system at work:

# rpm -q systemd
systemd-216-5.fc21.x86_64
# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; disabled)
   Active: inactive (dead)
 Docs: man:systemd-timesyncd.service(8)
# systemctl status ntpd.service
● ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled)
   Active: active (running) since Thu 2014-10-16 16:06:22 CDT; 6 days ago
 Main PID: 1438 (ntpd)
   CGroup: /system.slice/ntpd.service
   └─1438 /usr/sbin/ntpd -u ntp:ntp -g

I'm not sure what NTP service is installed by default in Fedora 21+
(which will ship with systemd 216), as this system has been upgraded
from previous Fedora versions, but as you can see it's perfectly
possible to run ntpd on a system that used systemd 216.

> https://bugzilla.redhat.com/show_bug.cgi?id=1136905
> https://mail.gnome.org/archives/distributor-list/2014-September/msg2.html
>
> Lennart's attitude was pretty much "why would anybody want to run ntpd
> when they have our SNTP implementation":

A vast oversimplification of Lennart's point.  Basically you left off
"if you really want to run chronyd or ntpd service go right ahead,
we're just not going to have code in systemd to do that for you".

> http://lists.freedesktop.org/archives/systemd-devel/2014-August/022537.html
>
> There's been similar issues with their dhcp.

The "bug" here is really timedatectl (a component of systemd) isn't
going to manage chronyd or ntpd (third party packages), and that made
a Gnome control panel (which used timedatectl under the hood) report
that network time synchronization wasn't enabled.

If you don't want timedated then it's perfectly possible to disable
timedated and use something else.  If someone cares enough, I'm sure
that the Gnome control panel will get updated so that I can manage
chronyd or ntpd itself.

-- 
Jeff Ollie

Re: Linux: concerns over systemd [OT]

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 3:34 PM, Randy Bush  wrote:
>> the vast majority of negative tongue wagging regarding systemd is ill
>> informed.
>
> can we skip the ad homina and leave that for the systemd dev fora?

I don't think that it's an ad homina attack, as it's pretty clear that
many of the people commenting have not spent a significant time using
systemd so many of their comments are based on what they've read on
the Internet, not from practical experience with systemd.

>> does systemd have growing pains? definitely. are some egos involved?
>> sure. can systemd be far reaching? yes, is such reach mandated?
>> no. use the units you want and disregard the rest.
>
> how does this work out in practice?  at install, can i choose whether
> systemd is used for X as opposed for the separate component?  can i
> template such choices for cluster deployment with the usual tools?

I think that Debian's plan to allow multiple init systems
(irregardless of which one is default) is a bad plan.  The non-default
ones won't get any love - at some point they'll just stop working (or
indeed, work at all).

Allowing choice of components is a good thing at one level (e.g.
sendmail vs. postfix vs. exim).  I really don't care (and don't really
even remeber) which SMTP server is installed by default on my systems
because my configuration management system makes sure that the SMTP
server that I prefer is installed and configured the way I want it
once the system is up and running.

For something like PID 1, each distribution should make a choice and
stick with it.  I really couldn't care what Debian's init system is,
as I don't use Debian (never have, at least not when I have had a
choice).  If Debian goes through with the switch to systemd, they
won't gain me as a user as there are a host of other reasons that I
prefer something other than Debian (or Debian-derived) distributions.

If a group of people fork Debian because of systemd, more power to them.

-- 
Jeff Ollie

Re: Linux: concerns over systemd [OT]

[Chris Adams]

Once upon a time, valdis.kletni...@vt.edu  said:
> Actually, systemd 216 will cram systemd-timesyncd down your throat even
> if you had ntpd installed.

Yeah, I think a lot of the upset with systemd is not so much with the
core daemon that runs as PID 1, but with the massive scope creep that
the systemd project appears to have.  Why should a project centered
around an init system start reimplementing system logging, network
management (and a DHCP client), clock management, etc.?

> Lennart's attitude was pretty much "why would anybody want to run ntpd
> when they have our SNTP implementation":

Wow, maybe because SNTP is inferior to an actual NTP daemon in just
about every way?
-- 
Chris Adams 

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

[Miles Fidelman]

Jeffrey Ollie wrote:

On Wed, Oct 22, 2014 at 3:22 PM, John Schiel  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 [OT]

[Valdis . Kletnieks]

On Wed, 22 Oct 2014 19:35:51 -, David Ford said:

> into a common bus. not everything in systemd is a requirement to run it.
> just because a unit is offered for dhcp or ntp, doesn't mean you are
> required to use it.

Actually, systemd 216 will cram systemd-timesyncd down your throat even
if you had ntpd installed.

https://bugzilla.redhat.com/show_bug.cgi?id=1136905
https://mail.gnome.org/archives/distributor-list/2014-September/msg2.html

Lennart's attitude was pretty much "why would anybody want to run ntpd
when they have our SNTP implementation":

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

There's been similar issues with their dhcp.


pgpRjcjiVttxV.pgp
Description: PGP signature

Re: Linux: concerns over systemd [OT]

[Miles Fidelman]

Randy Bush wrote:

the vast majority of negative tongue wagging regarding systemd is ill
informed.

can we skip the ad homina and leave that for the systemd dev fora?


does systemd have growing pains? definitely. are some egos involved?
sure. can systemd be far reaching? yes, is such reach mandated?
no. use the units you want and disregard the rest.

how does this work out in practice?  at install, can i choose whether
systemd is used for X as opposed for the separate component?  can i
template such choices for cluster deployment with the usual tools?


Right now, the problem is that the installer does not give a choice, and 
the preseed function has a bug such that you can't do a systemvinit 
install directly at install time; rather you have to let the default 
install complete, then replace systemd with sysvinit-core - and there 
seem to be cases of dropping into dependency hell when doing so (reports 
vary).


Longer term, the above-mentioned bug will (hopefully) be patched (the 
patch is there, but not well tested, and has not yet been included into 
the installer).  Then we get into the question of to what extent 
upstream packages start depending on systemd.


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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 3:22 PM, John Schiel  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 [OT]

[Randy Bush]

> the vast majority of negative tongue wagging regarding systemd is ill
> informed. 

can we skip the ad homina and leave that for the systemd dev fora?

> does systemd have growing pains? definitely. are some egos involved?
> sure. can systemd be far reaching? yes, is such reach mandated?
> no. use the units you want and disregard the rest.

how does this work out in practice?  at install, can i choose whether
systemd is used for X as opposed for the separate component?  can i
template such choices for cluster deployment with the usual tools?

as barry said, we get to drive this car.

randy

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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 2:30 PM,   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
"  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 2>&1 > /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

[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 [OT]

[C. Jon Larsen]

Which leads me to ask - those of you running server farms - what
distros are popular these days, for server-side operations?  We've
been running Debian like forever (by way of Solaris and redhat) - but
this systemd thing is making me rethink things.  Seems like an awful
lot of folks are now designing for the desktop, and it might be time
to migrate to a BSD or Solaris derivative.  What are others doing?


to be honest, i like systemd. nobody else has really stepped up to the
bat to fix issues of existing init systems and tying interoperabilty
into a common bus.


Perhaps because folks that understand more about security than you (and 
me for sure so I'm not picking on you) think thats a bad idea? If 
something is a bad idea then smart folks dont rush out (generally) to 
build it ... thus the no one stepping up to bat "problem" thats not really 
a problem - its a good thing to not have problems solved improperly.


Perhaps because when you say/hear things like "tying interoperabilty into 
a common bus" you think thats a good idea. Others hear those same words and think:


vendor lock-in
single point of failure
lack of choice

The binary logging thing is a non-starter for a lot of folks. dbus ? On a 
server ? Do we really need that ?


Lets keep servers reliable - less code not more (no bugs in unwritten 
code).


Shouldnt the amount of code running as PID 1 be kept to an absolute 
minimum?


Bad architecture decisions dont suddenly become good ones even if they 
solve other problems along the way or make some things better or faster.

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

[Barry Shein]

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 [OT]

[Miles Fidelman]

David Ford wrote:

Which leads me to ask - those of you running server farms - what
distros are popular these days, for server-side operations?  We've
been running Debian like forever (by way of Solaris and redhat) - but
this systemd thing is making me rethink things.  Seems like an awful
lot of folks are now designing for the desktop, and it might be time
to migrate to a BSD or Solaris derivative.  What are others doing?





before making ill informed rash decisions, study what you're talking
about and then decide whether or not you like and can/can't use said
subject.


Is that not the point of discussions like this one?


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

[Barry Shein]

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

[Barry Shein]

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 [OT]

[Randy Bush]

Barry Schein:
> I'm reminded of the remark often attributed to DEC CEO Ken Olson,
> roughly:
> 
>   With VMS (their big complex OS) it might take hours searching
>   through manuals to find a feature you need while with Unix you can
>   determine in seconds that it is not available.

and how did that work out for vms?  and digital?

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.  There's no way to
> argue rationally with that.

and with this ad homina you dismiss all technical, architectural, and
security concerns.  much from folk who have been administering unix
systems since you were in nappies.  and you advocate rational argument?

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.

i am a long time bsd user and deployer.  amelioration of shellshock,
heartbleed, and poodle on an annoying number of servers was not any
better on freebsd than debian.

randy

Re: Linux: concerns over systemd [OT]

[Barry Shein]

On October 22, 2014 at 12:00 md1...@md1clv.com (Daniel Ankers) wrote:
 > On 22 October 2014 11:34,  wrote:
 > 
 > > Before leaving Debian, things to think:
 > > - will systemd be officialy the only system available ?
 > > - if so, won't we get a way to bypass that ?
 > >
 > 
 > And one other thought... is it really that bad?
 > 
 > Personally I like it a lot better than sysV plus inittab plus daemontools.

I posted my complaints but I think they fall more in the realm of lack
of maturity than bad design.

I believe systemd is superior to sysvinit but it will take time for it
to mature, administrative tools to become available (even if just
better logging/tracing), and for us to get used to it and acquire the
folk knowledge we need.

Until then frustration will arise from time to time.

-- 
-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 [OT]

[David Ford]

> Which leads me to ask - those of you running server farms - what
> distros are popular these days, for server-side operations?  We've
> been running Debian like forever (by way of Solaris and redhat) - but
> this systemd thing is making me rethink things.  Seems like an awful
> lot of folks are now designing for the desktop, and it might be time
> to migrate to a BSD or Solaris derivative.  What are others doing?

to be honest, i like systemd. nobody else has really stepped up to the
bat to fix issues of existing init systems and tying interoperabilty
into a common bus. not everything in systemd is a requirement to run it.
just because a unit is offered for dhcp or ntp, doesn't mean you are
required to use it.

the vast majority of negative tongue wagging regarding systemd is ill
informed. does systemd have growing pains? definitely. are some egos
involved? sure. can systemd be far reaching? yes, is such reach
mandated? no. use the units you want and disregard the rest.

i run Arch Linux in my farms and except for the advanced networking
functions and ease of locally tailoring Gentoo offered, I love Arch more
than any of my .rpm or .deb flavors, *bsd or *nix, and i have used
pretty much all of them. i've run unix like systems since 1988 and cover
the gammut of code writing from bash scripts to kernel modules to apache
and postgres on everything from microcontrollers to mainframes.

before making ill informed rash decisions, study what you're talking
about and then decide whether or not you like and can/can't use said
subject.

-d




signature.asc
Description: OpenPGP digital signature

Re: Why is .gov only for US government agencies?

[Barry Shein]

On October 22, 2014 at 01:25 i...@itechgeek.com (ITechGeek) wrote:
 > Instead of multiple govs trying to use .gov or .mil, the best idea would be
 > to collapse .gov under .gov.us and .mil under .mil.us (Much like how other
 > countries already work).

And of course they'll also keep .GOV and .MIL because it's too much
trouble to do whatever it'd take to actually decomission them so not
much would be accomplished.

I'm not opposed to the idea, sure, why not, but I'm pessimstic that
it'd accomplish much in our lifetimes (depending on your age of
course.)

 > I don't see that happening as long as the US gov has a say in the matter.
 > I think .su will be decommissioned long before .gov or .mil are.

We agree.

  Never attribute to megalomania that which can be adequately
  explained by inertia.

-- 
-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 [OT]

[Ricky Beam]

On Wed, 22 Oct 2014 14:31:02 -0400, Barry Shein  wrote:

Perhaps you don't remember the days when an fsck was
basically mandatory and could take 15-20 minutes on a large disk.


Journaling has all but done away with fsck. You'd have to go *way* back to  
have systems that ran a full fsck on every boot -- and in my experience,  
you absolutely wanted that fsck.


I've used xfs for over a decade. It doesn't even have an fsck (xfs_check  
and xfs_repair, yes, but NO system will ever call them. And as a rule,  
never needs to.)



And you whisk all that away with "it's not really clear to me that
'reboots in seconds' is a think to be optimized"


You're arguing the difference between optimizing a 15min boot into a 5min  
boot, vs a 15sec "boot" into a 14sec "boot". The former is an actual  
optimization allowing subsystems to start in parallel, in ways that do not  
introduce delay. (eg. sendmail startup, used to be the #1 slow down on  
solaris) The latter is pure nonsense, with "boot" being measured as when  
login pops up -- which is NOT when all the subsystems have actually  
completely started.



To me that's like saying it's not important to try to design so one
can recover from a network outage in seconds.


Your efforts are better spent avoiding an outage in the first place. If  
outages are common enough to be something that needs to be "sped up", then  
you've already failed.

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

[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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 2:13 PM, John Schiel  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

[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

[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

[Barry Shein]

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 [OT]

[Barry Shein]

On October 21, 2014 at 16:43 morrowc.li...@gmail.com (Christopher Morrow) wrote:
 > On Tue, Oct 21, 2014 at 4:10 PM, Andrew Sullivan  wrote:
 > > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote:
 > >> But
 > >> for example some of my servers boot in seconds.
 > >
 > > One is reminded of a mail, included in the Preface to _The UNIX-HATERS
 > > Handbook_, available at
 > 
 > it's really not clear to me that 'reboots in seconds' is a thing to 
 > optimize...

The unix community has exerted great amounts of effort over the
decades to speed up reboot, particularly after crashes but also
planned. Perhaps you don't remember the days when an fsck was
basically mandatory and could take 15-20 minutes on a large disk.

Then we added the clean bit (disk unmounted cleanly, no need for
fsck), reorg'd the file system layout to speed up fsck considerably
and make it more reliable/recoverable, added journaled file systems
which really sped things up often eliminating the need to fsck after a
crash entirely and recovering in seconds, various attempts to figure
out the dependency graph of servers and services which need to be
started so they could be started in parallel where dependencies are
met, etc.

And learned how to do hot failover and master/slave servers etc.

And you whisk all that away with "it's not really clear to me that
'reboots in seconds' is a think to be optimized"

To me that's like saying it's not important to try to design so one
can recover from a network outage in seconds.

Anyhow, if it's not clear: I disagree.

 > 
 > I suppose the win is:
 >   "Is the startup/shutdown process clear, conscise and understandable
 > at 3am local time?"
 > 
 > followed by:
 >   "Can I adjust my startup processes to meet my needs easily and
 > without finding a phd in unix?"
 > 
 > If systemd is simply a change in how I think about /etc/init.d/* and
 > /etc/rc?.d/* cool, if it's more complexity and less EASY flexibility
 > then it's a fail.

Actually, much of that is less important except perhaps to a hobbyist.

You only have to get the startup/shutdown process etc right once in a
while and generally during a planned outage.

Recovering from a failure or going back into service quickly after a
planned outage is critical and can be critical at any time.

Obviously one can appeal to extremum but what you say doesn't make
sense to me. At any rate, you are disputing a huge, decades long, and
widely fought battle. It's certainly not my opinion.


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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 12:35 PM, George Herbert
 wrote:
>
>
>
>
>> On Oct 22, 2014, at 9:30 AM, 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.  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 [OT]

[Barry Shein]

I'm reminded of the remark often attributed to DEC CEO Ken Olson,
roughly:

  With VMS (their big complex OS) it might take hours searching
  through manuals to find a feature you need while with Unix you can
  determine in seconds that it is not available.


On October 21, 2014 at 16:10 asulli...@dyn.com (Andrew Sullivan) wrote:
 > On Tue, Oct 21, 2014 at 03:11:55PM -0400, Barry Shein wrote:
 > > But
 > > for example some of my servers boot in seconds.
 > 
 > One is reminded of a mail, included in the Preface to _The UNIX-HATERS
 > Handbook_, available at
 > http://www.art.net/~hopkins/Don/unix-haters/preface.html.  Apparently,
 > things really are going to get a lot worse before they get worse.
 > 
 > Best regards,
 > 
 > A
 > 
 > -- 
 > Andrew Sullivan
 > Dyn, Inc.
 > asulli...@dyn.com
 > v: +1 603 663 0448

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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 11: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

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

[Daniel Corbe]

Andrew Sullivan  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

[George Herbert]

> On Oct 22, 2014, at 9:30 AM, 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.  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

[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

[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

[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

[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

[Jeffrey Ollie]

On Wed, Oct 22, 2014 at 11:12 AM, Miles Fidelman
 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

[Miles Fidelman]

Jeffrey Ollie wrote:

On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo  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

[Jeffrey Ollie]

On Mon, Oct 20, 2014 at 7:48 PM, Israel G. Lugo  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

[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 [OT]

[Miles Fidelman]

na...@jack.fr.eu.org wrote:

Before leaving Debian, things to think:
- will systemd be officialy the only system available ?
- if so, won't we get a way to bypass that ?


officially, there will be support for multiple init systems; in 
practice, the installer doesn't provide an option, and trying to remove 
systemd seems to drag one into dependency hell




I'm not gonna throw Debian away due to such a mess, without fighting
hard, and I think you should do the same: talk, patch if needed, show
you're here


unfortunately, the fight is rather ugly, and seemingly fruitless (have 
you been on debian-user, debian-devel, or debian-vote lately?) - sigh... 
this discussion, if a bit OT for nanog, is a breath of fresh air - 
PLEASE weigh in on the side of goodness and light


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

[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 [OT]

[Valdis . Kletnieks]

On Wed, 22 Oct 2014 12:34:17 +0200, na...@jack.fr.eu.org said:
> Before leaving Debian, things to think:
> - will systemd be officialy the only system available ?
> - if so, won't we get a way to bypass that ?

Somebody already forked systemd at a point before it completely
lost the plot.

http://uselessd.darknedgy.net/


pgpdhmr9dzrU5.pgp
Description: PGP signature

Re: Linux: concerns over systemd [OT]

[Jimmy Hess]

On Wed, Oct 22, 2014 at 6:12 AM, Joe Greco  wrote:
> when so much effort has been put into that very issue, specifically so
> that we could gain the advantages of a BSD hypervisor that supported
> ZFS natively...
[snip]

If you want native ZFS support,  then Solaris x86-64+Zones+KVM  or
SmartOS.  Now  Solaris/Illumos'  process supervision and fault
management systems,  SMF and FMA are pretty complex,   but  they
aren't stuffing 1000 random tasks  into the init program.   ^_^


>
> ... JG

--
-JH

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

[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: Jared Mauch

[Robert Webb]

Congrats Jared!!!

On Tue, 21 Oct 2014 22:29:33 -0500
 Larry Sheldon  wrote:

I don't remember seeing mention of this here:

https://www.youtube.com/watch?v=69-qhoS9sSw

h/t Suresh Ramasubramian on Facebook.

(I didn't copy and paste any names--hope I got them right.)
--
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 [OT]

[nanog]

When it's working, no doupt, I'll be fine
I don't care (or just a few) about when it's working.
The point is: what about it's failure ?

On the ethical point of view, systemd is killed anyway

On 22/10/2014 13:00, Daniel Ankers wrote:
> On 22 October 2014 11:34,  > wrote:
> 
> Before leaving Debian, things to think:
> - will systemd be officialy the only system available ?
> - if so, won't we get a way to bypass that ?
> 
> 
> And one other thought... is it really that bad?
> 
> Personally I like it a lot better than sysV plus inittab plus daemontools.
> 
> Dan 

Re: Linux: concerns over systemd [OT]

[Matt Palmer]

On Wed, Oct 22, 2014 at 12:00:52PM +0100, Daniel Ankers wrote:
> On 22 October 2014 11:34,  wrote:
> > Before leaving Debian, things to think:
> > - will systemd be officialy the only system available ?
> > - if so, won't we get a way to bypass that ?
> 
> And one other thought... is it really that bad?
> 
> Personally I like it a lot better than sysV plus inittab plus daemontools.

When it was init+daemontools, I could hold my nose over the binary logging
and consider using it.  Now it's taking over cron and all manner of other
things, there's no way in hell I'm letting it onto my systems.

As to the issue of "will it only be systemd", the problem is that as the
officially-blessed option, that's the one that'll get the universal support,
so if you want to run something else, some things will mysteriously not
work, and package maintainers won't care nearly as much.

Bypassing systemd is a whole hell of a lot harder than switching out
sysvinit for something else, because systemd does so many things, and many
other things are being modified to absolutely depend on things that only
systemd provides -- GNOME's the big one, but docker is closely tied to
systemd too, I believe, I think udev needs systemd now (or has it been
incorporated into systemd?  I can't keep all this straight) and I'm pretty
sure I've heard of other things deprecating non-systemd ways of doing
things.

The *really* damaging part of it, though, is that as systemd grows
to overshadow the things it re-implements (udev, dbus, etc) it starves the
alternatives of light and they quickly fall behind and are no longer viable
as ways to avoid systemd.  That isn't systemd's fault, per se, but it does
make it much harder over time to avoid getting caught in the gaping maw.

- Matt

Re: Linux: concerns over systemd [OT]

[Joe Greco]

> >>> Which leads me to ask - those of you running server farms - what
> >>> distros are popular these days, for server-side operations?
> >> been running bsd forever.  but moving to debian and ganeti, as bsd
> >> does not host virtualization.
> > Simply not true; http://bhyve.org/
> > It is a bit immature compared to Xen+Ganeti or something like that.
> 
> apologies.  i thought we were talking about production systems.  my
> mistake.

Oh, c'mon Randy, you've been around long enough to know how this all
works.

You can't honestly tell me that VMware ESX was born handling production
loads.  You can't honestly tell me that Xen was born handling production
loads.  All hypervisor technologies were new at one point in their life
cycle, and most were also catastrofails at one point in their life cycle.
The fact that bhyve is new means it's more immature, but people are
certainly trying noncricitical production loads on it.  Y'know, the same
way they did years ago with ESX.

No one's saying you have to trust it with your production workloads, but
it's pretty unfair to characterize BSD as "not host(ing) virtualization"
when so much effort has been put into that very issue, specifically so
that we could gain the advantages of a BSD hypervisor that supported 
ZFS natively...

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

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

[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 [OT]

[Randy Bush]

>>> Which leads me to ask - those of you running server farms - what
>>> distros are popular these days, for server-side operations?
>> been running bsd forever.  but moving to debian and ganeti, as bsd
>> does not host virtualization.
> Simply not true; http://bhyve.org/
> It is a bit immature compared to Xen+Ganeti or something like that.

apologies.  i thought we were talking about production systems.  my
mistake.

randy

Re: Linux: concerns over systemd [OT]

[Daniel Ankers]

On 22 October 2014 11:34,  wrote:

> Before leaving Debian, things to think:
> - will systemd be officialy the only system available ?
> - if so, won't we get a way to bypass that ?
>

And one other thought... is it really that bad?

Personally I like it a lot better than sysV plus inittab plus daemontools.

Dan

Re: Linux: concerns over systemd [OT]

[Joe Greco]

> > Which leads me to ask - those of you running server farms - what
> > distros are popular these days, for server-side operations?
> 
> been running bsd forever.  but moving to debian and ganeti, as bsd does
> not host virtualization.  

Simply not true; http://bhyve.org/

It is a bit immature compared to Xen+Ganeti or something like that.

> would love it if debian ditched this systemd
> monstrosity and provided solid zfs.


... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

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

[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 [OT]

[Randy Bush]

> Which leads me to ask - those of you running server farms - what
> distros are popular these days, for server-side operations?

been running bsd forever.  but moving to debian and ganeti, as bsd does
not host virtualization.  would love it if debian ditched this systemd
monstrosity and provided solid zfs.

randy

Re: Linux: concerns over systemd [OT]

[Elmar K. Bins]

na...@jack.fr.eu.org (na...@jack.fr.eu.org) wrote:

> I'm not gonna throw Debian away due to such a mess, without fighting
> hard, and I think you should do the same: talk, patch if needed, show
> you're here

...and sit it out with wheezy-LTS...

Elmar.

Re: Linux: concerns over systemd [OT]

[nanog]

Before leaving Debian, things to think:
- will systemd be officialy the only system available ?
- if so, won't we get a way to bypass that ?

I'm not gonna throw Debian away due to such a mess, without fighting
hard, and I think you should do the same: talk, patch if needed, show
you're here

If all good people who laugh insanely about systemd leave Debian alone,
who's left ? gnome-people ? systemd-fanatics (heretics?) ?

On 22/10/2014 12:09, Tom Hill wrote:
> On 22/10/14 10:41, Miles Fidelman wrote:
>> Which leads me to ask - those of you running server farms - what distros
>> are popular these days, for server-side operations?  We've been running
>> Debian like forever (by way of Solaris and redhat) - but this systemd
>> thing is making me rethink things.  Seems like an awful lot of folks are
>> now designing for the desktop, and it might be time to migrate to a BSD
>> or Solaris derivative.  What are others doing?
> 
> Not making rash decisions.
> 
> Debian and CentOS are still the 'asked for' distributions of Linux. Once
> in a blue moon, someone asks about something else.
> 
> Those that care are outnumbered greatly by those that just want a known
> platform to develop upon. (The irony of this is not lost on me).
> 
> I'd take systemd over ditching apt/yum in a mad panic. And I'm certainly
> no fan of systemd myself.
> 

Re: Linux: concerns over systemd [OT]

[Tom Hill]

On 22/10/14 10:41, Miles Fidelman wrote:
> Which leads me to ask - those of you running server farms - what distros
> are popular these days, for server-side operations?  We've been running
> Debian like forever (by way of Solaris and redhat) - but this systemd
> thing is making me rethink things.  Seems like an awful lot of folks are
> now designing for the desktop, and it might be time to migrate to a BSD
> or Solaris derivative.  What are others doing?

Not making rash decisions.

Debian and CentOS are still the 'asked for' distributions of Linux. Once
in a blue moon, someone asks about something else.

Those that care are outnumbered greatly by those that just want a known
platform to develop upon. (The irony of this is not lost on me).

I'd take systemd over ditching apt/yum in a mad panic. And I'm certainly
no fan of systemd myself.

-- 
Tom

Re: Linux: concerns over systemd [OT]

[Miles Fidelman]

George Herbert wrote:





On Oct 21, 2014, at 6:03 PM, Jay Ashworth  wrote:

GNOME is probably the linchpin.

But it's not just RH.  It's Debian, and by extension *buntu, and SuSE, and
at least one other major independent parent distro that I can't think of
just now...

And as far as I know, it's done; SuSE packages already largely don't even
include initscripts.

Enough to make a grown man fork RHEL (or, CentOS).



Which leads me to ask - those of you running server farms - what distros 
are popular these days, for server-side operations?  We've been running 
Debian like forever (by way of Solaris and redhat) - but this systemd 
thing is making me rethink things.  Seems like an awful lot of folks are 
now designing for the desktop, and it might be time to migrate to a BSD 
or Solaris derivative.  What are others doing?


Miles Fidelman

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

Re: Why is .gov only for US government agencies?

[Tei]

(very unimportant contribution, please ignore)

any change to this things, must be done in the benefit of future
users, making the internet a less weird place, with less exceptions

everyone else have already learned a .edu domain is probably a USA
university, and some .mil domain is the usa military.


((unfunny joke follow, you can stop reading here))
http://www.usma.edu  =>  usma.edu.mil.us



-- 
--
ℱin del ℳensaje.