[CentOS] Ceph - best practices

[Nux!]

Hello,

I'm looking into installing ceph, can anyone share his experiences and 
advices? What kernels you used and so on, installation repos, are there 
any selinux issues? Etc.


-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Not respected repo priorities...

[John Doe]

From: Johnny Hughes 
> On 01/28/2013 08:00 AM, John Doe wrote:
>> ---> Package perl-Compress-Zlib.x86_64 0:2.020-127.el6 will be obsoleted
>> ---> Package perl-IO-Compress.noarch 0:2.037-1.el6.rfx will be
>> obsoleting
>> --> Processing Dependency: perl(Compress::Raw::Bzip2) = 2.037 for
>> package: perl-IO-Compress-2.037-1.el6.rfx.noarch
>> --> Processing Dependency: perl(Compress::Raw::Zlib) = 2.037 for
>> package: perl-IO-Compress-2.037-1.el6.rfx.noarch
>> ---> Package perl-IO-Compress-Base.x86_64 0:2.020-127.el6 will be
>> obsoleted
>> ---> Package perl-IO-Compress-Zlib.x86_64 0:2.020-127.el6 will be
>> obsoleted
> It isn't really a bug, an obsolete causes the one package to be removed,
> then another package is replacing it.  Since they have different names,
> the restrictions in priorities do not apply (it does when they have the
> same name).  You will have to exclude perl-IO-Compress from the rfx repo
> ... or if perl-IO-Compress for rfx is a real requirement for a package
> you want to install, you will have to exclude perl-Compress-Raw-Bzip2
> and perl-Compress-Raw-Zlib from Base so those can also be pulled in from
> rfx.

Excluding works.

Thx,
JD
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] CentOS-announce Digest, Vol 95, Issue 10

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@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-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@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-2013:0199 Important CentOS 6 libvirt Update (Johnny Hughes)


--

Message: 1
Date: Mon, 28 Jan 2013 21:41:46 +
From: Johnny Hughes 
Subject: [CentOS-announce] CESA-2013:0199 Important CentOS 6 libvirt
Update
To: centos-annou...@centos.org
Message-ID: <20130128214146.ga12...@chakra.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Security Advisory 2013:0199 Important

Upstream details at : https://rhn.redhat.com/errata/RHSA-2013-0199.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

i386:
880a2564b9c1b120b001ebfc57a2765763ef66a170b40405deef201e4ba5698a  
libvirt-0.9.10-21.el6_3.8.i686.rpm
f132baecba83484560d1720c9cefebe2029514315878b32f1bc7294473669937  
libvirt-client-0.9.10-21.el6_3.8.i686.rpm
d24ba4cdd52ea49e1a270a4a571e006f2f5e8b518af932e3124817cc193b45de  
libvirt-devel-0.9.10-21.el6_3.8.i686.rpm
d7bca83b7d2ac0a2ec89f108158a88ff2907fc5fa974f4c2b8775b480daecca3  
libvirt-python-0.9.10-21.el6_3.8.i686.rpm

x86_64:
27d7eb63e13c6b6089f5dcd0b363236ea3d882062f7cfd392dc46317a48574ee  
libvirt-0.9.10-21.el6_3.8.x86_64.rpm
f132baecba83484560d1720c9cefebe2029514315878b32f1bc7294473669937  
libvirt-client-0.9.10-21.el6_3.8.i686.rpm
fae89ea4ccc4e98dbe8bc0adf0d96ac3275e4818eb3a31f97407e891f467c92f  
libvirt-client-0.9.10-21.el6_3.8.x86_64.rpm
d24ba4cdd52ea49e1a270a4a571e006f2f5e8b518af932e3124817cc193b45de  
libvirt-devel-0.9.10-21.el6_3.8.i686.rpm
1c1e7dea98cf5cfa0ba319525c5de482c7e4e1c64cb1ba279cb1a49819ac3245  
libvirt-devel-0.9.10-21.el6_3.8.x86_64.rpm
82711c817a9fe952e876d56295ed186bd8e574be45acde611f7f2261923216a0  
libvirt-lock-sanlock-0.9.10-21.el6_3.8.x86_64.rpm
b966795762b8c83bfb11e16adf3f4847ee4b6b720a23c3c80afc005e8967403a  
libvirt-python-0.9.10-21.el6_3.8.x86_64.rpm

Source:
05cb232df3bc8b740dbadae94666e4e260bfc119a5dc63d97f8953c1806a4504  
libvirt-0.9.10-21.el6_3.8.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net



--

___
CentOS-announce mailing list
centos-annou...@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce


End of CentOS-announce Digest, Vol 95, Issue 10
***
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Mail notification in panel/system tray on CentOS 6

[Toralf Lund]

On 28/01/13 14:18, SilverTip257 wrote:
> On Mon, Jan 28, 2013 at 2:48 AM, Toralf Lund  wrote:
>
>> On 27/01/13 07:13, SilverTip257 wrote:
>>> On Fri, Jan 25, 2013 at 10:10 AM, Giles Coochey
>>   wrote:
 On 25/01/2013 15:00, Toralf Lund wrote:

> Hi.
>
> Does anyone know of a way to add a "new mail" notification icon to the
> panel/system tray under CentOS 6?
> On CentOS 5, I used the "mail-notification" software package provided
[ ... ]
>>
>> You might consider having your MUA do the notifying rather than having an
>> applet go check your inbox for you.
>> I'm mostly using thunderbird for e-mail, and it actually also supports
>> notification via pop-ups. But:
>>
>>   1. I think it's nice to be able to close the application completely
>>  when not working on e-mail.
>>
> I hear you! ;)
>
>
>>   2. "Global" popups are generally annoying/too obtrusive. A small icon
>>  that changes state is much better.
>>
> Understandable.
>
> http://www.nongnu.org/mailnotify/
> I'm guessing this is what you've used in the past.
Actually, what I used on CentOS 5 was the below mentioned software. 
Before that, i.e. on EL 4, I believe something else was included in the 
main distro, but I don't remember what.

>
> https://admin.fedoraproject.org/pkgdb/acls/name/mail-notification
> Even though the package is listed it appears nobody has packaged it in EPEL
> (for example).
> http://dl.fedoraproject.org/pub/epel/6/i386/repoview/letter_m.group.html
Well, it is actually included in EPEL 5, but not 6.

>
> Not as simple, but you might consider building it on your system.
I tried both binary and source rpms from EPEL5, but it didn't work too 
well. Actually, the problem wasn't mail-notification itself, but rather 
eel2, which it requires. This used to be part of the main distribution, 
but isn't any more. Binaries from past versions have dependencies that 
are hard to resolve, and an attempt to rebuild from source rpm failed 
with the below error messages. Maybe I can find away around this, but I 
don't have time to try right now...

test-eel-image-table.c: In function 'image_table_child_pressed_callback':
test-eel-image-table.c:126: error: 'G_GNUC_FUNCTION' undeclared (first 
use in this function)
test-eel-image-table.c:126: error: (Each undeclared identifier is 
reported only once
test-eel-image-table.c:126: error: for each function it appears in.)
test-eel-image-table.c: In function 'image_table_child_released_callback':
test-eel-image-table.c:141: error: 'G_GNUC_FUNCTION' undeclared (first 
use in this function)
test-eel-image-table.c: In function 'image_table_child_clicked_callback':
test-eel-image-table.c:156: error: 'G_GNUC_FUNCTION' undeclared (first 
use in this function)
test-eel-image-table.c: In function 'foo_timeout':
test-eel-image-table.c:167: error: 'G_GNUC_FUNCTION' undeclared (first 
use in this function)
test-eel-image-table.c: In function 'image_table_size_allocate':
test-eel-image-table.c:195: error: 'G_GNUC_FUNCTION' undeclared (first 
use in this function)

- Toralf


>
>> - Toralf
>>
>>
>>
>>>
 It isn't so common to receive email locally anymore, most people are
>> using
 remote mail servers.

 --
 Regards,

 Giles Coochey, CCNA, CCNAS
 NetSecSpec Ltd
 +44 (0) 7983 877438
 http://www.coochey.net
 http://www.netsecspec.co.uk
 gi...@coochey.net



 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos


>>
>> This e-mail, including any attachments and response string, may contain
>> proprietary information which is confidential and may be legally
>> privileged. It is for the intended recipient only. If you are not the
>> intended recipient or transmission error has misdirected this e-mail,
>> please notify the author by return e-mail and delete this message and any
>> attachment immediately. If you are not the intended recipient you must not
>> use, disclose, distribute, forward, copy, print or rely on this e-mail in
>> any way except as permitted by the author.
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
>


This e-mail, including any attachments and response string, may contain 
proprietary information which is confidential and may be legally privileged. It 
is for the intended recipient only. If you are not the intended recipient or 
transmission error has misdirected this e-mail, please notify the author by 
return e-mail and delete this message and any attachment immediately. If you 
are not the intended recipient you must not use, disclose, distribute, forward, 
copy, print or rely on this e-mail in any way except as permitted by the author.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Is this a NFSv4 bug??

[C. L. Martinez]

HI all,

 I have configured a CentOS 6.3 x86_64 as a NFSv4 server and I am
suffering errors like this:

 perl[7889]: segfault at a80 ip 7fb870227ea2 sp 7fff2fecda30
error 4 in libperl.so[7fb870193000+162000]

The symptoms are the same as described in this thread:

http://serverfault.com/questions/235059/vfs-file-max-limit-1231582-reached

 Can anyone confirm that is a bug when NFSv4 is used?

My actual options are:

fs.file-max = 1639200

[root@server01 fs]# lsof |wc -l
3962

[root@server01 fs]# cat file-nr
30400   1639200
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is this a NFSv4 bug??

[m . roth]

C. L. Martinez wrote:
> HI all,
>
>  I have configured a CentOS 6.3 x86_64 as a NFSv4 server and I am
> suffering errors like this:
>
>  perl[7889]: segfault at a80 ip 7fb870227ea2 sp 7fff2fecda30
> error 4 in libperl.so[7fb870193000+162000]
>
> The symptoms are the same as described in this thread:
>
> http://serverfault.com/questions/235059/vfs-file-max-limit-1231582-reached
>
>  Can anyone confirm that is a bug when NFSv4 is used?
>
> My actual options are:
>
> fs.file-max = 1639200
>
We tested 6.x and NFSv4 - other than speed (much slower than v3, unless
you use async), we saw no perl problems.

   mark

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is this a NFSv4 bug??

[Johnny Hughes]

On 01/29/2013 09:58 AM, C. L. Martinez wrote:
> HI all,
>
>  I have configured a CentOS 6.3 x86_64 as a NFSv4 server and I am
> suffering errors like this:
>
>  perl[7889]: segfault at a80 ip 7fb870227ea2 sp 7fff2fecda30
> error 4 in libperl.so[7fb870193000+162000]
>
> The symptoms are the same as described in this thread:
>
> http://serverfault.com/questions/235059/vfs-file-max-limit-1231582-reached
>
>  Can anyone confirm that is a bug when NFSv4 is used?
>
> My actual options are:
>
> fs.file-max = 1639200
>
> [root@server01 fs]# lsof |wc -l
> 3962
>
> [root@server01 fs]# cat file-nr
> 30400   1639200

Here is the beginning of the thread:

http://www.spinics.net/lists/linux-nfs/msg19623.html

There is a patch here:
http://www.spinics.net/lists/linux-nfs/msg19709.html

If that is your issue.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Is this a NFSv4 bug??

[Johnny Hughes]

On 01/29/2013 10:28 AM, Johnny Hughes wrote:
> On 01/29/2013 09:58 AM, C. L. Martinez wrote:
>> HI all,
>>
>>  I have configured a CentOS 6.3 x86_64 as a NFSv4 server and I am
>> suffering errors like this:
>>
>>  perl[7889]: segfault at a80 ip 7fb870227ea2 sp 7fff2fecda30
>> error 4 in libperl.so[7fb870193000+162000]
>>
>> The symptoms are the same as described in this thread:
>>
>> http://serverfault.com/questions/235059/vfs-file-max-limit-1231582-reached
>>
>>  Can anyone confirm that is a bug when NFSv4 is used?
>>
>> My actual options are:
>>
>> fs.file-max = 1639200
>>
>> [root@server01 fs]# lsof |wc -l
>> 3962
>>
>> [root@server01 fs]# cat file-nr
>> 30400   1639200
> Here is the beginning of the thread:
>
> http://www.spinics.net/lists/linux-nfs/msg19623.html
>
> There is a patch here:
> http://www.spinics.net/lists/linux-nfs/msg19709.html
>
> If that is your issue.

BTW, that is a fairly long time ago not to be fixed .. so I am not sure
it is the current problem.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] yum killed, ipa\* and xorg\* a mess

[Zube]

On Mon Jan 28 08:20:55 AM, Zube wrote:

Follow-up, for the archives:

> yum update was killed at an inopportune time, leaving ipa\* and xorg\*
> in an inconsistent state.  
> 
> yum-complete-transaction looks like it it's going to erase the entire 
> system and then fails.
> 
> >From the transaction files, the following are in:
> 
> install 0:ipa-python-2.2.0-17.el6_3.1.x86_64
> install 0:ipa-client-2.2.0-17.el6_3.1.x86_64
> install 0:xorg-x11-server-common-1.10.6-1.0.1.el6.centos.x86_64
> install 0:ipa-admintools-2.2.0-17.el6_3.1.x86_64
> 
> rpm -q ipa-server returns:
> 
> ipa-server-2.2.0-16.el6.x86_64
> ipa-server-2.2.0-17.el6_3.1.x86_64
> 
> rpm -q ipa-server-selinux returns:
> 
> ipa-server-selinux-2.2.0-16.el6.x86_64
> 
> Thinking I could remove the old and then drop in the new, I tried:
> 
> rpm -e ipa-server-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64
> 
> but that fails with:
> 
> ipa-server-selinux = 2.2.0-17.el6_3.1 is needed by (installed) 
> ipa-server-2.2.0-17.el6_3.1.x86_64

Taking both ipa-server's out:

rpm -e ipa-server-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86
_64 ipa-server-2.2.0-17.el6_3.1.x86_64

worked.  I was then able to:

yum install ipa-server

followed by rpm -e the other ipa\* and xorg\* duplicates that were listed,
to get things back to a consistent state.  I also ran:

yum check 

for good measure.  

Lessons:  

1) yum-complete-transaction is not a silver bullet.

2) Don't order the Kill Yum Special at the Derhay Cafe.

Cheers,
Zube
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Anything Like Solaris' Live Upgrade?

[Tim Evans]

On 01/28/2013 07:55 PM, Karanbir Singh wrote:
> On 01/28/2013 06:54 PM, Tim Evans wrote:
>> It creates one or more "alternate boot environment(s)," then newfs's it,
>
> This is redundant on CentOS
>
>> mounts it, copies the running system to it, then applies
>> upgrades/patches to it.  It does not touch the running environment
>
> not true, you have severe performance loss and no reliable way to
> measure the impact of what that changeset is going to bring in. Patching
> the running system, with a failback option is far better. Unless you
> dont trust the platform at all. Lack of a reasonable manageable and
> predictable packaging system can cause that lack of trust.
>
>> (except to create a housekeeping database for the multiple boot
>> environments).  The target boot environment is made bootable, and the
>
> the idea of bootable on Linux is limited to the kernel and the initrd (
> which even has a shell ). Unless you installed a kernel in the
> transactino set, there is no need to update grub, since your existing
> running boot components are still intact ( if not, you can measure and
> handle it ). If you do update the kernel, the setup will retain multiple
> copies and your last running kernel is always retained as an option to
> boot from next boot cycle
>
>> grub configuration is updated to include the second bootable
>> environment, and the /etc/fstab file on the second environment is
>> modified to reflect the disks/LV's it uses.
>
> Take a look at the yum lvm plugin, it already does most of this - with
> some assumptions on what its going to snapshot and how you want to
> handle that.
>
>> The whole idea is not to touch the running system, apply changes to the
>> alternate system, then boot to the alternate when change is done. Once
>> the reboot to the new environment is done, you can further use LU to
>> replace the un-upgraded/un-patched original environment with a copy of
>> the new one.
>
> This kind of highlights the issue here, you are attempting to look at
> this with too far a solaris process mindset. Most CentOS best-practises
> are driven towards keeping a running system up, by not breaking it or
> needing to do downtime efforts. Some packages due to their nature will
> enforce this, like glibc; but on the whole, its considered acceptable to
> patch live and keep going, with the understanding that there is a
> failover option / failback opton, rather than assume a running system
> must be taken down for a patch to be applied.
>
> There are exceptions, but most of them are niche implementation driven
> ones, on the whole CentOS is built to be patched in place. Take a look
> at the yum lvm plugin on how you can fairly-easily implement the extra
> step you mentioned ( i.e tweak fstab to boot from a diff lv / uuid ).
>

Thanks to everyone for their replies.  I suppose it's not possible in 
this forum to ask such a question and not get into religion. Kinda like 
the U.S. Congress.

No one has yet shown how a byte-for-byte, fully redundant, bootable 
disk(set) can be created and kept up to date that will allow immediate 
recovery from a catastrophic failure of the primary disk(set) with 
nothing more than a reboot.

FWIW, Solaris' problems are not technical.  Rather, they're Oracle's 
licensing and support policies that have essentially fired all its small 
system customers.

-- 
Tim Evans   |   5 Chestnut Court
Linux/UNIX Consulting   |   Owings Mills, MD 21117
http://www.tkevans.com/ |   443-394-3864
http://www.come-here.com/News/  |   tkev...@tkevans.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] yum killed, ipa\* and xorg\* a mess

[Les Mikesell]

On Tue, Jan 29, 2013 at 12:45 PM, Zube  wrote:
>> Lessons:
>
> 1) yum-complete-transaction is not a silver bullet.
>
> 2) Don't order the Kill Yum Special at the Derhay Cafe.

And as an extra warning, note that this is likely to happen if the
updates being installed include freenx or nx and you start yum from a
window in a freenx session.

-- 
   Les Mikesell
lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Anything Like Solaris' Live Upgrade?

[Rainer Duffner]

Am 29.01.2013 um 20:03 schrieb Tim Evans :
> 
> Thanks to everyone for their replies.  I suppose it's not possible in 
> this forum to ask such a question and not get into religion. Kinda like 
> the U.S. Congress.
> 
> No one has yet shown how a byte-for-byte, fully redundant, bootable 
> disk(set) can be created and kept up to date that will allow immediate 
> recovery from a catastrophic failure of the primary disk(set) with 
> nothing more than a reboot.
> 
> FWIW, Solaris' problems are not technical.  Rather, they're Oracle's 
> licensing and support policies that have essentially fired all its small 
> system customers.
> 


I have to say, in my experience the LU-process works (reasonably) well for 
systems without zones.
Once you have zones, it gets much, much more complicated.

It's a nice idea, though, and to me it makes sense (you don't want the system 
to be in a state where only half the patches are installed, however minuscule 
the effects of that may be).



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] intel_iommu=on => No root device found

[Nils Caspar]

Hi all,

for some reaseon, my message wasn't published. Second try, this time without 
the giant attachment.

I have an Intel server (SR2600URBRPR) in front of me. The disks in my server 
are connected via PCI card (Adaptec RAID 3405).

Now I would like to passthrough a PCI-E graphics card to a KVM guest. As this 
requires Intel VT-d, I configured the following options in the BIOS:

Intel VT for Directed I/O  [Enabled]
 Interrupt Remapping   [Enabled]
 Coherency Support [Disabled]
 ATS Support   [Enabled]
 Pass-through DMA Support  [Enabled]

Everything works so far, but when I add intel_iommu=on to the kernel line of my 
grub.conf, Dracut gives my a kernel panic while booting. I added "rdshell" to 
the command line and extracted the boot messages via dmesg 
(http://nilscaspar.ch/centos-dmesg.log). I think the main problem is this:

dracut Warning: No root device 
"block:/dev/disk/by-uuid/280234d1-dff5-4e04-b1ef-93d54cdcd825" found

But I doesn't make sense to me... As soon as I remove intel_iommu=on, 
everything works again (except the passthrough :P).

Regards,
Nils

-- 
nilscaspar.ch

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Alias for sending email messages from root

[James B. Byrne]

I have run into what can only be described as a farce but one that is
outside my control and which I need fixed.

I am informed that my cell phone service provider, Bell Canada, will
not allow any email messages from a user id 'root' to pass through
their email to sms text gateway.  Now, I send alerts out from cron and
other system monitoring software and these all go out as
r...@host.domain.tld.

Is there any way to configure the outgoing address to be something
else?  Or do I have to rename the root user to get around this
nonsensical, and utterly useless, restriction imposed by my provider?


-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Alias for sending email messages from root

[Patrick McEvoy]

On 01/29/2013 04:03 PM, James B. Byrne wrote:
> I have run into what can only be described as a farce but one that is
> outside my control and which I need fixed.
>
> I am informed that my cell phone service provider, Bell Canada, will
> not allow any email messages from a user id 'root' to pass through
> their email to sms text gateway.  Now, I send alerts out from cron and
> other system monitoring software and these all go out as
> r...@host.domain.tld.
>
> Is there any way to configure the outgoing address to be something
> else?  Or do I have to rename the root user to get around this
> nonsensical, and utterly useless, restriction imposed by my provider?
>
>

vi /etc/aliases

Edit entry at bottom of file:

# Person who should get root's mail
#root:  marc

Execute  newaliases as root or sudo



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Alias for sending email messages from root

[Les Mikesell]

On Tue, Jan 29, 2013 at 4:03 PM, James B. Byrne  wrote:
> I have run into what can only be described as a farce but one that is
> outside my control and which I need fixed.
>
> I am informed that my cell phone service provider, Bell Canada, will
> not allow any email messages from a user id 'root' to pass through
> their email to sms text gateway.  Now, I send alerts out from cron and
> other system monitoring software and these all go out as
> r...@host.domain.tld.
>
> Is there any way to configure the outgoing address to be something
> else?  Or do I have to rename the root user to get around this
> nonsensical, and utterly useless, restriction imposed by my provider?

First, are you sure that the @host.domain.tld is really included for
root?   If you are relying on sendmail's 'MASQUERATE_AS', you have to
make sure that you remove root from the EXPOSED_USER default setting.

Otherwise see 'man 5 crontab' for how to set MAILFROM, or if you are
mailing in a script, construct the headers yourself and use 'sendmail
-t' to use them instead of using the unix user as the sender.

-- 
   Les Mikesell
 lesmikes...@gmail.com
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Anything Like Solaris' Live Upgrade?

[Warren Young]

On 1/29/2013 12:03, Tim Evans wrote:
> I suppose it's not possible in
> this forum to ask such a question and not get into religion. Kinda like
> the U.S. Congress.

Um.  Yes.  

I know you think you're asking for an additional freedom that you feel 
CentOS doesn't provide, but what you're really looking for is a reason 
to go back and shackle yourself to a proprietary technology.

Wise man say: "Free your mind...and your ass will follow."  Wise man was 
on acid when he said that[1] but the point...the POINT I say...is that 
you're being trapped by a material desire which if satisfied costs more 
than it's worth when you add in *all* the costs.  Kinda like a jelly 
doughnut.  A really big, expensive jelly doughnut.

In addition to the problems with proprietary technology, there's at 
least one more problem with Solaris' boot environment snapshots: they 
take space, and space costs money.  Oh, you say, it "only" costs a few 
tens of gigabytes for each system version upgrade.  What's the problem 
in today's terabyte world?

Here's the problem: You want to set up a Solaris VM for development and 
testing, and read that Solaris needs just 7 GB or so to install[2] 
everything, so you generously give it 20 GB on your laptop.[3]  Life is 
fine: you install some additional software, you do your dev work, you 
iterate.  Then six months later an OS upgrade comes out, you attempt to 
install it, it runs you out of disk space creating the snapshot, and 
then fails to boot.  (Yes, actual genuine war story.  Made in USA.)

But wait, weren't snapshots supposed to save me from unbootable systems? 
  Sure, as long as you have prodigious free disk space.  I don't know 
about you, but several gigs of free disk on a VM still feels like a lot 
to me.

You get bit other ways by this feature, too.  It requires ZFS, which by 
most accounts requires 64-bit CPUs and a gig of RAM per terabyte of disk 
just to manage it.  This means that if I give up on my reasonable wish 
for a 20 GB VM and give it a dedicated HDD or three to play with, now I 
have to go and set aside beaucoup RAM for it, too.  Or maybe a whole system.

I'm not saying that all of this is out of reach.  Yes, I get the fact 
that I'm bitching about under $1000 of hardware.  My point is that 
features have a cost, and different OSes "charge" you different amounts 
through their designer's choices about which features to include and 
which to skip for now.

In the end, we are in fact talking rationality here, not religion.  How 
much do you want to pay for those features?  TANSTAAFL.

> FWIW, Solaris' problems are not technical.  Rather, they're Oracle's
> licensing and support policies that have essentially fired all its small
> system customers.

That pool is deeper than you realize.

Maybe above you were rolling your eyes at my wish for a usable 20 GB 
OpenSolaris VM.

Consider this: I have five or six flavors of Linux on that laptop, plus 
all the BSDs, Windows 8, and the native OS X.  When it comes time for me 
to test a new version of my software, guess which OS it isn't going to 
get tested on, purely because I can't afford to dedicate a whole system 
to it?  Or if I *am* fortunate enough to be able to afford a dedicated 
OpenSolaris box, it's a good chance it isn't where I am now, so it might 
as well not exist.

Do you expect developers like me to multiply the cost by 2, 3, 4x just 
so we can have a dedicated test box at every development location?  Or 
maybe punch holes in firewalls so we can remotely use a remote box on 
the back-end somewhere; that isn't "free" either, once you tally the 
security risks it buys.

Here's why you care about my development problems: if my software 
doesn't work on your platform, what does it cost you to do the fixes to 
it to make it work, or seek out an alternative that does work?

How many more are there like me who also might like to test on Solaris 
occasionally if it were easy, but don't because it isn't?  How many 
packages are there with Solaris portability problems as a result?  I'd 
guess there are hundreds of such packages that you personally would like 
to use, but either can't, or could if you wanted to put in the time to 
port them yourself.

All this because Solaris chased the high end at the expense of the 
smaller systems.

What's happening today to Solaris is simply what happened to all the 
lesser proprietary Unixes before it.  The market's been dissolving from 
the bottom, and now the mountaintop is dissolving, too.

It's the old UnixWare vs Linux arguments, recapitulated.  You remember 
how that story ended, don't you?

Yes, I know you're switching to Linux now.  What I'm trying to get 
across is that you should take Linux on its own terms, not try to force 
it into the Solaris mold.  It is the way it is for a pile of good, 
rational reasons.


[1] http://goo.gl/uSIUN
[2] http://goo.gl/RnXpW
[3] Generous = 10-50% of the free space on a typical laptop SSD.
___
CentO

[CentOS] centos 6.3 git core.sharedRepository = group/all not working?

[Min Wang]

HI

I have a git bare repo on centos 6.3 ( with selinux off)

the config is:
[core]
 repositoryformatversion = 0
 filemode = true
 bare = true
 sharedRepository = all  ( or true or group)


chmod -R g+rs objects

when  git pushed the changes from remote ssh .

the new file under objects are not writable.
e.g.:

-r--r--r--. 1 myuser mygroup 156 Jan 29 22:22 
objects/fa/905054c795a3b7e5c244bfc6f3a30a0277c6d0

what could be wrong?


thanks.

min



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] pid location from clamav on Centos 6.3

[Robert Moskowitz]

I was getting nowhere with my clamav permissions problem, so I blew away 
my test system and did a total rebuild.  I am now up to the part right 
after the install of amavis-new, clamav, clamav-devel, and clamd all 
from the epel.repo (spamassassin, also installed at the same time comes 
from the base repo).

Prior to this, I rebuild the system from my kickstart file, and did the 
postfix, postfixadmin, mysql, dovecot, and roundcube setups all from 
instructions and scripts that I have put together over the past number 
of weeks, and this part went right through with no apparent problems.

So now I am carefully checking out clamav before I make any config 
changes and right away I notice discrepencies with where clamd.pid is 
located.

In /etc/clamd.conf it is placed in /var/run/clamav/clamd.pid

In /etc/clamd.d/amavisd.conf it is placed in /var/run/amavisd/clamd.pid

/etc/amavisd/amaviisd.conf does not reference the clamd.pid, only the 
.sock and warns you to point it to the same place as in /etc/clamd.conf.

But what gives with the pid file locations?  I might think that in a 
base install the pid file would be pointed to the same place?

Obviously, I have figured out I really need to make these two enteries 
the same, but still.  :(


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Centos 6.3 - which repos to use?

[Bry8 Star]

Sorry, mentioned [pgdg92] twice. Pls ignore/delete the [pgdg92] that
has priority 15.



Received from Bry8 Star, on 2013-01-28 10:16 AM:
> For PostgreSQL, i've done these (shown below) at initial/test
> stage: (pls DO NOT follow/copy it, try to understand pattern and
> do what fits for your case/need).
> 
> From a VE instance inside HN:
> 
> yum has these plugins:
> fastestmirror, filter-data, keys,
> list-data, merge-conf, presto, priorities, security, verify.
> 
> # CentOS-Base.repo
> [CentOS-base]
> #<...snip...>
> enabled=1
> # i do not want below set from centos repo
> # as these exacts are released by postgre devs
> # but other postgre portions from others i do want
> exclude=postgresql.* postgresql-contrib*
> postgresql-debuginfo* postgresql-devel* postgresql-docs*
> postgresql-jdbc.* postgresql-jdbc-debuginfo* postgresql-libs*
> postgresql-odbc.i686 postgresql-odbc-debuginfo*
> postgresql-plperl* postgresql-plpython* postgresql-pltcl*
> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo*
> postgresql-test*
> priority=1
> 
> [CentOS-updates]
> #<...snip...>
> enabled=1
> exclude=postgresql.*
> postgresql-contrib* postgresql-debuginfo* postgresql-devel*
> postgresql-docs* postgresql-jdbc.* postgresql-jdbc-debuginfo*
> postgresql-libs* postgresql-odbc.i686 postgresql-odbc-debuginfo*
> postgresql-plperl* postgresql-plpython* postgresql-pltcl*
> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo*
> postgresql-test*
> priority=1
> 
> [CentOS-extras]
> #<...snip...>
> enabled=1
> exclude=postgresql.*
> postgresql-contrib* postgresql-debuginfo* postgresql-devel*
> postgresql-docs* postgresql-jdbc.* postgresql-jdbc-debuginfo*
> postgresql-libs* postgresql-odbc.i686 postgresql-odbc-debuginfo*
> postgresql-plperl* postgresql-plpython* postgresql-pltcl*
> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo*
> postgresql-test*
> priority=1
> 
> [CentOSplus]
> #<...snip...>
> enabled=1
> exclude=kernel.*
> kernel-firmware.* kernel-headers.* postgresql.* 
> postgresql-contrib* postgresql-debuginfo* postgresql-devel* 
> postgresql-docs* postgresql-jdbc.* postgresql-jdbc-debuginfo* 
> postgresql-libs* postgresql-odbc.i686 postgresql-odbc-debuginfo* 
> postgresql-plperl* postgresql-plpython* postgresql-pltcl* 
> postgresql-server* postgresql-tcl.i686 postgresql-tcl-debuginfo* 
> postgresql-test*
> priority=1
> 
> # pgdg92-centos.repo
> [pgdg92]
> #<...snip...>
> enabled=1 
> priority=10
> 
> [pgdg92-source]
> #<...snip...>
> enabled=1
> priority=10
> 
> #scntflnx.repo
> [SciLnx-6x-os]
> #<...snip...>
> enabled=1 
> exclude=redhat-rpm-config.* postgresql.* postgresql-devel* 
> postgresql-docs* postgresql-contrib* postgresql-jdbc.* 
> postgresql-libs* postgresql-odbc* postgresql-plperl* 
> postgresql-plpython* postgresql-pltcl* postgresql-server* 
> postgresql-test*
> priority=13
> 
> [SciLnx-6x-updates-fastbugs]
> #<...snip...>
> enabled=1 
> exclude=postgresql.* postgresql-devel* postgresql-docs* 
> postgresql-contrib* postgresql-jdbc.* postgresql-libs* 
> postgresql-odbc* postgresql-plperl* postgresql-plpython* 
> postgresql-pltcl* postgresql-server* postgresql-test* 
> priority=13
> 
> [SciLnx-6x-updates-security]
> #<...snip...>
> enabled=1 
> exclude=postgresql.* postgresql-devel* postgresql-docs* 
> postgresql-contrib* postgresql-jdbc.* postgresql-libs* 
> postgresql-odbc* postgresql-plperl* postgresql-plpython* 
> postgresql-pltcl* postgresql-server* postgresql-test* 
> priority=13
> 
> [SciLnx-6x-debuginfo]
> #<...snip...>
> enabled=0
> priority=13
> 
> [SciLnx-6x-SRPMS]
> #<...snip...>
> enabled=1
> priority=13
> 
> [pgdg92]
> #<...snip...>
> enabled=1
> priority=15
> 
> ... other repo & distro ...
> 
> In above way, i get most from PosteGre repo, and other postgre 
> related side packages from other repos. if i were to place 
> exclude=postgre* then all packages would have gotten excluded,
> and then the extra postgre pkg which are not released by postgre,
> would get hidden/excluded as well, though, i could have used this
> approach for to get that:
> 
> includepkgs=related-extra-postgre-pkg
> 
> to get those. but then i would need specific name, but what if
> new extra pkg that i dont know yet, is included, but since i have
> not specified specifically, those would get hidden/excluded. (my
> repo inquiries have shown, many other repo has at-least 1 to 3 or
> some up to 6 extra postgre related tools which are not released 
> by postgre devs themselves).
> 
> Few patterns/logics which i like to follow:
> 
> repo#1, rpm priority 1, srpm priority 50
> repo#2, rpm priority 10, srpm priority 40
> repo#3, rpm priority 15, srpm priority 30 
> repo#4, rpm priority 20, srpm priority 20
> ...
> 
> Priority numbering pattern/logic:
> Since i'm using centos as my
> base, so various DISTRO & REPO rpm/binary which are closest to
> CentOS & CentOS's source RHEL, those distro & repo will get
> lowest priority# close to centos. i like to think/visualize in
> this way ... a LIST from t

Re: [CentOS] centos 6.3 git core.sharedRepository = group/all not working?

[Phil Dobbin]

On 01/30/2013 03:34 AM, Min Wang wrote:

> HI
> 
> I have a git bare repo on centos 6.3 ( with selinux off)
> 
> the config is:
> [core]
>  repositoryformatversion = 0
>  filemode = true
>  bare = true
>  sharedRepository = all  ( or true or group)
> 
> 
> chmod -R g+rs objects
> 
> when  git pushed the changes from remote ssh .
> 
> the new file under objects are not writable.
> e.g.:
> 
> -r--r--r--. 1 myuser mygroup 156 Jan 29 22:22 
> objects/fa/905054c795a3b7e5c244bfc6f3a30a0277c6d0
> 
> what could be wrong?

You've set the group read permissions but you haven't set any write
permissions.

Take a look at:


Cheers,

  Phil...

-- 
currently (ab)using
CentOS 5.8 & 6.3, Debian Squeeze & Wheezy, Fedora Beefy & Spherical,
Lubuntu 12.10, OS X Snow Leopard & Ubuntu Precise & Quantal
GnuPG Key : http://www.horse-latitudes.co.uk/publickey.asc


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] yum killed, ipa\* and xorg\* a mess

[SilverTip257]

On Tue, Jan 29, 2013 at 2:09 PM, Les Mikesell  wrote:

> On Tue, Jan 29, 2013 at 12:45 PM, Zube  wrote:
> >> Lessons:
> >
> > 1) yum-complete-transaction is not a silver bullet.
> >
> > 2) Don't order the Kill Yum Special at the Derhay Cafe.
>
> And as an extra warning, note that this is likely to happen if the
> updates being installed include freenx or nx and you start yum from a
> window in a freenx session.
>

Run updates behind screen via local console or SSH.
:)


>
> --
>Les Mikesell
> lesmikes...@gmail.com
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


-- 
---~~.~~---
Mike
//  SilverTip257  //
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] centos 6.3 git core.sharedRepository = group/all not working?

[Min Wang]

Hi

thanks. I had a typo on my previsous emai

it was:  chmod -R g+rws objects

> -r--r--r--. 1 myuser mygroup 156 Jan 29 22:22
> objects/fa/905054c795a3b7e5c244bfc6f3a30a0277c6d0


min


On Tue, Jan 29, 2013 at 11:18 PM, Phil Dobbin wrote:

> On 01/30/2013 03:34 AM, Min Wang wrote:
>
> > HI
> >
> > I have a git bare repo on centos 6.3 ( with selinux off)
> >
> > the config is:
> > [core]
> >  repositoryformatversion = 0
> >  filemode = true
> >  bare = true
> >  sharedRepository = all  ( or true or group)
> >
> >
> > chmod -R g+rs objects
> >
> > when  git pushed the changes from remote ssh .
> >
> > the new file under objects are not writable.
> > e.g.:
> >
> > -r--r--r--. 1 myuser mygroup 156 Jan 29 22:22
> > objects/fa/905054c795a3b7e5c244bfc6f3a30a0277c6d0
> >
> > what could be wrong?
>
> You've set the group read permissions but you haven't set any write
> permissions.
>
> Take a look at:
> <
> http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.cmds%2Fdoc%2Faixcmds1%2Fchmod.htm
> >
>
> Cheers,
>
>   Phil...
>
> --
> currently (ab)using
> CentOS 5.8 & 6.3, Debian Squeeze & Wheezy, Fedora Beefy & Spherical,
> Lubuntu 12.10, OS X Snow Leopard & Ubuntu Precise & Quantal
> GnuPG Key : http://www.horse-latitudes.co.uk/publickey.asc
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] intel_iommu=on => No root device found

[Gordon Messmer]

On 01/29/2013 01:16 PM, Nils Caspar wrote:
> Everything works so far, but when I add intel_iommu=on to the kernel
> line of my grub.conf, Dracut gives my a kernel panic while booting. I
> added "rdshell" to the command line and extracted the boot messages
> via dmesg (http://nilscaspar.ch/centos-dmesg.log).

Similar behavior has been diagnosed as a hardware bug:
https://bugzilla.redhat.com/show_bug.cgi?id=605888

Boot the system with the IOMMU off and find out what PCI device is at 
05:01.0 using lspci.  Assuming that it's not critical, try disabling or 
removing that component.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Alias for sending email messages from root

[Gordon Messmer]

On 01/29/2013 02:03 PM, James B. Byrne wrote:
> Is there any way to configure the outgoing address to be something
> else?  Or do I have to rename the root user to get around this
> nonsensical, and utterly useless, restriction imposed by my provider?

http://www.postfix.org/ADDRESS_REWRITING_README.html#remote

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] intel_iommu=on => No root device found

[Nils Caspar]

Thank you for your hint.

> Boot the system with the IOMMU off and find out what PCI device is at 
> 05:01.0 using lspci.  Assuming that it's not critical, try disabling or 
> removing that component.

I can not see a 05:01.0 using lspci. There is however 05:0e.0, which is the 
RAID controller (Adaptec RAID 3405). It's kind of a critical component, so I 
can not disable it. ;)
Does this mean, it's impossible to make IOMMU work on this machine?

-- 
nilscaspar.ch

On 30.01.2013, at 05:52, Gordon Messmer  wrote:

> On 01/29/2013 01:16 PM, Nils Caspar wrote:
>> Everything works so far, but when I add intel_iommu=on to the kernel
>> line of my grub.conf, Dracut gives my a kernel panic while booting. I
>> added "rdshell" to the command line and extracted the boot messages
>> via dmesg (http://nilscaspar.ch/centos-dmesg.log).
> 
> Similar behavior has been diagnosed as a hardware bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=605888
> 
> Boot the system with the IOMMU off and find out what PCI device is at 
> 05:01.0 using lspci.  Assuming that it's not critical, try disabling or 
> removing that component.
> ___
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos