Add a mode to landscape-client that allows it to run non-root (and with limited plugins)

That will become possible with the DBUS ideas we've been discussing.

It looks like the only thing left for this to be done is the ability to configure landscape-client to not run landscape-manager at all.

Ready for review in the attached branch!

Looks good to me, only one question, and not directly related to this branch, but this just highlights it more.

Should we allow a tri-state for "locked" i.e. "locked", "unlocked" or "unknown"?

This isn't a blocker, so +1

After a reboot, /var/run/landscape directory is gone. This happens because /var/run is a tmpfs filesystem (I checked all the way back to dapper: it's always tmpfs).

The landscape-client initscript needs to create this directory every time. For example, this is the klogd initscript:

(...)
case "$1" in
  start)
    log_begin_msg "Starting kernel log daemon..."
    # create klog-writeable pid and fifo directory
    mkdir -p /var/run/klogd
    chown klog:klog /var/run/klogd
(...)

So these are my other findings.

a) running landscape-config erases the non-root configuration from /etc/landscape/client.conf. /etc/default/landscape-client stays the same.

b) the following actions/monitoring functions stop working (probably expected, so I mention them just for completeness):
- custom graphs
- script execution
- package operations
- process killing
- user management
- viewing user locked or not locked status: it's assumed they are always unlocked
- restart/shutdown

c) the error message that is displayed when one of the above is tried is confusing, because it's a generic error message that states many possible causes for the error. If possible, we should try to give a precise message about why the error happened (the client is in non-root and read-only mode).

/var/run/landscape: good catch, I'll get to work on this.

[a] Are you sure about that? I just ran another test and verified that it's not removing the monitor_only = true line. It does rewrite it and it may come out in a different order, though.

[b] thanks. I guess this is a good list to go into the documentation.

[c] Yeah, that's true. I think for practicality's sake for now we'll just have to add "non-root client" as one of the items to the list of possible causes for this generic failure. If it becomes important we can at some point get the client to start reporting to the server that it's actually in non-root mode, and then report more meaningful errors (or even disable certain user interface elements when dealing with non-root clients). I'll do this in a separate server branch.

Thanks for the review.

Okay, I've fixed the /var/run/landscape issue and tested it on my own intrepid machine.

Oh, you are right about (a). I jumped the gun. It's there, just in a different order as you said.

The other last issue I could find is that if the switch to non-root happens after the client has been running for a while in the traditional root mode, at least the watchdog.log log file would be owned by root, making the client crash when starting in non-root mode because of lack of write access to that file.

I also tested custom graphs with the client in non-root mode, and, using trunk on the server side, got the expected error of having script execution disabled on the client.

qa + 1 other than the log issue.

Just a couple of questions, and +1!

[1]

+ # Specify a low timeout because it may be quite normal for this
+ # service to not be provided, if the client is being run in non-root
+ # mode.

2 seconds seems to be a bit on the low side. Would increasing it a bit hurt too much on the normal failure case, or perhaps can we catch the error and see if the other side isn't up at all to make a more conscious decision?

[2]

+ if (config.bus == "system"
+ and not (os.getuid() == 0 or pwd.getpwnam("landscape").pw_uid == os.getuid())):

That reminds me, can landscape use the system bus according to the dbus configuration we have?

Btw, that line is now running over 80 cols.

[1] Okay, I've changed this to check if we're in monitor_only mode before making the call.

[2] As we discussed on IRC, "yes" :-)

Can I get another quick look?

Nice improvements! +1!

DONE! Merged to trunk!

This bug was fixed in the package landscape-client - 1.0.28-0ubuntu1.9.04.0

---------------
landscape-client (1.0.28-0ubuntu1.9.04.0) jaunty; urgency=low

  * Fix minor packaging issues in last release (LP: #343954)
    - Version number in landscape.VERSION is now correct
    - Fixed package version number to maintain convention
  * The following changes are in the 1.0.28 release:
    - Invalidate package cache when server UUID changes (LP: #339948)
    - Improve the "cloud mode" introduced in 1.0.26 to send more
      disambiguation data (LP: #343942) and allow the EC2 user data to specify
      the exchange and ping URLs (LP: #343947)
    - Allow importing of initial configurations (along with public SSL
      certificates) when running landscape-config (LP: #341705)
    - Support a non-root mode which allows running the client without the
      management functionality (LP: #82159)
    - Automatic cloud registration when there's no user-data to specify an OTP
      now works (LP: #344323)

 -- Christopher Armstrong <email address hidden> Thu, 19 Mar 2009 09:52:03 -0400

Is there actually a UI for turning this on or discovering it? I'd like this feature but there's no indication that it exists.

It's only documented in the supplied README file I'm afraid. We should add it to the help.landscape.canonical.com site.

The way this is handled for OAuth for Launchpad is pretty nice,
whereby during the handshaking process you're asked if you want to
give the program readonly or write access, and whether it should be
able to see private bugs or not. Similarly for say facebook.

I realize it's not precisely technically comparable because in this
case it is the less-trusted program that's presenting the web ui, but
the way it appears to the user may be something to aim for.

Perhaps during registration you could just show a message saying something like:

 Landscape will have root-level control of $machine. You can restrict
it to having read-only or limited access by editing $file on $machine
and restarting the landscape-client service.

To me, root access to my machines is relatively more trusted than my
Launchpad account and I don't really want to invert that.

ps, eventually it might be nice to have even finer-grained control
enforced on the client - for instance I might want to track package
updates and machine performance, but not to tell Canonical's servers
what processes are running on this machine or which users are logged
in. (This is probably a separate bug.)

Martin:

You can specify exactly which plugin you want to run, in the client
configuration. This is also, sadly, not documented very well.