Comprobar la delegación de DNS inversa

El nombre más exacto sería Delegación IN-ADDR.ARPA sin clase, pero el que tiene por ahora tiene como más mejor posicionamente en buscadores, y es la forma en que la mayoria del mundo lo conoce.

La idea es que la resolución inversa DNS suele estar fuertemente asociada a los ISP que administran las IP que se han de resolver. Sin embargo, en ocasiones puede ser bastante engorroso tener que consultar con ellos los cambios en nuestras entradas DNS, sobre todo cuando son demasiadas.

Después de las gestiones administrativas necesarias, es posible que nos delegue la resolución inversa para una red sin clase, básicamente, las direcciones IP públicas que nos han sido proporcionadas.

Las comprobaciones pueden ser un poco tediosas, pero son sumamente necesarias para garantizar que todo esté funcionando como es debido. Si bien no hay una especie de fórmula mágica para este caso, es posible establecer una especie de pasos a seguir para comprobar que todo esté funcionando perfectamente

• Puede obtener los servidores DNS de su proveedor, usualmente preguntandole, sino, puede intentar a buscar los servidores dados para su dominio, en ese caso, proveedor.com
  Una comprobación exhaustiva requiere que se revise cada uno de los servidores DNS que aparecen como respuesta. Un DNS de su proveedor que no tenga los registros actualizados hará que los registros que se propagan por internet tengan errores.

dig NS proveedor.com +noall +additional
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> NS proveedor.com +noall +additional
;; global options: +cmd
ns.proveedor.net.         35430    IN    A    200.1.2.3
ns.proveedor9.net.        35027    IN    A    200.1.2.4  

• Luego, hay que comprobar que los servidores DNS del proveedor no pueda resolver la entrada PTR para nuestras IP, como normalmente haría, sino que frente a las consultas DNS devuelva un CNAME que ha de enviar a la autoridad para esas IP, que ya debe estar señalada como nuestros servidores DNS. Usaremos una ip 200.1.2.130, que debe estar dentro del rango de IP públicas de las que el proveedor nos transfiere la autoridad.

dig @200.1.2.3 -x 200.1.2.130 +norecurse +noall +answer +authority +comment
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> @200.1.2.3 -x 200.1.2.130 +norecurse +noall +answer +authority +comment
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16232
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
130.2.1.200.in-addr.arpa. 86400 IN    CNAME    130.128-254.2.1.200.in-addr.arpa.

;; AUTHORITY SECTION:
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns1.institucion.com.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns2.institucion.com.

Podemos obtener la forma actual del registro PTR viendo el CNAME que el servidor de nuestro proveedor devuelve en la sección ANSWER en la respuesta de la consulta anterior, pero bien puede verlo más claro con el siguiente comando

dig @200.1.2.3 -x 200.1.2.130 +norecurse +short
130.128-254.2.1.200.in-addr.arpa.

Dado que nuestros servidores DNS resuelven la reversa en base a la forma en que el servidor de su proveedor se las tranfiere, (Vea el CNAME que el servidor DNS de su proveedor ha devuelto), tenga en cuenta que su servidor ya no puede resolver ninguna de las siguientes consultas

dig @ns1.institucion.com PTR 130.2.1.200.in-addr.arpa

dig @ns1.institucion.com -x 200.1.2.130

que son con las que normalmente haría una comprobación de este tipo, pero tome en cuenta que cualquier otro servidor debe ser capaz de obtener respuestas de las mismas

dig @8.8.8.8 -x 200.1.2.130 +short
130.128-254.2.1.200.in-addr.arpa.
mail.salud.gob.sv.

dig @8.8.8.8 PTR 130.2.1.200.in-addr.arpa +short
130.128-254.2.1.200.in-addr.arpa.
mail.salud.gob.sv.

Para resolver correctamente en sus servidores DNS, debe hacer la consulta PTR igual al CNAME devuelto por los DNS de su proveedor. Lo que significa que usted ha configurado según parámetros del proveedor.

dig @ns1.institucion.com 130.128-254.2.1.200.in-addr.arpa
correo.institucion.com.

• Una de las pruebas más exhaustivas para empezar a revisar el problema desde un principio es hacer un dig +trace, ya que el resultado especifica el final de cada bloque, en la línea que empieza por Received x bytes… el servidor que responde por dicho bloque, así que puede rastrear si algún servidor están enviando resultados erróneos.

dig @8.8.8.8 -x 200.31.169.130 +trace +nodnssec

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> @8.8.8.8 -x 200.31.169.130 +trace +nodnssec
; (1 server found)
;; global options: +cmd
.            19272    IN    NS    a.root-servers.net.
.            19272    IN    NS    l.root-servers.net.
.            19272    IN    NS    m.root-servers.net.
.            19272    IN    NS    j.root-servers.net.
.            19272    IN    NS    f.root-servers.net.
.            19272    IN    NS    i.root-servers.net.
.            19272    IN    NS    e.root-servers.net.
.            19272    IN    NS    g.root-servers.net.
.            19272    IN    NS    h.root-servers.net.
.            19272    IN    NS    d.root-servers.net.
.            19272    IN    NS    c.root-servers.net.
.            19272    IN    NS    k.root-servers.net.
.            19272    IN    NS    b.root-servers.net.
;; Received 239 bytes from 8.8.8.8#53(8.8.8.8) in 31 ms

in-addr.arpa.        172800    IN    NS    e.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    a.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    c.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    d.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    f.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    b.in-addr-servers.arpa.
;; Received 432 bytes from 192.33.4.12#53(c.root-servers.net) in 63 ms

200.in-addr.arpa.    86400    IN    NS    a.arpa.dns.br.
200.in-addr.arpa.    86400    IN    NS    ns.lacnic.net.
200.in-addr.arpa.    86400    IN    NS    ns2.lacnic.net.
200.in-addr.arpa.    86400    IN    NS    ns3.afrinic.net.
200.in-addr.arpa.    86400    IN    NS    sec1.authdns.ripe.net.
200.in-addr.arpa.    86400    IN    NS    sec3.apnic.net.
200.in-addr.arpa.    86400    IN    NS    tinnie.arin.net.
200.in-addr.arpa.    86400    IN    NS    ns-lacnic.nic.mx.
;; Received 267 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 174 ms

2.1.200.in-addr.arpa. 86400    IN    NS    NS.PROVEEDOR.NET.
;; Received 83 bytes from 204.61.215.62#53(ns3.afrinic.net) in 120 ms

130.2.1.200.in-addr.arpa. 86400 IN    CNAME    130.128-254.2.1.200.in-addr.arpa.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns1.institucion.com.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns2.institucion.com.
;; Received 162 bytes from 200.1.2.3#53(NS.PROVEEDOR.NET) in 2 ms

(1) Fuente
(2) Fuente

Notas sobre la forma de hacer nateo respecto a rutas

Este post será dentro de poco algo obsoleto, en cuanto el nateo será una técnica inútil cuando IPv6 termine su despliegue, sin embargo, aprovecho a subir estas notas porque en ningún lugar hacen bien excepto aquí

De este esquema hablo

¿Podría este esquema acceder a un FTP en Sucursal?
Totalmente, siempre y cuando entre el Firewall y y Sucursal no se este nateando el tráfico desde LAN, ya que estamos nateando el tráfico de LAN en Firewall, lo que haría un segundo nateo (Nadie en sus cabales lo haría, pero yo no estaba en mis cabales el día que jugué con una configuración de ese tipo )

Rutas
En una configuración de primer o segundo caso completas, es necesario configurar rutas para especificar cual es el gateway que deben usar para llegar a tal ruta, y en consecuencia, que interfaz física han de buscar para salir. (Si bien se haya configurado la ip en una interfaz virtual, lo importante es la física sobre la que esa interfaz virtual trabaja)

Las interfaces virtuales son un chiste dentro de la configuración de iptables
Es bastante común que se configure la interfaz hacia DMZ (Central + Sucursal) como una interfaz virtual respecto a la interfaz hacia internet.

En ese caso, iptables toma en cuenta la interfaz fisica debido a que es lo que la configuración de rutas toma en cuenta.

Para ejemplo: Habiendo configurado como rutas adicionales

route add -net  192.168.10.0 gw 172.16.2.1
route add -net  192.168.83.0 gw 172.16.2.1
route add -net  192.168.85.0 gw 172.16.2.1
route add -net  192.168.87.0 gw 172.16.2.1

Y estando configurada 172.16.2.1 sobre una interfaz virtual eth0:1, las rutas para el sistema deberían aparecer de la siguiente forma

root@firewall:~# route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.25   0.0.0.0         UG    0      0        0 eth0
10.10.20.0      172.16.2.1      255.255.255.0   UG    0      0        0 eth0
10.20.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.30.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth2
172.16.2.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.10.0    0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.83.0    172.16.2.1      255.255.255.0   UG    0      0        0 eth0
192.168.85.0    172.16.2.1      255.255.255.0   UG    0      0        0 eth0
192.168.87.0    172.16.2.1      255.255.255.0   UG    0      0        0 eth0

Hice un experimento para demostrarme lo anterior, y no es del todo complicado una vez que se entiende lo hasta ahora expuesto, pero como yo no lo entendía casi me mata
 Imagínemos que hemos configurado firewall, y que tenemos acceso a nebula, que es un equipo que se encuentra entre Firewall y DMZ (Central + Sucursal). En la vida real, este es un proveedor de enlaces, pero el experimento va de configurar un equipo cualquiera como nebula con apenas forwarding de paquetes y un par de reglas en la cadena POSTROUTING en la tabla nat de iptables

Cuando Firewall muestra esto:

root@firewall:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    3   189 ACCEPT     all  --  *      eth0    10.20.20.0/24        10.10.20.0/24        /* Vamos hacia DMZ */
    3   180 MASQUERADE  all  --  *      eth0    10.20.20.0/24        0.0.0.0/0            match-set rwa dst /* Vamos hacia RWA */
    0     0 MASQUERADE  all  --  *      eth0    10.20.20.0/24        0.0.0.0/0            /* Vamos hacia Internet */

Nebula nebula dice estar nateando de esta manera:

root@nebula:~# iptables -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 5 packets, 1058 bytes)
 pkts bytes target     prot opt in     out     source               destination        
    3   189 MASQUERADE  all  --  *      br0     10.20.20.0/24        0.0.0.0/0          
    3   180 MASQUERADE  all  --  *      br0     172.16.2.0/24        0.0.0.0/0  

Cuando el destino desde la red $LAN era 10.10.20.0, #firewall no lo natea en realidad, por tanto llega a #nebula con su ip original como se puede ver, y hace coincidencia en la regla esperada para tal fin, en el ejemplo la primera
Luego, cuando el destino eran los grupos en rwa, (que de hecho incluyen a 10.10.20.0/24, pero al anteponer la regla anterior en el orden de iptables nunca llegará a este punto) #firewall nateo con salida en la interfaz eth0, pero hay que fijarse en eth0

root@firewall:~# ip addr show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:de:78:a8 brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.15/24 brd 172.16.2.255 scope global eth0:1
    inet 192.168.10.15/27 brd 192.168.10.31 scope global eth0
    inet6 fe80::5054:ff:fede:78a8/64 scope link
       valid_lft forever preferred_lft forever 

Si bien se especifica la interfaz eth0 en su totalidad, iptables en #firewall natea la salida con la ip 172.16.2.15/24, (Puede observarse que pertenece a eth0:1 porque fue creada con ifconfig). La prueba de dicho nateo esta en que en #nebula se ha hecho coincidencia en la regla para nateo de 172.16.2.0/24, no de 192.168.10.0/27 (Regla que de hecho no existe en #nebula), porque en la tabla de ruteo mostrada arriba se especifica que hacia las redes en el grupo ipset #rwa es a traves de  172.16.2.1

Es obvio que llegando a este punto mi explicación podría ser insuficiente para entender, confió en que las tablas que he colocado sean de hecho más explicativas por si mismas

Para arrancar un nebula como el que use para revisar todo la teoría

Nebula debe conocer esas redes que natea, para que cuando le devuelvan las peticiones el sepa a donde putas debe enviarlas:

root@nebula:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG    0      0        0 br0
10.20.20.0      172.16.2.15     255.255.255.0   UG    0      0        0 br1
10.30.20.0      0.0.0.0         255.255.255.0   U     0      0        0 virbr2
172.16.2.0      0.0.0.0         255.255.255.224 U     0      0        0 br1
172.16.3.0      0.0.0.0         255.255.255.0   U     0      0        0 br1
192.168.10.0    0.0.0.0         255.255.255.224 U     0      0        0 br0

Nateamos

iptables -t nat -D POSTROUTING -o br0 -s 192.168.10.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o br0 -s 172.16.2.0/24 -j MASQUERADE
iptables -t nat -A POSTROUTING -o br0 -s 172.16.3.0/24 -j MASQUERADE

"Instalar" Java: update-alternatives en Fedora 21

Si bien tengo ya una entrada sobre como configurar Java (Tomando como base una instalación de OpenSuSE), creí conveniente actualizarla un poco.

Lo recomendable es usar el RPM, tal como lo indica esta guía. Como sea, parece ser que el RPM no configura la alternativa, y lo que es más,  la instalación de OpenOffice ya había instalado la openJDK como dependencia, así que será necesario usar update-alternatives para no hacer un lío (Aunque tuve que hacer un lío para evitarlo).

Básicamente, los comandos a usar son estos:

update-alternatives --install /bin/java java /usr/java/default/bin/java 200 --slave /usr/share/man/man1/java.1.gz java.1.gz /usr/java/default/man/man1/java.1.gz \
--slave /bin/javaws javaws /usr/java/default/bin/javaws --slave /usr/share/man/man1/javaws.1.gz javaws.1.gz /usr/java/default/man/man1/javaws.1.gz \
--slave /bin/jcontrol jcontrol /usr/java/default/bin/jcontrol --slave /usr/share/man/man1/jcontrol.1.gz jcontrol.1.gz /usr/java/default/man/man1/jcontrol.1.gz \
--slave /bin/jjs jjs /usr/java/default/bin/jjs --slave /usr/share/man/man1/jjs.1.gz jjs.1.gz /usr/java/default/man/man1/jjs.1.gz \
--slave /bin/keytool keytool /usr/java/default/bin/keytool --slave /usr/share/man/man1/keytool.1.gz keytool.1.gz /usr/java/default/man/man1/keytool.1.gz \
--slave /bin/orbd orbd /usr/java/default/bin/orbd --slave /usr/share/man/man1/orbd.1.gz orbd.1.gz /usr/java/default/man/man1/orbd.1.gz \
--slave /bin/pack200 pack200 /usr/java/default/bin/pack200 --slave /usr/share/man/man1/pack200.1.gz pack200.1.gz /usr/java/default/man/man1/pack200.1.gz \
--slave /bin/policytool policytool /usr/java/default/bin/policytool --slave /usr/share/man/man1/policytool.1.gz policytool.1.gz /usr/java/default/man/man1/policytool.1.gz \
--slave /bin/rmid rmid /usr/java/default/bin/rmid --slave /usr/share/man/man1/rmid.1.gz rmid.1.gz /usr/java/default/man/man1/rmid.1.gz \
--slave /bin/rmiregistry rmiregistry /usr/java/default/bin/rmiregistry --slave /usr/share/man/man1/rmiregistry.1.gz rmiregistry.1.gz /usr/java/default/man/man1/rmiregistry.1.gz \
--slave /bin/servertool servertool /usr/java/default/bin/servertool --slave /usr/share/man/man1/servertool.1.gz servertool.1.gz /usr/java/default/man/man1/servertool.1.gz \
--slave /bin/tnameserv tnameserv /usr/java/default/bin/tnameserv --slave /usr/share/man/man1/tnameserv.1.gz tnameserv.1.gz /usr/java/default/man/man1/tnameserv.1.gz \
--slave /bin/unpack200 unpack200 /usr/java/default/bin/unpack200 --slave /usr/share/man/man1/unpack200.1.gz unpack200.1.gz /usr/java/default/man/man1/unpack200.1.gz

