Bug 221785

As I mentioned on the music list, modifying other packages in %post is hackery.
IMHO this should be filed against pam, which owns /etc/security/limits.conf.

Though this definately needs to be run by everyone on fedora-devel for a sanity
check. Unfortunatly the list seems to be a bit crap flooded right now. Maybe
fedora-maintainers would be better?

Oh, and the creation of a "jackuser" group opens up the question of, now that
core and extras are merged, how are new users/groups to be handled? We no longer
have to dance around Core.

Though this is all F7 stuff. We'll probably have to settle for some hackery if
we want this in FC6.

(In reply to comment #2)
> Though this is all F7 stuff. We'll probably have to settle for some hackery if
> we want this in FC6.

F7-only is fine by me. It's probably easier to buy approval for a clean solution
in a future distro, rather than introducing hack-ish changes to an existing one.

I have read the discussion on above link.
As I understand correctly the limits.conf should be prepared by Fedora Core 
team for using jackstart group. Is it right?

I've started the discussion on fedora-devel-list...

https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00307.html

(In reply to comment #2)
> Oh, and the creation of a "jackuser" group opens up the question of, now that
> core and extras are merged, how are new users/groups to be handled? We no longer
> have to dance around Core.

After discussion on  fedora-devel-list, and some inspection of how things
currently work, I think we should simple add the group in a
jack-audio-connection-kit package %post scriplet.  This is how many core
components, such as "rpm", add their groups.

In rpm package the group creation is placed in %pre scriptlet.
And another question is may be good solution is to use fedora-usermgmt wrappers 
instead of direct using of groupadd?

(In reply to comment #7)
> In rpm package the group creation is placed in %pre scriptlet.
> And another question is may be good solution is to use fedora-usermgmt wrappers 
> instead of direct using of groupadd?

Yes, I think that's how we're supposed to do it in fedora land.

What group number should I use for that? Do we need to register this number at 
the WiKi page?

Ugh, no. fedora-usermgmt is over-engineered unfocused kitchen sink crackrock.
And its usage is in no way required.

User ID assignment is what I hand in mind, yes. IIRC, previously there was
concern about clashing with core if we picked fixed UID/GIDs, but now that we're
merging that should no longer be a concern.

There's a page for registering IDs:

http://fedoraproject.org/wiki/PackageUserRegistry

I'd register an ID there, add 300 to it, and just forget fedora-usermgmt.

I'd put the new spec into CVS. Please, review it and put here changes for 
README.Fedora.
Thanks.

(In reply to comment #11)
> I'd put the new spec into CVS. 

Cool.  I noticed that in the spec file you require userdel/groupdel but they are
never used.  Should we use them in %postun?

No, do not ever automatically delete users and/or groups once created. It
creates potential security problems.

http://www.fedoraproject.org/wiki/PackageDynamicUserCreationConsideredBad

Even if you're not doing dynamic IDs the underlying problem still applies.

Note, man page for groupadd says you need a -g flag before the groupid. If it
works without it, its undocumented behaviour. :)

Also, since its actually a group, the macro names don't make sense. Should be
%gid and %groupname, though IMHO these macros are pointless anyway and you
shouldn't bother with them.

I miss -g due to copy command line for fedora-usermgmt's groupadd wrapper.
Also, I agree with more logical names for macros.

I'm going ahead and cleanup the spec with new build. Try 0.102.20-4.

Looks good... now, are we prepared to put change %post to read...

%post
/sbin/ldconfig
! grep jackuser /etc/security/limits.conf  > /dev/null 2>&1 && \
sed -i "s/# End of file/\* jackuser rtprio 20\n\* jackuser memlock 131072\n\n# E\
nd of file/g" /etc/security/limits.conf

Eugh. Try this instead:

grep -q jackuser /etc/security/limits.conf \
||cat >> /etc/security/limits.conf << EOF

## Automatically appended by jack-audio-connection-kit
* jackuser rtprio 20
* jackuser memlock 4194304
EOF

Much clearer. Doesn't depend on the "End of file" comment being there. Also it
doesn't keep the EOF comment at the end, but the hell with it, a hack is a hack.

Has there been any dialog with whoever maintains limits.conf? Its part of the
pam package.

Also note, once I started loading huge sample banks into fluidsynth, the 128mb
memlock no longer cuts it. I think we're going to have to just bite the bullet
and default it to something massively huge (like 4gb) so people don't have the
mysterious non-obvious problems a too small memlock limit seems to cause. The
user can reduce it if they so desire.

I fix the spec file accordingly to the last notes (related to the 
limits.conf).
Additionally I update jack to the 0.103.0.
I'll try to push the new build at the end of this day for devel. Please, test 
it. Can I push than to the F-7 branch? 

Fixed for FC6, F-7, Rawhide. Please, check it and reopen this report if needs.

jack-audio-connection-kit-0.103.0-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

jack-audio-connection-kit-0.103.0-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.