hi Guys,
CentOS-3 goes EOL in about 3 months. I was thinking we should do a couple of things for this milestone :
1) Setup and run an education campaign to inform users about this.
2) Put together some documents that clearly lay down the options that users have at this point, and going forward ( Migration options, upgrade paths, virtualised containers etc )
3) Put together some scripts that might help people with various options from point-2.
Of-course, doing some of (2) and (3) before (1) would make (1) more effective.
So, at this time - is there anyone who wants to step forward to take this task up as co-ordinator and lead ?
- KB
Hello All, Hello Kb,
I'm too new on to the centos project (and my English is too bad), so I'm not ready to lead this project but: *I know very well Centos3/RHEL3 and clones *I have some very very good skills in RH and co (10 years already ... kernel hacking, complex bash scripts and things totally useless :-P ) *I'm in the case 2: big servers to migrate, so my work will be (i hope) useful for others (how too, scripts, case study)
Waiting for orders :)
best regards,
js.
Le 11/08/2010 23:12, Karanbir Singh a écrit :
hi Guys,
CentOS-3 goes EOL in about 3 months. I was thinking we should do a couple of things for this milestone :
Setup and run an education campaign to inform users about this.
Put together some documents that clearly lay down the options that
users have at this point, and going forward ( Migration options, upgrade paths, virtualised containers etc )
- Put together some scripts that might help people with various options
from point-2.
Of-course, doing some of (2) and (3) before (1) would make (1) more effective.
So, at this time - is there anyone who wants to step forward to take this task up as co-ordinator and lead ?
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 08/11/2010 09:27 PM, js wrote:
Hello All, Hello Kb,
I'm too new on to the centos project (and my English is too bad), so I'm not ready to lead this project but: *I know very well Centos3/RHEL3 and clones *I have some very very good skills in RH and co (10 years already ... kernel hacking, complex bash scripts and things totally useless :-P ) *I'm in the case 2: big servers to migrate, so my work will be (i hope) useful for others (how too, scripts, case study)
Waiting for orders :)
best regards,
js.
Le 11/08/2010 23:12, Karanbir Singh a écrit :
hi Guys,
CentOS-3 goes EOL in about 3 months. I was thinking we should do a couple of things for this milestone :
Setup and run an education campaign to inform users about this.
Put together some documents that clearly lay down the options that
users have at this point, and going forward ( Migration options, upgrade paths, virtualised containers etc )
- Put together some scripts that might help people with various options
from point-2.
Of-course, doing some of (2) and (3) before (1) would make (1) more effective.
So, at this time - is there anyone who wants to step forward to take this task up as co-ordinator and lead ?
- KB
So,
maybe we should just start a wiki page and gather information there in a structured way?
Timo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Karanbir Singh spake:
On 08/11/2010 08:34 PM, Timo Schoeler wrote:
maybe we should just start a wiki page and gather information there in a structured way?
That might be a good place to start, are you able to do this ?
Sure, but I don't have the rights to create a new page; I need someone to create one and modify ACL so that I can edit it...
- KB
Timo
On 08/12/2010 11:50 AM, Timo Schoeler wrote:
That might be a good place to start, are you able to do this ?
Sure, but I don't have the rights to create a new page; I need someone to create one and modify ACL so that I can edit it...
Now that there is a wiki page in place, its imperative that we setup a plan on what is going to get done, how its going to be tested and what sort of a timeline we have in mind. We can then start pulling out tasks that various people can take on and provide feedback / comments on.
thanks for talking this up Timo
- KB
Well, migrations options should be :
- migrate to CentOS 4 : . Feb 29, 2012 EOL . i386 x86_64 ia64 s390 s390x support . prerequites . services changes (match to upstream)
- migrate to CentOS 5 . Mar 31, 2014 EOL . i386 x86_64 support . prerequites . services changes (match to upstream)
- migrate to CentOS 6 . EOL... . i386 x86_64
JML
Le 12/08/10 16:13, Karanbir Singh a écrit :
On 08/12/2010 11:50 AM, Timo Schoeler wrote:
That might be a good place to start, are you able to do this ?
Sure, but I don't have the rights to create a new page; I need someone to create one and modify ACL so that I can edit it...
Now that there is a wiki page in place, its imperative that we setup a plan on what is going to get done, how its going to be tested and what sort of a timeline we have in mind. We can then start pulling out tasks that various people can take on and provide feedback / comments on.
thanks for talking this up Timo
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Thu, 12 Aug 2010, Karanbir Singh wrote:
On 08/12/2010 04:28 PM, Jean-Marc Liger wrote:
- migrate to CentOS 4 :
- migrate to CentOS 5
- migrate to CentOS 6
is it worth investigating the option to move the physical machine running C3 into a virtualised host on C4/5/6 ?
How would that help? The problem being addressed is that the software will no longer be maintained, not that the host hardware is about to crash and burn.
--- Charlie
is it worth investigating the option to move the physical machine running C3 into a virtualised host on C4/5/6 ?
How would that help? The problem being addressed is that the software will no longer be maintained, not that the host hardware is about to crash and burn.
If you have applications that only run on C3, then it provides the information necessary for maintaining future C3 installations on newer hardware that C3 does not natively support. I would think it would be sufficient to state that C3 will run inside a virtual container and that you would follow X existing document to setup virtual containers and Y existing document for installing C3. pps - C3 is no longer maintained, migrating to C4/5/6 is recommended.
On 08/12/2010 09:33 PM, Blake Hudson wrote:
If you have applications that only run on C3, then it provides the information necessary for maintaining future C3 installations on newer hardware that C3 does not natively support.
Yes, also in many cases the app being hosted on the platform could exposes services in a self contained manner ( a legacy DB ? ), taking it off the wire natively allows the app to run inside the virtualised container without needing to rely on C3's iptable or ssh ( as an example ), which might in turn have reported public vuln's no longer being patched.
- KB
Karanbir Singh wrote:
On 08/12/2010 09:33 PM, Blake Hudson wrote:
If you have applications that only run on C3, then it provides the information necessary for maintaining future C3 installations on newer hardware that C3 does not natively support.
Yes, also in many cases the app being hosted on the platform could exposes services in a self contained manner ( a legacy DB ? ), taking it off the wire natively allows the app to run inside the virtualised container without needing to rely on C3's iptable or ssh ( as an example ), which might in turn have reported public vuln's no longer being patched.
- KB
I totally agree : just *try* to imagine the number or running Red Hat Linux 7.2 still used in production :-) One argument in favor of the virtualization (given by Red Hat at a seminar) was that if you *still* have to maintain legacy apps, virtualization is the way to go, and of course in a separate vlan and not faced to the wild web ...
On Friday, August 13, 2010 02:00:50 pm Fabian Arrotin wrote:
I totally agree : just *try* to imagine the number or running Red Hat Linux 7.2 still used in production :-)
I'm getting ready to upgrade a production system to a virtualized CentOS 2.1 instance. Yes, really, 2.1, as an app (non-opensource) running on that production system needs libc5. Yes, really, libc5, and CentOS 2.1 is the latest dist I've found with libc5. Client has no need or funds to rewrite app or convert to open source app, and is happy with what works.
Production system is running Red Hat Linux 5.2. No, not RHEL 5.2; RHL (boxed set, 1998 vintage) 5.2. Runs like Gump. Not net connected, fortunately.
hi Lamar,
On 08/16/2010 07:25 PM, Lamar Owen wrote:
I'm getting ready to upgrade a production system to a virtualized CentOS 2.1 instance. Yes, really, 2.1, as an app (non-opensource) running on that production system needs libc5. Yes, really, libc5, and CentOS 2.1 is the latest dist I've found with libc5. Client has no need or funds to rewrite app or convert to open source app, and is happy with what works.
Notes that you can share from the process would be very welcome. either post here to the list and we can tweak them into the wiki, or just directly incorporate into the wiki
- KB
On Monday, August 16, 2010 02:30:40 pm Karanbir Singh wrote:
hi Lamar, On 08/16/2010 07:25 PM, Lamar Owen wrote:
I'm getting ready to upgrade a production system to a virtualized CentOS 2.1 instance. Yes, really, 2.1, as an app (non-opensource) running on that production system needs libc5. Yes, really, libc5, and CentOS 2.1 is the latest dist I've found with libc5. Client has no need or funds to rewrite app or convert to open source app, and is happy with what works.
Notes that you can share from the process would be very welcome. either post here to the list and we can tweak them into the wiki, or just directly incorporate into the wiki
I'll try to do so; it's going to be a lengthy process due to some of the lower layers involved; one of which involves migration of the PostgreSQL 6.5.3 database to something more modern....
With KVM being the wave of the future, I'll likely go that route (meaning the target server will need cross-grading from Xen to KVM). Although the initial version of the CentOS 2.1 VM is on VMware Server (which presents a 440BX chipset in the VM, and thus very compatible with the older kernel). VMware server is less than ideal, though, since the kernel module rebuild has to be done after every kernel update.
I'm targeting sometime in October or November to have the process complete.
On 08/11/2010 08:27 PM, js wrote:
*I know very well Centos3/RHEL3 and clones *I have some very very good skills in RH and co (10 years already ... kernel hacking, complex bash scripts and things totally useless :-P ) *I'm in the case 2: big servers to migrate, so my work will be (i hope) useful for others (how too, scripts, case study)
All of those are good things :) So welcome to the mix and look forward to your help!
- KB
On 08/11/2010 08:12 PM, Karanbir Singh wrote:
CentOS-3 goes EOL in about 3 months.
This is an interesting development and perhaps something worth mentioning ?
http://press.redhat.com/2010/08/19/red-hat-enterprise-linux-extended-life-cy...
- KB
On 08/19/2010 11:57 PM, Karanbir Singh wrote:
On 08/11/2010 08:12 PM, Karanbir Singh wrote:
CentOS-3 goes EOL in about 3 months.
This is an interesting development and perhaps something worth mentioning ?
http://press.redhat.com/2010/08/19/red-hat-enterprise-linux-extended-life-cy...
I wonder if "Extended Life Cycle Support is delivered through Red Hat Network, similar to the way regular Red Hat Enterprise Linux content is provided." means "we'll publish the source packages just as we did before". Given the "similar to" part, I guess they will, right ?
wolfy "I am happy to say that I've migrated this year all my Centos 3 servers (and almost all of the desktops, as well) to Centos 5"
On 20/08/10 01:41, Manuel Wolfshant wrote:
On 08/19/2010 11:57 PM, Karanbir Singh wrote:
On 08/11/2010 08:12 PM, Karanbir Singh wrote:
CentOS-3 goes EOL in about 3 months.
This is an interesting development and perhaps something worth mentioning ?
http://press.redhat.com/2010/08/19/red-hat-enterprise-linux-extended-life-cy...
I wonder if "Extended Life Cycle Support is delivered through Red Hat Network, similar to the way regular Red Hat Enterprise Linux content is provided." means "we'll publish the source packages just as we did before". Given the "similar to" part, I guess they will, right ?
I assumed the opposite - similar to Extended Update Support (EUS) for point releases where upstream don't publish the source rpms.
I guess we will have to wait and see :-)
-
Blake Hudson -
Charlie Brady -
Fabian Arrotin -
Jean-Marc Liger -
js -
Karanbir Singh -
Lamar Owen -
Manuel Wolfshant -
Ned Slider -
Timo Schoeler