Apertura puertos iptables para VNC

[root@pc10 ~]# iptables -A INPUT -p tcp -s 0/0 --dport 5907 -j ACCEPT
[root@pc10 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-ns
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-dgm
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:nfs
ACCEPT udp -- anywhere anywhere state NEW udp dpt:nfs
ACCEPT udp -- anywhere anywhere state NEW udp dpt:openvpn
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-ns
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-dgm
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:netbios-ssn
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:microsoft-ds
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:5907

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@pc10 ~]# service iptables save
iptables: Guardando las reglas del cortafuegos en /etc/sysc[ OK ]tables:
[root@pc10 ~]# service iptables restart
iptables: Guardando las reglas del cortafuegos: [ OK ]
iptables: Poniendo las cadenas de la política ACCEPT: filt[ OK ]
iptables: Descargando módulos: [ OK ]
iptables: Aplicando reglas del cortafuegos: [ OK ]
iptables: Cargando módulos adicionales:nf_conntrack_netbio[ OK ]

Gigabyte y su garantía de RMA

Outlook ERROR: 0x800CCC0B

Quiero contarles lo que me ocurrió con Outlook Express hace un par de días, y en lo que estuve perdiendo un poco de tiempo, yendo en varias direcciones incorrectas debido a la ambigüedad de los mensajes de error de MS Outlook.

El error que me aparecía era:

Error desconocido. Asunto 'Test', Cuenta: 'h4informatica.com.ar', Servidor: 'h4informatica.com.ar', Protocolo: SMTP, Puerto: 465, Seguridad (SSL): Sí, Número de error: 0x800CCC0B

Entonces, como es mi costumbre, comencé a buscar con google información sobre el error, y encontré bastante, así que me dediqué a leer diversos posts, con diferentes explicaciones y posibles soluciones. Como ejemplo y resumen, cito el siguiente:

Síntoma
Cuando tenemos un problema para autentificarnos en el servidor de correo y nos aparece lo
siguiente...
...
Solucion
Estos mensajes de error se producen si Microsoft Outlook o si Microsoft Outlook Express no
pueden establecer una conexión con el servidor de correo electrónico.
Estos mensajes de error suelen deberse a una de las causas siguientes:
- Configuración incorrecta de la cuenta
- Mala configuración del software de servidor de seguridad personal
- Software antivirus
- Un módem defectuoso
- Tamaño de Unidad máxima de transmisión (MTU)
- Outlook Express se ha quitado del equipo o la instalación está dañada
- El perfil de usuario en Outlook está dañado
- Un elemento de correo electrónico del servidor POP3 está dañado

Entonces, me puse en la tarea de revisar algunos de los items propuestos.
A poco de que me surgiera la pregunta: ¿Y cómo cambio el MTU?, sonó la alarma en mi cerebelo...

Otro yo: Loco, ¿Qué estás haciendo? ¿Revisaste en el servidor que todo esté normal?
Yo: Si, revisé...
Otro yo: ¿Seguro?
Yo: Bueno che, voy a ver de nuevo...

No fue menor mi sorpresa al verificar que mi cuenta de correo había superado su Cuota asignada: 253/250 MB, en un lindo color rojo resaltaba en medio de mi pantalla.

Entonces, a la lista de posibles causas y soluciones al ERROR: 0x800CCC0B de Outlook, le agrego:

-Tamaño en MB, o Cuota, o Espacio en disco Superado para su cuenta de correo.

Aumenté el espacio asignado para mi cuenta desde mi Web Host Manager y solucioné el problema. En caso de que no puedan hacer esto último, entonces pueden borrar los emails del servidor, ya sea con Outlook (configuración Avanzada de la Cuenta) o ingresando a su Webmail.

Salutti a tutti...

H4

Atahualpa Yupanqui - El Bien Perdido

Windows XP Error 0x000000F4 (0x00000003, Pantalla Azul, Falla de Disco

Windows XP o posterior deja de responder al volver del modo de suspensión y hace que aparezca el siguiente mensaje de error grave

KERNEL_DATA_INPAGE_ERROR:
0x0000007a (e163a3e4,c000000e,bf8e9313,0697f860)

o

0x000000F4 (0x00000003, parámetro2, parámetro3, parámetro4)

Nota:
Los valores de parámetro2, parámetro3 y parámetro4 del error pueden variar.

http://support.microsoft.com/kb/330100

Este problema se produce en un equipo en el que Windows XP o un sistema operativo posterior está instalado en un disco duro configurado como subordinado y donde ningún otro dispositivo está conectado al mismo canal de controladora IDE (principal o secundario).

WHM SMTP Tweak error - Falla Envío de Emails con Exim

C: Los emails no se envían
H: Mmm, me parece que si, porque el servidor los saca de la cola.
C: A mi me rebotan todos...
H: Dejame ver... Si, rebotan... Voy a investigar.


root@vps9885 [~]# tail -f /var/log/exim_mainlog
2010-05-30 21:31:42 H=(PC997122301552) [186.110.109.39] Warning: Sender rate 4.3 / 1h
2010-05-30 21:31:45 1OIsut-0005lE-Ao <= info@h4informatica.com.ar H=(PC997122301552) [186.110.109.39] P=esmtpsa X=TLSv1:RC4-MD5:128 A=fixed_login:info@h4informatica.com.ar S=1494 id=66AB4B601D484B30A177C1676CAA0AD5@PC997122301552 2010-05-30 21:31:48 1OIsut-0005lE-Ao alt2.gmail-smtp-in.l.google.com [209.85.211.56] Connection refused 2010-05-30 21:31:51 1OIsut-0005lE-Ao alt4.gmail-smtp-in.l.google.com [209.85.219.57] Connection refused 2010-05-30 21:31:51 1OIsut-0005lE-Ao == hectorhuergo@gmail.com R=lookuphost T=remote_smtp defer (111): Connection refused 2010-05-30 21:31:51 1OIsut-0005lE-Ao ** hectorhuergo@gmail.com: retry timeout exceeded 2010-05-30 21:31:51 1OIsv1-0005Ap-Rd <= <> R=1OIsut-0005lE-Ao U=mailnull P=local S=2354
2010-05-30 21:31:51 1OIsut-0005lE-Ao Completed
2010-05-30 21:31:51 1OIsv1-0005Ap-Rd => info R=virtual_user T=virtual_userdelivery
2010-05-30 21:31:51 1OIsv1-0005Ap-Rd Completed


Entonces, el problema puede ser local?

2010-05-30 21:31:51 1OIsut-0005lE-Ao == hectorhuergo@gmail.com R=lookuphost T=remote_smtp defer (111): Connection refused

Este mensaje de conexión rechazada...

Veamos las reglas del firewall:


root@vps9885 [~]# iptables -L output
iptables: No chain/target/match by that name
root@vps9885 [~]# iptables -L OUTPUT
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
VZ_OUTPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere vps9885 tcp dpt:smtp
REJECT tcp -- anywhere anywhere tcp dpt:smtp reject-with icmp-port-unreachable
acctboth all -- anywhere anywhere
root@vps9885 [~]# iptables -D OUTPUT 4
root@vps9885 [~]# iptables -L OUTPUT
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
VZ_OUTPUT all -- anywhere anywhere
ACCEPT tcp -- anywhere vps9885 tcp dpt:smtp
acctboth all -- anywhere anywhere
root@vps9885 [~]# service iptables save
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
root@vps9885 [~]# service iptables restart
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: mangle filter nat [ OK ]
Unloading iptables modules: [ OK ]
Applying iptables firewall rules: [ OK ]


Y si, el problema estaba en que el firewall tenía una regla que Rechazaba
cualquier conexión SMTP que no se haga sobre el servidor local.
Esto es lo que hace SMTP Tweak, evitar que el servidor haga Relay.
El error está en que al Deshabilitar SMTP Tweak, no se borran las reglas de
iptables creadas. La solución es eliminarlas manualmente.

Ahora, funciona.

H4

Limpieza de disco en VPS o Servidor dedicado con CPanel, WHM, VZPP

Cómo rehabilitar un Servidor que ha llegado al 100% de uso de espacio de disco.

Cuándo en un servidor linux se llena el disco o partición /, la mayoría de los servicios comienzan a fallar, dado que no hay espacio para crear los archivos que cada programa requiere para interactuar con el sistema operativo. Entre estos servicios que no funcionan está el demonio SSH, por lo que no podemos conectarnos a la consola remota para eliminar algunos archivos y recuperar el espacio.
Si bien el método que se describe a continuación está referido a servidores que utilizan Virtuozzo para administrar la máquina virtual, es posible aplicar este tipo de solución a cualquier servidor, siempre y cuándo podamos acceder remotamente al hipervisor y montar nuestro sistema de archivos en una nueva partición con algo más de espacio que el que ocupa / al momento del problema.

1. Acceder a Virtuozzo Power Panel y Habilitar Modo Reparación

https://vpsXXXX.managemyvps.com:4643/vz/cp (esta URL es particular de un proveedor de hosting. Reemplace con la URL de su servidor).

Top > VPS Management  > Maintenance

Repair Mode > Run Repair

VPS is starting-repair at the moment

VPS is in reparing mode. Available for secure shell login.VPS is repairing at the moment

2. Acceder por SSH

login as: h4
h4@e-ssence.net's password:
=============== VPS REPAIR MODE ===============
 Your VPS is under repair mode now.
 You can access the file system of your VPS under /repair directory.
 To finish repair mode, either login in Virtuozzo Power Panel and select "Stop
Repair", or just reboot your VPS using 'shutdown -r now' command.
=============== VPS REPAIR MODE ===============
Could not chdir to home directory /home/h4: No such file or directory
-bash-3.00$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
vzfs                     41928     31536     10392  76% /
vzfs                  52428800  51216976   1211824  98% /repair
-bash-3.00$ su -
password:


3. Limpiar los archivos innecesarios.

Generalmente, en cada cuenta dentro de /home hay una carpeta mail/new que es el
catch all de la cuenta, dónde van los emails dirigidos a cuentas inexistentes.
Si el cliente no solicita mantener estos emails, se pueden eliminar.

[root@vpsXXXX /] cd /repair/
[root@vpsXXXX repair]# cd home/
[root@vpsXXXX home]# du -sh *
1.0K    MySQL-install
5.5M    xxxxxxxx (están ofuscados los nombres de las cuentas)
183M    xxxxxxx0
273M    xxxxxxx1
24M     xxxxxxx2
513M    xxxxxxx3
8.6M    xxxxxxx4
5.2M    xxxxxxx5
157M    xxxxxxx6
41M     xxxxxxx7
89M     xxxxxxx8
29M     xxxxxxx9
184M    cpanel
176M    cpapachebuild
307M    cpeasyapache
...
...
...


Dado que generalmente en la carpeta /repair/home/xxxxxxxx/mail/new hay muchos archivos,
es complicado eliminarlos a todos de una vez, por lo que resulta más fácil eliminar la
carpeta y luego recrearla.


[root@vpsXXXX mail]# rm -Rf ./new/
[root@vpsXXXX mail]# mkdir new
[root@vpsXXXX mail]# chown xxxxxxxx new
[root@vpsXXXX mail]# chgrp xxxxxxxx new


Las carpetas /home/cpapachebuild y /home/cpeasyapache contienen el cache de la actualización
del sistema. Se pueden eliminar sin afectar el funcionamiento del servidor.

[root@vpsXXXX home] rm -Rf ./cpapachebuild
[root@vpsXXXX home] rm -Rf ./cpeasyapache


Revisar las siguientes carpetas también:

/var/log    Es mejor comprimir los log en vez de eliminarlos.
/var/lib/mysql    Aquí pueden quedar archivos temporales creados por consultas truncadas.
/tmp


Otra solución para obtener espacio extra, es descargar los backups y luego eliminarlos. Estos se encuentran en /cpbackup. Para realizar esto es necesario salir del Modo Reparación.

4. Finalizar el Modo Reparación

Top > VPS Management  > Maintenance

Repair Mode > Finish Repair

VPS is up and running now.VPS is running at the moment

Ingresamos de nuevo por SSH:

[root@vps3639 home]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vzfs             52428800  50170898   2257902  96% /


Para más información pueden consultar los Foros de CPanel.

Saludos.

H4