| Summary: | Regression from 3.0.1-6 to 3.0.1-9 in MSN logins | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pekka Pietikäinen <pp> |
| Component: | bitlbee | Assignee: | Robert Scheck <redhat-bugzilla> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | awilliam, lpoetter, mcepl, mcepl, redhat-bugzilla, rzhou |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | bitlbee-3.0.3-5.fc16 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-24 22:10:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Self-compiled 3.0.2-1 fails, self-compiled 3.0.2-1 with all mentions of Fedora 15 in the spec file changed into 16 (effectively disabling the systemd patches) works... I hit this too - I also had to run bitlbee from a console as I could not get systemd to start it whatever I tried, it hit file descriptor and bind permission errors. So I also did a self-build which reverted all the systemd changes, to make it run via xinetd, and it works fine. If MSN doesn't work and everything else (Jabber, AIM, ICQ, etc.) do, then we are in trouble with 3DES encryption again (MSN is the only protocol which uses 3DES for authentication). See bug 655736 and bug 666022 for some inspiration. Ricky, any ideas? CCing Lennart too, since there's a difference here between running it via xinetd and via systemd. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Adam, wassup? lennart, see above: it seems bitlbee was patched to start via systemd rather than xinetd, but it doesn't work right for me or pekka. for both me and pekka, if we revert all the systemd patching and make it use xinetd again (with no changes to bitlbee itself), it works great. so there's something up with the systemd implementation. matej: for me, I couldn't make it work at all via systemd, it only works when started directly or via xinetd. (In reply to comment #7) > matej: for me, I couldn't make it work at all via systemd, it only works when > started directly or via xinetd. Just to make myself clear ... I have just removed myself from bitlbee in pkgdb. I really don't have time to manage yet another package which I actually don't use much (my tendency are in other direction ... proxying IRC to Jabber, so I can use Jabber for everything). Also, the issue with systemd is covered by bug 662289, this one should be probably kept for MSN problems. No idea about bug 705096 ... most likely another SELinux issue, but given we don't have any information from the reporter, it's hard to tell. I am really sorry, that I haven't managed to fix bug 666209, but file transfers themselves in bitlbee are currently such mess, that even wilmer doesn't know how to configure it properly. So Long, and Thanks for All the Fish! Note that systemd is actually compatible with inetd-style socket activation too. So if you can make it work with xinetd, then systemd should work fine with that. I am not sure what bitlbee actually is, so I am probably not the best one to ask to comment on the bitblee systemd integration. Lennart, in the past bitlbee was configured for xinetd using this configuration file: http://pkgs.fedoraproject.org/gitweb/?p=bitlbee.git;a=blob;f=bitlbee.xinetd May you provide me (as the package maintainer) a proper systemd configuration, please? You developed that systemd thing, so there's no better one who could help me with the systemd thing. Otherwise, I'm going to fall back to xinetd till RHEL 7 or so... We ship an IRC proxy in RHEL? interesting... Try something like the following. It's untested, but should work. in bitblee.socket: <snip> [Unit] Description=... [Socket] ListenStream=[::1]:6667 BindIPv6Only=both Accept=yes [Install] WantedBy=sockets.target </snip> in bitblbee@.service: <snip> [Unit] Description=... [Service] ExecStart=/usr/sbin/bitlbee StandardInput=socket [Install] Also=bltlbee.socket </snip> lennart: bitlbee isn't an IRC proxy exactly; it's an IM-to-IRC gateway. It runs an IRC server, and connects to various IM accounts (MSN, AIM etc); it turns the IM traffic into IRC traffic, so you can then connect to the Bitlbee server and access all your IM accounts through your IRC client right alongside all your other IRC traffic. We also package bip, which *is* an IRC proxy; I use bitlbee and bip together, so the bitlbee IRC traffic itself is proxied through bip. Yay complexity. (I don't know whether bip or bitlee is part of the RHEL package set; I'd guess not and they're in EPEL, but I don't know.) I'll try and find time to test your suggestion and put it into the package if it works - thanks. It's not at the top of my list, though, as running it through xinetd works right now, and all I need is for it to work, so...it doesn't get super high priority... Any progress on this bug with bitlbee-3.0.3-1.fc16.x86_64? Please, complain in bug 705096, and I will try to finish everything what's missing there. 3.0.3-1.fc15 fixes this bug -> closing for the record, 3.0.3-4 is working fine here too, by the looks of it. Should -3 or -4 go to F15 as well? Looks like the fixes between -1 and -3 would be relevant there. I rebuild -4 for F15 for my own use. bitlbee-3.0.3-5.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/bitlbee-3.0.3-5.fc16 bitlbee-3.0.3-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/bitlbee-3.0.3-5.fc15 bitlbee-3.0.3-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. bitlbee-3.0.3-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: I recently upgraded to F15, and bitlbee stopped working. First it was SELinux (I think this got already reported as #666182 and is being worked on) require { type ircd_port_t; type bitlbee_t; class capability dac_override; class tcp_socket name_bind; } #============= bitlbee_t ============== allow bitlbee_t ircd_port_t:tcp_socket name_bind; allow bitlbee_t self:capability dac_override; Solving that (setenforce 0 or the above) MSN logins still didn't work (3.0.1-9.fc15 and 3.0.2-1.fc16 tested): 12:55 <@root> Trying to get all accounts connected... 12:55 <@root> msn - Logging in: Connecting 12:56 <@root> msn - Logging in: Connected to server, waiting for reply 12:56 <@root> msn - Logging in: Transferring to other server 12:56 <@root> msn - Logging in: Connected to server, waiting for reply 12:56 <@root> msn - Login error: Error during Passport authentication: (null) 12:56 <@root> msn - Logging in: Signing off.. 12:56 <@root> msn - Logging in: Reconnecting in 900 seconds.. Downgrading to 3.0.1-6.fc14: 12:58 <@root> Trying to get all accounts connected... 12:58 <@root> msn - Logging in: Connecting 12:58 <@root> msn - Logging in: Connected to server, waiting for reply 12:58 <@root> msn - Logging in: Transferring to other server 12:58 <@root> msn - Logging in: Connected to server, waiting for reply 12:58 -!- mode/&bitlbee [+C] by root 12:58 <@root> msn - Logging in: Authenticated, getting buddy list 12:58 <@root> msn - Logging in: Logged in I suppose that could be SELinux too, but didn't see anything relevant in the audit logs... Continuing my investigations and will report if I find anything relevant, probably will start with compiling a 3.0.2-1 pre-systemd and continue from there.