Dataseam Workstation Support Resources
Adding the dGridAgent to your systems.
The dGgridAgent.pkg ( password to download: dGrid-2017) installs and configures the components required for a workstation to participate in the Cancer research grid.
Once installed, the package will periodically check in with the network servers, and can update itself when new versions become available, so it should not need to be manually updated. However, installing over an existing install should not cause any issues.
The package can be installed using the GUI, from the command-line, via Apple Remote Desktop, or can be included in a base image.
The Agent requires network access on TCP port 22 ( SSH ) to both your district grid controller, and the master grid controller, master.kydataseam.com , so please be sure your local firewall allows this traffic to pass. Contact email@example.com if you have any questions or issues regarding network access requirements.
Monitoring your district grid status.
There is a simple tool for monitoring your district’s grid status. The dgStat.app (password to download: dGrid-2017) shows the status of the grid controller, and of all the grid workstations, including their most recent check-in, current on/off line status, and various system values ( e.g. memory, free disk space, etc. ). The tool also allows you to report ( by serial number ) any failed system which should be removed from your district.
Once you have downloaded the app, place it in /Applications or ~/Applications on your system — this only needs to be installed on your administrative workstations, not on every system.
On first launch, a ‘dGrid Preferences’ panel will appear. Click the ‘Request New Account’ button and enter the appropriate information. This will log an account request. Once you receive confirmation by email that your account has been activated, you can enter the Username and Password in the dGridPreferences box. ( note: you may need to click in each box, vs using enter or tab, depending on the version of macOS you are running ). Be sure the ‘Save in keychain’ box is checked, then exit the App and relaunch it. You should be presented with a panel showing a breakdown of your district’s status. Buttons are available to bring up details of online and offline systems.
The View menu item contains an ‘Report Unrepairable’ options, which will let you log any ‘dead’ systems. Likewise the ‘Show Dead’ button will provide a list of system that have been marked permanently offline.
Active Directory Binding
KETS and Apple worked together to develop a tool for properly binding MacOS system to KETS Active Directory installation. You should have access to this using your firstname.lastname@example.org account. It is hosted here KETS-Mac-BindScript.zip. Instructions for use are inside the package. There are only a couple of configuration options, primarily you just add your district and the user/pass of an account with permission to bind workstations to the network. Enabling ADMOBILE is not recommended unless you are sure you need it and have fully tested it.
Apple produced the following support documentation which may provide some insight: Best Practices for Integrating with AD
When binding to AD on a Mac, 3 home directory options are offered, Shared, Mobile, & Local. Mobile allows for online and offline use, but has some overhead in terms of the caching of credentials, and should be avoided unless absolutely needed. Shared maps a UNC path specified in the users AD credentials and sets it to be their home directory. This can be useful so that students can see the same resources across different individual workstations, however it can cause slowdowns and other issues depending on network speeds, available remote storage, and other factors. If users experience slowdowns, especially when using media-intensive applications such as Photos, iMovie, & GarageBand and a network share is being used for home directory storage, try switching those systems to use Local home directories. This can be done using the unix command:
dsconfigad --mobile disable --sharepoint disable --localhome enable
Of course, this will have the disadvantage that students will need to manually copy completed work to the network after each session, but the increased performance can be very substantial.
No iMac is great to work on. The form factor is great for style and even convenience, but having the bulk of the computer behind a big glass screen makes for challenging repairs.
The older iMacs are actually much easier to repair that the newer ones, the glass is thicker and not glued in, there’s more room to move around, and more components are modularized and replaceable. Still doesn’t mean it’s a cake walk.
I’ve had a number of them open, but I’m by no means an expert, instead I’ll refer you to the iFixit series of take-aparts. Some are video, some are just a series of still images, some are both. Swapping out a failed HD is doable by most, and even for the ham-fisted, if the alternative is a non-working system anyway, it may still be worth a shot. I can’t advise ordering random repair parts such as power supplies, motherboards, and screens from eBay, unless you _really_ know what you are doing, but swapping between your own inventory and replacing failed HDDs is definitely an option.
DDR3 RAM for iMac 9,1 models
These iMacs use 1066 PC3-8500 DDR3 204 pin SO-DIMMs, and have 2 memory slots. Regardless of what some Apple docs say, they support up to 4G per slot, for a total of 8. The sizes of the DIMMS do not have to match, can run a 4G and a 1G.
Buying memory that’s known to work in a Mac is the safest bet, but if you are either shopping on severe budget or rifling through a stack of RAM pulled from other systems, generally anything with CL7 or lower timing will work.
Many 1333Mhz SO-DIMMs will work as well, and theoretically CL9 timed 1333Mhz chips == CL7 1066Mhz chips. However, mixing 1066 and 1333 units will not work!I have tried a few, and had some success, and plan to do some ‘product testing’ over the coming weeks, and will update this entry and add a Message Board entry with the results.
Prices for both 1066 and 1333Mhz chips were at an all time low at the end of 2016, but are now on the rise. If you are interested in upgrading some of your fleet, now is probably the time to do so. Splitting 8G (2×4) kits across a couple of machines is usually the most economical option.
Prices range from around $23-40 per 4G part, depending on bulk, sales, brand, phase of the moon, etc.
There are many drive upgrade/replacement options for these systems, and they provide a serious performance boost. The OEM drives were never fast, and are likely even slower now given their age.
However, this is a more technically challenging upgrade ( see the iFixit.com guides ), and unless you are facile with both PC hardware and working with untempered glass, it may be best left to units which actually have a drive which has already failed!
SSDs provide the biggest boost, but at the highest cost. In addition to being quite a bit more expensive per GB, they will require an adapter bracket. These can be found on Amazon, or you can order complete kits from OWC. It is tempting to go for the smallest available unit, but 128G is probably the most viable size.
Hybrid HDD/SDD units are a compromise in size/performance/cost. Units from 500G to 4TB can be had from $60-200 and are drop in replacements. These units basically act like Apple’s Fusion drives, but in hardware. Having 8-32G of SSD acting as a cache for a larger traditional HDD. Many 2.5″ sized ones will still need an adapter, though some ship with one.
Regular HDDs are available for as little as $35, and yet can still offer a performance boost. Most newer HDDs offer lower seek times, larger caches, and higher transfer rates.
Lastly, for the adventurous, several vendors offer mounting brackets which allow you to swap the optical disk for a 2nd HDD or SDD. Need a stealth server, slip a 6TB HDD and a 512G SDD into an old iMac equipped with 8G of RAM, build a Fusion drive with on on macOS or use ZFS on Linux or FreeBSD and you’ve got a compact reasonably performant server on the cheap. There’s even a VMWare ESXi port for it — but I digress.ChromeOS on an iMac?
It may come as a surprise to some that ChromeOS, the OS powering ChromeBooks and ChormeBoxes, is not actually a free-to-use fully open distribution like any other Linux. While it is a Linux based environment, and Google does provide source-code for Linux components which were modified for use in ChromeOS, all of the other components of the OS, including the Chrome browser itself, are not freely available.
In fact, Google / Alphabet doesn’t even offer ChromeOS directly to individuals, it is a proprietary system sold through various partner vendors. Typically these are vendors selling hardware.
However a company called Neverware offers a version of ChromeOS for various existing computers, including most older iMacs. They offer a free version, which can easily be installed on an older iMac. I have tested it on an iMac 9,1 and it is reasonably performant, and includes ( via an extra click ) most of the needed plug-ins ( Flash, video, etc. ).
But, there’s a catch. The Free version doesn’t integrate with Google’s management tools. No remote PowerWashing, no bulk restriction settings, and, maybe most importantly, no Active Directory interface.
Instead they offer a paid version, which does integrate with the various management tools. Their pricing model is $15 per device or $1 per enrolled student — annually. Whether that makes logical or financial sense will probably depend on your situation, but it does seem to be a technically viable option.
Of course, their software works on older PCs as well. Check out the pricing and supported systems on the Neverware.com site.
SIP, Bless, and netboot across switches/broadcast domains
With the advent of SIP, System Integrity Protection, in MacOS 10.11 and newer , making changes in various system files is no longer possible, even as root. This includes most all files in /bin, /sbin, /System, etc. While disabling SIP is possible, not only is it time consuming, as each system would need to boot into recovery mode, but it decreases the security of the overall system.
One area where SIP becomes problematic in a school environment is when trying to netboot from a particular server using the ‘bless’ command ( either from the command line, or executed via ARD ). The ‘bless’ command wrote the selected boot device information into NVRAM, allowing the system to follow that path on the next reboot. However, the NVRAM is also now protected via SIP, so something like
bless --netboot --server bsdp://10.1.1.8
will fail with an error, as it’s trying to update NVRAM in the background.
There are a couple of alternatives.
You can boot into recovery mode and use the csrutil command line tool to add specific destinations that will be allowed. e.g. :
csrutil netboot add 10.1.1.8
This is just as much trouble as disabling SIP, and less flexible, but it does retain the security that SIP provides.
However, Netboot services that are visible via the boot manager can be selected using Remote Desktop (ARD) or the systemsetup command. If your netboot server is on a different network segment though, it may not be visible. There are various ways to allow the DHCP-based BSDP packets from your netboot server to pass to other switchs/vlans/etc. Some of these vary depending on the network equipment involved, for example, using IP Helpers .
An alternative to using IP helpers or other solutions at the network equipment level is to simply configure a single Mac in the same network segment as the ones to be Netbooted to be a BSDP relay. This is pretty easy to do and can even be done on a machine with SIP enabled.
To do this simply create a file in /etc called bootpd.plist which contains the following text
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NetBoot</key> <dict/> <key>Subnets</key> <array/> <key>bootp_enabled</key> <array> <string>en0</string> </array> <key>detect_other_dhcp_server</key> <false/> <key>dhcp_enabled</key> <false/> <key>netboot_enabled</key> <false/> <key>old_netboot_enabled</key> <false/> <key>relay_enabled</key> <array> <string>en0</string> </array> <key>relay_ip_list</key> <array> <string>10.20.10.11</string> </array> </dict> </plist>
Change the 10.20.10.11 to the IP of your netboot server. Then run:
from Terminal on that system. Wait a few minutes and you should be able to see your netboot server in the list presented in System Preferences->Startup Disk on a target machine. Once you can see it, you can use systemsetup to select it from the command line.
To use ARD to select it requires that both the target systems and the machine from which ARD is executing both be able to see the netboot server — ARD will show it in the panel that appears with Manage->Set Startup Disk.