Change jamulus-server to jamulus-headless

[ann0see]

Short description of changes Changes to jamulus-headless as that is the default. I think @mcfnord proposed it somewhere, and we should probably discuss that a bit further. It is probably better to have the default config here.

Context: Fixes an issue? Related issues Plain copy and paste would now work if the default .deb setup is used.

Status of this Pull Request Ready for discussion

What is missing until this pull request can be merged?

Discussion Does this need translation? YES

Checklist

• [x] I've verified that this Pull Request follows the general code principles
• [ ] I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• [ ] I'm sure that this Pull Request goes to the correct branch

[mcfnord]

I entered systemctl status jamulus-headless and did see ten lines of a log. I don't know where my (sys)log is found, but I bet the systemctl status log can be expanded somehow.

[ann0see]

You could just use journalctl to view your syslog.

[pljones]

You could just use journalctl to view your syslog.

journalctl -u jamulus-headless --since 12:20

where -u prefaces the unit name, jamulus-headless is your chosen unit name, --since limits the listing to a particular start time and 12:20 is your chosen start time. You can also add --follow to "tail" the log.

[mcfnord]

I tried --log and couldn't make it work.

-l or --log Enable logging, set path and file name

Is this the same logging that we appear to get for free as a systemd process? Without this parameter, logging appears to occur anyway. With this, nothing seems to change... no new logging appears.

--log does work as a CLI parameter, but I don't believe it works with a systemd process. Nothing appears to become enabled. But of course there are severe restrictions on where a process under systemd can write a file. Still, setting ProtectHome to false, I still couldn't --log /home/ubuntu/mylog.txt

[mcfnord]

I didn't know we say this:

Note: You will need to save recordings to a path outside of the jamulus home directory, or remove ProtectHome=true from your systemd unit file, but be aware that doing could be a security risk.

So we give some clues for people adding --recording. But we only hint about the problem in our coverage of --welcomemessage. Maybe we could provide the equivalent guidance with -w that we provide with --recording. Of course I will fight for years to provide --welcomemessage /etc/jamulus/welcome.html as an empty file. I spoke with another user last night who ran into the welcome message file location nightmare that I hope to end before I die.

[ann0see]

I believe they are all permission errors. So that should be an easy fix with chown jamulus:jamulus /path/to/file

[mcfnord]

I can't think of anything I've specified that chown will fix. Can you? I think (not sure) --log is just broken when running as a systemd process. Heaven help us if we have to create and chown the log file manually before it works. --welcomemessage with a path is just a nightmare by design because systemd prevents processes from using paths that make sense. Maybe we need a section called Running as a Systemd Process. I dunno. With only reference to a broken feature (--log), things do feel a little deficient on this page log-wise.

[ann0see]

because systemd prevents processes from using paths that make sense

Which sounds odd to me, as it should just be a string passed as argument to an executable...

Usually if a file doesn't get created/written to, it's a permission error from my experience

[mcfnord]

By default, we lock people out of most of the places they would think of putting a welcome or log file, when we say:

ProtectSystem=true ProtectHome=true

I guess ProtectSystem isn't so painful or odd, but ProtectHome=read-only would let people use /home/ubuntu/welcome.html or /root/welcome.html which would be great. It's not clear if this could endanger server security, but I imagine it could somehow. Don't get me started about using -w with a literal (non-path) containing HTML! So many escape sequences! Boggling. And so Anne in Toronto settles for a dinky little text message. At least -w isn't simply broken like --log appears to be under systemd.

Incidentally, I can't write sudo chown jamulus:jamulus /home/ubuntu/loggy.txt on my installation. It says invalid group. Could it be because our systemd config says Group=nogroup?

[ann0see]

Could it be because our systemd config says Group=nogroup?

No. Then the Jamulus user is not in a Jamulus group of the system. However, you can try to chown it to jamulus:nogroup

However, as the welcome message is a config like file, by convention it should go to /etc and the logs should go to /var/log. Otherwise I'd find it very confusing if every log is in /var/log but jamulus logs to some home directory?

That's all linux server admin stuff tbh.

[mcfnord]

I very much support -w /etc/jamulus/welcome.html of an empty file as a configuration parameter in our out-of-box default systemd configuration. Anne would follow the breadcrumbs!

I might understand cd ~ and not much else. (That's sorta true.) But --log doesn't work in /var/log either, and the real fix here is to tell people --log doesn't work when running as a systemd process, and use journalctl -u jamulus-headless instead. (They can still use --log when running as CLI.)

Why do you mention that it's all Linux server admin stuff? Previously I've been told here that we prefer to assume Linux server admins don't need us to repeat those fundamentals. Then I talk to Anne and know we lose server opportunities due to this view. What a breakthrough when Anne can easily add HTML to her server welcome message.

You know what else? Our Server Troubleshooting doesn't mention logs. Is that fishy? Does the log ever reveal meaningful failure codes? Or just connection entries-exits and directory registrations?

I hadn't noticed Adding metadata to the Server. I think it is misleading information. I had to step back from the debate about its worthiness because it mentions bots. I thought rather hard about a suitable usage of server metadata. Not contact information! Not bot policy. I hope nobody tries to act on these claims. What if I backed all of this out? I know you want to present a generalized approach. I really want a killer usage of welcome file metadata before mentioning it, but just don't know of one. What we say now seems more unhelpful than helpful.

[ann0see]

Hmm. The jamulus welcome message thing should be kind of doable. Maybe you can open a PR - we might need to change functionality in the code, but if a PR is opened, we can discuss that there too. I think you'd need to edit (and add) files in https://github.com/jamulussoftware/jamulus/tree/main/linux/debian

But --log doesn't work in /var/log either, and the real fix here is to tell people --log doesn't work when running as a systemd process, and use journalctl -u jamulus-headless instead. (They can still use --log when running as CLI.)

Might be the case. I think corrados said somewhere that the log might not be working perfectly? I don't really like the idea of logging anyway (IP address privacy, GDPR discussion).

If the points of mcfnord are actionable, and doable, then they can be implemented. This does not mean that the maintainers implement it - anyone can do.

Nevertheless, I think we should go for this PR and don't get too much off topic.

[mcfnord]

But --log doesn't work in /var/log either, and the real fix here is to tell people --log doesn't work when running as a systemd process, and use journalctl -u jamulus-headless instead. (They can still use --log when running as CLI.)

Might be the case. I think corrados said somewhere that the log might not be working perfectly? I don't really like the idea of logging anyway (IP address privacy, GDPR discussion).

@rdica also asserts --log works under systemctl.

I'm unsuccessful creating log output when running under systemctl and connecting a client. This my ExecStart:

ExecStart=/bin/sh -c 'exec /usr/bin/jamulus-headless -s -n --directoryaddress anygenre2.jamulus.io:22224 --serverinfo "bip;Seattle;US" --log /var/log/jamulus/j.log'

I ran this with no benefit:

ubuntu@ip-172-31-26-212:/var/log/jamulus$ sudo chown jamulus j.log

@ann0see said above that chown jamulus:jamulus would work, but the systemd says:

User=jamulus
Group=nogroup

My Linux ignorance may be the root cause of this faulure. --log documentation should include steps to make it work.

[ann0see]

I think you can just use the normal journalctl and view the log of Jamulus there.

[rdica]

I think @mcfnord makes a valid point about documentation, and how to implement -l|--log properly on a default installation. Since the pkg default is to not write anything to /usr, /boot, /efi, /root, /home, and /run/user, setting a path for -l|--log elsewhere requires that the jamulus process user must be able to write to that destination. This also applies to recordings though that's not mentioned in this thread.

I'm not privy to the decisions regarding the security of the jamulus server process, but it would seem if there's writability built into the program, and a lack of documentation to correctly implement it when using the pkg defaults, that lack should be addressed, or a re-examination regarding the use of those systemd directives in the service file be done in order to ease implemention of logging/recording.

For the record, I use a custom service file without those two systemd directives, and a separate volume for logs and recordings that is owned by the jamulus process user.

[mcfnord]

For --recording we do say this now:

Note: You will need to save recordings to a path outside of the jamulus home directory, or remove ProtectHome=true from your systemd unit file, but be aware that doing could be a security risk.

I'd like to hear a plausible insecurity scenario about ProtectHome=false. And is there really a "jamulus home directory" ? I don't have one. I have /home/ubuntu/ in most cases. Surely this doesn't mean /usr/bin, where jamulus-headless binary sits (by default). I speculate that we're just being cautious, which is ok, except for the ways it shoots --welcome, --log, and --recording in the head. (I will return to /etc/jamulus/welcome.html before I die.)

For --log I think we should say users running jamulus-headless using systemctl should instead use journalctl, which appears to include more details than --log. I still want to see --log working under systemctl in the defaultiest default scenario possible.