cclite 0.8: issues with "File::Path"

[Xavi]

Hi Hugh:

We are testing CClite 0.8 in the server where we had CClite 0.7 working (in ourproject.org ), but we are starting to see the first issues.
I followed the steps in the manual for the upgrade, and when I fired the checkinstall, I got:

------------------------------------------------------------------------------------------------
Running Tests...

ok 1 - use CGI; ok 2 - use CGI::Carp; ok 3 - use DBI; ok 4 - use Digest::SHA1; not ok 5 - use Digest::SHA2; ok 6 - use File::Path; ok 7 - use GD; ok 8 - use GD::Graph::lines; ok 9 - use GD::Text; ok 10 - use GD::Graph::sparklines; not ok 11 - use Net::XMPP; ok 12 - use Log::Log4perl; not ok 13 - use GnuPG; ok 14 - use MIME::Base64; ok 15 - use MIME::Decoder; ok 16 - use Net::POP3; not ok 17 - use Net::OpenID::Consumer; ok 18 - use XML::RSS; ok 19 - use XML::Simple; ok 20 - use Mail::Sendmail; ok 21 - use Net::SMTP; ok 22 - use LWP::Simple; ok 23 - use SOAP::Lite; usable is 1

Analysis of Installed Modules and Programs

Cclite core is usable!

cclite can't process encrypted email

cclite can't process jabber based payment

cclite can use local sendmail at /usr/sbin/sendmail

cclite is sms capable with local phone: gammu found
------------------------------------------------------------------------------------------------

However, when I attempt the installation, I get a report on issues with  "File::Path" (even if we got "ok 6 - use File::Path"):

------------------------------------------------------------------------------------------------

Software error:

"make_path" is not exported by the File::Path module
"remove_tree" is not exported by the File::Path module
Can't continue after import errors at ../../lib/Ccadmin.pm line 52
BEGIN failed--compilation aborted at ../../lib/Ccadmin.pm line 52, <MESS> line 606.
Compilation failed in require at [path]/cgi-bin/protected/ccinstall.cgi line 598, <MESS> line 606.

BEGIN failed--compilation aborted at [path]/cgi-bin/protected/ccinstall.cgi line 598, <MESS> line 606.

Please use the Cclite Google Group for help, if necessary

------------------------------------------------------------------------------------------------

Since I could read at the release notes that the File::Path module was upgraded,

    "58. New version of File::Path used for batch directory creation, should be more OS neutral..."

I thought that there might be some issues in our server with some older version of the package, or whatever... (debian based server, but I installed the tar.gz since we don't have a root account there, but or own shared hosting space with ssh acces, etc.)

Any tip on where the problem can be, and how to avoid it?

Xavi

P.S: Thanks for the new version of the manual also! you've been working hard on all aspects! I'll send in another message some small issues I could detect with the current documentation.
P.S.2. I'll ask the sys admin to install the modules required for gpg and openid (and probably jabber) to work...

[Hugh Barnard]

Hi Xavi

Sorry communication will be slower at the moment, busy then away a
little. Anyway, here's the link to the version and doc:
http://perldoc.perl.org/File/Path.html

The trouble you are describing may be because the right version is
installed but, because of path order, the wrong one is being picked up
[I think it works like that, not 'latest' is best]. That's likely with
the parallel debian style packaging system.

As I recall [rather than as I grep, teehee] it's only Ccadmin.pm, so,
at worst we could retro-engineer this to take the older signatures.

Best regards Hugh

> --
> You received this message because you are subscribed to the Google Groups
> "cclite" group.
> To post to this group, send email to ccl...@googlegroups.com.
> To unsubscribe from this group, send email to
> cclite+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cclite?hl=en.
>

--
http://www.hughbarnard.org
http://www.twitter.com/hughbarnard
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/

[Xavi]

Thanks Hugh!

With your tips, I managed to retro-engineer Ccadmin.pm (we are in a
gnu/linux server so folders can be created the traditional way as
before :-) ), and moved forward. Besides that, the sys admin alredy
installed the missing packages, so things are looking nicer to have
Cclite working in our server, and improve our connection from Tiki to
use CClite 0.8 with GnuPG, etc.

Right now, I face a new problem. Once I installed cclite 0.8 (new
config/cclite.cf created successfully), I go to the list of available
registries, I can see the two registries that we had created in Cclite
0.7 (which I sql-upgraded to 0.8), and when I click to any of them (
cgi-bin/protected/ccinstall.cgi?action=showregistries ) , I'm sent to
cgi-bin/cclite.cgi with this error message :

------------------------
Software error:

Mandatory parameter 'filename' missing at
/usr/share/perl5/Log/Log4perl/Appender/File.pm line 38.

Please use the Cclite Google Group for help, if necessary

------------------------

and I'm lost. I don't know where this parameter filename should be
defined, and it seems it's not defined/sent.
No hurries, but tips very welcome, of course. :-)

Cheers

Xavi

2010/8/15 Hugh Barnard <hugh.b...@gmail.com>

[Xavi de Pedro]

