[EA]

[QUOTE][u]Quote by: macdummy[/u][p]

I guess more than us getting the response that “you can’t do it” I am hearing that “Apple doesn’t do it that way”. Which is fine. However, if they do something different and it creates a bigger headache rather than bennefit I want to know the truth. The biggest thing is the Domain issue. Can we create a domain on the XServe? The other part is network logins instead of local user acounts. The whole idea is to get to centralized management. Right now it is all locally managed and is becoming a nightmare.

Thanks for your post, and your williness to respond with your knowledge.[/p][/QUOTE]

Yes, you can create a Windows domain on an XServe, with the XServe serving as the Primary Domain Controller for your domain. The level of functionality will lag far behind those of an Active Directory domain for your Windows clients, but it can be done. You will lose out on things like Group Policies for the Windows clients. This is why the Active Directory piece gets implemented if it isn’t already there. OD can use AD for authentication, but not vice versa, so you put yourself in a position of the Windows Active Directory server being the canonical source of authentication information for your enterprise.

If you want to do a purely Open Directory implementation, authentication can be managed centrally using the Open Directory LDAP/Kerberos combination (and, really, just the LDAP portion can handle this). At my place, I have Windows, Linux, and Mac servers and clients authenticating against Open Directory hosted on OS X Server, as well as web applications like a wiki, databases, and WebDAV shares. Network logins are part and parcel of having users in the Open Directory LDAP directory. Just set the users’ home directories properly.

[EA]

One trick that might help is to set the users’ home directories to “None” in Workgroup Manager, save that, then set the new home directory, then save that. Although I have never seen it documented in print, I have gotten this advice in dealings with Apple in the past. Somewhat nonsensical, but it seems to work.

You can also check on the OD Replica to make sure that the home directory record is pointing to the right place on the replica using Workgroup Manager or dscl on the command line:

dscl /LDAPv3/127.0.0.1 -read /Users/$i NFSHomeDirectory

where $i is the username in question.

[EA]

In /etc/amavisd.conf, Section V covers white/blacklisting of sending email addresses. It can be done with a list of email addresses in the file as an ACL (an example being given in the commented line that begins: #@whitelist_sender_acl =), a regular expression or series of regular expressions, or a reference to an external file (see the example line beginning #read_hash(\%whitelist_sender) which is then converted to a hash for address testing.

Starting out, just creating an ACL list in the body of the amavisd.conf file should be enough. All you have to do is change:

[code]# @whitelist_sender_acl = qw( .example.com );
[/code]
to (use the sender’s real domain name rather than sendersdomain.com)

[code] @whitelist_sender_acl = qw(sendersdomain.com);
[/code]
And restart at least amavisd, although it is probably easier to do a:

[code]serveradmin stop mail && serveradmin start mail
[/code]
This should exempt any email from the sendersdomain.com domain from the SPAM checks.

[Author]

Posts