[orca-list] Ubuntu hardyheron alpha4
- From: Hammer Attila <hammera pickup hu>
- To: orca-list gnome org
- Subject: [orca-list] Ubuntu hardyheron alpha4
- Date: Sun, 17 Feb 2008 20:28:33 +0100
I vould like testing Ubuntu hardyheron alpha4 release.
The live cd booting, selected accessibility mode (screen reader when f5
Any administration application is not accessible yet. The /root/.orbitrc
file is not work, Villie suggest private mail.
In ubuntu 7.10, if put the /root/.orbitrc file two lines with
orca/sysadmin suggestions, the installation is work and speech fine, and
later administration is work except the first administration task start.
(my bugreport is filled).
In hardyheron alpha4, this solution is not work.
Another installation steps (e.g. feyst installation writed orca
homepage) not work my computer.
I generated new live cd, enabled the root login with gdm with
gdm.conf-custom (added root password ubuntu), enabled the accessibility
support with root.
If i logged root, every administration applications work perfectly, and
speech the ubiquity installation.
But this is not good idea.
Hav any people with install Hardyheron alpha4 with accessible with Orca?
In tomorrow, trying install hardy my prepared live cd, and trying the
It's very interesting, why not work the .orbitrc file the new system.
Not problem the new Policy kit feature?
Copying the short description this feature:
With Alpha 4, PolicyKit integration is visible in the administrative
user interfaces. PolicyKit makes it possible to run administrative
a normal user, and have them get a particular set of extra privileges
for certain operations, which allows fine-grained control over user
enhances usability, as well as eliminating the security implications of
running the whole application as root. "
And this is the letter of ubuntu devel list archive:
in Hardy we now use PolicyKit instead of gksu/sudo for authenticating
various sysadmin tasks, such as the GNOME system tools (users-admin,
network-admin), and mounting internal hard drives. The move to PK has
been described and justified in the spec .
The remaining unimplemented point is the "Migration" section of this
spec, which basically revolves around the question "What is the
definition of an admin?" Should it be "Everyone who is in the admin
group" or "Everyone who can execute arbitrary commands through sudo"?
The former case is implemented in PK right now. Implementing the
latter is very hard, since sudo does not easily give away any
information about who can do what, for good reasons.
Do you think that defining the group as authoritative is reasonable?
If not, then we need to engineer a pretty PK specific solution into
sudo itself, such as an option to "give me a list of all users who can
run arbitrary commands as root", which can only be called as user
"polkituser" (or root). Parsing /etc/sudoers is out of the question,
since it can get arbitrarily nested and complicated. Once we have
that, PK needs to get another authentication method, but that's
relatively easy then."
Have you any idea this unaccessible problem?
Or what your openion?
] [Thread Prev