--- autoqa.spec | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/autoqa.spec b/autoqa.spec index 73ae957..ffe22c2 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -6,7 +6,7 @@ Name: autoqa Summary: Automated quality assurance framework Version: 0.4.4 -Release: 0.1.pre%{?dist} +Release: 0.2.pre%{?dist} Source0: http://fedorahosted.org/autoqa/releases/%%7Bname%7D-%%7Bversion%7D.tar.gz License: GPLv2+ Group: Applications/Internet @@ -65,6 +65,18 @@ rm -rf $RPM_BUILD_ROOT
%changelog +* Tue Mar 08 2011 James Laska jlaska@redhat.com - 0.4.4-0.2.pre +- upgradepath: run on post-bodhi-update-batch, test all updates, send bodhi + comments (kparal) +- depcheck: enable scheduling for -batch event (jskladan) +- Stop using epoch in NVR variables (kparal, jskladan) +- Replace old bodhi watcher with new koji watcher (jskladan) +- Ticket#269 - update repoinfo.conf for Fedora 15 branch (jlaska) +- Add a setup method to the no-swap-lvm test suite. (clumens) +- Update documentation in testclass template regarding email subject (kparal) +- bodhi_already_commented() does not require user arg anymore (kparal) +- New test - depcheck (wwoods) + * Tue Jan 25 2011 James Laska jlaska@redhat.com - 0.4.4-0.1.pre - Add BuildRequire: autotest (jlaska) - Copy config files to clients in a better way (jlaska)
Greetings,
I've just pushed this in master along with a new tag for the version-release. No functionality changes, this is just updating the spec for another pre-release build before 0.4.4.
Thanks, James
On Tue, 2011-03-08 at 12:16 -0500, James Laska wrote:
autoqa.spec | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/autoqa.spec b/autoqa.spec index 73ae957..ffe22c2 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -6,7 +6,7 @@ Name: autoqa Summary: Automated quality assurance framework Version: 0.4.4 -Release: 0.1.pre%{?dist} +Release: 0.2.pre%{?dist} Source0: http://fedorahosted.org/autoqa/releases/%%7Bname%7D-%%7Bversion%7D.tar.gz License: GPLv2+ Group: Applications/Internet @@ -65,6 +65,18 @@ rm -rf $RPM_BUILD_ROOT
%changelog +* Tue Mar 08 2011 James Laska jlaska@redhat.com - 0.4.4-0.2.pre +- upgradepath: run on post-bodhi-update-batch, test all updates, send bodhi
- comments (kparal)
+- depcheck: enable scheduling for -batch event (jskladan) +- Stop using epoch in NVR variables (kparal, jskladan) +- Replace old bodhi watcher with new koji watcher (jskladan) +- Ticket#269 - update repoinfo.conf for Fedora 15 branch (jlaska) +- Add a setup method to the no-swap-lvm test suite. (clumens) +- Update documentation in testclass template regarding email subject (kparal) +- bodhi_already_commented() does not require user arg anymore (kparal) +- New test - depcheck (wwoods)
- Tue Jan 25 2011 James Laska jlaska@redhat.com - 0.4.4-0.1.pre
- Add BuildRequire: autotest (jlaska)
- Copy config files to clients in a better way (jlaska)
On Tue, 2011-03-08 at 12:18 -0500, James Laska wrote:
Greetings,
I've just pushed this in master along with a new tag for the version-release. No functionality changes, this is just updating the spec for another pre-release build before 0.4.4.
I just pushed out a new build of autoqa to the -testing repos. I'll setup a test instance and do a sample deployment tomorrow.
The following repo configuration should pull down autoqa-0.4.4-0.2.pre for fedora-[15,14,13].
http://repos.fedorapeople.org/repos/fedora-qa/autoqa/fedora-autoqa-testing.r...
Thanks, James
Only root can chgrp files, and since mock doesn't allow running as root, 'install -g autotest' was failing. This patch moves the group permission adjustment into %attr in the %files section of the rpm. Anyone running autoqa without rpm's installed will need to manually adjust the permissions. --- Makefile | 2 +- autoqa.spec | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 4a2134a..4153590 100644 --- a/Makefile +++ b/Makefile @@ -23,7 +23,7 @@ install: build install autoqa $(PREFIX)/usr/bin/ install -d $(PREFIX)/etc/autoqa [ -f $(PREFIX)/etc/autoqa/autoqa.conf ] || install -m 0644 autoqa.conf $(PREFIX)/etc/autoqa/ - [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 -g autotest fas.conf $(PREFIX)/etc/autoqa + [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf $(PREFIX)/etc/autoqa install -m 0644 repoinfo.conf $(PREFIX)/etc/autoqa/ install -d $(PREFIX)$(HOOK_DIR) for h in hooks/*; do cp -a $$h $(PREFIX)$(HOOK_DIR); done diff --git a/autoqa.spec b/autoqa.spec index ffe22c2..f45c2cf 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -15,7 +15,6 @@ Requires: autotest Requires: koji Requires: python-fedora Requires: mod_wsgi -BuildRequires: autotest BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot BuildArch: noarch
@@ -38,7 +37,7 @@ make build PYTHON=%{__python} rm -rf $RPM_BUILD_ROOT make install PREFIX=$RPM_BUILD_ROOT TEST_DIR=%{testdir} HOOK_DIR=%{hookdir} PYTHON=%{__python} install -m 644 autoqa.conf repoinfo.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/ -install -m 640 -g autotest fas.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/ +install -m 640 fas.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/
%clean @@ -50,7 +49,7 @@ rm -rf $RPM_BUILD_ROOT %doc README LICENSE TODO autoqa.cron %dir %{_sysconfdir}/autoqa %config(noreplace) %{_sysconfdir}/autoqa/autoqa.conf -%config(noreplace) %{_sysconfdir}/autoqa/fas.conf +%config(noreplace) %attr(0640,autoqa,autotest) %{_sysconfdir}/autoqa/fas.conf %config %{_sysconfdir}/autoqa/repoinfo.conf %config(noreplace) %{testdir}/rats_sanity/irb.cfg %config(noreplace) %{_sysconfdir}/httpd/conf.d/autoqa-git-hook.conf
--- autoqa.spec | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/autoqa.spec b/autoqa.spec index f45c2cf..93e1c7e 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -15,6 +15,7 @@ Requires: autotest Requires: koji Requires: python-fedora Requires: mod_wsgi +BuildRequires: python2-devel BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot BuildArch: noarch
----- Original Message -----
Only root can chgrp files, and since mock doesn't allow running as root, 'install -g autotest' was failing. This patch moves the group permission adjustment into %attr in the %files section of the rpm. Anyone running autoqa without rpm's installed will need to manually adjust the permissions.
Makefile | 2 +- autoqa.spec | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 4a2134a..4153590 100644 --- a/Makefile +++ b/Makefile @@ -23,7 +23,7 @@ install: build install autoqa $(PREFIX)/usr/bin/ install -d $(PREFIX)/etc/autoqa [ -f $(PREFIX)/etc/autoqa/autoqa.conf ] || install -m 0644 autoqa.conf $(PREFIX)/etc/autoqa/
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 -g autotest
fas.conf $(PREFIX)/etc/autoqa
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf
$(PREFIX)/etc/autoqa
Can we add conditional chgrp when running as root (after installing that file), or is it too much hassle?
install -m 0644 repoinfo.conf $(PREFIX)/etc/autoqa/ install -d $(PREFIX)$(HOOK_DIR) for h in hooks/*; do cp -a $$h $(PREFIX)$(HOOK_DIR); done diff --git a/autoqa.spec b/autoqa.spec index ffe22c2..f45c2cf 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -15,7 +15,6 @@ Requires: autotest Requires: koji Requires: python-fedora Requires: mod_wsgi -BuildRequires: autotest BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot BuildArch: noarch
@@ -38,7 +37,7 @@ make build PYTHON=%{__python} rm -rf $RPM_BUILD_ROOT make install PREFIX=$RPM_BUILD_ROOT TEST_DIR=%{testdir} HOOK_DIR=%{hookdir} PYTHON=%{__python} install -m 644 autoqa.conf repoinfo.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/ -install -m 640 -g autotest fas.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/ +install -m 640 fas.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/
I don't know much about packaging, maybe a silly question - why do we install all those config files again, when it was already done by "make install" command?
On Wed, 2011-03-09 at 03:21 -0500, Kamil Paral wrote:
----- Original Message -----
Only root can chgrp files, and since mock doesn't allow running as root, 'install -g autotest' was failing. This patch moves the group permission adjustment into %attr in the %files section of the rpm. Anyone running autoqa without rpm's installed will need to manually adjust the permissions.
Makefile | 2 +- autoqa.spec | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 4a2134a..4153590 100644 --- a/Makefile +++ b/Makefile @@ -23,7 +23,7 @@ install: build install autoqa $(PREFIX)/usr/bin/ install -d $(PREFIX)/etc/autoqa [ -f $(PREFIX)/etc/autoqa/autoqa.conf ] || install -m 0644 autoqa.conf $(PREFIX)/etc/autoqa/
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 -g autotest
fas.conf $(PREFIX)/etc/autoqa
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf
$(PREFIX)/etc/autoqa
Can we add conditional chgrp when running as root (after installing that file), or is it too much hassle?
I thought about it as well, but decided against it due to laziness and I didn't feel up for maintaining two solutions (rpm and 'make install'). But if you have a suggestion, I'll definitely add it to the set of patches.
install -m 0644 repoinfo.conf $(PREFIX)/etc/autoqa/ install -d $(PREFIX)$(HOOK_DIR) for h in hooks/*; do cp -a $$h $(PREFIX)$(HOOK_DIR); done diff --git a/autoqa.spec b/autoqa.spec index ffe22c2..f45c2cf 100644 --- a/autoqa.spec +++ b/autoqa.spec @@ -15,7 +15,6 @@ Requires: autotest Requires: koji Requires: python-fedora Requires: mod_wsgi -BuildRequires: autotest BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot BuildArch: noarch
@@ -38,7 +37,7 @@ make build PYTHON=%{__python} rm -rf $RPM_BUILD_ROOT make install PREFIX=$RPM_BUILD_ROOT TEST_DIR=%{testdir} HOOK_DIR=%{hookdir} PYTHON=%{__python} install -m 644 autoqa.conf repoinfo.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/ -install -m 640 -g autotest fas.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/ +install -m 640 fas.conf $RPM_BUILD_ROOT%{_sysconfdir}/autoqa/
I don't know much about packaging, maybe a silly question - why do we install all those config files again, when it was already done by "make install" command?
Not a silly question, good catch. It might be just code that aged and isn't needed anymore. I'll make an attempt to avoid duplication in the next build, or at least try to remember why this is in two places. If it's more than a simple change ... I'll likely punt to a ticket for later work.
Thanks, James
Can we add conditional chgrp when running as root (after installing that file), or is it too much hassle?
I thought about it as well, but decided against it due to laziness and I didn't feel up for maintaining two solutions (rpm and 'make install'). But if you have a suggestion, I'll definitely add it to the set of patches.
Laziness approved. Nobody probably wants to run production instance by installing from source. And the development machines don't usually have any security concerns (single-user only).
On Wed, 2011-03-09 at 08:31 -0500, James Laska wrote:
On Wed, 2011-03-09 at 03:21 -0500, Kamil Paral wrote:
I don't know much about packaging, maybe a silly question - why do we install all those config files again, when it was already done by "make install" command?
Not a silly question, good catch. It might be just code that aged and isn't needed anymore. I'll make an attempt to avoid duplication in the next build, or at least try to remember why this is in two places. If it's more than a simple change ... I'll likely punt to a ticket for later work.
This should be straight forward to fix. I'll adjust this when I push this set of autoqa.spec changes.
Thanks! James
On Wed, 2011-03-09 at 03:21 -0500, Kamil Paral wrote:
----- Original Message -----
Only root can chgrp files, and since mock doesn't allow running as root, 'install -g autotest' was failing. This patch moves the group permission adjustment into %attr in the %files section of the rpm. Anyone running autoqa without rpm's installed will need to manually adjust the permissions.
Makefile | 2 +- autoqa.spec | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 4a2134a..4153590 100644 --- a/Makefile +++ b/Makefile @@ -23,7 +23,7 @@ install: build install autoqa $(PREFIX)/usr/bin/ install -d $(PREFIX)/etc/autoqa [ -f $(PREFIX)/etc/autoqa/autoqa.conf ] || install -m 0644 autoqa.conf $(PREFIX)/etc/autoqa/
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 -g
autotest fas.conf $(PREFIX)/etc/autoqa
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf
$(PREFIX)/etc/autoqa
Can we add conditional chgrp when running as root (after installing that file), or is it too much hassle?
I thought about it as well, but decided against it due to laziness and I didn't feel up for maintaining two solutions (rpm and 'make install'). But if you have a suggestion, I'll definitely add it to the set of patches.
I got bitten by this now. It wouldn't be a problem if it actually ran ok for 'make install' installations. But it doesn't, autotest doesn't have permission to read that file:
~~~~ AutoservRunError: scp -rq -P 22 "/etc/autoqa/"* 'root@aqc:"/etc/autoqa/"' * Command: scp -rq -P 22 "/etc/autoqa/"* 'root@aqc:"/etc/autoqa/"' Exit status: 1 Duration: 0
stderr: /etc/autoqa/fas.conf: Permission denied ~~~~
So my proposal is: What about to install fas.conf as 0644 in Makefile and then change it to %attr(0640,autoqa,autotest) in autoqa.spec?
This way it should work fine for development machines and production machines. The only change required is in Makefile: -[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf $(PREFIX)/etc/autoqa +[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0644 fas.conf $(PREFIX)/etc/autoqa
On Mon, 2011-04-04 at 08:43 -0400, Kamil Paral wrote:
On Wed, 2011-03-09 at 03:21 -0500, Kamil Paral wrote:
----- Original Message -----
Only root can chgrp files, and since mock doesn't allow running as root, 'install -g autotest' was failing. This patch moves the group permission adjustment into %attr in the %files section of the rpm. Anyone running autoqa without rpm's installed will need to manually adjust the permissions.
Makefile | 2 +- autoqa.spec | 5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile index 4a2134a..4153590 100644 --- a/Makefile +++ b/Makefile @@ -23,7 +23,7 @@ install: build install autoqa $(PREFIX)/usr/bin/ install -d $(PREFIX)/etc/autoqa [ -f $(PREFIX)/etc/autoqa/autoqa.conf ] || install -m 0644 autoqa.conf $(PREFIX)/etc/autoqa/
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 -g
autotest fas.conf $(PREFIX)/etc/autoqa
- [ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf
$(PREFIX)/etc/autoqa
Can we add conditional chgrp when running as root (after installing that file), or is it too much hassle?
I thought about it as well, but decided against it due to laziness and I didn't feel up for maintaining two solutions (rpm and 'make install'). But if you have a suggestion, I'll definitely add it to the set of patches.
I got bitten by this now. It wouldn't be a problem if it actually ran ok for 'make install' installations. But it doesn't, autotest doesn't have permission to read that file:
AutoservRunError: scp -rq -P 22 "/etc/autoqa/"* 'root@aqc:"/etc/autoqa/"' * Command: scp -rq -P 22 "/etc/autoqa/"* 'root@aqc:"/etc/autoqa/"' Exit status: 1 Duration: 0 stderr: /etc/autoqa/fas.conf: Permission deniedSo my proposal is: What about to install fas.conf as 0644 in Makefile and then change it to %attr(0640,autoqa,autotest) in autoqa.spec?
This way it should work fine for development machines and production machines. The only change required is in Makefile: -[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf $(PREFIX)/etc/autoqa +[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0644 fas.conf $(PREFIX)/etc/autoqa
Isn't it a bad idea to have fas.conf with permissions other than 0640, since it potentially contains a secret? Rather than preparing the system for potentially exposing your FAS password, what about just ignore fas.conf in 'make install' entirely? Leave it as an exercise for the developer?
Thanks, James
So my proposal is: What about to install fas.conf as 0644 in Makefile and then change it to %attr(0640,autoqa,autotest) in autoqa.spec?
This way it should work fine for development machines and production machines. The only change required is in Makefile: -[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf $(PREFIX)/etc/autoqa +[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0644 fas.conf $(PREFIX)/etc/autoqa
Isn't it a bad idea to have fas.conf with permissions other than 0640, since it potentially contains a secret? Rather than preparing the system for potentially exposing your FAS password, what about just ignore fas.conf in 'make install' entirely? Leave it as an exercise for the developer?
But 644 permissions should be present only when you do 'make install', when installing from rpm you should get 640. Thus I believe it only concerns developers. We can also add a big warning into fas.conf saying "Make sure this file is readable only by root and autotest user if you fill in secret data".
I want to reach a state where you checkout autoqa, make install, and it works. Because currently it fails and if you're not an autoqa expert, it's very hard to find out the cause. I'd like to eliminate those roadblocks, otherwise we won't get much help from the community, students, etc in the future.
If you don't want to change the permissions, the second solution is to add conditional statement into the Makefile and "chgrp autotest fas.conf" if running under root and autotest user is present. Thus it won't be executed in mock but it will be executed for AutoQA developers.
I'll gladly prepare a patch, just tell me which solution you find better. Or is there a third way?
On Tue, 2011-04-05 at 03:50 -0400, Kamil Paral wrote:
So my proposal is: What about to install fas.conf as 0644 in Makefile and then change it to %attr(0640,autoqa,autotest) in autoqa.spec?
This way it should work fine for development machines and production machines. The only change required is in Makefile: -[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf $(PREFIX)/etc/autoqa +[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0644 fas.conf $(PREFIX)/etc/autoqa
Isn't it a bad idea to have fas.conf with permissions other than 0640, since it potentially contains a secret? Rather than preparing the system for potentially exposing your FAS password, what about just ignore fas.conf in 'make install' entirely? Leave it as an exercise for the developer?
But 644 permissions should be present only when you do 'make install', when installing from rpm you should get 640. Thus I believe it only concerns developers. We can also add a big warning into fas.conf saying "Make sure this file is readable only by root and autotest user if you fill in secret data".
I want to reach a state where you checkout autoqa, make install, and it works. Because currently it fails and if you're not an autoqa expert, it's very hard to find out the cause. I'd like to eliminate those roadblocks, otherwise we won't get much help from the community, students, etc in the future.
If you don't want to change the permissions, the second solution is to add conditional statement into the Makefile and "chgrp autotest fas.conf" if running under root and autotest user is present. Thus it won't be executed in mock but it will be executed for AutoQA developers.
I'll gladly prepare a patch, just tell me which solution you find better. Or is there a third way?
Maybe a crazy idea, how possible would it be to emit a logging.warning if fas.conf is world-readable. Something like http://fpaste.org/R7UB/
If we have that warning, along with future logging improvements, this seems like a good fit for the 'make install' 644 approach you suggest. Thoughts?
Thanks, James
On Tue, 2011-04-05 at 10:31 -0400, James Laska wrote:
Maybe a crazy idea, how possible would it be to emit a logging.warning if fas.conf is world-readable. Something like http://fpaste.org/R7UB/
Corrected typo ... but you get the idea.
Thanks, James
On Tue, 2011-04-05 at 10:31 -0400, James Laska wrote:
On Tue, 2011-04-05 at 03:50 -0400, Kamil Paral wrote:
So my proposal is: What about to install fas.conf as 0644 in Makefile and then change it to %attr(0640,autoqa,autotest) in autoqa.spec?
This way it should work fine for development machines and production machines. The only change required is in Makefile: -[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0640 fas.conf $(PREFIX)/etc/autoqa +[ -f $(PREFIX)/etc/autoqa/fas.conf ] || install -m 0644 fas.conf $(PREFIX)/etc/autoqa
Isn't it a bad idea to have fas.conf with permissions other than 0640, since it potentially contains a secret? Rather than preparing the system for potentially exposing your FAS password, what about just ignore fas.conf in 'make install' entirely? Leave it as an exercise for the developer?
But 644 permissions should be present only when you do 'make install', when installing from rpm you should get 640. Thus I believe it only concerns developers. We can also add a big warning into fas.conf saying "Make sure this file is readable only by root and autotest user if you fill in secret data".
I want to reach a state where you checkout autoqa, make install, and it works. Because currently it fails and if you're not an autoqa expert, it's very hard to find out the cause. I'd like to eliminate those roadblocks, otherwise we won't get much help from the community, students, etc in the future.
If you don't want to change the permissions, the second solution is to add conditional statement into the Makefile and "chgrp autotest fas.conf" if running under root and autotest user is present. Thus it won't be executed in mock but it will be executed for AutoQA developers.
I'll gladly prepare a patch, just tell me which solution you find better. Or is there a third way?
Maybe a crazy idea, how possible would it be to emit a logging.warning if fas.conf is world-readable. Something like http://fpaste.org/R7UB/
If we have that warning, along with future logging improvements, this seems like a good fit for the 'make install' 644 approach you suggest. Thoughts?
Okay, after using my eyes to read the suggestoin (and with some extra details from Kamil) ... as long as fas.conf isn't world readable at any point, I don't see any problem doing a conditional chgrp in the 'make install' path. That seems completely reasonable.
Thanks, James
autoqa-devel@lists.fedorahosted.org
-
James Laska -
Kamil Paral