Packages changing SELinux configurations
by Jose Pedro Oliveira
Hi,
I would like to ask a couple of questions regarding
SELinux configurations:
1) is it valid to change SELinux booleans from within a
specfile (via scripts/triggers) ?
2) and adding local rules and make selinux reload
them (also via scripts/triggers)?
In my particular case - the package syslog-ng [1] - needs
to activate the "use_syslogng" SELinux boolean that
exists only after selinux-policy-targeted >= 1.17.30-2.96
(to be correct the boolean exists after release 2.90 but
the rules are more useful/correct after release 2.96 [2]).
I have done the following changes to the base specfile
but I am wondering if they are valid? I remember
reading something a while back that packages *should not*
change SELinux configurations.
-----------------------------------------------------------
...
# SELinux (Fedora Core 3)
Requires(preun): libselinux
Requires(post): libselinux
Requires: selinux-policy-targeted >= 1.17.30-2.96
...
%post
if [ $1 = 1 ]; then
setsebool -P use_syslogng 1
...
fi
%preun
if [ $1 = 0 ]; then
...
setsebool -P use_syslogng 0
fi
...
-----------------------------------------------------------
Feedback would be appreciated.
Thanks in advance,
jpo
References:
[1] Bug 1332 - syslog-ng is a sysklogd replacement
https://bugzilla.fedora.us/show_bug.cgi?id=1332
[2] Fedora Core 3, SELinux, and syslog-ng
See comment #33 of the above ticket
--
José Pedro Oliveira
* mailto: jpo(a)di.uminho.pt * http://gsd.di.uminho.pt/~jpo *
* gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *
19 years, 1 month
Can you review my specfile: rsnapshot.spec
by Gavin Henry
Dear all,
Not sure if I should e-mail the Extras list or this, so here goes:
Anything stupid that I have missed?
I have imported the srpm to Extras devel.
----------
Name: rsnapshot
Summary: Local and remote filesystem snapshot utility
Version: 1.2.1
Release: 1
License: GPL
Group: Applications/System
Url: http://www.rsnapshot.org
Source0: http://www.rsnapshot.org/downloads/rsnapshot-1.2.1.tar.gz
Patch0: rsnapshot.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u}
-n)
Requires: perl, rsync, ssh
AutoReqProv: no
%description
This is a remote backup program that uses rsync
to take backup snapshots of filesystems.
It uses hard links to save space on disk.
%prep
rm -rf %{buildroot}
%setup
%patch
%build
%configure
%install
install -d %{buildroot}/%{_bindir}
install -m 755 rsnapshot %{buildroot}/%{_bindir}/rsnapshot
install -d %{buildroot}/%{_mandir}/man1
install -m 644 rsnapshot.1 %{buildroot}/%{_mandir}/man1/
install -d %{buildroot}/%{_sysconfdir}
install -m 644 rsnapshot.conf.default
%{buildroot}/%{_sysconfdir}/rsnapshot.conf.default
install -m 600 rsnapshot.conf.default
%{buildroot}/%{_sysconfdir}/rsnapshot.conf
%post
#
# upgrade rsnapshot config file
#
RSNAPSHOT_CONFIG_VERSION=`%{_bindir}/rsnapshot check-config-version`
if test $? != 0; then
echo "Error upgrading %{_sysconfdir}/rsnapshot.conf"
fi
if test "$RSNAPSHOT_CONFIG_VERSION" = "1.2"; then
# already latest version
exit 0
fi
if test "$RSNAPSHOT_CONFIG_VERSION" = "unknown"; then
%{_bindir}/rsnapshot upgrade-config-file
RETVAL=$?
exit $RETVAL
fi
echo "Error upgrading %{_sysconfdir}/rsnapshot.conf. Config format unknown!"
exit 1
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root)
%verify(user group mode md5 size mtime) %doc AUTHORS COPYING ChangeLog
README INSTALL TODO
%verify(user group mode md5 size mtime) %config
%{_sysconfdir}/rsnapshot.conf.default
%verify(user group mode) %config(noreplace) %{_sysconfdir}/rsnapshot.conf
%verify(user group mode md5 size mtime) %{_bindir}/rsnapshot
%verify(user group mode md5 size mtime) %{_mandir}/man1/rsnapshot.1*
%changelog
* Tue Apr 12 2005 Gavin Henry <ghenry(a)suretecsystems.com>
- Cleaned up a lot and imported to Fedora Extras
* Sun Jan 29 2005 Nathan Rosenquist <nathan(a)rsnapshot.org>
- Added upgrade script
* Sat Jan 22 2005 Nathan Rosenquist <nathan(a)rsnapshot.org>
- Added --with-du option
* Thu Jan 15 2004 Nathan Rosenquist <nathan(a)rsnapshot.org>
- Added "AutoReqProv: no" for SuSE compatibility
* Fri Dec 26 2003 Nathan Rosenquist <nathan(a)rsnapshot.org>
- Added util-linux dependency, and --with-logger= option
* Fri Dec 19 2003 Nathan Rosenquist <nathan(a)rsnapshot.org>
- now fully support autoconf
* Tue Dec 16 2003 Nathan Rosenquist <nathan(a)rsnapshot.org>
- changed rsnapshot.conf to rsnapshot.conf.default from the source tree
* Wed Nov 05 2003 Nathan Rosenquist <nathan(a)rsnapshot.org>
- Removed fileutils dependency, added verification info
* Tue Nov 04 2003 Nathan Rosenquist <nathan(a)rsnapshot.org>
- fixed anonymous rsync error
* Thu Oct 30 2003 Nathan Rosenquist <nathan(a)rsnapshot.org>
- update to 1.0.3
* Tue Oct 28 2003 Carl Wilhelm Soderstrom <chrome(a)real-time.com>
- created spec file
Thanks all.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
19 years, 1 month
Re: dist tag usage
by Rex Dieter
Ignacio Vazquez-Abrams wrote on fedora-extras-list:
> It's part of the disttag set.
> http://www.fedoraproject.org/wiki/DistTag
Here's a suggestion for that page:
Replace %{?dist:%{dist}} references with %{?dist}
(It's shorter and produces the same result).
-- Rex
19 years, 2 months
perl module MODULE_COMPAT
by Warren Togami
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
As long as we're going through all FC4 perl modules, we might as well
add this to all packages too. Just confirming, is this wanted in *ALL*
packages that need perl, both regular arch and noarch?
Warren Togami
wtogami(a)redhat.com
19 years, 2 months
dist tag revisited
by Tom Callaway
I had an insightful discussion with Sopwith this afternoon, and we
discussed the idea of dist tags, and some important discussion arose:
Elliot pointed out that for any given .src.rpm, the name-version-release
needs to stay fixed for all builds of that .src.rpm. Otherwise it
becomes impossible to track packages back to their source, keep an audit
trail, etc.
The problem with using the macros is that if a maintainer does 'make
build' on an fc3 box, then they get the dist tag value from that machine
in the n-v-r. When they go to check this into CVS (say, into the fc4
branch), its wrong. We don't want someone doing 'make tag' on the FC-4
branch and having n-v-r = foo-1.2-3.fc3.
But at the same time, we also want to avoid forcing the packagers to
have to put the dist value into the spec manually. This defeats the
entire reason for dist tags, which is to have a single spec that can be
used for multiple distributions.
We discussed a lot of options, but Elliot came up with a good idea,
which is best explained by giving an example of a new package commit:
- I'm a maintainer, of package logjam.
- I make a single spec for all possible fc builds using the documented
"approved" dist macros
- I set Release: 1 (note, no %{dist})
- I make my src.rpm.
- I then run ./cvs-import.sh --use-dist --branch=fc4
logjam-1.0.0-1.src.rpm
- The cvs-import script does the following:
- Checks my spec to make sure that n-v-r doesn't have %{dist} in it
already
- Notes the value of the branch that I'm checking this package into
- Uses that value and adds the following lines to the top of my spec
%define fedora 4
%define dist .fc4
- Appends %{?dist} to the end of Release (so it becomes
Release: 1%{?dist} )
- Commits the spec with the added defines into the branch.
Now, with this mechanism, if I want to do multiple branches for a single
spec, its easy, cvs-import.sh does the work for me. We keep a single
n-v-r per branch, and there is no naming conflicts between branches.
The branch-copy operations would just change the values of the macros,
or add the macros near the top if they're not already in the .spec file.
We'd want to add a check in the buildsystem to make sure that people
haven't polluted the %{dist} defines, but that shouldn't be terribly
difficult.
Now, for people wanting to take their original spec and build it
somewhere else, say for RHEL, we could use a set of rpm macros. Elliot
and I worked on a simple shell script that parses /etc/redhat-release
and returns (depending on the flag chosen):
The version of RHEL for %{_el} (if on RHEL)
The version of Fedora for %{_fedora} (if on Fedora)
The version of RHL for %{_rhel} (if on RHL)
The number of the distro for %{_distnum}
The type of the distro for %{_disttype}
The dist tag value for %{_dist}
The macros then become as simple as:
%_dist %{expand:%%(/usr/lib/rpm/redhat/dist.sh --dist)}
%_distnum %{expand:%%(/usr/lib/rpm/redhat/dist.sh --distnum)}
%_disttype %{expand:%%(/usr/lib/rpm/redhat/dist.sh --disttype)}
%_rhel %{expand:%%(/usr/lib/rpm/redhat/dist.sh --el)}
%_fedora %{expand:%%(/usr/lib/rpm/redhat/dist.sh --fc)}
%_rhl %{expand:%%(/usr/lib/rpm/redhat/dist.sh --rhl)}
The script is already checked into CVS for redhat-rpm-config. If you
wanted to build off that spec for RHEL, you'd just need to add these 7
lines to your local .rpmmacros file.
This provides a standardized, easy way to do single-spec, multiple
distribution packaging. But of course, there are bound to be
complications.
Please ponder this implementation, and offer feedback.
Thanks,
~spot
--
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
19 years, 2 months
