[gentoo-dev] call for testers: udev predictable network interface names

[gentoo-dev] call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

All,

as you probably know by now, udev-197 has hit the tree.

This new version implements a new feature called predictable network
interface names [1], which I have currently turned off for live systems, because it
will require migration on the part of the user.

When you upgrade to this new version of udev, you will find a file
/etc/udev/rules.d/80-net-name-slot.rules on your system. It currently
has comments explaining what is happening.

As long as this file is in place, this feature is not activated. That is
why there is not a news item. If you do nothing, nothing changes.

What I would like to do is find some people who are willing to migrate
and report any issues they find.

I would like this to be the default for everyone at some point, so I
want to document the migration process and find out if there are any
bugs in tools because they expect the eth* names.

Thoughts?

William

[1]
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Christopher Head]

On Wed, 9 Jan 2013 16:13:10 -0600
William Hubbs <williamh@gentoo.org> wrote:

> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

This seems like a good thing for some systems. Will there be a news
item when 197 (or greater) goes stable informing people that the option
is available and if they want to use it they can do so? In my (ordinary
user) opinion, there should be.

Chris

Re: [gentoo-dev] call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

On Wed, Jan 09, 2013 at 02:59:10PM -0800, Christopher Head wrote:
> On Wed, 9 Jan 2013 16:13:10 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
> 
> This seems like a good thing for some systems. Will there be a news
> item when 197 (or greater) goes stable informing people that the option
> is available and if they want to use it they can do so? In my (ordinary
> user) opinion, there should be.

There will definitely be a newsitem before this hits stable.

Once we figure out what the migration will involve and if there are any
bugs we need to worry about, I want to discuss making this the default
setup before we go stable.

There is a way for users to opt out if we default this to on, but I
think the new naming scheme has advantages over the traditional eth*
wlan* etc names.

I did the migration myself on my box this afternoon in just a minute or
two; it wasn't painful at all.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Christopher Head]

On Wed, 9 Jan 2013 18:13:21 -0600
William Hubbs <williamh@gentoo.org> wrote:

> There is a way for users to opt out if we default this to on, but I
> think the new naming scheme has advantages over the traditional eth*
> wlan* etc names.

I think it should be taken with a grain of salt. The page mentions how
it lets you replace a failed NIC without losing its name. But given a
simple computer with just one NIC, if the NIC fails and is replaced
(perhaps by a different type of NIC in a different slot, or perhaps an
onboard NIC disabled in the BIOS and replaced by an add-in), the name
could change, while the kernel’s automatically assigned name will not:
eth0 (this also applies to a computer with one Ethernet NIC and one
wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki
page, even though it applies to a heck of a lot of systems. Perhaps
something to include when the Gentoo docs are put together, as part of
the balance of reasons to choose one way or the other?

Chris

[gentoo-dev] Re: call for testers: udev predictable network interface names

[Steven J. Long]

Christopher Head wrote:
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > There is a way for users to opt out if we default this to on, but I
> > think the new naming scheme has advantages over the traditional eth*
> > wlan* etc names.
> 
> I think it should be taken with a grain of salt. The page mentions how
> it lets you replace a failed NIC without losing its name. But given a
> simple computer with just one NIC, if the NIC fails and is replaced
> (perhaps by a different type of NIC in a different slot, or perhaps an
> onboard NIC disabled in the BIOS and replaced by an add-in), the name
> could change, while the kernel’s automatically assigned name will not:
> eth0 (this also applies to a computer with one Ethernet NIC and one
> wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki
> page, even though it applies to a heck of a lot of systems. Perhaps
> something to include when the Gentoo docs are put together, as part of
> the balance of reasons to choose one way or the other?
>
That's a very good point. For the vast majority of users all these
"desktop" changes are supposed to help, it's not at all relevant.
Obviously it's good to have the functionality should you need it, but
again it appears that simple cases are being made complex, just to allow
for someone else's complex cases. Which is faulty logic.

While many packages have default configurations, changing the default
setup for base system packages in the absence of any configuration is
not generally a good idea, unless you know for a fact it's not going to
mess anything up (which is a big ask given that you're distributing
source.)

Especially given the arguments presented as a motivation, that all this
has "serious security implications, for example in firewall rules which
are coded for certain naming schemes, and which are hence very sensitive
to unpredictable changing names."

If you're certain that every user with a current simple setup, who
uses the kernel default names, and has such a firewall setup isn't
going to suddenly find their interface name changed when they reboot,
fair play to you. If not, allow the admin to opt-in, rather than force
them to opt-out when something breaks.

That's the usual manner to introduce something new or changed, and for
good reason. After all, those who are aware of it and interested,
already know to configure it, or are looking for help to do so. Most
other users don't care, and don't want the maintenance headache.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: call for testers: udev predictable network interface names

[Alec Warner]

On Fri, Jan 11, 2013 at 6:11 PM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
> Christopher Head wrote:
>> William Hubbs <williamh@gentoo.org> wrote:
>>
>> > There is a way for users to opt out if we default this to on, but I
>> > think the new naming scheme has advantages over the traditional eth*
>> > wlan* etc names.
>>
>> I think it should be taken with a grain of salt. The page mentions how
>> it lets you replace a failed NIC without losing its name. But given a
>> simple computer with just one NIC, if the NIC fails and is replaced
>> (perhaps by a different type of NIC in a different slot, or perhaps an
>> onboard NIC disabled in the BIOS and replaced by an add-in), the name
>> could change, while the kernel’s automatically assigned name will not:
>> eth0 (this also applies to a computer with one Ethernet NIC and one
>> wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki
>> page, even though it applies to a heck of a lot of systems. Perhaps
>> something to include when the Gentoo docs are put together, as part of
>> the balance of reasons to choose one way or the other?
>>
> That's a very good point. For the vast majority of users all these
> "desktop" changes are supposed to help, it's not at all relevant.
> Obviously it's good to have the functionality should you need it, but
> again it appears that simple cases are being made complex, just to allow
> for someone else's complex cases. Which is faulty logic.

I think the wiki page explains the motivations well. They are similar
to the disk changes that were made years ago (porting apps to use
UUIDs to ensure you have the correct disk, even when disk order
changes.) The MAC address is obviously the first UUID one thinks of;
however they talk about why they did not end up choosing the MAC
address as the UUID for network devices.

As an example; I have a server with two ethernet ports. One is onboard
(driverA) and the other is a pci-express card (driverB.) It turns out
driverB doesn't work, but sometimes driverB gets put as eth0. Then the
machine cannot get on the network. We work around this by blacklisting
driverB (so it is never loaded as an ethernet device) but it might be
saner to adopt this new udev and simply configure the network to use
driverA always.

>
> While many packages have default configurations, changing the default
> setup for base system packages in the absence of any configuration is
> not generally a good idea, unless you know for a fact it's not going to
> mess anything up (which is a big ask given that you're distributing
> source.)
>
> Especially given the arguments presented as a motivation, that all this
> has "serious security implications, for example in firewall rules which
> are coded for certain naming schemes, and which are hence very sensitive
> to unpredictable changing names."
>
> If you're certain that every user with a current simple setup, who
> uses the kernel default names, and has such a firewall setup isn't
> going to suddenly find their interface name changed when they reboot,
> fair play to you. If not, allow the admin to opt-in, rather than force
> them to opt-out when something breaks.
>
> That's the usual manner to introduce something new or changed, and for
> good reason. After all, those who are aware of it and interested,
> already know to configure it, or are looking for help to do so. Most
> other users don't care, and don't want the maintenance headache.

I agree it is one way to introduce something new; I wouldn't say it is
the only way (or even the 'usual' way.)

>
> --
> #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
>

Re: [gentoo-dev] Re: call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 4614 bytes --]

On Sat, Jan 12, 2013 at 02:11:43AM +0000, Steven J. Long wrote:
> Christopher Head wrote:
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > There is a way for users to opt out if we default this to on, but I
> > > think the new naming scheme has advantages over the traditional eth*
> > > wlan* etc names.
> > 
> > I think it should be taken with a grain of salt. The page mentions how
> > it lets you replace a failed NIC without losing its name. But given a
> > simple computer with just one NIC, if the NIC fails and is replaced
> > (perhaps by a different type of NIC in a different slot, or perhaps an
> > onboard NIC disabled in the BIOS and replaced by an add-in), the name
> > could change, while the kernel’s automatically assigned name will not:
> > eth0 (this also applies to a computer with one Ethernet NIC and one
> > wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki
> > page, even though it applies to a heck of a lot of systems. Perhaps
> > something to include when the Gentoo docs are put together, as part of
> > the balance of reasons to choose one way or the other?
> >
> That's a very good point. For the vast majority of users all these
> "desktop" changes are supposed to help, it's not at all relevant.
> Obviously it's good to have the functionality should you need it, but
> again it appears that simple cases are being made complex, just to allow
> for someone else's complex cases. Which is faulty logic.
> 
> While many packages have default configurations, changing the default
> setup for base system packages in the absence of any configuration is
> not generally a good idea, unless you know for a fact it's not going to
> mess anything up (which is a big ask given that you're distributing
> source.)
> 
> Especially given the arguments presented as a motivation, that all this
> has "serious security implications, for example in firewall rules which
> are coded for certain naming schemes, and which are hence very sensitive
> to unpredictable changing names."

Isn't this the very definition of the kernel-based names? if you do not
have a persistent net rules file, you are subject to the kernel's naming
order, and I have heard of situations in the past when people upgrade
their kernels, etc, and when they reboot their interface names are
changed around.

> If you're certain that every user with a current simple setup, who
> uses the kernel default names, and has such a firewall setup isn't
> going to suddenly find their interface name changed when they reboot,
> fair play to you. If not, allow the admin to opt-in, rather than force
> them to opt-out when something breaks.

The following is taken from the wiki:

"
I don't like this, how do I disable this?
 
You basically have three options: 

1.  You disable the assignment of fixed names, so that the unpredictable
kernel names are used again. For this, simply mask udev's rule file for
the default policy:
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules 

2.  You create your own manual naming scheme, for example by naming your
interfaces "internet0", "dmz0" or "lan0". For that create your own udev
rules file and set the NAME property for the devices. Make sure to
order it before the default policy file, for example by naming it
/etc/udev/rules.d/70-my-net-names.rules 

3.  You alter the default policy file, for picking a different naming
scheme, for example for naming all interface names after their MAC
address by default:

cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules,

then edit the file there and change the lines as necessary. 
"

If you have upgraded your udev, you see that you have the file
/etc/udev/rules.d/80-net-name-slot.rules. This file is only created
*once*, when you upgrade from a version of udev lower than 197. This
means when this version of udev goes stable, new installs will not
have this file created.

If you have a file that fits the requirements of option 2 (which
70-persistent-net.rules does) in your
/etc/udev/rules.d, you can rm 80-net-name-slot.rules and you will not be
affected.

If you do not have a file in /etc/udev/rules.d that fits the
requirements of option 2 and you remove 80-net-name-slot.rules, your
interface names will change on your next reboot, so you should be
prepared for that. The created version of
/etc/udev/rules.d/80-net-name-slot.rules has comments explaining how to
get the new names of your network interfaces before the reboot so you
can reconfigure.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Steven J. Long]

On Sat, Jan 12, 2013 William Hubbs wrote:
> Steven J. Long wrote:
> > Obviously it's good to have the functionality should you need it, but
> > again it appears that simple cases are being made complex, just to allow
> > for someone else's complex cases. Which is faulty logic.
> > 
> > While many packages have default configurations, changing the default
> > setup for base system packages in the absence of any configuration is
> > not generally a good idea, unless you know for a fact it's not going to
> > mess anything up (which is a big ask given that you're distributing
> > source.)
> >
> > Especially given the arguments presented as a motivation, that all this
> > has "serious security implications, for example in firewall rules which
> > are coded for certain naming schemes, and which are hence very sensitive
> > to unpredictable changing names."
> 
> Isn't this the very definition of the kernel-based names?

Not if you read what Christopher wrote in his reply to you:

> > Christopher Head wrote:
> > > But given a
> > > simple computer with just one NIC, if the NIC fails and is replaced
> > > (perhaps by a different type of NIC in a different slot, or perhaps an
> > > onboard NIC disabled in the BIOS and replaced by an add-in), the name
> > > could change, while the kernel's automatically assigned name will not:
> > > eth0 (this also applies to a computer with one Ethernet NIC and one
> > > wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki.

Amazingly convenient. Anyone would think the kernel devs had gone through this
themselves! ;)

IME that setup describes pretty much every end-user desktop or laptop computer
I've come across, except the *very* occasional analyst with 2 NICs, and users
I don't count as end-users-- in whose name all the awful hackage is supposedly
carried out.

> if you do not
> have a persistent net rules file, you are subject to the kernel's naming
> order, and I have heard of situations in the past when people upgrade
> their kernels, etc, and when they reboot their interface names are
> changed around.

Yes, I've heard of that too, and I'm all for giving them the ability to
set things up exactly how they like, just like I've always been in favour
of an initrd *if* you need it (or are a binary distro.) Granted that's always
meant encrypted rootfs to me, but a bluetooth keyboard is just as valid: it's
the user's choice/system, give them what they need to set it up and run it (and
leave you alone.)

What I'm not in favour of is making the simple cases more difficult, to deal
with the complex ones. It's completely brain-dead thinking.

More importantly, advances in the code don't change the principle:
 you don't break backward compatibility for a default install;
 you don't require people to opt into anything in order to keep their
existing config running, MOST especially if they have not even tweaked anything.
You put out the last version, so if something's not supported in the new one,
you write code to handle the change gracefully, if it's needed.

Or you get a well-earnt basting.

I guess in distro context you have to allow: unless it's a whole new
package, or at worst a major version change. But the principle still
applies, *more* stringently to a coder than a distro packager, irrespective
of how people learning nowadays might carry on.

Or just give up any pretence of caring about your users (and where I come
from, the majority of the pay that you nearly burnt-out to earn, since you
have to cover another 2 or 3 months of remedial work caused by your own
stupidity.)

> > If you're certain that every user with a current simple setup, who
> > uses the kernel default names, and has such a firewall setup isn't
> > going to suddenly find their interface name changed when they reboot,
> > fair play to you. If not, allow the admin to opt-in, rather than force
> > them to opt-out when something breaks.
> 
> The following is taken from the wiki:
> 
> You basically have three options: 
<3 options that all require an admin opt-in to keep their existing
 config running>

There you go: the exact wrong way to do it. As Poettering might say:
"C'mon man, seriously? (whiny voice and pleading looks)"

Honestly, the guy's a complete amateur.
-- 
#friendly-coders -- Where you can unwind when some nub starts throwing
    the word "integration" around.

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Peter Stuge]

