pogson

I don't do RedHat/CentOS these days but Debian GNU/Linux and others need /etc/nsswitch.conf to point to ldap after changing the PAM (pluggable authentication modules) settings to use ldap. Presumably, you have a select bunch of users in /etc/shadow, /etc/passwd on the servers. There are scripts to pump them into LDAP. generally, see LDAP authentication using pam_ldap and nss_ldap specifically for RedHat, see Authentication using LDAP

If the problem is I/O errors, you could try copying block by block with dd (disk duplicate). Using the options noerror,notrunc, it should give you garbage blocks in the output rather than stopping. This should copy all good blocks, I hope. ssh server "dd if=/dev/sda conv=noerror,notrunc " | cat > somebackup disc or file should be helpful. see https://wiki.archlinux.org/index.php/Disk_Cloning SSH is the next best thing to being there. dd can work on one partition or a whole disc. It's wonderful.

That's right. Wireless clients should have a local OS installed. Wireless thin clients have bandwidth issues. There are ways to recuce bandwidth requirements like reducing screen resolution, using NX instead of X, and just virtualizing some major apps instead of the whole desktop. To virtualize just a single app is simple. Replace the executable on the client with a script that looks like ssh -Y servername "oowriter" The "-Y" forwards the window for the application to the client and the application runs on the server. This keeps the user data on the server and off the network so file saves etc. do not clog up the network. preventing pauses. Experience with Ethernet may be relevant. At 10 mbits/s, a thin client will see jerky behaviour because screen refreshes take an appreciable time. At 100 mbits/s, most users will see a normal desktop. At 1000mbits/s, even video works well. The problem for wireless is that the room shares a single channel unless you take care to put a few clients on each channel and the wireless router can be a bottleneck. I would look into using Wireless N if that's an option and/or using multiple wireless routers. 802.11b/g use overlapping channels so use widely spaced channels may be better. I used to use 1 and 11. You might need 1, 6 and 11 if you need three groups. The bandwidth requirements for non-video at 1024x768 is around 200kbits/s per client for adults doing a fair bit of reading. Twitchy teenagers or elementary children use a lot more graphical bandwidth, perhaps 1 megabit/s per client, so the usage can really impact a wireless setup of thin clients. If you find tweaking the wireless connectivity problematic, you could look at using the notebooks as conventional thick clients but only using the wireless to share users' files from the server.

The clients accept the key offered by the requesting machine if it matches what's in /root/.ssh/authorized_keys. If it's the UPS sending the command, that command will be executed by some user on some computer. Let it be root or someone with a key that the clients accept as from root. Typically the UPS will send a "shutdown" command to execute on a particular host. Just replace it with the command you need to run ssh to each other client. You may also want to shut machines down in a certain order, so instead of a loop, use a sequence of commands with delays between: ssh able "shutdown -h now&exit;"// The web applicaton sleep 15 ssh baker "shutdown -h now&exit;" //The database sleep 15 shutdown -h now //the machine local to the UPS You can put the sequence of commands in some file, say, /root/shutdown_servers Have as the first line #!/bin/bash commands ... Then instead of shutdown -h now, have the UPS run /root/shutdown_servers Make the script executable and runnable by root chown root:root /root/shutdown_servers chmod 550 /root/shutdown_servers

for remote shutdown, try for f in ip1 ip2 ip3 ... ; do ssh $f "shutdown -h now&exit;" &done You need to set up passwordless logins by doing ssh-keygen as root on the system somewhere and copying /root/.ssh/id_rsa.pub into /root/.ssh/authorized_keys on each client you wish to control. One way to make the list of IPs is to create a directory in /root/ with the IP addresses as directories or filename, e.g. cd /root/ mkdir IPs cd IPs touch 192.168.0.34 for ((f=4;f=f-1;));do ((g=f+13));echo $f $g;done //generates a sequence of values for ((f=4;f=f-1;));do ((g=f+13));echo $g;touch 192.168.0.$g; done //generates a sequence of empty files 192.168.0.14-16 for f in *;do ssh $f "shutdown -h now&exit;" & done // executes shutdown on the list of IPs The process is very fast, a fraction of a second per PC. The shutdowns run in parallel once started. It's a great way to get students' attention at the end of class or whatever. It can be scripted with crontab, for example to occur at end of day/class (dangerous to shutdown visiting teachers PC, however...). Instead of the shutdown, you can distribute the keys this way (imaging saves typing the root password repeatedly too). for f in *; do cat /root/.ssh/id_rsa.pub | ssh $f "cat >> /root/.ssh/authorized_keys";done //Type root password once for each client visited This can also work for thin clients. Just copy the SSH key into the chroot in the NFS filesystem of the clients. e.g. cat /root/.ssh/id_rsa.pub >> /opt/ltsp/i386/root/.ssh/authorized_keys //append to key file in chroot. SSH is the Swiss army knife of GNU/Linux system administration.

I've done this a lot in schools. The least expensive way to use old PCs as thin clients is to use GNU/Linux on the server as well as the thin client. That way their is no licensing fee at either end. I usually use Debian GNU/Linux. On old PCs, the CPU may even have trouble encrypting the traffic so using plain X window system really cuts down the load on the machines. Since the old machines are doing less, they are pretty snappy, better than a new desktop PC. e.g. 5s logins and 2s opening an application given a new machine as server. By putting the lab on its own LAN/using a second NIC and switch on the server you can get enough security. Any modern PC with 500MB RAM plus 100 MB RAM per client should do a great job as server. It helps to have multiple hard drives so that multiple seeks can take place. I normally use RAID 1 with 500 gB hard drives. GNU/Linux can do software RAID efficiently. Booting PXE on the clients may be faster than booting from a hard drive if you don't have a BIOS that fiddles around too long. Hard drives take seconds to stabilize. The PXE kernel can be customized to be much smaller than a normal kernel because it does not need many drivers. You can also trigger some PCs to boot on schedule or command using wake on LAN settings. That way the time taken to boot is irrelevant because it can be done before students enter the room. Unfortunately, some browsers insist on doing "smooth scrolling" (multiple screen refreshes look smoother). Lately FireFox and Chrome both have no means of turning that off. The result is that scrolling is jerky on thin clients because of multiplied network lags. Opera does permit disabling smooth scrolling. If you have GNU/Linux installed on the client PCs, you can edit /etc/rc.local to start an X session with X -query ipaddress_of_server. Then students will see a login screen when the old machines boot. Typically, it takes 30s to boot GNU/Linux from the hard drive of an old machine. The newer/more powerful machine used as a server needs to be tweaked to accept XDMCP connection from the LAN/subnet. The display manager/firewall setting may need to be tweaked. Most distros have that turned off by default. There are packages one can install from Debian GNU/Linux and other distros to set up LTSP on the terminal server. ltsp-server-standalone will set up DHCP for the lab and run the clients. ltsp-server will just run the clients. Some distros, like skolelinux or edubuntu will have an option to set up the installation from a CD. Just boot from the installation CD and choose the server setup. A couple of years ago, I had a lab with 17 PCs that were 8 to 10 years old and I converted them to boot PXE from a 5 year old machine with 2gB RAM. It was a constant problem with driver issues with XP as students would swap mice and XP would freeze... With GNU/Linux, I gathered all the old machines I could find making 24 clients running LTSP and the lab ran trouble-free with the performance of the newer machine. Kids and teachers loved it. The clients were so slow that turning off encryption was essential. Performance of the old lab was then better than the new lab running XP. It's the best way to run a lab IMHO but it doesn't do video very well because of the old/slow graphics cards and network bottleneck. If you can afford gigabit/s NICs you win on the network lag but I had graphics cards with as little as 4MB RAM. Sad...