In issue2551027 (outgoing email does not work on sourceforge when
running own wiki) we've decided to move our wiki to a new moinmoin instance
hosted at Waldmann-EDV, a specialisted MoinMo.in hoster.

This issue is about implementing the decision technically.
Open tasks transfered:

[ ] Check for additional plugins (probably none)
[ ] Check that we and our theme works on MoinMoin 1.9 (hopefully)
[ ] Cleanout spam-pages
[ ] Cleanout or think about how to cleanout (spam) users
[ ] Give clean copy to waldmann-edv
[ ] Plan migration with everyone involve
[ ] Migrate
[ ] Announce migration
[ ] Enjoy better wiki! \o/


In addition I think we may start with a runnin beta version of the wiki
before switching.

Let us start setting up the new wiki in parallel, so
   wikibeta.roundup-tracker.org
so we need to point it to the same IP as wikiwikiweb.de (213.239.209.163)

== Access to old wiki
This runs on sourceforge.net, the access is documented in 
https://sourceforge.net/p/roundup/code/ci/7a570b1f0d675c1a1807c5d6041eb35d270daf6e/tree/website/README.txt

To download the data of the wiki, scp with an sf account with the
privileges for "roundup" as to be used.

A command like this does work,
check
https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/
to allow the connection
 scp -r
ber@web.sourceforge.net:/home/project-web/roundup/persistent/wiki/data .