Steven J. Long wrote:
> What I'm not in favour of is making the simple cases more
> difficult, to deal with the complex ones. It's completely
> brain-dead thinking.

This is exactly what some people think or say when they learn that I
use Gentoo.

I appreciate Gentoo because I am able and willing to control my system.

Users of other distributions are either not able or not willing or
both, and thus they find Gentoo completely brain-dead. That's fine.

I don't have to care about them when deciding what I will run.

I hope the analogy is clear.

If the kernel changes it's network device naming policy, please talk
to the kernel developers - it seems counterproductive to expect that
some distribution will bend far f-ing backwards in order to provide
you the same experience that you were used to with the old kernel.

It seems equally counterproductive to expect or demand that udev will
change (or not change) the way you want it to, if you are not one of
the core developers.

William is packaging upstream udev for Gentoo.

You are shooting the messenger.

If you do not like what udev is doing, then step in and PARTICIPATE
in that project, or in one of the competing projects. (I wish there
wouldn't be so much fragmentation, but the NIH syndrome is mighty.)

The task of distributions is to deliver a composite of upstreams.

The task of distributions is NOT to deliver an immutable system where
internals are magically updated with all the latest developments and
fixes, except for all the latest developments that make any sort of
visible change because those require an administrator to work.


I think that if you have a requirement for an extremely stable
environment, to the point where network interface names matter,
then you need to take significant responsibility to *create* that
environment *yourself*. You can't really rely on distributions to
do that for you - that's not part of their value proposition.

I would suggest to leverage the fantastic Gentoo tools and portage,
in order to create your own distribution which suits your needs.

Open source is only ever successful when you own your problems.


//Peter

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Kevin Chadwick]

> William is packaging upstream udev for Gentoo.
> 
> You are shooting the messenger.

I expect there is 0 blame meant for William. 


P.s. 

Is it William that Lennart dished some blame in the direction of. I
completely disagree. It's not the job of every distro to look for all
build flags to fix some software's defaults because other software has
some small issues. That's simply ludicrous and my best guess is it
being a feeble attempt at reasoning an excuse. At the very least and
like in many release notes, it should have been made clear that distros
may wish to consider using that flag to keep the current behaviour
whether any reason to do was understood or not. The thought strikes me
now that in the reverse case their likely wouldn't be any justification
for having a build flag?

Debian having to patch KDE to use /etc for configs is simply wrong too.

You are right though, I don't suppose it helps much airing any of it
here.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Samuli Suominen]

On 14/01/13 20:35, Kevin Chadwick wrote:
> Debian having to patch KDE to use /etc for configs is simply wrong too.

huh huh, do you know if they have a fix for 
http://bugs.gentoo.org/438790 to stop KDE from destroying upstream 
polkit files?

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

> > Debian having to patch KDE to use /etc for configs is simply wrong too.  
> 
> huh huh, do you know if they have a fix for 
> http://bugs.gentoo.org/438790 to stop KDE from destroying upstream 
> polkit files?

I don't, I just know that on Debian the configs are in /etc and the bug
you mention, comments was what caused me to comment.

"Debian patches to make /etc/kde4 the config directory".

Of course it may just be that debians KDE hasn't got the polkit
rubbish as it is older.

I remember reading a while back that distros had some blunders in
writing secure sudoers files and so it was emptied. Is that true?

I still ascert that apps adding groups with NOPASSWD sudoers lines
perhaps even commented out by default in all or some cases is far
better than polkit for many reasons. Any counter argument can apply
to sudo too and rather easily.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Rich Freeman]

On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>
> I still ascert that apps adding groups with NOPASSWD sudoers lines
> perhaps even commented out by default in all or some cases is far
> better than polkit for many reasons. Any counter argument can apply
> to sudo too and rather easily.
>

I think you need to consider the use case for polkit and such.  I
believe they were focused on linux on the desktop.  Imagine you have
10,000 users running linux on the desktop.  Anybody can log into any
PC.  Do you want anybody to be able to remote login to any PC and
access the webcam and audio, or access local USB drives and such
(which do not have POSIX security applied to their filesystems)?
Unless sudo has some config setting that allows access only when
logged in via console it isn't really a solution.

Rich

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Alec Warner]

On Tue, Jan 15, 2013 at 3:00 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>>
>> I still ascert that apps adding groups with NOPASSWD sudoers lines
>> perhaps even commented out by default in all or some cases is far
>> better than polkit for many reasons. Any counter argument can apply
>> to sudo too and rather easily.
>>
>
> I think you need to consider the use case for polkit and such.  I
> believe they were focused on linux on the desktop.  Imagine you have
> 10,000 users running linux on the desktop.  Anybody can log into any
> PC.  Do you want anybody to be able to remote login to any PC and
> access the webcam and audio, or access local USB drives and such
> (which do not have POSIX security applied to their filesystems)?
> Unless sudo has some config setting that allows access only when
> logged in via console it isn't really a solution.
>
> Rich
>

I manage 'thousands' of desktops at Google and we generally like
polkit. It is however, designed for graphical UI single-seat systems.
Its command line support sucks (they only added a CLI auth agent in
May) and it is not well adopted. Multi-user systems do not work well
with polkit. Certainly with polkit and dbus you can allow users to
take more specific action without complex wrappers, setuid scripts, or
sudo. My package manager can have a polkit action like 'install a
signed package' and I can grant the user access to do that, but not
access to install unsigned packages (root exploit there...) or run
other dangerous apt commands. It comes built into apt, so I don't have
to write extra wrappers.

I don't recommend letting anyone log into any desktop, from a security
policy POV :)

-A

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

> > Unless sudo has some config setting that allows access only when
> > logged in via console it isn't really a solution.
> >
> > Rich
> >  

man sudoers -> /requiretty

> 
> I manage 'thousands' of desktops at Google and we generally like
> polkit.

I never meant it is rubbish as such but I saw it as rediculously
inferior to sudo before I even read this.

http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/


> It is however, designed for graphical UI single-seat systems.
> Its command line support sucks (they only added a CLI auth agent in
> May) and it is not well adopted. Multi-user systems do not work well
> with polkit. Certainly with polkit and dbus you can allow users to
> take more specific action without complex wrappers, setuid scripts, or
> sudo.

Except you can't, it only encourages more coarse grained approaches,
less useful commands available and devs to learn an api rather than C
and simply moves code into a far less secure mechanism and increases the
chance that the code will not be well designed to the task at hand and
running as root. It can be a real pain to work out exactly what polkit
allows and you cannot just edit it to suit your application and it
completely ignores the existing unix security technologies with
brilliant track records.

You could try to argue that many eyes will look at a central piece of
code but in fact less implementations will likely mean less eyes and
just assumption that a guy who got JS through as a config language has
everything covered. Granted, unmaintained code running as root may be
higher with sudo but if it needs maintaining, should it be running as
root at all or is it actually simply doing too much.

> My package manager can have a polkit action like 'install a
> signed package' and I can grant the user access to do that, but not
> access to install unsigned packages (root exploit there...) or run
> other dangerous apt commands. It comes built into apt, so I don't have
> to write extra wrappers.

That would be the default and wouldn't even need the command line
argument control of sudo. Just allowing updates is apt-get update.

In fact I have a debian system where experimental iceweasel is
installable but nothing else. I have an Arch system where the only
kernel updateable is a signed by me when offline kernel and polkit is
disabled as I don't have the time to keep track of what it is
permitting and code comments weren't helpful there.

Sudo even supports regex!

p.s. apt should be downloading as an _apt user, simply as best
practice before adding polkit support ;-)

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Maxim Kammerer]

On Tue, Jan 15, 2013 at 9:43 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> You could try to argue that many eyes will look at a central piece of
> code but in fact less implementations will likely mean less eyes and
> just assumption that a guy who got JS through as a config language has
> everything covered.

