Improving the Community

I’ll admit it. I was quite sceptical when I was first introduced to UniData. It was different from other systems I was familiar with. It also seemed quite antiquated. It didn’t help that I was introduced to it via a green screen and single line editor that was preached as “very powerful” because it could do the equivalent of ‘Find & Replace’

It does have its charm, however. It also exceeds in areas where other solutions don’t.

The biggest problem I still have with U2 over other stacks out there, is the community. Now, the problem isn’t the people in the community. The problem is size and accessibility of the community compared to the mainstream stacks. This is especially true for newer users/developers as their normal sources of information generally pull up empty regarding U2.

StackOverflow (programming), ServerFault (Server admin) and SuperUser (End-User) have quickly become one of those “One-Stop-Shops” for Q&A’s for large number of admins, developers and users. I am one of those developers. I even link to it on the right-side here. I have not gone there for U2 answers though, since I know there is only a small handful who know about UniData or UniVerse that frequent it.

Evan Carrol recently posted about StackOverflow/ServerFault as an alternative medium. I completely agree and find that while the mail-list serves it’s purpose, I found the above trilogy of sites to have a far more useful system in place. I also believe that more activity at these sites will be far more useful and easy to find for new players.

From now one, if I post a question on the mailing list, I will also post on the appropriate above site. I also encourage any others in the U2 world to do the same.

That isn’t the only problem facing the community when competing with the mainstream stacks. U2 has a unique business model which causes users to not only be isolated from the actual U2 team by “middlemen” (resellers, etc) who act as first line support, but also isolating the users from each other. The U2 User Group helps, but I feel still doesn’t negate this initial segregation.

Comprehensive introduction tutorials (not just for the core product, but also the additional bolt-on products), a more direct route for reporting bugs to Rocket and an easier to use community site would go along way to closing the gap.

That’s my opinion anyway.

Security is not Obscurity. Even in U2 [Part 2]

I hope everyone had a relaxing and enjoyable holiday season!

I also hope everyone is considering what information they log. Is it too little for when things go wrong? Is it too much and compromising your security?

Lets start with too little.

Say you have a system that services requests from an external system. Maybe it does login requests as well. Now, you need to explain something that has changed in your data. Do you have log files with enough information to look back on and determine when the change happened and who made the change? Do you have logs at all?

Without appropriate logs, you leave yourself vulnerable to unexplainable and unaccountable changes. Effective logging not only gives you diagnostic capabilities for when mistakes happen (user OR developer), but can also act as a deterrent for would-be malicious parties.

On the flip side, it is possible for too much information to be logged.

Aside from the administration headache causes by excessive amounts of data, it is possible that you are recording normally secure information in unsecured log files.

Typically, log files have security practices that are much more lax than the most secure data on your system. Log files are more likely to be found on developers machines, in print-outs and generally unencrypted.

With that in mind, you must make sure that sensitive information is effectively censored from logs. This means information such as passwords, credit card details and clients personal information. This should be done in the program that creates the data to be logged, as it should know which sections should be censored. If this isn’t possible, the log files should be censored by another program before being accessible by anyone else.

Think of any programs you have that do custom logging or create printer spools. Don’t forgot to check log files that you can get UD/UV to automatically create for you such as COMO logs, Protocol logging and system logs. Also important to consider is the logging done by applications that talk to your U2 system.

Remember

When considering security of Data in Motion and Data at Rest, it is highly likely that it is at rest in more places than just your database. Sure, may have your U2 system locked up tight, but if the information unscrupulous parties are after can be accessed elsewhere, you can bet they will just get it from the easier target.