Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Lamar Owen]

On 04/24/2017 11:52 AM, Warren Young wrote:

On Apr 24, 2017, at 7:53 AM, Lamar Owen  wrote:

James' point isn't the hardware cost, it's the people cost for retraining.

Unless you’ve hired monkeys so that you must train them to do their tasks by 
rote, that is a soft cost, not a hard cost.


Dollars are dollars.  An hour spent in training as one hour less to 'do 
work.'  (I'm intentionally playing devil's advocate here; I personally 
don't have a problem with the changes other than I now have to remember 
to check the OS type and version every time I log in to a server prior 
to issuing commands).

Note also that Byrne’s solution was to move to an entirely different OS, but we 
don’t hear about the “retraining cost” involved with that.  Surely it was a 
larger jump from C6 or C7 to FreeBSD 10 than from C6 to C7?
Guaranteed that it was a much larger jump.  Although I am tangentially 
reminded of Apollo Domain/OS 10 where the SysV/BSD/Aegis behavior was 
settable by changing an environment variable.



It’ll be interesting to see how much change FreeBSD gets in the next 7 years.


What is interesting to me, having just worked on a 20-year-old server 
stack last week, is how much hasn't changed as well as how much of what 
gets used a lot has changed (remember life before yum? How about early 
yum that needed to download individual headers?). But 90% of what I 
learned 30 years ago on Xenix System 3 for the Tandy 6000 still works 
(mainly because I still use vi :-)  ).


That depends on the organization and its goals. 


Very much true.  My IT department that I run has a bit of a reputation; 
our 'stock' answer to any IT question is rumored to be 'it depends.'  
YMMV, etc.



...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once installed, 
works great...

That doesn’t really contradict my point.

First, I said “most” hardware, but you’ve gone and cherry-picked uncommonly 
durable hardware here; you’re probably out in +3 sigma territory.


Hey, I just picked what I have here, that's all.  I could also talk 
about our 2007, 2009, and 2010-vintage donated EMC Clariion hardware.  
We have gotten many Dell PowerEdge servers and Optiplex/Precision 
desktops donated to us; got 19 Dell PE1950's donated in a lot three 
years ago, and those are some of our best servers.  The last servers we 
actually bought were a pair of Dell PE6950's in 2007; a grant funded two 
of them plus VMware VI3 and a couple of EMC Clariion CX3-10c SANs.  (All 
of those are still running and still doing their jobs.)


I'd rather have a five-year-old Precision than a 2017-model generic 
desktop.  A bit slower, but it's going to last a whole lot longer. For 
my own personal use I never buy new; I'll take the same money that would 
buy a low-end current-year marvel and buy a three to five year-old 
Precision that will run faster and much longer.  My current laptop is a 
Precision M6700 with a Core i7-3740QM.  It was $600 and will run rings 
around anything built today at that price point (and even twice or 
thrice that price point I dare say!).


But we're talking servers here, and the LS20 blade for the BladeCenter 
is middle-of-the-road as far as server hardware is concerned.  The 
PE1950 is on the lower side of MOR.



A lot of commodity PC-grade SOHO “server” hardware won’t even last the 3 years 
between major CentOS upgrades before dying of something.  There was a period 
where I’d budget 1-2 years for a Netgear switch, for example.  (They appear to 
be lasting longer now.)


I haven't looked at the lower end of the server hardware scale in a long 
time, although we did get some older low-end Dell PE SC1425's donated to 
us a while back.  They run C7 quite well, too.  I'd rather buy a used 
higher-end box than a new low-end box, which is going to both cost more 
and wear out sooner.


But that's just SOP for a non-profit.


Second, the application of my quoted opinion to your situation is that you 
should run that hardware with CentOS 7 through the EOL of the hardware or 
software, whichever comes first.  That is, I’m advising the change-adverse 
members of the audience to opt into the second group above, taking OS changes 
in big lumps when it’s time to move to new hardware anyway.
There is no easy solution.  The sysadmin's work and continuing education 
is never done.  I don't mind learning new things nor is my budgeted time 
so tight that I can't spend company time getting familiar with newer 
admin paradigms.  I understand that everyone is not like me (which is 
probably a good thing).


The sysadmin 'political landscape' is not too different from the 
'regular' political landscape, really.  You have conservatives, and you 
have progressives.  They both think they're right, and they both tend to 
demonize those who disagree.  And both are growing more extremist with 
time.  Is there no middle ground to be had (in the sysadmin world, at 
least)?


I certainly understand and sympathize with James' point of view.  I

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Valeri Galtsev]

On Mon, April 24, 2017 10:52 am, Warren Young wrote:
> On Apr 24, 2017, at 7:53 AM, Lamar Owen  wrote:
>> James' point isn't the hardware cost, it's the people cost for
>> retraining.
>
> Unless you’ve hired monkeys so that you must train them to do their
tasks by rote, that is a soft cost, not a hard cost.  If you’ve hired
competent IT staff, they will indeed need some time to work out the
differences, but they will do that on their own if only given that time.

I've been through that, I agree almost on all counts with James Byrne, so
I can give some comments from my chair here. Yes, I do consider myself a
notch more intelligent sysadmin than a monkey, and it does cost me time to
adjust to the differences, and it is annoying, and most annoying is to
adjust to some changes in philosophy (whoever considers the last
non-existent is allowed to re-qualify me back to the level of monkey ;-)

>
> Note also that Byrne’s solution was to move to an entirely different
OS,
> but we don’t hear about the “retraining cost” involved with that. 
Surely it was a larger jump from C6 or C7 to FreeBSD 10 than from C6 to
C7?

Yes and no. Maybe it is just my case, as I stared migrating servers to
FreeBSD even before C7 was released. FreeBSD feels closer to C5, whereas
difference between C5 and C7 is more dramatic (in my by no means objective
feeling). So, everyone who maintained C5 after quick "jump start" may feel
at hone with FreeBSD. My case may be even simpler as as many older
sysadmins I maintained a few UNIXes in the past, including FreeBSD.

>
> He also seems to be sweeping aside the fact that FreeBSD major releases
generally stay in support for about half the span of RHEL and its
derivatives.

True, but keeping your system incrementing in smaller steps that happen
more often is not a big deal. But this is a question of taste: both long
support life like RHEL and CentOS and shorter but smoother changes like
FreeBSD or some Linuxes (Debian and its clone Ubuntu come to mind) - they
both have their advantages and their place where they shine.

>  If he wants to stay on a supported OS the whole time that C7
> remains in support, he’s probably looking at 2 major OS version upgrades.

I've been through several FreeBSD major version upgrades on servers I
migrated to FreeBSD earliest, and they went smoothly, requiring just 3
reboots in the process. They all had a bunch of jails that were upgraded
as well. Not a single major issue that I had to resolve in a process (call
me lucky... knocking on wood ;-)

>
> It’ll be interesting to see how much change FreeBSD gets in the next 7
years.

It really is. Unless my usual luck in choosing what I expect to be in a
future fails me, not much change will happen to FreeBSD. I was thanking my
luck big time for choosing RedHat (and continuing to Fedora, then CentOS)
instead of Debian once when big flop in Debian (and all clones) was
discovered that was sitting there for over two years (search for Debian
predictable keys). My Debian friend was re-creating all his certificates,
re-generating ssh keys, rebuilding systems from scratch (as you don't know
who might have had root access to your box). And I was repeating myself,
that RedHat never had such a big flop. So I hope, I will be the same lucky
with my choice of FreeBSD as I was with my choice of RedHat (and clones)
back then.

And while we are here: My big thanks to RedHat, and big thanks to CentOS
team for the great job you guys are doing!! I wish I could help you more
than just maintaining CentOS and centosvault public mirrors.

Valeri

>
>> In many ways the Fedora treadmill is easier, being that there are many
more smaller jumps than the huge leap from C6 to C7.
>
> That depends on the organization and its goals.
>
> If you have a true IT staff that exists just to keep servers up to date
and working properly, then yes, you’re right, smaller upgrades every
3-6
> months are often easier to handle than trying to choke down 2-10 years
of
> changes all at once, depending on the LTS release strategy and how many
major upgrades you skip.
>
> If you’re trying to treat the OS as a base atop which you do something
else, and you just need something that will keep working for 2-10 years
despite being continually patched, then choking that big ball of changes
down every 2-10 years might be preferable.
>
> My main point is that if you’re going to take the second path, don’t
cry about how much change there is to choke down when you’re finally
forced to move forward.  You choose to put off dealing with it for many
years; the chickens have come back home to roost, so there will of
course
> be a lot of work to do.
>
>> ...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once
installed, works great...
>
> That doesn’t really contradict my point.
>
> First, I said “most” hardware, but you’ve gone and cherry-picked
uncommonly durable hardware here; you’re probably out in +3 sigma
territory.  A lot of commodity PC-

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Warren Young]

On Apr 24, 2017, at 7:53 AM, Lamar Owen  wrote:
> 
> James' point isn't the hardware cost, it's the people cost for retraining.

Unless you’ve hired monkeys so that you must train them to do their tasks by 
rote, that is a soft cost, not a hard cost.  If you’ve hired competent IT 
staff, they will indeed need some time to work out the differences, but they 
will do that on their own if only given that time.

Note also that Byrne’s solution was to move to an entirely different OS, but we 
don’t hear about the “retraining cost” involved with that.  Surely it was a 
larger jump from C6 or C7 to FreeBSD 10 than from C6 to C7?

He also seems to be sweeping aside the fact that FreeBSD major releases 
generally stay in support for about half the span of RHEL and its derivatives.  
If he wants to stay on a supported OS the whole time that C7 remains in 
support, he’s probably looking at 2 major OS version upgrades.

It’ll be interesting to see how much change FreeBSD gets in the next 7 years.

> In many ways the Fedora treadmill is easier, being that there are many more 
> smaller jumps than the huge leap from C6 to C7.

That depends on the organization and its goals.

If you have a true IT staff that exists just to keep servers up to date and 
working properly, then yes, you’re right, smaller upgrades every 3-6 months are 
often easier to handle than trying to choke down 2-10 years of changes all at 
once, depending on the LTS release strategy and how many major upgrades you 
skip.

If you’re trying to treat the OS as a base atop which you do something else, 
and you just need something that will keep working for 2-10 years despite being 
continually patched, then choking that big ball of changes down every 2-10 
years might be preferable.

My main point is that if you’re going to take the second path, don’t cry about 
how much change there is to choke down when you’re finally forced to move 
forward.  You choose to put off dealing with it for many years; the chickens 
have come back home to roost, so there will of course be a lot of work to do.

> ...dual-socket Opteron LS20 blades (10+ years old)...CentOS 7, once 
> installed, works great...

That doesn’t really contradict my point.

First, I said “most” hardware, but you’ve gone and cherry-picked uncommonly 
durable hardware here; you’re probably out in +3 sigma territory.  A lot of 
commodity PC-grade SOHO “server” hardware won’t even last the 3 years between 
major CentOS upgrades before dying of something.  There was a period where I’d 
budget 1-2 years for a Netgear switch, for example.  (They appear to be lasting 
longer now.)

Second, the application of my quoted opinion to your situation is that you 
should run that hardware with CentOS 7 through the EOL of the hardware or 
software, whichever comes first.  That is, I’m advising the change-adverse 
members of the audience to opt into the second group above, taking OS changes 
in big lumps when it’s time to move to new hardware anyway.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Lamar Owen]

On 04/20/2017 05:55 PM, Warren Young wrote:
... I find that most hardware is ready to fall over by the time the 
CentOS that was installed on it drops out of support anyway.

...


James' point isn't the hardware cost, it's the people cost for 
retraining.  In many ways the Fedora treadmill is easier, being that 
there are many more smaller jumps than the huge leap from C6 to C7. For 
the most part, however, I agree with most of your post.  I strongly 
disagree with the paragraph above, though.


I have worked for non-profits for most of my career thus far, which 
spans almost 30 years.  Non-profits by their very nature live on the 
slimmest of margins, and donations of hardware by individuals and 
companies have been in my experience the bread and butter for obtaining 
server-quality hardware.  The typical donation will be at least one or 
two generations old before the non-profit gets it; my current employer 
is just putting in production some IBM BladeCenters with the dual-socket 
Opteron LS20 blades (10+ years old).  Given the spiky workload, these 
blades are suitable for the targeted use, and the electrical 
requirements aren't a problem (I've done the math; it would take ten 
years or more to justify the purchase price of a new blade based on 
power savings alone, and our power is quite inexpensive here).  At least 
I can use very recent blades, and the eBay prices for 5-year-old blades 
are pretty good, so when I need that much more power I can get it.


Oh, and the LS20 blades are built like tanks.  We have a couple hundred 
of them that were donated, and we're going to use them.


For what it's worth, CentOS 7, once installed, works great as long as 
the lack of a GUI console isn't a problem (something with the 
BladeCenter's KVM switch and C7's kernel keeps the keyboard from working 
properly).


And don't even get me started on networking equipment, where I still 
have Catalyst 5500-series hardware in production.  (going on 20 years 
old and still trucking!)


And having said that, I just pulled out of service a server for another 
non-profit that had a power supply fan seize.  I posted about moving its 
application Friday.  It is an AMD K6-2/400 with a Western Digital 6GB 
boot drive and a Maxtor 30GB data drive, running Red Hat Linux 5.2.  The 
Antec power supply was put into service in 1999.  It stopped working 
Friday, and could have probably been put back into operation with a new 
power supply without a huge amount of work, but I decided it was time.  
Heh, it was time ten years ago!


The 6GB WD drive was only 19 years old; while I honestly wanted to see 
it turn 20, it was time (power supply glitches caused by overheating of 
the power supply; worst-case for hard disk death in my experience).  
Yeah, 24x7 operation for 19 years with minimal downtime.  I'm going to 
personally put it back into service for hysterical raisins, since the 
VA-503+ board doesn't need re-cap and it runs very well for what it is.  
I'm not sure what I'm going to run on it yet.  (It will be in service 
for the same reasons I'm going to put a Reh CPU280 running UZI280 into 
service.).




And that’s why I use *all* the major OSes and several weird ones besides.  None 
of it is perfect, yet it all has its place.

I couldn't agree more.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Warren Young]

On Apr 20, 2017, at 7:33 AM, James B. Byrne  wrote:
> 
> When a vendor ... fundamentally changes the way the administration
> of an operating system is presented

I’ve gotten the sense from this other part of the thread that the answer to my 
question, “What are you moving to?” is FreeBSD.

If you think FreeBSD system administration hasn’t changed over the past 10 
years, you must not have been using it that long.  What makes you think it 
won’t change again in the next 10 years, possibly in very large breaking ways?

> vanishingly few firms in my
> experience (i.e.NONE) have ever had operational programming staff
> write or even modify a device driver.

My company is very small.  I’ve modified device drivers to make them work 
properly on Linux, purely in a “scratch my own itch” kind of way.

I assure, you, many larger organizations also do this or something similar.  
Netflix is famous for using FreeBSD on their streaming servers and for tuning 
the FreeBSD kernel heavily for that purpose.

> A business is in existence to
> make money for its owners not dick around with esoteric computer
> theory and practice.

I’m not glorifying change for its own sake.  I’m just saying it happens, and 
however inessential it may be to your business’ operations is really not 
on-point.  The fact is that it happens everywhere in this industry, so your 
only choice is in which bag of changes you want to deal with, not whether you 
get a bag of changes.

> The idea that one has to rebuild from scratch entire host systems and
> then laboriously port over data and customised portions to a new host
> simply to upgrade the underlying OS is absolutely ludicrous.

I find that most hardware is ready to fall over by the time the CentOS that was 
installed on it drops out of support anyway.

That is to say, I think the right way to use CentOS is to install one major 
version on the hardware when it’s built, and then ride it for the 7-10 years 
until that OS version drops out of support.  (7 being the worst case, when you 
install a new system jst before the next major OS version comes out.)

Then there’s all the change that is outside the OS proper.  For example, 
there’s all the current changes in the way encryption is handled, which would 
require operational changes anyway.  You can’t keep running BIND 4 on your 
public-facing DNS servers, for example, even if all the security problems were 
somehow fixed without changing any user interface.

Ditto mail, HTTP, and many other critical services, since old versions often 
don’t even speak today’s required protocols.  (TLS 1.1 minimum, DMARC, DKIM, 
SPF, etc.)

FreeBSD, this supposed bastion of stability, now actively discourages you from 
using BIND in the first place, for example.  Now they want you to migrate to 
NSD + Unbound.  Oh noes, more change!

> Consider
> the tremendous labour costs regularly incurred in accomplishing what
> amounts to maintaining the status quo.

If you only wanted the status quo ante, why upgrade at all?

Obvious answer: because you actually do want *some* change.

> We just upgraded a FreeBSD host from 10.3 to 11.0 in situ without
> problem

Lucky you.  I’ve had such upgrades take a system out for a day, working around 
all the breakages.

Upgrading FreeBSD is historically one of the most painful things about it.  
It’s getting better, but only by changing how everything about packaging was 
done.  Holy ChangeLogs, Batman!

Don’t get the wrong idea that I don’t like FreeBSD, by the way.  I know these 
things about it because I use it regularly.  This is one of those “bags of 
changes” I referred to above.  Sometimes I want the Linux bag, and sometimes I 
want the FreeBSD bag, and I know going into the decision that each bag implies 
a future bag of changes I’ll have to deal with.

> It was the OS running the metal for multiple BHyve virtual machines

Ah, more change.  Bhyve only goes back to FreeBSD 10, so if you were using 
FreeBSD prior to that, you’d have had to either drag forward whatever VM 
manager you were using or migrate to bhyve.

> given we use ZFS in FreeBSD, and that we snapshot regularly, getting
> back to 10.3 would have been, and still could be, nearly
> instantaneous.

That’s a great reason to pick FreeBSD.  Just don’t fool yourself that by 
switching that you’ve somehow gotten off the upgrade treadmill.  You’ve only 
switched bags.

> Systemd is not the problem.  It
> is a symptom of a deeper malaise, indifference.

systemd offers benefits to certain classes of end users which could not have 
been achieved without *some* kind of change.

We can argue about how well systemd did its job — I share many of the negative 
opinions about it — but I think you’ll have a very tough time convincing me 
that we could have gotten all the benefits without changing the user interface.

Again it comes back to the bag of features: if you didn’t want any of the 
features systemd brought, then you may be right to abandon Linux.  (“May” 
because it

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Warren Young]

On Apr 19, 2017, at 2:22 PM, Chris Murphy  wrote:
> 
> On Wed, Apr 19, 2017 at 5:21 AM, James B. Byrne  wrote:
>> 
>> On Mon, April 17, 2017 17:13, Warren Young wrote:
>> 
>>> Also, I’ll remind the list that one of the *prior* times the systemd
>>> topic came up, I was the one reminding people that most of our jobs
>>> summarize as “Cope with change.â€
>> 
>> At some point 'coping with change' is discovered to consume a
>> disproportionate amount of resources for the benefits obtained…Linux
>> does not meet our business needs.
> 
> Apple has had massively disruptive changes on OS X and iOS. Windows
> has had a fairly disruptive set of changes in Windows 10.

…And FreeBSD finally just got through the whole binary-package-everything 
phase, meaning installation and upgrade practices have changed almost entirely 
in the past few years.  And before that, there was “move everything to ZFS,” 
which totally changed file system management, the boot system, backups, at-rest 
data encryption, file sharing services, and more.

The other BSDs haven’t had as much change, but that’s both bad and good.

Solaris has had mighty shakeups in the past 10 so years, much before the Oracle 
buyout and much more after.

So what is Harte & Lyne Limited moving *to*?

> the Linux community appears to have a
> change-for-change-sake fetish.

Are you seriously saying that none of the change in the Linux world in the past 
10 years has had any practical benefit?

The only such charge that immediately comes to mind for me is this move in the 
past 5 years or so to “flat” user interfaces, led by the mobile world but 
infecting desktop OSes as well…but not Linux.  If Linux were doing change for 
change’s sake, wouldn’t Linux have flattened its UIs like Google, Apple, and 
Microsoft have?

I wonder if what you’d actually prefer is magical levels of foresight, so that 
we could have made all the change required 30, 40 years ago, and now just be 
riding on top of perfect stability?

Or is is that you think the *ix world already had perfection and lost it?  What 
was the perfect OS, what version, and does it still run your apps today?  Will 
it still run them 10 years from now?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Jonathan Billings]

On Thu, Apr 20, 2017 at 09:33:30AM -0400, James B. Byrne wrote:
> Red Hat, again in my sole opinion, increasingly appears to me to be
> emulating another company notorious for shuffling the user interface
> to little evident purpose other than profit.  That is good business
> for them.  It is not good for us.

>From my perspective as a Red Hat customer who supports hundreds of
RHEL7 Workstation systems, Red Hat really doesn't seem to care or test
their Workstation product.  Their support doesn't seem to have much
training when it comes to problems with the GUI.  Since GNOME itself
moves along at a much faster pace than RHEL, I always end up looking
for archives of documentation, and trawling through GNOME's bugzilla.

Red Hat makes its business on the Server side.  They don't really care
about graphical user interfaces apart from the installer.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Pete Biggs]

> 
> Think about what that would take in terms of man hours to accomplish
> moving from EL6 to 7.  And moving from 5 to 6 was not much better. 
> This is just too expensive to repeat every three years.

So why do it? There is absolutely nothing wrong with sticking with EL6
for a long time, certainly for the lifetime of the hardware - EL5 has
only just gone EoL, and if you pay RH you can still have it on support.
 Just because EL7 exists, it doesn't mean that you have to upgrade to
it. I've only just started to seriously roll out CentOS7, and then
mostly only on new machines.

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[James B. Byrne]

On Wed, April 19, 2017 16:22, Chris Murphy wrote:

>
> Apple has had massively disruptive changes on OS X and iOS. Windows
> has had a fairly disruptive set of changes in Windows 10. About the
> only things that don't change are industrial OS's.
>

I have no idea how this reference applies to my earlier post.  We do
not use Apple or Windows servers and the desktop environment is
stabilised at Win7pro.  There will be be no Windows 10 here ever.  OSX
/ iOS employment is limited to personal devices, none of which are
permitted on premise in any case.

> When it comes to breaking user space, there's explicit rules against
> that in Linux kernel development. And internally consistent API/ABI
> stability is something you're getting in CentOS/RHEL kernels, it's one
> of the points the distributions exist. But the idea that Windows and
> OS X have better overall API stability I think is untrue, having
> spoken to a very wide assortment of developers who build primarily
> user space apps.

This may be true.  It is likely important to software developers.  It
is also totally irrelevant to a business.

Businesses, other than software development houses and consultants,
are software users.  When a vendor massively rearranges things in
their software, deprecates scripting syntax that has existed for years
if not decades, and fundamentally changes the way the administration
of an operating system is presented it really matter not a wit to a
business that the internal kernel level api remains unchanged.  It is
the accumulated administrative experience that is lost in consequence
that concerns a business given that replacing that loss will cost
either directly in retraining or indirectly in error and resultant
disruption; or both.

>
> What does happen, in kernel ABI changes can break your driver, as
> there's no upstream promise for ABI compatibility within the kernel
> itself. The effect of this is very real on say, Android, and might be
> one of the reasons for Google's Fuscia project which puts most of the
> drivers, including video drivers, into user space. And Microsoft also
> rarely changes things in their kernel, so again drivers tend to not
> break.
>
>

And this illustrates the point that I attempting to make.  A business
owner assumes that whatever OS is used it will deal with the various
devices that make up its hardware environment. For if it does not then
they seek an OS that does.  However, vanishingly few firms in my
experience (i.e.NONE) have ever had operational programming staff
write or even modify a device driver.  A business is in existence to
make money for its owners not dick around with esoteric computer
theory and practice.

Red Hat, again in my sole opinion, increasingly appears to me to be
emulating another company notorious for shuffling the user interface
to little evident purpose other than profit.  That is good business
for them.  It is not good for us.

Bear in mind that we have been RedHat/Whitebox/CA-OS/CentOS users
since 1998 so it is not like we are moving away from Linux with
anything like enthusiasm. But this upgrade treadmill that has
developed within RH is simply too costly for us to bear any longer. 
The idea that one has to rebuild from scratch entire host systems and
then laboriously port over data and customised portions to a new host
simply to upgrade the underlying OS is absolutely ludicrous. Consider
the tremendous labour costs regularly incurred in accomplishing what
amounts to maintaining the status quo.

We just upgraded a FreeBSD host from 10.3 to 11.0 in situ without
problem; and with very little downtime (three reboots in the space of
30 minutes).  This was no standalone device either.  It was the OS
running the metal for multiple BHyve virtual machines, themselves
running various operating systems (but mainly FreeBSD-11).  One of
said vms being our Samba-4 AD-DC.  And, had it all gone south then,
given we use ZFS in FreeBSD, and that we snapshot regularly, getting
back to 10.3 would have been, and still could be, nearly
instantaneous.

Think about what that would take in terms of man hours to accomplish
moving from EL6 to 7.  And moving from 5 to 6 was not much better. 
This is just too expensive to repeat every three years.

And allow me to forestall any claims that the chimera that is 'cloud
computing' is the answer. All that does is make creating the requisite
new platforms marginally less tedious. And that small advantage is
purchased at the cost of handling over control of all your data to
entities who are thoroughly discredited with respect to security and
privacy.

I am not anti or pro systemd, upstart, or etc/rc (or any other
software although I admit to holding a generally dim view of things
from Redmond).  I do not really care what is used so long as it works
and that introducing it does not greatly diminish the value of
existing user skills and knowledge.  However, I am past the point of
patience with gratuitous changes that offer no appreciable benefit to

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Chris Murphy]

On Wed, Apr 19, 2017 at 5:21 AM, James B. Byrne  wrote:
>
> On Mon, April 17, 2017 17:13, Warren Young wrote:
>
>>
>> Also, I’ll remind the list that one of the *prior* times the systemd
>> topic came up, I was the one reminding people that most of our jobs
>> summarize as “Cope with change.â€
>>
>
> At some point 'coping with change' is discovered to consume a
> disproportionate amount of resources for the benefits obtained.  In my
> sole opinion the Linux community appears to have a
> change-for-change-sake fetish. This is entirely appropriate for an
> experimental project.  The mistake that I made many years ago was
> inferring that Linux was nonetheless suitable for business.
>
> To experimenters a ten year product cycle may seem an eternity. To
> many organisations ten years is barely time to work out all the kinks
> and adapt internal processes to automated equivalents.  And the
> smaller the business the more applicable that statement becomes.
>
> I do not have any strong opinion about systemd as I have virtually no
> experience with it.  But the regular infliction of massively
> disruptive changes to fundamental software has convinced us that Linux
> does not meet our business needs. Systemd and Upstart are not the
> cause of that.  They are symptoms of a fundamental difference of focus
> between what our firm needs and what the Linux community wants.

Apple has had massively disruptive changes on OS X and iOS. Windows
has had a fairly disruptive set of changes in Windows 10. About the
only things that don't change are industrial OS's.

When it comes to breaking user space, there's explicit rules against
that in Linux kernel development. And internally consistent API/ABI
stability is something you're getting in CentOS/RHEL kernels, it's one
of the points the distributions exist. But the idea that Windows and
OS X have better overall API stability I think is untrue, having
spoken to a very wide assortment of developers who build primarily
user space apps.

What does happen, in kernel ABI changes can break your driver, as
there's no upstream promise for ABI compatibility within the kernel
itself. The effect of this is very real on say, Android, and might be
one of the reasons for Google's Fuscia project which puts most of the
drivers, including video drivers, into user space. And Microsoft also
rarely changes things in their kernel, so again drivers tend to not
break.


-- 
Chris Murphy
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[James B. Byrne]

On Mon, April 17, 2017 17:13, Warren Young wrote:

>
> Also, I’ll remind the list that one of the *prior* times the systemd
> topic came up, I was the one reminding people that most of our jobs
> summarize as “Cope with change.”
>

At some point 'coping with change' is discovered to consume a
disproportionate amount of resources for the benefits obtained.  In my
sole opinion the Linux community appears to have a
change-for-change-sake fetish. This is entirely appropriate for an
experimental project.  The mistake that I made many years ago was
inferring that Linux was nonetheless suitable for business.

To experimenters a ten year product cycle may seem an eternity. To
many organisations ten years is barely time to work out all the kinks
and adapt internal processes to automated equivalents.  And the
smaller the business the more applicable that statement becomes.

I do not have any strong opinion about systemd as I have virtually no
experience with it.  But the regular infliction of massively
disruptive changes to fundamental software has convinced us that Linux
does not meet our business needs. Systemd and Upstart are not the
cause of that.  They are symptoms of a fundamental difference of focus
between what our firm needs and what the Linux community wants.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Warren Young]

On Apr 15, 2017, at 12:19 AM, Anthony K  wrote:
> 
> Also, there's a lot of people moving to FreeBSD - but it appears that the 
> grass isn't greener there either as they are now trialling OpenRC.

You appear to have misunderstood my post.

First, TrueOS is not FreeBSD.  TrueOS is to FreeBSD as Ubuntu is to Debian, 
kinda-sorta.  Some of the things the TrueOS people do make their way back into 
FreeBSD, but TrueOS largely exists for those who want an easier desktop 
experience than stock FreeBSD or want a semi-supported bleeding-edge 
distribution of FreeBSD.

Now that TrueOS is based on the CURRENT (i.e. bleeding-edge) branch of FreeBSD 
development, TrueOS also serves a pioneer role for FreeBSD: those being the 
guys with all the arrows in their backs.

Because of that, TrueOS’s adoption of OpenRC doesn’t mean FreeBSD will follow 
suit.  Maybe they will, maybe they won’t.

Second, it’s not a “trial”.  It was announced, and then suddenly between two 
versions BSD rc was switched to OpenRC.  No “are you sure,” no “here are the 
consequences,” no “sorry, what you’re doing here is incompatible.”  Just boom, 
best-effort automatic conversion; if it breaks, you get to keep both pieces.

(Kinda makes you smile when you remember all the threads from those who found 
out that RHEL family OSes can’t self-upgrade between major versions.  Suddenly 
it’s looking like a feature.  Imagine if the EL6 to EL7 transition happened the 
same way.)

FreeBSD proper splits the difference between these two upgrade methods.  You 
have to explicitly opt into minor version upgrades, and automatic major version 
upgrades are possible but always offered with plenty of warnings and migration 
advice.

If you want a FreeBSD-specific lesson from this, it would be “don't run 
12.0-CURRENT on critical servers.”

Also, I’ll remind the list that one of the *prior* times the systemd topic came 
up, I was the one reminding people that most of our jobs summarize as “Cope 
with change.”
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Always Learning]

On Sun, 2017-04-16 at 18:25 +0100, Pete Biggs wrote:


> Yes. And despite what people think, those agencies don't have super
> powers. They have tools to help them, and lots of resources, but
> nothing out of the ordinary.

Untrue. They are in advance of mainstream developments. Spying has
existed for thousands, of years *and* it is their job to discover and
then discretely monitor what is going-on.

It is never one team doing everything but many highly specialist teams
dedicated to particular aspects of intelligence gathering which they do
expertly, and impressively, well.

All countries monitor, by all available means, what is happening in
their own territory and around the world. Just because, for example, the
USA and Russia are not officially loving buddies it never ever prevents
their intelligence agencies covertly sharing intelligence of mutual
interest. It is a incestuous world with an international web of contacts
doing favours and often disregarding their own government's official
political pronouncements.

>  There is nothing that the NSA can do that can't be done by other
>  agencies or even individuals (or enough individuals working together).

Mmmm, you forgot physical access to targets :-) That is one of their
advantages together with links into national infrastructures and
seemingly endless money. They are much more audacious than "normal"
people.

> There is no doubt that every single security agency in the world has a
> team working on discovering exploitable code in all operating systems.
> It's what they do. Any exploit they find that has been reported is
> probably because some other agency has found it as well so they want to
> stop them using it.

Not only software but hardware too. Most hardware has backdoors which
may not be routinely disclosed to purchasers. The question then arises
if the "official" backdoor is the only one. Difficult to detect if the
logic is coded on a chip.

> The only truly secure machine is one that is at the bottom of a mine
> shaft, turned off and dismantled. :-)

Nope, just protected from public networks like the Internet and from
radio transmissions of all types. Faraday-cage types and 'high-security
rooms' don't have to be buried at the bottom of mines; they exist
everywhere.



-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Gordon Messmer]

On 04/16/2017 03:53 AM, ken wrote:
And, yes, the exploits also include more than a few against linux.  Go 
to their site and look under vault7.  Or search for "linux" or 
"redhat"... you'll get hundreds of hits.  Here's just one: 
https://wikileaks.org/spyfiles4/documents/FinSpy-3.10-User-Manual.docx 
(If you have only a few seconds to look at it, see page 34.) 



That document appears to describe a remote control application, not an 
exploit.  It's only useful once you have administrative access to the 
system in question.


I won't say that I don't think exploits against Linux systems exist, 
that would be naive.  But, I haven't yet seen any CVEs for GNU/Linux 
systems resulting from the Vault7 leaks.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Pete Biggs]

> Indeed. I think the assertion "OSS is somehow safer because of community
> audit" is a logical fallacy. How would one go about "auditing" in the first
> place?

There are tools to audit source code for problems - OSS is safer
*because* the source is available and can be audited. 

>  Even if the various Intelligence agencies are not injecting
> vulnerabilities then they would certainly be in a strong position to
> discover some of the holes already existing some time before they become
> public.

Yes. And despite what people think, those agencies don't have super
powers. They have tools to help them, and lots of resources, but
nothing out of the ordinary. There is nothing that the NSA can do that
can't be done by other agencies or even individuals (or enough
individuals working together).

There is no doubt that every single security agency in the world has a
team working on discovering exploitable code in all operating systems.
It's what they do. Any exploit they find that has been reported is
probably because some other agency has found it as well so they want to
stop them using it.

> 
> Unless you're operating an air gap network you can be damn sure that 'they'
> can get into your systems if they really want to.

The only truly secure machine is one that is at the bottom of a mine
shaft, turned off and dismantled. :-)

P.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Pete Biggs]

On Sun, 2017-04-16 at 06:53 -0400, ken wrote:
> On 04/15/2017 04:46 AM, Pete Biggs wrote:
> > Not wishing to extend this thread further, but ...
> > 
> > > There are conspiracy theories out there that the NSA is involved with
> > > bringing systemd to Linux so they can have easy access to *"unknown"*
> > > bugs - aka backdoors - to all Linux installations using systemd *[1]*.
> > 
> > They're conspiracy theories, and that's it.
> 
> Hmm.  That's not quite it.  Wikileaks recently posted a trove of docs on 
> CIA exploits.  It was big news.  I'm surprised you missed that.  And, 
> yes, the exploits also include more than a few against linux.

That's not what I said - I said that the security agencies writing
backdoors into systemd was a conspiracy theory. I said later that they
have exploits as part of their toolkit. I'm surprised you missed that
part when you replied to it ...


> Years ago it was revealed that one of the linux developers inserted an 
> exploit into the gcc code which, when the login code was compiled, would 
> give him access to any system running it, effectively every linux 
> system.  This exploit was in the linux code for a long time and was 
> never discovered.  It was revealed only by the developer himself, and 
> only because he was retiring.  Point is: Code is often complex, 
> especially that written in C (or C++ and others), so much so that an 
> exploit can be written into it and not discovered for a long time, or 
> ever.  This is yet another argument against systemd: it would be much 
> easier to hide an exploit in it than in a handful of bash scripts.

Perhaps bash is exploitable - designed to hide the malicious code put
into the init.d scripts by the NSA.

P.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Alice Wonder]

On 04/16/2017 06:51 AM, Andrew Holway wrote:


There is no doubt that most security agencies have a long list of zero-

day exploits in their toolbox - I would hazard to suggest that they
wouldn't be doing their job if they didn't! But I seriously doubt they
would commission exploitable code in something that is openly
auditable.

P.



P., I used to think that too... indeed, I was thoroughly convinced of it.
But reality changed my mind.



Indeed. I think the assertion "OSS is somehow safer because of community
audit" is a logical fallacy. How would one go about "auditing" in the first
place? Even if the various Intelligence agencies are not injecting
vulnerabilities then they would certainly be in a strong position to
discover some of the holes already existing some time before they become
public.


I'm more worried about cloud services and the large number of root 
certificates that software trusts by default.


That's where a lot of the hacks are going to happen, and AFAIK the only 
defense against it is DNSSEC + DANE which very few zones actually utilize.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Andrew Holway]

>
> There is no doubt that most security agencies have a long list of zero-
>> day exploits in their toolbox - I would hazard to suggest that they
>> wouldn't be doing their job if they didn't! But I seriously doubt they
>> would commission exploitable code in something that is openly
>> auditable.
>>
>> P.
>>
>
> P., I used to think that too... indeed, I was thoroughly convinced of it.
> But reality changed my mind.


Indeed. I think the assertion "OSS is somehow safer because of community
audit" is a logical fallacy. How would one go about "auditing" in the first
place? Even if the various Intelligence agencies are not injecting
vulnerabilities then they would certainly be in a strong position to
discover some of the holes already existing some time before they become
public.

Unless you're operating an air gap network you can be damn sure that 'they'
can get into your systems if they really want to.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Jonathan Billings]

On Apr 16, 2017, at 6:53 AM, ken  wrote:
> Years ago it was revealed that one of the linux developers inserted an 
> exploit into the gcc code which, when the login code was compiled, would give 
> him access to any system running it, effectively every linux system.  This 
> exploit was in the linux code for a long time and was never discovered.  It 
> was revealed only by the developer himself, and only because he was retiring. 
>  Point is: Code is often complex, especially that written in C (or C++ and 
> others), so much so that an exploit can be written into it and not discovered 
> for a long time, or ever. This is yet another argument against systemd: it 
> would be much easier to hide an exploit in it than in a handful of bash 
> scripts.


When you say “one of the linux developers”, you mean Ken Thompson?

http://wiki.c2.com/?TheKenThompsonHack 

This story predates Linux, and describes a problem with any potential software. 
 

You realize ‘bash’ could be just as malicious as systemd in this scenario?  Are 
you meticulously going through *it’s* source code in your version of the world? 
 Note:  bash is not written in bash.

--
Jonathan Billings 


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[ken]

On 04/15/2017 04:46 AM, Pete Biggs wrote:

Not wishing to extend this thread further, but ...


There are conspiracy theories out there that the NSA is involved with
bringing systemd to Linux so they can have easy access to *"unknown"*
bugs - aka backdoors - to all Linux installations using systemd *[1]*.

They're conspiracy theories, and that's it.


Hmm.  That's not quite it.  Wikileaks recently posted a trove of docs on 
CIA exploits.  It was big news.  I'm surprised you missed that.  And, 
yes, the exploits also include more than a few against linux.  Go to 
their site and look under vault7.  Or search for "linux" or "redhat"... 
you'll get hundreds of hits.  Here's just one: 
https://wikileaks.org/spyfiles4/documents/FinSpy-3.10-User-Manual.docx 
(If you have only a few seconds to look at it, see page 34.)




The bottom line is that in
general people don't like not understanding things and when they come
across something they don't understand they create a mythology around
those things to rationalise their non-understanding.


True, but that "mansplanation" can point in a lot of ways, including at 
Pollyanna.





Systemd is complex; it's implementation was badly handled on a social
level. Nevertheless it is open source. It is highly unlikely that the
NSA, or any other agency, would risk putting in backdoors to code that
could be audited by Joe "random hacker" Blogs, let alone that might be
discovered by hostile agencies.


Years ago it was revealed that one of the linux developers inserted an 
exploit into the gcc code which, when the login code was compiled, would 
give him access to any system running it, effectively every linux 
system.  This exploit was in the linux code for a long time and was 
never discovered.  It was revealed only by the developer himself, and 
only because he was retiring.  Point is: Code is often complex, 
especially that written in C (or C++ and others), so much so that an 
exploit can be written into it and not discovered for a long time, or 
ever.  This is yet another argument against systemd: it would be much 
easier to hide an exploit in it than in a handful of bash scripts.



There is no doubt that most security agencies have a long list of zero-
day exploits in their toolbox - I would hazard to suggest that they
wouldn't be doing their job if they didn't! But I seriously doubt they
would commission exploitable code in something that is openly
auditable.

P.


P., I used to think that too... indeed, I was thoroughly convinced of 
it.  But reality changed my mind.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Pete Biggs]

Not wishing to extend this thread further, but ...

> There are conspiracy theories out there that the NSA is involved with 
> bringing systemd to Linux so they can have easy access to *"unknown"* 
> bugs - aka backdoors - to all Linux installations using systemd *[1]*. 

They're conspiracy theories, and that's it. The bottom line is that in
general people don't like not understanding things and when they come
across something they don't understand they create a mythology around
those things to rationalise their non-understanding. Factor in to that
the general mindset of Linux hackers/admins that they must know and
understand every part of their system and you create the perfect
environment for such theories to grow and blossom.

Systemd is complex; it's implementation was badly handled on a social
level. Nevertheless it is open source. It is highly unlikely that the
NSA, or any other agency, would risk putting in backdoors to code that
could be audited by Joe "random hacker" Blogs, let alone that might be
discovered by hostile agencies.

There is no doubt that most security agencies have a long list of zero-
day exploits in their toolbox - I would hazard to suggest that they
wouldn't be doing their job if they didn't! But I seriously doubt they
would commission exploitable code in something that is openly
auditable.

P.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll - So Long, and Thanks for All the fish.

[Anthony K]

On 09/04/17 14:39, Anthony K wrote:


So, at which stage are you in w/ regards to adopting systemd?  Are you 
still ridiculing it, violently opposed to it, or have you mellowed to it? 
Thanks for all those that responded. systemd still appears to be a sore 
topic.


systemd is still coping a whole lot of ridicule but not so violent 
opposition.  Can't say I understand why, but you can't please all of the 
people all of the time!


Quick comments to some issues identified in the conversation:
=

There are several responses siting poor documentation but I can't fault 
the documentation; there's plenty of it and the man pages are quite well 
structured - man -k --names-only systemd


Also, there's a lot of people moving to FreeBSD - but it appears that 
the grass isn't greener there either as they are now trialling OpenRC.


