On Monday, 25 November 2019 14:55:48 CET Ludwig Nussel wrote: Hi,

...

Do you know who is responsible for the main doc.o.o content (manuals etc.) and knows the setup, scripting etc. good enough to move it to another server? Can you please ask that person to join the discussion here?

Frank is taking care of that from the Doku team side AFAIK.

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. I suggest to also use the existing virtual host config as a template for a new host to make sure nothing breaks. 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). Until we are ready to do so, we need ssh access (as user lxbuch) to the new webserver root for doc.o.o.

...

For /release-notes/, your question implies that you know what is needed to get everything setup on a new server.

It's just a shell script in the home of the releng user that's downloading and extracting rpm packages. So moving the home dir of that user plus the cronjob and the apache config should be all that's needed.

...

Depending on how much scripting is needed, doc.o.o could either be moved to the narwal[5-7] machines hosting static.o.o, or to a separate VM.

(In theory, we could move the release notes to their own subdomain and move them independent of the manuals, but I slightly doubt if that is a good idea.)

I'll also add my usual sidenote: Ideally everything should be salted. (If needed, I can help with salt - but I'll at least need someone who knows what needs to be done).

-- Regards Frank Frank Sundermeyer, Project Manager Documentation SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg Tel: +49-911-74053-0, Fax: +49-911-7417755; http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, HRB 36809 (AG Nürnberg) "Reality is always controlled by the people who are most insane" Dogbert -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org

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

Hi, On 12/2/19 11:23 AM, Ludwig Nussel wrote:

Christian Boltz schrieb:

...

still uses the old bento theme. Ludwig, maybe you have some time to update it to the current design?

Well, all of doc.opensuse.org uses the same design. So whoever changes that will also have to change release-notes/index.html

We actually have 2 PR concerning the page design. I was initially a bit unhappy because https://github.com/openSUSE/doc.o.o/pull/1 necessitated the use of Jekyll and given all the break-prone Ruby stuff that brings with it, I wasn't sure what kind of maintenance effort that'd bring with it for that page. However, if this were on GH Pages, we'd get Jekyll server-side rebuilds for free and my objection would be moot. I have not looked in detail at pull/2 yet. I'd still rather like to have doc.o.o be built the same way we build doc.suse.com now, i.e. with Docserv2 build server building docs and navigation and then just rsyncing everything to $somewhere. That'd make the most sense from the SUSE Doc Team perspective, as it'd finally make rebuilding openSUSE docs painfree for us. There are a few caveats to this: 1. I need time to incorporate the web site design into a template. 2. We'd still need to put the release notes there in some other way, because Docserv2 does not build RPMs. 3. If we set this up on the current server, the process would be bound to SUSE a bit. Docserv2 has no permissions system for its HTTP API currently, so making this much more community-accessible would involve extra effort. Input? Stefan. -- SUSE Software Solutions Germany GmbH: Maxfeldstraße 5 / 90409 Nürnberg / Germany. HRB 36809, Amtsgericht Nürnberg. Geschäftsführer: Felix Imendörffer.