Web Hosting Talk : Web Hosting Main Forums : Dedicated Server : Source code or compiling

[CarlAndr]

Hi

It would like to know what he is safer to initiate the server, get all the sources codes and to compile or to the packages with apt-get direct?

Thanks

[ServerNinja]

There is no safety problems for both the ways. If you use source codes, you will be able to define the path of the binaries and configuration files. If you use apt-get, you can install the necessary packages very easily.

[sockopt]

Originally Posted by CarlAndr

It would like to know what he is safer to initiate the server, get all the sources codes and to compile or to the packages with apt-get direct?

I am often conflicted with this, as I really enjoy using vendor tested and supplied binaries, especially from MySQL. On the other hand, if you want to upgrade to a newer version and maintain the older version or if you have some non-standard build options/parameters not included in the base RPM, you may well want to approach building from source.

It comes down to a couple different options when wanting to install custom compiled software.

1. You can build from source and install, typically using the configure/make/make install paradigm.

2. You can install, in my case because I use RedHat, a source RPM and then modify it to reflect the paths and build options you want. Then you simply rebuild the RPM then install it. You can also have specific build RPMs of apache/php/mysql and others that you place into a system like apt-get or yum or up2date, really, they can be repositories of binaries that you have custom built and act as a means for a cenrtal build server, that comes in very handy if you have multiple machines.

Method 2 is nice if you have several machines, all with an identical builds/architectures and you like maintaining RPMs. Otherwise, if you prefer a very fine grained control to how you build and where you install the software, go with a custom compile.

There are certain distros of Unix/Linux that cater to the different preferences. A typical BSD system uses the ports system, which is an automated means for pulling down and compiling from source. While RPM based systems like RedHat/CentOS/Fedora use prebuilt binaries. I also know some folks that really like Gentoo Linux, as it has very nice controls for automating builds, but does them all in a BSD-style way.

As far as your question about "safer", I'd say that if you rely on a vendor for an RPM update for a security flaw, and don't have the means to patch and/or recompile and install again, it *may* be less secure, simply in that your boxes have compromised software hanging out there for less time than others.

[karlkatzke]

Vendor RPMs are signed with a GPG-key typically. (I'm not sure how apt-get does things, as I haven't used a Debian distro in years...) The repository that you download those packages from also has a key. First the repository key is verified, and then the individual RPM keys that pertain to the packages can be verified. This means that the releases you get from a repository are just as safe as compiling and installing the source code... and it's 100x easier to deal with RPMs than it is to deal with upgrading source installations.

[spaethco]

Most everyone would agree that keeping current on software patches and updates is a vital step for overall server security. That said, which are you most likely to do:

Option 1: Grab the source code for all of the packages you want, define all your compile-time options (and record them so that you can recompile later), and track the project status for each program for when new critical patches and bug fixes are released so you can feed the changes back into the source and recompile.

Option 2: Occasionally type "apt-get update" and then "apt-get upgrade" to keep your packages up to date.

[cywkevin]

It depends on what your goals are. Packages are generally better than source in a production environment because they are back ported with security fixes. This means stability for your system. For example, apache has from time to time rewritten their interface and configuration so that newer versions conflict with configurations used for the older versions. Back porting allows production systems to maintain the old interfaces but incorporate the new security updates (effectively tweaking the old version of the software)

I understand why they don't increment the version number since it's not officially the new version. However, this can cause false positives on security scanners that check based on version number.

Conversely, source code compiling can break dependencies with other applications.

[CarlAndr]

Thanks my friends.

I caught another server with the Red Hat.

I go to use up2date and yum. It takes that everything is functioning very well.

One more time, thanks for the tips.

I find that I do not go to have problems in using the packages.

Thanks

[eymbo]

I normally read all of the change logs and the forums of vendors (if they have one) for any problems that people may get. I'll only upgrade the crucial things which I know what source code changes are and will only then update the software.

using apt-get or yum is actually relatively fast and efficient, so I'll stick with that unless you know exactly what your doing