On 4/2/12 1:26 PM, Shawn Wells wrote:
0001-Added-make-rpm.patch
From f9199eedfa6b54b8f3542d03740ada8c57e98e69 Mon Sep 17 00:00:00 2001 From: Shawn Wellsshawn@redhat.com Date: Mon, 2 Apr 2012 13:19:24 -0400 Subject: [PATCH] Added 'make rpm' First crack at creating a 'make rpm' command.
(1) 'make rpm' now exists, you can use that or 'make all' for desired effect. RPMs will be placed into ${OUT}/RPMS until they get a bit more vetted
(2) I put a few notes inside of the 'make rpm' section, please follow them! There is an expectation that rpm-build is installed as is your rpmbuild directory structure.
(3) I have the RPM install to/usr/local/scap-security-guide/. We can easily change this, thoughts and patches welcome.
(4) For this initial build I'm on RHEL6. It*should* work for Fedora but testing is needed.
rhel6/src/.gitignore | 1 + rhel6/src/Makefile | 35 ++++++++++- .../input/rpmbuild/scap-security-guide-alpha.spec | 64 ++++++++++++++++++++ rhel6/src/output/.gitignore | 5 ++ 4 files changed, 102 insertions(+), 3 deletions(-) create mode 100644 rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec
diff --git a/rhel6/src/.gitignore b/rhel6/src/.gitignore index e69de29..4852292 100644 --- a/rhel6/src/.gitignore +++ b/rhel6/src/.gitignore @@ -0,0 +1 @@ +scap-security-guide-*/ diff --git a/rhel6/src/Makefile b/rhel6/src/Makefile index 9d62ace..8649f66 100644 --- a/rhel6/src/Makefile +++ b/rhel6/src/Makefile @@ -2,9 +2,9 @@ IN=input OUT=output TRANS=transforms REFS=references -DIST=dist +DIST=scap-security-guide-alpha
-all: shorthand-guide shorthand2xccdf tables guide checks content dist +all: shorthand-guide shorthand2xccdf tables guide checks content dist rpm
shorthand-guide: xsltproc -o ${OUT}/rhel6-shorthand.xml ${IN}/guide.xslt ${IN}/guide.xml @@ -77,6 +77,35 @@ dist: content guide tables cp ${OUT}/rhel6-table-cnssrefs.html ${DIST}/policytables cp ${OUT}/rhel6-table-dcidrefs.html ${DIST}/policytables
+rpm: dist
- # A few quick notes on preparing your system to build the SSG RPMs:
- # (1) May the flies of a thousand horses annoy you for eternity
- # if you build an RPM as root. Don't do it!
- # (2) This build process assumes you have your rpmbuild structure setup
- # $ sudo yum -y install rpm-build
- # $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
- # (3) The value if ${DIST} in this Makefile needs to match
- # the %{name}-%{version} string from the .spec file, i.e.
- # scap-security-guide-alpha
- # (4) If you're making an RPM, chances are the code has changed. Make
- # sure you update the %changelog in the .spec to reflect what's new
- # copy template .spec over to rpmbuild
- cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/
- # tar up the sources
- tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST}
- mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/
- # let's see if a build works
- rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec
- # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back
- mv ~/rpmbuild/RPMS/ ${OUT}/
- clean:
- rm -f ${OUT}/*.xml ${OUT}/*.html ${OUT}/*.pdf
- rm -f ${OUT}/*.xml ${OUT}/*.html ${OUT}/*.pdf ${OUT}/*.spec ${OUT}/*.tar ${OUT}/*.gz ${OUT}/*.ini rm -f ${DIST}/policytables/*.html ${DIST}/guide/*.html ${DIST}/content/*.xml
- rm -rf ${OUT}/RPMS/
diff --git a/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec b/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec new file mode 100644 index 0000000..01ad83f --- /dev/null +++ b/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec @@ -0,0 +1,64 @@ +Name: scap-security-guide +Version: alpha +Release: 1%{?dist} +Summary: The scap-security-guide project, or SSG for short, aims to deliver security guidance, baselines, and associated validation mechanisms for Red Hat Enterprise Linux.
+Group: Testing +License: GPL +URL:https://fedorahosted.org/scap-security-guide/
+Source0: %{name}-%{version}.tar.gz +BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
+BuildArch: noarch
+BuildRequires: /bin/rm, /bin/mkdir, /bin/cp +Requires: /bin/bash, /bin/date, /usr/bin/oscap
+%description +Today the SSG project provides guidance against U.S. Government requirements, +including those of the U.S. Department of Defense and U.S. Intelligence Community. +Many U.S. Government policies, such as NIST 800-53 provide prose stating that +System Administrators must audit "privileged user actions," but do not define +what such actions are. The SSG bridges the gap between generalized U.S. +Government Policy and specific implementation guidance.
+To lean more about the SCAP Security Guide project, please +visithttps://fedorahosted.org/mailman/listinfo/scap-security-guide. Here +you will be able to find documentation, support, and information on getting +involved in the SCAP Security Guide community.
+%prep +%setup -q
+%build +#configure +#`make %{?_smp_mflags}
+%install +rm -rf $RPM_BUILD_ROOT +#make install DESTDIR=$RPM_BUILD_ROOT +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submission
+cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/
+%clean +rm -rf $RPM_BUILD_ROOT
+%files +%defattr(-,root,root,-) +%doc
+%attr(0750,root,root)/usr/local/scap-security-guide/
+%changelog +* Mon Apr 02 2012 Shawn Wellsshawn@redhat.com 1.0-1 +- First attempt at SSG RPM. May ${diety} help us... diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore index 7206c02..4bbeae5 100644 --- a/rhel6/src/output/.gitignore +++ b/rhel6/src/output/.gitignore @@ -3,3 +3,8 @@ *.html *.pdf *.ini +*.spec +*.tar +*.gz +scap-security-guide-*/ +RPMS/ -- 1.7.1
Pushed
On 4/2/12 1:31 PM, "Shawn Wells" shawn@redhat.com wrote:
+rpm: dist
- # A few quick notes on preparing your system to build the SSG RPMs:
- # (1) May the flies of a thousand horses annoy you for eternity
- # if you build an RPM as root. Don't do it!
- # (2) This build process assumes you have your rpmbuild structure
setup
- # $ sudo yum -y install rpm-build
- # $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
- # (3) The value if ${DIST} in this Makefile needs to match
- # the %{name}-%{version} string from the .spec file, i.e.
- # scap-security-guide-alpha
- # (4) If you're making an RPM, chances are the code has changed. Make
- # sure you update the %changelog in the .spec to reflect what's
new
- # copy template .spec over to rpmbuild
- cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/
- # tar up the sources
- tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST}
- mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/
- # let's see if a build works
- rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec
- # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back
- mv ~/rpmbuild/RPMS/ ${OUT}/
I'm not happy with assumptions regarding user environment. We don't control rpmbuild or the RPM macros file. Barring those issues this also makes some assumptions about directory structure that might not be correct.
clean:
- rm -f ${OUT}/*.xml ${OUT}/*.html ${OUT}/*.pdf
- rm -f ${OUT}/*.xml ${OUT}/*.html ${OUT}/*.pdf ${OUT}/*.spec
${OUT}/*.tar ${OUT}/*.gz ${OUT}/*.ini rm -f ${DIST}/policytables/*.html ${DIST}/guide/*.html ${DIST}/content/*.xml
- rm -rf ${OUT}/RPMS/
Should these be moved into a bare target?
diff --git a/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec b/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec new file mode 100644 index 0000000..01ad83f --- /dev/null +++ b/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec @@ -0,0 +1,64 @@ +Name: scap-security-guide +Version: alpha +Release: 1%{?dist} +Summary: The scap-security-guide project, or SSG for short, aims to deliver security guidance, baselines, and associated validation mechanisms for Red Hat Enterprise Linux.
+Group: Testing +License: GPL +URL: https://fedorahosted.org/scap-security-guide/
+Source0: %{name}-%{version}.tar.gz +BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
+BuildArch: noarch
+BuildRequires: /bin/rm, /bin/mkdir, /bin/cp +Requires: /bin/bash, /bin/date, /usr/bin/oscap
+%description +Today the SSG project provides guidance against U.S. Government requirements, +including those of the U.S. Department of Defense and U.S. Intelligence Community. +Many U.S. Government policies, such as NIST 800-53 provide prose stating that +System Administrators must audit "privileged user actions," but do not define +what such actions are. The SSG bridges the gap between generalized U.S. +Government Policy and specific implementation guidance.
+To lean more about the SCAP Security Guide project, please +visit https://fedorahosted.org/mailman/listinfo/scap-security-guide. Here +you will be able to find documentation, support, and information on getting +involved in the SCAP Security Guide community.
+%prep +%setup -q
+%build +#configure +#`make %{?_smp_mflags}
+%install +rm -rf $RPM_BUILD_ROOT +#make install DESTDIR=$RPM_BUILD_ROOT +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submission
How does this work if $RPM_BUILD_ROOT has spaces?
+cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/
+%clean +rm -rf $RPM_BUILD_ROOT
+%files +%defattr(-,root,root,-) +%doc
+%attr(0750,root,root)/usr/local/scap-security-guide/
+%changelog +* Mon Apr 02 2012 Shawn Wells shawn@redhat.com mailto:shawn@redhat.com 1.0-1 +- First attempt at SSG RPM. May ${diety} help us... diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore index 7206c02..4bbeae5 100644 --- a/rhel6/src/output/.gitignore +++ b/rhel6/src/output/.gitignore @@ -3,3 +3,8 @@ *.html *.pdf *.ini +*.spec +*.tar +*.gz +scap-security-guide-*/
+RPMS/
1.7.1
Pushed
I'd prefer to wait for at least one ACK before pushing. IMO an ACK from anyone with commit access should be sufficient for a merge/push. Thoughts?
Thanks, --Spencer
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/2/12 1:52 PM, Spencer R. Shimko wrote:
On 4/2/12 1:31 PM, "Shawn Wells"shawn@redhat.com wrote:
+rpm: dist
- # A few quick notes on preparing your system to build the SSG RPMs:
- # (1) May the flies of a thousand horses annoy you for eternity
- # if you build an RPM as root. Don't do it!
- # (2) This build process assumes you have your rpmbuild structure
setup
- # $ sudo yum -y install rpm-build
- # $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
- # (3) The value if ${DIST} in this Makefile needs to match
- # the %{name}-%{version} string from the .spec file, i.e.
- # scap-security-guide-alpha
- # (4) If you're making an RPM, chances are the code has changed. Make
- # sure you update the %changelog in the .spec to reflect what's
new
- # copy template .spec over to rpmbuild
- cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/
- # tar up the sources
- tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST}
- mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/
- # let's see if a build works
- rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec
- # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back
- mv ~/rpmbuild/RPMS/ ${OUT}/
I'm not happy with assumptions regarding user environment. We don't control rpmbuild or the RPM macros file. Barring those issues this also makes some assumptions about directory structure that might not be correct.
All valid. I wanted to get *something* in there that would work on a stock RHEL6 build system.
What I'd *really* like to see is input/rpmbuild be setup as a localized buildroot which would allow us to be completely self contained (and much more elegant). But I have no idea how to do that and in mucking around it didn't become apparent to me. Hopefully someone with more RPM knowledge than me could patch to make that happen.
clean:
- rm -f ${OUT}/*.xml ${OUT}/*.html ${OUT}/*.pdf
- rm -f ${OUT}/*.xml ${OUT}/*.html ${OUT}/*.pdf ${OUT}/*.spec
${OUT}/*.tar ${OUT}/*.gz ${OUT}/*.ini rm -f ${DIST}/policytables/*.html ${DIST}/guide/*.html ${DIST}/content/*.xml
- rm -rf ${OUT}/RPMS/
Should these be moved into a bare target?
Yes, I caught that too. Done.
diff --git a/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec b/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec new file mode 100644 index 0000000..01ad83f --- /dev/null +++ b/rhel6/src/input/rpmbuild/scap-security-guide-alpha.spec @@ -0,0 +1,64 @@ +Name: scap-security-guide +Version: alpha +Release: 1%{?dist} +Summary: The scap-security-guide project, or SSG for short, aims to deliver security guidance, baselines, and associated validation mechanisms for Red Hat Enterprise Linux.
+Group: Testing +License: GPL +URL:https://fedorahosted.org/scap-security-guide/
+Source0: %{name}-%{version}.tar.gz +BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
+BuildArch: noarch
+BuildRequires: /bin/rm, /bin/mkdir, /bin/cp +Requires: /bin/bash, /bin/date, /usr/bin/oscap
+%description +Today the SSG project provides guidance against U.S. Government requirements, +including those of the U.S. Department of Defense and U.S. Intelligence Community. +Many U.S. Government policies, such as NIST 800-53 provide prose stating that +System Administrators must audit "privileged user actions," but do not define +what such actions are. The SSG bridges the gap between generalized U.S. +Government Policy and specific implementation guidance.
+To lean more about the SCAP Security Guide project, please +visithttps://fedorahosted.org/mailman/listinfo/scap-security-guide. Here +you will be able to find documentation, support, and information on getting +involved in the SCAP Security Guide community.
+%prep +%setup -q
+%build +#configure +#`make %{?_smp_mflags}
+%install +rm -rf $RPM_BUILD_ROOT +#make install DESTDIR=$RPM_BUILD_ROOT +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submission
How does this work if $RPM_BUILD_ROOT has spaces?
Assumed stock environment. Patches welcome.
+cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/
+%clean +rm -rf $RPM_BUILD_ROOT
+%files +%defattr(-,root,root,-) +%doc
+%attr(0750,root,root)/usr/local/scap-security-guide/
+%changelog +* Mon Apr 02 2012 Shawn Wellsshawn@redhat.com mailto:shawn@redhat.com 1.0-1 +- First attempt at SSG RPM. May ${diety} help us... diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore index 7206c02..4bbeae5 100644 --- a/rhel6/src/output/.gitignore +++ b/rhel6/src/output/.gitignore @@ -3,3 +3,8 @@ *.html *.pdf *.ini +*.spec +*.tar +*.gz +scap-security-guide-*/
+RPMS/
1.7.1
PushedI'd prefer to wait for at least one ACK before pushing. IMO an ACK from anyone with commit access should be sufficient for a merge/push. Thoughts?
Personally I'd like to see *every* patch hit the mailing list and get 1-2 ack's, but it's been the wild west as we get core content created. While I want it now, I'm thinking that once alpha drops all patches need to be sent out before commits.
On 4/2/12 2:27 PM, "Shawn Wells" shawn@redhat.com wrote:
On 4/2/12 1:52 PM, Spencer R. Shimko wrote:
On 4/2/12 1:31 PM, "Shawn Wells" <shawn@redhat.com>mailto:shawn@redhat.com wrote:
> >+rpm: dist
- # A few quick notes on preparing your system to build the SSG RPMs:
- # (1) May the flies of a thousand horses annoy you for eternity
- # if you build an RPM as root. Don't do it!
- # (2) This build process assumes you have your rpmbuild structure
setup
- # $ sudo yum -y install rpm-build
- # $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
- # (3) The value if ${DIST} in this Makefile needs to match
- # the %{name}-%{version} string from the .spec file, i.e.
- # scap-security-guide-alpha
- # (4) If you're making an RPM, chances are the code has changed.
Make
- # sure you update the %changelog in the .spec to reflect what's
new
- # copy template .spec over to rpmbuild
- cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/
- # tar up the sources
- tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST}
- mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/>+
- # let's see if a build works
- rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec
- # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back
- mv ~/rpmbuild/RPMS/ ${OUT}/
I'm not happy with assumptions regarding user environment. Wedon't control rpmbuild or the RPM macros file. Barring those issues this also makes some assumptions about directory structure that might not be correct.
All valid. I wanted to get *something* in there that would work on a stock RHEL6 build system.
What I'd *really* like to see is input/rpmbuild be setup as a localized buildroot which would allow us to be completely self contained (and much more elegant). But I have no idea how to do that and in mucking around it didn't become apparent to me. Hopefully someone with more RPM knowledge than me could patch to make that happen.
How about supporting both mock and plain RPM builds? We have a build system that does that internally that we can apply to this situation (we are done with the fragility of build VMs). But the caveat here is that it comes with some rather significant complexity. Not auto make's level of complexity, but perhaps unnecessary complexity for this project.
A simpler approach that just handles RPM builds (no mock) can be found here: http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/build/Makefile
<snip>
+%install +rm -rf $RPM_BUILD_ROOT +#make install DESTDIR=$RPM_BUILD_ROOT +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft +mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submission
How does this work if $RPM_BUILD_ROOT has spaces?Assumed stock environment. Patches welcome.
Cool. FWIW the link I pasted above has the same issue. I'll fix it up in SSG and push a patch soonish.
>++cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/
+%clean +rm -rf $RPM_BUILD_ROOT
+%files +%defattr(-,root,root,-) +%doc
+%attr(0750,root,root)/usr/local/scap-security-guide/>+ +%changelog +* Mon Apr 02 2012 Shawn Wells shawn@redhat.com mailto:shawn@redhat.com>mailto:shawn@redhat.com mailto:shawn@redhat.com 1.0-1 +- First attempt at SSG RPM. May ${diety} help us... diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore index 7206c02..4bbeae5 100644 --- a/rhel6/src/output/.gitignore +++ b/rhel6/src/output/.gitignore @@ -3,3 +3,8 @@ *.html *.pdf *.ini +*.spec +*.tar +*.gz +scap-security-guide-*/
+RPMS/
1.7.1
Pushed
I'd prefer to wait for at least one ACK before pushing. IMO anACK from anyone with commit access should be sufficient for a merge/push. Thoughts?
Personally I'd like to see *every* patch hit the mailing list and get 1-2 ack's, but it's been the wild west as we get core content created. While I want it now, I'm thinking that once alpha drops all patches need to be sent out before commits.
Sounds good to me.
Thanks, --Spencer
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
On 4/2/12 2:58 PM, Spencer R. Shimko wrote:
On 4/2/12 2:27 PM, "Shawn Wells"shawn@redhat.com wrote:
On 4/2/12 1:52 PM, Spencer R. Shimko wrote: On 4/2/12 1:31 PM, "Shawn Wells"<shawn@redhat.com>mailto:shawn@redhat.com wrote:
> >+rpm: dist
- # A few quick notes on preparing your system to build the SSG RPMs:
- # (1) May the flies of a thousand horses annoy you for eternity
- # if you build an RPM as root. Don't do it!
- # (2) This build process assumes you have your rpmbuild structure
setup
- # $ sudo yum -y install rpm-build
- # $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
- # (3) The value if ${DIST} in this Makefile needs to match
- # the %{name}-%{version} string from the .spec file, i.e.
- # scap-security-guide-alpha
- # (4) If you're making an RPM, chances are the code has changed.
Make
- # sure you update the %changelog in the .spec to reflect what's
new
- # copy template .spec over to rpmbuild
- cp ${IN}/rpmbuild/scap-security-guide-alpha.spec ${OUT}/
- # tar up the sources
- tar -zcvf ${OUT}/scap-security-guide-alpha.tar.gz ${DIST}
- mv ${OUT}/scap-security-guide-alpha.tar.gz ~/rpmbuild/SOURCES/>+
- # let's see if a build works
- rpmbuild -ba ${OUT}/scap-security-guide-alpha.spec
- # Our RPM(s) will be waiting for us in ${HOMEDIR}, so copy them back
- mv ~/rpmbuild/RPMS/ ${OUT}/
I'm not happy with assumptions regarding user environment. Wedon't control rpmbuild or the RPM macros file. Barring those issues this also makes some assumptions about directory structure that might not be correct.
All valid. I wanted to get*something* in there that would work on a stock RHEL6 build system. What I'd*really* like to see is input/rpmbuild be setup as a localized buildroot which would allow us to be completely self contained (and much more elegant). But I have no idea how to do that and in mucking around it didn't become apparent to me. Hopefully someone with more RPM knowledge than me could patch to make that happen.How about supporting both mock and plain RPM builds? We have a build system that does that internally that we can apply to this situation (we are done with the fragility of build VMs). But the caveat here is that it comes with some rather significant complexity. Not auto make's level of complexity, but perhaps unnecessary complexity for this project.
A simpler approach that just handles RPM builds (no mock) can be found here: http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/build/Makefile
Read through your Makefile.... very clean. I've got no objections on using mock, especially to create the SRPMs. And IMO there shouldn't be much of a problem introducing complexity if it creates cleaner output than we're otherwise capable of producing.
Are you volunteering to clean up the Makefile, or should I take a stab at it?
###
<snip> >> >>+%install >> >>+rm -rf $RPM_BUILD_ROOT >> >>+#make install DESTDIR=$RPM_BUILD_ROOT >> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/content >> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/guide >> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/policytables >> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/STIG-draft >> >>+mkdir -p $RPM_BUILD_ROOT/usr/local/%{name}/USGCB-submission > > > > > > > > How does this work if $RPM_BUILD_ROOT has spaces? > > > > > > > > > > Assumed stock environment. Patches welcome. Cool. FWIW the link I pasted above has the same issue. I'll fix it up in SSG and push a patch soonish.
>++cp -r * $RPM_BUILD_ROOT/usr/local/%{name}/
+%clean +rm -rf $RPM_BUILD_ROOT
+%files +%defattr(-,root,root,-) +%doc
+%attr(0750,root,root)/usr/local/scap-security-guide/>+ +%changelog +* Mon Apr 02 2012 Shawn Wellsshawn@redhat.com mailto:shawn@redhat.com>mailto:shawn@redhat.com mailto:shawn@redhat.com 1.0-1 +- First attempt at SSG RPM. May ${diety} help us... diff --git a/rhel6/src/output/.gitignore b/rhel6/src/output/.gitignore index 7206c02..4bbeae5 100644 --- a/rhel6/src/output/.gitignore +++ b/rhel6/src/output/.gitignore @@ -3,3 +3,8 @@ *.html *.pdf *.ini +*.spec +*.tar +*.gz +scap-security-guide-*/
+RPMS/
1.7.1
>>>
>
PushedI'd prefer to wait for at least one ACK before pushing. IMO anACK from anyone with commit access should be sufficient for a merge/push. Thoughts?
Personally I'd like to see*every* patch hit the mailing list and get 1-2 ack's, but it's been the wild west as we get core content created. While I want it now, I'm thinking that once alpha drops all patches need to be sent out before commits.Sounds good to me.
Forgive the format issues but my mail client isn't playing nice tonight.
On 4/2/12 1:31 PM, "Shawn Wells" <shawn@redhat.com>mailto:shawn@redhat.com>mailto:shawn@redhat.com mailto:shawn@redhat.com wrote:
> >+rpm: dist
>>
I'm not happy with assumptions regarding user environment. Wedon't control rpmbuild or the RPM macros file. Barring those issues this also makes some assumptions about directory structure that might not be correct.
All valid. I wanted to get *something* in there that would work on a stock RHEL6 build system.
What I'd *really* like to see is input/rpmbuild be setup as a localized buildroot which would allow us to be completely self contained (and much more elegant). But I have no idea how to do that and in mucking around it didn't become apparent to me. Hopefully someone with more RPM knowledge than me could patch to make that happen.
How about supporting both mock and plain RPM builds? We have a build system that does that internally that we can apply to this situation (we are done with the fragility of build VMs). But the caveat here is that it comes with some rather significant complexity. Not auto make's level of complexity, but perhaps unnecessary complexity for this project.
A simpler approach that just handles RPM builds (no mock) can be found here:
http://oss.tresys.com/projects/clip/browser/trunk/refpolicy/build/Makefil e
Read through your Makefile.... very clean. I've got no objections on using mock, especially to create the SRPMs. And IMO there shouldn't be much of a problem introducing complexity if it creates cleaner output than we're otherwise capable of producing.
Are you volunteering to clean up the Makefile, or should I take a stab at it?
Yup sign me up :) I'll submit a patch in the next day or two for the RPM rolling outside of mock. I'll submit an update that will support mock if folks think it is worth the pain.
Thanks, --Spencer
-- Shawn Wells Technical Director, U.S. Intelligence Programs (e) shawn@redhat.com (c) 443.534.0130
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orghttps://fedorahosted.org/mailman/ listinfo/scap-security-guide
Spencer, is there a project with a similar workflow that you believe does this in a preferable way? We will reach resolution on this (but I am swamped today).
I'd prefer to wait for at least one ACK before pushing. IMO an ACK from anyone with commit access should be sufficient for a merge/push. Thoughts?
Commits that involve moving directories or adding Makerules should definitely be vetted by a second party. I think more minor stuff (like adding SCAP content such as references or new Rules) is fine for direct commit. I also need to document some rules for writing Rules (ahem) on the wiki, to ensure proper granularity.
On 4/2/12 2:35 PM, "Jeffrey Blank" blank@eclipse.ncsc.mil wrote:
Spencer, is there a project with a similar workflow that you believe does this in a preferable way? We will reach resolution on this (but I am swamped today).
Yup the libvirt project. They actually started down a similar path as SSG without the need for ACKs before merge. But as the project matured and the number of contributors grew the work flow changed to the ACK/NACK model. As another example the SELinux userspace project follows this model. SELinux's userspace workflow changed fairly recently. Now they queue submitted patches in what is effectively a second branch. Then someone (anyone) pops a patch off the queue in that branch and ACKs/NACKs it and it gets merged into master.
I'd prefer to wait for at least one ACK before pushing. IMO an ACK from anyone with commit access should be sufficient for a merge/push. Thoughts?
Commits that involve moving directories or adding Makerules should definitely be vetted by a second party. I think more minor stuff (like adding SCAP content such as references or new Rules) is fine for direct commit. I also need to document some rules for writing Rules (ahem) on the wiki, to ensure proper granularity.
I agree the content is straight forward and *shouldn't* be an issue. But there is always the chance it will break something, e.g. someone forgot to "git add" a file and the build system breaks. Perhaps just an elimination period? If someone posts something and 48 hours later hasn't gotten a NACK they are free to merge. I like some form of acknowledgement but I'm not too stuck in my ways so if we just do straight merges and "advertise" master->HEAD as possibly unstable I think that is fine too.
Thanks, --Spencer
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Shawn Wells -
Shawn Wells -
Spencer R. Shimko