Hello CentOS,
I'm an old hat, and have been compiling my own MySQL, Apache, PHP, OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around with the RPM installs on CentOS, and have basically been able to get most things setup so that they "function" about the same.
If I could stick to RPM's rather than compiling my own sources, it would save me a fair bit of time, but of course, it would limit the customization benefit. what I'm wondering, is if anyone on this list has any good reasons why one method would be better, more secure, etc than the other. I'm tempted to start using RPM's instead of compile sources.
Comments appreciated, thanks.
On Mon, 2006-01-09 at 00:18 -0800, Mickael Maddison wrote:
Hello CentOS,
I'm an old hat, and have been compiling my own MySQL, Apache, PHP, OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around with the RPM installs on CentOS, and have basically been able to get most things setup so that they "function" about the same.
If I could stick to RPM's rather than compiling my own sources, it would save me a fair bit of time, but of course, it would limit the customization benefit. what I'm wondering, is if anyone on this list has any good reasons why one method would be better, more secure, etc than the other. I'm tempted to start using RPM's instead of compile sources.
Usually in an RPM distro it is better to use RPMS if at all possible. That is because there are several requires that must be met throughout the system that aren't if RPMS are not used.
Also, not using RPMS means that you must manually track all security updates to all packages and install them, rebuilding everything as required ... and then there is the issue of backporting to maintain compatibility (which can be very important in the case of specially compile apache modules):
http://www.redhat.com/advice/speaks_backport.html
So my advise is to use RPMS unless you absolutely have to compile something. Even then, understand the effect that compiling your own items has on the stability of the rest of the system.
Johnny Hughes wrote:
So my advise is to use RPMS unless you absolutely have to compile something. Even then, understand the effect that compiling your own items has on the stability of the rest of the system.
and when you really really need to compile your own things - build rpms :)
On Mon, 2006-01-09 at 00:18 -0800, Mickael Maddison wrote:
Hello CentOS,
I'm an old hat, and have been compiling my own MySQL, Apache, PHP, OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around with the RPM installs on CentOS, and have basically been able to get most things setup so that they "function" about the same.
If I could stick to RPM's rather than compiling my own sources, it would save me a fair bit of time, but of course, it would limit the customization benefit. what I'm wondering, is if anyone on this list has any good reasons why one method would be better, more secure, etc than the other. I'm tempted to start using RPM's instead of compile sources.
Comments appreciated, thanks.
Well, let's look at why tarballs might be better than packages:
- Both are customizable before the build, but packages aren't afterward.
No, wait, once a tarball has been compiled then that's it...
- Tarballs are easier to manage since they all go in /usr/local.
Well, no, they get spread throughout /usr/local. OTOH, packages are managed on a file-by-file basis in the rpmdb. This also makes it easier to discover if files have been modified or corrupted since installation.
Okay, I'm out of reasons why tarballs are better. Maybe we should look at the flipside.
- Package builds are reproducible.
So are tarballs, if you're willing to type in or copy all the commands you used to install them identical to the letter, *plus* can make sure that you have exactly the same set of tarballs built or -devel packages installed before you run configure. Better to just let the spec file handle all that for you ("hey dumbass, you forgot to install openssl-devel!").
- Package builds can run arbitrary commands.
So can tarballs, but once again with the typing them in or running a script. With a spec file it's just *all there*.
- Package builds are archivable.
So are tarballs, at least until you misplace the sheet of paper you wrote the notes on. SRPMs can easily be transmitted via NFS, SMB, optical media, etc., as a single file, and are rebuildable by running "rpmbuild --rebuild" against them. Easy peasy.
Well, those are my reasons for using packages over tarballs. I'm sure others have their reasons, but I can only speak for myself.
Generally, the only time I would use a tarball and compile myself would be:
1)If no rpm was available 2)If a feature was missing in the rpm version that I needed to enable, ( a classic example here would be milter support in sendmail, but I think thats in the rpms these days).
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding....
Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...
P.
Ignacio Vazquez-Abrams wrote:
On Mon, 2006-01-09 at 00:18 -0800, Mickael Maddison wrote:
Hello CentOS,
I'm an old hat, and have been compiling my own MySQL, Apache, PHP, OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around with the RPM installs on CentOS, and have basically been able to get most things setup so that they "function" about the same.
If I could stick to RPM's rather than compiling my own sources, it would save me a fair bit of time, but of course, it would limit the customization benefit. what I'm wondering, is if anyone on this list has any good reasons why one method would be better, more secure, etc than the other. I'm tempted to start using RPM's instead of compile sources.
Comments appreciated, thanks.
Well, let's look at why tarballs might be better than packages:
- Both are customizable before the build, but packages aren't afterward.
No, wait, once a tarball has been compiled then that's it...
- Tarballs are easier to manage since they all go in /usr/local.
Well, no, they get spread throughout /usr/local. OTOH, packages are managed on a file-by-file basis in the rpmdb. This also makes it easier to discover if files have been modified or corrupted since installation.
Okay, I'm out of reasons why tarballs are better. Maybe we should look at the flipside.
- Package builds are reproducible.
So are tarballs, if you're willing to type in or copy all the commands you used to install them identical to the letter, *plus* can make sure that you have exactly the same set of tarballs built or -devel packages installed before you run configure. Better to just let the spec file handle all that for you ("hey dumbass, you forgot to install openssl-devel!").
- Package builds can run arbitrary commands.
So can tarballs, but once again with the typing them in or running a script. With a spec file it's just *all there*.
- Package builds are archivable.
So are tarballs, at least until you misplace the sheet of paper you wrote the notes on. SRPMs can easily be transmitted via NFS, SMB, optical media, etc., as a single file, and are rebuildable by running "rpmbuild --rebuild" against them. Easy peasy.
Well, those are my reasons for using packages over tarballs. I'm sure others have their reasons, but I can only speak for myself.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
2006/1/9, Peter Farrow peter@farrows.org:
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding....
Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...
Is EVERY package intended for RHEL (DAG or otherwise) just CentOS compatible right out of the box? TIA
-- Eduardo Grosclaude Universidad Nacional del Comahue Neuquen, Argentina
Eduardo Grosclaude wrote:
2006/1/9, Peter Farrow <peter@farrows.org mailto:peter@farrows.org>:
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding.... Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...Is EVERY package intended for RHEL (DAG or otherwise) just CentOS compatible right out of the box?
yes - as long as you match the release and update cycle ( if required )
if you come across something that isnt compatible - let the packager know and let us know as well.
On Mon, 2006-01-09 at 14:35 +0000, Karanbir Singh wrote:
Eduardo Grosclaude wrote:
2006/1/9, Peter Farrow <peter@farrows.org mailto:peter@farrows.org>:
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding.... Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...Is EVERY package intended for RHEL (DAG or otherwise) just CentOS compatible right out of the box?
yes - as long as you match the release and update cycle ( if required )
if you come across something that isnt compatible - let the packager know and let us know as well.
right ... everything that is written for RHEL should work on CentOS too.
The only issue might be things that look specifically for something in /etc/redhat-release.
Obviously, we can't put the same line that RH puts in their product, so some installers (like Oracle) that specifically look for a string from upstream will not initially work with CentOS.
It is usually very easy to get these to work .. look at this example and search for redhat-release on the page:
http://www.puschitz.com/InstallingOracle10g.shtml
And it will tell you how to change your /etc/redhat-release file to allow there installers to function.
Thanks, Johnny Hughes
Monday, January 9, 2006, 8:32:07 AM, you wrote:
On Mon, 2006-01-09 at 14:35 +0000, Karanbir Singh wrote:
Eduardo Grosclaude wrote:
2006/1/9, Peter Farrow <peter@farrows.org mailto:peter@farrows.org>:
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding.... Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...Is EVERY package intended for RHEL (DAG or otherwise) just CentOS compatible right out of the box?
yes - as long as you match the release and update cycle ( if required )
if you come across something that isnt compatible - let the packager know and let us know as well.
right ... everything that is written for RHEL should work on CentOS too.
The only issue might be things that look specifically for something in /etc/redhat-release.
Obviously, we can't put the same line that RH puts in their product, so some installers (like Oracle) that specifically look for a string from upstream will not initially work with CentOS.
It is usually very easy to get these to work .. look at this example and search for redhat-release on the page:
And it will tell you how to change your /etc/redhat-release file to allow there installers to function.
Thanks, Johnny Hughes
Ok. So basically, every response on this list feels that RPM's are sufficiently stable, are created fast enough to address security concerns that come up, and have all the 'normal' functionality that pretty much anyone needs... is that a fair statement?
My reasons over the years for compiling stem from starting on Solaris, then Solaris for Intel, then to RedHat 7-9, to WBEL and now CentOS. While there have been a lot of changes to the OS's, the compiling and installing has remained pretty much the same throughout. I have had some problems at times getting dependancies worked out, but at the end of the day have always acheived the desired result eventually.
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
Thanks. Mickael
Mickael Maddison wrote:
Monday, January 9, 2006, 8:32:07 AM, you wrote:
On Mon, 2006-01-09 at 14:35 +0000, Karanbir Singh wrote:
Eduardo Grosclaude wrote:
2006/1/9, Peter Farrow <peter@farrows.org mailto:peter@farrows.org>:
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding....
Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...
Is EVERY package intended for RHEL (DAG or otherwise) just CentOS compatible right out of the box?
yes - as long as you match the release and update cycle ( if required )
if you come across something that isnt compatible - let the packager know and let us know as well.
right ... everything that is written for RHEL should work on CentOS too.
The only issue might be things that look specifically for something in /etc/redhat-release.
Obviously, we can't put the same line that RH puts in their product, so some installers (like Oracle) that specifically look for a string from upstream will not initially work with CentOS.
It is usually very easy to get these to work .. look at this example and search for redhat-release on the page:
And it will tell you how to change your /etc/redhat-release file to allow there installers to function.
Thanks, Johnny Hughes
Ok. So basically, every response on this list feels that RPM's are sufficiently stable, are created fast enough to address security concerns that come up, and have all the 'normal' functionality that pretty much anyone needs... is that a fair statement?
My reasons over the years for compiling stem from starting on Solaris, then Solaris for Intel, then to RedHat 7-9, to WBEL and now CentOS. While there have been a lot of changes to the OS's, the compiling and installing has remained pretty much the same throughout. I have had some problems at times getting dependancies worked out, but at the end of the day have always acheived the desired result eventually.
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
Thanks. Mickael
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I do my updates from time to time, unless a high profile security update comes to light....
Usually, "if it aint broke don't fix it" is a good motto.....
P.
On Mon, 2006-01-09 at 09:10 -0800, Mickael Maddison wrote:
Monday, January 9, 2006, 8:32:07 AM, you wrote:
On Mon, 2006-01-09 at 14:35 +0000, Karanbir Singh wrote:
Eduardo Grosclaude wrote:
2006/1/9, Peter Farrow <peter@farrows.org mailto:peter@farrows.org>:
You can reduce still further the chances of no rpms being available by adding the DAG repository to your yum.conf file. This adds a lot of stuff that would otherwise take a bit of finding.... Becareful though, you should be aware of the possible consequences and pitfalls of updating from multiple repositories....generally I use dag to get stuff that isn't available from the standard yum repos... but not for an os update...Is EVERY package intended for RHEL (DAG or otherwise) just CentOS compatible right out of the box?
yes - as long as you match the release and update cycle ( if required )
if you come across something that isnt compatible - let the packager know and let us know as well.
right ... everything that is written for RHEL should work on CentOS too.
The only issue might be things that look specifically for something in /etc/redhat-release.
Obviously, we can't put the same line that RH puts in their product, so some installers (like Oracle) that specifically look for a string from upstream will not initially work with CentOS.
It is usually very easy to get these to work .. look at this example and search for redhat-release on the page:
And it will tell you how to change your /etc/redhat-release file to allow there installers to function.
Thanks, Johnny Hughes
Ok. So basically, every response on this list feels that RPM's are sufficiently stable, are created fast enough to address security concerns that come up, and have all the 'normal' functionality that pretty much anyone needs... is that a fair statement?
I think that is the reason to have an enterprise linux OS ... fast updates that should make your software continue to work.
My reasons over the years for compiling stem from starting on Solaris, then Solaris for Intel, then to RedHat 7-9, to WBEL and now CentOS. While there have been a lot of changes to the OS's, the compiling and installing has remained pretty much the same throughout. I have had some problems at times getting dependancies worked out, but at the end of the day have always acheived the desired result eventually.
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
rpm -ql package_name
(tells you where the files are ... although knowing where they are is less important since they all go away if the package is removed)
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
I would never update important production servers automatically without testing the install first on a test server ... but that is just me.
Thanks. Mickael
On Mon, 2006-01-09 at 11:10, Mickael Maddison wrote:
Ok. So basically, every response on this list feels that RPM's are sufficiently stable, are created fast enough to address security concerns that come up, and have all the 'normal' functionality that pretty much anyone needs... is that a fair statement?
You might have an exception or two where for some local situation you need to have the latest available version or some special option set during a compile but the RPMs are fine for normal use.
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
But rpm keeps track of everything. There is no equivalent of 'rpm -e packagename' to remove all parts of a tarball installed package. If you do need a slight customization you can download the src rpm and tweak it.
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
I do them manually because I don't like surprises, but try not to get too far behind.
On Monday 09 January 2006 12:40, Les Mikesell wrote:
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
I do them manually because I don't like surprises, but try not to get too far behind.
Does aPnyone cron updates? That sounds like a recipe for a 2 AM wake-up call. :-)
On 1/9/06, Les Mikesell lesmikesell@gmail.com wrote:
But rpm keeps track of everything. There is no equivalent of 'rpm -e packagename' to remove all parts of a tarball installed package.
Obviously you've never seen "stow".
On Mon, 2006-01-09 at 17:17 -0800, Bart Schaefer wrote:
On 1/9/06, Les Mikesell lesmikesell@gmail.com wrote:
But rpm keeps track of everything. There is no equivalent of 'rpm -e packagename' to remove all parts of a tarball installed package.
Obviously you've never seen "stow".
Or you could just install gentoo if you want to build everything from scratch :)
Mickael Maddison wrote:
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
You can still do this if you download the source rpm and edit the prefix in the .spec file. I used to do this for a number of packages, but I've gotten lazy over the years and have gotten used to leaving most stuff where it defaults to.
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
In theory, you could do this. However, there have been instances in the past where this resulted in a wedged machine upon reboot. So I've gotten into the habit of doing a "yum check-update" first to see what is going to get updated before I actually commit to the update...especially on servers in unattended locations. 8-)
Cheers,
Monday, January 9, 2006, 10:00:21 AM, you wrote:
Mickael Maddison wrote:
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
You can still do this if you download the source rpm and edit the prefix in the .spec file. I used to do this for a number of packages, but I've gotten lazy over the years and have gotten used to leaving most stuff where it defaults to.
Well, if I'm going to move to using the RPM's to save time, then I'll have to get used to the distributed layout.
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
In theory, you could do this. However, there have been instances in the past where this resulted in a wedged machine upon reboot. So I've gotten into the habit of doing a "yum check-update" first to see what is going to get updated before I actually commit to the update...especially on servers in unattended locations. 8-)
Fortunately for me, all the remote machines have KVM and power controls, but that said, if I convert all machines to use RPMs, updates are quick and easy providing new packages don't break anything.
Thanks for the great replies all.
Mickael
Mickael Maddison wrote:
Ok. So basically, every response on this list feels that RPM's are sufficiently stable, are created fast enough to address security concerns that come up, and have all the 'normal' functionality that pretty much anyone needs... is that a fair statement?
Yes. Out of interest what features, in the apps you mentioned in your original post, did you need to compile in that weren't in the RPMs?
The one thing I've always liked about installing from tarball distributions is that I prefix everything into /usr/local -- so it's easy to find all the pieces. This is perhaps the one thing that I find most annoying about RPM; spreading things all over the place. Of course, being able to custom compile modules etc. has worked well.
rpm -ql packagename is easier to find the pieces than searching through /usr/local IMHO. Anyway packages are still consistent - they put config files in /etc, binaries in /usr/bin, libs in /usr/lib, shared files in /usr/share and so on: http://www.pathname.com/fhs/
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
We have a Nagios check that notifies when updates are available. Then we do a yum update so we can see what's going to be updated before confirming with 'y' or 'n'.
I apply them manually.
But, I have a cron script something like:
yes 'n' | yum update
This runs once/week, and runs as user "root". Email filters send this output to a special account, so just by checking email on this special account, I see all the yum updates run on all the servers, once/week.
Then, it's easy to see what needs to be done! Probably 1 hour/month to keep 2 dozen systems updated weekly on an "as needed" basis. This way we're both current, and I'm on hand in case something goes wrong.
PS: I'm aware of only ONE issue in the past 2 years with over 1 dozen servers updated via yum that resulted in ANY ACTION AT ALL (beyond a reboot of kernel packages) in order to fix anything yum "broke".
In short, if you're running Yahoo, spend a few days and test before rollout. You have the money, why not? But, if you're running a small(ish) business on said server, the issues that break from yum are few and far between, unless you have a specialized environment. (installing * from CPAN, for example)
-Ben
PS: If you want to see what RPM files are installed for NN rpm, try
rpm -ql NN
PPS: If you want to get rid of whatever package owns file foo, try
yum remove `rpm -qf /path/too/foo`;
You'll be prompted before the delete...
don't exuse lack of familiarity with RPM tools to mean that they "suck" or are "hard to use". Like driving a car, they require a bit of training, and once you get it, it becomes second-nature.
On Monday 09 January 2006 09:10, Mickael Maddison wrote:
QUESTION: Do most of you cron the yum updates, or do you watch for new RPMs and update "manually"?
Hello Benjamin,
Thanks for the reply. I have had a few CentOS and WBEL boxes that have cron set for "yum -y update" updates running nightly and same as you, have had only a single instance of trouble. But if I start using the apache, mysql, php, etc... RPMs... I think I'll just cron myself to do it once/week or whenever there's a need.
mailing-lists@hughesjr.com (Johnny Hughes) writes:
The only issue might be things that look specifically for something in /etc/redhat-release.
Obviously, we can't put the same line that RH puts in their product, so some installers (like Oracle) that specifically look for a string from upstream will not initially work with CentOS.
I've never understood this.
If centos/whitebox/... wants to look like RHEL why not produce:
1. their centos-release rpm with appropriate files 2. an "redhat-release" rpm with required files ( /etc/redhat-release probably only) - then make sure that the rpm -qi redhat-release says "redhat-release rpm built to provide redhat compatibility" "This rpm is built on and for centos-a.b...."
Then everyone can use the normal redhat-release RPM or /etc/redhat-release checks (which are recompiled originals from redhat) without worrying if the system is a "clone" or not. The build server will show they are not built by redhat, and if you really care you can look for a centos-release rpm to see if it is a clone.
It is usually very easy to get these to work .. look at this example and search for redhat-release on the page:
http://www.puschitz.com/InstallingOracle10g.shtml
And it will tell you how to change your /etc/redhat-release file to allow there installers to function.
This would not be necessary if the above methodology were used.
Perhaps RH will sue the "RH clone" builders if they include a redhat-release rpm or /etc/redhat-release file? It would seem rather silly.
Simon
On Tue, 2006-01-10 at 22:21 +0100, Simon J Mudd wrote:
mailing-lists@hughesjr.com (Johnny Hughes) writes:
The only issue might be things that look specifically for something in /etc/redhat-release.
Obviously, we can't put the same line that RH puts in their product, so some installers (like Oracle) that specifically look for a string from upstream will not initially work with CentOS.
I've never understood this.
If centos/whitebox/... wants to look like RHEL why not produce:
- their centos-release rpm with appropriate files
- an "redhat-release" rpm with required files ( /etc/redhat-release probably only)
"redhat-release rpm built to provide redhat compatibility" "This rpm is built on and for centos-a.b...."
- then make sure that the rpm -qi redhat-release says
Then everyone can use the normal redhat-release RPM or /etc/redhat-release checks (which are recompiled originals from redhat) without worrying if the system is a "clone" or not. The build server will show they are not built by redhat, and if you really care you can look for a centos-release rpm to see if it is a clone.
It is usually very easy to get these to work .. look at this example and search for redhat-release on the page:
http://www.puschitz.com/InstallingOracle10g.shtml
And it will tell you how to change your /etc/redhat-release file to allow there installers to function.
This would not be necessary if the above methodology were used.
Perhaps RH will sue the "RH clone" builders if they include a redhat-release rpm or /etc/redhat-release file? It would seem rather silly.
While it would be rather silly ... we have been told not to make redhat- release say Trademarked things :)
On Tue, 2006-01-10 at 15:28, Johnny Hughes wrote:
Perhaps RH will sue the "RH clone" builders if they include a redhat-release rpm or /etc/redhat-release file? It would seem rather silly.
While it would be rather silly ... we have been told not to make redhat- release say Trademarked things :)
I'm not a lawyer, but I thought that if you wanted to keep your trademark you had to keep it from being used as a generic term. If third party apps must use the trademarked reference when they really want to test for a generic compatible OS, they've done something wrong. There was a time when the only way to get aspirin was to ask for a trademarked brand name...
On 1/10/06, Les Mikesell lesmikesell@gmail.com wrote:
On Tue, 2006-01-10 at 15:28, Johnny Hughes wrote:
Perhaps RH will sue the "RH clone" builders if they include a redhat-release rpm or /etc/redhat-release file? It would seem rather silly.
While it would be rather silly ... we have been told not to make redhat- release say Trademarked things :)
I'm not a lawyer, but I thought that if you wanted to keep your trademark you had to keep it from being used as a generic term. If third party apps must use the trademarked reference when they really want to test for a generic compatible OS, they've done something wrong. There was a time when the only way to get aspirin was to ask for a trademarked brand name...
The applications only want to support the actual Prominent North American... or what ever we should call them.
-- Leonard Isham, CISSP Ostendo non ostento.
On Tue, 2006-01-10 at 17:05, Leonard Isham wrote:
Perhaps RH will sue the "RH clone" builders if they include a redhat-release rpm or /etc/redhat-release file? It would seem rather silly.
While it would be rather silly ... we have been told not to make redhat- release say Trademarked things :)
I'm not a lawyer, but I thought that if you wanted to keep your trademark you had to keep it from being used as a generic term. If third party apps must use the trademarked reference when they really want to test for a generic compatible OS, they've done something wrong. There was a time when the only way to get aspirin was to ask for a trademarked brand name...
The applications only want to support the actual Prominent North American... or what ever we should call them.
Some applications might want to do that, but others may not. If the description always said XXX brand of YYY where YYY was a generic term then they could tell they had what they wanted either way.
____________________________________________________________
I'm not a lawyer, but I thought that if you wanted to keep your trademark you had to keep it from being used as a generic term. If third party apps must use the trademarked reference when they really want to test for a generic compatible OS, they've done something wrong. There was a time when the only way to get aspirin was to ask for a trademarked brand name...
The applications only want to support the actual Prominent North American... or what ever we should call them.
Some applications might want to do that, but others may not. If the description always said XXX brand of YYY where YYY was a generic term then they could tell they had what they wanted either way.
As Johnny said, we've been asked not to use certain trademarked items, and I don't really see any reason to go against that right now whether or not we're "technically" correct in doing so. There are plenty of other "open source" distributions like mandriva and suse, where rebuilding the corporate or EL version is nearly impossible, if not outright prohibited by the license agreement. RH supports the community as much as anyone else, and we do use their source packages, so if they say "we'd appreciate you not doing that" it's a reasonable thing. Add 2-3 lines of text manually, or bite the hand that feeds you. Not really a tough call for me.
-- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center
On Tue, 2006-01-10 at 17:55, Jim Perrin wrote:
XXX brand of YYY where YYY was a generic term then they could tell they had what they wanted either way.
As Johnny said, we've been asked not to use certain trademarked items, and I don't really see any reason to go against that right now whether or not we're "technically" correct in doing so. There are plenty of other "open source" distributions like mandriva and suse, where rebuilding the corporate or EL version is nearly impossible, if not outright prohibited by the license agreement. RH supports the community as much as anyone else, and we do use their source packages, so if they say "we'd appreciate you not doing that" it's a reasonable thing. Add 2-3 lines of text manually, or bite the hand that feeds you. Not really a tough call for me.
Of course, but it would be nice if 3rd party app packagers started asking how to detect the OS compatibility without referencing a brand name with the danger of letting it become generic.
-- Les Mikesell lesmikesell@gmail.com
On Tue, 2006-01-10 at 18:12 -0600, Les Mikesell wrote:
On Tue, 2006-01-10 at 17:55, Jim Perrin wrote:
XXX brand of YYY where YYY was a generic term then they could tell they had what they wanted either way.
As Johnny said, we've been asked not to use certain trademarked items, and I don't really see any reason to go against that right now whether or not we're "technically" correct in doing so. There are plenty of other "open source" distributions like mandriva and suse, where rebuilding the corporate or EL version is nearly impossible, if not outright prohibited by the license agreement. RH supports the community as much as anyone else, and we do use their source packages, so if they say "we'd appreciate you not doing that" it's a reasonable thing. Add 2-3 lines of text manually, or bite the hand that feeds you. Not really a tough call for me.
I agree 100% ... the upstream provider is extremely forthcoming with their GPL compliance. They are doing much more than is required by the GPL with respect to the way they distribute their SOURCES ... and the new Fedora Project is also extremely open.
That is not to say that we will just totally roll over on every single suggestion ... see the front page of CentOS.org for an example of how that is not happening. That said, CentOS does respect the trademarks and copyrights of others, and we will meet all reasonable requests by anyone.
Of course, but it would be nice if 3rd party app packagers started asking how to detect the OS compatibility without referencing a brand name with the danger of letting it become generic.
I also agree with this ... which is why we often ask FOSS companies to include support for CentOS directly. Many programs are doing that including Webmin, The GNU Telephony stack, Asterisk, Ensim, Qmail- Toaster, Virtuozzo, Plesk, cPanel ... and many, many more.
As paying customers of other programs continue to demand CentOS support, that list will continue to grow.
We are already growing unbelievably in the webserver market: http://www.centos.org/modules/news/article.php?storyid=109
On Tuesday 10 January 2006 05:22 pm, Johnny Hughes wrote:
I also agree with this ... which is why we often ask FOSS companies to include support for CentOS directly. Many programs are doing that including Webmin, The GNU Telephony stack, Asterisk, Ensim, Qmail- Toaster, Virtuozzo, Plesk, cPanel ... and many, many more.
As long as you mention cPanel, let me say that DirectAdmin does as well, with a simple:
cat /etc/redhat-release | cut -d\ -f5
to get the version number.
Jeff
On Tuesday 10 January 2006 02:29 pm, Les Mikesell wrote:
There was a time when the only way to get aspirin was to ask for a trademarked brand name...
The last time I was in Canada (a few years ago) that was still true. If you asked for Aspirin you got Bayer's Asprin brand.
Jeff
I find that the maintainers of the RPMs (at RedHat, and by reference, CentOS) are much more punctual in updating their stuff than I am. So, I prefer to use RPMs whereever possible.
To do it all yourself requires constant vigilance and I'm a busy guy...
In combination with yum, I'm almost never out of current; a problem I always had in the past. There are still a few things I have to compile and manage with checkinstall, but they are few, now.
Viva RPM and yum!
-Ben
On Monday 09 January 2006 00:18, Mickael Maddison wrote:
Hello CentOS,
I'm an old hat, and have been compiling my own MySQL, Apache, PHP, OpenSSL, ModSSL, etc. for my webservers for years. I'm playing around with the RPM installs on CentOS, and have basically been able to get most things setup so that they "function" about the same.
If I could stick to RPM's rather than compiling my own sources, it would save me a fair bit of time, but of course, it would limit the customization benefit. what I'm wondering, is if anyone on this list has any good reasons why one method would be better, more secure, etc than the other. I'm tempted to start using RPM's instead of compile sources.
Comments appreciated, thanks.
-- Best regards, Mickael mailto:centos@silverservers.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Bart Schaefer -
Benjamin Smith -
Chris Mauritz -
Eduardo Grosclaude -
Ignacio Vazquez-Abrams -
Jeff Lasman -
Jim Perrin -
Johnny Hughes -
Karanbir Singh -
Leonard Isham -
Les Mikesell -
Mickael Maddison -
Peter Farrow -
ryan -
Simon J Mudd -
Tim Edwards