16 thoughts on - CentOS And Typical Usage

• Op 12-dec.-2015 15:03 schreef Alice Wonder :

  Having 150 people using CentOS on the desktop, I couldn’t agree more

  Greetings, J. _______________________________________________

• I think you’re committing the same kind of error here that Fedora is: assuming your “typical” use case is typical of the wider world.

  We do use a lot of VMs here, but they’re far outnumbered by the number of bare-metal installations.

  You’re describing the appliance model, which is a fine and valid use of CentOS, but hardly the only one.

  One of the big recent trends in the virtualization space is containerization (e.g. Docker, BSD jails, Solaris zones…) where there may be little to no “OS” inside the container. Its growth is partly at the expense of the old “full OS inside a VM” model of virtualization.

  Like most displaced tech, I don’t expect heavyweight VMs to ever disappear, but the tech might be slowly marginalized.

  General purpose OSes remain useful in a world of increasing appliance VMs, embedded OSes, cloud services, and mobile OSes because you can use them as the base for anything a computer can do.

  Where once upon a time, GP OSes were the only thing available, they remain useful to handle all the weird edge-case things that aren’t covered by the existing cookie-cutter cases.

  That has a practical consequence, though: you can’t predict, a priori, how someone will use a GP OS. “Streamlining” it amounts to putting barriers up on many of those edge case paths.

  Instead of trying to make CentOS simpler to use for a predetermined task set, I’d rather they made it simpler to access all of its power, and leave it to *me* to decide what the tasks are. That means not hiding functionality behind task-focused interfaces, because my tasks are not your tasks.

  I gave one example of a case where EL7 is now harder for us to use than earlier versions in the other thread. (The “NM swaps static and IP interfaces” problem.) Let me give another here:

  In EL5 on a single-NIC machine, it was possible to set it up for a static IP, then create an ifcfg-eth0:0 file with a DHCP configuration, so that the interface would also get an IP alias, DNS info, and a default route from the DHCP server.

  You can’t do that in EL7 any more because NetworkManager only knows about static IP aliases. It knows nothing about alias interfaces, which are a much more powerful concept.

  In the end, I had to configure enp3s0 as DHCP, then hack in a static IP alias with an ifconfig call in rc.local.

  I’ll forgive you if that solution makes you nearly puke, because it did that to me, too.

  In case you’re thinking about the previous complaint, yes, this is the single-NIC version of the same problem, but with a different consequence, which is suspect all by itself. Why is there a behavior difference between static+DHCP in the dual-NIC and alias interface cases? The whole idea of alias interfaces is that they act like independent NICs that just happen to share the same physical medium as their parent NIC. Answer: Because NM doesn’t know what alias interfaces *are*.

  Instead of adding the ability to create alias interfaces to the NM GUI/TUI, they just added a field that lets you list additional static IP aliases, which captures part of the *function* of the previous mechanism while missing out on much of its full power. They made it task-focused for a task that does not need doing in my world. It’s like giving a mop to the owner of a fully-carpeted home.

  I characterize this as an EL7 issue because there were fewer consequences to disabling NM in EL6. Here in EL7, things break if you disable NM, so that they’re basically forcing you to use it, even though it doesn’t do everything the old scheme could yet.

  I remain ambivalent about systemd.

  I’m with you insofar as I recognize that systemd serves a useful purpose, and it is mostly fit for that purpose. Pretty much everything you could do on a pre-systemd box, you can do under systemd, too. systemd provides real value to CentOS.

  The biggest problem I have with it is its monopolization of system functionality.

  The most commonly cited example of this I see is that systemd now owns logging. Never mind the whole binary logging problem, why does a process launcher own logging in the first place? What was wrong with syslogd? You know, the Unix philosophy and all? Small pieces, loosely joined? Why aren’t we dancing with the one who brought us to the dance any more?

  But it goes much further than that, with more serious consequences. For example, systemd has usurped udev and dbus, which are key parts of the freedesktop.org standards, which allow GNOME, KDE, and other *ix desktop environments to interoperate. But that in turn means that non-systemd based OSes that want to ship FreeDesktop-compatible DEs like GNOME and KDE must now include systemd. FreeBSD doesn’t *want* systemd.

  This feels an awful lot like “embrace, extend, and extinguish.”[1] I sure hope Red Hat isn’t the new Microsoft.

  If you want to see what systemd *could* have looked like, take a look at launchd.[2] There’s talk in the BSD world of using it instead of systemd, though that may not be practical given the FreeDesktop standards problem.

  By the way, what NIH process went on in North Carolina that led them to reject the Apache-licensed launchd, available 5 years prior to the creation of systemd, and used in a production capacity that whole time? Or upstart, created 4 years prior for Ubuntu?

  This is what I mean about EEE: systemd is derailing other OSes’ development processes.

  I understand the ambivalence toward the use of XML in launchd, and there are Mac-isms in launchd, but those are both easier problems to solve than creating systemd from scratch. So much easier, in fact, that it’s been solved multiple times.[3][4]

  The inverse of that sort of effort — “fixing” systemd to make it suitable for non-Linux OSes — seems to be too difficult to bother with.[5]

  [1]: https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
  [2]: https://en.wikipedia.org/wiki/Launchd
  [3]: https://github.com/mheily/relaunchd
  [4]: http://www.nextbsd.org/clarifying-near-term-expectations/
  [5]: http://uselessd.darknedgy.net/

  What is this GNOME thing you speak of? Is it part of ssh? :)

  Why? Bleeding-edge Linuxes work best in places where there are hands on the box constantly, so you can cope with the blood loss, so to speak. In such an environment, the benefits outweigh the costs.

  Contrast a stable Linux use case, where it’s mainly important that the provided packages be reasonably up-to-date at the time of development and deployment. Once you’ve got an unattended server up and running, it is rare to need newer package versions on it; you just need security patches and bugfixes, the very thing that a stable OS provides.

  Newer services typically get deployed on new servers, not on the one that’s been running for 5 years, and is now 2 major OS versions behind.

• Alice Wonder wrote:

  Who is “you”?
  I’m running a home server under CentOS-7, and I’m not using a virtual machine. Why should I?
  I don’t want to “deploy it thousands of times”.

  It’s amazing how people assume that everyone in the world is, or should be, running things in the same way as themselves.

  I dislike systemd because it is much more complicated than its predecessor, and it has no advantages in my case to make up for this. The main advantage that was originally claimed was that it boots faster. That is not the case on my Fedora laptop. It is no faster, and it is much harder to work out what is happening if something goes wrong.

• You is an author’s you, kind of like author’s we. I understand author’s you and we are going out of style, but they are very much ingrained within me.

  I mean the typical server and indicated a server environment opposed to a home environment.

  It’s not speed that matters to me, and I would be fine with System V
  init. However it seemed at the end of the day, most of the arguments against systemd boiled down to “we’ve never done it that way before” or
  “It’s not the UNIX way” rather than actual technical reasons why System V should be used and systemd rejected.

  One of the benefits of systemd is the dependency based parallel startup. The same speed can often be achieved with system V init by fine tuning when the services start but systemd does that automatically.

  Speed though doesn’t concern me. I almost never reboot my servers or my desktop or laptop (I do sleep the laptop but only reboot after kernel update)

  Especially with SSDs, boot time isn’t an argument for systemd – and I do not want to convince anyone that it is better. Just that it is not difficult to use, there are some advantages – how valuable those advantages are depend upon what you do (author’s you again, not personal you) but it seems that these advantages have since been seen by just about every Linux distro that has any significant market share.

  Popular doesn’t make it right, but it did make me rethink my objections to it and whether or not those objections were rational. For me, I
  decided that no, they weren’t rational.

• I’m joining my “you” to yours. I’m even joining the kind of what one often does for servers: virtualized stuff, even though my case is FreeBSD jails
  (mostly even more comparmentalized than single virtual machine: one jail per service or per group of services which need to talk to each other through UNIX sockets; still I put mu case in the same category with yours).

  true. Pretty much as true would be: why should we (*nix admins) be like certified Windows admins: every incarnation of the system we have to learn new way to find yet the same on the low level code tools. I know systemd is not it, it is quite different architecture. But jumping to this incarnation of Linux does feel similar.

  Well, for last 6+ years you should: at lest once every 45 days on average
  (either kernel or glibc security update, – just my observation). Of course, time the machine boot takes doesn’t by any measure compare to interval between reboots. Neither it does compare to the fact you have to reboot the server. The funniest thing is: for some of the server hardware initialization by BIOS, which has to happen even before system boot starts, takes longer than system V init (not talking about faster systemd boot as I only can compare with workstation systemd boot: I do not have servers running systemd based system). So all in all the best pro systemd argument – fast boot – kind of doesn’t exist for me. I know, tastes differ. But if I _have_ to reboot server often, it is time to build service cluster in which case reboot of single machine doesn’t matter. Neither the time the it takes to boot matters, so we are back to square one: no advantage of systemd’s fast boot (just IMHO).

  Valeri

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

• Alice Wonder wrote:

  If it’s no faster then why is it a benefit?

  Why don’t you say what the advantages are, instead of launching into a philosophical discussion of “market share”.

• Alice Wonder wrote:

  To me, a server is a computer providing a service to other computers or electronic devices. It may be on a space-station, or it may be in someone’s home –
  its whereabouts, or “environment” as you call it, is completely irrelevant. All that matters is what services it offers.

• Binary logs with checksums is one benefit, much harder for a hacker or malware to hide its tracks.

  Binary logging also makes it easier / faster to look at specific types of events in the log.

  And sockets can be used before the service is actually started, so services that want to log for example can start before the logger is finished coming up.

  And it allows services to start on demand and stop when no longer needed. I don’t use that, but that is not as easy to do with system V init.

  It also reduces issues related to poorly scripted init scripts, and needing to sometimes change the numbers to make sure services start in the correct order.

  There are benefits, at least to some people. And there isn’t anything I
  could do with System V that can’t be accomplished with systemd.

  systemd isn’t critical to use, not for me, but other than needing to do a little research and learning, it also isn’t a negative.

• Just for the record, CentOS doesn’t make these kinds of decisions .. we rebuild whatever Red Hat releases for soruce code for RHEL. You will notice, if you used the CR tree, that the new desktop for 7.1511 (based on the 7.2 RHEL source code), is a much newer version of Gnome and KDE.

  Gnome is now 3.14.x, it was 3.8.x. KDELibs are now 4.14.x, the were 4.10.x.

  So, CentOS does not make and decisions about usability or anything else, we simply build released source code when it is released .. nothinh more, nothing less. (For our core repos)

  We do have special intrenet groups, and those can focus on and even change some areas. For example, if the community is willing to do the work, they can ask for and form a Desktop SIG and add items to the desktop.

  But I wanted to make sure people did understand that we are not making content decisions for the core CentOS repos.

  Thanks, Johnny Hughes

