Re: [CentOS] Stupid C7 firewall question

[Warren Young]

On Oct 24, 2018, at 8:06 PM, Joel Freeman  wrote:
> 
> Is there any reason to use Firewalld over IPTables?

Lots: https://firewalld.org/

> I'm incredibly new to Linux administration

Given that, which would you rather type:

$ sudo firewall-cmd --add-service=ftp

or whatever that does under the hood, which probably resembles the 7 commands 
given here:

https://unix.stackexchange.com/a/93555/138

The commands given will only take effect while the system runs, so to make them 
permanent, you have to edit `/etc/sysconfig/iptables` with a somewhat different 
syntax.  

Contrast FirewallD, where you just re-issue the command above with a single 
additional flag:

$ sudo firewall-cmd --add-service=ftp --permanent

FTP is an uncommonly difficult case, but direct iptables manipulation remains 
more difficult even in the single-port case.

FirewallD doesn’t require that you use predefined services, either.  It works 
just fine with raw port numbers:

$ sudo firewall-cmd --add-port=5/tcp

Contrast the equivalent iptables command:

$ sudo iptables -A INPUT -p tcp --dport 5 -j ACCEPT

…and that only works if inserting into the INPUT chain is what you actually 
want to do, which it might not be on a system managed by FirewallD, which 
probably set up some more complicated chain scheme you’d have to understand in 
order to get the expected behavior.

Why not let FirewallD handle all of that for you?

I don’t miss direct iptables manipulation.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] No searchable archives for this mailing list?

[Warren Young]

On Oct 19, 2018, at 2:13 PM, Kay Schenk  wrote:
> 
> I can't seem to find a way to search the archives of this list

Here’s one: https://www.mail-archive.com/centos@centos.org/

Alternately, use the “site:” feature of your search engine to restrict it to 
the web archives of this list:

https://duckduckgo.com/?q=systemd+site%3Alists.centos.org%2Fpipermail%2Fcentos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

[Warren Young]

On Oct 17, 2018, at 6:55 PM, Warren Young  wrote:
> 
> I’d rather spend time advocating for and taking advantage of systemd’s 
> features than complaining about its weaknesses.
> 
> (Automatic service restarts saved me a lot of work just a few weeks ago!)

Today’s software project is going to take me all day, and it’s largely going to 
amount to reinventing systemd template units, since the software has to run on 
non-CentOS 7 boxes.  I’d be done in an hour if I could just use template units.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

[Warren Young]

On Oct 19, 2018, at 5:07 AM, Simon Matter  wrote:
> 
> - the upgrade path from EL6 to EL7 is completely broken.

Under what conditions would you actually use it?

As we can see from the repeated attempts to get a reliable in-place upgrade 
process working, the community doesn’t seem to have much interest in the idea:

   https://lists.centos.org/pipermail/centos/2018-October/170379.html

I believe this is because in-place upgrade is antithetical to the idea of a 
“stable” Linux distro in the first place.  Once something’s configured and 
running, you just want it to keep doing so.

In my world, OS upgrades are generally paired with new hardware or VMs.

I did just this on an Ubuntu VM recently, which does have an in-place upgrade 
system.  I’d been ignoring its motd offers of upgrade for years, on purpose, 
and only upgraded it from 14.04 LTS to 18.04 LTS when I needed to rebuild the 
VM anyway.

That’s why I was on an LTS release in the first place: to give me the years of 
stability that let me batch the changes up into a single big-bang upgrade.  
CentOS is even better in this regard, with version lifetimes up around 10 
years, rather than 5 for Ubuntu LTS.  One of the reasons I chose to upgrade it 
recently was because Ubuntu 14.04 is about to fall out of support, so it was 
time to move.

I believe a lot of the antipathy toward systemd is that people want “LTS” to be 
forever.  That’s not going to happen until the rest of the world stops 
changing.  That would be a very sad thing: it’s basically a wish for stagnation.

If upgrading via separate hardware or a new VM is difficult, it calls into 
question the usefulness of your backup and restore strategy.

Another advantage of this style of upgrade is that you have the prior box 
online and ready to fall back to if the manual upgrade fails.  If an in-place 
upgrade fails, you’ve just lost the primary.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upstream and downstream (was Re: What are the differences between systemd and non-systemd Linux distros?)

[Warren Young]

On Oct 18, 2018, at 7:35 PM, Warren Young  wrote:
> 
> It is certainly not a lot of work

Typo: remove “not”.  Running your own Linux distro is a *lot* of work.  Just 
ask our benefactors here!

Also, I should clarify that I’m not calling for action for my own benefit.  I’m 
a happy CentOS 7 user; it would take a *very* nice alternative to make me 
switch.  I’m just saying that I’d much rather see people starting a project to 
produce a new distro than more anti-systemd griping.

If the project is successful, the user community can then vote with its feet.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Upstream and downstream (was Re: What are the differences between systemd and non-systemd Linux distros?)

[Warren Young]

On Oct 18, 2018, at 6:52 PM, Japheth Cleaver  wrote:
> 
> Conoboy, on the other hand, takes great pains during the speech to describe a 
> much more fluid and complex interaction between CentOS and its upstream, and 
> puts forth CentOS as a mechanism (perhaps the best mechanism) for the winder 
> EL community to contribute (something?) back into RHEL's future.

I don’t see a change as significant as a new (or old!) init system making its 
way up from CentOS or Fedora to RHEL.

But hey, if you wanted to spend your time trying, that’s a *far* better use of 
your time than griping about systemd on mailing lists.

I think forking CentOS 5 or 6 is less effort, but hey, your time, your project.

If anyone out there is thinking this is too much work, some of the major Linux 
distributions are, or were at one point, largely one-person efforts.  It is 
certainly not a lot of work, but you don’t need a multibillion dollar company 
to fork CentOS.

Both projects could fail, and it would still be a much better signal to Red Hat 
what the people want.  Again: working code argues best.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

[Warren Young]

On Oct 18, 2018, at 9:41 AM, mark  wrote:
> On 10/17/18 7:55 PM, Warren Young wrote:
>>> Benno Rice is right: Lennart Poettering gets stuff done.
> 
> Because he's funded.

There are plenty of people with jobs that don’t get stuff done.

> I strongly suspect that a lot of that funding
> comes from M$'s interest in Upstream.


S…systemd is a Microsoft conspiracy against Linux?

> my home workstation is CentOS 6, and I am NOT
> looking forward to EOL.

That’s what I meant with my comment about the technical debt bill coming due.  
You can’t ignore the changes in the external world forever.  

The OpenSSL issue brought up in a prior post is another example of the same 
basic problem.

> people are tired of screaming and yelling about
> systemd, because we've had years now of the response being "tough, it's
> the Wave of the Future"

We covered that back when RHEL 7 was still in beta: the time is far too late to 
change the init system of RHEL 7.  The fact that you’re tired of being ignored 
doesn’t enter into it: you could still be yelling about it, and it still 
wouldn’t change.  Red Has simply isn’t going to swap out its Enterprise Linux 
init system within a major release cycle.

I believe it’s certain that RHEL 8 (and thus CentOS 8) will also be 
systemd-based, since we’d be hearing about the change by now via Fedora if it 
were otherwise.

Those of you who want a systemd-free CentOS-like OS to be available before 
CentOS 6 hits EOL are going to have to see to that yourselves.  You cannot 
expect it to just drop from the sky.

> Poettering is like upper management: they
> know, I mean, Everything, so why should they need to talk to end users (or
> working sysadmins)?

The suggestion that Red Hat is not listening to working system administrators 
beggars belief.  That’s pretty much the basis of their company’s major income 
stream.

What Red Hat is not doing is filling every demand from all working system 
administrators.  They’re choosing which demands to address, as any software 
project management must.

Red Hat has certainly heard the screams of the reactionaries.  Since that 
hasn’t changed anything, I believe you have your demand’s answer.  So, what are 
you going to do about it?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

[Warren Young]

On Oct 17, 2018, at 3:28 PM, Mark Rousell  wrote:
> 
> On 17/10/2018 20:03, Warren Young wrote:
>> On Oct 17, 2018, at 10:03 AM, Mark Rousell  
>> wrote:
>>> launchd is not being forced on them as systemd is in practice
>> Try doing without launchd on macOS.
> 
> If launchd was on Linux and it had systemd's cultural
> issues and, in many people's views, technical issues then the opposition
> to it would be identical to the opposition to systemd.

Try this gedankenexperiment instead: what if RHEL 7 shipped based on launchd 
instead of systemd, with no differences relative to the version shipped in the 
contemporaneous version of Mac OS X?

I’m uncertain as to whether the opposition would have been as great, but I’m 
dead certain the opposition would have been vociferous and strident, because 
Linux, though less conservative than the BSDs, is much more conservative than 
macOS.

The systemd vs launchd vs sysvinit vs whatever-else arguments are more about 
human factors than about technology, even though they’re usually couched as 
technical battles.

> When people go to Mac they accept what it is (mostly).

I doubt most Mac people even know launchd exists, much less have an informed 
technical opinion about it.  And of the small minority that do have such an 
opinion, it almost certainly doesn’t drive buying decisions.  Maybe that’s what 
you mean by accepting macOS as it is.

The thing I don’t get is, why is it different in the Linux world?  Why did we 
in the Linux community spend so much time arguing about systemd over the past 
several years?  Why is it still an active topic five years after the key 
events?  And why is the BSD community continuing to stir the pot?

Here’s what I want to see: I want one of the BSDs to clean Linux’s clock with a 
thoroughly awesome modern init system that makes us Linux fans so jealous we 
start noisily advocating to replace systemd with it, much as ZFS is starting to 
replace the horrid lash-up that is ext4/xfs+md+LVM+DM.

What I *don’t* want is more of this retrenchment to SysVInit.  I liked it well 
enough within its limitations, but we can do better in 2018.

(It’s a related tragedy that a slightly modified ksh88 remains the most 
powerful general purpose scripting language mandated by POSIX three decades 
after it was released by AT  We’ve got better alternatives here, too.)

>> For an init system to gain sufficient momentum, it must be the default, with 
>> no easy way to avoid it.
> 
> That's an argument for authoritarianism

I call it leadership.  Working code argues best.

Benno Rice is right: Lennart Poettering gets stuff done.

In the BSD world, they call the opposite tendency bikeshedding.  You can find a 
thousand people willing to argue about why something shouldn’t be done, or why 
it shouldn’t be done *that* way for every person capable, willing, and 
available to write a given piece of software.

For all the complaints about systemd over the past several years, I note that 
there is still no fork of CentOS 6 or CentOS 5, keeping the prior init 
system(s) but updating their package set to recent versions.  Many would rather 
gripe about change than put in the work it takes to maintain the status quo.

Then you get the crowd that tries to argue that we should just stay with what 
works, apparently under the misapprehension that staying in place is a 
zero-effort choice, when in reality it is at best an accrual of technical debt; 
the bill will come due eventually, with interest.

I suspect these two groups overlap quite a lot, inconsistent though the 
combined position is.

> the fact that some people do dislike change (a) does not
> make the substantive and objective problems, in many people's views,
> with systemd any less real or important

Of course not, but I also don’t see a lot of effort going into replacing 
systemd with something better.  Most of the effort opposing systemd seems to be 
going into anti-systemd advocacy campaigns, plus a tiny slice off to the side 
going into retrenchment to SysVInit.  That’s conservatism, plain and simple.

> he effectively claimed that it was all to do with fear of change when,
> as you agree, there in fact are substantive, real and objective issues
> which are widely recognised.

I suspect that for many people, those are rationalizations rather than reasons.

I saw much the same sort of logic in the Unix vs Linux wars, roughly spanning 
the decade surrounding 1996.

The Big Iron Unix and SCO Unix fans had all kinds of myopically rational 
reasons why Linux wasn’t going to replace their OS of choice: journaled 
filesystems, better SMP, STREAMS, hot-swap hardware, real ksh93 instead of that 
cheesy nonstandard imitation Bash… 

The analogy I used at the time is that the Unix fans saw Linux surfing behind 
their big yacht and laughed at the tiny, flimsy, cheap little surfboard, not 
realizing that it would take an awfully big wave 

Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?

[Warren Young]

On Oct 17, 2018, at 10:03 AM, Mark Rousell  wrote:
> 
> launchd is not being forced on them as systemd is in practice

Try doing without launchd on macOS.

If you think that’s irrelevant, count the number of MacBooks at the next 
FreeBSD conference you attend.

For an init system to gain sufficient momentum, it must be the default, with no 
easy way to avoid it.  Without that, you get things like:

1. TrueOS, where major non-core services still have no OpenRC script despite 
OpenRC being the default for about a year.  There were no Samba or NUT OpenRC 
scripts the last time I tried TrueOS, for example.  Even if that’s changed, 
it’s still a reflection of the fundamental barrier to adoption that I’m talking 
about here.

2. Lazy third-party Linux packages that still use SysVInit scripts, because 
they’re just forward-porting old packages with minimal effort.

> I should add that the speaker also massively over-simplifies opposition
> to systemd on the basis that he incorrectly perceives it to be
> opposition to change. He seems to ignore the fact that, as above, there
> are substantive objections to the specific architecture and quality of
> systemd, not merely objections to change with no deeper reason.

While there certainly are objective problems with systemd’s design and 
implementation, it is basic human psychology that many people will not move to 
a newer system despite piles of advantages.  

The major BSDs are fundamentally conservative at the project management level, 
so I believe this tendency is stronger in the BSD user population than 
elsewhere in the IT world.  It’s a form of self-selection bias: the BSDs are 
run conservatively, so they attract a user base that is also technologically 
conservative, from which come the next generation of core developers, who 
therefore continue to run the project conservatively.  Consequently, the major 
BSDs are even more conservative than the Enterprise Linuxes.

If it were otherwise, TrueOS would have long since taken over the FreeBSD 
world, and nvi wouldn’t still be missing proper UTF-8 support.

> many people objecting to systemd
> would nevertheless favour more modern system/service management.

I’d love to see that quantified.

Alternatives to the BSD rc init system are readily available, yet I think if 
you were to survey actual use, you’d find that over 99% of BSD boxes use the 
stock init system.

Change has to be forced from the center out on this kind of thing.  Diffusion 
from the outside in takes too long.

The question in my mind is how long it’s going to take for the major BSDs to 
make such a change at the center, so that the majority of new installs will use 
a modern init system.  The systemd project started in 2005, and wasn’t widely 
deployed as the default until about 4 years ago.  If past is prologue, I think 
this won’t happen on the BSDs for another decade or so, if ever.

Example: FreeBSD is just now moving to pkg-in-base in earnest, giving it 
features I first saw in the default install of Debian in about 1995.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] mount points @install time

[Warren Young]

On Oct 9, 2018, at 6:42 AM, lejeczek via CentOS  wrote:
> 
> is there a way to add custom mount points at installation point?

Yes: tell the installer that you want to do manual partitioning.  Then you can 
create whatever partitioning scheme you like.

> And if there is would you say /usr should/could go onto a separate partition?

Once upon a time, yes, but not any more:

   https://unix.stackexchange.com/a/4194/138

A complete CentOS installation is in the single-digit gigs, which is smaller 
than even most removable media these days.  Even small embedded systems can get 
a useful Linux installation onto a single flash IC or whatever it is they use 
for mass storage.

When installing to a single volume, the only partitions I make these days are 
to provide storage space isolation, as a cheap alternative to setting up 
quotas, log rotation, etc.:

*  /var if you expect large log files, large MySQL DBs, large /var/www trees, 
etc.

*  /home if you want to prevent problems with the root disk if normal users end 
up filling that partition with files they create.

*  Network file shares for the same reason.

With filesystems featuring pooled/shared storage (ZFS, btrfs, APFS…) I tend to 
create only one partition, then rely on the filesystem’s quota feature if 
necessary to avoid such problems.

Even on single-volume systems without pooled storage, you can usually get away 
with a minimal partition scheme:

*  Small /boot (plus maybe /boot/efi and/or /biosboot)

*  swap partition

*  root for everything else

This is because modern Unix-type filesystems will will typically reserve the 
last 5% of the space for root only, so that normal users simply cannot fill a 
filesystem, so that the OS won’t crash due to system daemons being unable to 
write to the disk.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] "WARNING: fdisk GPT support is currently new"

[Warren Young]

On Oct 7, 2018, at 4:49 AM, Nicolas Kovacs  wrote:
> 
> * use traditional fdisk with DOS-MBR style partitioning on systems that
> supported it

Unless you only need 4 or fewer partitions and are using 2TB or smaller disks, 
I can’t see any good reason to use MBR on desktop, laptop, or server systems 
these days.

(MBR does still have some well-justified use in the embedded world, removable 
media, etc.)

> As far as I can tell, the CentOS installer is doing something similar,
> but "automagically". Please correct me if I'm wrong.

I believe the primary criteria the CentOS installer uses is that it checks 
whether it was booted via EFI or BIOS.  If EFI, it assumes it must use GPT 
partitioning to get a bootable system.

Obviously if you’re installing onto a > 2TB disk or drive array, it also uses 
GPT.

You can tell which case you’ve fallen into by doing manual partitioning in the 
installer and then seeing whether the installer offers you the option of 
creating a “biosboot” partition or /boot/efi.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] "WARNING: fdisk GPT support is currently new"

[Warren Young]

On Oct 7, 2018, at 4:09 AM, Nicolas Kovacs  wrote:
> 
> How "experimental"
> (e. g. prone to blow up in my face) is fdisk really? So far, I've only
> used it for MBR-style partitioning.

I have no idea.  In fact, before your post, I had no idea fdisk even had GPT 
awareness.

I’m replying because you have a third option besides fdisk and gdisk, which 
should be present on a minimal install, and which is extremely well-tested for 
the GPT case: parted.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Seagate - experience/opinion on vendor?

[Warren Young]

On Sep 27, 2018, at 3:40 AM, lejeczek via CentOS  wrote:
> 
> And when they do release new software(which firmware is) then, they must have 
> a very good reason(which sometimes they do not say, but often than not they 
> do say) to do that.

You’re assuming that their good reason is *your* good reason.

The fix in the firmware may address a situation that simply never happens in 
your application.

Let’s flip the question around for the group:

1. How many times have any of you upgraded hard drive firmware, as a percentage 
of drives you’ve personally bought or been responsible for managing?

2. Of that percentage, what percentage showed a discernible improvement in 
behavior after doing the upgrade?

I’ve personally never done it, having never seen the point in doing so.

I *have* upgraded motherboard firmware, but only after looking at the change 
logs to see if it fixes something I care about.  I’ve looked at such change 
logs many more times than I’ve actually downloaded and attempted to use the new 
firmware, because most of the time, I decide that it will give me no relevant 
benefit.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: Linux recommendations for old Pentium PC

[Warren Young]

On Sep 3, 2018, at 2:30 AM, Gary Stainburn  wrote:
> 
> ...Pentium M processor...tiny fan...assumed power consumption would be low.

You could well be right, but I’m a fan of taking measurements over guessing. :)

If you were in the US, I’d recommend either of these from personal testing:

https://amzn.to/2NMWXJq
https://amzn.to/2oyz5Oz

I wrote the review voted most helpful for the latter item.  You might want to 
read it.

A clamp meter + line splitter is more fiddly to use than a Kill-a-Watt, but you 
can use the clamp meter for many more things, so it’s a better overall value 
unless you simply will not be doing those other things.

Neither of those will work for you due to US vs UK AC line connector 
differences, but these two items appear to be roughly equivalent:

https://www.amazon.co.uk/dp/B01DSQ30FO/
https://www.amazon.co.uk/dp/B00H99EECU/
   plus:
https://www.amazon.co.uk/dp/B075D512KM/

I’ve found the same clamp meter that I reviewed above, differing only in OEM 
labeling.

I’m not too happy with my guess for the best line splitter, for two reasons:

First, I'm unfamiliar with your UK power plugs, so I don’t know if that’s 
actually a UK plug.

Second, two of the reviews of that line splitter point out a design flaw that 
you might care about.  I’d have passed it by if I could find something better 
on the Amazon.co.uk site, but that is the best I found, alas.

You need a line splitter to do this test with a clamp meter, else you get a 
zero reading since the electromagnetic field from the neutral line cancels that 
of the hot line: you have to measure one or the other, separately.  It doesn’t 
matter which one you measure: the current through both lines is the same, 
differing only in direction, which is what we mean when we call something an 
electrical “circuit”.

Alternate plan: build a “broken circuit:”

https://tangentsoft.com/elec/broken-circuit.html

You can either make one for an inline current meter, as shown, or take the 
basic idea to DIY your own line splitter.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Certificates

[Warren Young]

On Sep 1, 2018, at 12:10 PM, Rainer Duffner  wrote:
> 
>> Am 01.09.2018 um 12:51 schrieb Pete Biggs :
>> 
>> That was until LetsEncrypt comes along - it has the backing of some big
>> names and *IS* an effective business model for small and private
>> customers.
> 
> What *is* the business model of Let’s Encrypt?

They’re a nonprofit, run off of sponsorships and donations:

https://letsencrypt.org/about/
https://letsencrypt.org/donate/
https://letsencrypt.org/docs/faq/
https://letsencrypt.org/sponsors/
https://letsencrypt.org/become-a-sponsor/

> Are they going to issue „Pro“ certificates at some point that cost money?

That would be incompatible with their 501(c)(3) status.

> Running a CA is not expensive per se

Indeed.

Let’s Encrypt was inevitable: the compute costs of generating certs, running 
the back-end service, and holding the data were tiny in the 1990s and are even 
tinier now.

Tiny times massive equals large, so at scale there are non-trivial costs, but 
the old standard of ~$100/yr was rapacious for what we’d now call a domain 
validation (DV) or light organization validation (OV) cert.

> In the beginning, the certificates had a certain level of trust with them 
> that came both from the high prices (deterring drive-by crooks) and the fact 
> that some sort of vetting was made to ensure that nobody could have issued a 
> certificate for a domain they didn’t really control.

I had certs in the early days, and even back then, a standard web site cert 
didn’t involve a whole lot of checking.

That’s lead to the DV vs OV vs EV distinction:

https://www.ssl.com/article/dv-ov-and-ev-certificates/

If a DV-only cert is sufficient for your purposes, then Let’s Encrypt probably 
does all you need.

The only reason to buy a cert these days is if you want OV or EV, and if it 
were me, I’d skip OV and go to EV in order to get the extra assurances that the 
green styling in the browser asserts.  For some applications, it’s worth the 
money.

DV-only covers a whole lot of use cases, though, including the one that started 
this thread.

> These days, a certificate just shows that the communication is encrypted.

You may be right that there is little practical difference to a random end user 
between DV and OV, but I believe there is real value in EV.

> There’s even talk about deprecating the special handling browsers have for 
> EV-certificates from future versions of Mozilla.

Why?

I’m aware that it’s possible to generate a fraudulent EV cert, but to deprecate 
the distinction between EV and DV is to impugn the value of the CA system 
entirely.  There’s plenty of problems in the system, which is one reason why we 
have the CAB Forum: untrustworthy CAs get run out of business.

That leaves transparent TLS proxy middleboxes and such, but that’s just another 
“Who do you trust?” argument.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Certificates

[Warren Young]

On Aug 31, 2018, at 4:42 PM, Robert Moskowitz  wrote:
> 
> [Let’s Encrypt] is designed for getting web servers quickly into TLS

Yes.

> ...and then to a more stable provider.

[citation wanted]

> If your content is short information, your contacts will never notice that 
> you go to a new cert quarterly.

They’ll never notice regardless.

I’m looking at a Google.com certificate right now that was generated on August 
14th of this year and will not be valid past October 23.  That’s the same 
replacement schedule as Let’s Encrypt.

The old model of long-lived certificates has no special value.  It’s purely a 
business decision on the part of the providers and customers.  Automation 
removes much of this model’s value.

> I can see web services where a new cert every 90 days will cause a pain point.

Describe one.

I’ve been running some of my domains on Let’s Encrypt for years now, and have 
never had a single user complain to me that my certs are changing too often.

> And for other services like IMAP, SMTP, LDAP (maybe not LDAP) constant 
> changing certs even with a long lived root may get old for your customers.

As long as both the old and new certs are valid at the time of replacement, the 
client should care nothing about it unless they’ve gone to the trouble to 
download the cert and check it against the cached copy every time.

I remember hearing about at least one browser plugin that did this, but since 
the idea of rapid cert replacement has been gaining ground, I expect that 
plugin has lost much of the small amount of popularity it once held.

> Unfortunately, there has never been an effective business model for small 
> customers.

There is now: it’s called Let’s Encrypt. :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OT: Linux recommendations for old Pentium PC

[Warren Young]

On Aug 31, 2018, at 8:29 AM, Gary Stainburn  wrote:
> 
> I've got a very small footprint rack server with a 4TB drive in that I wish 
> to 
> be a Bacula storeage device. However, it's got an old board / processor in 
> it.

You’re giving two very mixed signals here.

“Old Pentium,” as someone else said, can mean anything back to 1993, but “4 TB 
drive” suggests something far newer than that.

I ask because that affects the expected energy draw of the server.  If it’s 
old, it could be 200 W or so.  If you’re using “old” rather loosely, then it 
could be down in the double digits.

Here’s why it matters:

   https://www.rapidtables.com/calc/electric/energy-cost-calculator.html

At 12 pence per kWh — typical for power in some places in your country, based 
on your TLD — it’s going to cost you about 1 pound per watt consumed if it runs 
all day every day.  If it draws 35 W, that’s £35/yr.  If it draws 200 W, that’s 
£200/yr.

If the cost is high enough, then it’s probably cheaper to buy a new 
energy-efficient server, which then lets you buy something that will run any 
Linux distro you want.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] OpenLDAP support in future versions of CentOS

[Warren Young]

On Aug 28, 2018, at 9:51 AM, Alicia Smith  wrote:
> 
> Red Hat and Suse announced they are no longer supporting OpenLDAP in future
> releases.
> https://www.ostechnix.com/redhat-and-suse-announced-to-
> withdraw-support-for-openldap/

I only see a link to the SuSE announcement from that article.  The Red Hat 
links just talk about how 398 is preferred, but don’t actually say OpenLDAP is 
deprecated.  Is there a public Red Hat announcement of this somewhere?

I’ve searched the RHEL 7.4 and 7.5 release notes, and I don’t see anything 
about it being deprecated there.

We use the OpenLDAP libraries to talk to other LDAP implementations.  (We don’t 
use the OpenLDAP server itself.)  A skim of the docs at port389.org says they 
use the Mozilla LDAP API, but that library doesn’t appear to be in the CentOS 7 
package repository:

$ yum search ldap | grep devel
openldap-devel.i686 : LDAP development libraries and header files
openldap-devel.x86_64 : LDAP development libraries and header files

We’d like to get ahead of this and migrate, if that’s going to be forced on us 
by CentOS 8, but is there a better path than just building Mozilla’s LDAP 
client libraries from source?

Maybe CentOS 8 beta will appear sometime soon so I can start work on the 
migration within a development VM?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux question

[Warren Young]

On Aug 21, 2018, at 4:34 PM, Nataraj  wrote:
> 
> On 08/21/2018 02:20 PM, Warren Young wrote:
>> On Aug 21, 2018, at 1:27 PM, Nataraj  wrote:
>>> I have a web application which uses sudo to invoke python scripts as the
>>> user under which the application runs (NO root access).
>> Why is the web app not running with that user’s permissions in the first 
>> place?
>> 
> The php code runs as user apache under the webserver.

Okay, that’s useful to know, and it’s something we’re just now learning.  
You’ll get better advice if you include such details when using for help.

> If the php ran as the app users it would have full access to all of the data 
> in the app.

…and that’s a problem why, exactly?  What could happen if that were allowed?

I understand that you’re creating a privilege separation scheme here, but if 
you want good advice, we need to know what you want to achieve with the scheme 
and why that is necessary.

What resources does this non-php user own that user php must not be allowed to 
have access to?  Once we know that, we can advise on how to protect those 
resources.

> Using sudo the app can only invoke one specific python script (which is the 
> command name in the sudoers file) to do what it needs to do, without having 
> access to the rest of the apps data and other python scripts used by other 
> functions in the app).

Another way to go about it would be to have the background service running as 
the non-php user, then provide access to it over the many IPC mechanisms 
available in a Linux system: named pipes, SysV message queues, shared memory…  
Add to that all of the higher-level services available like message-oriented 
middleware:

   https://en.wikipedia.org/wiki/Category:Message-oriented_middleware

Such services let one process tell another, “Hey, I need you to do something 
for me,” then wait for the answer, received as a single coherent message.  Many 
of these schemes let you split that worker process off into a separate machine, 
or even a cluster of machines.  

That could help you to get off CentOS 5: move the worker process onto a C7 box, 
then when that’s well-validated, move the PHP bits over.  

Or, move the PHP bits to a *second* C7 box, and now you’ve got much stronger 
privilege separation.  You may remember all of the ways that Shellshock — a 
local-only exploit — was able to be exploited over HTTP, because local web app 
code was using the shell, thus converting it into a remote-exploitable security 
hole.  By separating the worker processes to a separate machine, that now can’t 
happen on the second box.  If the front-end box has no sensitive material on 
it, that’s enough security: just wipe it and re-image it if it’s ever 
compromised.

However you do this, these mechanisms give you hard privilege separation 
without SELinux bugging you.

> I could be convinced otherwise if I could see where running the php as the 
> app users, would make more sense.

That depends on whether the boundary between user php and this unknown 
“appuser” is bidirectional or not.

If there are things owned by user “php” that “appuser” should not see, then 
continuing to run the web app as two separate users makes sense.  

If “appuser” can be said to own everything in the web app, and the only reason 
you’re converting user php privileges to “appuser” privileges is so you don’t 
have to give user php access to everything in the web app, then I’d say my 
prior suggestion holds.

Now that I know you’re using PHP, I can recommend something like PHP-FPM:

https://php-fpm.org/

That’s the old external project.  It’s now part of the PHP core:

https://secure.php.net/manual/en/install.fpm.php

You’ll have to use the old version with C5, though, as that happened after C5 
was released.

FPM isn’t the only way to go, just one idea, which happens to be well-supported 
within the PHP community.

Regardless of the exact method, this lets you run your PHP code as a non-php 
user, letting Apache proxy to it using mod_fcgi.  Now you’ve got strong 
separation between things Apache is allowed to read and things it must talk 
down through PHP to get access to.

> It could be that giving sudo sys_ptrace access could increase the risk to the 
> security of the system

Once you give a process ptrace ability, it’s pretty much game over when it 
comes to security.  The scope of what one process can do to another via 
ptrace(2) is HGE.  I’d very much resist placating SELinux in this way.

SELinux might in fact be warning you about a real attack here, which would 
explain why it’s intermittent.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] selinux question

[Warren Young]

On Aug 21, 2018, at 1:27 PM, Nataraj  wrote:
> 
> I have a web application which uses sudo to invoke python scripts as the
> user under which the application runs (NO root access).

Why is the web app not running with that user’s permissions in the first place?

If your answer is that it needs root access to bind to port 80, there are two 
common solutions:

1. Start the service as root, set up the port 80 listener, then drop privileges 
internally with getpwent(“myuser”) and setuid(my_uid).

2. Use an HTTP[S] proxy server, such as Apache with mod_proxy configured.  Bind 
the actual web app to localhost and a high-numbered random port, then forward 
external port 80 hits to the internal service.  This method has the additional 
advantage that you can use the path part of the URL to relieves the web app of 
having to serve hits for the static resources — *.js, *.png, *.css… — which can 
speed the application up.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] rsync versioning problem

[Warren Young]

On Aug 3, 2018, at 10:17 AM, Warren Young  wrote:
> 
> It’s possible this behavior changed since I last looked at it.

It looks like the rsync version shipping with CentOS 7 will actually complain 
if multiple target directory levels are missing.  With only ~/tmp existing on 
the target machine, this command:

$ rsync -a path/to/stuff remote-host:tmp/foo/bar

gives:

rsync: mkdir "/home/USER/tmp/foo/bar" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(657) [Receiver=3.1.2]

I recall a confusing, softer failure mode, so perhaps they decided this would 
be better handled with a hard failure to avoid some end user confusion.  (And 
probably some support email traffic!)

The trailing slash on the source path affects the remote result once you get 
past this issue, but adding a slash doesn’t prevent the error in this condition.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] rsync versioning problem

[Warren Young]

On Aug 3, 2018, at 9:59 AM, Robert Moskowitz  wrote:
> 
>> You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default.  
>> It was released in 2004.
> 
> How do I specify -p and -l that I cut out of my example?

Add it to ~/.ssh/config:

Host nevia.htt-consult.com
Port 
User rmoskowitz

You might not think of rsync as paying attention to this file, which is 
correct, because it doesn’t.  But since it is executing ssh under the hood, and 
ssh *does* pay attention to that file, it takes effect.

If you’re creating that file for the first time, be sure to chmod 600 it.  Ssh 
will ignore it if it’s not locked-down.  RTFM for details.

