Discuss

discuss@lists.centos.org

34758 discussions

Sendmail restriction
by Ugo Bellavance 03 Sep '06

03 Sep '06

Hi, I'm looking for a way, in sendmail, to set access rule, saying: Accept messages for domain.com only from this IP address. I did some research yesterday, but could only find a way to restrict by IP for all domains managed by sendmail. Any ideas? Regards, Ugo

7 12

CentOS needs some love at DistroRankings.com
by Akemi Yagi 03 Sep '06

03 Sep '06

Johnny Hughes wrote: > / Guys, />/ />/ CentOS is not doing very well at this ranking site: />/ />/ http://www.distrorankings.com/ />/ />/ We need some good foo there, so if you like CentOS, go there and rank />/ us ... />/ />/ {If you don't like CentOS then you are getting sleepy .... sleepy ..... />/ You will not remember anything you read in this message} />/ />/ Thanks, />/ Johnny Hughes />/ />/ ------------------------------------------------------------------------ />/ />/ _______________________________________________ />/ CentOS mailing list />/ CentOS at centos.org <http://lists.centos.org/mailman/listinfo/centos> />/ http://lists.centos.org/mailman/listinfo/centos // / I am new to CentOS. Have been running it on a test machine for about 3 weeks now. And I already like it, so poured lot of love on the ranking site. Look, Ma, CentOS is on top of the world. Honestly, I had never heard of the name CentOS until March this year when I also learned about the little city Tuttle.... The fact that the person behind the project is so patient made me feel this is the distro to use. Having used RedHat/Fedora for many years, I found myself quite comfortable on the first day I installed CentOS. Glad I found you, CentOS. Akemi

5 4

Kernel-2.6.9-42.0.2EL fails to boot after upgrade to CentOS 4.4
by Johnny Hughes 03 Sep '06

03 Sep '06

---On Sat, 2006-09-02 at 07:42 -0500, Gerald Waugh wrote: We have a problem with upgrade to 4.4 When we run 'yum update' everything appears to be OK But, if we reboot the server with the new kernel, we get "kernel panic" when the new kernel attempts to load. The CentOS splash screen shows briefly, but not long enough to select the old kernel Gerald (let's try it like this ... johnny :)

9 18

Cron Problem
by Matthew T. O'Connor 03 Sep '06

03 Sep '06

Cron is sending me an email once per minute, the emails look like this: Subject: Cron <root@host> chown root:root /dev/shm/local/local5 && chmod 4755 /dev/shm/local/local5 && rm -rf /etc/cron.d/core && kill -USR1 7140 Body: chown: cannot access `/dev/shm/local/local5': No such file or directory I've un-installed and reinstalled the vixie-cron packages, I have verified that they are not corrupted by using rpm --verify vixie-cron, I have checked all the crontabs on the system there aren't any running every minute. I don't understand why this is happening, anyone have any insight? Thanks, Matt

4 5

CentOS 4.4 LILO Raid (also e2fsprogs in general)
by Benjamin Karhan 02 Sep '06

02 Sep '06

i noticed that the 4.4 upgrade broke LILO on Raid... it gave errors on partitions not on the primary disk along the lines of "/dev/dis: no such device"... even explicitly installing the boot sector on each device in the array, while it allowed the system to boot, gave errors at boot time and did not display the CentOS boot screen anymore... i solved the problem by creating a package for the most recent version of LILO and installing that... with a few minor changes to "lilo.conf" everything was kosker for LILO install and boot... i even made a nice new 640x480x256 CentOS boot screen for it... there is one caveat to using the new LILO... the new version (or at least one above 22.x) must be booted once (text-mode) before LILO can correctly probe the video BIOS... so, the boot screen needs to be installed after an initial priming boot... afterwards, i did some thorough testing before deploying on any production servers... and noticed only one problem... the new version of LILO broke the "grubby" probe... primarily because "/boot/boot.b" is no longer needed... but also because the comparisons between "boot.b" and the actual boot sector aren't accurate anymore either... since i'd noticed that "grubby"'s probe for GRUB itself has been broken for a while... i decided a quick patch-job for the "mkinitrd" package was in order... my new package correctly identifies whether either LILO or GRUB has been installed at all, but lacks the careful byte comparisons that were the core of the breakage of the original "grubby"... it's possibly problematic... but i doubt it... and it solves more problems than it creates... anyways... that solved my 4.4 upgrade breakage... and... since i was writing to the list... i figured i should mention a rather serious, but extremely unlikely to happen, bug i noticed in "e2fsprogs" (specifically "e2fsck")... with the version on CentOS... "e2fsck" will cause some big problems and potential data loss on directories containing more than 1.2 million inodes... the first 1.2 million inodes will be ok... the next 1.2 million (max) will be saved to /lost+found as unidentified files... before it too fills up... and then everything else will just "vanish"... this problem is due to some incorrect math in the handling of the maximum inode size... and has already been fixed in e2fsprogs 1.38... so, my solution was to take the 1.38 Fedora Core sources and build a package for CentOS... if anyone is particularly interested... i have the SRPMS for my lilo, mkinitrd, and e2fsprogs packages... also, i have the pretty new CentOS boot screen (and a few others i made) and some working lilo configurations for switching over to them... all of which i could probably post somewhere public... but if they are really useful, i'd rather ship them along to someone more closely involved in maintaining CentOS... so as to "contribute" as best i could to everyone's future well-being as well... B. Karhan simon(a)pop.psu.edu PRI/SSRI Unix Administrator

1 0

Re: [CentOS] latest kernel
by Clive Gould 02 Sep '06

02 Sep '06

Marko I have 5 servers running CentOS. Four of them work fine with the 42 kernel. The fifth I use as a yum respository and when I try to use the 42 kernel I lose all network connectivity. Reverting to the earlier kernel on this box restores connectivity. I append some dmesg excerpts which suggest that the new kernel handles PCI (GSI) differently, but have not had the time to investigate further. Please let me know if you find a solution. Best wishes Clive dmesg excerpt for 42 kernel: PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9 ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *0, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI interrupt 0000:00:05.0[A]: no GSI - using IRQ 11 ACPI: PCI interrupt 0000:00:06.0[A]: no GSI - using IRQ 5 ACPI: PCI interrupt 0000:00:0e.0[A]: no GSI - using IRQ 5 ACPI: PCI interrupt 0000:00:11.1[A]: no GSI ACPI: PCI interrupt 0000:00:11.2[D]: no GSI - using IRQ 11 ACPI: PCI interrupt 0000:00:11.3[D]: no GSI - using IRQ 11 ACPI: PCI interrupt 0000:00:11.5[C]: no GSI - using IRQ 9 ACPI: PCI interrupt 0000:01:00.0[A]: no GSI - using IRQ 11 apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) apm: overridden by ACPI. 8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004) 8139cp: pci dev 0000:00:0e.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip 8139cp: Try the "8139too" driver instead. ACPI: PCI interrupt 0000:00:06.0[A]: no GSI - using IRQ 5 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:06.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xa400. Vers LK1.1.19 divert: allocating divert_blk for eth0 via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker ACPI: PCI interrupt 0000:00:05.0[A]: no GSI - using IRQ 11 divert: allocating divert_blk for eth1 eth1: VIA Rhine at 0xe3000000, 00:50:ba:a1:86:44, IRQ 11. eth1: MII PHY found at address 8, status 0x7809 advertising 05e1 Link 0000. 8139too Fast Ethernet driver 0.9.27 ACPI: PCI interrupt 0000:00:0e.0[A]: no GSI - using IRQ 5 divert: allocating divert_blk for eth2 eth2: RealTek RTL8139 at 0xa800, 00:10:dc:59:bd:dc, IRQ 5 eth2: Identified 8139 chip type 'RTL-8101' ACPI: PCI interrupt 0000:00:11.5[C]: no GSI - using IRQ 9 PCI: Setting latency timer of device 0000:00:11.5 to 64 pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5 pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5 USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:11.2[D]: no GSI - using IRQ 11 dmesg excerpt for 34 kernel: PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9 ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *0, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 (level, low) -> IRQ 5 ACPI: PCI interrupt 0000:00:0e.0[A] -> GSI 5 (level, low) -> IRQ 5 ACPI: PCI interrupt 0000:00:11.1[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 ACPI: PCI interrupt 0000:00:11.2[D] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:11.3[D] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11 8139too Fast Ethernet driver 0.9.27 ACPI: PCI interrupt 0000:00:0e.0[A] -> GSI 5 (level, low) -> IRQ 5 divert: allocating divert_blk for eth0 eth0: RealTek RTL8139 at 0xa800, 00:10:dc:59:bd:dc, IRQ 5 eth0: Identified 8139 chip type 'RTL-8101' ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 (level, low) -> IRQ 5 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 0000:00:06.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xa400. Vers LK1.1.19 divert: allocating divert_blk for eth1 via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 11 (level, low) -> IRQ 11 divert: allocating divert_blk for eth2 eth2: VIA Rhine at 0xe3000000, 00:50:ba:a1:86:44, IRQ 11. eth2: MII PHY found at address 8, status 0x7809 advertising 05e1 Link 0000. ACPI: PCI interrupt 0000:00:11.5[C] -> GSI 10 (level, low) -> IRQ 10 PCI: Setting latency timer of device 0000:00:11.5 to 64 pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5 pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5 USB Universal Host Controller Interface driver v2.2 ACPI: PCI interrupt 0000:00:11.2[D] -> GSI 11 (level, low) -> IRQ 11 uhci_hcd 0000:00:11.2: UHCI Host Controller uhci_hcd 0000:00:11.2: irq 11, io base 0000b000 uhci_hcd 0000:00:11.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected ACPI: PCI interrupt 0000:00:11.3[D] -> GSI 11 (level, low) -> IRQ 11 Message: 34 Date: Fri, 1 Sep 2006 15:13:02 -0400 (EDT) From: "Marko A. Jennings" <markobiz(a)bluegargoyle.com> Subject: Re: [CentOS] latest kernel To: centos(a)centos.org Message-ID: <48730.192.168.77.10.1157137982.squirrel(a)bluegargoyle.com> Content-Type: text/plain;charset=iso-8859-1 On Fri, September 1, 2006 4:04 pm, Micha Silver wrote: > Today I updated several servers running CentOS 4.3, and got the new > 2.6.9-42 kernel. One of the machines serves as our firewall. After > rebooting I lost all forwarding thru the machine. I reverted back to the > 2.6.9-34 kernel and connectivity returned. During the few minutes that > the new kernel was running I checked that the routing table looked OK, > and with tcpdump I saw that indeed no traffic was going thru from the > externel interface to any of the internal interfaces. > > Has anyone seen similar behavior?? >

1 0

Re: [CentOS] vncserver startup issue
by Bart Schaefer 02 Sep '06

02 Sep '06

Did you edit /etc/sysconfig/vncservers ?

2 1

CentOS-announce Digest, Vol 19, Issue 1
by centos-announce-request＠centos.org 02 Sep '06

02 Sep '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. CEBA-2006:0901 Important CentOS 4 i386 up2date - bugfix update (Johnny Hughes) 2. CEBA-2006:0901-001 Important CentOS 4 x86_64 up2date - bugfix update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Fri, 01 Sep 2006 12:48:59 -0500 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2006:0901 Important CentOS 4 i386 up2date - bugfix update To: CentOS-Announce <centos-announce(a)centos.org> Message-ID: <1157132939.5268.126.camel(a)myth.home.local> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Bugfix Advisory 2006:0901-001 The up2date released with CentOS-4.4 did not specifically require the new centos-release, however the new centos-release provides the /etc/sysconfig/rhn/sources file for up2date. This update changes up2date to require centos-release >= 4-4.2 which will allow up2date to be used to upgrade of CentOS from 4.3 (or older versions) to 4.4. The following updated files have been uploaded and are currently syncing to the mirrors: i386: up2date-4.4.69-25.centos4.7.i386.rpm up2date-gnome-4.4.69-25.centos4.7.i386.rpm src: up2date-4.4.69-25.centos4.7.src.rpm

1 0

vncserver startup issue
by Alex Pilson 02 Sep '06

02 Sep '06

I installed vncserver via yum and when I reboot the server it does not want to start despite being set to start upon boot. Logging in via SSH and then issuing vncserver, I am able to get it running properly. I can't seem to figure this out. Any pointers appreciated. -- <---------------------------------------------------------------> Alex Pilson FlagShip Interactive, Inc. alex(a)flagshipinteractive.com <--------------------------------------------------------------->

1 0

Yum upgrade to 4.4 problem
by Simen Thoresen 02 Sep '06

02 Sep '06

CentOS 4.3 (SMP, x86_64, Athlon64 X2) with all pre-4.4 release updates applied. Since I ran into the Yum issue at the previous upgrade, I first did yum upgrade to get the list of packages (6 to install, 206 to update). I then did yum upgrade yum (which passed without issues) yum upgrade sqlite (which passed without isseus). Fairly certain that yum now works correctly, I wanted to just do another small upgrade before doing the rest, and did yum upgrade samba [root@naboens ~]# yum upgrade samba Setting up Upgrade Process Setting up repositories Reading repository metadata in from local files <no progress> This seemed to hang, and a look at top showed yum consuming more and more memory, the system starting to swap and bog down and then become unresponsive (all swap exhausted, I was not quick enough to kill yum). I was able to reproduce this on a different machine (also x86_64, SMP and Athlon64 X2), so it seems to be an actual problem. As I can play around a bit more on this machine, I tried doing a yum upgrade (without specifying samba) and it behaves the same (ie yum consuming increasing amounts of memory while "Reading repository metadata (etc)". Has anyone else experienced and been able to resolve this? -S -- Simen Thoresen, Dolphin ICS Systems Administration and Wulfkit Support

14 27

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