Discuss January 2012

discuss@lists.centos.org

222 participants
221 discussions

SELinux and rsh+xauth
by Philippe Naudin 16 Jan '12

16 Jan '12

Hello, I have a strange (for me) problem with these two machines : - Client, a CentOS-5.7 workstation ; - Server, a CentOS-6.2 headless, up-to-date server. From Client, I want to use xauth on Server with the help of rsh (yes, I know, ssh and all this sort of things... another time.) When SELinux is in permissive mode on Server, all these commands perform as expected : rsh Server /usr/bin/xauth info rsh Server /usr/bin/xauth list xauth nextract - Client:0.0 | rsh Server /usr/bin/xauth nmerge - But when SELinux is in enforcing mode on Server, the commands fail with this message : bash: /usr/bin/xauth: Permission denied and /var/log/audit/audit.log shows the following errors : type=SELINUX_ERR msg=audit(1326381080.364:610): security_compute_sid: invalid context system_u:system_r:xauth_t:s0-s0:c0.c1023 for scontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xauth_exec_t:s0 tclass=process type=AVC msg=audit(1326381080.364:610): avc: denied { write } for pid=3487 comm="xauth" path="pipe:[21744]" dev=pipefs ino=21744 scontext=system_u:system_r:xauth_t:s0-s0:c0.c1023 tcontext=system_u:system_r:rshd_t:s0-s0:c0.c1023 tclass=fifo_file type=AVC msg=audit(1326381080.369:611): avc: denied { getattr } for pid=3487 comm="xauth" path="socket:[21700]" dev=sockfs ino=21700 scontext=system_u:system_r:xauth_t:s0-s0:c0.c1023 tcontext=system_u:system_r:inetd_t:s0-s0:c0.c1023 tclass=tcp_socket The output from audit2allow is here : $ grep AVC /var/log/audit/audit.log | audit2allow libsepol.context_from_record: invalid security context: "system_u:system_r:xauth_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:system_r:xauth_t:s0-s0:c0.c1023 to sid (these 4 lines are repeated 2 times) On Server, after creating a new authority file (with rsh again, while Server is in permissive mode), I find : $ ls -Z .Xauthority -rw-------. naudin biom system_u:object_r:xauth_home_t:s0 .Xauthority I don't have this problem on a CentOS-5.7 server with the same configuration. Any idea (other than ssh) on how to solve it ? Thanks, -- Philippe Naudin

2 1

URL pour les logiciels du campus
by Philippe Naudin 16 Jan '12

16 Jan '12

https://www1.montpellier.inra.fr/intranet/intracampus/logiciels/consult/

1 0

with Centos6 i cant Partition on 3TB Disks, problem
by Marko Weber 16 Jan '12

16 Jan '12

Hello List, i try to install Centos 6 on a Server with 2x 3TB Disks. When anaconda is showing up the disk partitioner i cant do more then 3 "normal Partitions" or more then 3 "Raid Partitions". Even when u choose that each partition is 200mb, u cant do more then 3 "normal" or "raid" partitions. is this a bug of anaconda installer? thanks marko

3 2

[CENTOS6] mtrr_cleanup: can not find optimal value - during server startup
by no.spa＠o2.pl 15 Jan '12

15 Jan '12

