9 Replies Latest reply: Jan 15, 2013 10:59 AM by Jonathan2001 Branched to a new discussion.
Jonathan2001 Level 1 Level 1 (0 points)

We're migrating our home server (email, web, file sharing, ...) from an older RedHat Linux machine to a fast new Mac Mini running OS X server, to complement our growing number of Mac OS machines at home.

 

I'm trying to figure out how to best configure our system. I've used the Server.app and Workgroup Manager to configure a bunch of the basics, and believe I will be pretty happy using the GUI tools to manage file sharing, and some of the basic services.

 

I have relatively complex settings for postfix/dovecot and apache httpd from my linux server that I would like to migrate in a reasonable way. I am a little confused about how the GUI interacts with the underlying settings within the MacOS server for the built-in mail and web servers.

 

I've seen some people reference commands like "sudo serveradmin settings XYZ" however I haven't found a complete reference manual describing all the potential commands, and it feels like a hacky approach. (Is there a reference manual for all settings?) How do commands like these relate to plist files floating around on the server? Is this documented somewhere?

 

I think I would be more comfortable directly editing config files and then restarting services...I think I could more or less reuse my more complex postfix or apache rules. A quick look around suggests they are in /private/etc. Is that correct? If I wish to edit these directly, what is the right way to restart services? If I edit them directly, will it mess up Server.app GUI? Will it be compatible with issuing individual "sudo serveradmin settings mail:XYZ" commands? Will it make it more difficult to upgrade to OS X Server 10.9 in the future?

 

More broadly, I guess I'm interested in best practices for tuning OS X server to meet my needs...


OS X Server
  • 1. Re: Moving from Linux to OS X Server
    pterobyte Level 6 Level 6 (10,910 points)

    If you are used to edit configuration files, then it will certainly be easier for you to continue doing so. This gives you way more control than Server.app or serveradmin.

     

    Manual settings are preserved if you are careful about where you place your changes. Most configuration files that Server.app touches, have commented sections which tell you what you shouldn't touch.

     

    As a rule of thumb, wherever supported, don't modify the main config file, but put your changes into a linked/included file. Apache and Dovecot can handle that well. For Postfix, put your changes at the end of main.cf. Postfix will always keep the last instance of a parameter it reads.

     

    Paths:

    Mail config (Postfix, amavisd, etc): /Library/Server/Mail/Config

    Postfix: /Library/Server/Mail/Config/postfix

    Dovecot: /Library/Server/Mail/Config/dovecot and /Library/Server/Mail/Config/dovecot/conf.d

    Apache: /Library/Server/Web/Data

    For Apache it may be worth considering webapps. See:

    man webappctl

    man webapp.plist

     

    HTH,

    Alex

  • 2. Re: Moving from Linux to OS X Server
    FromOZ Level 2 Level 2 (405 points)

    "We're migrating our home server (email, web, file sharing, ...)" welcome, you're in a large demographic doing very similar thing.

     

    "from an older RedHat Linux machine " Gentoo for me

     

    For a complete (?) listing of all OS X related (?) mail settings you can run this command.

     

    sudo serveradmin settings mail

     

    you will see it lists settings for postfix, imap (dovecot).

     

    Settings can be changed by using this method and there are settings there, for example,

     

    mail:postfix:greylist_disable = no

     

    which are not in main.cf, which Postfix config file is it defined in??

     

    I agree with you that it is a bit of a 'mishmash' of places where one updates config/settings — and the functionality exposed via the UI might as well not have a UI for what it provides. And you do have to be careful what lines (for example in main.cf) you change because some Apple script can come along and clobber it. For example this command (which I believe is widely used in Postfix)

     

    smtpd_client_restrictions = 

     

    is in the 'Apple' section, will an Apple config setting script overwrite what I put in there?!?

     

    It is a bit of a challenge and I am also working on building up my knowledge of Posfix (was using Exim) to get it to do all I want. For example I want to have greylisting, seems nice feature, but that runs into problems with Google's annoying habit of not using the same mail server name to retry the mail sending after temp reject. So I am trying to whitelist Google's servers by any means - ideally MX server CIDR address ranges... or host domain name, or even domain of sending person. No luck so far don't know if you have any pointers in that area?

     

    What I am doing for the whole documentation thing as I set everything up — mail, certificates, web, Open Directory, Calendar, Contacts — is writing down everything I find out.

     

    This site has helpful info and not just on mail area

     

    http://krypted.com/mac-os-x/setting-up-the-mail-service-in-mountain-lion-server/

  • 3. Re: Moving from Linux to OS X Server
    FromOZ Level 2 Level 2 (405 points)

    Also one tip — if you want some OS X Server specific documentation from Apple you could download from the Apple support site all the Snow Leopard docs. That was the last version where they made available substiantial documentation. Some systems and apps have changed but it is helpful information and covers some apps that haven't changed.

  • 4. Re: Moving from Linux to OS X Server
    Jonathan2001 Level 1 Level 1 (0 points)

    Thanks, I do feel most comfortable reading the man pages and editing the files directly. A few follow-up questions as I try to configure postfix. I'm editing via "sudo nano /Library/Server/Mail/Config/postfix/main.cf", and have put my settings at the end after the (APPLE) section such that the server app ideally doesn't clobber my settings.

     

    Potential issue: I'm still a little confused about the mishmash of configuration files. There's a seperate /etc/postfix/main.cf file (symlinked to /private/etc/postfix/main.cf). It seems to point to config_directory /Library/Server/Mail/Config/postfix. Any idea what this /etc based file is for? My conclusion thus far is that it is installed as a part of the OSX **non-server** base install for the postfix that is used by the "desktop OS" to allow mails to be sent. Is this accurate?

     

    Primary issue: I want to make sure that I am accurately configuring postfix. I tried changing the reciipient_delimiter setting to see if I can get the server to propigate the settings. Here's what I've done so far -

    1) edit the /Library/.../main.cf file

    2) sudo serveradmin stop mail

    3) sudo serveradmin start mail

    4) run "postconf -n" ... and yet I don't see the change reflected.

    If I run "postconf -c /Library/Server/Mail/Config/postfix -n" it looks like the changes are reflected, but without going through some tests against the server on port 25 it's hard for me to debug what's going on.

     

     

    Potential issue that I expect to see soon: Several of the settings that I'd like to change are located in other postfix configuration files - such as the "aliases" file. On other machines I've run commands like "newaliases" to compile new alias.db files, which typically will go into their default hash db location within etc -- like /etc/aliases.db. It would appear that there aren't any custom settings for this defined in either the /Library/.../main.cf file so it would seem like my machine would continue with the default setting. But doing this feels wierd since the OS X Server has gone to great lengths to keep config settings in the /Library/... location.

     

    Another best practice question: on other machines with postfix it made sense to deliver spooled mail into Mailbox files located within /Users/username/Mailbox rather

    than to a centrally spooled location. I'm somewhat inclined to do that just for transparency sake but perhaps this is a place where Apple and Server.app know best for their enviornment. Thoughts?


  • 5. Re: Moving from Linux to OS X Server
    pterobyte Level 6 Level 6 (10,910 points)

    There's a seperate /etc/postfix/main.cf file (symlinked to /private/etc/postfix/main.cf). It seems to point to config_directory /Library/Server/Mail/Config/postfix. Any idea what this /etc based file is for? My conclusion thus far is that it is installed as a part of the OSX **non-server** base install for the postfix that is used by the "desktop OS" to allow mails to be sent. Is this accurate?

    Yes, you are correct.

     

    Primary issue: I want to make sure that I am accurately configuring postfix. I tried changing the reciipient_delimiter setting to see if I can get the server to propigate the settings. Here's what I've done so far -

    1) edit the /Library/.../main.cf file

    2) sudo serveradmin stop mail

    3) sudo serveradmin start mail

    4) run "postconf -n" ... and yet I don't see the change reflected.

    If I run "postconf -c /Library/Server/Mail/Config/postfix -n" it looks like the changes are reflected, but without going through some tests against the server on port 25 it's hard for me to debug what's going on.

    The correct Postfix config files are in /Library/Server/Mail/Config/postfix so postconf -c /Library/Server/Mail/Config/postfix -n is the way to go.

    Sometimes it may seem to you that changes are reflected also in /etc/postfix/main.cf, but that is simply because serveradmin periodically copies /Library/Server/Mail/Config/postfix/main.cf to /etc/postfix/main.cf

     

    BTW: Changes in main.cf do not require restarting of al mail services. Simply use:

    sudo postfix reload

     

     

    Potential issue that I expect to see soon: Several of the settings that I'd like to change are located in other postfix configuration files - such as the "aliases" file. On other machines I've run commands like "newaliases" to compile new alias.db files, which typically will go into their default hash db location within etc -- like /etc/aliases.db. It would appear that there aren't any custom settings for this defined in either the /Library/.../main.cf file so it would seem like my machine would continue with the default setting. But doing this feels wierd since the OS X Server has gone to great lengths to keep config settings in the /Library/... location.

    Instead of postalias, use postalias /Library/Server/Mail/Config/postfix/aliases

    (newaliases is only needed for sendmail backwards compatibility)

     

     

    Another best practice question: on other machines with postfix it made sense to deliver spooled mail into Mailbox files located within /Users/username/Mailbox rather

    than to a centrally spooled location. I'm somewhat inclined to do that just for transparency sake but perhaps this is a place where Apple and Server.app know best for their enviornment. Thoughts?

    You could change this if you like, but it doesn't really make a difference and you are correct Server.app would go bonkers. Also, putting mail in users directories made sense in the "old days" where users would actually log onto the server and be restriced to their home directory. Nowadays users simply access mail or other services through some kind of front end application.

     

    HTH,

    Alex

  • 6. Re: Moving from Linux to OS X Server
    Jonathan2001 Level 1 Level 1 (0 points)

    Alex: Thanks, this has been consistently good advice. I've set things up for postfix at the end of the file, backed it up, and then let my settings override Apple where appropriate. I copied the contents of the 10-mail.conf file and created a 50-jonathan.conf file to override settings that I need.

     

    For the benefit of others, this is roughly what I'm going with for now, since I'd letting apple deliver new mail into the (opaque) Maildir format so the server doesn't go totally bonkers, but also provide imap access to ~/mail mbox files. Due to dovecot limitation, I cannot mix/match maildir INBOX and personal mbox files by overriding mailbox_location ... so I'm using namespaces.  And since I'd like the mbox files to be at the root level I cannot use the implicit root private namespace. So I'm listing two:

    -----------

    namespace {

      type = private

      separator = /

      prefix = APPLE_INBOX/

      inbox = yes

      #stolen from apple. ideally i wouldn't have to use this.:

      location = maildir:/Library/Server/Mail/Data/mail/%u

      hidden = yes

      list = no

    }

     

    # I think I'd prefer default namespace to be all "mail" that's not the inbox.

    namespace  {

      type = private

      separator = /

      prefix =

    # bad: location = mbox:~/Documents/mail -- OSX and dovecot evidently cannot expand ~ to the root directory.

    # error in logs was like  --->  Can't expand ~/ for mail root dir in: ~/mail

      location = mbox:/Users/%n/mail

      inbox = no

      hidden = no

      list = yes

    }

    service imap {

    # set client_limit to 1 as override to allow mbox.

      client_limit = 1

    }

     

    ----------------------------

     

    So far I've run into one problem with permissions ... dovecot doesn't show any of the mbox files in IMAP view with the default "700" perms associated with the ~/mail folder. Changing directory to 755 at least shows the mbox file names but then causes system.log erros like:

                imap(pid 96374 user jonathan): Error: mkdir(/Users/jonathan/mail/.imap) failed: Permission denied

    Perhaps I need to change the folder/file permissions to allow dovecot to read files and/or create index files in .imap folder? Any thoughts?

     

     

    pterobyte wrote:


    You could change this if you like, but it doesn't really make a difference and you are correct Server.app would go bonkers. Also, putting mail in users directories made sense in the "old days" where users would actually log onto the server and be restriced to their home directory. Nowadays users simply access mail or other services through some kind of front end application.

     

    Funny enough, although I often check email from a webmail client or my IMAP-enabled iOS/Android devices, I'm a bit stuck in the "old days" where I'd like to login to the server directly to use alpine. So making sure I can directly access my mbox files (sent, saved mail, etc) from alpine, as well as via IMAP from mobile phones is important for me.

     

    While I know I'm in the minority here, the simplicity of installing alpine via macports suggest I'm not quite alone .

     

    One additional mail-related issue I'm seeing is sending mail from alpine. If I configure it to talk directly to the server via authenticated SMTP, things are fine. But the default, where it attempts to use sendmail, fails. I've found a solution, and mostly understand the reason but still am a little confused about what Apple has done.

     

    The error in the log:

       postfix/smtpd[96171]: fatal: open /Library/Server/Mail/Config/postfix/submit.cred: Permission denied

    is odd relates to Apple's use of the imap_submit_cred_file postfix configuration paramater in main.cf. Doing something naive like chmod 644 causes the server to go bonkers since it does involve a secret being stored in plaintext, and Apple doesn't want other applications to read it. Anyway, I've concluded it's part of their seemingly hacky way of adding authorization to imap sending. If anybody can better explain what this is really doing I'd appreciate it.

     

    However, for anybody using alpine, the default with macport is mentioned in the technote here: http://www.washington.edu/alpine/tech-notes/background.html: for UNIX Alpine if nothing is specified then the sendmail program is invoked with "-bs -odb -oem" flags. Surprisingly this isn't mentioned in the .pinerc details, which imply the "-t" flag will be used. Anyway, explicitly configuring alpine to use /usr/sbin/sendmail -t solves the problem since it allows local sending, and puts the burden on postfix to interpret recipients ... as opposed to the -bs flag which tries to operate as SMTP on stdin/stdout ... but yet with Apple's hacky submit.cred getting in the way.

  • 7. Re: Moving from Linux to OS X Server
    Jonathan2001 Level 1 Level 1 (0 points)

    I think I've discovered a bug in how Apple set up dovecot to interface with end-user accounts for IMAP purposes.

     

    Have you seen the error "home directory not set for user. Can't expand ~/ for mail root dir in: ~/mail" before? At least one other person has -- https://discussions.apple.com/thread/3686859?start=0&tstart=0, and following his lead I initially decided to hard code in a /Users/%n variant. This caused further problems with permissions.

     

    According to the dovecot guide, http://wiki2.dovecot.org/UserIds, dovecot is supposed to change to access individual mail as the end-user account uid/gid. This comes from the userdb, which in OSX server, is the auth-od implementation, which opaquely does the following:

     

    userdb {

      # OD cache refresh intervals.  The positive cache TTL applies to

      # enabled accounts.  The negative cache TTL applies to disabled

      # accounts.  Nonexistent accounts are not cached.

      # Set enforce_quotas to yes to deny message delivery and message

      # copying when user account has exceeded their quota.

      # Use global_quota to enable system wide quota.  Individual

      # quotas override global quota.

      # additional args: pos_cache_ttl=3600 neg_cache_ttl=60

      #                  luser_relay=<userid> enforce_quotas=no

      #                  use_getpwnam_ext=yes blocking=no

      driver = od

      args = partition=/Library/Server/Mail/Config/dovecot/partition_map.conf

    enforce_quotas=no

    }

    but this appears to always return no home directory, and the effective UID/GID is always set to 214/6, which is _dovecot/mail. Perhaps this is good enough for the spool directory settings, but not if you want to have IMAP folders that are owned by individual end users in /Users/%n with 0700 permissions. From the debug log for dovecot:

         Jan 13 23:31:16 imap(pid 33012 user jonathan2001): Debug: Effective uid=214, gid=6, home=

     

    Anybody have any thoughts on possibilities? I'm almost at the point of throwing out Apple's settings to centrally use a Maildir-based spool owned by _dovecot and replace the auth-od implementation with one that uses a simpler paswd-file implementation. Perhaps I'll be able to get the two to coexist but I'm growing depressed.

  • 8. Re: Moving from Linux to OS X Server
    pterobyte Level 6 Level 6 (10,910 points)

    If you want to use the local sendmail interface with Alpine, you should be able to add user creds to submit.cred (haven't tested it, but should work).

     

    That said, even though authenticated SMTP is not necessary on locally transmitted mail, there are no ill effects using it. (I actually try to always use postfix SMTP directly as I can use different ports with different features - like DKIM signing, etc).

     

    Regarding the mailboxes, yes, Apple's setup expects _dovecot:mail permissions. This was introduced in 10.7. The 10.6 implementation used GUID:mail. Don't have it handy right now, but if you check the 10.6 default configurations, youcould find the parameters needed to play nicely with what you'd like to achieve.

     

    HTH,

    Alex

  • 9. Re: Moving from Linux to OS X Server
    Jonathan2001 Level 1 Level 1 (0 points)

    Thanks - if you have a moment and have access/sugestions based upon the default 10.6 coniguration that'd be great.

     

    I'm indifferent whether I end up storing the inbox as a (1)~/Maibox mbox file owned by username:staff or (2a)Maildir stored in /Library/.../GUID/... owned by either dovecot or username:staff or (2b) Maildir stored in /Library/.../username/... , as long as it is set up to operate securely and reliably. Ideally it will be easy to maintain over time with future OSX releases, too.

     

    In playing around with userdb/passdb implementations yesterday evening based upon passwd-file listing of users, I was able to return username:staff ownership/home directory information. I wanted to use CRAM-MD5 but regardless of whether my passwd-file was storing (ugh) plaintext passwords that would be hashed on the fly or stored hashed from using doveadm pw tool, the authentication kept failing. Using the od implementation for passdb and my implementation for userdb seemed to at least return the right information, but I didn't have time to figure out the appropriate namespace configuration and permissions settings to get everything to work.