On Thu, 2006-11-09 at 12:21 -0500, Joe Marcus Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Carlos Garnacho wrote: > > Hi! > > > > On Wed, 2006-11-08 at 17:38 -0500, Joe Marcus Clarke wrote: > >> I'm having a pretty difficult time getting the latest > >> system-tools-backends to like FreeBSD. I was hoping I could get a few > >> questions answered. > >> > >> 1. s-t-b tries to find its D-BUS service using the system bus. However, > >> the system bus has no concept of service directories, so this causes > >> Nautilus to fail to launch since the org.freedesktop.SystemToolsBackends > >> service cannot be found. If I add the following to D-BUS's system.conf, > >> I can get over this hurdle: > > > > Ideally, the backends have to be run as root (they need it to change > > system configuration) by a script in /etc/dbus-1/event.d, the service > > file is mostly a fallback to make tools at least show something instead > > of failing miserably :) > > > > Sadly, due to the diversity of init script types out there, I'm not > > including any at the moment, so packages should provide their own. > > Oh, cool. This is the first I've heard of event.d scripts. Do you have > an example for s-t-b I could look at? Hmmm, after reading the DBus initscript, I now realize that it's a distros' artifact to raise or stop services in the system bus (HAL, NetworkManager, s-t-b, ...). It's the DBus initscript the one that goes to that directory and launches the scripts in there... At least, all Linux distributions that ship DBus have it, and IIRC some apps already rely on /etc/dbus-1/event.d/ usage, but running s-t-b during init as root should be just ok. I'm attaching both Ubuntu's DBus initscript and s-t-b event.d file, hope it's a good example :) Regards > > > > >> <standard_session_servicedirs /> > >> > >> Why should I need that? Shouldn't s-t-b be using the session bus like > >> other applications (e.g. gnome-vfs-daemon, gnome-power-manager, etc.)? > >> Note: I am using dbus-0.95. > > > > s-t-b changes affect the whole system, besides that, they very probably > > need to run as a different user than the session bus, and IIRC that's > > something that's not allowed to happen, and besides that, privileges > > scalation would be a complete hack... > > > > Instead, the backends are supposed to be running already as root, using > > DBus policies to block access from untrusted users, only root user and > > users in stb-admin group are allowed to access backends (the admin group > > may be modified using --with-stb-group=foo during configure) > > I'm absolutely making use of this configure argument to allow users in > the wheel group to use s-t-b. I just need to know how to get things > started, and I think a sample event.d script would go a long way. > > > > > In a close future s-t-b will be using PolicyKit, it will allow much more > > fine grained permissions than DBus policies. > > > >> 2. s-t-b fails to run as a daemon > >> (i.e. /usr/local/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl exits with a status of 0). This is caused by the daemon not being able to write its PID file to /var/run. This is understandable as the script is being run by my user, and only root can write to this directory. My question is, who should be running this script? Should I be hacking it to write its PID to a directory that is writable by the stb-admin group? > > > > as explained above, "stb-admin" is used to determine which users can > > access the backends, the backends should run as root however... > > > > Backends failing because they can't write to the pidfile shouldn't be > > happening, though... > > This will go away if s-t-b is started as root. > > > > >> Note: I can also get around this problem by adding --no-daemon to the > >> D-BUS service config. > >> > >> 3. Finally, why does Nautilus try to initialize liboobs when trying to > >> get SMB share information? Where in the code path does that occur? > > > > That's the nautilus extension in shares-admin to show an emblem on > > shared folders, it's in g-s-t/src/shares/nautilus > > Yep, figured this out right after I emailed the list. I didn't think to > look at the g-s-t pkg-plist. > > > > > I'm sorry for the confusions, perhaps it all should be documented > > somewhere... > > No problem. I think the big gotcha would be the event.d script. > > Joe > > - -- > Joe Marcus Clarke > FreeBSD GNOME Team :: gnome FreeBSD org > FreeNode / #freebsd-gnome > http://www.FreeBSD.org/gnome > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFFU2ONb2iPiv4Uz4cRAroFAJ4yn3LPoYvQqRy/A9FM7BUPx+jdRgCgnTUL > ku7jLmzFwnlVUiiA9Crf21U= > =q+jT > -----END PGP SIGNATURE-----
Attachment:
dbus
Description: application/shellscript
Attachment:
70system-tools-backends
Description: application/shellscript