Instalando GitLab en Debian 8

Qué es GitLab?

GitLab es un repositorio de gestión de proyectos mediante una interfaz web en la cual podemos gestionar grupos, permisos y hacer seguimiento de las modificaciones del código.

Instalamos curl como pre-requisito:

apt-get install curl

Descargamos el paquete con wget:

wget https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb

Ejecutamos:

cat script.deb | bash

Detected operating system as debian/jessie.
Checking for curl...
Detected curl...
Running apt-get update...
done.
Installing debian-archive-keyring which is needed for installing
apt-transport-https on many Debian systems.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/gitlab_gitlab-ce.list...done.
Importing packagecloud gpg key... done.
Running apt-get update... done.
The repository is setup! You can now install packages.

Instalamos gitlab-ce:

apt-get install gitlab-ce

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  gitlab-ce
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 257 MB of archives.
After this operation, 803 MB of additional disk space will be used.
Get:1 https://packages.gitlab.com/gitlab/gitlab-ce/debian/ jessie/main gitlab-ce amd64 8.16.5-ce.1 [257 MB]
Fetched 257 MB in 3min 53s (1,101 kB/s)
Selecting previously unselected package gitlab-ce.
(Reading database ... 29918 files and directories currently installed.)
Preparing to unpack .../gitlab-ce_8.16.5-ce.1_amd64.deb ...
Unpacking gitlab-ce (8.16.5-ce.1) ...
Setting up gitlab-ce (8.16.5-ce.1) ...


       *.                  *.
      ***                 ***
     *****               *****
    .******             *******
    ********            ********
   ,,,,,,,,,***********,,,,,,,,,
  ,,,,,,,,,,,*********,,,,,,,,,,,
  .,,,,,,,,,,,*******,,,,,,,,,,,,
      ,,,,,,,,,*****,,,,,,,,,.
         ,,,,,,,****,,,,,,
            .,,,***,,,,
                ,*,.

     _______ __  __          __
    / ____(_) /_/ /   ____ _/ /_
   / / __/ / __/ /   / __ `/ __ \
  / /_/ / / /_/ /___/ /_/ / /_/ /
  \____/_/\__/_____/\__,_/_.___/


gitlab: Thank you for installing GitLab!
gitlab: To configure and start GitLab, RUN THE FOLLOWING COMMAND:

sudo gitlab-ctl reconfigure

gitlab: GitLab should be reachable at http://SERVIDOR.DOMINIO
gitlab: Otherwise configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
gitlab: And running reconfigure again.
gitlab:
gitlab: For a comprehensive list of configuration options please see the Omnibus GitLab readme
gitlab: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
gitlab:

gitlab: GitLab now ships with a newer version of PostgreSQL (9.6.1), and will be used
gitlab: as the default in the next major release. To upgrade, RUN THE FOLLOWING COMMANDS:

sudo gitlab-ctl pg-upgrade

gitlab: For more details, please see:
gitlab: https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server
gitlab:
It looks like GitLab has not been configured yet; skipping the upgrade script.

Reconfigure:

gitlab-ctl reconfigure

 Nos logueamos por la dirección del servidor ó la ip: http://nombreServidor y nos logueamos

No common kex alg: client 'diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1', server 'curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1'

Al querer conectarme por ssh desde un cliente ssh solaris a un servidor ssh linux me aparecía lo siguiente:

no common kex alg: client 'diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1', server 'curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1'

Para permitir la conexión editamos el sshd_config del servidor ssh:

vi /etc/ssh/sshd_config

Al final agregamos lo siguiente:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

Reiniciamos el servicio ssh del server:

/etc/init.d/ssh restart

Y ya nos deja conectarnos correctamente.

SSH "Server refused our key" para todos los usuarios excepto root

Le pasé el siguiente instructivo a un compañero del trabajo para que configure SSH sin password: http://redes-seguridad.blogspot.com.ar/2012/10/putty-con-key-publica-y-privada.html 

Me dice que estaba mal el instructivo, lo pruebo con root y me funciona perfectamente, buscando un poco llego a que con un usuario sin privilegios de root no funcionaba, yo lo había probado solamente con root.

Al intentar loguearse con "usuario_no_root" le aparecía el siguiente mensaje:

Using username "usuario_no_root".

Server refused our key

usuario_no_root@servidorcirigillo's password:

Investigando un poco llegue a que para el usuario no root hay que agregar el authorized_keys en el /etc/ssh y no en el home del usuario, ejecutamos lo siguiente:

root@servidorcirigillo:~# mkdir /etc/ssh/usuario_no_root

root@servidorcirigillo:~# chmod 755 /etc/ssh/usuario_no_root/

root@servidorcirigillo:~# chown usuario_no_root /etc/ssh/usuario_no_root/

root@servidorcirigillo:~# touch /etc/ssh/usuario_no_root/authorized_keys

root@servidorcirigillo:~# chmod 644 /etc/ssh/usuario_no_root/authorized_keys

root@servidorcirigillo:~# cat /home/usuario_no_root/.ssh/authorized_keys > /etc/ssh/usuario_no_root/authorized_keys

root@servidorcirigillo:~# echo "AuthorizedKeysFile /etc/ssh/%u/authorized_keys" >> /etc/ssh/sshd_config

Reiniciamos el SSH:

root@servidorcirigillo:~# /etc/init.d/ssh restart

[ ok ] Restarting ssh (via systemctl): ssh.service.

Y ahora si nos deja loguearnos por ssh con un usuario sin privilegios de root sin contraseña, utilizando clave publica y privada.


Gracias estimado doctor Ballerini por el testeo del instructivo.


FUENTE: http://serverfault.com/questions/591476/ssh-server-refused-our-key-for-all-users-except-root-user

 

Ver en Windows ventana gráfica de Linux (Xming + Putty)

Descargamos el Xming para windows 7 desde la siguiente URL: https://sourceforge.net/projects/xming/files/stats/timeline

Hacemos la instalación por defecto, siguiente, siguiente, tener en cuenta sólo si tenemos el putty portable ó instalado. Seguimos las capturas:

En este paso debemos tener en cuenta si es el portable:

Configuramos la sesión en el putty, ponemos ip, puerto, nombre y guardamos:

Luego vamos a la Solapa "Connection" -> "SSH" -> X11
Habilitamos el X11 forwarding tildando la opción y configuramos el display con: localhost:0

Antes de dar open en la sesión del putty, verificamos que esté el Xming ejecutando, hacemos doble click en el ícono del escritorio y verificamos al lado del reloj que esté corriendo:

Ahora si abrimos la sesión del putty y ejecutamos cualquier cosa con entorno gráfico desde la consola del linux:

Ya con la terminal abierta ejecutamos el xeyes, el gedit ó por ejemplo un instalador en entorno gráfico de linux:

check_esxi_hardware.py (Service check timed out after 60.01 seconds)

Tenemos en la empresa 4 ESXi configurados de igual forma y en uno de ellos empecé a recibir la siguiente alarma de monitoreo en nagios:

Al ejecutar el check_esxi_hardware.py desde la cli de nagios obtenía que se quedaba trabado en lo siguiente y no seguía:

root@nagios:~# ./check_esxi_hardware.py -H mi_server_esxi -U root -P mi_passguord -V marca_server -v
20160927 15:22:24 Connection to https://mi_server_esxi
20160927 15:22:24 Check classe OMC_SMASHFirmwareIdentity

En los logs del vmware aparecía el siguiente error:

esxi@agios:~# tail -f /var/log/syslog.log
sfcb-vmware_base[2954690]: Timeout (or other socket error) sending request to provider

Nos logueamos al VCenter y vamos a: 

 1. Configuration

 2. Security Profile

 3. Properties

Luego seleccionamos "Servidor CIM" -> Options:

Seleccionamos seguimos los pasos:

 1- Start and stop manually
 2- Ok
 3- Restart

Volvemos a ejecutar el ./check_esxi_hardware.py y veremos que devuelve el valor, luego de unos minutos se fue la alarma del nagios.

Que tema están pasando en la radio en el celu?

Tocamos la lupita del Windows Phone (si tenemos otro sistema operativo elegimos el programa para detectar temas):

Colocamos el auricular junto al micrófono y subimos al tope el sonido:

Tocamos el botón de la nota musical al lado del ojo:

Nos aparecerá el siguiente mensaje, mientras el programa detecta el sonido:

Y finalmente nos aparecerá el tema que nos mostraba por la radio:

PBM error occurred during PreCloneCheckCallback

Al intentar clonar una máquina virtual me encontré con el siguiente error:

Se produjo un error general del sistema: PBM error occurred during PreCloneCheckCallback: No connection could be made because the target machine actively refused it:

Nos logueamos al VCenter a ver si estaban todos los servicios habilitados y efectivamente había uno bajo, el: "VMware vSphere Profile-Driven Storage Service"

Lo inicié manualmente y dejé de tener el error al clonar la virtual.

Fuente: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2118551