Custom Query (1145 matches)

Reported by broder, 16 years ago.

Soon, hopefully, machines in various Moira clusters around campus will have "production", "proposed", and/or "development" values for the "apt-release" key in clusterinfo.

debathena-auto-update should know about that key, and adjust /etc/apt/sources.list.d/debathena.list accordingly when it runs.

This allows us to configure cluster machines (and other workstations) to take updates from -proposed and -development without having to ever physically manipulate the machines.

Reported by broder, 16 years ago.

Soon, hopefully, machines in various Moira clusters around campus will have "production", "proposed", and/or "development" values for the "apt-release" key in clusterinfo.

The Debathena installer script should somehow know about this field, and should use it to frob /etc/apt/sources.list.d/debathena.list appropriately at install time.

This allows us to test how a system handles being installed with the packages in -proposed (or -development).

This one is a little trickier than #163 because we don't have debathena-clusterinfo or debathena-getcluster installed when /etc/apt/sources.list.d/debathena.list is written.

It may be that we want to install debathena-getcluster, find out the clusterinfo, and then re-generate /etc/apt/sources.list.d/debathena.list, but even this seems slightly non-ideal, as for a small period packages will only be pulled from production.

Reported by jdreed, 16 years ago.

Debathena machines don't respond to udp/49154 packets correctly.

Querying an Athena 9 machine: $ nc -u w20-575-37 49154 <CR> 1w20-575-37.mit.edui686 ^{C $}

Querying an Athena 10 machine: $ nc -u w20-575-37 49154 <CR> (no output) ^{C $}