Feeds:
Entradas
Comentarios

Posts Tagged ‘administración’

La versión gratuita de NoMachine NX sólo permite acceso remoto a dos usuarios.

Para poder gestionar dichos usuarios, utilizaremos la utilidad nxserver que se encuentra en “/usr/NX/bin“:

ramiro@cormanthor:~$ cd /usr/NX/bin/
ramiro@cormanthor:/usr/NX/bin$ ls
nxagent  nxclient  nxesd  nxkill  nxnode  nxprint  nxsensor  nxserver  nxservice  nxspool  nxssh  nxstat  nxuexec
ramiro@cormanthor:/usr/NX/bin$

Para listar los usuarios, usaremos el parámetro “–userlist“:

ramiro@cormanthor:/usr/NX/bin$ sudo ./nxserver –userlist
NX> 149 Listing NX users:
Username
——————————–
usuario1
usuario2
NX> 999 Bye.
ramiro@cormanthor:/usr/NX/bin$

Para eliminar a un usuario de la base de datos, usaremos el parámetro “–userdel“:

ramiro@cormanthor:/usr/NX/bin$ sudo ./nxserver –userdel usuario1
NX> 900 Disabling user: usuario1 in the NX user DB.
NX> 900 NX user DB is disabled.
NX> 900 NX password DB is disabled.
NX> 900 To remove user: usuario1 from the system, please
NX> 900 run the command with option: –system.
NX> 999 Bye.
ramiro@cormanthor:/usr/NX/bin$

Y para añadir un usuario a la base de datos, usaremos el parámetro “–useradd“:

ramiro@cormanthor:/usr/NX/bin$ sudo ./nxserver –useradd usuario3
NX> 801 User: usuario3 uses SSHD authentication.
NX> 900 Adding public key for user: usuario3 to the authorized keys file.
NX> 716 Public key is already present in: /home/usuario3/.ssh/authorized_keys2.
NX> 900 Verifying public key authentication for NX user: usuario3.
NX> 900 Public key authentication succeeded.
NX> 301 User: usuario3 enabled in the NX user DB.
NX> 999 Bye.
ramiro@cormanthor:/usr/NX/bin$

Read Full Post »

En el curro usamos bastante Apache Tomcat, un software porculizante donde los haya. Una de sus bonitas costumbres es dejar conexiones TCP “a medias” al bajar el servicio, las cuales impiden volver a levantarlo durante un tiempo que depende directamente del timeout de los estados de TCP.

Una solución es cambiar dicho valor de timeout, pero puede tener consecuencias imprevisibles en otros servidores. Otra solución es matar las conexiones TCP en un determinado puerto, sea cual sea su estado. Para ello, acudiremos a una orden del paquete dsniff: tcpkill.

Un ejemplo concreto, para conexiones a un Tomcat en su puerto por defecto (8080), sería el siguiente:

tcramiro@cormanthor:~$ sudo tcpkill -i eth0 port 8080
tcpkill: listening on eth0 [port 8080]

Read Full Post »

En un par de ocasiones, he tenido que revertir un servidor SVN completo a una revisión concreta. La primera, hace ya mucho, cuando un compañero decidió -por error- convertir el repositorio en recursivo. La segunda, ayer, cuando yo mismo me equivoqué subiendo un proyecto incorrecto. Sé que se podía haberlo borrado pero, ¿para qué dejar mierda en las revisiones?

Al lío. Si queremos revertir el repositorio completo a una revisión dada, los pasos son los siguientes:

  1. Crear un repositorio temporal:
    • svnadmin create /ruta/svn.tmp
  2. Volcar todos los cambios hasta la revisión, de forma incremental:
    • svnadmin dump -r 1:revisión /ruta/svn –incremental > volcado.svn
  3. Cargar el volcado en el repositorio temporal:
    • svnadmin load  /ruta/svn.tmp < volcado.svn
  4. Borrar el repositorio viejo:
    • rm -r /ruta/svn
  5. Renombrar el repositorio temporal:
    • mv /ruta/svn.tmp /ruta/svn
  6. Reparar los permisos del repositorio, si es necesario:
    • chown -R usuario.grupo /ruta/svn

Fácil, rico, y para toda la familia.

Read Full Post »

A %d blogueros les gusta esto: