Computers: July 2005 Archives
Last week, Rushabh started poking me about enabling SSL on redefine's webserver, so that we could post to our blogs securely. This has been on my TODO list for awhile, so I decided to start down this long, dark road on Saturday. After decoding much of the SSL certificate generation and Apache configuration crap that I needed to go through, I found out that the version of Apache that I was running didn't have SSL support compiled into it.
Drat.
So today, I uninstalled my old apache, and installed a new one that had mod_ssl compiled in. At first, everything was going swimmingly. I got Apache to agree that my new SSL-enabled config file was okay, and then restarted it. All was well, but SSL didn't work. I found that I had to use the 'startssl' instead of the 'start' parameter. And of course, after I figured that out, all hell broke loose.
To make a long story short, first apache wouldn't start. Some googling told me that mod_ssl rejiggers Apache's internal API, requiring all modules to be re-compiled. Great. After a tense half hour comprised of a lot of hacking (and apache getting random bus errors later), I managed to recompile all of the PHP crap, and now things appear to be stable.
whew
-Andy.
The focus of this talk is on improving incident management, more for resource failures than end-user requests. Focus of this talk is on SIM. In the past, auto-generated tickets haven't been correlated, and there has been duplicate tickets submitted by users. Technology of Event Manager and Help Desk is advanced that it is worth another shot. Help Desk has more automation capabilities, Event Managers more dynamic.
Central issue is that alerts say what physical resource is broken, not what service is affected. Not possible to automatically notify users.
Solution: In the CS tradition, insert another layer in between EM and Help Desk. This is SIM (Service Impact Manager). Event Management can reduce event flow (filtering, duplicate detection, enrichment, etc.). Correlation not required by SIM model. Needs work to define service model -- can use discovery to determine infrastructure & some config/topology, but need to define actual user-preceived services by hand. Can do master/child tickets automatically. List of services affected in ticket can be dynamic (as additional services go down or get fixed).
IDEA: event suppression? Change tickets that you cut in HD could have CI information in them, and that could then flow into EM, to automatically suppress alerts during change.
My summary: The idea of a SIM seems like a reasonable one. I didn't get a lot of details about BMC's product, so I can't say if that is something that I would want to see in our environment or not. But I think that there is a lot of potential in the EM/SIM/HD combo for doing automation (which is my bread and butter at EDS).
- requires business awareness and context across IT silos
- tools need service centric view instead of infrastructure centric
- ability to manage business services across entire IT infrastructure
- CMDB
- Shared service model
- Dashboards
- Open foundation for information sharing and process collaboration across BMC products and 3rd party solutions
- shared data repository, common user interface
- CMDB (Core BSM Data)
- Service model (business relevance) (Core BSM Data)
- web services and data access (common data abstraction layer)
- reporting -- aggregates (presentation layer)
- view -- management dashboards (presentation layer)
- Provide Service Model Editor (operates on CMDB -- where model is stored?), API for accessing Service Model
- Examples: SLAs, Change Management (determine which components affected are part of business service), asset management from service perspective
- In order to get Service Model Editor, have to buy SIM (today)
- SIM maps incoming events to service model, and correlates to CI
Automatic upgrades are possible, but there are some manual steps, and care must be taken.
The merge problem:
* original app -> vendor new version -> |-> my updates to app -> NEW MERGED VERSION
- How do you make it so that to independent teams making changes, don't conflict with each other?
- Decide whether modification is really needed?
- Keep an eye on where development is going (vender and internal)
- Plan and follow process during upgrade
- Test and resolve conflicts
- Important to the business, or just legacy?
- Is it an add-on or built-in to the application?
- Add-ons generally safe, built-in is intrinsic to application, much trickier
- Know vision and direction of the application supplier
- consider the philosophy of the application
- more likely to be compatible as upgrades happen
- Develop a vision and direction around the application
- Do not repurpose fields (OK to add fields; OK to use existing fields for intended purpose; DON'T arbitrarily re-purpose fields)
- Do not change existing workflow (OK to add workflow; OK to copy existing workflow and change the copy [pick different name prefix]; OK to disable existing workflow [upgrade will re-enable] - only change allowed
- Do not change permissions (Add new groups/permissions, don't touch BMC's)
- All fields and VUIs of BMC forms will have IDS in reserved range
- During upgrade, will not modify or delete any field that is not a BMC field
- BMC is free to change definitions of fields they own (OK to add new groups and permissions; don't modify perms on BMC's groups)
- During upgrade will not modify or delete any workflow that is not BMC's
- BMC free to modify its own workflow in existing way
- generate an export file of all definitions in the AR system server
- can also backup at database level
- Available from developer site
- makes list of all disabled workflow (will need later)
- Helps you find what needs to be re-disabled after upgrade
- Run in import mode to do re-disabling for you
- records all permissions for your groups
- creates a file containing a list of all workflow/fields/forms in the system and the permissions assigned for specific groups
- developer community (soon)
- Restore disabled forms and permissions
- Restore views (which were exported before-hand) -- note that new fields will not show on view, and will have to be added manually
- History/change data will be preserved
- direct modifications to factory definitions, make again
- modified qualifications of any application table fields need to be restored
- you need to run a suite of tests for the application after the upgrade
I am attending the last day of the Remedy User Group (RUG) conference today. Much like I did for JavaOne, I plan to blog about each session that I attend. So, to all of my non-nerd readers: you have been warned.
-Andy.
So, I've been using iPhoto to manage my pictures ever since I got my first mac. And while I'm not always happy with it, iPhoto does allow me to at least keep track of the pictures that I'm taking with a minimal amount of effort. iPhoto really falls down when you want to export your photos to the web. I don't have .Mac, so the only other option is some canned HTML that looks kindof funky.
So, I have been using Gallery to fulfill my pictures-on-the-web needs for some time now. However, one pain point has been getting my photos from iPhoto into Gallery. Basically, I have been doing a lot of manual effort, which has consisted of exporting pictures from iPhoto, scp'ing them to my server, then manually importing them into Gallery. The whole process is slow, repetitive, and generally sucks.
I had been thinking about trying to make things easier via Automator, when I stumbled across the free iPhotoToGallery software. This software does exactly what I want -- it provides an easy-to-use interface for exporting my photos directly from iPhoto to Gallery, without any of the annoying pain in-between. It seems like this software is a little rough around the edges, but so far, it has been working for me.
To celebrate, I have posted two new galleries of pictures: July 4th pictures from Chicago, and pictures from my trip to Antioch last Friday.
-Andy.