If you are a fire marshall, building inspector, or hold a similar
position, please skip this post. I received an email from the
office manager explaining that she and several others had gotten trapped
in the bathroom hallway ealier in the day and asking me if I could do
anything about it.
Background: The company I work for shares the bottom floor
of a building with another tenant. The bathrooms are in a T shaped
hallway between the two suites. An interesting property of this
hallway, is that when you enter the hallway, you get locked into the
hallway and need either a keycode (to get into the other suite) or a
security card (to get into our suite). There is an
emergency release (looks like a fire alarm, only it's
yellow) next to the door into our suite.
Now you might be wondering why, what sounds like a facilities problem
was being brought to the attention of IT. She assumed that there was
something wrong with the card reader and thus we needed to fix it since
we manage the security system. This was my first chance to seriously
poke about at the computer running the alarm and keycard system.
Unfortunately I found nothing wrong. So off to investigate the door I
went.
It took me about five minutes to work out the problem. The card
reader was indeed reading each and every swipe of a card, and you could
always hear a noise from the lock mechanism. What was odd however was
that the lock mechanism made two different noises. One when the lock
actually opened properly, and another when it didn't. It was pretty
clear that that the solenoid that released
the lock and allowed the door to open was not working correctly;
probably sticking at times.
It was as I stood there experimenting with the door that the office
manager came and explained how the emergency release was supposed to
work. After activating the emergency release a few times, it became
quiet clear however that this release sends the same electrical signal
to the lock as the card reader, and thus if the problem is with the lock
itself, the emergency release won't actually let you out of the hallway.
Before this experience, I was under the impression that the reference
implementation of NTP by the NTP
Project was the bees knees. I have since come to have a very
different opinion of the program. It all started with the need to
setup a pair of NTP servers.
First off I needed to get the correct time on the servers. After
changing the default server entries from the global pool.ntp.org entries
to the country specific us.pool.ntp.org and adding entries to the
step-tickers file (this enables the init script for ntpd to specifically
set the time from the listed servers upon daemon startup. Why exactly
isn't this the default?) I had the correct time on my servers. This
step was easy enough.
Next, I had to get the server to accept requests from other machines
on the network. Redhat kindly commented up ntp.conf. The
relevant section is;
# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service. Do not permit those systems to modify the
# configuration of this service. Also, do not use those
# systems as peers for synchronization.
# restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
Wait a minute, to allow a network to request time from the server, I
start a line with restrict? You have got to be kidding me.
Anyway, I make the change to make it applicable to the network, and from
another machine, queried the server for the time. The request was not
met with an answer that pleased me though.
[root@server ~]# ntpdate -q 192.168.0.1
server 192.168.0.1, stratum 0, offset 0.000000, delay 0.00000
2 Sep 22:27:26 ntpdate[2674]: no server suitable for synchronization
found
Which leads to perhaps the biggest problem with the project: some of
the worst documentation I have encountered. You can't blame them for
lack of documentation.
They have lots of documentation. Lots and
lots of
documentation. That is really the problem. I can assure the authors of
all that written material that very very few people care about the
gritty details of how NTP works. People just want a simple,
straight-forward, and reliable way to get sub second accurate time on
all of their machines.
I spent nearly four hours reading nearly all of that documentation.
I not only found the answer to my problem; ntpd won't respond to
requests for time until it is confident that it has the accurate time,
which takes a few minutes after each restart of the daemon. In the end,
I found that someone had already gone through the pain of working out
the correct config for ntp.conf and Redhat ships that nicely
documented config that will work for the majority of administrators.
After all of this, I am left with the feeling that there has got to
be a simpler and more straightforward ntp daemon. Thankfully, there are
indeed alternatives to the reference implementation of NTP. There is Chrony, or OpenNTPD from the fine OpenBSD
group. I have begun using the later at home. Next time I need to solve
this problem at work, perhaps I will move away from the reference
implementation.
We were expanding into a new building and I was tasked with setting
up the new conference rooms so that they could be scheduled through
Outlook/Exchange. I recall from many years ago that there was much
idiocy to setting up such things, so I asked the interweb for
assistance.
Early in my searches I came across a page from Microsoft TechNet
entitled Set
Up a Conference Room as an Outlook 2000 Resource (another set of
instructions doing the same thing is here). I
followed the instructions (Ignoring how silly it is to need to create a
profile in Outlook for each resource you wish to manage) and surprise
surprise it works. Great, on to test it with Evolution and the Exchange
Connector. Nope, it doesn't work. But clearly it should work from
the Outlook Web Interface provided by the Exchange Server, right? Hmmm,
no that doesn't work there either.
I guess the page was serious with the prerequisite of "You must be
using Microsoft Outlook 2000 and Microsoft Exchange Server 5.5." Further
investigation confirms that that solution only works when using
Outlook 2000 or greater as the client to setup the meeting. More info
here
(note Windows IT Pro magazine subscription required to access).
Still further investigation yields an interesting page entitled Scheduling
Resources for Microsoft Outlook that says that there are two primary
ways to allow Outlook users to schedule shared resources automatically.
1) setup each resource as an Exchange Server mailbox and do various bits
of trickery to make it auto accept meeting requests or 2) create a
public folder that holds appointment items and allow various groups of
users permission to read and write to it.
In the end I find that the conference rooms we already have in our
Exchange system were implemented using the first option with a tool
called the Microsoft
Exchange Server Auto Accept Agent (download
here. I created new users (this does of course use up a CAL)
to represent each of the new conference rooms, setup Outlook profiles
for each so I could change permissions on the new calendars, and
finally, using the command line VB scripts from the Auto Accept Agent,
added the new conference rooms to the monitored mailboxes list.
The Auto Accept Agent basically snags incoming meeting requests to
registered mailboxes and processes them based on criteria (if the room
is available, if the event is in the future, etc.). Registering
mailboxes to check is done through a trio of command line VB scripts.
Managing the behavior is done through editing an xml file. Another more
full featured option (which I would have used had MS's solution not
already been configured on the server) appears to be the open source AutoAccept Sink for
Exchange
The sad part, is that about half way through the day (about the time
I learned that Outlook and the Outlook Web Interface behaved
differently) I took a break from fighting with Exchange and Outlook and
voluntarily went to read the Sun Grid Enginedocumentation.
When a product is so frustratingly annoying that I voluntarily go to
read a very very dull manual to take a break, there is clearly something
wrong.
