I did a simple calculator on Google Spreadsheets for calculating bitmasks (DEC and BIN notations with user friendly labels for all flags) - here's a published version for Linux kernel.sysrq sysctl flags, but you're welcome to adapt it to any other needs you like:
bitmask calculator for Linux kernel.sysrq
So, I've recently finally went about with developing my old idea of integrating Kerberos and LDAP protocols into a working proof of concept.
I've also made it into a subject of my master's thesis at PJIIT (Polish-Japanese Institute of Information Technology).
You can read the master's thesis in PDF format here. Don't pay attention to the silly title, fragments of title and introduction in polish and appendices with source code (which, above all, is available on Github). All of those were simply requirements of the institute.
The actual point of the paper is:
- to present the premise that the current stack of protocols needed to integrate Kerberos with LDAP is unnecessarily complex (think SASL, and possibly GSSAPI),
- that a simpler and more logical solution would be closely integrating the protocols by carrying Kerberos v5 messages inside LDAP v3 extended operations (exop) - resulting in a new protocol named KrbLDAP,
- present a working proof of concept.
It turns out that carrying Kerberos messages over LDAP is quite straightforward, as demonstrated in the proof of concept code, which consists of an integration test, a customized client and customized server.
On the client side, it was sufficient to make simple changes to MIT libkrb5. Currently, due to time pressure when working on the thesis, the switch to transporting krb5 over LDAP exop is hadcoded in libkrb5. It should be quite simple to make a /etc/krb5.conf config option that selectively activates this logic per KDC server. It was also necessary to make use of some actual application that uses the customized libkrb5, as a base for the automatically performed integration test. I went with PAM krb5 module as it already has a set of ready made integration tests for plain krb5.
On the server side, I needed to make a bit larger in scope, but still simple customizations. I chose Apache Directory for the server since it's a well architected, extensible implementation of both LDAP v3 and Kerberos KDC. The downside of this choice, as it turned out later into the implementation, is that Apache DS has some serious compatibility problems with standard krb5 as per RFC, and MIT krb5 client library is especially sensitive to those.
Both the server side customizations and the integration test launcher are contained in one Maven-based Java project named apacheds-krbldap-test.
The proof of concept succeeds in performing a simple Kerberos message exchange, which progresses analogously to an exchange between unmodified vanilla krb5 client and Apache DS over plain TCP-based Kerberos.
Unfortunately, due to interoperability issues between ApacheDS's KDC and MIT libkrb5, this exchange doesn't succeed in obtaining a Kerberos ticket. This is true both for KrbLDAP and classic Krb5 over TCP.
As discussed on the Apache DS mailing list, this issue still needs to be addressed separately, as well as probably several other interoperability issues.
The main point of the thesis can, however, be considered proven - Kerberos can be easily transported over LDAP and this protocol stack is much simpler than having 2 separate TCP-based protocols working in concert.
Oto Tłumaczenie z angielskiego jakże trafnej, ponadczasowej i zawsze aktualnej ...
Recently I've written a web app whose purpose is to aid people who switch between Russian and English QWERTY keyboard layouts and often mistype what they intend to with a wrong layout. Usually switching the layout and retyping the same thing is more effort than clicking through a Google search result that shows the mapping from the wrong to the right text. Or copying the mistyped text and pasting it into the web app. For people who mistype very often, there's even a search plugin for popular browsers.
It's my first try at a web application implemented in Python so it may have a few rough edges, but it already shows some interesting results.
The most popular mistypes seem to currently be:
d rjynfrnt (в контакте)
Try the browser search plugin, it's fun!
After wondering for the n-th time about what would be the difference (if any) in toString() representations of a TreeMap and a Vector, I've decided to make a simple catalog for future reference.
Here it is: Java standard classes toString representation catalog.
It currently includes only JCF classes.
I've compiled a list of the most useful MBeans to be found in JBoss through its JMX console: Aleksander Adamowski's JBoss JMX console tips and tricks. It includes MBeans with operations for shutting down JBoss remotely, listing Java system properties, listing JNDI contents, forcing log4j configuration reload, listing ClassLoader info for given class, listing deployed apps, retrieving cluster information etc. This list is being updated whenever I discover some MBean worth mentioning.
I've published a document with all sorts of useful scripts for various tasks, ranging from encoding/decoding Base64 and quoted printable, through determination of remote host's SSL certificate expiry date, to recursively exploding ZIP/JAR/EAR archives (similar to the way JBoss does when deploying). It's available here: Aleksander Adamowski's useful scripts. This document is being updated whenever I write a script worth publishing.
This script, explode_zips.sh, taken straight from the document Aleksander Adamowski's useful scripts, should be very useful for a Java Enterprise application developer or administrator. It takes a ZIP archive (which JAR/WAR/EAR archives are in their heart, too) and recursively explodes it in a way similar to what the JBoss application server does when deploying. It's very useful e.g. when you have two versions of an enterprise application and want to compare them by content e.g. using diff. Comparing binary ZIP archives wouldn't do the trick, especially if they contain other archives, which contain another ones (you get the idea). On the other hand, when you recursively unpack all the archives and get rid of the binary ZIPs, you'll be left with a directory structure which can be easily compared for differences using appropriate tool (like the aforementioned diff on UNIX systems, or e.g. Total Commander under MS Windows). Here's the actual script:
# Iteratively explode all ZIP/JAR/WAR/EAR archives in the current dir and all the archives they contain.
while [ $foundzips -gt 0 ]; do
# Not very efficient to re-find for each sublevel, but it's simple:
for zipfile in $(find ./ -type f -iname '*.zip' -or -iname '*.[jwe]ar'); do
echo "Archive: [$zipfile]"
if [ ! -e "$expdir" ]; then
echo "making $expdir" && \
mkdir "$expdir" && \
echo "entering $expdir" && \
pushd "$expdir" && \
dirpushed=1 && \
echo "unzipping $PWD/../$zipfilebasename" && \
unzip "../$zipfilebasename" && \
echo "removing $PWD/../$zipfilebasename" && \
rm "../$zipfilebasename" ||
mv "../$zipfilebasename" "../$zipfilebasename.bad"
if [ $dirpushed -gt 0 ]; then
The problem with Java's loading of classes on demand is that it's non trivial to implement a mechanism for dynamic discovery of new classes in packages. If we only want to drop new classes into a package, and don make any further modifications in the code and application configuration (e.g. properties), then we have no other choice but to do dirty tricks with traversing the package's file structure to discover the .class files.
This requires two different code paths for class files in JAR archives and in the filesystem - that's because the JAR archive is a ZIP file and doesn't contain a tree structure of directories. Instead, it contains a flat listing of all contents. So the getResource() method is unable to give us a File object which isDirectory() in the case of a JAR archive.
I've implemented a ClassPreloader class that provides a convenient preloadCurrentPackageClasses() method that handles both cases gracefully.
You'll find the source here.