One issue I resolved quickly after installing CentOS 7 was to revert to 
ethx for interface names and to install iptables and remove firewalld.  
The other occassional issue I have is where restarting services takes a 
seriously long time and I've discovered that restarting 
`systemd-logind.service, dbus.service, and polkit.service resolves this, 
albeit for a short period before it crops up again *[0]*.



In closing:
###
There are conspiracy theories out there that the NSA is involved with 
bringing systemd to Linux so they can have easy access to *"unknown"* 
bugs - aka backdoors - to all Linux installations using systemd *[1]*.  
I guess anything goes now that Edward Snowden has educated us all - for 
better or worse.



Thanks again to all respondents - I quite enjoyed the read - I did read 
all responses.



Regards,
ak.

*[0]* - https://github.com/systemd/systemd/issues/2925
*[1]* - 
https://www.google.com.au/search?complete=0&hl=en&site=webhp&source=hp&q=nsa+and+systemd


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Lamar Owen]

On 04/09/2017 12:39 AM, Anthony K wrote:
So, at which stage are you in w/ regards to adopting systemd?  Are you 
still ridiculing it, violently opposed to it, or have you mellowed to it?

So, the hornets are swarming.

But to answer your question:  None of the above.  If I want to run 
CentOS 7, I need to learn systemd.  It doesn't matter what my opinion is 
of the systemd developers, or of systemd itself; CentOS is an RHEL 
rebuild, and RHEL 7 ships systemd.  If I do not want to deal with 
systemd, then I need to use something other than CentOS 7.  My 
'feelings' on the subject are irrelevant.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[mark]

On 04/12/17 22:02, Always Learning wrote:


On Mon, 2017-04-10 at 22:45 +0200, Nicolas Kovacs a écrit:


On my Slackware servers (no systemd, no funny network interface names),
I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0
and eth1 (and eth2 etc.) if needed.

Keep It Simple.


Un bon idea !
Ich auch
Ikki ook :-)

That's even scientific: "entities shall not be multiplied without need" - 
Occam's razor.


mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Steve Clark]

On 04/10/2017 05:17 PM, John R Pierce wrote:
> On 4/10/2017 1:57 PM, m.r...@5-cent.us wrote:
>> In what universe are those "consistant" device names, as opposed to
>> eth[0...]? And how could it help automated scripts that you can run on
>> *any*  system you're administering?
> if I have a Intel gigE interface and a Marvell 10g interfaces, which one 
> is eth0 and why?
>
> Say its Intel on eth0 and Marvell on eth1, if I then add another intel, 
> is the Marvell now eth2 ?
>
>
In my experience the new interface would be eth2, because the startup scripts 
create a mac binding to ethx name in the
/etc/udev/rules.d/70-persistent-net.rules file, so even if the intel is probed 
before the marvel the scripts rename them to keep
them in the original order.

Steve
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Always Learning]

On Mon, 2017-04-10 at 22:45 +0200, Nicolas Kovacs a écrit:

> On my Slackware servers (no systemd, no funny network interface names),
> I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0
> and eth1 (and eth2 etc.) if needed.
> 
> Keep It Simple.

Un bon idea !
Ich auch
Ikki ook :-)


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Always Learning]

On Mon, 2017-04-10 at 15:38 -0400, m.r...@5-cent.us wrote:

> At home, I'm staying on CentOS 6 until it EoLs.

Production and development +1

Then FreeBSD ?


-- 
Regards,

Paul.
England, EU.  England's place is in the European Union.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[m . roth]

Andrew Holway wrote:
>>
>> I think the points been made, can we all move along and let this thread
>> be.
>>
>
> SystemD RULES!
>
> :D

systemd may be worse than Sean Spicer (You *did* read the news
yesterday eve, right?)

mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Leroy Tennison]

Why don't we discuss something ***less*** controversial, 
like politics or religion?

- Original Message -
From: "Karanbir Singh" 
To: "centos" 
Sent: Wednesday, April 12, 2017 6:19:43 AM
Subject: Re: [CentOS] OT: systemd Poll

On 09/04/17 05:39, Anthony K wrote:
> So, at which stage are you in w/ regards to adopting systemd?  Are you
> still ridiculing it, violently opposed to it, or have you mellowed to it?

I think the points been made, can we all move along and let this thread be.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Andrew Holway]

>
> I think the points been made, can we all move along and let this thread be.
>

SystemD RULES!

:D
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Karanbir Singh]

On 09/04/17 05:39, Anthony K wrote:
> So, at which stage are you in w/ regards to adopting systemd?  Are you
> still ridiculing it, violently opposed to it, or have you mellowed to it?

I think the points been made, can we all move along and let this thread be.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Gordon Messmer]

On 04/11/2017 07:09 PM, Keith Keller wrote:

On 2017-04-11, Gordon Messmer  wrote:

You also don't have the flexibility to replace the kernel.  Or glibc.

But you do, don't you?  It'll take you months to replace them, or years
to rewrite, but you*can*  do it.



The same is true of systemd, which is what I'm trying to illustrate.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Tue, April 11, 2017 9:09 pm, Keith Keller wrote:
> On 2017-04-11, Gordon Messmer  wrote:
>>
>> You also don't have the flexibility to replace the kernel.  Or glibc.
>
> But you do, don't you?  It'll take you months to replace them, or years
> to rewrite, but you *can* do it.

I agree. We had once new machine with 32 bit CPUs and 8GB of RAM - that
time RAM was cheap, but amd664 architecture didn't exist yet,- and
standard kernel only supported 1 GB user space. Not changeable in kernel
config. It took me between one and two weeks to find hardcoded boundaries,
and change them; 3.5 GB for userspace was max I could squeeze leaving the
rest to kernel + stack + ... and still having stable solid system. That
was decent solution.

I wholeheartedly agree with Keith.

Valeri

> That is the freedom that open source
> software provides that proprietary OSes do not; it does not come with
> the additional promise to provide exactly the software you specify.
>
> --keith
>
> --
> kkel...@wombat.san-francisco.ca.us
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Keith Keller]

On 2017-04-11, Gordon Messmer  wrote:
>
> You also don't have the flexibility to replace the kernel.  Or glibc.

But you do, don't you?  It'll take you months to replace them, or years
to rewrite, but you *can* do it.  That is the freedom that open source
software provides that proprietary OSes do not; it does not come with
the additional promise to provide exactly the software you specify.

--keith

-- 
kkel...@wombat.san-francisco.ca.us


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Scott Robbins]

On Tue, Apr 11, 2017 at 05:11:25PM -0500, Valeri Galtsev wrote:
> 
> On Tue, April 11, 2017 4:41 pm, Warren Young wrote:
> > On Apr 11, 2017, at 11:28 AM, Scott Robbins  wrote:
> >>
> >> (though they're talking of trying OpenRC)
> >
> > Not just talking.  TrueOS, neé PC-BSD, now runs on OpenRC.
> >
> > So let me tell you about how my recent TrueOS server upgrade broke
> > virtually all of my services on the TrueOS server, roached the X
> > configuration, and now has the system in an un-upgradeable state, to the
> > point that it’s looking like I’ll have to reinstall if I ever want to
> > install software from pkg again.
> 


> All systems suck. And thanks to that I got my job.

And as for me, I was just trying to make people laugh. :)


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Tue, April 11, 2017 4:41 pm, Warren Young wrote:
> On Apr 11, 2017, at 11:28 AM, Scott Robbins  wrote:
>>
>> (though they're talking of trying OpenRC)
>
> Not just talking.  TrueOS, neé PC-BSD, now runs on OpenRC.
>
> So let me tell you about how my recent TrueOS server upgrade broke
> virtually all of my services on the TrueOS server, roached the X
> configuration, and now has the system in an un-upgradeable state, to the
> point that it’s looking like I’ll have to reinstall if I ever want to
> install software from pkg again.
>
> Oh, and let’s also talk about how FreeBSD has been training people to
> run services via direct /etc/rc.d/$service script calls, but now you must
> use rc-service calls, with no graceful fallback.  Got scripts calling the
> old style scripts?  Too bad.

All systems suck. And thanks to that I got my job.

Valeri

>
> The grass isn’t always greener on the other side of the fence.



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Warren Young]

On Apr 11, 2017, at 11:28 AM, Scott Robbins  wrote:
> 
> (though they're talking of trying OpenRC)

Not just talking.  TrueOS, neé PC-BSD, now runs on OpenRC.

So let me tell you about how my recent TrueOS server upgrade broke virtually 
all of my services on the TrueOS server, roached the X configuration, and now 
has the system in an un-upgradeable state, to the point that it’s looking like 
I’ll have to reinstall if I ever want to install software from pkg again.

Oh, and let’s also talk about how FreeBSD has been training people to run 
services via direct /etc/rc.d/$service script calls, but now you must use 
rc-service calls, with no graceful fallback.  Got scripts calling the old style 
scripts?  Too bad.

The grass isn’t always greener on the other side of the fence.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[J Martin Rushton]

On 11/04/17 17:02, Bruce Ferrell wrote:
> On 04/11/2017 07:50 AM, Andrew Holway wrote:
>>>   I'd much rather have a bash script to look at-- and manually step
>>> through.
>>
>> Is that a joke? Bash is an almighty impenetrable nightmare. I've been
>> doing
>> *nix for nearly 10 years and *still* am unable to read anything vaguely
>> complicated in bash whereas I can write fairly decent python after 6
>> months. From my point of view SystemD is amazing I can write a 6 line
>> service file for my apps and it *just works* and I don't have to think
>> about it anymore.
>>
>> What is it about SystemD that brings out the Richard Stallman in
>> everyone?
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>>
> *10 WHOLE years*...  And bash is *STILL* impenetrable for you?
> 
> How about over 30 and it took me a week?  No, I don't carry a CS degree
> or cert of any kind either, just some high school.
> 
> For me, systemd has been an absolute nightmare of unexpected reboots and
> non-transparently broken processes with just plain bad implementations
> crammed onto my system.  Faster boot they said, except it ISN'T faster
> now, it's slower and MUCH more difficult to sort through to find out why
> with it's monolithic architecture and poor documentation.
> 
> It wasn't broken before.  What was being fixed?
> 
Boot speed isn't everything.  My servers take far longer to initialise
than boot, so having to repeat the boot to sort out the black magic
takes __much__ longer than having a steppable script.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[J Martin Rushton]

Similar.  When user jobs can run for a couple of months you can't just
do a reboot every few days.  Yum makes doing updates easy, but that can
bring another problem: I've seen people do "yum update" multiple times
and not realise that they need to reboot.

On 11/04/17 19:23, Pete Biggs wrote:
> 
>>
>> Years uptime, wow! What do you do when security update for kernel or glibc
>> is released? These come as often as once every 45 days in my observation.
>>
> They're non-exposed hosts doing very specific things - think internal
> network with an air-gap to the internet.
> 
> P.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
> 



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Tue, April 11, 2017 1:23 pm, Pete Biggs wrote:
>
>>
>> Years uptime, wow! What do you do when security update for kernel or
>> glibc
>> is released? These come as often as once every 45 days in my
>> observation.
>>
> They're non-exposed hosts doing very specific things - think internal
> network with an air-gap to the internet.

Ah, that explains. Doesn't suite me though: I do run machines in an
assumption that bad guy is already inside. Saved me twice: I watched
attempts of elevation of privileges (unsuccessful) before I locked regular
user account that was compromised. So this doesn't suit me, alas, even for
backend servers. I guess I had too "strict" teachers ;-)

Thanks for clarifying!

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Pete Biggs]

> 
> Years uptime, wow! What do you do when security update for kernel or glibc
> is released? These come as often as once every 45 days in my observation.
> 
They're non-exposed hosts doing very specific things - think internal
network with an air-gap to the internet.

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Tue, April 11, 2017 12:43 pm, Pete Biggs wrote:
>
>> I just read through this thread, and I must say I'm a bit worried, to
>> the point that I'm asking myself: is CentOS still as reliable as it was?
>
> Yes.
>
>> This is not a rhetorical question, but a real one. On my Slackware
>> servers, I'm hosting a few dozen websites, various platforms for schools
>> and public libraries, some streaming stuff, webmail, etc. and these
>> machines *never ever* give me any headache. Can I expect the same
>> stability from CentOS 7?
>>
> I have a hundred or so CentOS desktops, ~10 webservers hosting many
> virtual sites, an LDAP infrastructure, a couple of VM servers, a number
> of large computational clusters, mail servers, mail relays, a Nextcloud
> host and so on all running on CentOS of various flavours (but mostly 7
> now) and ALL of them rock solid. I don't see any of these random
> reboots because of systemd, it is just not something I recognise - the
> uptimes are usually in the months to years region.

Years uptime, wow! What do you do when security update for kernel or glibc
is released? These come as often as once every 45 days in my observation.

Valeri

>
> Look, CentOS is a RHEL clone, RH make money out of this and they aren't
> going to produce an OS that is flaky. If they did, no one would use it.
>
> P.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Nicolas Kovacs]

Le 11/04/2017 à 19:43, Pete Biggs a écrit :
> Look, CentOS is a RHEL clone, RH make money out of this and they aren't
> going to produce an OS that is flaky. If they did, no one would use it.

That was my initial thought. Thanks for confirming it.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Pete Biggs]

> I just read through this thread, and I must say I'm a bit worried, to
> the point that I'm asking myself: is CentOS still as reliable as it was?

Yes.

> This is not a rhetorical question, but a real one. On my Slackware
> servers, I'm hosting a few dozen websites, various platforms for schools
> and public libraries, some streaming stuff, webmail, etc. and these
> machines *never ever* give me any headache. Can I expect the same
> stability from CentOS 7?
> 
I have a hundred or so CentOS desktops, ~10 webservers hosting many
virtual sites, an LDAP infrastructure, a couple of VM servers, a number
of large computational clusters, mail servers, mail relays, a Nextcloud
host and so on all running on CentOS of various flavours (but mostly 7
now) and ALL of them rock solid. I don't see any of these random
reboots because of systemd, it is just not something I recognise - the
uptimes are usually in the months to years region.

Look, CentOS is a RHEL clone, RH make money out of this and they aren't
going to produce an OS that is flaky. If they did, no one would use it.

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Alice Wonder]

On 04/11/2017 10:36 AM, Gordon Messmer wrote:

On 04/11/2017 10:16 AM, Nicolas Kovacs wrote:

I just read through this thread, and I must say I'm a bit worried, to
the point that I'm asking myself: is CentOS still as reliable as it was?



Yes. I've been very happy with release 7 across hundreds of servers and
dozens of configurations.




Ditto that. CentOS 7 has been an amazing release for me.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Gordon Messmer]

On 04/11/2017 10:16 AM, Nicolas Kovacs wrote:

I just read through this thread, and I must say I'm a bit worried, to
the point that I'm asking myself: is CentOS still as reliable as it was?



Yes. I've been very happy with release 7 across hundreds of servers and 
dozens of configurations.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Scott Robbins]

On Tue, Apr 11, 2017 at 12:11:19PM -0400, Jonathan Billings wrote:
> I feel like this conversation has reached the "lets just keep
> repeating FUD about systemd" stage and probably won't progress in a
> useful direction.
> 
> Maybe we should just jump right to the end that we always have each
> time this comes up.  systemd is the death of linux and you're leaving
> for FreeBSD/devuan/whatever.  Lets just move along now.

Young man,
You feel down on your luck
Young man
You're tired of Linux
Young Man 
You want to free
Of trying to figure out systemd

Why don't you try
Free BSD
FreeeBSD
It still has an init
that you can see
(though they're talking of trying 
OpenRC)

And so on.
Sorry, that's all I was allowed to sing at work before people got annoyed.
(We're a FreeBSD shop though).  
-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Nicolas Kovacs]

Le 11/04/2017 à 18:11, Jonathan Billings a écrit :
> Maybe we should just jump right to the end that we always have each
> time this comes up.  systemd is the death of linux and you're leaving
> for FreeBSD/devuan/whatever.  Lets just move along now.

I've been using CentOS 5.x almost exclusively for a few years on both
servers and desktops, and then I went back to Slackware Linux because I
liked its simplicity. Slackware is still running on most of my servers
and desktops, and I even maintain a small spinoff distribution for
desktops (https://www.microlinux.eu).

I'm currently faced with the perspective of teaching Linux for some
bigger companies (think broadcasting business). Since here in France,
many big companies are running RHEL on their servers, I thought it might
be a good idea to check out CentOS again. So some time ago I started
fiddling with more recent versions again, and I even have a new section
on my blog about CentOS: http://blog.microlinux.fr/centos/

I just read through this thread, and I must say I'm a bit worried, to
the point that I'm asking myself: is CentOS still as reliable as it was?
This is not a rhetorical question, but a real one. On my Slackware
servers, I'm hosting a few dozen websites, various platforms for schools
and public libraries, some streaming stuff, webmail, etc. and these
machines *never ever* give me any headache. Can I expect the same
stability from CentOS 7?

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Gordon Messmer]

On 04/11/2017 09:48 AM, Leroy Tennison wrote:

Interesting that you should cite Stallman because freedom is an issue here, 
we've been reduced to Microsoft when it comes to init.  We've lost most of our 
flexibility with no option to choose piecemeal what we want and don't want.




You also don't have the flexibility to replace the kernel.  Or glibc.

Does anyone here remember Red Hat 5, when libc5 was replaced with 
glibc?  The noise about systemd seems *awfully* familiar.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Jonathan Billings]

On Tue, Apr 11, 2017 at 09:24:11AM -0700, Bruce Ferrell wrote:
> Well, sorta yes and sorta no Jonathan.  Yes, in that I've moved my
> personal systems to Linux distros that don't use systemd. 
> 
> No in the it's not "FUD"... The complaints about the code and
> development are facts.  Not alternative facts, real, verifiable
> incidents and outages. 
> 
> Professionally, I end up having to deal with these incidents that
> suck my time and effort and irritate my customers. 
> 
> Just move on, ISN'T a solution.
> 
> I deal in solutions.  Partially, where possible, I move my customers
> to system that don't have this viral infection just as I moved them
> off of windows, where possible. 
> 
> systemd isn't "the death of linux".  It is a serious quagmire that
> needs to be resolved.  That can only happen by confronting the issue
> head on.  step one is admitting a problem exists.

While some of these might be valid concerns, the CentOS mailing list
isn't really the place where you'll be able to achieve those goals.
CentOS is a rebuild of RHEL, with very little change.  Maybe as a Red
Hat customer, you might get more traction complaining about how their
OS runs.

I suggest getting involved with the systemd project if you'd like to
make positive change there.  You can also participate in the Fedora
Project if you'd like to influence how systemd manages the OS.  You'll
also have plenty of heads-up about things coming down the pipe before
they hit CentOS.

If you want a real head-scratcher, take a look at how systemd --user
runs on Fedora 25.  It is my current painful interaction with
systemd. 

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Leroy Tennison]

Interesting that you should cite Stallman because freedom is an issue here, 
we've been reduced to Microsoft when it comes to init.  We've lost most of our 
flexibility with no option to choose piecemeal what we want and don't want.

- Original Message -
From: "Andrew Holway" 
To: "centos" 
Sent: Tuesday, April 11, 2017 9:50:02 AM
Subject: Re: [CentOS] OT: systemd Poll

>
>  I'd much rather have a bash script to look at-- and manually step through.


Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing
*nix for nearly 10 years and *still* am unable to read anything vaguely
complicated in bash whereas I can write fairly decent python after 6
months. From my point of view SystemD is amazing I can write a 6 line
service file for my apps and it *just works* and I don't have to think
about it anymore.

What is it about SystemD that brings out the Richard Stallman in everyone?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Leroy Tennison]

Interesting, I'm going to have to look into this.

- Original Message -
From: "Jonathan Billings" 
To: "centos" 
Sent: Tuesday, April 11, 2017 8:32:49 AM
Subject: Re: [CentOS] OT: systemd Poll

On Tue, Apr 11, 2017 at 08:02:56AM -0500, Leroy Tennison wrote:
> This does concern me, another post referred to the heavy-handed way
> in which systemd has been implemented and I totally agree.  "You
> will conform" - no exceptions.  What I fear is that we will lose the
> ability to control the name, MAC address association at some future
> point because "no one needs to do that" (speaking from their ivory
> tower). 

To be honest, if you use systemd-networkd (instead of NM or the network init
script), you can arbitrarily name your interfaces whatever you want, in a much
more configuration-management-friendly way.

It's just that systemd-networkd isn't that well-known yet.  I'm on the fence
about whether I like it or not.  It is nice that its really simple files and
consistent across distros, but it doesn't yet do stuff like wifi well.  Also,
most GNOME desktops have a NM applet that gets confused if you're using
systemd-networkd.  I still feel like systemd-networkd is a lot less
convoluted than NetworkManager.

https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Bruce Ferrell]

On 04/11/2017 09:11 AM, Jonathan Billings wrote:

On Tue, Apr 11, 2017 at 09:02:45AM -0700, Bruce Ferrell wrote:

How about over 30 and it took me a week?  No, I don't carry a CS
degree or cert of any kind either, just some high school.

For me, systemd has been an absolute nightmare of unexpected reboots
and non-transparently broken processes with just plain bad
implementations crammed onto my system.  Faster boot they said,
except it ISN'T faster now, it's slower and MUCH more difficult to
sort through to find out why with it's monolithic architecture and
poor documentation.

It wasn't broken before.  What was being fixed?

I feel like this conversation has reached the "lets just keep
repeating FUD about systemd" stage and probably won't progress in a
useful direction.

Maybe we should just jump right to the end that we always have each
time this comes up.  systemd is the death of linux and you're leaving
for FreeBSD/devuan/whatever.  Lets just move along now.


Well, sorta yes and sorta no Jonathan.  Yes, in that I've moved my personal 
systems to Linux distros that don't use systemd.

No in the it's not "FUD"... The complaints about the code and development are 
facts.  Not alternative facts, real, verifiable incidents and outages.

Professionally, I end up having to deal with these incidents that suck my time 
and effort and irritate my customers.

Just move on, ISN'T a solution.

I deal in solutions.  Partially, where possible, I move my customers to system 
that don't have this viral infection just as I moved them off of windows, where 
possible.

systemd isn't "the death of linux".  It is a serious quagmire that needs to be resolved.  That can only happen by confronting the issue head on.  step one is admitting a problem 
exists.




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Christian, Mark]

On Tue, 2017-04-11 at 12:11 -0400, Jonathan Billings wrote:
Maybe we should just jump right to the end that we always have each
> time this comes up.  systemd is the death of linux and you're leaving
> for FreeBSD/devuan/whatever.  Lets just move along now.
+1
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Jonathan Billings]

On Tue, Apr 11, 2017 at 09:02:45AM -0700, Bruce Ferrell wrote:
> How about over 30 and it took me a week?  No, I don't carry a CS
> degree or cert of any kind either, just some high school. 
> 
> For me, systemd has been an absolute nightmare of unexpected reboots
> and non-transparently broken processes with just plain bad
> implementations crammed onto my system.  Faster boot they said,
> except it ISN'T faster now, it's slower and MUCH more difficult to
> sort through to find out why with it's monolithic architecture and
> poor documentation. 
> 
> It wasn't broken before.  What was being fixed?

I feel like this conversation has reached the "lets just keep
repeating FUD about systemd" stage and probably won't progress in a
useful direction.

Maybe we should just jump right to the end that we always have each
time this comes up.  systemd is the death of linux and you're leaving
for FreeBSD/devuan/whatever.  Lets just move along now.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Bruce Ferrell]

On 04/11/2017 07:50 AM, Andrew Holway wrote:

  I'd much rather have a bash script to look at-- and manually step through.


Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing
*nix for nearly 10 years and *still* am unable to read anything vaguely
complicated in bash whereas I can write fairly decent python after 6
months. From my point of view SystemD is amazing I can write a 6 line
service file for my apps and it *just works* and I don't have to think
about it anymore.

What is it about SystemD that brings out the Richard Stallman in everyone?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


*10 WHOLE years*...  And bash is *STILL* impenetrable for you?

How about over 30 and it took me a week?  No, I don't carry a CS degree or cert 
of any kind either, just some high school.

For me, systemd has been an absolute nightmare of unexpected reboots and 
non-transparently broken processes with just plain bad implementations crammed 
onto my system.  Faster boot they said, except it ISN'T faster now, it's slower 
and MUCH more difficult to sort through to find out why with it's monolithic 
architecture and poor documentation.

It wasn't broken before.  What was being fixed?

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Andrew Holway]

>
> most scripts are perfectly clear.


This is the Richard Stallman assumption:

He assumes that the average normal person is able to program Fortran 77 and
Lisp and are able to spend inordinate amounts of time debugging and getting
obscure OSS software packages working because using Skype and other
proprietary software is somehow evil. Bash is a significant barrier for
entry unless you spend a significant amount of your time writing bash
whereas a service file is 6 lines for a proper service management solution.

>From a usability point of view init is a disaster.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[m . roth]

Andrew Holway wrote:
>>
>>  I'd much rather have a bash script to look at-- and manually step
>> through.
>
Same here.
>
> Is that a joke? Bash is an almighty impenetrable nightmare. I've been
> doing *nix for nearly 10 years and *still* am unable to read anything
vaguely
> complicated in bash whereas I can write fairly decent python after 6
> months. From my point of view SystemD is amazing I can write a 6 line
> service file for my apps and it *just works* and I don't have to think
> about it anymore.
>
> What is it about SystemD that brings out the Richard Stallman in everyone?

Sorry, other than my manager's extreme use of regular expressions, most
scripts are perfectly clear. I'm not sure what you're seeing as an
"impenetrable nightmare"

 mark "likes bash, because I can use my c-shell-isms"

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[m . roth]

Jonathan Billings wrote:
> On Tue, Apr 11, 2017 at 08:02:56AM -0500, Leroy Tennison wrote:
>> This does concern me, another post referred to the heavy-handed way
>> in which systemd has been implemented and I totally agree.  "You
>> will conform" - no exceptions.  What I fear is that we will lose the
>> ability to control the name, MAC address association at some future
>> point because "no one needs to do that" (speaking from their ivory
>> tower).
>
> To be honest, if you use systemd-networkd (instead of NM or the network
> init script), you can arbitrarily name your interfaces whatever you
want, in a
> much more configuration-management-friendly way.
>
> It's just that systemd-networkd isn't that well-known yet.  I'm on the
> fence about whether I like it or not.  It is nice that its really simple
files
> and consistent across distros, but it doesn't yet do stuff like wifi well.
> Also, most GNOME desktops have a NM applet that gets confused if you're
using
> systemd-networkd.  I still feel like systemd-networkd is a lot less
> convoluted than NetworkManager.
>
> https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

I may need to look into that. I mean, I've disliked NM since I first saw
it in 6. I mean, why would I want it to even try wpa-supplicant on a wired
network? And perhaps for home users or laptops, but for a server install,
I NEVER want avahi running.

   mark "Do what I tell you to do, and stop trying to think you know better"


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Andrew Holway]

>
>  I'd much rather have a bash script to look at-- and manually step through.


Is that a joke? Bash is an almighty impenetrable nightmare. I've been doing
*nix for nearly 10 years and *still* am unable to read anything vaguely
complicated in bash whereas I can write fairly decent python after 6
months. From my point of view SystemD is amazing I can write a 6 line
service file for my apps and it *just works* and I don't have to think
about it anymore.

What is it about SystemD that brings out the Richard Stallman in everyone?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[ken]

On 04/11/2017 09:10 AM, Leroy Tennison wrote:

Another huge concern: It breaks, someone else has to fix it because it's in the 
C source - after it reaches a high enough priority.  At least with scripts you 
could conceivably hack it.  From what I've read there is some ability to get 
systemd to defer to a script, I'm going to have to become an expert at that.


Even as a former C programmer, that disturbs me too.  I'd much rather 
have a bash script to look at-- and manually step through.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Tue, April 11, 2017 8:12 am, James B. Byrne wrote:
>
> On Sun, April 9, 2017 00:39, Anthony K wrote:
>> According to "Arthur Schopenhauer":
>>
>> "All truth passes through three stages.
>>  First, it is ridiculed.
>>  Second, it is violently opposed.
>>  Third, it is accepted as being self-evident."
>>
>> I must admit that I skipped through the first and second stages - I
>> never found creating init scripts a joy and instead opted to write my
>> own scripts that I launched via inittab.  As such, I welcomed the
>> simplicity systemd's service files without fuss.
>>
>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>> still ridiculing it, violently opposed to it, or have you mellowed to
>> it?
>>
>
> A. FreeBSD-11.
>

FreeBSD here too. But we should be quieter about the direction we are
fleeing. Microsoft has already made big donation to FreeBSD foundation ;-)

Valeri


Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[ken]

On 04/11/2017 07:42 AM, m...@tdiehl.org wrote:

On Tue, 11 Apr 2017, ken wrote:

And I have to wonder, why in /usr/lib/systemd/system/ is there a file 
named -.slice ?? Didn't anyone see a problem with this...? or 
countless possible problems?  Doesn't instill confidence.


Well wonder no more!! Simply look it up in the man pages. It is 
documented

after all!!

Hummm, lets see: (vcliff pts2) # grep Documentation= 
/usr/lib/systemd/system/-.slice

Documentation=man:systemd.special(7)
(vcliff pts2) #

I will let you do the rest of the research yourself. :-)




Tom, you're missing the point.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Jonathan Billings]

On Tue, Apr 11, 2017 at 08:02:56AM -0500, Leroy Tennison wrote:
> This does concern me, another post referred to the heavy-handed way
> in which systemd has been implemented and I totally agree.  "You
> will conform" - no exceptions.  What I fear is that we will lose the
> ability to control the name, MAC address association at some future
> point because "no one needs to do that" (speaking from their ivory
> tower). 

To be honest, if you use systemd-networkd (instead of NM or the network init
script), you can arbitrarily name your interfaces whatever you want, in a much
more configuration-management-friendly way.

It's just that systemd-networkd isn't that well-known yet.  I'm on the fence
about whether I like it or not.  It is nice that its really simple files and
consistent across distros, but it doesn't yet do stuff like wifi well.  Also,
most GNOME desktops have a NM applet that gets confused if you're using
systemd-networkd.  I still feel like systemd-networkd is a lot less
convoluted than NetworkManager.

https://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[isdtor]

Leroy Tennison writes:
> Another huge concern: It breaks, someone else has to fix it because it's in 
> the C source - after it reaches a high enough priority.  At least with 
> scripts you could conceivably hack it.  From what I've read there is some 
> ability to get systemd to defer to a script, I'm going to have to become an 
> expert at that.

Best of both worlds - power-grabbing systemd plus convoluted init scripts.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[James B. Byrne]

On Sun, April 9, 2017 00:39, Anthony K wrote:
> According to "Arthur Schopenhauer":
>
> "All truth passes through three stages.
>  First, it is ridiculed.
>  Second, it is violently opposed.
>  Third, it is accepted as being self-evident."
>
> I must admit that I skipped through the first and second stages - I
> never found creating init scripts a joy and instead opted to write my
> own scripts that I launched via inittab.  As such, I welcomed the
> simplicity systemd's service files without fuss.
>
> So, at which stage are you in w/ regards to adopting systemd?  Are you
> still ridiculing it, violently opposed to it, or have you mellowed to
> it?
>

A. FreeBSD-11.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Leroy Tennison]

Another huge concern: It breaks, someone else has to fix it because it's in the 
C source - after it reaches a high enough priority.  At least with scripts you 
could conceivably hack it.  From what I've read there is some ability to get 
systemd to defer to a script, I'm going to have to become an expert at that.

- Original Message -
From: "Bruce Ferrell" 
To: "centos" 
Sent: Monday, April 10, 2017 7:13:55 PM
Subject: Re: [CentOS] OT: systemd Poll

On 04/10/2017 03:20 PM, Pete Biggs wrote:
>> I must admit that I skipped through the first and second stages - I
>> never found creating init scripts a joy and instead opted to write my
>> own scripts that I launched via inittab.  As such, I welcomed the
>> simplicity systemd's service files without fuss.
>>
>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>> still ridiculing it, violently opposed to it, or have you mellowed to it?
>>
> It is what it is.
>
> I can see that systemd may not look as straightforward as init scripts,
> but it has been clear for a while that SysVinit is generally not really
> fit-for-purpose. Things like the mystic incantations embedded in
> comments at the top to try and make chkconfig work properly, or the
> lack of a consistent approach to configuring parameters (are they
> embedded in the script? In /etc/sysconfig? The package's own config
> files?).
>
> The fact that there was at one point multiple solutions to the problem
> (with systemd eventually becoming the accepted one) and that no dev is
> really going to voluntarily go through the pain and abuse of
> implementing something new like this shows that it really was thought
> to be necessary.
>
> I think what is/was the issue is the abrasive way that some of it was
> done. It seems to have put people's backs up no end and makes them
> predisposed to find fault with it.
>
> It's just different, that's all. It does the job it was designed to do.
> It even copes with legacy init scripts, so you can still use them if
> you want.
>
> And I remember when these new fangled init scripts first appeared - boy
> did everyone find them confusing and hated them.
>
> P.
>

My first *IX system had only /etc/inittab and I had to manually add and 
configure inetd. Next generation used the bsd init system... Monolithic.  No 
process start/stop, but I 
understood it. Then SystemV came along; Individual processes could be started, 
stopped, and queried. The came the function file and THAT was a complete 
mess... Every distro 
developer had his own idea of what functions were needed.

In all three of those cases, there was a single, simple start up entity.  That 
was the literal binary program init.  It read /etc/inittab and used that to 
handle process management 
and those management processes were completely transparent.  Standardized, well 
known locations were used.  It was considered to be a not just good practice, 
but excellent practice 
to do so.  It wasn't commonly done, but it was relatively simple to swap 
between them too.

The current crop of system initialization systems, do everything possible to 
obscure the details of operation...  Boot status on the console?  Nope, 
obscured. Processes logged to 
standard places? Nope, someone might hijack the logs (we had a technique for 
that... remote logging, but that isn't important enough to make work... Too 
much trouble).

The bottom line seems to be, "I've looked at this, and I know better than 20, 
30 years of experience, so throw it all out and do it my way"... And if things 
get broken in the 
process... Oh well, that's progress.

I've had my init system lose communication with the desktop gui and decide to 
reboot my system.  Yes, systemd did that.  dbus got an upgrade and was 
restarting so systemd rebooted 
my system.

While not directly a systemd problem, I've haddistro builds of apache that 
didn't work because of some patch "needed" so systemd could manage apache (We 
need systemd hooked so 
deeply into every process now?!).  Yes, each of these was corrected... But they 
didn't need to happen and NEVER happened with earlier init systems.

The concepts in upstart, launchd, and systemd are mildly interesting to me and 
probably more so to others.  The implementations of the ideas have been poorly 
thought out and 
tested. They cause so much trouble for me as to make them worthless to me. When 
complaints are registered, the response has often been "if we don't force it, 
it will never be 
tested".  Completely unacceptable.

This is MY issue with the new shiny toy.  Heedless and needless system breakage 
by an escaped lab rat.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Leroy Tennison]

And to add to the issues concerning consistency, what if you have a fail over 
unit and you're replicating configuration (i.e. NIC), you really prefer that 
NIC names remain the same.  Given the hardware morass underneath all of this, 
the only safe choice (regardless of whether you use systemd, init scripts, 
whatever) is to take control and force the association of the name to the MAC 
address in the appropriate file.  It doesn't allow total configuration 
replication but it does allow enough (with judicious use of segregation) to be 
useful.

This does concern me, another post referred to the heavy-handed way in which 
systemd has been implemented and I totally agree.  "You will conform" - no 
exceptions.  What I fear is that we will lose the ability to control the name, 
MAC address association at some future point because "no one needs to do that" 
(speaking from their ivory tower).


- Original Message -
From: "John R Pierce" 
To: "centos" 
Sent: Monday, April 10, 2017 4:36:48 PM
Subject: Re: [CentOS] OT: systemd Poll

On 4/10/2017 2:27 PM, Valeri Galtsev wrote:
> Without intent to contradict... I really would prefer them numbered
> according to their bus address. Not in the order (or reverse order - as it
> was once) of them been discovered. And if you add hardware with bus
> address between those of eth0 and eth1, you will have newly added one
> become eth1, and former eth1 becomes eth2. I know, it stems from old
> idiotic habit to always look inside the boxes... call me an old UNIX
> outcast. (No, don't, that would be a complement I unlikely deserve


bus address is a somewhat nebulous concept on PCI, afaik, its not 
neccessarily slot specific.   its even messier on things like USB


-- 
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[isdtor]

> er, I meant to add that the 09: seems to correspond with the enp9s* and the
> 0a: seems to correspond with the enp10s*

I wrote myself a little script that uses /sys/class/net, ethtool and lspci to 
identify which interface corresponds to which bus slot/lspci entry.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Alice Wonder]

On 04/11/2017 05:39 AM, Alice Wonder wrote:

On 04/11/2017 05:30 AM, Jonathan Billings wrote:

On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:

And *why* random NIC names? Quick, you've got servers from 5
manufacturers, of different ages... what's the NIC going to be
called? Do
names like enp5s0 offer any convenience to *anyone* not a hardware
engineer?


As someone else had stated, it's not related to SystemD but
Fedora/RHEL has changed the way they handle some things.  NICs, for
instance, are no longer named after the device number (eth0, eth1,
eth2, etc.) but after the *driver* name.  Yes, it's a change but it
also makes sense.  IIRC this is how FreeBSD handles NIC names.


It's true that FreeBSD names their network interfaces after the driver.

But the consistent device naming in Linux comes from slot index
numbers, physical location and even the MAC (if so configured), and
not what driver it uses.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html#sec-Naming_Schemes_Hierarchy




Okay that makes sense.

eno1: flags=4099  mtu 1500
ether 0c:c4:7a:c8:a5:4c  txqueuelen 1000  (Ethernet)
eno2: flags=4099  mtu 1500
ether 0c:c4:7a:c8:a5:4d  txqueuelen 1000  (Ethernet)

Those two are my onboard nic, Intel - Scheme 1

enp10s0f0: flags=4099  mtu 1500
ether 00:1b:21:94:72:37  txqueuelen 1000  (Ethernet)
enp10s0f1: flags=4099  mtu 1500
ether 00:1b:21:94:72:36  txqueuelen 1000  (Ethernet)
enp9s0f0: flags=4099  mtu 1500
ether 00:1b:21:94:72:35  txqueuelen 1000  (Ethernet)
enp9s0f1: flags=4099  mtu 1500

Those four are on a PCI-E card, Intel - Scheme 3

05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
09:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)
0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (Copper) (rev 06)

Anyway thanks for that link.


er, I meant to add that the 09: seems to correspond with the enp9s* and 
the 0a: seems to correspond with the enp10s*


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Alice Wonder]

On 04/11/2017 05:30 AM, Jonathan Billings wrote:

On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:

And *why* random NIC names? Quick, you've got servers from 5
manufacturers, of different ages... what's the NIC going to be called? Do
names like enp5s0 offer any convenience to *anyone* not a hardware
engineer?


As someone else had stated, it's not related to SystemD but
Fedora/RHEL has changed the way they handle some things.  NICs, for
instance, are no longer named after the device number (eth0, eth1,
eth2, etc.) but after the *driver* name.  Yes, it's a change but it
also makes sense.  IIRC this is how FreeBSD handles NIC names.


It's true that FreeBSD names their network interfaces after the driver.

But the consistent device naming in Linux comes from slot index
numbers, physical location and even the MAC (if so configured), and
not what driver it uses.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html#sec-Naming_Schemes_Hierarchy



Okay that makes sense.

eno1: flags=4099  mtu 1500
ether 0c:c4:7a:c8:a5:4c  txqueuelen 1000  (Ethernet)
eno2: flags=4099  mtu 1500
ether 0c:c4:7a:c8:a5:4d  txqueuelen 1000  (Ethernet)

Those two are my onboard nic, Intel - Scheme 1

enp10s0f0: flags=4099  mtu 1500
ether 00:1b:21:94:72:37  txqueuelen 1000  (Ethernet)
enp10s0f1: flags=4099  mtu 1500
ether 00:1b:21:94:72:36  txqueuelen 1000  (Ethernet)
enp9s0f0: flags=4099  mtu 1500
ether 00:1b:21:94:72:35  txqueuelen 1000  (Ethernet)
enp9s0f1: flags=4099  mtu 1500

Those four are on a PCI-E card, Intel - Scheme 3

05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network 
Connection (rev 03)
06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network 
Connection (rev 03)
09:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
09:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
0a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)
0a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet 
Controller (Copper) (rev 06)


Anyway thanks for that link.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Pete Orrall]

> But the consistent device naming in Linux comes from slot index
> numbers, physical location and even the MAC (if so configured), and
> not what driver it uses.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html#sec-Naming_Schemes_Hierarchy

Thanks for the clarification, John.  I will check this out.

-- 
Pete Orrall
p...@cs1x.com
www.peteorrall.com
"If there isn't a way, I'll make one."
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Jonathan Billings]

On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:
> > And *why* random NIC names? Quick, you've got servers from 5
> > manufacturers, of different ages... what's the NIC going to be called? Do
> > names like enp5s0 offer any convenience to *anyone* not a hardware
> > engineer?
> 
> As someone else had stated, it's not related to SystemD but
> Fedora/RHEL has changed the way they handle some things.  NICs, for
> instance, are no longer named after the device number (eth0, eth1,
> eth2, etc.) but after the *driver* name.  Yes, it's a change but it
> also makes sense.  IIRC this is how FreeBSD handles NIC names.

It's true that FreeBSD names their network interfaces after the driver.

But the consistent device naming in Linux comes from slot index
numbers, physical location and even the MAC (if so configured), and
not what driver it uses.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html#sec-Naming_Schemes_Hierarchy

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Scott Robbins]

On Tue, Apr 11, 2017 at 08:09:01AM -0400, Pete Orrall wrote:
> > And *why* random NIC names? Quick, you've got servers from 5
> > manufacturers, of different ages... what's the NIC going to be called? Do
> > names like enp5s0 offer any convenience to *anyone* not a hardware
> > engineer?
> 
> As someone else had stated, it's not related to SystemD but
> Fedora/RHEL has changed the way they handle some things.  NICs, for
> instance, are no longer named after the device number (eth0, eth1,
> eth2, etc.) but after the *driver* name.  Yes, it's a change but it
> also makes sense.  IIRC this is how FreeBSD handles NIC names.

FreeBSD uses the driver in the name, such as bge0, em0, and so on, as
opposed to bge0 or em0, depending upon the make of the card.


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Pete Orrall]

> And *why* random NIC names? Quick, you've got servers from 5
> manufacturers, of different ages... what's the NIC going to be called? Do
> names like enp5s0 offer any convenience to *anyone* not a hardware
> engineer?

As someone else had stated, it's not related to SystemD but
Fedora/RHEL has changed the way they handle some things.  NICs, for
instance, are no longer named after the device number (eth0, eth1,
eth2, etc.) but after the *driver* name.  Yes, it's a change but it
also makes sense.  IIRC this is how FreeBSD handles NIC names.

-- 
Pete Orrall
p...@cs1x.com
www.peteorrall.com
"If there isn't a way, I'll make one."
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[me]

On Tue, 11 Apr 2017, ken wrote:

And I have to wonder, why in /usr/lib/systemd/system/ is there a file named 
-.slice ??  Didn't anyone see a problem with this...? or countless possible 
problems?  Doesn't instill confidence.


Well wonder no more!! Simply look it up in the man pages. It is documented
after all!!

Hummm, lets see: 
(vcliff pts2) # grep Documentation= /usr/lib/systemd/system/-.slice

Documentation=man:systemd.special(7)
(vcliff pts2) #

I will let you do the rest of the research yourself. :-)

Regards,

--
Tom m...@tdiehl.org Spamtrap address
me...@tdiehl.org

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[ken]

On 04/10/2017 08:13 PM, Bruce Ferrell wrote:

On 04/10/2017 03:20 PM, Pete Biggs wrote:

I must admit that I skipped through the first and second stages - I
never found creating init scripts a joy and instead opted to write my
own scripts that I launched via inittab.  As such, I welcomed the
simplicity systemd's service files without fuss.

So, at which stage are you in w/ regards to adopting systemd? Are you
still ridiculing it, violently opposed to it, or have you mellowed 
to it?



It is what it is.

I can see that systemd may not look as straightforward as init scripts,
but it has been clear for a while that SysVinit is generally not really
fit-for-purpose. Things like the mystic incantations embedded in
comments at the top to try and make chkconfig work properly, or the
lack of a consistent approach to configuring parameters (are they
embedded in the script? In /etc/sysconfig? The package's own config
files?).

The fact that there was at one point multiple solutions to the problem
(with systemd eventually becoming the accepted one) and that no dev is
really going to voluntarily go through the pain and abuse of
implementing something new like this shows that it really was thought
to be necessary.

I think what is/was the issue is the abrasive way that some of it was
done. It seems to have put people's backs up no end and makes them
predisposed to find fault with it.

It's just different, that's all. It does the job it was designed to do.
It even copes with legacy init scripts, so you can still use them if
you want.

And I remember when these new fangled init scripts first appeared - boy
did everyone find them confusing and hated them.

P.



My first *IX system had only /etc/inittab and I had to manually add 
and configure inetd. Next generation used the bsd init system... 
Monolithic.  No process start/stop, but I understood it. Then SystemV 
came along; Individual processes could be started, stopped, and 
queried. The came the function file and THAT was a complete mess... 
Every distro developer had his own idea of what functions were needed.


In all three of those cases, there was a single, simple start up 
entity.  That was the literal binary program init.  It read 
/etc/inittab and used that to handle process management and those 
management processes were completely transparent.  Standardized, well 
known locations were used.  It was considered to be a not just good 
practice, but excellent practice to do so.  It wasn't commonly done, 
but it was relatively simple to swap between them too.


The current crop of system initialization systems, do everything 
possible to obscure the details of operation...  Boot status on the 
console?  Nope, obscured. Processes logged to standard places? Nope, 
someone might hijack the logs (we had a technique for that... remote 
logging, but that isn't important enough to make work... Too much 
trouble).


The bottom line seems to be, "I've looked at this, and I know better 
than 20, 30 years of experience, so throw it all out and do it my 
way"... And if things get broken in the process... Oh well, that's 
progress.


I've had my init system lose communication with the desktop gui and 
decide to reboot my system.  Yes, systemd did that.  dbus got an 
upgrade and was restarting so systemd rebooted my system.


While not directly a systemd problem, I've haddistro builds of apache 
that didn't work because of some patch "needed" so systemd could 
manage apache (We need systemd hooked so deeply into every process 
now?!).  Yes, each of these was corrected... But they didn't need to 
happen and NEVER happened with earlier init systems.


The concepts in upstart, launchd, and systemd are mildly interesting 
to me and probably more so to others.  The implementations of the 
ideas have been poorly thought out and tested. They cause so much 
trouble for me as to make them worthless to me. When complaints are 
registered, the response has often been "if we don't force it, it will 
never be tested". Completely unacceptable.


This is MY issue with the new shiny toy.  Heedless and needless system 
breakage by an escaped lab rat. 


And I have to wonder, why in /usr/lib/systemd/system/ is there a file 
named -.slice ??  Didn't anyone see a problem with this...? or countless 
possible problems?  Doesn't instill confidence.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Bruce Ferrell]

On 04/10/2017 03:20 PM, Pete Biggs wrote:

I must admit that I skipped through the first and second stages - I
never found creating init scripts a joy and instead opted to write my
own scripts that I launched via inittab.  As such, I welcomed the
simplicity systemd's service files without fuss.

So, at which stage are you in w/ regards to adopting systemd?  Are you
still ridiculing it, violently opposed to it, or have you mellowed to it?


It is what it is.

I can see that systemd may not look as straightforward as init scripts,
but it has been clear for a while that SysVinit is generally not really
fit-for-purpose. Things like the mystic incantations embedded in
comments at the top to try and make chkconfig work properly, or the
lack of a consistent approach to configuring parameters (are they
embedded in the script? In /etc/sysconfig? The package's own config
files?).

The fact that there was at one point multiple solutions to the problem
(with systemd eventually becoming the accepted one) and that no dev is
really going to voluntarily go through the pain and abuse of
implementing something new like this shows that it really was thought
to be necessary.

I think what is/was the issue is the abrasive way that some of it was
done. It seems to have put people's backs up no end and makes them
predisposed to find fault with it.

It's just different, that's all. It does the job it was designed to do.
It even copes with legacy init scripts, so you can still use them if
you want.

And I remember when these new fangled init scripts first appeared - boy
did everyone find them confusing and hated them.

P.



My first *IX system had only /etc/inittab and I had to manually add and configure inetd. Next generation used the bsd init system... Monolithic.  No process start/stop, but I 
understood it. Then SystemV came along; Individual processes could be started, stopped, and queried. The came the function file and THAT was a complete mess... Every distro 
developer had his own idea of what functions were needed.


In all three of those cases, there was a single, simple start up entity.  That was the literal binary program init.  It read /etc/inittab and used that to handle process management 
and those management processes were completely transparent.  Standardized, well known locations were used.  It was considered to be a not just good practice, but excellent practice 
to do so.  It wasn't commonly done, but it was relatively simple to swap between them too.


The current crop of system initialization systems, do everything possible to obscure the details of operation...  Boot status on the console?  Nope, obscured. Processes logged to 
standard places? Nope, someone might hijack the logs (we had a technique for that... remote logging, but that isn't important enough to make work... Too much trouble).


The bottom line seems to be, "I've looked at this, and I know better than 20, 30 years of experience, so throw it all out and do it my way"... And if things get broken in the 
process... Oh well, that's progress.


I've had my init system lose communication with the desktop gui and decide to reboot my system.  Yes, systemd did that.  dbus got an upgrade and was restarting so systemd rebooted 
my system.


While not directly a systemd problem, I've haddistro builds of apache that didn't work because of some patch "needed" so systemd could manage apache (We need systemd hooked so 
deeply into every process now?!).  Yes, each of these was corrected... But they didn't need to happen and NEVER happened with earlier init systems.


The concepts in upstart, launchd, and systemd are mildly interesting to me and probably more so to others.  The implementations of the ideas have been poorly thought out and 
tested. They cause so much trouble for me as to make them worthless to me. When complaints are registered, the response has often been "if we don't force it, it will never be 
tested".  Completely unacceptable.


This is MY issue with the new shiny toy.  Heedless and needless system breakage 
by an escaped lab rat.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[John R Pierce]

On 4/10/2017 3:20 PM, Pete Biggs wrote:

And I remember when these new fangled init scripts first appeared - boy
did everyone find them confusing and hated them.


indeed.   BSD just used /etc/rc.conf and /etc/rc.d/{servicename} 
then AT&T SystemV came along with the whole levels and init.d and 
everything.






--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Pete Biggs]

> I must admit that I skipped through the first and second stages - I 
> never found creating init scripts a joy and instead opted to write my 
> own scripts that I launched via inittab.  As such, I welcomed the 
> simplicity systemd's service files without fuss.
> 
> So, at which stage are you in w/ regards to adopting systemd?  Are you 
> still ridiculing it, violently opposed to it, or have you mellowed to it?
> 

It is what it is.

I can see that systemd may not look as straightforward as init scripts,
but it has been clear for a while that SysVinit is generally not really
fit-for-purpose. Things like the mystic incantations embedded in
comments at the top to try and make chkconfig work properly, or the
lack of a consistent approach to configuring parameters (are they
embedded in the script? In /etc/sysconfig? The package's own config
files?).

The fact that there was at one point multiple solutions to the problem
(with systemd eventually becoming the accepted one) and that no dev is
really going to voluntarily go through the pain and abuse of
implementing something new like this shows that it really was thought
to be necessary.

I think what is/was the issue is the abrasive way that some of it was
done. It seems to have put people's backs up no end and makes them
predisposed to find fault with it.

It's just different, that's all. It does the job it was designed to do.
It even copes with legacy init scripts, so you can still use them if
you want.

And I remember when these new fangled init scripts first appeared - boy
did everyone find them confusing and hated them.

P.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[John R Pierce]

On 4/10/2017 2:27 PM, Valeri Galtsev wrote:

Without intent to contradict... I really would prefer them numbered
according to their bus address. Not in the order (or reverse order - as it
was once) of them been discovered. And if you add hardware with bus
address between those of eth0 and eth1, you will have newly added one
become eth1, and former eth1 becomes eth2. I know, it stems from old
idiotic habit to always look inside the boxes... call me an old UNIX
outcast. (No, don't, that would be a complement I unlikely deserve



bus address is a somewhat nebulous concept on PCI, afaik, its not 
neccessarily slot specific.   its even messier on things like USB



--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[m . roth]

John R Pierce wrote:
> On 4/10/2017 1:57 PM, m.r...@5-cent.us wrote:
>> In what universe are those "consistant" device names, as opposed to
>> eth[0...]? And how could it help automated scripts that you can run on
>> *any*  system you're administering?
>
> if I have a Intel gigE interface and a Marvell 10g interfaces, which one
> is eth0 and why?
>
> Say its Intel on eth0 and Marvell on eth1, if I then add another intel,
> is the Marvell now eth2 ?
>
And if I have a 5-yr-old Penguin (OEM-branded Supermicro), and a Dell
PowerEdge R530 and an HP ProLiant dl580 and a hot-off-the-presses
Penguin/Intel, what will their primary device be named?

As opposed to you installing a new NIC in addition to one that's there...
which, since you've just installed it, I suppose you could add the UUID to
whatever you want to name it.

mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Mon, April 10, 2017 4:17 pm, John R Pierce wrote:
> On 4/10/2017 1:57 PM, m.r...@5-cent.us wrote:
>> In what universe are those "consistant" device names, as opposed to
>> eth[0...]? And how could it help automated scripts that you can run on
>> *any*  system you're administering?
>
> if I have a Intel gigE interface and a Marvell 10g interfaces, which one
> is eth0 and why?
>
> Say its Intel on eth0 and Marvell on eth1, if I then add another intel,
> is the Marvell now eth2 ?
>

Without intent to contradict... I really would prefer them numbered
according to their bus address. Not in the order (or reverse order - as it
was once) of them been discovered. And if you add hardware with bus
address between those of eth0 and eth1, you will have newly added one
become eth1, and former eth1 becomes eth2. I know, it stems from old
idiotic habit to always look inside the boxes... call me an old UNIX
outcast. (No, don't, that would be a complement I unlikely deserve ;-)

Valeri

>
> --
> john r pierce, recycling bits in santa cruz
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[John R Pierce]

On 4/10/2017 1:57 PM, m.r...@5-cent.us wrote:

In what universe are those "consistant" device names, as opposed to
eth[0...]? And how could it help automated scripts that you can run on
*any*  system you're administering?


if I have a Intel gigE interface and a Marvell 10g interfaces, which one 
is eth0 and why?


Say its Intel on eth0 and Marvell on eth1, if I then add another intel, 
is the Marvell now eth2 ?



--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[m . roth]

Jonathan Billings wrote:

>> And *why* random NIC names? Quick, you've got servers from 5
>> manufacturers, of different ages... what's the NIC going to be called?
>> Do names like enp5s0 offer any convenience to *anyone* not a hardware
>> engineer?
>
> Unrelated to systemd.  This actually started happening in RHEL6 with
> the biosdevname feature.  systemd can handle the NIC naming stuff, but
> it started happening well before systemd appeared in RHEL.
>
> Having consistent device names is helpful when you've got more than
> one NIC and you don't want to rely on the order in which the network
> driver is loaded to define the interface name.

In what universe are those "consistant" device names, as opposed to
eth[0...]? And how could it help automated scripts that you can run on
*any* system you're administering?

mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Nicolas Kovacs]

Le 10/04/2017 à 21:57, Jonathan Billings a écrit :
> Having consistent device names is helpful when you've got more than
> one NIC and you don't want to rely on the order in which the network
> driver is loaded to define the interface name.

On my Slackware servers (no systemd, no funny network interface names),
I just edit /etc/udev/rules.d/70-persistent-net.rules and switch eth0
and eth1 (and eth2 etc.) if needed.

Keep It Simple.


-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Web  : http://www.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Jonathan Billings]

I know this is systemd-punching day, but at least get your information
straight.  


On Mon, Apr 10, 2017 at 03:38:03PM -0400, m.r...@5-cent.us wrote:
>Why change names, such as rpc-idmapd to
> nfs-idmapd?

Unrelated to systemd, as far as I can tell.  Fedora adopted new names
that made more sense, and it was incorporated into RHEL7.

>And I've just been fighting today, because I have to munge the
> MAC address for a workstation, because they have old software that is very
> usefull, and there's no budget to pay the company that bought the software
> $15k (no kidding) so that they can shift the license to the new
> workstation, and that's tied to eth0 and the MAC.
> 
> And *why* random NIC names? Quick, you've got servers from 5
> manufacturers, of different ages... what's the NIC going to be called? Do
> names like enp5s0 offer any convenience to *anyone* not a hardware
> engineer?

Unrelated to systemd.  This actually started happening in RHEL6 with
the biosdevname feature.  systemd can handle the NIC naming stuff, but
it started happening well before systemd appeared in RHEL.

Having consistent device names is helpful when you've got more than
one NIC and you don't want to rely on the order in which the network
driver is loaded to define the interface name.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[m . roth]

Pete Orrall wrote:
>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>> still
>> ridiculing it, violently opposed to it, or have you mellowed to it?
>
> I've never had to write my own init scripts before so I'm not feeling
> the pain of others, but having professionally managed machines running
> SystemD for a while now honestly I don't mind it.  While the language
> used (units, targets) is confusing and documentation could be better,
> there are some things I like about it more than SysVInit.
>
Don't look at me - I still *loathe* systemd. Change for no other reason
than to put it on your resume, and write papers about.

Examples: is it service, or target, and where of many places do I have to
look to find a given service name? Why change names, such as rpc-idmapd to
nfs-idmapd? And I've just been fighting today, because I have to munge the
MAC address for a workstation, because they have old software that is very
usefull, and there's no budget to pay the company that bought the software
$15k (no kidding) so that they can shift the license to the new
workstation, and that's tied to eth0 and the MAC.

And *why* random NIC names? Quick, you've got servers from 5
manufacturers, of different ages... what's the NIC going to be called? Do
names like enp5s0 offer any convenience to *anyone* not a hardware
engineer?

And the binary message log At home, I'm staying on CentOS 6 until it
EoLs.

mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Jonathan Billings]

On Sun, Apr 09, 2017 at 09:30:20AM +0100, J Martin Rushton wrote:
> For those of us with (in my case) over 30 years in the industry, reading
> init scripts is trivial and at least we can see what is going on and fix
> problems quickly.

As someone who has both debugged and written many init scripts, I'm a
big fan of the way systemd does things.  Every distro provided their
own shell functions, so you ended up with a debian init script, a
redhat init script, and usually some weird "kinda works everywhere"
init script that used neither and reinvented the wheel.

Quite often, what was going wrong was *NOT* apparent by glancing at
the init script.  How do you enforce limits on the service?  Run
ulimits in the script?  The service starts fine if you run
'/etc/rc.d/init.d/myservice start', but then if you run
'service myservice start', it fails.  On top of that, there's no
journal so you can't even *SEE* why it is failing during boot unless
it is kind enough to write an error to the console.  Hope you have a
crash cart!

Also, how configurable is the init script?  You had to hope that
upstream was smart enough to use environment variables that were
sourced from /etc/sysconfig/servicename.  Sometimes I had to do evil
things like put executable code into /etc/sysconfig/servicename which
fixed problems with the init script.

Also, that reminds me, there's no simple way to override some or all
of a packaged init script, except to provide your own alternative init
script that had a different name.  And don't get me started on the
terrible startup sequence rules.  I've seen several people who have
edited the init script itself and then had it replaced by a yum
update, breaking their service.  The RPMs don't mark the init script
as a config file.

>  Some vague, poorly documented, data file which is
> interpreted by a black box is the sort of joy one expects from the
> murkier regions of Redmond not the sunnier climes of Carolina.

I don't know... I find the unit syntax pretty simple to read.  It says
what processes are going to be run, what user it'll run under, you can
see what order it wants to be run, etc.  There are dozens of man pages
for systemd, each with examples.

Don't get me wrong, I have a lot of anger about some of the stuff that
systemd does.  But lets not reminisce about SysVinit as if it was
anything but a horrible mess.  systemd's best feature is that it
finally makes managing services better.

-- 
Jonathan Billings 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Chris Adams]

Once upon a time, Pete Orrall  said:
> > So, at which stage are you in w/ regards to adopting systemd?  Are you still
> > ridiculing it, violently opposed to it, or have you mellowed to it?
> 
> I've never had to write my own init scripts before so I'm not feeling
> the pain of others, but having professionally managed machines running
> SystemD for a while now honestly I don't mind it.  While the language
> used (units, targets) is confusing and documentation could be better,
> there are some things I like about it more than SysVInit.

Yeah, the old init script setup was sorely lacking in some areas
(especially dependencies).  While there were well-written init scripts
that were easy to understand, had plenty of configuration options, etc.,
there were many that were largely unreadable.

I like to distinguish systemd-the-pid-1 from systemd-the-project; I
generally like systemd-the-pid-1 (it isn't perfect by any means, but I
think it is an improvement).  On the other hand, I dislike the scope
creep and "replace all the wheels" approach of systemd-the-project.

-- 
Chris Adams 
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Keith Keller]

On 2017-04-10, Valeri Galtsev  wrote:
>
> The same here. Could repeat that word for word. I fled what I could to
> FreeBSD, but in that process systemd was just the last drop that confirmed
> that my earlier decision to abandon Linux to the extent I can was right.
> Whatever has to stay Linux sucks ... more time for any problem than it
> used to.

FWIW this is a distro issue, not a Linux issue.  Slackware still has not
switched to systemd IIRC.  I would imagine there are other distros that
haven't switched (yet).

--keith

-- 
kkel...@wombat.san-francisco.ca.us


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Pete Orrall]

> So, at which stage are you in w/ regards to adopting systemd?  Are you still
> ridiculing it, violently opposed to it, or have you mellowed to it?

I've never had to write my own init scripts before so I'm not feeling
the pain of others, but having professionally managed machines running
SystemD for a while now honestly I don't mind it.  While the language
used (units, targets) is confusing and documentation could be better,
there are some things I like about it more than SysVInit.

-- 
Pete Orrall
p...@cs1x.com
www.peteorrall.com
"If there isn't a way, I'll make one."
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Alice Wonder]

On 04/08/2017 09:39 PM, Anthony K wrote:

According to "Arthur Schopenhauer":

"All truth passes through three stages.
First, it is ridiculed.
Second, it is violently opposed.
Third, it is accepted as being self-evident."

I must admit that I skipped through the first and second stages - I
never found creating init scripts a joy and instead opted to write my
own scripts that I launched via inittab.  As such, I welcomed the
simplicity systemd's service files without fuss.

So, at which stage are you in w/ regards to adopting systemd?  Are you
still ridiculing it, violently opposed to it, or have you mellowed to it?



I am using systemd, don't really have a problem with it.

It was different at first but so far I manage to have adjusted.

It's different. For better or worse I can't say, but I can do what I 
need to do with it.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Leroy Tennison]

Like you, I have been looking for alternatives to Linux due to systemd, 
SELinux, desktop environments gone way off course, etc.  What can and can't be 
replaced with FreeBSD or other alternatives (and why)?

- Original Message -
From: "Valeri Galtsev" 
To: "centos" 
Sent: Monday, April 10, 2017 8:38:03 AM
Subject: Re: [CentOS] OT: systemd Poll

On Mon, April 10, 2017 7:29 am, Steve Clark wrote:
> On 04/09/2017 04:30 AM, J Martin Rushton wrote:
>> On 09/04/17 05:39, Anthony K wrote:
>>> According to "Arthur Schopenhauer":
>>>
>>> "All truth passes through three stages.
>>>     First, it is ridiculed.
>>>     Second, it is violently opposed.
>>>     Third, it is accepted as being self-evident."
>> All ideas, true or false, follow those stages, but one hopes that the
>> false ones are eventually derided and toppled.
>>
>>
>>> I must admit that I skipped through the first and second stages - I
>>> never found creating init scripts a joy and instead opted to write my
>>> own scripts that I launched via inittab.  As such, I welcomed the
>>> simplicity systemd's service files without fuss.
>>>
>>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>>> still ridiculing it, violently opposed to it, or have you mellowed to
>>> it?
>>>
>> Accepting it as a fait accompli.  It makes life much harder for no
>> obvious gain, but short of creating one's own distro we seem to be stuck
>> with it.  To answer your question, a combination of proposition 1 and
>> the first part of proposition 3.
>>
>> For those of us with (in my case) over 30 years in the industry, reading
>> init scripts is trivial and at least we can see what is going on and fix
>> problems quickly.  Some vague, poorly documented, data file which is
>> interpreted by a black box is the sort of joy one expects from the
>> murkier regions of Redmond not the sunnier climes of Carolina.
>>

The same here. Could repeat that word for word. I fled what I could to
FreeBSD, but in that process systemd was just the last drop that confirmed
that my earlier decision to abandon Linux to the extent I can was right.
Whatever has to stay Linux sucks ... more time for any problem than it
used to.

Valeri

>>
> +1
>>
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
>
> --
> Stephen Clark
> *NetWolves Managed Services, LLC.*
> Director of Technology
> Phone: 813-579-3200
> Fax: 813-882-0209
> Email: steve.cl...@netwolves.com
> http://www.netwolves.com
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Valeri Galtsev]

On Mon, April 10, 2017 7:29 am, Steve Clark wrote:
> On 04/09/2017 04:30 AM, J Martin Rushton wrote:
>> On 09/04/17 05:39, Anthony K wrote:
>>> According to "Arthur Schopenhauer":
>>>
>>> "All truth passes through three stages.
>>> First, it is ridiculed.
>>> Second, it is violently opposed.
>>> Third, it is accepted as being self-evident."
>> All ideas, true or false, follow those stages, but one hopes that the
>> false ones are eventually derided and toppled.
>>
>>
>>> I must admit that I skipped through the first and second stages - I
>>> never found creating init scripts a joy and instead opted to write my
>>> own scripts that I launched via inittab.  As such, I welcomed the
>>> simplicity systemd's service files without fuss.
>>>
>>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>>> still ridiculing it, violently opposed to it, or have you mellowed to
>>> it?
>>>
>> Accepting it as a fait accompli.  It makes life much harder for no
>> obvious gain, but short of creating one's own distro we seem to be stuck
>> with it.  To answer your question, a combination of proposition 1 and
>> the first part of proposition 3.
>>
>> For those of us with (in my case) over 30 years in the industry, reading
>> init scripts is trivial and at least we can see what is going on and fix
>> problems quickly.  Some vague, poorly documented, data file which is
>> interpreted by a black box is the sort of joy one expects from the
>> murkier regions of Redmond not the sunnier climes of Carolina.
>>

The same here. Could repeat that word for word. I fled what I could to
FreeBSD, but in that process systemd was just the last drop that confirmed
that my earlier decision to abandon Linux to the extent I can was right.
Whatever has to stay Linux sucks ... more time for any problem than it
used to.

Valeri

>>
> +1
>>
>>
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
>
> --
> Stephen Clark
> *NetWolves Managed Services, LLC.*
> Director of Technology
> Phone: 813-579-3200
> Fax: 813-882-0209
> Email: steve.cl...@netwolves.com
> http://www.netwolves.com
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Steve Clark]

On 04/09/2017 04:30 AM, J Martin Rushton wrote:
> On 09/04/17 05:39, Anthony K wrote:
>> According to "Arthur Schopenhauer":
>>
>> "All truth passes through three stages.
>> First, it is ridiculed.
>> Second, it is violently opposed.
>> Third, it is accepted as being self-evident."
> All ideas, true or false, follow those stages, but one hopes that the
> false ones are eventually derided and toppled.
>
>
>> I must admit that I skipped through the first and second stages - I
>> never found creating init scripts a joy and instead opted to write my
>> own scripts that I launched via inittab.  As such, I welcomed the
>> simplicity systemd's service files without fuss.
>>
>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>> still ridiculing it, violently opposed to it, or have you mellowed to it?
>>
> Accepting it as a fait accompli.  It makes life much harder for no
> obvious gain, but short of creating one's own distro we seem to be stuck
> with it.  To answer your question, a combination of proposition 1 and
> the first part of proposition 3.
>
> For those of us with (in my case) over 30 years in the industry, reading
> init scripts is trivial and at least we can see what is going on and fix
> problems quickly.  Some vague, poorly documented, data file which is
> interpreted by a black box is the sort of joy one expects from the
> murkier regions of Redmond not the sunnier climes of Carolina.
>
>
+1
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos


-- 
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com


signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[ken]

On 04/09/2017 04:30 AM, J Martin Rushton wrote:

On 09/04/17 05:39, Anthony K wrote:

According to "Arthur Schopenhauer":

"All truth passes through three stages.
 First, it is ridiculed.
 Second, it is violently opposed.
 Third, it is accepted as being self-evident."

All ideas, true or false, follow those stages, but one hopes that the
false ones are eventually derided and toppled.



I must admit that I skipped through the first and second stages - I
never found creating init scripts a joy and instead opted to write my
own scripts that I launched via inittab.  As such, I welcomed the
simplicity systemd's service files without fuss.

So, at which stage are you in w/ regards to adopting systemd?  Are you
still ridiculing it, violently opposed to it, or have you mellowed to it?


Accepting it as a fait accompli.  It makes life much harder for no
obvious gain, but short of creating one's own distro we seem to be stuck
with it.  To answer your question, a combination of proposition 1 and
the first part of proposition 3.

For those of us with (in my case) over 30 years in the industry, reading
init scripts is trivial and at least we can see what is going on and fix
problems quickly.  Some vague, poorly documented, data file which is
interpreted by a black box is the sort of joy one expects from the
murkier regions of Redmond not the sunnier climes of Carolina.



I agree.  I never had a problem with init scripts.  Anyone who 
understood bash/sh could fairly easily come to grips with init scripts.  
I have no idea where to look for whatever starts up services with 
systemd.  What language is systemd written in...?  no idea.  Yes, I 
tried reading docs, but they're so vague and inscrutable that I gave 
up.  E.g., what is a "unit"?  Could they have picked a word more vague?  
What does "unit" tell us which "thing" doesn't?  Basically, a service is 
either running or stopped... so what is "static"?  "Static" means the 
opposite of "moving" or "dynamic".  How does "static" describe a service?


In short, although computer geeks generally aren't known for being good 
at documentation, in the commercial world at any rate.  But this is 
GNU/Linux.  We rely on online documentation and the open source 
community to figure out problems and make improvements. Lacking sensible 
documentation, it's hard to figure out problems. If problems can't be 
figured out, we're faced with problematic systems.  And who's going to 
tolerate that for long?  How is that an improvement over Redmondware?

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Kay Schenk]

On Sun, Apr 9, 2017 at 2:20 AM, John R Pierce  wrote:

> On 4/8/2017 9:39 PM, Anthony K wrote:
>
>>
>> So, at which stage are you in w/ regards to adopting systemd?  Are you
>> still ridiculing it, violently opposed to it, or have you mellowed to it?
>>
>
> I wish the documentation was a bit better.   systemd and networkmanager
> definitely change the rules...  I had a minimal C7 VM where I had a heck of
> a time getting it to use the right DNS servers, only way I got it set up
> was to use nmtui, my attempts at using nmcli were an exercise in
> frustration.maybe this is more of a networkmanager problem more than
> systemd, but they are both tied together in my mind.
>

​Yes, lack of documentation is a big bug-a-boo in my mind also. However, I
do think working with systemd is a bit like working with udev​

​ hooks. My first experience with systemd was probably back in late 2011.
In any case, the RH documentation on it may be beneficial at this point:

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

or maybe take a look at the Fedora projects info:

https://www.freedesktop.org/wiki/Software/systemd/


>
> --
> john r pierce, recycling bits in santa cruz
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>



-- 
--
MzK

"Every time you hear a bell ring,
 it means that some angel's just got his wings."
  -- Clarence, "It's a Wonderful Life"
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[John R Pierce]

On 4/8/2017 9:39 PM, Anthony K wrote:


So, at which stage are you in w/ regards to adopting systemd?  Are you 
still ridiculing it, violently opposed to it, or have you mellowed to it? 


I wish the documentation was a bit better.   systemd and networkmanager 
definitely change the rules...  I had a minimal C7 VM where I had a heck 
of a time getting it to use the right DNS servers, only way I got it set 
up was to use nmtui, my attempts at using nmcli were an exercise in 
frustration.maybe this is more of a networkmanager problem more than 
systemd, but they are both tied together in my mind.



--
john r pierce, recycling bits in santa cruz

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: systemd Poll

[Nux!]

I'm ok with it as a init system, not much enthused by its ancillary components.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Anthony K" 
> To: "CentOS mailing list" 
> Sent: Sunday, 9 April, 2017 05:39:59
> Subject: [CentOS] OT: systemd Poll

> According to "Arthur Schopenhauer":
> 
> "All truth passes through three stages.
> First, it is ridiculed.
> Second, it is violently opposed.
> Third, it is accepted as being self-evident."
> 
> I must admit that I skipped through the first and second stages - I
> never found creating init scripts a joy and instead opted to write my
> own scripts that I launched via inittab.  As such, I welcomed the
> simplicity systemd's service files without fuss.
> 
> So, at which stage are you in w/ regards to adopting systemd?  Are you
> still ridiculing it, violently opposed to it, or have you mellowed to it?
> 
> 
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos