Mta-interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.0.1 at daleenterprise.com
On Jul 26, 2008, at 00:46 AM, Brian Blood wrote:
On Jul 25, 2008, at 9:52 PM, webmaster wrote:
I did this by using the lipo command to thin out Apple's apache2
binary
(after making a backup of course) to just contain a 32-bit x86
image.
Works like a charm.
This is not a recommended path to follow, you're better off
compiling things using the correct flags than you to open yourself
up to issues caused by software update.
I guess you've haven't grasped the universal constant when it comes
to judging the efficacy of technological solutions:
It Depends.
If you're running client as a weekend warrior and not a deployed
server in a production environment then I would say breaking it due
to an OS update isn't mission critical.
The OS was supplied with 64bit capabilities for a reason and in a
real server environment it makes practical sense to utilize the
advantages offered from running in a 64bit environment.
YOUR situation may compel you to decide that this is not the a
"recommended path", however there are others in the world who have
differing circumstances where this particular approach works out
absolutely brilliantly.
Off-hand I don't know of any real deployed production servers that
use a thinned apache since the benefits of running in 64bit are much
more attractive and this is the general consensus and not my personal
situation.
Case in point, the server I first did this on was in need of being
updated from 10.5.2 to 10.5.4.
I ran the update and yes, Apple HAD updated the httpd binary wiping
out my thinned out binary. Apache was not loading due to the
expected errors described previously.
If you did it right it wouldn't have broken so your "Case in point"
isn't really valid, it's just a lazy way to get it up and running
with software generated by someone else that wasn't built for or
intended to be used in a real server environment, entropy is an
example of this and I have discussed this with Marc many times in the
past, he does it this way out of conveniences, not out of requirements.
No matter. I had placed my commands for thinning httpd down into a
shell script. I simply reran that and lo and behold launchd pretty
much immediately started up the new i386-only based httpd without
me having to do anything else.
Problem solved. Case closed. No muss. No fuss.
The fact that it broke due to an OS update is reason enough to not do
it on a deployed server in a production environment unless you have
absolutely no other choices or options and the benefits would have to
outweigh the cons considerably and that is why it's not a recommended
procedure.
The better solution would have been to build your add-on software to
use both architectures and you wouldn't have had any issues when
software updated occurred now or later in the future so there was
fuss and muss because the update broke your server.
Indeed. I guess I was just being 64bit stubborn ;)
Not really, right idea wrong approach.
Well, in my case, this particular servers usage pattern was such
that I deemed this an acceptable workaround that is well documented
in our system and works flawlessly. If Jeremy deems it works for
him and he accepts the consequences, then good for him.
Suggesting such an approach should have been as a last resort when no
other options are available, doing it the right way is what I
recommend to avoid any future issues, if he wants to take a different
approach that's up to him, I offered my recommendations and
information to help achieve the required results which aren't
susceptible to OS updating failures.
Looking at your other email I see you recommend spending orders of
magnitude more time recompiling for an end result that most likely
provides no real-world practical benefit.
That is not so, I recommend spending the time planning and doing it
right the first time so you don't have to worry about rebuilding it
or fixing it later cause it breaks due to an OS update.
So how is thinning out the binary and being back up in 5 seconds
the "wrong" approach?
If you have to ask then it's obvious you don't understand why.
Dale, I respect your knowledge in how to tear apart and rebuild the
modules in PHP. You've frequently shared valuable knowledge in that
area with the list.
However in this case, a better approach might have been:
"Thinning out the binary is an interesting approach. It does pose
deployment risks from a Software Update wiping out your change, but
if you REALLY wanted 64-bit, here's how to do it:"
Knowing a little about his setup and his use is the reason I
recommend he do it properly now rather than placing his server in a
heightened position of potential failure due to an OS update.
Otherwise, you just come across as rude and arrogant.
If you interpret it as rude that's OK, others probably share the same
opinion and everyone is entitled to their own.
