I had to roll back to 1.9.7 to get PlexRequests.net back up and running. While I was at it, I did some work getting the app to auto start as a daemon on BusyBox (Which most NASes run on these days.) The scripts and instructions provided here: http://www.htpcguides.com/install-plex-requests-net-ubuntu-14-x/ didn’t work with my model of NAS. Too many things aren’t exactly the same with these versions of Linux…
So this is the edits I had to do to the main start, stop script on that page:
#!/bin/sh
### BEGIN INIT INFO
# Provides: PlexRequests.net
# Required-Start: $local_fs $remote_fs $network
# Required-Stop: $local_fs $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: PlexRequests.net
# Description: PlexRequests.net
### END INIT INFO
# Documentation available at
# http://refspecs.linuxfoundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
# Debian provides some extra functions though
. /lib/lsb/init-functions
USER=admin
GROUP=administrators
DAEMON_NAME="PlexRequests"
DAEMON_USER="${USER}:${GROUP}"
DAEMON_PATH="/usr/local/bin/mono"
DAEMON_PACK_PATH="/volume1/misc/PlexRequests"
DAEMON_OPTS=${DAEMON_PACK_PATH}/PlexRequests.exe
DAEMON_PWD="/volume1/misc/PlexRequests/"
DAEMON_DESC=$(get_lsb_header_val $0 "Short-Description")
DAEMON_PID=${DAEMON_PACK_PATH}/PlexRequests.pid
DAEMON_NICE=0
DAEMON_LOG='/volume1/misc/PlexRequests/PlexRequests.log'
[ -r "/etc/default/${DAEMON_NAME}" ] && . "/etc/default/${DAEMON_NAME}"
do_start() {
local result
pidofproc -p "${DAEMON_PID}" "${DAEMON_PATH}" > /dev/null
if [ $? -eq 0 ]; then
log_warning_msg "${DAEMON_NAME} is already started"
result=0
else
log_daemon_msg "Starting ${DAEMON_DESC}" "${DAEMON_NAME}"
touch "${DAEMON_LOG}"
chown $DAEMON_USER "${DAEMON_LOG}"
chmod u+rw "${DAEMON_LOG}"
if [ -z "${DAEMON_USER}" ]; then
start-stop-daemon -S --background --quiet --chuid "${DAEMON_USER}" --user "${USER}" --pidfile "${DAEMON_PID}" --make-pidfile --exec "$DAEMON_PATH" -- "$DAEMON_OPTS"
result=$?
else
start-stop-daemon -S --background --quiet --chuid "${DAEMON_USER}" --user "${USER}" --pidfile "${DAEMON_PID}" --make-pidfile --exec "$DAEMON_PATH" -- "$DAEMON_OPTS"
result=$?
fi
log_end_msg $result
fi
return $result
}
do_stop() {
local result
pidofproc -p "${DAEMON_PID}" "${DAEMON_PATH}" > /dev/null
if [ $? -ne 0 ]; then
log_warning_msg "${DAEMON_NAME} is not started"
result=0
else
log_daemon_msg "Stopping ${DAEMON_DESC}" "${DAEMON_NAME}"
killproc -p "${DAEMON_PID}" "${DAEMON_PATH}"
result=$?
log_end_msg $result
rm "${DAEMON_PID}"
fi
return $result
}
do_restart() {
local result
do_stop
result=$?
if [ $result = 0 ]; then
do_start
result=$?
fi
return $result
}
do_status() {
local result
status_of_proc -p "${DAEMON_PID}" "${DAEMON_PATH}" "${DAEMON_NAME}"
result=$?
return $result
}
do_usage() {
echo $"Usage: $0 {start | stop | restart | status}"
exit 1
}
case "$1" in
start) do_start; exit $? ;;
stop) do_stop; exit $? ;;
restart) do_restart; exit $? ;;
status) do_status; exit $? ;;
*) do_usage; exit 1 ;;
esac
This gives start, stop and restart, as well as status. Hopefully someone with a lot more experience than I have with scripting can look at this, maybe clean it up a bit, or tell me what I need to do to make it better.
@dynAdZ said:
I have the same issue, I can’t get it to work entirely. I wonder what the c:\projects… references mean since that path obviously doesn’t exist.
The c: reference is a reference to the location where it was compiled, it has nothing to do with your machine.
The error is a bug that i intend on fixing today. Please keep in mind this is a early access preview and not a stable release.
@dynAdZ said:
I have the same issue, I can’t get it to work entirely. I wonder what the c:\projects… references mean since that path obviously doesn’t exist.
The c: reference is a reference to the location where it was compiled, it has nothing to do with your machine.
The error is a bug that i intend on fixing today. Please keep in mind this is a early access preview and not a stable release.
Cool, thanks for the info! I will keep with the 1.8.4 release until the bug is fixed :)>-
@dynAdZ said:
I have the same issue, I can’t get it to work entirely. I wonder what the c:\projects… references mean since that path obviously doesn’t exist.
The c: reference is a reference to the location where it was compiled, it has nothing to do with your machine.
The error is a bug that i intend on fixing today. Please keep in mind this is a early access preview and not a stable release.
Cool, thanks for the info! I will keep with the 1.8.4 release until the bug is fixed :)>-
@tidusjar said:
That’s strange, never encountered that error before. Thanks for reporting it, I’ll make sure I add some better error handling around that. You can always turn off the analytics in the settings.
Therein lies the problem… On a fresh install there is no way to get to the settings…
@tidusjar said:
That’s strange, never encountered that error before. Thanks for reporting it, I’ll make sure I add some better error handling around that. You can always turn off the analytics in the settings.
Therein lies the problem… On a fresh install there is no way to get to the settings…
You are the only person who has currently reported this issue and I cannot recreate it myself , it’s looks like it’s something to do with your DNS not being able to resolve the domain. But i’ll add better handling for it later.
@dynAdZ said:
I have the same issue, I can’t get it to work entirely. I wonder what the c:\projects… references mean since that path obviously doesn’t exist.
The c: reference is a reference to the location where it was compiled, it has nothing to do with your machine.
The error is a bug that i intend on fixing today. Please keep in mind this is a early access preview and not a stable release.
Cool, thanks for the info! I will keep with the 1.8.4 release until the bug is fixed :)>-
@dynAdZ said:
I have the same issue, I can’t get it to work entirely. I wonder what the c:\projects… references mean since that path obviously doesn’t exist.
The c: reference is a reference to the location where it was compiled, it has nothing to do with your machine.
The error is a bug that i intend on fixing today. Please keep in mind this is a early access preview and not a stable release.
Cool, thanks for the info! I will keep with the 1.8.4 release until the bug is fixed :)>-
I could now fix it, I ran into a FileLoadException and the reason was that several .dll files have been blocked. The solution was part of your FAQ already, I had to unblock the archive and then don’t use WinRAR to extract it but the regular Windows Explorer. This would cause all containing files to retain the “unblock” settings and now the program starts as expected.
HI,
I install PlexRequest.net, the problem I have is I can’t access as an administrator. I can’t login with the ID who is administrator, my PLEX.TV ID isn’t admin.
I have no idea where I screw up.
How can modify manually user permissions ?
Thanks for your help
@bigedison said:
HI,
I install PlexRequest.net, the problem I have is I can’t access as an administrator. I can’t login with the ID who is administrator, my PLEX.TV ID isn’t admin.
I have no idea where I screw up.
How can modify manually user permissions ?
Thanks for your help
After an update not too long ago the admin link was missing but all you have to do is add /admin at the end of the url ex: http://yourip:3579/admin
If you changed the port from 3579 then just replace it with the port you are using.
Just wondering - I have Plex account connected but I search for example “Casino”.
I already have Casino in my Plex library - but I get the button to Request it.
Is this normal behaviour or it should say that it already exists?
I’m a bit concerned about the security situation with Ombi. Nobody should be inputting their Plex username and password into a form unless it’s on plex.tv. This software is conditioning people to enter their password into forms on other people’s servers, which is a bad idea. If I’m a user who also operates his own Plex server, I’m definitely not logging into a random person’s Ombi page with my Plex credentials that would potentially give away administrative access.
What this really needs is SSO with Plex. But I am not sure Plex has this. Currently in this very forum there’s a stickied thread that actually encourages 3rd party services to proxy plaintext user credentials, which creates situations just like this. Plex needs to have an on-site, branded sign-in page that generates a token and passes it back to the requesting app/service/whatever. (Edit: Duh, the PIN system exists. It isn’t officially documented, but there are other projects using it. See my post below)
I know local users are a thing but are pretty tedious. It’s honestly easier to just use basic auth with nginx and reverse proxy it.
I also noticed the wiki on Ombi’s github for Debian/Ubuntu installation recommends running Ombi as root (very bad idea).
@honkdazzle said:
I’m a bit concerned about the security situation with Ombi. Nobody should be inputting their Plex username and password into a form unless it’s on plex.tv. This software is conditioning people to enter their password into forms on other people’s servers, which is a bad idea. If I’m a user who also operates his own Plex server, I’m definitely not logging into a random person’s Ombi page with my Plex credentials that would potentially give away administrative access.
No one has forced you to use this application. I do not store any user credentials when it comes to the Plex.Tv integration, all that happens is I call out to Plex’s API to sign the user in. If you are curious, don’t forget the code is available, it’s open source.
What this really needs is SSO with Plex. But I am not sure Plex has this. Currently in this very forum there’s a stickied thread that actually encourages 3rd party services to proxy plaintext user credentials, which creates situations just like this. Plex needs to have an on-site, branded sign-in page that generates a token and passes it back to the requesting app/service/whatever.
I agree with the above
I know local users are a thing but are pretty tedious. It’s honestly easier to just use basic auth with nginx and reverse proxy it.
I also noticed the wiki on Ombi’s github for Debian/Ubuntu installation recommends running Ombi as root (very bad idea).
The Debian/Ubuntu documentation is all community provided, if you have a better way of doing it then you are welcome to edit that page.
@honkdazzle said:
I’m a bit concerned about the security situation with Ombi. Nobody should be inputting their Plex username and password into a form unless it’s on plex.tv. This software is conditioning people to enter their password into forms on other people’s servers, which is a bad idea. If I’m a user who also operates his own Plex server, I’m definitely not logging into a random person’s Ombi page with my Plex credentials that would potentially give away administrative access.
No one has forced you to use this application. I do not store any user credentials when it comes to the Plex.Tv integration, all that happens is I call out to Plex’s API to sign the user in. If you are curious, don’t forget the code is available, it’s open source.
What this really needs is SSO with Plex. But I am not sure Plex has this. Currently in this very forum there’s a stickied thread that actually encourages 3rd party services to proxy plaintext user credentials, which creates situations just like this. Plex needs to have an on-site, branded sign-in page that generates a token and passes it back to the requesting app/service/whatever.
I agree with the above
I know local users are a thing but are pretty tedious. It’s honestly easier to just use basic auth with nginx and reverse proxy it.
I also noticed the wiki on Ombi’s github for Debian/Ubuntu installation recommends running Ombi as root (very bad idea).
The Debian/Ubuntu documentation is all community provided, if you have a better way of doing it then you are welcome to edit that page.
It’s not an attack on the trustworthiness of your code in your repo. The issue is that people logging into an Ombi instance on someone else’s server have no idea whether they can trust that running code with their Plex credentials.
@honkdazzle said:
I’m a bit concerned about the security situation with Ombi. Nobody should be inputting their Plex username and password into a form unless it’s on plex.tv. This software is conditioning people to enter their password into forms on other people’s servers, which is a bad idea. If I’m a user who also operates his own Plex server, I’m definitely not logging into a random person’s Ombi page with my Plex credentials that would potentially give away administrative access.
No one has forced you to use this application. I do not store any user credentials when it comes to the Plex.Tv integration, all that happens is I call out to Plex’s API to sign the user in. If you are curious, don’t forget the code is available, it’s open source.
What this really needs is SSO with Plex. But I am not sure Plex has this. Currently in this very forum there’s a stickied thread that actually encourages 3rd party services to proxy plaintext user credentials, which creates situations just like this. Plex needs to have an on-site, branded sign-in page that generates a token and passes it back to the requesting app/service/whatever.
I agree with the above
I know local users are a thing but are pretty tedious. It’s honestly easier to just use basic auth with nginx and reverse proxy it.
I also noticed the wiki on Ombi’s github for Debian/Ubuntu installation recommends running Ombi as root (very bad idea).
The Debian/Ubuntu documentation is all community provided, if you have a better way of doing it then you are welcome to edit that page.
It’s not an attack on the trustworthiness of your code in your repo. The issue is that people logging into an Ombi instance on someone else’s server have no idea whether they can trust that running code with their Plex credentials.
Ok, thanks for raising your concern. But there is not much I can do about this.
