Re: [sabayon] <pinkfloyd>Is there anybody... out there?</pinkfloyd>

[Federico Mena Quintero <federico ximian com>]

On Tue, 2010-01-26 at 14:16 -0600, Scott Balneaves wrote:

> Here's an updated "Where I'm headed for the next few months" state of the union
> address.

Thanks for the overview, Scott!  This is very interesting stuff.

> 1) I've started the process of thinking how we can "PolKit-1"-ize Sabayon.  I'm
>    not really sure what I'm doing, but... hopefully I can at least map out a
>    plan over the next little while.

I think just to "let sabayon run if you are not root" is not
interesting.

Here are some badly-structured thoughts:

* It would be useful to have some privileged users be able to tweak user
profiles.  Think of a company where the Grand Poobah Sysadmin has a few
privileged Minor Minions who deal directly with users; those Minions
would tweak the user profiles and leave the server room to Poobah.
PolicyKit would maintain the policy of who can actually edit user
profiles.

The technical details are interesting.  Sabayon needs to be able to
write to the /etc subdir where the profiles live.  It needs to create a
temporary user for the child session.  The sysadmin should not have to
tweak all those sub-privileges individually.

* Mandatory settings in GConf are easy to circumvent, as users can
simply delete or change their ~/.gconf-xml-mandatory directories.  It
would be nice to have a place for mandatory and/or default settings that
users can really not change.  GConf lets you do this easily by tweaking
the /etc/gconf/2/path file, but I don't think it lets you set a per-user
path easily (maybe I'm wrong; I don't know GConf's internals very well).
Maybe if we had an environment variable
GCONF_EXTRA_PATH=/etc/profile/PROFILENAME/path, we could have
sabayon-apply stick that in the appropriate place.  This may need
cooperation from gnome-session or whatever.

Hmm, I thought I had more ideas than those, but that seems to be it :)

(By the way, you shouldn't have to change all the calls to dprint() in
the code.  If dprint() needs to be any more sophisticated than
"debuglog.log ("domain", "message")", then feel free to change
debuglog's API).

> 2) Fixing the logging situation's next.  I've posted on this before, but the
>    long and the short of it is: Unix-like logging (no news is good news, log
>    all errors to the standard places (syslog || STDERR), verbosity with a "-d"
>    flag).  I've got to do this without touching all the dprint's in the code,
>    since I don't want to aggro the translators.

Sigh, the logging code is so broken.  I must have broken it at some
point; it *seemed* to work quite well when I initially introduced it.

The idea was that Sabayon's child processes (sabayon-apply and
sabayon-session) would feed their logs upstream to the main Sabayon
process, which in turn would only write them to the logfile if an error
occurred ("no news is good news").  However, this is not working very
well.  I don't know if it's the children not writing their logs to the
right place (stderr) or if it's the main Sabayon process not reading the
children correctly.

When sabayon-apply gets run as part of a user's login, the logs
*definitely* need to go to syslog so that the sysadmin can catch errors.

The reason for having ~/sabayon-debug-log.conf is basically this:

1. sabayon-apply is a login-time process.  It's a PITA to have to set
environment variables to turn on logging at that time.

2. Having a ~/sabayon-debug-log.conf makes it very obvious that you
requested logging at some point.  When you see logfiles in your home
directory and wonder where they are coming from, you'll see the conf
file and say, "oh, yeah, I remember".

3. Developers can give users a pre-made sabayon-debug-log.conf file and
just tell them to stick the file in their home directories, instead of
giving laborious instructions for configuring logging.

Anyway, that was the idea :)  See
http://visibleworkings.com/trace/Documentation/ring-buffer.pdf for the
inspiration behind Sabayon's logging mechanism (it's a short, excellent
paper).

  Federico