Bug 169247
Summary: | Review request: rt3 - Request tracker 3 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ralf Corsepius <rc040203> |
Component: | Package Review | Assignee: | Chris Grau <chris> |
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | chris, fedora-extras-list, kms, sheltren |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.bestpractical.com/rt | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-10-29 02:18:45 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 168070, 168213, 168227, 168265, 170998 | ||
Bug Blocks: | 163779 |
Description
Ralf Corsepius
2005-09-26 06:29:14 UTC
Updated packages: ftp://packman.iu-bremen.de/fedora/SRPMS/rt3.spec ftp://packman.iu-bremen.de/fedora/SRPMS/rt3-3.4.4-4.src.rpm Are all the deps in FE now ? If there are still a few packages waiting for approval, please make the associated bugs block this one. (In reply to comment #2) > Are all the deps in FE now ? No. But all deps are in the request queue. > If there are still a few packages waiting for approval, please make the > associated bugs block this one. I already did ;) Just check https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169247 Silly me, was fooled by RedHat's bugzilla theming :) (In reply to comment #2) > Are all the deps in FE now ? Now, they are ;) - Hint, hint! $ rpmlint rt3-3.4.4-4.fc4.src.rpm W: rt3 strange-permission rt3-filter-requires.sh 0755 W: rt3 strange-permission rt3-filter-provides.sh 0755 These are strange to me. I would guess those are the proper permissions for such files. I'm assuming this is ignorable. E: rt3 configure-without-libdir-spec This can be ignored. The configure script for rt3 doesn't take a libdir argument. $ rpmlint rt3-3.4.4-4.fc4.noarch.rpm | sort E: rt3 dir-or-file-in-usr-local /usr/local/etc/rt3 E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3 E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/html E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/lib E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/po Why are directories being %ghosted in /usr/local? I see these directories being configured in the Fedora layout, and I'm inferring from it that these are used for user-generated content. If that's the case, I don't really see a problem with it, but it is odd to see an package owning anything in /usr/local. E: rt3 non-readable /etc/rt3/RT_Config.pm 0640 E: rt3 non-readable /etc/rt3/RT_SiteConfig.pm 0640 E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data 0770 E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data/cache 0770 E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data/etc 0770 E: rt3 non-standard-dir-perm /var/lib/rt3/mason_data/obj 0770 E: rt3 non-standard-dir-perm /var/lib/rt3/session_data 0770 E: rt3 non-standard-gid /var/lib/rt3/mason_data apache E: rt3 non-standard-gid /var/lib/rt3/mason_data/cache apache E: rt3 non-standard-gid /var/lib/rt3/mason_data/etc apache E: rt3 non-standard-gid /var/lib/rt3/mason_data/obj apache E: rt3 non-standard-gid /var/lib/rt3/session_data apache E: rt3 non-standard-uid /var/lib/rt3/mason_data apache E: rt3 non-standard-uid /var/lib/rt3/mason_data/cache apache E: rt3 non-standard-uid /var/lib/rt3/mason_data/etc apache E: rt3 non-standard-uid /var/lib/rt3/mason_data/obj apache E: rt3 non-standard-uid /var/lib/rt3/session_data apache These are all ignorable. They're set that way on purpose for security reasons. W: rt3 dangerous-command-in-%postun userdel I'll leave this one alone. The package creates the user in %pre, it's only right that the user is removed when no longer needed, I suppose. W: rt3 non-conffile-in-etc /etc/rt3/acl.Informix W: rt3 non-conffile-in-etc /etc/rt3/acl.mysql W: rt3 non-conffile-in-etc /etc/rt3/acl.Oracle W: rt3 non-conffile-in-etc /etc/rt3/acl.Pg W: rt3 non-conffile-in-etc /etc/rt3/acl.Sybase W: rt3 non-conffile-in-etc /etc/rt3/initialdata W: rt3 non-conffile-in-etc /etc/rt3/schema.Informix W: rt3 non-conffile-in-etc /etc/rt3/schema.mysql W: rt3 non-conffile-in-etc /etc/rt3/schema.Oracle W: rt3 non-conffile-in-etc /etc/rt3/schema.Pg W: rt3 non-conffile-in-etc /etc/rt3/schema.SQLite W: rt3 non-conffile-in-etc /etc/rt3/schema.Sybase True, these aren't configuration files, but rather initialization files. Maybe a better place for them would be /usr/share/rt3? An explicit requires is needed for perl(HTML::Mason). I don't like that /usr/sbin/webmux.pl has mode +x, since it's meant to be sourced and doesn't actually do anything when run. I think it would be better somewhere like /usr/lib/rt3, but I don't know how much that change would affect the RT install. Would /var/lib/rt3 be better as /var/cache/rt3? I ran into SELinux issues when starting httpd. Maybe a README.SELinux mentioning that /var/lib/rt3 and its subdirectories need the proper SELinux settings. It took some tinkering to get running (installing the proper DBD and initializing the database). The existing README section on initializing the database isn't appropriate for an RPM-based install. For its target audience, I don't think it's very difficult. Maybe just add README.Fedora to point users to /etc/rt3. I didn't know what to do with RT once I got it running and didn't have much luck getting rt-setup-database to work, but I'm going to chalk that up to user error. I did get a login page with RT installed on my local httpd server, so I'm going to go ahead and say the package does work as intended. (In reply to comment #6) > $ rpmlint rt3-3.4.4-4.fc4.noarch.rpm | sort > E: rt3 dir-or-file-in-usr-local /usr/local/etc/rt3 > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3 > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/html > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/lib > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/po > > Why are directories being %ghosted in /usr/local? I see these directories being > configured in the Fedora layout, and I'm inferring from it that these are used > for user-generated content. If that's the case, I don't really see a problem > with it, but it is odd to see an package owning anything in /usr/local. Does rt3 create these if they're not present? I guess ghosting directories here is OK if the directories won't get removed if they're not empty, which I would think (but am not sure) would be rpm's behaviour here. > W: rt3 dangerous-command-in-%postun userdel > > I'll leave this one alone. The package creates the user in %pre, it's only > right that the user is removed when no longer needed, I suppose. See https://www.redhat.com/archives/fedora-extras-commits/2005-June/msg00271.html for why users and groups shouldn't be removed when a package is uninstalled. > I ran into SELinux issues when starting httpd. Maybe a README.SELinux > mentioning that /var/lib/rt3 and its subdirectories need the proper SELinux > settings. If you know what the contexts should be for this directory and its contents, you could raise the issue on fedora-selinux-list or in bugzilla for one of the policy packages and hopefully get the right contexts set by default in an updated version of the policy packages. That has to be better than manually setting contexts (which would need fixing again after a relabel). (In reply to comment #6) > [Many rpmlint complaints, probably ignorable] Yes, rpmlint is facing its limitations and deficits at many places with this rpm. > W: rt3 non-conffile-in-etc /etc/rt3/acl.Informix > W: rt3 non-conffile-in-etc /etc/rt3/acl.mysql > W: rt3 non-conffile-in-etc /etc/rt3/acl.Oracle > W: rt3 non-conffile-in-etc /etc/rt3/acl.Pg > W: rt3 non-conffile-in-etc /etc/rt3/acl.Sybase > W: rt3 non-conffile-in-etc /etc/rt3/initialdata > W: rt3 non-conffile-in-etc /etc/rt3/schema.Informix > W: rt3 non-conffile-in-etc /etc/rt3/schema.mysql > W: rt3 non-conffile-in-etc /etc/rt3/schema.Oracle > W: rt3 non-conffile-in-etc /etc/rt3/schema.Pg > W: rt3 non-conffile-in-etc /etc/rt3/schema.SQLite > W: rt3 non-conffile-in-etc /etc/rt3/schema.Sybase > > True, these aren't configuration files, but rather initialization files. > Maybe a better place for them would be /usr/share/rt3? May-be, may-be it's rpmlint enforcing non-existing standards. I am inclined to think the latter. All the FHS says is "The /etc hierarchy contains configuration files", it doesn't say "configuration files only" nor does it prohibit "initial data files". For now I don't want to move them to avoid further surgery on the package configuration nor do I see any need to do so. > An explicit requires is needed for perl(HTML::Mason). Right, this is missing. > I don't like that /usr/sbin/webmux.pl has mode +x, since it's meant to be > sourced and doesn't actually do anything when run. I think it would be better > somewhere like /usr/lib/rt3, but I don't know how much that change would affect > the RT install. > > Would /var/lib/rt3 be better as /var/cache/rt3? Hmm? Are you looking at an older rpm? My latest version (3.4.4-4) uses /var/lib/rt3. > I ran into SELinux issues when starting httpd. Maybe a README.SELinux > mentioning that /var/lib/rt3 and its subdirectories need the proper SELinux > settings. > > It took some tinkering to get running (installing the proper DBD and > initializing the database). The existing README section on initializing the > database isn't appropriate for an RPM-based install. For its target audience, I > don't think it's very difficult. Maybe just add README.Fedora to point users to > /etc/rt3. > > I didn't know what to do with RT once I got it running and didn't have much luck > getting rt-setup-database to work, but I'm going to chalk that up to user error. > I did get a login page with RT installed on my local httpd server, so I'm going > to go ahead and say the package does work as intended. I need to try setting it up once again. It's been a while since I did (mysql based config) and have it running since ;) (In reply to comment #7) > (In reply to comment #6) > > $ rpmlint rt3-3.4.4-4.fc4.noarch.rpm | sort > > E: rt3 dir-or-file-in-usr-local /usr/local/etc/rt3 > > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3 > > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/html > > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/lib > > E: rt3 dir-or-file-in-usr-local /usr/local/lib/rt3/po > > > > Why are directories being %ghosted in /usr/local? I see these directories being > > configured in the Fedora layout, and I'm inferring from it that these are used > > for user-generated content. Yes, these are for user provided stuff. These dirs are being added to PATH variables all over the place (grep -R LOCAL_ * inside of the source tree for details) > > If that's the case, I don't really see a problem > > with it, but it is odd to see an package owning anything in /usr/local. Well, actually many package use the standardized dirs below /usr/local. They only don't have to make this explicit, because the "filesystem" rpm already owns them. > Does rt3 create these if they're not present? AFAICT, no. It just uses them, whether or not these dirs are present. > I guess ghosting directories here > is OK if the directories won't get removed if they're not empty, which I would > think (but am not sure) would be rpm's behaviour here. Just try and you'll see what happens (FC4): # mkdir /usr/local/etc/rt3 # touch /usr/local/etc/rt3/foo # rpm -e rt3 # ls /usr/local/etc/rt3/ foo => The directory will be removed from the rpmdb. IIRC, older rpms issued a "directory not empty" or similar warning on similar sitations. > > W: rt3 dangerous-command-in-%postun userdel > > > > I'll leave this one alone. The package creates the user in %pre, it's only > > right that the user is removed when no longer needed, I suppose. > > See > https://www.redhat.com/archives/fedora-extras-commits/2005-June/msg00271.html > for why users and groups shouldn't be removed when a package is uninstalled. Then you probably know my attitude on this topic. The rt3 user is a local system account (!) and is not meant to be used across networks. Also, the rt3 package has all files being own by the rt3 user under its control. > > I ran into SELinux issues when starting httpd. And so do I. I have _never_ been able to use httpd without switching SELinux off for it. With having switched SELinux off for httpd I am able to run rt3 without any problems. >> Maybe a README.SELinux > > mentioning that /var/lib/rt3 and its subdirectories need the proper SELinux > > settings. > If you know what the contexts should be for this directory and its contents, you > could raise the issue on fedora-selinux-list or in bugzilla for one of the > policy packages and hopefully get the right contexts set by default in an > updated version of the policy packages. That has to be better than manually > setting contexts (which would need fixing again after a relabel). ... some SELinux geek will have to implement this ;) Updated package to be released soon ... (In reply to comment #8) > > > W: rt3 dangerous-command-in-%postun userdel > > > > > > I'll leave this one alone. The package creates the user in %pre, it's only > > > right that the user is removed when no longer needed, I suppose. > > > > See > > https://www.redhat.com/archives/fedora-extras-commits/2005-June/msg00271.html > > for why users and groups shouldn't be removed when a package is uninstalled. > Then you probably know my attitude on this topic. > > The rt3 user is a local system account (!) and is not meant to be used across > networks. Also, the rt3 package has all files being own by the rt3 user under > its control. The issue is nothing to do with networks; leaving the user there ensures that any files left that are owned by the "rt3" user after deletion of the rt3 package are still owned by the "rt3" user if the package is subsequently reinstalled. If the account is deleted on uninstall, the reinstallation may result in a new rt3 user being created with a different UID to the original one > > > I ran into SELinux issues when starting httpd. > And so do I. I have _never_ been able to use httpd without switching SELinux off > for it. With having switched SELinux off for httpd I am able to run rt3 without > any problems. I'm using httpd with SELinux without problems, albeit only serving static pages and a few cgi scripts. I know though that more complex packages such as squirrelmail can work with SELinux enabled too. > > If you know what the contexts should be for this directory and its contents, you > > could raise the issue on fedora-selinux-list or in bugzilla for one of the > > policy packages and hopefully get the right contexts set by default in an > > updated version of the policy packages. That has to be better than manually > > setting contexts (which would need fixing again after a relabel). > ... some SELinux geek will have to implement this ;) What does the package do with the files/directories in /var/lib/rt3? Read? Write? Execute? (In reply to comment #9) > (In reply to comment #8) > > > > W: rt3 dangerous-command-in-%postun userdel > > > > > > > > I'll leave this one alone. The package creates the user in %pre, it's only > > > > right that the user is removed when no longer needed, I suppose. > > > > > > See > > > https://www.redhat.com/archives/fedora-extras-commits/2005-June/msg00271.html > > > for why users and groups shouldn't be removed when a package is uninstalled. > > Then you probably know my attitude on this topic. > > > > The rt3 user is a local system account (!) and is not meant to be used across > > networks. Also, the rt3 package has all files being own by the rt3 user under > > its control. > > The issue is nothing to do with networks; leaving the user there ensures that > any files left that are owned by the "rt3" user after deletion of the rt3 > package are still owned by the "rt3" user if the package is subsequently > reinstalled. If the account is deleted on uninstall, the reinstallation may > result in a new rt3 user being created with a different UID to the original > one There is no such issue, because the rt3 package does not leave any file being owned by rt3 left around. > I'm using httpd with SELinux without problems, albeit only serving static > pages > and a few cgi scripts. I know though that more complex packages such as > squirrelmail can work with SELinux enabled too. Does SELinux work for anything but trivial cases? IMO, no - It still leave much to be desired and so far has failed to prove sustainability. > What does the package do with the files/directories in /var/lib/rt3? Read? > Write? Execute? I am not sure about all scenarios, but in mine, /var/lib/rt3 (which IMO should actually be /var/cache/rt3, but I had changed it to /var/lib to work around SELinux deficits) is essentally only used by Mason. Both for writing and reading (It's a cache). I am not sure about executing. (In reply to comment #10) > > The issue is nothing to do with networks; leaving the user there ensures that > > any files left that are owned by the "rt3" user after deletion of the rt3 > > package are still owned by the "rt3" user if the package is subsequently > > reinstalled. If the account is deleted on uninstall, the reinstallation may > > result in a new rt3 user being created with a different UID to the original > > one > There is no such issue, because the rt3 package does not leave any file being > owned by rt3 left around. No log files, cache files, etc.? That's OK then. > > I'm using httpd with SELinux without problems, albeit only serving static > > pages > > and a few cgi scripts. I know though that more complex packages such as > > squirrelmail can work with SELinux enabled too. > Does SELinux work for anything but trivial cases? IMO, no - It still leave much > to be desired and so far has failed to prove sustainability. > > > What does the package do with the files/directories in /var/lib/rt3? Read? > > Write? Execute? > I am not sure about all scenarios, but in mine, /var/lib/rt3 (which IMO should > actually be /var/cache/rt3, but I had changed it to /var/lib to work around > SELinux deficits) is essentally only used by Mason. > Both for writing and reading (It's a cache). I am not sure about executing. Try: # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3 and then try running in SELinux permissive mode to see what SELinux issues crop up (check the output of "audit2allow -i /var/log/audit/audit.log") after running rt3 for a short while. Updated packages: ftp://packman.iu-bremen.de/fedora/SRPMS/rt3.spec ftp://packman.iu-bremen.de/fedora/SRPMS/rt3-3.4.4-5.src.rpm (In reply to comment #11) > Try: > # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3 For what it's worth at this point, that is how I got RT3 to work with SELinux. If I find some time, I'll see about offering up a patch to the SELinux people. (In reply to comment #8) > > Would /var/lib/rt3 be better as /var/cache/rt3? > Hmm? Are you looking at an older rpm? My latest version (3.4.4-4) uses > /var/lib/rt3. I was looking at the most recent package you had posted. What I meant here is that /var/cache/rt3 is a better choice than /var/lib/rt3; much the same as we are using /var/cache/mason in the perl-HTML-Mason package. I'll give -5 a look shortly. (In reply to comment #13) > (In reply to comment #11) > > Try: > > # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3 > > For what it's worth at this point, that is how I got RT3 to work with SELinux. Is that *all* that was needed? > If I find some time, I'll see about offering up a patch to the SELinux people. The following lines added to file_contexts/program/apache.fc in the policy sources should take care of both HTML::Mason and rt3 /var/cache/mason(/.*)? system_u:object_r:httpd_cache_t /var/cache/rt3(/.*)? system_u:object_r:httpd_cache_t I think we're all agreed that /var/cache/rt3 is a better option than /var/lib/rt3, aren't we? (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > > Try: > > > # chcon -R system_u:object_r:httpd_cache_t /var/lib/rt3 > > > > For what it's worth at this point, that is how I got RT3 to work with SELinux. > > Is that *all* that was needed? Yes. > I think we're all agreed that /var/cache/rt3 is a better option than > /var/lib/rt3, aren't we? I am. (In reply to comment #14) > The following lines added to file_contexts/program/apache.fc in the policy > sources should take care of both HTML::Mason and rt3 > > /var/cache/mason(/.*)? system_u:object_r:httpd_cache_t > /var/cache/rt3(/.*)? system_u:object_r:httpd_cache_t How can this be achieved inside of the rt3-rpm? > I think we're all agreed that /var/cache/rt3 is a better option than > /var/lib/rt3, aren't we? Yes, but unless somebody tells me how to achieve this inside of an rpm, without having to modify on of the centralized SELinux packages I don't seem any perspective to do so. AFAIK, the current SELinux implementation doesn't allow this, except of (may-be) running chcon inside of a %postin script directly. You need to raise a bug against selinux-policy-targeted with the changes you need to get rt3 to work. I don't think there is a mechanism for individual packages to update the selinux policy when they are installed. or better to send an email to fedora-selinux-list. dan used to reply to such request in a few days! (In reply to comment #16) > (In reply to comment #14) > > > The following lines added to file_contexts/program/apache.fc in the policy > > sources should take care of both HTML::Mason and rt3 > > > > /var/cache/mason(/.*)? system_u:object_r:httpd_cache_t > > /var/cache/rt3(/.*)? system_u:object_r:httpd_cache_t > How can this be achieved inside of the rt3-rpm? They could be added to a file in /etc/selinux/targeted/contexts/files. However, that would be the wrong approach. The right approach is to get the policy changed upstream, by raising a bug on selinux-policy-targeted or mentioning the issue on fedora-selinux-list, as mentioned in the previous two comments. > > I think we're all agreed that /var/cache/rt3 is a better option than > > /var/lib/rt3, aren't we? > Yes, but unless somebody tells me how to achieve this inside of an rpm, without > having to modify on of the centralized SELinux packages I don't seem any > perspective to do so. > > AFAIK, the current SELinux implementation doesn't allow this, except of (may-be) > running chcon inside of a %postin script directly. I'm happy to handle the SELinux bug report and get it fixed, but I need to make sure that I'm getting the right directories fixed. There's no point getting the context of /var/cache/{mason,rt3} fixed if /var/lib/{mason,rt3} are being used by the {mason,rt3} packages. So, are /var/cache/{mason,rt3} the directories that are going to be used? BTW, I believe FC5 will have a more modular approach where tweaks to policy like this *can* be handled within the package. (In reply to comment #19) > (In reply to comment #16) > > (In reply to comment #14) > > > > > The following lines added to file_contexts/program/apache.fc in the policy > > > sources should take care of both HTML::Mason and rt3 > > > > > > /var/cache/mason(/.*)? system_u:object_r:httpd_cache_t > > > /var/cache/rt3(/.*)? system_u:object_r:httpd_cache_t > > How can this be achieved inside of the rt3-rpm? > > They could be added to a file in /etc/selinux/targeted/contexts/files. > However, that would be the wrong approach. IMO, this approach is wrong without any doubt. > The right approach is to get the policy > changed upstream, by raising a bug on selinux-policy-targeted or mentioning the > issue on fedora-selinux-list, as mentioned in the previous two comments. I can't avoid to disagree, again. > > > I think we're all agreed that /var/cache/rt3 is a better option than > > > /var/lib/rt3, aren't we? > > Yes, but unless somebody tells me how to achieve this inside of an rpm, without > > having to modify on of the centralized SELinux packages I don't seem any > > perspective to do so. > > > > AFAIK, the current SELinux implementation doesn't allow this, except of (may-be) > > running chcon inside of a %postin script directly. > > I'm happy to handle the SELinux bug report and get it fixed, but I need > to make sure that I'm getting the right directories fixed. There's no > point getting the > context of /var/cache/{mason,rt3} fixed if /var/lib/{mason,rt3} are being used > by the {mason,rt3} packages. So, are /var/cache/{mason,rt3} the > directories that are going to be used? Yes, we want /var/cache/*, but are deadlocked and we can't switch to it, before _SELinux_ has been changed. > BTW, I believe FC5 will have a more modular approach where tweaks to > policy like this *can* be handled within the package. Well, face it: SELinux suffers from the same design flaws as any other centralized registry suffer from. IMO, this must be fixed ASAP or SELinux should be discontinued. (In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #16) > > > (In reply to comment #14) > > > > I think we're all agreed that /var/cache/rt3 is a better option than > > > > /var/lib/rt3, aren't we? > > > Yes, but unless somebody tells me how to achieve this inside of an rpm, without > > > having to modify on of the centralized SELinux packages I don't seem any > > > perspective to do so. > > > > > > AFAIK, the current SELinux implementation doesn't allow this, except of (may-be) > > > running chcon inside of a %postin script directly. > > > > I'm happy to handle the SELinux bug report and get it fixed, but I need > > to make sure that I'm getting the right directories fixed. There's no > > point getting the > > context of /var/cache/{mason,rt3} fixed if /var/lib/{mason,rt3} are being used > > by the {mason,rt3} packages. So, are /var/cache/{mason,rt3} the > > directories that are going to be used? > Yes, we want /var/cache/*, but are deadlocked and we can't switch to it, before > _SELinux_ has been changed. I don't get this. In what way is using /var/lib/rt3 any less broken than using /var/cache/rt3? With SELinux enabled, apache can write to neither. In the meantime I shall raise the bug to get SELinux to support /var/cache/{mason,rt3} Another, hopefully the final version at: ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3.spec ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3-3.4.4-7.src.rpm Most important change: This version uses /var/cache/rt3 The package still creates and owns /var/lib/rt3, and I notice that /var/cache/rt3 is not owned. I assume this is a typo in the %files section: %dir %{_localstatedir}/lib/rt3 %attr(0770,apache,apache) %{RT3_CACHEDIR}/mason_data %attr(0770,apache,apache) %{RT3_CACHEDIR}/session_data Everything else looks good to me. I'll give it about 24 hours before I set this package to FE-ACCEPT, just in case anyone else has any input. (In reply to comment #23) > The package still creates and owns /var/lib/rt3, Correct, because rt3 still uses it on occasion (cf. VarPath in RT.pm) .. but there is another bug hiding this issue. > and I notice that > /var/cache/rt3 is not owned. > I assume this is a typo in the %files section: ... and this is a bug ... another iteration ... ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3.spec ftp://packman.rsync.zmi.at/fedora/SRPMS/rt3-3.4.4-8.src.rpm W: rt3 log-files-without-logrotate /var/log/rt3 I don't recall seeing this warning from rpmlint before, but it's there now. Maybe in a future release you can add a logrotate script. Requires(post): /usr/bin/chcon You can remove that, since you don't have a %post scriptlet. APPROVED (In reply to comment #25) > W: rt3 log-files-without-logrotate /var/log/rt3 > > I don't recall seeing this warning from rpmlint before, but it's there now. > Maybe in a future release you can add a logrotate script. Hmm, does rt3 generate logs for you? > Requires(post): /usr/bin/chcon > > You can remove that, since you don't have a %post scriptlet. Done. Remnant from experiments with running chcon in %post scripts ;) > APPROVED Thanks Package Change Request ====================== Package Name: rt3 New Branches: EL-5 Updated Fedora CC: corsepiu xavierb mmahut Updated EPEL Owners: xavierb mmahut Updated EPEL CC: xavierb mmahut perl-sig cvs done. Package Change Request ====================== Package Name: rt3 InitialCC: perl-sig Done. |