I've apparently gotten myself into somewhat of a bind. I've been trying to exclude various packages from the different repos, and while I *think* I've gotten a working configuration again, it it still pulling stuff in that I have excluded I think in the right repos, but things I have no use for whatsoever. Items like kernel-hugemem-devel, kernel-hugemem, and anything involving kernel development. I run a stock kernel and am not doing any building of any kind at this point. The machine is an i-686 machine, and a single processor. I'd be very much appreciative if someone could send me,, or post a proper repo config that points to the various exclude lines to get rid of some of the unnecessary files. It's taken me about 2 hours of modifying stuff to finally get a yum repo config to make it all the way thru.
Any type of help here would be great!
Thanking you in advance,
Sam
On Friday 18 July 2008 12:56:30 pm Sam Drinkard wrote:
I've apparently gotten myself into somewhat of a bind. I've been trying to exclude various packages from the different repos, and while I *think* I've gotten a working configuration again, it it still pulling stuff in that I have excluded I think in the right repos, but things I have no use for whatsoever. Items like kernel-hugemem-devel, kernel-hugemem, and anything involving kernel development. I run a stock kernel and am not doing any building of any kind at this point. The machine is an i-686 machine, and a single processor.
OK, I'm still new to centos, so I could have a misunderstanding of this so others may feel free to correct me if I am wrong.
First, which version of centos are you using? Also, how much memory are you using? "hugemem" means "huge memory" and, to my understanding was introduced to allow for memory in excess of 4 GB. If your system has over 4 GB, it could be loading that kernel because that is what you need.
The kernel headers or kernel development may well be need at the time of install. In another distribution I used, to install and use nvidia video card drivers, the install script requires the kernel headers to build the appropriate module or some such thing. It has been a while since I installed the OS, so I don't recall the specifics.
As I have said, I'm new to centos and not sure how things are done in this part of the Linux world, so don't take my word as gospel and I' won't get offended if someone corrects me.
Well to start, I'm not that new to CentOS, but I've never used yum except to keep things up to date, but after reading a lot of articles, I started adding software I'd never used before, and unfortunately, the most up to date versions came from repositories which I thought were all the same. I never realized there were multiple sources where bits could be obtained, yet of different versions. That's my fault. Prior to migrating to Linux, I'd been a BSD person, and with BSD, you had one source of software, and you didn't have to worry about different versions from different sources, as everything was located within a central source.
My current version is 4.6, and it most likely where I'll stay for some time, as the software I use has most likely not been tested or rebuilt for later versions, but I'm behind on the weather software itself. The server at my co-lo site has only 512m memory, and the server here at my house has 2G, so I don't think I need the huge-mem kernel for the downtown location, nor here for that matter. Essentially, I only use the stock kernel, whatever version happens to be current, and even with that said, I don't reboot every time a kernel comes out because of a problem with remote reboots which fails most of the time, and it's difficult to get into the co-lo site, and the ISP does not keep personnel at the building all the time. Only when someone needs to get in, or has a problem will they send someone downtown.
Based on my past 3 years of running CentOS, I'll admit I'm not nearly as up to speed with various aspects of it and a lot of the tools available. Only in the past few days did I realize within the various repo files, were they subdivided into the various areas by name. To make a long story short, I'd just like to be able to keep up essentially the base software on the server(s) and not have to worry about getting files mixed up like I was told by numbers of folks. Just did not sink in from previous messages stating the same thing. At any rate, I did manage to get some stuff fixed yesterday, but yum is still pulling in some of the kernel stuff that I don't need or want, and that's the basis for my request for help.
Thanks for your reply,
Sam
On Sat, Jul 19, 2008 at 9:49 AM, Sam Drinkard sam@wa4phy.net wrote:
Well to start, I'm not that new to CentOS, but I've never used yum except to keep things up to date, but after reading a lot of articles, I started adding software I'd never used before, and unfortunately, the most up to date versions came from repositories which I thought were all the same. I never realized there were multiple sources where bits could be obtained, yet of different versions. That's my fault. Prior to migrating to Linux, I'd been a BSD person, and with BSD, you had one source of software, and you didn't have to worry about different versions from different sources, as everything was located within a central source.
Suggest that you install and configure the yum-plugin-priorities plug in
yum install yum-plugin-priorities
http://wiki.centos.org/PackageManagement/Yum/Priorities
and read up on Yum Repositories
http://wiki.centos.org/AdditionalResources/Repositories?action=show&redirect=Repositories
My current version is 4.6, and it most likely where I'll stay for some time, as the software I use has most likely not been tested or rebuilt for later versions, but I'm behind on the weather software itself. The server at my co-lo site has only 512m memory, and the server here at my house has 2G, so I don't think I need the huge-mem kernel for the downtown location, nor here for that matter. Essentially, I only use the stock kernel, whatever version happens to be current, and even with that said, I don't reboot every time a kernel comes out
IMHO, you need to keep your server up to date, for security reasons, so that it is your server and not someone elses server that you are paying for. If you do not reboot after updating the kernel, I don't think you are running the new kernel and I don't think you are getting whatever additional security is available in the new kernel.
because of a problem with remote reboots which fails most of the time, and it's difficult to get into the co-lo site, and the ISP does not keep personnel at the building all the time. Only when someone needs to get in, or has a problem will they send someone downtown.
PITA. Suggest you look for another colo site or get a Dedicated Box somewhere where the Remote Reboots work properly. Not being able to get to your box, when you need to, is not a good thing. Bad service on the part of your ISP.
Based on my past 3 years of running CentOS, I'll admit I'm not nearly as up to speed with various aspects of it and a lot of the tools available. Only in the past few days did I realize within the various repo files, were they subdivided into the various areas by name. To make a long story short, I'd just like to be able to keep up essentially the base software on the server(s) and not have to worry about getting files mixed up like I was told by numbers of folks. Just did not sink in from previous messages stating the same thing. At any rate, I did manage to get some stuff fixed yesterday, but yum is still pulling in some of the kernel stuff that I don't need or want, and that's the basis for my request for help.
Sam: I suggest you do some reading on the Wiki at centos.org and begin to understand what you can do, to make your Server more secure: (a) not allowing root logins (b) not using passwords (using keys) and (c) a ton of other things. Keeping your server up to date and as secure as possible takes time but is worth the investment of your time. 73, Lanny
Hi Lanny,
Well, for the most part, I have all the security issues taken care of w/r/t logins, ssh, no root logins, etc. My main problem is as I stated is the fact that the co-lo site is somewhat difficult to get access to, however if I call the office, someone will meet me at the place and let me in, and give me all the time I need to do whatever is needed. For $25/mo, I doubt seriously I could find another ISP that would let me have access to a DS-3 line for said amount. It started out years ago, and I think the co-lo fee now for a DS-3 service runs in excess of $250./mo, so I put up with a bit of inconvenience to retain a low fee for the location. As for the reboot problem, I think it's related to the ACPI on the box, and at times, it will remote reboot, but I don't usually risk it, and yes, while the kernel is updated I don't immediately reboot after an update because of the chances the box won't come back up. It's odd that it will work sometimes, but most times I does not, and that dictates a trip downtown, or having one of the ISP's staff yank power and repower the box. I'd considered replacing the machine, but it's less than a year old, or perhaps maybe a tad older.. don't have the install notes handy, but since the machine is my only mail server and the only way I have to send/receive mail, that makes it a very critical operation. I do have some weather related web pages that are served by it, but for the most part, it's a low volume server. Believe me, if I had the $$ to install a more reliable box there, I'd do it it a heartbeat. I'd also considered moving the server here at home downtown, but then that move would create a whole set of new problems I just don't want to deal with. If I can keep things running regardless of what version of kernel is currently running, and there are no problems w/r/t the actual serving of web pages or mail, that is the ultimate goal. Current uptime is something over 150 days, and I have no clue what /when the last reboot took place. It just works... which I'm very happy to state.
Given all the various aspects of the server, the physical site situations, and the factors of money, I detest change as long as stuff works as advertised! My favorite motto is "if it ain't broke, don't try to fix it"... lol. I know I need to get myself up to speed w/r/t yum and the various repos. I do have the priorities plugins installed, but I"m not 100% sure that it is configured right, just as the protect base stuff. I don't have a lot of time to delve into the innards of stuff like I used to, and I have taken the posture of using the defaults for most because people a lot smarter than me have done the grunt work and I can only assume that they configure stuff that works for most people or "appliance operators" like myself. At any rate, once I get something fixed to take care of my needs, I generally don't mess with it further unless absolutely required. May not be the best method, but it's worked for me for a lot of years both with BSD and CentOS.
I'll definitely check out the links you provided and see what I can glean from them. I'm not the young buck I used to be, and it takes me some time for new ideas and such to finally take hold. The inner workings of an OS is not for the faint of mind like me, and yeah, there are some 60 year olds that still are making inroads to technology, I am, unfortunately not one of them, but I just try to stay semi-current with whatever the issue happens to be. It's just not fun getting old... and it creates a big problem at times..
Thanks..
Sam
On Sun, Jul 20, 2008 at 8:43 AM, Sam Drinkard sam@wa4phy.net wrote:
Hi Lanny, Well, for the most part, I have all the security issues taken care of w/r/t logins, ssh, no root logins, etc.
Excellent!
My main problem is as I stated is the fact that the co-lo site is somewhat difficult to get access to, however if I call the office, someone will meet me at the place and let me in, and give me all the time I need to do whatever is needed. For $25/mo, I doubt seriously I could find another ISP that would let me have access to a DS-3 line for said amount. It started out years ago, and I think the co-lo fee now for a DS-3 service runs in excess of $250./mo,
Colos are expensive. $25 is dirt cheap for a colo. If you ever get tired of the setup you have now, you can get a Refurbished box from olm.net (and probably a lot of other reputable companies) for $30+ a month, but it won't have Remote Reboot at that price. That's $5 a month extra.
so I put up with a bit of inconvenience to retain a low fee for the location. As for the reboot problem, I think it's related to the ACPI on the box, and at times, it will remote reboot, but I don't usually risk it, and yes, while the kernel is updated I don't immediately reboot after an update because of the chances the box won't come back up. It's odd that it will work sometimes, but most times I does not, and that dictates a trip downtown, or having one of the ISP's staff yank power and repower the box. I'd considered replacing the machine, but it's less than a year old, or perhaps maybe a tad older.. don't have the install notes handy, but since the machine is my only mail server and the only way I have to send/receive mail, that makes it a very critical operation. I do have some weather related web pages that are served by it, but for the most part, it's a low volume server. Believe me, if I had the $$ to install a more reliable box there, I'd do it it a heartbeat. I'd also considered moving the server here at home downtown, but then that move would create a whole set of new problems I just don't want to deal with. If I can keep things running regardless of what version of kernel is currently running, and there are no problems w/r/t the actual serving of web pages or mail, that is the ultimate goal. Current uptime is something over 150 days, and I have no clue what /when the last reboot took place. It just works... which I'm very happy to state.
Sounds like the box is extremely reliable. Are you sure it is not their Remote Reboot that is not working properly on your box?
Given all the various aspects of the server, the physical site situations, and the factors of money, I detest change as long as stuff works as advertised! My favorite motto is "if it ain't broke, don't try to fix it"... lol. I know I need to get myself up to speed w/r/t yum and the various repos. I do have the priorities plugins installed, but I"m not 100% sure that it is configured right, just as the protect base stuff.
You are not using both Priorities and Protect Base are you? Use one or the other, preferably Priorities.
http://lists.centos.org/pipermail/centos/2008-June/101142.html
<snip>
I'll definitely check out the links you provided and see what I can glean from them. I'm not the young buck I used to be, and it takes me some time for new ideas and such to finally take hold. The inner workings of an OS is not for the faint of mind like me, and yeah, there are some 60 year olds that still are making inroads to technology, I am, unfortunately not one of them, but I just try to stay semi-current with whatever the issue happens to be. It's just not fun getting old... and it creates a big problem at times..
Also 60+ here. I got my Novice license in 1955.
73,
Lanny, HK5MDT
<snip>
because of a problem with remote reboots which fails most of the time, and it's difficult to get into the co-lo site, and the ISP does not keep personnel at the building all the time. Only when someone needs to get in, or has a problem will they send someone downtown.
PITA. Suggest you look for another colo site or get a Dedicated Box somewhere where the Remote Reboots work properly. Not being able to get to your box, when you need to, is not a good thing. Bad service on the part of your ISP.
Also see if your colo site offers some sort of remote access/reboot system. Many are only a ssh (prefered) or telnet to a odd numbered port that maps directly to your systems serial port. At least you can trigger reboots and see what happens when grub loads.
Unfortunately, the ISP is sort of an independent outfit, and while they are not small in any sense of the word, their equipment room is stacked full of servers from floor to ceiling. I'm not aware of any power related switches where one could ssh into a "box" and cycle the power for one server. I know I really should take this dual Xeon server here in my cave and move it downtown, but I miss having the horsepower when I need it, as I still dabble with numerical weather models, and it takes a lot of number crunching cpu cycles to accomplish that task. It's also possible that the ACPI of the bios is partly to blame, but when I put the machine down there, I actually had maybe 2 hours, or the time it took to install CentOS on the drive and get the FS set up for the task. Only later did I learn there was a problem remote rebooting.
I appreciate everyone's responses, and I suppose I'll just have to deal with the problems as they occur. I've switched back to digest mode, as of this morning, so if you don't get any response from me till the day after, that is the reason.
Many thanks
Sam
On Mon, 2008-07-21 at 08:45 -0400, Sam Drinkard wrote:
<snip>
the machine down there, I actually had maybe 2 hours, or the time it took to install CentOS on the drive and get the FS set up for the task. Only later did I learn there was a problem remote rebooting.
Ahhh. That prompts a possible solution. I would guess that you didn't have time to see if it had a BIOS upgrade available. From watching this list of a long period, I note that many ACPI issues are resolved when a BIOS upgrade is applied. I guess that manufacturers rush the stuff out the door and then later some issues are found and fixes made available.
If you've not checked to see if there is a BIOS upgrade available, it may be worthwhile. Even if it doesn't solve the occasional operational issues, it may solve the reboot issues.
<snip>
HTH
On Mon, Jul 21, 2008 at 7:45 AM, Sam Drinkard sam@wa4phy.net wrote:
Unfortunately, the ISP is sort of an independent outfit, and while they are not small in any sense of the word, their equipment room is stacked full of servers from floor to ceiling. I'm not aware of any power related switches where one could ssh into a "box" and cycle the power for one server.
Can you ssh into your server and give it a reboot or shutdown -r command? If you can do that, you will not have such a problem with the Remote Reboot switch frequently not doing the job you need it to do for you. However, I think the Remote Reboot is something *very* nice to have, if you and your ISP can get it to work properly, because you and your server are not in the same place. You should not need to cycle power to reboot the box and you said something about them unplugging your box and then plugging it back in, which seems drastic. From that, I assume it does not have a reset swtich (our newer desktops lack that very nice feature) or even a Power Switch.
It's also possible that the ACPI of the bios is partly to blame, but when I put the machine down there, I actually had maybe 2 hours, or the time it took to install CentOS on the drive and get the FS set up for the task. Only later did I learn there was a problem remote rebooting.
After the update to CentOS 5.2 I had a very minor issue, where that kernel wouldn't boot, after shutting my desktop down and then powering it up. I added acpi=off to the line for that kernel and the problem disappeared.
I appreciate everyone's responses, and I suppose I'll just have to deal with the problems as they occur. I've switched back to digest mode, as of this morning, so if you don't get any response from me till the day after, that is the reason.
I used to get the Digest mode, but then I was advised I was breaking the threading (probably if one has their MUA configured correctly that won't happen), so now I get the individual messages and I read them online.
-
Lanny Marcus -
MJT -
Sam Drinkard -
Scott Silva -
William L. Maltby