Re: A bridge too far ...

[Simos Xenitellis <simos lists googlemail com>]

Clark Dunson wrote:
> Friendly Gnomers;
>
> Recently we came up against some decisions made by your team that have 
> left us quite irate and disillusoned.  In particular, your choice to 
> go around the design of Unix with regards to hostname/network and 
> other permissions, e.g.:
>
> Users and Groups
> Time and Date
> Shared Folders
> Services
>
> The hostname is usually set by the ‘hostname’ program, but not in the 
> Gnome case.  We cannot set the hostname and recover several of our 
> systems due to your design choice, which by every standard is not 
> Unix-like.
>
> Consider what’s happened.  We cloned a drive and booted it on another 
> machine.  Oops, we forgot to shutdown the original system before we 
> turned on the clone.  Our DHCP server refused to give an IP address to 
> the same hostname twice.  Of course.  That’s called ‘security’. 
>  Result?  The cloned system failed the network.  That’s all good.  On 
> a normal Unix box, we could just use the command ‘hostname newname’ to 
> change the hostname, and then reboot.  But not on a Gnome machine. 
>  The ‘real’ hostname is kept and set by Gnome?!?  Booooooooooo!!!
>
> Gnome (Ubuntu 7.0.4) now blocks us PERMANENTLY from changing the 
> hostname.  And Gnome overrides su/root?!?  Whathehellis this dialog 
> box?!?:
>
> "You are not allowed to access the system configuration"
>
> That is really bogus.  I'm root!!!  Keep doing stuff like this and you 
> might as well just hand the future to Windows Vista.  Now a bunch of 
> our clones, and all of the hours we put into them are DEAD!!!  We have 
> tried every workaround we found on the internet: restart dbus, use 
> alacarte, blah, blah, blah.  None work.  If we shut the original 
> machine down first, boot a clone for the first time, and then change 
> its hostname by hand with your GUI, then reboot, we can save that 
> clone aka, workaround.  But this blocks up our builds and slows us 
> down a lot.  Perhaps you could tell us how to access the hostname 
> within Gnome directly so we could set it as part of the cloning 
> process before booting the first time?  We guess that your security 
> policy will not allow us to find out how to do this, right? 
>
> Our Admin is winning the day with management by saying we should be on 
> Windows Embedded.  The way things are going now, he may win.  Our only 
> out?  Spend the next two weeks re-cloning, hit our delivery schedule, 
> and eat the $$$$ - or scotch Gnome.
>
> The -backend- scripts *.pl are not happy, and you have just unravelled 
> three decades of Unix wisdom.  How dare you create state inside of 
> Gnome that overrides Unix, that not even ‘su’ can fix?!  Man that is 
> weird.  All of us other programmers are forced to deal with 
> permissions, why not you?  The developers of X have lived with the 
> rules despite having a much harder problem to solve.  What are you dong??
>
> Sorry to sound abusive, but I know of no other way to impress upon you 
> how serious this situation is, and what risk you have introduced to 
> the entire Linux community via your design choice.  Until we hear of a 
> work around or a fix, we are proposing to cut all of our machines back 
> to runlevel three.  (If it can even be done in Ubuntu).  We have no 
> other way of knowing what other similar decisions your team has made, 
> and a damn strong customer who is in no mood for this kind of BS.
>
> I’m sure, given my quasi-hostile tone, that you are turned off, but 
> any insight or guidance you could offer would be greatly appreciated.
>
> Thank you ...
I think the problem is with udev (low level package), not GNOME.

Have a look at /etc/udev/rules.d/70-persistent-net.rules
You may want to empty it and restart your system. In this way, you will 
be able to reclaim eth0 as the onboard network adaptor, and so on.

Many people stumble on these enhancements, they struggle to fix, they 
got them fixed and at the end they do not give back to the community.
Make a difference,

Simos