On Thu, Nov 17, 2011 at 3:41 PM, Jeffrey Ollie wrote:
> On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote:
>> Ok, reviving this conversation!
>>
>> I ran into the issue that user "mythtv" can not create the file
>> "/var/run/mythbackend.pid". I see other services that have their pid
>> file own
On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote:
> Ok, reviving this conversation!
>
> I ran into the issue that user "mythtv" can not create the file
> "/var/run/mythbackend.pid". I see other services that have their pid
> file owned by their own user...
systemd doesn't really need a PID fil
Ok, reviving this conversation!
I ran into the issue that user "mythtv" can not create the file
"/var/run/mythbackend.pid". I see other services that have their pid
file owned by their own user...
Also, user "mythtv" can't write to the log file in /var/log/mythtv/
How do I do this with systemd?
On Fri, Oct 21, 2011 at 11:44 AM, Toshio Kuratomi wrote:
> On Wed, Oct 19, 2011 at 06:53:12PM -0500, Richard Shaw wrote:
>> You're right, an ACL approach may be better. But my sql-fu isn't
>> really up to the task. For this to work:
>>
>> 1. mysqld would have to be running.
>> 2. I would have to s
On 21/10/11 17:44, Toshio Kuratomi wrote:
> On top of that, if I've been following the thread right, the previous rpm
> ran as a mythbackend user -- so it's only people who customized away from
> that to a root user that will have this migration issue, correct?
No - the current RPMs have the abil
On Wed, Oct 19, 2011 at 06:53:12PM -0500, Richard Shaw wrote:
> On Wed, Oct 19, 2011 at 6:34 PM, Lennart Poettering
> wrote:
> > On Wed, 19.10.11 18:28, Richard Shaw (hobbes1...@gmail.com) wrote:
> >> Well, as I had already mentioned I more or less relented, so I'm all
> >> for the a/v group metho
2011/10/20 "Jóhann B. Guðmundsson" :
> On 10/19/2011 08:29 PM, Lennart Poettering wrote:
>> The After=syslog.target is unnecessary these days and should be removed
>> to keep things simple.
>
> If you expect upstream to ship unit files then you must realize that
> upstream needs to ship a unit fil
On 10/19/2011 08:29 PM, Lennart Poettering wrote:
> The After=syslog.target is unnecessary these days and should be removed
> to keep things simple.
If you expect upstream to ship unit files then you must realize that
upstream needs to ship a unit file that works across distribution on
what eve
On 10/19/2011 09:48 PM, Richard Shaw wrote:
> That will work for the user, however, I was also going to allow for
> additional options from the sysconfig file, but $OPTIONS wasn't being
> expand either.
sysconfig files for daemons kinda is obsolete these days either write
the daemon to parse a co
On Wed, Oct 19, 2011 at 6:34 PM, Lennart Poettering
wrote:
> On Wed, 19.10.11 18:28, Richard Shaw (hobbes1...@gmail.com) wrote:
>> Well, as I had already mentioned I more or less relented, so I'm all
>> for the a/v group method. My main concern is how to apply this. If
>> someone has already been
On Wed, 2011-10-19 at 18:28 -0500, Richard Shaw wrote:
> In order to fix this retroactively, I would have to do an sql query
> using the login credentials for mythbackend and pull the recording
> groups, then go to each recording group directory and chown all the
> recordings. That's a mess.
Yeah
On Wed, 19.10.11 18:28, Richard Shaw (hobbes1...@gmail.com) wrote:
>
> On Wed, Oct 19, 2011 at 5:09 PM, Lennart Poettering
> wrote:
> > On Wed, 19.10.11 16:20, Richard Shaw (hobbes1...@gmail.com) wrote:
> >> Ok based on Tom's file I came up with the following. I know Lennart,
> >> you don't like
On Wed, Oct 19, 2011 at 5:09 PM, Lennart Poettering
wrote:
> On Wed, 19.10.11 16:20, Richard Shaw (hobbes1...@gmail.com) wrote:
>> Ok based on Tom's file I came up with the following. I know Lennart,
>> you don't like setting ACL's from Systemd, but unless someone want's
>> to help me write udev r
On Wed, 19.10.11 23:43, Kay Sievers (kay.siev...@vrfy.org) wrote:
> >> Like mentioned earlier in this thread, just put the user into the
> >> audio/video system group and forget about any permissions management.
> >
> > That works for me. I wonder if I could use ExecStartPre to run a shell
> > scr
On Wed, 19.10.11 16:20, Richard Shaw (hobbes1...@gmail.com) wrote:
>
> On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote:
> > On 19/10/11 21:48, Richard Shaw wrote:
> >>
> >> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering
> >> wrote:
> >>>
> >>> You should manage acess control of device n
On 10/20/2011 03:18 AM, Richard Shaw wrote:
> That will work for the user, however, I was also going to allow for
> additional options from the sysconfig file, but $OPTIONS wasn't being
> expand either.
Don't use a sysconfig file. Let the user copy the service file from lib
to etc or use the inc
On 19/10/11 22:34, Tom Hughes wrote:
> On 19/10/11 22:27, Kay Sievers wrote:
>
>> Like mentioned earlier in this thread, just put the user into the
>> audio/video system group and forget about any permissions management.
>
> My unit was based on a translation of the old init scripts but yes, it
> l
On Wed, Oct 19, 2011 at 4:43 PM, Kay Sievers wrote:
> On Wed, Oct 19, 2011 at 23:35, Richard Shaw wrote:
>> That works for me. I wonder if I could use ExecStartPre to run a shell
>> script to make sure the user is in those groups and write to stderr if
>> not?
>
> That's a job for a %pre RPM scri
On Wed, Oct 19, 2011 at 4:41 PM, Adam Williamson wrote:
> I'd think best practice here would be for mythbackend package to create
> a mythbackend user which is a member of audio and video groups, and have
> the startup script run mythbackend as that user...would there be any
> problem with that ap
On Wed, Oct 19, 2011 at 23:35, Richard Shaw wrote:
> On Wed, Oct 19, 2011 at 4:27 PM, Kay Sievers wrote:
>> On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote:
>>> On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote:
On 19/10/11 21:48, Richard Shaw wrote:
>
> On Wed, Oct 19, 2011 at 3
On Wed, 2011-10-19 at 16:35 -0500, Richard Shaw wrote:
> On Wed, Oct 19, 2011 at 4:27 PM, Kay Sievers wrote:
> > On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote:
> >> On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote:
> >>> On 19/10/11 21:48, Richard Shaw wrote:
>
> On Wed, Oct 19, 2
On Wed, Oct 19, 2011 at 4:27 PM, Kay Sievers wrote:
> On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote:
>> On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote:
>>> On 19/10/11 21:48, Richard Shaw wrote:
On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering
wrote:
>
> You sh
On 19/10/11 22:27, Kay Sievers wrote:
> On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote:
>
>> Ok based on Tom's file I came up with the following. I know Lennart,
>> you don't like setting ACL's from Systemd, but unless someone want's
>> to help me write udev rules that will run before the start
On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote:
> On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote:
>> On 19/10/11 21:48, Richard Shaw wrote:
>>>
>>> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering
>>> wrote:
You should manage acess control of device nodes from udev rules. Tha
On Wed, Oct 19, 2011 at 22:26, Lennart Poettering wrote:
> On Wed, 19.10.11 13:43, Richard Shaw (hobbes1...@gmail.com) wrote:
>
>> It looks like I'll be taking over mythtv packaging for RPM Fusion and
>> I noticed it still only uses a sysv init script.
>>
>> In the sysv script it sets some ACL per
On Wed, Oct 19, 2011 at 3:58 PM, Tom Hughes wrote:
> On 19/10/11 21:48, Richard Shaw wrote:
>>
>> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering
>> wrote:
>>>
>>> You should manage acess control of device nodes from udev rules. That's
>>> the only reasonably safe way to handle these things.
On 19/10/11 21:48, Richard Shaw wrote:
> On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering
> wrote:
>> You should manage acess control of device nodes from udev rules. That's
>> the only reasonably safe way to handle these things. And this should not
>> be mentioned at all in systemd unit files
On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering
wrote:
> You should manage acess control of device nodes from udev rules. That's
> the only reasonably safe way to handle these things. And this should not
> be mentioned at all in systemd unit files.
Well, that's a bit beyond me at this point.
On Wed, 19.10.11 14:21, Richard Shaw (hobbes1...@gmail.com) wrote:
>
> Ok, I took Jóhann's idea and ran with it, trying to preserve as much
> of the functionality of the sysv init script as I could. It turn out
> the need to change device permissions is only for people who want to
> run mythback
On Wed, 19.10.11 18:58, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote:
> This is what I wrote a while back for mythtv in rpmfusion but never
> submitted since I could not find someone to test it.
>
> Note this got picked up by someone and adapted to atrpm version the
> other day.
>
> Cant
On Wed, 19.10.11 13:43, Richard Shaw (hobbes1...@gmail.com) wrote:
> It looks like I'll be taking over mythtv packaging for RPM Fusion and
> I noticed it still only uses a sysv init script.
>
> In the sysv script it sets some ACL permissions on video and audio
> devices necessary for the backend
Ok, I took Jóhann's idea and ran with it, trying to preserve as much
of the functionality of the sysv init script as I could. It turn out
the need to change device permissions is only for people who want to
run mythbackend as a real user, not root. I'm not sure if the
following is valid, but here
2011/10/19 "Jóhann B. Guðmundsson" :
> This is what I wrote a while back for mythtv in rpmfusion but never
> submitted since I could not find someone to test it.
>
> Note this got picked up by someone and adapted to atrpm version the
> other day.
>
> Cant recall if that indvidual pinged me on irc o
On 10/19/2011 06:43 PM, Richard Shaw wrote:
> It looks like I'll be taking over mythtv packaging for RPM Fusion and
> I noticed it still only uses a sysv init script.
>
> In the sysv script it sets some ACL permissions on video and audio
> devices necessary for the backend service, and then on shut
Am 19.10.2011 20:43, schrieb Richard Shaw:
> ExecStart=/bin/sh /usr/libexec/mythtv/startmythbackend.sh
> ExecStop=/bin/sh /usr/libexec/mythtv/stopmythbackend.sh
>
You don't need to specified /bin/sh if your script starts with
a proper #!/bin/sh.
Best Regards:
Jochen Schmitt
--
devel mailing lis
35 matches
Mail list logo
