proper system integration

[6arms1leg]

sorry, for creating so many related issues there already is #135 and #139, but they dont cover the whole issue. there is more. i realized that maybe the stuff that resides in the home directory should also be applied system wide.

suggestions:

• systemd service file (/etc/systemd/system/)
• init.d script (whereever that goes on all the distributions out there)
• config file (in /etc/)
• db (in /var/lib/cherrymusic/)
• log file (/var/log/)

no?

[tilboerner]

i'd rather have it all in one place, because it makes it more consistent across different OSes. :penguin: :tiger: :pig: also, i just personlly like the idea of keeping as much of it together in one directory and put that somewhere easy to find.

even so, we'll soon be able to hotplug specific configuration parts to make stuff like this highly variable.

we should also take into account how we intend cherrymusic to work. is it more like a system service or a something you turn on if you want to listen to some of your music? are we running in a multi-user environment? can different users configure their own music library at some point? is it supposed to be handled mainly by system-wise people who know where to look for things?

you know, i'm still not used to the linux way of scattering the files according to their purpose. "you! my program! that I installed! are you hiding from me?!" makes you run all over the place if you need to deal with different aspects at the same time... anyway, i think we should stick with what most of the people expect and can most easily deal with.

[6arms1leg]

:penguin::tiger::pig:

:tanabata_tree: :facepunch:

also, i just personlly like the idea of keeping as much of it together in one directory and put that somewhere easy to find.

and where would that be? since its mainly a linux server, it should adhere to FHS. and that means moving the files to above (os similar) locations. this "keeping all in one place" practice is no longterm solution and not the linux way. there are tons of reasons why it should be done that way. you mentioned an important one yourself: "i think we should stick with what most of the people expect and can most easily deal with". -> moving the files to different locations according to FHS. e.g. thing of people's server hardware setup. some people have certain parts of their os (/var, /tmp, ...) on different storage/filesystems (for performance or safety reasons), because they expect a certian type of usage on those directories (many small write accesses on "/var", important configuration files in /etc). they would expect that all their programs now write to "/var/log", thats why they put it on a seperate storage or used a certain filesystem, same for "/home", "/etc", ...

well, im not the author of cherrymusic (@devsnd help me out here, please), but i had lots of disscussions about it with @devsnd about it before it existed. my understanding:

is it more like a system service or a something you turn on if you want to listen to some of your music?

its mainy a streaming server, so its running all the time and normally wont get turned off. i think we should leave that behavior to the many thousands other music players out there.

are we running in a multi-user environment?

linux is multi-user. and windows... well, at least it thinks it is.

can different users configure their own music library at some point?

why should they? i thought thats not the purpose of cherrymusic. isnt the whole idea to serve one (big) music library to many users?

is it supposed to be handled mainly by system-wise people who know where to look for things?

at least the cherrymusic admin should know what he is doing. i think a person who runs a server knows what he is doing. a linux user must know his system anyway. leaves us only with windows users and i think many of them dont know what they are doing.

@devsnd, hope im not that wrong, please help us out here (and convince @tilboerner^^).

[tilboerner]

and where would that be?

where it is now, for example: $HOME/.cherrymusic, but that's not what i'm after, here.

the question is, who would we like to profit from cherrymusic? these are the people we must make using cherrymusic easy for.

at least the cherrymusic admin should know what he is doing

of course. however, the implication of that is, if you turn it around: how much do we require people to have to know to be able to run (= admininistrate) cherrymusic?

how multiplatform do we want to be? and if we want to be mainly about linux, which linux populations do we care about? arch? mint? ubuntu? how many of these people are run a true multi-user setup, as opposed to a personal system with a couple of sys accounts they don't know about? there are different levels of "linux savvy" we can assume there. what comes easy for some will confound others (and people do not read manuals, an aggravating factor). i think you'll find a lot of linux users who don't know their way around the filesystem, and i think the more we "systemize" everything, the higher the bar becomes for potential admins. users.

i'm not arguing because of my personal preferences here. (if i appear to, than just because i put myself in harm's way to serve as an example. ^^) i'm arguing because i think these things should be considered, that's why i'm posing them as questions, real, open ended questions, that are not meant to stand in for final conclusions.

