Why don't you download the DVD, it give you much more than disc 1.
Parshwa Murdia 01/19/11 1:41 PM >>>
Hi,
I have downloaded the following version:
CentOS-5.5-i386-LiveCD-Release2.iso
from the mirror:
http://ftp.iitm.ac.in/centos/5.5/isos/i386/
What I want to ask is that 'Release2' is the complete OS and after installation we can use 'yum update'. So at first, is it enough (as I am not going to download the complete set of 7 CDs)?
On 01/19/11 11:53 AM, Lisandro Grullon wrote:
Why don't you download the DVD, it give you much more than disc 1.
Parshwa Murdia b330bkn@gmail.com 01/19/11 1:41 PM >>>
Hi,
I have downloaded the following version:
CentOS-5.5-i386-LiveCD-Release2.iso
from the mirror:
http://ftp.iitm.ac.in/centos/5.5/isos/i386/
What I want to ask is that 'Release2' is the complete OS and after installation we can use 'yum update'. So at first, is it enough (as I am not going to download the complete set of 7 CDs)?
the LiveCD will not install the operating system. It is purely for demo or diagnostic purposes.
use the network installer iso if you want a single CD install. otherwise, you need most of the 7 CDs to install a typical selection of packages, or the DVD.
On Wed, Jan 19, 2011 at 9:09 PM, John R Pierce pierce@hogranch.com wrote:
the LiveCD will not install the operating system. It is purely for demo or diagnostic purposes.
But there comes an option "Install to Hard-disk" after we see the Live CD desktop!
On 1/19/2011 4:00 PM, Parshwa Murdia wrote:
On Wed, Jan 19, 2011 at 9:09 PM, John R Pierce pierce@hogranch.com wrote:
the LiveCD will not install the operating system. It is purely for demo or diagnostic purposes.
But there comes an option "Install to Hard-disk" after we see the Live CD desktop!
Then try it and see what happens! :)
The LiveCD is not the complete OS. If there is an install option on the LiveCD, it will be a network install.
At Wed, 19 Jan 2011 22:00:21 +0100 CentOS mailing list centos@centos.org wrote:
On Wed, Jan 19, 2011 at 9:09 PM, John R Pierce pierce@hogranch.com wrote:
the LiveCD will not install the operating system. It is purely for demo or diagnostic purposes.
But there comes an option "Install to Hard-disk" after we see the Live CD desktop!
I'm guessing this is much the same as the netinstall CD. Or else it will promptly ask you for installer CD #1 or the installer DVD.
On Wednesday, January 19, 2011 04:26:57 pm Robert Heller wrote:
At Wed, 19 Jan 2011 22:00:21 +0100 CentOS mailing list centos@centos.org wrote:
On Wed, Jan 19, 2011 at 9:09 PM, John R Pierce pierce@hogranch.com wrote:
the LiveCD will not install the operating system. It is purely for demo or diagnostic purposes.
But there comes an option "Install to Hard-disk" after we see the Live CD desktop!
I'm guessing this is much the same as the netinstall CD. Or else it will promptly ask you for installer CD #1 or the installer DVD.
Please see https://projects.centos.org/trac/livecd/wiki/InstallToHardDrive
Yes, it looks like it works; no, it's not officially supported, and reading the page implies you have to build it yourself. This looks to me like the Fedora LiveCD install method; basically, it copies the LiveCD to the HD and sets things up as if it were installed via kickstart and with the regular installer.
I do remember doing a couple of Fedora installs this way; they are fast, that's for sure.
There is also a 'Network install' option (see http://wiki.centos.org/Manuals/ReleaseNotes/CentOSLiveCD5.5 ) on the 5.5 LiveCD that works the same as the netinstall ISO. Perhaps that's the Install icon that's being seen here.
Lamar Owen wrote:
On Wednesday, January 19, 2011 04:26:57 pm Robert Heller wrote:
At Wed, 19 Jan 2011 22:00:21 +0100 CentOS mailing list centos@centos.org wrote:
On Wed, Jan 19, 2011 at 9:09 PM, John R Pierce pierce@hogranch.com
wrote:
the LiveCD will not install the operating system. It is purely for demo or diagnostic purposes.
But there comes an option "Install to Hard-disk" after we see the Live CD desktop!
<snip>
Yes, it looks like it works; no, it's not officially supported, and reading the page implies you have to build it yourself. This looks to me like the Fedora LiveCD install method; basically, it copies the LiveCD to the HD and sets things up as if it were installed via kickstart and with the regular installer.
I do remember doing a couple of Fedora installs this way; they are fast, that's for sure.
<snip> Yeah - I hate the Fedora way. Why not *ask* where you want to install the liveCD? Why force it into /boot, when until now, *everyone* has kept boot at about 100M or so?
mark, grumble, grumble
On Wednesday, January 19, 2011 05:09:25 pm m.roth@5-cent.us wrote:
Yeah - I hate the Fedora way. Why not *ask* where you want to install the liveCD? Why force it into /boot, when until now, *everyone* has kept boot at about 100M or so?
The last one I did from LiveCD was prior to the need for a larger than 100M /boot, and it didn't need to install there. Haven't tried one since then; I guess that was F11. F12 and F13 I did from DVD, and I did the preupgrade thing from F13 to F14 (with the recommended yum distro-sync). I don't currently have a /boot on this laptop, but it has other interesting and difficult oddities associated with it, that are beyond the scope of the CentOS list....
On Wed, Jan 19, 2011 at 05:44:45PM -0500, Lamar Owen wrote:
On Wednesday, January 19, 2011 05:09:25 pm m.roth@5-cent.us wrote:
Yeah - I hate the Fedora way. Why not *ask* where you want to install the liveCD? Why force it into /boot, when until now, *everyone* has kept boot at about 100M or so?
Boot has to be huge in Fedora for the preupgrade to have a chance of working--having given up on it several releases ago, I have no idea if it's been improved or not.
So, that's the theory behind the huge boot partition. Seems there must be a Sir Mixalot joke in there.
On Wednesday, January 19, 2011 06:38:12 pm Scott Robbins wrote:
Boot has to be huge in Fedora for the preupgrade to have a chance of working--having given up on it several releases ago, I have no idea if it's been improved or not.
This is obviously straying from the topicality of this list, but yes the mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
These are features we're likely to see at some point in EL, so it's useful to have a handle on the caveats that will arise from their use, that's for sure, and that's the only reason in continue the thread.....
Lamar Owen wrote:
On Wednesday, January 19, 2011 06:38:12 pm Scott Robbins wrote:
Boot has to be huge in Fedora for the preupgrade to have a chance of working--having given up on it several releases ago, I have no idea if it's been improved or not.
This is obviously straying from the topicality of this list, but yes the
Not really, since I assume that at least some of what's in Fedora will come down to us, sooner or later.
mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
<snip> Could you define "improved"? My wish list would include "I (fedora) will install the o/s in /boot, and then *ask* where you want the rest to go", so I can tell something like /upgrade in the root filesystem, where I've got a *TON* more space.
mark
On Thursday, January 20, 2011 11:52:48 am m.roth@5-cent.us wrote:
Lamar Owen wrote:
mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
<snip> Could you define "improved"? My wish list would include "I (fedora) will install the o/s in /boot, and then *ask* where you want the rest to go", so I can tell something like /upgrade in the root filesystem, where I've got a *TON* more space.
Well, since you asked, I'm talking again about a preupgrade; the /boot filesystem on that box is 100MB in size, and the preupgrade worked. It downloaded the install image during the boot of the anaconda upgrader, rather than downloading during the preupgrade run. I don't know which BZ entry it would be, but I'm sure you could look that up.
The preupgrade by definition is an in-place upgrade rather than an install. The LiveCD install cannot upgrade (since it's just really duplicating the on-cd filesystem, plus a few other operations) and there aren't any RPMs on the LiveCD to do an upgrade with.... Having the netinstall option should also give the upgrade option, but I don't recall if the Fedora LiveCD will do a netinstall like the CentOS LiveCD will.
But upgrades between EL versions aren't supported, so that's sort of moot. Can you imagine trying to upgrade an FC6 to an F12 in one step? That's essentially what a C5 to C6 upgrade will be like, and it's not going to be easy. And it may not even be directly possible to upgrade; there have been a lot of changes between, including RPM format, disk naming, among a few things. It might be possible to do C5 to F7, to F8, to F9, to F10, to F11, and then to C6. It might even be possible to skip some of those steps; don't know.
Lamar Owen wrote:
On Thursday, January 20, 2011 11:52:48 am m.roth@5-cent.us wrote:
Lamar Owen wrote:
mechanism has been improved at least between F13 and F14, as I did do
a
preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
<snip> Could you define "improved"? My wish list would include "I (fedora) will install the o/s in /boot, and then *ask* where you want the rest to go", so I can tell something like /upgrade in the root filesystem, where I've got a *TON* more space.
Well, since you asked, I'm talking again about a preupgrade; the /boot filesystem on that box is 100MB in size, and the preupgrade worked. It downloaded the install image during the boot of the anaconda upgrader, rather than downloading during the preupgrade run. I don't know which BZ entry it would be, but I'm sure you could look that up.
<snip> Far out! The last time I did a Fedora upgrade, between FC11? 12? and 14? it wanted over 260M *free* in /boot.
mark
On 1/20/2011 12:58 PM, Lamar Owen wrote:
mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
<snip> Could you define "improved"? My wish list would include "I (fedora) will install the o/s in /boot, and then *ask* where you want the rest to go", so I can tell something like /upgrade in the root filesystem, where I've got a *TON* more space.
Well, since you asked, I'm talking again about a preupgrade; the /boot filesystem on that box is 100MB in size, and the preupgrade worked. It downloaded the install image during the boot of the anaconda upgrader, rather than downloading during the preupgrade run. I don't know which BZ entry it would be, but I'm sure you could look that up.
The preupgrade by definition is an in-place upgrade rather than an install. The LiveCD install cannot upgrade (since it's just really duplicating the on-cd filesystem, plus a few other operations) and there aren't any RPMs on the LiveCD to do an upgrade with.... Having the netinstall option should also give the upgrade option, but I don't recall if the Fedora LiveCD will do a netinstall like the CentOS LiveCD will.
But upgrades between EL versions aren't supported, so that's sort of moot. Can you imagine trying to upgrade an FC6 to an F12 in one step? That's essentially what a C5 to C6 upgrade will be like, and it's not going to be easy. And it may not even be directly possible to upgrade; there have been a lot of changes between, including RPM format, disk naming, among a few things. It might be possible to do C5 to F7, to F8, to F9, to F10, to F11, and then to C6. It might even be possible to skip some of those steps; don't know.
In all this talk about the tradeoffs among different distros where frequent updates have been mentioned as a downside for some, no one has been very specific about which ones can be expected to do in-place major upgrades without breaking too much. I was pleasantly surprised when an old ubuntu 8.04LTS offered to upgrade itself to 10.04, and did it, but I didn't have anything complicated set up on it to know how well this is really handled.
On Thu, Jan 20, 2011 at 5:46 PM, Lamar Owen lowen@pari.edu wrote:
This is obviously straying from the topicality of this list, but yes the mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
You say for SL6, would it sometimes prove better than stable CentOS?
On 1/20/2011 10:53 AM, Parshwa Murdia wrote:
On Thu, Jan 20, 2011 at 5:46 PM, Lamar Owenlowen@pari.edu wrote:
This is obviously straying from the topicality of this list, but yes the mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
You say for SL6, would it sometimes prove better than stable CentOS?
That would depend on what you mean by 'better'. SL adds things not included in stock Red Hat - and thus strays farther from strict RH compatibility. Whether that's better or worse probably depends on how much you would use the things they add. Another difference is that they release alpha/beta versions. That's better if you need something to test today - maybe worse if you expect it to be perfect.
On Thursday, January 20, 2011 11:53:52 am Parshwa Murdia wrote:
You say for SL6, would it sometimes prove better than stable CentOS?
As Les said, it depends by what you consider to be 'better.' I consider them to be roughly equivalent, with SL having some advantages (mostly of perception in my dayjob, for instance) and CentOS having some advantages (long track record of stability and strict adherence to upstream in many ways). I don't consider either to be 'better' in the strict sense of that word; I would simply describe them as 'different' rather than try to qualify a 'better.'
See where I work as a dayjob, and then see why Scientific Linux, backed by Fermilab and others, would have a perception advantage..... :-) But the binaries are essentially the same, and both are excellent choices.
Yet we use CentOS on virtually all of our servers, with very few exceptions. Again, it's not a matter of which is 'better' in any way; when the whole RHEL 3 thing came about, and Red Hat stopped selling boxed sets of Red Hat Linux with RHL9, there were a number of rebuilds that came out. The first one out of the gate (IIRC) was Whitebox, but not by much. So my first EL was a Whitebox 3 install, which is now a CentOS 3 install, and is still running. My second EL was a CentOS 2.1 install, which, again, is still running (libc5 compatability stops here in the EL line; a large commercial libc5 binary-only package is still running on that box).
I have done a few SL installs for some researchers who have come here, but, honestly, most of the desktop Linux we use (which isn't much) is Fedora. The servers run CentOS (a mix of 3, 4, and 5) and, well, they just run like clockwork. And I've just stuck with CentOS for the reason of inertia, more than any other.
But I monitor both mailing lists; the two distributions aren't in competition, really, and it's good to have both out there. And I've done enough migrating back and forth among the various EL from source distributions to be able to go either way (it's not really hard, unless you use some of the extra packages) and pretty much any time. And they're both from the same upstream source packages.....
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Lamar Owen Sent: Thursday, January 20, 2011 2:12 PM To: CentOS mailing list Subject: Re: [CentOS] Is it okay?
On Thursday, January 20, 2011 11:53:52 am Parshwa Murdia wrote:
You say for SL6, would it sometimes prove better than stable CentOS?
the two distributions aren't in competition, really, and it's good to have both out there. They're both from the same upstream source packages.....
It is in my perspective like having a hot-swap backup of vital data.
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Thu, Jan 20, 2011 at 8:12 PM, Lamar Owen lowen@pari.edu wrote:
As Les said, it depends by what you consider to be 'better.' I consider them to be roughly equivalent, with SL having some advantages (mostly of perception in my dayjob, for instance) and CentOS having some advantages (long track record of stability and strict adherence to upstream in many ways). I don't consider either to be 'better' in the strict sense of that word; I would simply describe them as 'different' rather than try to qualify a 'better.'
Yet we use CentOS on virtually all of our servers, with very few exceptions. Again, it's not a matter of which is 'better' in any way; when the whole RHEL 3 thing came about, and Red Hat stopped selling boxed sets of Red Hat Linux with RHL9, there were a number of rebuilds that came out. The first one out of the gate (IIRC) was Whitebox, but not by much. So my first EL was a Whitebox 3 install, which is now a CentOS 3 install, and is still running. My second EL was a CentOS 2.1 install, which, again, is still running (libc5 compatability stops here in the EL line; a large commercial libc5 binary-only package is still running on that box).
Yes correct, it is the user who sees which one is better or not? But it is true that both (SL and CentOS) are excellent. Both are Linux which is highly secured, especially for us who are new and switching to it from Windows, which I don't want to compare at all. What made me think for this comparison was the simple question why did Fermi Labs and CERN chose SL and developing but they didn't go for other distros, keeping in mind always that all the distros have their own pros and cons but essentially the same security.
On 1/21/11 12:09 AM, Parshwa Murdia wrote:
On Thu, Jan 20, 2011 at 8:12 PM, Lamar Owenlowen@pari.edu wrote:
As Les said, it depends by what you consider to be 'better.' I consider them to be roughly equivalent, with SL having some advantages (mostly of perception in my dayjob, for instance) and CentOS having some advantages (long track record of stability and strict adherence to upstream in many ways). I don't consider either to be 'better' in the strict sense of that word; I would simply describe them as 'different' rather than try to qualify a 'better.'
Yet we use CentOS on virtually all of our servers, with very few exceptions. Again, it's not a matter of which is 'better' in any way; when the whole RHEL 3 thing came about, and Red Hat stopped selling boxed sets of Red Hat Linux with RHL9, there were a number of rebuilds that came out. The first one out of the gate (IIRC) was Whitebox, but not by much. So my first EL was a Whitebox 3 install, which is now a CentOS 3 install, and is still running. My second EL was a CentOS 2.1 install, which, again, is still running (libc5 compatability stops here in the EL line; a large commercial libc5 binary-only package is still running on that box).
Yes correct, it is the user who sees which one is better or not? But it is true that both (SL and CentOS) are excellent. Both are Linux which is highly secured, especially for us who are new and switching to it from Windows, which I don't want to compare at all. What made me think for this comparison was the simple question why did Fermi Labs and CERN chose SL and developing but they didn't go for other distros, keeping in mind always that all the distros have their own pros and cons but essentially the same security.
I think SL was designed for Fermi/CERN's needs rather than being chosen. But they (like most of us...) where probably using RH back in the days when it was free, before the RHEL/Fedora split and Fedora is obviously not suitable for work where you need stability. And the only other reasonable distro choice at the time was debian which was a purely volunteer effort with a good code base but a very strict policy about 'free-ness' and poor track record of getting releases out on any kind of schedule. Subsequently, ubuntu has greatly improved the usability of the debian base and puts real effort into the release schedule. But, SL and Centos inherit the install/admin programs and style from RH, and debian/ubuntu are considerably different so once you have learned and perhaps automated one it is hard to change even though there is little difference from a users perspective.
In retrospect I think the world would be a better place if everyone using RH would have walked away the day they stopped permitting redistribution of binaries to the community that had contributed their code base. But I was too lazy to do that myself and CentOS lets me stay that way (and at the time, no one knew how crazy fedora would become...).
Les Mikesell wrote: <MVNCH>
In retrospect I think the world would be a better place if everyone using RH would have walked away the day they stopped permitting redistribution of binaries to the community that had contributed their code base. But I was too lazy to do that myself and CentOS lets me stay that way (and at the
time,
no one knew how crazy fedora would become...).
Yeah. I played with slackware in the mid-nineties, then went to RH with 4.2. Stayed there until I was ready to leave 9, and I went to SuSE. About a year and a quarter ago, came to CentOS. Much happier. fedora "become" crazy, Mike? The beginning of '06, when I went to SuSE, I already knew that it was bleeding edge, and that wasn't just my opinion, but the opinion of a number of folks I know, whose technical expertise I respect, including some guy who's initials are ESR (his politica are another matter, but that's OT).
*shakes head* I hate fedora (says the guy who just upgraded someone's workstation, and then spent the better part of an hour getting X working....)
mark
On 1/21/2011 8:55 AM, m.roth@5-cent.us wrote:
fedora "become" crazy, Mike? The beginning of '06, when I went to SuSE, I already knew that it was bleeding edge, and that wasn't just my opinion, but the opinion of a number of folks I know, whose technical expertise I respect, including some guy who's initials are ESR (his politica are another matter, but that's OT).
Bleeding edge or not wasn't quite the point - the problem was that there was never an attempt to converge the changes to stability, just a sequence of wildly different changes in every release. In the history leading up to that, the pre-RHEL versions of RH would have an X.0 release that everyone know would be buggy, and subsequent X.1, X.2 versions that were increasingly stable. And you could sort of relate the X.2 versions to Microsoft releasing 'service pack 2' for a product in that you really didn't want to use anything before that for anything but testing. The first few RHEL releases sort of looked like the same pattern where there would be 2 fedora versions replacing the X.0, X.1 RH's with the 3rd in the set being RHEL, but it didn't stay that way very long and quickly got to the point where is wasn't worth even testing on fedora because things would just be completely different in the next release and there was no effort to maintain hardware compatibility or user data across the upgrades - or sometimes even for minor updates. I had a fairly mainstream IBM box refuse to boot an update kernel mid-fedora 5 or so.
And before someone else points it out, I know RH8 and RH9 didn't use the .0 minor number (perhaps to avoid the buggy connotation) but they were really more fedora-like and broke more things than users had come to expect in the the RH tradition.
On Friday, January 21, 2011 11:01:01 am Les Mikesell wrote:
The first few RHEL releases sort of looked like the same pattern where there would be 2 fedora versions replacing the X.0, X.1 RH's with the 3rd in the set being RHEL, but it didn't stay that way very long and quickly got to the point where is wasn't worth even testing on fedora because things would just be completely different in the next release and there was no effort to maintain hardware compatibility or user data across the upgrades - or sometimes even for minor updates.
My experience has been considerably different, and I have found Fedora, especially recently, has been more stable than the non-LTS Ubuntu, at least for KDE usage. Once you got past the first release with KDE4, but that happened during my two-year excursion into disappointing KUbuntu-land. I'm told that going from the last KDE3 to the first KDE4 wasn't pleasant; but that was/is just as true with Ubuntu, excepting for the fact that Ubuntu waited just a little longer to go there.
I have also seen CentOS (and by extension the upstream) kernels break things, reorder ethernet ports, etc.
And before someone else points it out, I know RH8 and RH9 didn't use the .0 minor number (perhaps to avoid the buggy connotation) but they were really more fedora-like and broke more things than users had come to expect in the the RH tradition.
Technically this isn't true. I'm looking at my shelf of boxed sets, and the first one without a .0 was 7. I don't still have my box for RH8, but I do actually have a machine running with RH8.... # cat /etc/redhat-release Red Hat Linux release 8.0 (Psyche)
I distinctly remember the .0 being there on the box. Some thought, at the time, that RHL7.3 should have been labeled 8.0; RHAS2.1 IIRC is/was based off RHL7.2.
But RH 9 was just that; no .0 there. RH only kept up the .0 .1 .2 consistently through 4.x, 5.x, and 6.x; 7 and later were a different beast, and 3.03 and prior were as well. There were more major versions that didn't do that than did. :-)
Ubuntu folk have just as many problems; I do support for a couple who use Linux exclusively, and they have a mix of boxes, including an F13, a Ubuntu 8.04, and Ubuntu 9.04, and a Ubuntu 6.06. The upgrade from 6.06 on up is not going to be pleasant.
The Ubuntu 9.04 was upgraded to 9.10, and many things broke. I mean, just flat out broke. Sound stopped. Video output stopped. Wireless stopped. On a Dell notebook with Linux support, that shipped with Ubuntu installed.
In contrast, I returned to Fedora at F11, and haven't had major issues with moving from 11 to 12 to 13 to 14. In fact, the 13 to 14 experience was rather smooth, particularly for bleeding edge.
But that's what Fedora is; bleeding edge, and if that's what you need, that's what you need.
Your mileage (and breakage) may vary.
Lamar Owen wrote:
On Friday, January 21, 2011 11:01:01 am Les Mikesell wrote:
The first few RHEL releases sort of looked like the same pattern where there would be 2 fedora versions replacing the X.0, X.1 RH's with the 3rd in the set being RHEL, but it didn't stay that way very long and quickly got to the point where is wasn't worth even testing on fedora because things would just be completely different in the next release and there was no effort to maintain hardware compatibility or user data across the upgrades - or sometimes even for minor updates.
<snip>
I have also seen CentOS (and by extension the upstream) kernels break things, reorder ethernet ports, etc.
Haven't seen the kernel break things, with the exception of *sigh* NVidia drivers.... I've also seen it reorder ethernet ports, but finally found the simple solution (/etc/sysconfig/network-scripts/ifcfg-ethx, and add the HWADDR)
And before someone else points it out, I know RH8 and RH9 didn't use the .0 minor number (perhaps to avoid the buggy connotation) but they were really more fedora-like and broke more things than users had come to expect in the the RH tradition.
Technically this isn't true. I'm looking at my shelf of boxed sets, and the first one without a .0 was 7. I don't still have my box for RH8, but I do actually have a machine running with RH8....
Lazy! If I fired up my currently-not-running firewall/router at home, it's got RH9. <snip>
In contrast, I returned to Fedora at F11, and haven't had major issues with moving from 11 to 12 to 13 to 14. In fact, the 13 to 14 experience was rather smooth, particularly for bleeding edge.
But that's what Fedora is; bleeding edge, and if that's what you need, that's what you need.
Lessee, FC10->FC13, screw with /boot, finally get it, and X DOES NOT WORK, then I got it working, but gnome is completely broken, and you can't log in, then find that gnome is hostile to window manager switching, and I had to remove all of gnome to get KDE to run (and not have gnome try to run), then for weeks, I had random panics....
Your mileage (and breakage) may vary.
It did, indeed.
mark "that was FC14 that broke X yesterday"
On Friday, January 21, 2011 12:34:57 pm m.roth@5-cent.us wrote:
Haven't seen the kernel break things, with the exception of *sigh* NVidia drivers.... I've also seen it reorder ethernet ports, but finally found the simple solution (/etc/sysconfig/network-scripts/ifcfg-ethx, and add the HWADDR)
You use the RPMfusion kmod's, and use the yum plugin to protect them, right?
Lazy! If I fired up my currently-not-running firewall/router at home, it's got RH9.
I'll let the following speak for itself. Read it carefully. It's from a running machine. # cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) # uname -a Linux localhost.localdomain 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 i586 unknown # date Fri Jan 21 13:15:04 EST 2011 #
What's that about 'if it ain't broke, don't fix it' at least with boxes that don't have a direct Internet connection......and this box is doing its job, and doing it well, and with the features that meet the need. Yes, it's had a hard drive replacement, a motherboard/CPU replacement, among other things.... but even back in those days cloning drives was somewhat common.....
[snip]
mark "that was FC14 that broke X yesterday"
Filed a bug report, right? :-)
On 01/21/11 10:22 AM, Lamar Owen wrote:
I'll let the following speak for itself. Read it carefully. It's from a running machine. # cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) # uname -a Linux localhost.localdomain 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 i586 unknown # date Fri Jan 21 13:15:04 EST 2011 #
$ cat /etc/redhat-release && uname -a && uptime Red Hat Linux release 6.2 (Zoot) Linux hogranch.com 2.2.24-6.2.3 #1 Fri Mar 14 08:41:15 EST 2003 i686 unknown 10:24am up 33 days, 6:53, 4 users, load average: 0.10, 0.04, 0.01
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
Yer not the only one. this thing is my firewall/gateway/router, also DNS and DHCP, and is quite reasonably hardened. yes, ipchains is starting to get stinky, but it works. it started life as RHL 6.0, but got upgraded, and now has an bastard mix of stuff on it. It started life as a pentium-1 100Mhz, but that got upgraded to this 450Mhz when it was still a email server and the 100 couldn't keep up with the spam filtering. I've got a P3 800 here running RHEL5 that I keep meaning to configure and swap in, but it ain't broke, so I've procrastinated.
On Fri, Jan 21, 2011 at 10:29:14AM -0800, John R Pierce wrote:
Red Hat Linux release 6.2 (Zoot)
Yer not the only one. this thing is my firewall/gateway/router, also
I replaced my old redhat 6 firewall (Pentium Pro) with a wrt54g around 7 years ago when I realised just how much energy that machine was wasting spinning up hard disks and stuff.
I dug it out of the cupboard a couple of years ago and refreshed the OS (put Damn Small Linux on it) and freecycled it. People still wanted a machine that old!
filtering. I've got a P3 800 here running RHEL5 that I keep meaning to configure and swap in, but it ain't broke, so I've procrastinated.
These days for small stuff I actually run a user-mode-linux installation on my main server, with a very very cut down centOS install. Works nicely and I build a new "machine" within minutes. Last year I used it to build 2 postgres servers and tested out a DR solution :-) I'm trying to cut on on physical machines to save money and space.
On 01/21/11 10:35 AM, Stephen Harris wrote:
I replaced my old redhat 6 firewall (Pentium Pro) with a wrt54g around 7 years ago when I realised just how much energy that machine was wasting spinning up hard disks and stuff.
wrt54's (I have a wrt54gs v1.0 doing my wireless) are awfully slow little processors. I have considered and still may get around to setting up a little atom or something running pfSense, with no hard disk, and moving my services to a modest powered NAS/server box, which would double as the media server on my LAN (4 x 2TB or something) The P3-450 running my network now draws about 70 watts average per my Kill-A-Watt, which really isn't that bad.
On Friday, January 21, 2011 02:13:54 pm John R Pierce wrote:
The P3-450 running my network now draws about 70 watts average per my Kill-A-Watt, which really isn't that bad.
Kaill-a-watts are great little devices....
If you can find a cast-off Nomadix HotSpot gateway, you can save a lot of power and get something more speedy at the same time. It's a custom-labelled Portwell NAD-2050; if you can find one they're neat. Lot less than 70 watts; closer to 10 or 20. Three or five 10/100 ethernet ports, and other options, in a box that's 1 RU high, but smaller than rack width.
On Jan 21, 2011, at 2:37 PM, Lamar Owen wrote:
If you can find a cast-off Nomadix HotSpot gateway, you can save a lot of power and get something more speedy at the same time. It's a custom-labelled Portwell NAD-2050; if you can find one they're neat. Lot less than 70 watts; closer to 10 or 20.
Just checked it with one of my Kill-a-watts: 17 watts. Cool.
On Fri, Jan 21, 2011 at 11:13:54AM -0800, John R Pierce wrote:
On 01/21/11 10:35 AM, Stephen Harris wrote:
I replaced my old redhat 6 firewall (Pentium Pro) with a wrt54g around 7 years ago when I realised just how much energy that machine was wasting spinning up hard disks and stuff.
wrt54's (I have a wrt54gs v1.0 doing my wireless) are awfully slow little processors. I have considered and still may get around to
It can handle my 30Mbit/s FIOS connection just fine, which is more than I think my old Pentium Pro could do :-)
On 01/21/11 12:11 PM, Stephen Harris wrote:
On Fri, Jan 21, 2011 at 11:13:54AM -0800, John R Pierce wrote:
On 01/21/11 10:35 AM, Stephen Harris wrote:
I replaced my old redhat 6 firewall (Pentium Pro) with a wrt54g around 7 years ago when I realised just how much energy that machine was wasting spinning up hard disks and stuff.
wrt54's (I have a wrt54gs v1.0 doing my wireless) are awfully slow little processors. I have considered and still may get around to
It can handle my 30Mbit/s FIOS connection just fine, which is more than I think my old Pentium Pro could do :-)
huh, I'm surprised. I've had trouble routing 10Mbit through them at wire speeds.
The wrt54g(s) internally has a single 100baseT ethernet port attached to a 6 port VLAN switch. WAN vs LAN are done with vlan switching, so effectively its a half duplex device. The CPU is also brutally slow, a 200MHz MIPSel system-on-a-chip with no cache, and very narrow memory bus with rather slow memory cycles.
On Fri, Jan 21, 2011 at 01:57:32PM -0800, John R Pierce wrote:
On 01/21/11 12:11 PM, Stephen Harris wrote:
On Fri, Jan 21, 2011 at 11:13:54AM -0800, John R Pierce wrote:
On 01/21/11 10:35 AM, Stephen Harris wrote:
I replaced my old redhat 6 firewall (Pentium Pro) with a wrt54g around 7 years ago when I realised just how much energy that machine was wasting spinning up hard disks and stuff.
wrt54's (I have a wrt54gs v1.0 doing my wireless) are awfully slow little processors. I have considered and still may get around to
It can handle my 30Mbit/s FIOS connection just fine, which is more than I think my old Pentium Pro could do :-)
huh, I'm surprised. I've had trouble routing 10Mbit through them at wire speeds.
With a WRT54G v2 running Tomato 1.21, connection made from a Centos 5.5 machine on the LAN (via a Gbit switch); connection to the FIOS ActionTec router (in bridge mode) on the WAN.
% wget -O/dev/null http://cachefly.cachefly.net/100mb.test --2011-01-21 21:03:32-- http://cachefly.cachefly.net/100mb.test Resolving cachefly.cachefly.net... 205.234.175.175 Connecting to cachefly.cachefly.net|205.234.175.175|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: `/dev/null'
100%[======================================>] 104,857,600 3.64M/s in 28s
2011-01-21 21:03:59 (3.63 MB/s) - `/dev/null' saved [104857600/104857600]
So downloading 100Mbytes of data at 3.63MB/s == 29.04Mbit/s
The wrt54g(s) internally has a single 100baseT ethernet port attached to a 6 port VLAN switch. WAN vs LAN are done with vlan switching, so
At least on versions 1-4 and the GL series it has a 5 port 100baseT switch which can do native VLAN. The VLANs are presented to the OS as sub-devices of eth0. Ports 0-3 are LAN, port 4 is WAN with the standard VLAN setup; third part firmware can do more.
effectively its a half duplex device. The CPU is also brutally slow, a
No, it's not half-duplex. The VLAN switching is done in the switch hardware. The OS only needs to see traffic between LAN and WAN, which is what a router does. The main CPU never touches inter-LAN traffic. Being a switch it can receive and transmit at the same time; 100FDX on each port.
From an OS perspective it sees two ethernet devices and it routes as
necessary. Definitely the routing is done via the primary CPU, but that's what makes it a cheap router :-)
As can be seen, it's very easy for the device to handle 29Mbit/s. Since I'm only paying for 25Mbit/s this makes me happy :-)
3.64 is the constant speed wget reports over multiple tests over multiple months; I dunno if this is the max my FIOS line will do or the max that the router will do (or even the fastest the ActionTec will do). It's consistent over multiple tests. I have a spare WRT54G v4 which is essentially the same spec; I might configure it and see how quickly it can do 100Mbit WAN transfers.
(Interesting thought; could I get faster with a better router? Hmm!)
But definitely this router can do 10Mbit/s without sweating. If you had trouble doing 10Mbit/s then you had other problems.
On 01/21/11 6:26 PM, Stephen Harris wrote:
But definitely this router can do 10Mbit/s without sweating. If you had trouble doing 10Mbit/s then you had other problems.
I was trying to route between two 100Mbit ethernets and seeing ~10Mbit, maybe a little more, when there was traffic going both ways. Also doing torrent type bidirectional peer to peer traffic, it swamps really easily due to the limited CPU horsepower. currently my wrt is acting as a 100baseT switch and a wireless access point, using the latest Tomato firmware.
On Friday, January 21, 2011 01:29:14 pm John R Pierce wrote:
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
Being that it's Friday.... (note that this output isn't snipped; kernel 2.0.36 doesn't grab the CPU frequency apparently!): [root@localhost /root]# cat /proc/cpuinfo processor : 0 cpu : 586 model : AMD-K6(tm) 3D processor vendor_id : AuthenticAMD stepping : M fdiv_bug : no hlt_bug : no f00f_bug : no fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu vme de pse tsc msr mce cx8 syscr pge mmx 3dnow bogomips : 999.42 [root@localhost /root]#
I happen to know it's a K6-2 500.
I have a few K6-2 300 systems here that would be ideal for a few uses if I could get something a little more modern than the i586 C4 build running on them... for that matter, perhaps I need the i586 C4 build on them.... They are Agilent ATMProbes that had a custom dual OC12 card complex, with the K6-2 board, which is not PC form-factor compliant, acting as a controller for the specialized atm cell capture/analysis complex.
For that matter, I'm looking for a distribution I can put on DiskOnChip and run on some embedded PC104 5x86/133 systems I have..... :-)
On 1/21/2011 1:28 PM, Lamar Owen wrote:
I have a few K6-2 300 systems here that would be ideal for a few uses if I could get something a little more modern than the i586 C4 build running on them... for that matter, perhaps I need the i586 C4 build on them.... They are Agilent ATMProbes that had a custom dual OC12 card complex, with the K6-2 board, which is not PC form-factor compliant, acting as a controller for the specialized atm cell capture/analysis complex.
For that matter, I'm looking for a distribution I can put on DiskOnChip and run on some embedded PC104 5x86/133 systems I have..... :-)
Except for things with specialized hardware adapters it just seems wasteful to power up any old stuff compared to running a virtual machine on something current and maybe giving it USB access to its own device.
On Friday, January 21, 2011 02:35:40 pm Les Mikesell wrote:
On 1/21/2011 1:28 PM, Lamar Owen wrote:
For that matter, I'm looking for a distribution I can put on DiskOnChip and run on some embedded PC104 5x86/133 systems I have..... :-)
Except for things with specialized hardware adapters it just seems wasteful to power up any old stuff compared to running a virtual machine on something current and maybe giving it USB access to its own device.
Well, in this particular case it's for remote locations that are solar powered. That and the embedded boxen draw 15 watts max and have the RS-485 interfaces I need to work with......oh, and they were free.
Ordinarily I would agree; provision a VM, and throw an AnyWhere USB out there and run the USB ports only in the remote, but ethernet-over-fiber connected, location. But I don't need USB; I need RS-232 and RS-485. The little PC-104/ISA boards (Advantech PCA-6144's and PCA 6145's) have ethernet; the 1RU and 2RU cases have RS-485 multiport muxes in them.
Lamar Owen wrote:
On Friday, January 21, 2011 01:29:14 pm John R Pierce wrote:
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
Being that it's Friday.... (note that this output isn't snipped; kernel 2.0.36 doesn't grab the CPU frequency apparently!): [root@localhost /root]# cat /proc/cpuinfo processor : 0 cpu : 586 model : AMD-K6(tm) 3D processor
Yup. I replaced my very nice, thank you very much, K6-2 250 (or was it 300) processor when I rebuilt my system in '05 or '06. But then, I still miss my rock-solid CompuAdd 286 that I replaced in the early nineties.... <snip>
I happen to know it's a K6-2 500.
mark
On Fri, Jan 21, 2011 at 02:38:28PM -0500, m.roth@5-cent.us wrote:
Lamar Owen wrote:
On Friday, January 21, 2011 01:29:14 pm John R Pierce wrote:
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
Being that it's Friday.... (note that this output isn't snipped; kernel 2.0.36 doesn't grab the CPU frequency apparently!): [root@localhost /root]# cat /proc/cpuinfo processor : 0 cpu : 586 model : AMD-K6(tm) 3D processor
Yup. I replaced my very nice, thank you very much, K6-2 250 (or was it 300) processor when I rebuilt my system in '05 or '06. But then, I still miss my rock-solid CompuAdd 286 that I replaced in the early nineties....
<snip> > I happen to know it's a K6-2 500.
Got one o'them, or maybe it's a K6-2/400 that I had overclocked. can't remember. anyway, I ran a Smoothwall firewall box on it for a couple years (after upgrading from a Pentium-90 which served for several years). ran great! then in interests of saving money on my outrageous power bill, I switched it out for a linksys WRT54GL which probably draws about 1/10 or maybe 1/20 of the power.
I would suggest "Damn Small Linux". It seems taylor made for stuff like this.
On Friday, January 21, 2011 11:28:26 am Lamar Owen wrote:
On Friday, January 21, 2011 01:29:14 pm John R Pierce wrote:
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
Being that it's Friday.... (note that this output isn't snipped; kernel 2.0.36 doesn't grab the CPU frequency apparently!): [root@localhost /root]# cat /proc/cpuinfo processor : 0 cpu : 586 model : AMD-K6(tm) 3D processor vendor_id : AuthenticAMD stepping : M fdiv_bug : no hlt_bug : no f00f_bug : no fpu : yes fpu_exception : yes cpuid : yes wp : yes flags : fpu vme de pse tsc msr mce cx8 syscr pge mmx 3dnow bogomips : 999.42 [root@localhost /root]#
I happen to know it's a K6-2 500.
I have a few K6-2 300 systems here that would be ideal for a few uses if I could get something a little more modern than the i586 C4 build running on them... for that matter, perhaps I need the i586 C4 build on them.... They are Agilent ATMProbes that had a custom dual OC12 card complex, with the K6-2 board, which is not PC form-factor compliant, acting as a controller for the specialized atm cell capture/analysis complex.
For that matter, I'm looking for a distribution I can put on DiskOnChip and run on some embedded PC104 5x86/133 systems I have..... :-) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hello Benjamin,
On Fri, 2011-01-21 at 14:35 -0800, Benjamin Smith wrote:
I would suggest "Damn Small Linux". It seems taylor made for stuff like this.
The problem with many of these special purpose distros is that they are usually poorly maintained wrt updates. A minimal install of a mainstream distro like CentOS shouldn't take up much more than a GB, and if you put in some effort to strip out excess packages even half of that. DSL is really more of a distro to put on embedded hardware.
Regards, Leonard.
On Friday, January 21, 2011 10:36:00 pm Leonard den Ottolander wrote:
The problem with many of these special purpose distros is that they are usually poorly maintained wrt updates. A minimal install of a mainstream distro like CentOS shouldn't take up much more than a GB, and if you put in some effort to strip out excess packages even half of that. DSL is really more of a distro to put on embedded hardware.
With CentOS 4 i586 available, I like that route best.
This keeps even the embedded stuff (that's at least i586) using the same admin interfaces, the same file locations, and in general it keeps things consistent. Consistency in user and admin interfaces is a good thing and helps admin productivity, at least in my case. That's partly the reason I run Fedora on my laptop; I run CentOS on my servers, and having my own machine running something fairly close helps me get things done quicker, and I'm less likely to mistype things.
So I'm not likely to use DSL or Puppy or similar on systems that are big enough to run CentOS 4 i586 at the least.
Now on really small storage (DiskOnChip for instance) things are completely different, and specialized distributions are useful. But if I have enough storage I'll run C4 (C4 is powering the majority of the servers here at the moment; we're transitioning somewhat slowly to C5 and soon to C6 for those cases that need it). No rush on most of the C4 boxen, though. As mentioned, I still have C3 and C2.1 in production, although that's slowly changing, and I try to be careful.
Now, when C4 is no longer supported, the choice of i586 distribution might change. See, i586 distributions are required for some fairly modern hardware, too, like much of the VIA embedded lines, which don't have CMOV.
On Fri, 21 Jan 2011 14:28:26 -0500 Lamar Owen lowen@pari.edu wrote:
On Friday, January 21, 2011 01:29:14 pm John R Pierce wrote:
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
I have a few K6-2 300 systems here that would be ideal for a few uses if I could get something a little more modern than the i586 C4 build running on them... for that matter, perhaps I need the i586 C4 build on them.... They are Agilent ATMProbes that had a custom dual OC12 card complex, with the K6-2 board, which is not PC form-factor compliant, acting as a controller for the specialized atm cell capture/analysis complex.
I have an old amd k6 (600 I think?) which currently just barely runs Mint 9 LXDE. I made the mistake of letting it update grub and a kernel and one or the other of those updates made it decide to reboot as soon as it should have brought up the grub menu, so I had to re-install it. Now the only thing I'll let through for an update is if it's cups or related to cups.
It previously had Vector Linux on it for a very short time, but since that uses lilo and is based on slackware, I decided to use Mint 9 lxde instead since it booted it o.k. I had enough issues getting a handle on grub. Before that it had Win98 on it.
I rarely turn it on, I thought I'd give it a spin as a print server for my very old Panasonic dot matrix printer, since it has a parallel port. But it is really slow. I have a PIII 500mhz laptop running Fedora 12 (gnome-openbox) that's faster. fwiw.
On Fri, 2011-01-21 at 10:29 -0800, John R Pierce wrote:
$ cat /proc/cpuinfo ... model name : Pentium III (Katmai) cpu MHz : 451.031 ...
Yer not the only one. this thing is my firewall/gateway/router, also DNS and DHCP, and is quite reasonably hardened. yes, ipchains is starting to get stinky, but it works. it started life as RHL 6.0, but got upgraded, and now has an bastard mix of stuff on it.
$ cat /proc/cpuinfo model name : Pentium II (Deschutes) cpu MHz : 334.113
$ cat /etc/redhat-release CentOS release 5.5 (Final)
Using this as a firewall too. Started out as a RHL 6.2 box with ipchains, upgraded it to CentOS 4 when the hd gave up - upgraded the firewall script for iptables -, then to CentOS 5 when yet another hd died. This box has been running for over 10 years, I estimate for 8 hours a day on average, survived a flash fire in the power supply after it gathered a bit too much dust but no other issues :)
Had to increase the amount of RAM when installing CentOS 4, but it's mostly unused:
$ free total used free shared buffers cached Mem: 255468 157688 97780 0 39360 70304 -/+ buffers/cache: 48024 207444 Swap: 987956 0 987956
Regards, Leonard.
Lamar Owen wrote:
On Friday, January 21, 2011 12:34:57 pm m.roth@5-cent.us wrote:
Haven't seen the kernel break things, with the exception of *sigh* NVidia drivers.... I've also seen it reorder ethernet ports, but
finally found
the simple solution (/etc/sysconfig/network-scripts/ifcfg-ethx, and add the HWADDR)
You use the RPMfusion kmod's, and use the yum plugin to protect them, right?
For nVIdia? I've been manually building the driver using the proprietary kit. One of these days, I'll try the... who is it, rpmforge? that has the packages? If that works, I'll have a literal handful of machines that I'll do that for.
Lazy! If I fired up my currently-not-running firewall/router at home, it's got RH9.
I'll let the following speak for itself. Read it carefully. It's from a running machine. # cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) # uname -a Linux localhost.localdomain 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 i586
Argh! You're one of *those*.... <snip>
What's that about 'if it ain't broke, don't fix it' at least with boxes that don't have a direct Internet connection......and this box is doing its job, and doing it well, and with the features that meet the need.
Right, and it's not online. Big changes, if it ever does go online. Hey, I was just using my box a year and a half ago. But I built it for its purpose: no compilers, no X, no diddly-squat, *and* I'd run Bastille Linux on it. To the best of my knowledge, over 10 years, I'd never had an intrusion.
[snip]
mark "that was FC14 that broke X yesterday"Filed a bug report, right? :-)
*If* I could pin down the exact cause, and I can't play around with the machine, since the user needed it *now*....
mark
On Friday, January 21, 2011 01:33:03 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
On Friday, January 21, 2011 12:34:57 pm m.roth@5-cent.us wrote:
Haven't seen the kernel break things, with the exception of *sigh* NVidia drivers.... I've also seen it reorder ethernet ports, but
finally found
the simple solution (/etc/sysconfig/network-scripts/ifcfg-ethx, and add the HWADDR)
You use the RPMfusion kmod's, and use the yum plugin to protect them, right?
For nVIdia? I've been manually building the driver using the proprietary kit. One of these days, I'll try the... who is it, rpmforge? that has the packages? If that works, I'll have a literal handful of machines that I'll do that for.
Sorry, not RPMfusion, but ELrepo. See elrepo.org
Install yum-kmod (I have also install yum-kernel-module), then install whichever nvidia kmod you need from elrepo. That should prevent kernel updates until the matching nvidia kmod is available. The yum-kmod and yum-kernel-module plugins are part of regular CentOS, not third-party repos.
Linux localhost.localdomain 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 i586
Argh! You're one of *those*....
Yep. I have a couple of VAXstation 4000's here, and soon will have a smallish SGI multiprocessor box that I'm planning to load CentOS on..... I like old kit. If I still had my PDP-8 now that would be interesting..... :-)
Right, and it's not online. Big changes, if it ever does go online. Hey, I was just using my box a year and a half ago. But I built it for its purpose: no compilers, no X, no diddly-squat, *and* I'd run Bastille Linux on it. To the best of my knowledge, over 10 years, I'd never had an intrusion.
I have had intrusions; that box actually was originally RH 4.2, but got upgraded after an intrusion (which is when its direct internet went away....bind 4 vulnerability). I've learned from those intrusions; good experience. One was on a Ubuntu box, fully up-to-date at the time. Turns out the password I thought was pretty unique wasn't; and it was a 'strong' password by most tools' estimation, being it had mixed case, numbers, and a punctuation symbol in it; it got infected with a slow-brute-forcer ssh worm, and when I saw the strange ssh traffic I shut it down; got a note about it, too. Now I don't allow outbound port 22 to just anywhere (among a few other things; it's becoming to where I'm tempted to firewall outgoing as aggressively as I firewall incoming, but we still do too many academic 'things' that connect to unusual port numbers.....).
Filed a bug report, right? :-)
*If* I could pin down the exact cause, and I can't play around with the machine, since the user needed it *now*....
Just *now* and not *yesterday* ? :-) But I understand; the goal of filing a report is to file a useful report, and 'it broke' is not a useful report....
Lamar Owen wrote:
On Friday, January 21, 2011 01:33:03 pm m.roth@5-cent.us wrote:
Lamar Owen wrote:
On Friday, January 21, 2011 12:34:57 pm m.roth@5-cent.us wrote:
Haven't seen the kernel break things, with the exception of *sigh* NVidia drivers.... I've also seen it reorder ethernet ports, but finally found the simple solution
(/etc/sysconfig/network-scripts/ifcfg-ethx, and
add the HWADDR)
You use the RPMfusion kmod's, and use the yum plugin to protect them, right?
For nVIdia? I've been manually building the driver using the proprietary kit. One of these days, I'll try the... who is it, rpmforge? that has the packages? If that works, I'll have a literal handful of machines that I'll do that for.
Sorry, not RPMfusion, but ELrepo. See elrepo.org
Right. That's the one.
Install yum-kmod (I have also install yum-kernel-module), then install whichever nvidia kmod you need from elrepo. That should prevent kernel updates until the matching nvidia kmod is available. The yum-kmod and yum-kernel-module plugins are part of regular CentOS, not third-party repos.
Thanks for that - I really will get around to it, one of these days. It gets tedious, rebuilding.
Linux localhost.localdomain 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 i586
Argh! You're one of *those*....
Yep. I have a couple of VAXstation 4000's here, and soon will have a smallish SGI multiprocessor box that I'm planning to load CentOS on..... I like old kit. If I still had my PDP-8 now that would be interesting..... :-)
I have a friend with several RISC 6000's, and of course his MicroVAX. You had a PDP-8? When I was taking an o/s class in the mid-eighties, I was on a PDP-11/780. *Nice* machine, running RSTS, I think it was.
Right, and it's not online. Big changes, if it ever does go online. Hey, I was just using my box a year and a half ago. But I built it for its purpose: no compilers, no X, no diddly-squat, *and* I'd run Bastille Linux on it. To the best of my knowledge, over 10 years, I'd never had an intrusion.
I have had intrusions; that box actually was originally RH 4.2, but got upgraded after an intrusion (which is when its direct internet went away....bind 4 vulnerability). I've learned from those intrusions; good experience. One was on a Ubuntu box, fully up-to-date at the time. Turns
Have you looked into Bastille Linux? It's not a distro, it's a set of scripts to harden a system. <snip>
about it, too. Now I don't allow outbound port 22 to just anywhere (among
Ah, no. When I've had a home network with the old machine running, the *only* place it would accept ssh from was the inside NIC. <snip>
Filed a bug report, right? :-)
*If* I could pin down the exact cause, and I can't play around with the machine, since the user needed it *now*....
Just *now* and not *yesterday* ? :-) But I understand; the goal of filing a report is to file a useful report, and 'it broke' is not a useful report....
Yup. That's what most of us jump up and down about, when a user says "it's Broke!!!", when they mean something went wrong in a package. And by *now*, I meant that he's working on a project hot and heavy, and will for a week or two or more, and I don't want to shove him out of his cube to screw with this, rebooting for hours.
mark
On 1/21/2011 1:35 PM, m.roth@5-cent.us wrote:
Yup. That's what most of us jump up and down about, when a user says "it's Broke!!!", when they mean something went wrong in a package. And by *now*, I meant that he's working on a project hot and heavy, and will for a week or two or more, and I don't want to shove him out of his cube to screw with this, rebooting for hours.
That's just one of the reasons that it's nice to divorce the display from the processing. I mostly do it with NX/freenx. Unfortunately it looks like future versions of the NX library aren't going to be free. Does anyone know of any other equivalents?
On Friday, January 21, 2011 02:35:11 pm m.roth@5-cent.us wrote:
I have a friend with several RISC 6000's, and of course his MicroVAX. You had a PDP-8? When I was taking an o/s class in the mid-eighties, I was on a PDP-11/780. *Nice* machine, running RSTS, I think it was.
Hmm, I wonder....nope, simh isn't in EPEL 5 or 6 yet (it's available for F14). See simh.trailing-edge.com and you'll see why I mention it.... I used simh's MicroVAX module to rescue some disk images from the VS4000's we have (they are controllers for our 7,000 pound 20x20 microdensitometers used for photographic plate scanning; see http://www.pari.edu/library/apda/rooms/ for a little bit of info about what they're for).
We want to replace the VS4000's with Linux box(en); since the interface to GAMMAs I and II is CAMAC-over-SCSI plus IEEE-488-over-RS-232 (CAMAC for the digitizer ADC and GPIO; IEEE-488 for the Agilent/HP laser interferometer servo system for the platen drive), I'm considering using the SGI box to control them; if not the SGI box, any generic CentOS box with RS-232 or IEEE-488 and a SCSI adapter will work. (GAMMA = Guide star Automatic Measuring MAchine; used at Space Telescope Science Institute (STScI) to generate the guide star catalog for use with Hubble, as well as for generating the one arcsecond digitized sky survey 102 volume CD set.
Have you looked into Bastille Linux? It's not a distro, it's a set of scripts to harden a system.
Yes; I have tried it out, but it's just another one of those things that I periodically look at and say 'I need to be doing that....' I think the first time I looked at it was back before RHEL3, maybe in the RHL7.2 timeframe. It's on the list; somewhere between 'Implement PacketFence (implies writing a module for Cisco Catalyst 5500 and Cisco 7600 and Catalyst 8540 and Catalyst 2948G-L3 and the other old but working oddball Cisco switches and routers in my network)' and 'Implement IPv6 (once the ISP gives me the prefix)'. That is, pretty high up the list, just not in the execution queue yet.
<snip> > about it, too. Now I don't allow outbound port 22 to just anywhere (among
Ah, no. When I've had a home network with the old machine running, the *only* place it would accept ssh from was the inside NIC.
That's the point; it was an outbound *to* someone else's port 22 brute-forcer. I can count on one hand the number of people who have come here and had me add their server to the 'outbound to port 22' permit ACL on the Cisco border router(s). That way, even when someone gets in, they can't get out, at least not on that port. Yeah, I said when, not if. Someone at some point in time will get in; when that does happen I want to try to mitigate the potential for damage.
That is, since I know I cannot possibly prevent all ingress attempts, I can at least make the success as useless as possible. That's part of the reason PacketFence is high on my To Do list. 1 PARI Drive Rosman, NC 28772 http://www.pari.edu
On 1/21/2011 12:22 PM, Lamar Owen wrote:
I'll let the following speak for itself. Read it carefully. It's from a running machine. # cat /etc/redhat-release Red Hat Linux release 5.2 (Apollo) # uname -a Linux localhost.localdomain 2.0.36 #3 Fri Apr 9 15:36:11 EDT 1999 i586 unknown # date Fri Jan 21 13:15:04 EST 2011 #
What's that about 'if it ain't broke, don't fix it' at least with boxes that don't have a direct Internet connection......and this box is doing its job, and doing it well, and with the features that meet the need. Yes, it's had a hard drive replacement, a motherboard/CPU replacement, among other things.... but even back in those days cloning drives was somewhat common.....
RH 7.3 was my 'run forever' version - using the update stream from freshrpms while it lasted. I had one run of 4+ years of uptime, interrupted by a server room move, then about that long again before office changes made it obsolete. It was nice to have DHCP/DNS, mail, etc., on a box that was reliable. Incidentally, I think that was the only version where the stock RH build of mod_perl was done right and they proceeded to break it again in RH8.
On Fri, 21 Jan 2011, Les Mikesell wrote:
RH 7.3 was my 'run forever' version - using the update stream from freshrpms while it lasted. I had one run of 4+ years of uptime, interrupted by a server room move, then about that long again before office changes made it obsolete. It was nice to have DHCP/DNS, mail, etc., on a box that was reliable.
I had a RH 7.3 workstation (daily X logins, Mozilla, plenty of compiling and RPM building, etc) that ran the entire 22 months I was with that employer with the exception of a single half-hour gap when I moved offices across the hall.
At Fri, 21 Jan 2011 09:55:56 -0500 CentOS mailing list centos@centos.org wrote:
Les Mikesell wrote:
<MVNCH> > In retrospect I think the world would be a better place if everyone using > RH would have walked away the day they stopped permitting redistribution of > binaries to the community that had contributed their code base. But I was > too lazy to do that myself and CentOS lets me stay that way (and at the time, > no one knew how crazy fedora would become...).
Yeah. I played with slackware in the mid-nineties, then went to RH with 4.2. Stayed there until I was ready to leave 9, and I went to SuSE. About a year and a quarter ago, came to CentOS. Much happier. fedora "become" crazy, Mike? The beginning of '06, when I went to SuSE, I already knew that it was bleeding edge, and that wasn't just my opinion, but the opinion of a number of folks I know, whose technical expertise I respect, including some guy who's initials are ESR (his politica are another matter, but that's OT).
*shakes head* I hate fedora (says the guy who just upgraded someone's workstation, and then spent the better part of an hour getting X working....)
Yeah, I too started with slackware, then moved to RH (starting with 4.2) pretty all the way to 9 (managed to skip 8). I install FC2 on an older workstation and things were a bit of a disaster: it refused to believe there was a middle button on the mouse and cdrecord refused to believe there was anything on the two SCSI buses but the scanner -- it failed to detect the system (boot) disk (!), both the internal CD-ROM drive and the external CD-RW drive, not to mention neigher tape drive, the zip drive, and several additional hard drives. Arg -- at that point I installed WBL 3.0 on the workstation and all was good (everything worked properly). I used WBL 3.0, then CentOS 4 and CentOS 5 ever since.
Fedora might be fine as a toy/experimental system, but I'd *never* recomend it for any sort of production system (workstation, desktop, laptop, much less server). I guess Ubuntu might be OK for a newbie's home system, but it is not what *I* am used to. Whatever else one can say, there is a continuity from early RH's distros though CentOS, in terms of system admin (where configuration / admin stuff is and the tools used to deal with configuration and general admin tasks).
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Friday, January 21, 2011 01:09:37 am Parshwa Murdia wrote:
What made me think for this comparison was the simple question why did Fermi Labs and CERN chose SL and developing but they didn't go for other distros, keeping in mind always that all the distros have their own pros and cons but essentially the same security.
That question would be best asked on the SL mailing list(s). The SL FAQ just says that many criteria were used.
On Thu, Jan 20, 2011 at 11:46 AM, Lamar Owen lowen@pari.edu wrote:
On Wednesday, January 19, 2011 06:38:12 pm Scott Robbins wrote:
Boot has to be huge in Fedora for the preupgrade to have a chance of working--having given up on it several releases ago, I have no idea if it's been improved or not.
This is obviously straying from the topicality of this list, but yes the mechanism has been improved at least between F13 and F14, as I did do a preupgrade on my development/testing box, which will likely go to CentOS 6 or SL6 some time RSN.
IIRC, Fedora's pre-upgrade was failing because "/boot"'s default size is/was 200MB and the workaround was to clear out some space by keeping just one kernel and removing the "hidden space" allocated to root on "/boot".
We have to hope that this'll be taken into account and "/boot"'s default set larger if pre-upgrade's coming to CentOS 6. (Would pre-upgrade be to go from CentOS 6 to CentOS 7?!)
-
Benjamin Smith -
Bowie Bailey -
Brunner, Brian T. -
Cia Watson -
fred smith -
John R Pierce -
Lamar Owen -
Leonard den Ottolander -
Les Mikesell -
Lisandro Grullon -
m.roth＠5-cent.us -
Parshwa Murdia -
Paul Heinlein -
Robert Heller -
Scott Robbins -
Sean -
Stephen Harris -
Tom H