Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
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: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
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
Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
On Wed, Jan 16, 2013 at 12:34 PM, Kevin Chadwick ma1l1i...@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=aptdaemonInstall or remove packages/description message gettext-domain=aptdaemonTo install or remove software, you need to authenticate/message defaults allow_anyauth_admin/allow_any allow_inactiveauth_admin/allow_inactive allow_activeauth_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
Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
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)
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)
On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick ma1l1i...@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: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
-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: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
On Tue, Jan 15, 2013 at 3:00 AM, Rich Freeman ri...@gentoo.org wrote: On Tue, Jan 15, 2013 at 5:25 AM, Kevin Chadwick ma1l1i...@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)
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)
On Tue, Jan 15, 2013 at 9:43 PM, Kevin Chadwick ma1l1i...@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)
On Tue, 15 Jan 2013 22:19:37 +0200 Maxim Kammerer m...@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: anonliberte = 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)
On Tue, Jan 15, 2013 at 11:43 AM, Kevin Chadwick ma1l1i...@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
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
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
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) ___
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
On Mon, Jan 14, 2013 at 06:04:01AM +, 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 pgpvRLLiLgugN.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
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 pgpswXbIiseJI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
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 pgpOr7kUoyxc4.pgp Description: PGP signature
[gentoo-dev] Re: Re: call for testers: udev predictable network interface names
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.
[gentoo-dev] Re: Re: call for testers: udev predictable network interface names
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 ;-)
