La primera vez que instale FreeBSD me sorprendio la manera en la cual yo podia decidir cuantos servicios x usuario podia ejecutar, cuanta capacidad de ram podia este usuario consumir del sistema, cuantos procesos podia ejecutar, cuantos archivos podia abrir, etc. Todo era sencillamente en un simple archivo de texto indicarle un 1 ('activado') o 0 ('desactivado') pasado como parametro al kernel. Y me pregunte porque en Linux esta funcionalidad no existe? Luego me he topado con smrole en Solaris, que es un comando que nos permite controlar lo mismo, muchos pensamos que Linux no posee esta funcionalidad integrada. Y en caso de poseerla, o poseer algo similar es una funcionalidad extra tipo Selinux, o Rsbac que son parches para el kernel.
Pero existe algo comun en todos los Linuxes, y que muchos usuarios desconocen su existencia. Esta funcionalidad es 'ulimit'
Ulimit es un comando especial de la terminal, mayormente utilizado para controlar los servicios, cantidad de archivos a abrir, cantidad de consumo de ram, etc, que un usuario especifico pueda ejecutar en una terminal (Y como todos sabemos todos los servicios se ejecutan en una terminal). Podemos jugar con ulimit, en modo global o en modo solo aplicable a 1 usuario.
En modo global incluye editar 'ulimit' en /etc/profile pero si editamos a modo global aplicaria al usuario root por igual, pero si editamos .bashrc en cada $HOME de 1 usuario especifico y ponemos permisos chmod 600 donde solo root sea duenio, tendremos a dicho usuario controlado al nivel que queramos.
Para conocer nuestra limitante en una terminal basta con escribir :
bash$ ulimit -u
Si dice unlimited es porque tenemos acceso sin ninguna restriccion, si queremos algo mas detallado al respecto usamos:
bash$ ulimit -a
bash-3.1$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 8182
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 8182
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
si queremos controlar las opciones que proporciona ulimit basta con agregar a .bashrc
ulimit -n 30
Donde el parametro -n indica cantidad de archivos que puede un usuario abrir. Podemos tambien hacerlo temporal en nuestra propia shell para probar, luego verificamos con ulimit -a los cambios.
:)
sábado 12 de julio de 2008
KDE 4 en Slackware 12.1 o (current).
Muchos usuarios tienen la duda, de como obtener paquetes precompilados de KDE 4 para Slackware 12.1 o rama current.
me alegra informarles, que existen paquetes ya precompilados disponibles para nuestro apreciado Slackware :) He aqui el Link. En ingles pero este senor es el responsable por el momento de crear paquetes precompilados de KDE 4 para Slackware, tambien ha sido halagado por el mismo Patrick Volkerding (Desarrollador principal de Slackware) en relacion a lo estables que son estos paquetitos en Slackware.
http://geektime.wordpress.com/2008/04/23/kde-4-on-slackware-120/
me alegra informarles, que existen paquetes ya precompilados disponibles para nuestro apreciado Slackware :) He aqui el Link. En ingles pero este senor es el responsable por el momento de crear paquetes precompilados de KDE 4 para Slackware, tambien ha sido halagado por el mismo Patrick Volkerding (Desarrollador principal de Slackware) en relacion a lo estables que son estos paquetitos en Slackware.
http://geektime.wordpress.com/2008/04/23/kde-4-on-slackware-120/
sábado 7 de junio de 2008
Maria nuevo Motor Almacenamiento Mysql
No es tan nuevo, pero me entere un poco tarde Sonreir
Mysql lanzo una version testing en Enero 2008 de Maria. Un nuevo motor de almacenamiento no transaccional, desarrollado como una extension del famoso Myisam.
Maria aporta las mismas funcionalidades que Myisam, con la unica diferencia que es 'efectivo contra fallas' cosa que Myisam no, la definicion de 'efectivo contra fallas' implica que luego de hacer un proceso tipo backup, transacciones remota de una tabla a otro servidor y que haya por desgracia una falla electrica y se corte repentinamente nuestro intercambio, en tablas Myisam ocurria la dificultad que nos resultaba dificil recuperar los datos de dicha tabla y aveces usando 'repair table' no funcionaba.
Y es aqui cuando Maria funciona ya que Maria si tiene capacidad de recobrar data rota con una gran facilidad.
El motor de almacenamiento Maria No esta disponible oficialmente dentro de ninguna version Mysql, mas bien esta dentro de una version Mysql 5.x considerada como testing por el simple hecho de tener a Maria embebido sin embargo los fuentes de este Mysql con Maria se pueden conseguir desde la web oficial de Mysql o Sun. Se pretende, en un futuro integrar Maria de manera oficial dentro de Mysql, con el objetivo de sustituir a Myisam.
Mysql lanzo una version testing en Enero 2008 de Maria. Un nuevo motor de almacenamiento no transaccional, desarrollado como una extension del famoso Myisam.
Maria aporta las mismas funcionalidades que Myisam, con la unica diferencia que es 'efectivo contra fallas' cosa que Myisam no, la definicion de 'efectivo contra fallas' implica que luego de hacer un proceso tipo backup, transacciones remota de una tabla a otro servidor y que haya por desgracia una falla electrica y se corte repentinamente nuestro intercambio, en tablas Myisam ocurria la dificultad que nos resultaba dificil recuperar los datos de dicha tabla y aveces usando 'repair table' no funcionaba.
Y es aqui cuando Maria funciona ya que Maria si tiene capacidad de recobrar data rota con una gran facilidad.
El motor de almacenamiento Maria No esta disponible oficialmente dentro de ninguna version Mysql, mas bien esta dentro de una version Mysql 5.x considerada como testing por el simple hecho de tener a Maria embebido sin embargo los fuentes de este Mysql con Maria se pueden conseguir desde la web oficial de Mysql o Sun. Se pretende, en un futuro integrar Maria de manera oficial dentro de Mysql, con el objetivo de sustituir a Myisam.
jueves 5 de junio de 2008
Bourne o C Shell
Como usuarios de Linux & Unix. Debemos conocer bien la terminal, sabemos (y para quienes no lo saben Cheesy) que la terminal en Linux/Unix es simplemente un interprete de comandos. La via por donde el usuario puede comunicarse con el SO. En estos sistemas existen sin embargo, varios clientes terminales en los cuales podemos destacar :
Bourne Shells :
/bin/sh
/bin/bash
/bin/ksh
C Shells ::
/bin/csh
/bin/tcsh
Las mas usadas por nosotros (Linuxeros Sonrisa) es la tipica 'bash'. En sistemas Unixes (BSD, HP-UX, Solaris). Por defecto se utiliza o /bin/sh o /bin/ksh.
Un poquito de historia :
La primera 'shell' en nacer fue /bin/sh que es una shell creada por Sthepen Bourne, sustituyendo a la shell de Thompsom en los sistemas Unixes alla por los 70 y algo.
La bourne shell 'sh' se hizo tan popular que aun hoy dia uno de sus hijos son los mas usados. Y obviamente mas adelante GNU no podia quedarse fuera de este proyecto Sonrisa y nacio la primera Gnu-Bourne-Shell (Basada en sh) - nuestra querida 'bash'
Por igual forma otras companias no podian quedarse sin su propia version de shell bourne, y tambien surgio korn shell. Estas 3 shells, son totalmente compatibles entre si, y cualquier bourne-script funciona en (bash, sh, korn).
Pero como todo tiene una contraparte, no olvidemos las C - shells.
Las C-shells son (csh & tcsh) aunque tiene la misma funcionalidad que las Bourne Shells (funcionar como interprete de comandos) se desarrollo para los amantes del lenguaje 'C' por ser sus C-shell-script tan parecido a este lenguaje.
La C-Shell fue desarrollada por la gente de 'Berkeley' (Nuevamente tenemos la mano maestra de estos genios Cheesy ). Aunque como todo lo que sale de Berkeley, esta terminal no es tan popular como su competencia las Bourne Shells.
Su objetivo esta mas dirigido a programadores que a administradores, y un C-Shell-Script no precisamente va a funcionar en una terminal bourne y viceversa, ya que la sintaxis de interpretar comandos es distinta. Las C-Shells incluyen funciones, parametros, matrices, muy distintas a las que las Bourne Shells pueden soportar y viceversa.
Aunque tanto con cualquier shell Bourne o cualquier shell C Shell, se pueden desarrollar scripting, es de gusto y decision final del usuario cual de los dos distintos tipos de interpretes utilizar.
Yo utilizo bastante, la Bourne shell /bin/sh aveces /bin/bash, pero me he adaptado un poco a /bin/sh.
Cual es la preferida por ti
Bourne Shells :
/bin/sh
/bin/bash
/bin/ksh
C Shells ::
/bin/csh
/bin/tcsh
Las mas usadas por nosotros (Linuxeros Sonrisa) es la tipica 'bash'. En sistemas Unixes (BSD, HP-UX, Solaris). Por defecto se utiliza o /bin/sh o /bin/ksh.
Un poquito de historia :
La primera 'shell' en nacer fue /bin/sh que es una shell creada por Sthepen Bourne, sustituyendo a la shell de Thompsom en los sistemas Unixes alla por los 70 y algo.
La bourne shell 'sh' se hizo tan popular que aun hoy dia uno de sus hijos son los mas usados. Y obviamente mas adelante GNU no podia quedarse fuera de este proyecto Sonrisa y nacio la primera Gnu-Bourne-Shell (Basada en sh) - nuestra querida 'bash'
Por igual forma otras companias no podian quedarse sin su propia version de shell bourne, y tambien surgio korn shell. Estas 3 shells, son totalmente compatibles entre si, y cualquier bourne-script funciona en (bash, sh, korn).
Pero como todo tiene una contraparte, no olvidemos las C - shells.
Las C-shells son (csh & tcsh) aunque tiene la misma funcionalidad que las Bourne Shells (funcionar como interprete de comandos) se desarrollo para los amantes del lenguaje 'C' por ser sus C-shell-script tan parecido a este lenguaje.
La C-Shell fue desarrollada por la gente de 'Berkeley' (Nuevamente tenemos la mano maestra de estos genios Cheesy ). Aunque como todo lo que sale de Berkeley, esta terminal no es tan popular como su competencia las Bourne Shells.
Su objetivo esta mas dirigido a programadores que a administradores, y un C-Shell-Script no precisamente va a funcionar en una terminal bourne y viceversa, ya que la sintaxis de interpretar comandos es distinta. Las C-Shells incluyen funciones, parametros, matrices, muy distintas a las que las Bourne Shells pueden soportar y viceversa.
Aunque tanto con cualquier shell Bourne o cualquier shell C Shell, se pueden desarrollar scripting, es de gusto y decision final del usuario cual de los dos distintos tipos de interpretes utilizar.
Yo utilizo bastante, la Bourne shell /bin/sh aveces /bin/bash, pero me he adaptado un poco a /bin/sh.
Cual es la preferida por ti
System V vs BSD Scripts
La primera vez que me instale Slackware.. hace ya unos anitos, recuerdo que me sentia rara porque queria reiniciar servicios o desabilitarlos buscando en '/etc/init.d' o sus respectivos runlevels '/etc/rcx.d' Pero me di una sorpresa al ver que no existia ni la carpeta init.d, ni rcx.d de cada runlevel, nisiquiera /etc/pam.d
Yo que venia de Linuxes que si incluian estos menesteres(Mandrake, Suse, RedHat, Debian). Me sorprendi un poco y tuve que indagar porque esto era asi o donde slackware guardaba los demonios. Ahi fue que me tope con que hay sistemas Linux & Unixes que poseen sus scripts de arranque basado en BSD scripts o System V. Slackware estaba y aun esta basado en scripts de inicio BSD Scripts. Ahora ustedes se preguntaran que son scripts de inicios System V y que son BSD scripts.
La mayoria de Linuxes y Unixes (Solaris & HP-UX) poseen sus scripts de inicio basados en System V, cuando un sistema esta basado en System V, divide los servicios a cargar por defecto en varias carpetas por cada runlevel. Por ejemplo, el runlevel 5 en Linux es al cual ingresamos por defecto despues que termina de cargar el sistema. Este runlevel en los sistemas basados en System V tiene los servicios a cargar en '/etc/rc5.d' ahi dentro vemos muchos enlazes directos a los servicios de '/etc/init.d' todo lo que aparezca dentro de '/etc/rc5.d' es lo que va a cargar o es lo que vemos cargando cuando iniciamos el sistema. Si por ejemplo dentro de la carpeta '/etc/rc5.d' se encuentra el enlace 'mysql', bastaria con borrar mysql de /etc/rc5.d y ya este no cargaria por defecto cada vez que ingresemos al sistema, que es el runlevel 5.
Ahora.. como si se hace asi en System V, como se hace en sistemas BSD scripts?
Existen otros Unixes y Linux (minoria) que aun trabaja con BSD scripts, entre estos tenemos (Slackware, Crux, Arch Linux) y los BSD (FreeBSD, OpenBSD, NetBSD). Aqui no existe 1 carpeta para cada runlevel como si existe en un System V. Aqui existe 1 solo archivo de configuracion, que es el que indica que servicios cargar y cuales no a la hora de iniciar el sistema... y cualquier cambio a este archivito aplica a todos los runlevels (Van captando la diferencia?).
En slackware dicho archivo se llama rc.M se encuentra en /etc/rc.d (que seria el equivalente a '/etc/init.d' en un System V). en rc.M vemos que servicios el sistema por defecto carga al iniciar y cuales no, si queremos apagar uno podemos o comentarlo en rc.M o quitarle los permisos de ejecucion al demonio que tambien esta dentro de '/etc/rc.d'.
En los sistemas BSD (FreeBSD por ejemplo y Crux o Arch linux), igual que slackware tenemos 1 solo archivo de configuracion para todos los runlevels. dicho archivito se llama rc.conf y esta en '/etc' Como slackware en rc.conf estan todos los demonios a cargar para todos los runlevels, aqui activamos o desactivamos servicios solo editando ese archivo.
En resumen ::
System V : 1 carpeta por cada runlevel dicha carpeta contiene dentro enlacez simbolicos a los demonios que debe cargar. Cada carpeta de runlevel, cualquier cambio solo aplica para ese runlevel.
BSD Scripts: 1 solo archivo de configuracion, donde se editan los servicios que deben o no subir, cualquier cambio aplica para todos los runlevels.
Cual es mejor? ninguno, son solo distintas maneras de manejar el asunto Sonrisa
Como me doy cuenta cuando un sistema es System V o BSD scripts?
Sencillo, cuando iniciamos un Unix o Linux donde se nos permita ver en el proceso de inicio antes de llegar al prompt login o al servidor X (Gnome, KDE, etc). si nuestro sistema va cargando asi :
Samba .............. (OK)
networking ..............(OK)
sound ...................(OK)
Es un sistema tipo System V. Ya sabemos que como tal, debe tener una carpeta de demonios llamada 'init.d' generalmente ubicada en '/etc' pero hay unixes que la ubican en otro lado (HP-UX por ejemplo). Y que como es System V no solo tiene init.d tambien tiene subcarpetas por cada runlevel.
Ahora si el sistema va iniciando asi ::
raid6: using algorithm sse2x2 (1901 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 4182.000 MB/sec
raid5: using function: pIII_sse (4182.000 MB/sec)
md: multipath personality registered for level -4
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
Y va cargando un poco rapido, estamos frente a un sistemas BSD-Scripts. Ya saben que dentro debe tener algun rc.conf o rc.M donde manipule los servicios a cargar al inicio y que cualquier cambio aplica para todos los runlevels.
Yo que venia de Linuxes que si incluian estos menesteres(Mandrake, Suse, RedHat, Debian). Me sorprendi un poco y tuve que indagar porque esto era asi o donde slackware guardaba los demonios. Ahi fue que me tope con que hay sistemas Linux & Unixes que poseen sus scripts de arranque basado en BSD scripts o System V. Slackware estaba y aun esta basado en scripts de inicio BSD Scripts. Ahora ustedes se preguntaran que son scripts de inicios System V y que son BSD scripts.
La mayoria de Linuxes y Unixes (Solaris & HP-UX) poseen sus scripts de inicio basados en System V, cuando un sistema esta basado en System V, divide los servicios a cargar por defecto en varias carpetas por cada runlevel. Por ejemplo, el runlevel 5 en Linux es al cual ingresamos por defecto despues que termina de cargar el sistema. Este runlevel en los sistemas basados en System V tiene los servicios a cargar en '/etc/rc5.d' ahi dentro vemos muchos enlazes directos a los servicios de '/etc/init.d' todo lo que aparezca dentro de '/etc/rc5.d' es lo que va a cargar o es lo que vemos cargando cuando iniciamos el sistema. Si por ejemplo dentro de la carpeta '/etc/rc5.d' se encuentra el enlace 'mysql', bastaria con borrar mysql de /etc/rc5.d y ya este no cargaria por defecto cada vez que ingresemos al sistema, que es el runlevel 5.
Ahora.. como si se hace asi en System V, como se hace en sistemas BSD scripts?
Existen otros Unixes y Linux (minoria) que aun trabaja con BSD scripts, entre estos tenemos (Slackware, Crux, Arch Linux) y los BSD (FreeBSD, OpenBSD, NetBSD). Aqui no existe 1 carpeta para cada runlevel como si existe en un System V. Aqui existe 1 solo archivo de configuracion, que es el que indica que servicios cargar y cuales no a la hora de iniciar el sistema... y cualquier cambio a este archivito aplica a todos los runlevels (Van captando la diferencia?).
En slackware dicho archivo se llama rc.M se encuentra en /etc/rc.d (que seria el equivalente a '/etc/init.d' en un System V). en rc.M vemos que servicios el sistema por defecto carga al iniciar y cuales no, si queremos apagar uno podemos o comentarlo en rc.M o quitarle los permisos de ejecucion al demonio que tambien esta dentro de '/etc/rc.d'.
En los sistemas BSD (FreeBSD por ejemplo y Crux o Arch linux), igual que slackware tenemos 1 solo archivo de configuracion para todos los runlevels. dicho archivito se llama rc.conf y esta en '/etc' Como slackware en rc.conf estan todos los demonios a cargar para todos los runlevels, aqui activamos o desactivamos servicios solo editando ese archivo.
En resumen ::
System V : 1 carpeta por cada runlevel dicha carpeta contiene dentro enlacez simbolicos a los demonios que debe cargar. Cada carpeta de runlevel, cualquier cambio solo aplica para ese runlevel.
BSD Scripts: 1 solo archivo de configuracion, donde se editan los servicios que deben o no subir, cualquier cambio aplica para todos los runlevels.
Cual es mejor? ninguno, son solo distintas maneras de manejar el asunto Sonrisa
Como me doy cuenta cuando un sistema es System V o BSD scripts?
Sencillo, cuando iniciamos un Unix o Linux donde se nos permita ver en el proceso de inicio antes de llegar al prompt login o al servidor X (Gnome, KDE, etc). si nuestro sistema va cargando asi :
Samba .............. (OK)
networking ..............(OK)
sound ...................(OK)
Es un sistema tipo System V. Ya sabemos que como tal, debe tener una carpeta de demonios llamada 'init.d' generalmente ubicada en '/etc' pero hay unixes que la ubican en otro lado (HP-UX por ejemplo). Y que como es System V no solo tiene init.d tambien tiene subcarpetas por cada runlevel.
Ahora si el sistema va iniciando asi ::
raid6: using algorithm sse2x2 (1901 MB/s)
md: raid6 personality registered for level 6
md: raid5 personality registered for level 5
md: raid4 personality registered for level 4
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 4182.000 MB/sec
raid5: using function: pIII_sse (4182.000 MB/sec)
md: multipath personality registered for level -4
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
Y va cargando un poco rapido, estamos frente a un sistemas BSD-Scripts. Ya saben que dentro debe tener algun rc.conf o rc.M donde manipule los servicios a cargar al inicio y que cualquier cambio aplica para todos los runlevels.
martes 3 de junio de 2008
Umask en Unix/Linux
Alguna vez se han preguntado como sabe Unix/Linux cuando creo un directorio nuevo o un archivo que permisos otorgar por defecto??? Sabes como tu como administrador puedes manipular dichos permisos?.
En los distintos sistemas Unixes/Linux tenemos una variable de entorno que controla esto llamada umask. Umask no es mas que otra forma de administrar los permisos bajo sistemas unixes/linux, y podemos encontrar una entrada de el en /etc/profile, por lo general siempre lo veremos asi :
umask 022
Los permisos en Linux/Unix se otorgan como octal, decimal o simbolo:
Octal : 0000
decimal : 000
simbolos : u, a, +, -
como manipulamos umask con los permisos estandares de nuestro sistema? sencillo, toda carpeta recien creada en Linux tiene los permisos 755, y si es un archivo de texto 655.. Ahora te preguntaras porque 755 y 655 y no 777 o 666? o 700 o 600? sencillo, porque si tenemos definido una umask 022 que es la estandar en /etc/profile, todos los permisos de los nuevos archivos se restaran con el octal que tengamos como umask. Por lo cual realmente todas las carpetas se crean con permisos 777 y los archivos de textos 666 pero si restamos ambos a la umask ya definida en /etc/profile como 022, obtenemos lo siguiente :
umask = 022
carpeta = 777
archivo = 666
022 - 777 = 755
022 - 666 = 644
Captan la idea? no podemos restar el primer 7 ni el primer 6 ya que 0 no tiene valor, pero si podemos restar 2 - 7 y 6 - 2, y es aqui que se definen los permisos reales que tendran todos los archivos y carpetas que recien vayamos creando. Ahora, que ocurre si modificamos el umask 022 de /etc/profile y decimos que quiero un umask 077 y guardamos los cambios en /etc/profile actualizamos con el comando source /etc/profile y creamos una carpeta nueva, que ocurrira aqui?? ya nuestra carpeta no tendra permisos 755 sino :
umask 077
carpeta 777
077 - 777 = 700
Todas las nuevas carpetas se crearan con permisos 700, donde solo el duenio tendra acceso a entrar, modificar, borrar, actualizar, etc. Lo mismo ocurre si volvemos a modificar la entrada umask en /etc/profile y decimos que ya no queremos una umask 077 sino umask 066, y actualizamos /etc/profile y creamos un archivo de texto nuevo. Ya nuestro archivo no tendra permisos 644 como ocurre cuando tenemos umask 022. Aqui seria :
umask 066.
archivo 666
066 - 666 = 600
Donde solo el duenio o creador del archivo tendra acceso a modificarlo, insertar, verlo, leerlo, etc. Tambien podemos jugar con umask fuera de editar /etc/profile (ya que editar /etc/profile indica que se apliquen a todos los usuarios del sistema). sencillamente abrimos una terminal, y ejecutamos umask valor, donde valor es el valor temporal que queremos asignar a esa seccion que tengo abierta en la terminal, y la cual se aplicara solo mientras mantenga esa seccion abierta, y cree nuevas carpetas o archivos dentro de dicha seccion.
Espero que la explicacion de umask les haya sido de utilidad.
En los distintos sistemas Unixes/Linux tenemos una variable de entorno que controla esto llamada umask. Umask no es mas que otra forma de administrar los permisos bajo sistemas unixes/linux, y podemos encontrar una entrada de el en /etc/profile, por lo general siempre lo veremos asi :
umask 022
Los permisos en Linux/Unix se otorgan como octal, decimal o simbolo:
Octal : 0000
decimal : 000
simbolos : u, a, +, -
como manipulamos umask con los permisos estandares de nuestro sistema? sencillo, toda carpeta recien creada en Linux tiene los permisos 755, y si es un archivo de texto 655.. Ahora te preguntaras porque 755 y 655 y no 777 o 666? o 700 o 600? sencillo, porque si tenemos definido una umask 022 que es la estandar en /etc/profile, todos los permisos de los nuevos archivos se restaran con el octal que tengamos como umask. Por lo cual realmente todas las carpetas se crean con permisos 777 y los archivos de textos 666 pero si restamos ambos a la umask ya definida en /etc/profile como 022, obtenemos lo siguiente :
umask = 022
carpeta = 777
archivo = 666
022 - 777 = 755
022 - 666 = 644
Captan la idea? no podemos restar el primer 7 ni el primer 6 ya que 0 no tiene valor, pero si podemos restar 2 - 7 y 6 - 2, y es aqui que se definen los permisos reales que tendran todos los archivos y carpetas que recien vayamos creando. Ahora, que ocurre si modificamos el umask 022 de /etc/profile y decimos que quiero un umask 077 y guardamos los cambios en /etc/profile actualizamos con el comando source /etc/profile y creamos una carpeta nueva, que ocurrira aqui?? ya nuestra carpeta no tendra permisos 755 sino :
umask 077
carpeta 777
077 - 777 = 700
Todas las nuevas carpetas se crearan con permisos 700, donde solo el duenio tendra acceso a entrar, modificar, borrar, actualizar, etc. Lo mismo ocurre si volvemos a modificar la entrada umask en /etc/profile y decimos que ya no queremos una umask 077 sino umask 066, y actualizamos /etc/profile y creamos un archivo de texto nuevo. Ya nuestro archivo no tendra permisos 644 como ocurre cuando tenemos umask 022. Aqui seria :
umask 066.
archivo 666
066 - 666 = 600
Donde solo el duenio o creador del archivo tendra acceso a modificarlo, insertar, verlo, leerlo, etc. Tambien podemos jugar con umask fuera de editar /etc/profile (ya que editar /etc/profile indica que se apliquen a todos los usuarios del sistema). sencillamente abrimos una terminal, y ejecutamos umask valor, donde valor es el valor temporal que queremos asignar a esa seccion que tengo abierta en la terminal, y la cual se aplicara solo mientras mantenga esa seccion abierta, y cree nuevas carpetas o archivos dentro de dicha seccion.
Espero que la explicacion de umask les haya sido de utilidad.
domingo 25 de mayo de 2008
Mysql Falcon
Much@s conocemos las grandes ventajas de las bases de datos relacionales, sobretodo si es de codigo libre, como el caso de Postgresql y Mysql. Hablemos sobre Mysql en si, Mysql se ha caracterizado por ser el RDBMS mas rapido que existe dentro de las DB relacionales existentes (Oracle, SQL Server, DB2, etc).
Mysql tambien se diferencia de sus amigas en muchas cosas, ademas de ser una DB relacional posee distintos motores de almacenamientos de datos, que las demas DB no poseen. En Mysql version 5.1.x he inferiores teniamos los siguientes motores de almacenamientos disponibles :
Myisam :: El motor por defecto de Mysql, indice alto de lectura, no posee capacidad ni soporte para claves foraneas ni referencias. Un gran ambito de escritura sobre este motor alenta sobre manera la DB, pero para lectura es bastante rapida. Es un motor No transaccional, lo que indica que cualquier peticion realizada por un usuario o administrador se aplica inmediato en la tabla y no somos capacez de usar rollback, ya que el cambio es real no virtual como ocurre en una tabla transaccional.
InnoDB :: Motor de almacenamiento transaccional perteneciente a la compania de Oracle. Posee la caracteristica de soportar claves foraneas y referencias. Tambien posee la capacidad de crear un archivo distinto por cada tabla. No es tan rapida como su contraparte Myisam, pero maneja la data en un modo mas seguro.
Federated :: Motor de almacenamiento No transaccional, su funcion principal es permitir al administrador que los objectos de una tabla sean guardados en un servidor Mysql remoto y no local.
NDBCluster :: Utilizado para realizar clusteres de discos en varias DB Mysql locales.
Memory & Example :: Motores no transacionales, su uso es mas para testing.
Mirando una breve descripcion de los motores de almacenamientos disponibles en Mysql, nos encontramos con un nuevo motor de almacenamiento en Mysql 6.x el cual aun es alpha y esta en version beta. Hablamos de Falcon.
Falcon es un nuevo motor de almacenamiento totalmente GPL y totalmente transaccional , tiene soporte para claves foraneas y referencias. Tambien posee una nueva implementacion que es la creacion de tablespaces (como en Oracle) donde podemos asignar un datafile para guardar los objetos de nuestras tablas.
Las caracteristicas de estos tablespaces a diferencia de un tablespace Oracle, es que Falcon crea un datafile de 16KB por defecto, el cual automaticamente ira automentando de tamano mientras tengamos capacidad en el disco duro. No ocurre asi en un datafile de Oracle donde debemos indicar su tamano y si queremos agrandar o reducir debemos alterar la DB Oracle. Otra utilidad de un datafile en Falcon es, que al eliminar nuestro tablespace, este automaticamente eliminar el datafile que le pertenece, otra ventaja sobre un tablespace de Oracle que no elimina datafiles.
Otra ventajilla de un tablespace Falcon, es que su datafile incluye al igual que los demas motores de almacenamiento de Mysql (exceptuando Myisam), los indices y la data de una tabla dentro del mismo archivo. Esto, muchos DBA Oracle piensan que es una desventaja, ya que se tiene la creencia por ley que los indices deben estar en otro HD distinto a la data, y esto debe ser asi en Oracle u otra DB relacional, pero no en Mysql. La razon? la siguiente :
Oracle lee alternadamente 1 indice, 1 data, 1 indice, 1 data dentro de sus archivos. Si los indices y la data se encuentran en el mismo HD, imaginen la presion que esto causaria al HD y la banda ancha en si.
Mysql con Falcon, al tener indices y data en 1 solo archivo, lee de antemano primero todos los indices y luego la data no lee alternadamente como lo hace Oracle en 2 archivos distintos, sino que lee 1 solo primero todos los indices, y luego toda la data, lo cual arregla este problemita de saturamiento de lectura por el cual hay que separar indices y data en 2 HD distintos.
El motor de almacenamiento Falcon solo viene disponible en Mysql 6.x. Para crear un tablespace usamos :
mysql> create tablespace fulano
add datafile 'fulano.fts'
engine = falcon;
Con esto creamos 1 nuevo tablespace con 1 datafile llamado fulano.fts, podemos verificar en el diccionario de metadata de Mysql sobre la existencias de todos nuestros tablespaces en la DB, pero si nuestro tablespace en cuestion no tiene aun objetos guardados (una tabla), no aparecera a la hora que hagamos :
mysql> select * from information_schema.falcon_tables;
Hasta el momento no se soporta agregar mas datafiles a un tablespace, aunque en un futuro la pretension existe. Ya creado nuestro tablespace fulano, creamos una tabla con el mismo motor de almacenamiento y le asignamos su respectivo tablespace.
mysql> create table prueba ( nombres char(20), apellidos char(20)) engine = falcon tablespace fulano;
Ahora que existe un objeto real en el datafile fulano.fts podemos verificar la existencia de dicho tablespace :
mysql> select * from information_schema.falcon_tables;
Para eliminar un tablespace existente, debemos tener claro que no debe contener ningun objeto, de lo contrario no podremos eliminarlo y nos dara error. Para borrar un tablespace hacemos :
mysql> drop tablespace fulano engine = falcon;
Un Saludo :)
Mysql tambien se diferencia de sus amigas en muchas cosas, ademas de ser una DB relacional posee distintos motores de almacenamientos de datos, que las demas DB no poseen. En Mysql version 5.1.x he inferiores teniamos los siguientes motores de almacenamientos disponibles :
Myisam :: El motor por defecto de Mysql, indice alto de lectura, no posee capacidad ni soporte para claves foraneas ni referencias. Un gran ambito de escritura sobre este motor alenta sobre manera la DB, pero para lectura es bastante rapida. Es un motor No transaccional, lo que indica que cualquier peticion realizada por un usuario o administrador se aplica inmediato en la tabla y no somos capacez de usar rollback, ya que el cambio es real no virtual como ocurre en una tabla transaccional.
InnoDB :: Motor de almacenamiento transaccional perteneciente a la compania de Oracle. Posee la caracteristica de soportar claves foraneas y referencias. Tambien posee la capacidad de crear un archivo distinto por cada tabla. No es tan rapida como su contraparte Myisam, pero maneja la data en un modo mas seguro.
Federated :: Motor de almacenamiento No transaccional, su funcion principal es permitir al administrador que los objectos de una tabla sean guardados en un servidor Mysql remoto y no local.
NDBCluster :: Utilizado para realizar clusteres de discos en varias DB Mysql locales.
Memory & Example :: Motores no transacionales, su uso es mas para testing.
Mirando una breve descripcion de los motores de almacenamientos disponibles en Mysql, nos encontramos con un nuevo motor de almacenamiento en Mysql 6.x el cual aun es alpha y esta en version beta. Hablamos de Falcon.
Falcon es un nuevo motor de almacenamiento totalmente GPL y totalmente transaccional , tiene soporte para claves foraneas y referencias. Tambien posee una nueva implementacion que es la creacion de tablespaces (como en Oracle) donde podemos asignar un datafile para guardar los objetos de nuestras tablas.
Las caracteristicas de estos tablespaces a diferencia de un tablespace Oracle, es que Falcon crea un datafile de 16KB por defecto, el cual automaticamente ira automentando de tamano mientras tengamos capacidad en el disco duro. No ocurre asi en un datafile de Oracle donde debemos indicar su tamano y si queremos agrandar o reducir debemos alterar la DB Oracle. Otra utilidad de un datafile en Falcon es, que al eliminar nuestro tablespace, este automaticamente eliminar el datafile que le pertenece, otra ventaja sobre un tablespace de Oracle que no elimina datafiles.
Otra ventajilla de un tablespace Falcon, es que su datafile incluye al igual que los demas motores de almacenamiento de Mysql (exceptuando Myisam), los indices y la data de una tabla dentro del mismo archivo. Esto, muchos DBA Oracle piensan que es una desventaja, ya que se tiene la creencia por ley que los indices deben estar en otro HD distinto a la data, y esto debe ser asi en Oracle u otra DB relacional, pero no en Mysql. La razon? la siguiente :
Oracle lee alternadamente 1 indice, 1 data, 1 indice, 1 data dentro de sus archivos. Si los indices y la data se encuentran en el mismo HD, imaginen la presion que esto causaria al HD y la banda ancha en si.
Mysql con Falcon, al tener indices y data en 1 solo archivo, lee de antemano primero todos los indices y luego la data no lee alternadamente como lo hace Oracle en 2 archivos distintos, sino que lee 1 solo primero todos los indices, y luego toda la data, lo cual arregla este problemita de saturamiento de lectura por el cual hay que separar indices y data en 2 HD distintos.
El motor de almacenamiento Falcon solo viene disponible en Mysql 6.x. Para crear un tablespace usamos :
mysql> create tablespace fulano
add datafile 'fulano.fts'
engine = falcon;
Con esto creamos 1 nuevo tablespace con 1 datafile llamado fulano.fts, podemos verificar en el diccionario de metadata de Mysql sobre la existencias de todos nuestros tablespaces en la DB, pero si nuestro tablespace en cuestion no tiene aun objetos guardados (una tabla), no aparecera a la hora que hagamos :
mysql> select * from information_schema.falcon_tables;
Hasta el momento no se soporta agregar mas datafiles a un tablespace, aunque en un futuro la pretension existe. Ya creado nuestro tablespace fulano, creamos una tabla con el mismo motor de almacenamiento y le asignamos su respectivo tablespace.
mysql> create table prueba ( nombres char(20), apellidos char(20)) engine = falcon tablespace fulano;
Ahora que existe un objeto real en el datafile fulano.fts podemos verificar la existencia de dicho tablespace :
mysql> select * from information_schema.falcon_tables;
Para eliminar un tablespace existente, debemos tener claro que no debe contener ningun objeto, de lo contrario no podremos eliminarlo y nos dara error. Para borrar un tablespace hacemos :
mysql> drop tablespace fulano engine = falcon;
Un Saludo :)
Suscribirse a:
Entradas (Atom)
