Discuss

discuss@lists.centos.org

34758 discussions

Re: [CentOS] Building a kernel without kabichk
by Terry Hull 14 Apr '09

14 Apr '09

On 4/14/09 3:12 AM, in article bfa89a870904140112s490d223ch440cf009d20e88df(a)mail.gmail.com, "Akemi Yagi" <amyagi(a)gmail.com> wrote: > On Mon, Apr 13, 2009 at 8:08 PM, Terry Hull <tah(a)nrg-inc.com> wrote: >> >> >> On 4/13/09 7:01 PM, in article >> bfa89a870904131701i2afd9b41j78b53b0611a9e462(a)mail.gmail.com, "Akemi Yagi" >> <amyagi(a)gmail.com> wrote: > >> The patches I need to make do break kABI. I just have not yet applied them. >> I was trying to get the base kernel to build before I added the complexity >> of patching it. > >>> If the build still fails, please post the last portion of the error >>> log (or e-mail the whole log file to me). >> >> I have attached a compressed log file. The errors seem to be in the build >> of OCFS. > > Thanks for the err log file. From the looks of it, the error is in the > code itself as you noted. So, that should have nothing to do with > kABI. > > I checked my own log for the kernel 128.1.6 building but did not see > anything (warnings and such) relating to ocfs2. You mentioned " have > NOT installed any patches that will break KABI". Have you installed > any patches at all, that is, patches that do not break kABI ? If so, > would any of them touch the ocfs code? > > Akemi It may also be of note that I've done this on two separate machines. I guess I'm a little puzzled by this. It must be true that very few people actually have to turn off kABI, or this would have come up before. I know that I can turn off ocfs in the .config and see if there is anything else that does not build correctly. -- Terry Hull Network Resource Group, Inc.

2 1

Re: [CentOS] Building a kernel without kabichk
by Terry Hull 14 Apr '09

14 Apr '09

On 4/14/09 3:12 AM, in article bfa89a870904140112s490d223ch440cf009d20e88df(a)mail.gmail.com, "Akemi Yagi" <amyagi(a)gmail.com> wrote: > On Mon, Apr 13, 2009 at 8:08 PM, Terry Hull <tah(a)nrg-inc.com> wrote: >> >> >> On 4/13/09 7:01 PM, in article >> bfa89a870904131701i2afd9b41j78b53b0611a9e462(a)mail.gmail.com, "Akemi Yagi" >> <amyagi(a)gmail.com> wrote: > >> The patches I need to make do break kABI. I just have not yet applied them. >> I was trying to get the base kernel to build before I added the complexity >> of patching it. > >>> If the build still fails, please post the last portion of the error >>> log (or e-mail the whole log file to me). >> >> I have attached a compressed log file. The errors seem to be in the build >> of OCFS. > > Thanks for the err log file. From the looks of it, the error is in the > code itself as you noted. So, that should have nothing to do with > kABI. > > I checked my own log for the kernel 128.1.6 building but did not see > anything (warnings and such) relating to ocfs2. You mentioned " have > NOT installed any patches that will break KABI". Have you installed > any patches at all, that is, patches that do not break kABI ? If so, > would any of them touch the ocfs code? > > Akemi No, I have not added any patches at all to the source. I just modified the .spec file and compiled with the --without kabichk option. I also did not have any trouble building the kernel as long as kabichk was enabled. -- Terry Hull Network Resource Group, Inc. President

2 1

Ramdisk
by Matt 14 Apr '09

14 Apr '09

On Centos 4.x 32 I want to create like a 64Mbyte ramdisk. Is there a problem putting 30k to 80k empty files on a ramdisk? Is there a simple howto on creating a ramdisk that anyone knows of off the top of there head? Matt

2 1

python-dbus
by Anne Wilson 14 Apr '09

14 Apr '09

During startup there is a message about a missing python-dbus. Querying rpm and yum tells me that nothing provides python-dbus and no such package exists. What do I need? Anne

3 5

Raid1 on CentOS 5.x 64bit
by Matt 14 Apr '09

14 Apr '09

Does anyone know of a howto on setting up raid1 on CentOS 5.x 64 bit? Matt

7 8

Re: [CentOS] DKMS and new(er) Nvidia-drivers
by Scott Silva 14 Apr '09

14 Apr '09

on 4-6-2009 5:55 AM Sorin Srbu spake the following: > I got the DKMS-system working and now have the Nvidia-drivers v173.08 > installed (using rpmforge as suggested previously). Unfortunately this > particular driver version gives me screen artifacts so as to make the screen > more or less unreadable. > > Nvidia's proprietary drivers are now up to v180.44 and this version is fine > with my test system. > > I really like the DKMS-system, as it enables me to keep kernel and > gfx-drivers up-to-date on our course-lab computers doing 3D-molecular > modeling. However if I can't make use of newer, and better, drivers this > whole thing is borked for me... 8-/ > > My question is who updates those drivers, as the v173.08 Nvidia drivers are > now almost a year old? Would there be any other good repo with more current > drivers suitable for use with DKMS and CentOS? > The repos I found are tagged with PCLinux, Mandriva and Ubuntu to name a few. > I'm not quite sure these rpms would work with CentOS and the dkms install > there. > > Any hints appreciated. Thanks. > You could always try and make a newer version yourself using the old one as a template. Here is some help; http://www.linuxjournal.com/article/6896 http://www.dell.com/downloads/global/power/1q04-ler.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf

3 3

Clamav engine updates
by Mike Yates 14 Apr '09

14 Apr '09

Hi I get this on every scan report:- LibClamAV Warning: *********************************************************** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *********************************************************** ----------- SCAN SUMMARY ----------- Known viruses: 538589 Engine version: 0.94.2 yet "yum update clamd clamav clamav-db" returns "No Packages marked for Update". Is there a yum URL I should add to get 0.95.1 (and onwards) from CentOS or Redhat, or must I "roll my own" ? Mike Yates MBCS CITP (ISSG) IT Support Engineer Hawkgrove Ltd - Software Systems Design 2, The Business Courtyard, Marl Pits Lane, Trudoxhill, Frome, Somerset, BA11 5DL, UK +44 (0)1373 837900 fax: +44 (0)8700 518155 Registered in England: 2756481 VAT Reg: UK 601 1137 11 Registered Office: NSO Associates LLP, 75 Springfield Road, Chelmsford, Essex CM2 6JB All e-mail is subject to contract and is not intended to create a legally binding agreement. Hawkgrove Ltd will only be bound by an agreement in writing signed by an authorized signatory. All outgoing email is scanned by Kerio, using ClamAV Antivirus.

2 1

httpd with SNI
by German Pulido 14 Apr '09

14 Apr '09

Hi! I am currently publishing some web services on a Centos 5.3 server on my office using the included apache httpd. They are available from the Internet, and they require validation (username/password). I would like to publish them all under https, so the passwords won't travel unencrypted, but then all my sites use the same certificate on apache httpd. The solution to this is using an httpd server that supports SNI: <http://en.wikipedia.org/wiki/Server_Name_Indication> however, the httpd included in Centos does not have this feature. Question is: have anybody made httpd RPMs for CentOS supporting this feature? (according to the link, httpd supports this since 2.2.11) or maybe they can be requested on the CentOS Plus repositories? Thanks!

5 4

Repo for Abiword
by centos＠911networks.com 14 Apr '09

14 Apr '09

Hi, I need to run Abiword on CentOS 5.3, any repository? -- Thanks

5 4

Odd SELinux messages during+after 5.3 upgrade (system_mail_t and postfix_postdrop_t access rpm_var_lib_t)
by Dan Mensom 14 Apr '09

14 Apr '09

Hey guys, I've been getting some strange selinux messages after the 5.3 upgrade. It appears as though my mail system (postfix) is constantly trying to access the rpm database? Here's the audit messages (I tend to look at my selinux messages using audit2allow < /var/log/audit.log as I find it easier to read quickly): allow postfix_postdrop_t rpm_t:tcp_socket { read write }; allow postfix_postdrop_t rpm_var_lib_t:file { read write }; allow postfix_postdrop_t user_home_t:file { getattr append }; allow postfix_postdrop_t var_lib_t:file write; allow system_mail_t rpm_t:tcp_socket { read write }; allow system_mail_t rpm_var_lib_t:file { read write }; allow system_mail_t var_lib_t:file write; I've been getting the latter set continously since the upgrade. The first set appeared briefly when I did a 'setenforce 0' to diagnose a spamc_t issue with calling the /usr/sbin/sendmail symlink.. They correspond to audit.log messages similar to the following: type=AVC msg=audit(1239664501.977:9052044): avc: denied { write } for pid=18901 comm="sendmail" name="transaction-done.2009-04-12.22:52.45" dev=loop0 ino=901575 scontext=user_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=user_u:object_r:var_lib_t:s0 tclass=file type=AVC msg=audit(1239664501.977:9052044): avc: denied { read write } for pid=18901 comm="sendmail" name="__db.000" dev=loop0 ino=901554 scontext=user_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=root:object_r:rpm_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1239664501.977:9052044): arch=40000003 syscall=11 success=yes exit=0 a0=5e2237b8 a1=5e223584 a2=5e2439bc a3=8 items=0 ppid=18880 pid=18901 auid=517 uid=517 gid=517 euid=517 suid=517 fsuid=517 egid=517 sgid=517 fsgid=517 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.postfix" subj=user_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null) type=AVC_PATH msg=audit(1239664501.977:9052044): path="/var/lib/rpm/__db.000" type=AVC_PATH msg=audit(1239664501.977:9052044): path=2F7661722F6C69622F79756D2F7472616E73616374696F6E2D646F6E652E323030392D30342D31322E32323A35322E34352028646 56C6574656429 During the upgrade it looks like it was pretty common for most packages' contexts to attempt to access a tcp socket to rpm and do similar things (again, in audit2allow format): allow tzdata_t rpm_t:tcp_socket { read write }; allow tzdata_t rpm_var_lib_t:file { read write }; allow tzdata_t var_lib_t:file write; allow tzdata_t var_t:file read; But I was surprised that these mail messages didn't show up till the following day, and are still showing up continuously now. Does anyone know what these accesses are? And why they might be still continously triggering for the mail system, where as all the other packages have stopped causing them? Also, on a related note, is it normally best practices to 'setenforce 0' during a 5.x upgrade? Is it possible I've damaged something by leaving selinux enabled? Other than the spamassassin issue, the machine seems to be running ok..

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss