Hace un tiempo leyendo la lista de soporte me llamo la atención un hilo creado por el usuario @Delio que daba agradecimientos a @Lázaro por su vital colaboración en la solución a problemas presentados con el initscript. Debido a que yo anteriormente tuve este mismo problema, el cual me robo horas para solucionarlo y que se que hay muchos otros usuarios que de seguro también lo han presentado o quizás se les presente en un futuro. Acá les dejo el tema con la solución.
@Delio:
En el talento y la buena voluntad del colega Lázaro, descansa el hecho de que los servicios del Archivo Histórico de la ciudad de Manzanillo, único repositorio cubano que tiene migrados todos sus servicios y estaciones de trabajo a GNU/Linux, haya podido mantenerlos; pues, gracias a su pericia se resolvió un problema que las sugerencias de otros amigos e incluso algunas soluciones ofrecidas en Internet no pudieron resolver.
Este mensaje, además del agradecimiento implícito que justiprecia sus buenos oficios, lleva el clamor de que postee a la lista la solución al problema que nos resultaba sumamente peliaguda y complicada.
@Lazaro
……. Mejor cuento la batalla épica a ver si alguien se le ocurre una posible mejor salida.
Resulta que al hacer cualquier gestión de paquetes, devolvía un carretón de errores y un paquete roto. Cualquier gestión con o sin force, devolvía el mismo error. El paquete roto era nada menos que ‘initscripts’. Con apt-get y aptitude renuentes a resolver el conflicto, tuve que borrarlo a mano.
dpkg –forca-all –remove initscrips
Que es nada mas y nada menos la herramienta que se encarga de gestionar el contenido de /etc/rc*d./, es decir, los niveles del sistema. Al desintalarse me dice que la carpeta /sys se deja porque no está vacía 😀
Sudando frio vuelvo a instalarlo pero el enorme error se replica y el paquete se marca como roto, ademas de no instalado. A ese punto un apagón hubiera dejado el sistema fuera de combate porque no tenia stages de inicio ni orden en los programas de arranque. Tenga en cuenta que /etc/rcS.d/S10mountall.sh no tenia como ejecutarse.
Solución burda
dpkg -i /var/cache/apt/archives/initscri*deb
Pero el conflicto seguía! y pedía como solución, desinstalar util-linux netbase nfs-common y otros componentes de base. No podía quedarme sin netbase porque estaba por un LENTÍSIMO terminal ssh. Reinstalar NO era una opción, no mientras estuviera mi dignidad en juego y la corriente eléctrica fluyendo.
aptitude hold netbase
Al correr trató de configurar los paquetes y trajo el conflicto, por suerte se puso el hold. Leyendo detenidamente el error, entre muchas lineas vi que hablaba de que udpate-rc.d devolvía un error 255. Esto hacia creer al gestor de paquetes que el paquete «insserv» había devuelto error y por alguna razón el error se reflejaba en initscripts. ……. Solución encabronada y extremadamente drástica.
cp /usr/sbin/update-rc.d /usr/sbin/update-rc.d.old echo ‘exit 0’ > /usr/sbin/update-rc.d aptitude purge
Con eso termino el conflicto, pero el cordón se quedo suelto. Si se iba la luz no había dios escandinavo que arrancara eso. Solución extremista y bien aprovechada.
aptitude full-upgrade
Se tardo un buen rato calculando dependencias. Con el exit 0 en RC, el error que causo el desastre no se replicó mas. Con el sistema recién upgradeado entonces instalar el paquete conflictivo, pero con el exit 0 en update-rc.d, nada que involucrara a /etc/rc*d./ pincharía. Para probar ambas, instale el initscripts y sobreesribi el script falso.
cp /usr/sbin/update-rc.d.old /usr/sbin/update-rc.d
PINCHO! al final nunca supe lo que era, parece que se quedo atrás cuando upgradie el sistema. Una opción hubiera sido sacarlo de el fichero de control con la lista de paquetes instalados pero eso alteraría la coherencia de los ficheros existentes. Ademas, que al reinstalar, el script conflictivo NO se sobrescribía, así que no hubiera solucionado el problema
¿Te resultó interesante? Compártelo ...
Bien por el héroe … tres hurras!! 😀
Felicitaciones a Lázaro, me consta que Delio pudo mantener sus servicios con esta solución. Gracias a Elmor3no por su detalle al agradecer públicamente este capítulo de la historia de colaboración del país. Creo también que gutl-l es la cuasi única lista, infinita e inapagable, del país que opera ayudando a la gente en cuestiones técnicas. Como mismo pasa en Internet, lo cual fue su objetivo desde el inicio.
Disculpen el Offtopic total, pero es que esto no se ni donde preguntarlo. Alguien sabe que pasa con humanOS???? Se volverá a caer de por vida?????
Solo puedo decirte que Jako está de misión en Venezuela 🙂
Si, de hecho desde que se ausentó Jako se notó su ausencia. Y no me refiero exactamente a lo de estar en modo Offline-perpetuo
Hola Maikel, soy ale uno de los redactores de humanOS. Solo 2 preguntas:
1- Desde cuando no puedes entrar a humanOS?? Porque no sabia que no tenia visibilidad desde fuera de la UCi otra vez.
2- Qué has notado en humanOS desde la salida de Jako??? Solo para intentar arreglarlo.
ale, a veces humanOS se queda offline, en realidad es como si el servidor estuviera offline porque no logra acceder a él el navegador, como si un firewall con DROP denegase el acceso o como si el servidor estuviese offline.
@ale, como te dice @KZKG^Gaara, humanos se pasa buena parte del time offline para los que estamos fuera de la UCI. De hecho, ni siquiera store.uci.cu esta disponible
Leer mensaje más abajo
me dijeron q hay problemas graves en los servidores de etecsa en la UCI, por eso hay problemas no solo con humanOS, sino q con el correo y demas servicios, Saludos
todos los dias abro gutl y humanos sin problemas. Hubo un tiempo cuando estaban pasando a https que si retornaba respuesta vacia pero ya no. Y eso que la conexion de aca de desoft es un suero.
A mí me pasa lo mismo, de hecho, desde hace días estoy intentando enviar un software hecho por mí para el concurso “Comparte tu Software” de HumanOs, pero no logro entrar. Mi conexión es de la Universidad de La Habana, y últimamente no tenemos visibilidad a ninguna página de la UCI (incluyendo Firefoxmanía). Tengo entendido que el software hay que enviarlo al concurso antes del día 18; parece que no voy a poder participar.
Para comprobar que HumanOs está funcionando, entré a la página de mejoras de CCS de HaciendoWeb, desde ahí le puse que me cogiera el CCS de humanos.uci.cu, y en el resultado que me retornó, logré darme cuenta que habían artículos nuevos en humanos (o sea, que no me retornó algo que estaba en caché), por lo que entonces HaciendoWeb pudo acceder a HumanOs; la manera en que lo hizo, no la sé.
Una gigantesca Botnet está atacando a todos los sitios creados con WordPress
Se estima que más de 100 mil bots están efectuando ataques de fuerza bruta para apoderarse de las cuentas de administrador del famoso software de edición de contenidos Web.
Por: Fernando Triveri / Lunes, 15 de Abril de 2013
WordPress bajo ataque. Los sitios con la cuenta predeterminada llamada «admin» son los más vulnerables. WordPress bajo ataque. Los sitios con la cuenta predeterminada llamada «admin» son los más vulnerables.
Share on email
e-mail
Si son administradores de algún sitio web que opere bajo WordPress, es de importancia primordial que den de baja la cuenta llamada admin y gestionen su sitio web con una cuenta de administrador que posea un nombre diferente. De acuerdo a dos reportes elaborados por HostGator y CloudFlare, una red de hackers está utilizando más de cien mil bots para intentar loguearse a los blogs creados con WordPress, mediante la cuenta llamada admin (que viene por defecto) usando un ataque de fuerza bruta basado en un diccionario con las contraseñas más comunes utilizadas por los administradores de sitios web.
Ambos análisis demostraron que se trata de un ataque muy bien organizado y distribuido, y que afecta a más de 90 mil direcciones IP. También estiman que se trata de un ataque preliminar efectuado con PCs hogareñas; si logran acceder a un número considerable de servidores con sus bots, los ataques podrían intensificarse hasta límites insospechados.
Las características de este ataque son muy similares al producido en 2012, que también apuntaba a sitios con WordPress, aprovechándose de una vulnerabilidad en el plugin TimThumb, instalado por defecto en numerosos templates del popular software.
Tanto HostGator como CloudFlare y otros grandes proveedores de hosting ya han tomado las medidas necesarias para proteger a sus clientes. Además de utilizar passwords fuertes (lo que siempre es una buena idea), se recomienda a los usuarios instalar plugins que limiten la cantidad de logins incorrectos desde la misma IP para evitar que se produzcan estos ataques de fuerza bruta.
Por su parte, el fundador de WordPress Matt Mullenweg recomienda reemplazar el nombre de la cuenta de administración por uno más complejo, ya que la botnet apunta con sus ataques tomar el control de la cuenta admin.