>>> /var/flexshare/shares 
>>> x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
>> Rsync won’t create multiple levels of directories on the target.  It will 
>> only create up to one level of missing directories.  Try this:
>> 
>> $ ssh x.htt-consult.com 'mkdir -p 
>> /media/backup/homebase/var/flexshare/shares/'
> 
> Oh?  I have been doing this in one shape or form for a long time.

Let me clarify: 

If only /media/backup exists on the remote machine, I believe you’ll end up 
with /media/backup/shares with that command.

If at least /media/backup/homebase/var/flexshare exists, rsync will always 
create “shares” under “flexshare" on the remote host.

Anything below that level will also be created, regardless of depth.  I’m 
speaking only of the target path given as the last argument to rsync here, not 
of the source machine’s directories discovered during the sync process.

It’s possible this behavior changed since I last looked at it.  I ran into this 
issue many years ago and now ensure that the target path passed to the rsync 
command exists on the remote host before starting the sync.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] rsync versioning problem

[Warren Young]

On Aug 3, 2018, at 8:57 AM, Robert Moskowitz  wrote:
> 
> I seem to have an rsync versioning problem.

Have you ruled out the other causes of that error?  For instance:

https://askubuntu.com/a/716911

> And researching this it comes down to a versioning issue.

That seems rather unlikely for such an old and stable tool as rsync, and 
especially for two versions with the same major version number.  If you’d said 
rsync 2 and 3 or we were talking about a tool that still hadn’t hit 1.0 yet, 
I’d believe the protocol was still in flux, but rsync is 22 years old now.

On the other hand, 3.0.6 is nine years old now, so maybe.

> rsync -ah --stats --delete -e “ssh"

You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default.  It 
was released in 2004.

> /var/flexshare/shares 
> x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/

Rsync won’t create multiple levels of directories on the target.  It will only 
create up to one level of missing directories.  Try this:

$ ssh x.htt-consult.com 'mkdir -p 
/media/backup/homebase/var/flexshare/shares/'

Then retry the rsync.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Finding memory usage

[Warren Young]

On Jul 27, 2018, at 9:10 AM, Bowie Bailey  wrote:
> 
> I have a CentOS 7 server that is running out of memory

How do you know that?  Give a specific symptom.

> Running "free -h" gives me this:
>   totalusedfree  shared  buff/cache  
> available
> Mem:   3.4G2.4G123M5.9M  

This is such a common misunderstanding that it has its own web site:

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

Re: [CentOS] two 2-node clusters or one 4-node cluster?

[Warren Young]

On Jul 7, 2018, at 7:54 AM, Gianluca Cecchi  wrote:
> 
> I have yet to dig sufficiently deep in Warren considerations, but I will do
> it, I promise! Very interesting arguments

Until then, I offer this tl;dr:

A 4-member cluster has distinct advantages over a 2x2 cluster of the same 
machines *if* the software running that cluster knows how to take the full 
available advantage of that configuration.

That “if” is key.  By it, I’m telling you I don’t know whether the clustering 
software you want to run uses a proper distributed consensus algorithm or is 
something simpler, like a blind mirroring system.  If the latter, then the 
choice of configuration is purely an operational consideration, something only 
you can decide.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] two 2-node clusters or one 4-node cluster?

[Warren Young]

On Jul 5, 2018, at 1:07 PM, Alexander Dalloz  wrote:
> 
> classical cluster setups are so 2000s. Outdated by modern infrastructure 
> concepts you see implemented in Kubernetes, OpenShift or cloud solutions in 
> general. It's commonly summarized in the phrase "pets versus cattle". You 
> don't want clusters to be treated as pets.

That depends on how expensive it is to grow the herd, to extend your metaphor.

For example, if you have a big DBMS, it’s probably much, much faster to 
maintain a live spare that you can fail over to instantly than it is to spin up 
a new VM with OpenKuberStack® and clone the complete DBMS over the Internet.  
At 1 Gbit/sec, every 10 TB costs you about a day of replication time!

The herd-of-cattle model and follow-ons like “serverless” assume you can spin a 
new one up in a second or so.  That ain’t always possible.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] two 2-node clusters or one 4-node cluster?

[Warren Young]

On Jul 5, 2018, at 11:10 AM, Digimer  wrote:
> 
> There is no effective benefit to 3+ nodes

That depends on your requirements and definition of terms.

For one very useful (and thus popular) definition of “success” in distributed 
computing, you need at least four nodes, and that only allows you to catch a 
single failed node at a time:

http://lamport.azurewebsites.net/pubs/reaching.pdf

See section 4 for the mathematical proof.  This level of redundancy is 
necessary to achieve what is called Byzantine fault tolerance, which is where 
we cannot trust all of the nodes implicitly, and thus must achieve consistency 
by consensus and cross-checks.

A less stringent success criterion assumes a less malign environment and allows 
for a minimum of three nodes to prevent system failure in the face of a single 
fault at a time:

http://lamport.azurewebsites.net/pubs/lower-bound.pdf

With your suggested 2-node setup, you only get replication, which is not the 
same thing as distributed fault tolerance:

http://paxos.systems/how.html

To see the distinction, consider what happens if one node in a mirrored pair 
goes down and then the one remaining up is somehow corrupted before the downed 
node comes back up: the second will be corrupted as soon as it comes back up 
because it mirrors the corruption.

The n >= 2f+1 criterion prevents this problem in the face of normal hardware or 
software failure, with a minimum of 3 nodes required to reliably detect and 
cope with a single failure at a time.

The more stringent n > 2m+1 criterion prevents this problem in the face of 
nodes that may be actively hostile, with 4 nodes being required to reliably 
catch a single traitorous node.

That terminology comes from one of the most important papers in distributed 
computing, “The Byzantine Generals Problem,” co-authored by Leslie Lamport, who 
was also involved in all of the above work:


https://www.microsoft.com/en-us/research/uploads/prod/2016/12/The-Byzantine-Generals-Problem.pdf

And who is Leslie Lamport?  He is the 2013 Turing Award winner, which is as 
close to the Nobel Prize as you can get with work in pure computer science:

https://en.wikipedia.org/wiki/Leslie_Lamport

So, if you want to argue with the papers above, you’d better bring some pretty 
good arguments. :)

If his current affiliation with Microsoft bothers you, realize that he did all 
of this work prior to joining Microsoft in 2001.

Also, he’s also the “La” in LaTeX. :)

> (quorum is arguably helpful, but proper stonith, which you need anyway, makes 
> it mostly a moot point).

STONITH is orthogonal to the concepts expressed in the CAP theorem:

   https://en.wikipedia.org/wiki/CAP_theorem

It is mathematically impossible to escape the restrictions of the CAP theorem.  
I’ve seen people try, but it inevitably amounts to Humpty Dumpty logic: "When I 
use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what 
I choose it to mean — neither more nor less.”  You can win as many arguments as 
you like if you get to redefine the foundational terms upon which the argument 
is based to suit your needs at different stages of the argument.

With that understanding, we can say that a 2-node setup results in one of the 
following consequences:


OPTION 1: Give up Consistency (C)
-
If you give up consistency, you get an AP system:

- While one node in a mirrored pair is down, the other is up giving you 
availability (A), assuming all clients can normally see both nodes.

- Since you give up on consistency (C), you can put the two nodes in different 
data centers to gain partition tolerance (P) over the data paths within and 
between those data centers. This only gets you availability as well if both 
data centers can be seen by all clients.

In other words, you can tolerate either a loss of a single node or a partition 
between them, but not both at the same time, and while either condition 
applies, you cannot guarantee consistency in query replies.

This mode of operation is sometimes called “eventual consistency,” meaning that 
it’s expected that there will be periods of time where multiple nodes are 
online but they don’t all respond to identical queries with the same data.


OPTION 2: Require Consistency
-
In order to get consistency, a 2-node system behaves like it is a bare-minimum 
quorum in a faux 3-node cluster, with the third node always MIA.  As soon as 
one of the two “remaining” nodes goes down, you have two bad choices:

1. Continue to treat it as a cluster.  Since you have no second node to check 
your transactions against to maintain consistency, the cluster must stop write 
operations until the downed node is restored.  Read-only operations can 
continue, if we’re willing to accept the risk of the remaining system somehow 
becoming corrupted without going down entirely.

2. Split the cluster so that the remaining node is a standalone instance, 

Re: [CentOS] git public web frontends

[Warren Young]

On Jun 6, 2018, at 4:06 AM, Alice Wonder  wrote:
> 
> I'm not anti-microsoft but I'm worried they will make changes that I don't 
> like (e.g. requiring ms account, changing billing, etc.) so I figured better 
> take control now.

What had you using GitHub in the first place, then?  Is it just the web UI, 
since you’ve apparently decided that none of GitHub’s other major advantages 
over stock Git matter?  Those being:

- pull request management
- the social network
- one-click hosting
- issue tracking
- GitHub.io

> But... can anyone recommend a web front end?

Do you actually enjoy using Git over the alternatives?  Do you know what your 
alternatives are?

Once you get past a perceived need to participate in the network effects from 
the popularity of Git and GitHub, you have several superior options, on some 
axes.

My personal choice is Fossil, the DVCS behind SQLite:

https://fossil-scm.org/

It’s much easier to use Fossil than Git when things go well, it’s less likely 
to get you tangled up than Git when things *don’t* go well, and it provides 
much of what GitHub does over stock Git.

There’s only one area I’m aware of where Git is actually easier to use than 
Fossil, and that’s in the initial clone.  It’s a single command in Git, whereas 
it’s a several-step process in Fossil, in part owing to one of Fossil’s 
advantages over Git, that being that the local repository clone and local 
checkout are separate things in Fossil, which avoids the need for hacks like 
git-worktree.

If you’re worried that your users will have to deal with that complexity, it’s 
not true: Fossil makes it easy to set up single-click zip and tarball download 
links, so that those not needing a “real” repo checkout don’t have to put up 
with the complexity.

If you want to see it in action, the Fossil web site I pointed you to above 
*is* Fossil.  (They eat their own dog food!)  The SQLite web site is another: 
https://sqlite.org/

> It doesn't need to be as fancy as github

Fossil’s web UI is more advanced than GitHub in some ways:

1. I find Fossil’s timeline view more useful than GitHub’s closest equivalent, 
the “Commits” page.  The commits all look “flat” to me in GitHub, whereas 
parentage, branches, etc. are clearer in Fossil’s web timeline view.  I suspect 
this is actually a reflection of a difference in the underlying philosophies of 
these two DVCSes rather than some UI designer’s idiosyncratic preference, but 
I’ll get back to that later.

2. Fossil makes it easy to diff two versions from the web UI: click the bubble 
next to the “from” version in the timeline view, then click the bubble next to 
the “to” version.  GitHub’s equivalent is much more complicated:

https://help.github.com/articles/comparing-commits-across-time/

3. Fossil’s ticket tracker is more advanced than GitHub’s issue tracker in 
several ways, and it’s quite configurable if you don’t like the out-of-box 
behavior.  GitHub’s issue tracker is little more than a tagged comment system.

4. Each Fossil instance can be configured to a custom startup page.  By 
default, it’s a wiki document called “Home”, which you typically write to serve 
the needs of new users on a public project.  For private projects, my first 
need on visiting the Fossil web UI is almost never a wiki document, so I find 
it more useful to default to the timeline view.

If you want a more GitHub-like experience, you could make the default web UI 
view be the Files page, but I never quite understood why I’d like to see a file 
browser as my project’s default presentation to the public.  If you force me to 
dig through the Files view to find things in your project, the project’s 
maintainers have probably failed in their duty to guide new users to key 
material.

5. Fossil is skinnable.  If you don’t like the default skin, which is that used 
by the Fossil and SQLite project sites, it currently ships with a dozen others, 
one of which you may like better.  And if you don’t like any of those, anyone 
with web front-end skills can make a new one.  Here’s a non-default skin that I 
made, to match the esthetics of the hardware related to the repository:

   https://tangentsoft.com/pidp8i/


There must be advantages to GitHub’s web UI relative to Fossil, but none come 
immediately to my mind.  I’ve asked GitHub fans to name some, and so far I’ve 
only gotten vague answers that amount to familiarity rather than objective 
advantages.


Now, above I spoke of a major philosophical difference between Git and Fossil: 
Git was made to support the needs of the Linux kernel developers, whereas 
Fossil was made to support the needs of the SQLite developers.  Which one is 
closer to the way you manage your projects?

There are several differences between the two DVCSes that I believe fall out of 
that basic difference.

Git wants each “leaf” developer to work disconnected from the rest until he has 
something coherent to push up through the commit hierarchy towards the core.  
Thus “fork 

Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1804) on x86_64 aarch64 i386 ppc64 ppc64le

[Warren Young]

On May 10, 2018, at 1:33 AM, Karanbir Singh  wrote:
> 
> I am pleased to announce the general availability of CentOS Linux 7
> (1804) for across all architectures.

I’ve checked about a dozen of the mirrors, and see no *.torrent files yet.  Any 
idea how long they’ll take to appear?  I ask because we’re building a system 
today, so if it’s going to be more than a few hours, I’ll grab the ISO file 
directly, but otherwise, I’d prefer to spread the load.

> As always, read through the Release Notes at :
> http://wiki.centos.org/Manuals/ReleaseNotes/CentOS7

The “RHEL” link here still points to the 7.4 release notes:

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

Re: [CentOS] Samba HOWTO wiki bug: chcon samba_share_t

[Warren Young]

On May 5, 2018, at 12:04 AM, Gordon Messmer <gordon.mess...@gmail.com> wrote:
> 
> On 05/04/2018 04:05 PM, Warren Young wrote:
>> On May 4, 2018, at 4:11 PM, Louis Lagendijk <lo...@fazant.net> wrote:
>>> The comment is correct: chcon will not survive a relabel. You need to
>>> update the database first (semanage fcontext) and then let a relabel
>>> apply the new context.
>> Alright, then why do I get that error when I give the command from this 
>> morning’s wiki text, and how do I avoid it?
> 
> # od -c
> sudo semanage fcontext –at samba_share_t /path/to/share
> 000   s   u   d   o   s   e   m   a   n   a   g   e f   c
> 020   o   n   t   e   x   t 342 200 223   a   t   s a   m
> 040   b   a   _   s   h   a   r   e   _   t   /   p   a t   h
> 060   /   t   o   /   s   h   a   r   e  \n
> 
> You get the error because that isn't a hyphen, it's an en-dash. Someone 
> probably copied and pasted from Word.

The formatting is from my mailer.  The paste into the terminal wouldn’t have 
been affected.

And again, the chcon command succeeded, with the same type name, copied from 
the same source by the same method.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba HOWTO wiki bug: chcon samba_share_t

[Warren Young]

On May 4, 2018, at 6:35 PM, Earl A Ramirez  wrote:
> 
> You can check the labels using seinfo -t, below is what I had for samba

I’m away from work now, so I can’t check it at the moment, but if that 
explained the problem, wouldn’t my chcon command also have failed?  Clearly the 
SELinux type samba_share_t does exist on my CentOS 7 machine.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba HOWTO wiki bug: chcon samba_share_t

[Warren Young]

On May 4, 2018, at 5:13 PM, Gordon Messmer <gordon.mess...@gmail.com> wrote:
> 
> On 05/04/2018 12:03 PM, Warren Young wrote:
>> …there is a command down in section 2 that gives an error here on CentOS 7:
>> 
>> $ sudo semanage fcontext –at samba_share_t /path/to/share
>> …noise noise noise…
>> semanage: error: unrecognized arguments: samba_share_t /path/to/share
> 
> What is "noise" exactly?  I don't get errors from that command:

The full message is:

usage: semanage [-h]


{import,export,login,user,port,interface,module,node,fcontext,boolean,permissive,dontaudit}
...
semanage: error: unrecognized arguments: samba_share_t 
'/path/to/share(/.*)?'
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba HOWTO wiki bug: chcon samba_share_t

[Warren Young]

On May 4, 2018, at 4:11 PM, Louis Lagendijk  wrote:
> 
> The comment is correct: chcon will not survive a relabel. You need to
> update the database first (semanage fcontext) and then let a relabel
> apply the new context.

Alright, then why do I get that error when I give the command from this 
morning’s wiki text, and how do I avoid it?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Samba HOWTO wiki bug: chcon samba_share_t

[Warren Young]

On May 4, 2018, at 3:03 PM, Akemi Yagi <amy...@gmail.com> wrote:
> 
> On Fri, May 4, 2018 at 12:03 PM, Warren Young <war...@etr-usa.com> wrote:
>> 
>>$ sudo chcon -R -t samba_share_t /path/to/share
> 
> Updated the page as suggested. Thanks.

Thanks!

I now see another instance of this in section 3.  Instead of copying the text 
verbatim, it should probably be:

chcon -R -t samba_share_t /mnt/data

…in order to match the text above it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Samba HOWTO wiki bug: chcon samba_share_t

[Warren Young]

In this wiki article:

   https://wiki.centos.org/HowTos/SetUpSamba

…there is a command down in section 2 that gives an error here on CentOS 7:

$ sudo semanage fcontext –at samba_share_t /path/to/share
…noise noise noise… 
semanage: error: unrecognized arguments: samba_share_t /path/to/share

That and the following restorecon command can be replaced by a single shorter 
command, which also fixes the symptom:

$ sudo chcon -R -t samba_share_t /path/to/share
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7 1708 won't boot after grub2 update

[Warren Young]

On Feb 19, 2018, at 5:00 AM, Sorin Srbu  wrote:
> 
> This is the third fresh install of CentOS 7 1708 the last two months that
> won't boot after a regular "yum update" just after the fresh install has
> finished.

Define “won’t boot”.  Does it stop:

1. Before the GRUB2 screen?
2. Between the GRUB2 screen and root device mount?
3. After root device mount but before entering runlevel 5?
4. Something else?

Maybe post a screenshot to imgur.

> Am I missing something here?

You’re a computer person.  This means people come to you with problems they 
want you to solve.  I know this because it is a law of the universe; Q.E.D.

Is “won’t boot” the sort of report you’d like to receive from those depending 
on you for support?  Give us the sort of problem report you’d most dearly love 
to receive from your users.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS 7 1708 won't boot after grub2 update

[Warren Young]

On Feb 19, 2018, at 6:36 PM, Steven Tardy  wrote:
> 
> BTW, anyone have a good method for finding driver for a given
> disk(/dev/sdX)?

Use this script: https://stackoverflow.com/a/42382011

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

Re: [CentOS] Percentage of CentOS coded in each language

[Warren Young]

On Feb 15, 2018, at 2:14 PM, Blake Hudson  wrote:
> 
> Anyone have any suggestions for determining this info?

Unpack all of the sources somewhere, then run SLOCCount on the tree:

   https://www.dwheeler.com/sloccount/

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

Re: [CentOS] lshw in centos 7 withdrawn

[Warren Young]

On Jan 15, 2018, at 9:10 AM, david  wrote:
> 
> - SATA3 is faster than USB3 (I think)

Almost always, yes.

> But sometimes one has no choice.

Only if you have no PCI slots, and hence can’t put a better interface into the 
system.

> The Mac pro may look cute in its black cylinder, for example, but there's no 
> place to add anything to it.

The old trashcan Mac Pro has *six* Thunderbolt 2 ports in 3 separate busses, 
running at a reliable 20 GBit/sec per bus.  Contrast USB 3.0, which might 
deliver its promised 5 Gbit/sec on a perfect bench test with uncommonly good 
cabling and other hardware, and where there’s a fair chance you have only 1 or 
2 busses per system, with the bandwidth shared among the ports on each bus.

Much of the difference in quality between USB and Thunderbolt comes from the 
fact that Thunderbolt is almost exclusively found on professional-grade 
machines, so there isn’t as much drive behind the old race to the bottom, so 
that there actually are reliable Thunderbolt cables and enclosures available, 
and the vendors of same tend not to cheap out on things like power supplies.

You won’t pay $13.64 for a Thunderbolt enclosure and cable, though.

The same is true of other professional-grade storage busses like Fibre Channel. 
 You gets what you pays for.

Contrast eSATA, which I’ve found to be about as troublesome as USB, again due 
to a race to the bottom.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] lshw in centos 7 withdrawn

[Warren Young]

On Jan 15, 2018, at 8:57 AM, Warren Young <war...@etr-usa.com> wrote:
> 
> Whenever I have a machine with an unkillable userspace program, I run dtrace

Sorry, got my OS wires crossed: I mean dmesg.  Though dtrace could help, too, 
if you’ve managed to build that for CentOS; I hear it can be dnoe. :)

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

Re: [CentOS] lshw in centos 7 withdrawn

[Warren Young]

On Jan 12, 2018, at 3:18 PM, david  wrote:
> 
> Or is it related to the annoying spin-down and spin-up delay of external USB 
> disks.

More likely, crap hardware, which is awfully hard to avoid in USB-land.

Just the other day, I traced a machine that failed to reboot to an external USB 
disk.  Unplug it, machine boots right up.  Move the same disk to a machine as 
different as can be — different hardware, different OS, different firmware… — 
and it kernel panic’d that box within about a minute of plugging it in.

Then there was the time a USB enclosure ate my data.  Only the filesystem’s 
strong checksums saved me that time.  I moved the disk to another enclosure, 
and the bad sector writes stopped occurring; all else remained the same.

The problem is a market conditioned to believe that it should expect to pay 
$13.64 for an enclosure, power supply, and interface cable and get a 5-star 
product.  If you put a $200 enclosure in front of the vast majority of members 
of that market, they’d either disbelieve the price or rate it 1 star for bad 
value, even if it was guaranteed to outlast the prevalence of the USB standard 
it supports, had a higher transfer rate, and had guaranteed data corruption 
rates best given in scientific notation with large negative exponents.

Whenever I have a machine with an unkillable userspace program, I run dtrace, 
and almost always get told exactly which bit of hardware (and therefore which 
kernel driver) is holding the machine hostage.

You might be able to dig the same info out of /var/log/messages, given 
close-enough timestamps.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754

[Warren Young]

On Jan 4, 2018, at 12:18 PM, Walter H.  wrote:
> 
> will there be updates for these CVEs for CentOS 6?

Red Hat hasn’t released them all yet.  Quoting Christopher Robinson in the 
thread for this here:

https://access.redhat.com/errata/RHSA-2018:0007

"We will be pushing errata out as soon as they have passed our QA team's 
testing. The more modern versions were easier to backport patches from 
upstream, and as you progress backwards the fixes change from a backporting 
exercise into a complete rewrite. We expect all packages for RHEL7 to be 
available shortly, with RHEL6 following closely behind.”

Robinson’s reply then goes into other ramifications which don’t impact CentOS 
for one reason or another, except insofar as CentOS’s speed in responding to 
this is gated in large part by Red Hat’s ability to respond.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accessing crashed disk

[Warren Young]

On Dec 13, 2017, at 5:15 PM, J Martin Rushton  
wrote:
> 
> # dd if=/dev/sdc of=/home/dd-copy-of-sdc

Better, use ddrescue:

   https://www.gnu.org/software/ddrescue/

dd will do unfortunate things like quit early on I/O errors, even if later 
blocks would read just fine.  ddrescue assumes the input file is dodgy and 
tries to cope.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Gulliver

[Warren Young]

On Oct 31, 2017, at 12:47 PM, Gordon Messmer  wrote:
> 
> If this is an application that you've developed in-house, you should be using 
> htonl() to convert your 32-bit values to network byte order

…or its superset, XDR  [1]
…or use a text format (XML, JSON, YAML, SQL, CSV…)
…or use a binary serialization of same (BSON, CBOR, Binary XML…)
…or use FlatBuffers  [2]
…or use ASN.1  [3]

or, or or.  This problem is *solved*.  The only difficult part is choosing 
which of the many available solutions to use.



[1]: https://en.wikipedia.org/wiki/External_Data_Representation
[2]: https://en.wikipedia.org/wiki/FlatBuffers
[3]: https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

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

Re: [CentOS] [OT] Bash help

[Warren Young]

On Oct 26, 2017, at 10:37 AM, Gordon Messmer <gordon.mess...@gmail.com> wrote:
> 
> On Wed, Oct 25, 2017 at 9:47 AM, Warren Young <war...@etr-usa.com> wrote:
>> 
>> CentOS 5 is definitely out, as that ships Bash 3, which lacks this feature.
> 
> Nonsense.  Every POSIX shell has an associative array called "the filesystem.”

Ah, *there’s* our masochist.  I knew we had at least one around here somewhere. 
:)

Takes one to know one, I suppose: not long ago, I proposed using the filesystem 
to implement a [DAG][1] in shell. ;)


[1]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT] Bash help

[Warren Young]

On Oct 25, 2017, at 11:28 AM, Mark Haney  wrote:
> 
> An associative array was the first thing I thought of, then realized BASH 
> doesn't do those.

But it does: in Bash 4, only.

If you mean you must still use Bash 3 in places, then yeah, you’ve got a 
problem… one probably best solved by switching to some other language once the 
program grows beyond Bash 3’s natural scope.

I was trying to think of which languages I know well which require even more 
difficult solutions than the Bash 4 one.  It’s a pretty short list: assembly, 
C, and MS-DOS batch files.  By “C” I’m including anything of its era and 
outlook: Pascal, Fortran…

I think even Tcl beats Bash 4 on this score, and it’s notoriously minimal in 
its feature set.

Here’s a brain-bender: You could probably do it with sqlite3 with fewer lines 
of code than my Bash 4 offering. :)

> I honestly expected there to be a fairly straight forward way to do it in 
> BASH, but I was sadly mistaken.

Oh, I don’t know, there must be a way to do it without associative arrays, but 
you’d only get points for the masochism value in doing without.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT] Bash help

[Warren Young]

On Oct 25, 2017, at 11:00 AM, Leroy Tennison  wrote:
> 
> Although "not my question", thanks, I learned a lot about array processing 
> from your example.

Yeah, it’s amazing how many obscure corners of the Bash language must be tapped 
to solve such a simple problem.  I count 7 features in that script that I 
almost never use, because I’d have just written this one in Perl if not 
required to write it in Bash by the OP.

I expect that’s why the features are obscure to you, too: once you need to step 
beyond POSIX 1988 shell levels, most people just switch to some more powerful 
language, owing to the dark days when even a POSIX shell was sometimes tricky 
to find, much less a post-POSIX shell.  (Can you say /usr/xpg4/bin/sh ?   
Yyyeahh…)

That situation threw a long shadow over the shell scripting landscape, where 
relatively few dare to tread, even today.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [OT] Bash help

[Warren Young]

On Oct 25, 2017, at 10:02 AM, Mark Haney  wrote:
> 
> I have a file with two columns 'email' and 'total' like this:
> 
> m...@example.com 20
> m...@example.com 40
> y...@domain.com 100
> y...@domain.com 30
> 
> I need to get the total number of messages for each email address.

This screams out for associative arrays.  (Also called hashes, dictionaries, 
maps, etc.)

That does limit you to CentOS 7+, or maybe 6+, as I recall.  CentOS 5 is 
definitely out, as that ships Bash 3, which lacks this feature.


#!/bin/bash
declare -A totals

while read line
do
IFS="\t " read -r -a elems <<< "$line"
email=${elems[0]}
subtotal=${elems[1]}

declare -i n=${totals[$email]}
n=n+$subtotal
totals[$email]=$n
done < stats

for k in "${!totals[@]}"
do
printf "%6d  %s\n" ${totals[$k]} $k
done


You’re making things hard on yourself by insisting on Bash, by the way.  This 
solution is better expressed in Perl, Python, Ruby, Lua, JavaScript…probably 
dozens of languages.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Apache 2.2 EOL - what is Red Hat's story for RHEL6?

[Warren Young]

On Sep 12, 2017, at 1:29 PM, Alan McKay  wrote:
> 
> I have been googling for a few weeks now and not finding anything.
> Apache 2.2 is EOL at the end of this year.
> 
> Has Red Hat announced a plan yet on what they are doing in RHEL6?
> 
> I am assuming they will up-version from 6.9 to 6.10 and as part of
> that upgrade from Apache 2.2 to Apache 2.4 ?

I’d assume they’re just going to make their own fixes, since 2.4 is not a 
compatible upgrade for many apps, e.g. anything relying on mod_perl.

We ended up needing to do a major rework of our mod_perl based application to 
make it run on CentOS 7 as a result.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Errors on an SSD drive

[Warren Young]

On Aug 11, 2017, at 1:07 PM, Robert Nichols  wrote:

>> Yeah he'd want to do an fsck -f and see if repairs are madestem.
> 
> fsck checks filesystem metadata, not the content of files.

Chris might have been thinking of fsck -c or -k, which do various sorts of 
badblocks scans.

That’s still a poor alternative to strong data checksumming and Merkle tree 
structured filesystems, of course.

> LVM certainly makes the procedure harder. Figuring out what filesystem
> block corresponds to that LBA is still possible, but you have to examine
> the LV layout in /etc/lvm/backup/ and learn more than you probably wanted
> to know about LVM.

Linux kernel 4.8 added a feature called reverse mapping which is intended to 
solve this problem.

In principle, this will let you get a list of files that are known to be 
corrupted due to errors at the block layer, then fix it by removing or 
overwriting those files.  The block layer, DM, LVM2, and filesystem layers will 
then be able to understand that those blocks are no longer corrupt, therefore 
the filesystem is fine, as are all the possible layers in between.

This understanding is based on a question I asked and had answered on the 
Stratis-Docs GitHub issue tracker:

https://github.com/stratis-storage/stratis-docs/issues/53

We’ll see how well it works in practice.  It is certainly possible in 
principle: ZFS does this today.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Btrfs going forward, was: Errors on an SSD drive

[Warren Young]

On Aug 11, 2017, at 12:39 PM, hw <h...@gc-24.de> wrote:
> 
> Warren Young wrote:
> 
>> [...]
>>>> What do they suggest as a replacement?
>> 
>> Stratis: https://stratis-storage.github.io/StratisSoftwareDesign.pdf
> 
> Can I use that now?

As I said, they’re targeting the first testable releases for Fedora 28.  
Whether, how, and on what schedule Stratis gets into RHEL will be based on how 
well those tests go.

So, if you want Stratis in RHEL or CentOS and you want it to be awesome, you 
need to get involved with Fedora.  Wishes are not changes.

> How do you install on an XFS that is adjusted to the stripe size and the 
> number of
> units when using hardware RAID?

That’s one of many reasons why you want to use software RAID if at all 
possible.  Software RAID makes many things easier than with hardware RAID.

Hardware RAID made the most sense when motherboards came with only 2 PATA ports 
and CPUs were single-core and calculated parity at double-digit percentages of 
the CPU’s capacity.  Over time, the advantages of hardware RAID have been 
eroded greatly.

> What if you want to use SSDs to install the system on?  That usually puts 
> hardware
> RAID of the question.

SSD and other caching layers are explicitly part of the Stratis design, but 
won’t be in its first versions.

Go read the white paper.

> I don´t want the performance penalty MD brings about even as a home user.

You keep saying that.  [citation needed]

> Same goes for ZFS.

You want data checksumming and 3+ copies of metadata and copy-on-write and… but 
it all has to come for free?

> I can´t tell yet how the penalty looks with btrfs,
> only that I haven´t noticed any yet.

https://www.phoronix.com/scan.php?page=article=linux_317_4ssd=2

> And that brings back the question why nobody makes a hardware ZFS controller.

They do.  It’s called an Intel Xeon. :)

All RAID is software, at some level.

> Enterprise users would probably love that, provided that the performance 
> issues
> could be resolved.

Enterprise users *do* have hardware ZFS appliances:

https://www.ixsystems.com/truenas/
https://nexenta.com/products/nexentastor

These are FreeBSD and Illumos-based ZFS storage appliances, respectively, with 
all the enterprisey features you could want, and they’re priced accordingly.

> Just try to copy a LV into another VG, especially when the VG resides on 
> different devices.

ZFS send/receive makes that pretty easy.  You can even do it incrementally by 
coupling it with snapshots.  It’s fast enough that people use this to set up 
failover servers.

> Or try to make a snapshot in another VG
> because the devices the source of the snapshot resides on don´t have enough 
> free
> space.

I don’t think any volume managing filesystem will fix that problem.  Not enough 
space is not enough space.

I think the best answer to that provided by ZFS is, “Why do you have more than 
one pool?”   Not a great answer, but it should at least make you re-justify 
your current storage design to yourself.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Btrfs going forward, was: Errors on an SSD drive

[Warren Young]

On Aug 11, 2017, at 11:52 AM, hw  wrote:
> 
> Software RAID with mdadm is a bad idea because
> it comes with quite some performance loss.

That sounds like outdated information, from the time before CPUs were fast 
enough to do parity RAID calculations with insignificant overhead.

> ZFS is troublesome because it´s not
> as well integrated as we can wish for, booting from a ZFS volume gives you 
> even
> more trouble

Those are both solvable problems, involving less resources than Fedora/Red Hat 
are throwing at Stratis.  Therefore, we can infer that they don’t *want* to 
solve those problems.

> it is rather noticeable that ZFS wasn´t designed with
> performance in mind.

You don’t get the vastly superior filesystem durability ZFS offers without a 
performance hit.  Any competing filesystem that comes along and offers the same 
features will have the same hit.

If you want burnin’ speed at all costs, use ext4.

> That doesn´t even mention features like checksumming

That is intended to be in Stratis, but not until 3.0, which is not yet even 
scheduled.

This is part of what I meant by my speculation in a prior post that Stratis 
won’t be ready for prime time until EL9.  Plan accordingly.

> deduplication, compression

Also Stratis 3.0.

> and the creation of subvolumes (or their equivalent)

That should be possible with the earliest testable versions of Stratis, as LVM2 
provides this today:

https://goo.gl/2U4Uio

> It also doesn´t mention
> that LVM is a catastrophy.

I will grant that it’s an utter mess to manage by hand with the current tools.  
Fixing that is one of the primary goals of the Stratis project.

Complaining about it on the CentOS list is not the right way to fix it.  If you 
want Stratis to not suck, they’re targeting the first releases of it for Fedora 
28.  

There’s also the GitHub issue tracker.  Let them know what you want Stratis to 
be; the Stratis developers are not likely to schedule features “properly” if 
they misunderstand which ones matter most to you.

> I could use hardware RAID

My sense is that the Linux-first hardware RAID card market is shrinking and 
maybe even dying.

With 10-dumb-SATA motherboards readily available, I think it’s time for 
hardware RAID to die in Linux, too, if only in the workstation and low-end 
server segment, where 10-ish drives is enough.

> So far, it´s working fine, but I´d rather switch now than experience
> desaster.

One of your options is to take advantage of the fact that CentOS major releases 
overlap in support: EL7 will still be supported when EL9 comes out.  All of 
this should be greatly clarified by then.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Btrfs going forward, was: Errors on an SSD drive

[Warren Young]

On Aug 11, 2017, at 11:00 AM, Chris Murphy  wrote:
> 
> On Fri, Aug 11, 2017 at 5:41 AM, hw  wrote:
>> That´s one thing I´ve been wondering about:  When using btrfs RAID, do you
>> need to somehow monitor the disks to see if one has failed?
> 
> Yes.
> 
> The block layer has no faulty device handling

That is one of the open questions about Stratis: should its stratisd act in the 
place of smartd?

Vote and comment on its GitHub issue here:

https://github.com/stratis-storage/stratisd/issues/72

I’m in favor of it.  The daemon had to be there anyway, it makes sense to push 
SMART failure indicators up through the block layer into the volume manager 
layer so it can react intelligently to the failure, and FreeBSD’s ZFS is 
getting such a daemon soon so we want one, too:

https://www.phoronix.com/scan.php?page=news_item=ZFSD-For-FreeBSD

>>> Also FWIW Red Hat is deprecating Btrfs, in the RHEL 7.4 announcement.
>>> Support will be removed probably in RHEL 8. I have no idea how it'll
>>> affect
>>> CentOS kernels though. It will remain in Fedora kernels.

I rather doubt btrfs will be compiled out of the kernel in EL8, and even if it 
is, it’ll probably be in the CentOSPlus kernels.

What you *won’t* get from Red Hat is the ability to install EL8 onto a btrfs 
volume from within Anaconda, the btrfs tools won’t be installed by default, and 
if you have a Red Hat subscription, they won’t be all that willing to help you 
with btrfs-related problems.

But will you be able to install EL8 onto an existing XFS-formatted boot volume 
and mount your old btrfs data volume?  I guess “yes.”

I suspect you’ll even be able to manually create new btrfs data volumes in EL8.

>> That would suck badly to the point at which I´d have to look for yet another
>> distribution.  The only one ramaining is arch.

openSUSE defaults to btrfs on root, though XFS on /home for some reason:

https://goo.gl/Hiuzbu

>> What do they suggest as a replacement?

Stratis: https://stratis-storage.github.io/StratisSoftwareDesign.pdf

The main downside to Stratis I see is that it looks like 1.0 is scheduled to 
coincide with RHEL 8, based on the release dates of RHELs past, which means it 
won’t have any kind of redundant storage options to begin with, not even 
RAID-1, the only meaningful RAID level when it comes to comparing against btrfs.

The claim is that “enterprise” users don’t want software RAID anyway, so they 
don’t need to provide it in whatever version of Stratis ships with EL 8.  I 
think my reply to that holds true for many of us CentOS users:

https://github.com/stratis-storage/stratis-docs/issues/54

Ah well, my company has historically been skipping even-numbered RHEL releases 
anyway due to lack of compelling reasons to migrate from the prior odd-numbered 
release still being supported.  Maybe Stratis will be ready for prime time by 
the time EL9 ships.

>> removing btrfs alltogether would be taking living in the past too
>> many steps too far.

The Red Hat/Fedora developers are well aware that they started out ~7 years 
behind when they pushed btrfs forward as a “technology preview” with RHEL 6, 
and are now more like 12 years behind the ZFS world after waiting in vain for 
btrfs to catch up.

Basically, Stratis is their plan to catch up on the cheap, building atop 
existing, tested infrastructure already in Linux.

My biggest worry is that because it’s not integrated top-to-bottom like ZFS is, 
they’ll miss out on some of the key advantages you have with ZFS.

I’m all for making the current near-manual LVM2 + MD + DM + XFS lash-up more 
integrated and automated, even if it’s just a pretty face in front of those 
same components.  The question is how well that interface mimics the end user 
experience of ZFS, which in my mind still provides the best CLI experience, 
even if you compare only on features they share in common.  btrfs’ tools are 
close, but I guess the correct command much more often with ZFS’ tools.

That latter is an explicit goal of the Stratis project.  They know that 
filesystem maintenance is not a daily task for most of us, so that we tend to 
forget commands, since we haven’t used them in months.  It is a major feature 
of a filesystem to have commands you can guess correctly based on fuzzy 
memories of having used them once months ago.

> Canonical appears to be charging ahead with OpenZFS included by
> default out of the box (although not for rootfs yet I guess)

Correct.  ZFS-on-root-on-Ubuntu is still an unholy mess:

https://github.com/zfsonlinux/zfs/wiki/Ubuntu

> I can't tell you for sure what ZoL's faulty device behavior is
> either, whether it ejects faulty or flaky devices and when, or if like
> Btrfs is just tolerates it.

Lacking something like zfsd, I’d guess it just tolerates it, and that you need 
to pair it with smartd to have notification of failing devices.  You could 
script that to have automatic spare replacement.

Or, port 

Re: [CentOS] Errors on an SSD drive

[Warren Young]

On Aug 10, 2017, at 2:17 PM, John R Pierce <pie...@hogranch.com> wrote:
> 
> On 8/10/2017 1:12 PM, Warren Young wrote:
>> You want those pages to get swapped out quickly so that the precious RAM can 
>> be used more productively; by the buffer cache, if nothing else.
> 
> most modern virtual memory OS's don't swap out unused pages, instead, they 
> swap IN accessed pages directly from the executable file.  only thing written 
> to swap are 'dirty' pages that have been changed since loading.

Is that not a distinction without a difference in my case?

Let’s say I have a system with 256 MB of free user-space RAM, and I have a 
binary that happens to be nearly 256 MB on disk, between the main executable 
and all the libraries it uses.

Question: Can my program allocate any dynamic RAM?

The OS’s VMM is free to use addresses beyond 0-256 MB, but since we’ve said 
there is no swap space, everything swapped in must still be assigned a place in 
physical RAM *somewhere*.

Is there a meaningful distinction between:

Scenario 1: The application’s first few executable pages are loaded from disk, 
a few key libraries are loaded, then the application does a dynamic memory 
allocation, then somehow causes all the rest of the executable pages to be 
loaded, running the system out of RAM.

Scenario 2: The application is entirely loaded into RAM, nearly filling it, 
then the application attempts a large dynamic memory allocation, causing an OOM 
error.

Regardless of the answer to these questions, I can tell you that switching that 
web site to a more efficient web application stack allowed us to shrink the VPS 
from a 256 MB plan, under which it would occasionally crash and require a 
reboot, to a 64 MB plan, under which the site has been rock-solid.  Same VPS 
provider, same web site content, same user-facing functionality.

If I’d had the ability to assign swap space, I probably could have gotten away 
with a 64 MB VPS plan with the inefficient web technology, too.  They gave me 
plenty of disk space with that plan.

(And no, swapon /some-file is no solution here.  The VPS technology simply 
didn’t allow swap space, even from a swap file on one of the system disks.  It 
wasn’t simply an inability to add a swap partition.)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Errors on an SSD drive

[Warren Young]

On Aug 10, 2017, at 10:46 AM, mad.scientist.at.la...@tutanota.com wrote:
> 
> is that because the drive is compressing the information?

No.  I believe by “probabilistic representation” the parent poster simply means 
that in any given data cell, you don’t have a hard “1” or “0”, you have some 
voltage potential which can be interpreted as some number of 1 or 0 bits, often 
3 bits or more.

Between that fact and wear-leveling, you can’t take a simple voltage 
measurement on a data cell and say, “This cell contains 011.”  You need more 
smarts about what’s going on to turn the voltage reading into the correct value.

As the drive’s data cells wear out, the drive’s ability to do that correctly 
and reliably degrade.  Thus cell death, thus drive death, thus filesystem 
death, thus backups, else sadness.

And please don’t top-post.

A: Yes.

Q: Are you sure?

A: Because it makes the flow of conversation more difficult to read.

Q: Why shouldn’t I top-post?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Errors on an SSD drive

[Warren Young]

On Aug 10, 2017, at 2:07 AM, John Hodrien  wrote:
> 
> For a well configured desktop that rarely needs to swap, I struggle to see the
> load on the SSD as being significant, and yet obviously the performance of an
> SSD would make it ideal for swap.

I agree.

It’s a bad idea to do without swap even if you almost never use it, because 
today’s bloated apps often have many pages of virtual memory they rarely or 
never actually touch.  You want those pages to get swapped out quickly so that 
the precious RAM can be used more productively; by the buffer cache, if nothing 
else.

I once used a web application server on a headless VPS that still had GUI 
libraries linked to its binary because one of the underlying technologies it 
uses was also used in a GUI app, and it was too difficult to tear all that GUI 
code out, even if it was never called.  Because the VPS technology didn’t 
support swap, I directly paid the price for those megs of unused (and 
unusable!) libraries in my monthly VPS rental fees.

> Coo, I've never seen a disk actually shrink due to failed sectors.  I don't
> think I've got an SSD into a worn state yet to see this.

Me, neither.  I’m pretty sure the spare sector pool’s size isn’t reported to 
the OS, and the drive isn’t allowed to dip into the sectors it does expose 
externally for spares.  

When the spare pool is used up, the drive just starts failing in a way that 
even SMART can see.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] claiming unsused space back

[Warren Young]

On Jul 31, 2017, at 4:27 PM, Leroy Tennison  wrote:
> 
> some commands (or command options) are only supported on later releases, the 
> man pages don't say this.

You only run into that problem when trying to use man pages from one system but 
then run commands on a very different system.  The man pages actually installed 
on the system you’re running the command on lists only those options that are 
supported by that version of the command.

> Does anyone know of a source of information listing the command, option and 
> version it is implemented in?

The closest thing I’m aware of is the man page collection at unix.com:

http://www.unix.com/man-page/linux/1/ls/

They don’t have man pages for absolutely every version of Linux — that would 
require hundreds of sets! — and it only includes commands in the base system, 
not those for add-on packages.

In this particular case, I suspect the problem is that you haven’t got the 
libguestfs-tools-c package installed, which is what owns the virt-sparsify 
command.  And I found that out with one Google search and one “yum search” 
command.

With that package installed, now you can say “man virt-sparsify” to find out 
what the CentOS 7 version of that command understands.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] claiming unsused space back

[Warren Young]

On Jul 31, 2017, at 7:28 AM, Leroy Tennison  wrote:
> 
> if you have found Debian commands, you're doing better than me.  What are 
> they?

I’m not aware of a generic Debian-to-CentOS command translation dictionary.  
You’ll have to be specific about the commands you’re not finding.

Almost all of the commands you can run on a Debian system apply to a CentOS 
system, and vice versa.  The main differences today are in the packaging 
system.  Prior to the systemd takeover of the world, there were also 
significant command differences in the init system.

(See, haters, there’s actual value in systemd!)

Anyway, your `dd` command will run just fine on CentOS.  The only thing I’d 
look at changing is that it will only affect the root filesystem, which may not 
include all of the other filesystems you want to affect.  Post your mount table 
(i.e. output of the `mount` command) if you want advice here.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] claiming unsused space back

[Warren Young]

On Jul 31, 2017, at 7:50 AM, Fred Smith  wrote:
> 
> On Mon, Jul 31, 2017 at 08:28:49AM -0500, Leroy Tennison wrote:
>> dd to totally fill the partition 
> 
> I may be blind, but I don't seehow that technique can "reclaim" any space.

In addition to the OP’s qemu case, zeroing the free space can also be valuable 
when building binary OS images from physical media.

The first time you do it with a fresh drive, the disk image contains only what 
you put onto the drive.  Then later when you update that drive for the next 
release, you cause files to be overwritten, thus leaving outdated copies of 
file system blocks laying around which you don’t want to be dd’d into the 
resulting disk image.

Zeroing the free space not only prevents inclusion of these discarded FS 
blocks, they compress better, too.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Fedora bugs and EOL [was Re: CentOS users: please try and provide feedback on Fedora] Boltron

[Warren Young]

On Jul 28, 2017, at 11:56 AM, hw  wrote:
> 
> Matthew Miller wrote:
>> On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote:
>>> What?s the point of doing this with Fedora?  It?s not like bugs
>>> were fixed before Fedora is EOL and all reports are forgotten.
>> 
>> Many bugs are fixed in Fedora. Many more bugs are fixed in the
>> upstreams.
> 
> Contributions are usually not wanted, despite what all projects tell
> you.

The main reason contributions are rejected at the level of this mailing list is 
that they’re being offered at the wrong level.

CentOS is really hard to fix directly, because virtually none of the work 
product of the CentOS maintainers goes into writing or patching the software 
that is distributed.  Fixes need to happen at the upstream levels: RHEL, 
Fedora, or the individual software project.

This list is mainly about using CentOS as we find it today, not about driving 
its future, because its future is largely driven by the upstreams.

If you’ve been trying to get fixes into the upstream software projects, then I 
can tell you as the lead maintainer of a few open source software projects and 
contributor to many others, there are many good reasons not to accept random 
drive-by patches:

1. No license given.  This may mean no contributor agreement was signed for 
projects that require it, or simply no explicit license on the contributed 
files.  The default in the civilized world is full copyright, all rights 
reserved, so you can’t just put a set of changes online and expect others to 
merge them into the official source base.

2. ABI breakage.  Many projects restrict any change that would break an ABI to 
major version transitions.

3. API breakage.  If the project is a library, you generally can only add new 
interfaces, not remove or change existing ones, except at major version 
transitions.

4. Does not build on all target systems, no tests, patch doesn’t apply cleanly 
to the development branch, bad code formatting, poor variable naming, etc.  
Some projects will take a half-assed patch and do the finishing work on it for 
you, but not all will.

5. Philosophy mismatch.  If your patch changes how something behaves and that 
behavior change doesn’t match how the project maintainer wants things to work, 
you’re probably stuffed.  Quite frankly, your opinion doesn’t matter as much as 
that of the person who designed the system and has been maintaining it for the 
last N years.  As long as that person holds well-regarded opinions, his project 
is likely to remain unforked, and your contribution will remain disregarded.

I can summarize all of the above with, “It’s difficult to work with other 
people,” but that’s no particular failing of open source software.  That’s just 
people.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Using GIMP on Centos-7, problem

[Warren Young]

On Jul 30, 2017, at 1:15 PM, Fred Smith  wrote:
> 
> I find the installation instructions (for the binary tarball) are
> minimal

Your link to the binary tarball is also minimal, to the point of being 
nonexistent. :)

> and whatever I do, it doesn't seem to appear in the gimp
> menus, as it should.

It sounds like it was made for a different system, with Gimp installed in a 
different location.  As a rule, you can’t use complicated binary packages made 
on one Linux type OS on a greatly different one.

> I also tried building the source, but even "autoconfig" spewed some
> errors that are greek to me

1. What is “autoconfig”?  Do you mean autoconf, autoreconf, autogen.sh, or 
something else?

2. By leaving the messages out, you’re implying that you think the messages 
will be Greek to everyone else here, too.

Anyway, I was able to build the plugin with:

 $ git clone https://github.com/bootchk/resynthesizer.git
 $ cd resynthesizer
 $ sudo yum install gimp-devel
 $ ./autogen.sh
 $ make -j11 && sudo make install