After fresh installation of CentOS 6.2 on my server, I get following errors in my dmesg output: ------- MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-D7FFF write-protect D8000-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 0CB800000 mask FFF800000 uncachable 3 base 0CC000000 mask FFC000000 uncachable 4 base 0D0000000 mask FF0000000 uncachable 5 base 0E0000000 mask FE0000000 uncachable 6 base 42FE00000 mask FFFE00000 uncachable 7 base 430000000 mask FF0000000 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: 3256MB, range: 8MB, type UC reg 3, base: 3264MB, range: 64MB, type UC reg 4, base: 3328MB, range: 256MB, type UC reg 5, base: 3584MB, range: 512MB, type UC reg 6, base: 17150MB, range: 2MB, type UC reg 7, base: 17152MB, range: 256MB, type UC total RAM covered: 16310M gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 64K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 64K chunk_size: 8M num_reg: 10 lose cover RAM: -2M 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 gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 128K chunk_size: 128K num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 128K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 128K chunk_size: 8M num_reg: 10 lose cover RAM: -2M 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 gran_size: 128K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 128K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 256K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 256K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 256K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 256K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 256K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 256K chunk_size: 8M num_reg: 10 lose cover RAM: -2M 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 gran_size: 256K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 256K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 512K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 512K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 512K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 512K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 512K chunk_size: 8M num_reg: 10 lose cover RAM: -2M 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 gran_size: 512K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 512K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 1M chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 1M chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 1M chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 1M chunk_size: 8M num_reg: 10 lose cover RAM: -2M 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 gran_size: 1M chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 1M chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 2M chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 2M chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 2M chunk_size: 8M num_reg: 10 lose cover RAM: -2M 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 gran_size: 2M chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 2M chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 4M chunk_size: 4M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 4M chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 4M chunk_size: 16M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 32M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 64M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 128M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 256M num_reg: 10 lose cover RAM: 2M *BAD*gran_size: 4M chunk_size: 512M num_reg: 10 lose cover RAM: -254M gran_size: 4M chunk_size: 1G num_reg: 10 lose cover RAM: 2M *BAD*gran_size: 4M chunk_size: 2G num_reg: 10 lose cover RAM: -1022M gran_size: 8M chunk_size: 8M num_reg: 10 lose cover RAM: 126M gran_size: 8M chunk_size: 16M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 32M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 64M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 128M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 256M num_reg: 10 lose cover RAM: 6M *BAD*gran_size: 8M chunk_size: 512M num_reg: 10 lose cover RAM: -250M gran_size: 8M chunk_size: 1G num_reg: 10 lose cover RAM: 6M *BAD*gran_size: 8M chunk_size: 2G num_reg: 10 lose cover RAM: -1018M gran_size: 16M chunk_size: 16M num_reg: 10 lose cover RAM: 70M gran_size: 16M chunk_size: 32M num_reg: 10 lose cover RAM: 22M gran_size: 16M chunk_size: 64M num_reg: 10 lose cover RAM: 22M gran_size: 16M chunk_size: 128M num_reg: 10 lose cover RAM: 22M gran_size: 16M chunk_size: 256M num_reg: 10 lose cover RAM: 22M *BAD*gran_size: 16M chunk_size: 512M num_reg: 10 lose cover RAM: -234M gran_size: 16M chunk_size: 1G num_reg: 10 lose cover RAM: 22M *BAD*gran_size: 16M chunk_size: 2G num_reg: 10 lose cover RAM: -1002M gran_size: 32M chunk_size: 32M num_reg: 10 lose cover RAM: 54M gran_size: 32M chunk_size: 64M num_reg: 10 lose cover RAM: 54M gran_size: 32M chunk_size: 128M num_reg: 10 lose cover RAM: 54M gran_size: 32M chunk_size: 256M num_reg: 10 lose cover RAM: 54M *BAD*gran_size: 32M chunk_size: 512M num_reg: 10 lose cover RAM: -202M gran_size: 32M chunk_size: 1G num_reg: 10 lose cover RAM: 54M *BAD*gran_size: 32M chunk_size: 2G num_reg: 10 lose cover RAM: -970M gran_size: 64M chunk_size: 64M num_reg: 8 lose cover RAM: 118M gran_size: 64M chunk_size: 128M num_reg: 8 lose cover RAM: 118M gran_size: 64M chunk_size: 256M num_reg: 9 lose cover RAM: 118M gran_size: 64M chunk_size: 512M num_reg: 10 lose cover RAM: 118M gran_size: 64M chunk_size: 1G num_reg: 9 lose cover RAM: 118M gran_size: 64M chunk_size: 2G num_reg: 10 lose cover RAM: 118M gran_size: 128M chunk_size: 128M num_reg: 7 lose cover RAM: 182M gran_size: 128M chunk_size: 256M num_reg: 9 lose cover RAM: 182M gran_size: 128M chunk_size: 512M num_reg: 10 lose cover RAM: 182M gran_size: 128M chunk_size: 1G num_reg: 9 lose cover RAM: 182M gran_size: 128M chunk_size: 2G num_reg: 10 lose cover RAM: 182M gran_size: 256M chunk_size: 256M num_reg: 5 lose cover RAM: 438M gran_size: 256M chunk_size: 512M num_reg: 5 lose cover RAM: 438M gran_size: 256M chunk_size: 1G num_reg: 6 lose cover RAM: 438M gran_size: 256M chunk_size: 2G num_reg: 7 lose cover RAM: 438M gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 438M gran_size: 512M chunk_size: 1G num_reg: 6 lose cover RAM: 438M gran_size: 512M chunk_size: 2G num_reg: 7 lose cover RAM: 438M gran_size: 1G chunk_size: 1G num_reg: 4 lose cover RAM: 950M gran_size: 1G chunk_size: 2G num_reg: 4 lose cover RAM: 950M gran_size: 2G chunk_size: 2G num_reg: 3 lose cover RAM: 1974M mtrr_cleanup: can not find optimal value please specify mtrr_gran_size/mtrr_chunk_size -------------- use 16 GB ECC Ram on this server, all modules are the same (speed, manufacuer - Kingston, etc). Here are my questions: 1. o you know what disadventages this could make on server installation 2. what should I modify in server configuration to solve this problem?

1 0

update bind97 centos 5 to centos 6
by fakessh ＠ 15 Jan '12

15 Jan '12

hello centos list hello guys hello master of Fu I want to know the different changes to be applied in the config bind97 because I use dnssec and differences may be present. I do not know they are the differences that may exist between centos 5.7 and bind to bind to centos 6.2 I want to know the small differences that may be present in the config bind in the concerns of my desire to perform the update from my server to centos 6.2 in the best conditions all testimonial are welcome -- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting

1 0

Is avahi essential?
by Timothy Murphy 15 Jan '12

15 Jan '12

I've been getting a few avahi-daemon errors in /var/log/messages, eg ------------------------------- Jan 11 00:40:24 helen avahi-daemon[12732]: Invalid query packet. Jan 11 00:40:29 helen last message repeated 17 times ------------------------------- (This is on a CentOS-5.7 server.) So I looked up avahi on the web, but as far as I could see it is not doing anything essential; so I was wondering if stopping avahi-daemon would have any bad effect? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin

15 30

Re: [CentOS] Storage - posibilities?
by Lisandro Grullon 15 Jan '12

15 Jan '12

I hope you will be clustering those storage arrays since email is such a vital service for any organization. What are your current choices? I don't think there would be any major issues as long as you plan you current and long term capacity needs. Let us know what are your plans at the moment. ------Original Message------ From: Rafał Radecki Sender: centos-bounces(a)centos.org To: CentOS mailing list ReplyTo: CentOS mailing list Subject: [CentOS] Storage - posibilities? Sent: Jan 14, 2012 4:56 AM Hi all. Currently I am administering a mail cluster in which messages are stored on software RAID shared with NFS. There are several NFS servers, every one of them exports a part of all mail files for a specific frontend with postfix. We are thinking about replacing these storage hosts with one solution, maybe a storage array with appropriate disk space and I/O capacity. What are pros and cons of that solution? Do storage arrays have appropriate I/O capacity (X*software RAID)? Does it scale good? Does storage capacity also scale good in those solutions? Best regards, R. _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos Sent on the Sprint® Now Network from my BlackBerry®

1 0

LSI/3ware 9750-4i and multipath I/O
by Vahan Yerkanian 15 Jan '12

15 Jan '12

Hi, I was wondering if anyone has successfully configured two lsi/3ware 9750-4i series controllers for multipathing under CentOS 5.7 x86_64? I've tried some basic setups with both multibus and failover settings, and had repeatable filesystem corruption over a iscsi(tgtd) or nfs3 connection. Any ideas? Vahan

3 12

blue screen instead of login screen
by Frank Cox 14 Jan '12

14 Jan '12

I installed Centos 6.2/i386 on a machine last night with a 1920x1080 monitor. The installer ran in graphical mode and looked fine. After the install was finished I rebooted and ran through the "firstboot" stuff (set up user, etc) with no problem and, again, it looked good. After that, when I should have seen the gdm login screen, all I got was the blue background but not the box with the usernames in it, so there is no way to log in. "telinit 3", login to the text console, no problem. Type "startx", back to the same empty blue screen that gdm shows me. [root@ws194 log]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain ws194 ws194.ltsp ::1 localhost localhost.localdomain ws194 ws194.ltsp [root@ws194 log]# uname -a Linux ws194.ltsp 2.6.32-220.2.1.el6.i686 #1 SMP Thu Dec 22 18:50:52 GMT 2011 i686 i686 i386 GNU/Linux [root@ws194 log]# I rsynced /etc/skel to /home/myusername before running startx but that made no difference. Still got the blank blue screen. I tried disabling the Composite extension as directed here: http://www.linuxquestions.org/questions/slackware-14/unable-to-startx-after… Nothing changed. I don't see anything in /var/log/Xorg.0.log that looks too interesting; it appears that X figures it's running fine. This was working fine with a smaller monitor on Centos 5.7. Plus the Centos 6 installer looked fine, and the blue screen also looks nice and crisp, -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com www.creekfm.com - FIFTY THOUSAND WATTS of POW WOW POWER!

3 8

Storage - posibilities?
by Rafał Radecki 14 Jan '12

14 Jan '12

Hi all. Currently I am administering a mail cluster in which messages are stored on software RAID shared with NFS. There are several NFS servers, every one of them exports a part of all mail files for a specific frontend with postfix. We are thinking about replacing these storage hosts with one solution, maybe a storage array with appropriate disk space and I/O capacity. What are pros and cons of that solution? Do storage arrays have appropriate I/O capacity (X*software RAID)? Does it scale good? Does storage capacity also scale good in those solutions? Best regards, R.

4 3

← Newer
1
...
10
11
12
13
14
15
16
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss January 2012