On November 27, 2016 5:42:40 PM CST, Bruce Dubbs <[email protected]>
wrote:
Douglas R. Reno wrote:
On Nov 27, 2016 5:10 PM, "Bruce Dubbs" <[email protected]> wrote:
akhiezer wrote:
D-Bus next to be 'integrated' into sysd? :
----
https://lwn.net/Articles/705479/
--
Nov. 2016
--
"D-Bus is incompatible with a chroot() environment because there is
a need to drop policy files into the host filesystem. For now, that
is an unsolved problem, but the goal is to move D-Bus functionality
into systemd itself. That is something the project should have done
a
long time ago, Poettering said. The systemd D-Bus server would then
use a different policy mechanism that doesn't require access to the
host filesystem."
----
Why do they NEED to do this? The short answer is that they don't.
It's
about politics and control.
https://devuan.org/
NIH syndrone? According to the above, Poettering wants this to be in
systemd for some reason. I don't see what is wrong with a stacked mount
in the host, followed by an ro, or again stacked bind mount in the
chroot environment, nor how having dbus in systemd solves this
particular problem unless the intention is to have the policy
'filesystem' be entirely virtual and be built from configuration files.
Why can't this be done outside of systemd?
Have you ever heard of Containers? They use these VM snapshots all
over in
modern IT. Each container is running on a host running systemd and
one of
Xen, Docker, KVM, etc. And the Containers can all start off the same
image
with the exception of a few volatile filesystems. Companies such as
CapitalOne and Abbot Laboratories use this all the time. They do this
to
cut energy usage and bring the TCO down. This is why systemd was
invented.
It is NOT about Politics and Control. There is a practical reason for
it.
And what percentage of Linux users uses this capability?
Depends on how tightly you want to define 'container.' Number is
probably not very high for desktop users. Using the loosest definition,
the number falls even more if you exclude LFS users. ;-) Coreutils
chroot will never take advantage of new kernel features, for the same
reason that the CPUID patch will never be accepted for uname - it's
Linux specific.
One size fits
all? And at the expense of complexity. There is a problem with dhcp
--
updated systemd. There is a problem with ntp -- update systemd. There
is
a problem with udev -- update systemd.
The bigger a software package becomes, the harder it is to ensure
security
and otherwise manage.
Agree completely, but not much we can do about this new development. If
we can continue to rip out the parts needed (ie: eudev and elogind, and
I guess edbus soon?) we are good for the foreseeable future. LXC will
continue to work for containers as it does today I presume. If they make
it incompatible, then I don't know, but for now we are good.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