I have no idea if it runs, because I don’t use Gimp on this box, nor on any 
other.  Still, I think that’s got it solved.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Physically moving a mail server vs. cached DNS

[Warren Young]

On Jul 1, 2017, at 3:00 AM, Pete Biggs  wrote:
> 
>> In your experience, what's the "longest" a DNS cache is configured to
>> keep outdated information? A day? A week? A month? Longer?
>> 
> That is controlled by the TTL (time to live) entry.

…which is often under your control as the domain owner.

A common practice when moving hosts between providers like this is to 
temporarily shorten TTL from its normal working value to something much 
shorter, wait out the original TTL, do the move, wait out the new shorter TTL, 
and put the TTL back up to its previous value.

For example, if the normal TTL for the domain is 24 hours, then 24+ hours 
before the move, you could set TTL to 1 hour, then move the host 24+ hours 
later, so that any client that queries the DNS for that domain will get the 
1-hour TTL.  Then 1 or more hours after you’re sure everything is fine, put TTL 
back to 24 hours.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Markdown editor for CentOS 7?

[Warren Young]

On Jun 16, 2017, at 3:27 AM, Nicolas Kovacs  wrote:
> 
> For the time being, I'm using my good old Vim editor for writing it. I
> turned off syntax highlighting, since this produces random results with
> Markdown.

I write Markdown in Vim on CentOS 7 with the stock Markdown syntax highlighting 
rule set regularly, and I have never seen it mark text incorrectly.

What you may be running into here is that there are multiple flavors of 
Markdown, and some rendering engines are more forgiving of syntax variances 
than others.  The flavor tolerated by the Vim syntax file is fairly strict.  If 
you stick to what it considers acceptable, it should render correctly 
everywhere.

For example, many Markdown engines tolerate this:

* Bullet item 1
* Bullet item 2

But if you actually read the Markdown spec [1], you will find that the Vim 
syntax highlighter is right to reject it.  It should be:

*   Bullet item 1
*   Bullet item 2

That is, the text needs to start in the fourth column relative to the bullet.

The Vim Markdown rules also tend not to cope well with nonstandard Markdown 
extensions like ASCII art tables.  (Core Markdown only supports HTML s.)

[1]: https://daringfireball.net/projects/markdown/syntax

> I wonder if there's a good WYSIWYG
> editor for Markdown, or at least something where I can check locally
> what the page looks like.

I rarely see CentOS’s GUI, much less make enough use of it, but if I had to get 
a WYSIWYG Markdown view on CentOS, I’d do the same thing I do on Chrome OS: use 
StackEdit:

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

Re: [CentOS] C7, systemd, say what?!

[Warren Young]

On Jun 9, 2017, at 10:08 AM, Michael Hennebry  
wrote:
> 
> On Thu, 8 Jun 2017, m.r...@5-cent.us wrote:
> 
>> Maybe we need another mailing list, like alt.religion.editors*, we could
>> have alt.religion.systemd 
>> 
>> mark
>> 
>> * vi, not emacs! Nya
> 
> You mean 6, right?

The developer of Sublime Text is hard at work on his third attempt at a Vi 
emulating plugin, apparently having run into walls with the prior two attempts. 
 He is calling his latest attempt…Six.  :)

http://www.sublimesix.com/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C7, systemd, say what?!

[Warren Young]

On Jun 7, 2017, at 2:24 PM, Always Learning  wrote:
> 
> What is the advantage of patches over a virgin version that can be
> subsequently patched ?

Doing the change as a patch to the upstream RPM means that, most of the time, 
you can just apply your patch again whenever the upstream RPM changes.  If the 
patch applies cleanly, chances are that your port update is done, right there.

If you fork the package base entirely, you have to backport each change from 
upstream yourself, which is a much bigger burden.  Chances are good that you’ll 
end up forking the whole OS that way, rather than creating a variant spin of it.

The fork-the-whole-thing model would make sense if you’re starting from C6, 
since it’s on the downhill side of the patch rate curve now, so that there will 
be little backporting necessary.  And soon, a maintainer of a C6 fork would be 
on his own anyway, when the upstream patches dry up.

Whereas if you start with C7, you’d like to have the benefit of the upstream 
changes while you do the smallest amount of work you can while achieving your 
end of ridding C7 of systemd.  The project is likely to take years to complete 
— after all, it took many years for systemd to get to where it is now — so 
there’s a good chance you could complete the project before you’re left with an 
EOL’d C7 base package set.

If you look inside many RPMs, they are composed of the untouched upstream 
source tarball plus a series of patches.  One RPM I looked into recently had 
something like 30 separate patches applied to it, some from Fedora, some from 
Red Hat, Inc, and potentially (though not in this specific case) some from the 
CentOS project.  This is the normal way of doing these things.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C7, systemd, say what?!

[Warren Young]

On Jun 7, 2017, at 1:02 PM, John R Pierce  wrote:
> 
> every RPM that interacts with systemd will need to be 'fixed' to do it the 
> old way, with init.d scripts. repositories like postgres, EPEL, etc won't 
> work, either, as their C7 packaged daemons are all configured to use systemd.

That’s just skimming the surface.

The real hard bits come from the way systemd hooks into the whole FreeDesktop 
infrastructure and vice versa.  (e.g. dbus is now inextricably part of systemd, 
and many FreeDesktop interactions happen via dbus.)  This is why the BSDs are 
either dropping GNOME and KDE (e.g. Lumina in TrueOS) or have badly lagging 
ports compared to the upstream version.

I suspect it’s probably easier to start with C6, then backport as much as is 
possible without dragging in any systemd stuff, the same way the BSDs are doing.

Good luck to y’all.  Sincerely.  I plan to keep on using C7, warts and all.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] C7, systemd, say what?!

[Warren Young]

On Jun 7, 2017, at 9:31 AM, Mark Haney  wrote:
> 
> On 06/07/2017 11:24 AM, James Hogarth wrote:
>> 
>> Mark stop with the flame baiting please.
>> 
>> This is nothing systemd specific - and keep in mind /var/tmp is a
>> persistent temp area unlike /tmp which as it's tmpfs by default is of
>> course emptie don boot.
> I would wholeheartedly disagree.  This IS something systemd specific.

I’m sure James Hogarth meant that circular symlink chains are a problem for any 
program, not just for systemd.

Now if you can show that systemd *generated* this chain, you might have a point.

Since we have only one report of this, it seems unlikely that systemd is doing 
this.  Surely we’d have thousands of reports of this is something systemd 
always did.

> I have never seen init.d blow itself up over bloody symlinks.

Only the systemd-readahead process failed.  It’s an optional component.  
systemd is clearly not “blown up” on Mark’s system, else he couldn’t have 
gotten to a login prompt.

This optional component diagnosed an actual problem, that’s all.

> The readahead, while /possibly/ nice isn't at all necessary on modern 
> hardware.

Explain then why a VM containing a given OS generally boots faster the second 
time on a given host than rebooting the same OS on the bare hardware running 
that VM host.

RAM caches matter more today than they ever did, due to the vast disparity 
between storage access speeds in a modern system.  Precharging the caches is 
still a good idea in 2017.

> I want my hardware to boot consistently, not bomb like an Adam Sandler movie 
> because of /symlinks/.

Hyperbolic much?

> I'd be willing to bet a year's salary most admins hate systemd with a passion.

I think you’re basing that bet on data generated by an angry noisy minority.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] more recent perl version?

[Warren Young]

On Jun 3, 2017, at 4:13 AM, hw  wrote:
> 
> I´m using CGI as a simple
> means for the users to use the programs...There are less than 10 users.

If we’re talking less than one full page hit per second, then it doesn’t much 
matter what technology you use.  You won’t be able to tell from the end user’s 
perspective.

(“One” meaning the page and all its static assets, not the inflated count from 
all the PNGs, JS files, etc. that may be pulled in by the page proper.)

> Perl is pretty fast, and most of the work is being done by the database,
> so I´m not sure how using an alternative to CGI could make things go faster.

There are many reasons CGI is relatively slow.

1. If you have many connections per second, you need a parallelizable 
technology to make things go fast.  If everything chokes down to a single 
thread, you’ve got a serious bottleneck when the CPS count gets high enough.

