What: Could you please configure the webserver of docs.fp.o in a way that:
docs.fp.o
pagure.io/fedora-docs/fedora-docs-web
docs-old.fp.o
After this, could you also remove all the redirects from docs.fp.o to docs-old.fp.o, and set it up the other way round, so docs-old.fp.o would always redirect to docs.fp.o?
Why:
Currently, we host docs on two URLs:
The docs.fp.o is a main entrypoint, and has redirects to docs-old.fp.o for the old urls — so old links work and search engines are happy. The rules seem to be very simple:
docs.fp.o/en_US
docs.fp.o/<anything-else>
Because the current docs don't use the /en_US namespace, this works fine.
/en_US
However, the new Documentation will be using localization as well. So there is a conflict. Both, the old and the new, will be using namespaces such as /en_US. Good news is that the old and the new won't overlap. So having both, layered in the way described above, could be a solution.
Before Wednesday 1 August.
Never? It will be needed as long as we want to get the new docs out. Delaying this will delay the docs.
We would probably have to namespace the new docs, which would give us uglier URL, or figure out an alternative.
cc @bex
We will see about getting this setup (first in stg).
If someone else wants to work on it feel free, otherwise I will get to it likely early next week...
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Needs Review)
If @asamalik is away I am happy to help here
Also, I believe, but cannot verify that the files here:
are from https://pagure.io/fedora-docs-web
If so, I suggest we consider: 1. Moving it into the Fedora-Docs name space 2. Making the redirects referenced below a new commit on top of these files
yes, that is the repo it was pulling from. However, it's currently just a copy we last checked out there, it's not pulling from anywhere now. ;(
I don't know if it's possible to move repos in pagure. @pingou ?
We could also do the redirects in a new repo, or as part of the new docs... doesn't matter to me.
I don't think we plan to ever update the "old".
If we could do the redirects in a new repo (or a branch) that would be fantastic. I believe @bex pushed the redirect files into a "redirect" branch of https://pagure.io/fedora-docs/fedora-docs-web/tree/redirects — so getting it from there would be the best.
Yeah, that would work.
Hum, I see those all use "http://localhost:8080/" in them? Is that intended?
Oops, I don't think that's right. It should be "https://docs.fedoraproject.org/" for production. But if we wanna test it on staging, then it should be "https://docs.stg.fedoraproject.org/".
@kevin do you think that "/" would work?
@kevin OK, it looks it should work fine. Let me push a fix.
Pushed.
So, I have been hacking around with the staging setup.
I've not pulled the redirects yet, so this is just docs and docs-old.
There's some... oddities. For instance, the docs site has a /index.html in it, which means that one always 'wins', but the lack of that on the old site makes it work weirdly. For example:
https://docs.stg.fedoraproject.org/en_US/index.html works, but the sidebar is broken because the toc.html file is one more level up.
Perhaps thats not a big deal if you are just wanting old direct links to work?
Also, can you make a 'redirects-stg' branch? That way we can test redirects also in stg before prod...
@kevin
I have update the redirects branch to use the proper language code. I have crated a redirects-stg that is currently a duplicate.
I did some experimenting on my local box and I could not recreate your oddity. I used this procedure:
rsync -a
I'll be online, let's talk this through and see if we can get it ready for launch.
We want to get this out today. Is there anything I could help with?
There are also alternative options we could do short-term to get this out on time, i.e. pushing everything into the single repo and completely disabling all redirects.
ok. I have the proposed combined dir setup in stg.
two questions:
I am merging en-US to en_GB on the top level combined? Or what exact directories did you want merged in item 4?
The old docs has everything under a public_html dir (except the top level index and such). Did you want that at the top level or is it ok to be under public_html? ie, now I have:
/usr/bin/rsync -aH /srv/web/docs-old.fedoraproject.org/ /srv/web/docs-combined/ /usr/bin/rsync -aH /srv/web/docs-redirects/ /srv/web/docs-combined/ /usr/bin/rsync -aH /srv/web/docs.fedoraproject.org/ /srv/web/docs-combined/ /usr/bin/rsync -aH /srv/web/docs-combined/en-US/ /srv/web/docs-combined/en_GB/
Did you want instead:
/usr/bin/rsync -aH /srv/web/docs-old.fedoraproject.org/public_html/ /srv/web/docs-combined/ /usr/bin/rsync -aH /srv/web/docs-redirects/ /srv/web/docs-combined/ /usr/bin/rsync -aH /srv/web/docs.fedoraproject.org/ /srv/web/docs-combined/ /usr/bin/rsync -aH /srv/web/docs-combined/en-US/ /srv/web/docs-combined/en_GB/
WIth the current setup and public_html under / you get things like: https://docs.stg.fedoraproject.org/public_html/en-US/index.html which looks fine, but has that public_html in there.
ok. I have the proposed combined dir setup in stg. two questions: I am merging en-US to en_GB on the top level combined? Or what exact directories did you want merged in item 4?
ok. I have the proposed combined dir setup in stg. two questions:
en-US should merge to en-US. Ignore en_GB it was part of unrelated testing.
Visiting docs-old.fp.o doesn't have public_html. I think that hte public_html is spurious and was just part of a dump of data. I believe the webroot is public_html and that is what should be in / for the webserver. The files above it are aiui, uneeded.
we do not want public_html to appear in the URL
ok I think I have stg all in place for all that. Please check and we can go to prod early tomorrow morning.
@kevin - looks good. Let's coordinate to get this launched when you get in today. I have the magazine and commblog articles ready.
Also, I was thinking about the rsync. This isn't a launch blocker, but we should ideally make sure that new updates allow old pages to be removed. Perhaps we should spend 3 min discussing the final compose process.
ok, this should all be live now.
Let us know if you need anything else.
:checkered_flag:
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Everything seems to work well, thank you @kevin!
I think we can close this is as a 100% success :). We can open a new ticket when we figure out what of the 12GB of legacy data can be removed.
I've been meaning to reply to this for a while:
Basically it's not possible at the moment, doing the DB changes is easy, the issue is correctly handling the redirects (both at the web and the ssh level) and dealing with new project (say project X is renamed to Y, do we block X forever or allow someone else to create a project X again or??). If people are interested there is a ticket in upstream's pagure tracking it.
Login to comment on this ticket.