Search results for query "Linux ./configure"

6358 messages

Re: [CentOS] IPv6 broken on Linode

by James Hogarth

On 16 February 2017 at 11:46, James Hogarth <james.hogarth(a)gmail.com> wrote: > On 16 February 2017 at 11:35, Alice Wonder <alice(a)domblogger.net> wrote: >> On 02/16/2017 03:28 AM, James Hogarth wrote: >>> >>> On 16 February 2017 at 10:42, Alice Wonder <alice(a)domblogger.net> wrote: >>>> >>>> On 02/16/2017 02:32 AM, James Hogarth wrote: >>>>> >>>>> >>>>> On 16 February 2017 at 10:17, Alice Wonder <alice(a)domblogger.net> wrote: >>>>>> >>>>>> >>>>>> On 02/16/2017 02:03 AM, James Hogarth wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 16 February 2017 at 09:09, Alice Wonder <alice(a)domblogger.net> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 02/16/2017 12:54 AM, Tony Mountifield wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In article <4cbb9dc4-f063-3434-b7a1-d4d0e6581b5e(a)domblogger.net>, >>>>>>>>> Alice Wonder <alice(a)domblogger.net> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://forum.linode.com/viewtopic.php?f=19&t=14570&p=72785 >>>>>>>>>> >>>>>>>>>> I can not figure out what I need to do. >>>>>>>>>> >>>>>>>>>> Apparently according to linode support, the VM is trying to grab an >>>>>>>>>> IPv6 >>>>>>>>>> address with some privacy stuff enabled by default causing it to >>>>>>>>>> not >>>>>>>>>> grab the IPv6 address that is assigned to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Does the accepted answer at the following link give you any useful >>>>>>>>> hints? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-… >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> Tony >>>>>>>>> >>>>>>>> >>>>>>>> Not really - I tried >>>>>>>> >>>>>>>> net.ipv6.conf.all.use_tempaddr = 0 >>>>>>>> >>>>>>>> and it still fails to grab the proper IPv6 >>>>>>>> >>>>>>>> -=- >>>>>>>> >>>>>>>> Just in case, I did ask Linode support to verify that my hardware >>>>>>>> address >>>>>>>> is >>>>>>>> what it is suppose to be. Still waiting to hear on that. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> it still is key=value ... it uses the ifcfg- files (via the rh >>>>>>> plugin) and they are all key=value >>>>>>> >>>>>>> It would be helpful if you could paste the journal output (journalctl >>>>>>> -u NetworkManager) from the time period of attempting to get an >>>>>>> address ... >>>>>>> >>>>>>> also the nmcli conn sh <connection_name> information for the interface >>>>>>> along with your ifcfg- files >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ifcfg-lo is the only one that exists on any of the servers - including >>>>>> the >>>>>> VMs that grab the correct IPv6 address. >>>>>> >>>>>> from /sbin/ifconfig -a : >>>>>> >>>>> >>>>> For a start stop using ifconfig ... it's broken at this point on >>>>> linux, especially on multi ip and ipv6 scenarios >>>>> >>>>> Use `ip -6 addr sh` for ipv6 specfic stuff, or just ip addr sh to see >>>>> all IP address stuff regardless of family >>>>> >>>>>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 >>>>>> inet 178.79.185.217 netmask 255.255.255.0 broadcast >>>>>> 178.79.185.255 >>>>>> inet6 fe80::a8ad:d312:4ef4:7272 prefixlen 64 scopeid >>>>>> 0x20<link> >>>>>> inet6 2a01:7e00::825f:e564:ad53:72fc prefixlen 64 scopeid >>>>>> 0x0<global> >>>>>> ether f2:3c:91:18:8a:7e txqueuelen 1000 (Ethernet) >>>>>> RX packets 9903 bytes 1088621 (1.0 MiB) >>>>>> RX errors 0 dropped 0 overruns 0 frame 0 >>>>>> TX packets 7786 bytes 1087223 (1.0 MiB) >>>>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 >>>>>> >>>>>> That hardware address - the 18:8a:7e corresponds with what the IPv6 >>>>>> address >>>>>> is suppose to be. But that's not the address it is grabbing, despite >>>>>> the >>>>>> fact that net.ipv6.conf.all.use_tempaddr = 0 is set. >>>>>> >>>>>> I'm seriously wondering if the real issue is a mis-configured dhcp >>>>>> server >>>>>> in >>>>>> their London facility because nothing makes sense. >>>>>> >>>>>> journalctl -u NetworkManager >>>>>> >>>>>> reports no journal entries found. >>>>>> >>>>> >>>>> So are you not using NetworkManager then? there should be some logs ... >>>>> >>>>> >>>>>> I think the problem must be on their end. >>>>>> >>>>>> It all was working fine until they migrated the VM because of a >>>>>> hardware >>>>>> issue, and I suspect now all the hardware address privacy stuff being >>>>>> the >>>>>> issue is barking up the wrong tree because all the reading I have done >>>>>> seems >>>>>> to indicate that with >>>>>> >>>>>> net.ipv6.conf.all.use_tempaddr = 0 >>>>>> >>>>>> that a fake temporary hardware address would not be sent to their dhcp >>>>>> server when obtaining the address, but the real one, that should be >>>>>> fetching >>>>>> my assigned address. >>>>> >>>>> >>>>> >>>>> Only if the kernel is doing SLAAC ... if other things (eg NM) are >>>>> handling it directly they may act differently ... but then from the >>>>> lack of logs is NM actually handling this? >>>>> >>>>> Does systemctl status NetworkManager show it running and does nmcli >>>>> show anything? >>>>> >>>> >>>> systemctl status NetworkManager >>>> ● NetworkManager.service - Network Manager >>>> Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; >>>> enabled; >>>> vendor preset: enabled) >>>> Active: active (running) since Thu 2017-02-16 08:19:34 UTC; 2h 19min >>>> ago >>>> >>>> * more stuff * >>>> >>>> nmcli >>>> eth0: connected to Wired connection 1 >>>> "Red Hat Virtio network device" >>>> ethernet (virtio_net), F2:3C:91:18:8A:7E, hw, mtu 1500 >>>> ip4 default, ip6 default >>>> inet4 178.79.185.217/24 >>>> route4 178.79.187.246/32 >>>> inet6 2a01:7e00::825f:e564:ad53:72fc/64 >>>> inet6 fe80::a8ad:d312:4ef4:7272/64 >>>> route6 2a01:7e00::/64 >>>> >>>> * more stuff for other interfaces * >>>> >>>> -=- >>>> >>>> The output of >>>> >>>> sysctl -a | grep net.ipv6 : >>>> >>>> https://librelamp.com/sysctl.txt >>>> >>>> It looks from that like it should not be hiding the real MAC address. >>>> >>> >>> >>> do nmcli conn show "Wired connection 1" >>> >>> the entries of interest are: >>> >>> ipv6.ip6-privacy >>> ipv6.addr-gen-mode >>> >>> man nm-settings to get what they mean >>> _______________________________________________ >>> CentOS mailing list >>> CentOS(a)centos.org >>> https://lists.centos.org/mailman/listinfo/centos >>> >> >> ipv6.ip6-privacy: -1 (unknown) >> ipv6.addr-gen-mode: stable-privacy >> > > > Okay so from the man page: > > The permitted values are: > "eui64", or > "stable-privacy". If > the property is set to > "eui64", the addresses > will be generated using > the interface tokens > derived from hardware > address. This makes the > host part of the > address to stay > constant, making it > possible to track > host's presence when it > changes networks. The > address changes when > the interface hardware > is replaced. The value > of "stable-privacy" > enables use of > cryptographically > secure hash of a secret > host-specific key along > with the connection > identification and the > network address as > specified by RFC7217. > This makes it > impossible to use the > address track host's > presence, and makes the > address stable when the > network interface > hardware is replaced. > > > I'm not certain (would have to go get changelogs) but I suspect this > was a change at 7.3 with the rebase of NetworkManager > > From what you say you want it sounds like you want eui64 - the one > based entire on the current MAC - whereas the present version is using > stable-privacy to avoid tracking. > > Note that this is distinct and different to ip6-privacy which is > concerned about the automatic generation of temporary addresses to use > for outbound communication. Okay a little more research as I'm curious when it changed from EUI64 by default ... https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy-in-t… NM changed upstream to stable-privacy at 1.2 (the privacy extensions for the external connections were added at 1.0.4) RHEL 7.2 enabled privacy extensions by default: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht… But at that milestone we had NM 1.0.6 At the RHEL 7.3 release NM was rebased to 1.4.0 It was briefly referenced with this change in the 7.3 release notes but honestly it's pretty opaque ... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht… "NetworkManager now supports new device types, improved stacking of virtual devices, LLDP, stable privacy IPv6 addresses (RFC 7217), detects duplicate IPv4 addresses, and controls a host name through systemd-hostnamed. Additionally, the user can set a DHCP timeout property and DNS priorities." Of course unless you knew what RFC 7217 was you'd have no idea this was the effect and there's no note that stable-privacy is the new default behaviour ARGH Disappointingly it's not listed in the "Networking" part of the release notes .... I think I'll raise the priority on my blog for the article I'm intending on the NM rebase ... there are nice things in the rebase like the arbitrary layering of teams, vlans and bridges but then there's unexpected stuff like this as well which should be made more visible. So ... Alice if you want to configure the system with the older EUI64 behaviour then in your ifcfg file for that interface you need IPV6_ADDR_GEN_MODE=eui64 and then restart NetworkManager (or `nmcli conn reload` rather than a full service restart or `nmcli conn mod "Wired Connection 1" ipv6.addr-gen-mode eui64` to do it at the CLI without editing files and needing a connection reload).

9 years, 1 month

Re: [CentOS-es] [iptables] denegar rando dependiendo la IP de la fuenta ?

by David González Romero

Hace un forward en el IPtables de que todo lo que vaya al 0/0 port 80, 443, 21, 20, etc... vaya al 3128... Squid no necesita configuacion adicional para https lo soporta perfectamente bien. Tu puedes controlar los accesos por dominios, o por IP... escoge el que te guste. Saludos, David El 5 de noviembre de 2013 12:07, angel jauregui <darkdiabliyo(a)gmail.com>escribió: > mmm es qye hay varios listillos que se lo podrian brincar :S... existe la > problematica que en esa red todos tienen acceso admin a sus propios > equipos. Generalmente siempre estan conectados con una cuenta de usuario > dentro del dominio local, pero a veces se logean con la cuenta admin. > > Y como soy un prestador de servicios y no quieren invertir, la unica > solucion es poner el proxy como GW. > > Para prevenir retardos coloque en el proxy 2 tarjetas de red 1Gb en > virtual, y configure el switch cisco como VLAN en los 2 puertos donde > conecto el proxy. > > Saludos ! > > > El 5 de noviembre de 2013 08:52, Ramón Macías Zamora <rmacias(a)rks.ec > >escribió: > > > Efectivamente el problema que tienes es porque está usando proxy > > transparente. > > > > Si no usas proxy transparente si puedes controlarlo con las acl normales, > > sin embargo para que funcione el proxy debes configurar manualmente el > > proxy en los navegadores (En Firefox -> Preferencias -> Avanzado -> red > -> > > Conexión dar click en Configurar -> Configuración Manual del Proxy > > > > Saludos > > > > -- > > > > > > > > Ramón Macías Zamora > > Tecnología, Investigación y Desarrollo > > www.rks.ec - www.raykasolutions.com > > Guayaquil - Ecuador > > msn: ramon_macias(a)hotmail.com > > skype: ramon_macias > > UserLinux# 180926 (http://counter.li.org) > > Cel: 593-8-0192238 > > Tel: 593 4 6044566 > > > > <http://www.raykasolutions.com/> > > > > > > WEB SITES, HOSTINGS, DOMINIOS, MANTENIMIENTO DE EQUIPOS, REDES, > SERVIDORES > > LINUX, SOPORTE. > > > > > > 2013/11/5 angel jauregui <darkdiabliyo(a)gmail.com> > > > > > @Ramon no entiendo cuando mencionas "forzar a que los usuarios > configuren > > > el proxy" ??? > > > > > > Los usuarios no tienen que configurar nada, ya que por consecuencia el > GW > > > que se les asigna es el del proxy, el proxy en si actua como > > > Proxy+Router+firewall. > > > > > > No entendi :S > > > > > > Saludos ! > > > > > > > > > El 5 de noviembre de 2013 08:38, Ramón Macías Zamora <rmacias(a)rks.ec > > > >escribió: > > > > > > > Yo creo que la solución ahí es forzar a que los usuarios configuren > el > > > > proxy en vez de usar proxy transparente que sólo funciona para http y > > no > > > > para https. > > > > > > > > Saludos > > > > > > > > -- > > > > > > > > > > > > > > > > Ramón Macías Zamora > > > > Tecnología, Investigación y Desarrollo > > > > www.rks.ec - www.raykasolutions.com > > > > Guayaquil - Ecuador > > > > msn: ramon_macias(a)hotmail.com > > > > skype: ramon_macias > > > > UserLinux# 180926 (http://counter.li.org) > > > > Cel: 593-8-0192238 > > > > Tel: 593 4 6044566 > > > > > > > > <http://www.raykasolutions.com/> > > > > > > > > > > > > WEB SITES, HOSTINGS, DOMINIOS, MANTENIMIENTO DE EQUIPOS, REDES, > > > SERVIDORES > > > > LINUX, SOPORTE. > > > > > > > > > > > > 2013/11/5 angel jauregui <darkdiabliyo(a)gmail.com> > > > > > > > > > @David asi tengo la denegacion tambien, pero si el usuario cambia a > > > > "https" > > > > > la pagina ya no es bloqueada, se brinca el filtro. > > > > > > > > > > Esto mas que nada porque en IPTables la regla indica que cualquier > > cosa > > > > que > > > > > va al 80 se rediriga al 3128 (puerto squid), y al cambiar a HTTPS, > ya > > > no > > > > se > > > > > aplica la regla. > > > > > > > > > > Ahora no puedo quitar el puerto https y forzar solo http, ya que > > > existen > > > > > paginas de gobierno que requieren https, y se me vendria el mundo > > > encima > > > > > :S. > > > > > > > > > > Estoy intentando con estas reglas, ustedes que opinan: > > > > > > > > > > *# dar acceso a facebook para una ip fija* > > > > > shell# iptables -A FORWARD -p tcp -s 10.1.0.10 -d > IP_CIDR_DEFACEBOOK > > > -j > > > > > ACCEPT > > > > > > > > > > *# quitar acceso facebook para cualquiera del segmento* > > > > > shell# iptables -A FORWARD -p tcp -s 10.1.0.0/24 -d > > IP_CIDR_DEFACEBOOK > > > > -j > > > > > REJECT > > > > > > > > > > Saludos ! > > > > > > > > > > > > > > > El 5 de noviembre de 2013 05:08, David González Romero > > > > > <dgrvedado(a)gmail.com>escribió: > > > > > > > > > > > Tu has probado esta opción en Squid? > > > > > > > > > > > > acl denys url_regex "/etc/squid/denys" > > > > > > Donde > > > > > > /etc/squid/denys contiene: > > > > > > facebook > > > > > > twitter > > > > > > ..... > > > > > > Y luego > > > > > > http_access deny restric > > > > > > > > > > > > Al menos así me funciona a mi. > > > > > > > > > > > > > > > > > > Otra opcion sería comentar la línea "acl SSL_ports port 443" para > > > > evitar > > > > > > conexiones por el 443... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Saludos, > > > > > > David > > > > > > > > > > > > > > > > > > > > > > > > El 4 de noviembre de 2013 18:47, angel jauregui > > > > > > <darkdiabliyo(a)gmail.com>escribió: > > > > > > > > > > > > > Buenas. > > > > > > > > > > > > > > Estoy implementando limitaciones en la red, el objetivo es > quitar > > > > > acceso > > > > > > a > > > > > > > Redes Sociales, en primera instancia tengo SQUID que logra > tapar > > el > > > > > > acceso > > > > > > > a los sitios mediante http. > > > > > > > > > > > > > > El problema es que si los sitios tienes HTTPS, este es > > > accesible.... > > > > > > > > > > > > > > En este caso http://facebook.com esta denegad por Squid. > > > > > > > Pero al poner https://facebook.com entra exitosamente. > > > > > > > > > > > > > > La unica ocurrencia que tuve es usar IPTABLES, asi que puse > esta > > > > regla > > > > > > que > > > > > > > me esta haceindo cumplir el objetivo "En parte": > > > > > > > > > > > > > > iptables -I FORWARD -m tcp -p tcp -m iprange --dst-range > > > > > > > 173.252.64.0-173.252.127.255 -j REJECT > > > > > > > > > > > > > > Donde: 173.252.64.0-173.252.127.255 ---> es el rando CIDr de > > > > facebook. > > > > > > > > > > > > > > El problema *ahora radica* en que no logro hacer que ciertas > IPs > > > > > Locales > > > > > > > (privilegiada - jefes) SI puedan acceder a redes sociales :S !. > > > > > > > > > > > > > > Intente ANTEponiendo esta regla: > > > > > > > > > > > > > > iptables -I FORWARD *-s ip_del_jefe *-m tcp -p tcp -m iprange > > > > > --dst-range > > > > > > > 173.252.64.0-173.252.127.255 -j ACCEPT > > > > > > > > > > > > > > Pero aun asi, se sigue bloqueando el sitio :S.... > > > > > > > > > > > > > > *shell# iptables -L -n* > > > > > > > REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 > tcp > > > > > > > destination IP range 173.252.64.0-173.252.127.255 reject-with > > > > > > > icmp-port-unreachable > > > > > > > ACCEPT tcp -- 10.1.0.150 0.0.0.0/0 > tcp > > > > > > > destination IP range 173.252.64.0-173.252.127.255 > > > > > > > > > > > > > > -- > > > > > > > M.S.I. Angel Haniel Cantu Jauregui. > > > > > > > > > > > > > > Celular: (011-52-1)-899-871-17-22 > > > > > > > E-Mail: angel.cantu(a)sie-group.net > > > > > > > Web: http://www.sie-group.net/ > > > > > > > Cd. Reynosa Tamaulipas. > > > > > > > _______________________________________________ > > > > > > > CentOS-es mailing list > > > > > > > CentOS-es(a)centos.org > > > > > > > http://lists.centos.org/mailman/listinfo/centos-es > > > > > > > > > > > > > _______________________________________________ > > > > > > CentOS-es mailing list > > > > > > CentOS-es(a)centos.org > > > > > > http://lists.centos.org/mailman/listinfo/centos-es > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > M.S.I. Angel Haniel Cantu Jauregui. > > > > > > > > > > Celular: (011-52-1)-899-871-17-22 > > > > > E-Mail: angel.cantu(a)sie-group.net > > > > > Web: http://www.sie-group.net/ > > > > > Cd. Reynosa Tamaulipas. > > > > > _______________________________________________ > > > > > CentOS-es mailing list > > > > > CentOS-es(a)centos.org > > > > > http://lists.centos.org/mailman/listinfo/centos-es > > > > > > > > > _______________________________________________ > > > > CentOS-es mailing list > > > > CentOS-es(a)centos.org > > > > http://lists.centos.org/mailman/listinfo/centos-es > > > > > > > > > > > > > > > > -- > > > M.S.I. Angel Haniel Cantu Jauregui. > > > > > > Celular: (011-52-1)-899-871-17-22 > > > E-Mail: angel.cantu(a)sie-group.net > > > Web: http://www.sie-group.net/ > > > Cd. Reynosa Tamaulipas. > > > _______________________________________________ > > > CentOS-es mailing list > > > CentOS-es(a)centos.org > > > http://lists.centos.org/mailman/listinfo/centos-es > > > > > _______________________________________________ > > CentOS-es mailing list > > CentOS-es(a)centos.org > > http://lists.centos.org/mailman/listinfo/centos-es > > > > > > -- > M.S.I. Angel Haniel Cantu Jauregui. > > Celular: (011-52-1)-899-871-17-22 > E-Mail: angel.cantu(a)sie-group.net > Web: http://www.sie-group.net/ > Cd. Reynosa Tamaulipas. > _______________________________________________ > CentOS-es mailing list > CentOS-es(a)centos.org > http://lists.centos.org/mailman/listinfo/centos-es >

12 years, 5 months

Re: [CentOS-devel] Minishift in PaaS SIG

by Lalatendu Mohanty

On Tue, Mar 21, 2017 at 3:47 AM, Marcin Dulak <marcin.dulak(a)gmail.com> wrote: > > > On Thu, Mar 16, 2017 at 11:58 AM, Marcin Dulak <marcin.dulak(a)gmail.com> > wrote: > >> >> >> On Thu, Mar 16, 2017 at 11:55 AM, Lalatendu Mohanty <lmohanty(a)redhat.com> >> wrote: >> >>> >>> >>> On Wed, Mar 15, 2017 at 1:30 AM, Marcin Dulak <marcin.dulak(a)gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> On Tue, Mar 14, 2017 at 7:17 PM, Lalatendu Mohanty <lmohanty(a)redhat.com >>>> > wrote: >>>> >>>>> Hi All, >>>>> >>>>> In last couple of Paas SIG meetings we discussed around if we should >>>>> provide Minishift from PaaS SIG and the general agreement was that it will >>>>> benefit the CentOS community. As a member of Minishift project and PaaS >>>>> SIG member I will work to build Minishift in the CentOS build system and >>>>> doing the releases through PaaS SIG. I have copied the recent release >>>>> announcement of Minishift in this mail to give you some context about >>>>> Minishift . >>>>> >>>>> Previously we were working on Atomic Developer Bundle (ADB) which was >>>>> part of Atomic SIG. Minishift is the next generation tool to replace ADB >>>>> as it address lot of ADB's short comings. It is written in Go and it is >>>>> light weight and designed to provide better user experience. >>>>> >>>>> We have been doing couple of beta releases in Minishift project as we >>>>> move towards the 1.0.0 release. The next release is planned to be a release >>>>> candidate release then followed by 1.0.0 release. >>>>> >>>>> If you are interested to help us in building, testing, releasing >>>>> Minishift through PaaS SIG, please let us know. >>>>> >>>> >>>> I would like to help. >>>> Got https://github.com/minishift/minishift/blob/master/READM >>>> E.md#deploying-a-sample-application run with virtualbox 5.1.14r112924 >>>> and minishift-1.0.0-beta.5-linux-amd64.tgz >>>> >>>> My packaging experience: >>>> https://admin.fedoraproject.org/pkgdb/packager/marcindulak/ >>>> >>> >>> Thanks for the offer for helping with Minishift. >>> >>>> >>>> Any specific tasks that may correspond to my profile? >>>> >>> >>> There are two tasks for Minishift. First we need to create a RPM for >>> Minishift binary. >>> >> >> OK, I think I can contribute to this. >> > > https://copr.fedorainfracloud.org/coprs/marcindulak/minishift/builds/ - > it looks like the following dependencies are needed on CentOS7, and a > couple packages less on Fedora: > > DEBUG util.py:439: Error: No Package found for golang(github.com/DATA-DOG/godog) > DEBUG util.py:439: Error: No Package found for golang(github.com/DATA-DOG/godog/gherkin) > DEBUG util.py:439: Error: No Package found for golang(github.com/asaskevich/govalidator) > DEBUG util.py:439: Error: No Package found for golang(github.com/blang/semver) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/go-units) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/drivers/fakedriver) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/drivers/hyperv) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/drivers/virtualbox) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/drivers/vmwarefusion) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/auth) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/drivers) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/drivers/plugin) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/drivers/plugin/localbinary) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/engine) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/host) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/log) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/mcnerror) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/mcnflag) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/mcnutils) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/provision) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/provision/pkgaction) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/provision/provisiontest) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/provision/serviceaction) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/shell) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/ssh) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/state) > DEBUG util.py:439: Error: No Package found for golang(github.com/docker/machine/libmachine/swarm) > DEBUG util.py:439: Error: No Package found for golang(github.com/golang/glog) > DEBUG util.py:439: Error: No Package found for golang(github.com/google/go-github/github) > DEBUG util.py:439: Error: No Package found for golang(github.com/inconshreveable/go-update) > DEBUG util.py:439: Error: No Package found for golang(github.com/kardianos/osext) > DEBUG util.py:439: Error: No Package found for golang(github.com/olekukonko/tablewriter) > DEBUG util.py:439: Error: No Package found for golang(github.com/pborman/uuid) > DEBUG util.py:439: Error: No Package found for golang(github.com/pkg/browser) > DEBUG util.py:439: Error: No Package found for golang(github.com/spf13/viper) > DEBUG util.py:439: Error: No Package found for golang(golang.org/x/oauth2) > DEBUG util.py:439: Error: No Package found for golang(k8s.io/kubernetes/pkg/api) > DEBUG util.py:439: Error: No Package found for golang(k8s.io/kubernetes/pkg/api/v1) > DEBUG util.py:439: Error: No Package found for golang(k8s.io/kubernetes/pkg/client/unversioned) > DEBUG util.py:439: Error: No Package found for golang(k8s.io/kubernetes/pkg/client/unversioned/clientcmd) > DEBUG util.py:439: Error: No Package found for golang(k8s.io/kubernetes/pkg/client/unversioned/clientcmd/api) > DEBUG util.py:439: Error: No Package found for golang(k8s.io/kubernetes/pkg/client/unversioned/clientcmd/api/latest) > > Don't know about the required dependencies versions. > > I see also that several dependencies have been added to minishift git 250c9ed compared to beta5. > > https://copr.fedorainfracloud.org/coprs/logic/vault/ seems working on getting some of the dependencies into Fedora, > > but there are also several packages present in Fedora but absent in EPEL7 (the main one: k8s). > > Hi Marcin, Thanks for taking the initiative. WIll take a look and see if I can find a way to fix this. In the mean time can you please put the the spec file some place ( may be in a temporary github repository), so that we can collaborate on this? Thanks, Lala > Marcin > > >> >> >>> Second we need to build the minishift-centos ISO in CBS. I will send you >>> a separate mail on this and lets collaborate. >>> >> >> Marcin >> >> >>> Thanks, >>> Lala >>> >>>> >>>> Marcin >>>> >>>> >>>>> >>>>> >>>>> >>>>> *Release announcement for Minishift 1.0.0-Beta.5 : * >>>>> >>>>> The Minishift team is pleased to announce the release of Minishift >>>>> 1.0.0 Beta 5. >>>>> >>>>> Minishift [1] is a command-line tool that provisions and manages >>>>> single-node OpenShift clusters optimized for development workflows. You can >>>>> run Minishift on GNU/Linux, Microsoft Windows or macOS. >>>>> >>>>> Release highlights >>>>> >>>>> ------------------------ >>>>> >>>>> This release adds several features, enhancements, and bug fixes, >>>>> including: >>>>> >>>>> - >>>>> >>>>> Minishift is now configured to use nip.io instead of xip.io [4]. >>>>> - >>>>> >>>>> The default routes for application will be created with the <VM >>>>> IP>.nip.io routing suffix. >>>>> - >>>>> >>>>> The sudoers role was added to the “developer” user [5]. >>>>> - >>>>> >>>>> This role allows the “developer” to impersonate system:admin >>>>> when running a command. For example, you can run “$ oc get nodes --as >>>>> system:admin” while logged in as the developer user. >>>>> - >>>>> >>>>> An important bug for proxy server (http/https) support was fixed >>>>> [10]. >>>>> - >>>>> >>>>> We had a bug where registration was failing in proxy >>>>> environments. >>>>> - >>>>> >>>>> OpenShift related subcommands from the root context were moved >>>>> under the “minishift openshift” command [11]. >>>>> >>>>> >>>>> This release also includes many changes and bug fixes, which are >>>>> detailed in the release notes [2] and milestone [3] . For information >>>>> about getting started, using, and developing Minishift, see the >>>>> documentation [6]. >>>>> >>>>> Additional components >>>>> >>>>> ----------------------------- >>>>> >>>>> >>>>> - >>>>> >>>>> We released new versions of the Boot2Docker ISO (v1.0.2) [ 8] and >>>>> the CentOS ISO (v1.0.0-rc3) [7] images. >>>>> - >>>>> >>>>> We added the ‘fuse-sshfs’ package to both the ISO images. With >>>>> SSHFS, users can mount host folders. Currently this is a manual process [9] >>>>> but we are working on automating it. >>>>> >>>>> >>>>> Please give the new release a try and let us know your feedback. The >>>>> Minishift community hangs out at #minishift channel on Freenode and it is >>>>> the perfect place to discuss anything Minishift related. >>>>> >>>>> [1] https://github.com/minishift/minishift >>>>> >>>>> [2] https://github.com/minishift/minishift/releases/tag/v1.0.0-beta.5 >>>>> >>>>> [3] https://github.com/minishift/minishift/milestone/10 >>>>> >>>>> [4] https://github.com/minishift/minishift/issues/501 >>>>> >>>>> [5] https://github.com/minishift/minishift/issues/509 >>>>> >>>>> [6] https://github.com/minishift/minishift#documentation >>>>> >>>>> [7] https://github.com/minishift/minishift-centos-iso/releases/t >>>>> ag/v1.0.0-rc.3 >>>>> >>>>> [8] https://github.com/minishift/minishift-b2d-iso/releases/tag/v1.0.2 >>>>> >>>>> [9] https://github.com/minishift/minishift/blob/master/docs/mana >>>>> ging-minishift.md#sshfs >>>>> >>>>> [10] https://github.com/minishift/minishift/issues/489 >>>>> >>>>> [11] https://github.com/minishift/minishift/issues/465 >>>>> >>>>> >>>>> Thanks, >>>>> Lala >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CentOS-devel mailing list >>>>> CentOS-devel(a)centos.org >>>>> https://lists.centos.org/mailman/listinfo/centos-devel >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> CentOS-devel mailing list >>>> CentOS-devel(a)centos.org >>>> https://lists.centos.org/mailman/listinfo/centos-devel >>>> >>>> >>> >>> _______________________________________________ >>> CentOS-devel mailing list >>> CentOS-devel(a)centos.org >>> https://lists.centos.org/mailman/listinfo/centos-devel >>> >>> >> > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel(a)centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > >

9 years

Re: [CentOS-es] Problema con USB Disk HELP!!

by Ernesto Pérez Estévez

El mar, 06-09-2011 a las 10:46 -0300, Federico Don escribió: > Hola lista, tengo un problema con un disco usb, cuando enchufo el disco al > server me asigno /dev/sdc1, el disco esta en EXT4 y mi centos es Linux > version 2.6.18-164.11.1.el5 (Red Hat 4.1.2-46). Bien el problema es el > siguiente, de un momento a otro ls: reading directory .: Input/output error, > tiro un dmesg y veo qeu cambio el disco usb de particion: > separa el celular del cable del disco. saludos epe > sdc: Write Protect is off > sdc: Mode Sense: 38 00 00 00 > sdc: assuming drive cache: write through > SCSI device sdc: 1953525168 512-byte hdwr sectors (1000205 MB) > sdc: Write Protect is off > sdc: Mode Sense: 38 00 00 00 > sdc: assuming drive cache: write through > sdc:<6>EXT3 FS on dm-0, internal journal > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-1, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-5, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-2, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-6, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-7, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-3, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on dm-8, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda1, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > Adding 8552440k swap on /dev/VolGroup00/LVSwap. Priority:-1 extents:1 > across:8552440k > powernow-k8: Pre-initialization of ACPI failed > powernow-k8: Found 1 AMD Athlon(tm) II X2 245 Processor processors (2 cpu > cores) (version 2.20.00) > powernow-k8: Your BIOS does not provide _PSS objects. PowerNow! does not > work on SMP systems without _PSS objects. Complain to your BIOS vendor. > powernow-k8: Your BIOS does not provide _PSS objects. PowerNow! does not > work on SMP systems without _PSS objects. Complain to your BIOS vendor. > sdc1 > sd 2:0:0:0: Attached scsi disk sdc > sd 2:0:0:0: Attached scsi generic sg2 type 0 > usb-storage: device scan complete > NET: Registered protocol family 10 > lo: Disabled Privacy Extensions > IPv6 over IPv4 tunneling driver > eth0: no IPv6 routers present > EXT4-fs: barriers enabled > kjournald2 starting: pid 2815, dev sdc1:8, commit interval 5 seconds > EXT4 FS on sdc1, internal journal on sdc1:8 > EXT4-fs: delayed allocation enabled > EXT4-fs: file extents enabled > EXT4-fs: mballoc enabled > EXT4-fs: mounted filesystem sdc1 with ordered data mode > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > eth0: link down. > eth0: link up. > tnslsnr[2946]: segfault at 0000000000000018 rip 0000003115a70485 rsp > 00007fff0bcb96b0 error 4 > tnslsnr[9084]: segfault at 0000000000000018 rip 0000003115a70485 rsp > 00007fff101eaed0 error 4 > usb 1-4: reset high speed USB device using ehci_hcd and address 2 > usb 1-4: USB disconnect, address 2 > sd 2:0:0:0: SCSI error: return code = 0x00010000 > end_request: I/O error, dev sdc, sector 393094152 > sd 2:0:0:0: rejecting I/O to device being removed > sd 2:0:0:0: rejecting I/O to device being removed > sd 2:0:0:0: rejecting I/O to device being removed > sd 2:0:0:0: SCSI error: return code = 0x00010000 > end_request: I/O error, dev sdc, sector 393094392 > Aborting journal on device sdc1:8. > sd 2:0:0:0: rejecting I/O to device being removed > Buffer I/O error on device sdc1, logical block 121667584 > lost page write due to I/O error on sdc1 > JBD2: I/O error detected when updating journal superblock for sdc1:8. > journal commit I/O error > sd 2:0:0:0: rejecting I/O to device being removed > Buffer I/O error on device sdc1, logical block 13107232 > lost page write due to I/O error on sdc1 > sd 2:0:0:0: rejecting I/O to device being removed > Buffer I/O error on device sdc1, logical block 50855968 > lost page write due to I/O error on sdc1 > sd 2:0:0:0: rejecting I/O to device being removed > Buffer I/O error on device sdc1, logical block 61866016 > lost page write due to I/O error on sdc1 > scsi 2:0:0:0: rejecting I/O to dead device > ext4_abort called. > EXT4-fs error (device sdc1): ext4_journal_start_sb: Detected aborted journal > Remounting filesystem read-only > usb 1-4: new high speed USB device using ehci_hcd and address 3 > usb 1-4: configuration #1 chosen from 1 choice > scsi3 : SCSI emulation for USB Mass Storage devices > usb-storage: device found at 3 > usb-storage: waiting for device to settle before scanning > Vendor: ST310005 Model: 20AS Rev: > Type: Direct-Access ANSI SCSI revision: 04 > SCSI device sdd: 1953525168 512-byte hdwr sectors (1000205 MB) > sdd: Write Protect is off > sdd: Mode Sense: 38 00 00 00 > sdd: assuming drive cache: write through > SCSI device sdd: 1953525168 512-byte hdwr sectors (1000205 MB) > sdd: Write Protect is off > sdd: Mode Sense: 38 00 00 00 > sdd: assuming drive cache: write through > sdd: sdd1 > sd 3:0:0:0: Attached scsi disk sdd > sd 3:0:0:0: Attached scsi generic sg2 type 0 > usb-storage: device scan complete > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > EXT3-fs: sdd1: couldn't mount because of unsupported optional features > (240). > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs error (device sdc1): ext4_find_entry: reading directory #2 offset 0 > scsi 2:0:0:0: rejecting I/O to dead device > scsi 2:0:0:0: rejecting I/O to dead device > EXT4-fs: barriers enabled > kjournald2 starting: pid 15697, dev sdd1:8, commit interval 5 seconds > EXT4 FS on sdd1, internal journal on sdd1:8 > EXT4-fs: delayed allocation enabled > EXT4-fs: file extents enabled > EXT4-fs: mballoc enabled > EXT4-fs: recovery complete. > EXT4-fs: mounted filesystem sdd1 with ordered data mode > usbcore: registered new driver usbserial > drivers/usb/serial/usb-serial.c: USB Serial support registered for generic > usbcore: registered new driver usbserial_generic > drivers/usb/serial/usb-serial.c: USB Serial Driver core > drivers/usb/serial/usb-serial.c: USB Serial support registered for GSM modem > (1-port) > usbcore: registered new driver option > drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1 > > El equipo no se reinicio " uptime 10:51:04 up 6 days, 15:14, 1 user, > load average: 0.03, 0.91, 2.25 " > > Alguien me puede guiar por donde puede venir el problema de que cambie por > si solo!!?? ahora tengo montado asi= > > /dev/sdc1 917G 221G 650G 26% /mnt/disk2 > /dev/sdd1 917G 221G 650G 26% /mnt/disk2 > > donde sdd1 es donde se encuentra en este momento y sdc1 no me permite > desmontar > > umount /dev/sdc1 > umount: /mnt/disk2: device is busy > umount: /mnt/disk2: device is busy > > Help me!!!!! > > Gracias a todos por su tiempo!! > _______________________________________________ > CentOS-es mailing list > CentOS-es(a)centos.org > http://lists.centos.org/mailman/listinfo/centos-es >

14 years, 7 months

SOLVED Re: [CentOS] Need basic PPPoE startup help

by Robert Moskowitz

I did a lot of googling today and made two changes, got brave, rebooted and everything is working. Everything was ready and right in my ifcfg-ppp0 for IPv4, just needed the ONBOOT=yes And IPv6 allocation needed in ifcfg-ppp0: IPV6INIT=yes PPPD_EXTRA="ipv6 ," Not the later can be placed in /etc/ppp/options, but I thought it better to keep all PPPoE customizations in one place. Robert Moskowitz wrote: > I need basic PPPoE startup help. > > adsl-start DID bring up my PPPoE link (ppp0) to my ISP over eth0 via > the DSL modem/bridge. My IPv4 CIDR block is routing and Shorewall is > doing the firewalling. > > But shorewall has to be started after ppp0 is up and working. For now > this means running shorewall restart (or start?). Shorewall 4.2 will > have a way to restart shorewall without recompiling, I learned on the > their list. > > In /etc/sysconfig/network-scripts/ifcfg-ppp0 I have: > > BOOTPROTO=dialup > NAME=DSLppp0 > DEVICE=ppp0 > TYPE=xDSL > ONBOOT=no > > Should ONBOOT be changed to yes, or is there some startup script that > I should add the > > /sbin/adsl-start ppp0 > > command line followed with the shorewall restart command? > > I am away at IEEE 802 plenary meeting next week, and I need this to be > automated in case of system glitches. > > Also sometimes the Speedstream just stops forwarding datagrams. > Supposedly if it overheats. This requires a power recycle for the > speedstream (and my ISP will not use anything else for the modem > services). I suspect this will glich the PPPoE connection as well, so > I will need some sort of watchdog and a restart of ppp0 and Shorewall. > Attached is a rather large script of a user that I picked up on the > Shorewall list for some Linux distro. I am NOT a script reader, let > alone writer. Should I use this (how would I modify it for Centos and > a ppp0 interface) and where would I place it to run as needed? > > ======================================================= > > #!/usr/bin/perl -w > > #THIS SCRIPT CREATED BY EJM (alias Erik Mundall) IN ORDER TO MAINTAIN > A CONSTANT CONNECTION WITH THE TWO > #PPPOE ADSL LINES WHICH HAVE PROVEN TO BE UNRELIABLE/UNSTABLE. 15 > APRIL 2008 > # > #THIS PROGRAM NEEDS TO FOLLOW THE FOLLOWING ROUTINE IN ORDER TO > MAINTAIN CONNECTIVITY OF THE TWO PPPOE LINES > #AND TO SHARE THE INTERNET LOAD ACROSS THOSE AND ACROSS THE STATIC LINE > # > #THE STATIC SHOULD NEVER FAIL. THIS SCRIPT IS INTENDED TO ADDRESS ONLY > THE INSTABILITY OF THE TWO PPPOE > #LINES, AND WILL DO NOTHING FOR THE STATIC LINE IF IT SHOULD FAIL. > # > # > #STEP ONE: THE PROGRAM SHOULD IDENTIFY THE LINE(S) THAT ARE DOWN, IF > ANY, AND ISOLATE THEM. > #STEP TWO: THE PROGRAM SHOULD RECONFIGURE AND RESTART SHOREWALL TO > MATCH THE LINES THAT ARE UP. > #STEP THREE: THE PROGRAM SHOULD FOCUS ON RESTORING THE DROPPED PPPOE > LINE(S). > #STEP FOUR: THE PROGRAM MUST REPEAT STEP TWO ONCE STEP THREE HAS > SUCCEEDED. > > ############################################### > # REQUIRED VARIABLES. THESE MUST BE SET PROPERLY!!! > our $admin_email =q`your_email_address(a)your_domain_name.com`; > our $domain_name = "your_domain_name.com"; > our $GATEWAY_1 = 'x.x.x.x'; #GATEWAY OF PPP0 LINE > our $GATEWAY_2 = 'x.x.x.x'; #GATEWAY OF PPP1 LINE > our $IPADDRESS_1 = 'x.x.x.x'; #STATIC IP ADDRESS OF PPP0 LINE > (ASSIGNED BY ISP) > our $IPADDRESS_2 = 'x.x.x.x'; #STATIC IP ADDRESS OF PPP1 LINE > (ASSIGNED BY ISP) > > our $DEBUG=1; #SET THIS TO 1 FOR DEBUGGING, 0 TO TURN DEBUGGING OFF > our $DEBFILE='/var/log/ppp/debug.log'; #THE /var/log/ppp DIRECTORY > MUST EXIST FOR THE DEBUG FILE > our $logfile='/var/log/ppp/maint.log'; #THE /var/log/ppp DIRECTORY > MUST EXIST FOR LOGGING. > > ############################################### > # BELOW THIS LINE, NOTHING MORE SHOULD NEED TO BE CONFIGURED. > our @ifconf = (); > our @iprout = `/sbin/ip route`; > our $p1; > our $p2; > our $ppp0=0; > our $ppp1=0; > our $FAILED='FALSE'; > our $FAIL='TRUE'; > our $attempt=0; > our $date=''; > our @data=(); > our @updata=(); > our @log=(); > our @total_log=(); > our $cur_day=0; > our $cur_month=0; > our $cur_year=0; > our $late_day=0; > our $late_month=0; > our $late_year=0; > our > %months=(Jan,1,Feb,2,Mar,3,Apr,4,May,5,Jun,6,Jul,7,Aug,8,Sep,9,Oct,10,Nov,11,Dec,12); > > our $start_time=`/bin/date`; > our $stop_time; > > ############################################# > ### SAFEGUARD AGAINST MULTIPLE PROCESSES! ### > ############################################# > our @pslist = `/bin/ps auxw`; > our $line=''; > our $scripts=0; > > foreach $line(@pslist) { > if ($line=~s/(ppp-line-maintenance\.pl)/$1/) { #THIS SCRIPT MUST NOT > BE RENAMED, OR IF IT IS, THIS LINE MUST BE ADJUSTED ACCORDINGLY!!!! > $scripts++; > if ($DEBUG==1) {print "Line:$line\nScripts:$scripts\n" }; > }; > }; > if ($scripts<=2) { #CONTINUE THIS SCRIPT IF ONLY ONE OCCURRENCE (THIS > ONE) OF THIS SCRIPT IN CURRENT PROCESS LIST > > > ############# > ### BEGIN ### > ############# > if ($DEBUG==1) {open DLOG, ">$DEBFILE" or die "Cannot open debugging > file!\n"}; > > > &ping1; > &ping2; > &checkdowned; > &trimlog; > > if ($DEBUG==1) {close DLOG}; > > } #END 'CONTINUE SCRIPT' > > sleep 2; > > exit; > > > ###################################################################################################### > > ### SUBROUTINES ### > ################### > > sub ping1 { > $p1=`/bin/ping -c 3 $GATEWAY_1`; > if ($p1=~s/100\%\spacket\sloss//) {$p1='DOWN'}; > if ($p1=~s/unreachable//) {$p1='DOWN'}; > if ($DEBUG==1) {print DLOG "p1:$p1\n"}; > return $p1; > }; > > sub ping2 { > $p2=`/bin/ping -c 3 $GATEWAY_2`; if ($p2=~s/100\%\spacket\sloss//) > {$p2='DOWN'}; > if ($p2=~s/unreachable//) {$p2='DOWN'}; > if ($DEBUG==1) {print DLOG "p2:$p2\n"}; > return $p2; > }; > > > sub trimlog { > ################ > ### TRIM LOG ### > ################ > # THIS PRUNES THE LOG FILE TO JUST THE PREVIOUS THREE MONTH PERIOD. > open DATA, "<$logfile" or die "Cannot read PPP maint log file!\n"; > @data = <DATA>; > close DATA; > $date = `/bin/date`; > #$cur_month = > (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[(localtime)[4]]; > $cur_month = (localtime)[4]; > $cur_year = (localtime)[5]; $cur_year+=1900; > $cur_day = (localtime)[3]; > #PPP Check: Wed Jan 30 09:20:01 CST 2008 [sample from log] > foreach $line(@data) { > if ($line=~m/PPP\sCheck:\s\w{3}\s(\w{3})\s(\d{2}).{14}(\d{4})/) { > $late_month=$months{$1}; $late_day=$2; $late_year=$3; > if ( ($late_year==$cur_year) && ( (($cur_month-$late_month)>=3) && > ($late_day<=$cur_day) ) ) {@updata=()} > elsif ( ($late_year<$cur_year) && ( (($late_month-$cur_month)<=9) && > ($late_day<=$cur_day) ) ) {@updata=()} > else { push @updata, $line } > } else { push @updata, $line }; > } > open DATA, ">$logfile" or die "Cannot write PPP maint log file!\n"; > print DATA @updata; > close DATA; > ################### END TRIM LOG > }; > > ############################## > ### Check for Downed Lines ### > ############################## > > sub checkdowned { > while ($FAIL eq 'TRUE') { > @ifconf=(); > @ifconf = `/sbin/ifconfig`; > $FAIL='FALSE'; > > while (@ifconf) { > $line=shift @ifconf; > if ($line=~m/ppp0/) { > if ($DEBUG==1) {print DLOG "PPPO:$ppp0 "}; > > $ppp0=1; > if ($DEBUG==1) {print DLOG "PPPO:$ppp0 "}; > > $line=shift @ifconf; > if ($line=~m/$IPADDRESS_1/) {$ppp0+=2}; > if ($DEBUG==1) {print DLOG "PPPO:$ppp0 "}; > $line=shift @ifconf; > if ($line=~m/UP /) {$ppp0+=4}; > if ($DEBUG==1) {print DLOG "PPPO:$ppp0\n"}; > }; > if ($line=~m/ppp1/) { > if ($DEBUG==1) {print DLOG "PPP1:$ppp1 "}; > $ppp1=1; > if ($DEBUG==1) {print DLOG "PPP1:$ppp1 "}; > $line=shift @ifconf; > if ($line=~m/$IPADDRESS_2/) {$ppp1+=2}; > if ($DEBUG==1) {print DLOG "PPP1:$ppp1 "}; > $line=shift @ifconf; > if ($line=~m/UP /) {$ppp1+=4}; > if ($DEBUG==1) {print DLOG "PPP1:$ppp1\n"}; > print $line > }; > } > > $attempt++; > if ($DEBUG==1) {print "ATTEMPT: $attempt\n"}; > if ($FAILED eq 'TRUE') {push @log, "Attempt#:$attempt > PPP0:$ppp0 > PPP1:$ppp1\n"}; > > if ($ppp0<7) { > if ($DEBUG==1) {print "$ppp0: Restarting ppp0 line by ifdown/ifup > commands...\n"}; > system("/sbin/ifdown ppp0"); > sleep 3; > system("/sbin/ifup ppp0"); > }; > if ($ppp1<7) { > if ($DEBUG==1) {print "$ppp1: Restarting ppp1 line by ifdown/ifup > commands...\n"}; > system("/sbin/ifdown ppp1"); > sleep 3; > system("/sbin/ifup ppp1"); > }; > if ($FAILED eq 'TRUE') { > push @log, `/bin/date`."\n"; > push @log, @iprout."\n\n"; > open LOG, ">>$logfile"; > print LOG @log; > close LOG; > } > push @total_log, @log; > @log=(); > > my $testppp0=ping0; > my $testppp1=ping1; > if ($DEBUG==1) {print "testppp0: $testppp0 testppp1:$testppp1\n"}; > if (($testppp0 eq 'DOWN') || ($testppp1 eq 'DOWN')) { $FAIL='TRUE' }; > if ($FAIL eq 'TRUE') {$FAILED='TRUE'}; > if ($DEBUG==1) {print DLOG "FAIL:$FAIL\n"}; > > > if ($FAILED eq 'TRUE') { > > system("/etc/init.d/shorewall", "restart"); > system("/etc/init.d/snmpd restart"); > open LOG, ">>$logfile" or die "Cannot open PPP maint log file!\n"; > print LOG @log; > close LOG; > push @total_log, @log; > $stop_time=`/bin/date`; > > ######################################################################################################### > > #NOW, SEND AN EMAIL OR CAUSE AN ERROR SO THAT CRON WILL EMAIL THE > SYSADMIN A NOTICE OF THIS NECESSITY!!! > system("/bin/mail -t <<EOF > To: $admin_email > From: pppoe-maintenance\@$domain_name > Subject: PPPoE Dropped Connection Restored!\n\n > > A PPPoE Connection was dropped or was lost. It should now be restored. > The restoration of the line began at: > > $start_time -- and finished at -- $stop_time. > > Here is the log from this process: > > @total_log > > END OF REPORT. > > EOF > "); > ############################################################################################################ > > > } else { > > open LOG, ">>$logfile" or die "Cannot open PPP maint log file!\n"; > print LOG "PPP Check: ".`/bin/date`; > close LOG; > }; #END IF FAILED > } #END WHILE FAIL > > print "SUCCEEDED AFTER $attempt ATTEMPTS!\n"; > } #END SUB CHECKDOWNED > > > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos >

17 years, 8 months

Re: [CentOS] Could not complete SSL handshake to Amazon EC2 host

by Eric Lehmann

Hi NRPE: Error receiving data from daemon Seems as this is not a SSL Problem. Do you have a nagios user account? Cat /etc/passwd Am 01.05.2015 18:45 schrieb "Tim Dunphy" <bluethundr(a)gmail.com>: > > > > Oh my mistake. I mean nrpe without parameters. It should say something > > about SSL/TLS aktiv or so. > > You could test nrpe without SSL. Use nrpe -n - H host > > > > This is what I see about ssl if I just run nrpe on the client without any > flags: > > [root@ops:~] #nrpe| head -8 > > NRPE - Nagios Remote Plugin Executor > Copyright (c) 1999-2008 Ethan Galstad (nagios(a)nagios.org) > Version: 2.15 > Last Modified: 09-06-2013 > License: GPL v2 with exemptions (-l for more info) > SSL/TLS Available: Anonymous DH Mode, OpenSSL 0.9.6 or higher required > TCP Wrappers Available > > And if I go back to the monitoring host and try to run nrpe with the -n > flag, this is what I get: > > [root@monitor1:~] #/usr/local/nagios/libexec/check_nrpe -n -H > ops.jokefire.com > *CHECK_NRPE: Error receiving data from daemon.* > > And still getting the SSL error without the -n flag: > > [root@monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H > ops.jokefire.com > *CHECK_NRPE: Error - Could not complete SSL handshake.* > > Running nmap from the monitor host I can see that the nrpe port is open: > > [root@monitor1:~] #nmap -p 5666 ops.jokefire.com > > Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-01 12:38 EDT > Nmap scan report for ops.jokefire.com (54.225.218.125) > Host is up (0.011s latency). > rDNS record for 54.225.218.125: ec2-54-225-218-125.compute-1.amazonaws.com > PORT STATE SERVICE > *5666/tcp open nrpe* > > Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds > > Yet if I try telnetting to it, it connects, then closes the connection > immediately: > > [root@monitor1:~] #telnet ops.jokefire.com 5666 > Trying 54.225.218.125... > *Connected to ops.jokefire.com <http://ops.jokefire.com>.* > Escape character is '^]'. > *Connection closed by foreign host.* > > Going back to the ops host that I want to monitor, I can verify that the > port is listening: > > [root@ops:~] #lsof -i :5666 > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > xinetd 1434 root 5u IPv4 4063 TCP *:nrpe (LISTEN) > > > And I can verify that the nrpe conf is owned by the nagios user and group: > > [root@ops:~] #ls -l /usr/local/nagios/etc/nrpe.cfg > -rw-r--r-- 1 nagios nagios 7988 May 1 00:37 /usr/local/nagios/etc/nrpe.cfg > > I think that covers all your suggestions. Except for Eero's suggestion to > try running nrpe without xinetd. I can try to get to that later, but I may > not have time for that suggestion today. But as I demonstrate above, the > problem is not that nrpe isn't listening. > > This remains a really odd situation. Does anyone else have any clues? > > Thanks, > Tim > > > > On Fri, May 1, 2015 at 7:43 AM, Eric Lehmann <e.lehmann88(a)gmail.com> > wrote: > > > Oh my mistake. I mean nrpe without parameters. It should say something > > about SSL/TLS aktiv or so. > > You could test nrpe without SSL. Use nrpe -n - H host > > Am 01.05.2015 13:18 schrieb "Eero Volotinen" <eero.volotinen(a)iki.fi>: > > > > > well. how about trying default setting and running nrped without > xinetd. > > > > > > -- > > > Eero > > > > > > 2015-05-01 14:14 GMT+03:00 Tim Dunphy <bluethundr(a)gmail.com>: > > > > > > > > This is strange... > > > > > Do you have SSL aktive on both systems? Run nrpr localy without > > > > parameters > > > > > (this should return some nrpe stats) and check ldd for libssl. > > > > > > > > > > > > I don't seem to have that command. > > > > > > > > > > > > [root@monitor1:~] #find / -name "*nrpr" 2> /dev/null > > > > [root@monitor1:~] # > > > > > > > > And that's on either system. > > > > > > > > And if I do an ldd on both, this is what I can tell: > > > > > > > > Server: > > > > > > > > [root@monitor1:~] #ldd /usr/local/nagios/libexec/check_nrpe > > > > linux-vdso.so.1 => (0x00007fffd895d000) > > > > * libssl.so.10 => /lib64/libssl.so.10 (0x00007fc61722a000)* > > > > * libcrypto.so.10 => /lib64/libcrypto.so.10 > > (0x00007fc616e43000)* > > > > libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fc616c29000) > > > > libc.so.6 => /lib64/libc.so.6 (0x00007fc616868000) > > > > libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 > > > > (0x00007fc61661c000) > > > > libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fc616338000) > > > > libcom_err.so.2 => /lib64/libcom_err.so.2 > (0x00007fc616134000) > > > > libk5crypto.so.3 => /lib64/libk5crypto.so.3 > > (0x00007fc615f02000) > > > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fc615cfd000) > > > > libz.so.1 => /lib64/libz.so.1 (0x00007fc615ae7000) > > > > /lib64/ld-linux-x86-64.so.2 (0x00007fc6174a0000) > > > > libkrb5support.so.0 => /lib64/libkrb5support.so.0 > > > > (0x00007fc6158d8000) > > > > libkeyutils.so.1 => /lib64/libkeyutils.so.1 > > (0x00007fc6156d3000) > > > > libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc6154b9000) > > > > libpthread.so.0 => /lib64/libpthread.so.0 > (0x00007fc61529d000) > > > > libselinux.so.1 => /lib64/libselinux.so.1 > (0x00007fc615077000) > > > > libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fc614e16000) > > > > liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc614bf1000) > > > > > > > > > > > > Client: > > > > > > > > [root@ops:~] #ldd /usr/local/nagios/libexec/check_nrpe > > > > * libssl.so.6 => /lib64/libssl.so.6 (0x00002aaaaaaba000)* > > > > * libcrypto.so.6 => /lib64/libcrypto.so.6 > (0x00002aaaaad08000)* > > > > libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaab05a000) > > > > libc.so.6 => /lib64/libc.so.6 (0x00002aaaab273000) > > > > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > > > > (0x00002aaaab5cc000) > > > > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaab7fa000) > > > > libcom_err.so.2 => /lib64/libcom_err.so.2 > (0x00002aaaaba90000) > > > > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 > > > > (0x00002aaaabc92000) > > > > libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaabeb7000) > > > > libz.so.1 => /lib64/libz.so.1 (0x00002aaaac0bc000) > > > > /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) > > > > libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0 > > > > 0002aaaac2d0000) > > > > libkeyutils.so.1 => /lib64/libkeyutils.so.1 > > (0x00002aaaac4d8000) > > > > libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaac6db000) > > > > libselinux.so.1 => /lib64/libselinux.so.1 > (0x00002aaaac8f0000) > > > > libsepol.so.1 => /lib64/libsepol.so.1 (0x00002aaaacb09000) > > > > > > > > > > > > So it looks like everything is OK from the SSL end of things. Any > other > > > > ideas or suggestions? > > > > > > > > Thanks > > > > Tim > > > > > > > > On Fri, May 1, 2015 at 5:46 AM, Eric Lehmann <e.lehmann88(a)gmail.com> > > > > wrote: > > > > > > > > > This is strange... > > > > > Do you have SSL aktive on both systems? Run nrpr localy without > > > > parameters > > > > > (this should return some nrpe stats) and check ldd for libssl. > > > > > Am 01.05.2015 07:32 schrieb "Tim Dunphy" <bluethundr(a)gmail.com>: > > > > > > > > > > > Hi Eric, > > > > > > > > > > > > Thanks for your reply. I do have nrpe running under xinetd on > the > > > host > > > > > I'm > > > > > > trying to monitor. > > > > > > > > > > > > And running the nrpe checl locally: > > > > > > > > > > > > [root@ops:~] #/usr/local/nagios/libexec/check_nrpe -H localhost > > > > > > NRPE v2.15 > > > > > > > > > > > > [root@ops:~] #grep only_from /etc/xinetd.d/nrpe > > > > > > only_from = 127.0.0.1 216.120.248.126 > > > > > > > > > > > > And I do have port 5666 open on the security group for this host. > > > > > > > > > > > > And I made sure the local firewall was stopped, because I am > > blocking > > > > > ports > > > > > > with the security groups instead. > > > > > > > > > > > > [root@ops:~] #service iptables status > > > > > > Firewall is stopped. > > > > > > > > > > > > It's only when checking from the monitoring host that nrpe fails: > > > > > > > > > > > > [root@monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H > > > > > > ops.jokefire.com > > > > > > CHECK_NRPE: Error - Could not complete SSL handshake. > > > > > > > > > > > > Really, really puzzling. This is driving me up a wall!! I hopeI > can > > > > solve > > > > > > this soon.... > > > > > > > > > > > > Thanks for any and all help with this one!! > > > > > > Tim > > > > > > > > > > > > On Fri, May 1, 2015 at 1:02 AM, Eric Lehmann < > > e.lehmann88(a)gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hi > > > > > > > Does the deamon run under xinetd? Then you have to configure > the > > > > > > only_from > > > > > > > in */etc/**xinetd.d**/**nrpe* to. > > > > > > > > > > > > > > Regards > > > > > > > Eric > > > > > > > Am 01.05.2015 06:46 schrieb "Tim Dunphy" <bluethundr(a)gmail.com > >: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > I am trying to monitor a host in the Amazon EC2 cloud. > > > > > > > > > > > > > > > > Yet when I try to check NRPE from the monitoring host I am > > > getting > > > > an > > > > > > SSL > > > > > > > > handshake error: > > > > > > > > > > > > > > > > [root@monitor1:~] #/usr/local/nagios/libexec/check_nrpe -H > > > > > > > > ops.jokefire.com > > > > > > > > CHECK_NRPE: Error - Could not complete SSL handshake. > > > > > > > > > > > > > > > > And if I telnet into the host on port 5666 to see if the FW > > port > > > is > > > > > > open, > > > > > > > > the connection closes right away: > > > > > > > > > > > > > > > > [root@monitor1:~] #telnet ops.somewhere.com 5666 > > > > > > > > Trying 54.225.218.125... > > > > > > > > Connected to ops.somewhere.com. > > > > > > > > Escape character is '^]'. > > > > > > > > Connection closed by foreign host. > > > > > > > > > > > > > > > > You can see there it connects, but then it closes immediately > > > after > > > > > the > > > > > > > > connection. > > > > > > > > > > > > > > > > I have NRPE running on the host I want to monitor: > > > > > > > > > > > > > > > > [root@ops:~] #lsof -i :5666 > > > > > > > > COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME > > > > > > > > xinetd 1434 root 5u IPv4 4063 TCP *:nrpe > (LISTEN) > > > > > > > > > > > > > > > > And I have the IP of my nagios server listed in the xinetd > conf > > > > file: > > > > > > > > > > > > > > > > [root@ops:~] #cat /etc/xinetd.d/nrpe > > > > > > > > # default: on > > > > > > > > # description: NRPE (Nagios Remote Plugin Executor) > > > > > > > > service nrpe > > > > > > > > { > > > > > > > > flags = REUSE > > > > > > > > socket_type = stream > > > > > > > > port = 5666 > > > > > > > > wait = no > > > > > > > > user = nagios > > > > > > > > group = nagios > > > > > > > > server = /usr/local/nagios/bin/nrpe > > > > > > > > server_args = -c /usr/local/nagios/etc/nrpe.cfg > > > --inetd > > > > > > > > log_on_failure += USERID > > > > > > > > disable = no > > > > > > > > only_from = 127.0.0.1 xx.xx.xx.xx # <- > > > representing > > > > > my > > > > > > > real > > > > > > > > nagios server IP > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And I have my default security group for that host open on > port > > > > 5666 > > > > > to > > > > > > > the > > > > > > > > world for this experiment. I plan on locking that down again > > to > > > > the > > > > > > > single > > > > > > > > IP of my monitoring host once I get this resolved. > > > > > > > > > > > > > > > > Does anyone have any suggestions on how I can get that > problem > > > > > solved? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Tim > > > > > > > > > > > > > > > > -- > > > > > > > > GPG me!! > > > > > > > > > > > > > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > > > > > > _______________________________________________ > > > > > > > > CentOS mailing list > > > > > > > > CentOS(a)centos.org > > > > > > > > http://lists.centos.org/mailman/listinfo/centos > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > CentOS mailing list > > > > > > > CentOS(a)centos.org > > > > > > > http://lists.centos.org/mailman/listinfo/centos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > GPG me!! > > > > > > > > > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > > > > _______________________________________________ > > > > > > CentOS mailing list > > > > > > CentOS(a)centos.org > > > > > > http://lists.centos.org/mailman/listinfo/centos > > > > > > > > > > > _______________________________________________ > > > > > CentOS mailing list > > > > > CentOS(a)centos.org > > > > > http://lists.centos.org/mailman/listinfo/centos > > > > > > > > > > > > > > > > > > > > > -- > > > > GPG me!! > > > > > > > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > > > > _______________________________________________ > > > > CentOS mailing list > > > > CentOS(a)centos.org > > > > http://lists.centos.org/mailman/listinfo/centos > > > > > > > _______________________________________________ > > > CentOS mailing list > > > CentOS(a)centos.org > > > http://lists.centos.org/mailman/listinfo/centos > > > > > _______________________________________________ > > CentOS mailing list > > CentOS(a)centos.org > > http://lists.centos.org/mailman/listinfo/centos > > > > > > -- > GPG me!! > > gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos >

10 years, 11 months

Re: [CentOS-pt-br] Digest CentOS-pt-br, volume 32, assunto 28

by Marcelo Carvalho

centos-pt-br-request(a)centos.org escreveu: > Enviar submissões para a lista de discussão CentOS-pt-br para > centos-pt-br(a)centos.org > > Para se cadastrar ou descadastrar via WWW, visite o endereço > http://lists.centos.org/mailman/listinfo/centos-pt-br > ou, via email, envie uma mensagem com a palavra 'help' no assunto ou > corpo da mensagem para > centos-pt-br-request(a)centos.org > > Você poderá entrar em contato com a pessoa que gerencia a lista pelo > endereço > centos-pt-br-owner(a)centos.org > > Quando responder, por favor edite sua linha Assunto assim ela será > mais específica que "Re: Contents of CentOS-pt-br digest..." > > > Tópicos de Hoje: > > 1. RES: Problemas com spam (Marcelo Gondim) > 2. Bloquear e-mails de saida no Sendmail (Netsul - Valcir) > 3. Re: Bloquear e-mails de saida no Sendmail (Fabio Rampazzo Mathias) > 4. Re: Dns (Paulo R Santos) > 5. [OT] - Estrutura de armazenamento de uma grande quantidade de > arquivos (Fábio Jr.) > 6. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (irado furioso com tudo) > 7. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Bruno L F Cabral) > 8. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Leandro Cerqueira) > 9. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Vinicius Lage) > 10. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Fábio Jr.) > 11. Re: Bloquear e-mails de saida no Sendmail (Netsul - Valcir) > 12. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Fábio Jr.) > 13. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Fábio Jr.) > 14. Re: Digest CentOS-pt-br, volume 32, assunto 26 > (Fabiano Souza de Azevedo) > 15. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Fabio Rampazzo Mathias) > 16. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Lucas Timm LH) > 17. Re: [OT] - Estrutura de armazenamento de uma grande > quantidade de arquivos (Gilberto Nunes) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 26 Nov 2009 15:13:40 -0200 > From: "Marcelo Gondim" <gondim(a)linuxinfo.com.br> > Subject: [CentOS-pt-br] RES: Problemas com spam > To: "'Portuguese $Brazilian$ CentOS mailing list'" > <centos-pt-br(a)centos.org> > Message-ID: <002a01ca6ebb$cd097810$671c6830$(a)com.br> > Content-Type: text/plain; charset="iso-8859-1" > > Bem, na verdade seria interessante mais detalhes sobre o servidor como por > exemplo: é linux ou Windows? > Algumas coisas que já aconteceram comigo: > > 1) Tenho um servidor CentOS rodando postfix+amavis+clamd com > squirrelmail(webmail). Tive problemas com contas de usuários que mudaram > suas senhas para algo realmente seguro como 12345 ou fulano(a)dominio.com.br > com senha fulano e por aí vai. O interessante é que um indivíduo desse > poderia por também a sua conta bancária com senha 12345 né? Seria tão mais > fácil para o bandido. Bem voltando à questão como essas contas tinham senhas > muito fáceis spammers de fora entraram nessas contas e através do próprio > webmail enviam spam para Deus e o mundo. Catei essas contas e bloqueei > sugerindo aos donos delas que alterassem suas senhas para algo mais difícil > sob pena de perderem suas contas de e-mail. Resolvido! :) > > 2) Outro caso bem semelhante que aconteceu com senhas fáceis mas os spammers > enviavam os e-mails pelo servidor usando autenticação do SASL. Também fiz o > mesmo procedimento acima e resolveu. > > Tudo isso você pode nos logs do servidor de correio. :) > > No meu caso não eram vírus, eram usuários ignorantes que não possuem cultura > alguma de Internet e acham que basta sentar na frente do micro e acessar a > Internet sem o menor cuidado. Que acham que senhas tem que ser tão fáceis > que até mesmo meu filho de 2 anos saberia digitá-las. :D > Essas mesmas pessoas o dia que forem lesadas acharão ruim e colocarão a > culpa no provedor, na Internet, no técnico mas nunca neles mesmo por usarem > uma senha tão ridícula e por terem comportamento descuidado. > > Marcelo dá uma checada se pode ser uma dessas coisas que disse e qualquer > coisa estaremos aqui :) > > Grande abraço > > > > -----Mensagem original----- > De: centos-pt-br-bounces(a)centos.org [mailto:centos-pt-br-bounces@centos.org] > Em nome de Marcelo Carvalho > Enviada em: quinta-feira, 26 de novembro de 2009 14:49 > Para: centos-pt-br(a)centos.org > Assunto: [CentOS-pt-br] Problemas com spam > > Galera, > > Talvez esteva fora do foco da lista, mas ai vai: > > Tenho uma conta de e-mail que esta recebendo muitos spams. Nosso > servidor de e-mail fica em um datacenter, falei com o pessoal do > suporte, eles checaram os cabeçalhos no servidor e me disseram que estes > envios estão partindo do ip desta mesma máquina. Eles afirmaram que se > trata de um vírus, ja chequei a máquina com nosso antivirus e outras > ferramentas e não foi encontrado nada. Esta afirmação de vírus procede > ou não existe vírus deste tipo? > > Desde já agradeço, > > Marcelo > > > > __________ Informação do ESET NOD32 Antivirus, versão da vacina 4639 > (20091126) __________ > > A mensagem foi verificada pelo ESET NOD32 Antivirus. > > http://www.eset.com > > > > > ------------------------------ > > Message: 2 > Date: Thu, 26 Nov 2009 17:09:36 -0200 > From: Netsul - Valcir <valcir(a)netsulsolutions.com.br> > Subject: [CentOS-pt-br] Bloquear e-mails de saida no Sendmail > To: Centos - Br <centos-pt-br(a)centos.org> > Message-ID: <4B0ED270.8090509(a)netsulsolutions.com.br> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Boa tarde turma, > > Seguinte, já li na documentação do Sendmail que dá pra bloquear um > destinatário usando a tag "To:fulano@dominio.com.br ERROR:"Aviso > ao usuario" ou "REJECT" no arquivo /etc/mail/access. Porém já fiz de > tudo e não consigo bloquear a saida, somente a entrada com o > From:fulano@dominio. Com o from: funciona perfeito, com to: não bloqueia > nem para dominios externos, nem para destinatários do próprio dominio. > > Uso CentOS 5 e sendmail 8.13 e mantenho o arquivo sendmail.mc nas > configurações padrão (apenas habilito masquerade_envelope). > > Alguém tem alguma idéia do que pode ser? > > Valcir. > > > ------------------------------ > > Message: 3 > Date: Thu, 26 Nov 2009 17:24:53 -0200 > From: Fabio Rampazzo Mathias <fmathias(a)gmail.com> > Subject: Re: [CentOS-pt-br] Bloquear e-mails de saida no Sendmail > To: "Portuguese (Brazilian) CentOS mailing list" > <centos-pt-br(a)centos.org> > Message-ID: > <f63f0cde0911261124j234e3bf2ve8fbe98ab1b80cf3(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Cara, não conheço o sendmail. Mas de qualquer forma, quando configurei ele, > o /etc/mail/access era para permitir hosts a conectarem no servidor.... > > Dá uma olhada em > > http://www.freebsd.org/doc/en/books/handbook/sendmail.html > > "The access database defines what host(s) or IP addresses have access to the > local mail server and what kind of access they have" > > abraços > > > 2009/11/26 Netsul - Valcir <valcir(a)netsulsolutions.com.br> > > >> Boa tarde turma, >> >> Seguinte, já li na documentação do Sendmail que dá pra bloquear um >> destinatário usando a tag "To:fulano@dominio.com.br<To%3Afulano(a)dominio.com.br> ERROR:"Aviso >> ao usuario" ou "REJECT" no arquivo /etc/mail/access. Porém já fiz de >> tudo e não consigo bloquear a saida, somente a entrada com o >> From:fulano@dominio. Com o from: funciona perfeito, com to: não bloqueia >> nem para dominios externos, nem para destinatários do próprio dominio. >> >> Uso CentOS 5 e sendmail 8.13 e mantenho o arquivo sendmail.mc nas >> configurações padrão (apenas habilito masquerade_envelope). >> >> Alguém tem alguma idéia do que pode ser? >> >> Valcir. >> _______________________________________________ >> CentOS-pt-br mailing list >> CentOS-pt-br(a)centos.org >> http://lists.centos.org/mailman/listinfo/centos-pt-br >> >> > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: http://lists.centos.org/pipermail/centos-pt-br/attachments/20091126/c6f4eae… > > ------------------------------ > > Message: 4 > Date: Thu, 26 Nov 2009 20:37:48 -0200 > From: Paulo R Santos <prsantos1(a)gmail.com> > Subject: Re: [CentOS-pt-br] Dns > To: "Portuguese (Brazilian) CentOS mailing list" > <centos-pt-br(a)centos.org> > Message-ID: > <457646a80911261437x7f5523c4x7e47afa75c3fb607(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Valeu gente ... agora cabe a mim estudar e ver as melhores opçoes. > > brigadao! pelo menos por enquanto rererer > > > > 2009/11/26 Fabio Rampazzo Mathias <fmathias(a)gmail.com> > > >> Paulo, >> >> Você pode fazer de 2 formas : >> >> 1. Colocar 1 servidor de DNS e configurar diferentes ZONAS de solução de >> IPS. Uma interna e outra externa. >> >> 2. Colocar 2 servidores de DNS e configurar um para solução interna e outra >> externa. Depois configurar o roteamento adequadamente. >> >> De qualquer forma, seria legal ter servidores de DNS em redundância (2 no 1 >> caso e 4 no 2o caso). Claro que dependendo da necessidade. >> >> Ah, e já configure o servidor para rodar em CHROOT (igual do irado) pois é >> uma segurança a mais, principalmente para o DNS externo. >> >> Abraços >> >> On Wed, Nov 25, 2009 at 7:42 PM, irado furioso com tudo <irado(a)bsd.com.br>wrote: >> >> >>> Em Wed, 25 Nov 2009 18:07:01 -0200 >>> Paulo R Santos <prsantos1(a)gmail.com>, conhecido consumidor de drogas >>> (BigMac's com Coke) escreveu: >>> >>> >>>> a seguinte situação > o meu Servido é um centOs 5.4 que esta >>>> virtualizando o expreso mail, quero colocar o Bind9 no CentOs para >>>> ser o servidor de DNS. >>>> >>> eu fiz conforme está aqui: >>> >>> >>> http://irado-lembretes.blogspot.com/2009/05/bind-chroobind-chroot-no-centos… >>> >>> mas (IMHO, claro) vc deve incrementar com views para definir acesso >>> externo/interno e etc. Alguns links que podem ajudar, aqui: >>> >>> >>> http://www.google.com.br/search?q=centos+dns+bind&ie=utf-8&oe=utf-8&aq=t&rl… >>> >>> divirta-se. >>> >>> >>> -- >>> saudações, >>> irado furioso com tudo >>> Linux User 179402/FreeBSD BSD50853/FUG-BR 154 >>> Não uso drogas - 100% Miko$hit-free >>> O homem esquecerá antes a morte do pai do que a perda da propriedade >>> [Maquiavel] >>> _______________________________________________ >>> CentOS-pt-br mailing list >>> CentOS-pt-br(a)centos.org >>> http://lists.centos.org/mailman/listinfo/centos-pt-br >>> >>> >> _______________________________________________ >> CentOS-pt-br mailing list >> CentOS-pt-br(a)centos.org >> http://lists.centos.org/mailman/listinfo/centos-pt-br >> >> >> > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: http://lists.centos.org/pipermail/centos-pt-br/attachments/20091126/41fa81f… > > ------------------------------ > > Message: 5 > Date: Fri, 27 Nov 2009 10:05:22 -0200 > From: "Fábio Jr." <fjuniorlista(a)gmail.com> > Subject: [CentOS-pt-br] [OT] - Estrutura de armazenamento de uma > grande quantidade de arquivos > To: "Portuguese (Brazilian) CentOS mailing list" > <centos-pt-br(a)centos.org> > Message-ID: <4B0FC082.8050303(a)gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Um anexo em HTML foi limpo... > URL: http://lists.centos.org/pipermail/centos-pt-br/attachments/20091127/3ea6fc0… > > ------------------------------ > > Message: 6 > Date: Fri, 27 Nov 2009 10:22:16 -0200 > From: irado furioso com tudo <irado(a)bsd.com.br> > Subject: Re: [CentOS-pt-br] [OT] - Estrutura de armazenamento de uma > grande quantidade de arquivos > To: "Portuguese $Brazilian$ CentOS mailing list" > <centos-pt-br(a)centos.org> > Message-ID: <20091127102216.6c07b88e.irado(a)bsd.com.br> > Content-Type: text/plain; charset=ISO-8859-1 > > Em Fri, 27 Nov 2009 10:05:22 -0200 > "Fábio Jr." <fjuniorlista(a)gmail.com>, conhecido consumidor de drogas > (BigMac's com Coke) escreveu: > > >> Finalmente, o que venho pedir a lista seriam sugesto~es de como >> melhorar a indexaça~o/organizaça~o destes arquivos. Ja' >> pensei em utilizar armazenamento distribui'do (SAN, cloud, >> GlusterFS), organizaça~o por pastas com AliasMatch do apache >> para recupera'-las depois e armazenamento em banco de dados. >> > > MySQL blobs?? > > http://www.google.com.br/search?q=using+mysql+blobs&ie=utf-8&oe=utf-8&aq=t&… > > > > Godin, Muito obrigado pela dica. Vou imediatamente trocar as senhas deste usuário e chegar o resultado. Valeu

16 years, 4 months

Re: [CentOS] Fwd: Re: SELinux triggered during Libvirt snapshots

by Trey Dockendorf

On Tue, Oct 18, 2011 at 7:30 AM, Daniel J Walsh <dwalsh(a)redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/17/2011 03:40 PM, Trey Dockendorf wrote: > > > > On Oct 17, 2011 2:06 PM, "Daniel J Walsh" <dwalsh(a)redhat.com > > <mailto:dwalsh@redhat.com>> wrote: > >> > > On 10/17/2011 02:09 PM, Trey Dockendorf wrote: > >> On Oct 17, 2011 10:30 AM, "Daniel J Walsh" <dwalsh(a)redhat.com > >> <mailto:dwalsh@redhat.com> <mailto:dwalsh@redhat.com > >> <mailto:dwalsh@redhat.com>>> wrote: > > > >> On 10/17/2011 11:19 AM, Trey Dockendorf wrote: > >>> Forwarding back to list. ---------- Forwarded message > >>> ---------- From: "Trey Dockendorf" <treydock(a)gmail.com > >>> <mailto:treydock@gmail.com> <mailto:treydock@gmail.com > >>> <mailto:treydock@gmail.com>>> Date: Oct > >> 17, 2011 10:06 AM Subject: > >>> Re: [CentOS] SELinux triggered during Libvirt snapshots To: > >>> "Daniel J Walsh" <dwalsh(a)redhat.com <mailto:dwalsh@redhat.com> > >> <mailto:dwalsh@redhat.com <mailto:dwalsh@redhat.com>>> > > > > > > > >>> On Mon, Oct 17, 2011 at 7:47 AM, Daniel J Walsh > >>> <dwalsh(a)redhat.com <mailto:dwalsh@redhat.com> > >> <mailto:dwalsh@redhat.com <mailto:dwalsh@redhat.com>>> wrote: > > > >>> On 10/14/2011 08:17 PM, Trey Dockendorf wrote: > >>>>>> I recently began getting periodic emails from SEalert > >>>>>> that SELinux is preventing /usr/libexec/qemu-kvm > >>>>>> "getattr" access from the directory I store all my > >>>>>> virtual machines for KVM. > >>>>>> > >>>>>> All VMs are stored under /vmstore , which is it's own > >>>>>> mount point, and every file and folder under /vmstore > >>>>>> currently has the correct context that was set by doing > >>>>>> the following: > >>>>>> > >>>>>> semanage fcontext -a -t virt_image_t "/vmstore(/.*)?" > >>>>>> restorecon -R /vmstore > >>>>>> > >>>>>> So far I've noticed then when taking snapshots and also > >>>>>> when using virsh to make changes to a domain's XML file. > >>>>>> I haven't had any problems for the 3 or 4 months I've > >>>>>> run this KVM server using SELinux on Enforcing, and so > >>>>>> I'm not really sure what information is helpful to debug > >>>>>> this. The server is CentOS 6 x86_64 updated to CR. This > >>>>>> is the raw audit entry, (hostname removed) > >>>>>> > >>>>>> node=kvmhost.tld type=AVC msg=audit(1318634450.285:28): > >>>>>> avc: denied { getattr } for pid=1842 comm="qemu-kvm" > >>>>>> name="/" dev=dm-2 ino=2 > >>>>>> scontext=system_u:system_r:svirt_t:s0:c772,c779 > >>>>>> tcontext=system_u:object_r:fs_t:s0 tclass=filesystem > >>>>>> node=kvmhost.tld type=SYSCALL > >>>>>> msg=audit(1318634450.285:28): arch=c000003e syscall=138 > >>>>>> success=no exit=-13 a0=9 a1=7fff1cf153f0 a2=0 > >>>>>> a3=7fff1cf15170 items=0 ppid=1 pid=1842 auid=4294967295 > >>>>>> uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 > >>>>>> sgid=107 fsgid=107 tty=(none) ses=4294967295 > >>>>>> comm="qemu-kvm" exe="/usr/libexec/qemu-kvm" > >>>>>> subj=system_u:system_r:svirt_t:s0:c772,c779 key=(null) > >>>>>> > >>>>>> I've attached the alert email as a quote below, > >>>>>> (hostname removed) > >>>>>> > >>>>>> Any help is greatly appreciated, I've had to deal little > >>>>>> with SELinux fortunately, but at the moment am not > >>>>>> really sure if my snapshots are actually functional or if > >>>>>> this is just some false positive. > >>>>>> > >>>>>> Thanks - Trey > >>>>>> > >>>>>> Summary > >>>>>>> > >>>>>>> SELinux is preventing /usr/libexec/qemu-kvm "getattr" > >>>>>>> access on /vmstore. > >>>>>>> > >>>>>>> Detailed Description > >>>>>>> > >>>>>>> SELinux denied access requested by qemu-kvm. It is not > >>>>>>> expected that this > >>>>>>>> access is required by qemu-kvm 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 > >>>>>>>> Please file a bug report. > >>>>>>> > >>>>>>> Additional Information > >>>>>>> > >>>>>>> Source Context: > >>>>>>> system_u:system_r:svirt_t:s0:c772,c779 > >>>>>>> > >>>>>>> Target Context: system_u:object_r:fs_t:s0 > >>>>>>> > >>>>>>> Target Objects: /vmstore [ filesystem ] > >>>>>>> > >>>>>>> Source: qemu-kvm > >>>>>>> > >>>>>>> Source Path: /usr/libexec/qemu-kvm > >>>>>>> > >>>>>>> Port: <Unknown> > >>>>>>> > >>>>>>> Host: kvmhost.tld > >>>>>>> > >>>>>>> Source RPM Packages: qemu-kvm-0.12.1.2-2.160.el6_1.8 > >>>>>>> > >>>>>>> Target RPM Packages: > >>>>>>> > >>>>>>> Policy RPM: selinux-policy-3.7.19-93.el6_1.7 > >>>>>>> > >>>>>>> Selinux Enabled: True > >>>>>>> > >>>>>>> Policy Type: targeted > >>>>>>> > >>>>>>> Enforcing Mode: Enforcing > >>>>>>> > >>>>>>> Plugin Name: catchall > >>>>>>> > >>>>>>> Host Name: kvmhost.tld > >>>>>>> > >>>>>>> Platform: Linux kvmhost.tld > >>>>>>> 2.6.32-71.29.1.el6.x86_64 #1 SMP Mon Jun 27 > >>>>>>>> 19:49:27 BST 2011 x86_64 x86_64 > >>>>>>> > >>>>>>> Alert Count: 1 > >>>>>>> > >>>>>>> First Seen: Fri Oct 14 18:20:50 2011 > >>>>>>> > >>>>>>> Last Seen: Fri Oct 14 18:20:50 2011 > >>>>>>> > >>>>>>> Local ID: c73c7440-06ee-4611-80ac-712207ef9aa6 > >>>>>>> > >>>>>>> Line Numbers: > >>>>>>> > >>>>>>> Raw Audit Messages : > >>>>>>> > >>>>>>> > >>>>>>>> node=kvmhost.tld type=AVC > >>>>>>>> msg=audit(1318634450.285:28): avc: denied { getattr > >>>>>>>> } for pid=1842 comm="qemu-kvm" name="/" dev=dm-2 > >>>>>>>> ino=2 > >>>>>>>> scontext=system_u:system_r:svirt_t:s0:c772,c779 > >>>>>>>> tcontext=system_u:object_r:fs_t:s0 tclass=filesystem > >>>>>>> > >>>>>>> node=kvmhost.tld type=SYSCALL > >>>>>>> msg=audit(1318634450.285:28): arch=c000003e > >>>>>>>> syscall=138 success=no exit=-13 a0=9 a1=7fff1cf153f0 > >>>>>>>> a2=0 a3=7fff1cf15170 items=0 ppid=1 pid=1842 > >>>>>>>> auid=4294967295 uid=107 gid=107 euid=107 suid=107 > >>>>>>>> fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) > >>>>>>>> ses=4294967295 comm="qemu-kvm" > >>>>>>>> exe="/usr/libexec/qemu-kvm" > >>>>>>>> subj=system_u:system_r:svirt_t:s0:c772,c779 > >>>>>>>> key=(null) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ CentOS > >>>>>> mailing list CentOS(a)centos.org > >>>>>> <mailto:CentOS@centos.org> > >> <mailto:CentOS@centos.org <mailto:CentOS@centos.org>> > >>>>>> http://lists.centos.org/mailman/listinfo/centos > > > > > >>> THis is a bug in policy. It can be allowed for now. > > > >>> We have 6.2 selinux-policy preview package available on > >>> http://people.redhat.com/dwalsh/SELinux/RHEL6 > > > >>> I believe all that is happening is qemu-kvm is noticing you > >>> have a file system mounted, and doing a getattr on it. > > > > > >>> Thanks for the help Dan. Is there something that could have > >>> triggered this between 6.0 and 6.1? This server was updated > >>> to 6.0 CR around the same time this began happening, so I want > >>> to make sure if it's an issue in CR that I can file a useful > >>> bug report. > > > >>> When updating selinux-policy, do I have to update all the RPMs > >>> listed or will that one package suffice? > > > >>> Thanks - Trey _______________________________________________ > >>> CentOS mailing list CentOS(a)centos.org > >>> <mailto:CentOS@centos.org> > >> <mailto:CentOS@centos.org <mailto:CentOS@centos.org>> > >>> http://lists.centos.org/mailman/listinfo/centos > > > >> Did you add additional file systems? > > > >> Not after the upgrade. The same filesystems were in place using > >> 6.0 and 6.0 CR. The only change was the upgrade to CR. > > > >> - Trey > > > > > > Well I have no idea. Anyways it is not a problem allowing this > > access. > > > > What do I have to do to allow that access? Or should I update to > > the selinux-policy you linked ? Ive had little in the way of > > experience with selinux so this is all new. > > > > Thanks - Trey > > > > You can allow it by executing the following as root. > > # grep svirt /var/log/audit/audit.log | audit2allow -M mysvirt > # semodule -i mysvirt.pp > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk6dcVYACgkQrlYvE4MpobPduQCfZyY00S+74FBlLFqsBbk5bX5R > YKIAnjM+/Gb2H7BUgqKbn6xPVJARrkii > =uazZ > -----END PGP SIGNATURE----- > That was easy enough, thanks for your help Daniel. - Trey

14 years, 5 months

Re: [CentOS] Creating the symbolic links in the /boot and /boot/grub/

by Simon Matter

> Well, I have the disks in hand - all 4, but there is the > overriding level of apprehension. Is there a reference to what I > should do *if* I cannot reboot that I should read? As I said before, you may need to run grub-install, but I don't know for sure. And then, you have to know where to install grub, and I don't know where you have installed it. In fact I don't know how we could know because it really depends on how your BIOS boots the box. It can be that it's installed into the MBR of /dev/hdc, then you should be able to install it using 'grub-install /dev/hdc'. But, since the disk is named /dev/hdc, it's most likely that there is also /dev/hda and /dev/hdb, and then it's also likely that grub has been installed into the MBR of /dev/hda. Who knows? That said, check disk 1 by putting it into another computer, and chose 'linux rescue' at the boot prompt. Then it will boot using a root filesystem in ram, and configure network if you want and then tries to find any CentOS installation in the disks, and mount them if it finds one. Maybe it wont find one but it should find it on your server. Then it will mount it as something like /mnt/sysimage. You can then 'chroot /mnt/sysimage' and fix things. Good luck! Simon > > Also, after reading the responses to my query about using FAT32 > to store data, I decided to follow the suggestions to use Samba > to copy the data that needs to be shared with others to my > Windows connected NTFS external. So, I am in the process of > doing that first even though I have an ext3 backup of the same data. > > Preparing to jump as I look for my spare parachute.... > > Todd > > On 3/10/2011 2:15 AM, Simon Matter wrote: >>> Unfortunately, I live out with the cows, so I am using DSL to >>> download the latest - it will take awhile. It has been awhile >>> since I downloaded the four disks, however I assume disk 1 >>> contains all that I need to do a "rescue". >> Yes that's correct, you need to download only disk 1. >> >>> Once I get that down, I will use torrent to get all four disks. >>> >>> Hey, guys, many thanks. Any of you live in the SF Bay Area? >>> Love to treat you to a beer. >> Thanks, but it may be a bit difficult. Just let us know if you have been >> able to boot successfully. >> >> Simon >> >>> Todd >>> >>> On 3/9/2011 1:03 PM, Simon Matter wrote: >>>>> And here are the contents of grub.conf: >>>>> >>>>> # grub.conf generated by anaconda >>>>> # >>>>> # Note that you do not have to rerun grub after making changes to >>>>> this file >>>>> # NOTICE: You have a /boot partition. This means that >>>>> # all kernel and initrd paths are relative to /boot/, eg. >>>>> # root (hd0,0) >>>>> # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 >>>>> # initrd /initrd-version.img >>>>> #boot=/dev/hdc >>>>> default=0 >>>>> timeout=5 >>>>> splashimage=(hd0,0)/grub/splash.xpm.gz >>>>> hiddenmenu >>>>> title CentOS (2.6.9-100.EL) >>>>> root (hd0,0) >>>>> kernel /vmlinuz-2.6.9-100.EL ro >>>>> root=/dev/VolGroup00/LogVol00 rhgb quiet >>>>> initrd /initrd-2.6.9-100.EL.img >>>> OK, the file listing of /boot from your last mail and now grub.conf, >>>> they >>>> look quite good. grub.conf has been updated by the kernel update, and >>>> also >>>> a new initrd-2.6.9-100.EL.img has been created, so that doesn't look >>>> bad. >>>> >>>> The only thing I'm not really sure is if grub is installed correctly >>>> now. >>>> Maybe you have to run grub-install again to be sure but I'm just not >>>> so >>>> sure about grubs internals. Maybe someone can tell you more about >>>> this. >>>> >>>> As someone else mentioned, it's a very good idea to have a current >>>> CentOS >>>> 4.8 disk at hand so you could boot into rescue mode with 'linux >>>> rescue' >>>> at >>>> the boot prompt if somethings goes wrong. >>>> >>>> Simon >>>> >>>>> Todd >>>>> >>>>> On 3/9/2011 12:23 AM, Simon Matter wrote: >>>>>>> I inadvertently missed using the list...here are my recent >>>>>>> messages. >>>>>> As Nico suggested, download the kernel but also grub and >>>>>> redhat-logos, >>>>>> like so >>>>>> wget >>>>>> http://mirrors.kernel.org/centos/4.9/updates/i386/RPMS/kernel-2.6.9-100.EL.… >>>>>> wget >>>>>> http://mirrors.kernel.org/centos/4.9/os/i386/CentOS/RPMS/redhat-logos-1.1.2… >>>>>> wget >>>>>> http://mirrors.kernel.org/centos/4.9/os/i386/CentOS/RPMS/grub-0.95-3.8.i386… >>>>>> >>>>>> Then do a >>>>>> >>>>>> rpm -Uvh --replacepkgs --replacefiles kernel-2.6.9-100.EL.i686.rpm >>>>>> redhat-logos-1.1.26-1.centos4.4.noarch.rpm grub-0.95-3.8.i386.rpm >>>>>> >>>>>> And the show us the contents of 'ls -laR /boot' and 'cat >>>>>> /etc/grub.conf' >>>>>> >>>>>> Simon >>>>>> >>>>>>> On 3/8/2011 8:39 PM, Nico Kadel-Garcia wrote: >>>>>>>> On Tue, Mar 8, 2011 at 11:31 PM, Todd >>>>>>>> Cary<todd(a)aristesoftware.com> >>>>>>>> wrote: >>>>>>>>> reinstall is not an option for yum. I ran "yum install kernel" >>>>>>>>> and >>>>>>>>> it >>>>>>>>> completed without errors however there are no links created. >>>>>>>> Oh, dear. Can you grab the RPM and do "rpm -U -replacepkgs >>>>>>>> [kernel-whatver].rpm"? You should be able to use "yum remove" on >>>>>>>> the >>>>>>>> old kernel packages, consistent with freeing up the space, and now >>>>>>>> install your new kernel with yum. >>>>>>>> >>>>>>>>> Would this be the correct ln command for vmlinuz-2.6.9-89.35.1 >>>>>>>>> >>>>>>>>> # /boot/vmlinuz-2.6.9-89.35.1 /boot/vmlinuz >>>>>>>>> >>>>>>>>> Todd >>>>>>>>> >>>>>>>>> On 3/8/2011 7:04 PM, Nico Kadel-Garcia wrote: >>>>>>>>>> On Tue, Mar 8, 2011 at 9:58 PM, Todd >>>>>>>>>> Cary<todd(a)aristesoftware.com> >>>>>>>>>> wrote: >>>>>>>>>>> I started a new thread since the original one is getting rather >>>>>>>>>>> long. >>>>>>>>>>> >>>>>>>>>>> I have retrieved the files I deleted in /boot and /boot/grub, >>>>>>>>>>> however I need to make links for >>>>>>>>>>> >>>>>>>>>>> /boot/System.map (System.map -> >>>>>>>>>>> System.map-2.6.9-89.35.1) >>>>>>>>>>> /boot/vmlinuz (vmlinuz -> vmlinuz-2.6.9-89.35.1) >>>>>>>>>>> /boot/grub/menu.lst (menu.lst -> ./grub.conf) >>>>>>>>>> Instead, re-install your kernel. "yum reinstall kernel". This >>>>>>>>>> should >>>>>>>>>> regenerate your symlinks correctly, except possibly the >>>>>>>>>> grub.conf. >>>>>>>>>> >>>>>>>>>>> If it was not so important to get it correct, I would >>>>>>>>>>> appreciate >>>>>>>>>>> the syntax for the command. Usually I would figure it out. >>>>>>>>>>> >>>>>>>>>>> Since I have restored the files (I will double check to make >>>>>>>>>>> sure >>>>>>>>>>> they are all there), do I need to run grub-install? >>>>>>>>>> i think yes. The old location of the boot loader is listed in >>>>>>>>>> /boot/grub/grub.conf, and should be used as the argument to that >>>>>>>>>> command. grub is much smarter than LILO used to be, but I think >>>>>>>>>> the >>>>>>>>>> bootstrap procedure relies on knowing details of where the >>>>>>>>>> fiddly >>>>>>>>>> bits >>>>>>>>>> of grub live on the relevant ex2 compatible filesytem. >>>>>>>>>> >>>>>>>>>>> My apologies for bothering everyone with such a dumb error on >>>>>>>>>>> my >>>>>>>>>>> part. >>>>>>>>>>> >>>>>>>>>>> Todd >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ariste Software >>>>>>>>>>> Petaluma, CA 94952 >>>>>>>>>>> >>>>>>>>>>> http://www.aristesoftware.com >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> CentOS mailing list >>>>>>>>>>> CentOS(a)centos.org >>>>>>>>>>> http://lists.centos.org/mailman/listinfo/centos >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ariste Software >>>>>>>>> Petaluma, CA 94952 >>>>>>>>> >>>>>>>>> http://www.aristesoftware.com >>>>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>> Ariste Software >>>>>>> Petaluma, CA 94952 >>>>>>> >>>>>>> http://www.aristesoftware.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CentOS mailing list >>>>>>> CentOS(a)centos.org >>>>>>> http://lists.centos.org/mailman/listinfo/centos >>>>>>> >>>>>> _______________________________________________ >>>>>> CentOS mailing list >>>>>> CentOS(a)centos.org >>>>>> http://lists.centos.org/mailman/listinfo/centos >>>>>> >>>>>> >>>>> -- >>>>> Ariste Software >>>>> Petaluma, CA 94952 >>>>> >>>>> http://www.aristesoftware.com >>>>> >>>> >>> -- >>> Ariste Software >>> Petaluma, CA 94952 >>> >>> http://www.aristesoftware.com >>> >> >> > > -- > Ariste Software > Petaluma, CA 94952 > > http://www.aristesoftware.com >

15 years

Re: [CentOS] C7, mdadm issues

by Alessandro Baggi

Il 30/01/19 18:49, mark ha scritto: > Alessandro Baggi wrote: >> Il 30/01/19 16:33, mark ha scritto: >> >>> Alessandro Baggi wrote: >>> >>>> Il 30/01/19 14:02, mark ha scritto: >>>> >>>>> On 01/30/19 03:45, Alessandro Baggi wrote: >>>>> >>>>>> Il 29/01/19 20:42, mark ha scritto: >>>>>> >>>>>>> Alessandro Baggi wrote: >>>>>>> >>>>>>>> Il 29/01/19 18:47, mark ha scritto: >>>>>>>> >>>>>>>>> Alessandro Baggi wrote: >>>>>>>>> >>>>>>>>>> Il 29/01/19 15:03, mark ha scritto: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I've no idea what happened, but the box I was working >>>>>>>>>>> on last week has a *second* bad drive. Actually, I'm >>>>>>>>>>> starting to wonder about that particulare hot-swap bay. >>>>>>>>>>> >>>>>>>>>>> Anyway, mdadm --detail shows /dev/sdb1 remove. I've >>>>>>>>>>> added /dev/sdi1... >>>>>>>>>>> but see both /dev/sdh1 and /dev/sdi1 as spare, and have >>>>>>>>>>> yet to find a reliable way to make either one active. >>>>>>>>>>> >>>>>>>>>>> Actually, I would have expected the linux RAID to >>>>>>>>>>> replace a failed one with a spare.... >>>>>>> >>>>>>>>>> can you report your raid configuration like raid level >>>>>>>>>> and raid devices and the current status from /proc/mdstat? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Well, nope. I got to the point of rebooting the system (xfs >>>>>>>>> had the RAID volume, and wouldn't let go; I also commented >>>>>>>>> out the RAID volume. >>>>>>>>> >>>>>>>>> It's RAID 5, /dev/sdb *also* appears to have died. If I do >>>>>>>>> mdadm --assemble --force -v /dev/md0 /dev/sd[cefgdh]1 >>>>>>>>> mdadm: >>>>>>>>> looking for devices for /dev/md0 mdadm: /dev/sdc1 is >>>>>>>>> identified as a member of /dev/md0, slot 0. mdadm: /dev/sdd1 >>>>>>>>> is identified as a member of /dev/md0, slot -1. mdadm: >>>>>>>>> /dev/sde1 is identified as a member of /dev/md0, slot >>>>>>>>> 2. >>>>>>>>> mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot >>>>>>>>> 3. >>>>>>>>> mdadm: /dev/sdg1 is identified as a member of /dev/md0, slot >>>>>>>>> 4. >>>>>>>>> mdadm: /dev/sdh1 is identified as a member of /dev/md0, slot >>>>>>>>> -1. >>>>>>>>> mdadm: no uptodate device for slot 1 of /dev/md0 >>>>>>>>> mdadm: added /dev/sde1 to /dev/md0 as 2 >>>>>>>>> mdadm: added /dev/sdf1 to /dev/md0 as 3 >>>>>>>>> mdadm: added /dev/sdg1 to /dev/md0 as 4 >>>>>>>>> mdadm: no uptodate device for slot 5 of /dev/md0 >>>>>>>>> mdadm: added /dev/sdd1 to /dev/md0 as -1 >>>>>>>>> mdadm: added /dev/sdh1 to /dev/md0 as -1 >>>>>>>>> mdadm: added /dev/sdc1 to /dev/md0 as 0 >>>>>>>>> mdadm: /dev/md0 assembled from 4 drives and 2 spares - not >>>>>>>>> enough to start the array. >>>>>>>>> >>>>>>>>> --examine shows me /dev/sdd1 and /dev/sdh1, but that both >>>>>>>>> are spares. >>>>>>>> Hi Mark, >>>>>>>> please post the result from >>>>>>>> >>>>>>>> cat /sys/block/md0/md/sync_action >>>>>>> >>>>>>> There is none. There is no /dev/md0. mdadm refusees, saying >>>>>>> that it's lost too many drives. >>>>>>> >>>>>>> mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CentOS mailing list >>>>>>> CentOS(a)centos.org >>>>>>> https://lists.centos.org/mailman/listinfo/centos >>>>>>> >>>>>> >>>>>> I suppose that your config is 5 drive and 1 spare with 1 drive >>>>>> failed. It's strange that your spare was not used for resync. Then >>>>>> you added a new drive but it does not start because it marks the >>>>>> new disk as spare and you have a raid5 with 4 devices and 2 >>>>>> spares. >>>>>> >>>>>> First I hope that you have a backup for all your data and don't >>>>>> run some exotic command before backupping your data. If you can't >>>>>> backup your data, it's a problem. >>>>> >>>>> This is at work. We have automated nightly backups, and I do >>>>> offline backups of the backups every two weeks. >>>>>> >>>>>> Have you tried to remove the last added device sdi1 and restart >>>>>> the raid and force to start a resync? >>>>> >>>>> The thing is, it had one? two? spares when /dev/sdb1 started dying, >>>>> and it didn't use them. >>>>>> >>>>>> Have you tried to remove this 2 devices and re-add only the >>>>>> device that will be usefull for resync? Maybe you can set 5 >>>>>> devices for your raid and not 6, if it works (after resync) you >>>>>> can add your spare device growing your raid set. >>>>> >>>>> I tried, and that's when I lost it (again), and it refuses to >>>>> assemble/start the RAID "not enough devices". >>>>>> >>>>>> Reading on google many users use --zero-superblock before re-add >>>>>> the device. >>>>> >>>>> I can take one out, and re-add, but I think I'm going to have to >>>>> recreate the RAID again, and again restore from backup. >>>>>> >>>>>> Other user reassemble the raid using --assume-clean but I don't >>>>>> know what effect it will produces >>>> >>>> Hope that someone give you a better help for this. >>>> >>>> >>>> Update here if you got the solution. >>>> >>>> >>> >>> Not that I'm into American football, but I seem to have pulled off what >>> I >>> understand is called a hail-mary: *without* zeroing the superrblocks, I >>> did a create with all six good drives, excluding /dev/sdb1, and >>> explicitly told it one spare. >>> >>> And the array is there, complete with data, with *one* spare, five good >>> drives, and it's currently rebuilding the spare. >>> >>> The last resort worked, though we'll see how long. >>> >> So you have recreated the array without faulty device? >> > Yep. > mdadm --create --verbose /dev/md0 --level=5 --raid-devices=6 /dev/sd[cdefgh]1 > > It's currently at 2.2% recovered for the extra drive. > > mark > > How many TB?

7 years, 2 months

Jump to page: