Re: [gentoo-user] Re: Change from udev to eudev?

[Tom H]

On Wed, Jun 15, 2016 at 6:29 AM, Rich Freeman  wrote:
>
> I think I've gotten burned out talking about the advantages of systemd
> on Gentoo lists. If anybody wants to chat about it feel free to ping
> me via email or irc, but not in a channel.

You're giving up far too early! There are a few more years of arguing to come ;)

Re: [gentoo-user] Re: Change from udev to eudev?

[Rich Freeman]

On Wed, Jun 15, 2016 at 3:06 AM, Marc Joliet  wrote:
> Perhaps somebody with more systemd expertise will now feel compelled to
> respond ;-) .

I think I've gotten burned out talking about the advantages of systemd
on Gentoo lists.  If anybody wants to chat about it feel free to ping
me via email or irc, but not in a channel.  Or just ask in any of the
bazillion forums where systemd is the norm.  Or just do a Google
search or search the various list archives.

FWIW, other than Arch you'd be hard-pressed to find a distro that
supports systemd better than Gentoo if you do want to use it...

-- 
Rich

Re: [gentoo-user] Re: Change from udev to eudev?

[Marc Joliet]

On Tuesday 14 June 2016 06:46:32 J. Roeleveld wrote:
>On Monday, June 13, 2016 02:10:27 PM James wrote:
>> wabe  gmail.com> writes:
>> Still, if you manage 1000 linux workstations, then systemd does have
>> it's merits.
>
>Serious question: What makes systemd more suitable to manage 1000 linux
>workstations when compared to, for instance, OpenRC?
>
>--
>Joost

Well, since nobody else gave a proper response yet...

Not being somebody who manages lots of containers like that, I'm not aware of 
*all*
of the relevant features and how they interact, but one that I can think of is 
that
systemd can communicate with systemd instances running in containers started 
with
systemd-nspawn (e.g., "machinectl status " gives you the status of systemd
+ services in a container).  In fact, systemd-nspawn could probably be seen as 
such a
feature in itself (though personally, when I do use it, it's mainly as chroot 
on steroids).
Oh, and its cgroups management probably helps, that is, I *think* that you can 
limit
resource consumption of containers that way, just like with service units 
(though I'm
not 100% sure of that).

In general, my understanding is that systemd provides base features that 
container
management software utilises, and not so much that systemd by itself does 
container
management.

Perhaps somebody with more systemd expertise will now feel compelled to respond 
;-)
.

HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup



signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Change from udev to eudev?

[James]

J. Roeleveld  antarean.org> writes:

> 
> On Monday, June 13, 2016 02:10:27 PM James wrote:
> > wabe  gmail.com> writes:
> > Still, if you manage 1000 linux workstations, then systemd does have
> > it's merits.

> Serious question: What makes systemd more suitable to manage 1000 linux 
> workstations when compared to, for instance, OpenRC?

> Joost


Seriously?
(note:: awkward position for me to defend systemd)


Because RHEL says so? Why else would they promote systemd?

Because It's what bloggers say that make systemd the Kool_aid of choice
these days?

Because really, I was just being polite and trying very hard to say
something nice about systemd?

Because Jim Morrison told me systemd is the way to nirvana, in a 60s laden
pipe dream?

Because, if you are not promoting systemd, you are just not Quool?

Because, resistance, defined as the counterflow to Systemd flux,
is futile? Reflectance is defined as the summation of your futile resistance
area, under the curve. The endpoint being when you finally addopted
(integrated) systemd into your hopes and dreams?

Because cross-dressing the linux systems you manage, with different, custom
scripts, is so 2010. We all need to wear the emperor's new clothes, to be
hip, just like lennertd ?

Because the NSA is funding systemd, and those that do not cooperate, will be
barred from all GSA  and large corporate contracts?

Because Big, Corporate management believes that systemd will enable them to
replace seasoned linux admins with mindless drones from the labor pool?
(Note::Management is always the first to 'drink the Kool_aide' from other
large, corporate vendors)? You do not want to know what else they do, after
guzzling the kool_aide.

Because, I think we all know that I'm no whiz at systemd, actually far from
it; in fact I'll be a very late adopter (perhaps post mortem as they inject
me with embedded linux micro-nomes on my way to an oceanic burial)?


So, one of the common arguments you here is that Systemd can standardize
management across different linux distros. If fact many promote systemd
based on a standardization track, as a really good idea. So in a large
installation, it provides the inter-intra-system discipline thereby reducing
the tendency of admins to create fiefdoms (via unique scripts) within the
different machines that different admins manage ( vs traditional divide and
conquer strategies).

Perhaps a workshop or conference is a good idea, should you want the latest,
expert advice on systemd [1]; just pay attention to the "no smoking signs"
posted near the kool_aid punch-bowl. 

(liar liar, hair on fiar)  -- da doors, resurrection tour.


[1] http://0pointer.net/blog/


it's been great fun defending systemd!
James

Re: [gentoo-user] Re: Change from udev to eudev?

[J. Roeleveld]

