Re: Make install or upgrade for new install location
Le 30 avr. 2013 à 21:20, Larry Stone a écrit : [...] FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. Hello Larry, I'm going to be somewhat OT here... The postfix binaries coming with 10.8 are per se at least as capable as the ones that came with earlier versions of the OS; as usual, these binaries are identical on the client and server versions of the OS. For Mountain Lion (10.8), they changed a lot of the default directories No, unless you upgraded from a 10.7 client to a 10.8 server version; but then, such changes were to be expected (yet easily reversible). but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value). Amavis, SpamAssasin and consorts never came with the client version; perhaps did you install Amavis yourself? That said, as far as I can tell, the latest server version of 10.7 (resp. 10.8) comes with amavisd-new-2.6.6 (20110518) (resp. amavisd-new-2.8.0 (20120630)). Plus the pain of Apple provided updates deciding to make changes to main.cf for security (Apple considers having something listening 24/7 on port 25 to be a security issue). By default, on both the client and the server versions of the OS, the master process has always been launched with its -e option (since that option became available; before, the same effect was achieved through other means), as part of a scheme allowing to have Postfix running on demand for local needs only. In order to revert to a traditional behavior, it is just a matter of manually editing a plist on the client version of the OS; on the server, this is done indirectly with the admin tools. Just wanted to clarify some points that otherwise could have appeared as counterfactual. Axel (BTW, should you have the feeling I could be of some help, please do not hesitate to contact me off-list)
Make install or upgrade for new install location
I have been running Postfix under Mac OS X for a number of years (now on OS X 10.7.latest (Lion)). I am working on moving away from the Apple provided and customized Postfix to real Postfix built from sources. I've successfully built Postfix but not yet tested. To avoid having it overwritten by Apple updates to Postfix, I'm planning to install in /usr/local/ (e.g. /usr/local/etc/postfix, /usr/local/sbin, and /usr/local/libexec/postfix). When it comes time to install, do I do make install or make upgrade? It's not clear to me if make upgrade will work when the upgrade is in a different location than the previous version. -- Larry Stone lston...@stonejongleux.com
Re: Make install or upgrade for new install location
On Tue, Apr 30, 2013 at 12:02:11PM -0500, Larry Stone wrote: I have been running Postfix under Mac OS X for a number of years (now on OS X 10.7.latest (Lion)). I am working on moving away from the Apple provided and customized Postfix to real Postfix built from sources. I've successfully built Postfix but not yet tested. To avoid having it overwritten by Apple updates to Postfix, I'm planning to install in /usr/local/ (e.g. /usr/local/etc/postfix, /usr/local/sbin, and /usr/local/libexec/postfix). When it comes time to install, do I do make install or make upgrade? It's not clear to me if make upgrade will work when the upgrade is in a different location than the previous version. You could consider the Postfix from macports. Otherwise, make install. -- Viktor.
Re: Make install or upgrade for new install location
On Tue, 30 Apr 2013, Viktor Dukhovni wrote: When it comes time to install, do I do make install or make upgrade? It's not clear to me if make upgrade will work when the upgrade is in a different location than the previous version. You could consider the Postfix from macports. I did consider Macports. Already did some testing with it and it worked fine. But I became comfortable with building from source before I learned about packages so prefer to continue that way when I can. Plus having some stuff from Macports and some from source seems to cause some side issues. FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. For Mountain Lion (10.8), they changed a lot of the default directories but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value). Plus the pain of Apple provided updates deciding to make changes to main.cf for security (Apple considers having something listening 24/7 on port 25 to be a security issue). So now, it's get off the Apple provided Postfix, then amavisd-new, then see about upgrading to Mountain Lion. Otherwise, make install. Thanks. I had a feeling that was the answer. -- Larry Stone lston...@stonejongleux.com
Re: Make install or upgrade for new install location
Am 30.04.2013 21:20, schrieb Larry Stone: FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. For Mountain Lion (10.8), they changed a lot of the default directories but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value) and that is why nobody seriously uses Apple OSX for production servers been there, seen that crap over years never ever i will use any Apple hardware / software for servers long ago they burried their only server hardware X-serve to give a clear public statement that Apple Inc. formerly known as Apple Compuiters Inc. is no longer interested in any professional user and has switched to the customer bullshit market signature.asc Description: OpenPGP digital signature
Re: Make install or upgrade for new install location
On 30 Apr 2013, at 15:20, Larry Stone wrote: On Tue, 30 Apr 2013, Viktor Dukhovni wrote: When it comes time to install, do I do make install or make upgrade? It's not clear to me if make upgrade will work when the upgrade is in a different location than the previous version. You could consider the Postfix from macports. I did consider Macports. Already did some testing with it and it worked fine. But I became comfortable with building from source before I learned about packages so prefer to continue that way when I can. MacPorts is a mixed system akin to the FreeBSD ports subsystem: there are some pre-built packages available but it is mostly just a collection of build configuration files, links to source tarballs, and patches that handle all the niggling little details for you. If you DO need to fiddle with details, it's not hard to make local adjustments to Portfiles and get exactly the variant you want. Plus having some stuff from Macports and some from source seems to cause some side issues. Yes, it can. MacPorts creates its own world under /opt/local and uses very limited parts of of the base system (e.g. the XCode build toolchain) where necessary. There's no simple way to tell MacPorts that you've installed dependencies outside of MacPorts that you want it to use instead of its internal dependencies, but some software (e.g. autoconf scripts and similar build tools) can sometimes find manually installed stuff in /usr/local and use it instead of a MacPorts-installed version. Hilarity (or something) ensues... I have found that just using MacPorts where possible instead of maintaining my own MacOS builds of open source software has been the right choice, because I really don't get anything out of manually doing the housekeeping that MacPorts handles for me, and I'm more likely to make a mistake in it that I will discover because one component breaks when I want it working. Do I really want to manually keep track of which of the 100 OSS packages I have installed need rebuilding because I want to fix latest OpenSSL oopsie? No, not really. FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. For Mountain Lion (10.8), they changed a lot of the default directories but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value). Plus the pain of Apple provided updates deciding to make changes to main.cf for security (Apple considers having something listening 24/7 on port 25 to be a security issue). So now, it's get off the Apple provided Postfix, then amavisd-new, then see about upgrading to Mountain Lion. Otherwise, make install. Thanks. I had a feeling that was the answer. And it certainly can be. Just make sure that when you manually build postfix, you don't blindly let it link into the base MacOS X world. That can cause trouble (i.e. a need to rebuild) after any OS update, major or minor. Apple makes no allowances for users replacing base components and will not accommodate your reliance on a version of something in /usr/lib/ that they no longer need.
Re: Make install or upgrade for new install location
On 01/05/2013, at 3:02 AM, Larry Stone lston...@stonejongleux.com wrote: I have been running Postfix under Mac OS X for a number of years (now on OS X 10.7.latest (Lion)). I am working on moving away from the Apple provided and customized Postfix to real Postfix built from sources. I've successfully built Postfix but not yet tested. To avoid having it overwritten by Apple updates to Postfix, I'm planning to install in /usr/local/ (e.g. /usr/local/etc/postfix, /usr/local/sbin, and /usr/local/libexec/postfix). When it comes time to install, do I do make install or make upgrade? It's not clear to me if make upgrade will work when the upgrade is in a different location than the previous version. -- Larry Stone lston...@stonejongleux.com Have you had a look at http://diymacserver.com/ ? Go to the Documentation page. It shows you how to install Postifx (and Dovecot, etc) independently of Apple's installation. Following this you can run Apple updates without fear of your Postfix settings being messed up. It's been absolutely essential for me. James. smime.p7s Description: S/MIME cryptographic signature
Re: Make install or upgrade for new install location
On Apr 30, 2013, at 2:27 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 30.04.2013 21:20, schrieb Larry Stone: FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable. For Mountain Lion (10.8), they changed a lot of the default directories but also removed amavisd-new (compatability through OS upgrades apparently is not something Apple thinks has value) and that is why nobody seriously uses Apple OSX for production servers been there, seen that crap over years never ever i will use any Apple hardware / software for servers long ago they burried their only server hardware X-serve to give a clear public statement that Apple Inc. formerly known as Apple Compuiters Inc. is no longer interested in any professional user and has switched to the customer bullshit market Reindl, I can't say I disagree. But I've been running this server for a good number of years. It supports four users (all family) for email and I run some low volume mailing lists (with Mailman). It uses a Macintosh that would be running here anyway. Buying a real Unix system is not going to happen. For the most part, it just runs. If I reach a point I can no longer run it effectively, I outsource the mail and drop the mailing lists. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: Make install or upgrade for new install location
On Apr 30, 2013, at 7:02 PM, Bill Cole postfixlists-070...@billmail.scconsult.com wrote: Yes, it can. MacPorts creates its own world under /opt/local and uses very limited parts of of the base system (e.g. the XCode build toolchain) where necessary. There's no simple way to tell MacPorts that you've installed dependencies outside of MacPorts that you want it to use instead of its internal dependencies, but some software (e.g. autoconf scripts and similar build tools) can sometimes find manually installed stuff in /usr/local and use it instead of a MacPorts-installed version. Hilarity (or something) ensues... I have found that just using MacPorts where possible instead of maintaining my own MacOS builds of open source software has been the right choice, because I really don't get anything out of manually doing the housekeeping that MacPorts handles for me, and I'm more likely to make a mistake in it that I will discover because one component breaks when I want it working. Do I really want to manually keep track of which of the 100 OSS packages I have installed need rebuilding because I want to fix latest OpenSSL oopsie? No, not really. If I were starting from scratch, I'd probably go the MacPorts route. But trying to switch a running system is a lot of work. Easier to keep going with what I have. I have a good enough feel for what does what that when something breaks, I usually can deal with it quickly. In fact, on my aborted attempt to upgrade to Mountain Lion (on my test system - just my regular MacBook Pro booted off a clone of the server), lots broke. Due to the Postfix issues which I already knew about, I did a MacPorts install of Postfix. But then as I moved on, I found Postfwd wouldn't run as it needed something updated in CPAN. And that's where MacPorts caused me trouble because with the MacPorts changed PATH value, CPAN was updating the MacPorts library, not the one Postfwd was using. Just make sure that when you manually build postfix, you don't blindly let it link into the base MacOS X world. That can cause trouble (i.e. a need to rebuild) after any OS update, major or minor. Apple makes no allowances for users replacing base components and will not accommodate your reliance on a version of something in /usr/lib/ that they no longer need. I followed the diymacserver.com instructions (mentioned by James Brown in another note although I had already found it) which helped me over a big hurdle which was getting the make makefiles arguments all combined properly. It does dip into /usr/lib for a couple of things - -llber and -lresolv. But the Postfix command, config, and daemon directories are all in /usr/local. The one thing that isn't is sendmail but I have so much (scripts, etc.) that have /usr/sbin/sendmail in them that's it's probably easier to leave that in /usr/sbin, keep a copy, and restore it if Apple wipes it out in an upgrade. Just need to remember to check each time. Anyway, I did a test build and install and all seemed to work as expected with no surprises. But since everything sits behind a NAT router, I have no easy way to route external mail to it. I do have a second IP address I can use so the final test will be to make a good backup, switch the router to the alternate IP address (thereby stopping legitimate outside mail from getting in), install in production, test, and if all seems OK, switch back to the regular IP address. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