update-alternatives --install /usr/bin/javac javac /usr/java/default/bin/javac 200 --slave /usr/share/man/man1/javac.1.gz javac.1.gz /usr/java/default/man/man1/javac.1.gz \
--slave /usr/bin/appletviewer appletviewer /usr/java/default/bin/appletviewer --slave /usr/share/man/man1/appletviewer.1.gz appletviewer.1.gz /usr/java/default/man/man1/appletviewer.1.gz \
--slave /usr/bin/extcheck extcheck /usr/java/default/bin/extcheck --slave /usr/share/man/man1/extcheck.1.gz extcheck.1.gz /usr/java/default/man/man1/extcheck.1.gz \
--slave /usr/bin/idlj idlj /usr/java/default/bin/idlj --slave /usr/share/man/man1/idlj.1.gz idlj.1.gz /usr/java/default/man/man1/idlj.1.gz \
--slave /usr/bin/jar jar /usr/java/default/bin/jar --slave /usr/share/man/man1/jar.1.gz jar.1.gz /usr/java/default/man/man1/jar.1.gz \
--slave /usr/bin/jarsigner jarsigner /usr/java/default/bin/jarsigner --slave /usr/share/man/man1/jarsigner.1.gz jarsigner.1.gz /usr/java/default/man/man1/jarsigner.1.gz \
--slave /usr/bin/java-rmi.cgi java-rmi.cgi /usr/java/default/bin/java-rmi.cgi --slave /usr/share/man/man1/java-rmi.cgi.1.gz java-rmi.cgi.1.gz /usr/java/default/man/man1/java-rmi.cgi.1.gz \
--slave /usr/bin/javadoc javadoc /usr/java/default/bin/javadoc --slave /usr/share/man/man1/javadoc.1.gz javadoc.1.gz /usr/java/default/man/man1/javadoc.1.gz \
--slave /usr/bin/javafxpackager javafxpackager /usr/java/default/bin/javafxpackager --slave /usr/share/man/man1/javafxpackager.1.gz javafxpackager.1.gz /usr/java/default/man/man1/javafxpackager.1.gz \
--slave /usr/bin/javah javah /usr/java/default/bin/javah --slave /usr/share/man/man1/javah.1.gz javah.1.gz /usr/java/default/man/man1/javah.1.gz \
--slave /usr/bin/javap javap /usr/java/default/bin/javap --slave /usr/share/man/man1/javap.1.gz javap.1.gz /usr/java/default/man/man1/javap.1.gz \
--slave /usr/bin/javapackager javapackager /usr/java/default/bin/javapackager --slave /usr/share/man/man1/javapackager.1.gz javapackager.1.gz /usr/java/default/man/man1/javapackager.1.gz \
--slave /usr/bin/jcmd jcmd /usr/java/default/bin/jcmd --slave /usr/share/man/man1/jcmd.1.gz jcmd.1.gz /usr/java/default/man/man1/jcmd.1.gz \
--slave /usr/bin/jconsole jconsole /usr/java/default/bin/jconsole --slave /usr/share/man/man1/jconsole.1.gz jconsole.1.gz /usr/java/default/man/man1/jconsole.1.gz \
--slave /usr/bin/jdb jdb /usr/java/default/bin/jdb --slave /usr/share/man/man1/jdb.1.gz jdb.1.gz /usr/java/default/man/man1/jdb.1.gz \
--slave /usr/bin/jdeps jdeps /usr/java/default/bin/jdeps --slave /usr/share/man/man1/jdeps.1.gz jdeps.1.gz /usr/java/default/man/man1/jdeps.1.gz \
--slave /usr/bin/jhat jhat /usr/java/default/bin/jhat --slave /usr/share/man/man1/jhat.1.gz jhat.1.gz /usr/java/default/man/man1/jhat.1.gz \
--slave /usr/bin/jinfo jinfo /usr/java/default/bin/jinfo --slave /usr/share/man/man1/jinfo.1.gz jinfo.1.gz /usr/java/default/man/man1/jinfo.1.gz \
--slave /usr/bin/jmap jmap /usr/java/default/bin/jmap --slave /usr/share/man/man1/jmap.1.gz jmap.1.gz /usr/java/default/man/man1/jmap.1.gz \
--slave /usr/bin/jmc jmc /usr/java/default/bin/jmc --slave /usr/share/man/man1/jmc.1.gz jmc.1.gz /usr/java/default/man/man1/jmc.1.gz \
--slave /usr/bin/jmc.ini jmc.ini /usr/java/default/bin/jmc.ini --slave /usr/share/man/man1/jmc.ini.1.gz jmc.ini.1.gz /usr/java/default/man/man1/jmc.ini.1.gz \
--slave /usr/bin/jps jps /usr/java/default/bin/jps --slave /usr/share/man/man1/jps.1.gz jps.1.gz /usr/java/default/man/man1/jps.1.gz \
--slave /usr/bin/jrunscript jrunscript /usr/java/default/bin/jrunscript --slave /usr/share/man/man1/jrunscript.1.gz jrunscript.1.gz /usr/java/default/man/man1/jrunscript.1.gz \
--slave /usr/bin/jsadebugd jsadebugd /usr/java/default/bin/jsadebugd --slave /usr/share/man/man1/jsadebugd.1.gz jsadebugd.1.gz /usr/java/default/man/man1/jsadebugd.1.gz \
--slave /usr/bin/jstack jstack /usr/java/default/bin/jstack --slave /usr/share/man/man1/jstack.1.gz jstack.1.gz /usr/java/default/man/man1/jstack.1.gz \
--slave /usr/bin/jstat jstat /usr/java/default/bin/jstat --slave /usr/share/man/man1/jstat.1.gz jstat.1.gz /usr/java/default/man/man1/jstat.1.gz \
--slave /usr/bin/jstatd jstatd /usr/java/default/bin/jstatd --slave /usr/share/man/man1/jstatd.1.gz jstatd.1.gz /usr/java/default/man/man1/jstatd.1.gz \
--slave /usr/bin/jvisualvm jvisualvm /usr/java/default/bin/jvisualvm --slave /usr/share/man/man1/jvisualvm.1.gz jvisualvm.1.gz /usr/java/default/man/man1/jvisualvm.1.gz \
--slave /usr/bin/native2ascii native2ascii /usr/java/default/bin/native2ascii --slave /usr/share/man/man1/native2ascii.1.gz native2ascii.1.gz /usr/java/default/man/man1/native2ascii.1.gz \
--slave /usr/bin/rmic rmic /usr/java/default/bin/rmic --slave /usr/share/man/man1/rmic.1.gz rmic.1.gz /usr/java/default/man/man1/rmic.1.gz \
--slave /usr/bin/schemagen schemagen /usr/java/default/bin/schemagen --slave /usr/share/man/man1/schemagen.1.gz schemagen.1.gz /usr/java/default/man/man1/schemagen.1.gz \
--slave /usr/bin/serialver serialver /usr/java/default/bin/serialver --slave /usr/share/man/man1/serialver.1.gz serialver.1.gz /usr/java/default/man/man1/serialver.1.gz \
--slave /usr/bin/wsgen wsgen /usr/java/default/bin/wsgen --slave /usr/share/man/man1/wsgen.1.gz wsgen.1.gz /usr/java/default/man/man1/wsgen.1.gz \
--slave /usr/bin/wsimport wsimport /usr/java/default/bin/wsimport --slave /usr/share/man/man1/wsimport.1.gz wsimport.1.gz /usr/java/default/man/man1/wsimport.1.gz \
--slave /usr/bin/xjc xjc /usr/java/default/bin/xjc --slave /usr/share/man/man1/xjc.1.gz xjc.1.gz /usr/java/default/man/man1/xjc.1.gz  