On Monday, June 13, 2016 02:10:27 PM James wrote:
> wabe  gmail.com> writes:
> Still, if you manage 1000 linux workstations, then systemd does have
> it's merits.

Serious question: What makes systemd more suitable to manage 1000 linux 
workstations when compared to, for instance, OpenRC?

--
Joost

[gentoo-user] Re: Change from udev to eudev?

[James]

wabe  gmail.com> writes:


> waltdnes  waltdnes.org wrote:


> I'm glad that gentoo users still have an alternative to systemd, and
> hope that this will also be the case in future.

Non Systemd has a very bright future. In clustering, Systemd is ok, even
great for containers. In Hi Performance Computing types of clusters, systemd
is loosing the battle. Many in these trenches
believe that the cluster engines of HPC cluster architectures
will vastly outperform clusters with systemd; thus eventually
removing systemd from linux clusters where performance is important.


Still, if you manage 1000 linux workstations, then systemd does have
it's merits.


> But I really don't wanna start another pro/con systemd thread here! ;-)

Exactly. I just wanted to encourage the non-systemd folks that their future
looks very bright.

> Regards
> wabe


hth,
James

Re: [gentoo-user] Re: Change from udev to eudev?

[wabe]

Jonathan Callen  wrote:

> On 06/09/2016 10:00 AM, Dale wrote:
> > waltd...@waltdnes.org wrote:  
> >> On Thu, Jun 09, 2016 at 08:16:57AM -0500, Dale wrote  
> >>> k...@aspodata.se wrote:  
>  Dale:
>  ...  
> > Can a system even boot without udev?  
>  Yes, use sys-fs/static-dev (unless you have some special boot 
>  requirements).  
> >>> Well, I was talking about if udev was removed and then a reboot
> >>> was done.  I would think it would boot to a certain point then
> >>> when whatever started and needed devices to be created in /dev,
> >>> it would start failing.  I suspect this would vary depending on
> >>> the install as well.  
> >>   You need *A* device-manager.  You can use udev, eudev,
> >> static-dev, mdev, whatever, but you need something.  Mind you,
> >> some software assumes or requires udev/eudev.
> >>  
> > 
> > 
> > What I was referring to was if during this switch from udev to
> > eudev, someone rebooted without any dev manager at all.  In other
> > words, emerge -C udev and then reboot before emerging eudev or some
> > other dev manager.  I suspect that would get interesting pretty
> > quick. 
> > 
> > Dale
> > 
> > :-)  :-) 
> > 
> >   
> 
> Actually, you no longer need a user-space device manager at all,
> unless you want to be able to access device nodes under /dev as a
> user that isn't UID=0 or has CAP_DAC_OVERRIDE.  The kernel provides a
> devtmpfs filesystem that will have every single device node that udev
> used to create (udev no longer even creates the devices -- it just
> relies on devtmpfs doing so), but most of them will be owned by 0:0
> (root:root) with permissions 0600; excepting certain nodes
> like /dev/null or /dev/zero, which will be owned by 0:0 with
> permissions 0666.  One other thing that udev does that you might rely
> on is to create symlinks like /dev/disk/by-label/*, which can be used
> by mount(8) if you specify LABEL=foo in /etc/fstab.  The only other
> things that I'm aware of udev doing is to rename network devices and
> (possibly) to notify other applications of changes, somehow (but I'm
> not sure that it actually does that).
> 
> If you don't actually need any of that (you are working on an embedded
> system where you only need root anyway, for instance), then you can
> just use a bare devtmpfs without a device manager changing
> permissions, adding links, etc.

THX for all the information. Now I understand better what (e)udev is
doing.

--
Regards
wabe

Re: [gentoo-user] Re: Change from udev to eudev?

[waltdnes]

On Thu, Jun 09, 2016 at 10:18:01PM -0400, Jonathan Callen wrote

> Actually, you no longer need a user-space device manager at all, unless
> you want to be able to access device nodes under /dev as a user that
> isn't UID=0 or has CAP_DAC_OVERRIDE.  The kernel provides a devtmpfs
> filesystem that will have every single device node that udev used to
> create (udev no longer even creates the devices -- it just relies on
> devtmpfs doing so), but most of them will be owned by 0:0 (root:root)
> with permissions 0600; excepting certain nodes like /dev/null or
> /dev/zero, which will be owned by 0:0 with permissions 0666.  One other
> thing that udev does that you might rely on is to create symlinks like
> /dev/disk/by-label/*, which can be used by mount(8) if you specify
> LABEL=foo in /etc/fstab.  The only other things that I'm aware of udev
> doing is to rename network devices and (possibly) to notify other
> applications of changes, somehow (but I'm not sure that it actually does
> that).
> 
> If you don't actually need any of that (you are working on an embedded
> system where you only need root anyway, for instance), then you can just
> use a bare devtmpfs without a device manager changing permissions,
> adding links, etc.

  Interesting.  In the initial panic after the announcement that udev
would be subsumed by systemd, I started what went on to become the
Gentoo wiki entries at...

 https://wiki.gentoo.org/wiki/Mdev
 https://wiki.gentoo.org/wiki/Mdev/Automount_USB
 https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount

  I wonder if it would be possible to set up a functional multi-user
devtempfs-based system with appropriate permissions being granted in
/etc/sudoers.d/  It would certainly be an interesting project.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Change from udev to eudev?

[Dale]

Jonathan Callen wrote:
> On 06/09/2016 10:00 AM, Dale wrote:
>> waltd...@waltdnes.org wrote:
>>> On Thu, Jun 09, 2016 at 08:16:57AM -0500, Dale wrote
 k...@aspodata.se wrote:
> Dale:
> ...
>> Can a system even boot without udev?
> Yes, use sys-fs/static-dev (unless you have some special boot 
> requirements).
 Well, I was talking about if udev was removed and then a reboot
 was done.  I would think it would boot to a certain point then when
 whatever started and needed devices to be created in /dev, it would
 start failing.  I suspect this would vary depending on the install
 as well.
>>>   You need *A* device-manager.  You can use udev, eudev, static-dev,
>>> mdev, whatever, but you need something.  Mind you, some software assumes
>>> or requires udev/eudev.
>>>
>>
>> What I was referring to was if during this switch from udev to eudev,
>> someone rebooted without any dev manager at all.  In other words, emerge
>> -C udev and then reboot before emerging eudev or some other dev
>> manager.  I suspect that would get interesting pretty quick. 
>>
>> Dale
>>
>> :-)  :-) 
>>
>>
> Actually, you no longer need a user-space device manager at all, unless
> you want to be able to access device nodes under /dev as a user that
> isn't UID=0 or has CAP_DAC_OVERRIDE.  The kernel provides a devtmpfs
> filesystem that will have every single device node that udev used to
> create (udev no longer even creates the devices -- it just relies on
> devtmpfs doing so), but most of them will be owned by 0:0 (root:root)
> with permissions 0600; excepting certain nodes like /dev/null or
> /dev/zero, which will be owned by 0:0 with permissions 0666.  One other
> thing that udev does that you might rely on is to create symlinks like
> /dev/disk/by-label/*, which can be used by mount(8) if you specify
> LABEL=foo in /etc/fstab.  The only other things that I'm aware of udev
> doing is to rename network devices and (possibly) to notify other
> applications of changes, somehow (but I'm not sure that it actually does
> that).
>
> If you don't actually need any of that (you are working on an embedded
> system where you only need root anyway, for instance), then you can just
> use a bare devtmpfs without a device manager changing permissions,
> adding links, etc.
>


That's interesting to read.  I recall reading about the devtmpfs in the
kernel but thought that was for just the very early stages of booting,
reading /boot to get the kernel and such things required to start the
boot process.  I figured once it got started, it would eventually get to
a point and sort of hang up because it couldn't find devices to read to
keep going. 

Interesting.  Still don't want to test the theory tho.  ;-) 

Dale

:-)  :-) 

[gentoo-user] Re: Change from udev to eudev?

[Jonathan Callen]

On 06/09/2016 10:00 AM, Dale wrote:
> waltd...@waltdnes.org wrote:
>> On Thu, Jun 09, 2016 at 08:16:57AM -0500, Dale wrote
>>> k...@aspodata.se wrote:
 Dale:
 ...
> Can a system even boot without udev?
 Yes, use sys-fs/static-dev (unless you have some special boot 
 requirements).
>>> Well, I was talking about if udev was removed and then a reboot
>>> was done.  I would think it would boot to a certain point then when
>>> whatever started and needed devices to be created in /dev, it would
>>> start failing.  I suspect this would vary depending on the install
>>> as well.
>>   You need *A* device-manager.  You can use udev, eudev, static-dev,
>> mdev, whatever, but you need something.  Mind you, some software assumes
>> or requires udev/eudev.
>>
> 
> 
> What I was referring to was if during this switch from udev to eudev,
> someone rebooted without any dev manager at all.  In other words, emerge
> -C udev and then reboot before emerging eudev or some other dev
> manager.  I suspect that would get interesting pretty quick. 
> 
> Dale
> 
> :-)  :-) 
> 
> 

Actually, you no longer need a user-space device manager at all, unless
you want to be able to access device nodes under /dev as a user that
isn't UID=0 or has CAP_DAC_OVERRIDE.  The kernel provides a devtmpfs
filesystem that will have every single device node that udev used to
create (udev no longer even creates the devices -- it just relies on
devtmpfs doing so), but most of them will be owned by 0:0 (root:root)
with permissions 0600; excepting certain nodes like /dev/null or
/dev/zero, which will be owned by 0:0 with permissions 0666.  One other
thing that udev does that you might rely on is to create symlinks like
/dev/disk/by-label/*, which can be used by mount(8) if you specify
LABEL=foo in /etc/fstab.  The only other things that I'm aware of udev
doing is to rename network devices and (possibly) to notify other
applications of changes, somehow (but I'm not sure that it actually does
that).

If you don't actually need any of that (you are working on an embedded
system where you only need root anyway, for instance), then you can just
use a bare devtmpfs without a device manager changing permissions,
adding links, etc.

-- 
Jonathan Callen



signature.asc
Description: OpenPGP digital signature