open source code

ONB-Classic

Repo: https://github.com/palantir/onb-classic Docs: https://palantir.github.io/onb-classic/

Background

I have been on a slow mission to open source some of the projects I have worked on over the years. The next project after the IsoFileReader actually predates that other project. ONB-Classic has the ability to serve files directly from an ISO without extracting the ISO, to do this we utilize IsoFileReader. That feature required me to open source IsoFileReader first. ONB-Classic is a fork of the OpenNetBoot project I started around 12 years ago. The project originated with having to PXE (Preboot Execution Environment) boot systems via the network, and I wanted to be able to use Proxy-DHCP (more on that in a second) to boot anywhere no matter the infrastructure. This allowed any sysadmin to pop up a PXE server, quickly image systems, and then tear it down.

When I started this project we were imaging Windows 7 machines with Symantec Ghost (what a time to be alive). It wasn’t new at that time, but it had a built in utility from 3Com which allowed us to do Proxy-DHCP, and PXE boot systems. Proxy-DHCP is when you have an authoritative DHCP server giving out addresses on a layer 2 segment, but then have a secondary DHCP server which jumps in after the Server -> Client offer broadcast and offers up boot information (PXE data) which the client then combines to boot. This has its own RFC as part of DHCP, and works on all (with some difficulty) PXE roms.

Concept

The main concept of OpenNetBoot was to bring PXE, TFTP, and HTTP services together into a simple app, allowing someone to stand up an imaging system or Linux installation system anywhere. I also always hoped to open source it, hence the name. The program started as what you see in the repo. It became classic when I had the idea to make it into a web app, and that web app became more of a platform with plugins that could allow different types of system installation. That greater platform was more work specific and I may write about it later, but was very mission focused for building servers at work. It hooked into different systems like server ordering and customer delivery.

This project was where I really started loving lower level programming, and the things you could do if you owned the whole stack. This allows you to have greater insight into the boot process, in addition to doing some fun tricks with the protocols because we control them. I can send the client to different images depending on data I get at different stages in the pipeline, watching the client progress through the boot stages.

Development / Boot Flow

There were bumps along the way. The system would be able to boot one system, and then not work on the next. Some of this came down to vendors **cough** Realtek **cough**, not following the RFC and requiring extra bytes where there are not supposed to be any. We later moved from shipping all BIOS systems to UEFI, which proved to be a new generation of PXE roms that were more picky. The project was also written in Java, this allowed me to run it on any operating system, but this also led to issues where different systems would treat sending to a broadcast address (255.255.255.255) differently.

At this point it may be worth going through the boot flow, and how I always used ONB. A server boots, asks for DHCP, your local network gives you an IP and ONB comes in and gives boot information based on the headers in your original DHCP request. Are you x86? ARM? Are you a BIOS system, or UEFI? Then we return the address to a boot server (ourselves) and a file to load, usually iPXE.

I have been using iPXE for the whole life of this project, it’s a great boot rom except it never was SecureBoot signed, forcing us to disable SecureBoot for PXE operations. That is until recently! iPXE project after a decade got their rom signed by Microsoft! I have been very excited.

Now that iPXE’s address is given, the client reaches out over TFTP to the server to pull the rom. TFTP is very slow; the client requests bytes of a file over UDP, we send bytes, the client acknowledges and requests next bytes. There is no windowing, and if the link is full because let’s say 100 servers are booting, some UDP packets are dropped, forcing a restart. That makes our goal to leave TFTP as quickly as we can. Once iPXE is loaded, it does a new DHCP request, and gets Proxy DHCP information again, but this time with an iPXE system id. Now we serve them a menu file instead of a boot rom. From now on, we can send them data in HTTP format, which is much, much faster and unlocks things like loading large kernel roms before the heat death of the universe. Loading 100MB Linux kernels at 500kb/s is not feasible for a production environment.

As mentioned, the application is written in Java, this allows it to load anywhere, and the JavaFX UI to work on any of them. Over the years things have changed; JavaFX used to be included in Oracle Java, and as we all moved to open source Java it became its own package. The application back end became heavily multi-threaded with threads dispatched when clients connect. Multi-threading dispatch allows the DHCP and TFTP servers to handle 100+ clients at a time. When a client reaches out, we get their request, and pass it to a new worker thread to respond. Then we can immediately free up the original server process to handle the next client. There are several core threads and the goal is always to get work off them as quickly as possible and hand it to a sub-worker.

