Custom Query (1145 matches)

Reported by jdreed, 14 years ago.

The rest of the world still relies on this library, unfortunately, so we need to find a way to get it on to the dialups. (Discussions of why programs that still rely on this are Wrong(tm) is out of scope for this ticket.)

Conventional wisdom seems to be to install the amd64 version from here:  http://packages.debian.org/stable/base/libstdc++5

and also download the i386 version from the same place, and use dpkg-deb to manually shove the i386 libraries in /usr/lib32.

We should possibly consider a compatibility package.

Reported by geofft, 15 years ago.

This is a separate issue from removing unwanted packages from debathena-thirdparty: there are a couple of cases in which our metapackages depend on one package and a couple of that package's dependencies, which can be simplified. -dev packages and their non-dev library partners are a good example of this. This should not be a change in practical function of the package.

There are also a couple of cases in which our metapackages depend on one package and a couple of that package's recommendations: for instance, we could replace (almost?) all of the boost packages in thirdparty-libraries with just libboost-dev. This would be a significant cleanup, but a slight functional change. It's worth considering if there are reasons to keep these packages as hard dependencies; one technical reason to do so is that recommendations are never resatisfied if they happen not to be satisfied when the package is first installed (see #373). See that ticket and also #372 for discussion of making everything in -thirdparty recommendations, which, if implementable, would make this option clearly okay.

Reported by andersk, 15 years ago.

[Not entirely a Debathena bug, but this is the most convenient place to keep track of it.]

As an experiment, I modified my Kerberos principal to have only a triple-DES enctype using kadmin:

kadmin:  cpw -e des3-hmac-sha1:normal andersk

This works out fine from a Kerberos client perspective:

• kinit -5, kinit -45, and krb524init all works, which allows me to use any Kerberized service as normal, including krb4 Zephyr and krb4 IMAP. krb4 is now effectively disabled
• kinit -4 no longer works (kinit(v4): Kerberos principal unknown), which is expected because Kerberos IV can only use a single-DES key to encrypt my TGT. But that is okay because kinit -45 or krb524init replace this functionality. krb4 is now effectively disabled
• aklog and AFS works fine.

However, it exposed some problems with various password-authenticated services:

•  ca.mit.edu does not allow me to generate a new MIT certificate. FIXED.
• The PO servers do not allow me to log in over IMAP using a password. (Kerberized IMAP still works.) I receive this error using imtest: FIXED.

  $ imtest -s -m login andersk.mail.mit.edu
  …
  Please enter your password:
  C: L01 LOGIN andersk {9}
  S: + go ahead
  C: <omitted>
  S: L01 NO Login failed: authentication failure
  Authentication failed. generic failure
  

• I cannot log in to  Webmail, presumably as a consequence of the above: “Login failed.” FIXED.
• I cannot log in to  Touchstone services using a password (though certificate and Kerberos authentication still work): “Error: Please enter a valid username and password. Click help for assistance.” FIXED.
•  Outlook Web Access works fine.
• I cannot log in to the  MITnet VPN (vpn.mit.edu): “Login error.” FIXED.
• I cannot log in to  Brightmail: “Invalid user name or password. Please try again.” FIXED.
• I cannot log in to Windows after starting the Citrix ICA Client from  Citrix MetaFrame XP: “The system could not log you on. Make sure your User name and domain are correct, then type your password again. Letters in passwords must be typed using the correct case.” GONE. The new citrixapps.mit.edu works, however.
• I cannot log in to the MIT SECURE wireless network:
• outgoing(-auth) does not accept passwords auth from principals with strong keys, though it does accept GSSAPI auth, much as the PO servers. FIXED.

Given that single-DES is critically weak, is disabled by default in current releases of Kerberos, and will be removed entirely in future releases, we should talk with network and try to get these little problems worked out sooner rather than later.

Solution

In at least one case (ca.mit.edu), the problem was that the server’s /etc/krb5.conf had the line default_tkt_enctypes = des-cbc-crc. This line should be removed. Since we think this misconfigured /etc/krb5.conf has been copied to many MIT servers, that’s probably all we need to do to fix most or all of these problems.