Actualizar Debian Squeeze a Wheezy con instalación de ISPconfig 3 + dovecot + roundcube

Bueno llego el tiempo de la actualización planeada de Debian 6 (Squeeze) a Debian 7 (Wheezy) en el servidor de la empresa, me leí los “known issues” de debian.org y como no encontré nada que afectara a mi server inicié con el upgrade, solo para encontrar que dovecot-core vomitó 10 errores de post-inst (arrastrando otros paquetes de dovecot).

doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf: mail_plugin_dir: access(/usr/lib/dovecot/modules/lda) failed: No such file or directory

Pues el error era de que ese archivo ‘lda’ ya no existe, asi que al cambiar la ruta de su entrada en /etc/dovecot.conf:

protocol lda {
  auth_socket_path = /var/run/dovecot/auth-master
  mail_plugin_dir = /usr/lib/dovecot/modules/lda
  mail_plugins = sieve quota
  postmaster_address = postmaster@my-domain.tld
}

a esto:

protocol lda {
  auth_socket_path = /var/run/dovecot/auth-master
  mail_plugin_dir = /usr/lib/dovecot/modules
  mail_plugins = sieve quota
  postmaster_address = postmaster@my-domain.tld
}

El archivo era correcto nuevamente, ahora a terminar de instalar:

apt-get -f install

Luego el problema era roundcube, el error de roundcube era este en /var/log/apache2/error.log:

SoftException in Application.cpp:221: File "/usr/share/roundcube/index.php" is not in document root of Vhost "/var/www/"

Rarisimo, pero buscando en startpage.com (si, ya no uso google) entre los resultados encontré esto:
http://www.crazysquirrel.com/computing/debian/servers/ubuntu-mail-server.jspx
Y encotré al culpable, se llamaba /etc/suphp/suphp.conf, tenemos que cambiar dos cosas aqui, primero el “check_vhost_docroot” que revisa si el script que estamos corriendo esta dentro del document root de este archivo (no el de apache):

check_vhost_docroot=false

Y luego encontré otra belleza gracias a este mismo archivo:

 SoftException in Application.cpp:350: UID of script "/var/lib/roundcube/index.php" is smaller than min_uid

Bueno resulta que roundcube instalado desde paquetes debian siempre guarda sus archivos como usuario root (UID 0) ya que antes roundcube llamaba a php-cli para trabajar, ahora todo lo que es php-cli se esta migrando a php5-cgi, y que para correr aplicaciones que requieran permisos altos (como para mover, copiar y borrar dentro de un buzón de correo en posesión de otro usuario) debe usar un programa llamado suphp, hasta aquí todo bien, solo que este roundcube es algo viejito y no venía preparado para el cambio por lo que es imposible hacerlo correr, a menos que cambiemos sus permisos y volvamos a modificar el archivo:

Primero cambiamos el dueño y el grupo de los directorios de roundcube:

chown -R www-data:www-data /var/lib/roundcube
chown -R www-data:www-data /usr/share/roundcube

Y luego en el archivo /etc/suphp/suphp.conf cambiamos el min_uid y el min_gid a 33 (UID Y GID de www-data):

; Minimum UID
min_uid=33

; Minimum GID
min_gid=33

Luego reiniciamos apache y probamos nuestros servicios, podemos ver que todo funciona perfectamente.

Si llegan a experimentar un error de base de datos entonces deben actualizar mysql con el script integrado:

mysql_upgrade --force  --password='mysqlrootpassword'

ISPConfig en mi configuración actual ya está integrado con estos servicios y funciona sin problemas, aun no he probado el manejo de OpenVZ, pero eso es para otro articulo.

Usar recursos de google en kdepim

Se da el caso, estamos usando por primera ves un cliente de correo electrónico en lugar del webmail de google y olvidamos la dirección de correo a la que queremos enviar el mensaje :S, o la otra que queremos enviarle correo a alguien que le envíamos algún mensaje por ultima ves hace un par de años, pues icedove (thundebird) resuelve ese problema sincronizando los contactos de su libreta de direcciónes con la nuestra de la cuenta de google, en kmail es posible pero hay que hacer algunas configuraciones al sistema:

Si tienes KDE 4 instalado lo mas seguro es que ya tengas nepomuk y akonadi, si ves que gasta mucha memoria nepomuk en “preferencias del sistema” se puede apagar (solo apaga strigi que es el componente mas pesado y activo) ahora hay que instalar el complemento para que akonadi lea los contactos desde google:

aptitude install akonadi-kde-resource-googledata

Nos vamos a “Preferencias del sistema” -> “Avanzados” -> “Recursos de KDE”, ahi sale una lista de cosas que podemos agregar y que por defecto son archivos,

En Debian Wheezy, Kubuntu, OpenSuse y otras que usen kde 4.6 o superios la opción se encuentra en “Preferencias del sistema” -> “Información Personal”.

En la lista de recursos vamos a “Contactos”, veremos que ya hay una lista de contactos pero es un archivo, primero agreguemos una nueva con el boton agregar al lado de la lista de contactos, seleccionamos una “Libreta de contactos de Akonadi” , en el titulo dira “akonadi-resource” a eso le podemos cambiar el nombre, luego en la lista de fuentes abajo veremos que esta marcado un archivo, lo seleccionamos y le damos click al boton “Manage Address Book Sources”, ahi aparecera el archivo local que ya teníamos, antes de eliminarlo agregamos otro, damos click en “Add” y en la lista buscamos “Recurso Google Contacts de Akonadi”, lo seleccionamos e ingresamos nuestros datos de la cuenta de google (se guardarán encriptados en la cartera de KDE), luego sincronizamos y si el icono del recurso se pone en verde nuestros contactos ya estan agregados, salimos del díalogo, eliminamos el archivo normal de akonadi y aplicamos los cambios. Cuando abran kmail y escriban un correo nuevo este ya tendrá las direcciones que alguna ves hemos usado en gmail y además podremos agregar nuevas desde kmail, repetir los pasos para el calendario, pruebenlo y vean si funciona correctamente para ustedes

Probado en Debian Wheezy con KDE 4.6.5

Servidor FTP para webmasters

Vamos con un procedimiento práctico, un webmaster hace sus páginas, arma el proyecto, diseña la página, etc. Pero nada de lo que hacen lo van a usar en local, sino en un VPS, un servidor web en otro lugar, por lo que se debe tener una manera para subir los sitios al lugar donde deben estar, esa es la labor de los sysadmin, en ocasiones se les puede dar un usuario en el sistema, pero quizás el webmaster no sea muy letrado en usar herramientas de línea de comando (como ssh), así que debemos darle una herramienta más accesible.

FTP: o Protocolo de Transferencia de Archivos es una forma ancestral para enviar archivos entre una maquina y otra, pero muy efectiva, la mayoría de los webmasters son familiares con los clientes (filezilla o los exploradores de archivos) así que ya sabiendo esto debes asegurarte de algunas cosas:

1- Que el webmaster solo pueda ingresar a la carpeta que contiene el sitio web
2- Que esa carpeta tenga permisos de escritura
3- Que el usuario con el que ingresará el webmaster no tenga shell (osea no pueda ejecutar comandos a parte del ftp), claro a menos que tambien quieras habilitar ssh.

Empezamos, obviaremos el servidor web en este momento ya que no le compete a este post, primero instalaremos con aptitude nuestro servidor FTP, en este caso será vsftpd, muy recomendado por su seguridad y soporta SSL (en caso que seamos paranoicos o necesitemos realmente que pasen encriptadas las transferencias).

aptitude install vsftpd

Ahora comenzamos a construir la configuración, abrimos con nuestro editor favorito, al ser un servidor lo más seguro es que no tenga modo gráfico, asi que usaremos un editor de texto, como nano o vim (dependiendo de con cual prefieras trabajar).

vim /etc/vsftpd.conf

Y habilitamos lo siguiente:

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022

La línea listen=YES hace que el servidor acepte peticiones remotas, anonymus_enable lo desactivamos para que no puedan loguearse anonimos (usuarios sin contraseña) al ftp, local_enable sirve para que los usuarios del sistema sean los que se logueen en el ftp, write_enable le permite al usuario escribir en la carpeta y local_umask nos permite cambiar el acceso que se tendrá a los archivos, por ejemplo escribir y modificar pero no borrar, ahora al final del archivo debemos colocar lo siguiente:

local_root=/var/www/web

Bueno con esto le decimos al servidor que el usuario entrará directamente a /var/www donde normalmente se guardan las páginas web en los servidores y le damos un subdirectorio llamado “web” al que le daremos permisos de escritura luego, ahora para que no pueda ser posible ingresar a otros directorios del sistema hacemos esto:

chroot_local_user

Con esto el usuario tendrá como directorio por defecto a /var/www y solamente ese directorio.

Ahora creamos al usuario, si queremos que no tenga otro acceso que el de ftp entonces le deshabilitamos el shell (este paso se puede omitir si le daremos ademas ssh o si no lo creen necesario):

adduser -s /bin/false wemaster

Llenamos los datos y la contraseña del sistema será la contraseña del ftp.

Ahora le damos a “wemaster” la posesión de /var/www/web:

chown wemaster:wemaster /var/www/web

Y en el servidor Web redirigimos el “Document Root” a /var/www/web (o simplemente le dan los permisos a /var/www directamente), ahora a probar con un cliente ftp como filezilla, dolphin, nautilus o incluso firefox (solo ver, no escritura), usando como login “wemaster” y la password que le dimos a adduser al principio.

Fuente

Montando Reportbug

Una de las cosas por las que la comunidad del software libre es conocida es por la importancia del trabajo comunitario, es decir si los usuarios creen que los developers o los que manejan cierto software la estan cagando reportan la queja, ya sea una
vulnerabilidad, un programa que se truena (crash) o simplemente quieren dar una sugerencia de alguna caracteristica que podría ser útil a otros usuarios (o al que lo reporto).

En la comunidad debian usamos un programa que sirve para eso, para reportar problemas en nuestra distro y ayudar a hacerla mas estable, este programa se llama Reporbug.

Este busca la información del paquete que presento problema o al que le pedimos caracteristicas nuevas para tener un reporte detallado y sobre todo “útil y legible para el desarrollador”.

Lo que necesitamos:

-Un sistema debian o derivado
-Reportbug (instalado por default en la mayoría)
-un MTA o servidor de correo (msmtp solo configuracion de usuario)(opcional)

Configurando reportbug

a) inicio, nivel de experiencia en Debian
Primero buscamos una aplicacion que nos esta dando problemas, luego damos el comando reportbug en la consola (para gnome ya hay un reportbug gráfico, para los que usan squeeze esta reportbug-ng también gráfico):

$ reportbug

Y nos aparecerá este mensaje:

Welcome to reportbug! Since it looks like this is the first time you have used reportbug,
we are configuring its behavior. These settings will be saved to the file "/home/user/.reportbugrc",
which you will be free to edit further.
Please choose the default operating mode for reportbug.

1 novice Offer simple prompts, bypassing technical questions.

2 standard Offer more extensive prompts, including asking about things that a
 moderately sophisticated user would be expected to know about Debian.

3 advanced Like standard, but assumes you know a bit more about Debian, including "incoming".

4 expert Bypass most handholding measures and preliminary triage routines.
This mode should not be used by people unfamiliar with Debian's policies and operating procedures.

Select mode: [novice]

Aqui dice:
“Bienvenido a reportbug!, Como parece ser esta la primera vez que usas reportbug configuraremos primero su comportamiento. Estas opciones se guardaran en /home/user/.reportbugrc, el cual tienes toda la libertad de modificar despues, elige el comportamiento predeterminado de operación para reportbug:

1 novato Ofrece preguntas simples omitiendo lo mas técnico

2 estandar Ofrece preguntas un poco mas extensas, incluyendo cosas sofisticadas, se espera que el usuario sepa sobre Debian

3 avanzado igual que estandar, pero asume que sabes un poco mas sobre Debian

4 experto Omite la mayoría de las medidas y las rutinas preliminares de pregunta. Este modo no debe ser usado por gente no familiarizada con las politicas y procedimientos de Debian”

Aqui elegiremos novato (si soy novato también) dando enter, si tenemos gnome nos preguntará si queremos interfaz gráfica o interfaz de texto, no es la gran diferencia, pero si te sientes mas cómodo/a con un entorno gráfico elígelo.

b) ¿Tienes acceso a internet?
Despues aparecerá la siguiente pregunta:

Will reportbug often have direct Internet access? (You should answer yes to this question unless you know what you are doing and
plan to check whether duplicate reports have been filed via some other channel.) [Y|n|q|?]?

