Perspective matters. Particularly when you're not terribly sure which way you are heading.

Around this time last year, I had been in up to my neck dealing with a messy repair job at work. Every day my team and I had to work with issues revolving  The Tickler, The Reacharound, and The Dumptruck. No, this isn’t some unsavory gay porno I’m talking about… these are real project names we have given to various software components of a fairly complex job. Specifically, these are the functional pieces of a physical access control system that we use at work which needed some significant tuning.

By now, if you’re still reading this you are probably involved in some capacity with the access control or security industry. Thanks for sticking around. I will try to make this whole rant of mine worth your time.

In hindsight, I really wish we had just taken the plunge to be rid of this particular system completely and started over from scratch. It really has been nothing more than a headache for us, but at least I’ve learned a quite a few things about access control and physical ID card production. So here I am sharing these valuable nuggets of information to you, at no cost whatsoever… except that if you find them useful, you owe me a beer (or two). I’m not a heavy drinker. I promise.

…access control functionality is a rather mature feature set, and everyone at this point is supposed to be doing it right… but you would be surprised because some vendors still get it horribly wrong.

I had though long and hard about making any comments about this sort of thing publicly. But after having been asked why I had locked myself in a cage for many months last year, it seemed like a good time to vent a little bit and share some of the mistakes we made so that others can’t make them. This is part of the coolness of working at a university. I wouldn’t dare discuss these sort of issues in the open otherwise, if this was corporate America.

So here goes. I broke these tips down in pieces for you:

Card Production

• Wear Your Overcoat. If you use ribbon printers (Fargo, MagiCard, Zebra, Evolis, etc), don’t cheap out and avoid using an overcoat. You will be left with ID cards which will wear the hell out and look like garbage within the space of a few months. Spend the extra dough and use a proper overcoat. In the words of the great Mister T… “I pity the fool who wants to be a cheap bastard”… or something like that.
• Tune Your Oven. When you use a printer that supports overcoats, you must properly tune it. This isn’t just some fire-and-forget solution… you need to find the proper temperature that the overcoat likes to be applied to the card. Too hot, and the card warps. Too cold, and the overcoat doesn’t bond properly. These printers can be like petulant little electric toasters rather than the grand pizza ovens that their vendors advertise them as. They require occasional inspection and maintenance in order to minimize errors during printing.
• Automating RFID Input Fail. Automated RFID/HID tag reading is one of those things that a good number of the smaller access control software vendors advertise – “It’s all automatic!”… and you will have to accept  that this process will most often not work properly at all. This is one feature which is bullshat around the most. Be prepared to enter these values in by hand. Someone’s going to have to do it.
• Strip Permissions Out. Proper delegation. You DO NOT want your card production staff to have the ability to change access control groups or to do ANY of that sort of thing. Why? It’s not about trust. It’s about accountability. Make it easier for everyone and don’t let them have that burden/responsibility. Make sure your production environment makes it impossible for them to do anything other than perhaps correcting typos of a person’s name, or editing data that they would only use, such as barcodes or magstripe data. They and everyone else will thank you in the long run for it.

Access Control Software/Hardware

• Core Access Control Functionality Is Easy-Peasy. For every big vendor like Lenel, AMAG, Software House, or S2, there are are a bunch of smaller companies who eke out a living building accordingly smaller software packages. There is nothing wrong with that. However access control functionality is a rather mature feature set, and everyone at this point is supposed to be doing it right… but you would be surprised because some vendors still get it horribly wrong. In other words what I am saying is that while it may not be as simple a procedure as boiling water- a vendor better not totally fuck shit up when it comes to making doors open when a proper card is presented to them. So if you are stuck with a system which requires you to constantly restart intelligent controllers or door modules… or has trouble updating cardholder state changes across the system… you had best kick them to the curb and find someone else who can do this sort of thing properly.
• Scalability Blah Blahblahblah. Unfortunately the refrain is similar to above. A lot of the smaller vendors simply don’t have this functionality done properly. What works well when you are a single building with less than a hundred card readers, and a fixed population will most likely turn into a vat of boiling vomit when you double or quadruple the cardholder population. There are some things which simply can’t be reproduced in a lab environment. When talking to a vendor, get their references and seriously grill them. Ask these references what sort of problems they encountered with scaling up, and home in on the usual suspect issues… such as server requirements, hardware costs, additional feature costs, and the reliability of each additional component when added to the system as a whole. Do your homework and do not be afraid to dig in.
• System Monitoring… Don’t Underestimate It. Make sure you have some way to monitor your smart controllers. Industry standard stuff like SNMP would be nice, but most of them don’t support it, so you are left with the only option of ping monitoring. This is complicated by a lot of the controllers having Ethernet/TCP/IP support as an afterthought, with their roots from RS-485 or similar serial connections, so the Ethernet module might fail, but the underlying controller will resume functionality.
• Go Heavy On Smart Controller RAM. There is a temptation to cheap out on the memory available for transactions or card data for your smart controllers- in particular the ones you will regard as being low-traffic. Don’t do it. You will be doing yourself a huge disservice. Think about what happens if access to a set of readers changes because of a department move, and suddenly many more people need access to a set of doorways. Understand that many vendors do not have truly drop-and-replace system boards… they will need to be reprogrammed and one of the side effects to that is system downtime. We all know how pissed of people can be if they can’t access their corporate computing resources. Now think of what happens if you deny them access to their bathroom doors.
• Proprietary Schmoprietary. Some of the intelligent controllers available on the market allow you to run any vendor’s software on them. Of course this is used as a selling point. Guess what though… just like any other technology, you can get royally screwed by this. The caveat usually falls in line with… “Oh, you can run our new software on these boards… but you would have to have the latest version of the board to do it”. Sound familiar? Sure! You can upgrade to Windows Version XXX but your motherboard and CPU are too slow, so you need to upgrade to something newer… The moral of this story is that it really doesn’t matter if a vendor’s hardware is proprietary or open- if you plan on switching vendors with an open system you are going to get screwed in some fashion. As for the war between choosing a proprietary or open system… so long as the damn thing works properly, these sort of issues really falls into oblivion.
• Think Like A Boulder. If rocks and dirt could actually talk… what would they say? Other than expressing displeasure at being buried without anything interesting to look at for hundreds of millions of years, only to be exposed to the elements, perhaps without a good view for hundreds of thousands of years… only to be covered over again by a mudslide or whatnot for another few million years… okay, the point is… you need to take a long term perspective on how long the hardware installation is going to last. Instead of just thinking on three year level, you need to really look further down the road and scale things to the lifetime of the building, or at the very least, the full length term of your lease. You will not be a happy camper if you are faced with the prospect of replacing hardware mounted in door jambs or walls on a frequent basis.
• Don’t Overlook The Installer Selection. Shady installers will underbid their initial installation contracts because they know once they have you locked in, they can charge $$$ for any service related work in the future. Chances are… you will have lots of service work. I think it goes without saying that you cannot simply assume that the installer vendor search is going to be straightforward. This is probably the most critical piece of the whole vendor search process.
• Beware of Mom & Pop Shop Disease. This is mainly applicable to the access control software vendor… but if they are too small of a company, or if the product is run by a single super-intelligent guru (who doubles as a single point of failure), then you need to be careful. Veeeery careful. This is your physical security we are talking about, right?

Well, as abruptly as I started ranting, I will end it. I guess I’ll quit when I’m ahead, right? As a disclaimer, the people at my job who I continue to work with on security related capacities are awesome people, and they know I’m not railing at any of them. If anything they’re probably wondering why I haven’t said anything about this sooner.

Anyhow, this is my attempt to distill my however short involvement with access control and security into some meaningful nuggets of knowledge. I hope they don’t appear like floating poop logs… but even lodged within the poop there are kernels of wisdom. Thanks again for reading.

This topic comes up for me not necessarily as a rant, but as I was going through some old notes before tossing them away, and this issue came up. How much damage can an organization do to themselves by hiring discount, unqualified programming resources?

The answer: A hell of a lot.

If you own a small software development shop, do yourself a huge favor and keep reading.

Stupidity cost us about $250,000 over a 9 month period. Another $250,000 was lost for us in other means.

