- Discuss - lists.centos.org

Disk Druid - control RAID partition layout?
by Les Mikesell 12 Jul '05

12 Jul '05

Is it possible to partition a disk with Disk Druid and control the order of the partitions? I want to create my own boot and swap as RAID partitions but Disk Druid won't keep them in the order I want, no matter what I specify first. I've done this before by using fdisk to make the partitions before starting Disk Druid but I thought someone said this was an old bug and should have been fixed. -- Les Mikesell lesmikesell(a)gmail.com

3 3

Re: [CentOS] hardware acceleration with radeon
by Rohan Walsh 12 Jul '05

12 Jul '05

Thanks Aleksandar, Option "DRI" was all I needed, doh!

1 0

Sarah: RHSA tracking tool
by Dag Wieers 11 Jul '05

11 Jul '05

Hi, I'm working on a RHSA tracking tool, named Sarah. It allows you to build a local RHSA database of different RHEL releases and then allows you to verify systems for compliance (and lists applicable RHSA and required packages). But before releasing my prototype, I would like to know what requirements people have. How they would be using such a tool and what for reports they need to extract. My main reason for writing such a tool is to automate reports to send out to customers for getting approval for updates during planned maintenance. My aim is to list the risk and information based on information provided by Red Hat. Another use case would be to send out emails either when new RHSAs are released or updates are made to existing RHSAs or sending out daily or weekly mails for systems that are lacking certain security updates. I bet other people have other requirements, so I like to hear about those. PS You may wonder what it offers on top on RHN. In fact it doesn't offer much more than RHN already provides. But in our environment, we don't have RHN access for our systems (some of them are not even connected to the Internet) and security policy does not allow this anyway. Plus a CLI tool that is able to access and process this information allows for some specialized use that RHN may not provide. Bright ideas are welcomed. Kind regards, -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]

6 8

Re: [CentOS] Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 11 Jul '05

11 Jul '05

From: Peter Farrow <peter(a)farrows.org> > looks like the 4500 came second to me by a fair margin, > between 3x and 5x faster best case, "Best case" would be something that scales linearlly over many processors with minimal (<0.1GBps) inter-CPU interconnect, which is exactly what a cluster (using GbE) is. In other cases, the old UltraSPARC II was able to keep within ~60% or so, and that's not even looking at the fact that it only had 2GB -- which _each_ dual-P4 node had as well. > not what Iwould call limping away. > Anyway that's enough of this thread, kill it now..... Here's my final statement. I have never debated that the P4 isn't more capable than old UltraSPARC II processors when something clearly relies on ALU/FPU. Heck, I _still_ deploy refurb/unused dual-P3 850MHz-1.4GHz systems because of this (especially when interconnect is not the bottleneck). But there _are_ cases where a more capable interconnect is what is needed. In those cases, even some older, cheap UltraSPARC II NUMA/UPA platforms are very useful. E.g., we're currently using a 8-way UltraSPARC II as our near-line/ off-line disk/tape backup server, and it's using multiple out-of-band and storage interconnects. Now yes, a 4-way HP DL585 would have been much nicer, and even far more interconnect. But it's clearly better than a 2-way P4 for what we're using it for. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 11 Jul '05

11 Jul '05

From: Rodrigo Barbosa <rodrigob(a)suespammers.org> > Btw, don't quote me on this one :) > I'm only 90% sure of the hotswapping capabilities, and less than 50% > sure about the price :) There _are_ systems with hot-swap CPUs, memory and/or, PCI[-X] slots. They are _not_ commodity and pricey, and require OS-level support. In fact, I believe Linux 2.6 has some support for hot-swap -- at least at the PCI[-X] level, if not memory and possibly CPU as well. It requires extensive support though for that type of "dynamic" flexibility. -- Bryan J. Smith mailto:b.j.smith@ieee.org

7 10

RE: [CentOS] Anything todo against massive connects
by Marc Powell 11 Jul '05

11 Jul '05

It sounds like your machine was the hub of a botnet. I would talk to your ISP and ask them to block all access to those IP/port pairs at the edge of their network. Chances are high that those connections will never stop as they're probably being initiated by some kind of worm. -- Marc > -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On > Behalf Of Niels Przybilla > Sent: Monday, July 11, 2005 8:53 AM > To: 'CentOS mailing list' > Subject: AW: [CentOS] Anything todo against massive connects > > Hi, > > Yes i had a compromised server where a ircd was running on these ports. > > Now many clients try to connect, but the server has been replaced and no > irc > is running and a better firewall configuration. > > Best regards > > Niels > > -----Ursprüngliche Nachricht----- > Von: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] Im > Auftrag > von Marco Garza > Gesendet: Montag, 11. Juli 2005 15:47 > An: CentOS mailing list > Betreff: Re: [CentOS] Anything todo against massive connects > > Niels Przybilla wrote: > >> Hi, > >> > >> i got a server that is massivly contacted on the ports 5190, 5150 and > >> 6667. > >> > >> Is there any possibility to stop these requests ? > >> > >> I block everything with my firewall. > >> > >> That are ten thousands of different IP's that try to connect. > >> > >> Thanks and best regards > >> > >> Niels > >> > > > > > > > >> _______________________________________________ > >> CentOS mailing list > >> CentOS(a)centos.org > >> http://lists.centos.org/mailman/listinfo/centos > >> > > > > > > > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: > > 7/11/2005 > > 5190 is for AOL / AIM > 6667 is IRC dcc > I am not sure what 5150 is for. > > Do you have servers behind this server?? > > -Marco Garza > > > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > > > > > > > ___________________________________________________________ > Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier > anmelden: http://mail.yahoo.de > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos

1 0

bad rpm openssh?
by Traxhosting Tech 11 Jul '05

11 Jul '05

Hello, I just did a cPanel upgrade from R11 > R82 (it's been a while, I know) Putty denied my root password after the - otherwise - successful update. Restarting OpenSSH in WHM results in: -- Waiting for sshd to restart.... . . . . . . . . . . finished. sshd status root 24840 0.6 0.9 38892 18596 ? S 07:28 0:00 /usr/local/cpanel/whostmgr/bin/whostmgr ./ressshd root 24858 0.1 0.0 20492 1896 ? S 07:28 0:00 /usr/sbin/sshd Jul 7 07:28:27 sunv20z sshd: sshd -TERM succeeded Jul 7 07:28:27 sunv20z sshd: succeeded sshd has failed, please contact the sysadmin. -- Any known issues - maybe a bad (new) openssh rpm for Centos 3.5 x86_64 bit - Dual Opteron? (Another person had the same problem - ref: http://forums.cpanel.net/showthread.php?p=195455#post195455) Thanks in advance. TT

2 1

Anything todo against massive connects
by Niels Przybilla 11 Jul '05

11 Jul '05

Hi, i got a server that is massivly contacted on the ports 5190, 5150 and 6667. Is there any possibility to stop these requests ? I block everything with my firewall. That are ten thousands of different IP's that try to connect. Thanks and best regards Niels

2 3

raid5 crash
by Farkas Levente 11 Jul '05

11 Jul '05

hi, after we switch our servers from centos-3 to centos-4 (aka. rhel-4) one of our server always crash once a week without any oops. this happneds with both the normal kernel-2.6.9-11.EL and kernel-2.6.9-11.106.unsupported. after we change the motherboard, the raid contorller and the cables too we still got it. finally we start netdump and last but not least yesterday we got a crash log and a core file. it seems there is a bug in the raid5 code of the kernel. this is our backup server with 8 x 200GB hdd in a raid5 (for the data) plus 2 x 40GB hdd in raid1 (for the system) with 3ware 8xxx raid contorller, running. i attached the netdump log of the last crash. how can i fix it? yours. -- Levente "Si vis pacem para bellum!" RAID5 conf printout: --- rd:8 wd:8 fd:0 disk 0, o:1, dev:sda1 disk 1, o:1, dev:sdb1 disk 2, o:1, dev:sdc1 disk 3, o:1, dev:sdd1 disk 4, o:1, dev:sde1 disk 5, o:1, dev:sdf1 disk 6, o:1, dev:sdg1 disk 7, o:1, dev:sdh1 Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: 00000000 *pde = 0f94a067 Oops: 0000 [#1] Modules linked in: cifs nls_utf8 ncpfs nfsd exportfs lockd sunrpc parport_pc lp parport netconsole netdump i2c_dev i2c_core ipx dm_mod e1000 tg3 floppy ext3 jbd raid5 xor raid1 3w_xxxx sd_mod scsi_mod CPU: 0 EIP: 0060:[<00000000>] Not tainted VLI EFLAGS: 00010246 (2.6.9-11.106.unsupported) EIP is at 0x0 eax: c1806138 ebx: c018961c ecx: 00000016 edx: c035c7f4 esi: e7182200 edi: 00000001 ebp: c18fb380 esp: f7878f34 ds: 007b es: 007b ss: 0068 Process md2_raid5 (pid: 224, threadinfo=f7878000 task=f7872600) Stack: f7b973c0 f8879a26 md_thread+0x20d/0x23a [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c030ce1a>] ret_from_fork+0x6/0x14 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02a183f>] md_thread+0x0/0x23a [<c01041d9>] kernel_thread_helper+0x5/0xb Code: Bad EIP value. Pid: 224, comm: md2_raid5 EIP: 0060:[<00000000>] CPU: 0 EIP is at 0x0 EFLAGS: 00010246 Not tainted (2.6.9-11.106.unsupported) EAX: c1806138 EBX: c018961c ECX: 00000016 EDX: c035c7f4 ESI: e7182200 EDI: 00000001 EBP: c18fb380 DS: 007b ES: 007b CR0: 8005003b CR2: ffffffd5 CR3: 0fd6b000 CR4: 000006d0 [<f8879a26>] handle_stripe+0xfca/0x1207 [raid5] [<f887a7d5>] raid5d+0x197/0x2ab [raid5] [<c02a1a4c>] md_thread+0x20d/0x23a [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c030ce1a>] ret_from_fork+0x6/0x14 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02a183f>] md_thread+0x0/0x23a [<c01041d9>] kernel_thread_helper+0x5/0xb sibling task PC pid father child younger older init S C01458E9 920 1 0 2 (NOTLB) f7f44eb0 00000086 00000055 xfrm_state_flush+0x2/0x289 tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb ntpd S 000000D0 2516 2196 1 2219 2172 (NOTLB) f0885eb0 00000082 00000246 000000d0 cf8553a0 000021cd 5197434f 00003abd f697d2a0 f697d42c f6a0d580 7fffffff 00000000 f0885f74 c030b7e5 f69a5980 00000000 f0885f58 f69a5980 f106ed18 c017648e 00000246 f106b800 f0885f58 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02aeeac>] datagram_poll+0x25/0xd1 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01058d8>] sys_sigreturn+0x1ce/0x1f2 [<c030cefb>] syscall_call+0x7/0xb rpc.rquotad S 00000000 3416 2219 1 2223 2196 (NOTLB) f65a4f1c 00000082 00000001 00000000 f697ccd0 00030ee2 966e2a43 00000033 f69b1320 f69b14ac 00000000 7fffffff f65a4fa0 f0888ba0 c030b7e5 f106b580 f65a4fa0 f106e518 c02aeeac f6a7a780 c03806c0 00000145 f0888bb0 00000001 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c02aeeac>] datagram_poll+0x25/0xd1 [<c02a8f2c>] sock_poll+0x12/0x14 [<c0176db3>] do_pollfd+0x54/0x77 [<c0176e63>] do_poll+0x8d/0xab [<c0177020>] sys_poll+0x19f/0x24f [<c0176461>] __pollwait+0x0/0x94 [<c030cefb>] syscall_call+0x7/0xb nfsd S FF4DCFB0 2316 2223 1 2224 2219 (L-TLB) f05fff10 00000046 00000002 ff4dcfb0 f69c4dd0 000013cc c85b7bd5 000037c8 f69b0d50 f69b0edc 03db8cae 03db8cae 0000000b c1993c00 c030b886 f5675f18 c035b0d0 03db8cae 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<f8ade6bb>] svc_recv+0x325/0x65b [sunrpc] [<c011b856>] default_wake_function+0x0/0xc [<c011b921>] __wake_up+0x6e/0xca [<c011b856>] default_wake_function+0x0/0xc [<c012d587>] sigprocmask+0x140/0x1f4 [<f8b2e44d>] nfsd+0x1ae/0x540 [nfsd] [<f8b2e29f>] nfsd+0x0/0x540 [nfsd] [<c01041d9>] kernel_thread_helper+0x5/0xb nfsd S 000037C3 3472 2224 1 2225 2223 (L-TLB) f1513f10 00000046 431bf158 000037c3 f78731a0 00001630 431bf158 000037c3 f6a21870 f6a219fc 03db2fe5 03db2fe5 0000000b f7f58400 c030b886 f1806f18 c035b0c0 03db2fe5 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<f8ade6bb>] svc_recv+0x325/0x65b [sunrpc] [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c012d587>] sigprocmask+0x140/0x1f4 [<f8b2e44d>] nfsd+0x1ae/0x540 [nfsd] [<f8b2e29f>] nfsd+0x0/0x540 [nfsd] kernel_thread_helper+0x5/0xb schedule_timeout+0x50/0x10c [<c02ae7c6>] skb_recv_datagram+0x15a/0x18f [<f8ade6bb>] svc_recv+0x325/0x65b [sunrpc] [<c011b856>] default_wake_function+0x0/0xc [<c01041d4>] kernel_thread_helper+0x0/0xb [<c011b856>] default_wake_function+0x0/0xc [<f894c6f7>] lockd+0x1ae/0x33f [lockd] [<f894c549>] lockd+0x0/0x33f [lockd] [<c01041d9>] kernel_thread_helper+0x5/0xb rpciod S C0129BCC 3752 2231 1 2232 2230 (L-TLB) f5665f9c 00000046 f5665000 c0129bcc f69b0780 00000a63 99004822 00000033 f69c4dd0 f69c4f5c f5665000 00000000 f5665fb8 00000000 f8ada30b 00000000 f69c4dd0 c011ceaf f5665fd0 f5665fd0 f05fff10 c030ce1a f69b0d50 00000000 free_uid+0x15/0xac [<f8ada30b>] rpciod+0x556/0x74b [sunrpc] [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c030ce1a>] ret_from_fork+0x6/0x14 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<f8ad9db5>] rpciod+0x0/0x74b [sunrpc] [<c01041d9>] kernel_thread_helper+0x5/0xb nfsd S 00000000 2136 2232 1 2236 2231 (L-TLB) f5675f10 00000046 f7f59864 00000000 f7f59864 00000886 cf330c8a 000037c8 f69c4800 f69c498c 03db8d21 03db8d21 0000000b f7f59800 c030b886 c035b0d0 f05fff18 03db8d21 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<f8ade6bb>] svc_recv+0x325/0x65b [sunrpc] [<c011b856>] default_wake_function+0x0/0xc [<f8adc82b>] svc_process+0x480/0x6cd [sunrpc] [<c011b856>] default_wake_function+0x0/0xc [<c012d587>] sigprocmask+0x140/0x1f4 [<f8b2e44d>] nfsd+0x1ae/0x540 [nfsd] [<f8b2e29f>] nfsd+0x0/0x540 [nfsd] [<c01041d9>] kernel_thread_helper+0x5/0xb rpc.mountd S C16A7000 3416 2236 1 2256 2232 (NOTLB) f567eeb0 00000086 c01458e9 c16a7000 f697ccd0 0004c4da 9d1f8094 00000033 f69c5970 f69c5afc f6a0f480 7fffffff 00000000 f567ef74 c030b7e5 00000000 00df9100 00000246 f5664580 f567ef58 f1818598 c02d1fed f5663d00 f567ef58 Call Trace: buffered_rmqueue+0x1c4/0x1e7 [<c030b7e5>] schedule_timeout+0x50/0x10c [<c02d1fed>] tcp_poll+0x31/0x144 [<c02aeeac>] datagram_poll+0x25/0xd1 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030b650>] __cond_resched+0x14/0x3b [<c030cefb>] syscall_call+0x7/0xb rpc.idmapd S 00003ABB 3288 2256 1 2316 2236 (NOTLB) f088af1c 00000086 6792e02d 00003abb cf919770 00000f18 912b8daa 00003abc f6a6d1a0 f6a6d32c 03d65077 03d65077 00000000 00001388 c030b886 f6bc7eb8 cf9a0da4 03d65077 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c018fd78>] ep_poll+0xb7/0x11e [<c011b856>] default_wake_function+0x0/0xc [<c018f041>] sys_epoll_wait+0x70/0x83 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 master S C01458E9 2288 2316 1 2325 2331 2256 (NOTLB) f65d4eb0 00000086 00000055 c01458e9 f08e80b0 000024bb 32f4d56a 00003ab7 f697ccd0 f697ce5c 03d6cd16 03d6cd16 00000000 f65d4f74 c030b886 c0439020 f04d0f54 03d6cd16 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c01458e9>] buffered_rmqueue+0x1c4/0x1e7 [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01243db>] sys_time+0xf/0x58 [<c030cefb>] syscall_call+0x7/0xb qmgr S 00003AA6 2368 2325 2316 5271 (NOTLB) f65d9eb0 00000086 aff835d3 00003aa6 f780a1b0 0000586b aff87065 00003aa6 f6a6d770 f6a6d8fc 03de71f1 03de71f1 00000000 f65d9f74 c030b886 c035b128 c035b128 03de71f1 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030b650>] __cond_resched+0x14/0x3b [<c01243db>] sys_time+0xf/0x58 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 gpm S 00000034 2764 2331 1 2340 2316 (NOTLB) f04cceb0 00000082 30984ef4 00000034 f780a1b0 00031940 309a3434 00000034 f78a60b0 f78a623c 0524d0d9 0524d0d9 00000000 f04ccf74 c030b886 c035b368 c035b368 0524d0d9 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c02aa01a>] sys_socketcall+0xde/0x1dd [<c01244b5>] sys_gettimeofday+0x53/0xac [<c030cefb>] syscall_call+0x7/0xb crond S 000000FF 2616 2340 1 5980 2349 2331 (NOTLB) f65dcf4c 00000082 00000000 000000ff cfdc0dd0 000025c3 16273dd1 00003abc f0ba3970 f0ba3afc 03d71f46 03d71f46 0000ea6b fa09bac0 c030b886 c035b040 f8b57e98 03d71f46 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c012944e>] sys_nanosleep+0x103/0x1a1 [<c030cefb>] syscall_call+0x7/0xb smbd S C035CA9C 1752 2349 1 2374 2353 2340 (NOTLB) f04caeb0 00000086 000000d0 c035ca9c c01459c0 0001f6f4 b600904c 00003133 f0ba33a0 f0ba352c f04d1b80 7fffffff 00000000 f04caf74 c030b7e5 f0bbac98 c017648e 00000246 f0b43580 f04caf58 f0bba898 c02d1fed 00000000 00000000 Call Trace: [<c01459c0>] __alloc_pages+0xb4/0x29d [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02d1fed>] tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01058d8>] sys_sigreturn+0x1ce/0x1f2 [<c030cefb>] syscall_call+0x7/0xb nmbd S 00003ABB 2320 2353 1 2370 2349 (NOTLB) f04d3eb0 00000086 78a3db2d 00003abb cffc18f0 0001365b 78ab8b56 00003abb f0ba2dd0 f0ba2f5c 03d65194 03d65194 00000000 f04d3f74 c030b886 d11d6da4 c035ade8 03d65194 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c012d587>] sigprocmask+0x140/0x1f4 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 atd S 00000000 2764 2370 1 2380 2353 (NOTLB) f04d0f4c 00000082 f04d0f34 00000000 cffc18f0 0000260f c782e9a5 00003a7f f0ba2230 f0ba23bc 03d6d34f 03d6d34f 0004940f fa09bac0 c030b886 f65d4eb8 c035b038 03d6d34f 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c012944e>] sys_nanosleep+0x103/0x1a1 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 smbd S C0107DF7 3436 2374 2349 (NOTLB) f04cffb8 00000082 00000001 c0107df7 f0ba33a0 0006ccbc 8803dfb7 00000034 f6a6c600 f6a6c78c 00d1da3c 00cfc97c 00cfc7d0 f04cf000 c012f12b c030cefb 00d1da3c 00000000 08120880 00cfc97c 00cfc7d0 bfed9178 0000001d 0000007b Call Trace: [<c0107df7>] handle_IRQ_event+0x25/0x4f [<c012f12b>] sys_pause+0x14/0x1d [<c030cefb>] syscall_call+0x7/0xb dbus-daemon-1 S 00000001 3040 2380 1 2381 2370 (NOTLB) f65eef1c 00000086 c01459c0 00000001 f0b76bd0 000020ae b10881c6 00000035 f0ba2800 f0ba298c 00000000 7fffffff f65eefa0 f39a5ca0 c030b7e5 00000246 f0b4ca80 f65eefa0 f0b64d18 c0306e62 c03822c0 00000145 f39a5cb8 00000001 Call Trace: [<c01459c0>] __alloc_pages+0xb4/0x29d [<c030b7e5>] schedule_timeout+0x50/0x10c [<c0306e62>] unix_poll+0x24/0xa3 [<c02a8f2c>] sock_poll+0x12/0x14 [<c0176db3>] do_pollfd+0x54/0x77 [<c0176e63>] do_poll+0x8d/0xab [<c0177020>] sys_poll+0x19f/0x24f [<c0176461>] __pollwait+0x0/0x94 [<c01244b5>] sys_gettimeofday+0x53/0xac [<c030cefb>] syscall_call+0x7/0xb dbus-daemon-1 S 00000000 3096 2381 1 2390 2380 (NOTLB) f04c8cac 00000086 00000000 00000000 00000000 00005927 9626398f 00000034 f0b771a0 f0b7732c 00000000 7fffffff f04c8d1c f7fe6080 c030b7e5 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c02ae622>] wait_for_packet+0xca/0x114 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02ae7e2>] skb_recv_datagram+0x176/0x18f [<c02c5ef5>] netlink_recvmsg+0x54/0x1c1 [<c02a86b6>] sock_recvmsg+0xef/0x10c [<c01458e9>] buffered_rmqueue+0x1c4/0x1e7 [<c015661b>] anon_vma_prepare+0x1f/0x1bf [<c0151a41>] do_anonymous_page+0x215/0x27f [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c0151b00>] do_no_page+0x55/0x3bf [<c02a996c>] sys_recvfrom+0xa5/0xf5 [<c015204a>] handle_mm_fault+0xd5/0x1fd [<c011924d>] do_page_fault+0x1ac/0x4dc [<c02aa0b5>] sys_socketcall+0x179/0x1dd [<c030cefb>] syscall_call+0x7/0xb hald S C035CA9C 2556 2390 1 2399 2381 (NOTLB) f65e5f1c 00000086 000000d0 c035ca9c cffc01b0 00007310 e7657e44 00003abc f0b76bd0 f0b76d5c 03d64a69 03d64a69 f65e5fa0 e71f7d00 c030b886 c035a8a8 c035a8a8 03d64a69 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c0176e63>] do_poll+0x8d/0xab [<c0177020>] sys_poll+0x19f/0x24f [<c0176461>] __pollwait+0x0/0x94 [<c01244b5>] sys_gettimeofday+0x53/0xac [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 mingetty S 00000001 3040 2399 1 2400 2390 (NOTLB) f65e6e94 00000086 0000000a 00000001 f697c130 0001550a e18fa1a8 00000034 f6a6cbd0 f6a6cd5c f04d2000 7fffffff f04d2c64 fffffffb c030b7e5 00000000 ffffffff 00000000 f65e6ed8 f65e6ef8 00000000 f65e6f3c f7c69714 f65e6f74 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c01c2327>] inode_has_perm+0x4c/0x54 [<c021f69b>] read_chan+0x319/0xa11 [<c021ff55>] write_chan+0x1c2/0x1d5 [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c02195ca>] tty_read+0x140/0x1ea [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 mingetty S 00000034 3040 2400 1 2401 2399 (NOTLB) f65e7e94 00000082 c4b810a2 00000034 f7f111a0 0003bf45 ecb0d76b 00000034 f0b77770 f0b778fc f39b6000 7fffffff f39b6c64 fffffffb c030b7e5 00000000 ffffffff 00000000 f65e7ed8 f65e7ef8 00000000 f65e7f3c f7c73d8c f65e7f74 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c01c2327>] inode_has_perm+0x4c/0x54 [<c021f69b>] read_chan+0x319/0xa11 [<c021ff55>] write_chan+0x1c2/0x1d5 [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c02195ca>] tty_read+0x140/0x1ea [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb mingetty S 00000001 3040 2401 1 2402 2400 (NOTLB) f08c0e94 00000082 0000000a 00000001 f0b76030 0004849f cb166906 00000034 f0b76600 f0b7678c f08f3000 7fffffff f08f3c64 fffffffb c030b7e5 00000000 ffffffff 00000000 f08c0ed8 f08c0ef8 00000000 f08c0f3c f7c774ec f08c0f74 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c01c2327>] inode_has_perm+0x4c/0x54 [<c021f69b>] read_chan+0x319/0xa11 [<c021ff55>] write_chan+0x1c2/0x1d5 [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c02195ca>] tty_read+0x140/0x1ea [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb mingetty S 00000001 3040 2402 1 2403 2401 (NOTLB) f08c3e94 00000086 0000000a 00000001 f69b18f0 00052d6d d66f7d73 00000034 f0b76030 f0b761bc f1550000 7fffffff f1550c64 fffffffb c030b7e5 00000000 ffffffff 00000000 f08c3ed8 f08c3ef8 00000000 f08c3f3c f7c80b64 f08c3f74 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c01c2327>] inode_has_perm+0x4c/0x54 [<c021f69b>] read_chan+0x319/0xa11 [<c021ff55>] write_chan+0x1c2/0x1d5 [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c02195ca>] tty_read+0x140/0x1ea [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb mingetty S 00000001 3040 2403 1 6851 2402 (NOTLB) f08c6e94 00000082 0000000a 00000001 f6a6cbd0 0003ccd9 e18e4c9e 00000034 f08e97f0 f08e997c f1866000 7fffffff f1866c64 fffffffb c030b7e5 00000000 ffffffff 00000000 f08c6ed8 f08c6ef8 00000000 f08c6f3c f7c832c4 f08c6f74 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c01c2327>] inode_has_perm+0x4c/0x54 [<c021f69b>] read_chan+0x319/0xa11 [<c021ff55>] write_chan+0x1c2/0x1d5 [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c02195ca>] tty_read+0x140/0x1ea [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 mingetty S 00000001 3040 6851 1 5922 2403 (NOTLB) f6999e94 00000082 0000000a 00000001 f7f11770 00027873 8e10f662 00000049 f69b18f0 f69b1a7c f695b000 7fffffff f695bc64 fffffffb c030b7e5 00000000 ffffffff 00000000 f6999ed8 f6999ef8 00000000 f6999f3c f69c6d8c f6999f74 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c01c2327>] inode_has_perm+0x4c/0x54 [<c021f69b>] read_chan+0x319/0xa11 [<c021ff55>] write_chan+0x1c2/0x1d5 [<c011b856>] default_wake_function+0x0/0xc [<c011b856>] default_wake_function+0x0/0xc [<c02195ca>] tty_read+0x140/0x1ea [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb pickup S 00000246 2824 5271 2316 7087 2325 (NOTLB) d354ceb0 00000086 c127cfc0 00000246 cfeb97f0 0000428f 32f517f9 00003ab7 f08e80b0 f08e823c 03d76956 03d76956 00000000 d354cf74 c030b886 c037d940 c035b048 03d76956 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01243db>] sys_time+0xf/0x58 [<c030cefb>] syscall_call+0x7/0xb mgetty S C01459C0 2764 5922 1 6438 6851 (NOTLB) e6214eb0 00000082 c035ca9c c01459c0 00000001 0001cb89 5cfc24c7 000038ed f697c130 f697c2bc 03eec231 03eec231 00000000 e6214f74 c030b886 c035b350 c035b350 03eec231 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c01459c0>] __alloc_pages+0xb4/0x29d [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb crond S F786F540 3024 5980 2340 5981 (NOTLB) d157aee8 00000086 d157af74 f786f540 c01c2327 00010b87 7ce582b9 00003951 f78a77f0 f78a797c f3e0e0ac d157af10 d157af04 f3e0e02c c016fc5c 00000000 f78a77f0 c011ceaf d157af1c d157af1c 0001b1a6 b7fff000 f3dc2e58 00000000 Call Trace: [<c01c2327>] inode_has_perm+0x4c/0x54 [<c016fc5c>] pipe_wait+0x70/0xa9 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c016febc>] pipe_readv+0x227/0x2a2 [<c016ff53>] pipe_read+0x1c/0x20 [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb run-parts S 00000004 2600 5981 5980 6437 (NOTLB) d11b2f28 00000082 f08e1be0 00000004 cfd1d8f0 000076ab 28d43399 00003954 f69b0780 f69b090c f69b0824 fffffe00 f69b0780 00000000 c0123c14 00030002 d11b2fc4 bfe476d4 d0ff0030 d11b2000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb awk S F08E1BE0 3192 6437 5981 (NOTLB) d0809ee8 00000086 d0809f74 f08e1be0 cff6c130 000082f3 2e8bea3b 000039ae d0ff0030 d0ff01bc f3e0e414 d0809f10 d0809f04 f3e0e394 c016fc5c 00000000 d0ff0030 c011ceaf d0809f1c d0809f1c b7fff000 d0809fc4 d0acb918 00000000 Call Trace: [<c016fc5c>] pipe_wait+0x70/0xa9 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c016febc>] pipe_readv+0x227/0x2a2 [<c016ff53>] pipe_read+0x1c/0x20 [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb atom S 00000004 2576 6438 1 6850 6440 5922 (NOTLB) d167bf28 00000086 f3e27a00 00000004 cfeb97f0 000117de 5c2feef4 00003957 d0ff0600 d0ff078c d0ff06a4 fffffe00 d0ff0600 00000000 c0123c14 00030002 d167bfc4 bfe4a6f4 cfe54600 d167b000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb backup_local- S 00000004 2764 6440 1 6808 6441 6438 (NOTLB) d085cf28 00000086 f10c8e40 00000004 cfeb97f0 0000fad2 4914056f 00003954 d08657f0 d086597c d0865894 fffffe00 d08657f0 00000000 c0123c14 00030002 d085cfc4 bff2e5d4 cfdc0dd0 d085c000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb backup_remote S 00000004 2764 6441 1 6727 6443 6440 (NOTLB) d67e7f28 00000086 f1867d40 00000004 cfeb9220 0000f6a0 3e9c21e1 00003954 d0b26dd0 d0b26f5c d0b26e74 fffffe00 d0b26dd0 00000000 c0123c14 00030002 d67e7fc4 bfe5a654 cfe55770 d67e7000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb backup_remote S 00000004 2600 6443 1 6623 6449 6441 (NOTLB) cfc1af28 00000086 f6a07520 00000004 cfeb9220 0000f0be 354885d8 00003954 d0864c50 d0864ddc d0864cf4 fffffe00 d0864c50 00000000 c0123c14 00030002 cfc1afc4 bff04774 cf9191a0 cfc1a000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb hirdet S 00000004 2576 6449 1 6821 6451 6443 (NOTLB) d03f0f28 00000082 f0bbd180 00000004 cfeb97f0 000117c7 4b2384c2 00003954 d02d0700 d02d088c d02d07a4 fffffe00 d02d0700 00000000 c0123c14 00030002 d03f0fc4 bff984a4 cfeb97f0 d03f0000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb mailmkk S 00000004 2764 6451 1 6849 6452 6449 (NOTLB) cfc58f28 00000086 f0820e60 00000004 d0b27970 00012bfd d06721be 00003956 cfd1d8f0 cfd1da7c cfd1d994 fffffe00 cfd1d8f0 00000000 c0123c14 00030002 cfc58fc4 bfe3dfd4 cf919770 cfc58000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb novell S 00003954 2576 6452 1 6830 6453 6451 (NOTLB) cfd11f28 00000082 5138e6ed 00003954 f6a6d1a0 00010790 5138e6ed 00003954 cfd1d320 cfd1d4ac cfd1d3c4 fffffe00 cfd1d320 00000000 c0123c14 00030002 cfd11fc4 bff9f7a4 cffc18f0 cfd11000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb pallasz S 00000004 2576 6453 1 6831 6454 6452 (NOTLB) cfd32f28 00000082 f18674c0 00000004 cff6c130 00010786 595d5245 00003954 cfd1cd50 cfd1cedc cfd1cdf4 fffffe00 cfd1cd50 00000000 c0123c14 00030002 cfd32fc4 bfe45824 cffc0d50 cfd32000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb tempo2 S 00000004 2576 6454 1 6829 6455 6453 (NOTLB) cfd4df28 00000086 f39a53c0 00000004 cff6c130 0001ce28 50de794b 00003954 cfd1c780 cfd1c90c cfd1c824 fffffe00 cfd1c780 00000000 c0123c14 00030002 00000000 c0265fe7 0423e7b8 cfd4d000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c0265fe7>] start_request+0x1a0/0x1c1 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 ubul S 00000004 2576 6455 1 7002 6456 6454 (NOTLB) cfd69f28 00000086 f39a54a0 00000004 cf9191a0 000187b2 a8415fc5 000039e6 cfd1c1b0 cfd1c33c cfd1c254 fffffe00 cfd1c1b0 00000000 c0123c14 00030002 cfd69fc4 bfe56314 cffc01b0 cfd69000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb zeusz S 00003954 2576 6456 1 6818 6705 6455 (NOTLB) cfd85f28 00000086 4aaa25cb 00003954 cfdc13a0 0000fca6 4aaa25cb 00003954 cfdc1970 cfdc1afc cfdc1a14 fffffe00 cfdc1970 00000000 c0123c14 00030002 cfd85fc4 bfe2fbd4 cffc1320 cfd85000 00000001 00000004 ffffffff 00000000 Call Trace: [<c0123c14>] do_wait+0x25a/0x435 [<c011b856>] default_wake_function+0x0/0xc [<c012ef43>] sys_rt_sigaction+0xdd/0xf2 [<c011b856>] default_wake_function+0x0/0xc [<c0123e82>] sys_wait4+0x27/0x2a [<c0123e98>] sys_waitpid+0x13/0x17 [<c030cefb>] syscall_call+0x7/0xb rdiff-backup R running 1920 6623 6443 6838 (NOTLB) ncpmount S 00003AB6 3112 6705 1 6770 6456 (NOTLB) cff28eb0 00000086 7798132f 00003ab6 cf854dd0 000009e6 7798132f 00003ab6 cff6d870 cff6d9fc cfded480 7fffffff 00000000 cff28f74 c030b7e5 cf9f5780 00000000 cff28f58 cf9f5780 cfa54c98 c017648e 00000246 00000246 d05aa800 schedule_timeout+0x50/0x10c schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c02ab707>] sk_wait_data+0x87/0xbb [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02d465a>] tcp_recvmsg+0x379/0x651 [<c02abe91>] sock_common_recvmsg+0x30/0x46 [<c02a86b6>] sock_recvmsg+0xef/0x10c [<c030b7e5>] schedule_timeout+0x50/0x10c [<c011adc1>] recalc_task_prio+0x128/0x133 [<c030ad9f>] schedule+0x43f/0x552 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02a86fd>] kernel_recvmsg+0x2a/0x31 [<f8b9cde5>] cifs_demultiplex_thread+0x11e/0x99c [cifs] [<f8b9ccc7>] cifs_demultiplex_thread+0x0/0x99c [cifs] [<c01041d9>] kernel_thread_helper+0x5/0xb ncpmount S 000000D0 3112 6810 1 6826 6812 (NOTLB) d3275eb0 00000082 00000246 000000d0 cffc0d50 0000097d 77981cac 00003ab6 cf854dd0 cf854f5c cfee8e80 7fffffff 00000000 d3275f74 c030b7e5 cfb1fa80 00000000 d3275f58 cfb1fa80 cf8cdd18 c017648e 00000246 00000246 d05aa080 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c0175723>] sys_fcntl64+0x6c/0x7d [<c017572d>] sys_fcntl64+0x76/0x7d [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 cifsd S 00003AAD 2340 6811 1 6812 6799 (L-TLB) d11d6d9c 00000046 8947e102 00003aad cf919770 000005f0 2e399238 00003abc cfdc13a0 cfdc152c 03d651c8 03d651c8 00000000 d11d6e14 c030b886 c035ade8 f04d3eb8 03d651c8 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c02ab707>] sk_wait_data+0x87/0xbb [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02ae889>] skb_copy_datagram_iovec+0x53/0x1e5 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02d465a>] tcp_recvmsg+0x379/0x651 [<c02abe91>] sock_common_recvmsg+0x30/0x46 [<c02a86b6>] sock_recvmsg+0xef/0x10c [<c0107df7>] handle_IRQ_event+0x25/0x4f [<f885b35e>] scsi_delete_timer+0xc/0x48 [scsi_mod] [<c011adc1>] recalc_task_prio+0x128/0x133 [<c030ad9f>] schedule+0x43f/0x552 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02a86fd>] kernel_recvmsg+0x2a/0x31 [<f8b9cde5>] cifs_demultiplex_thread+0x11e/0x99c [cifs] [<f8b9ccc7>] cifs_demultiplex_thread+0x0/0x99c [cifs] [<c01041d9>] kernel_thread_helper+0x5/0xb cifsd S 00003ABC 2604 6812 1 6810 6811 (L-TLB) d1233d9c 00000046 843db3c4 00003abc cf8553a0 00000d31 5baec11c 00003abd cff6d2a0 cff6d42c 03d66592 03d66592 00000000 d1233e14 c030b886 c035ae88 f6952eb8 03d66592 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c02ab707>] sk_wait_data+0x87/0xbb [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02ae889>] skb_copy_datagram_iovec+0x53/0x1e5 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02d465a>] tcp_recvmsg+0x379/0x651 [<c02abe91>] sock_common_recvmsg+0x30/0x46 [<c02a86b6>] sock_recvmsg+0xef/0x10c [<c011b72b>] scheduler_tick+0x37f/0x4aa [<c0129210>] do_timer+0x49/0xb5 [<c010cde3>] timer_interrupt+0x9c/0x181 [<c0107df7>] handle_IRQ_event+0x25/0x4f [<c0144396>] mempool_alloc+0x7b/0x1f9 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c02a86fd>] kernel_recvmsg+0x2a/0x31 [<f8b9cde5>] cifs_demultiplex_thread+0x11e/0x99c [cifs] [<f8b9ccc7>] cifs_demultiplex_thread+0x0/0x99c [cifs] [<c01041d9>] kernel_thread_helper+0x5/0xb rdiff-backup D CFF83D20 1700 6818 6456 (NOTLB) cff83d58 00000082 00000010 cff83d20 cf8553a0 000fca76 5bf0288f 00003abd cffc1320 cffc14ac 03d684d6 cff83000 cff83dac c18f1580 f8baa34b cf404380 00000000 00000000 f1380f80 0000d1b2 0000000f 00000000 cffc1320 c011ceaf Call Trace: autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<f88ca027>] char2uni+0xe/0x1f [nls_utf8] __cond_resched+0x14/0x3b [<f8ba6d9b>] cifs_revalidate+0x1a6/0x2d6 [cifs] [<f8ba2553>] cifs_d_revalidate+0xb/0x35 [cifs] [<c017136b>] do_lookup+0x70/0x8f [<c0171db7>] link_path_walk+0xa2d/0xd8c [<c0172391>] path_lookup+0xff/0x12f [<c01724d5>] __user_walk+0x21/0x51 [<c016ca23>] vfs_lstat+0x11/0x37 [<c016d018>] sys_lstat64+0xf/0x23 [<c01281b0>] ptrace_setsiginfo+0x1be/0x1c0 [<c010884e>] do_IRQ+0x239/0x242 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 rdiff-backup R running 1476 6821 6449 (NOTLB) ncpmount S 000000D0 3112 6826 1 6810 (NOTLB) d0eb9eb0 00000082 00000246 000000d0 cfdc0230 000008ad 85dcc468 00003a71 cfeb8c50 cfeb8ddc cf516980 7fffffff 00000000 d0eb9f74 c030b7e5 cf516d80 00000000 d0eb9f58 cf516d80 cfa1d798 c017648e 00000246 00000246 cff66800 schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c0175723>] sys_fcntl64+0x6c/0x7d [<c017572d>] sys_fcntl64+0x76/0x7d [<c030cefb>] syscall_call+0x7/0xb rdiff-backup R running 1172 6829 6454 (NOTLB) rdiff-backup D 00003ABD 1912 6830 6452 (NOTLB) cffd1eec 00000086 588b9723 00003abd f697c700 0000019a 588b9ad8 00003abd cffc18f0 cffc1a7c f7fd6e00 cffd1f18 f7fd6ea4 002130fc f889e7a8 00000000 00000000 cffc18f0 c011ceaf cffd1f24 cffd1f24 00000000 f7fd6efc 00000003 Call Trace: autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<f88985e9>] journal_stop+0x37b/0x42f [jbd] [<f88986b9>] journal_force_commit+0x1c/0x21 [jbd] direct_strncpy_from_user+0x3e/0x5d [<c01412b1>] filemap_fdatawrite+0xf/0x13 [<c0163aec>] sys_fsync+0x95/0xd6 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 rdiff-backup R running 1628 6831 6453 (NOTLB) ssh S 00003ABD 2428 6836 6727 (NOTLB) dfa9aeb0 00000082 49cc20c5 00003abd cfe55770 000003ca 49cc2d68 00003abd cf854230 cf8543bc cf2d7680 7fffffff 00000000 dfa9af74 c030b7e5 cf9ea698 c017648e 00000246 ce6cb580 dfa9af58 cf9ea698 c02d1fed 00000000 00000082 schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02d1fed>] tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 ssh S C035CA9C 2544 6838 6623 (NOTLB) e7f4eeb0 00000082 000000d0 c035ca9c cf919770 0000123e 5a529d9a 00003a82 cfdc0230 cfdc03bc cda89880 7fffffff 00000000 e7f4ef74 c030b7e5 cf9eac98 c017648e 00000246 cdf0fa80 e7f4ef58 cf9eac98 c02d1fed 000007b0 00000082 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02d1fed>] tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 rdiff-backup S F0820E60 1836 6849 6451 6867 (NOTLB) cf8eaee8 00000086 cf8eaf74 f0820e60 cffc18f0 0003b947 f0afe825 00003abc cf919770 cf9198fc cff9e5c8 cf8eaf10 cf8eaf04 cff9e548 c016fc5c 00000000 cf919770 c011ceaf cf8eaf1c cf8eaf1c 00000000 f6e06034 00000001 00000000 Call Trace: [<c016fc5c>] pipe_wait+0x70/0xa9 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c016febc>] pipe_readv+0x227/0x2a2 [<c016ff53>] pipe_read+0x1c/0x20 [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb rdiff-backup R running 2120 6850 6438 6869 (NOTLB) ssh S C035CA9C 2340 6867 6849 (NOTLB) e6f9eeb0 00000082 000000d0 c035ca9c cffc18f0 000047cb f0f80be1 00003abc cf918bd0 cf918d5c ccc19c80 7fffffff 00000000 e6f9ef74 c030b7e5 cf9ea898 c017648e 00000246 ce6cb080 e6f9ef58 cf9ea898 c02d1fed 000003d8 00000082 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02d1fed>] tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 ssh S 0000395D 2648 6869 6850 (NOTLB) c32e5eb0 00000086 2095eedb 0000395d cfe54600 000051e3 20960484 0000395d cfeb80b0 cfeb823c c59eda80 7fffffff 00000000 c32e5f74 c030b7e5 cda78318 c017648e 00000246 f0b43080 c32e5f58 cda78318 c02d1fed 00000000 00000082 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02d1fed>] tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb rdiff-backup S F39A54A0 2008 7002 6455 7003 (NOTLB) f57c8ee8 00000082 f57c8f74 f39a54a0 cf8553a0 000002dd 5a3b5875 00003abd cffc01b0 cffc033c f7cab77c f57c8f10 f57c8f04 f7cab6fc c016fc5c 00000000 cffc01b0 c011ceaf f57c8f1c f57c8f1c 00000000 00000000 f5393a18 00000000 Call Trace: [<c016fc5c>] pipe_wait+0x70/0xa9 [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c011ceaf>] autoremove_wake_function+0x0/0x2d [<c016febc>] pipe_readv+0x227/0x2a2 [<c016ff53>] pipe_read+0x1c/0x20 [<c01620b2>] vfs_read+0xb6/0xe2 [<c01622c5>] sys_read+0x3c/0x62 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 ssh S 00003ABD 2604 7003 7002 (NOTLB) c63f8eb0 00000082 5a3b2f32 00003abd cffc01b0 00000500 5a3b3bd2 00003abd cfe54030 cfe541bc cfaf5d80 7fffffff 00000000 c63f8f74 c030b7e5 e9770598 c017648e 00000246 cf886a80 c63f8f58 e9770598 c02d1fed 000003d8 00000082 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c02d1fed>] tcp_poll+0x31/0x144 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb proxymap S 00000246 2276 7087 2316 7088 5271 (NOTLB) e155feb0 00000082 c10841a0 00000246 cf9191a0 00001ef1 3982b7ea 00003aa6 cfa0c680 cfa0c80c ce771480 7fffffff 00000000 e155ff74 c030b7e5 00000001 f0524380 00000000 e155ff58 f0524380 f0528718 c017648e 00000246 cff66300 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 trivial-rewri S 00000246 2276 7088 2316 7128 7087 (NOTLB) f0e43eb0 00000082 c105f3e0 00000246 f08e8c50 00000896 3e4abd9a 00003aa6 cfa0cc50 cfa0cddc cddada80 7fffffff 00000000 f0e43f74 c030b7e5 00000001 f6946c80 00000000 f0e43f58 f6946c80 f051c118 c017648e 00000246 f0b4c300 Call Trace: [<c030b7e5>] schedule_timeout+0x50/0x10c [<c017648e>] __pollwait+0x2d/0x94 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 smtpd S 00003AA6 2196 7128 2316 7129 7088 (NOTLB) d2e70eb0 00000082 3ed0320a 00003aa6 f780a1b0 000136ff 3ed291b3 00003aa6 f08e8680 f08e880c 03d64c63 03d64c63 00000000 d2e70f74 c030b886 cb2eeeb8 f6966f54 03d64c63 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01243db>] sys_time+0xf/0x58 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 cleanup S 00000246 2276 7129 2316 7130 7128 (NOTLB) cb2eeeb0 00000082 c1376f40 00000246 cffc01b0 0000558e 3ed5b624 00003aa6 f08e8c50 f08e8ddc 03d64c64 03d64c64 00000000 cb2eef74 c030b886 f7f28f4c d2e70eb8 03d64c64 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01243db>] sys_time+0xf/0x58 [<c030cefb>] syscall_call+0x7/0xb [<c030007b>] xfrm_state_flush+0x2/0x289 local S 00003AA6 2364 7130 2316 7129 (NOTLB) eb6a9eb0 00000086 affc3a08 00003aa6 cf854230 0000532f affc3a08 00003aa6 d0b26800 d0b2698c 03d653d1 03d653d1 00000000 eb6a9f74 c030b886 c035adf8 c035adf8 03d653d1 1d244b3c 00000000 00000005 c031a0b5 c031c25c 000000a8 Call Trace: [<c030b886>] schedule_timeout+0xf1/0x10c [<c0129336>] process_timeout+0x0/0x5 [<c01768e1>] do_select+0x347/0x378 [<c0176461>] __pollwait+0x0/0x94 [<c0176c05>] sys_select+0x2e0/0x43a [<c01243db>] sys_time+0xf/0x58 [<c030cefb>] syscall_call+0x7/0xb Mem-info: DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 16, high 48, batch 8 cpu 0 cold: low 0, high 16, batch 8 Free pages: 331372kB (256kB HighMem) Active:62682 inactive:102899 dirty:25948 writeback:0 unstable:0 free:82843 slab:5921 mapped:29439 pagetables:474 DMA free:1276kB min:16kB low:32kB high:48kB active:3884kB inactive:7156kB present:16384kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 Normal free:329840kB min:936kB low:1872kB high:2808kB active:175308kB inactive:349000kB present:901120kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 HighMem free:256kB min:128kB low:256kB high:384kB active:71536kB inactive:55440kB present:131072kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 DMA: 213*4kB 47*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1276kB Normal: 0*4kB 19006*8kB 8122*16kB 1377*32kB 47*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 329840kB HighMem: 0*4kB 0*8kB 0*16kB 4*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 256kB Swap cache: add 40, delete 40, find 0/0, race 0+0 Free swap: 2108440kB 262144 pages of RAM 32768 pages of HIGHMEM 3192 reserved pages 56867 pages shared 0 pages swap cached

7 16

Problem opening CD/DVD Drive door
by Dick Roth 10 Jul '05

10 Jul '05

Since moving from FC2 to CentOS 4.x I've been having a strange problem opening the CD/DVD drive door after burning backups. A cron job tars and gzips directories I want to back up and stores the .tar.gz file in my /misc directory. I then burn the file onto a blank CD. All goes well with the burn...the drive door opens upon completion. The problem occurs when I re-insert the CD to test the backup using File Roller. After reading the directories for verification, I find that I can not eject the disc unless I log out. This, obviously is a pain in the neck since I then have to restart several apps I normally have open. Has anyone run into this before? Any suggestions? Thanks, Dick -- Pithy saying goes here: (future).

3 5

k3b for Centos 4
by Jeffrey B. Layton 10 Jul '05

10 Jul '05

Good morning, Does anyone know of a yum repository for k3b for Centos 4? (Yes, I've googled and after a few pages my head just started to spin - however, that could be normal :) ) Thanks! Jeff

2 1

hardware acceleration with radeon
by Rohan Walsh 09 Jul '05

09 Jul '05

Hi, I am using CentOS4 on i686. Can anyone tell me how to get hardware acceleration to work with a radeon 9000 using xorg and dri (not ATI's proprietary driver) I had it working fine on fc1. thanks Rohan

4 5

yum error on 3.5 repo?
by Ken Godee 09 Jul '05

09 Jul '05

Here's the error I'm getting on fresh install of 3.5 ==================================================== retrygrab() failed for: http://mirror.centos.org/centos/3/updates/i386//headers/php-imap-0-4.3.2-24… Executing failover method failover: out of servers to try Error getting file http://mirror.centos.org/centos/3/updates/i386//headers/php-imap-0-4.3.2-24… [Errno 4] IOError: HTTP Error 404: Not Found

2 2

Re: Hot swap CPU -- shared memory (1 NUMA/UPA) v. clustered (4 MCH)
by Bryan J. Smith <b.j.smith＠ieee.org> 09 Jul '05

09 Jul '05

From: Bruno Delbono <bruno.s.delbono(a)mail.ac> > I'm really sorry to start this thread again but I found something very > interesting I thought everyone should ^at least^ have a look at: > http://uadmin.blogspot.com/2005/06/4-dual-xeon-vs-e4500.html > This article takes into account a comparision of 4 dual xeon vs. e4500. > The author (not me!) talks about "A Shootout Between Sun E4500 and a > Linux Redhat3.0 AS Cluster Using Oracle10g [the cluster walks away limping]" People can play with the numbers all they want. Shared memory systems (especially NUMA) with their multi-GBps, native interconnects are typically going to be faster at anything that is GbE or FC interconnected. At the same time, lower-cost, clustered systems are competitive *IF* the application scales _linearally_. In this test scenario, the operations were geared towards operations that scale _linearally_. But even then, I think this blogger pointed out some very good data. The reality of the age of the systems in comparison, as well as the "less than commodity" cluster configuration of the PC Servers. It too is also a "power hungry" setup, and very costly. The reality is that a dual-2.8GHz Xeon MCH system does _not_ have the same interconnect capable of an even _yesteryear_ UltraSPARC II hardware that actually had a _drastically_lower_ cost overall. And even then, for its age, price, etc..., the "old" 4-way UltraSPARC II NUMA/UPA was quite "competitive" against a processor with 7x the CPU clock, but because the latter, "newer" P4 MCH platform has a _far_lower_ total aggregate throughput capable interconnect. Had the test included database benchmarks that were less linear and favored shared memory systems, then the results might have been very different. Frankly, if they wanted to make the "Linux v. Solaris" game stick, they should have taken a SunFire V40z and compared _directly_. Or at least pit a SunFire V40z running Linux against the same cluster, as the costs are very much near each other. So, in the end, I think this was a _poor_ test overall, because apples and oranges are being compared. The clustered setup has _better_ failover, the shared memory system has _better_ "raw interconnect." And it wasn't fair to use an aged Sun box, a newer, "cost equivalent" SPARC (III/IV?) should have been used -- especially given the costs. It's very likely that someone was just "re-using" the only Sun box they had, which is just a piss-poor show of journalism. The memory of the Sun should have also been boosted to the same, total amount to show off the power of a shared memory system with the appropriate benchmarks. I mean, the shared memory system has interconnect measured in the multi-GBps, while the cluster is well sub-0.1GBps for the GbE, and sub-0.5GBps for the FC-AL on even PCI-X 2.0. Furthermore, I would really like to see how the 4x P4 MCH platforms would perform versus more of a NetApp setup, beyond just the SunFire V40z (Opteron). Or, better yet, a new Opteron platform with HTX InfiniBand (Infiniband directly on the HT). That's _exactly_ what Sun is moving to, and something Intel doesn't have. Especially considering that InfiniBand on PCI-X 2.0 is only capable of maybe 0.8GBps in an "ideal" setup, and 1GbE can't get anywhere near that (let alone the layer-3/4 overhead!), while HTX InfiniBand has broken 1.8GBps! At 1.8GBps throughput InfiniBand, you're starting to blur the difference between Clustered and Shared Memory, especially with the HyperTransport protocol -- and especially versus traditional GbE. Intel can't even compete at 40% the power of Opteron HTX in a cluster configuration. **SIDE DISCUSSION: SATA and the evolution to SAS (bye SCSI!) As far as SATA v. SCSI, they were using 10K SATA disks that basically roll of the same lines as SCSI. Using the intelligent FC host fabric, the SATA's not only queue just as good as a SCSI array, the SATA throughput is _higher_ because of the reduced overhead in the protocol. There has been study after study after study that shows if [S]ATA is paired with an intelligent storage host, the host will queue and the drives will burst. The combination _roasts_ traditional SCSI -- hence why SCSI is quickly being replaced by Serial Attached Storage (SAS), a multi-target ATA-like interconnect, in new designs. Anyone who still thinks SCSI is "faster" versus [S]ATA is lost. Yes, [S]ATA doesn't have queuing, and putting NCQ (Native Command Queuing) on the Intelligent Drive Electronics (IDE) is still not the same as having an intelligent Host Adapter (HA) which SCSI always has. But when you use an intelligent Host Adapter (HA) for [S]ATA, such as the ASIC in 3Ware and other products, the game totally changes. That's when SCSI's command set actually becomes a latency liability versus ATA -- especially in an ASIC design like 3Ware's, and new Broadcom, Intel and other solutions, SCSI can _not_ compete. Hence, again, the evolution to SAS. Parallel is dead, because it's much better to have a number of point-to-point devices with direct pins to a PHY to a wide ASIC than a wide bus that is shared by all devices. And these 10K RPM SATA models are rolling of the _exact_same_ fab lines as their SCSI equivalents, with the same vibration specs and MTBF numbers. They are not "commodity" [S]ATA drives, of which many 7,200rpm SCSI drives are even now sharing (and share the same 0.4Mhr MTBF as commodity [S]ATA). -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

2.6.9-5.0.3 src rpm
by Jesse 08 Jul '05

08 Jul '05

I need to make a new driver disk, so I need to install the src.rpm for the initial centos4 install kernel, kernel-2.6.9-5.0.3.EL. However upon browsing around the mirrors, in the 4.0 directories, I find only 2.6.9-11.EL kernels and source? What's going on here -- am I looking in the wrong place? I would expect to see 2.6.9-11.EL in the 4.0/updates directories, not in the 4.0/os. I would expect 4.0/os to have the packages that correspond to the initial release. Since there are no src ISO (right?), I can't grab the kernel-2.6.9-5.0.3.EL.src.rpm from there either. Where can I find it? Thanks, --- Jesse <j(a)lumiere.net>

2 3

Re: [CentOS] 2.6.9-5.0.3 src rpm
by Bryan J. Smith <b.j.smith＠ieee.org> 08 Jul '05

08 Jul '05

From: Jesse <j(a)lumiere.net> > I need to make a new driver disk, so I need to install the src.rpm > for the initial centos4 install kernel, kernel-2.6.9-5.0.3.EL. Actually, if the driver will build against a binary kernel that is installed (which is typically the case with today's binary kernels that include the header and other config files in the run-time), all you need is the "-BOOT" kernel binary installed on your system. >From there, you should be able to build your driver against it. > However upon browsing around the mirrors, in the 4.0 directories, I find > only 2.6.9-11.EL kernels and source? What's going on here -- am I looking > in the wrong place? Hmmm, yeah, I guess I don't see a SRPMS directory anywhere. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

iPod on Centos 4
by Jesse 08 Jul '05

08 Jul '05

I'm having trouble getting my iPod working under Centos 4. I was hoping someone else using their iPod with Centos 4 could shed some light on this. When I attach my iPod via USB, I get these messages: 19:36:44 brahma kernel: usb 1-8: new high speed USB device using address 2 19:36:45 brahma kernel: Initializing USB Mass Storage driver... 19:36:45 brahma kernel: scsi2 : SCSI emulation for USB Mass Storage devices 19:37:35 brahma kernel: usb 1-8: reset high speed USB device using address 2 19:37:51 brahma kernel: scsi: Device offlined - not ready after error recovery: host 2 channel 0 id 0 lun 0 I had no problems getting my iPod to work under Centos 3 (2.4.x kernel), once I had recompiled without the EFI partition option. In this case I don't think EFI is a factor though, as the device isn't even making it to the partition scanning stage. I tried using just the slower uhci_hcd but got the same results. Then I tried using the latest FC3 kernel (2.6.11-1.35_FC3), and surprise, the iPod mounts (with ehci) without any problems. Obviously I'd prefer to run the RHEL/Centos kernel though, even if it requires a small patch. At least then I know what's changed.

2 6

ftp firewall/iptables
by Dave 08 Jul '05

08 Jul '05

I just installed CentOS4 on my main server. It runs proftpd and is not NATted.. When I did the install I said to allow FTP and HTTP. I can ftp from windows dos ftp client. In IE I get "Unable to build data connection: No route to host" ncftp I get.. Data connection timed out. Falling back to PORT instead of PASV mode. List failed. Wget and FireFox just time out. Anything I need to add to the firewall rules? This is all it has related to FTP. -A RH-Firewall-1-INPUT -p tcp -m state -m tcp --dport 21 --state NEW -j ACCEPT

5 5

Re: Evolution rpm for CentOS?
by Bryan J. Smith <b.j.smith＠ieee.org> 08 Jul '05

08 Jul '05

From: Matthew Miller <mattdm(a)mattdm.org> > My guess is that the sales rep simply explained the above policy poorly. Yeah, I honestly think that too. Sales reps have a nasty habit of doing that, not realizing what harm they actually cause a company. As Scott Adams was always fond of illustrating ... "Marketing: 2 Drink Minimum" -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Evolution rpm for CentOS?
by Adrian Coman 08 Jul '05

08 Jul '05

Hi, Is there a CentOS4 rpm for Evolution 2.2.2 (I think that's the latest) ? Thanks, Adrian

10 12

Re: [CentOS] Backup Server with rsync methods
by Bryan J. Smith <b.j.smith＠ieee.org> 08 Jul '05

08 Jul '05

From: "scott.list" <scott.list(a)mlec.net> > My real, main objective is to be able to get a config working on a > local machine for FTP, Postfix, Apache, etc. then quickly getting a > remote server up and running with those configs in a quick fashion. I > would like to have my configuration "portable" so to speak so I may > change providers on a whim if desired, and to do minimal configuration > on the remote server to quickly get it to the stage and setup of my > main, home box. Then you should maintain all configuration and other system-specific files under CVS. That way you know what may or may not need to be changed, possibly with a couple of sed commands after checkout. This is the greater detail of "configuration management" in general, and not really specific to any backup scheme. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Backup Server with rsync methods
by scott 08 Jul '05

08 Jul '05

Hi guys: I'm about to migrate a sever to a managed server facility. I've alwau=ys used tape to backup my server, now that's not an option. I've read abut using rsync to do backups and have several scripts to do same. I believe rsync is a good solution. I am missing some important nuiances though... I would like to have essentially a "mirror" server at my facility ( call it "master") that I can backup to, and from, completely from the other server (call it "hosted"). Obviously I have to have at least different IP addresses on "master" and "hosted", but other than that, I'd like them to be mirrors of each other. I would like to do all my configs, setup, etc. at my leisure on "master", where I have hands on control, then when ready, have "hosted" setup with a basic Centos server install, then configure it to rsync to my "master" and update the entire thing (updates and all) to my "master". 1. Which files tdo I need to exclude to avoid IP address and hostname changes? 2. What caveats do I need to be aware of? Are there other files such as 'live" libraries that I cannot sync to? 3. The "master" server at my facility and their server may have different hard drive architecture (i.e. IDS and SCSI drives, different processor, etc.). As long as I use a generic Kernel (i.e. stock) that supposts the hardware on both, this shoudl not be a problem, right? 4. Am I missing something, is there a better way? Thanks, Scott

5 4

CentOS-announce Digest, Vol 5, Issue 3
by centos-announce-request＠centos.org 08 Jul '05

08 Jul '05

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-2005:564 Important CentOS 3 ia64 php - security update (Pasi Pirhonen) 2. CESA-2005:564 Important CentOS 4 ia64 php - security update (Pasi Pirhonen) 3. CESA-2005:564 Important CentOS 3 i386 php - security update (Tru Huynh) 4. CESA-2005:564 Important CentOS 3 x86_64 php - security update (Tru Huynh) 5. CESA-2005:564 Important CentOS 4 i386 php - security update (Johnny Hughes) 6. CESA-2005:564 Important CentOS 4 x86_64 php - security update (Johnny Hughes) 7. CESA-2005:564 Important CentOS 3 s390(x) php - security update (Pasi Pirhonen) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Jul 2005 23:36:04 +0300 From: Pasi Pirhonen <upi(a)iki.fi> Subject: [CentOS-announce] CESA-2005:564 Important CentOS 3 ia64 php - security update To: centos-announce(a)centos.org Message-ID: <20050707203604.GA23950(a)core.upi.iki.fi> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:564 https://rhn.redhat.com/errata/RHSA-2005-564.html The following updated files have been uploaded and are currently syncing to the mirrors: files: updates/ia64/RPMS/php-4.3.2-24.ent.ia64.rpm updates/ia64/RPMS/php-devel-4.3.2-24.ent.ia64.rpm updates/ia64/RPMS/php-imap-4.3.2-24.ent.ia64.rpm updates/ia64/RPMS/php-ldap-4.3.2-24.ent.ia64.rpm updates/ia64/RPMS/php-mysql-4.3.2-24.ent.ia64.rpm updates/ia64/RPMS/php-odbc-4.3.2-24.ent.ia64.rpm updates/ia64/RPMS/php-pgsql-4.3.2-24.ent.ia64.rpm -- Pasi Pirhonen - upi(a)iki.fi - http://iki.fi/upi/

1 0

Dual booting centos 4.1 and Solaris 10 express build 15
by mohamed yusuf 08 Jul '05

08 Jul '05

I have been trying to multiboot centos 4.1 and the current solaris express build 15. I have two hard drive s, the first one ( hd0 ) devoted to CentOS 4.1 and windows xp (no problems). The second drive (hd1) for Solaris 10 only. I tried to boot solaris from CentOS grub and got the following error messages: Booting Solaris 10 root(hd1,0) Filesystem type unknown, partition type 0Xbf kernel /platform/i86pc/multiboot Error 17: can not mount selected partition press any key to continue.... I googled for error 17 and found out that "the partition exists but grub failed to recognize Solaris partition". That is odd because I had no problems triple booting windows,CentOs 4.1 and opensolaris build 16 and I don't get it, there is no partition difference between opensolaris 10 and solaris express. or is there ? Please somebody explain to me. Here is menu.lst for centos grub # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,5) # kernel /vmlinuz-version ro root=/dev/hda7 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=5 splashimage=(hd0,5)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.9-11.106.unsupported) root (hd0,5) kernel /vmlinuz-2.6.9-11.106.unsupported ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-11.106.unsupported.img title CentOS (2.6.9-11.EL) root (hd0,5) kernel /vmlinuz-2.6.9-11.EL ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.9-11.EL.img title Solaris 10 root (hd1,0) kernel /platform/i86pc/multiboot module /platform/i86pc/boot_archive makeactive chainloader +1 title Windows xp rootnoverify (hd0,0) chainloader +1 Note: This is my first post and I have learned a lot from your forum since I moved from mandrake 3 months ago. Thanks alot guys __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

ftp daemon problem
by Jeff Lasman 08 Jul '05

08 Jul '05

New install of CentOS 4.1; our first try at the 4.x. On previous 3.x installs we've used proftpd. On this one we're using (trying to use is a better statement of what we're going through) the default daemon, /usr/sbin/vsftpd. But we don't get anywhere. <snip> ftp> passiv Passive mode off. ftp> put ~/xorg.conf.work local: /home/jlasman/xorg.conf.work remote: /home/jlasman/xorg.conf.work 200 PORT command successful. Consider using PASV. 553 Could not create file. </snip> and <snip> ftp> pass Passive mode on. ftp> put ~/xorg.conf.work local: /home/jlasman/xorg.conf.work remote: /home/jlasman/xorg.conf.work 227 Entering Passive Mode (65,58,240,217,174,30) ftp: connect: Connection timed out </snip> When we turn off our firewall (which allows passive under CentOS 3 on a 2.4 kernel) we don't get the connection timeout on passive transfers, but we still get the 533. Any ideas where we should go from here? Perhaps install proftpd? I'm willing to, but I shouldn't have to. Thanks. Jeff -- Jeff Lasman, Nobaloney Internet Services 1254 So Waterman Ave., Suite 50, San Bernardino, CA 92408 Our blists address used on lists is for list email only Phone +1 909 266-9209, or see: "http://www.nobaloney.net/contactus.html"

2 3

Re: [CentOS] ftp daemon problem
by Jeff Lasman 08 Jul '05

08 Jul '05

On Thursday 07 July 2005 12:36 pm, someone wrote offlist: > how is the user logging in -- what username? and what are the > ownerships and permissions on /home/jlasman/ ? The user on my local desktop is jlasman. /home/jlasman is myself as a local user on my desktop system. Which is Mandriva 2005 LE. But I don't think that should matter. The remote server (running CentOS 4.1) user is test, set up as a standard user with adduser and passwd. But I did change the the default shell to "nologin". However nologin IS listed in /etc/shells, so my understanding is it should work. The file I tried to transfer is: -rw-rw-r-- 1 jlasman jlasman 2505 Jun 27 15:34 xorg.conf.work The permissions for /home/jlasman are: drwxr-xr-x 33 jlasman jlasman 4096 Jul 6 22:07 /home/jlasman/ Any help appreciated. (Though I know you wrote me offlist, the questions are good and helpful and I can only hope you won't mind my responding onlist in an attempt to get as much help as possible.) Thanks in advance. Jeff -- Jeff Lasman, Nobaloney Internet Services 1254 So Waterman Ave., Suite 50, San Bernardino, CA 92408 Our blists address used on lists is for list email only Phone +1 909 266-9209, or see: "http://www.nobaloney.net/contactus.html"

2 2

DHCPd Config
by Joao Medeiros 07 Jul '05

07 Jul '05

I've read a number of articles, googled the web for a few months and now attempting at turning my CentOS box into a gateway for the third time. Configured my dhcpd.conf and other related files and all seems to be working, I can have my M$ desktop leasing an ip address and all. The problem is when I want to go out to the internet I keep on getting the Request Timed out error. I'm pretty sure I've followed the manuals to the letter. The hardware is working fine. Any clues or pointers would be very much appreciated. TIA, Joao

11 19

Kickstart-based Install, editing comps.xml, hdlist/hdlist2
by dan.trainor 07 Jul '05

07 Jul '05

Hello, all - I've been throwing the question around on the kickstart-list for the last few days here, and can't quite get ahold of things. Please, allow me to explain. I am in the process of making a custom CentOS/RHEL kickstart install. It works well right now; however, it's a hackjob, and I am not comfortable with it as of yet. For the past few days, I've even gone as far as making a custom comps.xml file, for the purpose of the kickstart. What I'd like to do is not include any @groups or -/+files in my kickstart file; rather, I'd like to edit comps.xml's @Base and @Core so that I need nothing else in my kickstart file, except for the configuration options. I know that this isn't required, I'm just anal about the whole situation ;) This would also give me a chance to package, along with my install, newer and updated packages/RPMs so that I don't have to run an update process on the newly installed machine. My understanding is, if this is done, a new base/hdlist{2} file{s} is/are needed to be created. I've read around a bit, and apparently I'm supposed to use a tool named "genhdlist", but I've not been able to find any documentation on this tool, what exactly it does, and how exactly to use it. I'm expressing my frustration, along with many other people who have been in the same situation, as seen from the kickstart-list. I guess what I'm asking for, is if someone has ever made a completely custom kickstart install that does the following: 1) edits comps.xml to modify @base and @core 2) takes newer packages into consideration 3) compiles this information, creates new hdlist{2} reference files 4) gets the mother to work. This seemingly simple process seems to lack a bit of documentation. I ahve found sniplets all over the 'net where it would show a small process of how to get all this done, however, the author fails to document the utility or method in detail, or the process is for something totally archaic such as RH6.2. Any help would be greatly appreciated. Thanks! -dant

3 5

CentOS-announce Digest, Vol 5, Issue 2
by centos-announce-request＠centos.org 07 Jul '05

07 Jul '05

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-2005:569 Important CentOS 4 ia64 zlib - security update (Pasi Pirhonen) 2. CESA-2005:569 Important CentOS 4 i386 zlib - security update (Johnny Hughes) 3. CESA-2005:569 Important CentOS 4 x86_64 zlib - security update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Wed, 6 Jul 2005 17:58:06 +0300 From: Pasi Pirhonen <upi(a)iki.fi> Subject: [CentOS-announce] CESA-2005:569 Important CentOS 4 ia64 zlib - security update To: centos-announce(a)centos.org Message-ID: <20050706145806.GA23921(a)core.upi.iki.fi> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:569 https://rhn.redhat.com/errata/RHSA-2005-569.html The following updated files have been uploaded and are currently syncing to the mirrors: files: updates/ia64/RPMS/zlib-1.2.1.2-1.1.ia64.rpm updates/ia64/RPMS/zlib-devel-1.2.1.2-1.1.ia64.rpm -- Pasi Pirhonen - upi(a)iki.fi - http://iki.fi/upi/

1 0

Yum Update issues
by William Warren 07 Jul '05

07 Jul '05

I get this when i try to yum update: http://mirror.centos.org/centos/4/updates/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from update: [Errno 256] No more mirrors to try. I have done yum clean all with no joy. I have two servers with CentOS-4.1 and both are exhibiting htis issue. I have not made any changes to my yum configuration. Here is my Yum configuration. First /etc/yum.repo.d/CentOS-Base.repo [base] name=CentOS-$releasever - Base baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 #released updates [update] name=CentOS-$releasever - Updates baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 #packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/ gpgcheck=1 #additional packages that may be useful [extras] name=CentOS-$releasever - Extras baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 #additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever - Plus baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/ gpgcheck=1 enabled=0 #contrib - packages by Centos Users [contrib] name=CentOS-$releasever - Contrib baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/ gpgcheck=1 enabled=0 #packages in testing [testing] name=CentOS-$releasever - Testing baseurl=http://mirror.centos.org/centos/$releasever/testing/$basearch/ gpgcheck=1 enabled=0 Now is my yum.conf: [dag] name=Dag RPM Repository for Red Hat Enterprise Linux baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag gpgcheck=1 enabled=1 -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/

2 3

[Fwd: [Full-disclosure] [ GLSA 200507-05 ] zlib: Buffer overflow]
by William Warren 07 Jul '05

07 Jul '05

Has Centos been tested for this yet? -------- Original Message -------- Subject: [Full-disclosure] [ GLSA 200507-05 ] zlib: Buffer overflow Date: Wed, 06 Jul 2005 16:23:20 +0200 From: Thierry Carrez <koon(a)gentoo.org> Organization: Gentoo Linux To: gentoo-announce(a)lists.gentoo.org CC: full-disclosure(a)lists.grok.org.uk, bugtraq(a)securityfocus.com, security-alerts(a)linuxsecurity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200507-05 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: High Title: zlib: Buffer overflow Date: July 06, 2005 Bugs: #98121 ID: 200507-05 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== A buffer overflow has been discovered in zlib, potentially resulting in the execution of arbitrary code. Background ========== zlib is a widely used free and patent unencumbered data compression library. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 sys-libs/zlib < 1.2.2-r1 >= 1.2.2-r1 Description =========== Tavis Ormandy of the Gentoo Linux Security Audit Team discovered a buffer overflow in zlib. A bounds checking operation failed to take invalid data into account, allowing a specifically malformed deflate data stream to overrun a buffer. Impact ====== An attacker could construct a malformed data stream, embedding it within network communication or an application file format, potentially resulting in the execution of arbitrary code when decoded by the application using the zlib library. Workaround ========== There is no known workaround at this time. Resolution ========== All zlib users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=sys-libs/zlib-1.2.2-r1" References ========== [ 1 ] CAN-2005-2096 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2096 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200507-05.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security(a)gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/

2 2

NetRaid 1Si on Centos4
by Francesco F 07 Jul '05

07 Jul '05

Hi, I tried to install Centos4 on server with scsi NetRaid 1si. This card isnt't support from kernel version 2.6 (old megaraid driver, like LSI controller). What are steps to doing new install with this scsi card? And it will be stable? Thanks, Francesco

1 0

CentOS on IBM 7043-150, liblaus missing
by Richard Bejtlich 07 Jul '05

07 Jul '05

Hello, I found Pasi's site (http://centos.upi.iki.fi/pub/centos/4/os/ppc/) describing how to get CentOS working on a IBM 7043-150 43p CHRP 604e RS/6000 box. I have the exact same machine. I followed his instructions and got the version of CentOS he provided working on my system. [root@murray ~]# uname -a Linux murray 2.6.9-5.0.3.102.EC #1 Sun Mar 6 18:32:26 EET 2005 ppc ppc ppc GNU/Linux [root@murray ~]# cat /etc/redhat-release CentOS release 4.0 (Final) I thank him for posting the files and his instructions! Is anyone else running CentOS on IBM RS/6000 hardware? Does anyone know if CentOS will formally distribute a ppc version for my hardware? I've only found one problem with CentOS so far -- liblaus is missing, so I can't use passwd to change passwords. [root@murray ~]# passwd richard passwd: error while loading shared libraries: liblaus.so.1: cannot open shared object file: No such file or directory [root@murray ~]# ldd /usr/bin/passwd libuser.so.1 => /usr/lib/libuser.so.1 (0x0ffcb000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x0ff7e000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x0ff16000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x0fef2000) libdl.so.2 => /lib/libdl.so.2 (0x0fece000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x0fe1d000) libpopt.so.0 => /usr/lib/libpopt.so.0 (0x0fdf4000) libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x0fdd0000) liblaus.so.1 => not found libselinux.so.1 => /lib/libselinux.so.1 (0x0fda0000) libc.so.6 => /lib/tls/libc.so.6 (0x0fc43000) libpam.so.0 => /lib/libpam.so.0 (0x0fc1a000) /lib/ld.so.1 (0x30000000) Have you encountered this issue? Any ideas on how to fix it? Thank you again for helping me get my 7043-150 doing something useful! Sincerely, Richard PS: Has anyone tried running other Linux distros? I did not have any luck booting the latest Debian (debian-31r0a-powerpc-binary-1.iso) or NetBSD (2.0.2, prepcd.iso) on this system, but maybe I wasn't using the right OpenFirmware commands.

3 2

Netware server emulation on Linux
by Nigel kendrick 07 Jul '05

07 Jul '05

One of our group companies has just 'gone live' on a new laboratory management package. Although the software is M$-based (ie: expects a M$ server at the heart of it), it is running with its core database on a CentOS3 server using Samba for client access - in fact, the developers are amazed at the performance and say it beats a Win2K/2K3 server 'hands down'!!! Anyway, the old lab management app that I inherited has its database hosted on a Netware 3.12 server and the client app is written in Turbo Pascal including database units compiled with a specific Netware switch and if we try to run the db off the Linux server using Samba we get record lock errors. Unfortuntely, we have no confidence in re-compiling the ancient source code, expecially since the company that developed the database engine is long gone. We need access to the old data for reference and although I am going to attempt to extract it all and do some PHP stuff with it, a Google search turns up two netware emulation packages for Linux - lwared and mars_nwe - so my question is this: has anyone around these here parts used any or both of these apps with CentOS 3 or 4 and if so can I have any useful insight? I suppose the ultimate test would be to try them both but a head start would be aprpeciated. Thanks as ever, Nigel Kendrick

2 1

CentOS 4.1 Apache
by Ben 06 Jul '05

06 Jul '05

Hi folks, I've just put CentOS 4.1 on my webserver, displacing OpenBSD (1 up for Linux :-)) I found that the Virtual Hosts function doesn't appear to work. All virtual hosts accesses default to the main www directory instead of serving from their respective directories. Has anyone else found the same problem? Thanks. Ben

10 17

sendmail + plain auth
by alex＠milivojevic.org 06 Jul '05

06 Jul '05

I'm probably missing something obvious, but I can get sendmail to give me AUTH PLAIN and LOGIN options. What I have is fairly standard configuration. The relevant part of sendmail.mc looks something like this: define(`confCACERT_PATH',`/etc/ssl/certs') define(`confCACERT',`/etc/ssl/ca-bundle.crt') define(`confSERVER_CERT',`/etc/ssl/smtp.crt') define(`confSERVER_KEY',`/etc/ssl/smtp.key') define(`confAUTH_OPTIONS', `A p') TRUST_AUTH_MECH(`EXTERNAL LOGIN PLAIN') define(`confAUTH_MECHANISMS', `EXTERNAL LOGIN PLAIN') DAEMON_OPTIONS(`Port=25, Name=MTA') DAEMON_OPTIONS(`Port=465, Name=TLSMTA, M=s') So basically, LOGIN and PLAIN should be offered when SSL/TLS is in use (but not for plaintext sessions). However, when connecting over TLS, sendmail doesn't advertise them: $ openssl s_client -connect localhost:465 [ SSL/TLS handshake output deleted, AES256 cipher was used ] 220 testbox.miliv.org ESMTP Unauthorized access prohibited EHLO localhost 250-testbox.miliv.org Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DELIVERBY 250 HELP Attempt to "brute-force" use them results in error (as expected): AUTH PLAIN 504 5.3.3 AUTH mechanism PLAIN not available I'm sure I'm missing something obvious here, probably a flag or two either in confAUTH_OPTIONS or in DAEMON_OPTIONS, but couldn't dig out which. Alraedy drank all coffe, and becoming desparate ;-) ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

4 8

does anyone have mysql 4.1 rpms for centos 3
by Robin Mordasiewicz 06 Jul '05

06 Jul '05

I am in need of mysql 4.1 rpms which will not break the php_mysql module. --

2 1

Re: Compiling kernel 2.6.12.2 with gcc-3.4.3-22.1
by Bryan J. Smith <b.j.smith＠ieee.org> 06 Jul '05

06 Jul '05

From: Jose Alburquerque <jaalburquerque(a)cox.net> > Sorry, I'm not very experienced and didn't know exactly where to turn > to compile a new kernel. Well hold on. ;-> If there is one area where Fedora Core (FC) and Red Hat Enterprise Linux (RHEL) _really_ differ, it's the kernel. So you _might_ run into issues with rebuilding that on RHEL/CentOS 4, especially since Fedora Development is currently targeting FC 5 -- 2 revisions (~12 months) ahead of where RHEL/CentOS 4 is at. That's why I was wondering if there is a "Development" kernel more for RHEL/CentOS than Fedora Development. I have used the Fedora Development kernels on RHEL/CentOS in the past, but typically only on desktops or systems under test. > Thanks for the link! I'd much rather have an rpm than compiling > directly from source! Well, it's really more than just that. It's all the patches and other fixes Red Hat adds. As much as Red Hat is trying to use the vanilla kernel in Fedora Core as of kernel 2.6, there are still a number of patches, tweaks, etc... that still go in. If I need to modify anything, unpackage the RPMBUILD/SPEC environment, create a formal patch and "rpmbuild -bb kernel-2.6.spec" directly. But I typically and rarely have to do that, and it's a matter of "rpmbuild --rebuild --target=i686|x86_64 kernel-2.6*.src.rpm" directly. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Compiling kernel 2.6.12.2 with gcc-3.4.3-22.1
by Jose Alburquerque 06 Jul '05

06 Jul '05

Hi. I just have a quick question that maybe some of you might know. I'm thinking of compiling a new kernel (kernel 2.6.12.2) for my system which is running CentOS 4 (updated to 4.1 using yum). I downloaded the kernel tarball and read in the docs that for stability gcc 2.95.x (x>=3) might be best to compile the new kernel. With an "rpm -q gcc" command I see that I have gcc-3.4.3-22.1 installed on my box. Can anyone tell me if the kernel I'm trying to compile will compile fine using the version I have installed? Should I "downgrade" my gcc to 2.95 to compile this kernel? The reason I'm trying to compile an new kernel is that my system uses a LSI Logic/Symbios Logic 53c875 SCSI controller (information obtained from "System Tools/Hardware Browser" menu in GNOME) and I keep getting a bunch of errors like the following in my system logs: sym0:0:0:phase change 6-7 11@12856b84 resid=2. I read somewhere that by compiling a new kernel (2.6.11, I think), this problem might go away and I wanted my system to run as efficiently so decided to compile a new kernel. Am I doing the right thing? Thanks! Sincerely Jose

4 6

Opteron Mobo Suggestions
by Kirk Bocek 06 Jul '05

06 Jul '05

I've been planning to build a dual Opteron server for awhile. I'd like to get people's suggestions on a suitable motherboard. I've looked at the Tyan K8SE (S2892) and K8SRE (S2891) but would like to find more Linux-specific experiences with these boards. Some features I expect are at least 4 SATA (SATA-300?) ports, serial console support in the BIOS, USB 2.0 and IEEE-1394 ports, low-end on-board video. Anyone care to share their experiences? Kirk Bocek

4 5

CentOS-announce Digest, Vol 5, Issue 1
by centos-announce-request＠centos.org 06 Jul '05

06 Jul '05

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-2005:0705-001 Critical CentOS 4 x86_64 php - security update (CENTOSPLUS only) (Johnny Hughes) 2. CESA-2005:0705-001 Critical CentOS 4 i386 php - security update (CENTOSPLUS only) (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 05 Jul 2005 18:43:12 -0500 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2005:0705-001 Critical CentOS 4 x86_64 php - security update (CENTOSPLUS only) To: centos-announce(a)centos.org Message-ID: <1120606992.10579.43.camel(a)myth.home.local> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:0705-001 Critical CentOS 4 x86_64 php - security update This CESA is for the version of php is that is included in the centosplus repo for CentOS-4 ... this is not an update to the main CentOS-4 repo. -------------------------- Name : php Relocations: (not relocatable) Version : 5.0.4 Vendor: CentOS Release : 2.centos4 Build Date: 05Jul2005 04:15:18PM CDT Install Date: (not installed) Build Host: x8664-build Group : Development/Languages Source RPM : php-5.0.4-2.centos4.src.rpm Packager : Johnny Hughes <johnny(a)centos.org> URL : http://www.php.net/ Summary : The PHP HTML-embedded scripting language. ------------------------ Update Information: This update is considered critical by the CentOS Development Team, and exploitation of the vulnerability can lead to remote code execution. Anyone using php-5 from the centosplus repo is highly encouraged to upgrade their installation immediately. This update includes the PEAR XML_RPC 1.3.1 package, which fixes a security issue in the XML_RPC server implementation. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1921 to this issue. The bundled version of shtool is also updated, to fix some temporary file handling races. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-1751 to this issue. Bug fixes for the dom, ldap, and gd extensions are also included in this update. ------------------------ References: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1751 https://www.redhat.com/archives/fedora-announce-list/2005-July/msg00011.html ------------------------ The following updated files have been uploaded and are currently syncing to the mirrors: x86_64: php-5.0.4-2.centos4.x86_64.rpm php-bcmath-5.0.4-2.centos4.x86_64.rpm php-dba-5.0.4-2.centos4.x86_64.rpm php-devel-5.0.4-2.centos4.x86_64.rpm php-gd-5.0.4-2.centos4.x86_64.rpm php-imap-5.0.4-2.centos4.x86_64.rpm php-ldap-5.0.4-2.centos4.x86_64.rpm php-mbstring-5.0.4-2.centos4.x86_64.rpm php-mysql-5.0.4-2.centos4.x86_64.rpm php-ncurses-5.0.4-2.centos4.x86_64.rpm php-odbc-5.0.4-2.centos4.x86_64.rpm php-pear-5.0.4-2.centos4.x86_64.rpm php-pgsql-5.0.4-2.centos4.x86_64.rpm php-snmp-5.0.4-2.centos4.x86_64.rpm php-soap-5.0.4-2.centos4.x86_64.rpm php-xml-5.0.4-2.centos4.x86_64.rpm php-xmlrpc-5.0.4-2.centos4.x86_64.rpm src: php-5.0.4-2.centos4.src.rpm

1 0

Netfinity 5100
by Simone 05 Jul '05

05 Jul '05

Hi, it happens I could get a Netfinity 5100 IBM server and I was wondering if anyone has successfully installed CentOS4 (or even 3) on this server. Thanks, have a nice day Simone

2 1

915 Combo MS-7058 Ver1
by Michael Falzon 05 Jul '05

05 Jul '05

Hi All Just like to know if some one got or has running a "VIA 6410 IDE RAID Controller" with centos 4(.1) I have a server I need to get install, that has this on-board I have even test the with Knoppix 3.8 and it don't not pick it up at all. but the card and the drivers work ok ( tested this with the bart PE (XP) cd ) See BUG. "That's not a bug, it's a feature!" A bug can be changed to a feature by documenting it. Michael Falzon (RHCT) Mozy's Swamp BBs & Red Dwarf BBs http://mozysswamp.org Registered LFS User #406 Registered Linux User #204397 gpg --keyserver hkp://subkeys.pgp.net --recv-key 02E9ADC2 ------------------------------------------------------------------------------- UNINTENDED RECIPIENT: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then permanently delete both messages. VIRUS WARNING: Mozy's Swamp & Red Dwarf BBs does not accept liability in connection with computer viruses, data corruption, delay or denial of service as a result of virus infection.

2 2

Correlation with LNAELV ....
by William A. Mahaffey III 05 Jul '05

05 Jul '05

.... I am new to this list (got referred here from the fedora list, COLD ....) and have a few questions. I poked around CentOS.org & couldn't figure these out, so here goes: 1. What is the correspondence, if any, betwixt RHEL, err, I mean LNAELV version #'s and CentOS version #'s ? 2. Does CentOS plan to branch permanently away from LNAELV distribution, or periodically re-sync ? 3. How long have you been around, I have been looking for something like this for years now :-) ? -- William A. Mahaffey III --------------------------------------------------------------------- Remember, ignorance is bliss, but willful ignorance is LIBERALISM !!!!

3 6

root@localhost email problem
by Melinda Odom 05 Jul '05

05 Jul '05

I have another problem with the email root@localhost not working now on centos 3.5 with plesk. This has always worked in the past. Anytime I test my ecommerce store the default email address has been root@localhost and has sent an email to my domain email address when testing. Just recently this has stopped working. The ecommerce store is php. I contacted the ecommerce store developer and root@localhost works for him and he is hosting at Pair Networks. This is a reply from plesk about cgi recently on my cgi forms that were working, stopped working, and somehow started working again without anyone finding the problem: >>>>>>>>>>>>> "Actually root@localhost shouldn't work at all. The point is that qmail unlike sendmail is unable to pass messages via the system mail delivery into the /var/spool/mail/username file. It works only via SMTP. Please use an actual mail address in your cgi scripts." >>>>>>>>>>>>>> Since the ecommerce store is php and root@localhost has been working for months is there someplace I can look to try to find the problem? Thanks! Sincerely, Melinda Odom www.designhosting.biz 479-471-0891 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005

3 2

Re: Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 05 Jul '05

05 Jul '05

From: Peter Arremann <loony(a)loonybin.org> > *rofl* either you forgot how damned slow a E4500 is or you never > worked with them... There is _nothing_ fast about them (see, I > learned how to use the underscore from you, aren't you happy?)... Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow. But there are a lot of UltraSPARC II options that are still quite viable solutions. > Oh - misquote to omit my acknowledgment of the inadequacy of my > comparison. What was the reason for you leaving off where I said > "compilers aren't a good benchmark"? :-) Are you that desperate to > win an agrument that you have to misquote me to infer that I'm > saying something else? Dude, this is _not_ about "winning an argument." It's about reminding you that "build times" are _not_ a good indictator of _server_ benchmark (please note that I said _server_). I mean, if you want to see one benchmark that Intel has _always_ lost to AMD -- and handily -- build times are it. ;-> > That's why I made the comment that you so nicely cut out :-) > Performance tuning of provisioning apps is another thing I do :-) Working > for a fortune 5 and dealing with the biggest systems that company has can > be fun... Dude, stop with the resume. The problem with pulling credentials is that someone else _always_ has more. Now stop while you _think_ you are "ahead." ;-> > 4TB databases, used by Java and C++ programs, 48way 96GB > ram... that a better example or still too small for you to accept that > I might not just do little things? Once again, I will re-iterate, there are _other_ performance considerations than computational. And even then, "build" times are _not_ very representative of performance in even some computational > An Athlon64 3200+/4GB running on a 3ware controller with mirrored > disks beats an 8way E4500/4GB running a 400GB oracle database... > give the sun box 8GB and the performance is roughly equal... Depends on if you are computationally limited, and also what is your I/O -- let alone the number of sessions you are serving. In raw, unthreaded, linear aspects -- hell yes, the E4500 is a _dog_. > Yes, and one of the limitations on the E4500 is throughput... > A 3510 on a v490 does 61MB/sec - same lun, just connected into the > SUNW,socal of a E4500 IO board does about 20MB/sec... It all depends on how distributed your environment works, as well as the application. I'm not saying an old UltraSPARC II platform is always going to be faster. But man, you are like a single track that thinks there are _no_ other considerations. -- Bryan J. Smith mailto:b.j.smith@ieee.org

13 26

What do you think about this motherboard?
by Juan Carlos 05 Jul '05

05 Jul '05

Hello all..... I would like to know if anyone here has had good experience with this Supermicro motherboard.....http://supermicro.com/products/motherboard/P4/E7221/P8SCT.c… I am thinking about using it in an entry level mail and file server with a 3ware card and 200 GB SATA drives. Cost is a factor here otherwise I would go for an Opteron board instead. JC

5 12

RedHat to CentOS transition
by Matt Jaffe 05 Jul '05

05 Jul '05

I installed RHEL ES 4.0 on a new server because I had the disks. The problem is that the new server does not have a RedHat network subscription and can't use Up2date to keep itself current. We set up a script that just runs apt once a week, but I am curious whether there is some way of changing the box into a CentOS machine and using your Up2Date to get updates from one of the mirrors. I read on the White Box site that they use a Fedora Yum package and a modified version of Up2Date to accomplish the same thing as RedHat's tool. I assume CentOS is the same way. Can I just install those packages and modify the /etc/redhat-release or is there more to it?

2 1

NFS sleepy woes
by Res 03 Jul '05

03 Jul '05

Hi all, I have a problem with a CentOS 4 and now updated to 4.1 server, every so often the other servers try to contact it and this not there a retry and it is, like it goes to sleep, I have no problem with the fedora1, RH9 and slackware machines they just never do this. its most annoying.. they all use IP's not names. all access lists are identical, all hosts files are identical, all exports and fstabs are same format. in fact one of the machines on another network altogether reponds instantly. if I reboot *shudder* the CentOS box it fixes it, temporarily, but thats a joke, the hardware is fine, it used to run slackware smoothly, I hope I dont have to go back to it :) TIA

4 6

RE: CentOS Digest, Vol 6, Issue 3
by Melinda Odom 03 Jul '05

03 Jul '05

Hi, I checked the sendmail and it is: [root@godslove root]# which sendmail /usr/sbin/sendmail Plesk uses sendmail and this is what is listed in my form that was working. I tried my form at 7:27 am this morning and this is the last listing in /var/log/messages Jul 3 07:05:42 godslove authpsa: IMAP connect from @ [67.138.221.157] There are no listings in /var/log/maillog. These are the settings in FormMail.pl: $DEBUGGING = 1; $emulate_matts_code= 0; $secure = 1; $allow_empty_ref = 1; $max_recipients = 1; $mailprog = '/usr/sbin/sendmail -oi -t'; $postmaster = ''; @referers = qw(designhosting.biz); @allow_mail_to = qw(mail.designhosting.biz designhosting.biz); @recipients = (); %recipient_alias = (); @valid_ENV = qw(REMOTE_HOST REMOTE_ADDR REMOTE_USER HTTP_USER_AGENT); $locale = ''; $charset = 'iso-8859-1'; $date_fmt = '%A, %B %d, %Y at %H:%M:%S'; $style = '/css/nms.css'; $no_content = 0; $double_spacing = 1; $wrap_text = 0; $wrap_style = 1; $address_style = 0; $send_confirmation_mail = 0; Sincerely, Melinda Odom www.designhosting.biz 479-471-0891 -----Original Message----- From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org]On Behalf Of centos-request(a)centos.org Sent: Sunday, July 03, 2005 7:00 AM To: centos(a)centos.org Subject: CentOS Digest, Vol 6, Issue 3 Send CentOS mailing list submissions to centos(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos or, via email, send a message with subject or body 'help' to centos-request(a)centos.org You can reach the person managing the list at centos-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS digest..." Today's Topics: 1. form problem (Melinda Odom) 2. Re: form problem (Johnny Hughes) 3. Re: form problem (Egypt.com) 4. Re: boot failure after install (Feizhou) 5. Re: Re: boot failure after install -- my bootloader beat up your honor student (Feizhou) 6. Re: Re: Hot swap CPU (Lamar Owen) 7. Re: Re: Hot swap CPU (Lamar Owen) 8. Re: Re: Hot swap CPU (Bruno Delbono) 9. Re: Re: Hot swap CPU (Peter Arremann) 10. Re: Re: Hot swap CPU (Bryan J. Smith) 11. Re: Re: Hot swap CPU (Lamar Owen) 12. Re: Hot swap CPU (Bryan J. Smith) 13. Loosing mouse pointer on centos 4.1 (Jerry Geis) 14. Non-CentOS related arguments off-list please (Dag Wieers) 15. OT: about openswan (User Lists) 16. Re: NFS sleepy woes (Res) 17. Syslog & charset issues (Jamie Pratt) 18. Re: Re: Directory Server for CentOS 4.1 (Aleksandar Milivojevic) 19. Re: NFS sleepy woes (Les Mikesell) 20. Re: NFS sleepy woes (Res) 21. Re: NFS sleepy woes (Johnny Hughes) 22. Re: Re: Hot swap CPU (Johnny Hughes) 23. Re: Re: Hot swap CPU (Chris Mauritz) ---------------------------------------------------------------------- Message: 1 Date: Sat, 2 Jul 2005 07:47:03 -0500 From: "Melinda Odom" <info(a)designhosting.biz> Subject: [CentOS] form problem To: <centos(a)centos.org> Message-ID: <OHEMIKFDMHLDNJAPNOLECEMOFMAA.info(a)designhosting.biz> Content-Type: text/plain; charset="windows-1250" Hi, I am using CentOS 3.5 plus the Plesk reloaded 7.3 server admin and just recently did a small upgrade of some plesk packages plus the update from CentOS 3.4 to 3.5. It seems that all of my forms have stopped working using nms FormMail.pl script. Everything was working before these last two updates. I have debug set on the form script and it does work without any errors but I never get the email that a form was submitted. The server company I get my server through did a test on one of the forms and I got the technician's email but when I went to test the very same form I did not get an email. The technician tested from the company so I am thinking this might be some permissions problem with something on my server as the technician would have higher permissions than myself. Another strange occurrence is that whenever a customer of one of my customers on my server submits my client's email form I am getting an email instead of my client showing the details of the form. I have checked all the forms thoroughly and there is nothing wrong with them and since they all were working and now are not working that the problem is with the server itself. Can someone give me some ideas of where to look for this problem because we are stumped? Sincerely, Melinda Odom www.designhosting.biz 479-471-0891 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.8/37 - Release Date: 7/1/2005 ------------------------------ Message: 2 Date: Sat, 02 Jul 2005 08:29:19 -0500 From: Johnny Hughes <mailing-lists(a)hughesjr.com> Subject: Re: [CentOS] form problem To: CentOS ML <centos(a)centos.org> Message-ID: <1120310959.14145.181.camel(a)myth.home.local> Content-Type: text/plain; charset="us-ascii" On Sat, 2005-07-02 at 07:47 -0500, Melinda Odom wrote: > Hi, > > I am using CentOS 3.5 plus the Plesk reloaded 7.3 server admin and just > recently did a small upgrade of some plesk packages plus the update from > CentOS 3.4 to 3.5. > > It seems that all of my forms have stopped working using nms FormMail.pl > script. Everything was working before these last two updates. I have debug > set on the form script and it does work without any errors but I never get > the email that a form was submitted. > > The server company I get my server through did a test on one of the forms > and I got the technician's email but when I went to test the very same form > I did not get an email. The technician tested from the company so I am > thinking this might be some permissions problem with something on my server > as the technician would have higher permissions than myself. > > Another strange occurrence is that whenever a customer of one of my > customers on my server submits my client's email form I am getting an email > instead of my client showing the details of the form. > > I have checked all the forms thoroughly and there is nothing wrong with them > and since they all were working and now are not working that the problem is > with the server itself. > > Can someone give me some ideas of where to look for this problem because we > are stumped? I don't use plesk, but since the form worked for the technician, I would suspect a problem with either name lookups, what IP your mail server is listening on, or your MTA setup. The first thing you need to do is look at /var/log/maillog and see if the messages are making it through the local server and getting to an external server. Any errors, reasons for non delivery, etc. should be in /var/log/maillog or /var/log/messages. I don't even know which MTA plesk uses (sendmail, postfix, etc.) ... but that is where I would start.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss