De manera resumida, FreeBSD es un sistema operativo tipo UNIX® para plataformas Alpha/AXP, AMD64 e Intel EM64T, i386 IA-64, PC-98 y UltraSPARC basado en “4.4BSD-Lite” de la Universidad de Berkeley en California. También está indirectamente basado en el port de Net/2 para i386 de Berkeley, conocido como “386BSD”, realizado por William Jolitz's. Una descripción más detallada de FreeBSD y de cómo puede trabajar, se encuentra en FreeBSD home page.

FreeBSD es usado por compañías, proveedores de Internet, profesionales de la informática, estudiantes y usuarios particulares de todo el mundo en su trabajo, educación y ocio. Puedes ver a algunos de ellos en FreeBSD Gallery.

Para información más detallada sobre FreeBSD, por favor mira en FreeBSD Handbook.

El objetivo del Proyecto FreeBSD es proveer software que pueda ser usado en todos los ámbitos sin ningún tipo de atadura. Muchos de nosotros estamos significativamente involucrados en el desarrollo del código (y del proyecto) y no sería cierto decir que no esperábamos o esperamos algún tipo de financiación, pero definitivamente no estamos preparados para insistir en ello. Creemos que nuestra primera y principal “misión” es proporcionar el código libremente, y en cualquier ámbito, para que el código se difunda lo más posible y genere los mayores beneficios. Esto es, creemos en uno de los objetivos fundamentales del Software Libre y lo apoyamos de manera incondicional.

El código fuente de los programas registrados bajo la GNU General Public License (GPL) o la GNU Library General Public License (LGPL), se proporciona bajo las condiciones fijadas por esas licencias. Debido a complicaciones adicionales en el uso comercial de Software GPL, intentamos reemplazar ese software por otros registrados bajo la licencia FreeBSD,menos estricta y más permisiva.

Si. Las restricciones no controlan el uso del código. Cualquier duda puede ser contestada leyendo la licencia. Esta misma puede ser resumida de la siguiente manera:

Para la mayor parte de la gente, si. Aunqué esta pregunta no se contesta tan fácilmente.

La mayoría de las personas no usa realmente un sistema operativo. Usan aplicaciones. Las aplicaciones son las que en realidad usan el sistema operativo. FreeBSD esta diseñado para proveer un ambiente robusto y listo para aplicaciones. Soporta una gran variedad de exploradores de web, suites de oficina, lectores de correo electrónico, programas de gráficos, ambientes de programación, servidores y casi todo lo que se desee. La mayor parte de estas aplicaciones pueden ser encontrádas en la Colección de Ports.

Si se requiere de una aplicación solamente disponible para un sistema operativo, simplemente no puede cambiar ese sistema operativo. Aunqué muy probablemente encuentre una aplicación muy parecida en FreeBSD. Si lo que se desea es una sólida oficina o un servidor de Internet, una estación de trabajo confiable, o solamente la habilidad de trabajar sin interrupciones, FreeBSD seguramente hará lo que usted necesita. Una gran cantidad de usuarios alrededor del mundo, incluyendo novatos y usuarios de UNIX® experimentados usan FreeBSD como su sistema operativo.

Si se desea migrar a FreeBSD desde algún otro ambiente UNIX®, usted ya sabe mas de lo que se necesita. Si su constumbre es un sistema operativo gráfico como Windows o viejas versiones de Mac OS, usted tendrá que invertir mas tiempo aprendiendo la forma en la que UNIX® hace las cosas. Este FAQ y el FreeBSD Handbook son excelentes lugares donde empezar.

Para todos nuestros lectores cuyo primer lenguaje no sea el inglés, aclaremos que la palabra “free” es usada en dos sentidos, uno significando “sin coste” y el otro “puedes hacer lo que quieras”. Aparte de una o dos cosas que no puedes hacer con el código de FreeBSD, por ejemplo decir que lo has escrito, realmente puedes hacer lo que quieras con él.

James Howard escribió una buena explicación para DaemonNews, acerca de la historia y las diferencias entre los diferentes proyectos, llamada The BSD Family Tree, la cual puede contestar esta pregunta.

La versión 4.9R es la última -STABLE; fue declarada definitiva (a partir de ahora “release”) en Diciembre de 2003.

Brevemente explicado, -STABLE está dirigido a proveedores de Internet y otros usuarios corporativos que quieren estabilidad y una sucesión tranquila en los cambios y actualizaciones a las nuevas versiones y sus mejoras. Sólo debes usar la rama -CURRENT si estás seguro de estar preparado para su mayor “volatilidad” (relativa a -STABLE).

Las versiones Release se hacen cada varios meses. Aunque mucha gente mantiene más al día los fuentes de FreeBSD (lee las preguntas en FreeBSD-CURRENT y FreeBSD-STABLE, ello está pensado para gente que se considere preparada para seguir el desarrollo continuo del código fuente.

FreeBSD-CURRENT es la versión de desarrollo del sistema operativo, la cual acabará siendo la versión FreeBSD-STABLE. Como es de suponer, esta versión es de interés sólo para los desarrolladores que trabajan en el sistema y “masoquistas” de la programación. Mira la sección correspondiente en el handbook para saber cómo funciona esta opción.

Si no estás familiarizado con el sistema operativo o no eres capaz de identificar la diferencia entre un problema real y un problema temporal, no deberías usar FreeBSD-CURRENT. Esta rama a veces avanza muy rápidamente y puede no ser compilable durante unos días. La gente que usa FreeBSD-CURRENT es capaz de analizar los problemas y sólo comunicarlos si son motivo de errores. Preguntas como “al ejecutar make world obtengo un error referente a grupos” en la lista de distribución -CURRENT pueden quedar fuera de lugar.

Una release snapshot corresponde al desarrollo de la rama -CURRENT; distribuciones en CDROM de esta versión están disponibles. Los objetivos de cada release snapshot son:

No se garantiza que ningún snapshot pueda ser considerado “calidad de producción”. Para conseguir estabilidad y un sistema garantizado, tendrás que usar las versiones release.

Las release snapshot están directamente disponibles en ftp://current.FreeBSD.org/pub/FreeBSD/ y son generadas un promedio de una vez por día para las ramas 4.0-CURRENT y 3.0-STABLE.

Cuando la versión de FreeBSD 2.0.5 fue declarada release, decidimos dividir el desarrollo de FreeBSD en dos ramas. Una rama fue llamada -STABLE, otra -CURRENT. FreeBSD-STABLE está previsto para provedores de Internet y otras empresas para las que no resultan deseables cambios repentinos o experimentales. FreeBSD-CURRENT, por otra parte, ha sido la línea común desde la release 2.0, llegando hasta 5.2.1-RELEASE (y más allá). Se espera que 5-STABLE sea creado a la salida de 5.3-RELEASE y es entoncés cuando FreeBSD-CURRENT pasará a ser 6-CURRENT. Aquí hay un pequeño gráfico ASCII para ayudar a entender este sistema de desarrollo:

                 2.0
                  |
                  |
                  |  [2.1-STABLE]
 *BRANCH*       2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1  [2.1-STABLE termina]
                  |                            (Mar 1997)
                  |
                  |
                  |  [2.2-STABLE]
 *BRANCH*       2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [termina]
                  |       (Mar 1997)    (Oct 97) (Abr 98) (Jul 98) (Dic 98)
                  |
                  |
               3.0-SNAPs  (comenzado Q1 1997)
                  |
                  |
               3.0-RELEASE (Oct 1998)
                  |
                  |  [3.0-STABLE]
 *BRANCH*      3.1-RELEASE  (Feb 1999) -> 3.2 -> 3.3 -> 3.4 -> 3.5 -> 3.5.1
                  |                     (May 1999) (Sep 1999) (Dic 1999) (Junio 2000) (Julio 2000)
                  |
                  |  [4.0-STABLE]
 *BRANCH*        4.0  (Mar 2000) -> 4.1 -> 4.1.1 -> 4.2 -> 4.3 -> 4.4 -> ... later 4.X releases ...
                  |
                  |              (Julio 2000)   (Sep 2000)   (Nov 2000)
               5.0-RELEASE (Enero 2003)
                  |
                  |
               5.1-RELEASE (Junio 2003)
                  |
                  |
               5.2-RELEASE
                  |
                  |
               5.2.1-RELEASE (Febrero 2004)
                 \|/
                  +
          [5-CURRENT continua]

La version 2.2-STABLE fue retirada con el release 2.2.8. La rama 3-STABLE fue terminada con la release 3.5.1, la última release de 3.X. Los únicos cambios que se le podrían hacer son arreglos en la seguridad.

4-STABLE es actualmente el branch -STABLE en desarrollo. El ultimo release en branch 4-STABLE es 8.4-RELEASE, el cual fue hecho en June 2013.

La rama 5-CURRENT progresa lentamente hacia la creación de la rama 5-STABLE. Ver ?Qué es FreeBSD-CURRENT? para mas información sobre esta rama.

El re@FreeBSD.org publica una nueva versión de FreeBSD cada 4 meses aproximadamente. Las fechas de las nuevas versiones se anuncian por adelantado, con la finalidad de que los desarrolladores trabajando en el sistema sepan cuando deben terminar sus proyectos para ser probados e integrados en el sistema. Hay un periodo de prueba para cada release, para asegurar que los nuevos cambios introducidos en el sistema no comprometan la estabilidad de la versión. Algunos usuarios califican esta precaución como una de las mejores características de FreeBSD, aunque esperar el alcance de -STABLE puede ser un poco frustrante.

Mas información en el proceso de las releases (incluyendo fechas y releases futuras) puede ser encontrada en la página de release engineering.

Para personas que quieran o necesiten más emoción, diariamente se crean snapshots binarios de la misma manera.

Las decisiones clave concernientes al proyecto FreeBSD como la dirección a seguir y quién está autorizado a añadir código a la distribución original, se hace a través de un grupo de unas 17 personas llamado core team. Existe también un grupo de unas 150 personas o committers que también están autorizadas a realizar cambios directamente sobre la distribución original.

De todas maneras, la cambios importantes son discutidos en las listas de distribución en las que no existen restricciones sobre quién participa en las discusiones.

Todas las versiones release de FreeBSD están disponibles via ftp anónimo en el servidor FTP de FreeBSD:

Más información acerca de como obtener FreeBSD en CD, DVD, y otros medios en el Handbook .

Puedes encontrar información acerca de como instalar un mirror de FreeBSD en el artículo Mirroring FreeBSD.

Puedes encontrar toda la información en la sección de listas del Handbook.

Puedes encontrar toda la información en la sección de news del Handbook.

Sí, muchas de las grandes redes de IRC tienen canales de chat de FreeBSD.

Cada uno de estos canales es diferente y no están conectados entre ellos. Sus estilos de chat difieren, por lo que podrís probarlos todos para ver cuál te gusta más.

El libro de Greg Lehey's ``Installing and Running FreeBSD'' está disponible en Walnut Creek y se vende con el CDROM 2.2.5. Hay también un libro más completo titulado ``The Complete FreeBSD'', el cual tiene manuales adicionales e incluye el CDROM 2.2.6. Debería estar disponible en las mejores librerías.

Hay un proyecto de documentación de FreeBSD con el que puedes contactar (o mejor, participar), en la lista de distribución doc: <doc@FreeBSD.org>. En esta lista se tratan todos los temas referentes a la documentación de FreeBSD. Para verdaderas preguntas sobre FreeBSD, existe la lista question: <questions@FreeBSD.org>.

Está disponible un ``manual'' (handbook a patir de ahora) de FreeBSD, y se puede encontrar en: El Handbook de FreeBSD. Ten en cuenta que éste es un trabajo en constante desarrollo y actualización, por lo que algunas secciones podrían estar incompletas.

Teniendo en cuenta que FreeBSD 2.2.x está basado en la versión Berkeley 4.4BSD-Lite2, la mayoría de manuales de 4.4BSD con aplicables a FreeBSD 2.2.x. O'Reilly y Asociados publican estos manuales:

Una descripción de éstos puede ser encontrada vía WWW en:

Descripción de libros sobre 4.4BSD

Para profundizar más en la organizacion del kernel de 4.4BSD, no puedes ir mal con los siguientes:

McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman.

The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4

Un buen libro en administración de sistemas es:

Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 ISBN: 0-13-151051-7

NOTA Asegurate de conseguir la segunda edición, con cubierta roja y no la primera.

Este libro cubre las necesidades básicas, así como TCP/IP, DNS, NFS,SLIP/PPP, sendmail, INN/NNTP, impresión, etc,. Es caro, (aproximadamente unos US$45-$55), pero vale la pena. También incluye un CD-ROM con los fuentes de varias herramientas, muchas de las cuales están incluidas, también, en la versión 2.2.6R (CDROM) de FreeBSD, incluso incluyendo versiones más modernas.

La base de datos de Problem Report puede ser consultada vía web a traves de la dirección query. También pueden ser enviados vía web a través de la dirección envio. El comando send-pr(1) también puede ser usado para el envío de reporte de problemas.

La FAQ actualizada está disponible en el servidor Web de FreeBSD o en cualquiera de los mirrors en formato PostScript y texto (7 bits ASCII y 8 bits Latin-1).

Formato PostScript (unos 370KB):

Formato ASCII (unos 220KB):

Formato texto ISO 8859-1 (unos 220KB):

El Hansbook actualizado está disponible en el servidor Web de FreeBSD o en cualquiera de los mirrors en formato PostScript y texto (7 bits ASCII y 8 bits Latin-1).

Formato PostScript (unos 1.7MB):

Formato ASCII (unos 1080KB):

Formato texto ISO 8859-1 (unos 1080KB):

Cierto, las versiones ASCII y Latin1 del Handbook no están estrictamente en formato de texto plano; contienen carácteres de control de impresión asumiendo que el documento será enviado a una impresora. Si necesitas tenerlos en un formato leible, pasa el archivo por el programa col:

Hay múltiples maneras de hacer mirror de las páginas web.

Bueno, no podemos pagar, pero quizás te enviemos un CD-ROM o una camiseta y añadiremos tu nombre en la sección ``Contributors'' del Handbook si nos envías una traducción de la documentación.

Los siguientes grupos de news contienen temas relacionados con FreeBSD y sus usuarios:

Recursos Web:

El handbook de FreeBSD tiene una completa bibliografía en la sección bibliografía la cual recomendamos leer si estás interesado en comprar libros actuales relacionados con estos temas.

Generalmente sólo es necesario un disco de 1,44Mb con una imgen del archivo floppies/boot.flp. Arranca con este disco para comenzar con el programa de instalación, el cual se encargará de realizar todas las operaciones necesarias (gestión de TCP/IP, cintas, CDROMs, floppies, particiones DOS y cualquier cosa necesaria para realizar la instalación).

Si necesitas bajarte las distribuciones (para una instalación desde una partición DOS por ejemplo), estas son las distribuciones mínimas que necesitarás:

Todas las instrucciones sobre este procedimiento y una ampliación de la documentación se puede encontrar en Instalación de FreeBSD.

Un floppy de 1.44MB puede contener hasta 1474560 bytes de datos. La imagen de arranque es exactamente de 1474560 bytes.

Los errores más comunes en la preparación de disco de arranque son:

Las instrucciones de instalación están en Instalación de FreeBSD.

Necesitarás un PC con 386 o superior, 5 Mb o más de memoria RAM y al menos 60 Mb de espacio en disco duro. Puede funcionar con tarjetas gráficas de bajo nivel (Hercules), pero para poder ejecutar X11R6 es necesario una tarjeta VGA o superior.

FreeBSD 2.1.7 fue la última version de FreeBSD que podía ser instalada en un sistema de 4Mb. Las nuevas versiones de FreeBSD, como la 2.2, necesitan al menos 5Mb para poder ser instaladas.

Todas las versiones de FreeBSD, incluyendo la 3.0, funcionarán en sistemas con 4Mb de RAM, lo que no puedes ejecutar es la instalación en sistemas con 4Mb. Puedes añadir memoria extra para el proceso de instalación, y una vez instalado, volver a los 4Mb. Tambien puedes instalar tu disco en una máquina con más de 4Mb, realizar la instalación y reponer el disco en su máquina con 4Mb.

Hay algunas situaciones en las que FreeBSD 2.1.7 no se instalará en sistemas con 4Mb. Para ser exactos: no se instalará con 640Kb de memoria base + 3Mb de memoria extendida. Si tu placa base puede remapear algo de la memoria ``perdida'' fuera de los 640Kb a la región de 1Mb, entonces aun podrás instalar FreeBSD 2.1.7.

Intenta entrar en el setup de tu BIOS y busca la opción ``remap''. Actívala. Quizás tendrás que desactivar la opción de ROM shadowing.

Es más fácil añadir en la máquina 4Mb de memoria para la instalación. Crea un kernel unicamente con las opciones que necesites y vuelve a quitar los 4Mb añadidos.

También puedes instalar la versión 2.0.5 y a continuación actualizar tu sistema a la 2.1.7 con la opción ``upgrade'' del programa de instalación de la versión 2.1.7.

Después de la instalación, si te creas un kernel personalizado, funcionará en 4Mb. Algunos fueron capaces de arrancar con 2Mb (aunque después el sistema era incapaz de hacer nada más :-))

Realmente, no hay una manera para sólo hacer un disco de instalación personalizado. Hay algún código en /usr/src/release/floppies/Makefile que supuestamente es para hacer sólo un disco de instalación personalizado, pero no está realmente testeado todavía.

Echa un vistazo en La página multi-OS.

Instala primero Windows 95 y después FreeBSD. El boot manager de FreeBSD se encargará de darte la opción de arrancar con cualquiera de los dos sistemas. Si lo haces al revés, Windows 95 borrará el boot manager sin hacer ninguna pregunta previa. Si ocurre esto, pasa a la siguiente sección.

Puedes reinstalar el boot manager que viene con FreeBSD de dos maneras:

La gestión de sectores erróneos por parte de FreeBSD no está desarrollada todavía al 100% y desgraciadamente debemos decirte que si tienes discos IDE o ESDI con gran cantidad de sectores erróneos, FreeBSD no es para tí. De todas maneras, te aconsejamos que antes de descartar la instalación, hagas un intento.

Si observas cosas como que la maquina se ``cuelga'' o se reinicializa espontáneamente cuando intentas arrancar con el disco de instalación, aquí tienes tres preguntas que debes responder tu mismo:

Han habido informaciones referentes a problemas al bajar el disco de instalación con Netscape, por lo que te recomendamos que uses un programa diferente como cliente de ftp.

Si estás instalando la versión 2.1.7R desde una cinta, debes crear esa cinta con un tamaño de bloque de tar de 10 (5120 bytes). El tamaño por defecto de los bloques tar es de 20 (10240 bytes), y las cintas creadas con este tamaño por defecto no pueden ser usadas para instalar FreeBSD 2.1.7R; con estas cintas tendrás un error referente a un tamaño de registro demasiado grande.

Coge un cable de laplink y asegurate que ambos computadores tienen un kernel que soporta el puerto paralelo.

Conecta el cable en los dos puertos paralelos.

Configura los parámetros de red para el interfaz lp0 (como root) en ambas máquinas. Por ejemplo, si quieres conectar la máquina max y moritz:

En el arranque de max

En el arranque de moritz

Esto es todo!!. Por favor, lee los man de lp(4) y lpt(4).

También deberías añadir las máquinas en el archivo /etc/hosts:

Para asegurarte que funciona haz:

en max:

Conecta los dos computadores usando Laplink mediante el puerto paralelo y usa las siguientes características:

Mira también esta nota en la página de informática móvil.

(Por geometría de un disco, entendemos el número de cilindros, cabezales y sectores por pista en el disco - de ahora en adelante nos referiremos por conveniencia a estos parámetros como C/H/S. Así es como trabaja el BIOS de los PC's para gestionar la lectura/escritura.

Por alguna razón, esto parece crear mucha confusión. Ante todo, la geometría física de un disco SCSI es totalmente irrelevante ya que FreeBSD trabaja en términos de bloques de disco. Con discos IDE, FreeBSD trabaja en términos de C/H/S, pero todos los discos modernos convierten estos datos en referencias internas de bloques.

Para discos SCSI, la geometría a usar depende de si tenemos activado en la controladora el soporte de translación (comunmente conocido como "soporte para discos mayores de 1GB" o algo similar). Si esta opción está desactivada, entonces usa N cilindros, 64 cabezales y 32 sectores por pista, donde N es la capacidad del disco en MB. Por ejemplo, para un disco de 2GB, los parámetros correctos serían 2048 cilindros, 64 cabezales y 32 sectores.

Si el soporte de translación está activado y la capacidad del disco es mayor de 1GB, usa M cilindros, 63 cabezales (*no* 64), y 255 sectores, donde M es la capacidad del disco en MB dividida por 7.844238. Para nuestro ejemplo de un disco de 2GB, los parámetros serían 261 cilindros, 62 cabezales y 255 sectores.

Si no estás seguro sobre los parámetros a usar, o FreeBSD falla al detectar la geometría correcta del disco durante la instalación, el método más simple para solucionar este problema es crear una pequeña partición DOS en el disco. Entonces, la geometría debería ser detectada correctamente (y siempre puedes borrar esa partición desde el ``editor de particiones'' si no quieres mantenerla).

Alternativamente, existe una utilidad de libre distribución incluida en FreeBSD llamada pfdisk.exe (situada en el directorio tools del CD-ROM de distribución o en cualquiera de los servidores ftp) que nos dice la geometría del disco usada por el sistema operativo DOS. Lo único que tenemos que hacer es introducir los datos obtenidos en el editor de particiones de FreeBSD.

Sí. Debes asegurarte de que la partición raiz esta por debajo del cilindro 1024, para que el BIOS pueda arrancar el kernel desde ella. (Ésta es una limitación del BIOS de los PCs, no de FreeBSD).

Para discos SCSI, esto implica que la partición raíz debe estar instalada en los primeros 1024MB (o en los primeros 4096MB si la translación extendida esta activada). Para discos IDE, la partición raíz debe estar en los primeros 504MB.

FreeBSD reconoce el disk manager Ontrack. Otros disk managers no están soportados.

Si quieres usar el disco solo con FreeBSD no necesitas el disk manager. Solo configura el disco para el espacio máximo que pueda manejar el BIOS (usualmente 504MB), y FreeBSD se encargará de averiguar cuánto espacio tienes realmente. Si estás usando un disco antiguo con controladora MFM, necesitarás decirle explícitamente a FreeBSD cuántos cilindros puede usar.

Si quieres usar el disco con FreeBSD y otro sistema operativo, todavía puedes hacerlo sin necesitar un disk manager; sólo asegúrate de que la partición raíz de FreeBSD y la partición de arranque del otro sistema operativo están en los primeros 1024 cilindros. Si eres cuidadoso, una partición raiz de 20MB debería ser suficiente.

Esto es un clásico conflicto entre FreeBSD y DOS u otro sistema operativo sobre sus ideas de geometría.. Tendrás que reinstalar FreeBSD, pero teniendo en cuenta la información que te damos más arriba sobre este asunto.

Éste es otro problema descrito en el párrafo anterior. La geometría de tu BIOS y los datos de configuración de FreeBSD no coinciden. Si tu controladora o BIOS soporta la translación de cilindros (también conocido como "soporte para discos de más de 1GB"), intenta activar/desactivar esta opción y reinstala FreeBSD.

Aparte del rendimiento, no. FreeBSD 2.X tiene buffers que permiten al ``bus mastering controller'' acceder a más de 16MB. (Esto sólo es aplicable si estás usando dispositivos ISA).

También mira la sección máquinas con >64M si tienes esta cantidad de memoria o si usas máquinas Compaq u otro BIOS que no da correctamente la cantidad de memoria disponible.

En general, no. De todas maneras, te recomendamos que instales, por lo menos, el kit de código fuente base, el cual incluye muchos de los archivos aquí mencionados, y el kit sys, que incluye el código fuente del kernel. No hay nada en el sistema que requiera el código fuente para funcionar, a excepción del programa de configuración de kernel config. Con la excepción de las fuentes del kernel, nuestra estructura esta diseñada para que puedas montar una unidad en solo lectura via NFS en la que exista el código fuente, y aun así, ser capaz de compilar los nuevos binarios. (Debido a las restriciones de los fuentes del kernel, recomendamos que no montes estos en /usr/src directamente, sino en cualquier otra parte del disco con los links simbólicos apropiados para duplicar la estructura principal del árbol de directorios original),

Teniendo los fuentes on-line y sabiendo como crear un sistema con ellas (compilar), te haremos mucho mas fácil la actualización a futuras versiones de FreeBSD.

Para seleccionar auténticamente un subconjunto del código fuente, usa la opción Custom del menú desde el menú Distributions de la herramienta de instalación. El script src/install.sh instalará sólo partes de la distribución del código fuente dependiendo de los parámetros (argumentos) que se le pasen.

La creación de un nuevo kernel era, originariamente, un paso requerido en la instalación de FreeBSD, pero en las versiones más recientes nos hemos beneficiado de la introducción de una herramienta de configuración de kernel mucho más amigable. Cuando en el prompt de arranque de FreeBSD (boot:), usamos el parámetro "-c", llegamos a una pantalla de configuración visual la cual permite configurar las opciones del kernel para la mayoría de tarjetas ISA.

Todavía es recomendable la creación de un nuevo kernel conteniendo sólo los drivers que nos sean necesarios para ahorrar un poco de RAM, pero no es estrictamente necesario para la mayoría de sistemas.

Si no es absolutamente necesario que uses la encriptación DES, puedes usar la encriptación por defecto de FreeBSD para una mejor seguridad, y sin restricciones de importación. La encriptación por defecto de los passwords en FreeBSD está basada en MD5, y es necesario un mayor uso intensivo de CPU con programas de descubrimiento de passwords que en DES. La única razón para no usar hoy en día la encriptación MD5 sería usar un sistema de passwords compartidos entre sistemas FreeBSD y no FreeBSD.

Puesto que el algoritmo de encriptación DES no puede ser legalmente exportado fuera de USA, los usuarios externos a USA NO deberían descargar este software desde los servidores FTP situados en USA.

Existe una alternativa para la biblioteca de encriptación, basada en el código escrito en Australia por David Burren. Este código está disponible en algunos mirrors de FreeBSD fuera de USA. El código fuente de la biblioteca de encriptación, y los binarios de los programas que la usan pueden encontrarse en los siguientes servidores FTP:

Los usuarios de fuera de USA no deben descargar ningún software de encriptación de servidores situados en USA, ya que de no seguir esta norma los responsables de esos servidores podrían verse envueltos en importantes problemas legales.

Se está desarrollando una distribución no estadounidense de Kerberos, cuyas versiones actuales pueden obtenerse vía ftp anónimo en braae.ru.ac.za.

Existe también una lista de distribución para la discusión de software de encriptación externo a USA. Para más información envía un e-mail con una simple línea diciendo "help en el cuerpo del mensaje a:

<majordomo@braae.ru.ac.za>.

Si tienes instalado un ZIP o un Jaz IDE, desconéctalo e inténtalo de nuevo. El disco de arranque puede haberse confundido con los discos. Una vez el sistema esté instalado, puedes volver a conectar los dispositivos. Esperamos que esto sea arreglado en las próximas releases.

Este error proviene de la confusión entre los bloques de arranque y lo que ve el kernel en los discos. El error se suele manifestar en sistemas con dos discos IDE, con los discos duros dispuestos como máster o ''single'' en controladoras diferentes, estando FreeBSD instalado en la controladora IDE secundaria. Los bloques de arranque piensan que el sistema está instalado en wd1 (el segundo disco en el BIOS) mientras el kernel asigna el primer disco de la controladora secundaria wd2. Después de la detección de dispositivos, el kernel intenta montar lo que los bloques de arranque piensan que es el disco de arranque, wd1, cuando realmente es el wd2, y falla.

Para solucionar el problema, haz una de las siguientes cosas:

Para memoria, el límite (teórico) es de 4 gigabytes. Un gigabyte ha sido comprobado y funciona sin problemas: generalmente no se pueden comprar equipos i386 que soporten más cantidad de memoria.

Para sistemas de archivos FFS, el máximo teórico está en 8 terabytes (bloques de 2G), o 16TB para el tamaño de bloque por defecto de 8K. En la práctica hay un límite ``blando'' de 1 terabyte, pero con pequeáas modificaciones son posibles (y existen) sistemas de archivos de 4 terabytes.

El tamaño máximo de un único archivo FFS es aproximadamente de 1 Gbloque (4TB) si el tamaño del bloque es de 4K.

Cuando el tamaño del bloque del sistema de archivos es de 4K, los bloques triple-indirectos funcionan y el límite total debería venir determinado por el número máximo de bloques que puede ser representado usando los bloques triple-indirectos (aproximadamente 1K^3 + 1K^2 + 1K), pero el límite total lo establece un límite (incorrecto) de 1G-1 en el número de bloques. El límite en el número de bloques debería ser de 2G-1, pero estos números de bloque son inalcanzables cuando los bloques del sistema de archivos son de 4K.

El tamaño máximo de un archivo no depende directamente del tamaño máximo del disco. El tamaño máximo del disco es de 1TB. Es una ventaja que el tamaño del archivo pueda ser mayor que el tamaño del disco.

El siguiente ejemplo crea un archivo con un tamaño de 1TB usando 32K de espacio de disco (3 bloques indirectos y 1 bloque de datos) en una pequeña partición raíz.

Bruce Evans, septiembre de 1998

Puedes arrancar especificando el kernel directamente en la segunda fase del boot, pulsando cualquier tecla cuando veas el símbolo | justo antes de que se arranque el cargador (loader). Más específicamente, has actualizado los fuentes para tu kernel, y lo has creado y actualizado a partir de ellos sín hacer un ``make world''. Así no funciona. Haz un ``make world''.

FreeBSD soporta discos duros EIDE y SCSI (con controladoras compatibles; mira en la siguiente sección), y todos los discos que usen el interface original ``Western Digital'' (MFM, RLL, ESDI y por supuesto IDE). Algunas controladoras ESDI que usan interfaces propietarios quizá no funcionen correctamente.

FreeBSD soporta las siguientes controladoras SCSI:

Está soportado cualquier disco SCSI conectado a una controladora soportada

Los siguientes interfaces de CD-ROM propietarios también están soportados:

Todas las tarjetas no SCSI son conocidas por ser extremadamente lentas comparadas con los discos SCSI, y algunos CDROM ATAPI quizá no funcionen correctamente.

A partir de la versión 2.2 de FreeBSD en CDROM de Walnut Creek se soporta el arranque directo (boot) desde el propio CD.

FreeBSD soporta los ZIP SCSI externos. Las unidades ZIP sólo pueden funcionar en los ID's SCSI 5 y 6, pero si el BIOS de tu controladora lo soporta, puedes arrancar desde él. No sabemos qué controladoras dejan arrancar desde ID's diferentes de la 0 o 1... mira en tu documentación y házmelo saber si te funciona.

Los discos Zip ATAPI (IDE) están soportados en FreeBSD 2.2.6 y releases posteriores.

FreeBSD ha incluido el soporte de discos ZIP por puerto paralelo desde la versión 3.0. Si estás usando una versión actualizada, debes asegurarte de que tu configuración del kernel incluye los drivers scbus0, da0, ppbus0 y vp0 (el kernel GENERIC los contiene todos excepto vp0). Con todos estos drivers presentes, el disco por puerto paralelo debería estar disponible como /dev/da0s4. Los discos se pueden montar usando mount /dev/da0s4 /mnt o (para discos dos) mount_msdos /dev/da0s4 /mnt.

También mira en discos removibles, y esta nota en 'formatting'.

Aparte de la versión IDE de EZ, todos estos son dispositivos SCSI, por lo que deberían funcionar sin problemas ya que FreeBSD los toma como discos SCSI y el IDE EZ también debería funcionar sin problemas ya que se toma como un disco IDE estándar.

No estoy seguro de cómo soporta FreeBSD el cambio de soporte mientras está funcionando. Deberás, desde luego, desmontar la unidad antes de poder cambiar el soporte, y estar seguro de que todas las unidades externas están encendidas antes de arrancar el computador con FreeBSD para que éste pueda reconocerlas.

Mira esta nota en 'formatting'.

Hay una lista de ellas en la sección dispositivos varios del manual (handbook).

Algunas tarjetas ``sin nombre'' también han funcionado, especialmente las que dicen ser compatibles AST.

Mira la página sio para obtener más información sobre la configuración de estas tarjetas.

FreeBSD soporta el ``bus mouse'' y el ``InPort bus mouse'' de fabricantes como Microsoft, Logitech y ATI. El driver de mouse estiá compilado en el kernel GENERIC (kernel por defecto que carga el sistema). Si estás haciéndote un kernel a medida que incluya el driver de ratón, asegúrate de añadir la siguiente línea en el archivo de configuración del kernel:

Si estás usando una versión reciente de FreeBSD, el driver necesario, psm, está incluido y activado en el kernel. El propio kernel debería detectar tu ratón PS/2 en el momento de arrancar.

Si estás usando una versión antigua, sólo tienes que activarlo en la configuración del kernel en el momento de la instalación del sistema. Si éste ya está instalado, escribe -c en el prompt boot: y actívalo. Por defecto, este driver está desactivado.

Si estás usando alguna de las versiones más antiguas, tendras que añadir la siguiente línea en el archivo de configuración del kernel y compilar uno nuevo:

Mira la sección configuración del kernel si no tienes experiencia en la creación de nuevos kernel.

Una vez que el kernel detecta correctamente el dispositivo psm0 al arrancar, asegúrate de que existe una entrada en /dev para este dispositivo. Puedes hacerlo tecleando:

Si estás usando el driver por defecto de la consola, syscons, puedes usar el ratón en las consolas de texto para realizar ``cut & paste''. Ejecuta el demonio (daemon) de ratón moused y arranca el ratón en la consola virtual:

donde xxxx es el nombre del dispositivo del ratón e yyyy es un tipo de protocolo para el ratón. Mira en moused para saber los tipos de protocolo soportados.

Si quieres ejecutar el demonio moused automáticamente al arrancar el sistema, activa las siguientes variables en /etc/sysconfig (para versión 2.2.1).

En versiones 2.2.2 o superiores, activa las siguientes variables en /etc/rc.conf.

A partir de la versión 2.2.6, el demonio del ratón es capaz de determinar automáticamente el protocolo correcto a utilizar. Sólo tienes que especificar auto como el protocolo a usar.

Cuando el demonio de ratón está funcionando, el acceso al ratón necesita coordinarse con otros programas como X Window. Mira en esta sección para más información.

Una vez que tengas el demonio del ratón funcionando (mira la sección anterior, pulsa el botón 1 (izquierdo) y mueve el ratón para seleccionar la región de texto. A continuación, pulsa el botón 2 (medio) o 3 (derecho) para hacer un paste (pegar) de la región seleccionada en el lugar en el que tengamos situado el cursor.

En versiones 2.2.6 o superiores, pulsando el botón 2 hara un paste del texto seleccionado. Pulsando el botón 3 extenderemos la región seleccionada de texto. Si tu ratón no tiene el botón medio, puedes emularlo o ``remapear'' (reconfigurar) los botones de tu ratón con las opciones del demonio moused. Mira en moused para más información.

La respuesta es, desafortunadamente, ``depende''. Estos ratones con características adicionales requieren en muchos casos drivers propios y especializados. A no ser que el driver de dispositivo o el programa de usuario tenga soporte específico, el ratón se comportará como un ratón normal y corriente.

Por favor, mira en la respuesta anterior. Mira también esta nota en la sección de computadores portátiles.

FreeBSD soporta unidades SCSI, QIC-36 (con interfaz QIC-02) y QIC-40/80 (interfaz floppy). Esto inclye dispositivos de 8mm (conocidos como Exabyte) y dispositivos DAT. Los QIC-40/80 son conocidos por su lentitud.

Algunos de los dispositivos de 8mm primitivos no son totalmente compatibles con SCSI2 por lo que puede que no funcionen correctamente en FreeBSD.

FreeBSD 2.2 soporta SCSI changers usando el dispositivo ch y el comando chio. Los detalles acerca de cómo controlar realmente el changer se encuentran en chio.

FreeBSD soporta las tarjetas SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib y Gravis Ultrasound. Hay también soporte limitado para la tarjeta MPU-401 y compatibles midi. Las tarjetas SoundBlaster 16 ASP todavía no son soportadas. El Microsoft Sound System sí está soportado.

NOTA: ¡Esto es solo para sonido! Este driver no soporta CD-ROMs, SCSI o joysticks en estas tarjetas, a excepción de la SoundBlaster. El interface SCSI de SoundBlaster y algunos CD-ROMs no SCSI están soportados, pero no podrás arrancar el sistema desde ellos.

Puedes ejecutar el siguiente mandato cada vez que arranques el sistema:

Mira la sección de tarjetas Ethernet en el manual para una lista más completa.

NOTA Los drivers marcados con (*) pueden tener problemas.

NOTA: 3C598D NO está soportada todavía.

NOTA: FreeBSD también soporta TCP/IP sobre líneas paralelo. En estos momentos, no somos compatibles con otras versiones, pero esperamos corregirlo en un futuro cercano. Encontrarás más información sobre este tema en la página man de lp(4).

NOTA: Algunas de estas tarjetas requieren una partición DOS en el disco duro para ejecutar el programa de configuración.

NOTA: Esto sólo afectará a los computadores 386/486SX/486SLC. El resto de los microprocesadores tienen un coprocesador integrado.

En general, esto no causará problemas, pero hay circunstancias en las que pudieras echarlo de menos, especialmente si trabajas en entorno X Window. Si puedes, te recomendamos que compres uno y lo instales en tu computador.

Aquí hay una lista de drivers que no se han podido catalogar en las categorías anteriores.

FreeBSD soporta APM en algunas máquinas. Por favor, mira en el archivo de configuración del kernel LINT y busca la parabra APM

Algunas placas base Micron tienen una implementación de PCI en el BIOS que no es estándar, lo que provoca que FreeBSD no pueda encontrar los dispositivos PCI en las direcciones en las que deberían estar.

Desactiva la opción ``Plug and Play Operating System'' en el BIOS para solucionar el problema. Puedes encontrar más información en: http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron

Las nuevas controladoras Adaptec con chipset de la serie AIC789x están soportados bajo la nueva CAM SCSI que hace su debut en la version 3.0 de FreeBSD. Los parches para las versiones 3.0-CURRENT y 2.2-STABLE están en: ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/. Un disco de arranque con soporte CAM está disponible en: http://www.FreeBSD.org/~abial/cam-boot/. En ambos casos lee el archivo README antes de empezar.

Necesitarás añadir el ID del modem PnP a la lista de ID PnP en el driver serie. Para activar el soporte PnP, compila un nuevo kernel con controller pnp0 en el archivo de configuración y rearranca el sistema. El kernel mostrará en pantalla los IDs de todos los dispositivos PnP que encuentre. Copia el ID del módem en la tabla del archivo /sys/i386/isa/sio.c, sobre la línea 2777. Busca la cadena "SUP1310" en la estructura "siopnp_ids[]" para encontrar la tabla. Genera un nuevo kernel, instálalo y rearranca. Tu módem debería ser encontrado.

Quizá tengas que configurar manualmente los dispositivos PnP usando el comando ``pnp'' en la configuración de arranque usandolo de la siguiente manera:

Mira el archivo /usr/src/sys/i386/boot/biosboot/README.serial para más información.

Algunas placas base Micron tienen una implementación de PCI en el BIOS que no es estándar, lo que provoca que FreeBSD no pueda encontrar los dispositivos PCI en las direcciones en las que debieran estar.

Para solucionar el problema, desactiva la opción ``Plug and Play Operating System'' en el BIOS.

Puedes encontrar más información sobre este problema en http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron

SMP sólo está soportado a partir de la versión 3.0-STABLE

Los discos SCSI deberían ser capaces de marcar estos bloques erróneos automaticamente para que no presenten problemas. Algunos discos, por alguna razón desconocida, se venden con esta característica desactivada.

Para activar esta opción, tendrás que editar una de las opciones del dispositivo, lo que puede ser hecho con FreeBSD tecleando el siguiente comando (como root):

y cambiando los valores de AWRE y ARRE de 0 a 1:-

Para otros tipos de discos, dependes de las características de los sistemas operativos. Desafortunadamente, el comando "bad144" que se incluye en FreeBSD, necesita ser desarrollado más en profundidad.

Se supone que los discos IDE incluyen de serie la posibilidad de "remapear" los bloques dañados; si tienes documentación de tu disco, podrás ver si esta opción está activada o desactivada.

Esta información es específica para la tarjeta 742a, pero puede ser aplicable a otras tarjetas Buslogic. (Bustek = Buslogic)

Existen dos versiones de la tarjeta 742a. Son revisiones de hardware A-G y H. La letra de revisión está situada después del número de ensamblaje. La 742a tiene 2 ROMs, una es el BIOS y la otra es el Firmware. FreeBSD no se fija en la versión de BIOS de la tarjeta, pero si en la de Firmware. Buslogic te enviará una actualización de de las ROMs si te pones en contacto con su departamento técnico. La BIOS y el Firmware son distribuidas de manera inseparable. Deberías tener la versión de Firmware más actualizada para la revisión de hardware de tu tarjeta.

Las tarjetas con revisión A-G solo pueden aceptar BIOS/Firmware 2.41/2.21. La revisión H y superiores pueden aceptar las versiones más actuales 4.70/3.37. La diferencia entre las versiones de Firmware es que la 3.38 soporta "round robin".

Las tarjetas Buslogic tienen un número de serie serigrafiado en ellas. Si tienes una revisión de hardware antigua, puedes llamar al departamento de RMA de Buslogic y darles el número de serie de la tarjeta para intentar cambiarla por una revisión superior del hardware.

FreeBSD 2.1 solo soporta revisiones de Firmware 2.21 o superiores. Si tienes una versión inferior, tu tarjeta no será reconocida como Buslogic. Quizás sea reconocida como una Adaptec 1540. Las primeras versiones de Firmware de Buslogic contienen una modo de emulación de la AHA1540.

Si tienes una revisión de hardware antigua y consigues una más actual (2.21), necesitarás chequear la posición del jumper W1 y asegurarte que está en la posición B-C (por defecto esta en B-C).

Este es un problema ya conocido. Las controladoras SCSI EISA integradas en la placa base en las máquinas HP Netserver, ocupan el slot numero 11. El espacio de direcciones para los slots EISA >=10 colisionan con los espacios de direcciones asignados para los dispositivos PCI, y la autoconfiguración de FreeBSD no maneja esta situación demasiado bien.

Lo mejor que puedes hacer es pretender que no existan clases de rangos de direcciones :), cambiando el valor de la opción del kernel EISA_SLOTS a un valor de 12. Configura y compila un nuevo kernel como se describe en la entrada correspondiente del manual.

Por supuesto, esto presenta un pequeño problema. Para poder solucionarlo, es necesario un truco en la utilidad de configuración. No uses el interface "visual", simplemente teclea lo siguiente en la línea de comando de la utilidad

Esperamos que en las próximas versiones tengamos solucionados estos temas.

No funciona. No puede manejar comandos en los dos canales simultáneamente.

Hay una solución posible y se activa automáticamente si tu sistema usa este chip. Para más detalles, referirse al man del driver de discos (man 4 wd).

Si todavía estás usando FreeBSD 2.2.1 o 2.2.2 con una controladora IDE CMD640 y quieres usar el segundo canal, crea un nuevo kernel con options "CMD640" activada. Esta es la opción por defecto en la versión 2.2.5 y superiores.

Esto, normalmente es causado por conflictos de interrupciones (por ejemplo, dos tarjetas usando la misma IRQ). Las versiones anteriores a la 2.0.5R eran tolerantes con los problemas de conflictos de IRQ. A partir de esa versión, los conflictos de IRQ ya no son tolerados. Arranca con la opción -c y cambia la entrada correspondiente a tu tarjeta.

Si estás usando conectores BCN en tu tarjeta de red, el mensaje de error puede ser debido a una mala terminación de la red. Para chequear esto, conecta un terminador directamente a la salida BNC de la tarjeta (sin cable) y mira si el mensaje desaparece.

Tienes que indicar el tipo de dispositivo que quieres montar. Por defecto mount asumirá que el dispositivo que quieres montar es ``ufs''. Si quieres montar un CDROM, tienes que especificar -t cd9660. Esto hace que el sistema asuma que tiene que montar un sistema de archivos con formato ISO 9660 que es lo que los CDROM deben tener.

Como ejemplo, si quieres montar una unidad CDROM, /dev/cd0c, bajo /mnt, tienes que ejecutar

Ten en cuenta que el nombre de tu dispositivo (/dev/cd0c en este ejemplo) puede ser diferente dependiendo del interface que estés usando. El comando anterior puede ser acortado tecleando:

Esto, generalmente, significa que no hay ningún disco en el lector de CDROM. También puede significar que el lector no es visible para el bus. Chequea que está bién configurado en lo referente a master/slave si es IDE (ATAPI).

Algunas veces un CDROM SCSI puede "desaparecer" por que no ha tenido tiempo suficiente para responder a un reset del bus. Si tienes un CDROM SCSI, añade la siguiente línea en el archivo de configuración del kernel y recompílalo.

Si es paralelo, y el único problema es la lentitud, intenta configurar el puero de impresora en modo "polled":

Algunas impresoras nuevas de HP son conocidas por no trabajar correctamente en modo de interrupción, aparentemente debido (y todavía no exactamente entendido), a un problema de "timing".

Esto puede ser por hardware erróneo (memoria, placa base, etc). Intenta ejecutar algún programa de test de memoria. Ten en cuenta que es posible que tu memoria pase el test del programa que uses, pero que falle en algunas condiciones de uso, como en compilación de kernel.

La FAQ SIG11 (listada más abajo) apunta a problemas de lentitud de memoria. Incrementa el número de "wait states" en tu BIOS o instala una memoria más rápida.

También puedes intentar desactivar el caché de placa base en el BIOS y comprueba si se resuelve el problema.

Hay una extensa FAQ en the SIG11 problem FAQ

Este es un problema conocido con las tarjetas de vídeo ATI Mach 64. El problema es que esta tarjeta usa la dirección 2e8, también usada por el puerto serie 4. Debido a un bug (feature?) en el driver sio.c , éste "tocará" este puerto aunque no esté instalado o esté desactivado.

Hasta que el problema sea fijado, puedes hacer esto:

Si quieres ser capaz de usar tus puertos serie, tendrás que compilar un nuevo kernel con la siguiente modificación: /usr/src/sys/i386/isa/sio.c. Busca la cadena 0x2e8 y borra esta cadena y la coma anterior (mantén la coma siguiente). Ahora, compila un nuevo kernel de la manera habitual.

Después de realizar estos cambios, puedes encontrarte aun que las X Window no funcionan correctamente. Algunas tarjetas de vídeo modernas ATI Mach 64 (especialmente la ATI Mach Xpression) no funcionan con la versión actual de XFree86; la pantalla se queda negra cuando arrancas las X o ocurren cosas extrañas en su funcionamiento. Puedes instalar una versión beta del nuevo servidor X que trabaja mejor, situada en el servidor XFree86 y seguir los links hasta el download. Coge los siguientes archivos:

AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz

Reemplaza los viejos archivos por las nuevas versiones y asegúrate de ejecutar de nuevo xf86config.

Debido a la forma que tiene FreeBSD de "ver" el tamaño de memoria en el BIOS, solo puede detectar 16 bits (65535 Kbytes = 64MB) (o menos... algunas BIOS fijan el tamaño de la memoria a 16MB).

Para solucionar este problema, tienes que usar la opción del kernel indicada más adelante. Hay una manera de ver la información completa sobre memoria en el BIOS, pero no tenemos espacio en los bloques de arranque (bootblocks) para hacerlo. Por ahora, tenemos que trabajar con la opción del kernel.

options "MAXMEM=<n>"

Donde n es tu memoria en Kilobytes. Para 128MB, tendrías que usar 131072.

Nota El mensaje debería ser ``mb_map too small!''

La parada indica que el sistema no tiene memoria virtual suficiente para los buffers de red (específicamente, clusters mbuf). Puedes incrementar la cantidad de memoria virtual disponible para los clusters mbuf añadiendo:

options "NMBCLUSTERS=<n>"

al archivo de configuración del kernel, donde <n> es un número en el rango 512-4096, dependiendo del número de conexiones tcp simultáneas que necesites soportar. Te recomendamos intentar con 2048. Puedes monitorizar el número de clusters mbuf en uso con la orden netstat -m.

El programa que intenta detectar archivos /var/db/kvm_*.db puede fallar y provocar el "panic" en el arranque.

Si esto ocurre, arranca en mono-usuario y haz:

Esto significa un conflicto con una controladora Ultrastor SCSI.

Durante el proceso de arranque, entra en el menú de configuración del kernel y desactiva el dispositivo uha0.

Esto está contestado en la FAQ de sendmail de la siguiente manera:

La versión actual de la FAQ de sendmail puede ser encontrada en comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, y news.answers. Tambien puedes recibir una copia enviando un mail a mail-server@rtfm.mit.edu con el comando "send usenet/news.answers/mail/sendmail-faq" en el cuerpo del mensaje.

Quizás la máquina remota tiene el tipo de terminal diferente de cons25 que es el usado por la consola de FreeBSD.

Hay diferentes maneras de solucionar este problema:

Esto puede ser causado por varios problemas de hardware o software relacionados con las interrupciones. Utilizar TCP/IP sobre el puerto paralelo con un MTU muy grande es una buena manera de provocar este error. Las tarjetas gráficas aceleradoras también lo pueden provocar, teniendo que revisar la interrupción utilizada por la tarjeta.

El efecto de este error es que los procesos mueren con el mensaje "SIGXCPU exceeded cpu time limit".

Para FreeBSD 3.0 y posteriores desde el 29 de Noviembre de 1998: si el problema no puede fijarse de otra manera, la solución es poner la variable sysctl a:

Esto puede significar un impacto en el rendimiento del sistema, pero considerando la causa del problema, probablemente no lo notarás. Si el problema persiste, mantén la variable sysctl a uno y añade la opción "NTIMECOUNTER" en tu kernel para aumentar su valor. Si finalmente llegas a un valor de "NTIMECOUNTER=20" el problema no está resuelto, y las interrupciones están demasiado saturadas para ofrecer un buén rendimiento.

Contacta con Apps2go para una distribución de Motif ELF 2.1 para FreeBSD.

Esta distribución incluye:

Asegúrate de especificar que deseas la distribución para FreeBSD cuando hagas el pedido. También se distribuyen versiones para NetBSD y OpenBSD por Apps2go. La distribución sólo está disponible por FTP.

Contacta con Metro Link para obtener una distribución de Motif 2.1 ELF o a.out para FreeBSD.

Esta distribución incluye:

Asegúrate de especificar que deseas la distribución para FreeBSD cuando hagas el pedido. También se distribuyen versiones para Linux por Metro Link. La distribución está disponible en CDROM o vía FTP.

Contacta con Xi Graphics para una distribución de Motif a.out 2.0 para FreeBSD.

Esta distribución incluye:

Asegúrate de especificar que deseas la distribución para FreeBSD cuando hagas el pedido. También se distribuyen versiones para BSDI y Linux por Xi Graphics. La distribución se hace en cuatro disquetes... en el futuro esto se cambiará por una versión en CDROM unificada.

Contacta con Xi Graphics para la distribucion CDE 1.0.10 para FreeBSD. Incluye Motif 1.2.5, y puede ser usada con Motif 2.0.

Este es un CDROM unificado para FreeBSD y Linux.

Xi Graphics ya no vende el CDE para FreeBSD.

KDE es un entorno gráfico "open source" similar a CDE en muchos aspectos.

Sí, Xi Graphics y Metro Link venden el producto Accelerated-X para FreeBSD y otros sistemas basados en Intel.

La oferta de Metro Link es un servidor X de altas prestaciones que ofrece una fácil configuración usando el conjunto de herramientas "FreeBSD Package", soporte de múltiples tarjetas de vídeo concurrentes y sólo se distribuye en formato binario desde su FTP. Mencionar que la oferta de Metro Link está disponible por el razonable precio de $39.

Metro Link también vende el Motif ELF y a.out para FreeBSD.

La oferta de Xi Graphics es un servidor X de altas prestaciones que ofrece una fácil configuración, soporte para múltiples tarjetas de vídeo concurrentes, y sólo se distribuye en formato binario, en una distribución en disquetes unificada para FreeBSD y Linux. Xi Graphics también ofrece un servidor X de altas prestaciones para computadores portátiles.

Hay una distribución demo para testear (versión 5.0).

Xi Graphics también vende el Motif y CDE para FreeBSD.

Sí!. Mira en la sección Productos Comerciales del web de FreeBSD.

También te recomendamos que mires en la sección Bases de Datos de la colección de Ports.

Sí. Las siguientes páginas te explican como configurar el Oracle de Linux en FreeBSD:

Por favor, mira en la sección de ports para obtener información sobre programas y aplicaciones que han sido portados a FreeBSD. En estos momentos la lista llega a los 1800 creciendo día a día, por lo que te recomendamos que la visites habitualmente o te subscribas a la lista de distribución FreeBSD-announce para las actualizaciones periódicas de nuevas aportaciones.

La mayoría de programas están disponibles tanto para la rama 2.2 como para la 3.x y 4.0, y muchos de ellos deberían funcionar en sistemas 2.1.x. Cada vez que se realiza una release de FreeBSD, se incluye un snapshot del arbol de aplicaciones en el directorio ports/.

También trabajamos con el concepto de "package", que es, esencialmente una distribución binaria "zipada" con una pequeña información extra que realiza la instalación del programa automaticamente. Un package puede ser instalado y desinstalado fácilmente sin tener que saber los detalles de archivos o configuraciones que esto conlleva.

Usa el menú de instalación de "packages" en /stand/sysinstall (bajo la opción post-configuration del menú principal) o ejecuta el comando pkg_add(1) con el package que estás interesado en instalar. Los package pueden ser identificados por su extensión .tgz. En la distribución de CDROM existe un directorio packages/All en la que se encuentran todos los packages disponibles. También pueden conseguirse en la red en los siguientes servidores:

o en tu mirror más cercano.

Ten en cuenta que no todos los ports están disponibles como packages. Es siempre buena idea visitar periodicamente la dirección ftp.FreeBSD.org.

Estás intentando ejecutar un package para versión 2.2/3.x/4.0 en un sistema de versión 2.1.x. Por favor, mira en la sección anterior y usa el package adecuado para tu sistema.

No tienes coprocesador matemático, verdad? Necesitarás añadir el emulador matemático en tu kernel; puedes hacerlo añadiendo lo siguiente en el archivo de configuración del kernel:

NOTA Necesitarás eliminar la opción MATH_EMULATE.

Primero necesitas editar el archivo /etc/sysconfig (o /etc/rc.conf) y en la última sección cambiar la siguiente variable a YES:

El kernel caragará el módulo ibcs2 al arrancar.

A continuación necesitarás configurar /compat/ibcs2/dev de la siguiente manera

Solo necesitas el socksys para ir a /dev/null e imitar la apertura y cierre de archivos. El código en -current gestionará el resto. Esto es mucho más limpio que la manera en la que se hacía antes. Si quieres el driver spx para un conexión, define SPX_HACK cuando compiles el kernel.

Después de la instalación del package o port de inn, un excelente lugar para empezar es Dave Barr's INN Page donde encontrarás las FAQ de INN.

Usa el Port. Una versión pre-parcheada para Apache está disponible en la colección de ports.

Sí. Por favor, mira en http://www.FreeBSD.org/java/.

Si utilizas una versión de FreeBSD que ha quedado ligeramente anticuada con respecto a -stable o -current necesitarás el kit de actualización de ports disponible en http://www.FreeBSD.org/ports/. Si tienes una versión actualizada, es posible que alguien haya modificado el port de manera que éste compile en -current pero no en -stable. Por favor, envía un informe de error con el comando send-pr(1) ya que la colección de ports está pensada para que funcione tanto en las ramas -stable como -current.

Si quieres ejecutar aplicaciones a.out como Netscape en sistemas con formato de ejecución ELF como FreeBSD 3.1-RELEASE o posteriores, necesitarás la librería /usr/libexec/ld.so y algunas otras en formato a.out. Estas librerías están incluidas en la distribución compat22. Usa /stand/sysinstall o el script install.sh en el subdirectorio compat22 e instalala. También deberían consultarse los archivos ERRATA de FreeBSD 3.1-R y 3.2-R.

No!, primero, necesitas la distribución completa de fuentes o, por lo menos, la distribución de fuentes del kernel. De esta manera tienes los fuentes necesarios para crearte un nuevo kernel. Al contrario que muchos Unix comerciales, nosotros tenemos la política de NO vender nuestro kernel en formato binario.

La instalación de los fuentes ocupa un poco más de espacio, pero te permite consultar los fuentes del kernel en caso de dificultad o entender que está ocurriendo realmente en la ejecución del sistema.

Una vez tienes instalada la distribución completa de fuentes, o por lo menos la del kernel, haz lo siguiente como root:

El paso 2 no es necesario si todavía tienes un archivo de configuración del kernel de una release anterior de FreeBSD 2.X. - simplemente, copia el archivo antiguo y examínalo cuidadosamente para asegurar que no haya cambiado la sintaxis da algún driver, o haya alguno anticuado.

Un buen archivo de configuración para consultar es LINT, el cual contiene ejemplos documentados para todas las posibles opciones del kernel. El archivo de configuración GENERIC se usa para crear el kernel "por defacto" que es el que estarás usando si no has creado ninguno nuevo.

Si no necesitas hacer ningún cambio al archivo GENERIC, puedes saltar al paso 3, donde personalizas el kernel para tu sistema. El paso 8 solo debe ejecutarse si los pasos 6 y 7 se han realizado de manera satisfactoria. Esto copiará una imágen del nuevo kernel a /kernel y realizará una copia del antiguo kernel en /kernel.old. Es muy importante recordar esto por si el nuevo kernel falla en algun momento - puedes seleccionar kernel.old en el prompt de arranque. Al hacer un reboot, por defecto se cargará el nuevo kernel.

Si la compilación en el paso 7 falla por alguna razón, es recomendable que empieces desde el paso 4 substituyendo GENERIC por MYKERNEL. Si puedes generar el kernel GENERIC, significa que algo en tu archivo de configuración es incorrecto (o has decubierto un bug). Si la compilación del kernel GENERIC falla, posiblemente tengas los fuentes corruptos.

Finalmente, si necesitas ver los mensajes originales de arranque del sistema para compilar un nuevo kernel, ejecuta el comando dmesg. Este comando debe imprimir en pantalla todos los mensajes producidos por el kernel al arrancar, los cuales te pueden servir en la configuración de tu nuevo kernel.

NOTA Recomendamos hacer un historial fechado de los kernel que vayas creando, de la manera kernel.YYMMDD una vez estén funcionando correctamente. De esta manera, si la próxima vez que juegues con el kernel algo no funciona, puedes arrancar desde el último kernel correcto. Esto es especialmente importante si ahora estás arrancando desde una controladora no soportada por el kernel GENERIC (si, experiencia personal).

Dejame adivinar. Has borrado npx0 de tu archivo de configuración porque no tienes coprocesador matemático, no? Mal hecho :-) El dispositivo npx0 es OBLIGATORIO. Aunque no tengas coprocesador, debes incluir el dispositivo npx0