Never mind, Hugh and co-listers, I've found it!
the log file path needed to be defined properly and commented out from
./config/logging.cf

Great! Every basic thing seems to be working now at least as it was in 0.7. So we move forward to explore the GnuPG configuration!

Thanks for answering my previous messages, Hugh, even if busy, because with your tips I've been able to move forward myself, and getting more used to see how cclite is organized, etc.

Cheers

Xavi

P.S. Jonny, Eclipse (now with the perl plugin EPIC) is helping me a lot to move around and get oriented easily when looking at the Cclite code! Thanks again for your tutoring on using Eclipse! (it seems that it has been a good investment of time for many aspects of my work at university and out of university :-)

2010/8/15 Xavi <xa...@tikiwiki.org>

[hugh.b...@gmail.com]

Hi folks

Just one last comment on File::Path on Debian/Ubuntu. The deb-packaged
version is apparently old. However, yesterday, we downloaded and
installed [via perl -MCPAN -e shell, the traditional method]
File::Path 2.08 onto Phil's Ubuntu and it worked.

Obviously, this is a little messy though, but it looks as though the
pick-up order is sane. best regards Hugh

[Jonny Bradley]

Hi all

We have cclite-0.8.0.1_98 where we used to have 0.7 and the remote login etc was working fine from our Tiki, but now we're getting "password failed for manager at..." for all users. I've updated the .htaccess file which all seems to work fine now (but even if i manually go to /cgi-bin/cclite.cgi?action=logon&subaction=om_users&registry=our_reg&userLogin=manager&logontype=api with the magic cookie set i get this).

Has the way the hashing of passwords changed? I checked the gateway examples and they don't seem to have been updated - do they still work?

We have to use sha1 due to server admin difficulties, and it seems to work ok for "normal" logins.

Sorry, stuck!

jonny B

[hugh.b...@gmail.com]

Hi Jonny, folks

No change in this that's damaged anything else...however REST doesn't
currently have good regression tests either. I'm in France at the
moment but will try and shed more light on this, in a week when I'm
back..

Best regards Hugh

On Sep 9, 7:12 pm, Jonny Bradley <jonnybrad...@gmail.com> wrote:
> Hi all
>

> We have cclite-0.8.0.1_98 where we used to have 0.7 and the remote login etc was working fine from our Tiki, but now we're getting "password failed for manager at..." for all users. I've updated the .htaccess file which all seems to work fine now (but even if i manually go to /cgi-bin/cclite.cgi?action=logon&subaction=om_users&registry=our_reg&userLo gin=manager&logontype=api with the magic cookie set i get this).

[Jonny Bradley]

Thanks for the reply anyway, Hugh. I'll go back and re-retest in the meantime...

jonny

[hugh.b...@gmail.com]

Hi Jonny, folks

Looked at the code that produces this, it's from line 382 in Cclite.pm
and also involves Ccsecure.pm to compare the hashes:

$log->warn(
"$messages{loginfailedfor} $$fieldsref{userLogin} $messages{at} $
$fieldsref{registry} : password failed"
);

#FIXME: The locking mechanism is in place but nothing for resetting
and testing, bigger job...
$$userref{userPasswordTries}--;
if ( $$userref{'userPasswordTries'} <= 1 ) {
$$userref{'userPasswordStatus'} = 'locked';
$$userref{userPasswordTries} = 0;
}


But, also, if you see above, it locks the password after three tries
as well. This is not new in 0.8.0 but may be problematic.
Also, the switch between SHA1 and SHA2 in Ccsecure.pm, has changed
from 'use' to 'require' see lines 91 and following.

Finally (and this could contribute) I've relaxed the spacing for for
the list of IP addresses (because it really shouldn't matter if
they're separated by more than one space and it's near-impossible to
'see'), for the API hash. If you de-comment the debugging code in 278
Ccsecure.pm, it goes through the API key comparison there, that may
show what's going on...

Ok, there are some ideas..tell me how you do...

Best regards Hugh

--
http://www.hughbarnard.org
http://www.twitter.com/hughbarnard
http://www.big-wave-heuristics.com/
http://www.hackney-environment-network.org.uk/

On 10 Sep, 12:24, Jonny Bradley <jonnybrad...@gmail.com> wrote:
> Thanks for the reply anyway, Hugh. I'll go back and re-retest in the meantime...
>
> jonny
>

[Jonny Bradley]

Hi Hugh

Many thanks for your investigations.

We only have sha1, but as i understand it that should still be fine, right?

Maybe the locking thing has happened - how do we tell? Looking at the user record of the one i was testing with the form seems all blank - no UserLogin even... (although there is a UserName showing) might that be a clue? (just a bug i think - the list has all the data in)

I'll try the debugging code you suggest when i can, and get back with any news...

Thanks again

jonny

[hugh.b...@gmail.com]

Hi Jonny

Replies below...sorry about all the new questions...best regards Hugh

On Sep 19, 2:22 pm, Jonny Bradley <jonnybrad...@gmail.com> wrote:
> Hi Hugh
>
> Many thanks for your investigations.
>
> We only have sha1, but as i understand it that should still be fine, right?