I have gone on to update this application, and write other ones using JavaFX. It’s another one of those – devil you know – situations, where I do not love programming in it, but I know how it works. The SceneBuilder allows you to create the XML GUI templates fairly easily. One of the more complicated parts of the application is actually the logging system. It has to be able to pass log messages to the GUI, or the CLI; and then pass some of them to a text log file. This system also has to take logs from different threads as they fire, and try not to block. It naturally grew over time, and has shown to work well.

While I was deep in the protocols, I went off on a weird tangent: I added a ‘virtual NIC’ option to the command line of the app. It allows you to simulate a client on the network. It generates a new MAC address and reaches out to see how the authoritative DHCP server responds. That was fun because it was the first time I acted as the PXE client instead of server, simulating a full network card.

That is all ONB-Classic does. Brings those different parts together to help iPXE get through the process. You load your own menu and images to boot whatever systems you have. The application supports running as a console app, a daemon, or a full GUI app with a tray icon. It works on Windows, Mac, and Linux; over the years has been in production on all three.

UI Design

The app went through several designs and mock-ups. Not altering too much until it became a web platform.

Original Design Mac
Original Design Windows
Original Mock Up
Updated UI Mock Up

I also tried making different logos. This is before generative AI, I had to sit there in Gimp or Inkscape myself and draw ideas. Here are a few for fun.

Final Logo
Attempt 1
Attempt 2
ONB-Classic Settings Page
ONB-Classic Final App Settings page and look

Wrapping Up

I have maintained this app for over a decade now. It ran the heart of our server shipments for years, shipping thousands of servers. It helped launch my career. And gave me a love of lower level programming down to RFC. I am excited to share it with the world, and I hope it helps a sysadmin out there to boot systems. The system is Apache 2.0 licensed, and I am always happy to get pull requests or feedback!

Moving From Dropwizard to Spring Boot

Where I work historically, we have used Dropwizard, a Java framework for creating web apps a lot. This framework went head-to-head with Spring Boot, in the last few years and has seem to drop out of favor with the community. Nonetheless, I thought for a new project I would dive into using that to get more acquainted with it. After trying to get two of the basic things I needed done, I ended up giving up on Dropwizard and pivoting to Spring Boot instead.

The first big library I tend to use with Java projects, especially web apps, is jOOQ. This framework creates simple objects and gives many ways to interact with your database. The best feature for me is you can have a Gradle plugin scan your database, then create all the objects automatically in Java. Not only does this save you from handwriting a bunch of SQL queries, but it also means when you update the database (probably using something like Flyway), your objects automatically get updated. Now when you compile your program, if you forgot to add that new field somewhere when editing an object, you get a compilation error instead of the application silently failing SQL queries in production.

Dropwizard does not natively support jOOQ, I went looking for a library to add the support I needed. I found benjamin-bader/droptools library. It seemed to do what I needed. I got it wired in, and soon everything was working! I could make objects and with one or two lines edit objects web requests. Wonderful. Then Dropwizard did a major update; version 3.0 was created to keep the javax namespace, and 4.0 was created to move to the jakarta namespace. These versions also moved a bunch of the internals of the Dropwizard libraries around, meaning supporting libraries like droptools would need updated.

That’s when I saw droptools had not been updated for 3 years… I decided I would open a GitHub issue. With not hearing anything for a few days I started tinkering with it. I got a updated build working for Dropwizard 3.0 and did a pull request back to the main repo. In doing this I realized with the Dropwizard 3.0 and 4.0 split, we would need at least 2 versions of the library created at one time. Then on top of that, jOOQ 3.16 was the last to support Java 11, and jOOQ 3.18 was out as the main community supported branch. This means we need to make 4 versions; 2 with Dropwizard 3.0, and 2 with 4.0, then each one having jOOQ 3.16 and 3.18. I rewrite the build pipeline from the Travis CI the repo had to Github actions, and got all 4 versions compiling with some regex to do the edits in the code that were needed. I then used my earlier article, to publish these 4 assets to Maven Central.

This allowed me to update to Dropwizard 4.0, and the Jakarta namespace.

Next, I need to get basic authentication working. My plan is to use Google OAuth as the login mechanism. I do not feel like writing my own for a side project, and out of the ones out there (Google, Facebook, Twitter, Github) I thought it had the most coverage of people, with the least surveillance factor. It is easy enough to get setup with a developer account and get the client-id and secret I needed for OAuth.

Now I had to wire up the OAuth on the application side, this is not too hard I have done this many times with applications at work, but usually there I am using internal libraries. Heading over to the Dropwizard docs didn’t give me exactly what I wanted. They are pretty sparce, and when it comes to setting it up, they mention how to do OAuth but then mention you need to write your own Authenticator and Authorizer for it. I don’t want to do that. I have done that before for servlet-based apps, but this is supposed to be a fun thing, and on the general internet I want a supported auth library. I went searching for an example of how to use the OAuth system. I could not find anything that got me what I wanted.

Then I remembered using Pac4J before with other Java frameworks, this is a security library that has support for many login methods, and many web frameworks. Dropwizard is listed as supported! But the last time it was touched by a human, and not a bot, was over a year ago, and that was just for a small CI fix… I’ll try to get it working anyway!

The dropwizard-pac4j library is what I need, and there is a dropwizard-pac4j-demo which walks you through setting everything up! I get the demo working, I added in Google login support, which wasn’t there by default. Then I spent a day… Where I wanted to get this auth working on Dropwizard 3.0 or 4.0. I don’t want to start working in the older 2.x framework to get stuck later. I downloaded dropwizard-pac4j and the demo locally and started editing them to get the dependencies updated and try to get everything onto the jakarta namespace.

This is where the dependency hell came in. dropwizard-pac4j-demo depends on dropwizard-pac4j, which makes sense. dropwizard-pac4j sets a lot of your project versions based on what it has in it. After updating a ton of dependencies to try to get it to compile it came down to DropwizardTestSupport.java failing to run because it relies on jax-rs-pac4j. jax-rs-pac4j is still in the javax namespace and hasn’t been touched by a human in 6 months or more. This library would need to be updated, because it links directly to the main Jetty Server project which has a dependency on jakarta.servlet.SingleThreadModel in ServletHolder.java, which has been deprecated and removed (discussion), then and I could not get the demo project to load with any combination of dependencies. They all wanted this Jetty 11 file, which should have jakarta.servlet.SingleThreadModel removed, but doesn’t.

I went back and tried to move to Dropwizard 3.0, going back to the javax namespace, but that opened up a bunch of similar issues and a ton of conflicting dependencies in different versions of code dropwizard-pac4j needed. I have my code on GitHub if anyone wanted to continue this journey, or in the future things are in a better place.

With all of that, I thought I would go and check the documentation for Spring Boot. There is a giant page, with in-depth, step by step instructions on how to get Google or GitHub auth working in your app. There is a night and day difference between the support and thoroughness of Dropwizard docs and Spring Boot. With seeing that, I had to decide to change my plans away from Dropwizard. Many on the Java subreddit will debate Spring Boot vs Quarkus; for me, who has only used servlets in the past with embedded Tomcat, I think starting with the popular Spring Boot makes the most sense.

Pac4J Integration with Embedded Tomcat 10 using Generic OAuth via Keycloak

(I will ramble for a bit, if you just want the guide jump below) I want to start a series more around programing than the other articles I have put up here. I know everyone here knows me as the good-looking hardware hacking guy, but most of my time at work is spent on programming and systems automation. I haven’t used the programming tag on this blog in a while, and I want to start this new series beginning with discussing upgrading to Tomcat 10.

I have for years been using an embedded Tomcat + Servlet backend, with a jQuery frontend for different small webapps I have made. I know for anyone who learned webdev in the recent past that sounds very old. I am using more and more Dropwizard and React these days, but that does leave my legacy projects on this old framework. While not the newest or flashiest thing, it does perform well with some systems handling hundreds to thousands of calls a second. (My hope is to get approval and open source some of them soon.) With the changes in the Java universe, (after Oracle bought Sun and decided to ruin everyone’s fun and causing splintering) I had to start moving from the traditional JavaX servlet namespace that Tomcat 9 and before used to Tomcat 10s Jakarta namespace. Migrating the servlets themselves was not so bad. The first big issue arose around Google’s OAuth library. I have used this library for a long time. It provides the easy-ish ability to connect to any OAuth server you want (I have specific ones at work I use) for authentication. Recently Google, doing what they do, marked this library as Maintenance Mode Only, stating they would only do emergency security fixes, but overall, its abandoned. Not what you want to hear from your authentication library. They also are not planning to move it over the Jakarta namespace making me stuck on Tomcat 9 for as long as it has support. This should be a long-time sine many big companies and projects are right where I was, and the plan is for 9 and 10 to develop together for a long time. This does mean that I cannot use the newer features of Java though. From this I knew I had to start looking at other options.

Every time I have to work on auth systems, it is maze, and once I get it working, I want it to stay working for a while, where I hopefully don’t have to touch it. There are not a ton of OAuth libraries for Java backend systems, and I wanted one that I knew had community support and would last for a while. That brought me to the popular PAC4J project. A lot of the guides I found for using this were around using JavaX and/or using PAC4J to integrate with Google Auth, or Facebook Auth, or other auth systems. I want to be able to use the systems at work, or a more generic provider such as Keycloak. I spent a good amount of time bringing different bits of information together to get a fully working PAC4J 5.7 + Tomcat 10 + Servlets setup working. I posted it on Github, and below has a guide on how to configure Keycloak in Docker to demonstrate this. This took a fair amount of time to put together, I hope it helps you out there, if it does, please give the post a like or star the repo, it pushes me to keep doing these tutorials.

Keycloak Setup

To start at the beginning, Keycloak is a webserver that works as an Identity Provider (IDP). It has its own database for users and groups, or can link into many other systems such as Google, Facebook, and many more. When hooking up to it, you can decide to use SAML or OpenID. I tend to use OAuth which is a subset of the OpenID standard (I think thats the order). This guide will use Keycloak as our IDP, then connect to that with RAC4J. I do believe PAC4J has a more native and easier to use Keycloak integration, but where is the fun in that.

Keycloak out of the box has a Docker image for development. You optionally can attach persistent storage to make users and groups stay after you delete and rebuild the container. Using this container with local storage is not a good setup this way for production, you should use a database like Postgres to back the container instead. But for our home testing this setup is fine and will work well. I use persistent storage so I can have a local Keycloak that can be updated without recreating everything. More information about the Keycloak docker container can be found here.

Setting up Keycloak with persistent storage

docker volume create keycloak
# We need to set the keycloak user to be the owner of that folder
docker run --rm --entrypoint chown -v keycloak:/keycloak alpine -R 1000:0 /keycloak
docker run -p 8081:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -v keycloak:/opt/keycloak/data/h2 quay.io/keycloak/keycloak:20.0.2 start-dev --http-relative-path /auth

Setting up Keycloak WITHOUT persistent storage

docker run -p 8081:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:20.0.2 start-dev --http-relative-path /auth

After a minute you should be able to browse to “http://127.0.0.1:8081/auth” and get:

