Administrators
B240 Access System
B240 is equipped with an Andover Automated lock system and is monitored by Police and Security(P&S) 24/7. Monitorin includes action triggered video from a camera watching the inside of the door. This video is stored for periods of time on DOITs' PLATFORM DVR system controlled also by P&S.
Access involves getting card swiped at card reader(can read it through a wallet)and entering a pin number. The combination opens the lock and records the event and the triggers the camera recording.
Requirements
Access takes three things:
1. New WiscCard with the computer chip embedded.
2. User generated pin
3. Activation for B240
The new WisCards are available for free in the basement of the union south. You present your old card and your old ID card. They take your picture and give you a new card. It will be active on the campus around 10am the next day. You will know if it is the right one if it has both the magnetic strip and two sets of numbers on the bottom of the back towards the right. They are currently issuing 113,000s. The numbers will look something like;
113807 11362950-1B
The pin number requires 4 numbers and can not start with a 0.
Requests
Requests for access (Activation) requires email sent to condor-admin@cs.wisc.edu where it will be handed off to be processed. bt is primary card administrator and khahn and tannenba are alternates if I am not around. Each request or set of requests should consist of a Name, 6 digit card ID and 4 digit pin.
Due to their not always entering the pin number title all requests "Keypad Activation for Computer Science B240" and always remind people to test it before they need to use it.
Activation/Deactivation
Authorized person send email to: access@mhub.uwpd.wisc.edu
SLES 9 on new hardware
In Order to install sles 9 amd64 on the new machines in Rack 7.
- Make sure hard drive is in compatibility mode
- Make sure install is done with safe settings.
Egenera pServer VM Host Setup How-to
First login to the web front end for the egenera.
To setup a pserver first go to the nmi-lpan, and click create in the pServer section.
Next assign the pServer the following:
- the next available pBlade
- a disk
- an ethernet device (make sure to assign the ethernet device to the private network switch)
- basic_sles9_boot boot image
After this select the disk, and partition the drive.
1gb: linux
16 gb: linux swap
Rest: linux
Save the drive’s settings and select Install Root Partition from above.
Select simple_sles9, and partition 3 and click submit. This will take a while.
Once the install has been done, start the machine and watch it via console.
After it is booted login and make the following directories, /sys, /proc, /proc/egenera.
Also goto /etc/sysconfig/network and rename ifcfg-eth-id-(mac address) to the correct mac address for that machine.
Reboot and make sure the machine boots correctly.
Intall gcc
scp 192.168.1.1:/root/gcc-3.3.3-43.28.i586.rpm .
scp 192.168.1.1:/root/glibc-devel-2.3.3-98.38.i686.rpm .
rpm -i glibc-devel-2.3.3-98.38.i686.rpm
rpm -i gcc-3.3.3-43.28.i586.rpm
Install VMware
scp 192.168.1.1:/root/VMware-server-1.0.4-56528.i386.rpm .
rpm -i VMware-server-1.0.4-56528.i386.rpm
vmware-config.pl
Follow the steps to install, serials available at http://nmi.cs.wisc.edu/node/1150
fixing cfengine's update.conf
I had the unfortunate experience of breaking cfengine sitewide by making faulty changes to update.conf
Fortunately, I’ve administered large sites before and I learned a few tricks…
This is a quick and dirty fix, so don’t expect anything particularly elegant…
What you’ll need:
- cluster ssh (http://sourceforge.net/projects/clusterssh/)
- a webserver accessible from the private net without a login
- This lame little script:
#!/usr/bin/perlmy $slash24 = “192.168.0.”;
my $list_of_servers;for( my $i = 1; $i < 255; $i++ ) { system(“ping -c 3 “.$slash24.$i); my $exit_code = $? >> 8; if( $exit_code == 0 ) { $list_of_servers .= $slash24.$i .” “; else { print $slash24.$i .” Not online\n”; }
}
print “\n\n” . $list_of_servers;
First, run that script on an NMI machine to determine which hosts in 192.168.0/24 are alive. Yes, there are better ways to do this, but this is just quick and dirty.
Second, connect to all of the live hosts with ‘cssh -l root <paste output of script>’. >100 windows will pop up. Yay. Enter the NMI B&T machine root password in the cssh console. We’re working under the assumption that they all have the same root password, which they should. The VDT machines and some of the ‘service’ machines won’t let you log in. Hit enter a few times to get rid of their windows.
Third, copy the good version of update.conf to the webserver.
Fourth, in the cssh console, run ‘cd /var/cfengine/inputs; pwd’ and verify (yes, by looking at each window) that you are in the correct directory. Some of the machines don’t run cfengine and hence don’t have this directory. You can close those windows. We’ll pretend those machines don’t exist.
Finally, in the cssh console, run ‘wget -N “http://<path to update.conf>/update.conf”’.
All the machines should now have a good version of update.conf
Double check by looking at the ‘last seen’ output after a couple hours.
—Ross
Metronome 2.5.0
This is a development release of Metronome. It contains new features, and may be unstable.
Download
Release Date: 2008-04-16
MD5 checksum: ae1672b027af1d56377894e199d17446
Metronome-2.5.0-0.noarch.rpm not created due to technical difficulties
MD5 checksum: TBD
Release Notes
The RPM packaging of this release has been delayed. Please contact us if this becomes a problem.
Backwards-incompatible syntax change: as a result of adding the ability to support multiple platform namespaces, we had to change the syntax of the platforms command in input specification files for the nmi input method. Instead of using a single colon to separate the source and destination platforms, users must now separate the platforms with two. This does not affect Metronome 2.5.0’s ability to use runs from earlier Metronome releases.
You can not run parallel jobs with Condor 6.9.5 and this release. Condor versions 6.9.4 and earlier, and 7.0.0 and later, do not have the problematic bug. Condor versions before 6.9.5 do not have the improved parallel job exit policies, which can dramatically simplify parallel testing, so we recommend using Condor 7.0.0 or above.
Some of Metronome 2.5.0’s new features require new tables in the database. Support for ‘git’ requires a new table, and this table has been added to the schema files. Support for nmi_resubmit_run remains more experimental, and its table is defined in a new file in the distribution, “database/Metronome-2.5.0”, which also includes a table for use with nmi_update_machine_table. This schema has only been tested against MySQL (although if you are using Metronome with Postgres, please let us know).
New Features
- renamed “Hosts” to “CPU Slots” in pool statistics sidebar, to reflect reality
- the Run Details web status pages now display the path to a run’s archive directory on the archive host (feature request 1176)
- Added remote_task_is_null flag to submit files to support local-only jobs.
- Added ability to handle multiple platform namespaces in a single submit file. See the new platforms and prereqs_ documentation.
- Added option for use with Condor 6.9.5 and later which throttles potentially IO-intensive jobs on the submit node. See the documentation for a discussion on this feature.
- Rewrote
nmi_migrate_runto better handle large run directories. - Added support for individually specifying
remote_*_timeouts, as well asremote_default_timeoutto replace the functionality of the 2.4.xremote_task_timeout. See <taskname>_timeout. - Large run workspaces are now more efficiently packaged in preparation for transfer to remote machines (feature requests 1327 and 1328).
- Add wgetrc option to use a separate wgetrc file for each input.
- Added ability to recreate a run entirely from the database. See documentation for nmi_resubmit_run.
Bugs Fixed
- This release contains all bug fixes from the Metronome 2.4.3 stable release.
Known Bugs
- View all Metronome bugs, as of the current release.
Requirements
- Metronome Submit/Archive Host
- Condor >= 6.8.0 or Condor >= 6.9.0
- Perl >= 5.005 (including DBI and DBD::mysql modules)
- Apache >= 2.0
- PHP >= 4.2.3 (i.e, with Session & MySQL support)
- Metronome DB Host
- MySQL 4.1.20
- Condor Central Manager Host
- Condor >= 6.8.0 or Condor >= 6.9.0
- Build/Test Execution Hosts
- Condor >= 6.8.0 or Condor >= 6.9.0
- Perl >= 5.005
Special Feature Requirements
- For Cross-Facility Job Migration: Condor >= 6.8.0
- For Parallel jobs: Condor >= 6.9.0 on central manager, submit and execute hosts.
Metronome 2.4.0
This is a stable release of Metronome. It contains only new bug fixes or new platform support.
Download
Release Date: 2007-08-30
MD5 checksum: 1c2fb3ea8fed3626760ad644fb98ae15
MD5 checksum: 42775e9de4e14c26378077ff0e11c4bf
Release Notes
None.
New Features
- Metronome now supports the Sony PlayStation 3 platform (requires Condor 6.9.4+)
Bugs Fixed
- The web status pages’ pool statistics sidebar now correctly reports the total number of Condor CPU Slots in the pool, instead of incorrectly reporting the number of hosts.
- The web status pages once again report prereq information. Additionally, many small bugs in the sorting of various related tables have been eliminated.
- Pinned runs whose pins have expired no longer display the pinned icon in the runs overview page.
nmi_rmno longer throws a spurious Perl warning.
nmi_condor_qhandles remote (migrated) jobs better.
Known Bugs
- Automatic email notification of run completion is broken in 2.4.0; it will be fixed in 2.4.1, but to fix it by hand in the meantime, simply edit line 15 of notify.pl. The broken line reads:
use lib $ENV{'NMI_LIB'} || "/usr/local/nmi-2.2.7/lib";Just change the path at the end to be your installation’s actual NMI lib/ directory, and email notification will once again work.
- View all Metronome bugs, as of the current release.
Requirements
- Metronome Submit/Archive Host
- Condor >= 6.8.0 or Condor >= 6.9.0
- Perl >= 5.005 (including DBI and DBD::mysql modules)
- Apache >= 2.0
- PHP >= 4.2.3 (i.e, with Session & MySQL support)
- Metronome DB Host
- MySQL 4.1.20
- Condor Central Manager Host
- Condor >= 6.8.0 or Condor >= 6.9.0
- Build/Test Execution Hosts
- Condor >= 6.8.0 or Condor >= 6.9.0
- Perl >= 5.005
Special Feature Requirements
- For Cross-Facility Job Migration: Condor >= 6.8.0
- For Parallel jobs: Condor >= 6.9.0 on central manager, submit and execute hosts.
WARNING_PAGE
This is the file that is loaded to display warning messages in the web interface. It is not advised to change this parameter.
define('WARNING_PAGE', 'msgs/warning');
SESSION_NAME
The cookie name used for the web sessions. You can change this if you would like to have multiple Metronome installations within the same domain.
define('SESSION_NAME', 'MetronomeSessID');
NMI serial console scripts (node-reboot, node-console)
the scripts are located in /usr/local/bin on nmi-net
they use config files in /usr/local/condor/admin – this is where to add new machines/serial consoles
