create an empty default welcome file

[mcfnord]

With this change, a Debian installation will create an empty /etc/jamulus/welcome.html file and specify it as the welcome file in the systemd default configuration.

https://github.com/orgs/jamulussoftware/discussions/3086#discussioncomment-6248420

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[pljones]

This will fail if the directory already exists. It will also

Suggested change

	sudo mkdir /etc/jamulus
	sudo mkdir -p /etc/jamulus

[ann0see]

Why is sudo required anyway? If adduser I'd executable meditate should also work without sudo. Nevertheless, I believe there's another way to add files and folders which is then also automatically cleaned up by dpkg/apt. Check out deploy_linux.sh

[mcfnord]

Writing in /etc might require root access, but I can't explain why adduser doesn't in this instance. Should I test this without the sudo?

There is no deploy_linux.sh. Do you mean deploy_deb.sh ?

If I am uninstalling an application, there's a case for intentionally not removing a small file the user has customized. I guess a concern is that if I re-install, I don't expect the previous welcome file?

Are there examples of our files that are handled in the auto-cleanup way you prefer?

[pljones]

This will require the user to edit the file as root (it is being created by root and both owner and group will be root). The file needs to be readable by the user jamulus, and - depending on how the system is already set up - this may not be the case - it may not be readable others.

[mcfnord]

How about:

chmod -c 666 /path/to/file

Everyone can read and write, nobody can execute.

[pljones]

I wouldn't want files installed on a system that any user could edit without control, that were then displayed publicly...

Ideally:

• there would be a jamulus group as well as user
• the file would be placed in a location owned by the jamulus user and owned by jamulus:jamulus
• permissions could then be 0660 - so jamulus user and any user in the jamulus group could edit it - but no one else

This is getting outside the scope of this PR, though, so I think just leaving (with -p) will do for now - so only root can edit. It probably is worth making use it's a+r permissions (i.e. anyone can read, other permissions unchanged).

[mcfnord]

a+r appears to work

[ann0see]

Check jamulus.install file and deploy_deb.sh. I think you just need to move the file to the correct location during deb creation. This ensures the file doesn't get overwritten by updates, I suppose

[mcfnord]

I don't want my custom welcome file to be overwritten when I upgrade.

[ann0see]

Exactly. I think that we might want to add an empty file to the deb directly instead of creating it during install time. But I'm unsure about the actual way config files are handled.

For example I'd like that a apt purge deletes it while an apt remove doesn't.

I found https://wiki.debian.org/ConfigPackages but it doesn't help me.

@mirabilos how should config files be handled correctly in deb files?

[mirabilos]

The usual Debian way: ship it as conffile by placing it in /etc/jamulus/ in the package contents, then it will be placed there on first install by dpkg and later updated with newer versions iff the user did not change it; if the user changed it, they’ll get a chance to merge, keep their changes or throw their changes away. And the file will have proper default root:root 0644 permissions.

[mcfnord]

@ann0see, touch won't overwrite anything. The Debian technique would behave more appropriately with apt purge vs. apt remove, and I guess that's good citizenship. Someday deploying default welcome file metadata could be a thing.

[ann0see]

@mirabilos thanks for answering.

[ann0see]

Before this gets merged, we should check how newly clients behave. Do they show an empty chat window?

[ann0see]

See comments. Also maybe @jujudusud can help out a bit as he knows packaging on Arch (I think).

[mcfnord]

Before this gets merged, we should check how newly clients behave. Do they show an empty chat window?

Yes. There's no content change in the chat window, visually same as if there's no welcome message. Should I also test that getServerProfile returns same results in result.welcomeMessage in both cases?

[ann0see]

Should I also test that getServerProfile returns same results in result.welcomeMessage in both cases?

Yes

[mirabilos]

John Dempsey dixit:

+sudo mkdir /etc/jamulus +sudo touch /etc/jamulus/welcome.html @ann0see, touch won't overwrite anything. This file would behave more @Appropriately with apt purge vs. apt remove, and I guess that's good @CITIZENSHIP. Someday deploying default welcome file metadata could be @A thing.

No. • sudo is not available by default but as this *already* runs as root… • this will not preserve user changes as per Policy if some default content is also deployed • this will need manual cleanup via postrm maintainer scripts on purge

[mcfnord]

Nobody has ever expressed a great usage of metadata in the welcome file. Instead, our docs now mention bad uses for it. I tried to pitch welcome file metadata that our client reads and uses, but rdica and pljones found this idea meritless. So default content remains a fantasy. But littering a 50 byte file is no joke.

[ann0see]

It's still no problem, but we best follow the standard approach.

[mcfnord]

This will apparently be our first usage of conffiles. How can this be? This command would seem to work the same way:

sudo systemctl edit --full jamulus-headless

It shows an editable configuration file, our ./linux/debian/jamulus-headless.service file. I hope if we change a field, then the user would get the option to merge, discard local changes, etc. But I don't see a file named conffiles.

I do see jamulus.install, and jamulus-headless.install, which maybe have the format of a conffile. jamulus-headless.install has a two-token line separated by whitespace, but the first field does not seem like a fflag (and remove-on-upgrade is the only supported flag anyway). Also, these files maybe don't contain absolute pathnames, because lines don't start with a slash, which is a requirement for conffiles.

Why don't I see a file named DEBIAN/conffile? Is that optional? Are we using this mechanism now?

(Once I was framed for a speech crime. After three nights in jail, I was taken to a room to wait for arraignment, where a judge sets the bail. One by one, each defendant was taken before the judge. As they'd return some said there was a television camera in the courtroom. Why? As we ran out of defendants, a math wiz with an opioid addiction calculated that the cameras must be for me. He said a judge can't show weakness on television. He turned to me, pointed at me, and said, "They must be here for you. You're the sacrificial lamb!"

I hope I'm not the sacrificial lamb for conffiles.)

[ann0see]

I don't know the progress of the top of my head, but I remember that the DEBIAN folder is created and populated via the shell script I mentioned. So you'd cp the empty welcome message in there.

1. create an etc folder
2. cp the empty file there
3. that's already in the script, but make sure the deb is built.

[ann0see]

Ah stop. I believe it's just an entry in https://github.com/jamulussoftware/jamulus/blob/main/linux/debian/jamulus-headless.install

[ann0see]

I'd not do it this way.
Modify the files in this folder instead: https://github.com/jamulussoftware/jamulus/tree/main/linux/debian
Add an empty .html file to the directory.

Add the empty file here: https://github.com/jamulussoftware/jamulus/blob/main/linux/debian/jamulus.install and here: https://github.com/jamulussoftware/jamulus/blob/main/linux/debian/jamulus-headless.install

Maybe you'd also need to edit https://github.com/jamulussoftware/jamulus/blob/main/linux/deploy_deb.sh

[pljones]

Closing in favour of #3281