<!-- 1,1 -->
<!-- Infobia,0 -->
<!-- Francisco J.,Montilla,pacopepe@insflug.org -->
<!-- 0.98,1998-06-26 -->
<!-- ppp,infovía,internet,conexión a internet -->
<!-- Software,Conexion a Internet -->

<!-- ****************************************************************** -->
<!-- * Revisión y re-reformateo sgml v0.98     Francisco. J. Montilla * -->
<!-- *      26/06/98                               pacopepe@insflug.org * -->
<!-- ****************************************************************** -->

<!doctype linuxdoc system>

<article>

<title>``Infobia''- Como. 
<author>Francisco José Montilla, <tt><htmlurl url="mailto:pacopepe@insflug.org" 
name="pacopepe@insflug.org"></tt>
<date>v0.98, 26 de Junio de 1998.

<abstract>
Este documento pretende ser una guía rápida de configuración y puesta en
funcionamiento de procedimientos para conectarse a Internet a través de
Infovía mediante enlaces ppp. También puede aplicarse a casos de acceso
"directo" sin mediar Infovía, o a través de retenet. Así mismo, describiré
un método tal vez no muy ortodoxo pero sí sencillo y eficiente para
recoger y mandar el correo a través de este tipo de conexiones.
</abstract>

<toc>

<sect>Introducción

<p>
En este documento intentaré explicar un par de métodos para establecer
conexiones <tt/ppp/ a servidores de acceso a Internet, así como un sistema
para recoger y enviar el correo a la cuenta del Servidor con el que se
establece la conexión. 

No soy ni pretendo ser un <em/gurú/ en LiNUX. Lo que aquí se describe lo
he extraído de correo que generosamente me enviaron en su momento usuarios
de <tt/Fidonet/ e Internet, y he probado, experimentado, y buscado la
forma más sencilla y fácil de hacerlo, ya que me consta que una de las
cosas que más ilusión hace a los recién llegados es precisamente
conectarse a Internet a través de LiNUX --- cosa que por cierto, se
realiza mucho más eficientemente en este sistema operativo que en otros,
al obtenerse soporte directo del núcleo o <em/kernel/ del sistema, sin
tener que recurrir a ``chapuzas'' para ello.---

La motivación por tanto, que me ha llevado a hacer este documento ha sido
el ponerlo a disposición de los demás (y por que ya estaba cansado de
<em/forwardear/ una y otra vez los mismos mensajes que previamente había
recibido ;-) y como agradecimiento y <em/granito de arena/ a toda la
comunidad LiNUX. 

Si encuentra cualquier error de concepto, u opina que el método se puede
mejorar, o simplemente quiere hacer alguna aportación a este documento, no
dude en ponerse en contacto conmigo. Estaré encantado de saberlo. 

<sect>Requisitos.
<p>

<sect1><it>Hardware</it>
<p>

<sect2>Módems
<p>

Está claro: <tt/:)/ además del ordenador, un módem. En cuanto al tipo de
módem, siempre he recomendado lo mismo: Externo. Un módem interno sólo
tiene razón de ser en la poco probable situación de no poseer UARTs
rápidas (16550A). Si este no es su caso, la mejor apuesta será siempre
(hablando de módems por RTC<footnote>Red Telefónica Conmutada, en
oposición a la reciente RDSI</footnote>) un módem externo, de cuanta mejor
reputación mejor; no me gusta entrar en marcas y modelos, pero sé que esta
es un pregunta frecuente en aquellos que se disponen a actualizar o
adquirir uno, por lo que haré una excepción. 

	Las marcas aconsejables son las de siempre: <it/USR/, en sus
modelos <it/Sportster/ o <it/Courier/, siempre que no sean <it/winmodems/
, <it/Supra/ (actualmente <it/Diamond/) en su modelo <it/Fax/, <it/Zyxel/,
etc.  Siempre y cuando no sean <it/winmodems/. Recientemente ha pasado uno
por mis manos de fabricación nacional, cuyo nombre era <it/Vayris/ (o algo
así), que no estaba nada mal. En cuanto a velocidades, comprar menos de
33.6 Kbps hoy en día es un desperdicio. 

	Una cosa sí que está muy clara en todo caso: rehuir como de la
peste de los denominados <it/winmodems/; éstos no poseen chip inteligente,
y realizan sus funciones lógicas a través de software, que normalmente no
está disponible (siendo poco probable que alguna vez lo esté, dada la
escasa calidad de dicho "hardware") en LiNUX y otros SOs.

	Modelos y Marcas conocidos de éstos son:

<itemize>
<item><it/USR Sportster Winmodem/
<item><it/IBM Aptiva MWAVE/
<item><it/Sitre Super PC336/
<item><it/Zoltrix VoiceMail 33600 Win HSP/
<item>Módems con chip <it/Rockwell RPI/
<item>También he recibido últimamente frecuentes preguntas de propietarios
de módems de chip <it/PCTEL HSP/, que desafortunadamente, no podrán
beneficiarse de las capacidades de conexión de Linux, debido a que
pertenece a la funesta categoría de <it/winmodems/. 
</itemize>

	Resumiendo: <bf/NADA de winmodems/, a ser posible NO internos, y nada 
de PnP.

<sect2>Configuración del módem
<p>

	Un problema frecuente es el hecho de que ``<it/el módem no
marca/''. En el 90&percnt; de los casos, y asumiendo que no son
<it/winmodems/, se debe a estar intentando que LiNUX comparta IRQ, bien
por estar usando un módem interno, en la típica configuración DOS COM4,
irq 3, bien por tener la IRQ asignada a ese puerto ocupada con otro
dispositivo.

	Linux NO puede compartir IRQs, y esto no es un fallo, es una necesidad.
Así pues, la estrategia es:

<enum>
<item>Configurar el módem para que su puerto interno pase a ser el COM2
(<tt>/dev/ttyS1</tt> en Linux); la configuración en Linux por defecto para
este puerto es irq 3, dirección base 0x02f8. Así pues, si el módem admite
ser configurado <bf/por jumpers/ de tal modo, nos habremos ahorrado
trabajo. No olvidar desactivar el COM2 de la Placa madre. 

<item>Si lo anterior no puede hacerse, pero el módem admite (<bf/por
jumpers, nada de PnP!/) al menos cambiar la IRQ que usará el puerto
interno del módem, asignarle una IRQ distinta de la 3 o 4. Si se tiene
tarjeta de sonido, posiblemente ésta ocupe la IRQ 5, y la 7 es del LPT1
aunque no se emplee si utilizamos el driver de <it/polling/ del núcleo. La
9 está en cascada con la 2, así que una apuesta segura son las IRQs de la
10 a la 12. 

<item>Si esto tampoco puede hacerse, la estrategia a seguir es desactivar
el COM2 en la placa base, mediante los jumpers o como suele ser posible
con las placas Pentium, mediante la BIOS, a fin de dejar la IRQ 3 libre,
que será usada por defecto por el puerto interno del módem (COM4); o bien
cambiar la IRQ utilizada por el COM2 de la placa, a fin de que pueda ser
usada por el puerto interno del módem.

<item>Una vez nos hemos asegurado de que el <it/hardware/ está empleando
los recursos que debe, hemos de decírselo al <it/software/. Si hemos
conseguido poner el puerto interno del módem como COM2 (¡y hemos
desactivado el de la placa!), no hay más que hacer, todo lo que sigue está
pensado para ese caso. Una respuesta típica del comando <tt/setserial/
sería: 

<tscreen><verb>
 ~]# setserial /dev/ttyS1
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
</verb></tscreen>

<item>En caso de haber cambiado la IRQ a utilizar por el puerto interno
del módem, (COM4) deberemos decírselo a Linux cada vez que lo arranquemos
(incluyendo el comando en el <it/script/ de arranque
<tt>/etc/rc.serial</tt>, si nuestra distribución es una <it/Slackware/, o
en <tt>/etc/rc.d/rc.serial</tt> si es <it/RedHat/). Si le hemos puesto en
la IRQ 10, y tenemos un módem superior a 22.8 Kbps, el comando (o la línea
a poner en dicho <it/script/) sería:

<tscreen><verb>
setserial -v /dev/ttyS3 irq 10 spd_vhi
</verb></tscreen>

Con el cual le indicamos que el COM4 (<tt>/dev/ttyS3</tt>) usará la IRQ
10, y que bloquee el puerto a alta velocidad (<it/SPeeD Very HIgh/). 

El parámetro <tt/-v/ hará que el comando devuelva la información de
configuración final del puerto. 
</enum>

Si se continúa com problemas, e incluso si no los tiene, es
recomendable leer el <it/Serie-Como/, disponible en &nl;
<tt><htmlurl url="http://www.insflug.org" 
name="http://www.insflug.org"></tt> o en el directorio de
traducciones (<tt>pub/Linux/docs/HOWTO/translations/es</tt>) disponible en
cualquier <it/mirror/ de <it/sunsite/.

<sect1><it>Software</it>

<p>

Básicamente, lo único necesario es tener soporte ppp ya por parte del
núcleo o <em/kernel/ o por módulos, en cuyo caso son necesarios tener
cargados <tt/shlc.o/ y <tt/ppp.o/, mediante por ejemplo la orden:

<tscreen><verb>
modprobe ppp
</verb></tscreen>

existen métodos más modernos como <tt/kerneld/ y otros en los que la carga
se automatiza al llamar al otro requisito, el ``demonio'' o <em/daemon/
<tt/pppd/, que suele instalarse en un paquete aparte. Téngase en cuenta
que si se emplea un kernel posterior al 1.3.95 ha de utilizarse una
versión de <tt/pppd/ posterior a la 2.2.0e. Para el kernel 1.2.13 vale a
partir de la 2.1.2d<footnote>Esto obviamente está "obsoleto".</footnote>. 

Los fuentes de distribución del kernel contienen un módulo de compresión
ppp, <tt/bsd_comp.o/, que por problemas de copyright no puede ser
compilado sino es como módulo, ni cargado automáticamente por
<tt/kerneld/. El uso de este módulo mejora el rendimiento de la conexión,
especialmente en lo referente a transferencia de ficheros. Para evitarnos
el tener que cargarlo ``a mano'' tras <tt/shlc.o/ y <tt/ppp.o/, podemos
crear un alias para <tt/pppd/:

<tscreen><verb>
alias pppd="pppd; modprobe bsd_comp"
</verb></tscreen>

que incluiremos en el fichero de personalización correspondiente, p. ej. 
<tt>/etc/bashrc</tt> si queremos que afecte a todos los usuarios
globalmente, o <tt>&tilde;/.bash_profile</tt> para cada uno de los 
usuarios de RedHat o <tt>&tilde;/.bashrc</tt> para Slackware. 

Ciertamente, no es una solución muy elegante, pero funciona :-).

Para conectarse a un <em/ISP/ (<em/Internet Service Provider/, o Proveedor
de Acceso a Internet) a través de nuestra queridísima Infovía, pueden
utilizarse los métodos que a continuación describo: 

<sect>Conexiones a través de Infovía.<label id="ConexionesInfobia">
<p>

<sect1>Método ``A''<label id="metodoA">

<p>

<enum>

<item>Fichero <tt>/etc/resolv.conf</tt>. &nl En el caso cada vez más
corriente, en que obtengamos nuestra dirección por asignación dinámica, se
ha de conocer la dirección en notación decimal del servidor de nombres o
<em/nameserver/ del ISP que nos proporciona acceso.  Esta información se
la ha de proporcionar su ISP, y <it/generalmente/ será de la forma 
<tt/194.xxx.yyy.zzz/. (En la posición <tt/zzz/ generalmente suele emplearse
el <tt/2/)

El dato restante es el nombre de dominio de su servidor, que será el mismo
que aparezca en su dirección de correo <em/email/, es decir, todo lo que
se encuentra tras la arroba. En mi caso, <tt/pacopepe@insflug.org/ sería por
tanto <tt/insflug.org/.

Una vez conocemos estos datos, editamos (con <tt/vi/, por ejemplo) el fichero
<tt>/etc/resolv.conf</tt>, de modo que añadimos: &nl

<tt>/etc/resolv.conf</tt>

<tscreen><verb>
domain insflug.org 
nameserver 194.xxx.yyy.zzz
</verb></tscreen>

<item>Elaboramos el fichero <tt>/etc/ppp/options</tt> (Sólo con versiones de
<tt/pppd/ iguales o inferiores a la <tt/2.2.x/)

<tscreen><verb>
connect /etc/ppp/infovia   
crtscts
modem
passive
+ua /etc/ppp/infoviappp   # Ojo en pppd version 2.3.x, opcion no valida
noipdefault
debug
defaultroute
asyncmap a0000
/dev/modem # (Este fichero es un enlace a /dev/ttySX)
38400 # (Siempre que su modem soporte esa velocidad)
</verb></tscreen>

<bf/Nota:/ Si nuestro <tt/pppd/ es de version <tt/2.2.3/ o superior, 
deberemos modificar el fichero <tt>/etc/ppp/options</tt>, suprimiendo la
línea <tt>+ua /etc/ppp/infoviappp</tt> y añadiendo:

<tscreen><verb>
...
+pap
user id@dominio
...
</verb</tscreen>

Así, utilizará en su lugar el fichero <tt>/etc/ppp/pap-secrets</tt> para
la autentificación:

<tscreen><verb>
infovia		*	infovia
id@dominio	dominio	clave
</verb></tscreen>

Para más información sobre <tt>pap-secrets</tt> ver apartado 
correspondiente de la sección <ref id="metodoB">.

<tt>/dev/ttySX</tt> es el fichero de dispositivo correspondiente al puerto
donde tengamos el módem, generalmente, el COM2 si lo vemos desde msdos, o
<tt>/dev/ttyS1</tt> en LiNUX. En caso de que en su sistema no exista
<tt>/dev/modem</tt>, puede crear un enlace o <em/symlink/ al puerto donde
se encuentra el módem, con la orden:

<tscreen><verb>
ln -s /dev/ttyS1 /dev/modem
</verb></tscreen>

Siempre que el COM2 sea el que esté usando el módem. Puede por supuesto
incluir directamente <tt>/dev/ttyS1</tt> en lugar de <tt>/dev/modem</tt>
en el anterior script si lo prefiere.

Para los usuarios de <it/Intercom/ o <it/bankinter/, los ficheros
<tt/options/ serían:

<itemize>

<item>Intercom
<tscreen><verb>
connect /etc/ppp/infovia
crtscts
modem
passive
noipdefault
ipcp-accept-local
ipcp-accept-remote
debug
defaultroute
lock
asyncmap a0000
/dev/modem
38400
</verb></tscreen>

<item>Bankinter
<tscreen><verb>
connect /etc/ppp/infovia
crtscts
modem
defaultroute
lock
/dev/modem
38400
</verb></tscreen> 
</itemize>

Los permisos del anterior script pueden ser 640 en forma octal o 

<tscreen><verb>
-rw-r-----   1 root     root
</verb></tscreen>

lo cual podemos conseguir con la orden:

<tscreen><verb>
chmod 640 /etc/ppp/options
</verb></tscreen>

<item>Fichero <tt>/etc/ppp/infovia</tt>

<tscreen><verb>
#!/bin/sh
/usr/sbin/chat -v  "" atdt055 CONNECT ""
</verb></tscreen>

Este fichero debe de hacerse ejecutable, con la orden por ejemplo:

<tscreen><verb>
chmod 744 /etc/ppp/infovia
</verb></tscreen>

<item>Fichero <tt>/etc/ppp/infoviappp</tt>

<tscreen><verb>
su_login  
su_password 
</verb></tscreen>

<tt/su_login/ quiere decir <tt/nombre@proveedor/, en mi caso
<tt/pacopepe@insflug/.  Este fichero es especialmente delicado, ya que
contiene la contraseña o password de acceso al ISP, por lo que conviene
tener cuidado con sus permisos;  yo no soy un gurú en eso, si alguien con
más experiencia me recomienda otro tipo de permisos, se lo agradeceré, yo
por ahora lo tengo como 640, por lo que con la orden

<tscreen><verb>
chmod 640 /etc/ppp/infoviappp
</verb></tscreen>

quedarían establecidos los permisos.

<item>Ejecutar, como <tt/root/, <tt/pppd/. Al momento se escuchará marcar
al módem, y una vez establecida la conexión, se escuchará actividad por
parte del disco duro; también, en el caso de poseer un módem externo, se
observará las luces de cd, sd y tr encendidas o parpadeando; en caso de
ser interno, podemos constatar que la conexión está establecida
correctamente, y que por tanto, el dispositivo ppp0 ha sido creado, con
una orden como ``<tt/top/'' o ``<tt/ps/'' en la que se observará como
proceso activo. 

También podemos observar el proceso de conexión conmutando a otra VC, y 
tecleando la orden

<tscreen><verb>
tail -f /var/log/messages
</verb></tscreen>

lo cual nos mostrará, en caso de problemas, los fallos que están
ocurriendo. Un proceso de conexión normal aparecería como:

<tscreen><verb>
May 23 01:51:00 beastie pppd[4485]: pppd 2.1.2 started by root, uid 0
May 23 01:51:00 beastie pppd[4488]: Connecting with /etc/ppp/infovia
May 23 01:51:02 beastie chat[4490]: send (atdt055^M)
May 23 01:51:02 beastie chat[4490]: expect (CONNECT)
May 23 01:51:23 beastie chat[4490]: atdt055^M^M
May 23 01:51:23 beastie chat[4490]: CONNECT -- got it
May 23 01:51:23 beastie chat[4490]: send (^M)
May 23 01:51:23 beastie pppd[4488]: Connected...
May 23 01:51:24 beastie kernel: ppp: channel ppp0 mtu = 1500, mru = 1500
May 23 01:51:24 beastie kernel: ppp: channel ppp0 open
May 23 01:51:24 beastie pppd[4488]: set kernel debugging level to 0
May 23 01:51:24 beastie pppd[4488]: Using interface ppp0
May 23 01:51:24 beastie pppd[4488]: Connect: ppp0 <--> /dev/modem
[...]
May 23 01:51:25 beastie pppd[4488]: ipcp: received ADDR
May 23 01:51:25 beastie pppd[4488]: (172.16.1.1)
May 23 01:51:25 beastie pppd[4488]:  (ACK)
May 23 01:51:25 beastie pppd[4488]: ipcp: returning Configure-ACK
May 23 01:51:25 beastie pppd[4488]: fsm_sdata(IPCP): Sent code 2, id 1.
May 23 01:51:25 beastie pppd[4488]: fsm_rconfnakrej(IPCP): Rcvd id 1.
May 23 01:51:25 beastie pppd[4488]: local IP address 194.179.123.229
May 23 01:51:25 beastie pppd[4488]: fsm_sdata(IPCP): Sent code 1, id 2.
May 23 01:51:25 beastie pppd[4488]: IPCP: sending Configure-Request, id 2
May 23 01:51:25 beastie pppd[4488]: fsm_rconfack(IPCP): Rcvd id 2.
May 23 01:51:25 beastie pppd[4488]: ipcp: up
May 23 01:51:25 beastie pppd[4488]: local  IP address 194.179.123.229
May 23 01:51:25 beastie pppd[4488]: remote IP address 172.16.1.1
</verb></tscreen> 

<item>Para finalizar la conexión podemos emplear el script que suele
acompañar al paquete pppd, <tt/ppp-off/, o bien ``matar'' directamente el
proceso una vez identificado su PID con <tt/ps/; para ello, si una vez
ejecutado <tt/ps/ observamos la respuesta: 

<tscreen><verb>
PID   TTY   STAT  TIME  COMMAND
58    v01   S     0:01  -bash
[...]
353   v03  R      1:12  pppd
[...]
</verb></tscreen> 

la orden

<tscreen><verb>
kill -9 353
</verb></tscreen>

matará el proceso. No obstante, algunas personas han experimentado
``cuelgues'' de sus servidores si no finalizan la conexión con métodos
``civilizados'' como el script <tt/ppp-off/. 

Uno puede hacerse un <tt/ppp-off/ rudimentario mediante el comando: 

<tscreen><verb>
killall pppd
</verb></tscreen>

Si se quiere saber más sobre los comandos de este script, consulte el
comando <tt/chat/ y la documentación sobre <tt/pppd/.

</enum>

<sect1>Método ``B''<label id="metodoB">

<p>

El mismo que el empleado para conectar sin mediar Infovía, descrito en la
sección <ref id="sininfovia" name="Conexiones sin mediar Infovía."> a
excepción de: 

<enum> 
<item>Fichero <tt>/etc/ppp/pap-secrets</tt>, que quedaría así:

<tscreen><verb>
infovia               *                  infovia
id@dominio            *                  su_password
</verb></tscreen>

donde <tt/id@dominio/ sería, en mi caso, <tt/pacopepe@insflug/, es decir, su
dirección <em/email/ sin el <tt/.es/ del dominio perteneciente a España. 


Este fichero es especialmente sensible por contener el password, por lo
que se aplica lo dicho anteriormente para el fichero 
<tt>/etc/ppp/infoviappp</tt> en la sección <ref id="metodoB" name="Método
``B''">, punto número 4. 


Como se puede observar, lo único que varía es que se añade la línea
referente a Infovía. 


<item>Cambiar la variable <tt/NUMERO/ del script
<tt>/usr/local/bin/infovia</tt> por <tt/055/, como corresponde a Infovía. 

</enum>

<sect>Conexiones sin mediar Infovía.<label id="sininfovia">

<p>

En el caso de que tengamos acceso directo a un servidor, los scripts y
ficheros necesarios serían los siguientes: 

<enum>
<item>Script <tt>/usr/local/bin/infovia</tt>

<tscreen><verb>
#!/bin/sh

LOCKDIR=/var/spool/uucp
DEVICE=modem
NUMERO=numero_del_Proveedor

if [ -f $LOCKDIR/LCK..$DEVICE ]
then
  echo /dev/$DEVICE "El modem esta ocupado."
  exit 1
fi

/usr/lib/ppp/fix-cua $DEVICE
(
    stty 38400 -tostop crtscts

    if /usr/lib/ppp/chat ABORT "NO CARRIER" ABORT BUSY "" ATZ0 OK ATDT$NUMERO CONNECT ""
    then
      pppd /dev/$DEVICE 38400 crtscts modem lock mtu 1500 defaultroute noipdefault user id@dominio
      sleep 10
      route add default ppp0
      exit 0
    else
        echo "La llamada PPP ha fallado." 1>&2
        exit 1
    fi
) < /dev/$DEVICE > /dev/$DEVICE
</verb></tscreen>

en donde:
<itemize>
<item>En la variable <tt/NUMERO=/ deberá reflejar el número de su Proveedor.
<item>En <tt/id@dominio/ tendrá que poner su dirección <em/email/ sin el 
<tt/.es/ del dominio perteneciente a España.
</itemize>

Este script ha de ser ejecutable, por lo que tenemos que otorgarle
permisos de ejecución, con una orden como por ejemplo: 

<tscreen><verb>
chmod 750 /usr/local/bin/infovia
</verb></tscreen>

A decir verdad, este script lo puede colocar donde quiera, si bien
<tt>/usr/local/bin/infovia</tt> sería la situación más ``estándar''. 

<item>Fichero <tt>/etc/ppp/pap-secrets</tt>

<tscreen><verb>
id@dominio            *                  su_password
</verb></tscreen>

nuevamente, se aplica lo dicho en la sección <ref id="metodoB"
name="Método ``B''">. 

<item>Fichero <tt>/etc/resolv.conf</tt> &nl

aquí se aplica lo mismo que en la sección <ref id="metodoA" name="Método
``A''"> punto número 1. 

<item>A partir de aquí, se aplica lo mismo que en la sección <ref
id="metodoA" name="Método ``A''">, punto 5, a excepción de que por
supuesto, no ha de ejecutarse pppd, ya que lo hacemos ejecutando el script
<tt>/usr/local/bin/infovia</tt>. 
  
<item><bf/ATENCIÓN usuarios de RedHat/ &nl

Si el sistema LiNUX que tiene instalado pertenece a una distribución
RedHat, deberá tener en cuenta lo siguiente: 

<itemize>
<item>En el script <tt>/usr/local/bin/infovia</tt> deberá modificarse las líneas
13 y 17, por:

<tscreen><verb>
[...]
/usr/lib/ppp/fix-cua $DEVICE  -->  /usr/sbin/fix-cua $DEVICE
[...]
if /usr/lib/ppp/chat...  --> if /usr/sbin/chat...
[...]
</verb></tscreen>
ya que la localización de dichos ficheros en RedHat está en esos directorios.

<item>Para ciertos programas que hacen uso del módem, como el <tt/binkley/, y
otros, resulta inocuo y muy conveniente crear el enlace o <em/symlink/
siguiente: 

<tscreen><verb>
ln -s /var/spool /usr
</verb></tscreen>

</itemize>

</enum>

Para obtener una visión más completa y detallada en lo que a <tt/ppp/ se
refiere, recomiendo hacerse con la traducción del <bf/PPP-Como/, realizada
por Rafael Agundo, <tt><htmlurl url="mailto:ragundo@bitmailer.net" 
name="ragundo@bitmailer.net"></tt>. En la sección <ref id="Grupos"
name="Insflug"> se detallan los servidores donde obtenerlo.

<sect>Gestión de Correo de Internet.
<p>

A continuación describiré dos métodos para gestionar el correo en el caso
que nos ocupa, una máquina aislada, con conexiones esporádicas a su
Servidor de Acceso a Internet. El método B es desde luego, poco ortodoxo y
se puede mejorar mucho, por lo que una colaboración en lo que a
configuraciones ``ideales'' de red de este tipo de máquinas será harto
agradecida.

<sect1>Método ``A'' o fácil y <em/güindosero/ ;-).
<p>

Instalar, usar y configurar Netscape, Mosaic u otro navegador con
capacidad de gestionar correo, news, etc. 

Como me consta que la inmensa mayoría de los que empiezan a usar Linux o
bien no poseen una cantidad desmesurada de RAM, ni les sobra disco duro
como para sacrificar más de 6 megas en el Netscape, y además desean
aprender a usar métodos más *nixeros y eficaces de gestión de correo,
propongo el siguiente (más fácil de configurar incluso que el netscape)
método: 

<sect1>Método ``B''.

<p>

<sect2>Requisitos

<p>

<enum>
<item><bf/Popclient./ Se precisa instalar el paquete Popclient. En caso de
que la versión de éste use <tt/perl/, se deberá instalar este último
también.

<item>popclient se ha quedado desfasado últimamente, siendo <tt/fetchmail/
el que más se emplea ahora por ser más seguro. 

<item><bf/Sendmail+IDA/. No, no os asustéis ;-) El <tt/sendmail+IDA/, que 
viene en la inmensa mayoría de las distribuciones, lo tendremos configurado 
con editar dos líneas.
</enum>

<sect2>Configuración del sistema.

<p>

<enum>Crear una cuenta en la máquina con el mismo identificativo que se
tenga en el Proveedor. Por ejemplo, mi identificativo o <em/login/ en mi
ISP es <tt/pacopepe/, cosa fácilmente deducible debido a mi dirección de
correo <em/email/;  por tanto, creo una cuenta en el sistema con login
<tt/pacopepe/, con el comando <tt/adduser/: (por supuesto, hay que hacerlo
como <tt/root/). 

Supongamos el login ``<tt/probancio/'':

<tscreen><verb>
 /home/linuxdoc-sgml-1.5/working]# adduser probancio

Looking for first available UID... 502
Looking for first available GID... 502

Adding login: probancio...done.
Creating home directory: /home/probancio...done.
Creating mailbox: /var/spool/mail/probancio...done.

Don't forget to set the password.
</verb></tscreen>

ahora, le asignamos un password:

<tscreen><verb>
 /home/linuxdoc-sgml-1.5/working]# passwd probancio
Changing password for probancio
Enter an empty password to quit.
New password (? for help):
New password (again):
Password changed for probancio
</verb></tscreen>

y tenemos creada su cuenta.
</enum>

<sect3><tt/popclient/
<p>

<enum>
<item>Ahora creamos el siguiente script, que será el que ejecutemos para
recoger el correo, al que llamamos, por ejemplo, &nl
<tt>/usr/local/bin/getmail</tt>

<tscreen><verb>
#!/bin/sh
#
# getmail, para bajarnos el correo...
#
PATH=/bin:/usr/bin:/usr/local/bin
echo Bajando el correo.....
popclient -3 -u <nombre_usuario> -p <password_del_ISP> -o /var/spool/mail/login <servidor_POP>
</verb></tscreen>

Dado que este fichero contiene datos delicados como las passwords del ISP,
lo protegeremos dándole los permisos adecuados (<tt/700/ es lo
recomendable). 

Donde en:

<descrip> 

<tag>&lt;nombre_usuario&gt;</tag> pondremos nuestro identificativo, en mi
caso, <tt/pacopepe/.

<tag>&lt;password_del_ISP&gt;</tag> Pues exactamente eso, la clave con la
que accede a su servidor. 

<tag>&lt;...login&gt;</tag> Como se observará tras crear la cuenta que
describimos anteriormente, en <tt>/var/spool/mail/</tt> se creará un
fichero de igual nombre que el <em/login/ de dicho usuario; en el caso
supuesto anterior, <tt/probancio/, este fichero sería
<tt>/var/spool/mail/probancio</tt>. 

<tag>&lt;servidor_POP&gt;</tag> Aquí ha de ponerse la dirección de vuestro
servidor POP; en mi caso (y suele ser común) <tt/pop03.insflug.org/. 
</descrip>

<bf/Nota:/ Al elaborar el script prescindiremos de los signos ``&lt'' y
``&gt''; en el ejemplo están simplemente para resaltar los parámetros a 
completar.

Juan Manuel Villar Navarro <tt><htmlurl
url="mailto:juanma@gaps.ssr.upm.es" name="juanma@gaps.ssr.upm.es"></tt>
apunta que en las versiones <tt/3.xx/ del <tt/popclient/ no se puede dar
por línea de comandos la contraseña del ISP, (con <tt/-p/) para ello ha de
usarse el fichero <tt>&tilde/.poprc</tt>, en el que podemos definir otros
parámetros de comportamiento, como el que mantenga los mensajes en el
servidor (<tt/keep/) en caso de que estemos de pruebas, o por cualquier
otra razón.

Iñigo González <tt><htmlurl url="mailto:nexus@adv.es"
name="nexus@adv.es"></tt> recomienda usar versiones del <tt/popclient/
superiores a la <tt/3.0b6/, además de sugerir el uso de un programa
filtrador de correo como <tt/procmail/, para lo que deberemos añadir al
comando <tt/getmail/ el parámetro <tt/-m procmail/.
</enum>

<sect3><tt/fetchmail/
<p>

En caso de usar fetchmail, un cliente muy potente y cuya documentación
es bastante clara y precisa, la configuración personal se almacena en el
fichero del directorio personal del usuario,
<tt>&tilde;/.fetchmailrc</tt>.

Un ejemplo del mismo:

<tscreen><verb>
poll host-servidor-pop proto pop3 user usuario password pass_usuario is usuario here;
</verb></tscreen>

donde 

<descrip>
<tag/host-servidor-pop/ sería el nombre del la máquina servidora de correo
vía pop del proveedor que utilicemos;
<tag/pop3/sería el protocolo a emplear, ya que <tt/fetchmail/ soporta
otros también, como <it/pop2/ (obsoleto) <it/imap2bis/ <it/imap4/ y
<it/apop/ y <it/kpop/.
</descrip>

seguidamente, le otorgaremos permisos de lectura/escritura únicamente para
el propietario, hecho muy importante, ya que de lo contrario podrían ser
accesibles las contraseñas, e incluso el programa  se
negaría a funcionar:

<tscreen><verb>
chmod 600 .fetchmailrc
</verb></tscreen>

<tt/fetchmail/ ofrece una serie de prestaciones adicionales, como
temporización, reenvío, funcionamiento en modo <it/daemon/ etc... Es un
cliente muy potente y recomendable en cuanto a seguridad se refiere. 

En caso de emplearlo, no haría falta el <it/script/ <tt/getmail/, bastaría
con invocar a <tt/fetchmail/ a secas.

<sect3><tt>sendmail</tt>
<p>

<enum>
<item>Modificación de la llamada al demonio <tt/sendmail/, hecha
normalmente en el arranque desde el script
<tt>/etc/rc.d/init.d/sendmail.init</tt>, (RedHat) o
<tt>/etc/rc.d/rc.M</tt> (Slackware) buscar la línea que dice algo así como
<tt/daemon sendmail ..../ en RedHat, o <tt>/usr/sbin/sendmail -bd -q
15m</tt> en Slackware, y modificarla, editándola para que quede: 

<tscreen><verb>
[...]
	.... sendmail -bd -q2d
[...]
</verb></tscreen>

Esto lo que hace es que <tt/sendmail/ no intente continuamente mandar el
correo que haya <em/en la cola/ para salir, o en <em/spool/, ya que lo
haremos nosotros manualmente. 

Si no hacemos esto veremos que al enviar un email estando desconectados,
el programa donde estemos (el <tt/pine/, por ejemplo) se quedará
``congelado'' un buen rato, debido a que sendmail intentará enviar
inmediatamente el email, y no encontrará el destino, hasta que finalmente
se produzca un <em/timeout/.

<item>Modificación de <tt>/etc/sendmail.cf</tt>. Aquí buscaremos una línea
que comienza por <tt/DS/: 

<tscreen><verb>
# "Smart" relay host (may be null)
# DS
</verb></tscreen>

y la modificaremos para que quede reflejado nuestro servidor SMTP o de
correo saliente: (en mi caso, <tt>smtp.insflug.org</tt>): 

<tscreen><verb>
# "Smart" relay host (may be null)
DSsmtp.insflug.org
</verb></tscreen>

ahora buscaremos otra que comienza por <tt/DM/:

<tscreen><verb>
# who I masquerade as (null for no masquerading)
# DM
</verb></tscreen>

y la modificamos para que refleje el dominio de nuestra dirección de correo, 
en mi caso <tt/insflug.org/:

<tscreen><verb>
# who I masquerade as (null for no masquerading)
DMinsflug.org
</verb></tscreen>

Con esto, lo que hemos hecho es básicamente, "enmascarar" nuestra
dirección en la máquina propia; supongamos que nuestra máquina se llama
<tt/beastie.insflug.org/ y enviamos un mensaje sin la modificación
anterior; el mensaje llegará correctamente a su destino, pero no podrá ser
respondido, ya que la dirección de retorno no existirá, al figurar la de
nuestra propia máquina, que en nuestro caso ficticio sería
<tt/probancio@beastie.insflug.org/, en lugar de la de la cuenta de nuestro
ISP, que es <tt/probancio@insflug.org/. 

Realmente, lo único que enmascaramos es el dominio, de ahí la necesidad de
crear una cuenta en nuestra máquina con el mismo login que en nuestro ISP
(<tt/probancio/ en este caso); la línea <tt/DS.../ hace que sendmail rute
todos los mensajes salientes hacia internet a través de nuestro servidor
SMTP, que hace de servidor de <it/relevo/ hacia internet.  Podríamos no
decirle nada, y dejar que se encargara de contactar y enviar directamente
con el servidor de correo entrante de cada dirección, pero eso haría más
lento el envío de los correo, además de que es mucho más rápida la
transferencia con nuestro ISP, al no tener que salir a internet siquiera.

<tt/DM.../ cambia los <tt/from/ de nuestros mensajes por nuestra verdadera
dirección en el ISP.  
</enum>

<sect2>Cómo escribir

<p>

Para responder o escribir nuestro correo podremos usar cualquier programa
escritor de correo, los simples como <tt/mail/ o <tt/mailx/, un poco más
completos como el facilísimo <tt/elm/, o <tt/pine/, el modo de correo del
versátil <tt/emacs/, etc... recordando <bf/siempre/ hacer uso de estos
programas desde la cuenta que creamos para tal fin (la de <tt/probancio/
en nuestro caso ficticio). 


<sect2>Procedimiento.

<p>

<enum>

<item>Establecer la conexión <tt/PPP/ con nuestro servidor, con cualquiera
de los métodos descritos en las secciones <ref id="sininfovia"
name="Conexiones sin mediar Infovía"> o <ref id="ConexionesInfobia"
name="Conexiones a través de Infovía">. Esto se hará normalmente como
<tt/root/. 

<item>Ejecutar el script <tt/getmail/ en caso de que queramos recoger el
correo;  en caso de querer mandar el correo pendiente por salir, teclear
la orden: 

<tscreen><verb>
sendmail -q
</verb></tscreen>

que ordenará a sendmail a enviar el correo. (el parámetro <tt/-q/ 
viene de <em/queue/ o la ``cola'' de correo pendiente por salir).

</enum>

Por supuesto, los procedimientos para establecer la conexión y
recoger/mandar correo se pueden automatizar escribiendo scripts sencillos,
pero eso lo dejo ya al gusto y según las circunstancias de cada uno.
Estaré encantado de recibirlos, a fin de incluirlos en la próxima versión
de este <em/COMO/. 

<sect1>Método ``C''.
<p>

Empleando clientes de correo capaces de enmascarar al usuario/dominio,
podemos prescindir de la fase de configuración del enmascaramiento de
dominio del <tt/sendmail/. El cliente de correo
(<it/MUA/<footnote><it/Mail User Application/, aplicación de gestión de
correo a nivel usuario)</footnote> <tt/mutt/, puede hacer esto, a nivel
tanto de dominio como de usuario, entre otras muchas prestaciones que
harán las delicias de los amantes del modo texto: gestión <tt/pgp/
integrada, <it/threads/, color... Un cliente muy recomendable. Su servidor
de ftp primario es:

<tt><htmlurl url="ftp://ftp.cs.hmc.edu/pub/me/mutt" 
name="ftp://ftp.cs.hmc.edu/pub/me/mutt"></tt>

Es posible también prescindir de la ``<it/chapucilla/'' de tener que
emplear el mismo usuario que en el proveedor empleando un
<it/MTA/<footnote><it/Mail Tranfer Agent/, Agente de Gestión de
transferencia de Correo</footnote> de configuración más flexible y cómoda
que <tt/sendmail/, como el prometedor <tt/qmail/, fácilmente obtenible en
Internet, que además ofrece muchas otras prestaciones, sin la fragilidad
en cuanto a seguridad de <tt/sendmail/, y menos exigente en cuanto a
recursos, lo que le hace ideal para listas de correo..

<sect>Agradecimientos

<p>

Mi más sincero agradecimiento a todos los contertulios de R34.LINUX, y a
los de la Lista de correo de RedHat, así como a José L. Navarro Simón,
<tt>2:345/102.36</tt> y Miguel Cruz por los scripts a través de infovía, a
Urko Lusa, <tt>2:344/25.8</tt> por los de acceso directo, y a Eric S.
Pulley, <tt><htmlurl url="mailto:pulley@dabus.com"
name="pulley@dabus.com"></tt> por las explicaciones con lo relacionado
con el correo.

A Carlos Terrón por sus correcciones, a Juan Manuel Villar Navarro
<tt><htmlurl url="mailto:juanma@gaps.ssr.upm.es"
name="juanma@gaps.ssr.upm.es"></tt> por sus apuntes sobre <tt/popmail/,
y a Iñigo González <tt><htmlurl url="mailto:nexus@adv.es"
name="nexus@adv.es"></tt> por las sugerencias sobre <tt/procmail/, y a
Jesús Fuentes Saavedra <tt><htmlurl
url="mailto:jesus.fuentes@etsi.uva.tel.es"
name="jesus.fuentes@etsi.uva.tel.es"></tt> por el detalle del
<tt/bsd_comp/, y tantísimas otras cosas...

A Antonio Verdejo García aka <it/wait_man/, <tt><htmlurl
url="mailto:wait&lowbar;man@hotmail.com"
name="wait&lowbar;man@hotmail.com"></tt> por su lista de winmodems y
tantas otras críticas y sugerencias.

<sect>Copyright<label id="sec-copy">

<p>
Este documento es Copyright (c)1996 de Francisco José Montilla. Este
trabajo puede ser reproducido en su totalidad o en parte, tanto de forma
impresa como electrónica, sujeto a las siguientes condiciones: 

<enum>
<item>La notificación del copyright y esta licencia debe preservarse
completa en todas las copias, tanto completas como parciales. 

<item>Cualquier traducción o trabajo derivado debe de ser
aprobado por el autor por escrito antes de su distribución.

<item>Si se distribuye el Trabajo parcialmente, deben de incluirse
instrucciones para poder obtener la versión completa (en forma impresa
o electrónica), así como los medios para conseguirla.

<item>Pueden ser reproducidas pequeñas porciones como ilustraciones
para revistas o citas para otros trabajos sin esta notificación de
permiso si se cita apropiadamente su procedencia.
</enum>

<sect>Anexo: El INSFLUG <label id="Grupos">
<p>

El <em/INSFLUG/ forma parte del grupo internacional 
<it/Linux Documentation Project/, 
encargándose de las traducciones al castellano de los Howtos (Comos),
así como la producción de documentos originales en aquellos casos
en los que no existe análogo en inglés.

En el <bf/INSFLUG/ se orienta preferentemente a la traducción de documentos
breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de
<bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc.

Diríjase a la sede del INSFLUG para más información al respecto.

En la sede del INSFLUG encontrará siempre las <bf/últimas/ versiones 
de las traducciones:  <tt><htmlurl url="www.insflug.org" 
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última versión 
disponible en el Insflug antes de bajar un documento de un servidor réplica.

Se proporciona también una lista de los servidores
réplica (<it/mirror/) del Insflug más cercanos a Vd.,  
e información relativa a otros recursos en castellano.

Francisco José Montilla, <tt><htmlurl url="mailto:pacopepe@insflug.org"
name="pacopepe@insflug.org"></tt>.

</article>
