#165 closed task (fixed)
Wiki LDAP integration
Reported by: | crschmidt | Owned by: | robe |
---|---|---|---|
Priority: | major | Milestone: | Sysadmin Contract 2021-I |
Component: | SysAdmin/Wiki | Keywords: | ldap, wiki |
Cc: | martin, Jeff McKenna, strk, Cwillmes, sac@…, jive, hexmode |
Description
MediaWiki has an extension to support LDAP integration. It is described in the http://www.mediawiki.org/wiki/Extension:LDAP_Authentication Mediawiki LDAP auth page .
The requirements to install are as follows:
- MediaWiki 1.6+ for current version of the plugin (I will no longer be backporting to the 1.5 series)
- PHP must be compiled with LDAP support for any functionality at all
- PHP must be compiled with SSL support if you wish to authenticate over SSL (HIGHLY Recommended!!)
- Your server must trust the LDAP server's Certificate's Root CA for SSL to work (mostly affects you if you are using self signed certificates)
- The DNS name for your LDAP server must match the name in the LDAP server's certificate for SSL to work
- Smartcard/CAC authentication requires a PEM encoded list of CAs, proxy or anonymous (if allowed) LDAP credentials, and an SSL enabled webserver
There are more details at the page on how to proceed with this.
Change History (100)
comment:1 by , 17 years ago
Component: | General → SAC |
---|---|
Owner: | changed from | to
comment:2 by , 17 years ago
follow-up: 7 comment:3 by , 17 years ago
While we are at it, I'd like to make our Wiki a bit nicer by eliminating the "index.php" string in the URL's. These are the rules that I prefer to apply:
http://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_Apache_rewrite--root_access
Martin.
follow-up: 6 comment:4 by , 17 years ago
Martin,
I'm supportive of this idea, as long as the old urls continue to work too, since they are published all over the place.
comment:6 by , 17 years ago
Replying to warmerdam:
Martin,
I'm supportive of this idea, as long as the old urls continue to work too, since they are published all over the place.
That could be done with a
RedirectMatch permanent /index.php(.*)$ http://wiki.osgeo.org\1
This will result in all old links resulting in a HTTP response code of 301 (which the browser automatically redirects). Hopefully search engines will take note of this too.
comment:7 by , 17 years ago
Replying to martin:
While we are at it, I'd like to make our Wiki a bit nicer by eliminating the "index.php" string in the URL's.
Changes in /var/www/wiki/LocalSettings.php
Replace:
$wgArticlePath = "$wgScript/$1";
with:
$wgArticlePath = "/wiki/$1";
Changes in /etc/httpd/conf.d/hosts/wiki.conf
Add to each <VirtualHost [...]>
RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule /wiki/(.*)$ /index.php?title=$1 [PT,L,QSA] RedirectMatch permanent ^/index.php/(.*)$ /wiki/$1
Martin.
comment:8 by , 17 years ago
RewriteRule /wiki/(.*)$ /index.php?title=$1 [PT,L,QSA]
Just curious why you rewrote to the "/wiki/" prefix - was there a particular quirk you were avoiding? I'd love to wiki.osgeo.org/Main_Page, avoiding "/wiki/" altogether. But I don't understand the technical implications.
comment:9 by , 17 years ago
Owner: | changed from | to
---|
comment:11 by , 17 years ago
Cc: | added |
---|
comment:12 by , 17 years ago
Cc: | added |
---|
comment:13 by , 9 years ago
Keywords: | ldap wiki added |
---|
comment:14 by , 9 years ago
Component: | Systems Admin → Wiki |
---|
comment:15 by , 8 years ago
The updated link to LDAP authentication extension for MediaWiki: https://www.mediawiki.org/wiki/Extension:LDAP_Authentication
comment:16 by , 8 years ago
Cc: | added; removed |
---|
comment:17 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
Taking, the solution we want for the new site should also solve this, so we might as well get both...
comment:18 by , 7 years ago
Status: | new → assigned |
---|
comment:19 by , 7 years ago
This functionality may help to merge local and LDAP accounts: https://wiki.osgeo.org/wiki/Special:UserMerge
Astrodog: any news about your plan to fix this ?
comment:20 by , 7 years ago
Cc: | added |
---|
IMHO this should become a paid job. This report is open for 10 years...
comment:21 by , 7 years ago
+1 on paying for this.
How about sending an official motion to the list to make a call for offers to deal with it ?
comment:22 by , 7 years ago
Cc: | added |
---|
For reference: Board just realized this problem (#2139) Sounds about time to gather offers to do the work... I suggest we contact the authors of Wikimedia LDAP plugin(s) and ask for a quote to do whatever is missing to complete the migration, if nobody else from SAC want to to place a bid.
comment:23 by , 7 years ago
My own plan for merging Wiki- and LDAP-logins (a couple of years ago) envisioned a custom extension to the Wiki login page as the first step, asking Wiki users to enter their LDAP username after a successful Wiki login.
The second step included a page to ask LDAP users to enter their Wiki username after successful LDAP login.
Or something along these lines, which would allow to match Wiki and LDAP logins against each other without manual intervetion.
This never happened because nobody was available and skilled at the same time to modify the Wiki login page accordingly. Thus, even though this would have allowed almost fool-proof matching, I have to admit it has failed.
The UserMerge Wiki extension in contrast, while allowing to merge user logins, requires not only manual action in the process of merging user logins but also manual verification of the respective identities.
Adding LDAP and UserMerge to the Wiki is pretty simple from a *technical* point of view. Therefore the question boils down to: Which method is preferred from an *organizational* point of view ?
comment:24 by , 7 years ago
Following on to board f2f meeting "volunteer-confusion-over-user-ids" topic which reopened this issue:
The board discussion indicated it would be acceptable to just go to LDAP, with full understanding that a portion of the wiki users would not have access after the transition (until they established an OSGeo userid).
Is there an advantage to mapping LDAP username to Wiki username that I am not seeing?
comment:25 by , 7 years ago
Advantage of mapping would be, I guess, not leaving thousand of unaccessible accounts, orphaned content and identity split
comment:26 by , 7 years ago
As far as I can see, there are two issues in "just go to LDAP" - please, whoever knows better, correct me, if I'm wrong:
1.) The vast majority of Wiki edits will refer to an author not available in the LDAP user database after the switch, simply because most of them don't match.
2.) There are more than 5k users in the Wiki user database, more than 20k users in OSGeo LDAP and more than 1k overlapping user names between both, which will lead to conflicting user names in the Wiki after the switch.
While 1.) will just disturb Wiki editors, because they don't "own" their edits any more, 2.) will likely ask for a solution because it'll add confusion in itself.
comment:27 by , 7 years ago
Would UserMerge (URL?) allow fixing both points in the long run, beside the envisioned manual effort ? Does it necessarely need to be manual, btw ? Can we help it programmatically with some email based matching ?
comment:28 by , 7 years ago
As far as I can tell, UserMerge works by - manually - entering two existing user names, one being just a source and another being the common destination.
Maybe we can add automated matching and scripting to the process but apparently we're short of expertise on automating MediaWiki, therefore I don't know who's capable of adding the missing bits.
I also have little confidence in the quality of EMail addresses in the Wiki database, because a long-term policy had been "we don't want any obstacles in the process of registering with OSGeo". Therefore I would expect a lot of garbage and false EMail addresses on the Wiki as well as in LDAP.
That's why I proposed to ask authenticated LDAP users to provide their Wiki account name and vice versa in order to ensure, the matches are valid (at least most of them).
Moreover, I have no idea what's going to happen when we use UserMerge for merging Wiki user "joe" into LDAP user "karl" while "joe" is a valid user name in LDAP as well. This probably means we need to resolve conflicting user names beforehand (see above).
Disclaimer: Especially now, after realizing I was unable to carry out my own plan, I do *not* intend to hold OSGeo back from switching the Wiki over to LDAP authentication. I just want to add my thoughts to this discussion, hoping they'll help in making an educated decision.
Maybe someone will even prove me to be totally wrong.
comment:29 by , 7 years ago
Please also read the mailing list thread starting about here:
http://lists.osgeo.org/pipermail/sac/2017-September/008440.html
comment:30 by , 7 years ago
Regarding handling merge of existing wiki users and osgeo account users:
- Existing users with accounts on the wiki should be the only ones inconvenienced in the migration.
- No loss of authorship information should occur.
- No namespace conflicts should occur between old wiki accounts and new LDAP accounts.
- All future logins should go through the OSGeo LDAP authentication service.
- Users should provide their wiki account credentials to migrate their existing wiki account after authenticating to their OSGeo LDAP account.
- Non-migrated usernames in database may be modified to prevent collision with newly migrated users if necessary.
comment:31 by , 7 years ago
Proposed migration plans following #OSGeo-sac meeting 2018-03-29
Martin noted that the current MediaWiki instance is somewhat out of date, therefore I propose the following migration to both a newer mediawiki version and ldap authenticated accounts:
- Setup clean new MediaWiki instance, including all necessary extensions.
- Export database from current instance and import to new instance.
- Rename all existing user accounts with prefix, such as "_wikiuser_".
- Disable login to any account having the prefix.
- Force all logins through OSGeo LDAP authentication.
- On first login of a LDAP user to the wiki, prompt user to provide credentials for any existing wiki accounts they wish to merge; prepend prefix to authenticate and merge if valid.
We will want to do this on a testing basis first to work out any issues, then freeze the existing instance before importing clean with a fresh dump and swapping in the new instance.
comment:32 by , 4 years ago
Work in progress: https://git.osgeo.org/gitea/hexmode/WikiToLDAP
Santa Claus has been busy for these 13 years but he may have finally getting to us
comment:33 by , 4 years ago
The work is ready for test. Please go to https://dev.wiki.osgeo.org/w/ and try logging in. Both LDAP and WIKI credentials should be accepted, unless you have the same username on WIKI and LDAP, in which case only WIKI credentials will be accepted for first login (you'll be able to then login via LDAP after the merge operation). How's your experience ? Smooth enough ? Anything you'd change ?
comment:34 by , 4 years ago
I just tried and
https://dev.wiki.osgeo.org/wiki/Special:PluggableAuthLogin
504 Gateway Time-out nginx/1.14.0 (Ubuntu)
(maybe the version should be suppressed to reduce the attack surface for script kiddies)
comment:35 by , 4 years ago
Please try again now. It was a problem with the LDAP connection. File another ticket for omitting the nginx version information (this is probably common for all of our proxies, but it has to be confirmed).
comment:36 by , 4 years ago
I'm sorry to report, the credentials I used to update this ticket don't work for me on the Dev Wiki:
Incorrect username or password entered. Please try again.
...., btw, I'm pretty much excited about this move in general!
comment:37 by , 4 years ago
When LDAP credentials don't work it is beacuse your WIKI username is the same as the LDAP username. This is a known issue described here: https://git.osgeo.org/gitea/hexmode/WikiToLDAP/issues/3
I'm afraid the ball was dropped on this, and the only improvement we're left with would be changing the error message to suggest logging-in via the WIKI credentials. I don't like this either, but the external consultant (Mark aka hexmode) says it's too much work to allow direct LDAP access in this case.
The good new is that you should still be able to access via the WIKI credentials and you should be guided into the migration process, after which you should be able to login via LDAP (and no more via WIKI).
comment:38 by , 4 years ago
Hi Sandro, my Wiki username is different from the LDAP username (Mspott/martin).
Edit: Ok, after reading https://git.osgeo.org/gitea/hexmode/WikiToLDAP/issues/3, if I get it right, I understand there will be no resolution for any LDAP user names already being occupied on the Wiki. Correct?
comment:39 by , 4 years ago
Cc: | added |
---|
Martin: I'm not sure "no solution" is correct. We should ask Mark (hexmode, now in Cc). I think you can still login with your WIKI credentials and associate your wiki user with the LDAP account, can you please try that ?
Do you who is Martin, btw ? https://dev.wiki.osgeo.org/wiki/Special:Contributions/Martin Last contribution in 2007
comment:40 by , 4 years ago
Looks like Wiki user "Martin" was an OSGeo Journal editor .... I myself joined by end of 2006, so there must have been an overlap, but this definitely wasn't myself.
Maybe Martin Wegmann, now known as Wiki user "Wegmann"? Their edit histories match pretty well.
Nevertheless, I suspect that I'm not the only user being affected by such a naming collision. There are thousands of nicknames in LDAP and Wiki and while a solution for myself would be nice (of course :-) , others might complain as well.
Ah, and, for some - unknown - reason I lost my Wiki password. While I was able to trigger a PasswordReset on the production Wiki, this is disabled on the Dev.
follow-up: 42 comment:41 by , 4 years ago
Do you think renaming all wiki accounts with having a prefix would fix these cases ? Sounds like a good plan to me (assuming we can verify no LDAP user has such prefix AND we can prevent using it in the future)
follow-up: 44 comment:42 by , 4 years ago
Replying to martin:
Looks like Wiki user "Martin" was an OSGeo Journal editor .... I myself joined by end of 2006, so there must have been an overlap, but this definitely wasn't myself.
Maybe Martin Wegmann, now known as Wiki user "Wegmann"? Their edit histories match pretty well.
Someone should reach out to "Wegmann" and find out if it is the same user and offer to use Special:UserMerge to merge their users.
Replying to strk:
Do you think renaming all wiki accounts with having a prefix would fix these cases ? Sounds like a good plan to me (assuming we can verify no LDAP user has such prefix AND we can prevent using it in the future)
Changing all wiki usernames could be done with a slightly altered form of the UserRename extension's "renameUser.php" script: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Renameuser/+/refs/heads/master/maintenance/renameUser.php
I'm willing to do that this weekend if you want.
comment:43 by , 4 years ago
+1 for wiki users rename (_wikiuser_
prefix as per TemporSent plan). What do others think ?
comment:44 by , 4 years ago
Replying to hexmode:
Replying to martin:
Looks like Wiki user "Martin" was an OSGeo Journal editor .... I myself joined by end of 2006, so there must have been an overlap, but this definitely wasn't myself.
Maybe Martin Wegmann, now known as Wiki user "Wegmann"? Their edit histories match pretty well.Someone should reach out to "Wegmann" and find out if it is the same user and offer to use Special:UserMerge to merge their users.
I have just contacted Martin Wegmann asking him to support us here.
comment:46 by , 4 years ago
I think we've finally gotten this to where we're ready to push it to prod. Please log into https://dev.wiki.osgeo.org/ and with either or both of your Wiki and LDAP credentials and see if you understand how to merge one account with the other.
comment:47 by , 4 years ago
Initial login with Wiki, and converting to LDAP works. Minor, we should add a link to sign up for LDAP if needed, in the statement. Now the confusing part is what happened after, upon trying to login again the username was filled in 'Wiki-', which didn't work. Changing it to my LDAP username works but then I get a prompt to 'Merge old wiki accounts with LDAP accounts' which isn't well explained and doesn't work.
comment:48 by , 4 years ago
Minor, we should add a link to sign up for LDAP if needed, in the statement.
Which statement? I assume you mean this one: https://dev.wiki.osgeo.org/wiki/MediaWiki:Wikitoldap-introduction
Those messages should be edited on-wiki to adjust them to point to id.osgeo.org.
Now the confusing part is what happened after, upon trying to login again the username was filled in 'Wiki-', which didn't work. Changing it to my LDAP username works but then I get a prompt to 'Merge old wiki accounts with LDAP accounts' which isn't well explained and doesn't work.
Could you clarify "didn't work"? strk and others have tested this multiple times before we got to the point of posting about it here, so I know that, in some sense, it works.
What did you do? What did not work?
follow-up: 50 comment:49 by , 4 years ago
I think he refers to this:
the username was filled in 'Wiki-', which didn't work.
He means the browser input field is pre-filled with 'Wiki-$Username' on next login. I've had the same experience, and is indeed annoying.
The "didn't work" refers to using the 'Wiki-' prefixed username with which the form is pre-filled. I've no idea where that pre-fill comes from (a cookie?) or if the extension can do anything about it.
Regarding the second prompt I also think I saw it once, but then disappeared on next login, so not sure when the merge prompt should or should stop popping up (still a cookie?).
comment:50 by , 4 years ago
Replying to strk:
He means the browser input field is pre-filled with 'Wiki-$Username' on next login. I've had the same experience, and is indeed annoying.
Agreed. And that login won't work after the merge because, after the merge, that account doesn't exist.
I'm not sure what to do about it -- maybe we could destroy that cookie after a merge? Or, better, replace it with a the name of the account that it is merged to.
Regarding the second prompt I also think I saw it once, but then disappeared on next login, so not sure when the merge prompt should or should stop popping up (still a cookie?).
I don't think I've seen that, but maybe I wasn't paying attention.
It would be good if wildintellect could confirm or clarify some more here.
comment:51 by , 4 years ago
Yes that's what happened, expiring the cookie might make sense. On re-login I discovered if I choose the "skip this step" button, then it doesn't ask again. But I'm not sure why it asked in the first place, and I think it's potentially confusing for users. Does the skip set a flag to not ask again in the db somewhere?
comment:52 by , 4 years ago
I've updated the extension so that you won't see the "wiki-" prefix when you try to login now.
Skipping does make sure that you aren't in the group that sees the transition any more.
comment:53 by , 4 years ago
I think the WIKI users should *always* see the merge request. It's just LDAP users that we want able to say "don't ask me anymore" becuase maybe they NEVER had a WIKI account.
Those with a WIKI account we want to DROP as soon as possible, so we should keep bothering them with the message.
comment:54 by , 4 years ago
Moreover: the message bugging WIKI users for merging them with a LDAP account should be configurable because at one point we want to give them a timeframe within they need to merge before the accunt is REMOVED.
follow-ups: 57 59 comment:55 by , 4 years ago
Hi all, I looked into this again and now I successfully merged my old Wiki name "Mspott" into the LDAP account "martin" on the "dev.wiki". The edit history in the pages I worked on was migrated properly.
Anyhow I noticed that the"Special:Contributions/Martin" page was empty after the merge.
Moreover I'd suggest to add a notice to remind users to move their former User page .... and not to make the same mistake I made by moving it into the "(Main)" section of the Wiki but instead directly into the "User" section ;-)
Great progress!!!
follow-up: 60 comment:56 by , 4 years ago
Martin: we payed the consultant (I think) so from now on is all on our shoulders. Can you see if there's a way to have the notice you mention written in some template already ? We also now need to plan for deploy this new plugin to production (and I didn't touch wiki on the ansible side, so if you did you're welcome to suggest or even send a pull request for our playbooks)
follow-up: 58 comment:57 by , 4 years ago
Replying to martin:
Anyhow I noticed that the"Special:Contributions/Martin" page was empty after the merge.
Interesting, I thought that was handled.
Moreover I'd suggest to add a notice to remind users to move their former User page .... and not to make the same mistake I made by moving it into the "(Main)" section of the Wiki but instead directly into the "User" section ;-)
The pages should have been moved automatically.
comment:58 by , 4 years ago
Replying to hexmode:
The pages should have been moved automatically.
I just realized why the page move, at least wasn't done. The old user accounts have been renamed, but I don't think I attempt to move from the renamed user accounts. I have to check that.
comment:59 by , 4 years ago
Replying to martin:
Moreover I'd suggest to add a notice to remind users to move their former User page
You can see the messages displayed and find the proper MediaWiki: page to modify by seeing the messages here: https://git.osgeo.org/gitea/hexmode/WikiToLDAP/src/branch/master/i18n/en.json
follow-up: 64 comment:60 by , 4 years ago
Replying to strk:
Can you see if there's a way to have the notice you mention written in some template already ?
I think the changes I just committed will fix this. Can we test the updated code?
martin: If I reset the db would you have time to test again?
comment:61 by , 4 years ago
Milestone: | → Sysadmin Contract 2021-I |
---|
comment:62 by , 4 years ago
Priority: | normal → major |
---|
comment:63 by , 4 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:64 by , 4 years ago
Replying to strk:
I think the changes I just committed will fix this. Can we test the updated code?
martin: If I reset the db would you have time to test again?
I'm sorry, apparently that message slipped through ....
Anyhow, I checked again and now the migration completed successfully, moving the user page and updating the contributions included. Wonderful!
comment:65 by , 4 years ago
I've incorporated hexmode's install scripts into an ansible playbook. In addition to the wiki ldap, he provided us with a bunch of other goodies incorporated in this playbook -- e.g. restructuring to fit wiki modern convention, using memcached etc.
I have it in this repo https://git.osgeo.org/gitea/sac/ansible-deployment/src/branch/master/deployment/roles/wiki
I tested it on a backup of wiki of a week ago. I'm going to do a couple more final tests on new snapshot of wiki before go live.
I'm planning to go live to be this coming Friday to give people a week to test on. I'll send an official announcement after I've done some final ansible test runs.
Testing env is:
https://staging.wiki.osgeo.org
(NOTE: I'm doing a couple more trial runs of my ansible script - so that staging link above may be up and down depending on my testing phase)
comment:66 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Migration of wiki.osgeo.org is complete. You should now be able to login with your LDAP account and if your content has not been migrated, you should be prompted to do so.
comment:67 by , 4 years ago
Just ran through the update:
- Can we add some info to the login page (or a link), so people know they have to use LDAP (and if they don't have LDAP make one) - I suspect many people won't have seen the email on Discuss and will be confused.
- After completing the merge, the continue button takes me back to starting the merge. It did finish and navigating away seems fine, but that was odd, maybe continue should send people to homepage.
comment:68 by , 4 years ago
- Happened to me a number of times, but I couldn't replicate the issue consistently.
Regarding the #1, the Request login page takes you to the LDAP create page. I also changed the main site where it talks to wiki to say you need an LDAP account and changed the LDAP create page to note wiki is one of the things you need an LDAP account for.
I thought #1 was pretty clear for old users, as it does find your old account and tells you to merge. Not sure what more we can add to that page to make it clear without being more confusing. Perhaps we can have link to the detailed instructions like what hexmode had provided.
follow-up: 73 comment:69 by , 4 years ago
Hi, I am stuck in 2) -> endless loop, in which the continue button takes me back to starting the merge, rejecting the merge.
User name "neteler"
Another report is at https://github.com/OSGeo/osgeo/issues/233
comment:71 by , 4 years ago
I performed the migration to LDAP user "martin" on the prod instance but, unfortunately, in contrast to the preceding test on staging, my user page was not migrated and my edits are still owned by the old Wiki user "Mspott".
This time I started the migration on prod by logging in as the old Wiki user first .... wait let me cross-check. Oh, re-running the migration on the current staging leads to the same result when logging in as LDAP user first. Obviously the procedure has changed since my last - successful - test.
Meanwhile I moved the user page manually on prod, but, of course, this still doesn't fix the ownership of my edits.
follow-up: 74 comment:72 by , 4 years ago
If you have access to https://wiki.osgeo.org/wiki/Special:UserMerge you can merge your old user with your new one. The old user will now be "Wiki-OLDUSERNAME".
Once your old user is merged with your new one, the ownership of the edits should be fixed.
comment:73 by , 4 years ago
Replying to neteler:
Hi, I am stuck in 2) -> endless loop, in which the continue button takes me back to starting the merge, rejecting the merge.
User name "neteler"
Can you log in with your ldap user? What happens if you do?
Another report is at https://github.com/OSGeo/osgeo/issues/233
I replied to that one.
comment:74 by , 4 years ago
Replying to hexmode:
If you have access to https://wiki.osgeo.org/wiki/Special:UserMerge you can merge your old user with your new one. The old user will now be "Wiki-OLDUSERNAME".
I am part of SAC and (think) to also be part of the group "Bureaucrats", but I get
Permission error Jump to navigation Jump to search You do not have permission to merge users, for the following reason: The action you have requested is limited to users in the group: Bureaucrats.
Maybe robe or strk could check that please?
comment:75 by , 4 years ago
I seem to not have access to bureaucrats anymore either, gives me the same permission error as @neteler gets.
comment:76 by , 4 years ago
It's very odd though, cause when I look here
https://wiki.osgeo.org/w/index.php?title=Special:ListUsers&group=bureaucrat
I am listed as a bureaucrat and so is neteler. Could it be the error is wrong and it's for a different reason, like we are in LDAP mode and that doesn't fully apply?
But it could be just our accounts for some reason did not fully merge as ours shows "In process of merging".
I see wildintellect's account doesn't show that strange message, so perhaps he can do it.
comment:77 by , 4 years ago
I think it does have to do with my issue when originally merging my account, that error that sadly happened to me in production but not in staging.
I noticed in staging.wiki.osgeo.org, I do have merge permissions.
comment:78 by , 4 years ago
I've logged the issue in https://git.osgeo.org/gitea/hexmode/WikiToLDAP/issues/8
@neteler I edited the mysql database to put back your group permissions and did so with mine as well. I was going to leave the others as is until we determine the culprit of the issue. The problem does not consistently happen so hard to troubleshoot. Some people's groups seem to come thru fine and some do not and as mentioned it's not even consistent by user as my groups came thru fine when testing in staging but did not come thru fine in prod. Wildintellect's seems to have come thru fine in prod.
comment:79 by , 4 years ago
Thanks for your efforts. I can login again but something is still wrong
- the user is still linked to an old page (or should the content be flipped which I could do)
- I have no edit rights
- perhaps because still being in "Accounts in progress of converting"
- the list of my contributions (hey, since 2006 :-) ) are currently 0
I suspect that the migration of my user account didn't work well so far.
comment:80 by , 4 years ago
I deleted the in progress part and deleted all the groups the neteler acocunt belongs to. Can you try logging again and see if things are better.
follow-up: 83 comment:81 by , 4 years ago
Neteler can you see if you have access to your pages again? Hopefully I didn't cause more damage than good.
I couldn't merge the accounts neteler / Neteler because the routine sees them as the same name.
However I was able to use the Rename User feature to rename your ghost account from neteler to Wiki-Neteler and then merge Wiki-Neteler into Neteler (and deleted the Wiki one). Hopefully that did the trick. If so I can do that with others that have ghost accounts.
comment:82 by , 4 years ago
My user account 'Jmckenna' is in the exact same situation as 'Neteler': no past edits, not part of bureaucrats even though was before. Could it be that any bureaucrat is facing this issue, since the merge?
- zero past contributions: https://wiki.osgeo.org/wiki/Special:Contributions/Jmckenna
follow-up: 84 comment:83 by , 4 years ago
Replying to robe:
Neteler can you see if you have access to your pages again? Hopefully I didn't cause more damage than good.
Thanks - the login now works, and history is there: https://wiki.osgeo.org/wiki/Special:Contributions/Neteler
However, yet no edit rights...
follow-up: 90 comment:84 by , 4 years ago
Replying to Jeff McKenna:
Could it be that any bureaucrat is facing this issue, since the merge?
- zero past contributions: https://wiki.osgeo.org/wiki/Special:Contributions/Jmckenna
The issue is case sensitivity one. It turns out our Mysql wiki database is case sensitive. Came as shock to me and wiki expects the first letter to be Upper. Cutting to the chase, this resulted in ghost accounts being created. So there is a Jmckenna and a jmckenna account. It seems for many people the history / group was assigned to the all lower case account which you can't log into because login forces uppercase for first letter.
We put in a patch last night which hopefully should fix the issue moving forward.
I've just merged your identity Jeff -- can you try again.
Replying to neteler:
Replying to robe:
Neteler can you see if you have access to your pages again? Hopefully I didn't cause more damage than good.
Thanks - the login now works, and history is there: https://wiki.osgeo.org/wiki/Special:Contributions/Neteler
However, yet no edit rights...
This is odd I thought I took you out of the in-progress/needs-migration group and yet you seem to have gotten back in. I've deleted those again, but this time via the Wiki interface instead of directly from the database. If they show up again when you log in I'll investigate further.
+---------+----------------------------+-----------+ | ug_user | ug_group | ug_expiry | +---------+----------------------------+-----------+ | 25083 | bureaucrat | NULL | | 25083 | sysop | NULL | | 25083 | wikitoldap-in-progress | NULL | | 25083 | wikitoldap-merged | NULL | | 25083 | wikitoldap-needs-migration | NULL | +---------+----------------------------+-----------+
follow-up: 89 comment:85 by , 4 years ago
At a glance no new accounts since I put in the ucFirst patch have ghosts (ticket / patch here - https://git.osgeo.org/gitea/hexmode/WikiToLDAP/issues/8)
I have merged the following accounts which had ghosts. Can these people check and see if they have history and can edit their content.
Aghisla Jbryant Kalxas Martin Mlennert Rjuju
comment:86 by , 4 years ago
Also merge these with their ghost accounts
Alfonx Aanderson Gfleming Jsanz Krashish8
comment:87 by , 4 years ago
Excellent - I can now login and edit!
The others hopefully as well after the fix.
comment:88 by , 4 years ago
Hi all, I hardly remember observing such automated process succeed on a test copy of a system and afterwards fail on the production instance .... well, learning never stops :-)
As far as I can tell, most of the migration steps of my Wiki user account have now completed successfully on the prod instance, the Contributions list filled up and looks plausible. I found one single, minor issue:
References to the specific User page, like the one in https://wiki.osgeo.org/wiki/SAC:Primary_Administrators still refer to the old Wiki user name. I'll apply a manual fix to mine, anyhow other contributors might not be aware of this fact.
comment:89 by , 4 years ago
Replying to robe:
At a glance no new accounts since I put in the ucFirst patch have ghosts (ticket / patch here - https://git.osgeo.org/gitea/hexmode/WikiToLDAP/issues/8)
I have merged the following accounts which had ghosts. Can these people check and see if they have history and can edit their content.
Aghisla Jbryant Kalxas Martin Mlennert Rjuju
Everything seems to work fine for me (Mlennert).
comment:90 by , 4 years ago
I've just merged your identity Jeff -- can you try again.
Great work Regina, fixed, thanks again!! (nice find on the upper case issue)
follow-up: 94 comment:91 by , 4 years ago
I did the merge with LDAP account, I can login and I can see my contributions but my personal page is lost (I don't understand if it is related or not but it doesn't seem, however I can recover from history) and I cannot edit any pages (I tried with three random pages and my user page)
follow-ups: 93 96 comment:92 by , 4 years ago
I still can't edit anything My LDAP user is Stevenfeldman, my old wiki user was Stevenfeldman. Is that the cause of the problem? Steven
follow-up: 97 comment:93 by , 4 years ago
Replying to Steven Feldman:
I still can't edit anything My LDAP user is Stevenfeldman, my old wiki user was Stevenfeldman. Is that the cause of the problem? Steven
Doesn't look like you had a dupe account but you still had the merge in progress bit. Can you give it another try. I took that off.
follow-up: 95 comment:94 by , 4 years ago
Replying to lucadelu:
I did the merge with LDAP account, I can login and I can see my contributions but my personal page is lost (I don't understand if it is related or not but it doesn't seem, however I can recover from history) and I cannot edit any pages (I tried with three random pages and my user page)
Can you see if you can edit now - I removed you from merge in progress group
comment:95 by , 4 years ago
Replying to robe:
Can you see if you can edit now - I removed you from merge in progress group
Yes, I can edit the pages. Thanks a lot
comment:96 by , 4 years ago
Replying to Steven Feldman: @robe That has fixed it, I am able to edit again Thanks Steven
I still can't edit anything My LDAP user is Stevenfeldman, my old wiki user was Stevenfeldman. Is that the cause of the problem? Steven
comment:97 by , 4 years ago
Replying to robe: That's fixed it! Thanks
Replying to Steven Feldman:
I still can't edit anything My LDAP user is Stevenfeldman, my old wiki user was Stevenfeldman. Is that the cause of the problem? Steven
Doesn't look like you had a dupe account but you still had the merge in progress bit. Can you give it another try. I took that off.
comment:98 by , 3 years ago
I've just login into wiki.osgeo.org and it has merged my account with the LDAP one. However I'm unable to edit any page in the Wiki.
My user in id.osgeo.org is juanluisrp
and my user in the Wiki is https://wiki.osgeo.org/wiki/User:Juanluisrp
The message that I get when I try to edit a page is that I must be member of one of these two groups https://wiki.osgeo.org/wiki/OSGeo:Users or emailconfirmed
. AFAIK I'm member of emailconfirmed
group (https://wiki.osgeo.org/wiki/Special:UserRights/Juanluisrp).
Could you please check what's the problem with my user?
All PHP-related packages that were shipped with the distribution on 'osgeo2' have been removed. Such script was used to configure PHP:
Wiki database access parameters can be read from the "LocalSettings.php" file. We're running MySQL here, so the GRANT for database access looks a bit funny: