FFe: cntlm 0.91 rc6
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| cntlm (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned | ||
Bug Description
Binary package hint: cntlm
This is rather late to request a new upstream pre-release version, but I feel it's worth it for the following reasons:
At my University we are forced to use CNTLM/ntlmaps to make port-80 connections off campus. There was recently a change to the ISA proxies, and ntlmaps no longer works for us. CNTLM hasn't been all-roses, though, and we've had many issues with it, unfortunately these are hard to debug (and most users just restart it, so no LP bugs).
However, with this cntlm RC, we've had significantly less issues. I've been running it for around a month. It still needs to be restarted every other week, but it seems reasonable to try and get this RC into Ubuntu.
I have a version in my PPA that I and others in my lab have been using. I intend to upload something similar.
http://
I've contacted the upstream developer about this, and he says:
> > Are you anywhere close to releasing 0.91?
> I can release any time. It's been tested beyond reason, has many more
> features, proxies support, stand-alone proxy mode, via PROXY + direct WWW
> NTLM(v2) auth and is extremely stable...
He is an Ubuntu user, and will presumably help us should we run into issues with this RC.
There is no upstream changelog, the new changelog entries would simply be:
cntlm (0.91~rc6-0ubuntu1) maverick; urgency=low
* New Upstream pre-release.
-- Stefano Rivera <email address hidden> Wed, 08 Sep 2010 11:39:35 +0200
Related branches
| Changed in cntlm (Ubuntu): | |
| importance: | Undecided → Wishlist |
| description: | updated |
| Dave (foceni) wrote | #1 |
| Scott Kitterman (kitterman) wrote | #2 |
| Changed in cntlm (Ubuntu): | |
| status: | New → Confirmed |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in cntlm (Ubuntu): | |
| status: | Confirmed → Fix Released |
About the new version
~~~~~~~~~~~~~~~~~
There are many new useful features and important rewrites in 0.91. After some silent coding and polishing support for more OS's in early 2010, I spent two months adding new features, testing and fixing based on user requests and feedback. Though I still have some new features on my TODO list, they must wait, because the inferior 0.35.1 has been around for too long and 0.91 is a long time ready. Now I'm going to mark 0.91rc6 stable, because at this point, it's been used in various production environments for half a year without a single issue reported.
Current stable 0.35.1 had some unnecessary limits, had issues with HTTP protocol abuse by certain Java libraries talking through MS ISA and altogether didn't handle some unusual corner cases well. I strongly recommend upgrading to the upcoming 0.91.
Couple of words about 0.35.1 stability
~~~~~~~
Current stats from a random Cntlm server: IBM pSeries 560 (64bit/big-endian AIX6.1, 6x 3.6GHz POWER6 CPU, 8GB RAM). Apart from actual production, it's also used for accessing Internet from some prod-net non-Windows terminals and for downloading huge installation media and updates directly from the clusters.
# uptime
12:13PM up 449 days, 23:04, 6 users, load average: 2.84, 2.45, 2.17
# ps aux | grep [c]ntlm
cntlm 5243088 0.0 0.0 2368 884 - A Jun 02 9:49 cntlm -U cntlm -P /var/run/
# perl -MDate:
Sep 28 - Jun 02 = 118 days
This is the old 0.35.1, mind you: used by tens of users for about 4 months - mainly for http(s) browsing and some permanent, auto-reconnect SSH port forwarding sessions to outside the corporate proxy via Tunnel directives. There were never any restarts required to fix anything.
As I only suspend to RAM, my notebook has currently 49 days uptime (usually ~60) and I use Cntlm in corporate networks heavily: browsing, FTP uploading, Usenet, SSH tunnelling, VPN, VoIP, etc.
If there are cases where users feel that a restart is required, I'd really appreciate some reports and details. Try running Cntlm in verbose mode with a trace file and when a problem occurs, isolate it from the trace and send it to me. When I don't learn about your issue, I cannot help you prevent it.
Sometimes people mail me (or submit a request on SF.net) about some issue and how they're forced to restart, but every single time, after analysing the issue, the cause is confirmed to be the client application and/or the parent proxy's policy.
Regards,
David Kubicek