Linguistics

My working assumption always was that about 33% of my duty as an administrator is language related, it might sound like a hell of an exaggeration but experience shows I'm not that far off target. You can always count on Hebrew to supply some issue with printing, badly encoded databases or question marks instead of readable text. The problem with linguistics' issues is that they tend to be hard to solve, you would expect most of these problems to have a common root cause but the fact is that a new solution is required each time, you do collect useful tips as time goes by but there's always some new issue waiting around the corner.

Hack, if I think about what I did for the last month it seems like most of the time spent was somehow connected to the fact that English is not the only existing language, I even think I have material for a couple of posts with useful tips and a lot of desperation.

Usually when I encounter these issues I blame Hebrew for being so odd - wrong writing direction and weird characters don't make my job easier, but English seems to be pretty fucked up as well. Sometimes I wish I could find the guy who invented case (as in lower case and upper case), it really makes no sense, OK so we'd write "english" instead of "English", who cares!

About a year ago I've mentioned researching EUS, well, we managed to implement (the rather cool) design we wanted but not without trouble. 

As part of the design we wanted to run command line esm commands to assign global roles to enterprise roles, the problem was that whenever we added a global role with the command line tool the whole list of global roles would just disappear from the GUI. How come you ask, and case sensitivity I answer! The issue was that the record inserted into the OID had case issues. It took me a few months to stop waiting for Oracle's solution and a few days to decompile the code and find the problem, it took Oracle another couple of months to supply a working patch.

And all of the this because of that stupid case invention.

Security Issues

A while ago I was phoned by the Apps DBA when I was away from the office and he told me the production is experiencing an issue that includes concurrents failing with an error message regarding access problems to .tmp files. It's not the first time I encounter this kind of problems and it's needles to say that it was never the stated issue with file permissions or disk space. So I came to the office to help the DBA to solve this issue (nothing trivial worked).

Solving the problem was odd, I had a good guess regarding the solution based on the previous cases, but it's really strange it did work since if what I did fixed a real problem I have no idea what triggered it and how the issue didn't manifest itself before, since nothing I know of changed (definitely not the problematic database parameter). Concurrents just started crashing with no apparent reason.

But that's not the main issue here (unless you're stuck with it and then you better know the solution or else you'll have some "fun" trying to solve the issue).

The really alarming thing about this case is that when concurrents crashed some of them had the apps password  (in cleartext) in their log files - the same log files every user can see for the concurrents they submit. 

Really, I couldn't believe my eyes, it seemed like the format usually present in those damn .tmp files, but I really don't understand what kind of a leak can cause the apps password to be dumped into the log file, to tell the truth it almost looks like an intended (buffer overflow?) attack.

The implications are very unnerving, what if we didn't happen to check a problematic log (not all of them had the issue) or what if we had just overlooked it? The meaning would be that everyone would be able to see the password until those logs were purged and we wouldn't have a clue. How can we be sure it won't happen again and who guarantees we will notice it the next time?