Still can't wrap my mind around that. A call into a multi-MB generic
language library (usually with JIT as well) on every PolKit action —
right, a good idea. I kind of liked PolKit before that change.

This is a major problem, there are other questionable choices that
raise the question whether developers are familiar with how things are
done on Unix:
https://bugs.freedesktop.org/show_bug.cgi?id=58787

> Sudo even supports regex!

Only glob patterns, and it's not too good at that.
http://www.sudo.ws/bugs/show_bug.cgi?id=500

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

On Tue, 15 Jan 2013 22:19:37 +0200
Maxim Kammerer <mk@dee.su> wrote:

> This is a major problem, there are other questionable choices that
> raise the question whether developers are familiar with how things are
> done on Unix:
> https://bugs.freedesktop.org/show_bug.cgi?id=58787
> 

I have to confess that despite this being a serious matter that really
made me chuckle.

> > Sudo even supports regex!  
> 
> Only glob patterns, and it's not too good at that.
> http://www.sudo.ws/bugs/show_bug.cgi?id=500


/etc/sudoers:
anon	liberte = NOPASSWD: /sbin/shutdown -[hr] now

sudo shutdown -h now -> allowed
sudo shutdown "-h now" -> allowed (probably shouldn't be)

It may not be perfect and is why I would love to see distros grow some
balls or perhaps more rightly packagers and embrace sudoers again but it
is far clearer what is allowed than polkit and I believe.

/sbin/shutdown -[h][r]

Would do what you want. You may need to test but I have never found a
command I couldn't add to sudoers.

After all it can only make the likes of Ubuntu and perhaps all in fact
more secure ;-)

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Alec Warner]

On Tue, Jan 15, 2013 at 11:43 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> > Unless sudo has some config setting that allows access only when
>> > logged in via console it isn't really a solution.
>> >
>> > Rich
>> >
>
> man sudoers -> /requiretty
>
>>
>> I manage 'thousands' of desktops at Google and we generally like
>> polkit.
>
> I never meant it is rubbish as such but I saw it as rediculously
> inferior to sudo before I even read this.
>
> http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/

Perhaps I'm misunderstanding, but that is talking about a specific set
of problems that I don't think polkit was actually designed to
address. Polkit is basically for authenticating applications via
users, not the applications themselves. If I am running app foo, and
app foo wants to inhibit hibernation; polkit is there to ask 'hey is
antarus allowed to inhibit hibernation? Does antarus need to auth to
do so? Is antarus already authenticated? Now one may say 'hey but I
only want certain applications to hibernate' and while that may be an
interesting problem...I don't think the existing polkit intends to
solve it.

>
>
>> It is however, designed for graphical UI single-seat systems.
>> Its command line support sucks (they only added a CLI auth agent in
>> May) and it is not well adopted. Multi-user systems do not work well
>> with polkit. Certainly with polkit and dbus you can allow users to
>> take more specific action without complex wrappers, setuid scripts, or
>> sudo.
>
> Except you can't, it only encourages more coarse grained approaches,
> less useful commands available and devs to learn an api rather than C
> and simply moves code into a far less secure mechanism and increases the
> chance that the code will not be well designed to the task at hand and
> running as root. It can be a real pain to work out exactly what polkit
> allows and you cannot just edit it to suit your application and it
> completely ignores the existing unix security technologies with
> brilliant track records.

One could say that 'a discrete set of APIs will be no match for
the..fined grain control that is the command line!' I would agree. I
don't agree that this is a one-size fits all deal though. There can be
a command line AND an API. I'd rather grant my users 'access to the
install authenticated packages action' than have to own a complex sudo
rule.

I don't understand 'the APIs that coders will learn instead of C.' Can
you elaborate? Polkit has a C api...

I don't understand how the code will 'not be well designed to the
application at hand.' I mean ideally the API and the CLI are
essentially just wrappers around the same library of functions.

Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
you will have to read some manpages. However i don't think the
concepts are difficult. There are plenty of helpers (pkcheck springs
to mind) that assist the user in figuring out what is 'allowed'. The
configuration for polkit is all in /usr/share and /etc. The configs
are configurable..again in /etc. This is not something I would term
'challenging.'

>
> You could try to argue that many eyes will look at a central piece of
> code but in fact less implementations will likely mean less eyes and
> just assumption that a guy who got JS through as a config language has
> everything covered. Granted, unmaintained code running as root may be
> higher with sudo but if it needs maintaining, should it be running as
> root at all or is it actually simply doing too much.

Its not a matter of many-eyes. It is a matter of 'some other guy is in
charge of maintaining that component.' It means I can focus on stuff
that matters, and not focus on 'wrappers to make random things work.'
Is the polkit maintain any less 'trustworthy' than the gnome
maintainers? the kde maintainers? the kernel maintainers? At the end
of the day my machines are running software from thousands of
contributors.

>
>> My package manager can have a polkit action like 'install a
>> signed package' and I can grant the user access to do that, but not
>> access to install unsigned packages (root exploit there...) or run
>> other dangerous apt commands. It comes built into apt, so I don't have
>> to write extra wrappers.
>
> That would be the default and wouldn't even need the command line
> argument control of sudo. Just allowing updates is apt-get update.

Er, apt-get update downloads new Packages files, it doesn't install
any additional software. apt-get *upgrade* will. These are separate
*actions*.

>
> In fact I have a debian system where experimental iceweasel is
> installable but nothing else. I have an Arch system where the only
> kernel updateable is a signed by me when offline kernel and polkit is
> disabled as I don't have the time to keep track of what it is
> permitting and code comments weren't helpful there.

Look if you don't trust polkit, or you dislike it, or you just don't
have time to understand how it works; that is cool. 18 months ago I
was in the same camp. Polkit is not strictly required. But don't go
spouting about how much it sucks unless you have actually *used* it.

In some cases (like most places where multiple users are present) it
is in fact terrible. We wanted to do some 'unique' things with
mounting of USB hardware with polkit (and udisks) and found it
basically impossible to make work over ssh. I ended up going with the
'sudo make me a sandwich' route. Sometimes that is necessary.

>
> Sudo even supports regex!
>
> p.s. apt should be downloading as an _apt user, simply as best
> practice before adding polkit support ;-)

Feel free to file a bug against apt. I don't maintain it (I am not
even a Debian developer.)

>
> --
> _______________________________________________________________________
>
> 'Write programs that do one thing and do it well. Write programs to work
> together. Write programs to handle text streams, because that is a
> universal interface'
>
> (Doug McIlroy)
> _______________________________________________________________________
>

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

> >
> > I never meant it is rubbish as such but I saw it as rediculously
> > inferior to sudo before I even read this.
> >
> > http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/
> 
> Perhaps I'm misunderstanding, but that is talking about a specific set
> of problems that I don't think polkit was actually designed to
> address. Polkit is basically for authenticating applications via
> users, not the applications themselves. If I am running app foo, and
> app foo wants to inhibit hibernation; polkit is there to ask 'hey is
> antarus allowed to inhibit hibernation? Does antarus need to auth to
> do so? Is antarus already authenticated? Now one may say 'hey but I
> only want certain applications to hibernate' and while that may be an
> interesting problem...I don't think the existing polkit intends to
> solve it.
> 

The point is that it is inferior in every way and so pointlessly causing
more work and other problems not to mention guaranteed increased
security risk having extra code constantly running as root. Why was it
started, rather than contributing to sudo.

> >
> >
> >> It is however, designed for graphical UI single-seat systems.
> >> Its command line support sucks (they only added a CLI auth agent in
> >> May) and it is not well adopted. Multi-user systems do not work well
> >> with polkit. Certainly with polkit and dbus you can allow users to
> >> take more specific action without complex wrappers, setuid scripts, or
> >> sudo.
> >
> > Except you can't, it only encourages more coarse grained approaches,
> > less useful commands available and devs to learn an api rather than C
> > and simply moves code into a far less secure mechanism and increases the
> > chance that the code will not be well designed to the task at hand and
> > running as root. It can be a real pain to work out exactly what polkit
> > allows and you cannot just edit it to suit your application and it
> > completely ignores the existing unix security technologies with
> > brilliant track records.
> 
> One could say that 'a discrete set of APIs will be no match for
> the..fined grain control that is the command line!' I would agree. I
> don't agree that this is a one-size fits all deal though. There can be
> a command line AND an API. I'd rather grant my users 'access to the
> install authenticated packages action' than have to own a complex sudo
> rule.
> 

How about uncommenting a line that does so. All you are buying into is
a default setup.

> I don't understand 'the APIs that coders will learn instead of C.' Can
> you elaborate? Polkit has a C api...
> 

It has an api that is simply not needed? Small tools are better.

> I don't understand how the code will 'not be well designed to the
> application at hand.' I mean ideally the API and the CLI are
> essentially just wrappers around the same library of functions.
> 

If you search for sites that evaluate polkit you will see that it is
considered to encourage granting more permissions than necessary rather
than coding a specific tool.

> Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
> you will have to read some manpages. However i don't think the
> concepts are difficult.

Man pages won't help with polkit and it actually generally ships with no
configs by default.

> There are plenty of helpers (pkcheck springs
> to mind) that assist the user in figuring out what is 'allowed'. 

I know about pkaction, the problem is that the actions tells you next to
nothing about what is actually allowed. I haven't time to dig out one
of the rediculous comments from the source now unfortunately. With
small tools it's much better all round.

>The
> configuration for polkit is all in /usr/share and /etc. The configs
> are configurable..again in /etc. This is not something I would term
> 'challenging.'
> 

Generally there aren't any rules files, the defaults are built in and
your expected to use a webbrowser, even on a server?!?! You shouldn't
run lynx never mind X on a server. 

If some configs are in /usr/share rather than /etc perhaps that explains
why one tutorial said so and it has no effect on some systems.

> >
> > You could try to argue that many eyes will look at a central piece of
> > code but in fact less implementations will likely mean less eyes and
> > just assumption that a guy who got JS through as a config language has
> > everything covered. Granted, unmaintained code running as root may be
> > higher with sudo but if it needs maintaining, should it be running as
> > root at all or is it actually simply doing too much.
> 
> Its not a matter of many-eyes. It is a matter of 'some other guy is in
> charge of maintaining that component.' It means I can focus on stuff
> that matters, and not focus on 'wrappers to make random things work.'

That can apply to sudo, would be more secure and cause less problems
and you see why I brought it up and asked why not, because that should
be the case.

> Is the polkit maintain any less 'trustworthy' than the gnome
> maintainers? the kde maintainers? the kernel maintainers? At the end
> of the day my machines are running software from thousands of
> contributors.
>

I think that has been demonstrated and we are talking about root code
and sudo is never running as such.

> >
> >> My package manager can have a polkit action like 'install a
> >> signed package' and I can grant the user access to do that, but not
> >> access to install unsigned packages (root exploit there...) or run
> >> other dangerous apt commands. It comes built into apt, so I don't have
> >> to write extra wrappers.
> >
> > That would be the default and wouldn't even need the command line
> > argument control of sudo. Just allowing updates is apt-get update.
> 
> Er, apt-get update downloads new Packages files, it doesn't install
> any additional software. apt-get *upgrade* will. These are separate
> *actions*.
> 