Pero como el proceso fue tan educativo, vale la pena explicarlo un poco

• Los script dentro del RPM de Java alojan su contenido en /usr/java/. Crea dos enlaces simbolicos: default y latest que apuntan hacia el directorio jdk<version>. 
• Suponemos que cuando actualicemos con otro RPM, actualizará dichos enlaces simbólicos.
• Dado lo anterior, apuntamos la dirección en el comando update-alternatives a /usr/java/default, para no tener que realizar todo este proceso con cada actualización de JDK
•  Antes de empezar a configurar las alternativas, empaquetamos los manuales relacionados con los paquetes java.

for i in `find /usr/java/jdk1.8.0_31/man/man1/ -mindepth 1 -exec readlink -f {} +`; do gzip $i; done

•  Para el primer comando update-alternatives, buscamos todo software que se relacione con java (JRE): se alojan en /usr/java/default/jre/bin/, pero los apuntaremos a /usr/java/default/bin/.

lista=""
for i in `find /usr/java/default/jre/bin/ -type f`; do lista="$lista `basename $i`"; done

for i in ${lista[*]}; do 
  if [[ $i = java ]]; then
    echo -e update-alternatives --install /usr/bin/java java  /usr/java/default/bin/java 200 --slave /usr/share/man/man1/java.1.gz java.1.gz /usr/java/default/man/man1/java.1.gz "\\"
  else
    echo -e --slave /usr/bin/$i $i /usr/java/default/bin/$i --slave /usr/share/man/man1/$i.1.gz $i.1.gz /usr/java/default/man/man1/$i.1.gz "\\"; 
  fi
done

Luego, buscamos en /usr/java/default/bin/ todo el software que no está en $lista, es decir, aquellos que no configuramos como esclavo de java, y que he querido suponer que son todas herramientas de desarrollo:

