NOTAS DE LOS ORDENATAS DE GARRAXI TRAS EL UPGRADE A ETCH: SISTEMA: ======== AUTOMONTAJE DE UNIDADES: Posibiliades encontradas: - Submount: es lo que usa(ba) Suse. Parece muerto. - usbmount: automatically mount and unmount USB mass storage devices (no requiere hal ni dbus). Se trataria de un sistema lightweight independiente del desktop environment. Pero no hace que aparezca el icono del usb en el escritorio cuando se enchufa (Users which would like an icon to appear when an USB device is plugged in should use the pmount and hal packages instead). - El automount del kernel: Hay mucha info de como configurarlo y en debian viene de serie en el kernel y solo necesita un demonio (el del paquete autofs). Le encuentro la pega de que los directorios de montaje de las unidades no deben de existir, autofs los creara cuando se intente acceder a la unidad, en el sitio especificado en la config. De esta manera, hay que crear enlaces simbolicos (por ejemplo) en un dir, para que apunten al dir que se creara cuando se monte la unidad. Asi cuando listas el dir donde estan los enlaces simbolicos, ya se montan las unidades (y al diskette le cuesta un rato), luego cuando accedes al diskete hace la misma operacion (otro rato)... Ademas, es un poco lio esto de que el dir no exista pero luego aparezca... - Supermount: es lo que usa(ba) Mandriva, y el que teniamos en uso en Garraxi con el kernel 2.4 y Sarge. Para probar supermount hay que recompilar el kernel, asi que bajo el paquete linux-sources de Etch (es un 2.6.18) y el parche para el 2.6.18 de supermount desde sourceforuge. Tras instalar el kernel parcheado, udev detecta la memoria usb cuando se enchufa y se cargan los modulos (mass-storage y tal) necesarios. Despues el supermount funciona perfectamente tanto para el usb, como para cds y disketes. El problema que tiene supermount es que no es dinamico, esto es que requiere de entradas en fstab (estaticas) para funcionar. De esta manera, cuando quieres enchufar un nuevo dispositivo de caracteristicas diferentes a los probados hasta entonces necesitas una nueva entrada en fstab con las caracteristicas adecuadas. Asi por ejemplo probandolo con un disco duro externo usb, formateado en ntfs, no podia hacerlo porque, aun teniendo la entrada adecuada en fstab para hacerlo, estaba con sistema de ficheros vfat. Ademas cambiando esta entrada a sistema de ficheros auto, esto tampoco funcionaba con supermount y ntfs (creo que es un fallo de supermount, o de fuse y su interaccion con el, ver abajo). Este problema de los miltiples aparatos a enchufar es lo que trata de resolver (con bastante exito) los sistemas basados en dbus-hal. - udev-dbus-hal-pmount (ver tambien ivman, hay paquete debian): es lo que parece que estan utilizando todas las distros, pero es mas rollo configurar tanto cacharro y ademas hay que tener al menos 3 demonios corriendo a la vez: udev (que siempre estar, porque lo necesita el kernel 2.6), dbus y hal (e ivman si se usa automontaje...). Pero sin embargo es el unico que se adapta al vuelo a nuevos cachivaches enchufados por usb. Lo usaremos con xfce (ver mas adelante). SOPORTE PARA ESCRITURA EN SYSTEMAS DE FICHEROS NTFS (Windows XP): Etch no trae soporte para escribir en particiones y aparatos con filesystem ntfs (el de windoze XP), dado que no tiene los paquetes de ntfs-3g. Para conseguirlo hay que instalar los paquetes de fuse > 2.6 y de ntfs-3g, y para conseguir estos paquetes se pueden compilar desde los paquetes fuente de SID, o buscar backports. Pasos para conseguirlo: - Compilar e instalar los paquetes de fuse >= 2.6 (libfuse2_2.6.3-4_i386.deb fuse-utils_2.6.3-4_i386.deb). - Añadir el user al grupo fuse: 'sudo adduser garraxi fuse'. - Compilar e instalar los paquetes de ntfs-3g (libntfs-3g0_1.328-2_i386.deb y ntfs-3g_1.328-2_i386.deb). - Compilar el kernel con soporte para "Filesystem in Userspace" (FUSE), como modulo. Quito ademas el soporte para NTFS del kernel, dado que ya no es necesario. - Si se usa fstab, configurarlo para montar los dispositivos ntfs con lineas como la siguiente: /dev/sda4 /zip auto rw,users,noauto,noatime,sync,uid=1000,gid=1000,umask=033,locale=eu_ES@euro 0 0 uid=1000,gid=1000: los archivos pertenecen al user. umask=033: los archivos tienen permisos rwxr--r-- locale=eu_ES@euro: para que se vean los acentos y tal en los nombres de archivos Pero en los puntos de montaje de fstab preparados para montar unidades externo que no sabemos si vienen formateadas como vfat o como ntfs pondriamos como tipo de sistema de ficheros "auto" para que detecte que tipo de fs tiene. Pero si detecta un fs ntfs, el sistema automatico lo monta con el driver ntfs del kernel y no con el ntfs-3g. Para que utilicen ntfs-3g, es necesario hacer un enlace simbolico desde /sbin/mount.ntfs que apunte a /usr/bin/ntfs-3g. Sin embargo, supermount para montar unidades formateadas en ntfs, el filesystem "auto" chequea (en ese orden) los siguientes tipos de filesystem: "udf", "iso9660", "ext2", "vfat", "msdos". Ademas, ninguna solucion buscada funciona para "supermontar" ntfs. Da la impresion de que el problema es que falta soporte para ntfs, o para ntfs-3g en supermount, o que hay problemas entre fuse y supermount??. Esto nos lleva a la necesidad de utilizar un sistema con dbus-hal para el montaje de unidades extraibles. UTILIZACION DE XFC4 COMO SISTEMA DE ESCRITORIO: Xfce es un entorno e escritorio muy ligero, pero que se adapta a las necesidades de gestion de dispositivos actuales, por lo que soluciona los problemas encontrados antes. Para instalarlo, instalo los paquetes debian: xfce4 (metapackage que instala todos los importantes) y xfce4-cpugraph-plugin (un plugin para mostrar la carga de la CPU, como en icewm). Tambien el conjunto de iconos tango-icon-theme. Para el sistema de montaje de unidades extraible instalo los paquetes hal, dbus y pmount. Xfce4 se inicia arrancando el programa startxfce4. El inicio se puede customizar copiando /etc/xdg/xfce4/xinitrc en ~/.config/xfce4/xinitrc y modificandolo. Para arrancarlo pongo en ~/.xinitrc que se arranque el programa startxfce4. Despues hago que solo haya una barra de tareas de xfce, y que tenga el menu de xfce, el icono para ir al escritorio, el gestor de ventanas abiertas, el medidor de la cpu y el reloj. Por defecto se inicia junto con xfce4 el programilla 'ssh-agent' que sirve para utilizar keys privadas para autentificarse si se intenta uno logearse en otra maquina despues de iniciada la sesion X. Para evitar que se carge en el inicio si no se utiliza comentar las lineas 62-67 del xinitrc de xfce. Para usar xfce con medios extraibles, es necesario tener en marcha dbus y hal (pmount ya no es necesario si se usa thunar >= 0.8.0, ver abajo). Teniendo los dos primeros paquetes instalados, al arrancar el demonio dbus, se arranca despues el hald (asi que para evitar su arranque vale con 'update-rc.d -f dbus remove', y para recuperarlos con 'dpkg-reconfugure dbus'). Tras instalar pmount, el README.Debian dice que añadas los users al grupo plugdev ('sudo adduser plugdev'). Ademas, para que pmount funcione, el man dice que el device enchufado no debe de aparecer en /etc/fstab, asi que hay que quitar de el todos los medios removibles. Ademas, parece que tambien hay que poner en fstab la siguiente linea (que encuentro en googlegroups): none /sys sysfs defaults 0 0 o si no instalar el paquete sysfsutils (lo instalo tambien porsia). Pero tras probar mucho el funcionamiento con medios extraibles en el Xfce que trae Debian/Etch, veo que da muchos problemas, por lo que instalo la nueva version de Thunar (0.8.0) que hay en Debian/SID y que puede funcionar sin tener que actualizar el resto de Xfce. Para ello tengo que compilar e instalar los siguientes paquetes debian de fuentes: exo (0.3.2-4) (al que añado soporte para libnotify, que el paquete oficial debian de sid no trae), thunar (0.8.0-3), thunar-volman (0.1.2-1), thunar-media-tags-plugin (0.1.2-1), thunar-archive-plugin (0.2.4-1); y el paquete source notification-daemon-xfce-0.3.7 bajado de: http://goodies.xfce.org/projects/applications/notification-daemon-xfce. La novedad de esta version es que el propio thunar se encarga del montaje de los medios (sin necesitar pmount) y su manejo es configurable a traves de thunar-volman. Con estos paquetes y teniendo los paquetes 'dbus' y 'hal' instalados, y los demonios dbus-daemon y hald arrancados, al enchufar la memoria usb (o meter un cdrom), estos son reconocidos, se añade el icono en el escritorio (y en la barra lateral de thunar), y se montan y se abre una ventana de thunar en el directorio de montaje. Esta caracteristica es configurable con el thunar-volman, y la configuracion se hace a traves de la ficha avanzada de las prefs de thunar, que da paso a la configuracion de thunar-volman. Tambien hay (en el escritorio y en la barra lateral de thunar), un icono del floppy y su montaje y desmontaje funciona bien a traves de el. Esto funciona bien tambien con devices formateados en ntfs, atraves de ntfs-3g. Al montar se crea un dir para el device enchufado en el dir /media y ahi se monta su contenido. Cuando se desmonta y se retira el device, se borra ese dir. Con los cds tambien funciona, ademas si es un cd de datos, una vez reconocido se monta y abre thunar para poder explorarlo, y si es de musica no comprimida se abre el ripperX para rippearlo (configurado). Para desenchufar correctamente el aparato hay que desmontarlo, y para mejorar el aprendizaje del user se podria usar un notification-daemon que informe al user cuando se ha desmontado el aparato y que ya puede desenchufarlo. Ver: file:///usr/share/doc/thunar/html//es/using-removable-media.html. Para ello es necesario que libexo (libreria de thunar) este compilada con soporte para libnotify (instalando libnotify-dev antes de compilar). Como notification-daemon se podria utilizar el paquete del mismo nombre de debian (que no he conseguido que funionara y no debe de estar instalado a la vez que el otro), o tambien se puede compilar-instalar el notification-daemon-xfce que es lo que hago. Una vez hecho esto, cuando se acaba de usar un medio extraible se desmonta (click dcho - desmontatu, hay que indicar al user que lo tiene que hacer en la documentacion) y despues sale (casi siempre :-/) una ventanita que informa (en perfecto euskera :-D) de que ya puede retirar el medio. Un bug que tiene Thunar 0.8 (ya informado a Debian) es que no aparece la fecha de los archivos mas antiguos (pone ezezaguna). La solucion que encuentro es exportar LANG=es_ES, antes de arrancar thunar para que la fecha salga en castellano y salga bien. Pero esto no se puede hacer facilmente porque en el arranque de xfce se arranca un '/usr/bin/Thunar --daemon' (lo arranca el xfdesktop o el xfce4-panel, segun la documentacion). Ese daemon parece que hace falta para que al abrir una ventana de thunar con el icono de un medio removible, este se monte automaticamente y arranque thunar. Para solucionarlo pongo al final del xintrc de xfce: que se mate el 'thunar --daemon' (despues de unos segundos para que de tiempo a que este arrancado) y que se vuelva a arrancar con 'export LANG=es_es && Thunar --daemon'. Pero con Thunar 0.9.0 este hack ya no es necesario, dado que esta version trae la posibilidad de configurar el formato de fechas de varias maneras. Por eso tras compilar los paquetes source debian thunar-0.9.0 y exo-0.3.4, elimino lo de arriba de xinitrc de xfce. Tambien se puede pasar de 'xfce4-session', que es el programilla que se ejecuta al inicio de xfce y sirve para guardar el estado del desktop con los programas que hay abiertos, asi como proveer el dialogo de cerrar, rebotar, apagar. Para quitarlo del inicio de xfce, comentar en ~/.config/xfce4/xinitrc las lineas 78-90. Comentar tambien mas adelante la linea de orange, para que no aparezca el calendario si esta instalado. Para despues apagar/reiniciar el ordenata cambiar el menu y poner la interfaz en Xdialog para apagar el ordenata. Tambien es bueno vaciar la cache de datos de xfce4-session, que esta en ~/.cache/sessions (borrar todos los archivos del dir) para que no de problemas despues. Sin embargo esto no parece poder hacerse cuando intalas Thunar 0.9.0, por lo que deshago los cambios y vuelvo a usar xfce4-session /si no, no arrancaban las X). El applet de mostrar las ventanas abiertas agrupa las ventanas de la misma aplicacion por defecto, en vez de mostrarlas en el orden que se han abierto. Se puede cambiar en las propiedades del applet, pero no funciona bien, creo (mirarlo mas). Añadir iconos al escritorio desde la entrade del menu del escritorio (boton dcho en un icono del escritorio, idazmaia, sortu abiarazlea) no es posible, y creo que es debido a que no utilizo utf8. Se pueden poner iconos de aplicaciones creando en ~/Desktop un archivo de texto, con nombre comando.desktop, y con el siguiente contenido (ejemplo): [Desktop Entry] Comment= Comment[eu]= Encoding=UTF-8 Exec=emelfm GenericName=Emelfm GenericName[eu]=Emelfm Icon=/usr/share/pixmaps/icon_dirparent.xpm MimeType= Name=Emelfm Name[eu]=Emelfm Path= StartupNotify=true Terminal=false TerminalOptions= Type=Application Añado tambien entradas el menu "Bidali..." de Thunar, añadiendo el dir ~/.local/share/Thunar/sendto y poniendo ahi archivos de texto como el siguiente (llamado x-xmms.desktop): [Desktop Entry] Version=1.0 Encoding=UTF-8 Type=Application Name=Encolar en Xmms Exec=xmms -e %F Icon=applications-multimedia MimeType=audio/x-ogg;audio/x-speex;application/x-ogg;audio/x-aiff;audio/aiff;aud io/x-pn-aiff;audio/basic;audio/x-basic;audio/x-pn-au;audio/x-wav;audio/wav;audio /x-pn-wav;audio/x-pn-windows-acm;audio/x-m4a;audio/x-8svx;audio/8svx;audio/x-16s v;audio/168sv;audio/mpeg2;audio/x-mpeg2;audio/mpeg3;audio/x-mpeg3;audio/mpeg;aud io/x-mpeg;audio/x-mpegurl;audio/mpegurl;audio/mp3;audio/x-mp3;application/x-flac ; Pillado de http://thunar.xfce.org/pwiki/documentation/sendto_menu Otros paquetes interesantes para funcionar junto a Thunar son: thunar-archive-plugin (añade al menu contextual la opcion de crear y desempaquetar archivos comprimidos) y thunar-media-tags-plugin (permite visualizar/cambiar los tags de los archivos de musica y tambien una funcion de renombrado masivo de archivos con los tags). Tambien instalo catfish, que es un buscador de archivos en python-gtk2 y que esta bastante integrado con Thunar. Pongo una accion personalizada de thunar (Menu Editatu/Ekintza Personalizatuak) para que aparezca en el menu contextual cuando se pinche con el boton dcho. en cualquier archivo o directorio. El comando usado es 'catfish --large-icons --fileman=thunar --wrapper=exo-open --method=find --path=%d'. Programa pillado de http://software.twotoasts.de/?page=catfish. Otras ekintzak personalizatuak instaladas (desproteger archivo /home/garraxi/.config/Thunar/uca.xml para añadir mas): - Ireki terminal bat emen: cd %F; mrxvt - Fitxategien tamaina: /usr/local/bin/directory-getsize.sh %F - Data aldatu fitxategiei: /usr/local/bin/touch-gtkdialog.sh %N Xfce tiene modo kiosk que depende de xfce4-session para la parte general del escritorio, y de xfce4-panel para el modo kiosko del panel, ver: file:/usr/share/xfce4/doc/C/xfce4-session.html#xfsm-kiosk-mode, para la session; y file:/usr/share/xfce4/doc/C/xfce4-panel.html#panel-kiosk, para el panel. La configuracion va en /etc/xdg/xfce4/kiosk/kioskrc y necesita utilizar xfce4-session (que no utilizamos) y xfce4-panel. La otra manera para hacer un modo kiosk es hacer que los archivos de config de xfce (y sus principales aplicaciones como thunar) pertenezcan al user "garraxi2" y solo sean leibles por el user "garraxi". Asi que lo primero que hago es configurar completamente xfce y despues cambio los permisos y dueño a los siguintes archivos/directorios: - ~/.config/xfce4/xinitrc: script de inicio de xfce. - ~/.config/Thunar: configs de thunar. - ~/.config/xfce4-session/: configs de xfce4-session. - ~/.config/xfce4/panel/: configuraciones del panel y sus applets. - ~/.config/xfce4/desktop/: configuraciones del menu. - ~/.config/xfce4/mcs_settings/: configuraciones de otras partes del escritorio segun los paquetes que esten instalados. - ~/.config/xfce4/shortcuts/: Configuraciones de los atajos de teclado. - ~/.config/xfce4/xfwm4/: Configuraciones del windowmanager de xfce. - ~/.cache/Thunar/: thunar asocia metadatos de archivos/carpetas ahi. - ~/.cache/sessions/: xfce4-session guarda el estado del escritorio al cerrarlo en ese dir. - ~/.cache/xfce4/: otros estados del desktop (menu e iconos), y el programita de arrancar comandos (sfrun4). - ~/Desktop: iconos de escritorio. Pongo a todos estos directorios permisos tipo rwxr-xr-x y owner garraxi2:garraxi2, y a los archivos de estos directorios permisos tipo rw-r--r--, excepto a ~/.config/xfce4/xinitrc que tiene que ser ejecutable. De esta manera xfce arranca perfectamente (aunque lanza algunos errores a la consola desde la que se arranca, pero el user no los ve) y despues funciona perfectamente, pero da avisos de que no puede modificar cosas (el menu, por ejemplo) por falta de permisos. Otras cosas si que parece permitirlas (mover de sitio los iconos...) pero despues en el siguiente reinicio vuelven a estar en su sitio. Tampoco permite añadir mas iconos, ni guardar ficheros en el escritorio. Xfce tambien guarda algunas configuraciones en otros sitios no documentados. Por ejemplo al decir a un tipo de archivo que se abra con tal aplicacion en Thunar, la configuracion va: ~/.local/share/applications (protegerlo cambiandolo a owned garraxi2). Los enlaces "enviar a" del menu contextual se guardan, como se ha dicho arriba, en ~/.local/share/Thunar/sendto (proteger tambien). Tambien hay alguna configuracion mas en ~/.local/share/xfce4 (no se muy bien de que, dejarlo sin proteger), y la papelera esta en ~/.local/share/Trash (no proteger). Tambien implemento el modo kiosko de xfce para el panel. Para ello creo el archivo /etc/xdg/xfce4/kiosk/kioskrc, con el siguiente contenido, que hace que solo el user garraxi2 pueda modificar cosas (solo es valido lo del panel, dado que no utilizamos la session, pero por si acaso): [xfce4-panel] CustomizePanel=garraxi2 [xfce4-session] CustomizeSplash=garraxi2 CustomizeChooser=garraxi2 CustomizeLogout=garraxi2 CustomizeCompatibility=garraxi2 Shutdown=garraxi2 CustomizeSecurity=garraxi2 Ademas hay que coger todas las settintgs del panel que estan en ~/.config/xfce4/panel/, y copiarlas en /etc/xdg/xfce4/panel/. Asi lo hago, dejando las originales con la extension .ORIG, y el panel que he configurado se arranca pero no se puede modificar. Para el modo kiosko de garraxi hay que quitar tambien las combinaciones de teclas siguientes (que vienen por defecto en xfce): Alt+F2: arranca la caja de correr comandos Ctrl+Alt+Esc: arranca xkill para matar ventanas Ctrl+Alt+delete: llama a xflock4 y este script a xlock y a xscreensaver, que no tenemos instalado, por lo que no hace nada (mejor). Esto se quitaria en el "Settings manager", en Teklatua, pero no se puede porque son configuraciones que vienen por defecto y no estan en la home del usuario. Encuentro el archivo en /usr/share/xfce-mcs-plugins/shortcuts/default.xml y lo edito para quitar las convinaciones anteriores (guardo copia del original en el mismo dir). AUTOLOGIN Y ARRANQUE AUTOMATICO DE LAS X: El sistema para el autologin sin utilizar un daemon como el xdm, se describe en http://www.linuxgazette.net/issue72/chung.html, y el que tenemos en Garaxi es similar. - Crear archivo texto autologingarraxi.c: int main() { execlp( "login", "login", "-f", "garraxi", 0); } - Compilar con 'gcc -o autologingarraxi autologingarraxi.c' - Copiar autologingarraxi a /usr/local/sbin/ y darle permisos de ejecucion. - Editar /etc/inittab y cambiar la primera linea de getty que pone: 1:2345:respawn:/sbin/getty 38400 tty1 por: 1:2345:respawn:/sbin/getty -n -l /usr/local/sbin/autologingarraxi 38400 tty1 Autoarranque de las X tras el login: - Forma 1º. Poner en el archivo /home/garraxi/.bash_profile, en el final: if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then startx fi Esto hace que se arranquen las X automticamente cada vez que un login se realiza en la 1º consola virtual. Sin embargo, los login que se realizan en las demas consolas no arrancan las X automaticamente. Tampoco se vuelven a arrancar las X si se matan, por un fallo o a drede. Ademas deja arrancado en background una shell bash. - Forma 2º. Poner en el archivo /home/garraxi/.bash_profile, en el final: exec xinit >/dev/null Esto hace que se intenten arrancar unas X tras cualquier login del user, de manera que se vuelven a arrancar si estas se caen por cualquier razon. Por eso, no permite ya a ese user logearse en una consola de texto (con Ctrl+Alt+Fx) porque al tratar de arrancar las X tras el login y estar estas ya arrancadas, la consola queda inutilizada. Ademas no deja a bash corriendo en background. Pillado de: http://www.lugli.org.ar/mediawiki/index.php/Linux_Chico, pero ahi lo hacen con la shell dash, con bash funciona igual. Finalmente utilizo este ultimo metodo de arranque de las X para Garraxi, para evitar que si se caen las X por cualquier razon, el user se quede sin saber que hacer. Pero con este sistema hay que cambiar algunas cosas que si no van mal: - Aumentar el tamaño de las fuentes de las aplicaciones gtk2 (editar el archivo ~/.gtkrc-2.0). - La terminal mrxvt no arranca, hay que quitarle la opcion -ls (login shell). SONIDO: ======= JINGLE QUE ANUNCIA REEMISIONES DE PROGRAMAS: Creo un script (jingle-reemisiones.sh) que anunciar la fecha del programa que se va a re-emitir. El script se ejecuta con soma_run cuando se inserta este modulo en una transmision del palinsesto.cfg. Paquetes necesarios: los 3 de ircha (ircha_1.0.1-1_i386.deb, mbrola-es1_3.0.1h_i386.deb y mbrola_3.0.1h_i386.deb), bajados de http://www.telefonica.net/web2/ircha/, y el modulo de soma soma-run_X.X.deb. Tambien podria utilizar festival en vez de ircha, en cuyo caso serian necesarios los paquetes: festival, festlex-cmu, festlex-poslex, festvox-ellpc11k, festvox-kallpc16k, libestools1.2, y ademas una configuracion adecuada del sistema (porque a priori festival tiene menor volumen y peor calidad de "vocalizacion" que ircha). Configuracion de Ircha: El volumen de la voz de ircha se puede modificar en el script /usr/share/ircha/lee.pl, en la variable $volumen que permite cambiar el volumen de la voz entre 1 (bajo) y 8 (fuerte) y esta por defecto a 3. Lo pongo a 8 de manera que el volumen de mplayer y el de ircha es aparentemente el mismo. Ahi tambien se puede cambiar el tempo, la velocidad a la que lee las palabras. Por defecto esta a 0.8 y cuanto mas pequeño es el numero mas rapido lee. A mi me parece que es demasiado rapido y lo pongo a 0.9. El valor 1 se considera el normal, segun un comentario en el script, pero me parece demasiado lento. Para añadir nuevos fonemas e indicarle como se leen, por ejemplo en euskera la tx, ir a /usr/share/ircha/ttp.pl y añadirlos a partir de la linea 230, en la funcion @txt2fonema. El orden en que se introducen NO es arbitrario, segun dice un comentario, de manera que los primeros fonemas de la lista tienen prioridad sobre las mismas letras que aparecen posteriormente. Yo he añadido: ['tx', 'C'], #MARTINTXO: euskal tx = ch (txoko = "choko") Tambien es importante saber que ircha modifica la entonacion en funcion de los puntos de ortografia (ejemplo: punto final de frase) y los acentos. Script: Ademas del script jingle-reemisiones.sh (que es donde estan las ordenes de que sonidos emitir, y que textos "leer"), tambien se necesitan los archivos de sonido: jingle-reemisiones1.ogg, jingle-reemisiones2.ogg y jingle-reemisiones3.ogg. jingle-reemisiones.sh es un script para el modulo de soma soma_run. Esta instalado en /usr/local/bin/jingle-reemisiones.sh, y es llamado por la parrilla de soma (palinsesto) cuando se va a reemitir un programa. Para ello en /etc/somad/palinsesto.cfg hay que poner en la transmision de la reemision del programa: module soma_run.so /usr/local/bin/jingle-reemisiones.sh Nombre_Programa (Notese que solo se pone el nombre del archivo de programa a reemitir, no su extension, de manera que aunque se grabaran unos programas en ogg y otros en mp3, el sistema funcionaria igual) Tambien puede utilizarse para editarlo el somax-editor, ver ayuda de garraxi. El resto de datos se utilizaran los normales de una transmision de reemision (start y stop de 1 minuto de duracion y sofstop activado, para que si existe el programa se emita completo, y si no solo haya un minuto de silencio), excepto que no es necesario definir ningun archivo para emitir (no hay nada en ) porque no es una transmision files sino de un modulo. El script se utilizara tambien (por simplificar) en la "reemision" de programas el dia que se emite "oficialmente" el programa, dado que en ese dia de la semana, si el archivo a reemitir no es uno previamente backupeado (un enlace duro) y su fecha de grabacion es menor de 3 dias, no sonara el jingle que avisa de la reemision, sino que se emitira solo el programa. Esto esta puesto asi para permitir que salgan programas grabados como si se estuvieran haciendo en directo. Para conseguirlo se ha tenido que modificar el "fichero de configuracion de programas" (ver mas adelante), añadiendo a la informacion el dia de la semana en que se emite en directo el programa. El script utiliza el nombre del archivo del programa a reemitir (no precisa poner el path completo, porque ya esta puesto en el script; tampoco la extension, porque la busca en el archivo a emitir) para leer en voz alta el nombre del programa a reemitir y para sacar la fecha original de emision del programa (del tag vorbis|id3 "date", si existe, y si no de la fecha incluida en el nombre del archivo en el caso de los archivos de programas a re-emitir, o en ultima instancia de la fecha de ultimo acceso del archivo, lo cual es menos segura (ver discusion sobre fechas en la siguiente seccion)). El script emite los archivos de audio indicados anteriormente uno detras de otro y con lo que lee en voz alta entre medio, para crear asi el jingle inicial de la reemision. Con esto, la transmision sera completamente del tipo: 1º Jingle que anuncia la reemision, con las siguientes partes: 1.1. Sonido que dice que es una reemision del programa... 1.2. Ircha lee "$Nombre_Programa" 1.3. Sonido que dice "que fue emitido" 1.4. Ircha lee "$Fecha del programa (El [pasado martes] 13 de marzo de 2007)" 1.5. Sonido de cortinilla: "Garraxi Irratia 101.9 FM" 2ª Reemision del programa. Al script de garraxi2 para editar la lista de programas a grabar se le añade la indicacion de que los nombres de programas se escribiran sin espacios entre palabras, sustituyendo los espacios por guiones bajos "_" o poniendo la 1ª letra de cada palabra en mayusculas para diferenciarlas. Esto es asi porque el script de reemisiones tiene una rutina para volver a poner espacios entre palabras al leer el nombre del programa (porque asi pronuncia mejor) y estas son las dos reglas incluidas para ponerlos. Notar que se ha modificar el "fichero de configuracion de programas" (ver mas adelante). Tras realizar la extension de todo el sistema de archivos de programas de radio a gestionarlos por los directorios de emision, consigo que se puedan utilizar diferentes nombres del archivo de programas (que no trenga que ser obligatoriamente el nombre del programa y pueda tener extension ogg o mp3) y que se puedan poner varios archivos de audio para que sean emitidos consecutivamente (en orden alfanumerico). Para ello implemento en el script el que se puedan encontrar varios archivos y se ordenen de manera alfanumerica antes de emitirlos, y que se elija el archivo de mayor peso (que se supone que seria el principal del programa) para elegir de él la fecha de emision a vocalizar. GESTIONAR ARCHIVOS DE PROGRAMAS REPUESTOS CON ENLACES (Y DISCUSION TIPO DE FECHA EN ARCHIVOS): Una mejora al sistema de gestion de los programas antiguos repuestos (realizado por el script de cron "mantenprogramas") es utilizar enlaces simbolicos apuntando al archivo original en el dir de backup, en vez de copiar ese archivo al dir de programas. De esta manera se consumirian menos recursos en el momento de hacer la copia porque solo se haria un enlace, y ademas se usaria menos espacio en disco, al no haber 2 copias del mismo archivo. El problema que tiene esto es que no es posible ponerle a un enlace simbolico la fecha que queramos, al cambiar la fecha del enlace este siempre mantiene la misma fecha (la de su creacion) y lo que se cambia es la fecha del archivo al que el enlace apunta. Esto es un problema, porque lo que hacemos es buscar archivos de programas que tengan mas de 10 dias de antiguedad y son esos archivos los que movemos para que se cambien por otro y no se repitan mas. El asunto para el sistema que se ponga es que tiene que valer para 2 tipos de archivos diferentes, los programas grabados recientemente y que son archivos de sonido normales y los programas repuestos, que en este caso serian enlaces simbolicos. Una solucion es hacer enlaces duros, de modo que si se puede cambiar la fecha del enlace, aunque lo que se hace en realidad es cambiar la fecha en ambos archivos (el enlace y el archivo original) porque son el mismo archivo. Por lo demas el enlace se puede borrar perfectamente (sin que se borre el archivo original), no ocupa mas espacio en disco pues ambos archivos son exactamente el mismo, y el unico problema que da es que el archivo original queda con la fecha cambiada (no importaria demasiado, porque esta fecha esta recogida en el nombre del archivo, y en el tag adecuado si ha sido correctamente grabado). Compruebo si el cambio de fecha (con mtime) que ocurre en el archivo de backup puede afectar a otros scripts. Grabaprograma comprueba la fecha del programa anterior al que se va a grabar, pero que esta todavia en el dir de programas y no en el de backup (todavia no ha podido ser puesto en reemision). De manera que NO AFECTA. Jingle-reemisiones: comprueba la fecha del programa backupeado para leerlo en el jingle. Primero busca esa informacion en el tag vorbis/id3 adecuado y si no aparece lo saca de la fecha de ultima modificacion del archivo, por lo que SI AFECTA, dado que en este caso el jingle leeria una fecha que no es correcta. Posible solucion para jingle-reemisiones: Utilizar fechas (en este orden) 1º tag vorbis/id3, 2º fecha en nombre archivo, 3º fecha de ultimo acceso al fichero (atime). Porque usar atime: Atime: fecha y hora del ultimo acceso (leer o ejecutar el archivo, sin modificarlo). Observese que en un sistema Debian la simple lectura de un archivo provocará una operacion de escritura para actualizar la informacion referente a atime en el nodo. Montando un sistema de archivos con la opcion noatime hará que el sistema omita esta operacion lo que resultara en un acceso de lectura mas rapido. (Obtenido de la Guia de referencia de Debian, 4.5.4 Marcas de tiempo). De esta manera, el atime en mis sistemas (que siempre los monto con la opcion noatime) viene a ser como la fecha de creacion del archivo (puede no serlo siempre). Asi utilizaremos: * atime: como fecha de "creacion" del archivo (fecha original, fija, no cambiarla en ningun script). * mtime: como fecha "modificable" del archivo (fecha cambiable para lo que sea). * ctime: esta fecha se cambia al cambiar los permisos/owner, cosa que se hace cuando un admin "protege" los archivos -> no usar. Asi modifico el script mantenprogramas para que utilice enlaces duros para reponer los programas a reemitir y que al cambiar la fecha del archivo repuesto (en dir programas, pero que con enlace duro tb cambia en dir backup) hacer que solo cambie mtime (no el atime): touch -m -d '4 day ago' (se añade -m). Tambien modifico el script jingle-reemisiones para que utilice en segundo lugar la fecha que viene dentro del nombre del archivo backupeado, para poder vocalizar de cuando es el programa que se reemite. Asi mismo, se pone como tercera opcion (y menos fiable) el leer la fecha del atime. (La primera opcion es leer la fecha del tag vorbis/id3). Para comprobar si el programa que se esta emitiendo (en el dir de programas) es en realidad un enlace duro a un programa en el dir de backup, utilizo stat (stat -c %h "$NOMBREPROG"). El output de esto es 1 para los que no son enlaces duros (solo tienen un enlace) y 2 (o mas) para los que si son enlaces duros (tienen mas de un enlace). Este sistema lo implemento en los script: mantenprogramas, grabaprograma y jingle-reemisiones. GESTION DE LOS ARCHIVOS DE PROGRAMAS EN DIRECTORIOS DE EMISION Que pasa si se graba un programa en mp3, y en la parrilla (palinsesto.cfg) esta como ogg. En este caso no se podria emitir el nuevo programa, aunque estaria ahi. Para evitar el problema, pasamos a utilizar un sitema para reemitir los programas basado en el nombre de la carpeta donde esta alojado, en vez de el actual que busca el archivo por su nombre. Asi, se pone un arbol de carpetas tal que: Biltegi/ |-----> Programas/ |------>Backup | |---->Saltsa-berde | |---->... (todos los subdirs de cada programa donde | se guardan los programas viejos) |------>Emision |---->Saltsa-berde |----->.... (carpetas para todos los programas, en las que estaria solo el programa que se va a emitir, con cualquier nombre de archivo (incluso el mismo que el de backup, con fecha en el nombre). De esta manera, en palinsesto.cfg ponemos que para emitir un programa, en lugar del nombre del archivo de programa que poniamos antes, se emita el contenido de estas ultimas carpetas que cuelgan de Emision (sea cual sea su contenido, con el nombre que tenga el archivo, pero ponemos que se haga en forma no aleatoria, para que se pueda utilizar caracteres alfanumericos para ordenar los archivos a emitir, en el caso de que fueran varios). De esta manera se puede realizar "programas" de manera mucho mas libre, dado que se podrian "componer" de varios archivos emitidos uno tras otro. Sin embargo para la reemision de programas, si utilizamos el modulo soma_run y el script jingle-reemisiones.sh, no es necesario cambiar nada en el palinsesto, porque los cambios ya se han realizado en el script. Otra ventaja que tendria esto vendria para la emision de programas pillados de internet, que no seria necesario cambiarles el nombre, tan solo bajarlos y dejarlos en la carpeta correspondiente con el nombre que traigan. Para ello se modifican los scripts flrec-grabaprograma.sh, mantenprogramas (cron), garraxi2-chown.sh y jingle-reemisiones.sh. En todos ellos se comprueba que se puedan utilizar para gestionar archivos con nombres diferentes del nombre del programa de radio (que estara definido en le directorio y no en el nombre del archivo), que se puedan utilizar espacios en los nombres de archivo (por si acaso) y que puedan existir varios archivos en el dir de Emision (por si se utilizan varios archivos en vez de solo uno, que es lo normal y predeterminado por el script de grabacion). Ademas, pongo que al reponer un archivo de backup para reemitir un programa, no se cambie el nombre, manteniendo el origina que tiene la fecha de grabacion en el nombre del archivo. Con esto se facilita el parseo para sacar la fecha, tal y como hace el jingle-reemisiones.sh para "decir" la fecha, en el caso de que no este puesta como tag vorbis/id3. ARCHIVO DE CONFIGURACION DE PROGRAMAS DE RADIO: Antes teniamos 2 archivos con informacion sobre los programas de radio: uno que saca el nombre del programa en el dialogo de grabar, y otro que indica al script mantenprogramas si ese programa debe de ser "mantenido" (poner un programa aleatorio cuando no hay nada para la reemision...) o no. Cuando me encuentro con la necesidad de guardar la informacion de en que dia de la semana se emite en directo un programa (ver arriba, jingle-reemisiones) implemento un solo archivo donde guardar toda la informacion necesaria sobre los archivos de los programas de radio. El archivo se guarda en /home/garraxi/.programas-radio/config-programas.txt, y en su encabezado hay informacion (como comentarios, con #) sobre el formato en el que se guarda la informacion (nombre de programa, dia y hora de emision en directo, si se va a mantener o no, cuantos dias...). Tambien se informa que este archivo afecta a los siguientes scripts: mantenprogramas (mira en el a ver si hay que mantener o no el programa), flrec-grabaprograma (saca lista de programas a grabar de este fichero), jingle-reemisiones (saca el dia de la semana en que se emite el programa en directo de aqui) y garraxi2-editprog (sirve para editar este fichero). WORKARROUNDS DE LOS PROBLEMAS DE SOMA CON JINGLE-REEMISIONES: Dado que empiezo a utilizar el script jingle-reemisiones para todas las reemisiones de programas (tanto si es reemision de verdad, como si es para que exista un programa en el dia que se emite en directo cuando no se hace, ver arriba), puedo utilizar este script para resolver los problemas que da soma al hacer transmisiones de programas de radio, mientras no se resuelven en el propio programa. Se trata de arreglar el problema de Soma de que si no existe el archivo de programa a tocar en la transmsion de alta prioridad, no suena nada (silencio) hasta que no se acaba la transmision. Tambien arreglar el problema de que si la duracion del programa a reemitir es mas corta que la duracion de la transmision, el programa se repite. Con esto tengo un workarround a 2 de los 3 problemas que reporte sobre la nueva snapshot de Soma. El tercero es que es necesario hacer transmisiones para reemitir el programa de unos 40 minutos para conseguir que este entre en emision incluso en el caso de que justo antes de entrar el programa empiece una cancion larga (por ejemplo de 30 minutos, que seria la mas larga que podemos tener). La solucion en el script, de manera esquematica, son: 1. Para silencio si no hay programa: Si existe archivo-programa => lo toca como ahora (con jingle, si es reemision). Si NO lo encuentra => meter una lista de musica variada (y no jingle). 2. Para la repeticion del programa si es corto: añadir que despues del programa se toque tambien musica variada. PROBLEMA: Al estar la transmision del programa con SoftStop, con un sistema de mandar a mplayer que toque archivos de musica en random no terminaria nunca de tocarlos (soma no termina nunca la transmision y no pasa a la de baja prioridad). Entonces la "solucion" pasa por mandarle una playlist de una duracion similar (un poco mas larga) que la duracion de la transmision (que podemos suponer que el standar son los 40 minutos). Asi elijo una carpeta con musica variada como la de RTL. Miro la duracion de todas las canciones y busco la mas corta (2:35 min). Y para el asunto del silencio si no hay archivo miro cuantas canciones como esa mas corta harian falta para llenar los 40 minutos de transmision standar (aprox 15). Entonces construyo una playlist para mplayer pasando las canciones por randomize lines y cogiendo solo 15 de ellas (con esto seguro que me paso de los 40 minutos, porque solo hay 1 cancion de 2:35, las demas son mas largas). Para el caso de añadir musica a la transmision del programa si lo hacemos de esta misma forma, despues de cada programa (aunque este dure mas de 40 min) siempre sonaria esa musica, y eso no interesa, debe de ser solo un seguro. Como solucion no vale utilizar diferentes invocaciones de mplayer para ello. Entonces la solucion es: - Ver la duracion del programa a reemitir. - Si < 40 min. => añadir musica. Si > 40 min. no hacer nada. - Para añardir musica: ver diferencia entre duracion de programa y 40 min. Ver cuantas canciones de 2:35 min hacen falta para llenar esa diferencia y utilizar el sistema de arriba para _añadir_ ese numero de canciones a la playlist del programa de mplayer. Añado ademas una cancion mas a esta lista como seguro. Hay que tener en cuenta que el programa de radio puede durar en el peor de los casos 39 minutos, en ese caso, la cantidad de canciones que caben en una transmision de 40 minutos es 0, por lo que no funcionaria si no se añade una cancion. Para sacar la duracion del programa pruebo los comandos ogginfo (para ogg) y mp3info (para mp3), pero este ultimo habria que instalarlo. Tambien se puede hacer para los dos tipos de archivos con ffplay (del paquete ffmpeg), pero este tambien habria que instalarlo. Finalmente encuentro la solucion con mplayer usando: mplayer -identify 'file' -ao null -vo null -frames 0. MANTENPROGRAMAS CON TIEMPO DE ESPERA HASTA MANTENER VARIABLE: Objetivo: Que el tiempo de "espera" hasta que se realiza el mantenimiento de un programa pueda ser variable para cada programa. De esta manera podemos tener una configuracion para un programa de "agenda cultural" (por ejemplo) de manera que se emita el viernes y se repita el sabado y el domingo (osea se mantenga sin tocar durante 3 dias) y que se realice el "mantenimiento" del programa al dia 4ª de forma que se guarde en backup pero no se reponga para que si no se graba programa el siguiente viernes no se repita uno viejo. La variable definida "Dias Mantener", indicara por tanto al script mantenprogramas los dias que ha permanecido el archivo de programa en dir Emision hasta que se realiza su mantenimiento. Esquema de la solucion: 1. En archivo de configuracion de programas añadir la configuracion "DiasMantener" para indicar a cada programa cuantos dias se mantiene el archivo en Emision, hasta que se pasa a Backup. Lo normal para los programas seria el actual de 10 dias, de manera que el programa emitido un martes, se reemite el miercoles siguiente (1 dia viejo), el martes siguiente (7 dias viejo) y el miercoles siguiente (8 dias viejo), no mas. 2. Mantenprogramas: A. Mantenimiento: - Se buscan todos los archivos de programas en emision (sin buscar los que son mas viejos de 10 dias como ahora) - Se comprueba que el programa está en archivo config. programas, si no, no se realiza el mantenimiento-reposicion. - Se comprueba si hay que mantener el programa segun el archivo config. programas, si "no", no se realiza el mantenimiento-reposicion. - Se comprueba cuantos dias hay que mantener el programa segun el archivo config. programas, si no pone nada, no se realiza manten.-reposicion. - Se chequea para cada uno a ver cuantos dias viejo es el archivo. - Se compara para cada archivo con su configuracion "DiasMantener". - Si dias_viejo >= DiasMantener, comienza rutina de mantenimiento actual, si no se descarta su mantenimiento-reposicion. B. Reposicion: Concluido el mantenimiento, el script comienza la resposicion del programa (si debe hacerla segun config-programas). El objetivo de la reposicion es lograr que el programa repuesto se mantenga en parrilla siempre 7 dias (1 semana): no mas dias de manera que no se repitan demasiado a menudo los programas antiguos, ni tampoco menos, de manera que no haya que estar "manteniendo" demasiado a menudo el programa. Enconces se "retrasara" la fecha del archivo repuesto por el valor de (la variable - 7). Esto se hace pasando el archivo repuesto por: touch -m -d 'X day ago'. De esta forma, para valores de la variable > 7 el resultado sera retrasar la fecha del archivo (ejemplo: para $V=10 se retrasaran 3 dias (10-7=3)), y para valores < 7 el resultado sera adelantar la fecha del archivo (ejemplo: para $V=5 se adelantaran 2 dias (5-7=-2)). Como efecto colateral, esto trae que se incluya en el fichero de configuracion de programas a todos los programas que se emiten, tanto los que se graban en Garraxi, como los bajados de internet. De esta forma, para que en la lista de programas del cuadro de dialogo de grabarlos no aparezcan los que no se graban (y asi evitar confusiones) añado en el archivo de configuracion la opcion "SeGraba" para indicar si ha de aparecer o no en el dialogo de grabar. MANTENIMIENTO DE CUÑAS: Se ve necesario poner algun tipo de sistema para que se puedan quitar de emision las cuñas ya caducadas (las de convocatorias y asi) sin necesidad de intervencion humana. Para ello se escoge un sistema sencillo que consiste en añadirle al nombre de la cuña la informacion del dia que caducan. Esto se implementa tambien (por comodidad) en el script de cron "mantenprogramas". Para que funcione el nombre de la cuña ha de contener la cadena DD-MM o tambien DD-MM-AA (donde DD es el dia del mes en formato de dos digitos (02, 13...), MM es el mes en formato 2 digitos (01 es enero...), y AA son las dos ultimas cifras del año (08 para 2008)). Si la fecha no se pone en ese formato, el script simplemente ignorara la cuña y habra que quitarla a mano. El script se ejecuta todos los dias a eso de las 6 de la mañana. Por lo tanto la fecha a poner seria la del dia despues al que finaliza la convocatoria, dado que lo que el script hace es buscar la fecha de hoy en el nombre del programa. Las cuñas encontradas no las borra, sino que las mueve al dir de Cuñas Emitidas, por lo que si hay varias copias de la misma cuña posteriormente seria interesante quitar las que sobran. SEGURIDAD: ========== CRUCE DE COPIAS DE SEGURIDAD: En Debian/Etch han eliminado el paquete cpbk que utilizabamos para el cruce de copias de seguiridad. Ademas, la anterior implementacion tenia el problema de que habia que esperar a que se cruzaran las copias para continuar con el arranque del sistema (no pasaba a background). Ademas, en todos los arranques realizaba una serie de trabajos que no siempre eran necesarios. Asi que: - Sustituyo cpbk por mirrordir. El comando utilizado es 'mirrordir --keep-files /dir_origen/ /dir_destino/'. --keep-files: no borra archivos del dir destino. Esto evita que si en el dir de origen se borraran todos los backups, cuando se realizaria el proximo mirrordir, se borrarian tambien todos los backups del dir destino. Ademas, esto lo podemos hacer porque siempre estamos manteniendo el mismo numero de archivos con el mismo nombre, que van cambiando de contenido (con savelog) y de esta manera no hay problema de que se va llenando de archivos viejos el dir de destino. - Elimino el cruce de copias de seguridad en el arranque del auxiliar y lo añado a la tarea de anacron del auxiliar, para que el cruce se realice justo despues de hacer la copia de seguridad del aux. El resto del sistema de copias de seguridad se mantiene como se explica en info-software-garraxi2.txt. De esta manera, los archivos que utilizo para la copia de seguridad son: - /usr/bin/ibackup: script modificado que realiza la copia. - /etc/ibackup.conf (aux/server): configuraciones de ibackup. - /etc/cron.weekly/copiaseg (aux/server): tareas (ana)cron. PROTECCION DE MUSICA, CUÑAS Y PROGRAMAS GRABADOS CON STICKY BYTE: El bit Sticky de permisos para la proteccion de los directorios de musica, al ponerlos como 'drwxrwxrwt garraxi2:garraxi2' permite la escritura en dichos directorios por cualquiera (tb. user garraxi) y en cualquier momento, pero solo garraxi2 podria borrar los archivos que ya estuvieran "protegidos" (pasados a chown garraxi2). Mientras que el archivo no esta protegido puede ser borrado por garraxi, por lo que le permite arreglar errores. Esto simplifica la gestion de los directorios, porque antes teniamos que algunos eran propiedad de garraxi2 (los protegidos) y otros tenian que permanecer siempre propiedad de garraxi, para permitir la escritura en ellos. Ahora con mantener todos con el sticky bit activado vale. Ademas, incluyo en el script que protege los archivos que solo actue en los que son propiedad de garraxi (asi evito que tenga que actuar sobre el total de los archivos), y que ademas de cambiar el propietario, tambien fije los permisos: - fichero: rw-rw-r-- (ver discusion en info-software-garraxi2, aunque ahora podria no ser valida) - directorio: rwxrwxrwt (escribible por todos pero no borrable mas que por el propietario del archivo a borrar, por el sticky bite). Esto nos evita que permanezcan archivos de musica con el bit ejecutable activado (los que provienen de particiones FAT, como las de las memorias USB) vienen asi. De esta manera aplicamos tambien la proteccion a los programas grabados que guardamos, para evitar que se borren por error. Sin embargo no se pueden proteger los programas que estan para emitirse (en el dir ~/Biltegi/Programas, y no en su subdirectorio), porque si se hace, luego no pueden ser movidos a su subdir de backup por el script de grabar programas. Otra cosa que cambia esto, es la gestion de los programas guardados, que ya no pueden ser borrados por el que graba los programas, sino por un admin. Pongo este dato en la ventana de grabacion de programas. Ademas, el script de cron "mantenprogramas" tambien cambia, porque ahora cuando repone un programa viejo para su reemision, tiene que cambiar el owner del archivo a garraxi, para que despues pueda ser borrado por el script de gabacion. GARRAXI2 INTENTANDO ESCRIBIR EN DIRS CREADOS POR GARRAXI: En Garraxi, usamos los user garraxi y garraxi2 para manejar la musica (porque hay musica que pertenece a garraxi (la que esta sin proteger) y otra a garraxi2 (la protegida). Es usual que garraxi cree un dir para musica desde Thunar y despues se intente manejarla con user garraxi2 (que pertenece al grupo garraxi) para mover a el musica "protegida" por ejemplo. Para que garraxi2 pueda escribir en dirs creados por garraxi es necesario que esten con permisos drwxrwxr-x (umask 002), pero por defecto en Debian se crean con permisos drwxrw-r-x (umask 022). Para cambiar esto es suficiente con editar el fichero /home/garraxi/.bash_profile y ponerle un 'umask 002'. El problema esta en que, aunque se haga ese cambio, Thunar no hace caso (otras apps como Emelfm o una Mrxvt si que lo hacen). Tras darle varias vueltas encuentro que es un bug de Thunar que no hace caso al umask definido por el usuario (http://bugzilla.xfce.org/show_bug.cgi?id=3532) y que hay un patch muy sencillo: http://launchpadlibrarian.net/15574407/thunar-fsperms.diff. Basta con aplicar los cambios que se proponen en el patch y recompilar Thunar. Realizado este cambio Thunar hace caso al umask de cada usuario definido en ~/.bash_profile. No hace falta instalar libpam-umask (se habla algo de esto en el fichero /etc/login.def) ni tocar este fichero o /etc/profile. ---------------- TEMAS PENDIENTES: - Euskaratu nere scriptak. Horretarako jarri dezakegu bi user, bat erderazkoa eta bestea euskerazkoa, eta honetan ingurune osoa euskeraz izatea, eta ere scriptak. Erederazkoa ingurunea eta scriptak gaztelainaz. Horretarako info bat eman behar da login egiterakoan (ad. ze user eta password erabili behar da segun eta hizkutza). Hori jarri behar da /etc/motd.tail'en. - Pensar en utilizar un usuario "normal" por cada programa de radio que se haga, para evitar los riesgos de seguridad que implica tener un solo usuario para toda la gente que anda en la radio. Idea copiada de lo que hacen en Eguzki Irratia. - Que ocurre si alguien se deja grabando el flrec (no para de grabar su programa), Implementar un checkeador?. La solucion puede venir de no usar el server por el user, de manera que tenga que arrancar y apagar el ordenata. - Para cuando no utilicemos el server como ordenata de usuario: hacer algun tipo de "visor" de lo que esta emitiendo el somad, algo parecido a lo que se ve ahora en una terminal, que dice el archivo que esta sonando, y cuando tiempo tiene de total y cuanto le falta. Para saber el archivo que se esta tocando basta con poner un visor del soma.log con tail (por ejemplo en la ventana raiz con 'root-tail -g 900x25+100+740 /var/log/soma/soma.log' (adaptar la geometria a la pantalla y al numero de lineas a mostrar)). Pero para saber cuanto falta de sonar... Se puede redireccionar el output de somad del servidor a una determinada tty (terminal de texto) del propio servidor. Para ello primero debemos estar logeados en esa tty como user normal. Esto se puede hacer añadiendo a /etc/inittab otra linea como la que ya hace de autologin en la tty1: 2:2345:respawn:/sbin/getty -n -l /usr/local/sbin/autologingarraxi 38400 tty2 Despues lanzar somad desde tty1 con un comando como 'somad >& /dev/tty2 &', donde: >&: redirecciona tanto stderr (errores) que en somad son la info de cancion cacheada y a tocar, como stadout, que es el output de mplayer con el progreso de la cancion. /dev/tty2: la terminal a la que lo enviamos (en este caso tty3) &: para pasar el comando a segundo plano (si no se pone da un error "Binding error"). Despues. desde el auxiliar conectarnos por ssh a esa terminal tty concreta donde hemos lanzado el somad (para ver su output en una xterm). Esto no tengo claro como hacerlo. quizas con el paquete ttysnoop: Description: TTY Snoop - allows you to spy on telnet+serial connections TTYSnoop allows you to snoop on login tty's through another tty-device or pseudo-tty. The snoop-tty becomes a 'clone' of the original tty, redirecting both input and output from/to it. Esto se puede hacer por ssh, como dice aqui (pero parece complicado): http://www.linuxforums.org/forum/debian-linux-help/14702-recompiling-sshd-2.html. Parece que hay que recompilar ssh (en castellano): http://blogdebian.net/node/87 OTRA SOLUCION MUCHO MAS SENCILLA es usar el paquete gems. Tras instalarlo en todos los ordenatas, en el server lanzar (en el script de arranque por ejemplo) el comando 'gems-server' primero y despues el somad. En el auxiliar, lanzar (tb en el arranque) en una xterm el comando 'gems-client serverIP' y ya estamos viendo en esa xterm el output de somad del server !! :-D. Ver: http://debaday.debian.net/index.php?s=gems.