/usr/bin/sudo /usr/bin/aptitude
/usr/bin/sudo -t experimental install iceweasel

You could even make synaptic use a _synaptic group just to install.

> >
> > In fact I have a debian system where experimental iceweasel is
> > installable but nothing else. I have an Arch system where the only
> > kernel updateable is a signed by me when offline kernel and polkit is
> > disabled as I don't have the time to keep track of what it is
> > permitting and code comments weren't helpful there.
> 
> Look if you don't trust polkit, or you dislike it, or you just don't
> have time to understand how it works; that is cool. 18 months ago I
> was in the same camp. Polkit is not strictly required. But don't go
> spouting about how much it sucks unless you have actually *used* it.
> 

I do understand and I asked on the kde lists how to get kde 4.9 to
switch back to using kdesudo by default. NOONE replied except a
gentoo user called Duncan who was interested in the answer
himself and was very helpful and told me how to remove rather than
disable polkit if I don't mind compiling obviously. I worry more
problems will be brought to bear and a lot of development done that
could have been spent better.


> In some cases (like most places where multiple users are present) it
> is in fact terrible. We wanted to do some 'unique' things with
> mounting of USB hardware with polkit (and udisks) and found it
> basically impossible to make work over ssh. I ended up going with the
> 'sudo make me a sandwich' route. Sometimes that is necessary.
> 

Same here but not over ssh, though some of the functionality has since
been put back.

We have digressed from the point though, unless there is a real need
for polkit that I have missed?

I've read Polkit's predecessor was abandoned because it was a bad
development and yet has been basically renamed to get away from the
flak.

Is it just misunderstanding of what sudo has to offer that drives
polkit, that seems rife wherever polkit and sudo are mentioned in
lists, often to the point of confusing sudo with su.

It may become a real shame in history that many threads seem to believe
sudo makes systems less secure when in fact it is polkit.

So does anyone know for sure why sudoers with rules in aside from allow
all were dropped and if that was a bad decision? I imagine users are
better at avoiding sudo pitfalls these days and so maybe it should be
brought back?

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Alec Warner]

On Wed, Jan 16, 2013 at 12:34 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
>> >
>> > I never meant it is rubbish as such but I saw it as rediculously
>> > inferior to sudo before I even read this.
>> >
>> > http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/
>>
>> Perhaps I'm misunderstanding, but that is talking about a specific set
>> of problems that I don't think polkit was actually designed to
>> address. Polkit is basically for authenticating applications via
>> users, not the applications themselves. If I am running app foo, and
>> app foo wants to inhibit hibernation; polkit is there to ask 'hey is
>> antarus allowed to inhibit hibernation? Does antarus need to auth to
>> do so? Is antarus already authenticated? Now one may say 'hey but I
>> only want certain applications to hibernate' and while that may be an
>> interesting problem...I don't think the existing polkit intends to
>> solve it.
>>
>
> The point is that it is inferior in every way and so pointlessly causing
> more work and other problems not to mention guaranteed increased
> security risk having extra code constantly running as root. Why was it
> started, rather than contributing to sudo.

I'm glad you think it is inferior, but i don't really buy your argument.

>
>> >
>> >
>> >> It is however, designed for graphical UI single-seat systems.
>> >> Its command line support sucks (they only added a CLI auth agent in
>> >> May) and it is not well adopted. Multi-user systems do not work well
>> >> with polkit. Certainly with polkit and dbus you can allow users to
>> >> take more specific action without complex wrappers, setuid scripts, or
>> >> sudo.
>> >
>> > Except you can't, it only encourages more coarse grained approaches,
>> > less useful commands available and devs to learn an api rather than C
>> > and simply moves code into a far less secure mechanism and increases the
>> > chance that the code will not be well designed to the task at hand and
>> > running as root. It can be a real pain to work out exactly what polkit
>> > allows and you cannot just edit it to suit your application and it
>> > completely ignores the existing unix security technologies with
>> > brilliant track records.
>>
>> One could say that 'a discrete set of APIs will be no match for
>> the..fined grain control that is the command line!' I would agree. I
>> don't agree that this is a one-size fits all deal though. There can be
>> a command line AND an API. I'd rather grant my users 'access to the
>> install authenticated packages action' than have to own a complex sudo
>> rule.
>>
>
> How about uncommenting a line that does so. All you are buying into is
> a default setup.

App authors don't ship configs like that though. Does apt ship a sudo
config? Does anything?
The nice thing about (really dbus, not so much polkit per se) is that
I can offer a nice API for applications that is not command line
based. No parsing strings, no 'oh this tool writes to stderr, that one
writes to stdout, I need to ignore these lines...)

>
>> I don't understand 'the APIs that coders will learn instead of C.' Can
>> you elaborate? Polkit has a C api...
>>
>
> It has an api that is simply not needed? Small tools are better.

You prefer the commandline api? (one byte for return values, half of
which are signals)

>
>> I don't understand how the code will 'not be well designed to the
>> application at hand.' I mean ideally the API and the CLI are
>> essentially just wrappers around the same library of functions.
>>
>
> If you search for sites that evaluate polkit you will see that it is
> considered to encourage granting more permissions than necessary rather
> than coding a specific tool.

Hah, because no one uses sudo to grant extraordinarily broad permissions.

>
>> Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
>> you will have to read some manpages. However i don't think the
>> concepts are difficult.
>
> Man pages won't help with polkit and it actually generally ships with no
> configs by default.

In Ubuntu Precise..

