Cumulus Support

With the sunsetting of Linux Mint 19.3 in April, I've set up a Linux Mint 21.1 on a separate drive to test. There seems to be numerous issues with my 19.3 so just going to a fresh install would be the best way to go.

There are only two things I use my Linux box for. CumulusMX and OBS for live streaming a landscape camera (mountains in my back yard). While not being an issue in running Cumulus my problem is trying to move it to a different location. For some reason I have some log files that won't copy because I don't have ownership of them. I'm not sure who owns them but for some reason it isn't me. Using the chown command I've been able to change the ownership back to me but my question is why did this happen?

There are over a thousand files about 50 had ownership issues. In fact Jan23log.txt, Feb23log.txt and Mar23log.txt all had issues. These were in the data folder. In the backup folder All the folders within the folder were locked with ownership issues but all the files inside those folders were OK. Now it looks like the 20230310163857 & 20230311111656 are probably newly created and locked since I last visited this folder. So it looks like most everything this year is having ownership issues. In the root folder strings.ini was locked. Also looks like the AirLink202Xxxlog.txt are particularly prone to ownership issues.

Is there a setting somewhere that I need to check? Once again, program is running fine. Locked files only prevent moving them to another hard drive.

Probably related, on January 1st Cumulus wan't running until I updated to the latest release which seems like it came out on the 1st. I've never had problems running not the latest release for awhile before noticing it needed to be updated. I thought it was odd behavior but what do I know.

The files were most likely owned by root:root as you run cmx with mono using the sudo command to elevate privileges for it to run, so any file created or modified with cmx will be owned by root.

This should not be a problem seeing you have root access for the system, or if you're backing up files under your username.

hahniv wrote: ↑Sat 11 Mar 2023 10:52 pm There are only two things I use my Linux box for. CumulusMX and OBS for live streaming a landscape camera (mountains in my back yard). While not being an issue in running Cumulus my problem is trying to move it to a different location. For some reason I have some log files that won't copy because I don't have ownership of them. I'm not sure who owns them but for some reason it isn't me. Using the chown command I've been able to change the ownership back to me but my question is why did this happen?

Assuming you use systemd
You probably install under <username> and run under root as a daemon probably?

Stop CMX.
In the /etc/systemd/system/cumulusmx.service you must use: Edit /etc/systemd/system/cumulusmx.service under root (sudo) and change the user for which you installed CMX.
You will have to change user and group for the files which are already created. Then restart CMX

As a result all new files (e.g. new monthly logs) will be created under the <user> and <group>.

Thanks for the replies.

There is only one user on this machine "alt". I've checked the ownership of CumulusMX.exe and it is "alt". I launch Cumulus with the terminal command, "sudo mono CumulusMX.exe" after cd to its directory.

I'm not a big user of Linux, my main platform is Mac. I'm not sure why I'm worried about running the latest Mint because I'm running Mac OS 10.14.6 which lost support years ago. However, I'm there because it's the last OS that does 32 bit programs and I have a few 32 bitters that I use that never went to 64 sooooo. I just know enough about Linux to get it running. I haven't done anything with Linux other than updating the system and program since probably when I installed Cumulus a couple of years ago. So I've been bumbling around thus the test drive before switching operations to Mint 21.1.

That said, I've navigated to etc/systemd/system and there is no cumulusmx.service. Is this some sort of indication?

I still don't understand how different owner show up when there is only 1 user and I've been starting the program the same way since day one. Maybe my Mint 19.3 is screwed up and when I transition to 21.1 it will get straightened out?

My main weather program is WeatherDisplay on the Mac which I've been running for over 15 years. Cumulus came about a couple of years ago when I switch my Davis console to WeatherLink. I refuse to pay Davis to backup my data so I started Cumulus on my original console as a backup. I use some of its gauges along with the weatherdisplay panel on my desktop. If you go to the URL in my signature you can see the webcam (2nd purpose of the Linux box), Weatherdisplay panel and the Cumulus gauges.

When you run "sudo mono CumulusMX.exe" it is running as the root user (sudo is to run under as different user and defaults to root user unless you specify another user), so this is why the files modified by cumulus are owned by root.

What Hansr suggested is a work around, but you need to set it up to run as a service, as of right now you're running under a shell or interactive, and thats perfectly fine, if you want to run as a service, the cumulusmx.service file is provided within your CumulusMX/MXutils/linux directory and that would need to be first modified to match your system setting as far as the directory CMX is installed and then the modifications Hansr suggested then you can copy that file to /etc/systemd/system directory (you will need to use sudo to copy file over)
With this setup CMX will start up on a system boot and run without any interaction other than to upgrade.
you can reference this for much more help https://www.cumuluswiki.org/a/MX_on_Lin ... _a_service

