[mythtv-users] Fwd: Re: Fwd: Re: Mythfrontend freezing and VDPAU?
Allen Edwards
allen.p.edwards at gmail.com
Fri Mar 6 03:50:54 UTC 2020
On Thu, Mar 5, 2020 at 7:45 PM Greg Oliver <oliver.greg at gmail.com> wrote:
> On Thu, Mar 5, 2020 at 9:40 PM Allen Edwards <allen.p.edwards at gmail.com>
> wrote:
>
>>
>>
>> On Thu, Mar 5, 2020 at 7:07 PM Stephen Worthington <
>> stephen_agent at jsw.gen.nz> wrote:
>>
>>> On Thu, 5 Mar 2020 09:40:12 -0800, you wrote:
>>>
>>> >On Thu, Mar 5, 2020 at 8:50 AM Stephen Worthington <
>>> stephen_agent at jsw.gen.nz>
>>> >wrote:
>>> >
>>> >> On Thu, 5 Mar 2020 07:19:49 -0800, you wrote:
>>> >>
>>> >>
>>> >> >Thank you for this. I have modified my killgui.sh file to add sudo
>>> >> >
>>> >> >
>>> >> >*#!/bin/bash while [ true ]; do sudo
>>> systemctl
>>> >> >isolate multi-user.target if [ $? -eq 0 ]; then
>>> >> > sudo systemctl isolate graphical.target
>>> exit 0
>>> >> > fi sleep 1 done*
>>> >> >
>>> >> >I created a test file that will only run with root permissions and
>>> put it
>>> >> >in /etc/sudoers.d/ and changed the permissions and it runs.
>>> >> >*chown root:mythtv*
>>> >> >*chmod ug=rx,o=*
>>> >> >
>>> >> >My plan is to wait until I have a real lockup and run the file
>>> manually.
>>> >> >When that test is successful, I will modify*
>>> /home/dad/.mythtv/lircrc*
>>> >> like
>>> >> >this
>>> >> >
>>> >> >*config = /etc/sudoers.d/killgui.sh &*
>>> >> >
>>> >> >Hopefully I have this all correct. Please let me know if I screwed
>>> >> >anything up :-)
>>> >> >
>>> >> >Allen
>>> >>
>>> >> Looks like you have things a bit back to front there. Either the
>>> >> killgui.sh file needs to be run using sudo (and therefore needs an
>>> >> sudoers.d entry to allow it to be run without a password), or
>>> >> killgui.sh needs to call another file using sudo that can run
>>> >> systemctl. Killgui.sh can not directly run things using sudo. And
>>> >> the sudoers.d files are not executables - they are sudoer config files
>>> >> that provide sudo permissions to the executables.
>>> >>
>>> >> So one way to do it would be to remove the sudo commands in killgui.sh
>>> >> and run the whole of killgui.sh using sudo. Then it can run systemctl
>>> >> directly without sudo.
>>> >>
>>> >> Then you need to work out what user things will be run from when you
>>> >> run them from a button in lirc, and set up the sudoers.d file for
>>> >> killgui to allow it to be run from that user without a password.
>>> >> Running the whoami command from the killgui script and storing the
>>> >> output of it to a file in /tmp should show the username. When that
>>> >> logging is working, run it from a lirc button.
>>> >>
>>> >> So if killgui.sh is in /usr/local/bin and it will be run from user
>>> >> lirc, then you would need a /etc/sudoers.d/killgui file that contains
>>> >> something like this:
>>> >>
>>> >> lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh
>>> >>
>>> >> The /etc/sudoers.d/killgui file must be chown root:root and chmod
>>> >> u=r,g=r or it will be ignored.
>>> >>
>>> >> The killgui.sh file needs to be run using sudo, so the command in the
>>> >> lirc config file would be something like this:
>>> >>
>>> >> config = sudo /usr/local/bin/killgui.sh &
>>> >>
>>> >> To do it the other way around, you would replace the sudo systemctl
>>> >> commands in killgui.sh with calls to a helper script. So
>>> >> /usr/local/bin/killgui-helper.sh might look like this:
>>> >>
>>> >> #!/bin/bash
>>> >>
>>> >> if [ "$1" == "" ]; then
>>> >>
>>> >> exit 1
>>> >>
>>> >> elif [ "$1" == "graphical" || [ "$1" == "multi-user" ]; then
>>> >>
>>> >> # Execute systemctl isolate command on the specified target.
>>> >> systemctl isolate $1.target
>>> >>
>>> >> else
>>> >>
>>> >> exit 2
>>> >>
>>> >> fi
>>> >>
>>> >> and in killgui.sh you would replace "sudo systemctl isolate
>>> >> graphical.target" with:
>>> >>
>>> >> sudo killgui-helper.sh graphical
>>> >>
>>> >> and you would have /etc/sudoers.d/killgui-helper with this:
>>> >>
>>> >> lirc ALL=NOPASSWD:/usr/local/bin/killgui-helper.sh
>>> >>
>>> >> and the lirc config would be:
>>> >>
>>> >> config = /usr/local/bin/killgui.sh &
>>> >>
>>> >> The second way is more complicated (it takes two scripts), but easier
>>> >> to use as you can run killgui.sh directly from any user specified in
>>> >> the sudoers.d file without using sudo. So if you want to be able to
>>> >> ssh into the MythTV box as user "dad", user "mythtv" or any user in
>>> >> the "mythtv" group and run killgui.sh manually as well as via a lirc
>>> >> button, your /etc/sudoers.d/killgui-helper file would look like this:
>>> >>
>>> >> lirc,dad,mythtv,%mythtv ALL=NOPASSWD:/usr/local/bin/killgui-helper.sh
>>> >>
>>> >>
>>> >I see now that my test was not good as I had already entered my
>>> password in
>>> >previous testing so the system did not ask me again when I did the test
>>> and
>>> >thus I thought I had it nailed. I just tried again and password was
>>> >requested so obviously I had it screwed up as feared and as you have
>>> >pointed out.
>>> >
>>> >There obviously is a lot to learn on this sudoers thing that I do not
>>> >understand. I will try the things you have suggested and see if I can
>>> >figure it out.
>>> >
>>> >I am not concerned about being able to run the file from multiple users
>>> as
>>> >I can just have multiple copies of the file.
>>> >
>>> >One question just to clarify. If my file is called killgui.sh I think
>>> you
>>> >are saying I would create a file
>>> >*/etc/sudoers.d/killgui*
>>> >with this single line in it
>>> >* lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh *
>>> >
>>> >This assumes I have figured out that the user is *lirc *as you
>>> suggested.
>>> >
>>> >I just want to verify that the file is called */etc/sudoers.d/killgui*
>>> and
>>> >not */etc/sudoers.d/killgui.sh*
>>> >
>>> >Thanks,
>>> >
>>> >Allen
>>>
>>> You sound like I felt when I first tried using sudoers. As usual, the
>>> man files are written as a reference for someone who already knows how
>>> to do it and just needs to confirm the details. I never did find a
>>> really good tutorial on the net, but I did find examples on how to do
>>> it. So I would not classify myself as an expert on the subject, but I
>>> can make it work when I need it.
>>>
>>> In most cases, the name of a config file in an *.d directory has no
>>> meaning except to the humans involved. This is the case for
>>> /etc/sudoers.d. So you can use whatever name you like for the
>>> /etc/sudoers.d config files. Only the contents matters. I consider
>>> it a bad idea to put .sh on a file name when that file is not, in
>>> fact, a shell script, hence why I dropped it in my examples. The
>>> sudoers config files can contain as many lines of config as you like.
>>> The lines do not need to be related to each other. See the
>>> /etc/sudoers file for examples. At the end of that file, you will see
>>> where it has an include line that reads all the files in
>>> /etc/sudoers.d.
>>>
>>> In the line "lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh", the
>>> "/usr/local/bin/kullgui.sh" bit after the colon identifies the program
>>> or script that is being given sudo permissions. The "ALL=NOPASSWD:"
>>> bit tells what sudo permissions are being given - it can do anything
>>> that sudo allows ("ALL") and it can do it without having to ask for a
>>> password ("NOPASSWD"). The "lirc" at the left hand side is who is
>>> allowed this sudo permission. It is actually a comma separated list
>>> of usernames, group names (with % in front) and other things. See
>>> "man sudoers" for the full syntax. So specifying "lirc" says that
>>> these special sudo permissions only apply when the script or program
>>> is being run by user "lirc".
>>>
>>> The sudoers permissions just allow the specified program or script to
>>> be run using sudo. As far as I know, there is no way to allow users
>>> who do not have the correct permissions to run systemctl to run it
>>> without using sudo. So if you were to set up /bin/systemctl in an
>>> sudoers file, you would still need to run it using "sudo systemctl".
>>> If you really want to be able to run anything from a user, you could
>>> try adding that user to the root group. I have never done this, so I
>>> do not know how well it would work. And it clearly is a dangerous
>>> thing to do.
>>>
>>> If all you need is to be able to ssh to the box and execute any
>>> command you want to, then the obvious way to do that is to set it up
>>> so you can log in as root instead of your normal MythTV username. To
>>> do that, you need to edit the /etc/ssh/sshd_config file and change the
>>> PermitRootLogin line to read:
>>>
>>> PermitRootLogin yes
>>>
>>> then restart the sshd daemon:
>>>
>>> sudo systemctl restart sshd
>>>
>>> Then, if you have not already done so, you need to add a password to
>>> the root account:
>>>
>>> sudo passwd
>>>
>>> For ease of use, you can make it the same password as the normal user
>>> on the MythTV box if you like.
>>>
>>> I normally do this bit of setup as the first thing I do on a new Linux
>>> system, as I always need full root access for something.
>>>
>>> If you do not have the above setup on a box, and so can not login as
>>> root directly, then it is still easy to use the root account. Just
>>> login as a normal user that has sudo capability and run this command:
>>>
>>> sudo su
>>>
>>> You will be asked for the sudo password once, and will then be running
>>> as the root user. The "su" command is "set user". Without any
>>> options, it sets the user to "root". This command usually works on
>>> things like Linux based routers too - it is very convenient once you
>>> have learnt it. Unfortunately, it does not work on Android phones, as
>>> Android has been set up specifically to prevent it.
>>>
>>>
>> It looks like this is pretty straightforward assuming I can figure out
>> the user. Just to confirm
>>
>> file: */etc/sudoers.d/killgui*
>> contents: *lirc ALL=NOPASSWD:/usr/local/bin/killgui.sh*
>>
>> Then modify killgui.sh to remove the sudo
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *dad at NewMyth:~$ more killgui.sh#!/bin/bash while [ true ]; do
>> systemctl isolate multi-user.target if [ $?
>> -eq 0 ]; then systemctl isolate graphical.target
>> exit 0 fi sleep 1 done*
>>
>> and call it
>> *config = sudo /etc/sudoers.d/killgui.sh &*
>>
>>
>> If I understand things correctly, lirc is not going to be the user
>> because it is not in the list of users
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *_aptavahiavahi-autoipdbackupbincolorddaddaemondnsmasqgamesgnatshplipirckernoopslightdmlistlpmailmanmessagebusmysqlmythtvnewsnobodyntpproxypulserootrtkitsanedsshdsyncsyssyslogsystemd-bus-proxysystemd-networksystemd-resolvesystemd-timesyncusbmuxuucpuuiddwhoopsiewww-data*
>>
>> The suggestion was to make a test file that has this line in it
>> *whoami > somefile*
>>
>
> ps auwwxf|grep lirc
>
> will list the user in the 1st column. If lirc is running as root, you do
> not need sudo at all :)
>
>
>
>> and call it with the remote and look at somefile to see who the user is.
>> According to the lirc documentation (which isn't always right) lirc runs as
>> root. That would make my entry into sudoers.d as
>> *root ALL=NOPASSWD:/usr/local/bin/killgui.sh*
>>
>> For reference. I start lircd in /etc/rc/local
>>
>>
>> *killall lircdlircd -H udp -d 5000*
>>
>> The input for my remote is my HDHomerun. I never could figure out where
>> lircd was started and consider what I did a hack but it works. Perhaps this
>> means that I am running lircd as root.
>>
>> How am I doing?
>>
>> Allen
>>
>
haha.
*root 1104 0.0 0.0 6352 1560 ? Ss Mar04 0:00 lircd -H
udp -d 5000 *
So all I need to do is call the script and I don't need to fool with
sudoers at all. Well, that makes it easier.
Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200305/39455820/attachment.htm>
More information about the mythtv-users
mailing list