for j in `find /usr/java/default/bin/ -type f `; do
  i=`basename $j`
  if [[ $lista != *`basename $i`* ]]; then 
    if [[ `basename $i` = javac ]]; then
      echo -e update-alternatives --install /usr/bin/javac javac  /usr/java/default/bin/javac 200 --slave /usr/share/man/man1/javac.1.gz javac.1.gz /usr/java/default/man/man1/javac.1.gz "\\"
    else
      echo -e --slave /usr/bin/$i $i /usr/java/default/bin/$i --slave /usr/share/man/man1/$i.1.gz $i.1.gz /usr/java/default/man/man1/$i.1.gz "\\"; 
    fi
  fi
done

Casi terminado, basta con configurar la versión de java a usar:

update-alternatives --config java

Como no había otra alternativa para javac, se ha configurado automáticamente.

(1) Fuente
(2) Fuente
(3) Fuente

Compilando xscreensaver

Para muchos "compilar" no debería ser una tarea a realizar por un administrador linux, no lo discuto: Hay razones de peso al respecto.

Pero con xscreensaver, esta vez tengo una mejor: Resulta que en CentOS 7 (Con XFCE como Entorno Gráfico), a la fecha, no he podido encontrarlo en los repositorio extra como CentOSPlus, EPEL o incluso RPMForge (El que por cierto esta desaconsejado porque ya no se actualiza).

Así, el procedimiento no ha sido un dolor de cabeza como lo han sido otros, básicamente:

Una vez obtenido el paquete desde la página más oficial posible:

wget http://www.jwz.org/xscreensaver/xscreensaver-5.32.tar.gz

