I recently updated an existing web application to remove any and all Windows-only bits and pieces. The revamped application is running fine on Windows, but I decided to get rid of Windows everywhere possible.
So I built a Linux Debian 12.5 VM and made a Linux 64 bit build of my application. I decided to place my web app in /usr/local/bin/MyApp.
I set permissions such that my non-root user can create files, read and write files in the folder, and is owner of all child folders (including the libs folder and individual files for my application). Still, I am not certain I have it set correctly. When I try to run the application from the console, I get an error message:
error while loading shared libraries: XojoConsoleFramework64.so: cannot open shared object file: No such file or directory
Since the libs folder is present and the file is present in the folder, I suspect that I may still have permissions wrong.
Also, once I have the application running manually from the console, I plan to set it up as a service. Permissions may need additional tweaking.
Can someone point me in the right direction with regards to the eror above?
Thanks in advance!
LD
I changed permissions to the app folder and all child folders and files to 777. Anyone could run the program and read or write files. I still get the same error. It may not be a permissions issue after all.
If you need a good baseline of “Can my system run Web Apps” you can always test with the Lifeboat demo, it’s free to use for one web app and one website
I don’t mean to spam or anything. It’s just that with all the moving parts of running a Web App on Linux, I like having an app do all the setup and configuration for me.
Thank you Tim. I know what Lifeboat can do and will surely use it when I move to a VPS. Lifeboat is a remarkable tool. But for now, it is not compatible with my environment. My VM is already behind a perimeter firewall and a reverse proxy, When I tested Lifeboat a few weeks back, my environment did not play well with Lifeboat. I have not yet configured the server-level firewall. I want to be able to run the application from the console first and then to access it from within my network and then from the outside before I proceed with this step.
First step: get it to run from the console. This is where I stumble right now. I did run a test app successfully before, but it was in the user’s home folder. Not where I want it if I am going to run the app as a service without a user logged in.
Make sure the owners / permissions match between the main executable, the MyApp Libs, and the user you are trying to run with. That’s all I can recommend for what you’ve described. I can’t really think of why it would work in your home folder but fail to find the framework lib once moved to /opt/ (assuming everything was moved correctly).
I was not clear… The test app was a different app, kind of just hello world from Linux. This is a different app. The VM is also brand new. The good news is that the app currently runs fine on the Windows host. I am not in a special rush to fix the Linux host/app. I just want it done.
777 is never the right choice. Some modern Linux’ may refuse to load files with masks that are too permissive.
The app is best located in the /opt directory IMO.
The following permissions are sufficient for a non-priviledged service account
#Type Mask Path
d 755 /opt/myapp
f 755 /opt/myapp/myapp
d 755 /opt/myapp/Libs
f 755 /opt/myapp/Libs/*
d 755 /opt/myapp/Resources
f 644 /opt/myapp/Resources/*
There are several reasons a shared object file may fail to load. If you have selinux enabled, turn it off or set it to permissive, at least while you fault find.
Missing dependancies are the most common issue. XojoConsoleFramwork64.so may be trying to call a library distributed in a package that has not been installed. Also some Xojo components have dependancies that require particular versions of additional packages to be installed - libsoup for instance.
You can check for missing dependancies using the ldd utility. You can also try setting the LDD_LIBRARY_PATH environment variable, although you should not need to and it will not magically resolve dependance on an file that is actually missing. The strace utility can also reveal useful information.
# Check the status of selinux
getenforce
# ldd -v <binary>
ldd -v ./myapp
ldd -v ./Libs/XojoConsoleFramework64.so
# print a list of the shared object files cached by the system
ldconfig -p
# log files to check often
tail -n 100 /var/log/messages
tail -n 100 /var/log/syslog
dmesg
Thank you for this information. I still have much to learn about Linux. Getting there, but not there yet. . I kind of knew that 777 is not the proper choice, but I tried to get permissions out of the way.
ldd does not report missing dependencies, but it cannot find the problematic XojoConsoleFramework64.so file.
I notice in your post that you use /opt, instead of /usr/local/bin which I saw recommended somewhere (i believe on the Debian site, not too sure). Would /opt be a better choice to place my app?
It was a permissions issue. I noticed that some of the changes I tried to make to permissions did not apply recursively to all files and folders underneath the folder. I deleted everything, recreated the folder structure manually, changed permissions on each folder and checking every child folder. Once the folder structure was re-created, I used FileZilla to move files from my build folder to each appropriate folder on the Linux server. I logged in using the same user that the permissions were set for. (of course…) I set the executable flag on the application file, and launched it. Application is ready.
It seems that this issue is resolved. I can access the application from my network. I now have some behavior differences compared with the same app running on a Windows host. That is more in my comfort zone.
Ha! Windows is a “case retentive” OS. Linux is a “case sensitive” OS. MYAPP is not the same as MyApp on Linux. There lies some of the behavior discrepancies, notably when accessing an SQLite database. I create a MYAPP database alongside the MyApp database… Baby steps.
/usr/local/bin is intended for single user binary executables that are executed from the local shell. Generally I leave it for the installed distribution and managed packages.
/opt is for optional applications. An appropriate place to segregate a web app with it’s support files. Files within /opt should not be writable by non-privileged users.
The problem with the File Hierarchy Standard (FHS) is it’s not very standard.
Thank you. Good to know. I read a couple of documents on the file hierarchy standard. Your conclusion was my feeling. But I put it on account that I must have missed something, or misunderstood something. I put the topic on my learning backburner. Anyway, once I fix all my little gremlins, it is now going to be easy enough to move the application to a new home in /opt.
. I kind of knew that 777 is not the proper choice, but I tried to get permissions out of the way.