Discuss

discuss@lists.centos.org

5 participants
34752 discussions

RE: [CentOS] Rebuilding RPMs
by Bowie Bailey 14 Nov '05

14 Nov '05

From: Matt Hyclak [mailto:hyclak@math.ohiou.edu] > > On Mon, Nov 14, 2005 at 12:09:49PM -0500, Bowie Bailey enlightened us: > > From: Karanbir Singh [mailto:Mail-Lists@karan.org] > > > > > > Bowie Bailey wrote: > > > > I am trying to install the Cluster RPMS from rpm.karan.org. > > > > But since I have updated my kernel with yum, I have the wrong > > > > kernel for a couple of the packages. > > > > > > > > I think I can just grab the source RPM and do a rebuild, but > > > > having never attempted that before, I just want to make sure > > > > I'm not missing anything. (I have built RPMs from source > > > > tarballs, so I know how to setup the build environment) > > > > > > > > It looks like I can just do this: > > > > > > > > # rpmbuild --rebuild cman-kernel-2.6.9-36.0.src.rpm > > > > > > > > Is there anything else I need to do? > > > > > > > > > > Just simple rebuilds will work, you might need to work out what > > > order they are built in - and some pkgs like the cman-kernel > > > need a specified --target i686 passed in via the rpmbuild. > > > > Hmmm...no luck there. It still wants the older kernel. > > For the *-kernel packages, you'll have to rpm -i the src.rpm, edit > the spec file, and rebuild from that. Making progress here. One more question and I think I'll be done. I installed the source package and edited the spec file to change the kernel version and remove the fake-build-provides requirement (as I can't seem to find it and it appears to be safe to remove based on a previous conversation on this list). I still have a build requirement for the kernel-hugemem package. I don't have the hugemem kernel installed and I'm just trying to build the smp package. Is it safe to remove this dependency if all I care about is the smp package? $ rpmbuild -bb --target=i686 rpm/SPECS/cman-kernel.spec Building target platforms: i686 Building for target i686 error: Failed build dependencies: kernel-hugemem = 2.6.9-22.0.1.EL is needed by cman-kernel-2.6.9-36.0.i686 Thanks, Bowie

2 1

gd2 on Centos 3.6?
by Mike Kercher 14 Nov '05

14 Nov '05

I need to upgrade gd from 1.8 to 2.x, but can't find any rpm's to do so. If I try to rebuild a .src.rpm, I get into a dependency hell. Does anyone know how I can accomplish this upgrade without getting into a source install? Mike

2 1

Bugzilla package
by Darryl L. Pierce 14 Nov '05

14 Nov '05

Is there a Bugzilla package for CentOS? What I mean is a bundle already created that I can install on my server so I can have my own Bugzilla setup? -- Darryl L. Pierce <mcpierce(a)gmail.com> Homepage: http://mcpierce.multiply.com/ "By doubting we come to inquiry, through inquiry truth." - Peter Abelard

1 0

YUM error "can't create transaction lock"
by James B. Byrne 14 Nov '05

14 Nov '05

A short while ago I reported a network interruption while performing a YUM update on a server. A check of the logs as recommended by a list member indicated that the update process had succeeded. However, I am now encountering the following problem on that same server and my nastily suspicious mind is trying to tell me that the previous event and this situation are somehow related. > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > warning: waiting for transaction lock > error: can't create transaction lock I have googled for this error and have come across a web site devoted to it, but for Redhat's rpm and up2date managers only. There is evidently a lock file or database entry that is preventing yum from proceeding but I am not sure that the information that I have found applies to yum and I am unable to clear the lock manually. After following all the recovery steps I reach this point: > /usr/lib/rpm/rpmdb_dump Packages-ORIG | \ > /usr/lib/rpm/rpmdb_load Packages > rpm -qa > rpm --rebuilddb > warning: waiting for transaction lock Any assistance with this problem is gratefully accepted. I am a digest subscriber so the favour of a direct reply is appreciated. Regards, Jim -- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3

2 1

RE: [CentOS] Rebuilding RPMs
by Bowie Bailey 14 Nov '05

14 Nov '05

