CrushFTP Bugfixing

Recently I had the opportunity to work with managed file transfer software called CrushFTP. Although the client already had a CrushFTP server set up, I had the opportunity to install a new server with the latest, brand new version. Additionally, due to the low-risk environment, it was possible to opt for weekly updates to keep the functionality and security current.

As always with newer software, you run the risk that there are a few issues that haven’t been ironed out yet. We discovered an issue after a routine update, where users logging in sometimes were unable to upload files as expected.

Our set-up utilises two servers. One server is placed in the internal network and handles all the files and authentication and other processes. This can be considered the brains of the setup. The second server sits in our DMZ, used to mediate the communication with external parties. This server ensures the internal network can’t be compromised.

A little troubleshooting identified the DMZ server to be the issue. At this point we contacted CrushFTP support; they identified an issue when the DMZ was used in combination with LDAP integration (a user-management system). Our production servers postponed the update in order to avoid further issues.

CrushFTP soon released a fix, so we were able to apply both the original and bugfixing updates simultaneously.

A second issue was also handled similarly. Some of the interfaces allow users to upload files, but not to download anything from that folder (or even to see the contents). An update caused folders with these specific permissions to become invisible. Once again we were able to postpone the update from the production servers until a fix was provided.

Production impact: None.

Update _26 and _42 fixed the issues identified in the testing environment