[6arms1leg]

where it is now, for example: $HOME/.cherrymusic [...]

deleting a user then means loosing all data of a server application... the linux way is having both: systemwide configs and local user specific configs in the home directory. user specific configs take precedence.

i think you'll find a lot of linux users who don't know their way around the filesystem[...]

they are probably not after a music streaming server and will use a standard music player anyway.

how much do we require people to have to know to be able to run (= admininistrate) cherrymusic?

on linux: they have to know how to install a program (at least via their distributions package menagement). if they are able to install a program under linux they know the standard procedure to configure it: look for a config in $HOME and /etc. finetuning is then up to the skill of the user.

[...] which linux populations do we care about?

we assume a couple of standards, which sadly should be debian. its a big "main" distribution, on which many others are based. if it runs on debian, it probably can be run on ubuntu and most other distributions. arch linux, gentoo etc are no problem anyway, since they are rolling release distributions and far ahead of debian anyway.

how many of these people are run a true multi-user setup, as opposed to a personal system with a couple of guest and sys accounts?

covered by a config in $HOME and /etc.

in my opinion, going with the linux standards is the best and easiest way.

[tilboerner]

you're right. still, it's all a matter of perspective to me.

although it certainly is one, i think of cherrymusic not so much as a music streaming server, but as a way to have your music library follow you wherever you go, as long as you keep can keep [your pc | whatever box you use] online. that makes it very interesting for people who have no idea what to do with the concept of a "streaming server".

these people run windows, macOS and ubuntu, not debian; and they don't ever delete their user. they don't know what '/etc' is, and why should they, 'etc' doesn't sound very interesting, anyway. they know about their home folder, they know how to download and doubleclick a file, and they know the software manager.

on the other hand, if you're a linux admin who wants to run a server as a system service, couldn't you have a special user with limited privileges to own that service? and maybe we can make you jump through one extra hoop to get everything set up really linux-y. yeah, that's package management going down the drain there. :)

[6arms1leg]

although it certainly is one, i think of cherrymusic not so much as a music streaming server, but as a way to have your music library follow you wherever you go, as long as you keep can keep [your pc | whatever box you use] online. that makes it very interesting for people who have no idea what to do with the concept of a "streaming server".

and how would they do this without a static ip or some kind of dyndns? they have to figure out how to reach their computer at home from the internet (static ip/dyndns), not to mention port forwarding in the router, safe setups for ssh, etc... at that point we can expect our users to have some kind of understanding what a server is and how it runs. if they dont, they shouldnt make their computer available in the internet anyway. before they even start using cherrymusic over the internet they at least have to configure ssh (and therefor edit sshd_config) for security reasons. if they can do that, they can figure out how to use cherrymusic.

on the other hand, if you're a linux admin who wants to run a server as a system service, couldn't you have a special user with limited privileges to own that service?

that should be done in any case. dropping root privileges after startup if they are not needed for a service is a must. a dedicated user for that is a way to achive this. but still then config files, log files and the music library should be in the appropriate places according to FHS.

[tilboerner]

and how would they do this [networking stuff]?

ah, dynamic IPs, hadn't thought of that. well yeah, needing dyndns makes it tough. ^^ but if you get internet through cable, your IP could be pretty static, and if you then know how to find whatsmyip.com and can click through your router's GUI, you're not totally lost. do you need SSH if you run it on your home box? so this is who i'm thinking about: someone who has a working knowledge of what an internet is and how it comes to live in the box by his phone. sets his own WiFi password, knows what an IP address is, and even knows about ports. someone who could be sitting on his roof, listening to his music through his iPhone because his WiFi reaches up there!

so you see, i still think we're talking different levels of proficiency here. i never thought that any dildo with a windows should be able to run cherrymusic, but i also think that you shouldn't need to have put together your system from the command line, either. i'm just not convinced that's necessary. i could be wrong.

also, what about those other platforms, windows and mac? how much of an effort do we want to make there? do we want to go there at some point?