Keycloak can use OpenID as its connector which is more of a superset of OAuth itself. For this guide I want to go over using OAuth; so we will tweak some of the Keycloak configs to work how we want, as a generic OAuth provider.

  • Login with the username and password of “admin” that we set in creating the container
  • Click in the top left dropdown where it says “master” and create a new realm, we will call it “example“
  • Now that we are in your new realm, go to “Users” on the left
    • Create a new user, lets name this new user “Jon” (or whatever your heart desires)
    • Once created, click the “Credentials” tab, and set a password, I disable “temporary password” because this is not a production auth system
  • Click “Client Scopes” in the top left
    • “Create client scope“
    • Name “openid”
    • Type “Default“
    • Save
    • “Mappers” tab
    • “Add predefined mapper“
    • I did “full name”, “email”, “username”, “groups”
    • Note: I found the add screen here buggy, if you page to the next list of mappers, saving doesn’t work, so do one page at a time
  • Click “Clients” in the top left
    • “Create client“
    • Client-id “example-client”, I like to enable “Always display in console”, “Next”
    • Enable “Client Authentication”, then save.
      • “Client Authentication” enables “confidential access type”, this is the classic OAuth where you need a client secret to access the server
    • For this demo we need to enter “http://127.0.0.1:8080/oauth/redirect*” to the “Valid redirect URIs“, and save
    • Go up to “Client scopes” and add the “openid” scope as a “Default” type
    • Note: I have found with PAC4J + Keycloak specifically, if you do not add the openid type, then you will get through auth but when PAC4J goes to get user information you will get an error of WARN org.keycloak.events type=USER_INFO_REQUEST_ERROR, realmId=59d04435-daf4-4ca7-8623-195769911c0e, clientId=null, userId=null, ipAddress=172.17.0.1, error=access_denied, auth_method=validate_access_token. You may also see WARN org.keycloak.services KC-SERVICES0091: Request is missing scope 'openid' so it's not treated as OIDC, but just pure OAuth2 request. If your client is not requesting the openid scope.
    • Go to the “Credentials” tab, view the “Client secret” and save that for later

At this point going to http://127.0.0.1:8081/auth/realms/example/.well-known/openid-configuration will give you the OAuth endpoints we need.

Using The Example Code

Clone down the repository over at my Github. The README.md should contain what you need to get going! After adding your client secret from above, if you followed this guide, that demo should work for you with http://127.0.0.1:8080/ being the web app, and http://127.0.0.1:8081/auth being the auth server.

In the end you get a simple screen like this one that lets you play around with the functionality and experiment with the code.

Building a Tiny Classic Mac Part 3 – OS and Software

In building the project I wanted the computer to have the closest to the original feel as I could get. There were a few difficulties in the project, from the TFT screen, to the OS configuration. Yet in the end, I got a cute little replica running on top of a Raspberry Pi. I am not trying to break copyright, or profit from this. I simply do it as a fan of good hardware and past operating systems.

To start I want to mention that there are areas of this “guide” where I have been short, if you are unfamiliar with Linux, some of the parts in this config may give you problems. This project includes compiling code, adding scripts to boot, and configuring systems like VNC.

I loaded the standard Debian install onto a SD card to start (which at the time was Debian 6 or 7), then I started investigating the different original Motorola Mac emulators. The two main ones I found were Basilisk II and Mini vMac. Basilisk offers features such as Color, networking, and advanced features over Mini vMac. A very useful feature that Basilisk has is supporting a shared drive. You can tell the emulator that a folder on your Pi or any PC should show up as a hard drive in Mac OS 7. That way you can easily download games/software from archive.org or other locations, then load it onto the virtual system!

Mini vMac did offer greater compatibility for apps, while only being black and white, it seems to do a much deeper level of emulation; this makes it slower, but some apps that wont work on Basilisk will work on it. My solution in the end was to put both of the emulators on the box, pointing to the same virtual hard drive.

A script wraps the system, by default it auto boots into Basilisk, but if you “shutdown” the Mac in the emulator, you get a options screen that will allow you to switch modes the emulator is running in, the emulator itself, or some other settings. Some of the other settings including pairing Bluetooth, shutting down, or dropping to the console.

These files are available under https://github.com/daberkow/minimacparts. There is a SYSINIT script that starts the script, aka the wrapper, and gets the session started under the “pi” user, this goes in the /etc/init.d folder. Then there are folders for the different emulators in the /opt/mac folder.

Note: I used the current Raspberry Pi Debian build when I did this project, which at the time was using SYSINIT over the newer SystemD. If you want to use a newer build (which you probably should) you will have to translate my crummy SYSINIT script into a SystemD script. Feel free to pull request the repo! 🙂

One of the larger issues that had to be overcome was screen scaling. The screen I used is 480×320, but the original Macintosh resolution was 512 × 342. This had some of the emulators either cut off, or scrolling around the screen when the mouse got to a corner, which was not great. I could run the emulators at a smaller resolution, but some software was designed with that screen in mind and applications were cut off!

