Fedora/CentOS (RPM)

[fc7 123]

As of today the Fedora 23 repo is reporting a new update, but the rpm doesn't exist on the origin server?

 

You may want to clean DNF cache and try again.

 

I just checked and the rpm is in the repo. Be aware that we only provide 64-bit packages.

 

You can check the repo manually with your browser: http://download.opensuse.org/repositories/home:/emby/Fedora_23/x86_64/

[dcrdev 251]

Yeah it goes to this url:

http://suse.lagis.at/repositories/home:/emby/Fedora_23/x86_64/emby-server-3.0.5930-12.1.x86_64.rpm

 

Which doesn't exist?

[fc7 123]

Yeah it goes to this url:

http://suse.lagis.at/repositories/home:/emby/Fedora_23/x86_64/emby-server-3.0.5930-12.1.x86_64.rpm

 

Which doesn't exist?

 

I was able to reproduce the problem with a Fedora 23 VM.

Indeed OBS is redirecting to suse.lagis.at.

This is not happening for every repo. For example CentOS repo is working fine but it's not redirecting to suse.lagis.at but to downloadcontent.opensuse.org.

 

I doubt there is anything we can do from our side to fix this, since I'm afraid that this is a OBS CDN/Mirroring issue.

[88fingerslukee 2]

Some questions

1. Why is the mono version lower in the Fedora 23 repo as opposed to the Fedora 22 repo
2. Can we get an update for mono? I'm having crashes that might be version specific
3. Has anybody had random mono crashes? 

[Luke 37071]

The best version of mono right now is the stable version which is 4.2.3.4

[fc7 123]

 

Some questions

1. Why is the mono version lower in the Fedora 23 repo as opposed to the Fedora 22 repo
2. Can we get an update for mono? I'm having crashes that might be version specific
3. Has anybody had random mono crashes? 

 

 

Mono version should be exactly the same for F22, 23 and CentOS.

We are using exactly the same package but builded for the different distros.

 

I just checked and somehow only the packages for F23 are really old. I don't have an explanation for that but an OBS glitch.

I deleted the current packages and trigger a new build to see if the correct packages are pushed to the repo.

 

I will update the thread later once the rebuild is finished.

[88fingerslukee 2]

Mono version should be exactly the same for F22, 23 and CentOS.

We are using exactly the same package but builded for the different distros.

 

I just checked and somehow only the packages for F23 are really old. I don't have an explanation for that but an OBS glitch.

I deleted the current packages and trigger a new build to see if the correct packages are pushed to the repo.

 

I will update the thread later once the rebuild is finished.

Thanks,

 

I just installed the latest version from the actual mono site by using their CentOS repo. Seems to work just fine. 

 

see here: http://www.mono-project.com/docs/getting-started/install/linux/

[fc7 123]

Thanks,

 

I just installed the latest version from the actual mono site by using their CentOS repo. Seems to work just fine.

 

see here: http://www.mono-project.com/docs/getting-started/install/linux/

 

Sure. That's basically the same since we are just rebuilding the official package without any modification to make things more simple for the new users.

Edited May 4, 2016 by fc7

[fc7 123]

We are now providing mono 4.2.3.4 RPM packages.

This package is a basically a clone from the packages you can find in mono's site, except for a dependancy.

 

PS: there is a problem with F23 mono packages in OBS, they are not updated. I will look into it and update the thread with any news. In the meantime feel free to use the official ones: http://www.mono-project.com/docs/getting-started/install/linux/

[Sinistag 0]

Hi, I'm using emby-server-beta on my f23 on a dedicated server.

Everything was just fine a month ago, but I just tried it again after not using it in some time, and it doesn't work anymore.

When I (re)start the server, it start, take a lot of cpu as usual, I can reach the log in page, but after ~40s, it stop working. I am currently stuck on the spinning wheel after putting my password. What is very strange is that all the mono-sgen thread are still running, taking ram, but with 0% cpu, which is very unusual…

I can't see anything unusual in the log, it just doesn't take anymore request after some time…

I have just updated everything, nothing better.

Thanks

[Luke 37071]

Hi, I'm using emby-server-beta on my f23 on a dedicated server.

Everything was just fine a month ago, but I just tried it again after not using it in some time, and it doesn't work anymore.

When I (re)start the server, it start, take a lot of cpu as usual, I can reach the log in page, but after ~40s, it stop working. I am currently stuck on the spinning wheel after putting my password. What is very strange is that all the mono-sgen thread are still running, taking ram, but with 0% cpu, which is very unusual…

I can't see anything unusual in the log, it just doesn't take anymore request after some time…

I have just updated everything, nothing better.

Thanks

 

Hi, welcome. Please provide the info requested in how to report a problem, and we'll take a look at your issue. Thanks!

[rossome 3]

Is there any ETA on spinning a compatible version for Fedora 24? I've tried install emby-server with the Fedora 23 repo with no avail, it will not install with the updated version of libwebp.

[fc7 123]

Is there any ETA on spinning a compatible version for Fedora 24? I've tried install emby-server with the Fedora 23 repo with no avail, it will not install with the updated version of libwebp.

 

Not yet. But it would not take a long time before the packages are available.

Once they are ready I will post an announcement in this thread.

Edited June 23, 2016 by fc7

[fc7 123]

Announcement: Emby server packages for Fedora 24 are now ready for download. Please check Emby installation instructions in http://emby.media/linux-server.html.

 

Also Emby packages for Fedora 22 will be retired since the distribution is already EOL.

 

Please don't hesitate to report any problems with the new packages for Fedora 24 in this thread.

 

Thanks.

Edited June 23, 2016 by fc7

[rossome 3]

WOW! Thank you so much for the update, that was super fast 

[fc7 123]

WOW! Thank you so much for the update, that was super fast

Enjoy Emby.

 

 

Sent from my iPhone using Tapatalk

[rossome 3]

Actually I'm running into a problem with selinux:

SELinux is preventing emby-server.sh from open access on the file /usr/bin/su

[fc7 123]

 

Actually I'm running into a problem with selinux:

SELinux is preventing emby-server.sh from open access on the file /usr/bin/su

 

The default SELINUX configuration is set to enforce. You need to change it to permissive or disable it (/etc/selinux/config).

 

The other option is to create a SELINUX policy which the current packages doesn't do but you can do it yourself.

 

Remeber that after changin SELINUX configuration you need to reboot the machine so it can take effect.

[-=ypsilon=- 1]

Hello. Just found emby after a brief flirt with plex, love that its open source and haven't really tried it yet, but just the ease to sort my download folder and more advanced config looks really great.

 

Please do not disable SeLinux (its just great at keeping your system protected from illicit code) if you're not just planning on running it on a isolated LAN or really know what your doing... Follow suggestion 2 and create a se policy, its not so hard.

 

Installed on Fedora 24 and first generated these errors first: (code=exited, status=127) and second: (code=exited, status=126)

 

I Have posted it to a SeLinux list for approval, might open up more than necessary, will post back or if anyone can se if its to open? but I think its better than Disabling or setting it to permissive if you don't like to keep an eye on your log all the time.

 

1. sudo audit2allow -w -a

 

2. sudo grep emby-server.sh /var/log/audit/audit.log | audit2allow -M emby-server.sh

 

3. I had to recreate my emby user to have an uid higher than 1001 to be able to su. run "sudo system-control-users" and delete emby and create it with a free/ custom uid over 1001

 

4. sudo systemctl restart emby-server.service

 

5. check if its running "sudo systemctl status emby-server.service -l"

 

Hope that helps.

 

Thanks and Greetings -=ypsilon=-

Edited June 26, 2016 by -=ypsilon=-

[Luke 37071]

Hi, welcome

[wangmaster 0]

The default SELINUX configuration is set to enforce. You need to change it to permissive or disable it (/etc/selinux/config).

 

The other option is to create a SELINUX policy which the current packages doesn't do but you can do it yourself.

 

Remeber that after changin SELINUX configuration you need to reboot the machine so it can take effect.

 

Another solution that seems to work is:

 

ExecStart=/bin/sh -c "/usr/lib/emby-server/emby-server.sh start"

and also changing ExecStopPost to:

ExecStopPost=/bin/sh -c "/usr/lib/emby-server/emby-server.sh clear"

 

Executing as /bin/sh seems to work.

 

 

Hello. Just found emby after a brief flirt with plex, love that its open source and haven't really tried it yet, but just the ease to sort my download folder and more advanced config looks really great.

 

Please do not disable SeLinux (its just great at keeping your system protected from illicit code) if you're not just planning on running it on a isolated LAN or really know what your doing... Follow suggestion 2 and create a se policy, its not so hard.

 

Installed on Fedora 24 and first generated these errors first: (code=exited, status=127) and second: (code=exited, status=126)

 

I Have posted it to a SeLinux list for approval, might open up more than necessary, will post back or if anyone can se if its to open? but I think its better than Disabling or setting it to permissive if you don't like to keep an eye on your log all the time.

 

1. sudo audit2allow -w -a

 

2. sudo grep emby-server.sh /var/log/audit/audit.log | audit2allow -M emby-server.sh

 

I agree with your comments that what you've suggested is better than disabling SELinux entirely, but it also defeats some of the purpose of SELinux.  The specific access controls that prevent the things that the emby start script is trying to do (specifically calling su in a startup script) is something that's probably a good protection.  The audit2allow effectively allows the init_t context (the context that systemd service start up runs at) to have "global" access to exec'ing su, defeating the entire purpose of the specific protection.

 

Arguably the better solution is to create a policy and context specific to emby which can get a bit ugly.

[-=ypsilon=- 1]

This is a much better solution than opening up SeLinux and keeping it out from /sbin I agree. Didn't even think to try that in the rage frenzy of troubleshooting everything that stopped working after an upgrade to 24 from 23 using the new dnf plugin.. I think a full install would have been quicker. And I really wanted to continue binge watching The Big Bang Theory..

 

Will change this to my setup asap. Thanks for the tip Wangmaster......

 

Stay safe

 

Greetings yps

 

Another solution that seems to work is:

 

ExecStart=/bin/sh -c "/usr/lib/emby-server/emby-server.sh start"

and also changing ExecStopPost to:

ExecStopPost=/bin/sh -c "/usr/lib/emby-server/emby-server.sh clear"

 

Executing as /bin/sh seems to work.

 

 

I agree with your comments that what you've suggested is better than disabling SELinux entirely, but it also defeats some of the purpose of SELinux.  The specific access controls that prevent the things that the emby start script is trying to do (specifically calling su in a startup script) is something that's probably a good protection.  The audit2allow effectively allows the init_t context (the context that systemd service start up runs at) to have "global" access to exec'ing su, defeating the entire purpose of the specific protection.

 

Arguably the better solution is to create a policy and context specific to emby which can get a bit ugly.

 

 

Edited June 27, 2016 by -=ypsilon=-

[-=ypsilon=- 1]

 

Another solution that seems to work is:

 

ExecStart=/bin/sh -c "/usr/lib/emby-server/emby-server.sh start"

and also changing ExecStopPost to:

ExecStopPost=/bin/sh -c "/usr/lib/emby-server/emby-server.sh clear"

 

Executing as /bin/sh seems to work.

 

 

I agree with your comments that what you've suggested is better than disabling SELinux entirely, but it also defeats some of the purpose of SELinux.  The specific access controls that prevent the things that the emby start script is trying to do (specifically calling su in a startup script) is something that's probably a good protection.  The audit2allow effectively allows the init_t context (the context that systemd service start up runs at) to have "global" access to exec'ing su, defeating the entire purpose of the specific protection.

 

Arguably the better solution is to create a policy and context specific to emby which can get a bit ugly.

 

 

BTW, what Wangmaster refers to are adding /bin/sh -c in front of the execlines in /etc/systemd/system/multi-user.target.wants/emby-server.service

Making the user call sh -c instead of the root user.

 

sudo gedit /etc/systemd/system/multi-user.target.wants/emby-server.service

 

Paste Wangmasters lines replacing the old ones, the "" is important.

 

ExecStart=/usr/lib/emby-server/emby-server.sh start

ExecStopPost=/usr/lib/emby-server/emby-server.sh clear

to

ExecStart=/bin/sh -c "/usr/lib/emby-server/emby-server.sh start"

ExecStopPost=/bin/sh -c "/usr/lib/emby-server/emby-server.sh clear"

 

sudo systemctl daemon-reload

sudo systemctl start emby-server.service

 

Tried it with the old policy's removed* and SeLinux set to enforce and targeted, and it works like a charm.

 

*

sudo rm emby-server.sh.* from working folder

sudo semodule --remove emby-server.sh

 

Hope I don't spam the thread with oversimplification, but worked most of my career as a support technician and clear instructions is worth gold to me..=)

 

Props again to wangmaster

 

Greetings Yps

Edited June 28, 2016 by -=ypsilon=-

[wangmaster 0]

 

BTW, what Wangmaster refers to are adding /bin/su -c in front of the execlines in /etc/systemd/system/multi-user.target.wants/emby-server.service

Making the user call su -c instead of the root user.

 

 

You mean /bin/sh -c right? You got the config right, but typoed the description

 

I think that the /bin/sh thing works only because, as of right now, something is allowing the transition from the init_t domain to the bin_t domain that /bin/sh executes under.  To me, that seems like a nice workaround but also a fairly large hole that someone might get an itch on and "fix" in the future.  So I am curious how long this might work.

 

Oh and I can't take all the credit.  I learned about this trick (and started reading into selinux transitions) after seeing a similar problem with Plex.

[-=ypsilon=- 1]

"You mean /bin/sh -c right? You got the config right, but typoed the description :)"

 

Yup, even with the best intentions you can still get it wrong. Thanks for the proofreading.

 

 

"Oh and I can't take all the credit.  I learned about this trick (and started reading into selinux transitions) after seeing a similar problem with Plex."

 

Well found emby  for that reason, and stayed for the open source.

 

Haven't really gotten as deep into SeLinux as you might to get it function as secure as possible but still leaving a usable computing experience.

Just react to how many people rather turn it off than work with it and how many developers just expects that you should turn it off so their code can run on your compromised computer. Seems like cutting out your seatbelts because you don't understand the need or think they are to complicated.

 

But is it a emby issue or something in fedora 24 that makes it call for /sbin/sh in the systemd script?

 

Greetings yps