Well, what exact steps I should take to enable a normal user to change the cpufreq and shutdown/reoobt system from the gnome menu?

Thanks

Adding an account to the "power" group allows it to shutdown and reboot via HAL, which should work from the GNOME menu.

I like your italicized "should"....

Adding policykit/console kit was the worst bullsh*t move that Gnome has made to date. (and that's saying something)

Ewww, good question. I don't know how GSB has all of the PolicyKit stuff set up, but as I understand it, it's supposed to "just work" for a user logged in at the physical machine.

In the admittedly limited testing I did in trying to see if a PolicyKit/ConsoleKit-enabled HAL was an option for us (NOTE: It's NOT, at least not yet), I reached the conclusion that duplicating our current setup (authentication via group membership) is not possible. Theoretically, ConsoleKit integration with PolicyKit is supposed to work in such a way that a user logged in locally (along with proper PolicyKit configuration) should have permission to those things, but I was unable to make it work after a couple of days of experimenting, so I quit trying. I may very well have been able to figure it out eventually, but ultimately, I have to consider the fact that supporting it will be *my* job, and I'm not prepared to support something that I (obviously) don't fully understand.

I *was* able to grant permissions per *user* in PolicyKit's configuration, so perhaps that's an option for you, if all else fails.

I would suggest that you inquire about this in GSB support areas, and please forward the resolution here, as I'd like to see where I went wrong.

I tried that before but no effect at all as regards to permission to shutdown or reboot for a a certain user. Also I checked the /etc/PolicyKit/PolicyKit.conf did not take change at all after that.

I googled and added the following lines to /etc/PolicyKit/PolicyKit.conf, but still no luck.



<match action="org.freedesktop.hal.power-management.hibernate">
<return result="yes"/>
</match>
<match action="org.freedesktop.hal.power-management.suspend">
<return result="yes"/>
</match>
<match action="org.freedesktop.hal.power-management.shutdown">
<return result="yes"/>
</match>
<match action="org.freedesktop.hal.power-management.reboot">
<return result="yes"/>
</match>
<match action="org.freedesktop.hal.storage.mount-removable">
<return result="yes"/>
</match>
<match action="org.freedesktop.hal.storage.mount-fixed">
<return result="yes"/>
</match>
<match action="org.freedesktop.hal.storage.eject">
<return result="yes"/>
</match>

If there any way to disable policykit, so that I could shutdown/reboot and change cpufreq from the gnome menu?

Well, after some testing, I modified the /etc/Policykit/Policykit.conf as following, and my problem is partially solved. I am happy to see that gnome cpufreq-selector works now, but still no luck with shutdown/reboot. It seems to be related to the same bug as this https://bugs.launchpad.net/ubuntu/+s...it/+bug/250506

tail -1 syslog
==============
Feb 4 11:59:51 darkstar gnome-session[2837]: WARNING: Unable to stop system: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.ConsoleKit.Manager" member "Stop" error name "(unset)" destination "org.freedesktop.ConsoleKit")


cat /etc/PolicyKit/PolicyKit.conf
=================================

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">

<!--
This is the default PolicyKit.conf file for GNOME SlackBuild. Some default
settings have been configured here as example. Feel free to change them
as suits your needs.

For more information and the file format, please see the manual page
PolicyKit.conf(5) for the file format.

-->

<config version="0.1">

<!-- Users in the group "netdev" are allowed to change the network
settings through NetworkManager -->
<match action="org.freedesktop.network-manager-settings.system.modify">
<define_admin_auth group="netdev"/>
<return result="yes" />
</match>

<match user="root">
<return result="yes"/>
</match>


<match action="org.freedesktop.hal.power-management.hibernate">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.power-management.suspend">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.power-management.shutdown">
<return result="yes"/>
</match>
<match action="org.freedesktop.consolekit.system.stop">
<return result="yes"/>
</match>

<match action="org.freedesktop.consolekit.system.restart">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.power-management.reboot">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.storage.mount-removable">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.storage.mount-fixed">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.storage.eject">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.power-management.cpufreq">
<return result="yes"/>
</match>

<match action="org.gnome.cpufreqselector">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.device-access.camera">
<return result="yes"/>
</match>

<match action="org.freedesktop.hal.device-access.video4linux">
<return result="yes"/>
</match>
</config>

Not unless you downgrade gnome-session, gdm and possibly others to the 2.22.x versions (that are explicitly NOT linked against CK/PK). There are atleast 6-7 packages, if not more, that link against them.

consolekit/policykit is a requisite for 2.24.x. Let me clarify, you can still build all of gnome without them but you'll have many broken things.

I had some of the same issues as rworkman and threw in the towel on my Gnome build. Just an unnecessary layer of complication IMO. I was however able to reboot/shutdown about 90% of the time as a normal user. Couldn't figure out what was happening the other 10% of the time and got pissed off.

Followup:

Instead of gnome-menu, system could be shutdown through gnome-power-manager. Here I configure d gnome-power-manager to shutdown my laptop when I press the laptop physical power button. At least this is an easy workaround for me.

I reported the problem to gsb user group, and here is the solution to shutdown/reboot:

You need to undo patch 01-dbus_policy.patch which GSB applies
to /etc/dbus-1/share/ConsoleKit.conf. By default ConsoleKit will
allow you to shutdown from the desktop but GSB policy appears to be
that you should only do so by going back to the display manager (gdm).
As I say, to change this just unapply the patch.

Check for more details and other valuable comments through this group discuss link:

http://groups.google.com/group/gsb-u...9dd4d22c17ea21

That's one hell of a way to side skirt a bug. Call it intended behavior, look up at the ceiling and walk away whistling.... I really hope that's not GSB's official stance on shutting down or rebooting. I could always reliably shutdown or reboot from gdm but I would never think about forcing people to do it because I was unable to figure out the root of the problem.

Kite, after ditching that patch, anyway you can post back after using it for a week or two and tell us if you have any issues with rebooting via gnome-{menu,session}. As I've said, using the default CK/PK behavior, Every once in awhile, I'd get no response from the shutdown or reboot options in the menu (seemed the longer session I was in, the greater chance I had of it happening, don't know tho). If I recall correctly, after trying to reboot (and it not working), once you "logout" of gnome-session and you got thrown to gdm, your reboot command would take effect.

I forget the particulars now but I saw some really screwy behavior because of these new authentication mechanisms... I could never determine whether it was my ignorance with something new or whether it was flawed upstream.

Glad you've gotten it working, but don't get used to it. PolicyKit is being rewritten.

It's not "opposition to progress" that keeps lots of this sort of thing out of Slackware - it's the difficulty of hitting a moving target. For those who don't recall, HAL was rewritten around 0.4 due to limitations in it; then PolicyKit and friends were written to address limitations in the rewritten HAL; now PolicyKit itself is being rewritten to address limitations in itself, and the intent is for the new PolicyKit and friends to completely replace HAL.

To be honest, I don't know what the future holds for us in this regard, so don't bother asking. :-)