Am 10.01.2011 14:23, schrieb Reindl Harald:
Am 10.01.2011 14:11, schrieb John Adams:
As it may take some time to build up software packaging facility
where is the problem to take the source-package and
try to replace the programsource for a rebuild?
On RHEL/Fedora you take the srpm, install it as builduser, put
the newer tarball under SOURCES, edit the SPECFILE and do
a "rpmbuild -bb postfix.spec", i do this since a long time
necause i rebuild all our core-services with optimized
gcc-flags
I use Slackware. There's no deb, no rpm, no spec, no dependency
checking, no whatever you may have in ubuntu debian centos rhel sles
etc..., it's not there :)
Just plain old tgz. Great, isn't it? No tight corsett, it gives you all
the freedom you may ever require.
To learn building/rebuilding packages for your distro
is good knowhow because it affects other packages too
and later you can deploy your version with a own repo
on thousands of machines if needed, dependencies are
resolved and so on....
I suggest you make a clean install on a vmware
Jep the builduser, environemnt etc. should be a VM
Jere too, one for i386 and one for x86_64 :-)
I do use root permissions to build, but I do it on a build host
bad practice is everywhere bad practice
A bad practice that works for me.
some source packages disallowing this as long you do not
modifie the sources,
Well, if you use the tar ball, you can always use root. Slackware.
ok a snapshot can revert back
but it is nicer prevent damage instead repair and
Exactly. That's why I usually check the Makefile for a very specific
capability before running 'make install DESTDIR=/installation/path'.
be sure if this happens your latest snapshot is old enough
that revert hurts :-)
My build scripts are svn-ized :) I would just lose the time to delete
the checkout and type svn up. 2 minutes with a cup of coffee in between?
More than that I do preliminary checks of the
Makefile's capabilities - if there is a Makefile - before I am building. These
tests perhaps do not apply on you
because I don't use Ubuntu or Debian.
Before I deploy a package, I usually test it. Are the permissions right? Does
it install the files into the right
directories? Does it create the needed links, devices, ...? When I configure
the software and start it, does it
start up? And then, finally, when I am sure, I deploy it to a productive server
and always have a way back to the
old version if the new still does not work.
rpmbuild as example should EVER called with explicit user and
if there is a bug in the bzild-process which wants to touch files
outside the build-folder it fails an dnothing happens - do this
as root overwrites files on your build-system, mybe fails later
and you have an undefined state of your system
To summarize:
* If avoidable, don't use root for software building
* put your software packaging facility away from your productive servers
* before deploying to production, test your new built package
This may sound like overkill. But it's worth the trouble.
On Mon, Jan 10, 2011 at 10:43 AM, John Adams<mailingli...@belfin.ch> wrote:
Am 10.01.2011 10:06, schrieb Buzai Andras:
Hi,
I want to install Postfix 2.7.2 by compiling it from sources.
In the INSTALL file I saw the following statement:
"In the instructions below, a command written as "#
command" should be executed as the superuser.
A command written as "% command" should be executed as an
unprivileged user."
My question is:
The user used to configure/compile the sources is used in anyway in
Postfix later?
No.
Is there any security risk if I configure/compile all the sources
as the superuser? (I am referring only to the build/installation
process)
For installing, take a look at the software packaging procedure of your
distro/OS. This is much cleaner than just run 'make install'.
Thank you,
Buzai
