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 -- edubuntu-users mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
