some questions

[Gavin McCullagh]

Hi,

On Wed, 01 Aug 2007, Jim Kronebusch wrote:

> The $SSH_CLIENT variable successfully returns the IP of the client which
> could be cross referenced to a preset list of Mac Addresses to IP's
> (maybe from the hosts file, dhcpd.conf, lts.conf or some other file).

SSH_CLIENT is indeed the right choice (rather than ESPEAKER) to figure out
the thin client address.

> Maybe instead of including this directly into LDM2 this may be a good use
> of the new rc.d scripting?  I am not sure the exact thoughts behind what
> the rc.d was developed for, but maybe putting add-on features such as
> this into there would be cleaner than hacking up LDM?

It depends what you want, but we'd have to think in terms of who this
default printer setting applies to:

If you run it on the thin client itself (under any user), it'll apply to
users local to the thin client -- this might be useful for local apps but
not for the current thin clients.  An rc.d script run within the thin
client chroot can only easily apply to the thin client.

If you run it as root on the thin client server, it applies to everyone on
the server which is not what you want either.

You could indeed run it in /etc/bash.bashrc or /etc/profile on the server
though this will probably involve a static ip address and a file 
mapping IPs to printers (the thin client server doesn't easily know the
thin client mac address -- though I suppose you could determine it via the
arp table).

The reason I've suggested hooking it into ldm is that ldm (as far as I
know) is the only place where the thin client executes code on the server
as the user who logs in.  So, it allows us to run lpoptions on the server
as that user which seems to be the desired effect.  Also, ldm is the place
where many other thin client specific settings are passed up to the server
(such as setting up pulse) so it's reasonably consistent in that sense too.
Practically all thin client-specific settings are currently applied in
lts.conf so it seems logical to try to keep them all together in that one
file.

Perhaps ldm could call one or more external lpoptions scripts on the server
which would reduce the amount of code in ldm and allow us to separate that
logic out allowing an admin to modify it if necessary.  I guess there are
potentially lots of complex cases (eg. an admin might want to apply a
default printer depending on the user's group and/or the thin client) so a
separate script might make sense, though I think ldm would need to call it.

It would presumably be best if whatever we propose looks after both the
current thin client case as well as local apps or a complete diskless
workstation.  Apps run in all three cases should pick up their default
print server/queue from ~/.cups/ so the question might just be how to set
this info consistently across all three.  It would be important to set the
print server, not just the queue though. 

A different approach (in keeping with how sound works) might be to run cups
on each thin client and point the user at a queue called "Default" on the
$SSH_CLIENT print server.  This might also gel better with local printers
on the thin clients.

Gavin