Custom Query (196 matches)

Check for the error message:

[23/Sep/2010:15:18:56 -0400] NSMMReplicationPlugin - agmt="cn="GSSAPI
Replication to whole-enchilada.mit.edu"" (whole-enchilada:389): Replica has a
different generation ID than the local data.

which indicates something has gone wrong with replication. This message does not appear to be picked up by our existing MMR checks.

Old text: In the nsds50ruv attribute, replication agreements record a "generation ID" which prevents two masters initialized from different sources from attempting to overwrite each other and cause a mess. Unfortunately, this safety mechanism also means that replication doesn't work, and furthermore, while this will result in a lot of spew to the LDAP error log, this won't show up in the usual status field. We should check that all of the replication generations on our servers are consistent.

We should monitor LDAP replication to make sure all the servers can talk to all the servers. We can probably adapt ​http://directory.fedoraproject.org/wiki/Howto:ReplicationMonitoring to do what we want.

(Imported from ​help.mit.edu #432614.)

andersk:

While upgrading packages on scripts4, I received strange errors that I think can be attributed to our shared /tmp directory. We need to find a better solution. (This has made me uncomfortable for a long time, I'm just adding this to our todo list.)

andersk:

This is now one of ghudson's selling points for cobwebs: http://scripts.mit.edu/~ghudson/blog/?p=13 so we should fix it as soon as possible. :-)

Here are some options I see:

1. Keep the NFS solution and try to hack something to solve the failover problem.
2. Unshare /tmp and stop pretending we only have one server.
3. Unshare /tmp, but move PHP sessions and other similar data to some other shared directory (involving one of the other solutions).
4. Put /tmp in AFS somewhere.
5. Experiment with Coda, which I believe is supposed to support what we need.

Thoughts?

I think I'm happiest with either 2 or 3+5. Did we ever find specific examples of popular scripts that depend on a shared /tmp?

jbarnold:

I think that we previously found that some scripts cache data in /tmp, and they expect this data to be either not-there or entirely-up-to-date; they do not expect it to be in an old state.

I think that #2 might hard to get right.

I've considered putting /tmp into AFS, and that option might be the best one.