@hahniv: What @jlmr731 says. And that is the advisable thing to do.

But what you could try, if you don't want to set up the daemon, is to modify the individual filenames which are root to the user alt. As CumulusMX.exe is owned by alt you will update and maintain as alt. So let's take alt as the user to run CMX.

Then start CMX by changing to its directory and then: There is no need to use sudo here so it is started as alt.

But whatever way you chose, run under alt or root, the files need to have consistent user/group properties and that needs to remain so while running. So the user/group must be the one that is executing CMX.

Remember root is generally not advised, by experienced people, to run and maintain user programs under Unix/Linux, for the simple reason that while running/maintaining you simply can make very regrettable mistakes.

Interesting . . .

As I said, I'm not that proficient in Linux or command line directions. I use terminal on my Mac only sparingly. Most of this is purely academic because once I move everything over to Mint 21.1 I probably won't touch it again until 2027 when 21 is due to sunset. The beauty of Linux and Mac is that it just works.

That said, why is the ownership of files not consistent? The only way I've know how to run Cumulus is thru "sudo mono CumulusMX.exe" yet a majority of the files are not locked. Locked meaning I can move them to a different location without having to change the ownership. I would think that all files run under that directive would be the same, either locked or unlocked.

I see that I'm not running the latest version of Cumulus so I need to update either later today or tomorrow schedule permitting. After the update I'll try running it without the sudo and see what that does. I hope to make the big move by the end of the week. Right now my test drive is running off a USB drive on my laptop.

When you change in terminal to root which I did when I changed the ownership with the chown command, are you now logged in to the entire computer as the root or is that just in terminal? I've setup a root password. I tried to logout and log back in as root but there wasn't an option to type in a user. It only showed the 1 user account. Ideally, what i want to do is compress my CumulusMX folder in 19.3, then decompress it in 21.1. Compression doesn't happen if there are some locked files. Then again I suppose I should be able to compress the folder with a terminal command that would be running under root.

I always get an education when I start start screwing with this stuff but it is short lived because if you don't deal with it daily it gets forgotten a year to two later.

hahniv wrote: ↑Mon 13 Mar 2023 5:48 pm That said, why is the ownership of files not consistent?

The ownership is not consistent if you start mixing users (root and alt) for running an application.

I don't hear you are implementing any of the solutions and I am kind of getting lost on the problem/solution.

@hahniv If your going to run without the sudo make sure you chown all the files within CumulusMX directory first like or course make sure that is the dir that cumulus is in.

@HansR Thanks honestly didnt know cmx was able to run as a user now, many years ago it was needed for some reason and it does still state this in the Cumulus MX Announcements and Download - PLEASE READ FIRST

EDIT:
If your using built in local copy to web directory, make sure user has permissions to write to that directory.

jlmr731 wrote: ↑Mon 13 Mar 2023 7:48 pm @HansR Thanks honestly didnt know cmx was able to run as a user now

Good... Never too old to learn
Yes maybe that piece of proze should be revised as well

Cool, thanks, kind of what I was thinking. I was going to run the, "sudo chown -R alt:alt /home/alt/cumulusMX" by the group to see if that was the right direction. Looks like it is.

As far as running inconsistent use of owners in running Cumulus, that's never happened. There is only 1 user on this box. I have always been in alt when in the terminal program, have always used sudo, which i guess is super user (google is a wonderful thing). Looks like I got that from the PLEASE READ FIRST section. I never knew anything about root until I started looking into changing the ownership so I could move my data files. I was doing that in root because in my googling, that's how it said to do it. (Maybe google isn't such a wonderful thing) Yet still I've got inconsistent ownership. It was the cause of my looking to change ownership. I'm going to assume that dropping the sudo from the launch code and changing the ownership of all the files in the CMX folder to alt will take care of the problem.

I haven't had a chance to try any of this out yet because I've got a lot going on right now.

I'm simplifying and diluting everything here - so you Richard Stallmans out there - I hear you!

Root is god, root runs all your critical services and can take control of any other user. For years, most Windows users were effectively running as root - and with that kind of 'power' you can imagine how quickly malware could spread. In theory with most exploits - if your normal user directory gets infected it should not spread to other users, systems, or root - but that also depends on where it came from. Thankfully Microsoft has hardened their consumer software since. But security always had a big impact on performance and user-friendliness, more so back then.

So the user root on unix runs your critical stuff that stops your computer crashing, stops you from deleting important files and helps to keep the bad guys out. The permissions issue that you had, was because another user was indeed owning them - root. You may know of the Administrator account on Windows and that is effectively root. (those security prompts in windows are not just there to annoy you). You can also enable root on OSX but as explained below - please don't. (you can still use sudo on OSX)

Sudo is not superuser, think of it as a lion tamer and root is the lion =)

You can enable the root account on Linux (especially debian based ones) and actually login as root with a desktop and everything. This is a really bad idea and highly discouraged.

However, how do you install new software or update, modify files etc if you don't have access to the root account? I already said logging in as root was a bad idea.

So here comes su, Substitute User and sudo - substitute user do.

When you run sudo chown -R alt:alt /home/alt/cumulusMX"

You are sudo - substituting your user for root, so that root can do,
-Recursively chown, Change ownership of
CumulusMX within alts home folder to
alt, who is a user in the group alt.
once complete, root then hands it back to you.

This tries to give you the best of both worlds, the protection of a user and some of the power of root, only when needed.

So with the above in mind - what happens when you substitute your user for root and install software? Unless action is taken, only root can access it.

Remember how I said Root owns everything? Root also delegates who can do what, such as use a cdrom, access a file share and even print things.

To give you a little more understanding why alt:alt ? Why do you need to be in a group ? From a terminal, type groups you should get something like the following:
On my linux box, as you can see I can access my own files, use the cdrom, use the sudo command, access bluetooth devices, fileshares etc. Yours will be similar. As an example, my user Ian is in the bluetooth group and so I inherit the bluetooth groups access and abilities.

Anyway - don't be scared of sudo, but just wary where you copy and paste code from as without realising you could do yourself some harm -- such as install cumulus in a way that you cant access it

Sudo does not have to be root, although it does assume so if you don't put another user

Su = substitute user
sudo = substitute user do - a set of commands

You could run su ian and then put in my password and then you would be running commands as me (if my account existed on your system) once that line of commands were completed you would remain as me and would need to do su alt to change back.

sudo does the above, but once you hand the batton to my user, my user Ian runs the command and then hands it back to you.

Anyway - I was very bored and thought you now know enough to be dangerous

Use the power to change roots files back to you and once they are in your ownership, you should then be able to launch them as you say without the sudo command.

Sometimes it's important that certain files are owned by root, such as password files and private things you may not wish exposed -- this is especially true if you start hosting your own websites and things. As Cumulus is a pretty well contained application, it does not really need access to important parts of your computer and should be quite happy in most configurations running as you.

Oh goodness, that's longer than I thought it would be ....apologies if it's clear as mud!

After submitting it - I thought I'd paste it into chat GPT to see what it thought and the moment I pasted and sent it came back with

Thank you for the detailed explanation of root, sudo, and su in Unix/Linux systems. You provided a clear understanding of how these commands work and their importance in maintaining system security. It's important to be cautious while using sudo and to be aware of what commands you are executing. Your explanation will be helpful for those who are new to Unix/Linux systems and are looking to learn more about system administration.

I asked ChatGPT:

Do you have any suggestions that would make it better?

and it came back with:

As an AI language model, I don't have personal opinions or preferences, but I can suggest some additional points that might make the explanation more comprehensive:

It's important to note that the sudo command logs all user activity, so it's easy to track who ran what command and when. This makes it easier to audit and troubleshoot issues.

In addition to assigning ownership and group permissions to files and directories, Unix/Linux systems also use file permissions that dictate which users or groups can read, write, or execute files. These permissions can be managed using the chmod command.

It's also worth mentioning that some Unix/Linux distributions have different ways of managing users and permissions. For example, some systems use the wheel group to grant administrative access instead of the sudo command.

Lastly, it's important to emphasize the importance of keeping the system up-to-date with security patches and following best practices for password management, network security, and other security measures to prevent unauthorized access and protect sensitive data.

File permissions are really important if you are hosting your own files and if you don't mark a script as executable - well you wont be able to run that script - but errrrr I decided it was irrelevent to your usage haha.

I remember the days, way back then - at school I'd try to train Eliza to act like an AI, but I'd be disappointed as she always made mistakes - these days with chatgpt, I'm genuinely worried they might be getting too good!