/etc/polkit-1/*
This contains machine and site specific configuration. Ubuntu ships a
configuration such that anyone in the 'sudo' group is a 'polkit admin'
and can take most actions by entering their (not roots) password.

/usr/share/polkit-1/actions/*
This directory contains all available actions that polkit might auth.

for example, on ubuntu:
org.debian.apt.policy contains the policies for apt.

<action id="org.debian.apt.install-or-remove-packages">
  <description gettext-domain="aptdaemon">Install or remove
packages</description>
  <message gettext-domain="aptdaemon">To install or remove software,
you need to authenticate</message>
  <defaults>
     <allow_any>auth_admin</allow_any>
     <allow_inactive>auth_admin</allow_inactive>
     <allow_active>auth_admin_keep</allow_active>
  </defaults>
</action>

All of this is explained in man polkit.

>
>> There are plenty of helpers (pkcheck springs
>> to mind) that assist the user in figuring out what is 'allowed'.
>
> I know about pkaction, the problem is that the actions tells you next to
> nothing about what is actually allowed. I haven't time to dig out one
> of the rediculous comments from the source now unfortunately. With
> small tools it's much better all round.

Really? Please enumerate what giving someone access to 'emerge' can do.

>
>>The
>> configuration for polkit is all in /usr/share and /etc. The configs
>> are configurable..again in /etc. This is not something I would term
>> 'challenging.'
>>
>
> Generally there aren't any rules files, the defaults are built in and
> your expected to use a webbrowser, even on a server?!?! You shouldn't
> run lynx never mind X on a server.

The configs are all ASCII on disk...The manpages are availablie..

>
> If some configs are in /usr/share rather than /etc perhaps that explains
> why one tutorial said so and it has no effect on some systems.

The actions are in /usr/share, the machine / site configs are in /etc/polkit-1/

>
>> >
>> > You could try to argue that many eyes will look at a central piece of
>> > code but in fact less implementations will likely mean less eyes and
>> > just assumption that a guy who got JS through as a config language has
>> > everything covered. Granted, unmaintained code running as root may be
>> > higher with sudo but if it needs maintaining, should it be running as
>> > root at all or is it actually simply doing too much.
>>
>> Its not a matter of many-eyes. It is a matter of 'some other guy is in
>> charge of maintaining that component.' It means I can focus on stuff
>> that matters, and not focus on 'wrappers to make random things work.'
>
> That can apply to sudo, would be more secure and cause less problems
> and you see why I brought it up and asked why not, because that should
> be the case.

No one maintains the sudo wrappers though. Someone maintains the
polkit actions. That someone also happens to be the upstream author.

>
>> Is the polkit maintain any less 'trustworthy' than the gnome
>> maintainers? the kde maintainers? the kernel maintainers? At the end
>> of the day my machines are running software from thousands of
>> contributors.
>>
>
> I think that has been demonstrated and we are talking about root code
> and sudo is never running as such.

I don't follow...

>
>> >
>> >> My package manager can have a polkit action like 'install a
>> >> signed package' and I can grant the user access to do that, but not
>> >> access to install unsigned packages (root exploit there...) or run
>> >> other dangerous apt commands. It comes built into apt, so I don't have
>> >> to write extra wrappers.
>> >
>> > That would be the default and wouldn't even need the command line
>> > argument control of sudo. Just allowing updates is apt-get update.
>>
>> Er, apt-get update downloads new Packages files, it doesn't install
>> any additional software. apt-get *upgrade* will. These are separate
>> *actions*.
>>
>
> /usr/bin/sudo /usr/bin/aptitude
> /usr/bin/sudo -t experimental install iceweasel
>
> You could even make synaptic use a _synaptic group just to install.
>
>> >
>> > In fact I have a debian system where experimental iceweasel is
>> > installable but nothing else. I have an Arch system where the only
>> > kernel updateable is a signed by me when offline kernel and polkit is
>> > disabled as I don't have the time to keep track of what it is
>> > permitting and code comments weren't helpful there.
>>
>> Look if you don't trust polkit, or you dislike it, or you just don't
>> have time to understand how it works; that is cool. 18 months ago I
>> was in the same camp. Polkit is not strictly required. But don't go
>> spouting about how much it sucks unless you have actually *used* it.
>>
>
> I do understand and I asked on the kde lists how to get kde 4.9 to
> switch back to using kdesudo by default. NOONE replied except a
> gentoo user called Duncan who was interested in the answer
> himself and was very helpful and told me how to remove rather than
> disable polkit if I don't mind compiling obviously. I worry more
> problems will be brought to bear and a lot of development done that
> could have been spent better.
>
>
>> In some cases (like most places where multiple users are present) it
>> is in fact terrible. We wanted to do some 'unique' things with
>> mounting of USB hardware with polkit (and udisks) and found it
>> basically impossible to make work over ssh. I ended up going with the
>> 'sudo make me a sandwich' route. Sometimes that is necessary.
>>
>
> Same here but not over ssh, though some of the functionality has since
> been put back.
>
> We have digressed from the point though, unless there is a real need
> for polkit that I have missed?
>
> I've read Polkit's predecessor was abandoned because it was a bad
> development and yet has been basically renamed to get away from the
> flak.
>
> Is it just misunderstanding of what sudo has to offer that drives
> polkit, that seems rife wherever polkit and sudo are mentioned in
> lists, often to the point of confusing sudo with su.
>
> It may become a real shame in history that many threads seem to believe
> sudo makes systems less secure when in fact it is polkit.
>
> So does anyone know for sure why sudoers with rules in aside from allow
> all were dropped and if that was a bad decision? I imagine users are
> better at avoiding sudo pitfalls these days and so maybe it should be
> brought back?
>
> --
> _______________________________________________________________________
>
> 'Write programs that do one thing and do it well. Write programs to work
> together. Write programs to handle text streams, because that is a
> universal interface'
>
> (Doug McIlroy)
> _______________________________________________________________________
>

[gentoo-dev] Re: Debian patching KDE to use /etc for configuration

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 12:36 AM, Alec Warner wrote:
> 
> for example, on ubuntu: org.debian.apt.policy contains the policies
> for apt.
> 
> <action id="org.debian.apt.install-or-remove-packages"> 
> <description gettext-domain="aptdaemon">Install or remove 
> packages</description> <message gettext-domain="aptdaemon">To
> install or remove software, you need to authenticate</message> 
> <defaults> <allow_any>auth_admin</allow_any> 
> <allow_inactive>auth_admin</allow_inactive> 
> <allow_active>auth_admin_keep</allow_active> </defaults> </action>
> 
> All of this is explained in man polkit.
> 

Uh..  I thought polkit .policy files are deprecated with the new
polkits, the ones that depend on spidermonkey and use javascript to do
their all their processing?

(haven't looked into it but i remember trying to help someone with it
because their old .policy files were no longer read with new polkit)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4EosACgkQ2ugaI38ACPB4dgD/dofmTb4oOkI8UchAIDy7hB3/
P38qxweJ16nBrbeNzEoA/1H7yx9a/WksvR0aPTpeenkwslPZnB19rlMBSi7LJhZW
=HMO0
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Debian patching KDE to use /etc for configuration

[Maxim Kammerer]

On Thu, Jan 17, 2013 at 5:02 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> Uh..  I thought polkit .policy files are deprecated with the new
> polkits, the ones that depend on spidermonkey and use javascript to do
> their all their processing?

The .ini-style …/polkit-1/localauthority/*/*.pkla files were replaced
with Javascript …/polkit-1/rules.d/*.rules files. The XML
.../polkit-1/actions/*.policy are still relevant. That's how they
roll, I guess — defaults in XML (called “actions”, extension
“.policy”), and local changes in Javascript (called “rules”).

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)

[Kevin Chadwick]

> >
> > How about uncommenting a line that does so. All you are buying into is
> > a default setup.
> 
> App authors don't ship configs like that though. Does apt ship a sudo
> config? Does anything?

Perhaps you missed my opening message on this topic, except it was in
your first reply.

__________________________________________________________________

I remember reading a while back that distros had some blunders in
writing secure sudoers files and so it was emptied. Is that true?

I still ascert that apps adding groups with NOPASSWD sudoers lines
perhaps even commented out by default in all or some cases is far
better than polkit for many reasons. Any counter argument can apply
to sudo too and rather easily.
____________________________________________________________________

> The nice thing about (really dbus, not so much polkit per se) is that
> I can offer a nice API for applications that is not command line
> based. No parsing strings, no 'oh this tool writes to stderr, that one
> writes to stdout, I need to ignore these lines...)
> 

What is wrong with sed and you can simply echo files in some sudoers.d
config. What kind of unix dev cannot handle text strings.

That is one of the problems with it too, especially if polkit becomes
over used and perhaps this is below the belt but it's certainly true
that IPC has caused Android more than enough security issues.

> >
> >> I don't understand 'the APIs that coders will learn instead of C.' Can
> >> you elaborate? Polkit has a C api...
> >>
> >
> > It has an api that is simply not needed? Small tools are better.
> 
> You prefer the commandline api? (one byte for return values, half of
> which are signals)
> 

What's the problem there?. I have already stated some of the very
important benefits.

> >
> >> I don't understand how the code will 'not be well designed to the
> >> application at hand.' I mean ideally the API and the CLI are
> >> essentially just wrappers around the same library of functions.
> >>
> >
> > If you search for sites that evaluate polkit you will see that it is
> > considered to encourage granting more permissions than necessary rather
> > than coding a specific tool.
> 
> Hah, because no one uses sudo to grant extraordinarily broad permissions.
> 

They do, but it encourages them not to and not vice versa and they can
easily customise the default rule to say emerge -moresecurethandefault

Win Win and a couple more Wins in fact

> >
> >> Its unclear how polkit is 'hard'. Now it *is* new, and I will concede
> >> you will have to read some manpages. However i don't think the
> >> concepts are difficult.
> >
> > Man pages won't help with polkit and it actually generally ships with no
> > configs by default.
> 
> In Ubuntu Precise..

You still have to do way more than commenting or editing a file to
restrict the default further, aka it's unlikely to happen.

> 
> All of this is explained in man polkit.
> 

And pkauthority and and .... How will that help when as I have
mentioned a coders comments aren't even sure exactly what the code
permits. 

> >
> > I know about pkaction, the problem is that the actions tells you next to
> > nothing about what is actually allowed. I haven't time to dig out one
> > of the rediculous comments from the source now unfortunately. With
> > small tools it's much better all round.
> 
> Really? Please enumerate what giving someone access to 'emerge' can do.
> 

Exactly, you see man emerge and grepping the source does work perfectly
well there. You could make myemerge pretty quick too.


> 
> No one maintains the sudo wrappers though. Someone maintains the
> polkit actions. That someone also happens to be the upstream author.
> 

That's what I am asking, is there any reason not to as it would be
better? No reason has come up yet?


> >
> >> Is the polkit maintain any less 'trustworthy' than the gnome
> >> maintainers? the kde maintainers? the kernel maintainers? At the end
> >> of the day my machines are running software from thousands of
> >> contributors.
> >>
> >
> > I think that has been demonstrated and we are talking about root code
> > and sudo is never running as such.
> 
> I don't follow...
> 

It is certainly far easier to exploit polkit than sudo with a decent
sudoers of course for multiple reasons.



-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On Mon, Jan 14, 2013 at 06:04:01AM +0000, Steven J. Long wrote:
> On Sat, Jan 12, 2013 William Hubbs wrote:
> > Steven J. Long wrote:
> > > If you're certain that every user with a current simple setup, who
> > > uses the kernel default names, and has such a firewall setup isn't
> > > going to suddenly find their interface name changed when they reboot,
> > > fair play to you. If not, allow the admin to opt-in, rather than force
> > > them to opt-out when something breaks.
> > 
> > The following is taken from the wiki:
> > 
> > You basically have three options: 
> <3 options that all require an admin opt-in to keep their existing
>  config running>
> 
> There you go: the exact wrong way to do it. As Poettering might say:
> "C'mon man, seriously? (whiny voice and pleading looks)"

If you have read this thread at all, you see that when you upgrade to
udev-197, I create a file, /etc/udev/rules.d/80-net-name-slot.rules on
your system.

Now, go and compare that fact to the wiki page and tell me if I'm not
setting you up to be opted out of this by default.

There is a separate issue, which is new installs. I have a bug opened
with the docs team and release engineering to discuss whether we want
the new names for new installs.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

William Hubbs wrote:
> I have a bug opened with the docs team and release engineering
> to discuss whether we want the new names for new installs.

IMO yes we do.

What's that bug - or what is the good way to thumbs up/down?


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

On Tue, Jan 15, 2013 at 01:25:01AM +0100, Peter Stuge wrote:
> William Hubbs wrote:
> > I have a bug opened with the docs team and release engineering
> > to discuss whether we want the new names for new installs.
> 
> IMO yes we do.
> 
> What's that bug - or what is the good way to thumbs up/down?

https://bugs.gentoo.org/show_bug.cgi?id=451950

The focus of this bug really is how to document the new names in the
handbook if they decide to go that way. The problem we will have is we
don't know the names of the interfaces a user will see.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/01/13 09:48 PM, William Hubbs wrote:
> On Tue, Jan 15, 2013 at 01:25:01AM +0100, Peter Stuge wrote:
>> William Hubbs wrote:
>>> I have a bug opened with the docs team and release engineering 
>>> to discuss whether we want the new names for new installs.
>> 
>> IMO yes we do.
>> 
>> What's that bug - or what is the good way to thumbs up/down?
> 
> https://bugs.gentoo.org/show_bug.cgi?id=451950
> 
> The focus of this bug really is how to document the new names in
> the handbook if they decide to go that way. The problem we will
> have is we don't know the names of the interfaces a user will see.
> 

That's easy enough to deal with -- list a code block that says what
command to use to find out the iface names, and show an example of the
output.

For that matter, if udev-197 goes stable it'll be included on the
livecd, right?  So a user's interface on the livecd will already be
set to the new naming scheme.

***OH***, that'll mean the livecd's config (or at least the openrc
oldnet portion) is going to need some work....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1Ww0ACgkQ2ugaI38ACPB/sAEAlr+wzX5X7jEsY2KkbC9hylu7
IAIyoZkbtl0A5Z+68A8BALXbRZyv+PZg1eqmWr0DNXfmdwVidOq0RISOxBt0sK7W
=mTAM
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: call for testers: udev predictable network interface names

[Kevin Chadwick]

>  but
> again it appears that simple cases are being made complex, just to allow
> for someone else's complex cases. Which is faulty logic.

It's a welcome option but an important question seems to be; Why wasn't
this picked up in the dev cycle?.

This reminds me of udisks 8 months ago losing features for
multi-seat costing me time to replace it with udev and scripts which I
still prefer. Is it coincidence that Redhat wanted complex multiseat at
all costs for udisks and Redhat want fast boot at all cost for cloud
services?

p.s. I am very glad of RedHats contributions and respect their position
of giving coders freedom but I just think that if they are able to fund
coders to look after a corner full-time or completely then they need
to manage that corner or atleast have some ground rules to cover any
case of my way or the high way. The kernel wouldn't tolerate this
kind of breakage and I really hope I never see linux userland as
dependent on IPC as minix is or as broken without IPC as windows is
without RPC.

I take the unarguably more secure well setup sudoers and useful small
tools anyone can use or take code from over polkit anyday.

-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________

[gentoo-dev] Re: Re: call for testers: udev predictable network interface names

[Steven J. Long]

 Kevin Chadwick wrote:
> >  but
> > again it appears that simple cases are being made complex, just to allow
> > for someone else's complex cases. Which is faulty logic.
> 
> It's a welcome option but an important question seems to be; Why wasn't
> this picked up in the dev cycle?.
>
That would require consequences when borkage was put out, beyond just releasing
new binaries. Something like having to go and personally reboot and reconfigure
all the hosts that didn't work because of the lack of thinking.
 
> The kernel wouldn't tolerate this kind of breakage

Exactly. Or imagine glibc requiring coders to do even a half of what end-users
and admins have had to go through to get their machines working after Lennart's
pressed enter.

> and I really hope I never see linux userland as
> dependent on IPC as minix is or as broken without IPC as windows is
> without RPC.
> 
> I take the unarguably more secure well setup sudoers and useful small
> tools anyone can use or take code from over polkit anyday.

Yeah, and PAM is a lovely invention. Dominique, who does a lot of the work
on pro-audio overlay, saved me from nubkit thankfully[1]- it even makes things
faster for some reason, which wasn't at all why I went ahead with it. Nothing
like the speedup from losing semantic-craptop, of course.
 
> 'Write programs that do one thing and do it well. Write programs to work
> together. Write programs to handle text streams, because that is a
> universal interface'
> 
> (Doug McIlroy)

 "Do the simplest thing that could possibly work."

 "First make it work. Then make it work right. Then make it faster."

My all time favourite:

 "When in doubt, use brute force." <Thompson>

Regards,
steveL.

[1] *kit free system [lxde kde gnome-2.32]
    http://forums.gentoo.org/viewtopic-p-7171240.html
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2013 04:13 PM, William Hubbs wrote:
> All,
> 
> as you probably know by now, udev-197 has hit the tree.
> 
> This new version implements a new feature called predictable
> network interface names [1], which I have currently turned off for
> live systems, because it will require migration on the part of the
> user.
> 
> When you upgrade to this new version of udev, you will find a file 
> /etc/udev/rules.d/80-net-name-slot.rules on your system. It
> currently has comments explaining what is happening.
> 
> As long as this file is in place, this feature is not activated.
> That is why there is not a news item. If you do nothing, nothing
> changes.
> 
> What I would like to do is find some people who are willing to
> migrate and report any issues they find.
> 
> I would like this to be the default for everyone at some point, so
> I want to document the migration process and find out if there are
> any bugs in tools because they expect the eth* names.
> 
> Thoughts?
> 
> William
> 
> [1] 
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
>
> 
So long as users retain the choice of keeping eth* or wlan*, no
complaints from me. I (and others) came to Gentoo to get away from
systemd, and this smells of a systemd-ism. Will eudev be pursuing this
as well?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQ7kHbAAoJEJUrb08JgYgHJ20H/20G6Pkq+hIB1546UKR/Kti+
VmxaFdi5msWjtor6xzzBaVsaWjdpHHHH1ovCHqL1EeuIDg6JUIpeQ2HiAlj9OqaP
9Kg1xATiTw8TKOiGF4r6J1ysfDgFI/K/5CCsMr1Eea6+8m6EUI+yOR5K5xSXZbkR
9Pti3JIrE6t3EkY1EdWguPOGRiiSshjbessNbIzWe/SM/92aDbylQp0ut4DjXn7F
XZyPQ+mCzU2tNWVq8HYuqg6xoO1izk6huYWc9jjxwGXfdewxPN6ebng7uDRhIQSK
QR5dSLpoLEkrC5aZqmtuz2v5zqxgJWz30uNZl6JG8dCrdAntB9JmYwFTVkpekHY=
=6v04
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Rich Freeman]

On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell <dlcampbell@gmx.com> wrote:
> So long as users retain the choice of keeping eth* or wlan*, no
> complaints from me. I (and others) came to Gentoo to get away from
> systemd, and this smells of a systemd-ism. Will eudev be pursuing this
> as well?

Keep in mind that this is a udev announcement, not a eudev
announcement.  Udev is generally going to follow upstream, so if
avoiding systemd is your main goal in life you probably will want to
stick with eudev, which might or might not adopt this feature.

You might want to take discussion of eudev planned features to its
dedicated list.

Rich

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Daniel Campbell]

On 01/09/2013 10:33 PM, Rich Freeman wrote:
> On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell <dlcampbell@gmx.com> wrote:
>> So long as users retain the choice of keeping eth* or wlan*, no
>> complaints from me. I (and others) came to Gentoo to get away from
>> systemd, and this smells of a systemd-ism. Will eudev be pursuing this
>> as well?
> 
> Keep in mind that this is a udev announcement, not a eudev
> announcement.  Udev is generally going to follow upstream, so if
> avoiding systemd is your main goal in life you probably will want to
> stick with eudev, which might or might not adopt this feature.
> 
> You might want to take discussion of eudev planned features to its
> dedicated list.
> 
> Rich
> 

My apologies. It wasn't my intent to derail the discussion with my
simple yes/no question.

Re: [gentoo-dev] call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

On Wed, Jan 09, 2013 at 11:33:42PM -0500, Rich Freeman wrote:
> On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell <dlcampbell@gmx.com> wrote:
> > So long as users retain the choice of keeping eth* or wlan*, no
> > complaints from me. I (and others) came to Gentoo to get away from
> > systemd, and this smells of a systemd-ism. Will eudev be pursuing this
> > as well?
> 
> Keep in mind that this is a udev announcement, not a eudev
> announcement.  Udev is generally going to follow upstream, so if
> avoiding systemd is your main goal in life you probably will want to
> stick with eudev, which might or might not adopt this feature.
 
For the record, I have no plans of forcing systemd on anyone. I still
maintain OpenRC and plan to continue doing so.

As described on the wiki, it is very simple to turn this feature off
either by adding your own persistent rules in /etc/udev/rules.d or by
overriding the 80-net-slot-name.rules file by putting a file in
/etc/udev/rules.d with that name. So, how is this a "systemd-ism"? a lot
of software has defaults that you can reconfigure.

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: call for testers: udev predictable network interface names

[Nuno J. Silva]

On 2013-01-10, Daniel Campbell wrote:

> On 01/09/2013 04:13 PM, William Hubbs wrote:
>> All,
>> 
>> as you probably know by now, udev-197 has hit the tree.
>> 
>> This new version implements a new feature called predictable
>> network interface names [1], which I have currently turned off for
>> live systems, because it will require migration on the part of the
>> user.
>> 
>> When you upgrade to this new version of udev, you will find a file 
>> /etc/udev/rules.d/80-net-name-slot.rules on your system. It
>> currently has comments explaining what is happening.
>> 
>> As long as this file is in place, this feature is not activated.
>> That is why there is not a news item. If you do nothing, nothing
>> changes.
>> 
>> What I would like to do is find some people who are willing to
>> migrate and report any issues they find.
>> 
>> I would like this to be the default for everyone at some point, so
>> I want to document the migration process and find out if there are
>> any bugs in tools because they expect the eth* names.
>> 
>> Thoughts?
>> 
>> William
>> 
>> [1] 
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
>>
>> 
> So long as users retain the choice of keeping eth* or wlan*, no
> complaints from me. I (and others) came to Gentoo to get away from
> systemd, and this smells of a systemd-ism. Will eudev be pursuing this
> as well?

This sounds like an udev feature, completely unrelated to systemd. It's
a bit hard for me to understand why do you even relate this to systemd,
when udev has done this kind of device name management for *ages*.

I mean, I think udev has been bundled with *persistent* rules for some
months now...

Playing with NIC device names is not something exclusive to udev, it has
always been fun with wireless drivers who roam between eth*, wlan*,
ath*...

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/01/13 11:21 PM, Daniel Campbell wrote:
>> [1] 
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
>
>> 
> 
> So long as users retain the choice of keeping eth* or wlan*, no 
> complaints from me. I (and others) came to Gentoo to get away from 
> systemd, and this smells of a systemd-ism. Will eudev be pursuing
> this as well?
> 

The eudev team hasn't discussed it yet, but it's on the agenda for our
next meeting.  I believe that we will be implementing the
functionality (probably by default) in the eudev software package, but
we will not be enabling this by default in the eudev ebuilds (at
least, not any time soon).

Also of note, though, is that the eudev package (and ebuild) will
still have available (although not by default) the old legacy
persistent-net functionality.  I am planning to update the rules
generator for this to use the same attributes as the new method
though, which should be theoretically more reliable than the old
attributes.

- ---

Finally, something that wasn't mentioned yet -- if a user has / still
uses a 75-persistent-net.rules from old udev's, or any custom
iface-naming rules, then the new 80-net-name-slot.rules will also not
take effect on any of the interfaces that were named in these other rules.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlDuydMACgkQ2ugaI38ACPDaLwD+JCn43am7AkSkz4/7d/IisXAp
U9wm1hD2hqjAe2RjAQUBAKGwBTRAcDDx5od26ip99svgnWu6TQw2DKSICWq8BGQd
=T9fH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

I respect both sides of the discussion, because:

a) I once set up an old P3-700 with 5+1 eth cards in 6 different
networks as (bridging)router and truly benefited from the ability to
change a broken NIC - which happened quite often due scrap-metal
hardware - without ending up with martian packages, dhcp service on
the wrong places. But that was 1 incident in 10 years.

b) I use multi-nic servers, some with onboard and extention NICs

c) I tend to move my setups (esp. my laptop) around between different
hardware (nearly identical thinkpad R61/X61), and I _share_ my
installation with other/new users by cloning my disc (well rsync),
lets call this stageN installation.

d) I abuse an old multiport GBit card as GBit switch in my desktop,
besides an onboard one.

e) Some distro/driver constellations (archlinux?) tend to name their
wireless lan eth*.

This resulted in one decision per setup, whether or not to set
/etc/conf.d/udev's

> persistent_net_disable="yes" persistent_cd_disable="yes"

Either to avoid random names due hardware replacement (a) or changed
module loading order (b, inside debian initrd)
or to just use kernel names (eth0, wlan0) because no other cards
present (c) or the NIC drivers compiled into the kernel (d).
e) never happened to me.

It always bugged me to fix/reboot systems which needlessly end up with
eth1/wlan1 because some stupid pre-persistent_net_disable did not
recognize beeing run on an entirely different hardware.

So can we just watch out for the disable="yes" setting and migrate it
during udev's pkg_install phases __and__ post an big fat warning
(elog, news item) on the wall?

I assume most linux users do not operate
servers/multi-nic/multi-networking setups, do not clone their setups
to other hardware.
Given that, these user will almost only see the 'my nics changed names
and i cannot connect to the internet' errors due some moronic or
unavoidable change in initrd/module loading.
That might be the driving force behind udev persistence in the first
place.

I'd be glad if I we respect setups w/ custom-built kernels, w/o
initrds, roots capable of choosing network-name-persistence iff
needed, users adoring the possibility of just dd(1)'ing installations
to new hardware without reinstalling or entering an new product code.

rant=1; And I'd like to avoid dozends of conversations like "Yeah,
your setup/firewall/rouing/... command no longer works, eth0 is no
enp0xx2_at_home_lid_open or was it _bluetooth_turned_off. Didn't you
read the post on some derps mailing list." with haunted people not
knowing better than asking me about their problems.
Not to mention all online documentation/forum posts referring to eth0.
rant=0;

Keep up the good work!

   Michael

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlD1FmAACgkQknrdDGLu8JA68wD/Vuw8mL7O0T398QR7OetqDoLN
pQ7kJz9nveemDxw7o9MBAJSsyQ/DWIKLsqudXjlXhTPQEd0Od6vDBEL6IeFtXCjc
=AfSI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/01/13 03:42 AM, Michael Weber wrote:
> 
> e) Some distro/driver constellations (archlinux?) tend to name
> their wireless lan eth*. [...] e) never happened to me.

It has for me, but not for a *LONG* time -- iirc it was prior to
2.6.16 and I think it was with an (externally compiled) ipw2100
driver.  Neither of which are supported now in general, and certainly
not with a current udev.

I think (e) has been sorted out long ago in the kernel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1YbYACgkQ2ugaI38ACPC1vQEArVONIEOlLPrvd4PV7NnXszOg
AOTxveWpT5drCAV681sA/1WuQwKaqnvfoZReEedNk6Uthedp8dSSIVyvsYaEj0Ud
=0Hnr
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

"This can have serious security implications" [1]

For whom?
The often cited end user not running any network service, not even sshd?
Without firewalls, routing or dhcp_d_?
Some avahi-discovery woodoo stuff unaware of network topology at all?

Maybe the M$/Windows mechanism asking the user to classify an newly
discovered network as (and shutting down network communication until
done so) isn't the worst solution at all.
(Well, that would need an dbus like service to pop up this box *hihi*)

[Generally speaking]

Linux developed from an highly specialized group of users to an broad
spectrum from "I have control, leave my unique setup alone" to "I have
no idea what I'm doing/I'm unwilling to read/Lets sudo random search
results" kinda users. Not all are enlightened.

Good part is the media coverage, money invested/wasted/...
Hard part is to find an compromise for all users.

So lets provide something that works w/o interaction or master
knowledge and not annoys the crap out of users - for all users.

[about NIC names]

Changing the netdev names way from eth*/wlan*/wwan*/ results in a hell
of obsolete documentation.
Opt-out urges users into either adapt their setups or disable the rules.
This LAN/WLAN eth0/eth1 mess could be fixed by assuring Wi-Fi NICs
being called wlan*, and running WPA stuff just there.