My solution was to use VNC, the system starts the emulator in a VNC session running at the native resolution, then the Pi screen connects to that session and enables scaling mode, shrinking it to the proper size. This way VNC worries about all the scaling, at a minor speed loss. I looked at different X configs to try to do the scaling that way, but the way this screen works, it gets upset and has problems very easily. The screen does not have a scaler of any sort, so you HAVE to send that resolution of 480×320 to it. The VNC solution works well. The different emulators have VNC config files that are copied to the running config right before its run depending on the emulators properties.

At this point we should discuss dependencies; TightVNC server was used for VNC. A quick minor note about VNC, you need to config the VNC users password, and then setup the script to auto-login with that password for the above script to work. Bluez Bluetooth stack and utils were used to be able so use Bluetooth peripherals. Basilisk and Mini vMac were compiled from source on the Pi 2 so that I could squeeze the most performance out of the little PC. Also its hard to find the latest versions ARM compiled online.

Basilisk II:

Basilisk has a good make file that you can use on the Pi as long as you have standard development environment setup, https://github.com/cebix/macemu/tree/master/BasiliskII.

Mini vMac:

The authors website offers a nice little service to have the website compile to code for you, or you can compile it yourself. Depending on your screen and how you want the app to start (a lot of those settings are hard coded in at compile time) http://www.gryphel.com/c/var/index.html.

I made one virtual hard drive, that both emulators used. Luckily they use a compatible hard drive image format. I set the first image up on my desktop just because it was easier. Then copied it over once I got the image in a good state. For years Apple gave out for free on their website Mac OS 7.5.3, then after a website update it seem to break a lot of the links. A few still worked but most over the years have stopped working. A lot of different sites have mirrors of those disks available though, if you search “System_7.5.3_01of19.smi.bin”, that should bring you to one of the mirrors. The one other thing you need is a ROM for a original Macintosh. I have some classic Macs at home, and you can dump the ROM from those. Or there are sites out there that have them hosted, I would guess that would not be to hard to find.

I put the virtual hard drive, and the ROM in a folder called “Shared” in the /opt/mac directory. You may have to tweak some of the configs/scripts to get everything working your way.

Once you get it working, there are a ton of games and pieces of software on archive.org for the old Macintosh, just make sure you get the 680*0 versions not the PowerPC versions. There are also a ton of abandonware sites, since half the companies that made this software are out of business, I doubt they will mind you taking a look, though legally its a grey area.

Those are the basics for how I got the system setup. One item that gave me a bunch of problems was the TFT screen. At the time you needed to load separate kernel modules and configure boot parameters for it. I think newer kernel images have added this, so that should be a simpler task for everyone.

 

Updated Windows Sudo

Recently I updated my Windows sudo program and added a command for Super Conduit, this is what I call some tweaks that you can make to a Windows Vista+ system. This allows someone to copy sudo.exe to a systems, system32 folder; then after running “sudo cmd” you can run “sudo /write” so add ls, ifconfig, and superc as a option in the command line.

Superc has options of enable, disable, and show. Making it easy to run. 🙂

Newest build is always here https://github.com/daberkow/win_sudo/raw/master/sudo/sudo/bin/Release/sudo.exe

QuickLogs v3.3.0 (and quickly v3.3.1) (and then v3.3.2)

Recently there was a big update the to QuickLogs product, on the face of it, it looks like the buttons have been changed a little bit. That is the small part of the upgrade, the main change is how the stats page works. Now the stats page is run by the HighCharts JavaScript engine instead of the PHP libchart that was used in the past. This takes the load of creating charts off of the server, and moves it to JavaScript  Also this increases the flexibility to add more charts in the future.

I started the new stats page (v3.3.0) with a drop down to select different types of graphs, the Activities, User, and Overall graphs were used with the drop down. A quick comment made by people at the Helpdesk was “why not use all the space available, I dont like having to navigate again after refreshing.” v3.3.1 brought back the single page, but more importantly sorted the data in the charts. By default Highcharts plots by order the data is put into it; but it was not largest category to smallest. A quick sort was put in, and then we were back to where v3.2 ws with charts but a new engine. The new engine also allows for the charts to be looked at under different time periods instead of only 30 days.

