Re: change_passwd-4.3beta7-1.2.8.tar.gz -- has stopped working.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 8, 2010 at 8:48 PM,  <sm@xxxxxxxxxxxx> wrote:
>> Not sure what you did to the text, but quoting is quite borked here,
>> hard to read...
> I'm using Squirrelmail-1.4.21 and the reply link.  When I go to reference
> a previous mail, I save to draft folder and come back to the draft and
> continue, nothing else.
>
>>
>> On Wed, Sep 8, 2010 at 7:04 PM,  <sm@xxxxxxxxxxxx> wrote:
>>>>>>> think 'step-5' applied to our situation or issue; I thought we
>>>>>>> tested
>>> 'change_passwd' at least once.  However, I will try 'step-5' now.
>>>>>> It says if the binary isn't working, recompilation is probably called
>>> for... your situation definitely qualifies for that.
>>>>>>> RESULTS:
>>>>>>> gcc -lcrypt -O -o chpasswd chpasswd.c
>>>>>>> chpasswd.c:33:19: error: crypt.h: No such file or directory
>>>>>>> A little googling leads us to believe that "the crypt() function is
>>> defined in unistd.h, not crypt.h".
>>>>>> Either one might work.  Not sure.  What does "man crypt" tell you?
>>>>>> Did
>>> you search for those header file and actually look in them for crypt?
> No I have not.  I thought you were meaning the chpasswd.c was a header file.
>
>>>>>>> I tried replacing #include <crypt.h>
>>>>>>> with #include <unistd.h>, remember we're not programmers; chpasswd
>>> continues to not function on FreeBSD-7.3.
>>>>>> You have to give more details.
>>>>> find / -name 'crypt.h'
>>>>> /usr/src/lib/libcrypt/crypt.h
>>>>>>What is the compilation output?
>>>>> # gcc -lcrypt -O -o chpasswd chpasswd.c
>>>>> chpasswd.c:33:19: error: crypt.h: No such file or directory
>>>> Looks like you have crypt on your system.  You just need to find the
>>> right combination of compilation arguments to get it to work.  Try
>>> adding
>>> "-L/usr/src/lib/libcrypt" for starters. Or just adding
>>>> "-lcrypt" might work.  You'll have to play around and/or do some
>>> searching.
> None of the above is working.  Please allow me to point out that I have at
> least one other port that has used "-lcrypt" recently; here's a snipp...
>
> cflags        (mysql_config) = -I/usr/local/include/mysql
> -fno-strict-aliasing -pipe
>  embedded      (mysql_config) =
>  libs          (mysql_config) = -L/usr/local/lib/mysql -lmysqlclient -lz
> -lcrypt -lm
>
> It compiled without any issues.

I don't have a BSD test machine, so I can't really help you any more
than you can help yourself.  Google and whatnot.  The best solution
would be to convert the program to use automake, but I have not the
time to fiddle with that right now.  If you are willing to wait around
and test it when I do, I can try to put that on my list in the next
few weeks.  Otherwise, as I said, have a try at figuring out the right
compilation arguments and let us know the correct ones when you have
it compiling.

> Please report back if you get it to compile.
>>>>>>What happens when you run the binary from the command line?
>>>>> #  ./chpasswd <user> <correct.current.passwd> <new.passwd>
>>>>> RESULT: Current password is incorrect
>>>> How is this when you could not compile it?  I just looked and unistd.h
>>> is > already included, so if you replaced crypt.h with unistd.h, then
>>> you
>>> have > it twice.
>>>
>>> It was removed once we saw it had no affect.
>>> -
>>> The results I posted here, starting with the preceding email was with a
>>> fresh install and with the removal of 'all' the '^M'.  That being said,
>>> you are correct gcc/cc compiles continue to fail with the results we
>>> previously posted; here are the compile failure results again:
>>>
>>> # gcc -lcrypt -O -o chpasswd chpasswd.c
>>> chpasswd.c:33:19: error: crypt.h: No such file or directory
>>>
>>> # gcc -Wall -lcrypt -O -o chpasswd chpasswd.c
>>> chpasswd.c:33:19: error: crypt.h: No such file or directory
>>> chpasswd.c: In function 'main':
>>> chpasswd.c:103: warning: pointer targets in passing argument 1 of
>>> 'fixpwd'
>>> differ in signedness
>>> chpasswd.c:104: warning: pointer targets in passing argument 1 of
>>> 'fixpwd'
>>> differ in signedness
>>> chpasswd.c:105: warning: pointer targets in passing argument 1 of
>>> 'fixpwd'
>>> differ in signedness
>>>
>>> Once again this is a fresh install using: cp config_example.php
>>> config.php
>>> afterwards removing 'all' of the '^M'.
>>> -
>>> Using ./chpassword from the cli:
>>> change_passwd/chpasswd 'userID' 'old_pass' 'new_pass' 2>&1
>>> RESULT: [3] 18811
>>> 1: Command not found.
>>> [2]  - Exit 9                       ./chpasswd userid old_pass new_pass
>>> > 2 -
>>> Above nothing truncated or added.  Given that we aren't able to compile
>>> chpasswd, watch this:
>>>
>>> # ./chpasswd user1
>>> Missing current password
>>> # ./chpasswd user1 12345
>>> Missing new password
>>> # ./chpasswd user1 12345 67890
>>> User does not exist: user1
>>> -
>>> Correct user1 does not exist, however it appears 'chpasswd' runs in some
>>> way from the cli but it doesn't actually change any password when you
>>> have
>>> a valid userid in place. chpasswd also 'appears' to run via SM-1.4.21 >
>>> options > change password. Currently, using the latter method tells the
>>> user, in red; "Your password was changed successfully" <-- verbatim; on
>>> the change password form/page.
>>
>> You originally reported that running the binary gave you "ELF binary
>> type "0" not known"
>>
>> Now you say it is (half) working.  I can't follow what you are doing,
>
> The output that include ELF was shown on the change password page/form
> after we attempted to change a valid users password while both: $debug =
> 1; and $seeOutput = 1; <--config.php.
>
>> what version of which binary you are using,
> If the answer to your question is not the version number in the subject
> line, I have not a clue, nor to I know How to find the answer to that
> question.  I'd be more than happy to follow your instructions.
>
>> but the most relevant
>> thing to say is that all this testing is useless if you couldn't
>> compile the binary in the first place.  I'm not sure what you expect
>> out of it otherwise.  I already gave you some tips to help find the
>> right compilation arguments.
>
> At this point the focus is on why chpasswd is not compiling and/or finding
> crypt.h when in fact crypt is on the machine and other ports can find and
> use crypt.h when they need to.  Nothing really customized on this machine
> other than the kernel, as in nothing exotic in /etc/make.conf.
>
> Yes the reply quotes are annoying, this is the default setting for SM eith
> the exception of a theme change.
>
>>
>>> The indented lines directly below this line still hold true.
>>>
>>>>> There is no doubt about the <correct.current.password>; I use that
>>>>> passwd
>>>>> everyday when logging into Squirrelmail.  As you can see (above)
>>> running the ./chpasswd from the cli shows (incorrect), however running
>>> the
>>> binary
>>>>> via SM > Options > change password, the results are printed in red
>>>>> that
>>> the password was successfully changed.
>>>
>>>> You said it gives an error (...contact administrator...).  Which is it?
>>> Can't remember exactly what I was doing to get that msg; and I'm
>>> currently
>>> unable to reproduce it.
>>>
>>>>Please try to keep your output reports consistent with what version of
>>> the >binary/binaries you are using.
>>>
>>> Everything in this email I have repeatedly reproduced, before sending
>>> the
>>> mail a minimum of 10-times, with a fresh install of the plugin. I hope
>>> that falls under the 'consistent' definition.
>>>
>>> Going to read 'man crypt' Enigma(1) FreeBSD-7.3.  Maybe I'll learn
>>> something.  Let me know if I left any detail out that you need.
>>>
>>>
>>>>> Any attempts to reload or go to
>>>>> another page results in SM directing you to login.  At this point
>>> Attempting to login with what you think is the new.passwd; fails.
>>>>>>> Given this crypt.h issue,
>>>>>> How do you know that is the case?  Supposedly you fixed that.
>>>>> I tried to fix it; didn't work.  What you see above is
>>>>> native/original;
>>> nothing edited, with the exception of removing the '^M' from the
>>> aforementioned file(s).
>>>> The native/original supposedly won't even run at all on your system,
>>>> and
>>> recompiling it fails with an error, so I'm not sure what you've done
>>> now.
>>
>>

-- 
Paul Lesniewski
SquirrelMail Team
Please support Open Source Software by donating to SquirrelMail!
http://squirrelmail.org/donate_paul_lesniewski.php

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
-----
squirrelmail-users mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx
List archives: http://news.gmane.org/gmane.mail.squirrelmail.user
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users



[Index of Archives]     [Video For Linux]     [Yosemite News]     [Yosemite Photos]     [gtk]     [KDE]     [Cyrus SASL]     [Gimp on Windows]     [Steve's Art]     [Webcams]

  Powered by Linux