[mythtv-users] Fwd: Re: Fwd: Re: Mythfrontend freezing and VDPAU?

Greg Oliver oliver.greg at gmail.com
Fri Mar 6 03:44:56 UTC 2020


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
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200305/1a32f4bf/attachment.htm>


More information about the mythtv-users mailing list