On 12/24/11 00:22, Roland Smith wrote:
On Fri, Dec 23, 2011 at 02:18:19PM +1000, Da Rock wrote:
This is doing my head in.
:-)
I'm trying to get my head around hal, dbus,
and PolicyKit, and I've made some inroads on the basics, but I cannot
get a few things happening.
One: I managed to get network:/// smb shares working in say nautilus
(not that I've specifically mounted one- not a windows in sight here
thank god!), but I was hoping for NFS shares to show up.
Why not just use mount_nfs from your login shell's rc file?
I'm dealing with mobile devices (laptops, etc), ergo I need an automount
solution. I've been using automounter happily for removable devices, but
users are picky and I then can't use amd for nfs and automounter
couldn't give a shit about network drives. One scenario is network goes
down and I get a screenful of error messages- it annoys the shit out of
me, let alone scaring illiterate users.
I did come across one interesting observation in my search for the
truth: its easier to mount a winblows share than an nfs one! On any *nix
no less...
I also got the
usb disk to show up as a 'place' but when I access it I get permissions
issues. This is what I'm hung up on.
I'm not using policykit or hal, but I did make a separate group predictably
called 'usb' to solve permission problems for USB devices. My user-id is a
member of that group. I have to following set in /etc/devfs.rules:
[my_devs=10]
add path 'da*' mode 0660 group usb
add path 'msdosfs/*' mode 0660 group usb
add path 'usb/*' mode 0660 group usb
add path 'ugen*' mode 0660 group usb
add path 'tap*' mode 0660 group wheel
add path 'pass*' mode 0660 group cdrom
add path 'dri/card*' mode 0666
And in /etc/rc.conf I have activated this ruleset:
devfs_system_ruleset="my_devs"
With this I can access the necessary devices.
Already done, but that doesn't help automounting.
I checked out /media/hal-* and I see that the mount occurs only as root.
How do I change that exactly? I need it showing for operator group.
Is hald running under its own user-id? Try the usb group thing and add the hald
user to that group.
Interesting theory, but it doesn't hold water. More further...
I've
searched high and low and googled my brains out, but anything remotely
related is for linux and udev.
I don't think enough people care to make it really work under FreeBSD. I've
certainly never missed it.
They don't care too much under linux either.... So many years, yet not a
single user doc anywhere on any of the f***ing monsters! Goddamn linux
devs- ever heard of KISS?! How about a user doc for something so bloody
confusing it takes a brain surgeon to figure it out?
Ok. The final cut... I did finally get hal/polkit/dbus to cooperate in
the end. But there were more suspects by the end:
%.xsession
#!/bin/sh
exec xhost +localhost &
## test for an existing bus daemon, just to be safe
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
## if not found, launch a new one
eval 'dbus-launch --sh-syntax --exit-with-session'
echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"
fi
exec /usr/local/libexec/polkit-gnome-authentication-agent-1 &
exec xscreensaver &
exec ck-launch-session icewm-session
So... one needs to start a local dbus session, a polkit-auth session,
and a ck-launch-session...
And in PolicyKit.conf (I'm not entirely happy with the security here),
scratch user or group matches and just add the action with result=yes.
Now that will work in a single user situation. There is yet another
culprit here: gconf. GConf was the shooter on the grassy knoll causing
issues with the mount options and permissions.
And the crazy part in all this is there is hardly a scratch of info out
there on such complex software that are supposedly interacting together
in some way that is not exactly documented and yet is in control of the
whole bloody system! We should just all revert to winblows at this rate-
there's more docs there than for this stuff! An absolute embarrassment
to the FOSS community...
Ahh, one more thing of note here: polkit-gnome-authorization would not
work under any circumstances (run as root or otherwise) to change
policies! WTF!
You might take a look at devd(8) as a FreeBSD alternative, but I'm not sure if
it notices new da devices popping up.
Oh, believe me I'd happily jump on it rather than deal with this mess.
But I can't find anything that will interact happily with the apps,
mount network shares of all kinds, and be exceedingly user friendly
(take note lin-devs: user-friendly != sys_admin-hell at least it
_doesn't have to_).
How forgiving is devd to a user pulling the plug to early? I did look
into it a bit, but it appeared nearly as difficult as deciphering the
above scenario- that said, having come through the other side of that
I'm not so sure my judgment was very accurate :) So now I might check
that fork out and see...
God! What a mess... this belongs in the X-files: the truth _is_ out
there. But you might lose your head and many years of life just finding
the fragments!
HTH someone now when the whole lot will change yet again and this will
probably be pointless...
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
