clicompanion-devs team mailing list archive

[Jonathan Marsden <jmarsden@xxxxxxxxxxx>]

On 11/18/2011 10:47 PM, Duane Hinnen wrote:

> On Fri, Nov 18, 2011 at 1:00 AM, Jonathan Marsden wrote:


>> Didn't you test each of the commands in a default-install on a 
>> Debian machine or VM, as part of working towards getting
>> clicompanion into Debian?  If not, I suggest your test process for
>> the port is lacking.


I still think this is a key observation.  A clicompanion dev has frozen
both application and packaging codebases ready for a release, but no-one
has tested the current default set of commands in the library on a
default install of Debian?  That's very peculiar.  Not good practice.  I
can't imagine going for a release to a new OS or distro without running
through a basic set of tests on a default install of that platform first...

>> Unless the user installs the sudo package and configures
>> themselves to have full sudo rights, all commands in the
>> .clicompanion file that use sudo will fail in a default Debian
>> installation.  ...


> This is very interesting. I did not even think of this. i chose to 
> install sudo during installation on my Debian box so I never thought 
> about this. At the moment I am inclined to think the gksu option 
> would be the front runner solution so far.


It's certainly the easiest to implement :)  The main obvious downside to
gksu (assuming that it gets installed in Debian by default for any
normal GUI-oriented installation, I/we need to check that!) is that if
people are using clicompanion and its command library to learn text mode
Unix/Linux administration, if they then try these (gksu-based) commands
over SSH to a remote server, they'll be unhappy -- gksu won't be there
on the server.

[Aside: clicompanionlib seems to have code that looks in /etc/passwd to
determine the user's preferred shell; it is considered much better
practice to use getpwent(3), so it works on machines that don't use
/etc/passwd but use LDAP or NIS for their authentication database... I
think that's

import os,pwd
shell = pwd.getpwuid(os.getuid()).pw_shell

in Python.  But that's untested "off the top of my fingers" code!]

How much has clicompanion been tested where you:

 (1) run clicompanion locally, and in its shell you then
 (2) ssh to a remote machine, and then
 (3) use its library of commands within the *remote* shell?

How does this (unusual?) use case affect our discussion of when to
decide which commands in the library work or are displayed?  What if the
remote machine runs a totally different distribution of Linux from the
one being used locally?  What if it runs NetBSD, or OS X, or even Cygwin
under Windows? :)

> I think this is a fairly big issue.

> I think the program should be just as useful to beginners as well as

> more advanced users. So I think the app should be as smart as
> possible in handling this without as Jonathan points out compromising
> performance.


I suspect we need (a) a quick fix ASAP, so Marek's 1.1 package for
Debian has a working set of commands, and (b) possibly a more complex
longer term approach.  I think gksu is good enough for (a).

Jonathan