Discuss August 2008

discuss@lists.centos.org

271 participants
280 discussions

Adding new Hard disk to server with RAID-5
by Lunix1618 23 Aug '08

23 Aug '08

Hi all, I have Dell 2950 III with RAID-5 installed and managed by hardware Raid controller, I also use LVM when install CentOS. Now I get more 03 Hard disk and I would like to add it in to the running system. My question is: 1) if new hard disks add in to the machine, I have to rebuild the RAID volume with RAID management (raid controller) and the volume will be expanded, but is that make any problem to LVM at OS level ? 2) if (1's) answer is YES, what I need to do to prevent trouble occur ? If any one exprience or know the place can help me start pls share. Sorry for the dumb question but I never did this before as a newbie Linux admin - I am 'handmade' former....Windows admin Thanks for your help. regards.

2 1

Re: [CentOS] OT: Google Earth, v.4.3.7284.3916 (beta) on CentOS 5.2 (32 bit) (SOLVED)
by Lanny Marcus 23 Aug '08

23 Aug '08

On Fri, Aug 22, 2008 at 8:00 PM, Lanny Marcus <lmmailinglists(a)gmail.com> wrote: > On Fri, Aug 22, 2008 at 6:49 PM, Lanny Marcus <lmmailinglists(a)gmail.com> wrote: >> On Fri, Aug 22, 2008 at 3:48 PM, MHR <mhullrich(a)gmail.com> wrote: >>> On Fri, Aug 22, 2008 at 11:22 AM, Lanny Marcus <lmmailinglists(a)gmail.com> wrote: >>>> The version of Google Earth I installed last December was working >>>> great this morning. Then, I decided to update to the latest version >>>> and when I tried to do that with yum, I didn't have the right name for >>>> the package (now, I think it may be "google-earth"), so I downloaded >>>> the file (GoogleEarthLinux.bin) and installed with "sh >>>> GoogleEarthLinux.bin" The latest version is now installed and I can >>>> launch it, without any problem, but, it does not seem to >>>> work......... :-) >> >>> Where did you get this? >> >> Mark: I got it from google.com I have google among my yum >> repositories, but I couldn't remember what the package was called, so >> I >> couldn't "yum update" and I downloaded and installed their file, but >> it won't go. It isn't getting any date from the Google Earth servers. >> That >> worked perfectly, with the older version I had been using. Lanny >> > > I tried to install google-earth with yum but either that isn't the > name of the package or it is not available in the Google repository. > Then, I did some reading on the Google site. Question: How do I > determine whether or not the CPU in this box (I think it's an Intel > Celeron 2.6 GHz) supports SSE2 or not? I suspect the CPU does *not* > support SSE2. Posting some information below: > >>Hi Folks, > >>After taking a peek and looking at some of the issues in this thread: > >>http://groups.google.com/group/earth-linux/browse_thread/thread/b2a5e... > >>I thought you guys deserved an update. The long and short of it is >>that Google Earth 4.3 only works in Linux on machines with processors >>that support SSE2. This means a P4, A64, or greater is now required. I >>too was sad to see my little Athlon XP-M machine unable to run 4.3 >>with all of it's beautiful sunlight and atmosphere effects. > >>However, I'd like to let you know that we're aware of this and we're >>looking into getting 4.2 available for you folks! > >>Thanks for your patience, >>ERR <snip> SOLVED. I went back to the previous version of Google Earth for Linux. It must be that the Celeron CPU does *not* support SSE2. Previous version works great. :-) Google Earth 4.2.0205.5730 Build Date Nov 13 2007 Build Time 17:50:46 Renderer OpenGL Operating System Linux (2.6.18.1) Video Driver Tungsten Graphics, Inc Max Texture Size 2048x2048 Server kh.google.com User

1 0

CentOS position on systems intrusion at Red Hat
by Karanbir Singh 22 Aug '08

22 Aug '08

Earlier in the day today Red Hat made an announcement [1] that there had been an intrusion into some of their computer systems last week. In the same announcement they mention that some of the packages for OpenSSH on RHEL-4 ( i386 and x86_64 ) as well as RHEL-5 ( x86_64 ) were signed by the intruder. In their announcement they also clarified that they were confident that none of these, potentially compromised, packages made their way into or through RHN to client and customer machines. As a security measure a script [3] was made available along with a semi-detailed description of the issue [2]. We take security issues very seriously, and as soon as we were made aware of the situation I undertook a complete audit of the entire CentOS4/5 Build and Signing infrastructure. We can now assure everyone that no compromise has taken place anywhere within the CentOS Infrastructure. Our entire setup is located behind multiple firewalls, and only accessible from a very small number of places, by only a few people. Also included in this audit were all entry points to the build services, signing machines, primary release machines and connectivity between all these hosts. Since OpenSSH is a critical component of any Linux machine, we considered it essential to audit the last two released package sets ( openssh-4.3p2-26.el5.src.rpm, openssh-4.3p2-26.el5_2.1.src.rpm ). I have just finished this code audit, and can assure everyone that there is no compromised code included in either of these packages. A similar check is also being done for the CentOS-4 sources. Packages released today, by upstream, ( based on : openssh-4.3p2-26.el5_2.1.src.rpm, openssh-3.9p1-11.el4_7.src.rpm ) address two issues. Firstly they contain a fix for http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752 . And secondly, in the remote event that someone had indeed got compromised packages via RHN, their packages would get updated to a known good state. We wanted to get these packages out right away to address the first issue, and also to cover users converting non updated RHEL installs to CentOS in the next few weeks/months. Release of these packages into the mirror.centos.org network does *not* imply that CentOS users are affected by the intrusion at Red Hat. Finally, while we feel confident that there is no possibility of this compromise having been passed onto the CentOS userbase, we still encourage users to verify their packages independently using whatever resources they might have available. -- [1]: https://rhn.redhat.com/errata/RHSA-2008-0855.html [2]: http://www.redhat.com/security/data/openssh-blacklist.html [3]: https://www.redhat.com/security/data/openssh-blacklist-1.0.sh :Its important to note that this script *only* checks for packages built within Red Hat, and will *not* be a reliable source of verification on CentOS since we rebuild from sources, using no Red Hat binary. -- Karanbir Singh CentOS Project { http://www.centos.org/ } irc: z00dax, #centos(a)irc.freenode.net

1 0

Is there a way to save the routing table permanently?
by ABBAS KHAN 22 Aug '08

22 Aug '08

I'm adding the default gateway to the route through "route add default gw 10.10.10.10" which is also shown in "route -n" but the problem is that as soon as I restart the network through /etc/init.d/network restart; the route sets to default one...! SO, my question is there any way to save the modified route permanently by hardcoding the changes? Thanks.

13 24

Yum Issues with Dev groups
by Joseph L. Casale 22 Aug '08

22 Aug '08

Just my luck, None of my CentOS systems or my Fedora systems can #yum groupinstall "Development Tools" "Development Libraries"? Both are having dep issues? Is that a coincidence, or what's going on? The CentOS boxes all complain: --> Processing Dependency: glibc-common = 2.5-18.el5_1.1 for package: glibc Error: No Package Matching glibc.i686 jlc

4 12

Disk quotas for Sendmail
by Jussi Hirvi 22 Aug '08

22 Aug '08

Hi, CentOS 5.x, Sendmail 8.13.8. I would like to start using disk quotas on my Sendmail server, and optimally they should be configurable by user or group. How can this be done? (I tried to google, but no success.) - Jussi -- Jussi Hirvi * Green Spot Topeliuksenkatu 15 C * 00250 Helsinki * Finland Tel. & fax +358 9 493 981 * Mobile +358 40 771 2098 (only sms) jussi.hirvi(a)greenspot.fi * http://www.greenspot.fi

9 18

A couple of minutes on GnuPG and signing files
by R P Herrold 22 Aug '08

22 Aug '08

There has been a notice of a breach (see: CVE-2007-4752) as to some binary content upstream of CentOS. I do not address that matter here beyond stating that the CentOS team have responded to the matter, and will continue this review process: updated 22 Aug 2008 CentOS acknowledge CVE-2007-4752 and are reviewing our build and signing processes and hosts for signs of tampering subsequent to retrieval of SRPMs It can be hard for a person to get a capsule writeup on signed content, and how to verify that it is indeed authentic. I have placed clearsigned content addressing this process at my personal domain webserver: http://www.herrold.com/import-key-howto.txt.asc and as an attachment to this email. I have verified that the copy at my site verifies. this email. Hopefully this attched writeup will transit the CentOS mailing list manager intact. I also include it inline below, but this may mangle the signature. -- Russ herrold -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A few minutes on using detached and clearsigned content. In light of today's CVE-2007-4752 by the CentOS project's upstream: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752 I issue this brief piece on using GnuPG 1. View a proposed key to use, at the MIT keyserver from: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x650D5882 2. Copy and create a local instance [herrold@centos-5 redhat]$ vi rht-key [herrold@centos-5 redhat]$ gpg --import rht-key gpg: key 650D5882: duplicated user ID detected - merged gpg: key 650D5882: public key "Red Hat, Inc. (Security Response Team) <secalert(a)redhat.com>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 2 signed: 5 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: depth: 1 valid: 5 signed: 2 trust: 0-, 0q, 0n, 1m, 4f, 0u gpg: next trustdb check due at 2009-03-14 3. Compute a local fingerprint of the candidate [herrold@centos-5 redhat]$ gpg --fingerprint 650D5882 pub 1024D/650D5882 2001-11-21 Key fingerprint = 9273 2337 E5AD 3417 5265 64AB 5E54 8083 650D 5882 uid Red Hat, Inc. (Security Response Team) <secalert(a)redhat.com> sub 2048g/7EAB9AFD 2001-11-21 [herrold@centos-5 redhat]$ 4. Compare and validate the fingerprint of the candidate against the RHT statement of the same fingerprint: http://www.redhat.com/security/team/key/ 5. You do NOT need to accept a key permanently to check signed content purportedly with it; consider the Red Hat notice at: http://www.redhat.com/security/data/openssh-blacklist.html 6. We can retrieve the checking script wget https://www.redhat.com/security/data/openssh-blacklist-1.0.sh and the (presumptively) signed checksum of that file wget https://www.redhat.com/security/data/openssh-blacklist-1.0.sh.asc This is called a detached signature 7. And then we can validate ('--verify') that the signature and the file were signed by a person in possession of the private key. Hopefully that private key is itself protected, as behind one way firewalls, and with a 'pass phrase' which matches a known public (which we retrieved and added earlier). This procedural security process is followed by me [one way firewalls, and pass phrases, and other CentOS team members], along with other measures. [herrold@centos-5 redhat]$ gpg --verify openssh-blacklist-1.0.sh.asc \ openssh-blacklist-1.0.sh gpg: Signature made Fri 22 Aug 2008 05:02:29 AM EDT using DSA key ID 650D5882 gpg: Good signature from "Red Hat, Inc. (Security Response Team) <secalert(a)redhat.com>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 9273 2337 E5AD 3417 5265 64AB 5E54 8083 650D 5882 [herrold@centos-5 redhat]$ 8. As we have not indicated to gpg that we permanently trust this key, gpg adds the WARNING -- this is expected and correct under this outline. The validation checks out. 9. This file can be clearsigned -- the process we will follow is this: [herrold@centos-5 .gnupg]$ gpg --clearsign import-key-howto.txt You need a passphrase to unlock the secret key for user: "R P Herrold <herrold(a)owlriver.com>" 1024-bit DSA key, ID 9B649644, created 2003-02-09 File `import-key-howto.txt.asc' exists. Overwrite? (y/N) y [herrold@centos-5 .gnupg]$ 10. That is, import-key-howto.txt is clearsigned, and a new file, import-key-howto.txt.asc, is produced. As I did it twice, to add this text, the warning about Overwriting a file appeared. 11. This is a non-detached (clearsigned, file, and might also be tested by retrieving the indicated key contents, and doing a '--verify' 12. As I have previously certified my own key, I can do it more simply locally: [herrold@centos-5 .gnupg]$ gpg --verify import-key-howto.txt.asc gpg: Signature made Fri 22 Aug 2008 12:37:39 PM EDT using DSA key ID 9B649644 gpg: Good signature from "R P Herrold <herrold(a)owlriver.com>" [herrold@centos-5 .gnupg]$ Note that the TIME of the signing will vary, as I have to resign the file after adding this content. 13. Previously (prior to 22 Aug 2008), I have included my PGP details in every piece of email I send. Starting today, as to email originate; I will add another line with my GPG details as well. I will send this document to the main centos mailing list. Date: Thu, 21 Aug 2008 17:43:28 -0400 (EDT) From: R P Herrold <herrold(a)owlriver.com> To: trading-shim general mailing list <ts-general(a)trading-shim.org> Subject: segmentation faults In-Reply-To: <1219351509.12150.18.camel@gb07> Message-ID: <alpine.LRH.1.999.0808211742100.2443(a)arj.bjyevire.pbz> References: <200808202117.m7KLH4rf011059(a)pippin.first.lan> <20080820224216.GA11712@localhost> <alpine.LRH.1.10.0808202147340.28881(a)arj.bjyevire.pbz> <1219351509.12150.18.camel@gb07> User-Agent: Alpine 1.999 (LRH 1145 2008-08-19) X-M: Go Blue X-OpenPGP-Key-ID: 0x7BFB98B9 MIME-Version: 1.0 In pine (alpine), one does this with Customized X-headers: Customized Headers = X-M: Go Blue X-GnuPG-GPG-Key-ID: ox9B649644 X-OpenPGP-Key-ID: 0x7BFB98B9 This piece intentionally does not address CentOS response; a preliminary statement on this has been posted in the /topic of the IRC channel #centos on irc.freenode.org, and I have done a blog losting which is up at: http://planet.centos.org/ - -- Russ herrold herrold(a)owlriver.com herrold(a)centos.org security(a)centos.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFIru4fMRh1QZtklkQRAgj6AJ9PDJFL59L2WEpzq3f5t93jUf2SrQCePAjm k8mX//167cFOTV0oF6TJFR8= =LFRY -----END PGP SIGNATURE-----

1 1

RE: [CentOS] Re: Support policy CentOS 5
by Patrick Derwael 22 Aug '08

22 Aug '08

<big snip> > Do you have a link to this application's website? Maybe we could determine > why it might be stuck to a limited set of OS releases. If a software can't > keep up with a limited subset of OS updates, maybe they are concerned more > costs then security. Scott, more info here: http://www.parallels.com/en/pro/reqs/ Cheers

2 1

RH's servers breached
by kfx 22 Aug '08

22 Aug '08

What's the point on this for us, CentOS users ? http://www.redhat.com/security/data/openssh-blacklist.html Regards, kfx

2 1

Support policy CentOS 5
by Patrick Derwael 22 Aug '08

22 Aug '08

Hi list Can someone tell me what the exact CentOS policy for end-of-life is for 5.0? Let me explain: I have been using RHEL for a number of years and had to switch to Fedora for installing some packages only supported under F6. As I find Fedora's policy for release life duration too stringent (and I do no longer need the packages that made me choose F6), I'm considering switching over to CentOS5.0 I know, 5.0 is not the most recent release, but that one is supported by Parallel Pro (new package I need) Thanks

5 5

← Newer
1
...
8
9
10
11
12
13
14
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss August 2008