Items tagged with: systemd
Please vote if you can!
They have added a forum poll about init system used on MX Linux. systemd (yep, it is written non-capitalized) is now a very widely used option for this but it divides people's opinions.
== > https://forum.mxlinux.org/viewtopic.php?f=94&p=496908
#init #MXLinux #Linux #systemd #sysVinit
A systemd flash from the past!
Rethinking PID 1
While I started off with much resistance to systemd, like most folks, I have to admin that I like it more in more as I dive deeper in to it. Many people have legitimate gripes with it, no doubt - I still haven't totally convinced myself that timers are better than cron in all situations - but many others seem to just hate that which is different than they are accustom to. Here's a great blog post by systemd's creator, Lennart Poettering, wrote near just after the inception of systemd. It's interesting and I find it hard to not agree with his logic and reasoning for systemd, just maybe not every point on implementation. That said, him and those who have worked on the project have really moved desktop GNU/Linux forward, I'm not even using it on my servers, and they just generally gave us a far more modern init system. At least, this is my humble opinion. I know many will disagree, and that's okay. The 'me' from a couple years back disagreed as well. Maybe my mind will change again, but for now I find it to be one of the more impressive parts of the GNU/Linux system to date.
#systemd #gnulinux #linux #gnu-linux
Any of these other topics interesting?
My thoughts on
#Truth #Podcasts Truth #News Sites
#Ham #Radio Software #HAM #Amateur #Radio #Licensing
#Cellphones #WIFI Dangers
#GMOs #Global #Cooling
#fact-checkers #NWO #TRUMPED
On #Guns #Images
People Defending Themselves
on #911 "Mister" #Soros
#newhere Things I Said
#NATO v #Russia #music
#Brave #New #World #1984
Further thoughts on
on #Conspiracy #Theorists
on diaspora nits
on #Email #Recommendations
on #Natural #Cures
People Defending Them-self with a Gun
Just Block Google Completely
I wrote some little helpers (for #systemd and #docker), which you can find here https://github.com/nupplaphil/borg-backup-docker-lvm-systemd
one application per task on the installation ISO
fully backwards compatible with Slackware
optimized for desktop usage
high quality package repositories with dependency support
incredibly fast package tools
simple & fully localized system administration tools
supports 32-bit and 64-bit architectures
#SALIX #Linux #GNU/Linux #Slackware #FOSS #SOFTWARE #OperatingSystem #systemd #computer #technology
...and i really like it. lasts more than 45 min, but it's time well spent for people like me who know there has been or is some type of religious war going on re. systemd, but haven't really followed the arguments in detail.
Best way to run Wine on 64-bit Debian
I am trying to figure out how running Wine in a very cool way, I mean modern and isolated, there are several way to achieve it but I would like to see your opinion!
#debian #linux #winehq #opensource #containers #docker #systemd #systemadmin #floss #foss #freesoftware #sysadmin
Here’s an interesting article by an experienced Systems Admin saying he is done with SystemD. I find the “honesty” in it refreshing 😉
#SYSTEMD #UNIX #LINUX #SOFTWARE #COMPUTER #TECHNOLOGY #INIT #RUNIT #PROGRAMMING
The systemd project is a large, complex and popular – but also controversial – toolkit used by many mainstream Linux distros to handle system startup and logging.
#Linux #systemd #security #bug #cybersecurity #unix #computer #software #hacker #internet #web #init
Understanding the Red Hat Enterprise Linux random number generator interface
January 30, 2019
Like other operating systems, Red Hat Enterprise Linux provides a cryptographically-secure pseudo-random number generator (CSPRNG) as part of our kernel. It is intended to be used by cryptographic back-ends and applications requiring cryptographic operations. Unfortunately, there is much mystery around the interfaces provided. While the new random(7) manual page does clarify some aspects, it does not fully address all common questions. In this post, we will make a brief overview of these interfaces, starting from their initialization to their use.MORE:
Note that, this post will not get into the internals of a CSPRNG. We will go through these interfaces, intentionally staying on the high-level, without considering internal details, and discuss their usefulness for an application or library that requires access to such a CSPRNG.
Note that these interfaces are a compromise of various schools of thought in the free software ecosystem and carry their historical mistakes for backward compatibility.
How does the kernel initialize its CSPRNG?
The kernel has an “entropy pool,” a place where unpredictable input observed by the kernel is mixed and stored. That pool serves as a seed to the internal CSPRNG, and until some threshold of estimated entropy is reached initially, it is considered uninitialized.
Let’s now see how the kernel initializes its entropy pool.
- After the kernel takes control on power-on, it starts filling its entropy pool by mixing interrupt timing and other unpredictable input.
- The kernel gives control to systemd.
- Next, systemd starts and initializes itself.
- Systemd, optionally, loads kernel modules which will improve the kernel's entropy gathering process on a virtual machine (e.g., virtio-rng).
- Systemd loads the rngd.service which will gather additional input entropy obtained via a random generator exposed by hardware (e.g., the x86 RDRAND instruction or similar) and jitter entropy1; this entropy is fed back into the kernel to initialize its entropy pool, typically in a matter of milliseconds.
After the last step, the kernel has its entropy pool initialized, and any systemd services started can take advantage of the kernel’s random generator.
Note that the virtio-rng kernel module loading in step (3), is an optional step which improves entropy gathering in a virtual machine by using the host's random generator to initialize the guest systems in KVM. The rngd.service loading at the final step (4) is what ensures that the kernel entropy pools are initialized on every scenario, and furthermore it continues mixing additional data in the kernel pool during system runtime.
How does the kernel provide access to its CSPRNG?
The Linux kernel, as shipped with Red Hat Enterprise Linux after 7.4, provides the following interfaces for accessing the CSPRNG:
- getrandom(): A system call which provides random data from the kernel CSPRNG. It will block only when the CSPRNG is not yet initialized.
- /dev/random: a file which if read from, will output data from the kernel CSPRNG. Reading from this file is blocked until the kernel estimates that enough random events have been accumulated since the last use (many details are omitted for clarity).
- /dev/urandom: a file which if read from, will provide data from the kernel CSPRNG. Reading from /dev/urandom will never block.
- AT_RANDOM: a location in process’ memory containing 16-bytes of random data; these are accessible via getauxval() and are always available.
The recommended kernel interface for Red Hat Enterprise Linux 7 is getrandom(); in the following paragraphs we will discuss the weaknesses and strengths of each interface which will make our statement above apparent.
This interface is described in the random(4) manpage as: “/dev/random is suitable for applications that need high-quality randomness, and can afford indeterminate delays.” The interface was designed to work even when the cryptographic primitives it depended on were broken in a catastrophic way.
In practice, because that interface depends on proven primitives like the stream cipher ChaCha20 (in the past it was SHA256), that did not prove to be a reasonable risk, and in practice its dependence on conservative randomness estimation which blocks indefinitely made it unsuitable for applications. Putting its threat model in contrast with existing applications, if the
/dev/randomthreat model applies, the majority of the protocols and algorithms that take advantage of the random generator are already untrustworthy as they depend on the same primitives.
As such, due to its unpredictable semantics, we do not recommend the use of that interface in any scenario.
The device /dev/urandom provides access to the same random generator, however it will never block, nor apply any restrictions to the amount of new random events that must be mixed in the kernel entropy pool in order to provide any output. That is quite natural given that the cryptographic primitives used by the Linux kernel random generator, when initialized, can provide enormous amounts (practically unlimited) of output prior to being considered insecure in an informational-theory sense.
Unfortunately /dev/urandom has a quite important flaw. If used early on in the boot process when the random number generator of the kernel is not fully initialized, it will still output data. The "unpredictability" or "randomness" of that data is system-specific.
That interface provides 16-bytes of randomness to each process, following the same rules and having the same limitations as /dev/urandom above, i.e., its value may be derived from an uninitialized entropy pool. Its value remains constant for the lifetime of the process, and is shared with potential children processes after fork(). It can be accessed by using the getauxval() glibc call.
Due to the limitations above, we do not recommend the use of that interface in any scenario.
The getrandom() interface provides non-blocking access to kernel CSPRNG, after the kernel's entropy pool is initialized. When the entropy pool is not initialized the function blocks, making this interface suitable not only for the typical user-space application, but also for applications requiring random data early, during the system's boot process.
Another advantage of this interface is that it does not require a file descriptor to operate. That not only simplifies code using the random generator, but also makes applications more resilient when operating in chroot() environments, because it does not require the presence of a device file.
Which CSPRNG interface should I use in my application?
How to use getrandom() in an application safely?
Don’t leave randomness to chance
#gnu #linux #redhat #rhel #fedora #centos #systemd #kernel #openssl #gnutls #nss #libgcrypt #crypto #random #urandom #security #privacy #programming #generator
Tragedy, according to Wikipedia, is "a form of drama based on human suffering that invokes an accompanying catharsis or pleasure in audiences". Benno Rice took his inspiration from that definition for…
Article word count: 1821
HN Discussion: https://news.ycombinator.com/item?id=19023232
Posted by wyldfire (karma: 10108)
Post stats: Points: 145 - Comments: 111 - 2019-01-29T02:36:03Z
\#HackerNews #systemd #tragedy
Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!
Tragedy, according to Wikipedia, is "a form of drama based on human suffering that invokes an accompanying catharsis or pleasure in audiences". Benno Rice took his inspiration from that definition for his 2019 linux.conf.au talk on the story of systemd which, he said, involves no shortage of suffering. His attempt to cast that story for the pleasure of his audience resulted in a sympathetic and nuanced look at a turbulent chapter in the history of the Linux system.
Rice was also influenced by Aurynn Shawʼs writing on "contempt culture". According to Shaw, people use contempt (of developers using a different programming language, for example) as a social signifier, a way of showing that they belong to the correct group. This sort of contempt certainly plays into this story, where large groups identify themselves primarily by their disdain for systemd and those who work with it. A related concept is change, or the resistance thereto. The familiar is comfortable, but it isnʼt necessarily good, especially if it has been around for a long time.
The roots of the tragedy
The ancestry of systemd, he said, is tied to the origin of Unix, which was "a happy accident" — a reaction to the perceived complexity of the systems that came before. It was brutally simple in all regards, including how its user space was bootstrapped. Putting up an early init man page, he [Benno Rice] called out the "housekeeping functions" that it was designed to carry out, including mounting filesystems and starting daemons. Those are two distinct tasks, but they had been lumped together into this one process.
In those days, there were few daemons to worry about; cron, update (whose job was to write out the filesystem superblocks occasionally), and the init process itself listening on a few terminals were about it. By the time that 4BSD came around, Unix had gained a proper getty daemon, network daemons like routed and telnetd, and the "superdaemon" inetd. That is where things started to get interesting, but it still worked well enough for a while.
Then the Internet happened. Using inetd worked well enough for small amounts of traffic, but then the World Wide Web became popular and it was no longer possible to get away with forking a new process for every incoming connection. Sites on the net started running databases and other systems with a great deal of stored state that could not go away between connections. All this shifted the notion of a daemon toward "services", which are a different beast. Old-style init could start services, but was pretty much useless thereafter.
Part of the problem was the conflation of services and configuration. Tasks like mounting filesystems are of the latter variety; they are generally done once at boot time and forgotten thereafter. But that approach is not sufficient for automated service management, which requires ongoing attention. Thus we saw the birth of more service-oriented systems like Upstart and systemd. This is something other operating systems figured out a while back. Windows NT had a strong service model from the beginning, he said, and Mac OS has one now in the form of launchd. Other systems had to play a catch-up game to get there.
Appleʼs launchd showed up in the Tiger release and replaced a whole series of event-handling daemons, including init, cron, and inetd. Systemd, Rice said, was an attempt to take a lot of good ideas from launchd. When Lennart Poettering started thinking about the problem, he first looked at Upstart, which was an event-based system that was still based around scripts, but he concluded that he could do a better job. His "Rethinking PID 1" blog post cited launchd as an example to work from. He was concerned about improving boot speed and the need for the init system to be tuned into the hardware and software changes on a running system. When the Unix init system was designed, systems were static, but the environment in which the operating system runs now is far more dynamic.
The service layer
Classic Unix-like systems are split into two major components: the kernel and user space. But kernels have become more dynamic and changeable over time, responding to the hardware on which they run. That has led to the need for a new layer, the "service layer", to sit between the kernel and user space. This layer includes components like udev and Network Manager, but systemd seeks to provide a comprehensive service layer; that is why it has pulled in functionality like udev over time. It has been quite successful, achieving wide (but not universal) adoption through much of the Linux distribution space, often creating a great deal of acrimony in the process.
There are a number of often-heard arguments against systemd; one of those is that it violates the Unix philosophy. This argument, he said, seems to be predicated on the notion that systemd is a single, monolithic binary. That would indeed be silly, but thatʼs not how systemd is structured. It is, instead, a lot of separate binaries maintained within a single project. As "a BSD person" (he is a former FreeBSD core-team member), Rice thought this pulling-together of related concepts makes sense. The result is not the bloated, monolithic system that some people seem to see in systemd.
Another frequently heard criticism is that systemd is buggy. "Itʼs software" so of course itʼs buggy, he said. The notion that systemd has to be perfect, unlike any other system, raises the bar too high. At least systemd has reasonable failure modes much of the time, he said. Then, there is the recurrent complaint usually expressed as some form of "I canʼt stand Lennart Poettering". Rice declined to defend Poetteringʼs approach to community interaction, but he also said that he had to admire Poetteringʼs willpower and determination. Not everybody could have pushed through such a change.
Systemd makes no attempt to be portable to non-Linux systems, which leads to a separate class of complaints. If systemd becomes the standard, there is a risk that non-Linux operating systems will find themselves increasingly isolated. Many people would prefer that systemd stuck to interfaces that were portable across Unix systems, but Rice had a simple response for them: "Unix is dead". Once upon a time, Unix was an exercise in extreme portability that saw some real success. But now the world is "Linux and some rounding errors" (something that, as a FreeBSD person, he finds a little painful to say), and it makes no sense to stick to classic Unix interfaces. The current situation is "a pathological monoculture", and Linux can dictate the terms that the rest of the world must live by.
Systemd has gained a lot from this situation. For example, control groups are a highly capable and interesting mechanism for process management; it would be much harder to do the job without them. They are much more powerful and granular than FreeBSD jails, he said. Developers for systems like FreeBSD can see systemdʼs use of these mechanisms, and its subsequent non-portability, as a threat. But they can also use it as an excuse to feel just as liberated to pursue their own solutions to these problems.
Change and tragedy
The whole systemd battle, Rice said, comes down to a lot of disruptive change; that is where the tragedy comes in. Nerds have a complicated relationship to change; itʼs awesome when we are the ones creating the change, but itʼs untrustworthy when it comes from outside. Systemd represents that sort of externally imposed change that people find threatening. That is true even when the change isnʼt coming from developers like Poettering, who has shown little sympathy toward the people who have to deal with this change that has been imposed on them. That leads to knee-jerk reactions, but people need to step back and think about what they are doing. "Nobody needs to send Lennart Poettering death threats over a piece of software". Contempt is not cool.
Instead, it pays to think about this situation; why did systemd show up, and why is it important? What problem is it solving? One solution for people who donʼt like it is to create their own alternative; that is a good way to find out just how much fun that task is. Among other things, systemd shows how the next generation doesnʼt think about systems in the same way; they see things more in terms of APIs and containers, for example.
So what can we learn from systemd? One is that messaging transports are important. Systemd uses D-Bus heavily, which gives it a lot of flexibility. Rice is not a fan of D-Bus, but he is very much a fan of messaging systems. He has been pushing for BSD systems to develop a native message transport, preferably built into the kernel with more security than D-Bus offers. On top of that one can make a proper remote procedure call system, which is a way to make kernel and user-space components operate at the same level. In a properly designed system, a process can simply create an API request without having to worry about where that request will be handled.
Other lessons include the importance of supporting a proper service lifecycle without having to install additional service-management systems to get there. Service automation via APIs is important; systemd has provided much of what is needed there. Support for containers is also important; they provide a useful way to encapsulate applications.
Systemd, he concluded, fills in the service layer for contemporary Linux systems; it provides a good platform for service management, but certainly does not have to be the only implementation of such a layer. It provides a number of useful features, including painless user-level units, consistent device naming, and even the logging model is good, Rice said. Binary logs are not a bad thing as long as you have the tools to pull them apart. And systemd provides a new model of an application; rather than being a single binary, an application becomes a bunch of stuff encapsulated within some sort of container.
The world is changing around us, Rice said. We can either go with that change or try to resist it; one path is likely to be more rewarding than the other. He suggested that anybody who is critical of systemd should take some time to look more closely and try to find one thing within it that they like. Then, perhaps, the catharsis phase of the tragedy will be complete and we can move on.
A video of this talk is available on YouTube.
[Thanks to linux.conf.au and the Linux Foundation for supporting my travel to the event.]
(Log in to post comments)
HackerNewsBot debug: Calculated post rank: 133 - Loop: 100 - Rank min: 100 - Author rank: 37
Linux Lite 4.2
I kinda miss my old #linuxlite. There's a lot not to like about it (#systemd, the #Ubuntu base), and I would never dare use any Ubuntu-based #Linux distro without the added "aftermarket" safeguards that a former LinuxLite developer made and maintains to protect LL users from that weird upstream beta crap.
Yet there's a lot that I miss about my old distro, too. The super-ultra-mega "newbie friendliness" of the distro. The very helpful and enthusiastic community, which happens to include a lot of users of my current daily driver, #MX-Linux. The exquisite ease of installation, the highly specialized #Xfce4 desktop, the cool tool set. Without the added safety stuff from unlockforus I wouldn't use it, but for total #noobs coming from #Windows or #Mac, I think it beats even #Linux-Mint for introducing new users to #desktop Linux.
So I'm torrenting it today and I'll probably dual-boot it with MX-18, and create a custom LinuxLite-Plus+Unlockme iso to share with new users.