2. CGI re-launches the cgi-bin/* programs on every page hit.  Since Perl 
doesn’t leave behind “compiled” forms of the program as some other dynamic 
languages do (e.g. *.pyc in Python, *.beam in Erlang) it has to do the entire 
re-compilation over again.

With FastCGI or Plack, the app remains running once launched, serving hit after 
hit using the same instance.

3. A follow-on advantage from the above is that you also don’t have to 
re-establish other runtime resources like DB connections, file handles, 
application state, etc.  You can just keep it in RAM and access it repeatedly 
on each hit.

But again, down below about 1 CPS, the differences cease to matter, unless 
you’ve got the sort of app where the difference between a response time of 50 
vs 100 ms matters.

>>> Test have shown that
>>> lighttpd apparently is somewhat faster than apache2
>> 
>> This is generally true only at fairly high loads, up in the thousands of 
>> connections per second.  Distinguishing this also requires that the 
>> bottleneck be in the web server, not in the web app it’s serving.
> 
> I simply had the impression that responses came faster, with
> me being the only user.

Not really.  With only 10 clients, you likely have 1 or 0 concurrent hits at 
any one time, which means any web server is probably fast enough.  You could 
probably swap out Apache for HTTP::Server::Simple and still not notice the 
speed hit.

> So what would speak against using lighttpd?

If you had to serve thousands of CPS or needed to serve the app in very little 
RAM, it might be worth switching from Apache to nginx or lighttpd, but since 
neither applies in your case, you might as well stick with Apache, since that’s 
the standard web server in CentOS.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] more recent perl version?

[Warren Young]

On Jun 2, 2017, at 5:05 AM, hw <h...@gc-24.de> wrote:
> 
> Warren Young wrote:
>> 
>> There are various options.  We use mod_fcgid + Plack here.
> I need to look into that when I have time. 

I wonder if it wouldn’t have been faster to just backport the app to Perl 5.16? 
 How hard could it be?  It’s not like Perl 5.16 is a hopelessly lame and 
incapable language.

The recommendation to replace mod_perl with mod_fcgid comes from the RHEL 7 
release notes: http://goo.gl/fZxHw9

After sending that message, I remembered that we rejected that option once we 
found out that when you build your app under Plack, it serves content via a 
Perl web server using a standard interface called PSGI.  That Perl web server 
normally binds to localhost on a high-numbered TCP port, so we just stood 
Apache up in front of it as a reverse proxy.  That avoids the security hassles 
of binding to TCP port 80, and it lets us foist the static content serving load 
off on Apache, so that the Perl layer serves only dynamic content.

There are many PSGI-aware web servers:

http://plackperl.org/#servers

The default used by Plack is HTTP::Server::Simple, which is probably fast 
enough for your purposes if CGI remains appropriate for your app.

If you were already trying to get off CGI to make the app faster, many of the 
alternatives in that list will get you that speed.

The mod_fcgid method may be easier to port to, since you’re already using CGI, 
however.

> Test have shown that
> lighttpd apparently is somewhat faster than apache2

This is generally true only at fairly high loads, up in the thousands of 
connections per second.  Distinguishing this also requires that the bottleneck 
be in the web server, not in the web app it’s serving.

Since your app is currently running via CGI, one of two conditions is true:

1. You have chosen well: CGI is appropriate for your application, in which case 
all web servers with the features you need are interchangeable, because the 
bottleneck is CGI, not the web server.

2. You have chosen poorly: CGI is slowing your app down enough that end users 
notice the speed hit, in which case you need to get off CGI before you start 
chasing nonstandard web servers, because speeding up the web server won’t solve 
the primary bottleneck.

(“Nonstandard” meaning that lighttpd is not in the stock CentOS 7 repos.  You 
have to reach out to EPEL to get it.)

This is not to say that different web servers don’t have advantages even in the 
CGI case.  I run nginx in one extra-small VPS because I don’t have the RAM to 
run Apache.  I couldn’t put enough load on that server to tell any speed 
difference between Apache and nginx without running it out of CPU or network 
bandwidth first.

> it can be difficult to run systems using ancient software.

“You keep using that word.  I do not think it means what you think it does.”

   — Inigo Montoya

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

Re: [CentOS] more recent perl version?

[Warren Young]

On May 24, 2017, at 1:58 PM, hw  wrote:
> 
> It seems that lighttpd uses the perl version that is assigned in
> the configuration

This is one of the advantages of Plack vs mod_perl, by the way: decoupling the 
Perl version from the web server version.

> while ignoring the LIBRARY_PATH variable set with mod_setenv

Are you certain you don’t mean LD_LIBRARY_PATH here?

https://stackoverflow.com/questions/4250624/

> Even with a shell script as wrapper that sets and exports LIBRARY_PATH,
> perl can not find the library.  Trying to set LIBRARY_PATH for lighttpd
> through systemd also doesnīt work.

Beware that some layers of the OS actively redefine LD_LIBRARY_PATH in order to 
avoid security exploits.  I wouldn’t be surprised if systemd did that in some 
cases, for good cause.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] more recent perl version?

[Warren Young]

On May 24, 2017, at 9:38 AM, hw <h...@gc-24.de> wrote:
> 
> Warren Young schrieb:
>> On May 24, 2017, at 7:05 AM, hw <h...@gc-24.de> wrote:
>>> apache uses mod_perl
>> 
>> mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 
>> 7.
> 
> What is it using instead?

There are various options.  We use mod_fcgid + Plack here.

And atop that, Dancer, if you care.  http://perldancer.org/  Join me on the 
Dancer ML if you want to talk further about it.

>> I hope this does not strike you as inconsistent with respect to my prior 
>> posts, since that would be to construct a false equivalence between 
>> abandoned software and maintained stable software that is getting no new 
>> features.
> 
> Not at all --- the point is that software usually becomes abandoned
> once a more recent version becomes available.

And that’s what we keep trying to tell you: in the RHEL/CentOS world, that 
simply is not the case, because there is a multibillion-dollar entity ensuring 
that it is not so.

All hail the benefactors!
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Warren Young]

On May 24, 2017, at 9:37 AM, Tate Belden  wrote:
> 
> The time transmitted from WWV is not Mountain Time.

I should have split the paragraph, because I didn’t mean to imply that that was 
the case.

My point in mentioning the transmission location is to show that it’s probably 
a thousand km or more from wherever you are, since the spots in the US within 
the 1000 km radius are some of the least populous parts of the US.

When most people think of “radio,” they think of the towers on the big hill 
just outside of town, or the faux palm tree concealing the cell phone 
transmitter a mile down the road.

WWVB is in a different sub-class of “radio” from those two.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Warren Young]

On May 24, 2017, at 8:52 AM, Chris Adams <li...@cmadams.net> wrote:
> 
> Once upon a time, Warren Young <war...@etr-usa.com> said:
>> a. It’s transmitting from a fixed location in a time zone you probably 
>> aren’t in — US Mountain — being the least populous of the lower 48’s four 
>> time zones.  You therefore have to configure time zone offset and DST rules, 
>> which means additional software if you want it to track changes to these 
>> things.  There were 10 batches of such changes last year!
> 
> This really has no bearing on time source; none of the commonly-used
> time sources (satellite, terrestrial radio, or network) carry time zone
> information

In editing my prior reply, I removed the observation that GPS solves problem 
“a” by telling you where you are in the world, as well as what the UTC time is.

It still has problems b and c, though.

> (although WWVB does carry a bit to indicate if US DST rules
> are in effect).

…which is of no help when the DST rules are hard-coded into the clock, as they 
are so frequently.  I had to discard a few WWVB clocks when the last DST rules 
went into effect.

>> GPS time is a much better solution, but it’s power-hungry, as you probably 
>> know from running GPS on your smartphone.  This rules it out for laptops.
> 
> Not exactly; laptop batteries' capacity is an order of magnitude larger
> than phone batteries.

Sure, but it’s still a market where people buy based on benchmarks.  The laptop 
that gets 20 minutes less battery life but has great time accuracy even when 
not on the Internet will lose in the market.

>> The GPS transmitters probably have a higher received signal strength than 
>> WWVB
> 
> No, GPS is lower signal strength than WWVB, at least for most of the
> continental US (although WWVB signal strength varies significantly based
> on the time of day, because it is a low frequency signal).

I went looking, and you’re right.  GPS satellites transmit at 0.5 kW and WWVB 
at 70 kW, and WWVB has the additional advantage of less distance to transmit. 

(21000 km from orbit to Earth surface vs ~3000 km from Fort Collins to either 
Bangor, Maine or Miami.)

Regardless, that's another reason not to do this as a matter of general policy.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] System Time Source

[Warren Young]

On May 24, 2017, at 7:53 AM, Chris Olson  wrote:
> 
> One of our STEM interns recently observed that there are
> inexpensive clocks that sync via radio to standard time
> services.

There are two major types:

1. WWVB and its equivalents in other countries:

https://en.wikipedia.org/wiki/WWVB

2. GPS clocks.


WWVB has several problems:

a. It’s transmitting from a fixed location in a time zone you probably aren’t 
in — US Mountain — being the least populous of the lower 48’s four time zones.  
You therefore have to configure time zone offset and DST rules, which means 
additional software if you want it to track changes to these things.  There 
were 10 batches of such changes last year!

https://mm.icann.org/pipermail/tz-announce/2016-November/thread.html

b. It’s a weak signal.  Unless you’ve got a big antenna or are positioning the 
receiving device near a window, you probably can’t receive the WWVB signal 
reliably.

c. Computers have major RFI shielding problems, which is why they’re typically 
placed in metal boxes.  (Even plastic-cased laptops have metal boxes inside.)  
That means you have to have an external antenna even in the best case.  Now 
apply what you know about Wifi reliability to the problem of receiving a signal 
from a different *time zone*.

I happen to be in the Mountain time zone, and it doesn’t take too much to 
shield our WWVB clocks from the signal.  I can only imagine how much easier it 
is out on the coasts.


GPS time is a much better solution, but it’s power-hungry, as you probably know 
from running GPS on your smartphone.  This rules it out for laptops.

The GPS transmitters probably have a higher received signal strength than WWVB, 
but cinderblock walls and grids of 42U equipment racks block the GPS signal 
quite well.  This is why data centers with such clocks generally have to run an 
antenna to the outside for their clock.  That makes it far more expensive than 
just connecting to an upstream NTP server.

> When I was a student, such questions would have earned me
> extra homework assignments.

So do I get an “A”? :)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] more recent perl version?

[Warren Young]

On May 24, 2017, at 7:05 AM, hw  wrote:
> apache uses mod_perl

mod_perl was dropped from Apache in 2.4, and Red Hat followed suit with RHEL 7.

> But there is a package 'rh-perl524-mod_perl’.

That must be someone’s backport.  As someone who migrated a mod_perl based app 
off of mod_perl several years ago, I recommend that you do not use it, unless 
you have old mod_perl based software that you cannot migrate to newer 
technologies like FastCGI, Plack, etc.

I hope this does not strike you as inconsistent with respect to my prior posts, 
since that would be to construct a false equivalence between abandoned software 
and maintained stable software that is getting no new features.

Also, you speak of CGI.  CGI is not at all the same thing as mod_perl.  You use 
one or the other, not both together.  You’d know it if you were using mod_perl.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] more recent perl version?

[Warren Young]

On May 24, 2017, at 6:02 AM, hw <h...@gc-24.de> wrote:
> 
> Warren Young schrieb:
>> 
>> CentOS 5 just left supported status, which shipped Perl 5.8.8 from first 
>> release to last
> 
> Living in the past seldwhen is a good idea.

I don’t propose to teach you about my problems — they are, after all, mine, and 
I’m coping with them quite well, thank you — but I’ll give you a glimpse into 
someone else’s as a lesson: the San Francisco Bay Area Rapid Transit System was 
still running on PDP-8s as of several years ago, and may still be doing so.

As I understand it, they were using a modified PDP-8/e, which is 1970 tech.  
Note that I didn’t say “1970’s.”  I mean the year nineteen hundred and seventy, 
A.D.  The PDP-8/e is just an enhanced version of the original PDP-8 from 1965, 
which is itself not a huge departure from the PDP-5, from 1963.

And you know what?  The PDP-8/e is still well suited to the task.  Trains 
haven’t changed that much in the intervening decades, and the construction 
techniques used by that era of computer mean it’s still repairable with little 
more than a soldering iron.

We have 40-cent microcontrollers with equivalent computing power to a PDP-8/e 
today that run on far less power, but you’d have to pile up a bunch of I/O 
interfacing in front of them to make it as electrically capable and robust as a 
PDP-8/e, and you’d have to re-develop all the software, too.

The modern tendency would not be to use one of those 40-cent micros, it would 
instead be to put a gigahertz class Linux PC in its place, with all the 
concomitant risks.

Try getting a modern Internet worm into a PDP-8!  Good luck not blowing the 4k 
word field boundary.

>> If this sort of stance seems risible to you, you probably shouldn’t be using 
>> CentOS.  This is what distinguishes a “stable” type of OS from a “bleeding 
>> edge” one.
> 
> When a version of a software has been released 20 years ago,

Eleven: https://dev.perl.org/perl5/news/2006/perl-5.8.8.html

…which makes it younger than the C89 standard some still stick to over in C 
land.  And younger than C99.  And younger than C++-98.  And C++-93.

By your lights, the C/C++ world is positive decrepit for not immediately 
tossing everything and insisting on C11 and C++-14.

> that doesn´t mean it´s more stable than a version of that
> software which is being released today.

Actually, it does, provided it’s still being maintained, as Perl 5.8.8 was up 
to a few months ago.  Software that gets no new features also gets no new bugs. 
 Therefore, the overall bug count can only go down.

The distinction you may be looking for is that there is a fine line between 
“stable” and “moribund.”  RHEL/CentOS rides that line much closer than some 
other OSes, but it actively stays on the good side of the line.

After that end-of-support date, sometimes all it takes to slip over to the bad 
side of the line is a new exploit or similar, but decades-old exploit targets 
are very rare.

More commonly, something changes in the environment to make the old software 
unsuitable, as happened with BIND 4 and Apache 1.3.  You couldn’t drag either 
of those forward into the modern world without major rework, so people running 
on them were forced to transition.

I don’t see that happening with Perl 5.8.  It was an uncommonly good release of 
a language that was already quite stable by that point.  It is, after all, the 
fourth major version after Perl 5.0.  You’d *expect* it to be stable by that 
point.

The only question then, is whether you can live without the new features.  I 
can.

> what about the bug fixes?

Red Hat was backporting them up until a few months ago.

Now we just get to see how fast it bit-rots without Red Hat’s support.

I don’t expect it to do so quickly.

> Feature "signatures" is not supported by Perl 5.16.3 at …

Again, see the docs:

https://perldoc.perl.org/perlsub.html#Signatures

I note that this feature is still marked experimental and subject to removal.

…And you’re lecturing me about stability?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] more recent perl version?

[Warren Young]

On May 23, 2017, at 10:44 AM, hw  wrote:
> 
> are there packages replacing the ancient perl version in
> Centos 7 with a more recent one, like 5.24?  

Since when is Perl 5.16 “ancient?”  It’s only 4 years old.

CentOS 5 just left supported status, which shipped Perl 5.8.8 from first 
release to last, which means I’ll probably still be limited to Perl 5.8 
features for a few years yet, since the remaining CentOS 5 boxes I’m supporting 
can’t be upgraded and won’t likely be turned off until they fall over dead.  
That makes Perl 5.10 “the future” from my perspective.

If this sort of stance seems risible to you, you probably shouldn’t be using 
CentOS.  This is what distinguishes a “stable” type of OS from a “bleeding 
edge” one.

> At least the state feature is required.

According to the docs,[*] that feature has been in Perl since 5.10.  This 
appears to confirm it:

$ perl -e "use feature 'state'" && echo yes

Are you looking for something else, or do you have a simple test case that 
shows what’s provided in CentOS 7 is insufficient?


[*]: http://perldoc.perl.org/feature.html#The-'state'-feature

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

Re: [CentOS] CentOS 7 selinux

[Warren Young]

On May 9, 2017, at 12:14 PM, Larry Martell  wrote:
> 
> If I make a change to /etc/sysconfig/selinux do I have to restart anything
> for the change to take effect?

Isn’t the correct answer “yes” for every single file under that directory?

If it were otherwise, you’d have services continually restarting to look for 
updated settings.  Then because of all the resulting inadvertent lock-outs and 
other failures, you’d have big block comments at the top of those files telling 
you not to save the file until you’re sure you want those settings applied 
immediately.

If you’re trying to entirely disable SELinux with this change, you’ll have to 
reboot. If you’re changing between enforcing and permissive, there are commands 
for that:


https://unix.stackexchange.com/questions/148890/how-to-disable-selinux-without-restart
___
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 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] Need a bit of 'archeocomputing' help on CentOS 7.

[Warren Young]

On Apr 21, 2017, at 10:11 AM, Lamar Owen  wrote:
> 
> 1.) Run Red Hat Linux 5.2 (or similar vintage) on KVM on CentOS 7;

For what it’s worth, I couldn’t get it working under a modern flavor of VMware, 
either.  I find that telling because VMware tends to have the best driver 
support of all the VM systems, if only because it’s been around the longest.

Unfortunately, current VMware appears to have dropped Linux 2.0 support 
entirely, along with other contemporaneous things.  For instance, even the 
“legacy Linux” version of its VMware Tools package contains Perl scripts that 
are written with the assumption that they’re running on at least Perl 5.8, 
which is contemporaneous with RHL 7.3 and kernel 2.4.18.

I spent some time trying to backport those scripts to the Perl 5.004 that ships 
with RHL 5.2, but gave up after making over a dozen changes with no obvious end 
in sight.

The way I see it, your solution involving CentOS 2.1 and the libc5 
compatibility libraries just bought you the last upgrade to your software that 
you are likely to pull off without heroic efforts.  I advise you to use CentOS 
7’s remaining supported lifetime to get off this old software somehow.

You say there is no open source alternative, yet clearly the software was 
useful to at least you, and probably others, given that it appears to be 
commercial software.  It might be prudent to sponsor the development of an open 
source replacement system.

> e1000 drivers are not likely available (I couldn't find any).

That series of adapters didn’t get Linux support until about 2 years after RHL 
5 shipped, according to the sources:


http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/e1000/e1000_main.c

That would make the e1000 driver about ~3 years too late for you.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] What besides Postfix should not start until system time set?

[Warren Young]

On Apr 20, 2017, at 3:39 PM, Robert Moskowitz <r...@htt-consult.com> wrote:
> 
> On 04/20/2017 05:16 PM, Warren Young wrote:
>> On Apr 20, 2017, at 3:00 PM, Robert Moskowitz <r...@htt-consult.com> wrote:
>>> So I have learned that Postfix should delay until Chronyd has moved the 
>>> system time from 0 to current.
>> I think it’s more the case that CentOS is written with the assumption that 
>> you’re running it on a host with a battery-backed RTC
> 
> It is the Centos7 for arm SOCs.  RPi is one of the worst (in my opinion) of 
> these.

So you picked an alternative that cites “server stability” when explaining why 
they’re redirecting you to a Kim Dotcom service to get info about the product?  
No, no, no.  No thank you.  No.

http://dl.cubieboard.org/model/CubieBoard5/CB5%20Resource%20changed%20download%20%20server.txt

That looks like a “Don’t stick your hand in this hole.” sign to me.

>>> Apache?
>> Just speculating here, but my sense is that Apache doesn’t care about dates 
>> and times until it gets an HTTP request, in order to handle Expires headers 
>> and such correctly. And, HTTP being stateless, even if an HTTP request comes 
>> in so early that it gives the wrong answer, it should get back on track once 
>> the system clock is fixed.
> 
> On the Apache list, I was just told
> 
> "There are some parts of the HTTP conversation which could be affected by 
> having the wrong time, but HTTPD itself doesn't care.
> For example, if you are using cookies, caching, those could be affected by 
> the time change (even more specifically, for PHP sessions, when the clock 
> changes, the PHP session cleanup handler might think a session is very old 
> and remove it).”

That pretty much just backs up and amplifies my speculation: strange things 
will happen in the window where the clock is wrong, but operations will get on 
track quickly without restarting the web server once the clock changes out from 
under it.

It is possible that some particular web apps won’t cope nicely, such as because 
they keep server time info on the client and then make later stateful 
comparisons, but that isn’t about Apache or PHP.
___
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 

Re: [CentOS] What besides Postfix should not start until system time set?

[Warren Young]

On Apr 20, 2017, at 3:00 PM, Robert Moskowitz  wrote:
> 
> So I have learned that Postfix should delay until Chronyd has moved the 
> system time from 0 to current.

I think it’s more the case that CentOS is written with the assumption that 
you’re running it on a host with a battery-backed RTC, so that system time 
isn’t wildly off at boot time.  This includes VMs, since the VM host should 
pass its RTC through to the VM.

What are you running CentOS on that doesn’t have this property?

The only such system I can think of which will also run CentOS is the Raspberry 
Pi 3. They dropped the battery-backed RTC in the name of cost savings and that 
most Pi boards are network-connected, so they can get Internet time soon after 
boot.  But yeah, there is a small window...

> What other services need to be delayed?

I can only speculate.  But take the above as a warning: lots of other software 
may assume sane system time at startup.  Short of a massive code audit or your 
present “canvass the audience” approach, I don’t know how you find out which 
ones.

> Apache?

Just speculating here, but my sense is that Apache doesn’t care about dates and 
times until it gets an HTTP request, in order to handle Expires headers and 
such correctly. And, HTTP being stateless, even if an HTTP request comes in so 
early that it gives the wrong answer, it should get back on track once the 
system clock is fixed.

> Bind?

Similar to Apache, due to cache expiration rules.  Since “now” minus time_t(0) 
is $bignum, that means as soon as the system clock is fixed, it will expire all 
the info it learned in the time the clock was wrong, and any info it gave out 
with start time equal to 0 + epsilon will expire immediately in clients’ DNS 
caches.

Since so much other software depends on having a local DNS server early in 
their startup, I would definitely not delay BIND startup on any machine where 
the local DNS configuration points to localhost.
___
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 19, 2017, at 2:22 PM, Chris Murphy <li...@colorremedies.com> wrote:
> 
> On Wed, Apr 19, 2017 at 5:21 AM, James B. Byrne <byrn...@harte-lyne.ca> 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.

[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

[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] CentOS-6.8 fsck report Maximal Count

[Warren Young]

On Mar 10, 2017, at 9:28 AM, Valeri Galtsev <galt...@kicp.uchicago.edu> wrote:
> 
> 
> On Fri, March 10, 2017 9:52 am, Warren Young wrote:
>> On Mar 10, 2017, at 6:32 AM, James B. Byrne <byrn...@harte-lyne.ca> wrote:
>>> 
>>> On Thu, March 9, 2017 09:46, John Hodrien wrote:
>>>> 
>>>> fsck's not good at finding disk errors, it finds filesystem errors.
>>> 
>>> If not fsck then what?
>> 
>> badblocks(8).
> 
> And I definitely will unmount relevant filesystem(s) before using
> badblocks…

You don’t necessarily have to.  The default mode of badblocks is a non-invasive 
read-only test which is safe to run on a mounted filesystem.

That said, a read-only badblocks pass can give a false “no errors” report in 
cases where a non-destructive read-then-write pass (-n) will show errors.

Alternatively, a read-only pass may show an error that a read-then-write pass 
will silently bury by forcing the drive to relocate the bad sector.

In extreme cases, you could potentially fix a problem with a 
read-random-random-write pass (-n -t random -t random) because that will 
statistically flip all the bits at least twice, which may rub the drive’s nose 
in a bad sector, forcing a reallocation where a normal read-then-write pass (-n 
alone) may not.

Hard drives are weird.  It is only through the grace of ECC and such that they 
approximate deterministic behavior as well as they do.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] CentOS-6.8 fsck report Maximal Count

[Warren Young]

On Mar 10, 2017, at 6:32 AM, James B. Byrne  wrote:
> 
> On Thu, March 9, 2017 09:46, John Hodrien wrote:
>> 
>> fsck's not good at finding disk errors, it finds filesystem errors.
> 
> If not fsck then what?

badblocks(8).

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

Re: [CentOS] Solved Re: imaging a drive with dd

[Warren Young]

On Mar 3, 2017, at 10:49 AM, Lamar Owen  wrote:
> 
> On 03/02/2017 11:57 PM, Robert Moskowitz wrote:
>> The following worked:
>> 
>> # dd if=/dev/sdb of=cubietruck.img bs=512 count=6268927
>> 
>> 6268927+0 records in
>> 6268927+0 records out
>> 3209690624 bytes (3.2 GB, 3.0 GiB) copied, 114.435 s, 28.0 MB/s
>> 
>> So bs= IS the drive blocksize.
>> 
>> This is the result of trying a number of different values for bs and count.
> 
> You can set bs to a multiple of 512 and it will go a lot faster.

Maybe, maybe not.  OP said he’s on an embedded system, which often implies 
low-end eMMC or SD type storage, and 28 MB/sec is typical for such things.

When mirroring HDDs and proper SSDs, yes, you want to use large block sizes.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] imaging a drive with dd

[Warren Young]

On Mar 2, 2017, at 7:04 PM, Robert Moskowitz <r...@htt-consult.com> wrote:
> 
> On 03/02/2017 08:53 PM, Warren Young wrote:
>> Why reinvent the wheel?
> 
> This is Centos7-armv7.  Not all the tools are there.

btrfs and LVM2 appear to be built:


https://armv7.dev.centos.org/repodir/c71611-pass-1/btrfs-progs/4.4.1-1.el7/armv7hl/

https://armv7.dev.centos.org/repodir/c71611-pass-1/lvm2/2.02.166-1.el7/armv7hl/

That’s the userland tools for both.  The rest is in the kernel, so you’d need 
to ensure that the appropriate drivers are built and installed.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] imaging a drive with dd

[Warren Young]

On Mar 2, 2017, at 6:53 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> Why reinvent the wheel?

Oh, I forgot to say, LVM2, ZFS, and btrfs snapshots don’t image the *entire* 
drive including slack space.  They set a copy-on-write point which is 
near-instantaneous, so that whenever one of the current data blocks changes, 
its content gets copied to a new space on the disk and modified there, so that 
rolling back amounts to moving a bunch of pointers around, not downing the 
whole machine and wiping out your prior setup, including all that mail you’ve 
accumulated in the meantime.

If you’re after some unstated goal, such as off-machine backups, there’s 
generally a way to send a copy of the snapshot to another machine, such as via 
SSH.  This is also more efficient than copying a raw dd image.  Not only does 
it skip over slack space, you can send the snapshot to another similar machine 
and “play back” the snapshot there, effectively mirroring the machine, taking 
only as much time as needed to transmit the *changes* since the last snapshot.

If you’ve use a virtual machine manager with snapshotting features, these 
filesystems’ features are a lot like that.  Quick, efficient, and quite robust.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] imaging a drive with dd

[Warren Young]

On Mar 2, 2017, at 6:36 PM, Robert Moskowitz  wrote:
> 
> I want to image the drive at various 'checkpoints' so I can go back and redo 
> from a particular point…
> what dd params work?
> 
> dd if=/dev/sdb of=os.img bs=1M count=3210

That looks plausible.  (I haven’t verified your count parameter exactly.)

However, I wonder why you’re trying to reinvent snapshots, a technology now 
built into several advanced filesystems, such as btrfs and ZFS?

https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots

btrfs is built into CentOS 7.  While there have been some highly-publicized 
bugs in btrfs, they only affect the RAID-5/6 features.  You don’t need that 
here, so you should be fine with btrfs.

And if you really distrust btrfs, ZFS is easy enough to integrate into CentOS 
on-site.

And if *that* is also out of the question, you have LVM2 snapshots:

http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

Why reinvent the wheel?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Checksums for git repo content?

[Warren Young]

On Feb 23, 2017, at 2:57 PM, Alice Wonder  wrote:
> 
> I think the issue is that you not only have to create a trojan file that 
> matches the same hash, but you have to create a trojan file that matches the 
> same hash and doesn't break compiling.

No, that’s the easy bit.  If I want to replace this line of C code:

++i;

with this:

system("dd if=/dev/zero of=/dev/sda bs=1m");

the attack presented by Google shows that you merely need to modify the evil 
version of the file (the Git checkin, in this case) until it matches the good 
version according to SHA1, which is spoofable given sufficient resources.  
Those resources let you fuzz the patch until you succeed:


system("dd if=/dev/../dev/zero of=/dev/sda bs=1m");
system("dd if=/dev/zero of=/dev/sda”); /* 0tt^V */

etc.

That’s why this is considered a collision attack rather than a second-preimage 
attack: both versions of the data can be adjusted until you find a collision, 
rather than just the new version of the data.

> Bottom line is git needs to move to sha256 but I do not believe there is any 
> present danger.

There is present danger.  Just not for the git.centos.org use case, for the 
reasons I laid out in my other reply.

> I'd be more worried about fraudulently issued TLS certs

TLS has other defenses that prevent this attack from working against it:

https://news.ycombinator.com/item?id=13715349

We’ve been to this rodeo before.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Checksums for git repo content?

[Warren Young]

On Feb 23, 2017, at 12:55 PM, Lamar Owen  wrote:
> 
> On 02/09/2017 03:12 PM, Johnny Hughes wrote:
>> The patch files are in git as text files, right?  Why would you need
>> checksums of those? That is the purpose of git, right?
>> 
> Not to stir up a hornets' nest, but how does Google's announcement at 
> https://shattered.it affect this now?

To replace pre-existing checkins in place, you have to execute what’s called a 
second-preimage attack, which is much, much harder than the collision attack 
presented by Google.

The collision attack gives you the freedom to change both files until they 
match, whereas fixing one of the artifacts ahead of time requires you to pull 
off a second-preimage attack.  Since the fear up-thread is about whether we can 
trust what’s already in the CentOS Git repos, only a second-preimage attack 
will do.

There is a way to use a collision attack against Git or similar systems:

https://news.ycombinator.com/item?id=13715887

However, realize that in this context, it means you’d have to:

1. Get the Red Hat or CentOS folks to accept the good version of your patch.  
(i.e. The benign version of the evil patch you want to get into RHEL and 
CentOS.)

2. Hope that the committer doesn’t modify your patch before committing it, thus 
breaking the match to the evil version you spent $100k and a month of time 
creating.

3. MITM the Git sync protocol between git.centos.org and the target site to 
inject your evil version into the sync stream.  Since git.centos.org redirects 
to HTTPS by default and issues HTTPS URLs for you to clone from, this means you 
also have to break TLS, since unbroken TLS prevents MITM attacks.  That, or 
someone has to *aim* while shooting themselves in the foot, going out of their 
way to remove the “s” from the URL.

4. Since git.centos.org is apparently not mirrored, you have to execute this 
attack between git.centos.org and all end users of their service that you wish 
to attack, rather than poison one or more of the mirrors by MITMing the 
mirror’s connection back to git.centos.org.

So yeah, it’s still Difficult.™

All of this is not to say that Git doesn’t have a problem.  They do.  It’s just 
that the problem in question doesn’t affect the integrity of git.centos.org, as 
far as I can see.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Serious attack vector on pkcheck ignored by Red Hat

[Warren Young]

On Feb 9, 2017, at 2:39 PM, Leonard den Ottolander <leon...@den.ottolander.nl> 
wrote:
> 
> On Thu, 2017-02-09 at 14:22 -0700, Warren Young wrote:
>> There are two serious problems with this argument:
>> 
>> 1.  Give me a scenario where this attacker can execute *only* pkcheck
> 
> On many systems local users cannot execute their own uploaded binaries
> (noexec mounts). This would also be true for an adversary entering a
> system with a remote "unprivileged" exploit. In that situation pcheck
> gives them a "crow bar" they did not have before.

So you’ve now sprayed the heap on this system, but you can’t upload anything 
else to it because noexec, so…now what?  What has our nefarious attacker gained?

>> A vulnerable library is a vulnerable library.  Fix the library, don’t
>> invent reasons to fix all the other programs on the system because the
>> library is vulnerable.
> 
> I would say the modus operandi should be to eliminate all known attack
> vectors, including such a powerful one as the described "heap spraying”.

That sounds like an esthetic argument, not a logical argument.  “Heap spraying” 
sounds scary, so let’s fix it!

What I want to know is, what can you *do* with a sprayed heap caused by an 
unprivileged executable?

Realize that as soon as a second executable starts, it doesn’t see the sprayed 
heap.  The kernel zeroes all reassigned memory pages.  Your attack must 
therefore work within the pkcheck process, while that sprayed heap is still 
active.

>> 2.  There’s no such thing as SUID libraries.
> 
> I never argued there are.

I threw that idea out in an effort to follow the Principle of Charity. 
(https://goo.gl/uwS4UE)  I wasn’t required to provide the idea in the first 
place; the burden of proof was on you, and remains there, even though you’ve 
rejected my attempt to provide you with such an idea.

>> So, how is this hypothetical library of yours going to gain
>> privileges that the executable linked to it does not have?  Point me
>> at a CVE where a vulnerable library was used for privilege escalation.
> 
> Maybe the example using a library is wrong. But there are other ways to
> gain a privilege escalation, kernel bugs for example. Those could be
> triggered just as well.

Now you’re just moving the goalposts.  The nature of the vulnerability does not 
change just because we call it a “kernel” instead of a “library”.  A vulnerable 
kernel is a vulnerable kernel, and does not require that we fix all the other 
problems on the system in order to fix the kernel.

I’m with Gordon: someone certainly should fix this problem for its own sake, 
but don’t try to strong-arm Red Hat into doing it for you because Security.

Way too many bad things are done Because Security.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Serious attack vector on pkcheck ignored by Red Hat

[Warren Young]

On Feb 9, 2017, at 2:03 PM, Leonard den Ottolander  
wrote:
> 
> On Thu, 2017-02-02 at 13:40 -0800, Gordon Messmer wrote:
>> Escalation *requires* attacking a program in a security context other 
>> than your own.
> 
> Not necessarily. Suppose the adversary is aware of a root
> exploit/privilege escalation in a random library.

There are two serious problems with this argument:

1.  Give me a scenario where this attacker can execute *only* pkcheck in order 
to exploit this hypothetical library’s flaw, but where the attacker cannot 
simply provide their own binary to do the same exploit.  Short of something 
insane like exposing pkcheck via CGI over HTTP, I don’t see how a flaw in 
pkcheck gives you something here that you don’t already have.

A vulnerable library is a vulnerable library.  Fix the library, don’t invent 
reasons to fix all the other programs on the system because the library is 
vulnerable.

2.  There’s no such thing as SUID libraries.  So, how is this hypothetical 
library of yours going to gain privileges that the executable linked to it does 
not have?  Point me at a CVE where a vulnerable library was used for privilege 
escalation.

You can point at vulnerable libraries giving data exfiltration and such all day 
long, but privilege escalation??
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Checksums for git repo content?

[Warren Young]

On Feb 9, 2017, at 1:26 PM, Leonard den Ottolander  
wrote:
> 
> On Thu, 2017-02-09 at 14:12 -0600, Johnny Hughes wrote:
>> The patch files are in git as text files, right?  Why would you need
>> checksums of those? That is the purpose of git, right?
> 
> Checksums are there to make sure that you get what you are supposed to
> get.

What failure model are you trying to solve for, specifically?

If you’re worried about malicious tampering of the files on the server, how 
would your request solve anything?  If you don’t trust the Git repo you’re 
cloning from, why would you trust a checksum file stored in that same repo?

If you’re worried about a MITM attack, any MITM that can modify Git data 
in-flight can produce bogus checksum files in-flight, too.

If you’re worried about corrupted data at rest on the remote server or 
corruption introduced during the transfer, Git already solves this:

   https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

If you want to verify that a given Git clone is consistent:

   $ git fsck --full —strict 

Git can do this because its contents are a type of Merkle tree:

   https://en.wikipedia.org/wiki/Merkle_tree

Merkle trees are highly resistant to attacks, particularly in the case of 
source code, where an attack must not only change the attacked resource, the 
change has to a) create some effect desired by the attacker; and b) still be 
legal code in the programming language being used.  Getting both effects while 
still maintaining the same SHA1 hash is Difficult.™

I don’t know Git internals, but I would expect the above git-fsck command to be 
pointless immediately after a clone, because Git should be doing something like 
what it does during the clone process.  (I’ve been disappointed by Git’s 
behavior before, though, so…)

That command should only have a useful effect after a later git pull command in 
order to detect whether the local copy has bitrotted in the meantime.

> Having checksums for all files (like in a SRPM) is a guarantee

A checksum guarantees nothing by itself.  A file’s checksum is only as 
trustworthy as the source of that checksum.  If you don’t trust the source to 
give you a correct file, you can’t trust that same source to give you a valid 
checksum.  Any bad actor that can compromise one can compromise the other.

*Distributed* checksums can sometimes be helpful, if they’re maintained by 
disparate parties on distributed servers.  Here, you’re asking some third party 
to assert that they got a copy of the same RPM (or whatever) and that they got 
checksum XXX for it.  That devolves into a trust relationship, rather than 
the math problem it naively looks like: do you trust that party not to be 
compromised by the same party that produced the RPM in question?

Another trust problem — which is again a people problem rather than a math 
problem — is cryptographic signatures.  A signed SRPM is only as trustworthy as 
the provider of the signing certificate.  Certificate authorities are getting 
caught doing untrustworthy things *all the time*.  Have you vetted your trusted 
CAs, or are you relying on a third party to do that?  Why do you trust that 
third party to do that job thoroughly?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] bash on ubuntu (centos) on windows

[Warren Young]

On Dec 8, 2016, at 2:33 PM, Peter  wrote:
> 
> Ubuntu on Windows is *not* Linux.

No, but it does implement the kernel syscall interface and an ELF loader.

Therefore, there is no reason, in principle, why you could not build a CentOS 
userland on top of the Windows Subsystem for Linux.

It would be about as difficult as live-migrating a working Ubuntu box to 
CentOS, replacing binaries one by one until you’re suddenly running a CentOS 
userland on top of the kernel Ubuntu shipped.

Difficult, but do-able.

Get to work, Jerry. :)

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

Re: [CentOS] Off-Topic: Travel Router and Firewall

[Warren Young]

On Nov 23, 2016, at 3:40 PM, John R Pierce  wrote:
> 
> On 11/23/2016 2:24 PM, Leon Fauster wrote:
>> DIY based onhttp://www.pcengines.ch/  hardware ...
> 
> ...tis not suitable for USB power (5V, up to 2.5 amp)

I think you mean 2.5 *watts* not amps.  USB 2.0 and below are 500 mA @ 5 Vdc 
max == 2.5W.  There are nonstandard extensions to USB to allow 2+ amps, but you 
can’t expect to get that from generic USB ports.

USB 3 Type C fixes this, but I don’t think that helps the OP.

> unless you rig up a USB to 12V DC-DC converter.

Increasing the voltage decreases the current.  TANSTAAFL.

With typical conversion losses, you could only expect to get about 170 mA out 
of USB when boosted to 12V.

Incidentally, the Raspberry Pi is only USB-powered in the sense that the base 
board will usually run fine from a PC USB port.  Add a couple of wifi radios 
and an Ethernet adapter, and you may exceed the 500 mA limit.  The Pi is also 
famously intolerant of power rail sags and such.

It’s best to think of the Pi as a device that just happens to have a micro USB 
power connector on it, but which is still wall-powered.

> I do wonder how the OP plans on connecting his phone and/or tablet via 
> ethernet to this.

It can be done:

  http://www.gottabemobile.com/2014/08/28/how-to-connect-an-ipad-to-ethernet/

I assume there are equivalent methods on Android.

> the router would need TWO wifi adapters.

Yes, that’s a much simpler option, inherent in a proper travel router, another 
reason to avoid hacking something up with a Pi.  The problem’s already been 
solved, and solved well.

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

Re: [CentOS] Announcement: new yum repos

[Warren Young]

On Oct 21, 2016, at 1:49 PM, Richard Grainger  wrote:
> 
> ergel (Extra Ruby Gems for Enterprise Linux)

You should call it RIGEL: Ruby Imported Gems for Enterprise Linux.

Much space.  So geek.  

  https://en.wikipedia.org/wiki/Rigel

> epmel (Extra Perl Modules for Enterprise Linux)

CoMPEL: CPAN Modules Provided for Enterprise Linux

“By the power of Randall Schwartz I compel you!  Rise and walk, my new Perl 
app!”

> The repos are designed to work in conjunction with EPEL, so you will
> need this installed first and they should be "safe" (they don't
> upgrade packages in base).

My biggest hassle with Perl modules not provided in the base OS or EPEL has 
just been that we still need to support EL5, and every now and then cpanm will 
fetch a new version of a module that used to work on EL5 but no longer does.  
So, unless you’re going to solve that problem,[*] I don’t think I’ll be using 
it, since cpanm and bug reports work well enough for us right now.

(And yes, I’m aware of Carton, FatPacker, and Docker.  If the compatibility 
problem gets bad enough before we can jettison our last EL5 users, we may end 
up going that way.)

Regardless, thank you for doing this work.  I’m sure it will help many people.



[*] By that, I imagine someone doing something like Red Hat does and settling 
on a stable set of Perl distribution versions and backporting fixes to those 
versions rather than upgrading wholesale.  It’d be a lot of thankless work, 
which is why I don’t expect you to do it.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos