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
>> Do you know who is responsible for the main
You can just copy the existing content it is static
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.
Looking at the apache config brought up some interesting details and
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
- (any other cgi script hidden in a subdirectory?)
Are these scripts still used/needed?
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 ;-)
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
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:
# find -name '*_sd'
/documentation/html/ doesn't exist.
/book/ doesn't exist.
The alternative domains (rtfm.o.o, docs.o.o, activedoc.o.o and
get redirected to doc.o.o - doing that in haproxy
probably makes more sense.
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?
Note to myself: /home/relsync/release-notes-openSUSE (the scripts to
deploy the release notes) are already managed on
which makes things a bit easier.
The main pages for doc.o.o are created from
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
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 ;-)
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.
To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org
To contact the owner, e-mail: heroes+owner(a)opensuse.org