some questions

[Jim Kronebusch]

> 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).

Thanks for clearing that up for me.

> 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 makes sense then that something be placed in ldm.  But I agree that if possible to
place a minimal amount of code in ldm and to use external scripts where possible for
different scenarios.  Hopefully that would help keep ldm clean and not put your average
admin into such a critical file when trying to modify printer options.  I like the idea
of enabling everything with DEFAULT_PRINTERS=Y option or something in the lts.conf as well.

> 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.

Agreed.  Hopefully simple seamless local apps are in the very near future, and a
solution that takes local apps into account seems like it would be a very good choice.

Also wondering if it would be possible to build the scripts in a way that they create
the printers on the fly when setting the default?  Let me clarify.  Here at our school
we have many printers.  Instead of sitting down and creating 20 printers always
available to all users and picking a default, I would rather have the list of printers
be empty to start.  Ideally my file/s that specified groups of workstations names/mac
addresses/ip addresses to default certain printers would also contain the information
needed to set up the printer (IP address, driver, printer name, etc).  Then when I boot
a client in the Senior High main lab group the scripts would have enough information to
create the "CHS Main Lab Laserwriter" and also set it to default.  This way when
students went to print, their only option would be "CHS Main Lab Laserwriter" and it
would not be easy for them to print 100 copies of a funny picture from Google images to
the Junior High main lab.  Make sense?  And also in a real perfect world I could assign
multiple printers to be created for each group of clients.  An example would be that in
our Senior High lab maybe we have a Color Inkjet and a BW Laserjet, and right next door
in an adjacent room we have another BW Laserjet.  It would be nice if we could list all
3 printers for the Senior High Main Lab group that all were created on log in and the
Main lab laser set as default.  Then student could select the color printer if desired,
and the laser in the adjacent room would be available in the case of high print loads or
if the default failed.  Still make sense?  This is actually how we added printers in the
past to our stand alone machines and it would be awesome to maintain that sort of
functionality.

I will make a new post quick as well regarding some possible changes/modifications to
Student Control Panel to help out with this. 

-- 
This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.