Re: Make install or upgrade for new install location
- On Apr 30, 2013, at 2:27 PM, Reindl Harald <h.reindl@...> wrote:
> Am 30.04.2013 21:20, schrieb Larry Stone: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.
>> 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
- On Apr 30, 2013, at 7:02 PM, Bill Cole <postfixlists-070913@...> 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...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.
> 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.
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.
- Le 30 avr. 2013 à 21:20, Larry Stone a écrit :
> [...]Hello Larry,
> FWIW, I consider Lion (10.7) to be the last version of OS X for which the Apple provided Postfix is usable.
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 directoriesNo, 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.
(BTW, should you have the feeling I could be of some help, please do not hesitate to contact me off-list)