Custom Query (1145 matches)

Reported by broder, 15 years ago.

Right now we're still enabling libpam-krb524 on Squeeze and Karmic. Since libpam-krb524 configures itself as optional, this turns out to not be deadly, but we should still kill it on those versions.

Reported by cgao, 15 years ago.

I was following the steps  http://www.mit.edu/~gracewoo/utils/vpn/index.html But it doesn't work, for the patch is in old version.

Then I was following the steps here  https://debathena.mit.edu:444/trac/ticket/77

1. Install network-manager-vpnc.
2. Click the NetworkManager applet → VPN Connections → Configure VPN… → Add.
3. For Choose a VPN Connection Type, select Cisco Compatible VPN (vpnc).
4. Fill in Connection name: MITnet (or whatever), Gateway: vpn-public.mit.edu, Group name: MIT, Group password: [the super-secret VPN password], Username: [your Athena username], and click Apply.
5. Now you can connect by clicking NetworkManager applet → VPN Connections → MITnet. You will be prompted for your Athena password (or you could have saved it in step 4).

But what is [the super-secret VPN password]? I leave it blank and this method still does work? Where am I wrong?

Thanks so much

Reported by broder, 15 years ago.

Right now packages built by the autodebathenifier are going into proposed, and require a manual move by a maintainer to move into production. In theory, this is to prevent a successful build of a mysteriously broken package from screwing everything.

I don't think this makes sense. I think we should be moving autodebathenified packages (and especially openafs modules) immediately into production. We don't perform any testing of autodebathenified packages before making the move. Nor do we have any automated infrastructure that does it for us. Nor do we seem to have made any progress at all in writing such an infrastructure.

And I'm not even clear what sort of mysterious bug we're concerned with. To the autodebathenifier has been running as part of the Athena 10/Debathena infrastructure for well over a year now, and it's never failed in a way that caused it to upload a broken package.

All this extra step is serving to do is create more work for debathena-root without any apparent gain, and it causes additional delays for packages that users may be expecting. Therefore, I'm going to plan to reconfigure the autodebathenificator to upload directly to production in a week.