Newbie: Installing from repository vs compile for the long term support
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Newbie: Installing from repository vs compile for the long term support
I'm stuck on a question and wanted to ask the group.
Currently I'm a Windows admin who does part time Linux server installs. Most of the time I'm asked to deploy a generic Windows server, install a few basic applications and if needed some other applications like Nagios or Zabbix.
My question is for long term support, or patching should I be focusing on deploying with repositories to install applications or compile from source? In the Windows world you can patch and update from Windows Update, but is there problems using 3rd party repositories for future updates? Would one of these locations go off line?
Well, you didn't say which distribution you are referring too, but if we assume the Ubuntu in your profile, you should be using the repositories exclusively. On a server you should be running the LTS (Long Term Support) releases, which will have upgrades and security patches over the long term, there is no reason at all to build anything from source if it is already included in the repositories (and anymore, it is very rare that something worth running won't already be in the repos).
For example, I'm installing Nagios on a CentOS server. From my documentation it shows I should install the rpm from rpmforge. But I'm wondering since this was not included in the default repository, is this a security risk using another place like rpmforge?
rpmforge can be considered a safe and stable 3rd party repo for CentOS. I have it set at lower priority to protect the base install. Also certain repo's I have disabled and turned on only when necessary.
rpmforge is offering 3.2.1-4.el5.rf nagios while another repo I sometimes use, epel, has only 2.12-6.el5 nagios.
I have not had problems with rpmforge.
So the general idea is stick with the distro's repository, but if you need for certain applications (Nagios) 3rd party from a reputable source are ok. Compile from source is highly recommended only for personal use.
Seems so strange, from what I read it was what I understood the standard of building apps from using the source and just reserved using repositories for my own personal use on Linux workstations. Now that I know better, I'll save my self so much more time.
I agree with the above; rpmforge is very reputable.
CentOS is a little different from other distros (like Ubuntu); they only include apps in the standard repository that are supported by the "upstream vendor." So if an application is not in the CentOS repositories, it doesn't necessarily mean that it's a security or stability risk, just that it is not officially supported by Red Hat.
With RPM based systems, especially, it is best to stick to the standard RPMs where possible. RPM is really just a 'great big database' approach to managing a computer, and as such can be prone to some of the pitfalls we know of, so well, from similar approaches, such as the Windows Registry.
Even maybe even roll your own RPMs for stuff you DO have to compile from source, so that the RPM system actually knows that they are there and contains a record for them. If the RPM is good, you could even submit it back to your third party software vendor, as a known example of an RPM that is known to work on an otherwise standard copy of RHEL version x.y, for instance. I add this suggestion, since it can prompt the vendor to take up some of the work of supporting an RPM-based release, themselves, or encourage uptake of the software with other Redhat users. Well-used software, usually has a way of becoming well-supported software, so feeding some support back into the system (work that you were having to do anyway) can occasionally opperate to your own benefit in the long term.
The CentOS website does give guidance on using other repositories. Some can be used without hesitation. For some you just need to set a few parameters to prevent the private repository from altering the stuff you've got from the official source.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.