New Domains

June 22, 2006

I’ve established a web hosting account with DreamHost. It will be a place to at least develop and test new prjects. Hopefully it will work out as a place to host projects in production as well.

These are the anticipated URLs:

http://www.287tools.org – main page

manage.287tools.org – project management page, running subversion and perhaps trac

cwgriesel.287tools.org – future home of this wordpress blog, and model for other 287 personal blogs

http://www.287tools.org/share – 287 Sharing and re-use project

http://www.287tools.org/mileage – 287 mileage reimbursement project

http://www.287tools.org/incentive – student incentive program

http://www.287tools.org/ebooks – ebook download service

new.287tools.org – perhaps a place to generate new databases from templates

Advertisements

Problems with OSX server in AD environment

June 15, 2006

I can easily set up an OSX server to handle file services for my Mac machines. But here are the problems I see with doing that in our current Active Directoroy environment.

  1. Seperate logins – no directory integration
  2. OSX file system is not backed up and not on SAN

That being said, there are some challenges that need to be addressed if I am not going to use the OSX server

  1. Automatically syncronize local hard disk with server
    1. bind mac to AD
    2. do the following at login
    3. mount shared volumes
    4. at logoff, sync desktop changes with server and delete desktop files
  2. Syncronize laptops with server
    1. similar to desktops, but first time machine is used, ask if it is a laptop.  If it is, copy entire contents of desktop folder to laptop

Sharing tasks via RSS

June 15, 2006

I would like some way to easily publish my current tasks via RSS, so I can share them with others.  Maybe maintaining a parallel task list in TaDa is one way to do it.

Tracking Projects with TrackIT

June 15, 2006

Each project will consist of one main task that defines the project, then multiple sub-tasks for each part of the project.  The main task will be have "Project" as the first word in the title.

There are some reports that will be needed

1) The number of hours worked by a person in one day – to help worker organize their daily activity.

2) The number of hours worked by a person in one week – to fill in time cards.

3) The number of hours applied to one project in any period of time – to manage project.

4) The total number of hours ever applied to one project – to manage project. 

Project Management Problem

June 15, 2006

 

It is currently very difficult to get a clear report on the number of hours spent on projects within the district. Also, it is difficult to manage the assignment of tasks to individuals and report when the tasks are completed. This is especially true in the realm of computer support where our tasks are so varied and work is done simultaneously for many people across the district.

 

Our new inventory and helpdesk software, TrackIT, has the potential of resolving these project management needs. It has the ability to define projects, define tasks, assign tasks to individuals, and track the hours spend on each task. What is missing is clear instructions on how to combine all of those pieces into the management of a complete project. Also, there are some reporting needs that are not currently provided.

This project will document how to use TrackIT for project management and will build the reports needed to do effective project management with TrackIT. The goal is an easy way to get full accounting for time spent on individual projects.

Macintosh Integration

June 15, 2006

Goal: full integration of Macintosh computers into our information technology infrastructure.

Specific issues to address:

1) Automatic update of software

· Most of our Macintosh computers haven’t had critical updates installed for almost one year.

2) Remote control of computer

· More that half of helpdesk requests could be resolved quickly if a technician could control the local computer from a distance.

3) Lack of easy access to file server

· Files are at great risk of being lost, and are difficult to share with others, when they are stored on the local computer rather than on our district file server.

4) Lack of central authentication.

· Using central authentication will greatly simplify the ability of people to log into various computers and retrieve their work.

5) Lack of web browser support for key functions

· Inability to spell-check email and inability to share and manage bookmarks are key gaps that exist.

Tier 1 Group 2006 Recap

June 14, 2006

We've just wrapped up the 2005-06 school year.  This year saw the Tier 1 starting to gel as a more cohesive group.  The computer system upgrade over the last year required us all to work together on a common project, and work toward common computer standards for all of our users.  Tier 1s began to meet as a group to 1) work on our PLC project 2) discuss IT needs in the district 3) learn about web development with the District's new Accrisoft software.  I'm sure next year will see more opportunities for Tier 1s to work together as a team.

School Technology Infrastructure

May 4, 2006

I’ve started compiling what I hope will be a comprehensive list of the essential elements of a school information technology infrastruction. This is very much a work in progress, compiled by reviewing the technology plans of various schools and unerversities.  I’ll start by summarizing the strategic IT plan of Stanford University, found at http://www.stanford.edu/dept/its/vision