The upcoming UMTS/broadband interfaces are called wwan*? *duck*

Last point - as long as identification of LAN networks isn't handled
properly, the consistency of NIC names it the lesser security concern
for users carring around their laptops.

Enough!

   Michael

[1]
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

On 01/09/2013 11:13 PM, William Hubbs wrote:
> All,
> 
> as you probably know by now, udev-197 has hit the tree.
> 
> This new version implements a new feature called predictable
> network interface names [1], which I have currently turned off for
> live systems, because it will require migration on the part of the
> user.
> 
> When you upgrade to this new version of udev, you will find a file 
> /etc/udev/rules.d/80-net-name-slot.rules on your system. It
> currently has comments explaining what is happening.
> 
> As long as this file is in place, this feature is not activated.
> That is why there is not a news item. If you do nothing, nothing
> changes.
> 
> What I would like to do is find some people who are willing to
> migrate and report any issues they find.
> 
> I would like this to be the default for everyone at some point, so
> I want to document the migration process and find out if there are
> any bugs in tools because they expect the eth* names.
> 
> Thoughts?
> 
> William
> 
> [1] 
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
>
> 
- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlD1HmkACgkQknrdDGLu8JDLRQD+P0pO8z0WHnELVYOgQrEQi0wm
Xp1kG1pQhYTCN271T6EBAJvRSacaBE7hdIaTCRH7VUoeugWdktQaXE935kqhFCNV
=BWkO
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/01/13 04:16 AM, Michael Weber wrote:
> Hi,
> 
> "This can have serious security implications" [1]
> 
> For whom?

I think the idea there is that a user expects eth0 and eth1 to stay
the same, writes iptables rules on a per-interface basis to control
what they want, then update the kernel or make some other change
(upgraded udev, maybe? :D) which swaps them around and poof, the rules
they thought were correct don't end up protecting them they way they
assumed it would...

Not saying this is necessarily valid, just saying how I interpreted
their meaning of "serious security implications".



> [about NIC names] ... Opt-out urges users into either adapt their
> setups or disable the rules.

Unless i'm mistaken (and i haven't done any sort of comprehensive
search so I could be), I believe the majority of package rollouts for
systemd-udev is going to provide an opt-in rather than an opt-out.  I
understand the general point here, that systemd-udev upstream perhaps
should also be defaulting to an opt-in, but there isn't a whole lot of
benefit in making that point on the gentoo ML.. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD1YKMACgkQ2ugaI38ACPA8OgEAtK1Y3vHB3oBQyAdmZHYFZcBW
4g9ry2YFts41Zu1wuXcA/REe9lunWnLQ9w4uZNxvFnZ0LqEK9lMrOP0pJEr3UHAq
=06X2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Greg KH]

On Tue, Jan 15, 2013 at 08:58:59AM -0500, Ian Stakenvicius wrote:
> On 15/01/13 04:16 AM, Michael Weber wrote:
> > Hi,
> > 
> > "This can have serious security implications" [1]
> > 
> > For whom?
> 
> I think the idea there is that a user expects eth0 and eth1 to stay
> the same, writes iptables rules on a per-interface basis to control
> what they want, then update the kernel or make some other change
> (upgraded udev, maybe? :D) which swaps them around and poof, the rules
> they thought were correct don't end up protecting them they way they
> assumed it would...
> 
> Not saying this is necessarily valid, just saying how I interpreted
> their meaning of "serious security implications".

Yes, that is true.

And it's not udev that could rename the interface (hint, it wouldn't),
it's the kernel, it _never_ guarantees the same interface "name" every
time you boot.  You might just be getting lucky, but really, PCI busses
can be enumerated in different ways, USB devices can come and go and
initialize sometimes slower one boot from another, and lots of other
things can happen.

So anyone who relies on network names right now to be deterministic, and
you have more than one network device in your system, should seriously
reconsider how they are naming their devices, as it will not work if you
only rely on the kernel.

You might have gotten "lucky" for the past 5 years, but you never know
what could happen if you reboot today.  Seriously, I've seen it happen
all the time.

Hope this helps explain things a bit better.

greg k-h

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Rich Freeman]

On Tue, Jan 15, 2013 at 1:58 PM, Greg KH <gregkh@gentoo.org> wrote:
> And it's not udev that could rename the interface (hint, it wouldn't),
> it's the kernel, it _never_ guarantees the same interface "name" every
> time you boot.  You might just be getting lucky, but really, PCI busses
> can be enumerated in different ways, USB devices can come and go and
> initialize sometimes slower one boot from another, and lots of other
> things can happen.

Not that anybody is taking requests, but it would be really handy if
serial ports were deterministically labeled.

I ended up having to hack my udev rules to hard-code a symlink a USB
serial device to a specific hardware USB port.  It has broken once or
twice over the years, but has otherwise been reliable.  Otherwise, if
you have more than one USB serial interface there is no way to know
which one will end up with what minor number, which is a bummer if
they aren't hooked up to the same thing.

Rich

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Peter Stuge]

Rich Freeman wrote:
> Not that anybody is taking requests, but it would be really handy
> if serial ports were deterministically labeled.

Does /dev/serial/* solve the problem?


//Peter

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Rich Freeman]

On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge <peter@stuge.se> wrote:
> Rich Freeman wrote:
>> Not that anybody is taking requests, but it would be really handy
>> if serial ports were deterministically labeled.
>
> Does /dev/serial/* solve the problem?

I don't see this directory at all on my system.

Rich

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Greg KH]

On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
> On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge <peter@stuge.se> wrote:
> > Rich Freeman wrote:
> >> Not that anybody is taking requests, but it would be really handy
> >> if serial ports were deterministically labeled.
> >
> > Does /dev/serial/* solve the problem?
> 
> I don't see this directory at all on my system.

Do you have a usb-serial device plugged in?  You need a serial device
for it to show up, and you need to be using udev.

greg k-h

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Rich Freeman]

On Wed, Jan 16, 2013 at 9:49 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
>> On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge <peter@stuge.se> wrote:
>> > Rich Freeman wrote:
>> >> Not that anybody is taking requests, but it would be really handy
>> >> if serial ports were deterministically labeled.
>> >
>> > Does /dev/serial/* solve the problem?
>>
>> I don't see this directory at all on my system.
>
> Do you have a usb-serial device plugged in?  You need a serial device
> for it to show up, and you need to be using udev.

Yes, I have two plugged in and they're working fine.  However, perhaps
my custom rules are preventing them from showing up:
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca2"

I'm not sure if rules are additive - if these symlinks would show up
in addition to whatever other ones are created by other rules, or if
these would be exclusive.  I hard-coded them to specific physical USB
ports so that they would be persistent.  If I plug them in elsewhere
they still get ttyUSBn devices, but no symlinks.

Rich

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/13 09:55 PM, Rich Freeman wrote:
> SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0", 
> KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
> 
> I'm not sure if rules are additive - if these symlinks would show
> up in addition to whatever other ones are created by other
> rules...
> 

I should look this up before making an authoritative response but I
believe that  SYMLINK= would mean no, it's not additive.  If you
changed that to SYMLINK+= then it would be additive.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4D98ACgkQ2ugaI38ACPBvJQD/dFlhO8q9voNAMedF1TBIyEK8
/IXoXUjuWMxwaBrDlSwA/i8wB6BfkWyVopPDboikcl1K37hFrEhE3npaLbIhrtbX
=HA4k
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Rich Freeman]

On Thu, Jan 17, 2013 at 9:51 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> On 16/01/13 09:55 PM, Rich Freeman wrote:
>> SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
>> KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
>>
>> I'm not sure if rules are additive - if these symlinks would show
>> up in addition to whatever other ones are created by other
>> rules...
>>
>
> I should look this up before making an authoritative response but I
> believe that  SYMLINK= would mean no, it's not additive.  If you
> changed that to SYMLINK+= then it would be additive.

That worked.

Looks like /dev/serial/by-path would accomplish what I ended up doing.
 The by-id directory only lists one of my two serial devices.  I
suspect this is because the devices are completely identical, aside
from being plugged into two different ports.

Rich

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Samuli Suominen]

On 17/01/13 04:49, Greg KH wrote:
> On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
>> On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge <peter@stuge.se> wrote:
>>> Rich Freeman wrote:
>>>> Not that anybody is taking requests, but it would be really handy
>>>> if serial ports were deterministically labeled.
>>>
>>> Does /dev/serial/* solve the problem?
>>
>> I don't see this directory at all on my system.
>
> Do you have a usb-serial device plugged in?  You need a serial device
> for it to show up, and you need to be using udev.
>
> greg k-h
>

Right, I have 3G Huawei USB modem attached and I see:

$ ls /dev/serial/*
/dev/serial/by-id:
usb-Huawei_Technologies_HUAWEI_Mobile-if00-port0
usb-Huawei_Technologies_HUAWEI_Mobile-if03-port0
usb-Huawei_Technologies_HUAWEI_Mobile-if04-port0

/dev/serial/by-path:
pci-0000:00:1d.0-usb-0:1.2:1.0-port0  pci-0000:00:1d.0-usb-0:1.2:1.4-port0
pci-0000:00:1d.0-usb-0:1.2:1.3-port0

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Tobias Klausmann]

Hi! 

On Tue, 15 Jan 2013, Greg KH wrote:
> So anyone who relies on network names right now to be deterministic, and
> you have more than one network device in your system, should seriously
> reconsider how they are naming their devices, as it will not work if you
> only rely on the kernel.
> 
> You might have gotten "lucky" for the past 5 years, but you never know
> what could happen if you reboot today.  Seriously, I've seen it happen
> all the time.

It has been rather nifty that if I walk up to a random machine
with exactly one NIC (that I've been asked to examine/fix), I
_know_ that there will be eth0 and only that.

OTOH, maybe it's a good idea to make admins do "ip link sh" and
"ip addr sh" every time they examine a new computer -- it goes a
long way to root out wrong assumptions in that field.

Regards,
Tobias

PS: Do not use ifconfig. Ever. Except if there's no iproute. And
then you should only use ifconfig to enable downloading of
iproute :)

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Mike Gilbert]

On Wed, Jan 16, 2013 at 10:19 AM, Tobias Klausmann <klausman@gentoo.org> wrote:
> Hi!
>
> On Tue, 15 Jan 2013, Greg KH wrote:
>> So anyone who relies on network names right now to be deterministic, and
>> you have more than one network device in your system, should seriously
>> reconsider how they are naming their devices, as it will not work if you
>> only rely on the kernel.
>>
>> You might have gotten "lucky" for the past 5 years, but you never know
>> what could happen if you reboot today.  Seriously, I've seen it happen
>> all the time.
>
> It has been rather nifty that if I walk up to a random machine
> with exactly one NIC (that I've been asked to examine/fix), I
> _know_ that there will be eth0 and only that.
>
> OTOH, maybe it's a good idea to make admins do "ip link sh" and
> "ip addr sh" every time they examine a new computer -- it goes a
> long way to root out wrong assumptions in that field.
>
> Regards,
> Tobias
>
> PS: Do not use ifconfig. Ever. Except if there's no iproute. And
> then you should only use ifconfig to enable downloading of
> iproute :)
>

I would actually like to see iproute2 added to the system set.

Re: [gentoo-dev] call for testers: udev predictable network interface names

[vivo75]

Il 16/01/2013 17:25, Mike Gilbert ha scritto:
> On Wed, Jan 16, 2013 at 10:19 AM, Tobias Klausmann <klausman@gentoo.org> wrote:
>> Hi!
>>
>> On Tue, 15 Jan 2013, Greg KH wrote:
>>> So anyone who relies on network names right now to be deterministic, and
>>> you have more than one network device in your system, should seriously
>>> reconsider how they are naming their devices, as it will not work if you
>>> only rely on the kernel.
>>>
>>> You might have gotten "lucky" for the past 5 years, but you never know
>>> what could happen if you reboot today.  Seriously, I've seen it happen
>>> all the time.
>> It has been rather nifty that if I walk up to a random machine
>> with exactly one NIC (that I've been asked to examine/fix), I
>> _know_ that there will be eth0 and only that.
>>
>> OTOH, maybe it's a good idea to make admins do "ip link sh" and
>> "ip addr sh" every time they examine a new computer -- it goes a
>> long way to root out wrong assumptions in that field.
>>
>> Regards,
>> Tobias
>>
>> PS: Do not use ifconfig. Ever. Except if there's no iproute. And
>> then you should only use ifconfig to enable downloading of
>> iproute :)
>>
> I would actually like to see iproute2 added to the system set.
>
additionally (or indipendently) I would like to see it in bin instead of 
sbin

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Michael Weber]

On 01/16/2013 05:25 PM, Mike Gilbert wrote:
>> It has been rather nifty that if I walk up to a random machine
>> with exactly one NIC (that I've been asked to examine/fix), I
>> _know_ that there will be eth0 and only that.
++

> I would actually like to see iproute2 added to the system set.
++

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Peter Stuge]

Tobias Klausmann wrote:
> It has been rather nifty that if I walk up to a random machine
> with exactly one NIC (that I've been asked to examine/fix), I
> _know_ that there will be eth0 and only that.

Only as long as that system hasn't seen *another* NIC first, if it
has persistent interface name udev rules.


//Peter

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Tobias Klausmann]

Hi! 

On Thu, 17 Jan 2013, Peter Stuge wrote:
> Tobias Klausmann wrote:
> > It has been rather nifty that if I walk up to a random machine
> > with exactly one NIC (that I've been asked to examine/fix), I
> > _know_ that there will be eth0 and only that.
> 
> Only as long as that system hasn't seen *another* NIC first, if it
> has persistent interface name udev rules.

I was talking about strictly kernel order vs. predictable-net.
Persistent-net has VM-related downsides as pointed out in the
udev page about the whole thing.

Regards,
Tobias

Re: [gentoo-dev] call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

On Thu, Jan 17, 2013 at 07:44:39PM +0100, Tobias Klausmann wrote:
> Hi! 
> 
> On Thu, 17 Jan 2013, Peter Stuge wrote:
> > Tobias Klausmann wrote:
> > > It has been rather nifty that if I walk up to a random machine
> > > with exactly one NIC (that I've been asked to examine/fix), I
> > > _know_ that there will be eth0 and only that.
> > 
> > Only as long as that system hasn't seen *another* NIC first, if it
> > has persistent interface name udev rules.
> 
> I was talking about strictly kernel order vs. predictable-net.
> Persistent-net has VM-related downsides as pointed out in the
> udev page about the whole thing.

The problem is the kernel names are not dependable.

If you have one network card right now, sure, it will be eth0.
But, suppose you buy another network card and plug it into the system.
Now you have no way to know that eth0 will refer to the card you think
it does.

With the predictable names, on my system for example, I know that enp1s5
will always refer to the same nic, even if I put a new one in the box.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] call for testers: udev predictable network interface names

[vivo75]

Il 09/01/2013 23:13, William Hubbs ha scritto:
> All,
>
> as you probably know by now, udev-197 has hit the tree.
>
> This new version implements a new feature called predictable network
> interface names [1], which I have currently turned off for live systems, because it
> will require migration on the part of the user.
>
> When you upgrade to this new version of udev, you will find a file
> /etc/udev/rules.d/80-net-name-slot.rules on your system. It currently
> has comments explaining what is happening.
>
> As long as this file is in place, this feature is not activated. That is
> why there is not a news item. If you do nothing, nothing changes.
>
> What I would like to do is find some people who are willing to migrate
> and report any issues they find.
>
> I would like this to be the default for everyone at some point, so I
> want to document the migration process and find out if there are any
> bugs in tools because they expect the eth* names.
>
> Thoughts?
>
> William
>
> [1]
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Since for servers predictable names are useful and for desktop (which 
usually have only one ethernet that never change)
Is it possible to set desktop profiles to still use ethX, and base 
profile to use new naming scheme?

For wireless situation may be different, many of them are external, 
could wireless be managed differently?

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/01/13 07:24 AM, vivo75@gmail.com wrote:
> Since for servers predictable names are useful and for desktop
> (which usually have only one ethernet that never change) Is it
> possible to set desktop profiles to still use ethX, and base 
> profile to use new naming scheme?
> 
> For wireless situation may be different, many of them are
> external, could wireless be managed differently?
> 

In short, no.  At least, not unless the functionality that is
currently a configure-time thing is changed into a
build-time/install-time thing controlled via a use flag.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD5TxkACgkQ2ugaI38ACPCQHAD7BEIoXLuskCfv/TllbCDaW94u
84t/PufZ03LJLjqzWlAA/Azuvil7oLWAzTxSDuHT+oheJsPvf4tBFmQUojSf+WIj
=FOCB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 18/01/13 07:24 AM, vivo75@gmail.com wrote:
> > Since for servers predictable names are useful and for desktop
> > (which usually have only one ethernet that never change) Is it
> > possible to set desktop profiles to still use ethX, and base 
> > profile to use new naming scheme?
> > 
> > For wireless situation may be different, many of them are
> > external, could wireless be managed differently?
> > 
> 
> In short, no.  At least, not unless the functionality that is
> currently a configure-time thing is changed into a
> build-time/install-time thing controlled via a use flag.

Actually,this is how I set you up by dropping the file in
/etc/udev/rules.d/80-net-name-slot.rules.

Nothing changes on your system unless you remove this file and do not
have 70-persistent-net.rules.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/01/13 09:54 AM, William Hubbs wrote:
> On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> On 18/01/13 07:24 AM, vivo75@gmail.com wrote:
>>> Since for servers predictable names are useful and for desktop 
>>> (which usually have only one ethernet that never change) Is it 
>>> possible to set desktop profiles to still use ethX, and base 
>>> profile to use new naming scheme?
>>> 
>>> For wireless situation may be different, many of them are 
>>> external, could wireless be managed differently?
>>> 
>> 
>> In short, no.  At least, not unless the functionality that is 
>> currently a configure-time thing is changed into a 
>> build-time/install-time thing controlled via a use flag.
> 
> Actually,this is how I set you up by dropping the file in 
> /etc/udev/rules.d/80-net-name-slot.rules.
> 
> Nothing changes on your system unless you remove this file and do
> not have 70-persistent-net.rules.
> 
> William
> 

..right, but default behaviour can't be changed automatically
depending on what profile you're on, as vivo requested, since profiles
don't control configuration (just use flags)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD5ZT4ACgkQ2ugaI38ACPCECQD6A78Wgm30Tx0RIfgblZhAu4d2
/2NFMtZng4JQlgmbCc8BAJZgPOgH3fxhSl+pRBpWFkZu/v5kwqxs+h+9ooBJZ5nG
=MhsO
-----END PGP SIGNATURE-----

Re: [gentoo-dev] call for testers: udev predictable network interface names

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

On Fri, Jan 18, 2013 at 10:07:42AM -0500, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 18/01/13 09:54 AM, William Hubbs wrote:
> > On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >> 
> >> On 18/01/13 07:24 AM, vivo75@gmail.com wrote:
> >>> Since for servers predictable names are useful and for desktop 
> >>> (which usually have only one ethernet that never change) Is it 
> >>> possible to set desktop profiles to still use ethX, and base 
> >>> profile to use new naming scheme?
> >>> 
> >>> For wireless situation may be different, many of them are 
> >>> external, could wireless be managed differently?
> >>> 
> >> 
> >> In short, no.  At least, not unless the functionality that is 
> >> currently a configure-time thing is changed into a 
> >> build-time/install-time thing controlled via a use flag.
> > 
> > Actually,this is how I set you up by dropping the file in 
> > /etc/udev/rules.d/80-net-name-slot.rules.
> > 
> > Nothing changes on your system unless you remove this file and do
> > not have 70-persistent-net.rules.
> > 
> > William
> > 
> 
> ..right, but default behaviour can't be changed automatically
> depending on what profile you're on, as vivo requested, since profiles
> don't control configuration (just use flags)

Right, and we have a policy against using use flags to control the
installation of configuration files.

vivo, what is your concern here exactly?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

2013/1/19 William Hubbs <williamh@gentoo.org>

> On Fri, Jan 18, 2013 at 10:07:42AM -0500, Ian Stakenvicius wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On 18/01/13 09:54 AM, William Hubbs wrote:
> > > On Fri, Jan 18, 2013 at 08:33:13AM -0500, Ian Stakenvicius wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> > >>
> > >> On 18/01/13 07:24 AM, vivo75@gmail.com wrote:
> > >>> Since for servers predictable names are useful and for desktop
> > >>> (which usually have only one ethernet that never change) Is it
> > >>> possible to set desktop profiles to still use ethX, and base
> > >>> profile to use new naming scheme?
> > >>>
> > >>> For wireless situation may be different, many of them are
> > >>> external, could wireless be managed differently?
> > >>>
> > >>
> > >> In short, no.  At least, not unless the functionality that is
> > >> currently a configure-time thing is changed into a
> > >> build-time/install-time thing controlled via a use flag.
> > >
> > > Actually,this is how I set you up by dropping the file in
> > > /etc/udev/rules.d/80-net-name-slot.rules.
> > >
> > > Nothing changes on your system unless you remove this file and do
> > > not have 70-persistent-net.rules.
> > >
> > > William
> > >
> >
> > ..right, but default behaviour can't be changed automatically
> > depending on what profile you're on, as vivo requested, since profiles
> > don't control configuration (just use flags)
>
> Right, and we have a policy against using use flags to control the
> installation of configuration files.
>
> vivo, what is your concern here exactly?
>
> William
>
> My concern was to make simple desktop users happy while leaving the
servers safe.
The answers given in the previous emails are satisfying, since they cover
exhaustively what is in place and what could be (or not) done.

Thanks,
Francesco

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]