The Energy Efficiency and Monitoring services (wake-on-lan and power management monitoring) are delivered to University networks by "EEM gateways". Each University network on which EEM services are to be offered must be connected to a gateway, but each gateway can serve multiple networks (physical, logical, and virtual). This means that typical units will only need a single EEM gateway, regardless of the number of separate physical networks, IP subnets, and virtual networks (virtual infrastructure networks and/or VLANs).
This document provides first-time installation instructions for local ITSS wishing to set up an EEM gateway on one or more networks. A typical set up can be completed in under a day.
2. Installation Procedure - Fully Managed
Gateway FQDN is the FQDN of
the gateway on your network - you will need to
register this DNS nameGateway subnet maskis the
subnet mask for the EEM gateway's IP
configurationGateway router addressis
the EEM gateway's local routerContact email is an email
address that we can use to contact the
appropriate person if there is a problem with
the gatewayNetwork
sections, with a friendly name, define the
networks that this gateway should monitor. The
friendly name will be used to identify the
network to users on the PMM graphs.VLAN is the VLAN on which
the network is connected, or None
if VLAN tagging is not used for this
networkUnits is a list of units
whose members can view PMM graphs for this
network (useful if you want to share your data
with other units)Publish specifies whether
PMM data should be available for public
viewingOnce your request has been received, OUCS will contact you to arrange a convenient installation date.
3. Installation Procedure - Part Managed
3.1. Vanilla Debian (squeeze) install
Please note that, as the system configuration of this host will be fully managed by OUCS, we strongly recommend that a fresh host is used, dedicated for EEM, and not used for any other purpose.
Gateway FQDN is the FQDN of the gateway on your networkITSS Managers is a list of the /itss principals of ITSS who will be setting up / managing the gateway.Contact email is an email address that we can use to contact the appropriate person if there is a problem with the gatewayNetwork sections, with a friendly name, define the networks that this gateway should monitor. The friendly name will be used to identify the network to users on the PMM graphs.Interface is the Ethernet interface that this network is connected to on the gateway. For simple setups this will usually be eth0. VLANs must be specified individually in the ethX.VLAN format.Units is a list of units whose members can view PMM graphs for this network (useful if you want to share your data with other units)Publish specifies whether PMM data should be available for public viewingOnce you have sent in your registration, please wait until sysdev has processed this and replied to you before continuing with the next step.
Visit https://eem.ox.ac.uk/ from a workstation that has not previously been registered with the EEM service, and select .
This should take you to a registration page with the MAC address for the workstation auto-completed. Other fields may also have been completed for you. Complete the registration.
Power down the machine you registered above, and visit https://eem.ox.ac.uk/ from another workstation. Select and click on the button for the registered workstation.
This should send a wake-up call to the registered workstation within a few seconds, and the workstation should start to boot.
Back at https://eem.ox.ac.uk/, select and configure a schedule for the registered workstation (choosing a wake-up time around 10 minutes in the future is suitable for a quick test). Power down the workstation to be woken-up.
This should cause a wake-up call to be sent to the registered workstation at the scheduled time, and the workstation should boot.
Visit https://eem.ox.ac.uk/cgi-webauth/graphs.cgi.
You should see energy usage charts for all networks that you are authorised to view - including those that your gateway supports. Charts are generated once an hour, so you may need to wait a bit before the first set are ready for display.
5.1. Can I run EEM on other Linux flavours than Debian?
The EEM system is developed for the Debian GNU/Linux operating system as target platform and we do not support other Linux distributions.
The Debian installation manual provides comprehensive guidance for anyone who is not already familiar with installing Debian GNU/Linux.
5.3. How do I configure VLANs in Debian?
/etc/network/interfaces, for example
the following sample configures 3 VLANs on the first Ethernet interface (eth0), where
VLAN 13 is used to provide host connectivity to the outside world (note that you do not need to
specify IP addresses for all interfaces - only the one that will be used to contact the gateway):
5.4. What is a /itss principal and how do I set one up?
Oxford SSO accounts include a Kerberos principal that can be used for authentication - to prove
your identity. Normal SSO accounts are based on a "simple" principal of the form
unit9999@OX.AC.UK - the first part is often referred
to as the Oxford username. These accounts are used for a wide variety of purposes, and the
account password is likely to be used in a number of situations where convenience is preferred
over security.
For certain administrative IT activities, such as establishing server-to-server trust, a higher
level of security is required than can be assumed for most SSO accounts. OUCS therefore issues
a separate set of credentials to ITSS who need this facility. For consistency and ease of
remembering, the principal is based on the usual SSO username, taking the form
unit9999/itss@OX.AC.UK. The password constraints on these
accounts are more stringent as well, requiring a minimum of 8 characters. /itss
accounts can be managed in the same way as a normal SSO account, through the
Webauth account management pages.
Registered ITSS can request a /itss principal by email to sysdev@oucs.ox.ac.uk. In
order to set a password on this account you will typically need to visit OUCS with your University
Card as photographic identification, although we can send temporary passwords encrypted with GPG
where we already have trusted keys for the relevant recipient.
5.5. Who is responsible for maintaining the gateway once it is installed?
Responsibility for maintenance is shared between yourself and OUCS. Under normal circumstances OUCS will ensure that updates to the installed Debian release are applied expediently, and will manage the system configuration. You should maintain the infrastructure (physical or virtual), environment, and network connectivity.
OUCS will endeavour to identify and resolve minor platform issues if/when they arise. If a problem cannot be resolved then you may need to reinstall the gateway using the instructions above. EEM gateways are not backed up as the only data that could be lost are the recent observations of active devices.
Upgrading to future Debian releases is expected to be the responsibility of local ITSS, carried out by way of a new installation / full reinstallation. This has not yet been explored or tested however, and a more lightweight upgrade option may become available.
5.6. What if I am not able to provide a suitable platform?
Some people may not have the infrastructure, resources, capabilities, or authorisation to meet the requirements set out above to run their own part managed EEM gateway. Therefore you can request a fully managed gateway provided by OUCS free of charge.
5.7. Why don't you make krb5-user a dependency of eem-gateway-oxford?
The main reason is that krb5-user on its own is not enough - you also need proper configuration in
/etc/krb5.conf. The eem-configure step will do both things for you, which is
why it comes before the kadmin step in the installation instructions.
5.8. Does EEM work with Cisco VMPS / dynamic VLANs?
No. EEM is perfectly capable of being used on VLANs, and even of waking up hosts that move from one VLAN to another, and works well with systems such as the Bradford Campus Manager. However, Cisco's VMPS DVLAN solution actually marks as "inactive" any managed switch ports that have not seen traffic from the connected device for a given period of time, and will not forward any further network packets on that port. This means that when a computer is turned off, the switch port is marked "inactive" and the switch will not send the wake-on-LAN magic packet to the target host.
The Cisco support forms include a ticket about this issue, available at https://supportforums.cisco.com/thread/15213