Next revision | Previous revision |
client_distribution [2010/11/23 14:29] – created - I have dumped info gathered from IRC to start things. aatre | client_distribution [2022/02/10 13:34] (current) – external edit 127.0.0.1 |
---|
| |
===== Client on a stick (pine cones) MVLC ===== | ===== Client on a stick (pine cones) MVLC ===== |
| **Note:** This is method relies on revisions not available in 1.6.* releases and will probably be useful out of the box once Evergreen reaches version 2.1 |
| |
Jason Stephenson: We're distributing Evergreen clients to our member libraries on USB sticks. These will have a clickable, ready to run client pre-configured with the server address and a pre-registered workstation. There will also be a windows-executable installer if they want to install onto their workstation. That won't be pre-registered, but it will have the server pre-populated. Going to put them in delivery after the US holiday weekend (2010). Just so everyone can groan, we call them "pine cones." | The "Client on a stick" method is useful for several things (that have been thought of so far, anyway). |
| |
Thomas Berezansky: http://www.mvlc.org/images/1123101118a.jpg - http://www.mvlc.org/images/1123101118.jpg | The first, MVLC's initial purpose, is a simple to use client that requires no setup, you can just run it off of the USB stick. |
| |
Each flash drive will have a standalone evergreen client (windows) that stores everything (including profile) on the drive and an installer for installing on machines. Each one will be pre-registered too. With xulrunner auto-updates. | The second is for a portable client for use away from internet connectivity, such as in a bookmobile. Because everything is stored on the USB stick the offline client can be used in the bookmobile, then the USB stick (rather than an entire computer) can be brought to a computer with internet connectivity to do the upload. |
| |
90% of the work is "make a custom frontend launcher that adds a 'force use this profile' command line option". Then put the last_ws_server and ws_info files into place using a bash script //(Anoop Atre - share code?)//. LOADING the sticks is a different story, as is labeling them. | The third is for an "emergency" client. Provided it is kept up to date the USB stick can be used with a computer that is not normally a staff workstation in the event of the normal workstation failing. Alternatively, it can be used as a "we need a staff client right here for a few hours" type of thing, where the USB stick becomes a "roaming" staff client that can be used on normally public or non-library computers (such as staff laptops). |
| |
I do include an autorun.inf, but it is used (or ignored) differently on each version of windows we have kicking around. | Building the USB stick staff client is simple. With the staff client build enhancements (as of this writing, only in trunk) a 'make win-xulrunner' will build the base client itself in the "client" folder. This can then be copied onto a usb stick, recommended into a folder like "egstaffclient". A second folder can then be made, we used openils, for the profile. ("Profile" may be another option in this case) |
| |
For the record, my "make a launcher" bit was "make a .bat file to run 'evergreen.exe -profile openils' then run a .bat to .exe converter to make it an exe". I can better document this if people want, though. | For the "demo" sticks MVLC made an installer was included (based on trunk's windows installer functionality), and the "open-ils.write_in_user_chrome_directory" preference was defaulted to false. This meant that we could set last_ws_server for the installer and that workstations would be registered on a computer level instead of an individual user level when using the installer. With that set to false our ws_info and last_ws_server files on the USB sticks lived in "egstaffclient/chrome/open_ils_staff_client/content/conf/". With that preference set to true (the normal default) we would have used "openils/chrome/", assuming our "fixed profile" folder was openils. |
| |
| We needed a launcher to set the forced profile. We ended up with a batch file (.bat) containing the following: |
| |
| <code>egstaffclient\evergreen.exe -profile openils</code> |
| |
| Note that "openils" is in the root of the USB stick in our case and was where the forced profile would end up living. |
| |
| We then used a Bat to Exe converter from http://www.f2ko.de ([[http://www.f2ko.de/programs.php?lang=en&pid=b2e|This specifically]]) to turn that .bat into a .exe with an icon. We used the "invisible application, current directory, delete at exit" options and specified the icon in the versioninformations section. |
| |
| An autorun.inf file was also included, although behaviour will differ from windows version to windows version with it on a USB stick. |
| |
| <code> |
| [AutoRun] |
| ICON=startevergreen.exe |
| LABEL=MVLC Evergreen Demo |
| OPEN=startevergreen.exe |
| ACTION=Start Evergreen Demo Client |
| </code> |
| |
| To populate the USB sticks we used a bash script on a linux box (it does two at a time, and takes the shortname the stick should be for as an argument): |
| |
| <code> |
| #!/bin/bash |
| |
| echo Mounting... |
| mkdir /media/usb0 |
| mkdir /media/usb1 |
| mount /dev/sdc1 /media/usb0 |
| mount /dev/sdd1 /media/usb1 |
| echo Starting Copy, USB1 |
| cp -R build/* /media/usb0 > /dev/null |
| echo Starting Copy, USB2 |
| cp -R build/* /media/usb1 > /dev/null |
| if [ "$1" ]; then |
| echo Pre-reg USB Sticks with library $1 |
| libnum=`grep $1 libs.csv | cut -d , -f 2` |
| sed -e s/SHORT/$1/g -e s/ID/$libnum/ -e s/NUM/0/ ws_info.tmpl > /media/usb0/egstaffclient/chrome/open_ils_staff_client/content/conf/ws_info |
| sed -e s/SHORT/$1/g -e s/ID/$libnum/ -e s/NUM/1/ ws_info.tmpl > /media/usb1/egstaffclient/chrome/open_ils_staff_client/content/conf/ws_info |
| echo Add passwords to USB sticks |
| for DRIVE in {usb0,usb1}; do |
| grep \"$1\" generic.csv | sed -e 's/ /\ /' | sed -e 's/^[0-9]*,"\([^"]*\)","\([^"]*\)",.*,"\([^"]*\)"$/<tr><td>\1<\/td><td>\2<\/td><td>\3<\/td><\/tr>/' | while read PASSWORD ; do |
| sed -i "/<passwords\/>/i\ |
| $PASSWORD |
| " /media/$DRIVE/README.html |
| done |
| sed -i "/<passwords\/>/d" /media/$DRIVE/README.html |
| done |
| fi |
| echo Unmounting Drives |
| umount /media/usb0 |
| umount /media/usb1 |
| rmdir /media/usb0 |
| rmdir /media/usb1 |
| echo Done |
| </code> |
| |
| Take note that this pulled information from ws_info.tmpl, generic.csv, and libs.csv. generic.csv was a list of our accounts for the sticks, libs.csv was a simple "SHORTNAME,ID" list. It also refers to a README.html file we made (with screenshots) for our members, where it puts username/password information in place of a <passwords/> element. |
| |
| ws_info.tmpl ended up being this: |
| <code>{"SERVER":{"name":"SHORT-pineconeNUM","owning_lib":"ID","lib_shortname":"SHORT"}}</code> |
| |
| The most annoying part ends up being loading and properly labeling the USB sticks. |
| |
| As for the server-side registration, we used the following SQL: |
| |
| <code>INSERT INTO actor.workstation(name,owning_lib) SELECT shortname || '-pinecone' || num AS name, id AS owning_lib FROM actor.org_unit, (SELECT unnest(ARRAY[0,1]) AS num) AS n WHERE ou_type = 3 AND shortname IN ('list','of','shortnames') ORDER BY id, num;</code> |
| |
| The "ou_type = 3" part wasn't really needed, originally I wasn't limiting the shortnames to the branches we were building the sticks for. |
| |
===== Client management using WPKG TADL ===== | ===== Client management using WPKG TADL ===== |
| |
Jeff Godin uses WPKG to install and manage staff clients. | Jeff Godin uses WPKG to install and manage staff clients. |