From: Karanbir Singh [mailto:Mail-Lists@karan.org] > > Bowie Bailey wrote: > > I am trying to install the Cluster RPMS from rpm.karan.org. But > > since I have updated my kernel with yum, I have the wrong kernel > > for a couple of the packages. > > > > # rpm -i --test cman-kernel-smp-2.6.9-36.0.i686.rpm > > error: Failed dependencies: > > /lib/modules/2.6.9-11.ELsmp is needed by > > cman-kernel-smp-2.6.9-36.0.i686 > > kernel-smp = 2.6.9-11.EL is needed by > > cman-kernel-smp-2.6.9-36.0.i686 > > # uname -a > > Linux bnofdnbackup.buc.com 2.6.9-22.0.1.ELsmp #1 SMP Thu Oct 27 13:14:25 CDT > > 2005 i686 i686 i386 GNU/Linux > > > > I think I can just grab the source RPM and do a rebuild, but > > having never attempted that before, I just want to make sure I'm > > not missing anything. (I have built RPMs from source tarballs, so > > I know how to setup the build environment) > > > > It looks like I can just do this: > > > > # rpmbuild --rebuild cman-kernel-2.6.9-36.0.src.rpm > > > > Is there anything else I need to do? > > > > Just simple rebuilds will work, you might need to work out what order > they are built in - and some pkgs like the cman-kernel need a > specified > --target i686 passed in via the rpmbuild. Hmmm...no luck there. It still wants the older kernel. Do I need the buildcentos user and group? What is "fake-build-provides" and where can I get it? $ rpmbuild --rebuild --target=i686 cman-kernel-2.6.9-36.0.src.rpm Installing cman-kernel-2.6.9-36.0.src.rpm warning: user buildcentos does not exist - using root warning: group buildcentos does not exist - using root warning: user buildcentos does not exist - using root warning: group buildcentos does not exist - using root Building target platforms: i686 Building for target i686 error: Failed build dependencies: kernel-smp = 2.6.9-11.EL is needed by cman-kernel-2.6.9-36.0.i686 kernel-hugemem = 2.6.9-11.EL is needed by cman-kernel-2.6.9-36.0.i686 kernel-devel = 2.6.9-11.EL is needed by cman-kernel-2.6.9-36.0.i686 kernel-smp-devel = 2.6.9-11.EL is needed by cman-kernel-2.6.9-36.0.i686 kernel-hugemem-devel = 2.6.9-11.EL is needed by cman-kernel-2.6.9-36.0.i686 fake-build-provides is needed by cman-kernel-2.6.9-36.0.i686 Bowie

2 1

RPM php-mcrypt - CENTOS 4.2
by Adriano Frare 14 Nov '05

14 Nov '05

Dear Friends, The PHP in CENTOS 4.2 hasn't lib php-mcrypt. Where I do download RPM php-mcrypt ? Thanks Adriano

3 3

Re: [CentOS] selinux stuff - I just don't get
by Brian T. Brunner 14 Nov '05

14 Nov '05

How do we define Ready? I gave that answer in the text you replied to: when it doesn't break things. You ask about applications not being SELinux aware. The proper things for SELinux to do in those cases is advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux. This is consistent with SELinux being a *service* to the operator, not a bully-boss to the operator and the authors/maintainers of every package Joe Operator might have on his system. >> SELinux is *broken* if it renders otherwise working >> applications dysfunctional as shipped. > Depends on your viewpoint. No, it doesn't. It's about ownership of control. Is this RedHats' system to break if they want to compel me to do things their way? If not, then distributing SELinux with a default of 'on' when it breaks running systems is distributing a broken software package. >SELinux works. It's just that most software isn't designed > with it in mind. ;-> Translate: Everybody is out of step except my boy! (and those who happen to be in step with him). I say Broken, and Disabled for Good. The proper things for SELinux to do in cases of non-compliant apps is to advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux. That's a *service*. Breaking said applications is a broken application. Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> thebs413(a)earthlink.net 11/14/05 10:49AM >>> "Brian T. Brunner" <brian.t.brunner(a)gai-tronics.com> wrote: > 1: SELinux is hereby invited to grow by giving pain to > others, not to me. When it's ready for release to the > unsuspecting world, let it be released in a 'default on' > state then. Not now. How do you define "ready"??? Do we wait until all software is SELinux-aware? Do we wait until all sysadmins know how to use it? Same problems with ... NPTL ANSI C++ GLibC 2 and many others. Red Hat is forcing people to adopt it, so people have to comply. Because if they don't, they won't. And then it will _never_ be "ready." > SELinux is *broken* if it renders otherwise working > applications dysfunctional as shipped. Depends on your viewpoint. The same was said about NPTL, ANSI C++ and GLibC 2. Yet Red Hat regression tests _all_ its distros as a whole before shipment. It verifies things work as they should. That was true of the first Red Hat distro with NPTL, the first distro with ANSI C++ compliant compilers and code, with GLibC 2. But then people configure things, use them in ways that aren't stock, and things start to break. And the biggest culprit is legacy software that isn't compatible or compliant. Who's at fault then? In the end, it's not about "fault" and it's not about "broken." By the same definition, _real_ firewalls that do outgoing as well as incoming blocking are "broken" as well. Furthermore, the same could be said for higher-layer IDS/IPS systems. Red Hat always forces the issue. They get chastized for it. Their software and/or defaults get declared as broken, etc..., etc..., etc... In fact, I distinctly remember a major complaint about Red Hat taking off suid on cdrecord, which forced people to use proper permissions on the devices. That was also, so-called, "broken." But then, Red Hat had only one of the very few distros without the kernel 2.8.1.x priority issue (because cdrecord didn't run suid). So who was "broken" there? It's all a matter of viewpoint. > I don't mind being asked to volunteer to alpha/beta test > software. What's done is to *compel* me to be a SELinux > tester, or to disable it. Everybody who is inclined to > help SELinux get ready for The Big Time Release, *please* > accept my encouragement to do so. SELinux is already "The Big Time" -- but the majority of software on Linux is not. At some point, _someone_ has to get people to care. SELinux works. It's just that most software isn't designed with it in mind. ;-> > Us other miserable grunts who want to beta test something > else are best off disabling SELinux as of it's current > behavior. > "It's needed for security" meets the "necessary" test, but > not the "proper" test, which won't be met until it works > without breaking things. Then you're going to be waiting _forever_. Just like most people don't do "deny all outgoing" firewalls either. They don't want have to deal with things. I hate these meta-discussions. But I guess I'm tired of seeing "compatibility issues" mistaken for "broken." SELinux throws a wrench into a lot of programs that should be written differently, and no amount of "SELinux hacking" is going to be a "workaround" for some programs/configurations. The mindset has to change. Otherwise, you will _never_ get something like SELinux to work. And Linux won't be able to reach higher CC levels. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* 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

2 1

Re: [CentOS] selinux stuff - I just don't get
by David Thompson 14 Nov '05

14 Nov '05

Peter Farrow wrote: >I agree 100% I don't need it to make a system secure. > >>and it appears still that your confidence that you can secure systems >>without it gets in the way of any efforts to learn how it may benefit >>you. Having an agent like selinux that knows and monitors the behavior of known processes, and prevents unexpected behavior, presents a second line of defense that _may_ prevent or mitigate an attacker's ability to take over a system. While certainly not a substitute for secure programming practices, it may lessen the impact of security holes that do exist in deployed applications. Is it worth the added code complexity, configuration complexity, system resources, etc. required to use it? That is a question that different admins will come to their own conclusions about. Also, selinux is in its relative infancy, and there is currently both a shortage of expertise about it in the admin community, and problems in the current packaging (e.g. rule sets that break things in the default configuration) that are causing headaches. As these issues are dealt with, folks may or may not decide that selinux enhances the security of their systems. Some have already made their decisions. We are currently running selinux in permissive mode. Also, I had to remove some of the RPMs during the Centos 4.2 update, because the RPM update wanted to scan every file in the ~4000 user home directories in our central file storage pool _from every host running the update_. Oh, and that's a central file storage pool that doesn't even do ACLs. Bad selinux. No biscuit. That being said, I would like to use selinux as _one_ piece of our security infrastructure. But there are several issues that need to be solved before I do so. Dave Thompson UW-Madison

1 0

Mail Server
by ijez 14 Nov '05

14 Nov '05

Hi, I need to setup a new mail server and before I got my feet wet or losing in the configurations jungle, I really need some advice from the gurus here for what the best software to used for the mailserver base on CentOS 4.x setup. The objective is, the mailserver will be easy to setup, maintained and have some 1. database backend for storing user info ( mysql? ) 2. spam and antivirus filtering 3. webbase user administrations 4. Provide smtp,smtps,pop3,pop3s,imap,imaps service Any pointer to a good documentations, how-to or links base on CentOS 4.x setup is really appreciates. Thanks In Advances, regards, ijez

11 15

Re: [CentOS] selinux stuff - I just don't get
by Brian T. Brunner 14 Nov '05

14 Nov '05

1: SELinux is hereby invited to grow by giving pain to others, not to me. When it's ready for release to the unsuspecting world, let it be released in a 'default on' state then. Not now. 2: The word 'but' *always* indicates a denial of the statement before the 'but'. What's before the 'but' in this case is not just too important to deny, it's an understatement. SELinux is *broken* if it renders otherwise working applications dysfunctional as shipped. I don't mind being asked to volunteer to alpha/beta test software. What's done is to *compel* me to be a SELinux tester, or to disable it. Everybody who is inclined to help SELinux get ready for The Big Time Release, *please* accept my encouragement to do so. Us other miserable grunts who want to beta test something else are best off disabling SELinux as of it's current behavior. "It's needed for security" meets the "necessary" test, but not the "proper" test, which won't be met until it works without breaking things. Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> jperrin(a)gmail.com 11/14/05 09:29AM >>> SELinux is going through growing pains, and it's not quite to the point where I'd call it "user friendly", but ******************************************************************* 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

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