Discuss

discuss@lists.centos.org

5 participants
34752 discussions

Customizing desktop systems
by Collins Richey 22 Jan '06

22 Jan '06

My company is now in the process of rolling out enterprise desktop systems (mostly rhel3 since we have some commercial software that is not quite ready for rhel4). Most of our users (ca. 120 workstations) are using RH9. I've developed a simple, extensible set of kickstart post procedures and firstboot procedures that provide a quick way to image new systems, but one thing is missing. I haven't found a good way to deliver a common desktop image for KDE or Gnome. We want to provide each new user with a common set of desktop icons, for example. I tried using a preloaded /etc/skel, but that doesn't work very well. There are too many individual hidden files and directories where userid is imbedded. I would need to search and replace userid in a lot of files. Has anyone in the group tackled this sort of problem, and would you care to share your methods? What I'm trying to avoid is having to configure each new desktop manually to have a common look and feel. -- Collins Richey Debugging is twice as hard as writing the code ... If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan

2 2

Re: [CentOS] Bittorrent RPM/Python Issue
by Jim Perrin 22 Jan '06

22 Jan '06

On 1/22/06, Sam Trenholme <sam+centos(a)hotaru.chaosring.org> wrote: > >Building from source on an rpm based distro isn't a good idea. > > I disagree with this statement. Building from source is something I have > been doing on RPM-based distros since long before Fedora Core or CentOS > existed. It's a very old UNIX tradition. Basically, this is why there > is a /usr/local; the files that are installed from RPMs are in /usr (or > just the root directory) and programs compiled and installed from source > are in /usr/local. Almost all programs, when compiled and installed from > source, will install in /usr/local by default. You're allowed to disagree. It doesn't make your point right however. My statement doesn't make me right either. Just because something was done in the past doesn't make it a tradition, or make it the proper way to do things. Package management by source sucks. Many source applications don't allow for 'make uninstall' etc. So you have to dig by hand to figure out what it put on the system, and dig to remove it if need be. If you're going to take the time to build from source, take the time to put it in an rpm. > The issue, though, is that one shoudn't instll from source to replace a > program already on their system unless they go to great care to make > sure the replaced program doesn't step over the already installed program. > The simplest way to ensure this is to simply remove the RPM install of the > offending program before installing from source. However, some programs > have dependencies on the already-installed RPM which you really don't want > to mess with. The way I work around this is by having my own perl be > called "perl5.8.7" instead of perl in /usr/local/bin, and having my own > from-source install of ghostscript called gs-afpl. This way, the newly > installed program is seen as a completely separate program from the already > installed program. Except that it can't really be duplicated reliably system to system, upgrade to upgrade. There is no changelog for how you built it unless you take the time to do it, and most people don't. Basically once you start down this road you're on your own for support. So yes, as a rule, I stick by my statement of "don't build from source". While it may work well in limited circumstances, it is NOT something that I recommend. It's a last resort option. One major reason for this has to do with RHEL's (and therefore CentOS's) policy of backporting. People look at a version number and assume it's old or has holes. They don't know that the fix they want has already been backported and patched into the current distribution release of the app. The combination of ignorance (intentional or otherwise) of the backporting policy and the desire people have to combine gentoo/solaris/unix logic to a particular distribution leads to problems. Each distribution has its own way of doing things. Whether it's deb, emerge, slackpack, or rpm, you should ALWAYS work within the framework provided by your distribution. > Installing from source can be done, but care has to be taken when installing > from source for a package already on your system. I don't install from > source unless the RPM-based program has a known problem, and the RPM-based > program is the latest official update. I make sure to change the name of > the program which I install from source, and always install in /usr/local. Yes, installing from source can be done. It's quick, but in the end it's far more time-consuming when things don't go as planned. It's not tough to write a spec and build an rpm for something, if you REALLY have to build it yourself. If it works for you, great. But it's bad advice for a mailing list for someone who is learning and potentially far less skilled than you. - Hide quoted text - -- Jim Perrin System Architect - UIT Ft Gordon & US Army Signal Center

1 0

Kolab on Centos 4.x
by Denis Croombs 22 Jan '06

22 Jan '06

Does anyone have Kolab running on Centos 4.x. I have always used Centos 3.x and Kolab 1.0 todate, but cannot find a howto for Kolab V2.x Any clues/url's welcome. Thanks Denis

1 0

htdbm
by Paul R. Ganci 22 Jan '06

22 Jan '06

According to the man page for htdbm: NAME htdbm - Manipulate DBM password databases SYNOPSIS <snipped> htdbm -l [ -TDBTYPE ] <snipped> -l Print each of the usernames and comments from the database on stdout. yet when I execute htdbm I am finding that the output of the command is going to stderr not stdout. I have proved this by trying the following two commands: $ htdbm -l -TDB passwords > junk; wc junk Dumping records from database -- ./passwords Username Comment <snipped> 0 0 0 junk $ /usr/bin/htdbm -l -TDB ./passwords >&junk; wc junk 28 37 1034 junk Note in the first command the output still goes to the screen despite the stdout redirect with ">". In the second command line I added the "&" ito redirect stderr to the file. This time note that there is no htdbm output to the screen and that the file junk now contains the expected data. This is clearly a bug. Does anyone know of a work around to this problem or where I can find a RPM for dbmmanage? -- Paul (ganci(a)nurdog.com)

2 2

Latest kde/tetex updates fail on my attempts. Is it me or ...?
by William L. Maltby 22 Jan '06

22 Jan '06

Trying to apply the latest updates to an Athalon base fully updated CentOS 4.2. In the past used the update process kicked off by clicking the hand-dandy red icon. This failed, so I tried yum. Somewhere in the process, it complained that there was no GPG key for the lame libraries (IIRC, everything's a little hazy after all the Googling trying to fix this). Anyway, tried "yum update", same problem (I think). Tried importing some GPG keys that I thought were from CentOS, tried rm -rf on the cache, tried "yum clean headers" and "yum clean packages" (suspecting temporarily bad mirrors?), etc. Reread *in toto* the yum guide again, googled for hours, which has caused the observed hazing of the cornea and glazing of countenance. The rhn config file is out-of-box stock, but I've added the extras, kb and such to the repos directory. All this has worked in the past. Caveat: I manually installed mplayer on the system before I learned enough to realize it is available from the other repositories. I've not yet corrected the situation, which I suspect is the underlying cause of the 1st error regarding the GPG key for the lame libraries (which I could not resolve, btw). I have *not* googled for what I'm about to show, having given up for the week, except for this posting. Edited Yum output is shown below. Update goes into an endless install process after reporting sources are downloaded already. =========== Edited yum output: abbreviated ============= yum update kdelibs >&/tmp/errs error: rpmdbNextIterator: skipping h# 1875 Header V3 DSA signature: BAD, key ID 443e1821 error: rpmdbNextIterator: skipping h# 1553 Header V3 DSA signature: BAD, key ID 443e1821 error: rpmdbNextIterator: skipping h# 1875 Header V3 DSA signature: BAD, key ID 443e1821 ==== 8 more of above and many other DSA keys once or more each ==== <snipped a hundred or more?> Error: Missing Dependency: perl(File::Basename) is needed by package kdelibs Error: Missing Dependency: perl >= 0:5.000 is needed by package kdelibs Error: Missing Dependency: perl(Getopt::Long) is needed by package kdelibs Error: Missing Dependency: perl(strict) is needed by package kdelibs Error: Missing Dependency: perl(Data::Dumper) is needed by package kdelibs Error: Missing Dependency: /usr/bin/perl is needed by package kdelibs Error: Missing Dependency: libcom_err.so.2 is needed by package kdelibs Error: Missing Dependency: perl(File::Path) is needed by package kdelibs Error: Missing Dependency: perl(vars) is needed by package kdelibs Error: Missing Dependency: perl(Exporter) is needed by package perl- Devel-Carp Error: Missing Dependency: qt-devel >= 1:3.3.3 is needed by package kdelibs-devel Setting up Update Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package kdelibs.i386 6:3.3.1-3.14 set to be updated --> Running transaction check --> Processing Dependency: perl(File::Basename) for package: kdelibs --> Processing Dependency: perl >= 0:5.000 for package: kdelibs --> Processing Dependency: perl(Getopt::Long) for package: kdelibs --> Processing Dependency: perl(strict) for package: kdelibs --> Processing Dependency: perl(Carp) for package: kdelibs --> Processing Dependency: perl(Data::Dumper) for package: kdelibs --> Processing Dependency: kdelibs = 6:3.3.1-3.11 for package: kdelibs- devel --> Processing Dependency: /usr/bin/perl for package: kdelibs --> Processing Dependency: libcom_err.so.2 for package: kdelibs --> Processing Dependency: perl(File::Path) for package: kdelibs --> Processing Dependency: perl(vars) for package: kdelibs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package kdelibs-devel.i386 6:3.3.1-3.14 set to be updated ---> Package perl-Devel-Carp.noarch 0:0.04-1.2.el4.rf set to be updated --> Running transaction check --> Processing Dependency: perl(File::Basename) for package: kdelibs --> Processing Dependency: perl >= 0:5.000 for package: kdelibs --> Processing Dependency: perl(Getopt::Long) for package: kdelibs --> Processing Dependency: perl(strict) for package: kdelibs --> Processing Dependency: perl(Data::Dumper) for package: kdelibs --> Processing Dependency: perl(Exporter) for package: perl-Devel-Carp --> Processing Dependency: openssl-devel for package: kdelibs-devel --> Processing Dependency: /usr/bin/perl for package: kdelibs --> Processing Dependency: libcom_err.so.2 for package: kdelibs --> Processing Dependency: qt-devel >= 1:3.3.3 for package: kdelibs- devel --> Processing Dependency: perl(File::Path) for package: kdelibs --> Processing Dependency: perl(vars) for package: kdelibs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package openssl-devel.i586 0:0.9.7a-43.4 set to be updated --> Running transaction check --> Processing Dependency: perl(File::Basename) for package: kdelibs --> Processing Dependency: perl >= 0:5.000 for package: kdelibs --> Processing Dependency: perl(Getopt::Long) for package: kdelibs --> Processing Dependency: perl(strict) for package: kdelibs --> Processing Dependency: perl(Data::Dumper) for package: kdelibs --> Processing Dependency: perl(Exporter) for package: perl-Devel-Carp --> Processing Dependency: /usr/bin/perl for package: kdelibs --> Processing Dependency: libcom_err.so.2 for package: kdelibs --> Processing Dependency: qt-devel >= 1:3.3.3 for package: kdelibs- devel --> Processing Dependency: perl(File::Path) for package: kdelibs --> Processing Dependency: perl(vars) for package: kdelibs --> Finished Dependency Resolution TIA for any help, Bill

1 0

Bittorrent RPM/Python Issue
by Mark Sargent 22 Jan '06

22 Jan '06

Hi All, tried to install the RPM for bittorrent, and got the following, [root@localhost bittorrent]# rpm -Uvh BitTorrent-4.2.2-1-Python2.3.noarch.rpm error: Failed dependencies: python(abi) = 2.3 is needed by BitTorrent-4.2.2-1.noarch [root@localhost bittorrent]# python -V Python 2.3.4 why is this so, when I have 2.3.4. Is this RPM only compatible with 2.3, not 2.3.1-4? Little confused. Cheers. Mark Sargent.

3 4

yum updates
by Andrew Rice 21 Jan '06

21 Jan '06

Hey all...just curious if anyone has ever run into any trouble using yum for updates.. anything at all? just curious. I use it all the time...finds the dependencies and never had any real issues. just curious how you would downgrade a package though if that option is even at all available or not. -- Andrew Rice Jr Systems Analyst Carrier Management Systems, Inc. 500 Chestnut Street, Suite 500 Abilene, TX 79602 USA support: (325) 672-0975 office: (325) 677-5900 fax: (325) 676-0529 http://www.nams.net NAMS III, NAMS 2000 Centralized, NAMS BMX

2 1

CentOS-announce Digest, Vol 11, Issue 9
by centos-announce-request＠centos.org 21 Jan '06

21 Jan '06

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2006:0184 Critical CentOS 4 s390(x) kdelibs - security update (Pasi Pirhonen) 2. CESA-2006:0160 Moderate CentOS 4 s390(x) tetex - security update (Pasi Pirhonen) 3. CESA-2006:0140 Important CentOS 3 s390(x) kernel - security update (Pasi Pirhonen) 4. CESA-2006:0160 Moderate CentOS 3 s390(x) tetex - security update (Pasi Pirhonen) ---------------------------------------------------------------------- Message: 1 Date: Fri, 20 Jan 2006 14:04:49 +0200 From: Pasi Pirhonen <upi(a)papat.org> Subject: [CentOS-announce] CESA-2006:0184 Critical CentOS 4 s390(x) kdelibs - security update To: centos-announce(a)centos.org Message-ID: <20060120120449.GF7507(a)core.upi.iki.fi> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2006:0184 https://rhn.redhat.com/errata/RHSA-2006-0184.html The following updated files have been uploaded and are currently syncing to the mirrors: s390: updates/s390/RPMS/kdelibs-3.3.1-3.14.s390.rpm updates/s390/RPMS/kdelibs-devel-3.3.1-3.14.s390.rpm s390x: updates/s390x/RPMS/kdelibs-3.3.1-3.14.s390x.rpm updates/s390x/RPMS/kdelibs-devel-3.3.1-3.14.s390x.rpm -- Pasi Pirhonen - upi(a)iki.fi - http://iki.fi/upi/

1 0

ps2 keybaord doesn't work
by Fong Vang 21 Jan '06

21 Jan '06

I just realized that the PS2 on our CentOS systems do not work (normally we use USB). Shouldn't they work by default?

2 1

Installation sequence for 4.2 / 3.6 dual boot
by Bruce McPeek 21 Jan '06

21 Jan '06

Hello, I have a Dell 1850 with dual Xeon procs and two u320 36Gb drives. I would like to set this up as dual boot system with 4.2 on disk 0 and 3.6 on disk 1. I imagine that I would install 4.2 first and then 3.6. Would I need to remove the other hard drive while installing a given version? Any gotchas? How about setting up GRUB? Anything special or does the install take care of it? Thanks, Bruce McPeek

2 1

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