Cursos Online Gratuitos
Por si les interesa .
http://www.security-class.org/
Si eres propietario de un PS3, y deseas probar software de 3ros o desarrollar tu propio software para este sistema, aqui tienes la Guia basica para liberar tu PS3.
Si en 14 simples pasos liberaras tu PS3.
NOTA: Este metodo va sin garantias, usalo bajo tu propio riesgo, nosotros no nos hacemos responsables por fallas o desperfectos despues ocacionados en tu consola…
GeoHot ha decidido además de liberar para cargar con homebrew software casero y nada de copias caseras de los videojuegos.
El método de George Hotz es de momento el primero y por ahora el único de momento, aunque podrán ir saliendo alternativas.
No funcionan sobre antiguos homebrew y funciona sobre el firmware 3.55 (el último conocido).
Los pasos a seguir serán los siguientes:
1. Conecta una memoria USB al PC
2. Crea una carpeta raíz llamada PS3
3. Añade una carpeta llamada ” UPDATE ” que lleve a /PS3/UPDATE/
4. Descarga el Jailbreak de GeoHot ( Descargar aquí )
5. Extrae el archivo PS3UPDAT.PUP y muevelo a UPDATE en la memoria USB
6. Conecta la memoria a tu PS3
7. Navega hasta “Herramientas”
8. Elige “Actualización de sistema”
9. Opción “Actualizar desde la memoria o pendrive”
10. Reconocerá la actualización “Version 3.55-jb”, dale al OK
11. Acepta las condiciones e instala la actualización finalmente
12. Cerca de 1 minuto en actualizar ( pitará varias veces y se apagará )
13. Enciende la consola desde su botón principal
14. Después de todos los pasos ya ha sido la versión modificada firm 3.55
Informacion de Noticias2D
Esta semana Google introdujo un nuevo lenguage de programación llamado “Go“.
Por lo cual vamos a ver como instalar el compilador para nuestro Ubuntu.
Paso 1: Editar nuestro .bashrc con lo siguiente:
k001@icemovil$ export GOROOT=$HOME/go k001@icemovil$ export GOARCH=386 k001@icemovil$ export GOOS=linux k001@icemovil$ export GOBIN=$HOME/bin k001@icemovil$ export PATH=$GOBIN:$PATH |
Paso 2: Creamos un directorio llamado bin:
k001@icemovil$ mkdir ~/bin k001@icemovil$ $chmod 755 ~/bin |
Paso 3: Instalamos los paquetes necesarios para compilar:
k001@icemovil$ sudo apt-get install python-setuptools python-dev k001@icemovil$ sudo apt-get install mercurial k001@icemovil$ hg clone -r release https://go.googlecode.com/hg/ $GOROOT k001@icemovil$ sudo apt-get install bison gcc libc6-dev ed make |
Paso 4: Construir el compilador:
k001@icemovil$ cd $GOROOT/src |
k001@icemovil$ ./all.bash |
Con eso ya iniciará la compilación para tener nuestro compilador de “GO”.
Pronto daré ejemplos de codigo con dicho lenguaje.
Actualmente existen varios servicios de hospedaje gratuito para
repositorios git, el único requisito es que nuestros proyectos sean
opensource. Pero si no queremos que algún proyecto sea público, ya
sea porque X o Y razón, tendríamos que pagar una módica
cantidad.
Aunque es un precio accesible, algunos si somos bien
<del>pobres</del> codos y por otro lado, si tenemos otro lugar para
hospedarlo nos podemos ahorrar esos loritos para otra
ocasión.
Esta receta puede llevarse a cabo tanto local como remotamente,
para comenzar necesitaremos únicamente de git y un servidor ssh,
los cuales en debian y derivados se instalan de esta manera:
# apt-get install git-core openssh-server |
Para crear los repositorios nos conectaremos al servidor remoto.
En mi caso hice esto localmente y decidí agregar el usuario git, ya
que en mi disco duro tengo una partición dedicada para /home.
$ ssh git@git.kelevra.org |
Y ejecutamos los siguientes comandos:
$ mkdir test-project.git $ cd test-project.git $ git --bare init # inicializamos el repositorio remoto |
Con eso ya tenemos nuestro repositorio funcionando, ahora vamos
a commitear algunos archivos:
$ cd projects $ mkdir test-project $ cd test-project $ git init # inicializamos el repositorio local $ git remote add origin git@git.kelevra.org:test-project.git # agregamos el repositorio remoto $ echo 'Hello World!' > README $ git add README $ git commit -m 'first push' $ git push origin master |
Si todo ha ido bien, veremos algo como:
git@git.kelevra.org's password: Counting objects: 3, done. Writing objects: 100% (3/3), 221 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To git@git.kelevra.org:test-project.git [new branch] master -> master |
Nuestro repositorio está trabajabdo bien, el password obviamente
es el que le hayamos designado al usuario que creamos.
¿Pero que pasa si otros van a colaborar en mi proyecto?
Tienes dos opciones: La número uno sería que les hagas saber el
password de dicho usuario, pero estar escribiendolo cada vez que
vayamos a pushear algo es molesto.
La número dos y la más recomendable: Usar SSH-KEYS.
A saber, existen dos tipos de llaves, DSA y RSA, sea cual sea
nuestra elección, el procedimiento para crear un par de llaves es
la siguiente:
$ ssh-keygen -t dsa # cambiar por rsa según nuestra elección Generating public/private dsa key pair. Enter file in which to save the key (/home/kelevra/.ssh/id_dsa): .ssh/git_dsa # no es obligatorio especificar ubicación Enter passphrase (empty for no passphrase): # escribimos una clave para usar la llave Enter same passphrase again: # y la escribimos de nuevo para confirmar Your identification has been saved in .ssh/git_dsa. Your public key has been saved in .ssh/git_dsa.pub. |
Hemos generado una llave pública y una privada, la pública es la
que copiaremos al servidor remoto:
$ scp .ssh/id_dsa.pub git@git.kelevra.org:.ssh/authorized_keys2 git@git.kelevra.org's password: id_dsa.pub 100% 608 0.6KB/s 00:00 |
Ahora ya no nos pedirá el password del usuario cada vez que
hagamos push o nos conectemos para crear un nuevo repositorio, en
su lugar nos pedirá la clave que le asignamos a nuestro par de
llaves. Pero aún tenemos que escribir un password, sin embargo
podemos usar ssh-agent que recordará por determinado
tiempo nuestras claves, para iniciar este agente basta con teclear
en la terminal:
$ ssh-agent SSH_AUTH_SOCK=/tmp/ssh-RwRst31999/agent.31999; export SSH_AUTH_SOCK; SSH_AGENT_PID=32000; export SSH_AGENT_PID; echo Agent pid 32000; |
Ya una vez corriendo el agente agregamos nuestra llave:
$ ssh-add .ssh/git_dsa Enter passphrase for .ssh/git_dsa: Identity added: .ssh/git_dsa (.ssh/git_dsa) |
¡Y listo! Nos conectamos de nuevo vía ssh o hacemos otro push
para comprobar que ya no nos pide el password del usuario y de la
llave ssh. Y ahora si ya tenemos nuestro servidor de repositorios
git bien sencishito y carismático
#pkg-get en Solaris
(manejador de paquetes para solaris)
Como primer paso le recomiendo se den una vuelta por
http://www.bolthole.com/solaris/pkg-get.html Que es el sitio oficial para el manejador de paquetes que utilizaremos llamado
pkg-get
Usando pkg-get Y el repositorio blastwave podremos instalar software en nuestro Solaris/Open Solaris de manera similar a debían.
Primer Paso instala pkg-get
#pkgadd -d http://www.blastwave.org/pkg_get.pkg
Aceptamos todas las preguntas que nos hará el instalador,el repositorio a usar es www.blastwave.org que contiene 1700 paquetes de sofrware en su mayoria open source todo este repositorio trabaja bajo /opt/csw Y el Fichero de configuracion de pkg-get se encuentra en
/opt/csw/etc/pkg-get.conf
Definimos nuestro mirror a usar
url=http://mirrors.sunsite.dk/csw/stable
Si estamos atrás de un Firewall o algun Proxy
configuramos las lineas correspondientes
# If you are behind a firewall, set one of these as appropriate
#ftp_proxy=http://your-proxy:8023
#http_proxy=http://your-proxy:8023
#export http_proxy ftp_proxy
Guardamos y como primer paso
#/opt/csw/bin/pkg-get -U
Y es todo a instalar el software que necesitemos ![]()
Se me ocurre instalar
/opt/csw/bin/pkg-get -i nano
/opt/csw/bin/pkg-get -i bash
/opt/csw/bin/pkg-get -i vim
En el siguiente tutorial sera configuracion de postfix en Solaris Usando Mysql para la BD de usuarios ![]()
Dudas a roa@unixmexico.org/roa@tucancunix.net
Replicacion de Mysql en FreeBSD
Master To Slave
El punto es.. mantener tus B.D sincronizanadas y no tener perdida de datos , y tener nuestros backups al día.
Manos a la Obra
Requerimientos mínimos
Tener Acceso root tanto en el sistema como en las base de datos.
Servidor 1 FreeBSD 6.3 (será Nuestro servidor Master)
Mysql Server mysql-server-5.0.51a (Corriendo N cantidad de Base de datos)
Servidor 2 FreeBSD 7.0
Mysql Server mysql-server-5.0.67_1 (Sin Bases de datos)
La teoría es replicar las bases de datos del Servidor 1 al Servidor 2 Y ya en el servidor 2 sacarle un backup a todas nuestras base de datos, para no sobre cargar nuestro servidor 1 que se encuentra en producción.
Aquí pueden replicar 1 base de datos o todas las base de datos mi caso es el segundo.
Les recomiendo se lean http://dev.mysql.com/doc/refman/5.0/es/replication.html antes de comenzar todo.
y si por algun motivo algo no les funciona revisen de nuevo sus configuraciones en ambos servidores por que si no pasaran horas tratando de dar con el problema y resultara que se les fue algún carácter raro en los archivos de configuración de mysql “Experiencia Personal” , al mejor cazador se le va la liebre no?.
Manos a la obra.
En nuestro Servidor 1 Que es nuestro servidor Master de Mysql daremos de alta
un usuario que nos servira para replicar las bases de datos con esta sentencia
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘replicador’@'host_esclavo’ IDENTIFIED BY ‘mi_contraseña’;
Donde replicador=Es el usuario que nos permitira hacer la replica de nuestras bases de datos
hosts_esclavo=la ip o el host de nuestro servidor esclavo
mi_contraseña= Sera igual a la contraseria del usuario que replicara las bases de datos.
En nuestro Servidor 2 Ingresamos la misma sentencia
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘replicador’@'host_master’ IDENTIFIED BY ‘mi_contraseña’;
El Unico cambio aqui sera el host_master que sera igual a la Ip o el nombre del host.
Siguiente paso configuración de los servidores de Base de Datos tanto en el Servidor 1 (Master) Como en el Servidor 2 (Slave)
Editaremos En el Servidor1 (Master) El archivo my.cnf , si usamos Linux/Unix/Windows usaremos nuestro editor de texto preferido.
nano /var/db/mysql/my.cnf
Agregaremos estas opciones
[mysqld]
server-id = 1
log-bin = /var/log/mysql/bin.log
Donde server-id es un numero con el que se identificare al servidor maestro.
La segunda linea log-bin es la ruta de la bitacora binaria, Asegurarnos que ese directorio exista y que el usuario mysql sea el propietario y tenga
permisos de escritura sobre el mismo directorio.
#mkdir /var/log/mysql; chown mysql.mysql /var/log/mysql
Para Nuestro Servidor Esclavo o Slave, añadiremos unas lineas extras al archivo de configuración de my.cnf
Buscamos la sección
[mysqld]
server-id= 2
master-host = host_maestro,com # o la IP del servidor maestro
master-port = 3306
master-user = replicador
master-password = mi_contraseña
log-bin = /var/log/mysql/bin.log
log-bin-index = /var/log/mysql/log-bin.index
log-error = /var/log/mysql/error.log
relay-log = /var/log/mysql/relay.log
relay-log-info-file = /var/log/mysql/relay-log.info
relay-log-index = /var/log/mysql/relay-log.index
Y ahora que ? Ya tenemos las configuraciones tanto en el servidor 1 (master) como en el Servidor2(Slave)
El siguiente paso sera copiar todas las BD del Servidor 1 Hacia el Servidor2
Pero si el servidor Master esta en produccion si sacamos un respaldo de nuestro servidor master
y lo llevamos al servidor slave, podrian existir inconsistencias en nuestras base de datos
Para eso tendremos que prevenir todo eso.
En nuestro servidor master hacemos esto
mysql> SHOW VARIABLES LIKE ‘max_connections’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 100 |
+—————–+——-+
mysql> SET GLOBAL max_connections = 0;
Lo que hicimos es indicarle a mysql que ya no podran realizarse conexiones a la BD y solo se reserva
1 sola conexion que es para root .
Y procedemos a sacar el dump de todas las bases de datos.
# mysqldump –user=root –password=mi_root_pwd –extended-insert –all-databases –master-data > /tmp/backup.sql
Necesita explicacion? .
Procederemos a llevarnos nuestro backup de nuestras BD hacia el servidor esclavo ya sea usando
scp or ftp como sea de nuestro agrado tranferirlas.
Ok Cuando Establecimos las conexiones a 0 y al sacar el dump de eso
Nos agrega unos datos que probablemente necesitaremos mas adelante.
####
–
– Position to start replication from
–
CHANGE MASTER TO MASTER_LOG_FILE=’bin.00046′ ;
CHANGE MASTER TO MASTER_LOG_POS=8827 ;
###
O podemos obtener estos datos en el servidor master
En el servidor maestro visualizamos el estado del servidor:
mysql> SHOW MASTER STATUS\G
File: bin.00046
Position: 8827
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
Bueno nos quedamos en la parte de mover el backup hacia nuestro servidor esclavo y restauraremos
todas las bases de datos con la siguiente sentencia.
Siguiente paso
#mysql –user=root –password=mi_root_pwd < /tmp/backup.sql
Si no nos da ningun error eso quiere decir que todas nuestras bases de datos fueron restauradas en nuestro
servidor slave.
Iniciamos con esta sentencia nuestro servidor SLAVE no olviden regresar a 100 la opcion de max_connection.
#mysql>CHANGE MASTER TO MASTER_HOST=’ip-maestro’,MASTER_USER=’slave’, MASTER_PASSWORD=’slaveabdul’,MASTER_LOG_FILE=’bin.00046′, MASTER_LOG_POS=8827;
#mysql> START SLAVE;
Aqui si todo esta bien se empezaran a sincronizar los ultimos cambios del servidor master
al servidor slave.
Facil no?
Ahora si necesitamos sacar un respaldo en nuestro servidor Slave
Solo basta con parar la replicacion
mysql> STOP SLAVE;
Y sacar el dump de cualquier base de datos y luego volver a arrancarlo
mysql> START SLAVE;
O podemos sacar respaldos Automatizados, mediante este script en bash.
#!/bin/sh
fecha=`date +%Y%m%d`
mysqladmin –user=root –password=mi_root_pwd stop-slave
mysqldump –user=root –password=mi_root_pwd –lock-all-tables –all-databases > /roa/mysql/respaldo-$fecha.sql
mysqladmin –user=root –password=mi_root_pwd start-slave
Se le pueden agregar mas opciones
pero ya es cuestion de uno. Si son algo paranoicos podremos hacerlo sobre ssh-tunels para Mysql aqui en un tutorial que anteriormente escribi espero que le sirva
Dudas a roa@unixmexico.org,roa@tucancunix.net