A previous company that I worked at had a habit of hiring low-cost coding staff to handle production quality servers- Not just any production machines… but the very hardware which was responsible for 100% of the revenue being generated for said company. This makes no sense as their client side programmers were generally top-notch, and among the more creative and competent that I have had the pleasure to work with.

Management also had a habit of protecting these junior staff members voraciously- for various reasons, but mainly economic. A single server-side programmer could cost two or three times more in salary to maintain. Also, some in the management felt that this staff member was a ‘worthy project’ that could become a superstar programmer someday. I mean, it worked for Darko Milicic during his stint with the Pistons, didn’t it?

I calculated that my previous employer definitely cost themselves $250,000 in lost cashmoney over a 9 month period for the mishaps they had in retaining ONE very junior server-side engineering resource. This was absolutely staggering to me. Another $250,000 could easily be accounted for in other means. I’ll get to that in a moment.

The other sources for my numbers are the assumptions that:

1. Yes, this programmer was causing problems nearly EVERY SINGLE DAY.
2. Five client/server development resources were utilized, at $20/hr in wage costs each time a bug needed to be fixed.
3. Eight QA staff were utilized, at $15/hr in wage costs to confirm said bug fix.
4. This underqualified developer introduced one bug per day, which took an average of six hours per bug to fix.
5. This individual worked for a period of 9 months, before finally being axed for causing a systemwide outage of all revenue generating products for a significant part of a business day.
6. Not entirely relevant, but said individual produced on average 15 lines of code per day, with the assumption of 21 working days per month. Vacation time is included in this count because this individual only really took one, and worked some weekends as well – so it all balances out.

The numbers I am leaving out are:

1. Costs to management salaries. The reason for this is twofold- one is that I don’t know how many staff members were involved in back-room decisionmaking each time we suffered downtime events. This ranges from one to four. Who knows…
2. Costs to my productivity. I was a systems admin, so it was my job to support the engineering staff. I had the unique experience of being able to read/understand code, but full well knew that I could not hold a candle to the proper engineers. In a nutshell, I could talk shop with them, and help diagnose problems. I was a bit faster than a plain old sysadmin at doing this. I was a good cheerleader at times. That’s about it.
3. Costs of contractors: During most of this 9 month period, we had consulting/contracting staff on board who had to shift gears to help fix problems on a near-regular basis. I simply did not accurately keep track of how often they had to drop whatever they were doing and scramble to help us.
4. The damage caused by spaghetti code. This is utterly incalculable. Each time new server-side programming staff were added they faced an absolute nightmare of a learning curve.
5. The amount of time lost by production server uptime – According to my notes we were down (and by that I mean not being able to process subscription material) for a period of nine total business days during that 9 month period. To this day I still don’t exactly know how many dollars per hour in transactions were being handled by those servers, so I can’t guess there. I won’t even bother to put a price tag on it, but it is the elephant in the room.

If I really do have to hazard a guess at the total cost of damage over 9 months, then I’ll say that stupidity cost us about USD $500,000 total. There is also the untold damage done to the reputation of the company, as subscribers probably grew tiresome of outages and took their business somewhere else.

How much damage can one incompetent programmer do to an organization? A hell of a lot.

In the end it isn’t my intention to throw anyone under the bus for the mistakes that were made. Guilty parties all know who they are, and to some degree or another, they all paid for it already, so there’s no need to flog that dead horse all over again.

The underqualified individual who boasted of general programming expertise which he did not have faced the prospect of never finding work in a proper engineering environment again. Management who felt they were saving money by having this resource around because of cost-effectiveness are facing the prospect of their entire company going down the tubes because the server-side codebase is nearly unmaintainable, among other things. Those of us who stuck around trying to fix the situation paid for it with a few sleepless nights, and the agony of ‘Heisenbug’ code which was nigh near unpossible to debug or maintain effectively.

I learned many things myself. I used to never document very well. Because of the insanity I was forced to deal with, I feel I have come a long way in that regard. I enjoy documenting now. It’s saved my ass a number of times since then.

Over a year after the staff member was let go, the server programmers were still fixing bugs.

