[K12OSN] Remote shutdown/startup Thin Clients

[Immanuel Derks]

Jim, this is an excellent feature! I didn't know we could have all this
info available through ltspinfod.

Regarding powering up/down with WOL and ltspinfo --host --shutdown we
ran into a few strange issues. 
After enabling ACPI or APM and wake on pci features in the bios of the
Thin Clients, I can use successfully WOL with etherwake --MAC-ADDRESS to
boot the client. However, after a shutdown with ltspinfo, it is
impossible to use etherwake again. Apparently the hard shutdown is not
the same as the (remote) soft shutdown, because the latter seems to kill
the the WOL function. Only after hard power-cycling I get this funtion
back, so this is not very useful. 

Anyone experienced this before, or for that matter has any pointers in
the right direction?

Kind regards,
Immanuel Derks 


On Sun, 2004-08-22 at 14:11, Jim McQuillan wrote:
> On Sun, Aug 22, 2004 at 04:26:11AM -0400, Jay Pfaffman wrote:
> > I'm profoundly lazy.  Can't these things put themselves to sleep?  Maybe not.
> > 
> > If you turn on ssh on the clients & put a key in root's
> > .ssh/authorized_keys file you could do something like this:
> > 
> > for x in 0 1 2 3 4 5 6 7 8 9 ; do ssh -l root 192.168.1.$x shutdown -h now; done
> > 
> > Oh, wait.  The clients don't run a ssh daemon.
> 
> They will run sshd, if you enable LOCAL_APPS.
> 
> But, there's an easier way.  You can use ltspinfo and ltspinfod to do it
> for you.
> 
> Starting with LTSP-4.0, we've got a daemon running on the client,
> waiting for something to do.  It's called 'ltspinfod'.  It was
> originally designed to answer questions about the client.  For instance,
> the server can ask the client which sound daemon it is running, so that
> it knows how to setup the server-side stuff to send the sound stream to
> it.
> 
> Well, ltspinfod has a couple of other features too.  1) It can do a
> shutdown or a reboot of a terminal.  2) It can read things from the
> /proc filesystem.
> 
> Both of those features are disabled by default, but it's really easy
> to enable them.
> 
> In lts.conf, the following entries control ltspfinod:
> 
>    ALLOW_SHUTDOWN  =  Y
>    ALLOW_PROCREAD  =  Y
> 
> If you want to allow a remote shutdown and/or reboot to happen, then
> set ALLOW_SHUTDOWN = Y  (the default is N).
> 
> Then, to actually get the server to send the shutdown/reboot message to
> the client, you'd use the 'ltspinfo' script to do that.
> 
> It's installed on the server, in the /usr/sbin directory.
> 
> To run it, try something like this:
> 
>    /usr/sbin/ltspinfo --host=ws001 --shutdown   (or --reboot)
> 
> 
> If your terminals are fairly new hardware, with apm stuff in the bios,
> it should actually shut down the client.  If the terminal doesn't have
> an apm bios, it will kill the processes, but then just sit there.
> 
> If you want to read something from the /proc filesystem, 
> you'd use the '--proc' arg to ltspinfo.  For example, if you
> want to read /proc/meminfo on the client, to see info about the
> terminals memory, you'd do this:
> 
>    /usr/sbin/ltspinfo --host=ws001 --proc=meminfo
> 
> Notice I removed the leading '/proc' from the --proc arg.  That's
> because the ltspinfod, running on the client will do a fork and a
> chroot() into the /proc directory.  This is to prevent someone from
> reading anything else in the client filesystem.  This is for security
> purposes. As we work on getting kerberos and other security measures in
> place, we need to make sure nobody can grab private keys and such.
> 
> If you want to use ltspinfod for what it was originally designed for,
> you can use it like so;
> 
>    /usr/sbin/ltspinfo --host=ws001 --cfg=XSERVER
> 
> Or, pretty much any other parameter from lts.conf can be used in the
> --cfg entry.  you can also use   --cfg=all
> that will retrieve all of the parameters from the workstation.
> 
> Anyway, I hope that helps,
> 
> Jim McQuillan
> jam at ltsp.org
> 
> 
> > 
> > Another way would be to use cron, but the clients don't run cron either.
> > 
> > You could make the clients run this stuff.  Turning them on
> > automatically might be possible with the machine'sBIOS.
> > 
> > A simple solution would be to turn off the power to the circuits that
> > the machines are plugged in to.  It's not really necessary to do a
> > clean shutdown.  Just pull the plug or hit the power strip.
> > 
> > On Thu, 19 Aug 2004 09:30:57 +0200, Immanuel Derks
> > <i.derks at translucent.nl> wrote:
> > > Hi,
> > > 
> > > I wonder if anybody has already some experience with remotely powering
> > > down/up of APCI capable thin clients. What do you need to enable this?
> > > We have 60 Netier 1000XL on a site, and could save the librarian a lot
> > > of work by getting this feature working.
> > > 
> > > Kind regards,
> > > Immanuel Derks
> > > 
> > > _______________________________________________
> > > K12OSN mailing list
> > > K12OSN at redhat.com
> > > https://www.redhat.com/mailman/listinfo/k12osn
> > > For more info see <http://www.k12os.org>
> > > 
> > > 
> > 
> > 
> > -- 
> > Jay Pfaffman                           <pfaffman at utk.edu>
> > Asst Professor of Instructional Technology, U. TN, Knoxville
> > Experimenting with gmail, please honor the Reply-To
> > 
> > 
> > _______________________________________________
> > K12OSN mailing list
> > K12OSN at redhat.com
> > https://www.redhat.com/mailman/listinfo/k12osn
> > For more info see <http://www.k12os.org>
> 
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>