(Pudiendo encontrar en http://www.jwz.org/xscreensaver/download.html la versión más reciente) Y desempacarlo en un luga apropiado:

cd /usr/local/src/
tar -xzvf xscreensaver-5.32.tar.gz

Basta con entrar al directorio

cd xscreensaver-5.32

Configurarlo, compilar e instalar

./configure --with-shadow
make
make install

En cuanto a dependencias, basta con instalar los siguientes paquetes:

yum install gcc xorg-x11-server-devel.x86_64 libXt-devel libXpm-devel motif-devel bc intltool gtk3-devel gtk2-devel libxml2-devel libglade2-devel pam-devel

Si no lo habías hecho antes, el compilador

yum install gcc

Lo que en suma pueda parecer mucho, (Y eso que no han visto el espacio usado) pero la opción es dejar de usar un salvapantallas, o tener que usar Gnome o KDE. O dejar de usar una distribución orientada a servidores como estación de trabajo.

No, parece ser que no se activa openGL, lo que de todos modos no es el fin del mundo. Pero si quieres activarlo no te olvides de revisar si tu sistema lo soporta e instalar las cabeceras:

yum install freeglut-devel.

Sólo es necesario instalar pam-devel si se usa algún módulo PAM para la autenticación de usuarios. En ese caso, configure el paquete de la siguiente forma

./configure --with-pam --with-shadow

Si no lo hace, al iniciar xscreensaver se lanzará un mensaje así:

xscreensaver: 12:19:57: couldn't get password of "alortiz"
xscreensaver: 12:19:57: locking is disabled (error getting password).
xscreensaver: 12:19:57: does xscreensaver need to be setuid?  consult the manual.

Por último, especial mención a uno de los mensajes de error que encontré mientras buscaba las dependencias del sistema:

configure: error: Your system doesn't have "bc", which has been a standard
                  part of Unix since the 1970s.  Come back when your vendor
                  has grown a clue.

El cual fácilmente arranca una sonrisa.

(1) Fuente
(2) Fuente

Compilando la última versión del driver wanpipe en Elastix 2.5

Al seguir las instrucciones de la página oficial el siguiente error aparece:

Press [Enter] to continue...

Compiling WANPIPE LibSangoma API library ...Failed.

Press [Enter] to continue...

Compiling WANPIPE LibStelephony API library ...Failed.

El problema es que la instalación de las librerías LibSangoma API y LibStelephony API requieren del comando libtoolize que es proporcionado por el paquete libtool... O al menos eso se supone, la cuestión es que Elastix proporciona una versión más nueva de dicho paquete que no incluye ese comando

Luego, la solución consiste en instalar la versión proporcionada por CentOS. Después de instalar los paquetes para crear el entorno de desarrollo (Revise el procedimiento descrito en el link de arriba), ejecute lo siguiente:

yum remove libtool

yum install libtool.x86_64 --disablerepo=* --enablerepo='base'

Adicionalmente, cada vez que vaya a actualizar el sistema debe excluir dicho paquete del proceso con la opción -x:

yum update -x libtool

Por cierto, la gente de Elastix mantiene una campaña en indiegogo para financiar la Migración de Elastix 2.5 a CentOS 7. Supongo que las razones pueden no parecer del todo claras (De hecho, muchas cosas parecen no tener sentido en este proyecto). No obstante, no veo mala idea el colaborar.

Error con aptitude update

Ciertamente, el siguiente error es difícil de explicar.

W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/contrib/source/Sources: 404  Not Found
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/non-free/source/Sources: 404  Not Found
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/contrib/binary-amd64/Packages: 404  Not Found
W: Se produjo un fallo al descargar http://debian.salud.gob.sv/debian/dists/wheezy/non-free/binary-amd64/Packages: 404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.
E: No se pudo reconstruir el almacén de paquetes

Resulta que los servidores del trabajo estaban respondían de esta forma a un aptitude update, aún cuando los equipos que uso para laboratorio usaban la misma configuración en el archivo sources.lst.

Supongo que debe existir una mejor solución: Sin embargo, lo que me funcionó fue eliminar del ficheros aquellos ramas que daban problemas. Más o menos de esta forma

#deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free
#deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free

deb-src http://debian.salud.gob.sv/debian/ wheezy main
deb-src http://debian.salud.gob.sv/debian/ wheezy main

deb http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free

deb http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free

Luego, actualizo la lista de paquetes sin problemas

aptitude update

Vuelvo a activar las ramas problemáticas

deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free
deb http://debian.salud.gob.sv/debian/ wheezy main contrib non-free

deb http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian/ wheezy-updates main contrib non-free

deb http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free
deb-src http://debian.salud.gob.sv/debian-security/ wheezy/updates main contrib non-free

Y esta vez la actualización sucede sin problemas:

aptitude update

Un de las tantas cosas que evidencian el final feliz a este problema es que el comando avisa que hay nuevos paquetes disponibles. (El tanto el pensaba que ya no existían porque había creado su lista de paquetes disponibles sin las ramas problemáticas)

Estado actual: 50 actualizados [+13], 36480 nuevos [+35024].

'nomodeset' y gráficos Intel

Los dispositivos Intel son sin duda de los más soportados en Linux.
Hace años, comprar una motherboard Intel me cambio la vida en cuanto a la experiencia con gráficos.

Sin embargo un pequeño inconveniente aparece con las versiones más recientes del kernel linux: Tomo como referencia el 3.11-6 que trae OpenSuSE 13.1 y el que trae Fedora 20, 3.11.10.
En openSuse es posible que el vídeo no se muestre correctamente. Tal como si no se hubiera instalado el driver correctamente. En Fedora, es la resolución de pantalla que no se muestra correctamente, y no es posible cambiar entre todas las resoluciones que sabemos están soportadas. Estos problemas se deben a nomodeset

nomodeset

The newest kernels have moved the video mode setting into the kernel. So all the programming of the hardware specific clock rates and registers on the video card happen in the kernel rather than in the X driver when the X server starts.. This makes it possible to have high resolution nice looking splash (boot) screens and flicker free transitions from boot splash to login screen. Unfortunately, on some cards this doesnt work properly and you end up with a black screen. Adding the nomodeset parameter instructs the kernel to not load video drivers and use BIOS modes instead until X is loaded.

La solución no podría ser más sencilla: Removemos nomodeset. En el fichero /etc/default/grub buscamos en la línea GRUB_CMDLINE_LINUX la opción nomodeset y la borramos.

Ahora, actualizamos propiamente la configuracion del kernel con algo tan simple como ejecutar desde consola:
grub2-mkconfig

La ventaja de modificar indirectamente /boot/grub2/grub.cfg de esta forma es que la configuración no ha de perderse con actualizaciones del Kernel u otras modificaciones que hagamos.

Por otra parte, hay que tener en cuenta que este arreglo sólo funciona para los problemas descritos (Y quizá algunos más) pero exclusivamente para gráficos Intel.

Fuente