Hello, thanks everybody for the input! That helped to get a rough picture of what is needed. I'll try to sum it up below. A few detail questions are still open, answers welcome. Please also comment if I missed something. Am Montag, 25. November 2019, 16:31:09 CET schrieb Frank Sundermeyer:
On Monday, 25 November 2019 14:55:48 CET Ludwig Nussel wrote:
Do you know who is responsible for the main doc.o.o content
You can just copy the existing content it is static HTML only. If you give me a heads up before you do so, I will look into subdirs to see whether there is old stuff that can get deleted.
You can do the cleanup whenever you want - even *now* ;-)
I suggest to also use the existing virtual host config as a template for a new host to make sure nothing breaks.
Good idea. Looking at the apache config brought up some interesting details and questions: 1) There are two CGI scripts in the document root: - redirect.cgi - a quick look indicates it might be a leftover of activedoc, but I'm not sure - search.cgi - greps through projects/ and products/, but is terribly slow - (any other cgi script hidden in a subdirectory?) Are these scripts still used/needed? 2) Another interesting detail is that the release notes use MultiViews to deliver translated release notes based on the browser language settings. This means we'll have to use Apache for serving them - doing MultiViews with nginx looked somewhat scary when I last checked. This also means we can't use the static.o.o VMs because they run nginx. The pinot VM runs Apache already for counter.o.o and might be an option. It's bored anyway ;-) 3) I noticed that there's a .git directory - it seems to be a local git repo with the rendered documentation. The last commit was a year ago, and git status shows lots of modified files. What's the idea behind this local git repo? Any ideas why the changed files weren't commited for a year? Just as an idea - would commiting the rendered documentation to a git repo somewhere on github and pulling from there be an option for you? (Yes, I know that having generated files in a git repo is a bad idea in general, but IMHO it would still be better than doing manual rsync runs.) 4) I'll also need someone to review the existing redirects - I have a feeling that most of them redirect to targets that no longer exist... Currently there are the following redirects: RedirectMatch ^(/products/other/WebYaST/webyast-(vendor|user))$ https://doc.opensuse.org/$1_sd/ RedirectMatch ^(/products/other/WebYaST/webyast-(vendor|user))/(.*)$ https://doc.opensuse.org/$1_sd/$3 For comparison: # find -name '*_sd' ./products/opensuse/Styleguide/opensuse_documentation_styleguide_sd ./_obsolete_products/other/WebYaST/webyast-user_sd ./_obsolete_products/other/WebYaST/webyast-vendor_sd RedirectMatch ^/products/opensuse/(openSUSE[^/]*/.*) https://doc.opensuse.org/documentation/html/$1 /documentation/html/ doesn't exist. RedirectMatch ^/documentation/.*/openSUSE/(opensuse-|book\.)tuning https://doc.opensuse.org/book/opensuse-system-analysis-and-tuning-guide RedirectMatch ^/documentation/.*/openSUSE/(opensuse-|book\.)kvm https://doc.opensuse.org/book/opensuse-virtualization-with-kvm RedirectMatch ^/documentation/.*/openSUSE/(opensuse-|book\.)security https://doc.opensuse.org/book/opensuse-security-guide RedirectMatch ^/documentation/.*/openSUSE/(opensuse-|book\.opensuse\.)reference https://doc.opensuse.org/book/opensuse-reference RedirectMatch ^/documentation/.*/openSUSE/(opensuse-|book\.opensuse\.)startup https://doc.opensuse.org/book/opensuse-start-up /book/ doesn't exist. 5) The alternative domains (rtfm.o.o, docs.o.o, activedoc.o.o and www.activedoc.o.o get redirected to doc.o.o - doing that in haproxy probably makes more sense. 6) Not really problematic on the server side, but - /release-notes/index.html still uses the old bento theme. Ludwig, maybe you have some time to update it to the current design? 7) Note to myself: /home/relsync/release-notes-openSUSE (the scripts to deploy the release notes) are already managed on github.com/openSUSE/release-notes-openSUSE which makes things a bit easier.
The main pages for doc.o.o are created from https://github.com/openSUSE/doc.o.o
Static pages fall out of that repo and get copied to doc.o.o. To update the manuals I currently use scp--the plan is to also use the automated process we recently set up for documentation.suse.com in the future (it will only require an rsync target on the web server).
Enabling you to rsync (over ssh) shouldn't be hard ;-)
Until we are ready to do so, we need ssh access (as user lxbuch) to the new webserver root for doc.o.o.
Well, ssh access and rsync over ssh are not too different ;-) Regards, Christian Boltz -- I tip my hat to the creators of the SomeFool virus, for actually (albeit temporarily and minimally) affecting my Linux experience. However, if that's the most damage I can get by running viruses with Wine under a dummy account, then it's clear that the Wine developers have a long way to go before Wine is truly Windows compatible. [http://os.newsforge.com/article.pl?sid=05/01/25/1430222&from=rss] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org