Also, a young and promising programmer who was forced to help debug and manage the fix processes on a regular basis learned a hell of a lot from these failures, and it will serve him tremendously in his career as time goes on. This is the type of education you just can’t get in college. Over a year after the staff member was let go, he was still fixing bugs. The thing is, he’s already bailed on this company and isn’t looking back. If there was someone worth focusing on and making into your future team nucleus… this guy was the one.

What’s done is done, and hopefully dear reader, if you’re in management or if you own a small company, you won’t make the same mistakes that they did. I implore you to hire competent people. Don’t cheap out in that regard. It will cost you a whole lot more than you think.

Warning- this may not be really all that funny unless you are a database administrator or a geek with the right knowledge. This rather silly product I am working with stores its data in the backend via a Microsoft SQL Server database. There’s nothing wrong with that… but on further examination of the schema I found a pretty ridiculous jewel of a table setup. Click on the picture to see the bloody details.

For those not technically inclined- this is precisely NOT how you would utilize a relational database server. It’s poor design, and rather an extreme and laughable example.

Microsoft SQL-DMO (ODBC SQLState:42000)

[Microsoft][ODBC SQL Server Driver][SQL Server] To connect to this server you must use SQL Server Management Studio or SQL Server Management Objects (SMO).

Bonus points if you’re using the Data Transformation Services and are now looking at an error screen similar to this:

Well, I unfortunately don’t have much substantial solutions to offer you. I apologize.

Connectivity MAY work if you use the SQL Native Client (SQLNCLI)  instead  of an OLE DB connection, but this is shaky at times and a much more complicated solution when wrapped into DTS.

If you’re looking to copy entire databases, then look here:

http://blogs.msdn.com/euanga/archive/2006/07/18/668916.aspx

If you’re looking to only pick and choose a few tables at a time, then that’s a different story altogether.

My solution was to use a horrifying transmogrifying method of SQL to CSV and back to SQL again for the few tables that we needed.

I try to be vendor-agnostic when it comes to any sort of IT solutions, but Microsoft has become increasingly infuriating and difficult to defend over the years.

It seems that they just wanted to stick a way in to make data interoperability between SQL 2005 and older versions in order to force their customers upgrade. In our case it might just work from them. The particular server that we have still running SQL 2000 is tied to an archaic legacy application which is poorly supported. We SHOULD upgrade it, but we can’t without breaking it.

This is another example of how they are not only shooting themselves in the foot, but their dwindling enterprise customer base as well.

So in the end, all I can offer is this diagram, while I prepare an upgrade path that does not ultimately involve Windows or  MSSQL Server:

We use Xythos at our workplace to provide a file repository for students and eventually faculty and staff. It’s basically a web front end for a file system.

My personal feelings about the product are somewhat ho-hum and indifferent. It makes funny noises under the hood, it’s a bit clunky, but it works, runs on Linux and it’s reliable.

So you’re probably here because you searched on this error:

java.lang.ClassFormatError: Truncated class file

The problem is that you’re probably running your Xythos installation over port 443 (as you should) but there are still components trying to pull files down from port 80. With Xythos, if SSL is enabled, any requests to port 80 get dumped over to 443, and you will get truncated errors like above.

The fix is to feed some hardcoded variables for your site name into the application so it does not do that, and use port 443 isntead.

We use version 7.1, and in our case the error was addressed by editing the following file, in your Xythos installation:

/path_to_xythos/wfs<version>/webapps/xythoswfs/upload_advanced.jsp

Now look for the text “UPLOAD Applet”, and you should see some source that looks like this:

<!-- UPLOAD Applet -->

<% if (l_showApplet) { %>

<div class="xy_content" style="margin-top: 5px;">

  <div id="uploadAppletDiv">

    <script type="text/javascript">

      var l_altMessage = "<%= p_msgBun.getString("NO_JAVA_PLUGIN_MESSAGE") %>";

      printUploadApplet("uploadAppletDiv",

        "<%= l_codeContext %>",

        "<%= l_sessionID %>",

        "<%= ServletUtil.makeHtmlSafe(l_baseWebdavServerURL) %>",

Change the following lines, so it looks like this:

<!-- UPLOAD Applet -->

<% if (l_showApplet) { %>

<div class="xy_content" style="margin-top: 5px;">

  <div id="uploadAppletDiv">

    <script type="text/javascript">

      var l_altMessage = "<%= p_msgBun.getString("NO_JAVA_PLUGIN_MESSAGE") %>";

      printUploadApplet("uploadAppletDiv",

<%--        "<%= l_codeContext %>",  --%>

        "https://yournamehere/xythoswfs",

        "<%= l_sessionID %>",

<%--        "<%= ServletUtil.makeHtmlSafe(l_baseWebdavServerURL) %>",  --%>

        "https://yournamehere",

You won’t need to restart the Xythos service, but now give your setup a whirl. Advanced Upload functionality should work now. Be aware that if you do this, drop-in upgrades might break this functionality, and you’ll need to edit the new files again.

I’m generally for the practice of pixel peeping, as long as it is done in moderation. In case you don’t know what pixel peeping entails, it’s real simple and roughly goes along these steps:

1. Get two or more cameras that you want to compare. Let’s use one that you love, and one that you hate.
2. Pick a subject to photograph, preferably a still life or something that won’t move much or change colors between shots.
3. Set one camera up on a tripod, and take a shot.
4. Set up the other camera to replace the first, using the same settings, and take a shot.
5. Load the images from both cameras to your computer.
6. Zoom into one section with high detail and compare the hell out of both images side by side.
7. Linger around at step 6 or repeat EVERYTHING until you feel that the camera you love and always wanted to ‘win’ all along gets better results than the other one that you hate.

Okay, i’m being a bit sarcastic. But seriously, this is how pixel peeping usually ends up happening.

It’s not that pixel peeping isn’t without its merits, but if you have taken more pictures of $20 bills taped to a wall compared with actually interesting subject matter, you have chosen the wrong hobby. Perhaps chainsaw juggling would be a more suitable endeavor instead.

Some people also consider pixel peeping to be an Internet sport. If you do choose to engage in this giant tub of fail, at least don’t go around on discussion boards making quotes like this:

“in my eyes nikon colors look more fake…that is why i never switched to nikon, even though they make amazing cameras a lot of times the color look too saturated, not natural at all canon has the opposite tendency, which i prefer…”

“for my eyes, Nikon’s color looks more natural, no? From the examples, the tree and lawn has a warmer green.”

So what exactly is wrong with those quotes? They seem like perfectly legitimate critiques of color, right?

Here’s what’s wrong- when the image that is being pixel peeped is that of a Bailey’s Irish Cream bottle label with a painted rendition of a pastoral nature scene.

Yup. Every time I think I have seen something silly, the Internet shows me how much I have to learn about silliness.

I use Gallery2 for the backend service of photos. It works rather well, despite a few quirks. But none of these issues are nearly as bad as something in the world of a closed-source vendor.

I recently tried to upgrade the Gallery software and found this nasty error in the logs right around when I was trying to push the big red ‘Upgrade’ button:

...Unable to selectAdminUser for core upgrade...

Hopefully if you are reading this, it is because you found this page on a web search and are grasping for some answers. I’m not saying I have all of them, but this is the process I used to figure things out.

First I determined that when logged in as my site admin for Gallery, i did not see the ‘Site Admin’ functionality that is normally present for that user… which is a BAD thing. Try this now. You might experience the same.

Then I looked at the database itself. There was no corruption as far as I could tell, but of interest was the gallery group and user mappings. Open up a command prompt and use whatever you use to interface with your database to run the following SQL query:

select * from g2_UserGroupMap where g_userID=6;

You should see something that looks like this:

+----------+-----------+
| g_userId | g_groupId |
+----------+-----------+
|        6 |         2 |
|        6 |         4 |
|        6 |         3 |
+----------+-----------+
3 rows in set (0.00 sec)

Note the last row, where it shows ‘6′ and ‘3′. If that row does not appear, then your admin user is not set up to actually have admin privileges!

A quick and dirty fix to enable the default user you created when you installed Gallery is to run this query:

insert into g2_UserGroupMap values (6,3);

You have now just given user ID number 6 admin privileges.

Now make sure you know who that user ID 6 is:

select g_userName from g2_User where g_id=6;

Now you can login as that user and try the upgrade again. Bingo!