looking beyond this filesystem issue, we should establish what kind of user we want to cater to, because it's relevant to other questions as well. in a way it comes down to how much effort it's gonna cost to provide comfort for more people. ideally, i'd like cherrymusic to be useable without digging through systemctl manpages and knowing where a daemon goes to dump his logs. nonetheless, i'm okay with the pure linux admin path, if that's what we decide. but til wanna have clear picture! :)

so i'll shut up now. other opinions?

[6arms1leg]

someone who could be sitting on his roof, listening to his music through his iPhone because his WiFi reaches up there!

good point, thats more realistic. but if you want to achieve something you got to work for it. if you plan such a project, you should get yourself familiar how to get it done. why should we cripple cherrymusic just to stay atractive to stupid users who are too lazy to read a few man or wiki pages. i dont like this attitude of "hey, i want to get this thing running but im too lazy and stupid to find out how it works". we are not apple, who expect their users to be unable to do anything but clicking its one-button mouse with one finger and try to sell systems with "features" like "time machine" or "siri". (why exaclty would i want to set up an alarm-clock by speech?) why should we care about this type of user? how about this solution: one of us writes a nice step-by-step and idiot-proof wiki page about how to set it all up safely and easily on linux. good?

also, what about those other platforms, windows and mac? how much of an effort do we want to make there? do we want to go there at some point?

thats up to you. i might be ignorant, but i dont care about these systems. i cant stand apple nor windows. in my opinion its a waste of time to care about these systems. just because cherrymusic could be multi-platform doesnt mean it has to. if it could be done with minimal effort, sure thats fine. but it will give you headaches and draws you away from fixing important bugs in cherrymusic itself.

looking beyond this filesystem issue, we should establish what kind of user we want to cater to, because it's relevant to other questions as well. in a way it comes down to how much effort it's gonna cost to provide comfort for more people. ideally, i'd like cherrymusic to be useable without digging through systemctl manpages and knowing where a daemon goes to dump his logs. nonetheless, i'm okay with the pure linux admin path, if that's what we decide. but til wanna have clear picture! :)

i give up. you are the developer here, but i have the feeling that you still think of cherrymusic as some sort of itunes replacement. basically, its a streaming server. people who dont understand the meaning wont touch it. only people who know what they are after will be interested in this software. they know what a streaming server does, then they know how to set it up. if not, they know how to read a wiki page and follow an easy tutorial.

[devsnd]

Alright, first, I want to give you my opinion of what cherrymusic should and should not be, and secondly I will try to propose a solution to get over these problems.

For me, cherrymusic is about replacing all music players on all possible devices. I'm tired of finding my MP3 player not having the music on it I'd like to hear right now. This is priority number one. We have to make a clear destinction between its purpose and its inner workings here. The purpose is to do it in a way, that you didn't even notice that you have just abondoned all other player because:

• It's incredibly easy to set up
• I works on all devices
• It gives me sufficiently more features / less hassle than a file server
• It is less bloated than the "big" players

Now to the technical aspects:

• It comes in a package for linux (arch/debian for now)
• It stays compatible with a single user setup (and therefore with OSX and Windows)
• It can be started as a daemon using sysv or systemd

For me the reasoning to keep a single user setup possible are manyfold. First, it makes it much easier to test. Second, it separates the OS internals from the program, which will make the program cleaner and will therefore give us the freedom of making it work on Windows and OSX. Also, cherrymusic still will be able to run using mod_python in apache, which could be a big plus for someone not wanting cherrypy directly listening to the internet.

Possible solution: When cherrymusic is installed using a package, a cherrymusic user is created. This user gets a symlinked configuration file pointing to /etc/cherrymusic/config. The databases however will stay in its home dir. The sysv/systemd init scripts dont call /usr/bin/cherrymusic on startup, but /usr/sbin/cherrymusicd, which will be a script that starts cherrymusic as the cherrymusic user and daemonizes it. This script also will be able to talk to the daemon, for example to start a db-update or to stop cherrymusic.

In this way, we can package all needed functionality to comply with linux standards, while maintaining the freedom to move to other platforms.

[6arms1leg]

great! actually, thats what i suggested in the opening post, except for moving the database and log file. its your decision and i dont want to get on your nerves by expanding this discussion any further, but why dont we put the database and log in the apropriate places on linux? why does it breaks compatibility? i mean, the setup for mac osx and windows is different anyway, the package manager could take of it. it would have lots of advantages (s.o.). just asking out of interest...

[6arms1leg]

there is a new comment in the aur for the cherrymusic master package from user roukoswarf, who provided a systemd service file. i hesitate to include it in the pkgbuild because this issue here hasnt been addressed yet. providing a systemd service file with the cherrymusic pkgbuild would be a major security risk as it would run cherrymusic as root. also, if running as a system service, it needs its files to be installed according to FHS. we discussed both of these problems thoroughly in this issue here (see discussion above). if you agree, i will hold back the systemd service file for cherrymusic's pkgbuild until:

• [ ] cherrymusic has a mechanism to drop root privileges on startup and switches to run as a regular user
• [ ] cherrymusic's system files are placed into the right places according to FHS

---

NOTE: the following part of this post is outdated, see the cherrymusic arch linux wiki page for up-to-date information!

until then, people who still want to start cherrymusic using a systemd service file can do so by copy-and-paste the systemd service file provided in the comments. however, i would advise against it. as a temporarely workaround (to improve security) the line (in the systemd service file provided in the aur comments, see link above)

ExecStart=/usr/bin/cherrymusic

could be changed to

User=USER
ExecStart=/usr/bin/cherrymusic
Restart=always

where USER is the user that will run cherrymusic. (this is untested, though! im not sure if this works...) EDIT: this method seems to work fine.

2nd EDIT: see the cherrymusic arch linux wiki page on how to correctly set it all up. in short:

$ sudo cp cherrymusic.service /usr/lib/systemd/system/cherrymusic.service
$ sudo chmod 644 /usr/lib/systemd/system/cherrymusic.service
$ sudo systemctl enable cherrymusic.service
$ sudo systemctl start cherrymusic.service

[6arms1leg]

ok, i read a little about systemd service files and found a safe way to run cherrymusic as non-root.

i just included systemd service files in both aur packages... to see how to use it or for the debug version (using gnu screen) have a look at the arch wiki page. another source would be the comments on the cherrymusic master package.

this does not make the todo list in the post above obsolete, because this is no solution for sysv.

[devsnd]

Is systemV cross compatible with all distributions, or do we have to ake special systemV startup files for each individual distribution? Depending on that, we should first start to make CherryMusic FSH-compatible and tren create a sample sysV, which works at least on, say, debian...

[6arms1leg]

Is systemV cross compatible with all distributions, or do we have to ake special systemV startup files for each individual distribution?

sysv startup files are (like most of the old skool init stuff) simple shell scripts, they should work on all systems that use sysv. the process to enable a sysv startup script may vary, so do the paths... but that would be easy to adjust.

[Suika]

Made an init script for cherrymusic, if someone is interested. Tested only on Debian. Note: No backup before update...

https://github.com/Lord-Simon/Scripts/blob/master/cherrymusic

[devsnd]

Hey @Lord-Simon, Thanks for your contribution, this looks quite handy! I've added it to the wiki for anyone to find (https://github.com/devsnd/cherrymusic/wiki/Setup-guide#running-as-debian-daemon)

Would you also know how to package DEBs for debian? I'd love to offer distribution packages that work out of the box and include the corresponding startup scripts...

[Suika]

Hm... not really. I've never packaged python packages, but I'll look into it. And when I've made it run, I'll tell you.

But first, I'd like to publish it to PyPi. If you have nothing against it.

[Suika]

Registered CherryMusic at PyPi: https://pypi.python.org/pypi/CherryMusic

[Suika]

Ok, I uploaded the debian folder to https://github.com/Lord-Simon/cherrymusic-conf

It's a bit crude at the moment and can't be uploaded to Debian repos untill it's completely clean. But it works, except the python3 package.

If you want to have a python3 cherrymusic package, you have to wait untill python3-cherrypy3 is out of sid or the user has to go over to the unstable repository. Probably the first.

Also, to make it work correctly #428 has to be resolved.

I will update it from time to time until it's clean.