#foswiki 2017-08-24,Thu

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood
gac410 changes topic to: Download: https://foswiki.org/Download/FoswikiRelease02x01x04 - Logs: http://irclogs.foswiki.org/bin/irclogger_log/foswiki - Slack: https://foswiki-slackin.herokuapp.com/ - Bugs: https://foswiki.org/Tasks - Next Release meeting Monday 4 Sept 2017, 1300Z
gac410 changes topic to: Download: https://foswiki.org/Download - Logs: http://irclogs.foswiki.org/bin/irclogger_log/foswiki - Slack: https://foswiki-slackin.herokuapp.com/ - Bugs: https://foswiki.org/Tasks - Next Release meeting Monday 4 Sept 2017, 1300Z
[02:48]
......................................... (idle for 3h24mn)
ChanServ sets mode: +o MichaelDaum [06:13]
................................................................................ (idle for 6h35mn)
ChanServ sets mode: +o gac410 [12:48]
zak256I see there is no topic "WikiUsers" in a new install of Foswiki. Should I just create a new topic without text? I cannot find a template topic either. [13:02]
jastit's not required
only if you use TopicUserMapping with custom login names allowed
and if you have it configured that way, registering users will automatically create it
[13:03]
zak256Yes, we use TopicUserMapping.
What triggers its creation then?
[13:04]
jastregistering users, but only if {Register}{AllowLoginName} is enabled, otherwise WikiUsers is neither needed nor used [13:06]
zak256Yes, that is enabled.
I configured ApacheLogin and login works. If I click "login" I just see "Hi, u sername" in the left bar.
And if I try to register, it says "username" is already used.
[13:06]
jastWikiUsers is not directly related to whether Apachelogin is used
well, I'm guessing there's a password entry in the way, then...
[13:07]
zak256No password... kerberos authentification is used. [13:08]
jastso you're using some kind of user directory with kerberos support? [13:09]
zak256active directory, yes [13:09]
jastnot sure what good TopicUserMapping would be doing you then
you'll probably have a better time with LdapContrib's LdapUserMapping and so on
add in NewUserPlugin and your users will get a personal user topic the first time they log in
the whole idea with TopicUserMapping is that the users are *not* managed in an external user directory :)
[13:09]
zak256Yeah, I thougt of that, but we had nice "FirstnameLastname" topics before and I think it is better to continue using this. The usernames itself are not meaningful
At least for now.
[13:10]
jastsure, you can automatically derive FirstnameLastname type WikiNames from AD attributes (givenName, sn)
it's the default configuration, too
in LdapContrib, that is
[13:10]
zak256Yes... in an ideal world... but it's not that easy I'm afraid. We cannot rely on whats written in the AD
This needs to be something to switch to in an extra project.
[13:11]
jastokay, then I guess you'll have to muddle your way through with TopicUserMapping after all
TopicUserMapping stores its password hashes in .../data/.htpasswd, I recommend making a backup and then removing all entries for the AD accounts you're wanting to set up, that way registration should succeed
[13:12]
zak256There are no passwords stored in foswiki. The authentication is done by Apache/Kerberos.
Foswiki just gets the username, and should map this to the wikiname.
[13:14]
jastyes, but if the TopicUserMapping registration claims that the account already exist, I'm guessing you have old registrations left in there, from before setting up Kerberos (you said you've been using FirstnameLastname topics before, so that seems to fit) [13:15]
zak256it's a fresh install, but I guess it has something to do with the setting {FeatureAccess}{Configure} = 'username' [13:16]
jastit shouldn't, from what I know
unless you're trying to register one of the built-in accounts (e.g. admin, AdminUser, guest, WikiGuest, ...)
[13:16]
zak256Well, I copied the old WikiUsers topic and it seems to work now. [13:16]
jastunless you have an old user database, mapping to e-mail addresses won't work, though, so notifications won't happen [13:17]
zak256For now I only configured a fresh new Foswiki. The plan is to copy/migrate old data bit by bit.
So no old user database, no old wiki pages, nothing.
[13:19]
jastright. sounds like you'll be a little busy, then... :) [13:20]
zak256That is an understatement...
Another question: I see there is a configuration {UsersWebName} (set to 'Main')
But I cannot change this in bin/configure
is this unsupported or discouraged?
I am thinking about keeping all the users topics in a separate web.
[13:20]
jastyou *can* set it in configure but it's marked as an 'expert' option [13:22]
zak256Yes, I activated expert options.
But I still cannot find it.
[13:22]
jastunfortunately it's not used *only* for users [13:22]
zak256users and groups? that would be okay. [13:22]
jastalso some templates, control topics, and various plugins will assume that it serves the function of a "Main" web
personally I prefer putting everything *else* (your content) in a different web
[13:23]
zak256Well... if everything that is now stored in 'Main' will then be stored in 'Users' the rename makes no sense of course.
Yes, we do that already.
[13:24]
jastbtw the option is in Miscellaneous -> Web and topic names [13:25]
zak256Ahh... found it. Thanks.
So, it makes no sense to rename this, if Main is not really used for anything else by us?
[13:26]
jastthat's my opinion, yes [13:34]
zak256ok, I will do that then [13:34]
What about the TWiki-Web, is that still needed? [13:44]
jastno
Foswiki puts its documentation and internal stuff in the 'System' web
[13:44]
zak256can I remove lib/TWiki.pm and lib/TWiki/* as well? [13:45]
jastshould be fine [13:45]
zak256Great. [13:45]
jastif you have any old TWiki plugins running, you might want to hold onto your backups of that at least
so you can put them back in if it turns out no Foswiki port exists
[13:45]
zak256I don't think we have, but if that is the case I will see later if something doesn't work. [13:46]
.... (idle for 16mn)
gac410Note that if you do choose to rename Main, it seems to work fine in latest foswiki. most everything referenced to Main will automatically be found in whatever webname you use.
It's why in everying we ship, we use %USERSWEB% macro instead of referencing Main directly. Of course an occasional mistake slips in, but we try to find them
My development system runs with a Usersweb. I leave Main there as-is, but don't put anything in it.
However as you are migrating data from an old wiki, you will probably find lots of explicit Main.blah references, so probably not a good idea.
Re removing the lib/TWiki All of the files in there come from the TWikiCompatibilityPlugin. As long as you have disabled that plugin, it's probably safe to remove it.
[14:02]
Worst case, you could reinstall Foswiki:Extensions.TWikiCompatibilityPlugin and get them all back. It has not been updated since July 2015 [14:18]
FoswikiBothttps://foswiki.org/Extensions.TWikiCompatibilityPlugin [ TWikiCompatibilityPlugin ] [14:18]
gac410and with that... I'm away for a while. [14:18]
***ChanServ sets mode: +o Lynnwood [14:32]
......... (idle for 40mn)
zak256Thanks gac410. My goal is to get rid of TWikiCompatibilityPlugin completely. [15:12]
But there are so many things... right now I am trying to figure out what to enter in {FeatureAccess}{Configure} to get rid of the warning that I am locked out when saving the configuration. But it is already saved...
It says members of AdminGroup have access by default, but my user is in fact a member of AdminGroup.
I think I already had that error some time ago.. :-/
Yeah... https://foswiki.org/Tasks/Item14169
[15:19]
gac410That fix is checked in. [15:30]
zak256Well, I am using a new version 2.1.4 [15:30]
gac410So the fix wasn't good, and as I don't have kerberos available, it wasn't verified. Quality of fixes depends on enthusiasm of the beta testers. :( [15:31]
zak256Then it should be included I guess... but it doesn't work I am afraid.
No problem.
I am glad to help!
[15:31]
gac410FeatureAccess}{Configure} should be a registered user. At which point AdminGroup will be ignored.
It's perfectly fine to leave FeatureAccess empty. Then just trust your admins.
[15:32]
zak256Yes, it is myself.
AdminGroup has two members right now: AdminUser and MyselfUser
And I am logged in as Myself User.
And I am able to access configure without problems.
But it shows this warning.
[15:32]
gac410Does the warning also say "The admin group has no members?" [15:34]
zak256No.
only: "Current user MySelf not in this list, and is locked out, If you save the configuration, you'll lose access to configure!"
[15:34]
gac410hm okay let me look [15:35]
zak256If I write "AdminGroup" into the list, the warning disappears, but after saving, I cannot access configure :( [15:35]
gac410y, AdminGroup should not be in the list. It's only users, not groups [15:35]
zak256okay [15:35]
gac410Is your AdminGroup defined as a conventional Topic based group? Main.AdminGroup ... or is it coming in via Kerberos groups [15:36]
zak256no, it's a simple AdminGroup.txt within the Main directory [15:36]
gac410hm okay I'll have to look at that code [15:37]
zak256I can easily add debug code if that helps, just tell me what you need. [15:37]
gac410The message about current user not in group comes from lib/Foswiki/Configure/Checkers/FeatureAccess/Configure.pm [15:39]
zak256I see the code from the fix is in there as expected.
but it looks different
[15:42]
gac410Verify that the error is reported as part of the FeatureAccess}{Configure} field. And that {FeatureAccess}{Configure} is empty? [15:43]
zak256# grep FeatureAccess}{Configure lib/LocalSite.cfg
$Foswiki::cfg{FeatureAccess}{Configure} = '';
And yes, the error is below that field
[15:44]
gac410okay. What are the errors reported again. Just the one error, that the user is locked out? [15:45]
zak256yes, see c&p above [15:45]
gac410Okay, I've recreated the bug. :( [15:52]
zak256At least a step forward [15:52]
gac410You are not locked out, so it's a false error. [15:52]
zak256I guess it somehow checks the wrong names? Maybe it checks if "unixuser" is included in "AdminGroup" instead of "WikiUser"? [15:53]
gac410No, it's a stupid error. It actually doesn't check the list of admins. Doh... [15:59]
zak256Well... better a stupid error than an error which needs more work to fix. [16:00]
gac410See if this fixes it: https://pastebin.com/e2rHQY7a
And if you would please open a task, I'll get a fix checked in tonight. Just had 5 yards of loam delivered, so I need to get hauling. :(
[16:02]
zak256Of course! Can't I reopen the old task? [16:03]
gac410No, once a task has been marked closed and shipped in a release, it would confuse things to then have it opened. [16:04]
zak256ok, I will open a new task [16:04]
gac410Thanks
Actually Item14169 was for FeatureAccess to handle login names. which I hope is actually fixed. Ie You don't get errors if you use the wikiname or login name in {FeatureAccess}{Configure}
[16:04]
FoswikiBothttps://foswiki.org/Tasks/Item14169 [ Item14169: Verification for {FeatureAccess}{Configure} in configure fails to handle login names. ] [16:06]
gac410This bug is because it doesn't properly check the AdminGroup when FeatureAccess}{configure} is actually empty.
Anyway, I gotta run out and start shoveling ... Please let me know if the patch does fix it for you, and also verify that it works with your Kerberos configuration when you get a chance. Thanks.
[16:07]
zak256Will do that! Thanks again! [16:08]
gac410yw
Sorry for the error,
I'll check back in in a few hours.
[16:08]
zak256I will be home then, but will be back again tomorrow I guess
So have a nice evening
[16:09]
Hmm... no change for now unfortunately. I added some debug code to print out the actual values of $user and $curuser.
@admins contains: BaseUserMapping_333 and unixuser
But $curuser is MyWikiUser
$cUID is the unixuser as well
[16:14]
I opened https://foswiki.org/Tasks/Item14463 [16:26]
....... (idle for 33mn)
gac410okay. That's good info. I'll check *both* wikiname and cUID. Unfortunately with alternate mappers, it can be confusing where cUID, login username, and wikiname are used. This is probably one of the more difficult areas that really needs some reworking.
zak256: So for the if statement, in both the @admins loop *and* the @Authorized loop, the if statement should read:
+            if ( $user eq $curuser || $user eq $cUID ) {

That should fix the AdminGroup, and also allow the FeatureAccess to use the login id / cUID
[16:59]
zak256wait... I will check...
Yes, the error is gone.
Great.
Thanks again. I'm going home now. See you later.
[17:05]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)