ftp
Hi, I'm having trouble connecting to a SLF5 kerberized ftpd from an SLF5 kerberized ftp client. On the server, I'm using: rpm -qf /usr/kerberos/sbin/ftpd krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client, I'm using: rpm -qf rpm -qf /usr/kerberos/bin/ftp krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client side, I get: ... GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Permission denied GSSAPI error: acquiring credentials GSSAPI ADAT failed GSSAPI authentication failed ... and on the server side, in /var/log/messages, I get: ... ftpd[25305]: gssapi error acquiring credentials ... I do have a valid ticket! and I can connect to another SLF5 node, so it seems to be a server issue. I've tried looking at the kdc logs on fnalu... I use to be able to tail -f the log in the tmp directory but now I can just see a log file that seems to be several hours old. In that log file, however, I do see an ISSUE: line for my server, so it would appear that I do have a valid ftp principal. Any suggestions? Thanks, Ron
Re: ftp
Does the account that you are trying to ftp into on the server side have a valid shell? is that shell listed in /etc/shells? Is ftpd open in the iptables on the server side, and in /etc/hosts.allow, hosts.deny? Steve On Thu, 30 Jul 2009, Ron Rechenmacher wrote: Hi, I'm having trouble connecting to a SLF5 kerberized ftpd from an SLF5 kerberized ftp client. On the server, I'm using: rpm -qf /usr/kerberos/sbin/ftpd krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client, I'm using: rpm -qf rpm -qf /usr/kerberos/bin/ftp krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client side, I get: ... GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Permission denied GSSAPI error: acquiring credentials GSSAPI ADAT failed GSSAPI authentication failed ... and on the server side, in /var/log/messages, I get: ... ftpd[25305]: gssapi error acquiring credentials ... I do have a valid ticket! and I can connect to another SLF5 node, so it seems to be a server issue. I've tried looking at the kdc logs on fnalu... I use to be able to tail -f the log in the tmp directory but now I can just see a log file that seems to be several hours old. In that log file, however, I do see an ISSUE: line for my server, so it would appear that I do have a valid ftp principal. Any suggestions? Thanks, Ron -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
Re: ftp
Hi Steve, The account is my own user account and I can ssh to it. I currently have iptables off. I do have: ftpd: ALL in /etc/hosts.allow and ALL: ALL: banners /etc/banners in host.deny (again, I can ssh into the node just fine). Thanks for the reply. This problem is puzzling to me. I tied added the -v option (actually -v -v -v just in case) to server_args in xinetd.d/gssftp. I just get the additional info of importing the ftp and host principal info (from the keytab). In my /etc/krb5.keytab file I do see something a bit strange: The KVNO for the ftp entry is 3 while the host line has KVNO 6. --Ron Steven Timm wrote: Does the account that you are trying to ftp into on the server side have a valid shell? is that shell listed in /etc/shells? Is ftpd open in the iptables on the server side, and in /etc/hosts.allow, hosts.deny? Steve On Thu, 30 Jul 2009, Ron Rechenmacher wrote: Hi, I'm having trouble connecting to a SLF5 kerberized ftpd from an SLF5 kerberized ftp client. On the server, I'm using: rpm -qf /usr/kerberos/sbin/ftpd krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client, I'm using: rpm -qf rpm -qf /usr/kerberos/bin/ftp krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client side, I get: ... GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Permission denied GSSAPI error: acquiring credentials GSSAPI ADAT failed GSSAPI authentication failed ... and on the server side, in /var/log/messages, I get: ... ftpd[25305]: gssapi error acquiring credentials ... I do have a valid ticket! and I can connect to another SLF5 node, so it seems to be a server issue. I've tried looking at the kdc logs on fnalu... I use to be able to tail -f the log in the tmp directory but now I can just see a log file that seems to be several hours old. In that log file, however, I do see an ISSUE: line for my server, so it would appear that I do have a valid ftp principal. Any suggestions? Thanks, Ron
Re: ftp
What happens, if, as root on the server, you do kinit -k ftp/hostn...@fnal.gov klist -f That will show you if the ftp principal in the keytab is OK. Given the different version numbers it might not be. Steve On Thu, 30 Jul 2009, Ron Rechenmacher wrote: Hi Steve, The account is my own user account and I can ssh to it. I currently have iptables off. I do have: ftpd: ALL in /etc/hosts.allow and ALL: ALL: banners /etc/banners in host.deny (again, I can ssh into the node just fine). Thanks for the reply. This problem is puzzling to me. I tied added the -v option (actually -v -v -v just in case) to server_args in xinetd.d/gssftp. I just get the additional info of importing the ftp and host principal info (from the keytab). In my /etc/krb5.keytab file I do see something a bit strange: The KVNO for the ftp entry is 3 while the host line has KVNO 6. --Ron Steven Timm wrote: Does the account that you are trying to ftp into on the server side have a valid shell? is that shell listed in /etc/shells? Is ftpd open in the iptables on the server side, and in /etc/hosts.allow, hosts.deny? Steve On Thu, 30 Jul 2009, Ron Rechenmacher wrote: Hi, I'm having trouble connecting to a SLF5 kerberized ftpd from an SLF5 kerberized ftp client. On the server, I'm using: rpm -qf /usr/kerberos/sbin/ftpd krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client, I'm using: rpm -qf rpm -qf /usr/kerberos/bin/ftp krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client side, I get: ... GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Permission denied GSSAPI error: acquiring credentials GSSAPI ADAT failed GSSAPI authentication failed ... and on the server side, in /var/log/messages, I get: ... ftpd[25305]: gssapi error acquiring credentials ... I do have a valid ticket! and I can connect to another SLF5 node, so it seems to be a server issue. I've tried looking at the kdc logs on fnalu... I use to be able to tail -f the log in the tmp directory but now I can just see a log file that seems to be several hours old. In that log file, however, I do see an ISSUE: line for my server, so it would appear that I do have a valid ftp principal. Any suggestions? Thanks, Ron -- -- Steven C. Timm, Ph.D (630) 840-8525 t...@fnal.gov http://home.fnal.gov/~timm/ Fermilab Computing Division, Scientific Computing Facilities, Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.
Re: ftp
Thanks for this chant (I hadn't learned/used the -k flag before :) I was able to successfully kinit -k for both the host and ftp principals. So the ftp principal is OK and something else must be wrong. Thanks again Steve. --Ron Steven Timm wrote: What happens, if, as root on the server, you do kinit -k ftp/hostn...@fnal.gov klist -f That will show you if the ftp principal in the keytab is OK. Given the different version numbers it might not be. Steve On Thu, 30 Jul 2009, Ron Rechenmacher wrote: Hi Steve, The account is my own user account and I can ssh to it. I currently have iptables off. I do have: ftpd: ALL in /etc/hosts.allow and ALL: ALL: banners /etc/banners in host.deny (again, I can ssh into the node just fine). Thanks for the reply. This problem is puzzling to me. I tied added the -v option (actually -v -v -v just in case) to server_args in xinetd.d/gssftp. I just get the additional info of importing the ftp and host principal info (from the keytab). In my /etc/krb5.keytab file I do see something a bit strange: The KVNO for the ftp entry is 3 while the host line has KVNO 6. --Ron Steven Timm wrote: Does the account that you are trying to ftp into on the server side have a valid shell? is that shell listed in /etc/shells? Is ftpd open in the iptables on the server side, and in /etc/hosts.allow, hosts.deny? Steve On Thu, 30 Jul 2009, Ron Rechenmacher wrote: Hi, I'm having trouble connecting to a SLF5 kerberized ftpd from an SLF5 kerberized ftp client. On the server, I'm using: rpm -qf /usr/kerberos/sbin/ftpd krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client, I'm using: rpm -qf rpm -qf /usr/kerberos/bin/ftp krb5-workstation-1.6.1-31.el5_3.3.x86_64 On the client side, I get: ... GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Permission denied GSSAPI error: acquiring credentials GSSAPI ADAT failed GSSAPI authentication failed ... and on the server side, in /var/log/messages, I get: ... ftpd[25305]: gssapi error acquiring credentials ... I do have a valid ticket! and I can connect to another SLF5 node, so it seems to be a server issue. I've tried looking at the kdc logs on fnalu... I use to be able to tail -f the log in the tmp directory but now I can just see a log file that seems to be several hours old. In that log file, however, I do see an ISSUE: line for my server, so it would appear that I do have a valid ftp principal. Any suggestions? Thanks, Ron
Re: ftp
The problem turned out to be that there seems to be an selinux configuration issue on my machine and I didn't notice that the setroubleshoot service die (I did suspect that there might be an selinux issue but I was expecting there to be log messages.) Any way, the problem for now is solved. --Ron
Best video card for SL 5? (fwd)
I'm having trouble finding a decent video card that is supported by the drivers in SL 5. The Xorg in that system is getting rather long in the tooth, many newer cards don't work properly, and I want to avoid proprietary add-on drivers. I don't need high performance, but I want to reliably drive a 1920x1200 monitor. I've been using cards based on the ATI X1050 platform, but those are no longer available. thanks, Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA
unknown yum output
Hi all, I'd like to ask you for a help - explanation of yum output. When I get line like: Error: Missing Dependency: jdk = 2000:1.6.0_03-fcs is needed by package java-1.6.0-sun-compat what is the meaning of 2000:1.6.0_03-fcs part ? I was desperate, because when I typed yum remove jdk I was able to see the correct version. After a day I noticed that the only difference is in this number 2000 before ':'. Could you explain to me what it means ? Thanks! Cheers, Vladimir
Re: Security ERRATA Important: bind security for SL 4.x on i386/x86_64
Connie, On every SL4.7 system I tried, doing a 'yum update', I'm getting No Packages marked for Update/Obsoletion. Checking which bind-libs and bind-utils I have, I'm getting version: 9.2.4-30.el4_7.1. Now, the weird part - I first tried (after the message below arrived) on my test virtual system SL4.7 (guest OS on VMWare) with 'yum update' and (besides the new kernel) I got version: 9.2.4-30.el4_8.4 of the bind rpm's. - Larry Connie Sieh wrote on 7/30/2009 12:31 PM: Synopsis: Important: bind security and bug fix update CVE: CVE-2009-0696 CVE-2009-0696 bind: DoS (assertion failure) via nsupdate packets A flaw was found in the way BIND handles dynamic update message packets containing the ANY record type. A remote attacker could use this flaw to send a specially-crafted dynamic update packet that could cause named to exit with an assertion failure. (CVE-2009-0696) Note: even if named is not configured for dynamic updates, receiving such a specially-crafted dynamic update packet could still cause named to exit unexpectedly. This update also fixes the following bug: * when running on a system receiving a large number of (greater than 4,000) DNS requests per second, the named DNS nameserver became unresponsive, and the named service had to be restarted in order for it to continue serving requests. This was caused by a deadlock occurring between two threads that led to the inability of named to continue to service requests. This deadlock has been resolved with these updated packages so that named no longer becomes unresponsive under heavy load. (BZ#512668) After installing the update, the BIND daemon (named) will be restarted automatically. SRPM: bind-9.2.4-30.el4_8.4.src.rpm i386: bind-9.2.4-30.el4_8.4.i386.rpm bind-chroot-9.2.4-30.el4_8.4.i386.rpm bind-devel-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-utils-9.2.4-30.el4_8.4.i386.rpm x86_64: bind-9.2.4-30.el4_8.4.x86_64.rpm bind-chroot-9.2.4-30.el4_8.4.x86_64.rpm bind-devel-9.2.4-30.el4_8.4.x86_64.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.x86_64.rpm bind-utils-9.2.4-30.el4_8.4.x86_64.rpm -Connie Sieh -Troy Dawson -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Re: Security ERRATA Important: bind security for SL 4.x on i386/x86_64
Larry, It takes a really long time to move a errata to our ftp server. The time is in the createrepo and repoview creation. It should be there soon. I think that 47 , 46, 45 are done now for x86_64 and all of the i386 ones are not done. You also may need to do a clean all to clean out the yum cache. -Connie Sieh On Thu, 30 Jul 2009, P. Larry Nelson wrote: Connie, On every SL4.7 system I tried, doing a 'yum update', I'm getting No Packages marked for Update/Obsoletion. Checking which bind-libs and bind-utils I have, I'm getting version: 9.2.4-30.el4_7.1. Now, the weird part - I first tried (after the message below arrived) on my test virtual system SL4.7 (guest OS on VMWare) with 'yum update' and (besides the new kernel) I got version: 9.2.4-30.el4_8.4 of the bind rpm's. - Larry Connie Sieh wrote on 7/30/2009 12:31 PM: Synopsis: Important: bind security and bug fix update CVE: CVE-2009-0696 CVE-2009-0696 bind: DoS (assertion failure) via nsupdate packets A flaw was found in the way BIND handles dynamic update message packets containing the ANY record type. A remote attacker could use this flaw to send a specially-crafted dynamic update packet that could cause named to exit with an assertion failure. (CVE-2009-0696) Note: even if named is not configured for dynamic updates, receiving such a specially-crafted dynamic update packet could still cause named to exit unexpectedly. This update also fixes the following bug: * when running on a system receiving a large number of (greater than 4,000) DNS requests per second, the named DNS nameserver became unresponsive, and the named service had to be restarted in order for it to continue serving requests. This was caused by a deadlock occurring between two threads that led to the inability of named to continue to service requests. This deadlock has been resolved with these updated packages so that named no longer becomes unresponsive under heavy load. (BZ#512668) After installing the update, the BIND daemon (named) will be restarted automatically. SRPM: bind-9.2.4-30.el4_8.4.src.rpm i386: bind-9.2.4-30.el4_8.4.i386.rpm bind-chroot-9.2.4-30.el4_8.4.i386.rpm bind-devel-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-utils-9.2.4-30.el4_8.4.i386.rpm x86_64: bind-9.2.4-30.el4_8.4.x86_64.rpm bind-chroot-9.2.4-30.el4_8.4.x86_64.rpm bind-devel-9.2.4-30.el4_8.4.x86_64.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.x86_64.rpm bind-utils-9.2.4-30.el4_8.4.x86_64.rpm -Connie Sieh -Troy Dawson -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Re: Security ERRATA Important: bind security for SL 4.x on i386/x86_64
The latest version is bind-9.2.4-30.el4_8.4 for 4.x . -connie sieh On Thu, 30 Jul 2009, Connie Sieh wrote: Larry, It takes a really long time to move a errata to our ftp server. The time is in the createrepo and repoview creation. It should be there soon. I think that 47 , 46, 45 are done now for x86_64 and all of the i386 ones are not done. You also may need to do a clean all to clean out the yum cache. -Connie Sieh On Thu, 30 Jul 2009, P. Larry Nelson wrote: Connie, On every SL4.7 system I tried, doing a 'yum update', I'm getting No Packages marked for Update/Obsoletion. Checking which bind-libs and bind-utils I have, I'm getting version: 9.2.4-30.el4_7.1. Now, the weird part - I first tried (after the message below arrived) on my test virtual system SL4.7 (guest OS on VMWare) with 'yum update' and (besides the new kernel) I got version: 9.2.4-30.el4_8.4 of the bind rpm's. - Larry Connie Sieh wrote on 7/30/2009 12:31 PM: Synopsis: Important: bind security and bug fix update CVE: CVE-2009-0696 CVE-2009-0696 bind: DoS (assertion failure) via nsupdate packets A flaw was found in the way BIND handles dynamic update message packets containing the ANY record type. A remote attacker could use this flaw to send a specially-crafted dynamic update packet that could cause named to exit with an assertion failure. (CVE-2009-0696) Note: even if named is not configured for dynamic updates, receiving such a specially-crafted dynamic update packet could still cause named to exit unexpectedly. This update also fixes the following bug: * when running on a system receiving a large number of (greater than 4,000) DNS requests per second, the named DNS nameserver became unresponsive, and the named service had to be restarted in order for it to continue serving requests. This was caused by a deadlock occurring between two threads that led to the inability of named to continue to service requests. This deadlock has been resolved with these updated packages so that named no longer becomes unresponsive under heavy load. (BZ#512668) After installing the update, the BIND daemon (named) will be restarted automatically. SRPM: bind-9.2.4-30.el4_8.4.src.rpm i386: bind-9.2.4-30.el4_8.4.i386.rpm bind-chroot-9.2.4-30.el4_8.4.i386.rpm bind-devel-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-utils-9.2.4-30.el4_8.4.i386.rpm x86_64: bind-9.2.4-30.el4_8.4.x86_64.rpm bind-chroot-9.2.4-30.el4_8.4.x86_64.rpm bind-devel-9.2.4-30.el4_8.4.x86_64.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.x86_64.rpm bind-utils-9.2.4-30.el4_8.4.x86_64.rpm -Connie Sieh -Troy Dawson -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Re: Security ERRATA Important: bind security for SL 4.x on i386/x86_64
Connie, Thanks! The 'yum clean all' did the trick. I can now get the latest bind version. - Larry Connie Sieh wrote on 7/30/2009 3:55 PM: Larry, It takes a really long time to move a errata to our ftp server. The time is in the createrepo and repoview creation. It should be there soon. I think that 47 , 46, 45 are done now for x86_64 and all of the i386 ones are not done. You also may need to do a clean all to clean out the yum cache. -Connie Sieh On Thu, 30 Jul 2009, P. Larry Nelson wrote: Connie, On every SL4.7 system I tried, doing a 'yum update', I'm getting No Packages marked for Update/Obsoletion. Checking which bind-libs and bind-utils I have, I'm getting version: 9.2.4-30.el4_7.1. Now, the weird part - I first tried (after the message below arrived) on my test virtual system SL4.7 (guest OS on VMWare) with 'yum update' and (besides the new kernel) I got version: 9.2.4-30.el4_8.4 of the bind rpm's. - Larry Connie Sieh wrote on 7/30/2009 12:31 PM: Synopsis: Important: bind security and bug fix update CVE: CVE-2009-0696 CVE-2009-0696 bind: DoS (assertion failure) via nsupdate packets A flaw was found in the way BIND handles dynamic update message packets containing the ANY record type. A remote attacker could use this flaw to send a specially-crafted dynamic update packet that could cause named to exit with an assertion failure. (CVE-2009-0696) Note: even if named is not configured for dynamic updates, receiving such a specially-crafted dynamic update packet could still cause named to exit unexpectedly. This update also fixes the following bug: * when running on a system receiving a large number of (greater than 4,000) DNS requests per second, the named DNS nameserver became unresponsive, and the named service had to be restarted in order for it to continue serving requests. This was caused by a deadlock occurring between two threads that led to the inability of named to continue to service requests. This deadlock has been resolved with these updated packages so that named no longer becomes unresponsive under heavy load. (BZ#512668) After installing the update, the BIND daemon (named) will be restarted automatically. SRPM: bind-9.2.4-30.el4_8.4.src.rpm i386: bind-9.2.4-30.el4_8.4.i386.rpm bind-chroot-9.2.4-30.el4_8.4.i386.rpm bind-devel-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-utils-9.2.4-30.el4_8.4.i386.rpm x86_64: bind-9.2.4-30.el4_8.4.x86_64.rpm bind-chroot-9.2.4-30.el4_8.4.x86_64.rpm bind-devel-9.2.4-30.el4_8.4.x86_64.rpm bind-libs-9.2.4-30.el4_8.4.i386.rpm bind-libs-9.2.4-30.el4_8.4.x86_64.rpm bind-utils-9.2.4-30.el4_8.4.x86_64.rpm -Connie Sieh -Troy Dawson -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | High Energy Physics Group 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/ --- Information without accountability is just noise. - P.L. Nelson
Fwd: CentOS Project Administrator Goes AWOL
This affects us. Imagine that all the CentOS users show up to use Scientific Linux. Imagine all their maintainers and developers show up, too. Keith forwarded message --- (http://linux.slashdot.org/story/09/07/30/130249/CentOS-Project-Administrator-Goes-AWOL): Lance Davis, the main project administrator for CentOS, a popular free 'rebuild' of Red Hat's Enterprise Linux, appears to have gone AWOL. In an open letter* from his fellow CentOS developers, they describe the precarious situation the project has been put in. There have been attempts to contact him for some time now, as he's the sole administrator for the centos.org domain, the IRC channels, and apparently, CentOS funds. One can only hope that Lance gets in contact with them and gets things sorted out. * Open Letter (http://www.centos.org/): July 30, 2009 04:39 UTC This is an Open Letter to Lance Davis from fellow CentOS Developers It is regrettable that we are forced to send this letter but we are left with no other options. For some time now we have been attempting to resolve these problems: You seem to have crawled into a hole ... and this is not acceptable. You have long promised a statement of CentOS project funds; to this date this has not appeared. You hold sole control of the centos.org domain with no deputy; this is not proper. You have, it seems, sole 'Founders' rights in the IRC channels with no deputy ; this is not proper. When I (Russ) try to call the phone numbers for UK Linux, and for you individually, I get a telco intercept 'Lines are temporarily busy' for the last two weeks. Finally yesterday, a voicemail in your voice picked up, and I left a message urgently requesting a reply. Karanbir also reports calling and leaving messages without your reply. Please do not kill CentOS through your fear of shared management of the project. Clearly the project dies if all the developers walk away. Please contact me, or any other signer of this letter at once, to arrange for the required information to keep the project alive at the 'centos.org' domain. Sincerely, Russ Herrold Ralph Angenendt Karanbir Singh Jim Perrin Donavan Nelson Tim Verhoeven Tru Huynh Johnny Hughes -- Sincerely, Michael Lauzon -- The Toronto Linux Users Group. Meetings: http://gtalug.org/ TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists - end forwarded message --- -- Keith Lofstrom kei...@keithl.com Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- Your Ideas in Silicon Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
Re: Fwd: CentOS Project Administrator Goes AWOL
Hi, This affects us. Imagine that all the CentOS users show up to use Scientific Linux. Imagine all their maintainers and developers show up, too. I personally don't think that's a bad thing especially if it allows SL to have the ability to open more of it's infrastructure to 3rd party extensions like the CentOS team have done for CentOS Plus etc. For example, EL5 is stuck in the php 5.1.6 and MySQL 5.0.45 days and when you want applications which relay on at least php 5.2.x (and so many do) then you have to go to 3rd party repo's which may be incompatible with other repo's used in the environment. It's really like opening a can of worms and IMHO CentOS got the right mix by having their own team of developers providing those packages which TUV doesn't. In case there's a question, I use SL exclusively for over 30 Linux servers, never used CentOS. Regards, Michael. Keith forwarded message --- (http://linux.slashdot.org/story/09/07/30/130249/CentOS-Project- Administrator-Goes-AWOL): Lance Davis, the main project administrator for CentOS, a popular free 'rebuild' of Red Hat's Enterprise Linux, appears to have gone AWOL. In an open letter* from his fellow CentOS developers, they describe the precarious situation the project has been put in. There have been attempts to contact him for some time now, as he's the sole administrator for the centos.org domain, the IRC channels, and apparently, CentOS funds. One can only hope that Lance gets in contact with them and gets things sorted out. * Open Letter (http://www.centos.org/): July 30, 2009 04:39 UTC This is an Open Letter to Lance Davis from fellow CentOS Developers It is regrettable that we are forced to send this letter but we are left with no other options. For some time now we have been attempting to resolve these problems: You seem to have crawled into a hole ... and this is not acceptable. You have long promised a statement of CentOS project funds; to this date this has not appeared. You hold sole control of the centos.org domain with no deputy; this is not proper. You have, it seems, sole 'Founders' rights in the IRC channels with no deputy ; this is not proper. When I (Russ) try to call the phone numbers for UK Linux, and for you individually, I get a telco intercept 'Lines are temporarily busy' for the last two weeks. Finally yesterday, a voicemail in your voice picked up, and I left a message urgently requesting a reply. Karanbir also reports calling and leaving messages without your reply. Please do not kill CentOS through your fear of shared management of the project. Clearly the project dies if all the developers walk away. Please contact me, or any other signer of this letter at once, to arrange for the required information to keep the project alive at the 'centos.org' domain. Sincerely, Russ Herrold Ralph Angenendt Karanbir Singh Jim Perrin Donavan Nelson Tim Verhoeven Tru Huynh Johnny Hughes -- Sincerely, Michael Lauzon -- The Toronto Linux Users Group. Meetings: http://gtalug.org/ TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists - end forwarded message --- -- Keith Lofstrom kei...@keithl.com Voice (503)-520- 1993 KLIC --- Keith Lofstrom Integrated Circuits --- Your Ideas in Silicon Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs --- End of Original Message ---
Re: CentOS Project Administrator Goes AWOL
On Thu, Jul 30, 2009 at 7:59 PM, Keith Lofstromkei...@kl-ic.com wrote: This affects us. Imagine that all the CentOS users show up to use Scientific Linux. Imagine all their maintainers and developers show up, too. This is a good thing for SL, isn't it? Increase the user base, I am sure Troy and Connie could use some help from the developers, and then lead to the world dominance of SL :) This affects us positively, IMHO, though perhaps there will be less competition. Keith Serguei Mokhov http://www.cs.concordia.ca/~mokhov http://marf.sf.net | http://sf.net/projects/marf
Re: CentOS Project Administrator Goes AWOL
Serguei Mokhov wrote: On Thu, Jul 30, 2009 at 7:59 PM, Keith Lofstromkei...@kl-ic.com wrote: This affects us. Imagine that all the CentOS users show up to use Scientific Linux. Imagine all their maintainers and developers show up, too. This is a good thing for SL, isn't it? Increase the user base, I am sure Troy and Connie could use some help from the developers, and then lead to the world dominance of SL :) This affects us positively, IMHO, though perhaps there will be less competition. The CentOS Project isn't going anywhere. There is simply an issue whereby the person who controls the centos.org domain is being non-responsive and the matter is being dealt with openly. Worst case scenario, the project would have to flip to an alternative domain but the developers have made it clear it will continue and that full contingency plans are in place should they be needed. If there were only one rebuild project then there would be a single point of failure should that project then cease. Besides, diversity and competition are a good thing - each becomes stronger for it. Collaboration and/or shared knowledge in common areas are also attractive. Phil A CentOS and SL user
Re: CentOS Project Administrator Goes AWOL
On Thu, Jul 30, 2009 at 6:28 PM, Serguei Mokhovserg...@gmail.com wrote: On Thu, Jul 30, 2009 at 7:59 PM, Keith Lofstromkei...@kl-ic.com wrote: This affects us. Imagine that all the CentOS users show up to use Scientific Linux. Imagine all their maintainers and developers show up, too. This is a good thing for SL, isn't it? Increase the user base, I am sure Troy and Connie could use some help from the developers, and then lead to the world dominance of SL :) This affects us positively, IMHO, though perhaps there will be less competition. [cough] As someone who knows a bit of both worlds, I can offer to write a *CentOS* wiki article entitled HowTo Migrate from CentOS to SL. [/cough] Akemi - who now has to hide from all CentOS devs.
