Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
-- Dexter
Desire is the ingredient that changes the hot water of mediocrity to the steam of outstanding success. It's the ingredient that enables a person with average ability to successfully compete with those who have far more.
Ability is important--dependability is critical! See You At The Top
Dexter Stowers wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
take a look at the 'yum' package - and the options available with it. eg. 'yum list' will tell you what you need to know.
Also, its a good idea to subscribe to the CentOS-announce mailing list, all package updates are announced there. ( http://lists.centos.org/ )
Setting up rss feeds for the repositories as well, so you could / would / should be able to subscribe to only the repo+arch combinations you want to stay informed about... Lookout for an announcement about this shortly.
- K
On Mon, 2006-02-27 at 06:57, Karanbir Singh wrote:
Dexter Stowers wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
take a look at the 'yum' package - and the options available with it. eg. 'yum list' will tell you what you need to know.
Also, its a good idea to subscribe to the CentOS-announce mailing list, all package updates are announced there. ( http://lists.centos.org/ )
Setting up rss feeds for the repositories as well, so you could / would / should be able to subscribe to only the repo+arch combinations you want to stay informed about... Lookout for an announcement about this shortly.
Or you can just do a 'yum update' regularly and the right thing will happen.
Thanks a bunch...I appreciate the fast response!
-- Dexter
On 2/27/06, Les Mikesell lesmikesell@gmail.com wrote:
On Mon, 2006-02-27 at 06:57, Karanbir Singh wrote:
Dexter Stowers wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
take a look at the 'yum' package - and the options available with it. eg. 'yum list' will tell you what you need to know.
Also, its a good idea to subscribe to the CentOS-announce mailing list, all package updates are announced there. ( http://lists.centos.org/ )
Setting up rss feeds for the repositories as well, so you could / would / should be able to subscribe to only the repo+arch combinations you want to stay informed about... Lookout for an announcement about this shortly.
Or you can just do a 'yum update' regularly and the right thing will happen.
-- Les Mikesell lesmikesell@gmail.com
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Desire is the ingredient that changes the hot water of mediocrity to the steam of outstanding success. It's the ingredient that enables a person with average ability to successfully compete with those who have far more.
Ability is important--dependability is critical! See You At The Top
Les Mikesell wrote:
On Mon, 2006-02-27 at 06:57, Karanbir Singh wrote:
Dexter Stowers wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
take a look at the 'yum' package - and the options available with it. eg. 'yum list' will tell you what you need to know.
Also, its a good idea to subscribe to the CentOS-announce mailing list, all package updates are announced there. ( http://lists.centos.org/ )
Setting up rss feeds for the repositories as well, so you could / would / should be able to subscribe to only the repo+arch combinations you want to stay informed about... Lookout for an announcement about this shortly.
Or you can just do a 'yum update' regularly and the right thing will happen.
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
but, i guess that depends a lot on what you do and what your machines do :)
- K
On Mon, 2006-02-27 at 08:58, Karanbir Singh wrote:
Also, its a good idea to subscribe to the CentOS-announce mailing list, all package updates are announced there. ( http://lists.centos.org/ )
Setting up rss feeds for the repositories as well, so you could / would / should be able to subscribe to only the repo+arch combinations you want to stay informed about... Lookout for an announcement about this shortly.
Or you can just do a 'yum update' regularly and the right thing will happen.
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
but, i guess that depends a lot on what you do and what your machines do :)
You still have to answer 'yes' to a "yum update' after it shows you the list it plans to update, so assuming you answer correctly it will always do the right thing. If you do it fairly often, the list will only be large at point release times so you won't have much trouble deciding whether it is likely to break something or not. Or, if you have a place to test, do it there first. In general, I'll assume that the people generating the updates know more about the programs than I do and thus it is worse to avoid the update than apply it. If you've watched this list for a while, you'll know that you don't see a lot of 'update xxx broke something', although it is always possible.
Les Mikesell wrote:
On Mon, 2006-02-27 at 08:58, Karanbir Singh wrote:
Also, its a good idea to subscribe to the CentOS-announce mailing list, all package updates are announced there. ( http://lists.centos.org/ )
Setting up rss feeds for the repositories as well, so you could / would / should be able to subscribe to only the repo+arch combinations you want to stay informed about... Lookout for an announcement about this shortly.
Or you can just do a 'yum update' regularly and the right thing will happen.
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
but, i guess that depends a lot on what you do and what your machines do :)
You still have to answer 'yes' to a "yum update' after it shows you the list it plans to update, so assuming you answer correctly it will always do the right thing. If you do it fairly often, the list will only be large at point release times so you won't have much trouble deciding whether it is likely to break something or not. Or, if you have a place to test, do it there first. In general, I'll assume that the people generating the updates know more about the programs than I do and thus it is worse to avoid the update than apply it. If you've watched this list for a while, you'll know that you don't see a lot of 'update xxx broke something', although it is always possible.
we seem to be talking about disconnected issues.
On Mon, 2006-02-27 at 13:34, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
but, i guess that depends a lot on what you do and what your machines do :)
You still have to answer 'yes' to a "yum update' after it shows you the list it plans to update, so assuming you answer correctly it will always do the right thing.
we seem to be talking about disconnected issues.
Maybe. I thought you were saying it is better to understand what's broken than to get the fix.
Les Mikesell wrote:
On Mon, 2006-02-27 at 13:34, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
but, i guess that depends a lot on what you do and what your machines do :)
You still have to answer 'yes' to a "yum update' after it shows you the list it plans to update, so assuming you answer correctly it will always do the right thing.
we seem to be talking about disconnected issues.
Maybe. I thought you were saying it is better to understand what's broken than to get the fix.
:) always get the fix. no questions about that.
my initial post was just on how Dexter could stay in touch with updates being released...
- KB
Thanks guys...I really do appreciate your help!
-- Dexter
On 2/27/06, Karanbir Singh mail-lists@karan.org wrote:
Les Mikesell wrote:
On Mon, 2006-02-27 at 13:34, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
but, i guess that depends a lot on what you do and what your machines do :)
You still have to answer 'yes' to a "yum update' after it shows you the list it plans to update, so assuming you answer correctly it will always do the right thing.
we seem to be talking about disconnected issues.
Maybe. I thought you were saying it is better to understand what's broken than to get the fix.
:) always get the fix. no questions about that.
my initial post was just on how Dexter could stay in touch with updates being released...
- KB
-- Karanbir Singh : http://www.karan.org/ : 2522219@icq _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Desire is the ingredient that changes the hot water of mediocrity to the steam of outstanding success. It's the ingredient that enables a person with average ability to successfully compete with those who have far more.
Ability is important--dependability is critical! See You At The Top
On Monday 27 February 2006 06:58, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
The answer can be found here:
yes "n" | yum update
Benjamin Smith wrote:
On Monday 27 February 2006 06:58, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
The answer can be found here:
yes "n" | yum update
I hope you dont do sysadmin as a profession. if you do - I fear for the people you run servers for. :)
On Monday 27 February 2006 14:32, Karanbir Singh wrote:
Benjamin Smith wrote:
On Monday 27 February 2006 06:58, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
The answer can be found here:
yes "n" | yum update
I hope you dont do sysadmin as a profession. if you do - I fear for the people you run servers for. :)
You provide only a vague reference to god-knows-what form of impending doom, so perhaps you aren't aware of what `yes "n" | yum update` actually does? Do you need to read it a bit closer?
Perhaps you have a better way to find out what packages are reported by yum as ready for update that you might want to test first?
And I yes, I do sysadmin work as an integral part of my profession...
-Ben
On Tue, Feb 28, 2006 at 07:16:51PM -0800, Benjamin Smith enlightened us:
I hope you dont do sysadmin as a profession. if you do - I fear for the people you run servers for. :)
You provide only a vague reference to god-knows-what form of impending doom, so perhaps you aren't aware of what `yes "n" | yum update` actually does? Do you need to read it a bit closer?
Perhaps you have a better way to find out what packages are reported by yum as ready for update that you might want to test first?
yum check-update
On Tuesday 28 February 2006 19:24, Matt Hyclak wrote:
Perhaps you have a better way to find out what packages are reported by
yum as
ready for update that you might want to test first?
yum check-update
Is that the best you can come up with? This is worthy of the scathing (but vague) criticism I saw earlier? Isn't this sorta like sayi ng that "cat foo | grep NNN" is not nearly as good as "grep NNN foo" ? They appear largely equivalent, for all intents and purposes... the output even looks similar.
Hey, whatever floats your boat, I guess. I'm certainly not worried about my client's well-being because I used one over the other.
yum check-update
Is that the best you can come up with?
Given that it's the way specifically written into the program and documentation for just this thing, I'd say yes.. it is the best.
This is worthy of the scathing (butvague) criticism I saw earlier?
You didn't see it from Matt. You saw the proper documented method.
Isn't this sorta like saying that "cat foo | grep NNN" is not nearly as good as "grep NNN foo" ? They appear largely equivalent, for all intents and purposes... the output even looks similar.
That's not a perfect analogy, but given the situation, it's pretty good. Yes, the output looks the same, and most people won't notice or care, but there's overhead and extra system work in getting the answer. Scalability and performance over load where it counts is what makes a good admin. It's the attention to detail and the drive to do things the right way, not just the way that yeilds the proper answer.
Hey, whatever floats your boat, I guess. I'm certainly not worried about my client's well-being because I used one over the other.
I'd like this to not end up in typical flame session, and you're right.. your clients may not suffer from your way, but it's not the 'documented way'. This really is not meant to be personal, or an attack, so try not to take it that way. Your way is a hack, and is evidence of not reading the documentation. It's a functional solution, but not the right one. There is a difference.
If you're going to make something your profession, do it to the best of your ability no matter what it is. Know the tools you use inside and out. And always remember, you can bill the customer for the time you spend reading the documentation if you don't immediately know the right answer. If you don't believe me, ask a lawyer what they bill for. Might help to have some cash handy just in case they bill you for the answer.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
This is a discussion.
It gets personal when I see "dear god I'd hate to be one of your clients...". But notice that rather than flame away, and highlight Mom's relationship with Dad, I did ask for reasoning to support the criticism. Perhaps some emotion is involved, but there's also a chance you or I might learn something here.
On Tuesday 28 February 2006 20:16, Jim Perrin wrote:
Isn't this sorta like saying that "cat foo | grep NNN" is not nearly as good as "grep NNN foo" ? They appear largely equivalent, for all intents and purposes... the output even looks similar.
That's not a perfect analogy, but given the situation, it's pretty good. Yes, the output looks the same, and most people won't notice or care, but there's overhead and extra system work in getting the answer. Scalability and performance over load where it counts is what makes a good admin. It's the attention to detail and the drive to do things the right way, not just the way that yeilds the proper answer.
It seems to me that you are dealing with premature optimization. How much are you willing to make your clients pay to read documentation that provides little discernable benefit? Are they aware that they are, in fact, paying for time with marginal value?
I write software, and do what works first, balancing knowing every permutation of every option with simply getting the job done competently. Performance optimization generally comes fairly late in the game, after initial spec, design, implementation, testing, and frequently, deployment. Even in large codebases, it's surprising how often tweaking just a few (perhaps a dozen?) key points can result in vast performance increases of the system at large, with very little time wasted on "optimization".
In this case, the performance penalty of the "yes" shell command doesn't even qualify for consideration, and the job gets done competently in either case.
Your way is a hack, and is evidence of not reading the documentation. It's a functional solution, but not the right one. There is a difference.
The *nix environment is not only tolerant of such "hacks", but is actually designed to encourage it. Small tools, cobbled together to get whatever you need out. See http://www.linuxlots.com/~dunne/unix-philosophy.html
Compare this idea with "more than one way to skin a cat".
If you're going to make something your profession, do it to the best of your ability no matter what it is.
"Best" isn't some ivory tower ideal based on zen-like knowledge. "Best" is getting the most done for the least amount of customer's money. Happy customers == repeat business + referrals == 6-figure incomes + longevity + security. Overcharged customers == bankrupt customers + negative remarks == average incomes + high turnover + financial insecurity.
Know the tools you use inside and out.
It's naive to think that the average person could be intimately familiar with *ALL* aspects of the *nix environment. There's simply too much accumulated over the past 30 years. Just to keep up with current developments in their entirety is not possible, even assuming omnipotent knowledge of the present scene.
Far better to set sights that are comfortably attainable, to ensure that you know enough to do the job sensibly and professionally, and invest a percentage (I'd suggest about 10%) of your time in ongoing research and self-improvement.
And always remember, you can bill the customer for the time you spend reading the documentation if you don't immediately know the right answer. If you don't believe me, ask a lawyer what they bill for. Might help to have some cash handy just in case they bill you for the answer.
Sure, but keep in mind above comments about premature optimization. I'd be sorely upset if I asked my lawyer to review a contract, and he spent 3 weeks at my expense researching the legal definition and derivatives of every single word used. And, this degree of research could be justified by the phrase "knowing it inside and out". He should know what words are key, and do just enough research to reasonably determine that I'm not about to make a mistake I'll regret.
In short, while it's immature to expect to know every facet of every tool, it's expertise to know what facets of the available tools are actually relevant and worthy of time investment to get the job done well.
-Ben
That's not a perfect analogy, but given the situation, it's pretty good. Yes, the output looks the same, and most people won't notice or care, but there's overhead and extra system work in getting the answer. Scalability and performance over load where it counts is what makes a good admin. It's the attention to detail and the drive to do things the right way, not just the way that yeilds the proper answer.
It seems to me that you are dealing with premature optimization. How much are you willing to make your clients pay to read documentation that provides little discernable benefit? Are they aware that they are, in fact, paying for time with marginal value?
Hey you hit the reason why I said it wasn't a perfect analogy, but you veered to the left at the last moment and took it a tad to literally.
I write software, and do what works first, balancing knowing every permutation of every option with simply getting the job done competently. Performance optimization generally comes fairly late in the game, after initial spec, design, implementation, testing, and frequently, deployment. Even in large codebases, it's surprising how often tweaking just a few (perhaps a dozen?) key points can result in vast performance increases of the system at large, with very little time wasted on "optimization".
More of the same from above. Taking my inital point a bit too literally.
In this case, the performance penalty of the "yes" shell command doesn't even qualify for consideration, and the job gets done competently in either case.
It gets the job done. Competently is up for discussion, as this thread indicates.
Your way is a hack, and is evidence of not reading the documentation. It's a functional solution, but not the right one. There is a difference.
The *nix environment is not only tolerant of such "hacks", but is actually designed to encourage it. Small tools, cobbled together to get whatever you need out. See http://www.linuxlots.com/~dunne/unix-philosophy.html
Compare this idea with "more than one way to skin a cat".
Do you use a chainsaw, or a tool built specifically for skinning cats (that in this case is BUILT INTO THE CAT) ? They both work. There are varying degrees of right. Your way works, and I never said it didn't; however there's a way documented 'better way'.
If you're going to make something your profession, do it to the best of your ability no matter what it is.
Know the tools you use inside and out.
I don't do consulting as my primary business, so I have the luxury to not have to be all things to all people. I specialize in a few toolsets, and I do make an effort to know them inside and out. Sure there are things you miss, but I'd rather focus on doing one group of things well, than having a passing knowledge of most everything else.
It's naive to think that the average person could be intimately familiar with *ALL* aspects of the *nix environment. There's simply too much accumulated over the past 30 years. Just to keep up with current developments in their entirety is not possible, even assuming omnipotent knowledge of the present scene. Far better to set sights that are comfortably attainable, to ensure that you know enough to do the job sensibly and professionally, and invest a percentage (I'd suggest about 10%) of your time in ongoing research and self-improvement.
Given that yum is the primary means for updating centos systems, I'd say if falls squarely in your realm of 'know enough to do the job sensibly and professionally' and yet from all appearances you didn't even glance at the man page for it, as check-update is at the very top of the documentation, and is the 3rd item under *command*. It's right under description. THAT seems to be the primary factor that started this insanity/flamefest/discussion/whatever. Emotion aside, would you as a customer knowingly hire someone who ignored the documentation for updating the OS of a mission critical system? Whether it's an accurate statement or not, that is the perception you gave with your hack.
And always remember, you can bill the customer for the time you spend reading the documentation if you don't immediately know the right answer. If you don't believe me, ask a lawyer what they bill for. Might help to have some cash handy just in case they bill you for the answer.
Sure, but keep in mind above comments about premature optimization. I'd be sorely upset if I asked my lawyer to review a contract, and he spent 3 weeks at my expense researching the legal definition and derivatives of every single word used. And, this degree of research could be justified by the phrase "knowing it inside and out". He should know what words are key, and do just enough research to reasonably determine that I'm not about to make a mistake I'll regret.
No new counterpoint here. same as above. Yum is your key word, and you appear to have not looked it up.
In short, while it's immature to expect to know every facet of every tool, it's expertise to know what facets of the available tools are actually relevant and worthy of time investment to get the job done well.
Covered this above.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
On Tue, Feb 28, 2006 at 07:41:17PM -0800, Benjamin Smith enlightened us:
Perhaps you have a better way to find out what packages are reported by
yum as
ready for update that you might want to test first?
yum check-update
Is that the best you can come up with? This is worthy of the scathing (but vague) criticism I saw earlier? Isn't this sorta like sayi ng that "cat foo | grep NNN" is not nearly as good as "grep NNN foo" ? They appear largely equivalent, for all intents and purposes... the output even looks similar.
Hey, whatever floats your boat, I guess. I'm certainly not worried about my client's well-being because I used one over the other.
First of all, you need to settle down. Maybe then you would have noticed that I had nothing to do with the "scathing criticism". You asked a question, I provided an answer. No, it probably doesn't make a difference if you use your method or mine, however I propose that the yum command above is a lot less prone to accidentally updating a system that you just wanted to check updates for.
Matt
Benjamin Smith wrote:
On Monday 27 February 2006 14:32, Karanbir Singh wrote:
Benjamin Smith wrote:
On Monday 27 February 2006 06:58, Karanbir Singh wrote:
depends on what you do, on a lot of production machines, people prefer to first know about the issues being fixed, and testing updates before they go live.
The answer can be found here:
yes "n" | yum update
I hope you dont do sysadmin as a profession. if you do - I fear for the people you run servers for. :)
You provide only a vague reference to god-knows-what form of impending doom, so perhaps you aren't aware of what `yes "n" | yum update` actually does? Do you need to read it a bit closer?
Perhaps you have a better way to find out what packages are reported by yum as ready for update that you might want to test first?
And I yes, I do sysadmin work as an integral part of my profession...
you missed the point completely .... specifically the portion about "....first know about the issues being fixed..." - you want to tell me how a yum list is going to explain the issues being fixed in the pkgs ?
I guess you could parse the pkgnames into a yum-downloader script and then --changelog check each.. suppose, that might work. But apart from that, for critical apps, I've always recommended people look at the issues before rolling out. eg. if you run a 5 million emails/day setup on postfix-mysql, it might be a good idea to make sure those connectors work before the yum update rollout.
I propose that we all take some time away from posting to this thread as it's clear that emotion and ego are now at stake. Instead take a moment to bask in the wisdom of Strongbad's knowledge of technology http://homestarrunner.com/sbemail143.html (requires flash). If you have even the slightest sense of humor, it'll calm you right down and make you smile.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
On 01/03/06, Jim Perrin jperrin@gmail.com wrote:
I propose that we all take some time away from posting to this thread as it's clear that emotion and ego are now at stake. Instead take a moment to bask in the wisdom of Strongbad's knowledge of technology http://homestarrunner.com/sbemail143.html (requires flash). If you have even the slightest sense of humor, it'll calm you right down and make you smile.
"The word technology means... magic", "and when it breaks you need to buy a new one."
Heh.
Quick commands inlcude:
# list updates yum check-update
# install all necesary updates for sendmail httpd php openssh yum -y update sendmail httpd php openssh
# update all your system, not always recomended. Update manually your critical services first yum -y update
HTH Oliver
Dexter Stowers wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
-- Dexter
Desire is the ingredient that changes the hot water of mediocrity to the steam of outstanding success. It's the ingredient that enables a person with average ability to successfully compete with those who have far more.
Ability is important--dependability is critical! See You At The Top _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--- Dexter Stowers dexter.stowers@gmail.com wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
-- Dexter
Are you serious? Running a server for a year without updates? If you don't mind my asking were you living in a cave or something? I hope you don't use the same principles on Windows are you will be 40,000 viruses/trojans and malware worse off!!
I don't supppose you run Mambo/phpbb/phpnuke on the internet. They have had security issues that can allow a remote attacker to take over your machine.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Jim Smith wrote:
Are you serious? Running a server for a year without updates? If you don't mind my asking were you living in a cave or something? I hope you don't use the same principles on Windows are you will be 40,000 viruses/trojans and malware worse off!!
I also have a server that I have not updated since the original CentOS 4. And not only that, I will not update it.
Why?
1. It works. 2. It's a database server. 3. There are no user logged unless it's me. 4. There is no connection to Internet, only internal users are allowed and it has its own firewall. 5. Why take the chance that something will break?
I have a few CentOS 4.1 workstations that I can't fully upgrade because 4.2 broke X with some ATI cards, and those workstations have ATI cards. There are no problem with the nVidia cards, including the hardware acceleration. It's a problem in the ATI driver.
So why should I risk the database server go down?
On Mon, 2006-02-27 at 14:47 -0800, centos@911networks.com wrote:
Jim Smith wrote:
Are you serious? Running a server for a year without updates? If you don't mind my asking were you living in a cave or something? I hope you don't use the same principles on Windows are you will be 40,000 viruses/trojans and malware worse off!!
I also have a server that I have not updated since the original CentOS 4. And not only that, I will not update it.
Why?
- It works.
- It's a database server.
- There are no user logged unless it's me.
- There is no connection to Internet, only internal users are
allowed and it has its own firewall. 5. Why take the chance that something will break?
I have a few CentOS 4.1 workstations that I can't fully upgrade because 4.2 broke X with some ATI cards, and those workstations have ATI cards. There are no problem with the nVidia cards, including the hardware acceleration. It's a problem in the ATI driver.
So why should I risk the database server go down?
If you are not connected to the internet, then that is fine ... for machines that are connected to the internet, security updates need to be applied when they are released.
On Mon, 2006-02-27 at 16:47, centos@911networks.com wrote:
I also have a server that I have not updated since the original CentOS 4. And not only that, I will not update it.
Why?
- It works.
- It's a database server.
- There are no user logged unless it's me.
- There is no connection to Internet, only internal users are
allowed and it has its own firewall. 5. Why take the chance that something will break?
Do you trust everyone with access to your internal network?
On Mon, 2006-02-27 at 20:46 -0600, Les Mikesell wrote:
On Mon, 2006-02-27 at 16:47, centos@911networks.com wrote:
I also have a server that I have not updated since the original CentOS 4. And not only that, I will not update it.
Why?
- It works.
- It's a database server.
- There are no user logged unless it's me.
- There is no connection to Internet, only internal users are
allowed and it has its own firewall. 5. Why take the chance that something will break?
Do you trust everyone with access to your internal network?
Good point, I know I don't ... I work at a company with 42 plants all over the world and I don't trust everybody there. We have had in the past issues with windows worms take out the network and the same is possible with Linux. There is also fact that somebody could possibly plug a foreign PC into the network with a nasty payload..
Paul Berger
centos@911networks.com wrote:
I also have a server that I have not updated since the original CentOS 4. And not only that, I will not update it.
Why?
- It works.
But not as well as it could work!
- It's a database server.
It will continue to be a database server even after the update.
- There are no user logged unless it's me.
well, users dont need to be log'ed in locally in order to exploit vuln's and issues that your system might have. Or to benefit from updates and improvements being pushed down the pkg's
and if you also dont have any remote users - why not just turn it off in that case ? if noone is using it ?
- There is no connection to Internet, only internal users are allowed
and it has its own firewall.
read my reply to your point no.3 - applicable here too.
- Why take the chance that something will break?
becuase you could get better performance, ( there have been atleast a few kernel improvements in the last few months - that have a direct effect on performance ). You will also get a more 'supported' update cycle and better driver support etc etc etc ( lots and lots of things, pointless mentioning them here ).
This issue of 'risk' with updates is a very 'gentoo'ish / fedora'ish / ubuntu'ish state of mindset. Where, once things work - you leave them alone. On CentOS / RHEL the aim of having a long lifecycle and a supported platform, is to minimise this 'risk' effect, to a level where its practical in a production environment - to run the updates.
plus. if things are so critical for you - test it offline on a non production machine, then sync the updates into production!
- KB
If you are a control freak (like the Debian devs), then have a similar server like your database server and THEN FIRST apply any updates to that one. Then you have the chance to see if anything breaks. However doesn't your database/other apps need upgrades/bug fixes? Some bugs could lead in extreme cases to data corruption.
It sounds as if you are unusually paranoid, what database is that you are running that does not need updates even from the vendor?
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
This server was not online. It has been running in a backroom and I have not had a chance to get to work on it. I had setup another server in its place and now I want to use this machine for another purpose. My other machines are running RHEL AS 4. This is the reason why I have been out of the loop as to what has been going on with CentOS. Thank you for your concern.
-- Dexter
On 2/27/06, Jim Smith jim_smith2006@yahoo.com wrote:
--- Dexter Stowers dexter.stowers@gmail.com wrote:
Hi, I have a server that has been running Centos for about a year but I have not checked to see if there have been any changes to update. Has there been any updates or fixes for the update? I have not been in the loop for a while now. Thanks!
-- Dexter
Are you serious? Running a server for a year without updates? If you don't mind my asking were you living in a cave or something? I hope you don't use the same principles on Windows are you will be 40,000 viruses/trojans and malware worse off!!
I don't supppose you run Mambo/phpbb/phpnuke on the internet. They have had security issues that can allow a remote attacker to take over your machine.
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Desire is the ingredient that changes the hot water of mediocrity to the steam of outstanding success. It's the ingredient that enables a person with average ability to successfully compete with those who have far more.
Ability is important--dependability is critical! See You At The Top
When is it necessary to reboot after an update? Is there a way to exclude those packages from the update until you're able to reboot the box? eg kernel updates.
Thanks
Marc Peiser wrote:
When is it necessary to reboot after an update? Is there a way to exclude those packages from the update until you're able to reboot the box? eg kernel updates.
kernel, glibc, ssl issues - thats when I usually end up rebooting after an update.
- K
Marc Peiser wrote:
When is it necessary to reboot after an update? Is there a way to exclude those packages from the update until you're able to reboot the box? eg kernel updates.
Thanks _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
The only update I know that requires a reboot are the Kernel updates, all others generally require a stop/start of the service and your on the way again. You can excluded the kernel updates by adding a line in your config files. If you use multiple repo files then you will need to either put the exclude in all of them that offer Kernel updates or put it in the yum.conf file.
Zeb
-
Benjamin Smith -
centos＠911networks.com -
Dexter Stowers -
Jim Perrin -
Jim Smith -
Johnny Hughes -
Karanbir Singh -
Les Mikesell -
Marc Peiser -
Matt Hyclak -
Oliver Schulze L. -
Paul -
Will McDonald -
Zeb Fletcher