Home

Workstation Widget Concept (submitted by jnoah)

Using ruby's Net::SSH, the widget, every 15min or so, will ssh to a workstation and run the command 'w.'

• ssh'ing fails, the workstation name is shown in red implying an inability to connect
• ssh'ing succeeds, :[,...] is listed in green
  • This is acheived by shelling out and running 'w'

Another concept (submitted by mathuin)

What should the widget look like?

• The widget should be square with a background color dependent upon the state of the system. The foreground color should be easily readable and have high contrast with all background colors -- this probably means white or black, but the foreground color may change when the background color changes. At a minimum, the following states should be considered:

  • Unreachable/powered-off
  • Powered on but nobody logged in
  • Someone logged in remotely but nobody logged in on console
  • Someone logged in on console but screen is locked
  • Someone logged in on console but screen is unlocked and they are idle
  • Someone logged in on console but screen is unlocked and they are unidle

• The widget should contain a set of center-aligned strings (large/very-small/small font sizes):

  • The name of the workstation in large
  • The IP of the workstation in very small and wrapped in parentheses
  • A small amount of vertical space
  • The username of whoever is logged in on console, or another string like 'Available!'
  • The amount of time said user has been idle, in small
  • A small amount of vertical space
  • Load numbers in small, possibly also in parentheses

How could the widget work?

• The daemon approach

  • How?

      * The widget would poll a daemon running on each workstation.
      * The daemon would collect relevant information and generate a JSON file.
      * This JSON file would be versioned, with the version updated as the data changes.
      * The JSON file would include per-pty information plus load average.
      * The widget would then poll the daemon every minute or so, retrieving the JSON if it has changed, and then update its display accordingly.
    

  • Pros:

      * JSON file contains exactly what fenestra expects and needs, nothing more.
      * Privilege escalation kept to bare minimum -- all code runs in user space.
      * Push notifications possible!
    

  • Cons:

      * Additional code outside fenestra must be written, maintained, and installed by ops on all workstations.
    

• The SSH approach

  • How?

      * The widget would access each workstation via SSH.
      * It would then run 'w' (and possibly other commands) and scrape their output to retrieve the relevant information.
      * The widget would then update its display accordingly.
    

  • Pros:

      * No additional packages for ops to maintain.
    

  • Cons:

      * Requires a new account on all workstations configured to only run certain commands when accessed via ssh.
      * Requires screen-scraping, which can be fragile.
      * SSH connections are not lightweight.