Basic Infrastructure

  • Authentication
  • Authorization
  • Backup
  • Calendar
  • Desktop Management
  • Directory
  • Email
  • Identity Management
  • Integration
  • Printing
  • Storage
  • Voice
  • WWW Services
  • Windows Infrastructure

Let’s describe each one at a time:

Authentication

The goal of an authentication system is to provide a highly stable, centrally administered authentication service both for internal use by IT Services and for use by any and all campus systems that need to authenticate the population of users affiliated with Stanford. We must attempt to balance the following concerns:

  • A set of systems capable of handling the full authentication volume of all university business, tied into university-established notions of identity from the student and HR systems as well as sponsored and guest accounts, and able to centrally handle in a timely fashion withdrawal of authentication capability to terminated employees or abusive users.
  • Use of industry-standard and vendor-supported authentication technology to ease integration with vendor applications and software developed elsewhere while avoiding locking ourselves into any one vendor.
  • A highly secure authentication system that will be able to meet security concerns going forward. The authentication system must never be the weak point in the security of an application and must be sufficient to comply with regulatory restrictions such as HIPAA.
  • Users must be able to authenticate via hosts other than their normal desktops, including mobile devices in the future.
  • Authentication should be external to applications so that authentication mechanisms can be updated or changed to reflect changing requirements without requiring significant application development or surgery.
  • Authentication should be mutual, allowing clients to confirm the identity of the server as well as allowing the server to confirm the identity of the client. This will assist in preventing phishing and man-in-the-middle attacks.

Given the prevalence of the web as a user interface to applications, a trend which is expected to continue, special attention should be paid to standardized web authentication as the place that the most users will interact with the authentication system.

When possible, we will push for the ideal of never letting a user’s authenticator leave their local system under their physical control. This means using network authentication protocols based on a local identity cache rather than sending a password or passphrase to a server for verification. However, we must recognize that there is very little vendor support for such authentication systems at present, particularly in common desktop clients, and most software is still stuck on the model of verifying a password on the server. When it is necessary to send an authenticator to a server, that conversation must always be encrypted. (In other words, the network link shall not be trusted.)

All Stanford users will have to interact with the authentication system to do their daily work. In addition, all application developers and system administrators on campus, inside ITSS and out, represent a key audience for our authentication strategy. If we do not meet their needs, they will develop their own separate authentication systems, which both harms our ability to centrally manage authentication and hurts the consistency of the user experience. The goal is to get as close to universal use of the central authentication services as possible.

The authentication system will be closely tied to any campus identity management or authorization systems, and therefore will be directly affected by any projects in those areas even if those projects are not authentication projects directly.

Enterprise Applications

  • Student Information Systems – enrollment, grade tracking, attendance
  • Business Information Systems – Payroll, Budget, Purchasing, Finance
  • Transportation Management
  • Foodservice Management
  • Library Automation
  • Special Education Management
  • Course Management – authoring, testing, assignments

Project Development Process

April 28, 2006

There are many ways to describe the project development process. But in the interest of keeping things simple, I distill my project development process into three clear steps:

1) Define – Identify the need and dream about ideal solution.  Set clear boundaries on scope and timeline of project.

2) Develop – Build a solution.

3) Deliver – Put the solution into action, then go back to 1) to make it better.

For all of my projects I will try to provide clear, if sometimes brief, documentation for each of these key steps — Define, Develop, Deliver.

Web Filter Requests — A Story

April 28, 2006

We need some way to quickly process requests to have our web filter adjusted.  These can be requests to block or unblock sites.  Often the requester needs a response quickly — ideally within a day.  But blocking and unblocking can have unintented consequences, affecting other people who were depending on the site whose status is changing.  Because of these potential unintended consequences we have set up a committee to review these requests, and given them one week to make a decision on each request.  However, one week is far too slow from most requesters point of view.  What is needed is a faster way for committee members to review requests and vote up or down.

Here is how it could work.  The goal is to get a resolution, either approve or deny, within one work day of the request.

  1. the request is mailed to the filter committee mail list 
  2. committee members have one work day to review the request and vote either up or down.
  3. any committee member who does not resond within 24 hours forfeits their vote.
  4. committee members who do vote have must work out their differences and arrive at some consensus via email discussion about what course of action to take.
  5. committe decision is communicated to filter administrator within one work day of original request.