[CentOS-announce] CESA-2012:0016 Important CentOS 4 libxml2 Update
CentOS Errata and Security Advisory 2012:0016 Important
Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-0016.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
78e2dffdf8c995b1eccfd02132bb10663ea92daedcd293724cf1f51429680152
libxml2-2.6.16-12.9.i386.rpm
0e7b5c9c8ebcdd3b481006bce6fee5fb5b9c1ae5dc4bc1ed44ec3abfdb0ba749
libxml2-devel-2.6.16-12.9.i386.rpm
8321ca7f2ccc2d01dc42a8ea8f8585f5fa0eecb471e233764b8e9f970973a0a1
libxml2-python-2.6.16-12.9.i386.rpm
x86_64:
78e2dffdf8c995b1eccfd02132bb10663ea92daedcd293724cf1f51429680152
libxml2-2.6.16-12.9.i386.rpm
9553dd3c21c98ed4ef5d68e31c4420935eba81850f61eb2f69ea0854dbcf1a23
libxml2-2.6.16-12.9.x86_64.rpm
a08b852fa6b8cba07502ff67c5df8dd9f7284844d6c3ac075489c107b2877551
libxml2-devel-2.6.16-12.9.x86_64.rpm
8793fee9abfed29eb9251d652d2505fcbaa752abcb3e5c32943dc4bbe1ba51ab
libxml2-python-2.6.16-12.9.x86_64.rpm
Source:
8e4f9172f1b42efdf9fee4cb9a84ed90229d61120ba8bf40f4e56503696425c6
libxml2-2.6.16-12.9.src.rpm
--
Tru Huynh
CentOS Project { http://www.centos.org/ }
irc: tru_tru, #cen...@irc.freenode.net
___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2012:0007 Important CentOS 5 kernel Update
CentOS Errata and Security Advisory 2012:0007 Important
Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-0007.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
402d3404f92474d86ddd4d8c6758ba10bd3b39959a0faaec09e9e5a19d218a5a
kernel-2.6.18-274.17.1.el5.i686.rpm
b251bd9d76087e56bca02fc47501fe331c9625cefbaa7c7fc8f0a3fbc89b3b53
kernel-debug-2.6.18-274.17.1.el5.i686.rpm
8508f7d98f4a57fc393162f340944c0d07d8e2281c14701bc6420eb5f5cc1268
kernel-debug-devel-2.6.18-274.17.1.el5.i686.rpm
49563f6179d3eff48073c8949c080dc9e038b72d5aba27f436ae3a1ed1513fae
kernel-devel-2.6.18-274.17.1.el5.i686.rpm
251a821d2b78df410105a48a1c3dd3b6908d8146cdd03ee19270de5d0ec18251
kernel-doc-2.6.18-274.17.1.el5.noarch.rpm
28794913da797e46efffe592b4f6d498734372ad27028187fefb1475019a0b42
kernel-headers-2.6.18-274.17.1.el5.i386.rpm
d1110bc1638f68477990d39022f2cf1ba0cf80cb55ff26bae48ae2f04ec902eb
kernel-PAE-2.6.18-274.17.1.el5.i686.rpm
3fb76bc62ea497fe696a3e615ab3caccca33f0743e71c1217c6b5ebb48101d19
kernel-PAE-devel-2.6.18-274.17.1.el5.i686.rpm
e270307bac77e3d10542c64f625e27e3e10f3c5d65de4a718a34c061106f8977
kernel-xen-2.6.18-274.17.1.el5.i686.rpm
9d58b222cfa0442ea30fbc410c4eb46ce6ffcf25d7d1f19b6e59a8f43c54b109
kernel-xen-devel-2.6.18-274.17.1.el5.i686.rpm
x86_64:
5feb173a778651a68e9850193c2e7e36ef437c9b53ca7a991474d31db323538f
kernel-2.6.18-274.17.1.el5.x86_64.rpm
234ac89f24db3eca242881e8ca5b6fdb40eab8922cfe605b784ffc42ae22cab4
kernel-debug-2.6.18-274.17.1.el5.x86_64.rpm
56ff302db4e661afae1eb20b2e1d33416b3dd4539da96caf5c47e347a01eb8ec
kernel-debug-devel-2.6.18-274.17.1.el5.x86_64.rpm
cc2434f423b4c9c2f8249e507bb01aa12f0fa7f40fb36b9299037869e23e3398
kernel-devel-2.6.18-274.17.1.el5.x86_64.rpm
251a821d2b78df410105a48a1c3dd3b6908d8146cdd03ee19270de5d0ec18251
kernel-doc-2.6.18-274.17.1.el5.noarch.rpm
978743db832ae51f77de6f69f27e6924e79127a47b0f85f20711a17761610bd1
kernel-headers-2.6.18-274.17.1.el5.x86_64.rpm
2f00d6f7db60ac0317d524f72d3dafafdba2cb294c69f097b57c3dfba728cb31
kernel-xen-2.6.18-274.17.1.el5.x86_64.rpm
040b1b55c941f2ff5f837668b689d5150c8cb83617169d5f0ea86eba1a9a88b1
kernel-xen-devel-2.6.18-274.17.1.el5.x86_64.rpm
Source:
9d80443d04c6d7c47f5cb69359b257debfd4186557ef480503b1b65483b33e90
kernel-2.6.18-274.17.1.el5.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
[CentOS-announce] CESA-2012:0018 Important CentOS 6 libxml2 Update
CentOS Errata and Security Advisory 2012:0018 Important
Upstream details at : https://rhn.redhat.com/errata/RHSA-2012-0018.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
ee2079738a9700351dddb1119480aaa2484495d3e8241fe313910070e583418c
libxml2-2.7.6-4.el6_2.1.i686.rpm
85391644a9df8e8b6e348008e857dc5e48bc267fe9dcaa7dd323fa0fac7f9166
libxml2-devel-2.7.6-4.el6_2.1.i686.rpm
7f53126876df4b8d8c1babd1a45d618d1e25c57ce39a27a104e4805eb5ac554f
libxml2-python-2.7.6-4.el6_2.1.i686.rpm
9563d63785142a4f15d40c8a32d7c7cce1546dee0cf9e621b36a14375af6c6a7
libxml2-static-2.7.6-4.el6_2.1.i686.rpm
x86_64:
ee2079738a9700351dddb1119480aaa2484495d3e8241fe313910070e583418c
libxml2-2.7.6-4.el6_2.1.i686.rpm
111742b43aeca98d1d2b131887bbd28894f44d96cf6bdd86f8726ef185c0df56
libxml2-2.7.6-4.el6_2.1.x86_64.rpm
85391644a9df8e8b6e348008e857dc5e48bc267fe9dcaa7dd323fa0fac7f9166
libxml2-devel-2.7.6-4.el6_2.1.i686.rpm
3c78b7ef80739a9a55c30adbdd456e954e8096854363448c239f8b94cb0a7e0e
libxml2-devel-2.7.6-4.el6_2.1.x86_64.rpm
9f7244267ca51a9fbfdc873fe135623ac34fd1280ac6435e58d83f42054c2c5a
libxml2-python-2.7.6-4.el6_2.1.x86_64.rpm
308bc7a96bcb4aa2007d5274fc51406d329fbbd969f159cc21947ad28c8d106a
libxml2-static-2.7.6-4.el6_2.1.x86_64.rpm
Source:
af03917205bfd92ff9a2fac7cbb099c1081162d71b43a61e95e18d4e70c7c873
libxml2-2.7.6-4.el6_2.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
___
CentOS-announce mailing list
CentOS-announce@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
Re: [CentOS-virt] Has anyone been able to start a Fedora 16 VM in Xen PV?
On Tue, Jan 10, 2012 at 05:59:56PM +0400, Eugene Chupriyanov wrote:
I've managed to setup F16 PV-guest domU under Xen Cloud Platform. It's
more than just Xen, but solution will be the same.
So what you need to do:
1) Don;t use GPT (install with nogpt kernel parameter)
2) Create bootable /boot partition using ext2 filesystem
3) pygrub looks for grub.cfg in /boot/grub directory (to be exact in
/grub on /boot fs). But in F16 grub is located ion /boot/grub2.
So I just copied grub.cfg from /boot/grub2 to /boot/grub. Maybe there is
a better way to keep up-to-date copy of grub.cfg in /boot/grub.
4) pygrub bootloader fails on following line in default grub.cfg:
set default=${saved_entry}
so I've replaced it with:
set default=0
That should be enough to make f16 to run in PV mode.
Yes, thanks for that! This works for me. How did you know that pygrub
failed on that line?
Anyway, my steps to get F16 going under Centos 5.7 with
xen-3.0.3-132.el5_7.2 were:
1. Create a new PV guest and boot the F16 install image with the nogpt
kernel parameter.
2. After install has finished and before you reboot,
switch to text console on ALT-F2 of your install and copy the
/mnt/sysimage/boot/grub2/grub.cfg to /mnt/sysimage/boot/grub/grub.cfg
and edit the line:
set default=${saved_entry}
to
set default=0
And that's it. The F16 should boot now. The only difference to Eugene's
steps is that I didn't worry about the ext2 boot partition. Mine is
ext4.
Also note that the copy and edit in step 2 should be easy to put in a
kickstart file.
If you forget to do step 2, you can do it on the host with, in my case,
kpartx, mount, and edit the files there. Remember to do a:
echo 1 /proc/sys/vm/drop_caches
so that pygrub will read to changes and not use the cached version.
And finally, when xen-3.0.3-135 is released, it should fix this problem.
I also had success with doing an F15 install, doing an upgrade to F16
and not updating the boot loader. I then manually created a grub.cfg
file. After that F16 booted OK.
I did not try R P Herrold's solution of using an F15 install, installing
fedora-release-16-1.noarch.rpm with rpm, then doing a yum update.
Thanks all you your help.
--
Norman Gaywood, Computer Systems Officer
University of New England, Armidale, NSW 2351, Australia
ngayw...@une.edu.auPhone: +61 (0)2 6773 3337
http://mcs.une.edu.au/~normFax: +61 (0)2 6773 3312
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
___
CentOS-virt mailing list
CentOS-virt@centos.org
http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-es] Montar disco
Cesar, tu estas compartiendo /root/archivos y en error veo que el busca Archivos/archivos, en /etc/samba/smb.conf coloca en el path = /root/archivos/archivos. Reinicia el samba y prueba nuevamente, debería funcionar. C.R. El 10 de enero de 2012 21:33, Carlos Sura carlos.su...@googlemail.comescribió: 2012/1/10 César Martinez cmarti...@servicomecuador.com Hola amigos esperando que todos se encuentren bien acudo a ustedes para ver si me pueden hechar una mano con un problema, tengo un servidor HP proliant con centos 5.7 con dos discos 146 GB montados en Raid por hardware que viene por defecto, adquirimos un nuevo disco de 2TB el cual esta ya montado y lo reconoce bien mi linux puedo copiar y hacer todo en el disco en el mismo servidor, ahora la idea es este disco compartirlo en la red via samba para que los usuarios puedan usarlo como contenedor de sus archivos para ello expongo lo siguiente 1.- El disco esta montado aqui /dev/sda1 1,8T 196M 1,7T 1% /root/archivos [root@localhost ~]# df -h S.ficheros Tamaño Usado Disp Uso% Montado en /dev/sdb5 143G 2,7G 133G 2% / /dev/sdb3 494M 11M 458M 3% /tmp /dev/sdb1 99M 11M 83M 12% /boot tmpfs 220M 0 220M 0% /dev/shm /dev/sda1 1,8T 196M 1,7T 1% /root/archivos 2.- Puedo copiar mover archivos en el mismo servidor sin problemas en el fstab esta montado asi /dev/sda1 /root/archivos ext3defaults 0 0 3.- Cuando arranca el equipo se monta bien ahora en mi archivo smb.conf tengo esto [root@localhost ~]# cat /etc/samba/smb.conf [global] log file = /var/log/samba/log.%m name resolve order = wins hosts bcast announce version = 5.2 domain master = yes encrypt passwords = true wins proxy = yes wins support = true dns proxy = yes netbios name = archivos max wins ttl = 518400 server string = archivos max ttl = 86400 local master = yes workgroup = ARQUITECTOS os level = 100 debug level = 2 announce as = nt min wins ttl = 21600 max log size = 50 security = share username map = /etc/samba/smbusers smb passwd file = /etc/samba/smbpasswd encrypt passwords = yes Win7 Support client ntlmv2 auth = yes client lanman auth = yes client plaintext auth = yes lanman auth = yes ntlm auth = yes [archivos] comment = directorio publico writeable = yes delete readonly = yes browseable = yes public = yes guest ok = Yes path = /root/archivos create mask = 1777 directory mask = 1777 hide dot files = Yes 4.- Pero al tratar de entra a las carpeta compartida que esta en el nuevo disco me sale el error que pueden verlo aqui http://servicomecuador.com/** capturas/error.JPG http://servicomecuador.com/capturas/error.JPG 5.- Ya le cambie los permisos y los propietarios del la carpeta compartida a nobody y a permisos 777 por si era eso pero sigue sin funcionar [root@localhost archivos]# cd archivos/ [root@localhost archivos]# ll total 20 drwxrwxrwx 2 nobody nobody 4096 ene 10 20:30 archivos drwx-- 2 root root 16384 ene 10 19:59 lost+found [root@localhost archivos]# Ojalá que alguíen me pueda hechar una mano gracias a todos César ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es Hola César, He leído muy rápidamente tu correo, y el problema estoy seguro que está en el smb.conf Lo reviso más tarde a ver si encuentro algo y te escribo. Saludos -- Carlos Sura.- www.carlossura.com ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- Carlos Restrepo M. Administrador de Sistemas. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Montar disco
/dev/sda1 1,8T 196M 1,7T 1% /root/archivos no uses el HOME del usuario root para montar cosas,es una pésima idea ponle en /respaldos o /archivos. [archivos] comment = directorio publico writeable = yes delete readonly = yes browseable = yes public = yes guest ok = Yes path = /root/archivos create mask = 1777 directory mask = 1777 hide dot files = Yes 4.- Pero al tratar de entra a las carpeta compartida que esta en el nuevo disco me sale el error que pueden verlo aqui http://servicomecuador.com/capturas/error.JPG debes uasr el mismo smb.conf y agregarle a esta sección archivos: force user = root force group = root con eso trabajará. 5.- Ya le cambie los permisos y los propietarios del la carpeta compartida a nobody y a permisos 777 por si era eso pero sigue sin funcionar nunca, nunca se usa 777, 777 es como para el papa 666, definitivamente algo no muy apreciado, no jhuegues así con los permisos del servidor. saludos epe [root@localhost archivos]# cd archivos/ [root@localhost archivos]# ll total 20 drwxrwxrwx 2 nobody nobody 4096 ene 10 20:30 archivos drwx-- 2 root root 16384 ene 10 19:59 lost+found [root@localhost archivos]# Ojalá que alguíen me pueda hechar una mano gracias a todos César ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Montar disco
debes uasr el mismo smb.conf y agregarle a esta sección archivos: una aclaración, cuando digo el mismo es que sea el mismo original que viene con centos, y sólo agregar la sección que agregaste con las opciones force user y force group -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
[CentOS-es] Sendmail
Hola lista, como le hago para que sendmail no necesite agregar los dominios en el access para permitir enviar correo a dominios no dados de alta?? esto es poco automatizado!! Centos5.4 + sendmail+spamassassin+ mailscanner+clamd Gracias -- -- LCC Felipe Humberto Cabada Arismendiz ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Sendmail
On 01/11/2012 02:50 PM, Felipe Cabada wrote: Hola lista, como le hago para que sendmail no necesite agregar los dominios en el access para permitir enviar correo a dominios no dados de alta?? esto es poco automatizado!! Centos5.4 + sendmail+spamassassin+ mailscanner+clamd Gracias que error precisamente tienes? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
[CentOS-es] Alto puntaje de Spamassassin
saludos lista y feliz año nuevo a todos , estoy medio liado con el spamassassin me esta dando alto puntaje a los correos incluso de mi dominio y de otras personas que anteriormente me enviavan bien y ahora el spamassassin me los cacha miren la cebecera de este mensaje enviado desdi mi propio servidor a la cuenta root o mejor dicho de mi postmaster postmas...@domain.org.ni To: r...@domain.org.ni Yes, score=5.813 tag=-999 tag2=5.2 kill=5.2 tests=[CK_PHISHING_BEGGING=2, KAM_MXURI=2.5, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, URI_HEX=1.313] autolearn=no otro Yes, score=5.623-6.463 tag=-999 tag2=5.2 kill=5.2 tests=[AM:BOOST=-6.463, CK_DIVERS_BODY=5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no From: n...@rootcapital.org To: dgadea dga...@domain.org.ni ahora he estado bajando algunas puntuaciones dentro de 50_scores.cf pero aun asi me los cacha .. alguna idea lista o mejor dicho alguien que me regale algo de su tiempo y me explique algo mas que yo no vea ... no soy tan ducho con el spamassassin ... slsdss -- rickygm http://gnuforever.homelinux.com ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Sendmail
Tengo problemas con un server http que se me esta callendo el servcio pues me esta saliendo este mensage en la consola Out of memory : Killed process (aqui me pone un numerode el pid) httpd y se me para el servicio, posible ataque de DOS, ahora como evitarlo, y saber la procedencia de tantas solicitudes,, que me recomiendan, o es que el server no soporta tantas solicitudes.. saludos delaosa -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/ ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] Sendmail
On 01/11/2012 04:29 PM, test wrote: Tengo problemas con un server http que se me esta callendo el servcio pues me esta saliendo este mensage en la consola oom es cuando se agota la RAM, posiblemente debas tunear un poquito tu apache para que no pase (supongo que tienes una cantidad de ram adecuada para el trabajo que realiza el server), quizá probando bajar la cantidad de hijos limites el problema. mod_evasive puede que te ayude. otra variante es cambiarte a otro tipo de servidor web, por ejemplo lighttpd, nginx o hiawatha, este último es bueno para prevenir ataques de una gran variedad de tipos. saludos epe Out of memory : Killed process (aqui me pone un numerode el pid) httpd y se me para el servicio, posible ataque de DOS, ahora como evitarlo, y saber la procedencia de tantas solicitudes,, que me recomiendan, o es que el server no soporta tantas solicitudes.. saludos delaosa -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/ ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] Centos 6.2 Postfix - forward through SMTP smarthost with SMTP-AUTH
On 11/01/2012 00:31, Mail Lists wrote: On 01/10/2012 05:54 PM, Giles Coochey wrote: Hi All, I have set up three servers in a development environment. Via CR they're updated to Centos 6.2 It appears that these servers have postfix installed on them by default, which unfortunately I'm not very well acquainted with. All I want is a quick and dirty way to enable these hosts to send email through my own SMTP host. My (sendmail) SMTP host uses SMTP AUTH on a non-standard port and my dev (virtual env) runs off my laptop, so a dynamic IP. Does anyone have a quick and dirty configuration for setting up postfix to forward all remote mail through my smarthost? I'm guessing that I can put the hostname, the port, and the username and password somewhere in the postfix configuration and it will just work... /etc/postfix Edit main.cf I would recommend reading up on the configurations . I don't really have the enerygy to do that, thanks anyway. I'll uninstall postfix and use sendmail. Just thought maybe there was a quick way to keep the default MTA on the system. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6.2 Postfix - forward through SMTP smarthost with SMTP-AUTH
On 01/11/12 12:50 AM, Giles Coochey wrote: I don't really have the enerygy to do that, thanks anyway. I'll uninstall postfix and use sendmail. Just thought maybe there was a quick way to keep the default MTA on the system. the first google hit on 'postfix smarthost' says to change/add the line relayhost = your.server.com to the main.cf file, and restart postfix...seems simple enough. this is the 2nd or third hit, it expounds on that and shows how to setup SASL authentication with the smarthost... http://www.cyberciti.biz/faq/postfix-smtp-authentication-for-mail-servers/ -- john r pierceN 37, W 122 santa cruz ca mid-left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6.2 Postfix - forward through SMTP smarthost with SMTP-AUTH
On Wed, January 11, 2012 10:09, John R Pierce wrote: On 01/11/12 12:50 AM, Giles Coochey wrote: I don't really have the enerygy to do that, thanks anyway. I'll uninstall postfix and use sendmail. Just thought maybe there was a quick way to keep the default MTA on the system. the first google hit on 'postfix smarthost' says to change/add the line relayhost = your.server.com to the main.cf file, and restart postfix...seems simple enough. this is the 2nd or third hit, it expounds on that and shows how to setup SASL authentication with the smarthost... http://www.cyberciti.biz/faq/postfix-smtp-authentication-for-mail-servers/ I forgot to mention that I had already googled. My smarthost doesn't use SASL, just STARTTLS - I have tried all those options to no avail.. Perhaps some combination of options might work... but which... I was just hoping someone else had done this before. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/10/2012 12:52 PM, 夜神 岩男 wrote: On 01/11/2012 05:04 AM, Les Mikesell wrote: On Tue, Jan 10, 2012 at 1:46 PM, Daniel J Walshdwa...@redhat.com wrote: On Tue, Jan 10, 2012 at 7:47 AM, Daniel J Walsh dwa...@redhat.com wrote: Now if only more people used RHEL we could further enhance the products. :^) Why isn't it accepted as more of a standard? I don't understand the question. Why is it vendor-specific to RHEL? I was talking Money not vendor specific. The question meant as a jab was if more people used RHEL instead of Centos, we could pay more developers. I thought the @redhat.com would signify why I would want that. :^) OK, I can understand why you would want that. I don't understand why you think anyone else would want even more nonstandard variations in linux distributions. And if this isn't intended to be vendor-specific, why isn't it an independent upstream project or included in the kernel? The logical code to SELinux isn't specific to RH, not by a long shot. (Of course, RH may wind up doing some way un-Unixy/very-vendor-specific things in the near future, but that has nothing to do with SELinux) http://userspace.selinuxproject.org/trac http://www.gentoo.org/proj/en/hardened/selinux/ https://wiki.ubuntu.com/SELinux ... But the difficult thing about SELinux isn't how it works, its the detail required for each policy to wrap each program up correctly without denying useful functionality in the process, not to mention deploying them with packages, and dealing with the whole new universe of inaccurate bug reports SELinux has spawned... *That* is very hard -- and that is what Red Hat has been so good about over the last while. In the process Fedora has spawned a slew of new tools to make SELinux policy easier to deal with -- and in the process of doing that Fedora acquired/affirmed its reputation for eating babies. SElinux exists all over the place, and there are binaries for it in nearly every distro -- but nearly everyone has decided that its too hard so its just a set of accessory packages almost nobody installs, and if installed not activated, and if activated quickly de-activated (the #1 web server fix your frustrations on the web advice for noobs is still disable SELinux, it sux). Honestly, though, at this point the tools really are there. A packager that wants to publish an SELinux policy with his package finds it easy if the tools are understood -- what is really lacking now is just a very public, beginner-friendly introduction to the core concepts of SELinux which includes a nice intro to the somewhat arbitrary jargon that surrounds access policy concepts. Well there is already a beginner-friendly introduction: http://wiki.centos.org/HowTos/SELinux The problem I had with it is that there are several statements that are unclear, missing, or just wrong. That's not necessarily the fault of the author; if I had to write an intro to something that I knew a lot about, I'd probably also make a few statements that were unclear or wrong. The cure for that is to show it to 10 people whose intelligence you are reasonably confident about, but who *don't already know* what the document is trying to teach, and ask them to suggest edits: anything that tells the user to do something without saying how, or is unclear, or doesn't work when they try it. Then when the documentation has been tweaked enough that it no longer has too many of those problem areas, then it's ready. (If I were a volunteer, some of my suggested edits to that page would be: - Near the beginning the doc says the machine should be rebooted and the filesystem relabeled, without telling the user how to actually do that. Have a forward-reference telling the user where to read how to relabel the filesystem. - The sentence about Access is only allowed between similar types is apparently wrong (and meaningless anyway if it doesn't explain what similar types means). I would just go ahead and say that there's no way to know for sure what process types will be allowed to access what file types, and all you can do is make educated guesses based on the similarity of the names, and then look at error logs afterwards to see if you were right. - Explain that files in /tmp/ aren't relabeled after rebooting. (If indeed that is the case. We never did figure out why my /tmp/ files weren't being relabeled.) - The genhomedircon command gives an error if SELinux is enforcing; switch to permissive before running that command. - The doc says httpd runs in the httpd_t security context. This is only true if it's started silently; if the user starts it from the command line, it runs in a different context.) It doesn't take that much work to turn so-so documentation into really useful documentation, but you have to start with the assumption that there is room for improvement. The main obstacle is the attitude of people like John Dennison, who assume the documentation is fine
Re: [CentOS] Centos 6.2 Postfix - forward through SMTP smarthost with SMTP-AUTH
Dear Giles, I think you're searching for this. $ cat /etc/postfix/main.cf myorigin=yourdomain.com relayhost=your.smarthost.com smtp_sasl_auth_enable=yes ## you probably want to limit how postfix authenticates # smtp_sasl_security_options=noanonymous # smtp_sasl_mechanism_filter=login smtp_sasl_password_maps=hash:/etc/postfix/relay_password ## if something doesn't work and you need detailed(!!) logs #debug_peer_list=your.smarthost.com #debug_peer_level=3 smtp_use_tls=yes #inet_interfaces = loopback-only #local_transport = error: disabled unknown_local_recipient_reject_code = 450 $ cat /etc/postfix/relay_password your.smarthost.com yourusername:yourpassword $ postmap /etc/postfix/relay_password $ service postfix reload You can check out the commented option in the man pages or http://www.postfix.org/postconf.5.html if you're interested later/have some spare time/if it doesn't work ;-) Brgds -- Freundliche Gruesse/Best Regards Benjamin Hackl IT/Administration Media FOCUS Research Ges.m.b.H. Maculangasse 8, 1220 Wien Austria Tel: +43 1 258 97 01-295 b.ha...@focusmr.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
Dne 11.1.2012 1:13, email builder napsal(a): Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages. Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-\* dependent file de-compressors Regards, DH ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Building REDHAT Desktop Virtualization Solution With Centos
Redhat offers a desktop virtualization solution using kvm,qemu,libvirt and spice which is directed at centralized server hosting virtual desktops and thin clients connecting to it. All the relevant software are open source. So it should be possible to achieve the same feat with CentOS. Anyone know any complete tutorial regarding this? I've found separate tutorials regarding spice, kvm etc. But a complete tutorial describing how to emulate the Redhat virtualization for Desktops will be very handy. Thanks in advance. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
Rilindo Foster wrote: 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? Avahi is a mdns daemon. You can safely disable it in most cases. But what applications use mdns? As far as I can see, it is some sort of rival to dhcpd. Is it only used within local LANs? Is it used, for example, by CUPS to identify printers? When, if ever, would it be used in a home network? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On 1/11/2012 6:42 AM, Timothy Murphy wrote: Rilindo Foster wrote: 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? Avahi is a mdns daemon. You can safely disable it in most cases. But what applications use mdns? As far as I can see, it is some sort of rival to dhcpd. Is it only used within local LANs? Is it used, for example, by CUPS to identify printers? When, if ever, would it be used in a home network? http://www.google.com/search?sourceid=chromeie=UTF-8q=mdns http://www.google.com/search?sourceid=chromeie=UTF-8q=mdns multicast dns. How it applies to cent though i don't know at this instant. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Building REDHAT Desktop Virtualization Solution With Centos
On 01/11/2012 05:11 AM, Arif Tuhin wrote: Redhat offers a desktop virtualization solution using kvm,qemu,libvirt and spice which is directed at centralized server hosting virtual desktops and thin clients connecting to it. All the relevant software are open source. So it should be possible to achieve the same feat with CentOS. Anyone know any complete tutorial regarding this? I've found separate tutorials regarding spice, kvm etc. But a complete tutorial describing how to emulate the Redhat virtualization for Desktops will be very handy. If you are talking about the RHEV product line, not all of it is open source yet (at least not in the versions for the currently released RHEV line). What is specifically not yet available and/or opensource are all the jboss and maven2 requirements ... at least not the versions that are in RHEV. We are looking into the RHEV packages, and I hear that they plan to release an upgraded version with more of the enterprise package sources available by 2nd quarter 2012. If you want to try early adoption things then this might be for you: http://www.ovirt.org/ If you are only looking for the things that you listed (kvm,qemu,libvirt,spice) those are all in 6.2 right now. But, to answer your question (if it is about RHEV) ... if and when the sources for the enterprise tools of RHEV-H and RHEV-M become available in a ready to build way ... then yes will the CentOS project build them. Here are some other good sources of info on this subject: http://lists.centos.org/pipermail/centos/2009-November/085639.html http://www.linux-kvm.com/content/update-rhev-m-going-open-source signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On 01/11/12 3:47 AM, William Warren wrote: multicast dns. How it applies to cent though i don't know at this instant. its part of multimedia home network plug and play, I believe... lets media boxes find media servers, and such.if you were to serve up streaming media on a home network, it would be a useful thing to have. otherwise? meh. -- john r pierceN 37, W 122 santa cruz ca mid-left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] gabber/jabber for centos 5.7?
I used to use jabber for chats. But I don't find it in centos 5.7 anymore. Is it still around? Or has something else taken its place? What do people using 5.7 use these days? Is there anything which handles MSN? tia. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
On 01/11/2012 04:42 AM, David Hrbáč wrote: Dne 11.1.2012 1:13, email builder napsal(a): Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages. Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-\* dependent file de-compressors Regards, DH I agree with David here ... repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository. If you are going to use rfx packages, you likely need to use all relevant rfx packages and not mix and match (which is what caused this problem). In this case, that would include the whole stack for spamassassin. This DOES replace base CentOS packages ... but that is the purpose of the RFX repo, so don't enable it in the first place if you don't want to replace CentOS packages. And if you DO want to replace CentOS packages, then replace them all for the things you are installing from rfx. A different way to accomplish the same thing without replacing CentOS base packages (if your goal is to prevent replacing base packages ... which may or may not be your goal) is to first try EPEL. EPEL has a version of amavisd-new (for this particular scenario) which works properly with all the base CentOS packages. A goal of EPEL is that they can not replace packages from RHEL (so also not CentOS). But the version of amavisd-new is older in EPEL than the one in RFX. Which is best ... that is up to you. I am not recommending one approach over the other ... which approach you take depends on your goals. Most of the time my personal goals are to stay as close to the enterprise OS as I possibly can and only replace packages if absolutely necessary, so I would likely try EPEL first and go to RFX later. But, I do not know of any packages in RFX that break things, so I think either approach can be equally stable on CentOS servers. The bottom line is that you need to understand what you are trying to accomplish and adjust your strategy as necessary. You need to understand what the goals of a repository is before you enable it (does it replace base packages, do I want to try to block that aspect of the repo, etc) ... and you need to enable it correctly if you intend to use it. For RFX (as an example)... if you enable things like yum-priorities (which will always choose base/updates from CentOS over newer packages from RFX), that is going to cause issues where some packages from RFX may not work properly with the base CentOS packages. Adding 3rd party repos is complicated and if you do it, you need to pay close attention to what each one does and enable it properly. You can't expect 3rd party repos to support using only parts of the repo and not others (ie, yum-priorities) ... but you also can't expect CentOS to support the packages installed by the 3rd party repos that replace base packages. Therefore, YOU have to support yourself if you add them :D signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gabber/jabber for centos 5.7?
On 01/11/2012 06:45 AM, ken wrote: I used to use jabber for chats. But I don't find it in centos 5.7 anymore. Is it still around? Or has something else taken its place? What do people using 5.7 use these days? Is there anything which handles MSN? tia. Pidgin is the IM client included in CentOS ... I think it supports MSN and Yahoo chats. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 01/11/2012 11:07 AM, Les Mikesell wrote: On Tue, Jan 10, 2012 at 3:50 PM, Daniel J Walshdwa...@redhat.com wrote: That is not the way it works. SELinux Reference policy is a database of rules that govern the default ways application run. Yes, but it is application developers that know what their applications need to do. Is there a way for them to express that? This gets back to the core problem of people often just not learning SELinux in the first place. Its not RH or Fedora's problem if upstream developers trying to port Windows apps to Fedora dont, for example, understand Unix permissions. Various distros deal with such problems in various ways. This family's response was to write troubleshooting tools, start writing docs and get packagers on-board with it -- other distros' responses varied but tended toward scary, this thing... let's just quietly include binaries but not turn the scary spinning thing on... heaven forbid we learn anything new These rules that have been written for Fedora/RHEL are public and are being moved upstream. There has to be a better approach than letting the Fedora guys second-guess where application components should live, then second-guess what the application needs to do. In fact, that sounds like a recipe for years of problems for everyone who uses the results. Honestly, SELinux is far less of a complication -- be it within a distro or across the Unixcape (new word?) -- than the current proliferation of different init subsystems. There is, for example, no tool that can even give you reasonable hints to get your daemons from SysV to Upstart to Systemd. Trying just to package for Upstart between distros can be a nightmare. SELinux is, by comparison, far easier to develop a basic, reasonably sane (if not as tight as could be) policy to distribute per package. Different Distributions can choose to use these policies or write there own. So after the Fedora version of second-guessing, that gets pushed off to other distributions to likely make it even worse? I'm assuming this is a joke. Fedora already ate (almost) all the babies. Seriously. I lived through it and now I find SELinux a breeze, and audit2allow is *really* quite a livable tool to work with. You're talking like other distro's burden somehow belongs to Fedora. Fedora's burdens aren't even RH's problem -- RH only picks what it finds as useful for its customer base out of Fedora, and SELinux is very high on the list of incredibly useful things. But just like PostgreSQL, Sendmail, Apache2, Bash, Awk, Sed (the list is long) all the really powerful stuff, new or old, requires some study. You're expecting to get a system-wide mandatory access control policy system across every distro based solely on Fedora's efforts (as if Fedora is actively pushing SELinux to other distros) without the users/sysadmins needing to do some reading? When was the last time you ever heard of a safe, secure, all-encompassing web (or otherwise) CMS, for example, that didn't require at least some configuration and knowhow? Out of the Reference Policy you can build your own version of targeted or MLS policy or you can write your policy from scratch. But is there a way that these can originate from the group that manages the application, and appear automatically as a result in distributions that include the application or if you compile from the source distribution? Upstream projects can certainly assist enormously by learning about SELinux and writing guidelines ahead of time, and some of the larger projects have such people (Postgres is a good example of this), but just like startup scripts, installation, linking, $PATH-related and compile-time library linking decisions SELinux policy is *heavily* the responsibility of the packager/distro maintainer, *not* the upstream itself. Each distro has its own quirks and nearly every package on every system has to work around these as constraints. SELinux policy is not the hardest thing a packager has to deal with, IMO. Its one of those things that if a project has sane guidelines to cover (which many, perhaps most, distros lack on for many things) is not too hard to deal with, but must be learned through experience at play and study, just like RPM. The place that SELinux breaks applications is when an application does something that SELinux did not expect. Well, of course. The issue is how SELinux is supposed to learn from the person who does know what the application is going to do. I don't run an OS distribution to what a distribution does, I run it so it does what the application is supposed to do. That is, the application is the point, not what SELinux guesses it was supposed to do. That's what the auditing tools can help you out with. Outside of that, you're asking for Microsoft-style defaults, which is ridiculous. There is no way, for example, that you could consider it a sane default to permit
Re: [CentOS] Upgrade Question
On 01/10/2012 12:55 PM, Gene Poole wrote: We've got about 200 existing servers running CentOS/RHEL 5.6 and all new servers are being provisioned using CentOS/RHEL 6.1. So that everything is consistent we need to upgrade the servers running CentOS/RHEL 5.6. I've searched the CentOS wiki, the Red Hat site, and the internet looking for something official on upgrading/migrating from CentOS/RHEL 5.x to CentOS/RHEL 6.x. There's got to be a way other than having 2 times hardware. Any ideas??? Note, it does not take 2x the hardware ... you only need 1 extra machine to convert 1 server at a time from 5.x to 6.x and when you get done, use that do the next one. You can do more than one on a machine with VMs as well (or as suggested, backup, format and bring on data, reconfigure) You CAN (unsupported :D) also use a 6.x disc and run an upgrade over top the old machine. (It should offer that as an option for the install). But RH does not recommend or support upgrades done that way if using RHEL, so use at your own risk. Also please understand that things are not going to just work after an upgrade from CentOS 5.x to 6.x. For example, if you have php based websites using php-5.1.6-x in CentOS-5, you are likely going to have issues running them on php-5.3.x in CentOS-6. The bottom line is that CentOS provides 7 years of support, but moving between major versions requires that you reconfigure everything. You can still get support for CentOS-5.x through 31 Mar 2014, so you have time before you need to move those 5.x servers to 6.x. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 01/11/2012 03:07 AM, Les Mikesell wrote: On Tue, Jan 10, 2012 at 3:50 PM, Daniel J Walshdwa...@redhat.com wrote: That is not the way it works. SELinux Reference policy is a database of rules that govern the default ways application run. Yes, but it is application developers that know what their applications need to do. Is there a way for them to express that? These rules that have been written for Fedora/RHEL are public and are being moved upstream. There has to be a better approach than letting the Fedora guys second-guess where application components should live, then second-guess what the application needs to do. In fact, that sounds like a recipe for years of problems for everyone who uses the results. Different Distributions can choose to use these policies or write there own. So after the Fedora version of second-guessing, that gets pushed off to other distributions to likely make it even worse? Other distros use those policies as an template and customize them if necessary. Out of the Reference Policy you can build your own version of targeted or MLS policy or you can write your policy from scratch. But is there a way that these can originate from the group that manages the application, and appear automatically as a result in distributions that include the application or if you compile from the source distribution? There are distributions that do not even have /proc. There are meny differences where things are placed between Debian-like and Fedora-like distros. But in all cases/distro's you have a designated package maintainer that knows what needs to be done, and probably already has patches prepared. App developers only need to know to code/develop the app, why burden them with knowledge about every single distro difference? And what about if a distro decides to change something inside the distro? Every single Linux developer in the world has to be notified and learn about the new way? The place that SELinux breaks applications is when an application does something that SELinux did not expect. This can not happen with packages of apps prepared by Fedora developers. They know where to put stuff, and they also maintain SELinux policies. Problem arises with third-party packed apps or install from source. Well, of course. The issue is how SELinux is supposed to learn from the person who does know what the application is going to do. I don't run an OS distribution to what a distribution does, I run it so it does what the application is supposed to do. That is, the application is the point, not what SELinux guesses it was supposed to do. I wrote a paper and presentation on the four main causes of SELinux issues. http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_four_things.pdf Don't these all boil done to SELinux not understanding the application's needs? SELinux is basically a police officer. So what about people flying by plane that need some medicine that can be confiscated by airport authorities on both airports/countries? They also do not know your need and need to be explained, right? -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
Johnny Hughes wrote: On 01/11/2012 04:42 AM, David Hrbáč wrote: Dne 11.1.2012 1:13, email builder napsal(a): Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages. Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-\* dependent file de-compressors Regards, DH I agree with David here ... repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository. the problem in this case is that perl-NetAddr-IP from repoforge should be in RFX, but it isn't. But it's really for historical reasons: perl-NetAddr-IP was only added to base in 5.7. So now that it's in base it has to move from rf to rfx, and it just hasn't done so yet. But the move from rf to rfx doesn't fundamentally change things, there's no magic solution here: in any case, if a user had the RF perl-NetAddr-IP installed prior to 5.7 (perfectly legitimate), and decides to install spamassassin today (pulling it from base since it's there, this is legit and standard practice as well), s/he will have the OP's issue. Having the package tagged RFX will simply make it easier to identify the problem. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
William Warren wrote: Avahi is a mdns daemon. You can safely disable it in most cases. But what applications use mdns? As far as I can see, it is some sort of rival to dhcpd. Is it only used within local LANs? Is it used, for example, by CUPS to identify printers? When, if ever, would it be used in a home network? http://www.google.com/search?sourceid=chromeie=UTF-8q=mdns http://www.google.com/search?sourceid=chromeie=UTF-8q=mdns I had looked up mdns on google, which is what you seem to be suggesting. But it did not give me an answer to my query above. Which URL did you think answered this? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
Timothy Murphy wrote: William Warren wrote: Avahi is a mdns daemon. You can safely disable it in most cases. But what applications use mdns? As far as I can see, it is some sort of rival to dhcpd. Is it only used within local LANs? Is it used, for example, by CUPS to identify printers? When, if ever, would it be used in a home network? http://www.google.com/search?sourceid=chromeie=UTF-8q=mdns http://www.google.com/search?sourceid=chromeie=UTF-8q=mdns I had looked up mdns on google, which is what you seem to be suggesting. But it did not give me an answer to my query above. Which URL did you think answered this? maybe this: http://en.wikipedia.org/wiki/Zero_configuration_networking ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 01/11/2012 07:19 PM, Bennett Haselton wrote: Well there is already a beginner-friendly introduction: http://wiki.centos.org/HowTos/SELinux The problem I had with it is that there are several statements that are unclear, missing, or just wrong. That's not necessarily the fault of the author; if I had to write an intro to something that I knew a lot about, I'd probably also make a few statements that were unclear or wrong. Tell me about it. I constantly find myself really great at writing docs for systems that the audience is already expert in, but somewhat lacking on writing it for complete beginners. Really, the principal problem is one of prereqs. Teaching people on this list about SELinux is a lot easier than teaching professional diesel mechanics about it, and a bit harder than teaching a certain breed of security researchers about it. So at what level is appropriate to begin the explanation? This is tricky. The cure for that is to show it to 10 people whose intelligence you are reasonably confident about, but who *don't already know* what the document is trying to teach, and ask them to suggest edits: anything that tells the user to do something without saying how, or is unclear, or doesn't work when they try it. Then when the documentation has been tweaked enough that it no longer has too many of those problem areas, then it's ready. This is sounds very much the way open source development works. And its the process you're engaging in, actually. See below... (If I were a volunteer, some of my suggested edits to that page would be: - Near the beginning the doc says the machine should be rebooted and the filesystem relabeled, without telling the user how to actually do that. Have a forward-reference telling the user where to read how to relabel the filesystem. - The sentence about Access is only allowed between similar types is apparently wrong (and meaningless anyway if it doesn't explain what similar types means). I would just go ahead and say that there's no way to know for sure what process types will be allowed to access what file types, and all you can do is make educated guesses based on the similarity of the names, and then look at error logs afterwards to see if you were right. - Explain that files in /tmp/ aren't relabeled after rebooting. (If indeed that is the case. We never did figure out why my /tmp/ files weren't being relabeled.) - The genhomedircon command gives an error if SELinux is enforcing; switch to permissive before running that command. - The doc says httpd runs in the httpd_t security context. This is only true if it's started silently; if the user starts it from the command line, it runs in a different context.) And you should *really* cc this bit to the author. Anyway, you said it is a wiki -- so why don't you get to wikifying instead of writing on a mailinglist? That's the heart of the process! This is a system under development, and as such needs your help. How great would it be for you to document your trouble spots in learning and contribute that back? Most of the best tutorials on the web started that way -- as a how to learn how to learn systemX based on my personal experience type of document. A roadmap for learning is never more accurate than the one written by a learner himself. There is a secondary benefit to this -- it forces you as a learner to really understand your subject, which makes the learning more complete for you. Its a win-win, give it a spin! If nobody did that we wouldn't even have a kernel, by the way... It doesn't take that much work to turn so-so documentation into really useful documentation, but you have to start with the assumption that there is room for improvement. The main obstacle is the attitude of people like John Dennison, who assume the documentation is fine the way it is, and that any problems are therefore the fault of the user: If people would bother to spend some time _reading_ _documentation_ on the systems they are attempting to admin they might find that subsystems such as selinux aren't quite as complex as they make them out to be... Blaming selinux itself for creating what you perceive as a problem because you won't make a rudimentary attempt at learning to properly manage it is ludicrous. (Even though it subsequently came out that I was in fact following the instructions on the wiki, and there were steps missing in the instructions.) He's right in principle, if not in detail. You're right in principle, but you're also correct in the specific detail of practice as things stand right now. Every system we use is a moving target. JD was probably dead-on correct a few months ago. Things have changed, and the documentation likely doesn't take into account the specific version of the distro you're running, so some things could be missing. This happens a LOT, and its not really anyone's fault, per se -- that is entirely the wrong way of looking at it,
Re: [CentOS] gabber/jabber for centos 5.7?
On 01/11/2012 01:52 PM, Johnny Hughes wrote: On 01/11/2012 06:45 AM, ken wrote: I used to use jabber for chats. But I don't find it in centos 5.7 anymore. Is it still around? Or has something else taken its place? What do people using 5.7 use these days? Is there anything which handles MSN? tia. Pidgin is the IM client included in CentOS ... I think it supports MSN and Yahoo chats. It supports 18 protocols, even facebook chat (plugin maybe) Jabber is actually Google Talk/Jabber/XMPP protocol, just with different servers. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
John R Pierce wrote: its part of multimedia home network plug and play, I believe... lets media boxes find media servers, and such.if you were to serve up streaming media on a home network, it would be a useful thing to have. otherwise? meh. Could you give a concrete example of such a setup, please? I must admit I'm rather confused by UPnP. Is it intended for devices that don't have an IP address? Or how does it fit in with dhcpd? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College Dublin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On Wed, Jan 11, 2012 at 7:40 AM, Timothy Murphy gayle...@eircom.net wrote: John R Pierce wrote: its part of multimedia home network plug and play, I believe... lets media boxes find media servers, and such. if you were to serve up streaming media on a home network, it would be a useful thing to have. otherwise? meh. Could you give a concrete example of such a setup, please? I must admit I'm rather confused by UPnP. Is it intended for devices that don't have an IP address? Or how does it fit in with dhcpd? It is for devices with IP, but to find names that aren't officially registered in a DNS server. For example if you have a Playstation 3, or a newer blu-ray player that supports network streaming it will use DHCP to get an address. But then suppose you install your own DLNA media server like ps3mediaserver (or have windows 7 home premium which includes one). Without registering your new server name in DNS, the device will be able to find the service if it is on the same lan. I think Macs use it to find printers too. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 1/11/2012 5:32 AM, 夜神 岩男 wrote: On 01/11/2012 07:19 PM, Bennett Haselton wrote: Well there is already a beginner-friendly introduction: http://wiki.centos.org/HowTos/SELinux The problem I had with it is that there are several statements that are unclear, missing, or just wrong. That's not necessarily the fault of the author; if I had to write an intro to something that I knew a lot about, I'd probably also make a few statements that were unclear or wrong. Tell me about it. I constantly find myself really great at writing docs for systems that the audience is already expert in, but somewhat lacking on writing it for complete beginners. Really, the principal problem is one of prereqs. Teaching people on this list about SELinux is a lot easier than teaching professional diesel mechanics about it, and a bit harder than teaching a certain breed of security researchers about it. So at what level is appropriate to begin the explanation? This is tricky. I agree that's always a tricky question, but I think the problem here was that even if you knew a lot about Linux but just happened to be unfamiliar with SELinux, the documentation was still incorrect in ways that the reader wouldn't be able to figure out on their own. When the doc says Access is only allowed between similar types, you can't make head or tail of that unless you already know what it means. The cure for that is to show it to 10 people whose intelligence you are reasonably confident about, but who *don't already know* what the document is trying to teach, and ask them to suggest edits: anything that tells the user to do something without saying how, or is unclear, or doesn't work when they try it. Then when the documentation has been tweaked enough that it no longer has too many of those problem areas, then it's ready. This is sounds very much the way open source development works. And its the process you're engaging in, actually. See below... Yes, for software. But I've never heard of it being done for documentation. I suspect this is for two reasons: (1) if software fails, the dev does has to bite the bullet and make it work, but if documentation fails, it's easy to blame the user (reader); (2) to get help testing your software, you can stay within the community of people who helped right it or those closely connected to them, but to get help testing documentation, you have to reach out to people far removed from your inner circle. (Plus, in theory you can only test the document on a single person one time. You can't use them to test future iterations of the same document, because then they might incorrectly report that the document is getting clearer when really their understanding is just becoming clearer from multiple readings and back-and-forth with the authors.) (If I were a volunteer, some of my suggested edits to that page would be: - Near the beginning the doc says the machine should be rebooted and the filesystem relabeled, without telling the user how to actually do that. Have a forward-reference telling the user where to read how to relabel the filesystem. - The sentence about Access is only allowed between similar types is apparently wrong (and meaningless anyway if it doesn't explain what similar types means). I would just go ahead and say that there's no way to know for sure what process types will be allowed to access what file types, and all you can do is make educated guesses based on the similarity of the names, and then look at error logs afterwards to see if you were right. - Explain that files in /tmp/ aren't relabeled after rebooting. (If indeed that is the case. We never did figure out why my /tmp/ files weren't being relabeled.) - The genhomedircon command gives an error if SELinux is enforcing; switch to permissive before running that command. - The doc says httpd runs in the httpd_t security context. This is only true if it's started silently; if the user starts it from the command line, it runs in a different context.) And you should *really* cc this bit to the author. Anyway, you said it is a wiki -- so why don't you get to wikifying instead of writing on a mailinglist? That's the heart of the process! This is a system under development, and as such needs your help. How great would it be for you to document your trouble spots in learning and contribute that back? I wasn't going to get into this, but... I did find the wiki contact page, and join their e-mail list, and post to the list asking to create an edit account so that I could make an edit (for starters, after the sentence about you should re-label the file system, I was going to add a link to the steps on how to do that). I got one reply, replied to that, and the thread went dead. Here it is: http://lists.centos.org/pipermail/centos-docs/2012-January/thread.html Now, I understand if I kept bugging them, they might get back to me, and maybe my precious edit would actually happen. I think
[CentOS] EPEL not working ... is it just me?
This is very strange - has been happening the last few days. I just upgraded this system from 5.3 to 5.7 on Monday and the problem started some time after that (but not immediately because I know I used yum Monday evening after the upgrade) I get the following error from yum, but it goes away if I --disablerepo=epel The funny thing is that the listed xml file I can easily wget from this system. Also having the issue with other 5.7 systems that were upgraded from 5.3 several weeks ago and had been working fine since. I did some googling and found some things to try like yum clean all and I even deleted the rpm database based on advice from one site, and then rebuilt it from scratch. But nothing. [root@solexa-db varlog]# yum -y install hddtemp Loaded plugins: downloadonly, rhnplugin, security http://fedora.mirror.nexicom.net/epel/5/x86_64/repodata/repomd.xml: [Errno 4] IOError: urlopen error (111, 'Connection refused') Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: epel. Please verify its path and try again -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of In Defense of Food ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages. Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-\* dependent file de-compressors Regards, DH I agree with David here ... repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository. If you are going to use rfx packages, you likely need to use all relevant rfx packages and not mix and match (which is what caused this problem). In this case, that would include the whole stack for spamassassin. This DOES replace base CentOS packages ... but that is the purpose of the RFX repo, so don't enable it in the first place if you don't want to replace CentOS packages. And if you DO want to replace CentOS packages, then replace them all for the things you are installing from rfx. A different way to accomplish the same thing without replacing CentOS base packages (if your goal is to prevent replacing base packages ... which may or may not be your goal) is to first try EPEL. EPEL has a version of amavisd-new (for this particular scenario) which works properly with all the base CentOS packages. A goal of EPEL is that they can not replace packages from RHEL (so also not CentOS). But the version of amavisd-new is older in EPEL than the one in RFX. Which is best ... that is up to you. I am not recommending one approach over the other ... which approach you take depends on your goals. Most of the time my personal goals are to stay as close to the enterprise OS as I possibly can and only replace packages if absolutely necessary, so I would likely try EPEL first and go to RFX later. But, I do not know of any packages in RFX that break things, so I think either approach can be equally stable on CentOS servers. I don't 100% understand your explanation of EPEL, but I'm definitely going to go learn about it. The bottom line is that you need to understand what you are trying to accomplish and adjust your strategy as necessary. You need to understand what the goals of a repository is before you enable it (does it replace base packages, do I want to try to block that aspect of the repo, etc) ... and you need to enable it correctly if you intend to use it. For RFX (as an example)... if you enable things like yum-priorities (which will always choose base/updates from CentOS over newer packages from RFX), that is going to cause issues where some packages from RFX may not work properly with the base CentOS packages. Adding 3rd party repos is complicated and if you do it, you need to pay close attention to what each one does and enable it properly. You can't expect 3rd party repos to support using only parts of the repo and not others (ie, yum-priorities) ... but you also can't expect CentOS to support the packages installed by the 3rd party repos that replace base packages. Therefore, YOU have to support yourself if you add them :D I understand this in principle, but I think reality ends up being a little more difficult. I think I ended up with what RepoForge packages I did because at the time I built the server, CentOS either didn't have amavisd-new at all or RepoForge's was newer and without knowing about yum-priorities, I got the RepoForge one (and a bunch of other dependencies) without really understanding the implications (I had enabled RepoForge to get a version of Postfix that wasn't horribly crippled, although at this point both RepoForge and CentOS's versions of postfix are deplorably ancient - compiling by hand may be in order). So I could have been better educated for sure, but the way it plays out also isn't going to be straight forward in a lot of cases I think. Maybe RepoForge should make it more clear on their site what the implications of using their packages are or that users may want to use yum-priorities for a better chance of avoiding problems. I certainly would have thought twice if their site had warned me of possible problems
Re: [CentOS] sa-update error with perl
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not. Maybe Daniel could move it, which would definitely help my yum to stop complaining David not Daniel. My apologies missing your name. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Tuesday, January 10, 2012 04:38:27 PM Les Mikesell wrote: But the hardest part is that these things are application specific and there is no standardization for locations where applications do things. In fact, distributions intentionally move those locations around in their packaging. Good morning, Les. Distribution differences are the price we pay for choice. Distributions are (and should be) free to put things where they see fit. Each major distribution I've looked at has had good reasons for the different choices that they have made. That reputation is well deserved. Would it not have made sense to have the needed diagnostic tools before shipping the thing that needs it? No, it wouldn't have. With open source being a 'scratch your own itch' thing, and with Fedora well-placed in the 'hobbyist/enthusiast/not a normal user' domain, this somewhat 'forces' the issue of getting things fixed. Otherwise things would likely not have been fixed at all. And wouldn't it have been a good idea to have the documentation before turning on something non-standard that breaks things? If Fedora were a commercial product, sure. It isn't; documentation follows code in open source, full stop. Whether that's the way it should be or not, it is the way it is, and I for one prefer true developer freedom to choose the way to develop. If an open source development group wants to write docs first, and then implement, they have the freedom to do so. If a development group doesn't want to write any documentation at all, but just hand out the source, then that development group has the freedom to do so (and users have the freedom to use or not use that software). Companies wanting to productize open source should do their homework and write their own docs; Red Hat for one has done that, and the docs are quite good. Yeah, the whole idea seems like what a car company would have to do to come back after selling a model that gets a lot of publicity for crashing and burning. The earlier opinions weren't wrong, after all. You have the wrong analogy. Linux today is in a state quite similar to the state of the automotive industry before Henry Ford. Every car was unique, parts didn't interchange, roads were a mess, and people as hobbyists/enthusiasts built their oen cars (not from kit parts like most of today's auto enthusiasts) from scratch. Or the days of airplanes prior to World War I. Things did crash and burn, and it was an enthusiast's world. And thus far no one of whom I am aware has died due to an SELinux problem. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] EPEL not working ... is it just me?
-Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Alan McKay Sent: Wednesday, January 11, 2012 9:36 To: CentOS mailing list Subject: [CentOS] EPEL not working ... is it just me? This is very strange - has been happening the last few days. I just upgraded this system from 5.3 to 5.7 on Monday and the problem started some time after that (but not immediately because I know I used yum Monday evening after the upgrade) I get the following error from yum, but it goes away if I -- disablerepo=epel The funny thing is that the listed xml file I can easily wget from this system. You mean in the terminal on solexa-db you just issued the yum install in, you can issue as the next command wget http://fedora.mirror.nexicom.net/epel/5/x86_64/repodata/repomd.xml and it gets the xml file? Also having the issue with other 5.7 systems that were upgraded from 5.3 several weeks ago and had been working fine since. SNIP yum and rpm cleans [root@solexa-db varlog]# yum -y install hddtemp Loaded plugins: downloadonly, rhnplugin, security http://fedora.mirror.nexicom.net/epel/5/x86_64/repodata/repomd.xml: [Errno 4] IOError: urlopen error (111, 'Connection refused') Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: epel. Please verify its path and try again It seems a bit strange to me that there is only one mirror tried... As a quick temporary fix/test I would comment mirrorlist and uncomment baseurl in epel.repo and see if the yum command worked. BTW it seems solexa-db may be a RH machine instead of a CentOS machine. see the rhnplugin get loaded? Could that be a difference between the working and non working machines (granted I have not seen any problems with RH machines and epel)? I think it might be good to take this question over to epel-devel (AFAIK the appropriate list) and see if they can help figure out why you are having trouble with THEIR infrastructure. https://www.redhat.com/mailman/listinfo/epel-devel-list ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Write to USB pendrives horribly slow
On 01/11/2012 08:45 AM, wwp wrote: Hello John, On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doejd...@yahoo.com wrote: From: wwpsubscr...@free.fr I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here. I guess it is to be safe in case users remove their usb keys without unmounting first... OK, meaning no write-cache for those devices, makes sense in some way. But this doesn't explain the main issue I reported, although I didn't find a way to change the default mount options used by Gnome (gconf settings don't match those that are used). Do you have ehci_hcd module running? Do you have any error messages in dmesg after you plug it in? -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] EPEL not working ... is it just me?
You mean in the terminal on solexa-db you just issued the yum install in, you can issue as the next command wget http://fedora.mirror.nexicom.net/epel/5/x86_64/repodata/repomd.xml and it gets the xml file? Yup, exactly As a quick temporary fix/test I would comment mirrorlist and uncomment baseurl in epel.repo and see if the yum command worked. Yup, tried that BTW it seems solexa-db may be a RH machine instead of a CentOS machine. see the rhnplugin get loaded? Could that be a difference between the working and non working machines (granted I have not seen any problems with RH machines and epel)? Yes it is RHEL. I have a mixture of RHEL, CentOS and Scientific and tend to treat them all the same - so sorry that it is technically OT for this list. But you guys (and gals) are just too good :-) I think it might be good to take this question over to epel-devel (AFAIK the appropriate list) and see if they can help figure out why you are having trouble with THEIR infrastructure. https://www.redhat.com/mailman/listinfo/epel-devel-list I'll do that - thanks. -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of In Defense of Food ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
On 01/11/2012 08:42 AM, email builder wrote: Well, kind of. If you review this thread, you'll see that the the fix was to stop using the RepoForge package for perl-NetAddr-IP so that it wasn't mixed with CentOS packages for perl-Net-DNS and perl-IO-Socket-INET6. Maybe your position is that you won't fix perl-NetAddr-IP because you only support it when used when all other packages are from RepoForge, but I don't think that's realistic at all - everyone running CentOS will have mostly CentOS packages - naturally. They'll pick up some others they want or need for various reasons from RepoForge, so I'd imagine you'll see mixing of packages quite often amongst people who add RepoForge to their yum systems. Therefore, I'd have thought you'd be interested to learn of an incompatibility in one of the RepoForge packages. Well, I will definitely not fix it. Most of users does not pick up the particular packages but enables the repo entity. Basically it would be really hard to support both scenarios. I consider packages you mention as a whole email stack provided by RF. The stack includes: amavisd-new spamassassin dependent perl-\* dependent file de-compressors Regards, DH I agree with David here ... repoforge has moved all packages that replace CentOS base packages to their rfx (repoforge extras) repository. If you are going to use rfx packages, you likely need to use all relevant rfx packages and not mix and match (which is what caused this problem). In this case, that would include the whole stack for spamassassin. This DOES replace base CentOS packages ... but that is the purpose of the RFX repo, so don't enable it in the first place if you don't want to replace CentOS packages. And if you DO want to replace CentOS packages, then replace them all for the things you are installing from rfx. A different way to accomplish the same thing without replacing CentOS base packages (if your goal is to prevent replacing base packages ... which may or may not be your goal) is to first try EPEL. EPEL has a version of amavisd-new (for this particular scenario) which works properly with all the base CentOS packages. A goal of EPEL is that they can not replace packages from RHEL (so also not CentOS). But the version of amavisd-new is older in EPEL than the one in RFX. Which is best ... that is up to you. I am not recommending one approach over the other ... which approach you take depends on your goals. Most of the time my personal goals are to stay as close to the enterprise OS as I possibly can and only replace packages if absolutely necessary, so I would likely try EPEL first and go to RFX later. But, I do not know of any packages in RFX that break things, so I think either approach can be equally stable on CentOS servers. I don't 100% understand your explanation of EPEL, but I'm definitely going to go learn about it. The bottom line is that you need to understand what you are trying to accomplish and adjust your strategy as necessary. You need to understand what the goals of a repository is before you enable it (does it replace base packages, do I want to try to block that aspect of the repo, etc) ... and you need to enable it correctly if you intend to use it. For RFX (as an example)... if you enable things like yum-priorities (which will always choose base/updates from CentOS over newer packages from RFX), that is going to cause issues where some packages from RFX may not work properly with the base CentOS packages. Adding 3rd party repos is complicated and if you do it, you need to pay close attention to what each one does and enable it properly. You can't expect 3rd party repos to support using only parts of the repo and not others (ie, yum-priorities) ... but you also can't expect CentOS to support the packages installed by the 3rd party repos that replace base packages. Therefore, YOU have to support yourself if you add them :D I understand this in principle, but I think reality ends up being a little more difficult. I think I ended up with what RepoForge packages I did because at the time I built the server, CentOS either didn't have amavisd-new at all or RepoForge's was newer and without knowing about yum-priorities, I got the RepoForge one (and a bunch of other dependencies) without really understanding the implications (I had enabled RepoForge to get a version of Postfix that wasn't horribly crippled, although at this point both RepoForge and CentOS's versions of postfix are deplorably ancient - compiling by hand may be in order). So I could have been better educated for sure, but the way it plays out also isn't going to be straight forward in a lot of cases I think. Maybe RepoForge should make it more clear on their site what the implications of using their packages are or that users may want to use yum-priorities for a better chance of avoiding problems. I certainly would have thought
Re: [CentOS] sa-update error with perl
Johnny Hughes wrote: On 01/11/2012 08:42 AM, email builder wrote: And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not.Maybe Daniel could move it, which would definitely help my yum to stop complaining It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF. http://apt.sw.be/redhat/el6/en/x86_64/ (there is a repoforge and and extras dir under there) it's in RFX for el6, but not for el5 which we were talking about ;-) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not. Maybe Daniel could move it, which would definitely help my yum to stop complaining It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF. http://apt.sw.be/redhat/el6/en/x86_64/ (there is a repoforge and and extras dir under there) I'm on a 32 bit machine, not sure if that makes a difference. What I do know is this: yum update == Package Arch Version Repository Size == Updating: perl-NetAddr-IP i386 4.044-1.el5.rf rpmforge 140 k Transaction Summary == Install 0 Package(s) Upgrade 1 Package(s) Is this because I need to migrate something from rpmforge to RepoForge??? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
On 01/11/2012 09:59 AM, Nicolas Thierry-Mieg wrote: Johnny Hughes wrote: On 01/11/2012 08:42 AM, email builder wrote: And then there's the problem Nicolas is pointing out, which seems to be part of my problem. If such conflicting packages are supposed to be in rfx but are not.Maybe Daniel could move it, which would definitely help my yum to stop complaining It is now part of RFX and not part of RF. If you look here, you will see no perl-NetAddr-IP now in RF. http://apt.sw.be/redhat/el6/en/x86_64/ (there is a repoforge and and extras dir under there) it's in RFX for el6, but not for el5 which we were talking about ;-) OK ... then it ought to move (probably) :) signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wed, Jan 11, 2012 at 9:15 AM, Lamar Owen lo...@pari.edu wrote: On Tuesday, January 10, 2012 04:38:27 PM Les Mikesell wrote: But the hardest part is that these things are application specific and there is no standardization for locations where applications do things. In fact, distributions intentionally move those locations around in their packaging. Good morning, Les. Distribution differences are the price we pay for choice. Distributions are (and should be) free to put things where they see fit. Each major distribution I've looked at has had good reasons for the different choices that they have made. If the first thing you saw on a unix-like system was the horror of autoconf, would you have taken a second look? This is an even worse situation, because there is no equivalent way to describe what you want across flavors. I'm not saying that distribution packagers shouldn't be free to break whatever applications they want, and that sysadmins shouldn't be allowed to break even more, I'm saying it would be better if that didn't happen because they didn't understand what the application writer intended. How is the application developer (unquestionably the expert on the application needs) supposed to describe those needs to SELinux in a way that can work across distributions without 'less-expert' people guessing about them? You have the wrong analogy. Linux today is in a state quite similar to the state of the automotive industry before Henry Ford. Every car was unique, parts didn't interchange, roads were a mess, and people as hobbyists/enthusiasts built their oen cars (not from kit parts like most of today's auto enthusiasts) from scratch. Or the days of airplanes prior to World War I. Things did crash and burn, and it was an enthusiast's world. I guess you are right about the state of the art and that it is as wrong to expect things to work as it was to expect flying cars by now. But it would have been fun. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] with Centos6 i cant Partition on 3TB Disks, problem
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 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wednesday, January 11, 2012 10:47:44 AM m.r...@5-cent.us wrote: I'll have to disagree, Lamar. There *are* large distros: RH its derivatives, SuSE, and Debian its derivatives (i.e., Ubuntu), and though there are kit distros (fedora?), they're more like the Big Three automakers of the US, and I can't think of frequent crashburn reports. In terms of commercial distributions, I see more of an analogy to REO, Hupmobile, Duesenburg, and Studebaker than the current large automakers. The history of automobiles and auto manufacturers is educational, even to the 'patent wars' going on (like the Selden two-stroke patent that was overturned in 1911). Using the auto analogy, I would compare the current state of open source OS's to the dawn of the 'Brass' Age of autos. (We're past the 'veteran' stage, which started roughly about the time Red Hat and SuSE started their respective Enterprise Linux distributions, IMO; prior to that it was most definitely an enthusiast's world). ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] A silly question about getting access to webapp installed with yum
Greetings, I have helped host a few applications such as GLPI, OCSInventory, etc etc. using the tarball method and untarring them in /var/www/htom directory. I have never done them though using yum. I was trying to install Trac, Bugzilla etc using yum install method on a Centos 6.2 box. Somehow I am not able to see the respective pages say even using http://localhost/trac or http://localhost/bugzilla Now comes the elementary and stupid question: Now where do these stuff get installed? they are not under /var/www/html I did find some under /usr/share Any pointers to instantiate them? I am not good at understanding what that beast of yum does as to post install script. Though I have created a mysql with CSV and blackhole engines about a year back and as I did it for a client of the company where I worked then and cannot have my grubby hands on that script. Any help appreciated. TIA -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wed, Jan 11, 2012 at 10:53 AM, Lamar Owen lo...@pari.edu wrote: On Wednesday, January 11, 2012 10:47:44 AM m.r...@5-cent.us wrote: I'll have to disagree, Lamar. There *are* large distros: RH its derivatives, SuSE, and Debian its derivatives (i.e., Ubuntu), and though there are kit distros (fedora?), they're more like the Big Three automakers of the US, and I can't think of frequent crashburn reports. In terms of commercial distributions, I see more of an analogy to REO, Hupmobile, Duesenburg, and Studebaker than the current large automakers. I was thinking more of Ford getting people to forget about the Pinto - which I think they have done fairly successfully although it may just have to do with aging memory. Let's see, that was around 1980. Maybe I'll try Fedora again in 30 years. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A silly question about getting access to webapp installed with yum
On Wed, 11 Jan 2012 22:28:18 +0530 Rajagopal Swaminathan wrote: Now where do these stuff get installed? they are not under /var/www/html rpm -ql nameofrpm If you're not sure of the names of the rpms that yum installed, read /var/log/yum.log to find out. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com www.creekfm.com - FIFTY THOUSAND WATTS of POW WOW POWER! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A silly question about getting access to webapp installed with yum
On Wed, Jan 11, 2012 at 11:58 AM, Rajagopal Swaminathan raju.rajs...@gmail.com wrote: Greetings, I have helped host a few applications such as GLPI, OCSInventory, etc etc. using the tarball method and untarring them in /var/www/htom directory. I have never done them though using yum. I was trying to install Trac, Bugzilla etc using yum install method on a Centos 6.2 box. Somehow I am not able to see the respective pages say even using http://localhost/trac or http://localhost/bugzilla Now comes the elementary and stupid question: Now where do these stuff get installed? they are not under /var/www/html I did find some under /usr/share Any pointers to instantiate them? I am not good at understanding what that beast of yum does as to post install script. Though I have created a mysql with CSV and blackhole engines about a year back and as I did it for a client of the company where I worked then and cannot have my grubby hands on that script. Any help appreciated. TIA -- Regards, Rajagopal Yum only downloads and installs RPM files, so in general you will use the rpm command to get the details of the packages you installed. You can see all the files included in a package by using rpm --query --list package. For apache web apps, the centos style is to place an include file in /etc/httpd/conf.d with the configuration for the app, but your apps might have done something different. Take a look at the include file and see if you need to configure something. There may be docs in /usr/share/doc/packagename explaining what you need to do. ❧ Brian Mathis ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A silly question about getting access to webapp installed with yum
Greetings, On Wed, Jan 11, 2012 at 10:39 PM, Brian Mathis brian.mathis+cen...@betteradmin.com wrote: On Wed, Jan 11, 2012 at 11:58 AM, Rajagopal Swaminathan raju.rajs...@gmail.com wrote: Yum only downloads and installs RPM files, so in general you will use the rpm command to get the details of the packages you installed. You can see all the files included in a package by using rpm --query --list package. For apache web apps, the centos style is to place an include file in /etc/httpd/conf.d with the configuration for the app, but your apps might have done something different. Take a look at the include file and see if you need to configure something. There may be docs in /usr/share/doc/packagename explaining what you need to do. Sure. I will do that in about 13 hours and report back to this list. -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6.2 Postfix - forward through SMTP smarthost with SMTP-AUTH
On 11/01/2012 10:33, Benjamin Hackl wrote: $ cat /etc/postfix/main.cf myorigin=yourdomain.com relayhost=your.smarthost.com smtp_sasl_auth_enable=yes ## you probably want to limit how postfix authenticates # smtp_sasl_security_options=noanonymous # smtp_sasl_mechanism_filter=login smtp_sasl_password_maps=hash:/etc/postfix/relay_password ## if something doesn't work and you need detailed(!!) logs #debug_peer_list=your.smarthost.com #debug_peer_level=3 smtp_use_tls=yes #inet_interfaces = loopback-only #local_transport = error: disabled unknown_local_recipient_reject_code = 450 This is very much nearly what I got to. Note though that outbound port 25 is blocked, but my smarthost listens on the submission port as well if auth is used. So my relayhost line says: relayhost=my.smarthost.com:587 On my relayhost maillog I can see the connection appears, but mails are bounced with: 530 5.7.0Authentication required (in reply to MAIL FROM command) $ cat /etc/postfix/relay_password your.smarthost.com yourusername:yourpassword I have tried my.smarthost.comusername:password and [my.smarthost.com]:587username:password and my.smarthost.com:587username:password With various entries in main.cf to co-incide with these... (and remembering to run postmap each time). $ postmap /etc/postfix/relay_password $ service postfix reload You can check out the commented option in the man pages or http://www.postfix.org/postconf.5.html if you're interested later/have some spare time/if it doesn't work ;-) The line I get in the logs on my smarthost is: Jan 11 18:31:35 gate sendmail[17441]: STARTTLS=server, relay=188.29.xxx.xxx.threembb.co.uk [188.29.xxx.xxx], version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256 The mail just bounces back to the sender, nothing else on the smarthost logs. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
2012/1/11 夜神 岩男 supergiantpot...@yahoo.co.jp: That is not the way it works. SELinux Reference policy is a database of rules that govern the default ways application run. Yes, but it is application developers that know what their applications need to do. Is there a way for them to express that? This gets back to the core problem of people often just not learning SELinux in the first place. Its not RH or Fedora's problem if upstream developers trying to port Windows apps to Fedora dont, for example, understand Unix permissions. No, that's not the issue. The issue is that RH and Fedora have consistently shipped kernels and glibc's (etc., etc.) full of flaws that are trivially exploited to let anyone become root, and then they try to slap bandaids on the applications in a so-so attempt to keep things from being able to get to those vulnerabilities. So after the Fedora version of second-guessing, that gets pushed off to other distributions to likely make it even worse? I'm assuming this is a joke. Fedora already ate (almost) all the babies. No, its not a joke. Doctors get to bury their mistakes, but this is more of an architectural issue where the best you can do is plant vines to cover up a bad design. The vines may have grown over old applications, but if I were to write a new one today, how would I include a configuration that would work regardless of the distribution? Seriously. I lived through it and now I find SELinux a breeze, and audit2allow is *really* quite a livable tool to work with. You're talking like other distro's burden somehow belongs to Fedora. Leave Fedora out of the picture. The burden (or capabiliy, depending on how you look at it) should belong to the application designer. SELinux needs a way for the application designer to tell it what to permit the application to do. Anything else is equivalent to every distribution needing to go rewrite the mode parameters on every open() in every application before the app will work. Fedora's burdens aren't even RH's problem -- RH only picks what it finds as useful for its customer base out of Fedora, and SELinux is very high on the list of incredibly useful things. But just like PostgreSQL, Sendmail, Apache2, Bash, Awk, Sed (the list is long) all the really powerful stuff, new or old, requires some study. Study? Do you mean that people who don't understand them are making these changes? And you expect them to get it right? You're expecting to get a system-wide mandatory access control policy system across every distro based solely on Fedora's efforts (as if Fedora is actively pushing SELinux to other distros) without the users/sysadmins needing to do some reading? When was the last time you ever heard of a safe, secure, all-encompassing web (or otherwise) CMS, for example, that didn't require at least some configuration and knowhow? You have it backwards. I'm saying it needs the knowhow of the upstream application developer, not someone guessing at what they meant to do. SELinux policy is not the hardest thing a packager has to deal with, IMO. Can you quantify that - like with the number of Fedora bugs it produced? That's what the auditing tools can help you out with. Outside of that, you're asking for Microsoft-style defaults, which is ridiculous. Beg your pardon? There is no way, for example, that you could consider it a sane default to permit Apache, on a basic installation, to automatically index directories and serve files from NFS mounted /home partitions and call that secure -- and definitely not to do so while invoking background code that resides in those directories, sending mail out or exercising any sort of database access (which I guess would have to also all be enabled in your favored default policy?). I don't understand your point here. Are you saying that SELinux is not well matched to typical tasks on Linux systems? Complaining or insisting that Fedora or RH somehow magically fix packaging policy for every other distribution, however, are not realistic options, Having distribution packagers make these changes doesn't make any more sense than having them write the application source code in the first place. nor is Yeah, I *want* it to enforce stuff, but I don't want to know what those things are, how they work or to ever have to explain those things to the system when its at a loss amongst the millions of interactions which occur in my system every second or the billions of potential states which can arise. I consider the application writer to be the expert here, and would like just as little intervention by the packagers and sysadmins as we can get away with while the distributions keep shipping kernel and glibc vulnerabilities. I also refuse to read the man pages for chmod and chown. The system should just know who owns what and why, the way Windows used to -- now *that* was slick! You are out of line there. chmod and chown are well documented and
Re: [CentOS] Write to USB pendrives horribly slow
Hello Ljubomir, On Wed, 11 Jan 2012 16:31:43 +0100 Ljubomir Ljubojevic off...@plnet.rs wrote: On 01/11/2012 08:45 AM, wwp wrote: Hello John, On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doejd...@yahoo.com wrote: From: wwpsubscr...@free.fr I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here. I guess it is to be safe in case users remove their usb keys without unmounting first... OK, meaning no write-cache for those devices, makes sense in some way. But this doesn't explain the main issue I reported, although I didn't find a way to change the default mount options used by Gnome (gconf settings don't match those that are used). Do you have ehci_hcd module running? Do you have any error messages in dmesg after you plug it in? ehci_hcd does manage my devices (it's not a loadable module, apparently compiled in kernel instead), see for instance: kernel: usb 2-2: new high speed USB device using ehci_hcd and address 28 kernel: usb 2-2: New USB device found, idVendor=18a5, idProduct=0300 kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-2: Product: STORE N GO kernel: usb 2-2: Manufacturer: Verbatim kernel: usb 2-2: SerialNumber: 25LHXEWIZ5IZKSO0 kernel: usb 2-2: configuration #1 chosen from 1 choice kernel: scsi26 : SCSI emulation for USB Mass Storage devices kernel: scsi 26:0:0:0: Direct-Access Verbatim STORE N GO 1100 PQ: 0 ANSI: 0 CCS kernel: sd 26:0:0:0: Attached scsi generic sg4 type 0 kernel: sd 26:0:0:0: [sdd] 31506432 512-byte logical blocks: (16.1 GB/15.0 GiB) kernel: sd 26:0:0:0: [sdd] Write Protect is off kernel: sd 26:0:0:0: [sdd] Assuming drive cache: write through kernel: sd 26:0:0:0: [sdd] Assuming drive cache: write through kernel: sdd: sdd1 kernel: sd 26:0:0:0: [sdd] Assuming drive cache: write through kernel: sd 26:0:0:0: [sdd] Attached SCSI removable disk No error AFAICS. Regards, -- wwp signature.asc Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wednesday, January 11, 2012 12:06:31 PM Les Mikesell wrote: I was thinking more of Ford getting people to forget about the Pinto - which I think they have done fairly successfully although it may just have to do with aging memory. Let's see, that was around 1980. Maybe I'll try Fedora again in 30 years. 'Unsafe at any speed' Still not a great analogy, though, since the Pinto (and the Corvair) were oriented towards the normal user; Fedora is more of a 'concept car' thing. SELinux and kin are much like seatbelts; they can save your life in a crash, but people tend to worry about the annoyances and the corner cases like that of being trapped underwater (the pressure on the door is a bigger problem than a stuck seatbelt, as Mythbusters demonstrated to good effect). And seatbelt latches have gotten better. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6.2 Postfix - forward through SMTP smarthost with SMTP-AUTH [RESOLVED]
On 11/01/2012 17:36, Giles Coochey wrote: On 11/01/2012 10:33, Benjamin Hackl wrote: $ cat /etc/postfix/main.cf myorigin=yourdomain.com relayhost=your.smarthost.com smtp_sasl_auth_enable=yes ## you probably want to limit how postfix authenticates # smtp_sasl_security_options=noanonymous # smtp_sasl_mechanism_filter=login smtp_sasl_password_maps=hash:/etc/postfix/relay_password ## if something doesn't work and you need detailed(!!) logs #debug_peer_list=your.smarthost.com #debug_peer_level=3 smtp_use_tls=yes #inet_interfaces = loopback-only #local_transport = error: disabled unknown_local_recipient_reject_code = 450 I was missing: smtp_sasl_mechanism_filter postconf.5.html#smtp_sasl_mechanism_filter = !gssapi Something about GSSAPI auth meant it was tried first, failed, and failed permanently. Disabling that, and it works. -- Best Regards, Giles Coochey NetSecSpec Ltd UK Mobile: +44 7983 877 438 Business Email: giles.cooc...@netsecspec.co.uk Email/MSN/Live Messenger: gi...@coochey.net Skype: gilescoochey ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] SELinux blocking cgi script from writing to socket (httpd_t)
Is this really supposed to get easier over time? :) Now my audit.log
file shows that SELinux is blocking my cgi script, index.cgi (which is
what's actually served when the user visits the front page of one of our
proxy sites like sugarsurfer.com) from having 'read write to socket
(httpd_t)'. I have no idea what that means, except that I thought that
cgi scripts were supposed to be able to write to stdout so that the web
server could send the data via a socket connection to the end user's
browser, so I don't know why a CGI script would be blocked from writing
to a socket with security context httpd_t.
The only clue that might narrow it down is the line Target
Objectssocket [ udp_socket ]. The sockets that the cgi
scripts usually send output to are of course tcp sockets, so why would
it say udp? The only time one of my cgi scripts might use udp would be
if it were doing a hostname lookup via dns, but the index.cgi script
doesn't do that at any point.
What would the pros do at this point?
***
Summary:
SELinux is preventing index.cgi (httpd_sys_script_t) read write to socket
(httpd_t).
Detailed Description:
[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]
SELinux denied access requested by index.cgi. It is not expected that this
access is required by index.cgi and this access may signal an intrusion
attempt.
It is also possible that the specific version or configuration of the
application is causing it to require additional access.
Allowing Access:
You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Contextsystem_u:system_r:httpd_sys_script_t
Target Contextsystem_u:system_r:httpd_t
Target Objectssocket [ udp_socket ]
Sourceindex.cgi
Source Path Unknown
Port Unknown
Host Unknown
Source RPM Packages
Target RPM Packages
Policy RPMselinux-policy-2.4.6-316.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing ModePermissive
Plugin Name catchall
Host Name g6950-21025.securedservers.com
Platform Linux g6950-21025.securedservers.com
2.6.18-274.12.1.el5 #1 SMP Tue Nov 29
13:37:46 EST
2011 x86_64 x86_64
Alert Count 1
First SeenWed Jan 11 09:34:13 2012
Last Seen Wed Jan 11 09:34:13 2012
Local ID 2adcd43d-7b8b-4e17-bb93-ad11a35f378a
Line Numbers 1
Raw Audit Messages
type=AVC msg=audit(1326303253.473:3626): avc: denied { read write }
for pid=6668 comm=index.cgi path=socket:[415055] dev=sockfs
ino=415055 scontext=system_u:system_r:httpd_sys_script_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=udp_socket
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] with Centos6 i cant Partition on 3TB Disks, problem
Hi, Marko, Marko Weber wrote: 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? I *think* disk druid (or whatever it's called) is based on fdisk. For larger than 2TB partitions, you need parted or gparted. Consider a) booting off a rescue disk b) using gparted to partition them: note that you *will* need to make them gpt, *not* the normal mbr. c) make usable partitions for /boot and /. d) make larger partitions for whatever else you want. The normal goes back to the M$ DOS days, and 2TB is the max, and only four primary partitions are allowed. Beyond that, you make an extended partition, and make partitions in that. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wed, Jan 11, 2012 at 12:06 PM, Lamar Owen lo...@pari.edu wrote: Still not a great analogy, though, since the Pinto (and the Corvair) were oriented towards the normal user; Fedora is more of a 'concept car' thing. I don't think of myself as a 'normal user', but I still don't appreciate it when a distribution goes out of its way to arbitrarily modify and break what application developers spent years designing and writing. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Write to USB pendrives horribly slow
Blah, blah, blah, Being blocked again, still appears to be based on new content vs. included content. Which makes it very annoying when I want to include context for my response. blah, blah, blah, new content. Hi, wwp, wwp wrote: On Wed, 11 Jan 2012 16:31:43 +0100 Ljubomir Ljubojevic off...@plnet.rs wrote: On 01/11/2012 08:45 AM, wwp wrote: On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doejd...@yahoo.com wrote: From: wwpsubscr...@free.fr I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here. snip ehci_hcd does manage my devices (it's not a loadable module, apparently compiled in kernel instead), see for instance: kernel: usb 2-2: new high speed USB device using ehci_hcd and address 28 snip This may be a dumb question, but have you done an lsusb? I'd be curious - I know that on my brand new, as of a few months ago, Dell I have two kinds of USB ports, 1.1 and 2.0. We also have some 1.1 webcams... and some 1.0. See if your pen drive's in a slower port. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A silly question about getting access to webapp installed with yum
On Wed, Jan 11, 2012 at 11:13 AM, Rajagopal Swaminathan raju.rajs...@gmail.com wrote: Greetings, On Wed, Jan 11, 2012 at 10:39 PM, Brian Mathis brian.mathis+cen...@betteradmin.com wrote: On Wed, Jan 11, 2012 at 11:58 AM, Rajagopal Swaminathan raju.rajs...@gmail.com wrote: Yum only downloads and installs RPM files, so in general you will use the rpm command to get the details of the packages you installed. You can see all the files included in a package by using rpm --query --list package. For apache web apps, the centos style is to place an include file in /etc/httpd/conf.d with the configuration for the app, but your apps might have done something different. Take a look at the include file and see if you need to configure something. There may be docs in /usr/share/doc/packagename explaining what you need to do. Sure. I will do that in about 13 hours and report back to this list. If you are lucky, the app will place a file with an obvious name in /etc/httpd/conf.d/ with some comments about what you have to change locally to set it up - perhaps even commented out lines that you can uncomment to active the defaults. If you are not so lucky you may have to understand the original app setup, then look at the rpm -q --list packagename output to figure out where the packager installed the parts. Even then you are generally better off with the yum installation because it will take care of any required dependencies. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gabber/jabber for centos 5.7?
On 01/11/2012 08:35 AM Ljubomir Ljubojevic wrote: On 01/11/2012 01:52 PM, Johnny Hughes wrote: On 01/11/2012 06:45 AM, ken wrote: I used to use jabber for chats. But I don't find it in centos 5.7 anymore. Is it still around? Or has something else taken its place? What do people using 5.7 use these days? Is there anything which handles MSN? tia. Pidgin is the IM client included in CentOS ... I think it supports MSN and Yahoo chats. It supports 18 protocols, even facebook chat (plugin maybe) Jabber is actually Google Talk/Jabber/XMPP protocol, just with different servers. Thanks, guys. Pidgin works pretty good. It didn't list any jabber servers that I could see, at least not the one I used to use. I wanted to encrypt the connection both ways, which jabber did. And you have to create an account-- e.g., on ICQ or AOL-- separately. But that's okay. Got it going. It works fast, much faster and much less of a cpu load than chatting on facebook. Thanks again. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wednesday, January 11, 2012 01:22:05 PM Les Mikesell wrote: I don't think of myself as a 'normal user', but I still don't appreciate it when a distribution goes out of its way to arbitrarily modify and break what application developers spent years designing and writing. SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy. I still remember when simple packet filtering firewalls first came out, and those with a 'default deny and allow only what you specify' policy were much more difficult to properly configure than those with a 'default allow and block only what you specify' policy. Default deny is the correct way to firewall, but it does require much more work, as you need to know what your traffic actually looks like, and you may need to put in some 'helper' applications and connection trackers for things like ftp and H.323. SELinux is no different in concept, it just brings the access control paradigm onto a much more detailed internal level instead of just being on the network like a simple packet filter would be. If you need to special-case stuff, then you need to do an analysis of the special cases you need to create; this is what a testing server running SELinux in permissive mode is for, as there is no better analysis of what SELinux needs than SELinux in permissive mode loggin what your application is using. Get the logs and run audit2allow and package that as a piece of your applications' SELinux policies. That is new, but it isn't very hard. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Is Amanda vaulting what I need for archiving data?
Hi folks, I've got a bit of a different scenario than I imagine most, and have spent the last 60 or 90 minutes searching Amanda list archives and googling, but did not come up with anything much. Then I went browsing around the Amanda website and found vaulting and was wondering whether this would suit my needs. I'm basically searching around for a backup solution and trying to decide whether to use something off the shelf or just roll my own with gtar. It is important to me that my solution use standard tools like dump/restore / gtar on the back end, which is how I ended up at Amanda. In looking through some of the initial configuration how-tos it seemed as though this was massively over-complex for my application. But then I hit upon vaulting http://wiki.zmanda.com/index.php/How_To:Copy_Data_from_Volume_to_Volume This is not exactly my scenario, but maybe there is another way to roll a vaulting solution to suit me. Basically I work in a scientific research lab (stem cell research) where the scientists produce a fair bit of raw data. We want to periodically take the data and archive it to tape and then remove it from disk and store the tape in our archival facility. We'd need a record of what is on each tape of course. But this would not be the same scenario as in the link above because it would not be taking data from 2ndary to tertiary storage. It would essentially be taken from primary to tertiary directly. i.e. directly from disk to tape. But not in an automated fashion like typical nightly dumps. On request, we'd take the scientist's data and copy it over to our server that has the tape unit, then dump it out to tape, and remove it from the disk there. Once verified, we could tell the scientist it is OK to remove their primary data now, and then we'd store the tape. Is Amanda suited to this? Or is there another application I should be looking at? thanks, -Alan -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of In Defense of Food ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux blocking cgi script from writing to socket (httpd_t)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/2012 01:18 PM, Bennett Haselton wrote:
Is this really supposed to get easier over time? :) Now my
audit.log file shows that SELinux is blocking my cgi script,
index.cgi (which is what's actually served when the user visits the
front page of one of our proxy sites like sugarsurfer.com) from
having 'read write to socket (httpd_t)'. I have no idea what
that means, except that I thought that cgi scripts were supposed to
be able to write to stdout so that the web server could send the
data via a socket connection to the end user's browser, so I don't
know why a CGI script would be blocked from writing to a socket
with security context httpd_t.
The only clue that might narrow it down is the line Target Objects
socket [ udp_socket ]. The sockets that the cgi scripts usually
send output to are of course tcp sockets, so why would it say udp?
The only time one of my cgi scripts might use udp would be if it
were doing a hostname lookup via dns, but the index.cgi script
doesn't do that at any point.
What would the pros do at this point?
***
Summary:
SELinux is preventing index.cgi (httpd_sys_script_t) read write
to socket (httpd_t).
Detailed Description:
[SELinux is in permissive mode, the operation would have been
denied but was permitted due to permissive mode.]
SELinux denied access requested by index.cgi. It is not expected
that this access is required by index.cgi and this access may
signal an intrusion attempt. It is also possible that the specific
version or configuration of the application is causing it to
require additional access.
Allowing Access:
You can generate a local policy module to allow this access - see
FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or
you can disable SELinux protection altogether. Disabling SELinux
protection is not recommended. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this
package.
Additional Information:
Source Contextsystem_u:system_r:httpd_sys_script_t
Target Contextsystem_u:system_r:httpd_t Target
Objectssocket [ udp_socket ] Source
index.cgi Source Path Unknown Port Unknown Host Unknown
Source RPM Packages Target RPM Packages Policy RPM
selinux-policy-2.4.6-316.el5 Selinux Enabled True
Policy Type targeted MLS Enabled
True Enforcing ModePermissive Plugin Name
catchall Host Name
g6950-21025.securedservers.com Platform Linux
g6950-21025.securedservers.com 2.6.18-274.12.1.el5 #1 SMP Tue Nov
29 13:37:46 EST 2011 x86_64 x86_64 Alert Count 1
First SeenWed Jan 11 09:34:13 2012 Last Seen
Wed Jan 11 09:34:13 2012 Local ID
2adcd43d-7b8b-4e17-bb93-ad11a35f378a Line Numbers
1
Raw Audit Messages
type=AVC msg=audit(1326303253.473:3626): avc: denied { read write
} for pid=6668 comm=index.cgi path=socket:[415055] dev=sockfs
ino=415055 scontext=system_u:system_r:httpd_sys_script_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=udp_socket
___ CentOS mailing
list CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Looks like a leaked file descriptor, you can probably add a dontaudit
rule.
In Fedora we currently dontaudit this leak.
audit2allow -i /tmp/t
#= httpd_sys_script_t ==
# This avc has a dontaudit rule in the current policy
allow httpd_sys_script_t httpd_t:udp_socket { read write };
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8N2YMACgkQrlYvE4MpobPnYACg0avTPwuj0XSYKOJIKIIw5Q6J
N5EAoLptqsCytbXtWc7R0EvECbwQJm29
=luHO
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux blocking cgi script from writing to socket (httpd_t)
On 01/12/2012 03:18 AM, Bennett Haselton wrote: Is this really supposed to get easier over time? :) Now my audit.log file shows that SELinux is blocking my cgi script, index.cgi (which is what's actually served when the user visits the front page of one of our proxy sites like sugarsurfer.com) from having 'read write to socket (httpd_t)'. I have no idea what that means, except that I thought that cgi scripts were supposed to be able to write to stdout so that the web server could send the data via a socket connection to the end user's browser, so I don't know why a CGI script would be blocked from writing to a socket with security context httpd_t. Your cgi script isn't allowed to write to the socket file. The context httpd_t isn't touchable by your executable. Is your index.cgi script custom or something from a distro package? In any case you can find a way to deliberately make this audit message show up (sounds like you have), try to vary it a few times to get a good base of audit information, and then use audit2allow to inspect the last several lines of your audit file. From this you can have audit2allow create and package a new policy that explicitely permits just this access and nothing else. See if you get any more AVC denials (9 out of 10 times this will be the end of it). If no more AVC notices and everything works well, turn SELinux back to enforcing and test a bit. Usually for custom scripts (of any depth, really) this is all that's needed. I have to do the same thing every time I decide to do something weird like run a new version of Django on top of Postgres 9.1 from source with all my other custom database-using apps asking for things from other servers, etc. Even with that much messaging going around its pretty easy to pin the situation down. You will need policycoreutils-python installed and you'll want to read over the manpages for audit2allow and any other tool that you find interesting, but its pretty easy now that you've got sane output to go by, know where/what your audit file is, and what a security context is. The only clue that might narrow it down is the line Target Objectssocket [ udp_socket ]. The sockets that the cgi scripts usually send output to are of course tcp sockets, so why would it say udp? The only time one of my cgi scripts might use udp would be if it were doing a hostname lookup via dns, but the index.cgi script doesn't do that at any point. No idea why it would need to talk to a UDP socket if you're absolutely certain that it doesn't need to, but it could be something else related that needs to do a lookup (Apache set to resolve names for logs, for example?). What would the pros do at this point? Aside from checking the policy that the audit tools come up with, it would be reasonable to run a test on the script in a clean environment (minimal install of the OS with just enough web server (Apache) setup to let the script execute) and see what is happening in the audit log (and anywhere else you're curious about -- database, other processes, file system acces, etc.). If you're really paranoid (and a pro is paid to be, so...) it would be good to check the contents of the packets being passed in and out of the test environment to make sure you fully understand what is expected, then compare that against what you see coming from the production server. In *any* case, putting together a quick SELinux policy that let's your app run and lets you turn SELinux back on is better in the interim than simply letting the system sit with a permissive policy while you do your homework. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owen lo...@pari.edu wrote: On Wednesday, January 11, 2012 01:22:05 PM Les Mikesell wrote: I don't think of myself as a 'normal user', but I still don't appreciate it when a distribution goes out of its way to arbitrarily modify and break what application developers spent years designing and writing. SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy. Yes, the breakage came from having someone who didn't understand the needs define that policy. If you need to special-case stuff, then you need to do an analysis of the special cases you need to create; this is what a testing server running SELinux in permissive mode is for, as there is no better analysis of what SELinux needs than SELinux in permissive mode loggin what your application is using. Get the logs and run audit2allow and package that as a piece of your applications' SELinux policies. So if an application only needs to do something once at some future time, what happens? If you write an application that will need to do something at some rare future time, what is the standard way to tell distribution packaging systems and system administrators to permit it? That is new, but it isn't very hard. Doesn't that really depend on what the application needs to do? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux blocking cgi script from writing to socket (httpd_t)
On 01/12/2012 03:48 AM, Daniel J Walsh wrote:
In Fedora we currently dontaudit this leak.
audit2allow -i /tmp/t
#= httpd_sys_script_t ==
# This avc has a dontaudit rule in the current policy
allow httpd_sys_script_t httpd_t:udp_socket { read write };
Pow. Reasonable answer, and it isn't so hard to run that command -- its
just difficult to understand why its necessary if you don't know
anything about the environment, and mystifying if you know the command
but nothing about what's going on.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux blocking cgi script from writing to socket (httpd_t)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/11/2012 02:50 PM, 夜神 岩男 wrote:
On 01/12/2012 03:48 AM, Daniel J Walsh wrote:
In Fedora we currently dontaudit this leak.
audit2allow -i /tmp/t
#= httpd_sys_script_t == # This avc
has a dontaudit rule in the current policy
allow httpd_sys_script_t httpd_t:udp_socket { read write };
Pow. Reasonable answer, and it isn't so hard to run that command --
its just difficult to understand why its necessary if you don't
know anything about the environment, and mystifying if you know the
command but nothing about what's going on.
___ CentOS mailing
list CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
The following explaines leaked file descriptors.
http://danwalsh.livejournal.com/6117.html?thread=23525
In RHEL6 and Fedora you can run avc messages through audit2allow and
it will tell you whether or not there is policy effecting the AVC.
setroubleshoot can also be helpful in these circumstances.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8N6MQACgkQrlYvE4MpobOsJACeIf9ubCB7kBDQFTITJ7hYRXlc
QJIAoMPdXne6a+nVUBBBakeyd0bjkBfs
=8fnf
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
Dne 11.1.2012 17:22, Johnny Hughes napsal(a): OK ... then it ought to move (probably) :) Se my post on repoforge users list. http://lists.repoforge.org/pipermail/users/2012-January/022634.html There's no one to move the package but Dag. DH ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is Amanda vaulting what I need for archiving data?
Hey, Alan, Alan McKay wrote: snip gtar on the back end, which is how I ended up at Amanda. In looking through some of the initial configuration how-tos it seemed as though this was massively over-complex for my application. But then I hit upon vaulting http://wiki.zmanda.com/index.php/How_To:Copy_Data_from_Volume_to_Volume snip Basically I work in a scientific research lab (stem cell research) where the scientists produce a fair bit of raw data. We want to periodically take the data and archive it to tape and then remove it from disk and store the tape in our archival facility. We'd need a record of what is snip For one thing, I think you seriously need to look at backup up to offline hard drives, instead of tapes. Unless you really want/need to archive the tapes for seven years, or whatever, legally, tapes are not the preferred solution these days: they're very slow to use for recovery, and h/d's are large and fast, and still cheap. We back up to backup servers, then, every couple of weeks, I run rsync backups (well, we have a locally-rolled system to run the rsync) onto offline drives - in our case, I swap large drives into an eSATA drive bay. When I'm done, they go in the fire safe. I will note that I work for a US federal agency who I shouldn't mention (I do not speak for the agency or my employer), and our division generates a lot of data, also: easily half a terabyte for one user, and a number for the group that does protein folding mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
Dne 11.1.2012 17:12, email builder napsal(a): I'm on a 32 bit machine, not sure if that makes a difference. What I do know is this: yum update == Package Arch Version Repository Size == Updating: perl-NetAddr-IP i386 4.044-1.el5.rf rpmforge 140 k Transaction Summary == Install 0 Package(s) Upgrade 1 Package(s) Is this because I need to migrate something from rpmforge to RepoForge??? No, this is the timeline: - no perl-NetAddr-IP in Centos 5.7 - RF's perl-NetAddr-IP replaces no package in OS, so it must be in RF repo - perl-NetAddr-IP-4.027 has been introduced in Centos 5.7 - no one (Dag) moved perl-NetAddr-IP from RF to RFX - stock perl-NetAddr-IP-4.027perl-NetAddr-IP-4.044 from RF - and here goes the yum... DH ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On 01/12/2012 04:49 AM, Les Mikesell wrote: On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owenlo...@pari.edu wrote: On Wednesday, January 11, 2012 01:22:05 PM Les Mikesell wrote: I don't think of myself as a 'normal user', but I still don't appreciate it when a distribution goes out of its way to arbitrarily modify and break what application developers spent years designing and writing. SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy. Yes, the breakage came from having someone who didn't understand the needs define that policy. I think you are misunderstanding how SELinux policies are formed and how they work. Its a *lot* less complicated and mysterious than you're making it sound. For most applications its really, really easy to do this. If you need to special-case stuff, then you need to do an analysis of the special cases you need to create; this is what a testing server running SELinux in permissive mode is for, as there is no better analysis of what SELinux needs than SELinux in permissive mode loggin what your application is using. Get the logs and run audit2allow and package that as a piece of your applications' SELinux policies. So if an application only needs to do something once at some future time, what happens? If you write an application that will need to do something at some rare future time, what is the standard way to tell distribution packaging systems and system administrators to permit it? I'm trying to think of a single example (that isn't a worm) that fits this description. Can you think of any examples? (again, worms don't count... actually, that is sort of the point here...) That is new, but it isn't very hard. Doesn't that really depend on what the application needs to do? No, there are tools that do almost all the work for you. Its much easier than learning how to write a spec file in the first place. At this point it sounds like you're just arguing against something you're refusing to find out more about -- which is the standard human policy towards SELinux, so you're in good company (it used to be the standard human policy toward ipchains back in the day, too). You can just turn it off if it bothers you so much. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is Amanda vaulting what I need for archiving data?
For one thing, I think you seriously need to look at backup up to offline hard drives, instead of tapes. Unless you really want/need to archive the tapes for seven years Well, the scientists are talking longer than 7 years so HDs just are not going to cut it We back up to backup servers, then, every couple of weeks, I run rsync backups (well, we have a locally-rolled system to run the rsync) onto offline drives - in our case, I swap large drives into an eSATA drive bay. When I'm done, they go in the fire safe. That's what I'd prefer to do :-) -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of In Defense of Food ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] blue screen instead of login screen
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-fresh-install-%5Bwarning-first-time-linux-user%5D-888683/ 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! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] EPEL not working ... is it just me?
Aha, I forgot about /etc/yum.conf and found an erroneous entry there that has fixed my problem! -- “Don't eat anything you've ever seen advertised on TV” - Michael Pollan, author of In Defense of Food ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
2012/1/11 夜神 岩男 supergiantpot...@yahoo.co.jp: Yes, the breakage came from having someone who didn't understand the needs define that policy. I think you are misunderstanding how SELinux policies are formed and how they work. Its a *lot* less complicated and mysterious than you're making it sound. For most applications its really, really easy to do this. You still haven't quantified this yet so I can understand what you consider 'really, really easy'. How many Fedora bugs have there been specifically related to this? So if an application only needs to do something once at some future time, what happens? If you write an application that will need to do something at some rare future time, what is the standard way to tell distribution packaging systems and system administrators to permit it? I'm trying to think of a single example (that isn't a worm) that fits this description. Can you think of any examples? (again, worms don't count... actually, that is sort of the point here...) For an obvious case, consider an application that needs to send mail but only does it when certain errors happen. Or an application that is configured to fail over using different ports/addresses/sockets that won't be used until the primary fails and may never be seen in an attempt to guess what is supposed to be happening. Or distributed applications that negotiate connections. What about something like the remote monitoring instances that OpenNMS can instantiate with java's RMI capabilities? No, there are tools that do almost all the work for you. Its much easier than learning how to write a spec file in the first place. At this point it sounds like you're just arguing against something you're refusing to find out more about No, I'm arguing that I don't know how to exchange this information in a useful way. And that I don't believe reverse-engineering is the best approach to it. Assuming I would write a new application, how would I confer the knowledge about the needed policy to the places where it needs to be enacted. You can even take distributions out of the context of this question. If a local development group is building/changing applications, what is the expected way for them to inform the system administrators or the operators that will be installing it about the policy needs? -- which is the standard human policy towards SELinux, so you're in good company (it used to be the standard human policy toward ipchains back in the day, too). No, it is the standard human policy when policy makers try to impose policy in ways that don't make sense. You can just turn it off if it bothers you so much. That kind of misses the point. You could run everything as root if you wanted and make all your files mode 777. The reason people don't is that application programs have ways to use lower privileges and ways to represent what is needed. For other restrictions to be widely usable you need standard ways to represent what is required and exchange that information. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is Amanda vaulting what I need for archiving data?
On Wed, Jan 11, 2012 at 2:40 PM, Alan McKay alan.mc...@gmail.com wrote: For one thing, I think you seriously need to look at backup up to offline hard drives, instead of tapes. Unless you really want/need to archive the tapes for seven years Well, the scientists are talking longer than 7 years so HDs just are not going to cut it I'd be hard pressed to find a tape drive that could read any tape I've written that long ago. We back up to backup servers, then, every couple of weeks, I run rsync backups (well, we have a locally-rolled system to run the rsync) onto offline drives - in our case, I swap large drives into an eSATA drive bay. When I'm done, they go in the fire safe. That's what I'd prefer to do :-) You probably need to look at how you identify things first to see if any existing archive approach maps onto that well enough or has a searchable online index so you would know which tape to restore when someone asks for old data. Personally I always think of backuppc first for backups because it can hold so much more online, but it isn't great at archiving. You can make a standard tar image out of anything it has stored, but for anything but the latest run it would take some command line options or selecting it through a web browser. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On 01/11/12 6:03 AM, Les Mikesell wrote: It is for devices with IP, but to find names that aren't officially registered in a DNS server. For example if you have a Playstation 3, or a newer blu-ray player that supports network streaming it will use DHCP to get an address. But then suppose you install your own DLNA media server like ps3mediaserver (or have windows 7 home premium which includes one). Without registering your new server name in DNS, the device will be able to find the service if it is on the same lan. I think Macs use it to find printers too. its to find SERVICES that aren't registered in regular DNS, not hostnames. for instance, yes, said playstation will ask are there any media servers out here? and get the IPs of them so it can query them, ge their capabilities, and display them to the user as sources for music/movies/etc. -- john r pierceN 37, W 122 santa cruz ca mid-left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wednesday, January 11, 2012 11:42:08 AM Les Mikesell wrote: On Wed, Jan 11, 2012 at 9:15 AM, Lamar Owen lo...@pari.edu wrote: On Tuesday, January 10, 2012 04:38:27 PM Les Mikesell wrote: But the hardest part is that these things are application specific and there is no standardization for locations where applications do things. In fact, distributions intentionally move those locations around in their packaging. Distribution differences are the price we pay for choice. If the first thing you saw on a unix-like system was the horror of autoconf, would you have taken a second look? The first thing I saw on a unix-like system was hand-edited Makefiles; I got into this thing before autoconf came into being, a 68k at 10MHz was fast, and 768K of RAM was enough to work with the eight-inch 1.2MB floppies and 5.25 inch full-height 12MB hard drives of the day. Having owned three different unix-like systems of that era, I'm well aware of the difficulties; and all were 680x0 systems, but all different. This is an even worse situation, because there is no equivalent way to describe what you want across flavors. Yes, there is, actually. SELinux policies. How is the application developer (unquestionably the expert on the application needs) supposed to describe those needs to SELinux in a way that can work across distributions without 'less-expert' people guessing about them? This is a problem that each upstream project will need to work out for themselves. I guess you are right about the state of the art and that it is as wrong to expect things to work as it was to expect flying cars by now. I wish I were wrong, honestly, but it is the current state of the art. But it would have been fun. No doubt; I'm waiting on my George Jetson air-scooter-in-a-briefcase myself. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wednesday, January 11, 2012 02:49:29 PM Les Mikesell wrote: On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owen lo...@pari.edu wrote: SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy. Yes, the breakage came from having someone who didn't understand the needs define that policy. 'Going out of its way to break' something means knowing what is needed for something to work, and intentionally preventing it from working. I'm reminded of DR-DOS years ago You can't intentionally break the thing of which you weren't aware; such breakage is not intentional. ... what is the standard way to tell distribution packaging systems and system administrators to permit it? An SELinux policy set. Seriously. Set up variables or whatnot to specify filepaths if you need to. That is new, but it isn't very hard. Doesn't that really depend on what the application needs to do? No, unless the application is doing something dangerous. OpenNMS (for one) does some dangerous (in the security context) things, but the RPM packages I've run 'just worked' from the repository, to the best of my recollection (I did some fairly major network reconfiguration, and need to reinstantiate my OpenNMS instance, and when I do it will be on a different VM running C6, assuming the OpenNMS yum repo is up to date). If the application needs to do wierd things, then the application developer (or some member of the development team, or a user of that package, or the packager (if there is one)) needs to write the SELinux policy and bundle it for those who need it. Simple as that; CentOS and other rebuilds of upstream EL are common enough that SELinux is out there pervasively, so there's really no excuse. Telling people 'turn SELinux off' shouldn't cut it any more. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On 11/01/12 11:16 PM, John R Pierce wrote: its part of multimedia home network plug and play, I believe... lets media boxes find media servers, and such.if you were to serve up streaming media on a home network, it would be a useful thing to have. otherwise? meh. I use AVAHI for an office full of iDevices that the boss wanted to be able to print from. AVAHI lets me advertise the CUPS printers in a format that the iDevices can see and subsequently utilise. Otherwise I disable and remove it on my other server instances. Cheers -pete -- Peter Brady Email: pdbr...@ans.com.au Home Page: http://www.simonplace.net/ Skype: pbrady77 Mobile: +61 410 490 797 signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
OK ... then it ought to move (probably) :) Se my post on repoforge users list. http://lists.repoforge.org/pipermail/users/2012-January/022634.html There's no one to move the package but Dag. Per your suggestion, I filed a bug report on this, although that tracker seems like a lonely place. :) https://github.com/repoforge/repoforge.github.com/issues/2 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wed, Jan 11, 2012 at 3:30 PM, Lamar Owen lo...@pari.edu wrote: Yes, the breakage came from having someone who didn't understand the needs define that policy. 'Going out of its way to break' something means knowing what is needed for something to work, and intentionally preventing it from working. I'm reminded of DR-DOS years ago You can't intentionally break the thing of which you weren't aware; such breakage is not intentional. Imposing a policy to deny things is intentional. And doing it without knowing the details of the needed exceptions isn't accidental. ... what is the standard way to tell distribution packaging systems and system administrators to permit it? An SELinux policy set. Seriously. Set up variables or whatnot to specify filepaths if you need to. Is there a namespace delegation or some central coordinator for that? How do two different policy writers avoid accidentally using the same terms for different things? That is new, but it isn't very hard. Doesn't that really depend on what the application needs to do? No, unless the application is doing something dangerous. OpenNMS (for one) does some dangerous (in the security context) things, but the RPM packages I've run 'just worked' from the repository, to the best of my recollection (I did some fairly major network reconfiguration, and need to reinstantiate my OpenNMS instance, and when I do it will be on a different VM running C6, assuming the OpenNMS yum repo is up to date). But, but... You are running in targeted mode and OpenNMS just isn't one of the targeted applications. That doesn't fix anything going forward. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SELinux and access across 'similar types'
On Wed, Jan 11, 2012 at 01:49:29PM -0600, Les Mikesell wrote: On Wed, Jan 11, 2012 at 1:23 PM, Lamar Owen lo...@pari.edu wrote: SELinux does not 'go out of its way' to 'break' anything; rather, SELinux enforces a deny by default 'need to access' policy. Yes, the breakage came from having someone who didn't understand the needs define that policy. I think part of the problem is that Linux+SELinux is a _different platform_ to Linux without SELinux. On any Unix or Linux system I can install apache, configure it so that DocumentRoot is /mywebtree/htdocs, CGIs are in /mywebtree/cgi. The CGI can write to /myapp/tmpdir and so on. And it will work the same way on all of those platforms. On Linux+SELinux, however, you need to do additional work. The platform needs to be configured to allow this to work. Developers need to target Linux+SELinux as if it was a new platform to be supported. But what about the gazillion of apps that don't support that platform? Either you disable SELinux or you have a large support overhead (initial onboarding of app, verification that updates to app still work, verification that OS updates don't break app, etc etc). Is the additional security worth it? Maybe. Maybe not. That's up to each individual to determine. -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bug submission justified for distribution of obsolete java software?
On Jan 10, 2012, at 11:15 AM, Les Mikesell lesmikes...@gmail.com wrote: But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor. You mean like Oracle? -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is Amanda vaulting what I need for archiving data?
--On Wednesday, January 11, 2012 03:40:20 PM -0500 Alan McKay alan.mc...@gmail.com wrote: Well, the scientists are talking longer than 7 years so HDs just are not going to cut it Regarding the use of hard drives, you might want to have a look at this: http://www.lockss.org/locksswiki/files/ISandT2008.pdf At any rate, if you're concerned with archiving beyond seven years, you probably also need to add another dimension to your archival problem. In the professional archival/library industry they're quite aware of having to maintain information longer than the lifetime of any of: - the individual media that it is stored on (eg: the tape got too old and is now throwing errors) - the media type (eg: my 10 year backups have been stored on ExaByte tapes in a humidity/temperature controlled vault, but I can't find a working ExaByte tape drive anymore, or does anyone have a drive for my 8-inch floppy? How about a computer that will talk to the drive?) - the data format (eg: the document I need is in AppleWriter format. I was able to retrieve it from backups, and the previously recorded checksums match, but I can't find a program that will read it!) For long term storage, you may need to be able to not just put stuff away, but also have a policy (and the resources!) to periodically migrate data to newer media formats. This can get expensive in time and money of course; your stakeholders may need to weigh in again periodically to evaluate the value of the data vs the cost of migration. I'm sure that there are some archivist-related mailing lists out there that can better explain the depth of the horror. Depending on the value of the data, you may also need to look at multiple copies. And then there's disaster recovery ... Just because you didn't have enough problems already ... (BTW, the main site http://www.lockss.org about LOCKSS looks interesting from an acedemic point of view, albiet not relevent here.) Devin ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Write to USB pendrives horribly slow
On 01/11/2012 07:33 PM, m.r...@5-cent.us wrote: wwp wrote: On Wed, 11 Jan 2012 16:31:43 +0100 Ljubomir Ljubojevicoff...@plnet.rs wrote: On 01/11/2012 08:45 AM, wwp wrote: On Tue, 10 Jan 2012 08:57:14 -0800 (PST) John Doejd...@yahoo.com wrote: From: wwpsubscr...@free.fr I wonder if some mount options aren't wrong with USB pendrives, see: /dev/sdd1 on /media/monolith type vfat (rw,nosuid,nodev,uhelper=udisks,shortname=mixed,dmask=0077,utf8=1,flush) my suspicion is about the flush option, which I find atypical here. snip ehci_hcd does manage my devices (it's not a loadable module, apparently compiled in kernel instead), see for instance: kernel: usb 2-2: new high speed USB device using ehci_hcd and address 28 snip This may be a dumb question, but have you done an lsusb? I'd be curious - I know that on my brand new, as of a few months ago, Dell I have two kinds of USB ports, 1.1 and 2.0. We also have some 1.1 webcams... and some 1.0. See if your pen drive's in a slower port. Yes I have seen those too and was VERY surprised. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Clustering solutions - mail, www, storage.
On Jan 10, 2012, at 2:59 PM, Rafał Radecki radecki.ra...@gmail.com wrote: Hi all. I am currently working for a hosting provider in a 100+ linux hosts' environment. We have www, mail HA solutions, as storage we mainly use NFS at the moment. We are also using DRBD, Heartbeat, Corosync. I am now gathering info to make a cluster with: - two virtualization nodes (active master and passive slave); - two storage nodes (for vm files) used by mentioned virtualization nodes (also active/passive). For virtualization I am thinking to use OpenVZ or KVM. For storage NFS or iSCSI. Could you please share your experiences with these technologies? Which one would you use and why? Are there any good alternatives in CentOS? For Linux virtualization on a scale greater then a couple of hosts I'd buy VMware and get a good SAN box with redundancy, say EMC, 3Par, NetApp or one of the middle tier like Equallogic, Lefthand or Compellent. Otherwise a Xen cluster with an NFS store for the VM files (ease of management) and iSCSI for their data partitions (performance) using DRBD for fault tolerance. -Ross ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A silly question about getting access to webapp installed with yum
On 01/11/2012 06:09 PM, Frank Cox wrote: If you're not sure of the names of the rpms that yum installed, read /var/log/yum.log to find out. CentOS 6.x has yum history, 'yum history 185, yum history info 185 ... -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 5.7, I10 video, 1920x1080 monitor
On 01/10/2012 11:21 PM, Frank Cox wrote: On Tue, 10 Jan 2012 20:50:36 -0500 Mark LaPierre wrote: Are you sure that your video card can support your desired resolution? I am now. After much fiddling around trying this and that I gave up and booted off of a Centos 6.2 install disk, and that came up in the 1920x1080 resolution all by itself. So I've decided that it's time to upgrade that machine to Centos 6. I think you have a great plan there. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registerd Linux user No #267004 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Building REDHAT Desktop Virtualization Solution With Centos
On 01/11/2012 06:53 AM, Johnny Hughes wrote: On 01/11/2012 05:11 AM, Arif Tuhin wrote: Redhat offers a desktop virtualization solution using kvm,qemu,libvirt and spice which is directed at centralized server hosting virtual desktops and thin clients connecting to it. All the relevant software are open source. So it should be possible to achieve the same feat with CentOS. Anyone know any complete tutorial regarding this? I've found separate tutorials regarding spice, kvm etc. But a complete tutorial describing how to emulate the Redhat virtualization for Desktops will be very handy. If you are talking about the RHEV product line, not all of it is open source yet (at least not in the versions for the currently released RHEV line). What is specifically not yet available and/or opensource are all the jboss and maven2 requirements ... at least not the versions that are in RHEV. We are looking into the RHEV packages, and I hear that they plan to release an upgraded version with more of the enterprise package sources available by 2nd quarter 2012. If you want to try early adoption things then this might be for you: http://www.ovirt.org/ If you are only looking for the things that you listed (kvm,qemu,libvirt,spice) those are all in 6.2 right now. But, to answer your question (if it is about RHEV) ... if and when the sources for the enterprise tools of RHEV-H and RHEV-M become available in a ready to build way ... then yes will the CentOS project build them. Here are some other good sources of info on this subject: http://lists.centos.org/pipermail/centos/2009-November/085639.html http://www.linux-kvm.com/content/update-rhev-m-going-open-source ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Remember that KVM is not available in 32 bit. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registerd Linux user No #267004 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On 01/11/2012 06:03 AM, Les Mikesell wrote: It is for devices with IP, but to find names that aren't officially registered in a DNS server. For example if you have a Playstation 3, or a newer blu-ray player that supports network streaming it will use DHCP to get an address. But then suppose you install your own DLNA media server like ps3mediaserver (or have windows 7 home premium which includes one). Without registering your new server name in DNS, the device will be able to find the service if it is on the same lan. I think Macs use it to find printers too. Wait a sec, I have that setup (just mediatomb instead of ps3mediaserver) and there's no avahi on my network. Yet the PS3 is perfectly capable of discovering and using the DLNA server. It might be useful for *something* but it doesn't appear to be required in this case. -- Florin Andrei http://florin.myip.org/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CPU Usage when idle
Hello guys, Did anyone noticed how green CentOS 6 is compared to the previous release? I've been running a couple of CentOS 6 VMs (on our vSphere environment) for the last couple of weeks and noticed a BIG difference when it comes to CPU usage when the VM is completely idle. I would like to share what I've seen in our environment: PfSense 2.0 (FreeBSD) VM: 40 Mhz CentOS 5.7 VM: 60 Mhz CentOS 6.2 VM: 5 Mhz This is really wonderful. They did a great job with RHEL6 and I'm curious what was changed in order to accomplish this. Regards, Jorge ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is avahi essential?
On 1/11/2012 6:10 PM, Florin Andrei wrote: On 01/11/2012 06:03 AM, Les Mikesell wrote: It is for devices with IP, but to find names that aren't officially registered in a DNS server. For example if you have a Playstation 3, or a newer blu-ray player that supports network streaming it will use DHCP to get an address. But then suppose you install your own DLNA media server like ps3mediaserver (or have windows 7 home premium which includes one). Without registering your new server name in DNS, the device will be able to find the service if it is on the same lan. I think Macs use it to find printers too. Wait a sec, I have that setup (just mediatomb instead of ps3mediaserver) and there's no avahi on my network. Yet the PS3 is perfectly capable of discovering and using the DLNA server. You're talking about the inverse case of Les. An MDNS server on your Linux box lets it find services on the network via MDNS. So, you could store movies on the PS3 and maybe play them on the Linux desktop without knowing the PS3's IP address, if you used an mdns/avahi-aware player program. The plug-and-play nature of MDNS would evaporate if you had to set up a Linux box on the LAN just to act as MDNS server. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
