At least 2 other packages (squid, mod_auth_ntlm_winbind) need to modity/use data contained within /var/cache/samba/winbind_priveleged. For example, squid currently contains the ugly scriptlet (imo, hack): %triggerin -- samba-common chgrp squid /var/cache/samba/winbindd_privileged > /dev/null 2>& 1 || true not nice. I propose that the samba packaging help avoid this by creating a samba user/group, and making the aforementioned folder owned/writable by group samba. This way, other winbind-using pkgs could simply add themselves to the samba group on install without having to resort to ugly scriptlet hacks to achieve the same thing.
Upon further review, I don't think this dir needs to be writable, only readable by other apps.
Potentially ntlm_auth/winbindd can be used by cyrus-sasl and dovecot, IMHO in the nearest future. I.e., it is actually more than 2 apps only. The group can be named "winbind" ...
The new samba-2.0.23a is released, which fixes some domain-related bugs etc. It seems that new samba update can appear soon. If it is true, maybe implement this group feature now (i.e., before FC6)?
Created attachment 133561 [details] Expected changes for the spec file ;) I prefer the gorup should be named "winbind". An appropriate patch added for squid too. I hope there is enough time to implement this feature (with cooperating samba and squid maintainers) before FC6 time...
Jay, can you please take a look at (or at least comment on) this before FC6 is released?
This new group is going to be implemented by creating the group in a separate subpackage (samba-group? I don't think we've decided on the name yet). That way packages that need that group to exist will only require the subpackage and not all of Samba. Unfortunately, the package list for FC6 was already frozen, and the change requires updates to packages I don't control, so it's going to be in FC7.
Dude, this *has* to be done in time for fc6. This is serious breakage, and package standards violation going on here. Further, other packages (see squid) and Extras Reviews (see mod_auth_ntlm) are waiting on *this* to be resolved in time for FC6. If fixing it for FC6 means putting the dep on the main samba pkg (which is where it should be anyway, that's where winbind lives), so be it.
It is *not* appropriate to have a server require another server just because some (small?) subset of users may want to configure the first server to use a service provided by the second server. They really need to be separately installable and removable.
Fair enough, hadn't thought about considering samba to be optional. How about this, which should make everyone happy: 1. include scriptlet in %post samba-common (or %pre, doesn't matter much) to create group (and user, if also desired) winbind (see comment #4) 2. Any other pkg that wants to make use of winbind, add something like: (code shamelessly borrowed from squid): %triggerin samba-common /usr/sbin/usermod -a -G winbind %{name} >/dev/null 2>&1 ||: This way, no new packages are required, and *this* bug gets fixed to boot.
Corrolary to 2. Those packages that want to use winbind, must also create the user %{name} referenced in the %triggerin scriptlet (of course).
for comment #6 : > This new group is going to be implemented by creating the group in a separate > subpackage and for comment #8 : > It is *not* appropriate to have a server require another server Jay, What can you say about trigger scripts in rpm? They just allow to avoid such dependencies. There is a couple of packages in Core which already uses such a technics (at least 71 for the moment). I.e, no any extra packages needed. Just add a group and let it own the winbind directory. All seems to be compatible and nothing is spoiled. for comment #8 : > because some (small?) subset of users IMHO Fedora is a little bit wider than RHEL. I.e, it can be used in some heterogeneous system, when both Linux and Windows boxes are used together. When such a system uses domain controllers for auth, i.e. AD, people want to use it for proxy/web/mail auth too. But currently it is possible just for squid. As a result, people switches from Apache to IIS when they need AD auth. Therefore I think it is not a "small subset of users". It is a policy to allow people to use open-source software (squid, apache, and dovecot/postfix/sendmail later) in its strong AD-based environment, and to not switch from Linux to Windows just because of such an auth is needed.
for comment #10 : > Those packages that want to use winbind, must also create the user %{name} All such packages already have a special user suitable for this (squid uses "squid", https uses "apache", dovecot uses "dovecot", postfix uses "postfix" etc. :)) Rex, Maybe it would be useful to discuss this issue at appropriate mail lists? (fedora-devel?) Also it would be useful if squid maintainers atleast remove its "chgrp ..." code for FC6 (and add "usermod" when/if a group will appear in the future).
Squid maintainer already had fixed his part of the issue, according to bug #198253 . Please, don't delay the Samba's part of work, the changes (for Samba itself exactly) are trivial enough.
By the way, there is a duscussion on samba-technical list about a best choice for the winbindd dir access, see http://lists.samba.org/archive/samba-technical/2006-September/049311.html The "best choice" is considered as what we propose.
Jay, any movement here? The mod_auth_ntlm_winbind package review is (still) blocking on this. Besides, this is a MUSTFIX item that will need to be addressed before samba (and squid for that matter) can pass any sort of package review.
Ping, ping, the witch is dead... only 2 more weeks till Christmas. We're now going on (almost) 4 *months* of silence, Jay.
It is a pity this missed FC6. I hope this gets picked up/fixed up in the transition to FC7 and the opening up of core...
Now, ping Simo... :)
apps dependent on this (squid, in particular) will not pass merge review, please address this asap. May want to start looking for help/comaintainers, since delay in implementing suggestions/patches imply that current/previous maintainers haven't had enough time to give samba pkg the love/attention it deserves. Hint: I'm interested in helping out. (:
Can't we just ask to have a wbpriv (I prefer this name as it makes clear it is privileged) group created by default at system install independent of squid, samba or whatever package may need it? Are there any counter arguments to this? Simo.
> wbpriv Hmmm... "wbPRIV" takes a sense only if "wbPUBL" is planned. Is it true?.. ;) Are another similar groups (f.e. "apache", "mail", "postfix", "news" etc.) private or public? IMHO they are private, and there are no needs to create some additional "public" group for those packages. Therefore the groups have been named just by the correspond package's name... Moreover, "wb" in "wbpriv" is not long enough to point that it is "winbind"-related. :) I still prefer "winbind", basing on apache/news/mail/dovecot/fuse/avahi etc.etc.etc... precedents. > group created by default at system install independent of squid, > samba or whatever package may need it? What about system upgrades? In such cases /etc/group is not replaced... Or you mean "assign the group some fixed number"? (i.e. when create the group in %pre section, add "-g NUMBER" to the groupadd command)? If so, looks fine. Anyway, as well as for dovecot/apache etc., the %pre section must try to add user and/or group, with "2>/dev/null" for case when it is already exists. As long as initial /etc/group (from "setup" package) has no any such group preinstalled, our way is to not preinstall it too.
> Are there any counter arguments to this? We'd need implementation details to make a fair asessment. When/how exactly would this account be created? I take it, then, that you have reservations about the implementation/suggestion put forth by Dmitry and myself. If so, I'd be interested in hearing them.
I will shortly push a package that fixes this. The group name is wbpriv with fixed gid 88. Comment about the name is not pertinent as this is a group that is specific to privileged operations (not private) and wb is a wellknown short for winbind. The group will be created by the package samba-common where winbindd is packaged. The directory is going to be moved to /var/lib/samba/winbindd_privileged to adhere to FHS standards (by the std. you can delete /var/cache/samba/ contents, this would be a disaster). More on this later.
Simo, is it necessary to use fixed gid/uid?
for comment #24 It seems that another programs (apache, postfix etc.) prefer fixed numbers. Just considering this as a precedent, anyway...
Imo no, but I asked and I was told that policy is we give it a fixed number. We can easily change this later if the policy changes and we can liberate the gid, so please do not rely on the gid number in any code but only on the group name. Simo.
Latest packages use the metioned in comment 23
We fixed this in F7, closing