Created attachment 717380 [details] Output of pidgin -d showing the failed authentication. Description of problem: - I was running purple-sipe-1.14.1-1.fc17.x86_64 and was successfully connecting to the office's OCS Server with Pidgin. - A week ago, purple-sipe-1.15.0-1.fc17.x86_64 was rolled out, and since then I have been unable to connect. - After erasing purple-sipe-1.15.0-1.fc17.x86_64 and re-installing purple-sipe-1.14.1-1.fc17.x86_64.rpm I am again able to connect to OCS. - If I upgrade again to purple-sipe-1.15.0-1.fc17.x86_64 it again fails. Version-Release number of selected component (if applicable): purple-sipe-1.15.0-1.fc17.x86_64 pidgin-2.10.5-1.fc17.x86_64 How reproducible: Always. In fact, I have the same problem on my home PC as I do on my work laptop. Steps to Reproduce: 1. Upgrade from purple-sipe-1.14.1-1.fc17.x86_64 to purple-sipe-1.15.0-1.fc17.x86_64 = FAIL to connect 2. Erase purple-sipe-1.15.0-1.fc17.x86_64 and reinstall purple-sipe-1.14.1-1.fc17.x86_64 = SUCCEED in connecting Actual results: The pidgin -d logs show the certificates are accepted, but the SIP REGISTER fails with: (02:12:56) sipe: ERROR: sip_sec_create_context: failed to acquire credentials. (02:12:56) connection: Connection error on 0x24e8400 (reason: 2 description: Failed to authenticate to server) I have attached the full log from start to finish. I have renamed my company's domain name. Expected results: I expect to sign into OCS and be able to use it, as happens when the older purple-sipe is installed. Additional info:
PLEASE PLEASE PLEASE read the update notice. Package maintainers *DO* write them for a reason: to inform the user about important changes. *** This bug has been marked as a duplicate of bug 922895 ***
Thank you for pointing that out. Having SSO selected was the issue - as was set by default by the older version I had been running. ON A SIDE NOTE: I keep my system up to date using "yum update". The problem is that I *NEVER* see the update notices. In fact, when you mentioned the update notice, the only way I could see it was to install yumex and specifically LOOK for the notice. Furthermore, when I run my update once a week, I can get 100 items being updated. I would sit forever if I had to verify the text in every update. Whilst I do appreciate and understand the comment that we should read the update notes, please also understand that from an end-user's point of view, we expect that ordinary package updates are going to be bug fixes, but not that they would change the fundamental way that the package works. In this case, knowing full well that hundreds of users of the package have SSO selected, the package was changed to work differently. As an end-user, I would rather have had a pop-up explaining this when I next ran pidgin, instead of it just not working and me blaming my IT Department for breaking things. And with them being Microsoft people they don't like or support me being on Linux. All I ask is that the impact of changes also consider the end-user who doesn't get to see a one-line message in an update notice. So, in your opinion, how should I run my updates to catch such a thing in the future?
I understand your frustration. BUT: please also try to understand the developer point of view. I had the choice between - keep the old messy buggy unmaintainable code where the SSO decision is taken randomly and differently in multiple places plus the wrong default for most new users, BUT save the user to having to change his account setting after upgrading OR - have maintainable error-free code with SSO handled the same way everywhere, BUT the user has to check his account settings once after upgrade. I took the latter approach and documented the decision in all places (release note, FAQ page, SourceForge News item, download page, DEB/RPM packaging changelogs). So in your opinion: what else should a developer do, when such changes are necessary? As for handling updates, this is my approach: - regularly read the package-announce list (http://lists.fedoraproject.org/pipermail/package-announce/), especially before upgrading and to monitor Fedora features that are important to me - if I have a problem with a feature after upgrading, then I have a lot of options; * check the above page for updates (shows update note) * check yum history if and when the package was updated on the system yum -C history info pidgin-sipe * check the package changelog rpm -q --changelog pidgin-sipe | head * check the package on the Fedora updates page (comments on updates from other users might be helpful) https://admin.fedoraproject.org/updates/pidgin-sipe * check the projects home page: (especially look for a FAQ page) $ rpm -qi pidgin-sipe | fgrep URL URL : http://sipe.sourceforge.net/ * as a last resort Google e.g. the error message or the project name All of the above does not require involvement of the IT department or installing extra SW on the system.
Thank you SO much for the reply. And likewise, I also understand your position. I think you covered all your bases, just that I missed checking there. Based on that I have to admit, I did not look properly. (I beg your forgiveness!) Do people USE SSO? In most cases I think people log onto Linux with a local account, and run Pidgin with stored credentials - specific to Exchange / OCS. So I guess the other way around could be to remove SSO globally on upgrade but then you probably still have potential unhappy users. So the proverbial rock and a hard place. If I may add my 2 cents worth though - when it fails we always recheck our settings. Possibly under the SSO checkbox you could have made mention as a comment that enabling this means that the password settings are ignored. Your thoughts? As for your troubleshooting approach - I *LIKE* it. There are things there I didn't think of looking at. I have saved that and will refer to it next time. You didn't waste time putting all that in there. If I may: one last question ... in bug 754395 a number of users have commented that Empathy / telepathy-haze stopped working with the SIPE plugin. I in fact switched from Empathy to Pidgin for this very reason. (And the only reason I originally switched from Pidgin to Empathy was because Fedora was forcing Empathy to be the standard IM client - go figure.) Empathy is a bit of a dog because it needs me to get certificated from Windows users and install them before it will work. I digress ... are you familiar with the problem, or do you have any opinion or things I could try? Creating a new account (no SSO) it still doesn't work. And it too just stopped at the beginning of the year. Finally, thank you many times over for you efforts in the sipe plugin. Me and many others are ever so grateful to you for your time. It's people like you who make Linux usable in the workplace. Thank you.
(In reply to comment #4) > Do people USE SSO? In most cases I think people log onto Linux with a local > account, and run Pidgin with stored credentials - specific to Exchange / > OCS. So I guess the other way around could be to remove SSO globally on > upgrade but then you probably still have potential unhappy users. So the > proverbial rock and a hard place. *YES* they do: On Windows: almost all users that have local accounts (i.e. no BPOS/Office365) On UNIX/Mac: all Kerberos users (what's the point of using Kerberos, if you are not going to use SSO?) Implementing full Kerberos support for HTTP connections was actually the trigger for the code cleanup that lead to the user-visible behaviour change for the SSO flag. And for new accounts it is *OFF*, so no problems there. > If I may add my 2 cents worth though - when it fails we always recheck our > settings. Possibly under the SSO checkbox you could have made mention as a > comment that enabling this means that the password settings are ignored. > Your thoughts? Actually it is only Pidgin which has this problem. Because Adium/Miranda developers have more control over the UI, i.e. they can put the SSO flag *WITH* the Login/Password fields *AND* use it to disable/enable them. > If I may: one last question ... in bug 754395 a number of users have > commented that Empathy / telepathy-haze stopped working with the SIPE > plugin. That is news to me. To be frank I have a dummy telepathy-haze installed on my development machine, so that the mandatory empathy -> telepathy-haze dependency doesn't interfere with my SIPE telepathy backend development (*NO* that is not ready yet :-) If I have time I'll try it out myself.