«Un nuevo tutorial que muestra cómo configurar un servidor CentOS 5.2, que ofrezca todos los servicios necesarios para un ISP y alojamiento web: servidor web Apache (con SSL), servidor de correo Postfix con SMTP-AUTH y TLS, servidor DNS con BIND, servidor FTP con Proftpd, servidor MySQL, Dovecot POP3/IMAP, Quota, Firewall, etc. El tutorial está escrito para la versión de 32 bits de CentOS 5.2, pero debería poder aplicarse igualmente a la versión de 64 bits con muy pocos cambios.»
http://www.howtoforge.com/perfect-server-centos-5.2
martes, 12 de agosto de 2008
Actualizar el kernel a partir de paquetes RPM
¿Es conveniente actualizar el Kernel? Si. La utilidad de actualizar un Kernel consiste en contar con soporte para un mayor número de dispositivos de hardware, pero principalmente por los parches de seguridad y mejoras que la actualización incluya.
El método tradicional consiste en descargar el código fuente desde http://www.kernel.org y configurar las opciones deseadas, compilarlo e instalarlo uno mismo. Ciertamente esto permite un mayor control sobre las características deseadas, pero puede resultar un procedimiento algo complejo para un usuario novicio. Lo más sensato que puede hacer un usuario recién ingresado al mundo de GNU/Linux utilizando alguna distribución basada sobre Red Hat™ Linux, consiste en utilizar los paquetes pre-compilados.
Procedimientos para Fedora™ Core
Si usted utiliza Fedora™ Core 1, olvidese de preocupaciones (y del resto de este documento) puesto que puede limitarse a ejecutar un solo mandato que se hará cargo de actualizar el kernel si así se requiere (con todo lo que también sea necesario):
yum update
Acto seguido, reinicie sistema para poder utilizar el kernel recién instalado.
Procedimientos para otras distribuciones que utilizan RPM
Determinemos que versión del kernel se tiene instalado preguntándole al sistema con el siguiente mandato:
rpm -q kernel
Lo cual debe devolver algo como lo siguiente:
kernel-kernel-2.4.18-3
Diríjase con el explorador web de su preferencia al ftp de las distribución que posea y compare la versión del Kernel que encontrará en la carpeta de actualizaciones correspondiente a la versión que posea. Para las distribuciones basadas fielmente sobre Red Hat™ Linux, puede acceder a las siguientes direcciones:
ftp://updates.redhat.com/9/ o http://updates.redhat.com/9/, si posee alguna distribución basada sobre Red Hat Linux 9
Dentro de cada una encontrará un directorio i386, donde se encuentra la paquetería que puede instalarse en maquinas con cualquier microprocesador de arquitectura 80386, 80486, 80586 y 80686. Descargue los siguiente paquetes:
kernel-x.x.xx-xx.i386.rpm (si su equipo tiene microprocesador 80386 y 80486)
kernel-doc-x.x.xx-xx.i386.rpm
kernel-source-x.x.xx-xx.i386.rpm (opcional)
En el subdirectorio i586 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i586.rpm, optimizado para microprocesadores 80586, como AMD K5, K6, K6-II y K6-III y Pentium, Pentium MMX y Pentium Pro, y el paquete kernel-smp-x.x.xx-xx.i586.rpm, para maquinas que utilizan múltiples microprocesadores 80586. En el subdirectorio i686 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i686.rpm, optimizado para microprocesadores 80686, como los Celeron, Pentium II y Pentium III, y el paquete kernel-smp-x.x.xx-xx.i686.rpm, para maquinas que utilizan múltiples microprocesadores 80686.
Lo siguiente será crear un disquete de arranque con el kernel actual y que será de utilidad en caso de presentarse alguna complicación para poder arrancar el sistema. Éste puede generarse introduciendo un disquete, sin montarlo, en la unidad de 3œ pulgadas y ejecutando lo siguiente:
mkbootdisk --device /dev/fd0 [número de versión del kernel actual]
Suponiendo que se tiene instalado el kernel versión 2.4.20-8, incluido en Red Hat Linux 9, quedaría del siguiente modo:
/sbin/mkbootdisk 2.4.20-8 --device /dev/fd0
A continuación procederemos a probar dicho disquete, solo como una precaución. Déjelo insertado y reinicie el equipo.
Coloque todos los paquetes que descargó en el mismo directorio, y ejecute el siguiente mandato:
rpm -Fvh kernel-*.rpm
NOTA: No ponga en le mismo directorio aquellos que no correspondan a la arquitectura de su microprocesador o que puedan ser sustituidos por otros optimizados para la arquitectura de su microprocesador, es decir, por ejemplo, no se pongan kernel-2.4.20-28.9.i386.rpm y kernel-2.4.20-28.9.i586.rpm si se va a actualizar con el paquete kernel-2.4.20-28.9.i686.rpm, o recibirá errores de conflictos debido a paquetes iguales y no podrá instalar.
Gracias a que las distribuciones actuales utilizan Grub en lugar de Lilo, ya no es necesario editar fichero de configuración alguno ni ejecutar mandato alguno adicional.
Reinicie la máquina y compruebe que todo carga correctamente. Para mayor seguridad, ejecute el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos del nuevo kernel:
/sbin/depmod -a
Si todo funcionó correctamente, genere un disquete de arranque con el nuevo kernel para futuras emergencias, del mismo modo que lo hizo para el kernel anterior.
/sbin/mkbootdisk 2.4.20-28.9 --device /dev/fd0
Si se tenían módulos para dispositivos de hardware, como serían el módulo de kernel para tarjetas NVIDIA, o bien funciones adicionales, y estos fueron compilados con las cabeceras del kernel anterior, será necesario volver a compilar estos módulos a fin de hacerlos funcionar con el nuevo kernel. Asegúrese de que el enlace simbólico /usr/src/linux apunta realmente al directorio que contenga el código fuente del kernel actual, y verifique que el tipo de microprocesador y si hay multiprocesamiento simétrico están correctamente especificados en /usr/src/linux/.config -utilice make xconfig y será más sencillo- así como también el soporte para módulos experimentales de ser necesario.
Si necesita recompilar el kernel por alguna razón, el siguiente es el resumen de procedimientos:
cd /usr/src/linux/
make menuconfig
make dep
make clean
make bzImage
make install
make modules
make modules_install
Debe ejecutarse el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos.
/sbin/depmod -a
El método tradicional consiste en descargar el código fuente desde http://www.kernel.org y configurar las opciones deseadas, compilarlo e instalarlo uno mismo. Ciertamente esto permite un mayor control sobre las características deseadas, pero puede resultar un procedimiento algo complejo para un usuario novicio. Lo más sensato que puede hacer un usuario recién ingresado al mundo de GNU/Linux utilizando alguna distribución basada sobre Red Hat™ Linux, consiste en utilizar los paquetes pre-compilados.
Procedimientos para Fedora™ Core
Si usted utiliza Fedora™ Core 1, olvidese de preocupaciones (y del resto de este documento) puesto que puede limitarse a ejecutar un solo mandato que se hará cargo de actualizar el kernel si así se requiere (con todo lo que también sea necesario):
yum update
Acto seguido, reinicie sistema para poder utilizar el kernel recién instalado.
Procedimientos para otras distribuciones que utilizan RPM
Determinemos que versión del kernel se tiene instalado preguntándole al sistema con el siguiente mandato:
rpm -q kernel
Lo cual debe devolver algo como lo siguiente:
kernel-kernel-2.4.18-3
Diríjase con el explorador web de su preferencia al ftp de las distribución que posea y compare la versión del Kernel que encontrará en la carpeta de actualizaciones correspondiente a la versión que posea. Para las distribuciones basadas fielmente sobre Red Hat™ Linux, puede acceder a las siguientes direcciones:
ftp://updates.redhat.com/9/ o http://updates.redhat.com/9/, si posee alguna distribución basada sobre Red Hat Linux 9
Dentro de cada una encontrará un directorio i386, donde se encuentra la paquetería que puede instalarse en maquinas con cualquier microprocesador de arquitectura 80386, 80486, 80586 y 80686. Descargue los siguiente paquetes:
kernel-x.x.xx-xx.i386.rpm (si su equipo tiene microprocesador 80386 y 80486)
kernel-doc-x.x.xx-xx.i386.rpm
kernel-source-x.x.xx-xx.i386.rpm (opcional)
En el subdirectorio i586 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i586.rpm, optimizado para microprocesadores 80586, como AMD K5, K6, K6-II y K6-III y Pentium, Pentium MMX y Pentium Pro, y el paquete kernel-smp-x.x.xx-xx.i586.rpm, para maquinas que utilizan múltiples microprocesadores 80586. En el subdirectorio i686 encontrará dos paquetes, el paquete kernel-x.x.xx-xx.i686.rpm, optimizado para microprocesadores 80686, como los Celeron, Pentium II y Pentium III, y el paquete kernel-smp-x.x.xx-xx.i686.rpm, para maquinas que utilizan múltiples microprocesadores 80686.
Lo siguiente será crear un disquete de arranque con el kernel actual y que será de utilidad en caso de presentarse alguna complicación para poder arrancar el sistema. Éste puede generarse introduciendo un disquete, sin montarlo, en la unidad de 3œ pulgadas y ejecutando lo siguiente:
mkbootdisk --device /dev/fd0 [número de versión del kernel actual]
Suponiendo que se tiene instalado el kernel versión 2.4.20-8, incluido en Red Hat Linux 9, quedaría del siguiente modo:
/sbin/mkbootdisk 2.4.20-8 --device /dev/fd0
A continuación procederemos a probar dicho disquete, solo como una precaución. Déjelo insertado y reinicie el equipo.
Coloque todos los paquetes que descargó en el mismo directorio, y ejecute el siguiente mandato:
rpm -Fvh kernel-*.rpm
NOTA: No ponga en le mismo directorio aquellos que no correspondan a la arquitectura de su microprocesador o que puedan ser sustituidos por otros optimizados para la arquitectura de su microprocesador, es decir, por ejemplo, no se pongan kernel-2.4.20-28.9.i386.rpm y kernel-2.4.20-28.9.i586.rpm si se va a actualizar con el paquete kernel-2.4.20-28.9.i686.rpm, o recibirá errores de conflictos debido a paquetes iguales y no podrá instalar.
Gracias a que las distribuciones actuales utilizan Grub en lugar de Lilo, ya no es necesario editar fichero de configuración alguno ni ejecutar mandato alguno adicional.
Reinicie la máquina y compruebe que todo carga correctamente. Para mayor seguridad, ejecute el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos del nuevo kernel:
/sbin/depmod -a
Si todo funcionó correctamente, genere un disquete de arranque con el nuevo kernel para futuras emergencias, del mismo modo que lo hizo para el kernel anterior.
/sbin/mkbootdisk 2.4.20-28.9 --device /dev/fd0
Si se tenían módulos para dispositivos de hardware, como serían el módulo de kernel para tarjetas NVIDIA, o bien funciones adicionales, y estos fueron compilados con las cabeceras del kernel anterior, será necesario volver a compilar estos módulos a fin de hacerlos funcionar con el nuevo kernel. Asegúrese de que el enlace simbólico /usr/src/linux apunta realmente al directorio que contenga el código fuente del kernel actual, y verifique que el tipo de microprocesador y si hay multiprocesamiento simétrico están correctamente especificados en /usr/src/linux/.config -utilice make xconfig y será más sencillo- así como también el soporte para módulos experimentales de ser necesario.
Si necesita recompilar el kernel por alguna razón, el siguiente es el resumen de procedimientos:
cd /usr/src/linux/
make menuconfig
make dep
make clean
make bzImage
make install
make modules
make modules_install
Debe ejecutarse el siguiente mandato inmediatamente después de reiniciar el sistema a fin de calcular las dependencias entre los módulos.
/sbin/depmod -a
Actualizacion, Instalacion y Desinstalacion de software Linux
Una vez que ya ha experimentado con algunos de los mandatos básicos, se encontrará ahora con una pregunta: ¿Cómo actualizo, instalo o desinstalo software? Existen varios métodos que dependerán del formato utilizado para empaquetar los programas. Este documento le proporcionará la descripción de los posibles métodos y algunos ejemplos. Por favor siga el procedimiento al pie de la letra.
La parte teórica.
Antes de continuar, es indispensable se conozca primero el uso y el porque de cada método existente para el manejo del software. De esto se dependerá en adelante para mantener un saludable estado de cualquier sistema GNU/Linux®. Indistintamente del método, todos se deberá de realizar desde la cuenta de root, así que proceda con cuidado.
Manejo de paquetes a partir de archivos RPM®
El formato RPM® es el más utilizado en la actualidad. Tiene como ventaja principal el encargarse de verificar las posibles dependencias o requisitos para la instalación o actualización de un paquete en particular, así como también el verificar si el paquete que se procederá a desinstalar es requerido por otros paquetes presentes en el sistema.
Analizaremos entonces el uso del mandato rpm. Existen dos aplicaciones en el entorno gráfico que utilizan rpm en el trasfondo y que son de muy fácil utilización, son gnorpm y kpackage. Sin embargo es importante que el usuario novicio se familiarice con este mandato para poder entender el funcionamiento de las mencionadas aplicaciones en el entorno gráfico.
Sintaxis
rpm -[opciones] paquete.rpmNos limitaremos a abordar solo las opciones más comúnes que un nuevo usuario de Linux® podría necesitar. Si desea ver una descripción completa de las posibles opciones del mandato rpm, consulte el manual escribiendo man rpm en cualquier terminal o consola.
Instalación binarios contenidos en paquetes con formato RPM®.
Los paquetes de este tipo son programas previamente compilados, almacenados y listos para ser instalados en el sistema. Estos paquetes pueden tener las extensiones .i386.rpm para PC compatible con al menos un microprocesador 80386, es decir, cualquier PC de arquitectura Intel® o compatible, .i486.rpm para PC compatible un microprocesador 80486, .i586.rpm para PC compatible con microprocesador 80586, .i686.rpm para PC compatible con microprocesador 80686, .ppc.rpm para Machintosh® PowerPC o .noarch.rpm que puede utilizarse en cualquier arquitectura.
En la práctica, no se preocupe por encontrar paquetes i686 para su PC con microprocesador Intel Pentium III, puede instalar con total seguridad los paquetes para i386. Los paquetes noarch generalmente contiene archivos de texto -guiones para diversas funciones, archivos de configuración o documentación-, imágenes, sonidos, etc., es decir, archivos que trabajan indistintamente en uno u otro sistema.
La sintaxis que se sugiere utilizar en la mayoría de los casos para instalar o actualizar paquetería es la siguiente:
rpm -Uvh paquete.i386.rpmEl utilizar la opción U, que significa Update, a fin de conseguir un proceso limpio, hace que primero se consulte la base de datos de la paquetería instalada, procediendo a desinstalar a continuación la versión anterior e instalando la nueva. Aunque también puede utilizarse la opción i, que significa install, esta no continuará el proceso si existiese en el sistema una versión anterior de dicho paquete.
Desinstalación binarios contenidos en paquetes con formato RPM®.
rpm -e paqueteNo requiere especificar el número de versión ni la extensión ya que consulta directamente la base de datos de la paquetería instalada en le sistema y procederá a desinstalar el paquete que lleve dicho nombre.
Instalación a partir de código fuente contenido en paquetes con formato RPM®.
Este procedimiento se aplica a los paquetes denominados SRPM, sobre los cuales seguramente ha leído en los foros y grupos d discusión, y requiere que se encuentren instalados en el sistema los paquetes de desarrollo -los paquetes contenidos en el CDROM de instalación que llevan "-devel-" en el nombre-, ya que el procedimiento implica que se realizará la compilación de programas.
La ventaja que tiene la construcción e instalación paquetería a partir de archivos SRPM es que los paquetes resultantes quedan compilados de forma especial para el sistema Linux® que tengamos instalado. Es de particular ayuda cuando se actualiza, por citar un ejemplo, de LinuxPPP® 5.x a LinuxPPP® 6.x y el usuario se topa con que alguna de sus aplicaciones favoritas simplemente ya no funcionan. Esto se debe a que la diferencia entre las versiones de las bibliotecas compartidas entre una y otra versión de LinuxPPP puede ser demasiada. Las distribuciones basadas sobre Red Hat™ Linux 5.x utilizan, entre otras cosas, libc5, en tanto que las versiones basadas sobre Red Hat™ 6.x hacen uso de Glibc-2.1.x y las versiones basadas sobre Red Hat™ 7.x hacen uso de Glibc-2.2.x.
Estos paquetes SRPM tienen la extensión .src.rpm y se procede sobre estos del siguiente modo:
rpmbuild --rebuild --clean paquete.src.rpmEsta última línea de mandato coloca un paquete comprimido, normalmente un archivo con extensión .tar.gz o tar.bz2, en /usr/src/redhat/SOURCES y un archivo, conocido como spec, con las especificaciones del paquete en /usr/src/redhat/SPECS. A continuación se descomprime el archivo .tar.gz o tar.bz2 y se inicia la compilación y construcción del paquete RPM® con las especificaciones del spec.
Si al terminar el proceso en la última línea se obtiene + exit 0, solo restará instalar o actualizar con el paquete RPM® que ahora encontraremos, dependiendo de la arquitectura para la que se compiló, en alguno de los subdirectorios de /usr/src/redhat/RPMS.
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmConfirmación de la existencia de paquetería en particular en el sistema.
En ocasiones es posible que se encuentre en una situación como esta: usted encuentra en algún sitio de Internet un paquete RPM® del cual se hablan maravillas en la descripción, pero desconoce si ya lo tendrá instalado, o si ya tiene una versión más reciente; podría averiguarlo descargando dicho paquete, que quizá tenga varios Mega-bytes en tamaño, utilizando una lenta conexión de modem y probando con la línea de mandato rpm -Uvh. Si resultó un paquete más reciente que el que usted tenía, habrán valido la pena los 10-15 minutos invertidos en descargar dicho paquete, pero si ya lo tenía instalado o bien se trataba de una versión anterior, usted desearía haber sabido que podía utilizar la siguiente línea de mandato:
rpm -q nombre_del_paquete_sin_número_de_versiónLa correspondiente salida de esto nos dirá si el paquete se encuentra o no instalado y el número de versión.
Si nos interesa examinar la información sobre algún paquete instalado en el sistema, utilizamos la siguiente línea de mandato:
rpm -qi nombre_del_paquete_sin_número_de_versiónLo anterior devuelve los detalles informativos respecto al paquete instalado.
Si queremos examinar dicha información pero en un paquete no instalado en el sistema, solo hace falta añadir p, que implica que nos referiremos a un paquete, en las opciones del mandato del modo siguiente:
rpm -qpi --clean cualquier_paquete_que_haya_descargado.i386.rpmVerificación de firmas de paquetes RPM®.
Por cuestiones de seguridad, si usted descarga un paquete RPM® desde un sitio Web o servidor FTP distinto al oficial de la distribución o conjunto de paquetes que utilice, lo más saludable será verificar dicho paquete. JAMÁS descargue e instale paquetes de binarios desde sitios Web dedicados a actividades ilegales o de dudosa reputación.
Por si acaso, utilice la siguiente línea de mandato para verificar las firmas incluidas en paquetes antes de proceder a instalarlos:
rpm -Kv paquete.i386.rpmEsto debe darle la siguiente salida, donde las x corresponden a la firma PGP de la persona que construyó el paquete:
paquete.i386.rpm:
MD5 sum OK: xxxxxxxxxxxxxxxxxxxxxCompare la firma PGP con la del empaquetador, misma que debe corresponder con la que este proporcione en el sitio Web desde donde descargue dicho paquete.
Instalación de paquetes a partir de paquetes .tar.gz o .tar.bz2.
Este el el método universal para todas las distribuciones de GNU/Linux® ya que funciona tanto en distribuciones basadas sobre Red Hat, como Debian, Stampede o Slackware. Debido a que no se guarda un registro sobre lo que se tiene instalado y lo que no, conviene, en le caso de distribuciones basadas sobre Red Hat™ Linux, dejar las carpetas resultantes con el código fuente en /usr/src/redhat/BUILD para tener una referencia y evitar romper las posibles dependencias entre los distintos paquetes.
La mayoría de estos paquetes, denominados tarballs, vienen con extensión .tar.gz o tar.bz2. Lo primero será copiarlos en la carpeta /usr/src/redhat/SOURCES y lo siguiente consiste en descomprimir estos con la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/paquete.tar.gz /usr/src/redhat/BUILD/Después acceda al interior de la carpeta resultante:
cd /usr/src/redhat/BUILD/paqueteEs necesario que lea la documentación que acompaña a dicho paquete y seguir las instrucciones proporcionadas por el autor. Por lo general son necesarios al menos tres pasos:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make install
make cleanAlgunos paquetes de binarios propietarios, como OpenOffice.org, incluyen documentación y un instructivo que detalla la instalación. OpenOffice.org requiere se ejecute el binario setup, con la opción /net si va ser utilizado por varios usuarios, contenido en la sub-carpeta bin.
cd /usr/src/redhat/BUILD/openoffice
./setup /netEn la mayoría de los casos, como ocurre con los programas con licencia GPL que se distribuyen como códigos fuentes, necesitará ejecutar algunos mandatos como se muestra a continuación:
Compilación desde código fuente.
./configure
Este prepara el Makefile y configura las opciones de compilación, mismas que en algunos casos pueden resultar demasiado complejas para un usuario novicio. Además de verifica si el sistema posee las bibliotecas de desarrollo necesarias para la compilación.
make
Este es el que realiza la compilación del código fuente. El procesos puede durar varios minutos.
make install
Este se encarga de realizar la instalación del los binarios y módulos compilados en los lugares correctos.
make clean
Opcionalmente podemos utilizar este mandato para limpiar los remanentes que se originaron por la compilación a fin de recuperar espacio en el disco duro.
Si por alguna razón necesita desinstalar el programa resultante, puede utilizar make uninstall.
En el mejor de los casos, si el tarball contiene un archivo spec, puede construirse un paquete RPM® de modo muy similar a la compilación e instalación desde paquetes SRPMS.
Solo requiere ejecutar la siguiente línea de mandato:
rpm -tb --clean paquete.tar.gzY, si obtuvimos en la última línea del proceso un + exit 0, finalmente podremos disponer de el paquete resultante:
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmEjercicios.
Antes de empezar, es necesario, si no lo ha hecho, instalar los paquetes de bibliotecas de desarrollo incluidas en el CDROM de instalación de la distribución que posea. Puede utilizar rpm -Uvh *-devel-*.
Instalación y desinstalación de un paquete RPM®
Instale firestarter-x.x.x-x.i586.rpm con la siguiente línea mandato:
rpm -Uvh firestarter-*.i586.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde un SRPM.
Ejecute el siguiente mandato:
rpmbuild --rebuild --clean firestarter-*.src.rpmEspere unos minutos, y si recibe en la última línea una salida +exit 0, cambie al directorio conde quedó el paquete RPM® de binarios:
cd /usr/src/redhat/RPMS/i386 ; lsInstale el RPM® resultante con la siguiente línea de mandato:
rpm -Uvh firestarter-*.i386.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde código fuente -tarball-.
Abra una terminal o consola.
Instale este paquete, que contiene un código fuente, con la siguiente línea de mandato.
rpm -Uvh firestarter-*.src.rpmRevise el contenido de los siguientes directorios, ya que en estos encontrará un par de archivos nuevos:
cd /usr/src/redhat/SPECS ; lsEn este encontrará un archivo llamado firestarter.spec
cd /usr/src/redhat/SOURCES ; lsEn este otro encontrará firestarter-0.8.2.tar.gz
Descomprima firestarter-0.8.2.tar.gz utilizando la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/firestarter-0.8.2.tar.gz /usr/src/redhat/BUILDComo resultado, ahora tendremos una carpeta firestarter-0.8.2.
Cambie al directorio /usr/src/redhat/BUILD/firestarter-0.8.2:
cd /usr/src/redhat/BUILD/firestarter-0.8.2Ejecute el siguiente mandato y observe los mensajes que aparecerán en pantalla:
./configureEjecute el siguiente mandato para iniciar la compilación, espere algunos minutos para que completen todos los procesos y observe los mensajes que aparecerán en pantalla, sobretodo asegurándose que la última línea se lea + exit 0:
makeEjecute el siguiente mandato a fin de instalar el programa que acaba de compilar:
make installEjecute el siguiente mandato para comprobar que ha concluído exitosamente la primera parte del ejercicio,, invocando a firestarter, un programa de correo electrónico:
firestarterProceda a desinstalar firestarter:
make uninstallFinalmente, a fin de recuperar algo de espacio en disco duro, procederemos a limpiar los módulos y binarios creados dentro de /usr/src/redhat/BUILD/firestarter-0.8.2
make clean
La parte teórica.
Antes de continuar, es indispensable se conozca primero el uso y el porque de cada método existente para el manejo del software. De esto se dependerá en adelante para mantener un saludable estado de cualquier sistema GNU/Linux®. Indistintamente del método, todos se deberá de realizar desde la cuenta de root, así que proceda con cuidado.
Manejo de paquetes a partir de archivos RPM®
El formato RPM® es el más utilizado en la actualidad. Tiene como ventaja principal el encargarse de verificar las posibles dependencias o requisitos para la instalación o actualización de un paquete en particular, así como también el verificar si el paquete que se procederá a desinstalar es requerido por otros paquetes presentes en el sistema.
Analizaremos entonces el uso del mandato rpm. Existen dos aplicaciones en el entorno gráfico que utilizan rpm en el trasfondo y que son de muy fácil utilización, son gnorpm y kpackage. Sin embargo es importante que el usuario novicio se familiarice con este mandato para poder entender el funcionamiento de las mencionadas aplicaciones en el entorno gráfico.
Sintaxis
rpm -[opciones] paquete.rpmNos limitaremos a abordar solo las opciones más comúnes que un nuevo usuario de Linux® podría necesitar. Si desea ver una descripción completa de las posibles opciones del mandato rpm, consulte el manual escribiendo man rpm en cualquier terminal o consola.
Instalación binarios contenidos en paquetes con formato RPM®.
Los paquetes de este tipo son programas previamente compilados, almacenados y listos para ser instalados en el sistema. Estos paquetes pueden tener las extensiones .i386.rpm para PC compatible con al menos un microprocesador 80386, es decir, cualquier PC de arquitectura Intel® o compatible, .i486.rpm para PC compatible un microprocesador 80486, .i586.rpm para PC compatible con microprocesador 80586, .i686.rpm para PC compatible con microprocesador 80686, .ppc.rpm para Machintosh® PowerPC o .noarch.rpm que puede utilizarse en cualquier arquitectura.
En la práctica, no se preocupe por encontrar paquetes i686 para su PC con microprocesador Intel Pentium III, puede instalar con total seguridad los paquetes para i386. Los paquetes noarch generalmente contiene archivos de texto -guiones para diversas funciones, archivos de configuración o documentación-, imágenes, sonidos, etc., es decir, archivos que trabajan indistintamente en uno u otro sistema.
La sintaxis que se sugiere utilizar en la mayoría de los casos para instalar o actualizar paquetería es la siguiente:
rpm -Uvh paquete.i386.rpmEl utilizar la opción U, que significa Update, a fin de conseguir un proceso limpio, hace que primero se consulte la base de datos de la paquetería instalada, procediendo a desinstalar a continuación la versión anterior e instalando la nueva. Aunque también puede utilizarse la opción i, que significa install, esta no continuará el proceso si existiese en el sistema una versión anterior de dicho paquete.
Desinstalación binarios contenidos en paquetes con formato RPM®.
rpm -e paqueteNo requiere especificar el número de versión ni la extensión ya que consulta directamente la base de datos de la paquetería instalada en le sistema y procederá a desinstalar el paquete que lleve dicho nombre.
Instalación a partir de código fuente contenido en paquetes con formato RPM®.
Este procedimiento se aplica a los paquetes denominados SRPM, sobre los cuales seguramente ha leído en los foros y grupos d discusión, y requiere que se encuentren instalados en el sistema los paquetes de desarrollo -los paquetes contenidos en el CDROM de instalación que llevan "-devel-" en el nombre-, ya que el procedimiento implica que se realizará la compilación de programas.
La ventaja que tiene la construcción e instalación paquetería a partir de archivos SRPM es que los paquetes resultantes quedan compilados de forma especial para el sistema Linux® que tengamos instalado. Es de particular ayuda cuando se actualiza, por citar un ejemplo, de LinuxPPP® 5.x a LinuxPPP® 6.x y el usuario se topa con que alguna de sus aplicaciones favoritas simplemente ya no funcionan. Esto se debe a que la diferencia entre las versiones de las bibliotecas compartidas entre una y otra versión de LinuxPPP puede ser demasiada. Las distribuciones basadas sobre Red Hat™ Linux 5.x utilizan, entre otras cosas, libc5, en tanto que las versiones basadas sobre Red Hat™ 6.x hacen uso de Glibc-2.1.x y las versiones basadas sobre Red Hat™ 7.x hacen uso de Glibc-2.2.x.
Estos paquetes SRPM tienen la extensión .src.rpm y se procede sobre estos del siguiente modo:
rpmbuild --rebuild --clean paquete.src.rpmEsta última línea de mandato coloca un paquete comprimido, normalmente un archivo con extensión .tar.gz o tar.bz2, en /usr/src/redhat/SOURCES y un archivo, conocido como spec, con las especificaciones del paquete en /usr/src/redhat/SPECS. A continuación se descomprime el archivo .tar.gz o tar.bz2 y se inicia la compilación y construcción del paquete RPM® con las especificaciones del spec.
Si al terminar el proceso en la última línea se obtiene + exit 0, solo restará instalar o actualizar con el paquete RPM® que ahora encontraremos, dependiendo de la arquitectura para la que se compiló, en alguno de los subdirectorios de /usr/src/redhat/RPMS.
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmConfirmación de la existencia de paquetería en particular en el sistema.
En ocasiones es posible que se encuentre en una situación como esta: usted encuentra en algún sitio de Internet un paquete RPM® del cual se hablan maravillas en la descripción, pero desconoce si ya lo tendrá instalado, o si ya tiene una versión más reciente; podría averiguarlo descargando dicho paquete, que quizá tenga varios Mega-bytes en tamaño, utilizando una lenta conexión de modem y probando con la línea de mandato rpm -Uvh. Si resultó un paquete más reciente que el que usted tenía, habrán valido la pena los 10-15 minutos invertidos en descargar dicho paquete, pero si ya lo tenía instalado o bien se trataba de una versión anterior, usted desearía haber sabido que podía utilizar la siguiente línea de mandato:
rpm -q nombre_del_paquete_sin_número_de_versiónLa correspondiente salida de esto nos dirá si el paquete se encuentra o no instalado y el número de versión.
Si nos interesa examinar la información sobre algún paquete instalado en el sistema, utilizamos la siguiente línea de mandato:
rpm -qi nombre_del_paquete_sin_número_de_versiónLo anterior devuelve los detalles informativos respecto al paquete instalado.
Si queremos examinar dicha información pero en un paquete no instalado en el sistema, solo hace falta añadir p, que implica que nos referiremos a un paquete, en las opciones del mandato del modo siguiente:
rpm -qpi --clean cualquier_paquete_que_haya_descargado.i386.rpmVerificación de firmas de paquetes RPM®.
Por cuestiones de seguridad, si usted descarga un paquete RPM® desde un sitio Web o servidor FTP distinto al oficial de la distribución o conjunto de paquetes que utilice, lo más saludable será verificar dicho paquete. JAMÁS descargue e instale paquetes de binarios desde sitios Web dedicados a actividades ilegales o de dudosa reputación.
Por si acaso, utilice la siguiente línea de mandato para verificar las firmas incluidas en paquetes antes de proceder a instalarlos:
rpm -Kv paquete.i386.rpmEsto debe darle la siguiente salida, donde las x corresponden a la firma PGP de la persona que construyó el paquete:
paquete.i386.rpm:
MD5 sum OK: xxxxxxxxxxxxxxxxxxxxxCompare la firma PGP con la del empaquetador, misma que debe corresponder con la que este proporcione en el sitio Web desde donde descargue dicho paquete.
Instalación de paquetes a partir de paquetes .tar.gz o .tar.bz2.
Este el el método universal para todas las distribuciones de GNU/Linux® ya que funciona tanto en distribuciones basadas sobre Red Hat, como Debian, Stampede o Slackware. Debido a que no se guarda un registro sobre lo que se tiene instalado y lo que no, conviene, en le caso de distribuciones basadas sobre Red Hat™ Linux, dejar las carpetas resultantes con el código fuente en /usr/src/redhat/BUILD para tener una referencia y evitar romper las posibles dependencias entre los distintos paquetes.
La mayoría de estos paquetes, denominados tarballs, vienen con extensión .tar.gz o tar.bz2. Lo primero será copiarlos en la carpeta /usr/src/redhat/SOURCES y lo siguiente consiste en descomprimir estos con la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/paquete.tar.gz /usr/src/redhat/BUILD/Después acceda al interior de la carpeta resultante:
cd /usr/src/redhat/BUILD/paqueteEs necesario que lea la documentación que acompaña a dicho paquete y seguir las instrucciones proporcionadas por el autor. Por lo general son necesarios al menos tres pasos:
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make
make install
make cleanAlgunos paquetes de binarios propietarios, como OpenOffice.org, incluyen documentación y un instructivo que detalla la instalación. OpenOffice.org requiere se ejecute el binario setup, con la opción /net si va ser utilizado por varios usuarios, contenido en la sub-carpeta bin.
cd /usr/src/redhat/BUILD/openoffice
./setup /netEn la mayoría de los casos, como ocurre con los programas con licencia GPL que se distribuyen como códigos fuentes, necesitará ejecutar algunos mandatos como se muestra a continuación:
Compilación desde código fuente.
./configure
Este prepara el Makefile y configura las opciones de compilación, mismas que en algunos casos pueden resultar demasiado complejas para un usuario novicio. Además de verifica si el sistema posee las bibliotecas de desarrollo necesarias para la compilación.
make
Este es el que realiza la compilación del código fuente. El procesos puede durar varios minutos.
make install
Este se encarga de realizar la instalación del los binarios y módulos compilados en los lugares correctos.
make clean
Opcionalmente podemos utilizar este mandato para limpiar los remanentes que se originaron por la compilación a fin de recuperar espacio en el disco duro.
Si por alguna razón necesita desinstalar el programa resultante, puede utilizar make uninstall.
En el mejor de los casos, si el tarball contiene un archivo spec, puede construirse un paquete RPM® de modo muy similar a la compilación e instalación desde paquetes SRPMS.
Solo requiere ejecutar la siguiente línea de mandato:
rpm -tb --clean paquete.tar.gzY, si obtuvimos en la última línea del proceso un + exit 0, finalmente podremos disponer de el paquete resultante:
rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpmEjercicios.
Antes de empezar, es necesario, si no lo ha hecho, instalar los paquetes de bibliotecas de desarrollo incluidas en el CDROM de instalación de la distribución que posea. Puede utilizar rpm -Uvh *-devel-*.
Instalación y desinstalación de un paquete RPM®
Instale firestarter-x.x.x-x.i586.rpm con la siguiente línea mandato:
rpm -Uvh firestarter-*.i586.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde un SRPM.
Ejecute el siguiente mandato:
rpmbuild --rebuild --clean firestarter-*.src.rpmEspere unos minutos, y si recibe en la última línea una salida +exit 0, cambie al directorio conde quedó el paquete RPM® de binarios:
cd /usr/src/redhat/RPMS/i386 ; lsInstale el RPM® resultante con la siguiente línea de mandato:
rpm -Uvh firestarter-*.i386.rpmEjecute el programa que acaba de instalar ejecutando firestarter
Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida
rpm -q firestarterProceda ahora a desinstalar el programa con la siguiente línea de mandato:
rpm -e firestarter
Compilación e instalación desde código fuente -tarball-.
Abra una terminal o consola.
Instale este paquete, que contiene un código fuente, con la siguiente línea de mandato.
rpm -Uvh firestarter-*.src.rpmRevise el contenido de los siguientes directorios, ya que en estos encontrará un par de archivos nuevos:
cd /usr/src/redhat/SPECS ; lsEn este encontrará un archivo llamado firestarter.spec
cd /usr/src/redhat/SOURCES ; lsEn este otro encontrará firestarter-0.8.2.tar.gz
Descomprima firestarter-0.8.2.tar.gz utilizando la siguiente línea de mandato:
tar -zxvf /usr/src/redhat/SOURCES/firestarter-0.8.2.tar.gz /usr/src/redhat/BUILDComo resultado, ahora tendremos una carpeta firestarter-0.8.2.
Cambie al directorio /usr/src/redhat/BUILD/firestarter-0.8.2:
cd /usr/src/redhat/BUILD/firestarter-0.8.2Ejecute el siguiente mandato y observe los mensajes que aparecerán en pantalla:
./configureEjecute el siguiente mandato para iniciar la compilación, espere algunos minutos para que completen todos los procesos y observe los mensajes que aparecerán en pantalla, sobretodo asegurándose que la última línea se lea + exit 0:
makeEjecute el siguiente mandato a fin de instalar el programa que acaba de compilar:
make installEjecute el siguiente mandato para comprobar que ha concluído exitosamente la primera parte del ejercicio,, invocando a firestarter, un programa de correo electrónico:
firestarterProceda a desinstalar firestarter:
make uninstallFinalmente, a fin de recuperar algo de espacio en disco duro, procederemos a limpiar los módulos y binarios creados dentro de /usr/src/redhat/BUILD/firestarter-0.8.2
make clean
Configurando valores por defecto para el alta de cuentas.
Procedimientos.
Como root, edite /etc/default/useradd. Encontrará el siguiente contenido:
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
Puede cambiar lo valores que considere convenientes, como por ejemplo el intérprete de mandatos a utilizar para las nuevas cuentas que sean creadas en adelante. De modo predefinido el sistema asigna /bin/bash (BASH o Bourne Again Shell) como intérprete de mandatos, sin embargo lo cierto es que si el sistema se utilizará como servidor, lo más conveniente es que se asigne de modo predefinido /sbin/nologin el cual muestra un mensaje respecto a que la cuenta no está disponible y da salida, utilizándose regularmente como intérprete de mandatos de reemplazo para cuentas que han sido deshabilitadas o bien que no tiene porque acceder con intérprete de mandatos al sistema. Cambie SHELL=/bin/bash por SHELL=/sbin/nologin.
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/sbin/nologin
SKEL=/etc/skel
En adelante todo nuevo usuario que sea dado de alta en el sistema con el mandato useradd sin parámetro alguno, de modo predefinido no podrá acceder al sistema a través de shell, es decir acceso en terminal local o remotamente. Los usuarios con estas características podrán, sin embargo, utilizar cuentas de correo o Samba sin problema alguno.
De modo predefinido las cuentas de usuario del sistema utilizarán como molde al directorio /etc/skel para crear el directorio de inicio de todos los usuarios del sistema. Regularmente, y como mínimo, /etc/skel incluye lo siguiente:
.bash_logout .bash_profile .bashrc .gtkrc
Si, por ejemplo, se desea que cada cuenta de usuario incluya un subdirectorio para carpetas de correo y suscripción a éstas a través del servicio de IMAP, se debe realizar el siguiente procedimiento:
mkdir /etc/skel/mail/touch /etc/skel/mail/Borradorestouch /etc/skel/mail/Enviadostouch /etc/skel/mail/Papelera
Y finalmente generar con el editor de texto el fichero /etc/skel/.mailboxlist que sirve para guardar las suscripciones de carpetas de correo que serán utilizadas por el servicio de IMAP, utilizando el siguiente contenido:
mail/Borradoresmail/Enviadosmail/Papelera
Adicionalmente puede contribuir a transparentar la migración de escritorios de GNOME 1.x, 2.0 y 2.2 hacia versiones posteriores predefiniendo se genere el directorio ~/Desktop/ con un enlace simbólico apuntando hacia éste y el cual se denominará ~/.gnome-desktop/
cd /etc/skel/mkdir Desktopln -s Desktop .gnome-desktop
Como root, edite /etc/default/useradd. Encontrará el siguiente contenido:
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
Puede cambiar lo valores que considere convenientes, como por ejemplo el intérprete de mandatos a utilizar para las nuevas cuentas que sean creadas en adelante. De modo predefinido el sistema asigna /bin/bash (BASH o Bourne Again Shell) como intérprete de mandatos, sin embargo lo cierto es que si el sistema se utilizará como servidor, lo más conveniente es que se asigne de modo predefinido /sbin/nologin el cual muestra un mensaje respecto a que la cuenta no está disponible y da salida, utilizándose regularmente como intérprete de mandatos de reemplazo para cuentas que han sido deshabilitadas o bien que no tiene porque acceder con intérprete de mandatos al sistema. Cambie SHELL=/bin/bash por SHELL=/sbin/nologin.
# useradd defaults file
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/sbin/nologin
SKEL=/etc/skel
En adelante todo nuevo usuario que sea dado de alta en el sistema con el mandato useradd sin parámetro alguno, de modo predefinido no podrá acceder al sistema a través de shell, es decir acceso en terminal local o remotamente. Los usuarios con estas características podrán, sin embargo, utilizar cuentas de correo o Samba sin problema alguno.
De modo predefinido las cuentas de usuario del sistema utilizarán como molde al directorio /etc/skel para crear el directorio de inicio de todos los usuarios del sistema. Regularmente, y como mínimo, /etc/skel incluye lo siguiente:
.bash_logout .bash_profile .bashrc .gtkrc
Si, por ejemplo, se desea que cada cuenta de usuario incluya un subdirectorio para carpetas de correo y suscripción a éstas a través del servicio de IMAP, se debe realizar el siguiente procedimiento:
mkdir /etc/skel/mail/touch /etc/skel/mail/Borradorestouch /etc/skel/mail/Enviadostouch /etc/skel/mail/Papelera
Y finalmente generar con el editor de texto el fichero /etc/skel/.mailboxlist que sirve para guardar las suscripciones de carpetas de correo que serán utilizadas por el servicio de IMAP, utilizando el siguiente contenido:
mail/Borradoresmail/Enviadosmail/Papelera
Adicionalmente puede contribuir a transparentar la migración de escritorios de GNOME 1.x, 2.0 y 2.2 hacia versiones posteriores predefiniendo se genere el directorio ~/Desktop/ con un enlace simbólico apuntando hacia éste y el cual se denominará ~/.gnome-desktop/
cd /etc/skel/mkdir Desktopln -s Desktop .gnome-desktop
Mandato Chattr
El mandato chattr se utiliza para cambiar los atributos de los sistemas de ficheros ext2 y ext3. Desde cierto punto de vista, es análogo al mandato chmod, pero con diferente sintaxis y opciones. Utilizado adecuadamente, dificulta las acciones en el sistema de ficheros por parte de un intruso que haya logrado suficientes privilegios en un sistema.
En la mayoría de los casos, cuando un intruso consigue suficientes privilegios en un sistema, lo primero que hará será eliminar los registros de sus actividades modificando estructuras de los ficheros de bitácoras del sistema y otros componentes. Utilizar el mandato chattr ciertamente no es obstáculo para un usuario experto, pero, afortunadamente, la gran mayoría de los intrusos potenciales no suelen ser expertos en GNU/Linux o Unix, dependiendo enormemente de diversos programas o guiones (los denominados rootkits y zappers) para eliminar aquello que permita descubrir sus actividades.
Utilizar el mandato chattr, incluido en el paquete e2fsprogs, que se instala de forma predeterminada en todas las distribuciones de GNU/Linux por tratarse de un componente esencial, hace más difícil borrar o alterar bitácoras, ficheros de configuración y componentes del sistema. Theodore Ts'o es el desarrollador y quien se encarga de mantener e2fsprogs, mismo que se distribuye bajo los términos de la licencia GNU/GPL, e incluye otras herramientas como e2fsck, e2label, fsck.ext2, fsck.ext3, mkfs.ext2, mkfs.ext3, tune2fs y dumpe2fs, entre otras.
URL: http://e2fsprogs.sourceforge.net/
Opciones.
-R Cambia recursivamente los atributos de directorios y sus contenidos. Los enlaces simbólicos que se encuentren, son ignorado
-V Salida de charttr más descriptiva, mostrando además la versión del programa.
-v Ver el número de versión del programa.
Operadores.
+ Hace que se añadan los atributos especificados a los atributos existentes de un fichero.
- Hace que se eliminen los atributos especificados de los atributos existentes de un fichero
= Hace que solamente haya los atributos especificados.
Atributos.
A Establece que la fecha del último acceso (atime) no se modifica.
a Establece que el fichero solo se puede abrir en modo de adjuntar para escritura.
c Establece que el fichero es comprimido automáticamente en el disco por el núcleo del sistema operativo. Al realizar lectura de este fichero, se descomprimen los datos. La escritura de dicho fichero comprime los datos antes de almacenarlos en el disco.
D Cuando se trata de un directorio, establece que los datos se escriben de forma sincrónica en el disco. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción dirsync del mandato mount, pero aplicada a un subconjunto de ficheros.
d Establece que el fichero no sea candidato para respaldo al utilizar la herramienta dump.
i Establece que el fichero será inmutable. Es decir, no puede ser eliminado, ni renombrado, no se pueden apuntar enlaces simbólicos, ni escribir datos en el fichero.
j En los sistemas de ficheros ext3, cuando se montan con las opciones data=ordered o data=writeback, se establece que el fichero será escrito en el registro por diario (Journal). Si el sistema de ficheros se monta con la opción data=journal (opción predeterminada), todo el sistema de ficheros se escribe en el registro por diario y por lo tanto el atributo no tiene efecto.
s Cuando un fichero tiene este atributo, los bloques utilizados en el disco duro son escritos con ceros, de modo que los datos no se puedan recuperar por medio alguno. Es la forma más segura de eliminar datos.
S Cuando el fichero tiene este atributo, sus cambios son escritos de forma sincrónica en el disco duro. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción sync del mandato mount.
u Cuando un fichero con este atributo es eliminado, sus contenidos son guardados permitiendo recuperar el fichero con herramientas para tal fin.
Utilización.
chattr [-RV] +-=[AacDdijsSu] [-v versión] ficheros
Ejemplos.
el siguiente mandato agrega el atributo inmutable al fichero algo.txt..
chattr +i algo.txt
El siguiente mandato elimina el atributo inmutable al fichero algo.txt.
chattr -i algo.txt
El siguiente mandato agrega el modo de solo adjuntar para escritura al fichero algo.txt.
chattr +a algo.txt
El siguiente mandato elimina el modo de solo adjuntar para escritura al fichero algo.txt.
chattr -a algo.txt
El siguiente mandato establece que el fichero algo.txt solo tendrá los atributos a, A, s y S.
chattr =aAsS algo.txt
El siguiente mandato lista los atributos del fichero algo.txt.
lsattr algo.txt
En la mayoría de los casos, cuando un intruso consigue suficientes privilegios en un sistema, lo primero que hará será eliminar los registros de sus actividades modificando estructuras de los ficheros de bitácoras del sistema y otros componentes. Utilizar el mandato chattr ciertamente no es obstáculo para un usuario experto, pero, afortunadamente, la gran mayoría de los intrusos potenciales no suelen ser expertos en GNU/Linux o Unix, dependiendo enormemente de diversos programas o guiones (los denominados rootkits y zappers) para eliminar aquello que permita descubrir sus actividades.
Utilizar el mandato chattr, incluido en el paquete e2fsprogs, que se instala de forma predeterminada en todas las distribuciones de GNU/Linux por tratarse de un componente esencial, hace más difícil borrar o alterar bitácoras, ficheros de configuración y componentes del sistema. Theodore Ts'o es el desarrollador y quien se encarga de mantener e2fsprogs, mismo que se distribuye bajo los términos de la licencia GNU/GPL, e incluye otras herramientas como e2fsck, e2label, fsck.ext2, fsck.ext3, mkfs.ext2, mkfs.ext3, tune2fs y dumpe2fs, entre otras.
URL: http://e2fsprogs.sourceforge.net/
Opciones.
-R Cambia recursivamente los atributos de directorios y sus contenidos. Los enlaces simbólicos que se encuentren, son ignorado
-V Salida de charttr más descriptiva, mostrando además la versión del programa.
-v Ver el número de versión del programa.
Operadores.
+ Hace que se añadan los atributos especificados a los atributos existentes de un fichero.
- Hace que se eliminen los atributos especificados de los atributos existentes de un fichero
= Hace que solamente haya los atributos especificados.
Atributos.
A Establece que la fecha del último acceso (atime) no se modifica.
a Establece que el fichero solo se puede abrir en modo de adjuntar para escritura.
c Establece que el fichero es comprimido automáticamente en el disco por el núcleo del sistema operativo. Al realizar lectura de este fichero, se descomprimen los datos. La escritura de dicho fichero comprime los datos antes de almacenarlos en el disco.
D Cuando se trata de un directorio, establece que los datos se escriben de forma sincrónica en el disco. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción dirsync del mandato mount, pero aplicada a un subconjunto de ficheros.
d Establece que el fichero no sea candidato para respaldo al utilizar la herramienta dump.
i Establece que el fichero será inmutable. Es decir, no puede ser eliminado, ni renombrado, no se pueden apuntar enlaces simbólicos, ni escribir datos en el fichero.
j En los sistemas de ficheros ext3, cuando se montan con las opciones data=ordered o data=writeback, se establece que el fichero será escrito en el registro por diario (Journal). Si el sistema de ficheros se monta con la opción data=journal (opción predeterminada), todo el sistema de ficheros se escribe en el registro por diario y por lo tanto el atributo no tiene efecto.
s Cuando un fichero tiene este atributo, los bloques utilizados en el disco duro son escritos con ceros, de modo que los datos no se puedan recuperar por medio alguno. Es la forma más segura de eliminar datos.
S Cuando el fichero tiene este atributo, sus cambios son escritos de forma sincrónica en el disco duro. Es decir, los datos se escriben inmediatamente en lugar de esperar la operación correspondiente del sistema operativo. Es equivalente a la opción sync del mandato mount.
u Cuando un fichero con este atributo es eliminado, sus contenidos son guardados permitiendo recuperar el fichero con herramientas para tal fin.
Utilización.
chattr [-RV] +-=[AacDdijsSu] [-v versión] ficheros
Ejemplos.
el siguiente mandato agrega el atributo inmutable al fichero algo.txt..
chattr +i algo.txt
El siguiente mandato elimina el atributo inmutable al fichero algo.txt.
chattr -i algo.txt
El siguiente mandato agrega el modo de solo adjuntar para escritura al fichero algo.txt.
chattr +a algo.txt
El siguiente mandato elimina el modo de solo adjuntar para escritura al fichero algo.txt.
chattr -a algo.txt
El siguiente mandato establece que el fichero algo.txt solo tendrá los atributos a, A, s y S.
chattr =aAsS algo.txt
El siguiente mandato lista los atributos del fichero algo.txt.
lsattr algo.txt
Mandatos Chown y Chgrp
Tanto chown como chgrp, forman parte del paquete coreutils, el cual se instala de forma predeterminada en todas las distribuciones de GNU/Linux, por tratarse de un componente esencial.
URL: ftp://alpha.gnu.org/gnu/coreutils/
Mandato chown.
El mandato chown se utiliza para cambiar el propietario al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un usuario, así como un número de identidad de usuario (UID). Opcionalmente, utilizando un signo de dos puntos (:), o bien un punto (.), permite especificar también un nombre de grupo.
Opciones.
-R Cambia recursivamente el propietario (y, opcionalmente, el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chown más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el propietario del destino en lugar del propio enlace.
--reference Cambia el el propietario de un fichero, tomando como referencia el propietario de otro.
Utilización.
chown [opciones] usuario[:grupo] fichero(s) o directorio(s)
Mandato chgrp.
El mandato chgrp se utiliza para cambiar el grupo al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un grupo, así como un número de identidad de grupo (GID).
Opciones.
-R Cambia recursivamente el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chgrp más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el grupo del destino en lugar del propio enlace.
--reference Cambia el grupo de un fichero, tomando como referencia el propietario de otro.
Utilización.
chgrp [opciones] fichero(s) o directorio(s)
Ejemplos.
El siguiente mandato realiza el cambio de propietario a fulano, sobre el fichero algo.txt.
chown fulano algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo desarrollo, sobre el fichero algo.txt.
chown fulano:desarrollo algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo mail, del subdirectorio Mail, junto con todo su contenido.
chown -R fulano:mail Mail
El siguiente mandato realiza el cambio de grupo a desarrollo, sobre el fichero algo.txt.
chgrp desarrollo algo.txt
URL: ftp://alpha.gnu.org/gnu/coreutils/
Mandato chown.
El mandato chown se utiliza para cambiar el propietario al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un usuario, así como un número de identidad de usuario (UID). Opcionalmente, utilizando un signo de dos puntos (:), o bien un punto (.), permite especificar también un nombre de grupo.
Opciones.
-R Cambia recursivamente el propietario (y, opcionalmente, el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chown más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el propietario del destino en lugar del propio enlace.
--reference Cambia el el propietario de un fichero, tomando como referencia el propietario de otro.
Utilización.
chown [opciones] usuario[:grupo] fichero(s) o directorio(s)
Mandato chgrp.
El mandato chgrp se utiliza para cambiar el grupo al que pertenece un fichero o directorio. Puede especificarse tanto el nombre de un grupo, así como un número de identidad de grupo (GID).
Opciones.
-R Cambia recursivamente el grupo al que pertenecen los directorios, junto con todos sus contenidos.
-v (o --verbose) Salida de chgrp más descriptiva.
--version Ver el número de versión del programa.
--dereference Actúa sobre enlaces simbólicos en lugar de hacerlo sobre el destino.
-h (o --no-dereference) En el caso de enlaces simbólicos, cambia el grupo del destino en lugar del propio enlace.
--reference Cambia el grupo de un fichero, tomando como referencia el propietario de otro.
Utilización.
chgrp [opciones] fichero(s) o directorio(s)
Ejemplos.
El siguiente mandato realiza el cambio de propietario a fulano, sobre el fichero algo.txt.
chown fulano algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo desarrollo, sobre el fichero algo.txt.
chown fulano:desarrollo algo.txt
El siguiente mandato realiza el cambio de propietario a fulano y el grupo mail, del subdirectorio Mail, junto con todo su contenido.
chown -R fulano:mail Mail
El siguiente mandato realiza el cambio de grupo a desarrollo, sobre el fichero algo.txt.
chgrp desarrollo algo.txt
Cómo configurar y utilizar Sudo.
Sudo es una herramienta de sistema que permite a los usuarios realizar la ejecución de mandatos como superusuario u otro usuario de acuerdo a como se especifique en el fichero /etc/sudoers, donde se determina quien está autorizado. Los números de identidad de usuario y de grupo (UID y GID) reales y efectivas se establecen para igualar a aquellas del usuario objetivo como esté especificado en el fichero /etc/passwd.
De modo predeterminado sudo requiere que los usuarios se autentiquen así mismos con su propia clave de acceso (nunca la clave de acceso de root). Una vez que el usuario se ha autenticado, el usuario podrá utilizar nuevamente sudo sin necesidad de volver a autenticarse durante 5 minutos, salvo que se especifique lo contrario en el fichero /etc/sudoers. Si el usuario ejecuta el mandato sudo -v podrá refrescar éste periodo de tiempo sin necesidad de tener que ejecutar un mandato, en cuyo caso contrario expirará esta autenticación y será necesario volver a realizarla.
Si un usuario no listado en el fichero /etc/sudoers. trata de ejecutar un mandato a través de sudo, se registra la actividad en la bitácora de sistema (a través de syslogd) y se envía un mensaje de correo electrónico al administrador del sistema (root).
Historia.
Sudo fue inicialmente concebido en 1980 por Bob Coggeshall y Cliff Spencer del departamento de ciencia computacional en SUNY (State University of New York o Universidad Estatal de Nueva York), en Buffalo.
En 1985 se publicó el grupo de noticias net.sources una versión mejorada acreditada a Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso y Don Gworek. Garth Snyder publicó otra versión mejorada en el verano de 1986 y durante los siguientes cinco años fue mantenido con al colaboración de muchas personas, incluyendo Bob Coggeshall, Bob Manchek, y Trent Hein.
En 1991 Dave Hieb y Jeff Nieusma escribieron una nueva versión con un formato mejorado para el fichero /etc/sudoers bajo contrato con la firma consultora The Root Group, versión que posteriormente fue publicada bajo los términos de la Licencia Pública General de GNU (GNU/GPL).
Desde 1996 el proyecto es mantenido por Todd Miller con la colaboración de Chris Jepeway y Aaron Spangler.
Fichero /etc/sudoers
El fichero /etc/sudoers se edita con el mandato visudo, herramienta que a través de vi permite realizar cambios y verificar sintaxis y errores. Si se trata de modificar directamente /etc/sudoers, éste tiene permisos de solo lectura.
La sintaxis básica de una lista sería:
XXXX_Alias NOMBRELISTA = elemento1, elemento2, elemento3
La sintaxis básica de una regla sería:
[usuario, %grupo, NOMBRELISTA] [anfitrión] = (id de usuario a usar) mandatos
Se pueden definir Aliases y reglas. Los aliases permiten definir una lista de mandatos , una lista de usuarios, un alista de anfitriones o bien ejecutar como otros usuarios.
Cmnd_Alias.
Cmnd_Alias MANDATOSHTTPD = /sbin/service httpd restart,
/usr/bin/vim /etc/httpd/conf.d/variables.conf,
/usr/bin/vim /etc/php.ini
Lo anterior define una lista de mandatos que podrían utilizarse para reiniciar el servicio de httpd, modificar un fichero de configuración en la ruta /etc/httpd/conf.d/variables.conf y modificar el fichero /etc/php.ini.
fulano ALL = MANDATOSHTTPD
Lo anterior define que el usuario fulano puede utilizar los mandatos de la lista MANDATOSHTTPD desde cualquier anfitrión.
User_Alias.
User_Alias USUARIOSHTTP = fulano, mengano, zutano
Lo anterior define una lista denominada HTTPUSERS, integrada por los usuarios fulano, mengano y zutano.
USUARIOSHTTP ALL = /usr/bin/vim
La regla anterior define que los usuarios que conforman la lista USUARIOSHTTP pueden utilizar el mandato vim desde cualquier anfitrión.
Host_Alias.
Host_Alias HOSTSHTTPD = 192.168.0.25, 192.168.0.26, 192.168.0.23
Lo anterior define que la lista HOSTSHTTPD está integrada por las 3 direcciones IP listadas anteriormente. Si además se añade la siguiente regla:
USUARIOSHTTPD HOSTSHTTPD = ADMINHTTPD
Lo anterior define que los usuarios de la lista HTTPDUSERS pueden utilizar los mandatos listados en ADMINHTTPD solamente si están conectados desde las direcciones IP listadas en HOSTSHTTPD.
Runas_Alias.
Si por ejemplo se quisiera que los usuarios de la lista USUARIOSHTTP pudieran además utilizar los mandatos ls, rm, chmod, cp, mv, mkdir, touch y vim como el usuarios juan, pedro y hugo, se requiere definir una lista para estos mandatos y otra para los aliases de usuarios alternos, y la regla correspondiente.
Runas_Alias CLIENTES1 = juan, pedro, hugo
Cmnd_Alias MANDATOSCLIENTES = /bin/ls,
/bin/rm,
/bin/chmod,
/bin/cp, /bin/mv,
/bin/mkdir,
/bin/touch,
/usr/bin/vim
USUARIOSHTTPD HOSTSHTTPD = (CLIENTES1) MANDATOSCLIENTES
Lo anterior permite a los usuarios definidos en USUARIOSHTTPD (fulano, mengano y zutano), utilizar los mandatos definidos en MANDATOSCLIENTES (ls, rm, chmod, cp, mv, mkdir, touch y vim) identificándose como los usuarios definidos en CLIENTES1 (juan, pedro y hugo) solamente si se realiza desde las direcciones IP listadas en HOSTSHTTPD (192.168.0.25, 192.168.0.26, 192.168.0.23).
Candados de seguridad.
Sudo incluye varios candados de seguridad que impiden se puedan realizar tareas peligrosas.
Si se define el mandato /usr/bin/vim en /etc/sudoers, se podrá hacer uso de éste de los siguientes modos:
$ sudo /usr/bin/vim
$ sudo vim
Sin embargo, no podrá ser utilizado así:
$ cd /usr/bin
$ sudo ./vim
Si se define el mandato /bin/echo, el usuario podrá utilizarlo de los siguientes modos:
$ sudo /bin/echo "Hola"
$ sudo echo "Hola"
Pero no podrá utilizarlo de la siguiente forma:
$ sudo echo "Hola" > algo.txt
Para poder realizar la operación anterior, tendría que utilizar:
$ sudo bash -c "echo 'Hola' > algo.txt"
Sudo permitirá realizar una tarea sobre cualquier fichero dentro de cualquier directorio aún si no tiene permisos de acceso para ingresar a dicho directorio siempre y cuando especifique la ruta exacta de dicho fichero.
$ sudo chown named /var/named/dominio.zone
Pero no podrá utilizarlo así:
$ sudo chown named /var/named/*.zone
Lo que no se recomienda.
Si se quiere permitir a un usuario utilizar lo que sea, desde cualquier anfitrión, cómo cualquier usuario del sistema y sin necesidad de autenticar, se puede simplemente definir:
fulano ALL = (ALL) NOPASSWD: ALL
Facilitando la vida a través de ~/.bash_profile.
BASH (Bourne-Again Shell) permite utilizar variables de entorno y aliases definidas en ~/.bash_profile al iniciar la sesión, siendo que el administrador utilizará activamente muchos mandatos diversos, estos se pueden simplificar a través de aliases que resuman éstos. Por ejemplo, si se quiere definir que se utilice sudo cada vez que se invoque al mandato chkconfig, se puede añadir lo siguiente al fichero ~/.bash_profile:
alias chkconfig="sudo /sbin/chkconfig"
Lo anterior permitirá ejecutar directamente el mandato chkconfig sin necesidad de preceder éste con el mandato sudo. A continuación só diversos aliases que pueden ser de utilidad en el fichero ~/.bash_profile y que permitirán utilizar mandatos diversos con sudo.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
export PATH
unset USERNAME
alias chkconfig="sudo /sbin/chkconfig"
alias service="sudo /sbin/service"
alias route="sudo /sbin/route"
alias depmod="sudo /sbin/depmod"
alias ifconfig="sudo /sbin/ifconfig"
alias chmod="sudo /bin/chmod"
alias chown="sudo /bin/chown"
alias chgrp="sudo /bin/chgrp"
alias useradd="sudo /usr/sbin/useradd"
alias userdel="sudo /usr/sbin/userdel"
alias groupadd="sudo /usr/sbin/groupadd"
alias groupdel="sudo /usr/sbin/groupdel"
alias edquota="sudo /usr/sbin/edquota"
alias vi="sudo /usr/bin/vim"
alias less="sudo /usr/bin/less"
alias tail="sudo /usr/bin/tail"
alias yum="sudo /usr/bin/yum"
alias saslpasswd2="sudo /usr/sbin/saslpasswd2"
alias htpasswd="sudo /usr/bin/htpasswd"
alias openssl="sudo /usr/bin/openssl"
alias system-config-printer="sudo /usr/sbin/system-config-printer"
alias system-config-network="sudo /usr/sbin/system-config-network"
alias system-config-display="sudo /usr/bin/system-config-display"
Para que surtan efectos los cambios, hay que salir de la sesión y volver a ingresar al sistema con la misma cuenta de usuario, en cuyo fichero ~/.bash_profile se añadieron estos aliases.
De modo predeterminado sudo requiere que los usuarios se autentiquen así mismos con su propia clave de acceso (nunca la clave de acceso de root). Una vez que el usuario se ha autenticado, el usuario podrá utilizar nuevamente sudo sin necesidad de volver a autenticarse durante 5 minutos, salvo que se especifique lo contrario en el fichero /etc/sudoers. Si el usuario ejecuta el mandato sudo -v podrá refrescar éste periodo de tiempo sin necesidad de tener que ejecutar un mandato, en cuyo caso contrario expirará esta autenticación y será necesario volver a realizarla.
Si un usuario no listado en el fichero /etc/sudoers. trata de ejecutar un mandato a través de sudo, se registra la actividad en la bitácora de sistema (a través de syslogd) y se envía un mensaje de correo electrónico al administrador del sistema (root).
Historia.
Sudo fue inicialmente concebido en 1980 por Bob Coggeshall y Cliff Spencer del departamento de ciencia computacional en SUNY (State University of New York o Universidad Estatal de Nueva York), en Buffalo.
En 1985 se publicó el grupo de noticias net.sources una versión mejorada acreditada a Phil Betchel, Cliff Spencer, Gretchen Phillips, John LoVerso y Don Gworek. Garth Snyder publicó otra versión mejorada en el verano de 1986 y durante los siguientes cinco años fue mantenido con al colaboración de muchas personas, incluyendo Bob Coggeshall, Bob Manchek, y Trent Hein.
En 1991 Dave Hieb y Jeff Nieusma escribieron una nueva versión con un formato mejorado para el fichero /etc/sudoers bajo contrato con la firma consultora The Root Group, versión que posteriormente fue publicada bajo los términos de la Licencia Pública General de GNU (GNU/GPL).
Desde 1996 el proyecto es mantenido por Todd Miller con la colaboración de Chris Jepeway y Aaron Spangler.
Fichero /etc/sudoers
El fichero /etc/sudoers se edita con el mandato visudo, herramienta que a través de vi permite realizar cambios y verificar sintaxis y errores. Si se trata de modificar directamente /etc/sudoers, éste tiene permisos de solo lectura.
La sintaxis básica de una lista sería:
XXXX_Alias NOMBRELISTA = elemento1, elemento2, elemento3
La sintaxis básica de una regla sería:
[usuario, %grupo, NOMBRELISTA] [anfitrión] = (id de usuario a usar) mandatos
Se pueden definir Aliases y reglas. Los aliases permiten definir una lista de mandatos , una lista de usuarios, un alista de anfitriones o bien ejecutar como otros usuarios.
Cmnd_Alias.
Cmnd_Alias MANDATOSHTTPD = /sbin/service httpd restart,
/usr/bin/vim /etc/httpd/conf.d/variables.conf,
/usr/bin/vim /etc/php.ini
Lo anterior define una lista de mandatos que podrían utilizarse para reiniciar el servicio de httpd, modificar un fichero de configuración en la ruta /etc/httpd/conf.d/variables.conf y modificar el fichero /etc/php.ini.
fulano ALL = MANDATOSHTTPD
Lo anterior define que el usuario fulano puede utilizar los mandatos de la lista MANDATOSHTTPD desde cualquier anfitrión.
User_Alias.
User_Alias USUARIOSHTTP = fulano, mengano, zutano
Lo anterior define una lista denominada HTTPUSERS, integrada por los usuarios fulano, mengano y zutano.
USUARIOSHTTP ALL = /usr/bin/vim
La regla anterior define que los usuarios que conforman la lista USUARIOSHTTP pueden utilizar el mandato vim desde cualquier anfitrión.
Host_Alias.
Host_Alias HOSTSHTTPD = 192.168.0.25, 192.168.0.26, 192.168.0.23
Lo anterior define que la lista HOSTSHTTPD está integrada por las 3 direcciones IP listadas anteriormente. Si además se añade la siguiente regla:
USUARIOSHTTPD HOSTSHTTPD = ADMINHTTPD
Lo anterior define que los usuarios de la lista HTTPDUSERS pueden utilizar los mandatos listados en ADMINHTTPD solamente si están conectados desde las direcciones IP listadas en HOSTSHTTPD.
Runas_Alias.
Si por ejemplo se quisiera que los usuarios de la lista USUARIOSHTTP pudieran además utilizar los mandatos ls, rm, chmod, cp, mv, mkdir, touch y vim como el usuarios juan, pedro y hugo, se requiere definir una lista para estos mandatos y otra para los aliases de usuarios alternos, y la regla correspondiente.
Runas_Alias CLIENTES1 = juan, pedro, hugo
Cmnd_Alias MANDATOSCLIENTES = /bin/ls,
/bin/rm,
/bin/chmod,
/bin/cp, /bin/mv,
/bin/mkdir,
/bin/touch,
/usr/bin/vim
USUARIOSHTTPD HOSTSHTTPD = (CLIENTES1) MANDATOSCLIENTES
Lo anterior permite a los usuarios definidos en USUARIOSHTTPD (fulano, mengano y zutano), utilizar los mandatos definidos en MANDATOSCLIENTES (ls, rm, chmod, cp, mv, mkdir, touch y vim) identificándose como los usuarios definidos en CLIENTES1 (juan, pedro y hugo) solamente si se realiza desde las direcciones IP listadas en HOSTSHTTPD (192.168.0.25, 192.168.0.26, 192.168.0.23).
Candados de seguridad.
Sudo incluye varios candados de seguridad que impiden se puedan realizar tareas peligrosas.
Si se define el mandato /usr/bin/vim en /etc/sudoers, se podrá hacer uso de éste de los siguientes modos:
$ sudo /usr/bin/vim
$ sudo vim
Sin embargo, no podrá ser utilizado así:
$ cd /usr/bin
$ sudo ./vim
Si se define el mandato /bin/echo, el usuario podrá utilizarlo de los siguientes modos:
$ sudo /bin/echo "Hola"
$ sudo echo "Hola"
Pero no podrá utilizarlo de la siguiente forma:
$ sudo echo "Hola" > algo.txt
Para poder realizar la operación anterior, tendría que utilizar:
$ sudo bash -c "echo 'Hola' > algo.txt"
Sudo permitirá realizar una tarea sobre cualquier fichero dentro de cualquier directorio aún si no tiene permisos de acceso para ingresar a dicho directorio siempre y cuando especifique la ruta exacta de dicho fichero.
$ sudo chown named /var/named/dominio.zone
Pero no podrá utilizarlo así:
$ sudo chown named /var/named/*.zone
Lo que no se recomienda.
Si se quiere permitir a un usuario utilizar lo que sea, desde cualquier anfitrión, cómo cualquier usuario del sistema y sin necesidad de autenticar, se puede simplemente definir:
fulano ALL = (ALL) NOPASSWD: ALL
Facilitando la vida a través de ~/.bash_profile.
BASH (Bourne-Again Shell) permite utilizar variables de entorno y aliases definidas en ~/.bash_profile al iniciar la sesión, siendo que el administrador utilizará activamente muchos mandatos diversos, estos se pueden simplificar a través de aliases que resuman éstos. Por ejemplo, si se quiere definir que se utilice sudo cada vez que se invoque al mandato chkconfig, se puede añadir lo siguiente al fichero ~/.bash_profile:
alias chkconfig="sudo /sbin/chkconfig"
Lo anterior permitirá ejecutar directamente el mandato chkconfig sin necesidad de preceder éste con el mandato sudo. A continuación só diversos aliases que pueden ser de utilidad en el fichero ~/.bash_profile y que permitirán utilizar mandatos diversos con sudo.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
export PATH
unset USERNAME
alias chkconfig="sudo /sbin/chkconfig"
alias service="sudo /sbin/service"
alias route="sudo /sbin/route"
alias depmod="sudo /sbin/depmod"
alias ifconfig="sudo /sbin/ifconfig"
alias chmod="sudo /bin/chmod"
alias chown="sudo /bin/chown"
alias chgrp="sudo /bin/chgrp"
alias useradd="sudo /usr/sbin/useradd"
alias userdel="sudo /usr/sbin/userdel"
alias groupadd="sudo /usr/sbin/groupadd"
alias groupdel="sudo /usr/sbin/groupdel"
alias edquota="sudo /usr/sbin/edquota"
alias vi="sudo /usr/bin/vim"
alias less="sudo /usr/bin/less"
alias tail="sudo /usr/bin/tail"
alias yum="sudo /usr/bin/yum"
alias saslpasswd2="sudo /usr/sbin/saslpasswd2"
alias htpasswd="sudo /usr/bin/htpasswd"
alias openssl="sudo /usr/bin/openssl"
alias system-config-printer="sudo /usr/sbin/system-config-printer"
alias system-config-network="sudo /usr/sbin/system-config-network"
alias system-config-display="sudo /usr/bin/system-config-display"
Para que surtan efectos los cambios, hay que salir de la sesión y volver a ingresar al sistema con la misma cuenta de usuario, en cuyo fichero ~/.bash_profile se añadieron estos aliases.
Suscribirse a:
Entradas (Atom)
