Hace algún tiempo que instale el servidor SVN en uno de nuestros servers con el fin de usarlo para motte. Como siempre pasa, por poco tiempo y falta de planificación ahora motte creció y tenemos hosteados varios proyectos, con lo cual se creo svn.codigolibre.net, ahora el tema que teníamos antes es que estaba pensado el SVN en un principio para un solo proyecto, el framework motte, con lo cual el versionado venia bárbaro, pero al subir cosas dentro del mismo repositorio los demás proyectos comenzaron a tomar el mismo numero de versionado que motte, con lo cual es una #@$&, así que migre el viejo SVN y su configuración anterior a un Vhost de apache2 usando DAV_SVN, con esto gano, en que separo los proyectos, quedan versionando individualmente y puedo ponerlo en cualquier dominio!, así que voy a intentar explicar como realizar esto, y que quede funcionando, de momento esta sobre http, pero pasarlo a https no es tan difícil! y estoy buscado como enjaular el svn.

y tenemos por ejemplo 2 dominios: svn.proj1.net o svn.proj2.net o podemos tenerlo en carpetas para un dominio ej: http://svn.codigolibre.net/motte y http://svn.codigolibre.net/project1 (en si la conf no cambia en mucho).

En donde tenemos la configuración de nuestro vhost debemos agregar las siguientes lineas:

<location /motte> # aca cambia, para que sea svn.codigolibre.net/motte
Order allow,deny
Allow from all
DAV svn
SVNPath /srv/repos/proj1 # El path al repositio, ver tambien SVNParentPath
SVNAutoVersioning On #Esto habilita el commit de forma automatica
Require valid-user
AuthType Basic
AuthName “project Subversion Repository”
AuthUserFile /etc/apache2/svn/proj1.dav_svn.passwd # usuarios del repositorio
AuthzSVNAccessFile /etc/apache2/svn/proj1-authz # permisos sobre el mismo
</location>

Agregamos los usuarios al dav_svn.passwd (yo, cree uno por projecto), para esto usamos htpasswd, las opcion -c crea el archivo, y la -m agrega usuarios.

$sudo htpasswd  -c -m /etc/apache2/svn/proj1.dav_svn.passwd pepe
$sudo htpasswd  -m /etc/apache2/svn/proj1.dav_svn.passwd juan

El archivo de Authz, podría ser algo así, los nombre pueden cambiar….

[groups]
desarrolladores = pepe, juan # los que definimos en el passwd
otros = anonimo
[/]
@desarrolladores = rw
@otros = r

Luego de esto, recargamos apache y listo, esta andando….

De momento en svn.codigolibre.net, no se piensa usar Branches, pero para crearlas, podemos hacerlo de la siguiente manera:

a) Trunk – Este es el directorio principal de desarrollo, aquí es donde casi siempre trabajamos

b) Tags – Este es el directorio de las versiones de liberación y de las alpha/beta, es un directorio “muerto”, cada vez que hay una nueva versión, se coloca en tags para el histórico y hacer el archivo project-version.tar.gz y se sigue trabajando en trunk

c) branches -Este es el directorio de las pruebas, si alguien desea intentar algo nuevo o hacer un experimento, lo desarrolla aqui y si resulta y el grupo lo acepta, se mueve al trunk

Para crear este árbol:

$svn –username pepe mkdir http://svn.codigolibre.net/motte -m “create project directory”
$svn mkdir http://svn.codigolibre.net/motte/trunk -m “create trunk directory”
$svn mkdir http://svn.codigolibre.net/motte/tags -m “create tags directory”
$svn mkdir http://svn.codigolibre.net/motte/branches -m “create branches directory”

Bueno, me queda por ver la posibildad de alguna interfaz web que haga mas facil el mantenimiento de los repos,usuarios y authz por mysql/ldap y chrootear el svn.

mas info en: svnbook, svn en wikipedia

Despues de una larga targe de apt-get el día sabado, ya que anteldata esta mal (que raro no!) restaure las configuraciones del samba sin dramas, así como los .tdb los verifique, probe de lo que tenia a mano, mi laptop con GNU/Linux y una maquina de la empresa con XP. barbaro, todo andando ! me voy.

Hoy, me llaman temprano, la maquina con 98 no se conecta… pensé (a veces pasa), me habrá quedado mal el usuario, toda la mañana luchando, nada… me sentía frustrado, samba me estaba ganando! y no tenia idea de por que. Los logs no me daban mucha informacion, lo unico que veia el el IPC, y mas nada…

Así que pense, sera un bug del Samba…., parece que no, no, a las 10, cai leyendo que en unas vesiones atras sacaron el lanman, o sea, esta deshabilitado por defecto, por medidas de seguridad:

samba (3.0.27a-2) unstable; urgency=low

* debian/patches/disable-weak-auth.patch: disable plaintext authentication
on the client, and lanman authentication on both client and server, by
default since these are only needed for Win9x or Samba with encrypted
passwords disabled and are potential password attack vectors. This
change is backported from Samba 3.2. LP: #163194.

Claro, los winNT no lo necesitan, no así los 9x, así que por una maquina tuve que activarlo:

chequee que no estaba activado con #testparm -vs | grep lanman que me devolvio:

lanman auth = No

y luego chequee la pass:

#pdbedit -w username -d0
username:1002:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:ADEC9EDC3A6A794D691E6DFAFCFAEE85:[U
> ]:LCT-481B6630:

Y donde estaba ese monton de XXXX deberia de haber unos hermosos hexas, así que habilite en el smb.conf agregando lanman auth = yes, y luego cambiando la pass con smbpasswd username y listo, ahora si, si hacemos el pdbedit en lugar de X aparecen los hexas! y quedo andando al toque….

Parece una pavada, pero que dolor de cabeza me dio esta mañana.

Bien, primero creamos la key del servidor para encriptar y firmar

#openssl genrsa -out servidor.key
#chmod 400 servidor.key

Luego de esto debemos crear el CSR (Certificate signing request)

#openssl req -new -nodes -key servidor.key -out servidor.csr

Aquí debemos de responder a varias preguntas, siendo la mas importante el CommonName
donde debemos especificar el hostname exacto del mailserver, pej correo.dominio.com.
El CSR es el archivo que ser enviara a CA (Certificate Authority – Entidad Certificadora) quien sera el que nos firme, en este caso usamos CaCert, por que lo hace sin costo alguno, pero se puede usar cualquier otro, los pasos no se si varían mucho, pero creo que no.

En CaCert.org, debemos registrarnos, ingresar un dirección de correo, agregar el dominio y aquí se nos pedida que peguemos el contenido del CSR, el cual podemos hacer # cat servidro.csr y copiar el contenido al navegador.
Luego de esto CaCert nos proveerá por mail y por la pagina el contenido firmado. Este lo guardamos como servidor.crt.

Ahora nos resta crear el archivo .pem que es lo que lee el Courier, este consta de 2 partes

1. La .key del servidor
2. El certificado firmado por el CA
3. Y el codigo Diffie-Hellman

Para eso realizamos los siguientes pasos:

# cat servidor.key servidor.crt > /etc/courier/imapd.pem

# openssl gendh >> /etc/courier/imapd.pem

Y reiniciamos courier, ahora cuando ingresemos al servidor desde nuestro cliente para acceder
al IMAPs estaremos usando nuestro certificado, dependiendo del cliente debemos de agregar la entidad certificadora para eso instalamos este certificado : https://www.cacert.org/certs/root.crt

Puede ser de utilidad a mas de uno…. Excusas no, complicaciones inesperadas!

Baje el fw, pero nunca preste atención a que era para el wap54g (si el mismo modelo) pero v1, y luego de subir y que se reiniciara el AP paf! nunca mas arranco. Como siempre pasa en estos aparatos en toda Internet abunda los sitios en donde te dice como flashear, pero todos eran para la v1 o v2 y el mio es un v3. El cambio es bastante notorio, por que mientras que en el otro debía puentear los pin 15 y 16 del Intel Flash en la parte de abajo de la PCB. en esta versión no había ningún Intel; Sino un SST39VF1601. En esta versión del AP la pata 15 no esta conectada a ningún lado, Entonces investigue un poco mas y encontré que para poder revivirlo tenemos que hacer lo siguiente.

El pin 16 de SST debemos de conectarlo a GND, hay un punto cercano, ( lo pueden ver en las imagenes ) Este corto produce que se genere un checksum error durante la carga, dejandonos el AP en la IP por defecto (192.168.1.245 clave: admin) y esperando una nueva fw.

Bueno soldamos entre el pin 16 del integrado SST ( o el pin 5 del zocalo en donde iria el chip Intel ) siempre contando desde la marca en el IC, después cada 5 pin hay una linea blanca o sea que no es muy difícil perderce. PERO OJO si no están seguros cuenten bien, ya que si conectan mal pueden matar el IC SST y chau AP!.

Luego de haber hecho el puente, a encenderlo y luego de unos 2 seg, deben de cortar el puente, siempre con el AP conectado así que CUIDADO! entonces haganle un pin desde su maquina a 192.168.1.245 y si responde es que todo salio bien!

Luego usando el FW correcto que lo adjunto al final de la pagina

desde Windows :

tftp -i 192.168.1.245 PUT path_archivo.trx

desde GNU/Linux (*nix)

atftp 192.168.1.245
atftp> trace

atftp> timeout 1

atftp> put archivo.trx

La re programación dura unos 2 min, pero dejenlo unos mas!, luego reinicienlo y apaguen y prendan hasta que puedan acceder a la pagina! y desde ahi lo pueden configurar de nuevo a su conflagración original, y en la parte de Advance settings del wireless van a ver que pueden aumentar la potencia de 42 a 84 mw el máximo disponible para este FW, así como también tienen hasta el canal 13 y la opción de poder elegir que antena usan para Tx y para Rx.

Espero que les sirva! y NO ME HAGO RESPONSABLE SI HACEN ALGO MAL O NO LES FUNCIONA, LO HACEN BAJO SU PROPIO RIESGO!

wap54g_v3-30402-hyperwap_v3.zip

password1 (106)

abc123 (73)

swimmer1(43)

iloveyou1 (41)

monkey1 (40)

fackyou (37)

123456 (33)

myspace1 (32)

fackyou1 (32)

i(32)

password (27)

babygirl1 (25)

iloveyou2 (24)

football1 (24)

danny12031986 (23)

blink182 (23)

princess1 (22)

freesh**4me (22)

16188s (22)

123abc (22)

Me gustaria que los aparatos de seguridad biométrica estén mas al alcance de las personas

Noticia Original