Aqui dice: “¿Tendrá reportbug acceso directo a internet? (Deberías decir que si a esta pregunta, a menos que sepas lo que haces y planeas revisar si hay reportes duplicados por otro medio) “, si tienes internet lo mejor será poner si (enter), en caso de que no tengas internet (y este how-to lo has impreso) responde que no (n).

c) Identidad
Luego preguntará con que nombre pondrás el reporte de bug (tu nombre completo), será para ser reconocido entre la comunidad Debian (y para que un developer cerca de ti queme tu casa por darle mas trabajo XD).

Luego preguntará tu correo electrónico (sera de conocimiento público asi que buscate uno con buen filtro anti-spam).

d) ¿Has configurado el servidor de correo? Preguntará si tienen instalado un MTA, entro en modo cultural aqui:

(tuxwarrior se pone lentes de fondo de botella y se peina el pelo con la lengua de una vaca y 10 litros de gel)


MTA o Mail Transfer Agent es lo que conocemos todos como un “Servidor de correo”, o el software encargado de enviar o “transferir” correos hacia otras computadoras a traves de la red (ver definicion en Wikipedia: MTA), por favor no confundir con esos programas que usamos para enviar flames a listas de correo o cadenas a nuestros familiares XD, el thunderbird, evolution y todos esos son clientes de correo o MUA (Mail User Agent) tampoco ponemos aqui a los servicios de WebMail como gmail y hotmail.

Saliendo del modo cultural si tenemos instalado y configurado un servidor de correos el bug se enviará directo desde el reportbug, la mayoría de usuarios normales no tiene uno configurado (aunque si instalado), asi que responderán que no, (al final de este post pongo como montar un MTA sencillo solo para un usuario).

e) Final, Proxy y última indicación
Preguntará si se tiene un proxy en la red, en caso de existir hay que poner la dirección o la IP de esta forma: “http://192.168.1.1:puerto/” cambiando la IP por el dominio o la IP de tu proxy y el puerto por el puerto default para el proxy, si no hay proxy entonces dejar en blanco.

Ahora ya terminamos con la configuración inicial de reportbug, ahora a llenar un reporte:

Reportando un bug

Primero hay que saber que es un bug por definicion: “Un defecto de software (computer bug en inglés), es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Los errores pueden suceder en cualquier etapa de la creación de software” fuente Wikipedia:bug.

Antes de llenar nuestro reporte recomiendo leer las buenas prácticas para enviar reportes de bug efectivos aqui

Encuentro un bug
Si alguna aplicación se porta extraño, se traba, usa demasiada memoria para algo muy simple o sin explicacion alguna “Truena“.

Entonces llenamos un reporte de bug de esta manera:

$ reportbug

Llenando el bug
Primero nos preguntará el nombre del paquete afectado, para saber como se llama el paquete del cual viene nuestra aplicacion problemática usamos aptitude:

$ aptitude search amarok
i amarok - easy to use media player based on the KDE Platform

en este caso vemos que el paquete al que pertenece amarok se llama “amarok”, algunos otros son mas engañosos como “epiphany-browser” ya que solo “epiphany” es el paquete de un juego que se llama igual al navegador.
El paquete debe estar instalado, no debemos mandar bugs sobre software que no tenemos.

Luego saldrá una lista de bugs que ya se enviaron sobre ese paquete (pueden ser muchísimos), por favor revisen todos los que mencionen algo sobre el mismo problema si el bug ya lo envió otra persona entonces solo revisemos si tenemos datos para aportar al bug, pero no lo enviemos de nuevo, es redundante y una pérdida de tiempo enviar bugs duplicados.

Si el bug no existe o no se ha reportado entonces nosotros debemos reportarlo y aportar la mayor cantidad de información útil sobre el bug en ingles (la mayoría de los developers son angloparlantes).

Luego nos pedirá una descripción sencilla del bug.

Luego determinamos la gravedad del bug, que puede ser:
1-Critical: hace que otros programas no relacionado en el sistema (o el propio sistema) dejen de funcionar o lo hagan erroneamente

2-Grave: hace al paquete inservible para la mayoría de usuarios o causa pérdida de datos, o inserta un hoyo de seguridad que permite el acceso a las cuentas de usuarios que usen el paquete.

3-Serious: Viola severamente alguna convención de las politicas de Debian sobre paquetes o la libertad de estos (solo developers y mantainers deben usar este).

4-Important: El bug tiene un impacto importante en la usabilidad del paquete, pero no lo hace completamente inservible para todos los usuarios

5-Does not build: No compila (developers o gente que compila las fuentes de debian para cualquier propósito)

6-normal: como el nombre lo dice es lo que normalmente encontraremos, una opcion, acción o entrada hara que el programa truene, sin que el programa sea totalmente inservible

7-minor: Fallos cosméticos, como por ejemplo una palabra mal escrita, ayuda no útil, un boton no funciona o se porta extraño.

8- wishlist: sugerencias o peticiones de carácteristicas nuevas (posibles y útiles).

Segun esta lista elegimos la severidad, luego nos abre un editor (generalmente nano o vi) para escribir la información del bug, debajo de donde se menciona la severidad que elegimos hay un espacio en blanco donde podemos poner la descripción del bug y las pruebas que hicimos para corroborar que es un problema en el programa y no otra cosa como por ejemplo una mala configuración.

Para finalizar guardamos el bug (control+x nano 😡 vi) luego nos preguntara si deseamos enviar el bug, aqui respondemos si (enter) si tenemos un MTA configurado, en este caso el bug será enviado de inmediato al Debian BTS para su publicación y revisión de parte del responsable del paquete, si no tenemos MTA (la mayoría) damos no (n) y nos dara la ruta donde el bug estara guardado (/tmp/reportbug-archivo), abrimos esta ruta con un editor y copiamos su contenido, luego lo pegamos en un correo nuevo desde nuestro MUA (thunderbird, evolution, claws, mutt <—-si tienes mutt configurado TIENES UN MTA) a la dirección submit@bugs.debian.org o desde nuestro webmail (preferentemente gmail o alguno que no envíe correo en HTML por default).

Montando MSMTP como MTA

Para esta tarea necesitamos una cuenta que soporte envío SMTP, usare gmail para ejemplo, primero instalamos msmtp:

#apt-get install msmtp

Luego como usuario creamos un archivo llamado ~/.msmtprc, y llenamos de la siguiente manera:

account default
host smtp.gmail.com
port 465
auth on
user usuario
password passguord
tls on
tls_starttls off
tls_certcheck off
from usuario@gmail.com

Cambia usuario por tu user de gmail y passguord por la contraseña, luego prueba con este comando si puedes enviar correo:

$echo "una prueba esto es" | msmtp -d direccion@correo.com

Cambia la direccion de correo por una dirección que puedas revisar correo, si recibes un correo sin asunto proveniente de tu cuenta de gmail entonces funciona (puedes usar mutt con este MTA sencillo).

Este MTA solo cumple la funcion de enviar correo de tu usuario hacia la cuenta de gmail asi que no puede manejar recipientes POP3 o IMAP como los servidores completos (postfix, exim, sendmail).

Espero que les haya funcionado y a enviar bugs

mejoremos juntos el software libre aunque no podamos programar

Dr. Tuxwarrior: predicciones para 2010.

Mwuajajajajaajaja (risa maligna) este día Dr. tuxwarrior paso a modo “astróloco” y dara las predicciones para el 2010:

1) El software libre sigue aumentando su popularidad, mientras que el software privativo gana menos pisto mientras mas gente lo piratee al ver que no vale la pena pagar por el, o empiece a usar software libre.

2) Chilo será victima de un atentado: será ametrallado con un arma blanca (un vergo de huevos)

3) TCheces dira en sus notifieros que a un año de estar Mauricio Funes en el poder no ha arreglado ni mierda de lo que jodio el otro partido en 20 años.

4) Habra 3 huelgas en la UES: 1 por despidos, otra la tradicional de principios de año y la última para conseguir local para el “super chupe underground”.

5) Todo sera mas caro y la gente ganara menos (eso no es prediccion es afirmacion)

6) Las enfermedades mentales subiran (cada ves me dan mas ganas de estudiar psicología realmente), se prevee que abran otro hospital psiquiatrico en soyapango bautizado como arkham.

7) Se hara una teleton para pagarle las vacaciones en mariona a flux

8) Muy borrosa pero veo el posible enfrentamiento entre tsundere y yandere.

9) El siguiente Debian Developer de .sv sera Lloyd (O.o no me pregunten, eso dicen las piedras de la rivera sagrada del acelhuate).

10) El mundial lo ganara cualquiera que no sea brazil (Inserte puteada en brasileño aqui).

Si crees que tienes mas predicciones para el 2010 postealas en tu blog, tienes hasta el 6 de enero :p. (no quiero crear un meme aunque no lo parezca :p)

Un tributo a las predicciones del 2010 en  Sinergia Sin Control

Programas de 32 bits no disponibles en AMD64

Todos los que hemos hecho el salto a 64 bits en linux nos encontramos con este problema (el mas grande de todos diría yo), estamos acostumbrados a conseguir todo (o casi todo) nuestro software de los repositorios e incluso algunos programas no-libres que estamos a veces obligados a conseguir por culpa de los amigos que tenemos o la empresa en la que laboramos que lo #exige, o incluso los que nos gusta jugar con consolas que ya no estan vigentes (emulacion) a veces no encontramos disponible el emulador al que estamos acostumbrados, aqui pongo una guía para instalar 2 aplicaciones no disponibles para AMD64 en debian:

1-ZSNES: Este es para mi el mejor emulador de SNES existente, no solo es potente, rápido y muy similar a lo que era la propia consola, ademas de todo es libre, el problema es que por alguna razon que no conozco no es posible compilarlo para 64 bits (si lo intente y varias veces), por lo que no existe un deb para AMD64, lo que hice para hacerlo funcionar fue lo siguiente:

* Bajar la version de 32 bits de packages.debian.org, les recomiendo que bajen la versión disponible para su rama de distro (stable, testing o unstable), y lo instalan de esta manera:

dpkg -i --force-architecture zsnes_****_i386.deb

Cambien la censura de asteriscos por la version que bajaron, luego bajen la única dependencia (que yo necesité) que necesita en 32 bits para funcionar, igual que con el emulador bajen la version de 32 bits de libao2, pero en lugar de instalarla con dpkg (por que puede reemplazar la version para 64 bits creando un error enorme en el sistema) la descomprimimos con (ark en KDE, fileroller en Gnome, Xarchiver en XFCE y LXDE):

ar -x libao***i386.deb

Y luego descomprimir el archivo “data” dentro de la resultante:

tar -xvf data.tar.gz 

entramos a usr/lib (dentro de la carpeta data, no en el sistema) y copiamos todo el contenido hacia /usr/lib32/ (esto si en el sistema):

cp -r * /usr/lib32/

ADVERTENCIA: no lo copien a /usr/lib o /usr/lib64, eso hara ESTRAGOS en el sistema.

Una vez listo damos en la consola el comando:

zsnes

Y veremos la pantalla del emulador listo para jugar \o/.

2- skype

Este es EVIL, por obligacion (unos primos en el norte que no conocen linux) tengo que usar este ya que es la unica forma de hacer una videoconferencia decente con gente que odia el mazinger, bueno para instalar este adefesio en AMD64 es necesaria una enorme cantidad de dependencias, skype lo instalamos igual como zsnes (solo que ese lo bajan de la página de la empresa skype no de debian), y lo instalan asi:

dpkg -i --force-architecture skype******.deb

Las dependencias son las siguientes, (bajar todas de packages.debian.org):

-libqt4-dbus
-libqt4-network
-libqtqui4
-libqtcore4
-libqt4-xml

Hagan el proceso que describí anteriormente para libao y skype funcionara en AMD64

Instalar los escritorios grandes sin la basura

Si eres un usuario GNU/linux desde hace algun tiempo te habras dado cuenta que algunos (en ocasiones muchos) programas que se instalaron automáticamente con tu distribución no los utilizas o se abren en lugar de los que tu prefieres por ser los “default” del entorno (ej: noatun en kde, totem en gnome), pero el mayor problema lo constituye el intentar desinstalar solo el (o los) programa(s) que nos hace estorbo o tenemos de adorno se va todo el escritorio y sus dependencias, como arreglar eso?

Pues la solución es instalar solamente el “CORE” del entorno de escritorio, la forma debian (y ubuntu) sería de esta manera:

apt-get install gnome-core

en caso de gnome

apt-get install kde-core

en caso de kde 3

apt-get install kde-minimal

en caso de kde 4

Espero que les sea de ayuda, pueden despedirse de los estorboware :p