The morning the program moved to version 3.3.2, this was a pure bug fix with CAS having a certificate issue under the login page. At this time, I decided to centralize the CAS information for all pages under the ‘core.php’ page. That way if the certificate moves there is one place to do it.

QuickLogs represents a early version of my app design; these days I tend to make core.php and ajax.php heavy with most of the application functions, and subsequent pages call them with ajax. This is a older app where a lot of the functions are hard coded in the page. I have started migrating to using a wrapper on MySQL like I have with the time cards app. But I only changed it on functions I was modifying so most of QuickLogs remains doing manual queries.

Looking to the future there are many ideas for QuickLogs, yet little time to compete them. One person suggested a achievement system for different things you can do at work. Another suggestion was a Nemesis  a person who is right ahead of you for tickets, and having competition. The final suggestion was for some different types of charts. I wanted to do charts, I just have to find time.

At this point, QuickLogs is going on the shelf. (Unless I get a itch to add more charts) I am shifting to more time on Time Tracker and getting this product finished, before I leave RPI. Documentation for both products should be updated soon as well.

OpenAFS @RPI Client

Recently I was told “I can’t remember anyone getting OpenAFS to work on their own”, by a staffer at my school. I took it on myself then to figure out how to get this working for students. And in the end I wrote an app that will automatically download and install the AFS client, then configure drives for you. This was an experiment in threading and using WPF instead of Windows Forms.

First the app goes and downloads the OpenAFS client, if it is a 64 bit machine it grabs the 32 bit tools first then the client. While downloading and installing these things it connects via SSH to a school server to get the location of the user’s home folder as well as verify the credentials given.

Once installation is complete the program runs ‘klog’, this goes to the AFS server and requests tokens in the cluster using the credentials given earlier. Once we are past the installing point all these actions need to be run on the campus network. When the program starts it tries to ping a couple internal servers, if it can hit more than half of them in under 75 milliseconds then it considers itself on campus; if it thinks it’s off campus, then it notifies the user. One small problem with the first release is sometimes this system gets confused by vpn taking slightly longer.

Now that we have working token the system recommends drive letters that are not in use as well as AFS spaces to mount including the users folder and ‘dept’ to start. The configure button will activate these drives, they are not set to persistent at this time.

Below is the github link, as well as the direct exe link:

Github: https://github.com/daberkow/RPI_OpenAFS

EXE: https://github.com/daberkow/RPI_OpenAFS/blob/master/OpenAFS%20Installer%20WPF/bin/Release/OpenAFS%20Installer%20WPF.exe

Enstall Project

I am working on a project called Enstall with a partner for RCOS @ RPI, it’s available at enstall.wordpress.com, the goal is to make a package management system. One may say “but Dan there are like 10 available and one or two are already open source…” That is true but most of them are aimed at IT personel, and controlling all the computers in a corporation, this is just for a student to install and get software from their school on their PERSONAL computer. That’s the dream.

6to4 Card Cleaner Github!

Here it is! The source code (all be it not great) for 6to4 card cleaner up on github. This program has become less useful recently because my school recently implemented IPv6 across the network, and that has seemed to fixed the problem, along with new images. Anyway have fun with it, build it out, add to it…

 

https://github.com/daberkow/6to4-Card-Cleaner

PHP/JS and C# Encryption

Here is some code from a project I have been working on and then shelved. A C# (mono) project creates a RSA public/private key pair, then gives the public side to a MySQL database. The private side is saved to the hard drive for later. Then PHP dynamically adds the currently active key public portion into javascript, which encrypts the users input, and saves it to MySQL. Then the C# application can get the keys it has saved in a good place, and decrypt the data in the database. Benefits of this include the web data is secured from the client to the server, and even if somehow someone steals your database off your webserver, they dont have the encryption keys to take it away. This system also has a way to deactivate a old key and move to a new one, if more code was put into it someone could revoke a old key and migrate all the data using it to a new key, but that wasn’t implemented. I thought this would be a cool project and I learned a lot about RSA public private keys, a lot of languages handle the keys differently; some take it in hex, some do it differently, some call the parts one thing, some call them other names. The javascript portion is based mostly off this library (link). JQuery is used for ease.

Feel free to give feed back or use this, open source fun.

https://github.com/daberkow/PHP_PublicKeyDemo