If I want to see task artifacts from [[http://taskotron-dev.fedoraproject.org/taskmaster//builders/x86_64/builds/29343/ | this task]], I can either traverse the dirs by the date: http://taskotron-dev.fedoraproject.org/artifacts/20150608/6cc9a1a6-0dec-11e5-9e63-5254007dccf9/ or by uuid only, in the all/ dir: http://taskotron-dev.fedoraproject.org/artifacts/all/6cc9a1a6-0dec-11e5-9e63-5254007dccf9/
all/
The latter is of course more convenient (you don't need to look for the date), but it returns HTTP 403 Forbidden now. The same is true for: http://taskotron-dev.fedoraproject.org/artifacts/all/
It seems there are wrong permissions on the all/ dir.
it's not a permissions issue - its an apache config issue.
we changed the config for all/ to not display an index of files so that someone (or some bot) trying to load the page wouldn't get the entire directory. that configuration has extended to all/{uuid}/ directory.
all/{uuid}/
we either need to redirect to the non-all directory in this case or figure out how to work the apache config so that index is disabled for all/ but not its subdirectories
Got a fix from @somebody near the end of the day yesterday. Applied it to git just now, ran the taskotron-dev playbook and viola - subdirs of all/ aren't throwing 403s anymore. I'm going to run the change on stg and prod before closing the ticket.
@somebody - thanks for the fix, off to a great start :)
applied to dev, stg and prod. reopen if the problem is not actually fixed
It's broken again https://bodhi.fedoraproject.org/updates/cockpit-0.74-1.fc23 -> https://taskotron.fedoraproject.org/artifacts/all/d0612270-523e-11e5-9227-525400062113/task_output/cockpit-0.74-1.fc23.x86_64.log which throws 403...
turns out it's not the same issue at all. somehow, the selinux context for artifacts in production is different from dev/stg - must have changed when I reformatted /srv/ yesterday to give more inodes.
/srv/
relabeling /srv/taskotron on prod, looking to see if it keeps or if more changes are needed
/srv/taskotron
That seems to have fixed it - new artifacts dirs are inheriting selinux context from the parent dirs.
FWIW, the fix this second time around was chcon -R -t httpd_sys_content_t /srv/taskotron which made the context of prod artifacts match stg.
chcon -R -t httpd_sys_content_t /srv/taskotron
Closing this ticket, please reopen if it resurfaces
For some reason, the issue was on dev and stg as well. Running the chcon command fixed it.
Metadata Update from @kparal: - Issue tagged with: easyfix, infrastructure
Login to comment on this ticket.