--> yes, if it isn't then it's 'my' problem...

>
> Maybe the locking thing has happened - how do we tell? Looking at the user record of the one i was testing with the form seems all blank - no UserLogin even... (although there is a UserName showing) might that be a clue? (just a bug i think - the list has all the data in)
>

--> userPasswordStatus shouldn't matter for api logon, sorry, that's
also something that could do to get fixed...

> I'll try the debugging code you suggest when i can, and get back with any news...

--> yes, the Ccsecure debugging should show something useful
anyway...also is the configuration file cclite.cf set with
hash_type=sha1? Is it only the manager who can't login or all created
users?

>
> Thanks again
>
> jonny

[Xavier de Pedro]

Well, I wonder what has been the real solution, but, in short: tiki and
cclite are back talking to each other!!!!
(see screenshot attached)

I also fixed a few "wrong paths" (expecting single installation in a
debian server, and not through a debian-gforged site) that I could see
at ./config/cclite.cf , through editing directly that file (I wonder why
I didn't see those wrong paths previously :-/ ...)

Hugh, did you edit those things in the cclite at c2c.op.o directly?

Xavi

Al 19/09/10 16:36, En/na hugh.b...@googlemail.com ha escrit:

[Jonny Bradley]

On 21 Sep 2010, at 07:47, Xavier de Pedro wrote:

> Well, I wonder what has been the real solution, but, in short: tiki and cclite are back talking to each other!!!!
> (see screenshot attached)

Yay! Well done Xavi :)

> I also fixed a few "wrong paths" (expecting single installation in a debian server, and not through a debian-gforged site) that I could see at ./config/cclite.cf , through editing directly that file (I wonder why I didn't see those wrong paths previously :-/ ...)

I double checked them all too and didn't spot anything out of place.

> Hugh, did you edit those things in the cclite at c2c.op.o directly?

If so, huge thanks! If not, Xavi... you have powers you are barely aware of! :)

jonny

> --
> You received this message because you are subscribed to the Google Groups "cclite" group.
> To post to this group, send email to ccl...@googlegroups.com.
> To unsubscribe from this group, send email to cclite+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cclite?hl=en.
>

> <200921_c2c_08_op_o_tiki6_transaction_ok.png>

[Hugh Barnard]

Hi both

Nope, didn't do anything...I'm going to become Barely Aware Man, a new
superhero for the twentyteens when I have a moment... best regards
Hugh

[Xavi]

ok, then until no other explantion is found, the problem had to be in
the wrong paths at the cclite.cf which were not shown at the cclite
interface for admins, but just guessed from the server type (debian),
but in the wrong place, since our cclite is in a gforged site, so they
are in subfolders from users, and not in the general path of that debian
server.

My guess...

Xavi

P.S. I still believe in superhero's of the twentyteens, but I reckon I'm
not one of them :-)

Al 21/09/10 16:59, En/na Hugh Barnard ha escrit:

[hugh.b...@gmail.com]

Hi Xavi

That's probably right, it guesses but [clearly] it can't make a good
guess for customised subcases...I'm working on making everything
possible 'relative' in most cases, that should make paths more
general..

Best regards Hugh

On Sep 22, 11:27 am, Xavi <x...@tikiwiki.org> wrote:
> ok, then until no other explantion is found, the problem had to be in
> the wrong paths at the cclite.cf which were not shown at the cclite
> interface for admins, but just guessed from the server type (debian),
> but in the wrong place, since our cclite is in a gforged site, so they
> are in subfolders from users, and not in the general path of that debian
> server.
>
> My guess...
>
> Xavi
>
> P.S. I still believe in superhero's of the twentyteens, but I reckon I'm
> not one of them :-)
>
> Al 21/09/10 16:59, En/na Hugh Barnard ha escrit:
>
> > Hi both
>
> > Nope, didn't do anything...I'm going to become Barely Aware Man, a new
> > superhero for the twentyteens when I have a moment... best regards
> > Hugh
>

> > On 21 September 2010 12:15, Jonny Bradley<jonnybrad...@gmail.com>  wrote:
>
> >> On 21 Sep 2010, at 07:47, Xavier de Pedro wrote:
>
> >>> Well, I wonder what has been the real solution, but, in short: tiki and cclite are back talking to each other!!!!
> >>> (see screenshot attached)
>
> >> Yay! Well done Xavi :)
>
> >>> I also fixed a few "wrong paths" (expecting single installation in a debian server, and not through a debian-gforged site) that I could see at ./config/cclite.cf , through editing directly that file (I wonder why I didn't see those wrong paths previously :-/ ...)
>
> >> I double checked them all too and didn't spot anything out of place.
>
> >>> Hugh, did you edit those things in the cclite at c2c.op.o directly?
>
> >> If so, huge thanks! If not, Xavi... you have powers you are barely aware of! :)
>
> >> jonny
>
> >>> Xavi
>

> >>> Al 19/09/10 16:36, En/na hugh.barn...@googlemail.com ha escrit: