Discuss

discuss@lists.centos.org

34758 discussions

Problem with CLVM (really openais)
by Cris Rhea 04 Nov '12

04 Nov '12

I'm desparately looking for more ideas on how to debug what's going on with our CLVM cluster. Background: 4 node "cluster"-- machines are Dell blades with Dell M6220/M6348 switches. Sole purpose of Cluster Suite tools is to use CLVM against an iSCSI storage array. Machines are running CentOS 5.8 with the Xen kernels. These blades host various VMs for a project. The iSCSI back-end storage hosts the disk images for the VMs. The blades themselves run from local disk. Each blade has 3 active networks: -- Front-end, public net. -- Back-end net (backups, Database connections to external servers, cluster communication) -- iSCSI net Front and Back nets are on Xen Bridges and available/used by the VMs. iSCSI net only used by Dom0/blades. Originally got CLVM working by installing Luci/Ricci. Cluster config is dead-simple: <?xml version="1.0"?> <cluster alias="Alliance Blades" config_version="6" name="Alliance Blades"> <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/> <clusternodes> <clusternode name="calgb-blade1-mn.mayo.edu" nodeid="1" votes="1"> <fence/> </clusternode> <clusternode name="calgb-blade2-mn.mayo.edu" nodeid="3" votes="1"> <fence/> </clusternode> <clusternode name="calgb-blade3-mn.mayo.edu" nodeid="4" votes="1"> <fence/> </clusternode> <clusternode name="calgb-blade4-mn.mayo.edu" nodeid="2" votes="1"> <fence/> </clusternode> </clusternodes> <cman/> <fencedevices/> <rm> <failoverdomains/> <resources/> </rm> </cluster> All the basics are covered... LVM locking set to "Cluster", etc. This all worked fine for a period (pre 5.8)... at some point, an update took a step backwards. I can bring up the entire cluster and it will work for about 10 minutes. During that time, I'll get the following on several of the nodes: Nov 3 17:28:18 calgb-blade2 openais[7154]: [TOTEM] Retransmit List: fe Nov 3 17:28:49 calgb-blade2 last message repeated 105 times Nov 3 17:29:50 calgb-blade2 last message repeated 154 times Nov 3 17:30:51 calgb-blade2 last message repeated 154 times Nov 3 17:31:52 calgb-blade2 last message repeated 154 times Nov 3 17:32:53 calgb-blade2 last message repeated 154 times Nov 3 17:33:54 calgb-blade2 last message repeated 154 times Nov 3 17:34:55 calgb-blade2 last message repeated 154 times Nov 3 17:35:56 calgb-blade2 last message repeated 154 times Nov 3 17:36:36 calgb-blade2 last message repeated 105 times Nov 3 17:36:36 calgb-blade2 openais[7154]: [TOTEM] Retransmit List: fe ff Nov 3 17:37:07 calgb-blade2 last message repeated 104 times Nov 3 17:38:08 calgb-blade2 last message repeated 154 times Nov 3 17:39:09 calgb-blade2 last message repeated 154 times Nov 3 17:40:10 calgb-blade2 last message repeated 154 times Nov 3 17:41:11 calgb-blade2 last message repeated 154 times Nov 3 17:42:12 calgb-blade2 last message repeated 154 times Nov 3 17:43:13 calgb-blade2 last message repeated 154 times Nov 3 17:44:14 calgb-blade2 last message repeated 154 times Nov 3 17:44:24 calgb-blade2 last message repeated 26 times Around the 10 minute mark, one of the nodes (it is not always the same node) will do: Nov 3 17:44:24 calgb-blade1 openais[7179]: [TOTEM] FAILED TO RECEIVE Nov 3 17:44:24 calgb-blade1 openais[7179]: [TOTEM] entering GATHER state from 6. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Creating commit token because I am the rep. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Storing new sequence id for ring 34 Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] entering COMMIT state. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] entering RECOVERY state. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] position [0] member 192.168.226.161: Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] previous ring seq 48 rep 192.168.226.161 Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] aru fd high delivered fd received flag 1 Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Did not need to originate any messages in recovery. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] Sending initial ORF token Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] CLM CONFIGURATION CHANGE Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] New Configuration: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.161) Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Left: Nov 3 17:44:34 calgb-blade1 clurgmgrd[9933]: <emerg> #1: Quorum Dissolved Nov 3 17:44:34 calgb-blade1 kernel: dlm: closing connection to node 2 Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.162) Nov 3 17:44:34 calgb-blade1 kernel: dlm: closing connection to node 3 Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.163) Nov 3 17:44:34 calgb-blade1 kernel: dlm: closing connection to node 4 Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.164) Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Joined: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CMAN ] quorum lost, blocking activity Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] CLM CONFIGURATION CHANGE Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] New Configuration: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] r(0) ip(192.168.226.161) Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Left: Nov 3 17:44:34 calgb-blade1 openais[7179]: [CLM ] Members Joined: Nov 3 17:44:34 calgb-blade1 openais[7179]: [SYNC ] This node is within the primary component and will provide service. Nov 3 17:44:34 calgb-blade1 openais[7179]: [TOTEM] entering OPERATIONAL state. ... When this happens, the node that lost connections kills CMAN. The other 3 nodes get into this state: [root@calgb-blade2 ~]# group_tool type level name id state fence 0 default 00010001 FAIL_START_WAIT [1 2 3] dlm 1 clvmd 00010003 FAIL_ALL_STOPPED [1 2 3 4] dlm 1 rgmanager 00020003 FAIL_ALL_STOPPED [1 2 3 4] One of the nodes will be barking about trying to fence the "failed" node (expected, as I don't have real fencing). Nothing (physically) has actually failed. All 4 blades are running their VMs and accessing the shared back-end storage. No network burps, etc. CLVM is unusable and any LVM commands hang. Here's where it gets really strange..... 1. Go to the blade that has "failed" and shut down all the VMs (just to be safe-- they are all running fine). 2. Go to the node that tried to fence the failed node and run: fence_ack_manual -e -n <failed node> 3. The 3 "surviving" nodes are instantly fine. group_tool reports "none" for state and all CLVM commands work properly. 4. OK, now reboot the "failed" node. It reboots and rejoins the cluster. CLVM commands work, but are slow. Lots of these errors: openais[7154]: [TOTEM] Retransmit List: fe ff 5. This goes on for about 10 minutes and the whole cycle repeats (one of the other nodes will "fail"...) What I've tried: 1. Switches have IGMP snooping disabled. This is a simple config, so no switch-to-switch multicast is needed (all cluster/multicast traffic stays on the blade enclosure switch). I've had the cluster messages use the front-end net and the back-end net (different switch model)-- no change in behavior. 2. Running the latest RH patched openais from their Beta channel: openais-0.80.6-37.el5 (yes, I actually have RH licenses, just prefer CentOS for various reasons). 3. Tested multicast by enabling multicast/ICMP and running multicast pings. Ran with no data loss for > 10 minutes. (IBM Tech web site article-- where the end of the article say it's almost always a network problem.) 4. Tried various configuration changes such as defining two rings. No change (or got worse- the dual ring config triggers a kernel bug). I've read about every article I can find... they usually fall into two camps: 1. Multiple years old, so no idea if it's accurate with today's versions of the software. 2. People trying to do 2-node clusters and wondering why they lose quorum. My feeling is that this is an openais issue-- the ring gets out of sync and can't fix itself. This system needs to go "production" in a matter of weeks, so I'm not sure I want to dive into doing some sort of custom compiled CLVM/Corosync/Pacemaker config. Since this software has been around for years, I believe it's something simple I'm just missing. Thanks for any help/ideas... --- Cris -- Cristopher J. Rhea Mayo Clinic - Research Computing Facility 200 First St SW, Rochester, MN 55905 crhea(a)Mayo.EDU (507) 284-0587

3 2

advice on storage for media storage/streaming server
by Phil Savoie 04 Nov '12

04 Nov '12

Hello, I would like to use centos 6.3 to build a media server with 7 2TB drives and would like suggestions on the storage aspect. This is going to run mediaplex and function only as a media storage/streaming server. 1. If I didn't care about redundancy, would ext4 handle the size of a raid 0? 2. If I did go with the redundancy, what raid level should I use? 3. Should I use LVM? Why? Thank you in advance for your thoughts on this. Phil

2 1

Desktop Switcher
by Mark LaPierre 04 Nov '12

04 Nov '12

Hey Y'all, Does CentOS have a desk top switcher similar to what you find on Fedora? A friend of mine want's to be able to switch between desktops. I've only got Gnome installed on my machine so I don't switch. A search of Google turns up reference to CentOS 4 for desktop switcher but I don't see anything for CentOS 6.3.

8 14

mtrr_gran_size and mtrr_chunk_size
by Earl Ramirez 03 Nov '12

03 Nov '12

Good Day All, Today I looked at the dmesg log and I notice that the following messages regarding mtrr_gran_size/mtrr_chunk_size. I am currently running CentOS 6.3 and I installed CentOS 6.2 and 6.1 and I was seeing the same errors. When I installed CentOS 5.8 on the same laptop I do not see these errors. $ lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: CentOS Description: CentOS release 6.3 (Final) Release: 6.3 Codename: Final Below is an excerpt from dmesg BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009e800 (usable) BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) BIOS-e820: 0000000020000000 - 0000000020200000 (reserved) BIOS-e820: 0000000020200000 - 0000000040000000 (usable) BIOS-e820: 0000000040000000 - 0000000040200000 (reserved) BIOS-e820: 0000000040200000 - 00000000aac0c000 (usable) BIOS-e820: 00000000aac0c000 - 00000000aad8e000 (reserved) BIOS-e820: 00000000aad8e000 - 00000000aad94000 (usable) BIOS-e820: 00000000aad94000 - 00000000aad95000 (reserved) BIOS-e820: 00000000aad95000 - 00000000aad96000 (usable) BIOS-e820: 00000000aad96000 - 00000000aadb8000 (reserved) BIOS-e820: 00000000aadb8000 - 00000000aadc6000 (usable) BIOS-e820: 00000000aadc6000 - 00000000aade8000 (reserved) BIOS-e820: 00000000aade8000 - 00000000aae22000 (usable) BIOS-e820: 00000000aae22000 - 00000000aafe8000 (ACPI NVS) BIOS-e820: 00000000aafe8000 - 00000000aaffd000 (usable) BIOS-e820: 00000000aaffd000 - 00000000ab000000 (ACPI data) BIOS-e820: 00000000ab000000 - 00000000b0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000e4000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved) BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved) BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff980000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000ffd80000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 000000044f800000 (usable) DMI 2.6 present. SMBIOS version 2.6 @ 0xF0460 DMI: ASUSTeK Computer Inc. N55SL/N55SL, BIOS N55SL.201 11/10/2011 AMI BIOS detected: BIOS may corrupt low RAM, working around it. e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) last_pfn = 0x44f800 max_arch_pfn = 0x400000000 MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-CFFFF write-protect D0000-E7FFF uncachable E8000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000 mask C00000000 write-back 1 base 400000000 mask FC0000000 write-back 2 base 440000000 mask FF0000000 write-back 3 base 0C0000000 mask FC0000000 uncachable 4 base 0B0000000 mask FF0000000 uncachable 5 base 0AC000000 mask FFC000000 uncachable 6 base 0AB000000 mask FFF000000 uncachable 7 base 44F800000 mask FFF800000 uncachable 8 disabled 9 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 16GB, type WB reg 1, base: 16GB, range: 1GB, type WB reg 2, base: 17GB, range: 256MB, type WB reg 3, base: 3GB, range: 1GB, type UC reg 4, base: 2816MB, range: 256MB, type UC reg 5, base: 2752MB, range: 64MB, type UC reg 6, base: 2736MB, range: 16MB, type UC reg 7, base: 17656MB, range: 8MB, type UC total RAM covered: 16296M gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 64K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 128K chunk_size: 128K num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 256K num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 128K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 128K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 128K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 128K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 256K chunk_size: 256K num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 256K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 256K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 256K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 256K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 512K chunk_size: 512K num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 512K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 512K chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 512K chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 512K chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 1M chunk_size: 1M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 1M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 1M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 1M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 1M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 2M chunk_size: 2M num_reg: 10 lose cover RAM: 56M gran_size: 2M chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 2M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 2M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 2M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 2M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 2M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 4M chunk_size: 4M num_reg: 10 lose cover RAM: 56M gran_size: 4M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 4M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 4M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 4M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 4M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 4M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 8M chunk_size: 8M num_reg: 10 lose cover RAM: 56M gran_size: 8M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 8M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 8M chunk_size: 512M num_reg: 10 lose cover RAM: -256M *BAD*gran_size: 8M chunk_size: 1G num_reg: 10 lose cover RAM: -512M *BAD*gran_size: 8M chunk_size: 2G num_reg: 10 lose cover RAM: -512M gran_size: 16M chunk_size: 16M num_reg: 10 lose cover RAM: 56M gran_size: 16M chunk_size: 32M num_reg: 10 lose cover RAM: 8M gran_size: 16M chunk_size: 64M num_reg: 10 lose cover RAM: 8M gran_size: 16M chunk_size: 128M num_reg: 10 lose cover RAM: 8M gran_size: 16M chunk_size: 256M num_reg: 10 lose cover RAM: 8M *BAD*gran_size: 16M chunk_size: 512M num_reg: 10 lose cover RAM: -248M *BAD*gran_size: 16M chunk_size: 1G num_reg: 10 lose cover RAM: -504M *BAD*gran_size: 16M chunk_size: 2G num_reg: 10 lose cover RAM: -504M gran_size: 32M chunk_size: 32M num_reg: 10 lose cover RAM: 40M gran_size: 32M chunk_size: 64M num_reg: 10 lose cover RAM: 40M gran_size: 32M chunk_size: 128M num_reg: 10 lose cover RAM: 40M gran_size: 32M chunk_size: 256M num_reg: 10 lose cover RAM: 40M *BAD*gran_size: 32M chunk_size: 512M num_reg: 10 lose cover RAM: -216M *BAD*gran_size: 32M chunk_size: 1G num_reg: 10 lose cover RAM: -472M *BAD*gran_size: 32M chunk_size: 2G num_reg: 10 lose cover RAM: -472M gran_size: 64M chunk_size: 64M num_reg: 8 lose cover RAM: 104M gran_size: 64M chunk_size: 128M num_reg: 8 lose cover RAM: 104M gran_size: 64M chunk_size: 256M num_reg: 9 lose cover RAM: 104M gran_size: 64M chunk_size: 512M num_reg: 10 lose cover RAM: 104M gran_size: 64M chunk_size: 1G num_reg: 10 lose cover RAM: 104M gran_size: 64M chunk_size: 2G num_reg: 10 lose cover RAM: 104M gran_size: 128M chunk_size: 128M num_reg: 7 lose cover RAM: 168M gran_size: 128M chunk_size: 256M num_reg: 9 lose cover RAM: 168M gran_size: 128M chunk_size: 512M num_reg: 10 lose cover RAM: 168M gran_size: 128M chunk_size: 1G num_reg: 10 lose cover RAM: 168M gran_size: 128M chunk_size: 2G num_reg: 10 lose cover RAM: 168M gran_size: 256M chunk_size: 256M num_reg: 5 lose cover RAM: 424M gran_size: 256M chunk_size: 512M num_reg: 5 lose cover RAM: 424M gran_size: 256M chunk_size: 1G num_reg: 6 lose cover RAM: 424M gran_size: 256M chunk_size: 2G num_reg: 7 lose cover RAM: 424M gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 424M gran_size: 512M chunk_size: 1G num_reg: 6 lose cover RAM: 424M gran_size: 512M chunk_size: 2G num_reg: 7 lose cover RAM: 424M gran_size: 1G chunk_size: 1G num_reg: 4 lose cover RAM: 936M gran_size: 1G chunk_size: 2G num_reg: 5 lose cover RAM: 936M gran_size: 2G chunk_size: 2G num_reg: 3 lose cover RAM: 1960M mtrr_cleanup: can not find optimal value please specify mtrr_gran_size/mtrr_chunk_size e820 update range: 00000000ab000000 - 0000000100000000 (usable) ==> (reserved) last_pfn = 0xaaffd max_arch_pfn = 0x400000000 initial memory mapped : 0 - 20000000 init_memory_mapping: 0000000000000000-00000000aaffd000 0000000000 - 00aae00000 page 2M 00aae00000 - 00aaffd000 page 4k kernel direct mapping tables up to aaffd000 @ 10000-15000 init_memory_mapping: 0000000100000000-000000044f800000 0100000000 - 044f800000 page 2M kernel direct mapping tables up to 44f800000 @ 13000-26000 My Laptop currently has 16GB of RAM and 8GB of swap as indicated below $ cat /proc/meminfo MemTotal: 16235284 kB MemFree: 15024984 kB Buffers: 28128 kB Cached: 412944 kB SwapCached: 134284 kB Active: 404240 kB Inactive: 440124 kB Active(anon): 224792 kB Inactive(anon): 230964 kB Active(file): 179448 kB Inactive(file): 209160 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 8388600 kB SwapFree: 7555824 kB Dirty: 8 kB Writeback: 0 kB AnonPages: 291668 kB Mapped: 45216 kB Shmem: 52452 kB Slab: 120600 kB SReclaimable: 32100 kB SUnreclaim: 88500 kB KernelStack: 4344 kB PageTables: 35824 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 16506240 kB Committed_AS: 3714116 kB VmallocTotal: 34359738367 kB VmallocUsed: 393260 kB VmallocChunk: 34359332704 kB HardwareCorrupted: 0 kB AnonHugePages: 165888 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10228 kB DirectMap2M: 16676864 kB $ cat /proc/swaps Filename Type Size Used Priority /dev/dm-0 partition 8388600 832688 -1 The laptop is running the latest updates and kernel $ uname -r 2.6.32-279.11.1.el6.x86_64 I saw that this was a bug from Fedora 14 and CentOS as well, however it does not appear to be resolved. https://bugzilla.redhat.com/show_bug.cgi?id=584493 http://bugs.centos.org/view.php?id=5659 At random times my laptop will just lock up and I will have to power cycle it, I don't know if this is related. I had CentOS 5.8 installed for over a week and I did not experience this behaviour. Do I need file this as a new bug or is there a solution for this? -- Kind Regards Earl Ramirez

1 0

CentOS-announce Digest, Vol 93, Issue 2
by centos-announce-request＠centos.org 02 Nov '12

02 Nov '12

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2012:1423 CentOS 6 rdma Update (Johnny Hughes) 2. CEBA-2012:1419 CentOS 6 resource-agents Update (Johnny Hughes) 3. CEBA-2012:1422 CentOS 6 glibc Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 1 Nov 2012 15:00:14 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1423 CentOS 6 rdma Update To: centos-announce(a)centos.org Message-ID: <20121101150014.GA1874(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1423 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1423.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 5d1aba1ef7c1955b55817bee8c0f729ab7f678271acaad23bde36b131862e885 rdma-3.3-4.el6_3.noarch.rpm x86_64: 9202e6046a3cd10c209e9e5136fe0f6eed6488797e76e3a565c8c327b00954f0 rdma-3.3-4.el6_3.noarch.rpm Source: 4b2f2be4923c56d5a9931fc5174ca89f2d67305c26af1523d35a0393bf74174d rdma-3.3-4.el6_3.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Thu, 1 Nov 2012 15:00:28 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1419 CentOS 6 resource-agents Update To: centos-announce(a)centos.org Message-ID: <20121101150028.GA1929(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1419 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1419.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: ce3b345406447e518e872d164628349d9787efff33c49188e4db26c48ecaa4c8 resource-agents-3.9.2-12.el6_3.1.i686.rpm x86_64: a722145da540668af3770993d462f51720c3c878349f5b7a9324e63ed174ba23 resource-agents-3.9.2-12.el6_3.1.x86_64.rpm Source: 8be6f4edc4ba0718f6b54393fc173ee59630d7b4bbe01ce64dd4835f5bf8c072 resource-agents-3.9.2-12.el6_3.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Thu, 1 Nov 2012 15:00:55 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1422 CentOS 6 glibc Update To: centos-announce(a)centos.org Message-ID: <20121101150055.GA2054(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1422 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1422.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 457313a59d63eb2906589ab9e14e67996c44c0e5fcf77020e6d2c3b5625da26d glibc-2.12-1.80.el6_3.6.i686.rpm d69a18a8a0b325a16817b08d3bc50ed2623a51c4ecd482ab1055a58692dca888 glibc-common-2.12-1.80.el6_3.6.i686.rpm 1356817ed8af3bcaaf21122c00aaa2618cbb4093bb8c3fa14e2a1bee7e9a1afe glibc-devel-2.12-1.80.el6_3.6.i686.rpm 34c7a6d6dcc3e41f9877316cc3b395a66540f97bd68e742272706cb5e9def994 glibc-headers-2.12-1.80.el6_3.6.i686.rpm 7e11593a2a7a15853f4a3d57ed65c8821fc03543b6d5762dbfe1af45cdc00a35 glibc-static-2.12-1.80.el6_3.6.i686.rpm d7dd6f230e8fa3a60d35824f01c9ae384801cd682f06375ee34c33290cfad375 glibc-utils-2.12-1.80.el6_3.6.i686.rpm dc13da609d397533da365f1cc12fba37504a081309cf60d1f9cd2347876e26fc nscd-2.12-1.80.el6_3.6.i686.rpm x86_64: 457313a59d63eb2906589ab9e14e67996c44c0e5fcf77020e6d2c3b5625da26d glibc-2.12-1.80.el6_3.6.i686.rpm 68d5bd49bb92baeceb3ed8fe19300465bdc24cea00229f3269b00d4007c20748 glibc-2.12-1.80.el6_3.6.x86_64.rpm 106d25052ae0b2d264ed014a6dde2254da379702654047d164179edbcc1a20ff glibc-common-2.12-1.80.el6_3.6.x86_64.rpm 1356817ed8af3bcaaf21122c00aaa2618cbb4093bb8c3fa14e2a1bee7e9a1afe glibc-devel-2.12-1.80.el6_3.6.i686.rpm 85616b4c31190208b288798019b3920c1fa2782d60aeb46c5ae37904f5cd912d glibc-devel-2.12-1.80.el6_3.6.x86_64.rpm 63aea1c0f19fba720d20db6ee983adccff8eab0738fab3c2429d29dbfbf27e92 glibc-headers-2.12-1.80.el6_3.6.x86_64.rpm 7e11593a2a7a15853f4a3d57ed65c8821fc03543b6d5762dbfe1af45cdc00a35 glibc-static-2.12-1.80.el6_3.6.i686.rpm 44f9dc44ccfdddd391c821f3fec25685cb926c47db710a0f8ba9e9e0e3a6602b glibc-static-2.12-1.80.el6_3.6.x86_64.rpm 7b61bab183ba95c8c100f82b73744b97805e4d9d4280703b5a14e647c9c088c0 glibc-utils-2.12-1.80.el6_3.6.x86_64.rpm 882f7c5e39743082e8856acbb7d112db0c74e07697922502f2f43fbac03331eb nscd-2.12-1.80.el6_3.6.x86_64.rpm Source: a842f956739aa225dabc1a26a86397f6e23dca47a42ad44bc44584ff6b464409 glibc-2.12-1.80.el6_3.6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 93, Issue 2 **********************************************

1 0

CentOS and ActiveX
by m.roth＠5-cent.us 01 Nov '12

01 Nov '12

Only vaguely on topic, here: does anyone know how, in Firefox on CentOS (6.3), or if it's possible, to see and use ActiveX controls on a website? The calendar here at work has ActiveX controls, apparently, and I can't even see them, much less use them. mark "my manager doesn't want reminders...."

4 4

Re: [CentOS] Virtualization Options!
by Antonio da Silva Martins Junior 01 Nov '12

01 Nov '12

----- "Johnny Hughes" <johnny(a)centos.org> escreveu: > De: "Johnny Hughes" <johnny(a)centos.org> > Para: centos(a)centos.org > Enviadas: Quinta-feira, 1 de Novembro de 2012 10:55:05 (GMT-0300) Auto-Detected > Assunto: Re: [CentOS] Virtualization Options! > > On 11/01/2012 07:42 AM, Johnny Hughes wrote: > > On 11/01/2012 06:53 AM, Antonio da Silva Martins Junior wrote: > >> Hi folks, > >> > >> Thanks for your advices, I'll take a look on all and post what I conclude on it. > >> > >> Maybe I'm not clear enought, I already had CentOS5.8 Xen on my Hosts, but I'm > >> finding a solution more "enterprise". The HA/Load Balance solution we had are self > >> made, it is much time consuming for our needs. We are searching for something more > >> easy (or self) administering software. > >> > >> This is why we take a look on VMware, Citrix, etc... > >> > >> We'll take a look on OpenStack, RHEV/RHEM, maybe Oracle VM... > >> > >> Thanks, > >> > >> Antonio. > >> > > If you are looking for Cloud stacks and not just Virtualization > > Note: This is a very good resource to explain the differences between > a Cloud and Virtualization: > > http://vimeo.com/51856809 > Well, thanks... I'll take a look on this... I'm thinking a "cloud" will be a bit overkilling for our applications :D We had only a dozen hosts with aprox. 100 VMs (linux, windows) on it. But, today, almos everything is a "cloud" :D I already read the manuals of Eucaliptus and OpenStack, will take a look on OpenNebula, too... I'm thinking that we will have a "cloud" when we can use VDI to virtualize our desktop labs :D For now we are searching a way to automatize the management of our VMs, but without all of the lights, rings, and bells most of the cloud softwares had :D Our installation is prety simple: all hosts share some LUNs from the Storage (via iSCSI). We had cLVM on it. The VMs had their own LVM partition. And we had a couple o C and bash programs that do the magic. But, to deploy a new VM is almos the same as deploy a physical host. No snaphsot (cLVM didn't had it working), and no clone (it almost kills the SAN net). This is why we are searching for something else! VMware and Citrix made some demonstrations for our boss, but both needs MS-AD. Then we are searching for other options :D We already had talks with RH, thanks Jim Wildman, and well we aren't in a touristic area either :D Well... we are still searching :D Thanks, Antonio. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antonio S. Martins Jr. - Support Analyst | "Only The Shadow Knows | | Universidade Estadual de Maringá - Brasil| what evil lurks in the | | NPD - Núcleo de Processamento de Dados | Heart of Men!" | | E-Mail: asmartins(a)uem.br / shadow(a)uem.br | !!! Linux User: 52392 !!! | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Real Programmers don’t need comments — the code is obvious." -- Esta mensagem foi verificada pelo sistema de antivirus e acredita-se estar livre de perigo.

1 0

CentOS-announce Digest, Vol 93, Issue 1
by centos-announce-request＠centos.org 01 Nov '12

01 Nov '12

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. CEEA-2012:1415 CentOS 5 iptables Update (Johnny Hughes) 2. CESA-2012:1418 Critical CentOS 6 kdelibs Update (Johnny Hughes) 3. CEBA-2012:1414 CentOS 6 cpio Update (Johnny Hughes) 4. CESA-2012:1416 Critical CentOS 6 kdelibs Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Oct 2012 16:28:03 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEEA-2012:1415 CentOS 5 iptables Update To: centos-announce(a)centos.org Message-ID: <20121030162803.GA25838(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Enhancement Advisory 2012:1415 Upstream details at : https://rhn.redhat.com/errata/RHEA-2012-1415.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 8a286c64f5164b17b5a7a24683c898c1b71f5f20b77a7ceba7d56df3e652a0a2 iptables-1.3.5-9.2.el5_8.i386.rpm fe8d9da60dbd7fb33e6f2e4838ab58d51086bd6e2e950bd1409bab849de6e8c0 iptables-devel-1.3.5-9.2.el5_8.i386.rpm 086e5ebdd6fd576fda7d2cece6ec9b0decd2e512c8ce8ae824ba6c51750dc099 iptables-ipv6-1.3.5-9.2.el5_8.i386.rpm x86_64: 01e65d5f3769bee51085fb6479d3649ac90239d2eae240f6211b4dfde999dbf8 iptables-1.3.5-9.2.el5_8.x86_64.rpm fe8d9da60dbd7fb33e6f2e4838ab58d51086bd6e2e950bd1409bab849de6e8c0 iptables-devel-1.3.5-9.2.el5_8.i386.rpm 29605e1c164e837afc2441d6d1eb19bc4fc09757e5beb14c7b4958b1dae25abb iptables-devel-1.3.5-9.2.el5_8.x86_64.rpm e528dc9f548f987375989717fb55d06a7b8f5f1685ce7dd3293591a0e77a3047 iptables-ipv6-1.3.5-9.2.el5_8.x86_64.rpm Source: d2a9851af4916aca244ee5b62149bf140d1192a8c1e2f0a1c80e4de439ce9586 iptables-1.3.5-9.2.el5_8.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Tue, 30 Oct 2012 19:55:03 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2012:1418 Critical CentOS 6 kdelibs Update To: centos-announce(a)centos.org Message-ID: <20121030195503.GA4295(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2012:1418 Critical Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-1418.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: f0bcc463cb9d74facf1c009c2b85c78518656ea3abb753a30a5ad1f1cf3f4ff7 kdelibs-4.3.4-19.el6.i686.rpm 10d6ebf979951bf85977556eee1ed95be2967280ddb503930f04cb93c7fe2090 kdelibs-apidocs-4.3.4-19.el6.noarch.rpm 4e124abd1619704f54bacc0c412748e80caa7575fa131cc9a64a918f17dc409a kdelibs-common-4.3.4-19.el6.i686.rpm bbbd930179a87d61f2e428b5322105afc1089a1dbfcdf03d1392ad00432fe048 kdelibs-devel-4.3.4-19.el6.i686.rpm x86_64: f0bcc463cb9d74facf1c009c2b85c78518656ea3abb753a30a5ad1f1cf3f4ff7 kdelibs-4.3.4-19.el6.i686.rpm ff4166dbbff91f24965d6e069d1c1d3e6cb381e52476e661706858dd3c7cda0e kdelibs-4.3.4-19.el6.x86_64.rpm 4a964466bf565023103383af20ce52a1996ede295a478d46d8289b7940c60907 kdelibs-apidocs-4.3.4-19.el6.noarch.rpm 70a7a40fa59f6854ab7b001429423d1667326520474eb22e8525c1e86d8e7384 kdelibs-common-4.3.4-19.el6.x86_64.rpm bbbd930179a87d61f2e428b5322105afc1089a1dbfcdf03d1392ad00432fe048 kdelibs-devel-4.3.4-19.el6.i686.rpm f0411e459b75bdaa279e9d956fe49a75823f6b51a622ab828aed8d5399448b66 kdelibs-devel-4.3.4-19.el6.x86_64.rpm Source: 8dcdfde834684d0e729e214dc830d052d370e7d7cf497195ef380dc56616996b kdelibs-4.3.4-19.el6.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Tue, 30 Oct 2012 17:13:30 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:1414 CentOS 6 cpio Update To: centos-announce(a)centos.org Message-ID: <20121030171330.GA28945(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:1414 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-1414.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 5eaf7281527b422bf50b5859a39f4710adeb5a102a4cd5453458a3894aae8f9a cpio-2.10-11.el6_3.i686.rpm x86_64: 70a6dcb83fac5fa7dab1f38c4df5ca45a4a1049110d1e13a35eab247967add66 cpio-2.10-11.el6_3.x86_64.rpm Source: 5f127aac9866889f869f3c73a9a21bf73e12680a329cecc786b192af5a0087c0 cpio-2.10-11.el6_3.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 4 Date: Tue, 30 Oct 2012 21:17:30 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2012:1416 Critical CentOS 6 kdelibs Update To: centos-announce(a)centos.org Message-ID: <20121030211730.GA8708(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2012:1416 Critical Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-1416.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 33036271c59622de9d1e41292b439bcd431b2301062e06105b34dfee7f3d5e84 kdelibs-4.3.4-14.el6_3.2.i686.rpm b9352b421bec617bb0a3cad8625d135881d0c6d65aa3b21116eaee253352426f kdelibs-apidocs-4.3.4-14.el6_3.2.noarch.rpm 9d15714194d7863d58e66f513cf550d3e47cbc738effa02482d1e9239d541504 kdelibs-common-4.3.4-14.el6_3.2.i686.rpm 5b37bac40f3c5fc62a525db25a60a545fc673eefc064fa1be9fb77252fc2886b kdelibs-devel-4.3.4-14.el6_3.2.i686.rpm x86_64: 33036271c59622de9d1e41292b439bcd431b2301062e06105b34dfee7f3d5e84 kdelibs-4.3.4-14.el6_3.2.i686.rpm e451694e3640fd0fa9f86ec4c19532ff9bbdcf22177375cc408774b19c6b1dce kdelibs-4.3.4-14.el6_3.2.x86_64.rpm 9b4042d66d14495a87b1c59e869a09250ec53f2e31381efaf3c47bd9f3ab8e93 kdelibs-apidocs-4.3.4-14.el6_3.2.noarch.rpm 0e1206fa157f02aa6c4c4e683c93d177556173f9dd883f55ba58a4f896865be8 kdelibs-common-4.3.4-14.el6_3.2.x86_64.rpm 5b37bac40f3c5fc62a525db25a60a545fc673eefc064fa1be9fb77252fc2886b kdelibs-devel-4.3.4-14.el6_3.2.i686.rpm 80f25fcb9dc1626920daa8e48d6a2e0ab335532445953b443629bd3c47d39fba kdelibs-devel-4.3.4-14.el6_3.2.x86_64.rpm Source: 9dcfe5dc7574d7383dc7de6a0e3c730b096078a779d11765b4765e57630d9d12 kdelibs-4.3.4-14.el6_3.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 93, Issue 1 **********************************************

1 0

network and stability issues
by Karanbir Singh 01 Nov '12

01 Nov '12

hi Guys, Over the last 24 hours we have had a series of stability issues. First, the DC our mail/lists machine is hosted in had power issues ( Internap LGA9, NY, USA ); then we had a h/w failure and needed a chassis swap ( thanks to the guys in the DC who executed this within minutes ); and we have since again had network issues - although power to the DC and the server seems stable now. Over the next 24 hours, lets just try and be a bit patient and work with this. We have good backups so if things dont stabalise in the next 24 hrs we will failover. The primary reason we have not done this as yet ( failover ), is down to the fact that its taken a long time, in years, for us to build a reputation with large hosting facilities and email providers and are on many whitelists. Moving the host over makes it hard for us to get that sort of level of trust again really quickly. Longer term, we should perhaps spread the load through multiple machines and then ensure we have good relationships out of all these machines exit IP's with the various vendors and service providers. There are backup MX's in place, so if there are issues with the primary machine, we will have mail's go into holding queues and we should not lose anything inbound. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc

2 2

Virtualization Options!
by Antonio da Silva Martins Junior 01 Nov '12

01 Nov '12

Hi, I'm searching for "virtualization options". I already take a look on VMware, but it needs too much MS software to work for my needs. Citrix needs less, but the key validation is still MS-AD. Now I'm taking a look at RHEV... and run into Oracle VM! Somebody had already take a look at Oracle VM? We need in primary a solid VM solution for an "enterprise cloud" running on top of some old and new Dell servers in conjunction with an EMC Cx4-120 storage. We had plans to provide "desktop virtualization" in the future, most to labs class, and maybe adminstrative tasks. But it isn't necessary now. Anybody had some other options to tell? Thanks in advance, Antonio. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antonio S. Martins Jr. - Support Analyst | "Only The Shadow Knows | | Universidade Estadual de Maringá - Brasil| what evil lurks in the | | NPD - Núcleo de Processamento de Dados | Heart of Men!" | | E-Mail: asmartins(a)uem.br / shadow(a)uem.br | !!! Linux User: 52392 !!! | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "Real Programmers don’t need comments — the code is obvious." -- Esta mensagem foi verificada pelo sistema de antivirus e acredita-se estar livre de perigo.

6 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss