Ocultar Passwords a produccion.

[Asdtaker]

Estimados, mi ultima consulta aqui fue respecto de un cliente para jabber (y
ya vieron lo que ocurrio (y esta ocurriendo)). Finalmente, se opto por
openfire y spark como cliente, lejos las discusiones respecto a la
performance del modelo, ya esta implementado y camina /de pelos/. Gracias a
todos lo que dieron sus opiniones.

Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios
con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como
escondo las password (y usuarios) de las db a los programas y usuarios?. Es
decir, pe. al configurar el acceso a mysql para un servicio web (LAMP),
necesariamente debo configurar en un file la passwordm user y database que
utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones
cliente-servidor, con archivos de configuracion en cada cliente, o bien (en
el caso sql server) odbc, en ese caso no existe manera de encriptar las
password, y al menos debe conocerla el desarrollador/analista de la
aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un
archivo de configuracion. Mi problema es que necesito que estas password no
sean conocidas por nadie, ni siquiera el admin del sistema (password
bipartida) y el dia de mañana poder cambiarlas de manera transparente para
los usuarios.

He hecho monos, tirado lineas y buscado en san google, pero ando medio
perdido. Espero me puedan orientar.

Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la
autenticacion, es decir:

SERVER(user, pass)<:>**ALGO**<:>CLIENTE(user, _clave_)

donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario
de dominio, etc.

De antemano, muchisimas gracias.

-- 
Saludos, LSM.
Existen 10 tipos de personas:
los que entienden binarios y los que no
From [EMAIL PROTECTED]  Wed Dec  5 14:10:37 2007
From: [EMAIL PROTECTED] (Alvaro Herrera)
Date: Wed Dec  5 14:13:35 2007
Subject: Ocultar Passwords a produccion.
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Asdtaker escribió:

> Otro problema, y mas grande aun, en cuando tenemos aplicaciones
> cliente-servidor, con archivos de configuracion en cada cliente, o bien (en
> el caso sql server) odbc, en ese caso no existe manera de encriptar las
> password, y al menos debe conocerla el desarrollador/analista de la
> aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un
> archivo de configuracion. Mi problema es que necesito que estas password no
> sean conocidas por nadie, ni siquiera el admin del sistema (password
> bipartida) y el dia de mañana poder cambiarlas de manera transparente para
> los usuarios.

Eso es imposible.  Ademas, no lograrias nada, porque el administrador de
la maquina, siendo "root", podria de todos modos detener el servidor y
levantarlo en el modo que no requiere password, si quisiera robarse tu
informacion.

Las passwords necesariamente deben estar en un archivo en alguna parte.
Lo que mas puedes hacer es que dicho archivo este oculto y que nadie
(salvo la aplicacion) tenga privilegios para leerlo.

-- 
Alvaro Herrera  Developer, http://www.PostgreSQL.org/
"Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias)
From [EMAIL PROTECTED]  Wed Dec  5 17:54:21 2007
From: [EMAIL PROTECTED] (Horst H. von Brand)
Date: Wed Dec  5 17:57:12 2007
Subject: =?iso-8859-1?q?Re=3A_Re=3A_Re=3A_Benchmarking_en_distintos_le?=
=?iso-8859-1?q?nguajes_=5B_Era_algo_as=ED_como_cliente_en_jabber?=
=?iso-8859-1?q?=2E=2E=2E_=5D?=
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Aldrin Gonzalo Martoq Ahumada <[EMAIL PROTECTED]> wrote:
> On Dec 3, 2007 10:59 AM, Xavier Andrade <[EMAIL PROTECTED]> wrote:
> > On Sun, 2 Dec 2007, Aldrin Gonzalo Martoq Ahumada wrote:
> > > Discrepo. Lo que se llama "maquina" es la definicion de una
> > > arquitectura y su set de instrucciones. Cuando se habla de "maquina
> > > virtual", se quiere decir que ese set de instrucciones no es el mismo
> > > que el implementado en hardware; por lo tanto si quieres ejecutar ese
> > > set de instrucciones requeriras de un paso de traduccion.
> > > Un interprete es un programa que realiza la traduccion desde un set de
> > > instrucciones o lenguaje y las ejecuta, de manera que puedas correr el
> > > codigo en tu maquina "real". La distincion importante es que el paso
> > > de traduc

Ocultar Passwords a produccion.

[Franco Catrin L.]

Asdtaker <[EMAIL PROTECTED]> ha escrito:

[...]

> Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios
> con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como
> escondo las password (y usuarios) de las db a los programas y usuarios?. Es
> decir, pe. al configurar el acceso a mysql para un servicio web (LAMP),
> necesariamente debo configurar en un file la passwordm user y database que
> utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones
> cliente-servidor, con archivos de configuracion en cada cliente, o bien (en
> el caso sql server) odbc, en ese caso no existe manera de encriptar las
> password, y al menos debe conocerla el desarrollador/analista de la
> aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un
> archivo de configuracion. Mi problema es que necesito que estas password no
> sean conocidas por nadie, ni siquiera el admin del sistema (password
> bipartida) y el dia de mañana poder cambiarlas de manera transparente para
> los usuarios.
>
> He hecho monos, tirado lineas y buscado en san google, pero ando medio
> perdido. Espero me puedan orientar.
>
> Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la
> autenticacion, es decir:
>
> SERVER(user, pass)<:>**ALGO**<:>CLIENTE(user, _clave_)
>
> donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario
> de dominio, etc.

Para algo asi deberias tener una capa intermedia.  Imagina esto:

Cliente -> Red -> Capa Intermedia -> BD

Tus aplicacioens clientes se autentican contra la capa intermedia, y  
con esa autenticacion solo pueden tener acceso a determinados  
"servicios".  Es la capa intermedia la unica que tiene acceso directo  
a tu BD y esa es la "todopoderosa".

Saludos
-- 
Franco Catrin L.
http://www.tuxpan.com/fcatrin


This message was sent using IMP, the Internet Messaging Program.

Ocultar Passwords a produccion.

[Asdtaker]

On Dec 6, 2007 1:11 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:

> Asdtaker <[EMAIL PROTECTED]> ha escrito:
>
> [...]
>
> >
>
> >
> > Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita
> la
> > autenticacion, es decir:
> >
> > SERVER(user, pass)<:>**ALGO**<:>CLIENTE(user, _clave_)
> >
> > donde clave, es una llave, un id de instalacion, la ip de mi LAN, el
> usuario
> > de dominio, etc.
>
> Para algo asi deberias tener una capa intermedia.  Imagina esto:
>
> Cliente -> Red -> Capa Intermedia -> BD


Sip, eso se parece a mi **ALGO**.

>
>
> Tus aplicacioens clientes se autentican contra la capa intermedia, y
> con esa autenticacion solo pueden tener acceso a determinados
> "servicios".  Es la capa intermedia la unica que tiene acceso directo
> a tu BD y esa es la "todopoderosa".

Ok, tenemos el "qué".
Y ahora me pregunto el "como". Ahi es donde aun no logro concebir nada.


>
>
> Saludos
> --
> Franco Catrin L.
> http://www.tuxpan.com/fcatrin
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
Gracias a todos y sego buscando

-- 
Saludos, LSM.
Existen 10 tipos de personas:
los que entienden binarios y los que no
From [EMAIL PROTECTED]  Thu Dec  6 14:33:08 2007
From: [EMAIL PROTECTED] (Ricardo Mun~oz A.)
Date: Thu Dec  6 14:37:09 2007
Subject: [LinUTFSM] Mayor Orden
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]><47  [EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Rodrigo Fuentealba wrote:
> El 6/12/07, Ricardo Mun~oz A. <[EMAIL PROTECTED]> escribió:
>   
>> Ricardo Albarracin B. wrote:
>> 
>
> [ ... harto texto; ver mensaje original para referencias ... ]
>
>   
>>> [...estamos cansados de las malas costumbres como por ejemplo: ]
>>> la mala costumbre de repetir un "papiro" para agregar 2 lineas
>>>   
>
> [ ... harto texto; ver mensaje original para referencias ... ]
>
>   
>> curiosamente (algunos de) los mismos que exigen respetar ciertas normas
>> reclaman que por favor no "alejen a la gente de la lista"...
>> 
>
> Modificación de la Ley de Godwin aplicable a Ricardo Muñoz A:
>
> "Si hay una discusión en Internet en la cual se habla de buenas
> costumbres en cualquier aspecto (llámese programación, listas de
> correo, bases de datos, etc...), en un plazo de menos de tres días
> aparecerá Ricardo Muñoz A. contradiciendo todo lo que hemos logrado
> hasta ahora, y se hará un flame de al menos 95 e-mails que podríamos
> haber aprovechado en temas más importantes como la inmortalidad del
> cangrejo."
>   

una mas, y le pido al Owner que te saque de la lista. estas siendo 
bastante grosero. si tanto te molestan mis mails, simplemente ignoralos.

-- 
Ricardo Mun~oz A.
Usuario Linux #182825 (counter.li.org)
From [EMAIL PROTECTED]  Thu Dec  6 14:56:09 2007
From: [EMAIL PROTECTED] (Ricardo Mun~oz A.)
Date: Thu Dec  6 14:59:52 2007
Subject: [LinUTFSM] Mayor Orden
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]><[EMAIL PROTECTED]   d.cl>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Alvaro Herrera wrote:
> Ricardo Mun~oz A. escribió:
>
>   
>> curiosamente (algunos de) los mismos que exigen respetar ciertas normas 
>> reclaman que por favor no "alejen a la gente de la lista"...
>> 
>
> Bueno, el punto es conservar la lista como un recurso util, donde se
> puedan plantear preguntas y que hayan respuestas utiles, que se genere
> discusion interesante, etc.  Hay muchas cosas que vuelven a la lista un
> medio menos util.  Por ej. que haya un lote de pasteles que responda con
> un simple "RTFM" (afortunadamente eso ya no pasa tanto).  Pero tambien
> que las normas minimas no se cumplan, como por ej. lo del top-posting, o
> contestar dos líneas al final citando el mensaje anterior gigante
> completo, o escribir en HTML (afortunadamente esto último tampoco ocurre
> porque se bloqueó de raíz en Mailman).
>   

IMHO los mensajes de la lista se pueden dividir en las siguientes 
categorias:

- preguntas tecnicas -> generalmente se responden con alguna URL con la 
solucion del problema. aca se podria justificar un RTFM, STFW, etc. ya 
que en la mayoria de los casos buscando un poco se puede encontrar la 
solucion.
- discusiones sobre algun tema particular -> estos threads pueden durar 
harto. aca nunca deberia aparecer un RTFM.
- off-topics -> los modales y buenas costumbres se ponen a prueba.
- flamewars -> aca no existen los modales ni buenas costumbres.

> Para mi gusto, el que en la lista haya estas meta-discusiones tan a
> menudo (discusiones acerca de la lista misma: que la convivencia, que
> las normas, que el objetivo de la lista, que los off-topic, etc) es una
> mala señal, porque indica que la lista no está funcionando de manera
> ideal, ni mucho menos.  Hay demasiado desorden, y eso molesta a algunos
> y eso genera la meta-discusion (como la actual).  La me

Ocultar Passwords a produccion.

[Franco Catrin L.]

Asdtaker <[EMAIL PROTECTED]> ha escrito:

> On Dec 6, 2007 1:11 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote:

>> Tus aplicacioens clientes se autentican contra la capa intermedia, y
>> con esa autenticacion solo pueden tener acceso a determinados
>> "servicios".  Es la capa intermedia la unica que tiene acceso directo
>> a tu BD y esa es la "todopoderosa".
>
> Ok, tenemos el "qué".
> Y ahora me pregunto el "como". Ahi es donde aun no logro concebir nada.

Solo necesitas algo que te permia hacer llamadas remotas, por ejemplo  
SOAP, XML/RPC, RMI, DCOM, etc.  Es trivial en algunos  
lenguajes/plataformas, tienes que ver qué hay disponible para lo que  
estes usando.

-- 
Franco Catrin L.
http://www.tuxpan.com/fcatrin


This message was sent using IMP, the Internet Messaging Program.

Ocultar Passwords a produccion.

[Mauro A. Morales M.]

On Thu, 2007-12-06 at 10:00 -0300, Alvaro Herrera wrote:
> Asdtaker escribió:
> > On Dec 5, 2007 2:10 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> 
> > > Lo que mas puedes hacer es que dicho archivo este oculto y que nadie
> > > (salvo la aplicacion) tenga privilegios para leerlo.
> > 
> > Exacto, buena practica. Pero aun tengo mi password en un file de
> > configuracion y debo entregarla al desarrollador/analista.
> 
> No entiendo.  ¿Para que tienes que entregarsela?  Solo dale privilegios
> para ejecutar la rutina de conexion a la BD.  El archivo le estará
> oculto y no podrá obtener la password por esa vía.

Complementa eso con la creacion de un ambiente de desarrollo y
produccion (si tienes espacio y/o maquina para un ambiente de testing
tanto mejor) tanto de tus aplicaciones como de tus BD y te liberas de
que tus desarrolladores sepan la contrasen~a de produccion (mas otros
beneficios de trabajar en ese esquema).

Saludos,

-- Mauro

> 

Ocultar Passwords a produccion.

[Wladimir A. Jimenez B.]

Adstaker:

Se me ocurre el siguiente esquema.

Un servicio, de comunicación estándar, con un protocolo propio.

(Servicio de Seguridad)
 Este servicio bajo un TCP-IP con los siguiente comandos.
 AUTH donde envías tu KEY(User+IP+Dominio+lo que necesites).
 Este responde con una Clave valida y la Ip del servicio de DB que necesitas.
 RESP 3DES(Key Valida en el Servidor)+ IP del Servidor+La base a la
que tiene acceso.

Con esto todas tus aplicaciones pasan por este servicio para hacer la petición.

No importaria(Plataforma, Maquina, SO) serian independientes, por lo
tanto genera la solicitud si no tiene acceso al servicio nunca
obtendra una clave.

Este servicio lo adornas con una interface grafica, y podria
ingresarse las contraseñas a travez de este sistema en dos terminales
diferentes una vez completas la dos mitades recien el sistema se
pondria a funcionar con esto nadie sabe la contraseña completa solo el
sistema.

El administrador estaria encragado de habilitar y deshabilitar
terminales o usuarios. Sin tener un real acceso a la base de datos
solo podria tener acceso a la base de permisos, puedes habilitar un
sistema de bloque que si cualquiera de la personas que se encargan de
una parte de la contraseña se vuelve riesgosa bloqueas todo hasta una
nueva validacion, con esto tus clientes son independiestes de las
contraseñas reales.

 El esquema quedaria mas o menos asi.
   (Sistema Cliente)==(KEY)==>
(Sistema de Seguridad)
\\<==(KEY3DES)==
 \\
  (KEY EN DURO)
 \\
   (SGDB)
Realmente la clave no la ve nadie, es solo visible para la apliacion
en tiempo de ejecucion, Debes otorga un medio para que las
aplicaciones puedan descifrar la contraseña antes de conectarse.

Si necesitas mas seguridad este medio haz lo cerrado, en una librería.
esta libreario le otorga la conexión, al sistema cliente, pero sigue
el proceso anterior, para obtener una clave que tampoco nadie sabrá.

Wladimir A. Jiménez B.

Ocultar Passwords a produccion.

[Aldrin Gonzalo Martoq Ahumada]

On Dec 5, 2007 1:54 PM, Asdtaker <[EMAIL PROTECTED]> wrote:
> Estimados, mi ultima consulta aqui fue respecto de un cliente para jabber (y
> ya vieron lo que ocurrio (y esta ocurriendo)). Finalmente, se opto por
> openfire y spark como cliente, lejos las discusiones respecto a la
> performance del modelo, ya esta implementado y camina /de pelos/. Gracias a
> todos lo que dieron sus opiniones.
>
> Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios
> con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como
> escondo las password (y usuarios) de las db a los programas y usuarios?. Es
> decir, pe. al configurar el acceso a mysql para un servicio web (LAMP),
> necesariamente debo configurar en un file la passwordm user y database que
> utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones
> cliente-servidor, con archivos de configuracion en cada cliente, o bien (en
> el caso sql server) odbc, en ese caso no existe manera de encriptar las
> password, y al menos debe conocerla el desarrollador/analista de la
> aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un
> archivo de configuracion. Mi problema es que necesito que estas password no
> sean conocidas por nadie, ni siquiera el admin del sistema (password
> bipartida) y el dia de mañana poder cambiarlas de manera transparente para
> los usuarios.
>
> He hecho monos, tirado lineas y buscado en san google, pero ando medio
> perdido. Espero me puedan orientar.
>
> Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la
> autenticacion, es decir:
>
> SERVER(user, pass)<:>**ALGO**<:>CLIENTE(user, _clave_)
>
> donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario
> de dominio, etc.

Tienes un problema de arquitectura o disen~o, algunos tips te dio
Franco. Esto se resuelve implementando servicios y creando una capa de
acceso a el (bus de servicios). El bus se encarga de la seguridad,
acceso, enrutamiento, excepciones, auditoria, etc.

Puedes implementarlo con muchas tecnologias y maneras, varias ya estan
hechas. Luego, lo que le das a tu desarrollador es una API o framework
que encapsula el acceso al bus y lo mas importante, a los servicios
que tiene acceso (esto independiza la tecnologia usada). Los accesos
(permisos) los defines en el servidor o en el bus.

Cualquier otro chamullo no te asegura nada. Si creas una DLL que
"encripta" la password por otra, es lo mismo, igual estas dando full
acceso a la base de datos (basta descompilar la dll o revisar el
stream a la conexion para saber que user/pass estas usando). Si creas
una DLL que realiza el servicio, estas duplicando codigo y eso lo hace
inmantenible, la logica del servicio tiene que estar donde se provee
(en el servidor) y el cliente solo debe tener una API para accesar a
el, que depende de la tecnologia usada.


Hay muchas otras razones para implementar esta arquitectura (un unico
punto con la logica, tienes un mecanismo de auditoria, generalmente el
bus te garantiza que no se pierden los datos, permite especializar los
sistemas, integrar sistemas antiguos y mejorar la performance ya que
los servidores trabajan en base a eventos en vez de a full conexiones,
...); pero en particular resuelve tu problema de acceso a los datos,
ya que no abres de patas la base de datos, sino que solo a servicios
bien conocidos y definidos. Puedes encontrar un monton de buzzwords al
respecto, estoy buscando alguna literatura que te pueda ayudar a
entender un poco el asunto Creo que este link te servira:

http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esbbenefits


Saludos,
-- 
Aldrin Martoq

Ocultar Passwords a produccion.

[Asdtaker]

On Dec 10, 2007 2:28 PM, Aldrin Gonzalo Martoq Ahumada <
[EMAIL PROTECTED]> wrote:

> On Dec 5, 2007 1:54 PM, Asdtaker <[EMAIL PROTECTED]> wrote:
>
[...mi problema]

>
>
> Tienes un problema de arquitectura o disen~o, algunos tips te dio
> Franco. Esto se resuelve implementando servicios y creando una capa de
> acceso a el (bus de servicios). El bus se encarga de la seguridad,
> acceso, enrutamiento, excepciones, auditoria, etc.

Término nuevo, tnks!

>
>
> Puedes implementarlo con muchas tecnologias y maneras, varias ya estan
> hechas. Luego, lo que le das a tu desarrollador es una API o framework
> que encapsula el acceso al bus y lo mas importante, a los servicios
> que tiene acceso (esto independiza la tecnologia usada). Los accesos
> (permisos) los defines en el servidor o en el bus.

bien!

>
>
> Cualquier otro chamullo no te asegura nada. Si creas una DLL que
> "encripta" la password por otra, es lo mismo, igual estas dando full
> acceso a la base de datos (basta descompilar la dll o revisar el
> stream a la conexion para saber que user/pass estas usando).

En realidad con eso solo obtengo lo actual. O solo necesitaria obtener el
archivo donde esté la password para hacer crack en mi sistema.

> Si creas
> una DLL que realiza el servicio, estas duplicando codigo y eso lo hace
> inmantenible, la logica del servicio tiene que estar donde se provee
> (en el servidor) y el cliente solo debe tener una API para accesar a
> el, que depende de la tecnologia usada.
>
>
> Hay muchas otras razones para implementar esta arquitectura (un unico
> punto con la logica, tienes un mecanismo de auditoria,

buen punto, los /jefes/ adoran los log de auditoria.

> generalmente el
> bus te garantiza que no se pierden los datos, permite especializar los
> sistemas, integrar sistemas antiguos y mejorar la performance ya que
> los servidores trabajan en base a eventos en vez de a full conexiones,
> ...); pero en particular resuelve tu problema de acceso a los datos,

es lo que mas me preocupa por ahora.

>
> ya que no abres de patas la base de datos, sino que solo a servicios
> bien conocidos y definidos. Puedes encontrar un monton de buzzwords al
> respecto, estoy buscando alguna literatura que te pueda ayudar a
> entender un poco el asunto Creo que este link te servira:


>
>
> http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esbbenefits


excelente, un vistazo rapido me da luces de lo que evidentemente he buscado
hace rato.

>
> 
>
>
> Saludos,
> --
> Aldrin Martoq
>
>
Saludos y muchas gracias.

-- 
Saludos, LSM.
Existen 10 tipos de personas:
los que entienden binarios y los que no
From [EMAIL PROTECTED]  Mon Dec 10 11:31:14 2007
From: [EMAIL PROTECTED] (=?iso-8859-1?Q?Cristian_Mu=F1oz_Rosenfeld?=)
Date: Mon Dec 10 15:59:02 2007
Subject: No apaga por completo
Message-ID: <[EMAIL PROTECTED]>

Estimados, tengo instalado ubuntu con kernel version 2.6.22-14en un 
notebook dell modelo Inspiron 710M. Sucede que al momento de mandar a apagar el 
equipo, este no se apaga por completo (queda el led del disco duro encendido). 

Alguien conoce donde podría indagar para solucionar el problema.

Saludos,

Cristian Muñoz Rosenfeld
From [EMAIL PROTECTED]  Mon Dec 10 16:15:35 2007
From: [EMAIL PROTECTED] (Rodrigo Fuentealba)
Date: Mon Dec 10 16:18:32 2007
Subject: No apaga por completo
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

2007/12/10, Cristian Muñoz Rosenfeld <[EMAIL PROTECTED]>:
> Estimados, tengo instalado ubuntu con kernel version 2.6.22-14en un 
> notebook dell modelo Inspiron 710M. Sucede que al momento de mandar a apagar 
> el equipo, este no se apaga por completo (queda el led del disco duro 
> encendido).

¿ACPI?

> Alguien conoce donde podría indagar para solucionar el problema.

Activa ACPI y dinos si vuelve a ocurrir.

-- 
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas - Consultor UNIX - Database Administrator