#foswiki 2016-11-07,Mon

↑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 [02:18]
........... (idle for 50mn)
GithubBot[distro] gac410 created Item14205 (+1 new commit): https://git.io/vXBsW
distro/Item14205 a5aef45 George Clark: Item14205: Issues with Email and Cert wizards...
[03:08]
***GithubBot has left [03:08]
FoswikiBothttps://foswiki.org/Tasks/Item14205 [ Item14205: Autoconfig Email failing with recent versions of IO::Socket::SSL ] [03:09]
gac410vrurg, I committed my work to a new Item14205 branch based on Release02x01. BTW, the Foswiki VM already has fcgi all set up - that's where I test fcgi stuff. [03:18]
GithubBot[distro] gac410 deleted Item14180 at c6bd9e6: https://git.io/vXBsS [03:22]
***GithubBot has left [03:22]
FoswikiBothttps://foswiki.org/Tasks/Item14180 [ Item14180: Bootstrap enhancements and refactoring. ] [03:22]
.......................... (idle for 2h6mn)
***gac410 has left [05:28]
........................... (idle for 2h13mn)
ChanServ sets mode: +o Lynnwood__ [07:41]
................ (idle for 1h15mn)
ChanServ sets mode: +o MichaelDaum [08:56]
......... (idle for 41mn)
ChanServ sets mode: +o Lynnwood [09:37]
........................................... (idle for 3h34mn)
ChanServ sets mode: +o gac410 [13:11]
.............. (idle for 1h8mn)
foswiki_irc1Hi there. Where would be the best way to implement the conversion of usernames to lowercase when using ApacheLogin? [14:19]
gac410Did the users register with both WikiName and Login Name? [14:20]
foswiki_irc1Yes
Apache uses Kerberos authentication. Unfortunately, usernames are given in uppercase from windows machines.
I did not find any parameter to lowercase the usernames during this authentication.
[14:28]
gac410And by usernames you are referencing the loginname, not the wikiname? [14:30]
foswiki_irc1yes, for example WikiUser -- unixuser [14:30]
gac410Using TopicUserMapper? or LDAP mapper?
Unfortunately I don't know all that much about the windows side of things.
And MichaelDaum who knows ldap much better just escaped ;)
[14:31]
foswiki_irc1Well I asked the Kerberos and LDAP professionals around here, and we tried some things, but no luck. So the last hope now is to just convert the username, which comes from Apache/Kerberos (and is authenticated successfully), to lowercase.
TopicUserMapping is already active
I saw the LdapPlugin has an option to do what I want, but I do not want to setup an LDAP integration right now.
[14:33]
gac410Okay, so with TopicUserMapping, the actual link between WikiName and loginname is stored in the Main.WikiUsers. So you are saying that in your case, it's stored in lower case, and you want it to remain in lower case, but just translate the apace provided name to lower case. [14:36]
foswiki_irc1Yes, exactly.
All the usernames on Main.WikiUsers are in lowercase, I was just looking at it.
[14:36]
gac410Probably needs a code change. let me look for a minute. Not sure if you can do it in a "custom mapper" or it would be needed in the core. [14:37]
foswiki_irc1I guess it should only be a one- or two-liner somewhere to add as a hack? But if that could be integrated as an extra option that would be better of course. [14:38]
gac410Take a look at Foswiki/LoginManager/ApacheLogin.pm around line 151
Thats the code that gets the user from the apache environment.
You could try changing it to: authUser = lc( $query->remote_user() ) if $query;
ie lc( ) the return of the remote user
[14:43]
foswiki_irc1Ah... I see it now. Will try that immediately... [14:44]
gac410And the way to do this, if it works, would be to copy ApacheLogin.pm to YourcompanyLogin.pm or LowercaseLogin.pm or something like that, and set the new name in the configuration
That way if you upgrade, you don't accidentally overwrite your changes.
[14:45]
foswiki_irc1okay, I did a 'cp ApacheLogin.pm ApacheLcLogin.pm' and edited this line to this:
$authUser = lc($query->remote_user()) if $query;
Set ApacheLcLogin in LocalSite.cfg
and restarted the webserver
Now I get an internal error: Can't locate object method "new" via package "Foswiki::LoginManager::ApacheLcLogin"
[14:50]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::LoginManager::ApacheLcLogin [14:51]
gac410Ah.... First line or so of the file. Look for Package line. Needs to match whatever name you chose.
actually line 22
Sorry .. forgot about that little detail
[14:52]
foswiki_irc1No problem. I replaced all occurrences of 'ApacheLogin' with 'ApacheLcLogin'...
And it works! Heureka!
I thank you so much!
[14:53]
gac410Excellent! Glad to help. [14:53]
..... (idle for 20mn)
***ChanServ sets mode: +o Lynnwood__
ChanServ sets mode: +o gac410
[15:13]
..... (idle for 22mn)
foswiki_irc1 has left [15:39]
ChanServ sets mode: +o SvenDowideit [15:50]
.............. (idle for 1h7mn)
foswiki_irc1fsfs: thx 4 your help! Maybe "Use of qw(...) as parentheses is deprecated" output isn't the problem, but there is more like "Can't locate object method "eachWeb" via package "Foswiki::Meta" at bulk_copy.pl line 169." Full output here: http://pastebin.com/r8Tr77ti [16:57]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Meta [16:57]
gac410foswiki_irc1: is this regarding using bulk_copy,pl migrating from a Foswiki 1.0.x system?
Foswiki 1.0 was so old, I don't believe that it was ever tested with bulk_copy. You are probably better off using CharsetConvertContrib on Foswiki 2.x, Copy each web, one at a time, to Foswiki 2.x, then convert the web in place
[16:58]
foswiki_irc1gac410: yes from V1.0.9 to V2.1.2 [16:59]
gac410CharsetConverter is much faster, but it cannot change store type from RCS to PlainFile. But RCS works fine on 2.x, so no need to convert if you don't want to.
See https://foswiki.org/Extensions/CharsetConverterContrib, in particular, the "expert" settings of -charset and -web
er ... -encoding and -web
On your running 2.x system. Install CharsetConverterContrib. Then copy a web from 1.0.x system data/Someweb and pub/Someweb to get all attachments and sub-directories.
Then convert the web in place ... perl convert_charset.pl -i -web=Someweb -encoding=cp1252 (Assuming your old wiki had windows users cutting/pasting.
-i will inspect without changing anything. remove the -i to actually make the change
of course... back up your backups :)
You cannot re-run a conversion on a web once it's been converted. The utility will choke if it gets some files with utf-8 and some with iso-...
If you use HtPasswdUser for password managment, you'll also need to convert the .htpasswd file. Unfortunately we don't have any magic tool to do that one.
Hopefully you have few or no WikiNames or email addresses containing high ascii characters
More info in https://foswiki.org/Support/Utf8MigrationConsiderations
[17:02]
foswiki_irc1gac410: THX a lot! I additional found http://foswiki.org/System/UpgradeGuide#Manual_copy_steps_40not_recommended_41 [17:13]
gac410yes, we don't really recommend the manual steps, but 1.0.x is really old. Manually will probably be the only way [17:15]
foswiki_irc1Maybe someone could drop a hint at http://foswiki.org/System/UpgradeGuide#Copy_the_data_using_61tools_47bulk_copy.pl_61 that 'bulk_copy.pl' doesn't work prior V1.X [17:15]
gac410Y. good point. I'll make a doc change for when we release 2.1.3 ... someday
When the 2.x instructions were first written, bulk_copy was clearly the way to go. But when we migrated Foswiki.org we learned a lot. And did enhancements on charset converter to allow per-web conversion.
Also we've learned that bulk_copy can be really really slow, if you have topics with lots of revision history. As it copies/converts each revision of every topic.
(because it has to support conversion from RCS to PlainFile (or any other store anyone writes).
Charset_converter converts the RCS file "in-place" so it's much faster.
[17:16]
foswiki_irc1OK thx 4 details, but '1.0.x is really old' is relative ;) When systems are running fine (Kudos 2 all@FOSWIKI), there often is no need to update, especially at LAN-intern systems [17:28]
gac410y true. though even internally, it's good to pay attention to security updates. There have been quite a few on 1.0.x and 1.1.x too. And of course all the new features :D
One of the biggest issues though is if a server updates to newer perl, or cpan modules, 1.0 foswiki will be toast 1.1 as well. Perl over the years has deprecated a lot of stuff.
anyway, can't argue with success :)
[17:29]
foswiki_irc1y. OS / perl update still was the main driver 2 update in our case ;) [17:38]
gac410For Foswiki 2.x, it's best to be on the very latest perl you can get. Performance on Perl 5.22 is significantly better than 5.18. Ubuntu 16.04 LTS is in good shape. Some of the other distros are rather back level
(Perl performance of regular expressions over unicode strings is slow .., but greatly improved in 5.22)
[17:39]
***ChanServ sets mode: +o CDot [17:52]
.................... (idle for 1h38mn)
vrurggac410: Hi, I'm trying to get mod_fcgid config on my Mac but is probably missing something essential from the doc. It doesn't look for the .fcgi in correct path: notes ~/src/foswiki in the log while in fact it must be ~/src/foswiki/master/core
Any idea?
[19:30]
gac410What instructions are you following?
Apache as web server? If so, ApacheConfigGenerator should generate a correct config - select mod_fcgid or mod_fastcgi as appropriate.
We probably ought to nuke the old instructions in the System/FastCGIContrib.
[19:31]
vrurgThe generator. But that's my fault. Forgot to change user/group the apache is running as. It's a mess of two apache versions which is relly confusing on MacPorts. Used to run 2.4, but mod_fcgid builds agains 2.2. [19:36]
gac4102.2? Really ... ugh
Must be a Mac issue, I've never seen that before
I usually use the SuexecUserGroup to just run CGI as my own uid. That way no need to fiddle with file ownership.
But it does kill off any ENV settings :(
[19:37]
vrurgMacPorts specific. Fun part of it all is that 2.4 they install under /opt/local (this is MacPorts default) while 2.2 is fully contained under /opt/local/apach2 – including /bin and /etc.
I don't need to suexec because this is my own notebook. No need to overcomplicate things.
Anyway, this is all about permissions only. The config is ok.
[19:39]
gac410okay good. [19:42]
................................... (idle for 2h51mn)
vrurggac410: I have tested the Dependencies module with mod_fcgid and the capture works as expected.
macos, of course.
[22:33]
gac410strange. FCGI definitely does not allow STDERR to be captured.
I guess time will tell then. Did you seen the rt ticket where the issue was reported
[22:33]
vrurgIf it's FCGI the problem then the reason could be that Dependencies.pm gets loaded first. [22:35]
gac410Ah... not running under the control of fcgi somehow? [22:35]
vrurgNo, I didn't see it yet. Just got enough time to finish configuring the apache and run some tests.
It's under fcgi but before the script loads FCGI. Let me check if it's in %INC.
[22:36]
gac410https://rt.cpan.org/Public/Bug/Display.html?id=75580
From the ticket: I have fixed this in trunk[1], attempts to call open on a FCGI::Stream throws: q/Operation 'OPEN' not supported on FCGI::Stream handle/
[22:37]
vrurgThe module is not loaded at when Dependencies is working – reasonable because 'use Foswiki::Aux::Dependencies' happens to be one of the first use/require calls. [22:38]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Aux::Dependencies [22:38]
gac410Okay so I guess you can get away with it, but the code can't be used elsewhere when under control of FCGI [22:39]
vrurgI'll try to test it too.
The module designed to utilize both automatic and manual mode.
[22:40]
gac410My branch Item14205 uses it in the AutoconfigEmail wizard [22:41]
FoswikiBothttps://foswiki.org/Tasks/Item14205 [ Item14205: Autoconfig Email failing with recent versions of IO::Socket::SSL ] [22:41]
vrurgActually, there few things in Perl one cannot suppress or get around. There must be a solution for FCGI superiority. [22:43]
gac410At least for the email wizard, it's a corner case, and if we can't capture the ssl debug messages, it's not all that important [22:44]
vrurgNeither it would be that critical for the dependencies – just one more time when the user would have to have a look into the logs. [22:49]
gac410At least with the email code, it crashes the autoconfig, unless you don't use the capture. It just causes the wizard to die with the "operation OPEN not permitted" error. [22:50]
........ (idle for 39mn)
vrurggac410: What version of FCGI do you use? 0.78, capture works after FCGI::OpenSocket and FCGI::Request calls with run() code.
s/with/within/
[23:29]

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