[gshenaut]

Well, I didn’t have much success. I can change the default route by hand, but establishing it in /etc/rc.local doesn’t stick like it does for other static routes.

I wonder: why there is this insistence on there being a "primary interface" anyway? Why does the interface with the default route also have to be the OD master? They’re just IP addresses, after all. I see no logic in it.

Next I’m going to see if I can set up a nonstandard default route using the launchd system.

Greg Shenaut

[gshenaut]

Yes, that’s about what I had concluded. But at some point, I do need to add those aliases.

When you say “highest priority interface that is active”, is there a specific meaning you had in mind ?

I think this is the key here. It’s not just when promoting, because if I do the promotion without aliases, I get the main (non-aliased) interface, but if I do other WGM things (e.g., add a user) after the promotion, but with the aliases put back, WGM still “wants” to use one of the aliases. Could “highest priority” means something like “highest IP address”, because this happens to be the case.

One other question, if you don’t mind. I’ve been adding IP aliases by putting them in /etc/IPAliases, which seems to work OK. You mentioned doing it via the GUI or with networksetup. What are the trade-offs on these three different methods of adding IP aliases? Also, I looked pretty hard, but I haven’t found a good step-by-step of adding IP aliases with the GUI (and I never heard of networksetup.

Thanks,
Greg Shenaut

[gshenaut]

I continue to plod along with this. I noticed that /etc/krb5.keytab contained the string "pirouette", the alias that keeps showing up in WGM, so I extended the previous idea: I demoted OD, removed krb5.keytab, commented out the aliases, rebooted, promoted OD, added a user & group using WGM, put back the aliases, and rebooted. After I did this, krb5.keytab contained only the correct, main hostname.

But when I then fired up WGM to add another user, the faux name showed up again as before in the window title, and the false name was suggested as the mail server for the new user (I typed in the correct name). I also noticed that in the "Account Summary" of both users, the "Location" field contained the alias, not the correct main name:

pirouette.ucdavis.edu/LDAPv3/127.0.0.1

I ran strings(1) on a file called /var/servermgrd/servermgr_info.lock, because when I xargs|grep’ed the entire filesystem, it was one of the files that contained "pirouette". But it contains all of the aliases and their addresses in ascii, so it isn’t the source of the problem.

Greg Shenaut

[gshenaut]

Progress report: I finally tried commenting out the three aliases in /etc/IPAliases, rebooted, and then in an unaliased state promoted the server to OD Master. This time everything seemed smooth: the suggested realm matched the server, and the Workgroup Manager window also reflected the same host.

I put back the aliases and rebooted again. Now, the kerberos realm stuff still seemed OK, but the WGM windowflipped to the same alias as before when I connected to the server.

Before I did this, I searched high and low in the system for some configuration file somewhere that identified the alias incorrectly as the primary address, and I couldn’t find anything (for either the name or the IP).

I’m beginning to think that some of the Server Admin programs use some secret algorithm to figure out the name of a server they are administering on the fly. It may be that I will be able to ignore the WGM weirdness.

Greg Shenaut

[gshenaut]

Providing a little more information. I noticed that the Include line in the main httpd.conf file includes sites/*.conf. Ab initio, the directory contains one file for each virtual host, plus a file called virtual_host_global.conf. The individual site files’ names are of the form <index>_<ip address>_<port>_<site dns>.conf, where index is a 4-digit zero-padded index, and ip-address, port, and site dns are what you would expect.

I put the customization into a file called 00000-zzz.conf and restarted apache. After a bit of tweaking, it seems to work. I also tried calling the file zzz.conf (so it would be read after the Apple-generated virtual host files), and that didn’t seem to work, although I admit I didn’t try too hard to figure why. My guess is that it’s the first definition of each variable that counts and redefinitions are ignored, but I couldn’t find anything in the documentation that dealt with this.

Then I went into System Admin and made a minor change in the Web module and saved it. Sure enough, the entire sites directory was rewritten, and my customization file disappeared. I had to copy it back in and restart apache.

So, it may be possible to use this band-aid method, but it is fragile. For the moment, each user has host-specific personal websites, but I don’t know yet if I broke anything by doing it.

I’d still appreciate any knowledge about this anyone has to share.

Greg Shenaut

[Author]

Posts