Cuando compilo el kernel con drivers para tarjetas serie multipuerto, el sistema me dice que sólo el primer puerto es testeado y el resto son obviados debido a conflictos de interrupción. Cómo soluciono esto?

El problema en este caso es que FreeBSD tiene código interno que evita caidas del sistema por conflictos de hardware o software. La manera de solucionar esto es dejar en blanco la entrada correspondiente a la irq en todos los puertos excepto en uno. Aquí tienes un ejemplo:

Necesitas "descomentar" la siguiente línea en el archivo genérico de configuración (o añadirla en tu propio archivo), añade un flags 0x1 en la línea fdc y recompila.

A continuación, crea un nuevo dispositivo llamado /dev/ft0 entrando en el directorio /dev y ejecutando el comando:

Para el primer dispositivo. ft1 para el segundo y así para todos los dispositivos de este tipo que tengas.

Tendrás un dispositivo llamado /dev/ft0, al cual puedes escribir a través de un programa especial de manejo llamado ft - mira el man en ft para más detalles.

Versiones anteriores a la -current tenían algunos problemas al encontrase con cintas en mal estado; si tienes problemas en los que parece que la cinta se rebovina siempre al llegar al mismo lugar, intenta utilizar la última versión del programa ft que encontrarás en /usr/src/sbin/ft en -current.

De la versión 2.0.5R a la 2.2.1R, el archivo principal de configuración es /etc/sysconfig. Todas las opciones son especificadas en este archivo y otros como /etc/rc y /etc/netstart.

Mira en el archivo /etc/sysconfig y cambia los valores para tu sistema. Este archivo está comentado para ayudar en la configuración

En versiones posteriores a la 2.2.1 y 3.0 el archivo /etc/sysconfig fue renombrado como rc.conf. La sintaxis también fue retocada para ser más descriptiva. El archivo /etc/netstart también fue renombrado como /etc/rc.network para que todos los archivos de configuración puedan ser copiados con el comando cp /usr/src/etc/rc* /etc.

/etc/rc.local existe como siempre y debería ser usado para arrancar servicios locales adicionales como INN o programas propios.

El archivo /etc/rc.serial es para la inicialización de puertos serie.

El archivo /etc/rc.i386 es para especificaciones propias de Intel, como la emulación iBCS2 o la configuración de la consola del sistema.

A partir de la versión 2.1.0R, también puedes tener un directorio en el que instalar archivos de arranque locales especificado en /etc/sysconfig (o /etc/rc.conf):

Cada archivo acabado en .sh será ejecutado en orden alfabético.

Si quieres asegurarte de un cierto orden en la ejecución sin tener que cambiar todos los nombres de los archivos, puedes usar un esquema similar al siguiente con dígitos al principio del nombre de cada archivo:

Puede ser visto como "malo" (o SysV :-)) pero nos provee de un esquema regular para programas añadidos localmente sin tener que hacer ediciones complicadas del archivo /etc/rc.local. Muchos de los ports/packages asumen que /usr/local/etc/rc.d es un directorio de arranque local.

Usa el comando adduser. Para opciones más avanzadas, usa el comando pw

Para borrar a un usuario, usa el comando rmuser.

Consultar el Tutorial de Formateo de Discos en www.FreeBSD.org.

Se trate de un disco removible como un ZIP o EA (o un floppy, si quieres usarlo de esta manera), o un nuevo disco duro, una vez instalado y reconocido por el sistema, y tengas tu cartridge/floppy/etc en su interior, las cosas son como para la mayoría de dispositivos.

(esta sección esta basada en Mark Mayo's ZIP FAQ)

Si es un disco ZIP o floppy, y está formateado en DOS, puedes usar el comando:

Si es un floppy, o este:

para un disco ZIP con la configuración de fábrica.

Para otros discos, mira como configurarlos usando fdisk o /stand/sysinstall.

El resto de ejemplos serán para un disco ZIP en da2, el tercer disco SCSI.

A no ser que se trate de un floppy o disco removible, lo que planeas compartir con otros usuarios, es aconsejable convertir el formato de archivos a BSD. Obtendrás nombre de archivos largos, como mínimo doblarás la velocidad de acceso del disco, y mucha más estabilidad. Antes, necesitas rehacer las particiones. Puedes usar el comando fdisk o la utilidad /stand/sysinstall. Si es un disco pequeño que quieres dedicar enteramente a FreeBSD, solo tienes que eliminar la FAT y tabla de particiones, y usar el sistema de particiones de FreeBSD:

Puedes usar el comando disklabel o /stand/sysinstall para crear múltiples particiones BSD.

Finalmente, crea un nuevo sistema de archivos:

y montalo:

Sería una buena idea añadir una línea como esta en el archivo /etc/fstab para que solo tengas que teclear "mount /zip" las siguientes veces.

Las particiones DOS secundarias se encuentran después de TODAS las particiones primarias. Por ejemplo, si tienes una partición "E" como la segunda partición DOS en el segundo disco SCSI, necesitas crear los archivos especiales para el dispositivo 5 en /dev, y después montar /dev/da1s5:

Digital UNIX UFS CDROMs pueden ser montados directamente en FreeBSD. Montar particiones de disco de Digital UNIX y otros sistemas que soportan UFS puede ser más complejo, dependiendo de los detalles de la partición de disco del sistema operativo en cuestión.

Linux: 2.2 y posteriores soportan particiones ext2fs. Mira mount_ext2fs para más información.

NT: Existe un driver de solo lectura de NTFS para FreeBSD. Para más información, mira este tutorial de Mark Ovens en http://www.users.globalnet.co.uk/~markov/ntfs_install.html.

La idea general es que copies el primer sector de la partición root nativa de FreeBSD en un archivo en la partición DOS/NT. Asumiento que nombras a ese archivo como c:\bootsect.bsd puedes editar el archivo c:\boot.ini para conseguir algo como esto:

Este proceso asume que DOS, NT, FreeBSD o cualquier otro sistema ha sido instalado en sus respectivas particiones en el mismo disco. En nuestro caso, DOS y NT están en la primera partición y FreeBSD en la segunda. Instalamos FreeBSD para arrancarlo desde su partición nativa y no desde el disco MBR.

Monta un floppy formateado en DOS bajo la partición /mnt.

Rearranca en DOS o NT. Copia el archivo bootsect.bsd y/o el archivo bootsect.lnx del floppy a C:\. Modifica los atributos a boot.ini con:

Edita y añade las líneas apropiadas del boot.ini mostrado enteriormente de ejemplo, y vuelve a poner los atributos originales:

Si FreeBSD está arrancando desde el MBR, restauralo desde el comando fdisk después de reconfigurarlos para arrancar desde sus particiones nativas.

Si tienes FreeBSD y Linux en el mismo disco, solo tienes que seguir las instrucciones de instalación de LILO para arrancar un sistema operativo no Linux. Brevemente, son estas:

Arranca Linux, y añade las siguientes líneas en el archivo /etc/lilo.conf:

(Asumiendo que tu partición FreeBSD es conocida por Linux como /dev/hda2). A continuación, ejecuta lilo como root y ya debería estar.

Si FreeBSD está en otro disco, necesitas añadir ``loader=/boot/chain.b'' al archivo lilo.conf. Por ejemplo:

En algunos casos necesitarás especificar el número de disco en BIOS para que el cargador del boot funcione correctamente desde el segundo disco. Por ejemplo, si tu disco SCSI con FreeBSD es visto por el BIOS como disco 1, en el prompt del cargador de arranque necesitarás especificar:

En FreeBSD 2.2.5 y posteriores, puedes configurar boot(8) para que haga esto automaticamente.

El Linux+FreeBSD mini-HOWTO es una buena referencia para las opciones de interoperabilidad entre FreeBSD y Linux.

Instala el LILO al inicio de la partición de arranque del Linux en lugar de hacerlo en el "Master Boot Record". Así podrás arrancar el LILO desde BootEasy.

Si estas usando Windows-95 y Linux, también es recomendable hacer esto para simplificar el arranque de Linux en caso de que sea necesaria una reinstalación del Windows-95 (ya que no quiere convivir con otros sistemas operativos en el mismo Master Boot Record).

El proceso de instalación nos permite elegir dos métodos diferentes de particionar un disco. El sistema por defecto hace que el disco sea compatible con otros sistemas operativos en la misma máquina, usando las tablas de entrada de fdisk (llamadas "slices" en FreeBSD). Opcionalmente, podemos instalar un boot-selector que nos permite seleccionar el sistema operativo con el que queremos arrancar.

Mientras este es el caso más com&ún para gente proveniente del mundo de PC, para la gente proveniente del mundo Unix y quienes quieren instalar una máquina para funcionar con FreeBSD y solo FreeBSD, es más habitual usar el sistema de reservar todo el espacio del disco para un solo sistema operativo. Si seleccionas "A)ll FreeBSD" en el editor de fdisk de la utilidad sysinstall, y respondes la siguiente pregunta con "No", usarás este último sistema. Ten en cuenta que usando este sistema no te permitirá la instalación de ningún otro sistema operativo o selector de arranque (boot manager).

Entonces, ?por qué se llama "peligroso"?. Un disco en este modo no contiene lo que las utilidades normales de un PC considerarían una tabla de partición de archivos válida. Dependiendo del diseño de estas aplicaciones, puede que dañen el sector de arranque una vez entren en contacto con el disco. Por lo menos una BIOS Award usada por máquinas HP Netservers (pero no sólo por ellos) es concocida por ignorar los disco duros que no contengan lo que el BIOS entiende por una tabla de archivos válida.

Para volver un disco "peligrosamente dedicado" a formato estándar de PC, hay básicamente dos opciones. La primera es, escribes suficientes bytes NULL sobre el MBR para hacer que las siguientes instalaciones crean que están en un disco sín usar. Puedes hacer esto así:

Alternativamente, puedes hacer:

que instalará un nuevo master boot record.

La mejor manera es incrementar el tamaño de tu partición de swap, o usar esta excusa para añadir un otro disco nuevo.

Añadir swap en discos separados hace las cosas más rápidas que simplemente añadir swap en el mismo disco. Como ejemplo, si estás compilando código fuente en un disco, y el swap está en otro disco, es mucho más rápido que si el swap y la compilación se realizaran en el mismo disco. Esto es cierto específicamente para discos SCSI.

Los discos IDE no son capaces de permitir el acceso a ambos discos en el mismo canal al mismo tiempo (FreeBSD no soporta el modo 4, ya que todas las I/O de discos IDE son "programadas").

Es realmente muy mala idea instalar el swap sobre NFS a no ser que trabajes en una red muy rápida con un muy buen servidor.

Aquí hay un ejemplo para un archivo de swap de 64Mb /usr/swap0, piensa que puedes usar el nombre que quieras).

Asegurate que el kernel está compilado con la línea

en tu archivo de configuración. El kernel GENERIC la contiene.

Para activar el archivo de swap inmediatamente teclea

Por favor, revisa la sección de impresoras del manual. Cubre la mayoría de posibles problemas. Pásate por esta sección.

El programa de control de teclado tiene una opción para cargar el mapa de teclado. En el directorio /usr/share/syscons/keymaps hay diferentes archivos de mapas de teclado. Selecciona el que corresponde a tu sistema y cárgalo.

Tanto el directorio /usr/share/syscons/keymaps como la extensión .kbd son asumidas por la orden kbdcontrol.

Esto puede ser configurado en /etc/sysconfig (o rc.conf). Mira los comentarios correspondientes en el propio archivo.

En la versión 2.0.5R y posteriores, todo lo referente a fuentes, teclado, etc está en /usr/share/examples/syscons.

Actualmente se soportan los siguientes mapas de teclado:

El síntoma es:

Esto actualmente ocurre cuando estás intentando concatenar las particiones c'. El driver ccd requiere que la partición sea del tipo FS_BSDFFS. Edita la etiqueta del disco (disklabel) que estás intentando concatenar y cambia el tipo de partición a '4.2BSD'.

El síntoma es:

Esto es porque el disklabel retornado por el ccd es actualmente uno que no corresponde con el real. Puedes resolver este problema escribiendo explícitamente:

Sí, FreeBSD las soporta. Estas incluyen memoria compartida, mensajes y semáforos. Necesitas añadir las siguientes líneas en la configuración de tu kernel para activarlas.

Recompila e instala.

NOTA: Quizás necesites incrementar SHMMAXPGS a un número como 4096 (16M) si quieres usar GIMP. 256K es suficiente para la memoria compartida en X11R6.

La configuración de sendmail incluida en FreeBSD está preparada para sistemas que conectan directamente con Internet. Los sistemas que quieran usar UUCP para el envío de mail deben utilizar otro archivo de configuración.

Retocar /etc/sendmail.cf manualmente está considerado algo para puristas. La versión 8 de sendmail incluye un nuevo sistema de configuración llamado m4, en el cual la configuración se realiza en un nivel más alto. Deberías usar los archivos de configuración situados en

Si no instalaste tu sistema con el código fuente completo, el paquete de configuración de sendmail está en una distribución aparte. Asumiendo que tienes tu CD-ROM montado, haz:

No te preocupes, solo son unos cientos de kilobytes de tamaño. El archivo README en el directorio cf puede servir como introducción a la configuración del m4.

Para envío y recepción va UUCP, te aconsejamos usar la opción mailertable. Se basa en una base de datos que sendmail puede usar como base para tomar las decisiones de enrutado del mail.

Primero tienes que crear tu archivo .mc. Estos archivos se encuentran en el directorio /usr/src/usr.sbin/sendmail/cf/cf. Si miras, encontrarás algunos ejemplos. Asumiendo que tu archivo se llama foo.com, todo lo que necesitas hacer para convertirlo en un archivo sendmail.cf válido es:

Un archivo típico .mc sería algo como:

Las opciones nodns y nocanonify previenen del uso del DNS durante el tráfico de correo. La cláusula UUCP_RELAY se necesita por razones imperiosas, no preguntes :). Simplemente pon un nombre de máquina de Internet que sea capaz de gestionar pseudo-dominios .UUCP; más sencillo, entrarás el mail relay de tu ISP.

Una vez hayas hecho esto, necesitas el archivo llamado /etc/mailtertable. Un ejemplo típico sería:

Como puedes ver, esto es parte de un archivo real. Las tres primeras líneas manejan casos especiales donde el correo dirigido a un dominio no debe ser enviado a través de la ruta por defecto, si no a través de un UUCP vecino para acortar el path de envío. La siguiente línea gestiona el mail del dominio local para que sea enviado vía SMTP. Finalmente, los vecinos UUCP son anotados en la parte .UUCP pseudo-domains, para poder sobreescribir las reglas por defecto. La última línea es siempre un punto, que indica el mail gateway hacia el resto del mundo. Todos los nombres de nodos detrás de uucp-dom: deben ser vecinos válidos UUCP.

Como recordatorio de que este archivo debe ser convertido a una base de datos DBM antes de ser usada, la línea de comandos para realizar esta operación esta puesta como un comentario al inicio del archivo. Siempre tienes que ejecutar este comando cada vez que realices algún cambio en tu mailtertable.

Si no tienes la seguridad de que una ruta de correo vaya a funcionar correctamente, recuerda la opción -bt de sendmail. Esta opción arranca el sendmail en modo test; simplemente entra 0, seguido por la dirección de mail sobre la que quieres testear la ruta. La última línea te indica el agente interno, el host de destino y la dirección (posiblemente traducido). Sal de este modo tecleando Control-D.

Si tienes una dirección IP fija en la conexión, no necesitarás ajustar nada de lo que ya viene por defecto. Configura tu hostname como el nombre asignado a tu IP de Internet y sendmail hará el resto.

Si tienes direcciones IP asignadas dinamicamente y usas una conexión ppp a Internet, probablemente tendrás un buzón en el servidor de correo de tu proveedor. Supongamos que el dominio de tu proveedor es myisp.com, y tu nombre de usuario es user. Supongamos también que has llamado a tu máquina bsd.home y que tu proveedor te ha indicado que uses la máaquina relay.myISP.com como mail realy (gateway).

Para poder recoger el correo de tu buzón necesitarás instalar un agente de recogida de correo. Fetchmail es una buena opción ya que soporta diferentes protocolos. Normalmente se usa POP3. Puedes recoger automaticamente tu correo al realizar la conexión añadiendo la siguiente línea en el archivo /etc+ppp/ppp.linkup:

Asumimos que tienes una cuenta para user en bsd.home. En el home directory de user en bsd.home, crea el archivo .fetchmailrc:

No hace falta decir que este archivo no debe ser "leible" por nadie excepto user ya que contiene el password MySecret.

Para enviar el correo con la cabecera from: correcta, debes decirle al sendmail que use <user@myISP.com> en lugar de <user@bsd.home>. También deberías decirle al sendmail que envie todo el correo saliente a traves de relay.myISP.com, para una transmisión mucho más rápida.

El siguiente archivo .mc debe ser suficiente:

Mira en la sección anterior para los detalles de como convertir este archivo .mc en un sendmail.cf. No te olvides de rearrancar sendmail después de cada actualización del archivo sendmail.cf.

Tranquilo!!!. Simplemenre rearranca tu sistema, teclea -s en el prompt de arranque para entrar en modo monousuario. En la pregunta sobre el shell a usar, pulsa ENTER. Aparecerá un prompt #. Teclea mount -u / para remontar tu sistema de archivos en modo de lectura/escritura y a continuación teclea mount -a para montar todos los sistemas de archivos. Ejecura passwd root para cambiar el password de root. Teclea exit para continuar normalmente con el arranque.

Edita el mapa de teclado que estás usando para la consola y reemplaza las palabras boot por nop. El mapa de teclado por defecto es /usr/share/syscons/keymaps/us.iso.kbd. Por supuesto si usas otro mapa de teclado adecuado a tu país, tendrías que editarlo.

Simplemente usando este comando de perl:

file es el archivo a procesar. La modificación se hace en el propio archivo dejando el original grabado con extensión .bak.

Alternativamente puedes usar el comando tr(1)

dos-text-file es el archivo que contiene el texto DOS mientras que unix-file contendrá la salida convertida. Este sistema puede ser más rápido que usar perl.

Usa killall(1).

El error proviene de sistema del autentificación distribuida Kerberos. El problema no es fatal pero si molesto. Puedes ejecutar el comando su con la opcion -K, o desinstalar Kerberos como se describe en la siguiente sección.

Para eliminar Kerberos del sistema, reinstala la distribución bin de la release que estés usando. Si tienes el CDROM, puedes montar el cd (asumiremos que esta en /cdrom) y ejecutar:

Si tienes muchos usuarios de telnet, ssh, X, o de consola, probablemente terminarás desbordando el número de pseudoterminales del sistema. Aquí tienes como añadir más:

Entra en modo monousuario y a continuación vuelve a modo multiusuario.

En la consola haz:

Sandbox es un término de seguridad. Puede significar dos cosas:

UNIX implementa dos tipos de sandboxes. Uno es a nivel de procesos, y el otro es a nivel de usuarios (userid).

Cada proceso UNIX es totalmente independiente de cualquier otro proceso UNIX. Un proceso no puede modificar el espacio de direcciones de otro. Es diferente a los sistemas Windows en los que un proceso puede sobreescribir facilmente el espacio de direcciones de otro proceso, probocando una caida de la máquina.

Un proceso UNIX es propiedad de un userid determinado. Si el userid no es el usuario root, éste solo podrá acceder a los procesos de su propiedad, evitando la intrusión en procesos ajenos. El userid también se usa como sistema de protección para datos grabados en disco.

La manera más fácil es, simplemente, especificar que quieres usar las X durante el proceso de instalación.

Entonces, lee y sigue la documentación de la herramienta xf86config, la cual te ayuda a configurar el sistema XFree86 sobre las características propias de tu sistema (tarjeta de vídeo , ratón, etc).

Quizás te interesaría investigar y probar el servidor Xaccel, disponible a un precio muy razonable. Mira en la sección Xi Graphics o Metro Link para más detalles.

Si estás usando syscons (el driver de consola por defecto), puedes configurar FreeBSD para soportar un ratón en cada consola virtual. Para evitar conflictos con las X, syscons soporta un dispositivo virtual llamado /dev/sysmouse. Todos los eventos recibidos desde el mouse real son escritos en el dispositivo sysmouse, usando el protocolo MouseSystems. Si quieres usar el ratón en una o más consolas virtuales y usar las X, te recomendamos la siguiente configuración:

Hay gente que prefiere usar /dev/mouse bajo X. Para que esto funcione, /dev/mouse debe estar lincado a /dev/sysmouse:

Intenta desactivar la tecla Num Lock.

Si tu tecla Num Lock está activada por defecto al arrancar el sistema, deberías añadir la siguiente línea en la sección Keyboard del archivo XF86Config.

Las consolas virtuales te permiten tener sesiones simultáneas en la misma máquina sin necesidad de tener montajes complicados como una red o ejecución de X.

Cuando el sistema arranca, mostrará el prompt de login en el monitor una vez finalizado el mismo. Puedes entonces teclear tu login y password y empezar a trabajar (o jugar), en la primera consola virtual.

En algun momento, es probablemente querras iniciar otra sesion , por ejemplo, para mirar la documentación de un programa que estás ejecutando, o para leer el correo mientras esperas que termine una sesión ftp que tienes establecida. Solo haz Alt-F2 y encontrarás un prompt un prompt de login esperandote en la segunda "consola virtual". Cuando quieras volver a la sesión original, sólo tienes que pulsar Alt-F1.

La instalación por defecto de FreeBSD tiene tres consolas virtuales activadas, y Alt-F1, Alt-F2 y Alt-F3 cambian entre ellas.

Para activar más consolas virtuales, edita /etc/ttys y añade tantas entradas como consolas virtuales quieras a partir de ttyv4, después del comentario "Virtual Terminals":

Utiliza tantas consolas como quieras o necesites. Cuantas más consolas tengas, más recursos utilizas; esto puede ser importante si tienes 8MB de RAM o menos. También te puede interesar cambiar el modo secure a insecure.

NOTA IMPORTANTE si quieres usar un servidor X DEBES dejar, al menos, un terminal virtual sin usar (o desactivado).

La manera más fácil de desactivar una consola es "apagarla". Por ejemplo, para desactivar el terminal 12, cambia esto:

por esto:

Si tu teclado solo tiene 10 teclas de función, tendras que acabar con:

(También puedes, simplemente, borrar estas líneas.)

Una vez has editado el archivo /etc/ttys, el siguiente paso es asegurarte de que tienes suficientes dispositivos de terminales virtuales. La manera más fácil de hacerlo es:

A continuación, la manera más fácil de activar las consolas virtuales es rearrancar el sistema. Si, realmente no quieres rearrancarlo, puedes para el servidor de X Window y ejecutar (como root):

Es imperativo que pares el servidor de X Window si está funcionando, antes de ejecutar este comando. Si no lo haces, parecerá que tu sistema está parado/colgado después de ejecutar el comando kill.

Si la consola está actualmente mostrando X Window, puedes usar Ctrl-Alt-F1, etc, para cambiar entre las consolas virtuales. Ten en cuenta que una vez pases de una consola X Window a un terminal virtual, solo tienes que usar la tecla Alf- para volver a conmutar entre terminales virtuales o volver a las X. No necesitas pulsar la tecla Ctrl. Si usas la tecla Ctrl para volver a las X en alguna de las releases antiguas, puedes encontrarte que la consola de texto está bloqueada. Pulsa la tecla Ctrl de nuevo para desbloquearla.

Existen dos escuelas sobre como arrancar el xdm . Una escuela arranca el xdm desde el archivo /etc/ttys usando el ejemplo dado, mientras que la otra simplemente arranca el xdm desde el archivo rc.local o desde un script X.sh en /usr/local/etc/rc.d. Ambos métodos son igualmente válidos, y uno puede funcionar en situaciones que el otro no. En ambos casos el resultado es el mismo: el sistema X Window lanzará un prompt de login gráfico.

El método ttys tiene la ventaja de documentar en que vty se lanzarán las X pasando la responsabilidad de rearrancar el servidor X al hacer el logout al proceso init. El método rc.local hace más fácil terminar con el proceso xdm en caso de problemas con el servidor X.

Si arrancamos desde rc.local, xdm debe ser arrancado sin argumentos (como un daemon). xdm debe arrancar DESPUES del proceso getty, o ambos entrarán en conflicto bloqueando la consola. La mejor manera de evitar este problema es tener un script que retrase el arranque de xdm durante 10 segundos.

Una versión previa de esta FAQ decía que debías añadir el terminal virtual usado por las X al archivo /usr/X11R6/lib/X11/xdm/Xservers. Esto no es necesario: las X usarán el primer terminal virtual que encuentre libre.

Si arrancas las X con startx, los permisos en /dev/console no serán cambiados, resultando en cosas como que xterm -C y xconsole no funcionen.

Esto se debe a la manera en que son fijados los permisos de la consola. En un sistema multiusuario, podemos no querer que cualquier usuario pueda escribir en la consola de sistema. Para usuarios que realizan logins directamente desde una máquina con un VTY, existe el archivo fbtab para resolver estos problemas.

Asegúrate de que existe al menos una línea como esta sin comentar:

Está en /etc/fbtab y asegurará que cualquiera que realice un login en /dev/ttyv0 será el propietario de la consola.

Tu ratón y el driver de ratón quizás estén fuera de sincronización.

En versiones 2.2.5 y anteriores, conmutando entre sesiones X y sesiones de terminales virtuales, podía provocar una desincronización. Si el problema ocurre muy amenudo, deberías añadir la siguiente opción en el archivo de configuración de tu kernel y recompilarlo.

Mira la sección creando un kernel si no tienes experiencia en compilar nuevos kernels.

En versiones 2.2.6 y posteriores, el chequeo de sincronización es realizado de otra manera, y es estándar en el driver de ratón PS/2. Aun así, en casos extraños puedes llegar a ver mensajes de error de sincronización como este:

y parecer que tu ratón no funciona adecuadamente.

Si esto ocurre, desactiva el código de chequeo de sincronización poniendo los flags del driver PS/2 a 0x100. Entra en UserConfig poniendo la opción -c en el prompt de arranque:

Entonces, en la línea de comando de UserConfig, teclea:

Hemos recibido reportes de que algunos modelos de ratones PS/2 de MouseSystems solo trabajan si están configurados en modo "alta resolución".

Desafortunadamente no hay solución para versiones 2.0.x y 2.1.x. En versiones 2.2.x, aplica el siguiente parche en /sys/i386/isa/psm.c y compila un nuevo kernel.

En versiones 2.2.6 o posteriores, especifica el flag 0x04 al driver PS/2 para poner el ratón en modo de alta resolución. Entra en UserConfig:

y en la línea de comandos teclea:

Mira en la sección anterior para posibles causas de problemas con los ratones.

Imake.tmpl es parte del package Imake, una aplicación estándar de compilación de X. Tanto Imake como headers y otros archivos necesarios para compilar aplicaciones X están en la distribución de programación X. Puedes instalarla desde el sysinstall o manualmente desde los archivos de la distribución X.

Ejecuta el comando xmodmap -e "pointer = 3 2 1" desde el archivo .xinitrc o .xsession.

Justo antes de la publicación de FreeBSD 3.1 se añadió una nueva característica que permite mostrar "splash screens" durante los mensajes de arranque del sistema. Los "splash screen" deben ser un bitmap de 256 colores (*.BMP) o ZSoft PCX (*.PCX). Además, deben tener una resolución de 320x200 o inferior para poder trabajar en controladoras VGA estándares. Si se compila el soporte VESA en el kernel, se pueden usar bitmaps de hasta 1024x768. Recordar que el soporte de VESA requiere que la opción VM86 sea compilada en el kernel. El soporte actual de VESA puede ser compilado directamente en el kernel con la opción de configuración VESA o cargando el módulo kld VESA durante el arranque.

Para usar un "splash screen" necesitas modificar los archivos de inicio que controlan el proceso de arranque de FreeBSD. Estos archivos cambiaron con FreeBSD 3.2, así que ahora existen dos maneras de cargar un "splash screen":

Ahora todo lo que necesitas es un "splash screen". Puedes navegar por una inmejorable galería en http://www.cslab.vt.edu/~jobaldwi/splash/.

"Diskless booting" significa que una máquina FreeBSD sea arrancada sobre una red, y lea los archivos necesarios de un servidor y no desde su disco duro. Para más detalles, por favor, lee la sección diskless booting del manual

Los estándares de Internet y las buenas prácticas de ingeniería nos prohiben proveer el forward de paquetes en la distribución estándar. Aun así, puedes activar esta opción cambiando la siguiente variable a YES en el archivo rc.conf:

Esta opción pondrá la variable sysctl net.inet.ip.forwarding a 1.

En muchos casos también necesitarás ejecutar un proceso de rutado para indicar la existencia en la red de tu router; FreeBSD incluye el daemon estándar de rutado BSD routed, aunque en situaciones más complejas quizás quieras usar GaTeD disponible en http://www.gated.org/

Es nuestro deber advertirte que estando FreeBSD configurado de esta manera, no cumple completamente con todos los estandares de routers de Internet, pero es suficiente para uso ordinario.

Típicamente, la gente que pregunta esto tiene dos pc's en casa, uno con FreeBSD y otro con Win95; la idea es usar FreeBSD para conectar a Internet y luego ser capaz de acceder a Internet desde el computador con Windows 95. Este es realmente un caso especial de la pregunta anterior.

Hay un útil documento disponible que explica como configurar FreeBSD como un Router PPP

NOTA: Esto requiere, al menos, tener dos direcciones IP fijas disponibles, y posiblemente tres o más, dependiendo del número de máquinas que quieras conectar. Como alternativa, si no tienes una dirección IP fija, puedes usar una de las subredes privadas e instalar un proxy como SQUID y The TIS firewall toolkit en tu FreeBSD.

Mira también la sección natd.

Hay un conflicto entre el archivo cdefs.h incluido en la distribución de BIND y el distribuido con FreeBSD. Solo tienes que borrar compat/include/sys/cdefs.h.

Sí. Mira las paginas man de slattach, sliplogin, pppd y ppp. pppd y ppp soportan conexiones entrantes y salientes. Sliplogin trabaja exclusivamente con conexiones entrantes y slattach con conexiones salientes.

Estos programas son descritos en las siguientes secciones del manual:

Si solo tienes acceso a Internet a traves de un "shell account", quizás quieras mirar el package slirp. Puede darte un (limitado) acceso a servicios como ftp y http.

Si tienes una red local (una o más máquinas), pero solo se te ha asignado una única dirección IP desde tu proveedor de Internet (o si recibes las direcciones de manera dinámica), te interesa mirar el programa natd. Natd te permite conectar una red entera a Internet usando solamente una dirección IP.

El programa ppp tiene una funcionalidad similar incluida, a través del parámetro -alias. La librería alias es usada en ambos casos.

En el sistema de trabajo de red de Berkeley, los interfaces de red solo son directamente accesibles por el código del kernel. Por favor, mira el archivo /etc/rc.network y los man de los programas de red allí mencionados. Si esto te deja totalmente confundido, entonces tendrías que conseguir algun libro de administración de red de cualquier sistema operativo basado en BSD; con algunas excepciones significativas, administrar el sistema de red en FreeBSD es básicamente igual que en SunOS 4.0 o Ultrix.

Añade ``netmask 0xffffffff'' en el comando ifconfig como el siguiente:

Si quieres usar los otros puertos, tendrás que especificar parámetros adicionales en el comando ifconfig. El puerto por defecto es link0. Para usar el puerto AUI en lugar del BSN, usa link2. Estos flags tendrían que ser especificados usando las variable ifconfig_* en el archivo /etc/rc.conf.

Algunas tarjetas de red son mejores que otras y algunas veces pueden causar problemas con aplicaciones de uso intensivo de red como NFS

Mira la entrada en el manual de NFS para más información sobre este tema.

Algunas versiones de NFS para Linux solo aceptan peticiones para montar unidades hechas desde un puerto privilegiado; intenta:

Las estaciones de trabajo Sun con SunOS 4.x solo aceptan peticiones de montar unidades hechas desde puertos privilegiados; intenta

Intenta desactivar las extensiones TCP en url="http://www.FreeBSD.org/cgi/man.cgi?rc.conf" name="/etc/rc.conf"> cambiando la siguiente variable a NO:

Las máquinas Xylogic's Annex también tienen este problema, por lo que tienes que hacer el mismo cambio para conectar con ellas.

Las operaciones multicast están totalmente soportadas en FreeBSD 2.0 y superiores. Si quieres usar tu máquina como router multicast, necesitarás cargar el módulo de kernel ip_mrouted_mod y ejecutar el programa mrouted.

Para más información:

Aquí tienes una lista hecha por Glen Foster:

Probablemente el host estará en un dominio diferente; por ejemplo, si estás en el dominio foo.bar.edu y quieres encontrar un host llamado "mumble" en el dominio bar.edu, tendrás que llamarlo por su nombre de dominio, "mumble.bar.edu", en vez de solo "mumble".

Tradicionalmente, esto era permitido por los resolvers BIND BSD. La versión actual de bind que se incluye en FreeBSD no resuelve abreviaciones de nombres para hosts fuera de nuestro dominio.

Si tienes el kernel compilado con la opción IPFIREWALL . debes tener en cuenta que la política por defecto es denegar explícitamente todos los paquetes que no están explícitamente permitidos.

Si involuntariamente has desconfigurado el firewall de tu sistema, puedes restaurar la operatibilidad de la red tecleando el siguiente comando como usuario root:

Para más información en la configuración del firewall de FreeBSD, mira la sección del manual.

Esta respuesta depende mucho en las reglas definidas y en la versión del procesador. Para la mayoría de aplicaciones que tienen que ver con la ethernet y pequeñas reglas, la respuesta es, prácticamente nada.

Aquí tienes una lista de cosas a tener en cuenta para crear reglas de filtrado eficientes:

Puedes redirigir peticiones FTP (y otros servicios) con el package "socket", disponible en la colección de ports categoría "sysutils". Simplemente tienes que reemplazar la línea del servicio correspondiente en el archivo /etc/services de la siguiente manera:

donde "ftp.foo.com" y "ftp" son la máquina y puerto de destino.

Existen dos herramientas de control de ancho de banda para FreeBSD. ALTQ es gratis; Bandwidth Manager de Emerging Technologies es un producto comercial.

El driver Berkeley Packet Filter (bpf) necesita ser activado para ejecutar programas que lo utilizan. Añade esto al archivo de configuración de tu kernel y crea uno nuevo:

A continuación, después de rearrancar tendrás el dispositivo. Esto puede hacerse entrando en el directorio /dev y ejecutando el siguiente comando:

            # sh MAKEDEV bpf0
          

Por favor, mira la entrada correspondiente en el handbook para más información sobre la creación de dispositivos.

Primero deberías leer el man de ppp y la sección de PPP del handbook. Activa los logs con el comando

Este comando debería ser tecleado en el prompt del ppp o incluirse en el archivo de configuración /etc/ppp/ppp.conf (al inicio de la sección default es el mejor lugar). Asegurate que el archivo url="http://www.FreeBSD.org/cgi/man.cgi?syslog.conf" name="/etc/syslog.conf"> contiene las siguientes líneas:

y que el archivo /var/log/ppp.log existe. Puedes encontrar mucha información sobre lo que está pasando en las conexiones con el archivo de log.

Si tu versión de ppp no entiende el comando "set log" deberías bajarte la última versión. Esta compilará sin problemas en FreeBSD 2.1.5 y superiores.

Esto ocurre normalmente por que no se puede resolver el nombre de la máquina. La mejor manera de solucionar este problema es asegurarse que el sistema use en primer lugar el archivo /etc/hosts para hacer la resolución de nombres. Para ello, basta con editar el archivo /etc/host.conf y poner la línea hosts en primer lugar. A continuación, simplemente hay que añadir una línea para la máquina local en el archivo /etc/hosts. Si no existe una red local, modificar la línea localhost:

Añadir otra línea para la máquina local. Consultar las páginas man relevantes para más detalles.

Ahora se debería poder ejecutar el siguiente mandato de forma satisfactoria ping -c1 `hostname`.

Primero, asegúrate de tener una ruta por defecto. Ejecutando el comando url="http://www.FreeBSD.org/cgi/man.cgi?netstat"> name="netstat -rn"> deberías ver dos entradas como estas:

Esto es asumiendo que hayas usado las direcciones del manual, la página man o del archivo de ejemplo ppp.conf.sample. Si no tienes una ruta por defecto, puede ser por que estés usando una versión antigua de ppp que no entiende la palabra HISADDR en el archivo ppp.conf. Si tu versión de ppp es de antes de FreeBSD 2.2.5, cambia la línea

por otra diciendo

Otra razón para la inexistencia de la ruta por defecto es que sin darte cuenta hayas creado un default router en el archivo /etc/rc.conf (anteriormente llamado /etc/sysconfig) y hayas omitido la línea

en el archivo ppp.conf. Si es este el caso vuelve a la sección configuración final del sistema en el handbook.

Este error se debe normalmente a la falta de la sección

en el archivo /etc/ppp/ppp.linkup. Esto es solo necesario si tienes una direccion IP dinámica o no sabes la dirección de tu gateway. Si estás usando el modo interactivo, puedes teclear lo siguiente despues de entrar en packet mode:

Pásate por la sección PPP y direcciones IP dinámicas del handbook para más información.

El timeout de ppp por defecto es de 3 minutos. Se puede ajustar con la línea:

Donde NNN es el número de segundos de inactividad antes de cerrar la conexión. Si NNN es 0, la conexión no se cerrará nunca por timeout. Es posible poner este comando en el archivo ppp.conf, o teclearla en el prompt del modo interactivo. También es posible ajustarla en cualquier momento mientras la conexión esté activa conectando al socket del servidor ppp usando telnet o pppctl. Leete el man de ppp para más detalles.

Si tienes la opción Link Quality Reporting (LQR) configurada es posible que demasiados paquetes LQR se pierdan entre tu máquina y el remoto. PPP deduce que la línea es mala y corta la conexión. En versiones anteriores a la 2.2.5 de FreeBSD, LQR estaba activado por defecto. Ahora está desactivado por defecto. LQR puede ser activado con la línea

Algunas veces, en líneas telefónicas de baja calidad o con mucho ruido, o líneas con la opción de llamada en espera activada, el módem corta la conexión por que piensa (erróneamente) que ha perdido la portadora.

Hay una opción en muchos modems para determiar la tolerancia a pérdidas temporales de portadora. En un USR Sportster por ejemplo, esta es medida por el registro S10 en décimas de segundo. Para hacer que tu módem sea más resistente, puedes añadir la siguiente secuencia "send-expect" a la cadena de llamada:

Mira en el manual de tu módem para más detalles.

En versiones anteriores a FreeBSD 2.2.5, una vez estaba la conexión establecida, ppp espera a que el remoto inicie la negociación LCP (Line Control Protocol). Muchos proveedores de Internet no iniciarán la negociación esperando que sea el cliente el que lo haga. Para forzar al ppp a iniciar el LCP, usa la siguiente línea:

Nota: Normalmente no hay problemas si las dos partes inician la negocioacion LCP, ya que el modo abierto (open mode) está activo por defecto. De todas maneras, la siguiente sección explica cuando pueden haber problemas.

Ocasionalmente, justo después de la conexión, puedes ver mensajes en el log referentes a "magic number is the same". Algunas veces, estos mensajes son inofensivos, y otras veces uno de los dos extremos finaliza la conexión. Algunas implementaciones de ppp no pueden solucionar este problema, y, aunque parezca que la conexión está establecida, verás repetidas peticiones y aceptaciones de configuración en el archivo de log hasta que una de las dos partes cierra la conexión.

Esto ocurre normalmente en servidores con disco lentos que tienen problemas para gestionar eficientemente los puertos serie. También existen informes de problemas en conexiones mediante slip. La razón es que en el tiempo que tarda el servidor en salir del getty y ejecutar el ppp, el cliente manda los paquetes de inicio LCP. Al estar el ECHO todavía activo en el puerto del servidor, el cliente ppp lo único que ve son sus propios paquetes "reflejados" por el servidor.

Una parte de la negociación LCP es establecer un número mágico para cada una de los dos extremos de las conexiones para que los "reflejos" puedan ser detectados. El protocolo dice que cuando el remoto intenta negociar el mismo "magic number", se debe enviar un NAK para seleccionar un nuevo "magic number". Durante el periodo de tiempo que el servidor tiene el ECHO activado en el puerto, el cliente ppp envía paquetes LCP, ve que el mismo "magic" vuelve en el paquete reflejado y lo da como no válido (envia NAK). Este todavía ve el paquete reflajado con NAK (lo que significa que el ppp debe cambiar su "magic"). Esto produce un enorme número de cambios de "magic number" que son introducidos en el buffer tty del servidor. Tan pronto como el ppp arranca en el servidor, es bombardeado con cambios de "magic numbers" e inmediatamente decide que ya ha realizado el número suficiente de negociaciones LCP y corta la conexión. Mientras tanto, el cliente, que ya no ve los paquetes reflejados, recibe sin problemas la desconexión del servidor y también cierra la conexión.

Esto puede ser resuelto permitiendo que el remoto inicie la negociación, poniendo la siguiente línea en el archivo ppp.conf:

Esto indica al ppp que espere a que el servidor comience la negociación LCP. Es posible que algunos servidores nunca inicien la negociación. Si este es el caso, puedes hacer algo como:

Esto le indica al ppp que sea pasivo durante 3 segundos, y despues comience a enviar peticiones LCP. Si el remoto envía peticiones durante este periodo, ppp responderá inmediatamente sin esperar los 3 segundos establecidos.

Existe actualmente un problema de implementación en ppp en la que no asocia las respuestas LCP, CCP & IPCP con sus peticiones originales. Como resultado, si una implementación ppp es más lenta durante 6 segundos que la remota, la remota enviará dos peticiones de configuración LCP adicionales. Esto es fatal.

Considera dos implementaciones, A y B. A empieza a enviar peticiones LCP inmediatamente después de conectar y B tarda 7 segundos en arrancar. Cuando B arranca, A ha enviado 3 peticiones LCP. Estamos asumiendo que la línea tiene el ECHO desactivado, si no, veriamos los problemas de "magic number" descritos en el apartado anterior. B envía un REQ, y a continuación envía un ACK al primer REQ de A. Esto resulta en que A entra en modo OPENED y envía un ACK (el primero) a B. Mientras, B devuelve dos ACKs más en respuesta a los dos REQs adicionales enviados por A antes de que B arrancase .B recibe el primer ACK de A y entra en modo OPENED. A recibe el segundo ACK de B y vuelve al estado REQ-SENT, enviando otro (el cuarto) REQ. Entonces recibe el tercer ACK y entra en modo OPENED. Mientras, B recibe el cuarto REQ de A, produciendo que vuelva de nuevo al estado ACK-SENT y enviando otro (el segundo) REQ y (cuarto) ACK. A recibe el REQ, entra en modo REQ-SENT y envía otro REQ. Inmediatamente recibe el siguiente ACK y entra en OPENED.

Esto pasa hasta que una de las partes piensa que ya ha realizado suficientes reintentos y corta la conexión.

La mejor manera de evitar esto es configurar una de las partes de manera pasiva - que es, hacer que una de las partes espere a que la otra comience la negociación. Esto puede realizarse con el comando:

Se debe tener cuidado con esta opción. También se puede usar:

para limitar el número de veces que ppp espera a que el remoto comience la negociación. Alternativamente, puedes user el comando:

donde N es el número de segundos que espera antes de empezar la negociación. Mira en el manual para más detalles.

Antes de la versión 2.2.5 era posible que la conexión se corte nada más iniciarse debido a un problema en la negociación de compresión Predictor1. Esto solo pasa si las dos partes intentan negociar con diferentes protocolos de control de compresión (CCP). Este problema ya está corregido, pero si estás usando una versión antigua de ppp, el problema puede solucionarse con la línea

Cuando ejecutas el comando shell o !, ppp ejecuta un shell (o si has pasado argumentos, ppp ejecutará esos argumentos). Ppp esperará a que se complete el comando antes de continuar. Si intentas usar la conexión ppp mientras se ejecuta el comando, parecerá que la conexión se ha colgado. Esto es por que ppp está esperando a que se complete la ejecución del comando.

Si quieres ejecutar comandos como este, usa el comando !bg en su lugar. Esto ejecutará el comando en background, y ppp continúa sin problemas con la conexión.

No hay manera que ppp detecte automáticamente que una conexión directa se ha cortado. Es debido a las líneas que se usan en un cable serie null-modem. Cuando usamos este tipo de conexión, LQR debería estar siempre activada con el comando

LQR es aceptado por defecto si es negociado por el remoto.

Si ppp llama inesperadamente, debes determinar la causa, y poner filtros (dfilters) para prevenir esas llamadas.

Para determinar la causa, usa la siguiente línea:

Esto guardara todo el tráfico que pase a través de la conexión. La próxima vez que se realice una llamada no deseada, podrás ver la causa convenientemente guardada.

Ahora puedes desactivar las llamadas producidas por esa causa. Usualmente, este tipo de problemas se debe a consultas de DNS. Para prevenir que las consultas de DNS puedan establecer conexiones usa la siguiente línea (esto no hará que los paquetes de DNS queden parados cuando la conexión está establecida):

Esto no siempre es aconsejable, ya que puede afectar a la capacidad de realizar conexiones bajo demanda - muchos programas necesitan hacer una consulta al DNS antes de poder realizar cualquier operación.

En el caso del DNS, deberías determinar que es lo que está intentando realizar esas consultas de DNS. Muchas veces, sendmail es el culpable. Debes asegurarte configurar el sendmail de manera que no realice ninguna consulta al DNS. Mira la sección Configuracion de correo para tener más detalles acerca de como crear una archivo propio de configuración de sendmail. También deberías añadir la siguiente línea en tu archivo .mc:

Esto hara que sendmail encole todo el correo hasta que no se procese la cola (usualmente, sendmail es invocado con "-bd -q30m", indicandole que procese la cola cada 30 minutos) o hasta que se ejecuta el comando "sendmail -q" (por ejemplo, desde el archivo ppp.linup).

Sigo viendo los siguientes errores en el archivo de log:

Esto es porque ppp está intentando negociar compresión Predictor1, y el remoto no quiere negociar ningún tipo de compresión. Estos mensajes son sin importancia, pero si quieres eliminarlos, puedes desactivar la compresión Predictor1 localmente:

En la versión FreeBSD 2.2.2 y anteriores, había un problema en el driver tun que no permitía paquetes entrantes con un tamaño mayor que el MTU del interface. La recepción de un paquete mayor que el MTU resulta en un error IO que es logueado vía syslogd.

La especificación PPP dice que un MRU de 1500 siempre debería ser aceptada como mínimo, a pesar de lo que se negocie mediante LCP, de todas maneras, es posible que hayas disminuido el MTU por debajo de 1500 y tu proveedor te esté enviando paquetes de 1500, haciendo que tu conexión se bloquee.

El problema puede solucionarse haciendo que el tamaño del MTU nunca sea inferior a 1500 bajo FreeBSD 2.2.2 y anteriores.

Para loguear todas las líneas de "conversación" de tu módem, debes activar la siguiente opción:

Esto hará que ppp loguee todo hasta la última cadena "expect" pedida.

Si quieres ver la velocidad de tu conexión y usas PAP o CHAP (y por lo tanto no tienes nada que "chatear" después del CONNECT en el script de marcado), debes estar seguro de indicarle al ppp que espera la línea "CONNECT con algo como esto:

Aquí, tenemos nuestro CONNECT, enviamos nada, y esperamos un salto de línea, forzando al ppp que lea la respuesta del CONNECT.

PPP lee cada línea de los archivos de configuración para poder interpretar cadenas como set phone "123 456 789" correctamente. Para especificar un carácter ``"'', debes usar la contrabarra (``\'').

Cuando el intérprete lee cada argumento, reinterpreta el argumento para buscar alguna secuencia especial de escape como ``\P'' o ``\T''. Como resultado de esta doble lectura, recuerda que has de usar el número correcto de escapes (contrabarras).

Si quieres enviar un caracter ``\'' a tu módem, necesitas hacer algo como:

resultando en la siguiente secuencia:

o

resultando en la siguiente secuencia:

Ppp (o cualquier otro programa de este tipo), nunca deberían hacer un core dump. Por que ppp funciona con un id de usuario 0, el sistema operativo no escribirá la imagen del core en disco. Si ppp termina con errores de "segmentation violation" o cualquier otra señal que normalmente causa un core dumped, y quieres poder hacer un debug de ese core, asegúrate de usar la última versión de ppp, y haz lo siguiente:

Ahora tendrás instalada una versión "debuggable" de ppp. Tendrás que ser root para poder ejecutar ppp ya que todos sus privilegios han sido revocados. Cuando arranques ppp, acuerdate del directorio en el que te encuentras.

Ahora, cuando ppp recibe una violación de segmentación , creará un archivo core llamado ppp.core. A continuación , deberías hacer lo siguiente:

Toda esta información puede hacer posible diagnosticar el problema. Si estás familiarizado con gdb, puedes encontrar otras pistas como que causó el dump y las direcciones y valores de las variables más relevantes.

Este es un problema conocido cuando ppp está configurado para negociar una IP dinámica local con el remoto. Este problema ha sido solucionado en la última versión - busca en el man la palabra iface.

El problema era que cuando el programa inicial llama a connect(2), el IP del interface tun es asignado al punto final del socket. El kernel crea el primer paquete saliente y establece la conexión. Si, como resultado de la asignación dinámica de IP, la dirección del interface es cambiada, el punto final del socket original será invalido. Los siguientes paquetes enviados al remoto normalmente serán descartados. Aun si no lo son, cualquier respuesta no será enrutada hacia la máquina de origen por que la dirección IP de la máquina de origen ha cambiado.

Hay varias maneras teóricas de solucionar este problema. Lo mejor sería que el remoto reasignase la misma IP si fuese posible :-) La versión actual de ppp hace esto, pero otras muchas implementaciones no.

El método más sencillo desde nuestra parte, sería no cambiar nunca la IP del interface tun, pero por el contrario, cambiar todos los paquetes salientes de manera que la ip de origen es cambiada del IP del interface a la IP negociada, instantaneamente. Esto es, esencialmente, lo que hacen libalias(3) y el parámetro -alias de ppp.

Otra alternativa (y probablemente la más eficaz) es implementar una llamada al sistema que cambie todos los sockets de una IP a otra. Ppp debería usar esta llamada para modificar los sockets de todos los programas existentes cuando una nueva dirección IP es negociada. La misma llamada de sistema podría ser usada para clientes dhcp cuando son forzados a rehacer sus sockets.

Una tercera opción es permitir que un interface se active sin IP. Los paquetes salientes tendrían un IP de 255.255.255.255 hasta que el primer SIOCAIFADDR ioctl este hecho. Esto permitiría que ppp cambiase el IP de origen, pero solo si el socket es 255.255.255.255 y solo el IP y el checksum necesitan cambiar. Esto, de todas maneras, requiere tocar el kernel para que puede enviar paquetes incorrectos a un interface mal configurado.

La razón por la que muchos de los juegos no funcionan es por que la máquina externa intentará abrir una conexión o enviar paquetes UDP (no solicitados) a la máquina interna. El software "alias" no sabe que esos paquetes debrín enviarse a la máquina interna.

Para que las cosas funcionen, asegúrate que la única cosa que está funcionando es el software con el que tienes problemas, entonces ejecuta tcpdump en el interface tun del gateway o ejecuta el log tcp/ip del ppp ("set log +tcp/ip" en el gateway.

Cuando arrancas el software que no funciona, deberís ver paquetes que pasan a través del gateway. Cuando algo vuelve del exterior, será rechazado (ese es el problema). Apunta el número de puerto de esos paquetes y cierra el software que no funciona. Haz esto varias veces para comprobar si el número de puerto se repite. Si es así, la siguiente línea en el archivo de configuración del ppp /etc/ppp/ppp.conf hará que las cosas funcionen:

donde "proto" puede ser "tcp" o "udp", "internalmachine" es la máquina a la que quieres que los paquetes sean enviados y "port" es el número de puerto de destino de los paquetes.

No podrás usar ese software en otras máquinas sin modificar el comando anterior, y ejecutar el software simultaneamente en dos máquinas internas no será posible - después de todo, el mundo exterior está viendo a toda tu red como una sola máquina.

Si los números de puertos no se repiten, hay tres opciones más:

1) Desarrollar el soporte en libalias. Ejemplos de estos "casos especiales" los puedes encontrar en /usr/src/lib/libalias/alias_*.c (alias_ftp.c es un buén prototipo). Esto usualmente supone leer ciertos paquetes salientes conocidos, identificando la instrucción que le indica a la máquina exterior que inicie una conexión con la máquina interna en un puerto específico (aleatorio) y configurar un "ruta" en la tabla de alias para que los paquetes siguientes sepan donde ir.

Esta es la solución más difícil, pero es la mejor y hará que el software funcione con múltiples máquinas.

2) Usar un proxy. La aplicación debe soportar socks5 por ejemplo, o (como en el caso del "cvsup") debería tener una opción "pasiva" que evita que el remoto intente abrir conexiones con la maquina local.

3) Redireccionar todo el tráfico a la máquina interna usando "alias addr". Esta es la solución más sencilla.

Todavía no, pero se podría hacer, si hay interés. En cada ejemplo, internal debe ser reemplazado por la dirección IP de la máquina que va a estar jugando.

FCS significa Frame Check Sequence. Cada paquete ppp tiene un checksum añadido para asegurar que los datos que se reciben son los datos que han sido enviados. Si el FCS de un paquete entrante es incorrecto, el paquete es rechazado y se incremente el contador HDLC FCS. Los valores de error HDLC se pueden visualizar usando el comando show hdlc.

Si tu conexión es mala (o si tu driver serie está rechazando paquetes), verás errores FCS ocasionales. En general no tienes porque preocuparte de ellos. Si tienes un módem externo, asegúrate que el cable está correctamente aislado de interferencias - esto debería erradicar el problema.

Si tu conexión se corta tan pronto como has conectado y ves gran cantidad de errores FCS, puede ser por que ti conexión no es de 8 bits. Asegúrate de que tu módem no está usando control de flujo (XON/XOFF) por software. Si tu conexión de datos debe usar control de flujo por software, usa el comando set accmap 0x000a0000 para indicar al ppp que "escape" los carácteres ^Q y ^S.

Otra razón para ver muchos errores FCS puede ser que el remoto haya dejado de "hablar" PPP. Deberís activar el log asíncrono para determinar si los datos entrantes son de un login o un prompt de shell. Si tienes un prompt de shell en el extremo de la conexión, es posible terminar el ppp sin cortar la conexión usando el comando close clp (usando el comando term podrás conectar de nuevo con el shell de la máquina remota.

Si no hay nada en el log que indique por que se ha terminado la conexión, deberís preguntar al administrador del sistema remoto porqué ha terminado la sesión.

Si todo falla, envía toda la información que puedas, incluyendo los archivos de configuración, como arrancas el ppp, las partes relevantes del archivo de log y la salida del comando netstat -rn (antes y despues de la conexión) a la lista de distribución FreeBSD-questions@FreeBSD.org, a la lista de FreeBSD en castellano o al grupo de news comp.unix.bsd.FreeBSD.misc y alguien te ayudará a solucionar los problemas.

Cuando el kernel de FreeBSD arranca, testeará los puertos serie del sistema que estén configurados en el kernel. Puedes estar atento a los mensajes de la consola o ejecutar el comando:

una vez el sistema esté en funcionamiento.

Aquí tienes un ejemplo del resultado de la ejecución del comando:

Esto muestra dos puertos serie. El primero en la irq 4 usando la dirección 0x3f8, y tiene una UART 16550A. El segundo usa el mismo tipo de chip pero está en la irq 3 y usa la dirección 0x2f8. Los módems internos son tratados como puertos serie, exceptuando que siempre tienen un módem adjuntado al puerto.

El kernel GENERIC incluye soporte para dos puertos serie usando la misma irq y dirección que en el ejemplo anterior. Si estas opciones no son correctar para tu sistema, o si has añadido módems internos o tienes más puertos serie de los que están configurados en el kernel, solo tienes que reconfigurar el kernel. Mira en la sección about building a kernel para más detalles.

Respondido en la sección anterior.

No te preocupes, han sido integrados en los dispositivos ttydX. Tendrás que modificar algunos archivos antiguos de configuración.

El tercer puerto serie, sio2 (conocido como COM3 en DOS), está en /dev/cuaa2 para dispositivos de salida (dial-out) y en /dev/ttyd2 para dispositivos de entrada (dial-in). Cuál es la diferencia entre estas dos clases de dispositivos?.

Usas los ttydX para los entrantes. Al abrir /dev/ttydX en "blocking mode", un proceso esperará para que el dispositivo cuaaX correspondiente se vuelva inactivo. Cuando abres un dispositivo cuaaX, se asegura de que el puerto serie no está en uso por un dispositivo ttydX. Si el puerto está disponible, se lo "roba" al dispositivo ttydX. Al mismo tiempo, el dispositivo cuaaXX no se preocupa de la detección de portadora. Con este esquema, y un módem en respuesta automática, puedes recibir usuarios remotos y puedes hacer conexiones externas con el mismo módem, mientras el sistema se preocupa de evitar los posible conflictos.

Otra vez, en la sección de configuración del kernel tienes la información. Para una tarjeta multipuerto, pon una línea sio para cada puerto serie de la tarjeta en el archivo de configuración del kernel. Especifica la irq y vector solo en una de las líneas. Todos los puertos de la tarjeta compartirán la misma irq. Por consistencia, usa el último puerto serie para especificar la irq. De la misma manera, especifica la opción COM_MULTIPORT.

El siguiente ejemplo es para una tarjeta AST 4-port en la irq 7:

Los flags indican que el puerto master tiene un número menor de 7 (0x700), los diagnósticos están activados durante el testeo (0x080), y los puertos comparten una irq (0x001).

Todavía no. Tendrás que usar una irq diferente para cada tarjeta.

El dispositivo ttydX (o cuaaX) es el que querrás abrir para tus aplicaciones. Cuando un proceso abre el dispositivo, tendrá una serie de configuraciones I/O por defecto. Puedes ver estas configuraciones con el comando:

Cuando le cambias la configuración a este dispositivo, este cambio se mantiene hasta que el dispositivo se cierra. Cuando se reabre, vuelve a la configuración por defecto. Para hacer cambios sobre la configuración por defecto, puedes abrir y ajustar las opciones del "estado inicial" del dispositivo. Por ejemplo, para poner el dispositivo tty5 en modo CLOCAL, 8 bits, y contro del flujo XON/XOFF, haz

Un buen lugar para hacer esto es en /etc/rc.serial. Ahora, una aplicación tendrá esta configuración por defecto cuando abra el puerto ttyd5.

También puedes prevenir o limitar ciertos cambios que pretenda hacer una aplicación. Para ello, ajusta el "lock state" del dispostivo. Por ejemplo, para bloquear la velocidad del puerto ttyd5 a 57600 bps, haz:

Ahora, una aplicación que abre ttyd5 e intenta cambiar la velocidad del puerto no podrá hacerlo.

Naturalmente, deberías hacer que el estado inicial y el estado de bloqueo sean solo de escritura para el usuario root. El script MAKEDEV NO hace esto cuando crea el dispositivo.

Quieres hacerte proveedor de Internet, eh?. Primero, necesitarás uno o más módems que puedan responder automáticamente. Tu módem necesitará activar el carrier-detect sólo cuando detecte una portadora y no tenerla activada continuamente. Necesitará cortar la comunicación y resetearse él mismo cuando la línea DTR pase de on a off. Probablemente usaría RTS/CTS para el control de flujo. Finalmente, debe usar una velocidad constante entre el computador y él mismo, pero debería negociar la velocidad entre él mismo y el módem remoto.

Para muchos módems compatibles Hayes, este comando creará estas configuraciones y las grabará en la memoria no volátil:

Mira la sección enviar comandos AT para saber como enviar estas configuraciones al módem sin necesidad de un programa terminal de DOS.

A continuación, añade una línea en el archivo /etc/ttys para el módem. Este archivo lista todos los puertos en los que el sistema operativo esperará los logins. La línea sería como esta:

Esta línea indica que el segundo puerto serie /dev/ttyd1 tiene un módem conectado, la velocidad es de 57600 bps y sin paridad (std.57600. El tipo de terminal para este puerto es "dialup". El puerto está "on" y es inseguro (lo que significa que los logins como root no son permitidos).

Muchos usuarios, ponen un sus archivos .profile o .login un prompt para el tipo de terminal. El ejemplo muestra el puerto como inseguro. Para ser root en ese puerto, hacer el login como un usuario normal, y ejecutar el comando su. Si en lugar de inseguro, el terminal es seguro (secure), puedes hacer login como root directamente.

Despues de modificar el archivo /etc/ttys, necesitas lanzar una señal HUP al proceso init:

Esto fuerza al proceso init a releer el archivo /etc/ttys. El proceso init arrancará los procesos getty en todos los puertos configurados como "on". Puedes ver si los logins están disponibles en los puertos tecleando:

deberías ver algo como:

Si estás usando otro computador como terminal en tu sistema FreeBSD, usa un cable null módem entre los dos puertos serie. Si ya estás usando un terminal, mira en las instrucciones del mismo.

A continuación, modifica el archivo /etc/ttys Por ejemplo, si estás instalando un terminal WYSE-50 en el quinto puerto serie, usa una línea como esta:

Este ejemplo muestra que el puerto /dev/ttyd4 tiene un terminal Wyse50 conectado a 38400 bps sin paridad y los logins de root son permitidos.

En tu sistema, los programas tip y cu son probablemente ejecutables solo por uucp y el grupo dialer. Puedes usar el grupo dialer para controlar quien tiene acceso al módem o sistemas remotos. Sólo tienes que añadirte tu mismo al grupo dialer.

Alternativamente, puedes dejar que todos los usuarios de tu sistema ejecuten tip y cu tecleando:

Actualmente, el man de tip está anticuado. Hay un dialer Hayes genérico. Solo usa ``at=hayes'' en tu archivo /etc/remote.

El driver Hayes no es tan desarrollado como para reconocer algunas de las características avanzadas de los módems modernos, mensajes como BUSY, NO DIALTONE o CONNECT 115200 lo pueden confundir. Deberías anular estos mensajes cuando uses tip (utilizando la cadena ATX0&W).

También, el timeout de llamada para tip está en 60 segundos. Tu módem debería usar algo menor, o tip puede pensar que hay un problema de comunicación. Intenta con ATS7=45&W.

Haz lo que se llama una entrada directa en el archivo /etc/remote. Por ejemplo, si tu módem está conectado al primer puerto serie, /dev/cuaa0, escribe la siguiente línea:

Usa la velocidad más alta que soporte tu módem en la sección br. A continuación teclea tip cuaa0 y estarás conectado al módem.

Si no existe el dispositivo /dev/cuaa0 en tu sistema , teclea lo siguiente:

O usa el comando cu como root con los siguientes parámetros:

con line siendo el puerto serie (por ejemplo /dev/cuaa0>) y speed siendo la velocidad (por ejemplo 57600. Cuando termines de entrar los comandos AT, pulsa la tecla . para salir.

El símbolo @ en la opción de números de teléfono indica a tip que busque en el archivo phone(5) un número de teléfono determinado. Pero el símbolo <@> es también un carácter especial en otros archivos y opciones como /etc/remote. Pon una contrabarra junto al carácter:

Pon lo que se llama una entrada genérica en el archivo /etc/remote. Por ejemplo:

Entonces puedes hacer cosas como tip -115200 5551234. Si prefieres usar cu antes que tip, usa una entrada genérica de cu:

y teclea ``cu 5551234 -s 115200''.

Pon una entrada para tip1200 o cu1200, pero puedes usar la velocidad que mejor se amolde a tus necesidades. tip piensa que una buena velocidad por defecto es 1200 bps ya que busca una entrada tip1200. No tienes por que usar 1200 bps.

En lugar de esperar a que estés conectado y teclear CONNECT <host> cada vez, usa la opción cm de tip. Por ejemplo, estas entradas en el archivo /etc/remote:

Esto hará que puedas teclear tip pain o tip muffin para conectarte a las máquinas pain o muffin.

Este es un problema habitual en universidades con diferentes líneas de módem y unos cientos de usuarios intentado usarlas...

Haz una entrada para tu universidad en el archivo /etc/remote y usa \@ para la opción pn:

Entonces, lista los números de teléfono de la universidad en el archivo /etc/phones:

tip intentará cada uno de estos números en el orden en el que estén listados. Si quieres que se realicen reintentos, ejecuta tip en una bucle while.

CTRL+P es el carácter por defecto de "forzar", usado para indicarle al programa tip que el próximo carácter es un dato literal. Puedes configurar el carácter "forzar" a cualquier otro carácter con el escape ~s, el cual significa "poner una variable".

Teclea ~sforce=<single-char> seguido de una nueva línea. <single-char> es cualquier carácter simple. Si dejas libre <single-char> entonces el carácter de forzar es el caracter nul, al cual puedes acceder tecleando CTRL+2 o CTRL+SPACE. Un valor más adecuado para <single-char> es SHIFT+CTRL+6, el cual solo es usado en algunos servidores de terminales.

Puedes tener el carácter de forzar donde quieras, especificando lo siguiente en tu archivo $HOME/.tiprc

Has debido pulsar CTRL+A, tip tiene este carácter especial para gente que tenga la tecla caps-lock estropeada. Usa ~s como en la sección anterior y pon la variable "raisechar" a un valor razonable. De hecho, puedes ponerla al mismo valor que que el carácter de forzar, si no esperas usar estas características.

Aqui hay un ejemplo del archivo .tiprc perfecto para usuarios de Emacs que necesiten teclear CTRL+2 y CTRL+A muchas veces:

El simbolo ^^ es SHIFT+CTRL+6.

Si estás conectado con otro sistema UNIX, puedes enviar y recibir archivos con ~p (put) y ~t (take). Estos comandos ejecutan cat y echo en el sistema remoto para aceptar y enviar archivos. La sintaxis es:

No hay chequeo de errores, por lo que es mejor usar otro protocolo como zmodem.

Primero, instala uno de los programas zmodem de la colección de ports (por ejemplo lrzsz y rzsz).

Para recibir archivos, inicia el programa de envío en la parte remota. A continuación, pulsa enter y teclea ~C rz'' (or ``~C lrz'' si instalaste lrzsz) para empezar a recibir localmente.

Para enviar archivos, inicia el programa de recepción en la parte remota. A continuación pulsa enter y teclea ~C sz <files>'' (o ~C lsz <files>) para enviarlos al sistema remoto.

Las placas bases y tarjetas con UARTs de Acer no son detectadas correctamente por FreeBSD durante la fase de detección serie. Obten un parche de www.lemis.com para solucionar el problema.

No lo hace. Deberías pensar "Porque mi swap parece lleno?". Si esto es lo que realmente querías decir, es por que poniendo los datos en swap en luar de descartarlos, hace que sea más rápido recuperarlos que si el paginador tuviese que ir a través del sistema de archivos y usar bloques sin modificar desde un ejecutable.

La cantidad actual de páginas que puedes tener en el core en una sola vez no es reducida; las páginas sin usar son desplazadas como sea necesario.

Para entender por que FreeBSD usa el formato a.out, debes saber primero un poco sobre los tres formatos dominantes actualmente en UNIX:

FreeBSD viene del sistema clásico y tradicionalmente ha utilizado el formato a.out, una tecnología probada y testeada a través de muchas generaciones de releases de BSD. También es posible construir y ejecutar binarios nativos ELF (y kernels) en sistemas FreeBSD. FreeBSD inicialmente se resistió al salto de cambiar a ELF como su formato por defecto. Porqué?, bien, cuando el mundo Linux hizo su transición a ELF no era nada fácil abandonar el formato ejecutable a.out debido a su inflexible mecanismo de tablas basadas en librerías compartidas. Esto hizo muy difícil para los fabricantes y desarrolladores la creación de librerías compartidas. A partir del momento en el que se ofrecieron una serie de herramientas que ofrecían la solución al problema de las librerías compartidas, el coste de la migración fue aceptado como necesario y la transición se hizo.

En el caso de FreeBSD, el mecanismo de librerías compartidas esta más basado en el estilo de SunOS, mucho más sencillo de usar. De todas maneras, empezando con la version 3.0, FreeBSD soportará oficialmente binarios ELF como el formato por defecto. Aunque pensamos que el formato ejecutable a.out nos ha servidor muy bién, la gente de GNU, que hacen las herramientas de compilación que usamos, ha dejado de dar soporte para el formato a.out. Esto nos ha forzado a mantener dos versiones divergentes del compilador y lincador.

Tienes que usar -H o -L junto con la opción -R para que funcione. Para más información, mira la página de chmod y de symlink.

CUIDADO la opción -R hace un chmod RECURSIVO. Ten cuidado aal especificar directorios o symlinks con chmod. Si quieres cambiar los permisos de un directorio referenciado por un symlink, usa chmod sin ninguna opción y sigue el symlink con una barra /. Por ejemplo, si foo es un symlink al directorio bar, y quieres cambiar los permisos de foo /actualmente bar), deberías hacer algo como esto:

Con la barra, chmod seguira el symlink, foo, para cambiar los permisos del directorio bar.

Pensarás que es fácil y suficiente con cambiar UT_NAMESIZE y reconstruir el kernel, y todo volverá a funcionar. Desafortunadamente hay aplicaciones y programas (incluyendo herramientas de sistema) que tienen en el propio código (no siempre 8 o 9, pero si 15 o 20) en estructuras, buffers... y rompería los clientes de NIS de Sun y sin duda existirían otros problemas interactuando con otros sistemas UNIX.

En FreeBSD 3.0 y superiores, se ha incrementado el número máxmimo de carácteres a 16 y todas esas utilidades con longitud de carácteres prefijada han sido encontradas y arregladas. El hecho de que este cambio afectase a muchas áreas del sistema es el motivo por el que el cambio no se ha hecho hasta la versión 3.0.

Si eres absolutamente cuidadoso y quieres arreglas tu mismo este problema en versiones anteriores, edita el archivo /usr/include/utmp.h y cambia el parámetro UT_NAMESIZE a la longitud que desees. También debes editar el archivo /usr/include/sys/param.h y poner el valor de MAXLOGNAME al mismo que UT_NAMESIZE. Finalmente, recompila los fuentes, no te olvides que el contenido de /usr/include es actualizado cada vez!. En su lugar, cambia los archivos apropiados en /usr/src/..

Sí, empezando en la versión 3.0 puedes usar la emulación DOS rundos de BSDI, la cual ha sido integrada y mejorada. Envía un mail a la Lista de discusión de emulación en FreeBSD si estás interesado en participar en la evolución de esta característica.

Para sistemas pre-3.0 hay una pequeña utilidad llamada pcemu en la colección de puertos que emula un 8088 y suficientes servicios de BIOS para ejecutar aplicaciones de modo texto. Requiere el sistema de X Window.

SUP significa Software Update Protocol, y fue desarrollado por CMU para mantener sus árboles de desarrollo sincronizados. Nosotros lo usabamos para manterner el servidor central sincronizado con otros servidores remotos.

SUP no es amigo del ancho de banda, y ha sido retirado. El método actual recomendado para mantener tus fuentes actualizados es CVSup

FreeBSD usa la instrucción HLT (halt) cuando el sistema está (idle) para reducir el consumo de energía. Si tienes la opción APM (Automatic Power Management) configurado, FreeBSD puede poner la cpu en modo de baja energía.

MFC es un acrónimo para "Merges From -CURRENT". Es usado en los logs de CVS para indicar que un cambio se ha migrado de la rama CURRENT a la rama STABLE.

Pertenece a un lenguaje secreto que solo sus miembros conoces. No tiene traducción literal, pero basta con decir que su traducción está entre, "Equipo de Fórmula-1", "Los Pinguinos son un buén aperitivo", y "Tenermos mejor sentido del humor que Linux" :-)

Seriamente, BSD es un acrónimo de "Berkeley Software Distribution", el cual es el nombre que el CSRG de Berkeley (Computer Systems Research Group) escogió para sus distribuciones de Unix.

Hay actualmente tres ramas activas/semi-activas en el desarrollo de FreeBSD y en su CVS Repository:

HEAD no es una rama actual, como las otras dos, es simplemente una constante simbólica para la versión de desarrollo actual a la cual nos referimos simplemente como -current.

Actualmente, -current es el desarrollo de la versión 4.0 y la rama 3.0-stable es RELENG_3, separada de -current en Enero de 1999.

Para hacer una release necesitas hacer tres cosas: primero, necesitas usar un kernel con el driver vn configurado. Añade esto a tu archivo de configuración del kernel y crea un nuevo kernel:

Segundo, debes tener las herramientas del CVS a mano. Para hacer esto, puedes usar CVSUP pero en tu supfile pon el nombre de la release a cvs y borra cualquier tag campo de fecha:

A continuación ejecuta cvsup -g supfile para tener todos los bits correctos en tu computador.

Finalmente, necesitas una buena cantidad de espacio vacío para crear en el la release. Digamos que está en /algun/disco/grande y en el ejemplo anterior has dejado los archivos del CVS en /home/ncvs:

Una release completa será creada en /algun/disco/grande/ y tendrás una instalación completa de tipo FTP en /algun/disco/grande/R/ftp cuando acabes. Si quieres crear tu SNAP usando otra rama de desarrollo diferente de -current, puedes añadir RELEASETAG=SOMETAG a la línea de comando anterior de creación de la release. Por ejemplo, RELEASETAG=RELENG_2_2 crearía un snapshot 2.2 GAMMA.

El proceso completo de creacación de discos de instalación y archivos fuentes y binarios esta automatizado por varios targets en /usr/src/release/Makefile. La información alli contenida debería ser suficiente para que puedas empezar. Falta decir que este proceso necesita la ejecución del comando "make world" y quizás te use mucho tiempo y espacio en disco.

Sí, esta es la idea general; como su nombre sugiere, "make world" rehace todos los binarios del sistema, de manera que puedas estar seguro de tener un entorno limpio y consistente al final (que es por lo que tarda tanto).

Si la variable de entorno DESTDIR está definida mientras se ejecuta make world o make install, los binarios creados nuevamente seran depositados en un árbol de directorios idéntico al instalado, y a partir de ${DESTDIR}. Algunas combinaciones aleatorias de modificaciones de librerías compartidas y programas pueden causar que falle el make world.

Las controladoras SCSI Adaptec 1542 permiten al usuario configurar su velocidad de acceso al bus en software. Versiones anteriores del driver de la 1542 intentaban determinar la velocidad más alta factible y configurar la Adaptec a esta. Nos hemos encontrado con que esto hace fallar el sistema de algunos usuarios, por lo que tienes que definir la opción de configuración del kernel TUNE_1542 para que esto ocurra. En algunos sistemas puede que puede hacer que los discos vayan más rápidos, pero en otros puede que los datos queden corrompidos.

Sí, puedes hacerlo sin bajarte todo el código fuente usando la utilidad CTM.

Los sistemas BSD más modernos tienen una opción -b para partir que les permite partir los archivos en tamaños arbitrarios.

Aqui hay un ejemplo de /usr/src/Makefile.

Por favor, mira en como enviar código.

Y gracias por pensar en nosotros!

Brevemente, hay unos cuantos puertos de entrada/salida a los que todas las tarjetas PnP responden cuando el computador pregunta si hay alguien ahí. Así, cuando comienza la rutina de prueba de PnP, pregunta si hay alguna tarjeta PnP presente y todas las tarjetas responden con su número de modelo a una lectura I/O del mismo puerto. Así el código de prueba puede conocer el ID de cada tarjeta (asignado por Microsoft/Intel).

Los ID's son dos campos de 32 bits (2^64) + 8 bits de checksum. Los primeros 32 bits son el identificador del fabricante. No se ha dicho publicamente, pero parece estar asumido que diferentes tipos de tarjeta del mismo fabricante pueden tener diferentes id's de fabricante. La idea de necesitar 32 bits sólo para los fabricantes parece un poco excesiva.

La parte baja de 32 bits son un número de serie, dirección ethernet, algo que haga a la tarjeta única. El fabricante no debe producir nunca una segunda tarjeta que tenga los mismos 32 bits de la parte baja, aunque los 32 bits de la parte alta sean diferentes. Así puedes tener múltiples tarjetas del mismo tipo en la misma máquina y los 64 bits serán únicos para cada tarjeta.

Los grupos de 32 bits nunca pueden ser todos cero. Esto permite mostrar todos los bits no-cero durante la búsqueda binaria inicial.

Una vez el sistema ha identificado todos los ID's de las tarjetas presentes, reactivaráa cada tarjeta, una tras otra (a través de los mismos puertos I/O), y encontrará los recursos que cada tarjeta necesita, que opciones de interrupción están disponibles, etc. Se realiza un escaneo sobre todas y cada una de las tarjetas presentes para conocer esta información.

Esta información se combina con la información de los archivos ECU del disco y con las BIOS MLB. El soporte PnP de ECU y las BIOS para hardware en el MLB usualmente es sintético, y los periféricos no hacen PnP genuino. De todas maneras, examinando la información del BIOS más la información ECU, la rutina de prueba puede causar que los dispositivos que no son PnP puedan evitar a esos dispositivos que el código de prueba no puede volver a posicionar.

Así, los dispositivos PnP son visitados una vez más y se les asigna su I/O, DMA, IRQ, direcciones del mapa de memoria. Los dispositivos aparecerán en esas direcciones y permanecerán en ellas hasta que se vuelva a reinicializar la máquina.

Todo el proceso se ha simplificado mucho, pero espero que hayas podido hacerte una idea del proceso.

Diferentes grupos de personas han expresado su interés en trabajar en un port multi-arquitectura de FreeBSD y FreeBSD/AXP (ALPHA) es un ejemplo de ese esfuerzo realizado, ahora disponible en forma de 3.0 SNAPshot release en ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha. El port de ALPHA funciona actualmente en diferentes tipos de máquinas ALPHA, entre ellas, AlphaStation, AXPpci, PC164, Miata y Multia. Este port todavía no se considera una release completa y no lo será hasta que exista una colección completa de herramientas de instalación y una distribución completa en cdrom para instalació, incluyendo un número razonable de ports y packages funcionales. FreeBSD/AXP debe considerarse software de calidad BETA en estos momentos. Para más información del proyecto, subscríbete a la <FreeBSD-alpha@FreeBSD.org> lista de correo.

También se ha expresado interés en un port de FreeBSD para arquitectura SPARC. Subscríbete a <FreeBSD-sparc@FreeBSD.org> la lista si estás interesado en participar en el proyecto. Para discusiones generales en nuevas arquitecturas, participa en la lista <FreeBSD-platforms@FreeBSD.org>.

Esto depende de si quieres hacer que el driver esté públicamente disponible. Si la respuesta es afirmativa, por favor, envianos una copia del código fuente del driver y las modificaciones apropiadas del archivo files.i386, un ejemplo de configuración y el código apropiado de MAKEDEV para crear cualquier archivo especial que use tu dispositivo. Puedes enviar todo lo necesario a <FreeBSD-hackers@FreeBSD.org>.

En respuesta a esta pregunta de políticas alternativas para los directorios, el esquema que está actualmente en uso no ha cambiado desde que lo escribí en 1983. Escribí esa política para el sistema de archivos rápido original, y nunca se ha revisado. Trabaja bién manteniendo los grupos de cilindros. Como muchos de vosotros habreis notado, el rendimiento es muy pobre con "find". Muchos sistemas de archivos son creados desde archivos que fueron creados por una primera búsqueda en profundidad (también conocido como ftw). Estos directorios terminan esparcidos a través de los grupos de cilindros. Si conociesemos el número total de directorios a crear, la solución sería crear (total / fs_ncg) por grupo de cilindros antes de moverlos. Obviamente, tendriamos que crear algún tipo de heurística para adivinar este número. Usando un número pequeño fijo (como puede ser 10) haría de orden de magnitud. Para diferencial restores de operaciones normales (cuando el algoritmo actual es probablemente más sensible), podrís usar el clustering hasta 10 si fueran todos hechos dentro de una ventana de diez segundos. De cualquier manera, mi conclusión es que este es un área para la experimentación.

Kirk McKusick, Septiembre 1998

[Esta sección fue extraida de un mensaje escrito por Bill Paul en la lista FreeBSD-current por Dag-Erling Coïdan Smørgrav, quién a fijado algunos errores y añadido algunos comentarios entre corchetes]

[<ben@rosengart.com> envió el siguiente panic]

[Cuando] ves un mensaje como este, no es suficiente con solo reproducirlo y enviarlo. El valor del puntero de instrucciones que he marcado arriba es importante; desafortunadamente, depende de la configuración. En otras palabras, el valor varía dependiendo de la imáden de kernel exacta que se use. Si estás usando el kernel GENERIC de uno de los snapshots, entonces es posible que alguien pueda seguir la función problemática, pero si estás usando un kernel personalizado, entonces solo tú puedes decirnos donde ha ocurrido el fallo.

Tendrías que hacer lo siguiente:

Veo gente que constantemente envía mensajes de panics como este, pero raramente veo que alguien se tome el tiempo de buscar la coincidencia entre el puntero de instrucción y una función en la tabla de símbolos del kernel.

La mejor manera de hacer el seguimiento de la causa de un panic es capturar un "crash dump", usando gdb(1) para hacer una traza del "crash dump". Por supuesto, esto depende de que gdb(1) funcione correctamente en -current, lo que no puedo garantizar (recuerdo que alguien ha comentado que el nuevo gdb(1) en formato ELF no manejaba bién los "dumps" de un crash del kernel; alguién debería mirar esto antes de que la 3.0 salga del estado beta).

En cualquier caso, el método que normalmente uso es este:

[Nota: ahora que los kernels de FreeBSD 3.x son ELF por defecto debes usar strip -g en lugar de strip -d. Si por algún motivo tu kernel es aún a.out, usa strip -aout -d.]

Ten en cuenta que TU NO QUIERES ARRANCAR CON UN KERNEL QUE TIENE TODOS LOS SIMBOLOS DE DEBUG EN EL. Un kernel compilado con -g puede llegar facilmente a los 10MB de tamaño. No tienes que arrancar esta imán masiva, solo lo necesitas para poder usar después gdb(1) (gdb(1) quiere la tabla de símbolos). Al contrario, quieres mantener una copia de la imágen completa y crear una segunda imágen con los símbolos de debug desactivados usando strip -d. Es esta segunda imágen la que quieres arrancar.

Para asegurarte de capturar un "crash dump", necesitas editar el archivo /etc/rc.conf y apuntar dumpdev a tu partición de swap. Esto hará que el script rc(8) use el comando dumpon(8) para activar los "crash dumps". También puedes ejecutar manualmente dumpon(8). Después de un panic, el "crash dump" puede ser recuperado usando savecore(8); si dumpdev está en /etc/rc.conf, el script rc(8) ejecutará savecore(8) automaticamente y pondrá el "crash dump" en /var/crash.

NOTA: los "crash dumps" de FreeBSD suelen tener el mismo tamaño que la cantidad total de memoria física del sistema. Esto significa que si tienes 64MB de RAM, obtendrás un "crash dump" de 64MB. Debido a esto, tienes que asegurarte de tener suficiente espacio libre en /var/crash. Alternativamente puedes ejecutar savecore(8) manualmente y hacer la recuparación en otro directorio donde tengas más espacio libre. Es posible limitar el tamaño del "crash dump" usando options MAXMEM=(foo) para indicar la cantidad de memoria que el kernel puede ocupar. Por ejemplo, si tienes 128MB de RAM, puedes limitar el uso de memoria del kernel a 16MB para que el "crash dump" sea de 16MB y no de 128MB.

Una vez hayas recuperado el "crash dump", puedes obtener una traza del stack con gdb(1) de la manera siguiente:

Es posible que aparezcan muchas líneas de información: es una buena idea usar el comando script(1) para capturarlas todas. Usando la imágen del kernel con todos los símbolos de debug deberí mostrar la línea exacta de código fuente del kernel donde ha ocurrido el panic. Normalmente, tienes que leer la traza del stack de abajo hacia arriba para poder conocer la secuencia exacta de eventos que han provocado el crash. También puedes usar gdb(1) para mostrar los contenidos de las diferentes variables o estructuras para examinar el estado del sistema en el momento del crash.

Ahora, si eres realmente curioso y tienes un segundo computador, puedes configurar gdb(1) para hacer un debug remoto de manera que puedes usar gdb(1) en un sistema para revisar el kernel de otro sistema, de la misma manera que lo harías en la máquina local.

[Bill añade: "Olvidé mencionar una cosa: si tienes DDB activado, puedes forzar un panic (y un crash dump) tecleando "panic" en el prompt del ddb. Es posible que el debugger se pare durante la fase del panic. Si esto ocurre, teclea "continue" y el crash dump finalizará"]

Las herramientas ELF no hacen por defecto que los símbolos definidos en un ejecutable sean visibles por el linker dinámico. Consecuentemente, dlsym() buscará en datos obtenidos desde llamadas a dlopen(NULL, flags), lo que provoca que no se encuentren esos símbolos.

Si quieres buscar, usando dlsym() símbolos presentes en el ejecutable principal de un proceso, necesitas linkar el ejecutable usando la opción -export-dynamic en el linkador ELF.

Por defecto, el espacio de direcciones del kernel es de 256MB en FreeBSD 3.x y 1GB en FreeBSD 4.x. Si gestionas un servidor de red muy cargado (por ejemplo, servidores FTP o HTTP con mucho tráfico), es posible que notes que 256MB no es suficiente.

Así que... como incremento el espacio de direcciones?. Hay dos aspectos a tener en cuenta. Primero, necesitas indicarle al kernel que reserve una mayor parte del espacio de direcciones para él mismo. Segundo, ya que el kernel se carga al inicio del espacio de direcciones, necesitas disminuir la dirección de carga.

El primer aspecto lo solucionamos incrementando el valor de NKPDE en src/sys/i386/include/pmap.h. Esta es una entrada de ejemplo para 1GB de espacio de direcciones:

Para encontrar el valor correcto de NKPDE, divide el espacio de direcciones deseado (en megabytes) por cuatro, después resta uno por UP y dos por SMP.

Para solucionar el segundo aspecto, necesitas calcular la dirección correcta de carga: simplemente resta el tamaño del espacio de direcciones (en bytes) de 0x100100000; el resultado es 0xc0100000 para 1GB de espacio de direcciones. Ajusta LOAD_ADDRESS en src/sys/i386/conf/Makefile.i386 a ese valor; a continuación pon el contador al inicio de la sección listado en src/sys/i386/conf/kernel.script al mismo valor, como sigue:

Reconfigura y compila el kernel. Probablemente tengas problemas con top(1), ps(1) y programas así haciendo un make world deberín solucionarse esos problemas (o una recompilación manual de libkvm, ps y top después de copiar el pmap.h parcheado a /usr/include/vm/.

NOTA: el tamaño del espacio de direcciones debe ser un múltiplo de cuatro megabytes.

[David Greenman añade: Pienso que el espacio de direcciones del kernel necesita ser una potencia de 2, pero no estoy totalmente seguro.]