🚀 go-pugleaf

Gracias, de momento ya se por donde ir. pero un par de detalles.

>>
>>Se suponia que programilla era un programa no shell con suid
>>
> 
> Hombre, si es un programilla que tiene el mismo contexto de seguridad que el
> servidor web, lo puedes meter en la misma p�gina PHP.  "Romper" el proceso
> tiene sentido cuando cambias el contexto de seguridad.
> [...]
 > 1/ Te he dado ya otras dos posibilidades: utilizar un
 > programa compilado en lugar de un script, si lo vas a hacer t�.

Eso es lo que queria decir con "un programa no shell con suid".

> 
> Ya: eso lo entiendo.  Pero contra el vicio de pedir, est� la virtud de no
> dar.


Si pero, lo primero es que el que paga manda, y lo segundo es que son 
"problemas mios" el tener que usar cron. Es evidente que una aplicacion 
robusta y bien hecha (aunque mas complicada) no necesitaria de cron. Es 
decir Lo que es una funcion inmediata yo la he transformado en mi (tu) 
resolucion en algo que requiera de tiempo.

En concreto ademas hay que hacer una demostracion de ciertas 
aplicaciones donde la velocidad en su uso, es vital. Asi que no puedo 
esperar minutos en procesar nada. Cosas del guion.

> Esta es otra: tienes dos bases de datos (/etc/passwd y la DB en MySQL) con
> informaci�n redundante.

Nada mas lejos de la realidad. Los datos de Mysql seran muchos y varios. 
Nombre, apellidos, direccion, cargo, empresa, telefono, movil, email de 
contacto etc etc etc...

ademas aqui guardare el username y password. y un 'activado' que 
comprobara el programa del cron.

 > Eso huele a chamusquina y, si es cierto lo que
> digo (lo de que existir� informaci�n redundante) deber�a tratar de
> evitarse.

Realmente no es informacion redundante desde mi punto de vista, y si lo 
es, me salto la normalizacion por necesidades de optimizacion :)


> 
> Por cierto, lo que no podr�s es guardar en MySQL la contrase�a utilizando la
> funci�n crypt, porque es de una sola v�a. 

Lo de el password ya lo tengo resuelto.

> Para crear el usuario
> propondr�a, si es adecuado en tu entorno, utilizar siempre la misma
> password en el momento de alta de la cuenta (con lo que no habr�a que
> incluirla en la base de datos), o una distinta cada vez, creada
> aleatoriamente y que se borra de la base de datos inmediatamente despu�s de
> verificar que el alta ha sido llevada con �xito.

--
Alex Estevez

PD: No pense que diese para tanto el tema :)