• startup. when the services start but systemd does that automatically. malware to hide its tracks.

  Without intent to be a pain in a… just respectfully disagreeing.

  Harder only from the point of view current tools script kiddies use will not deal with then. Fundamentally better security/forensics wise would be to keep logs on remote secure server. Like in the very first computer security lesson: you can not trust anything on compromised machine.

  of events in the log.

  Disagree. It is so only for people who are not familiar with few UNIX
  tools such as grep, e.g.

  services that want to log for example can start before the logger is finished coming up. needed. I don’t use that, but that is not as easy to do with system V init.

  We always considered starting new process in UNIX to be very expensive. Much more expensive than keeping the process in sleeping state. Sorry to contradict again… or am I missing something?

  needing to sometimes change the numbers to make sure services start in the correct order.

  I am not getting your logic here. If something is poorly written _it_ has to be fixed. Building the whole new building involves much more effort than just small thing like init script.

  could do with System V that can’t be accomplished with systemd. a little research and learning, it also isn’t a negative.

  It is not, you are right. But with my finite mental abilities and avalable time I always find many extremely worty things to learn, this one not the first on the list. But in the end a have a feeling that arguing on this subject as the same senseless as religios one between those who believe that God created people and those whe believe tha people created God for themselves…

  Valeri

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

• It’s a matter of knowing your machine has been compromised.

  Modifying the binary logs to hide that you are there will result in checksum inconsistencies, removing a few lines from text logs will not.

  Yes, you can use text log to a remote machine to avoid that, but binary logs let you on the local machine.

• Yes and no. If you are lucky this may be the way you learn about compromise. If you are not, see below.

  Checksums are created and stored on the same machine. So, checksums can be
  “doctored” as well as logs can.

  But yes, there is nothing ultimate, so even remote logs I mentioned earlier can be trusted only up to the moment the compromise had happened, further logs sent by compromised machine can be garbage. Luckily one (bad guy) can not do everything simultaneously, so there will be some clues in remote logs about compromise. But I agree, anything making the job of bad guy more difficult helps, as we are just competing with them for time. Only having logs in binary form brings more disadvantages for _me_ than it offers advantages. But it’s just me, so who cares ;-)

  Valeri

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

• Well, in the ideal case, yes. BUT, as it is, the binary log that systemd-journald, becomes compromised, and unreadable too often to be helpful.

  From a compromised journald log file you get NOTHING at all. You can’t even get the entries up until the point the compromise of the log happend. Not helpful.

  All you can see is that you cant view the log at all. Bravo. And why that has happend? Was it the filesystem, was it journald itself, was there a break-in, did someone local try to manipulate the log?

  Where is your answer?

  Sorry, nice idea but very ugly result, not useable as intended.

  Yes, I’m frustated with journald, for production I’m using remote logging with TLS and oneway replicated database, locally either syslog-ng or rsyslog.

  I’ll keep an eye on it, but atm it’s not useable for me on disk.

  – Yamaban.

• So, while the parallel startup can sometimes produce a faster startup, I believe it is more a side effect from the proper management of service dependencies. In SysV init, you either had hard-coded sequential startup of some parts of the OS (in the shell script that started init and mounted all the filesystems, ran fsck, whatever) and then the increasibly difficult to manage SysV init scripts, which were ordered by the chkconfig numbers. There’s no explicit dependencies, you had to basically modify those numbers if you knew they needed to start before some other number, and if the packaged init script had a number that just didn’t work out, then you’re stuck maintaining that script for the rest of time.

  Upstart tried to fix this, and it probably would have been what we’re all using instead of systemd if their development process wasn’t broken. But even when we had Upstart in CentOS6, no one wanted to use it, they all used SysV init scripts.

  As a sysadmin, I like systemd because I can finally manage the order in which services start up and keep my sanity. Don’t like how the packaged unit does something? Its easy to override a setting or write your own, and you don’t have to worry about the package overwriting it because its a separate file in /etc.

  As a packager, I like systemd because I can write one service unit file, and know that I don’t have to worry about the ordering of services, and I even get some cross-distribution portability.

• Jonathan Billings wrote:
  

  And a lot of us disagree. And, btw, I’m just waiting for the release… and then the update, where one or more systemd targets wind up with circular references.

  mark

• Alice Wonder wrote:

  What precisely do you mean by “the server environment”?
  I run a number of home servers on HP MicroServers. Evidently this is not a “server environment” in your view. The only sense I can give to your phrase is
  “a system run by one or more paid sysadmins”.