(However the eventlog seems to be pretty big, we won't need it fully.
So maybe I'll be using "rsync" and exclude this file.)

The theme used by the wiki is in the roundup main repo at
https://sourceforge.net/p/roundup/code/ci/default/tree/website/wiki/

[ ] come up with a list of user account (email addresses)
[ ] come with the the list of people that shall be Wiki-admins
    to be able to create user accounts.

Note https://wikibeta.roundup-tracker.org/BetaWiki
is already running as early technical preview (that will be cleaned),
but with a TLS certificate for wikiwikiweb.de.

Bern, I noticed one of the items on your list was to come up with a list 
of accounts. Is there something special that needs to be done to export 
the current list of users to the new instance?

Hi John,
first sorry for the long break on this issue.
There was vacation time in Germany.

To answer your question:
Current spam protection for MoinMoin wikis recommends that we
allow editors screen by a person. Given it some thought I believe this is
fine (at least for the time being). Our list of accounts probably contains
a number of fake accounts which were only created for the purpose of
spamming, thus my suggestion is that we start with a fresh manual list
and transfer those accounts.

Technically we could transfer them all, but I think it will be
suboptimal for our purposes as outlined above.

Regards,
Bernhard

Hi Bern:

In message <1564996160.73.0.927879820611.issue2551045@roundup.psfhosted.org>,
Bernhard Reiter writes:
>first sorry for the long break on this issue.
>There was vacation time in Germany.

No problem.

>To answer your question:
>Current spam protection for MoinMoin wikis recommends that we
>allow editors screen by a person.

So the user user applies to get editor privs through MoinMoin and some
person/people can acknowledge the request and get them access?

Should we set up the notifications to go to the devel list? That's
where the project "admins" hang out.

>Given it some thought I believe this is
>fine (at least for the time being). Our list of accounts probably contains
>a number of fake accounts which were only created for the purpose of
>spamming, thus my suggestion is that we start with a fresh manual list
>and transfer those accounts.

That works for me. Is there a way to see the most recent editor on all
the wiki pages. That may be a good initial list of users to transfer.
As I assume the most recent editor would be the person who reverted
any spam, or the last non-spam editor.

Alternatively if we have last login time, delete all users
who have not logged in in the past two years?

>Technically we could transfer them all, but I think it will be
>suboptimal for our purposes as outlined above.

I agree. Even though I think I purged a bunch of spammers a few years
ago, there are probably more in the list.

Have a great week and thanks again for working on this.

BTW do you have the info you need to move DNS records for the host
(and get an SSL cert)?

Dear John,

thanks for your remarks! Just a few comments now,
details next time I work on it.

> So the user user applies to get editor privs through MoinMoin and some
> person/people can acknowledge the request and get them access?

Not sure, I'll have to find out. Probably people have to ask on
the devel list.

> Is there a way to see the most recent editor on all
> the wiki pages. That may be a good initial list of users to transfer.

Good idea.

> Alternatively if we have last login time, delete all users
> who have not logged in in the past two years?

Also a good idea.

> BTW do you have the info you need to move DNS records for the host
> (and get an SSL cert)?

DNS record: yes (as documented, it's still Richard handling this).
TLS cert is something that I believe Waldmann-EDV will handle once
we go further.

Regards

[resuming work]


== Securing old contents

Downloading the old wikis contents (using compression with option `-z`,
so the size of event-log is transferable).

rsync -avz
ber@web.sourceforge.net:/home/project-web/roundup/persistent/wiki
wiki-sf-copy-20190826


== No additional plugins

[x] No additional plugins, only the theme.
Check used:

pushd /home/project-web/roundup/persistent/wiki/data/plugin
find -type f -name "*.py" | grep --invert-match __init__
./theme/roundup.py


== Theme not directly compatibly

Unloaded and unpacked moin-1.9.10.tar.gz
Copied the
https://sourceforge.net/p/roundup/code/ci/default/tree/website/wiki/

cp wiki/data/plugin/theme/roundup.py  moin-1.9.10/wiki/data/plugin/theme/

cp -r static/roundup
to moin-1.9.10/MoinMoin/web/static/htdocs/

add the following line to moin-1.9.10/wikiconfig.py at the end of class
LocalConfig()
    theme_default = "roundup"

cd moin-1.9.10
./wikiserver.py

Result: the images are different but the navigation style is not changed.

-> next step, fix style

== Theme is compatible

[continouing from msg6592]

Completed the config, instead of changing wikiconfig.py better use

::::::::::::::
wikiconfig_local.py
::::::::::::::
from wikiconfig import LocalConfig

class Config(LocalConfig):
    sitename = u'Roundup Tracker Wiki'
    logo_string = u'Roundup Tracker'
    theme_default = "roundup"
::::::::::::::


Made sure the reference from 

vim moin-1.9.10/MoinMoin/web/static/htdocs/roundup/css/screen.css 
to roundup's overall style sheet works.

Therefore placed the style.css from 
https://sourceforge.net/p/roundup/code/ci/default/tree/website/www/_static/
into moin-1.9.10/MoinMoin/web/static/htdocs/

Changed the line in screen.css to
@import url(/moin_static1910/style.css);

(restarted).
The theme has the icons of an elder Moinmoin theme and the color
in the RecentPages page does not match. 
-> Put onto backlog: We need a better theme. Red is not a good link
color anyway. :)

== Theme ready
With rev5866:f6bd55b37e9f the style.css is taken from the
https://issues.roundup-tracker.org side. This is better for the migration,
but probably should be changed if the style is overhauled.

Gave the theme to Thomas from waldmann-edv.

Status report:

[x] Download of old wiki data (as backup and preparation for transfer)
[x] Check for additional plugins -> none
[x] Check that we and our theme works on MoinMoin 1.9 -> yes
[ ] Split grown event-log on old wiki, compress old years.
[ ] Cleanout spam-pages
[ ] come up with a list of user account (email addresses)
[ ] come with the the list of people that shall be Wiki-admins
    to be able to create user accounts.
[ ] Give clean copy to waldmann-edv
[ ] Plan migration with everyone involve
[ ] Migrate
[ ] Announce migration
[ ] Enjoy better wiki! \o/

Feedback from Waldmann-EDV:

The beta-site has the theme now:
https://wikibeta.roundup-tracker.org/BetaWiki

The theme does not show the "important note"-box above all
contents as modernized does. (Needs to be investigated.)

Hi Bern:

In message <1566999421.81.0.287436953659.issue2551045@roundup.psfhosted.org>,
Bernhard Reiter writes:
>Bernhard Reiter added the comment:
>
>Feedback from Waldmann-EDV:
>
>The beta-site has the theme now:
>https://wikibeta.roundup-tracker.org/BetaWiki
>
>The theme does not show the "important note"-box above all
>contents as modernized does. (Needs to be investigated.)

This looks good.

I noticed that the Download link in the left hand menu of the theme is
http://pypi.python.org/pypi/roundup not https://. Using the http link
causes a redirect, so the user ends up on https, but it would be nice
to correct the link to https.

We may need to update that in other roundup properties as well.

Have a great day and good job moving this forward.
--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

rev5875:828bbf219e56 fixes (but does not activate automatically)
http -> https in a few places.

Created issue2551054 on the way.

Splitting out the following items,
as they do not affect the main move:

* issue2551055 (cleanup old wiki)
* issue2551056 (Wiki: Fix roundup theme for new version of moinmoin)

== [x] Come up with a fresh list of users

In wiki/data of the old wiki we have
  grep email= user/* | wc -l
32 users

grep 'email=\|^name=' user/*

# using fishshell.com for shell programming here
pushd user ; set -l users (grep 'email=' * | cut -d: -f1) ; popd
for u in $users ; echo -n "$u " >> list ; grep $u edit-log | wc -l
>>list ; end
sort -n -k2 list

# too see the datetime for the logged nano-seconds
python3 -c 'import datetime;
print(datetime.datetime.fromtimestamp(1344940051000000//1e6))'

Applying the following filter, not to be scheduled for migration:
 * no edits done 8
 * only spam edits 2
 * only a few edits (<4 changes) and more than 5 years ago
 * edits more than 10 years ago

Rationale: if edits are a long way ago or not many, they chance is lower
  that those people will edit again. They may not even have their access
or email
  address anymore and this it is okay, if they need to register again. 
  It also does not make much sense to email them explicitely.
  So there is a cleaner list.

We end up with 12 user acccounts, here are the Wiki names for reference:
{{{
name=stefan
name=Peter Funk
name=BernhardReiter
name=DanielDiniz
name=RichardJones
name=andyfloe
name=NikolausRath
name=JohnRouillard
name=ChristofMeerwald
name=TonuMikk
name=TomEkberg
name=Magnus Schieder
}}}

Users send to Waldmann-EDV.

== User list
Adding my colleague (which saves me to add him later).
name=ThomasArendsenHein


== [ ] find pages to transfer
We have 2485 pages, but only 129 have a "current" page.

ls pages/* | wc -l
2485
bernhard@ploto ~/h/r/w/w/data> ls pages/*/current | wc -l
129

Sampling a few directory contents that have no "current" file:
There is no preservable contents. So we only deal with 129 pages.

#using fishshell.com for scripting
pushd data/pages; ls */current >pl
for p in (cut pl -d/ -f1) ; echo -n "$p " ; cat $p/current ; end

== [ ] select pages to transfer

=== Do not transfer personal "homepages"

We won't transfer homepage, because

there is not much activity in those
pages. And the pages we have are all outdated with one exception.
This it is better to not have them. Most people with homepages 
do not have wiki accounts (anymore).
Ralf is an exception in that he is active in roundup and the page still
is relevant (but he has edited the wiki for a while and he has no account.
And no pages link to his homepage.)
(We may add some information about RichardJones in a history section,
which could be of historical interest.)

If we have plan to re-introduce homepages again, I'd say they should
be only for active people really active over a long period in the wiki
for roundup. The problem with homepages is that they cannot be collectively
maintainted, as they belong to single person.

Thos are all homepages we have in the old wiki:

  GeorgLehner
  RichardJones
  JohannesGijsbers
  MichaelTwomey
  MyersCarpenter
  RalfSchlatterbeck

== [ ] select pages to transfer
Found three pages that are unnecessary
   TDCOma
   ClassHelp
   ElementTree

And I've cleaned the following pages to start with the current
(non-spammed) edition:
  Proposal
  MultipleIncomingAddresses
  IndexBackLink

So we are down to 121 pages in 13MBytes.
There are still revisions in the history with spam, example:
  CustomisationExamples/revisions/00000004

In message <1567080208.97.0.571665358841.issue2551045@roundup.psfhosted.org>,
Bernhard Reiter writes:
>Bernhard Reiter added the comment:
>
>== [ ] select pages to transfer
>
>=== Do not transfer personal "homepages"
>
>We won't transfer homepage, because
>
>there is not much activity in those
>pages. And the pages we have are all outdated with one exception.
>Ralf is an exception in that he is active in roundup and the page still
>is relevant (but he has edited the wiki for a while and he has no account.
>And no pages link to his homepage.)
>(We may add some information about RichardJones in a history section,
>which could be of historical interest.)

Is there any info there that could be useful? If so maybe an
ArchiveHomePages page with each user as a section and useful info in
the area below? Could also Put Richards page there.

>If we have plan to re-introduce homepages again,

I would claim that we don't need homepages. I think Ralf's data might
be better on a RoundupConsultants page or something like that.

GeorgLehner's links might be better on RoundupInTheField or something
like that.

=== Do not transfer personal "homepages"

> Is there any info there that could be useful? 

In my assessment: no.
(usefulness is low compared to the efforts to keep them,
archive.org and search engines have more about the people if needed).

> I would claim that we don't need homepages. I think Ralf's data might
> be better on a RoundupConsultants page or something like that.

Same here.
(Though it we start a consultants page, we need to make sure that it is
kept current.)

Status report:

[x] Download of old wiki data (as backup and preparation for transfer)
[x] Check for additional plugins -> none
[x] Check that we and our theme works on MoinMoin 1.9 -> yes
[issue2551055] Split grown event-log on old wiki, compress old years.
[x] Cleanout spam-pages
[x] come up with a list of user account (email addresses)
[x] come with the the list of people that shall be Wiki-admins
    to be able to create user accounts.
[x] Give clean copy to waldmann-edv
[ ] Plan migration with everyone involve
[ ] Migrate
[ ] Announce migration
[ ] Enjoy better wiki! \o/

== For the stack (not in this issue): Cleanup contents
Development proposals and patches adding functionality that were
added to current roundup versions should be removed from the wiki.
And still working ones tagged with the version they work.


== [x] list of admins
We keep the current list which is
  superuser = [u"JohnRouillard", u"BernhardReiter", u'RichardJones']

== [x] Give clean copy to waldmann-edv
Gave cleanup pages/ users/ and the old wikiconfig.py to Waldmann-EDV
(with encrypted email).

== [x] select pages to transfer

We have 113 pages now. In addition to msg6608 and not transfering
homepages, I've cut out a number of spam revisions,
by deleting the files in `revisions/` and the entries in `edit-log`.
Sometimes the number in `current` had to be adjusted as well.

Some less relevant history of pages is lost deliberately.
This is partly because of spam and cleaned up users lists.


=== additional pages left out
No Useful contents, not linked
  TestingFireFox
  TestingFireFoxOneFive
  TestingFireFoxPrOneZero

Removing because I'm not sure we need it and it also is advertisment for bad
sites.
   BadContent
   LocalBadContent

No useful contents
    WikiWikiWeb
    SandBox

Butchered:
   TranslationStatus
   FrontPage
   CustomisationExamples
   RoundupPostgres
   UserMenu
   MessagesAsMbox
   GSoC09
   CreationPermissions
   FeedingRoundup
   RoundupAsWiki
   [and some more]

==== fishshell.com commands helping with the reviewing
As it is possible to edit `edit-log` files or even create a fresh directory,
here are some commands:

set -l newpage Proposal
mkdir -p $newpage/revisions
echo 00000001 > $newpage/current
set -l userid 12345678.54.42698
echo
1567148789673270\t00000001\tSAVE\t$newpage\t127.0.0.1\t127.0.0.1\t$userid\t\tMigrated\
from\ old\ wiki >>$newpage/edit-log

for p in (cat ../listofpages) ; more $p/edit-log $p/revisions/* ; or
break ; end

In message <1567147772.28.0.569942771521.issue2551045@roundup.psfhosted.org>,
Bernhard Reiter writes:
>> I would claim that we don't need homepages. I think Ralf's data might
>> be better on a RoundupConsultants page or something like that.
>
>Same here.
>(Though it we start a consultants page, we need to make sure that it is
>kept current.)

Maybe have the consultant entries put a "time added/updated" next to
their entry. Then add text saying some entries maybe stale and clear
anthing un-updated after 3 or so year.

Hi Bern:

In message <1567160338.45.0.15696693287.issue2551045@roundup.psfhosted.org>,
Bernhard Reiter writes:
>== For the stack (not in this issue): Cleanup contents
>Development proposals and patches adding functionality that were
>added to current roundup versions should be removed from the wiki.

Is there value into holding on to this? The proposal pages may
include additional background that is missing from any other location.

>And still working ones tagged with the version they work.

I agree with this, and I think the same can be done with other
proposal pages. If there are too many to tag with version info (who
cares if it was added 30 versions ago), maybe just add a note "this
functionality is in core roundup".

>== [x] list of admins
>We keep the current list which is
>  superuser = [u"JohnRouillard", u"BernhardReiter", u'RichardJones']

Do we want to ask Ralf if he want's access?

>== [x] select pages to transfer
>
>We have 113 pages now. In addition to msg6608 and not transfering
>homepages, I've cut out a number of spam revisions,
>by deleting the files in `revisions/` and the entries in `edit-log`.
>Sometimes the number in `current` had to be adjusted as well.

This brings up a question. I know we had some bit rot/corruption. At
one point I had to go through the page revisions and add some current
files because the pages were missing, but were linked to.

I think there is a Missing Pages or Pages Needed in moin moin, so
before we toss the bogus tree, maybe check that none of the missing pages
are present just not properly linked.

>Some less relevant history of pages is lost deliberately.

+1

>Removing because I'm not sure we need it and it also is advertisment for bad
>sites.
>   BadContent
>   LocalBadContent

Aren't these suppose to prevent committing of pages with spam links in
them? I assume we will get a new copy of BadContent, maybe we only need
to move LocalBadContent?

>Butchered:
>   TranslationStatus
>   FrontPage
>   CustomisationExamples
>   RoundupPostgres
>   UserMenu
>   MessagesAsMbox
>   GSoC09
>   CreationPermissions
>   FeedingRoundup
>   RoundupAsWiki
>   [and some more]

By butchered do you mean removing less relevelent history/spam? Or do
you mean the content has been managled?

* John Rouillard <issues@roundup-tracker.org> [20190831 14:52]:
> Bernhard Reiter writes:
> >(Though it we start a consultants page, we need to make sure that it is
> >kept current.)
> 
> Maybe have the consultant entries put a "time added/updated" next to
> their entry. Then add text saying some entries maybe stale and clear
> anthing un-updated after 3 or so year.

3 years sounds quite short for updates. Why should contact
information be changed if they are still the same?

Do we have a short term for "I'm on this list and this is the last
time I verified/confirmed that I still want to be on this list"?

== Consultant pages

As this question is not coupled with the wiki migration,
let us discuss this elsewhere.

== For the stack (not in this issue): Cleanup contents

Same here: We should discuss this elsewhere.
I've just noticed it, that we could need a content cleanup.
However we should keep the history of those pages, so we can do it
after the migration.

== Misc Questions (by John)

| Do we want to ask Ralf if he want's access?

Yes. I'll send him an email and I'll also ask Richard.

| I assume we will get a new copy of BadContent,
| maybe we only need to move LocalBadContent?

It is also my guess that we'll get a new BadContent, however I don't
think this is effective and our LocalBadContent wasn't really very
impressing. I'll ask our hoster about it, ideally they do the worst spam
fighting. Still the major defense now is that edit right are only
for contributors and handed out by the superusers.

| By butchered do you mean removing less relevelent history/spam?
| Or do you mean the content has been managled?

Yes, I've cut less relevant history/spam revisions. 
To get this done at all in a few hours, I was working fast, the history
revision list may have holes and I may have made mistakes. However I
think it is better to have the spam removed. I did not intentionally
mangle content.

== [x] list of admins, updated

After asking Ralf and Richard, this is the updated list which went
to waldmann-edv:

  superuser = [u"JohnRouillard", u"BernhardReiter"]

https://wikibeta.roundup-tracker.org/ has the contents now.

Recent changes have not been transfered. (I'll look into it.)
And there are other things to clarify, so it is not yet ready
for beta testing.

For the transfer of history I'm keep the last 114 entries
until 2013-12-12 before the bigger spam flood.
And I've removed the single homepage change because homepages
were not transfered.

TLS: would come once we point DNS to the right domain, currently 
the TLS is for wikiwikiweb.de
(the fingerprint I'm getting are SHA-256 Fingerprint	10 39 D4 2C 67 92
C0 49 72 DE 2A 7B CE 4A 49 B7
61 43 4A A1 34 6B FA 5D 90 95 45 93 B5 BD BE E1
SHA-1 Fingerprint	35 1C 25 15 C2 2B 37 3E 29 4E 0F 2A C9 E6 C3 4A
D3 48 A3 6F)

Idea for migration:
* Beta starting this week (maybe today or tomorrow)
* Migration next week.

It looks like some pages were written in restructured text.

  http://www.roundup-tracker.org/cgi-bin/moin.cgi/CloneAnIssue

is formatted correctly while:

  https://wikibeta.roundup-tracker.org/CloneAnIssue

says:

  Rendering of reStructured text is not possible, please install Docutils.

The page shows the raw input. I am not sure if reST can be supported by the new vendor. If not, we probably need to figure out how to identify the pages and manually convert them after the import. Alternatively  convert them with a program as part of the import.

-- rouilj

@rouilj
Good point about reSt, I've send an email to Waldmann-EDV.

Also send an email to roundup-users to announce our move
and the current state and a question about the default markup.

== Default markup language?

Note that our software can do Creole markup (by default),
many instances of moinmoin we have at Intevation use this as default format 
now, because it is simple and can be used elsewhere,
like roundup. :) See https://wikibeta.roundup-tracker.org/Markup

Would anybody mind a switch to creole as default?
(For a page this can be changed by the #format directive, so no page
must be 
migrated.)

Recent-changes are in, rst is activated.

Only question:
What default markup language for new pages.
(Can be adjusted)

[ ] keep it as it is (Moinmoin)
[ ] creole (suggestion by Bernhard)
[ ] rSt (suggestion by Ralf)

One problem is that if we change the default, we would need to mark
the current pages to be moinmoin Markup.

@John, as the primary wiki author in recent month, which markup option
would you prefer?

Hi Bern:

In message <1568115693.28.0.562995752665.issue2551045@roundup.psfhosted.org>,
Bernhard Reiter writes:
>Only question:
>What default markup language for new pages.
>(Can be adjusted)
>
>[ ] keep it as it is (Moinmoin)
>[ ] creole (suggestion by Bernhard)
>[ ] rSt (suggestion by Ralf)
>
>One problem is that if we change the default, we would need to mark
>the current pages to be moinmoin Markup.
>
>@John, as the primary wiki author in recent month, which markup option
>would you prefer?

I would say keep it as is moinmoin. This eliminates having to mark the
current moin moin pages. Also I think given it's a moin moin install,
it's what people would expect.

We do
[x] keep it as it is (Moinmoin)
because this way we do not need to add something to existing pages
and it is John's preferance (as the most active wiki contributor).

So we are ready for migration, I'll ask Thomas Waldmann from waldmann-edv
if and when they are ready.

Question what happens to links like:

  http://www.roundup-tracker.org/cgi-bin/moin.cgi/UserMenu

Ideas on how to redirect that to the wiki so we don't make all
these links in tickets etc. obsolete?

Maybe we replace moin.cgi with a (shell) script that does a
redirect to https://wiki.roundup-tracker.org/UserMenu?

* John Rouillard <issues@roundup-tracker.org> [20190913 02:21]:
> Question what happens to links like:
> 
>   http://www.roundup-tracker.org/cgi-bin/moin.cgi/UserMenu
> 
> Ideas on how to redirect that to the wiki so we don't make all
> these links in tickets etc. obsolete?
> 
> Maybe we replace moin.cgi with a (shell) script that does a
> redirect to https://wiki.roundup-tracker.org/UserMenu?

I doubt that the new server has cgi-bin enabled, but a regular
redirect should be possible.

> Maybe we replace moin.cgi with a script that does a redirect

Yes, should be possible, good idea.
Also we can replace links where we can.

Searching for `http://www.roundup-tracker.org/cgi-bin/moin.cgi`
in the tracker shows that we have 20 issues affected, we could just add
an additional message there.

There is just https://wikibeta.roundup-tracker.org/MessagesAsMbox
where it appears as string in the wiki pages.

Given that we only have those places I think we should not
take the time to do and maintain a script for the sourceforge server.
People will use a search engine and find the new wiki if they really
need that elder information.

Richard and Thomas (Waldmann) have moved our wiki over the weekend.
The TLS certificate is a remaining problem, which are are still solving.

I've also rectified the user names of two users and
send an email to our users list.

== Details DNS problem
To be able to use letsencrypt, we either need to move the DNS hosting
for waldman-edv or they have to change their infrastructure to use a
different letsencrypt protocol (http now it is dynamic DNS updates).

Questions to Richard and Waldmann-EDV about preferances and possibile
costs are pending. Intevation is willing to sponsor.

== letencrypt client setup problem

So there are three possibilities:
a) we add a few DNS server entries so that waldman-edv
   is the primary 
b) we transfer technical ownership of the Domain to waldman-edv
   and they handle it. (But keep Admin-C and Owner-C for Richard.)

Richard would be okay with changing the DNS maintenance.
Either a) or b) would be a one-time setup fee of 90€.
(Which Intevation would sponsor.)

c) Waldmann-edv changes their infrastructure to support letsencrypt via
http protocol (~4h of work, no additional use case).

I'll chat with @ThomasAH about which of a) or b) makes more sense.

At the moment the certificate for https://wiki.roundup-tracker.org/ 
does not match the domain (Error SSL_ERROR_BAD_CERT_DOMAIN).
The used letsencrypt certificate is issued for the domain (CN)
wikiwikiweb.de instead of wiki.roundup-tracker.org.

Best regards, Peter Funk

@pefu:
Yes, the TLS certificate is a known remaining problem.
(See msg6639. I've also tried to inform users with my email.)

Thanks for your note, it is good to know that people care for the wiki!
Best Regards, Bernhard

Bernhard Reiter added the comment:
> @pefu:
> Yes, the TLS certificate is a known remaining problem.
> (See msg6639. I've also tried to inform users with my email.)

Sorry. I should have read the other comments more carefully 
before posting.

> Thanks for your note, it is good to know that people care for the wiki!

BTW: I found the following article about using 
wildcard certificates with letsencrypt a helpful read:
http://strugglers.net/~andy/blog/2018/03/19/lets-encrypt-wildcard-certificates-acme-sh-and-automated-dns-verification/
I understand however that this article does not apply to the 
situation here of the roundup moinmoin wiki service.

Liebe Grüße, Peter Funk

Hi Bern,

I was just updating docs over the weekend and came across the website/README doc that has directions on updating the wiki.

Can that section be removed? I assume we don't have shell access
so most of it is useless. However having a process if we
have to update the theme, css, images etc. would be good.
Also I assume we have no option to change the configuation.

-- rouilj

Hi John,

| website/README doc that has directions on updating the wiki.

yes, good point, it was to be updated, once the move is completely done.

== updating
You are correct in that we do not have direct access anymore,
but you and me can contact our provider for changes in configuration
and theme. I haven't clarified this yet, but I assume there is room
for changes occasionally, which are regular. 
Otherwise we can contract more hours.



Note, I'had already created:
* issue2551055 (cleanup old wiki)
* issue2551056 (Wiki: Fix roundup theme for new version of moinmoin)

Bern, I know the TLS certificate issue still has to be resolved,
but is the new wiki open and ready to use otherwise?

Yes, the wiki is open and ready except TLS,
where the ball is in Richard's field currently
to move the DNS serving to Waldmann-EDV.
Afterwards we want point the remaining users to reset their passwords.
(Because they were transfered unencrypted.)

You could open a new issue for those remaining points
and close this one, if you like.

Thanks to Richard and Thomas (Waldmann), the DNS is now
switches over and we have a TLS certificate!

Thanks!