system-tools-backends 2.17

[marcus-11]

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:

<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.

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?

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?

Thanks.

Joe

--
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome@...
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome


_______________________________________________
system-tools-list mailing list
system-tools-list@...
http://mail.gnome.org/mailman/listinfo/system-tools-list

[Carlos Garnacho]

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.

>
> <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)

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...

>
> 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

I'm sorry for the confusions, perhaps it all should be documented
somewhere...

       Regards

>
> Thanks.
>
> Joe
>
> _______________________________________________
> system-tools-list mailing list
> system-tools-list@...
> http://mail.gnome.org/mailman/listinfo/system-tools-list
_______________________________________________
system-tools-list mailing list
system-tools-list@...
http://mail.gnome.org/mailman/listinfo/system-tools-list

[marcus-11]

-----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?

>
>> <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@...
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-----
_______________________________________________
system-tools-list mailing list
system-tools-list@...
http://mail.gnome.org/mailman/listinfo/system-tools-list

[Carlos Garnacho]

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@...
> 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-----

_______________________________________________
system-tools-list mailing list
system-tools-list@...
http://mail.gnome.org/mailman/listinfo/system-tools-list

[marcus-11]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carlos Garnacho wrote:

> On Thu, 2006-11-09 at 12:21 -0500, Joe Marcus Clarke wrote:
> 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 :)

This is perfect.  I have added a FreeBSD rc.d script to our port, and
Nautilus is now coming up as before.  Thanks!

Joe

- --
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@...
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

iD8DBQFFU3m/b2iPiv4Uz4cRAnykAKCm+rLsXGfQObOyXl8KdkP3/QqkHgCeMLj1
D99nNXCq4berA023BUgFxAM=
=6JaX
-----END PGP SIGNATURE-----
_______________________________________________
system-tools-list mailing list
system-tools-list@...
http://mail.gnome.org/mailman/listinfo/system-tools-list