Linux

manuales - Linux

¿Problemas al conectar? ¿No se muestra la web de test en el navegador? ¿Tampoco haces telnet?... ¿Has desactivado selinux e iptables y nada?...

Aquí tienes la solución:

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --zone=public --add-service=http 
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

Si.. de nuevo, el madito cortafuegos

manuales - Linux

Usar puntuación: / 9
MaloBueno 

Si te has vuelto loco como yo porque tras configurar apache no tienes acceso desde el exterior pero si desde la propia máquina, deberás saber que, ya no es culpa ni de Selinux (que seguramente te tocará desactivar) ni de iptables. Tenemos un nuevo demonio activo: firewalld

root@GNAPPWeb ~]# service firewall status
Redirecting to /bin/systemctl status  firewall.service
firewall.service
   Loaded: error (Reason: No such file or directory)
   Active: inactive (dead)
[root@GNAPPWeb ~]# service firewalld status
Redirecting to /bin/systemctl status  firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since vie 2013-10-04 11:34:33 CEST; 23min ago
 Main PID: 420 (firewalld)
   CGroup: name=systemd:/system/firewalld.service
           └─420 /usr/bin/python /usr/sbin/firewalld --nofork --nopid
oct 04 11:34:33 GNAPPWeb systemd[1]: Started firewalld - dynamic firewall d...n.

[root@GNAPPWeb ~]# service firewalld stop
Redirecting to /bin/systemctl stop  firewalld.service
[root@GNAPPWeb ~]# systemctl disable firewalld
rm '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
rm '/etc/systemd/system/basic.target.wants/firewalld.service'

manuales - Linux

¡¿Dónde está inittab?!

Si estás usando Fedora 15, 16, 17, 18 o 19 habrás observado que algunas cosas han cambiado. Entre otras, la forma en cambiar por defecto el runlevel o nivel de ejecución.

Ahora, debemos de realizar un link simbólico en lugar de editar el ya conocido inittab

RUNLEVEL 5

ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

RUNLEVEL 3

ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Lista completa de los niveles de ejecución

/lib/systemd/system/runlevel0.target -> poweroff.target
/lib/systemd/system/runlevel1.target -> rescue.target 
/lib/systemd/system/runlevel2.target -> multi-user.target
/lib/systemd/system/runlevel3.target -> multi-user.target
/lib/systemd/system/runlevel4.target -> multi-user.target
/lib/systemd/system/runlevel5.target -> graphical.target
/lib/systemd/system/runlevel6.target -> reboot.target

manuales - Linux

Usar puntuación: / 1
MaloBueno 

vi /etc/apt/sources.list

sudo apt-get update

manuales - Linux

Usar puntuación: / 122
MaloBueno 

fuente: http://www.planetainopia.com/2009-06-22/apache-ssl-quitar-peticion-de-clave-en-el-arranque.html

Copiamos la clave para tener una copia de ella en caso de necesitarla: cp server.key server.key.org y ahora quitamos el cifrado a la clave original, de la siguiente manera: openssl rsa -in server.key.org -out server.key Es importantísimo proteger debidamente el acceso a esta clave, ya que como digo ya no se encuentra cifrada, por lo que un posible atacante podría, en caso de tener acceso a ella, hacerse pasar por nosotros. Para ello, haremos que la clave solo sea accesible para el superusuario:  chmod 400 server.key Ahora, si reiniciamos nuestro servidor Apache, veremos que ya no nos pide la clave y que arranca como de costumbre. Si en algún momento queremos volver al estado anterior, con modificar la configuración para que apunte a server.key.org volveríamos al escenario anterior.